Patent Description:
When cardholders undertake transactions a receipt relating to the transaction is generated. Traditionally such receipts have been provided in either hard-copy form (a printed receipt) and/or in electronic form (e.g. a copy of a receipt may be emailed to a cardholder both in cardholder present transactions and also in cardholder not present transactions that occur via an online merchant).

Subsequent to a transaction between a cardholder and a merchant limited transaction data may be available for later retrieval by the cardholder.

Where merchants offer goods or services to consumers, incentives may be offered in order to seek to increase sales. Tracking the effectiveness of such incentive campaigns may require the sharing of transaction related data between two or more entities. In order to share such information a suitable data exchange protocol is required which maintains an agreed level of privacy and confidentiality for the various stakeholders involved in the transaction (e.g. cardholder, merchant, product manufacturer and promoter). <CIT> describes a method of tracking tagged transaction data corresponding to transactions between users and merchants is provided. The method includes receiving, by the tag tracking computing device, a plurality of transaction signals including a plurality of transaction data associated with the transactions.

The present disclosure aims to provide improved transaction related data retrieval and transaction sharing.

According to a first aspect of the present disclosure, there is provided a method of sending data related to cardholder transactions, comprising: receiving transaction data from a merchant relating to the cardholder transactions, the transaction data comprising itemised product data and payment device data, the itemised product data comprising itemised receipt line items for goods or services received from the merchant; storing, for each transaction, the received transaction data relating to that transaction in a transaction record in a database; aggregating received transaction data and storing the aggregated transaction data in the transaction records; receiving a request for data related to cardholder transactions stored in the database; querying the database and returning aggregated transaction data to a third party, wherein each transaction record comprises a transaction ID and wherein the database defines a set of attributes relating to the transaction records, the method comprising: generating a polynomial Ai(X) for each attribute where the zeros of the polynomial correspond to the transaction IDs of the records that have the ith attribute; assigning a Tag, Tag_i, to each attribute and encrypting (<NUM>) each Ai(x) as Enc (Ai(x)); sending the set {Tag_i, Enc(Ai(x))} to a proxy database; receiving an encrypted and blinded polynomial Enc(B(x)) from the proxy database, the polynomial Enc (B(x)) comprising attributes selected by a third party; decrypting Enc(B(x)) with the third party.

The present disclosure provides a method of receiving transaction data related to cardholder transactions, storing and aggregating the received data before returning, in response to a request, the aggregated data to a third party. The received transaction data comprises itemised product data (e.g. the products bought in the transaction) and payment device data (which enables a cardholder to send a request for their receipt data and for this data to be returned to the cardholder).

The present disclosure therefore enables cardholders to obtain a digital record of their itemised receipt data and third parties to perform analytics on suitably anonymised and aggregated data. Services such as Mastercard's M/Chip Tap and Connect allow itemised lists of items purchased by a cardholder in a transaction to be collected and stored.

The received transaction data is also anonymised and the aggregated and anonymised transaction data may be stored in the transaction records.

According to a second aspect of the present disclosure there is provided a database system comprising transaction data related to cardholder transactions, the database system comprising: an input arranged to receive transaction data from a merchant relating to cardholder transactions, the transaction data comprising itemised product data and payment device data, the itemised product data comprising itemised receipt line items for goods or services received from the merchant; ; a processor arranged to: store, for each transaction, the received transaction data relating to that transaction in a transaction record; aggregate received transaction data and store the aggregated transaction data in the transaction records; an output for outputting transaction data wherein the input is arranged to further receive requests for cardholder transactions stored in the database and the processor is arranged to query the transaction records and return aggregated transaction data to a third party, the output being arranged to output the returned transaction data to the cardholder or third party wherein each transaction record comprises a transaction ID and wherein the database system defines a set of attributes relating to the transaction records, the processor being arranged to: generate a polynomial Ai(X) for each attribute where the zeros of the polynomial correspond to the transaction IDs of the records that have the ith attribute; assign a Tag, Tag_i, to each attribute and encrypt (<NUM>) each Ai(x) as Enc (Ai(x)) wherein the output is arranged to send the set {Tag_i, Enc(Ai(x))} to a proxy database and the input is arranged to receive an encrypted and blinded polynomial Enc(B(x)) from the proxy database, the polynomial Enc (B(x)) comprising attributes selected by a third party; and the processor is arranged to decrypt Enc(B(x)) with the third party.

