WO2016069775A1 - Secure extensible point of sale platform - Google Patents

Secure extensible point of sale platform Download PDF

Info

Publication number
WO2016069775A1
WO2016069775A1 PCT/US2015/057863 US2015057863W WO2016069775A1 WO 2016069775 A1 WO2016069775 A1 WO 2016069775A1 US 2015057863 W US2015057863 W US 2015057863W WO 2016069775 A1 WO2016069775 A1 WO 2016069775A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
pos
sale
point
secure
Prior art date
Application number
PCT/US2015/057863
Other languages
French (fr)
Inventor
John Daniel BEATTY
Leonard Robert Speiser
Angelique Julie LAUSIER
Tamer Mohamed EL CALAMAWY
Michael Joseph QUINLAN
Abhinayak Mishra
Jeffrey Blattman
Jacob Whitaker ABRAMS
Eric David FUHS
Sam Niansheng QIU
Alvin Alza DOMINGUEZ
Arvin Carl Robert HAYWOOD
Original Assignee
Clover Network, Inc.
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
Priority to US201462072420P priority Critical
Priority to US62/072,420 priority
Priority to US201462074062P priority
Priority to US201462074061P priority
Priority to US201462074063P priority
Priority to US201462074064P priority
Priority to US62/074,064 priority
Priority to US62/074,063 priority
Priority to US62/074,061 priority
Priority to US62/074,062 priority
Application filed by Clover Network, Inc. filed Critical Clover Network, Inc.
Publication of WO2016069775A1 publication Critical patent/WO2016069775A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82Protecting input, output or interconnection devices
    • G06F21/85Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 – G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/1613Constructional details or arrangements for portable computers
    • G06F1/1633Constructional details or arrangements of portable computers not specific to the type of enclosures covered by groups G06F1/1615 - G06F1/1626
    • G06F1/1684Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675
    • G06F1/1694Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675 the I/O peripheral being a single or a set of motion sensors for pointer control or gesture input obtained by sensing movements of the portable computer
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 – G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/1613Constructional details or arrangements for portable computers
    • G06F1/1633Constructional details or arrangements of portable computers not specific to the type of enclosures covered by groups G06F1/1615 - G06F1/1626
    • G06F1/1684Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675
    • G06F1/1698Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675 the I/O peripheral being a sending/receiving arrangement to establish a cordless communication link, e.g. radio or infrared link, integrated cellular phone
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/03Arrangements for converting the position or the displacement of a member into a coded form
    • G06F3/041Digitisers, e.g. for touch screens or touch pads, characterised by the transducing means
    • G06F3/0416Control or interface arrangements specially adapted for digitisers
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/202Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/206Point-of-sale [POS] network systems comprising security or operator identification provisions, e.g. password entry
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/005Discovery of network devices, e.g. terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2200/00Indexing scheme relating to G06F1/04 - G06F1/32
    • G06F2200/16Indexing scheme relating to G06F1/16 - G06F1/18
    • G06F2200/161Indexing scheme relating to constructional details of the monitor
    • G06F2200/1614Image rotation following screen orientation, e.g. switching from landscape to portrait mode
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2200/00Indexing scheme relating to G06F1/04 - G06F1/32
    • G06F2200/16Indexing scheme relating to G06F1/16 - G06F1/18
    • G06F2200/163Indexing scheme relating to constructional details of the computer
    • G06F2200/1637Sensing arrangement for detection of housing movement or orientation, e.g. for controlling scrolling or cursor movement on the display of an handheld computer

Abstract

A secure extensible point-of-sale (POS) platform is disclosed. The platform includes numerous features that are not found in traditional POS system. In some implementations, information regarding transaction modifications are synchronized throughout the POS platform. In some implementations, registered applications on the POS platform receive broadcasts regarding transaction modifications on the POS platform and take actions in response thereto. In some implementations, the POS platform includes a client device with a secure processor, a second processor, and a hardware multiplexer that routes data to the secure processor and second processor under the exclusive control of the secure processor. In some implementations, the POS platform includes a client device with a display configured to present a first interface and a second interfaced based on the position of the POS device. The first interface has a first set of functionalities that is prevented from being accessible in the second interface.

Description

SECURE EXTENSIBLE POINT OF SALE PLATFORM

CROSS REFERENCE TO RELATED APPLICATION

[0001]This application claims the benefit of U.S. Provisional Application No.

62/072,420, filed October 29, 2014, U.S. Provisional Application No. 62/074,061 , filed November 2, 2014, U.S. Provisional Application No. 62/074,062, filed on November 2, 2014, U.S. Provisional Application No. 62/074,063, filed on November 2, 2014, and U.S. Provisional Patent Application No. 62/074,064, filed on November 2, 2014, all of which are hereby incorporated by reference in their entirety for all purposes.

BACKGROUND OF THE INVENTION

[0002] Point-of-sale (POS) systems are computerized networks that allow users, such as merchants, to offer customers to complete goods or services sales transactions. POS systems typically include a main computer, to which POS terminals are connected. POS terminals replace conventional cash registers, and can take the form of, for example, a personal computer or a mobile device. POS systems can include additional devices such as credit card readers, scanners, receipt printers, and can include customized applications such as for inventory control and accounting. However, such systems may not provide a mechanism for secure transactions such as entering a PIN (personal identification number) associated with a credit, debit, EMV, and other payment cards, including cards having embedded integrated circuits for, among other things, authentication. The relative lack of security may lead to identity theft or fraudulent transactions, and ultimately a relatively poor consumer and/or merchant experience. Also, such systems do not allow for enhanced usability functions. The lack of options to interface with other electronic devices may lead to poor user experience and/or inefficient transactions. Also, such systems can be limited to built-in functionalities, which may hinder the flexibility. Some of the functions lacking from such systems may be the ability for third-party developers to tailor applications that provide customers with a variety of options during their purchasing experience.

[0003] POS terminals need to have a secure operating environment that guarantee unscrupulous people cannot steal sensitive data or hijack the payment processing capabilities of the device. Unfortunately, this results in POS terminals that are closed systems, and have very limited applications that can be used to customize and augment the terminal functionality. In addition, the terminal needs a dedicated PIN pad that needs to be physically protected to meet strict security requirements and needs physical and logical security to isolate sensitive data from the regular operating environment.

SUMMARY OF INVENTION

[0004] In one embodiment, a device is disclosed. The device comprises an input device with an input device user data connection to an input device controller. The device also comprises a multiplexer with a multiplexer control input port, a multiplexer data input port communicatively coupled to the input device controller, a first data output port, and a second data output port. The device also comprises a secure processor with: (i) a control output port communicatively coupled to the multiplexer control input port; and (ii) a secure processor data input port communicatively coupled to the first data output port. The device also comprises a second processor with a second processor data input port communicatively coupled to the second data output port. The multiplexer is configurable between a first state and a second state. The multiplexer data input port is

communicatively coupled to the first data output port through the multiplexer when a current state of the multiplexer is the first state The multiplexer data input port is communicatively coupled to the second data output port through the multiplexer when the current state of the multiplexer is the second state. The current state of the multiplexer is exclusively controlled by the secure processor via the control output port.

[0005] In another embodiment, an integrated circuit (IC) is disclosed. The IC comprises a multiplexer with a multiplexer control input port, a multiplexer data input port, a first data output port, and a second data output port. The IC also comprises an input pin communicatively coupled to the multiplexer data input port; a multiplexer control circuit communicatively coupled to the multiplexer control input port. The IC also comprises an input device data processing circuit communicatively coupled to the first data output port. The IC also comprises an output pin communicatively coupled to the second data output port. The multiplexer is configurable between a first state and a second state via the multiplexer control circuit. The multiplexer data input port is communicatively coupled to the first data output port through the multiplexer when a current state of the multiplexer is the first state. The multiplexer data input port is communicatively coupled to the second data output port through the multiplexer when the current state of the multiplexer is the second state.

[0006] In another embodiment, a method is disclosed. The method comprises receiving secure data from a user via an input device. The method also comprises routing the secure data to a secure processor using a hardware multiplexer. The method also comprises processing the secure data using the secure processor. The method also comprises receiving non-secure data from the user via the input device. The method also comprises routing the non-secure data to a second processor using the hardware multiplexer. The method also comprises processing the non-secure data using the second processor. The method also comprises altering a routing state of the hardware multiplexer using the secure processor. The routing state of the hardware multiplexer is only controlled by the secure processor.

[0007] In another embodiment, a method is disclosed. The method comprises receiving secure data from a user via an input pin of an integrated circuit. The method also comprises routing the secure data to an input device data processing circuit using a hardware multiplexer. The method also comprises processing the secure data using the input device data processing circuit. The method also comprises receiving nonsecure data from the user via the input pin. The method also comprises routing the non-secure data to an output pin of the integrated circuit using the hardware multiplexer. The method also comprises altering a routing state of the hardware multiplexer using the secure processor. The routing state of the hardware multiplexer is only be controlled by the secure processor.

[0008] In another embodiment, a computer-implemented method for pairing a point of sale printer with a client device, using two-way identification, is disclosed. The method comprises: receiving, using the point of sale printer and a wireless communication protocol, a request to pair the point of sale printer; deriving, using the point of sale printer, the client device, and a device pairing protocol, a shared secret at the client device and the point of sale printer; printing, using the point of sale printer and upon deriving the shared secret, client device association information on a printout; receiving, using the client device and the printout, the client device association information; and associating the point of sale printer and the client device using the client device association information as received using the client device.

[0009] In another embodiment, another computer-implemented method for pairing a printing device with a client device, using two-way identification, is disclosed. The method comprises: sending, from the client device, a request to pair the printing device; receiving, using the printing device and a wireless communication protocol, the request to pair the printing device; deriving, using the printing device and the client device, a shared secret in accordance with a device pairing protocol; printing, using the printing device, client device association information on a printout, wherein the client association information is based on the shared secret; receiving, using the client device and the printout, the client device association information; and automatically pairing the client device with the printing device upon receiving the client association information from the printout with the client device.

[0010] In another embodiment, a system for pairing a printing device with a client device, using two-way identification is disclosed. The system comprises a

communications module instantiated on the client device. The communications module is configured to send a request to pair the printing device using a wireless

communication protocol and subsequently derive a shared secret with the printing device The system also comprises a printer. The printing device is configured to instruct the printer to print client device association information upon the

communications module deriving the shared secret. The system also comprises a first printout. The first printout is printed by the printer and includes the client device association information that is printed upon the communications module deriving the shared secret. The system also comprises an input device, provided on the client device, to receive the client device association information. The communications module is also configured to associate the printing device with the client device using the client device association information received via the input device. [0011] In another embodiment, a computer-implemented method for an extensible point- of-sale device is disclosed. The method comprises registering a third-party application to be notified of a transaction change on the point-of-sale device. The method also comprises displaying a user interface to a user during a purchase transaction on a display of the point-of-sale device using one of a register module and a payment module. The method also comprises receiving the transaction change via the user interface of the point-of-sale device. The method also comprises broadcasting the transaction change to a set of registered applications that includes the third-party application. The method also comprises taking an action that modifies the purchase transaction using the third-party application in response to the broadcasting.

[0012] In another embodiment, an extensible point-of-sale device is disclosed. The device comprises a POS processing service that registers a third-party application to be notified of a transaction change on the point-of-sale device. The device also comprises a display that displays a user interface to a user during a purchase transaction. The device also comprises a register module that receives the transaction change involving the purchase transaction via the user interface of the point-of-sale device. The third- party application is configured to take an action to modify the purchase transaction in response to a trigger. The POS processing service is configured to provide the trigger via a broadcast of the transaction change to a set of registered applications that includes the third-party application.

[0013] In another embodiment, a computer-implemented method for an extensible point- of-sale device is disclosed. The method comprises displaying a user interface to a user during a purchase transaction on a display of the point-of-sale device using a register module. The method also comprises modifying a customer order with a modification received via the user interface of the point-of-sale device. The method also comprises updating a database using the modification and a server. The method also comprises broadcasting the modification to a plurality of other point-of-sale devices.

[0014] In another embodiment, POS device is disclosed. The device comprises a memory configured to store data and computer-executable instructions. The device also comprises a display configured to present a user interface. The user interface comprises a first interface and a second interface. The device also comprises a sensor configured to detect an adjustment in a physical position of the POS device from a first position and from a second position. The first interface is presented in the first position and the second interface is presented in the second position. The first interface has a first set of functionalities that is prevented from being accessible in the second interface.

[0015] In another embodiment, a computer-implemented method is disclosed. The method comprises receiving, by a POS device that includes one or more processors, a first indication of interaction with a merchant. The method also comprises presenting, by the POS device in response to the first indication, a first user interface associated with the merchant. The method also comprises detecting, by the POS device, an adjustment to an orientation of the POS device. The method also comprises

determining, by the POS device, based on the adjustment to the orientation, that the POS device is to interact with a customer. The method also comprises presenting, by the POS device in response to the determination, a second user interface associated with a customer interaction. The first user interface includes a first set of functionalities. The second user interface is configured to prevent the first set of functionalities from being accessible to the customer. [0016] In another embodiment, a POS system is disclosed. The system comprises: a display; a sensor; a memory configured to store data and computer-executable instructions; and a processor configured to access the memory. The processor is also configured to execute the computer-executable instructions to: receive a first indication of interaction with a merchant; present, in response to the first indication, a merchant- associated interface associated with merchant interaction; detect, using the sensor, an adjustment to a physical position of the display; determine, based on the adjustment, that the POS system is to interact with a customer; and present, in response to the receipt, detection, or determination, a customer-associated interface associated with customer interaction. The customer-associated interface is restricted from accessing a first set of functionalities that is in the merchant-associated interface.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] FIG. 1 illustrates two architectures for a client device in a secure point-of-sale (POS) platform that are in accordance with one or more example embodiments.

[0018] FIG. 2 illustrates an example network architecture for a POS platform in accordance with one or more example embodiments.

[0019] FIG. 3 illustrates an example component architecture for certain components of the secure POS platform shown in FIG. 2 in accordance with one or more example embodiments.

[0020] FIG. 4 illustrates another example architecture for certain components of the secure POS platform shown in FIG. 2 for pairing peripherals in accordance with one or more example embodiments. [0021] FIG. 5 illustrates another example architecture for certain components of the secure POS platform shown in FIG. 2 for providing extensibility in accordance with one or more example embodiments.

[0022] FIG. 6 illustrates another example architecture for certain components of the secure POS platform shown in FIG. 2 for altering an interface of a client device in accordance with one or more example embodiments.

[0023] FIG. 7 illustrates a diagram of an example computer system within which a set of instructions may be executed to cause the machine to perform any one or more of the methodologies or modules discussed herein in accordance with one or more example embodiments.

[0024] FIG. 8 illustrates a flow diagram of an example method for operating a secure

POS platform in accordance with one or more example embodiments.

[0025] FIG. 9 illustrates a diagram of an example client device for a secure POS platform operating in a non-secure mode in accordance with one or more example embodiments.

[0026] FIG. 10 illustrates a diagram of an example client device for a secure POS platform operating in a secure mode in accordance with one or more example embodiments.

[0027] FIGs. 1 1 A-1 1 D illustrate diagrams of example device architectures for client devices for a secure POS platform in accordance with one or more example

embodiments.

[0028] FIG. 12 illustrates a flow diagram of an example method for operating a secure POS platform in accordance with one or more example embodiments. [0029] FIG. 13 illustrates a ladder diagram of communications between a secure processor and application processor for conducting a secure transaction that is in accordance with one or more example embodiments.

[0030] FIG. 14 illustrates another ladder diagram of communications between a secure processor, multiplexer, and second input device, for conducting a secure transaction that is in accordance with one or more example embodiments.

[0031] FIG. 15 illustrates another ladder diagram of communications between a secure processor, application processor, and server, for conducting a secure transaction that is in accordance with one or more example embodiments.

[0032] FIG. 16 illustrates another flow diagram of an example method for operating a secure POS platform in accordance with one or more example embodiments.

[0033] FIG. 17 illustrates another ladder diagram of communications for operating a secure POS platform in accordance with one or more example embodiments.

[0034] FIG. 18 illustrates an upper view of an example cover for a POS or client device in accordance with one or more example embodiments.

[0035] FIG. 19 illustrates a flow diagram of an example method for operating a point-of- sale (POS) platform in accordance with one or more example embodiments.

[0036] FIG. 20 illustrates a flow diagram of an example method for establishing a connection between a printing device and a client device in accordance with one or more example embodiments.

[0037] FIGs. 21 -26 illustrate example user interfaces of a client device while

implementing the example method of FIG. 19.

[0038] FIG. 27 illustrates a flow diagram of an example method for operating an extensible POS platform in accordance with one or more example embodiments. [0039] FIGs. 28 and 29 illustrate example user interfaces displayed when operating an extensible POS platform in accordance with one or more example embodiments.

[0040] FIG. 30A illustrates a diagram of example interactions between a merchant and a

POS device in accordance with one or more example embodiments.

[0041] FIG. 30B illustrates a diagram of example interactions between a customer and a

POS device in accordance with one or more example embodiments.

[0042] FIG. 30C illustrates a diagram of example interactions between a merchant and a

POS device in accordance with further example embodiments.

[0043] FIG. 30D illustrates a diagram of example interactions between a customer and a

POS device in accordance with further example embodiments.

[0044] FIG. 31 illustrates a flow diagram of an example method for adjusting POS interfaces in accordance with one or more example embodiments.

[0045] FIG. 32 depicts a cross-sectional view of an example internal configuration of a point-of-sale (POS) device and internal short-range communication antenna

configuration in accordance with one or more embodiments.

[0046] FIG. 33 illustrates an overhead view of an example configuration of an internal short-range communication device for a point-of-sale (POS) device in accordance with one or more embodiments.

[0047] FIG. 34 illustrates example methods of mounting a wireless communication antenna in a point-of-sale (POS) device in accordance with one or more embodiments.

[0048] FIGs. 35-36 illustrate different radio frequency fields generated by various point- of-sale (POS) devices in accordance with one or more embodiments.

[0049] FIG. 37 illustrates a flow diagram of a set of example methods for an extensible POS platform in accordance with one or more example embodiments. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0050] Reference now will be made in detail to embodiments of the disclosed invention, one or more examples of which are illustrated in the accompanying drawings. Each example is provided by way of explanation of the present technology, not as a limitation of the present technology. In fact, it will be apparent to those skilled in the art that modifications and variations can be made in the present technology without departing from the scope thereof. For instance, features illustrated or described as part of one embodiment may be used with another embodiment to yield a still further embodiment. Thus, it is intended that the present subject matter covers all such modifications and variations within the scope of the appended claims and their equivalents.

[0051] Described herein are systems and methods for providing secure POS (point-of- sale) platforms and associated methods. Certain embodiments of the systems and methods described herein may facilitate providing a secure POS platform to provide secure interactions with local services and/or third-party applications during one or more POS transactions (e.g., financial transactions, login sessions, etc.) at physical and/or remote locations. Further, certain embodiments of the systems and methods may also provide or otherwise facilitate secure communication with a user of the POS platform.

[0052] Described herein are systems and methods for providing a POS (point-of-sale) platform. Broadly, the systems and methods described herein may enable a POS platform to interact with local services and third-party applications during POS transactions (e.g., financial transactions, advertisement transactions, coupon

transactions, etc.) at physical and remote retail locations. Thus, one or more user devices may be accessed by one or more users (e.g., merchants, employees, customers, etc.). For example, an employee may access a POS platform to complete a transaction with a customer who may have placed an order for products or services (e.g., purchasing batteries, etc.). The POS platform may allow multiple employees to access their accounts on the POS platform to perform certain functions associated with those employees. Some of these functions may be logging time, completing a sales transaction, printing of receipts, or any other function related to a POS platform.

[0053] Described herein are systems and methods for providing an extensible POS (point-of-sale) platform. Broadly, the systems and methods described herein may facilitate providing an extensible POS platform to allow interactions with local services and/or third-party applications during POS transactions (e.g., financial transactions, advertisement transactions, coupon transactions, etc.) at physical and/or remote retail locations. Thus, one or more user devices may allow the extensibility of functions (e.g., internal applications, third-party applications, Internet applications, etc.), where these functions may influence what is displayed at the POS platform during a POS

transaction. For example, a merchant may use a POS platform to complete a transaction with a customer who may have placed an order for products or services (e.g., purchasing batteries, etc.), where the POS platform may allow the extensibility of its functions to include interactions with a third-party application programming interface (API) to, in certain instances, apply additional services (e.g., tender services or various forms of payment).

[0054] Described herein are systems and methods for adjusting POS (point-of-sale) interfaces. In a typical transaction, the merchant and the customer may respectively interact with a POS device at different points of time in a sales or purchase transaction. The merchant may interact with the POS device to input the items to be purchased by the customer. The customer may interact with the POS device to complete the transaction. In the present disclosure, different user interfaces may be presented by the POS device depending on who and/or what entity is interacting with the POS device at a particular time during the transaction.

[0055] POS transactions on a POS platform may influence the selection of data communication channels within the secure POS platform, where these data

communication channels may be used to process the data associated with one or more POS transactions. For example, a merchant may use a POS platform to complete a transaction with a customer who may have placed an order for goods or services (e.g., purchasing milk, etc.), where the merchant or the customer may swipe a credit card to complete the transaction. Based upon the type of transaction, the POS platform may choose one or more data channels to access one or more processors within the POS platform to complete the transaction. For example, if the transaction involves secure data, such as credit card information or a personal identification number (PIN) a secure channel may be used; whereas if the transaction involves unsecure data, such as the entry of a quantity of milk to be purchased, a non-secure channel may be used. The one or more data channels can be used to process or otherwise complete the

transaction.

[0056] Although certain embodiments of the disclosure are directed to a POS platform used to facilitate a financial transaction between an owner of the terminal and another party, the approaches described herein are more broadly applicable to any device that is used to handle both secure and non-secure data. For example, an ATM may include an account management system and may also include an application for ordering stamps or other applications that do not require the receipt of secure data from the user. As another example, a tablet computer may include core applications that are used to interact with financial institutions or ecommerce systems while other applications can be added to the device that do not require the use of secure information. Any of these and similar devices can benefit from some of the approaches described herein.

