Point-of-Sale (POS) System and Method with Dynamic Kernel Selection

Abstract

A payment reader may have one or more cores that are capable of performing certain payment processing functions but not certain more processing-intensive payment processing functions. The payment reader may be designed to selectively allocate processing tasks to application layer cores located on a mobile device and / or a cloud-based device outside the payment reader, where the mobile device has more or different processing resources than the payment reader. The selective allocation may be made dynamically based on a measurement of conditions of the reader or the occurrence of an event (such as determining that the payment reader cannot process a transaction, determining that the payment reader does not have sufficient battery strength to process a transaction, or determining that there has been a tampering attempt at the payment reader). The payment reader also has a physical layer module that maintains its processing on the payment reader. By these means, processing related to payment transactions is performed on a hybrid system using resources local and remote to the payment reader.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Application No. 16 / 230,823, filed on December 21, 2018, entitled "Point - of - Sale (POS) Systems and Methods with Dynamic Kernel Selection", which is incorporated herein by reference. This application also claims priority to U.S. Application No. 16 / 230,940, filed on December 21, 2018, entitled "Point - of - Sale (POS) Systems and Methods with Dynamic Kernel Selection", which is incorporated herein by reference. This application also claims priority to U.S. Application No. 16 / 231,030, filed on December 21, 2018, entitled "Point - of - Sale (POS) Systems and Methods with Dynamic Kernel Selection", which is incorporated herein by reference. Background Art

[0003] Consumers can interact with a merchant's payment reader in a variety of ways to conduct an electronic payment. For example, through a payment card with a magnetic stripe that is swiped through a magnetic reader of the payment reader, through a payment device with an Europay / MasterCard / Visa (EMV) chip that is inserted into a corresponding EMV slot of the payment reader, and through a Near - Field Communication (NFC) enabled device (such as a smartphone or an EMV card) that taps on the payment reader and transmits payment information via a secure wireless connection. The payment reader can receive payment information and information about the payment transaction from the payment device and can communicate such payment information to a payment system for processing and / or authorizing the transaction. Payment readers capable of facilitating such transactions can take many forms, including stand - alone mobile devices.

[0004] Mobile payment readers have been on the market for several years. However, as the functions related to payment processing increase in diversity and complexity, that is, as the payment options for consumers grow, the processing requirements for payment readers may become too excessive for the capabilities of the existing hardware already on the market. In some cases, the hardware of earlier (or older) generation payment readers used by merchants may not be able to meet the processing requirements of more modern payment transactions. In other cases, a payment reader used by a merchant may not be able to process modern payment transactions because the reader lacks sufficient power resources or the required software has not been updated. In other cases, a payment reader used by a merchant may be physically capable of processing payment transactions, but due to environmental or security conditions, may not be able or willing to process at a specific time or under specific conditions required by the consumer.

[0005] Accordingly, there is a need for solutions that more optimally utilize processing resources and / or power resources on a payment reader, prevent processing by outdated, less efficient, or undesirable software versions, and additionally enhance data security during payment processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The above and other features, nature, and various advantages of the present disclosure will become more apparent when the following detailed description is considered in conjunction with the accompanying drawings.

[0007] Figure 1 FIG. depicts a block diagram of a payment system according to some embodiments of the present disclosure.

[0008] Figure 2A and Figure 2B FIG. depicts a block diagram of a payment reader according to some embodiments of the present disclosure.

[0009] Figure 3A 、 Figure 3B 、 Figure 3C and Figure 3D FIGS. depict block diagrams of various payment service systems according to some embodiments of the present disclosure.

[0010] Figure 4 FIG. depicts a flowchart showing exemplary steps for payment processing according to some embodiments of the present disclosure.

[0011] Figure 5A and Figure 5B FIG. depicts a block diagram of a payment service system according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0012] Payment information can be processed using a payment reader by obtaining payment information from a payment interface, encrypting the obtained payment information, and / or performing payment processing according to a payment processing protocol to exchange information with a payment server. The payment reader can have one or more processors that include dedicated cores for payment processing and providing various functions related to the respective abstraction layers of the payment reader. For example, a module related to the functions of the first (physical) layer can control the interaction with a device (such as an NFC interface) capable of receiving information from a payment card. A core related to the functions of the second (application) layer can solve other tasks, such as, for example, processing payment transactions, encrypting within a secure payment enclave of the terminal, and / or transmitting payment information to a payment server for approval, etc. Generally, the physical layer is referred to herein as the "first layer" or "L1". Although in the context of the OSI model, the application layer is typically referred to as "layer 7" or "L7", in this document, application layer components can also be referred to as "second layer" or "L2" components to facilitate comparison with the term "L1". In this regard, it will be understood that in different embodiments, L1 and L2 can refer to OSI layers different from the physical layer and the application layer, and the concepts of the systems and methods described herein can be similarly applied thereto.

[0013] The payment reader may contain one or more processing units that can provide different processing capabilities. For example, older models of the payment reader may have been designed to work with a first-generation core that depends on a first limited set of hardware resources, while newer models of the payment reader may have been designed to have a second-generation core that provides a range of functions beyond those of the first-generation core, but requires a larger amount of memory and hardware resources compared to the first generation. For ease of reference, the core that provides the first limited set of processing functions is referred to herein as the "1st generation" or "GEN 1" core, while the core that provides the second, more robust set of processing functions is referred to herein as the "2nd generation" or "GEN 2" core.

[0014] In one embodiment, a merchant may have a payment reader with a GEN 1 core that cannot perform functions specific to a GEN 2 processor or handle information specific to a GEN 2 processor (i.e., "GEN 2 functions"). In a preferred embodiment, the payment reader includes a core controller (also referred to as a "core booter") that recognizes that the payment reader may not have the hardware or software resources required to perform GEN 2 functions. In response to this recognition, the core booter instead controls the payment reader to allocate the execution of such functions to an external device (such as a mobile device (e.g., a mobile phone or tablet) or a remote server) having the requisite GEN 2 core and resources. In a preferred embodiment, the core controller may be located within the processor, however, it may alternatively be implemented as a separate circuit within the payment reader (or implemented as any combination of hardware and software). In yet another embodiment, the core controller may be implemented on a separate device to control functions on the payment reader.

[0015] In another embodiment, the payment reader may have a GEN 2 core but may still decide to direct the processing of GEN 2 functions to the core of an external device because the payment reader is otherwise resource-constrained, e.g., due to the need to conserve power on the reader. In another alternative embodiment, the payment reader may have a GEN 2 core but may direct the processing of GEN 2 functions to the GEN 2 core of an external device having a different version than the GEN 2 core version on the reader, e.g., in cases where a particular GEN 2 function is performed more efficiently or better on the different version of the software. In yet another embodiment, the payment reader may have a GEN 2 core but may direct the processing of GEN 2 functions to the core of an external device because the payment reader has recognized a security threat to the reader (e.g., a tampering attempt). For ease of reference, processing performed by a core that is not local to the payment reader (regardless of the location of the device performing such processing and / or whether the device is physically connected to the payment reader) may be referred to herein as "processing in the cloud".

[0016] In another embodiment, rather than offloading the processing of GEN 2 functions to an external device, the processing is performed in an isolated secure area (such as a "trust zone") managed by a separate processor of the payment reader or a device acting as an embedded card reader (ECR).

