Patent Description:
<FIG> illustrates one example of a customer system interface <NUM> and a merchant system interface <NUM> that can be used in a POS system to facilitate commercial transactions. The interfaces <NUM> and <NUM> can be software-controlled interfaces that communicate information to a user, in which the communication can be accomplished by a cathode ray tube display, a liquid crystal display, an inorganic or organic light emitting diode display, e-reader, or any other type of display device, with or without touch screen capability. The interfaces <NUM> and <NUM> guide the users to input information directly into the POS system. The data may be input using non-display devices, such as a keyboard or PIN pad, by the interface displays when configured to receive touch information, such as through a touch screen display, or by other means, such as audio information received by a microphone. In the example illustrated in <FIG>, the customer system interface <NUM> has a customer system interface display <NUM>, and the merchant system interface <NUM> has a merchant system interface display <NUM>. The displays <NUM> and <NUM> can be touch screen displays that enable the users to simultaneously receive visual information from, and input touch information directly into, the interfaces <NUM> and <NUM>.

When displays <NUM> and <NUM> are touch screen displays, the users can communicate with the interfaces <NUM> and <NUM> by providing touch information at specific points that are designated by virtual buttons <NUM>, which can represent user commands, alphanumeric inputs, a virtual device such as a virtual keyboard or virtual pin pad <NUM>, or other inputs specified by the interface software. In one example, users can receive commercial transaction information, such as individual items costs, payment totals, payment types, keyboard or PIN pad input displays, and other information, by virtual displays <NUM> on the displays <NUM> and <NUM>. In another example, users can receive prompts provided by the interfaces <NUM> and <NUM> which help the users navigate the commercial transaction process. When customers and merchants are involved in a commercial transaction using a POS system, typically the customer will be the user that interacts with the customer system interface <NUM> and the merchant will be the user that interacts with the merchant system interface <NUM>. One prompt that is commonly given to the customer is a prompt for payment information <NUM> such as a prompt for a personal identification number (PIN), and one prompt that is commonly given to the merchant is a prompt for payment total confirmation <NUM>. Once the prompts <NUM> and <NUM> are properly addressed by the users, the commercial transaction can complete.

One type of POS system that is implemented widely in the retail space is a supermarket POS terminal with a payment device. A typical configuration includes a terminal that processes the commercial transaction, for use by a merchant, permanently connected to a payment device, for use by the customer during payment. The terminal can continuously provide access to a merchant system interface <NUM>. The terminal is configured to receive and store item identification data from scanned items using a barcode reader system. The results of the item identification process are shown to the merchant and customer, simultaneously and in real time, by a terminal display screen. Then the terminal calculates the total price to be paid for the items and sends commands to the payment device to process a transaction for that amount. The payment device could include a PIN pad with a display screen, to facilitate the payment process by giving the customer a payment prompt. The payment device could continuously provide access to a customer system interface <NUM>.

Another type of POS system includes a single POS terminal with a single display screen, wherein the customer and merchant share the terminal to complete the commercial transaction. In other words, the same display provides access to the merchant system interface <NUM> and the customer system interface <NUM>, but at separate times. For example, a shared POS terminal can be placed in-between the merchant and the customer and rotated on a rotatable stand to face either user. When the customer is using the terminal to make a payment, the terminal can be rotated to face the customer to provide the payment interface to facilitate efficient and secure entry of the user's payment information to the system. When the customer is done, the terminal can be rotated back to the merchant. When the shared screen is accessible to the customer, the customer can be locked out of accessing the merchant interface, such as to change the total payment amount or conduct other illicit activity.

<CIT> discloses a POS system housing, which may be adjustable so that a screen of the computing device can be viewed by a merchant and a customer. <CIT> discloses a POS terminal that can be used in different directions.

The competitive choice for a POS system is based on continually evolving factors. Specifically, merchants that use a single POS system in multiple purchasing environments, or have rapidly developing and fluid customer needs, require configurable POS system to provide time efficient service within the changing constraints of the retail environment. Additionally, configurable POS systems allow for the economic flexibility that small business owners need to succeed, allowing for service or security improvement after core POS system functionality has been established for basic business operation.

Methods and systems are disclosed that provide enhanced flexibility to merchants in the configuration of POS systems with minimal expenditures. In a specific embodiment, a POS device can offer both a customer and merchant system interface in one mode of operation, and only one of those system interfaces in a second mode of operation. In a specific embodiment, a POS device with a single display enables a customer and merchant to conduct a commercial transaction using that single display, and that same POS device can optionally connect to another display device and enable the customer to conduct their portion of the transaction using the original display while the merchant conducts their portion of the transaction using the added display device.

Methods and systems related to a dual mode payment interface device are disclosed. Disclosed devices can be used by users to facilitate commercial transactions, wherein the users comprise merchants, customers, and other authorized users. Commercial transactions can include the exchange of goods and services for legal tender or credit. Credit can be established with a credit card, a personal check, a credit account linked to a device, such as a smart phone, that communicates to the disclosed systems by near field communication (NFC) technology, or any other credit distribution system. Legal tender can be cash, coins, transferred by debit card, or represented by other means. Approaches disclosed herein include specific technical solutions to improve the configurability of systems that would otherwise be locked into a single mode of operation. Disclosed methods and systems comprising a dual mode payment interface device can involve a first mode, wherein the dual mode payment device is shared between the merchant and the customer, and a second mode, wherein the dual mode payment device is used by only the merchant or the customer. Various methods and systems for determining when the device should switch between these modes, and for how the device should switch between these modes are disclosed below.