[0057] The systems and methods described herein may facilitate adjusting a POS interface on a POS device in response to one or more user interactions with the POS device. According to one or more embodiments, the POS device may be configured to present a first interface or merchant-associated interface to a merchant, such as during interaction with the merchant. Furthermore, the POS device may be configured to detect a change in orientation and/or any other type of adjustment to the physical position of the POS device. For example, a merchant may interact with the POS device by inputting one or more line items to be purchased by a customer. After entering the line items, the merchant may turn, rotate, flip, and/or otherwise physically adjust the POS device and/or display to face the customer.

[0058] The POS device may be configured to detect the physical adjustment of the POS device. In response to this detection, the POS device may automatically adjust and/or change the first interface or merchant-associated interface to a second interface or customer-associated interface for interaction with the customer. In certain

implementations, the second interface or customer-associated interface may be different from the first interface or merchant-associated interface and may prevent the customer from viewing and/or accessing certain features and/or information that may be accessible to the merchant via the first interface or merchant-associated interface.

[0059] CLIENT DEVICE ARCHITECTURE [0060] As shown in FIG. 1 , secure POS platform element 100 may include a number of hardware components including input device controller (IDC) 102, multiplexer (MUX) 104, secure processor (SP) 106, and application processor (AP) 108. Throughout this specification, a touch screen will be used as an exemplary input device such that the input device controller may be referred to as a touch controller (TC). The input device controller could be a controller for any number of input devices or user interfaces such as a keypad, audio interface, or wireless interface. The above are only examples of components that may be included in a secure POS platform, such as 100, and other components may also be included.

[0061] Referring to FIG. 1 , there is shown an example schematic view of a secure POS platform element 100 in accordance with one or more example embodiments. In FIG. 1 , secure POS platform element 100 can include one or more components, such as 102, 104, 106, and 108 that are internal to associated client device 120, which can be a merchant POS device. Client device 120 may be operated by a user 1 10 entering various information for a purchase transaction via an associated input device associated with the client device 120 to facilitate a purchase transaction. The input device could be a touch screen integrated with the client device 120. The input device could be a multiuse input device such that it is used for both secure operations and normal (nonsecure) operations. Secure POS platform element 100 may evaluate whether the certain user inputs via the multiuse input device are associated with either secure operations or normal (non-secure) operations. An example of a secure operation is entering a PIN. An example of a non-secure operation is entering a quantity of an item to be purchased via the same touch screen. [0062] The hardware components, such as 102, 104, and 106, may be interconnected to provide various functions in response to certain actions performed by user 1 10 with respect to client device 120, such as inputting information via an associated input device or user interface. The hardware components can be implemented as individual integrated circuits (ICs) on a main board of client device 120. However, MUX 104 and SP 106 could also be implemented on a single application specific integrated circuit (ASIC) while IDC 102 and AP 108 are kept as separate ICs. The chip comprising MUX 104 and SP 106 could then be used as a "secure chip" in a chip set comprising the secure chip, IDC 102, and AP 108. As will be described later, integrating MUX 104 and SP 106 onto a single chip provides certain benefits in that IDC 102 and AP 108 could be commercially available ICs that are broadly available beyond the more limited market for specialized secure POS hardware. In other words, an application processor chip and peripheral controller chip could be standard devices for the control of peripherals and running applications generally, and do not need to be augmented in any manner to realize the security benefits of some of the approaches described herein. Any of the functions performed by SP 106 that are disclosed in this specification could be executed on the secure chip. For example, tamper detection circuitry implemented on the secure chip could receive a tamper indication from a tamper sensor and clear a memory implemented on the secure chip to protect encryption keys or other secure information stored on the secure chip.

[0063] AP 108 can be a standard processor used to implement an operating system for client device 120. For example, AP 108 can run the Android OS™. In general, the AP can maintain full control over the client device 120 while the device is running applications that don't require secure information. For example, the main application run by the AP 108 could be the standard merchant-facing retail checkout application used to accept inputs regarding a customer's order and tally the total of a specific purchase transaction. As another example, the main application run by AP 108 could be a restaurant server's ordering application used to input orders taken by the server. AP 108 can operate with a cache and main memory that are physically separate from the memory used by SP 106. This configuration provides certain benefits in that certain attacks may use a processor to write instructions to memory for later execution and exploitation of a secure program running on the same processor, or may use the processor to read and illicitly obtain data from the memory which was utilized and left over by a secure program using the same memory. These kinds of vulnerabilities can be avoided by not allowing the AP to have access to the same memory as the SP.

[0064] MUX 104 is a hardware multiplexer that receives control inputs from SP 106 and routes data received from IDC 102 to one or more data channels based on those control inputs. The data could be routed through transistors that turn on or off in response to control signals. MUX 104 could be an IC with one or more control pins, one or more input pins and at least two output pins. In approaches where MUX 104 and SP 106 are implemented on a single chip, MUX 104 could be a block of analog circuitry on the secure chip controlled by a digital output from SP 106. In such approaches, MUX 104 and SP 106 could exchange information via interconnects in the IC.

[0065] In one embodiment, illustrated by the region of FIG. 1 indicated by reference number 10, a secure transaction process can be implemented using the hardware components shown in FIG. 1. For example, when user 1 10 interacts with an input device or user interface associated with client device 120, IDC 102 can transmit certain user inputs to MUX 104. In certain instances, when secure POS platform element 100 detects or prompts user entry of secure data (e.g., a user entering PIN information) via the input device or user interface associated with client device 120, the operation is treated as a secure transaction and/or operation. In this instance, SP 106 can control the flow of secure data through MUX 104.

[0066] FIG. 1 illustrates another example schematic view of a secure POS platform which is illustrated by the region of FIG. 1 indicated by reference number 20, which is in accordance with one or more example embodiments. In the embodiment shown by 20, entry of data that may be considered non-secure (normal mode) can be facilitated via the hardware components, such as 102, 104, 106, and 108 of client device 120, such that data passes from a peripheral to AP 108. For example, IDC 102 may communicate user inputs to MUX 104, such as when user 1 10 interacts with an associated input device or user interface. MUX 104 can then pass the information received from this interaction to AP 108. AP 108 may then perform transactions and/or operations that may be considered non-secure. In addition, entry of data that may be considered secure can be facilitated via the same hardware components, such as 102, 104, 106, and 108 of client device 120. However, the data from the peripheral will now be routed to SP 106 instead of AP 108. For example, under the control of SP 106, MUX 104 will route input data from the peripheral to SP 106. SP 106 may then perform operations on the data that may be considered secure. IDC 102 may be completely unaware as to which processor the input data is being routed to.

[0067] EXAMPLE NETWORK ARCHITECTURE

[0068] Referring now to FIG. 2, there is shown an example network architecture of a POS platform 200 according to certain embodiments of the disclosure. The network architecture of the POS platform 200 may include one or more client devices 120. Each client device 120 may be coupled to one or more service provider servers 135 via a client API, which may be used to access the services and functionalities provided by the service provider servers 135. Client devices 120 can communicate via a network 130 with back end servers 140, remote services servers 160, control servers 180, and printing servers 181 . Each of the components in network architecture 200 are discussed in more detail below.

[0069] The one or more client devices 120 may be any of suitable devices that may be configured to execute one or more applications, software, and/or instructions to provide one or more services to the user 1 10. User 1 10 may be any person accessing a client device (e.g., client device 120), such as, merchants, employees, customers, system administrators, etc. Each client device 120 may be a merchant POS device, a POS stationary device (e.g., attached to a physical location), a mobile POS (e.g., able to be used in remote locations), a mobile device, a laptop computer, a desktop computer, other device with computer functionalities, or any combination thereof and/or other types of devices associated with a merchant at various locations. Each client device 120 may have a built-in stand that may support the client device 120. Further, each client device 120 may include a handle that a user (e.g., user 1 10) may hold and/or otherwise support the device with, for instance, the user's hand or arm. For example, a client device, such as 120 may be a POS terminal provided by First Data Corporation of Atlanta, Georgia. Other examples of client device 120 may be purpose-built POS equipment, a self-service kiosk, a smart phone, a tablet, a wearable computer device, or an e-reader operating a mobile operating system, such as Android OS™. An example hardware architecture of a particular client device that can be used in place of client device 120 is illustrated and described in FIG. 7 below. [0070] The network architecture of the secure POS platform 200 may also include one or more back-end servers 140. The one or more back-end servers 140 may be coupled to the one or more remote services servers 160 via a respective or single back-end application program interface (API). The back-end API may be an application programming interface for the one or more back-end servers 140 to supplement the services provided by the one or more remote services servers 160. The one or more back-end servers 140 may communicate with the one or more remote services servers 160 via network 130 as well. The one or more back-end servers 140, and/or the remote services servers 160 may be configured to handle financial transactions by authorizing or declining transactions. Each of the back-end servers 140 may be one or more independent computer systems, such as the computer system 700 of FIG. 7, for performing back-end processes for purchase transactions.

[0071] In FIG. 2, each client device 120 may communicate with one or more remote services servers 160 via a client API, which may be used to access the services and functionalities provided by the remote services servers 160. Each of the client devices 120 may also communicate with the one or more remote services servers 160 via one or more networks 130. The one or more remote services servers 160 may be one or more independent computer systems, such as the computer system 700 of FIG. 7. In some embodiments, the one or more remote services servers 160 may be a cloud- based computer system, where no on-premise servers are required, which may reduce relative cost and complexity of hardware, installation, and ongoing maintenance and administration.

[0072] The secure POS platform 200 may also include one or more control servers 180. Each of the control servers 180 may provide secure communication sessions between a customer support representative (e.g., user 190) and one or more client devices (e.g., client devices 120). The one or more control servers 180 may be one or more independent computer systems, such as the computer system 700 of FIG. 7.

[0073] The POS platform system 100 may include a printing server 181. The printing server 181 may communicate with one or more POS printing devices 182. As shown in FIGs. 2 and 4, the client device 120 may be connected directly to a printing server 181 or may be connected to the printing server 181 through one or more networks 130. Further, in some instances, the client device 120 may connect directly to one or more POS printing devices 182.

[0074] The one or more networks 130 may be a system for communication. Each network channel and network 130 may encompass a variety of mediums of

communication, such as wired communication for one part and wireless communication for another part. The one or more networks 130 may be part of the Internet.

[0075] For example, a network, such as 130, may include an Ethernet or other wire- based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. The network 130 may include any suitable network for any suitable communication interface. As an example and not by way of limitation, the network channel may include an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these networks. One or more portions of one or more of these networks may be wired or wireless. As another example, the network may be a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a 3G or 4G network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network).

[0076] Each network 130 may include links using technologies such as Ethernet, 802.1 1 , worldwide interoperability for microwave access (WiMAX), 3G, 4G, CDMA, digital subscriber line (DSL), etc. Similarly, the networking protocols used on the network channel may include multiprotocol label switching (MPLS), the transmission control protocol/Internet protocol (TCP/IP), the User Datagram Protocol (UDP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), and the file transfer protocol (FTP). The data exchanged over the network channel may be represented using technologies and/or formats including the hypertext markup language (HTML) and the extensible markup language (XML). In addition, all or some of links may be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (IPsec).

[0077] EXAMPLE ARCHITECTURES FOR POS PLATFORM COMPONENTS

[0078] FIGs. 3-6 illustrate diagrammatic representations of exemplary internal architectures of certain components of POS platform 200 shown in FIG. 2. In

accordance with one or more embodiments of the disclosure, the components of the example internal architectures may interact with one or more users (e.g., user 1 10) operating one or more client devices (e.g., client device 120) communicating with one or more servers (e.g., control server 180). The client device 120 may include a client operating system 214, at least one POS application or POS services process (e.g., POS application 216), and one or more applications (e.g., application(s) 218). The operating system 214 may be an operating system of the client device 120, such as Android™ or iOS™ or any other operating system that may be suitable for a point-of-sale system. The operating system 214 may be an open or closed format. An open format may be an operating system that may allow users to modify and interact with its source code (e.g., Windows™, and Android™). A closed format operating system may be a standalone operating system that defines parameters for interacting with such operating systems without allowing users to make modifications. For example, a closed operating system may not allow root access to the file system (e.g., iOS™). Additionally, client device 120 may be configured to provide a number of services via internal modules.

[0079] Each of the modules can operate individually and independently of other modules. Some or all of the modules can be combined as one module. A single module can also be divided into sub-modules, each performing a separate method operation or method operations of the single module. The modules can share access to a memory space. One module can access data accessed by or transformed by another module. The modules can be considered "coupled" to one another if they share a physical connection or a virtual connection, directly or indirectly, allowing data accessed or modified from one module to be accessed in another module. In some approaches, SP 106 will include separate modules that do not share access to the same memory space as the modules operating on AP 108. In addition, in certain approaches client device 120 will include two operating systems, one operating on SP 106 and one operating on AP 108.

[0080] POS applications 216 may contain modules executable on the client device 120 to perform POS services (e.g., Clover™, or any other POS services). The POS application(s) 216 may run on the AP 108. The POS application 216 may include a timecards module, a self-serve module, a register module, a store inventory module, or any combination thereof. The one or more applications, such as 218, may include applications that may be built-in or may be provided by third-party applications. For example, one or more applications 218 may include a register module, which may be configured to provide an interface for a merchant to facilitate sales transactions in a business. The register module may have bar code scanner functionality, check-out functionality, payment functionality, or any combination thereof. It is understood that the register module is one of many possible modules that may exist within one or more application(s) 218 executing on respective client devices 120, and that other modules may be implemented. The application(s) 218 may run on the AP 108.

[0081]The client device 120 may include additional, fewer, or different modules for various applications. Conventional components such as network interfaces, security functions, load balancers, failover servers, management and network operations consoles, and the like are not shown so as to not obscure the details of the system.

[0082] POS Architecture 300 shown in FIG. 3 illustrates specific aspects of a secure POS architecture that are in accordance with certain embodiments. As illustrated, client device 120 may include a PIN pad module 220, support module 222, a security module 224, and/or screenshot module 226. Client device 120 communicates with control servers 180.

[0083]Application(s) 218 may also include screenshot module 226, which may be configured to communicate with operating system 214 to request screenshots of client device(s) 120. A screenshot may be a screen capture of client device(s) 120 at a certain instance. The captured screenshots may be sent to control server 180 for viewing by user 190. An administrator or other users may choose the interval value to allow for continuous viewing of the screenshots. For example, every 1 millisecond, screenshot module 226 may capture a screenshot of client device(s) 120. Screenshot module 226 may send the captured screenshots to control server 180 so user 190 may view actions taken at the client device(s) 120 by user 1 10. The interval may be within a predetermined threshold time value. The predetermined threshold time value may be selected to allow consecutive viewing of the screenshots (similar to a video) by user 190. The predetermined threshold may determine the number of screenshots taken each second resulting in continuous viewing by the user 190. An interval value higher than the threshold may result in flickering while being viewed by the user 190. An interval value lower than the threshold may result in continuous viewing but may impact performance since more screenshots may be taken each second.

[0084]The PIN pad module 220 may be configured to allow a user (e.g., user 1 10) to interact with a particular client device, such as 120. PIN pad module 220 may allow customers to enter information associated with a transaction, such as a sales transaction. PIN pad module 220 may be configured to operate with either a touch screen or a physical PIN pad system, for example, the First Data ® FD-40 device provided by First Data Corporation of Atlanta Georgia, associated with client device 120. PIN pad module 220 may be configured to operate in a secure or insecure mode. A secure mode may be a mode that may require heightened security when entering information (e.g., payment authentication information). In other approaches, PIN pad module 220 may be configured to operate in the same manner whether it is in secure or insecure mode while alternate modules in the device adjust their characteristics to reflect the current mode of device 120.

[0085] PIN pad module 220 may be configured to operate with operating system 214 in a secure mode even if operating system 214 is an open format (e.g., Windows™, and Android™). The information may be related to a debit card or a credit card, or a gift card, or any other form of information related to a point-of-sale system. For example, a customer (e.g., user 1 10) may be purchasing a product from a business using a debit card. The customer may enter a code associated with the debit card in order to facilitate or otherwise complete the transaction.

[0086] Support module 222 may be configured to provide a user (e.g., user 190) to control client device 120 for performing maintenance or guidance activities. For example, user 190 may be at least one of a manager, a customer support personnel, or an administrator of the POS network, or any other person responsible for maintenance or guidance activities. For example, customer support personnel (e.g., user 190) may take control of client device 120 to assist the merchant (e.g., user 1 10) in

debugging/resolving one or more issues with client device 120 or to answer questions about that device. It may also be used by a manager who may provide guidance and support for an employee at client device 120. For example, a merchant (e.g., user 1 10) may contact a customer service representative (e.g., user 190) to report an issue with a client device (e.g., client device 120).

[0087] Security module 224 may be configured to handle payment transaction information, including a PIN or a card number. In one example embodiment, security module 224 may operate in a secure mode and may comply with one or more industry standards for secure transactions. For example, Payment Card Industry (PCI) as a governing body for payment security may provide one or more guidelines and/or rules to follow when implementing a secure sales transaction. For example, operating a physical PIN pad may allow for better control for implementing secure sales transaction. However, operating a touch screen PIN pad may present challenges. In one embodiment, PIN pad module 220 may operate a touch screen PIN pad that allows a user to enter the PIN of their debit card.

[0088] Security module 224 may be configured to operate with one or more processing units to implement secure sales transactions. For example, a client device, such as 120, may be configured to operate using a processing unit that may be dedicated for secure operations and an insecure processing unit dedicated for insecure operations. Secure operations may be, for example, swiping a credit card, entering a PIN for a debit card, or any other operation related to executing a secure transaction. Insecure operations include any operation that may be related to using client device 120 without handling secure data. For example, during a sales transaction, if a customer swipes his or her credit card, security module 224 may select a secure processing unit to complete the transaction. In a particular class of implementations, the selection of the secure processor units may involve the security module initiating a transition in the control signal or signals that are provided to MUX 104. Although the above example is presented with two processing units, other combinations of secure and insecure processors may be envisioned. For example, a single processing unit may be divided into two areas, one secure and one insecure, or a plurality of processing units may be separated into secure or insecure processor groups.

[0089] Security module 224 may be implemented independent of operating system 214. For example, this may allow developers to work independently from the firmware of operating system 214, which may allow for better code control. Security module 224 may also be implemented using a physically separate memory from the other modules. Security module 224 may execute its instructions using SP 106 and a physically separate memory from the memory used by AP 108. As mentioned above, in certain approaches PIN pad module 220, and other modules in device 120, do not require information as to whether the device is operating in a secure or non-secure mode.

[0090] Control server 180 may include operating system 230, at least one point-of-sale application (e.g., POS application 232), and at least one application (e.g., application(s) 234). Additionally, control server 180 may be configured to provide a number of services via internal modules. For example, control server 180 may include control module 236. The description of operating system 230, the at least one point-of-sale application (e.g., POS application 232), and at least one application (e.g., application(s) 234) may be substantially similar to the description of operating system 214, the at least one point-of-sale application (e.g., POS application 216), and the one or more applications (e.g., application(s) 218), respectively, of the client device 120.

[0091] With reference to FIG. 4, there is shown a diagrammatic representation of an example architecture 400 of a client device 120 for a POS platform in accordance with one or more embodiments of the disclosure. FIG. 4 illustrates one or more users (e.g., user 1 10) with one or more client devices (e.g., client device 120) interacting with one or more printing servers (e.g., printing server 181 ) and one or more printers (POS printer 182). As mentioned above, client device 120 can also communicate directly with POS printer 182.

[0092] As in FIG. 3, the client device 120 of architecture 400 may include a client operating system 214, at least one point-of-sale application (e.g., POS application 216), one or more applications (e.g., application(s) 218), and may be configured to provide a number of services via internal modules such as PIN pad module 220 and security module 224. In the specific example of architecture 400, client device 120 may also include a power module 225, a printing module 227, an employee module 228, and a communications module 229. The communications module 229 may be a Bluetooth module.

[0093] Power module 225 may be configured to power on the client device 120. For example, the power module 225 may allow the client device 120 to power on using a physical button, a touchscreen button or without the use of buttons. For example, client device 120 may contain a touch sensitive handle that may work in conjunction with a wristband to activate a near field communication (NFC)-type device. It is understood that NFC is a set of standards for smartphones and similar devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than a few inches.

[0094] The communications module 229 may be configured to enable the client device 120 to communicate in accordance with a wireless protocol. For example, the communications module 229 could be a Bluetooth module to allow the client device to utilize Bluetooth technology (e.g., Bluetooth LE or BLE™) to communicate with other devices. The communications module could also be a Zigbee™, iBeacon™, or

Eddystone™ module, or a module for any alternative low energy communication protocol. The communications module 229 may enable BLE™ payments or may enable using digital wallets (e.g., Google Wallet™, or any other digital wallets that may be used without the need for physically possessing a payment card). It is understood that BLE™ may provide low power consumption while maintaining communication range. The communications module 229 may enable a user (e.g., user 1 10) to communicate with a printing server (e.g., printing server 181 ), or directly with a printing device (e.g., POS printer 182) to print a document, such as a receipt, on a printer (e.g., POS printer 182). It is understood that the above are only examples for using a Bluetooth module 229 to interact with other devices and that other uses may be envisioned.

[0095] The communications module 229 or the communications module on POS printer 182 may facilitate discovery for a pairing procedure. For example, either the client device or the POS printer may broadcast low energy packets that identify the device to counterpart devices that may be looking for devices to pair to. As a more particular example, POS printer 182 may broadcast low energy advertisement packets that identify itself as a POS printer of a particular kind meant to be paired with the particular class of client devices represented by client device 120. Also, either device may utilize their communication modules to scan for devices that claim to be the kind of devices they are meant to pair with. For example, client device 120 could scan for devices that claim to be POS printers 182. The devices could identify themselves based on the contents of a general identification field such as the "device name" fields of certain protocols. For example, the general identification field could include a company name, an additional identifier such as "printer", and the last few digits of a manufacturer's serial number for POS printer 182. In this example, the POS printer 182 will come "out of the box" with this information in the general identification field. As another example, the device name could be a registered object identifier prefix in a reserved MAC address range for the communications protocol used by the POS printer 182 and

communications module 229. The prefix could be registered with an industry standards body.

[0096] The communications module 229 may be configured to enable the client device 120 to be associated with POS printer 182. For example, the communication module could include executable instructions in accordance with a pairing protocol. In specific approaches, POS printer 182 will also have a communications module to enable pairing of client device 120 and POS printer 182. In these instances, the communications module 229 may work in combination with a communications module on POS printer 182 to derive a shared secret to serve as part of the pairing procedure conducted between the two devices. In accordance with certain pairing procedures, the shared secret is generated in such a way that it cannot be intercepted by an external device that is spoofing client device 120 and POS printer 182 into thinking they are

