JP2022512297A - Point-of-sale (POS) system and method with dynamic kernel selection - Google Patents

Abstract

A payment reader can have one or more kernels that can perform certain payment processing functions, but cannot perform certain more processing intensive payment processing functions. The payment reader may be designed to selectively assign processing tasks to a mobile device external to the payment reader and / or an application layer kernel located on a cloud-based device, wherein the mobile device is the payment reader. Has more or different processing resources. The selective allocation determines that the payment reader is unable to process the transaction, determines that the payment reader does not have sufficient battery strength to process the transaction, or tampers with the payment reader. It may be done dynamically based on the measurement of the condition of the reader or the occurrence of an event, such as the determination that there was an attempt. The payment reader also has a physical layer module, which maintains its processing on the payment reader. By these means, the processing related to the payment transaction is performed on the hybrid system using both local and remote resources for the payment reader. [Selection diagram] FIG. 3A

Description

Cross-reference of related applications This application is the US application No. 1 filed on December 21, 2018, entitled "Point of Sale (POS) Systems and Methods by Dynamic Kernel Selection". Claim the priority of 16 / 230,823, which is incorporated herein by reference. This application also applies to US Application No., filed December 21, 2018, entitled "Point of Sale (POS) Systems and Methods with Dynamic Kernel Selection". Claim the priority of 16 / 230,940, which is incorporated herein by reference. This application also applies to US Application No., filed December 21, 2018, entitled "Point of Sale (POS) Systems and Methods with Dynamic Kernel Selection". Claim the priority of 16 / 231, 030, which is incorporated herein by reference.

Consumers may use, for example, a payment card with a magnetic strip that is passed through a payment reader's magnetic reader, a payment device with an EUROPAY / MasterCard / VISA (EMV) chip inserted into the corresponding EMV slot of the payment reader, and a payment reader. A merchant's payment reader to trade electronic payments (electronic payments) in a variety of ways, including short-range communication (NFC) -enabled devices such as smartphones or EMV cards that are tapped and send payment information over a secure wireless connection. Can interact with. Payment readers can receive payment information as well as information about payment transactions from payment devices, and such payment information can be communicated to the payment system for processing and / or authorization of transactions. Payment readers capable of facilitating such transactions can take various forms, including stand-alone mobile devices.

Mobile payment readers have been on the market for several years now. However, as the functions associated with payment processing become more diverse and complex, i.e., as consumers' payment options increase, the processing requirements of payment readers can exceed the capabilities of existing hardware already on the market. There is sex. In some cases, the hardware of early (or earlier) generation payment readers used by merchants may not be able to meet the processing requirements of more modern payment transactions. In other cases, the payment reader used by the merchant may not be able to process modern payment transactions because it lacks sufficient power resources or has not been updated with the required software. In yet other cases, the payment reader used by the merchant can physically process the payment transaction, but at a particular time or by the consumer due to environmental or security conditions. Under certain circumstances, you may not be able to or do not want to do so.

Therefore, in general, it makes better use of processing and / or power resources on the payment reader to prevent processing by obsolete, inefficient, or unwanted software versions, otherwise data in the process of payment. A solution that improves security is desired.

The above and other features of the present disclosure, their properties and various advantages will become more apparent by considering the following detailed description in conjunction with the accompanying drawings.

FIG. 1 shows a block diagram of a payment system according to some embodiments of the present disclosure.

, 2A and 2B show block diagrams of payment readers according to some embodiments of the present disclosure.

, , , 3A, 3B, 3C, and 3D show block diagrams of various payment service systems according to some embodiments of the present disclosure.

FIG. 4 shows a flow chart illustrating exemplary steps for payment processing according to some embodiments of the present disclosure.

, 5A and 5B show a block diagram of a payment service system according to some embodiments of the present disclosure.

Payment information by using a payment reader to retrieve payment information from the payment interface, encrypt the obtained payment information, and / or perform payment processing according to the payment processing protocol for exchanging information with the payment server. Can be processed. A payment reader can have one or more processors, including a dedicated kernel for payment processing, and provides various functions for each abstraction layer of the payment reader. For example, modules related to the functionality of the first physical layer can control interaction with devices that can receive information from payment cards such as NFC interfaces. Kernels related to the functionality of the second application layer are, among other things, such as processing payment transactions, encryption in the terminal's secure payment enclave, and / or sending payment information to a payment server for approval. Can deal with the task of. Generally, the physical layer (physical layer) is referred to herein as the "first layer" or "L1", while the application layer (application layer) is generally referred to as "layer 7" or "L7" in the context of the OSI model. The application layer component may also be referred to herein as a "second layer" or "L2" component for ease of comparison with the term "L1". In this regard, it is understood that in various embodiments L1 and L2 may refer to OSI layers that are different from the physical and application layers, and the concepts of systems and methods described herein may apply to them as well. Will be done.

The payment reader can include one or more processing units that can provide different processing powers. For example, older models of pay readers may be designed to work with first generation kernels that rely on the configuration of first limited hardware resources, while newer models of pay readers are first generation. It may be designed with a second generation kernel that offers a set of features that go beyond that of the first generation kernel, resulting in more memory and hardware resources than the first generation. For ease of reference, the kernel that provides the first limited processing function setting is referred to herein as the "Generation 1" or "GEN 1" kernel and is the second more robust. The kernel that provides the processing function settings is referred to herein as a "Generation 2" or "GEN 2" kernel.

In one embodiment, the merchant may have a payment reader with a GEN 1 kernel that is unable to perform functions specific to the GEN 2 processor (ie, "GEN 2 function") or process information. .. In a preferred embodiment, the payment reader comprises a kernel controller (also referred to as a "kernel director") that recognizes that the payment reader does not have the necessary hardware or software resources to perform the GEN 2 function. In response to that recognition, the kernel director instead controls the payment reader to control the performance of its functionality externally, such as on mobile devices (such as mobile phones and tablets) and remote servers with the required GEN 2 kernel and resources. Assign to device. In a preferred embodiment, the kernel controller can be located within the processor, but can instead be implemented as a separate circuit within the payment reader (or as any combination of hardware and software). In yet another embodiment, the kernel controller may be implemented on a separate device to control functionality on the payment reader.

In another embodiment, the payment reader can have a GEN 2 kernel, but nevertheless, the payment reader is otherwise limited in resources due to the need to save power in the reader, for example. Therefore, it can be decided to instruct the kernel of the external device to process the GEN 2 function. In another alternative embodiment, the payment reader can have a GEN 2 kernel, but on the reader, for example, if certain GEN 2 functions are performed more efficiently or preferably on different versions of the software. It is possible to instruct the GEN 2 kernel of an external device of a different version from the GEN 2 kernel to process the GEN 2 function. In yet another embodiment, the payment reader can have a GEN 2 kernel, but since the payment reader is aware of a security threat to the reader (eg, an attempt to tamper with it), the processing of the GEN 2 function can be handled by an external device. You can tell the kernel. For ease of reference, processing by the kernel that is not local to the payment reader (regardless of the location of the device performing the processing and / or whether the device is physically connected to the payment reader) is referred to herein. It can be called "in-cloud" processing.

