WO2015019115A1

WO2015019115A1 - Offer issuing system and method

Info

Publication number: WO2015019115A1
Application number: PCT/GB2014/052449
Authority: WO
Inventors: Yosuke OZAWA; Roman VALIUSENKO; Hassan Hajji
Original assignee: Ecrebo Limited
Priority date: 2013-08-09
Filing date: 2014-08-11
Publication date: 2015-02-12
Also published as: GB201314345D0

Abstract

A computing system for issuing transaction vouchers, the system comprising: an input arranged to: receive a transaction voucher from a voucher entity, the transaction voucher being associated with a set of data types, each data type having an issuance parameter to be met; receive transaction data, the transaction data comprising data related to a user transaction;a processor arranged to assess each issuance parameter of the transaction voucher against the received transaction data to determine if the issuance parameter is satisfied and, in response to there being any issuance parameters that have no transaction data to be assessed against, to retrieve further user related data and to asses each remaining issuance parameter against the further user related data to determine if each remaining issuance parameter is satisfied; flag the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied; an output arranged to output the matched transaction voucher.

Description

OFFER ISSUING SYSTEM AND METHOD

Technical Field The present invention relates to an offer issuing system and method. In particular, the present invention relates to a system in which offers may be uploaded to the system and then compared against transaction data and transaction related data in order to determine offers that may be available. Background to the Invention

The present invention relates to a system that may issue offers to users who have engaged in a transaction at a point-of-sale (POS). The issuing of targeted offers, such as coupons and vouchers, at POS systems is an important and effective marketing tool.

In many such systems transaction data relating to a given transaction is analysed and an offer is issued in accordance with pre-set criteria. However, the issuing of offers without knowledge of the user (i.e. the customer making a transaction at a point of sale) involved in the transaction may result in offers being issued that are not particularly relevant to the user in question.

US20040059708 discloses a system that is enabled to deliver targeted advertisements by identifying targeting information for an advertisement and then analysing a target document to identify a list of topics that are compared to the targeting information for a match and determining that an advertisement is relevant if there is a match between the targeting information and the list of topics. Such a system does not take into account the user of the system.

US6269361 discloses a method of influencing the position of a search result based on a bidding process between different information providers.

US20080154765 discloses a method of posting and redeeming offers in which a bidding process is used to place the discount offers. It is noted that the offers in this system are not linked to a user's transactions. It is an object of the present invention to provide an offer issuing system that overcomes or substantially mitigates the above mentioned problems.

Summary of the Invention

According to a first aspect of the present invention there is provided a computing system for issuing transaction vouchers, the system comprising: an input arranged to receive a transaction voucher from a voucher entity, the transaction voucher being associated with a set of data types, each data type having an issuance parameter to be met; receive transaction data, the transaction data comprising data related to a user transaction; a processor arranged to assess each issuance parameter of the transaction voucher against the received transaction data to determine if the issuance parameter is satisfied and, in response to there being any issuance parameters that have no transaction data to be assessed against, to retrieve further user related data and to asses each remaining issuance parameter against the further user related data to determine if each remaining issuance parameter is satisfied; flag the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied; an output arranged to output the matched transaction voucher. The present invention comprises a computer system (e.g. an offer issuance system comprising a processor having a matching module) that is arranged to issue transaction vouchers based on a user's transaction data and, if required, further user related data (such as the user's historical transactions, the user's location, the user's social connections, transaction data related to the user's social connections etc.). The transaction data and if required user related data is matched against transaction voucher issuance parameters.

Matched transaction vouchers may be selected by employing a bidding process which takes into account offer related information such as offer budget and redemption rate etc. Transaction vouchers (e.g. offers) may be delivered to a user's account and may be associated with specific customer;

The present invention may allow the issuance of transaction vouchers or offers (coupons/voucher/advertisements etc) by analyzing digital representations of transaction data. The digital representation of transaction may be a set of elements such as elements that give location information like store name or branch id, address, elements that give information about bought items such as item name, item identifier, amount and price, payment information such as credit or debit card, voucher or cash, and all other transaction related information. In addition to that, digital representation of transaction data may convey all other transaction or customer related information, such as history of all transactions of the given customer, social connections of the given customer and so on.

The output may be arranged to output the transaction voucher to the user. Alternatively, the user may access the computer system to retrieve the transaction voucher. Conveniently, transaction data may be received from a point of sale system and the output may be arranged to output the transaction voucher to the point of sale system for inclusion in a transaction receipt.

The transaction data may be received from a point of sale system and the output may be arranged to output the transaction voucher to the point of sale system for use in the user transaction.

The issuance parameters associated with the set of data types may comprise a set of Boolean conditions.

The transaction data may relate to a transaction at a point of sale system and the further user related data may comprise transaction metadata received from a further system. The further system may be a user location system and the further user related data may comprise user location data.

The further system may comprise a historical transaction system and the further user related data may comprise data relating to historical transactions of the user.

The further system may comprise a social network system and the further user related data may comprise transaction data relating to further users associated with the user.