communicating directly with each other. As a result, the dynamically generated shared secret, or a hash thereof, can be obtained from the POS printer 182 or the client device 120 to confirm that the link established by the pairing procedure is secure. The dynamically generated shared secret, or a hash thereof, can be the client device association information that is referred to below in this disclosure.

[0097] Client device association information can be used to provide two-way

identification to the pairing procedure. The information can be obtained from either device and passed to the other device for confirmation using an alternative

communications channel (i.e., a channel that is separate from the one that is being set up via the pairing procedure). For example, the printer could print the client device association information for visual inspection by user 1 10, and the user could manually enter that information into client device 120 via a user interface on client device 120. Other channels could include outputting the information on a display on POS printer 182, outputting the information in the form of a printed scannable code from POS printer 182 for scanning by a scanner of device 120, or an alternative wireless link between POS printer 182 and client device 120 provided via modulated visible light, IR

communication, NFC communication, or others. [0098] The printing module 227 may also be configured to enable a user (e.g., user 1 10) to send one or more print jobs to one or more printing servers (e.g., printing server 181 ). For example, a printing server (e.g., printing server 181 ) may be connected to at least one printing device (e.g., POS printer 182). The printing device (e.g., POS printer 182) may be a stationary (e.g., associated with a physical location) or a mobile printer (e.g., portable printer that may be independent of a physical location). The POS printer 182 may be a mobile printer (e.g., portable printer) that may accompany the client device 120. For example, a client device 120 may be used in a food truck, where the POS printer 182 may also be used to allow portability.

[0099] The location of the POS printer 182 may determine whether client device 120 begins a pairing procedure with that printer. For example, if a printer is in close proximity with client device 120, the client device 120 may enable the POS printer 182 to power on to engage in a pairing procedure. For example, using a communication protocol (e.g., BLE™), client device 120 may find a printing server (e.g., printing server 181 ), and/or printer (e.g., POS printer 182) and may enable the POS printer 182 to power on. The client device 120 may enable the POS printer 182 to power on by generating a wake-up message associated with the printing server 181 and/or POS printer 182. Once POS printer 182 has been powered on, the client device 120 can engage in a pairing procedure with POS printer 182.

[00100] The location of the POS printer 182 may determine whether the client device 120 may interact with that printer. For example, if two printers are in close proximity to a client device 120, the client device 120 may choose to communicate with the printer that meets certain criteria (e.g., the closest, the newest, the biggest, etc.). For example, using a communication protocol (e.g., BLE™), the client device 120, may find the closest printing server (e.g., printing server 181 ), and/or the closest printer (e.g., POS printer 182) and may enable the POS printer 182 to power on.

[00101] The client device 120 may enable the POS printer 182 to power on by generating a wake-up message associated with the printing server 181 and/or POS printer 182. The printing module 227 may establish a communication session with the printing server (e.g., printing server 181 ), and/or the closest printer (e.g., POS printer 182). The communication session may allow the client device 120 to print to a printer (e.g., POS printer 182) or to power on a printer (e.g., POS printer 182). The client device 120 may remotely control the power of the POS printer 182 during data transmission. For example, the POS printer 182 may be powered on to complete a print job. After the print job is complete, the POS printer 182 may be powered off. In some embodiments, BLE™ may be used to control hardware interrupts to power on and/or power off the POS printer 182. For example, the POS printer 182 may stay in sleep mode until the client device 120, using BLE™, wakes up the POS printer 182. At that point, a regular Bluetooth connection may be established through which the print job may be sent to be printed.

[00102] With reference to FIG. 5, there is shown a diagrammatic representation of an example architecture 500 of an extensible POS platform in accordance with one or more embodiments of the disclosure. FIG. 5 illustrates one or more client devices (e.g., client devices 202, 204, 206, and 208), which may be located at one or more respective locations (e.g., restaurants, hardware stores, malls, etc.). As explained above, the client devices may be implemented by a computer system, such as the computer system 700 of FIG. 7, which may be controlled by operating system software (e.g., operating system 214). Each of the one or more client devices may share the characteristics of client device 120 as described above. The one or more client devices may also include POS services (e.g., Clover® services, or any other services that relate to a point-of-sale system) and a POS services process 216. As above, the one or more applications 218 may be any application that may be built-in, installed, or added to the client devices 202, 204, 206, and 208.

[00103] Through the use of architecture 500, modifications to a transaction made using a client device, such as POS device 202, may be synchronized across multiple client devices (e.g., client devices 202, 204, 206, and 208), and may be provided to a server for remote processing. A change to a transaction may be, for example, adding new items to the order, including a donation to a charity with the order, adding taxes, receiving payment information, printing a receipt, applying coupons, adding a special notice on the transaction, or any other changes associated with the transaction.

Synchronization can involve both a push of data from the client device to a datastore via cloud services server 210 and a distribution of that data from the datastore to the multiple client devices. The datastore can comprise multiple databases associated with the overall POS system such as an orders database, a transactions database, an inventory database, and others. Remote processing can involve remote servers operating on the information provided directly by the client devices or data stored in the datastore. For example, the client devices (e.g., client devices 202, 204, 206, and 208) may utilize remote servers, such as cloud services servers (e.g., cloud services server(s) 210) to execute a sales transaction.

[00104] The client device (e.g., client devices 202, 204, 206, and 208) may implement a queue for recording changes that occur during a transaction. For example, adding an item to an order may cause the queue to record that action for a relatively short period of time. An item may be a product or service associated with the client device (e.g., client device 202). As another example, the client device can record payment information added to the transaction for payment processing. The client device (e.g., client device 202) may transmit the items in the queue to the server (e.g., cloud services server 210) over the network (e.g., network 130) for processing by a remote server. In an example, a merchant (e.g., user 1 10) may use a client device, such as POS device 202, to create a customer order for a product. The user 1 10 may, via the POS device 202, generate an order identifier and associate it with the order. For example, if a customer places an order for a certain product, the product may be inserted into the order as a line item. The line item for the product may have an identifier associated with it. The order may be stored on the POS device 202, which in turn may store the order and associated identifier information in a local database or other datastore. The order may then be put into a queue displayed by the POS device 202. The order may be stored in a data object, and the data object may be stored in the queue.

[00105] In some embodiments, the transaction change can involve the merchant (e.g., user 1 10) obtaining payment information from the customer, such as by swiping a credit card or other payment device using a reader associated with the POS device 202. The credit card or payment device information may be encrypted by the POS device 202, and stored by the POS device 202 in an object associated with the order. In some embodiments, the merchant may select a tender type (e.g., credit card, debit card, gift card, payment device, etc.) via the POS device 202. The payment information and tender type may be stored by the POS device 202 in a data object, and the data object may then be placed into the queue displayed by the POS device 202 as the next item after the corresponding order.

[00106] In any instance, when the POS device, such as 202, is online, the items may be stored in the queue for a relatively short period of time. The POS device 202 may transmit the items in the queue to a server (e.g. cloud services server(s) 210) over the one or more networks, such as 130. If the POS device 202 is not able to

communicate with the server, such as 210, the order items may be stored by the POS device 202 in the queue until a connection to the server 210 can be established. Once the POS device 202 is able to communicate with the server 210, items in the queue may be transmitted to the server for processing. Processing by the server, such as 210, may include adding the items to remote databases, processing payments, and communicating items back to one or more POS devices for further processing. For example, if there are multiple POS devices being utilized by merchants, and each merchant is creating and transmitting orders to the server 210, the server 210 may aggregate the orders, which may be based on time of receipt of the orders, and transmit the aggregated orders to at least one of the or multiple POS devices for fulfillment of the orders.

[00107] In some embodiments, the server (e.g., cloud services server(s) 210) may include a queue to receive items from the one or more client devices (e.g., client devices 202, 204, 206, and/or 208) of a merchant (e.g., user 1 10). The server, such as 210, may process items as they are being received in the queue. Multiple databases may be updated by the server 210 based on the items in an order. For example, the product line item in the above example may be decremented from an inventory database, may be added to a sales database, and the like. The update to the different databases may trigger synchronization across some or all of the client devices (e.g., client devices 202, 204, 206, and 208). This may enable the merchant (e.g., user 1 10) to have suitable information when interacting with a customer. For example, if the product is ordered, and it is the last product available, some or all of the client devices may be updated so that merchants can be alerted or otherwise notified that they may no longer take orders for certain products.

[00108] Additionally, a cloud services server (e.g., cloud services server(s) 210) may include applications (e.g. application(s) 252) that may be built-in or may be provided by third-party applications. In an illustrative example, a user (e.g., user 1 10) may initiate a transaction and/or modify a transaction (e.g., creating/modifying a purchase order of a product or a service) on a client device (e.g., client device 202). The POS services process (e.g., POS services process 216) may notify the cloud services server (e.g., cloud services server 210), which, in turn, may broadcast to other client devices (e.g., client devices 204, 206, and 208) that a change to a transaction may have occurred. As explained above, a change to a transaction may be, for example, adding new items to the order, including a donation to a charity with the order, adding taxes, receiving payment information, printing a receipt, applying coupons, adding a special notice to the transaction, or any other changes associated with the transaction.

[00109] Continuing with the example above, the POS services process 251 of the cloud services server 210 may receive an indication of a change in an order or transaction performed at one or more of the client devices (e.g., client devices 202, 204, 206, and 208), which may be received directly or through the one or more networks 130. Other applications (e.g., applications 252, and/or external applications 240), including third-party applications, may also be registered to be notified of any changes on the one or more client devices. In the event of an order or transaction change, the POS services process 251 of the cloud services server 210 may broadcast to some or all registered devices and applications that a change has occurred. Examples of these third party applications are provided below.

[00110] Registering applications for specific transaction changes provides certain benefits to the extensible POS platform in that the POS service process or operating system (e.g., 214, 216, 251 , 250) will be able to operate more efficiently. Although broadcasting to all applications that are registered with the operating system is feasible, in actuality such a system would be both less stable and less efficient than one in which particular applications are registered for particular modifications. When a subset of applications are registered for particular modifications (e.g., a third-party donation application is registered such that a payment confirmation screen serves as an explicit trigger for generating a "donate" button) the POS services process or operating system will know to expect a response within a certain time period. As a result, there is no need to design a worst-case response time monitoring system into the platform to allow for potential, but uncertain responses. Furthermore, if no applications are registered to receive a specific broadcast, the POS services process or operating system can forgo sending the broadcast itself and can immediately continue on with any given

transaction.

[00111] In some embodiments, the POS platform system may be an open platform, wherein the open platform may provide access to the system to allow third- party developers to develop their own applications to augment or provide further functionality to the system. For example, using any number of application program interfaces (APIs) or similar structures, data may be pulled from the system, and data may be pushed into the system. This may enable third-party developers to develop applications that may run concurrently with the system and augment system

functionality. Further, application(s) 218 may include applications from a third-party vendor, which may provide additional functionalities. In one embodiment, the additional functionality may be based upon one or more predetermined preferences (e.g., merchant preferences, system administrator preferences, location preferences, type of store preferences, etc.). As noted above, application(s) 252 can also include these third-party applications and owing to the extensibility of the POS platform, third-party applications provided via cloud services server(s) 210 will share disclosed

characteristics of third-party applications in the set of application(s) 218. Finally, the synchronization of data across multiple devices provided by the extensible POS platform results in a system where the third-party applications can implement an action on one client device in response to an event generated by another client device.

[00112] One or more applications that may be executed by a POS services process (e.g., POS services process 216, and/or 251 ) may allow other applications, such as one or more third-party or external applications 240, to control certain features or functionality of a client device 120. An application running on a client device (e.g., application 218 running on client device 202) may be provided by a third party and may be implemented to provide certain functions when a condition is met. An external application 240 or third-party application may be permitted to share resources with one or more built-in applications of the client device 120. The one or more external applications 240 or third-party applications may focus on performing their respective functions without having to perform some or all certain functions of the client device, such as those necessary to operate a POS infrastructure. Furthermore, the shared- resource functionality may allow the one or more external applications 240 or third-party applications to receive any number of various payment types without needing to communicate with a payment server dedicated to a particular POS infrastructure.

[00113] The functionality discussed above with reference to registering

applications and broadcasting modifications that trigger those applications to take certain actions can be applied to facilitate this shared-resource functionality. In some embodiments, one or more triggers may allow any number of the one or more external applications 240 or third party applications to control certain functions of the device 120. The triggers may be either explicit or implicit. Explicit triggers may include, but are not limited to, a new order created, a line item added or removed from an order, a payment made, a refund made, and a pay button clicked. Implicit triggers may include, but are not limited to, a change in the employee operating the client device 120, a change in an order of a sales transaction, and a change in the inventory of items. These explicit or implicit triggers may allow one or more third-party or external applications 240 to share the resources of the client device 120 to provide one or more functionalities specific to the one or more third-party or external applications 240. Any of the transaction modifications described above can be used as triggers for these processes.

[00114] In accordance with the shared-resource functionality described above, the payment flow for a particular transaction that is being administrated by the register and payment modules can be modified to include information and functionality from a third- party or external application. One or more third-party or external applications 240 may control one or more functions of the client device 120, such as output to an associated display screen. For example, during a purchase transaction for an item or a service, a donation button may be created by a third-party or external application on a payment window of a display screen of a client device 120 so that a customer user may contribute to a particular charity associated with the donation button.

[00115] The sharing of resources and information between applications is not limited to the functionality of a particular client device. Through the use of the data synchronization capabilities of the POS platform, information can be shared across multiple devices. Furthermore, the triggers that the external or third-party applications are listening for do not need to be generated on the same device on which the corresponding action will be taken. If a user (e.g., user 1 10) initiates and/or modifies a transaction (e.g., creating/modifying a purchase order of a product or a service) on a client device (e.g., client device 202), the POS services process (e.g., POS services process 216) may broadcast to other client devices (e.g., client devices 204, 206, and 208) that a change to a transaction occurred. The change to the transaction can be any of the examples previously provided. The following example of a happy hour

application illustrates this point. In this example, the client devices are co-located;

however, it is understood that this is only an example, and client devices may be located at different locations.

[00116] A third-party happy hour application may be interested in an event (e.g., transaction occurring within a certain time frame) that may occur on a client device (e.g., client device 202). In that case, the happy hour application may be interested in the event occurring on a client device (e.g., modification of an order to add new items, etc.) occurring at a certain time frame (e.g., between the hours of 5 PM and 7 PM). As such, the event will serve as the trigger for execution of the application's action. The happy hour application may then take certain actions associated with the event (e.g., applying a coupon, providing advertisement, inserting an image onto a sales receipt, or any other function). In some embodiments, if the same transaction is accessed from other client devices (e.g., client devices 204, 206, and 208), the transaction may be updated in real time across some or all of these client devices.

[00117] As a further exemplary feature of the open platform architecture, one or more applications may be executed by a POS services process (e.g., POS services process 216, and/or 251 ) to allow for extensibility of fender or payment methods. The client device 202 may include a payment module that provides or otherwise facilitates certain payment methods. The payment module may be configured to facilitate acceptance during a payment transaction of various tender types such as cash, credit, debit, or any other form of payment currency or compensation accepted by a merchant (e.g., user 1 10). Additionally, the client device 202 may be updated to accept additional payment methods, for example, from a third-party application. Additional payment method(s) may be added to a client device (e.g., client devices 202, 204, 206, and/or 208). Some examples of payment methods that may be added may be Bitcoin™, prepaid vouchers (e.g., Groupon™, LivingSocial™, etc.), prepaid gift cards (e.g., Gyft®, etc.), virtual checks, virtual wallets, or any other form of digital and/or virtual currency payment methods. A payment table may be maintained by a client device (e.g., client devices 202, 204, 206, and/or 208) and/or cloud services server(s) 210 or back-end server(s) 140 to maintain the merchant ID and the amount due, and also to store a correlation ID to the additional payment tender (e.g., Bitcoin™, etc.). This table may be accessible by the third-party application (e.g., Bitcoin™ application) to store a bitcoin ID for auditing and/or retrieval purposes. [00118] The external or third-party application (e.g., Gyft®, Bitcoin™ applications, etc.) may be associated with a refund module, which may be triggered in situations where a refund may be due to a customer (e.g., during a transaction for purchasing goods or services). The external or third-party application (e.g., Gyft®, Bitcoin™ applications, etc.) may render a "refund" button on the client device (e.g., client device 202) to be used in such situations. Further, the refund module may report to the client device (e.g., client device 202) that a refund may have failed or succeeded.

[00119] Considering Gyft® as an exemplary payment method for several of the features described above, when a user 1 10 presses a button on a touchscreen of the client device 120 to initiate a method of payment using a Gyft® prepaid card, an associated Gyft® application may be permitted to control outputting data to certain portions of the display screen of the client device 120, such as to allow user interaction with the Gyft® application. The user interaction may include entering customer information, card information, or any other information requested by the Gyft® application. After the user enters the information requested by the Gyft® application, the Gyft® application may relinquish control of the display screen and return control of the display screen to the client device 120.

[00120] Considering Bitcoin™ as an exemplary payment method for several of the features described above, a merchant may install a bitcoin application on one or more client devices (e.g., client devices 202, 204, 206, and/or 208) and/or cloud services server(s) 210. For example, in an Android™ operating system environment, a bitcoin package (e.g., bitcoin. apk) may contain a manifest file that may contain an "intent" file, e.g., a list of services that the application provides. A POS services process (e.g., POS services process 216 and/or 251 ) may define a "pay intent" event that the bitcoin. apk may support. A merchant (e.g., user 1 10) may utilize a client device (e.g., client device 202) to initiate a transaction associated, for example, with a product or a service requested by a customer. The client device (e.g., client device 202) may render a bitcoin button that may be presented on the client device (e.g., client device 202), and may be selected as an additional tender method by the customer. In this example, the bitcoin application may provide means for handling bitcoin payments, when the bitcoin button is pressed by the merchant and/or the customer. The bitcoin application may communicate with a bitcoin server to authorize or decline payments to the dollar amount associated with the transaction. For example, if the customer chooses bitcoin as a payment method for purchasing a $10 product, the bitcoin application may

communicate with the bitcoin server to determine whether there are enough funds to complete the transaction. If, for example, the customer's bitcoin balance was $7, the bitcoin application may return authorization for $7 and may present to the merchant and/or the customer that $3 is still owed. It is understood that the above is only an example, and other scenarios using Bitcoin™ or any other virtual currency may be used.

[00121] With reference to FIG. 6, there is shown a diagrammatic representation of an example architecture 600 of a POS platform for adjusting POS interfaces according to one or more embodiments of the disclosure. The system 600 may be incorporated in one or more client device(s) 120 (e.g., the client device(s) 120 illustrated in FIG. 1 ). The client device(s) 120 may also be in communication with one or more service provider server(s) 135 (e.g., the service provider server(s) 135 illustrated in FIG. 2), such as via a network 130. The client device and/or service provider server(s) 135 may have access to a database 142 via network 130. [00122] The client device(s) 120 may include one or more computer processors 201 , and a memory 203 storing an operating system 214 and a POS application 216. In addition, the client device(s) 120 may include one or more device sensor(s) 212, network and I/O interfaces 217, and a display 219. In certain embodiments, the one or more I/O interfaces 217 may be configured to present or otherwise output a user interface, such as a button or lock key, wherein a user can indicate that a subsequently displayed user interface to be output via the client device 120 (e.g., and/or its display 219) is to be rotated, flipped, moved, and/or otherwise adjusted, such as when a merchant transaction and/or operation, or a customer transaction and/or operation is to be initiated. In certain embodiments, the one or more device sensors 212 may be capable of gathering information associated with a present environment of the client device(s) 120, or similar hardware devices, such as a camera, microphone, antenna, a gesture capture or detection device, or Global Positioning Satellite (GPS) device.

Furthermore, the one or more device sensors 212 may be configured to determine a change and/or adjustment to an orientation and/or position of the client device 120. For instance, the one or more device sensors 212 may be configured to determine whether the client device 120 (e.g., and/or its display 219) has been rotated, flipped, moved, and/or otherwise physically adjusted, such as by a user (e.g., a merchant, merchant employee, and/or customer) of the client device 120.

[00123] The computer processors 201 may comprise one or more cores and may be configured to access and execute (at least in part) computer-readable instructions stored in the memory 203. The one or more computer processors 201 may include, without limitation: a central processing unit (CPU), a digital signal processor (DSP), a reduced instruction set computer (RISC), a complex instruction set computer (CISC), a microprocessor, a microcontroller, a field programmable gate array (FPGA), or any combination thereof. The client device 120 may also include a chipset (not shown) for controlling communications between the one or more processors 201 and one or more of the other components of the client device 120. In certain embodiments, the client device 120 may be based on an Intel® architecture or an ARM® architecture, and the processor(s) and chipset may be from a family of Intel® processors and chipsets. The one or more processors 201 may also include one or more application-specific integrated circuits (ASICs) or application-specific standard products (ASSPs) for handling specific data processing functions or tasks.

[00124] The memory 203 may include one or more computer-readable storage media (CRSM). In some embodiments, the memory 203 may include non-transitory media such as random access memory (RAM), flash RAM, magnetic media, optical media, solid state media, and so forth. The memory 203 may be volatile (in that information is retained while providing power) or non-volatile (in that information is retained without providing power). Additional embodiments may also be provided as a computer program product including a transitory machine-readable signal (in

compressed or uncompressed form). Examples of machine-readable signals include, but are not limited to, signals carried by the Internet or other networks. For example, distribution of software via the Internet may include a transitory machine-readable signal. Additionally, the memory 203 may store an operating system 214 that includes a plurality of computer-executable instructions that may be implemented by the computer processor to perform a variety of tasks to operate the interface(s) and any other hardware installed on the client device 120. The memory 203 may also store content that may be displayed by the client device 120 or transferred to other devices (e.g., headphones) to be displayed or played by the other devices. The memory 203 may also store content received from the other devices. The content from the other devices may be displayed, played, or used by the client device 120 to perform any necessary tasks or operations that may be implemented by the computer processor or other components in the client device 120.

[00125] The network and I/O interfaces 217 may also include one or more communication interfaces or network interface devices to provide for the transfer of data between the client device 120 and another device (e.g., network server) via a network 130.

