AU2019100775A4 - 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 - Google Patents

Abstract

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 Abstract A cryptosystem, including an end-to-end cryptographic messaging protocol to transfer receipts from receipt issuers to receipt recipients using anonymous digital signatures assuring anonymity, privacy and tamper-resistance for receipts, as wellas systems, methods and applications that facilitate an anonymously-individualized loyalty management and marketing paradigm are hereby disclosed under "Secure Receipt Transfer Protocol". As an end-to-end cryptographic messaging protocolbetween receipt issuers and receipt recipients, the protocol assures recipients'anonymity and privacy when receiving receipts against attackers, receipt issuers, and even intermediaries transferring data between issuers and recipients. It also provides tamper-resistance against receipt data through digital signatures. Despite anonymity preservation, the proposed protocol, systems and methods still enable receipt issuers to dice and slice their transactions data using Transaction Markers that are generated randomly and consistently as wellas anonymous signatures provided by receipt recipients at the time of receiving their receipts. Transaction Markers enable receipt issuers to extract useful grouping insights and intelligence out of their transactions and sales history data. We hereby propose the concept of "Abstract Anonymous Marketing Rules" that allow receipt issuers to reach out to customers with fully individualized but yet anonymous offers without being able to know the identity of such customers hence proposing the concept of "Anonymously Individualized Loyalty Management and Marketing Paradigm"for the first time. Despite such offers being dependent upon receipt recipients' purchase history the data of which is end-to-end encrypted and inaccessible to an intermediary, the protocol and the loyalty management/marketing method and tools still enable "mining"applicable Abstract Marketing Rules against receipt recipients'encrypted purchase history data locally and securely without any server-side processing. This paradigm assures recipients'anonymity against all 3 rdparties including receipt issuers, data transfer intermediaries and external attackers. This is equivalent to making "anonymity" and "individualization" possible at the same time in the context of loyalty management and marketing; a goal unachieved by this time without the use of techniqueslike zero knowledge proofs or ring signatures for set membership proofs. Background Paper receipts are a tremendous economic and environmental burden for the society and the planet. Every year, in the United States alone, up to 10 million trees are used to make the papers, 21 billion gallons of water are wasted making them, 686 million pounds of waste and 12 billion pounds of carbon dioxide (C0 2) (the equivalent of one million cars on the road) are generated to support the concept of paper receipts (Breyer, 2019). The core problem to solve in an attempt to eliminate paper receipts is the extraction of receipt data from Point-Of-Sale (POS) or other relevant systems owned by receipt issuers and transferring them to receipt recipients securely, anonymously and privately. Our previous patent #2019100146 addresses the first aspect of the problem to extract data effectively and seamlesslyfrom POS systems without needing to change or integrate with them and without recipients having to provide their details, useful to eliminate the need to roll out new POS systems for businesses that cannot afford to do it, while partially addressing the second aspect of security, privacy and anonymity for receipt recipients. With paper receipts, the recipients have the liberty to enjoy full privacy and anonymity without having to provide details to receipt issuers to receive their receipts. Many existing attempts to solve the paper receipt problem are partially or fundamentally ignoring this privilege and inherently, under the mantra of convenience, somehow involve an intermediary who will maintain recipients' purchase history to use in the context of loyalty management and marketing as a side benefit. Notwithstanding the GeneralData Protection Regulations (GDPR) and the likely infeasibility of allowing such a use of the data collected from receipts for marketing and loyalty management, in certain jurisdictions, attempts are in progress to propose receipt digitization mechanisms without addressing the underlying privacy issues arising and sacrificing buyer's privacy and anonymity in the process. Our proposal, for the first time, proposes a method in which it becomes possible to preserve buyers'anonymity and privacy by performing end-to end encryption against receipt data and marking transactions with recipient-generated anonymous digital signatures, but yet, be able to "mine" individualized offers applicable to buyers without an intermediary or attackers being able to access buyers' purchase history. This is equivalent to making anonymity and individualization possible at the same time in the context of loyalty management and marketing. This is the greatest outcome of the proposal hence making Anonymously-Individualized Loyalty Management and Marketing Paradigm possible. DefineAbstract Anonymous Issuer's Portal Loyalty/MarketingRles I SPublicuze Abstract Issuer's Anonymous Portal User Loyalty/MarketingRules POS Operator Ap plita lily POS Sys-temS Individualized Deals Mined SDK Calls .- .- - - - - - - - - . Secure StorageRed pients p I Send end-to-end entrypd receipts, P OS SD K Libraries/ Iusing theS eture Receipt Protocol POSsD K Instante Figure 6. Data flow and actions showinghow individualizedloyalty and marketing deals are "mined" against the data that no one except the end user has accessto

Description

Paper receipts are a tremendous economic and environmental burden for the society and the planet. Every year, in the United States alone, upto million trees are used to make the papers, 21 billion gallons of water are wasted makingthem, 686 million pounds of waste and 12 billion pounds of carbon dioxide (CO2) (the equivalent of one million cars on the road) are generated to support the concept of paper receipts (Breyer,

2019).

The core problem to solve in an attempt to eliminate paper receipts is the extraction of receipt data from Point-Of-Sale (POS) or other relevant systems owned by receipt issuers and transferring them to receipt recipients securely, anonymously and privately. Our previous patent #2019100146 addresses the first aspect of the problem to extract data effectively and seamlessly from POS systems without needing to change or integrate with them and without recipients having to provide their details, useful to eliminate the need to roll out new POS systems for businesses that cannot afford to do it, while partially addressing the second aspect of security, privacy and anonymity for receipt recipients.

With paper receipts, the recipients have the liberty to enjoy full privacy and anonymity without having to provide details to receipt issuers to receive their receipts. Many existing attempts to solve the paper receipt problem are partially or fundamentally ignoring this privilege and inherently, under the mantra of convenience, somehow involve an intermediary who will maintain recipients' purchase history to use in the context of loyalty management and marketing as a side benefit. Notwithstanding the General Data Protection Regulations (GDPR) and the likely infeasibility of allowing such a use of the data collected from receipts for marketing and loyalty management, in certain jurisdictions, attempts are in progress to propose receipt digitization mechanisms without addressing the underlying privacy issues arising and sacrificing buyer's privacy and anonymity in the process.

Our proposal, for the first time, proposes a method in which it becomes possible to preserve buyers' anonymity and privacy by performing end-toend encryption against receipt data and marking transactions with recipient-generated anonymous digital signatures, but yet, be able to mine individualized offers applicable to buyers without an intermediary or attackers being able to access buyers'purchase history. This is equivalent to making anonymity and individualization possible at the same time in the context of loyalty management and marketing. This is the greatest outcome of the proposal hence making Anonymously-Individualized Loyalty Management and Marketing Paradigm possible.

2019100775 17 Jul 2019

Figure 6. Data flow and actions showing how individualized loyalty a nd marketing deals are mined against the data that no one except the end user has access to

EDITORIAL NOTE

2019100775 17 Jul 2019

There are 15 pages of the description only.

Description of Invention

s chapter describes all the elements and components of the invention in details, as follows:

a. Basic definitions, assumptions and the use of commonly-known standard cryptographic schemes as follows:

m rro o o cr

