WO2018024980A1

WO2018024980A1 - Method for implementing a transaction from an electronic transaction means

Info

Publication number: WO2018024980A1
Application number: PCT/FR2017/052156
Authority: WO
Inventors: Arnaud BELLEE; Jacques Burger
Original assignee: Orange
Priority date: 2016-08-01
Filing date: 2017-07-31
Publication date: 2018-02-08
Also published as: FR3054701A1

Abstract

The present invention relates to a method for implementing a transaction from an electronic transaction means (1, 10) of a user, on which is stored at least one transaction module capable of authorising a transaction when it is activated, the electronic transaction means (1, 10) further comprising a communication unit (13) for communicating with a network (20); the method being characterised in that it comprises implementing by the electronic payment means (1, 10) of steps of: (a) obtaining from a server (21) of the network (20) via the communication unit (13), a list of identifiers of beneficiaries of recurring transactions; (b) receiving a transaction request intended for said transaction module, the request comprising at least one amount of said transaction and an identifier of the beneficiary of said transaction; (c) determining an authentication procedure of the user of the electronic payment means (1, 10) from a plurality of procedures depending on the amount and identifier of the beneficiary of said received transaction, and on the list of identifiers of beneficiaries of recurring transactions; (d) if said determined authentication procedure is completed, activating said transaction module, and sending a transaction authorisation in response to said transaction request.

Description

Method for implementing a transaction from an electronic transaction means

GENERAL TECHNICAL FIELD

The present invention relates to the field of transactions using mobile terminals or electronic cards.

More specifically, it relates to a method for implementing a transaction from an electronic transaction means of a user.

STATE OF THE ART

It is now possible to conduct a transaction at a payment terminal via a physical or dematerialized bank card (or "virtualized") that is to say simulated by an electronic medium, for example a mobile terminal. .

In one case as in the other, it is planned for small amounts (less than 20 €, threshold called "regulation") to avoid entering a credit card code (the bank PIN) including putting in a contactless payment with a payment terminal, for example of the NFC type. This greatly reduces the handling and the time required for the transaction because the user only has to approach his card or smartphone from the terminal to pay, and thus to avoid consumers queuing at the checkout.

Today, the regulatory threshold for payment without a PIN is low and set globally by banks so as to avoid fraud. Rolling it up would increase the number of eligible transactions and save time, but would mathematically cause more fraud in the face of larger winnings.

US 2016/132880 A1 discloses rules relating to the authorization of contactless payment transactions. After providing contactless payment information to a merchant, the mobile device receives a request for authorization of the transaction. The details of the transaction in the query are compared to the rules stored on the mobile device. Among these rules, some merchants may be specified, for which the regulation threshold does not apply. However, this system does not eliminate the risk of fraud and the way to select merchants remains problematic. It would therefore be desirable to have a new payment solution per terminal that is more ergonomic but equally secure.

PRESENTATION OF THE INVENTION The present invention thus relates, according to a first aspect, to a method for implementing a transaction from an electronic transaction means of a user, on which at least one transaction module adapted to authorize is stored. a transaction when activated, the electronic transaction means further comprising a communication unit with a network;

The method being characterized in that it comprises the implementation by the electronic payment means of steps of:

(a) Obtaining from a network server via the communication unit a list of recipients of recurring transactions;

(b) receiving a transaction request for said transaction module, the request comprising at least one amount of said transaction and an identifier of the beneficiary of said transaction;

(c) determining a method for authenticating the user of the electronic payment means among a plurality of procedures based on said amount and identifier of the beneficiary of said transaction received, and said list of recurring transaction beneficiary identifiers ;

(d) If said determined authentication procedure is completed, activating said transaction module, and issuing a transaction authorization in response to said transaction request.

(E)

The use of a transaction history coupled with a determination (in particular by a security element) of a transaction procedure to be envisaged makes it possible to bypass the payment regulation threshold without a PIN, so as to increase this threshold virtually. in recurring merchants with whom the user has a relationship of trust. This increases the number of fast transactions possible, and makes life easier for everyone without compromising security.

