FR3090959A1 - Processing an electronic ticket service - Google Patents

Abstract

The invention relates to a processing method implemented by a terminal (T1) for processing a transaction (TR1) with an electronic device (DV1), the method comprising: reception, from the electronic device (DV1), of first data ( DT1) comprising a user identifier (IDUR); transmission, to the electronic device (DV1), of second data (DT2) comprising a terminal identifier (IDT1) identifying the terminal (T1); reception, from the electronic device (DV1), of a cryptogram (MC1) generated from an encryption key (K1) and input data (DM1) comprising the terminal identifier (IDT1) and l 'user identifier (IDUR); and transmission, to a management server (SV1), of an electronic ticket generation request (RQ1) comprising the cryptogram (MC1), the input data (DM1) and transaction data (DTR2) characterizing the transaction (TR1), to require the generation by the management server of an electronic ticket (TK1) representative of the transaction (TR1). Figure for the abstract: Fig. 2.

Description

Description

Title of the invention: Processing of an electronic ticket service

Technical area

The invention is in the field of banking transactions and relates more particularly to the generation and management of electronic tickets representative of banking transactions processed by a terminal in cooperation with an electronic device such as a bank card for example.

Prior art

A bank card is a smart card intended to process bank transactions, such as payment transactions, transfer transactions, or any other appropriate financial transactions. These can be, for example, credit cards or debit cards.

To do this, a bank card comprises at least one banking application (payment application for example, of VISA ™ type or other) executable by an electronic chip integrated in the card. This electronic chip is configured to cooperate with external terminals (or readers), such as payment terminals or automatic teller machines (ATMs), to perform various functions.

A bank card is traditionally designed to cooperate with an external terminal by means of external contacts accessible on the surface of the card. An external terminal can thus position appropriate contact pins on the external contacts of the card in order to establish contact communication with the electronic chip. More recently, contactless bank cards have experienced significant growth due to the gain in speed and simplicity associated with contactless transactions. To do this, contactless cards have a radio frequency antenna for transmitting and receiving RP signals with an external terminal.

EMV (for "Europay Mastercard Visa") is the standardized protocol used today mainly in the world to secure banking transactions carried out by bank cards.

In known manner, it is common during a banking transaction, of the EMV type for example, that a ticket (also called "bill" or "receipt") is produced to indicate to the stakeholders (card user , user of the terminal) transaction data such as the amount, the date or the result of the transaction (successful, failed). This ticket is obtained by printing on a material support, generally in paper.

More and more traders are now using the electronic ticket solution, also called an e-ticket or electronic ticket. It is a dematerialized ticket which replaces the traditional paper ticket with digital information representative of a transaction. During an EMV transaction, for example, the electronic ticket is generated by the payment terminal and then sent by email to the holder of the bank card. This solution is more ecological and reduces the costs associated with the production of traditional tickets, while allowing better management of tickets by the user who no longer needs to store physical tickets.

[0008] However, the use of electronic tickets has certain constraints. To receive an electronic ticket during a payment transaction, for example, the holder of the bank card must generally provide their email address. This operation is slow, can generate seizure risks and is not always desirable for users who are often reluctant to disclose their email address, to a commercial sign for example. In general, users want to protect their digital identity and protect themselves from the risks of commercial spam. In addition, if the card holder does not have a loyalty card with the relevant retailer, he must provide his email address for each transaction, which is tedious, slows the processing of transactions and further increases the risk of error.

The constraints and problems set out above are all the more important since, in the future, more and more traders will be led to use electronic tickets exclusively, thus definitively abandoning the solution of traditional tickets.

Furthermore, the electronic tickets solution is not limited to bank cards but can be used more generally with other means of payment, such as smartphones, tablets or any other electronic device intended to implement an application for interact with an external terminal in order to process a transaction, such as EMV or other. The rise of mobile payment solutions or mPOS for "mobile point of sale" has meant that merchants often no longer have a printer available to produce traditional tickets.

There is therefore a need today for a solution allowing efficient management of electronic tickets, which guarantees the confidentiality of bank card holders while ensuring rapid and reliable processing of transactions.

A need exists in particular for improved management of electronic tickets linked to EMV type transactions.

Statement of the invention

To this end, the present invention relates to a first processing method implemented by a terminal for processing a bank transaction in cooperation with an electronic device, said method comprising:

- reception, from the electronic device, of first data including a user identifier (IDUR) identifying a user associated with the electronic device;

- transmission, to the electronic device, of second data comprising a terminal identifier identifying the terminal;

- reception, from the electronic device, of a cryptogram generated from an encryption key and input data comprising the terminal identifier and the user identifier; and

transmission to a management server of an electronic ticket generation request comprising the cryptogram, the input data and transaction data characterizing the transaction, to require the generation by the management server of an electronic ticket representative of the transaction from the data transmitted by the terminal.

The invention enables efficient management of electronic tickets generated during bank transactions, of the EMV type for example, so as to guarantee the confidentiality of bank card holders while ensuring rapid and reliable processing of transactions.

The electronic device can for example be a smart card or bank card, of the EMV type or other.

According to a particular embodiment, the first data transmitted by the electronic device comprises an address of the management server, the terminal using said address to transmit the request for generating an electronic ticket to said management server.

According to a particular embodiment, the second data, transmitted to the electronic device, further comprises at least one of:

at. a merchant identifier identifying a merchant entity associated with the terminal;

b. location data specifying a position of said market entity; vs. transaction data characterizing the transaction;

wherein each of said data a), b) and c) which is actually transmitted to the electronic device is used as input data by the electronic device to generate the cryptogram.

According to a particular embodiment, the cryptogram is a MAC code.

According to a particular embodiment, in the absence of a positive response to the ticket generation request, the terminal transmits to the electronic device a storage command requesting the storage, in a local memory of the electronic device, of history data including the cryptogram, the input data and the transaction data to allow a transmission of a subsequent request to generate an electronic ticket during a subsequent transaction.

According to a particular embodiment, the first treatment method further comprises:

- reception, from the electronic device, of historical data stored in a local memory of the electronic device and associated with at least one previous transaction; and

- Transmission to the management server, along with the request for generating an electronic ticket, of the historical data so as to further require the generation of at least one additional electronic ticket from the said historical data.

According to a particular embodiment, the historical data comprises, in association with each previous transaction: an earlier cryptogram, earlier input data and earlier transaction data characterizing said at least one previous transaction, said cryptogram having been generated by said electronic device from the encryption key and the associated prior input data.

According to a particular embodiment, the first treatment method further comprises:

- reception of a positive response from the management server to said request to generate an electronic ticket; and

- upon detection of the positive response, transmission to the electronic device of a delete command to order the deletion in the local memory of the electronic device of said historical data.

The invention also relates to a management method implemented by a management server cooperating with a terminal intended to process a bank transaction, said method comprising the following steps:

- reception, from the terminal, of a first cryptogram, of input data, of transaction data characterizing the transaction as well as of an electronic ticket generation request, in which the first cryptogram was generated by a device electronic from the input data which includes a user identifier identifying a user and a terminal identifier identifying the terminal;

- generation of a second cryptogram from a decryption key and input data;

- verification of the validity of the electronic ticket generation request, based on a comparison of the first cryptogram with the second cryptogram; and

- if said request is valid, generation of an electronic ticket representative of the transaction, from at least the input data and the received transaction data.

As already indicated, the electronic device can for example be a smart card or bank card, of the EMV type or the like.

According to a particular embodiment, the electronic ticket comprises at least one of the following data: a. transaction data characterizing the transaction; b. the terminal identifier;