<FIG> illustrates a specific embodiment of a dual mode payment device <NUM> that is in accordance with teachings of the prior paragraph. <FIG> illustrates a system used for commercial transactions that can include dual mode payment interface device <NUM> having a first touch screen display <NUM>. Dual mode payment interface device <NUM> has two modes of operation and is illustrated in three possible configurations. In the first configuration, device <NUM> operates in a first mode of operation <NUM>. In the second configuration, device <NUM> undergoes a connection step <NUM>. In the third illustrated configuration, device <NUM> operates in a second mode of operation <NUM>.

In first mode of operation <NUM>, the dual mode payment interface device <NUM> can operate without other devices such that users, which can include a customer <NUM> and a merchant <NUM>, provide inputs to the dual mode payment interface device <NUM> at separate times. In the same example, the inputs can be provided to the system by the users using the touch screen display <NUM>. In another example where the disclosed systems are operating in the first mode of operation <NUM>, at one point in time the dual mode payment interface device <NUM> can be rotated to an orientation that is customer facing <NUM>, while at another point in time can be rotated to an orientation that is merchant facing <NUM>. In the same example, the switching between the customer facing <NUM> to merchant facing <NUM> orientations can happen any number of times and in any order. When multiple users can use the screen, the touch screen display <NUM> can be considered as a shared screen. In an embodiment illustrated in <FIG>, the shared screen can enable the dual mode payment interface device <NUM>, after switching to customer facing <NUM>, to provide access to a customer system interface <NUM> on its touch screen display <NUM>, and after switching to merchant facing <NUM>, provide access to merchant system interface <NUM> on its touch screen display <NUM>. Throughout this process, the dual mode payment interface device <NUM> is simultaneously guiding the users through the process of the commercial transaction with prompts shown on the interfaces. In one example, the customer system interface <NUM> can provide a prompt for payment information and the merchant system interface <NUM> can provide a prompt for a payment total confirmation.

Purchasers of the POS systems in accordance with the disclosures herein, such as merchant <NUM>, could prefer the system comprising the dual mode payment interface device <NUM> in the first mode of operation <NUM> in certain circumstances. For example, when the space used for the commercial transaction is limited. The device used in the first mode of operation <NUM> can have a relatively small footprint and the fact that it can also be shared means that the total area required for the POS system is indeed limited. Another advantage of the system in the first mode of operation <NUM> is its relative low cost as only one single display device is required for system functionality. As such, the solution is a relative cheaper option compared to systems that require more than one device or display.

With the benefits of the first mode of operation <NUM> described above taken as a given, there are, concurrently with the cases discussed above, commercial transaction environments that can require added functionality from the dual mode payment interface device <NUM>, that are in addition to what is described in the first mode of operation <NUM>, to meet customer demand. In one example, a second display screen could be required to preclude the extra time needed to turn the dual mode payment interface device <NUM> between customer facing and merchant facing orientations. In another example, enhanced payment information security can be desired. Providing a dedicated screen to the customer <NUM> can help prevent the merchant <NUM> from seeing private payment information, such as a debit card PIN number, as well as other personal commercial transaction information, such as a customer-elected tip payment amount when paying for services where tip payments are expected. Providing a dedicated screen to merchant <NUM> can likewise prevent customers from illicitly accessing the merchant interface to change the amount of the transaction or access the merchant's core business information which could be accessible via the merchant system interface. For example, the merchant could have access to their inventory management system, price setting system, or confidential business information via the merchant system interface.

Systems and methods illustrated in <FIG> in the connection step <NUM> and the second mode of operation <NUM> disclose embodiments in which the dual mode payment interface device <NUM> can transition from a stand-alone device system configuration in the first mode of operation <NUM> to a multiple device system configuration in the second mode of operation <NUM>. In other words, the system can be configured at the discretion of the system purchaser to utilize the advantages, as described above, of the first mode of operation <NUM>, or of the advantages of the second mode of operation <NUM>, providing three distinct benefits. Firstly, this configuration choice can be implemented at a lower total cost than the cost of acquiring two different systems that are permanently configured to the first mode of operation <NUM> and the second mode of operation <NUM>. Second, the ability to transition to the second mode of operation only requires a marginal additional investment in that the payment processing and other complex functionality of the system is already provided by the initial device and the additional device is inexpensive because it provides a much more limited set of functionalities. Third, in accordance with the approaches disclosed below, transitioning the system from the first mode of operation <NUM> to the second mode of operation <NUM> can, by virtue of the novel design, be accomplished with very little technical skill and time, thus permitting system reconfiguration in almost any commercial transaction environment.

The connection step <NUM> provides an example of how the dual mode payment interface device <NUM> can be transitioned between the first mode of operation and the second mode of operation. In step <NUM>, dual mode payment interface device <NUM> is connected to a merchant display device <NUM> by a wire <NUM> that provides a communicative connection between the two devices. The connectors at each end of the wire <NUM> can, but are not required to be, the same type of connector, and can follow known connection standards such as USB, USB-B, USB-C, Thunderbolt, Lighting, or HDMI. The wire end connectors can transmit and receive electrical signals to and from the devices, wherein the wire <NUM> itself can carry the electrical signals between end connectors. The merchant display device <NUM> can have a second touch screen display <NUM>, wherein the second touch screen display <NUM> can provide access to the merchant system interface <NUM>. In specific embodiments, the second mode of operation <NUM> is enabled by the communicative connection. The dual mode payment interface device <NUM> can detect the communicative connection and enable the second mode of operation <NUM> in response to detecting the communicative connection. The dual mode payment interface device <NUM> can include a means for detecting the communicative connection and a means for enabling the second mode of operation <NUM>.