In another embodiment, instead of offloading the processing of the GEN 2 function to an external device, the processing is managed by a separate processor of the device acting as a payment reader or embedded card reader (ECR). It runs in a secure area (such as a "trust zone").

In another embodiment, the kernel may be modular in nature and different GEN 1 and / or GEN 2 functions at the application layer may be separated into different logic "submodules" of the kernel. In this embodiment, among other constraints, different kernel functions can be performed on different devices based on the hardware resources of the payment reader.

FIG. 1 shows an exemplary block diagram of a payment system 1 according to an embodiment of the present disclosure. As shown, the 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 PC) 40, and a payment server 50. .. In an exemplary embodiment, the payment server 50 can include multiple servers operated by different entities such as payment service systems or bank servers. The components of the payment system 1 facilitate electronic payment transactions between merchants and customers (consumers).

The electronic dialogue between the merchant and the customer takes place between the customer's payment device 10 and the merchant's payment reader 20. In a preferred embodiment, the payment reader 20 may be, but is not limited to, a stand-alone mobile hardware device. For example, in other embodiments, the payment reader 20 can be a mobile device such as a smartphone (iOS or Android), or another computing device configured to act as an embedded card reader (ECR). In one embodiment, the payment device 10 is with a device capable of communicating with the payment reader 20, such as a credit card with a magnetic strip, a credit card with an EMV chip, or an NFC-enabled electronic device such as a smartphone running a payment application. can do. The chip card communicates with the payment reader 20 to generate encrypted payment information, encrypted payment information as well as other payment or transaction information according to one or more electronic payment standards, such as those promulgated by EMVCo. Can include secure integrated circuits that can provide. The payment reader 20 can run a payment application, which in some embodiments may be a POS application, or an application that provides some of its functionality, to receive payment information from the payment device 10. Includes at least one interface of. The payment reader 20 receives and processes payment information via a contact or non-contact interface with the card, including transaction information (eg, purchase amount and point-of-purchase information) and card information (eg, encrypted payment card data and). Payment information including user authentication data) can be collected.

In some embodiments, the merchant may also have one or more mobile devices (or fixed computing devices) 40. In some embodiments, these devices correspond to payment reader applications and provide additional functionality to create, complete, supplement, or augment a comprehensive point-of-sale system implemented by merchants. Can be done. In some embodiments, one or more of the mobile devices 40 can provide a POS application that is completely separate from the payment application running 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 touch screen device, or a PC or fixed computing device, but any device capable of communicating with a payment reader. A practical device may be appropriate.

The payment reader 20 and / or, in some embodiments, any merchant device 40 can communicate with the payment server 50 via the communication network 30. The communication network 30 may be any suitable communication network, but in one embodiment, the communication network 30 may be the Internet, and payment information (payment information) and transaction information may be transport layer security (TLS). Alternatively, the secure socket layer (SSL) protocol may be used to communicate between the payment reader 20 and the payment server 50 in such an encrypted format. Further, when the network 30 is the Internet, the payment reader 20 may use a transmission control protocol / Internet protocol (TCP / IP) for communication.

The payment server 50 may be operated by a single entity, but in one embodiment the payment server 50 may be a payment service system, one or more banks of merchants and customers (eg, a bank server), or a card issuer. , May include any suitable number of servers operated by any suitable entity. The payment reader 20 and the payment server 50 communicate the payment information and the transaction information to determine whether the transaction is permitted. For example, the payment reader 20 can provide encrypted payment data, user authentication data, purchase amount information, and purchase time point information to the payment server 50 via the network 30. Based on this received information, as well as information about the customer's or merchant's account, the payment server 50 determines whether the transaction is permitted and sets the network 30 to indicate whether the payment transaction is permitted. You can respond to the payment reader 20 through. The payment server 50 can also send additional information, such as a legal entity, to the payment reader 20.

Based on the information received by the payment reader 20 from the payment server 50, the merchant can indicate to the customer whether the transaction has been approved. In some embodiments, such as a chip card payment device, approval may be shown on the payment reader 20, eg, on the screen of the payment reader 20. In other embodiments, such as mobile phones or smart devices that act as NFC payment devices, information and additional information about approved transactions (eg, receipts, special offers, coupons, or loyalty program information) is displayed on the screen of a smartphone or watch. It may be provided to the NFC payment device for display at or stored in memory.

As mentioned above, the payment reader 20 has a payment application that can provide purchase and payment information input, customer interaction, and communication with the payment server 50, alone or with the device 40. Can be done. For example, a payment application can provide a menu of services that merchants can select and a set of menus or screens for automating transactions. Payment applications can also facilitate the entry of customer credentials such as signatures, PIN numbers, or biometric information.

FIG. 2A shows an exemplary schematic of the components of an exemplary payment reader 20 according to an embodiment. The device can include a multi-core processor 205 or equivalent. In some embodiments, the payment reader 20 may have another type of suitable processor, hardware, software, memory, as needed to perform and control the functions of the payment reader 20. And circuits (or any combination thereof) can be included. In some embodiments, the payment reader 20 can have multiple independent processing units, such as a multi-core processor or other similar component. In a preferred embodiment, the processor can have one or more dedicated kernels for performing different functions related to payment processing.

The processor can control the operation of the payment reader 20 by executing the instructions stored in the memory 209. As used herein, memory can refer to any suitable storage medium, such as a disk, thumb drive, both volatile and non-volatile. Examples of such media include RAMs, ROMs, EPROMs, EEPROMs, SRAMs, flash memories, disks or optical storage devices, magnetic storage devices, or any other tangible medium or non-any other tangible medium that stores information accessible by a processor. Temporary media is included.

The reader may include a communication interface 213 which may include one or more of a wireless communication interface and / or a wired communication interface. The reader 20 can also include a battery 207. As an alternative to the battery, one or more power sources can be used, such as physical connection to AC power or DC power (including power conversion circuits). The battery 207 may be charged via a physical power connection, via inductive charging, or via any other suitable method. Although not shown to be physically connected to payment reader components other than the processor (discussed below), batteries vary into payment reader 20 components according to the requirements of these components. It can supply voltage.

The plurality of payment interfaces may be connected to the corresponding ports or terminals on the processor 205. Processor 205 receives the input from the magnetic stripe reader (MSR) 232 read by the magnetic head reader 230. In some embodiments, the MSR device 230, 232 may include a slot that guides the customer to swipe or dip the magnetized strip of the card to collect payment information. The payment information received can then be provided to processor 205 for processing. The input is also received from the EMV contact 240 (chip card) and processed by the EMV contact (contact) block 242. The chip card can have contacts that engage and physically interface with the contacts corresponding to the contact pins of the EMV interface 240. The EMV interface 240 provides power and communication to the EMV chip of the chip card according to the EMV specification. This data is processed by the EMV contact block 242 and supplied to the processor 205.