The input may be arranged to receive a plurality of transaction vouchers, each voucher being associated with a set of data types, each data type having an issuance parameter to be met, and, for each of the plurality of transaction vouchers, the processor may be arranged to assess each issuance parameter against the received transaction data to determine if the issuance parameter is satisfied and, in response to there being any issuance parameters that have no transaction data to be assessed against, to retrieve further user related data and to asses each remaining issuance parameter against the further user related data to determine if each remaining issuance parameter is satisfied; flag the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied and wherein the output may be arranged to output each matched transaction voucher.

Each matched transaction voucher may be output to a transaction voucher selection module. In the event that there are two or more matched transaction vouchers, the transaction voucher selection module may be arranged to select one transaction voucher according to a predetermined criteria. The transaction voucher selection module may be arranged to select the one transaction voucher in accordance with the issuance parameters of the two or more matched transaction vouchers. The transaction voucher selection module may be arranged to hold an auction between the two or more matched transaction vouchers.

Transaction vouchers may be selected on the basis of an auction and set of offer conditions (predetermined criteria). Such conditions may comprise maximum bid amount, which means that maximum amount of money a retailer is willing to pay to win the auction, and a budget, which is maximum amount of money a retailer will spend on this campaign. The auction may be run using an auction process module within the processor of the computer system according to the present invention.

When a digital representation of transaction data is coming through the system according to the present invention, the system may collect all available information (meta-data) that is available for the given transaction, such as customer ID, social graph of the customer, history of all previous transactions and so on. Next, the transaction along with transaction meta-data may be given to the system according to the present invention (the offer issuance system) that may determine which bids will participate in the auction by looking at their bid conditions. Then, an auction may be run, through which a set of winner offer bids may be selected, and, finally, the offers associated with the winner bids may be delivered to the user.

According to a second aspect of the present invention there is provided a computing system for issuing transaction vouchers, the system comprising: an input arranged to receive a transaction voucher from a voucher entity, the transaction voucher being associated with a set of data types, each data type having an issuance parameter to be met; receive transaction data, the transaction data comprising data related to a user transaction; receive further user related data; a processor arranged to assess each issuance parameter of the transaction voucher against the received transaction data and the further user related data to determine if the issuance parameter is satisfied; flag the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied; an output arranged to output the matched transaction voucher.

According to a third aspect of the present invention there is provided a method for issuing transaction vouchers, the method comprising: receiving a transaction voucher from a voucher entity, the transaction voucher being associated with a set of data types, each data type having an issuance parameter to be met; receiving transaction data, the transaction data comprising data related to a user transaction; assessing each issuance parameter of the transaction voucher against the received transaction data to determine if the issuance parameter is satisfied and, in response to there being any issuance parameters that have no transaction data to be assessed against, retrieving further user related data and to asses each remaining issuance parameter against the further user related data to determine if each remaining issuance parameter is satisfied; flagging the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied; outputting the matched transaction voucher. According to a fourth aspect of the present invention there is provided a method for issuing transaction vouchers comprising: receiving a transaction voucher from a voucher entity, the transaction voucher being associated with a set of data types, each data type having an issuance parameter to be met; receiving transaction data, the transaction data comprising data related to a user transaction; receiving further user related data;

assessing each issuance parameter of the transaction voucher against the received transaction data and the further user related data to determine if the issuance parameter is satisfied; flagging the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied; outputting the matched transaction voucher. It will be appreciated that preferred and/or optional features of the first aspect of the invention may be provided in the second to fourth aspects of the invention also, either alone or in appropriate combinations. The invention extends to a carrier medium for carrying a computer readable code for controlling a computer or POS terminal to carry out the method of the third and fourth aspects of the invention.

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 OPOS architecture in accordance with an embodiment of the present invention;

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

Figure 6 shows a known API structure; and

Figure 7 shows a filter driver using hooked APIs in accordance with an embodiment of the present invention; Figures 8a to 8c show further point of sale system arrangements that may be used in conjunction with embodiments of the present invention; Figure 9 shows a point of sale (POS) system in accordance with an embodiment of the present invention;

Figure 10 shows an overview of an offer issuance system in accordance with embodiments of the present invention;

Figure 1 1 shows the components of an offer issuance system in accordance with embodiments of the present invention;

Figure 12 shows a method of issuing offers in accordance with embodiments of the present invention;

Figure 13 shows a social graph network in accordance with embodiments of the present invention. Detailed description of the invention

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 the 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.

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.

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.

Figure 3 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.

