GB2516309A - Electronic receipts system and method - Google Patents

Electronic receipts system and method Download PDF

Info

Publication number
GB2516309A
GB2516309A GB1312938.2A GB201312938A GB2516309A GB 2516309 A GB2516309 A GB 2516309A GB 201312938 A GB201312938 A GB 201312938A GB 2516309 A GB2516309 A GB 2516309A
Authority
GB
United Kingdom
Prior art keywords
transaction record
data
electronic receipt
parser
retailer
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
GB1312938.2A
Other versions
GB201312938D0 (en
Inventor
Andrew Peter Lyon Carroll
Clive Andrew Whistler Baker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PAPERLESS RECEIPTS Ltd
Original Assignee
PAPERLESS RECEIPTS Ltd
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 PAPERLESS RECEIPTS Ltd filed Critical PAPERLESS RECEIPTS Ltd
Priority to GB1721221.8A priority Critical patent/GB2555345A/en
Priority to GB1312938.2A priority patent/GB2516309A/en
Publication of GB201312938D0 publication Critical patent/GB201312938D0/en
Publication of GB2516309A publication Critical patent/GB2516309A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/209Specified transaction journal output feature, e.g. printed receipt or voice output
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/047Payment circuits using payment protocols involving electronic receipts
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07GREGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
    • G07G1/00Cash registers
    • G07G1/0009Details of the software in the checkout register, electronic cash register [ECR] or point of sale terminal [POS]
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07GREGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
    • G07G1/00Cash registers
    • G07G1/0018Constructional details, e.g. of drawer, printing means, input means

Landscapes

  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

A method of enabling a Point of Sale (POS) 101 system to provide electronic receipts using existing software. The method involves identifying an output destination e.g. OPOS enabled or WindowsTM printer 102 or serial port, of a transaction record sent by the POS software in an unknown format. A data reader is configured as middleware based on the output, e.g. by redirecting data sent to the printer or using a serial port monitor, to obtain a copy of the transaction record. Where available customer identity information is collected and, when this is available, the transaction record is communicated to a parser which converts the record into an electronic receipt of a known format. The receipt is correlated with the customer identity information and stored in a data store for viewing by the customer and/or retailer. The data reader may forward the transaction record to a printer if a paper receipt is required. The electronic receipt may be accessible via a web browser 307-308 or app on a mobile device 306. The parser may be unique to the retailer or POS terminal and the system may include a parser builder arranged to initially generate the parser (Figures 10a-c), identify regions in the transaction record data corresponding to states in a state machine and/or identify similar previous transaction records in a library. The parser may check electronic receipt data for correctness, the builder refining the parser if errors are detected. Thus it is not necessary to know the format of the data created by the POS system in order to use the method, allowing electronic receipts to be generated using existing POS equipment without the co-operation of the POS supplier in providing information about the software used.

Description

ELECTRONIC RECEIPT SYSTEM AND METHOD
BACKGROUND
Technical Field of the Invention
The invention is in the field of Point of Sale (POS) systems operated by retailers, and particularly relates to providing customers with electronic receipts. The invention concerns providing an electronic receipt facility for existing POS software.
Description of Related Art
It is common for retailers to use some form of Point of Sale (POS) computer system to manage transactions with customers. A transaction is the exchange of goods or services for money. Information relating to the sale is logged for the benefit of the retailer and the customer is given a paper receipt as evidence of the sale for their own accounting purposes and to preserve the right to return goods.
However, paper receipts pose a problem, both for the retailer and the customer. The customer must have a filing system so that the receipt can be retrieved if necessary, sometimes many months after the purchase. Given that this may mean storing thousands of paper receipts, this represents a significant administrative burden for the customer. For the retailer, the problems presented by paper receipts include the expense of the paper for the receipts itself; a retail outlet with five tills can use up to a tonne of receipt paper a year. Receipt paper also presents a significant environmental problem because the chemicals used to produce the thermally reactive coating prevent the paper from being recycled in the normal way.
Electronic receipts offer a solution to these problems. An example of a known electronic receipt system is described in PCT patent application number WO 2012/1 43547, where an electronic receipt card is used by the consumer when transacting with a retailer, which allows the retailer to generate an electronic transaction receipt.
Another example of a known system is given in GB2450220B which describes a system and method for managing electronic receipts whereby, when a user makes a purchase of goods or services an electronic copy of the purchase receipt data is generated. This data is then assigned a user identification code to create user correlated purchase receipt data. This receipt data is stored where it may be accessed by a user.
However, retrofitting these services to existing FOS software requires a knowledge of the output formats used by the P05 software itself. This in turn requires the cooperation of the P05 software provider, to disclose formats or more preferably to provide an integration solution in the P05 software itself. This is a barrier as P05 software provider cooperation cannot be guaranteed and even if such help were available the integration of the electronic receipt service with an individual retailer would be slowed to the extent that it would not make economic sense to provide the service at all.
SUMMARY OF THE INVENTION
An embodiment of the present invention is therefore a method of providing an electronic receipt facility, or service, for the POS system of at least one retailer, wherein said POS system or systems are arranged to record customer-retailer transactions, the POS system or systems including at least one computer terminal running POS software, wherein the POS software is arranged to route a record of a transaction in the form of transaction record data in an unknown data format to one or more output destinations within the existing P05 system on completion of a customer-retailer transaction, the method comprising the steps of, for the or each POS terminal of the or each retailer, identifying an output destination, configuring the data reader in dependence on the output destination to obtain a copy of the transaction record data, collecting customer identity information for transactions when the customer identity information is available, and for each transaction where customer identity information is available, using the data reader to obtain a copy of the transaction record data routed to the identified output destination, communicating the transaction record data to a transaction record parser, said transaction record parser being arranged to convert the transaction record data into electronic receipt data of a known format, correlating the electronic receipt data with the user identity information and communicating the correlated electronic receipt data and the customer identity information to a data store, and making the electronic receipt data in the data store available to view by the retailer and/or the customer.
The electronic receipt service may be integrated with existing POS software without reference to the POS software provider, for example for data structures used or requesting formatted output feeds. This is done by identifying a suitable transaction record data output destination, which uses knowledge of the P03 system set-up readily obtained onsite or remotely, and converting the unstructured transaction record data to electronic receipt data using the transaction record parser.
A unique retailer identity may be given to the or each retailer and a unique transaction record parser used for the or each retailer. Retailers generally customise their receipt formats to suit their business and therefore a unique transaction record parser may be required for each retailer to handle the diversity of receipt formats.
The transaction record parser for each retailer may be created using a first transaction record received from the retailer, and then stored for parsing subsequent transaction record data from the retailer. Transaction record parsers are created for each retailer using the first transaction record as a starting point and subsequent transaction records used to refine the parser.
Subsequent transaction record data from the or each retailer may be used to refine the unique transaction record parser. It is possible that a P03 terminal produces different format receipts depending on the nature of the transaction and that a single transaction will not exemplify all of the receipt formats possible for that retailer.
Therefore subsequent transaction records are checked for correctness and if inaccuracies are found the transaction record is communicated back to the parser builder to refine the transaction record parser. This process can be applied to all transaction receipts so that any changes made by a retailer to their receipt format will be picked up and the parser modified accordingly.
A unique parser may be created for each POS terminal, for example because a retailer has different departments which issue different format receipts.
The first transaction record data from a retailer may be analysed for similarity with previous transaction record data from other retailers and the transaction record parser associated with the previous transaction record data is used as a starting point to create the parser for the retailer. This can save time in setting up the transaction record parser.
The POS software may be arranged to route transaction record data to an OPOS enabled printer. If so the OPOS enabled printer is identified as the output destination and transaction record data is redirected from the OPOS enabled printer to the data reader. It a paper receipt is required the transaction record data may be torwarded from the data reader to the OPOS enabled printer. Printing may be interrupted by opting for the print data not to be forwarded on to the printer. The POS software may be arranged to identify the OPOS printer by reference to an address stored in a registry on the POS terminal, the method including the step of copying the address of the OPOS printer in the registry and changing it to an address for the data reader. The transaction record data may be routed from the data reader to the address of the OFOS printer copied from the registry if a paper receipt is required. The OPOS printer capability may be detected and the data reader configured automatically.
The P05 software may be arranged to route transaction record data to a print driver which has the capability to print to a file, the method may include the step of identifying the output destination as a print-to-file enabled print driver, setting the print driver to print to a file and copying the transaction record data from the file.
The POS software may be arranged to send transaction record data to a serial port, the method may include the step of identifying the serial port as the output destination, installing a serial port monitor and copying the transaction record data sent over the serial port detected by the serial port monitor.
In another embodiment, an electronic receipt system for providing an electronic receipt capability to the POS system of at least one retailer may be provided. The POS system or systems may be arranged to record customer-retailer transactions and comprise at least one computer terminal running POS software, the P03 software arranged to route a record of a transaction in the form of transaction record data in an unknown data format to one or more output destinations within the existing POS system or systems on completion ot a customer-retailer transaction, the electronic receipt system comprising, for the or each retailer; an output destination selector for identifying one of the output destinations, a data reader configurable in dependence on the identified output destination to read data routed to the selected output destination, a customer identity collector for collecting customer identity information, a transaction record parser in communication with the data reader for converting the transaction record data into electronic receipt data of a known format, a data store in communication with both the transaction record parser and the customer identity collector, said data store arranged to correlate and store the electronic receipt data with the customer identity information, a data access unit for making the electronic receipt available to view by the retailer and/or the customer.
The system may include a transaction record parser builder, the parser builder arranged to receive a first transaction record data set from the or each retailer to use as the basis for the transaction record parser. The transaction record parser may include a state machine and the transaction record parser builder may be arranged to identify regions in the transaction record data, which correspond to states in the state machine.
The transaction record parser may be arranged to check the electronic receipt data for correctness and the transaction record parser builder arranged to refine the transaction record parser if transaction record data is found to have been incorrectly parsed.
The transaction record data formats may be arranged to be stored in a library and the transaction record parser builder may be arranged to refer to the library and identify previous transaction record data with similar characteristics. The transaction record parser builder may be arranged to use the transaction record parser associated with the previous transaction record data as a starting point to create the transaction record parser.
The transaction record output destination may include an OPOS printer having an address identified by the POS software from a registry, the electronic receipt system including means for changing the address in the registry to the address of the data reader. The system may include means for directing the transaction record data from the data reader to the OPOS printer identified by the address in the registry to provide a paper receipt and the system may have means for detecting OPOS printer capability and configuring the data reader automatically.
The transaction record output destination may be a print driver which has the capability to print to a file, the system may include means to identify the output destination as a print-to-file enabled print driver, and means to set the print driver to print to a file, wherein the data reader may be arranged to copy the transaction record data from the file.
The POS software may be arranged to send transaction record data to a serial port, the system having means to install a serial port monitor and the data reader may be arranged to copy the transaction record data detected by the serial port monitor.
The transaction record parser may be remote from the data reader, whereby the data reader is installed on the P05 terminal and communicates remotely via the internet with the transaction record parser which is located on a remote server.
The data access unit may include a web-enabled access point where customers and/or retailers may access electronic receipts using a web browser. The data access unit may be arranged to transmit electronic receipt data to a mobile device of a customer, who has installed a suitable software application on the mobile device to handle and display the incoming electronic receipt data.
In an embodiment a computer program product for an electronic receipt system is provided which includes computer readable instructions for executing the methods described herein.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the present invention are described below, by way of example only, with reference to the accompanying drawings, in which: Figure 1 a is a schematic view of a simple P05 system which may be employed by a retailer.
Figure lb is a schematic view of the POS software which may be installed on the POS terminal shown in Figure la.
Figure 2a is a schematic view of a more complex POS system which may be employed by a retailer and includes multiple P05 terminals.
Figure 2b is a schematic view of a still more complex POS system which may be employed by a retailer and includes multiple terminals provided in multiple shop locations.
Figure 3 is an overview of an embodiment of the invention when integrated with the simple POS system shown in Figure 1.
Figure 4 is a representation of how an embodiment of the invention is arranged to integrate with the POS software of a POS terminal when the POS software writes transaction record data to an OPOS enabled printer.
Figure 5 is a representation of how an embodiment of the invention is arranged to integrate with the P05 software of a P05 terminal when the P05 software writes transaction record data to a Windows TM enabled printer.
Figure 6 is a representation of how an embodiment of the invention is arranged to is integrate with the POS software of a POS terminal when the POS software writes transaction record data to a serial port.
Figure 7 is a representation of how an embodiment of the invention is arranged to integrate with the P05 software of a P05 terminal when the P05 software writes transaction record data to standard output, i.e. a named pipe.
Figure 8 is a representation of how an embodiment of the invention is arranged to integrate with the POS software of a POS terminal when the POS software writes transaction record data to a database.
Figure 9 is schematic view of the electronic receipt server shown in Figure 3.
Figure 1 Oa is a flow diagram showing how an embodiment of the electronic receipt system is set up for a retailer, including steps executed at a POS terminal of the retailer and at the electronic receipt server.
Figure 1 Ob is a flow diagram showing how the transaction record parser shown in Figure 9 is built.
Figure 1 Oc is a flow diagram showing how an embodiment of the invention operates.
Figure 11 is a flow diagram showing how the electronic receipt system is set up and operated for a customer.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Point of sale (POS) or checkout is the place where a retail transaction is completed.
It is the point at which a customer makes a payment to a retailer in exchange for goods or services. At the point of sale the merchant would use any of a range of possible methods to calculate the amount owing -such as manually entering items and prices, weighing machines or barcode scanners. The retailer will usually provide hardware and options for use by the customer to make payment -such as an EFTPOS terminal. The retailer may also issue a paper receipt for the transaction.
For small and medium-sized retailers, the POS will be customized by sector as different industries have different needs. For example, a grocer will need a scale at the point of sale, while bars and restaurants will customize the item sold when a customer has a special meal or drink request. The modern point of sale will also include advanced functionalities such as inventory, CRM, financials, warehousing, and so on, all built into the P05 software.
Many P05 configurations are of course possible depending on the preference of individual retailers, which could range from a one-till small shop, to a store with many P05 terminals, to large multi-national retailers having many thousands of POS terminals across hundreds of retail outlets. It is an object of the invention to adapt to any such configuration.
Figure 1 a shows a simple Point of Sale transaction handling system, comprising a computer terminal 101, which may be a standard PC with a touch screen GUI interface, running a conventional Operating System environment, for example Windows XPTM. The computer terminal 101 is connected by USB interface to P05 hardware such as a barcode scanner 103 and receipt printer 102, but may also include weighing equipment or other specialist peripherals.
Figure lb shows schematically the software components running on the POS terminal 101. The Windows Operating System provides an environment within which executable programs are able to run. The POS software application 105 is software which includes an interface component for entering information relating to a sale, for example the cost of goods or services but many other types of information may be entered as discussed below. Further information relating to goods or services and sales records may be stored and retrieved from a database 106 which may be local or remote from the POS terminal 101.
POS software is produced by a diverse array of developers and there are a number of communication protocols that have evolved to control peripheral equipment, including EPSON POS, UTC Standard, UTC Enhanced, AEDEX, 1CD2002, CD5220.
P05 software is further customised to suit a particular retail sector, and may be further customised still to suit a specific retailer and therefore the data communicated between P05 software and peripherals or databases can be thought of as unstructured, i.e. that the format of the transaction record data is unknown to a third party. Without intimate knowledge of the data structure that the POS software is output, the data is not directly usable by other software or hardware.
Types of transaction data that a retailer and a customer may wish to record include: * Retailer identification including name, logo, address and other contact details, * POS terminal identification, * Transaction item name and price, including tax details, * Product identity, * Offers, including conditions, rewards, expiry date, * Credit card information.
Other details might be included such as: * Serving person identification, * Time and date of the transaction, * Quantity of each item, * Total price of transaction including tax details.
Of course it may not be possible to identify goods individually, or that services are being provided, or that the POS system is only used for appointment management.
All of these variations can be accommodated with the embodiments of the present invention.
The transaction record may be printed, or recorded in the database 105. Customers often require a record of the transaction for accounting purposes and as evidence when returning goods. This can be provided if necessary by printing a receipt, a hardcopy of the transaction record. Printing of such a receipt is enabled by a print driver component 107 installed on the POS terminal 101. The print driver 107 is customised to suit a specific POS software and printer combination. Figure lb shows an OPOS enabled print driver. OPOS is a standard which was developed to help integrate POS hardware peripherals into the WindowsTM family of operating systems. The barcode scanning functionality is provided by a scanner driver 108.
This may be used to read a product identity directly from a product bearing a barcode, and also to record customer identities or loyalty card. The scanner driver may be OPOS enabled too.
Figure 2a shows a more complex POS arrangement which may be found in a large retail outlet with numerous point of sale terminals 201 a, 201 b etc, each having a printer 202a, 202b, etc and a scanner 203a. 203b, etc. A P05 manager 204 may be provided which is connected to each of the POS terminals to coordinate data flow between the POS terminals. A database 205 may be connected to the POS manager 204 to store transaction records and product or service details. Figure 2b shows a still more complex arrangement where numerous retail outlets 211 a, 211 b, etc each have numerous POS terminals 221a, 221b etc and peripherals (not shown).
A POS manager 204 is provided to manage data flow between the POS terminals and a database 205.
Electronic receipts are much more convenient for a customer to use than paper receipts. Increasing environmental considerations are also driving a move away from paper receipts. Furthermore, electronic receipts offer opportunities for innovative functionality and traceability of customer spending patterns. Electronic receipt systems are known already, but they require the cooperation of POS software providers to provide data structure tables and structured data feeds which would allow receipt data to be imported into a third party receipt management system. However, this is an unrealistic requirement because there is no incentive for POS software developers to make these concessions until an electronic receipt management system has a sufficient user base. Therefore an electronic receipt management system provider could be locked out because they may find it impossible to develop. An embodiment of the present invention overcomes this problem by providing an electronic receipt management system which is able to integrate with any POS system through the intelligent monitoring of unstructured output data and translating this into meaningful structured data that can then be manipulated as required.
Figure 3 shows an overview of the electronic receipt system of an embodiment of the invention. Conventional POS terminal 101 is shown connected to printer 102 and scanner 103. Raw unstructured transaction record data generated by the P05 software running on the P05 terminal 101 is captured by middleware installed on the POS terminal 101 and sent via the internet 304 to a remote electronic receipt server 305 where it is translated into a structured electronic receipt format as described in more detail below. The electronic receipt data may be pushed to a customer's mobile device 306 via the internet 304. The electronic receipt data may also be accessed by the customer using a web browser running on computer 307 to access the electronic receipt server 305. The receipt data generated by a particular retailer may also be accessed by that retailer using a web browser running on computer 308 to access the electronic receipt server 305 and also additional functionality such as preparing offers to be included on future receipts issued by that retailer.
Installation of the electronic receipt service is specific for each retailer and possibly for each POS terminal, because of the many different configurations that exist for P05 systems and receipt formats. To cope with variations in P05 systems a software component called a transaction record capture object is installed on the POS terminal. The transaction record capture object is a configurable data reader which can read and copy data in dependence on the output destination of the transaction record data. The transaction record capture object is able to identify the type of POS system being used and configure itself accordingly. P05 system type is selected in the transaction record capture object from list of available POS system configuration options. Alternatively the transaction record capture object can automatically identify the POS system type by detecting the presence of file types in the POS terminal. Generally, P05 systems fall into five broad groups; 1. POS terminals which print to an OPOS enabled printer.
OPOS printers are generally dedicated receipt printers. P05 software sends data to an OPOS printer by looking up the printer address in the Windows registry. To capture transaction record data sent to an OPOS printer, the transaction record capture object is installed on the P05 terminal as shown Figure 4. The P05 software 105, when printing refers to the Windows registry 108 for the address of the OPOS printer 102. The transaction record capture object 401 intervenes in the OPOS print process to capture receipt data. The transaction record capture object 401 is arranged to identify the OPOS printer address in the Windows registry, copy it and replace it with the location of the transaction record capture object 401. Print instructions from the P05 software 102 are then routed to the transaction record capture object 401. The original OPOS printer address is provided to the transaction record capture object 401 so that the print data can be routed to its original destination if a paper receipt is required. This will be determined by the preferences of the customer and/or the retailer. A card input window can also be activated on the display of the P05 terminal 101, which, when activated is able to receive a customer identification, by scanning a barcode using the barcode scanner 103 or manually entering it using a keypad. A copy of the transaction record data can be made by the transaction record capture object 401 and transmitted along with the customer identification data to the electronic receipt server 305 via the internet 304. The customer identity information can be time-stamped when it is acquired by the transaction record capture object 401, or when it is transmitted to the electronic receipt server 305 or when it is received by the electronic receipt server 305. Time-stamping allows the customer identity information to be correlated with the transaction record data.
2. POS terminals which print to a Windows1M printer The retailer may connect a standard Windows printer to the P05 terminal. Figure 5 shows how the transaction record capture object 108 is able to capture receipt data sent to a Windows print driver 501. The Windows print driver is identified from the list in the transaction record capture object 401 installed on the POS terminal 101.
The printer 102 is selected and the transaction record capture object 401 automatically enables the "keep printed documents" option in the print driver 501 settings. This causes all printed documents also to be stored in the spool directory of the operating system where the transaction record capture object 401 can directly read the print receipt data. The printed documents are deleted from the spool directory after having been read. The transaction receipt capture object 401 is arranged to transmit the transaction record data to the electronic receipt server 305 via the internet 304, and to correlate this with time-stamped customer identity information obtained from the scanner 103.
3. POS terminals which print to a serial port printer A printer may be connected to a serial port of the POS terminal 101, such as USB or RS-232. If a printer 102 is connected to a serial port 601 and the POS software 105 sends print data to this port, as shown in Figure 6, the data passing through the serial port 601 can be monitored. In the transaction record capture object 401 the "print to port" option is identified from a menu and a serial port monitor driver 602 and library routines for monitoring the data sent over a specified port are arranged to be installed. This raw data is then read directly by the transaction record capture object 4Oland transmitted to the electronic receipt server 305 via the internet 304 with customer identity information.
4. P05 terminals which send data to standard output Alternatively, print data may be sent to a named pipe 701, i.e. standard output as shown in Figure 7. The standard output option is selected from a menu in the transaction receipt capture object 401, which then virtualises a standard input printer and prints to this. Data captured in this way is sent to the electronic receipt server 305 via the internet 304 with customer identity information.
5. POS terminals which send data to a database Alternatively, or as well as sending transaction record data to a receipt printer, the P05 software may write transaction record data to a central database, such as SQL, Firebird or OLE-DB. For large retailers with many POS terminals it is not realistic to install the transaction record capture object 401 on each P05 terminal. The transaction record capture object 401 can be installed at the POS management point of the retailer (204 in Figures 2a and 2b) or remotely from the retailer, for example at the electronic receipt server 305. The "database" output destination is selected from a menu in the transaction record capture object 401. The transaction record capture object 401 is then arranged to log in to the database 205 to monitor activity, as shown in Figure 8, using log-in information provided by the retailer. The transaction record capture object 401 may read the entire contents of the database and transmit this to the electronic receipt server 305 for analysis. Subsequent transaction records can be obtained by storing the offset since the data was last copied and querying data entered in the database since the offset. Querying is performed for example every 2 to 5 seconds. Queries can be customised to suit the retailer's database.
Customer identity information is also searched for in the database 205 and the corresponding receipt data extracted and stored at the electronic receipt server 305.
The transaction record capture object 401 may automatically configure itself by detecting which of the five options is the most appropriate for any given retail environment. This may be by looking for a Windows registry and within that an OPOS print service object address and deciding to alter the registry as described above. If no OPOS print service object address is present in the Windows registry then looking for a Windows printer, or installing a serial port monitor or detecting named pipes. Alternatively each print data capture method may be installed and all of the raw data captured from each print output alternative and data analysed to determine which is the output method used by that particular retailer and thereafter capturing only data from that source. If no transaction record is found then it is assumed that the output is to a database, whereupon database login details can be requested as described above. Capturing print data is the preferred integration method because database entries can be more difficult to analyse as the data tends to arrive in chunks not related to a particular transaction.
It is an object of the invention to operate in an environment where the data structure and format is unknown, where the POS software provider does not need to be consulted or any changes made to the P03 software interface. In order to capture transaction records, a transaction record capture object 401 is installed on the P08 terminal 101. This is middleware that provides services to other software applications. The transaction record capture object 401 can capture transaction record data from any source, as selected depending on the particular set-up that the retailer is using. The transaction record capture object 401 is arranged to store transaction record data in the event of a connection problem with the electronic receipt server 305 and also to periodically transmit status information to the electronic receipt server 305.
When the transaction record data is captured it is sent to the electronic receipt server 305, which is arranged as shown in Figure 9. Retailer identity data, customer identity data and raw transaction record data is received at the data receiver 901, which is arranged to pass this data to a data manager 902. The data manager 902 is able to create retailer records 903a, 903b etc and read and write data to these records, of which there may be one for every retailer who subscribes to the service.
Retailer records 903a, 903b etc include a retailer identity record 904 where security information, retailer contact details including location, and individual POS information including location and unique identification information is stored. The retailer record 903 may also provide access to an offer module 905 which provides an interface for retailers to control offers as discussed below. The retailer record 903 also identifies a transaction record parser 906 for converting raw transaction record data into structured electronic receipt data. The parser is discussed in more detail below.
The retailer record 903 may also provide access to a receipt data retrieval module 907 for retrieving receipt data relating to particular customers, outlets or individual POS terminals. The data manager 902 is also able to create customer records 910a, 910b and read and write data to these records. Customer records 910 may include customer identity information 911 including security information and contact details. The customer records 910 also include receipt data 912 for transactions.
The data manager 902 is able to exchange data with a parser builder 920, which can accept raw transaction record data to be broken down into constituent parts and analysed to identify fields and values. A parser is generated which is used to parse subsequent transaction record data into structured receipt data The manager 902 is able to send structured receipt data to a data pusher 930 which can push receipt data to the customer's mobile device 306.
The electronic receipts generated and stored for each of a customer's transactions have a customisable communications field. This field may be used to present the customer with communications such as adverts, special offers, discounts etc. The offer module 905 is used to set the communications presented to the customer on their electronic receipt. The communications applied by a retailer to electronic receipts are not limited to receipts issued by the retailer. A retailer may opt to place communications such as an offer on the receipts issued by other retailers, or may allow other retailers to place communications on electronic receipts that they issue.
The criteria by which other retailer's receipts, or customers' receipts are chosen can be specified in an interface provided by the offer module 905. This functionality allows targeted advertising and can provide a revenue stream for retailers and the electronic receipt service provider.
Further advanced communications functionality could be deployed using the electronic receipts as a vehicle.
A retailer may access the electronic receipt data of its customers. Retailer identities are stored with the receipt data in a customer record. The data retrieve function 907 queries the customer records for receipts with correlating retailer identities for display. This can allow retailers to monitor customer spending habits and allow them to plan marketing strategies, which can be implemented using the offer module 905.
Operation of the electronic receipt system is described below.
Figure ba shows the steps involved in setting up a retailer with the electronic receipt system. A retailer first decides to subscribe to the electronic receipt service and sets up a retailer record 903 (Step 2000) on the electronic receipt server 305 using an interface provided by web browser 308. The transaction record capture object 401 is downloaded from the electronic receipt server 305 or uploaded locally from a memory storage device and installed (Step 1001). The transaction record capture object 401 may be installed directly on a POS terminal 101 or may reside on the P05 manager 204 if multiple P05 terminals are present. A suitable configuration for the transaction record capture object 401 is selected (Step 1002) depending on how the P05 software 105 is arranged to output transaction record data. The selection may be made by choosing the output destination from a list or the selection may be automated. Dummy transaction data representing a first transaction from the retailer to be captured is created (Step 1003), for example by creating a list of transaction items, returned items and example offers, to produce a transaction record data exemplary of all possible data fields. A dummy customer ID is entered either in the transactions field or in the card input window (Step 1003) and time-stamped by the transaction receipt capture object 401. The dummy transaction is completed and transaction record data is sent to the destination which might be an OPOS printer, Windows printer, database etc, whereupon it is captured by the transaction record capture object 401 (Step 1005). The transaction record capture object 401 adds a time-stamp, retailer ID and POS ID to the data (Step 1006), although the time of the transaction may already be added by the P05 software. The dummy customer ID which corresponds to the transaction may also be added as identified using the time-stamp information, to create a transaction record package. Alternatively the customer id may be correlated with the transaction record data later by the electronic receipt server 305. The transaction record capture object 401 attempts to contact the electronic receipt server 305 (Step 1007). If this is not possible then the transaction record capture object 401 stores the transaction record package (Step 1009) and periodically attempts to send the package to the electronic receipt server 305. When the transaction record capture object 401 has successfully contacted the electronic receipt server 305 the transaction record package is sent to the electronic receipt server 305 (Step 1008) and received by the electronic receipt server 305 (Step 2001). The data receiver 901 de-convolves the data package and sends the transaction record data to the data manager (Step 2002). The data manager decides what to do with the data (Step 2003), noting that there is not yet a transaction record parser for the particular POS terminal as this is the first transaction record data received from the retailer and sends the transaction record data to the parser generator (Step 2004).
The parser generator 920 is used to analyse the transaction record data to generate a parser to convert subsequent unstructured transaction record data into structured electronic receipt data (Step 2005). When the parser has been created it is stored in a retailer record for the POS terminal (Step 2006). The operation of the parser generator is shown in more detail in Figure lOb. The first transaction record is received from the data manager (Step 3001) and a general parser applied to remove irrelevant data (Step 3002). Then, the receipt header data is identified, along with markers, header field names and field values (Step 3003). The first section of the transaction record parser is built for handling the header field (Step 3004). The transaction record parser is a state machine which looks at each line of data and depending which state it is in (e.g. header state) looks for particular values and stores them if it finds them in a structured array, or it can change state if it finds another state identifier. The next region of data is then identified (Step 3005) and the next section of the transaction record parser is built (Step 3006). The process of identifying regions and building sections of the transaction record parser is repeated until all of the transaction record data has been analysed (Step 3007). The transaction record parser for that particular receipt format from the identified retailer is then stored to be accessed from the retailer record 903 in the electronic receipt server 305. For simple transaction record data structures this single parser build routine may be adequate to handle all subsequent transaction records. For retailers using a variety of different receipt structures depending on the nature of the transaction, further steps in refining the transaction record parser may be necessary.
Therefore, each subsequent transaction record that is parsed by the transaction record parser is checked for correctness, as shown in Figure 1 Oc. Subsequent (i.e. not the first transaction record data received from that retailer) transaction record data is received by the data manager 902 (Step 4001) and the transaction record parser associated with the identified retailer or particular P05 terminal is retrieved (Step 4002). The transaction record data is parsed (Step 4003). If the parsing proceeds correctly then the electronic receipt that is produced is stored (Step 4005).
If an error occurs, i.e. an unexpected data value is found, or the correctness checking fails, then the transaction record and the transaction record parser are returned to the building stage to refine the transaction record parser (Step 4006).
The updated transaction record parser is then stored (Step 4007). Correctness checking can include adding up the subtotal of the goods or services and checking this against the total in the electronic receipt.
Customer set-up is shown in Figure 11. When a customer wishes to join the electronic receipt service a unique customer identifier is selected and entered either as a transaction item in the POS software or in the card input window (Step 1101) When a database is used to service many POS terminals, customer identity information is entered as an item in the POS software interface and written to the database on completion of the transaction. The dedicated card input window is used to identify a customer if their identity cannot be stored or retrieved from a database.
The customer ID could be an email address or a credit card number although preferably it is a dedicated code generated by the electronic receipt system, as this poses less problems in terms of data protection or payment security. The customer ID data may be time-stamped by the transaction record capture object 401 on acquisition or on sending to the electronic receipt server 305, or by the electronic receipt server on receipt. The transaction record data is read by the transaction record capture object 401, either as OPOS print data, print file data, serial port data or standard output data and can either be given a time-stamp on capture or the data itself may already contain a time-stamp provided by the P05 software. The time-stamp is a method used to correlate the customer id with the transaction record.
Other goods or services are entered at the POS terminal (Step 1102) and the transaction completed (Step 1103). The transaction record capture object 401 sends time-stamped transaction record data, retailer and P05 ID and customer ID data (if the card input window is used) to the electronic receipt server 305 (Step 1104). The data can be stored by the transaction record capture object 401 if no connection to the electronic receipt server 305 is available, and another attempt made later (Step 1105). The data receiver 901 of the electronic receipt server 305 receives the transaction data (Step 2100). The data manager 902 determines whether the customer has registered yet, and if not stores the transaction record data (Step 2102) for processing later. The customer may complete the registration process at anytime. When they choose to do so, a web browser 307 is used to access the electronic receipt server 305, which is arranged to set up a new customer record (Step 1201). The customer enters their unique customer ID and contact details of their mobile device. They can then download a receipt management application to their mobile device and link this to their electronic receipt server 305 account (Step 1202). The electronic receipt server 305 is notified of the registration (Step 1203) and the electronic receipt server 305 checks to see if there is any stored transaction record data waiting to be processed. If data is present, the data manager 902 retrieves the transaction record parser for the identified retailer (and POS if the POS terminals of a retailer issue receipts of different formats) and converts the transaction record data into structured receipt data (Step 2103). This is checked for correctness (Step 2104). Electronic receipt data is then stored in the customer record (Step 2105) and includes retailer ID and POS ID for later retrieval by the retailer and the customer. Data is then pushed to the customer mobile device (Step 2106), and any offer data is added, by reference to the offer module 905.
Printing of the paper receipt may be interrupted so that a retailer can offer an electronic-only receipt service. For a retailer with an OPOS printer connected to the POS terminal this can be implemented by instructing the transaction record capture object 401 not to forward the print data to the OPOS printer.
For subsequent transactions, when the customer presents their ID at the till, it may be scanned into the card input window and time-stamped, or recorded with the goods and services. The transaction record capture object 401 acquires the transaction record data and sends this to the electronic receipt server 305, again with the time-stamp if this information is not already obtainable from the transaction record data. The electronic receipt server 305 then determines that the customer is already registered. The transaction record parser for the specified retailer or P05 is retrieved and used to parse the raw data. The structured receipt data is then stored in the customer record and then pushed to the customer's mobile device with offers applied in the communications field by the offer module 905, so that the customer instantly receives an electronic receipt for the transaction. Each parsed receipt is checked for correctness in case the transaction record parser is not complete or if the retailer changes the format of the receipt.
The transaction record parser receives transaction record data, and the first data through puts the parser into a particular state. When in this state certain variables are detected. If they are found then they are stored in a structured array or table.
Alternatively a new state may be found, e.g. an item list, and then in this new state, other variables such as prices, VAT, discounts, quantities and field values such as transaction items are looked for, or other states. The table of receipt data is gradually populated until all of the input data has been processed and the resulting receipt data stored. A receipt from a given retailer may be arranged in a variety of formats, with differences including discount structures, quantity lists, manual price corrections, offers, returns. The transaction receipt parser can handle these differences.
The functionality of the electronic receipt server may be provided in the transaction record capture object at each of the retailer's POS terminals.
The transaction record parser is written in the Python programming language, but many other languages may be used or parts of dedicated libraries used to build the parser.
It is to be understood that various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown and such modifications and variations also fall within the spirit and scope of the appended claims.

Claims (33)

  1. CLAIMS1. A method of providing an electronic receipt facility for the FOS system of at least one retailer, wherein said POS system or systems are arranged to record customer-retailer transactions and said system or systems include at least one computer terminal running POS software, wherein the FOS software is arranged to route a record of a transaction in the form of transaction record data in an unknown data format to one or more output destinations within the existing P05 system on completion of a customer-retailer transaction, the method comprising the steps of; for the or each P05 terminal of the or each retailer, identifying an output destination, configuring the data reader based on the output destination to obtain a copy of the transaction record data, collecting customer identity information for transactions when the customer identity information is available, for each transaction where customer identity information is available, using the data reader to obtain a copy of the transaction record data which is routed to the identified output destination, communicating the transaction record data to a transaction record parser, said transaction record parser being arranged to convert the transaction record data into electronic receipt data of a known format, correlating the electronic receipt data with the customer identity information, communicating the correlated electronic receipt data and customer identity information to a data store, making the electronic receipt data in the data store available to view by the retailer and/or the customer.
  2. 2. A method of providing an electronic receipt facility in accordance with claim 1, wherein a unique retailer identity is given to the or each retailer and a unique transaction record parser is created for the or each retailer.
  3. 3. A method of providing an electronic receipt facility in accordance with claim 2, wherein the unique transaction record parser is created using a first transaction record from the retailer and wherein said unique transaction record parser is stored for parsing subsequent transaction record data from the retailer.
  4. 4. A method of providing an electronic receipt facility in accordance with claim 3, wherein subsequent transaction record data from the or each retailer is used to refine the unique transaction record parser.
  5. 5. A method of providing an electronic receipt facility in accordance with any one of claims 1 to 4, wherein a unique parser is created for each POS terminal.
  6. 6. A method of providing an electronic receipt facility in accordance with any one of claims 2 to 5, wherein the first transaction record data from a retailer is analysed for similarity with previous transaction record data from other retailers and the transaction record parser associated with the previous transaction record data is used as a starting point to create the parser for the retailer.
  7. 7. A method of providing an electronic receipt facility in accordance with any preceding claim, wherein the POS software is arranged to route transaction record data to an OPOS enabled printer, the method including the step of identifying the OPOS enabled printer as the output destination, redirecting the transaction record data from the OPOS enabled printer to the data reader.
  8. 8. A method of providing an electronic receipt facility in accordance with claim 7, wherein the POS software is arranged to identify the OPOS printer by reference to an address stored in a registry on the POS terminal, the method including the step of copying the address of the OPOS printer in the registry and changing it to an address for the data reader.
  9. 9. A method of providing an electronic receipt facility in accordance with claim 8, wherein the transaction record data is routed from the data reader to the address of the OPOS printer copied from the registry to provide a paper receipt.
  10. 10. A method of providing an electronic receipt facility in accordance with any one of claims 7 to 9, wherein the OPOS printer capability is detected and the data reader configured automatically.
  11. 11. A method of providing an electronic receipt facility in accordance with any one of claims 1 to 6, wherein the POS software is arranged to route transaction record data to a print driver which has the capability to print to a file, the method comprising the step of identifying the output destination as a print-to4ile enabled print driver, setting the print driver to print to a file and copying the transaction record data from the file.
  12. 12. A method of providing an electronic receipt facility in accordance with any one of claims 1 to 6, wherein the POS software is arranged to send transaction record data to a serial port, the method comprising the step of identifying the serial port as the output destination, installing a serial port monitor and copying the transaction record data sent over the serial port detected by the serial port monitor.
  13. 13. A method of providing an electronic receipt facility in accordance with any preceding claim, wherein the transaction record data has a time-stamp and the customer identity information is time-stamped and the time-stamps used to correlate the transaction record data and the customer identity information.
  14. 14. An electronic receipt system for providing an electronic receipt capability to the FOS system of at least one retailer, said FOS system or systems arranged to record customer-retailer transactions and comprising at least one computer terminal running POS software, the POS software arranged to route a record of a transaction in the form of transaction record data in an unknown data format to one or more output destinations within the existing POS system on completion of a customer-retailer transaction, the electronic receipt system comprising, for the or each retailer; an output destination selector for identifying one of the output destinations, a data reader configurable in dependence on the identified output destination to read data routed to the selected output destination, a customer identity collector for collecting customer identity information, a transaction record parser in communication with the data readerfor converting the transaction record data into electronic receipt data of a known format, a data store in communication with both the transaction record parser and the customer identity collector, said data store arranged to correlate and store the electronic receipt data with the customer identity information, a data access unit for making the electronic receipt available to view by the retailer and/or the customer.
  15. 15. An electronic receipt system in accordance with claim 14, including a transaction record parser builder, said transaction record parser builder arranged to receive a first transaction record data set from the or each retailer to use as the basis for the transaction record parser.
  16. 16. An electronic receipt system in accordance with claim 14 or 15, wherein the transaction record parser includes a state machine and the transaction record parser builder is arranged to identify regions in the transaction record data, which correspond to states in the state machine.
  17. 17. An electronic receipt system in accordance with claim 15 or 16, wherein the transaction record parser is arranged to check the electronic receipt data for correctness.
  18. 18. An electronic receipt system in accordance with any one of claims 15 to 17, wherein the transaction record parser builder is arranged to refine the transaction record parser if transaction record data has been incorrectly parsed.
  19. 19. An electronic receipt system in accordance with any one of claims 15 to 18 wherein transaction record data formats are arranged to be stored in a library and wherein the transaction record parser builder is arranged to refer to the library and identify previous transaction record data with similar characteristics and wherein the transaction record parser builder is arranged to use the transaction record parser associated with the previous transaction record data as a starting point to create the transaction record parser.
  20. 20. An electronic receipt system in accordance with any one of claims 14 to 19, wherein the transaction record output destination includes an OPOS printer having an address identified by the P05 software from a registry, the electronic receipt system including means for changing the address in the registry to the address of the data reader.
  21. 21. An electronic receipt system in accordance with claim 20, wherein the system includes means for directing the transaction record data from the data reader to the OPOS printer identified by the address in the registry.
  22. 22. An electronic receipt system in accordance with claim 20 or claim 21, wherein the system has means for detecting OPOS printer capability and configuring the data reader automatically.
  23. 23. An electronic receipt system in accordance with any one of claims 14 to 19, wherein the transaction record output destination is a print driver which has the capability to print to a file, the system including means to identify the output destination as a print-to-file enabled print driver, and means to set the print driver to print to a file, wherein the data reader is arranged to copy the transaction record data from the file.
  24. 24. An electronic receipt system in accordance with any one of claims 14 to 19, wherein the POS software is arranged to send transaction record data to a serial port, the system having means to install a serial port monitor and the data reader arranged to copy the transaction record data detected by the serial port monitor.
  25. 25. An electronic receipt system in accordance with any one of claims 14 to 24, wherein the transaction record parser is remote from the data reader.
  26. 26. An electronic receipt system in accordance with any one of claims 14 to 25, wherein data access unit comprises a web-enabled access point where the customer and/or retailers may access electronic receipts using a web browser.
  27. 27. An electronic receipt system in accordance with any one of claims 14 to 25, wherein the data access unit is arranged to transmit electronic receipt data to a mobile device of a customer.
  28. 28. An electronic receipt system in accordance with any preceding claim, wherein a time-stamper is provided to time-stamp the customer identity information to enable the customer identity information and the electronic receipt to be correlated.
  29. 29. An electronic receipt system in accordance with claim 28, wherein the time-stamper is arranged to time-stamp the transaction record data and/or the electronic receipt data.
  30. 30. A computer program product for an electronic receipt system comprising; a computer readable medium, comprising computer readable instructions for executing the method of any one of claims 1 to 13.
  31. 31. A method of providing an electronic receipt service substantially as described herein with reference to the accompanying drawings.
  32. 32. An electronic receipt system substantially as described herein with reference to the accompanying drawings.
  33. 33. A computer program product for providing an electronic receipt service substantially as described herein with reference to the accompanying drawings.
GB1312938.2A 2013-07-19 2013-07-19 Electronic receipts system and method Withdrawn GB2516309A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
GB1721221.8A GB2555345A (en) 2013-07-19 2013-07-19 Electronic receipt system and method
GB1312938.2A GB2516309A (en) 2013-07-19 2013-07-19 Electronic receipts system and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1312938.2A GB2516309A (en) 2013-07-19 2013-07-19 Electronic receipts system and method

Publications (2)

Publication Number Publication Date
GB201312938D0 GB201312938D0 (en) 2013-09-04
GB2516309A true GB2516309A (en) 2015-01-21

Family

ID=49118982

Family Applications (2)

Application Number Title Priority Date Filing Date
GB1312938.2A Withdrawn GB2516309A (en) 2013-07-19 2013-07-19 Electronic receipts system and method
GB1721221.8A Withdrawn GB2555345A (en) 2013-07-19 2013-07-19 Electronic receipt system and method

Family Applications After (1)

Application Number Title Priority Date Filing Date
GB1721221.8A Withdrawn GB2555345A (en) 2013-07-19 2013-07-19 Electronic receipt system and method

Country Status (1)

Country Link
GB (2) GB2516309A (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3211577A1 (en) * 2016-02-26 2017-08-30 Toshiba TEC Kabushiki Kaisha Receipt server, electronic receipt system, and program
CN108364416A (en) * 2018-01-08 2018-08-03 四川省茂扬科技有限公司 A kind of self-service control method of 24 hours intelligent libraries
WO2018144685A1 (en) * 2017-02-02 2018-08-09 Griffith Thomas E Financial processing and data management system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5739512A (en) * 1996-05-30 1998-04-14 Sun Microsystems, Inc. Digital delivery of receipts
US20110184822A1 (en) * 2010-01-22 2011-07-28 Naviit, Inc. Point of sale network router
US20110307342A1 (en) * 2010-06-15 2011-12-15 Haji Faizal Method and system for generating electronic receipts from print data
US20120253958A1 (en) * 2011-04-01 2012-10-04 Third Solutions, Inc. System for generating digital receipts

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5739512A (en) * 1996-05-30 1998-04-14 Sun Microsystems, Inc. Digital delivery of receipts
US20110184822A1 (en) * 2010-01-22 2011-07-28 Naviit, Inc. Point of sale network router
US20110307342A1 (en) * 2010-06-15 2011-12-15 Haji Faizal Method and system for generating electronic receipts from print data
US20120253958A1 (en) * 2011-04-01 2012-10-04 Third Solutions, Inc. System for generating digital receipts

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3211577A1 (en) * 2016-02-26 2017-08-30 Toshiba TEC Kabushiki Kaisha Receipt server, electronic receipt system, and program
WO2018144685A1 (en) * 2017-02-02 2018-08-09 Griffith Thomas E Financial processing and data management system
CN108364416A (en) * 2018-01-08 2018-08-03 四川省茂扬科技有限公司 A kind of self-service control method of 24 hours intelligent libraries

Also Published As

Publication number Publication date
GB201721221D0 (en) 2018-01-31
GB2555345A (en) 2018-04-25
GB201312938D0 (en) 2013-09-04

Similar Documents

Publication Publication Date Title
JP5620565B1 (en) Product sales data processing apparatus and program
US11397927B2 (en) Electronic receipt system, electronic receipt management server, and program therefor
US20180005200A1 (en) Generation and delivery of digital receipts based on user preferences and transaction related data
US7324960B2 (en) POS system
US20110141494A1 (en) System, apparatus, and method for oriented switch of promotion information
US20150356689A1 (en) Data processing system in which data received from data collection terminals are converted for efficient searching
US20140249909A1 (en) Electronic receipt system, information processing apparatus, and program therefor
EP3485447A1 (en) System, device, and method for capturing and managing point of sale transaction related data
WO2017056091A1 (en) System and method for utilizing retail pos data streams with transaction information
US20190073649A1 (en) Transaction data processing apparatus connected to an external device for data communication
US20160104143A1 (en) Recording device, transaction processing system, and control method of a recording device
KR20200090136A (en) The method and system to inerlink QR pay
US20160155107A1 (en) Improved performance in interaction systems
GB2516309A (en) Electronic receipts system and method
JP6224777B2 (en) Product sales data processing apparatus and program
JP4569620B2 (en) Management system, management method, store terminal, and computer program thereof
CN104737190A (en) Method and system for improving encashment systems
JP6745865B2 (en) Electronic receipt management server and program
JP6457610B2 (en) Electronic receipt system
US20150154582A1 (en) Print control system and print control method
US20170185874A1 (en) Information Processing Device, Information Process System, and Control Method of an Information Processing Device
JP2020017004A (en) Electronic receipt system and program
US20220012816A1 (en) Information processing apparatus and program
JP7001775B2 (en) Product sales data processing equipment, programs and electronic receipt systems
US20220067696A1 (en) Method and system for linking qr pay

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)