vs. the user ID;

d. a merchant identifier identifying a merchant entity associated with the terminal;

e. location data specifying a position of said market entity; f. a predefined message associated with said market entity; and

g. a PAN type identifier, partial or complete, associated with the electronic device.

According to a particular embodiment, the management server receives the cryptogram, the input data, the transaction data as well as the request for generating an electronic ticket from the terminal via a first communication channel;

the method further comprises:

- sending the electronic ticket to said user via a second communication channel different from the first communication channel.

The invention also relates to a second processing method implemented by a system comprising a terminal and an electronic device cooperating together to process a banking transaction, in which the terminal performs the steps of a first processing method such as defined above, in which the electronic device performs the following steps:

- transmission, to the terminal, of first data comprising a user identifier identifying a user associated with the electronic device;

- reception, from the terminal, of second data comprising a terminal identifier identifying the terminal;

- generation of a cryptogram from an encryption key and input data comprising the terminal identifier and the user identifier; and

- transmission, to the terminal, of the cryptogram and of input data to allow the transmission by the terminal of an electronic ticket generation request to a management server.

According to a particular embodiment, the electronic device also generates the cryptogram from the current value of a counter, the value of said counter being incremented by the electronic device with each new transaction;

wherein the electronic device further transmits, as input data, the current value of the counter to the terminal.

Alternatively, the electronic device generates the cryptogram from a random value which is generated by the electronic device with each new transaction;

wherein the electronic device further transmits, as input data, the random value to the terminal.

According to a particular embodiment, the second treatment method further comprises:

- determination, by the electronic device, of a merchant identifier identifying a merchant entity associated with the terminal; and

- verification, by the electronic device, of whether the merchant identifier corresponds to a predefined merchant;

in which said transmission, by the electronic device, of the cryptogram to the terminal is only carried out if the merchant entity does not correspond to a predefined merchant.

According to a particular embodiment, the second treatment method further comprises:

- determination, by the electronic device, of a merchant identifier identifying a merchant entity associated with the terminal; and

- verification, by the electronic device, of whether the merchant identifier corresponds to a predefined merchant;

- in which said local storage, by the electronic device, of historical data is carried out if the merchant entity does not correspond to a predefined merchant.

According to a particular embodiment, the second method comprises: in response to a storage command received from the terminal, storage in a local memory of the electronic device, of the cryptogram, of input data and of transaction data to allow the transmission, by a terminal, of a subsequent request to generate an electronic ticket during a subsequent transaction.

In a particular embodiment, the different steps of the first processing method, the management method and the second processing method are determined by instructions from computer programs.

Consequently, the invention also relates to a computer program suitable for the implementation of the first processing method, the management method and the second processing method as defined in this document. More specifically, the invention relates to at least one computer program on an information medium, this program being capable of being implemented in an electronic device such as a smart card, in a terminal, in a server. or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of the first processing method, of the management method or of the second processing method as defined in this document.

The invention also relates to recording media (or information media) readable by a computer, and comprising instructions of a computer program corresponding to each of the methods defined above.

Note that the computer programs mentioned in this presentation can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such than in a partially compiled form, or in any other desirable form.

In addition, the recording media mentioned in this document can be any entity or device capable of storing the program. For example, the support may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk or a disc. hard.

On the other hand, the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means. The program according to the invention can in particular be downloaded from a network of the Internet type.

Alternatively, the recording media can correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

The invention also relates to a terminal for implementing the first processing method as defined in this document.

The invention also relates to a management server for implementing the management method as defined in this document.

The invention also relates to a system for implementing the second treatment method as defined in this document. This system thus comprises an electronic device, such as a smart card or bank card for example (of the EMV type or other), cooperating with the terminal of the invention.

Note that the various embodiments mentioned above in relation to the first processing method, the management method and the second method apply respectively analogously to the terminal, to the management server and to the system of the invention.

In the embodiments described in this document, the invention is implemented by means of software and / or hardware components. In this context, unless otherwise indicated, the term "module" may correspond in this document to a software component, a hardware component or a set of hardware and software components.

A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or of software capable of implementing a function or set of functions, as described below for the module concerned.

Similarly, a hardware component corresponds to any element of a hardware assembly (or hardware) capable of implementing a function or a set of functions, as described in this document for the module concerned. It may be a programmable hardware component or with an integrated processor for running software, for example an integrated circuit, a smart card, a memory card, etc.

In general, the terminal, the management server and the system of the invention may each include a respective module configured to perform each operation or step described in this document in relation to the corresponding methods of the invention.

Brief description of the drawings

Other features and advantages of the present invention will emerge from the description given below, with reference to the accompanying drawings which illustrate examples of embodiment devoid of any limiting nature. In the figures:

[Fig.l]

FIG. 1 schematically represents, in the form of a diagram, an example of processing a transaction according to the EMV protocol.

[Fig.2]

FIG. 2 schematically represents an environment comprising a smart card, a terminal and a management server, in accordance with a particular embodiment of the invention.

[Fig.3]

FIG. 3 schematically represents functional modules implemented by a terminal according to a particular embodiment of the invention.

[Fig.4]

FIG. 4 schematically represents functional modules implemented by a management server according to a particular embodiment of the invention.

[Fig.5]

FIG. 5 schematically represents functional modules implemented by a smart card according to a particular embodiment of the invention.

[Fig.6]

FIG. 6 schematically represents, in the form of a diagram, the steps of a treatment method according to a particular embodiment of the invention.

[Fig.7]

FIG. 7 schematically represents, in the form of a diagram, the steps of a treatment method according to a particular embodiment of the invention.

[Fig.8]

FIG. 8 schematically represents, in the form of a diagram, the steps of a treatment method according to a particular embodiment of the invention.

[Fig.9]

FIG. 9 schematically represents, in the form of a diagram, the steps of a treatment method according to a particular embodiment of the invention. Description of the embodiments

The present invention proposes to allow efficient management of electronic tickets generated during bank transactions, of the EMV type for example, so as to guarantee the confidentiality of bank card holders while ensuring rapid and reliable processing of transactions.

To do this, the invention provides a solution using a trusted third party in the form of a management server. According to different embodiments of the invention, during a transaction with an electronic device (such as a smart card for example), a terminal is configured to transmit data to the management server so that the latter can generate reliably and securely an electronic ticket for interested parties. This management server can also perform various operations to manage these electronic tickets.

The invention proposes in particular, according to different embodiments, a processing method implemented by a terminal for processing a bank transaction in cooperation with an electronic device, said method comprising:

- reception, from the electronic device, of first data comprising a user identifier identifying a user associated with the electronic device;

- transmission, to the electronic device, of second data comprising a terminal identifier identifying the terminal;

- reception, from the electronic device, of a cryptogram generated from an encryption key and input data comprising the terminal identifier and the user identifier; and

transmission to a management server of an electronic ticket generation request comprising the cryptogram, the input data and transaction data characterizing the transaction, to require the generation by the management server of an electronic ticket representative of the transaction, from the data transmitted by the terminal.

Correlatively, the invention relates to a management method implemented by a management server cooperating with a terminal intended to process a bank transaction, said method comprising the following steps:

- reception, from the terminal, of a first cryptogram, of input data, of transaction data characterizing the transaction as well as of an electronic ticket generation request,

- in which the first cryptogram was generated by an electronic device from the input data which includes a user identifier identifying a user and a terminal identifier identifying the terminal;

- generation of a second cryptogram from a decryption key and input data;

- verification of the validity of the electronic ticket generation request, based on a comparison of the first cryptogram with the second cryptogram; and

