WO2020128240A1 - Traitement d'un service de tickets electroniques - Google Patents

Traitement d'un service de tickets electroniques Download PDF

Info

Publication number
WO2020128240A1
WO2020128240A1 PCT/FR2019/053032 FR2019053032W WO2020128240A1 WO 2020128240 A1 WO2020128240 A1 WO 2020128240A1 FR 2019053032 W FR2019053032 W FR 2019053032W WO 2020128240 A1 WO2020128240 A1 WO 2020128240A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
data
transaction
electronic device
cryptogram
Prior art date
Application number
PCT/FR2019/053032
Other languages
English (en)
Inventor
Rozenn Trubert
Marco DE OLIVEIRA
Original Assignee
Idemia France
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idemia France filed Critical Idemia France
Publication of WO2020128240A1 publication Critical patent/WO2020128240A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/047—Payment circuits using payment protocols involving electronic receipts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3574—Multiple applications on card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card

Definitions

  • 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.
  • 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.
  • a bank card comprises at least one banking application (payment application for example, of VISA TM 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 card's external contacts in order to establish contact communication with the electronic chip.
  • contactless bank cards have experienced significant growth due to the gain in speed and simplicity associated with contactless transactions. To do this, contactless cards carry a radio frequency antenna allowing the transmission and reception of RF signals with an external terminal.
  • EMV Europay, MasterCard Visa
  • EMV Europay, MasterCard Visa
  • a ticket also called “bill” or “receipt”
  • This ticket is obtained by printing on a material support, generally in paper.
  • an e-ticket 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.
  • 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 linked to the production of traditional tickets, while allowing better management of tickets by the user who no longer needs to store physical tickets.
  • 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.
  • the electronic ticket 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.
  • 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:
  • 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 bank card holders while ensuring rapid and reliable processing of transactions.
  • the electronic device can be for example a smart card or bank card, of the EMV type or other.
  • 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 electronic tickets to said management server.
  • the second data, transmitted to the electronic device further comprises at least one of:
  • the cryptogram is a MAC code.
  • 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.
  • 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
  • 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.
  • the first treatment method further comprises:
  • the invention also relates to a management method implemented by a
  • 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;
  • the electronic device can be for example a smart card or bank card, of the EMV type or other.
  • the electronic ticket comprises at least one of the following data:
  • a PAN or partial type identifier associated with the electronic device.
  • the management server receives the
  • the method further comprises:
  • 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 bank transaction, in which the terminal performs the steps of a first processing method as defined above,
  • 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;
  • the electronic device further transmits, as input data, the current value of the counter to the terminal.
  • the electronic device generates the cryptogram from a random value which is generated by the electronic device with each new transaction;
  • the electronic device further transmits, as input data, the random value to the terminal.
  • the second treatment method further comprises:
  • the second treatment method further comprises:
  • 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.
  • the different steps of the first processing method, the management method and the second processing method are determined by instructions from computer programs.
  • 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 carriers) readable by a computer, and comprising instructions of a computer program corresponding to each of the methods defined above.
  • 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.
  • the recording media mentioned in this document can be any entity or device capable of storing the program.
  • 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.
  • 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.
  • 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.
  • 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.
  • the invention is implemented by means of software and / or hardware components.
  • the term "module" may correspond in this document to either 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.
  • a hardware component corresponds to any element of a hardware assembly (or hardware) capable of implementing a function or a set of functions, according to what is described in this document for the module concerned. It may be a programmable hardware component or with an integrated processor for the execution of software, for example an integrated circuit, a smart card, a memory card, etc.
  • 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.
  • FIG. 1 schematically represents, in the form of a diagram, an example of processing a transaction according to the EMV protocol.
  • 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 schematically represents functional modules implemented by a terminal according to a particular embodiment of the invention.
  • FIG. 4 schematically represents functional modules implemented by a management server according to a particular embodiment of the invention.
  • FIG. 5 schematically represents functional modules implemented by a smart card according to a particular embodiment of the invention.
  • 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 schematically represents, in the form of a diagram, the steps of a treatment method according to a particular embodiment of the invention.
  • 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 schematically represents, in the form of a diagram, the steps of a treatment method according to a particular embodiment of the invention.
  • 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.
  • the invention provides a solution using a trusted third party taking the form of a management server.
  • a terminal is configured to transmit data to the management server so that the latter can generate an electronic ticket to interested parties in a reliable and secure manner.
  • This management server can also perform various operations to manage these electronic tickets.
  • the invention notably proposes, 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:
  • 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:
  • the first cryptogram has been generated by an electronic device from the input data which comprises 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;
  • 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.
  • EMV type smart card configured to process EMV transactions.
  • 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.
  • 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.
  • 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.
  • the terminal 110 sends (S5a) to the smart card 100 a SELECT FILE command in order to request from the smart card the applications that this last is able to run.
  • This SELECT FILE 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).
  • 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 a SELECT APPLICATION command at S6 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 a S8 phase for reading data, called RECORDS, present in memory in the smart card 100.
  • GPO GET PROCESSING OPTIONS
  • RECORDS S8 phase for reading data
  • 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 code PIN of the 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 chip card 100 a first GAC command (for "GENERATE AC") also noted 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 and then sends (S11), in response to GAC1, a cryptogram.
  • the smart card 100 sends to S11 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 not to continue the online transaction depends on the configuration of the card.
  • the ARQC cryptogram is transmitted (S12) 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
  • the transmitter 120 sends (S 14) then, in response to the ARCQ message received, an ARPC cryptogram (for “Authorization Response Cryptogram”) indicating the decision of the transmitter 120.
  • This ARPC message is transmitted (S16) by the terminal 110 to the card 100 in a second GAC command, denoted GAC2, well known to those skilled in the art.
  • 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 returns to S18 a cryptogram TC or ACC respectively indicating that it accepts or refuses the transaction.
  • 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.
  • the smart card of the invention thus processes payment transactions, although other types of transaction are possible.
  • 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 T1, 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 TR1. It is assumed in this example that the transaction TR1 is a payment transaction of the EMV type, however other examples are possible.
  • the user U R uses his bank card DV1 to carry out the payment transaction TR1 with a third entity, namely the merchant entity (or trading sign) MD in this example.
  • a third entity namely the merchant entity (or trading sign) MD in this example.
  • the terminal T1 In addition to interacting with the bank card DV1 in accordance with the EMV standard, the terminal T1 also cooperates with the management server SV1, the latter being configured to generate and manage an electronic ticket, noted TK1, representative of the transaction TR1 .
  • the terminal T1 comprises a processor 2, a first non-volatile memory MR1, a second non-volatile memory MR2, a first communication interface INT1 and a second communication interface INT2.
  • Terminal T1 here takes the form of a payment terminal, although other embodiments are possible.
  • the memory MR1 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 terminal T1 , and on which is recorded a computer program PG1 conforming to a particular embodiment.
  • This computer program PG1 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 (Flash for example) capable of storing data such as a terminal identifier IDT 1 which identifies the terminal T1 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.
  • data such as a terminal identifier IDT 1 which identifies the terminal T1 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 memories MR1 and MR2 form a single memory.
  • the first communication interface INT 1 allows the terminal T 1 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.
  • the second communication interface INT2 allows the terminal T1 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 T1 and the management server SV1 on the one hand, and between the terminal T1 and the smart card DV1 on the other hand. These data will be described in more detail later.
  • the bank card DV1 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 DV1 comprises a processor 4, a communication interface INT5, 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 card bank DV1, and on which is recorded a computer program PG3 conforming to a particular embodiment.
  • This computer program PG3 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) K1 .
  • the memory MR6 can optionally store other data such as in particular DH history data or a counter CT1. The use and value of this data will be described later.
  • the memories MR5 and MR6 form a single memory.
  • the INT5 communication interface allows the terminal T1 to communicate with terminal T1, and more particularly with its communication interface INT2.
  • the DV1 chip card can for example include external contacts (of the ISO 7816 type for example) located on the surface of the card body.
  • the L2 link is a contact link.
  • the terminal T1 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.
  • the DV1 smart card comprises an antenna (not shown). In this case, the bank card DV1 can establish a link L2 without contact with the terminal T 1.
  • the management server SV1 comprises a processor 10, a first communication interface INT10, a second communication interface INT 11, a first memory MR10 and a second memory MR11.
  • 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 a particular embodiment.
  • 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 memory MR11 is a rewritable non-volatile memory (Flash for example) capable of storing data such as a cryptogram MC1 generated by the smart card DV1, input data DM1 used by the smart card DV1 for generate the cryptogram MC1, transaction data DTR1 representative of the transaction TR1 and the encryption key K1. The use and value of this data will be described later.
  • the memories MR10 and MR11 form a single memory.
  • the first communication interface INT10 allows the management server SV1 to communicate with the terminal T 1. To do this, the first communication interface INT10 establishes a communication link L1 with the terminal T1, and more particularly with its interface communication INT1. As already indicated, this L1 link can be wired or wireless, and can be of any suitable nature.
  • the second communication interface INT11 allows the management server SV1 to transmit to the user UR an electronic ticket TK1 generated by the management server SV1, this electronic ticket being representative of the transaction TR1.
  • This electronic ticket TR1 constitutes a digital ticket (or receipt) comprising various information relating to the transaction TR1 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 link, in particular by sending an email or an SMS.
  • the processor 2 of the terminal T1 controlled by the computer program PG1 here implements a number of modules, namely: a first reception module MD2, a first transmission module MD4, a second reception module MD6, a second transmission module MD8, and possibly a storage management module MD10.
  • the first reception module MD2 is configured to receive, from the bank card DV1, the first data DT1 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 T1.
  • second data DT2 can comprise other data as explained later, such as in particular transaction data DTR1 characterizing the transaction TR1.
  • the second reception module MD6 is configured to receive, from the bank card DV1, a cryptogram MC1 generated from an encryption key K1 and from input data DM1 comprising at least the identifier IDT1 of terminal T1 and 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 includes at least the cryptogram MC1, the input data DM1 and transaction data DTR2 characterizing the transaction TR1, and aims to trigger the generation by the management server DV1 of an electronic ticket TK1 representative of the transaction TR1 , from the data transmitted by the terminal T1.
  • the storage management module MD10 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 MD10 can send CMD4 or CMD5 commands to the bank card DV1 as described in more detail later.
  • the processor 10 of the server SV1 controlled by the computer program PG2 implements here a certain number of modules, namely: a module of reception MD20, a first generation module MD22, a verification module MD24, a second generation module MD26, and possibly a processing module MD28.
  • the reception module MD20 is configured to receive, from the terminal T1, the cryptogram MC1, the input data DM1, the transaction data DTR2 characterizing the transaction TR1 as well as the ticket generation request. electronic RQ1.
  • the cryptogram MC1 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.
  • the decryption key is identical to the encryption key K1 used by the bank card DV1 to generate the cryptogram MC1.
  • the MD24 verification module is configured to verify the validity of the request for generating an electronic ticket RQ1, and this from a comparison of the first cryptogram MC1 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 TR1, from at least the input data DM1 and / or the transaction data DTR2 received .
  • 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.
  • the processor 4 of the bank card DV1 controlled by the computer program PG3 implements here a certain number of modules, namely: a first module MD40 transmission module, an MD42 reception module, a MD44 generation module, a second MD46 transmission module and an MD48 storage module.
  • the first transmission module MD40 is configured to transmit, to the terminal T1, the first data DT1 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 T1, the second data DT2 comprising at least the terminal identifier IDT1 identifying the terminal T1.
  • the second data may include other data such as the transaction data DTR1 already mentioned above.
  • the MD44 generation module is configured to generate the cryptogram MC1 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 T1, the cryptogram MC1 and the input data DM1 to allow the transmission by the terminal T1 of the request for generating electronic ticket RQ1 to the management server SV1 .
  • the storage module MD48 is configured to manage the storage, locally in the memory MR6 of the bank card DV1, of the cryptogram MC1 or of DH history data, as explained below.
  • two modules of the terminal T1, of the management server SV1 or of the bank card DV1 can be implemented within a single module, depending on the configuration chosen. So the first and second reception modules MD2, MD8 can form a single 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.
  • the terminal T1, the server SV1 and the bank card DV1 each implement a respective module to carry out each operation or step of a corresponding process of the invention.
  • 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.
  • the management server SV1 implements a management method by executing the instructions of the computer program PG2.
  • TR1 an EMV transaction denoted TR1 is initiated between the external terminal T1 and the bank card CD1.
  • This transaction TR1 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.
  • the transaction TR1 is an EMV payment transaction in this example. More particularly, it is assumed that the user U R uses his bank card EMV DV1 to carry out the payment transaction TR1 with the shopping brand MD. To do this, the user U R inserts his bank card DV1 into the terminal T1 (contact transaction) or presents his bank card DV1 near the terminal (contactless transaction).
  • the bank card C4 sends to the terminal T1 a command CMD1 comprising a datum DX1 indicating that the bank card DV1 supports an electronic ticket service.
  • a command CMD1 comprising a datum DX1 indicating that the bank card DV1 supports an electronic ticket service.
  • the command CMD1 is a response from the bank card DV1 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.
  • the DX1 data can be transmitted in the CMD1 command in the form of at least one RFU bit (for "Reserved for Future Use"), provided that such an RFU bit is provided by the EMV standard for the CMD1 command in question.
  • the DX1 data is transmitted in a SELECT command which is sent by the bank card DV1 to the terminal T1 in response to a SELECT command, as already described with reference to step S5b in FIG. 1.
  • 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).
  • 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.
  • this DX1 datum can be transmitted by the bank card DV1 following the GET PROCESSING OPTIONS (GPO) command sent by the terminal T1, for example in RECORD data read by the terminal T1 from the bank card DV1 during a reading phase S8 of RECORDS already described with reference to FIG. 1.
  • GPO GET PROCESSING OPTIONS
  • 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.
  • the terminal T1 sends (B6) thus a request RC1 that the bank card DV1 receives during a reception step C6.
  • the bank card DV1 transmits (C8) to the terminal T1, as RECORDS, first data DT1 comprising at least one user identifier IDUR identifying the user UR associated with the bank card DV1.
  • This first DT1 data can possibly include other data such as an address AD1, corresponding to the server SV1, the use of which will be described later.
  • the user identifier IDUR is different from a PAN type identifier (for "Primary Account Number") associated with the bank card DV1.
  • PAN type identifier for "Primary Account Number”
  • the terminal T1 receives the first data DT1 at B8.
  • the process continues with an optional phase S20 of authentication of the user UR.
  • 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.
  • the PIN code is not verified, in particular during a contactless payment transaction.
  • the processing of the transaction TR1 continues with a phase of verification of the transaction, during which the terminal T1 performs (B12) a risk analysis (known as “Terminal Risk Management”) ), in accordance with the EMV protocol.
  • B12 a risk analysis
  • the terminal T1 transmits (B14) to the bank card DV1 second data DT2 comprising at least one terminal identifier IDT1 identifying the terminal T1.
  • 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 geographical position of the shopping sign MD where the terminal T 1 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 in C14 (FIG. 6) then proceeds to a generation step C16 during which it generates a cryptogram MC1 from an encryption key K1 and input data DM1 comprising at least the terminal identifier IDT1 and the user identifier IDUR.
  • the cryptogram is a MAC code (for "Message Authentication Code").
  • the purpose of this MC1 code is to secure the electronic ticket service.
  • the input data DM1 taken into account by the bank card DV1 to generate the cryptogram MC1 may include additional data, in particular other data also supplied by the terminal T1 in the second data DT2.
  • 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 MC1.
  • the second data DT2 transmitted in B14 by the terminal T1 also includes transaction data DTR1 representative of the transaction TR1 in progress.
  • this transaction data DTR1 can also be included in the input data DM1 used by the bank card DV1 to generate the cryptogram MC1.
  • This DTR1 data can include for example at least one of: the date and / or time of the TR1 transaction, the amount of the TR1 transaction and the currency used.
  • each of the IDMD, LOC and DTR1 data which are effectively transmitted to the bank card DV1 in the second data DT2 are used as input data DM1 by the bank card DV1 to generate the cryptogram MC1 in C16. Taking this additional data into account makes it possible to further secure the process of the invention.
  • each of the data transmitted by the terminal T1 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 EMV protocol.
  • the bank card DV1 can request in the list CDOL transmitted as RECORD in S8 that the terminal T1 transmits 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 DT2 data (B14) by the terminal T1 is then made in response to this prior request from the bank card DV1.
  • the bank card DV1 also takes into account, as input data CT1, the current value of a counter CT1 which is incremented by the bank card DV1 with each new transaction.
  • this counter CT 1 is stored locally in the memory MR6 (FIG. 2) of the bank card DV1.
  • the use of such a counter CT1 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.
  • CT1 is a random value which is generated by the bank card DV1 with each new transaction.
  • 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 (C18) to the terminal T1 a command CMD2 comprising the cryptogram MC1 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.
  • 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 stage of the TC or AAC response already described previously with reference to step S18 of FIG. 1.
  • the bank card DV1 also generates an electronic signature to validate the transaction TR1 in progress. In this case, this electronic signature is also transmitted (C18) to the terminal T1 in the command CMD2.
  • This electronic signature can be generated by the bank card DV1 from an encryption key other than K1.
  • the bank card DV1 can also contain in its local memory MR6 history data DH, denoted here DHO, associated with at least one previous TRO transaction processed by said card DV1.
  • 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 DV1 from the encryption key K1 and from the previous input data DM0 (in the same way as described above with reference to step C16).
  • the bank card DV1 also transmits in C18 the DHO history data to the terminal T1 (in the command CMD2 for example) in order to require the generation of an electronic ticket of at least one previous transaction TRO.
  • the terminal T1 receives the command CMD2 at B18 then transmits to the management server SV1 a request for generating an electronic ticket RQ1 comprising at least the cryptogram MC1, the input data DM1 and transaction data DTR2 characterizing the transaction TR1, 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.
  • the transaction data DTR1 and DTR2 are identical.
  • the nature and number of data TR2 transaction (date / time, amount, currency ...) that the T2 terminal chooses to provide to the SV1 server can be adapted as appropriate.
  • the terminal T1 can use this address AD1 to send the request RQ1 to the management server SV1.
  • This address AD1 can be a URL address or any other information allowing the terminal T1 to connect with the server SV1.
  • the terminal T1 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 sign MD associated with the terminal T 1.
  • the terminal T1 has also received in B18 (FIG. 6) the historical data DH0 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 history data DH0 to further require the generation of at least one additional electronic ticket from this history data DH0. It is thus possible to obtain one or more electronic tickets relating to at least one previous transaction TR0 in the case where it has not been 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.
  • the terminal T1 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 transaction TR1 is valid, as explained below.
  • the request RQ1 transmitted by the terminal T1 at B20 thus comprises a concatenation of the cryptogram MC1, of the input data DM1, of the transaction data DTR2 and possibly at least one of the additional data mentioned above (MSG1, DHO, SG1).
  • the management server SV1 receives the request RQ1 and all the data associated with A20 (FIG. 6).
  • the server SV1 In a generation step A22, the server SV1 generates a second cryptogram MC2 from the decryption key K1 (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 cryptogram MC1 in C16. 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 MC1 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 MC1 cryptogram is valid.
  • 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.
  • the management server SV1 then generates an electronic ticket TK1 representative of the transaction TR1, and this at least from the input data DM1 and the 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 transaction TR1.
  • the format of the TK1 electronic ticket and the nature of the information it contains may vary depending on the case.
  • the TK1 electronic ticket includes example of text type data and / or image type data.
  • the TK1 electronic ticket can take the form of a file for example.
  • the electronic ticket TK1 comprises at least one of the following data:
  • the transaction data DTR2 can include at least one of: the date and / or time of the transaction TR1, the amount of the transaction TR1, 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 SG1 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 transaction TR1.
  • the management server SV can also generate an electronic ticket TKO for each previous transaction TRO specified in this DHO history data. This allows the user U R 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.
  • the management server SV1 can carry out all appropriate management operations in relation to the electronic ticket TK1 thus generated (and, if applicable, with the TKO electronic ticket (s) from previous transactions).
  • the management server SV1 then sends (A30) the electronic ticket TK1 to the user U R via the communication link L3 (FIG. 2).
  • the server SV1 for example sends the electronic ticket TK1 via an email or an SMS.
  • 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 SV1 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.
  • the management server SV1 receives at A20 (FIG.
  • the server SV1 communicates (A20) with the terminal T1 via a telecommunications network, and sends (A30) the electronic ticket TK1 via an SMS, an email or the like.
  • the management server SV1 can also send the electronic ticket TK1 to the merchant 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 T1 (via the link L1 for example).
  • the management server SV1 transmits (A32) to the terminal T 1 a positive message MSG3 indicating that the request for generating an electronic ticket RQ1 is accepted.
  • Terminal T1 receives this positive response MSG3 in B32.
  • the terminal T1 on receipt of the positive response MSG3 from the management server SV1 to the request RQ1, the terminal T1 also sends (B34) to the bank card DV1 a deletion command CMD4 to order the deletion in the local memory MR6 of the bank card DV1 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 bank card DV1 receives the delete command CMD4 during a reception step C34. Upon detection of this CMD4 command, the bank card DV1 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 rapid and reliable processing of the transactions.
  • This solution is ecological and makes it possible to reduce the costs associated with the production of traditional tickets, while allowing better management of the tickets by the user who no longer needs to store the physical tickets.
  • the management server of the invention acting as a trusted third party, is capable of handling a request for generating an electronic ticket 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 identifier received from the terminal, to which address the generated electronic ticket (s) must be transmitted. 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.
  • the terminal T1 is capable of triggering the generation of an electronic ticket insofar as a connection (link L1, FIG. 1) can be established between the terminal T1 and the management server SV1.
  • a connection (link L1, FIG. 1) can be established between the terminal T1 and the management server SV1.
  • the terminal T 1 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 a problem of access to the communication network or a breakdown of the management server SV1.
  • the management server SV1 can decide to refuse to process the request for generating an electronic ticket TK1 for various reasons (technical problem, insufficient resources, etc.).
  • 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 SV1 for various reasons.
  • the terminal T1 transmits (B42) to the bank card DV1 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 SV1 or any other terminals and management server provided for this purpose.
  • the history data DH1, associated with the transaction TR1 includes at least the cryptogram MC1, 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 DV1 bank card then proceeds to the registration (C44) locally in its memory MR6 history data DH1 associated with the transaction TR1.
  • the DV1 bank card can thus locally store the historical data necessary for the subsequent generation of an electronic ticket.
  • the generation of this e-ticket is therefore 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.
  • the bank card DV1 checks whether it has sufficient memory space (in its memory MR6) before the recording step C44. It therefore does this C44 recording only if it has sufficient memory space.
  • the bank card DV1 receives in C14 in particular the merchant identifier IDMD in the second data DT2 transmitted by the terminal T 1.
  • the bank card DV1 After having determined (C14) the merchant identifier IDMD associated with the merchant entity MD, the bank card DV1 checks (C50) if this identifier corresponds to a predefined merchant. To do this, the bank card DV1 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.
  • step C52 the bank card DV1 blocks the generation (C16) of the cryptogram MC1. Consequently, the bank card DV1 does not transmit in C18 the cryptogram MC1 and the data associated with the terminal T1 as described above with reference to FIG. 6. On the other hand, the bank card DV1 can send an indication of refusal of electronic ticket to terminal T 1.
  • the bank card DV1 checks (C50) if the merchant identifier IDMD corresponds to a predefined merchant and transmits in C18 (FIG. 6) the cryptogram MC1 to the terminal T1 only if the merchant entity MD does not correspond not to a predefined merchant.
  • the bank card DV1 receives in C14 in particular the merchant identifier IDMD in the second data DT2 transmitted by the terminal T1.
  • the bank card DV1 verifies whether the merchant identifier IDMD received corresponds to a predefined merchant. To do this, the bank card DV1 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.
  • step C62 the bank card DV1 blocks the recording in its local memory MR6 of the historical data DH1.
  • DV1 bank card can send to terminal T1 an indication of refusal to store history data DH1.
  • the bank card DV1 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 unless the trading entity MD does not correspond to a predefined merchant.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention vise un procédé de traitement mis en œuvre par un terminal (Tl) pour traiter une transaction (TRI) avec un dispositif électronique (DV1), le procédé comprenant : réception, depuis le dispositif électronique (DV1), de premières données (DTI) comprenant un identifiant d'utilisateur (IDUR); transmission, au dispositif électronique (DV1), de deuxièmes données (DT2) comprenant un identifiant de terminal (IDT1) identifiant le terminal (Tl); réception, en provenance du dispositif électronique (DV1), d'un cryptogramme (MCI) généré à partir d'une clé de chiffrement (Kl) et de données d'entrée (DM1) comprenant l'identifiant de terminal (IDT1) et l'identifiant d'utilisateur (IDUR); et transmission, à un serveur de gestion (SV1), d'une requête de génération de ticket électronique (RQ1) comprenant le cryptogramme (MCI), les données d'entrée (DM1) et des données de transaction (DTR2) caractérisant la transaction (TRI), pour requérir la génération par le serveur de gestion d'un ticket électronique (TK1) représentatif de la transaction (TRI).

Description

Description
Titre de l'invention : Traitement d'un service de tickets électroniques
Domaine Technique
[0001] L’invention se situe dans le domaine des transactions bancaires et porte plus particulièrement sur la génération et la gestion de tickets électroniques représentatifs de transactions bancaires traitées par un terminal en coopération avec un dispositif électronique tel qu’une carte bancaire par exemple.
Technique antérieure
[0002] Une carte bancaire est une carte à puce destinée à traiter des transactions bancaires, telles que des transactions de paiement, des transactions de transfert, ou toutes autres transactions financières appropriées. Il peut s’agir par exemple de cartes de crédit ou de cartes de débit.
[0003] Pour ce faire, une carte bancaire comprend au moins une application bancaire (application de paiement par exemple, de type VISA™ ou autre) exécutable par une puce électronique intégrée dans la carte. Cette puce électronique est configurée pour coopérer avec des terminaux externes (ou lecteurs), tels que des terminaux de paiement ou des distributeurs automatiques de billets (DAB), pour réaliser diverses fonctions.
[0004] Une carte bancaire est traditionnellement conçue pour coopérer avec un terminal externe au moyen de contacts externes accessibles à la surface de la carte. Un terminal externe peut ainsi positionner des broches de contact appropriées sur les contacts externes de la carte afin d’établir une communication par contact avec la puce électronique. Plus récemment, les cartes bancaires sans contact ont connu un essor important en raison du gain en rapidité et en simplicité liées aux transactions sans contact. Pour ce faire, les cartes sans contact embarquent une antenne radiofréquence permettant la transmission et la réception de signaux RF avec un terminal externe.
[0005] EMV (pour « Europay MasterCard Visa ») est le protocole standardisé utilisé aujourd’hui majoritairement dans le monde pour sécuriser les transactions bancaires effectuées par les cartes bancaires. [0006] De façon connue, il est courant lors d’une transaction bancaire, de type EMV par exemple, qu’un ticket (appelé aussi « facturette » ou « reçu ») soit produit pour indiquer aux parties prenantes (utilisateur de la carte, utilisateur du terminal) des données de transaction telles que le montant, la date ou encore le résultat de la transaction (réussie, échouée). Ce ticket est obtenu par impression sur un support matériel, généralement en papier.
[0007] De plus en plus de commerçants utilisent à présent la solution du ticket électronique, appelé aussi e-ticket ou billet électronique. Il s’agit d’un ticket dématérialisé qui remplace le ticket traditionnel papier par des informations numériques représentatives d’une transaction. Lors d’une transaction EMV par exemple, le ticket électronique est généré par le terminal de paiement puis envoyé par email au porteur de la carte bancaire. Cette solution est plus écologique et permet de réduire les coûts liés à la production de tickets traditionnels, tout en permettant une meilleure gestion des tickets par l’utilisateur qui n’a plus besoin de stocker les tickets physiques.
[0008] Toutefois, l’utilisation des tickets électroniques présentent certaines contraintes. Pour recevoir un ticket électronique lors d’une transaction de paiement par exemple, le porteur de la carte bancaire doit généralement fournir son adresse email. Cette opération est lente, peut engendrer des risques de saisie et n’est pas toujours souhaitable pour les utilisateurs qui sont souvent réticents à divulguer leur adresse email, à une enseigne commerciale par exemple. De manière générale, les utilisateurs souhaitent protéger leur identité numérique et se prémunir des risques de spams commerciaux. En outre, si le porteur de la carte n’a pas de carte de fidélité auprès de l’enseigne commerçante concernée, il doit fournir son adresse email à chaque transaction, ce qui est fastidieux, ralentit le traitement des transactions et augmente encore plus les risques d’erreur.
[0009] Les contraintes et problèmes énoncés ci-dessus sont d’autant plus importants que, à l’avenir, de plus en plus de commerçants seront amenés à utiliser exclusivement les tickets électroniques, abandonnant ainsi définitivement la solution des tickets traditionnels. [0010] Par ailleurs, la solution des tickets électroniques n’est pas limitée aux cartes bancaires mais peut être utilisée plus généralement avec d’autres moyens de paiement, tels que les smartphones, tablettes ou tous autres dispositifs électroniques destinés à implémenter une application pour interagir avec un terminal externe afin de traiter une transaction, de type EMV ou autre. L’essor des solutions de paiement mobiles ou mPOS pour « mobile Point of Sale » a pour conséquence que les commerçants n’ont souvent plus d’imprimante à disposition pour produire des tickets traditionnels.
[0011] Un besoin existe donc aujourd’hui pour une solution permettant une gestion efficace des tickets électroniques, qui garantit la confidentialité des porteurs de cartes bancaires tout en assurant un traitement rapide et fiable des transactions.
[0012] Un besoin existe notamment pour une gestion améliorée des tickets électroniques liés aux transactions de type EMV.
Exposé de l’invention
[0013] A cet effet, la présente invention vise un premier procédé de traitement mis en œuvre par un terminal pour traiter une transaction bancaire en coopération avec un dispositif électronique, ledit procédé comprenant :
- réception, en provenance du dispositif électronique, de premières données comprenant un identifiant d’utilisateur (IDUR) identifiant un utilisateur associé au dispositif électronique ;
- transmission, au dispositif électronique, de deuxièmes données comprenant un identifiant de terminal identifiant le terminal ;
- réception, en provenance du dispositif électronique, d’un cryptogramme généré à partir d’une clé de chiffrement et de données d’entrée comprenant l’identifiant de terminal et l’identifiant d’utilisateur ; et
- transmission, à un serveur de gestion, d’une requête de génération de ticket électronique comprenant le cryptogramme, les données d’entrée et des données de transaction caractérisant la transaction, pour requérir la génération par le serveur de gestion d’un ticket électronique représentatif de la transaction à partir des données transmises par le terminal. [0014] L’invention permet une gestion efficace des tickets électroniques générés lors de transactions bancaires, de type EMV par exemple, de sorte à garantir la confidentialité des porteurs de cartes bancaires tout en assurant un traitement rapide et fiable des transactions.
[0015] Le dispositif électronique peut être par exemple une carte à puce ou carte bancaire, de type EMV ou autre.
[0016] Selon un mode de réalisation particulier, les premières données transmises par le dispositif électronique comprennent une adresse du serveur de gestion, le terminal utilisant ladite adresse pour transmettre la requête de génération de ticket électronique audit serveur de gestion.
[0017] Selon un mode de réalisation particulier, les deuxièmes données, transmises au dispositif électronique, comprennent en outre au moins l’un parmi :
a) un identifiant de marchand identifiant une entité marchande associée au terminal ;
b) une donnée de localisation spécifiant une position de ladite entité marchande ;
c) des données de transaction caractérisant la transaction ; dans lequel chacune desdites données a), b) et c) qui est effectivement transmise au dispositif électronique est utilisée en tant que donnée d’entrée par le dispositif électronique pour générer le cryptogramme.
[0018] Selon un mode de réalisation particulier, le cryptogramme est un code MAC.
[0019] Selon un mode de réalisation particulier, en l’absence d’une réponse positive à la requête de génération de ticket, le terminal transmet au dispositif électronique une commande de stockage requérant le stockage, dans une mémoire locale du dispositif électronique, de données d’historique comprenant le cryptogramme, les données d’entrée et les données de transaction pour permettre une transmission d’une requête ultérieure de génération de ticket électronique lors d’une transaction ultérieure.
[0020] Selon un mode de réalisation particulier, le premier procédé de traitement comprend en outre : - réception, en provenance du dispositif électronique, de données d’historique stockées dans une mémoire locale du dispositif électronique et associées à au moins une transaction antérieure ; et
- transmission, au serveur de gestion, en accompagnement de la requête de génération de ticket électronique, des données d’historique pour requérir en outre la génération d’au moins un ticket électronique supplémentaire à partir desdites données d’historique.
[0021] Selon un mode de réalisation particulier, les données d’historique comprennent, en association avec chaque transaction antérieure : un cryptogramme antérieur, des données d’entrée antérieures et des données de transaction antérieures caractérisant ladite au moins une transaction antérieure, ledit cryptogramme antérieur ayant été généré par ledit dispositif électronique à partir de la clé de chiffrement et des données d’entrée antérieures associées.
[0022] Selon un mode de réalisation particulier, le premier procédé de traitement comprend en outre :
- réception d’une réponse positive du serveur de gestion à ladite requête de génération de ticket électronique ; et
- sur détection de la réponse positive, transmission au dispositif électronique d’une commande de suppression pour commander la suppression dans la mémoire locale du dispositif électronique desdites données d’historique.
[0023] L’invention vise également un procédé de gestion mis en œuvre par un
serveur de gestion coopérant avec un terminal destiné à traiter une transaction bancaire, ledit procédé comprenant les étapes suivantes :
- réception, en provenance du terminal, d’un premier cryptogramme, de données d’entrée, de données de transaction caractérisant la transaction ainsi que d’une requête de génération de ticket électronique,
dans lequel le premier cryptogramme a été généré par un dispositif électronique à partir des données d’entrées qui comprennent un identifiant d’utilisateur identifiant un utilisateur et un identifiant de terminal identifiant le terminal ;
- génération d’un deuxième cryptogramme à partir d’une clé de déchiffrement et des données d’entrées ; - vérification de la validité de la requête de génération de ticket électronique, à partir d’une comparaison du premier cryptogramme avec le deuxième cryptogramme ; et
- si ladite requête est valide, génération d’un ticket électronique représentatif de la transaction, à partir au moins des données d’entrée et des données de transaction reçues.
[0024] Comme déjà indiqué, le dispositif électronique peut être par exemple une carte à puce ou carte bancaire, de type EMV ou autre.
[0025] Selon un mode de réalisation particulier, le ticket électronique comprend au moins l’une parmi les données suivantes :
a) les données de transaction caractérisant la transaction ; b) l’identifiant de terminal ;
c) l’identifiant d’utilisateur ;
d) un identifiant de marchand identifiant une entité marchande associée au terminal ;
e) une donnée de localisation spécifiant une position de ladite entité marchande ;
f) un message prédéfini associé à ladite entité marchande ; et
g) un identifiant de type PAN, partiel ou complet, associé au dispositif électronique.
[0026] Selon un mode de réalisation particulier, le serveur de gestion reçoit le
cryptogramme, les données d’entrée, les données de transaction ainsi que la requête de génération de ticket électronique en provenance du terminal via un premier canal de communication ;
le procédé comprend en outre :
- envoi du ticket électronique audit utilisateur via un deuxième canal de
communication différent du premier canal de communication.
[0027] L’invention vise également un deuxième procédé de traitement mis en œuvre par un système comprenant un terminal et un dispositif électronique coopérant ensemble pour traiter une transaction bancaire, dans lequel le terminal réalise les étapes d’un premier procédé de traitement tel que défini ci-avant,
dans lequel le dispositif électronique réalise les étapes suivantes :
- transmission, au terminal, de premières données comprenant un identifiant d’utilisateur identifiant un utilisateur associé au dispositif électronique ;
- réception, en provenance du terminal, de deuxièmes données comprenant un identifiant de terminal identifiant le terminal ;
- génération d’un cryptogramme à partir d’une clé de chiffrement et de données d’entrée comprenant l’identifiant de terminal et l’identifiant d’utilisateur ; et
- transmission, au terminal, du cryptogramme et des données d’entrée pour permettre la transmission par le terminal d’une requête de génération de ticket électronique à un serveur de gestion.
[0028] Selon un mode de réalisation particulier, le dispositif électronique génère en outre le cryptogramme à partir de la valeur courante d’un compteur, la valeur dudit compteur étant incrémenté par le dispositif électronique à chaque nouvelle transaction ;
dans lequel le dispositif électronique transmet en outre, en tant que données d’entrée, la valeur courante du compteur au terminal.
[0029] Selon une variante, le dispositif électronique génère le cryptogramme à partir d’une valeur aléatoire qui est générée par le dispositif électronique à chaque nouvelle transaction ;
dans lequel le dispositif électronique transmet en outre, en tant que données d’entrée, la valeur aléatoire au terminal.
[0030] Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend en outre :
- détermination, par le dispositif électronique, d’un identifiant de marchand identifiant une entité marchande associée au terminal ; et
- vérification, par le dispositif électronique, de si l’identifiant de marchand correspond à un marchand prédéfini ;
dans lequel ladite transmission, par le dispositif électronique, du cryptogramme au terminal n’est réalisée que si l’entité marchande ne correspond pas à un marchand prédéfini. [0031] Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend en outre :
- détermination, par le dispositif électronique, d’un identifiant de marchand identifiant une entité marchande associée au terminal ; et
- vérification, par le dispositif électronique, de si l’identifiant de marchand correspond à un marchand prédéfini ;
- dans lequel ledit stockage en local, par le dispositif électronique, des données d’historique est réalisé si l’entité marchande ne correspond pas à un marchand prédéfini.
[0032] Selon un mode de réalisation particulier, le deuxième procédé comprend : en réponse à une commande de stockage reçue en provenance du terminal, stockage dans une mémoire locale du dispositif électronique, du cryptogramme, des données d’entrée et des données de transaction pour permettre la transmission, par un terminal, d’une requête ultérieure de génération de ticket électronique lors d’une transaction ultérieure.
[0033] Dans un mode particulier de réalisation, les différentes étapes du premier procédé de traitement, du procédé de gestion et du deuxième procédé de traitement sont déterminées par des instructions de programmes d’ordinateurs.
[0034] En conséquence, l’invention vise également un programme d’ordinateur adapté pour la mise en oeuvre du premier procédé de traitement, du procédé de gestion et du deuxième procédé de traitement tels que définis dans ce document. Plus précisément, l’invention vise au moins un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un dispositif électronique tel qu’une carte à puce, dans un terminal, dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes du premier procédé de traitement, du procédé de gestion ou du deuxième procédé de traitement tels que définis dans ce document.
[0035] L’invention vise aussi des supports d’enregistrement (ou supports d'informations) lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur correspondant à chacun des procédé définis ci-avant. [0036] A noter que les programmes d’ordinateur mentionnés dans le présent exposé peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
[0037] De plus, les supports d’enregistrement mentionnés dans ce document peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
[0038] D'autre part, les supports d’enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
[0039] Alternativement, les supports d’enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
[0040] L’invention vise également un terminal pour mettre en œuvre le premier procédé de traitement tel que défini dans le présent document.
[0041] L’invention vise également un serveur de gestion pour mettre en œuvre le procédé de gestion tel que défini dans ce document.
[0042] L’invention vise également un système pour mettre en œuvre le deuxième procédé de traitement tel que défini dans ce document. Ce système comprend ainsi un dispositif électronique, tel qu’une carte à puce ou carte bancaire par exemple (de type EMV ou autre), coopérant avec le terminal de l’invention.
[0043] A noter que les différents modes de réalisation mentionnés ci-avant en relation avec le premier procédé de traitement, le procédé de gestion et le deuxième procédé s’appliquent respectivement de façon analogue au terminal, au serveur de gestion et au système de l’invention. [0044] Dans les modes de réalisation décrits dans ce document, l'invention est mise en œuvre au moyen de composants logiciels et / ou matériels. Dans cette optique, sauf indication contraire, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
[0045] Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci- dessous pour le module concerné.
[0046] De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, etc.
[0047] De manière générale, le terminal, le serveur de gestion et le système de l’invention peuvent chacun comprendre un module respectif configuré pour réaliser chaque opération ou étape décrite dans ce document en relation avec les procédés correspondants de l’invention.
Brève description des dessins
[0048] D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:
[0049] [Fig. 1] La figure 1 représente schématiquement, sous la forme d’un diagramme, un exemple de traitement d’une transaction selon le protocole EMV.
[0050] [Fig. 2] La figure 2 représente schématiquement un environnement comprenant une carte à puce, un terminal et un serveur de gestion, conformément à un mode de réalisation particulier de l’invention. [0051] [Fig. 3] La figure 3 représente schématiquement des modules fonctionnels mis en œuvre par un terminal selon un mode de réalisation particulier de l’invention.
[0052] [Fig. 4] La figure 4 représente schématiquement des modules fonctionnels mis en œuvre par un serveur de gestion selon un mode de réalisation particulier de l’invention.
[0053] [Fig. 5] La figure 5 représente schématiquement des modules fonctionnels mis en œuvre par une carte à puce selon un mode de réalisation particulier de l’invention.
[0054] [Fig. 6] La figure 6 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de traitement selon un mode de réalisation particulier de l’invention.
[0055] [Fig. 7] La figure 7 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de traitement selon un mode de réalisation particulier de l’invention.
[0056] [Fig. 8] La figure 8 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de traitement selon un mode de réalisation particulier de l’invention.
[0057] [Fig. 9] La figure 9 représente schématiquement, sous la forme d’un diagramme, les étapes d’un procédé de traitement selon un mode de réalisation particulier de l’invention.
Description des modes de réalisation
[0058] La présente invention se propose de permettre une gestion efficace des tickets électroniques générés lors de transactions bancaires, de type EMV par exemple, de sorte à garantir la confidentialité des porteurs de cartes bancaires tout en assurant un traitement rapide et fiable des transactions.
[0059] Pour ce faire, l’invention propose une solution faisant appel à un tiers de confiance prenant la forme d’un serveur de gestion. Selon différentes modes de réalisation de l’invention, lors d’une transaction avec un dispositif électronique (tel qu’une carte à puce par exemple), un terminal est configuré pour transmettre des données au serveur de gestion de sorte que ce dernier puisse générer de façon fiable et sécurisée un ticket électronique à destination des parties intéressées. Ce serveur de gestion peut en outre réaliser diverses opérations pour gérer ces tickets électroniques.
[0060] L’invention propose notamment, selon différents modes de réalisation, un procédé de traitement mis en oeuvre par un terminal pour traiter une transaction bancaire en coopération avec un dispositif électronique, ledit procédé comprenant :
- réception, en provenance du dispositif électronique, de premières données comprenant un identifiant d’utilisateur identifiant un utilisateur associé au dispositif électronique ;
- transmission, au dispositif électronique, de deuxièmes données comprenant un identifiant de terminal identifiant le terminal ;
- réception, en provenance du dispositif électronique, d’un cryptogramme généré à partir d’une clé de chiffrement et de données d’entrée comprenant l’identifiant de terminal et l’identifiant d’utilisateur ; et
- transmission, à un serveur de gestion, d’une requête de génération de ticket électronique comprenant le cryptogramme, les données d’entrée et des données de transaction caractérisant la transaction, pour requérir la génération par le serveur de gestion d’un ticket électronique représentatif de la transaction, à partir des données transmises par le terminal.
[0061] Corrélativement, l’invention vise un procédé de gestion mis en œuvre par un serveur de gestion coopérant avec un terminal destiné à traiter une transaction bancaire, ledit procédé comprenant les étapes suivantes :
- réception, en provenance du terminal, d’un premier cryptogramme, de données d’entrée, de données de transaction caractérisant la transaction ainsi que d’une requête de génération de ticket électronique,
- dans lequel le premier cryptogramme a été généré par un dispositif électronique à partir des données d’entrées qui comprennent un identifiant d’utilisateur identifiant un utilisateur et un identifiant de terminal identifiant le terminal ; - génération d’un deuxième cryptogramme à partir d’une clé de déchiffrement et des données d’entrées ;
- vérification de la validité de la requête de génération de ticket électronique, à partir d’une comparaison du premier cryptogramme avec le deuxième cryptogramme ; et
- si ladite requête est valide, génération d’un ticket électronique représentatif de la transaction, à partir au moins des données d’entrée et des données de transaction reçues.
[0062] En outre, l’invention vise notamment le serveur de gestion et le terminal correspondant aux procédés définis ci-dessus, ainsi qu’un système comprenant le terminal et le dispositif électronique et les programmes d’ordinateurs correspondants aux procédés de l’invention.
[0063] D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.
[0064] Dans le présent exposé, des exemples de mise en œuvre de l’invention sont décrits dans le cadre d’une carte à puce de type EMV, configurée pour traiter des transactions EMV. A noter que d’autres modes de réalisation sont toutefois possibles. En particulier, l’invention ne s’applique pas exclusivement aux cartes à puce mais peut s’appliquer plus généralement à des dispositifs électroniques quelconques configurés pour traiter des transactions en coopération avec un terminal externe, selon le standard EMV ou selon tous autres protocoles appropriés. L’invention peut s’appliquer notamment aux smartphones, tablettes ou tous autres dispositifs électroniques implémentant une application pour traiter une transaction, de type EMV par exemple, en coopération avec un terminal externe.
[0065] Le protocole EMV, bien connu de l’homme du métier, a été conçu pour diminuer les risques de fraudes lors d’une transaction bancaire (transaction de paiement, par exemple) en permettant notamment l’authentification à la fois de la carte à puce et de son porteur. Les principes du protocole EMV sont rappelés ci- dessous. [0066] La figure 1 représente un exemple de mise en œuvre d’une transaction de paiement conforme au protocole EMV, à l’aide d’une carte à puce EMV 100. Certains aspects d’une transaction EMV ont été omis par souci de simplicité.
[0067] Lors d’une première phase destinée à authentifier la carte à puce 100 utilisée, le terminal 110 et la carte 100 s’échangent un certain nombre de messages dont un message RESET (RST) en S2 puis une réponse ATR en S4 (en mode avec contact). Le terminal 110 tente de choisir l’application appropriée sur la carte à puce 100. Pour ce faire, le terminal 110 envoie (S5a) à la carte à puce 100 une commande SELECT FILE afin de demander à la carte à puce les applications que cette dernière est capable d’exécuter. Cette commande SELECT FILE contient en paramètre l’identifiant d’application (AID pour « Application Identifier ») du PSE pour « Payment System Environment » (ou PPSE pour « Proximity Payment System Environment », en mode sans contact). En réponse, le terminal 110 envoie en S5b une commande APPLICATIONS qui contient une liste des différentes applications que la carte est capable d’exécuter. Le terminal 110 répond en envoyant en S6 une commande SELECT APPLICATION pour sélectionner une application dans la carte à puce 100 qui va traiter la transaction EMV. Pour ce faire, cette commande SELECT APPLICATION contient l’identifiant AID de l’application sélectionnée.
[0068] Le terminal 110 envoie ensuite en S7 à la carte à puce 100 une commande GET PROCESSING OPTIONS (GPO) qui déclenche une phase S8 de lecture de données, dites RECORDS, présentes en mémoire dans la carte à puce 100. Ces données sont dites statiques dans le sens où elles ne varient pas d'une transaction à une autre. Pour ce faire, le terminal 100 envoie des requêtes READ RECORD auxquelles la carte à puce 100 répond en fournissant des données statiques dans des réponses RECORD.
[0069] La carte 100 et le terminal 110 peuvent ensuite procéder à une phase optionnelle (non représentée) d’authentification du porteur de la carte, au cours le code confidentiel PIN du porteur est vérifié. Toutefois, si le mode sans vérification de code PIN est sélectionné, aucune vérification de code PIN n’est réalisé.
[0070] Le protocole EMV initie une phase de vérification de la transaction au cours de laquelle le terminal 110 envoie (S9) à la carte puce 100 une première commande GAC (pour « GENERATE AC ») notée aussi GAC1. Cette commande GAC1 bien connue de l’homme du métier comprend des informations sur la transaction en cours telles que le montant de la transaction, la devise utilisée, le type de transaction, etc. La carte EMV 100 réalise (S9) alors une vérification de la transaction selon des critères de vérification prédéfinis puis envoie (S11), en réponse au GAC1 , un cryptogramme.
[0071] Divers modes de réalisation sont envisageables. On suppose dans cet exemple que la carte à puce 100 envoie en S11 un cryptogramme ARQC (pour (« Autorisation Request Cryptogram ») indiquant qu’elle souhaite poursuivre la transaction en ligne avec l’émetteur 120 de la carte 100. La demande ou non de poursuivre la transaction en ligne dépend du paramétrage de la carte. Le cryptogramme ARQC est transmis (S12) par le terminal 110 à l’émetteur 120 qui peut ainsi réaliser (S13) un certain nombre de vérifications afin de s’assurer que la transaction est valide. L’émetteur 120 envoie (S 14) ensuite, en réponse au message ARCQ reçu, un cryptogramme ARPC (pour « Autorisation Response Cryptogram ») indiquant la décision de l’émetteur 120. Ce message ARPC est transmis (S16) par le terminal 110 à la carte 100 dans une deuxième commande GAC, notée GAC2, bien connue de l’homme du métier.
[0072] A noter que la carte à puce 100 peut également traiter la transaction en mode hors ligne, c’est-à-dire sans faire intervenir l’émetteur 120 pour vérifier la transaction.
[0073] La carte 100 détermine si elle accepte ou non la transaction à partir de la réponse ARPC. La carte 100 renvoie ainsi en S18 un cryptogramme TC ou ACC indiquant respectivement qu’elle accepte ou refuse la transaction.
[0074] A noter par ailleurs que, dans ce document, la notion de transaction bancaire doit être entendue au sens large et comprend par exemple, dans le domaine bancaire, une transaction de paiement, une transaction de débit, une transaction de transfert, ou toutes autres transactions financières pouvant faire l’objet de la gestion d’un ticket électronique conformément à l’invention. Dans les modes de réalisation décrits ci-après, la carte à puce de l’invention traite ainsi des transactions de paiement, bien que d’autres types de transaction soient possibles. [0075] Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
[0076] La figure 2 représente, de manière schématique, un environnement comprenant un terminal T1 , une carte bancaire DV1 et un serveur de gestion SV1 , conformément à un mode de réalisation particulier de l’invention.
[0077] Le terminal T1 et la carte bancaire DV1 , formant ensemble un système SY1 , sont configurés pour coopérer ensemble pour traiter une transaction bancaire notée TR1 . On suppose dans cet exemple que la transaction TR1 est une transaction de paiement de type EMV, d’autres exemples étant toutefois possibles.
[0078] Plus particulièrement, on suppose que l’utilisateur U R utilise sa carte bancaire DV1 pour réaliser la transaction de paiement TR1 auprès d’une entité tierce, à savoir l’entité marchande (ou enseigne commerçante) MD dans cet exemple.
[0079] En plus d’interagir avec la carte bancaire DV1 conformément au standard EMV, le terminal T1 coopère également avec le serveur de gestion SV1 , ce dernier étant configuré pour générer et gérer un ticket électronique, noté TK1 , représentatif de la transaction TR1 .
[0080] Le terminal T1 comprend un processeur 2, une première mémoire non volatile MR1 , une deuxième mémoire non volatile MR2, une première interface de communication INT1 et une deuxième interface de communication INT2. Le terminal T1 prend ici la forme d’un terminal de paiement bien que d’autres modes de réalisation soient possibles.
[0081] Plus précisément, la mémoire MR1 est une mémoire non volatile (Flash ou ROM par exemple), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le terminal T1 , et sur lequel est enregistré un programme d’ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG1 comporte des instructions pour l’exécution des étapes d’un procédé de traitement selon un mode de réalisation particulier qui sera décrit ultérieurement. [0082] La mémoire MR2 est une mémoire non volatile réinscriptible (Flash par exemple) apte à stocker des données telles qu’un identifiant de terminal IDT 1 qui identifie le terminal T1 et, éventuellement, au moins l’un parmi un identifiant de marchand IDMD qui identifie l’entité marchande MD et une donnée de localisation LOC spécifiant une position de cette entité marchande MD. L’usage et l’intérêt de ces données seront décrits plus en détail ultérieurement.
[0083] Selon un exemple particulier, les mémoires MR1 et MR2 forment une seule et même mémoire.
[0084] La première interface de communication INT 1 permet au terminal T 1 de communiquer avec le serveur de gestion SV1. Pour ce faire, la première interface de communication INT1 établit une liaison de communication L1 avec le serveur de gestion SV1. Cette liaison L1 peut être filaire ou sans fil, et peut être de toutes natures appropriées.
[0085] De même, la deuxième interface de communication INT2 permet au terminal T1 de communiquer avec la carte bancaire DV1. Pour ce faire, la deuxième interface de communication INT2 établit une liaison de communication L2 avec la carte bancaire DV1. Cette liaison L2 peut être une liaison par contact ou une liaison sans contact, selon les moyens de communication dont dispose la carte bancaire DV1 et le cas d’usage.
[0086] Les liaisons L1 et L2 permettent d’échanger des données entre le terminal T1 et le serveur de gestion SV1 d’une part, et entre le terminal T1 et la carte à puce DV1 d’autre part. Ces données seront décrites plus en détail ultérieurement.
[0087] Par ailleurs, la carte bancaire DV1 est dans cet exemple une carte à puce EMV configurée pour traiter des transactions selon le standard EMV en coopération avec des terminaux externes tels que le terminal T1. La carte bancaire DV1 comprend un processeur 4, une interface de communication INT5, une première mémoire MR5 et une deuxième mémoire MR6. Ces composants sont compris dans une puce électronique (non représentée) de la carte DV1 , ou plus particulièrement dans un élément sécurisé de la carte à puce DV1.
[0088] La mémoire MR5 est une mémoire non volatile (Flash ou ROM par exemple), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par la carte bancaire DV1 , et sur lequel est enregistré un programme d’ordinateur PG3 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG3 comporte des instructions pour l’exécution de certaines étapes d’un procédé de traitement selon un mode de réalisation particulier qui sera décrit ultérieurement.
[0089] La mémoire MR6 est une mémoire non volatile réinscriptible (Flash par exemple) apte à stocker des données telles qu’un identifiant d’utilisateur IDUR correspondant à l’utilisateur U R ainsi qu’une clé de chiffrement (ou clé cryptographique) K1. La mémoire MR6 peut éventuellement stocker d’autres données telles que notamment des données d’historique DH ou un compteur CT1. L’usage et l’intérêt de ces données seront décrits ultérieurement.
[0090] Selon un exemple particulier, les mémoires MR5 et MR6 forment une seule et même mémoire.
[0091] L’interface de communication INT5 permet au terminal T1 de communiquer avec terminal T1 , et plus particulièrement avec son interface de communication INT2. La carte à puce DV1 peut par exemple comprendre des contacts externes (de type ISO 7816 par exemple) situés à la surface du corps de la carte. Dans ce cas, la liaison L2 est une liaison par contact. Le terminal T1 peut ainsi positionner des broches de contact appropriées sur les contacts externes de la carte afin d’établir une communication par contact avec la carte bancaire DV1. Selon un autre exemple, la carte à puce DV1 comprend une antenne (non représentée). Dans ce cas, la carte bancaire DV1 peut établir une liaison L2 sans contact avec le terminal T 1.
[0092] D’autre part, le serveur de gestion SV1 comprend un processeur 10, une première interface de communication INT10, une deuxième interface de communication INT 11 , une première mémoire MR10 et une deuxième mémoire MR11.
[0093] La mémoire MR10 est une mémoire non volatile (Flash ou ROM par exemple), cette mémoire constituant un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier, lisible par le serveur SV1 , et sur lequel est enregistré un programme d’ordinateur PG2 conforme à un mode de réalisation particulier. Ce programme d’ordinateur PG2 comporte des instructions pour l’exécution des étapes d’un procédé de gestion selon un mode de réalisation particulier qui sera décrit ultérieurement.
[0094] La mémoire MR11 est une mémoire non volatile réinscriptible (Flash par exemple) apte à stocker des données telles qu’un cryptogramme MC1 généré par la carte à puce DV1 , des données d’entrée DM1 utilisées par la carte à puce DV1 pour générer le cryptogramme MC1 , des données de transaction DTR1 représentatives de la transaction TR1 et la clé de chiffrement K1. L’usage et l’intérêt de ces données seront décrits ultérieurement.
[0095] Selon un exemple particulier, les mémoires MR10 et MR11 forment une seule et même mémoire.
[0096] La première interface de communication INT10 permet au serveur de gestion SV1 de communiquer avec le terminal T 1. Pour ce faire, la première interface de communication INT10 établit une liaison de communication L1 avec le terminal T1 , et plus particulièrement avec son interface de communication INT1. Comme déjà indiqué, cette liaison L1 peut être filaire ou sans fil, et peut être de toutes natures appropriées.
[0097] La deuxième interface de communication INT11 permet au serveur de gestion SV1 de transmettre à l’utilisateur UR un ticket électronique TK1 généré par le serveur de gestion SV1 , ce ticket électronique étant représentatif de la transaction TR1. Ce ticket électronique TR1 constitue un ticket (ou reçu) numérique comportant diverses informations relatives à la transaction TR1 telles que par exemple la date, le montant, l’identifiant du terminal, le résultat de la transaction, etc. La transmission de ce ticket TK1 peut se faire via toutes liaisons L3 appropriées, notamment par l’envoi d’un email ou d’un SMS.
[0098] Par ailleurs, comme représenté en figure 3 selon un mode de réalisation particulier, le processeur 2 du terminal T1 piloté par le programme d’ordinateur PG1 met ici en œuvre un certain nombre de modules, à savoir : un premier module de réception MD2, un premier module de transmission MD4, un second module de réception MD6, un second module de transmission MD8, et éventuellement un module de gestion de stockage MD10.
[0099] Plus précisément, le premier module de réception MD2 est configuré pour recevoir, en provenance de la carte bancaire DV1 , des premières données DT1 comprenant un identifiant d’utilisateur IDUR identifiant l’utilisateur UR associé à la carte bancaire DV1.
[0100] Le premier module de transmission MD4 est configuré pour transmettre, à la carte bancaire DV1 , des deuxièmes données DT2 comprenant au moins un identifiant de terminal IDT1 identifiant le terminal T1. Ces deuxièmes données DT2 peuvent comprendre d’autres données comme expliqué ultérieurement, telles que notamment des données de transaction DTR1 caractérisant la transaction TR1.
[0101] Le deuxième module de réception MD6 est configuré pour recevoir, en provenance de la carte bancaire DV1 , un cryptogramme MC1 généré à partir d’une clé de chiffrement K1 et à partir de données d’entrée DM1 comprenant au moins l’identifiant IDT1 du terminal T1 et l’identifiant d’utilisateur IDUR. Les données d’entrée DM1 peuvent comprendre d’autres données, comme décrit ultérieurement, telles que les données de transaction DTR1 mentionnées ci- avant. Le deuxième module de réception MD6 peut en outre transmettre à la carte bancaires DV1 les données d’entrée DM1 et d’autres données selon le cas d’usage, comme décrit ci-après.
[0102] Le second module de transmission MD8 est configuré pour transmettre, au serveur de gestion SV1 , une requête de génération de ticket électronique RQ1. Cette requête RQ1 comprend au moins le cryptogramme MC1 , les données d’entrée DM1 et des données de transaction DTR2 caractérisant la transaction TR1 , et vise à déclencher la génération par le serveur de gestion DV1 d’un ticket électronique TK1 représentatif de la transaction TR1 , à partir des données transmises par le terminal T1.
[0103] Le cas échéant, le module de gestion de stockage MD10 permet de gérer le stockage de données d’historique DH dans la mémoire MR6 de la carte bancaire DV1. Pour ce faire, le module de gestion de de stockage MD10 peut envoyer à la carte bancaire DV1 des commandes CMD4 ou CMD5 comme décrit plus en détail ultérieurement.
[0104] Par ailleurs, comme représenté en figure 4 selon un mode de réalisation particulier, le processeur 10 du serveur SV1 piloté par le programme d’ordinateur PG2 met ici en œuvre un certain nombre de modules, à savoir : un module de réception MD20, un premier module de génération MD22, un module de vérification MD24, un second module de génération MD26, et éventuellement un module de traitement MD28.
[0105] Plus précisément, le module de réception MD20 est configuré pour recevoir, en provenance du terminal T1 , le cryptogramme MC1 , les données d’entrée DM1 , les données de transaction DTR2 caractérisant la transaction TR1 ainsi que la requête de génération de ticket électronique RQ1. Comme déjà indiqué, le cryptogramme MC1 est préalablement généré par la carte à puce DV1 à partir des données d’entrées DM1 qui comprennent au moins l’identifiant d’utilisateur IDUR et l’identifiant de terminal IDT1.
[0106] Le premier module de génération MD22 est configuré pour générer un deuxième cryptogramme MC2 à partir d’une clé de déchiffrement et des données d’entrées DM1. Dans cet exemple la clé de déchiffrement est identique à la clé de chiffrement K1 utilisée par la carte bancaire DV1 pour générer le cryptogramme MC1.
[0107] Le module de vérification MD24 est configuré pour vérifier la validité de la requête de génération de ticket électronique RQ1 , et ce à partir d’une comparaison du premier cryptogramme MC1 reçu du terminal T1 avec le deuxième cryptogramme MC2 généré par le premier module de génération MD22.
[0108] Le second module de génération MD28 est configuré pour générer, si la requête RQ1 est valide, un ticket électronique TK1 représentatif de la transaction TR1 , à partir au moins des données d’entrée DM1 et / ou des données de transaction DTR2 reçues.
[0109] Le cas échéant, le module de traitement MD28 est configuré réaliser des traitements complémentaires tels que transmettre le ticket électronique TK1 à l’utilisateur UR et / ou à l’entité marchande MD, comme décrit par la suite.
[0110] Par ailleurs, comme représenté en figure 5 selon un mode de réalisation particulier, le processeur 4 de la carte bancaire DV1 piloté par le programme d’ordinateur PG3 met ici en œuvre un certain nombre de modules, à savoir : un premier module de transmission MD40, un module de réception MD42, un module de génération MD44, un second module de transmission MD46 et un module de stockage MD48.
[0111] Plus précisément, le premier module de transmission MD40 est configuré pour transmettre, au terminal T1 , les premières données DT1 comprenant au moins l’identifiant d’utilisateur IDUR identifiant l’utilisateur UR associé à la carte bancaire DV1.
[0112] Le module de réception MD42 est configuré pour recevoir, en provenance du terminal T1 , les deuxièmes données DT2 comprenant au moins l’identifiant de terminal IDT1 identifiant le terminal T1. Comme décrit plus en détail ultérieurement, les deuxièmes données peuvent comprendre d’autres données telles que les données de transaction DTR1 déjà mentionnées ci-avant.
[0113] Le module de génération MD44 est configuré pour générer le cryptogramme MC1 à partir de la clé de chiffrement K1 et des données d’entrée DM1 comprenant l’identifiant de terminal IDT1 et l’identifiant d’utilisateur IDUR (comme déjà indiqué).
[0114] Le second module de transmission MD46 est configuré pour transmettre, au terminal T1 , le cryptogramme MC1 et les données d’entrée DM1 pour permettre la transmission par le terminal T1 de la requête de génération de ticket électronique RQ1 au serveur de gestion SV1.
[0115] Le cas échéant, le module de stockage MD48 est configuré pour gérer le stockage, en local dans la mémoire MR6 de la carte bancaire DV1 , du cryptogramme MC1 ou encore de données d’historique DH, comme expliqué ci- après.
[0116] La configuration et le fonctionnement des modules MD2-MD10 du terminal T1 (figure 2), des modules MD20-MD28 du serveur de gestion SV1 (figure 3) et des modules MD40-MD48 de la carte bancaire DV1 (figure 4) apparaîtront plus précisément dans les exemples de réalisation décrits ci-après. On comprend que ces modules ne représentent qu’un exemple de mise en œuvre non limitatif de l’invention.
[0117] En variante, deux modules du terminal T1 , du serveur de gestion SV1 ou encore de la carte bancaire DV1 peuvent être mis en œuvre au sein d’un seul et même module, selon la configuration choisie. Ainsi, les premier et second modules de réception MD2, MD8 peuvent former un seul et même module du terminal T1 , l’identifiant d’utilisateur IDUR pouvant par exemple être transmis seulement dans les données d’entrée DM1. Il en va de même pour les premier et second modules de transmission MD40, MD46 de la carte bancaire DV1 , par exemple.
[0118] De manière générale, le terminal T1 , le serveur SV1 et la carte bancaire DV1 mettent chacun en œuvre un module respectif pour réaliser chaque opération ou étape d’un procédé correspondant de l’invention.
[0119] Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 6. Plus précisément, le terminal T1 et la carte bancaire DV1 mettent chacun en œuvre un procédé de traitement de l’invention en exécutant les instructions des programmes d’ordinateur PG1 et PG3, respectivement. De même, le serveur de gestion SV1 met en œuvre un procédé de gestion en exécutant les instructions du programme d’ordinateur PG2.
[0120] On suppose qu’une transaction EMV notée TR1 est initiée entre le terminal externe T1 et la carte bancaire CD1. Cette transaction TR1 fait appel à une coopération entre terminal T1 et la bancaire CD1 qui échangent ensemble des commandes ou messages conformément au standard EMV, comme déjà décrit dans un exemple particulier en figure 1.
[0121] Comme déjà indiqué, la transaction TR1 est une transaction de paiement EMV dans cet exemple. Plus particulièrement, on suppose que l’utilisateur U R utilise sa carte bancaire EMV DV1 pour réaliser la transaction de paiement TR1 auprès de l’enseigne commerçante MD. Pour ce faire, l’utilisateur U R insère sa carte bancaire DV1 dans le terminal T1 (transaction par contact) ou présente sa carte bancaire DV1 à proximité du terminal (transaction en sans contact).
[0122] Au cours d’une étape C4 de transmission, la carte bancaire C4 envoie au terminal T1 une commande CMD1 comportant une donnée DX1 indiquant que la carte bancaire DV1 supporte un service de tickets électroniques. Diverses manières de fournir cette donnée DX1 sont possibles. Selon un premier exemple, la commande CMD1 est une réponse de la carte bancaire DV1 à une commande SELECT APPLICATION envoyée préalablement par le terminal T1 conformément au standard EMV comme déjà décrit en référence à l’étape S6 de la figure 1.
[0123] Selon un deuxième exemple, la donnée DX1 peut être transmise dans la commande CMD1 sous la forme d’au moins un bit RFU (pour « Reserved for Future Use »), sous réserve qu’un tel bit RFU soit prévu par le standard EMV pour la commande CMD1 en question.
[0124] Selon un troisième exemple, la donnée DX1 est transmise dans une commande SELECT qui est envoyée par la carte bancaire DV1 au terminal T1 en réponse à une commande SELECT, comme déjà décrit en référence à l’étape S5b de la figure 1. Conformément au standard EMV, la commande SELECT est une réponse structurée selon le format TLV (pour « Tag-Length-Value ») et donc qui accepte d’être étendue avec des objets de données (dits « data objects » en anglais) supplémentaires. Selon ce troisième exemple, la commande SELECT comprend ainsi un tel objet supplémentaire de type TLV qui comprend la donnée DX1. Cet objet supplémentaire comporte un tag (qui identifie de manière unique l’objet), une longueur et une valeur.
[0125] Selon un quatrième exemple, cette donnée DX1 peut être transmise par la carte bancaire DV1 suite à la commande GET PROCESSING OPTIONS (GPO) envoyée par le terminal T1 , par exemple dans des données RECORD lues par le terminal T1 dans la carte bancaire DV1 lors d’une phase de lecture S8 de RECORDS déjà décrite en référence à la figure 1.
[0126] Le terminal T1 reçoit la commande CMD1 lors d’une étape B4 de réception.
Le terminal T1 détermine ainsi, à partir de la donnée DX1 , que la carte bancaire DV1 supporte un service de ticket électronique et en déduit que le procédé de l’invention peut être poursuivi comme expliqué ci-après.
[0127] Dans l’exemple considéré ici, lors de cette phase S8 de lecture, le terminal T1 envoie (B6) ainsi une requête RC1 que la carte bancaire DV1 reçoit lors d’une étape C6 de réception. En réponse à cette requête RC1 , la carte bancaire DV1 transmet (C8) au terminal T1 , en tant que RECORDS, des premières données DT1 comprenant au moins un identifiant d’utilisateur IDUR identifiant l’utilisateur U R associé à la carte bancaire DV1. Ces premières données DT1 peuvent éventuellement comprendre d’autres données telles qu’une adresse AD1 , correspondant au serveur SV1 , dont l’usage sera décrit ultérieurement.
[0128] Selon un exemple particulier, l’identifiant d’utilisateur IDUR est différent d’un identifiant de type PAN (pour « Primary Account Number ») associé à la carte bancaire DV1 . De manière avantageuse, cela permet de limiter la diffusion du PAN qui constitue une donnée sensible.
[0129] Le terminal T1 reçoit les premières données DT1 en B8. Le procédé se poursuit avec une phase S20 facultative d’authentification de l’utilisateur UR. Au cours de cette phase S20, le terminal T1 et la carte bancaire DV1 coopèrent par exemple ensemble pour vérifier le code personnel, dit code PIN, du porteur UR de la carte bancaire DV1 . Comme déjà décrit en référence à la figure 1 , d’autres modes de réalisation sont toutefois possibles dans lesquels le code PIN n’est pas vérifié, notamment lors d’une transaction de paiement sans contact.
[0130] Toujours en référence à la figure 6, le traitement de la transaction TR1 se poursuit avec une phase de vérification de la transaction, au cours de laquelle le terminal T1 réalise (B12) une analyse de risque (dite « Terminal Risk Management »), conformément au protocole EMV.
[0131] Après cette analyse B12, le terminal T1 transmet (B14) à la carte bancaire DV1 des deuxièmes données DT2 comprenant au moins un identifiant de terminal IDT1 identifiant le terminal T1. Ces deuxièmes données DT2 peuvent éventuellement comprendre d’autres données, telles qu’un identifiant IDMD identifiant l’entité marchande MD et / ou des données de localisation LOC spécifiant une position de cette entité marchande MD. Cette donnée LOC indique par exemple la position géographique de l’enseigne commerçante MD où se trouve le terminal T 1 .
[0132] Ces deuxièmes données DT2 peuvent par exemple être envoyées par le terminal T1 dans la commande GAC1 ou dans la commande GAC2, ces commandes étant toutes deux prévues dans le protocole EMV comme déjà décrit en référence respectivement aux étapes S9 et S16 de la figure 1.
[0133] La carte bancaire DV1 reçoit les deuxièmes données DT2 en C14 (figure 6) puis procède à une étape C16 de génération au cours de laquelle elle génère un cryptogramme MC1 à partir d’une clé de chiffrement K1 et de données d’entrée DM1 comprenant au moins l’identifiant de terminal IDT1 et l’identifiant d’utilisateur IDUR. Dans l’exemple considéré ici, le cryptogramme est un code MAC (pour « Message Authentification Code »). Comme décrit par la suite, ce code MC1 a pour objet de sécuriser le service de ticket électronique.
[0134] Les données d’entrées DM1 prises en compte par la carte bancaire DV1 pour générer le cryptogramme MC1 peuvent comprendre des données supplémentaires, notamment d’autres données également fournies par le terminal T1 dans les deuxièmes données DT2.
[0135] Dans le cas où le terminal T1 transmet en B14, dans les deuxièmes données DT2, l’identifiant de marchand IDMD et éventuellement la donnée de localisation LOC (déjà mentionnée) qui spécifie une position de l’entité marchande MD, alors la carte bancaire DV1 peut prendre en compte, en tant que données d’entrée DM1 , l’identifiant de marchand IDMD et éventuellement la donnée de localisation LOC dans la génération C16 du cryptogramme MC1.
[0136] Selon un exemple particulier, les deuxièmes données DT2 transmises en B14 par le terminal T1 comprennent également des données de transaction DTR1 représentatives de la transaction TR1 en cours. Dans ce cas, ces données de transaction DTR1 peuvent également être incluses dans les données d’entrée DM1 utilisées par la carte bancaire DV1 pour générer le cryptogramme MC1. Ces données DTR1 peuvent comprendre par exemple au moins l’un parmi : la date et / ou l’heure de la transaction TR1 , le montant de la transaction TR1 et la devise utilisée.
[0137] Selon un exemple particulier, chacune des données IDMD, LOC et DTR1 qui sont effectivement transmises à la carte bancaire DV1 dans les deuxièmes données DT2 sont utilisées en tant que données d’entrée DM1 par la carte bancaire DV1 pour générer le cryptogramme MC1 en C16. La prise en compte de ces données additionnelles permet de sécuriser d’avantage le procédé de l’invention.
[0138] Selon un exemple particulier, chacune des données transmises par le terminal T1 dans les deuxièmes données DT2 en B14 peut avoir été demandée au préalable par la carte bancaire DV1 , lors de la phase S8 de lecture, dans une liste CDOL (pour « Card Risk Management Data Object List ») conformément au protocole EMV. Ainsi, la carte bancaire DV1 peut demander dans la liste CDOL transmise en tant que RECORD en S8 que le terminal T1 lui transmette l’identifiant de terminal IDT1 , et éventuellement au moins l’une des données supplémentaires mentionnées ci-avant (IDMD, LOC et DTR1). L’envoi des deuxièmes données DT2 (B14) par le terminal T1 se fait alors en réponse à cette demande préalable de la carte bancaire DV1.
[0139] Selon un exemple particulier, la carte bancaire DV1 prend également en compte, en tant que données d’entrées CT1 , la valeur courante d’un compteur CT1 qui est incrémenté par la carte bancaire DV1 à chaque nouvelle transaction. Comme déjà indiqué, ce compteur CT 1 est stocké localement dans la mémoire MR6 (figure 2) de la carte bancaire DV1. L’utilisation d’un tel compteur CT1 permet de s’assurer que la valeur du cryptogramme généré en C16 (figure 6) varie à chaque transaction, améliorant ainsi encore d’avantage la sécurité du procédé de l’invention.
[0140] Selon une variante de réalisation, CT1 est une valeur aléatoire qui est générée par la carte bancaire DV1 à chaque nouvelle transaction. Comme indiqué ci-dessus, L’utilisation d’une telle valeur aléatoire permet de s’assurer que la valeur du cryptogramme généré en C16 (figure 6) varie à chaque transaction, améliorant ainsi encore d’avantage la sécurité du procédé de l’invention.
[0141] La carte bancaire DV1 transmet (C18) ensuite au terminal T1 une commande CMD2 comportant le cryptogramme MC1 ainsi que les données d’entrée DM1 pour permettre au terminal T1 de transmettre par la suite une requête de génération de ticket électronique au serveur de gestion SV1 , comme expliqué ci- après.
[0142] Selon un exemple particulier, cette commande CMD2 est envoyée par la carte bancaire DV1 en réponse à la commande GAC1 ou à la commande GAC2 qui ont déjà été décrites précédemment en référence respectivement aux étapes S9 et S16 de la figure 1. Cette commande CMD2 peut être envoyée au stade de la réponse TC ou AAC déjà décrite précédemment en référence à l’étape S18 de la figure 1. [0143] Selon un exemple particulier, la carte bancaire DV1 génère également une signature électronique pour valider la transaction TR1 en cours. Dans ce cas, cette signature électronique est également transmise (C18) au terminal T1 dans la commande CMD2. Cette signature électronique peut être générée par la carte bancaire DV1 à partir d’une clé de chiffrement autre que K1.
[0144] Comme déjà mentionné, la carte bancaire DV1 peut également contenir dans sa mémoire locale MR6 des données d’historique DH, notée ici DHO, associées à au moins une transaction TRO antérieure traitée par ladite carte DV1. Ces données d’historique DHO sont par exemple stockées localement dans la carte bancaire DV1 (dans MR6) lorsqu’il n’est pas possible de déclencher la génération d’un ticket électronique correspondant, comme expliqué ultérieurement. Ces données d’historique DHO peuvent comprendre, en association avec au moins une transaction antérieure TRO, un cryptogramme antérieur MCO, des données antérieures MDO et des données de transaction antérieures DTRO caractérisant ladite transaction antérieure TRO, le cryptogramme antérieur MCO ayant été généré par la carte bancaire DV1 à partir de la clé de chiffrement K1 et des données d’entrée antérieures DM0 (de façon identique à ce qui est décrit ci-avant en référence à l’étape C16).
[0145] Selon un exemple particulier, la carte bancaire DV1 transmet également en C18 les données d’historique DHO au terminal T1 (dans la commande CMD2 par exemple) afin de requérir la génération d’un ticket électronique d’au moins une transaction antérieure TRO.
[0146] Toujours en référence à la figure 6, le terminal T1 reçoit la commande CMD2 en B18 puis transmet au serveur de gestion SV1 une requête de génération de ticket électronique RQ1 comprenant au moins le cryptogramme MC1 , les données d’entrée DM1 et des données de transaction DTR2 caractérisant la transaction TR1 , pour requérir la génération par le serveur de gestion SV1 d’un ticket électronique représentatif de la transaction à partir des données transmises par le terminal T1.
[0147] Les données de transaction DTR2 peuvent comprendre tout ou partie des données de transaction DTR1. Dans un exemple particulier, les données de transaction DTR1 et DTR2 sont identiques. La nature et le nombre des données de transaction TR2 (date / heure, montant, devise...) que le terminal T2 choisit de fournir au serveur SV1 peuvent être adaptés selon le cas.
[0148] Dans le cas particulier où la carte bancaire DV1 a précédemment transmis, au terminal T1 , dans les premières données DT1 (étape C8, figure 6) une adresse AD1 correspondant au serveur de gestion SV1 , le terminal T1 peut utiliser cette adresse AD1 pour envoyer la requête RQ1 à destination du serveur de gestion SV1. Cette adresse AD1 peut être une adresse URL ou toute autre information permettant au terminal T1 de se connecter avec le serveur SV1.
[0149] Selon un exemple particulier, le terminal T1 inclus dans sa requête de génération de ticket électronique RQ1 un message MSG1 que le serveur de gestion SV1 doit prendre en compte pour générer un ticket électronique. Il est ainsi possible de personnaliser le ticket électronique en fonction de l’enseigne commerçante MD associée au terminal T 1.
[0150] Dans le cas particulier où le terminal T1 a également reçu en B18 (figure 6) les données d’historique DH0 stockées localement dans la carte bancaire DV1 , il peut aussi transmettre en B20, au serveur de gestion DV1 , en accompagnement de la requête RQ1 , les données d’historique DH0 pour requérir en outre la génération d’au moins un ticket électronique supplémentaire à partir de ces données d’historique DH0. Il est ainsi possible d’obtenir un ou des tickets électroniques relatifs à au moins une transaction antérieure TR0 dans le cas où il n’a pas été possible de les obtenir plus tôt, par exemple lors d’un traitement hors ligne d’une transaction EMV ou en raison d’un problème de connexion des terminaux qui ont traité les transaction antérieures avec un serveur de gestion.
[0151] Dans le cas particulier où le terminal T1 reçoit en B18 (figure 6) une signature électronique générer par la carte bancaire DV1 , celle-ci est également transmise en B20 au serveur de gestion DV1 avec la requête RQ1. Cette signature électronique permet au serveur de gestion DV de vérifier ultérieurement que la transaction TR1 est valide, comme expliqué ci-après.
[0152] Dans l’exemple considéré en figure 6, la requête RQ1 transmise par le terminal T1 en B20 comprend ainsi une concaténation du cryptogramme MC1 , des données d’entrée DM1 , des données de transaction DTR2 et éventuellement d’au moins l’une des données supplémentaires mentionnées ci-avant (MSG1 , DHO, SG1).
[0153] Le serveur de gestion SV1 reçoit la requête RQ1 et toutes les données associées en A20 (figure 6).
[0154] Au cours d’une étape A22 de génération, le serveur SV1 génère un deuxième cryptogramme MC2 à partir de la clé de déchiffrement K1 (identique dans cet exemple à la clé de chiffrement utilisé en C16 par la carte bancaire DV1 ) et à partir des données d’entrée DM1 reçues en A20 (figure 6). Pour ce faire, il procède de la même manière que la carte bancaire DV1 pour générer le cryptogramme MC1 en C16. Dans l’exemple considéré ici, le cryptogramme MC2 est donc un code MAC.
[0155] Le serveur de gestion SV1 vérifie (A24) ensuite la validité de la requête de génération de ticket électronique RQ1 , à partir d’une comparaison du premier cryptogramme MC1 reçu en A20 avec le deuxième cryptogramme MC2 calculé en A22. Grâce à cette vérification de cryptogramme, il est possible de sécuriser le processus de gestion de tickets électroniques dans la mesure où une demande de ticket électronique n’est acceptée que si le cryptogramme MC1 est valide.
[0156] Si les cryptogrammes MC1 et MC2 coïncident (MC1 = MC2), alors le procédé se poursuit à l'étape A28 de génération. Dans le cas contraire, le serveur de gestion DV1 bloque la génération d’un ticket électronique et transmet (A26) éventuellement un message négatif MSG2 indiquant que la requête RQ1 est refusée.
[0157] Au cours de l’étape A28 de génération, le serveur de gestion SV1 génère alors un ticket électronique TK1 représentatif de la transaction TR1 , et ce à partir au moins des données d’entrées DM1 et des données de transaction DTR2 reçues. Ce ticket électronique TK1 , appelé aussi e-ticket ou billet électronique, constitue un ticket dématérialisé qui remplace un ticket traditionnel par des informations numériques représentatives de la transaction TR1.
[0158] Le format du ticket électronique TK1 et la nature des informations qu’il contient peuvent varier selon le cas. Le ticket électronique TK1 comprend par exemple des données de type texte et / ou des données de type image. Le ticket électronique TK1 peut prendre la forme d’un fichier par exemple.
[0159] Selon un exemple particulier, le ticket électronique TK1 comprend au moins l’une parmi les données suivantes :
- les données de transaction DTR2 caractérisant la transaction TR1 ;
- l’identifiant de terminal IDT1 associé au terminal T1 ;
- l’identifiant d’utilisateur IDUR associé à l’utilisateur UR ;
- l’identifiant de marchand IDMD associé à l’enseigne commerçante MD ;
- la donnée de localisation LOC spécifiant une position de l’entité marchande MD ;
- le message prédéfini MSG1 associé à l’enseigne commerçante MD ; et
- un identifiant de type PAN, partiel ou complet, associé à la carte bancaire DV1.
[0160] Les données de transaction DTR2 peuvent comprendre au moins l’un parmi : la date et / ou heure de la transaction TR1 , le montant de la transaction TR1 , la devise utilisée, et le résultat de la transaction (réussie ou échouée). Le serveur de gestion DV1 peut éventuellement vérifier la validité de la signature électronique SG1 générée par la carte bancaire (lorsqu’une telle signature est effectivement générée et transmise au serveur de gestion SV1) et déduire de cette vérification le résultat de la transaction TR1.
[0161] Dans le cas particulier où le serveur de gestion SV a reçu les données d’historique DH0 relatives à au moins une transaction antérieure TR0 (comme déjà indiqué), il peut également générer un ticket électronique TKO pour chaque transaction antérieure TRO spécifiée dans ces données d’historique DHO. Cela permet à l’utilisateur U R d’obtenir un ticket électronique pour des transactions antérieures traitées en mode hors ligne par exemple, et donc où la connexion avec un serveur en charge de la gestion des tickets électroniques n’était pas possible.
[0162] Par la suite, le serveur de gestion SV1 peut réaliser toutes opérations de gestion appropriées en relation avec le ticket électronique TK1 ainsi généré (et, le cas échéant, avec le ou les tickets électroniques TKO des transactions antérieures).
[0163] Selon un exemple particulier, le serveur de gestion SV1 envoie (A30) par la suite le ticket électronique TK1 à l’utilisateur U R via la liaison de communication L3 (figure 2). Le serveur SV1 envoie par exemple le ticket électronique TK1 via un email ou un SMS. De la même manière, le serveur SV1 peut également transmettre à l’utilisateur UR le ou les éventuels tickets électroniques additionnels qu’il a générés, le cas échéant, en lien avec au moins une transaction antérieure TRO. Le serveur de gestion SV1 détermine à quelle adresse AD2 le ou les tickets électroniques doivent être envoyés à partir de l’identifiant d’utilisateur IDUR. Cette adresse AD2 peut être par exemple une adresse email ou un numéro de téléphone. Le serveur de gestion SV1 peut ainsi stocker dans sa mémoire une table associant pour une pluralité d’utilisateurs une adresse associée vers laquelle les tickets électroniques doivent être transmis.
[0164] Selon un exemple particulier, le serveur de gestion SV1 reçoit en A20 (figure
6), en provenance du terminal T1 , la requête de génération de ticket électronique RQ1 , le cryptogramme MC1 , les données d’entrée DM1 , les données de transaction DTR2 et toutes autres éventuelles données associées via un premier canal de communication (L1). La transmission A30 du ticket électronique TK comme indiqué ci-avant peut alors être réalisée via un deuxième canal de communication différent du premier canal de communication. Par exemple, le serveur SV1 communique (A20) avec le terminal T1 via un réseau de télécommunication, et envoie (A30) le ticket électronique TK1 via un SMS, un email ou autre.
[0165] De manière alternative ou cumulative, le serveur de gestion SV1 peut également envoyer le ticket électronique TK1 à l’entité marchande MD de façon analogue à l’étape A30 d’envoi. Pour ce faire, le serveur SV1 peut envoyer le ticket électronique TK1 au terminal T1 (via la liaison L1 par exemple).
[0166] Selon un exemple particulier, le serveur de gestion SV1 transmet (A32) au terminal T 1 un message positif MSG3 indiquant que la requête de génération de ticket électronique RQ1 est acceptée. Le terminal T1 reçoit cette réponse positive MSG3 en B32. [0167] Selon un exemple particulier, sur réception de la réponse positive MSG3 du serveur de gestion SV1 à la requête RQ1 , le terminal T1 envoie (B34) en outre à la carte bancaire DV1 une commande de suppression CMD4 pour commander la suppression dans la mémoire locale MR6 de la carte bancaire DV1 des données d’historique DHO. Le terminal T1 peut éventuellement déclencher l’envoi B34 de la commande de suppression CMD4 si le message positif MSG3 inclus une information indiquant que les données d’historique DHO ont été prises en charge avec succès par le serveur de gestion DV1.
[0168] La carte bancaire DV1 reçoit la commande de suppression CMD4 lors d’une étape C34 de réception. Sur détection de cette commande CMD4, la carte bancaire DV1 supprime dans sa mémoire locale MR6 les données d’historique DHO.
[0169] L’invention permet une gestion efficace des tickets électroniques générés lors de transactions bancaires, de type EMV par exemple, de sorte à garantir la confidentialité des porteurs de cartes bancaires tout en assurant un traitement rapide et fiable des transactions.
[0170] Cette solution est écologique et permet de réduire les coûts liés à la production de tickets traditionnels, tout en permettant une meilleure gestion des tickets par l’utilisateur qui n’a plus besoin de stocker les tickets physiques.
[0171] Plus particulièrement, le serveur de gestion de l’invention, agissant en tant que tiers de confiance, est capable de prendre en charge une requête de génération de ticket électronique fournie par un terminal coopérant lors d’une transaction avec une carte bancaire (ou plus généralement avec un dispositif électronique). Le serveur de gestion peut vérifier la validité de la demande et déterminer à partir d’un identifiant d’utilisateur reçu depuis le terminal, vers quelle adresse le ou les tickets électroniques générés doivent être transmis. Il est ainsi possible d’éviter les erreurs de saisie, d’accélérer le traitement des transactions, tout en garantissant la sécurité du processus ainsi que la confidentialité des consommateurs vis-à-vis des enseignes commerçantes.
[0172] Par ailleurs, dans le mode de réalisation décrit en référence à la figure 6, le terminal T1 est capable de déclencher la génération d’un ticket électronique dans la mesure où une connexion (liaison L1 , figure 1) peut être établie entre le terminal T1 et le serveur de gestion SV1. En revanche, on peut envisager que dans certains cas le terminal T 1 ne sera pas en mesure de communiquer avec le serveur de gestion SV1 , par exemple dans le cas d’une transaction en mode hors ligne ou en raison d’un problème d’accès au réseau de communication ou encore d’une panne du serveur de gestion SV1.
[0173] Par ailleurs, le serveur de gestion SV1 peut décider de refuser de traiter la requête de génération de ticket électronique TK1 pour diverses raisons (problème technique, ressources insuffisantes...).
[0174] On décrit à présent en référence à la figure 7 un mode de réalisation particulier de l’invention dans lequel la requête de génération de ticket électronique RQ1 (figure 6) transmise par le terminal T1 n’est pas traitée avec succès par le serveur de gestion SV1.
[0175] Suite à l’envoi B20 (figure 6) de la requête RQ1 , le terminal vérifie (B40) s’il détecte la réception depuis le serveur de gestion SV1 d’une réponse positive. Comme indiqué ci-avant, la requête de génération de ticket électronique RQ1 peut ne pas être traitée avec succès par le serveur de gestion SV1 pour diverses raisons.
[0176] En l’absence d’une réponse positive MSG3 à la requête de génération de ticket (i.e. en cas d’absence de réponse du serveur de gestion SV1 ou d’une réponse négative MSG2), par exemple dans un délai prédéfini, le terminal T1 transmet (B42) à la carte bancaire DV1 une commande de stockage CMD5 requérant le stockage, dans une mémoire locale de ladite carte (i.e. MR6 dans cet exemple), de données d’historique notées DH1 pour permettre une transmission d’une requête ultérieure de génération de ticket électronique lors d’une transaction ultérieure. Cette requête ultérieure pourra faire intervenir le terminal T1 et / ou le serveur de gestion SV1 ou de quelconques autres terminaux et serveur de gestion prévus à cet effet. A cette fin, les données d’historique DH1 , associées à la transaction TR1 , comprennent au moins le cryptogramme MC1 , les données d’entrée DM1 , les données de transaction DTR2, et toutes éventuelles autres informations pertinentes.
[0177] La carte bancaire DV1 reçoit cette commande de stockage CMD5 lors d’une étape C42 de réception. La carte bancaire DV1 procède alors à l’enregistrement (C44) localement dans sa mémoire MR6 des données d’historique DH1 associées à la transaction TR1.
[0178] La carte bancaire DV1 peut ainsi stocker localement les données d’historique nécessaires à la génération ultérieure d’un ticket électronique. La génération de ce e-ticket est ainsi différée jusqu’à ce qu’une requête ultérieure de ticket électronique soit acceptée et traitée par un serveur de gestion lors d’une transaction ultérieure. Cette variante permet de ne pas perdre les données permettant de créer un ticket électronique lorsqu’un problème empêche d’obtenir immédiatement un tel ticket électronique depuis le serveur de gestion concerné.
[0179] Selon un exemple particulier, la carte bancaire DV1 vérifie si elle dispose d’un espace mémoire suffisant (dans sa mémoire MR6) avant l’étape C44 d’enregistrement. Elle ne procède ainsi à cet enregistrement C44 que si elle dispose d’un espace mémoire suffisant.
[0180] On décrit à présent en référence à la figure 8 un mode de réalisation particulier de l’invention dans lequel la carte bancaire DV1 bloque dans certains cas la transmission du cryptogramme MC1 permettant au terminal T1 de demander au serveur de gestion SV1 la création d’un ticket électronique.
[0181] Plus précisément, comme déjà décrit en référence à la figure 6, on suppose que la carte bancaire DV1 reçoit en C14 notamment l’identifiant de marchand IDMD dans les deuxièmes données DT2 transmises par le terminal T 1.
[0182] Après avoir déterminé (C14) l’identifiant de marchand IDMD associé à l’entité marchande MD, la carte bancaire DV1 vérifie (C50) si cet identifiant correspond à un marchand prédéfini. Pour ce faire, la carte bancaire DV1 compare par exemple l’identifiant de marchand IDMD avec une liste d’au moins un identifiant de marchand prédéfini. Si l’identifiant de marchand IDMD reçu correspond à un marchand prédéfini, le procédé se poursuit à l’étape C52 de blocage. Sinon, le procédé se poursuit avec les étapes C16 puis C18, comme déjà décrit ci-avant en référence à la figure 6.
[0183] A l’étape C52 (figure 8), la carte bancaire DV1 bloque la génération (C16) du cryptogramme MC1. Par voie de conséquence, la carte bancaire DV1 ne transmet pas en C18 le cryptogramme MC1 et les données associées au terminal T1 comme décrit ci-avant en référence à la figure 6. En revanche, la carte bancaire DV1 peut envoyer au terminal T 1 une indication de refus de ticket électronique.
[0184] Autrement dit, la carte bancaire DV1 vérifie (C50) si l’identifiant de marchand IDMD correspond à un marchand prédéfini et ne transmet en C18 (figure 6) le cryptogramme MC1 au terminal T1 que si l’entité marchande MD ne correspond pas à un marchand prédéfini.
[0185] Il est ainsi possible de mettre en œuvre un mécanisme de masquage pour éviter la génération d’un ticket électronique lorsque ce service n’est pas souhaité par l’utilisateur UR pour des raisons de sécurité ou confidentialité liées au marchand MD.
[0186] On décrit à présent en référence à la figure 9 un mode de réalisation particulier de l’invention dans lequel la carte bancaire DV1 bloque dans certains cas le stockage dans sa mémoire locale de données visant à générer ultérieurement un ticket électronique.
[0187] Plus précisément, comme déjà décrit en référence à la figure 6, on suppose que la carte bancaire DV1 reçoit en C14 notamment l’identifiant de marchand IDMD dans les deuxièmes données DT2 transmises par le terminal T1.
[0188] Après avoir déterminé (C14) l’identifiant de marchand IDMD associé à l’entité marchande MD, on suppose également que la carte bancaire DV1 reçoit une commande CMD5 de stockage comme déjà décrit ci-avant en référence à la figure 7.
[0189] Au cours d’une étape C60, la carte bancaire DV1 vérifie si l’identifiant de marchand IDMD reçu correspond à un marchand prédéfini. Pour ce faire, la carte bancaire DV1 compare par exemple l’identifiant de marchand IDMD avec une liste d’au moins un identifiant de marchand prédéfini. Si l’identifiant de marchand IDMD reçu correspond à un marchand prédéfini, le procédé se poursuit à l’étape C62 de blocage. Sinon, le procédé se poursuit à l’étape C44 au cours de laquelle la carte bancaire DV1 enregistre localement les données d’historique DH1 , comme déjà décrit ci-avant en référence à la figure 7.
[0190] A l’étape C62 (figure 9), la carte bancaire DV1 bloque l’enregistrement dans sa mémoire locale MR6 des données d’historique DH1. La carte bancaire DV1 peut envoyer au terminal T1 une indication de refus de stockage des données d’historique DH1 .
[0191] Autrement dit, la carte bancaire DV1 vérifie (C60) si l’identifiant de marchand IDMD correspond à un marchand prédéfini et ne procède au stockage en C44 (figure 7) des données d’historique DH1 dans sa mémoire locale MR6 que si l’entité marchande MD ne correspond pas à un marchand prédéfini.
[0192] Il est ainsi possible de mettre en œuvre un mécanisme de masquage pour éviter le stockage localement dans la carte bancaire DV1 de données d’historique permettant la génération ultérieure d’un ticket électronique associé à la transaction concernée. Un tel blocage est par exemple réalisé lorsque le service d’e-ticket n’est pas souhaité par l’utilisateur UR pour des raisons de sécurité ou confidentialité liées au marchand MD.
[0193] Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l’invention. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier.

Claims

Revendications
[Revendication 1] Procédé de traitement mis en œuvre par un terminal (Tl) pour traiter une transaction bancaire (TRI) en coopération avec un dispositif électronique (DV1), ledit procédé comprenant :
- réception, en provenance du dispositif électronique, de premières données (DTI) comprenant un identifiant d'utilisateur (IDUR) identifiant un utilisateur associé au dispositif électronique ;
- transmission, au dispositif électronique, de deuxièmes données (DT2) comprenant un identifiant de terminal (IDT1) identifiant le terminal (Tl) ;
- réception, en provenance du dispositif électronique, d'un cryptogramme (MCI) généré à partir d'une clé de chiffrement (Kl) et de données d'entrée (DM1) comprenant l'identifiant de terminal (IDT1) et l'identifiant d'utilisateur (IDUR) ; et
- transmission, à un serveur de gestion (SV1), d'une requête de génération de ticket électronique (RQ1) comprenant le cryptogramme, les données d'entrée et des données de transaction (DTR2) caractérisant la transaction (TRI), pour requérir la génération par le serveur de gestion d'un ticket électronique représentatif de la transaction à partir des données transmises par le terminal.
[Revendication 2] Procédé selon la revendication 1, dans lequel les premières données (DTI) transmises par le dispositif électronique (Tl) comprennent une adresse (ADI) du serveur de gestion,
le terminal utilisant ladite adresse pour transmettre la requête de génération de ticket électronique (RQ1) audit serveur de gestion.
[Revendication 3] Procédé selon la revendication 1 ou 2, dans lequel les deuxièmes données, transmises au dispositif électronique, comprennent en outre au moins l'un parmi : a) un identifiant de marchand (IDMD) identifiant une entité marchande (MD) associée au terminal ;
b) une donnée de localisation (LOC) spécifiant une position de ladite entité marchande (MD) ;
c) des données de transaction (DTR1) caractérisant la transaction ; dans lequel chacune desdites données a), b) et c) qui est effectivement transmise au dispositif électronique est utilisée en tant que donnée d'entrée par le dispositif électronique pour générer le cryptogramme (MCI).
[Revendication 4] Procédé selon l'une quelconque des revendications 1 à 3, dans lequel le cryptogramme est un code MAC.
[Revendication 5] Procédé selon l'une quelconque des revendications 1 à 4, dans lequel en l'absence d'une réponse positive à la requête de génération de ticket, le terminal transmet au dispositif électronique une commande de stockage requérant le stockage, dans une mémoire locale (MR6) du dispositif électronique, de données d'historique (DH1) comprenant le cryptogramme (MCI), les données d'entrée (DM1) et les données de transaction (DTR1) pour permettre une transmission d'une requête ultérieure de génération de ticket électronique lors d'une transaction ultérieure.
[Revendication 6] Procédé selon l'une quelconque des revendications 1 à 5, dans lequel le procédé comprend en outre :
- réception, en provenance du dispositif électronique, de données d'historique (DHO) stockées dans une mémoire locale (MR6) du dispositif électronique et associées à au moins une transaction antérieure ; et
- transmission, au serveur de gestion, en accompagnement de la requête de génération de ticket électronique, des données d'historique pour requérir en outre la génération d'au moins un ticket électronique supplémentaire à partir desdites données d'historique.
[Revendication 7] Procédé selon la revendication 6, dans lequel les données d'historique (DHO) comprennent, en association avec chaque transaction antérieure : un cryptogramme antérieur (MCO), des données d'entrée antérieures (DM0) et des données de transaction antérieures (DTRO) caractérisant ladite au moins une transaction antérieure, ledit cryptogramme antérieur ayant été généré par ledit dispositif électronique à partir de la clé de chiffrement et des données d'entrée antérieures associées.
[Revendication 8] Procédé selon la revendication 6 ou 7, le procédé comprenant en outre :
- réception d'une réponse positive (MSG2) du serveur de gestion à ladite requête de génération de ticket électronique ; et
- sur détection de la réponse positive, transmission au dispositif électronique d'une commande de suppression (CMD4) pour commander la suppression dans la mémoire locale du dispositif électronique desdites données d'historique (DHO).
[Revendication 9] Procédé de gestion mis en œuvre par un serveur de
gestion (SV1) coopérant avec un terminal (DV1) destiné à traiter une transaction bancaire (TRI), ledit procédé comprenant les étapes suivantes : réception, en provenance du terminal, d'un premier cryptogramme (MCI), de données d'entrée (DM1), de données de transaction (DTR2)
caractérisant la transaction (TRI) ainsi que d'une requête de génération de ticket électronique (RQ1),
dans lequel le premier cryptogramme (MCI) a été généré par un dispositif électronique (DV1) à partir des données d'entrées qui comprennent un identifiant d'utilisateur (IDUR) identifiant un utilisateur et un identifiant de terminal (IDT1) identifiant le terminal ;
- génération d'un deuxième cryptogramme (MC2) à partir d'une clé de
déchiffrement (Kl) et des données d'entrées (DM1) ; - vérification de la validité de la requête de génération de ticket
électronique (RQ1), à partir d'une comparaison du premier cryptogramme (MCI) avec le deuxième cryptogramme (MC2) ; et
- si ladite requête est valide, génération d'un ticket électronique (TK1)
représentatif de la transaction, à partir au moins des données d'entrée (DM1) et des données de transaction (DTR1) reçues.
[Revendication 10] Procédé selon la revendication 9, dans lequel le ticket électronique comprend au moins l'une parmi les données suivantes :
a) les données de transaction (DTR2) caractérisant la transaction (TRI) ; b) l'identifiant de terminal (IDT1) ;
c) l'identifiant d'utilisateur (IDUR) ;
d) un identifiant de marchand (IDMD) identifiant une entité marchande (MD) associée au terminal ;
e) une donnée de localisation (LOC) spécifiant une position de ladite entité marchande (MD) ;
f) un message prédéfini associé à ladite entité marchande ; et
g) un identifiant de type PAN, partiel ou complet, associé au dispositif électronique.
[Revendication 11] Procédé selon la revendication 9 ou 10, dans lequel le serveur de gestion reçoit le cryptogramme (MCI), les données d'entrée (DM1), les données de transaction (DTR1) ainsi que la requête de génération de ticket électronique (RQ1) en provenance du terminal (Tl) via un premier canal de communication ;
le procédé comprend en outre :
- envoi du ticket électronique audit utilisateur via un deuxième canal de communication différent du premier canal de communication.
[Revendication 12] Procédé de traitement mis en oeuvre par un système (SI) comprenant un terminal (Tl) et un dispositif électronique (DV1) coopérant ensemble pour traiter une transaction bancaire (TRI), dans lequel le terminal réalise les étapes d'un procédé selon l'une quelconque des revendications 1 à 8,
dans lequel le dispositif électronique (DV1) réalise les étapes suivantes :
- transmission, au terminal, de premières données comprenant un identifiant d'utilisateur (IDUR) identifiant un utilisateur associé au dispositif électronique ;
- réception, en provenance du terminal, de deuxièmes données (DT2) comprenant un identifiant de terminal (IDT1) identifiant le terminal ;
- génération d'un cryptogramme (MCI) à partir d'une clé de chiffrement (Kl) et de données d'entrée (DM1) comprenant l'identifiant de terminal et l'identifiant d'utilisateur ; et
- transmission, au terminal, du cryptogramme (MCI) et des données d'entrée (DM1) pour permettre la transmission par le terminal d'une requête de génération de ticket électronique à un serveur de gestion.
[Revendication 13] Procédé selon la revendication 12, dans lequel le dispositif électronique génère en outre le cryptogramme (MCI) à partir de la valeur courante d'un compteur (CTI), la valeur dudit compteur étant incrémenté par le dispositif électronique à chaque nouvelle transaction ;
dans lequel le dispositif électronique transmet en outre, en tant que données d'entrée (DM1), la valeur courante du compteur au terminal.
[Revendication 14] Procédé selon la revendication 12 ou 13, dans lequel le procédé comprend en outre :
- détermination, par le dispositif électronique, d'un identifiant de marchand (IDMD) identifiant une entité marchande (MD) associée au terminal ; et
- vérification, par le dispositif électronique, de si l'identifiant de marchand correspond à un marchand prédéfini ;
dans lequel ladite transmission, par le dispositif électronique, du cryptogramme au terminal n'est réalisée que si l'entité marchande ne correspond pas à un marchand prédéfini. [Revendication 15] Procédé selon l'une quelconque des revendications 12 à 14, dans lequel le procédé comprend : en réponse à une commande de stockage (CMD5) reçue en provenance du terminal (Tl), stockage dans une mémoire locale (MR6) du dispositif électronique, du cryptogramme (MCI), des données d'entrée (MD1) et des données de transaction (DT2) pour permettre la transmission, par un terminal, d'une requête ultérieure de génération de ticket électronique lors d'une transaction ultérieure.
PCT/FR2019/053032 2018-12-21 2019-12-12 Traitement d'un service de tickets electroniques WO2020128240A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1874025 2018-12-21
FR1874025A FR3090959B1 (fr) 2018-12-21 2018-12-21 Traitement d’un service de tickets électroniques

