OA16641A - Module for managing a transaction between a terminal and an electronic device. - Google Patents

Abstract

This transaction module (MOD) can be integrated into a terminal to authorize a transaction between a first application residing in this terminal and a second application residing in an electronic device, this module (MOD) comprising: - means (10) for obtaining a code (OTP); - an interface (31) with means (COM) of communication of the terminal allowing the sending, to a secure server, of a validation request comprising code (OTP); - means (CONV) for generating an audio signal (AUD) from the code (OTP); - an interface (32) with a module of the terminal capable of sending the audio signal (AUD) to a loudspeaker (HP) of the terminal with a view to its reproduction; and - means (10) for authorizing the transaction (TR) on receipt of a validation message from the secure server (SRV), this message being representative of the reception, by the secure server, of said code (OTP) in origin of the electronic device.

Description

Module for managing a transaction between a terminal and an electronic device

Background of the invention

The present invention lies in the field of communication terminals, and in particular in the field of intelligent terminals otherwise known under the name of Smartphone.

Recently, these terminals have developed considerably, and 10 offer their users the possibility of installing numerous applications called resident applications.

Some of these applications can be used to transact with the resident application of another electronic device.

In this document, the term “transaction” will be understood to mean any exchange of information with the aim of obtaining an agreement between the resident terminal applications, under the authority of a secure server, sometimes also called a trusted server.

The major obstacle, in the current state of the art, to the deployment of these transactions between terminals is undoubtedly due to the fact that there is no simple solution for the implementation of these transaction mechanisms, a solution which may be apply in the same way to any type of resident application, regardless of its context.

Moreover, and very damagingly, the solutions known to date require that the two terminals parties to the transaction implement the same application for managing the transaction or at least one compatible application.

The invention solves the aforementioned drawbacks.

Purpose and summary of the invention

More particularly, and according to a first aspect, the invention relates to a transaction module that can be integrated into a terminal to authorize a transaction between a first application residing in this terminal and a second application residing in an electronic device, this module comprising:

- means for obtaining a code;

an interface with means of communication of the terminal allowing the sending, to a secure server, of a validation request comprising the code;

- means for generating an audio signal from the code;

an interface with a module of the terminal capable of sending the audio signal to a loudspeaker of the terminal with a view to its reproduction; and

means for authorizing the transaction on receipt of a validation message from the secure server, this message being representative of the reception, by the secure server, of the code from the electronic device.

Thus, and in general, the transaction between the terminal and the electronic device is validated by the secure server, as soon as it receives the same code from each of these entities.

According to the invention:

- The code is sent by the terminal to the secure server digitally;

- The code is converted into an audio signal by the terminal (modulation), emitted by the loudspeaker of the terminal and picked up by the microphone of the electronic device;

- The code is sent by the electronic device to the secure server, either in audio format, that is to say as captured by the microphone, or converted into digital form when the electronic device incorporates a demodulation function or means of 'recording.

Very advantageously, the demodulation can therefore be performed by the secure server. In this embodiment, the only means necessary for the electronic device are the microphone to pick up the audio signal and the means of communication with the secure server to transmit this audio signal to it. Therefore, the electronic device party to the transaction can be a conventional mobile phone.

In one embodiment, the terminal comprises means for generating the code and the means for obtaining the transaction module obtain the code from these generation means.

In one embodiment, the means for obtaining the transaction module comprise an interface with a memory constituting a reservoir of codes.

This memory can be internal or external to the terminal. In one embodiment, a limited number of codes is installed by a server in an internal memory of the terminal, giving it the possibility of carrying out only a limited number of transactions. In another embodiment, the terminal accesses codes generated by a trusted server, under determined conditions which are not the subject of this patent.

In one embodiment, the transaction module comprises a software interface with the first resident application, the software interface comprising a function used by the first resident application to request the authorization of the transaction, and a function allowing the first application resident to receive a value representative of the authorization of the transaction by the electronic device and the validation of this transaction by the secure server.

