Patent Description:
Fuel dispensers typically include a controller configured to handle sensitive payment information received from a user to effect payment for fuel dispensed to the user. The sensitive payment information is usually provided to the fuel dispenser via one or more components, such as a card reader and a PIN pad. Any sensitive payment information received by the PIN pad is generally encrypted and forwarded to the controller regardless of whether the PIN pad uses a separate controller. Because the controller is configured to handle the sensitive payment information, it is usually subject to certain security requirements imposed on devices that handle such information, which may include a certification process. Any changes to the design of the controller typically require recertification, which can be a relatively protracted and expensive process. This process may also impact other functions of the fuel dispensers supported by the controller. <CIT> discloses an information collection method of a fuel dispenser in fueling system, involving encrypting data of data entry point devices for transmission to a location removed from the fuel dispenser when content to be presented at the fuel dispenser requests sensitive information.

The present invention is as set out in the appended independent claim; advantageous embodiments of the present invention are set out in the appended dependent claims of the independent claims.

The disclosed aspects will hereinafter be described in conjunction with the appended drawings, provided to illustrate and not to limit the disclosed aspects, wherein like designations may denote like elements, and in which:.

The examples described in relation to <FIG>, <FIG> and <FIG> fall within the scope of the present invention according to the appended claims, whereas the examples described in relation to <FIG> and <FIG> do not and are only offered for the purpose of better understanding the present invention as claimed.

Reference will now be made in detail to various aspects, one or more examples of which are illustrated in the accompanying drawings. Each example is provided by way of explanation, and not limitation of the aspects.

Described herein are various aspects relating to securing components of a vending machine, such as a fuel dispenser, or at least certain functions thereof, from other components to facilitate security, tamper-proofing, etc. In some cases, this can facilitate replacement of components without requiring recertification. For example, a secure controller can be used to secure a component where the component, or another component or related function, is active. In a specific example, the fuel dispenser can include a display with touchscreen functionality, and a secure controller operatively connected to the display can manage the display such to limit access thereof where the touchscreen display is requesting personal identification number (PIN) entry via the display or a PIN entry device (PED). Limiting access can include locking the display for use only by an application accessing the display, disabling the touchscreen functionality, limiting a number of touchable regions, and/or the like. Moreover, for example, the components accessing the display can relate to one or more processors, where at least one of the processors can verify authentication of applications executing thereon by determining whether the applications are signed by an authenticated entity to provide another layer of security for accessing the display.

In another example, various components can be separated by using separate controllers to operate the components, separate printed circuit boards (PCB) to operate the components, etc. In other examples, a component to be secured can have sole access to another component, such to ensure the accessed component cannot be used to infiltrate the secured component. In this example, the secured component can include a secure controller for providing security thereto, and can use the secure controller to operate the other component in accordance with security parameters or policies defined by or for the secured component.

In one specific example, a PIN pad in a fuel dispenser can operate separately from a display such to secure PIN pad communications of confidential PIN information received during a transaction. Multiple configurations of the PIN pad and display, and communications therebetween, are possible to achieve security within the PIN pad. For example, the PIN pad can include a controller for various operations, including obtaining information as an input interface (e.g., obtain numbers pressed by a user), communicating secured information to other systems (e.g., a transaction processing system), communicating general information to/from other systems, etc. The controller can be a secure controller, for example, that can block access to the PIN pad when the PIN pad is activated for use with a certain application. This secure controller can operate the display as well from the PIN pad, which can allow the PIN pad to ensure the display is not used to tamper with confidential information processed by the PIN pad. In this example, the display does not need a controller, and the PIN pad can communicate with the display over a communicative medium, such as one or more cables, which can provide additional features as described herein.

In other examples, it is to be appreciated that the display can have a second controller separate from that of the PIN pad (e.g., and/or the display and PIN pad correlate to separate PCBs). In this regard, the controller for the PIN pad (or at least for sensitive functions thereof) can communicate with the display via the second controller, but can regulate whether and/or what sort of communications can be received from the second controller. In one example, the controllers can implement secure communication paths or channels to ensure another component does not compromise the communications path. For example, the controllers can use encryption, such as a digital certificate, or some sort of similar communication-based implementation. In an additional or alternative example, a hardware verification can be used, such as dismounting sensors, to detect tampering with the display, the second controller, or communications media displaced between the controllers.

Moreover, though illustrated and described as embodied in a fuel dispenser, it is to be appreciated that aspects described herein can be similarly applied to substantially any vending machine that processes transaction payment or other processes involving confidential information while maintaining the ability to execute other applications.

Certain aspects of the embodiments described herein are related to fueling environments, fuel dispensers, and user interfaces for fuel dispensers, examples of which may be found in <CIT>), <CIT>), <CIT>), <CIT>), <CIT>),<CIT>), <CIT>), <CIT>), <CIT>),<CIT>),<CIT>), and <CIT>), <CIT>), and <CIT>).

<FIG> is a partially schematic, perspective view of a fueling environment <NUM> adapted to provide fuel and to accept payment for the dispensed fuel. Fueling environment <NUM> includes at least one fuel dispenser 200a and a central facility <NUM>. Typically, one or more additional fuel dispensers, such as fuel dispenser 200b, may also be included within fueling environment <NUM>. Fueling environment <NUM> may also include a canopy system <NUM> connected to central facility <NUM> that provides shelter to fuel dispensers 200a and 200b.

Central facility <NUM> includes a point-of-sale device (POS) <NUM> and a site controller <NUM> and may include additional computing devices, such as cashier and/or manager workstations. In the example illustrated, POS <NUM> includes an associated card reader and payment terminal <NUM>. Each of POS <NUM> and site controller <NUM> may also include a display, a touchscreen, and/or other devices, such as a printer. It should be understood that the functionality of POS <NUM>, site controller <NUM>, and any additional computing devices within central facility <NUM> may be incorporated into a single computer or server. Alternatively, these computing devices may be operatively interconnected via a local area network (LAN). An example of a suitable system that may be used in conjunction with subject matter described herein combines the functions of POS <NUM> and site controller <NUM>, to which multiple payment terminals <NUM> may be operatively connected, is the PASSPORT system offered by Gilbarco Inc. of Greensboro, North Carolina.

It is to be appreciated that fueling environment <NUM> may include a number of other components to facilitate the dispensing of fuel. In the example provided by <FIG>, for instance, fueling environment <NUM> includes two underground storage tanks (USTs) <NUM> and <NUM> configured to store fuel that is available for purchase. For example, USTs <NUM> and <NUM> may be stocked with respective grades of fuel. USTs <NUM> and <NUM> are in fluid communication with an underground piping network <NUM> to which dispensers 200a and 200b are connected. As a result, fuel stored within USTs <NUM> and <NUM> may be delivered to the dispensers for purchase. Moreover, in one example, dispensers 200a and 200b can obtain information regarding the USTs <NUM> and <NUM> (e.g., a tank level, an environment indicator, such as temperature around the tank, etc.), and can communicate the information to the POS <NUM>, site controller <NUM>, or other device to allow for tank monitoring and/or notification of safety issues.

<FIG> is a partially schematic, front elevation view of a fuel dispenser <NUM> that may be used as fuel dispensers 200a and 200b in the fueling environment of <FIG>. Fuel dispenser <NUM> includes a user interface <NUM> that includes a first controller <NUM>, a second controller <NUM>, a display <NUM>, a card reader <NUM>, and a numeric pad <NUM>. Controller <NUM> is operatively connected to controller <NUM> and to display <NUM>, while controller <NUM> is operatively connected to controller <NUM> and to card reader <NUM> and numeric pad <NUM>. It is to be appreciated that user interface <NUM> may include other components, such as a cash acceptor and/or a receipt printer, etc. Each of controllers <NUM> and <NUM> includes an Ethernet adapter and communicates with the other controller via the transmission control protocol and the Internet protocol (e.g., transmission control protocol (TCP)/internet protocol (IP), user datagram protocol (UDP), etc.), as explained below. Alternatively, controllers <NUM> and <NUM> may be connected via a universal serial bus (USB) connection and configured to communicate via the USB connection or other wired or wireless (e.g., Bluetooth, wireless local area network (WLAN), etc.) connection. In one example, one or more of the controllers <NUM> and <NUM> may be included within devices of the fuel dispenser <NUM>, such as display <NUM>, PIN pad <NUM>, etc., as describer further herein, and in some examples, one or more of the controllers <NUM> and <NUM> may not be present, or maybe replaced by another controller where the remaining controller implements functionality such that the replaced controller is not needed.

For purposes of the ensuing explanation, it is to be appreciated that card reader <NUM> may be any device or combination of devices configured to receive data from payment cards supplied by users that contain sensitive or confidential account or payment information (referred to generally herein as sensitive information or confidential information). Card reader <NUM>, for instance, may be a magnetic stripe card reader, a smart card reader, a contactless card reader, a radio frequency (RF) reader, or any combination thereof. Thus, the term "payment card" as used herein is intended to encompass magnetic stripe cards, smart cards, contactless cards, and RF devices, as well as other forms of cards and devices that are configured to store and provide account information. Information received from such a payment card is referred to herein as "payment data" for purposes of explanation, while the portion of the payment data sufficient to identify the account associated with the payment card is referred to as "sensitive payment data. " Thus, it is to be appreciated that "payment data" as used herein may include both sensitive and non-sensitive payment information. Moreover, it is to be appreciated that "sensitive payment data" may include other confidential information, such as a PIN associated with the payment card, and is also referred to generally as "sensitive data," "confidential information," or similar terms.