Enabling the second mode of operation can involve various aspects. Enabling the second mode of operation can include allowing dual mode payment interface device <NUM> to enter a mode in which it only displays the customer system interface on its own screen and transmits the information necessary to display the merchant system interface over the wire for ultimately presentation on the merchant display device <NUM>. The means for enabling the second mode of operation can switch device <NUM> into this mode of operation automatically or provide a prompt requesting user confirmation that the mode of operation should be entered. In general, enabling the second mode of operation involves allowing the device to enter that mode either automatically or through some form of user input such as selection of the mode in a settings menu. Enabling the second mode of operation can also include causing device <NUM> to provide a customer system interface <NUM> on the touch screen display <NUM> of the dual mode payment interface device <NUM> while, concurrently, the device does not provide access to the merchant system interface <NUM> on the touch screen display <NUM>. The dual mode payment interface device <NUM> is programmed to lock-in to the second mode of operation <NUM> upon detecting the communicative connection. When locked-in, the dual mode payment device will only be capable of providing the customer system interface and will stay in that mode until the communicative connection is lost.

<FIG> provides a block diagram and flow chart demonstrating one example of a set of methods for using a dual mode payment interface device, as described in part previously with reference to <FIG>, when it is used by users in the first mode of operation <NUM>, when it is being connected to additional hardware and devices in a connection step <NUM>, and when it is used by users in the second mode of operation <NUM>. In this figure, rectangular blocks with solid borders can indicate devices comprising physical structure and electrical hardware, rectangular blocks with smoothed corners and broken borders can indicate method steps of the embodied systems and methods, and solid arrows that connect two blocks together can indicate a unidirectional or bidirectional communicative connection between, modification to, or enablement of, those blocks.

The connection step <NUM> can be considered as a subset of operational behavior of the disclosed systems while in the first mode of operation <NUM>. In some embodiments, a dual mode payment interface device <NUM> will begin in the first mode of operation <NUM> wherein the customer and the merchant share the interface of the dual mode payment interface device <NUM> to proceed with the commercial transaction. The dual mode payment interface device <NUM> can be reoriented to become merchant facing <NUM>, after which the interface can provide access to the merchant system interface <NUM> to show prompts for inputs, and other information, to the merchant. Alternatively, the dual mode payment interface device <NUM> can be reoriented to become customer facing <NUM>, after which the interface can provide access to the customer system interface <NUM> to show prompts for inputs, and other information, to the customer. The reorientation of the device and the displaying of interfaces can happen any number of times and in any order.

A wire <NUM> provides a communicative connection <NUM> between a dual mode payment interface device <NUM> and a merchant display device <NUM> in the connection step <NUM> and, thereby, the second mode of operation is enabled <NUM>. In one embodiment, when the dual mode payment interface device <NUM> and the merchant display device <NUM> are communicatively connected, the dual mode payment interface device <NUM> can detect the communicative connection <NUM>. In one example, the dual mode payment interface device <NUM> is programmed to lock-in the second mode of operation <NUM> upon detecting the communicative connection <NUM>. In one example, the dual mode payment interface device <NUM> is configured to switch <NUM> from the first mode of operation <NUM> to the second mode of operation <NUM> automatically upon detecting the communicative connection <NUM>.

The dual mode payment interface device <NUM> can be in the second mode of operation <NUM>. In one example, the dual mode payment interface device can be connected to the merchant display device <NUM>, wherein the two connected devices can be oriented to be customer facing <NUM> and merchant facing <NUM>, respectively. In the same example, the dual mode payment interface device <NUM> provides access to a customer system interface <NUM> on its touch screen display and does not provide access to the merchant system interface on its touch screen display. In the same example, the merchant display device <NUM> provides access to a merchant system interface <NUM> on its touch screen display.

While the aforementioned embodiments and described advantages of the specific disclosed systems and methods stand on their own, certain additional characteristics of the disclosed systems and methods, related to the security features, user ergonomics, and transaction efficiency, will now be described.

According to the invention a dual mode payment interface device is locked-in to the second mode of operation by the communicative connection for additional security. The dual mode payment interface device can express the second mode of operation, and only the second mode of operation, while the communicative connection between the merchant display device and the dual mode payment interface device is detected. These approaches provide significant benefits in that the merchant operator of the merchant display device can remain confident that the dual mode payment interface is not being used to access the merchant system interface so long as the display of the merchant display device is presenting the merchant system interface. To this end, even if the system occasionally places the merchant display device in an idle state in which the screen is not active, the merchant display device can still receive a specific screen saver indicative of the communicative connection remaining active. Then, if the display of the merchant display device ever indicates that the communicative connection has been lost, the merchant will know to stop allowing customers to interact with the dual mode payment interface device and trouble shoot the system.

In specific embodiments, a dual mode payment interface can be conceptualized as the customer-facing device when it is operating in combination with the merchant display device, and the merchant display device can, of course, be conceptualized as an add-on merchant-facing device. In alternative approaches, the add-on device is a customer-facing device. However, using a device with a payment interface as the customer-facing device in the combined system offers significant benefits. For example, the add-on device can be a more basic piece of hardware that only provides a display and a way to receive commands instead of the complex hardware required to encrypt and secure payment information. Therefore, the system can be upgraded at lower cost than would otherwise be required. As another example, the combined system offers certain security benefits. Due to industry security requirements, such as those put forward by the payment card industry (PCI), payment information needs to be heavily secured at all phases of use during payment processing. For example, the information must be encrypted as soon as it is received by the system. In alternative approaches in which the add-on device is designed to receive payment information and transfer it to a payment information processing system on the main device, a complex system would need to be put in place to assure that the information was encrypted as it was first received and transferred to the peripheral. However, this requirement is avoided by having the main device be the customer-facing device when operating in the combined system because it is already equipped to securely receive and transmit payment information for processing by a remote approval system.