Encryption	In cryptography, encryption is the process of encoding a message or information in such a way that only authorized parties can access it and those who are not authorized cannot. There are normally two approaches to encryption: symmetric (using a single key) or asymmetric (using multiple keys like a key pair). The critical aspect with encryption is where and how encryption keys are maintained since it would be an arbitrary extra to encrypt data without ensuring keys are protected. In the context of this proposal, a client-side encryption paradigm is used which means the act of encryption and decryption are performed in components like Point-Of-Sale machines or user smartphones or users' web browsers, not on servers. This assures that the intermediary transferring data between parties cannot have access to plain data or encryption keys.
AES	Advanced Encryption System is a symmetric encryption scheme used to encrypt data using a single encryption key
RSA	RSA (Rivest-Shamir-Adleman) is a public-key cryptosystem in which an RSA key pair is used to perform asymmetric encryption. The RSA public key can be shared with other parties and can be used to encrypt data. The encrypted data can only be decrypted by the party who owns the relevant private key. The scheme is used to encrypt short pieces of data (e.g. symmetric encryption keys). One important feature of RSA cryptography is that by sharing a single public key, many parties can send secrets to the owner of the relevant private key. This can provide a range of options when managing private key vaults that store encryption keys.
Elliptic-curve cryptography	It is an approach to asymmetric cryptography based on the algebraic structure of elliptic curves over finite fields. Asymmetric cryptography uses two keys that are mathematically related to each other but one cannot derive one of them from the other in feasible times even when using high-power computing. One of such keys is preserved as a private key, not shared with any party, while the other one is usually shared publicly hence being called a public key. Multiple characteristics are enabled through asymmetric cryptography schemes without which information security would not have matured to what it is today. Anytime in this document, elliptic curve cryptography is referred to, it is a reference to fm?255Z£scheme.
ECDSA	Elliptic Curve Digital Signature Algorithm is a digital signature scheme built upon elliptic curves cryptography. With a digital signature scheme, a private key is used to sign the contents of a message to generate a digital signature. The signature can later on be verified by having access to a) the message that was signed, b) the public key associated with the private key used at the time of singing. The signatures assure authenticity, tamper-resistance and non-repudiablity. It would be obvious that having access to the signature and the message that has been signed as well as all the possible public keys that could have been used to sign a message creates a possibility (or attack) by which an attacker could brute-force all possible public keys and check who the signer of a signature is hence implying the non-anonymity of digital signatures by default, unless some parts of the signed message remain unknown to the attacker(s), which is the basis of most anonymous signature schemes (Yang et al., 2006). As an obvious result of this property, digital signatures signed by receipt recipients using their permanent public identity keys may not be directly useful when it comes to keeping recipients' identities hidden from a transaction and more anonymous types of signatures have to be explored.
Hash Function	A hash function is any function that can be used to map data of arbitrary size onto data of a

	fixed size. Collision-resistant hash functions assure that the output remains unique for unique input values (no different inputs generate the same output) hence providing one-way irreversible mapping possibilities and are used in cryptography. Hash functions are also used to provide authenticity and tamper-resistance for a message that can be verified by passing the message to the same function and checking the return values with the originally-generated hash values. Throughout this document, Sha256 is the hash function used.
HMAC	Hash-Based Message Authentication Code is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. Throughout this document Sha256 is the HMAC scheme used.
HKDF	Hash Key Derivation Function is a simple key derivation function (KDF) based on a hash-based message authentication code (HMAC). It receives a parameter and derives outputs from the parameter in a one-way fashion so that it will be extremely costly and infeasible to find out which input created the output, and, that no two different inputs create the same output.
ECDH	Elliptic Curve Diffie Hellman key exchange is a secret agreement scheme that enables two parties to agree upon a shared secret unknown to the public by only transferring one public message to each other (i.e. KlPubiic and K2Public). The transfer of such public message does not need to be real-time (e.g. a message can be left on a common server and later picked up by another party). When used in combination with elliptic curve public keys as the public message, this scheme can help derive common private secrets between two parties with exchanging short elliptic curve public keys. Accordingly: Shared Secret 1 = ECDH (KlPrivate,K2Public) And Shared Secret 2 = ECDH (K2Private, KlPubiic) Essentially, Shared Secret 1 will be equal to Shared Secret 2 even though they are being calculated using different parameters by the two different parties. The common encryption key which is usually used with symmetric encryption schemes like AES256 is normally calculated by feeding this calculated shared secret into a key derivation function, as follows: Common Encryption Key = HKDF (Shared Secret)
PBKDF2	Password-Based Key Derivation Function 2 is a key derivation function with a sliding computational cost, used to reduce vulnerabilities to brute force attacks. The number of iterations passed to this function as a parameter defines the computational cost involved. For Secure Receipt Protocol, the iteration cost is at least 200,000. It is customary to derive encryption keys from a master password using a function like PBKDF2 in which case, the password is fed to this function and the resulting return values are then used as encryption keys that are irreversible to the password (i.e. return values cannot be used to derive back to the input parameters of this function by having the outputs).
Concatenation	Attaching byte sequences to the end of another byte sequence, demonstrated using the || operator.
Secure Local Storage	Hardware-backed keychain-enabled devices can store encryption keys securely in keychain storage. Access to such keys in keychains is limited to an application that creates such keys. This enables a secure paradigm of locally encrypting data (or databases) at rest depriving an attacker from being able to download application data from a device and extract encryption keys from keychain storage to decrypt them. In case of operating systems like Windows, secure storage services like Data Protection API can be utilized for this purpose as well.
Implementation Transparency	The fundamental assumption in proposing software systems that encrypt and decrypt data is that despite possibilities to have access to locally-saved data in plain format (e.g. when displaying information to end users on user interfaces), there is an element of trust in the fact that the implementations of the proposed algorithms or systems are 100% aligned with the designs of such algorithms or systems. In other words, systems that operate unencrypted data do not operate a back door to send plain data to 3rd party systems without users

2019100775 17 Jul 2019

knowing. One approach to increase implementation transparency is to release code openly for the community to view and confirm the alignment.

Intermediary

In the context of this proposal, the term intermediary means a body responsible for transferring data between recipients and issuers who may have access to receipt recipients' identifying details and receipt issuers' identifying details. One of the goals of the proposal is to create a situation in which there remains no need to have trust in the intermediary by making it impossible for the intermediary (or an attacker for that matter) to have access to receipt data and/or be able to have access to recipients' identifying information which can lead to access to users' purchase history.

b. Receipt Issuers, who are bodies, entities or individuals intending to provide invoices or receipts against a transaction of sales or transfer of goods/services to a buyer

c. Receipt Recipients, who are bodies, entities or individuals receiving invoices or receipts from Receipt Issuers following a transaction of sales or transfer of goods/services. Throughout this document, the term buyer and receipt recipient may be used interchangeably

d. The Secure Receipt Transfer Protocol, heavily inspired by the open-source X3DH (or Extended Triple Diffie-Hellman) Key Agreement Protocol (Moxie Marlinspike, 2016b), comprising the following steps and messages communicated between Recipient R, AND, a Receipt Issuer operating a Point-of-Sale (POS) station/machine, POS.

NOTE:

//? the context of the Secure Receipt Protocol, Receipt issuer and POS Software Development Kit (SDK) instance or POS Machine or POS Station can be used interchangeably even though POS SDK instance may actually refer to the physical tools used by Receipt issuers for the transfer of receipts. Obviously, the definition of a protocol is more about the messages and conventions between parties rather than the physical implementation details. Accordingly, the Secure Receipt Protocol may be implemented by a POS Software System without the need for an SDK instance or an APP which is still covered by this patent as a protocol.