- if said request is valid, generation of an electronic ticket representative of the transaction, from at least the input data and the received transaction data.

In addition, the invention relates in particular to the management server and the terminal corresponding to the methods defined above, as well as a system comprising the terminal and the electronic device and the computer programs corresponding to the methods of invention.

Other aspects and advantages of the present invention will emerge from the embodiment examples described below with reference to the drawings mentioned above.

In this presentation, examples of implementation of the invention are described in the context of an EMV type smart card, configured to process EMV transactions. Note that other embodiments are however possible. In particular, the invention does not apply exclusively to smart cards but can more generally apply to any electronic device configured to process transactions in cooperation with an external terminal, according to the EMV standard or according to any other appropriate protocols. . The invention can be applied in particular to smartphones, tablets or any other electronic device implementing an application for processing a transaction, of the EMV type for example, in cooperation with an external terminal.

The EMV protocol, well known to those skilled in the art, was designed to reduce the risk of fraud during a bank transaction (payment transaction, for example) by allowing in particular the authentication of both the smart card and its holder. The principles of the EMV protocol are recalled below.

FIG. 1 represents an example of implementation of a payment transaction in accordance with the EMV protocol, using an EMV 100 smart card. Certain aspects of an EMV transaction have been omitted for the sake of simplicity.

During a first phase intended to authenticate the smart card 100 used, the terminal 110 and the card 100 exchange a certain number of messages including a RESET message (RST) in S2 then an ATR response in S4 ( in contact mode). The terminal 110 attempts to choose the appropriate application on the smart card 100. To do this, the terminal 110 sends (S5a) to the smart card 100 a SELECT EILE command in order to request from the smart card the applications that this last is able to run. This SELECT EILE command contains as parameter the application identifier (AID for "Application Identifier") of the PSE for "Payment System Environment" (or PPSE for "Proximity Payment System Environment", in contactless mode). In response, the terminal 110 sends in S5b an APPLICATIONS command which contains a list of the various applications that the card is capable of executing. The terminal 110 responds by sending in S6 a SELECT APPLICATION command to select an application in the smart card 100 which will process the EMV transaction. To do this, this SELECT APPLICATION command contains the AID of the selected application.

The terminal 110 then sends in S7 to the smart card 100 a GET PROCESSING OPTIONS (GPO) command which triggers an S8 phase for reading data, called RECORDS, present in memory in the smart card 100. These data are say static in the sense that they do not vary from one transaction to another. To do this, the terminal 100 sends READ RECORD requests to which the smart card 100 responds by providing static data in RECORD responses.

The card 100 and the terminal 110 can then proceed to an optional phase (not shown) of authentication of the card holder, during the confidential PIN code of the card holder is verified. However, if the mode without PIN code verification is selected, no PIN code verification is performed.

The EMV protocol initiates a transaction verification phase during which the terminal 110 sends (S9) to the smart card 100 a first GAC command (for "GENERATE AC") also denoted GAC1. This command GAC1 well known to those skilled in the art includes information on the transaction in progress such as the amount of the transaction, the currency used, the type of transaction, etc. The EMV card 100 performs (S9) a verification of the transaction according to predefined verification criteria then sends (SU), in response to GAC1, a cryptogram.