It is in fact considered that the fact that the audio signal has been received by the electronic device is proof that the user of this electronic device authorizes the transaction, since this requires him to position his electronic device at a very short distance from the top. terminal speaker.

We now look at the point of view of the other party to the transaction.

It has already been mentioned that the electronic device of this other part may or may not include the means for demodulating the audio signal picked up by its microphone.

Thus, and according to a second aspect, the invention relates to a transaction module that can be integrated into the electronic device to authorize a transaction between a first application residing in this electronic device and a second application residing in a terminal, this module comprising:

an interface for receiving an audio signal picked up by a microphone of the electronic device, the audio signal having been emitted by a loudspeaker of the terminal;

- Means capable of generating a code from the audio signal; and

- an interface with means of communication of the electronic device allowing the sending of the code to a secure server, in order to authorize the transaction.

And according to a third aspect, the invention relates to a transaction module that can be integrated into an electronic device to authorize a transaction between a first application residing in this electronic device and a second application residing in a terminal, this module comprising:

an interface for receiving an audio signal picked up by a microphone of the electronic device, the audio signal having been emitted by a loudspeaker of the terminal;

- Means capable of detecting a first part of the audio signal; and

an interface with communication means of the terminal allowing the sending of the recording of a second part of the audio signal recorded following said detection, to a secure server in order to authorize the transaction.

In one embodiment of the transaction module according to this second or third aspect, this module comprises a software interface with the first resident application, the software interface comprising a function used by the first resident application to request the transaction module to authorize the transaction.

The invention also relates to a transaction module which incorporates the means of a transaction module according to the first aspect and the means of a transaction module according to the second or the third aspect.

Brief description of the drawings

Other characteristics and advantages of the invention will emerge from the description given below with reference to the appended drawings which illustrate an exemplary embodiment thereof without any limiting nature.

- Figure 1 shows a transaction between two smart phones incorporating transaction modules according to a first embodiment of the invention;

- Figure 2 shows a transaction between a smart phone of Figure 1 and a conventional mobile phone;

FIG. 3 represents a transaction between two smart phones incorporating transaction modules in accordance with a second embodiment of the invention; and

FIGS. 4 and 5 represent communication modules according to two particular embodiments of the invention.

Detailed description of a first embodiment of the invention

FIG. 1 represents two intelligent mobile telephones TRM, DSP commonly called Smartphone.

The TRM smart mobile telephone constitutes a terminal within the meaning of the invention.

The intelligent mobile telephone DSP constitutes an electronic device within the meaning of the invention.

Each of these AQ, DSP smart phones has a transaction MOD according to the invention.

This MOD transaction module mainly interfaces with a software application RES1, RES2 resident in the TRM, DSP smart phone.

It also interfaces with an OS operating system of these smart phones.

More specifically, in the exemplary embodiment described here, it interfaces with COM communication means of the smart phone and with DRV software drivers (driver) capable of controlling smart phone peripherals, more precisely an HP speaker. in the case of the TRM smartphone and a MIC microphone in the case of the DSP smartphone.

In the embodiment described here, the transaction module MOD further comprises a software interface easily allowing the developer of the resident applications RES1, RES2 to interface with this transaction module.

More precisely, in the exemplary embodiment described here:

- the MOD transaction module of the TRM smart phone offers an API software interface with the first resident application RES1, this interface comprising two functions AUT_RQ, AUT_RX usable by the first resident function RES1, the AUT_RQ function to request% t16641 the authorization of a transaction and the AUT_RX function for receiving a value representative of the authorization of the transaction by the intelligent telephone DSP and of the validation of this transaction by a secure server SRV; and

the transaction module MOD of the smart phone DSP offers the resident application RES2 a software interface AP2 comprising a function AUT_TX used by this resident application to ask the transaction module MOD to authorize the transaction.

