WO2015019115A1 - Système et procédé d'émission d'offre - Google Patents

Système et procédé d'émission d'offre Download PDF

Info

Publication number
WO2015019115A1
WO2015019115A1 PCT/GB2014/052449 GB2014052449W WO2015019115A1 WO 2015019115 A1 WO2015019115 A1 WO 2015019115A1 GB 2014052449 W GB2014052449 W GB 2014052449W WO 2015019115 A1 WO2015019115 A1 WO 2015019115A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
data
voucher
issuance
offer
Prior art date
Application number
PCT/GB2014/052449
Other languages
English (en)
Inventor
Yosuke OZAWA
Roman VALIUSENKO
Hassan Hajji
Original Assignee
Ecrebo Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ecrebo Limited filed Critical Ecrebo Limited
Publication of WO2015019115A1 publication Critical patent/WO2015019115A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/387—Payment using discounts or coupons

Definitions

  • the present invention relates to an offer issuing system and method.
  • 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.
  • 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).
  • POS point-of-sale
  • the issuing of targeted offers, such as coupons and vouchers, at POS systems is an important and effective marketing tool.
  • 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.
  • a computing system for issuing transaction vouchers 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
  • Transaction vouchers 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.
  • 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.
  • the user may access the computer system to retrieve the transaction voucher.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a computing system for issuing transaction vouchers 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.
  • 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; 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.
  • 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;
  • 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.
  • Figure 1 shows a known point-of-sale (POS) till configuration
  • FIG. 2 shows an OPOS architecture
  • FIG. 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
  • 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).
  • 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.
  • 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.
  • the POS application software module 17 formats details of the transaction and sends them to the receipt printer 5.
  • 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.
  • 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.
  • 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.
  • 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).
  • API OPOS application programming interface
  • 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
  • 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 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).
  • the virtual driver software module 40 may be installed and operated as follows:
  • 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.
  • 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.
  • 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).
  • 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")
  • 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.
  • 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.
  • 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.
  • 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:
  • ⁇ Provide information from a computing device 44 to a customer using existing hardware (i.e. the receipt printer 5);
  • POS terminal software module may in certain circumstances communicate directly with a physical hardware device rather than using an OPOS or JAVAPOS interface.
  • 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
  • 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.
  • the data sent to the printer is a digital copy of the receipt and can be parsed as text.
  • the data sent to the printer is binary, and a parsing program would not be able to readily recover the details of the transactions.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIGS 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.
  • 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.
  • the virtual driver module 40 may be used to issue coupons and vouchers with a barcode printed on them.
  • 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).
  • the offer conditions may be satisfied by means of an auction or bidding system.
  • FIG. 10 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.
  • 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.
  • the filter device 40 may send transaction data to the computing device 44 (the offer issuance system) for processing as described below.
  • the offer issuance system 204 may receive transaction data from another source.
  • 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.
  • 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
  • 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.
  • 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).
  • 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.
  • step 304 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.
  • step 306 this transaction meta-data is provided by the enrichment module 212 and the process moves to step 304 as before.
  • step 310 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.
  • 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.
  • TRANSACTION_ELEMENT ⁇ Transaction-ID, Retailer Name, Branch, Store,
  • 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).
  • Offers - a set of offer served at this transaction • Offers - a set of offer served at 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.
  • TRANSACTION_ELEMENT an 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.
  • 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.
  • 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:
  • 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)
  • TRANSACTION_M ETADATA_ELEM ENTS ⁇ DATAO(T), DATA1 (T), DATA2(T), DATAN(T) ⁇
  • 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 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.
  • 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.
  • 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.
  • FIG. 13 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).
  • 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.
  • a loyalty card system e.g. a loyalty card system
  • a social network e.g. a social network
  • data collected during a sign-up/registration process e.g. a loyalty card system, a social network
  • an offer within the system may be defined by a number of elements:
  • 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.
  • budget - is the total amount of money that a party offering offers within the system is willing to spend on a given offer campaign.
  • 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
  • Offer - is a coupon, a voucher, or an advertisement.
  • 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.
  • Retailer Y offer is: Get £1 off your next purchase at Y.
  • a user then buys an item during a transaction and spends £2 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 offer issuance system may be configured to issue offers in a number of different manners.
  • a customer user
  • the offer issuance system e.g. by logging into their user profile
  • the offer issuance system may issue an invoice to the customer on the basis of their transaction data.
  • 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.
  • a customer 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.
  • the offer issuance 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.
  • 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 £.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 £.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 £98.99.
  • the offers within the offer issuance system 204 now appear as:
  • 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.
  • Retailer Y offer is: Get £ off your next purchase at Y. Budget is set to be £98.99.
  • a 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 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 £.00.
  • An offer "Get £ 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.
  • 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)
  • 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.
  • Retailer Y offer is: Get £1 off your next purchase at Y.
  • 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].
  • 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.
  • retailer Y won with a maximum bid of £.01.
  • Retailer Z then decides to set their Maximum Bid Amount to £1.60 such that the offer from retailer Z is: Retailer Z
  • Retailer Z offer is: Get £ off your next purchase at Z.
  • a customer buys an item and spends £ 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.
  • the Matching Engine module 208 is arranged to all active bids within the system using the bid manager module 210.
  • 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 £.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.
  • Retailers X, Y and Z set up offers in accordance with the following conditions. Retailer X
  • Retailer X Offer is: Get £1 off your next purchase at X.
  • 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.
  • Retailer Z offer is: Get £ off your next purchase at Z.
  • 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 £ 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 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 £.01.
  • An offer "Get £ 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.
  • Retailer X offer is: Get £1 off your next purchase at X.
  • Retailer Y offer is: Get £1 off your next purchase at Y.
  • 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 £.00.
  • An offer "Get £ 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 £2 at store Z, and buys X123 item again.
  • Customer's C1 friend C2 also enters into a transaction and buys X456 item.
  • 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 £.01.
  • An offer "Get £ off your next purchase at X" is served to the customer, and the remaining budget for retailer X is set to be £98.99.
  • Retailer X sets up an offer under the following conditions Retailer X
  • DISTANCE_HALF_MILE GIS 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'.
  • 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.
  • 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.