The input from the non-contact interface is received from the NFC non-contact antenna 250 and processed by the NFC non-contact block 252. The non-contact antenna 250 is configured to receive inputs from the EMV card 20 and NFC (Near Field Communication) cards, as well as other NFC devices such as smartphones or other devices. In one embodiment, the antenna 250 can include circuits for NFC communication such as electromagnetic compatibility (EMC) circuits, matching circuits, modulation circuits, and measurement circuits. Based on the signal provided by processor 205, antenna 250 may output either 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 by a modulation procedure 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 can modulate the carrier signal via active or passive load modulation. By changing the tuning characteristics of the antenna of the paying device 10, the radio carrier signal is changed in both the paying device 10 and the paying reader 20, resulting in a modulated radio carrier signal. In this way, the payment device 10 can transmit the modulated data to the payment reader 20, which data can be sensed by the antenna 250 and provided to the processor 205 for processing. In a preferred embodiment, the contact and non-contact interfaces described above can be combined into a single payment device capable of providing all of the above functions.

FIG. 2B shows an embodiment similar to that of FIG. 2A, with the addition of a secure processor 260 and memory 265 located in the secure area or secure enclave 270 of the reader 20 and separate from the processor 205 and memory 209. There are components of. The secure area can include hardware (eg, processing unit, memory), firmware, and / or software (eg, application) that is physically and logically separated from the non-secure area. Secure areas are used to receive, process, and / or store secure data that enters payment readers, and to perform functions that depend on such secure data and components (eg, encryption). Can be done.

It should be appreciated that the architecture described above shown in FIGS. 2A and 2B is not limited to the components described herein and may include other hardware and software components. Rather, for ease of illustration, only the components and functions most relevant to the invention are discussed herein.

FIG. 3A shows an architecture in which various kernels dedicated to payment processing functions are placed on each device in the payment system. The merchant system 300 including the payment reader 20 is divided into a physical layer (L1) containing modules and an application layer (L2) having one or more first generation (GEN 1) kernels dedicated to different payment functions. Shown as being done. In a preferred embodiment, the L1 module 302 is a hardware component that controls interaction with an interface (such as an NFC interface) that can receive information from the payment card and transfer that information to other components of the payment reader. Can be included. In some embodiments, the L1 module may be capable of performing other physical layer functions (eg, error correction) related to the information received from the payment card. In the embodiment of FIG. 3A, a plurality of L2 GEN 1 kernels 304, 306 are shown. In this embodiment, each of the plurality of GEN 1 kernels can accommodate, for example, a basic type of transaction for contactless payment processing. In this regard, each of the plurality of GEN 1 L2 kernels may be dedicated to, for example, one for each of MasterCard (MC), VISA, JCB, CUP, and other transaction types.

In the embodiment of FIG. 3A, the payment reader 20 has limited hardware resources. For example, the payment reader 20 may have specific or specific chip technology that cannot provide the processing power to perform certain payment processing functions. These additional features outside the scope of the GEN 1 kernel can be referred to herein as "GEN 2 features", i.e., processor requirements that exceed the capabilities of the GEN 1 kernel but are within the capabilities of the GEN 2 kernel. It can be a feature it has, such as, among other things, the collection of payment information from gift cards, loyalty cards, or other non-standard EMV payment devices. At the application layer, the L2 GEN 2 kernel may provide various features that are inaccessible to the GEN 1 kernel, such as encryption. To illustrate, the security of Elliptic Curve Cryptography (ECC) (applicable to encryption, key agreements, digital signatures, and other tasks) depends on the ability of the device to perform relatively fast and intensive computations. Such computationally intensive tasks may not be accomplished within the constraints of older hardware, even if such hardware is still working. Alternatively or additionally, the feature set available on the L2 kernel may be larger (or different) than the feature set on the L1 module, and features available on the GEN 2 kernel compared to GEN 1. The set is still larger. For this reason, older devices have memory limits that further limit or prohibit processing-intensive tasks.

FIG. 3A shows some devices outside the payment reader 20 capable of processing GEN 2 transactions. In the illustrated example, a mobile device 40A (eg, a mobile phone such as an iPhone® or Android, an iPad® or other tablet, a laptop or touch screen computer, or any other suitable device. Each of the computing device 40B (which may be a personal computer), and the remote server 310 (which may include) has a GEN2 L2 kernel. Given the specific architecture of the merchant system and payment system, it will be understood that any number of external devices can be used. Both the mobile device 40A and the computing device 40B are shown as part of the merchant system (merchant device 300), i.e. the merchant under the control of the payment reader 20 is also the mobile device 40A and / or the computing device. Although under the control of 40B, they are not so limited. Therefore, in this embodiment, the devices 40A and 40B are outside the payment reader 20, but do not necessarily have to be located at a remote geographic location.

The payment reader 20 may also include a payment application or payment software 301. The payment application 301, in some embodiments, includes all or part of a POS (point-of-sale) (point-of-sale) application, or a function that constitutes a payment function related thereto. Can be done. When executed by the processor 205, the payment application 301 can, in some embodiments, provide a display with an interactive interface that allows a merchant to process a payment transaction with a customer. These orders allow merchants or customers to select products for purchase, calculate sales taxes, process tips, provide receipts, generate discounts or special offers, and process customer loyalty programs. And may include a customized interface that allows you to search for items for inventory or delivery and / or perform any other suitable retail operation. Further, at an appropriate time within the transaction process, 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. can. In an alternative embodiment, the payment application 301 may be performed from an external device of the payment reader 20, such as a mobile device 40A (smartphone), or any other practical implementation. Such an implementation is preferred, for example, when the hardware resources on the reader 20 are limited. In yet another embodiment, some elements of the payment application 301 may be executed on the reader 20 (eg, a function for user input), and other elements may be executed from different devices.

FIG. 3A also shows a payment processing server 50, which is a remote server capable of approving payments. The payment server 50 can include a plurality of 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 various ways.

In a 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, but in another example the kernel controller can be part of the payment application 301. In yet another example, the function of the kernel controller may otherwise be performed by one or more components of processor 205.

In the embodiment shown in FIG. 3A, the L1 module 302 controls a dialogue 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 processing of payment transactions requires functionality that cannot be performed by either the L2 GEN 1 kernels 304 and 306, although the processing of payment transactions can be performed by the GEN 2 kernel. Since it was determined that the reader does not have the hardware resources to perform the required GEN 2 functions, the kernel controller 305 instead GENs outside the reader such as mobile device 40A, PC 40B, or remote server 310. Control to assign the performance of the function to the 2 kernels (regardless of whether the processing device is outside the merchant system 300), one of which is the required GEN 2 kernel and sufficient. May have hardware resources.

In an alternative embodiment, the contactless program software (eg, NFC software) in the customer's mobile payment device 10 may itself be capable of initiating a call to the 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, the application layer kernel 304 or 306, or the kernel controller 305, which determine which kernel to use. Can be instructed to call the NFC software to its selected kernel.

This distribution of different kernel features to local and cloud resources can be thought of as a "hybrid" distribution or allocation of kernels. For example, in the hybrid implementation shown in FIG. 3A, the GEN 1 function required to process the payment is performed by the payment reader 20 (ie, locally) and the GEN 2 function required to process the payment is the reader. Run by the GEN 2 kernel away from 20 (ie, in the cloud). For example, in one embodiment, the GEN 2 function may be performed by the GEN 2 kernel on a mobile phone or iPad device. In a non-hybridized architecture, both the GEN 1 and GEN 2 kernels are located on the payment reader 20, or both are in a single location outside the reader 20 (eg, mobile devices, computing devices, or). It is placed on the remote server).