In the presently-described example, card reader <NUM> is configured to accept payment data from various types of payment cards, including credit and debit cards, prepaid and gift cards, fleet cards, any local/private cards, etc. accepted by fueling environment <NUM>. It should be appreciated that card reader <NUM> may also be configured to receive account information from non-payment and other cards, such as loyalty, frequent shopper, rewards, points, advantage, and club cards. Numeric pad <NUM> is also configured to receive payment data, such as the PIN associated with a payment card. For at least this reason, numeric pad <NUM> may be referred to in the ensuing explanation as a PIN pad (also known as a PED).

Moreover, it is to be appreciated that fuel dispenser <NUM> also includes various fuel dispensing components configured to facilitate the delivery of fuel to a vehicle. For instance, fuel dispenser <NUM> additionally includes a piping network <NUM>, a meter <NUM>, a pulser <NUM>, a valve <NUM>, a hose <NUM>, and a nozzle <NUM>, which can be duplicated to allow delivery of multiple fuel grades. Controller <NUM> is operatively connected to one or more of these components, such as pulser <NUM> and valve <NUM>, to control operation thereof and/or to manage the delivery of fuel by fuel dispenser <NUM>. Piping network <NUM> is in fluid communication with underground piping network <NUM>, as described in <FIG>, to receive fuel from the USTs. Piping network <NUM>, hose <NUM>, and nozzle <NUM> are also in fluid communication to supply the fuel to a vehicle. In other examples described herein, fuel dispenser <NUM> may include one of controllers <NUM> and <NUM>, in which case controller <NUM> may operate the fuel dispensing components instead (or in addition).

User interface <NUM> is configured to facilitate the dispensing of fuel and the acceptance of payment for the dispensed fuel. For instance, display <NUM> is configured to provide instructions to a user regarding the fueling process and to display totals during and at the completion of the transaction. Display <NUM> can be a liquid crystal display (LCD), light emitting diode (LED) display, plasma display, etc. In addition, display <NUM> can be a touchscreen or a non-touchscreen display. Card reader <NUM> and PIN pad <NUM> are configured to accept payment data (e.g., as provided by the user). That is, card reader <NUM> can be configured to receive account information from a payment card, such as a credit or debit card. PIN pad <NUM> is configured to at least receive information associated with the payment card, such as a PIN of a debit card, the billing postal (zip) code of a credit card, etc. In an example, PIN pad <NUM> can be a physical PED, such as a number pad with hard keys, or can be a virtual PED on display <NUM>, as described further herein. As noted above, other devices may be included within user interface <NUM>, which may also be configured to facilitate financial transactions for the dispensed fuel. For example, a cash acceptor may be configured to handle transactions involving cash payments, while a receipt printer is configured to print a receipt upon completion of the fueling process if desired.

User interface <NUM> may also be configured to exchange information with a user unrelated to the fueling transaction. For instance, display <NUM> may be configured to provide advertisements or other information to the user, such as regarding items available for sale in the associated convenience store. PIN pad <NUM> (or a set of soft keys, such as those referenced below) may be configured to receive a selection from the user regarding the displayed information, such as whether the user is interested in nearby amenities. In this regard, for example, PIN pad <NUM> can be used in conjunction with the card reader <NUM> and/or display <NUM> to communicate data that is not as sensitive as payment information as well.

Further, a fueling environment <NUM> (<FIG>) can be configured such that fuel dispenser <NUM> may be operatively connected to a wide area network (WAN) <NUM>, such as the Internet. It should be understood that fuel dispenser <NUM> may be connected either directly to WAN <NUM> or indirectly via one or more additional components, such as one or more devices <NUM>. It is to be appreciated that the additional components may include routers, switches, gateways, and other devices that participate in the LAN referenced above. In one example, devices <NUM> can include one or more of POS <NUM>, site controller <NUM> to which the fuel dispenser is directly connected, etc. Alternatively, fuel dispenser <NUM> is operatively connected to POS <NUM> and/or site controller <NUM> indirectly via the LAN. An example of a suitable configuration of the fueling environment's computing devices is set forth in the <NUM>/<NUM>,<NUM> application referenced above. It should also be understood that other external resources, such as a server <NUM>, may be operatively connected to WAN <NUM> and accessible to fuel dispenser <NUM> and/or fueling environment <NUM> (<FIG>) via the WAN.

<FIG> is a diagrammatic representation of an example user interface, such as user interface <NUM>, comprising controllers <NUM> and <NUM>, display <NUM>, card reader <NUM>, and PIN pad <NUM>. In this example, user interface <NUM> also includes a contactless card reader <NUM> and additional components <NUM> operatively connected to controller <NUM>, as well as a printer <NUM> and soft keys <NUM>, etc. operatively connected to controller <NUM>. User interface <NUM> may include additional components <NUM> and an auxiliary video input <NUM> operatively connected to controller <NUM>. If included, auxiliary video input <NUM> may be configured to supply controller <NUM> with audio and/or video to be presented to the user from an alternative source, as explained in more detail below.

In this example, controller <NUM> is operatively connected to POS <NUM> via the LAN, which may include devices <NUM>, as described above. Moreover, in this example, controller <NUM> is also operatively connected to WAN <NUM> indirectly via POS <NUM> but may alternatively be connected directly, as explained above. In the depicted example, and for purposes of the ensuing explanation, host <NUM> is a server of a host processing system associated with a financial institution. Separation of controllers <NUM> and <NUM>, for example, allows for access control of components connected to the separate controllers. Thus, for example, there is no direct link between display <NUM> and PIN pad <NUM> without traversing controllers <NUM> and <NUM>, and therefore tampering with the PIN pad <NUM> via display <NUM> is difficult or impossible, depending on policies established for communicating between the display <NUM> and PIN pad <NUM> via controllers <NUM> and <NUM>. In some examples, as described further herein, controller <NUM> may not be needed, and display <NUM> can connect directly to controller <NUM>, which manages access to the various components. Controller <NUM> can be part of PIN pad <NUM>, in an example.

<FIG> is a diagrammatic representation of user interface <NUM> similar to <FIG> but additionally illustrating certain internal components of controllers <NUM> and <NUM>. Controller <NUM> includes a processor <NUM> operatively connected to secure memory <NUM>, a portion <NUM> of which may include encryption information. Processor <NUM> is operatively connected to printer <NUM> via a USB driver <NUM>, to soft keys <NUM> via a soft key driver <NUM>, and to display <NUM> via a display controller <NUM>. Controller <NUM> also includes an Ethernet adapter <NUM> operatively connected to processor <NUM> and configured to communicate with controller <NUM> and/or with devices external to fuel dispenser <NUM> (<FIG>), as explained in more detail below. Processor <NUM> may be operatively connected to any additional components <NUM> directly or indirectly via one or more drivers or communication ports. In the depicted example, additional components <NUM> include any component that is not configured to receive payment data, such as a cash or bill acceptor, a speaker, auxiliary displays in addition to display <NUM>, other input/output devices, etc..

Controller <NUM> includes a processor <NUM> operatively connected to secure memory <NUM>. In this example, secure memory <NUM> includes a portion <NUM> configured to store a security state, as well as a portion <NUM> configured to store encryption information. Processor <NUM> is configured to communicate with PIN pad <NUM> via a PIN pad driver <NUM>, to card reader <NUM> via a card reader driver <NUM>, and to contactless card reader <NUM> via a contactless card reader driver <NUM>. Processor <NUM> may be operatively connected to a beeper <NUM>, as well as to any additional components <NUM>, the connection to which may be accomplished directly or indirectly via one or more drivers or communication ports. Drivers and ports configured to handle communication between a component and a controller should be understood in the art and are therefore not described in further detail. In this example, additional components <NUM> include any component capable of receiving payment data or other confidential information, such as a smart card reader.

Controller <NUM> also includes an Ethernet adapter <NUM> operatively connected to processor <NUM> and configured to communicate with Ethernet adapter <NUM>, as explained in more detail below. Ethernet adapter <NUM> can also effect connection between controller <NUM> and devices <NUM> in this example. Each of controllers <NUM> and <NUM>, in this example, includes a set of security sensors <NUM> and <NUM>, respectively, operatively connected to the processor of the respective controller. The function and operation of security sensors <NUM> and <NUM> are explained in more detail below.

Each of processors <NUM> and <NUM> may be a processor, microprocessor, controller, microcontroller, other appropriate circuitry, or any combination thereof. Each of memories <NUM> and <NUM> may be any suitable type of memory or computer-readable medium accessible by the respective processor. Examples of suitable types of memory include any type of random access memory (RAM), any type of read-only memory (ROM), or any other type of flash memory that may be used to carry or store computer program code in the form of computer-executable programs, instructions, or data. Each of processors <NUM> and <NUM> may also include a portion of memory accessible only to the respective processor, commonly referred to as "cache. " Thus, each memory may be part of the respective processor, may be separate, or may be split between the relevant processor and one or more separate memory devices.