[00126] The display 219 may include, but is not limited to, a liquid crystal display, a light-emitted diode display, or an E-lnk™ display as made by E Ink Corp. of Cambridge, Massachusetts. The display 219 may be used to show content to a user in the form of text, images, or video. In certain instances, the display 219 may also operate as a touch screen display that may enable the user to initiate commands or operations by touching the screen using certain finger or hand gestures.

[00127] The one or more service provider servers 135 may include one or more processors 261 and at least one memory 262, which may store an operating system 266, a POS service module 267, and a settlement module 268. Furthermore, the one or more service provider servers 135 may include network and I/O interfaces 263, a display 264, and storage 265. In some implementations, the one or more service provider servers 135 may be associated with one or more financial institutions and/or financial systems. As previously discussed, the service provider server(s) 135 may include multiple servers, such as one or more remote service servers 160 and/or one or more back-end servers 140. As such, in certain implementations, the functionalities associated with the POS service module 267 and the settlement module 268 may be performed by separate servers. For example, the functionality of the POS service module 267 may be implemented by the remote service server(s) 160, and the functionality of the settlement module 268 may be implemented by the back-end server(s) 140.

[00128] COMPUTING DEVICE ARCHITECTURES

[00129] In the example of FIG. 7, the computer system 700 may include a processor 302, a main memory 306, a non-volatile memory 310, and a network interface device 312. Various common components (e.g., cache memory) are omitted for illustrative simplicity. The computer system 700 is intended to illustrate example sub-components of the secure POS platform depicted in FIGs. 2-6. The computer system 700 may be of any applicable known or convenient type. The sub-components of the computer system 700 may be coupled together via a bus 330 or through some other known or convenient device.

[00130] This disclosure contemplates the computer system 700 taking any suitable physical form. As an example and not by way of limitation, the computer system 700 may be an embedded computer system, a custom built device and/or platform, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a wearable computer device, a server, or a combination of two or more of these systems or devices. Where appropriate, the computer system 700 may include one or more computer systems 700; be unitary or distributed; span multiple locations; span multiple machines; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 700 may perform, without substantial spatial or temporal limitation, one or more steps of one or more methods described or illustrated herein. As an example and not by way of limitation, one or more computer systems 700 may perform in real time or in batch mode one or more operations of one or more methods described or illustrated herein. One or more computer systems 700 may perform at different times or at different locations one or more operations of one or more methods described or illustrated herein, where appropriate.

[00131] The processor 302 may be, for example, a conventional microprocessor such as an Intel™ Pentium™ microprocessor or Motorola™ Power IDCTM

microprocessor. One of skill in the relevant art may recognize that the terms "machine- readable (storage) medium" or "computer-readable (storage) medium" include any type of device that can store data or instructions for the processor. The processor 302 may include computer-executable instructions 304.

[00132] The main memory 306 may be coupled to the processor 302 by, for example, a bus 330. The main memory 306 may include, by way of example but not limitation, random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). The main memory 306 may be local, remote, or distributed. The main memory 306 may include computer-executable instructions 308.

[00133] The bus 330 may also couple the processor 302 to the non-volatile memory 310 and drive unit 322. The non-volatile memory 310 may often be a magnetic floppy or hard disk, a magnetic-optical disk, an optical disk, a read-only memory (ROM), such as a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or another form of storage for large amounts of data. Some of this data may often be written, by a direct memory access process, into memory during execution of software in the computer system 700. The non-volatile storage may be local, remote, or distributed. The nonvolatile memory 310 is optional because systems may be created with all applicable data available in memory. A typical computer system may usually include at least a processor 302, a memory 306, and a device (e.g., a bus 330) coupling the memory 306 to the processor 302.

[00134] Software may typically be stored in the non-volatile memory 310 and/or the drive unit 322. The drive unit 322 may include a machine-readable (storage) medium 324. The machine-readable (storage) medium 324 may include instructions 326. Indeed, for large programs, it may not even be possible to store the entire program in the memory 306. Nevertheless, it should be understood that for software to run, if necessary, it is moved to a computer-readable location appropriate for

processing, and for illustrative purposes, that location is referred to as the memory 306. Even when software is moved to the memory for execution, the processor 302 may typically make use of hardware registers to store values associated with the software, and local cache that, ideally, serves to speed up execution. As used herein, a software program is assumed to be stored at any known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as

"implemented in a computer-readable medium." A processor 302 is considered to be "configured to execute a program" when at least one value associated with the program is stored in a register readable by the processor 302.

[00135] The bus 330 may also couple the processor 302 to the network interface device 312 to communicate via one or more networks 314. The network interface device 312 may include one or more of a modem or network interface. It will be appreciated that a modem or network interface may be considered to be part of the computer system 700. The interface may include an analog modem, an integrated services digital network (ISDN) modem, a cable modem, a token ring interface, a satellite transmission interface (e.g., "direct IDC"), or other interfaces for coupling a computer system to other computer systems. The interface may include one or more input and/or output (I/O) devices (e.g., video display 316, alpha-numeric input device 318, cursor control device 320, etc.). The I/O devices may include, by way of example but not limitation, a keyboard, a mouse or other pointing device, a gesture control and/or detection device, an eye movement control and/or detection device, disk drives, printers, a scanner, and other input and/or output devices, including a video display device 316. The video display device 316 may include, by way of example but not limitation, a cathode ray tube (CRT), a liquid crystal display (LCD), or some other applicable known or convenient display device. For simplicity, it is assumed that controllers of any devices not depicted in the example of FIG. 7 reside in the interface.

[00136] In operation, the computer system 700 may be controlled by operating system software that includes a file management system, such as a disk operating system. The file management system may typically be stored in the non-volatile memory and/or drive unit and causes the processor to execute the various acts required by the operating system to input and output data and to store data in the memory, including storing files on the non-volatile memory and/or drive unit.

[00137] Some portions of the detailed description may be presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated (e.g., by signal generation device 328). It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[00138] ALTERNATIVE REGISTER MODULE

[00139] As will be apparent from the following example, one potential application that can take advantage of certain features of the extensible POS platform is an alternative payment module that can run on client device 202 or cloud services server 210 of FIG. 5. The alternative register module can be built-in to certain client devices 202, but can also be provided as a third-party or external application. The alternative register module may be implemented to leverage a payment module.

[00140] A register module provided by a client device (e.g., client devices 202, 204, 206, and/or 208) may not provide certain functionalities for particular merchants (e.g., a pizza shop, a hardware store, etc.). As explained above, a client device (e.g., client devices 202, 204, 206, and/or 208) and/or cloud services servers 210 may include a register module that may be configured to provide a default or modified interface for an operator of the merchant/business to facilitate sales transactions. The register module may have bar code scanner functionality, check-out functionality, payment functionality, or any combination thereof. The alternative register module may be configured to communicate with a payment module associated with a client device (e.g., client devices 202, 204, 206, and/or 208) to accept available payment methods.

Additional tender methods may be provided through third-party applications as explained above. The payment module or the additional tender methods may authorize or decline payment based upon the merchant and/or the customer during execution of a transaction (e.g., sales transaction of goods or services).

[00141] EXTENSIBLE RECEIPTS

[00142] In another embodiment, the POS services process (e.g., POS services process 216, and/or 251 ) may be configured to provide a receipt module. A receipt module may be configured to handle receipts for a given transaction (e.g., a sales transaction, etc.). Receipts may be order receipts, payment receipts, or any other types of receipts associated with a POS platform system, such as 100. As can be seen in the following example, the receipt module may generate events to serve as triggers for external and third-party applications that have registered to listen for a broadcast of that event. In this sense, the printing of a receipt can serve as a transaction modification that causes applications to take certain actions. In accordance with the specific example below, printing the receipt can cause other applications on client device 202, or any of the other client devices (e.g., 204, 206, and 208) or cloud services server 210 to add an image to the receipt.

[00143] When printing a receipt of a transaction that may have initiated on a client device (e.g., client device 202), a POS services process (e.g., POS services process 216) may broadcast to other client devices (e.g., client devices 204, 206, and/or 208) and/or to cloud services server(s) (e.g., cloud services server(s) 210) that a printing receipt event occurred. Applications running on these client devices (e.g., client devices 204, 206, and/or 208) may be interested in that event and may transmit one or more images to the POS services process (e.g., POS services process 216 and/or 251 ) within a predetermined time. In certain embodiments, the image may be inserted into the print job of the receipt in a manner not to impact the execution of printing the receipt.

[00144] Although the example above is for applications running on client devices, in accordance with the characteristics of the extensible POS platform described previously, any other applications (e.g., external application(s) 240, application(s) 252) may be configured to transmit one or more images to the POS services process associated with printing the receipt. For example, coupons, promotions, discounts, invitations to use a digital and/or virtual wallet, or any other relevant campaign may be inserted during the printing of a receipt. The invitation to use a digital and/or virtual wallet may allow a customer to pay for the transaction using the digital and/or virtual wallet. It is understood that the above are only examples of images that may be inserted during the printing of a receipt and that other images of other campaigns may be inserted.

[00145] WALLET EXTENSIBILITY

[00146] In another embodiment, the POS services process (e.g., POS services process 216 and/or 251 ) may be configured to communicate with a wallet application module residing on a third-party server. For example, in a sales transaction, payment may be made remotely using a wallet application. When a payment is made, cloud services server(s) (e.g., cloud service(s) server 210) and one or more client devices (e.g., client devices 202, 204, 206, and/or 208) may be updated with the payment status. For example, during a sales transaction, the POS services process may provide the wallet application module with an order ID and an amount that is due. The wallet application may return a payment notification using one or more payment merchants. Consequently, cloud services server(s) (e.g., cloud services server(s) 210) and one or more client devices (e.g., client devices 202, 204, 206, and/or 208) may be updated with the payment status. It is understood that the above is only an example of a wallet application transaction and that other wallet applications and transactions may be envisioned.

[00147] MULTIPLE APPLICATIONS ON A POS DEVICE

[00148] In some embodiments, multiple applications may be executed on the POS devices. The applications may be in communication with each other to share

credentials and information. For example, one application that may execute on a POS device is a register application. A second application that may execute on the POS device may be an inventory application. Once a user signs into the register application, the register application and inventory application may communicate with each other to pass authentication credentials so the user only has to sign into the system once. The register application may communicate with the inventory application to obtain

information regarding the status of certain items in inventory. The different applications may be provided by the system or may be developed by third parties. In some embodiments, applications may have the ability to automatically discover each other and authenticate and interact with each other.

[00149] PAYMENT TYPE LOYALTY PROGRAM

[00150] In some embodiments, the POS platform may provide the ability for a merchant and/or a consumer to earn rewards for the use of specific payment types. For instance, if a merchant promotes the X Bank Card, and the customer uses that card as his or her payment type, the customer and the merchant may earn points (either fixed or in proportion to the amount spent at that merchant). The points may be redeemed via the POS platform during one or more purchase transactions that may be processed by the POS devices. The points may be associated with consumers via user profiles associated with consumers. The user profiles may be generated using information based at least in part on information received from the consumer. The user profiles may be stored in a remote database. The generated points or other loyalty-based incentives may be associated with the user profile and stored in association with the user profile. The POS devices may retrieve user profile information associated with the consumer, including information associated with the loyalty program, and may process transactions based at least in part on available loyalty program points. In some embodiments, the POS devices may retrieve a history of loyalty program points that have been earned, redeemed, expired, or the like.

[00151] EXAMPLE METHOD AND ARCHITECTURE FOR CLIENT DEVICE

[00152] FIG. 8 is a flow diagram of a method 800 for operating a client device on a secure POS platform. Method 800 can begin with step 501 in which secure data is received from a user via an input device. An example of step 501 could be a user 1 10 entering sensitive payment information on the touch screen of a point of sale terminal. This data, which could be in the form of coordinates that describe a touch interaction with a touch display, would be received by a touch controller such as input device controller 102. As another example of step 501 , a user 1 10 could enter similar information via other means such as a voice activated interface or standard key pad. Method 800 continues with step 502, in which the secure data is routed to a secure processor using a hardware multiplexer, and step 503, in which the secure data is processed by the secure processor. As an example based on FIG. 1 , the payment information received in step 501 could be routed to SP 106 by MUX 104, and then processed by SP 106. The mode in which client device 120 operates while routing data to SP 106 can be referred to as the secure mode.

[00153] Method 800 also includes steps that describe how the device operates in the normal or non-secure mode. In step 504, non-secure data is received from a user via an input device. An example of step 504 could be a user 1 10 entering a quantity of items to purchase using client device 120. In step 505, this data is routed to a second processor using the hardware multiplexer. The second processor could be AP 108. In step 506, the non-secure data is processed using the second processor.

[00154] The non-secure mode and secure mode differ in terms of which processor data is routed to for processing. With reference to the system in FIG. 1 , the routing state of MUX 104 sets which processor the data is routed to. In turn, the routing state of MUX 104 can only be controlled by SP 106. As such, when client device 120 is switched to operate in either mode, SP 106 can conduct either of steps 507 and 508 in which the routing state of the hardware multiplexer is altered. SP 106 will generally alter the routing state prior to the receipt of information from the user input device in order to match the mode of operation to the type of information being received.

[00155] FIGs. 9 and 10 illustrate a particular implementation of client device 120 described in FIG. 1 and include communication lines that have been annotated to illustrate the effect of the routing state of MUX 104 on the routing of data through the architecture. The particular implementation can be referred to separately as device 900. In the state illustrated by FIG. 9, device 900 is operating in non-secure mode. In the state illustrated by FIG. 10, device 900 is operating in secure mode. Active data lines in each figure have been annotated with white arrows to show the direction of data flow. Active control lines in each figure have been annotated with white circles.

[00156] Device 900 is capable of receiving user data from at least one input device. IDC 102 includes an input device user data connection to receive that data from an input device. As illustrated, IDC 102 is a touch screen controller which receives touch data from touch display 109. Device 900 also includes a set of additional input devices with additional input device user data connections. Any input device that handles secure data can be substituted in place of these additional devices. However, an exemplary set includes a chip reader 604, a near field communication (NFC) device 606, a magnetic swipe reader (MSR) 608, and a tamper sensor 610. The chip readers 604 may be configured to check one or more embedded microchips in a credit card or debit card or any other card that may contain readable information. The NFC device 606 may be configured to activate the client device 120 by touch or by proximity through a touch sensitive handle on the client device 120 or by detecting an NFC device within certain proximity of client device 120.

[00157] Device 900 also includes computing device 630 which includes multiplexer 104, SP 106, and a second processor. In the illustrated example, the second processor is AP 108. The multiplexer 104 includes a multiplexer control input port

communicatively coupled to a control output port on SP 106, a multiplexer data input port communicatively coupled to IDC 102, a first data output port communicatively coupled to a secure processor data input port on SP 106, and a second data output port communicatively coupled to a second processor data input port on AP 108. SP 106 and AP 108 are connected by bus 640. The elements of computing device 630 and the other components in device 900 are communicatively coupled in that information can be transmitted from one component and coherently received by the other component without intermittent alteration of that information. For the avoidance of doubt, information is not altered by standard signal conditioning or the application of CODECs that preserve the actual informational content of the signal. The term port is used here as it is used by those of skill in the art in the field of electronic communication and can encompass the pins of an integrated circuit, a via within an integrated circuit, a connection on a printed circuit board, or any other node in a circuit schematic.

[00158] The data lines that connect IDC 102 to MUX 104, MUX 104 to SP 106, and MUX 104 to AP 108 can comprise any communication interface such as I2C, SPI, USB, or equivalents along with any interrupts required by the peripheral controlled by IDC 102. Bus 640 between SP 106 and AP 108 can include any communication interface such as I2C, SPI, USB, UART, or equivalents. The number of interrupts required on bus 640 will vary depending upon the application as will be apparent to those of ordinary skill upon obtaining an understanding of the following disclosure.

[00159] MUX 104 is configurable between a first state and a second state. The first state corresponds to the secure mode of operation for device 900 and is illustrated in FIG. 10. The second state corresponds to the non-secure mode of operation for device 900 and is illustrated in FIG. 9. Examples of a secure operation may include entering a PIN used for cardholder verification, or entering a payment card number or verification code. Examples of non-secure transactions may include entering orders, entering a ZIP code, etc. When the current state of the multiplexer is the second state, the multiplexer data input port is communicatively coupled to the second data output port through the multiplexer. As seen in FIG. 9, this causes data to flow from IDC 102 through MUX 104 to AP 108. When the current state of the multiplexer is in the first state, the multiplexer data input port is communicatively coupled to the first data output port. As seen in FIG. 10, this will cause data to flow from IDC 102 through MUX 104 to SP 106. In both figures, the line connecting the control output port of SP 106 to the control input port of MUX 104 is emphasized using a white circle to note that the current state of MUX 104 is set by SP 106.

[00160] SP 106 has a direct connection to the set of second input devices in addition to that through IDC 102 and MUX 104. As illustrated, this set includes reader 604, NFC 606, MSR 608, and tamper sensor 610. SP 106 is communicatively coupled with a second input device in this set of second input devices via a second input device user data connection and a second data input port on SP 106. The connection is direct in that the devices are communicatively coupled with the secure processor 106 via the second input device user data connection and second data input port and not via MUX 104. In approaches in which SP 106 and MUX 104 are implemented on a single IC, the second data input port could be a second input pin on the IC in addition to the first data input pin that leads to the data input of MUX 104.

[00161] The current state of MUX 104 is exclusively controlled by SP 106 via the control output port of SP 106. In this regard, and with reference to FIG. 3, SP 106 can implement the functionality of security module 224. AP 108 can communicate with SP 106 along an inter-processor line which forms part of bus 640. AP 108 can utilize this line to indirectly affect the current state of MUX 104. For example, AP 108 can inform SP 106 that a user has requested a screen on display 108 for the entry of secure information. In response, SP 106 can choose to alter the routing state of MUX 104 and put device 900 into the secure mode of operation. In this example, AP 108 is only providing a request to transfer the state of MUX 104 and it does not control the state of MUX 104 directly. Also, once SP 106 takes control of MUX 104, SP 106 can be placed into a state in which it will not respond to any interrupts from AP 108 or other devices and will only relinquish control of the device and change the state of MUX 104 back when its own internal logic determines that such a change is necessary. This architecture thereby provides a high degree of control to SP 106 at the expense of AP 108. As a result, less secure programs can be installed on the device and run on AP 108 while a high level of security is still provided by SP 106.

[00162] The architecture illustrated in FIGs. 9 and 10 provides an additional benefit besides security in that IDC 102 can operate without regard to the state of computing device 630. In other words, a state machine that describes IDC 102 does not require information regarding whether or not device 900 is operating in the secure mode or the non-secure mode or information regarding the routing state of MUX 104. As shown in FIG. 9, when the device is operating in the non-secure mode, data will be passed through MUX 104 to AP 108. As shown in FIG. 10, when the device is operating in the secure mode, data will be passed through MUX 104 to SP 106. As long as SP 106 is configured to respond to data from IDC 102 in the same way that AP 108 does, IDC 102 will not need to know which processor is actually receiving the data it sends to computing device 630. As a result, steps 502 and 505 can both be preceded by identical pre-processing steps in which the data is pre-processed using IDC 102 in the same manner regardless of the state of MUX 104. Also, since AP 108 can be a standard applications processor, IDC 102 can also be an off the shelf user input device controller such as a standard touch display controller.

[00163] FIG. 9 and FIG. 10 include emphasized data lines that continue through the processors to display 109. In the secure mode of FIG. 10, data travels from SP 106 through inter-processor communication line 640 to AP 108 and then on through a display signal connection line to display 109. In the non-secure mode of FIG. 9, data travels from AP 108 through the display connection line to display 109. As a result, in either mode of operation AP 108 is the sole processor that display 109 needs to interact with. However, in the secure mode, SP 106 is controlling display 109 via a channel that comprises the inter-processor communication line 640 and display signal connection line.

[00164] SP 106 may apply one or more security algorithms (e.g., encryption) to protect subsequent outputs from the SP 106. Indeed, this may be one of the main components of the processing steps conducted by SP 106. Conducting encryption using SP 106 can provide device 900 with certain advantageous characteristics in that the crypto keys used to encrypt the information can be solely accessible to SP 106 and therefore isolated from AP 108.

[00165] The encryption can be conducted by an encryption module instantiated by SP 106 and a memory to which SP 106 has access. The encryption module can encrypt a quantum of data received from IDC 120 to create an encrypted quantum of data that is stored in that memory. The encryption module can also encrypt a quantum of data received from another input to the device such as MSR 608 or other input devices. The secure data entered on device 900 can be encrypted in real time as it is received or in bulk when the data is ready for transmission. SP 106 will have access to a network connection in order to send off secure data for verification. For example, SP 106 will be able to encrypt credit card information in order to receive an authorization for a charge against a credit card account. [00166] The transferred data can be sent through AP 108 and then on to a network connection. In these situations, the encrypted quanta of data can be sent along an inter-processor line on bus 640. Since the data is in encrypted form, it is safe to be handled by AP 108, and the actual network connection does not need to interface with SP 106. However, in certain approaches SP 106 will have an isolated network connection to send out authorization information and receive confirmation of

authorization.

[00167] In a POS application, SP 106 can conduct numerous additional secure features in addition to handling secure data and controlling when the state of MUX 104 should be altered. For example, SP 106 can run tamper sensors, such as tamper sensor 610, to determine when a physical attack has taken place on a device and destroy any sensitive information upon detection of an attack. SP 106 can also run code to conduct contact and contactless payments, and perform crypto operations required by the kernels of such payments, protect private keys used in the payment processing infrastructure.

[00168] The actual hardware implementation of SP 106 and AP 108 can vary in terms of the isolation between the devices. As will be described below, SP 106 and AP 106 can be implemented on the same physical processor. However, in certain embodiments, SP 106 and AP 108 can be independent microcontrollers. SP 106 and AP 108 can also be independently associated with first and second memories that are distinct and separate hardware components. The first memory can be associated with the operation of SP 106 and the second memory can be associated with the operation of AP 108. To ensure the security of SP 106, AP 108 may be incapable of addressing the first memory. As such, attacks that attempt to illicitly enter instructions for execution by SP 106 or access data utilized by SP 106 using AP 108 will not by physically possible. The independent microcontrollers may include multiple processing cores but the overall device will still be referred to herein as a processor.

