Method for recording transaction-related digital tickets

Abstract

The present invention relates to a method for recording digital tickets related to a transaction, the method being implemented by a computer, characterized in that the method includes the following steps: - generating a digital ticket (14) related to the transaction; - timestamping the digital ticket (14); - transmitting a transaction identifier (7) from a payment device (2) for the transaction to a payment terminal (3) for the transaction; - generating (107) an identifier (18; 31) of the digital ticket based on the transaction identifier (7); - transmitting (108) the interrelated digital ticket (14), the identifier (18) of the digital ticket, and the timestamp (15) of the digital ticket to a digital ticket database (5).

Description

Technical Field

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

[0002] This invention relates in particular to the paperless issuance of "cashier receipts". Background Technology

[0003] When a transaction is settled by a payment device through a payment terminal, a receipt and a payment slip are usually printed. These two items are collectively referred to as "receipts" below and are provided to the purchaser so that they can obtain information related to the transaction, especially payment information.

[0004] However, there is a trend toward the disappearance of such paper tickets in order to eliminate the need for paper and save on the purchase and maintenance costs of the components used to print these tickets.

[0005] To continue providing transaction information to buyers, an alternative to paper tickets is to generate digital tickets. Therefore, it is necessary to provide a means to transmit digital tickets associated with a transaction to the buyer who has just completed the transaction.

[0006] One known solution in the prior art involves sending the generated digital ticket to the user via email or SMS. However, this requires the user to provide their email address or phone number to the merchant. This process is binding on the user, prone to errors, and poses risks from the perspective of data confidentiality—the data could be seen or heard, or, in the case of the email address, could be subject to so-called "spear-fishing" attacks. Furthermore, the process is particularly time-consuming when there is high traffic at the checkout counter.

[0007] A solution also known in the art involves enabling tickets to be directly accessed by a user's mobile terminal via near-field communication (NFC) or QR code communication. Thus, a method is known, particularly from documents EP3382628 and KR102444679, in which, after a transaction, the payment terminal used for the transaction transmits a URL via NFC to the mobile terminal used for the transaction, allowing the mobile terminal to access the digital ticket associated with the transaction, or even the ticket itself, in the case of document EP3382628. However, this requires the purchaser to make the payment via a mobile terminal and have a suitable mobile application. Therefore, this process is not suitable for all consumers, not all of whom own smartphones, and even those who do not want to carry their smartphones with them all the time, not want to use their smartphones for transactions, or not want to install numerous mobile applications. The process is also restrictive, as it requires the purchaser to take out and operate their mobile terminal at the time of payment. Furthermore, the process consumes the mobile terminal's power and its memory. Finally, in general, near-field communication (NFC) and QR code usage are both processes that require the use of mobile applications. These applications must be updated regularly to be compatible with all platforms and all versions of those platforms, thus forcing users to update their mobile devices or lose access to their digital tickets. Summary of the Invention

[0008] The present invention aims, in particular, to provide a solution that enables users to access digital tickets associated with transactions, while the payment experience experienced by the user is no different from that associated with paper tickets.

[0009] Therefore, one subject of the present invention is a method for recording digital tickets related to transactions, the method being implemented by a computer and including the following steps:

[0010] - Generate digital invoices related to transactions;

[0011] - Timestamp the digital ticket;

[0012] - Transmitting the transaction identifier from the payment device used for the transaction to the payment terminal used for the transaction;

[0013] - The identifier for this digital ticket is generated based on the transaction identifier;

[0014] - Transmit the interconnected digital tickets, the digital ticket identifier, and the digital ticket timestamp to the digital ticket database.

[0015] Therefore, there is no need for a mobile terminal or to provide contact information to record digital tickets associated with a transaction. During payment, the payment device directly provides the terminal with information that allows the generation of a digital ticket identifier, specifically a transaction identifier unique to that transaction. This identifier, recorded in the payment device, is known to the user's bank, their digital wallet, or the user themselves, enabling the user to subsequently access digital tickets in a database based on that identifier.

[0016] In particular, the payment device may have a list and counter of pre-recorded random or pseudo-random transaction identifiers, which allows a unique identifier to be selected from the list for each transaction, or a generator of pseudo-random transaction identifiers, which allows a unique identifier to be generated for each transaction.

[0017] The payment process remains unchanged compared to that associated with paper tickets. The user experience is even less restrictive, as there's no waiting for a paper ticket during payment, and users decide for themselves whether to retrieve a digital ticket from the database at a time of their choosing.

[0018] The following are other optional features that can be used individually or in combination.