The COM communication modules included in the operating systems OS of each of the TRM and DSP smart phones are able to communicate with the aforementioned secure server SRV.

Preferably, the smart telephones TRM, DSP and the secure communication server SRV communicate via a mobile telecommunications network.

We will now explain in detail how a TR transaction can be performed between the RES1, RES2 applications resident in the TRM and DSP smart phones, in cooperation with the secure server SRV.

We will assume, in this example, that the mobile terminal TRM includes an interface 34 for obtaining OTP codes stored in a storage unit 15.

These codes are, in this example, generated by a trusted server, not shown.

Either way, each of these codes is unique. It can preferably be designed to be used only once: this is referred to as a one-time code or in English “one time password” OTP.

We will assume in this example that the resident applications RES1, RES2 are preparing to carry out a transaction and have previously established a dialogue, possibly exchanged information, which is not strictly speaking part of the invention.

To request the authorization of the TR transaction, the resident application RES1 of the TRM smartphone uses the AUT_RQ software application provided by the programming interface API of the MOD module.

This function triggers the obtaining, by the transaction module MOD of the TRM smart phone, of an OTP code, via interface 34, from memory 15.

This OTP code is sent by the communication means COM of the operating system OS of the TRM smart phone to the secure server SRV in an RQVAL validation request. In FIG. 1, the interface between the transaction module MOD and these communication means COM has been referenced 31.

In the embodiment described id, the validation request RQVAL also comprises the identifiers TRM, DSP of the smart phones TRM, DSP.

The TRM smartphone's MOD transaction module then converts the OTP code into an AUD audio signal. For this purpose, it uses its own CONV conversion resources.

The MOD transaction module of the TRM smartphone sends the audio signal AUD to an HP speaker of this phone for playback. In FIG. 1, 32 is the interface between the transaction module MOD and the DRV software drivers controlling this loudspeaker.

To complete the transaction, the TRM and DSP smartphones must be close enough, and for example positioned head-to-tail, so that the audio signal AUD, output from the HP speaker of the TRM smartphone, is picked up by the MIC microphone of the phone intelligent DSP.

When this is the case, the DRV software driver of the OS operating system of the DSP smartphone, in charge of controlling the microphone, routes this audio signal AUD to the MOD transaction module of this phone.

In FIG. 1, 33 is the interface between the transaction module MOD and the DRV software drivers controlling this microphone.

In the embodiment described here, the conversion means CONV of this transaction module MOD convert the audio signal AUD to regenerate the OTP (demodulation) code.

It is assumed, in this example, that the resident function RES2 has asked the transaction module MOD, via the software interface AP2, to authorize the transaction TR using the AUTTX application.

Consequently, the transaction module MOD of the intelligent telephone DSP, commands, via the interface 31, the sending to the secure server SRV of an MSG message comprising the OTP code obtained by converting the audio signal AUD received via the acoustic channel established between the loudspeaker and the microphone MIC.

The secure SRV server is therefore able to verify that the OTP code received from the first TRM smart phone is identical to that received from the second DSP smart phone, this identity being representative of the acceptance, by the DSP smart phone of the transaction proposed by the TRM smartphone.

Therefore, the secure SRV server sends a validation MSGVAL message to the TRM smartphone.

In the embodiment described here, this validation message MSGVAL comprises the OTP code and the DSP identity of the DSP intelligent telephone.

This message is received by the transaction module MOD of the TRM smart phone via interface 31. The AUT_RX function accessible via the software interface API of the transaction module MOD then returns to the resident function RES1 a value representative of the authorization of the TR transaction by the DSP smart phone and the validation of this transaction by the secure SRV server.

Detailed description of a second embodiment of the invention

FIG. 2 represents an intelligent mobile telephone TRM and a conventional mobile telephone TEL conforming to the GSM standard.

The TRM smart mobile phone described with reference to this figure is identical to that described with reference to Figure 1.

The mobile telephone TEL does not include a transaction module MOD in accordance with the invention.