[0017] In another embodiment, the core may be modular in nature, where different GEN 1 and / or GEN 2 functions at the application layer may be separated into different logically "sub-modules" of the core. In this embodiment, different core functions may be executed at different respective devices based on the hardware resources of the payment reader and other constraints.

[0018] Figure 1 FIG. depicts an illustrative block diagram of a payment system 1 in accordance with an embodiment of the present disclosure. As illustrated, payment system 1 includes a payment device 10, a payment reader 20, a network 30, a mobile device (such as a mobile phone or iPad) or an alternative computing device (such as a mobile device or a PC) 40, and a payment server 50. In an exemplary embodiment, payment server 50 may include multiple servers operated by different entities, such as a payment service system or a bank server. The components of payment system 1 facilitate an electronic payment transaction between a merchant and a customer.

[0019] The electronic interaction between the merchant and the customer occurs between the customer's payment device 10 and the merchant's payment reader 20. In a preferred embodiment, payment reader 20 may be a stand-alone mobile hardware device, although not limited thereto. For example, in other embodiments, payment reader 20 may be a mobile device, such as a smart phone (iOS or Android) or another computing device configured to act as an embedded card reader (ECR). In one embodiment, payment device 10 may be a device capable of communicating with payment reader 20, such as a credit card with a magnetic stripe, a credit card with an EMV chip, or an NFC-enabled electronic device (such as a smart phone running a payment application). The chip card may include a secure integrated circuit that is capable of communicating with payment reader 20, generating encrypted payment information, and providing the encrypted payment information and other payment or transaction information in accordance with one or more electronic payment standards (such as those published by EMVCo). Payment reader 20 is capable of executing a payment application (which may be a point-of-sale application or an application that provides a portion of its functionality in some embodiments), and includes at least one interface for receiving payment information from payment device 10. Payment reader 20 is capable of receiving and processing payment information through contact with a card or a contactless interface, and is capable of collecting payment information that includes transaction information (e.g., purchase amount and purchase point information) and card information (e.g., encrypted payment card data and user authentication data).

[0020] In some embodiments, a merchant may also have one or more mobile devices (or stationary computing devices) 40. In some embodiments, these devices may provide additional functionality to create, complete, supplement, or enhance a comprehensive point-of-sale system implemented by the merchant corresponding to the application of the payment reader. In some embodiments, one or more mobile devices 40 may provide a POS application that is completely separate from the payment application executed on the payment reader 20. The device 40 may be, for example, a mobile phone such as an iPhone or Android device, an iPad or tablet device, a laptop or touchscreen device, or a PC or stationary computing device, although any utility device capable of communicating with the payment reader may be suitable.

[0021] The payment reader 20, and / or, any merchant device 40 (in some embodiments), may communicate with a payment server 50 via a communication network 30. Although the communication network 30 may be any suitable communication network, in one embodiment, the communication network 30 may be the Internet, and payment and transaction information may be communicated between the payment reader 20 and the payment server 50 in an encrypted format such as via the Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocol. Additionally, when the network 30 is the Internet, the payment reader 20 may use the Transmission Control Protocol / Internet Protocol (TCP / IP) for communication.

[0022] Although the payment server 50 may be operated by a single entity, in one embodiment, the payment server 50 may include any suitable number of servers operated by any suitable entity, such as the payment service systems of merchants and customers and one or more banks (e.g., bank servers) or card issuers. The payment reader 20 and the payment server 50 communicate payment and transaction information to determine whether a transaction is authorized. For example, the payment reader 20 may provide encrypted payment data, user authentication data, purchase amount information, and point-of-purchase information to the payment server 50 via the network 30. The payment server 50 may determine whether the transaction is authorized based on the received information and information related to the customer's or merchant's account, and respond to the payment reader 20 via the network 30 to indicate whether the payment transaction is authorized. The payment server 50 may also transmit additional information such as a transaction identifier to the payment reader 20.

[0023] Based on the information received from the payment server 50 at the payment reader 20, the merchant can indicate to the customer whether the transaction has been approved. In some embodiments, such as a chip card payment device, approval can be indicated at the payment reader 20 (e.g., on the screen of the payment reader 20). In other embodiments, such as a mobile phone or smart device operating as an NFC payment device, information about the approved transaction and additional information (e.g., receipt, special offer, coupon, or loyalty program information) can be provided to the NFC payment device for display on the screen of the smartphone or watch or stored in the memory.

[0024] As previously described, the payment reader 20 can have, either alone or in combination with the device 40, a payment application that can provide for the entry of purchase and payment information, interaction with the customer, and communication with the payment server 50. For example, the payment application can provide a menu of services that the merchant can select and a series of menus or screens for automating the transaction. The payment application can also assist in entering customer authentication information, such as a signature, PIN, or biometric information.

[0025] Figure 2A An exemplary schematic diagram of the components of an exemplary payment reader 20 according to one embodiment is shown. The device can include a multi-core processor 205 or the equivalent. In some embodiments, the payment reader 20 can have another type of suitable processor and can include the hardware, software, memory, and circuitry (or any combination thereof) necessary to perform and control the functions of the payment reader 20. In some embodiments, the payment reader 20 can have multiple independent processing units, such as a multi-core processor or other similar components. In a preferred embodiment, the processor can have one or more dedicated cores for performing different functions related to payment processing.

[0026] The processor can execute instructions stored in the memory 209 to control the operation of the payment reader 20. As used herein, memory can refer to any suitable volatile and non-volatile storage medium, such as a disk, thumb drive, etc. Examples of such media include RAM, ROM, EPROM, EEPROM, SRAM, flash memory, magnetic or optical memory, magnetic memory, or any other tangible or non-transitory medium for storing information that can be accessed by the processor.

[0027] The reader may include a communication interface 213, which may include one or more wireless communication interfaces and / or wired communication interfaces. The reader 20 may also include a battery 207. As an alternative to the battery, one or more power sources may be used, such as a physical connection to an alternating current (AC) power source or a direct current (DC) power source (including a power conversion circuit). The battery 207 may be charged by a physical power connection, by inductive charging, or by any other suitable method. Although not depicted as physically connected to components of the payment reader other than the processor (described below), the battery may supply various voltages to the components of the payment reader 20 according to the requirements of those components.

[0028] A plurality of payment interfaces may be connected to respective ports or terminals on the processor 205. The processor 205 receives input from a magnetic stripe reader (MSR) 232, which is read by a head reader 230. In some embodiments, the MSR devices 230, 232 may include slots that guide a customer to slide or dip the magnetic stripe of a card to collect payment information. The received payment information may then be provided to the processor 205 for processing. Input is also received from EMV contacts 240 (chip cards), and this input is processed by an EMV contact block 242. The chip card may have contacts that engage and physically mate with corresponding contacts to contact the pins of the EMV interface 240. The EMV interface 240 provides power and communication for the EMV chip of the chip card according to the EMV specification. This data may be processed by the EMV contact application block 242 and provided to the processor 205.