[0019] Advantageously, the digital ticket identifier generated based on the transaction identifier is the same as the transaction identifier, or the method includes the step of hashing the transaction identifier such that the digital identifier generated based on the transaction identifier is the result of the hashing.

[0020] Therefore, the transaction identifier transmitted by the payment device is directly used to generate the identifier of the digital ticket, without any other information, or it is hashed. This 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, hashing prevents the generator's parameters from being obtained by a third party.

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

[0022] - Before generating the digital identifier, the payment device identifier is transmitted from the payment device to the payment terminal;

[0023] - Generating a digital bill identifier based on a transaction identifier is achieved by combining a payment device identifier with a transaction identifier, and preferably by hashing the result of the combination.

[0024] Therefore, in this case, the transaction identifier is not directly converted into a digital ticket identifier. Instead, in addition to the transaction identifier specific to a given transaction, the payment device also transmits a payment device identifier to the payment terminal. This payment device identifier remains the same for every transaction because it represents the payment device. In the case of a bank card, this could be, for example, a PAN ("Primary Account Number") identifier.

[0025] Like transaction identifiers, device identifiers come from the payment device owned by the user and are also known to the bank that issued the payment device, the user's e-wallet, or even the user themselves. This allows users to generate digital bill identifiers at any time so that they can obtain digital bills related to their transactions in the digital bill database.

[0026] Combining the payment device identifier with the transaction identifier enhances the confidentiality of digital tickets. Specifically, when the transaction identifier is generated in a pseudo-random manner, its combination with the payment device identifier prevents third parties from obtaining the digital ticket identifier solely based on the generator's parameters. Furthermore, if the transaction identifier is generated by a specific, untrusted entity during payment device initialization, combining these identifiers with the payment device identifier prevents that entity from obtaining the digital ticket identifier corresponding to the generated identifier without knowing the payment device identifier.

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

[0028] - Transmitting encryption keys from payment devices to payment terminals;

[0029] - Encrypt the generated digital ticket using this encryption key;

[0030] Furthermore, the step of transmitting digital tickets to the database involves transmitting encrypted digital tickets.

[0031] Therefore, the content of the digital ticket is encrypted. This prevents third-party entities from attempting to obtain information, such as generating statistics, through random requests to the digital ticket database. Thus, the encryption key is installed in the payment device during initialization, while the corresponding decryption key is known to the user's bank, their digital wallet, or themselves. This allows the user to decrypt the digital ticket's content when they wish to access it. This key pair can be asymmetric. In this case, the encryption key installed in the device is considered the public key, while the decryption key is a private key and is kept secret by the bank, digital wallet, or the user. Alternatively, the same key can be used for both encryption and decryption.

[0032] Advantageously, the method includes the following steps: selecting one of the transaction identifiers from the payment device's list of transaction identifiers before transmitting the transaction identifier to the payment terminal, so as to transmit the selected transaction identifier.

[0033] Therefore, transaction identifiers are pre-recorded in the payment device as a list. For each transaction, an identifier from this list is used.

[0034] Advantageously, the method includes the following steps:

[0035] - The number of transactions processed by the payment device is counted by the payment device's transaction counter, and the identifier is selected based on this count; or

[0036] - Select the identifier located at the end of the list of transaction identifiers of the payment device that corresponds to the selection position, and then delete the identifier from the list so that the next identifier in the list is in the selection position for the next transaction.

[0037] Therefore, to avoid selecting the same identifier twice for two different transactions, two possible solutions are provided: In the case of counting, the payment device's counter increments its count to select the identifier corresponding to the count. Alternatively, the selected transaction identifier is the one at the end of the payment device's transaction identifier list. This identifier is deleted after the transaction, allowing the next identifier in the list to be selected for the next transaction. This eliminates the need for a counter.

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

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

[0040] - Record the list of transaction identifiers in the payment device.

[0041] Therefore, these steps are performed when initializing the payment device, for example, when the payment device is a payment card, during the manufacturing of the payment card.

[0042] Alternatively, the method includes the following steps: generating the transaction identifier by a pseudo-random transaction identifier generator within the payment device before transmitting the transaction identifier to the payment terminal.

[0043] Therefore, in this scenario, the list of transaction identifiers is not stored in the payment device. Instead, an identifier generator is integrated into the device, which generates a transaction identifier for each transaction. This generator produces identifiers in a pseudo-random manner. Banks, digital wallets, or users all have the same generator, thus generating the same identifiers so that the digital tickets can be retrieved in a database.

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

[0045] - Create a pseudo-random transaction identifier generator;

[0046] - Set the generator within the payment device.

[0047] Preferably, the method includes: updating the list of random or pseudo-random transaction identifiers or the generator of the pseudo-random identifiers by the ATM within the payment device.

