Method of recording a digital ticket relating to a transaction

Abstract

The invention is a computer-implemented method for recording a digital ticket relating to a transaction, characterized in that it comprises the following steps: - generation of a digital ticket (14) relating to a transaction; - timestamping of the digital ticket (14); - transmission, from a payment device (2) used for the transaction to a payment terminal (3) used for the transaction, of a transaction identifier (7); - generation of an identifier of the digital ticket (18) from the transaction identifier (7); - transmission of the digital ticket (14), the identifier (18) of the digital ticket and the timestamp (15) of the digital ticket, associated with each other, to a database (5) of digital tickets. Figure for abstract: figure 1

Description

Title of the invention: Method for recording a digital ticket relating to a transaction

[0001] The invention relates to the management of digital tickets.

[0002] It concerns in particular the dematerialization of “receipts”.

[0003] When a transaction is settled by a payment device at a payment terminal, a receipt and a payment receipt, both generally referred to as "tickets" hereinafter, are usually printed and provided to the buyer so that he has information relating to the transaction, in particular payment information.

[0004] However, paper tickets of this type are intended to disappear, which makes it possible to eliminate the need for paper and save the costs of purchasing and maintaining the components for printing these tickets.

[0005] To continue providing transaction information to the buyer, an alternative to paper tickets is the generation of digital tickets. It is therefore appropriate to have a means of transmitting a digital ticket, relating to a transaction, to a buyer who has just completed a transaction.

[0006] A solution is already known in the state of the art consisting of sending the generated digital ticket by email or SMS to the user. However, this requires the user to provide their email address or telephone number to the merchant. This is a cumbersome process for the user, which may contain errors, and which also presents risks from the point of view of the confidentiality of their data, which may be seen or heard or, with regard to email addresses, be subject to so-called "spear-fishing" attacks. It is also a particularly time-consuming process in the case of a tight flow of buyers at payment cash registers.

[0007] Also already known in the art is a solution consisting of making the ticket directly accessible to the user's mobile terminal via near field communication or by QR code. Thus, in particular from documents EP3382628 and KR102444679, a method is known in which, after the transaction, a payment terminal used for this transaction transmits, by near field communication, to a mobile terminal used for the transaction, a web address allowing the mobile terminal to access the digital ticket relating to the transaction, or even the ticket itself in the case of document EP3382628. However, this requires the buyer to make his payment by means of a mobile terminal and to have an appropriate mobile application. This process is therefore not not suitable for all consumers, who do not all have a smartphone or, for those who do have a smartphone, who do not want to move around with it all the time, do not want to settle a transaction with it or do not want to multiply the mobile applications. This process is also restrictive since it requires the buyer to take out and manipulate their mobile terminal during payment. In addition, this process consumes the energy of the mobile terminal as well as its memory. Finally, in general, near-field communication (NFC) is, like the use of QR-codes, a process that requires the use of mobile applications that will necessarily be updated regularly to be adapted to all platforms and all versions of these platforms, forcing users to renew their mobile terminals or lose access to their digital tickets.

[0008] The invention aims in particular to provide a solution allowing a user to have access to a digital ticket relating to a transaction without the payment experience experienced by the user differing from that associated with paper tickets.

[0009] To this end, the invention relates to a method for recording a digital ticket relating to a transaction, implemented by computer, comprising the following steps:

[0010] - generation of a digital ticket relating to a transaction;

[0011] - timestamp of the digital ticket;

[0012] - transmission, from a payment device used for the transaction to a payment terminal used for the transaction, a transaction identifier;

[0013] - generation of a digital ticket identifier from the identifier of transaction;

[0014] - transmission of the digital ticket, the digital ticket identifier and the timestamp of the digital ticket, associated with each other, to a digital ticket database.

[0015] Thus, it is not necessary to have a mobile terminal or to provide contact details to record the digital ticket relating to the transaction. The payment device directly provides, during payment, the information to the terminal making it possible to generate an identifier of the digital ticket, in particular the transaction identifier, this transaction identifier being specific to the transaction. This identifier recorded within the payment device is known to the user's bank, their digital wallet or the user themselves, so that the user can then access the digital ticket in the database from this identifier.

[0016] In particular, the payment device has either a list of pre-recorded random or pseudo-random transaction identifiers and a counter, allowing to choose a unique identifier from the list for each transaction, or a pseudo-random transaction identifier generator allowing to generate a unique identifier for each transaction.

[0017] The payment process is unchanged from the processes associated with paper tickets. The user experience is even less restrictive since no paper ticket is to be expected at the time of payment, and the user decides for himself whether or not he wants to retrieve his digital ticket from the database, at a later time of his choice.

[0018] Other optional features, taken alone or in combination, follow.

[0019] Advantageously, the identifier of the digital ticket generated from the transaction identifier is the transaction identifier, or the method comprises a step of hashing the transaction identifier so that the digital identifier generated from the transaction identifier is the result of the hashing.