According to an example useful for understanding the present disclosure described above, where the received request for data related to cardholder transactions comprises receiving a request for product data related to a specific product from a third party, the method may further comprise: filtering the database transaction data to identify a set P of cardholder accounts that have completed a transaction for the specific product; calculating M(P), where M() is a one way commutative function; receiving G(C) from the third party, where G() is a one way commutative function known to the third party and C is a set of data identifying accounts that have interacted with a campaign hosted by the third party for the specific product; calculating MG(C) and sending to third party such that the third party can determine the intersection of MG(P) and MG(C).

The set MG(C) may be shuffled before sending to the third party. Fictitious cardholder accounts may be added to the set P.

M() may be a commutative one-way function, such as an elliptic curve scalar multiplication function. G() may be a commutative one-way function such as an elliptic curve scaler multiplication function.

According toan example useful for understanding the present disclosure described above, where the received request for data related to cardholder transactions comprises receiving a request for product data related to a specific product from a third party, the method may further comprise: filtering the database transaction data to identify a set P of cardholder accounts, IDx, that have completed a transaction for the specific product for value Vx, such that P={IDx : Vx}; sending {M(IDx): E(Vx)} to the third party, where M() is a one way commutative function and E() is a homomorphic encryption function; receiving {GM(IDx):E(Vx+Rx)} from the third party, where Rx is a blinding factor applied by a third party; receiving {G(IDy)} from the third party, where G() is a one way commutative function known to the third party and {IDy} is a set of data identifying accounts that have interacted with a campaign hosted by the third party for the specific product; determining, at the database, an intersection set J of {GM(IDx)} and {MG(IDy)} and the set {E(Vx+Rx)}; decrypting values {Vx+Rx}; sending J and a total blinded sum S to the third party.

The received request may be for a class of products and the database may be filtered for cardholder accounts that have completed a transaction for the product class.

The method may comprise receiving transaction IDs from the third party wherein the transaction IDs have been determined by factorising the polynomial B(x) and sending aggregated transaction data relating to data record IDs associated with B(x) to the third party.

The method may comprise identifying a set P of cardholders that have completed a transaction for products associated with the data record IDs associated with B(x). The method may comprise sending transaction data associated with the set P according to the method of any of the above aspects of the disclosure. For example, the set MG(C) may be calculated as described above and sent. Additionally, the set J and total blinded sums S as described above may be sent.

The homomorphic encryption function may comprise a Paillier encryption function.

In the above methods of sending transaction data the database used may be the database according to the second aspect of the present disclosure.

According to a further example useful for understanding the present disclosure, there is provided a method of sending transaction data from a database, the database comprising transaction data in the form of a plurality of transaction records, each transaction record comprising product data for products obtained by a cardholder in a transaction, the method comprising: receiving a request for product data related to a specific product from a third party; filtering the database transaction data to identify a set P of cardholder accounts that have completed a transaction for the specific product; calculating M(P), where M() is a one way commutative function; receiving G(C) from the third party, where G() is a one way commutative function known to the third party and C is a set of data identifying accounts that have interacted with a campaign hosted by the third party for the specific product; calculating MG(C) and sending to third party such that the third party can determine the intersection of MG(P) and MG(C).