Various embodiments are possible. It is assumed in this example that the smart card 100 sends in SI 1 an ARQC cryptogram (for (“Authorization Request Cryptogram”) indicating that it wishes to continue the transaction online with the issuer 120 of the card 100. The request or no to continue the online transaction depends on the configuration of the card. The ARQC cryptogram is transmitted (S 12) by the terminal 110 to the transmitter 120 which can thus perform (S13) a certain number of verifications in order to ensure that the transaction is valid The emitter 120 then sends (S 14), in response to the ARCQ message received, an ARPC cryptogram (for “Authorization Response Cryptogram”) indicating the decision of the emitter 120. This ARPC message is transmitted (S 16) by the terminal 110 to the card 100 in a second GAC command, denoted GAC2, well known to those skilled in the art.

Note that the smart card 100 can also process the transaction in offline mode, that is to say without involving the transmitter 120 to verify the transaction.

The card 100 determines whether or not it accepts the transaction from the ARPC response. The card 100 thus sends back to S18 a TC or ACC cryptogram indicating respectively that it accepts or refuses the transaction.

Note also that, in this document, the concept of bank transaction must be understood in the broad sense and includes for example, in the banking field, a payment transaction, a debit transaction, a transfer transaction, or all other financial transactions which may be subject to the management of an electronic ticket in accordance with the invention. In the embodiments described below, the smart card of the invention thus processes payment transactions, although other types of transaction are possible.

Unless otherwise indicated, the elements common or analogous to several figures bear the same reference signs and have identical or analogous characteristics, so that these common elements are generally not described again for the sake of simplicity.

FIG. 2 schematically represents an environment comprising a terminal Tl, a bank card DV1 and a management server SV1, in accordance with a particular embodiment of the invention.

The terminal T1 and the bank card DV1, together forming a system SY1, are configured to cooperate together to process a bank transaction denoted TRI. It is assumed in this example that the TRI transaction is an EMV type payment transaction, however other examples are possible.

More particularly, it is assumed that the user UR uses his bank card DV1 to carry out the TRI payment transaction with a third entity, namely the merchant entity (or trading sign) MD in this example.

In addition to interacting with the bank card DV 1 in accordance with the EMV standard, the terminal Tl also cooperates with the management server SV1, the latter being configured to generate and manage an electronic ticket, denoted TK1, representative of the transaction SORTING.

The terminal T1 comprises a processor 2, a first non-volatile memory MRI, a second non-volatile memory MR2, a first communication interface INT1 and a second communication interface INT2. The terminal Tl here takes the form of a payment terminal although other embodiments are possible.

More specifically, the MRI memory is a non-volatile memory (Elash or ROM for example), this memory constituting a recording medium (or information medium) conforming to a particular embodiment, readable by the terminal Tl , and on which is recorded a computer program PG1 conforming to a particular embodiment. This PG1 computer program includes instructions for the execution of the steps of a processing method according to a particular embodiment which will be described later.

The memory MR2 is a rewritable non-volatile memory (Elash for example) capable of storing data such as a terminal identifier IDT1 which identifies the terminal Tl and, optionally, at least one of a merchant identifier IDMD which identifies the market entity MD and a location data LOC specifying a position of this market entity MD. The use and value of this data will be described in more detail later.

According to a particular example, the memories MRI and MR2 form a single memory.

The first communication interface INT1 allows the terminal Tl to communicate with the management server SV1. To do this, the first communication interface INT1 establishes a communication link L1 with the management server SV1. This L1 link can be wired or wireless, and can be of any suitable nature.

Similarly, the second communication interface INT2 allows the terminal Tl to communicate with the bank card DV1. To do this, the second communication interface INT2 establishes a communication link L2 with the bank card DV1. This L2 link can be a contact link or a contactless link, depending on the means of communication available to the DV1 bank card and the use case.

The links L1 and L2 make it possible to exchange data between the terminal Tl and the management server SV 1 on the one hand, and between the terminal Tl and the smart card DV 1 on the other hand. These data will be described in more detail later.

Furthermore, the bank card DV 1 is in this example an EMV chip card configured to process transactions according to the EMV standard in cooperation with external terminals such as the terminal T1. The bank card DV 1 comprises a processor 4 , an INT5 communication interface, a first memory MR5 and a second memory MR6. These components are included in an electronic chip (not shown) of the DV1 card, or more particularly in a secure element of the DV1 smart card.

The MR5 memory is a non-volatile memory (Flash or ROM for example), this memory constituting a recording medium (or information medium) conforming to a particular embodiment, readable by the bank card DV1, and on which a PG3 computer program conforming to a particular embodiment is recorded. This PG3 computer program includes instructions for the execution of certain steps of a processing method according to a particular embodiment which will be described later.

The memory MR6 is a rewritable non-volatile memory (Flash for example) capable of storing data such as a user identifier IDUR corresponding to the user UR as well as an encryption key (or cryptographic key) Kl . The memory MR6 can optionally store other data such as in particular DH history data or a CTI counter. The use and value of this data will be described later.

In a particular example, the memories MR5 and MR6 form a single memory.

The INT5 communication interface allows the terminal Tl to communicate with terminal Tl, and more particularly with its communication interface INT2. The DV 1 smart card can for example include external contacts (of the ISO 7816 type for example) located on the surface of the card body. In this case, the L2 link is a contact link. The terminal Tl can thus position appropriate contact pins on the external contacts of the card in order to establish communication by contact with the bank card DV1. According to another example, the DV 1 smart card comprises an antenna (not shown). In this case, the bank card DV1 can establish a link L2 without contact with the terminal Tl.

On the other hand, the management server SV1 comprises a processor 10, a first communication interface INT 10, a second communication interface INT 11, a first memory MR 10 and a second memory MR 11.

The memory MR10 is a non-volatile memory (Flash or ROM for example), this memory constituting a recording medium (or information medium) conforming to a particular embodiment, readable by the server SV1, and on which is recorded a PG2 computer program according to an embodiment in particular. This PG2 computer program includes instructions for the execution of the steps of a management method according to a particular embodiment which will be described later.

The MRI 1 memory is a rewritable non-volatile memory (Elash for example) capable of storing data such as an MCI cryptogram generated by the DV1 chip card, DM1 input data used by the DV chip card 1 to generate the cryptogram MCI, transaction data DTR1 representative of the transaction TRI and the encryption key Kl. The use and value of this data will be described later.

In a particular example, the memories MR10 and MRI 1 form a single memory.

The first INT 10 communication interface allows the management server SV 1 to communicate with the terminal Tl. To do this, the first communication interface INT 10 establishes a communication link L1 with the terminal Tl, and more particularly with its INT1 communication interface. As already indicated, this L1 link can be wired or wireless, and can be of any suitable nature.

The second communication interface INTI 1 allows the management server SV 1 to transmit to the user UR an electronic ticket TK1 generated by the management server SV1, this electronic ticket being representative of the transaction TRI. This electronic TRI ticket constitutes a digital ticket (or receipt) containing various information relating to the TRI transaction such as for example the date, the amount, the terminal identifier, the result of the transaction, etc. The transmission of this TK1 ticket can be done via any appropriate L3 links, in particular by sending an email or an SMS.

Furthermore, as shown in Figure 3 according to a particular embodiment, the processor 2 of the terminal Tl controlled by the computer program PG1 here implements a number of modules, namely: a first receiving module MD2, a first transmission module MD4, a second reception module MD6, a second transmission module MD8, and possibly a storage management module MD 10.

More specifically, the first reception module MD2 is configured to receive, from the bank card DV1, first DTI data comprising a user identifier IDUR identifying the user UR associated with the bank card DV1.

The first transmission module MD4 is configured to transmit, to the bank card DV1, second data DT2 comprising at least one terminal identifier IDT1 identifying the terminal Tl. These second data DT2 can include other data as explained later , such as in particular transaction data DTR1 characterizing the transaction TRI.

The second reception module MD6 is configured to receive, from the bank card DV1, an MCI cryptogram generated from an encryption key Kl and from input data DM1 comprising at least the identifier IDT1 of the terminal Tl and the user identifier IDUR. The DM1 input data may include other data, as described later, such as the DTR1 transaction data mentioned above. The second reception module MD6 can also transmit to the bank card DV1 the input data DM1 and other data according to the use case, as described below.

The second transmission module MD8 is configured to transmit, to the management server SV1, a request to generate an electronic ticket RQ1. This request RQ1 comprises at least the cryptogram MCI, the input data DM1 and transaction data DTR2 characterizing the transaction TRI, and aims to trigger the generation by the management server DV1 of an electronic ticket TK1 representative of the transaction TRI , from the data transmitted by the terminal Tl.

If necessary, the storage management module MD 10 makes it possible to manage the storage of history data DH in the memory MR6 of the bank card DV1. To do this, the storage management module MD 10 can send CMD4 or CMD5 commands to the bank card DV 1 as described in more detail later.

Furthermore, as shown in FIG. 4 according to a particular embodiment, the processor 10 of the server SV1 controlled by the computer program PG2 implements here a certain number of modules, namely: a reception module MD20 , a first generation module MD22, a verification module MD24, a second generation module MD26, and possibly a processing module MD28.

More specifically, the reception module MD20 is configured to receive, from the terminal T1, the cryptogram MCI, the input data DM1, the transaction data DTR2 characterizing the transaction TRI as well as the ticket generation request electronic RQ1. As already indicated, the MCI cryptogram is previously generated by the smart card DV1 from input data DM1 which include at least the user identifier IDUR and the terminal identifier IDT1.

The first generation module MD22 is configured to generate a second cryptogram MC2 from a decryption key and from the input data DM1. In this example, the decryption key is identical to the encryption key Kl used by the bank card DV1 to generate the cryptogram MCI.

The verification module MD24 is configured to verify the validity of the request for generating an electronic ticket RQ1, and this from a comparison of the first cryptogram MCI received from the terminal T1 with the second cryptogram MC2 generated by the first module generation MD22.

The second generation module MD28 is configured to generate, if the request RQ1 is valid, an electronic ticket TK1 representative of the transaction TRI, from at least the input data DM1 and / or the transaction data DTR2 received .

If necessary, the processing module MD28 is configured to carry out additional processing such as transmitting the electronic ticket TK1 to the user UR and / or to the merchant entity MD, as described below.

Furthermore, as shown in Figure 5 according to a particular embodiment, the processor 4 of the bank card DV 1 controlled by the computer program PG3 here implements a number of modules, namely: a first MD40 transmission module, MD42 reception module, MD44 generation module, second MD46 transmission module and MD48 storage module.

More specifically, the first transmission module MD40 is configured to transmit, to the terminal T1, the first DTI data comprising at least the user identifier IDUR identifying the user UR associated with the bank card DV1.

The MD42 reception module is configured to receive, from the terminal Tl, the second data DT2 comprising at least the terminal identifier IDT1 identifying the terminal Tl. As described in more detail later, the second data may include d other data such as the DTR1 transaction data already mentioned above.

The MD44 generation module is configured to generate the MCI cryptogram from the encryption key K1 and the input data DM1 comprising the terminal identifier IDT1 and the user identifier IDUR (as already indicated) .

The second transmission module MD46 is configured to transmit, to the terminal Tl, the cryptogram MCI and the input data DM1 to allow the transmission by the terminal Tl of the request for generating an electronic ticket RQ1 to the management server SV1 .

If necessary, the storage module MD48 is configured to manage the storage, locally in the memory MR6 of the bank card DV1, of the MCI cryptogram or of DH history data, as explained below.

The configuration and operation of the modules MD2-MD10 of the terminal Tl (FIG. 2), of the modules MD20-MD28 of the management server SV1 (FIG. 3) and of the modules MD40-MD48 of the bank card DV 1 (FIG. 4) ) will appear more precisely in the exemplary embodiments described below. It is understood that these modules represent only an example of non-limiting implementation of the invention.