In specific embodiments, a dual mode payment interface device is configured to switch from the first mode of operation to the second mode of operation automatically upon detecting the communicative connection. For example, the operating system of the dual mode payment interface may include an event listener set to detect connection on the port designed for the wire to the merchant display device, and a routine that immediately instantiates a second display and beings transmitting information regarding the merchant system interface to that second display when a connection is formed by the driver operating the port. These approaches provide certain benefits in that the same device can quickly switch between modes as the immediate needs of the merchant's store changes. The dual mode payment interface device can also switch back to the first mode of operation with some degree of flexibility. However, given security concerns, in some approaches the display of the dual mode payment interface device will first present a request for a merchant unlock when switching back to the first mode of operation. The merchant unlock can require the entry of a merchant PIN or a physical key before reverting the dual mode payment interface device to the first mode of operation. The second mode of operation may commence with the presentation of a "Confirm" request on the display of the merchant display device via the wire and/or the display of the dual mode payment device. The second mode of operation may also commence with the presentation of a confirm request on the dual mode payment interface device before the dual mode payment interface device presents the customer system interface.

<FIG> illustrates a block diagram for a hardware configuration scheme that represents an embodiment of the systems and methods disclosed herein. <FIG> includes a payment interface device <NUM> and a peripheral device <NUM>. In this figure, solid and dotted lines that connect two blocks indicate a direct and two-way communicative connection between those blocks, and blocks with dotted outlines indicate optional variations of the illustrated system. Lines with arrow heads indicate one-way communication between the blocks in the direction of the arrows.

In one embodiment, the payment interface device <NUM> can include an applications microprocessor <NUM> that can instantiate an operating system. As illustrated, the peripheral device <NUM> does not include a microprocessor. The operating system can be any type of operating system commonly used in the mobile devices, such as iOS, Android, Android Go, Tizen, BlackBerry, Windows Mobile, and other operating systems. In this embodiment, the operating system can control both: one system interface displayed on the payment interface device <NUM> touch screen display <NUM>; and another system interface displayed on the peripheral device <NUM> touch screen display <NUM>; wherein the system interfaces can operate as customer system interfaces and merchant system interfaces as described previously with reference to <FIG>, or any other types of interfaces.

In one example where the Android operating system can be utilized for controlling the displays <NUM> and <NUM>, the operating system can leverage native applications, such as those available in Android, version <NUM> and later, or third-party applications, to enable the applications microprocessor <NUM> to implement system interfaces across multiple displays. In one example, the applications microprocessor <NUM> can be a Qualcomm Snapdragon series microprocessor, or another mobile device processor commonly used for managing multiple displays. The touch screen displays <NUM> and <NUM> can optionally be augmented with other types of displays, such as those that do not have touch screen capability, including LED, LCD, e-paper, and other display types, and can optionally have connected data input devices, such as key pads, key boards, PIN pads, or other data input devices to augment the input of information by the users of the devices.

In one embodiment, the payment interface device <NUM> can have a payment interface <NUM>. The payment interface can receive payment information as input, which includes account numbers, personal identification numbers (PINs), biometric information, passwords, or any other information that is used by a payment processor to authorize the transfer of funds from one entity to another. Common examples of payment information include <NUM>-digit credit card numbers for credit card transactions and <NUM>-digit PINs for debit card transactions. Means for receiving payment information include key pads for receiving PINs, bar code scanners (including QR code scanners), magnetic stripe readers (MSRs) for reading magnetically encoded account numbers, near field communication (NFC) readers for contactless payment processing, finger print readers, infrared surface or gesture analyzers, chip card readers, microphones for receiving auditory information, and other methods known in the industry. In one example, the payment interface device <NUM> can optionally include a secure microprocessor <NUM> to process payment information in a cryptographically secure manner. The devices that receive payment information generally also include injected payment keys that are used to encrypt payment information for transfer to a payment processor. In embodiments where a secure microprocessor <NUM> is present and connected to the applications microprocessor <NUM>, the connection is configured such that in cases where secure information, such as payment information, is unencrypted, it cannot be communicated from the secure microprocessor <NUM> to the applications microprocessor <NUM>.

In some embodiments, the payment interface device <NUM> can include an electronic memory <NUM> to store data, programs, and applications for the applications microprocessor <NUM> to process, including operating systems and interface systems. In one example, the memory <NUM> can be volatile memory device such as dynamic random access memory, static random access memory, or other types of volatile memory commonly used in mobile devices. In another example, the memory <NUM> can be non-volatile memory device such as solid state hard disk, mechanically rotating hard disk, an optical disc, or other type of non-volatile memory commonly used in the industry.

In some embodiments, the payment interface device <NUM> and peripheral device <NUM> can include accessories <NUM> which add various types of functionality to the devices installed thereon. The accessories <NUM> of the payment interface device <NUM> and the peripheral device <NUM> can be the same, can have some in common and others specific to one device or the other, or can comprise different groups of accessories with no overlapping form or function. Examples of accessories commonly used in payment interface devices and display devices including image sensors, microphone devices, audio speakers, thumb print readers, mouse touchpads, and modems configured with wireless radios that can act as a transceiver for wireless communications of any standard type or frequency band, including such standards as the Wi-Fi / IEEE <NUM> series, EDGE, the EV-Do series, Flash-ODFM, GPRS, the HSPA standards, Lorawan, LTE, RTT, the UMTS series, WiMAX, 6LoWPAN, the Bluetooth series, IEEE <NUM>. <NUM>-<NUM>, Thread, UWB, Wireless USB, ZigBee, ANT+, and other standards.