The architecture depicted in Figure 3 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. (It is noted that the computing device 44 is also referred to herein as a "transaction computing 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 4 and 5. Figure 5 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 5, an example useful for understanding 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 6 and 7.

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 8a, 8b and 8c. Figure 8a 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 8 the virtual drive 40 described above is shown. Figure 8c shows the arrangement for the printer hardware 5 and the arrangement comprises a printer support library 54 and printer USB driver 56.

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

Figure 9 shows a point-of-sale system in accordance with an embodiment of the present invention. Like reference numerals with the system of Figure 3 are used to denote like features. It is noted that the arrangement of Figure 9 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.

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 9 may be applied to data received from the scanner 7 so that coupons and vouchers may be validated.

The computing device 44 of Figure 9 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. Embodiments of the present invention provide a means for issuing offers, in the form of coupons, vouchers and advertisements, based on a combination of transaction data (in a transaction that a user has made), transaction meta-data and offer conditions (set up by the party providing the offer). In embodiments of the invention described below the offer conditions may be satisfied by means of an auction or bidding system.

An offer issuance arrangement 200 according to embodiments of the present invention is shown in Figure 10 in which the system comprises a digital receipt system 202 which is in communication with an offer issuance system 204 and a redemption system 206.

It is noted that the digital receipt system 202 may comprise the point-of-sale system according to Figure 9 and the offer issuance system 204 of Figure 10 may comprise the computing device 44 from Figure 9. In such an arrangement the filter device 40 may send transaction data to the computing device 44 (the offer issuance system) for processing as described below.

In another embodiment of the present invention the offer issuance system 204 may receive transaction data from another source. For example, a transaction "clearing house" may receive transaction data from a number of retailers or retailer networks and such data may be opened up to the offer issuance system such that offers may be applied to the transaction data that is received.

The offer issuance system 204 is shown in greater detail in Figure 1 1. The offer issuance system comprises four main components: a matching engine module 208 that is arranged to receive transaction data and offer data and to determine offers that match the information contained within the received transaction data; an offer manager module (bid manager module) 210 that is arranged to receive offers from any party wishing to provide an offer; an enricher module 212 that is arranged to process received transaction data and to generate an enhanced set of transaction data comprising the originally received transaction data and additionally meta-data relating to the user or the transaction; and an auction process module 214 that is arranged to determine a winning offer in the event that there are multiple matching offers returned from the offer manager module. It is noted that the matching engine module 208, bid manager module 210, enricher module 212 and auction process module 214 may be contained within a processor of the offer issuance system 204. In more detail, it is noted that within the offer issuance system 204 of Figure 10 third parties may upload or otherwise input offers via the Bid manager module 210. Each offer that is input will be associated with an offer (or bid) condition that will be used to determine if that offer should be used or selected against a particular set of transaction data.

The offers that are input via the bid manager module 210 result in a set of offers (bids) being held within the offer issuance system 204. The bid manager module 210 in addition to allowing the creation of new offers is also arranged to allow the updating and removal of existing offers from the system. The bid manager is arranged to maintain a history of previous offer issuances. Within the context of an auction system the bid manager module is arranged to maintain data on latest winning amounts of money, that is, how much was paid to win the last auction (or few last auctions). A third party uploading or managing offers within the system may also specify, via the bid manager module, a period of time (e.g. a day, a week, etc.) that an offer may be valid as well as other offer/bid conditions, maximum bids for offers and also budgets to be allocated to given offers for a given period.

The matching engine module 208 is arranged to take as inputs; details relating to the complete set of offers held by the bid manager module 210; digital transaction data relating to the transaction that a user makes (e.g. at a POS system as shown in Figure 9); and transaction meta-data received via the enricher module (as described below). The matching engine module 208 is arranged to process these inputs and return a subset of offers that should be further processed, e.g. a subset of offers that should be passed into an auction system. The matching engine module is arranged to select those offers only for which the offer conditions associated with the offer in question evaluate to TRUE based on the input transaction data and transaction meta-data.

The subset of offers that are returned by the matching engine module 208 may be sent to an auction process module 214 that is arranged to select a winning offer from within the subset of returned offers based on the offer conditions and the transaction data (see also Figure 12). Within Figure 12 it is noted that a digital representation of transaction data is received in step 300. The matching engine module 208 and bid manager module 210 may exchange information to determine whether the transaction data needs, at 302, to be enriched by the enricher module 212, e.g. to add historical transaction data related to the user.

If no enrichment of the transaction data is needed (e.g. no transaction meta-data is required) then the process moves to step 304 in which the matching engine module 208 assesses transaction vouchers against the transaction data. If no transaction vouchers have their issuance conditions (offer/bid conditions) satisfied then the process stops at 308.

If the transaction data requires further user related data to properly assess the issuance conditions associated with transaction vouchers within the bid manager module 210 then in step 306 this transaction meta-data is provided by the enrichment module 212 and the process moves to step 304 as before.

If the matching engine 208 matches more than one transaction voucher to the received transaction data then the process moves to step 310 in which the auction process module 214 runs an auction as described below.

The enricher module 212 is arranged to receive transaction data (e.g. from the POS system in Figure 9) and to determine a set of meta-data associated with the transaction data. Transaction data within the context of the present invention may include a range of data types associated with a transaction made by a user. For example the transaction data may comprise an identifier of the transaction, where the transaction occurred (e.g. retailer name, branch, store, geographic location etc.), time and data, details on the items in the transaction, financial characteristics of the transaction, how the transaction was paid for and other data such as loyalty data, voucher data etc.

These data types may be represented and defined as a data set as follows:

TRANSACTION_ELEMENT = {Transaction-ID, Retailer Name, Branch, Store,

Geographic Location, Timestamp, Items, Total Net, Total Include Tax, Total per

Category, Credit/Debit Card, Loyalty Card, Voucher, Cash, Offer, Advertisement} where

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

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

· Timestamp comprises a time stamp of the transaction.

• Items corresponds to the items that have been bought in the transaction in the form of 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) relate to Paid amount related information.