Abstract

La présente invention concerne un système informatique destiné à émettre des bordereaux de transaction. Ledit système comprend : une entrée configurée pour recevoir un bordereau de transaction d'une entité de bordereaux, le bordereau de transaction étant associé à un ensemble de types de données, chaque type de données ayant un paramètre d'émission à satisfaire, et pour recevoir des données de transaction, les données de transaction comprenant des données relatives à une transaction d'un utilisateur; un processeur configuré pour estimer chaque paramètre d'émission du bordereau de transaction par rapport aux données de transaction reçues afin de déterminer si le paramètre d'émission est satisfait et, en réponse au fait qu'il y a des paramètres d'émission qui n'ont pas de données de transaction par rapport auxquelles on peut réaliser une estimation, pour récupérer d'autres données relatives à l'utilisateur et estimer chaque paramètre d'émission restant par rapport aux autres données relatives à l'utilisateur afin de déterminer si chaque paramètre d'émission restant est satisfait; signaler que le bordereau est un bordereau de transaction apparié dans le cas où chaque paramètre d'émission parmi l'ensemble de types de données est satisfait; une sortie configurée pour sortir le bordereau de transaction apparié.
PCT/GB2014/052449 2013-08-09 2014-08-11 Système et procédé d'émission d'offre WO2015019115A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1314345.8 2013-08-09
GBGB1314345.8A GB201314345D0 (en) 2013-08-09 2013-08-09 Offering bidding system using digital representation of transaction data

Publications (1)

Publication Number Publication Date
WO2015019115A1 true WO2015019115A1 (fr) 2015-02-12

Family

ID=49261994

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2014/052449 WO2015019115A1 (fr) 2013-08-09 2014-08-11 Système et procédé d'émission d'offre

