The present disclosure released generally to point of sale terminals used in the operation of retail stores and other establishments and, more particularly, a distributed point of sale system having shareable device brokers.
Point of Sale (POS) systems may utilize a number of different devices such as scanners, pin pads, receipt printers, card readers and similar devices to complete sales transactions. Many current POS systems use platform-specific software components to communicate with such POS devices. The software components are written in different languages (e.g. Java, .net), making reuse of the software components and cross platform support difficult. For example, a POS system developed for LINUX® platform cannot run on a WINDOWS® platform. Similarly, a POS system developed for a desktop computer cannot run on a mobile device, and a POS system for an ANDROID® device cannot run on an IOS device.
The TCxgravity® system offered by Toshiba resolves the cross platform support issue by using a web based client that connects with POS devices through a device broker. The device broker runs on the same host as the web based client. This arrangement limits the types of platforms on which the POS system can run. Another challenge is that it can be hard to share POS devices among multiple POS applications deployed on the same or different platforms.
The present disclosure relates to a POS system having a shareable device broker service. The device broker application running on a device broker server manages POS devices (e.g. cash drawer, bar code scanner, receipt printer, card reader, etc.) and device-related business functions (e.g. payment handling, receipt printing, scanning, etc.). A POS application running on a separate client device communicates with the device broker application over a communication network via Transport Communication Protocol (TCP) and/or websocket transports. A discovery mechanism is provided to enable the client devices to discover the device broker server. The client devices may select a device broker and send service requests to the selected device broker server. The device broker server controls the POS devices to provide the requested service and sends response messages to the client devices indicating the results of the services provided by the device broker utilizing the POS devices.
The POS system as herein described abstracts the POS devices and device-related services into a service layer that is separate from the POS application. The POS application becomes a client requiring only a thin web-based application. The device broker application and platform may be sold as a separate product.
Referring now to the drawings, an exemplary point of sale (POS) system is shown therein and indicated generally by the numeral 10. The function of the POS system 10 is to facilitate sales transactions between a retail store or other establishment and a customer. The main functional components of the POS system 10 comprise a POS server 15, one or more client devices 200, one or more device broker servers 400, a registration server 600, and a plurality of POS devices 20. The client devices 200, device broker server 400, and registration server 600 communicate with each other over a communication network using JavaScript Object Notation (JSON), Extensible Markup Language (XML), or other known data exchange languages.
In one embodiment, the client device 200 comprises a mobile computing device such as such as smart phone, tablet, laptop computer, or similar devices configured to function as a POS terminal. The client devices 200 may use any type of operating system (OS) including a Windows®, Android®, Apple®, Linux®, or other OS. The client devices 20 have a web-based POS application installed for handling POS transactions. The client devices 20 and are used by sales associates or other personnel in the retail store or other establishment to complete point of sale transactions with a customer. The client devices 20 may, in some embodiments, communicate with a POS server 15 that maintaining records for point of sale transactions.
The device broker server 400 comprises a separate mini-server or other computer configured to provide device broker services as herein described. The device broker server 400 may include an embedded operating system (OS), such as a LINUX® OS. A device broker application is installed on the device server 400 and communicates with the POS applications on the client devices 200 over a communication network via Transport Control Protocol (TCP) and or web socket transports. The device broker server 400 manages one or more POS devices 20 (e.g. bar code scanner, receipt printer, cash drawer, etc.) and device-related business functions (e.g. payment handling, receipt printing, etc.). The device broker server 400 eliminates the need of the POS applications on the client devices 20 to manage the individual POS devices 20 and enables the sharing of POS devices 20 between client devices 20. The client devices 20 may request device-related services of the device broker server 400 offered utilizing one or more of the POS devices 20. The POS server 15 provides the requested services to the client devices 20 utilizing the controlled POS devices 20 and sends response messages to the client devices 20 associated with the services.
The registration server 600 comprises a computer configured to maintain a registry of device broker servers 40. The registration server 400 may include an embedded operating system (OS), such as a LINUX® OS. The registration server 600 receives registration requests from the device broker servers 40 and adds the device broker servers 40 to the device broker registry. The registration server 600 may be queried by the client devices 20 to discover the device broker servers 40 in the POS system 10.
Once the device broker server 400 is registered in the device broker registry, the device broker server 400 is discoverable by client devices 200. More particularly, a client device 200 may discover a device broker server 400 by querying the device broker registry. To query the device broker registry, the client device 200 sends a query to the registration server 600 (step c). The query may include a unique client identifier. In response to the query, the registration server 600 sends a query response to the client device 200 including a list of device broker servers 400 (step d). In one embodiment, the list may include, for each device broker server 400, a unique device broker identifier, a descriptive name associated with the device broker sever 400, the network address of the device broker server 400, and available devices/services associated with device broker server 400.
In some embodiments, the registration server 600 may also function as a presence server. The device broker servers 40 may report a presence status (e.g., online, offline, busy, etc.) to the registration server 600. The device broker list provided by the registration server 600 to the client device 200 may include the current presence status of each device broker server 400.
The client devices 200 may request device-related services from a device broker server 400. The POS application executing on the client device selects a device broker server (step e). The selection of the device broker server 400 may be based on user input, or may be selected automatically by the POS application on the client device. In one exemplary embodiment, the POS application on the client device 200 sends a claim request with a unique plan identifier to the device broker server 400 to request permission to use the service (step f). If the device broker server 400 grants the request, it returns a grant message to the client device 200 giving permission to the requesting client device 200 to use the services of the device broker server 400 (step g). In one exemplary embodiment, the grant of the claim request establishes a session between the device broker server 400 and client device 200. In one exemplary embodiment, the device broker server 400 is configured to support one session at a time with one client device 40. Once a session is established, the device broker server 400 will reject any claim request from other client devices 200 until the session with the current client device 200 is terminated. In other embodiments, the device broker server 400 may be configured to support concurrent sessions with multiple client devices 200.
Once a client device 200 establishes a session with a device broker server 400, the client device 200 may send service requests to the device broker server 400 to request device-related services (step h). Table 1 below provides a non-exhaustive list of exemplary service requests that may be sent by the client device 200.
Responsive to the service request, the device broker server 400 controls one or more POS devices 20 to provide the requested service and sends one or more response to the client device 200 (step i, j). For example, assume that a sales associate using a client device 200 needs to print a receipt for a customer. In this example, the client device 200 may send a PrintReceipt request to the device broker server 400. The PrintReceipt request, contains information that is required to print the receipt, such as the transaction number, items purchased, purchase price, date, etc. Upon receipt of the PrintReceipt request, the device broker server 400 controls a POS device (in this case a receipt printer) to print the receipt. When the receipt is printed, the device broker server 400 sends a response to the client device 200 indicating that the receipt has been printed.
During a session, the client device 10 may send multiple service requests to the device broker server 400. For each service request, the device broker server 400 controls one or more POS devices 20 to provide the requested services and provides a response indicating the result of the actions performed by the device broker server 400 responsive to the service request. In one exemplary embodiment, service requests are handled synchronously. That is, when the client device 200 sends a service request to the device broker server 400, the client device 200 may not send another service request until the previous service request is completed. In other embodiments, the service requests may be sent asynchronously. In this case, the client device 200 may send a new service request to the device broker server 400 before the previous service request is completed. The device broker server 400 may maintain the service request in a queue and perform the requested services in the order in which they are received. Alternatively, the device broker server 400 may prioritize service requests and process them in order of priority.
Once the session has ended, the POS application on the client device 200 may send a release request to the device broker server 400 to terminate the session and release the device broker server 400 (step k). The device broker server 400 sends an acknowledgement (ACK) to the client device (step I). After acknowledging the release request, the device broker server 400 is then available for use by other client devices.
To illustrate the functionality of the device broker service, assume that Carol is a cashier working in a grocery store having two device broker servers 400 available, each of which is connected to a cash drawer. Carol uses a POS application on a client device 200 with no cash drawer connected. In order to complete a cash sale, the following steps are performed:
As the above example demonstrates, the POS application on Carol's client device 200 does not need to know the implementation and control details to manage the cash drawer. It simply discovers and claims the device broker server 400, and then sends a service request to the device broker server 400. The device broker server 400 manages the cash drawer and other POS devices 20 for the client device 200. Thus, the POS application on the client device 200 is insulated from the underlying details of device management.
After the device broker server 400 for the sales transaction is selected, the client device 200 establishes a session with the selected device broker server 400 (block 115). In one embodiment, a session is established by sending a claim request to the device broker server 400 requesting permission to use the services of the device broker server 400. If the request is granted, the device broker server 400 sends a grant message to the client device 200 giving the client device permission to use the device broker server 400. A session is then established between the client device 10 and the device broker server 400. In some embodiments, the device broker server 400 may be configured to support a single session at a time with one client device 200. In other embodiments, the device broker server 400 may be configured to support multiple, concurrent sessions with different client devices 200.
Once a session is established, the client device 200 sends a service request to the device broker server 400 to request a device-related service (block 120). A device-related service is a service that requires use of one of the POS devices 20 controlled by the device broker server 400. Exemplary service requests include a PayByCash request, a PayByCredit request, a PayByCheck request, a Scan Product request and PrintRecipt request. Other device-related services could also be offered by the device broker server 400. After sending the request, the client device 200 waits for the device broker server 400 to perform the requested service. When the requested service is performed, in whole or in part, the client device 200 receives a service request response from the device broker server 400 (block 125). The service request response indicates a result of the service performed by the device broker server 400 utilizing one of the POS devices 20. The result may be an intermediate result (e.g., cash drawer is opened) or a final result (e.g., cash transaction completed). In some embodiments, a single service request may result in multiple service request responses.
Once the service request is completed, the client device terminates the session with the device broker server 400 (block 130). In one embodiment, the session is terminated by sending a release request to the device broker server 400. The device broker server 400 sends an acknowledgement message (ACK) to the client device 200 indicating the session is terminated.
In order to provide the device-related services, the device broker server 400 establishes a session with a client device 200 (block 160). Typically, the session establishment procedure is initiated by the client device 200 to support a sales transaction. In one embodiment, the device broker server 400 receives a claim request from a client device 200 needing device-related services to support a sales transaction. If the device broker server 400 is available (e.g., not currently engaged in another session), the device broker server 400 sends a grant message to the client device 200 giving permission to the client device 200 to use the services of the device broker server 400. Receipt of the grant message by the client device 200 establishes a session between the client device 200 and the device broker server 400.
Once the session is established, the device broker server 400 may receive one or more service requests from the client device 200 (block 165). For each service request, the device broker server 400 controls one or more POS devices 20 to provide the requested service (block 170) and sends appropriate service request responses (block 175) to the client device 200. The service request responses indicate a result of the services provided by the device broker server 400 and may be based on an action performed by one or more POS devices 20. For example, if the client device 200 requests a receipt for the sales transaction, the device broker server 400 controls the receipt printer to print the receipt. Data needed for printing the receipt is included in the service request. Once the receipt is printed, the device broker server 400 sends a service request response to the client device 200 indicating that the receipt was printed.
Once all requested services are performed, the session with the client device 200 is terminated (block 180). In one embodiment, the client device 200 sends a release request to the device broker server 400 after the sales transaction is completed to terminate the session. The device broker server 400 sends an acknowledgement message to the client device and terminates the session. In some embodiments, the device broker server 400 may also terminate the session based on expiration of an activity timer. When a service request is completed, a device broker server 400 may start a timer. If the timer expires before another service request is received, the device broker server 400 may terminate the session. In the event that the sales transaction was not complete, the client device 200 will need to establish a new session to complete the sales transaction.
The processing circuit 220 comprises one or more microprocessors, hardware circuits, firmware or a combination thereof configured to control the operation of the client device 200 and perform the methods as herein described. Program code and data needed for operation are stored in memory 240. Program code needed for operation and permanent data are stored in a non-volatile memory, which may comprise a solid state memory device, magnetic media, or optical media. Temporary data may be stored in a volatile memory such as a random access memory (RAM).
The user interface 260 provides a means for a user to interact with the client device 200. The user interface 260 comprises one or more user input devices 265 and a display 270. The user input devices 265 enable the user to input data and commands into the client device 200. The display 270 enables the user to view information generated by the POS application on the client device 200. The user input devices 260 may include one or more of a keypad, function keys, switches, touchpad, touchscreen, joystick, trackball, pointing device, or other input devices. The display 270 may comprise a liquid crystal display (LCD), light emitting diode (LED) display, electronic ink display, or other known type of display. In some embodiments, the display 30 may be a touchscreen display that also functions as a user input device 260.
The communication circuits 280 comprise one or more interface circuits for communicating with remote devices over a communication network. In the exemplary embodiment shown in
The POS system 10 as herein described includes a separate device broker server 400 that is configured to handle device-related functions for client devices 200, a discovery mechanism to enable discovery of the device broker server 400 by client devices 200, and a claim-release mechanism that enables sharing of the device broker servers 400 by multiple client devices 200. Because the client devices 200 are insulated from the details of device management, a thin web-based POS application can be implemented on the client devices 200. The device broker can implement a JAVA-based application to fully support client devices 200 running on any platform (e.g., WINDOWS®, APPLE®, IOS, LINUX®, etc). Because the device broker server 400 is separate from the client devices 200, the device broker server 400 and related applications can be packaged and sold as a separate product/service.