According to a further example useful for understanding the present disclosure, there is provided a method of sending transaction data from a database, the database comprising transaction data in the form of a plurality of transaction records, each transaction record comprising product data for products obtained by a cardholder in a transaction, the method comprising: receiving a request for product data related to a specific product from a third party; filtering the database transaction data to identify a set P of cardholder accounts, IDx, that have completed a transaction for the specific product for value Vx, such that P={IDx : Vx}; sending {M(IDx): E(Vx)} to the third party, where M() is a one way commutative function and E() is a homomorphic encryption function; receiving {GM(IDx):E(Vx+Rx)} from the third party, where Rx is a blinding factor applied by a third party; receiving {G(IDy)} from the third party, where G() is a one way commutative function known to the third party and {IDy} is a set of data identifying accounts that have interacted with a campaign hosted by the third party for the specific product; determining, at the database, an intersection set J of {GM(IDx)} and {MG(IDy)} and the set {E(Vx+Rx)}; decrypting values {Vx+Rx}; sending J and a total blinded sum S to the third party.

According to a further aspect of the present invention there is provided a method of sending transaction data from a database, the database comprising aggregated transaction data in the form of a plurality of transaction records, each transaction record comprising product data for products obtained by a cardholder in a transaction and having a transaction ID, wherein the database defines a set of attributes relating to the transaction records, the method comprising,: generating a polynomial Ai(X) for each attribute where the zeros of the polynomial correspond to the transaction IDs of the records that have the ith attribute; assigning a Tag, Tag_i, to each attribute and encrypting each Ai(x) as Enc (Ai(x)); sending the set {Tag_i, Enc(Ai(x))} to a proxy database; receiving an encrypted and blinded polynomial Enc(B(x)) from the proxy database, the polynomial comprising attributes selected by a third party; decrypting Enc(B(x)) with the third party.

According to a further example useful for understanding the present disclosure there is provided a method of sending transaction data from a database, the database comprising transaction data in the form of a plurality of transaction records, each transaction record comprising product data for products obtained by a cardholder in a transaction, the method comprising:.

It is noted that the order of the steps in the above method according to the present disclosure may be varied slightly depending on the particular implementation of the method, e.g. certain steps may occur together or in a different order to that shown above.

One or more embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:.

General and specific embodiments of the disclosure will be described below with reference to the Figures.

<FIG> shows a transaction system <NUM> comprising a cardholder's payment device <NUM> (in the arrangement shown in <FIG> this is a mobile device <NUM> with a digitised payment card <NUM> stored in a digital wallet. It is noted however that the transaction system may also comprise a physical payment card <NUM> in place of the mobile device), a merchant system <NUM> (comprising a point of sale device <NUM> and an electronic cash register <NUM>), a transaction network <NUM> and a remote database <NUM>.

During a transaction, a cardholder's payment device <NUM> undertakes a transaction with the merchant system <NUM>. The cardholder presents their payment device <NUM> during the transaction and, optionally, an offer token (such as a loyalty token or voucher) and payment for the goods or services obtained from the merchant is then taken.

Once the transaction is authorised, transaction data <NUM> (including an itemised receipt of the goods/services obtained by the cardholder and additionally payment device data) is sent via the transaction network <NUM> to the remote database <NUM> where the transaction data is stored. Subsequently the cardholder may retrieve their itemised receipt from the remote database <NUM>.

As a plurality of cardholders undertake transactions, the remote database is configured to receive transaction data from each transaction and to store such transaction data.

<FIG> shows a method of retrieving data from the remote database in which in step <NUM> transaction data relating to cardholder transactions is received at the remote database. The transaction data for each transaction comprises itemised product data and also payment device data. It is noted that the payment device data received is sufficient to identify specific cardholders. "Product data" in the present context means an itemised receipt line item for a goods or service received from the merchant.

In step <NUM>, the remote database is arranged to store, for each transaction, the received transaction data in a transaction record in the database, each specific transaction (transaction record) relating to a specific cardholder account.