Publications (1)

Publication Number Publication Date
WO2020128240A1 true WO2020128240A1 (fr) 2020-06-25

Family

ID=67185156

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/053032 WO2020128240A1 (fr) 2018-12-21 2019-12-12 Traitement d'un service de tickets electroniques

Country Status (2)

Country Link
FR (1) FR3090959B1 (fr)
WO (1) WO2020128240A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113129088A (zh) * 2021-03-31 2021-07-16 郭军 一种支付终端财政票据大数据管理方法及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4804825A (en) * 1986-06-17 1989-02-14 Casio Computer Co., Ltd. I C card system
US20090313132A1 (en) * 2008-06-13 2009-12-17 Microsoft Corporation Handling payment receipts with a receipt store
FR2968882A1 (fr) * 2010-12-09 2012-06-15 Guillaume Schneider Procede et dispositif de production de facturettes dematerialisees
WO2012143547A1 (fr) * 2011-04-21 2012-10-26 Ellan Dilek Contrôle de paiement sans papier en temps réel
US20140249951A1 (en) * 2013-03-01 2014-09-04 Toshiba Tec Kabushiki Kaisha Merchandise sales data processing apparatus, and program therefor
US20140358788A1 (en) * 2013-05-31 2014-12-04 Mastercard International Incorporated Method for Receiving an Electronic Receipt of an Electronic Payment Transaction Into a Mobile Device
WO2017203146A1 (fr) * 2016-05-23 2017-11-30 Oberthur Technologies Procede de securisation d'un dispositif electronique, et dispositif electronique correspondant

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4804825A (en) * 1986-06-17 1989-02-14 Casio Computer Co., Ltd. I C card system
US20090313132A1 (en) * 2008-06-13 2009-12-17 Microsoft Corporation Handling payment receipts with a receipt store
FR2968882A1 (fr) * 2010-12-09 2012-06-15 Guillaume Schneider Procede et dispositif de production de facturettes dematerialisees
WO2012143547A1 (fr) * 2011-04-21 2012-10-26 Ellan Dilek Contrôle de paiement sans papier en temps réel
US20140249951A1 (en) * 2013-03-01 2014-09-04 Toshiba Tec Kabushiki Kaisha Merchandise sales data processing apparatus, and program therefor
US20140358788A1 (en) * 2013-05-31 2014-12-04 Mastercard International Incorporated Method for Receiving an Electronic Receipt of an Electronic Payment Transaction Into a Mobile Device
WO2017203146A1 (fr) * 2016-05-23 2017-11-30 Oberthur Technologies Procede de securisation d'un dispositif electronique, et dispositif electronique correspondant

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113129088A (zh) * 2021-03-31 2021-07-16 郭军 一种支付终端财政票据大数据管理方法及系统
CN113129088B (zh) * 2021-03-31 2022-12-02 郭军 一种支付终端财政票据大数据管理方法及系统