FIG. 3B shows an alternative embodiment in which the payment reader 20 may include both GEN 1 kernel 304 and GEN 2 kernel 354 in the application layer and the L1 module in the physical layer. If the payment reader has a GEN 2 kernel, only one L2 GEN 2 kernel is required for contactless payments, regardless of which transaction type (eg MC, VISA, etc.) is used. In another embodiment (not shown), the second L2 GEN 2 kernel is dedicated to processing contact-based payments (eg, swipes or chip payments). In such an embodiment, if the payment reader has the ability to perform GEN 2 functions, the reader 20 will nevertheless offload GEN 2 processing to a device with the same (or similar) GEN 2 processor. You can choose to do. In other words, the system selectively chooses between duplicate copies of the GEN 2 kernel located at different installation points. This choice can be motivated by a variety of factors, not just constraints on hardware resources.

In one embodiment, the decision to offload the processing of the GEN 2 function can be based on the determination that the payment reader has sufficient processor bandwidth, but otherwise resource is limited. For example, payment readers may need to save power due to, for example, low battery levels or excessive power consumption due to other tasks such as card reading, arithmetic, and communication. The determination to transfer processing to the cloud may, in one embodiment, be made by the kernel controller 305 based on the determination of the power level of the payment reader, which otherwise GEN 1 local to the reader 20. Alternatively, the GEN 2 kernel can be instructed (directed) to process. In a preferred embodiment, the kernel controller can include a power measurement circuit or sensor (not specifically shown) that can be connected to processor 205, such sensor for dynamic measurement of the power level of battery 207. It can be carried out. Alternatively, the circuit that measures the battery level may be separate 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 via one of these means. If this current power level falls below a given minimum threshold, the kernel controller ignores the local kernel and instead uses the GEN 2 kernel installed on the mobile device 40A (or any other suitable external device). You can instruct the processing of the function. By these means, low power devices may save energy and there is no concern about processing failures based on limited power resources. In some embodiments, the predetermined threshold for measuring the battery level may be a value stored in memory 209, in others the predetermined threshold is a percentage value of the total battery capacity of the reader. There may be. In yet another embodiment, one or more thresholds are associated with a reader's mechanical or environmental conditions that may affect power consumption, or conditional events such as scheduled events, memory 209. Can be stored in a reference table or other data structure in. In such an example, the kernel controller 305 can determine that the reader is scheduled to perform a task that requires high power consumption, and the threshold power value associated with the scheduled event. You can refer to the reference table to identify. The current power level of battery 207 is then compared to its threshold to determine if payment processing can be performed while still maintaining power for the scheduled task. In yet another embodiment, the table in memory 209 can associate the threshold value with a particular history or predicted power usage condition (such as an observed or predicted pattern of power consumption). In an exemplary embodiment, the kernel controller can make several iterative measurements of power levels and observe patterns of power consumption (eg, drainage rate over time). The kernel controller can then refer to a table in memory 209 to determine if a particular threshold is associated with such a pattern (such thresholds take into account, for example, later power drops). Higher than the minimum threshold). If the current power level is below that threshold, the kernel controller directs the kernel on the external device to process the GEN 2 information. In general, it will be appreciated that the threshold at which the current power level is compared can be any measurable value to which the battery level can be compared.

Alternatively, the decision to offload processing from the reader may be a comparison of power levels between the paying reader and the device on which the target GEN 2 kernel is located (eg, relative battery power), or any of the power consumption and / or constraints. It may be based on other measurements. In such an example, the kernel controller 305 can measure both the current power level of the reader 20 and the current power level of the mobile device 40A. Both of these values can then be compared to a given threshold (either the same threshold or either of the two respective thresholds). If the measured power level of the reader's value is below the threshold and the measured power level of the mobile device 40A is above that threshold, the kernel controller bypasses the process on the kernel local to the reader (as described above). Instead, the GEN 2 kernel installed on the mobile device 40A can be instructed to do so. In another example, the power level difference between the pay reader and the mobile device 40A is calculated so that the power level of the mobile device is a predetermined difference higher than the power level of the pay reader (ie, the mobile device has spare power). In the scenario (with), the GEN 2 kernel installed on the mobile device 40A may be instructed to process even if the particular power level of the reader itself does not fall below the low power threshold.

In an alternative embodiment, the kernel controller 305 can dynamically determine to route the processing of the function to the GEN 2 kernel on the external device, and the GEN 2 kernel installed on the payment reader is a particular GEN. 2 It can be a non-ideal version to perform the function. That is, the GEN 2 kernel located on the reader 20 and the GEN 2 kernel on the external devices 40A, 40B, 310 are not duplicate copies, but the various copies of the kernel are relative to each other (in any ordered version). Can be different versions. Therefore, the kernel controller is the most appropriate (eg, most efficient or otherwise suitable) based on a comparison of the kernel software version of the payment reader with the kernel software version on the target cloud device. You may decide to instruct a version of the kernel to do something.

In yet another embodiment, the kernel controller 305 may choose to offload processing to the reader due to a recognized security threat. As an example, the reader 20 (or external security monitoring circuit (or software) or human actor (actor)) can read the card data through the addition of unauthorized third party hardware components or as a reader. It is possible to recognize that the reader has been tampered with, such as through modification, manipulation, or damage to any of the 20 components. In a preferred embodiment, the kernel controller can dynamically reference a tampering detection circuit (not shown) or another sensor to determine if a tampering attempt has been made. In other embodiments, the kernel controller itself may include such circuits, or such circuits may be housed on an external device. The tampering detection circuit can, in one embodiment, measure the resistance value or the capacitance value of the reader 20. Capacitance values can be measured based on the charge of any component of the reader, the charge of a particular (eg, secure) part of the reader, the overall charge of the reader, or any other suitable measurement. Will be understood. Capacitance measurements can then be compared to known capacitance values, and if the difference between the two values exceeds a certain amount, the kernel controller can determine that a tampering attempt has been made. .. In another example, an attempt to tamper with is detected by scanning the components of reader 20, whether there is any discrepancy in the data stored in memory 209, whether there is an unexpected or unknown application, and so on. Or, above all, it can be determined if there is a discrepancy in the physical and logical separation of the components within the secure and non-secure areas. By rerouting the process from the local kernel on the reader to the cloud, the system may, in some circumstances, circumvent the compromised components of the reader.