In some embodiments, the accessories <NUM> can be connected to an accessory hub <NUM>. In one example, the payment interface device <NUM> can have an accessory hub <NUM> and accessories <NUM>, in which the accessories <NUM> are connected to an accessory hub <NUM>, which is further connected to the applications microprocessor <NUM>. In this example, the connections can be communicative connections and the applications microprocessor <NUM> can send information and individual instructions to the accessories <NUM> for their operation, such as a command to take a picture with an image sensor, as well as receive information from the accessories <NUM>, such as receiving the picture taken with the image sensor to store in the memory <NUM>. On the peripheral device <NUM>, accessories <NUM> can interact with an accessory hub <NUM> using the same configurations and methods described for the payment interface device <NUM>.

In some embodiments, the accessories hub <NUM> can have permanent connections to internal components such as accessories <NUM>, as well as non-permanent connections to devices external to the device on which the accessory hub <NUM> is installed. In a first example, a non-permanent, optional, external connection can be constructed between the payment interface device <NUM>, or the peripheral device <NUM>, and other devices using electrical data cables with end connectors chosen by the standard associated with of the data cable type. In this example, the data cable type can be any type, and the accessory hub <NUM> can have data cable end connector receptors that accept the type of data cable end connector used, which can include ethernet, token ring, coaxial, optical fiber, serial cable, Cat2, telephone cable, universal serial bus (USB) cable, or other data cable type used for sending digital information. Alternatively, the data cable can be specific to the communication of video information, in which case the types of data cables can include s-video, component video, DVI, HDMI, display port, CoaXPress, and MHL, and other video cable types. In a second example, a non-permanent, optional, external connection can be constructed between the payment interface device <NUM>, or the peripheral device <NUM>, using a wireless connection. In this example, the connected devices have modems with wireless transceivers that operated and connect using standards and protocols as described above, in which the modem can be one of the accessories <NUM>. In a third example, a non-permanent, optional, external connection can be constructed between the payment interface device <NUM> and the peripheral device <NUM> using a communicative connection <NUM>. The communicative connection <NUM> can be constructed between the accessory hubs <NUM> of the respective devices, using either of the data cable or wireless methods described previously. With reference back to <FIG>, communicative connection <NUM> can be provided by wire <NUM> and provide the service of step <NUM> described above.

In some embodiments, the payment interface device <NUM> and the peripheral device <NUM> can have specific accessories <NUM>, and can make use of one or more communicative connections <NUM>, to facilitate an efficient and secure commercial transaction through the use of the accessories <NUM> and communicative connections <NUM>. One example of a method that facilitates an efficient and secure commercial transaction is described previously with reference to the method steps in <FIG>. In one example, the touch screen display <NUM> can be used to provide a customer with access to a customer system interface, instantiated by the application microprocessor <NUM> operating system, that can provide any type of customer-relevant commercial transaction information, commands, or prompts to the customer, such as guiding the customer through the necessary commercial transaction steps and providing the customer with a prompt for payment information. The customer can use the payment interface <NUM> in response to the prompt for payment information to make a payment using a compatible method, such as credit card, NFC, and others described previously. In another example building upon the configuration of the previous example, a communicative connection <NUM> can be established with the peripheral device <NUM> through the accessory hubs <NUM> of both devices, enabling the applications processor <NUM> operating system to implement a multi-screen display scheme. The multi-screen display scheme can further provide access to a merchant system interface by displaying, on touch screen display <NUM> of the peripheral device <NUM>, a merchant system interface to a merchant. The merchant system interface can provide any type of merchant-relevant commercial transaction information, commands, or prompts to the merchant, such as a prompt for payment total confirmation to authorize the commercial transaction. The utilization of the touch screen display <NUM> by the applications processor <NUM> through the accessory hub <NUM> of the peripheral device <NUM> renders the touch screen display <NUM> a specific species device in the genus of accessories <NUM> devices. In another example, the communicative connection <NUM> can be established between other types of devices, such as a printer device, to the accessory hubs <NUM> of the payment interface device <NUM> or of the peripheral device <NUM>. Through the communicative connections <NUM>, the applications microprocessor <NUM> can send commands to, provide prompts to, receive inputs from, and provide user interfaces to the displays of, the other types of devices, in addition to any other type of control afforded by the capabilities of the applications microprocessor <NUM>. As illustrated, the applications microprocessor <NUM> could also have a more direct connection to provide display information to the touch screen display <NUM> that bypasses accessor hub <NUM>. A specific example in which communicative connection <NUM> includes both communication pathways is disclosed below with reference to <FIG>.

While the aforementioned embodiments and described advantages of the disclosed systems and methods stand on their own, certain additional characteristics of the disclosed systems and methods, related to the device configurations and their use modes, will now be described.

In some embodiments, a commercial transaction process between a customer and a merchant can be carried out using only payment interface device. In one example, the payment interface device can be used in a POS configuration wherein the merchant is the sole user. The merchant can input sale item and customer information into the payment interface device using the touchscreen display displaying the merchant system interface, and can receive the physical representation of payment from the customer, which can be cash, a credit card, or any method described previously, and can conclude the transaction with the printing of a receipt for the customer to physically sign, or the entry of a PIN on a PIN pad, for payment authorization. In one example, the payment interface device can be used in a POS configuration wherein the device is shared between the customer and the merchant. In this example, the payment interface device can be rotated between users as described previously with reference to the first mode of operation in <FIG> in order to input transaction information in a fast and secure fashion.