[0029] Inputs from the contactless interface are received from the NFC contactless antenna 250 and processed by the NFC contactless application block 252. The contactless antenna 250 is configured to receive inputs from EMV cards 20 and NFC (Near Field Communication) cards as well as other NFC devices such as smart phones or other devices. In one embodiment, the antenna 250 may include circuitry for NFC communication such as electromagnetic compatibility (EMC) circuitry, matching circuitry, modulation circuitry, and measurement circuitry. Based on signals provided by the processor 205, the antenna 250 may output a carrier signal or a modulated signal. The carrier signal may be a signal having a fixed frequency such as 13.56 MHZ. The modulated signal may be a modulated version of the carrier signal according to modulation processes such as ISO 14443 and ISO 18092. When the payment reader 20 is inductively coupled to the contactless payment device 10, the contactless payment device 10 may modulate the carrier signal via active or passive load modulation. By changing the tuning characteristics of the antenna of the payment device 10, the wireless carrier signal is modified at both the payment device 10 and the payment reader 20, resulting in a modulated wireless carrier signal. In this way, the payment device 10 is able to send the modulated data to the payment reader 20, which can be sensed by the antenna 250 and provided to the processor 205 for processing. In a preferred embodiment, the above-described contactless and contact interfaces may be combined into a single payment device capable of providing all of the above functions.

[0030] Figure 2B An embodiment similar to Figure 2A is shown, where there are additional components, a security processor 260 and a memory 265, which are separate from the processor 205 and the memory 209 and are located in a secure area or secure enclave 270 of the reader. The secure area may include hardware (e.g., processing units, memory), firmware, and / or software (e.g., application programs) that are physically and logically isolated from the non-secure area. The secure area may be used to receive, process, and / or store secure data entering the payment reader and to perform functions depending on such secure data and components such as encryption.

[0031] It will be understood that the architectures described above and shown in Figure 2A and Figure 2B are not limited to the components discussed herein and may include other hardware and software components. Instead, for purposes of illustration, only the components and functions most relevant to the present invention are discussed herein.

[0032] Figure 3Aillustrates an architecture in which various cores dedicated to payment processing functions are located in corresponding devices within a payment system. A merchant system 300 including a payment reader 20 is illustrated as being divided into a physical layer (L1) containing modules and an application layer (L2) having one or more first-generation (GEN 1) cores, each core dedicated to a different payment function. In a preferred embodiment, the L1 module 302 may include hardware components that control the interaction with an interface (such as an NFC interface) that is capable of receiving information from a payment card and transferring the information to other components of the payment reader. In some embodiments, the L1 module may be capable of performing other physical layer functions related to the information received from the payment card (e.g., error correction). In Figure 3A the embodiment, multiple L2 GEN 1 cores 304, 306 are shown. In this embodiment, each of the multiple GEN 1 cores may correspond, for example, to a basic type of transaction for contactless payment processing. In this regard, each of the multiple GEN 1 L2 cores may be dedicated to, for example, a corresponding one of MasterCard (MC), VISA, JCB, CUP, and other transaction types.

[0033] In Figure 3A the embodiment, the payment reader 20 has limited hardware resources. For example, the payment reader 20 may have older or outdated chip technology that does not provide the processing power to perform certain payment processing functions. These additional functions that are beyond the capabilities of the GEN 1 cores may be referred to herein as "GEN 2 functions", i.e., functions having processor requirements that are beyond the capabilities of the GEN 1 cores but within the capabilities of the GEN 2 cores (such as collecting payment information from gift cards, loyalty cards, or other non-standard EMV payment devices, etc.). At the application layer, the L2 GEN 2 cores may provide various functions that are not accessible to the GEN 1 cores, such as encryption. By way of illustration, the security of elliptic curve cryptography (ECC) (suitable for, for example, encryption, key negotiation, digital signature, and other tasks) depends on the device's ability to perform intensive calculations at a relatively fast speed. Within the limitations of outdated hardware, such computationally intensive tasks may not be achievable, even if such hardware is otherwise still operational. Alternatively or additionally, the feature set available on the L2 cores may be larger (or different) than the feature set of the L1 module, and the feature set available on the GEN 2 cores is also larger compared to GEN 1. Thus, there may be memory limitations on outdated devices, which further limit or prohibit processing-intensive tasks.

[0034] Figure 3ASeveral devices capable of handling GEN 2 transactions external to the payment reader 20 are shown. In the illustrated example, each mobile device 40A (which may include, for example, a mobile phone (such as an iPhone or Android), an iPad or other tablet computer, a laptop or touchscreen computer, or any other suitable device), computing device 40B (which may be, for example, a personal computer), and remote server 310 have GEN 2 L2 cores. It will be understood that, given the particular architecture of a merchant system and payment system, any number of external devices may be used. Both the mobile device 40A and the computing device 40B are illustrated as part of the merchant system (merchant device 300), that is, the merchant controlling the payment reader 20 also controls the mobile device 40A and / or the computing device 40B, although they are not limited thereto. Thus, in this embodiment, although the devices 40A and 40B are external to the payment reader 20, they are not necessarily located in geographically distant locations.

[0035] The payment reader 20 may also include a payment application or payment software 301. In some embodiments, the payment application 301 may include features that make up all or part of a point-of-sale (POS) application (or associated payment functionality). When executed by the processor 205, in some embodiments, the payment application 301 may provide a display with an interactive interface that allows a merchant to process payment transactions with a customer. These instructions may include a customized interface that allows a merchant or customer to select products for purchase, calculate sales tax, process tips, provide receipts, generate discounts or specials, process customer loyalty programs, search for items in inventory or items for delivery, and / or perform any other suitable retail operations. Additionally, at an appropriate time during transaction processing, the payment application 301 may send a message to one or more payment interfaces to allow the payment reader 20 to receive payment information from the payment device 10. In an alternative embodiment, the payment application 301 may be executed from a device external to the payment reader 20 (such as the mobile device 40A (smartphone) or any other practical implementation). For example, such an implementation may be preferred where the hardware resources on the reader 20 are limited. In yet another embodiment, some elements of the payment application 301 may run on the reader 20 (such as the ability to accept user input), while other elements may be executed from a different device.

[0036] Figure 3AA payment processing server 50 is also shown. The payment processing server 50 is a remote server capable of authorizing payments. The payment server 50 may include multiple servers operated by different entities, such as a payment service system or a bank server. Each of the mobile device 40A, the computing device 40B, the remote server 310, and the payment reader 20 can communicate with the payment processing server 50 in multiple ways.

[0037] In the first embodiment, the payment reader includes a kernel controller 305 that dynamically selects or determines a dedicated kernel to which specific transaction data should be directed for processing. The kernel controller 305 can be implemented in hardware and / or software or any combination thereof. In the illustrated embodiment, the kernel controller 305 is shown as a separate component. However, in another example, the kernel controller can be part of the payment application 301. In yet another example, the functions of the kernel controller can alternatively be performed by one or more components of the processor 205.

[0038] In Figure 3A In the illustrated embodiment, the L1 module 302 controls the interaction with the payment interfaces 232, 242, 252 to receive payment information from the payment card 20. The kernel controller 305 of the payment reader 20 determines that the processing requirements for a payment transaction include functions that can be implemented by a GEN2 kernel but not by any of the L2 GEN 1 kernels 304 and 306. Since it has been determined that the reader does not have the hardware resources to execute the required GEN 2 functions, the kernel controller 305 instead controls the allocation of the execution of this function to a GEN 2 kernel external to the reader, such as the GEN 2 kernel of the mobile device 40A, the PC 40B, or the remote server 310 (regardless of whether the device performing the processing is outside the merchant system 300), any of which may have the required GEN 2 kernel and sufficient hardware resources.