Each of memories <NUM> and <NUM> includes computer-executable program code or instructions that, when executed by the respective processor, perform at least a portion of the processes and functions described in more detail below. The memory may also include one or more data structures for storing information, such as a database or a table. It is to be appreciated that such computer-executable program code or instructions in this scenario can include one or more application programs, other program modules, program data, firmware, drivers, and/or an operating system. In an example, portions <NUM> and <NUM> of respective memories <NUM> and <NUM> include one or more encryption algorithms, keys, and/or codes used to encrypt and decrypt information, as described in more detail below. One use of the encryption keys stored in the memories, for instance, is to allow controllers <NUM> and <NUM> to communicate securely with one another.

In one example, the encryption information that allows the controllers to securely communicate can be provided to the controllers and stored in portions <NUM> and <NUM> of memories <NUM> and <NUM> when the controllers are manufactured in order to ensure security. In other examples, the controllers <NUM> and <NUM> can negotiate the encryption information. In any case, controllers <NUM> and <NUM> exchange digital certificate and/or encryption information stored in respective portions <NUM> and <NUM> of memories <NUM> and <NUM> in order for controller <NUM> to authenticate controller <NUM> and authorize the communications between the two controllers described below. In one example, this may be accomplished through the use of a "clean room" where the controllers are mutually authenticated to one another in a secure environment, such as once manufacture has completed and prior to installation into fuel dispenser <NUM>. Encryption information provided by host <NUM> that allows controller <NUM> to encrypt sensitive payment data associated with the host and communicate therewith securely, as explained in more detail below, may also be stored in portion <NUM> of memory <NUM> at this point. It should be appreciated that hosts associated with other payment cards may also supply encryption information specific to the respective host to controller <NUM> to be stored in portion <NUM> of memory <NUM> at the same time. As should be understood in the art, each encryption scheme allows controller <NUM> to encrypt sensitive payment data to be transmitted to the host associated with the scheme, where only the specific host is able to decrypt the sensitive payment data for processing based on the scheme.

As noted above, each of controllers <NUM> and <NUM> includes respective security sensors <NUM> and <NUM>. These security sensors operate to either erase the information contained in the corresponding processor and secure memory of the respective controller or otherwise decommission one or both of the controllers when triggered. For instance, the security sensors may be physical microswitches, as explained in more detail below with respect to <FIG> and <FIG>, that cause the respective processor to erase the contents of the memory associated with the processor when the relevant microswitch has been triggered. In an example, each of processors <NUM> and <NUM> is a secure microcontroller (e.g., a <NUM>-bit microcontroller), such as a Universal Secure Integrated Platform (USIP) chip provided by Maxim Integrated Products of Austin, Texas. Additional information regarding anti-tampering security sensors configured to erase any information contained in a corresponding controller, processor, and/or secure memory may be found in the <NUM>/<NUM>,<NUM> application referenced above.

<FIG> is a diagrammatic side elevation view of PIN pad <NUM> and controller <NUM> in accordance with one example. As should be understood in the art, PIN pad <NUM> includes a plurality of keys <NUM> affixed to a PCB <NUM>. PCB <NUM> can be equipped with one or more tampering detection mechanisms, such as a mesh layer <NUM>. Controller <NUM> also includes a PCB <NUM>, which includes a mesh layer <NUM> configured to detect tampering similar to mesh layer <NUM>. An example of a mesh layer suitable for use as mesh layers <NUM> and <NUM> may be found in the <NUM>/<NUM>,<NUM> application referenced above.

For example, security sensors <NUM> (<FIG>) can include a pair of physical microswitches <NUM>, as described above, that are operatively connected to processor <NUM> and located so as to come into contact with PCB <NUM>. In another example, microswitches <NUM> are attached directly to processor <NUM> rather than to PCB <NUM>. Separation of PCB <NUM> from PCB <NUM> activates one or more of microswitches <NUM>, which transmits a signal to processor <NUM>. In one example, the signal can decommission controller <NUM> or otherwise render the controller inoperable. In another example, the signal causes processor <NUM> to erase any data within controller <NUM> necessary to ascertain any payment data stored by the controller, such as the encryption information stored within portion <NUM> of memory <NUM> or the payment data itself, when one or more microswitches are triggered. In this example, payment data within controller <NUM> cannot be ascertained should PCBs <NUM> and <NUM> become separated or if microswitches <NUM> are otherwise triggered.

Controller <NUM> communicates with controller <NUM> via Ethernet adapter <NUM> as denoted by arrow <NUM>. Arrow <NUM> denotes the communication path(s) by which controller <NUM> communicates with card reader <NUM>, contactless card reader <NUM>, and additional components <NUM>.

Controller <NUM> may also be physically connected to controller <NUM>, which may be accomplished in a manner similar to that described in the <NUM>/<NUM>,<NUM> application referenced above. Referring to <FIG>, for example, controller <NUM> is located adjacent to controller <NUM>, both of which are affixed to a housing or a frame <NUM>. In this example, display controller <NUM> is an external graphics board connected to controller <NUM> and display <NUM>, as explained in more detail in the <NUM>/<NUM>,<NUM> application. Arrow <NUM> denotes the communication paths by which controller <NUM> communicates with printer <NUM>, soft keys <NUM>, and additional components <NUM>. In an example, user interface <NUM> includes microswitches <NUM>, <NUM>, <NUM>, and <NUM>. Microswitch <NUM> activates should controller <NUM> and housing <NUM> become separated, while microswitch <NUM> activates should controller <NUM> and display controller <NUM> become separated. Similarly, microswitch <NUM> activates should keys <NUM> become separated from either of controllers <NUM> and <NUM>, while microswitch <NUM> activates should controller <NUM> become separated from controller <NUM>.

It is to be appreciated that these microswitches may be operatively connected to either or both sets <NUM> and <NUM> of security sensors of controllers <NUM> and <NUM>, respectively, to allow either or both controllers to determine when a microswitch has been activated. In one example, for instance, sets <NUM> and <NUM> of security sensors are routed to special inputs inside the respective secure processor <NUM> or <NUM>. The secure processors include logic to determine when a security sensor has been activated and are connected to a battery back-up to continue operating if the respective processor is disconnected from its main power supply. When a controller receives an indication that one of the microswitches has been triggered, the controller can be decommissioned and can become inoperable, as described above. Either or both controllers can remain in an inoperable state until resolved by an authorized technician. As a result, the entire user interface <NUM> can be decommissioned and inoperable until examined by the technician. In another example, when a controller receives an indication that one of the microswitches has been triggered, the controller's processor can erase the entirety of the controller's secure memory or the portion thereof containing decryption keys or other access criteria to prevent unauthorized access to any data stored in the memory.

While <FIG> illustrates the use of microswitches <NUM>, <NUM>, <NUM>, and <NUM>, it is to be appreciated that additional or alternative microswitches, as well as other configurations and arrangements of microswitches, may be employed by user interface <NUM> to detect tampering without departing from the scope of the subject matter as described.

The following description provides a specific example of fuel dispenser <NUM> and user interface <NUM> with reference to <FIG>. Processor <NUM> of a fuel dispenser <NUM> (e.g., fuel dispenser 200a or 200b) retrieves display data from secure memory <NUM> to present to the user via display <NUM> and transmits the data to controller <NUM> with an instruction to display the data. In this example, the display data may include instructions related to initiating the fueling process (e.g., text that instructs to swipe a debit or credit card or to prepay from within central facility <NUM>). Controller <NUM> can operate user interface <NUM> in a secure state based on initiation of the fuel process, as controller <NUM> may receive payment data. Controller <NUM> may determine when to place user interface <NUM> in a secure state depending on the current stage of the fueling process or upon an action or event triggered by the user, such as providing a magnetic stripe card to card reader <NUM> (e.g., in response to the instructions presented via display <NUM>), activating a PIN pad <NUM> for entry of a PIN or billing zip code associated with a scanned card), etc., for example. Processor <NUM> stores data in portion <NUM> of secure memory <NUM> indicating that user interface <NUM> has been placed in a secure state.

Information received by the components operatively connected to controller <NUM>, including payment data, is transmitted by the respective component to processor <NUM>. If user interface <NUM> is not in a secure state as indicated by security state <NUM> when the payment data is received, processor <NUM> can place the user interface in a secure state (e.g., as described above) based in part on identifying the security state <NUM>. Processor <NUM> processes the payment data as defined by the computer instructions stored in secure memory <NUM>. For instance, processor <NUM> may encrypt the sensitive payment data using the encryption information provided by host <NUM> stored in portion <NUM> of secure memory <NUM>. Processor <NUM> may also encrypt the non-sensitive payment data (that is incapable of identifying the account of the payment card) using the encryption information stored in memory portion <NUM> common to controllers <NUM> and <NUM>, in an example. Processor <NUM> transmits the encrypted data to controller <NUM> via Ethernet adapter <NUM> using TCP/IP.