In this second embodiment, the transaction module MOD in accordance with the invention is included in the secure server SRV.

In this second embodiment, when the SRV server receives the validation request RQVAL comprising an OTP code of the intelligent telephone TRM and the number of the conventional telephone TEL, it establishes a GSM communication channel CH with the conventional telephone TEL.

This communication channel allows the secure server SRV to receive the audio signal AUD picked up by the microphone MIC of the conventional telephone TEL.

In the embodiment described here, the transaction module MOD of the secure server converts the audio signal AUD to generate the OTP code.

The secure server SRV is therefore able to verify that the OTP code received, from the telephone TEL, in audio form AUD, by the GSM channel CH corresponds to that received from the intelligent telephone TRM in the validation request RQV.

This correspondence reflects the fact that the telephones TEL and TRM have been brought closer to one another, proof of the acceptance, by the user of the conventional telephone TEL, of the transaction proposed by the intelligent telephone TRM.

Detailed description of a third embodiment of the invention

FIG. 3 represents two intelligent mobile telephones TRM, DSP conforming to another embodiment of the invention.

The intelligent mobile telephone TRM differs from that described in FIG. 1 in that its transaction module MOD generates a complex audio signal AUD * consisting of a first part of audio signal CH RP and of a second part of audio signal AUD.

The first CHRP part is a predetermined audio signal, very easily recognizable.

The second AUD part corresponds to the conversion of the OTP code, as in the example of figure 1.

The DSP smart phone differs from that of Fig. 1 in that its transaction module includes a CHRDET detection unit capable of detecting the first part of CHRP audio signal when a complex audio signal AUD * is picked up by the microphone MIC.

When this detection is carried out, the CHRDET detection unit controls recording means REC of the transaction module MOD so that they record the second part AUD of the signal AUD *, the recording, denoted OTP *, being communicated to the server secure SRV for transaction validation.

The secure SRV server is therefore able to verify that the OTP code received from the first TRM smart phone corresponds to the OTP * record received from the second DSP smart phone, this correspondence being representative of the acceptance, by the ίο smart phone DSP of the transaction offered by the TRM smartphone.

The invention can be used for any type of transaction, the interface of the MOD transaction module with the resident applications RES1, RES2 being generic.

In the embodiments described in Figures 1 to 3, we have separated the transaction authorization request functions (role of the TRM terminal) and transaction authorization (role of the electronic device DSP).

Of course, in practice, the MOD transaction modules can play both roles.

FIG. 4 represents, for this purpose, a transaction module in a first preferred embodiment of the invention.

This transaction module comprises, in this example an interface 31 with communication means of an electronic device or of a terminal, means 33 for interfacing with a microphone, means 32 for interfacing with a loudspeaker. speaker, means for converting an audio signal into an OTP code, and vice versa, an interface 34 for receiving an OTP code, and software interfaces API, AP2 with the applications resident in the electronic device or the terminal.

FIG. 5 represents a transaction module in a second preferred embodiment of the invention.

This transaction module differs from that of FIG. 4 in that the conversion module CONV only ensures the modulation part but not the conversion of the audio signal received by the MIC microphone into OTP code. It comprises CHRDET means for detecting the first part of the audio signal and REC means for recording the second part of the audio signal, this recording being sent to the secure server by the DSP electronic device which incorporates it with which it communicates via the interface 31.

In the description given above, the data exchanged between the TRM terminal and the SRV server consisted of the OTP code and the DSP, TRM identifiers.

'ht

Only the OTP code is absolutely essential. In some applications, TRM and / or DSP identifiers may not be communicated.

Depending on the chosen application, other types of data can be conveyed and in particular transaction amounts, rights, access codes, passwords, cryptographic keys, or more generally any useful parameter. to the proposed transaction.