[0048] Therefore, users can "recharge" their list of transaction identifiers through the ATM.

[0049] Another subject of the present invention is a transaction-related payment method, which includes recording a digital ticket related to the transaction according to the method described above after the payment is completed.

[0050] Another subject of the present invention is a method for obtaining a transaction-related digital ticket, which has been recorded according to any one of the preceding claims, the method comprising the following steps:

[0051] - Obtain the transaction identifier;

[0052] - Generate a digital bill identifier based on this transaction identifier;

[0053] - Retrieve the digital ticket associated with the generated digital ticket identifier from the digital ticket database.

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

[0055] Preferably, the acquisition method includes the following steps:

[0056] - Obtain the payment device identifier before generating the digital identifier;

[0057] - A digital ticket identifier is generated by combining a payment device identifier with a transaction identifier, preferably by hashing the result of the combination.

[0058] Advantageously, the ticket has been encrypted during the recording process according to the method described above, and the acquired digital ticket is decrypted using a decryption key.

[0059] The subject matter of this invention also includes a computer program comprising instructions that, when executed by a computer, cause the computer to perform the steps of the above-described recording method, payment method, or acquisition method.

[0060] The subject matter of the present invention also includes a computer-readable recording medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the above-described recording method, payment method, or acquisition method.

[0061] The subject matter of this invention also includes a digital ticket database comprising at least one digital ticket recorded according to the method described above, the ticket being associated in the database with a generated ticket identifier and a timestamp of the ticket.

[0062] The subject matter of this invention also includes a payment device comprising:

[0063] - Payment device identifier;

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

[0065] - A transmission device for transmitting payment device identifiers to payment terminals;

[0066] - A transmission device for transmitting transaction identifiers from a list or pseudo-random identifiers generated by a generator to a payment terminal.

[0067] Preferably, the device further includes an encryption key, and the aforementioned transmission device is also adapted to transmit the key.

[0068] Advantageously, the device also includes a transaction counter.

[0069] The subject matter of the invention also includes a payment terminal comprising an automation device adapted to:

[0070] - Receive transaction identifier from payment device;

[0071] - Generate an identifier for the digital ticket associated with the transaction based on the transaction identifier;

[0072] - Transfer the digital ticket, associated with the generated digital ticket identifier and the digital ticket's timestamp, to the digital ticket database.

[0073] Advantageously, the automation device is also suitable for:

[0074] - Receive the identifier of the payment device from the payment device;

[0075] - A digital ticket identifier is generated by combining a payment device identifier with a transaction identifier, preferably by hashing the result of the combination. Attached Figure Description

[0076] The invention will be better understood by reading the following description, given only as an example and with reference to the accompanying drawings, in which:

[0077] Figure 1 This is a schematic diagram of a system for recording digital tickets related to transactions, according to the first embodiment;

[0078] Figure 2 Through Figure 1 A flowchart of the first implementation method of a system for recording transaction-related documents;

[0079] Figure 3 This is a schematic diagram of a system for recording digital tickets related to transactions, according to the second embodiment.

[0080] Figure 4 Through Figure 3 A flowchart of the second embodiment of the method implemented by the system;

[0081] Figure 5 This is a schematic diagram of a system for recording digital tickets related to transactions, according to a third embodiment.

[0082] Figure 6 Through Figure 5 The flowchart of the third embodiment of the method is shown below;

[0083] Figure 7 This is a schematic diagram of a system for recording digital tickets related to transactions, according to the fourth embodiment.

[0084] Figure 8 Through Figure 7 The flowchart of the fourth embodiment of the method is shown below;

[0085] Figure 9 This is a schematic diagram of a system for recording digital tickets related to transactions, according to the fifth embodiment;

[0086] Figure 10 Through Figure 9 The flowchart of the fifth embodiment of the method is shown below;

[0087] Figure 11 This is a flowchart of the update method;

[0088] Figure 12 This is a flowchart of the payment method;

[0089] Figure 13 This is a flowchart of the digital ticket acquisition method. Detailed Implementation

[0090] Figure 1 System 1 is a system for recording digital tickets related to transactions. It includes a payment device 2 in the form of a payment chip card 2. System 1 also includes a payment terminal 3. System 1 further includes a server 4 and a digital ticket database 5.

[0091] The term "payment device" refers to any device suitable for making payments on the buyer's side, such as a mobile terminal or any connected device, provided that the payment device is configured to make payments in conjunction with a payment terminal. Payment device 2 internally includes an identifier 32 ("Primary Account Number"). It also includes means for making payments according to protocols known to those skilled in the art, which will not be described in detail here.