[0039] In an alternative embodiment, the contactless program software (e.g., NFC software) in the customer's mobile payment device 10 may itself initiate a call to a kernel or module in the payment reader 20. For example, using the NFC antenna, the NFC software in the payment device 10 can call the L1 module 302, call the application layer kernels 304 or 306, or call the kernel controller 305, which can determine which kernel to use and can direct the NFC software to call the selected kernel.

[0040] The distribution of different kernel functions locally and to resources in the cloud can be considered a "hybrid" distribution or allocation of the kernels. For example, in Figure 3AIn the illustrated hybrid implementation, the GEN 1 functions required to process payments are performed at the payment reader 20 (i.e., locally), while the GEN 2 functions required to process payments are performed by a GEN 2 kernel remote from the reader 20 (i.e., in the cloud). For example, in one embodiment, the GEN 2 functions can be performed by a GEN 2 kernel on a mobile phone or iPad device. In a non-hybrid architecture, both the GEN 1 and GEN 2 kernels would be located on the payment reader 20, or both would be located at a single location external to the reader 20 (e.g., a mobile device, computing device, or remote server).

[0041] Figure 3B An alternative embodiment is illustrated, in which the payment reader 20 can include a GEN 1 kernel 304 and a GEN 2 kernel 354 at the application layer and an L1 module at the physical layer. In the case where the payment reader has a GEN 2 kernel, only one L2 GEN 2 kernel is required for contactless payments regardless of the transaction type used (e.g., MC, VISA, etc.). In another embodiment (not specifically illustrated), a second L2 GEN 2 kernel is dedicated to processing contact-based payments (e.g., swiping or chip payments). In such an embodiment, where the payment reader has the ability to perform GEN 2 functions, the reader 20 can still choose to offload GEN 2 processing to a device with the same (or similar) GEN 2 processor. In other words, the system selectively chooses among replicated copies of the GEN 2 kernel located at different installation points. This choice can be motivated by a variety of factors and is not limited to hardware resource constraints.

[0042] In one embodiment, the process of determining to offload GEN 2 functionality can be based on the determination that the payment reader, although having sufficient processor bandwidth, is otherwise resource - constrained. For example, due to low battery power or excessive power consumption caused by other tasks such as card reading, computing, and communication, the payment reader may need to conserve power. In one embodiment, the kernel controller 305 can make a determination based on the determination of the power level of the payment reader to move the processing to the cloud, or otherwise direct the processing to the GEN 1 or GEN 2 kernel local to the reader 20. In a preferred embodiment, the kernel controller can include a power measurement circuit or sensor (not specifically shown) that can be connected to the processor 205, and this sensor is capable of dynamically measuring the power level of the battery 207. Alternatively, the circuit for measuring the battery charge can be separated from the kernel controller and can communicate with the kernel controller. As an example, the kernel controller can measure the current power level of the reader supplied by the battery 107 by one of these means. If this current power level falls below a predetermined minimum threshold, the kernel controller can ignore the local kernel and instead direct the processing of the functionality to the GEN 2 kernel installed on the mobile device 40A (or any other suitable external device). By these means, a low - power device can conserve energy and not have to worry about being unable to process based on limited power resources. In some embodiments, the predetermined threshold against which the battery charge is measured can be a value stored in the memory 209, while in other embodiments, the predetermined threshold can be a percentage value of the total battery capacity of the reader. Still in other embodiments, one or more thresholds can be stored in a reference table or other data structure in the memory 209 in association with conditional events (such as the mechanical or environmental conditions of the reader) or scheduled events (which may affect power consumption). In one such example, the kernel controller 305 can determine that the reader is scheduled to perform a task that requires high power consumption and can refer to the reference table to determine the threshold power value associated with the scheduled event. Then the current power level of the battery 207 is compared with this threshold to determine whether the payment processing can be performed while still maintaining power for the scheduled task. In yet another embodiment, the table in the memory 209 can associate the threshold with specific historical or predicted power usage conditions (such as observed or predicted power consumption patterns). In an exemplary embodiment, the kernel controller can make several iterative measurements of the power level and can observe the pattern of power consumption (e.g., the rate of depletion over time). Then, the kernel controller can refer to the table in the memory 209 to determine whether a particular threshold is associated with such a pattern (e.g., such a threshold is higher than the minimum threshold to account for a subsequent drop in power). If the current power level is below this threshold, the kernel controller directs the processing of the GEN 2 information to the kernel on the external device.Generally, it should be understood that the threshold against which the current power level is compared can be any measurable value against which the battery charge can be compared.

[0043] Alternatively, the determination to offload processing from the reader can be based on a comparison of the power levels between the payment reader and the device on which the target GEN 2 kernel resides (e.g., relative battery power), or based on any other measurement of power consumption and / or constraints. In one such example, the kernel controller 305 can measure the current power level of the reader 20 and the current power level of the mobile device 40A. Then both of these values can be compared to a predetermined threshold (either compared to the same threshold or to two corresponding thresholds). In the case where the measured power level value of the reader drops below the threshold and the measured power level of the mobile device 40A is above its threshold, the kernel controller can then (as described above) bypass the processing on the local kernel of the reader and instead direct the processing to the GEN 2 kernel installed on the mobile device 40A. In another example, the difference in power levels between the payment reader and the mobile device 40A is calculated, and in the case where the power level of the mobile device is higher than the power level of the payment reader by a predetermined difference (i.e., the mobile device has power to spare), even if the specific power level of the reader itself does not necessarily drop below the low power threshold, the processing can be directed to the GEN 2 kernel installed on the mobile device 40A.

[0044] In an alternative embodiment, the kernel controller 305 can dynamically determine to route the processing of a function to the GEN 2 kernel on an external device, where the GEN 2 kernel installed on the payment reader may not be the ideal version for performing a particular GEN 2 function. That is, the GEN 2 kernels located on the reader 20 and on the external devices 40A, 40B, 310 are not replicated copies, but rather, the various copies of the kernel can be versioned differently relative to each other (in any permutation of versions). Thus, based on a comparison of the version of the kernel software on the payment reader with the version of the kernel software on the target cloud device, the kernel controller can determine to direct the processing to the most suitable (e.g., most efficient or otherwise preferred) version of the kernel.

[0045] In yet another embodiment, due to recognized security threats to the reader, the kernel controller 305 may choose to offload processing. As an example, the reader 20 (or an external security monitoring circuit (or software) or a human participant) may recognize that the reader has been tampered with, such as by adding unauthorized third-party hardware components capable of reading card data or by altering, manipulating, or damaging any component of the reader 20. In a preferred embodiment, the kernel controller may dynamically refer to a tamper detection circuit (not specifically shown) or other sensors to determine if a tampering attempt has been made. In other embodiments, the kernel controller itself may include such a circuit, or such a circuit may be housed on an external device. In one embodiment, the tamper detection circuit may be able to measure the resistance or capacitance value of the reader 20. It will be understood that the capacitance value may be measured based on the charge of any component part of the reader, the charge of a specific (e.g., secure) part of the reader, Charge the total charge of the reader, or any other suitable measurement. The capacitance measurement may then be compared to a known capacitance value, and if the difference between the two values exceeds a specific amount, the kernel controller may determine that a tampering attempt has been made. In another example, a tampering attempt may be detected by scanning the components of the reader 20 to determine if there are any differences in the data stored in the memory 209, where there are unexpected or unknown applications, or differences in the physical and logical partitioning of components within the secure and non-secure regions, etc. By rerouting the processing from the local kernel on the reader to the cloud, the system may in some cases circumvent the compromised components of the reader.