Controller <NUM> receives the encrypted information via Ethernet adapter <NUM> and handles transmission of the information, which may include, for instance, forwarding the information in its entirety to POS <NUM>, site controller <NUM>, another device within fueling environment <NUM>, and/or host <NUM>. In another example, controller <NUM> may transmit different portions of the information to some or all of these devices so that the respective device may process the portions of information it receives. This may be accomplished based on instructions received by controller <NUM> from controller <NUM> or may be defined by computer instructions stored within secure memory <NUM>.

In the present example, processor <NUM> receives an indication that fuel dispenser <NUM> is authorized to dispense fuel, which may be provided by POS <NUM>, site controller <NUM>, host <NUM>, or controller <NUM> depending on the configuration of fueling environment <NUM>. As a result, processor <NUM> instructs valve <NUM> to open to allow fuel to flow to hose <NUM>, nozzle <NUM>, and the user's vehicle. While in the secure state, processor <NUM> may retrieve additional display data from memory <NUM> and transmit it to controller <NUM> with an instruction to provide the data to display <NUM> (e.g., for presenting to a user).

At any point during the fueling process, controller <NUM> may instruct controller <NUM> to present information unrelated to the fueling process via display <NUM>, such as advertisements. Based on the instruction, a period of time elapsed since securing user interface <NUM>, an indication from another component, etc., controller <NUM> can place user interface <NUM> in a non-secure state and store an indication of such in security state <NUM> of secure memory <NUM>. The material to be presented may be stored in secure memory <NUM> or <NUM> or may be transmitted to controller <NUM> by a resource external to fuel dispenser <NUM>, such as POS <NUM>, site controller <NUM>, host <NUM>, or another resource operatively connected to WAN <NUM>. Alternatively, information to display may be supplied to controller <NUM> from another external source via auxiliary video input <NUM>. It should thus be appreciated that controller <NUM> can be configured to drive controller <NUM> as to the material presented to the user via display <NUM>. For instance, controller <NUM> determines when controller <NUM> may present material from another source, such as auxiliary video input <NUM>, depending on the security state <NUM> of controller <NUM>. Controller <NUM> is configured to handle presentation of the material to the user via display <NUM> based on the instructions from controller <NUM>.

In one example, other devices, such as controller <NUM>, additional components <NUM>, auxiliary input <NUM>, or POS <NUM>, may request presentation of information to the user via display <NUM>. In such an example, controller <NUM> may be configured to request authorization from controller <NUM> to display the information. Upon receipt of the request from controller <NUM>, processor <NUM> identifies the current security state as stored in portion <NUM> of secure memory <NUM>. If controller <NUM> is in a secure state, processor <NUM> then determines whether controller <NUM> has requested or received any payment data from the user that has not been processed by controller <NUM> or transmitted to controller <NUM>. If so, processor <NUM> does not change the security state and denies or caches the request. If controller <NUM> is in a secure state but has processed and transmitted any payment data it received, processor <NUM> may then place user interface <NUM> in a non-secure state by storing the appropriate indication in security state <NUM> and authorizing the request. If user interface <NUM> is in a non-secure state, controller <NUM> may authorize controller <NUM> to present the requested information. An example of a process for determining whether to display the requested information is set forth in the <NUM>/<NUM>,<NUM> application referenced above and may be accomplished via any suitable configuration, such as that described in the <NUM>/<NUM>,<NUM> application referenced above.

In one example, when controller <NUM> is in a non-secure state, it may disable the devices operatively connected to the controller that are configured to receive information from the user, such as described in the <NUM>/<NUM>,<NUM> application, for instance. The devices can include PIN pad <NUM>, card reader <NUM>, etc. Other devices that accept input from the user but are incapable of receiving payment data, such as soft keys <NUM>, may remain enabled. This prevents any unauthorized material from using user interface <NUM> to elicit payment data from the user. In this regard, controller <NUM> is referred to herein as a secure controller <NUM>.

Should controller <NUM> determine to present material or information via display <NUM>, the controller <NUM> can transmit a service message to controller <NUM> that preempts any non-secure material currently being presented. Controller <NUM> can place user interface <NUM> in a secure state by storing an indication of such within security state <NUM>, which controller <NUM> may do at the time it transmits the service message to controller <NUM>, after receiving confirmation from controller <NUM> that the service message has been received and/or executed, etc. Controller <NUM> may then transmit the material to be presented along with the service message (e.g., once the controller has received confirmation from controller <NUM> that the message was received and/or acted upon). It is to be appreciated that controller <NUM> is configured so that tampering with the computer instructions executed by the processor is not allowed. As a result, controller <NUM> is configured to receive the service message from controller <NUM> and process accordingly. For example, controller <NUM> can prevent non-secure material or material that has not been provided by controller <NUM> from being displayed once controller <NUM> receives the service message from controller <NUM>. Thus, it is to be appreciated that the configuration described above provides an example of a user interface where secure prompting or other material provided by one controller preempts prompting or material from the other controller or received from another source.

Once the fueling process has completed, controller <NUM> performs any ancillary tasks, which may include transmitting the final amount of the dispensed fuel to controller <NUM>, POS <NUM>, site controller <NUM>, host <NUM>, or another device for processing. This may also include instructing display <NUM> to present additional text to the user and/or instructing printer <NUM> to print a receipt for the transaction, as should be known in the art, based on instructions provided by controller <NUM>, POS <NUM>, site controller <NUM>, host <NUM>, and/or any other device, depending on the configuration of fueling environment <NUM>.

It is to be appreciated that the above provides a description of a user interface for a retail device that includes two controllers. The first controller is configured to manage operation of the retail device and is operatively connected to components that are not configured to receive payment data or other sensitive information. The second controller is configured to handle receipt of payment data and is operatively connected to any component of the retail device capable of receiving payment data, such as a PIN pad and/or card reader. Thus, payment data received by the retail device can be confined to processing by the second controller. As a result, controller <NUM> and portions of controller <NUM> are included within a security zone as denoted by dashed area <NUM> that can securely handles payment data received via the user interface <NUM>.

The second controller also determines and stores an indication of the security state of the user interface and instructs the first controller what to display depending on the security state. For instance, the second controller instructs the first controller what material to display or what source to receive material to display and when to display it. Thus, in at least one example, any prompt or information displayed to the user can be provided and/or authorized by the second, secure controller. As described further herein, the secure controller can control access of other controllers or devices to one or more components, and/or can be secure by anti-tampering hardware mechanisms. The second controller may also be configured to enable and disable the input devices of the user interface based on the security state.

The two controllers can be configured to communicate securely via Ethernet adapters using TCP/IP pursuant to encryption information stored in the respective secure memory of each controller. Each controller also includes security sensors configured to decommission the user interface and/or erase any payment data stored by the controller if the sensors detect that the controller has been tampered with.

It should be appreciated, however, that while portions of controller <NUM> are illustrated as being within security zone <NUM>, controller <NUM> may not be required to satisfy heightened security measurements and certifications for devices that handle sensitive payment data in an unencrypted format because the controller does not handle such data. That is, controller <NUM> may be unable to decrypt any sensitive payment data it receives from controller <NUM>. In this example, secure memory <NUM> does not include any encryption information that would allow controller <NUM> to decrypt any sensitive payment data received from controller <NUM>. Controller <NUM> is instead configured to route the sensitive payment data received from controller <NUM> to the device configured to handle processing of the data.

In one example, controller <NUM> stores one set of encryption information in portion <NUM> of secure memory <NUM> that allows controllers <NUM> and <NUM> to communicate securely and another set of encryption information that allows controller <NUM> to securely encrypt payment data, or other sensitive information, received by controller <NUM>, such as the host encryption scheme described above. As a result, devices configured to handle processing of the payment data, or other sensitive information, are able to decrypt the payment data, which does not include controller <NUM> and may include host <NUM> in certain examples. That is, the encryption information stored in portion <NUM> of secure memory <NUM> may be sufficient to allow controllers <NUM> and <NUM> to communicate securely but may be insufficient to allow controller <NUM> to decrypt any sensitive payment data received by controller <NUM>.

In another example, controller <NUM> is operatively connected to the device within fueling environment <NUM> that is configured to effect payment transactions or communicates directly with host <NUM>. In such examples, controller <NUM> handles the receipt of the payment data, or other sensitive information, received by the components operatively connected to the controller <NUM>. In this example, controller <NUM> also processes, encrypts, and transmits the payment data to the device configured to effect payment transactions directly rather than indirectly via controller <NUM>. As a result, controller <NUM> does not receive any payment data, or other sensitive information. Controllers <NUM> and <NUM> continue to communicate via Ethernet adapters <NUM> and <NUM> so that, for instance, controller <NUM> provides controller <NUM> with an amount of information sufficient to print a receipt for a fueling transaction, as described above. Additionally, controller <NUM> continues to instruct controller <NUM> what information may be presented via display <NUM>, or, alternatively, controller <NUM> continues to request authorization from controller <NUM> as to whether information may be presented.