[0092] Payment device 2 also includes a list of transaction identifiers 6. These can be in any format known to those skilled in the art, such as random numbers represented in hexadecimal or "base64" format to become readable. These identifiers are generated in advance in a pseudo-random or random manner. Advantageously, these identifiers are generated in a purely random manner. In practice, in this case, a malicious third party cannot identify certain common characteristics among these identifiers based on a portion of the list to generate other identifiers in that list. However, generating identifiers in a pseudo-random manner, i.e., generating identifiers that are sufficiently independent of each other and exhibit certain random characteristics in the sequence of identifiers, is simpler and generally sufficient. Device 2 includes a transmission means 8 for transmitting the transaction identifiers 7 of list 6 to payment terminal 3. Card 2 also includes a computer-readable recording medium 9, particularly a microprocessor-readable recording medium 9, which includes instructions that, when executed by such a microprocessor, cause the microprocessor to perform all or part of the steps of the following methods: different implementations of the recording methods 100, 200, 300, 400, 500, or 600 described below, or the payment method 700 described below, or the acquisition method 800 described below. For this purpose, the medium 9 includes a computer program 10. The program 10 includes instructions that, when executed by a computer, particularly a microprocessor, cause it to perform all or part of the steps of the following methods: different implementations of the recording method 100, 200, 300, 400, 500 or 600 described below, or the payment method 700 described below, or the acquisition method 800 described below.

[0093] The term "payment terminal" refers to any device suitable for participating in seller-side payments. Payment terminal 3 includes a communication device 11 that communicates with payment device 2; this device is known to those skilled in the art and will not be described in detail here. Terminal 3 also includes means for making payments according to protocols known to those skilled in the art, which will not be described in detail here. It also includes a computer-readable recording medium 12, particularly a microprocessor-readable recording medium 12, which includes instructions that, when executed by such a microprocessor, cause the microprocessor to perform all or part of the steps of: different embodiments of the recording method described below 100, 200, 300, 400, 500, or 600, or the payment method described below 700, or the acquisition method described below 800. For this purpose, the medium 12 includes a computer program 13. Program 13 includes instructions that, when executed by a computer, particularly a microprocessor, cause it to perform all or part of the steps of the following methods: different implementations of the recording method described below, 100, 200, 300, 400, 500, or 600, or the payment method described below, 700, or the acquisition method described below, 800.

[0094] In particular, by combining the conventional means of payment terminal 3 with means specifically configured to implement the methods described below, terminal 3 specifically includes automation means adapted to:

[0095] - Receive transaction identifier 7 from payment device 2;

[0096] - Identifier 18 is generated based on transaction identifier 7 to create digital ticket 14;

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

[0098] Database 5 comprises transaction-related digital tickets in tabular form, either encrypted or plaintext. Each of these tickets is associated with a digital ticket identifier 18, generated according to embodiments 100, 200, 300, 400, 500, or 600 of the recording methods described below. Each of these tickets is also associated with a timestamp 15, which allows determination of the time when the ticket was generated. Server 4 allows access to, reading, and modification of the contents of the digital ticket database 5. Therefore, server 4 includes means conventional to those skilled in the art for this purpose. It includes means for communicating with payment terminal 3. It also includes a computer-readable recording medium 16, particularly a microprocessor-readable recording medium 16, which includes instructions that, when executed by such a microprocessor, cause the microprocessor to perform all or part of the steps of: embodiments 100, 200, 300, 400, 500, or 600 of the recording methods described below, or payment method 700 described below, or acquisition method 800 described below. For this purpose, the medium 16 includes a computer program 17. The program 17 includes instructions that, when executed by a computer, particularly a microprocessor, cause it to perform all or part of the steps of the following methods: implementations 100, 200, 300, 400, 500, or 600 of the recording method described below, or the payment method 700 described below, or the acquisition method 800 described below.

[0099] Therefore, the three computer programs 10, 13 and 17 described above 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] Implementations 100 to 600 of a method for recording digital tickets related to transactions will now be described, the method being implemented by a computer, particularly by an automated device comprising a payment device 2, a payment terminal 3, and a server 4. Those skilled in the art will readily understand which implementations can be combined together.

[0101] First, describe the... Figure 1 The implementation method 100 of system 1.

[0102] Step 101, performed before the transaction, is to generate a list 6 of pseudo-random or random transaction identifiers. This is done by an entity outside the system, such as the bank that issued the payment card 2. For the aforementioned security reasons, a list of "random" identifiers is preferred over a list of "pseudo-random" identifiers, although generating a pseudo-random list is generally simpler.