[0020] Thus, the transaction identifier transmitted by the payment device is directly used to generate the identifier of the digital ticket, without any other information being necessary, or it is the subject of a hash. The identifier is advantageously the result of a pseudo-random identifier generator. In the case where the identifier is the result of a pseudo-random identifier generator, the hashing makes it possible to prevent the parameters of the generator from being found by a third party.

[0021] Alternatively, the method comprises the following steps:

[0022] - before the generation of the digital identifier, transmission, of the device of payment to the payment terminal, of an identifier of the payment device;

[0023] - the generation of the digital ticket identifier from the identifier of transaction is carried out by performing a combination between the payment device identifier and the transaction identifier, preferably also by performing a hash of a result of the combination.

[0024] Thus, in this case the transaction identifier is not directly transformed into a digital ticket identifier. Indeed, the payment device transmits to the payment terminal, in addition to this transaction identifier which is specific to a given transaction, an identifier of the payment device which remains the same for each transaction since it characterizes the payment device. This may be, for example, the PAN identifier (for “Primary Account Number”) in the case where the payment device is a bank card.

[0025] The device identifier is, like the transaction identifier, derived from the payment device possessed by the user and also known to the user's bank that issued this payment device, from an electronic wallet of the user or even from the user himself, so that the user can at any time generate the digital ticket identifier to find, in the digital ticket database, the digital ticket relating to its transaction.

[0026] Combining this payment device identifier with the transaction identifier makes the confidentiality of the digital tickets even more secure. In particular, in the case where the transaction identifiers are generated pseudo-randomly, their combination with the payment device identifier prevents a third party from finding the identifier of the digital ticket solely from the generator parameters. Furthermore, in the case where, upon initialization of the payment device, a specific entity, for which no trust is granted, is responsible for generating the transaction identifiers, combining the latter with the payment device identifier prevents this entity, which is unaware of the payment device identifier, from being able to find the identifiers of the digital tickets corresponding to the identifiers it has generated.

[0027] Preferably, the method comprises the following steps:

[0028] - transmission, from the payment device to the payment terminal, of a payment key encryption;

[0029] - encryption of the digital ticket generated by the encryption key;

[0030] and wherein the step of transmitting the digital ticket to the database is the transmission of the encrypted digital ticket.

[0031] Thus, the content of the digital ticket is encrypted. This prevents a third party entity from attempting to obtain information, for example to generate statistics, by making random queries on the digital ticket database. The encryption key is therefore installed in the payment device when it is initialized, while the corresponding decryption key is known to the user's bank, their digital wallet or themselves, allowing them to decrypt the content of the digital ticket when the user wishes to access it. This key pair may be an asymmetric key pair. In such a case, the encryption key installed in the device is considered to be the public key, while the decryption key, which is private, is kept confidential by the bank, the digital wallet or the user themselves. Alternatively, a single key may be used for encryption and decryption.

[0032] Advantageously, the method comprises, before the transmission of the transaction identifier to the payment terminal, a step of selecting, from a list of transaction identifiers of the payment device, one of these identifiers with a view to transmitting the selected transaction identifier.

[0033] Thus, the transaction identifiers are pre-recorded in the payment device in the form of a list. An identifier from this list is used for each transaction.

[0034] Advantageously, the method comprises:

[0035] - a counting step, by a transaction counter of the payment device, the number of transactions carried out by the payment device, the selection of the identifier being carried out based on this count; or

[0036] - the selection, from the list of transaction identifiers of the payment device, of the identifier located at one end of the list corresponding to a selection position, then deleting, in the list, this identifier so that the next identifier in the list is in the selection position for a following transaction.

[0037] Thus, to avoid selecting the same identifier twice for two separate transactions, two possibilities are offered: in the case of counting, the payment device counter increments its count so that the identifier corresponding to the count is selected. Alternatively, the selected transaction identifier is the one at the end of the list, within the list of transaction identifiers of the payment device. This identifier is deleted after the transaction, so as to select the next identifier from the list for the next transaction. This makes it possible to do without a counter.

[0038] Advantageously, the method comprises, prior to the transaction, the following steps:

[0039] - generation of a list of pseudo-random or random transaction identifiers;

[0040] - recording, within the payment device, of this list of identifiers of transaction.

[0041] Thus, these steps take place when the payment device is initialized, for example when the payment card is manufactured when the payment device is a payment card.

[0042] Alternatively, the method comprises, before the transmission of the transaction identifier to the payment terminal, a step of generation, by a generator of pseudo-random transaction identifiers within the payment device, of this transaction identifier.

[0043] Thus, a list of transaction identifiers is, in this case, not recorded within the payment device. Instead, an identifier generator is integrated into the device, and generates a transaction identifier for each transaction. This generator generates identifiers in a pseudo-random manner. The bank, the digital wallet or the user have the same generator, so as to generate the same identifiers, in order to be able to find the digital tickets in the database.

[0044] Advantageously, the method comprises, prior to the transaction, the following steps:

[0045] - creation of the pseudo-random transaction identifier generator;

[0046] - placement, within the payment device, of this generator.

[0047] Preferably, the method comprises updating, by an automatic teller machine and within the payment device, the list of random or pseudo-random transaction identifiers introduced above or the pseudo-random identifier generator introduced above.

