AU2024202020A1 - Point of sale (pos) systems and methods with dynamic kernel selection - Google Patents
Point of sale (pos) systems and methods with dynamic kernel selection Download PDFInfo
- Publication number
- AU2024202020A1 AU2024202020A1 AU2024202020A AU2024202020A AU2024202020A1 AU 2024202020 A1 AU2024202020 A1 AU 2024202020A1 AU 2024202020 A AU2024202020 A AU 2024202020A AU 2024202020 A AU2024202020 A AU 2024202020A AU 2024202020 A1 AU2024202020 A1 AU 2024202020A1
- Authority
- AU
- Australia
- Prior art keywords
- payment
- reader
- kernel
- information
- processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 52
- 238000012545 processing Methods 0.000 claims abstract description 148
- 230000006870 function Effects 0.000 claims abstract description 58
- 238000005259 measurement Methods 0.000 claims abstract description 10
- 238000004891 communication Methods 0.000 claims description 34
- 238000001514 detection method Methods 0.000 claims description 5
- 230000005540 biological transmission Effects 0.000 claims description 4
- 230000008569 process Effects 0.000 abstract description 29
- 238000005496 tempering Methods 0.000 abstract 1
- 238000010295 mobile communication Methods 0.000 description 29
- 238000003860 storage Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 7
- 230000003993 interaction Effects 0.000 description 6
- 238000013475 authorization Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000001419 dependent effect Effects 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000007613 environmental effect Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000005226 mechanical processes and functions Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000001939 inductive effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/0873—Details of the card reader
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/0009—Details of the software in the checkout register, electronic cash register [ECR] or point of sale terminal [POS]
Abstract
A payment reader can have one or more kernels capable of performing certain payment
processing functions but not capable of performing certain, more processing-intensive payment
processing functions. The payment reader may be designed to selectively assign processing
tasks to application layer kernels located on a mobile device and/or a cloud-based device
external to the payment reader, the mobile device having more or different processing
resources than the payment reader. The selective assignment may be made dynamically based
on the measurement of a condition of the reader or an occurrence of an event, such as a
determination that the payment reader cannot process a transaction, that the payment reader
does not have sufficient battery strength to process the transaction, or that there has been a
tempering attempt at the payment reader. The payment reader also has a physical layer
module, which maintains its processing on the payment reader. By these means, the
processing related to a payment transaction is conducted on a hybrid system, using resources
both local to and remote from the payment reader.
Description
[0001] This application is a divisional application of Australian Patent Application No.
2023201736 filed on 21 March 2023, which is a divisional application of Australian Patent
Application No. 2019405995 filed on 20 December 2019, which is the Australian National Phase
Application of PCT/US2019/067907 filed on 20 December 2019, which claims the benefit of US
Patent Application No. 16/231,030 filed on 21 December 2018, of US Patent Application No.
16/230,940 filed on 21 December 2018 and of US Patent Application No. 16/230,823 filed on
21 December 2018, the disclosures of which are incorporated herein by reference in their
entirety.
[0002] Consumers can interact with a merchant's payment reader to transact electronic
payments in a variety of ways, for example, a payment card having a magnetic strip that is
swiped in a magnetic reader of the payment reader, a payment device having a
Europay/MasterCard/Visa (EMV) chip that is inserted into a corresponding EMV slot of the
payment reader, and near field communication (NFC) enabled devices such as a smart phone
or EMV card that is tapped at the payment reader and that transmits payment information over a
secure wireless connection. The payment reader may receive payment information as well as
information about a payment transaction from the payment device, and may communicate such
payment information to a payment system for processing and/or authorization of the transaction.
Payment readers capable of facilitating such transactions may take a variety of forms, including
a standalone mobile device.
[0003] Mobile payment readers have existed on the market for several years. However,
as functionalities related to payment processing increase in variety and complexity, that is, as a consumer's options for payment grow, the processing requirements for a payment reader may outgrow the capabilities of the existing hardware that is already in the market. In some cases, the hardware of an early (or earlier)-generation payment reader that is in use by merchants may be unable to meet the processing demands of more modern payment transactions. In other cases, payment readers that are in use by merchants may be unable to process modern payment transactions because the readers lack sufficient power resources, or are not updated with the required software. In still other cases, payment readers that are in use by merchants may be physically capable of processing a payment transaction but may, due to environmental or security conditions, be unable or unwilling to do so at the particular time or under the particular circumstances requested by a consumer.
[0004] Therefore, solutions are generally desired that more optimally utilize processing
and/or power resources on a payment reader, prevent processing by obsolete, less efficient, or
undesired software versions, and otherwise enhance data security during payment processing.
[0005] The above and other features of the present disclosure, its nature and various
advantages will be more apparent upon consideration of the following detailed description,
taken in conjunction with the accompanying drawings in which:
[0006] FIG. 1 depicts a block diagram of a payment system in accordance with some
embodiments of the present disclosure.
[0007] FIGS. 2A and 2B depict block diagrams of payment readers in accordance with
some embodiments of the present disclosure.
[0008] FIGS. 3A, 3B, 3C, and 3D depict block diagrams of various payment service
systems in accordance with some embodiments of the present disclosure.
[0009] FIG. 4 depicts a flow chart illustrating exemplary steps for payment processing in
accordance with some embodiments of the present disclosure.
[0010] FIGs. 5A and 5B depict block diagrams of payment service systems in
accordance with some embodiments of the present disclosure.
[0011] A payment reader can be used to process payment information by acquiring
payment information from a payment interface, encrypting the acquired payment information,
and/or performing payment processing according to payment processing protocols for exchange
of information with a payment server. A payment reader may have one or more processors that
include dedicated kernels for payment processing, providing various functionalities relating to
respective abstraction layers of the payment reader. For example, a module relating to
functionalities of a first, physical layer may control interactions with devices capable of receiving
information from a payment card, such as an NFC interface. A kernel relating to functionalities
of a second, application layer may address other tasks, such as, e.g., the processing of a
payment transaction, encryption within a secure payment enclave of the terminal, and/or
transmission of the payment information to a payment server for approval, among others.
Generally, a physical layer is referred to herein as a "first layer" or "L." While an application
layer may generally, in the context of the OSI model, be referred to as "Layer 7" or"L7,"
application layer components may also be referred to herein as a "second layer" or"L2"
components, for ease of comparison with the term "Li." In this regard, it will be understood that
in different embodiments, Liand L2 may refer to different OSI layers than the physical layer
and the application layer, and the concepts of the systems and methods described herein can
be similarly applied thereto.
[0012] A payment reader may contain one or more processing units, which may provide
different processing capabilities. For example, older models of a payment reader may have
been designed to work with a first generation of kernel that is dependent on a first, limited set of
hardware resources, whereas newer models of a payment reader may have been designed with a second generation of kernel that provides a suite of functions beyond those of the first generation kernel, but in turn requires a greater amount of memory and hardware resources than the first generation. For ease of reference, kernels providing a first, limited set of processing functionality are referred to herein as "Generation 1" or "GEN 1" kernels, whereas kernels providing a second, more robust set of processing functionality are referred to herein as
"Generation 2" or "GEN 2" kernels.
[0013] In one embodiment, a merchant may be in possession of a payment reader with
a GEN 1 kernel that is incapable of performing a function or handling information specific to the
GEN 2 processor (i.e., a "GEN 2 function"). In a preferred embodiment, the payment reader
contains a kernel controller (also referred to as a "kernel director") that recognizes that the
payment reader may not have the hardware or software resources required to perform a GEN 2
function. In response to that recognition, the kernel director instead controls the payment
reader to assign performance of that function to an external device such as a mobile device
(e.g., a mobile phone or tablet) or a remote server that has the requisite GEN 2 kernel and
resources. In a preferred embodiment, the kernel controller may be located in a processor,
however, it may alternately be implemented as separate circuitry (or as any combination of
hardware and software) in the payment reader. In yet another embodiment, the kernel
controller may be implemented on a separate device to control functionality on the payment
reader.
[0014] In another embodiment, a payment reader may have a GEN 2 kernel, but may
nonetheless decide to direct processing of the GEN 2 function to a kernel of an external device
because the payment reader is otherwise resource limited, for example, due to a need to
conserve power at the reader. In another alternative embodiment, the payment reader may
have a GEN 2 kernel, but may direct processing of the GEN 2 function to a GEN 2 kernel of an
external device that is differently versioned than the GEN 2 kernel on the reader, for example, in
a case where the particular GEN 2 function is more efficiently or preferably performed on the differently versioned software. In yet another embodiment, the payment reader may have a
GEN 2 kernel, but may direct processing of the GEN 2 function to a kernel of the external device
because the payment reader has recognized a security threat to the reader (e.g., a tampering
attempt). For ease of reference, processing by a kernel that is not local to the payment reader
(regardless of the location of the device doing the processing and/or whether the device is
physically connected to the payment reader) may be referred to herein as processing "in the
cloud."
[0015] In another embodiment, rather than offload the processing of the GEN 2 function
to an external device, the processing is instead performed in an isolated secured area (such as
a "trust zone") managed by a separate processor of the payment reader or of a device acting as
an embedded card reader (ECR).
[0016] In another embodiment, a kernel may be modular in nature, where different GEN
1 and/or GEN 2 functionalities at the application layer may be separated into different logical
"submodules" of the kernel. In this embodiment, different kernel functions can be performed at
different respective devices based on the hardware resources of the payment reader, among
other constraints.
[0017] FIG. 1 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 alternate computing device (such as a mobile device or PC) 40, and a
payment server 50. In an exemplary embodiment, payment server 50 may include a plurality of
servers operated by different entities, such as a payment service system or a bank server. The
components of payment system 1 facilitate electronic payment transactions between a
merchant and a customer.
[00181 The electronic interactions between the merchant and the customer take 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 a standalone mobile hardware device,
though it is not so limited. For example, in other embodiments, the payment reader 20 may be
a mobile device, such as a smart phone (iOS or Android) or another computing device that is
configured to act as an embedded card reader (ECR). In one embodiment, payment device 10
may be a device that is capable of communicating with payment reader 20, such as a credit
card having magnetic strip, a credit card having an EMV chip, or a 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 the payment reader 20,
generating encrypted payment information, and providing the encrypted payment information as
well as other payment or transaction information in accordance with one or more electronic
payment standards such as those promulgated by EMVCo. The payment reader 20 is capable
of executing a payment application (which may be, in some embodiments, a point-of-sale
application or an application providing a portion of the functionality thereof) and includes at least
one interface for receiving payment information from the payment device 10. The payment
reader 20 can be capable of receiving and processing payment information through contact with
the card or contactless interfaces and collecting payment information, including transaction
information (e.g., purchase amount and point-of-purchase information) and card information
(e.g., encrypted payment card data and user authentication data).
[0019] In some embodiments, the merchant may also have one or more mobile devices
(or stationary computing devices) 40. These devices may in some embodiments provide
additional functions, so as to, in correspondence with the payment reader's application, create,
complete, supplement, or augment a comprehensive point-of-sale system implemented by the
merchant. In some embodiments, one or more of the mobile devices 40 may provide a POS
application wholly separate from the payment application executed on the payment reader 20.
The devices 40 may be, for instance, a mobile phone such an iPhone or Android device, an
iPad or tablet device, a laptop or touchscreen device, or a PC or stationary computing device,
though any practical device that can communicate with the payment reader may be appropriate.
[0020] The payment reader 20, and/or, in some embodiments, any of the merchant
devices 40, may communicate with payment server 50 over a communication network 30.
Although communication network 30 may be any suitable communication network, in one
embodiment, communication network 30 may be the Internet and payment and transaction
information may be communicated between payment reader 20 and payment server 50 in an
encrypted format such by a transport layer security (TLS) or secure socket layer (SSL) protocol.
In addition, when the network 30 is the Internet, the payment reader 20 may use the
transmission control protocol/Internet protocol (TCP/IP) for communication.
[0021] Although payment server 50 may be operated by a single entity, in one
embodiment, payment server 50 may include any suitable number of servers operated by any
suitable entities, such as a payment service system and one or more banks of the merchant and
customer (e.g., a bank server) or a card issuer. The payment reader 20 and the payment server
communicate payment and transaction information to determine whether the transaction is
authorized. For example, payment reader 20 may provide encrypted payment data, user
authentication data, purchase amount information, and point-of-purchase information to
payment server 50 over network 30. Payment server 50 may determine whether the transaction
is authorized based on this received information as well as information relating to customer or
merchant accounts, and respond to payment reader 20 over network 30 to indicate whether or
not the payment transaction is authorized. Payment server 50 may also transmit additional
information such as transaction identifiers to payment reader 20.
[0022] Based on the information that is received at payment reader 20 from payment
server 50, the merchant may indicate to the customer whether the transaction has been
approved. In some embodiments such as a chip card payment device, approval may be indicated at the payment reader 20, for example, at a screen of a payment reader 20. In other embodiments such as a mobile phone or smart device operating as a NFC payment device, information about the approved transaction and additional information (e.g., receipts, special offers, coupons, or loyalty program information) may be provided to the NFC payment device for display at a screen of the smart phone or watch or stored in memory.
[0023] As previously mentioned, the payment reader 20, alone or together with the
devices 40, can have a payment application that may provide for the entry of purchase and
payment information, interaction with a customer, and communications with a payment server
50. For example, a payment application may provide a menu of services that a merchant is
able to select and a series of menus or screens for automating a transaction. A payment
application may also facilitate the entry of customer authentication information such as
signatures, PIN numbers, or biometric information.
[0024] FIG. 2A illustrates an example schematic diagram of components of an
exemplary payment reader 20 in accordance with an embodiment. The device may include a
multi-core processor 205 or equivalent. In some embodiments, payment reader 20 may have
another type of suitable processor and may include hardware, software, memory, and circuitry
(or any combination thereof) as is necessary to perform and control the functions of payment
reader 20. In some embodiments, payment reader 20 may have multiple independent
processing units, for example a multi-core processor or other similar component. In a preferred
embodiment, the processor may have one or more dedicated kernels for performing different
functions related to payment processing.
[0025] The processor may execute instructions stored in a memory 209 to control the
operations of payment reader 20. As used herein, memory may refer to any suitable storage
medium such as disks, thumb drives, etc., both volatile and non-volatile. Examples of such
media include RAM, ROM, EPROM, EEPROM, SRAM, flash memory, disks or optical storage, magnetic storage, or any other tangible or non-transitory medium that stores information that is accessible by a processor.
[0026] 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 may also include a battery 207. As an alternate to a battery, one or more power
supplies such as a physical connection to AC power or DC power (including power conversion
circuitry) may be used. Battery 207 may be charged via a physical power connection, via
inductive charging, or via 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 a variety of voltages to the components of the payment reader 20 in
accordance with the requirements of those components.
[0027] A plurality of payment interfaces may be connected to corresponding ports or
terminals on the processor 205. The processor 205 receives inputs from the Magnetic Stripe
Reader (MSR) 232 which are read by a magnetic head reader 230. In some embodiments, the
MSR device 230, 232 may include a slot that guides a customer to swipe or dip the magnetized
strip of the card so as to collect payment information. The received payment information can
then be provided to the processor 205 for processing. Inputs are also received from EMV
contact 240 (chip card) and processed by an EMV contact block 242. The chip card may have
contacts that engage and physically interface with corresponding contacts to contact pins of
EMV interface 240. EMV interface 240 provides power and communications to an EMV chip of
the chip card according to EMV specifications. This data may be processed by an EMV contact
block 242 and provided to the processor 205.
[0028] Inputs from a contactless interface are received from an NFC contactless
antenna 250 and processed by the NFC contactless block 252. The contactless antenna 250 is
configured to receive input 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 can include circuitry for NFC communications such as electromagnetic compatibility (EMC) circuitry, matching circuitry, modulation circuitry, and measurement circuitry.
Based on a signal provided by the processor 205, the antenna 250 may output either a carrier
signal or a modulated signal. A carrier signal may be a signal having a fixed frequency such as
13.56 MHZ. A modulated signal may be a modulated version of the carrier signal according to a
modulation procedure such as ISO 14443 and ISO 18092. When the payment reader 20 is
inductively coupled to a 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 payment device 10, the wireless carrier signal is modified at
both the payment device 10 and payment reader 20, resulting in a modulated wireless carrier
signal. In this manner, the payment device 10 is capable of sending modulated data to payment
reader 20, which data may be sensed by the antenna 250 and provided to the processor 205 for
processing. In the preferred embodiment, the above-described contact and contactless
interfaces can be combined into a single payment device that can provide all of the above
functionalities.
[0029] FIG. 2B illustrates an embodiment similar to that of FIG. 2A, where there are
additional components, a secure processor 260 and memory 265 separate from the processor
205 and memory 209, that are located in a secure area or secure enclave 270 of the reader 20.
The secure area can include hardware (e.g., processing units, memory), firmware, and/or
software (e.g., applications) that is physically and logically isolated from the non-secure area.
The secure area may be used for receiving, handling, and/or storing secure data that enters the
payment reader, and for performing functions dependent on such secure data and components,
such as encryption.
[0030] It will be understood that the architecture described above and illustrated in FIG.
2A and FIG. 2B is not limited to the components discussed herein, and may include other hardware and software components. Rather, for ease of illustration, only the components and functionalities most relevant to the subject inventions are discussed herein.
[0031] FIG. 3A illustrates an architecture wherein various kernels dedicated to payment
processing functions are located in respective devices in the payment system. A merchant
system 300 including a payment reader 20 is illustrated as being divided into a physical layer
(L1) containing a module and an application layer (L2) with one or more 1st generation (GEN 1)
kernels each dedicated to different payment functions. In the preferred embodiment, the L
module 302 may include hardware components that control the interactions with the interfaces
(such as an NFC interface) capable of receiving information from a payment card, and
transferring that information to other components of the payment reader. In some
embodiments, the Li module may be capable of performing other physical layer functions (e.g.,
error correction) relating 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
this plurality of GEN 1 kernels may correspond, for example, to a basic type of transaction for
contactless payment processing. In this regard, each one of a plurality of GEN 1 L2 kernels
may be dedicated, for example, to a respective one of MasterCard (MC), VISA, JCB, CUP, and
other transaction types.
[0032] In the embodiment of FIG. 3A, payment reader 20 has limited hardware
resources. For example, payment reader 20 may have older or outdated chip technology that is
incapable of providing the processing power to perform certain payment processing functions.
These additional functions that are out of reach of the GEN 1 kernels may be referred to herein
as "GEN 2 functions," that is, functions with a processor requirement beyond the capabilities of
the GEN 1 kernels but within the capabilities of GEN 2 kernels, 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, an L2 GEN 2 kernel may provide a variety of
functions inaccessible to the GEN 1 kernel, such as encryption. To illustrate, the security of elliptic-curve cryptography (ECC) (applicable for, e.g., encryption, key agreement, digital signatures, and other tasks) is dependent upon the ability of a device to perform an intensive computation at a relatively fast speed. Such computation-heavy tasks may not be achievable within the constraints of outdated hardware, even if such hardware is otherwise still functional.
Alternatively or additionally, the feature set available on an L2 kernel may be bigger (or
different) than that of Li module, the feature set available on a GEN 2 kernel as compared to
GEN 1 being bigger still. Because of this, memory limitations may exist on dated devices,
further limiting or prohibiting processing-intensive tasks.
[0033] Fig. 3A illustrates several devices external to the payment reader 20 that are
capable of processing a GEN 2 transaction. In the illustrated example, each of mobile device
A (which may include, for example, a mobile phone, such as iPhone or Android, an iPad or
other tablet, a laptop or touch-screen computer, or any other suitable device), computing device
B (which may be, for example, a personal computer), and remote server 310 have a GEN 2
L2 kernel. It will be understood that any number of external devices may be available for use,
given the particular architectures of the merchant system and the payment system. Mobile
device 40A and computing device 40B are both illustrated as part of merchant system
(merchant devices 300), that is, the merchant in control of the payment reader 20 is also in
control of the mobile device 40A and/or the computing device 40B, though they are not so
limited. Therefore, in this embodiment, while devices 40A and 40B are external to the payment
reader 20, they are not necessarily located in a remote geographic location.
[0034] Payment reader 20 may also include payment application or payment software
301. The payment application 301 may in some embodiments include features that make up all
or a part of a point-of-sale (POS) application, or payment functionalities related thereto. When
executed by the processor 205, the payment application 301 may, in some embodiments,
provide a display with an interactive interface that allows a merchant to process payment
transactions with customers. These instructions may include customized interfaces that allow the merchant or customer to select products for purchase, calculate sales tax, process tips, provide receipts, generate discounts or special offers, process customer loyalty programs, search for items in inventory or for delivery, and/or perform any other suitable retail operations.
Further, at an appropriate time within the transaction process, the payment application 301 may
send a message to one or more payment interfaces to permit the payment reader 20 to receive
payment information from a payment device 10. In an alternate embodiment, the payment
application 301 may be executed from a device external to the payment reader 20, such as the
mobile device 40A (a smartphone), or any other practical implementation. Such implementation
may be preferred, for example, where 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, e.g., the capability for user input) while other elements may be executed from a
different device.
[0035] Fig. 3A also illustrates a payment processing server 50 that is a remote server
capable of authorization of a payment. The payment server 50 may include a plurality of
servers operated by different entities, such as a payment service system or a bank server.
Each of mobile device 40A, computing device 40B, remote server 310, and payment reader 20
are variously capable of communication with the payment processing server 50.
[0036] In a first embodiment, the payment reader contains a kernel controller 305 that
dynamically selects or determines the dedicated kernel to which particular transaction data
should be directed for processing. The kernel controller 305 may 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 may
be part of the payment application 301. In yet another example, the functions of the kernel
controller may be otherwise performed by one or more components of the processor 205.
[0037] In the embodiment shown in FIG. 3A, the Li 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 of the payment transaction requires a functionality that may be implemented by a GEN 2 kernel, but that may not be implemented by either of the L2 GEN 1 kernels 304 and 306. Because it has been determined that the reader does not have the hardware resources to perform the required GEN 2 function, the kernel controller 305 instead controls to assign performance of that function to a GEN 2 kernel external to the reader, such as those of mobile device 40A, PC 40B, or remote server 310 (regardless of whether or not the device doing the processing is external to the merchant system 300), any of which may have the requisite GEN 2 kernel and sufficient hardware resources.
[0038] In an alternate embodiment, it may be possible for contactless program software
(e.g., NFC software) in a customer's mobile payment device 10 to itself initiate a call to a kernel
or module in the payment reader 20. For example, using the NFC antenna, the NFC software in
payment device 10 may call to the Li module 302, to an application layer kernel 304 or 306, or
to the kernel controller 305 which may determine which kernel to use and which may direct the
NFC software to call to that selected kernel.
[0039] This distribution of different kernel functionalities locally and to resources in the
cloud may be thought of as a "hybrid" distribution or assignment of kernels. For example, in the
hybrid implementation illustrated in FIG. 3A, the GEN 1 functionalities required to process a
payment are performed at the payment reader 20 (that is, locally), while the GEN 2
functionalities required to process the payment are performed by a GEN 2 kernel remote to the
reader 20 (that is, in the cloud). For example, in one embodiment, the GEN 2 functionalities
may be performed by a GEN 2 kernel on a mobile phone or iPad device. In a non-hybridized
architecture, both 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 a remote server).
[00401 FIG. 3B illustrates an alternate embodiment where the payment reader 20 may
contain both a GEN 1 kernel 304 and a GEN 2 kernel 354 at the application layer and an L
module at the physical layer. In a case that the payment reader has a GEN 2 kernel, only one
L2 GEN 2 kernel is needed for contactless payment, regardless of which transaction type (e.g.,
MC, VISA, etc.) is used. In another embodiment (not specifically illustrated), a second L2 GEN
2 kernel is dedicated to processing contact-based based payment (e.g., swipe or chip payment).
In such embodiments, where the payment reader has the capability to perform GEN 2 functions,
the reader 20 may nonetheless choose to offload GEN 2 processing to devices with identical (or
similar) GEN 2 processors. Put another way, the system selectively choses between duplicative
copies of the GEN 2 kernel located at different installation points. This selection may be
motivated by a variety of factors, not limited to constraints on hardware resources.
[0041] In one embodiment, the decision to offload processing of a GEN 2 function may
be based on a determination that the payment reader, though having sufficient processor
bandwidth, is otherwise resource limited. For example, the payment reader may need to
conserve power, due to, e.g., low battery levels or excessive power consumption by other tasks
such as card reading, computation, and communication. The determination to move processing
to the cloud may be made, in one embodiment, based on a determination of a power level of the
payment reader, by a kernel controller 305, which might otherwise direct processing to a GEN 1
or GEN 2 kernel local to the reader 20. In a preferred embodiment, the kernel controller may
include a power measurement circuit or sensor (not specifically shown) that may be connected
to processor 205, such sensor being capable of taking a dynamic measurement of the power
level of the battery 207. Alternatively, the circuitry to take the measurement of battery level may
be separate from the kernel controller and can communicate with the kernel controller. As one
example, the kernel controller may, through one of these means, measure a current power level
of the reader, as supplied by battery 107. If this current power level falls under a predetermined
minimum threshold, the kernel controller may ignore the local kernels and instead direct processing of the function to a GEN 2 kernel installed on mobile device 40A (or any other appropriate external device). By these means, a low-power device may conserve energy, and there is no concern regarding failure to process based on limited power resources. In some embodiments, the predetermined threshold against with the battery level is measured may be a value stored in memory 209, and in others, the predetermined threshold may be a percentage value of the total battery capacity of the reader. In still other embodiments, one or more threshold values may be stored in a reference table or other data structure in the memory 209, in association with conditional events such as mechanical or environmental conditions of the reader, or a scheduled event, which may impact power consumption. In one such example, the kernel controller 305 may determine that the reader is scheduled to perform a task requiring high power consumption, and may refer to the reference table to identify a threshold power value associated with the scheduled event. The current power level of the battery 207 is then compared to that threshold value to determine if the payment processing may be executed while still maintaining power for the scheduled task. In yet another embodiment, the table in the memory 209 may associate a threshold value with particular historical or predictive power usage conditions (such as an observed or predicted pattern of power consumption). In an exemplary embodiment, the kernel controller may take several iterative measurements of power level, and may observe a pattern in power consumption (e.g., a drainage rate over time). The kernel controller may then refer to the table in memory 209 to determine whether a particular threshold value is associated with such a pattern (such threshold being, for example, higher than a minimal threshold in order to account for a later drop in power). If the current power level is below that threshold value, the kernel controller directs processing of the GEN 2 information to a kernel on an external device. In general, it will be understood that the threshold to which a current power level is compared may be any measureable value to which the battery level may be compared.
[00421 Alternatively, the determination to offload processing from the reader may be
based on a comparison of power levels between the payment reader and the device on which
the target GEN 2 kernel is located (e.g., relative battery power), or any other measure of power
consumption and/or constraint. In one such example, the kernel controller 305 may measure
both a current power level of the reader 20 and a current power level of the mobile device 40A.
Both of these values may then be compared to a predetermined threshold value (either to the
same threshold value or to two respective threshold values). In a case where the measured
power level of the reader values falls below a threshold and a measured power level of the
mobile device 40A is above its threshold, the kernel controller may then (as described above)
bypass processing on the kernels local to the reader and instead direct processing to a GEN 2
kernel installed on mobile device 40A. In another example, a difference in power levels
between the payment reader and the mobile device 40A is calculated, and in a scenario where
the power level of the mobile device is higher than that of the payment reader by a
predetermined difference (i.e., the mobile device has power to spare), processing may be
directed to the GEN 2 kernel installed on the mobile device 40A, even where the particular
power level of the reader may not itself fall below a low-power threshold value.
[0043] In an alternative embodiment, a kernel controller 305 may dynamically determine
to route processing of a function to a GEN 2 kernel on an external device where the GEN 2
kernel installed on the payment reader may be of a version that is not ideal to perform a
particular GEN 2 functionality. That is, rather than the GEN 2 kernel located on the reader 20
and the GEN 2 kernels on the external devices 40A, 40B, 310 being duplicative copies, the
various copies of the kernel may be differently versioned (in any permutation of versions) with
respect to each other. The kernel controller may therefore determine to direct processing to a
version of the kernel that is most appropriate (e.g., most efficient or otherwise preferred), based
on a comparison of the version of the kernel software of the payment reader and that of the
kernel software on the target cloud device.
[00441 In yet another embodiment, the kernel controller 305 may elect to offload
processing because of a recognized security threat to the reader. As one example, the reader
(or an external security monitoring circuit (or software) or a human actor) may recognize that
the reader has been tampered with, such as via an addition of an unauthorized third-party
hardware component capable of reading card data or through alteration, manipulation, or
breakage of any component of the reader 20. In a preferred embodiment, the kernel controller
may dynamically reference a tamper detection circuit (not specifically shown) or other sensor to
determine whether a tamper attempt was made. In other embodiments, the kernel controller
may itself contain such circuitry, or such circuitry may be housed on an external device. The
tamper detection circuit may, in one embodiment, be capable of measuring a 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, of a particular (e.g.,
secure) portion of the reader, of the reader in total, or any other appropriate measurement. The
capacitance measurement may then be compared to a known capacitance value, and if the
difference between the two values exceeds a certain amount, the kernel controller may
determine that a tampering attempt was made, In another example, a tampering attempt may
be detected through a scan of the components of reader 20 to determine whether there are any
discrepancies in the data stored in the memory 209, where there are unexpected or unknown
applications present, or whether there are discrepancies in the physical and logical separation
of the components in the secure and non-secure areas, among other things. By rerouting
processing from the local kernel on the reader to the cloud, the system may in some
circumstances, circumvent the compromised components of the reader.
[0045] FIG. 3C illustrates an alternate embodiment where the payment reader 20 may
contain a GEN 1 or GEN 2 L2 kernel that is modular in nature; that is, different GEN 1 and/or
GEN 2 functionalities at the physical layer and/or application layer may be separated into
different logical "submodules" of the L2 kernel. Put another way, rather than handling the entirety of the L2 kernel as a uniform or monolithic component that cannot be divided, its functionalities may be broken up into certain component parts. In this embodiment, different L2 kernel functions may be performed at different respective devices based on the hardware (or other) resources of the payment reader. In an exemplary embodiment, the submodules 1 and 2 of an L2 kernel of the reader 20 may be variously implemented on either the reader or on a device in the cloud. FIG. 3C depicts a mobile payment reader 20 with an L2 Kernel submodule
1 (a first submodule of the L2 kernel) 340. An L2 Kernel submodule 2 (a second submodule of
the same L2 kernel) 342, 344, or 346 may be housed on an external device, such as any of
mobile device 40A, PC 40B, or remote server 310. Submodule 340 and submodule 342, 344,
346 may be directed to different functions of the L2 Kernel. For example, in various
embodiments, any one or more of submodules 340, 342, 344, and/or 346 may variously act to
perform functions of a payment reader, such as the following: selection manager (e.g., a kernel
controller that directs data for processing of different elements of the payment reader), pin
handling, main kernel functions (e.g., core transactions), cryptography handler, payment
authorization/approval/decline/referral, processing additional payment services, processing non
payment services that use cardholder information, configuration manager (e.g., handling
configurations specific to countries, brands, payment transaction types, etc.), risk handling,
points of interaction (e.g., cardholder/merchant displays or data entry through UI, keypads, or
peripherals), receipt handling, proximity protocols, handling unauthorized transactions, timeouts,
or cancellations, secure channel management, and communication between different modules
or devices, among other functions. It will be understood that these are just general categories
of functions that may in some instances be implemented in one or more submodules, and are
not intended as an exhaustive list, or as a strict one-to-one correspondence between functions
and discrete submodules. As one illustrated example, where the L2 kernel on the reader 20
includes a submodule relating to contactless payment processing, and a submodule directed to
handling PIN/signature/biometric data, one these submodules may be executed on the reader
, and one may be executed on a mobile device 40A. While the above-mentioned functions
may be performed either on the reader itself or from an external device, functions related to a
communication abstraction layer (that is, handling communication between the Li layer of the
payment reader and the remainder of the OSI layers) or certain low-level dialogue with a
contact-based payment card must typically be located in the payment reader itself, as moving
such functions elsewhere would be impractical or inefficient.
[0046] By distributing the locations of these submodules, processing of the various
functions may be optimized in execution. In an exemplary scenario, a particular submodule
designed to process highly-sensitive information may be offloaded to a cloud-based device with
additional security features. In another exemplary scenario, one or more submodules may be
processed from a cloud-based device where computing resources would otherwise not allow for
the processing to be done on the reader in parallel, thereby completing processing in a more
timely fashion. In another exemplary scenario, information required by the submodule may be
stored in the cloud (that is, in a location remote and/or restricted from the reader 20) and
processing may be delegated to a kernel submodule located on a device from which the
required data can be more efficiently accessed.
[0047] FIG. 3D illustrates alternate embodiments in which an Li module has been
divided into submodules, a submodule of the Li module representing one or more of:
mechanical characteristics of elements with which the payment card or NFC-enabled device
interfaces, electrical characteristics of the signals applied to and received from the payment
card or NFC-enabled devices, and other characteristics required to operate a complete L
module. In some embodiments, all submodules of an Li module may be on the payment reader
itself, as with Li submodules 1c (element 370) and 2c (element 372) shown in FIG. 3D, which
are housed on the payment reader 20. Alternatively, as illustrated in FIG. 3D, an L submodule
may be divided between the physical layer and the application layer of the payment reader 20,
with a submodule 1a (element 350) in the Li layer of the reader while submodule 2a (element
352) is in the application layer of reader. In yet another alternate embodiment, submodule 1b
(element 360) may be located on the payment reader while submodule 2b (elements 356, 357,
or 358) may be located on an external device, such as mobile device 40A, PC 40B, or remote
server 310. Note that submodule 2b is a submodule of the Li layer of the payment reader 20,
not of the Li layer of the external device on which the submodule is located, therefore, in the
illustrated embodiment, the Lisubmodule 2b will be processed at the application layer of the
external device. In other embodiments, the L submodules may be distributed differently.
[0048] It will be understood that Li submodules directed to mechanical characteristics of
the reader (e.g., card contacts, electrical lines, active and/or passive circuits for processing
signals, etc.) may in practicality be implemented only on the reader itself, as those functions are
in general physically embedded in the reader. However, Li submodules directed to other
characteristics may alternatively be arranged so as to be located either on the reader or on a
device external to the reader. Table 1 below, for example, lists some of the distributions of
submodules that may be implemented in such embodiments.
Payment Reader Submodules External Device Submodules
Mechanical Submodules 1 Electrical Submodules Software Submodules
Mechanical Submodules 2 Electrical Submodules Software Submodules
Mechanical Submodules 3 Software Submodules Electrical Submodules
Electrical Submodules 4 Mechanical Submodules Software Submodules
Table 1
[00491 As an example, in some implementations, only software modules/characteristics
are arranged to be in-reader software or on an external device such as a mobile phone (L1
submodules 2a or 2b respectively). In these implementations, discrete software components
executed on the reader or on the external device drive electrical and mechanical
components/characteristics that, for example, adjust voltage or test for card contact (L1
submodules 1a and 1b). As another example, row 4 of Table 1 references an implementation
where both the electrical and the software submodules are arranged on the mobile phone (e.g.,
Li submodule 2b 356, 357, or 358) or in the application layer of the reader (L1 submodule 2a).
In this alternate implementation, software components executed on the kernel of an external
device may drive electrical properties of the reader 20 (e.g., via audio/lightning jack, etc.), for
example to adjust voltage or drive copper wire to EMV contact pads or NFC coil (antenna) on
the payment reader 20 (in e.g., Li submodule 1a or 1b). As one example, a Software Defined
Radio application or an equivalent on one of mobile device 40A, PC 40B, or remote server 310
(L1 submodule 2b) is used to control an NFC coil maintained on the payment reader 20 (L1
submodule 1b). Similarly, software in the application layer of the payment reader (L1
submodule 2a) may be used to control mechanical components in the physical layer (L1
submodule 1a).
[0050] It will be understood that the architectures described above and illustrated in
FIGS. 3A-3D are not limited to the components discussed herein, and may include other
hardware and software components. Rather, for ease of illustration, only the components and
functionalities most relevant to the subject inventions are discussed herein.
[0051] FIG. 4 illustrates an example diagram of a flow of data between the components
of the reader 20 and a mobile device 40A in accordance with an embodiment. In the example of
FIG. 4, an architecture along the lines of the one shown in FIG. 3B may be used as an
exemplary model. The process begins at Step 402, wherein the Li Module of the reader 20
reads card data, for example in an NFC transaction via the contactless antenna 250. The card data is transmitted, in step 404, to the processor 205 (or to the secure processor 260 as appropriate). At step 406, a kernel controller 305 determines which kernel should process the payment transaction.
[0052] In a first scenario, the processing needs, and payment information, of the
transaction are limited to the features of a GEN 1 application layer kernel. In this first scenario,
the kernel controller, in step 408, directs processing to the L2 GEN 1 kernel 304 local to the
payment reader 20. This processing may involve a variety of steps, including, e.g., the entry of
authentication data such as a signature, PIN, or biometric data. After processing, the kernel
304 sends the processed payment information, via the communications interface 213, to a
payment processing server 50, e.g., an issuer server, for authentication. In an alternate
embodiment, where the reader may not have the memory or processing capacity for
communication with the payment processing server, the processed payment data may be sent
to the mobile device 40A or computing device 40B, via the communications interface 213, which
device in turn forwards the data to the payment processing server 50.
[0053] In a second scenario, the processing needs of the transaction can only be met by
a GEN 2 application layer kernel, and the payment reader 20 has a GEN 2 kernel and has the
available resources to process the transaction. In this scenario, the kernel controller 305, in
step 408, directs processing to the L2 GEN 2 kernel 354 local to the payment reader 20. This
processing may involve a variety of steps, including, e.g., transactions based on a gift card of
non-standard form of payment like payment through an application on a smart phone, and/or
encryption of the card and payment data. This processing may also involve the entry of, e.g.,
authentication data. After processing, the kernel 354 sends the processed payment information,
via the communications interface 213, to a payment processing server 50 in step 410, or
alternatively, to the mobile device 40A or computing device 40B, which in turn forwards the data
to the payment processing server 50.
[00541 In a third scenario, the processing needs of the transaction can only be met by a
GEN 2 application layer kernel, however, the payment reader 20 does not have a GEN 2 kernel
and/or does not have the available resources to process the transaction. In this scenario, the
kernel controller 305, in step 406, directs processing to any of the L2 GEN 2 kernels 312, 322,
or 332 on remote server 310, mobile device 40A, or computing device 40B respectively, each of
which is external to the reader, by sending the payment data via the communications interface
213,. The kernel on the selected external device then processes the transaction. This
processing may involve a variety of steps, including, e.g., transactions based on a gift card of
non-standard form of payment, e.g., payment through an application on a smart phone, and/or
encryption of the card and transaction data. This processing may also require the entry of, e.g.,
authentication data, and in such a case, the kernel 312, 322, 332 receives such data in step 450
prior to processing the transaction in step 452. After processing, the external device transmits
the data (which may include the transmission of the PIN, signature, or biometric data, among
other information) to the payment processing server 50 in step 454.
[0055] By means of the methods and systems described above, even payment readers
that are limited in hardware resources, in memory, in power, or are otherwise constrained in
their ability to process payment transactions, may function to facilitate processing of a wide
variety of payment transactions. Through this, merchants can provide new life to their existing,
already deployed payment systems, without the need for extensive investment into new
computing resources and/or payment readers. In addition, the security and efficiency of existing
payment processing solutions can be improved (e.g., by providing more robust encryption
solutions) by creating hybrid processing systems using cloud-based resources. As a result,
improvements to the computing systems are put into effect even where dated hardware or other
factors may not allow for improvement at the level of a payment reader itself.
[0056] In another embodiment, with reference to FIG. 5A, an additional processor that
manages a secure area separate from the secure enclave 270 can be provided in the reader 20 in an area physically and logically isolated from other processing components in the non-secure
(or relatively non-secure) area and the secure enclave 270. This additional secure area is
referred to herein as a "trust zone" or "trusted zone" 520. The resources of a trust zone
processor 510 manage the trust zone 520, that is, the security of the trust zone is managed on
the chip itself. In some embodiments, the trust zone processor 510 may maintain a bit value
that designates whether the payment reader should be in a "trusted" or "normal" state, though
other embodiments are possible. The components of the reader 20 and any data buses would
be informed of the bit-value, thereby allowing the processor 510 to isolate and control access to
the trust zone. As one example, the trust zone 520 can be implemented with TrustZone@
technology from ARM Ltd, however, other technologies may be used. The trust zone may
include corresponding hardware (e.g., separate processing units, memory), firmware, and
software (e.g., applications).
[0057] In one exemplary embodiment, the kernel controller 305 may dynamically
determine to redirect processing of a GEN 2 function to a separate GEN 2 kernel 354 located in
the isolated trust zone 520 of the payment reader 20. The kernel controller 305 may make such
a determination based on a detected event such as a tamper event. That is, upon detection of a
tamper attempt, the kernel controller 305 may reroute processing of a GEN 2 function (which
may otherwise be performed by GEN 2 kernel 354 in the secure enclave 270, to instead be
executed by the GEN 2 kernel 524 in the trust zone 520. In another implementation, the trust
zone may be associated with a dedicated Android processer (e.g., chip) running on the payment
reader, that is, the trust zone is implemented by the Android OS, which may have additional
security features directed to, for example, tamper-related functionality.
[0058] In another exemplary architecture, the payment system 1 additionally includes a
mobile device 511, such as an Android smart phone, that is configured to act as an ECR. In the
exemplary embodiment illustrated in FIG. 5B, a device 511 is an mobile device with an Android
processor 517 for processing various functions of the Android OS and for managing a trust zone
520 with an Li module 522 and L2 kernel 524, dedicated to processing payment transactions.
In a scenario where the security needs of a GEN 2 process may not be met by the GEN 2
kernel on the reader 20 (for example, a tamper attempt on the reader is detected) or the reader
does not have available resources to process a security-intensive transaction, the kernel
controller 305 may send the GEN 2 data to be processed by the GEN 2 kernel 524 in the
isolated trust zone 520 of the ECR 511 (as shown in FIG. 5B by a dashed line). In a different
embodiment, the kernel controller 305 may send the GEN 2 data to a mobile device 40A, which
in turn determines that the data should be processed in a trust zone and sends the data to the
GEN 2 kernel 524 in the trust zone 520 (as shown in FIG. 5B by the dotted lines). In yet
another alternative architecture (not specifically shown), the ECR 511 (on, e.g., an Android
phone) takes the place of the payment reader 20, rather than a standalone payment reader 20,
and the ECR processes GEN 2 payment information locally by the appropriate kernel in its trust
zone.
[0059] The use of trust zones may have several benefits over an otherwise hybrid
system with a secure enclave. Initially, a trust zone is implemented in the preferred
embodiment through code that runs natively, allowing the code to directly access hardware
peripherals. A trust zone implementation may therefore be more efficient, and may be
processed faster, than a solution with code implemented on, e.g., a Java layer or main
processor that must access operating system/compatibility layers or that may require additional
Java compiles to perform the same action. Further, because the concept of a trust zone is
commonly implemented in ARM-based architectures (e.g., on some Android phones), no
separate secured chip is needed, thereby reducing manufacturing costs. What is more,
because trust zones are commonly implemented in some public CPU architectures, their
security is well-tested, leading to a potentially more secure system with a greater set of built-in
defenses.
[00601 Example Clauses
[0061] 1. A mobile communication device, comprising: a communication interface for
communicating with first-type payment readers and second-type payment readers, each of the
second-type payment readers having a 2nd generation Layer 2 (L2) kernel for processing
payment information from second-type payment devices, and each of the first-type payment
readers having a 1st generation L2 kernel for processing payment information from 1st
generation payment devices; 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
processed second-type payment information, the processed second-type payment information
having been processed by 2nd generation L2 kernels of the second-type payment readers;
transmit the processed second-type payment information to one or more payment servers for
approval of payment transactions based on the processed second-type payment information;
receive first-type payment information processed by 1st generation L2 kernels of the first-type
payment readers; transmit the first-type payment information to one or more payment servers
for approval of payment transactions based on the first-type payment information; receive raw
second-type payment information from the first-type payment readers; provide the raw second
type payment information to a 2nd generation L2 kernel of the mobile communication device for
processing of the raw second-type payment information; and transmit the raw second-type
payment information, the raw second-type payment information having been processed by the
2nd generation L2 kernel of the mobile communication device, to one or more payment servers
for approval of payment transactions based on the transmitted raw second-type payment
information.
[0062] 2. The mobile communication device of clause 1, further comprising: an interface
configured to receive contactless payment directly from payment devices, wherein the interface
receives contactless payment using the 2nd generation L2 kernel of the mobile communication
device.
[00631 3. The mobile communication device of clause 1, wherein the 2nd generation L2
kernel of the mobile communication device has a greater processing capability than the 1st
generation L2 kernels.
[0064] 4. The mobile communication device of clause 1, wherein the raw second-type
payment information includes authentication information related to a payment transaction.
[0065] 5. The mobile communication device of clause 1, wherein the mobile
communication device is further configured to: receive unprocessed second-type payment
information from the 2nd generation L2 kernels of the second-type payment readers; provide the
unprocessed second-type payment information to the 2nd generation L2 kernel of the mobile
communication device for processing of the unprocessed second-type payment information.
[0066] 6. The mobile communication device of clause 5, wherein the 2nd generation L2
kernels of the second-type payment readers are identical in functionality to the 2nd generation
L2 kernel of the mobile communication device.
[0067] 7. The mobile communication device of clause 1, wherein the mobile
communication device is a mobile phone.
[0068] 8. A method comprising: receiving, by a mobile communication device, payment
information from a first-type payment reader or a second-type payment reader, wherein the first
type payment reader has a 1st generation L2 kernel for processing payment information from
first-type payment devices, and wherein the second-type payment reader has a 2nd generation
Layer 2 (L2) kernel for processing payment information from second-type payment devices;
transmitting, by the mobile communication device, in a case that the received payment
information is processed second-type payment information processed by the 2nd generation L2
kernel of the second-type payment reader, the processed second-type payment information to
one or more payment servers for approval of payment transactions based on the processed
second-type payment information; transmitting by the mobile communication device, in a case that the received payment information is first-type payment information processed by the 1st generation L2 kernel of the first-type payment reader, the first-type payment information to one or more payment servers for approval of payment transactions based on the first-type payment information; in a case that the received payment information is raw second-type payment information from the first-type payment reader, (a) providing, by the mobile communication device, the raw second-type payment information to a 2nd generation L2 kernel of the mobile communication device for processing of the raw second-type payment information and (b) transmitting, by the mobile communication device, the raw second-type payment information, the raw second-type payment information having been processed by the 2nd generation L2 kernel of the mobile communication device, to one or more payment servers for approval of payment transactions based on the transmitted raw second-type payment information.
[0069] 9. The method of clause 8, further comprising: receiving contactless payment
from a payment device using the 2nd generation L2 kernel of the mobile communication device.
[0070] 10. The method of clause 8, wherein the 2nd generation L2 kernel of the mobile
communication device has a greater processing capability than the 1st generation L2 kernel of
the first-type payment reader.
[0071] 11. The method of clause 8, wherein the raw second-type payment information
includes authentication information related to a payment transaction.
[0072] 12. The method of clause 8, further comprising: receiving unprocessed second
type payment information from the 2nd generation L2 kernel of the second-type payment
reader; and providing the unprocessed second-type payment information to the 2nd generation
L2 kernel of the mobile communication device for processing of the unprocessed second-type
payment information.
[00731 13. The method of clause 8, wherein the 2nd generation L2 kernel of the second
type payment reader is identical in functionality to the 2nd generation L2 kernel of the mobile
communication device.
[0074] 14. The method of clause 8, wherein the mobile communication device is a
mobile phone.
[0075] 15. A non-transitory computer-readable storage medium comprising instructions
stored therein, which when executed by one or more processors of a mobile communication
device, cause the one or more processing units to perform operations comprising: 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 1st generation L2 kernel
configured to process a first type of payment information and wherein the second payment
reader has a 2nd generation Layer 2 (L2) kernel configured to process a second type of
payment information different than the first type of payment information; transmitting, in a case
that the received payment information comprises the second type of payment information and
the received payment information has been processed by the 2nd generation L2 kernel of the
second payment reader, the received payment information to one or more payment servers for
approval of payment transactions based on the received payment information; transmitting, in a
case that the received payment information comprises the first type of payment information and
the received payment information has been processed by the 1st generation L2 kernel of the
first payment reader, the received payment information to one or more payment servers for
approval of payment transactions based on the received payment information; performing, in a
case that the received payment information comprises the second type of payment information
and the received payment information has been received from the first payment reader without
processing, performing the following: (a) processing the received payment information using a
2nd generation L2 kernel of the mobile communication device and (b) transmitting processed payment information to one or more payment servers for approval of payment transactions based on the processed payment information.
[0076] 16. The non-transitory computer-readable storage medium of clause 15, wherein
execution of the instructions further causes the one or more processing units to perform
operations comprising: receiving contactless payment from a payment device using the 2nd
generation L2 kernel of the mobile communication device.
[0077] 17. The non-transitory computer-readable storage medium of clause 15, wherein
the 2nd generation L2 kernel of the mobile communication device has a greater processing
capability than the 1st generation L2 kernel of the first payment reader.
[0078] 18. The non-transitory computer-readable storage medium of clause 15, wherein
the received payment information includes authentication information related to a payment
transaction.
[0079] 19. The non-transitory computer-readable storage medium of clause 15, wherein
execution of the instructions further causes the one or more processing units to perform
operations comprising: receiving unprocessed payment information from the 2nd generation L2
kernel of the second payment reader, the unprocessed payment information comprising the
second type of payment information; and providing the unprocessed payment information to the
2nd generation L2 kernel of the mobile communication device for processing of the
unprocessed payment information.
[0080] 20. The non-transitory computer-readable storage medium of clause 15, wherein
the 2nd generation L2 kernel of the second payment reader is identical in functionality to the
2nd generation L2 kernel of the mobile communication device.
[0081] 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 of the payment information by the first module of the L2 kernel; and an apparatus external to the payment reader, the apparatus 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 apparatus for processing by the second module of the L2 kernel.
[0082] 22. The POS system of clause 21, wherein the apparatus 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.
[0083] 23. The POS system of clause 21, wherein the processing by the second module
of the L2 kernel is related to authentication of a payment transaction.
[0084] 24. The POS system of clause 21, wherein the payment information comprises
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.
[0085] 25. A point of sale (POS) system comprising: a payment device having a
payment application, a Layer 2 (L2) kernel, and a first submodule of a Layer 1 (L1) module, the
first submodule of the Li module being configured to receive payment information from a
payment object, the payment application being configured to provide the payment information
from the first submodule of the Li module to the L2 kernel for processing of the payment
information by the L2 kernel; and a payment reader coupled to the payment device and having a
second submodule of the L module comprising 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 submodule of the L
module.
[00861 26. The POS system of 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.
[0087] 27. The POS system of clause 25, wherein the second submodule of the Li
module relates to a mechanical function of the payment reader.
[0088] 28. The POS system of clause 27, wherein the mechanical function of the
payment reader relates to one or more of: adjustment of voltage levels of the payment reader
and implementing contact with the payment object.
[0089] 29. The POS system of clause 25, wherein the first submodule of the L module
relates to control of a software function of the payment reader.
[0090] 30. The POS system of clause 25, wherein the first submodule of the L module
relates to control of an electrical function of the payment reader.
[0091] 31. The POS system of clause 30, wherein the electrical function of the payment
reader relates to driving an electrical connection between a wire and a payment interface of the
payment reader, and wherein the payment interface is one or more of an EMV contact pad or an
NFC coil.
[0092] 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 communication with an apparatus other than the
payment device, the apparatus comprising a second module of the kernel, wherein the payment
application is configured to provide the received payment information to the apparatus, via the
wireless communication interface, for processing by the second module.
33. The payment device of clause 32, wherein the payment application is further
configured to: receive, via the wireless communication interface, processed payment
information from apparatus, the process payment information having been processed by the second module, and transmit the processed payment information to one or more payment servers.
[0093] 34. The payment device of clause 33, wherein the payment application is further
configured to transmit the processed payment information to the first module of the kernel to be
processed, prior to transmitting the processed payment information to the one or more payment
servers.
[0094] 35. The payment device of clause 32, wherein the first module processes first
payment information of the received payment information and the second module processes
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 is done in parallel.
[0095] 36. A method comprising: receiving, by a payment device, payment information
from a payment object; transmitting, by the payment device, the payment information to a first
module of a kernel, the first module being installed on the payment device, for processing of the
payment information by the first module; and transmitting, by the payment device, the payment
information processed by the first module to a second module of the kernel for processing by
the second module, the second module being installed on an apparatus external to the payment
device.
[0096] The foregoing is merely illustrative of the principles of this disclosure and various
modifications may be made by those skilled in the art without departing from the scope of this
disclosure. The above described embodiments are presented for purposes of illustration and
not of limitation. The present disclosure also can take many forms other than those explicitly
described herein. Accordingly, it is emphasized that this disclosure is not limited to the explicitly
disclosed methods, systems, and apparatuses, but is intended to include variations to and
modifications thereof, which are within the spirit of the following claims.
[00971 As a further example, variations of apparatus or process parameters (e.g.,
dimensions, configurations, components, process step order, etc.) may be made to further
optimize the provided structures, devices and methods, as shown and described herein. In any
event, the structures and devices, as well as the associated methods, described herein have
many applications. Therefore, the disclosed subject matter should not be limited to any single
embodiment described herein, but rather should be construed in breadth and scope in
accordance with the appended claims.
Claims (18)
1. A point of sale (POS) system comprising:
a payment reader having a first application-layer payment kernel for processing payment
transactions, the first application-layer payment kernel for performing at least one payment
processing function for processing and sending payment information for payment transactions
to at least one payment server for approval; and
a networked device external to the payment reader, the networked device having a
second application-layer payment kernel for processing payment transactions, the second
application-layer payment kernel configured to perform the at least one payment processing
function for processing and sending payment information for payment transactions to the at
least one payment server for approval,
wherein the payment reader is configured to receive first payment information for a first
payment transaction from a payment device and to obtain a first payment kernel selection of
whether to transmit at least a portion of the first payment information to the first application-layer
payment kernel or the second application-layer payment kernel for processing and sending the
portion of the first payment information to the at least one payment server for approval, and
wherein the payment reader is configured to transmit the portion of the first payment information
to the first application-layer payment kernel of the payment reader or to the second application
layer payment kernel of the networked device in accordance with the payment kernel selection
obtained by the payment reader, and wherein the payment kernel selection is based on a
detected condition of the payment reader.
2. The POS system of claim 1, wherein the payment reader is configured to receive
second payment information for a second payment transaction and to obtain a second payment
kernel selection of whether to transmit at least a portion of the second payment information to the first application-layer payment kernel or the second application-layer payment kernel for processing and sending the portion of the second payment information to the at least one payment server for approval, and wherein the payment reader is configured to transmit the portion of the second payment information to the first application-layer payment kernel of the payment reader or to the second application-layer payment kernel of the networked device in accordance with the second payment kernel selection obtained by the payment reader, and wherein the second payment kernel selection is based on a second detected condition of the payment reader.
3. The POS system of claim 2, wherein the payment reader is configured to transmit the
portion of the first payment information to the first application-layer payment kernel for
processing in accordance with the first payment kernel selection, and wherein the payment
reader is configured to transmit the portion of the second payment information to the second
application-layer payment kernel for processing in accordance with the second payment kernel
selection.
4. The POS system of claim 3, wherein the payment reader is configured to wirelessly
transmit the portion of the second payment information to the networked device.
5. The POS system of any one of claims 1 to 4, wherein the networked device is a
mobile phone, and wherein the payment reader is communicatively coupled to the mobile
phone.
6. The POS system of any one of claims 1 to 5, wherein the payment reader has a
battery, and wherein the first payment kernel selection is based on a measurement of a power
level for the battery.
7. The POS system of any one of claims 1 to 6, wherein the wherein the first payment
kernel selection is based on a detection of a tamper event associated with the payment reader.
8. A payment reader comprising:
a payment module for receiving first payment information for a first payment transaction
from a payment device;
at least one processor having a first application-layer payment kernel and a kernel
director, the first application-layer payment kernel for performing at least one payment
processing function for processing and sending payment information for payment transactions
to at least one payment server for approval;
a communications interface configured to transmit information from the payment reader
to a second application-layer payment kernel of a networked device, the second application
layer payment kernel for performing the at least one payment processing function for processing
and sending payment information for payment transactions to the at least one payment server
for approval; and
the kernel director configured to, in accordance with the receipt of the first payment
information from the payment device, (a) obtain a payment kernel selection of whether to
transmit at least a portion of the first payment information to the first application-layer payment
kernel of the payment reader or to the second application-layer payment kernel of the
networked device for processing and sending the portion of the first payment information to the
at least one payment server for approval, and (b) instruct the transmission of control the
payment reader to transmit the portion of the first payment information to the first application layer payment kernel of the payment reader or to the second application-layer payment kernel of the networked device in accordance with the payment kernel selection obtained by the kernel director, wherein the payment kernel selection is based on a detected condition of the payment reader.
9. The payment reader of claim 8, wherein the networked device is a mobile phone, and
wherein the payment reader is communicatively coupled to the mobile phone.
10. The payment reader of claim 8 or claim 9, wherein the payment reader has a battery,
and wherein the payment kernel selection is based on a measurement of a power level for the
battery.
11. The payment reader of any one of claims 8 to 10, wherein the payment kernel
selection is based on a detection of a tamper event associated with the payment reader.
12. The payment reader of any one of claims 8 to 11, wherein the second payment
kernel is configured to provide payment functions for the first payment information not provided
by the first payment kernel.
13. The payment reader of any one of claims 8 to 12, wherein the detected condition
indicates at least one of (1) whether hardware of the payment reader is compatible with the first
payment transaction, (2) whether an occurrence of a security threat to the payment reader is
detected, or (3) whether a power level of a power source in the payment reader is below a
threshold.
14. A method for use in a point of sale system, comprising: receiving, by a payment reader, first payment information from a payment device for a payment transaction; detecting a condition of the payment reader; performing, by a first application-layer payment kernel at least one payment processing function for processing and sending payment information for payment transactions to at least one payment server for approval; obtaining, by the payment reader based on the detected condition, a payment kernel selection of whether to transmit at least a portion of the first payment information to a first application-layer payment kernel of the payment reader or a second application-layer payment kernel of a device external to the payment reader, the second application-layer payment kernel for performing the at least one payment processing function for processing and sending payment information for payment transactions to the at least one payment server for approval; and transmitting, by the payment reader, the portion of the first payment information to the first application-layer payment kernel of the payment reader or to the second application-layer payment kernel of the device external to the payment reader in accordance with the payment kernel selection obtained by the payment reader.
15. The method of claim 14, wherein the transmitting comprises wirelessly transmitting
the portion of the first payment information to the device.
16. The method of claim 14 or claim 15, wherein the device is a mobile phone, and
wherein the payment reader is communicatively coupled to the mobile phone.
17. The method of any one of claims 14 to 16, further comprising measuring a power
level of a battery of the payment reader, and wherein the payment kernel selection is based on
the measuring.
18. The method of any one of claims 14 to 17, further comprising detecting, by the
payment reader, a tamper event associated with the payment reader, and wherein the payment
kernel selection is based on the detecting.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AU2024202020A AU2024202020A1 (en) | 2018-12-21 | 2024-03-28 | Point of sale (pos) systems and methods with dynamic kernel selection |
Applications Claiming Priority (10)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US16/230,823 | 2018-12-21 | ||
| US16/230,940 | 2018-12-21 | ||
| US16/230,823 US10762196B2 (en) | 2018-12-21 | 2018-12-21 | Point of sale (POS) systems and methods with dynamic kernel selection |
| US16/231,030 US11049095B2 (en) | 2018-12-21 | 2018-12-21 | Point of sale (POS) systems and methods with dynamic kernel selection |
| US16/231,030 | 2018-12-21 | ||
| US16/230,940 US10990969B2 (en) | 2018-12-21 | 2018-12-21 | Point of sale (POS) systems and methods for dynamically processing payment data based on payment reader capability |
| PCT/US2019/067907 WO2020132476A1 (en) | 2018-12-21 | 2019-12-20 | Point of sale (pos) systems and methods with dynamic kernel selection |
| AU2019405995A AU2019405995B2 (en) | 2018-12-21 | 2019-12-20 | Point of sale (pos) systems and methods with dynamic kernel selection |
| AU2023201736A AU2023201736B2 (en) | 2018-12-21 | 2023-03-21 | Point of sale (pos) systems and methods with dynamic kernel selection |
| AU2024202020A AU2024202020A1 (en) | 2018-12-21 | 2024-03-28 | Point of sale (pos) systems and methods with dynamic kernel selection |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2023201736A Division AU2023201736B2 (en) | 2018-12-21 | 2023-03-21 | Point of sale (pos) systems and methods with dynamic kernel selection |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| AU2024202020A1 true AU2024202020A1 (en) | 2024-04-18 |
Family
ID=71102338
Family Applications (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2019405995A Active AU2019405995B2 (en) | 2018-12-21 | 2019-12-20 | Point of sale (pos) systems and methods with dynamic kernel selection |
| AU2023201736A Active AU2023201736B2 (en) | 2018-12-21 | 2023-03-21 | Point of sale (pos) systems and methods with dynamic kernel selection |
| AU2024202020A Pending AU2024202020A1 (en) | 2018-12-21 | 2024-03-28 | Point of sale (pos) systems and methods with dynamic kernel selection |
Family Applications Before (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2019405995A Active AU2019405995B2 (en) | 2018-12-21 | 2019-12-20 | Point of sale (pos) systems and methods with dynamic kernel selection |
| AU2023201736A Active AU2023201736B2 (en) | 2018-12-21 | 2023-03-21 | Point of sale (pos) systems and methods with dynamic kernel selection |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP3857417A4 (en) |
| JP (1) | JP2022512297A (en) |
| CN (1) | CN113544673A (en) |
| AU (3) | AU2019405995B2 (en) |
| WO (1) | WO2020132476A1 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11049095B2 (en) | 2018-12-21 | 2021-06-29 | Square, Inc. | Point of sale (POS) systems and methods with dynamic kernel selection |
| GB202108281D0 (en) * | 2021-06-10 | 2021-07-28 | Mastercard International Inc | Wireless terminal apparatus and method |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180053157A1 (en) | 2010-01-08 | 2018-02-22 | Blackhawk Network, Inc. | Systems and methods for consumer modifiable payment card transactions |
| EP2688025A1 (en) | 2012-07-20 | 2014-01-22 | MobiPayPoint Limited | Method of processing a card-present, card payment transaction |
| GB201304764D0 (en) * | 2013-03-15 | 2013-05-01 | Mastercard International Inc | Method and apparatus for payment transactions |
| US9978054B2 (en) * | 2014-04-11 | 2018-05-22 | Mastercard International Incorporated | Acceptance quality improvement using localization data to adjust contactless payment |
| US9330383B1 (en) * | 2015-09-23 | 2016-05-03 | Square, Inc. | Message dispatcher for payment system |
| US10475034B2 (en) * | 2016-02-12 | 2019-11-12 | Square, Inc. | Physical and logical detections for fraud and tampering |
| KR20180037473A (en) * | 2016-10-04 | 2018-04-12 | 삼성전자주식회사 | Mobile payment method, electronic device and external payment device therefor |
| US11514418B2 (en) * | 2017-03-19 | 2022-11-29 | Nxp B.V. | Personal point of sale (pPOS) device with a local and/or remote payment kernel that provides for card present e-commerce transaction |
| SG10201708570XA (en) * | 2017-10-18 | 2019-05-30 | Mastercard International Inc | A system for executing a computer process for processing a transaction, and related computer process |
-
2019
- 2019-12-20 EP EP19899250.5A patent/EP3857417A4/en active Pending
- 2019-12-20 AU AU2019405995A patent/AU2019405995B2/en active Active
- 2019-12-20 CN CN201980085170.5A patent/CN113544673A/en active Pending
- 2019-12-20 WO PCT/US2019/067907 patent/WO2020132476A1/en unknown
- 2019-12-20 JP JP2021528447A patent/JP2022512297A/en active Pending
-
2023
- 2023-03-21 AU AU2023201736A patent/AU2023201736B2/en active Active
-
2024
- 2024-03-28 AU AU2024202020A patent/AU2024202020A1/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| AU2023201736A1 (en) | 2023-04-20 |
| AU2023201736B2 (en) | 2024-02-22 |
| CN113544673A (en) | 2021-10-22 |
| AU2019405995A1 (en) | 2021-08-12 |
| AU2019405995B2 (en) | 2022-12-22 |
| EP3857417A4 (en) | 2022-02-09 |
| WO2020132476A1 (en) | 2020-06-25 |
| JP2022512297A (en) | 2022-02-03 |
| EP3857417A1 (en) | 2021-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10762196B2 (en) | Point of sale (POS) systems and methods with dynamic kernel selection | |
| US11775957B2 (en) | Point of sale (POS) systems and methods with kernel selection | |
| US9785930B1 (en) | Expedited processing of electronic payment transactions | |
| US10417628B2 (en) | Multi-interface processing of electronic payment transactions | |
| US10990969B2 (en) | Point of sale (POS) systems and methods for dynamically processing payment data based on payment reader capability | |
| US10684848B1 (en) | Blocking and non-blocking firmware update | |
| US10817869B2 (en) | Preliminary enablement of transaction processing circuitry | |
| CA3027611C (en) | Expedited processing of electronic payment transactions | |
| US9778928B1 (en) | Compressed firmware update | |
| US10380389B1 (en) | Reading payment object upon detection of reader readiness | |
| CN109690593B (en) | Pre-transaction processing technology | |
| US10255464B2 (en) | Systems and methods for determining clock rates for communicating with processing devices | |
| AU2023201736B2 (en) | Point of sale (pos) systems and methods with dynamic kernel selection | |
| EP4177736A1 (en) | Compressed firmware update | |
| US20180005237A1 (en) | Preliminary acquisition of payment information | |
| US10002268B1 (en) | Identification of desired clock rate for an externally-driven processing device | |
| WO2018144591A1 (en) | Communication protocol speedup and step-down |