As a variant, two modules of the terminal Tl, of the management server SV 1 or of the bank card DV1 can be implemented within a single module, depending on the configuration chosen. Thus, the first and second reception modules MD2, MD8 can form one and the same module of the terminal T1, the user identifier IDUR can for example be transmitted only in the input data DM1. The same goes for the first and second transmission modules MD40, MD46 of the bank card DV1, for example.

In general, the terminal T1, the server SV 1 and the bank card DV1 each implement a respective module to carry out each operation or step of a corresponding process of the invention.

A particular embodiment of the invention is now described with reference to FIG. 6. More precisely, the terminal T1 and the bank card DV1 each implement a processing method of the invention by executing the instructions computer programs PG1 and PG3, respectively. Likewise, the management server SV 1 implements a management method by executing the instructions of the computer program PG2.

It is assumed that an EMV transaction denoted TRI is initiated between the external terminal T1 and the bank card CD1. This TRI transaction calls for cooperation between terminal T1 and the bank CD1, which together exchange orders or messages in accordance with the EMV standard, as already described in a particular example in FIG. 1.

As already indicated, the TRI transaction is an EMV payment transaction in this example. More particularly, it is assumed that the user UR uses his bank card EMV DV 1 to carry out the TRI payment transaction with the shopping brand MD. To do this, the user UR inserts his bank card DV1 into the terminal Tl (contact transaction) or presents his bank card DV1 near the terminal (contactless transaction).

In a transmission step C4, the bank card C4 sends to the terminal T1 a command CMD1 comprising DX1 data indicating that the bank card DV 1 supports an electronic ticket service. Various ways of providing this DX1 data are possible. According to a first example, the command CMD1 is a response from the bank card DV 1 to a SELECT APPLICATION command sent beforehand by the terminal T1 in accordance with the EMV standard as already described with reference to step S6 of FIG. 1.

In a second example, the DX1 data can be transmitted in the CMD1 command in the form of at least one REU bit (for "Reserved for Future Use"), provided that such a REU bit is provided by the EMV standard for the CMD1 command in question.

In a third example, the data DX1 is transmitted in a SELECT command which is sent by the bank card DV 1 to the terminal T1 in response to a SELECT command, as already described with reference to step S5b in FIG. 1 In accordance with the EMV standard, the SELECT command is a response structured according to the TLV format (for “Tag-Length-Value”) and therefore which accepts to be extended with additional data objects (called “data objects” in English) . According to this third example, the SELECT command thus includes such an additional object of type TLV which includes the data DX1. This additional object has a tag (which uniquely identifies the object), a length and a value.

According to a fourth example, this DX1 data can be transmitted by the bank card DV 1 following the GET PROCESSING OPTIONS (GPO) command sent by the terminal T1, for example in RECORD data read by the terminal T1 in the card bank DV1 during a reading phase S8 of RECORDS already described with reference to FIG. 1.

The terminal T1 receives the command CMD1 during a reception step B4. The terminal T1 thus determines, from the data DX1, that the bank card DV1 supports an electronic ticket service and deduces therefrom that the process of the invention can be continued as explained below.

In the example considered here, during this reading phase S8, the terminal T1 sends (B6) thus a request RC1 that the bank card DV1 receives during a reception step C6. In response to this request RC1, the bank card DV1 transmits (C8) to the terminal T1, as RECORDS, the first data DTI comprising at least one user identifier IDUR identifier T user UR associated with the bank card DV1. This first DTI data may possibly include other data such as an ADI address, corresponding to the server SV1, the use of which will be described later.

In a particular example, the user identifier IDUR is different from a PAN type identifier (for "Primary Account Number") associated with the bank card DV1. Advantageously, this makes it possible to limit the diffusion of the PAN which constitutes sensitive data.

The terminal T1 receives the first DTI data at B8. The process continues with an optional phase S20 of authentication of the user UR. During this phase S20, the terminal T1 and the bank card DV1 cooperate for example together to verify the personal code, said PIN code, of the holder UR of the bank card DV1. As already described with reference to FIG. 1, other embodiments are however possible in which the PIN code is not verified, in particular during a contactless payment transaction.

Still with reference to FIG. 6, the processing of the TRI transaction continues with a verification phase of the transaction, during which the terminal Tl performs (B 12) a risk analysis (known as “Terminal Risk Management”). ”), In accordance with the EMV protocol.

After this analysis B12, the terminal Tl transmits (B 14) to the bank card DV 1 second data DT2 comprising at least one terminal identifier IDT1 identifying the terminal Tl. This second data DT2 may possibly include other data , such as an identifier IDMD identifying the market entity MD and / or location data LOC specifying a position of this market entity MD. This LOC data indicates for example the geographic position of the shopping sign MD where the terminal Tl is located.

These second data DT2 can for example be sent by the terminal T1 in the command GAC1 or in the command GAC2, these commands being both provided for in the EMV protocol as already described with reference to steps S9 and S16 in the figure respectively 1.

The bank card DV1 receives the second data DT2 at C14 (FIG. 6) then proceeds to a generation step C16 during which it generates an MCI cryptogram from an encryption key K1 and input data DM1 comprising at least the terminal identifier IDT1 and the user identifier IDUR. In the example considered here, the cryptogram is a MAC code (for "Message Authentication Code"). As described below, the purpose of this MCI code is to secure the electronic ticket service.

The input data DM1 taken into account by the bank card DV 1 to generate the MCI cryptogram may include additional data, in particular other data also provided by the terminal T1 in the second data DT2.

In the case where the terminal T1 transmits in B14, in the second data DT2, the merchant identifier IDMD and possibly the location data LOC (already mentioned) which specifies a position of the merchant entity MD, then the bank card DV1 can take into account, as input data DM1, the merchant identifier IDMD and possibly the location data LOC in the generation C16 of the cryptogram MCI.

In a particular example, the second data DT2 transmitted in B14 by the terminal T1 also includes transaction data DTR1 representative of the transaction TRI in progress. In this case, this transaction data DTR1 can also be included in the input data DM1 used by the bank card DV 1 to generate the cryptogram MCI. This DTR1 data can for example include at least one of: the date and / or time of the TRI transaction, the amount of the TRI transaction and the currency used.

According to a particular example, each of the IDMD, LOC and DTR1 data which are effectively transmitted to the bank card DV 1 in the second data DT2 are used as input data DM1 by the bank card DV1 to generate the cryptogram MCI in Cl6. Taking this additional data into account makes it possible to further secure the process of the invention.

According to a particular example, each of the data transmitted by the terminal Tl in the second data DT2 in B14 may have been requested beforehand by the bank card DV1, during the reading phase S8, in a CDOL list (for “ Card Risk Management Data Object List ”) in accordance with the EMV protocol. Thus, the bank card DV 1 can request in the list CDOL transmitted as RECORD in S8 that the terminal Tl transmit to it the terminal identifier IDT1, and possibly at least one of the additional data mentioned above (IDMD, LOC and DTR1). The sending of the second data DT2 (B 14) by the terminal Tl is then done in response to this prior request from the bank card DV1.

In a particular example, the bank card DV 1 also takes into account, as CTI input data, the current value of a CTI counter which is incremented by the bank card DV1 with each new transaction. As already indicated, this counter CTI is stored locally in the memory MR6 (FIG. 2) of the bank card DV1. The use of such a CTI counter makes it possible to ensure that the value of the cryptogram generated in C16 (FIG. 6) varies with each transaction, thus further improving the security of the process of the invention.