FIG. 3C shows that the payment reader 20 may include a GEN 1 or GEN 2 L2 kernel that is essentially modular, i.e., different GEN 1 functions and / or different GEN 1 functions in the physical layer and / or application layer. Alternatively, an alternative embodiment in which the GEN 2 function can be separated into different logic "submodules" of the L2 kernel is shown. In other words, instead of treating the entire L2 kernel as a uniform or monolithic component that cannot be divided, its functionality can be divided into specific component parts. In this embodiment, different L2 kernel functions may be performed on different devices based on the hardware (or other) resources of the payment reader. In an exemplary embodiment, submodules 1 and 2 of the L2 kernel of the reader 20 can be variously implemented either on the reader or on a device in the cloud. FIG. 3C shows a mobile payment reader 20 with an L2 kernel submodule 1 (first submodule of the L2 kernel) 340. The L2 kernel submodule 2 (second submodule of the same L2 kernel) 342, 344, or 346 can be housed on an external device such as a mobile device 40A, PC40B, or a remote server 310. Submodules 340 and 342, 344, 346 can be directed to (target) different functions of the L2 kernel. For example, in various embodiments, any one or more of the submodules 340, 342, 344, and / or 346 is a payment reader function, eg, a selection manager (eg, processing of different elements of the payment reader). Kernel controller to direct data for), pin processing, main kernel function (eg core transaction), crypto handler, payment allow / approve / deny / inquiry processing, additional payment service processing, use cardholder information Processing non-payment services, configuration managers (eg, processing of configurations specific to country, brand, payment transaction type, etc.), risk handling, points of interaction (eg, cardholder through UI, keypad, or peripherals) / Merchant display or data entry), receipt processing, proximity protocols, processing of unauthorized transactions, timeouts or cancellations, secure channel management, and communication between various modules or devices, among other features, Can behave in various ways to perform. These are, in some examples, just general categories of features that can be implemented in one or more submodules, either as an exhaustive list or as an exact one-to-one between features and separate submodules. It will be understood that it is not intended as a response to. One of these submodules is taken as an example of the L2 kernel on the reader 20 including a submodule related to contactless payment processing and a submodule instructed to process PIN / signature / biometrics data. It may be executed on the reader 20 and one may be executed on the mobile device 40A. The above functions can be performed either by the reader itself or from an external device, but the functions associated with the communication abstraction layer (ie, between the L1 layer of the payment reader and the rest of the OSI layer). Processing communication), or some kind of low-level dialog with a contact-based payment card, usually has to be placed in the payment reader itself, and moving such features to other places is not possible. It is impractical or inefficient.

By distributing the positions of these submodules, the processing of various functions can be optimized at run time. In an exemplary scenario, certain submodules designed to handle sensitive information can be offloaded to cloud-based devices with additional security features. In another exemplary scenario, one or more submodules can be processed from a cloud-based device, otherwise computing resources will not allow the processing to be done in parallel on the reader. , Thereby completing the process more timely. In another exemplary scenario, the information required by the submodule may be stored in the cloud (ie, may be stored in a location away from the reader 20 and / or in a restricted location), and the processing may be performed. , The required data may be delegated to a kernel submodule located on a device that can be accessed more efficiently.

FIG. 3D shows an alternative embodiment in which the L1 module is divided into submodules, where the submodule of the L1 module is applied to the mechanical characteristics of the element to which the payment card or NFC-enabled device interfaces, the payment card or NFC-enabled device. It represents the electrical characteristics of the signal received from it, and one or more of the other characteristics required to operate the complete L1 module. In some embodiments, all submodules of the L1 module are housed on the payment reader 20 as well as on the payment reader itself, as well as the L1 submodules 1c (element 370) and 2c (element 372) shown in FIG. 3D. May be there. Alternatively, as shown in FIG. 3D, the L1 submodule has the submodule 1a (element 350) in the L1 layer of the reader and the payment reader 20 with the submodule 2a (element 352) in the application layer of the reader. It may be divided between the physical layer and the application layer of. In yet another alternative embodiment, the submodule 1b (element 360) is placed on the payment reader and the submodule 2b (element 356, 357, or 358) is external such as a mobile device 40A, PC 40B, or remote server 310. Can be placed on the device. The submodule 2b is a submodule of the L1 layer of the payment reader 20 and not a submodule of the L1 layer of the external device in which the submodule is located. Therefore, in the illustrated embodiment, the submodule 2b is the external device. Note that it is processed at the application layer. In other embodiments, the L1 submodules may be distributed differently.

L1 submodules that target the mechanical properties of the reader (eg, card contacts (contacts), electrical lines, active and / or passive circuits for processing signals) are generally physically readers of their function. Since it is embedded in, it will be understood that it may be implemented only in the reader itself in practicality. However, the L1 submodule, which targets other characteristics, may instead be arranged to be located either on the reader or on a device outside the reader. Table 1 below lists, for example, some of the submodule distributions that can be implemented in such embodiments.

As an example, in some implementations, only the software module / characteristic is placed as in-reader software or on an external device such as a mobile phone (L1 submodule 2a or 2b, respectively). In these embodiments, individual software components running on the reader or on an external device, for example, an electrical and mechanical configuration that regulates the voltage or test of the card contacts (contacts) (L1 submodules 1a and 1b). Drive elements / characteristics. As another example, row 4 of Table 1 shows that both the electrical and software submodules are on the mobile phone (eg, L1 submodule 2b 356, 357, or 358), or the reader's application layer (L1 submodule). Refer to the implementation placed in 2a). In this alternative embodiment, the software components running on the kernel of the external device are, for example, to adjust the voltage or an EMV contact pad or NFC coil (antenna) on the payment reader 20 (eg, an antenna). In order to drive the copper wire into the L1 submodule 1a or 1b), the electrical properties of the reader 20 can be driven (eg, via an audio / lightning jack or the like). As an example, an NFC in which a software-defined wireless application or equivalent on one of a mobile device 40A, PC40B, or remote server 310 (L1 submodule 2b) is maintained on a payment reader 20 (L1 submodule 1b). Used to control the coil. Similarly, the application layer software of the payment reader (L1 submodule 2a) can be used to control the mechanical components of the physical layer (L1 submodule 1a).

It should be appreciated that the architectures shown in FIGS. 3A-3D described above are not limited to the components described herein and may include other hardware and software components. Rather, for ease of illustration, only the components and functions most relevant to the invention are discussed herein.