It should be appreciated that the configuration described above allows controller <NUM> to execute applications that are otherwise non-secure and to provide the applications with access to display <NUM>, depending on the security state as determined by controller <NUM>, without having access to any internal components of controller <NUM>. It should also be appreciated that such a configuration allows changes to the design of controller <NUM> and/or display <NUM>, which may not be subject to heightened security standards since those components do not handle any unencrypted sensitive payment data, without subjecting the portions of user interface <NUM> that do handle such data to recertification. Referring specifically to <FIG>, for example, the combination of controller <NUM>, external graphics controller <NUM>, and display <NUM> may be replaced or redesigned, such as to increase the size of the display, without recertification since these components do not handle unencrypted sensitive payment information. It is to be appreciated that this allows replacement of these components without subjecting controller <NUM>, which is configured to handle unencrypted sensitive payment information, to recertification.

In another example, display <NUM> is operatively connected to controller <NUM> rather than controller <NUM>. As a result, controller <NUM> determines what information may be presented via display <NUM> depending on security state <NUM> in a manner similar to that explained above. Processor <NUM> may use the process described in the <NUM>/<NUM>,<NUM> application referenced above to determine whether to present information via display <NUM>, which may be accomplished via the configuration described in the <NUM>/<NUM>,<NUM> application referenced above. In such examples, controller <NUM> may continue to request presentation of non-secure material to the user via the display in a manner similar to that described above. It should be appreciated that display <NUM> may also be operatively connected to controller <NUM> rather than controller <NUM> (e.g., when the display is capable of receiving payment data, such as in the case of a touchscreen).

In this example, display <NUM> can be equipped to present PIN pad <NUM> as a virtual PED on the display <NUM> (in which case a hardwired PIN pad <NUM> may not be present in the fuel dispenser <NUM>). Moreover, in this example, controller <NUM> can operate the display <NUM>, and controller <NUM> can be omitted (and/or replaced by a display controller <NUM>), as described in more detail below. In this example, various possibilities are described in connection with securing controller <NUM> and/or sensitive communications to/from display <NUM>. In one example, the touchscreen can be limited by controller <NUM> (e.g., in a number of touchable regions, in displaying information only in certain regions, etc.) when used by non-secure applications, and less limited when used by secure applications. Examples of limiting touchscreen displays is described in the <NUM>/<NUM>,<NUM> application referenced above. Moreover, display <NUM> can limit touchable areas by excluding certain regions where some information is displayed, such as fuel dispensing amount, transaction amount, etc., to ensure this data is not modified.

<FIG> illustrate examples where controller <NUM> is omitted. Instead, the housing of PIN pad <NUM> can include the controller <NUM>, which is used to control a "dumb" display. In this example, the dumb display may house display controller <NUM>.

Referring now to <FIG>, a tamper-proof interface system <NUM> is illustrated including a display <NUM> and a PIN pad <NUM> that are physically separated from each other but communicatively coupled via a wired or wireless connection. In one example, display <NUM> and PIN pad <NUM> are coupled via a flexible circuit assembly. In this regard, display <NUM> can have a PCB physically separated from a PCB of PIN pad <NUM>. Controller <NUM> may be included on the PCB housed in PIN pad <NUM> and can directly control display controller <NUM> that is in the housing of display <NUM>. In this example, controller <NUM> is not present on the PCB of PIN pad <NUM> or of display <NUM>. Accordingly, in this example, secure operations (e.g., processing of payment or other sensitive information) occur on the PCB of PIN pad <NUM>, while standard display operations can occur in display <NUM>. In any case, secure controller <NUM> can accordingly operate the PIN pad <NUM> and display <NUM>, and can thus control data provided to/from display <NUM> to provide security for data from PIN pad <NUM>. As such, display <NUM> can be a standard or "dumb" display and can be easily replaced or upgraded without having to also replace or recertify PIN pad <NUM>. In addition, controller <NUM> controls communications to/from display <NUM> (e.g., via a software or firmware drivers), which can prevent tampering with PIN pad <NUM> via a communication path of display <NUM>.

According to one example, flexible circuit assembly <NUM> may take the form of a tamper-proof cable such as that described in <CIT>. In this example, flexible circuit assembly <NUM> includes two or more layers and is in electrical communication with a secure area in PIN pad <NUM>. Each of these layers can include a thin, flexible dielectric substrate having conductors thereon. The signal conductors can be surrounded with a conductor pattern defining a wire mesh. Thus, if access is attempted via the signal conductors, such as by separating the layers, the wire mesh is interrupted, which can trigger an event. For example, as described, such events can include causing erasure of certain information (e.g., encryption information, payment or other sensitive information, etc.), decommissioning of controller <NUM>, PIN pad <NUM>, display <NUM>, etc., and/or the like. In an example, a suitable adhesive is used to connect these various layers together to form the mesh.

When assembled, these layers define a cable extending between a first connector portion and a second connector portion. One end of flexible circuit assembly <NUM> can connect to display <NUM> via the first connector portion, and another end of flexible circuit assembly <NUM> can connect to PIN pad <NUM> via the second connector portion. The first and second connector portions may take the form of any secure connector device, such as connector portion <NUM> discussed in <CIT>. The first and second connector portions are preferably connected to display <NUM> and PIN pad <NUM>, respectively, using a suitable adhesive, such as the conductive adhesive described in <CIT>.

As noted above, the cable includes internal conductors that directly connect and allow electronic communications between controller <NUM> of the printed circuit board within PIN pad <NUM> and display controller <NUM> of the printed circuit board within display <NUM>. This allows PIN pad <NUM> to send data, such as display data, securely to display <NUM> within tamper-proof flexible circuit assembly <NUM>.

Because of the flexibility of flexible circuit assembly <NUM>, it will be appreciated that display <NUM> can be hingedly-moved relative to PIN pad <NUM> while being electrically connected to PIN pad <NUM>. Additionally, the flexible circuit assembly <NUM> allows display <NUM> to be mounted at a physical location on the fuel dispenser separate from the mounting location of PIN pad <NUM>.

In an example, flexible circuit assembly <NUM> can be a ribbon-cable or similar cable that couples components for communication therebetween. In one example, flexible circuit assembly <NUM> can include multiple cables, where at least one cable carriers video data, and the other cable is used for security detection. In one example, one cable facilitates communicating display data between PIN pad <NUM> and display <NUM> and has security mesh layers, as described, triggering an event if tampering is detected. This cable can additionally include a switch circuit at least at one connector of the cable that utilizes a ground connection at the component to detect removal of the cable, which can trigger an event (e.g., memory erasure, component decommissioning, etc.). In this example, another cable can provide the security mesh circuit series-connected with two dome switches (or other suitable switches to detect separation or movement of one or more components), and can be bonded or otherwise mounted to the other cable and/or can loop such that a dome switch is used to determine if a bracket over a connector of the other cable is disassembled, which can trigger an event. This cable can continue to another dome switch between display <NUM> and a bezel, or other portion of a fuel dispenser, to determine if display <NUM> is removed therefrom; this can also trigger an event.

In any case, the triggered events can cause various functionalities, and triggering of different switches can cause different event functionalities, in an example. In addition, the functionalities can require different resolutions. For example, removal of display <NUM> from the bezel can cause decommissioning of the PIN pad <NUM> and/or display <NUM>, such that the display can be reinstalled to contact the bezel, and normal operation can resume. Removal of cable <NUM> from display <NUM>, however, can cause erasure of encryption information used to communicate between PIN pad <NUM> and display <NUM>. Reestablishing encryption information can require a technician to replace the display <NUM> in the bezel, reinitialize encryption information between a new display <NUM> and PIN pad <NUM> in a clean room for reinstallation in the fuel dispenser, and/or the like. It is to be appreciated that various triggerable events can be used in this regard with varying remedial measures to reset the events.

<FIG> illustrates a fuel dispensing system <NUM> using two interface systems <NUM> of <FIG>. Fuel dispensing system <NUM> includes a fuel dispenser <NUM>, one or more interface systems <NUM>, LAN <NUM>, POS <NUM> and card reader or contactless payment system <NUM>. As discussed above with regard to <FIG> and <FIG>, fuel dispenser <NUM> operates to dispense fuel and includes interface systems <NUM> to facilitate payments from the user and to display fueling status. Card reader or contactless payment system <NUM> may work in concert with each respective interface system <NUM> to effect payment fuel dispensed at fuel dispenser <NUM>. Each interface system <NUM> includes flexible circuit assembly <NUM> to provide tamper-proof communications between display <NUM> and PIN pad <NUM>, as discussed above with regard to <FIG>. As such, when a user intends to dispense fuel, the user provides an indication that the user wishes to provide payment information, such as a credit card, at fuel dispenser <NUM>. Controller <NUM> of PIN pad <NUM> then provides prompts or other video directly to display controller <NUM> in display <NUM>, which in turn displays the prompts or other video on display <NUM>. In response to prompts on display <NUM>, the user provides payment data via card reader or contactless payment system <NUM>. Upon successful authentication of the payment data, the fuel may be dispensed by the user. In addition to facilitating the initial payment information, controller <NUM> may provide other video information directly to controller <NUM> of display <NUM>, such as fueling status or other payment information. As such, display <NUM> simply displays the video data sent by controller <NUM> of PIN pad <NUM> without encryption of the video data. In this regard, because the data is provided from the PIN pad <NUM> securely to display <NUM> via flexible circuit assembly <NUM>, the display is "dumb" and simply displays the video data provided via secure flexible circuit assembly <NUM>.