Also Published As

Publication number Publication date
FR3090959B1 (fr) 2020-12-11
FR3090959A1 (fr) 2020-06-26

Similar Documents

Publication Publication Date Title
EP3243176B1 (fr) Procédé de traitement d'une transaction à partir d'un terminal de communication
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
EP3455812B1 (fr) Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant
FR2923635A1 (fr) Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d'ordinateur et methode correspondants.
EP3234848B1 (fr) Procede d'envoi d'une information de securite et dispositif electronique apte a mettre en oeuvre un tel procede
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
EP3261014B1 (fr) Procédé d'envoi d'une information de sécurité
CA2999731A1 (fr) Procede de traitement de donnees par un terminal de paiement, terminal de paiement et programme correspondant
EP3343487A1 (fr) Procédé de contrôle d'habitudes d'utilisation et dispositif électronique apte à mettre en uvre un tel procédé
WO2017109405A1 (fr) Procédé d'authentification
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
CA3143068A1 (fr) Systeme d'applications de service pour terminaux de paiement
EP3291188B1 (fr) Procédé de contrôle d'un dispositif électronique et dispositif électronique correspondant
EP3113094B1 (fr) Procédé de traitement de données transactionnelles, dispositif et programme correspondant
EP4075358A1 (fr) Gestion de la mémoire dans un dispositif de traitement de transactions
CA2946145A1 (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
WO2023099238A1 (fr) Procédé de réalisation d'une transaction, dispositifs et programmes correspondants.
WO2018011514A1 (fr) Procédé de contrôle d'un dispositif électronique pour traiter une transaction
EP3223219A1 (fr) Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l'un d'eux
FR3031609A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19842390

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19842390

Country of ref document: EP

Kind code of ref document: A1