AU2021101937A4 - Systems and methods for the delivery of digital receipts to shoppers by post-purchase transaction matching via an aggregator without the need to acquire shoppers’ consent at the counter while remaining compliant to privacy legislations - Google Patents

Abstract

Systems and methods for the delivery of digital receipts to consumers via post purchase transaction matching by an aggregator without the need to acquire shoppers' consent at the counter even when sending the data of all receipts to the aggregator wherein all receipt contents are encrypted at the point of sale system using random independent data encryption keys before being sent to the aggregator, with such data encryption keys being encrypted themselves using an asymmetric encryption method based on key encryption keypairs owned by the card issuers that send transaction data of shoppers who have provided consent to aggregators. With point of sale systems able to look up the public key encryption keys relevant to a transaction, all receipts get encrypted before being sent to the aggregator until a moment when the relevant card issuer provides the relevant private key encryption key to the aggregator to decrypt the data encryption keys and receipt contents available to the aggregator, assuring that the aggregator maintains zero knowledge of the receipts whose owners have not provided consent to their card issuers. -,0 0 -'C a a)p -0 D c0 ( 0 Co (0 _0(0 3 0 0~ 0n -0 Fn0 (0 C,) (D _0 (0 C~ I E3t 0 0 .0 in - 0 CD w< IR (00 cr~ ~ (0 ( wL 0-0 = Qc )(00 ) - 0C~ 0 m 0 9aD. CD 0 = ;s (n I U) (0 I < -L ID w o -I - -0 g D m 0 0LC r C I 0(0- o ff c a)/) IDCW --10 0 < -' (< CL) (00 (0 (0 CD (0 a) =r( (0 3 M *0 CD iDlC 0 mj0

Description

-,0

0

-'C a a)p 0 -0 D c0 ( Co (0 _0(0

3 0 0~ 0n

-0 Fn0

(0

C,) (D _0 (0 0 C~I E3t 0 .0

in- 0

cr~ CD ~ (0 w< ( IR (00 wL 0-0 = Qc )(00 ) -

0C~

0 m 9 aD. 0CD 0 = ;s (n

I U)

(0 I < -L

ID w o -I - -0

g D m

0 0LC r C

I 0(0- o ff c

a)/) IDCW --10 0 <

-' (< CL)

(00 (0 (0

CD

(0 a) =r(

(0 3

M *0 CD iDlC 0 mj0

SYSTEMS AND METHODS FOR THE DELIVERY OF DIGITAL RECEIPTS TO SHOPPERS BY POST-PURCHASE TRANSACTION MATCHING VIA AN AGGREGATOR WITHOUT THE NEED TO ACQUIRE SHOPPERS' CONSENT AT THE COUNTER WHILE REMAINING COMPLIANT TO PRIVACY LEGISLATIONS TECHNICAL FIELD

This invention pertains to the field of retail technology and cryptography.

BACKGROUND

One of the challenges of delivering digital receipts to consumers is the need to identify consumers at the counter by merchants to deliver digital receipts to them. Examples include collecting email addresses or phone numbers at the counter to send receipts electronically. Consumer privacy is a major challenge with such methods since most consumers do not feel comfortable providing identifying information to operators over the counter. Other than advanced privacy-preserving end-to-end encrypted receipt and invoice delivery schemes like (Sadler, 2019a, Sadler, 2019b), some have tried the mechanism of matching transaction data, which is provided by banks, financial institutes and payment card issuers, with a stream of receipt data provided by merchants' point of sale systems to be able to map receipts to transactions without the collection of personal details at the counter. In these schemes, at a later point, once a receipt is mapped to a transaction, the financial institute takes on the task of displaying the delivered receipt to the consumer who hold an account with such institutes in the form of an attachment to the relevant transaction. This class of receipt delivery techniques require a data feed of all receipt data from point-of-sale systems, as well as transaction data from payment card issuers. This style of receipt delivery is mostly carried out by a receipt data aggregator that could be independent and eliminate the need to collect personal data at the counter to deliver receipts to their respective owners. Privacy legislations like GDPR and CCPA require the collection of consent from consumers before their data is handed over to a 3 rd

party like a receipt aggregator or their card issuers, especially for naturally-sensitive information like medical data and medications on pharmacy receipts or other relevant cases. Currently, in order to avoid change of consumer or POS operator behaviour, some defer the process of consent collection to card issuers. Accordingly, in their transaction data stream, card issuers will only include transaction data for those consumers who have provided their consent to the receipt aggregation program. Despite the fact that receipt aggregators receive all receipt data from POS systems, they only route the ones whose owners have provided consent to their card issuers and may and should discard other receipts data. However, in these schemes, the need to send the data related to all receipts from point-of-sale systems to the aggregator creates a need to ask every shopper about their consent before data can be sent out to the aggregator, otherwise, no such receipts can be sent to the aggregator without the shoppers' consent which requires a change of behaviour for shoppers and POS operators, creating barriers of adoption and inconveniences of use and potential legal and legislative compliance issues.

Accordingly, there is a clear need to improve the methods and systems of digital receipt delivery via an aggregator in which the need to seek and collect consent at the counter is eliminated to help such transaction matching algorithms remain legislatively compliant without requiring the collection of consent from every shopper at the counter, which this invention addresses.

SUMMARY OF INVENTION

The problem stated above with existing systems and methods of digital receipt delivery between receipt issuers and shoppers via transaction matching performed by receipt aggregators is that for such transaction matching methods to work, they require data streams of all receipts from receipt issuers and transaction data provided by card issuers belonging to shoppers who have provided consent to their payment card issuers to receive their receipts via the method. Since the data of all receipts are sent to the aggregator, all shoppers have to be asked for their consent at the counter which is inconvenient and impractical otherwise, such methods cannot be used without consent collection from all shoppers to remain compliant to privacy rules.

To eliminate needs of collecting shoppers' consent at the counter by receipt issuers, a novel transaction matching algorithm is hereby proposed that either assures aggregator's zero knowledge of receipt contents until the moment card issuers provide transaction data of those shoppers who have provided their consent to their card issuers hence assuring that the receipt issuer and the aggregator remain legislatively compliant despite not having collected consent from shoppers before sending receipt data to the aggregator, or, alternatively avoids sending the contents of all receipts to the aggregator until after the matching process has succeeded.

In one embodiment, the proposed invention enables the aggregator to receive all receipt data without collecting consent or without facing implementation complexities (e.g. pulling back receipts from POS upon request which requires two-sided communication to POS systems). This embodiment includes the encryption of all receipt data with randomly generated symmetric Data Encryption Keys (DEKs) at the point of sale system, before sending the encrypted data to the aggregator, and then encrypting the DEKs using an asymmetric encryption algorithm with public and private Key Encryption Keys (KEKs) generated by and known to the card issuers that send transaction data to the aggregator, with only the public keys of such encryption methods being shared with the point of sale system and looked up, at the time of issuing the receipt, from a publicly available key chain, using techniques like looking up the first few digits of a Personal Account Number (PAN) of a payment card. Point of sale systems then include the encrypted DEKs with the receipt data when sending data to the aggregator. With the card issuing institute being the party owning the private key of such asymmetric encryption methods, such card issuers can supply the private KEKs, only for the receipts that relate to them and they have consent for, to the aggregator together with transaction metadata, enabling the aggregator to decrypt such DEKs and receipt contents only for the receipts that card issuers have received consent from their respective owners of.

In another embodiment, the aggregator does not receive the contents of all receipts upfront. The merchant point of sale system only supplies transaction processing meta data without receipt contents for all transactions to the aggregator. After matching the transaction with the data stream that the aggregator receives from card issuers, the aggregator then pulls the contents of receipts for the matched transactions from the point of sale system, which requires the merchant point of sale system to be implemented in such a way that enables it to respond to such pull requests, as an implementation complexity consideration. As a result, not all receipt contents are uploaded to the aggregator except the ones that there is consent for by the card issuers.

The benefits of the proposed trolley include the followings:

1) The fact that private KEKs of those receipts whose owners have not provided their consents to card issuers remain unknown to the aggregator in the proposed invention assures that the aggregator won't have access to such receipt data despite having received their encrypted form from point of sale systems hence the need for collecting consent from consumers at the counter is eliminated while remaining complaint to privacy legislations.

2) The fact that the aggregator remains unable to have access to all receipts contents until a selected subset of them, whose owners have provided consent to their card issuers, can become available to the aggregator via the relevant card issuer providing the private KEKs to the aggregator, assures that the merchant and the aggregator remain legislatively compliant despite not having collected explicit consent before sending shoppers' data out of point of sale systems, helping the elimination of needs to seek consent or change consumer behaviour or needs to have a high degree of trust to the aggregator to dispose of the receipts data they don't have explicit consent to have access to.

DESCRIPTION OF THE DRAWINGS

Figure 1 demonstrates the high-level steps of the proposed post-purchase matching algorithm that eliminates needs for consent collection at the counter using cryptography and zero-knowledge enforcement for receipts whose owners have not given consent to their card issuers for receipt delivery despite the aggregator receiving the data of all receipts.

Figure 2 demonstrates the high-level steps of another embodiment of the proposed post-purchase matching algorithm that eliminates needs of consent collection via deferring the supplying of receipt data to the aggregator to after transaction matching.

DETAILED DESCRIPTION OF INVENTION

The inventor hereby proposes a method to facilitate the delivery of digital receipts to shoppers via post-purchase transaction matching performed by an aggregator which hands over receipts to shoppers' card issuers that unlike existing methods, does this without the necessity of collecting consent from shoppers at the counter while remaining legislatively compliant even when receiving the data of all receipts belonging to those shoppers who may not have provided consent to join this receipt delivery scheme to their card issuers.

Whilst the invention has been described for the delivery of digital receipts, in other embodiments, it can be used to help with the digital delivery of any other type of artefact to a recipient using an aggregator party that negotiates the routing of such artefacts with another party which may own identifying details of the recipient.

Referring to Figure 1, in one embodiment, cryptographic techniques are used when a Merchant Point of Sale System 100 sends the data of all receipts it generates to a Receipt Aggregator 102 which performs post-purchase transaction matching to map a subset of such receipts to payment transaction data of users who have provided consent to Shopper's Card Issuer 101 without the necessity of asking for consent (or personal details of shoppers) from any shoppers despite sending all shoppers' receipts to the Receipt Aggregator. In this process, the Merchant Point of Sale System 100 compiles a receipt record R for ALL transactions irrespective of whether shoppers' consent has been given to the shopper's card issuer or not. Then via applicable means, as normal, the Merchant Point of Sale System 100 initiates to process a payment 104 via applicable means (e.g. payment terminals). Once the payment is processed by the acquiring institution (i.e. merchant's bank) and the shopper's card issuer, the resulting metadata of transaction processing Tp are handed over to the Merchant Point of Sale System 100 (e.g. from the payment terminal). Next, the Merchant Point of Sale System looks up the relevant card issuer of the card used for the payment 115 (with technique comprising but not limited to using the first few digits of the Personal Account Number PAN of the card that identify the issuing institute). Next, the Merchant Point of Sale System requests a public Key Encryption Key (KEKpu) 107 from the Shopper's Card Issuer. As a response to this request, which the card issuer can receive via mechanisms that comprise but are not limited to Application Programming Interface (API) endpoints, the card issuer uses an asymmetric encryption algorithm (comprising but not limited to the RSA algorithm) to generate and persist an asymmetric keypair, including public Key Encryption Key (KEKpu) and private Key Encryption Key (KEKpr). The Shopper's Card Issuer then only supplies back KEKpu and its type (e.g. RSA) so that the point of sale system can decide how to use the key. Next, the Merchant Point of Sale system, chooses a symmetric encryption algorithm (e.g. AES) and generates and/or derives (e.g. from a combination of KEKpu and locally-generated asymmetric keypairs) a private Data Encryption Key (DEK) 109, to encrypt the main contents of the receipt R using DEK, then it encrypts DEK using KEKpu which results in the creation of the encrypted Data Encryption Key DEKe, which also includes which algorithm has been used for its generation. Then it compiles an aggregator's version of the receipt Re by including the encrypted version of the receipt contents, transaction metadata Tp, transaction identifier Tid and the encrypted data encryption key DEKe. Then the Merchant Point of Sale system submits 110 the aggregator's version of the receipt Re to the Receipt Aggregator, which it will persist while waiting to receive payment transaction metadata from Shopper's Card Issuer, if it has not yet received such metadata already. At some point, before or after Merchant Point of Sale System submits the encrypted receipt to the Receipt Aggregator, Shopper's Card Issuer sends 111 transaction data streams of those shoppers who have already provided consent and joined the proposed multi-party receipt delivery scheme. Such data stream includes aggregator's transaction metadata Ta, which may have been stripped of extra details like identity-revealing details, but includes transaction identifier Tid and the private Key Encryption Key (KEKpr) that the card issuer generated in step 107 for the transaction. At this point, by providing KEKpr only for those transactions belonging to the users who have provided consent to the Shopper's Card Issuer, the issuer only makes it possible for the aggregator to decrypt the receipts belonging to such users with consent, and not any of the other receipts submitted by the Merchant Point of Sale system, making claims 1, 2 and 3 possible. Next the Receipt Aggregator performs post-purchase transaction matching 112 using a matching function M which receives the transaction meta data provided by the Merchant Point of Sale System Tp as well as the transaction metadata provided by the Shopper's Card Issuer Ta. For the matching process to work, the aggregator loops through all the recent unmatched transactions included in the data stream sent by the Shopper's

Card Issuer and for each of these transactions, it calculates the value of M(Ta). Then it loops through all the recent unmatched transactions reported by the Merchant Point of Sale System and calculates M(Tp) in the same way. The transactions and receipts that create the same value for M are deemed to relate to each other. Different matching functions can be defined that serve the purpose of matching. One example could be a function that generates a string by concatenating transaction id, card scheme (e.g. MasterCard, VISA, AMEX) and the amount of the transaction metadata and passes the resulting string to a one-way deterministic hashing function (e.g. SHA256) and returns the value of the hash. This function will generate the same hash output for the transaction metadata with equal transaction ids, card schemes and amounts. Once a match between the transaction metadata provided by Shopper's Card Issuer and Merchant Point of Sale system is found, then the Receipt Aggregator uses the private Key Encryption Key provided by the Shopper's Card Issuer KEKpr to decrypt the encrypted Data Encryption Key DEKe, resulting in DEK and then uses DEK to decrypt the contents of the receipt to generate R, which then the aggregator can process and persist. In the next step, the Receipt Aggregator then supplies back the decrypted receipt R 113 to the Shopper's Card Issuer, which it will then persist, process and display or mark for future displaying. The process to supply the decrypted receipt can include but is not limited to the use of webhooks or Application Programming Interfaces (APIs) made available by Shopper's Card Issuer to the Receipt Aggregator. To ensure how the proposed receipt delivery scheme fulfills Claims 1, 2 and 3, a number of its attributes are analysed and described. Firstly, all receipts, irrespective of their owners' consent to any party, are encrypted before being sent out of the Merchant Point of Sale system. This encryption uses private symmetric encryption algorithms with data encryption keys (DEK) that are derived or generated by the point of sale system and not shared with the Receipt Aggregator in plain format. Such symmetric keys themselves are also encrypted with independent asymmetric key encryption keypairs (KEKpr and KEKpu) for each receipt that are generated by the Shopper's Card Issuer with only the public component of such keypairs KEKpu being known to the Point of Same system. As a result, the only party that can help decrypt DEK and the receipt content is the Shopper's Card Issuer who are not disclosed with the receipt contents at first. The Receipt Aggregator only receives an encrypted form of receipts that it can not decrypt unless the keys to such encryption algorithms are provided by the party that owns them (i.e. the Shopper's Card Issuer) and this only happens for the receipts whose recipients have provided their consents to their card issuer. As a result, the data of the receipts belonging to the shoppers that have not provided consent or have not joined the receipt delivery scheme remains unreadable to the aggregator which facilitates skipping the necessity to gain consent from shoppers before sending their receipts out of Merchant Point of Sale systems. Even if the aggregator maintains the data of such receipts, as long as the used symmetric and asymmetric algorithms used in the proposed scheme resist typical attacks, claims 1, 2 and 3 have been all met and fulfilled.

In different embodiments, referring to Figure 1, the Shopper's Card Issuer 101 can choose a variety of asymmetric or symmetric algorithms 107 to enable Merchant Point of Sale system 100 to encrypt receipts 109 before submitting them to the Receipt Aggregator 102. In One embodiment, the Shopper's Card Issuer 101 can use an Elliptic Curve (EC) algorithm to generate key encryption keypairs (KEKpu and KEKpr). In such an embodiment, when Merchant Point of Sale System 101 receives KEKpu, it can generate an elliptic curve keypair itself as a Data Encryption Keypair (public DEKpu and private DEKpr). It can then derive a private symmetric data encryption key DEK by feeding its DEKpr and KEKpu to the Elliptic-curve Diffie-Hellman (ECDH) key agreement algorithm to derive a secret key Sk and then feed the secret key Sk to a Hash Based Key Derivation Function (HKDF) to generate a symmetric data encryption key to use with a range of available symmetric encryption algorithms to encrypt the receipt contents. Briefly, in such an embodiment, for the Merchant Point of Sale System, DEK=HKDF(ECDH(DEKpr, KEKpu)). In such an embodiment, it will be necessary for the Merchant Point of Sale System to include its public elliptic curve key DEKpu as 'relevant data' 110 to the Receipt Aggregator since the aggregator will need it to derive the same DEK to decrypt the receipt contents at the right time. Once the Receipt Aggregator receives 111 transaction metadata from the Shopper's Card Issuer and starts to decrypt the receipt after matching the receipt to a transaction 112, it will use KEKpr (supplied by the Shopper's Card Issuer) and DEKpu (supplied by Merchant Point of Sale System) with the Elliptic-curve Diffie-Hellman (ECDH) function which will lead to the generation of the same Sk that Merchant Point of Sale system has derived at the time of encrypting the receipt. The Receipt Aggregator will then feed Sk to the same Hash Based Key Derivation Function (HKDF) the result of which will be the exact same DEK as the Merchant Point of Sale System has used to encrypt the receipt. In brief, for the Receipt Aggregator, DEK=HKDF(ECDH(KEKpr, DEKpu)) at the time of decrypting the receipt after transaction matching. The same attributes, as described in the previous embodiment, would still apply in the same way despite using different algorithms and key agreement schemes, fulfilling Claims 1, 2 and 3.

Referring to Figure 2, in another embodiment, a Merchant Point of Sale System 200 first compiles a receipt R for all transactions irrespective of shoppers' consent 203 and initiates to process the payment 204 (e.g. via a card reader terminal or other relevant means), which leads to the processing of the payment via the acquirer and the Shopper's Card Issuer 201, as a result of which transaction processing metadata Tp and transaction identifier Tid are passed back 205 to the Merchant Point of Sale System. Next, the Merchant Point of Sale System only supplies the transaction processing metadata Tp and the transaction identifier Tid 206 to the Receipt Aggregator, pending the removal of identifying information, without including receipt contents, which the Receipt Aggregator then persists for processing 207. At some point in time, either before the Receipt Aggregator receives such data from the Merchant Point of Sale System, or after that point, the Receipt Aggregator receives 208 transaction metadata Ta from the Shopper's Card issuer which can be stripped of identifying information to help with privacy and security. When the Receipt Aggregator has access to the receipt metadata that it receives from both the Merchant Point of Sale System and the Shopper's Card Issuer, it can then match transactions 209 using a matching process as described in the first embodiment of the invention based upon a matching function M that receives such metadata Ta and Tp and feeds some of the properties included in the metadata in concatenated form to a one-way deterministic hash function like SHA256. Equality of the return value of M for Ta and Tb should be deemed as the relatedness of a receipt to a transaction. Once a transaction is matched between the data stream received from the Merchant Point of Sale System and the Shopper's Card Issuer, then the Receipt Aggregator needs to send a request to the Merchant Point of Sale System to pull the contents of such matched receipts 210. To do this, the Receipt Aggregator needs to have received a return communication address from the Merchant Point of Sale System as part of the 'relevant data' 206 which it will then use to pull the relevant receipts from the Merchant Point of Sale System. Given the fact that Merchant Point of Sale Systems may be behind firewall or network address translators, techniques that can be used to make this pulling mechanism possible can include but are not limited to the use of a publish-subscribe protocol like MQTT via a message broker that transfer messages, in real time, to the Merchant Point of Sale System. The Merchant Point of Sale System can, upon starting up, book a random publish/subscribe topic and subscribe to it via the message broker and supply this topic to the Receipt Aggregator, which then the aggregator will use to reach back to the Merchant Point of Sale System to pull receipts. Upon receiving a request to pull a receipt (which will include a receipt identifier), the Merchant Point of Sale System then looks up the receipt 211 and supplies it back to the Receipt Aggregator 212 which in return will persist and process it 213 just to send it back to the Shopper's Card Issuer 215, via mechanisms that can include but are not limited to calling webhooks or Application Programming Interfaces (APIs) provided by the Shopper's Card Issuer. The proposed receipt delivery mechanism, unlike the first embodiment that uses cryptography to make the data of those receipts without consent unusable for the Receipt Aggregator, avoids sending all receipt contents to the aggregator fundamentally and waits for the aggregator to pull the ones that have been matched hence eliminating needs of consent or personal details collection at the counter from customers and fulfilling Claims 1, 2 and 3. Obviously, given that only the receipts whose owners have provided their consent to their card issuers are matched and pulled from the Merchant Point of Sale System assures that receipts belonging to other owners are not sent out of the Merchant Point of Sale System and the scheme remains fully legislatively compliant despite not requiring consent collection.

REFERENCES

SADLER, H. 2019a. Digital Invoice Wallet: Methods, Applications, Systems and Processes for Transferring Invoices to Buyers Seamlessly in Digital Format without the Need for Buyers to Share Their Personal Details [Online]. Available: https://patentscope.wipo.int/search/en/detail.jsf?docid=AU239180280 [Accessed]. SADLER, H. 2019b. Secure Receipt Transfer Protocol: Cryptosystem, Communication Protocol, Systems, Methods and Smartphone Applications for End-To-End Encrypted Transfer of Tamper-Resistant Receipts as an Enabler for Anonymously Individualized Marketing and Loyalty Management with Preservation of Buyers' Anonymity and Privacy [Online]. Available: https://patentscope.wipo.int/search/en/detail.jsf?docld=AU249885057 [Accessed].

EDITORIAL NOTE

2021101937

THERE ARE TWO PAGES OF CLAIMS ONLY

Claims (3)

1. Systems and methods for the delivery of digital receipts from receipt issuers to shoppers via post-purchase transaction matching performed by an aggregator without issuers needing to acquire consumer consent or personal details at the counter despite remaining legislatively compliant even when issuers send the data of all receipts belonging to all shoppers to the aggregator, including the receipts belonging to consumers who have not provided consent to their payment card issuers; the systems and methods comprising a. An aggregator that i. Receives receipt data from point of sales systems belonging to merchant/receipt issuers ii. Receives transaction metadata from banking institutes and card issuers iii. Matches transaction data with receipts data and enables the routing of mapped receipts to their respective users to be demonstrated to their owners by the card issuers and banking institutes b. A merchant operating a point-of-sale system that sends receipt data to an aggregator without having to seek individual consent or personal details to send out receipt data belonging to their customers, with the possibility of sending the data of all receipts belonging to all customers, even the ones who may not have provided consent to their card issuers c. Card issuers that seek consumer consent to match transactions belonging to them with receipt data by sending transaction data to a receipt aggregator d. A receipt matching algorithm/process that either uses cryptography to assure the aggregator's zero knowledge of all the receipt data sent by the point of sale systems except for the receipts whose owners have provided consent to their card issuers, or alternatively, avoids sending receipt contents to the aggregator until the moment matching has been finalized to only pull the receipts with consent from point of sale systems, facilitating the elimination of consent collection by receipt issuers at the time of issuing receipts while remaining complaint to privacy legislations; the algorithm comprising the following steps i. When using cryptography and zero knowledge:

* Merchant point of sale encrypts all receipts data with randomly generated or derived data encryption keys that get encrypted themselves using an asymmetric encryption algorithm making use of a key encryption keypair that are generated by shopper's card issuer for each receipt. • The aggregator receiving the encrypted data of all receipts as well as transaction metadata from shoppers' card issuers that it uses to match transactions to receipts, with the transaction metadata to include the private key encryption keys only for the receipts whose owners have provided consent to their card issuers. ii. When not using cryptography: • Merchant point of sale only sends the transaction metadata of all receipts without sending receipt contents to the aggregator, enabling the aggregator to still perform transaction matching with the transaction metadata it receives from shoppers' card issuers, and then only pull the contents of the receipts that are matched with card issuers' data which would be the ones that the card issuer has received consent for.

2. The systems and methods of claim 1 wherein shoppers and receipt recipients will not have to be asked by receipt issuers for their consent to receive receipts from issuers at the time of receipt issuance while the entire receipt delivery scheme remains compliant to privacy-related legislations.

3. The systems and methods of claim 1 wherein the aggregator maintains zero knowledge of the contents of receipts up until the moment card issuers provide transaction data to the aggregator to facilitate the mapping of receipts to transactions, making the maintaining of receipt data a useless phenomenon for the aggregator, eliminating the needs of trust to the aggregator to dispose of the receipt data belonging to shoppers who have not provided consent to receive digital receipts via their card issuers, making it possible not to ask for consent at the counter or changing consumers' or POS operators' behaviours.

EDITORIAL NOTE Apr 2021

2021101937

THERE ARE TWO PAGES OF DRAWINGS ONLY

100 101 102 Merchant Point of Sale System Shopper's Card Issuer Receipt Agregator 103 Compile receipt R for ALL transactions irrespective of shoppers’ consent 104 Processing payment thru acquirer and card networks 105 Supply transaction processing 115 metadata Tp Look up the relevant card issuer of the card used for transaction 106 Request public 107 Key Encryption Key (KEKpu) Generate and persist private for Transaction ID Tid and public Key Encryption Keys 108 (KEKpr, KEKpu) and supply Supply public KEKpu KEKpu 109 Choose or derive Data Encryption Key DEK, encrypt R with DEK, encrypt DEK with KEKpu resulting in DEKe, include DEKe and R to compile Re 110 Upload encrypted receipt Re (inclusive of Tp, Tid, DEKe and other relevant data) 111 Send live transaction data stream 112 for users with consent Ta, Tid and KEKpr Perform Matching: For merchant transaction meta data Ta and each transaction meta data Ta, if M (Tp)= M(Ta) then Re is a match to T. Then 113 Decrypt DEKe with KEKpr resulting in DEK Supply R back Decrypt Re to R using DEK, where M is a matching function 114 Persist, process and display Apr 2021 2021101937

200 201 202 Merchant Point of Sale System Shopper's Card Issuer Receipt Agregator 203 Compile receipt R for ALL transactions irrespective of shoppers’ consent 204 Processing payment thru acquirer and card networks 205 Supply transaction processing meta data Tp and Transaction ID Tid 206 Supply Tp, Tid and other relevant data 207 Persist 208 Send live transaction data stream 209 for users with consent Ta, Tid Perform Matching: For merchant transaction meta data Ta and each transaction meta data Ta, if M (Tp)= M(Ta) then R is a match to T. 210 Then pull R from merchant POS Request to pull receipt R from merchant POS 211 Lookup R and supply 212 Supply R 213 Persist and supply 214 Supply R 215 Persist, process and display Apr 2021 2021101937