In step <NUM>, the received transaction data is aggregated and the aggregated transaction data is additionally stored in the records within the database. As part of the aggregation process the specific transaction data relating to a given cardholder's transaction may be aggregated into one or more transaction data categories (e.g. merchant name, merchant type, product category, product brand, transaction amount or transaction range etc.). The aggregation process may effectively create an anonymised counterpart of the cardholder's transaction data.

Following step <NUM> the database may comprise a number of records where each record comprises aggregated data representing a purchased item and associated payment account (PAN), date, product identifier, and price. For the sake of this example the primary index of the database is Record#. Fully itemised product data may also be present within the Record# for access by the cardholder.

In step <NUM> the remote database may subsequently receive a request for data relating to cardholder transactions stored in the database. Such a request may originate from the cardholder themselves or from a third party.

In Step <NUM> the database may be queried and either itemised product data may be returned in the event that the querying entity is the cardholder or aggregated transaction data may be returned in the event that the request is received from a third party entity.

The use of the database containing transaction data and aggregated transaction data is described below in relation to two general use types: (i) where the actual consumer wishes to retrieve information relating to a transaction they have undertaken in the past (e.g. a user retrieving transaction data in order to activate or use a product warranty); (ii) where a 3rd party wants to access aggregated transaction data (e.g. so that a 3rd party can determine whether a promotional campaign for a targeted merchant (here, Walmart) and merchandise (here, electric appliances) was successful).

Consumer Access to Transaction Data (the "Warranty Use Case").

For the purposes of this example it is noted that a transaction, with the following parameters, has already taken place:
On March <NUM><NUM> at 15h20, John Junior Doe, son of John Doe, buys a Braun Brau Rasierer <NUM>-7880cc bk electric shaver as sole item at Walmart Supercenter in the Green Acres Mall, Valley Stream NY. The electric shaver costs $<NUM> and comes with a <NUM>-year warranty. pays for the shaver using his mobile device (the mobile device having been provisioned with a payment card in an application). The payment card used was a Mastercard with PAN <NUM>.

As part of the transaction with the merchant system, an itemised receipt is generated, in JSON format, as indicated below.

As per step <NUM> noted above the transaction data relating to the transaction is sent to the remote database where it is stored in a transaction record relating to consumer/cardholder "John Doe". The storage of the transaction data in the cloud at the remote database enables the consumer to retrieve information required to use the product warranty if necessary.

For example, in the event the shaver breaks down on November 5th, <NUM> (which is within a <NUM> year warranty period) then the cardholder is able to log into the remote database (for instance, through User ID and password) as John Doe. He is then able to place a search query (e.g. a combination of one or more of the search terms: "Electric shaver"; "Braun Brau"; "March <NUM>"; "Walmart") in order to access the digital itemised receipt data held on the database.

Third Party Access to Transaction Data (the "Campaign Use Case").

For the purposes of this example it is noted that the same transaction as noted above, with the same parameters, has already taken place. Following the receipt of the transaction data at the remote database the itemised data (that is personal to the specific cardholder John Doe) was aggregated into a number of transaction data categories (step <NUM> above) and also anonymised.

An example of the anonymised transaction data to be aggregated is illustrated below.

The aggregated and anonymised data may then be used by a third party as part of a campaign as follows. In February <NUM>, Walmart contracts the third party to start a promotional campaign on small electrical appliances affordable to youngsters that are typical for male adults, such as electric shavers or power tools. The campaign starts on March <NUM>st <NUM> and runs until March <NUM>st <NUM>. The third party operates in the online space and while the campaign is running the third party arranges for online adverts to appear in the browsers of, at least a proportion, of users browsing small electrical appliances.

Subsequent to the campaign concluding the third party is able to demonstrate to Walmart that the campaign had an effect and increased the number of affordable electronic appliances with respect to previous years, in particular to the previous year (i.e. <NUM>). This demonstration may be undertaken by the third party running a query on the database, comparing the total number of electrical appliances below $<NUM> bought at Walmart between March 1st and March 31st in <NUM> - where no promotional campaign was run- and the same period for <NUM>. A significant difference between the two numbers should illustrate the effectiveness of the campaign and therefore the value of the adverts/campaign.