FIG. 4 shows an exemplary diagram of the flow of data between the components of the reader 20 and the mobile device 40A according to one embodiment. In the example of FIG. 4, the architecture along the line of what is shown in FIG. 3B can be used as an exemplary model. This process begins at step 402, where the L1 module of the reader 20 reads card data, for example, in an NFC transaction via the non-contact antenna 250. The card data is transmitted to processor 205 (or optionally to secure processor 260) in step 404. At step 406, kernel controller 305 determines which kernel should process the payment transaction.

In the first scenario, transaction processing needs and payment information are limited to the characteristics of the GEN 1 application layer kernel. In this first scenario, the kernel controller directs the payment reader 20 to the local L2 GEN 1 kernel 304 in step 408. This process may include various steps such as signing, PIN, input of authentication data such as biometric data. After processing, the kernel 304 sends the processed payment information to the payment processing server 50, eg, the issuer server, for authentication via the communication interface 213. In another embodiment, if the reader does not have the memory or processing capacity to communicate with the payment processing server, the processed payment data will be sent to the mobile device 40A or computing device 40B via the communication interface 213. The device then transfers the data to the payment processing server 50.

In the second scenario, the transaction processing needs can only be met by the GEN 2 application layer kernel, where the payment reader 20 has the GEN 2 kernel and has the resources available to process the transaction. In this scenario, kernel controller 305 directs the payment reader 20 to the local L2 GEN 2 kernel 354 in step 408. This process can include various steps, including transactions based on gift cards in non-standard payment formats, such as payments through applications on smartphones, and / or encryption of cards and payment data. .. This process may include, for example, input of authentication data. After processing, the kernel 354 sends the processed payment information to the payment processing server 50 in step 410, or instead to the mobile device 40A or the computing device 40B, via the communication interface 213, which is: Data is transferred to the payment processing server 50.

In the third scenario. The processing needs of a transaction can only be met by the GEN 2 application layer kernel, but the payment reader 20 does not have a GEN 2 kernel and / or has available resources to process the transaction. do not have. In this scenario, kernel controller 305 in step 406 sends payment data through communication interface 213 to L2 GEN on remote server 310, mobile device 40A, or computing device 40B, respectively, outside the reader. 2 Instruct either kernel 312, 322, or 332 to process. The kernel on the selected external device handles the transaction. This process can include, for example, transactions based on gift cards for non-standard payments, such as payments by applications on smartphones, and / or various steps including encryption of cards and transaction data. This process may, for example, require input of authentication data, in which case kernel 312, 322, 332 receives such data in step 450 before processing the transaction in step 452. do. After processing, the external device sends data to the payment processing server 50 in step 454, which may include transmission of PIN, signature, or biometric data among other information.

The methods and systems described above facilitate the processing of a wide variety of payment transactions, even for payment readers who are limited in hardware resources, memory, power, or the ability to process payment transactions. Can function as. This allows merchants to provide a new life to their existing already deployed payment systems without the need for large investments in new computing resources and / or payment readers. In addition, the security and efficiency of existing payment processing solutions can be improved by creating hybrid processing systems using cloud-based resources (eg, by providing more robust cryptographic solutions). .. As a result, improvements in computing systems can be effective even if outdated hardware and other factors cannot be improved at the payment reader's own level.

In another embodiment, with reference to FIG. 5A, an additional processor that manages a secure area separate from the secure enclave 270, the non-secure (or relatively non-secure) area and other processing components within the secure enclave 270. It can be provided in the reader 20 in an area physically and logically separated from the reader. This additional secure area is referred to herein as the "trusted zone" or "trusted zone" 520, and the resources of the trusted zone processor 510 manage the trusted zone 520. That is, the security of the trust zone is managed on the chip itself. In some embodiments, the trusted zone processor 510 can maintain a bit value that specifies whether the payment reader should be in the "trusted" or "normal" state. Other embodiments are also possible. The components of the reader 20 and any data bus are notified of the bit values, which allows the processor 510 to segregate and control access to the trusted zone. As an example, the trust zone 520 can be implemented with TrustZone® technology from ARM Ltd, but other technologies can also be used. The trusted zone may include the corresponding hardware (eg, separate processing unit, memory), firmware, and software (eg, application).

In one exemplary embodiment, the kernel controller 305 dynamically determines to redirect the processing of the GEN 2 function to a separate GEN 2 kernel 354 located within the isolated trust zone 520 of the payment reader 20. be able to. The kernel controller 305 can make such a determination based on a detected event such as a tampering event. That is, upon detecting an attempted tampering, the kernel controller 305 instead performs processing of the GEN 2 function (which may otherwise be performed by the GEN 2 kernel 354 in the secure enclave 270) in the trust zone 520. It may be rerouted to be performed by the GEN 2 kernel 524. In another implementation, the trust zone may be associated with a dedicated Android processor (eg, a chip) running on the payment reader, i.e. the trust zone may be, for example, additional tamper-related functionality. Implemented by Android OS, which may have security features.

In another exemplary architecture, the payment system 1 further includes a mobile device 511, such as an Android smartphone, configured to act as an ECR. In the exemplary embodiment shown in FIG. 5B, device 511 manages a trust zone 520 for processing various functions of the Android OS and having an L1 module 522 and an L2 kernel 524 dedicated to processing payment transactions. A mobile device with an Android processor 517 for use. The security needs of the GEN 2 process are not met by the GEN 2 kernel on the reader 20 (eg, attempts to tamper with the reader are detected), or the resources available to the reader 20 to process security intensive transactions. In a non-existent scenario, kernel controller 305 can transmit GEN2 data processed by GEN2 kernel 524 in the isolated trusted zone 520 of ECR511 (as shown by the dashed line in FIG. 5B). In various embodiments, the kernel controller 305 can send GEN 2 data to the mobile device 40A, which determines that the data should be processed in the trusted zone and puts the data in the trusted zone 520. Send to GEN 2 kernel 524 (shown by dotted line in Figure 5B). In yet another alternative architecture (not specifically shown), the ECR 511 (eg, on an Android phone) replaces the payment reader 20 instead of the stand-alone payment reader 20, and the ECR is in its trust zone. Process GEN 2 payment information locally with the appropriate kernel of.

The use of trust zones can have several advantages over other hybrid systems with secure enclaves. First, the trust zone is implemented in a preferred embodiment via code that is executed natively so that the code has direct access to peripheral hardware. Therefore, the implementation of trusted zones is more efficient and may require access to, for example, the operating system / compatibility layer, or require additional Java compilation to perform the same behavior. May be processed faster than a solution with code that runs on a Java layer or main processor. In addition, the concept of trust zones is generally implemented in ARM-based architectures (eg, some Android phones), so no separate secure chip is required, thereby reducing manufacturing costs. .. In addition, trust zones are typically implemented on several public CPU architectures, so security is well tested and could result in a more secure system with more defense settings built-in. be.