According to an alternative embodiment, CTI is a random value which is generated by the bank card DV 1 at each new transaction. As indicated above, the use of such a random value makes it possible to ensure that the value of the cryptogram generated in C16 (FIG. 6) varies with each transaction, thus further improving the security of the process of the invention.

The bank card DV1 then transmits (Cl8) to the terminal T1 a command CMD2 comprising the cryptogram MCI as well as the input data DM1 to allow the terminal T1 to subsequently transmit a request for generating an electronic ticket to the server of SV1 management, as explained below.

In a particular example, this command CMD2 is sent by the bank card DV1 in response to the command GAC1 or to the command GAC2 which have already been described previously with reference respectively to steps S9 and S16 of FIG. 1. This command CMD2 can be sent at the TC or AAC response stage already described above with reference to step S18 in FIG. 1.

In a particular example, the bank card DV 1 also generates an electronic signature to validate the TRI transaction in progress. In this case, this electronic signature is also transmitted (Cl8) to the terminal T1 in the command CMD2. This electronic signature can be generated by the bank card DV 1 from an encryption key other than Kl.

As already mentioned, the bank card DV1 can also contain in its local memory MR6 historical data DH, denoted here DHO, associated with at least one previous TRO transaction processed by said card DV1. This DHO history data is for example stored locally in the bank card DV1 (in MR6) when it is not possible to trigger the generation of a corresponding electronic ticket, as explained later. This DHO history data can comprise, in association with at least one previous TRO transaction, an earlier MCO cryptogram, earlier MDO data and earlier DTRO transaction data characterizing said earlier TRO transaction, the earlier MCO cryptogram having been generated by the bank card DV 1 from the encryption key K1 and from the previous input data DM0 (in an identical manner to what is described above with reference to step Cl6).

According to a particular example, the bank card DV 1 also transmits in C18 the DHO history data to the terminal Tl (in the command CMD2 for example) in order to require the generation of an electronic ticket of at least one transaction anterior TRO.

Still with reference to FIG. 6, the terminal Tl receives the command CMD2 at B18 then transmits to the management server SV 1 a request for generating an electronic ticket RQ1 comprising at least the cryptogram MCI, the input data DM1 and transaction data DTR2 characterizing the transaction TRI, to require the generation by the management server SV1 of an electronic ticket representative of the transaction from the data transmitted by the terminal T1.

The DTR2 transaction data can include all or part of the DTR1 transaction data. In a particular example, the transaction data DTR1 and DTR2 are identical. The nature and number of the transaction data TR2 (date / time, amount, currency, etc.) that the terminal T2 chooses to provide to the server SV 1 can be adapted as appropriate.

In the particular case where the bank card DV 1 has previously transmitted, to the terminal Tl, in the first DTI data (step C8, FIG. 6) an address ADI corresponding to the management server SV1, the terminal Tl can use this address ADI to send the request RQ1 to the management server SV1. This ADI address can be a URL address or any other information allowing the terminal Tl to connect with the server SV1.

According to a particular example, the terminal Tl included in its request for generating an electronic ticket RQ1 a message MSG1 that the management server SV1 must take into account to generate an electronic ticket. It is thus possible to personalize the electronic ticket according to the shopping brand MD associated with the terminal TL

In the particular case where the terminal Tl also received in B18 (FIG. 6) the historical data DHO stored locally in the bank card DV1, it can also transmit in B20, to the management server DV1, in support of the request RQ1, the DHO history data to further require the generation of at least one additional electronic ticket from this DHO history data. It is thus possible to obtain one or more electronic tickets relating to at least one previous TRO transaction in the event that it was not possible to obtain them earlier, for example during an offline processing of a transaction. EMV or due to a problem with the connection of terminals that processed previous transactions with a management server.

In the particular case where the terminal Tl receives in B18 (FIG. 6) an electronic signature generated by the bank card DV1, it is also transmitted in B20 to the management server DV1 with the request RQ1. This electronic signature allows the management server DV to subsequently verify that the TRI transaction is valid, as explained below.

In the example considered in FIG. 6, the request RQ1 transmitted by the terminal Tl at B20 thus comprises a concatenation of the cryptogram MCI, input data DM1, transaction data DTR2 and possibly at least the one of the additional data mentioned above (MSG1, DHO, SGI).

The management server SV1 receives the request RQ1 and all the data associated with A20 (FIG. 6).

During a generation step A22, the server SV1 generates a second cryptogram MC2 from the decryption key Kl (identical in this example to the encryption key used in C16 by the bank card DV1) and at from the DM1 input data received at A20 (Figure 6). To do this, it proceeds in the same way as the bank card DV1 to generate the MCI cryptogram in Cl6. In the example considered here, the MC2 cryptogram is therefore a MAC code.

The management server SV1 then checks (A24) the validity of the request for generating an electronic ticket RQ1, from a comparison of the first cryptogram MCI received in A20 with the second cryptogram MC2 calculated in A22. With this cryptogram verification, it is possible to secure the electronic ticket management process as long as an electronic ticket request is only accepted if the MCI cryptogram is valid.

If the MCI and MC2 cryptograms coincide (MCI = MC2), then the process continues at step A28 of generation. Otherwise, the management server DV1 blocks the generation of an electronic ticket and transmits (A26) possibly a negative message MSG2 indicating that the request RQ1 is refused.

During the generation step A28, the management server SV1 then generates an electronic ticket TK1 representative of the transaction TRI, and this at least from the input data DM1 and transaction data DTR2 received. This electronic ticket TK1, also called e-ticket or electronic ticket, constitutes a dematerialized ticket which replaces a traditional ticket with digital information representative of the TRI transaction.

The format of the TK1 electronic ticket and the nature of the information it contains may vary depending on the case. The electronic ticket TK1 includes, for example, text type data and / or image type data. The TK1 electronic ticket can take the form of a file for example.

[0157] According to a particular example, the electronic ticket TK1 comprises at least one of the following data:

- DTR2 transaction data characterizing the TRI transaction;

- the terminal identifier IDT1 associated with the terminal Tl;

- the user identifier IDUR associated with the user UR;

- the merchant identifier IDMD associated with the retail brand MD;

- LOC location data specifying a position of the merchant entity

MD;

- the predefined message MSG1 associated with the retail brand MD; and - a PAN or partial type identifier, associated with the DV1 bank card.

The DTR2 transaction data can include at least one of: the date and / or time of the TRI transaction, the amount of the TRI transaction, the currency used, and the result of the transaction (successful or failed) . The management server DV1 can possibly check the validity of the electronic signature SGI generated by the bank card (when such a signature is actually generated and transmitted to the management server SV1) and deduce from this verification the result of the TRI transaction.

In the particular case where the management server SV has received the historical data DHO relating to at least one previous transaction TRO (as already indicated), it can also generate an electronic ticket TKO for each previous transaction TRO specified in this DHO history data. This allows the UR user to obtain an electronic ticket for previous transactions processed in offline mode for example, and therefore where connection with a server in charge of managing electronic tickets was not possible.

Subsequently, the management server SV1 can carry out all appropriate management operations in relation to the electronic ticket TK1 thus generated (and, where appropriate, with the electronic ticket (s) TKO of the previous transactions).

According to a particular example, the management server SV1 sends (A30) thereafter the electronic ticket TK1 to the user UR via the communication link L3 (FIG. 2

). The server SV1 for example sends the electronic ticket TK1 via an email or an SMS. In the same way, the server SV1 can also transmit to the user UR the one or more additional electronic tickets that it has generated, if necessary, in connection with at least one previous transaction TRO. The management server SV 1 determines to which address AD2 the electronic ticket (s) should be sent from the user identifier IDUR. This AD2 address can be for example an email address or a telephone number. The management server SV1 can thus store in its memory a table associating for a plurality of users an associated address to which the electronic tickets must be transmitted.