[0046] Figure 3C FIG. illustrates an alternative embodiment where the payment reader 20 may include a GEN 1 or GEN 2 L2 kernel, which is modular in nature; that is, different GEN 1 and / or GEN 2 functions at the physical layer and / or application layer may be partitioned into different logical "sub-modules" of the L2 kernel. In other words, rather than treating the entirety of the L2 kernel as an indivisible unified or monolithic component, its functions may be decomposed into certain component parts. In this embodiment, different L2 kernel functions may be executed at different corresponding devices based on the hardware (or other) resources of the payment reader. In an exemplary embodiment, sub-modules 1 and 2 of the L2 kernel of the reader 20 may be implemented in various ways on the reader or on a device in the cloud. Figure 3CDepicts a mobile payment reader 20 having an L2 core sub-module 1 (a first sub-module of the L2 core) 340. An L2 core sub-module 2 (a second sub-module of the same L2 core) 342, 344, or 346 can be housed on an external device, such as any one of a mobile device 40A, a PC 40B, or a remote server 310. The sub-module 340 and the sub-modules 342, 344, 346 can be directed to different functions of the L2 core. For example, in various embodiments, any one or more of the sub-modules 340, 342, 344, and / or 346 can act in various ways to perform functions of the payment reader, such as the following: a selection manager (e.g., a kernel controller that directs data for processing of different elements of the payment reader), personal identification number (pin) handling, primary kernel functions (e.g., core transactions), a cryptographic handler, payment authorization / approval / denial / recommendation, handling additional payment services, handling non-payment services using cardholder information, a configuration manager (e.g., handling configurations specific to a country, brand, payment transaction type, etc.), risk handling, an interaction point (e.g., cardholder / merchant display or data entry via a UI, keypad, or peripheral device), receipt handling, a proximity protocol, handling unauthorized transactions, timeouts or cancellations, secure channel management, and communication between different modules or devices, and other functions. It will be understood that these are merely general categories of functions that can be implemented in one or more sub-modules in some cases and are not intended as an exhaustive list or as a strict one-to-one correspondence between functions and discrete sub-modules. As an example illustrated, where the L2 core on the reader 20 includes a sub-module related to contactless payment processing and a sub-module directed to handling PIN / signature / bio data, one of these sub-modules can be executed on the reader 20 and one sub-module can be executed on the mobile device 40A. Although the above functions can either be executed on the reader itself or from an external device, functions related to the communication abstraction layer (i.e., handling communication between the L1 layer of the payment reader and the remaining layers of the OSI layer) or certain low-level conversations with contact-based payment cards typically must be located in the payment reader itself because moving such functions to other locations would be impractical or inefficient.

[0047] By distributing the locations of these sub - modules, the processing of various functions can be optimized during execution. In an exemplary scenario, a specific sub - module designed to handle highly sensitive information can be offloaded to a cloud - based device with additional security features. In another exemplary situation, one or more sub - modules can be processed from a cloud - based device in cases where computing resources would otherwise not allow parallel processing on the reader, thereby completing the processing in a more timely manner. In another exemplary scenario, the information required by the sub - modules can be stored in the cloud (i.e., at a location remote from and / or restricted away from the reader 20), and the processing can be delegated to a kernel sub - module located on a device from which the required data can be accessed more efficiently.

[0048] Figure 3D The figure shows an alternative embodiment in which the L1 module has been divided into sub - modules. The sub - modules of the L1 module represent one or more of the following: the mechanical characteristics of the elements that engage the payment card or NFC - enabled device, the electrical characteristics of the signals applied to and received from the payment card or NFC - enabled device, and other characteristics required to operate the complete L1 module. In some embodiments, all of the sub - modules of the L1 module can be on the payment reader itself, such as Figure 3D the L1 sub - modules 1c (element 370) and 2c (element 372) shown in, which are housed on the payment reader 20. Alternatively, as Figure 3D shown, the L1 sub - modules can be divided between the physical layer and the application layer of the payment reader 20, where sub - module 1a (element 350) is in the L1 layer of the reader and sub - module 2a (element 352) is in the application layer of the reader. In yet another alternative embodiment, sub - module 1b (element 360) can be located on the payment reader, while sub - module 2b (elements 356, 357, or 358) can be located on an external device (such as a mobile device 40A, a PC 40B, or a remote server 310). Note that sub - module 2b is a sub - module of the L1 layer of the payment reader 20, not of the L1 layer of the external device on which the sub - module is located. Thus, in the illustrated embodiment, the L1 sub - module 2b will be processed on the application layer of the external device. In other embodiments, the L1 sub - modules can be distributed differently.

[0049] It will be understood that the L1 sub - modules that are directed to the mechanical characteristics of the reader (e.g., card contacts, wires, active and / or passive circuits for processing signals, etc.) can actually be implemented only on the reader itself, since those functions are typically physically embedded in the reader. However, the L1 sub - modules that are directed to other characteristics can alternatively be arranged to be located on the reader or on a device external to the reader. For example, Table 1 below lists some distributions of sub - modules that can be implemented in such embodiments.

[0050]

[0051] Table 1

[0052] As an example, in some embodiments, only software modules / features are arranged as software within the reader or on an external device such as a mobile phone (L1 sub-modules 2a or 2b, respectively). In these embodiments, discrete software components executed on the reader or on the external device drive electrical and mechanical components / features, which, for example, regulate voltage or test card contacts (L1 sub-modules 1a and 1b). As another example, row 4 of Table 1 refers to an embodiment in which both electrical and software sub-modules are arranged on the mobile phone (e.g., L1 sub-modules 2b 356, 357, or 358) or in the application layer of the reader (L1 sub-module 2a). In this alternative embodiment, software components executed on the kernel of the external device can drive the electrical performance of the reader 20 (e.g., via an audio / lightning jack, etc.), for example, to regulate voltage or drive copper wires to the EMV contact pads or NFC coils (antennas) on the payment reader 20 (e.g., in L1 sub-modules 1a or 1b). As an example, a Software Defined Radio application or equivalent (L1 sub-module 2b) on one of the mobile device 40A, PC 40B, or remote server 310 is used to control the NFC coil (L1 sub-module 1b) held on the payment reader 20. Similarly, software (L1 sub-module 2a) in the application layer of the payment reader can be used to control mechanical components (L1 sub-module 1a) in the physical layer.

[0053] It will be understood that the architecture described above and illustrated in Figures 3A - 3D is not limited to the components discussed herein and may include other hardware and software components. Instead, for purposes of illustration, only the components and functions most relevant to the present invention are discussed herein.

[0054] Figure 4 An example diagram of the data flow between the components of the reader 20 and the mobile device 40A according to one embodiment is illustrated. In Figure 4 the example of Figure 3B the architecture along the lines shown in the example can be used as an exemplary model. The process begins at step 402, where the L1 module of the reader 20 reads card data via the contactless antenna 250, for example, in an NFC transaction. At step 404, the card data is transmitted to the processor 205 (or to the secure processor 260 when appropriate). At step 406, the kernel controller 305 determines which kernel should process the payment transaction.