[00169] One or more of the components in computing device 630 may exist on the same chip or a combination of the components may be on the chip, examples of which can be discussed with reference to FIGs. 1 1A-1 1 D. For example, MUX 104 and SP 106 could be implemented on a single integrated circuit while AP 108 and IDC 102 were left as stand-alone devices. In that IC, MUX 104 could be a block of circuitry on the IC, and SP 106 could include an encryption circuit configured to conduct the encryption operations for SP 106. In these approaches, the control output port of SP 106 and the control input of MUX 104 would be connected via interconnects in that single integrated circuit. In addition, the multiplexer data input port would be communicatively coupled to an input pin on the IC and the second multiplexer data output port (i.e., the one that is communicatively coupled to AP 108) would be communicatively coupled to an output pin on the IC. The pins on the IC could be solder bumps, copper posts, or any other IC packaging connection technology. As another example, and referring to FIGs. 1 1 A- 1 1 D, SP 106 and AP 108 may coexist on one multi-core processor, while MUX 104 may be a standalone device. One or more devices such IDC 102, chip reader 604, NFC 606, MSR 608 and tamper switch 610 may be accessible from the TrustZone™ of one of the cores of the multi-core processor. In order to access one or more of these device, an application may need to go through the TrustZone™ of the dedicate core.

[00170] In another embodiment, one core of a multi-core processor may be designated to function as SP 106 and another core to function as AP 108, while both of these cores may be connected directly to the MUX 104. Further, the IDC 102 may be connected to MUX 104. In that scenario, the IDC 102 may be isolated from both SP 106 and the AP 108. In one embodiment the TrustZone™ portion of the SP 106 core may determine whether the data passing through MUX 104 may go through SP 106 core or AP 108.

[00171] In another embodiment, a multi-core processor may not contain the TrustZone™ technology but instead rely on the physical security on the chip, such as, a secure mesh that protects the cores from tampering. It is understood that a multi-core processor may include any number of cores and not limited by the examples of FIGs. 1 1A-1 1 D.

[00172] In one embodiment, the IDC 102 may be connected directly to a

TrustZone™ area of a processor or a core of a multi-core processor. In this scenario, the core that includes the TrustZone™ may be always dedicated as a secure core that handles secure and normal (non-secure) transactions.

[00173] In one embodiment, it may not be necessary to have a MUX 104 included in the processing device 630. For example, in scenarios where a core of a multi-core processor is dedicated to be a secure microcontroller with a TrustZone™, and a IDC 102 may be connected through the TrustZone™, the TrustZone™ may decide whether to switch between secure and non-secure transactions based on the touches received from user 1 10 on client device 120.

[00174] EXAMPLE MODE TRANSITIONS AND TRANSACTION PROCESSING

[00175] Client device 120 can alternate between the secure mode and the nonsecure mode in various ways. After transitioning into secure mode, secure transactions can be conducted by SP 106 including reading data from display 109, reader 604, NFC 606, or MSR 608, encrypting that data, transmitting the data for authorization at a remote server, instantiating a virtual keypad on display 109, and other secure actions. After the secure transactions have been conducted, SP 106 will then relinquish control of client device 120 and then alter the state of client device 120 back to the non-secure mode.

[00176] SP 106 alters the state of MUX 104 to alternate the device between a secure mode and a non-secure mode. As mentioned previously, SP 106 has exclusive control over the state of MUX 104. However, given the particular architecture of the client device as described herein, there is no need for an additional interrupt line or special secure firmware on IDC 102 or AP 108 in order to enforce the secure mode of operation. Bus 640 will include a data line on which AP 108 can indicate that user inputs on IDC 102 are requesting a secure mode, and SP 106 can react to this information, but the manner in which access to the data from IDC 102 is provided is not burned into device 120. Instead, a dynamic runtime decision is made to decide which processor gets access to the input device. The decision is made entirely by SP 106, but can accommodate requests from any application running on AP 108 in a flexible manner. In addition, SP 106 can react directly to data received on a second input device without immediately interfering with the operation of AP 108. In specific approaches, this will also cause an interrupt to be sent on bus 640, but in these cases the interrupt will transfer from SP 106 to AP 108.

[00177] A set of methods in which a transition is made from the non-secure mode to the secure mode in response to a message sent by AP 108 can be described with reference to FIGs. 12-14. FIG. 12 illustrates a set of methods 1000 that can be conducted by a client device 120 in the form of a POS terminal having the architecture of device 1000. In these examples, device 1000 can be a POS terminal with a touch display in place of display 109, and IDC 102 may be a touch screen controller configured to receive touch input from user 110 (e.g., a merchant or customer) operating client device 1000.

[00178] In step 901 , a start transaction ("TX") message is sent from AP 108 to SP 106 using an inter-processor line on bus 640. The start transaction message can be provided by the AP 108 in response to receiving an input from a user. The input could indicate that the user wants to initiate a payment transaction, in which case SP 106 would administrate the entire payment transaction. However, the input could also indicate that the user would like to enter a secure piece of information, in which case SP 106 would only administrate the entry of that secure piece of information. In the context of a secure piece of information being entered as part of an overall payment flow, AP 108 could then retain control of the device for the other steps in the payment flow besides the receipt of the secure information. In this sense the term "transaction" is referring to a secure transaction between the user of the device and the device itself, not a payment transaction that is being conducted using the device. In keeping with this later case, the input can be the selection of a button on the screen that indicates the user would like to enter a credit card number manually, enter a PIN number, enter a CW number, or any other secure information. The specific example of a manual credit card number entry button 902 is provided in FIG. 12.

[00179] In step 903, the touch display is used to instantiate a secure interface. Prior to step 903, but after receiving the start transaction message, the routing state of MUX 104 can be altered as in step 507 of FIG. 8 under the control of SP 106. The secure interface will provide the user with the ability to view or enter secure information. For example, the secure interface could be a virtual keypad 904, an account selection interface, or an account information interface. Step 903 can be a sub-part of a larger process in which the SP 106 controls display 109 via the channel that includes the inter- processor line and the display drive line mentioned above. This channel can also include AP 108. As SP 106 controls display 109 in this step, and the data received in the secure mode is sent to SP 106, no programs associated with AP 108 will have access to the touch data entered on the keypad 904. In specific approaches, SP 106 will retain control of display 109 as the secure information is being entered so that it can display wild card characters while the user is entering the secure information.