i. Upon setting up and initial configuration, the following elliptic curve key pairs are generated by the Issuer. All PRIVATE keys are then saved locally in secure encrypted formats using the relevant secure persistence APIs available through the Operating System or hardware-backed secure key-chains while the PUBLIC keys are persisted on back-end servers through calls made to APIs.

IKP0S comprising IKPosPublic and I KpoSprivate

Long-term elliptic curve identity key pairs that are not changed after the initial installation and configuration (until next re-installation or reconfiguration). These keys are saved securely and locally on the POS hardware. IKposPublic will be then uploaded to back-end servers at the time of setting-up to become available to query publicly through an API using the Receipt Issuer Identifier and the POS Machine Identifier and a Key Index. In each receipt that is generated, these three parameters are embedded so that, at the time of verifying the digital signatures of receipts, the public key used to create the signature can be looked up from a trusted source. One important consideration is that the same POS machine may be reinstalled or re-configured, in which case, even though the Receipt Issuer Identifier and the POS Machine Identifier will remain the same but a different Key Index will be used when a new IKP0S is created by to

2019100775 17 Jul 2019

	ensure that those receipts generated in the past remain verifiable after re-configuring or re-installation.
SPKpos comprising SPKPosPublic and P POS Private	The Signed Pre-Key which is digitally signed using ECDSA scheme and IKposPrivate uPon the initial configuration on each POS system. SPKP0Spubllc can be looked up through APIs using the Receipt Issuer Identifier and the POS Machine Identifier.
DTKpos comprising 0TKPosPublic and 0TKPosPrivate	The One-Time Pre-Keys of the POS machine, generated in a set of 100 key pairs, each used in ONE handshake with all private keys saved securely locally, and all public keys saved on back-ends with their index defining which one is referred to. With each receipt transfer handshake, the one-time pre-key used gets deleted from both back-ends and from the local secure storage. Once all are used, a new set of 100 get generated and the process continues. The collection of [IKPOSpubllc, SPKP0Dpublic, 0TKPOSpublic, Index of 0TKPOSpublic, Signature o) SPKP0Spublic ] is called a Pre-Key bundle for a POS machine and can be looked up from backend APIs using the Receipt Issuer Identifier and the POS Machine Identifier and the Key Index of IKP0Spublic.

ii. When a receipt or invoice is ready to be submitted from a POS machine to a recipient, a Receipt Transfer Request is compiled by the Receipt Issuer, comprising

1. Acryptographically-secure randomly-selected Local Return Address

2. Random Receipt ID, generated randomly per receipt, unique per receipt per issuer

3. Receipt Time Stamp, generated per receipt based on the moment of generation

4. Receipt Issuer Identifier, set when configuring the POS machine, unique per Receipt Issuer

5. POS Machine Identifier, set when configuring the POS machine, unique per POS station

6. Authentication Challenge, which is a cryptographically-secure randomly-selected string used to create an authentication challenge to later on ensure the party who receives the original Receipt Transfer Request is the same party continuing with the protocol handshake, making the future requests.