[0048] Thus, the user can “reload” his list of transaction identifiers at a cash machine.

[0049] The invention also relates to a payment method relating to a transaction, comprising, once the payment has been made, the recording of a digital ticket relating to the transaction in accordance with the method described above.

[0050] The invention also relates to a method for recovering a digital ticket relating to a transaction, the digital ticket having been recorded in accordance with any one of the preceding claims, comprising the following steps:

[0051] - obtaining the transaction identifier;

[0052] - generation of a digital ticket identifier from the identifier of transaction;

[0053] - retrieving, in the digital ticket database, the digital ticket associated with the generated digital ticket ID.

[0054] Advantageously, in the recovery method, the identifier of the digital ticket is the transaction identifier, or the method comprises a step of hashing the transaction identifier so that the digital identifier is the result of the hashing.

[0055] Preferably, the recovery method comprises the following steps:

[0056] - before generating the digital identifier, obtaining the identifier of the payment device,

[0057] - generation of the digital ticket identifier by performing a combination between the payment device identifier and the transaction identifier, preferably also by hashing a result of the combination.

[0058] Advantageously, the ticket having been encrypted during recording in accordance with the method described above, this recovered digital ticket is decrypted by a decryption key.

[0059] The invention also relates to a computer program comprising instructions which, when the program is executed by a computer, cause the latter to implement the steps of the registration method described above, of the payment method described above or of the recovery method described above.

[0060] The invention also relates to a computer-readable recording medium comprising instructions which, when executed by a computer, cause the latter to implement the steps of the recording method described above, the payment method described above or the recovery method described above.

[0061] The invention also relates to a database of digital tickets, comprising at least one digital ticket recorded in accordance with the method described above, the ticket being associated, in the database, with the identifier of the generated ticket and the timestamp of the ticket.

[0062] The invention also relates to a payment device, comprising:

[0063] - an identifier of the payment device;

[0064] - a list of transaction identifiers or a pseudo identifier generator random transactions;

[0065] - means of transmitting, to a payment terminal, the identifier of the payment device;

[0066] - means of transmitting, to a payment terminal, an identifier of transaction from the list or a pseudo-random identifier generated by the generator.

[0067] Preferably, the device further comprises an encryption key, the transmission means being capable of also transmitting this key.

[0068] Advantageously, the device further comprises a transaction counter.

[0069] The invention also relates to a payment terminal, comprising automated means capable of:

[0070] - receive, from a payment device, a transaction identifier,

[0071] - generate an identifier of a digital ticket relating to the transaction from the transaction ID;

[0072] - transmit the digital ticket, associated with the identifier of the generated digital ticket and to the timestamp of the digital ticket, to a digital ticket database.

[0073] Advantageously, the automated means are also capable of:

[0074] - receive, from a payment device, an identifier of the payment device;

[0075] - generate a digital ticket identifier by performing a combination between the payment device identifier and the transaction identifier, preferably also by hashing a result of the combination. Brief description of the figures

[0076] The invention will be better understood on reading the following description given solely by way of example and with reference to the appended drawings in which:

[0077] [Fig-1] is a diagram of a system for recording a digital ticket relating to a transaction according to a first embodiment;

[0078] [Fig.2] is a flowchart of a first mode of implementation of a method of recording a ticket relating to a transaction by the system of [Fig.l];

[0079] [Fig.3] is a diagram of a system for recording a digital ticket relating to a transaction according to a second embodiment;

[0080] [Fig.4] is a flowchart of a second mode of implementation of the method by the system of [Fig.3];

[0081] [Fig.5] is a diagram of a digital ticket recording system relating to a transaction according to a third embodiment;

[0082] [Fig.6] is a flowchart of a third mode of implementation of the method by the system of [Fig.5];

[0083] [Fig.7] is a diagram of a digital ticket recording system relating to a transaction according to a fourth embodiment;

[0084] [Fig.8] is a flowchart of a fourth mode of implementation of the method by the system of [Fig.7];

[0085] [Fig.9] is a diagram of a digital ticket recording system relating to a transaction according to a fifth embodiment;

[0086] [Fig. 10] is a flowchart of a fifth mode of implementation of the method by the system of [Fig.9];

[0087] [Fig. 11] is a flowchart of an update process;

[0088] [Fig. 12] is a flowchart of a payment method;

[0089] [Fig. 13] is a flowchart of a digital ticket recovery process. Detailed description

[0090] The system 1 of [Fig.l] is a system for recording a digital ticket relating to a transaction. It comprises a payment device 2 taking the form of a payment chip card 2. This system 1 also comprises a payment terminal 3. This system 1 also comprises a server 4 and a database 5 of digital tickets.

[0091] The term “payment device” refers to any device capable of making a payment on the buyer's side, such as a mobile terminal or any connected device, insofar as this payment device is configured to make a payment in combination with a payment terminal. The payment device 2 comprises within it an identifier 32 (for “Primary Account Number”). It also comprises means for making a payment according to protocols known to those skilled in the art and which will not be described in detail.