Illustrative clause

1. 1. A mobile communication device, a communication interface for communicating with a first type payment reader and a second type payment reader, each of the second type payment readers of the second type. It has a second generation Layer 2 (L2) kernel for processing payment information from payment devices, and each of the first type payment readers is for processing payment information from first generation payment devices. A communication interface having a first generation L2 kernel and, when executed by at least one processor, having the at least one processor receive the processed second type of payment information and said the processed first. The second type of payment information is processed by the second generation L2 kernel of the second type of payment reader for approval of payment transactions based on the processed second type of payment information. , The processed second type of payment information is sent to one or more payment servers, and the first type of payment information processed by the first generation L2 kernel of the first type payment reader. Received and sent the first type of payment information to one or more payment servers for approval of payment transactions based on the first type of payment information, raw from the first type of payment reader. (Raw) second type of payment information is received and the raw second type of payment information is used to process the raw second type of payment information of the second generation of mobile communication devices. Payment based on the raw second type of payment information sent to the L2 kernel and processed by the second generation L2 kernel of the mobile communication device. A mobile communication device, including said at least one processor programmed by an instruction, which is sent to one or more payment servers for approval of a transaction.

2. 2. Further comprising an interface configured to receive contactless payments directly from the payment device, wherein the interface receives contactless payments using the second generation L2 kernel of the mobile communication device, in Section 1. The mobile communication device described.

3. 3. The mobile communication device according to Section 1, wherein the second generation L2 kernel of the mobile communication device has a larger processing capacity than the first generation L2 kernel.

4. The mobile communication device according to Section 1, wherein the raw second type of payment information includes authentication information related to a payment transaction.

5. The mobile communication device receives unprocessed second type payment information from the second generation L2 kernel of the second type payment reader and receives the unprocessed second type payment information. The mobile communication device according to section 1, further configured to provide to the second generation L2 kernel of the mobile communication device to process unprocessed second type of payment information.

6. The mobile communication device according to Section 5, wherein the second generation L2 kernel of the second type payment reader is functionally identical to the second generation L2 kernel of the mobile communication device.

7. The mobile communication device according to Section 1, wherein the mobile communication device is a mobile phone.

8. The mobile communication device receives payment information from a first-type payment reader or a second-type payment reader, wherein the first-type payment reader pays from a first-type payment device. It has a first generation L2 kernel for processing information, said second type payment reader is a second generation layer 2 (L2) for processing payment information from a second type payment device. A second type of processed payment that has a kernel and has been processed by the mobile communication device and the received payment information has been processed by the second generation L2 kernel of the second type payment reader. In the case of payment information, sending the processed second type of payment information to one or more payment servers for approval of payment transactions based on the processed second type of payment information. And if the received payment information by the mobile communication device is the first type of payment information processed by the first generation L2 kernel of the first type payment reader, the first type of payment information. Sending the first type of payment information to one or more payment servers and the received payment information being the first type of payment for approval of a payment transaction based on the type of payment information. If it is a raw second type of payment information from a reader, (a) the mobile communication device processes the raw second type of payment information and the raw second type of payment information. To the second generation L2 kernel of the mobile communication device for the purpose of (b) the raw second type processed by the mobile communication device by the second generation L2 kernel of the mobile communication device. A method comprising transmitting payment information to one or more payment servers for approval of payment transactions based on said raw second type of payment information transmitted.

9. 8. The method of Section 8, further comprising receiving contactless payments from a payment device using the second generation L2 kernel of the mobile communication device.

10. 8. The method of Section 8, wherein the second generation L2 kernel of the mobile communication device has greater processing power than the first generation L2 kernel of the first type payment reader.

11. The method of Section 9, wherein the raw second type of payment information includes authentication information related to the payment transaction.

12. To receive unprocessed second type payment information from the second generation L2 kernel of the second type payment reader and to process the unprocessed second type payment information. 8. The method of Section 8, further comprising providing unprocessed second type of payment information to the second generation L2 kernel of the mobile communication device.

13. 8. The method of Section 8, wherein the second generation L2 kernel of the second type payment reader is functionally identical to the second generation L2 kernel of the mobile communication device.

14. The method according to Section 8, wherein the mobile communication device is a mobile phone.

15. When executed by one or more processors of a mobile communication device, one or more processing units receive payment information from a first payment reader or a second payment reader external to the mobile communication device. The first payment reader has a first generation L2 kernel configured to process the first type of payment information, and the second payment reader has the first type of payment information. Receiving and having the received payment information having a second generation Layer 2 (L2) kernel configured to process a second type of payment different from that of the second type of payment. For approval of payment transactions based on the received payment information, if it contains information and the received payment information is processed by the second generation L2 kernel of the second payment reader. , The received payment information is transmitted to one or more payment servers, the received payment information includes the first type of payment information, and the received payment information is said first. When processed by the first generation L2 kernel of a payment reader, it sends the received payment information to one or more payment servers for approval of payment transactions based on the received payment information. (A) The said, when the received payment information includes the second type of payment information and the received payment information is received from the first payment reader without processing. The processed payment is processed using the second generation L2 kernel of the mobile communication device to process the received payment information and (b) approve the payment transaction based on the processed payment information. A non-temporary computer-readable storage medium containing instructions to perform an operation, including sending information to one or more payment servers.

16. Execution of the instruction further causes the one or more processing units to perform operations including receiving contactless payments from the payment device using the second generation L2 kernel of the mobile communication device. 15. The non-temporary computer-readable storage medium according to 15.

17. The non-temporary computer-readable storage medium according to section 15, wherein the second generation L2 kernel of the mobile communication device has greater processing power than the first generation L2 kernel of the first payment reader.

18. The non-temporary computer-readable storage medium according to section 15, wherein the received payment information includes authentication information related to the payment transaction.

19. Execution of the instruction is to receive the unprocessed payment information from the second generation L2 kernel of the second payment reader to the one or more processing units, wherein the unprocessed payment information is. The unprocessed payment information is provided to the second generation L2 kernel of the mobile communication device in order to receive and process the unprocessed payment information, including the second type of payment information. The non-temporary computer-readable storage medium according to section 15, which further performs an operation including that.

20. The non-temporary computer-readable storage medium according to section 15, wherein the second generation L2 kernel of the second payment reader is functionally identical to the second generation L2 kernel of the mobile communication device.

A point-of-sale information management (POS) system that is a payment reader with 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 is 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 an external device of the payment reader, the device having a second module of the L2 kernel, the payment application being the payment processed by the first module of the L2 kernel. A POS system comprising a device configured to send information to the device for processing by the second module of the L2 kernel.

22. Section 21 is the POS system of the device, which is configured to send the payment information to one or more payment servers after the payment information has been processed by the second module of the L2 kernel.