iii. The generated Receipt Transfer Request is sent to the Recipient through applicable means (e.g. a QR Code, barcode, or using any other mechanism, including but not limited to emailing links, radio frequency scans, wireless scanning or even manual entry on Recipient's devices etc..).

iv. The Receipt Issuer then starts listening on the previously-generated Local Return Address for the incoming Key Exchange message(s) after persisting details of the generated Receipt Transfer Request. It also persists details of the Receipt Transfer Request it created in its secure local storage that will be used in next stages.

v. Upon the reception of the Receipt Transfer Request, the Recipient performs the following steps:

1. It generates a fresh ephemeral elliptic curve key pair which we call Receipt Transfer Key Pair, RTK_r, comprising the public key RTK_RpubUc and the private key RTK_Rprlvate, saving the private key on

2019100775 17 Jul 2019 hardware-backed keychain-based secure local storage on the device.

RTK_Rprlvateshould be maintained and saved securely as long as the receipt exists on Recipient's device and will be used later on to verify digital signatures and purchase.

2. The Recipient looks up the Pre Key Bundle of the POS machine from intermediary servers using POS Machine Identifier of the POS system provided in the previous step hence retrieving [IKpos_PubUc > ^SPKPosPubliC' ^0TKPosPubliC'^{lndex of} 0TK_POSpublic, Signature o(SPK_POSpubllc ] for the provided POS Machine Identifier. It may be the case that no 0TK_POSpubUc and Index of 0TK_POSpublic is left to return on the server which does not create a problem as these values will be left blank.

3. The Recipient then verifies the signature of SPK_P0SpubUc by checking the return value of the following function:

ECDSAVerify (Signature of SPK_P0Spublic,IK_P0Spublic)

In case of failing to verify, the protocol stops with errors.

4. The Recipient then generates a fresh ephemeral elliptic curve key pair which we name Session Ephemeral Key EK_R, comprising public key EK_Rpublic and private key EK_Rprivate. It then saves the private key EK_Rprlvate ^on l°^cal^secure storage as part of the session data.

5. Using the POS Machine Identifier and the Pre Key Bundle, it starts the 3XDH-style key exchange handshake with the Issuer by sending a Key Exchange message to the Issuer which is listening on the Local Return Address it advertised as part of the original Receipt Transfer Request.

To do so, the Recipient calculates a Master Secret as follows:

Master Secret = ECDH(RTK_Rprlvate,SPK_P0SpubUc) II ECDH{EK_Rprivate,IK_P0Spublic ) || ECDH(EK_Rprlvate ,SPK_P0SpubUc ) || ECDH(EK_Rprivate,0TK_POSpublic) if 0TK_POSpublic'\s not available, the last ECDH() call is not made.

It then deletes EK_Rprivate.

6. The Recipient then generates a Root Key and a Chain Key, as follows:

RootKey = First 32 bytes of (HKDF(MasterSecret))

And

ChainKey = Last 32 bytes of (HKDF(MasterSecret/)

Note that in this version of the protocol, these keys are created similar to the Double Ratchet Algorithm (Moxie Marlinspike, 2016a) to leave the door open for future versions of the protocol where more messages may have to be sent between Recipients and Issuers without repeating the initial handshake.

7. The Recipient then generates the Receipt Encryption Key which it will use to decrypt the receipt data that it will receive from the Issuer in future. The same key will be derived by the Issuer as per the protocol.

ReceiptEncryptionKey = HMAC(ChainKey, 0x01)

8. The Recipient saves the public identity key of the Issuer IKpos_Pubi_iC' which together with RTK_Rpublic can be used (e.g. as part of a QR code or alternative methods) by both Recipient and Issuer as a common Receipt Verification Code between the parties so that in future, both parties can independently validate they were the original parties involved in the transfer of the receipt.

2019100775 17 Jul 2019

9. The Recipient then compiles a Key Exchange Message including the following items:

a. Local Return Address, which is a cryptographicaIly-secure randomly-selected string that the Recipient will start listening on to receive the final Receipt Transfer Request from the Issuer.

b. Random Receipt ID set from the previously-received Receipt Transfer Request

c. Receipt Time Stamp set from the previously-received Receipt Transfer Request

d. Recipient's public Receipt Transfer Key RTK_RpubUc

e. Index of 0TK_POSpubllc used, if applicable

f. EK_Rpublic which is the public key of the ephemeral session key generated as part of the key exchange scheme

g. Authentication Challenge Response, which is used to authenticate and verify that the party sending the Key Exchange Message is the same party who received the original Receipt Transfer Request, and is calculated as follows:

AuthChallenge Response = ECDSA(AuthChallenge,RTK_Rprivate) Since, the generation of the Authentication Challenge Response depends upon the ephemeral private keys only known to the Issuer and the Recipient, as well as the shared Authentication Challenge between them, it can authenticate that the party sending the Key Exchange Message is the party that actually received the original Receipt Transfer Request.

h. Transaction Marker, which is the hash of a cryptographicaIly-secure randomly-generated Raw Transaction Marker string which is generated and saved on local secure storage the first time the Recipient is receiving a receipt from a receipt issuer with the same Receipt Issuer Identifier, and, retrieved if this is not the first time.

Ultimately, Recipient anonymously marks transactions for the receipt issuer using this parameter and it is imperative that for future receipts, it marks transactions with the same marker to enable the issuer to slice and dice their transactions and group them anonymously by buyers.

TransactionMarker = HMAC(RawTransactionMarker)

The Recipient then saves Raw Transaction Marker and on its secure local storage for future reference (e.g. providing proof of purchase).

Raw Transaction Marker is NOT shared with back-end servers or any other parties.

i. Transaction Marker Signature, which acts as the anonymous digital signature of the transaction provided by the receipt recipient.

It helps a future mechanism to verify that the recipient claiming they are the ones who received the receipt are the ones who actually did so. In the context of claiming a purchase and or claiming loyalty or marketing offers applicable to a buyer, this signature can have a pivotal role. Accordingly:

Transaction Marker Signature = ECDSA (TransactionMarker, RTK_Rprlvate')

No identity-related or derived detail is provided as part of Key Exchange Message; therefore, an attacker (or the intermediary transferring the data between parties for that matter) cannot know who the actual call-maker is hence protecting the anonymity of the Recipient.

10. The Recipient then sends the generated Key Exchange Message to the Issuer using the Local Return Address of the original Receipt Transfer Request through a message which could be real-time or offline.

2019100775 17 Jul 2019

11. To ensure receipts can still be transferred in an offline mode (e.g. where internet connection drops after the initial step of Key Exchange Message transfer), both Issuer and Recipient, upon start-up, start listening to the local addresses of those receipts that have not been yet delivered in full for a limited time (e.g. 1 month). That ensures, half-left transfers can be continued after re-connection without the need to re-engage with the handshake. The use of offline pre-keys saved on online servers also allows the protocol not to need full real-time connectivity to work, as per the characteristics of X3 D H key exchange protocol.

vi. Upon the reception of the Key Exchange Message that contains RTK_Rpubllc and EK_RpubUc, the Issuer calculates the same Master Secret as follows:

Mastersecret = ECDH(SPK_F0SpMe,RTK_Kputllc) II ECDH(lK_F0SpMe,EK_FputlJ

II ECDH(SPK_F0Sp„_m,EK_Fpuluy II ECDH(0TK_FOSp„_m,EK_Fm·)

The last ECDH call using 0TK_POSprivate is only made if Index of 0TK_POSpublic is present in the Key Exchange Message.

vii. Then the Issuer calculates the same Root Key, Chain Key, and Receipt Encryption Key as follows:

RootKey = First 32 bytes of (HKDF(MasterSecretf)

And

ChainKey = Last 32 bytes of (HKDF(MasterSecret')) viii. The Issuer then calculates Receipt Encryption Key as follows:

ReceiptEncryptionKey = HMAC(ChainKey, 0x01) ix. The Issuer then authenticates the receipt recipient through the Authentication Challenge Response by checking the value of the following function:

ECDSAVerify (AuthChaiiengeRespouse, RTK_Rpubllc')

If it returns true, it means that

1. Authentication Challenge Response has been signed by the party who owns the private key associated with the public key they have sent in the Key Exchange Message

2. The same party has had access to the random Authentication Challenge the Issuer included in the original Receipt Transfer Request therefore concluding they are the same party

x. The Issuer then retrieves the full receipt record xi. Calculating Receipt Authenticity Signature

The Issuer then creates the Receipt Authenticity Signature for the receipt. To do so, it treats all the text included in the receipt as a single string and feeds it to the SΗA256 EIMAC function, as follows:

Receipt Authenticity Signature = SHA256(FuZZ Receipt Text at the time of generation)

The Receipt Authenticity Signature at the time of generation is then included in the receipt itself. This signature can be used to verify that the contents of the receipt have not been tampered with. At any point of time, if the contents of the receipt are fed into the same function and the resulting values are checked against the original Receipt Authenticity Signature, it can be verified that the contents have remained the same as they were when the receipt was generated (as described under section g.xyiii). This signature on its own may not provide full tamper resistance since anyone changing a receipt's data can also re-generate the correct Receipt Authenticity Signature for the forged receipt, which is why other signatures are also included.

2019100775 17 Jul 2019 xii. Calculating Receipt Digital Signature by the Issuer:

The Issuer then digitally signs the contents of the receipt. To do so, it treats all the text included in the receipt as a single string and feeds it to the ECDSA function using its own private identity key, as follows:

Receipt Digital Signature = ECDSA(FuZZ Receipt Text at the time of generation, IKpos_Private) Apart from the Receipt Digital Signature, each receipt will also include the Receipt Issuer Identifier and the POS Machine Identifier and the relevant Key Index of the identity key used so that at the time of signature verification, these values can be used to look up the right IKpos_PubUc verify the correctness of the receipt contents. This process can be carried out by Recipient (as described under section g.xix).

Receipt Digital Signature can provide a number of important properties, including

1. It provides a mechanism of authenticating the contents of the receipt and ensuring the contents have not been changed after the issuance by the Receipt Issuer.

2. It provides a mechanism to verify that the receipt has been genuinely issued by the Issuer included and cited in the receipt.

xiii. The Issuer serializes the receipt into a binary format, then uses the Receipt Encryption Key to encrypt it and compiles a Receipt Transfer Request and uses the Local Return Address field of the previously-received Key Exchange Message to send the Receipt Transfer Request to the Recipient.

Key Exchange Message is accompanied by SΗA256 signature of its entire serialized form to be verified by the Recipient to ensure the message is transferred correctly.

xiv. The Issuer then stops listening to the its own Local Return Address and hereby, the temporary communication channel ceases to exist xv. Upon the reception of the Receipt Transfer Request, the Recipient verifies SHA256 signature of the entire serialized form of the message to ensure contents are correct, then uses the already-calculated Receipt Encryption Key to decrypt the message, persists it locally on its local secure encrypted storage, updates its state and shows the receipt to the user.

xvi. Receipt Owner Verification Process:

It can be verified that a person with a receipt and an Issuer were the ones involved in the initial transfer of the receipt at the time of receipt issuance at two levels:

1. Via Receipt Verification Code which can be calculated and saved by both issuer and recipient in common and represented as a QR code, (numeric code or any other applicable form), as follows:

Receipt Verification Code = IR_POs_Public II ^^R_Pubu_c

Optimally, when both recipients and issuers calculate the same code based on their version of records, it can be deducted that the parties involved in the original transfer of the receipt are the ones owning these public keys.

Checking these values can be made possible by Recipient's App which can scan the Receipt Verification Code generated by the Receipt Issuer's Portal for a receipt as a QR code which can be then compared to a code that can be generated against local recipient's data.

Alternatively, it can be fed into a key derivation function to calculate a numeric value that can be checked by

2019100775 17 Jul 2019 both parties visually and manually as a guarantee that both parties checking the verification code are the same parties at the time of the reception of the receipt.

2. Using an Interactive Verification Challenge, the process comprising

a. An operator on behalf of a receipt Issuer looks up a receipt that needs to be verified using the identifier of the receipt provided by a Recipient

b. The Issuer then looks up the receipt and the RTK_Rpublic used to transfer it. It then generates a random string Verification Challenge and represents it as a code that can be either scanned as a QR code by the Recipient, or, entered numerically and manually.

The QR code will include a secured random ephemeral return Local Return Address that can be used by the Recipient to send back the Verification Challenge Response to the Issuer.

c. The Recipient then looks up RTK_Rprivate used to transfer the receipt and calculates a digital signature against the provided Verification Challenge, as follows:

Verification Challenge Response = ECDSA(Verification Challenge, RTK_Rprivate)

It then uses the included Local Return Address in the QR Code to send back the Verification Challenge Response to the Issuer.

d. Upon receiving the Verification Challenge Response, the Issuer stops listening on the provided Local Return Address and checks the equality of the following equation: ECDSAVerify(Verification Challenge Response, RTK_r )

If true, it can be proved that the party sending the Verification Challenge Response has access to the private key used during the original transfer of the receipt hence proving that the recipient is the party involved in the original transfer of the receipt at hand.

e. Optional Point of Sale (POS) Software Development Kits (SDKs) Instance: An instance ofthe tools and software libraries installed on a POS system that facilitate the transfer of receipt data from POS systems to receipt recipients with the following capabilities.

NOTE:

//? the context ofthe Secure Receipt Protocol, Receipt Issuer and POS SDK Instance or POS Machine or POS Station can be used interchangeably even though POS SDK instance may actually refer to the physical tools used by Receipt Issuers for the transfer of receipts. Obviously, the definition of a protocol is more about the messages and conventions between parties rather than the physical implementation details. Accordingly the Secure Receipt Protocol may be implemented by a POS Software System without the need for an SDK instance or an APP, which is still covered by this patent as a protocol.

i. Exposing software libraries that can be integrated in POS software systems or called by other tools that intercept or extract receipt data out of POS systems ii. Securely, bridging calls to back-end APIs iii. Facilitating and performing end-to-end encryption of receipt data when transferring them to receipt recipients or uploading the issuer's copy to Issuer's Portal using the Secure Receipt Transfer Protocol iv. Establishing one-to-one connections to receipt recipients' devices (e.g. smartphones) that may or may not involve intermediary servers

v. Facilitating and performing end-to-end encryption of receipt data when uploading a locally-encrypted issuer's copy of receipt data to the Receipt Issuer's Portal, the uploading process comprising, as per Figure 3,4 and 5:

1. Each receipt being independently encrypted by POS SDK instances on POS machines before being uploaded to issuer's Portal, by keys that are cryptographically and securely random and are independent

2019100775 17 Jul 2019 from the encryption keys used to transfer receipts to Recipient's Apps. Receipt data are uploaded to a common repository for all users in the same Issuer's account in issuer's Portal, however, receipt encryption keys are encrypted and saved in each user's individual key vault independently.

2. Each user of Issuer's Portal owning their own private key vault which acts as the repository of receipt encryption keys that are queried based on receipt identifiers.

3. Each user in the Issuer's Portal owning a Master Password, which is fed into configurable rounds of PBKDF2() salted with Issuer's identifiers, in client side, resulting in User's Portal Master Encryption Key.

4. Each key vault owning an RSA key pair, generated atthe time of user creation, in client side, with the public key being saved in the key vault. The private key either saved securely by the User locally, which due to the size of RSA keys would be a logistical issue with minimal portability, or, for convenience and portability, being encrypted with AES256, in client side, using User's Master Encryption Key and then uploaded to the key vault, as per Figure 5.

Design Philosophy:

The important principle is that the intermediary who is responsible for transferring data between issuers and recipients must not have access to receipt data in plain format, which is why they get encrypted before being uploaded to the Issuer's Portal, each with independent keys, even though issuer's copies of receipts are fully anonymous. However, a user in the Issuer's Portal should still be able to view receipts in decrypted format when logging into the portal. The decryption must happen at client side.

One approach to reach this goal would have been to let each user in the Issuer's Portal only view issued receipts on the POS machines, not in a centralized portal. This would be restrictive and not portable and would make centralized billing reporting, data analysis and business intelligence reportingvery inefficient and non-portable, which is the driver behind the Issuer's Portal idea. However, how to make receipt encryption keys available to a portal user securely is the challenge to solve in this case.

Importantly, no encryption key saved at server side must be constructible by the intermediary. To facilitate all these requirements, RSA scheme has been used to ensure each independent receipt encryption key can be encrypted itself using a singular public key associated with a user's key vault in the Issuer's Portal. This allows the owner of the private RSA key to perform decryption in client side and re-construct the independent keys used to encrypt receipts at the time of viewing them.

As a result, each portal user will have to have their own key vault which should include all the encryption keys of the receipts they have access to in RSA-encrypted format. This implies the encryption keysand encrypted receipt data to be saved separately with the receipt data being saved in common for all portal users. As long as the private RSA key is secure and accessible at client side, all such requirements have been met.

Therefore, Issuer's Portal enables its users to choose between two options: a) To save the private RSA key locally and securely and provide later at the time of logging back in, which may be challenging due to its size (which cannot be remembered like a password) or physical security constraint, or b) to choose a master password, which is used to derive a secure and hard-to-brute-force key, and then use the key, at client side, to encrypt the private RSA key and save it in the user's key vault in encrypted format. Since the master password itself is not saved in any form (even derived form) on servers, the entire scheme preservers its original security requirements while allowing the portability intended, without the portal user needing to store a private or manage a private key on their own.

5. When a new user is created in the Issuer's Portal, all POS SDK instances get informed and update their local secure storage with the public RSA key of the newly created user's key vault.

2019100775 17 Jul 2019

6. At the time of issuing a receipt, POS SDK instance encrypts the issuer's copy of the receipt data, locally, using the public RSA key of all users in the issuer's account within the Issuer's Portal and updates all such key vaults with the newly created key using the receipt identifier of the receipt. Only the owner of the private RSA key will be able to have access to the decrypted form of such data (i.e. the owner of the key vault), as per Figure 3.

7. Every time a user logs into the Issuer's Portal, in client side, using their Master Password, a copy of their private RSA key of their key vault is decrypted and used to decrypt the receipt encryption keys saved in their key vault whenever they view a receipt, which is downloaded in encrypted format and decrypted at client side, as per Figure 4.

8. When a new user is created in the portal, they will only have access to the receipts created after the moment of their account being created unless the entire key vault of a super admin user is downloaded in client side, cloned, re-encrypted using the newly-created user's key vault private RSA key and then uploaded to the corresponding user's key vault, as per Figure 5.

9. Loss of the Master Password will be equivalent to loss of access to the key vault since the master passwords (or their derivations) are not saved on back-end servers and all master key decryption processes happen at client side.

vi. These SDKs may call Application Programming Interface (API) back-ends hosted online while NOT sending any receipt data in unencrypted format out of the premises owned by receipt issuers (or their POS stations for that matter). These libraries may be integrated into POS systems to be called from and by such POS systems, or alternatively, as cited in our previous patent #2019100146, they can be called by any other relevant mechanism after receipt data has been captured from POS systems to be transferred to recipients.

f. Application Programming Interfaces (APIs) which are publicly or privately available back-ends providing functionality around user or POS machine registration or transfer of data between POS machines and recipients or saving locally-encrypted receipt data to be used in Issuer's Portal

g. Optional Receipt Recipients' software applications (hereby referred to as Recipient's App),which can be viewed as the software system that a receipt recipient may use to receive receipts from receipt issuers or their POS SDK instances using the Secure Receipt Transfer protocol, comprising

i. Local database encrypted at rest using AES256 scheme with encryption keys randomly generated upon installation and such keys being saved on hardware-backed keychain storage of the smartphone hence preserving full client-side security against unauthorized access or download of smartphone application data ii. Business logic layer facilitating the communication to the APIs and back-ends as well as the database layer

Hi. User interface layer facilitating communication with the end users iv. Deal and offer mining/deduction rule processing engine that receives downloaded sets of public Abstract Anonymous LoyaIty/Marketing Rules published by receipt issuers (i.e. businesses) and applies them to the locallysaved encrypted data OFFLINE, WITHOUT sending any user information or purchase history details to online backends, with the goal to extract, deduct and mine applicable Abstract Anonymous LoyaIty/Marketing Deals/Offers that fulfil the downloaded Abstract Anonymous LoyaIty/Marketing Rules against the data that can only be accessed in decrypted format on users' devices by the Recipient's App only.

NOTE:

The fact that locally encrypted data does not get sent to online back-ends can be verified by viewing the openlyreleased codebase of the smartphone applications or parts of their codebase that performs these rule processing operations.

With the smartphone applications facilitating the following functionality:

v. User registration, sign-up and sign-in facilities vi. Receiving a Receipt Transfer Request from receipt Issuers through relevant mechanisms including but not limited to scanning QR codes generated by Issuers, or manual data entry, or radio-frequency and wireless transfer of the Receipt Transfer Request from the Issuers to Recipient's App vii. Establishing real-time communication with the receipt Issuers based on the details within a Receipt Transfer Request to perform a complete end-to-end encrypted transfer of receipt data from the Issuer. This real-time communication channel can be established directly using NAT traversal point-to-point connections, or alternatively, through intermediary servers or Internet-Of-Things publish/subscribe messaging protocols like MQTT (Message Queuing Telemetry Transport), or any other relevant real-time communication mechanism through the Internet network viii. Receive and download receipt data from a receipt Issuer and decrypt them using the Secure Receipt Transfer Protocol, marking the transaction using a Transaction Marker that is generated for the first transaction and remains the same for future ones between the same recipient and issuer, and sing the issuers' transaction using Secure Receipt Transfer Protocol's Digital Signature scheme, persist and save receipts in local and encrypted databases ix. Search, categorization, labelling and indexing of receipt data

x. Creation of Periodic Expense Management Plans with quotasand limits of budgets or number of purchases xi. Notifications for reaching quotas of Periodic Expense Management Plans xii. Notifications based on GPS locations for returning items that have been marked for return by the user xiii. Receiving push notifications regarding the deals or offers from businesses the user may have chosen to be subscribed to xiv. Downloading a set of Abstract Anonymous LoyaIty/Marketing Rules from the online back-ends that have been published by receipt issuers (i.e. businesses) that the user has chosen to receive offers from xv. Applying Abstract Anonymous Loyalty/Marketing Rules to locally encrypted data in unencrypted format in an OFFLINE fashion WITHOUT sending the data to online back-ends outside of end users' device hence mining, deducting and generating applicable Loyalty/Marketing Offers that fulfil such Abstract Anonymous Loyalty/Marketing Rules, as per Figure 6 xvi. Demonstrating a list or map view of all mined, deducted and applicable deals and offers available to the user xvii. Functionality to Make a Claim against applicable and eligible Loyalty/Marketing Offers, process comprising

1. The verification of receipt and applicability of offers by receipt issuers by entering the identifier of one of the receipts owned by the recipient in the Issuer's Portal, or,

2. The generation of Random Return Addresses by the Issuer's Portal (to be provided to recipient at the time of Honouring the Claims through QR codes or other applicable mechanisms)

3. Recipient's App using the Random Return Address to provide one receipt identifier to the Issuer's Portal and enabling the Issuer's Portal to look up the history of all purchases made by the recipient WITHOUT the recipient needing to reveal their identity.

xviii. Verifying the Authenticity of the Contents of a Receipt:

As will be explained in section d.xi, each receipt includes an Authenticity Signature that can be verified easily by feeding the entire text of the receipt toa SHA256 HMAC function. It is possible validate the authenticity and unchanged status of a receipt contents by applying the SHA256 HMAC function against the downloaded receipt text at the time of verification and checking it against the originally supplied SHA256 hash of the receipt by checking the following equality equation

SHA265(Full Text of Receipt — to — be — verified ) = Included Authenticity Signature of the Receipt xix. Verifying the Digital Signature of a Receipt:

As will be explained in section d.xii, each receipt includes a Digital Signature by its Issuer, as well as the Identifier of the Receipt Issuer and the POS Machine Identifier and the used Key Index at the time of issuance, which can be used

2019100775 17 Jul 2019 to verify that a) the current receipt contents are the same as the contents that the Issuer originally put in the receipt, and b) the receipt with its current contents have been actually generated by the claimed Issuer.

It would be possible to validate both above statements by checking the following equality equation

ECDSA(Full Text of Receipt — to — be — verified, IKp_Os_Publlc) = Included Digital Signature of the Receipt

Where IKpos_PubUcis the public identity key used by the issuer, which can be queried from online back-ends using the Issuer's Identifier, POS Machine Identifier and the used Key Index.

xx. Features to look up or select a receipt and send its identifiers to the Receipt Issuer's Portal in real-time to facilitate an easy and seamless look-up of the same receipt by an operator using the Receipt Issuer's Portal, as per section i.xiv. This can enable other processes like refund issuance, or claiming loyalty and marketing deals, or any other processes which involves looking up a receipt from a list of receipts for a receipt recipient or buyer.

xxi. Features to Claim deducted/mined loyalty and marketing deals with the receipt issuer providing the deal xxii. Features to prove authenticity of claims and applicability of Abstract Anonymous LoyaIty/Marketing Rules to the receipt issuer at the time of claiming an applicable loyalty/marketing offer

h. Real-time communication back-end which provides facilities for the Issuers and recipients' smartphone applications through any applicable means, including but not limited to NAT traversal point-to-point connection, or alternatively, through intermediary servers or Internet-Of-Things publish/subscribe messaging protocols like MQTT (Message Queuing Telemetry Transport), or any other relevant real-time communication mechanism through the Internet network

i. Receipt Issuer's Portal, a single-page web-based application utilizing client-side logic, comprising

i. User interface components ii. Front-end business logic and secured local storage, including client-side code (e.g. JavaScript) capable of communicating with secured API back-ends to download end-to-end encrypted data from such back-ends and decrypt them locally in the web browser and feed them to the user interface components iii. Back-end API end-points that are secured only for authorized users and can provide end-to-end encrypted data to the front-end business logic to be decrypted locally

With the Receipt Issuer's Portal providing the following functionality:

iv. Functionality to sign up, log in and manage accounts

v. Functionality to download POS SDK Instances vi. Functionality to download POS tools that can bridge between POS systems and POS SDK instances vii. Functionality to register multiple POS machines multiple times (in which case different Key Indexes will be assigned to a POS machine), the process comprising

1. Generating a POS Machine ID to be entered in the Receipt Issuer's Portal

2. Generating a set of elliptic curve key pairs, saving the private keys on secure local storage and sending public keys as part of the registration process to the back-end APIs (as explained in section d.i)

3. The Receipt Issuer's Portal providing the Receipt Issuer ID to be entered in the POS SDK instance configuration settings

4. The Receipt Issuer's Portal providing the Key Index to be entered in the POS SDK instance configuration settings

5. The POS SDK instance downloading the public RSA keys of all users within the account of an issuer in the Issuer's Portal, later used to encrypt the unique-per-receipt encryption keys that are used to encrypt receipts before uploading them to the Issuer's Portal, as per section e.v

6. Local settings and configurations being set by the party installing the instance

2019100775 17 Jul 2019 viii. Functionality to manage, view and set up billing details ix. Functionality to view billing reports

x. Features to access Issuer's end-to-end encrypted receipt data in issuer's retailer portal, as explained in section e.v.7 xi. Functionality to view and select and manage lists of already-issued receipts xii. Functionality to create Abstract Anonymous LoyaIty/Marketing Rules, each comprising

1. Title

2. Applicability start and end dates, or periods against past purchases (e.g. one month)

3. A list of quantities of sellable goods or services to be included in a loyalty offer (e.g. 10 meals with identifier X)

4. A list of operators (i.e. AND, OR, XOR, NOT) that can apply

5. An applicable offer (e.g. 5% discount for next purchase)

6. Validity period for the applicable offer (e.g. till June 30,2018)

A full example of an Abstract Anonymous LoyaIty/Marketing Rules can be as follows, which can demonstrate they are abstract, they are not linked to anyone's identity, the define the underlying applicability rules of an offer or deal:

-Rulel:

Forpurchases between 1-7-18 to 1-8-18, OR, in the recent 45 days, those who have purchased (Item X, AND, Item Y) OR (Item A, AND, Item B) can receive a 10% discount with their next purchase until 30-6-19. -Rule2:

Anyone can receive a 5% discount in their next purchase until30-6-19.

-Ruie3:

Forthose who have purchased item X10 times in the last year, they can receive a 15% discount in their next purchase of item X, only once, until30-6-19.

xiii. Functionality to generate reports in multiple dimensions against the receipt data to extract business intelligence, especially against transactions that can be grouped by having similar Transaction Markers hence having been made by the same buyer xiv. Features to look up a receipt owned by a receipt recipient on their Recipient's App easily and seamlessly, the process comprising

1. The Recipient's App enables the user to look up the receipt from local storage from a list or by searching and then waiting for the next step

2. The Receipt Issuer's Portal then creates a random Local Return Address to act as a communication address to be provided to Recipient's App via an appropriate method (e.g. QR code to be scanned, alphanumeric codes to be entered or sent manually or through email or other mechanisms). The Receipt Issuer's Portal then starts listening on the Local Return Address through applicable means like Internet-ofThings publish/subscribe protocols like MQTT ((Message Queuing Telemetry Transport) or other point-topoint real-time communication mechanisms

3. Upon the reception of the Local Return Address, Recipient's App then sends through the Receipt identifier(s) (e.g. Receipt Random ID and Receipt Timestamp) to the Receipt Issuer's Portal using the Local Return Address.

4. Upon the reception of the receipt identifiers, the Receipt Issuer's Portal then looks up the receipt based on the provided identifiers.

5. Receipt Issuer's Portal also shows a list of other receipts with the same Transaction Markers as with the selected receipt, which can enable the operator to view the other purchases made by the same receipt recipient without revealing their identity

2019100775 17 Jul 2019 xv. Functionality to view a list of claims made against Abstract Anonymous Loyalty/Marketing Rules xvi. Functionality to Honour A Claim against Abstract Anonymous Loyalty/Marketing Rules, the process comprising

1. Generating Receipt Verification Code for a receipt (similar to the method explained under section d.xvi.1)

2. Entering or verifying a Claim number provided by a Receipt Recipient

3. Being able to view the history of all purchases made by the same Receipt Recipient making the claim, WITHOUT being able to view or have access to any details about the Receipt Recipient's identity making the claim.

IMPORTANT NOTE:

The receipt issuer already has access to the list ofthe receipts they have issued. It is just that they cannot know who the buyers (i.e. receipt recipients) in those transactions are. Neither can the intermediary transferring data between issuers and recipients nor can any attacker know this, as per the Secure Receipt Transfer Protocol and its cryptographically-sound design.

The possibility to slice and dice issuers' transactions is made possible through the fact that all such transactions have been marked by the same Transaction Markers by Recipient's App for the same receipt recipient. These transaction markers cannot be traced back to the identity of a user in any form or shape as the Secure Receipt Transfer Protocol cryptographically makes it impossible.

xvii. Functionality to create loyalty and marketing campaigns around Abstract Anonymous Loyalty/Marketing Rules and send out push notifications to those who have subscribed to receive such notifications from them xviii. Functionality to import and export data

j. Transport Security:

All traffic between all components like Issuers (POS stations) and server back-ends, or between POS SDK instances and Recipients, or between Recipients and server back-ends, or between web browsers and server back-ends are secured using Transport Layer Security of at least vl .2.

Claims (4)

1. A cryptosystem comprising an end-to-end encrypted messaging protocol between receipt issuers and receipt recipients to transfer receipt data securely, anonymously and privately in a tamper-resistant manner, comprising systems, methodsand applications that apart from end-to-end encryption of receipts, also facilitate mining/deducting anonymous individualized loyalty and marketing offers applicable to buyers'encrypted purchase history without comprising buyers'anonymity or server-side processing of purchase history via Abstract

Anonymous Loyalty/Marketing Rules; all compromising

a. Receipt Issuers

b. Receipt Recipients

c. The Secure Receipt Transfer Protocol, facilitating the followings

i. Defining message structures, steps, stages, conditions, conventions, conversations and actions taken between receipt issuers and receipt recipients to securely agree upon unique common shared secrets and encrypt/decrypt receipts ii. End-to-end client-side encryption of receipts and their transfer (both in real-time and in offline mode) between receipt issuers and receipt recipients with each receipt being encrypted with its own independent key iii. Marking transactions anonymous against receipt issuers, and, intermediaries transferring data between issuers and recipients, and, attackers, so that transactions made by the same receipt recipient are marked equallyfor the same receipt issuer without traceability back to the recipient's identity iv. Providing attributes (as per next claims) like anonymity preservation that lay the foundations of anonymouslyindividualized loyalty management and marketing in which, despite end-to-end encryption of receipt data and purchase history, and a 3^rd party's zero knowledge over a buyer's purchase history, individualized deals and offers, influenced by and deducted from the buyer's purchase history are mined and presented to them

v. Digitally singing receipts in multiple forms by issuers to assure integrity, tamper-resistance and authenticity of receipts vi. Digitally singing transactions for receipt issuers so that the identity of the recipient remains unknown to the issuer, as well as the intermediary transferring data between issuers and recipients and attackers vii. Recoverability of half-way incomplete handshakes between receipt issuers and receipt recipients

d. Optional Point of Sale (POS) Software Development Kits (SDKs) Instance: An instance of the tools and software libraries installed on a POS system that facilitate the followings:

i. Exposing libraries and functions that can be called by POS systems for issuing receipts based on the Secure Receipt Transfer Protocol ii. The transfer of receipt data from POS systems to receipt recipients in an end-to-end encrypted fashion using unique encryption keys per each receipt as per the Secure Receipt Transfer Protocol iii. Locally encrypting and uploading issuer's copies of receipts to the Receipt Issuer's Portal using Unique-Per-Receipt Issuer's Portal Upload Keys. Issuer's copies of receipt data are completely anonymous and do not contain recipient identifying information, as per the Secure Receipt Transfer Protocol. These copies are uploaded to the Issuer's Portal in end-to-end encrypted fashion to enable issuers to manage billing, searching, and grouping, report generation and marketing/loyaIty campaign creation in a centralized dashboard.

e. Receipt Recipients' software applications (Recipient's App) that facilitates the followings

i. Reception of end-to-end encrypted receipts from receipt Issuers ii. Secure storage of receipts iii. Searching, labelling and categorizing receipts iv. Notifying user of quotas and expense management limits being approached, or GPS-based reminders of items to be returned

v. Downloading publicly-advertised Abstract Anonymous Loyalty/Marketing Rulesfrom online- back-ends,

2019100775 17 Jul 2019 vi. Performing local data processing against local receipt data and purchase history, matching the applicability of Abstract Anonymous Loyalty/Marketing Rules to local purchase history without server-side processing or sharing of purchase history data vii. Verifying receipts viii. Engaging in receipt look-up with the Issuer's Portal and facilitating receipt verification ix. Claiming and helping honour applicable loyalty and marketing offers

f. Application Programming Interfaces (APIs) which are publicly or privately available back-ends providingfunctionality around user or POS machine registration or transfer of data between POS machines and recipients

g. Real-time communication back-end which provides facilities for the issuers and recipients'smartphone applications through any applicable means (including but not limited to Point-to-point or Internet-Of-Things real-time publish/subscribe messaging protocols like MQTT)

h. Receipt Issuer's Portal, a single-page web-based application, facilitating the followings

i. Account and billing managementfor receipt issuers ii. Browse, view, download, categorize, group, generate reports and intelligence against the receipts issued by the issuer iii. Create Abstract Anonymous Loyalty/Marketing Rules iv. Create loyalty and marketing campaigns

v. Look-up receipts and engage with verifying receipts vi. Honour applicable loyalty and marketing campaign offers without revealing or requiring buyers' identities

2. The proposed Secure Receipt Transfer Protocol provides a number of importantand novel properties, including

a. Receipt recipients' privacy and anonymity preservation, because:

i. Both Recipient and Issuers choose their Local Return Address parameters completely randomly. No part of such addresses is linked to or includes any party's identifiers, neither for the issuer nor for the recipient hence such addresses cannot be used to trace back to a user identifier for the recipient.

ii. For every receipt delivered, the local and remote addresses are deleted permanently and local addresses are unsubscribed from leading to the permanent closure of the temporary communication channel between Recipients and Issuers iii. In none of the messages sent by Recipients to Issuers (i.e. Key Exchange Message), an identity-revealing parameter is passed. This anonymity is the reason why the subsequent requests made by Recipients must be authenticated to have come from the same party that received the original Receipt Transfer Request generated by the Issuer. The absolute random generation of ephemeral elliptic keys to start the handshake does not leave any way to trace back, from the included public Receipt Transfer Keys in the initial Key Exchange Message to the identity of the receipt recipient involved in the handshake.

iv. The fact that the private Receipt Transfer Keys are saved securely by the Recipient and that they are not shared with any parties or even the intermediary transferring data between recipients and issuers, leaves only a randomlygenerated public key as the only hook to the recipientof the transfer, which would leave no options to trace back to the real owner of the private keys used.

b. Receipt integrity, correctness, issuer's non-repudiablity and tamper-resistance

i. The inclusion of Receipt Authenticity Signature and Receipt Digital Signaturescan be used to verify that

1. The contents of the receipt at the time of verification are the same as the contents used to create the included Receipt Authenticity Signature

2. The contents of the receipt at the time of verification are the same as the contents used to create the included Receipt Digital Signatures. Without access to the private keys used by the Issuer involved in the

2019100775 17 Jul 2019 transfer, it is impossible to forge this signature. The fact that the same signature is saved and persisted by

Issuer separately gives it another layer of security against possible forgeries by adversaries that may be able to break into and change the locally-saved data owned by the Recipient.

c. Forward secrecy

The fact of using an approach similar to the X3DH Key Agreement Protocol (i.e. Extended Triple Diffie-Hellman) makes it possible to inherit a whole set of cryptographic properties from X3DH, including forward secrecy that protects past sessions against future compromises of secret keysdue to thefact that the handshake involves a signed pre-key as well as an ephemeral key generated for the handshake.

3. A novel method of making the inherently-opposing characteristics of anonymity and individualization possible at the same time in the context of loyalty management and marketing, as per Figure 6, the method comprising

a. Issuers encrypting each receipt by an independent key securely agreed upon with Recipients when transferring them to recipients

b. Issuers encrypting each receipt by a different independent key securely stored in the key vault of a user using the Issuer's Portal in encrypted format

c. Receipt Issuer's Portal, a web-based tool that makes it possible for a user (e.g. super admin or an employee in a business) to view all their issued receipts, generate reports out of them, group and bundiethem based on buyers, create and manage anonymous marketing campaigns and Abstract Anonymous Loyalty/Marketing Rules, as well as payment and account management

d. Receipt data being transferred to receipt recipients from POS machines in end-to-end encrypted format which does not leave any options possible for the intermediary transferring the data between them to know what the data actually is (i.e. what a buyer has bought, what their purchase history looks like)

e. Receipt issuers'transaction data being marked using the same anonymous Transaction Markers for the same receipt recipient, enabling receipt issuers to dice and slice their local data and extract intelligence and insights from data without knowing the identity of their buyers

f. The concept of Abstract Anonymous Loyalty/Marketing Rules: anonymous rules that if fulfilled, certain deals/offer would become eligible and applicable.

An example of a rule can be as follows:

Forpurchases between 1-7-18 to 1-8-18, OR, in the recent 45 days, those who have purchased (Item X, AND, Item Y) OR (Item 4 AND, Item B) can receive a 10% discount with their next purchase until30-6-19.

g. Abstract Anonymous Loyalty/Marketing Rules being advertised publicly through back-endsand downloaded by Recipient's Apps

h. Recipient Apps, performing LOCAL, OFFLINE, NON-SERVER-SIDE dynamic mining and checking the applicability of the downloaded public Abstract Anonymous Loyalty/Marketing Rules against the securely-saved local purchase data, not shared with any parties

i. Recipient's App and Receipt Issuer's Portal features to anonymously verify a receipt, enablingthe process for the Issuer to Honour the loyalty/marketing offers applicable to a certain anonymous buyer with a history of transactions

4. Web-based access through the Issuer's Portal to receipt issuer's receipt history that is end-to-end encrypted client side without data transfer intermediaries or attackers being able to have access to receipt data, the method comprising

a. The use of RSA key pairs with the public key saved in the user key vault and shared with POS stations

b. POS stations using the public RSA key of each portal user to locally encrypt receipt encryption keys and saving them in a user's key vault for each receipt

c. POS stations saving the encrypted receipts commonly for all portal users

d. The portal user being able to either own and provide the private RSA key when logging into the portal or alternatively, having it saved in their key vault in locally-encrypted form for portability and ease of use

e. Optionally, portal users to own a Master Password, which is fed to configurable rounds of PBKDF2 key derivation function to derive a hard-to-brute-force Portal Encryption Key for the userand the Portal Encryption Key being used to locally encrypt and decrypt the private RSA key of a user's key vault (if they choose to have it saved in their key vault) hence providing portability and ease of use without needs to maintain a private RSA key by portal users.

2019100775 17 Jul 2019

References