According to other advantageous and nonlimiting features:

The electronic transaction means is chosen from a physical electronic card and a mobile terminal on which said transaction module is associated with an electronic card, and adapted to authorize a transaction on behalf of said electronic card when it is activated;

The electronic transaction means is a mobile terminal comprising a data processing module and a security element on which is stored said transaction module;

The security element is either a hardware element chosen from a subscriber identification card and a secure execution space of the terminal's data processing module, or a software element emulated by the data processing module of the terminal; terminal according to the Hosted Card Emulation architecture, HCE;

The security element implements said transaction module and a risk module storing said list of recurring transaction beneficiary identifiers, and the data processing module implements a management module of the transaction module (s); , step (b) comprising interrogating the risk module by the targeted transaction module;

Step (a) comprises the reception by the management module of historical data representative of previous transactions, the generation of said list of recurring transaction beneficiary identifiers by the management module from said historical data. representative of previous transactions, and the transmission of said list to the risk module;

The electronic transaction means is an electronic payment means, the transaction request being received in step (a) from an electronic payment terminal in wireless communication with the electronic payment means, the transaction authorization being issued in step (d) to the electronic payment terminal;

The method further comprises a step (e) of transmitting the transaction authorization to a bank server associated with said bank card via the network; • said authentication procedure of the user of the electronic payment means is determined between a normal procedure and a simplified procedure;

• said normal procedure includes the verification of a PIN entered by the user and / or the verification of a biometric parameter of the user, and the simplified procedure does not include verification of a PIN entered by the user or checking a user biometric parameter;

Step (d) comprises, in the case of a normal procedure, the transmission by the targeted transaction module, addressed to the management module, of a request to present a confidential code associated with the transaction module; management being configured to request and obtain via a terminal interface said confidential code;

Each recurrent transaction beneficiary identifier of said list is associated with a threshold, the step (c) comprising:

- If said identifier received from the beneficiary of the transaction belongs to said list, the authentication procedure of the user of the electronic payment means is determined to be the simplified procedure if the received transaction amount is less than or equal to the associated threshold in the list to the received identifier;

A default threshold is stored in the electronic transaction means, each threshold of said list being greater than the default threshold, step (c) comprising:

- If said identifier received from the beneficiary of the transaction does not belong to said list, the authentication procedure of the user of the electronic payment means is determined to be the simplified procedure if the transaction amount received is less than or equal to the threshold by default ;

The method comprises a step (e) of notifying the authorized transaction to the server so as to update said list of recurring transaction beneficiary identifiers.

According to a second aspect, the invention relates to an electronic transaction means on which is stored at least one transaction module adapted to authorize a transaction when it is activated, and comprising a communication unit with a network, The electronic transaction means being configured for:

- Obtaining from a network server via the communication unit a list of identifiers of recipients of recurring transactions;

receiving a transaction request for said transaction module, the request comprising at least one amount of said transaction and an identifier of the beneficiary of said transaction;

determining a method for authenticating the user of the electronic payment means among a plurality of procedures based on said amount and identifier of the beneficiary of said transaction received, and said list of recurring transaction beneficiary identifiers;

If said determined authentication procedure is completed, activate said transaction module, and issue a transaction authorization in response to said transaction request. According to other advantageous and non-limiting features, the electronic transaction means is a mobile terminal, the a transaction module associated with an electronic card, and adapted to authorize a transaction on behalf of said electronic card when activated. According to a third aspect, the invention relates to a computer program product comprising code instructions for executing a method according to the first aspect of the invention to implement a transaction from an electronic transaction means. of a user.

According to a fourth aspect, the invention relates to a storage means readable by a computer equipment on which this computer program product is found.

PRESENTATION OF THE FIGURES Other features and advantages of the present invention will appear on reading the description which follows of a preferred embodiment. This description will be given with reference to the appended drawings in which:

FIG. 1 is a diagram of a general network architecture for the implementation of the invention; - Figures 2a-2c show three embodiments of implementation of a transaction via the method according to the invention.

DETAILED DESCRIPTION

Principle

As previously explained, the limit amount for the payment without a PIN (generally without any other authentication other than the possession of the electronic means of transaction) can not be increased globally otherwise fraud will be encouraged, but it is understood that it would be interesting to get rid of it in the case of merchants where the user comes regularly to consume.

For example, the user usually always comes to his daily shopping in the same stores, and insurance can be provided by recurrence and proximity. In other words, it can be assumed with a very high level of certainty that the user who has paid in the same place a large number of times with the same bank card is trusted, which is not the case if is in a new and remote place. This technique is for example used in the application EP3014542 to check consistency between the current location and said previous locations of the terminal, and where appropriate detect fraudulent transactions.

When trusted users are identified, it would be interesting to raise the regulation threshold, ie to facilitate "simplified procedures" without user authentication, so as to reduce the payment time of these users and thus the time of payment. overall expectation in outlets, especially since these "trust" transactions are a big part if not the majority of transactions.

In order to be able to identify these trusted users and define whether a simplified procedure can be used, the present invention proposes a solution that differs from the known methods using not geolocation, but a past transaction history, rules defined by learning on this base, and a particular architecture to apply its rules without compromising security. Architecture

With reference to FIG. 1, the invention proposes a method for implementing a transaction from an electronic transaction means 1, 10 of a user. By electronic transaction means either a physical electronic card 10 (typically a bank card, see more detail on this later) or a mobile terminal 1.

In all cases, the means 1, 10 stores at least one transaction module adapted to authorize a transaction when it is activated.

As such, the transaction is implemented either directly by using the physical electronic card 10, or by using such a dematerialized card on the terminal 1, ie by reproducing the use of an electronic card 10. In the latter case, said transaction module is associated with an electronic card, and adapted to authorize a transaction on behalf of said electronic card when activated.

The transaction is typically a payment transaction (that is, the physical card 10 or dematerialized on the terminal 1 is a bank card), in particular a proximity transaction initiated by an electronic payment terminal (EPT) 2 as found in most outlets (eg EFTPOS). For the most part, the TPEs have near field communication means (NFC) intended to interact with a physical bank card 10 having this technology, but also enabling them to interact with a mobile terminal 1.

Generally, in the case of payment transactions, a transaction module (called "token") contains (among other things) an identifier of the dematerialized card, if necessary an additional code (for example the visual cryptogram), and a confidential code (the PIN code of the dematerialized card). Note that a terminal 1 can store a plurality of transaction modules so as to simulate several electronic cards.

It will be understood, however, that the present method is not limited to payment transactions, but may relate to any transaction using a physical card 10 or reproduced on a terminal 1, and in particular teletransmissions of care sheets via a vital card, validations of the card. medical procedures via Health Professional Card, etc., provided that the transaction is associated with an amount of said transaction and an identifier of the beneficiary of said transaction In the remainder of the present application, the example of the payment transaction will be taken, and the person skilled in the art will be able to translate it to other applications.

The electronic transaction means 1, 10 further comprises a communication unit 13 with a network 20 (for example the Internet), in order to communicate with a control server 21 of the network 20. In the case where the electronic transaction means is a mobile terminal 1, it is simply a wireless communication unit with a mobile network 15 (3G, 4G, Wi-Fi, etc.) itself connected to the network 20. The connection via this unit 13 is then distinct from the one in the near field (wireless connection of proximity, in general NFC, but also Wi-Fi or Bluetooth) that the terminal 1 can have with a TPE 2 (it is quite possible that the two connections are active simultaneously). In the case of a physical electronic card 10, either this card is an advanced card having a communication unit of the same type as that of a mobile terminal, or the unit 13 is merged with the means of field communications near, and then the TPE 2 is configured to allow the card 10 some particular connections with the network 20.