· Credit/Debit Card, Loyalty Card, Voucher, Cash are payment type information.

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

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

Transactions may comprise any subset of the above data types apart from an empty set (which would denote no data). Transactions may therefore be regarded as an element (defined below as TRANSACTION_ELEMENT) that belongs to a set of all subsets of elements from the set TRANSACTION_ELEMENT except empty set.

A set of transactions may therefore be defined as a power set of set TRANSACTION_ELEMENT except empty set:

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

A set of TRANSACTION_ELEMENT elements T is called a digital representation of transaction data if T e TRANSACTIONS.

Users undertaking transactions at, for example the POS system of Figure 9, may be represented within the offer issuance system as "Customers".

Transaction data may be mapped customers, for example by mapping credit card data within the received transaction data. This may be represented as: Transaction T is mapped to an element from CUSTOMERS by the following function:

CUSTOMER(T): TRANSACTIONS -> CUSTOMERS. For a given customer (user) the offer issuance system may be queried to return all transaction data associated with that user's ID. This may be represented within the system by introducing a filtering function where:

FILTER(U): CUSTOMERS -> HISTORY

where HISTORY is a subset of TRANSACTIONS, and for every T e HISTORY we have CUSTOMER(T) = U. Transaction data may be associated with additional data in the form of Transaction Metadata. Meta-data of T may be defined as an element from the set

TRANSACTION_METADATA = P(TRANSACTION_METADATA_ELEMENTS) where

