WO2015159105A1

WO2015159105A1 - Method of determining user identity

Info

Publication number: WO2015159105A1
Application number: PCT/GB2015/051174
Authority: WO
Inventors: Roman VALIUSENKO; Hassan Hajji
Original assignee: Ecrebo Limited
Priority date: 2014-04-17
Filing date: 2015-04-17
Publication date: 2015-10-22
Also published as: GB201406999D0

Abstract

A method of determining a customer identifier from transaction data generated during a transaction at a point-of-sale system in which the customer has used a transaction device, the transaction at the point-of-sale system generating first and second payment data related to the transaction device andto the transaction, and the transaction device being associated with a customer identifier, the method comprising: receiving transaction data from the point-of-sale system, the received transaction data comprising the first payment data related to the transaction device and the transaction; extracting the first payment data from the transaction data; querying a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated withthe customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query; receiving, from the data store, the customer identifier associated with the determined second payment data.

Description

METHOD OF DETERMINING USER IDENTITY

Field of the invention

The present invention relates to a method of determining user identity. The invention extends to a system for determining user identity. In particular, the present invention relates to the determination of user identity in the context of a transaction. The invention further extends to provision of a targeted offer system based on the determination of the user's identity.

Background

Within a transaction a user (customer) presents their transaction device (e.g. a payment card, payment enabled smartphone, payment enabled smartwatch or other payment device that has been configured to allow the user to make transactions) to a point-of-sale (POS) system operated by a merchant. During the transaction between the cardholder and the merchant, certain payment data related to the transaction and the user is exchanged between the transaction device, merchant's POS system and the merchant's financial institution (the acquirer) and the user's financial institution (the issuer).

Full payment data relating to a given transaction is generally not provided or retained by the POS system. There therefore exists a problem in uniquely associating a given transaction (and by extension the transaction details such as purchased items) to a user. Correspondingly, the financial institution that does have access to full payment data for the user does not have access to complete transaction data relating to the transaction.

Brands, retailers, and financial institutions (offer sponsors) use promotions, discounts, and various other promotional activity (collectively referred to herein as "offers") to incentivize customers to purchase their services and products.

Issuing targeted offers is an important and effective marketing tool. In most simple implementations these kinds of offer systems analyse transaction data and select an offer in accordance to some criteria or a set of rules.

It is desirable for an offer issuing system to store complete transaction data since this would facilitate the selection of targeted offers for a given user by exploiting all available information collected. Furthermore, it would be desirable for an offer issuing system to store a digital representation of historical transaction data.

Offer issuing systems also face a challenge in determining whether a user has satisfied all the conditions attached to a specific offer before that offer is redeemed (for example, an offer for 20% OFF Coca-Cola drink should make sure that a Coca-Cola drink was included in the basket before the 20% OFF is given to the customer).

One way of determining that offer conditions have been satisfied would be to collate complete transaction data and full payment data for each transaction that a user is involved in. This approach is, however, not practical since merchants/retailers do not generally have access to a complete set of payment data for a given transaction (e.g. the merchant will not be able to determine the full transaction device details). Instead, transaction device details are handled by payment providers (the acquirer and issuer institutions noted above) and the merchant's POS system generally only interacts with these payment providers through well-defined Application Programming Interfaces (APIs), where transaction device details are kept away from the software running on the point-of-sale system.

What this means is that a merchant's stored payment data only corresponds to a subset of the full payment data that a payment provider may have. In other words the merchant only has partial transaction device data (typically, the bits of data that clear of any payment card industry (PCI) requirement). As noted above however payment providers, on the other hand, have access to all payment card details, but do not have access to transaction details (e.g. transaction item information).

A number of offer issuing systems are known. One such example is a physical coupon based system in which offers (in the form of physical coupons) are visually inspected during a transaction. This method is prone to errors since it is relatively easy for out of data coupons to be inadvertently used or for irrelevant coupons to be applied to a transaction.

More sophisticated offer issuing systems comprise POS systems that compare decoded coupon barcode data to the transaction log of a given purchase transaction in order to validate the coupon. Usually, in such systems all paper coupons collected by the merchant/retailer are manually sorted and returned to the manufacturers for

reimbursement, which is typically done by a professional clearing house. Such systems however require sophisticated integration of the offer issuing system with existing POS software and infrastructure of a merchant/retailer. It is noted that POS systems are traditionally fairly closed systems with software update cycles of around a year or so.

Statements of Invention

According to a first aspect of the present invention there is provided a method of determining a customer identifier from transaction data generated during a transaction at a point-of-sale system in which the customer has used a transaction device, the transaction at the point-of-sale system generating first and second payment data related to the transaction device and to the transaction, and the transaction device being associated with a customer identifier, the method comprising: receiving transaction data from the point-of-sale system, the received transaction data comprising the first payment data related to the transaction device and the transaction; extracting the first payment data from the transaction data; querying a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated with the customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query; receiving, from the data store, the customer identifier associated with the determined second payment data.

The present invention provides a method of determining a customer identifier (such as a permanent account number of a bank card, a bank customer identifier, an customer's account number or any other identifier that may be linked to a customer/customer's transaction device) from transaction data generated during a transaction. It is noted that during a transaction a range of data will be generated and exchanged between the customer, the merchant and the merchant's and user's banking entities. Transaction data may comprise: payment data generated between the point of sale system and the various banking entities, transaction item data, data/time information, a transaction identifier, merchant details (name, location etc.), transaction totals, transaction device (e.g. banking card) details, loyalty card details etc. Payment data may fall into two general categories: first payment data that is available to the merchant's point of sale system and second payment data that is available to the banking entity associated with the customer. The first payment data may comprise a subset of the second payment data. In other words, the second payment data may comprise all available payment (e.g. full transaction card details) and the first payment data may comprise partial payment data, e.g. last 4 numbers of a bank card, authorisation codes.