<FIG> illustrates another fuel dispensing system <NUM> which also uses two interface systems <NUM> of <FIG>, but additionally provides for video services from a host <NUM> of other external feature source. Fuel dispensing system <NUM> includes a fuel dispenser <NUM>, two interface systems <NUM>, LAN <NUM>, POS <NUM>, WAN <NUM> and host <NUM>. Fuel dispensing system <NUM> allows for similar fueling operation as described above for <FIG>. Additionally, host <NUM> may provide video, such as advertisements, on display <NUM> via WAN <NUM>, POS <NUM>, LAN <NUM> and fuel dispenser <NUM>. Secure communications between the fuel dispenser <NUM> and display <NUM> can be beneficial in this example, as a third party can provide the video feed on display <NUM>.

As mentioned above, flexible circuit assembly <NUM> provides secure, tamper-proof communications between display <NUM> and PIN pad <NUM>. To communicate data securely between fuel dispenser <NUM> (e.g., the internal electronics or fuel dispensing components of fuel dispenser <NUM>) and PIN pad <NUM>, an additional cable <NUM> is provided between fuel dispenser <NUM> and PIN pad <NUM>. Cable <NUM> may be any suitable type of cable, such as a standard cable or a cable assembly similar to flexible circuit assembly <NUM>. The cable can include an Ethernet cable, USB cable, and/or the like.

Given the above, host <NUM> is able to send video data through WAN <NUM>, POS <NUM>, and LAN <NUM> to reach feature electronics <NUM> in fuel dispenser <NUM>. It is noted that host <NUM> may be an entity that is separate from the owner of the fuel dispensing system. Thus, a third party may be allowed to display video or images on display <NUM> in a secure fashion. A discussion of how the video or images are routed securely from host <NUM> to display <NUM> using controller <NUM> (but not controller <NUM>) is provided below.

Feature electronics <NUM> may include a processing system which controls handling of data to and from fuel dispenser <NUM> as well as other electronic operations of fuel dispenser <NUM>, as discussed in <CIT>. In this regard, feature electronics <NUM> transmit the video data received from host <NUM> via cable <NUM> to controller <NUM> of PIN pad <NUM>. Controller <NUM> of PIN pad <NUM> forwards the video data to display controller <NUM> of display <NUM> via flexible circuit assembly <NUM>. If flexible circuit assembly <NUM> detects tampering therewith, as described, the processor of controller <NUM> at PIN pad <NUM> triggers an event, which can include erasing the memory associated therewith, decommissioning one or more components to prevent the video data to be displayed on display <NUM>, etc. As such, controller <NUM> is omitted in the example illustrated in <FIG>, but it is to be appreciated that this controller can be present to receive video data from controller <NUM> for presenting on display <NUM>, for example (e.g., as a display controller <NUM>).

PIN pad <NUM> includes controller <NUM> and communications between PIN pad <NUM> and "dumb" display <NUM> is secure over flexible circuit assembly <NUM>. Display <NUM> can include a display controller <NUM>, as described, for displaying received video data. Additionally, communications between PIN pad <NUM> and feature electronics <NUM> in fuel dispenser <NUM> may also be secure so that the complete path from feature electronics to display is secure. This can be implemented by similarly using another controller or PCB at feature electronics <NUM> and/or implementing one or more security policies for communicating with PIN pad <NUM> or related controller. In addition, for example, PIN pad <NUM> (or secure controller <NUM> for example) can deactivate a connector of PIN pad <NUM> to which flexible circuit assembly <NUM> connects when the PIN pad <NUM> is activated to mitigate tampering with PIN pad <NUM> via the flexible circuit assembly <NUM>. When the PIN pad <NUM> is no longer user or is otherwise deactivated, PIN pad <NUM> (or secure controller <NUM>) can enable the connector to allow data from feature electronics <NUM> to pass over flexible circuit assembly <NUM>.

<FIG> illustrates an example system <NUM> for employing in a fuel dispenser to allow touchscreen input. System <NUM> is employed by a user interface, such as user interface <NUM>. System <NUM> includes a touch display <NUM> that is utilized by an auxiliary feature processor (AFP) <NUM> via a non-secured touch controller <NUM> or a PED <NUM>. For example, touch display <NUM> can be similar to display <NUM>, AFP <NUM> can be similar to or can include the feature electronics <NUM> described above, and/or PED <NUM> can be similar to PIN pad <NUM> (e.g., and can include a controller <NUM> to secure access to touch display <NUM>). Thus, AFP <NUM> Provides data from one or more applications to touch display <NUM> via PED <NUM>, as similarly described in <FIG>, and includes the non-secured touch controller <NUM> to receive touch coordinates or other input events from touch display <NUM>.

Implementing touchscreen functionality on touch display <NUM> can introduce additional entry points for obtaining sensitive information from a customer using the touch display <NUM>. In this regard, additional physical or virtual security measures can be used to mitigate tampering with the touch display <NUM> by non-authenticated entities. AFP <NUM> includes a SoM <NUM> that is used to authenticate applications for accessing touch display <NUM> via PED <NUM>, and a secure chip <NUM> for providing security information to SoM <NUM> for establishing a secure channel to PED <NUM>. In this regard, AFP <NUM> implements a secure area defined by the SoM <NUM> that allows secure access to touch display <NUM>. Furthermore, in this or other examples, SoM <NUM> and secure chip <NUM> are encased in an anti-tampering shell <NUM> to prevent physical access thereof. In addition, for example, the AFP <NUM> can be installed on a hub interface PCB (HIP), which can include two AFPs (e.g., one on each side) for a dual sided fuel dispenser.

SoM <NUM> establishes a secure channel with PED <NUM> for facilitating access of touch display902 via PED <NUM>. SoM <NUM> obtains secrets, encryption keys, or other security information from secure chip <NUM> for establishing the secure channel with PED <NUM>. Secure chip <NUM> and SoM <NUM> are separate components, which can allow SoM <NUM> to be an off-the-shelf product. Secure chip <NUM> is paired with SoM <NUM> based on an identification parameter of the SoM <NUM> (e.g., a media access control (MAC) or similar address) to prevent future replacement of the SoM <NUM> without commissioning thereof for use with secure chip <NUM>. The secure chip <NUM> and SoM <NUM> can be paired in a secure room by an authenticated entity (e.g., an entity that configures the security information between the secure chip <NUM> and the PED <NUM>, such as a fuel dispenser manufacturer), or otherwise paired upon installation within a related fuel dispenser and/or initialization of the secure chip <NUM> and/or SoM <NUM>. The secure chip <NUM> can be initialized with security information related to PED <NUM> (e.g., in a secure room, upon installation and/or initialization, etc.).

In any case, SoM <NUM> obtains the security information from secure chip <NUM> for establishing the secure channel with PED <NUM>. It is to be appreciated that secure chip <NUM> confirms the identification parameter (e.g., MAC address) of SoM <NUM> before providing the information. SoM <NUM> and PED <NUM> accordingly establish the secure channel, which can include communicating context information based on the security information for subsequent communications therebetween, or communicating the security information in each subsequent communication. In one example, PED <NUM> can download a trusted application to SoM <NUM> for subsequently verifying content signatures and/or a list of authenticated signatures to allow the SoM <NUM> to validate signatures of applications for providing access to touch display <NUM>, as described below.

PED <NUM> employs a secure controller for the display <NUM> (such as secure controller <NUM>, or a related firmware or software driver), and generally allows data received from SoM <NUM> over the secure channel to pass to touch display <NUM> over a connector (similar to the connector described above). It is to be appreciated, however, that PED <NUM> can disable the connector (e.g., using a secure controller, such as controller <NUM>) while PED <NUM> is activated to receive sensitive information from a customer, as described. In this regard, PED <NUM> can authenticate other components, such as SoM <NUM>, for accessing touch display <NUM>.

In this regard, SoM <NUM> can be considered a trusted device at the PED <NUM> when the secure channel is established with PED <NUM>. SoM <NUM> thus manages which applications receive access to touch display <NUM> by verifying whether the applications are signed by a trusted or otherwise authenticated entity. SoM <NUM> can evaluates a signature of one or more applications executing on AFP <NUM> in determining whether to allow the application to access touch display <NUM>. SoM <NUM> can store a list of signatures for trusted or authenticated entities, to which SoM <NUM> can compare a signature of one or more applications. For example, the list can be programmed in the SoM <NUM>, received from PED <NUM>, etc. In an example, an operator of a retail site where a related fuel dispenser is deployed can be charged with verifying a signature or identity of an application, and allowing the application with a signature related to the site operator (or specific site) to access touch display <NUM> via SoM <NUM>. In this example, SoM <NUM> can include a signature of the retail site for comparing to signatures of applications executing via AFP <NUM>. Thus, where the retail site signs the application, SoM <NUM> can allow the application to access touch display <NUM>.