TRANSACTION_M ETADATA_ELEM ENTS = { DATAO(T), DATA1 (T), DATA2(T), DATAN(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 can be interpreted by the system. The enricher module 212 is arranged to map transaction data that it receives via a set of functions to return relevant transaction meta-data. This meta-data in turn is arranged to be supplied as an input to the matching engine module 208. The set of functions in the enricher module may be represented as; ENRICH_FUNCTIONS = { F(T): TRANSACTIONS -> TRANSACTION_METADATA }

As an example the enricher module may operate on loyalty card number data within the received transaction data to return additional customer information associated with the loyalty card number data. For example, address information may be returned, alternative transaction card data may be returned etc.

In a further example the enricher module 212 may return data indicating the user's associations with other users , e.g. the enricher module may be arranged to return "friends" of a user or "friends of friends" data. In order to return such friend data a social graph may be defined as a graph G(E,V), where V = CUSTOMERS is a set of nodes, and E is a set of edges; an edge being defined as a pair (U 1 , U2), where U1 and U2 e V; (U 1 , U2) is present in set E of G only if social connection between U 1 and U2 exists.

In order to determine the "friends of friends" of a given user, then let d(U 1 , U2): V * V -> N, where N is a set of natural numbers. This function returns the length of a shortest possible path between nodes U1 and U2. The length of a path is a number of edges between node U1 and U2. If there is no path, the distance is put to be infinity.

Let FRIENDS(C) to be a function such that:

FRIENDS(C) : CUSTOMERS -> FRIENDS where FRIENDS is a subset of CUSTOMERS such that for any U e FRIENDS we have d(CUSTOMER(T), CUSTOMER(U)) = 1.

It can be seen that if we need friends of friends of customer C for instance, then friends of friends can be obtained by applying FRIENDS function to each element returned by FRIENDS(C), that is;

FRIENDS_OF_FRIENDS_OF(C) = Union of FRIENDS(T) for each T e FRIENDS(C) This function may be generalised further.

An example of a social graph is shown in Figure 13 in which five customers, C1 -C5, are shown (the social graph comprises 5 vertexes and 5 edges).

If the above defined FRIEND(C) function is applied to customer C1 , then the system will return the set {C2,C3,C4} as friends of C1. Similarly, if the same function is applied to customer C5, then the enricher module will return {C2} as a friend of C5 as they are directly connected each other (It means their distance is 1).

If the above defined FRIENDS_OF_FRIENDS_OF function is applied to C1 then the enricher module may return {C5}. Friend relationship data may be stored by the offer issuance system 204 or alternatively may be supplied via another data source, e.g. a loyalty card system, a social network or via data collected during a sign-up/registration process. Within the offer issuance system 204 according to embodiments of the present invention an offer within the system may be defined by a number of elements:

1. Maximum Bid Amount - is the maximum amount of money that a party offering offers within the offer issuance system is willing to pay to win the auction.

2. Budget - is the total amount of money that a party offering offers within the system is willing to spend on a given offer campaign.

3. Bid Condition - is a Boolean expression of Boolean functions that are defined on elements from TRANSACTION_ELEMENT and TRANSACTION_METADATA sets, that is functions that are used in this Boolean expression belong to the

set BID_CONDITIONS = { F: TRANSACTION_ELEMENT

U TRANSACTION_M ETADATA -> {TRUE, FALSE} }

4. Offer - is a coupon, a voucher, or an advertisement.

Embodiments of the present invention are now described, by way of example only, with reference to the following Example Scenarios.

Scenario 1 : Typical Case

In this scenario it is assumed that initially no offers have been loaded into the system via the bid manager module 210. Further, when third parties (e.g. retailers) load their offers into the system they have no knowledge of previous winning offers (and no knowledge therefore of the maximum bids that have won previous offers). Within the context of the present example it is noted that the unit £0.01 is a penny, and the minimum number of units to bid competitor's bid is one penny, that is £0.01. Within this example two offers are initially set up via two different third parties, Retailer X and Retailer Y, the details of which are noted below.

Retailer X

Maximum Bid Amount set to £1 Bid Conditions: SPEND(Total Net). A Boolean function SPEND(Total Net) is set up such that it returns TRUE if the Total Net amount in a transaction falls within the interval [10..20].

Retailer X Offer is: Get £1 off your next purchase at X.

Budget is set to be £100.

Retailer Y

Maximum Bid Amount set to £1.50

Bid Conditions : SPEND(Total Net) AND IS_CREDIT(Payment). In Retailer Y's offer the function SPEND(Total Net) will return as TRUE if Total Net amount in a transaction falls within the interval [10..15]. The function "IS_CREDIT" will return as TRUE if payment for the transaction is via a Credit/Debit Card.

Retailer Y offer is: Get £1 off your next purchase at Y.

Budget is set to be £200.

A user (customer) then buys an item during a transaction and spends £12 at store Z, paying by card. The digital representation of the transaction data corresponding to the transaction is supplied to the Digital Receipt System and then to the offer issuance system 204.

The customer then subsequently attempts to retrieve an offer from the offer issuance system 204. It is noted that the offer issuance system may be configured to issue offers in a number of different manners. In a first scenario a customer (user) may interact with the offer issuance system (e.g. by logging into their user profile) and request a copy of their digital receipt data. As a "bonus" the offer issuance system may issue an invoice to the customer on the basis of their transaction data. In a second scenario the customer may be sent an offer as part of a transaction. In this scenario the user would be presented with the offer at the end of the transaction process and the issue of the offer by the offer issuance system will have effectively occurred "behind the scenes" as far as the customer is concerned. In a third scenario a customer (user) may interact with the offer issuance system (e.g. by logging into their user profile) and attempt to directly retrieve an offer from the offer issuance system. In the event that the offer issuance system holds multiple transaction history data for the customer then the system may be configured to allow the user to search across all their available digital receipts and to select one particular receipt to retrieve offers against. Alternatively the customer may have been provided with a transaction code (e.g. printed on a physical receipt or sent to a mobile communications device associated with the customer) and the offer issuance system may be configured to search for offers against the digital receipt associated with the transaction code.

The Matching Engine module 208 is arranged to retrieves the all active offers from the bid manager module 210. The offer conditions relating to each offer are assessed by the matching engine module and both offers are determined to be met by the data in the transaction information.

Both offers are therefore output from the matching engine module and sent to the auction process module 214. The auction process module determines that the bid from retailer Y is the winning offer since it has the higher bid. The winning bid for retailer Y is set at £1.01 (it is not £1.50, because the closest offer [from retailer X] is £1.00, so one unit is added to retailer Y's bid amount to get a winning bid of £1.01). An offer "Get £1 off your next purchase at Y" is served to the customer, and the remaining budget for retailer Y is set to be £198.99. The offers within the offer issuance system 204 now appear as:

Retailer X

Maximum Bid Amount set to £1

Bid Conditions: SPEND(Total Net). A Boolean function SPEND(Total Net) is set up such that it returns TRUE if the Total Net amount in a transaction falls within the interval [10..20].

Retailer X Offer is: Get £1 off your next purchase at X.

Budget is set to be £100. Retailer Y

Maximum Bid Amount set to £1.50

Retailer Y offer is: Get £1 off your next purchase at Y. Budget is set to be £198.99.

If a customer (either the same customer as before or a new customer) buys an item and spends £17 at store Z and pays by cash. The digital representation of the transaction data corresponding to the transaction is supplied to the Digital Receipt System and then to the offer issuance system.

The customer then subsequently attempts to retrieve an offer from the system 204. The matching engine module 208 is arranged to retrieve all the active offers in the system using the Bid Manager module and is arranged to determine that only one bid is applicable, namely the bid placed by Retailer X (the net transaction amount of £17 is outside retailer Y's SPEND(Total Net) limit).

Retailer X's offer conditions are passed to the Auction Process module 214 and since there is just one bid, the Auction Process module determines that the bid placed by Retailer X wins. The winning bid is £1.00. An offer "Get £1 off your next purchase at X" is served to the customer. The remaining budget for retailer X is set to be £99.99. (There are no other retailers being assessed by the Auction Process module in this embodiment as the transaction is outside Retailer Y's limit. As such the winning bid is set to one unit, £0.01 leaving £99.99 in the budget for Retailer X. In alternative embodiments the offer issuance system may require retailers to specify a minimum or starting bid, e.g. if the starting bid was £0.50 then the remaining budget would be £99.50)

The offers within the offer issuance system 204 now appear as:

Retailer X

Maximum Bid Amount set to £1

Retailer X Offer is: Get £1 off your next purchase at X.

Budget is set to be £99.

Retailer Y

Maximum Bid Amount set to £1.50 Bid Conditions : SPEND(Total Net) AND IS_CREDIT(Payment). In Retailer Y's offer the function SPEND(Total Net) will return as TRUE if Total Net amount in a transaction falls within the interval [10..15]. The function "IS_CREDIT" will return as TRUE if payment for the transaction is via a Credit/Debit Card.

Retailer Y offer is: Get £1 off your next purchase at Y.

Budget is set to be £198.99.

At this point a further third party, Retailer Z, begins to enter an offer into the offer issuance system 204 with the following condition. Bid Conditions: SPEND(Total Net), which returns TRUE if Total Net amount in a transaction is in the interval [5..15].

At this point the bid manager module 210 determines that these conditions overlap with the offers entered by Retailer X and Retailer Y. The system is therefore arranged to output to retailer Z details of the last highest bid that won in auctions where these two retailers participated. As noted above, retailer Y won with a maximum bid of £1.01.

Retailer Z then decides to set their Maximum Bid Amount to £1.60 such that the offer from retailer Z is: Retailer Z

Maximum Bid Amount set to £1.60

Bid Conditions : SPEND(Total Net), which returns TRUE if Total Net amount in a transaction is in the interval [5..15]

Retailer Z offer is: Get £1 off your next purchase at Z.

Budget is set to be £150.

A customer (again this could be the same customer that participated in the above offer issues or a new customer) buys an item and spends £10 at store Z and pays by credit card. The digital representation of corresponding receipt is available to the Digital Receipt System 202.

The customer attempts to retrieve an offer from the system 204. Now the Matching Engine module 208 is arranged to all active bids within the system using the bid manager module 210. There are three active offers within the system and the matching engine module determines that all three offers are applicable. The three applicable offers are passed to the Auction Process module which determines that the offer placed by Retailer Z wins (as its maximum bid amount is the highest). The winning bid is actually set as £1.51 (which is one unit above retailer Y's maximum bid). An offer "Get £1 off your next purchase at Z" is served to the customer. The remaining budget for retailer Z is set to be £148.49.

Scenario 2: Typical Usage of History

In this scenario it is again assumed that initially no offers have been loaded into the system 204 via the bid manager module 210. Further, when third parties (e.g. retailers) load their offers into the system 204 they have no knowledge of previous winning offers (and no knowledge therefore of the maximum bids that have won previous offers). Within the context of the present example it is noted that the unit £0.01 is a penny, and the minimum number of units to bid competitor's bid is one penny, that is £0.01.

Retailers X, Y and Z set up offers in accordance with the following conditions. Retailer X

Maximum Bid Amount set to £1.00

Bid Conditions: SPEND(Total Net) AND WEEK_HISTORY_HAS(HISTORY, 'X123'). A Boolean function SPEND(Total Net) is set up such that it returns TRUE if the Total Net amount in a transaction falls within the interval [10..20] and the WEEK_HISTORY_HAS function takes the history and checks if any digital representation of transaction data from the last week, for the given customer, has Items element and that Items element contains a tuple where Item Identifier is X123 (e.g. for simplicity the system will check if some transaction from the last week for that user contains item X123).

Retailer X Offer is: Get £1 off your next purchase at X.

Budget is set to be £100. Retailer Y

Maximum Bid Amount set to £1.00

Bid Conditions : SPEND(Total Net). SPEND(Total Net) is set up such that it returns TRUE if the Total Net amount in a transaction falls within the interval [10..15].

Retailer Y offer is: Get £1 off your next purchase at Y.

Budget is set to be £100. Retailer Z

Maximum Bid Amount set to £1.10

Bid Conditions : SPEND(Total Net) AND WEEK_HISTORY_HAS(HISTORY, 'X123'). SPEND(Total Net) returns TRUE if Total Net is in interval [10..15].

Retailer Z offer is: Get £1 off your next purchase at Z.

Budget is set to be £100.

In this scenario a customer then enters into a transaction at store Z and spends £10, but doesn't buy X123 item. The digital representation of corresponding receipt is available to the Digital Receipt System 202.

The customer subsequently tries to retrieve an offer from the system 204. The Matching Engine module 208 is arranged to retrieve all active offers (three offers) using the Bid Manager module 210 and determines that only one offer is applicable, namely the offer placed by Retailer Y.

The offer is passed to Auction Process module 214 which determines that the offer wins, because there is just one applicable offer. The winning bid is £1.00. An offer "Get £1 off your next purchase at Y" is then served to the customer, and the remaining budget for retailer Y is set to be £99.00.

The same customer then enters into a subsequent transaction at store Y and spends £12 including the X123 item. The digital representation of corresponding receipt is available to the Digital Receipt System. Now this customer has two receipts in their history.

The customer tries to retrieve an offer from the system 204. The Matching Engine module 208 is arranged to retrieve all active offers (three offers) using the Bid Manager module 210 and determines that all offers are applicable. The three applicable offers are passed to the Auction Process module 214 which determines that the offer placed by Retailer Z wins, because it has the highest maximum bid. The winning bid is £1.01. An offer "Get £1 off your next purchase at Y" is served to the customer, and the remaining budget for retailer Z is set to be £98.99. Scenario 3: Example Usage of Customer's Friends Transaction History In this scenario it is again assumed that initially no offers have been loaded into the system 204 via the bid manager module 210. Further, when third parties (e.g. retailers) load their offers into the system they have no knowledge of previous winning offers (and no knowledge therefore of the maximum bids that have won previous offers). Within the context of the present example it is noted that the unit £0.01 is a penny, and the minimum number of units to bid competitor's bid is one penny, that is £0.01. Additionally in this scenario the offer issuance system has knowledge of a social connection between customer C1 and customer C2. Retailers X and Y set up offers in accordance with the following conditions.

Retailer X

Maximum Bid Amount set to £1.10

Bid Conditions: SPEND(Total Net) AND WEEK_HISTORY_HAS(HISTORY, 'X123') AND FRI EN DS_WEEK_H ISTORY_HAS(FRI EN DS, 'X456'). Boolean function SPEND(Total Net) is arranged to return as TRUE if the Total Net amount in a transaction is in the interval [10..20]. The WEEK_HISTORY_HAS function takes the transaction history of a user (customer) and checks if any transaction from the last week for the given customer contains item X123. The function FRIENDS_HISTORY_HAS takes as argument the friends set of a customer and checks if any of them bought X456 in the last week.

Retailer X offer is: Get £1 off your next purchase at X.

Budget is set to be £100. Retailer Y

Maximum Bid Amount set to £1.00

Bid Conditions: SPEND(Total Net) AND WEEK_HISTORY_HAS(HISTORY, 'X123'). The Boolean function SPEND(Total Net) is arranged to return TRUE if the Total Net amount in a transaction is in the interval [10..20]. The WEEK_HISTORY_HAS function takes the history and checks if any transaction from the last week for the given customer contains item X123.

Retailer Y offer is: Get £1 off your next purchase at Y.

Budget is set to be £100. In this scenario customer C1 enters into a transaction of £12 at store Z, and buys X123 item. Customer C1 then attempts to retrieve an offer from the system 204. The Matching Engine module 208 is arranged to retrieve all active offers (two offers) using the Bid Manager module and determines that only one bid is applicable, namely the bid placed by Retailer Y, since none of customer C1 's friends bought X456. The applicable offer is passed to the Auction Process module 214 which determines that the offer wins, because there is just one applicable offer. The winning bid is £1.00. An offer "Get £1 off your next purchase at Y" is served to the customer, and the remaining budget is set to be £99.00.

Customer C1 then enters into a further transaction of £12 at store Z, and buys X123 item again. Customer's C1 friend C2 also enters into a transaction and buys X456 item.

Customer C1 attempts again to retrieve an offer from the system. The Matching Engine module is arrange to retrieve all active offers (two offers) using the Bid Manager module and determines that two offers are applicable. The applicable offers are passed to the Auction Process module which determines that the bid placed by Retailer X wins, because it has highest bid. The winning bid is £1.01. An offer "Get £1 off your next purchase at X" is served to the customer, and the remaining budget for retailer X is set to be £98.99.

Scenario 4: Example of Meta-data Usage

In this scenario it is again assumed that initially no offers have been loaded into the system 204 via the bid manager module 210 . Further, when third parties (e.g. retailers) load their offers into the system they have no knowledge of previous winning offers (and no knowledge therefore of the maximum bids that have won previous offers). Within the context of the present example it is noted that the unit £0.01 is a penny, and the minimum number of units to bid competitor's bid is one penny, that is £0.01.

Retailer X sets up an offer under the following conditions Retailer X

Maximum Bid Amount set to £1.00

Bid Conditions: CONTAINS_ITEM(ltems, 'Coffee Mill') AND

DISTANCE_HALF_MILE(GPS Location, 'Coffee Brand Store'). Boolean function CONTAINS_ITEM(ltems, 'Coffee Mill') is arranged to return as TRUE if Items, an element of a current transaction, contains an item 'Coffee Mill', that is if Items element contains a tuple where Item Identifier is 'Coffee Mill'. Function

DISTANCE_HALF_MILE takes as arguments current GPS Location of a customer and checks if the distance to store 'Coffee Brand Store' is less than or equal to half a mile, and if it is, returns TRUE, otherwise FALSE. The GPS Location will be obtained by the Enricher module using one of the functions from ENRICH_FUNCTIONS set. For example, function CURRENT_GPS_LOCATION(C) e ENRICH_FUNCTIONS which takes an element from CUSTOMERS set and returns current GPS location of the corresponding customer. (This GPS location can be for example periodically supplied by an application installed on customer's mobile phone or a customer can supply it manually while retrieving a digital receipt from the system.)

Retailer X offer is: Get 20% off your next purchase at Coffee Brand Store on all coffee beans.

Budget is set to be £100.

A customer buys a Coffee Mill at store X. The digital representation of corresponding receipt is available to the Digital Receipt System. It is assumed that the customer is very close to Coffee Brand Store.

The customer attempts to retrieve an offer from the system 204. The Matching Engine module 208 is arranged to retrieve all active offers (one offer) using the Bid Manager module 210 and determines that only one bid is applicable, namely the bid placed by Retailer X, because the customer is close to the Coffee Brand Store and the customer bought 'Coffee Mill'. The bid is passed to the Auction Process module 214 which determines that the offer wins, because there is just one offer. The winning bid is £1.00. An offer "Get 20% off your next purchase at Coffee Brand Store on all coffee beans" is served to the customer, and the remaining budget is set to be £99.00. It will be understood that the embodiments described above are given by way of example only and are not intended to limit the invention. It will also be understood that the embodiments described may be used individually or in combination.

Claims

1. A computing system for issuing transaction vouchers, the system comprising:

an input arranged to

receive a transaction voucher from a voucher entity, the transaction voucher being associated with a set of data types, each data type having an issuance parameter to be met;

receive transaction data, the transaction data comprising data related to a user transaction;

a processor arranged to

assess each issuance parameter of the transaction voucher against the received transaction data to determine if the issuance parameter is satisfied and, in response to there being any issuance parameters that have no transaction data to be assessed against, to retrieve further user related data and to asses each remaining issuance parameter against the further user related data to determine if each remaining issuance parameter is satisfied

flag the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied

an output arranged to output the matched transaction voucher.

2. A system as claimed in Claim 1 , wherein the output is arranged to output the transaction voucher to the user.

3. A system as claimed in Claim 1 , wherein the transaction data is received from a point of sale system and the output is arranged to output the transaction voucher to the point of sale system for inclusion in a transaction receipt.

4. A system as claimed in Claim 1 , wherein the transaction data is received from a point of sale system and the output is arranged to output the transaction voucher to the point of sale system for use in the user transaction.

5. A system as claimed in any preceding claim, wherein the issuance parameters associated with the set of data types comprise a set of Boolean conditions.

6. A system as claimed in any preceding claim, wherein the transaction data relates to a transaction at a point of sale system and the further user related data comprises transaction metadata received from a further system.

7. A system as claimed in Claim 6, wherein the further system is a user location system and the further user related data comprises user location data.

8. A system as claimed in Claim 6 or Claim 7, wherein the further system comprises a historical transaction system and the further user related data comprises data relating to historical transactions of the user.

9. A system as claimed in any one of claims 6 to 8, wherein the further system comprises a social network system and the further user related data comprises transaction data relating to further users associated with the user.

10. A system as claimed in any preceding claim, wherein the input is arranged to receive a plurality of transaction vouchers, each voucher being associated with a set of data types, each data type having an issuance parameter to be met, and, for each of the plurality of transaction vouchers, the processor is arranged to assess each issuance parameter against the received transaction data to determine if the issuance parameter is satisfied and, in response to there being any issuance parameters that have no transaction data to be assessed against, to retrieve further user related data and to asses each remaining issuance parameter against the further user related data to determine if each remaining issuance parameter is satisfied; flag the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied and wherein the output is arranged to output each matched transaction voucher.

1 1. A system as claimed in Claim 10, wherein each matched transaction voucher is output to a transaction voucher selection module.

12. A system as claimed in Claim 11 , wherein in the event that there are two or more matched transaction vouchers, the transaction voucher selection module is arranged to select one transaction voucher according to a predetermined criteria.

13. A system as claimed in Claim 12, wherein the transaction voucher selection module is arranged to select the one transaction voucher in accordance with the issuance parameters of the two or more matched transaction vouchers.

14. A system as claimed in Claim 12 or 13, wherein the transaction voucher selection module is arranged to hold an auction between the two or more matched transaction vouchers.

15. A computing system for issuing transaction vouchers, the system comprising:

an input arranged to

receive further user related data

a processor arranged to

assess each issuance parameter of the transaction voucher against the received transaction data and the further user related data to determine if the issuance parameter is satisfied

an output arranged to output the matched transaction voucher.

16. A method for issuing transaction vouchers, the method comprising:

receiving a transaction voucher from a voucher entity, the transaction voucher being associated with a set of data types, each data type having an issuance parameter to be met;

receiving transaction data, the transaction data comprising data related to a user transaction;

assessing each issuance parameter of the transaction voucher against the received transaction data to determine if the issuance parameter is satisfied and, in response to there being any issuance parameters that have no transaction data to be assessed against, retrieving further user related data and to asses each remaining issuance parameter against the further user related data to determine if each remaining issuance parameter is satisfied

flagging the voucher as being a matched transaction voucher in the event that each issuance parameter across the set of data types is satisfied

outputting the matched transaction voucher.

17. A method for issuing transaction vouchers comprising:

receiving a transaction voucher from a voucher entity, the transaction voucher being associated with a set of data types, each data type having an issuance parameter to be met; receiving transaction data, the transaction data comprising data related to a user transaction;

receiving further user related data

assessing each issuance parameter of the transaction voucher against the received transaction data and the further user related data to determine if the issuance parameter is satisfied

outputting the matched transaction voucher.

18. A carrier medium for carrying a computer readable code for computer system to carry out the method of either Claim 16 or Claim 17.