Country Status (2)

Country Link
GB (1) GB201314345D0 (fr)
WO (1) WO2015019115A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6269361B1 (en) 1999-05-28 2001-07-31 Goto.Com System and method for influencing a position on a search result list generated by a computer network search engine
US20040059708A1 (en) 2002-09-24 2004-03-25 Google, Inc. Methods and apparatus for serving relevant advertisements
EP1610248A2 (fr) * 2004-06-23 2005-12-28 Coupon Line S.r.l. Procédé et système de traitement et de distribution d'offres commerciales personnalisées pendant le séjour dans un point de vente
US20080154765A1 (en) 2001-03-13 2008-06-26 Jason Wolfe Method for the bidding for the placement of discount offers
EP2551815A1 (fr) * 2011-07-27 2013-01-30 Sainsbury's Supermarkets Ltd. Système informatique pour traiter des données de produit

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6269361B1 (en) 1999-05-28 2001-07-31 Goto.Com System and method for influencing a position on a search result list generated by a computer network search engine
US20080154765A1 (en) 2001-03-13 2008-06-26 Jason Wolfe Method for the bidding for the placement of discount offers
US20040059708A1 (en) 2002-09-24 2004-03-25 Google, Inc. Methods and apparatus for serving relevant advertisements
EP1610248A2 (fr) * 2004-06-23 2005-12-28 Coupon Line S.r.l. Procédé et système de traitement et de distribution d'offres commerciales personnalisées pendant le séjour dans un point de vente
EP2551815A1 (fr) * 2011-07-27 2013-01-30 Sainsbury's Supermarkets Ltd. Système informatique pour traiter des données de produit

Also Published As

Publication number Publication date
GB201314345D0 (en) 2013-09-25

Similar Documents

Publication Publication Date Title
US10902420B2 (en) Merchant configured advertised incentives funded through statement credits
US20180005200A1 (en) Generation and delivery of digital receipts based on user preferences and transaction related data
US20140058818A1 (en) Offer redemption of an offer at a retailer interface that identifies a retail transaction and line items used by offer validation
US20170140411A1 (en) Systems and methods for providing loyalty awards of stock
KR20010113295A (ko) 포인트 거래 서비스 방법 및 그 서비스 시스템
US20130275266A1 (en) Universal consumer card offer and redemption system and related method
US20160239860A1 (en) A method of enabling a customer profile
US20130325582A1 (en) Campaign reward system that provides offers to users via their mobile devices
US20140149196A1 (en) Offer redemption of an offer at a retailer
US20130339143A1 (en) Campaign reward system with targeting of users for offers
JP2014137811A (ja) ポイントサービス装置、ポイントサービスシステム及びポイントサービス方法
US20160155107A1 (en) Improved performance in interaction systems
JP2013061903A (ja) クーポン提供システム、サーバ装置およびプログラム
US20180165716A1 (en) Advertisement exchange network
KR20200000605A (ko) 배달 주문 매출 정산 방법 및 그를 수행하기 위한 결제 단말 장치
JP2009271807A (ja) サーバシステム及びデータ処理方法
US20170243253A1 (en) Advertisement exchange network
US20150149313A1 (en) Method For Providing A Customer With Information At A Point Of Sale (POS)
KR102475569B1 (ko) 발행자 맞춤형 쿠폰 발행 서비스 방법 및 발행자 맞춤형 쿠폰 발행 서비스 시스템
US20140046759A1 (en) Campaign reward system with sorting of offers to users
WO2015159105A1 (fr) Procédé de détermination de l'identité d'un utilisateur
WO2012138413A2 (fr) Systèmes et procédés de récompense de la loyauté par des parts de capital
WO2015019115A1 (fr) Système et procédé d'émission d'offre
US20130339135A1 (en) Campaign reward system with campaign modification
US20130317913A1 (en) Campaign reward system in communication with financial institution

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14771351

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14771351

Country of ref document: EP

Kind code of ref document: A1