[0103] Step 102 is to record the list 6 of the transaction identifier in the payment device 2.

[0104] A parallel implementation step involves an external entity, such as the bank issuing the payment device, the user's e-wallet, or the user themselves, recording this list 6 in a dedicated database for later retrieval of digital tickets. For this purpose, if the identifiers are generated in a purely random manner, they are transmitted to the external entity, as the external entity cannot find them on its own. Conversely, if they are generated in a pseudo-random manner using a pseudo-random generator, the external entity can utilize the same generator and generate the same identifiers based on known parameters.

[0105] The following steps are performed during a transaction between a purchaser with payment card 2 and a merchant with payment terminal 3. The purchaser makes payment through the interaction between their card 2 and terminal 3.

[0106] Step 103 involves generating a digital receipt 14 associated with the transaction. This receipt 14 is generated by the payment terminal 4 used for the transaction, optionally in conjunction with the merchant's cash register, and generated according to a protocol not pertaining to the subject of this invention. The digital receipt 14 is a cash register slip containing transaction-related information such as the purchased items, price, taxes, transaction date, time, and merchant name. This digital receipt 14 essentially contains the same information as a traditionally printed paper cash register slip.

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

[0108] Step 105 involves selecting one of the identifiers 7 from the transaction identifier list 6 of the payment device used for the transaction, in order to transmit the selected transaction identifier 7. To do this, the payment terminal 3 selects the identifier 7 located at the end of the list 6 corresponding to the selection position. Then, the terminal 3 and / or the payment device 2 removes the identifier 7 from the list 6, so that the next identifier 7 in the list 6 is placed at the selection position for the next transaction.

[0109] Step 106 involves transmitting the selected transaction identifier 7 from payment device 2 to payment terminal 3. This identifier will only be used for this transaction.

[0110] Step 107-A generates identifier 18 for digital note 14 based on transaction identifier 7. In this variant, identifier 18 for digital note 14 generated based on transaction identifier 7 is transaction identifier 7 itself.

[0111] In the second variation, step 107-B hashes the transaction identifier 7 so that the identifier 18 generated based on the transaction identifier 7 is the result of the hashing. This variation improves security. Specifically, if the transaction identifier 7 is generated in a pseudo-random and non-random manner, the hashing process can limit the risk of the identifier being discovered by a third party.

[0112] Step 108 involves transmitting the associated digital ticket 14, digital ticket identifier 18, and timestamp 15 of digital ticket 14 to the digital ticket database 5. This transmission is performed by the payment terminal 3. In a variant not shown, it is performed by the merchant's cash register.

[0113] Figure 3 System 20 and Figure 1 The difference in the system is that the payment device 21 also includes a transaction counter 22.

[0114] pass Figure 3 System 21 implementation Figure 4 Implementation method 200 and Figure 2 The difference in implementation 100 is that instead of selecting an identifier at a certain position in the list and deleting it, the selection step includes a counting step. This counting step involves the transaction counter 22 of the payment device 21 counting the number of transactions made by the payment device 21, and the selection of identifier 7 is based on this count. For example, for the eighth transaction made by the payment device 21, the eighth identifier in the identifier list 6 is selected.

[0115] Figure 5 System 23 and Figure 1 and Figure 3 The difference between System 1 and 20 is that Payment Device 24 includes a pseudo-random transaction identifier generator 25, replacing List 6.

[0116] pass Figure 5 System 23 implementation Figure 6 The difference between implementation 300 and the aforementioned implementation is that it includes the following steps as described below.

[0117] Step 301 involves pre-creating a pseudo-random transaction identifier generator 25. This is done by an entity outside the system, such as the bank that issues the payment device 24.

[0118] Step 302 involves setting the generator 25 within the payment device 24.

[0119] A parallel step, not shown, is to set up the same generator at a bank, the user's e-wallet, the user themselves, or any entity that allows the user to subsequently generate the same transaction identifier as the generator 25 set up within payment device 24. For these generators to produce the same value, both must be pseudo-random and have the same parameters. Two purely random generators will not produce the same value.

[0120] Step 303 involves generating transaction identifier 7 by the pseudo-random transaction identifier generator 25 within the payment device 24 before transmitting it to the payment terminal 3. Therefore, it is this identifier 7, rather than an identifier selected from a list, that is transmitted and used to generate the digital ticket identifier 18. In the next transaction, another transaction identifier will be generated.

[0121] Figure 7 The difference between system 26 and the aforementioned systems is that, in addition to the components mentioned in the various embodiments, payment device 27 includes an encryption key 19, referred to as the "public" key. Transmission device 8 is also adapted to transmit this encryption key 19 to payment terminal 3. The corresponding decryption key, referred to as the private key, is held by an entity outside the system, such as the bank that issued payment device 27, the user's e-wallet, or the user themselves. As a variation, in a symmetric encryption system, the same key is used for both encryption and decryption.