Thus, SoM <NUM> Provides data to touch display <NUM> via PED <NUM> for given authenticated applications. In one example, SoM <NUM> can provide varying levels of access for different signatures, such as full access to touch display <NUM> for applications signed by a manufacturer of the fuel dispenser, more limitedaccess to touch display <NUM> for applications signed by a merchant (e.g., a limited number of touch regions), and/or the like using the driver. In any case, SoM <NUM> manages the levels of access to ensure certain applications are allowed only certain functions based on the associated signature.

Appropriately signed applications executing on AFP <NUM> can access touch display <NUM> via SoM <NUM>, and can implement functions based on captured touchscreen input events on the touch display <NUM>. An application can display data on touch display <NUM> via SoM <NUM>, and non-secured touch controller <NUM> can capture interactions on the touch display <NUM>, such as coordinates of a touch, coordinates or other data regarding a swipe or other interactive movement with the touch display <NUM>, etc. Non-secured touch controller <NUM> provides information regarding such coordinates or movement data to SoM <NUM> (e.g., via AFP <NUM>) for processing by the application, and SoM <NUM> can process the touch events via a software driver for providing related data to the application (e.g., touch coordinates, a region associated with the touch coordinates, or other movement data).

In this or alternative examples, additional hardware tampering mechanisms can be present, as described, such as anti-tampering shell <NUM>, mesh layered cabling, microswitches, etc. In one example, SoM <NUM> and secure chip <NUM> are encased in an anti-tampering shell <NUM>, which can be a cap displaced over the SoM <NUM> and secure chip <NUM> such that movement or removal of the cap, tampering with the components therein, etc. can be detected and reported. For example, the anti-tampering shell <NUM> can have mesh layers or other mechanisms to detect removal or movement of the shell <NUM> or contents thereof. The anti-tampering shell <NUM> can be coupled to a processor (e.g., AFP <NUM>, SoM <NUM>, secure chip <NUM>, etc.) or other devices, as described, to report detected tampering. The shell <NUM> can be composed of plastic, ceramic, or other suitable materials to prevent accessing contents thereof. In one example, the shell <NUM> can be or can include a Bourns cap. In addition, SoM <NUM> and/or secure chip <NUM> can be installed on a PCB with mesh layers disposed between or otherwise nearby to detect a cavity where the SoM <NUM> or secure chip <NUM> is partially or entirely removed. In any case, such detections can trigger one or more events to secure chip <NUM>, SoM <NUM>, AFP <NUM>, or other components, to erase memory, decommission components, etc..

In addition, as described above, PED <NUM> can use a mesh layered cable for communicating data from AFP <NUM> (and SoM <NUM>) to touch display <NUM>. The cable can additionally or alternatively have microswitches to detect removal from touch display <NUM> and/or PED <NUM>, as described above. Detection by the mesh layers, microswitches, etc., can trigger one or more events, as described. In addition, a battery back-up can be used to power certain portions of system <NUM>, such as anti-tampering shell <NUM>, one or more processors (e.g., SoM <NUM>, AFP <NUM>, etc.), or other tampering detection mechanisms to allow tamper detection and subsequent event processing (e.g., memory erasure, device decommissioning, etc.), in the event of power outage.

It is to be appreciated that AFP <NUM> is implemented as SoM <NUM>, coupled to secure chip <NUM> and able to communicate with PED <NUM> and non-secured touch controller <NUM>, as described in various examples above. Moreover, in some examples, it is to be appreciated that non-secured touch controller <NUM>, in the depicted configuration, can be secured, as described below.

<FIG> illustrates another example system <NUM> for employing in a fuel dispenser to allow touchscreen input. System <NUM> implements full touchscreen functionality also allowing for entry of a PIN or other sensitive data via the touch display <NUM>. In this configuration, a PIN pad, such as PED <NUM>, may not be present, or may be utilized for other purposes. Moreover, in this configuration, additional physical or virtual security of various components can be used to mitigate tampering with the sensitive data. Touch display <NUM> can be utilized by an AFP <NUM> directly, via a secured touch controller <NUM>, and/or via an optional secure device <NUM> that can include the secured touch controller <NUM>. In this regard, multiple configurations for the secured touch controller <NUM> are possible, as depicted and described further herein.

Touch display <NUM> can be similar to touch display <NUM>, AFP <NUM> can be similar to AFP <NUM>, and secured touch controller <NUM> can be similar to non-secured touch controller <NUM> but is secured by one or more physical (anti-tampering) or virtual security measures. AFP <NUM> optionally includes a secure chip <NUM> that is configured to provide SoM <NUM> with secrets, encryption keys, or other security information for establishing a secure channel with optional secure device <NUM> (similarly to secure chip <NUM>). In this example, SoM <NUM> can authenticate applications executing on AFP <NUM> based on verifying a signature thereof, as described, and can accordingly manage access to touch display <NUM> based on the signature. Moreover, an anti-tampering shell <NUM>, similar to anti-tampering shell <NUM>, can encase the SoM <NUM>, optional secure chip <NUM>, and/or secured touch controller <NUM> to provide the secure anti-tampering module. In addition, for example, the AFP <NUM> can be installed on a hub interface PCB (HIP), which can include two AFPs (e.g., one on each side) for a dual sided fuel dispenser.

Secured touch controller <NUM>, as depicted in this example, can be installed on the AFP <NUM> under the anti-tampering shell <NUM>, or outside of the AFP <NUM>, in which case secured touch controller <NUM> can be within a secure device <NUM> or otherwise secured. In one example, secured touch controller <NUM> can be secured outside of secure device <NUM> (with secure device <NUM> absent or present in the installation), as described, by implementation of the secured touch controller <NUM> on an independent PCB. For example, such a PCB can include one or more security mechanisms (e.g., mesh layers, microswitches, etc.) associated with PCB and/or related cabling to touch display <NUM>, AFP <NUM>, secure device <NUM>, SoM <NUM>, or other components, to prevent tampering with the secured touch controller <NUM>. As described, secure device <NUM>, where present, can include components similar to a PIN pad <NUM> for providing a secure environment for secured touch controller <NUM>, for processing payment transactions, etc. In one example, secured touch controller <NUM> can be affixed to the touch display via a port thereon (which can be an anti-tampering port as described) to mitigate the need for a cable to interface between the secured touch controller <NUM> and touch display <NUM>.

In another installation, optional secure device <NUM> can include the secured touch controller <NUM>. In this example, secured touch controller <NUM> can be a "dumb" controller, as described with respect to display controller <NUM>, that is within a secure environment of secure device <NUM>. Secure device <NUM> can include components similar to PED <NUM> used to provide the secure anti-tampering environment (e.g., a secure controller <NUM>), while other components (e.g., keys of a PIN pad) can be absent from secure device <NUM> or used for other purposes. In one example, where the secure device <NUM> excludes keys or other external interface functions, secure device <NUM> can be installed within a fuel dispenser <NUM> without having to be installed on an external face thereof. It is to be appreciated that optional secure device <NUM> can be present and not include secured touch controller <NUM> as well, in one example (e.g., the secured touch controller <NUM> can be on an independent PCB or AFP <NUM> and providing access from secure device <NUM> to touch display <NUM>).

In yet another installation, secured touch controller <NUM> can be installed under the anti-tampering shell <NUM> of the AFP <NUM>. In an example, the secured touch controller <NUM> is still connected to touch display, and the associated cabling can run underneath or through the anti-tampering shell <NUM>. The foregoing installations provide a secure anti-tampering environment for the secured touch controller <NUM> to prevent tampering therewith. Additional security measures can be provided by a driver that operates and/or limits display functionality of the touch display <NUM>, as described previously. The driver can be implemented by the secure device <NUM> when present (e.g., in the security controller <NUM>), in the SoM <NUM>, etc., depending on the installation.

According to an example, when the virtual PED is not activated on touch display <NUM> for receiving a PIN or other confidential information, the touch display <NUM> can be limited (e.g., to a number of touch regions, preventing an application from generating a PIN pad in an attempt to acquire confidential information). To effectuate such measures, optional secure device <NUM>, where present, can operate a driver to accordingly control the display <NUM> as described above with respect to secure controller <NUM>. For example, secure device <NUM> can normally operate touch display <NUM> in the limited mode (e.g., with <NUM> touch regions to prevent providing a <NUM> digit PIN pad). When PIN entry is requested, secure device <NUM> can activate the virtual PED on touch display <NUM>, and/or accordingly prevent other requests to the touch display <NUM> until the virtual PED is no longer displayed (e.g., until PIN entry is complete, until an OK or Cancel region is pressed, until a period of time has expired, etc.). In one example, secure device <NUM> can deactivate a connector to which a cable from AFP <NUM> (or SoM <NUM>) is coupled to prevent applications executing on AFP <NUM> (or SoM <NUM>) from accessing the display until the PIN or other confidential information is retrieved.