[00180] FIG. 13 provides a ladder diagram showing the communication between SP 106 and AP 108 during the execution of step 903 in approaches where the control channel includes AP 108. In one embodiment, while a user 1 10 is entering secure information on display 109, SP 106 may send a message to AP 108 instructing it to display a virtual keypad. The AP 108 may carry out the instruction by communicating with display 109 of client device 120 and may respond (acknowledgement "Ack") to the SP 106 when the action is completed. SP 106 may receive one or more button touches on the touch screen and may convert one or more of the button touches to wild card characters (e.g., #, *, etc.). The AP 108 may respond to the SP 106 when the instructions are completed and the user 1 10 is presented with the characters (e.g., #, *, etc.). This process continues until user 1 10 presses a completion button, such as, "enter," "OK," etc.

[00181] After the secure data is entered, SP 106 can retain control of display 109 for a period of time while the secure data is processed. For example, SP 106 could retain control of the display while a PIN entered by the user is encrypted and transferred off of client device 120 for authorization as in step 905, when control is relinquished. The display could show a transaction processing screen to a user, and allow the user to exit secure mode by pressing a cancel button on the screen.

[00182] Alternative or additional secure transactions can be conducted in place of step 903 in FIG. 12. For example, the display of the virtual keypad could be combined with encryption of the received data and transmission of that data for authorization from a remote server. One of the secure transactions could be the activation and

communication with one of the input devices in FIG. 12 besides display 109. This communication could be conducted independent of AP 108.

[00183] FIG. 14 and 15 include ladder diagrams that show exemplary additional secure transactions that can be conducted along with step 903. The ladder diagrams show the exchange of information between the AP 108, SP 106, MUX 104, and other devices during the execution of these secure transactions. Both FIGs. 14 and 15 involve transactions where AP 108 initiates a request for the secure mode by sending a start transaction message to SP 106. However, the ladder diagrams differ in terms of what additional secure transactions are illustrated along with the receipt of secure data in secure mode.

[00184] In FIG. 14, the secure mode is activated and SP 106 takes control of display 109. However, SP 106 also activates reader 604, 606, or 608 (Readers "ON") in order to receive additional secure data via a second input device besides display 109. The additional secure data can be provided directly from readers 604, 606, or 608 to SP 106 such that it is not routed through MUX 104. The data can be received via a second data input port on SP 106 that is communicatively coupled with a user data connection providing data from the reader. SP 106 can then process the additional secure data by, for example, encrypting the secure data. The encrypted secure data can then be sent on to a remote server for authorization. As mentioned previously, SP 106 can send off the information via AP 108 as the data is in encrypted format. In FIG. 15, the secure mode is activated and SP 106 instructs AP 108 to display an account selection screen and PIN entry screen to receive secure information from a user in the form of a PIN and account. As illustrated in FIG. 15, the SP 106 can then instruct 108 to establish a network connection with a server 1200 in order to authorize the transaction by providing server 1200 with the secure data in encrypted form.

[00185] Device 900 will exit the secure mode under the control of SP 106 when SP 106 relinquishes control of display 109 as in step 905. Control can be relinquished before or after additional secure transactions are conducted. For example, as in the ladder diagram in FIG. 14, control can be relinquished prior to encrypting the data for transmission. As long as display 109 is not being used to input secure information, SP 106 can relinquish control of the display to AP 108. Once control is relinquished, SP 106 will alter the routing state of MUX 104 as in step 508.

[00186] In some approaches, SP 106 will force the device into the secure mode without receiving a prompt from AP 108. As illustrated in flow chart 1300 of FIG. 16, SP 106 could receive a direct communication from a second input device such as reader 604, NFC 606, MSR 608, or tamper sensor 610 as in step 1301. In step 1301 , a user of client device 120 may initiate a secure transaction without first prompting the device using IDC 120 and instead using a second user input device. For example, if a secure transaction and/or operation is performed by a merchant (e.g., user 1 10), such as, card swipe, insertion of a payment card, etc., the appropriate system (e.g., chip reader 604, or NFC 606, or MSR 608, or tamper switch 610) may be triggered. With specific reference to a POS terminal with a touch display and NFC reader, this kind of secure transaction could be initiated via the unprompted introduction of an NFC device into close proximity with the POS terminal.

[00187] In step 1302, SP 106 could issue a hardware interrupt to AP 108 to initiate a secure transaction and put the device into secure mode. Continuing the above example, depending on the token used to provide the direct input (e.g., debit card, credit card, or chip card) the SP 106 may be able to determine whether to instantiate a virtual keypad, account selection, or account information screen on the display of the device. If SP 106 determines that the entry of secure information is required, the routing state of MUX 104 could be altered to protect the secure information. As another example, SP 106 could receive a tamper indication in step 1301 and transfer the device into secure mode in 1302 to lock out the device. At that point, SP 106 could continue a secure transaction such as erasing any crypto keys stored on the device. After the secure transaction or transactions were complete, SP 106 could relinquish control in step 1303 and the device could return to non-secure mode.

[00188] EXEMPLARY ENCRYPTION METHODS

[00189] FIG. 17 illustrates another flow diagram of an example method for operating a secure POS platform in accordance with one or more example

embodiments. The description is provided with reference to AP 108 conducting the transaction; however, in certain approaches SP 106 will be able to conduct these operations directly. In one embodiment, the AP 108 may send secure information to the server. The secure information may be a result of the secure transaction conducted using SP 106. A certificate may need to be exchanged before the AP 108 may communicate with the server. The certificate may need to be signed by an authority associated with First Data Corporation of Atlanta Georgia, such as root certification authority (e.g., Clover™). The certificate may be captured in one or more secure areas of the AP 108. For example, if the AP 108 contains a secure area, such as, TrustZone (TZ™), the TZ™ may contain an encrypted key (or private key) that may be unique for the AP 108 processor. In other approaches, the certificate will be stored in a memory that is only accessible to SP 106.

[00190] In one embodiment, the AP 108 may look up the flash to determine whether a private key exists. If one exists, the key may be used with the TZ™.

However, if a key is not found, the flash may report that a block location is empty and that a key needs to be created. The TZ™ may encrypt the key and send it to the AP 108 that sends a request to the flash memory to save the key at the block location.

[00191] In one embodiment, the AP 108 may have a persistent identity that may be presented to the server. The persistent identity may be due to maintaining the same private key over factory resets and/or power failures.

[00192] In order for the private key to service reset or power failures, the private key may be written to a non-volatile flash area that may survive resets and/or power failures. The private key may be saved in a TZ™ area during initial installation of a client device 120 at a user premises. It is understood that TZ™ is a system for securing peripherals such as memory, crypto blocks, keyboard and displays to ensure they can be protected from software attacks.

[00193] In one embodiment, the SP 106 and the AP 108 may have a persistent identity to present to a server that may provide services or data to the SP 106 or AP 108. The persistent identity may be in the form of a digital public-key certificate (such as an X.509 certificate). The SP 106 and AP 106 may authenticate themselves to a server using either transport-level security (e.g., SSL/TLS) or message-level security (e.g., RSA signature over a message). The private key component may be protected by the SP 106 secure cryptographic device such that tampering with the device may erase the private key, or a master symmetric key. This may provide strong, cryptographic, persistent device-to-server authentication in such a way that devices may not be cloned and communications remain private and authentic.

[00194] This persistent, cryptographic identity may be used by SP 106 to obtain financial encryption keys remotely from the server, for example a triple DES key for use with the derived unique key per transaction (DUKPT) key management scheme, which is a standard in the electronic transactions industry. The persistent identity of the SP 106 and the AP 108 may help prevent against security attacks where a component of the client device 120 may have been compromised or hacked because the persistent identity may be encrypted and communicated between components within the client device 120 and/or outside the client device 120. In case of a malicious substitution of either the SP 106 or the AP 106 with other components, or a tamper event of the original components, the identity may not match which may render the client device 120 as compromised and may be inoperable. In one embodiment the SP 106 may implement a persistent identity by having a discrete battery for maintaining the private key or master symmetric key.

[00195] In one embodiment, the SP 106 and the AP 108 may have persistent identities that work as a pair. For example, each pair of SP 106 and AP 108 may be bonded by the pair of keys that define their persistent identity. In that sense, mixing various SP 106 and AP 108 that may not have been bonded together as a pair, may render the client device 120 inoperable. Therefore, only bonded pairs of SP 106 and AP 108 may function together in a client device 120. [00196] In one embodiment, a remote key injection may be implemented on the SP 106 and/or the AP 108. For example, the SP 106 and/or the AP 108 may be placed in a secure room, containing a certificate authority. The certificate authority may sign a certificate signing request from the SP 106 or AP 108, thus providing the device with its persistent identity.

[00197] In one embodiment, a key may be injected in the SP 106 and/or the AP 108. During manufacturing of semiconductor components, a process for injecting keys is typically done inside of a key injection room with an injection device. A key may be generated by placing the SP 106 and/or the AP 108 in a secure room and injecting the key into the SP 106 and/or the AP 108 by a key injection device.

[00198] In one embodiment, bonding of the SP 106 and the AP 108 may be performed at the same time as signing the public key certificates. The purpose is to provide additional security against tampering and component swapping between devices.

[00199] EXEMPLARY PHYSICAL SECURITY MEASURES

[00200] As stated previously SP 106 may be in direct communication with a tamper sensor 610 that may be activated in case of a determination of tampering, such as unauthorized attempt to access the client device 120. The tamper sensor can be connected to several tamper detection points including a detection point on a tamper resistant cover for client device 120. The tamper resistant cover may be in keeping with the cover in FIG. 18 which shows an upper view of an exemplary cover for client device 120.

[00201] Cover 1502 may obscure or otherwise protect certain areas of an associated printed circuit board 1504 of a POS device or client device, such as client device 120, which may be the target of third-party tampering. The cover 1502 can include any number of other physical security devices, techniques, and/or technologies to prevent, inhibit, or otherwise deter third-party tampering.

[00202] As shown in FIG. 18, the cover 1502 may be a relatively rigid structure with a predefined shape or configuration mounted to one or more areas of the printed circuit board 1504. The cover 1502 may be mounted to the printed circuit board 1504 by way of any number of physical connectors, soldering, adhesives, etc.

[00203] Further, the cover 1502 can include one or more physical security devices, techniques, and/or technologies. In one embodiment, the cover 1502 may include special traces that may be molded on or in the plastic. In one embodiment, the cover 1502 may contain one or more break channels embedded on the cover 1502 to deter tampering if the cover is attempted to be removed. For example, if an attempt was made to remove the cover 1502, one or more break channels may disconnect the cover 1502 from the printed circuit board 1504 rendering the associated client device 120 or POS device inoperable by way of one or more signals generated by the client device 120 or POS device, and sent by the client device 120 or POS device to a remote server, such as a Clover™ server operated by First Data Corporation of Atlanta, Georgia. In one embodiment, the cover 1502 may be a laser direct structuring (LDS) or other printed circuit with traces that may have certain predefined heat tolerance and/or resistance, flexibility, and/or strength characteristics. For example, the cover 1502 may have a predefined heat tolerance that may be relatively higher than the heat tolerance of one or more components of the client device 120 or POS device that are being obscured or otherwise protected by the cover 1502. Having a relatively higher heat tolerance than one or more components of the client device 120 or POS device may provide additional security against third-party tampering since exposing the cover 1502 to a temperature above the heat tolerance of one or more components of the client device 120 or POS device may render the one or more components inoperable and ultimately cause failure of or otherwise render inoperable certain functionality or features of the client device 120 or POS device. Similarly, the cover 1502 may have a relatively low flexibility tolerance to prevent flexing the cover 1502 beyond a predefined point of breakage. That is, the cover 1502 may break rather than flex, when the cover 1502 is flexed beyond a certain point. Breaking the cover 1502 may render the client device 120 or POS device inoperable by way of the client device 120 or POS device generating one or more signals, and sending the signals to a remote server, such as a Clover™ server operated by First Data Corporation of Atlanta, Georgia.

[00204] In another embodiment, the cover 1502 may include one or more zones that may each have one or more respective layers of physical security. In some embodiments, the cover 1502 may have a relatively high strength factor that prevents, inhibits, or deters drilling or other applying other forces to the cover 1502 to attempt to access the one or more components of the client device 120 or POS device.

[00205] For example, the cover 1502 may be divided into two zones (e.g., zones 1520 and 1530). The division of the zones may be based on what components of the printed circuit board 1504 are covered by that zone. Further, the zones may contain various layers of physical security, again, based on what components of the printed circuit board 1504 are covered by that zone. For example, zone 1520 may cover the IDC 102, the SP 106, the NFC 606, the MSR 608, and the chip readers 604. The IDC 102, the SP 106, the NFC 606, the MSR 608, and the chip readers 604 may be considered as sensitive components that may require additional security protection against tampering. A malicious access to one or more of these components may expose sensitive information and may provide access to secure data. Therefore, zone 1520 may contain one or more layers of security to prevent against malicious access. Zone 1530 may cover AP 108, memory 306, and the LCD device driver. Since these components may not contain sensitive data where a malicious access may not severely impact the client device 120, the zone 1530 may contain less layers of security than the zone 1520. It is understood that the above is only an example of division between two zones and that other divisions between one or more zones may be implemented based on the security need for the client device 120.

[00206] PRINTER ACTIVATION AND PAIRING PROCEDURES

[00207] Turning now to FIG. 19, a flow diagram of a method 1900 for activating a POS printer in a POS platform is illustrated according to one or more example embodiments. The method 1900 may include block 1902, in which a computer, such as a client device 120, remote service server(s) 160, and/or a combination thereof may determine the location of a print server or POS printer within a distance from the client device 120. In block 1904, the computer may generate a wake-up message associated with the print server using a communication protocol. For example, the wake-up message could be generated by printing module 227 and the communication protocol could be BLE™. In block 1906, the computer may establish a communication session with the print server. The communication session could be a regular Bluetooth connection that is established after the POS printer has received the wake-up message from the client device. In block 1908, the computer may generate a print job associated with the print server. [00208] Referring now to FIG. 20, a flow diagram of a method 2000 for associating a printing device and a client device, as described herein, is illustrated according to one or more example embodiments. FIGs. 21 -26 illustrate example user interfaces at the client device that may be presented during implementation of the method 2000 and will be discussed in conjunction with FIG. 20. These user interfaces may be displayed on a touch display of client device 120 and allow the user to administrate a pairing procedure with two-way identification between the client device and a printing device. Certain steps in method 2000 are optional as will be apparent from the following disclosure.

[00209] Prior to the execution of any of the steps in method 2000, a computer, such as client device 120, remote service server(s) 160, and/or a combination thereof may be powered on, while a printing device, such as POS printer 182, is not powered on. Alternatively, client device 120 may be outside a distance from any discoverable printing device. In either situation, the client device may be configured to present a user interface 2102 such as that illustrated in FIG. 21 , with instructions to begin establishing a connection between the client device and a printing device. For example, the user interface 2102 may instruct a user to power on a POS printer 182 and/or load paper into the printer. The user interface may additionally include instructions to move into closer proximity with a POS printer 182.

[00210] Next, but still prior to the execution of any of the steps in method 2000, the printing device may be powered on. As described herein, the printing device may be powered on in response to client device 120 generating a wake-up message associated with the printing device, or in response to the printing device being manually powered on. As mentioned previously, the wake-up message may be generated by a low power short range communication protocol such as BLE™. In some embodiments, the printing device and/or client device may present status indicators such as light emitting diodes, audible sounds, lights, or other indicators to indicate a power and/or operational status of the printing device to the user. Power status may indicate an on or off state, or a low battery state, for example. Operational status may include active connection, no paper, or low paper, for example. When, or before, the printing device is powered on, paper may be loaded into the printing device.

[00211] Turning to FIG. 20, optional steps 2001 -2003 may be conducted to assist in a two-way pairing procedure between the printing device and a client device. At block 2001 , the printing device may determine that paper is loaded in the printing device. At block 2002, the printing device may determine that the printing device is unassociated with at least one client device. For example, the POS printer 182 may determine that it is unassociated with the client device 120. This step can involve the POS printer 182 identifying a particular client device via a short range wireless discovery process or it can involve the POS printer 182 checking an internal data store to determine that it has not recorded an association with any client device. Upon determining that the printing device is unassociated with at least one client device, at block 2003 the printing device may automatically print device identification information for the printing device. For example, the POS printer 182 may print all of, or a portion of, the device hardware serial number. The printing device can be configured to execute steps 2001 -2003 once every time the printing device is manually turned on, every time it receives a wake-up message, or every time it engages in a discovery process with an unassociated client device via short range wireless communication. In another embodiment, the POS printer 182 may print a numerical sequence, a scannable barcode, such as a Quick Response Code, or other information associated with the printing device that allows the printing device to be identified.

[00212] In some embodiments, the printing device may be positioned nearby the client device, such that short range communication (e.g., BLE™, NFC, etc.) with the printing device is possible. Therefore, optional steps 2004 and 2005, which involve a discovery process for a short range communications protocol, may also be conducted to assist in the two-way pairing procedure between the printing device and a client device. Steps 2004 and 2005 could each be individually conducted in combination with steps 2001 -2003. Notably, steps 2004 and 2005 may be the impetus for step 2002 in that they both involve the POS printer and client device engaging in a discovery process via short range wireless communication.

[00213] In step 2004, the printing device will broadcast low energy packets that identify the device as a printing device. These packets could be broadcast repeatedly with a period of, for example, greater than 10 milliseconds in order to preserve the battery life of a mobile printer while still allowing for rapid discovery to facilitate a seamless pairing procedure. For example, the printing device could broadcast BLE™ packets identifying itself as a POS printer for reception by client devices that are within range. The client devices that are configured to operate with the printing device could be configured to scan for packets of that type and add them to a list of printing devices displayed on a user interface of the client device. The client devices could alternatively or in combination be configured to send wake-up messages to devices broadcasting such packets.

[00214] In step 2005, the client device will send out scans to find devices that claim to be the kind of devices they are meant to pair with. For example, client device 120 could scan for devices that claim to be POS printers 182. The devices could identify themselves based on the contents of a general identification field such as the "device name" fields of certain protocols. For example, the general identification field could include a company name, an additional identifier such as "printer", and the last few digits of a manufacturer's serial number for POS printer 182. In this example, the POS printer 182 will come "out of the box" with this information in the general identification field. As another example, the device name could be a registered object identifier prefix in a reserved MAC address range for the communications protocol used by the POS printer 182 and communications module 229. The prefix could be registered with an industry standards body.

[00215] Prior to the execution of step 2008, the user interface 2102 could be updated to user interface 2103 as shown in FIG. 22. The user interface 2103 further identifies POS printers that are detected or are otherwise available for pairing or establishing a connection with. Again, steps 2004 and 2005, as well as the introductory steps of any low energy wireless pairing procedure, can serve as the impetus for steps 2002, and the display of printing devices in user interface 2103 can in turn be conducted upon determining that the devices are unassociated in step 2002. As a result, the user interface can display any number of printing devices that are within the discoverable range of the client device.

[00216] In some embodiments where multiple printing devices are present and/or within communication range of the client device, the client device may utilize a two-way identification method of establishing a connection between one or more of the available printing devices so as to avoid unintentional pairings or pairings intended to disrupt or interrupt the connection between a printing device and another client device. As shown in user interface 2103, the list of POS printers could include a device identifier 2104 that matches the device identifier printed by the POS printer in step 2003. This would allow the user to visually inspect the device identifier on the POS printer and cross reference it with user interface 2103 to assure that they were pairing with the appropriate device. Since the POS printer 182 can be configured to print this information as soon as it engages in a discovery process with an unassociated client device as described above, the information will be readily and conveniently made available to the holder of an unassociated client device as they approach the POS printer.

[00217] User interface 2103 may present a user with detected POS printers 182, and may present an option to pair with or otherwise establish a connection with one or more available printing devices. Referring briefly to FIG. 23, in some instances the client device may detect more than one printing device, and may present a user interface 2105 with selectable options allowing the user to select one or more printing devices to establish a connection with. The client device may further present device identification information of one or more printing devices within communication range. The device identification information can take on any of the forms described above with respect to the device identifier 2104. A user may select one or more of the presented printing devices on the client device. The client device may be configured to establish a connection or be paired with a single or multiple printing devices, such that the client device can initiate printing at the printing device nearest the client device. In some embodiments, more than one client device may establish a connection or be paired with a single printing device, such that the single printing device serves as a shared printer. In other embodiments, multiple client devices may establish connections or be paired with multiple printers, such that an active client device can initiate printing at the nearest one of multiple possible printing devices.

[00218] Upon receiving user input and/or a selection of a printing device to pair with, the client device may transmit a request to associate with the selected printing device. Upon transmitting the request to establish a connection, the client device may present a user interface 2106 indicating an attempted connection, as shown in FIG. 24. In some embodiments, communication may be established between the client device and the printing device using any device pairing protocol where there is shared secret commonly derived between two devices (for example, a Diffie Hellman key agreement protocol) where the shared secret (or a derived hash thereof) must be confirmed by the operator between the two devices to ensure there is not a man-in-the-middle. Such a procedure can be used to establish a standard Bluetooth communication link between the printing device and the client device. In some embodiments, other forms of communication may be established between the client device and the printing device such as WiFi in accordance with established standards and protocols, such as the IEEE 802.1 1 family of standards, including via 2.4 GHz channels (e.g. 802.1 1 b, 802.1 1 g, 802.1 1 η), 5 GHz channels (e.g. 802.1 1 η, 802.1 1 ac), or 60 GHZ channels (e.g.

802.1 1 ad). Other suitable forms of communication between the client device and the printing device include WiFi Direct, or wireless communication over cellular network infrastructure, such as Global System for Mobile Communications (GSM), including 3G standards (e.g., Universal Mobile Telecommunications System (UMTS), Wideband Code Division Multiple Access (W-CDMA), CDMA2000, etc.), 4G standards (e.g., Long- Term Evolution (LTE), WiMax, etc.), 5G standards, direct satellite communications, or the like. [00219] At block 2008 of FIG. 20, the printing device may receive a request to associate with a client device. For example, the POS printer 182 may receive a request to pair with the client device 120. At block 2010, the printing device may automatically print client device association information upon receiving the request to pair with the client device. For example, the POS printer 182 may print a numerical sequence, a scannable barcode, such as a Quick Response Code, or other information configured to associate or otherwise establish a connection between the printing device and the client device. The client device association information can be derived from a shared secret that is generated on both the printing device and the client device using any device pairing protocol where such a shared secret is so derived between the two devices. For instance, the client device association information can be a string of human readable characters that are equivalent to the shared secret or represent a hash thereof.

[00220] Referring to FIG. 25, the client device may present a user interface 2107 prompting the user to input client device association information for the printing device for which a connection is to be established with. The user may enter the client device association information at the client device, for example at the user interface 2107 of FIG. 25, or in some embodiments, may scan or otherwise capture an image of the client device association information printed by the printing device. The scan can be conducted by a scanner on the client device when the client device includes a scanner such as that described with reference to FIG. 7.

[00221] Certain benefits accrue to this approach in that an alternative channel is provided via a printer and that is already configured to output information to a user in the ordinary course of its use, and a scanner that saves the user from having to enter the client device association information. Furthermore, some client devices used as POS terminals will already have scanners to obtain data from bar codes on merchandise or from payment tokens like coupons with QR codes. As such, the pairing procedure utilizes two-way communication but does not require any additional hardware. Notably, any input device used during the ordinary course of operation of the client device can be re-appropriated temporarily to conduct this portion of the pairing procedure. For example, a POS terminal with a camera used to conduct OCR processing of a drivers license can take a picture of a human readable string of characters on a printout to receive the client association information. As another example, the printer may be able to broadcast the client association information via NFC communication, and the client device may utilize a built in NFC receiver used to process NFC payments to obtain the client association information. In general, since POS terminals take in payment data from a user, and embodiments of the pairing procedure likewise requires the client device to take in client association information, the input device can advantageously be any input device that is also used to accept payment information from the user.

[00222] Upon receiving the client device association data, the client device may automatically pair with the printing device without further input from the user. At block 2012, the printing device associates with the client device based at least in part on the client device association information. For example, the POS printer 182 may be paired with the client device 120 when the client device receives the client device association information. Upon association of the printing device with the client device, the printing device may automatically print a test page or sample page to confirm association with the client device. If the client device association information entered on user interface 2107 (or received by the client device via some other input device) matches the information expected by the client device in accordance with the pairing protocol, the client device may present a user interface such as 2108 in FIG. 26 indicating that a connection has been established with the printing device and prompting the user to initiate a test print at the printing device. If the client device association information entered on user interface 2107 does not match the information expected by the client device in accordance with the pairing protocol, the client device can refuse to complete the pairing operation and can display a user interface requesting the client device information to be entered again.

[00223] BROADCAST AND RESPONSE PROCEDURE

[00224] Turning now to FIG. 27, a flow diagram of a method 2700 for an extensible POS platform is illustrated according to one or more example embodiments. The method 2700 may include block 2702, in which a computer, such as a client device 120, a remote services server(s) 160, and/or a combination thereof may receive a request for a POS transaction associated with a first location of a plurality of locations. In block 2704, the computer may broadcast, i.e. transmit, the POS transaction to another POS device associated with at least one of the first location and a second location of the plurality of locations. In block 2706, the computer may receive a request for a modification to the POS transaction. In block 2708, the computer may display the modified POS transaction.

[00225] The method 2700 may be conducted in accordance with the examples provided above that illustrate the functionality of the extensible POS platform. For example, the transaction can be an entire transaction or a specific modification to a transaction. Furthermore, the broadcasting of modifications to the transaction can be to a set of applications that are registered to receive those modifications. The modifications to a transaction may be, for example, adding new items to the order, including a donation to a charity with the order, adding taxes, receiving payment information, printing a receipt, applying coupons, adding a special notice on the transaction, or any other changes associated with the transaction.

[00226] DISPLAY OF INFORMATION ON THE USER INTERFACE

[00227] Referring to FIGs. 28 and 29, there are shown example user interfaces for an extensible POS platform in accordance with one or more example embodiments. FIG. 28 shows an example user interface that may be displayed on, for example, a customer-facing display screen of a client device during a purchase transaction, while FIG. 29 shows an example user interface that may be displayed on a merchant-facing display screen of a client device during a purchase transaction. As mentioned previously, third-party or external applications can share resources with a built-in application on the client device such that portions of the user interface can be generated by a register module, to provide information regarding a purchase transaction, while additional information from a third-party or external application is provided

independently of the built-in application. The information can be provided concurrently along with the information from the register module.

[00228] In a purchase transaction between a customer user and a merchant user, the client device 120 may display one or more user interfaces to the merchant user and/or the customer user at various instances during the purchase transaction. A built- in register application may be used to instantiate the user interface. For example, when a merchant user enters a quantity and price of an item, a location on the display screen of the client device 120 may include one or more areas displaying information controlled by one or more third-party or external applications, such as 240. The portion of the screen associated with the third-party or external applications can also control certain features or functionality of the client device 120. The displayed information may be independent of the purchase transaction and may relate to the one or more third-party or external applications, such as 240, that may control a particular area of the display screen of the client device 120.

[00229] For example, area 2802 of FIG. 28 is an area of a customer-facing user interface used by one or more third-party or external applications, such as 240, controlling certain features or functionality of the client device 120, to display information output by the one or more third-party or external applications 240. In certain instances, the one or more third-party or external applications 240 may generate for display in the area 2802 of the customer-facing user interface, an announcement for the customer, such as an announcement about a particular charity, an invitation to donate an amount via a donation box, an announcement with event information, an invitation to apply a coupon to the transaction, an invitation to utilize a specific payment method for the transaction, an offer to add an additional item or service to the transaction, etc.

Selection of the content can result in a modification to the transaction. The modification can be administrated by the third-party or external application.

[00230] In another example, area 2902 of FIG. 29 is an area of a merchant-facing user interface where merchant-related information from one or more third-party or external applications, such as 240, may be displayed. The same information, content, and interactivity that is provided with respect to area 2802 can be supplied in area 2902. It is understood that the above are only examples of the various types of information. Other embodiments may vary in the location of information that can be displayed on a customer and/or merchant-facing user interface, and when a third-party or external application may display information such as before, during, or after a purchase transaction.

[00231] EXAMPLE SYSTEM AND METHOD FOR ADJUSTING POS INTERFACE

[00232] According to one or more embodiments, the client device(s) 120 may be a POS device at a merchant location, such as a merchant store and/or the like. As shown in FIG. 30A, the client device 120 may be configured to present, via the POS application 216, a first user interface (e.g., a merchant or merchant-associated interface) to interact with a merchant employee 3004 associated with the merchant. For instance, the merchant interface may enable the merchant employee 3004 to create and/or otherwise generate one or more line items associated with items that a customer 3002 may wish to purchase. Furthermore, the merchant interface may enable the merchant employee 3004 to access one or more restricted functionalities available only to the merchant. For instance, the merchant interface may enable the merchant employee 3004 to access certain aspects of the POS application 216 and/or operating system 214 of the client device 120 via one or more selectable components (e.g., interface buttons, radials, menus, fields, and/or the like). In addition, the merchant interface may display and/or otherwise enable the merchant employee 3004 to access private information stored by and/or otherwise associated with the merchant, such as sales records, customer information, and/or the like.

[00233] In certain implementations, and as shown in FIG. 30B, in order to initiate a payment transaction for the items listed in the line items created by merchant employee 3004, the merchant employee 3004 may adjust the orientation and/or physical position of the client device 120 such that the display 219 faces the customer 3002. As previously discussed, the device sensor(s) 212 of the client device 120 may detect the change and/or adjustment in the position or orientation of the client device 120.

Furthermore, the device sensors 212 may transmit and/or otherwise provide an indication of the change and/or adjustment to the POS application 216.

[00234] In certain implementations, in order to initiate a payment transaction for the items listed in the line items created by a merchant employee, the merchant employee 3004 may input a particular indication via a button or lock key associated with a user interface of the client device 120. As previously discussed, the client device 120 may detect the indication, and may initiate a change and/or adjustment in the position or orientation of the user interface of the client device 120. In this manner, the user interface may rotate, flip, or otherwise adjust according to whether a merchant or a customer is to interact with the client device 120.

[00235] In any instance, in response to receiving the indication, the POS application 216 may be configured to change and/or adjust the merchant interface. In certain implementations, the POS application 216 may be configured to present a second interface (e.g., a customer or customer-associated interface) to facilitate customer interaction with the client device 120. For example, the customer interface may display information associated with the line items to customer 3002 (e.g., information associated with product details, pricing, and/or the like). Furthermore, the customer interface enables the customer 3002 to input, submit, and/or otherwise provide payment information to the client device 120. The payment information may be provided toward the customer's purchase of the item(s) listed in the one or more line items. In addition, according to some embodiments, the customer interface prevents the customer 3002 from having the ability to access the restricted functionality available to the merchant via the merchant interface. For instance, the customer interface may not include the selectable components, such as those provided by the merchant interface, that are used to access restricted functionality and/or other aspects

associated with the POS application 216 or the operating system 214. In addition, the customer interface may not display the private information associated with the merchant that may be provided by the merchant interface. In other words, the customer interface may be a "locked down" version of the merchant interface with restricted access to certain functionality of the POS application 216 and/or operating system 214.

[00236] Moreover, upon entering the payment information via the customer interface, the customer may adjust the orientation and/or position of the client device 120 again, such that the client device 120 and/or display 219 faces the merchant employee 3004. As such, the device sensor(s) 212 may detect the change and/or adjustment in the orientation or position of the client device 120. The device sensor(s) 212 may further be configured to submit a second indication associated with the adjustment to the POS application 216. In response to receiving the second indication, the POS application 216 may be configured to switch from the customer interface back to the merchant interface. To this end, the merchant interface may interact with the merchant employee 3004 to facilitate completion of a payment transaction for the item(s) listed in the line items.

[00237] According to one or more embodiments, the POS application 216 may submit the payment information, received from the customer 3002, to the service provider server(s) 135. The payment information may be provided to the settlement module 268, which may be configured to settle the payment transaction for the items according to the payment information. [00238] FIGs. 30C and 30D show adjustments to a physical position and/or orientation of a client device 120. In FIGs. 30C and 30D, customer 3002 and merchant employee 3004 interact with a client device 120. Client device 120 has a display 3010, on which a user interface is presented. In FIG. 30C, the client device 120 is in a first position, facing the merchant employee 3004. A first user interface 3020, such as a merchant-associated interface, is presented on display 3010. The first user interface 3020 may include, for example, functionality allowing the merchant employee 3004 to generate one or more line items associated with items to be purchased by the customer 3002, access to a first set of functionalities that are available only to the merchant 3004, and/or a button or lock key associated with the first user interface 3020. In FIG. 30D, the client device 120 has been adjusted in its physical position to a second position, where in this embodiment the display 3010 has been rotated to face the customer 3002, as indicated by arrow 3032, and the display 3010 has also been changed in orientation by turning, as indicated by arrow 3034. In this second position shown in FIG. 30D, a second user interface 3022 is presented. Second user interface 3022 has been adjusted compared to first user interface 3020, by having its orientation turned per arrow 3034. Second user interface 3022 is different from first user interface 3020 in that it presents features that are different from first user interface 3020, such as by presenting customer-associated features. The second user interface 3022 may be, for example, a customer-associated interface that facilitates customer payment of items being purchased. Thus, FIGs. 30C and 30D demonstrate that the first user interface 3020 and second user interface 3022 can be rotated, flipped, moved, or otherwise adjusted according to whether the merchant 3004 or customer 3002 is to interact with the client (i.e., POS) device 120. In some embodiments, the client device 120 can be repeatedly moved between the first position of FIG. 30C and second position of FIG. 30D as needed, in order to complete the interactions between the customer 3002 and merchant 3004. As in previous embodiments, the device sensor(s) 212 of the client device 120 may detect the change and/or adjustment in the position of the client device 120. Furthermore, the device sensor(s) 212 may transmit and/or otherwise provide an indication of the change and/or adjustment to the POS application 216. For example, the device sensor(s) 212 may be configured to detect when the physical position of the POS device is adjusted from the first position of FIG. 30C, and to detect when the position is adjusted from the second position of FIG. 30D. When an adjustment is detected, the POS device can be configured to automatically change the first user interface 3020 to the second user interface 3022, or vice versa, where the change can include an adjustment of the user interfaces 3020 and/or 3022 such as by modifying the orientation.

[00239] Turning now to FIG. 31 , a flow diagram of a method 3100 for adjusting POS interfaces is shown in accordance with one or more example embodiments. The method 3100 may include block 31 10, in which a POS device, such as a client device 120, may receive a first indication of interaction with a merchant. In block 3120, the POS device may present, in response to the first indication, a first user interface or merchant-associated interface associated with merchant interaction. In block 3130, the POS device may detect an adjustment to an orientation of the POS device. In block 3140, the POS device may determine, based at least in part on the adjustment, that the POS device is to interact with a customer. In block 3150, the POS device may be configured to present, in response to the determination, a second user interface or customer-associated interface associated with customer interaction. [00240] In another embodiment, a method for adjusting POS interfaces in accordance with one or more example embodiments can include some or all of the following operations. The method may include a block, in which a POS device, such as a client device 120, may receive a first indication of interaction with a merchant. In a following block, the POS device may present, in response to the first indication, a first user interface or merchant-associated interface associated with merchant interaction. In a following block, the POS device may receive and/or detect an indication of a particular user input to the POS device and/or indication of one or more transaction events with respect to the POS device. In a following block, the POS device may determine, based at least in part on the indication that the POS device is to interact with a customer. In a following block, the POS device may be configured to present, in response to the determination, a second user interface or customer-associated interface associated with customer interaction.

[00241] MOUNTING A COMMUNICATION ANTENNA BENEATH POS DISPLAYS

[00242] FIG. 32 depicts a cross-sectional view of an example internal configuration of a point of sale (POS) device 3200 in accordance with one or more embodiments of the disclosure. The POS device 3200 shown in FIG. 32 is operable to generate a predefined radio frequency (RF) field 3205 above or otherwise adjacent to the POS device 3200, for instance, above or adjacent to an associated touchscreen 3210 of the POS device 3200. In some embodiments, the predefined RF field 3205 may be generated from behind or opposing side of the flat panel display 3220 and the touchscreen 3210 but may be operable from above the flat panel display 3220 and the touchscreen 3210. In this manner, a user desiring to use a payment device with wireless payment communication capabilities, such as a smartphone enabled with a NFC (near field communication) chip, in a purchase transaction may, when prompted, wave the payment device above or otherwise in close proximity to the touchscreen 3210 of the POS device 3200 to facilitate wireless communications between the payment device and POS device 3200. The POS device 3200 may include the client device 120 shown in FIGs. 1 -6.

[00243] As depicted in FIG. 32, the POS device 3200 may include a housing 3215 enclosing internal components of the POS device 3200. The internal components of the POS device 3200 may include, but are not limited to a touchscreen 3210, flat panel display 3220, short-range wireless communication antenna 3225, and a support frame 3230. Other components that may be included within the POS device are structural supports, processors, memory, data storage, input/output (I/O) interface, network interface, power adapter, adhesive 3235 (described more fully in FIG. 33), etc.

[00244] In some embodiments, the touchscreen 3210 may be an electronic visual display that a user can control through simple or multi-touch gestures by touching an outer layer of the touchscreen 3210 with an instrument (e.g., stylus, pen, glove, etc.) or one or more fingers. Touchscreen technologies may include, but are not limited to resistive touch technology, surface acoustic wave technology, capacitive sensing, surface capacitance technology, projected capacitance technology, mutual capacitance technology, self-capacitance technology, infrared technology, infrared acrylic projection technology, optical imaging technology, dispersive signal technology, acoustic pulse recognition technology, etc.

[00245] In the embodiment shown in FIG. 32, the flat panel display 3220 may be positioned behind or underneath the touchscreen 3210 within the POS device 3200, wherein the touchscreen 3210 is mounted to a first outer surface of the flat panel display 3220. In some embodiments, the flat display 3220 may be a four inch (diagonal) or larger display.

[00246] The flat panel display 3220 may be categorized as volatile or static. A volatile display may require that pixels be periodically refreshed to retain their state, which may occur many times a second. Examples of a volatile flat panel display may include, but are not limited to, active-matrix liquid-crystal display (AMLCD), electronic paper, electroluminescent display (ELD), digital light processing display (DLP), organic light-emitting diode display (OLED), light-emitting diode display (LED), liquid-crystal display (LCD), plasma display panel (PDP), etc. A static flat panel display may rely on materials whose color states are bi-stable, where the image they hold requires no energy to maintain, but requires energy to change. Examples of a static display can include cholesteric displays, electrophoretic displays, etc.

[00247] In the embodiment shown in FIG. 32, the short-range wireless

communication antenna 3225 associated with a short-range wireless communication device (described in more detail in FIG. 33) may be positioned behind or underneath the flat panel display 3220 within the POS device 3200, wherein the antenna 3225 is mounted to an opposing or other outer surface of the flat panel display 3220. That is, the flat panel display 3220 is sandwiched between the touchscreen 3210 and the antenna 3225. A relatively thin layer of adhesive 3235 may be used to mount the antenna 3225 directly to the opposing surface of the flat panel display 3220. In some embodiments, the thin layer of adhesive 3235 may be used to mount the antenna 3225 directly to the support frame 3230. In any instance, the antenna 3225 may be electrically coupled to an associated wireless communication reader 3310 and optional amplifier 3315, which are shown in FIG. 33. [00248] One example of short-range wireless communication is near-field communication (NFC). Many handheld user devices, such as smartphones, tablets, smart watches, and the like, may use short-range wireless communication technology to facilitate transactions. The short-range wireless communication antenna 3225 is described with more detail with regards to FIG. 33. As depicted, the short-range wireless communication antenna 3225 may be positioned to provide a predefined radio frequency (RF) field 3205, which may be generated from behind or opposing side of the flat panel display 3220 and the touchscreen 3210, but operable from above the flat panel display 3220 and the touchscreen 3210. In some embodiments, the RF field 3205, is generally operable adjacent to and above the touchscreen 3210 of the POS device 3200. For example, a predefined radio frequency (RF) field 3205 can be generated from the POS device 3200 to permit certain short-range wireless

communication-enabled user devices, such as smartphones, tablets, smart watches, and the like, to detect or otherwise communicate via the RF field 3205 and facilitate a purchase transaction with the POS device 3200. In some embodiments, the predefined RF field range may extend up to approximately four centimeters from a particular location, such as the center portion, of the touchscreen 3210.

[00249] In some embodiments, the support frame 3230 may be positioned underneath the short-range wireless communication antenna 3225. In some

embodiments, the support frame 3230 may be called the midframe, and may provide certain rigidity to the POS device 3200 and/or the associated housing 3215 of the POS device 3200. In any instance, the support frame 3230 may be positioned in an internally central position of the POS device 3200 to provide support for other internal

components of the POS device 3200. In some embodiments, the support frame 3230 may be constructed out of metal, plastic, acrylic, or other material strong enough to support the weight and internal layout or design of the internal components of the POS device 3200.

[00250] Turning to FIG. 33, an overhead view of example configuration of a short- range wireless communication device 3300 is shown that includes a short-range wireless antenna 3305, similar to 3225 in FIG. 32, with an associated wireless communication reader 3310 and optional amplifier 3315 in accordance with one or more embodiments of the disclosure. As depicted, these components may be collectively known as a short-range wireless communication device 3300, and may include a reader 3310, an optional amplifier 3315, and an antenna 3305.

[00251] In some embodiments, the short-range wireless communication device 3300 may operate using relatively low frequencies (e.g., 13.56 MHz). Such low frequencies may be utilized for exchanging information related to financial transactions as the low frequency range makes it difficult for third parties to eavesdrop on associated communications and/or messages. In some embodiments, the short-range wireless communication device 3300 may be a NFC device. The reader 3310 may drive the amplifier 3315 and the antenna 3305 to generate the RF field, similar to RF field 3205 in FIG. 32, that in turn bridges the physical space between the POS device 3200 and short-range wireless communication-enabled devices. In some embodiments, the reader 3310 may drive the optional amplifier 3315 and antenna 3305 to generate an electromagnetic field 3205 transmitted above the touchscreen 3210. The short-range wireless communication enabled device may be positioned above the touchscreen 3210 of the POS device 3200, receive and convert the RF energy into power and uses the same energy and electromagnetic field signal to transport data back to the reader 3310 through antenna 3305. A communication link may be established and completed between the reader 3310 and the short rant wireless communication-enabled device. The reader 3310 may communicate the received data to other components of the POS device 3200 to facilitate a transaction between the short range wireless

communications-enabled device and the POS device 3200.

[00252] In some embodiments, the short-range wireless communication device 3300 may include the reader 3310 and the antenna 3305 and may not include the optional amplifier 3315, where the reader 3310 may drive the antenna 3305 to generate the RF field 3205, receive signals from the short-range wireless communication-enabled devices, and transmit the received data to the other components of the POS device 3200 to facilitate transactions between the POS device 3200 and the short range wireless communication-enabled devices.

[00253] As seen in FIG. 33, the antenna 3305 is shown with respect to a flat panel display 3320, similar to 3220 shown in FIG. 32. As described with respect to FIG. 33, the antenna 3305 can be mounted to a flat panel display, such as 3320, wherein the antenna 3305 is mounted to an opposing or other outer surface of the flat panel display 3320. In some embodiments, the antenna 3305 may be mounted to a support, such as 3230 in FIG. 32, wherein the antenna 3305 is mounted to a surface of the support frame facing towards the flat panel display 3320.

[00254] EXAMPLE METHODS OF MOUNTING AN ANTENNA BENEATH A POS DISPLAY

[00255] FIG. 34 is a flow diagram depicting an illustrative method 3400 for mounting an antenna, such as 3225 in FIG. 32, beneath a flat panel display, such as 3220 in FIG. 32, associated with a POS device, such as 3200 in FIG. 32, in accordance with one or more embodiments of the disclosure.

[00256] At block 3405 of method 3400, a touchscreen 3210 and flat panel display 3220 of a POS device, such as 3200, may be provided, wherein the touchscreen 3210 can include a first outer surface and an opposing outer surface, and the opposing outer surface is positioned adjacent to one side of the flat panel display 3220. In some embodiments, the touchscreen 3210 may utilize one of many different touchscreen technologies that have different methods of sensing touch, as described herein. The flat panel display 3220 may be of any type of flat panel display, such as those described herein. The flat panel display 3220 may be positioned behind the touchscreen 3210, where the front of the touchscreen 3210 is oriented to face outward or away from the POS device 3200 and visible by the user. In some embodiments, the flat panel display 3220 may be positioned along the side of the touchscreen 3210 not facing the user. In some embodiments, the flat panel display 3220 may be positioned along the backside of the touchscreen 3210 using positioning mechanisms, such as adhesives, clamps, screws, mounts, rails, or the like.

[00257] At block 3410, a short-range wireless communication antenna 3225 may be positioned adjacent to an opposing side of the flat panel display 3220. That is, the flat panel display 3220 may be sandwiched between the touchscreen 3210 and the short-range wireless communication antenna 3225. In some embodiments, a relatively thin layer of adhesive 3235 can be used to mount the short-range wireless

communication antenna 3225 to the opposing side of the flat panel display 3220. The short-range wireless communication antenna 3225 may be any kind of antenna suitable for a short-range wireless communication device, such as those described herein. In some embodiments, the short-range wireless communication antenna 3225 may be positioned along the backside of the flat panel display 3220 using any number of positioning mechanisms, such as adhesives, clamps, screws, mounts, rails, or the like. In some embodiments, any technique and/or device to mount the short-range wireless communication antenna 3225 to a portion of the opposing side of the flat panel display 3220 can be used as long as any mura effects on the flat panel display 3220 are minimized or otherwise eliminated.

[00258] At block 3415, a RF field 3205 can be generated from the short-range wireless communication antenna 3225, wherein the RF field 3205 extends outward from the first outer surface of the touchscreen 3210. When the short-range wireless communication antenna 3225 is electrically connected to an associated wireless communication reader 3310 and amplifier 3315, all of these components may collectively be known as a short-range wireless communication device, similar to 3300 shown in FIG. 33. In some embodiments, the short-range wireless communication device 3300 may be an NFC device. In any instance, the reader 3310 may drive the optional amplifier 3315 and antenna 3225 to generate an electromagnetic field 3205 transmitted above the touchscreen 3210. The short-range wireless communication enabled device may be positioned above the touchscreen 3210 of the POS device 3200, receive and convert the RF energy into power and uses the same energy and electromagnetic field signal to transport data back to the reader 3310 through antenna 3225. A communication link may be established and completed between the reader 3310 and the short range wireless communication-enabled device. The reader 3310 may communicate the received data to other components of the POS device 3200 to facilitate a transaction between the short range wireless communications-enabled device and the POS device 3200.

[00259] In one embodiment, a support frame, such as 3230, may be positioned behind the flat panel display 3220 and the short-range wireless communication antenna 3225. The support frame 3230 may be positioned adjacent to the opposing side of the flat panel display 3220 using any number of positioning mechanisms, such as relatively thin adhesives, clamps, screws, mounts, rails, or the like. In some embodiments, the support frame 3230 may be positioned to provide a relatively small air gap between the short-range wireless communications antenna 3225 and the support frame 3230.

[00260] In one embodiment, the short-range wireless communication antenna 3225 can be mounted to a portion of the support frame 3230, wherein the antenna 3225 is adjacent and in close proximity to the opposing side of the flat panel display 3220. In such an embodiment, a relatively small air gap may exist between the flat panel display 3220 and the antenna 3225. The antenna 3225 may be mounted to the support frame 3230 using any number of positioning mechanisms, such as relatively thin adhesives, clamps, screws, mounts, rails, or the like.

[00261] EXAMPLE EMBODIMENTS OF MOUNTED ANTENNA BENEATH A POS DISPLAY

[00262] FIG. 35 is an example embodiment of an approximate RF field 3505 generated by an antenna, such as 3225 in FIG. 32, mounted internally in a POS device 3500, similar to 3200 in FIG. 32. For example, in FIG. 35 and with reference to FIG. 32, the antenna 3225 may be mounted beneath touchscreen 3210 and the flat panel display 3220, where the RF field 3205 is generated within the width and length of the

touchscreen 3210 and flat panel display 3220 visible to the user. A user can orient his or her short-range wireless communication enabled device 3520 within the generated RF field 3505. In some embodiments, the flat panel display 3220 may generate a visual cue to indicate to the user where to orient his or her short-range wireless

communication enabled device 3520 in relation to the RF field 3505 generated by the antenna 3225.

[00263] FIG. 36 is an example embodiment of an approximate RF field 3605, different than the RF field 3505 in FIG. 35, generated by an antenna 3225 mounted internally in a POS device 3600, similar to 3200 in FIG. 32. For example, in FIG. 36 and with reference to FIG. 32, the antenna 3225 may be oriented in such a way that a portion of the RF field 3605 is generated within the width and/or length of the

touchscreen 3210 and flat panel display 3220 visible to the user and a portion of the RF field 3605 is generated within the bounds of another portion of the POS device 3600, such as within the length and/or width of the housing of the display portion of the POS device 3600, as depicted in FIG. 36. In some embodiments, the RF field 3605 may be visually depicted to the user through a visual means, such as a message generated by the flat panel display 3220 or a marking on a portion of the POS device 3600, such as a logo 3610 or other type of visual indication to guide the user to orient their short-range wireless communication enabled device 3615 in relation to the RF field 3605 generated by the antenna 3225.

[00264] EXTENSIBLE POS PLATFORM EXAMPLE IMPLEMENTATION

[00265] Specific approaches that are described above can be further illustrated by flow chart 3700 in Fig. 37. Flow chat 3700 includes a set of methods that are within the scope of the above disclosure and are provided to illustrate the potential of the extensible POS platform. In step 3701 , a user interface is displayed to a user in a purchase transaction on a display of a POS device using either the register module or the payment module described above. In step 3702 a transaction change is received via the user interface of the POS device and is used to modify the transaction. The transaction modification can be any of the kinds of modifications described above including receiving a request to print a receipt for the transaction or adding an additional item for purchase to the transaction. However, in this example, the modification is adding an item for purchase to the transaction. In step 3703, a database is updated with the transaction change. For example, an inventory database could be updated by decrementing an inventory count for a particular item when that item is added to a transaction. This step could also include updating additional databases with the modification. In step 3704, the modification is broadcasted to a plurality of other POS devices.

[00266] As shown in flow chart 3700, after the transaction modification is received in step 3702, the modification can also be broadcast to a set of applications on the same POS device that received the modification. This is illustrated by step 3705, which is conducted by the operating system 214. All of the steps in flow chart 3700 that lie on area 3706 can be conducted by a single POS device. This step can be preceded by step 3707 in which a set of third-party applications are registered to receive the broadcast transmitted in step 3705. Alternatively or in combination with step 3705, the third-party applications can receiving an indication that a condition was met by the modification. This is illustrated by step 3708. The indication can be generated by a process that uses the modification along with instructions to run a comparison against previously stored data. [00267] The previously stored data associated with step 3708 can be a certain dollar amount for a given transaction and the indication can indicate that the total value of the transaction exceeds that dollar amount. In step 3709, an action can be taken that modifies the purchase transaction using the third-party application. As illustrated, the action can include generating a text string or an image in step 3710 and adding that text string or image to a receipt or on a user interface of a display in step 371 1. The image can be generated prior to and independently of step 3707 such that it is on hand whenever an action is taken to request the addition of a generic or category-specific image to the transaction flow. The image can be an optional coupon added to a receipt of the purchaser in return for spending a certain dollar amount during their transaction. However, in this example the image is of a coupon that will be applied to the current transaction which is presented on the display of the device. Note that the coupon could have been provided via either channel in response to the same stimulus, such that the actions taken and the impetus for those actions can be independently designed and implemented using the extensible POS platform disclosed herein. Furthermore, the action can itself serve as a modification to the transaction in a second iteration of step 3702, which will propagate through the entire extensible POS platform. In this case, each POS device in the extensible POS platform would be able to keep track of how many coupons had been issued for a particular promotion without having to

continuously access a central database to obtain that information.

[00268] CONCLUSION

[00269] The operations and processes described and shown in the various methods described above may be carried out or performed in any suitable order as desired in various implementations. Additionally, in certain implementations, at least a portion of the operations may be carried out in parallel. Furthermore, in certain implementations, less than or more than the operations described may be performed.

[00270] Any computer-executable program instructions described herein may be loaded onto a special-purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flow diagram block or blocks. These computer program instructions may also be stored in a computer-readable storage media or memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage media produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks. As an example, certain implementations may provide for a computer program product, comprising a computer- readable storage medium having a computer-readable program code or program instructions implemented therein, said computer-readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks. [00271] While the specification has been described in detail with respect to specific embodiments of the invention, it will be appreciated that those skilled in the art, upon attaining an understanding of the foregoing, may readily conceive of alterations to, variations of, and equivalents to these embodiments. These and other modifications and variations to the present invention may be practiced by those skilled in the art, without departing from the scope of the present invention, which is more particularly set forth in the appended claims.

Claims

WHAT IS CLAIMED IS:
1. A device comprising:
an input device with an input device user data connection to an input device controller;
a multiplexer with a multiplexer control input port, a multiplexer data input port communicatively coupled to the input device controller, a first data output port, and a second data output port;
a secure processor with: (i) a control output port communicatively coupled to the multiplexer control input port; and (ii) a secure processor data input port
communicatively coupled to the first data output port; and
a second processor with a second processor data input port communicatively coupled to the second data output port;
wherein the multiplexer is configurable between a first state and a second state; wherein the multiplexer data input port is communicatively coupled to the first data output port through the multiplexer when a current state of the multiplexer is the first state;
wherein the multiplexer data input port is communicatively coupled to the second data output port through the multiplexer when the current state of the multiplexer is the second state; and
wherein the current state of the multiplexer is exclusively controlled by the secure processor via the control output port.
2. The device of claim 1 , wherein:
the input device is a touch screen display;
the device is a point of sale terminal; and
the touch screen display instantiates a virtual keypad for a user.
3. The device of claim 2, further comprising:
a display signal connection line between the second processor and the touch screen display; and an inter-processor communication line between the secure processor and the second processor;
wherein the inter-processor communication line and the display signal connection line provide a channel for the secure processor to control the touch screen display.
4. The device of claim 1 , further comprising:
a first memory associated with operation of the secure processor; and
a second memory associated with operation of the second processor;
wherein the first memory and second memory are distinct separate hardware components; and
wherein the second processor cannot address the first memory.
5. The device of claim 4, further comprising:
an inter-processor line between the secure processor and the second processor; and
an encryption module instantiated by the secure processor and the first memory; wherein the encryption module encrypts a quantum of data received from the input device to create an encrypted quantum of data; and
wherein the inter-processor line carries the encrypted quantum of data from the secure processor to the second processor.
6. The device of claim 1 , wherein:
the secure processor and the multiplexer are located on a single integrated circuit;
the multiplexer is a block of circuitry on the single integrated circuit; and the control output port and the multiplexer control input port are connected via interconnects in the single integrated circuit.
7. The device of claim 6, wherein:
the device operates in a secure mode and a non-secure mode;
the multiplexer operates in the first state when the device is in the secure mode; the multiplexer operates in the second state when the device is in the non-secure mode; and
a state machine that describes the input device controller does not require information regarding whether the device is operating in the secure mode or the nonsecure mode.
8. The device of claim 1 , further comprising:
an inter-processor line between the secure processor and the second processor; wherein the second processor can only affect the current state of the multiplexer indirectly via the inter-processor line and the secure processor.
9. The device of claim 8, further comprising:
a second input device with a second input device user data connection;
wherein the secure processor includes a second data input port; and
wherein the secure processor is communicatively coupled with the second input device user data connection via the second data input port and not via the
multiplexer.
10. The device of claim 1 , wherein:
the secure processor and the second processor are independent
microcontrollers.
1 1. An integrated circuit comprising:
a multiplexer with a multiplexer control input port, a multiplexer data input port, a first data output port, and a second data output port;
an input pin communicatively coupled to the multiplexer data input port;
a multiplexer control circuit communicatively coupled to the multiplexer control input port;
an input device data processing circuit communicatively coupled to the first data output port; and
an output pin communicatively coupled to the second data output port; wherein the multiplexer is configurable between a first state and a second state via the multiplexer control circuit;
wherein the multiplexer data input port is communicatively coupled to the first data output port through the multiplexer when a current state of the multiplexer is the first state; and
wherein the multiplexer data input port is communicatively coupled to the second data output port through the multiplexer when the current state of the multiplexer is the second state.
12. The integrated circuit of claim 1 1 , further comprising:
a touch screen display controller circuit communicatively coupled to a second output port;
wherein the input device data processing circuit is configured to receive a personal identification number from a user.
13. The integrated circuit of claim 1 1 , further comprising:
an encryption circuit configured to encrypt a personal identification number received on the first data output port to create an encrypted personal identification number;
wherein the integrated circuit is configured to output the encrypted personal identification number on a second output pin.
14. The integrated circuit of claim 1 1 , wherein:
the multiplexer is a block of circuitry; and
the multiplexer control circuit and the multiplexer control input port are connected via interconnects in the integrated circuit.
15. The integrated circuit of claim 1 1 , further comprising:
a tamper sensor processing circuit; and
a memory; wherein the tamper sensor processing circuit is configured to clear the memory if tampering is detected.
16. The integrated circuit of claim 1 1 , further comprising:
a second input pin communicatively coupled to the input device data processing circuit without passing through the multiplexer.
17. A method comprising:
receiving secure data from a user via an input device;
routing the secure data to a secure processor using a hardware multiplexer;
processing the secure data using the secure processor;
receiving non-secure data from the user via the input device;
routing the non-secure data to a second processor using the hardware
multiplexer;
processing the non-secure data using the second processor; and
altering a routing state of the hardware multiplexer using the secure processor; wherein the routing state of the hardware multiplexer is only controlled by the secure processor.
18. The method of claim 17, further comprising:
instantiating a virtual keypad for the user on a touch screen display;
wherein the input device is the touch screen display; and
wherein the secure data is a personal identification number entered via the virtual keypad.
19. The method of claim 18, further comprising:
controlling the touch screen display using the secure processor and a channel; wherein the channel includes the second processor; and
wherein controlling the touch screen display includes instantiating the virtual keypad.
20. The method of claim 17, wherein:
the processing of the secure data is conducted using a first memory;
the processing of the non-secure data is conducted using a second memory; the first and second memories are separate and distinct hardware components; and
the second processor cannot address the first memory.
21. The method of claim 17, further comprising:
transferring encrypted secure data from the secure processor to the non-secure processor using an inter-processor line;
wherein the processing of the secure data includes encrypting the secure data to create the encrypted secure data.
22. The method of claim 17, wherein:
the secure processor and the multiplexer are located on a single integrated circuit;
the hardware multiplexer is a block of circuitry on the single integrated circuit; and
the secure processor controls the multiplexer via interconnects in the single integrated circuit.
23. The method of claim 22, further comprising:
pre-processing the secure data using an input device controller before it is routed by the hardware multiplexer; and
pre-processing the non-secure data using the input device controller before it is routed by the hardware multiplexer;
wherein a state machine that describes the input device controller does not utilize information regarding the routing state of the hardware multiplexer.
24. The method of claim 17, further comprising:
transferring a start transaction message from the second processor to the secure processor using an inter-processor line; wherein the altering of the routing state of the hardware multiplexer is conducted under the control of the secure processor and after the start transaction message is received.
25. The method of claim 17, further comprising:
receiving additional secure data via a second input device; and
processing the additional secure data using the secure processor;
wherein the additional secure data is not routed through the hardware multiplexer.
26. A method comprising:
receiving secure data from a user via an input pin of an integrated circuit;
routing the secure data to an input device data processing circuit using a hardware multiplexer;
processing the secure data using the input device data processing circuit;
receiving non-secure data from the user via the input pin;
routing the non-secure data to an output pin of the integrated circuit using the hardware multiplexer;
altering a routing state of the hardware multiplexer using the secure processor; wherein the routing state of the hardware multiplexer is only be controlled by the secure processor.
27. The method of claim 26, further comprising:
encrypting a personal identification number received on the input pin using an encryption circuit on the integrated circuit to create an encrypted personal identification number;
outputting the encrypted personal identification number on a second output pin.
28. A computer-implemented method for pairing a point of sale printer with a client device, using two-way identification, comprising: receiving, using the point of sale printer and a wireless communication protocol, a request to pair the point of sale printer;
deriving, using the point of sale printer, the client device, and a device pairing protocol, a shared secret at the client device and the point of sale printer;
printing, using the point of sale printer and upon deriving the shared secret, client device association information on a printout;
receiving, using the client device and the printout, the client device association information; and
associating the point of sale printer and the client device using the client device association information as received using the client device.
29. The computer-implemented method of claim 28, further comprising:
determining, using the point of sale printer, that the point of sale printer is unassociated; and
automatically printing, using the point of sale printer and upon determining that the point of sale printer is unassociated, a print device identifier;
wherein the print device identifier identifies the point of sale printer.
30. The computer-implemented method of claim 29, further comprising:
presenting, using a user interface on the client device, a list of detected point of sale printers, wherein the point of sale printer is in the list of detected point of sale printers and is identified in the list using the print device identifier; and
sending, using the client device and upon selection of the point of sale printer from the list of detected point of sale printers, the request to pair the point of sale printer.
31. The computer-implemented method of claim 29, further comprising:
determining, using the client device, that the point of sale printer is within a distance of the client device; and
generating, upon determining that the point of sale printer is within the distance of the client device, a wake-up message associated with the point of sale printer using the client device.
32. The computer-implemented method of claim 31 , wherein:
the determining that the point of sale printer is unassociated step is conducted in response to the wake-up message.
33. The computer-implemented method of claim 31 , wherein:
the determining that the point of sale printer is unassociated step is conducted automatically when the point of sale printer is powered on.
34. The computer-implemented method of claim 33, further comprising:
displaying, using a user interface on the client device and prior to the determining that the point of sale printer is unassociated step, instructions to power on the point of sale printer and load paper into the point of sale printer.
35. The computer-implemented method of claim 28, wherein:
the client device association information on the print out is in the form of a scannable barcode;
the client device association information is the shared secret or a hash of the shared secret; and
the client device association information is received using the client device by scanning the scannable barcode.
36. The computer-implemented method of claim 28, wherein:
the client device association information on the print out is in the form of a string of human readable characters;
the client device association information is the shared secret or a hash of the shared secret; and
the client device association information is received using a user interface on the client device.
37. The computer-implemented method of claim 28, wherein the request to pair the point of sale printer is received in accordance with a short range communications protocol; and
the shared secret is derived using a Diffie Hellman key agreement protocol.
38. A computer-implemented method for pairing a printing device with a client
device, using two-way identification, comprising:
sending, from the client device, a request to pair the printing device;
receiving, using the printing device and a wireless communication protocol, the request to pair the printing device;
deriving, using the printing device and the client device, a shared secret in accordance with a device pairing protocol;
printing, using the printing device, client device association information on a printout, wherein the client association information is based on the shared secret; receiving, using the client device and the printout, the client device association information; and
automatically pairing the client device with the printing device upon receiving the client association information from the printout with the client device.
39. The computer-implemented method of claim 38, further comprising:
determining, using the printing device, that the printing device is unassociated; and
automatically printing, using the printing device and upon determining that the printing device is unassociated, a print device identifier;
wherein the print device identifier identifies the printing device.
40. The computer-implemented method of claim 39, further comprising:
determining, using the client device, that the printing device is within a distance of the client device; and
generating, upon determining that the printer device is within the distance of the client device, a wake-up message associated with the printing device using the client device; wherein the determining that the point of sale printer is unassociated step is conducted in response to the wake-up message.
41. The computer-implemented method of claim 40, wherein:
the wireless communication protocol is a short range communications protocol; the shared secret is derived using a Diffie Hellman key agreement protocol; and the printing device is a point of sale printer.
42. A system for pairing a printing device with a client device, using two-way
identification, comprising:
a communications module, instantiated on the client device, wherein the communications module is configured to send a request to pair the printing device using a wireless communication protocol and subsequently derive a shared secret with the printing device;
a printer, wherein the printing device is configured to instruct the printer to print client device association information upon the communications module deriving the shared secret;
a first printout, wherein the first printout is printed by the printer and includes the client device association information that is printed upon the communications module deriving the shared secret; and
an input device, provided on the client device, to receive the client device association information;
wherein the communications module is also configured to associate the printing device with the client device using the client device association information received via the input device.
43. The system of claim 42 wherein:
the communications module is a Bluetooth module;
the shared secret is derived using a key agreement protocol; and
the printing device is a point of sale printer.
44. The system of claim 42, further comprising: a second printout, wherein the second printout is printed by the printer and includes a print device identifier that identifies the printing device;
wherein the printing device instructs the printer to print the print device identifier upon determining that the printing device is unassociated.
45. The system of claim 44, further comprising:
a printer module, instantiated on the client device, wherein the printer module is configured to determine if the printing device is within a distance of the client device; wherein the printer module is configured to generate, upon determining that the printing device is within the distance of the client device, a wake-up message associated with the printing device.
46. The system of claim 45, wherein:
the printing device is configured to determine if the printing device is
unassociated in response to the wake-up message.
47. The system of claim 45, wherein:
the printing device is configured to determine if the printing device is
unassociated automatically when the point of sale printer is powered on.
48. The system of claim 42, further comprising:
a user interface on the client device that displays instructions to power on the printing device and load paper into the printer.
49. The system of claim 42, further comprising:
a scanner on the client device that serves as the input device to receive the client device association information;
wherein the client device association information is the shared secret or a hash of the shared secret; and
wherein the client device association information is provided on the first printout in the form of a scannable barcode.
50. The system of claim 42, further comprising:
a user interface on the client device that serves as the input device to receive the client device association information;
wherein the client device association information is the shared secret or a hash of the shared secret; and
wherein the client device association information is provided on the first printout in the form of a string of human readable characters.
51. A computer-implemented method for an extensible point-of-sale device,
comprising:
registering a third-party application to be notified of a transaction change on the point-of-sale device;
displaying a user interface to a user during a purchase transaction on a display of the point-of-sale device using one of a register module and a payment module;
receiving the transaction change via the user interface of the point-of-sale device; broadcasting the transaction change to a set of registered applications that includes the third-party application; and
taking an action that modifies the purchase transaction using the third-party application in response to the broadcasting.
52. The computer-implemented method for an extensible point-of-sale device of
claim 51 , wherein:
the action is inserting an image onto a receipt printed for the purchase
transaction by the point-of-sale device.
53. The computer-implemented method for an extensible point-of-sale device of
claim 52, wherein the action of inserting the image onto the receipt comprises: transmitting the image to a services process on the point-of-sale device from the third-party application;
adding the image to the receipt using the services process; and
printing the receipt for the purchase transaction using the services process.
54. The computer-implemented method for an extensible point-of-sale device of claim 51 , wherein:
the action is inserting a text string onto a receipt printed for the purchase transaction by the point-of-sale device.
55. The computer-implemented method for an extensible point-of-sale device of claim 51 , wherein:
the action is displaying information on the display of the point-of-sale device.
56. The computer-implemented method for an extensible point-of-sale device of claim 55, further comprising:
generating the information to display on the point-of-sale device using the third- party application; and
displaying the information on an area of the display along with the user interface.
57. The computer-implemented method for an extensible point-of-sale device of claim 56, wherein:
the third-party application displays the information on the area of the display independently of the register module; and
one of the register module or payment module concurrently displays transaction data along with the information on the display.
58. The computer-implemented method for an extensible point-of-sale device of claim 51 , wherein:
the action is inserting a user interface element on a payment window display screen of the user interface.
59. The computer-implemented method for an extensible point-of-sale device of claim 58, wherein:
the third-party application displays the a user interface element on the display; and the register module concurrently displays the payment window on the display along with the button.
60. The computer-implemented method for an extensible point-of-sale device of claim 59, wherein:
the a user interface element initiates a method of payment provided by the third- party application.
61. An extensible point-of-sale device, comprising:
a POS processing service that registers a third-party application to be notified of a transaction change on the point-of-sale device; and
a display that displays a user interface to a user during a purchase transaction; and
a register module that receives the transaction change involving the purchase transaction via the user interface of the point-of-sale device;
wherein the third-party application is configured to take an action to modify the purchase transaction in response to a trigger; and
wherein the POS processing service is configured to provide the trigger via a broadcast of the transaction change to a set of registered applications that includes the third-party application.
62. The extensible point-of-sale device of claim 61 , further comprising:
a printer that prints a receipt for the purchase transaction with an added image using the POS processing service on the point-of-sale device;
wherein the action is transmitting the image to the POS processing service from the third-party application;
wherein the transaction change generates a printing receipt event to initiate a printing process; and
wherein the trigger is the printing receipt event.
63. The extensible point-of-sale device of claim 61 , further comprising: a printer that prints a receipt for the purchase transaction with an added text string using the POS processing service on the point-of-sale device;
wherein the action is transmitting the text string to the POS processing service from the third-party application;
wherein the transaction change generates a printing receipt event to initiate a printing process; and
wherein the trigger is the printing receipt event.
64. The extensible point-of-sale device of claim 61 , wherein:
the action is generating information to display on the display; and
the information is displayed on an area of the display along with the user interface.
65. The extensible point-of-sale device of claim 61 , further comprising:
a network connection; and
a local database that stores the transaction change in a queue;
wherein the point-of-sale device is configured to upload the transaction change from the queue via the network connection when the point-of-sale device is able to communicate with a server.
66. A computer-implemented method for an extensible point-of-sale device,
comprising:
displaying a user interface to a user during a purchase transaction on a display of the point-of-sale device using a register module;
modifying a customer order with a modification received via the user interface of the point-of-sale device;
updating a database using the modification and a server; and
broadcasting the modification to a plurality of other point-of-sale devices.
67. The computer-implemented method for an extensible point-of-sale device of claim 66, further comprising: updating a second database using the modification and the server;
wherein: one of the second database and the database is an inventory database; and
the modification decrements a quantity in the inventory database.
68. The computer-implemented method for an extensible point-of-sale device of claim 66, further comprising:
registering a third-party application to be notified of a transaction change on the point-of-sale device;
broadcasting the modification to the third-party application; and
taking an action that modifies the purchase transaction using the third-party application in response to the broadcasting to the third-party application.
69. The computer-implemented method for an extensible point-of-sale device of claim 68, wherein:
a built-in register application on the point-of-sale device is used to instantiate the user interface.
70. The computer-implemented method for an extensible point-of-sale device of claim 66, further comprising:
receiving an indication that a condition was met by the modification using a third- party application; and
taking an action that modifies the purchase transaction using the third-party application in response to the indication;
wherein the register module is part of a built-in register application on the point- of-sale device.
71. The computer-implemented method for an extensible point-of-sale device of claim 70:
wherein the third-party application is on one of the plurality of other point-of-sale devices.
72. The computer-implemented method for an extensible point-of-sale device of claim 70, wherein:
the action is applying a coupon to the purchase transaction.
73. The computer-implemented method for an extensible point-of-sale device of claim 70, wherein:
the action is applying an additional charge to the purchase transaction.
74. The computer-implemented method for an extensible point-of-sale device of claim 70, wherein:
the action is inserting an image onto a receipt printed by the point-of-sale device.
75. The computer-implemented method for an extensible point-of-sale device of claim 74, wherein the action of inserting the image onto the receipt comprises: transmitting the image to a services process on the point-of-sale device from the third-party application;
adding the image to the receipt using the services process; and
printing the receipt for the purchase transaction using the services process.
76. The computer-implemented method for an extensible point-of-sale device of claim 66, further comprising:
generating information for displaying to a user using a third-party application; and displaying the information on an area of the display screen along with the user interface but independently from the purchase transaction and register module.
77. A point of sale (POS) device comprising:
a memory configured to store data and computer-executable instructions;
a display configured to present a user interface, the user interface comprising a first interface and a second interface; and
a sensor configured to detect an adjustment in a physical position of the POS device from a first position and from a second position; wherein the first interface is presented in the first position and the second interface is presented in the second position; and
wherein the first interface has a first set of functionalities that is prevented from being accessible in the second interface.
78. The POS device of claim 77, wherein the first interface is a merchant-associated interface and the second interface is a customer-associated interface, the first set of functionalities being accessible only by a merchant.
79. The POS device of claim 78, wherein:
the first interface is configured to facilitate a creation of one or more line items by the merchant, the one or more line items being associated with one or more items to be purchased by a customer; and
the second interface is configured to facilitate customer payment of the one or more items.
80. The POS device of claim 78, wherein in the first position the display faces the merchant, and in the second position the display faces a customer.
81. The POS device of claim 77, wherein the first interface is a merchant interface and the second user interface is a locked down version of the first interface.
82. The POS device of claim 77, wherein the adjustment in the physical position is a change in orientation selected from a group consisting of: turning, rotating, flipping, or moving.
83. The POS device of claim 82, wherein:
the adjustment in the physical position is a change in orientation by turning; and the user interface rotates, flips, moves, or is otherwise adjusted according to whether a merchant or a customer is to interact with the POS device.
84. The POS device of claim 77, wherein the computer-executable instructions are configured to:
receive an indication, from the sensor, of the adjustment to the physical position of the POS device; and
present either the first interface or the second interface in response to receiving the indication from the sensor.
85. The POS device of claim 77, wherein the computer-executable instructions are configured to:
receive an indication of a user input to the POS device; and
present either the first interface or the second interface in response to receiving the indication of the user input.
86. A computer-implemented method comprising:
receiving, by a point of sale (POS) device that includes one or more processors, a first indication of interaction with a merchant;
presenting, by the POS device in response to the first indication, a first user interface associated with the merchant;
detecting, by the POS device, an adjustment to an orientation of the POS device; determining, by the POS device, based on the adjustment to the orientation, that the POS device is to interact with a customer; and
presenting, by the POS device in response to the determination, a second user interface associated with a customer interaction;
wherein the first user interface includes a first set of functionalities, and the second user interface is configured to prevent the first set of functionalities from being accessible to the customer.
87. The method of claim 86, wherein the first indication of interaction with the
merchant comprises a) generation of one or more line items associated with items to be purchased by the customer, b) access of the first set of functionalities that are available only to the merchant, or c) input via a button or lock key associated with the first user interface.
88. The method of claim 86, wherein the first set of functionalities comprises an ability to view or access private information including sales records, customer information, or merchant information.
89. The method of claim 86, wherein the first interface is a merchant interface and the second user interface is a locked down version of the first interface.
90. The method of claim 86, wherein:
the detecting is performed by a sensor of the POS device; and
the adjustment detected by the sensor is a change in the orientation to a first position.
91. The method of claim 86, further comprising:
detecting, by the POS device, a second adjustment to the orientation of the POS device;
determining, by the POS device based on the second adjustment, that the POS device is to interact with the merchant; and
presenting, by the POS device in response to the determination based on the second adjustment, a third user interface associated with merchant interaction.
92. The method of claim 91 , wherein:
the first user interface is configured to facilitate a creation of one or more line items associated with one or more items to be purchased by the customer;
the second user interface is configured to receive payment information associated with the purchase of the one or more items; and
the third user interface is configured to facilitate payment of the one or more items according to the payment information.
93. The method of claim 86, wherein the adjustment to the orientation comprises turning, rotating, flipping, or moving the POS device to face the merchant or the customer.
94. A point of sale (POS) system comprising:
a display;
a sensor;
a memory configured to store data and computer-executable instructions; and a processor configured to access the memory, the processor also being configured to execute the computer-executable instructions to:
receive a first indication of interaction with a merchant;
present, in response to the first indication, a merchant-associated interface associated with merchant interaction;
detect, using the sensor, an adjustment to a physical position of the display; determine, based on the adjustment, that the POS system is to interact with a customer; and
present, in response to the receipt, detection, or determination, a customer- associated interface associated with customer interaction;
wherein the customer-associated interface is restricted from accessing a first set of functionalities that is in the merchant-associated interface.
95. The POS system of claim 94, wherein the first indication of interaction with the merchant comprises a) generation of one or more line items associated with items to be purchased by the customer, b) access of the first set of functionalities that are available only to the merchant, or c) input via a button or lock key associated with the first user interface.
96. The POS system of claim 94, wherein the first interface is a merchant interface and the second user interface is a locked down version of the first interface.
97. The POS system of claim 94, wherein:
the adjustment to the physical position is a change in orientation selected from a group consisting of: turning, rotating, flipping, or moving; and
the adjustment includes adjusting the physical position to face the merchant or the customer.
98. The POS system of claim 94, wherein the customer-associated interface is rotated, flipped, moved, or otherwise adjusted in response to the determination that the POS system is to interact with the customer.
99. The POS system of claim 94, wherein the physical position comprises a) a first position in which the display faces the merchant, wherein the merchant- associated interface is presented in the first position, and b) a second position in which the display faces the customer, wherein the customer-associated interface is presented in the second position.
PCT/US2015/057863 2014-10-29 2015-10-28 Secure extensible point of sale platform WO2016069775A1 (en)