According to the method of the first aspect the second payment data is associated with the customer identifier and the method comprises querying a data store that stores the second payment data with the first payment data. In one example, the method may comprise a merchant's point of sale system sending the partial payment data (the first payment data) to the customer's banking entity. The banking entity may then query its own data store (e.g. a database of all its user's transactions) using the first payment data as a query input in order to determine the full payment data (second payment data) and the associated customer identifier. The customer identifier may then be returned to the merchant's point of sale system.

Preferably the method comprises checking the received transaction data for a hashed version of the customer identifier and, in the event that a hashed version of the customer identifier is not present, extracting the first payment data and querying the data store for the customer identifier.

Some banking entities and merchants may configure their payment processing systems such that a version of the desired customer identifier is included in the transaction receipt data. Such a version of the customer identifier would likely comprise a hashed version of the identifier (or some other suitably obscured version of the identifier). Preferably, therefore the method of the first aspect comprises a pre-processing step in which a check is made of the transaction data to determine if a version of the customer identifier is already present.

Preferably, in the event that a hashed version of the customer identifier is present, the method comprises storing the hashed version of the customer identifier and the received transaction data in a data record. For example, the merchant may operate a data storage system for storing customer transaction data records and may store the customer identifier in a data record within the data storage system. In the event that the transaction data comprises a hashed version of the customer identifier the method may still comprise querying the data store (i.e. the banking entity's data store) for confirmation of the customer identifier. The method may then preferably comprise additionally storing the customer identifier received from the database in the data record along with the hashed version of the customer identifier and the transaction data.

Storing both versions (hashed and "clear") of the customer identifier in the data record may conveniently reduce the need to query the data store (e.g. the banking entity's data store or database) in the future.

Preferably the method comprises checking received transaction data relating to a subsequent transaction and storing the further transaction data in the data record. By storing subsequent transaction data a historical transaction record relating to the customer may be created. Transaction data may initially be checked for a hashed identifier that is already present in the data store or the data store may be queried for a "clean" identifier.

The transaction device may be associated with a permanent account number (PAN) identifier and the customer identifier may be the PAN. Alternatively, in the event that a customer has multiple transaction devices with a banking entity (e.g. multiple bank and credit cards) then the customer identifier may be an overall customer identifier that identifies that customer to the banking entity.

The first payment data may comprise either a subset of a permanent account number (PAN) and/or an authorisation code relating to the transaction.

The first payment data may comprise a transaction identifier relating to the transaction at the point-of-sale system, the transaction identifier uniquely identifying that transaction.

According to a second aspect of the present invention there is provided a system for determining a customer identifier from transaction data generated during a transaction at a point-of-sale system in which the customer has used a transaction device, the transaction at the point-of-sale system generating first and second payment data related to the transaction device and to the transaction, and the transaction device being associated with a customer identifier, the system comprising: an input arranged to receive transaction data from the point-of-sale system, the received transaction data comprising the first payment data related to the transaction device and the transaction; a processor arranged to extract the first payment data from the transaction data; and an output arranged to query a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated with the customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query wherein the input is arranged to receive, from the data store, the customer identifier associated with the determined second payment data.

The processor may be arranged to extract first payment data from the transaction data and then generate the query for the output to send to the data store.

The invention extends to a transaction data repository system comprising a system according to the second aspect of the present invention and a data storage system comprising a system according to the second aspect of the present invention.

According to a third aspect of the present invention there is provided a method of operating an offer issuance and redemption system comprising: issuing an offer for use in a transaction for a transaction item, the offer being associated with offer conditions; receiving transaction data from a point-of-sale system, the transaction at the point-of-sale system generating first and second payment data related to a transaction device and to the transaction, and the transaction device being associated with a customer identifier, the received transaction data comprising the first payment data related to the transaction device and the transaction; extracting the first payment data from the transaction data; querying a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated with the customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query receiving, from the data store, the customer identifier associated with the determined second payment data; storing the transaction item in combination with the customer identifier; checking the transaction item against the offer conditions; redeeming the offer if the offer conditions have been met. It is noted that where an offer comprises an offer of the type "20% off of item X" then, upon redemption of the offer, the 20% reduction may be transferred directly to the customer's bank account, because the payment data in the bank is effectively "linked" to a merchant's transaction database through the operation of the first, second and third aspects of the present invention.

The method of operating an offer issuance and redemption system may further comprise activating the offer. The offer may be "hosted" by the banking entity, the merchant or a third party entity.

According to a fourth aspect of the present invention there is provided an offer issuance and redemption system comprising: a processor arranged to generate an offer for use in a transaction for a transaction item, the offer being associated with offer conditions; an output arranged to issue the generated offer; an input arranged to receive transaction data from a point-of-sale system, the transaction at the point-of-sale system generating first and second payment data related to a transaction device and to the transaction, and the transaction device being associated with a customer identifier, the received transaction data comprising the first payment data related to the transaction device and the transaction; wherein the processor is arranged to extract the first payment data from the transaction data; the output is arranged to query a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated with the customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query; the input is arranged to receive, from the data store, the customer identifier associated with the determined second payment data; the processor is arranged to: store the transaction item in combination with the customer identifier; check the transaction item against the offer conditions; redeem the offer if the offer conditions have been met.

The invention extends to a carrier medium for carrying a computer readable code for a server computer to carry out the method of the first or third aspects of the present invention.

The present invention may provide the following advantages over the other systems and methods:

• Allows the association of transaction data and full payment card information by using partial payment card and payment data via the collaboration of a card details holder (banking entity) and a transactions data repository (a database of transaction data. This may be held by the merchant or a third party)

• Enabling of the automatic redemption of offers that the customer is interested in (since transaction data may be supplied "behind the scenes" from the merchant to the banking entity and the customer uniquely identifier and their transaction history reviewed to determine if the conditions of any offer have been met).

• Improves customer experience as coupons are in electronic format, so cannot be damaged or lost, and are automatically managed by the system.

• Allows the issuance of personalized targeted offers by inspecting customer's transaction data history.

• Eliminates fraudulent usage of offers as offers are in electronic format and are associated with customers.

Within the scope of this application it is expressly intended that the various aspects, embodiments, examples and alternatives set out in the preceding paragraphs, in the claims and/or in the following description and drawings, and in particular the individual features thereof, may be taken independently or in any combination. That is, all embodiments and/or features of any embodiment can be combined in any way and/or combination, unless such features are incompatible. The applicant reserves the right to change any originally filed claim or file any new claim accordingly, including the right to amend any originally filed claim to depend from and/or incorporate any feature of any other claim although not originally claimed in that manner.

Brief description of the drawings

In order that the invention may be more readily understood, preferred non-limiting embodiments thereof will now be described with reference to the accompanying drawings, in which:

Figure 1 shows a known point-of-sale (POS) till configuration;

Figure 2 shows an OPOS architecture; Figure 3 shows an overview of a typical payment scheme;

Figure 4 shows a transaction data repository system in accordance with an embodiment of the present invention;

Figure 5 is a flow chart of the process in which an issuing bank (or a system associated with the issuing bank) determines a customer-ID in accordance with an embodiment of the present invention;

Figure 6 is a flow chart of the process by which the transaction data repository system queries an issuing bank for a customer-ID;

Figure 7 shows an embodiment of a transaction data repository and offer processing system in accordance with an embodiment of the present invention;

Figure 8 shows an OPOS architecture in accordance with an embodiment of the present invention;

Figure 9 shows a known filter driver architecture;

Figure 10 shows a filter driver architecture in accordance with an embodiment of the present invention;

Figure 1 1 shows a known API structure; and

Figure 12 shows a filter driver using hooked APIs in accordance with an embodiment of the present invention;

Figures 13a to 13c show further point of sale system arrangements that may be used in conjunction with embodiments of the present invention;

Figure 14 shows a point of sale (POS) system in accordance with an embodiment of the present invention.

Detailed description of the invention Embodiments of the present invention provide a method, system and computer product for determining a user identity. As described below the method and system of the present invention comprise the receiving of transaction data (e.g. digital basket data) and the subsequent identification of the user who has taken part in the transaction. Transaction data is received from a point of sale system and then processed by a transaction repository system.

In accordance with embodiments of the present invention, the transaction data received from the point of sale system comprises only partial payment data or partial derivatives of the payment data and payment related information relating to a transaction device (e.g. a payment card) and transaction, and the user identity is determined from this partial data. The user identity may be determined by querying a financial institution which holds full transaction device data (such entity also being referred to herein as the Card Detail Holder).

Embodiments of the present invention extend to an offer distribution system, and an offer validation system.

In one embodiment, an offer may be issued by the financial institution with access to complete transaction device details. This could be the bank issuer of the transaction device, or a transaction network provider such as Visa, MasterCard, or any other channel facilitated by these entities, where the entity is capable of determining a customer- ID/card PAN. The offer may then be sent to customers. The offer may have a set of conditions tied to it, so that the offer is issued and redeemed only when those conditions are met.

Once distributed to the customer, the customer may activate the offer by either logging into a website run by the Card Detail Holder or any means provided or facilitated by the Card Detail Holder (e.g. application on a smartdevice). Once activated, the offer distribution and validation system may then be used to track whether conditions associated with the offer have been met and then to redeem the offer.

A customer registered (registered user) with systems in accordance with embodiments of the present invention may carry out transactions at merchants as normal. Transaction data (typically containing at least the data printed on the receipt) arising from any transactions that the customer is involved in may be sent to a central transaction data repository system. This central transaction data repository system may include a database hosted by the merchant/retailer or managed by a third party provider. Transaction data received by such a transaction data repository system may only contain partial payment data relating to the transaction device/card and transaction (typically, the partial transaction device data relating to the transaction contains the last four digits of the card used, type/make of the card, and the authorization code of the transaction).

When the registered user logs into his account a call will be made to the central transaction data repository system with the partial payment data only. The repository system (typically through a well-defined set of APIs) uses the partial payment data including available payment related data, such as authorization code, reference id, etc., to fetch the transaction, checks the conditions against the transaction data recorded in the repository, and ascertains whether the offer conditions are met or not. The response is then returned to the offer issuance system which then decides if conditions met to provide the discount to the customers.

Definitions

The following terms may be used in conjunction with the description of embodiments of the present invention.

POS terminal - the "point of sale" terminal is a machine running and processing transactions. For instance, an ordinary retailer till. The POS terminal may be part of a POS system comprising, for example, a barcode scanner device, the POS terminal and a printer device.

Offer - may be a coupon, voucher, advertisement, discount, reward, or any other means to incentivize customers.

Offer Sponsor - may be an entity that manages user incentivisation offers. For example an offer sponsor may be a brand manufacturer, a retailers or a financial institution. Offer matching - is an event relating to the checking of current or historical transaction data against a set of rules that define criteria of offer issuance. If all the rules are satisfied, an offer associated with this set of rules, may be issued.

Validation process - is an event of checking current or historical transaction data against a set of rules that defines criteria of offer redemption. If all the rules are satisfied, and offer associated with this set of rules, may be redeemed/applied.

Card Details Holder (CDH) - relates to a financial institution with the full transaction device (card) data and information about payments made using these cards. The card details holder may be the issuing bank associated with a user/cardholder as described in relation to Figure 4 below.

Transactions Data Repository (TDR) system - a server and associated data store that receives, processes and stores transaction data.

Customer ID - an identifier that corresponds to a user (cardholder). The customer ID may relate to a specific transaction device (payment card) in the event that the user has a single card issued to them from the card details holder. The customer ID may relate to a plurality of transaction devices in the event that the user has more than one transaction device issued to them from the card details holder (e.g. current account card, savings account card, credit card etc.).

In one embodiment, transaction data elements may be defined by the following set TRANSACTION_ELEMENT = {Transaction-ID, Retailer Name, Branch, Store, Geographic Location, Timestamp, Items, Total Net, Total Include Tax, Total per Category, Credit/Debit Card, Partial Payment Data, Loyalty Card, Voucher, Cash, Offer, Advertisement}

where

• Transaction-ID - a globally unique identifier of the transaction

• Retailer ID, Branch, Store, Geographic Location - location related information.

• Timestamp - time stamp of the transaction.

• Items - bought items, a set of tuples of form (Item Identifier, Item Description, Amount, Price).

• Total Net, Total Include Tax, Total per Category (e.g. GM, Food, etc) - Paid amount related information.

• Credit/Debit Card, Loyalty Card, Voucher, Cash - payment type information.

• Partial Payment Data - this includes any information available about the payment card such as card make, masked pan, last 4 digits of the transaction device, expiry, bank identifier, authorization code, or any other related identifiers; the whole set or a sub-set of this information is used as described below to uniquely identify this transaction within a banking institution that processed the payment using the given payment card. This information may also be used to uniquely identify a corresponding transaction data in the Transaction data repository (TDR) system as well. It is noted that the payment. It is noted that the partial Payment Data relates to the transaction device (e.g. the user's bank card) and the transaction (e.g. authorisation code, merchant code).

• Offers - a set of offer served at this transaction.

• Advertisements - a set of advertisement served with this transaction.

Generally, any available information on the receipt or any other data that can be inferred using data on the receipt should be in TRANSACTION_ELEMENT.

Definition. A digital representation of transaction data (Transaction Data) may be an element than belongs to a set of all subsets of elements from the set TRANSACTION_ELEMENT except empty set; that is a set of transactions may be defined as a power set of set TRANSACTION_ELEMENT except empty set:

TRANSACTIONS = P(TRANSACTION_ELEMENT) - 0, here P(X) means power set of X.

Definition. The meta-data of T may be an element from the set

TRANSACTION_META DATA = P(TRANSACTION_METADATA_ELEMENTS) where

TRANSACTION_METADATA_ELEMENTS = { DATA₀(T), DATA^T), DATA₂(T), DATA_N(T) } here DATAi(T) : TRANSACTIONS→ DATA, 0 < i < N, represent functions that give some data relevant to the given transaction T, and DATA denotes any information that may be interpreted by the system.

A set of functions that map transaction T to some elements of TRANSACTION_METADATA may be introduced as:

EN ICH_FU NCTIONS = { F(T): TRANSACTIONS TRANSACTION_M ETADATA }

Turning to the figures, Figure 1 shows a typical POS configuration for a point-of sale system 1 comprising a POS terminal 3, a receipt printer 5, a barcode scanner 7, a data entry device 9 for the entry of PIN codes (the "Pin Pad"), back-office servers 11 and a payment processing server 13. The POS terminal, back-office servers 1 1 and payment processing server 13 are in communication with one another via a network 15 (which may be a local network, the Internet or a mixture of both).

The POS terminal 3 comprises a point of sale application software module 17, which is in communication with a product database 19, and a payment application software module 21.

The point of sale application software module 17 and payment application software module 21 are each in communication with the receipt printer 5 and scanner 7 and with the back-office servers 1 1 and payment processing server 13 via the network 15.

The point of sale application software module 17 is responsible for recording items to be sold one by one, calculating the total balance, triggering any pre-configured promotions, and then accepting multiple payment methods. Typically, items are input in using the scanner 7. Items having barcodes printed on external packaging will be placed in front of the scanner 7 which then scans the barcode and passes the barcode as input to the POS software module 17. The POS software module 17 will then query the local database 19 to retrieve the price of the item which may be displayed on a screen (not shown in Figure 1). Once all items are scanned, the cashier asks the customer to confirm their preferred payment type to use, and if the user chooses to pay by card, the POS software module 17 connects to the payment application software module 21.

The payment application software module 21 drives an external device 9 to get the credit card details and optionally the PIN associated with the card. In cases where a PIN code is not required, the payment application software module may interface with a magnetic strip reader (which may be integrated with the device 9) which reads the card details when the user or cashier swipes the card through the strip reader.

Once the transaction is paid for, the POS application software module 17 formats details of the transaction and sends them to the receipt printer 5. In many cases, two or more receipts are printed: one for the customer, and one of the retailer. It is noted that the retailer copy of the receipt can potentially contain more information than the customer one (for e.g. full card details, while the customer receipt contains only the last 4 digits of the card used).

The payment application software module 21 is responsible for authenticating the card, verifying the PIN, and authorising the card for payment. This is done by accessing the payment processor 13 over the network connection 15. The payment processor 13 may be either hosted inside or outside the premises of the retailer, and in that case it is hosted outside the retailer's premises, the network path from the payment application software module 21 to the payment processor 13 may involve leaving the retailer's local computer network and using the Internet or other communications network (e.g. dedicated communications network or a mobile telecommunications network). The network 15 is also used by the POS application software module 17 to send transaction details to the back-office servers 1 1. An example of a payment scheme is shown in relation to Figure 3, described below.

The POS application software module 17 typically runs on a commodity operating system (e.g. Microsoft Windows or Linux). Each of the devices external to the POS terminal 3 is connected to the machine using standard connectors: Serial, Parallel, USB, or Ethernet ports. To simplify the interoperability between POS software and payment software vendors and external devices vendors, a consortium of companies led by Microsoft, NCR, Epson, and Fujitsu-ICL standardised the interface between each device. These standards are typically implemented in Java or COM technologies, and known under the name of JAVAPOS or OPOS.

It is noted that OPOS is an implementation of an interoperability standard for a Windows® operating system using Component Object Model (COM) technology. OPOS defines a set of control objects that define the interface of each device, and a set of service objects that implement the interface above, in a set of libraries called service objects. Typically, the service object is provided by the hardware provider (e.g. Epson for the printers).

JAVAPOS is the implementation of the standard in JAVA language. It uses the same architecture as OPOS, with a set of JAVA classes defining the interface of the API, and another set of JAVA classes defining the implementation of these interfaces, called service objects. Typically, the manufactures provides the implementation for these service objects in JAVA.

Figure 2 shows a typical layout of the component of OPOS used to interface between a physical device 23 (e.g. the printer 5 or scanner 7 of Figure 1) and the POS application software module 17. The POS application software module 17 is arranged to access the physical device 23 using a standard OPOS application programming interface (API) 30. Communication between the POS application software module 17 and the physical hardware device 23 is handled by an OPOS device 32 (which is actually a software stack within the POS terminal 3).

The OPOS device comprises an OPOS device control module 34 which provides the interface for the POS application software module 17 and an OPOS device service module 36 which provides communication to the device 23.

The OPOS Device Service module 36 implements the details of the physical device 23 and is typically provided by the hardware vendor. For example, to print receipt data, the POS application software module 17 may call the following method:

PrintNormaKlnteger Station, String DataToBePrinted): Prints the data specified in "DataToBePrinted" to the station specified

in parameter "Station". This is guaranteed to work regardless of the

underlying printer attached to the POS terminal 3.

Similar APIs exist for the scanner 7 as well. For example, regardless of the scanner attached to the POS terminal 3, the scanner property called "ScanData" always holds the scanned data. The POS application software module 17 upon receiving a read event from the scanner, can read this data, and it is guaranteed to hold the barcode of the item scanned.

An arrangement mirroring that of Figure 2 may also be used to describe a JAVAPOS system for interfacing a POS software module with a hardware device.

Figure 3 shows an example of a typical payment scheme in which there are two payment providers: the issuing bank (issuer) 101 who issues a transaction device 103 (payment card) to a user 105 (/cardholder/customer); and the acquiring bank 107 (acquirer) who handles financial transactions for a merchant 109. The issuing and acquiring banks communicate via a payment network 11 1.

During a transaction at a merchant 109, the user provides their payment device 103 to the POS system 1 of the merchant. The POS system 1 contacts the acquiring bank 107 of the merchant and then, via a banking platform 11 1 (such as the VISA or MasterCard networks), contacts the issuing bank 101 to authorise the transaction. An authorisation code is generated for the transaction which is then returned to the merchant's POS system 1. At the end of the transaction a receipt 1 12 (traditionally a paper based receipt but optionally or alternatively a digital receipt) is returned to the user.

Figure 4 shows an overview of a transaction system 120 in accordance with an embodiment of the present invention.

Figure 4 shows a merchant's point of sale system 1 which receives a user's transaction device 103 during a transaction. The point of sale system is arranged to process the transaction device via the general method described in relation to Figure 3. Also shown in Figure 4 is the issuing bank 101 of the user. The issuing bank is responsible for issuing transaction devices 103 to users. Each user registered with the issuing bank will be allocated a unique user identifier (also referred to herein as the customer ID or customer identifier), the unique user identifier being associated with each transaction device that the issuing bank has issued to that user. It is therefore noted that the issuing bank is in possession of full transaction device data (e.g. the full primary account number (PAN) for each transaction device, the card security code associated with each transaction device and associated user data such as name, address etc.).

Also shown in Figure 4 is a transaction data repository system 122 comprising a transaction data server 124 and a transaction data store 126. The transaction data repository system 122 is arranged to collect/receive transaction data from the POS system 1 and additionally is in communication with the issuing bank 105.

The transaction data received from the POS system may comprise some or all of the data referred to in the transaction data elements set defined above

(TRANSACTION_ELEMENT). In particular, the transaction data received from the POS system may comprise partial payment data relating to the transaction device and transaction, e.g. masked PAN, last 4 digits of PAN only, authorisation code, card type etc.

The transaction data received from the POS system may conveniently be stored in the data store 126.

Figure 5 shows the process in which the issuing bank (or a system associated with the issuing bank) determines a customer-ID.

In step 130 the issuing bank receives partial payment data relating to the transaction device and transaction. In step 132 the issuing bank checks the partial payment data against all its customer records to identify the customer who took part in the transaction. In step 134 the customer-ID relating to the customer identified in step 132 is retrieved.

In certain embodiments of the present invention the identification of the customer-ID from the available partial payment data may be initiated at the issuing bank in order to provide further services, e.g. offer issuance system, to users of the system. In such embodiments the issuing bank may use the customer-ID within its own internal systems. Furthermore, in such embodiments Figure 5 may comprise an additional processing step prior to step A. In such a step 136 the issuing bank may request partial payment data from the transaction data repository.

In other embodiments of the present invention, the customer-ID may have been requested by the transaction data repository system. In such other embodiments Figure 5 may comprise an additional processing step 138 after step 134. In such a step D, the issuing bank may send the customer-ID to the transaction data repository system for further use, e.g. in linking transaction data to customer-ID and/or in the provision of additional services, such as an offer issuance system.

In further embodiments of the present invention, the issuing bank may provide customer- ID and full payment data to a Customers database (see Figure 7) which may then be queried either by the issuing bank 101 or the transaction data repository system in accordance with the embodiments described above.

Figure 6 shows an embodiment of the present invention in which the transaction data repository system queries the issuing bank for a customer-ID (i.e. an embodiment where Figure 5 comprises a step D).

In step 140 the transaction data repository system receives transaction data from the POS system. The transaction data comprises partial payment data relating to the transaction device and transaction.

In step 142 the transaction data repository system extracts the partial payment data from the transaction data

In step 144 the transaction data repository system sends the partial payment data to the issuing bank (the card details holder) and requests that the issuing bank returns a customer-ID relating to the partial payment data.

In step 146 the transaction data repository system receives the customer-ID from the issuing bank. In step 148 the transaction data repository system associates the transaction data received in Step 140 with the customer-ID. In the event that the transaction data repository system already has a data record for the customer-ID received in Step 146 then the transaction data may be added to the existing data record.

A specific embodiment of a user identity and offer issuance and redemption system in accordance with embodiments of the present invention is described in relation to Figure 7.

The reader should appreciate that the location of the various components described below in relation to Figure 7 may be varied within the scope of the present invention.

For example, the user interface may interact with the offer databases (212, 218, 220) and the card detail holders server but may equally be arranged to interact with the offer databases and the transactions data repository system.

Additionally the Customers database may be associated with the card details holder system or may be part of the transactions data repository system and may be supplied with data from the card details holder systems.

Yet further, the various offers databases and components, the payment information extractor component, the customer mapper component and the various redemption components may be part of the transactions data repository server 122, may be part of the card details holder systems 101 or may be a separate system that is in communication with these two systems.

Figure 7 shows the following components:

• The Offers Creator module 200 is a component that is used by an entity who wishes to create offers. An offer is delivered to a customer if a set of rules or criteria (issuance conditions) are met. In the event that there are no issuance conditions set, an offer would be delivered to all the customers. Example of issuance conditions: Some items may need to be bought, or some quantity of items may need to be bought, or some amount of money should be spent and so on. In one embodiment these offers may target a specific customer. An offer may also be associated with a set of redemption conditions, which are used to check if an offer can be redeemed.

The Transactions Data Repository system 122 (it is noted that for clarity Figure 7 only shows the database element 126 of the transactions data repository system) stores digital representations of transaction data received from the point of sale system. Such transaction data may comprise the transaction data elements "TRANSACTIONS_ELEMENT) as defined above.

The Payment Information Extractor module 202 takes transaction T and returns Payment Data (PD). This component uses AC(T) e ENRICH_FUNCTIONS. Function

AC(T) for the given transaction T returns Payment Data. It is noted that the Payment Data (PD) comprises partial payment data relating to the transaction device and the transaction.

The Customer Mapper module 204 takes as argument Payment Data (as determined by the Payment Information Extractor module) and returns a customer ID. The Customer Mapper module accesses a data store "Customers" that is populated by the Card Details Holder (i.e. by the issuing bank).

The Customers data store 206 stores tuples (P, C) populated by the Card Details Holder 101 , where C is a customer-ID, and P is Full Payment Data (It is noted that the Card Details Holder, as the entity that has issued transaction devices to customers, has access to the customer's details, manages full payment card details, and knows about payments performed by the payment cards, so it can populate this data store).

The Offers Distributor module 208 takes an offer A, created by using the Offers Creator module, and for every transaction T within the Transactions Data Repository system 122 extracts Payments Information (partial payment data) from T using the Payment Information Extractor module; then, using Payment Data as argument to Customers Mapper it gets customer-ID C; next, it sends T and A to Offers Matcher.

The Offers Matcher module 210 takes as argument a tuple (A, T), where A is an offer, and T is a transaction, and returns TRUE if transaction T satisfies issuance conditions of offer A, or FALSE otherwise. Offers Matcher indicates if (A, T), which were received from the Offers Distribution module, match. If so, it stores a tuple (A, T, C) in Pending Offers.

The Pending Offers component 212 is a data store that stores tuples (A, T, C). It is populated by the Offers Matcher module. Here A is an offer, T is a transaction data, and C is a customer-ID.

The User Interface component 214 is used by customers to manage their offers: activate pending offers, reject, or review redemptions history. The user interface component may be arranged to communicate with a number of the above modules and entities depending on the configuration of the system. The user interface may be arranged to communication with the Card Details Holder 101 (as shown in Figure 4) (or in an alternative with the Transactions Data Repository System 122 as noted above), the Pending Offers component, an Activated Offers component (as described below), a Redeemed Offers component (as described below). An offer A for customer C may considered "Activated" if a tuple (A, T, C) from the Pending Offers data store is removed, and a tuple (A, C) may be created in the Activated Offers data store. Offer A for customer C may be considered redeemed if a tuple (A, T, C) is in the Redeemed Offers component.

The Offers Redeemer module 214 extracts Payment Data for every transaction T in the Transactions Data Repository using the Payment Information Extractor module; then, using Payment Data as argument to Customers Mapper it gets customer ID C; Next, using C it takes a list of activated offers from the Activated Offers component and for every such offer A it calls the Redemption Validator module with a tuple (A, T). If the returned result is TRUE, it puts a tuple (A, T, C) into the Redeemed Offers data store, and removes the tuple (A, C) from the Activated Offers data store.

The Redemption Validator module 216 takes as argument a tuple (A, T), where A is an offer, and T is a transaction, and returns TRUE if transaction T satisfies redemption conditions of offer A, or FALSE otherwise.

The Activated Offers component 218 is a data store that holds tuples (A, C) where A is an offer, and C is a customer ID.

The Redeemed Offers component 220 is a data store that holds tuples (A, T, C) where A is an offer, T is a transaction, and C is a customer ID.

• The Card Details Holder (CDH) 101 represents the issuing bank and is a component that manages full cards details, payments information, and customers.

• Full Card Details 222 is a data store that contains full information about payment cards. This is managed by CDH.

• Payments 224 is a data store that contains information about payments performed by payment cards managed by CDH. It is noted that within the context of the present application the full card details data store 222 and payments data store 224 may be represented by, or be part of, a single data storage system 226.

A typical use scenario may be as follows:

An entity may use the Offer Creator module to create an offer A. The offer, for example, may be "20% OFF Y". Its issuance rules may be: If a customer buys Y, issue the offer. Its redemption rules may be: If a customer buys Y, validation is successful. The incentive provided by the Offer may be: Give 20% discount for item Y. The entity providing the offer may then publish the offer A to the Offers Distributor module.

Subsequently, a customer may complete a transaction at a merchant and pays by credit card at a POS system. The POS system may send all transaction data T₀ to the Transactions Data Repository system. The Transaction data T₀ may include item Y.

At some point (e.g. periodically or in response to a request to identify customers from stored transaction data) the Offers Distributor module may retrieve transaction T₀ from Transactions Data Repository system. The Payment Information Extractor module may then retrieve/extract Payment Data (i.e. the partial payment data described above) from T₀, and, using the Customers Mapper module the customer-ID, C, may be retrieved. A tuple (A, T) may then be sent to the Offers Matcher module, which returns TRUE, because T₀ includes Y and thus satisfies issuance condition of offer A. A tuple (A, T₀, C) is stored in the Pending Offers data store. The customer may then logs into their account using the User Interface. The Ul may retrieve pending offer A from the Pending Offers data store by using C. The customer may then activate offer A by removing tuple (A, T₀, C) from the Pending Offers data store and creating tuple (A, C) in the Activated Offers data store.

Subsequently, the Offers Redeemer module retrieves subsequent transaction Ti from the Transactions Data Repository system. The Payment Information Extractor module may then extract Payment Data (partial payment data) from Ti , and, the Customers Mapper module may retrieve customer-ID C. The offers redeemer module may then check the Activated Offers data store, the activated offers data store containing tuple (A, C). The offer redeemer module may then call the Redemption Validator module with a tuple (A, Ti). Since Ti includes Y, validation succeeds, that is it returns TRUE. So, the Offers Redeemer module creates a tuple (A, T1 , C) in the Redeemed Offers data store and remove tuple (A, C) from the Activated Offers data store.

Finally, the entity that created the offer may query the Redeemed Offers data store and finds that there is a tuple (A, Ti , C), meaning that customer C should receive its reward. The entity sponsoring the offer may then reward customer C appropriately, i.e. by transferring 20% of Y to the account of customer C.

To access the stream of data sent by the POS application software module 17 requires a change in the application so that appropriate code can be added in order to access the data. The data once accessed may be sent to the transaction data repository system 122.

Figures 8 to 14 shows a POS system suitable for use with embodiments of the present invention. It is noted that like numerals are used to denote like features throughout the claim set. Within the context of the following description it is noted that the computing device 44 may represent the transaction data repository system 122 described in relation to Figure 4 above.

The architecture depicted in Figure 8 is similar to the known OPOS architecture of Figure 2. The OPOS device 32 however now additionally comprises a virtual physical driver software module 40 that is located between the OPOS device control module 34 and the OPOS device service module 36. The inclusion of the driver software module 40 enables data communications to and from the POS application software module 17 or payment application software module 21 to the physical device 23 to be monitored and intercepted. The driver software module 40 also enables data communications that originate from outside the POS system 1 to be inserted into the OPOS device 32 and routed to either the physical device 23 or the POS application 17/payment application 21 software modules. In this manner information relating to transactions can be extracted from the POS system 1 and additional information can be added into the communication path between the POS terminal 3 and physical devices (5, 7).

In more detail the virtual driver software module 40 may be installed and operated as follows:

In an installation step the virtual physical driver software module 40 may be installed onto the POS terminal 3 such that it sits between the OPOS device control software module 34 and the OPOS device service software module 36.

In a first operational step, each command passed through from either the POS application software module 17 or the payment application software module 21 to the physical device 23 may be monitored and passed to a data stream parser module 42.

In a second operational step, the data stream parser module 42 may parse the data to create a list of transaction items; total amount spent; details of any promotions; cashier name or id; and/or any other data of interest. The data stream parser 42 may be achieved using a regular expression parser. The stream parser 42 may also parse the details of the cards used (either partial details, such as last 4 card digits and expiry date, or complete details if available). It is noted that since the payment application software module 21 uses the stack OPOS device 32, the virtual physical driver module 40 may also intercept any extra information used when printing the retailer receipt (in case the retailer receipt contains full card details).

In a third operational step the virtual physical driver module 40 may pass the card and transaction data derived in the second step above to a computing device 44. The computing device 44 may comprise a module associated with the POS system 1 , a separate local computing device or a remotely located device. In a fourth operational step the computing device 44 may return modified data to the virtual physical driver module 40 which can then be supplied via the OPOS device service software module 36 to the physical device 23. In the example where the physical device 23 is the receipt printer 5 this allows the modified data (or a part or representation thereof) to be printed onto the customer's receipt.

In one example the computing device 44 may be an offer engine and depending on rules pre-set within the offer engine (e.g. to serve an offer to any customer who spent more than £20), the offer engine may generate an offer and pass it to the virtual physical driver module 40 for printing. Once the standard receipt data (e.g. store details, transaction items, transaction details etc.) has been printed, the virtual physical driver module 40 may print the offer received above to the POS system's receipt printer 5.

The virtual physical driver module 40 described above allows existing POS hardware to be used without any alterations to achieve the following:

• Intercept transaction details without needing to modify the POS application software module 17;

• Provide information from a computing device 44 to a customer using existing hardware (i.e. the receipt printer 5);

• Associate transaction details with card details to thereby enable a loyalty scheme to be operated without any sign-up or loyalty cards to be used.

It is also noted that a POS terminal software module (either POS application software module 17 or Payment application software module 21) may in certain circumstances communicate directly with a physical hardware device rather than using an OPOS or JAVAPOS interface. Two alternative arrangements are therefore envisaged: (i) the software module (17, 21) may use ESC/POS (a command language used to drive receipt printers) or a similar language to directly to write to a serial port on the hardware device or to a USB device, or (ii) the software module may use a high-level printing API (for e.g. Windows printing architecture) and send rasterised data to the connected hardware device.

In arrangement (i) above, the data sent to the printer is a digital copy of the receipt and can be parsed as text. In arrangement (ii) above, the data sent to the printer is binary, and a parsing program would not be able to readily recover the details of the transactions.

In arrangement (i), the virtual driver software module 40 may be implemented as a filter driver as shown in Figures 9 and 10. Figure 10 shows a known POS terminal environment prior to modification in accordance with an embodiment of the present invention comprising a user space 500 and a kernel space 502 in which an application 17, 21 may read and write data to a physical device (5, 7) via a device driver 504 and upper (506) and lower (508) filter drivers.

It is noted that filter drivers are Microsoft Windows drivers that add value to peripheral devices or support specialized devices in a computing device. A filter driver is a driver/program/module that is inserted into an existing driver stack to perform some specific function. A filter driver should not affect the normal working of the existing driver stack in any major way. Written either by Microsoft® or the vendor of the hardware, any number of filter drivers can be added to Windows®. Upper level filter drivers sit above the primary driver for the device (the function driver), while lower level filter drivers sit below the function driver and above the bus driver.

Filters may work on a certain brand of device such as a mouse or keyboard, or they may perform some operation on a class of devices, such as any mouse or any keyboard. Another type of filter driver is the bus filter driver, which may be added on top of the bus driver. For example, an ACPI bus filter is added to support power management for each device.

Turning to Figure 10, an embodiment of the present invention is shown in which it can be seen that the virtual device software module 40 may be implemented as a filter driver either below the upper filter driver 506 or below the lower filter driver 508.

In arrangement (ii), the virtual driver may be implemented as a library that hooks the original API provided by the operating system with its own API hook. The virtual driver 40 may then transfer the API calls to the original library 520 provided by the operating system as shown in Figures 11 and 12.

Most OPOS or JAVAPOS service objects end up communicating with the hardware using the hardware driver installed in the OS. In this case, the virtual driver software module 40 may beneficially be installed as a filter driver and in the JAVPOS or OPOS layer. The reason is that changing the drivers stack to add a filter driver may be easier than changing the configurations of JAVAPOS and OPOS layers to accept an extra virtual device in the stack.

Further POS system arrangements that may be used in conjunction with embodiments of the present invention are shown in Figures 13a, 13b and 13c. Figure 13a shows a scanner arrangement on a known system such as that shown in Figure 1. A point of sale application (17, 21) located in the user mode of the POS terminal 3 is in communication with a scanner support library 50 (also in the user mode). This library in turn is in communication with a scanner driver 52 and the canner hardware 7.

In Figure 13b the virtual drive 40 described above is shown. Figure 13c shows the arrangement for the printer hardware 5 and the arrangement comprises a printer support library 54 and printer USB driver 56.

Figures 13b and 13c also show an interceptor module and router module which are explained in more detail below.

Figure 14 shows a point-of-sale system in accordance with an embodiment of the present invention. Like reference numerals with the system of Figure 8 are used to denote like features. It is noted that the arrangement of Figure 14 additionally comprises a computing device 44 having an input 60 for receiving scanning and printing data from the POS terminal 3 and an output 62 for sending modified printing and scanning data to the POS terminal 3.

The computing device 44 further comprises a processor 64 arranged, amongst other things, to determine the presence of voucher or loyalty card data within the scanned data stream, to convert said data into a format compatible with the POS terminal and to manage the status of issued voucher codes. The computing device may be in communication with or comprise a data store 66 for storing transaction related data. The computing device 44 may also comprise the functionality of the transaction data repository server 124.

As explained above, the virtual driver module 40 may be used to issue coupons and vouchers with a barcode printed on them. In cases where retailers want to check that each bar code is valid and also has not been used before, the computing device 44 as shown in Figure 14 may be applied to data received from the scanner 7 so that coupons and vouchers may be validated.

The computing device 44 of Figure 14 may also be applied to voucher data received from the scanner where the voucher was created by a third party, i.e. where the voucher has not previously been printed by the printer 5.

The driver software module (40) described above is a filter device driver that installs itself between the software module (17, 21) within the POS terminal 3 and the physical device 23, i.e. between the POS terminal 3 and the scanner 7 and between the POS terminal 3 and the printer 5. Data flowing within the POS system is then intercepted and sent to the computing device 44.

Claims

1. A method of determining a customer identifier from transaction data generated during a transaction at a point-of-sale system in which the customer has used a transaction device, the transaction at the point-of-sale system generating first and second payment data related to the transaction device and to the transaction, and the transaction device being associated with a customer identifier, the method comprising: receiving transaction data from the point-of-sale system, the received transaction data comprising the first payment data related to the transaction device and the transaction;

extracting the first payment data from the transaction data;

querying a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated with the customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query;

receiving, from the data store, the customer identifier associated with the determined second payment data.

2. A method of determining a customer identifier as claimed in Claim 1 , comprising checking the received transaction data for a hashed version of the customer identifier and, in the event that a hashed version of the customer identifier is not present, extracting the first payment data and querying the data store for the customer identifier.

3. A method of determining a customer identifier as claimed in Claim 2, wherein, in the event that a hashed version of the customer identifier is present, the method comprises storing the hashed version of the customer identifier and the received transaction data in a data record.

4. A method of determining a customer identifier as claimed in Claim 3, comprising additionally storing the customer identifier received from the database along with the hashed version of the customer identifier and the transaction data.

5. A method of determining a customer identifier as claimed in Claim 4, comprising checking received transaction data relating to a subsequent transaction and storing the further transaction data in the data record.

6. A method of determining a customer identifier as claimed in any preceding claim, wherein the transaction device is associated with a permanent account number (PAN) identifier and wherein the customer identifier is the PAN.

7. A method of determining a customer identifier as claimed in any preceding claim, wherein the first payment data comprises either a subset of a permanent account number (PAN) and/or an authorisation code relating to the transaction.

8. A method of determining a customer identifier as claimed in any preceding claim where the first payment data comprises a transaction identifier relating to the transaction at the point-of-sale system, the transaction identifier uniquely identifying that transaction.

9. A system for determining a customer identifier from transaction data generated during a transaction at a point-of-sale system in which the customer has used a transaction device, the transaction at the point-of-sale system generating first and second payment data related to the transaction device and to the transaction, and the transaction device being associated with a customer identifier, the system comprising: an input arranged to receive transaction data from the point-of-sale system, the received transaction data comprising the first payment data related to the transaction device and the transaction;

a processor arranged to extract the first payment data from the transaction data; and an output arranged to query a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated with the customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query

wherein the input is arranged to receive, from the data store, the customer identifier associated with the determined second payment data.

10. A transaction data repository system comprising a system as claimed in Claim 9.

1 1. A data storage system comprising a system as claimed in Claim 9.

12. A method of operating an offer issuance and redemption system comprising: issuing an offer for use in a transaction for a transaction item, the offer being associated with offer conditions;

receiving transaction data from a point-of-sale system, the transaction at the point-of-sale system generating first and second payment data related to a transaction device and to the transaction, and the transaction device being associated with a customer identifier, the received transaction data comprising the first payment data related to the transaction device and the transaction;

extracting the first payment data from the transaction data;

querying a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated with the customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query

receiving, from the data store, the customer identifier associated with the determined second payment data;

storing the transaction item in combination with the customer identifier;

checking the transaction item against the offer conditions;

redeeming the offer if the offer conditions have been met.

13. A method of operating an offer issuance and redemption system as claimed in Claim 12, further comprise activating the offer.

14. An offer issuance and redemption system comprising:

a processor arranged to generate an offer for use in a transaction for a transaction item, the offer being associated with offer conditions;

an output arranged to issue the generated offer;

an input arranged to receive transaction data from a point-of-sale system, the transaction at the point-of-sale system generating first and second payment data related to a transaction device and to the transaction, and the transaction device being associated with a customer identifier, the received transaction data comprising the first payment data related to the transaction device and the transaction;

wherein

the processor is arranged to extract the first payment data from the transaction data;

the output is arranged to query a data store using the extracted first payment data, the data store comprising the second payment data, the second payment data being associated with the customer identifier, wherein the data store is arranged to determine the second payment data from the first payment data incorporated in the data store query

the input is arranged to receive, from the data store, the customer identifier associated with the determined second payment data;

the processor is arranged to: store the transaction item in combination with the customer identifier; check the transaction item against the offer conditions; redeem the offer if the offer conditions have been met.

15. A carrier medium for carrying a computer readable code for a server computer to carry out the method of any one of Claims 1 to 8 or 12 to 13.