[0055] In a first scenario, the processing requirements of the transaction and the payment information are restricted to the features of the GEN 1 application layer kernel. In this first scenario, the kernel controller directs the processing in step 408 to the L2 GEN1 kernel 304 local to the payment reader 20. The processing can involve various steps, including, for example, the entry of authentication data such as signatures, PINs, or biometric data. After processing, the kernel 304 sends the processed payment information to the payment processing server 50 (e.g., the issuer server) via the communication interface 213 for authentication. In an alternative embodiment, where the reader may not have the memory or processing capabilities to communicate with the payment processing server, the processed payment data can be sent via the communication interface 213 to the mobile device 40A or the computing device 40B, which in turn forwards the data to the payment processing server 50.

[0056] In a second scenario, the processing requirements of the transaction can only be met by the GEN 2 application layer kernel, and the payment reader 20 has a GEN 2 kernel and has available resources to process the transaction. In this scenario, the kernel controller 305 directs the processing in step 408 to the L2 GEN 2 kernel 354 local to the payment reader 20. The processing can involve various steps, including, for example, transactions based on non-standard payments such as gift cards via an application on a smartphone and / or the encryption of the card and payment data. The processing can also involve, for example, the entry of authentication data. After processing, the kernel 354 sends the processed payment information to the payment processing server 50 in step 410, or alternatively, to the mobile device 40A or the computing device 40B, which in turn forwards the data to the payment processing server 50.

[0057] In a third scenario, the processing requirements of a transaction can only be met by the GEN 2 application layer kernel, however, the payment reader 20 does not have a GEN 2 kernel and / or does not have available resources to process the transaction. In this scenario, the kernel controller 305 in step 406 redirects the processing to any one of the L2 GEN 2 kernels 312, 322, or 332 on a remote server 310, a mobile device 40A, or a computing device 40B (each of which is external to the reader) by sending payment data via the communication interface 213. Then, the kernel on the selected external device processes the transaction. The processing can involve various steps, including for example transactions based on gift cards in the form of non-standard payments (such as payments via an application on a smart phone) and / or encryption of the card and transaction data. The processing may also require for example the entry of authentication data, and in such a case, the kernels 312, 322, 332 receive such data in step 450 before processing the transaction in step 452. After processing, in step 454, the external device transmits the data (which can also include the transmission of other data such as PIN, signature, or biometric data) to the payment processing server 50.

[0058] With the methods and systems described above, even if the payment reader is limited in terms of hardware resources, memory, power, or its ability to process payment transactions is otherwise restricted, it can still assist in the processing of various payment transactions. By this, merchants can rejuvenate their existing, already deployed payment systems without having to make significant investments in new computing resources and / or payment readers. Additionally, by creating a hybrid processing system using cloud-based resources, the security and efficiency of existing payment processing solutions can be improved (e.g., by providing more robust encryption solutions). As a result, improvements to the computing system are achieved even in cases where outdated hardware or other factors may not allow for improvements at the level of the payment reader itself.

[0059] In another embodiment, with reference to Figure 5A, an additional processor can be provided in the reader 20 in an area that is physically and logically isolated from the non - secure (or relatively non - secure) area and other processing components in the secure enclave 270, which manages a secure area separated from the secure enclave 270. This additional secure area is referred to herein as the "trusted area" or "trusted zone" 520. The resource of the trusted area processor 510 manages the trusted area 520, that is, manages the security of the trusted area on the chip itself. In some embodiments, the trusted area processor 510 can maintain a bit value that specifies whether the payment reader should be in a "trusted" or "normal" state, although other embodiments are also possible. The components of the reader 20 and any data buses will be notified of this bit value, allowing the processor 510 to isolate the trusted area and control access to it. As an example, the trusted area 520 can be implemented using technology from ARM Corporation, but other technologies can also be used. The trusted area can include corresponding hardware (e.g., a separate processing unit, memory), firmware, and software (e.g., applications).

[0060] In an exemplary embodiment, the kernel controller 305 can dynamically determine to redirect the processing of GEN 2 functions to a separate GEN 2 kernel 354 located in the isolated trusted area 520 of the payment reader 20. The kernel controller 305 can make such a determination based on detected events such as tampering events. That is, after detecting a tampering attempt, the kernel controller 305 can reroute the processing of GEN 2 functions (which otherwise could be executed by the GEN 2 kernel 354 in the secure enclave 270) to be executed by the GEN 2 kernel 524 within the trusted area 520. In another implementation, the trusted area can be associated with a dedicated Android processor (e.g., a chip) running on the payment reader, that is, the trusted area is implemented by the Android OS, which can have additional security features that are bootstrapped to functions related to tampering, for example.

[0061] In another exemplary architecture, the payment system 1 additionally includes a mobile device 511 such as an Android smartphone, which is configured to act as an ECR. In Figure 5BIn the illustrated exemplary embodiment, device 511 is a mobile device that has an Android processor 517 for handling the various functions of the Android OS and for managing a trust zone 520 having an L1 module 522 and an L2 core 524 dedicated to handling payment transactions. In scenarios where the GEN 2 core on reader 20 may not meet the security requirements of GEN2 processing (e.g., a tampering attempt on the reader is detected), or in scenarios where reader 20 does not have available resources to handle security-intensive transactions, kernel controller 305 can send GEN 2 data (as Figure 5B shown by the dashed line) to be processed by the GEN 2 core 524 in the isolated trust zone 520 of ECR 511. In different embodiments, kernel controller 305 can send the GEN 2 data to mobile device 40A, which in turn determines that the data should be processed in the trust zone and sends the data to the GEN 2 core 524 in trust zone 520 (as Figure 5B shown by the dotted line). In yet another alternative architecture (not specifically shown), ECR 511 (e.g., on an Android phone) replaces payment reader 20 instead of having a separate payment reader 20, and the ECR locally processes the GEN 2 payment information in its trust zone through an appropriate core.

[0062] Using a trust zone may have several benefits compared to a hybrid system that otherwise has a secure enclave. Initially, in the preferred embodiment, the trust zone is implemented by code running locally, allowing the code to directly access hardware peripherals. Thus, the trust zone implementation may be more efficient and process faster compared to solutions where the code is implemented, for example, in a Java layer or on the main processor that has to access an operating system / compatibility layer or may require additional Java compilation to perform the same action. Additionally, since the concept of a trust zone is typically implemented in ARM-based architectures (e.g., on some Android phones), a separate security chip is not required, thus reducing manufacturing costs. Moreover, since trust zones are typically implemented in some common CPU architectures, their security has been well tested, resulting in a potentially more secure system with more sets of built-in defenses.

[0063] Exemplary Clauses

[0064] 1. A mobile communication device, comprising: a communication interface for communicating with a first type of payment reader and a second type of payment reader, each second type of payment reader having a second-generation layer 2 (L2) kernel for processing payment information from a second type of payment device, and each first type of payment reader having a first-generation L2 kernel for processing payment information from a first-generation payment device; and at least one processor programmed with instructions that, when executed by the at least one processor, cause the at least one processor to: receive the processed second type of payment information that has been processed by the second-generation L2 kernel of the second type of payment reader; transmit the processed second type of payment information to one or more payment servers to approve a payment transaction based on the processed second type of payment information; receive the first type of payment information processed by the first-generation L2 kernel of the first type of payment reader; transmit the first type of payment information to one or more payment servers to approve a payment transaction based on the first type of payment information; receive the raw second type of payment information from the first type of payment reader; provide the raw second type of payment information to the second-generation L2 kernel of the mobile communication device for processing the raw second type of payment information; and transmit the raw second type of payment information that has been processed by the second-generation L2 kernel of the mobile communication device to one or more payment servers to approve a payment transaction based on the transmitted raw second type of payment information.