[0122] pass Figure 7 System 26 implemented Figure 8 The difference between implementation 400 and the method described above is that it includes the additional steps described below.

[0123] Step 401 involves transmitting the public encryption key 19 from the payment device 27 to the payment terminal 3.

[0124] Step 402 involves encrypting the generated digital ticket 14 using an encryption key. This encryption is performed by the payment terminal 3 using a key obtained from the payment device 27.

[0125] Then, instead of transmitting the plaintext digital ticket 14 to database 5, transmission step 403 transmits the encrypted digital ticket 28. The encrypted digital ticket 28 is the one associated with the identifier 18 and timestamp 15 of ticket 14 in database 5.

[0126] The advantage of this implementation 400 is that it prevents third parties from making statistics based on digital tickets obtained in plaintext. It also allows for conflict management via decryption, as described below.

[0127] Figure 9 The difference between system 29 and the aforementioned systems is that the automated device of payment terminal 30 is also suitable for:

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

[0129] - The identifier 31 of the digital ticket 14 is generated by combining the identifier 32 of the payment device 2 with the transaction identifier 7, and by hashing the result of the combination. The combination is described below.

[0130] pass Figure 9 The system implemented in system 29 Figure 10 The implementation method 500 differs from the aforementioned method in that it includes the steps described below.

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

[0132] Step 502-A generates the identifier 31 of the digital ticket. It is not performed solely based on the transaction identifier 7 as in method 100. Instead, it is performed by combining the payment device identifier 32 with the transaction identifier 7. This combination is a concatenation of the transaction identifier 7 and the payment device identifier 32. Alternatively, the transaction identifier 7 and the card identifier 32 are converted to binary numbers, and the combination is an XOR operation between these two binary identifiers. Other types of combinations also apply. The result of this combination is the digital identifier 31 of ticket 14, which is associated with ticket 14 or encrypted ticket 28 in database 5.

[0133] In one variation, step 502-B differs from step 502-A in that the result of the combination is hashed. Therefore, the hash value of the combined result is the digital identifier 32 of the ticket, and it is associated with ticket 14 or encrypted ticket 28 in database 5.

[0134] Compared to the aforementioned implementation that only requires a transaction identifier to generate a digital ticket identifier, this implementation 500 further enhances security. Even when the transaction identifier is generated in a purely random manner, this implementation remains advantageous because it allows different entities without a trust relationship to each other to create their own identifiers and payment devices. In fact, in the case where entity A only creates a transaction identifier and transmits it to entity B, while entity B creates the payment device and generates a payment device identifier, combining the payment device identifier with the transaction identifier prevents entity A, which stores the generated transaction identifiers, from attempting to access digital tickets generated based on those transaction identifiers.

[0135] Figure 11Method 600 is an update method relating to all the aforementioned embodiments of the recording method. It includes updating the pseudo-random or random transaction identifier list 6 or the pseudo-random identifier generator 25 described above within the payment device 2 by the ATM. Thus, when a purchaser inserts their card 2 into the ATM, they have the possibility of updating the list when the card is working according to embodiment 100 or 200, or updating the generator when the card is working according to method 300. Method 600 can be viewed both as an additional step in the recording method according to one of embodiments 100 to 500, and as a new embodiment 600 of the recording method.

[0136] In another embodiment, not shown, the list or generator is updated via a user's mobile application.

[0137] Figure 12 Method 700 is a transaction-related payment method that includes recording a transaction-related digital ticket 14 according to embodiments 100 to 600 of the digital ticket recording method described above after payment is completed. Therefore, the user makes a payment using their payment card, and the transaction-related digital ticket is recorded in the database according to embodiments 100 to 600.

[0138] Figure 13 Method 800 is a method for obtaining a digital ticket related to a transaction, which has been recorded according to one of the aforementioned recording methods. The user's purpose is to obtain a ticket corresponding to a previously conducted transaction.

[0139] Step 801 is to obtain the transaction identifier. This step is feasible because, according to the implementation of the aforementioned recording method, the transaction identifier is also held by an external entity, whether it is a bank, the user's wallet, or the user themselves.