In some embodiments, a commercial transaction process between a customer and a merchant can be carried out beginning with a payment interface device and, at a later time, a peripheral device can be connected to the payment interface device with a communicative connection. In one example, the payment interface device is a dual mode device. In a first mode, the payment interface device can operate as described in the previous paragraph. In another example, while the payment interface device is in a first mode, a communicative connection can be made between the payment interface device and a peripheral device, causing the payment interface device to enter into a second mode. In this example and while in the second mode, the user can use the payment interface device to complete their portion of the commercial transaction while the merchant can use the peripheral device to complete their portion of the commercial transaction. Continuing in the example and while in the second mode, the applications processor instantiates an operating system which can generate and control multiple display screens and show a merchant system interface and a customer system interface on the peripheral device and the payment interface device respectively.

<FIG> illustrates a block diagram for configurations of hardware modules and software modules that can be used to describe the means for detecting and the means for enabling mentioned above. The means for detecting can serve to detect a communicative connection <NUM> between a payment interface device <NUM> and a peripheral device <NUM>, and other devices. The means for enabling can serve to enable the second mode of operation of the payment interface device <NUM>, and other device modes. In this figure, solid lines that connect two blocks indicate a direct and two-way communicative connection between those blocks, rectangular blocks with solid borders indicate hardware modules whereas rectangular blocks with broken borders indicate software modules, and rectangular blocks with broken outlines and rounded corners indicate a process step used for the means for detecting or the means for enabling that can receive, generate, or transmit information that can travel along the block connections and through any number of blocks.

In some embodiments, the means for detecting can be located on and implemented by the payment interface device <NUM>, while using and being contingent upon peripheral hardware modules <NUM> and peripheral software modules <NUM> on the peripheral device <NUM>. The modules <NUM> and <NUM> can contain secure or unique identifiers that can be recognized by the payment interface device <NUM>. In a first example, the means for detecting can include specific kinds of peripheral hardware modules <NUM>, or subcomponents thereof, containing device type identifiers, such as an accessory port type, an accessory hub type, a memory device type, a display device type, a speaker type, an image sensor type, a light sensor type, a thermal sensor type, a microphone type, a wireless modem type or type of any subsystem thereof, a data input device type, or another device type. The device type can be represented by any combination of type identifiers, such as the device company brand, manufacturing ID, industry standard, model number, or other hardware identifiers common to microelectronic devices. In a second example, the means for detecting can include specific kinds of peripheral software modules <NUM>, such as algorithms, operating systems, routines, applications, programs, code sequences, or other computer language-based identifiers. Specific examples of peripheral software modules <NUM> can include a device driver for any of the devices listed above, a software module stored in a memory, a noncompilable data file, a cryptographic key, or an embedded security signature.

In some embodiments, the means for detecting can include hardware modules and software modules on the payment interface device <NUM>. The means for detecting can include hardware modules such as a port on applications processor <NUM> that is dedicated for connections to peripherals, or a peripheral hub, that is designed to detect an electrical connection and inform an operating system <NUM> of the connection. The means for detecting can include routines <NUM> built into an operating system <NUM> of the payment interface device <NUM>, wherein the routines <NUM> can be coded using the source code recognized by the operating system <NUM>, the operating system <NUM> is instantiated by an applications processor <NUM>, and the operating system <NUM> stored in a memory <NUM>. If the operating system <NUM> were an Android operating system, the routines <NUM> could be written in Java, C++, Python, or some other language recognized by the Android operating system standards. The routine <NUM> can include an event listener <NUM> designed to detect when the portion of the operating system <NUM> responsible for interfacing with the peripheral device <NUM> can detect a communicative connection <NUM>. The event listener <NUM> can be targeted to monitor and identify peripheral hardware modules <NUM> and peripheral software modules <NUM>, such as a specific port into which a peripheral device <NUM> could be connected to communicate with the operating system <NUM> on the payment interface device <NUM> through a communicative connection <NUM>. In this example and using an Android operating system <NUM> as an example, the event listener <NUM> can register to receive broadcasts from the PeripheralManager system service. The means for detecting can include registering an event listener <NUM> with the operating system <NUM>, transmitting a peripheral device <NUM> connection by the PeripheralManager, and receiving that broadcast at the payment interface device <NUM> with the registered event listener <NUM>. Instead of the PeripheralManager, the means for detecting could alternatively include the Android Hardware Abstract Layer (HAL) operating in combination with the Linux operating system. In particular, the Linux USB driver in the kernel of an applications processor, such as applications processor <NUM>, could detect a USB connection and inform the Android HAL of the connection. The means for detecting could alternatively include the Android USBManager. In these implementations, the means for detecting would involve routines coded at the level of the Android operating system interfacing directly with the USB protocol via a port on the applications processor, such as applications processor <NUM> as opposed to communicating via the USB driver of the kernel.

In some embodiments, the means for detecting, using any of the embodiments described above with reference to <FIG>, can enable a change of mode of operation of the payment interface device <NUM>. The payment interface device <NUM> can begin operation in a first mode of operation. Subsequently, the means for detecting can detect a communicative connection <NUM>, and the means for enabling can enables a second mode of operation <NUM> in response to the means for detecting. An applications processor <NUM> can be programmed to detect a communicative connection <NUM> and the programming can be stored in a memory <NUM>. The means for enabling can likewise, as illustrated, include programming stored in memory <NUM>. The means for enabling can include instructions to enable the second mode of operation <NUM>. This programming may enable a user to confirm that the second mode of operation should be entered via the display of a prompt for that confirmation or via unlocking a menu option to receive that confirmation. The means for enabling include instructions to lock-in <NUM> the second mode of operation wherein the programming to lock-in can be implemented by the applications processor <NUM> and stored in the memory <NUM>. The means for enabling can additionally or alternatively include instructions to automatically switch <NUM> from the first mode of operation to the second mode of operation upon the detecting of a communicative connection <NUM> with the means for detecting. The programming to automatically switch <NUM> can be stored in a memory <NUM>.