According to a particular example, the management server SV 1 receives at A20 (FIG. 6), from the terminal T1, the request for generating an electronic ticket RQ1, the cryptogram MCI, the input data DM1, the data DTR2 transaction and all other possible associated data via a first communication channel (L1). The transmission A30 of the electronic ticket TK as indicated above can then be carried out via a second communication channel different from the first communication channel. For example, the server SV 1 communicates (A20) with the terminal Tl via a telecommunications network, and sends (A30) the electronic ticket TK1 via an SMS, an email or the like.

Alternatively or cumulatively, the management server SV1 can also send the electronic ticket TK1 to the trading entity MD in a similar manner to the sending step A30. To do this, the server SV1 can send the electronic ticket TK1 to the terminal Tl (via the connection L1 for example).

In a particular example, the management server SV1 transmits (A32) to the terminal T1 a positive message MSG3 indicating that the request for generating an electronic ticket RQ1 is accepted. The terminal T1 receives this positive response MSG3 in B32.

In a particular example, on receipt of the positive response MSG3 from the management server SV1 to the request RQ1, the terminal Tl sends (B34) further to the bank card DV 1 a deletion command CMD4 to order the deletion in the local memory MR6 of the bank card DV 1 of the DHO history data. The terminal T1 can optionally trigger the sending B34 of the delete command CMD4 if the positive message MSG3 includes information indicating that the history data DHO has been successfully taken over by the management server DV1.

The DV 1 bank card receives the CMD4 delete command during a step

C34 reception. Upon detection of this CMD4 command, the bank card DV 1 deletes the DHO history data from its local memory MR6.

The invention allows efficient management of electronic tickets generated during bank transactions, of the EMV type for example, so as to guarantee the confidentiality of the holders of bank cards while ensuring fast and reliable processing of the transactions.

This solution is ecological and reduces the costs associated with the production of traditional tickets, while allowing better management of tickets by the user who no longer needs to store physical tickets.

More particularly, the management server of the invention, acting as a trusted third party, is capable of handling an electronic ticket generation request provided by a cooperating terminal during a transaction with a bank card. (or more generally with an electronic device). The management server can check the validity of the request and determine from a user ID received from the terminal, to which address the generated electronic ticket (s) should be sent. It is thus possible to avoid data entry errors, to speed up the processing of transactions, while guaranteeing the security of the process as well as the confidentiality of consumers vis-à-vis retailers.

Furthermore, in the embodiment described with reference to FIG. 6, the terminal T1 is capable of triggering the generation of an electronic ticket insofar as a connection (connection L1, FIG. 1) can be established between the terminal T1 and the management server SV1. On the other hand, it can be envisaged that in certain cases the terminal Tl will not be able to communicate with the management server SV1, for example in the case of a transaction in offline mode or due to an access problem. to the communication network or a breakdown of the management server SV1.

Furthermore, the management server SV 1 can decide to refuse to process the request for generating an electronic ticket TK1 for various reasons (technical problem, insufficient resources, etc.).

We now describe with reference to FIG. 7 a particular embodiment of the invention in which the request for generating an electronic ticket RQ1 (FIG. 6) transmitted by the terminal T1 is not successfully processed by the management server SV1.

Following the sending B20 (FIG. 6) of the request RQ1, the terminal checks (B40) if it detects the reception from the management server SV1 of a positive response. As indicated above, the request for generating an electronic ticket RQ1 may not be processed successfully by the management server SV 1 for various reasons.

In the absence of a positive response MSG3 to the ticket generation request (ie in the absence of response from the management server SV1 or of a negative response MSG2), for example within a predefined period, the terminal Tl transmits (B42) to the bank card DV 1 a storage command CMD5 requiring the storage, in a local memory of said card (ie MR6 in this example), of historical data denoted DH1 to allow transmission of a subsequent request to generate an electronic ticket during a subsequent transaction. This subsequent request may involve the terminal T1 and / or the management server SV 1 or any other terminal and management server provided for this purpose. To this end, the history data DH1, associated with the transaction TRI, includes at least the cryptogram MCI, the input data DM1, the transaction data DTR2, and any other relevant information.

The bank card DV1 receives this storage command CMD5 during a reception step C42. The bank card DV1 then proceeds to the recording (C44) locally in its memory MR6 of the historical data DH1 associated with the transaction TRI.

The DV1 bank card can thus locally store the historical data necessary for the subsequent generation of an electronic ticket. The generation of this eticket is thus deferred until a subsequent request for an electronic ticket is accepted and processed by a management server during a subsequent transaction. This variant makes it possible not to lose the data making it possible to create an electronic ticket when a problem prevents immediately obtaining such an electronic ticket from the management server concerned.

According to a particular example, the bank card DV 1 checks whether it has sufficient memory space (in its memory MR6) before the recording step C44. It thus does this C44 recording only if it has sufficient memory space.

We now describe with reference to FIG. 8 a particular embodiment of the invention in which the bank card DV1 blocks in certain cases the transmission of the MCI cryptogram allowing the terminal T1 to ask the management server SV1 for creation an electronic ticket.

More specifically, as already described with reference to FIG. 6, it is assumed that the bank card DV1 receives in C14 in particular the merchant identifier IDMD in the second data DT2 transmitted by the terminal TL

After determining (C14) the merchant identifier IDMD associated with the merchant entity MD, the bank card DV 1 checks (C50) if this identifier corresponds to a predefined merchant. To do this, the bank card DV 1 compares for example the merchant identifier IDMD with a list of at least one predefined merchant identifier. If the merchant identifier IDMD received corresponds to a predefined merchant, the process continues at blocking step C52. Otherwise, the process continues with steps C16 then C18, as already described above with reference to FIG. 6.

In step C52 (FIG. 8), the bank card DV1 blocks the generation (C16) of the MCI cryptogram. Consequently, the DV1 bank card does not transmit in

C18 the cryptogram MCI and the data associated with the terminal Tl as described above with reference to FIG. 6. On the other hand, the bank card DV 1 can send to the terminal Tl an indication of refusal of electronic ticket.

In other words, the bank card DV 1 checks (C50) if the merchant identifier IDMD corresponds to a predefined merchant and transmits in Cl8 (FIG. 6) the cryptogram MCI to the terminal Tl only if the merchant entity MD does does not correspond to a predefined merchant.

It is thus possible to implement a masking mechanism to avoid the generation of an electronic ticket when this service is not desired by the UR user for security or confidentiality reasons linked to the MD merchant.

We now describe with reference to FIG. 9 a particular embodiment of the invention in which the bank card DV1 blocks in certain cases the storage in its local memory of data aiming to generate an electronic ticket at a later date.

More precisely, as already described with reference to FIG. 6, it is assumed that the bank card DV1 receives in C14 in particular the merchant identifier IDMD in the second data DT2 transmitted by the terminal Tl.

After determining (C14) the merchant identifier IDMD associated with the merchant entity MD, it is also assumed that the bank card DV 1 receives a storage CMD5 command as already described above with reference to FIG. 7 .

[0187] During a step C60, the bank card DV1 checks whether the merchant identifier IDMD received corresponds to a predefined merchant. To do this, the bank card DV 1 compares for example the merchant identifier IDMD with a list of at least one predefined merchant identifier. If the merchant identifier IDMD received corresponds to a predefined merchant, the process continues at blocking step C62. Otherwise, the process continues at step C44 during which the bank card DV1 locally stores the history data DH1, as already described above with reference to FIG. 7.

