WO2015044693A1 - Méthode de stockage de contenus - Google Patents

Méthode de stockage de contenus Download PDF

Info

Publication number
WO2015044693A1
WO2015044693A1 PCT/GB2014/052958 GB2014052958W WO2015044693A1 WO 2015044693 A1 WO2015044693 A1 WO 2015044693A1 GB 2014052958 W GB2014052958 W GB 2014052958W WO 2015044693 A1 WO2015044693 A1 WO 2015044693A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
transaction
feedback
server
data
Prior art date
Application number
PCT/GB2014/052958
Other languages
English (en)
Inventor
Yosuke OZAWA
Roman VALIUSENKO
Hassan HAIJI
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 WO2015044693A1 publication Critical patent/WO2015044693A1/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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0282—Rating or review of business operators or products
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0226—Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems

Definitions

  • the present invention relates to a method of providing content.
  • the present invention relates to a system and method for providing user feedback to an event and a system and method for providing authenticated content.
  • Feedback is an important marketing tool to identify loyal customers, unsatisfied customers, or to facilitate improvement of the products. Feedback is also quite useful for customers to know about products or services before they buy. Feedback information may be used to understand customer demands and provide goods/services that better suit their needs. However, gathering feedback information has a number of challenges.
  • Efficient collection of feedback information is desirable.
  • Feedback that requires registration and/or is lengthy and/or complicated in nature reduces the level of client participation in providing feedback.
  • users customers
  • Anonymous data presented for example in the above described manner may not be reliable. It is therefore a further challenge to improve the reliability of feedback. It is important and beneficial for both the customer and the product seller to be able to identify reliable feedback. There is also a known problem of fake reviews including instances where positive reviews have been paid for in order to provide an improved appearance to third parties.
  • a method of processing at a server computer feedback events related to transactions comprising: receiving, from a payment terminal, transaction data relating to a transaction; receiving a feedback event related to the transaction from a user; associating the feedback event with the transaction data; storing the feedback event in a data store.
  • the present invention provides a server computer that is arranged to manage transaction data received from a payment terminal such as a POS terminal and also feedback events from a user relating to that transaction. Received feedback events are associated with the corresponding transaction data to ensure the authenticity of the feedback event.
  • the feedback event is stored in a data store (such as a database). The association between the feedback event and the transaction data may also be stored in the data store.
  • the server may be arranged to generate a server authentication message in
  • the server authentication message may be sent to the payment terminal or to a printer device associated with the payment terminal.
  • the server authentication message may also alternatively or additionally be sent to a user computing device such as a smartphone or tablet computing device.
  • the server authentication message may comprise one or more selected from the group of: a barcode, a 2D barcode, a QR code, a one time password.
  • the server authentication message may comprise the transaction data encoded into one of this group of message types.
  • a transaction identifier may also be included in the server authentication message.
  • the server authentication message may comprise a validity period, e.g. a user may be required to use or otherwise process the server authentication message within a predetermined period of time in order to be able to submit a feedback event.
  • the user may, for example, scan or enter the server authentication message into a feedback client application program running on a user computing device in order to start a procedure that allows the user to submit a feedback message.
  • the server may receive a submitted feedback message from the user, the feedback message comprising the server authentication message.
  • the received transaction data may be sent to the user in order to enable the user to submit a feedback event.
  • the method may further comprise receiving location data relating to the user (e.g. the location of the user computing device) and time data and then cross checking the user's location at a certain time with the location/time of a given transaction. If the user was either not present at the location of the transaction at the time of the transaction or was located outside of a reachable distance from the transaction location after a given period of time then the feedback event may either be flagged as fraudulent or associated with a lower degree of reliability.
  • Transaction data may, in a first such time/location variant, comprise time-of-transaction data and location of the transaction and the method may comprise sending a request to a user computing device to supply the location the user computing device was at when the feedback event was sent from the user computing device to the server computer.
  • the time of the transaction associated with the received transaction data and the location of the payment terminal may then be compared with the time the feedback event was sent and the location it was sent from.
  • a reliability factor may then be calculated in dependence on this comparison. For example, if the feedback event was sent 30 minutes after the transaction then the server computer may assess whether the user computer device could have travelled from the location of the payment terminal to the location the feedback event was sent from in 30 minutes. If the distance between the two locations was assessed as too high then the feedback event may be flagged as either fraudulent or of low reliability.
  • the server computer may be arranged to send a request to the user computing device for its location data corresponding to the time of the transaction.
  • the method may then comprise determining if the user computing device was present at the location of the transaction at the time of the transaction and authenticating the feedback event in the event that the user computing device was present at the time and location of the transaction.
  • the method may comprise establishing a user profile on the server computer, the user profile being associated with a unique user identifier used during a transaction made by a user.
  • the unique user identifier may comprise an account number associated with a user transaction device, such as a bank card or a payment-enabled mobile device.
  • the unique user identifier may comprise an account number associated with a user loyalty card.
  • the server computer may receive a cryptographically hashed version of the unique user identifier.
  • the received transaction data may be associated with the user profile to create a transaction history for the user.
  • the user profile may comprise a unique device identifier corresponding to a user computing device (e.g. a mobile device IMEI number or other similar unique identification code).
  • a transaction history request may be received from the user computing device.
  • transaction data stored in the transaction history of the user may be sent to the user to enable the user to submit a feedback request.
  • a search request may be received from the user, stored transactions may be searched and feedback events associated with the stored transactions may be retrieved. Feedback event may be matched to the received search request and relevant matches then sent to the user.
  • the server computer may comprise a data store having a plurality of transaction histories, each transaction history being associated with a user and each transaction history comprising user transaction data and at least one feedback event from that user.
  • the method may comprise receiving a recommendation request from a requesting user, searching the data store in dependence on a user similarity threshold, retrieving a list of users that meet the similarity threshold, sending recommendations to the requesting user based on the positive feedback events associated with the other users.
  • the method may further comprise receiving a recommendation request from a transaction vendor, searching the data store for matching users in dependence on a similarity threshold between a vendor profile and users that have submitted positive feedback events associated with other transaction vendors.
  • the method may comprise issuing a transaction offer to the user.
  • the present invention extends to a carrier medium for carrying a computer readable code for server computer to carry out the method of the first aspect of the present invention.
  • a server computer for processing feedback events related to transactions, comprising: an input; a processor; an output wherein the input is arranged to receive, from a payment terminal, transaction data relating to a transaction and to receive a feedback event related to the transaction from a user; the processor is arranged to associate the feedback event with the transaction data and to store the feedback event in a data store.
  • Web-site based feedback systems are also popular. However, they do not guarantee or provide any evidence that the given review/feedback is genuine. In addition to that, these feedback services do not provide a way to reach the customers. For instance, a retailer might be interested in unsatisfied customers and trying to mitigate bad customer experience by giving some offer or discount.
  • Feedback may be given per item, per product seller, location, or other relevant transaction data.
  • the system may also allow the delivery of offers to loyal or unsatisfied customers, s
  • a set of reviewers S with similar purchase patterns may be identified enabling reviewer A to explore product sellers that she or he is not familiar with.
  • Embodiments of the present invention may provide a secure, simple, and reliable review/feedback system with some or more of the following features:
  • customer's identifiers such as credit/debit/loyalty cards etc.
  • transaction elements and a template selected depending on the contents of the transaction (There might be multiple feedback templates at the feedback server and one or more feedback templates may be returned to a user depending on the contents of given transaction.
  • the feedback templates may also be further modified with actual value in the transaction. For example a standard template "Were the transaction items good?" might be changed to "Was the steak good?" based on the items listed in the transaction data).
  • embodiments of the present invention embody a number of operation sets, such as:
  • SUID and User-ID Association may be the operation that creates links between SUIDs and User-IDs in Customer Profiles.
  • SUID and Subsequent Transaction Association operation may associate transaction data with SUIDs or User-IDs. This may allow collecting transaction data that are associated with specific customer. A customer then might select separate items from this transaction history and write feedback/reviews about them.
  • embodiments of the present invention may provide: Validation commands (password checks etc) sent to Feedback Server may impose a delayed response in case of failure to prevent brute force attacks.
  • That User Transaction identifiers may not be transmitted over the network and may not be stored by the system in the data store, v " Transaction data may be amended by the Feedback Enhancer before sending it to Feedback Server in such a way that the transaction data becomes unobtainable.
  • Scan codes may optionally be digitally signed.
  • Figure 1 shows a known point-of-sale (POS) till configuration
  • FIG. 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
  • FIG. 5 shows a filter driver architecture in accordance with an embodiment of the present invention
  • Figure 6 shows a known API structure
  • FIG. 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 server computer in accordance with embodiments of the present invention
  • Figure 10 shows how the state of a transaction card within the server computer may be flagged according to embodiments of the present invention
  • Figures 11 to 13 show a process of associating a unique user identifier with a user-ID in accordance with embodiments of the present invention
  • Figure 14 shows a process for associating received transaction data with a user-ID in accordance with an embodiment of the present invention
  • Figure 15 shows a feedback submissions process in accordance with an embodiment of the present invention
  • Figure 16 shows an overview of a user profile in accordance with an embodiment of the present 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.
  • 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. It is noted that OPOS is an implementation of an interoperability standard for a Windows® operating system using Component Object Model (COM) technology.
  • COM Component Object Model
  • 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:
  • 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).
  • 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.
  • 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. 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.
  • 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: ⁇ Intercept transaction details without needing to modify the POS application software module 17;
  • a 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.
  • FIG. 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.
  • 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 102 which is explained in more detail below.
  • FIG 9 shows a point-of-sale system in accordance with an embodiment of the present invention.
  • Like reference numerals with the system of Figure 1 are used to denote like features.
  • transaction from the payment application software module data that is directed to the printer 5 passes through an enhancer module 100.
  • the enhancer module comprises an interceptor module 102 which is arranged to intercept the transaction data and send it to a feedback server 108. Data that is received from the server 108 at the enhancer module 100 may be inserted back into data stream to the printer by the modifier module 106.
  • the feedback server 108 may be located remotely from the payment terminal 3.
  • Figure 9 also shows , a feedback client application module 110, a thesaurus module 1 11 and a database 1 12 which are described in more detail below.
  • the payment terminal 3 may comprise any device that provides access to transaction data, for example a point of sale (POS) terminal, a Process Data Quickly (PDQ) terminal and electronic commerce systems such as online shops, transaction stores etc.
  • POS point of sale
  • PDQ Process Data Quickly
  • electronic commerce systems such as online shops, transaction stores etc.
  • the payment application software module 21 may be embodied as a Main Payment Terminal Application (MPTA) which corresponds to software responsible for authenticating a transaction or loyalty card, verifying a PIN, and authorising the card for payment.
  • MPTA Main Payment Terminal Application
  • the printer 5 may comprise any device that is capable of displaying or printing an image.
  • Transaction data sent from the software module 21 to the printer 5 may comprise one or more transaction elements defined as
  • TRANSACTION_ELEMENT ⁇ Transaction-ID, Retailer Name, Branch, Store,
  • Transaction-ID - a globally unique identifier of the transaction
  • Retailer ID Branch, Store, Geographic Location - location related information.
  • Timestamp - time stamp of the transaction Timestamp - time stamp of the transaction.
  • Items - bought items a set of tuples of form (Item Identifier, Item Description, Amount, Price).
  • Cash - payment type information e.g. Card Name, hashed PAN, etc.
  • Offers - a set of offer served at this transaction Offers - a set of offer served at this transaction.
  • Advertisements - a set of advertisement served with this transaction.
  • P(X) means power set of X.
  • a set of TRANSACTION_ELEMENT elements T is called a digital representation of transaction data (or just if transaction data) if
  • Customer Profile is a data structure that contains all relevant information associated with a user identifier (User-ID), including reviews/feedback given by a customer.
  • Index Function is a function that takes as argument Customer Profile and return an index. (E.g. some Index-Function might return a distance between two
  • the point-of-sale system in accordance with an embodiment of the present invention comprises a number of components that may be located remotely from the POS terminal 3. As shown in the figure these components comprise the feedback server 108, the feedback client application module 1 10 and a thesaurus module 1 11 and a database 112 (a data store). These four components in conjunction with the enhancer module 100 within the payment terminal 3 (effectively a further, distributed, component) form a feedback system 104.
  • the feedback program system as described below provides a mechanism for a user to register, obtain an account and submit feedback reviews with the system without the need to enter any additional personal data than is already present during a user transaction.
  • the components 108, 110, 11 1 and 1 12 may be located within a single device or system or alternatively may be located in distributed devices.
  • the feedback client application module 1 10 may be located in a user's mobile communication device such as a smartphone or tablet computer.
  • the interceptor module 102 is arranged to intercept data processed by the payment terminal application software module 21.
  • the interceptor module 102 is arranged to communicate with the feedback Server 108 to maintain user (customer) related information or to associate transactions with users.
  • the interceptor module may be integrated with the payment terminal 3 in order to obtain access to additional information about transactions.
  • the modifier module 106 is arranged to inject or modify data flowing from Payment Terminal 3 to the Printer 5.
  • the interceptor module 102 and modifier module 106 of Figure 9 may be implemented using the system arrangements shown in Figures 1 to 8 above.
  • the Feedback Server 108 may be arranged to keep track of user profiles, received reviews/feedback and may be arranged to analyse received data as described in more detail below.
  • the feedback Application module 1 10 and feedback Enhancer module 100 are arranged to communicate with the feedback server 108.
  • the feedback Client Application module 1 10 is in communication with the feedback Server 108 (e.g. the module 1 10 may be a software application running on a user's computing device) and allows users to register with the service, submit reviews, etc.
  • the Thesaurus module 1 11 is arranged to translate item identifiers found in transaction data received from the interceptor module 102 to human-readable common names and is arranged to store this along with other data (e.g. transaction data, associated transaction identifiers, any passwords or barcodes as described herein) in the database 1 12.
  • a user may register with the feedback Server 108 using an instance of the Feedback Client Application module 110 on a user's computing device and get an account within the system. In such an instance the user would be allocated a customer account ID during the registration process.
  • Embodiments of the present invention however enable a user to be associated with the feedback system using a unique user identifier associated with their computing device. In this case the user's ID within the loyalty system becomes their device's identifier and they are not required to explicitly register or provide any personal data over and above that which is already included in their transaction history.
  • a user identifier SUID which is an identifier that is associated with a user transaction card (e.g. a PAN number) or a loyalty card number.
  • a user transaction card e.g. a PAN number
  • a loyalty card number e.g. a PAN number
  • the SUID described below may be associated with one of three different states within the loyalty system according to embodiments of the present invention.
  • State A is an initial state within the feedback system. This state is equivalent to the first time the feedback system encounters a particular SUID.
  • State B is an intermediate state that denotes that an SUID has been encountered by the feedback system before but that it has not been authorised.
  • State C for an SUID corresponds to a SUID that has been confirmed.
  • a user 120 enters into a transaction, in stage 1 , at a payment terminal 3 and uses one of their transaction cards 122 (e.g. a bank card or credit card or loyalty card) during the transaction.
  • the interceptor module 102 within the point of sale, POS 3, intercepts transaction data comprising the identifier of the transaction card (e.g. the permanent account number (PAN) that appears on the transaction card).
  • PAN permanent account number
  • the transaction card identifier effectively corresponds to a unique user identifier and the interceptor module 102 is arranged to apply a cryptographic hash function to the identifier.
  • the hashed identifier therefore comprises a customer identifier, herein referred to as the SUID, that may then be sent to the feedback server 108 without compromising any personal user data.
  • HASH is some cryptographic function.
  • the cryptographic function may include salt, key-stretching or other technique preventing brute force attacks.
  • the payment terminal 3/interceptor module 102 is additionally arranged to send a transaction identifier, K1 , to the server 108.
  • the server stores the received SUID and transaction identifier K1 in a database 112 and sends in reply a signed copy of the transaction identifier K1 (SIGN(K1)) to the POS terminal 3.
  • the modifier module 106 within the POS terminal 3 is arranged to send the signed identifier to the printer 5 for supply to the user.
  • the signed identifier is printed as a two dimensional barcode 126.
  • the server classes the SUID as being in state A.
  • the user 120 scans the printed signed identifier (SIGN(K1)) using their user computing device 128, e.g. a smart device such as a smartphone or tablet that comprises suitable software and image capture features.
  • the user computing device will be associated with a device identifier (user-ID) and the computing device 128 is arranged to send both the user-ID and the scanned barcode 126 data (i.e. data corresponding to the signed transaction identifier, SIGN(K1)) to the server 108.
  • the user uses their computing device (smartphone, tablet etc) to use the feedback system 104.
  • the user-ID that is associated with their user profile within the feedback system 104 equates to their computing device's unique identifier (e.g. an IMEI number).
  • a user may use a feedback program client application module 1 10 (which may be installed on their computing device or accessed on any computing device, e.g. via a browser) to complete a more tradition signup process to the feedback system.
  • the user-ID would be an account ID generated by the feedback system (108, 110, 11 1 , 112).
  • the server 108 is arranged to store the user-ID in the database 112 along with the customer identifier (SUID) and transaction identifier (K1).
  • SUID customer identifier
  • K1 transaction identifier
  • Stage 2 of the process corresponds to the user indicating that they wish to utilise the feedback system.
  • the server 108 has sufficient data associated with the user 120 to open populate a customer profile.
  • the hashed transaction card identifier (SUID) is moved from state A to state B at the end of this stage to indicate that the user 120 has indicated a desire to join the system.
  • the scanning of the barcode 126 by the user 120 in stage 2 may be associated with an expiry period.
  • the server 108 may, on receipt of the SUID and K1 data in stage 1 , set an expiry period within which the user should perform stage 2 in order to continue with the process of establishing a customer profile.
  • stages 3 and 4 represent a confirmation process to double check that the user wishes to sign up to the system and to prevent or reduce the instance of fraudulent uses of the feedback system.
  • stages 3 and 4 in Figure 11 are similar to stages 1 and 2.
  • alternative confirmation processes may be used. For example following the completion of stage 2 a user may receive a request from the server to enter information that would only be known to the owner of the unique user identifier (for example the expiry date of a transaction card and/or a complete transaction card or loyalty card number).
  • a user may be allowed to register with the feedback system using stages 1 and 2 only but may be subject to periodic confirmations where they are required to follow the process of stages 1 and 2 again. This could be done on a periodic time interval or after a given number of transactions.
  • a further transaction and subsequent scanning stage is applied. Therefore in stage 3 a further transaction occurs using the same transaction card (therefore the same customer identifier SUID is generated for transmission to the server 108).
  • the SUID sent to the server 108 from the POS 3 is accompanied by a second transaction identifier K2 and the server 108 is arranged to store the second instance of the SUID and identifier K2 in the database 112.
  • the server 108 is then arranged to send a confirmation message 130 containing a signed copy of the transaction identifier K2 back to the POS 3 (i.e. the server returns SIGN(K2)).
  • the POS 3 is arranged to send the signed transaction identifier SIGN(K2) to the user, e.g. via the printer 5 and a further barcode 132.
  • the server 108 may again associate an expiry period within which the user should perform stage 4.
  • stage 4 the user scans the barcode 130 and sends this via their user computing device 128 to the server.
  • the user computing device therefore sends SIGN(K2) along with its own identifier, user-ID, to the server which can check that the user-ID received in stage 4 matches the user-ID in stage 2 and that the SUID used in stage 1 matches that used in stage 3. If all the information corresponds then the server 108 updates the SUID to stage C (confirmed) and creates an active customer profile in the database.
  • the profile comprises an association between the user's transaction card (represented by the SUID) and the user's computing device (represented by user-ID). It is noted that further transaction cards used by the user may be associated with this profile in the same manner such that the user's computing device (user-ID) is associated with multiple transaction cards.
  • the user's computing device may comprise an instance of the client application module 1 10 shown in Figure 9.
  • Figure 12 shows the process of Figure 1 1 mainly from the point of view of the server 108.
  • step 150 the process begins and in step 152 the POS terminal 3 authenticates token P.
  • Token P may comprise a transaction card PAN and step 152 therefore represents the transaction card within a transaction authorisation process.
  • step 154 the server 108 receives the SUID, the customer identifier that resulted from the cryptographic hashing of the token P on the payment terminal 3.
  • the SUID is received from the interceptor module 102.
  • step 156 the server 108 checks the state of the SUID as stored in the database 112. If the SUID corresponds to a transaction card that has already been registered then the database entry for the SUID will indicate it is in state C. The server 108 may then retrieve the associated customer profile from the database 112.
  • the SUID will be linked in the customer profile with the user's computing device ID, i.e. the user-ID will be the identifier of the user's computing device (e.g. an IMEI number).
  • the user may have formally registered with the system via a traditional log in and registration form.
  • the user-ID may be comprise a unique reference number generated by the server 108.
  • the server 108 is arranged in step 158 to retrieve the user-ID and the process either ends in step 160 or transfers to a further process for storing the user's transaction history [as described in relation to Figure 14 below]
  • the server 108 checks the state of the SUID stored in the database 112. If the SUID is in state A (indicating that this is the first time that the server 108 has encountered this particular transaction card) or state B (indicating that the transaction card has been encountered before but has not been confirmed) then the server moves to step 162.
  • the POS terminal 3 will assign an arbitrary transaction identifier to each transaction and sends this in stage 1 of Figure 11 to the server 108 along with the SUID.
  • the server 108 determines the transaction identifier (K) and associates this with the SUID in the database 112.
  • step 164 the server 108 sends the transaction identifier back to the user. As noted in Figure 1 1 this may be achieved by including a barcode within the transaction receipt. It is also noted that the identifier K may be signed by the server 108 to indicate that it has originated from an authentic source (the server 108).
  • step 166 the server 108 receives a communication from the user which contains the transaction identifier K and a user-ID (e.g. an identifier of the user's computing device).
  • a user-ID e.g. an identifier of the user's computing device
  • step 168 the server 108 extracts the transaction identifier K and, in step 170 checks if it is valid.
  • step 172 the server 108 may determine that a fraudulent attempt is being made to register with the feedback system.
  • the address of the user sending the user-ID may be recorded and the request may be discarded.
  • step 174 the server 108 determines if the transaction identifier K has expired. If the identifier K has expired then the server moves to step 176 and notes the expiry of the identifier and then proceeds to end the loyalty sign-up process in step 178.
  • step 180 the server 108 searches the database 112 to determine the SUID is associated with the transaction identifier K. It is noted that the SUID in step 180 will be in stage 2 of the registration process shown in Figure 1 1 (the SUID in step 154 above will be in stage 2 of the registration process shown in Figure 11).
  • step 176 the server 108 moves to step 176 and then terminates the signup process in step 178. If an SUID exists then in step 184 the state of the SUID is determined. If the SUID is in state C then in step 186 the server 108 determines that the SUID has already been registered and confirmed and the sign-up process ends in step 188. If the SUID is determined to be in state A or sate B then the server then searches, in step 190, to see if a previous transaction identifier, K', is associated with the same SUID.
  • step 194 the user-ID received in step 166 is associated with the transaction identifier K.
  • the state of the SUID is then updated to state B in step 196 and the process terminates at step 198.
  • the process requires a user to undertake another transaction with the same transaction card (i.e. the same SUID) in order to complete the signup process and move the SUID to state C.
  • step 192 a previous transaction identifier K' is found then the user identifier associated with the previous transaction identifier is retrieved in step 200 (i.e. retrieve user-ID').
  • step 202 the user-ID received in step 166 is compared to the previous user-ID' retrieved from the database 112.
  • step 204 the server 108 changes the SUID state to state C and then the signup process completes in step 206. If the user identifiers do not match (user-ID ⁇ user-ID') then one or other of the transactions may be fraudulent. Alternatively, the user may have used different devices to perform the stage 2 and stage 4 scanning in Figure 11.
  • the loyalty system 104 may be arranged to issue a one time password to the user for manual entry by the user. This alternative arrangement is shown in Figure 13.
  • Figure 13 shows a user making a transaction via an online store (web shop 3).
  • the online store however may be regarded as functionally similar to the POS terminal of Figure 11 and both the POS terminal and online stores are regarded as examples of payment terminals within the context of embodiments of the present invention.
  • the server 108 issues a one-time password 210 back to the user in stage 1.
  • This password may be entered in stage 2 into the user's computing device via the feedback client application 110.
  • the password may be entered via a browser 212.
  • the PDQ/POS terminal may, during the transaction such as before the PIN entry stage, ask the customer if they want to register with the loyalty program.)
  • the process described above in relation to Figures 10 to 13 establish a customer profile within the feedback system in which a user-ID (either in the form of a computing device's unique identifier or a system generated identifier) is associated with a transaction card (via the SUID corresponding to that transaction card).
  • the processes of Figures 10 to 13 may be repeated for multiple transaction devices such that the user-ID is associated with multiple SUIDs.
  • FIG 14 shows the process of capturing further transactions once an association between a user-ID and an SUID has been made.
  • the subsequent transaction capture begins and at step 222 the server 108 receives details of a transaction from a payment terminal 3.
  • the server 108 checks to see if a token P is present within the data sent from the payment terminal 3.
  • the token P may be a personal account number (PAN) of a transaction card or a loyalty card number.
  • PAN personal account number
  • this token P is received in the form of a cryptographically hashed version of the token (the SUID discussed above).
  • a token P/SUID may not be present in the transaction data received from the payment terminal 3 in cases where the user has concluded the transaction using cash.
  • step 226 the server 108 retrieves the SUID from the transaction data and checks the state of the SUID. In the event that the SUID is in state A or state B then the server 108 may output a recommendation that the SUID should be associated with a user-ID. The process then ends in step 230.
  • step 232 the server 108 retrieves the user- ID associated with the SUID.
  • step 234 the transaction details received from the payment terminal 3 are associated with the user-ID and stored in the database 112. The process then ends in step 236.
  • step 238 an arbitrary key K is assigned to the transaction (T).
  • a digitally signed copy of the key K is then generated in step 240 and sent to the user (e.g. via the printer receipt).
  • the user may scan the digitally signed copy of the key K that appears on the receipt.
  • the key may be embodied within a two dimensional barcode on the receipt that the user can scan with their computing device.
  • step 244 the scanned image and the user's user-ID are sent to the server 108.
  • the server 108 receives the transaction identifier K and user-ID and checks, in 247, if the key K is valid. If the key is not valid then in step 248 the server 108 flags the transaction as potentially fraudulent.
  • the server checks if the key K has expired. If it has expired then the server notes this in step 252 and then ends the process in step 254.
  • step 256 searches for transaction data associated with the key K (e.g. transaction data that has been sent in step 242 from the user when they scan the receipt for the transaction T).
  • transaction data associated with the key K e.g. transaction data that has been sent in step 242 from the user when they scan the receipt for the transaction T.
  • step 252 the server moves via step 252 to terminate the process in step 254.
  • step 260 the server 108 associates the transaction T with the user-ID and then the process terminates in step 262 until further data is provided.
  • the receipt delivered to the user may comprise a one time password which may be entered by the user in place of scanning a barcode in step 242.
  • the feedback Server 108 may be used to receive and process feedback events received from users of the system. Feedback events may be received anonymously based on an identifier 132 present on a transaction record (e.g. a barcode printed on a transaction receipt) or me be submitted in such a manner that they are associated with a User-ID.
  • a transaction record e.g. a barcode printed on a transaction receipt
  • Figure 15 shows an embodiment of the process of submitting a feedback/review related to a transaction.
  • the process begins in step 270 with a transaction on a payment terminal 3.
  • the transaction data associated with the transaction is associated with a user-ID stored in the database 112 that is in communication with the feedback server 108.
  • a user accesses their transaction history and chooses a particular transaction event from their history. It is noted that the user might access their transaction history that is stored in the database 112 by means of a feedback application module 1 10 on their user computing device.
  • the application module 110 may interact with the feedback server 108 (e.g. via a telecommunications network/the Internet) which can in turn retrieve the transaction history associated with that user.
  • step 276 the user submits a feedback event to the server 108.
  • a feedback event may be submitted via the feedback application module 1 10 on their computing device.
  • the user may access their transaction history and submit feedback events via a web browser interface.
  • step 278 the user is presented with the option of submitting further feedback events. The process either then returns to step 274 or ends in step 280.
  • FIG 16 is a representation of the user profile that is generated and used as described above in relation to Figures 10 to 16.
  • the user profile 330 comprises a user-ID 332 (which as described above may relate to a user's computing device's identifier or may be generated by the feedback system 104).
  • the user-ID 332 is associated with three different transaction cards 334 as represented by the cryptographically hashed values SUID1 , SUID2 and SUID3. A number of transactions 336 are shown. It is noted that transactions T1 through T6 are associated with one of the transaction cards 334. Transactions T7 and T8 however represent cash transactions.
  • Transactions 336 may be associated with one or more transaction events 338. Each transaction event 338 may in turn be associated with a review event 340.
  • Transaction T1 is associated with transaction events TE1 and TE2 (e.g. T1 may relate to a restaurant visit and TE1 may correspond to a particular dish ordered at the restaurant as part of transaction T1. TE2 may relate to another dish).
  • Transaction T3 is related to transaction event TE3 and transaction T7 is associated with transaction event TE4.
  • each of transaction events TE1 - TE4 are associated with a corresponding review event 340.
  • a user may write and submit one or more feedback events to the server 108.
  • Analysing users' profiles 330 enables the server 108 to provide the following services: 1. Give recommendations on search input;
  • An index of a given Customer Profile may be calculated and used to measure similarity between different Customer Profiles. Services such as recommendations or improved search result may be built on top of indexes.
  • a search request e.g. a search for a specific product or service provider or if the user wants to get ranking of products taking into account some conditions
  • the search query is translated into common query language and is executed on the search server 108.
  • the server 108 may comprise a query interpreter module in order to process the search request and the query interpreter module may access the Thesaurus 1 1 1.
  • QR-codes As an alternative one-time passwords or any other convenient identifier may be used instead of QR-codes.
  • Scenario 1 Secure SUID and User-ID Association Via Qr-Code using Point of Sale Terminal and Printer
  • a user enters into a transaction using a credit card at a POS Terminal 3.
  • the credit card may then be associated with a user-ID within a user profile in accordance with the method described in relation to Figures 1 1 and 12 above.
  • Embodiments of the present invention permit a user to leave an anonymous feedback event.
  • a customer buys a Caesar's salad, a sirloin steak, and a cheesecake at restaurant R.
  • the customer pays by cash.
  • a receipt with the QR-Code that is associated with the transaction data is then printed.
  • the customer scans this QR-Code with their mobile phone and an application installed on the mobile phone (e.g. the mobile application module 1 10) downloads transaction data from the database 112 (via the server 108) and presents it on the screen of the user's mobile device.
  • the application module 1 10 is arranged to allow the user to rate each item of the transaction.
  • the user rates the sirloin steak 8 out of 10 points, and the cheesecake 5 out of 10.
  • the customer writes a review about the cheesecake.
  • the customer rates the restaurant 7 out of 10 points and submits this feedback event to the server 108.
  • the QR-Code becomes invalid in the sense that it will be rejected by the feedback system..
  • the application module 1 10 may include data relating to the location of the mobile device (obtained for example via a GPS unit on the device) at the time that the receipt was printed. In this manner the server 108 may be able to accept the anonymous feedback event and cross check the user's location at the time of the transaction to determine whether the view may be fake.
  • Embodiments of the present invention permit a user to leave a non-anonymous review.
  • a customer buys a Caesar's salad, a sirloin steak, and a cheesecake at restaurant R.
  • the customer pays by card.
  • a receipt with a QR- Code that is associated with the transaction data is printed.
  • the customer scans this QR- Code with their mobile computing device (mobile phone) and an application module 110 installed on the mobile phone asks to login to the reward system. If the login is successful, the application downloads transaction data from the DB and presents it on the screen and associates this transaction with the customer's user-ID.
  • the user is presented as entering login information in order to access the feedback system. This may comprise a traditional username and password entry.
  • the login process may be transparent to the user and may comprise the application module 1 10 supplying some identifying information relating to the mobile device, e.g. telephone number, IMEI number, to the server which can then access the user's transaction history]
  • the user is then able to rate each item of the transaction.
  • the user rates the sirloin steak 8 out of 10 points, and the cheesecake 5 out of 10.
  • the customer writes a review about the cheesecake.
  • the customer rates the restaurant 7 out of 10 points and submits this feedback event to the server 108.
  • the QR-Code is marked as used by the server so that it cannot be scanned again as part of submitting another feedback event.
  • Embodiments of the present invention permit a user to leave a non-anonymous review without the need to scan a code.
  • a customer user enters into a transaction using a card which has been registered with the server 108 and which there is an associated User-ID.
  • the user may, via a feedback application module 110 on their computing device, directly access their entire transaction history and then select a particular transaction in order to enter a feedback event without scanning any QR-Codes (or other codes) at all.
  • Scenario 5 Searching Reviews on a Specific Product
  • Embodiments of the present invention may also permit a user to search for reviews on a specific product.
  • a user may want to find out best places for Caffe Latte.
  • a keyword "latte” may be entered as a search request to the feedback system (for example the user may be present with a search option via the feedback application module 110 or via a web browser interface to the server 108).
  • the server 108 may send this keyword to the Thesaurus 11 1 and translates it into a common form "Caffe Latte”.
  • the search on keyword "Caffe Latte” is executed to find all reviews on Caffe Latte. If there are no results for "Caffe Latte", then a keyword that represents more general idea may be used, that is "Coffee”.
  • the system presents search results to the user.
  • Embodiments of the present invention may also permit the feedback system to provide recommendations to a user.
  • a customer A may log into the system.
  • the server 108 may then analyze transaction history, reviews and ratings and select a sub-set of customers S based on some similarity. As an example, if customer A and some customer B have similar taste, which may be detected by looking for a common set of restaurants they have been to and/or by looking at the review they have given and checking if they correlate. In this way the server 108 may detect similar customers. If customer B has provided good feedback events or a number of positive feedback events from a particular location that customer A has never been to, the server 108 may recommend customer A to try out these locations (e.g. restaurants).
  • Scenario 7 Aggregating Potential Loyal Customers
  • a restaurant R may be interested in discovering a set of potentially loyal customers but who have never been to the restaurant.
  • the restaurant marketing manager may define a threshold, for instance 8 points out of 10, according to the rating system used by the feedback system.
  • the server 108 may then select a set S of customers who gave 8 points or more to restaurant R. Using this set S, the server 108 may search for a further set of customers T who have similar taste (see Scenario 6) but have never been to restaurant R. Since customer from set T share similar taste to customers from set S, they may also be viewed as likely to give a good rating to restaurant R. Therefore the marketing manager may decide to give some offers to these customer to encourage them to try out restaurant R. In this way they can make their reviews and rating even more accurate and reliable and attract new potentially loyal customers.
  • the server 108 may handle the routing of offers from the marketing manager to the users in set T and additionally may not provide any contact details of these users to the restaurant.
  • Scenario 8 Search Result Improvement using Customer Similarity
  • Embodiments of the present invention may also permit a user to search for feedback events from other users of the system.
  • a customer A may log in to the system and enter a keyword "Best Pizza in Oxford" in the search window of the system.
  • the set S of reviewers that match the search criteria may be selected by the server 108.
  • the system can take advantage of customer's history and profile to detect reviewers with similar taste.
  • the system can analyze transaction history, reviews, ratings, etc. and the search result may be sorted according to similarity, i.e. reviews from the customers with who have highest similarity with customer A are given on top.
  • the Offer Server may generate an actual offer that is associated with the customer who has written the review.
  • the offer may comprise a code that the user can present during a transaction to get a discount.
  • the server 108 may detect the customer that has been associated with the review. The server may then be able to determine the feedback providing customers that are regarded as influential in the sense that for these reviewers, other customers tend to click on the offer links by their reviews.
  • Identifying influential customers may be very valuable for marketing purposes.
  • a method as claimed in any preceding Clause comprising receiving further user-related data comprising identification data associated with the unique user identifier; sending a further server authentication message to the user in dependence on the further user related data; receiving a further registration message from the user, the message comprising the further authentication message; confirming the user profile in response to receiving the further registration message.
  • the further user-related data comprises a further transaction identifier relating to a further transaction.
  • the unique user identifier comprises an account number associated with a user loyalty card.
  • the identification data received by the server computer comprises a cryptographically hashed version of the unique user identifier.
  • a method as claimed in Clause 11 wherein the server computer is arranged to update the status flag to a confirmed status upon receipt of a further registration message.
  • the authentication message comprises a digitally signed copy of the transaction identifier and wherein the server computer verifies the validity of the transaction identifier received in the registration message.
  • a method as claimed in Clause 17, wherein the image comprises a two dimensional barcode. A method of processing transaction data in dependence a user profile, the user profile having been established according to the method of any one of Clausesl to 18, the method comprising:
  • a method as claimed in Clause 19 comprising comparing the transaction history of the user against a stored transaction offer, the transaction offer being associated with an issuance condition, and issuing the offer to the user in the event that the issuance condition is satisfied by the transaction history of the user.
  • a method as claimed in Clause 20 or Clause 21 wherein the transaction offer is sent to a payment terminal.
  • a server computer arranged to establish a user profile, the user profile being associated with a unique user identifier used during a transaction made by a user, comprising:
  • the input is arranged to receive user-related data comprising identification data associated with the unique user identifier
  • the processor is arranged to generate a server authentication message in dependence on the user related data and the output is arranged to send the server authentication message to the user
  • a server computer arranged to process transaction data in dependence a user profile, comprising a server computer as claimed in Clause 24 wherein the input is arranged to receive transaction data related to a user transaction and the processor is arranged to store the received transaction data and associate the received transaction data with the user profile to create a transaction history for the user.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

La présente invention concerne un procédé de traitement, au niveau d'un ordinateur serveur, d'événements de rétroaction se rapportant à des transactions, ledit procédé comprenant les étapes consistant à: recevoir, en provenance d'un terminal de paiement, des données de transaction relatives à une transaction; recevoir d'un utilisateur un événement de rétroaction relatif à la transaction; associer l'événement de rétroaction aux données de transaction; stocker l'événement de rétroaction dans une mémoire de données.
PCT/GB2014/052958 2013-09-30 2014-09-30 Méthode de stockage de contenus WO2015044693A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB1317304.2A GB201317304D0 (en) 2013-09-30 2013-09-30 Customer feedback gathering and review system using payment terminals and customer's internet enabled device
GB1317304.2 2013-09-30

Publications (1)

Publication Number Publication Date
WO2015044693A1 true WO2015044693A1 (fr) 2015-04-02

Family

ID=49585075

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2014/052958 WO2015044693A1 (fr) 2013-09-30 2014-09-30 Méthode de stockage de contenus

Country Status (2)

Country Link
GB (1) GB201317304D0 (fr)
WO (1) WO2015044693A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018011322A1 (fr) * 2016-07-12 2018-01-18 Ingenico Group Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
US20180082312A1 (en) * 2016-09-21 2018-03-22 Ford Global Technologies, Llc Feedback for Vehicle Dealership or Service Providers
US20230162230A1 (en) * 2021-11-24 2023-05-25 Capital One Services, Llc Systems and methods for targeting content based on implicit sentiment analysis

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120130794A1 (en) * 2010-06-13 2012-05-24 Bnc Ventures B.V. Method and System for Managing Customer Relationships
WO2012144142A1 (fr) * 2011-04-22 2012-10-26 Sony Corporation Appareil de traitement d'information, procédé de traitement d'information, et logiciel
DE102011018689A1 (de) * 2011-04-26 2012-10-31 Baumann Brützel Ramke GbR (vertretungsberechtigter Gesellschafter: André Christoph Baumann, 30169 Hannover) Kassenanordnung
US20120316950A1 (en) * 2011-06-10 2012-12-13 Jeffrey Laporte System and method for augmentation of retail pos data streams with transaction information
WO2013008041A1 (fr) * 2011-07-14 2013-01-17 Ecrebo Limited Procédé d'amélioration de systèmes de point de vente

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120130794A1 (en) * 2010-06-13 2012-05-24 Bnc Ventures B.V. Method and System for Managing Customer Relationships
WO2012144142A1 (fr) * 2011-04-22 2012-10-26 Sony Corporation Appareil de traitement d'information, procédé de traitement d'information, et logiciel
DE102011018689A1 (de) * 2011-04-26 2012-10-31 Baumann Brützel Ramke GbR (vertretungsberechtigter Gesellschafter: André Christoph Baumann, 30169 Hannover) Kassenanordnung
US20120316950A1 (en) * 2011-06-10 2012-12-13 Jeffrey Laporte System and method for augmentation of retail pos data streams with transaction information
WO2013008041A1 (fr) * 2011-07-14 2013-01-17 Ecrebo Limited Procédé d'amélioration de systèmes de point de vente

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018011322A1 (fr) * 2016-07-12 2018-01-18 Ingenico Group Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
FR3054055A1 (fr) * 2016-07-12 2018-01-19 Ingenico Group Procede de traitement d'au moins une donnee de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
US11010805B2 (en) 2016-07-12 2021-05-18 Ingenico Group Method for processing at least one piece of payment means data, corresponding payment terminal and computer program
US20180082312A1 (en) * 2016-09-21 2018-03-22 Ford Global Technologies, Llc Feedback for Vehicle Dealership or Service Providers
US20230162230A1 (en) * 2021-11-24 2023-05-25 Capital One Services, Llc Systems and methods for targeting content based on implicit sentiment analysis

Also Published As

Publication number Publication date
GB201317304D0 (en) 2013-11-13

Similar Documents

Publication Publication Date Title
US20120084135A1 (en) System and method for tracking transaction records in a network
US20090271322A1 (en) Electronic receipt system and method
US20090271265A1 (en) Electronic receipt system and method
EP3989148A1 (fr) Système d'analyse et de traitement de reçu numérique
US20180005200A1 (en) Generation and delivery of digital receipts based on user preferences and transaction related data
US8429009B2 (en) Universal affinity system
US20160239860A1 (en) A method of enabling a customer profile
CN107103458A (zh) 信息处理装置及电子票据系统
US20170286992A1 (en) System and method for coded transaction processing
JP2020512618A (ja) 情報をデータベースに登録するための改良された方法、システム、及びデバイス
US20160155107A1 (en) Improved performance in interaction systems
US20140032312A1 (en) Systems, methods, and computer program products for providing offers to mobile wallets
WO2015044693A1 (fr) Méthode de stockage de contenus
US20030033208A1 (en) Method and system for communicating using a user defined alias representing confidential data
US11238481B1 (en) Methods and systems for providing a best price guarantee
US9105022B1 (en) Methods and systems for providing a best price guarantee
JP2006236297A (ja) ネットワーク型クーポン発券システムおよびネットワーク型クーポン発券装置のクーポン発券方法
US20230205825A1 (en) Extracting webpage features using coded data packages for page heuristics
US10592909B2 (en) Apparatus, system, and method for universal tracking system
JP5371211B2 (ja) ポイント管理装置、ポイント管理方法、およびポイント管理プログラム
US20170076314A1 (en) Multi-platform data gathering and rewards administration for automated library systems
JP2002245316A (ja) ポイント還元方法、センタ装置、店舗装置、及びポイント還元プログラム
WO2015008095A2 (fr) Système et procédé de liaison d'enregistrement de données
WO2015019115A1 (fr) Système et procédé d'émission d'offre
WO2013170101A2 (fr) Système de traitement de transactions sans fil et sans contact

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: 14796836

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: 14796836

Country of ref document: EP

Kind code of ref document: A1