In some embodiments, the means for enabling can include hardware and software modules on the payment interface device <NUM> that serve to enable a second mode of operation <NUM> for the payment interface device <NUM> and the peripheral device <NUM>. The means for enabling <NUM> can be designed to trigger the creation of multiple system interfaces by the payment interface device <NUM>, using multi-display operating system <NUM> capabilities. In one example, when multiple system interfaces are created, one system interface can be shown on a touch screen display <NUM> on the payment interface device <NUM>, and another system interface can be shown on a peripheral hardware modules <NUM> touch screen display on the peripheral device <NUM>. The means for enabling can include routines <NUM> built into the operating system <NUM> of the payment interface device <NUM>. The routines <NUM> can be coded using the source code recognized by the operating system <NUM>. For example, if the operating system <NUM> were an Android operating system the routines can be written in Java, C++, Python, or some other language. The routines could be written at the level of the Android HAL or at a lower level of the operating system.

In specific embodiments, the routines <NUM> can use a multi-display mode <NUM>, native to operating system <NUM> versions of Android <NUM> and later, to utilize commands to control the dimensions, pixel resolution, orientation, and other characteristics of the system interfaces to display properly on multiple displays. The multi-display mode <NUM> can enable the applications processor <NUM>, in response to detecting a communicative connection <NUM> and enabling a second mode of operation <NUM>, to generate a customer system interface on the touch screen display <NUM> on the payment interface device <NUM>, and to generate a merchant system interface on a peripheral hardware modules <NUM> touch screen display on the peripheral device <NUM> by sending the merchant system interface display information to the peripheral device <NUM> through the communicative connection <NUM>. The applications processor <NUM> can receive inputs through the merchant system interface displayed on the peripheral hardware modules <NUM> touch screen display, indicated by touch information provided on the touch screen display by the user, and sent to the applications processor <NUM> through the communicative connection <NUM>. If the system is programmed to automatically switch <NUM>, the displays can be generated automatically and as soon as the detection of a communicative connection <NUM> occurs. The system is programmed to lock-in the second mode of operation <NUM>, and the displays can be generated as described in the first example and the mode of operation cannot change in response to inputs provided by a user using the payment interface device <NUM>, such as a customer interacting with the payment interface device <NUM> through a customer system interface. Alternatively, the displays can be generated as described in the first example and the mode of operation can change in response to inputs provided by a user using the payment interface device <NUM> only if the user enters a secure command to unlock, such as a merchant interacting with the payment interface device <NUM> through a customer system interface.

<FIG> illustrates the configuration of hardware modules on a dual mode payment interface device <NUM> and a merchant display device <NUM> that is in accordance with systems and methods disclosed herein. In this figure, solid lines without arrows that connect two blocks indicate a direct and two-way communicative connection between those blocks, while solid lines with arrows that connect two blocks indicate a direct, communicative connection in the direction of the arrows. Additionally, rectangular blocks with solid borders indicate hardware modules and rectangular blocks with broken borders indicate hardware that is supplemental to, but not part of, the main system. Data, digital files, and device information can travel along the block connections and through the illustrated blocks.

In some embodiments, the dual mode payment interface device <NUM> can be used in a cordless configuration while powered by an internal battery <NUM>. Alternatively, the dual mode payment interface device <NUM> can be powered by a power and module hub <NUM> connected to an alternating current (AC) to direct current (DC) converter <NUM> that is plugged into a standard wall electricity outlet. The battery <NUM> can be charged while the dual mode payment interface device <NUM> is powered by the power and module hub <NUM>. The dual mode payment interface device <NUM> can print on paper media to produce documents, such as commercial transaction receipts, using a printer <NUM> that is connected to the dual mode payment interface device <NUM> through the power and module hub <NUM>. The power and module hub <NUM> can connect to the dual mode payment interface device <NUM> using an onboard accessories hub <NUM>, through which commands can be sent from the applications microprocessor <NUM> to peripheral devices, such as the printer <NUM> and the merchant display device <NUM>, or to other internal hardware modules, such as a modem <NUM>. In some embodiments, the dual mode payment interface device <NUM> has internal hardware modules that can enable features such as speech recognition through a microphone <NUM>, image capture, video capture, and facial recognition with an image sensor <NUM>, audio playback through a speaker <NUM>, and wireless communication by a wireless modem <NUM>, all of which can be connected directly to the applications microprocessor <NUM>. In the embodiments above, the listed hardware modules can comprise any make, model, or type of device commonly used in mobile applications. For example, the battery <NUM> can be a lithium-ion battery, the accessories hub <NUM> can be configured to interface with other devices using USB connection standards, and the applications microprocessor <NUM> can be a Qualcomm Snapdragon microprocessor.

In some embodiments, a system comprising a dual mode payment interface device <NUM> with a touch screen display <NUM> and a memory <NUM> can operate in a first mode of operation, wherein a user, such as a merchant, can use the dual mode payment interface device <NUM> to carry out a commercial transaction. The touch screen display <NUM> can be of any size, wherein a display with a diagonal length of fourteen inches can be ideal for managing both the provided information and the information input tools. The memory <NUM> serves the applications microprocessor <NUM> in storing an operating system and programming needed to run the dual mode payment interface device <NUM> with connected peripheral devices. In one example, the applications processor <NUM> can provide access to a merchant system interface on the touch screen display <NUM>, wherein a merchant uses the merchant system interface to carry out a commercial transaction. When payment information must be provided to the system, the merchant can use any of the payment interfaces on the dual mode payment interface device <NUM>, which can be, for example, a near field communications (NFC) interface <NUM>, an integrated circuit card (ICC) interface <NUM>, and a magnetic stripe reader (MSR) <NUM>. Payment information provided by the methods and interfaces described here can be transferred to a secure microprocessor <NUM> for payment completion, wherein the unsecured applications microprocessor <NUM> does not gain access to unencrypted payment data and the secure microprocessor <NUM> has access to network resources of the modem <NUM> via the accessories hub <NUM>. In one example, the secure microprocessor <NUM> can be a Broadcom StrataGX device, or any other cryptographically secure processor or microcontroller.