[0092] The payment device 2 further comprises a list 6 of transaction identifiers. These are identifiers of any format for those skilled in the art, for example a random number made readable in hexadecimal format, or in “base64” format. These identifiers are generated beforehand in a pseudo-random or random manner. It is advantageous for these identifiers to be generated in a purely random. Indeed, in this case, it is impossible for a malicious third party, from a part of a list of these identifiers, to find certain common characteristics between these identifiers allowing the generation of the other identifiers in the list. However, it is simpler and generally sufficient to generate identifiers in a pseudo-random manner, that is to say identifiers sufficiently independent of each other, generated in a sequence of identifiers presenting certain properties of chance. The device 2 comprises means of transmission 8, to the payment terminal 3, of a transaction identifier 7 from the list 6.The card 2 also comprises a recording medium 9 readable by a computer, in particular by a microprocessor, comprising instructions which, when executed by such a microprocessor, cause the latter to carry out all or part of the steps of the different modes 100, 200, 300, 400, 500 or 600 of the recording method described below, of the payment method 700 described below or of the recovery method 800 described below. To do this, this support 9 comprises a computer program 10. The program 10 comprises instructions which, when the program 10 is executed by a computer, in particular by a microprocessor, lead the latter to implement all or part of the steps of the different modes 100, 200, 300, 400, 500 or 600 of the registration method described below, of the payment method 700 described below or of the recovery method 800 described below.

[0093] The term "payment terminal" refers to any device capable of participating in a payment on the seller's side. The payment terminal 3 comprises means of communication 11, with the payment device 2, known to those skilled in the art and which will therefore not be described in detail. The terminal 3 also comprises means for making a payment according to protocols known to those skilled in the art and which will not be described in detail. It also comprises a recording medium 12 readable by a computer, in particular by a microprocessor, comprising instructions which, when executed by such a microprocessor, cause it to implement all or part of the steps of the different modes 100, 200, 300, 400, 500 or 600 of the recording method described below, of the payment method 700 described below or of the recovery method 800 described below. To do this, this support 12 includes a computer program 13.The program 13 comprises instructions which, when the program 13 is executed by a computer, in particular by a microprocessor, cause the latter to implement all or part of the steps of the different modes 100, 200, 300, 400, 500 or 600 of the registration method described below, of the payment method 700 described below or of the recovery method 800 described below.

[0094] In particular, it results from the combination of the conventional means of the payment terminal 3 and the means of the terminal 3 specifically configured to put implement the processes described below that terminal 3 includes in particular automated means capable of:

[0095] - receive, from the payment device 2, a transaction identifier 7,

[0096] - generate an identifier 18 of a digital ticket 14 from the identifier of transaction 7;

[0097] - transmit the digital ticket 14, associated with the identifier 18 of the digital ticket generated and at timestamp 15 of the digital ticket, to the digital ticket database 5.

[0098] The database 5 comprises, in the form of data tables, digital tickets relating to transactions, in encrypted form or in clear form. Each of these tickets is associated with an identifier 18 of the digital ticket which is generated in accordance with the modes 100, 200, 300, 400, 500 or 600 of the recording method described below. Each of these tickets is also associated with a timestamp 15 making it possible to determine when the ticket was generated. The server 4 makes it possible to access, read and modify the content of the database 5 of digital tickets. This server 4 therefore comprises means for this purpose which are conventional for those skilled in the art.It comprises means of communication with the payment terminal 3. It also comprises a recording medium 16 readable by computer, in particular by a microprocessor, comprising instructions which, when executed by such a microprocessor, cause the latter to implement all or part of the steps of modes 100, 200, 300, 400, 500 or 600 of the recording method described below, of the payment method 700 described below or of the recovery method 800 described below. To do this, this support 16 comprises a computer program 17. The program 17 comprises instructions which, when the program 17 is executed by a computer, in particular by a microprocessor, lead the latter to implement all or part of the steps of the modes 100, 200, 300, 400, 500 or 600 of the registration method described below, of the payment method 700 described below or of the recovery method 800 described below.

[0099] The three computer programs 10, 13 and 17 mentioned therefore allow the payment device 2, the payment terminal 3 and the database 5 (via its server 4) to communicate with each other to implement the methods described below.

[0100] We will now describe implementation modes 100 to 600 of a method for recording a digital ticket relating to a transaction, implemented by computer, in particular implemented by the automated means of the payment device 2, the payment terminal 3 and the server 4. It will be clear to those skilled in the art which modes can be combined together.

[0101] We will first describe mode 100 implemented by system 1 of [Fig.l].

[0102] Step 101, implemented prior to a transaction, is the generation of a list 6 of pseudo-random or random transaction identifiers. It is carried out by an entity external to the system, for example by the bank that issued the payment card 2. A list of “random” identifiers is preferred to a list of “pseudo-random” identifiers for the security reasons mentioned, but the generation of a pseudo-random list is generally simpler.

[0103] Step 102 is the recording, within the payment device 2, of this list 6 of transaction identifiers.