[0140] Step 802 generates a digital ticket identifier based on the transaction identifier. This step is the same as the step performed by the payment terminal in different embodiments of the recording method. Therefore, if the transaction identifier is a digital identifier, as in step 107-A of embodiment 100, this acquisition method also follows this pattern. If hashing is required as in step 107-B, the same hashing is performed here, i.e., the same hash function is applied to the transaction identifier, thereby generating the same digital ticket identifier when the transaction identifier is the same. Similarly, if the payment device identifier is combined with the transaction identifier as in step 502-A of embodiment 500, step 802 includes obtaining the payment device identifier and generating a digital ticket identifier by performing the same combination between the payment device identifier and the transaction identifier. Furthermore, if hashing is performed as in step 502-B, the same hash function is applied to the combination result, thereby generating the same digital ticket identifier.

[0141] Step 803 involves retrieving the digital ticket associated with the generated digital ticket identifier from the digital ticket database 5. Therefore, users can easily obtain the digital ticket associated with their transaction only when and at the desired time, without affecting their payment experience.

[0142] If the digital ticket was encrypted according to implementation method 400 of the recording method, step 804 is performed. Since the ticket was encrypted at the time of recording, and the private key is held by the bank, digital wallet, or the user, the obtained digital ticket is decrypted using the decryption private key. The user then obtains the plaintext digital ticket. As a variation, in a symmetric encryption system, the same key is used for both encryption and decryption.

[0143] Besides preventing the counting of plaintext tickets, the encryption and decryption steps also allow for the resolution of potential collisions. In practice, it is theoretically possible for two different users to have the same ticket identifier. Since each user has their own decryption key, a user can only obtain the ticket decrypted using their own key and cannot access the ticket of another user.

[0144] This invention is not limited to the described embodiments, and other embodiments will be apparent to those skilled in the art.

[0145] First, as previously stated, those skilled in the art will readily understand that some of the described embodiments can be combined with each other. Therefore, encrypting or not encrypting the digital ticket according to embodiment 400 is independent of other steps of the method. Various possible hashing processes are also independent of other steps. Generating a digital identifier by combining a payment device identifier and a transaction identifier is different from generating the ticket identifier solely based on the transaction identifier. However, both embodiments are ways of generating a digital ticket identifier based on a transaction identifier; one embodiment does not require other elements, while the other requires a payment device identifier. The existence of a list of identifiers in the payment device does not preclude the existence of an identifier generator, although both schemes are redundant. Similarly, selecting an identifier by choosing an identifier at a specific position in the list and deleting it does not preclude selecting an identifier by counting transactions, although both identifier selection schemes are also redundant.

[0146] As mentioned earlier, the list or generator of transaction identifiers, the hash function, and the decryption key are held by an external entity such as a bank or e-wallet. It will be readily apparent to those skilled in the art that any other entity enabling a user to access their digital tickets may also hold these elements. This entity could be any platform associated with the system where the user can authenticate and have a private account containing the list or generator of identifiers, and possibly also the hash function and decryption key.

[0147] The digital tickets mentioned in this specification correspond to cash register receipts. However, any "transaction-related" ticket falls within the scope of this invention. This can be a payment ticket listing payment information related to a transaction; or a ticket related to information about a purchased product, such as product warranty information. Thus, a user can obtain information about their product, such as warranty information, by accessing the ticket when desired. It can also be information related to purchased event tickets, as the event is directly associated with the transaction.

[0148] List of reference numerals

[0149] 1: Digital Invoice Recording System

[0150] 2: Payment devices

[0151] 3: Payment terminal

[0152] 4: Server

[0153] 5: Database

[0154] 6: List of Transaction Identifiers

[0155] 7: Transaction Identifier

[0156] 8: Payment equipment communication device

[0157] 9: Payment device data medium

[0158] 10: Payment device computer program

[0159] 11: Payment terminal communication device

[0160] 12: Payment terminal data medium

[0161] 13: Payment terminal computer program

[0162] 14: Plaintext Digital Tickets

[0163] 15: Digital Ticket Timestamp

[0164] 16: Server data media

[0165] 17: Server computer program

[0166] 18: Digital Ticket Identifier

[0167] 19: Encryption Key

[0168] 20: Digital Invoice Recording System

[0169] 21: Payment devices

[0170] 22: Transaction Counter

[0171] 23: Digital Invoice Recording System

[0172] 24: Payment devices

[0173] 25: Pseudo-random transaction identifier generator

[0174] 26: Digital Invoice Recording System

[0175] 27: Payment devices

[0176] 28: Encrypted Digital Tickets

[0177] 29: Digital Invoice Recording System

[0178] 30: Payment Terminal

[0179] 31: Digital Ticket Identifier

[0180] 32: Payment Device Identifier

[0181] 100, 200, 300, 400, 500: Digital Invoice Recording Methods

[0182] 600: Method for updating transaction identifiers or identifier generators

[0183] 700: Payment Methods

