FR3029721A1 - METHODS OF IMPLEMENTING A TRANSACTION VIA A MOBILE TERMINAL - Google Patents

Abstract

The present invention relates to a method for implementing a transaction via a mobile terminal (1) connected to an operator network (21), characterized in that it comprises steps of: (a) Transmission from the terminal (1) ) to a server (2) of the operator network (21) of a request containing identification information of the terminal (1); (b) generating by the server (2) 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 an audible signal transmitted to the terminal (1); (d) transmitting said sound signal by a loudspeaker (10) of the terminal (1) so as to be picked up by sound pick-up means (31) of a payment equipment (3); (e) inverse 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 based on the result of the verification.

Description

TECHNICAL FIELD The present invention relates to the field of electronic banking. More precisely, it concerns a precedence of implementation of a mobile phone transaction. STATE OF THE ART Whether in a private vehicle or public transport, traveling requires the payment at regular intervals of small lump sums: in a personal vehicle, it is most often a question of tolls or parking, and for transport in common are tickets. In one case as in the other, counters and today automatic terminals allow the transaction to be made and to collect these sums. Automatic kiosks are usually automatons that can receive coins, notes or bank cards. Alternatively or in addition, the terminals may accept subscription cards (particularly NFC contactless cards) which trigger a payment, for example, monthly for an associated user, so as to free him from paying each time he take the transport. 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.

We also know payment means via smartphone-type mobile terminal, which allow the payment dematerialized avoiding the need to have a dedicated card. Connected to the internet, these smartphones establish a wireless communication with the terminal (or alternatively display a QR code type bar code that the terminal can read) so as to authenticate the user and trigger an online payment. The payment methods by smartphone are satisfactory but are not yet accessible to all since they require the possession of a recent and expensive mobile terminal. Many users still have a simple GSM terminal without internet access and a basic screen. Moreover, 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 dematerialized payment method that overcomes the above difficulties and allows a dematerialized 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) Transmitting from the terminal to a server of the operator network a request containing terminal identification information; (b) Generating a payment token by the server based on data associated with the terminal stored in a database of the server; (c) Sound transcription of the token by the server in an audible signal transmitted to the terminal; (d) transmitting said sound signal by a loudspeaker of the terminal so as to be picked up by means of sound recording of a payment equipment; (e) Reverse transcription of the sound signal by an equipment processing module into the payment token; 3029721 3 (f) Verification of the token by the processing module, and authorization of the transaction based on the result of the verification.

According to other advantageous and nonlimiting features: step (b) comprises the timestamp of the token by the server, the step (f) comprising the comparison of 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, the step (f) comprising the prior decryption of the token by the processing module with a private key of the payment equipment; step (b) furthermore comprises the encryption of the token by the server with a private key of the operator, the step (f) comprising the prior decryption of the token by the processing module with a public key of 15 l. operator; step (b) comprises prefixing the encrypted token with an identifier of the operator, step (f) comprising extracting said identifier from the operator by the processing module so as to select the public key for deciphering the token; Said terminal identification information comprises a telephone number of the terminal; step (a) consists in dialing a telephone number of the server so as to establish a telephone communication between the terminal and the server; Step (b) is implemented following the pressing of a predetermined key of the terminal (1) during said telephone conversation; the data associated with the terminal stored in the database of the server are representative of a remaining counter chips, step (b) being implemented only if said counter has a non-zero value, step (b) ) including, where appropriate, decrementing said counter; Step (f) comprises comparing the token with a list of expired chips, the method comprising a step (g) of adding said verified token to said list of expired chips; the equipment is connected to the server via the Internet network, the method comprising a step (h) of sending a transaction report to the server; step (f) comprises the activation of a mechanical element of the equipment if the transaction is authorized; the mechanical element is chosen from a moving barrier and a printer. According to a second aspect, the invention relates to a payment equipment, comprising a data processing module and sound collection means, characterized in that the data processing module is configured to implement, following the initiation of a transaction from a mobile terminal comprising a loudspeaker: a module for receiving a sound transcription of a payment token associated with the terminal into a sound signal emitted by the loudspeaker and picked up by the means of sound recording; A reverse transcription module of the sound signal in the payment token; - A module for verifying the token and authorizing the transaction according to the result of the verification.