[0104] A step implemented in parallel is the recording of this list 6 by an entity external to the system, such as the bank that issued the payment device, an electronic wallet of the user or the user himself, within a dedicated database, with a view to recovering the digital ticket subsequently. To do this, if the identifiers have been generated in a purely random manner, they are transmitted to the external entity, the latter not being able to find them by itself. If, on the other hand, they have been generated in a pseudo-random manner by a pseudo-random generator, the same generator can be used by the external entity, according to known parameters, to generate the same identifiers.

[0105] The following steps take place during the transaction between a buyer, having the payment card 2, and a merchant, having the payment terminal 3. The buyer makes the payment thanks to the interaction between his card 2 and the terminal 3.

[0106] Step 103 is the generation of a digital ticket 14 relating to the transaction. This ticket 14 is generated by the payment terminal used 4 for the transaction, possibly in collaboration with a payment cash register of the merchant, according to protocols which are not the subject of the invention. The digital ticket 14 is a cash register receipt which includes the information relating to the transaction such as the items purchased, the prices, taxes, date, time of the transaction and the name of the merchant. This digital ticket 14 in fact has the same information as the traditionally printed paper cash register receipt.

[0107] Step 104 is the timestamp of the digital ticket 14, that is to say the association of the date and time, forming a timestamp 15, corresponding to this ticket 14 and therefore to the transaction.

[0108] Step 105 is the selection, from the list 6 of transaction identifiers of the payment device used for the transaction, of one of these identifiers 7 in order to transmit the selected transaction identifier 7. To do this, from the list 6 of transaction identifiers of the payment device, the payment terminal 3 chooses the identifier 7 located at one end of the list 6 corresponding to a selection position. Then, the terminal 3 and / or the payment device 2 implements a step of deleting, from the list 6, this identifier 7 so that that the next identifier 7 from list 6 is in the selection position for a subsequent transaction.

[0109] Step 106 is the transmission, from the payment device 2 to the payment terminal 3, of the selected transaction identifier 7. It will only be used for this transaction.

[0110] Step 107-A is the generation of an identifier 18 of the digital ticket 14 from the transaction identifier 7. In this variant, the identifier 18 of the digital ticket 14 generated from the transaction identifier 7 is the transaction identifier 7 itself.

[0111] In a second variant, step 107-B is a hash of the transaction identifier 7 so that the identifier 18 generated from the transaction identifier 7 is the result of the hash. This variant improves security. In particular, if the transaction identifier 7 was generated in a pseudo-random and non-random manner, the hash makes it possible to limit the risks of this identifier being found by a third party.

[0112] Step 108 is the transmission of the digital ticket 14, the identifier 18 of the digital ticket and the timestamp 15 of the digital ticket 14, associated with each other, to the digital ticket database 5. This transmission is carried out by the payment terminal 3. In a variant not illustrated, it is carried out by the merchant's cash register.

[0113] The system 20 of [Fig. 3] differs from that of [Fig. 1] in that the payment device 21 further comprises a transaction counter 22.

[0114] Mode 200 of [Fig.4], implemented by system 21 of [Fig.3], differs from mode 100 of [Fig.2] in that instead of choosing an identifier at a certain position in the list and deleting it, the selection step has a step of counting, by the transaction counter 22 of the payment device 21, the number of transactions carried out by the payment device 21, the selection of the identifier 7 being carried out as a function of this count. For example, for the 8th transaction carried out by this payment device 21, the 8th identifier from the list 6 of identifiers is selected.

[0115] The system 23 of [Fig. 5] differs from the systems 1 and 20 of the respective figures 1 and 3 in that, instead of a list 6, the payment device 24 comprises a generator 25 of pseudo-random transaction identifiers.

[0116] Mode 300 of [Fig.6], implemented by system 23 of [Fig.5], differs from the previous modes in that it comprises the following steps described below.

[0117] Step 301 is the preliminary creation of the generator 25 of pseudo-random transaction identifiers. It is implemented by an entity external to the system, for example by the bank having issued the payment device 24.

[0118] Step 302 is the placement, within the payment device 24, of this generator 25.

[0119] A parallel step not illustrated is the placement of an identical generator with the bank, an electronic wallet of the user, the user himself or any entity allowing the user to subsequently generate the same transaction identifiers as the generator 25 placed within the payment device 24. In order for these generators to generate identical numbers, it is necessary that they both be pseudo-random and with identical parameters. Two purely random generators would not generate the same numbers.

[0120] Step 303 is, before the transmission of the transaction identifier 7 to the payment terminal 3, the generation, by the generator 25 of pseudo-random transaction identifiers within the payment device 24, of this transaction identifier 7. It is therefore this identifier 7 which is transmitted and used to generate the identifier 18 of the digital ticket, rather than an identifier chosen from a list. At the next transaction another transaction identifier will be generated.