PIN entry can be requested by one or more applications operating on AFP <NUM>, and SoM <NUM> can ensure the applications are signed by an appropriate entity before granting access thereto. As described, for example, SoM <NUM> can establish a secure channel with secure device <NUM> (e.g., similarly as SoM <NUM> to PED <NUM>), and thus can request rendering of the virtual PED over a secure channel with secure device <NUM> on behalf of a signed application. Secure device <NUM> can authorize the virtual PED. Where secure device <NUM> is not present, SoM <NUM> can provide functionality of the secure device <NUM> to securely operate touch display <NUM>, as described further herein. In one example, secure device <NUM> can additionally manage transaction payment, as described with respect to PIN pad <NUM> and/or related controller <NUM> above, and can thus activate the virtual PED to retrieve a PIN for processing transaction data at a related fuel dispenser, in one example.

In the above examples, where secured touch controller <NUM> is inside of secure device <NUM>, inputs to the virtual PED rendered by touch display <NUM> and received at the secured touch controller <NUM> are processed by secure device <NUM> as well. Where secured touch controller <NUM> is outside of secure device <NUM>, however, inputs from the touch display <NUM> can be encrypted by secured touch controller <NUM> for providing to secure device <NUM> and/or to SoM <NUM> to facilitate additional security for the input of confidential information on the virtual PED. This can be performed using secrets, encryption keys, or other security information held by and/or preconfigured to touch display <NUM> and the component operating the driver for secured touch controller <NUM> (e.g., secure device <NUM>), as similarly described above with respect to establishing the secure channel between a SoM and a PED.

Where secure device <NUM> is not present, AFP <NUM> can include the secured touch controller <NUM> under the anti-tampering shell <NUM>, and coupled to touch display <NUM> and/or SoM <NUM>. SoM <NUM> can be, or can provide, the secure controller for securing the secured touch controller <NUM> by implementing functionality described above with respect to secure device <NUM>, in one example. Thus, for instance, SoM <NUM> can implement the driver to operate and secure the display functionality of the touch display <NUM>, as described above with respect to PED <NUM> and/or associated secure controller <NUM>. For example, SoM <NUM> can operate the touch display <NUM> in a limited mode where not used for PIN entry. When an application requests rendering of the virtual PED on touch display <NUM> for PIN entry, for example, SoM <NUM> can accordingly prevent other applications from accessing touch display <NUM> until desired input is received or until the virtual PED is no longer active on touch display <NUM>. In addition, for example, SoM <NUM> can first verify the application is signed before rendering or otherwise allowing access to the virtual PED.

In addition, where secure device <NUM> is not present, SoM <NUM> can operate the driver to process inputs received via secured touch controller <NUM>, as described above with respect to SoM <NUM> and non-secured touch controller <NUM>. Thus, SoM <NUM> can receive commands from touch display <NUM> via secured touch controller <NUM>, and can process the commands for providing related information to one or more applications accessing the touch display <NUM>. Furthermore, where secure device <NUM> is not present and the secured touch controller <NUM> communicates directly with SoM <NUM>, SoM <NUM> can ensure that other applications are not able to access the touch input data received from secured touch controller <NUM>. In addition, where secure device <NUM> is not present, secure chip <NUM> may not be needed as the SoM <NUM> implements the secure controller functionality.

Furthermore, in this example, anti-tampering shell <NUM> encases the secured touch controller <NUM> as well to mitigate tampering with the controller <NUM> and/or any cables coupling the controller <NUM> to the touch display <NUM>. As described, anti-tampering shell <NUM> can include mesh layers to detect movement, removal, or other tampering with the shell <NUM> or components disposed therein. In addition, a secure cable can be used to couple secured touch controller <NUM> (e. under the anti-tampering shell <NUM>) with touch display <NUM>. The secure cable can be similar to the flexible circuit assembly <NUM> discussed previously, in one example. Also, for example, touch display <NUM> can utilize one or more microswitches, as discussed, to detect movement or removal thereof.

It is to be appreciated that AFP <NUM> can be implemented as SoM <NUM>, in one example, coupled to secure chip <NUM> and encased in the anti-tampering shell <NUM> with secured touch controller <NUM>.

<FIG> illustrates a diagrammatic side elevation view of an example AFP and SoM configuration <NUM> for deploying in a fuel dispenser. An AFP <NUM> is shown that includes a slot, socket, or similar interface <NUM> for receiving a SoM <NUM>. The SoM <NUM> can be a PCB that can be coupled to the slot <NUM> via a connector or circuit assembly. For example, the SoM <NUM> can include a plurality of terminal contacts that are received by slot <NUM> to provide electronic communications between the AFP <NUM> and SoM <NUM>. As depicted, horizontal mounting of the SoM <NUM> on a slot <NUM> displaced vertically or perpendicularly relative to the AFP <NUM> provides a low profile configuration.

In addition, in this regard, an anti-tampering shell <NUM> can be installed on the AFP <NUM>, encasing the SoM <NUM>, to prevent or otherwise detect tampering with the SoM <NUM>. For instance, the anti-tampering shell <NUM> can include a mesh layer or other tampering detection mechanism (e.g., one or more switches) disposed between it and the AFP <NUM> such that movement, removal, etc. detected on the anti-tampering shell <NUM> can trigger an event to AFP <NUM>, SoM <NUM>, or a related processor to erase memory, decommission one or more components, etc., as described above. Moreover, though not depicted, the AFP <NUM> can additionally include a secure chip or secured touch controller installed within the anti-tampering shell <NUM>.

Referring to <FIG>, a methodology that can be utilized in accordance with various aspects described herein is illustrated. While, for purposes of simplicity of explanation, the methodology is shown and described as a series of acts, it is to be understood and appreciated that the methodology is not limited by the order of acts, as some acts can, in accordance with one or more aspects, occur in different orders and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with one or more aspects.

<FIG> illustrates an example methodology <NUM> for processing a request to access a secured function. At <NUM>, a request for accessing a secured function is received. The request is received from an application operating on a feature processor, as described. The secured function relates accessing an input portion of a touchscreen display and accessing an available display function of such (e.g., a routine to present a virtual PED on the touchscreen, and receive information thereon). Moreover, it is to be appreciated that the request can be to present secure output or output in an attempt to solicit secure input as well.

At <NUM>, it is determined whether the application requesting the access is authenticated. This includes verifying whether the application is signed, and whether the signature correlates to an accepted source (e.g., a manufacturer of a fuel dispenser, a retail site operator, etc.). If the application is not authenticated, the request for the function is denied at <NUM>.

If the application is authenticated, at <NUM>, the function is activated and the request is granted. Activating the function includes communicating over a secure channel with a secure controller to access the secured function. This includes activating a touch display or a portion thereof, etc. over the secure channel (e.g., established using stored secrets, encryption information, etc.). In addition, activating the function and granting the request at <NUM> can also include ensuring another application is not using the requested function. Moreover, while verifying authentication at <NUM> is performed by a SoM, activating the function at <NUM> is requested by the SoM from a secure controller, which is a hardware controller at a PED.

At <NUM>, other applications can be blocked from using a device based on the request (e.g., applications that are not authenticated or any applications). This can include filtering commands from the other applications related to the device, which can include filtering commands related to an output or other function of the device as well in one example. The secured function correlates to an input function of a touch display where the device is the display, and thus the display is secured to prevent other applications from accessing while the secured function is activated. Blocking at <NUM> can occur on the SoM (e.g., where the other applications are not authenticated), and/or at the PED (e.g., where the other applications are not associated with the application using the secured function).

Claim 1:
A vending machine, comprising:
a display (<NUM>);
a non-secured touch controller (<NUM>) operatively connected to the display (<NUM>) and configured to receive input data from a touchscreen function of the display (<NUM>);
a PIN entry device PED (<NUM>) comprising a secure controller (<NUM>) operatively connected to the display (<NUM>) and configured to secure the display (<NUM>) by managing the display data transmitted to the display (<NUM>); and
an auxiliary feature processor (<NUM>) communicating with the secure controller (<NUM>) via a secure channel, wherein the auxiliary feature processor (<NUM>) comprises a system on module SoM (<NUM>) that establishes the secure channel with the secure controller (<NUM>), and a secure chip, wherein the SoM (<NUM>) is operatively coupled to the secure chip (<NUM>) that stores security information for establishing the secure channel with the secure controller (<NUM>), wherein the secure chip (<NUM>) provides the security information to the SoM (<NUM>) based at least in part on the secure chip verifying an identification parameter of the SoM (<NUM>), the auxiliary feature processor (<NUM>) being operative to manage access of one or more applications run on the auxiliary feature processor to the display (<NUM>) via the secure controller (<NUM>),
wherein the managing by the auxiliary feature processor (<NUM>) of the access of the one or more applications to the display (<NUM>) via the secure controller comprises: the SoM (<NUM>) evaluating respective signatures of the one or more applications by verifying whether the one or more applications are signed by a trusted or otherwise authenticated entity; the SoM (<NUM>) allowing appropriately signed applications to display data on the display (<NUM>) via the SoM (<NUM>) and secure controller; and the SoM (<NUM>) allowing appropriately signed applications to receive, for processing, touch screen input events associated with touch interactions on the display (<NUM>) and captured by the non-secured touch controller (<NUM>), from the non-secured touch controller (<NUM>) via the SoM (<NUM>).