Priority Applications (10)

Application Number Priority Date Filing Date Title
US201462072420P true 2014-10-29 2014-10-29
US62/072,420 2014-10-29
US201462074061P true 2014-11-02 2014-11-02
US201462074063P true 2014-11-02 2014-11-02
US201462074064P true 2014-11-02 2014-11-02
US201462074062P true 2014-11-02 2014-11-02
US62/074,064 2014-11-02
US62/074,063 2014-11-02
US62/074,061 2014-11-02
US62/074,062 2014-11-02

Publications (1)

Publication Number Publication Date
WO2016069775A1 true WO2016069775A1 (en) 2016-05-06

Family

ID=54602008

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/057863 WO2016069775A1 (en) 2014-10-29 2015-10-28 Secure extensible point of sale platform

Country Status (1)

Country Link
WO (1) WO2016069775A1 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3244375A1 (en) * 2016-05-10 2017-11-15 Atos Worldline Microcontroller for secure starting with firewall
WO2017222696A1 (en) * 2016-06-21 2017-12-28 Square, Inc. Transaction interface control
EP3447706A1 (en) * 2017-08-24 2019-02-27 Clover Network Inc. Distributing payment keys among multiple discrete devices in a point of sale system
WO2019162082A1 (en) * 2018-02-23 2019-08-29 Fujitsu Client Computing Limited Method for providing secure access to hardware components within a user terminal, and user terminal of this type
WO2019162276A1 (en) * 2018-02-23 2019-08-29 Fujitsu Client Computing Limited Method for securing access to information within a user terminal, and user terminal of this type
FR3084554A1 (en) * 2018-07-30 2020-01-31 Ingenico Group METHOD FOR SECURE DATA TRANSMISSION BETWEEN A PAYMENT TERMINAL AND A WIRELESS PRINTER
US10607200B2 (en) 2015-12-28 2020-03-31 Square, Inc. Point of sale system having a customer terminal and a merchant terminal
US10783508B1 (en) 2014-12-16 2020-09-22 Square, Inc. Processing multiple point-of-sale transactions
US10783509B2 (en) 2017-09-29 2020-09-22 Square, Inc. Message sizing and serialization optimization
EP3751749A1 (en) * 2019-06-14 2020-12-16 Clover Network Inc. Multi-use near field communication front end on a point of sale system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070280475A1 (en) * 2003-12-19 2007-12-06 Stmicroelectronics Limited Monolithic Semiconductor Integrated Circuit And Method for Selective Memory Encryption And Decryption

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070280475A1 (en) * 2003-12-19 2007-12-06 Stmicroelectronics Limited Monolithic Semiconductor Integrated Circuit And Method for Selective Memory Encryption And Decryption

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10783508B1 (en) 2014-12-16 2020-09-22 Square, Inc. Processing multiple point-of-sale transactions
US10607200B2 (en) 2015-12-28 2020-03-31 Square, Inc. Point of sale system having a customer terminal and a merchant terminal
EP3244375A1 (en) * 2016-05-10 2017-11-15 Atos Worldline Microcontroller for secure starting with firewall
WO2017222696A1 (en) * 2016-06-21 2017-12-28 Square, Inc. Transaction interface control
US10504092B2 (en) 2016-06-21 2019-12-10 Square, Inc. Transaction interface control
EP3447706A1 (en) * 2017-08-24 2019-02-27 Clover Network Inc. Distributing payment keys among multiple discrete devices in a point of sale system
US10783509B2 (en) 2017-09-29 2020-09-22 Square, Inc. Message sizing and serialization optimization
WO2019162082A1 (en) * 2018-02-23 2019-08-29 Fujitsu Client Computing Limited Method for providing secure access to hardware components within a user terminal, and user terminal of this type
WO2019162276A1 (en) * 2018-02-23 2019-08-29 Fujitsu Client Computing Limited Method for securing access to information within a user terminal, and user terminal of this type
FR3084554A1 (en) * 2018-07-30 2020-01-31 Ingenico Group METHOD FOR SECURE DATA TRANSMISSION BETWEEN A PAYMENT TERMINAL AND A WIRELESS PRINTER
WO2020025451A1 (en) * 2018-07-30 2020-02-06 Ingenico Group Secure method for transmitting data between a payment terminal and a wireless printer
EP3751749A1 (en) * 2019-06-14 2020-12-16 Clover Network Inc. Multi-use near field communication front end on a point of sale system