[0065] 2. The mobile communication device according to clause 1, further comprising: an interface configured to receive contactless payments directly from a payment device, wherein the interface uses the second-generation L2 kernel of the mobile communication device to receive contactless payments.

[0066] 3. The mobile communication device according to clause 1, wherein the second-generation L2 kernel of the mobile communication device has stronger processing capabilities than the first-generation L2 kernel.

[0067] 4. The mobile communication device according to clause 1, wherein the raw second type of payment information includes authentication information related to the payment transaction.

[0068] 5. The mobile communication device according to clause 1, wherein the mobile communication device is further configured to: receive the unprocessed second type of payment information from the second-generation L2 kernel of the second type of payment reader; and provide the unprocessed second type of payment information to the second-generation L2 kernel of the mobile communication device to process the unprocessed second type of payment information.

[0069] 6. The mobile communication device according to clause 5, wherein the second-generation L2 kernel of the second type of payment reader is functionally the same as the second-generation L2 kernel of the mobile communication device.

[0070] 7. The mobile communication device according to clause 1, wherein the mobile communication device is a mobile phone.

[0071] 8. A method, comprising: receiving, by a mobile communication device, payment information from a first type of payment reader or a second type of payment reader, wherein the first type of payment reader has a first-generation L2 kernel for processing payment information from a first type of payment device, and wherein the second type of payment reader has a second-generation layer 2 (L2) kernel for processing payment information from a second type of payment device; in a case where the received payment information is processed second type of payment information processed by the second-generation L2 kernel of the second type of payment reader, transmitting, by the mobile communication device, the processed second type of payment information to one or more payment servers to approve a payment transaction based on the processed second type of payment information; in a case where the received payment information is first type of payment information processed by the first-generation L2 kernel of the first type of payment reader, transmitting, by the mobile communication device, the first type of payment information to one or more payment servers to approve a payment transaction based on the first type of payment information; in a case where the received payment information is original second type of payment information from the first type of payment reader, (a) providing, by the mobile communication device, the original second type of payment information to a second-generation L2 kernel of the mobile communication device for processing the original second type of payment information, and (b) transmitting, by the mobile communication device, the original second type of payment information that has been processed by the second-generation L2 kernel of the mobile communication device to one or more payment servers to approve a payment transaction based on the transmitted original second type of payment information.

[0072] 9. The method according to clause 8, further comprising: receiving, using a second-generation L2 kernel of the mobile communication device, a contactless payment from a payment device.

[0073] 10. The method according to clause 8, wherein the second-generation L2 kernel of the mobile communication device has stronger processing capabilities than the first-generation L2 kernel of the first type of payment reader.

[0074] 11. The method according to clause 8, wherein the original second type of payment information includes authentication information related to the payment transaction.

[0075] 12. The method according to clause 8, further comprising: receiving unprocessed second type of payment information from the second-generation L2 kernel of the second type of payment reader; and providing the unprocessed second type of payment information to a second-generation L2 kernel of the mobile communication device for processing the unprocessed second type of payment information.

[0076] 13. The method according to clause 8, wherein the second-generation L2 kernel of the second type of payment reader is functionally the same as the second-generation L2 kernel of the mobile communication device.

[0077] 14. The method according to clause 8, wherein the mobile communication device is a mobile phone.

[0078] 15. A non-transitory computer-readable storage medium, comprising instructions stored therein that, when executed by one or more processors of a mobile communication device, cause one or more processing units to perform operations, the operations including: receiving payment information from a first payment reader or a second payment reader external to the mobile communication device, wherein the first payment reader has a first-generation L2 kernel configured to process a first type of payment information, and wherein the second payment reader has a second-generation layer 2 (L2) kernel configured to process a second type of payment information different from the first type of payment information; transmitting the received payment information to one or more payment servers to approve a payment transaction based on the received payment information in a case where the received payment information includes the second type of payment information and the received payment information has been processed by the second-generation L2 kernel of the second payment reader; transmitting the received payment information to one or more payment servers to approve a payment transaction based on the received payment information in a case where the received payment information includes the first type of payment information and the received payment information has been processed by the first-generation L2 kernel of the first payment reader; and in a case where the received payment information includes the second type of payment information and the received payment information has been received from the first payment reader without being processed, performing the following: (a) processing the received payment information using the second-generation L2 kernel of the mobile communication device, and (b) transmitting the processed payment information to one or more payment servers to approve a payment transaction based on the processed payment information.

[0079] 16. The non-transitory computer-readable storage medium according to clause 15, wherein the execution of the instructions further causes one or more processing units to perform an operation, the operation including: receiving a contactless payment from a payment device using the second-generation L2 kernel of the mobile communication device.

[0080] 17. The non-transitory computer-readable storage medium according to clause 15, wherein the second-generation L2 kernel of the mobile communication device has a stronger processing capability than the first-generation L2 kernel of the first payment reader.

[0081] 18. The non-transitory computer-readable storage medium according to clause 15, wherein the received payment information includes authentication information related to the payment transaction.

[0082] 19. The non-transitory computer-readable storage medium according to clause 15, wherein the execution of the instructions further causes one or more processing units to perform operations, the operations including: receiving unprocessed payment information from a second-generation L2 kernel of a second payment reader, the unprocessed payment information including a second type of payment information; and providing the unprocessed payment information to a second-generation L2 kernel of a mobile communication device for processing the unprocessed payment information.

[0083] 20. The non-transitory computer-readable storage medium according to clause 15, wherein the second-generation L2 kernel of the second payment reader is functionally the same as the second-generation L2 kernel of the mobile communication device.

[0084] 21. A point-of-sale (POS) system, comprising: a payment reader having a payment application, a first module of a layer 2 (L2) kernel, and a layer 1 (L1) module for receiving payment information from a payment device, the payment application being configured to provide the payment information to the first module of the L2 kernel for processing the payment information by the first module of the L2 kernel; and a device external to the payment reader, the device having a second module of the L2 kernel, wherein the payment application is configured to transmit the payment information processed by the first module of the L2 kernel to the device for processing by the second module of the L2 kernel.

[0085] 22. The POS system according to clause 21, wherein the device is configured to transmit the payment information to one or more payment servers after the payment information has been processed by the second module of the L2 kernel.

[0086] 23. The POS system according to clause 21, wherein the processing by the second module of the L2 kernel is related to the authentication of a payment transaction.

[0087] 24. The POS system according to clause 21, wherein the payment information includes first payment information and second payment information, wherein the first module of the L2 kernel is configured to process the first payment information, and the second module of the L2 kernel is configured to process the second payment information.

[0088] 25. A point-of-sale (POS) system, comprising: a payment device having a payment application, a layer 2 (L2) kernel, and a first sub-module of a layer 1 (L1) module, the first sub-module of the L1 module being configured to receive payment information from a payment object, the payment application being configured to provide the payment information from the first sub-module of the L1 module to the L2 kernel for processing the payment information by the L2 kernel; and a payment reader coupled to the payment device and having a second sub-module of the L1 module, the second sub-module of the L1 module including a physical interface configured to read payment information from the payment object, wherein the payment reader is configured to transmit the payment information read from the payment object to the first sub-module of the L1 module.

[0089] 26. The POS system according to clause 25, wherein the payment device is a mobile phone external to the payment reader, and wherein the payment reader is communicatively coupled to the mobile phone.