In operation, the TPE 2 is in all cases first connected via a wireless link (NFC, but also Wi-Fi or Bluetooth) by means of electronic transaction 1, 10, and secondly connected to the least one bank server 3 via the network 20, but in general the access of the TPE 2 to the network 20 is restricted, so that the TPE can not have access to other equipment than the bank servers 3 and vice versa.

In the particular embodiment where the transaction means is a physical card 10 which has no communication unit 13 other than that adapted to communicate in the near field with the TPE 2, the latter is configured to allow a communication with the control server 21 of the network 20, in addition to the communication with the bank servers 3. It will be understood that in embodiment, the TPE 2 remains limited to connections to the bank servers 3 and the control server 20 so to avoid security breaches.

In the case where the electronic transaction means is a mobile terminal 1, the latter can be of any type, in particular smartphone or touch tablets. It comprises a data processing module 11 (a processor), a data storage module (a memory), an interface user (HMI) 14 comprising for example input means and display means (for example a touch screen).

The terminal 1 also advantageously comprises a security element 12 for storing said transaction module. Preferably, it is an element adapted to allow a connection of the terminal 1 to a mobile communication network, in particular a subscriber identification card. By "subscriber identification card" is meant any integrated circuit capable of performing the functions of identifying a subscriber to a network by means of data stored therein, and more particularly a "SIM" card (of the English "Subscriber Identity Module"), or an "e-UICC" card ("embedded") comprising data processing means in the form of a microcontroller and the memory of type "EEPROM" (for "Electrically-Erasable Programmable Read-Only Memory"), or flash. The invention is not limited to this type of security element. Thus, in another exemplary embodiment, the security element 12 is a secure memory area of the mobile terminal such as a "TEE" (Trusted Execution Environment) component embedded in the data processing module 11. , or a dedicated hardware element of the terminal 1 (for example a microcontroller, an "eSE" chip for "(embedded) -Secure Element" or any "Secure Component GP (GlobalPIatform)"), or even a removable component of type microSD ("SD" for Secure Digital).

As an alternative to a "physical" security element 12, the data processing module 1 1 ("non-secure" processor) may have a Host Card Emulation (HCE) feature, which enables it to "Emulate" a security element, and manage directly and securely the transaction module. In such an embodiment, it will be understood that the mobile terminal 1 still comprises a security element 12, but that it is purely software.

In any case, the data processing module 1 1 of the terminal 1 implements preferably a "wallet" type management module, ie an electronic wallet application. If the user wants to use one of his dematerialized electronic cards for a transaction, he just has to open the wallet as the only payment application, and the latter offers him to choose between the cards (and more particularly between the modules). card transactions) that he wants to use, he just has to enter (if necessary, see below) the associated PIN. Wallets also provide additional features such as PIN code change.

This wallet can be cleverly completed by a "wallet companion", i.e. an authentication module as described in the application FR1562797.

The bank server 3 of the network 20 designates a transaction management platform, and comprises a data processing module 31, for example a processor and a data storage module 32 such as a hard disk or, preferably, an HSM ( for "Hardware Security Module").

It will be understood that the concept of "server 3" may include a plurality of separate banking servers connected and adapted to communicate together.

The control server 21 is typically a server of an operator electronic transaction means 1, 10 and will allow as we will see to trace transaction control data. There may be several, and particularly one per type of means 1, 10 and / or one per payment network.

Method for implementing the transaction Referring to FIGS. 2a-c, three embodiments of the present method according to the invention will be described. It will be understood that these examples are illustrative only. In FIGS. 2a and 2b, there is in the case of a terminal 1 having a separate security element 12 of the SIM card type, and in FIG. 2c it is in the case where there is no element of FIG. distinct security, which is typically the case of a mobile terminal 1 said HCE (Host Card Emulation), where the security element is emulated by the data processing module 1 1 (we will consider that there is always an element 12, but that it is part of the processing module 1 1). The situation will be similar in the case where the means of payment is a physical electronic card 10, since the microprocessor of a physical electronic card 10 is by definition a security element.