According to a third aspect, the invention relates to a transaction implementation system comprising at least one payment device 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. on the basis of data associated with the terminal stored in a database of the server, and implement a sound transcription of the token into a sound signal transmitted to the terminal.

According to a fourth and fifth aspect, the invention relates to a computer program product comprising code instructions for executing a method according to the first aspect of the invention of implementing a transaction. via a mobile terminal; and computer readable storage means on which a computer program product comprises code instructions for executing a method according to the first aspect of implementing a transaction via a mobile terminal. PRESENTATION OF THE FIGURES Other features and advantages of the present invention will be apparent from 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; FIG. 3 represents the implementation of a preferred embodiment of the method according to the invention; FIG. 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 for implementing a transaction via a mobile terminal 1 connected to an operator network 21. The operator network 21 can be any mobile network, in particular a GSM ("Global System for Mobile Communications") or EDGE ("Enhanced Data Rates for GSM 5 Evolution") network, even though is quite possible that it is a newer and more powerful network of type 3G or 4G. The operator network 21 comprises at least one server 2 of the mobile 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 that to allow the implementation of the method regardless of the operator of the user. Similarly to the operator network 21, the mobile terminal 1 can be any terminal capable of connecting to the network 21, including old mobile phones that do not have complex functionalities (as opposed to smartphones) or terminals partially. broken. In particular, it suffices that the terminal 1 allows a telephone conversation (and therefore it includes a speaker 10) so that the present method can be implemented, and it is not necessary for example that it has internet connection, Wi-Fi connectivity, or even a screen. The present method is intended to allow a transaction between the user of the terminal 1 and a payment equipment 3. By transaction means the transmission of sufficient information to prove a payment electronically by the user, so as to unlock a service at the equipment level 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 payment terminal of the POS type (the mechanical element 32 is then a printer that prints a receipt), a validator (the mechanical element 32 is a mobile barrier preventing access to the users unauthorized), etc. Validator means a device for verifying that a user has paid a service (parking, cinema, library, park, etc.), including a mode of transport (subway portal, toll, etc.) .). In the remainder of the present description, the example of the toll will be taken, the element 32 thus being the toll barrier that opens when the user has paid for his access. In all cases, it suffices that the present equipment 3 comprises 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 recording 31.

The sound pickup means 31 consist at least of a microphone capable of acquiring a sound, possibly placed in an enclosure adapted 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 includes 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.). This data makes it possible to determine whether the user of the terminal has the right to implement the transaction. They can be representative of a balance in one currency, or of a counter of "remaining chips", also called "tickets". The tickets represent a good prepaid for the transaction. They are particularly useful if the terminal 1 is used to recurrently implement a transaction of a constant price, such as the payment of tolls or access on public transport. A ticket is consumed (in the form of a token, which will be described later) each time the implementation of the transaction is required. With reference to FIG. 2, the tickets can be acquired before the implementation of the present method, in a plurality of ways. For example, he can buy tickets on the internet from a computer, from his telephone by dialing a number of the operator (the tickets are then billed with his telephone subscription bill), in the shop via prepaid cards (a zone to scratch 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 that form) at the operator's server 2. Implementation of the method With reference to FIG. 3, the present method starts with a transmission step (a) from the terminal 1 to a server 2 of the operator network 21 of a request containing information from terminal identification 1. As explained, these are typically the telephone number of the terminal 1, but other possibilities exist (MAC address, IMEI, etc.). The request may take a plurality of forms, but preferably it consists of a telephone call to a telephone number of the server 2. Also mentioned is the sending of an SMS message ("Short Message Service") to such a telephone number of the server 2. These two techniques work for any type of operator network 21 and terminal 1, including the oldest, and automatically allow to convey the telephone number of the terminal 1. In the following of the present description, the example of the call will be taken. Thus, at the end of step (a), a telephone call between the terminal 1 and the server 2 is established.