In one embodiment, the SRV server maintains a database in which it records the identifiers of the devices which incorporate a MOD transaction module within the meaning of the invention. This allows the server to spontaneously establish a GSM communication channel CH with the electronic device DSP, as in the example of FIG. 2, when this electronic device does not include a MOD module.

It should be noted that the MOD transaction module can be incorporated into terminals or electronic devices of any type: mobile communication terminals, cash register, banknote dispenser, fixed terminal, chip card, SIM card, etc.

The transaction module MOD can also be integrated into a lock, the transaction between the lock and the electronic device DSP in this case being a door opening request subject to validation by the secure server SRV.

BP 50

Cabin

Phone. : (23

E-mill

Claims (7)

1. Transaction module (MOD) that can be integrated into a terminal (TRM) to authorize a transaction between a first application (RES1) residing in this terminal (TRM) and a second application (RES2) residing in an electronic device (DSP) , this module (MOD) comprising: - means (10) for obtaining a code (OTP); - an interface (31) with means (COM) for communicating with said terminal (TRM) allowing the sending, to a secure server (SRV), of a validation request (RQVAL) comprising said code (OTP); - means (CONV) for generating an audio signal (AUD) from said code (OTP); - an interface (32) with a module (DRV) of said terminal (TRM) able to send said audio signal (AUD) to a loudspeaker (HP) of said terminal (TRM) with a view to its reproduction; and - means (10) for authorizing said transaction (TR) on receipt of a validation message (MSGVAL) from said secure server (SRV), this message being representative of the reception, by said secure server, of said code (OTP ) from said electronic device (DSP). 2. A transaction module according to claim 1 characterized in that said means (10) for obtaining comprise an interface (34) with a memory (15) constituting a code reservoir (OTP). 3. Transaction module according to claim 1 or 2 characterized in that it comprises a software interface (API) with said first resident application (RES1), said software interface comprising a function (AUT_RQ) used by said first resident application (RES1) to request the authorization of said transaction (TR), and a function (AUT_RX) allowing said first resident application (RES1) to receive a value representative of the authorization of the transaction by the electronic device and of the validation of the transaction by said module (MOD). 4. Transaction module (MOD) which can be integrated into an electronic device (DSP) to authorize a transaction between a first application (RES2) residing in this electronic device (DSP) and a second application (RES1) residing in a terminal (TRM) ), this module (MOD) comprising: - an interface (33) for receiving an audio signal (AUD) picked up by a microphone (MIC) of said electronic device (DSP), the audio signal having been emitted by a loudspeaker (HP) of said terminal; - Means (CONV) able to generate a code (OTP) from said audio signal (AUD); and - an interface (31) with means (COM) of communication of the electronic device (DSP) allowing the sending of said code (OTP) to a secure server (SRV) in order to authorize said transaction. 5. Transaction module (MOD) which can be integrated into an electronic device (DSP) to authorize a transaction between a first application (RES2) residing in this electronic device (DSP) and a second application (RES1) residing in a terminal (TRM) ), this module (MOD) comprising: - an interface (33) for receiving an audio signal (AUD *) picked up by a microphone (MIC) of said electronic device (DSP), the audio signal having been emitted by a loudspeaker (HP) of said terminal; - means (CHRDET) capable of detecting a first part (CHRP) of said audio signal (AUD *); and - an interface (31) with means (COM) of communication of the electronic device (DSP) allowing the sending of the recording (OTP *) of a second part (AUD) of said audio signal (AUD *) to a server secure (SRV) for the purpose of authorizing said transaction. 6. Transaction module according to claim 4 or 5, characterized in that it comprises a software interface (AP2) with said first resident application (RES2), said software interface (AP2) comprising a function (AUT_TX) used by said first application resident (RES2) to request said transaction module (MOD) to authorize said transaction (TR). 7. Module (MOD) comprising the means of a transaction module according to any one of claims 1 to 3 and the means of a transaction module according to any one of claims 4 to 6. 14 pages ORIGINAL TAGATTITÜDE VICARIOUS