The following worked examples further illustrate how transaction data within the remote database can be accessed by a third party while maintaining privacy controls.

Three worked examples are provided in order of complexity: the first deals with an advert for a specific product (e.g. Braun electric razor model 3200i), and the second deals with an advert for a product category (e.g. electrical appliances). In these two examples the third party queries the remote desktop with a search query (the transactions in which they are interested). The relevant transactions can then be filtered from the remote database and then, by means of a homomorphic protocol, the third party may be provided with a clicked subset of the associated aggregate information. In the third example the third party does not reveal their query criteria yet still manages to obtain the aggregate information for the transactions that satisfy their search query. The third example may be used on top of the existing 'double-blind' protocol in the first two worked examples or in place of it.

In the examples, distinction between a cardholder's payment account (that is known to the remote database owner) and an account that is known to the third party (e.g. an email) is not made and for simplicity the term account or ID is used.

Worked example <NUM> is detailed below in combination with <FIG> which shows the exchange of information between the remote database and the third party.

In this example a campaign (online adverts) has been run in respect of a specific product which is on sale at a number of merchants at roughly the same price. Consequently, it is sufficient to know the number of purchased products that correspond to a clicking of an advert (and indeed the number that do not), the actual monetary value of the transactions that has taken place is not relevant.

In Step <NUM>, the third party informs the remote database of the campaign (product and time period) such that the remote database can identify, in step <NUM>, all accounts that were used to purchase the specific product.

This step (<NUM>) requires access to the database of transaction data comprising itemized product data. The total number of cardholder accounts is therefore filtered and the result is a (multi-)set P of transaction data relating to 'purchased' accounts, where some accounts may be repeated if the cardholder made multiple purchases of the same product.

For the same time period, the third party identifies in step <NUM> all accounts that clicked on the advert for the specific product. This results in a set C of 'clicked' accounts.

In Step <NUM> the remote database encrypts the elements of P with its encryption function M(): M(P) = {M(IDx)}. The third party encrypts in step <NUM> the elements of C with its encryption function G(): G(C) = {G(IDy)}. It is noted that M() and G() are one way commutative functions known to, respectively, the remote database and the third party which are created in a set up phase. Such one way commutative functions may be elliptic curve scalar multiplications.

In Step <NUM> the remote database and the third party then exchange M(P) and G(C). Note, in Steps <NUM>/<NUM> it is possible for the remote database and the third party to include fictitious accounts that do not correspond to live accounts so that in Step <NUM>/<NUM> the size of the sets M(P) and G(C) do not reveal the number of product purchases or advert clicks, respectively.

In Step <NUM> the remote database then over-encrypts G(C) to become MG(C), shuffles the elements of the set and then sends, in step <NUM>, the shuffled MG(C) to the third party.

In Step <NUM>, the third party then over-encrypts M(P) to GM(P). Since the functions M and G commute then GM(P) = MG(P) and the third party is able to determine, in step <NUM>, the intersection of the two sets MG(P) and MG(C) such that.

By this mechanism the third party is able to determine the size of the intersection, being the number of items purchased that correspond to a click.