23. The POS system according to section 21, wherein the processing by the second module of the L2 kernel relates to authentication of payment transactions.

24. The payment information includes a first payment information and a second payment information, the first module of the L2 kernel is configured to process the first payment information, and the first of the L2 kernel. 2. The POS system according to section 21, wherein the module 2 is configured to process the second payment information.

25. A point-of-sale (POS) system, a payment device having a payment application, a layer 2 (L2) kernel, and a first submodule of a layer 1 (L1) module, the first of the L1 modules. Submodule of is configured to receive payment information from a payment object, the payment application from said first submodule of said L1 module for processing said payment information by said L2 kernel. A payment device configured to provide the payment information to the L2 kernel and a physical interface configured to be a payment reader connected to the payment device and read payment information from the payment object. A payment reader having a second submodule of the L1 module, wherein the payment reader is configured to transmit the payment information read from the payment object to the first submodule of the L1 module. A POS system with a payment reader.

26. 25. The POS system of section 25, wherein the payment device is a mobile phone external to the payment reader, the payment reader being communicably connected to the mobile phone.

27. The POS system according to Section 25, wherein the second submodule of the L1 module relates to the mechanical function of the payment reader.

28. The POS system according to section 27, wherein the mechanical function of the payment reader relates to one or more of adjusting the voltage level of the payment reader and performing contact with the payment object.

29. The POS system according to Section 25, wherein the first submodule of the L1 module relates to the control of software functions of the payment reader.

30. The POS system according to Section 25, wherein the first submodule of the L1 module relates to the control of the electrical function of the payment reader.

31. The electrical function of the payment reader relates to driving an electrical connection between the wire and the payment interface of the payment reader, the payment interface being one or more of an EMV contact pad or an NFC coil. The POS system according to section 30.

32. It comprises an interface configured to receive payment information from a payment object, a payment application, a first module of the kernel, and a wireless communication interface capable of communicating with devices other than the payment device. It comprises a second module of the kernel and 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. , Payment device.
33. The payment application receives the processed payment information from the device via the wireless communication interface, the processed payment information is processed by the second module, and the processed payment information is used. The payment device according to section 32, further configured to send to one or more payment servers.

34. The payment application further sends the processed payment information to the first module of the kernel to be processed before sending the processed payment information to the one or more payment servers. The payment device according to section 33, which is configured.

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

36. A method of receiving payment information from a payment object by a payment device and processing the payment information by the payment device by the first module, the payment information in the first module of the kernel. The first module is installed in the payment device, the transmission and the payment information processed by the first module by the payment device to the second. A method comprising sending to a second module of the kernel for processing by the module, wherein the second module is installed in a device external to the paying device. ..

The above is merely an example of the principles of the present disclosure, and various modifications can be made by those skilled in the art without departing from the scope of the present disclosure. The above embodiments are presented for illustrative purposes only and not for limited purposes. The disclosure may also take many forms other than those expressly described herein. Accordingly, this disclosure is not limited to the methods, systems, and devices explicitly disclosed, and is intended to include modifications and modifications thereof, which are within the spirit of the following claims. Be emphasized.

As a further example, modifications of equipment or processing parameters (eg, dimensions, configurations, components, processing step sequences, etc.) are made to provide structures, devices, and as described herein. The method can be further optimized. In any case, the structures and devices described herein, as well as related methods, have many uses. Accordingly, the subject matter disclosed should not be limited to any single embodiment described herein, but rather should be construed in the breadth and scope of the appended claims. ..

Claims (13)

A point-of-sale (POS) system
A payment reader with a payment application, a layer 1 (L1) module for receiving payment information from a payment card, and a first layer 2 (L2) kernel.
A mobile device that is external to the payment reader and has a second L2 kernel.
The payment application dynamically determines whether the first L2 kernel or the second L2 kernel on the mobile device should process the payment information based on the terms of the payment reader. Is configured to
The payment application sends unprocessed payment information to the first L2 kernel of the payment reader for processing when it is determined that the first L2 kernel should process the payment information. Is configured to
The payment application processes the unprocessed payment information into the second L2 kernel of the mobile device when it is determined that the second L2 kernel should process the payment information. A POS system that is configured to send. The payment application transfers the payment information processed by the first L2 kernel of the payment reader to the mobile device when it is determined that the first L2 kernel should process the payment information. The POS system according to claim 1, further configured to transmit to said second L2 kernel. The conditions of the payment reader are (a) the detected power level of the battery of the payment reader, (b) the detected power level of the battery of the device outside the payment reader, and (c) the payment reader. The POS system of claim 1, relating to one of the relative power levels between the device and the device external to the payment reader. The conditions of the payment reader relate to the occurrence of a low power event and
The low power event is (a) the detected power level of the battery of the payment reader below a predetermined threshold, (b) the detected power level of the battery of the payment reader and the payment reader. The difference between the detected power level of the battery of the external mobile device is greater than the predetermined difference, or (c) the detected power level of the battery of the pay reader is below a predetermined threshold. And claim 3, it is determined to occur when any of the detected power levels of the battery of the mobile device outside the payment reader exceeds a predetermined threshold is true. POS system. The POS system of claim 1, wherein the condition of the payment reader relates to a version number of the first L2 kernel of the payment reader. The POS system of claim 1, wherein the condition of the payment reader relates to detection of a potential tampering attempt at the payment reader. Being a payment leader
A layer 1 (L1) module for receiving payment information from payment devices,
A wireless communication interface configured to transmit information from the payment reader to a network device having a second layer (L2) kernel.
According to the determination made by the kernel director related to the conditions of the L1 module, it is configured to instruct the L1 module to transmit the payment information to the second L2 kernel via the wireless communication interface. With the kernel director
A payment reader. The payment reader of claim 7, wherein 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 network device. The payment reader according to claim 7, wherein the determination related to the condition of the L1 module is a determination that the payment information cannot be processed by the L1 module. The payment reader according to claim 7, wherein the determination regarding the conditions of the L1 module is a determination that the processing capacity of the payment processing device is insufficient to process the payment information. It ’s a system,
With payment devices,
A payment application, a first Layer 2 (L2) kernel in a first processor, a second L2 kernel in a second processor, and a payment reader with an L1 (L1) module in a third processor. The L1 module is for receiving payment information from the payment device.
The second L2 kernel is in the trust zone of the second processor.
The payment application dynamically selects one of the first L2 kernel and the second L2 kernel to process the payment information based on the event data and selects the payment information. It is configured to provide to the L2 kernel that has been
The payment application is configured to select the first L2 kernel to process the payment information if the event data indicates a first condition.
The POS application is configured to select the second L2 kernel to process the payment information if the event data indicates a second condition. The system according to claim 11, wherein the event data indicates a second condition when a tampering event is suspected for the first L2 kernel. 11. The system of claim 11, wherein the first processor is in a secure payment enclave (SPE) of the payment reader.

Images