In the remainder of the description, the preferred example of the transaction will be taken by means of a mobile terminal 1, but will be described later as adapting the present method to other means of electronic transaction and in particular a physical card. 10. In a first step (a), the terminal 1 (and more precisely a risk module stored in the security element 12) obtains (directly or indirectly) from the control server 21 of the network 20 via the communication unit 13 (typically via a mobile network 15 in the case of the terminal 1) a list of recurring transaction beneficiary identifiers.

This list, constructed by learning, is generated either by the data processing module 1 1 of the terminal 1 (more precisely by the wallet) from historical data representative of the previous transactions provided by the server 21 (in the case of FIGS. and 2c, it is understood that it is obtained indirectly), either directly by the server 21 (in the case of Figure 2b, note that this principle could be applied to the case of Figure 2c). The associated transfers are referenced 0. in FIGS. 2a-2c

This data can indicate for each merchant (the recipients of transactions) the number of transactions with them for a certain period of time and / or the associated amounts. Preferably, the geolocation is not involved.

The list can be summary and simply list the merchants for whom it is considered that the user has a "recurrent" use in the sense of a predetermined criterion, for example "at least four expenses in the previous month for a total of 'at least EUR 100', or may associate to each merchant a payment threshold in simplified procedure as will be explained below.

The idea is that the presence of a merchant in the list defines a low level of risk associated with the use of a transaction module of the terminal 1 for a transaction with this merchant, and thus allows a simplified authentication procedure the user of the electronic payment means 1, 10 (without user authentication, that is to say typically without PIN code entry) for amounts higher than usual.

This step can be implemented regularly, or at the beginning of the transaction (particularly in the case where the electronic transaction means 1, 10 is a physical card that can communicate with the server 21 only via a TPE 2).

In a step (b), the security element 12 receives a transaction request for a transaction module of said plurality, for example transmitted from a TPE 2 in connection with the terminal 1, in particular once the user has reported wanting to implement a transaction via a card from payment dematerialized he chose for example on his wallet. This step is referenced 1. in Figures 2a-2c.

The request includes at least one amount of said transaction and an identifier of the beneficiary of said transaction (merchant identifier).

It is noted that the TPE 2 can in this step query the matrix of active payment means, so as to select (using a filter) the instance (the transaction module) that will be in charge of the transaction.

In a step (c), is determined by the security element 12, in particular by interrogation of the risk module, a user authentication procedure among a plurality of procedures according to said amount and identifier of the beneficiary of said transaction, and said list of recurring transaction recipient IDs. This step is referenced 2. in FIGS. 2a-2c.

As explained, preferably said authentication procedure of the user of the electronic payment means 1, 10 is determined between a normal procedure and a simplified procedure, but more than two types of procedures can be envisaged if additional authentications were requested. for very high value transactions for example.

As explained above, in a particularly preferred manner, said normal procedure comprises the verification of a confidential code entered by the user and / or a biometric parameter of the user, such as his fingerprint (but preferably only the verification of the code confidential), whereas the simplified procedure does not include verification of a PIN entered by the user ("fast" procedure usually without contact). To rephrase again, the simplified procedure does not include any authentication of the user other than the possession of the transaction means 1, 10.

More precisely, and contrary to the prior art where only the regulation threshold was taken into account, the risk level defines a transaction amount threshold for transition to simplified procedure, ie the maximum amount for which the entry of the PIN code of the user (or any other authentication procedure such as a biometric measurement) is not required to activate the transaction module.

In practice, the choice between simplified procedure and normal procedure is determined by comparing the amount of the transaction with a threshold, this threshold being lower for a non-recurring merchant (who is not in the list and whose transaction is considered normal risk), for a recurring merchant (in the list and therefore the transaction is considered low risk).

Thus, in the normal procedure a threshold said by default is used, corresponding advantageously to the regulation threshold (today € 20), and in the simplified procedure at least a specific threshold greater than the first threshold is used, for example € 50.

