Browse Prior Art Database

Method of Pausing and Transferring Point-of-Sale Transactions to other Point-of-Sale Terminals Disclosure Number: IPCOM000184122D
Original Publication Date: 2009-Jun-11
Included in the Prior Art Database: 2009-Jun-11
Document File: 1 page(s) / 26K

Publishing Venue



In a retail setting, customers typically wait in long lines to either return merchandise, signup for credit cards, or pay for purchased items. Often customers who have large numbers of items to purchase cause the speed of the line to stagnate, resulting in delayed service, poor customer satisfaction, and potentially less sales transactions. Customers also may want to purchase more items once the retail employee has already given the customer the total amount due. In order to combat this problem, retail employees currently have three options to pursue: 1) Cancel the transaction entirely 2) Cancel the transaction and move registers 3) Save the transaction data to a database and start a new transaction on a different register with the data retrieved from the database. These current solutions either require a dedicated store server or require time consuming cancelling of the transaction and re-entering the data at a different point in time, etc.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 63% of the total text.

Page 1 of 1

Method of Pausing and Transferring Point -of-Sale Transactions to other Point-of-Sale Terminals

Disclosed is a method to transfer transaction data (e.g., SKU, Price, Item, etc) directly to other Point-of-Sale (POS) terminals in a P2P network in a XML format. This specific method would particularly be applicable in store environments which do not have any servers.

In this method, a POS application would have the ability to communicate directly with other POS clients directly, and can import/export transactional data in XML format through a serialization mechanism.

Consider the following scenarios:

1) A retail clerk scans all of the items into the POS application and the customer wishes to continue shopping. As a result of this preference, the retail clerk can suspend the transaction (i.e., pause it) by entering specific keystrokes or touching a button on a touch-screen monitor. As a result of this action, the POS application will store the data on it's hard disk in an XML format. The customer can then service other customers during this period. Once the customer returns to the terminal, the retail clerk will restart the suspended transaction by selecting it from a list of known suspended transactions. If the customer wishes to pay at another retail POS terminal, the clerk at said terminal can import the XML data (underlying serialization) from a different terminal. Of course, a pool of transactions are kept in a repository...