[It is noted that the steps shown in <FIG> may be varied in their order slightly without affecting the overall process, for example steps <NUM> and <NUM> described herein could occur before steps <NUM> and <NUM> or vice versa. Similarly steps <NUM> and <NUM> may happen concurrently or sequentially.

As an additional step the third party could screen out purchases that were made before an interaction with the campaign had occurred.

As an additional step, the remote database could provide the third party with the same information for unclicked accounts and also for a time period preceding the campaign. In this case, if after the campaign, the total number of items purchased increases, compared to a time period immediately prior to the campaign, by the number of purchase clicked accounts (i.e. the purchase unclicked accounts is the same for both time periods) then this is a strong argument that the additional purchases resulted from the clicks and hence the campaign.

In a variation to the worked example above a campaign may run in relation to a range of products which are on sale at a variety of prices at different retailers. As there is diversity in the products on sale a monetary value $value is included in the analysis below.

In an initial step the third party advises the remote database of a product range that is the subject of a campaign. The remote database is then able to provide aggregated transaction data to the third party as per the process below. Worked example <NUM> is detailed below in combination with <FIG> which shows the exchange of information between the remote database and the third party.

In a set up phase the remote database and third party create one way encryption functions M() and G() respectively. The remote database additionally generates a key pair for Paillier homomorphic encryption E() and shares the public key with the third party.

In step <NUM> the third party notifies the database of the campaign (product category and time period).

In step <NUM>, for the time period that the third party has indicated, the remote database identifies all transaction records (cardholder accounts) that were used to purchase items in the product category. This requires access to the database of transaction data comprising itemised product data. The total number of cardholder accounts is therefore filtered and the result is a (multi-)set P of aggregated transaction data relating to the 'purchased' accounts, where some accounts may be repeated if the cardholder made multiple purchases within the same product category. The remote database may optionally aggregate multiple transactions in respect of the same cardholder account and hold a single $value Vx for account IDx.

For the same time period, the third party identifies in step <NUM> all accounts that interacted with the campaign for the product category. This results in a set C of 'clicked' accounts.

In step <NUM>, the remote database encrypts the IDx in P with its encryption function M() and encrypts the Vx in P with the public key of the Paillier encryption function E(): ME(P) = {M(IDx):P(Vx)}.

In step <NUM>, the third party encrypts the elements of C with its encryption function G(): G(C) = {G(IDy)}.

In step <NUM> the remote database and the third party then exchange ME(P) and G(C). It is noted that in step <NUM> and <NUM> it is possible for the remote database and the third party to include fictitious accounts that do not correspond to live accounts so that in Step <NUM>/<NUM> the size of the sets ME(P) and G(C) do not reveal the number of product purchase accounts or advert clicked accounts, respectively.

In step <NUM>, the third party over-encrypts each M(IDx) to form GM(IDx) and blinds each Vx with an Rx (which it records for later use in Step <NUM>). The latter is achieved by encrypting Rx and exploiting the homomorphic properties of E(): calculating E(Rx) * E(Vx) = E(Vx + Rx).

The third party then sends, in step <NUM>, {GM(IDx):E(Vx+Rx)} to the remote database. It is noted that the elements of the set may be shuffled so that the remote database cannot cross-correlate items received with items sent.

In Step <NUM>, the remote database determines the purchased clicked items corresponding to the intersection J of {GM(IDx)} with {MG(IDy)} and then decrypts in step <NUM>, the values {Vx+Rx} associated with these values.

It can be seen that the third party's blinding of the Vx prevents the remote database from knowing the total value of the purchased clicked transactions as well as preventing cross-correlation (per the shuffling at the end of Step <NUM>).

The remote database then sends (step <NUM>) back to the third party the set J and the total blinded value S (the sum in J of {Vx+Rx}). The third party may then use the set J to calculate (step <NUM>) the total blind (the sum in J of {Rx}) and can then subtract this from S to reveal the total value of purchased clicked transactions.

Note: the functions M() and G() do not need to be encryption functions but rather commutative one-way functions with range equal to domain, thus satisfying G(M(z))=M(G(z)) for all z in the domain. Typical choices for commutative one-way functions M() and G() are modular exponentiation over a finite field or scalar multiplication of a point on an elliptic curve over a finite field. For example, the remote database and the third party could agree on a curve and a mapping of ID to points on the curve (which are the actual domain of the functions but the mapping is ignored for ease of exposition). Then the remote database may generate a secret scalar m and the third party generate a secret scalar g and if Qx is the point on the curve which represents IDx then M(IDx)=m·Qx and G(IDx)=g·Qx and, per Diffie-Hellman, M(G(IDx)= gm·Qx = mg·Qx = (G(M(IDx)).

Thus if using the curve P-<NUM> with standard generator G =
046B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296 4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
and with M() defined by the secret scalar m =
3CD78CF1F078BC7C376B797D2626416C0652C25214A73D07D787CE3BCFC3738F then an IDx = <NUM> (=0x0462D53C8ABAC0) might be mapped to the point IDx · G =
04B84C1BDE05E1F479E00E8DB7FF7DEF77042718F1A3C93535DFB72B4C17D0157 BFA9BEA6165BF53CA8387F34588225FE7F0A75AA619341C38E5F39D4C400E0A2A
and so the encryption of IDx under M() is m · (IDx · G) =
041D84DD86CB0C3334D38712117BBD891A6A73B0CF12D6860AD6BB2C33924C5C A14FF0F5FC2D0B3C8B51328E1E89E258102B79EF6790993AF06694C240A35D93EF.

The Paillier encryption function E() is a homomorphic encryption function like RSA but taking place modulo n<NUM>. The remote database may encrypt and decrypt, but the third party can only encrypt. As with the commutative one-way functions M() and G() there needs to be an agreed mapping to the domain, in this case, between $values and integers modulo n<NUM>which are the true domain of E(). Because n<NUM> might be over <NUM> bytes there will actually be space to map multiple $values into this domain.

In the first two worked examples described above the third party openly informs the remote database of the product to be queried. If this is considered a privacy problem then the remote database would either have to send the third party the full encrypted database or a privacy method such as that described in the third worked example below could be used.

In the third worked example privacy techniques are used to select a set of accounts {IDx} from the remote database without revealing the selection criteria to the database. The example described below additionally utilises a proxy database that is separate from the remote database described above. In the following example the selection criteria that the third party is using corresponds to "electrical appliances" from "Walmart" which are under $<NUM>.

As noted above, the present worked example involves two databases:.

With reference to <FIG>, the remote database receives in step <NUM> a request from the third party related to Walmart in March <NUM> and based on its historic data, the remote database prepares, in step <NUM>, a data set as a subset of the Mastercard Items database in which the dataset contains all transactions at Walmart between March <NUM>st, <NUM> and March <NUM>st, <NUM>.

For simplicity, it is assumed here that the dataset contains <NUM> transaction records, represented by the entries <NUM> to <NUM> in the table below. Each entry has an identifier equal to the Record# (written as REC) and so each entry is represented as REC1 to REC10.

In step <NUM> a list of attributes Ai (e.g. "electrical appliance", "<$<NUM>") are generated. Purchased items contained within the dataset fall into different product categories (e.g. electrical appliance, healthcare, beauty etc.) and have different amounts (or amount categories such as "<$<NUM>").

Within the dataset generated in step <NUM>, for example, Records REC1, REC2 and REC5 include the purchase of an electrical appliance (indicated by transaction records with an "X"). Records <NUM>, <NUM>, <NUM>, <NUM> and <NUM> include a transaction item costing less than <NUM>$ (indicated by transaction records with a "+").

In Step <NUM>, the remote database generates attribute polynomials Ai(x) whose zeros are the transaction IDs (REC#) of the records that have the ith attribute. It is noted that the remote database is arranged to generate a polynomial for all allowed query attributes along with an attribute identifying tag (the tag being a pseudo random function hash of the name of the attribute such that attribute information is not leaked to the Proxy database).

For example, each attribute in the Walmart March <NUM> data set is represented as a polynomial with roots corresponding to the matching records:.

In step <NUM>, to hide the polynomials (and hence their roots) from the Proxy database, the remote database encrypts all polynomials before sending them and their tags, in step <NUM>, to the Proxy lookup database where they are stored.

Each polynomial is encrypted in step <NUM> by encrypting its coefficients and the encryption function is a homomorphic encryption function E() owned by the remote database.

So polynomials A1(x) and A2(x) are stored at the proxy database as.

The Proxy database comprises an encrypted polynomial for each attribute that might be queried and as such there may be hundreds or thousands of such polynomials (each with an identifying tag).

In step <NUM> the third party obtains from the remote database the list of tags and associated attributes.

In step <NUM> the third party sends the tags associated with the attributes they are interested in ("electrical appliance" and "<$<NUM>") to the proxy database.

In step <NUM> the proxy database sends the third party an encrypted blinded polynomial. The blinded polynomial is B(x) = A1(x)R1(x) + A2(x)R2(x), where the polynomials Ri(x) are random polynomials multiplication by which does not affect the zeros of the polynomial. The blinded polynomial B(x) is encrypted by encrypting the coefficients of B(X).

In step <NUM> the third party then interacts with the remote database (e.g. using an oblivious protocol) to determine the decrypted polynomial B(x). In step <NUM> the third party then factorises the result to find its roots thereby finding the record indices of the conjunction of the two queries.

These record numbers can now be used by the third party to request from the remote database the desired records from the database in step <NUM>. The aggregated data corresponding to the identified records may be retrieved using a protocol as shown in either Worked Example <NUM> or <NUM> above.

<FIG> shows the remote database <NUM> of <FIG>, a third party computing device <NUM> representing the third party and the proxy database <NUM>. The remote database <NUM> comprises a data store <NUM> within which transaction data <NUM> is stored in the form of a number of transaction records <NUM> where each record <NUM> comprises aggregated data <NUM> representing a purchased item and associated payment account (PAN) <NUM>, date <NUM>, product identifier <NUM>, and price <NUM>. For the sake of this example the primary index of the database is REC#. Fully itemised product data <NUM> may also be present within the Record# for access by the cardholder. The proxy database <NUM> comprises a data store <NUM> within which are the tags <NUM> and encrypted attributes <NUM> received from the remote database <NUM>. The remote database <NUM> comprises an input <NUM> for receiving transaction data relating to cardholder transactions and requests from cardholders or third parties for transaction data stored in the database and an output <NUM> for outputting transaction data. The remote database <NUM> and proxy database <NUM> comprise processors (<NUM>, <NUM> respectively) arranged to carry out the various method steps described above in relation to <FIG>.

Claim 1:
A method of sending data related to cardholder transactions, performed by a remote database, comprising
receiving (<NUM>) transaction data from a merchant relating to the cardholder transactions, the transaction data comprising itemised product data and payment device data, the itemised product data comprising itemised receipt line items for goods or services received from the merchant;
storing (<NUM>), for each cardholder transaction, the received transaction data relating to that transaction in a transaction record in the remote database, wherein each transaction record comprises a transaction ID and wherein the remote database defines a set of attributes relating to the transaction records;
aggregating (<NUM>) the received transaction data and storing the aggregated transaction data in the transaction records;
receiving, from a third party, (<NUM>, <NUM>) a request for data related to cardholder transactions stored in the remote database;
generating (<NUM>) a polynomial Ai(X) for each attribute whose zeros correspond to the transaction IDs of the records that have the ith attribute; assigning (<NUM>) a Tag, Tag_i, to each attribute and encrypting (<NUM>) each Ai(x) as Enc (Ai(x)) sending (<NUM>) a set {Tag_i, Enc(Ai(x))} to a proxy database;
receiving an encrypted and blinded polynomial Enc(B(x)) that is based on the polynomial Ai(x) from the proxy database through the third party, the polynomial Enc (B(x)) comprising attributes selected by the third party;
decrypting Enc(B(x)) and sending the decrypted polynomial B(x) to the third party;
querying (<NUM>) the remote database based on the decrypted polynomial B(x) and returning aggregated transaction data to the third party.