[0121] The system 26 of [Fig.7] differs from the previous systems in that the payment device 27 comprises, in addition to the components mentioned in the various embodiments described, an encryption key 19, called the “public” key. The transmission means 8 are also capable of transmitting this encryption key 19 to the payment terminal 3. A corresponding decryption key, called the private key, is held by an entity external to the system, such as a bank that issued the payment device 27, an electronic wallet of the user or the user himself. Alternatively, in a symmetric encryption system, the same key is used to encrypt and to decrypt.

[0122] Mode 400 of [Fig.8], implemented by system 26 of [Fig.7], differs from the methods described previously in that it includes additional steps described below.

[0123] Step 401 is the transmission, from the payment device 27 to the payment terminal 3, of the public encryption key 19.

[0124] Step 402 is the encryption of the digital ticket 14 generated by the encryption key. This encryption is carried out by the payment terminal 3 using the key obtained from the payment device 27.

[0125] The transmission step 403 to the database 5 is then the transmission not of the digital ticket 14 in clear, but of the encrypted digital ticket 28. It is this encrypted digital ticket 28 which is associated, in the database 5, with the identifier 18 of the ticket 14 and the timestamp 15.

[0126] The purpose of this mode 400 is to prevent a third party from producing statistics from the digital tickets that they would obtain in clear text. It also makes it possible to manage collisions, as mentioned below, thanks to decryption.

[0127] The system 29 of [Fig.9] differs from the previous systems in that the automated means of the payment terminal 30 are further capable of:

[0128] - receive, from the payment device 2, an identifier 32 (PAN) of the payment device payment 2;

[0129] - generate an identifier 31 of the digital ticket 14 by making a combination between the payment device 2 identifier 32 and the transaction identifier 7, and by hashing a result of the combination. The combination is described below.

[0130] Mode 500 of [Fig. 10], implemented by system 29 of [Fig. 9], differs from the methods described previously in that it comprises the steps described below.

[0131] Step 501 is, before the generation of the identifier 31, the transmission, from the payment device 2 to the payment terminal 30, of the identifier 32 (“PAN”) of the payment device.

[0132] Step 502-A is the generation of the identifier 31 of the digital ticket. It is not carried out solely from the transaction identifier 7 as in the method 100. It is carried out by carrying out a combination between the identifier 32 of the payment device and the transaction identifier 7. The combination is the concatenation of the transaction identifier 7 with the identifier 32 of the payment device. Alternatively, the transaction identifier 7 and the identifier 32 of the card are converted into binary numbers, and the combination is the XOR operation between these two binary identifiers. Other types of combination are applicable. It is the result of this combination which is the digital identifier 31 of the ticket 14, and which is associated with the ticket 14 or the encrypted ticket 28 in the database 5.

[0133] In a variant, step 502-B differs from step 502-A in that the result of the combination is subject to a hashing operation. It is the hash of the result of the combination which is then the digital identifier 32 of the ticket, and which is associated with the ticket 14 or the encrypted ticket 28 in the database 5.

[0134] This mode 500 further improves security with respect to the previous modes where only the transaction identifier is necessary to generate the identifier of the digital ticket. Even in the case where the transaction identifier is generated purely randomly, this mode is advantageous because it allows the creation of the identifiers and the payment device by respective distinct entities without trust between them. Indeed, in the case where an entity A creates only transaction identifiers and transfers them to an entity B which creates the payment device and which generates the identifier of the payment device, the combination between the identifier of the payment device and transaction identifiers prevents entity A, which would have stored the generated transaction identifiers, from trying to access the digital tickets generated from these transaction identifiers.

[0135] The method 600 of [Fig. 11] is an updating method, relating to all the modes of implementation of the recording method described previously. It comprises the updating, by an automatic teller machine and within the payment device 2, of the list of pseudo-random or random transaction identifiers 6 introduced above or of the generator 25 of pseudo-random identifiers introduced above. Thus, the buyer inserts his card 2 into the payment dispenser and obtains the possibility of updating the list if the card operates according to modes 100 or 200 or of updating the generator if the card operates according to method 300. This method 600 can be considered as forming an additional step of a recording method according to one of modes 100 to 500, or as a new mode of implementation 600 of such a recording method.

[0136] In another embodiment not illustrated, the list or generator are updated via a mobile application of the user.

[0137] The method 700 of [Fig. 12] is a payment method relating to a transaction, comprising, once the payment has been made, the recording of a digital ticket relating 14 to the transaction in accordance with the modes 100 to 600 of the method for recording a digital ticket described previously. Thus, the user makes the payment by means of his payment card, and the digital ticket relating to this transaction is recorded in the database in accordance with the modes 100 to 600.

[0138] The method 800 of [Fig. 13] is a method of retrieving a digital ticket relating to a transaction, the digital ticket having been recorded in accordance with one of the modes of the recording method described previously. The objective of the user is to retrieve the ticket corresponding to a transaction that he has previously carried out.

[0139] Step 801 is obtaining the transaction identifier. It is feasible since the transaction identifier is also held by an entity external to the system, whether it is the bank, a user's wallet or the user himself, in accordance with the modes of the registration method described previously.