In the example of an expense of € 45, the user's PIN will be requested only from non-recurring merchants. More specifically, the "fast" contactless payment will be allowed at the recurring merchant (because it is below the second threshold of 50 €), while it will be refused at the non-recurring merchant (because we are above first threshold of 20 €) and he will be asked to enter his PIN code (in the case of a physical card 10, it will be inserted into the reader).

Note that within the list, some merchants can even be considered "very recurrent" if they verify even higher criteria of amount and frequency of expenditure. This can result in even higher thresholds.

Thus, particularly preferably, each merchant in the list is associated with a threshold calculated by the server 21 or by the wallet management module (i.e. by the data processing module 1 1). Each threshold of said list is greater than the default threshold for the process to be of interest.

In this embodiment, step (c) then comprises:

- If said identifier received from the beneficiary of the transaction belongs to said list, the authentication procedure of the user of the electronic payment means 1, 10 is determined to be the simplified procedure if the transaction amount received is less than or equal to associated threshold in the list to the received identifier;

If said identifier received from the beneficiary of the transaction does not belong to said list, the authentication procedure of the user of the electronic payment means 1, 10 is determined as being the simplified procedure if the amount of transaction received is less than or equal to the default threshold;

- Otherwise (in all other cases), the authentication procedure of the user of the electronic payment means 1, 10 is determined as the normal procedure. It should be noted that, to the extent that simplified procedural authorization at a threshold greater than the regulatory threshold constitutes a derogation from security standards, it is of particular interest that step (c) is managed by a risk module stored in the security element 12.

Such a security element, such as a subscriber identification card, is a physical device of trust that is almost impossible to infect with a Trojan horse, because the installation of applications in these cards is limited to well-defined entities. identified, and controlled by the operator and / or the issuer of the service in relation to the manufacturer of the security element 12.

The determined authentication procedure must then be completed, so that in a step (d) said transaction module can be activated if said determined authentication procedure is completed, in order to issue a transaction authorization in response to said transaction request.

More precisely, step (d) comprises, in the case of a normal procedure, the transmission by the targeted transaction module, intended for the management module, of a request to present a confidential code associated with the transaction module, the management module being configured to request and obtain via the interface 14 of the mobile terminal 1 said confidential code (or on an interface of the TPE 2 in the case where the electronic transaction means is a physical electronic card 10), step noted 3. in Figures 2a-2c.

On receipt of the valid PIN (otherwise it returns an error message, and preferably hangs after three errors) the wallet is activated, and it activates the targeted transaction module (step 4. of the figures), so that the latter ultimately issues the transaction authorization in response to said transaction request.

In a first embodiment, the wallet management module transmits the confidential code entered to the targeted transaction module.

Alternatively, the wallet issues an activation command of the targeted transaction module (rather than the code alone) in response, which further improves the security of one step. Any interception of requests and manipulation of the security element 12 becomes impossible.

The activated transaction module can then finish the implementation of the transaction in a conventional manner. Preferably, in the case of payments, the method further comprises a step (d) of transmitting the transaction authorization to a bank server 3 associated with said card electronic (physical or virtualized) via the network 20. Typically, in step 5. shown, the payment authorization is transferred to the TPE 2 so that the latter can report to the server 3 in a step 6. Learning

Preferably, said list of recurring transaction beneficiary identifiers dynamically evolves.

For this, the method advantageously comprises a subsequent step (e) of notification of the authorized transaction to the server 21 so as to update said list of recurring transaction beneficiary identifiers (more precisely historical data representative of previous transactions ). The server 21 can in turn notify the wallet module.

It can thus be expected that the first transaction at a given merchant is always managed vis-à-vis the regulation threshold, then if a certain number and / or amount of transaction is reached for this merchant he joins the list so to facilitate simplified procedures. Note that this may be subject to the authorization of the user. It can for example be notified (via the wallet) that a merchant can join the list of recurring merchants, and therefore a new payment threshold without authentication is offered if he accepts.

The threshold associated with a recurring merchant may change over time, up or down, depending on the transaction history. It can even be expected that it will leave the list if a certain periods without transactions with it elapses.