In some embodiments, a system comprising a dual mode payment interface device <NUM> with a touch screen display <NUM> and a memory <NUM> can operate in a first mode of operation, wherein more than one user, such as a customer and a merchant, can share the dual mode payment interface device <NUM> to carry out a commercial transaction. The transaction can carry out as described in the previous paragraph with the following exceptions. The touch screen display <NUM> can display a customer system interface to be used by the customer as well as a merchant system interface to be used by the merchant, as described previously with respect to <FIG>. The switching of the system interfaces can be triggered by an input given to the dual mode payment interface device <NUM>, for example, through an input to the touch screen display <NUM>, through the receipt of payment information by one of the payment interfaces <NUM>, <NUM>, and <NUM>, a verbal command received by the microphone <NUM>, a facial recognition algorithm stored in the memory <NUM> and used by the image sensor <NUM>, or another method. The customer system interface can be used by the customer to carry out the submission of payment information, thereby providing additional security to the payment information through removal of the merchant in this process step.

In some embodiments, the system can comprise a dual mode payment interface device <NUM> in a first mode of operation connecting to a merchant display device <NUM> through a communicative connection <NUM>, and, for example, switching to, automatically switching to, or locked-in to a second mode of operation. In the second mode of operation, the commercial transaction can be performed by a customer using a customer system interface shown on touch screen display <NUM> on the dual mode payment interface device <NUM> and a merchant using a merchant system interface shown on the touch screen display <NUM> on the merchant display device <NUM>. In these embodiments, the functionality provided by second mode of operation can be controlled by the applications microprocessor <NUM> to the dual mode payment interface device <NUM> using methods described above. The connection between touch screen display <NUM> and applications microprocessor <NUM> can be a two directional connection between two dedicated ports on applications microprocessor <NUM> with one port being a dedicated touch controller input port and out port being a dedicated display port. Additionally, control of the merchant display device <NUM> can be accomplished with the communicative connection <NUM> comprising two separate wires. The first wire can be used by a unidirectional connection from the applications microprocessor <NUM> directly to the touch screen display <NUM>. The wire can be a display peripheral wire. This connection can transition through a display port (DP) and mobile industry processor interface (MIPI) display serial interface (DSI) bridge <NUM> that sends the merchant system interface. In other embodiments where touch screen display <NUM> is DP compatible, bridge <NUM> can be removed. The second wire can be used by a bi-directional connection from the applications microprocessor <NUM> to the remaining merchant display device <NUM> hardware modules by way of the accessories hub <NUM> on both devices <NUM> and <NUM>. The wire can be a USB cord. Touch data from touch screen display <NUM> can be routed back to applications microprocessor <NUM> via bridge <NUM> and the accessory hubs <NUM> in order for the merchant inputs to the merchant system interface to affect the transaction.

Audio information, such as a prompt for payment total confirmation, can be sent to the merchant using the speaker <NUM> on the merchant display device <NUM>. Data sent to this end can be processed through an audio codec <NUM> to be converted to a format usable by the speaker <NUM>. Audio data to be received by the applications microprocessor <NUM> from the merchant display device <NUM>, such as voice commands, can originate from the microphone <NUM> thereon and be formatted by the audio codec <NUM> for sending to the accessories hub <NUM>.

The merchant display device <NUM> can include an image sensor <NUM> for image capture, video capture, and facial recognition, for example to unlock the device with a cleared facial recognition identity, with a MIPI camera serial interface (CSI) to USB bridge <NUM> for image data conversion when sending image data to the applications microprocessor <NUM>.

The merchant display device <NUM> can be equipped with a security finger print scanner (FPS) <NUM>. The FPS <NUM> can be put in communication with the accessories hub <NUM> on the merchant display device <NUM> by a serial peripheral interface (SPI) / inter-integrated circuit (I2C) to USB bridge <NUM>.

Claim 1:
A system comprising:
a dual mode payment interface device (<NUM>) having a touch screen display (<NUM>);
a merchant display device (<NUM>) having a second touch screen display (<NUM>);
a wire (<NUM>) that provides a communicative connection between the dual mode payment interface device (<NUM>) and the merchant display device (<NUM>);
the system alternatively operating in a first mode of operation (<NUM>) and a second mode of operation (<NUM>);
wherein the first mode of operation (<NUM>) provides access to a merchant system interface (<NUM>) on the touch screen display (<NUM>) and provides access to a customer
system interface (<NUM>) on the touch screen display (<NUM>); and wherein the second mode of operation (<NUM>) provides access to the customer system interface (<NUM>) on the touch screen display (<NUM>) and does not provide access to the merchant system interface (<NUM>) on the touch screen display (<NUM>), but instead provides access to the merchant system interface (<NUM>) on the second touch screen display (<NUM>);
characterized in that
the second mode of operation (<NUM>) is enabled by the communicative connection; and
wherein enabling the second mode of operation (<NUM>) comprises:
(i) locking in the second mode of operation (<NUM>) in response to detecting the communicative connection; and
(ii) maintaining the second mode of operation (<NUM>) as locked-in until the communicative connection is lost.