[0140] Step 802 is the generation of a digital ticket identifier from the transaction identifier. This step is the same as that implemented by the payment terminal in the different modes of implementation of the recording method. Thus, if the transaction identifier is the digital identifier, as in step 107-A of mode 100, this is also the case in this recovery method. If hashing is necessary as in step 107-B, the same hashing is performed here, i.e. the transaction identifier is subject to the same function of hashing, so as to generate the same identifier of the digital ticket if the transaction identifier is identical. Similarly, if the identifier of the payment device has been combined with the transaction identifier in accordance with step 502-A of mode 500, then this step 802 comprises obtaining the identifier of the payment device and generating the identifier of the digital ticket by performing the same combination between the identifier of the payment device and the transaction identifier. Furthermore, if a hash has been performed as in step 502-B, then the same hash function is applied to the result of the combination, so as to generate the same identifier of the digital ticket.

[0141] Step 803 is the retrieval, in the digital ticket database 5, of the digital ticket associated with the generated identifier of the digital ticket. The user thus simply retrieves the digital ticket relating to his transaction, only if he wishes, when he wishes, and without his payment experience having been hindered.

[0142] Step 804 is implemented if an encryption of the digital ticket has been carried out in accordance with mode 400 of the registration method. The ticket having been encrypted during registration, and the private key being held by the bank, the digital wallet or the user himself, this recovered digital ticket is decrypted by the decryption private key. The user then recovers the digital ticket in clear. Alternatively, in a symmetric encryption system, the same key is used for encryption and decryption.

[0143] The encryption and decryption steps make it possible, in addition to avoiding the creation of statistics on the clear tickets, to decide on possible collisions. Indeed, it is theoretically conceivable that two ticket identifiers, for two different users, are identical. Each user having a respective decryption key, a user will only obtain the ticket decrypted by his key and will not be able to access the ticket of the other user.

[0144] The invention is not limited to the embodiments presented and other embodiments will become clear to those skilled in the art.

[0145] Firstly, as already mentioned, it will be clear to those skilled in the art that some of the modes presented are combinable with each other. Thus, the encryption or not of the digital ticket, according to mode 400, is independent of the other steps of the method. Any hashes are also independent of the other steps. The generation of the digital identifier by the combination between the transaction identifier and the payment device identifier differs from the generation of this ticket identifier carried out solely from the transaction identifier. However, these two modes are a way of generating the digital ticket identifier from the transaction identifier, one of the modes not requiring other elements, the other mode requiring in addition the payment device identifier. The presence of a list of identifiers in the payment device does not preclude the presence of an identifier generator, although these two approaches are redundant. Selecting an identifier at a particular place in the list and deleting it does not preclude counting transactions to select the identifier, although again these two approaches to selecting the identifier are redundant.

[0146] The holding of the list of transaction identifiers or the generator, the hash functions and the decryption key by an external entity such as a bank or an electronic wallet has been mentioned. It will be clear to those skilled in the art that any other entity capable of allowing the user to recover their digital ticket may have these elements. This may be any platform associated with the system and with which the user can identify themselves and have a private account provided with the list of identifiers or the generator, possibly the hash functions and the decryption key.

[0147] The digital ticket mentioned in the description corresponds to a receipt. However, any ticket "relating to a transaction" is concerned by the invention. It may be a payment ticket, which will list the payment information relating to the transaction, but also a ticket relating to information on a purchased product, for example including the product warranty. The user can thus retrieve information on his product, for example the warranty, by accessing this ticket whenever he wishes. It may also be information relating to a ticket purchased for an event, since this event is directly associated with the transaction.

[0148] List of references 1: Digital ticket registration system 2: payment device 3: payment terminal 4: server 5: database 6: list of transaction identifiers 7: transaction identifier 8: means of communication of the payment device 9: payment device data carrier 10: computer program of the payment device 11: means of communication of the payment terminal 12: payment terminal data support 13: Payment terminal computer program 14: clear digital ticket 15: timestamp of the digital ticket 16: Server data support 17: Server computer program 18: digital ticket identifier 19: encryption key 20: Digital ticket registration system 21: payment device 22: transaction counter 23: Digital ticket registration system 24: payment device 25: pseudo-random transaction identifier generator 26: Digital ticket registration system 27: payment device 28: encrypted digital ticket 29: digital ticket registration system 30: payment terminal 31: digital ticket identifier 32: payment device identifier 100, 200, 300, 400, 500: process for registering a digital ticket 600: method for updating transaction identifiers or an identifier generator 700: payment method 800: process for recovering a digital ticket

Claims

Claims

1. A method (100; 200; 300; 400; 500; 600) for recording a digital ticket relating to a transaction, implemented by computer, characterized in that it comprises the following steps: - generation (103) of a digital ticket (14; 28) relating to a transaction; - time-stamping (104) of the digital ticket (14; 28); - transmission (106), from a payment device (2; 21; 24; 27) used for the transaction to a payment terminal (3; 30) used for the transaction, of a transaction identifier (7); - generation (107) of an identifier of the digital ticket (18; 31) from the transaction identifier (7); - transmission (108) of the digital ticket (14; 28), of the identifier (18; 31) of the digital ticket and of the timestamp (15) of the digital ticket, associated with each other, to a database (5) of digital tickets.