[0090] 27. The POS system according to clause 25, wherein the second sub-module of the L1 module is related to the mechanical function of the payment reader.

[0091] 28. The POS system according to clause 27, wherein the mechanical function of the payment reader involves one or more of the following: adjusting the voltage level of the payment reader and achieving contact with the payment object.

[0092] 29. The POS system according to clause 25, wherein the first sub-module of the L1 module is related to the control of the software function of the payment reader.

[0093] 30. The POS system according to clause 25, wherein the first sub-module of the L1 module is related to the control of the electrical function of the payment reader.

[0094] 31. The POS system according to clause 30, wherein the electrical function of the payment reader involves driving the electrical connection between the wire and the payment interface of the payment reader, and wherein the payment interface is one or more of an EMV contact pad or an NFC coil.

[0095] 32. A payment device, comprising: an interface configured to receive payment information from a payment object; a payment application; a first module of a kernel; and a wireless communication interface capable of communicating with a device other than the payment device, the device including a second module of the kernel, wherein the payment application is configured to provide the received payment information to the device via the wireless communication interface for processing by the second module.

[0096] 33. The payment device according to clause 32, wherein the payment application is further configured to: receive the processed payment information from the device via the wireless communication interface, the processed payment information having been processed by the second module, and transmit the processed payment information to one or more payment servers.

[0097] 34. The payment device according to clause 32, wherein the payment application is further configured to: before transmitting the processed payment information to one or more payment servers, transmit the processed payment information to the first module of the kernel for processing.

[0098] 35. The payment device according to clause 32, wherein the first module processes the first payment information of the received payment information, and the second module processes the second payment information of the received payment information, and wherein the processing of the first payment information by the first module and the processing of the second payment information by the second module are performed in parallel.

[0099] 36. A method, comprising: receiving payment information from a payment object by a payment device; transmitting the payment information by the payment device to a first module of a kernel, the first module being installed on the payment device for processing the payment information by the first module; and transmitting the payment information processed by the first module by the payment device to a second module of the kernel for processing by the second module, the second module being installed on a device external to the payment device.

[0100] The foregoing is only an illustration of the principles of the present disclosure, and those skilled in the art can make various modifications without departing from the scope of the present disclosure. The above embodiments are presented for illustration rather than limitation. The present disclosure can take many forms other than those explicitly described herein. Therefore, it is emphasized that the present disclosure is not limited to the explicitly disclosed methods, systems, and devices, but is intended to include variations and modifications thereof within the spirit of the appended claims.

[0101] As another example, changes in device or process parameters (e.g., dimensions, configurations, components, order of process steps, etc.) can be made to further optimize the provided structures, devices, and methods (as shown and described herein). In any case, the structures and devices described herein and the associated methods have many applications. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but should be construed in terms of the breadth and scope of the appended claims.

Claims

1. A point of sale (POS) system, comprising: A payment reader having a payment application, a layer 1 (L1) module for receiving payment information from a payment card, and a first layer 2 (L2) kernel; And A mobile device external to the payment reader, the mobile device having a second L2 kernel, Wherein, based on the payment information received from the payment card, the payment application is configured to obtain data related to the conditions of the payment reader, and dynamically select one of the first L2 kernel and the second L2 kernel for processing the payment information based on the obtained condition data, Wherein, when the first L2 kernel is selected to process the payment information, the payment application is configured to send the unprocessed payment information to the first L2 kernel of the payment reader for processing; and Wherein, when the second L2 kernel is selected to process the payment information, the payment application is configured to send the unprocessed payment information to the second L2 kernel of the mobile device for processing; The obtained data related to the conditions of the payment reader includes at least one of the following: Determining that the processing capacity of the payment reader is insufficient to process the payment information; Determining that the power level of the payment reader is insufficient to process the payment information; Determining that the L1 kernel of the payment reader cannot process the payment information; and Determining that a tampering attempt has occurred on the payment reader.

2. The POS system according to claim 1, wherein The payment application is further configured to, when the first L2 kernel is selected to process the payment information, send the payment information processed by the first L2 kernel of the payment reader to the second L2 kernel of the mobile device.

3. The POS system according to claim 1, characterized in that, The conditions of the payment reader are related to one of the following: (a) the detected power level of the battery of the payment reader, (b) the detected power level of the battery of the device external to the payment reader, and (c) the relative power level between the payment reader and the device external to the payment reader.

4. The POS system according to claim 3, wherein The conditions of the payment reader are related to the occurrence of a low power event, and Wherein, a low power event is determined to have occurred when any of the following is true: (a) the detected power level of the battery of the payment reader drops below a predetermined threshold; (b) the difference between the detected power level of the battery of the payment reader and the detected power level of the battery of the mobile device external to the payment reader exceeds a predetermined difference, or (c) the detected power level of the battery of the payment reader drops below a predetermined threshold, and the detected power level of the battery of the mobile device external to the payment reader exceeds a predetermined threshold.

5. The POS system according to claim 1, wherein The conditions of the payment reader are related to the version number of the first L2 kernel of the payment reader.

6. The POS system according to claim 1, wherein The conditions of the payment reader are related to the detection of potential tampering attempts on the payment reader.

7. A payment reader, comprising: A layer 1 (L1) module for receiving payment information from a payment device; A communication interface configured to transmit information from the payment reader to a networked device having a Layer 2 (L2) kernel; And A kernel booter configured to, based on payment information received from a payment device, (a) obtain data related to conditions of the L1 module, (b) dynamically select whether to send the payment information to the L2 kernel of the networked device for processing based on the obtained condition data, and (c) instruct the transmission of the payment information to the L2 kernel according to the selection made by the kernel booter; The obtained data related to conditions of the L1 module includes at least one of the following: Determining that the processing capacity of the payment reader is insufficient to process the payment information; Determining that the power level of the payment reader is insufficient to process the payment information; Determining that the L1 kernel of the payment reader cannot process the payment information; And Determining that a tampering attempt has occurred on the payment reader.

8. The payment reader according to claim 7, characterized in that, The L1 module is classified in the OSI physical layer of the payment reader, and the L2 kernel is classified in the OSI application layer of the networked device.

9. A system, comprising: A payment device; And A payment reader having a payment application, a first Layer 2 (L2) kernel in a first processor, a second L2 kernel in a second processor, and a Layer 1 (L1) module in a third processor, the L1 module for receiving payment information from the payment device, wherein the second L2 kernel is within a trusted region of the second processor, wherein the payment application is configured to dynamically select one of the first L2 kernel and the second L2 kernel for processing the payment information based on event data and provide the payment information to the selected L2 kernel, wherein the payment application is configured to select the first L2 kernel for processing the payment information when the event data indicates that a first condition occurs; and wherein the payment application is configured to select the second L2 kernel for processing the payment information when the event data indicates that a second condition occurs; The event data indicating that the second condition occurs includes at least one of the following: Determining that the processing capacity of the payment reader is insufficient to process the payment information; Determining that the power level of the payment reader is insufficient to process the payment information; Determining that the L1 kernel of the payment reader cannot process the payment information; and Determining that a tampering attempt has occurred on the payment reader.

10. The system according to claim 9, wherein When a tampering event is suspected to have occurred on the first L2 kernel, the event data indicates the second condition.

11. The system according to claim 9, characterized in that, The first processor is within a secure payment enclave (SPE) of the payment reader.

Images