Then follows a second step (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. It should be noted that this step (b) can be triggered following the pressing 5 on a predetermined key of the terminal 1 during said telephone conversation. In particular, as can be seen in FIG. 3, the server 2 can respond to the terminal 1 (for example via a pre-recorded voice message) by indicating a key to be pressed to continue the process. This has many advantages: it makes it possible to acknowledge receipt of the transaction request, to set up 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 allow the user to accurately choose the trigger time of step (b). We'll see why a little further.

By "token" is meant a secure computer element representative of a ticket, i.e. a unique comprehensible code of the equipment 3 as proof of the user's ability to implement the transaction. More specifically, the token is generated only if said data associated with the terminal 1 stored in a database are representative of a sufficient balance or a token counter remaining non-zero. Said data is then modified, for example by decreasing 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 changed after 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 comprises, for example, the generation of a unique code (and possibly its time stamp, i.e. the addition of a code representative of the generation time), and its encryption for security reasons. In particular, step (b) may comprise a first encryption of the token by the server 2 with a public key of the payment equipment 3, 3029721 and / or a second token encryption 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 identifier of the operator to allow its subsequent decryption (we will see how far).

At this stage, the method comprises a step (c) of sound transcription of the token (encrypted) by the server 2 into an audible signal transmitted to the terminal 1. In other words, the server 2 will convert the bit data of the token in a signal representative of a sound, for example by using the voice frequencies (DTMF code, "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 pick-up means 31 of the payment equipment 3. For example, it is sufficient that the user is tapping his phone at the toll level. This use of sound makes it possible to implement the method with any terminal having only the function "telephone". No function 20 NFC, internet, high definition screen, etc. is not required. Similarly it is sufficient that the network 21 is basic (and allows the voice). It will be understood that it is also possible for efficiency reasons, if the network 21 authorizes the internet data, to transmit the sound signal in the form of a sound file, for example of the mp3 type.

This sound technique is known, for example the application W02011 / 010052 which uses it in another frame (open 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 checked, that is to say processed for last validity, by the processing module 30 in step (f). For that, it is deciphered if necessary. The extraction of the identifier of the operator (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 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 the device 3 (this second decryption is the reverse operation of the first encryption with the public key of the device 3). This is the best means of securing because this private key of the equipment 3 can not be known by a third party who would intercept the token is attempting to use fraudulently. Once the token is completely deciphered, its code is checked, for example using an algorithm checking a mathematical property. Preferably, the token is "self-supporting", that is to say that it contains all the information necessary for its validation.

Alternatively or in addition, the token may be compared with a list of expired chips, i.e. already in use (and must be absent for validity to be confirmed). If the token has been timestamped, step (f) also includes comparing the timestamp with the current time. Indeed, it is desirable to define an expiry time of the tokens generated and played (for example one minute), so as to prevent even more fraudulent use of the chips (case of someone who would record the sound played for the replay later). This embodiment makes it very useful for step (b) to be conditioned at the touch of 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 a window of validity of the shortest possible token.

3029721 12 If the token is verified, then the transaction is allowed. This leads, if necessary, to a reaction on the part of the equipment 3, in particular an actuation of the element 32. In the case of a toll, the mobile barrier of the toll is raised and the user can advance. A ticket can be printed as well. If the data processing module 30 uses a list of expired chips, then the method includes a step (g) of adding said verified token to said list of expired chips. Note that the data processing module 30 may alternatively use a list of authorized tokens: during the verification, the module 30 verifies that the token is compliant and that it is present in this list, the step (g ) then consists in the deletion of said verified token from the list of authorized tokens. Invoicing and management of the tokens used At this stage, the payment equipment 3 has authorized the transaction, but its payment has not properly been made yet. Indeed, it is the operator of the network 21 who has 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 in FIG. 4, of sending a transaction report to the server 2. This is possible if the equipment 3 is connected to the server 2 This step (h) is not necessarily in line with the rest of the process, and can for example be carried out periodically, for example every evening, so as to transmit the whole transaction report of the day. This step has two objectives: to indicate to the server 2 which chips have actually been consumed (the server 2 advantageously holds its own list of authorized tokens, and the chips actually consumed will be deleted), and charge the telephone operator to obtain the payment of conducted transactions.

According to a second aspect, the invention relates in particular to the payment equipment 3 used for the implementation of the present method. As previously explained, the payment equipment 3 comprises a data processing module 30 and sound capturing means 31 (and, if necessary, 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 loudspeaker 10: a module for receiving a sound transcription of a token of Payment associated with the terminal 1 in a sound signal emitted by the loudspeaker 30 and picked up by the sound pickup means 31; - A reverse transcription module of the sound signal into the payment token; A token verification module (including, where appropriate, 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, according to data associated with the terminal 1 stored in a database of the server 2, and implement a sound transcription of the token in a sound signal transmitted to the terminal 1. The system may also include the terminal or terminals Computer Program Product According to a fourth and fifth aspect, 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 (eg a memory of the equipment 3) on which this computer program product is found.

Claims (17)

REVENDICATIONS1. Method for implementing a transaction via a mobile terminal (1) connected to an operator network (21), characterized in that it comprises steps of: (a) Transmission from the terminal (1) to a server (2) of the operator network (21) of a request containing identification information of the terminal (1); (b) generating by the server (2) 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 an audible signal transmitted to the terminal (1); (d) transmitting said sound signal by a loudspeaker (10) of the terminal (1) so as to be picked up by sound pick-up means (31) of a payment equipment (3); (e) inverse 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 based on the result of the verification. 2. The method of claim 1, wherein step (b) comprises the timestamp of the token by the server (2), the step (f) comprising the comparison of 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), the 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 the encryption of the token by the server (2) with a private key of the operator, the step (f) comprising the prior decryption of the token by the processing module (30) with a public key of the operator. The method according to claim 4, wherein step (b) comprises prefixing the encrypted token with an identifier of the operator, step (f) comprising extracting said identifier from the operator by the module. processing (30) so as to select the public key for decrypting the token. 15 6. Method according to one of claims 1 to 5, wherein said identification information of the terminal (1) comprises a telephone number of the terminal (1). The method of claim 6, wherein step (a) comprises dialing a telephone number of the server (2) so as to establish a telephone communication between the terminal (1) and the server (2). ). 8. The method of claim 7, wherein step (b) is carried out following the pressing of a predetermined key of the terminal (1) during said telephone conversation. 9. The method according to one of claims 1 to 8, wherein the data associated with the terminal (1) stored in the data base of the server (2) are representative of a counter of remaining chips, step (b). ) being implemented only if said counter 3029721 17 has a non-zero value, step (b) possibly including decrementing said counter. The method of one of claims 1 to 9, 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 chips. 11. Method according to one of claims 1 to 10, wherein the equipment (3) is connected to the server (2) via the internet network (20), the method comprising a transmission step (h) of a transaction report to the server (2) 12. The method according to one of claims 1 to 11, wherein step (f) comprises activating a mechanical element (32) of the equipment (3) if the transaction is authorized. The method of claim 12, wherein the mechanical element (32) is selected from a moving barrier and a printer. 14. Payment equipment (3), comprising a data processing module (30) and sound pick-up 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 an audible signal transmitted by the loudspeaker (30) and picked up by the sound pickup means (31); A reverse transcription module of the sound signal into the payment token; 3029721 18 - A module for verifying the token, and authorizing the transaction according to the result of the verification. 5 15. Transaction implementation system comprising at least one payment device (3) according to claim 14 and at least one server (2) of the operator network (21), the server (2) being configured to generate a payment token. payment, on request containing identification information of a 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 in a sound signal transmitted to the terminal (1). 15 16. A 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 13 when said program is run on a computer .. 20 17. A storage medium readable by a computer equipment on which a computer program product comprises code instructions for the execution of a method for implementing a transaction via a mobile terminal (1) according to one of the following: Claims 1 to 13. 25