2. Method (100; 200; 300; 400; 600) according to the preceding claim, wherein: - the identifier (18) of the generated digital ticket (107-A) from the transaction identifier is the transaction identifier (7), or - the method comprises a step of hashing (107-B) the transaction identifier (7) so that the digital identifier (18) generated from the transaction identifier (7) is the result of the hashing.

3. Method (500) according to claim 1, comprising the following steps: - before the generation of the digital identifier, transmission (501), from the payment device (2) to the payment terminal (30), of an identifier (32) of the payment device; - the generation (502) of the identifier (31) of the digital ticket from the transaction identifier (7) is carried out by carrying out a combination between the identifier (32) of the payment device and the transaction identifier (7), preferably also by carrying out a hash (502-B) of a result of the combination.

4. Method (400) according to any one of the preceding claims, comprising the following steps: - transmission (401), from the payment device (27) to the payment terminal (3), of an encryption key (19); - encryption of the digital ticket (14) generated by the encryption key (19); and wherein the step of transmitting (403) the digital ticket to the database is the transmission of the encrypted digital ticket (28).

5. Method (100; 200; 400; 500; 600) according to any one of the preceding claims, comprising, before the transmission of the transaction identifier to the payment terminal, a step of selecting (105), from a list of transaction identifiers (6) of the payment device, one of these identifiers (7) with a view to transmitting the selected transaction identifier.

6. Method according to the preceding claim (100; 200; 400; 500; 600), comprising: - a step of counting (200), by a transaction counter (22) of the payment device (21), the number of transactions carried out by the payment device, the selection of the identifier (7) being carried out as a function of this count; or - the selection (105), from the list of transaction identifiers (6) of the payment device, of the identifier (7) located at one end of the list corresponding to a selection position, then the deletion, in the list, of this identifier so that the next identifier in the list is in the selection position for a following transaction.

7. Method (100; 200; 400; 500; 600) according to claim 5 or 6, comprising, prior to the transaction, the following steps: - generation (101) of a list (6) of pseudo-random or random transaction identifiers; - recording (102), within the payment device (2), of this list (6) of transaction identifiers.

8. Method (300) according to any one of claims 1 to 4, comprising, before the transmission of the transaction identifier to the payment terminal, a step of generation (301), by a generator (25) of pseudo-random identifiers of the payment device (24), of this transaction identifier (7).

9. A payment method (700) relating to a transaction, comprising, once the payment has been made, recording a digital ticket relating to the transaction in accordance with the method (100; 200; 300; 400; 500; 600) according to any one of the preceding claims.

10. Method for retrieving (800) a digital ticket relating to a transaction, the digital ticket (14; 28) having been recorded in accordance with any one of claims 1 to 8, comprising the following steps: - obtaining (801) the identifier of the transaction; - generating (802) an identifier of the digital ticket from the transaction identifier; - retrieving (803), in the database (5) of digital tickets, the digital ticket (14; 28) associated with the identifier (18; 31) generated from the digital ticket.

11. A computer program (10; 13; 17) comprising instructions which, when the program is executed by a computer, cause the computer to implement the steps of the registration method (100; 200; 300; 400; 500; 600) according to any one of claims 1 to 8, of the payment method (700) according to claim 9 or of the recovery method (800) according to claim 10.

12. A computer-readable recording medium (9; 12; 16) comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the recording method (100; 200; 300; 400; 500; 600) according to any one of claims 1 to 8, the payment method (700) according to claim 9 or the retrieval method (800) according to claim 10.

13. Database (5) of digital tickets, characterized in that it comprises at least one digital ticket (14; 28) recorded in accordance with the method according to one of claims 1 to 8 (100; 200; 300; 400; 500; 600), the ticket being associated, in the database, with the identifier (18; 31) of the generated ticket and with the timestamp (15) of the ticket.

14. Payment device (2; 21; 24; 27), characterized in that it is specifically configured to implement the steps of the recording method (100; 200; 300; 400; 500; 600) according to any one of claims 1 to 8, of the payment method (700) according to claim 9 or of the recovery method (800) according to claim 10, and in that it comprises: - a list (6) of transaction identifiers or a generator (25) of pseudo-random transaction identifiers; - means of transmission (8), to a payment terminal (3; 30), of a transaction identifier from the list or of a pseudo-random identifier generated by the generator.

15. Payment terminal (3; 30), characterized in that it is specifically configured to implement the steps of the recording method (100; 200; 300; 400; 500; 600) according to any one of claims 1 to 8, of the payment method (700) according to claim 9 or of the recovery method (800) according to claim 10, and in that it comprises automated means capable of: - receiving, from a payment device (2; 21; 24; 27), a transaction identifier (7), - generating an identifier of a digital ticket (18; 31) relating to the transaction from the transaction identifier (7); - transmitting the digital ticket (18; 31), associated with the identifier of the generated digital ticket and the timestamp (15) of the digital ticket, to a database (5) of digital tickets.

Images