[0184] 800: How to Obtain Digital Tickets

Claims

1. A method for recording digital tickets related to transactions (100; 200; 300; 400; 500; 600), said method being implemented by a computer, characterized in that, The method includes the following steps: - Generate (103) digital notes related to the transaction (14; 28); - The digital tickets (14; 28) are timestamped (104); - Transmit (106) transaction identifier (7) from the payment device (2; 21; 24; 27) used for the transaction to the payment terminal (3; 30) used for the transaction; - Generate (107) the identifier (18; 31) of the digital ticket based on the transaction identifier (7); - Transmit (108) the interconnected digital tickets (14; 28), the identifiers of the digital tickets (18; 31), and the timestamps (15) of the digital tickets to the digital ticket database (5).

2. The method according to the preceding claim (100; 200; 300; 400; 600), wherein: - The identifier (18) of the digital ticket generated based on the transaction identifier (107-A) is the transaction identifier (7); or - The method includes the step of hashing the transaction identifier (7) (107-B) such that the numeric identifier (18) generated based on the transaction identifier (7) is the result of the hashing.

3. The method (500) according to claim 1, comprising the following steps: - Before generating the digital identifier, the identifier (32) of the payment device is transmitted (501) from the payment device (2) to the payment terminal (30). - The identifier (31) of the digital ticket is generated (502) based on the transaction identifier (7) by combining the identifier (32) of the payment device with the transaction identifier (7), preferably by hashing the result of the combination (502-B).

4. The method (400) according to any one of the preceding claims comprises the following steps: - Transmit (401) encryption key (19) from the payment device (27) to the payment terminal (3); - The generated digital ticket (14) is encrypted using the encryption key (19); The step (403) of transmitting the digital ticket to the database is to transmit the encrypted digital ticket (28).

5. The method according to any one of the preceding claims (100; 200; 400; 500; 600) includes the following selection step (105): selecting one of the identifiers (7) from the transaction identifier list (6) of the payment device before transmitting the transaction identifier to the payment terminal, so as to transmit the selected transaction identifier.

6. The method according to the preceding claim (100; 200; 400; 500; 600), comprising: - In the step (200) of counting the number of transactions made by the payment device (21) using the transaction counter (22), the selection of the identifier (7) is based on this count; or - Select (105) an identifier (7) located at one end of the list corresponding to the selection position from the transaction identifier list (6) of the payment device, and then delete the identifier from the list so that the next identifier in the list is in the selection position for the next transaction.

7. The method according to claim 5 or 6 (100; 200; 400; 500; 600), comprising the following steps prior to the transaction: - Generate a list of (101) pseudo-random or random transaction identifiers (6); - The transaction identifier list (6) is recorded (102) in the payment device (2).

8. The method (300) according to any one of claims 1 to 4, comprising the following generation step (301): the transaction identifier (7) is generated by a pseudo-random identifier generator (25) of the payment device (24) before the transaction identifier is transmitted to the payment terminal.

9. A transaction-related payment method (700) comprising recording a digital ticket related to the transaction after the payment is completed, according to a method (100; 200; 300; 400; 500; 600) as described in any of the preceding claims.

10. A method (800) for obtaining a digital ticket related to a transaction, said digital ticket (14; 28) having been recorded according to any one of claims 1 to 8, said method comprising the steps of: - Obtain the transaction identifier described in (801); - Generate (802) the identifier of the digital ticket based on the transaction identifier; - Obtain (803) the digital ticket (14; 28) associated with the identifier (18; 31) of the generated digital ticket in the digital ticket database (5).

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

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

13. A digital invoice database (5), characterized in that, The digital ticket database (5) includes at least one digital ticket (14; 28) recorded according to the method (100; 200; 300; 400; 500; 600) as described in any one of claims 1 to 8, the ticket being associated in the database with an identifier (18; 31) of the generated ticket and a timestamp (15) of the ticket.

14. A payment device (2; 21; 24; 27), characterized in that, The payment device includes: - A list of transaction identifiers (6) or a pseudo-random transaction identifier generator (25); - A transmission device (8) for transmitting transaction identifiers from the list or pseudo-random identifiers generated by the generator to payment terminals (3; 30).

15. A payment terminal (3; 30), characterized in that, The payment terminal includes an automation device, which is adapted to: - Receive transaction identifier (7) from payment device (2; 21; 24; 27); - Generate an identifier (18; 31) for the digital ticket associated with the transaction based on the transaction identifier (7); - Transmit the digital tickets (18; 31) associated with the identifier of the generated digital ticket and the timestamp (15) of the digital ticket to the digital ticket database (5).

Images