Similar Documents

Publication Publication Date Title
US10528934B2 (en) Payment terminal system and method of use
US10915906B2 (en) System and method for facilitating secure self payment transactions of retail goods
US20190066104A1 (en) Systems and methods for enhanced data routing based on a reconciled configuration
US20180357637A1 (en) Authentication token for wallet based transactions
US20200160371A1 (en) Extensible point-of-sale platforms and associated methods
US9904800B2 (en) Portable e-wallet and universal card
US9312923B2 (en) Personal point of sale
US20200051073A1 (en) System and method for enhanced token-based payments
US20190172048A1 (en) Security system incorporating mobile device
US10891619B2 (en) Dynamic transaction card protected by gesture and voice recognition
US10713648B2 (en) Dynamic transaction card for visual impairment and methods thereof
US10089471B2 (en) System and methods for secure firmware validation
US10346838B2 (en) Systems and methods for distributed enhanced payment processing
CN105474224B (en) Security platform system and correlation technique, device and electronic equipment
US10127538B2 (en) Smart integrated point of sale system
US10402818B2 (en) System, method, and apparatus for a dynamic transaction card
US20200302481A1 (en) Multi-mode point-of-sale device
US8805725B2 (en) Payment vehicle recommendations based on payment rules
CN105389699B (en) Mobile merchant proximity solution for financial transactions
AU2012370407B2 (en) Hub and spokes PIN verification
US10839081B2 (en) System and methods for secure firmware validation
US10360557B2 (en) Dynamic transaction card protected by dropped card detection
US9218557B2 (en) Portable e-wallet and universal card
US10769617B2 (en) Using a mobile device in a commercial transaction
US10043175B2 (en) Enhanced near field communications attachment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15797501

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15797501

Country of ref document: EP

Kind code of ref document: A1