Note that the server 21 may be in contact with the merchants, they may or may not accept the new payment threshold. Specifically, it can be expected that all interested merchants send their identifier to the server 21, and only those who have done so can be included in the list of recurring merchants. For others, the threshold will remain at the regulation threshold in all cases.

Electronic payment method

According to a second aspect, the invention relates to the electronic transaction means 1, 10 for the implementation of the method according to the first aspect. On this means 1, 10 is stored at least one transaction module adapted to allow a transaction when it is activated (in particular on a security element 12), and comprising a communication unit 13 with a network 20.

Preferably, the means 1, 10 is either a physical electronic card 10 or a mobile terminal 1 also comprising a data processing module 11 (a processor). In the second case, the transaction module is associated with a "virtualized" electronic card, and adapted to authorize a transaction on behalf of this electronic card when it is activated. Its security element 12 is advantageously in the form of a subscriber identification card, but also in the form of an area of the data processing module 11 or an optionally removable external component, etc.

In all cases, the electronic transaction means 1, 10 (and more precisely its security element 12 if it is a mobile terminal 1, although it will be understood that a physical electronic card 10 constitutes an element security by definition) is configured to:

Obtaining (at the level of a risk module, possibly via a wallet module processing transaction history data) from a server 21 of the network 20 via the communication unit 13 a list of identifiers of recipients of recurring transactions;

receiving a transaction request for said transaction module (for example from a TPE 2), the request comprising at least one amount of said transaction and an identifier of the beneficiary of said transaction;

determining (by interrogating the risk module) a procedure for authenticating the user of the electronic payment means 1, among a plurality of procedures according to said amount and identifier of the beneficiary of said transaction received, and said list of identifiers of Recurring Transactions Recipients;

- If said determined authentication procedure is completed (by soliciting an entry of a confidential code if a normal procedure is requested), activate said transaction module, and issue a transaction authorization in response to said transaction request

Computer program product According to a third and a fourth aspect, the invention relates to a computer program product comprising code instructions for execution (in particular on the security element 12 of the terminal 1 or on a physical card 10) of a method according to the first aspect of the invention for implementing a transaction from an electronic transaction means 1, 10 of a user, as well as storage means readable by a computer equipment (a memory of the security 12) on which we find this product computer program.

Claims

A method for implementing a transaction from an electronic transaction means (1, 10) of a user, on which at least one transaction module adapted to authorize a transaction is stored when it is activated, the means electronic transaction system (1, 10) further comprising a communication unit (13) with a network (20);

The method being characterized in that it comprises the implementation by the electronic payment means (1, 10) of steps of:

(a) Obtaining from a server (21) of the network (20) via the communication unit (13) a list of recurring transaction beneficiary identifiers;

(b) Obtaining at least one beneficiary threshold associated with at least one recurring transaction beneficiary identifier of said list

(c) receiving a transaction request for said transaction module, the request comprising at least one amount of said transaction and an identifier of the beneficiary of said transaction;

(d) determining a user authentication procedure of the electronic payment means (1, 10) among a plurality of procedures based on said received amount and beneficiary identifier of said transaction, and said list of identifiers recipients of recurring transactions, said plurality of procedures comprising at least:

at. a normal procedure including verifying an authentication parameter of the user;

b. a simplified procedure that does not include checking a user authentication parameter.

(e) If said identifier received from the beneficiary of the transaction belongs to said list, the authentication procedure of the user of the electronic payment means (1, 10) is determined to be the simplified procedure if the transaction amount received is less than or equal to an associated beneficiary threshold in the list to the received identifier.

(f) If said determined authentication procedure is completed, activating said transaction module, and issuing a transaction authorization in response to said transaction request.

2. Method according to claim 1, wherein the verification of a user authentication parameter comprises the verification of a confidential code entered by the user and / or the verification of a biometric parameter of the user. ,

3. Method according to claim 1, wherein a threshold [of the beneficiary] is obtained as a function of at least one of:

the number of transactions made with said transaction beneficiary;

- the amount associated with transactions with the said transaction beneficiary

4. The method of claim 1, wherein the electronic transaction means is selected from a physical electronic card (10) and a mobile terminal (1) on which said transaction module is associated with an electronic card, and adapted to allow a transaction on behalf of said electronic card when activated.

5. The method of claim 4, wherein the electronic transaction means is a mobile terminal (1) comprising a data processing module (1 1) and a security element (12) on which is stored said transaction module.

The method of claim 5, wherein the security element (12) is either a hardware element selected from a subscriber identification card and a secure execution space of the data processing module (1 1). of the terminal (1), ie a software element emulated by the data processing module (1 1) of the terminal (1) in accordance with the Hosted Card Emulation architecture, HCE.

The method according to one of claims 5 and 6, wherein the security element (12) implements said transaction module and a risk module storing said list of recurring transaction beneficiary identifiers, and the module data processing (1 1) implements a management module of the transaction module or modules, step (b) comprising interrogating the risk module by the targeted transaction module.

The method according to claim 7, wherein step (a) comprises the reception by the management module of historical data representative of previous transactions, the generation of said list of identifiers of recipients of recurring transactions by the module. management from said historical data representative of previous transactions, and the transmission of said list to the risk module.

9. Method according to one of claims 1 to 8, wherein the electronic transaction means (1, 10) is an electronic payment means, the transaction request being received in step (a) from a payment terminal. electronic (2) in wireless communication with the electronic payment means (1, 10), the transaction authorization being issued in step (d) to the electronic payment terminal (2).

10. The method of claim 7, further comprising a step (e) of transmitting the transaction authorization to a bank server (3) associated with a bank card via the network (20).

11. The method of claim 10 in combination with one of claims 7 and 8, wherein step (d) comprises in case of normal procedure the transmission by the target transaction module, to the management module, a request for presentation of a confidential code associated with the transaction module, the management module being configured to request and obtain via an interface (14) of the terminal said confidential code.

The method of claim 1, wherein a default threshold is stored in the electronic transaction means (1, 10), each threshold of said list being greater than the default threshold, the step (c) comprising:

- If said identifier received from the beneficiary of the transaction does not belong to said list, the authentication procedure of the user of the electronic payment means (1, 10) is determined as being the simplified procedure if the transaction amount received is less than or equal to the default threshold.

The method according to one of claims 1 to 12, comprising a step (e) of notifying the authorized transaction to the server (21) so as to update said list of recipients of recurring transactions.

14. Electronic transaction means (1, 10) on which is stored at least one transaction module adapted to authorize a transaction when it is activated, and comprising a communication unit (13) with a network (20),

The electronic transaction means (1, 10) being configured to:

- Obtaining from a server (21) of the network (20) via the communication unit (13) a list of recipients of recurring transactions;

- Obtain at least one beneficiary threshold associated with at least one recurring transaction beneficiary identifier of said list;

determining a method for authenticating the user of the electronic payment means (1, 10) among a plurality of procedures according to said amount and identifier of the beneficiary of said transaction received, and said list of transaction beneficiary identifiers. recurring; said plurality of procedures comprising at least:

b. a simplified procedure that does not include verifying a user authentication parameter;

- If said identifier received from the beneficiary of the transaction belongs to said list, determine the authentication procedure of the user of the electronic payment means (1, 10) as being the simplified procedure if the transaction amount received is less than or equal to at an associated beneficiary threshold in the list to the received identifier;

- If said determined authentication procedure is completed, activate said transaction module, and issue a transaction authorization in response to said transaction request

15. Electronic transaction means (1, 10) according to claim 14, being a mobile terminal (1), the transaction module being associated with an electronic card, and adapted to authorize a transaction on behalf of said electronic card when it is activated.

Computer program product comprising code instructions for executing a method according to one of the claims 1 to 13 for implementing a transaction from an electronic transaction means (1, 10) of a user, when said program is executed by a computer.