[0188] In step C62 (FIG. 9), the bank card DV1 blocks the recording in its local memory MR6 of the historical data DH1. The bank card DV 1 can send to the terminal Tl an indication of refusal to store historical data DHL

In other words, the bank card DV 1 checks (C60) if the merchant identifier IDMD corresponds to a predefined merchant and does not store in C44 (FIG. 7) the historical data DH1 in its local memory MR6 that if the trading entity MD does not correspond to a predefined merchant.

It is thus possible to implement a masking mechanism to avoid the storage locally in the bank card DV1 of historical data allowing the subsequent generation of an electronic ticket associated with the transaction concerned. Such blocking is for example carried out when the e-ticket service is not desired by the user UR for reasons of security or confidentiality linked to the merchant MD.

A person skilled in the art will understand that the embodiments and variants described above are only non-limiting examples of implementation of the invention. In particular, a person skilled in the art can envisage any adaptation or combination of the embodiments and variants described above in order to meet a very specific need.

Claims (1)

Claims [Claim 1] Processing method implemented by a terminal (Tl) for processing a bank transaction (TRI) in cooperation with an electronic device (DV1), said method comprising: - reception, from the electronic device, of first data (DTI) comprising a user identifier (IDUR) identifying a user associated with the electronic device; - transmission of second data to the electronic device (DT2) comprising a terminal identifier (IDT1) identifying the terminal (Tl); - reception, from the electronic device, of a encryption- togram (MCI) generated from an encryption key (Kl) and input data (DM1) comprising the terminal identifier (IDT1) and the user identifier (IDUR); and - transmission to a management server (SV1) of a request for electronic ticket generation (RQ1) comprising the cryptogram, the input data and transaction data (DTR2) characterizing the transaction (TRI), to require the generation by the management server of an electronic ticket representative of the transaction to from the data transmitted by the terminal. [Claim 2] Method according to claim 1, in which the first data (DTI) transmitted by the electronic device (Tl) comprises an address (ADI) of the management server, the terminal using said address to transmit the request for generating an electronic ticket (RQ1) audit management server. [Claim 3] Method according to claim 1 or 2, in which the second data, transmitted to the electronic device, further comprises at least one of: a) a merchant identifier (IDMD) identifying a merchant entity (MD) associated with the terminal; b) location data (LOC) specifying a position of said trading entity (MD); c) transaction data (DTR1) characterizing the transaction; wherein each of said data a), b) and c) which is actually transmitted to the electronic device is used as input data by the electronic device to generate the cryptogram (MCI). [Claim 4] The method of any of claims 1 to 3, wherein the cryptogram is a MAC code. [Claim 5] Method according to any one of Claims 1 to 4, in which in the absence of a positive response to the ticket generation request, the terminal transmits to the electronic device a storage command requesting storage, in a local memory ( MR6) of the electronic device, historical data (DH1) comprising the cryptogram (MCI), the input data (DM1) and the transaction data (DTR1) to allow transmission of a subsequent ticket generation request electronic during a subsequent transaction. [Claim 6] The method according to any of claims 1 to 5, wherein the method further comprises: - reception, from the electronic device, of history data (DHO) stored in a local memory (MR6) of the electronic device and associated with at least one previous transaction; and - transmission to the management server, accompanying the request for electronic ticket generation, historical data to further require the generation of at least one additional electronic ticket from said historical data. [Claim 7] The method of claim 6, wherein the history data (DHO) comprises, in association with each previous transaction: an earlier cryptogram (MCO), earlier input data (DM0) and earlier transaction data (DTRO) characterizing said at least one previous transaction, said previous cryptogram having been generated by said electronic device from the encryption key and from the associated earlier input data. [Claim 8] The method according to claim 6 or 7, the method further comprising: - reception of a positive response (MSG2) from the server management of said electronic ticket generation request; and - upon detection of the positive response, transmission to the electronic device of a delete command (CMD4) to control the deletion in the local memory of the electronic device of said historical data (DHO). [Claim 9] Management method implemented by a management server (SV1) cooperating with a terminal (DV1) intended to process a bank transaction (TRI), said method comprising the following steps: reception, from the terminal, of '' a first cryptogram (MCI), of input data (DM1), of transaction data (DTR2) characterizing the transaction (TRI) as well as of an electronic ticket generation request (RQ1), in which the first cryptogram (MCI) was generated by an electronic device (DV1) from input data which includes a user identifier (IDUR) identifying a user and a terminal identifier (IDT1) identifying the terminal; - generation of a second cryptogram (MC2) from a decryption key (Kl) and input data (DM1); - verification of the validity of the electronic ticket generation request (RQ1), from a comparison of the first cryptogram (MCI) with the second cryptogram (MC2); and - if said request is valid, generation of an electronic ticket (TK1) representative of the transaction, from at least the input data (DM1) and the transaction data (DTR1) received. [Claim 10] Method according to claim 9, in which the electronic ticket comprises at least one of the following data: a) the transaction data (DTR2) characterizing the transaction (TRI); b) the terminal identifier (IDT1); c) the user identifier (IDUR); d) a merchant identifier (IDMD) identifying a merchant entity (MD) associated with the terminal; e) location data (LOC) specifying a position of said [Claim 11] [Claim 12] [Claim 13] market entity (MD); f) a predefined message associated with said market entity; and g) a PAN type identifier, partial or complete, associated with the electronic device. Method according to claim 9 or 10, in which the management server receives the cryptogram (MCI), the input data (DM1), the transaction data (DTR1) as well as the request for generating an electronic ticket (RQ1) in from the terminal (Tl) via a first communication channel; the method further comprises: - sending the electronic ticket to said user via a second communication channel different from the first communication channel. Processing method implemented by a system (SI) comprising a terminal (Tl) and an electronic device (DV1) cooperating together to process a banking transaction (TRI), in which the terminal performs the steps of a method according to the any one of claims 1 to 8, in which the electronic device (DV1) performs the following steps: - transmission, to the terminal, of first data comprising a user identifier (IDUR) identifying a user associated with the electronic device; - reception, from the terminal, of second data (DT2) comprising a terminal identifier (IDT1) identifying the terminal; - generation of a cryptogram (MCI) from an encryption key (Kl) and input data (DM1) comprising the terminal identifier and the user identifier; and - transmission, to the terminal, of the cryptogram (MCI) and of the input data (DM1) to allow the transmission by the terminal of an electronic ticket generation request to a management server. The method of claim 12, wherein the electronic device further generates the cryptogram (MCI) from the current value of a counter (CTI), the value of said counter being incremented by the electronic device with each new transaction; wherein the electronic device further transmits, as input data (DM1), the current value of the counter to the terminal. [Claim 14] The method according to claim 12 or 13, wherein the method further comprises: - determination, by the electronic device, of a merchant identifier (IDMD) identifying a merchant entity (MD) associated with the terminal; and - verification, by the electronic device, of whether the merchant identifier corresponds to a predefined merchant; in which said transmission, by the electronic device, of the cryptogram to the terminal is only carried out if the merchant entity does not correspond to a predefined merchant. [Claim 15] Method according to any one of Claims 12 to 14, in which the method comprises: in response to a storage command (CMD5) received from the terminal (Tl), storage in a local memory (MR6) of the electronic device, cryptogram (MCI), input data (MD1) and transaction data (DT2) to allow the transmission, by a terminal, of a subsequent request for generation of electronic ticket during a subsequent transaction .