Communication protocol speedup and step-down

A payment terminal such as a payment reader may receive and form electrical connections with an electronic transaction card such as an EMV chip card. The payment terminal may provide a clock signal at a rate that exceeds a specified rate for the EMV chip card. The payment terminal may transmit messages to the EMV chip card and monitor receive messages at a data connection. The payment terminal may determine that the clock rate is excessive based on a timeout of a receive message, an error rate of a receive message, or a receive message indicating that one of the transmit messages was not received by the EMV card. The payment terminal may reduce the clock rate to a rate that is below the specified rate for the EMV chip card.

BACKGROUND

Electronic transaction processing systems may utilize a payment terminal. The payment terminal can process payment transactions and interact with payment devices such as a payment card having a magnetic strip that is swiped in a magnetic reader of the payment terminal, a payment device having a Europay/Mastercard/Visa (EMV) chip that is inserted into a corresponding EMV slot of the payment terminal, and near field communication (NFC) enabled devices such as a smart phone or EMV card that is tapped at the payment terminal and transmits payment information over a secure wireless connection.

Electronic devices such as electronic cards may store information that may be used for communications and processing of transactions. For example, EMV cards may have an EMV chip located on the EMV card. The EMV card may not have its own power and clock source, and may receive its power and clock signal from another device such as a payment terminal. The EMV chip may interface with a device such as the payment terminal or a portion thereof, which may provide a clock source for the EMV chip, e.g., by connecting clock, power and ground pins of the EMV chip to a clock source, power source, and ground of the payment terminal. Once the EMV chip is connected to a power source, it may communicate with the payment reader or terminal via one or more data lines at a rate determined by clock rate of the clock source. In this manner, the EMV chip may exchange information as required to complete a transaction such as a payment transaction.

The EMV chip and payment reader or terminal may begin exchanging messages after power is applied to the EMV chip. A speed at which information such as encrypted payment information may be exchanged depends on the clock rate of the clock source signal. In the case of payment transactions, exchanging the requisite number of messages between EMV chip and payment reader or terminal for performing transaction processing may take a number of clock cycles to complete. During this time, the EMV chip and the payment terminal must remain connected in order to maintain the power, clock, and data connections.

DETAILED DESCRIPTION

An electronic transaction card such as an EMV card has a chip (e.g., an EMV chip) embedded in or on the chip. The EMV chip may be an externally-driven processing device that receives signals necessary to operate the EMV chip (e.g., power, ground, and clock signals) from an external source. The chip has contacts that can be accessed by a reader device such as a payment terminal, for example, by inserting the EMV card into an EMV slot. When properly placed in the slot, the chip contacts will physically contact corresponding contacts of the reader device. The physical contacts provide power to the chip, which in turn allows processing circuitry and memory of the EMV card to begin to function. In addition, the EMV chip may receive a clock signal that is used as a clock source for the EMV chip. The speed at which the EMV card processes payment transactions and exchanges messages is based on the clock rate of the received clock signal.

A payment terminal may select a first clock rate at which to provide the clock signal to the EMV chip of the EMV card. The first clock rate may correspond to a first clock rate that approaches an upper limit for the clock rate for which the EMV card can function properly, e.g., without generating errors in data processing or communications. This first clock rate may be selected based on known information about a particular card, a particular card type, a type of merchant, a type of transaction, statistics about queues, environmental information, and other related information that is relevant to determining the clock rate at which the EMV card can operate correctly and whether it is desirable to speed up transactions to reduce wait time under particular circumstances. In an embodiment, the first clock rate may “overclock” the EMV card, such that the first clock rate is greater than a specified clock rate for the EMV card.

The payment terminal monitors information about the EMV card such as messages and data received from the EMV chip. Based on information such as whether messages are received from the EMV chip, bit errors in messages received from the EMV chip, acknowledgement messages, requests to re-send messages to the EMV chip, corrupt payload data in received messages, it may be determined whether the EMV chip is able to function properly at the first clock rate. Depending on how well the EMV chip functions at the first clock rate, the clock rate may be increased or decreased. The degree of the increase or decrease may be based on known information as described above, for example, based on known card information, transaction types, merchant types, environment information, and other related information. This process may be repeated until an appropriate clock rate for the EMV chip is determined.

Any data that is successfully received while communicating at particular clock rates may be cached by the payment terminal. In this manner, the payment terminal may continue to process current transactions while modifying the clock rate as desired, e.g., without having to restart the payment transaction. The known information may also be stored, in order to better determine appropriate starting clock rates and changes in clock rates for different cards, card types, transaction types, environmental conditions, and other relevant conditions. In some embodiments, rules for determining initial clock rates and for modifying clock rates may be determined at a remote device such as a payment service system. Some of the processing may be determined by the remote device, or in some instances, the rules may be updated at the payment terminal based on software and firmware updates.

FIG. 1depicts an illustrative block diagram of a payment system1in accordance with some embodiments of the present disclosure. In one embodiment, payment system1includes a payment device10, payment terminal20, network30, and payment server40. In an exemplary embodiment, payment server40may include a plurality of servers operated by different entities, such as a payment service system50and a bank server60. These components of payment system1facilitate electronic payment transactions between a merchant and a customer.

The electronic interactions between the merchant and the customer take place between the customer's payment device10and the merchant's payment terminal20. The customer has a payment device10such as a credit card having magnetic stripe, a credit card having an externally-driven processing device such as an EMV chip, or a NFC-enabled electronic device such as a smart phone running a payment application. The merchant has a payment terminal20such as a merchant device, payment reader, standalone terminal, combined customer/merchant terminals, electronic device (e.g., smart phone) running a point-of-sale application, or other electronic device that is capable of processing payment information (e.g., encrypted payment card data and user authentication data) and transaction information (e.g., purchase amount and point-of-purchase information).

In some embodiments (e.g., for low-value transactions or for payment transactions that are less than a payment limit indicated by a NFC or EMV payment device10) the initial processing and approval of the payment transaction may be processed at payment terminal20. In other embodiments, payment terminal20may communicate with payment server40over network30. Although payment server40may be operated by a single entity, in one embodiment payment server40may include any suitable number of servers operated by any suitable entities, such as a payment service system50and one or more banks of the merchant and customer (e.g., a bank server60). The payment terminal20and the payment server40communicate payment and transaction information to determine whether the transaction is authorized. For example, payment terminal20may provide encrypted payment data, user authentication data, purchase amount information, and point-of-purchase information to payment server40over network30. Payment server40may determine whether the transaction is authorized based on this received information as well as information relating to customer or merchant accounts, and responds to payment terminal20over network30to indicate whether or not the payment transaction is authorized. Payment server40may also transmit additional information such as transaction identifiers to payment terminal20.

Based on the information that is received at payment terminal20from payment server40, 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 terminal, for example, at a screen of a payment terminal. In other embodiments such as a smart phone or watch 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 storage in memory.

During transactions involving an EMV card, the EMV card may be inserted into a card slot of the payment terminal. The terminal may make a number of electrical connections with the EMV card including, inter alia, a power line, a ground line, a clock source line and a data line. The EMV card may have a processing element that is powered by the power and ground lines, and that performs various functions in conjunction with the payment terminal, such as encryption and communication of card and transaction information, for example via an authorization request cryptogram (ARQC) and other transaction information. The payment terminal may provide a clock signal to the EMV card via the card slot, which in turn establishes a data processing speed based on the clock rate of the provided clock signal. In addition, the EMV card and payment terminal exchange information that allows them to perform transaction processing, such as a process options data object list (PDOL) provided from the terminal and application interchange profile (AIP) and application file locator (AFL) provided by the EMV card.

EMV cards may include a specified clock rate for the particular processing element (e.g., chip) embedded in the EMV card. Some EMV cards may have chips rated at a higher specified clock rate than others. EMV cards having chips rated at various specified clock signal frequencies may be used as payment methods during payment transactions with the payment reader. In some embodiments, the specified clock rates may not accurately correspond to functional clock rates for the EMV card. For example, particular EMV cards may be functional at clock rates that are significantly greater than the specified clock rate. Allowable clock rates may also be impacted by other factors, such as environmental factors (e.g., temperature, humidity, etc.) or factors relating to transactions (e.g., greater error tolerance for lower-value transactions).

In some embodiments, the payment terminal may be configured to take advantage of an EMV card's ability to function at a clock rate that is greater than the specified clock rate, by provide a clock signal at an increased clock rate. The EMV card may then perform its internal processing and exchange data messages based on the increased clock rate. The payment terminal may monitor the performance of the EMV card and other related factors or information, and based on the monitored performance may modify (e.g., increase or decrease) the clock rate as is appropriate. For example, by exchanging messages via the data line connection to the EMV card, the type of messages (e.g., failed messages, acknowledgement messages, requests to re-send messages) and underlying payload data may be analyzed to set an appropriate clock rate. By tailoring the clock rate to the EMV card and other related operating conditions, the overall transaction time may be decreased.

FIG. 2depicts an illustrative block diagram of payment device10and payment terminal20in accordance with some embodiments of the present disclosure. Although it will be understood that payment device10and payment terminal20of payment system1may be implemented in any suitable manner, in one embodiment the payment terminal20may comprise a payment reader22and a merchant device29. However, it will be understood that as used herein, the term payment terminal may refer to any suitable component of the payment terminal, such as payment reader22. In an embodiment, the payment reader22of payment terminal20may be a device that facilitates transactions between the payment device10and a merchant device29running a point-of-sale application.

In one embodiment, payment device10may be a device that is capable of communicating with payment terminal20(e.g., via payment reader22), such as a NFC device12or an EMV chip card14. Chip card14may include a secure integrated circuit that is capable of communicating with a payment terminal such as payment terminal20, generating encrypted payment information, and providing the encrypted payment information as well as other payment or transaction information (e.g., transaction limits for payments that are processed locally) in accordance with one or more electronic payment standards such as those promulgated by EMVCo. In some embodiments, chip card14may include an EMV chip that is an externally-driven processing device that receives signals necessary to operate the EMV chip (e.g., power, ground, and clock signals) from an external source. Chip card14may include contact pins for communicating with payment reader22(e.g., in accordance with ISO 7816) and in some embodiments, may be inductively coupled to payment reader22via a near field15. A chip card14that is inductively coupled to payment reader22may communicate with payment reader22using load modulation of a wireless carrier signal that is provided by payment reader22in accordance with a wireless communication standard such as ISO 14443.

NFC device12may be an electronic device such as a smart phone, tablet, or smart watch that is capable of engaging in secure transactions with payment terminal20(e.g., via communications with payment reader22). NFC device12may have hardware (e.g., a secure element including hardware and executable code) and/or software (e.g., executable code operating on a processor in accordance with a host card emulation routine) for performing secure transaction functions. During a payment transaction NFC device12may be inductively coupled to payment reader22via near field15and may communicate with payment terminal20by active or passive load modulation of a wireless carrier signal provided by payment reader22in accordance with one or more wireless communication standards such as ISO 14443 and ISO 18092.

Although payment terminal20may be implemented in any suitable manner, in one embodiment payment terminal20may include a payment reader22and a merchant device29. The merchant device29runs a point-of-sale application that provides a user interface for the merchant and facilitates communication with the payment reader22and the payment server40. Payment reader22may facilitate communications between payment device10and merchant device29. As described herein, a payment device10such as NFC device12or chip card14may communicate with payment reader22via inductive coupling. This is depicted inFIG. 2as near field15, which comprises a wireless carrier signal having a suitable frequency (e.g., 13.56 MHz) emitted from payment reader22.

In one embodiment, payment device10may be a contactless payment device such as NFC device12or chip card14, and payment reader22and the contactless payment device10may communicate by modulating the wireless carrier signal within near field15. In order to communicate information to payment device10, payment reader22changes the amplitude and/or phase of the wireless carrier signal based on data to be transmitted from payment reader22, resulting in a wireless data signal that is transmitted to the payment device. This signal is transmitted by an antenna of payment reader22that is tuned to transmit at 13.56 MHz, and if the payment device10also has a suitably tuned antenna within the range of the near field15(e.g., 0 to 10 cm), the payment device receives the wireless carrier signal or wireless data signal that is transmitted by payment reader22. In the case of a wireless data signal, processing circuitry of the payment device10is able to demodulate the received signal and process the data that is received from payment reader22.

When a contactless payment device such as payment device10is within the range of the near field15, it is inductively coupled to the payment reader22. Thus, the payment device10is also capable of modulating the wireless carrier signal via active or passive load modulation. By changing the tuning characteristics of the antenna of payment device10(e.g. by selectively switching a parallel load into the antenna circuit based on modulated data to be transmitted) the wireless carrier signal is modified at both the payment device10and payment reader22, resulting in a modulated wireless carrier signal. In this manner, the payment device is capable of sending modulated data to payment reader22.

In some embodiments, payment reader22also includes an EMV slot21that is capable of receiving chip card14. Chip card14may have contacts that engage with corresponding contacts of payment reader22when chip card14is inserted into EMV slot21. Payment reader22provides power and a clock signal to an EMV chip of chip card14through these contacts and payment reader22and chip card14communicate through a communication path established by the contacts.

Payment reader22may also include hardware for interfacing with a magnetic strip card (not depicted inFIG. 2). In some embodiments, the hardware may include a slot that guides a customer to swipe or dip the magnetized strip of the magnetic strip card such that a magnetic strip reader can receive payment information from the magnetic strip card. The received payment information is then processed by the payment reader22.

Merchant device29may be any suitable device such as tablet payment device24, mobile payment device26, or payment terminal28. In the case of a computing device such as tablet payment device24or mobile payment device26, a point-of-sale application may provide for the entry of purchase and payment information, interaction with a customer, and communications with a payment server40. 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. Similar functionality may also be provided on a dedicated payment terminal28.

Merchant device29may be in communication with payment reader22via a communication path23/25/27. Although communication path23/25/27may be implemented via a wired (e.g., Ethernet, USB, FireWire, Lightning) or wireless (e.g., Wi-Fi, Bluetooth, NFC, or ZigBee) connection, in one embodiment payment reader22may communicate with the merchant device29via a Bluetooth low energy interface. In some embodiments, processing of the payment transaction may occur locally on payment reader22and merchant device29, for example, when a transaction amount is small or there is no connectivity to the payment server40. In other embodiments, merchant device29or payment reader22may communicate with payment server40via a public or dedicated communication network30. Although communication network30may be any suitable communication network, in one embodiment communication network30may be the internet and payment and transaction information may be communicated between payment terminal20and payment server40in an encrypted format such by a transport layer security (TLS) or secure sockets layer (SSL) protocol.

FIG. 3depicts a block diagram of an exemplary payment reader22in accordance with some embodiments of the present disclosure. In one embodiment, payment reader22may be a device that communicates with an interactive electronic device such as a merchant device29, for example, using USB, Bluetooth classic, or Bluetooth low energy. Although particular components are depicted in a particular arrangement inFIG. 3, it will be understood that payment reader22may include additional components, one or more of the components depicted inFIG. 3may not be included in payment reader22, and the components of payment reader22may be rearranged in a suitable manner. In one embodiment, payment reader22includes a reader chip100, a plurality of payment interfaces (e.g., a contactless interface102and a contact interface104), a power supply106, a wireless communication interface108, a wired communication interface110, a signal conditioning device112, and a user interface114. Payment reader22may also include a general processing unit120(e.g., a terminal/reader processing unit), general memory122, a cryptographic processing unit125and cryptographic memory128. Although in one embodiment the processing units and memories will be described as packaged in a reader chip100, and configured in a particular manner, it will be understood that general processing unit120, general memory122, a cryptographic processing unit125and cryptographic memory128may be configured in any suitable manner to perform the functionality of the payment reader22as is described herein. It will also be understood that the functionality of reader chip100may be embodied in a single chip or a plurality of chips, each including any suitable combination of processing units and memory to collectively perform the functionality of reader chip100described herein.

Processing unit120of reader chip100of payment reader22may be a suitable processor and may include hardware, software, memory, and circuitry as is necessary to perform and control the functions of payment reader22. Processing unit120may include one or more processors, and may perform the operations of reader chip100based on instructions in any suitable number of memories and memory types. In some embodiments, processing unit120may have multiple independent processing units, for example a multi-core processor or other similar component. Processing unit120may execute instructions stored in memory122of reader chip100to control the operations and processing of payment reader22. As used herein, a processor or processing unit may include one or more processors having processing capability necessary to perform the processing functions described herein, including but not limited to hardware logic (e.g., hardware designed by software that that describes the configuration of hardware, such as hardware description language (HDL) software), computer readable instructions running on a processor, or any suitable combination thereof. A processor may run software to perform the operations described herein, including software accessed in machine readable form on a tangible non-transitory computer readable storage medium.

In an exemplary embodiment, the processing unit120of reader chip100may include two RISC processors configured to operate as a hub for controlling operations of the various components of payment reader22, based on instructions stored in memory122. As used herein, memory may refer to any suitable tangible or non-transitory storage medium. Examples of tangible (or non-transitory) storage medium include disks, thumb drives, and memory, etc., but does not include propagated signals. Tangible computer readable storage medium include volatile and non-volatile, removable and non-removable media, such as computer readable instructions, data structures, program modules or other data. Examples of such media include RAM, ROM, EPROM, EEPROM, SRAM, flash memory, disks or optical storage, magnetic storage, or any other non-transitory medium that stores information that is accessed by a processor or computing device.

Reader chip100may also include additional circuitry (not depicted) such as interface circuitry, analog front end circuitry, security circuitry, and monitoring component circuitry. In one embodiment, interface circuitry may include circuitry for interfacing with a wireless communication interface108(e.g., Wi-Fi, Bluetooth classic, and Bluetooth low energy), circuitry for interfacing with a wired communication interface110(e.g., USB, Ethernet, FireWire, and Lightning), circuitry for interfacing with other communication interfaces or buses (e.g., I2C, SPI, UART, and GPIO), and circuitry for interfacing with a power supply106(e.g., power management circuitry, power conversion circuitry, rectifiers, and battery charging circuitry).

In an exemplary embodiment, reader chip100may perform functionality relating to processing of payment transactions, interfacing with payment devices, cryptography, and other payment-specific functionality. In some embodiments, reader chip100may include a cryptographic processing unit125for handling cryptographic processing operations. Note that each of general processing unit120and cryptographic processing unit125may have dedicated memory associated therewith (i.e., general memory122and cryptographic memory128). In this manner, specific cryptographic processing and critical security information (e.g., cryptographic keys, passwords, user information, etc.), may be securely stored by cryptographic memory128and processed by cryptographic processing unit125.

One or both of general processing unit120and cryptographic processing unit125of reader chip100may communicate with the other (e.g., processing unit120may communicate with cryptographic processing unit125and vice versa), for example, using any suitable internal bus and communication technique. In an embodiment, software routines running on each of the processing units may communicate with each other to exchange information, such as transaction processing information, requests for information, data objects, records, files, and similar information as described herein. In this manner, reader chip100can process transactions and communicate information regarding processed transactions (e.g., with merchant device29).

Reader chip100may also include circuitry for implementing a contact interface104(e.g., power and communication circuitry for directly interfacing with an externally-driven processing device such as an EMV chip of a chip card14that is inserted into slot21). For example, reader chip100may include circuitry to provide power and ground to an EMV chip that is inserted into contact interface104, and in some embodiments, a variable clock output (e.g., a frequency divider, voltage controlled oscillator, or other similar circuitry). In some embodiments, reader chip100also may also include analog front end circuitry for interfacing with the analog components of contactless interface102(e.g., electromagnetic compatibility (EMC) circuitry, matching circuits, modulation circuitry, and measurement circuitry).

Contactless interface102may provide for NFC communication with a contactless device such as NFC device12or chip card14. Based on a signal provided by reader chip100, an antenna of contactless interface102may 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 reader22is inductively coupled to a contactless device, the contactless device may also modulate the carrier signal, which may be sensed by the contactless interface102and provided to the reader chip100for processing. Based on these modulations of the carrier signal, payment reader22and a contactless device are able to communicate information such as payment information.

Contact interface104may be a suitable interface for providing power to an externally-driven processing device such as an EMV chip of a chip card14and communicating with the EMV chip. Contact interface104may include a plurality of contact pins (not depicted inFIG. 3) for physically interfacing with the chip card14according to EMV specifications. In some embodiments, contact interface104may include a power supply (VCC) pin, a ground (GND) pin, a reset (RST) pin for resetting an EMV card, a clock (CLK) pin for providing a clock signal, a programming voltage (VPP) pin for providing a programming voltage to an EMV card, an input output (I/O) pin for providing for EMV communications, and two auxiliary pins. In this manner, the payment reader and the chip card14are able to exchange information such as record request, payment information, and transaction information. In addition, the payment reader may control a processing speed of the chip card14by adjusting the rate of a clock signal provided to the chip card14via clock pin. Note that, in some embodiments, contact interface104may be housed on reader chip100and may communicate with the various components of reader chip100via any suitable means (e.g., a common internal bus).

Power supply106may include one or more power supplies such as a physical connection to AC power, DC power, or a battery. Power supply106may include power conversion circuitry for converting an AC or DC power source into a plurality of DC voltages for use by components of payment reader22. When power supply106includes a battery, the battery may be charged via a physical power connection, via inductive charging, or via any other suitable system. Although not depicted as physically connected to the other components of the payment reader22inFIG. 3, power supply106may supply a variety of voltages to the components of the payment reader22in accordance with the requirements of those components.

Wireless communication interface108may include suitable wireless communications hardware (e.g., antennas, matching circuitry, etc.) and one or more processors having processing capability necessary to engage in wireless communication (e.g., with a merchant device29via a protocol such as Bluetooth low energy) and control associated circuitry, including but not limited to hardware logic, computer readable instructions running on a processor, or any suitable combination thereof. Although wireless communication interface108may be implemented in any suitable manner, in an exemplary embodiment, wireless communication interface108may include a processing unit (not depicted) and memory (not depicted).

Wired communication interface110may include any suitable interface for wired communication with other devices or a communication network, such as USB, Lightning, FireWire, Ethernet, any other suitable wired communication interface, or any combination thereof. In some embodiments, wired communication interface110may allow payment reader to communicate with one or both of merchant device29and payment server40.

In some embodiments, reader chip100may include a signal conditioning device112. Although signal conditioning device112may include any suitable hardware, software, or any combination thereof, in an exemplary embodiment signal conditioning device112may comprise an FPGA. Signal condition device112may receive and condition signals sent from contactless interface102, such as when a payment device10using NFC communication communicates with payment reader22.

Payment reader may also include a user interface114. User interface114may provide one or more suitable systems for a user to interact with the payment reader22, such as buttons, a touch pad, a touch screen, a microphone, a speaker, a screen, a camera, a keyboard, or any suitable combination thereof. User interface114may allow the user to initiate actions of the payment reader22(e.g., initiating a reset mode, a sleep mode, a power-down, a low-power mode, or a transaction) and to respond to requests for information from the payment reader22.

In some embodiments, general memory122may be any suitable memory as described herein, and may include a plurality of sets of instructions for controlling operations of payment reader22and performing general transaction processing operations of payment reader22, such as operating instructions130, transaction processing instructions132, data authentication instructions134, and Clock control instructions136.

Operating instructions130may include instructions for controlling general operations of the payment reader22, such as internal communications, power management, processing of messages, system monitoring, sleep modes, user interface response and control, operation of the contact interface104, the wireless interface108, the wired interface110, or the signal conditioning device112, and the management of the other sets of instructions. In one embodiment, the operating instructions130may provide the operating system and applications necessary to perform most of the processing operations that are performed by the processing unit120of the reader chip100of payment reader22.

Operating instructions130may also include instructions for interacting with a merchant device29. In one embodiment, the merchant device29may be running a point-of-sale application. The operating instructions130may include instructions for a complementary application to run on processing unit120of reader chip100, in order to exchange information with the point-of-sale application. For example, the point-of-sale application may provide a user interface that facilitates a user such as a merchant to engage in purchase transactions with a customer. Menus may provide for the selection of items, calculation of taxes, addition of tips, and other related functionality. When it is time to receive payment, the point-of-sale application may send a message to the payment reader22(e.g., via wireless interface108). The operating instructions130facilitate processing of the payment, for example, by acquiring payment information via the contactless interface102or contact interface104, and invoking the various resources of reader chip100to process that payment information (e.g., by executing instructions stored in cryptographic memory128using cryptographic processing unit125), and by generating responsive messages that are transmitted to the point-of-sale application of the merchant device29via wireless communication interface108and wired communication interface110.

Operating instructions130may also include instructions for interacting with a payment service system50at a payment server40. In one embodiment, a payment service system50may be associated with the payment reader22and the point-of-sale application of the merchant device29. For example, the payment service system50may have information about payment readers22and merchant devices29that are registered with the payment service system50(e.g., based on unique identifiers). This information may be used to process transactions with servers of the merchant and customer financial institutions, for providing analysis and reports to a merchant, and aggregating transaction data. The payment reader22may process payment information (e.g., based on operation of reader chip100) and communicate the processed payment information to the point-of-sale application, which in turn communicates with the payment service system50. In this manner, messages from the payment reader22may be forwarded to the payment service system50of payment server40, such that the payment reader22and payment service system50may collectively process the payment transaction and exchange information as described herein (e.g., for storing information and rules relating to control of a clock signal to the contact interface104).

Transaction processing instructions132may include instructions for controlling general transaction processing operations of the payment reader22, such as controlling the interaction between the payment reader22and a payment device10(e.g., for interfacing with a payment device via the contactless interface102and contact interface104), selecting payment processing procedures (e.g., based on a payment processing entity associated with a payment method), interfacing with the cryptographic processor125, and any other suitable aspects of transaction processing.

Transaction processing instructions132also may include instructions for processing payment transactions at payment reader22. In one embodiment, the transaction processing instructions may be compliant with a payment standard such as those promulgated by EMV. Depending on the payment method that is being used (e.g., Europay, Mastercard, Visa, American Express, etc.), a particular processing procedure associated with the payment method may be selected and the transaction may be processed according to that procedure. When executed by processing unit120, these instructions may determine whether to process a transaction locally, how payment information is accessed from a payment device, how that payment information is processed, which cryptographic functions to perform, the types of communications to exchange with a payment server, and other suitable information related to the processing of payment transactions. In some embodiments, transaction processing instructions132may perform high level processing, and provide instructions for processing unit120to communicate with cryptographic processing unit125to perform most transaction processing operations, such as acquisition of records from the EMV card. In addition, transaction processing instructions132may provide instructions for acquiring any suitable information from a chip card (e.g., via contact interface104and cryptographic processing unit125) such as authorization responses, card user name, card expiration, etc.

Data authentication instructions134may include instructions for providing configuration information for a payment terminal20. The configuration information may include suitable information such as payment limits and types of transactions for local transactions (i.e., transactions that occur without contacting a payment server40) and supported applications. As an example, in some embodiments, data authentication instructions134may include configuration instructions such as TMS-CAPK instructions. In some embodiments, the TMS-CAPK may be tailored for a particular jurisdiction (e.g., country-specific).

In an embodiment, Clock control instructions136may comprise instructions that when executed by a processing unit (e.g., processing unit120) may adjust a clock speed or other characteristics of the clock signal that is provided to an EMV chip of an EMV card via a CLK pin of contactless interface. Although Clock control instructions136will be described herein as providing the clock signal to an EMV card in the present disclosure, it will be understood that the instructions may similarly provide a modifiable clock signal to other components or circuits (e.g., any suitable chip or components that are perform clocked operations based on an externally-provided clock signal). As described herein, characteristics of the provided clock signal (e.g., rate, duty cycle, slew rate, etc.) may be modified based on the clock control instructions136to provide for optimal timing and operation of the device or chip that receives the clock signal.

In an embodiment, the speed at which operations of the EMV chip of an exemplary EMV card are performed is modified by adjusting the clock rate of the clock signal that is provided to a chip card14inserted into the payment reader22, such as via contact interface104. As noted above, some EMV chip cards may be capable of performing internal operations and interpreting and generating messages (e.g., messages communicated via an I/O pin of contact interface104) at different rates based on a variety of factors such as card type, wear upon the card, environmental conditions, transaction type, or other similar factors. Clock control instructions136may include instructions for exchanging messages with such cards by increasing a clock rate provided to the data connection (e.g., EMV chip card data pin) to attempt to communicate messages with the EMV card at a higher clock rate.

Clock control instructions136may include instructions for initially selecting a clock signal with a clock rate and providing the clock signal to the EMV chip card via the clock signal connection. Clock control instructions136may select the clock signal based on various information, such as previous uses, transaction information, customer identity, merchant information, or otherwise. In some embodiments, Clock control instructions136may include instructions for selecting a clock rate of the clock signal based on information stored at a merchant device29, a remote server, such as payment server40of payment service system50, or other source. For example, a clock signal may be selected based on information generated from analysis of transaction histories for a particular scenario, such as time of day, location, merchant identification, environmental factors, goods or services for purchase, or other similar factors. Note that, in some embodiments, such information may be predictive in nature based on analysis of previous transactions and purchases.

Clock control instructions136may include instructions for selecting a clock signal having a clock rate that exceeds a specified clock rate for an EMV card. As noted herein, some EMV chip cards may be capable of executing instructions and exchanging messages at a higher clock rate than other EMV cards or than their specified clock rate. Clock control instructions136may include instructions for attempting to initially provide a clock signal with a high clock rate. In this manner, use of a higher clock rate for performing operations and exchanging messages with the EMV card may enable the EMV card to perform processing operations more quickly and for the payment reader22to communicate with the EMV card more quickly to decrease transaction time.

In some embodiments, clock control instructions136may include instructions for monitoring a data connection (e.g., at contact interface104) for one or more messages received from the EMV card. The received messages may be received based on transmitted messages provided to the data connection (e.g., based on transaction processing instructions132or otherwise). The one or more receive messages may include various information, such as an authorization request cryptogram (ARQC), acknowledgements, data records, requests for a transmitted message to be re-sent, and other related data and information.

Clock control instructions136may include instructions for determining that a clock rate of the clock signal provided to the EMV card is excessive. Clock control instructions136may include instructions for determining that the clock rate is excessive based on various information available at the payment reader22. For example, in some embodiments, a clock rate may be determined to be excessive based on failure to receive one of the one or more receive messages within a message timeout threshold, an excessive number of failed transmitted messages, incorrect data within the payload of received messages, and other similar information. A response threshold may relate to a duration within which the receive message should have been received following transmission of a corresponding transmit message of the one or more transmit messages. A response threshold may be based on other information in other embodiment, and may be determined for one or a plurality of the one or more receive messages by analysis of various information about transactions, merchants, customers, locations, EMV card types or otherwise. Other thresholds may relate to how often communication errors, percentages of failed or incorrect payload data, and other similar information relating to the quality of the processing and communications of the EMV chip.

As another example, in some embodiments, clock control instructions136may include instructions for determining that a clock rate is excessive based on receiving one of the one or more receive messages that has an error rate that exceeds an error rate threshold. Clock control instructions136may include instructions for comparing an error rate for each receive message of the one or more receive messages and comparing it with an error rate threshold stored at the payment reader22(e.g., in clock control instructions136in memory122). If a receive message has an associated error rate that does not exceed the error rate threshold, payment reader22may determine that the clock rate used for processing the receive message is not excessive. If the receive message has an associated error rate that exceeds the error rate threshold, the payment reader22may determine that the clock rate used for processing the receive message is excessive. Note that the error rate threshold may be based on various information, and may be determined for one or a plurality of the one or more receive messages by analysis of various information about transactions, merchants, customers, locations, EMV card types or otherwise.

As yet another example, in some embodiments, clock control instructions136may include instructions for determining that a clock rate is excessive based on failure of the EMV card to receive a transmit message. Clock control instructions136may include instructions for noting information in each of the one or more receive messages received from the EMV card and comparing it with information in a corresponding transmit message from the one or more transmit messages. If the information in the receive message indicates that a transmit message was not received (e.g., if a correlation threshold or rule is not satisfied or otherwise), a determination that the transmit message was not received by the EMV card may be made. Clock control instructions136may include instructions for determining that a transmit message was not received by the EMV card based on other information in other embodiments.

Clock control instructions136may include instructions for providing the clock signal at a second clock rate based on the determination that the initial clock rate was excessive for the proper operation of the EMV chip. In some embodiments, the second clock signal may have a second clock rate that is less than or equal to the specified clock rate for the EMV card. In some embodiments, the second clock signal may be selected based on analysis of various information about transactions, merchants, customers, locations, environmental information, EMV card types or other related information. In an embodiment, the determination of the second clock rate may be based on a severity of the errors (e.g., based on a degree to which the thresholds for response messages or data errors were exceeded at the first clock rate).

In some embodiments, sufficient information to determine a second clock rate that is less the initial clock rate but optimized for the particular chip card (e.g., that does not have an excessively low clock rate) may be unavailable. Clock control instructions136may include instructions for providing iteratively reducing the clock rate of a provided clock signal each time a determination is made that the clock rate is excessive. For example, clock control instructions136may include instructions for attempting to transmit one or more transmit messages at a clock rate, and if the clock rate is determined to be excessive, may select a lower clock rate for providing the one or more transmit messages. In some embodiments an iterative search pattern may be employed to selectively increase or decrease the clock rates by different amounts based on prior results for the chip card. This process may be repeated until a clock rate that is optimized for the particular chip card (and other current operational conditions) has been identified. In this regard, the payment reader22may be configured to identify a clock signal that permits exchange of messages with the EMV card to continue until the transaction is completed.

In some embodiments, if a clock rate is not determined to be excessive, Clock control instructions136may include instructions for selecting and providing the clock signal to the clock connection having at a clock rate that is higher than the initial clock rate. For example, clock control instructions136may include instructions for increasing the clock rate provided to the clock connection if a current clock rate is not determined to be excessive, such as when a predetermined number of transmit messages is successfully received by the EMV card or when error rates are less than a threshold.

In some embodiments, Clock control instructions136may include instructions for increasing the clock rate (e.g., iteratively by step or otherwise) until a threshold clock rate (e.g., a maximum clock rate) or clock rate measurement (e.g., error rate thresholds) has been reached. For example, if a clock rate is not determined to be excessive based on monitoring of the data connection, EMV instructions136may include instructions for selecting a clock signal having a higher clock rate to provide to the clock connection. If the higher clock rate is not excessive (e.g., based on monitoring receive messages or data at the data connection), a clock signal having a higher clock rate may be provided to the clock connection. In this regard, Clock control instructions136may include instructions for progressively increasing the clock rate until payment reader22reaches a maximum clock rate or begins to miss messages or send incorrect data. In an embodiment the thresholds use to increase the clock rate may be lower than the thresholds used to decrease the clock rates. In some embodiments, once the threshold for clock rate increases is reached, the clock rate may be decreased by a step decrease at which no errors were received or the number of errors was less than the threshold. Note that, in some embodiments, clock control instructions136may include instructions may modify the changes in clock rate (e.g., iterative steps, maximums, etc.) based on other operational conditions such transaction-specific information, environmental information, card type, merchant information, customer information, location, etc.

In some embodiments, clock control instructions136may include instructions for requesting a next transmit message in response to a determination that a clock rate is excessive. Clock control instructions136may include instructions for requesting, receiving and providing information stored at payment reader22(e.g., in general memory122or cryptographic memory128) about messages transmitted during a payment transaction. As described below, in some embodiments, receive messages may be stored at the payment reader22(e.g., in a receive message cache182in cryptographic memory128). Clock control instructions136may include instructions for requesting information about the last successfully received receive message of the one or more receive messages or data received in the receive message. Clock control instructions136may include instructions for identifying a next transmit message of the one or more transmit messages to provide to the data connection, such as at the second clock rate. Clock control instructions136may include instructions for requesting various data objects and information to minimize interruptions to transaction processing in other embodiments.

In an embodiment, processing of data as part of an initialization process may begin after the EMV card is placed in the EMV slot. Information may be obtained from the card that is used to identify information about the card (e.g., specified clock rates, identifying card information) or that may be used to identify known or probable information about acceptable clock rates for the card (e.g., based on information such as issuer, card type, cardholder, payment system, etc.). Based on this information, the clock control instructions136may execute one or more rules to store clock signal frequencies and transmit or receive messages in receive message cache182so that processing may be completed even if messages have been provided to the EMV card at an excessive clock rate and resulting messaging errors have occurred. In an embodiment, clock control instructions136can identify stored receive messages and allow payment reader22to identify the next transmit message to send. The rules of clock control instructions136may provide the last receive message when requested. Any data object (e.g., transmit or receive messages, or other data objects that are extracted from a read record) may be stored in the message cache182for future use in response to future data object requests.

Upon receipt of a request for data from the EMV card (e.g., based on a data object request), the clock control instructions136may perform a number of steps to return the requested information. In an embodiment, the clock control instructions136may first query the receive message cache182to determine whether the information has already been obtained and stored. If not, it may be determined from the requested information (e.g., transaction processing step, etc.) the next data processing steps that should be performed or next communication requests that should be provided to the EMV card. The current processing of payment transactions at a different clock rate may then continue based on information that has already been obtained, without having to repeat successful transaction processing steps or communications.

Clock control instructions136may include rules for managing data in receive message cache182. For example, rules in clock control instructions136may include specifications for determining what information (e.g., data objects, successful transmit or receive messages, etc.) to retain and when to remove or purge a data object from receive message cache182. In some embodiments, clock control instructions136may include instructions for storing a last receive message that was successfully received so that a next transmit message can be identified quickly. In some embodiments, rules in clock control instructions136may specify saving a copy of each receive message in receive message cache182until it is determined that a clock rate provided to the clock connection is appropriate. In some embodiments, clock control instructions136may include instructions for selecting a clock rate based on a clock rate history in receive message cache182(e.g., a previously provided clock rate). In some embodiments, clock control instructions136may include instructions for providing information that can be used for analysis of clock rates for different card types and conditions, such as to a payment service system50that aggregates data to make decisions and develop rules about particular clock rates, EMV cards, and conditions.

Although in the embodiment depicted inFIG. 3the clock control instructions136are depicted and described as being stored within memory122and executed by the processing unit120, it will be understood that clock control instructions136may be stored at other memory (e.g., cryptographic memory128) and executed by other processors (e.g., cryptographic processing unit125). In a similar manner, receive message cache182may be stored other than at cryptographic memory128(e.g., at general memory122) and may be utilized or executed at other processors (e.g., by general processing unit120). Moreover, it will be understood that any of the instructions or cache may be stored at multiple memories, and that any of the functionality related to EMV processing described herein may be combined in any suitable manner (e.g., into a single software routine or into additional software routines).

Cryptographic processing unit125may be any suitable processor as described herein, and, in some embodiments, may perform cryptographic functions for the processing of payment transactions. For example, in some embodiments a cryptographic processing unit125may encrypt and decrypt data based on one or more encryption keys, in a manner that isolates the encryption functionality from other components of payment reader22and protects the encryption keys from being exposed to other components of payment reader22.

In some embodiments, cryptographic memory128may be any suitable memory or combination thereof as described herein, and may include a plurality of sets of instructions for performing cryptographic operations, such as payment processing instructions176and cryptographic instructions178. In an embodiment, cryptographic memory128may also include a receive message cache182, which may provide quickly accessible storage of information relating to the EMV card and transactions, such as received EMV card messages or data objects obtained via READ RECORD requests.

Payment processing instructions176may include instructions for performing aspects of payment processing, such as providing for encryption techniques to be used in association with particular payment procedures, accessing account and processing information, any other suitable payment processing functionality, or any suitable combination thereof. Cryptographic instructions178may include instructions for performing cryptographic operations. Cryptographic processing unit125may execute the cryptographic instructions178to perform a variety of cryptographic functions, such as to encrypt, decrypt, sign, or verify a signature upon payment and transaction information as part of a payment transaction.

FIG. 4depicts an exemplary merchant device29in accordance with some embodiments of the present disclosure. Although a merchant device29may be implemented in any suitable manner, in one embodiment the merchant device29may be an interactive electronic device that provides a user interface and communicates with one or more other devices. Examples of interactive electronic devices include tablets, smart phones, smart watches, desktop computers, laptop computers, custom electronic devices, and other suitable electronic devices having the necessary user interface and communication capabilities to perform the functions described herein.

Although particular components are depicted in a particular arrangement inFIG. 4, it will be understood that merchant device29may include additional components, one or more of the components depicted inFIG. 4may not be included in merchant device29, and the components of merchant device29may be rearranged in any suitable manner. In one embodiment, merchant device29includes a processing unit202, a memory204, an interface bus206, a power supply208, a user interface210, a first wireless interface212, a second wireless interface214, and a wired interface216.

In one embodiment, the merchant device29includes a processing unit202and memory204that are configured to control and perform the necessary operations of the merchant device29. In one embodiment, the processing unit202may be a general purpose processor running instructions for a mobile operating system, programs, and applications based on instructions that may be stored in memory204. The memory204may include any suitable memory types or combination thereof as described herein, such as ROM, flash memory, and RAM, for storing instructions and other data and providing a working memory for the execution of the operating system, programs, and applications of the merchant device29. In one embodiment, the memory204may include a plurality of sets of instructions, such as operating instructions220, point-of-sale application instructions222, and EMV clock management instructions224.

The processing unit202may execute the instructions of memory204to interact with and control one or more other components of the merchant device29. Although the processing unit202may communicate with other components of the merchant device29in any suitable manner, in one embodiment the processing unit may utilize an interface bus206. Interface bus206may include one or more communication buses such as I2C, SPI, USB, UART, and GPIO. In one embodiment, the processing unit202may execute instructions of the memory and based on those instructions may communicate with the other components of the merchant device29via the communication buses of interface bus206.

Merchant device29may also include a power supply208. Power supply208may include power conversion circuitry for converting AC power and/or generating a plurality of DC voltages for use by components of merchant device29. When power supply208includes a battery, the battery may be charged via a physical power connection, via inductive charging, or via any other suitable method. Although not depicted as physically connected to the other components of merchant device29inFIG. 4, power supply208may supply a variety of voltages to the components of merchant device29in accordance with the requirements of those components.

Merchant device29may also include a user interface210. User interface210may provide various options for the user of the merchant device29to interact with applications and programs running on the merchant device29. An exemplary user interface210may include hardware and software for a suitable user interface, such as a touchscreen interface, voice command interface, keyboard, mouse, gesture recognition, other suitable user interface, or any suitable combination thereof. In one embodiment, the user interface210may be a touchscreen interface that displays an interactive user interface for programs and applications such as a point-of-sale application running on the merchant device29.

Merchant device29may also include a plurality of wireless communication interfaces. The wireless communication interfaces may include any suitable hardware and software for providing a wireless communication interface such as Bluetooth classic, Bluetooth low energy, WiFi, cellular, short message service (SMS), NFC, any other suitable wireless communication interface, or any combination thereof. In an embodiment, a first wireless communication interface212may be a wireless communication interface that primarily communicates with payment reader22(e.g., a Bluetooth low energy interface) while a second wireless communication interface214may be a wireless communication interface (e.g., WiFi) that primarily communicates with a payment service system50of payment server40(e.g., via the internet).

Merchant device may also include a plurality of wired interfaces216and218, which may include any suitable interface for wired communication with other devices or a communication network, such as USB, Lightning, FireWire, Ethernet, any other suitable wired communication interface, or any combination thereof. In an embodiment, wired interface216may primarily communicate with payment reader22(e.g., via USB) while wired interface218may primarily communicate with payment service system50(e.g., via Ethernet).

Operating instructions220may include instructions for controlling any suitable general operations of the merchant device29, such as internal communications, power management, control of I/O devices, control of communication devices, control of other hardware of the merchant device29, any other suitable instructions, or any combination thereof. In one embodiment, the operating instructions may provide instructions for the operating system of the merchant device29as well as most drivers, programs, and applications operating on the merchant device29.

Operating instructions220may include instructions for controlling the operations of the user interface210. The user interface210may be controlled in accordance with the instructions of programs and applications of the operating instructions220, point-of-sale application instructions222, and EMV clock management instructions224. Operating instructions220may also include instructions for interacting with a payment reader22and for interacting with a payment service system50at a payment server40. The payment reader22and/or the application running on the merchant device29may be known (e.g., via a registration process) to the payment service system50, such that the merchant device29may process payments with the payment service system50according to the point-of-sale application instructions222.

Point-of-sale application instructions222include instructions for running a point-of-sale application on the merchant device29. When executed by the processing unit202, the point-of-sale application instructions222may provide for a rich display of 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 perform any other suitable retail operations.

EMV clock management instructions224may provide operations and services for assisting with the processing of payment transactions at payment reader22and the intake and processing of information related to EMV card processing speed information at payment service system50. In an integrated payment terminal (e.g., where functionality of the payment reader22and merchant terminal are integrated into a single device) the functionality of EMV clock management instructions224may be integrated at the integrated payment terminal (e.g., with clock control instructions136and receive message cache182).

In an embodiment, EMV clock management instructions224may assist with selecting a clock rate during payment transactions. Aspects of the processing described for payment reader22(e.g., aspects of clock control instructions136and receive message cache182) may be offloaded to merchant terminal29. EMV clock management instructions224may assist with predictive selection of clock rates, execution of rules for identifying clock rate selection rules, and storage and processing of information that is acquired from the EMV card at different clock rates (e.g., to enable continuous operation while different clock rates are being utilized).

In an embodiment, EMV clock management instructions224may provide local processing to modify or create clock rate selection rules. As described in more detail with respect to the operations of payment service system50, data from numerous payment transactions may be aggregated and analyzed to generate rules for predictive selection of appropriate clock rates, storage and processing of received information, modifications to clock rates based on comparisons to thresholds and other information (e.g., card information, customer information, merchant information, environmental information, transaction information, etc.), and similar functionality to expedite the process of identifying the appropriate clock rate to be provided to an EMV chip card and adjusting the clock rate. A particular merchant terminal29may receive information from a limited number of sources (e.g., a limited subset of payment readers22that connect to the merchant device29, other merchant devices on shared networks, other merchant devices operated by the same entity, sensors of the merchant device, etc.). That limited information may be used to generate independent local rules (e.g., without regard to whether any rules are received from payment service system50), or in some embodiments, modifications to global rules received from payment service system50.

In an exemplary local rule, the merchant devices29may operate in a particular locality where a large percentage of EMV cards have similar specified clock rates, or where only a limited number of card types are used. Local rules may be created that prioritize clock rate selection based on these known likely clock rates, and may supplement or displace global rules in some embodiments.

In another exemplary local rule, merchants may have customer information (e.g., from loyalty programs, etc.) that may identify customers and associate customers with known EMV cards. In this manner, a library of payment cards and associated specified EMV card clock rates may be pre-loaded once a customer is identified. In an embodiment, customers may be identified by merchant biometric or monitoring systems (e.g., facial recognition, morphology, RFID devices, WiFi connections, GPS, cellular data, etc.) upon entering a queue, merchant location, or proximity to a merchant location, such that specified EMV card clock rate information may be identified and pre-loaded for the EMV cards previously used by the particular customer.

EMV clock management instructions224may also provide data to the payment service system50from payment reader22. This information may include card information, customer information, customer/specified EMV card clock rate associations, utilization of EMV cards having particular specified clock rates in processing payment transactions (e.g., clock rates that are frequently or infrequently used in payment transactions), and other similar information. This information may be forwarded to the payment service system, and in some embodiments, additional information may be appended. The additional information may be any suitable information that may be acquired by the merchant terminal29, such as customer information, customer preference information, geographic information, store-specific information, environmental information, purchased items, and other suitable information.

EMV clock management instructions224may also facilitate updates to the clock control instructions136and the receive message cache182. In some embodiments, EMV clock management instructions224may modify firmware updates received from payment service system50based on local rules.

FIG. 5depicts an exemplary payment service system50of a payment server40in accordance with some embodiments of the present disclosure. Although the payment service system50is depicted as a single server, it will be understood that the operations and memory of the payment service system50may be distributed over any suitable number of servers. Although particular components are depicted in a particular arrangement inFIG. 5, it will be understood that the payment service system50may include additional components, one or more of the components depicted inFIG. 5may not be included in the payment service system50, and the components of payment service system50may be rearranged in any suitable manner. It will also be understood that, in some embodiments, payment service system50may include the necessary components and have the necessary configuration to perform any of the functionality attributed to the payment server40herein. In one embodiment, payment service system50includes at least a processing unit302, a memory304, an interface bus306, a power supply308, and a communication interface310.

In one embodiment, the payment service system50includes a processing unit302and memory304that are configured to control and perform the necessary operations of the payment service system50. In one embodiment, the processing unit302of may be a high-speed processor running instructions for an operating system for the server, programs, and applications based on instructions that may be stored in memory304. The memory304may include any suitable memory types or combination thereof as described herein for storing instructions and other data and providing a working memory for the execution of the operating system, programs, and applications of the payment service system50. In one embodiment, the memory may include a plurality of sets of instructions, including but not limited to operating instructions320, payment processing instructions322, EMV clock analysis instructions324, and EMV clock rule instructions326. Memory304may also include EMV data storage328, which may provide for storage of information relating to clock rates for EMV cards, such as clock rate history for payment cards, card information, customer information, merchant information, and environmental information.

The processing unit302may execute the instructions of memory304to interact with and control one or more other components of the payment service system50. Although the processing unit302may communicate with other components of the payment service system50in any suitable manner, in one embodiment the processing unit302may utilize an interface bus306. Interface bus306may include one or more communication buses such as I2C, SPI, USB, UART, and GPIO. In one embodiment, the processing unit302may execute instructions of the memory304and based on those instructions may communicate with the other components of the payment service system50via the communication buses of interface bus306.

The payment service system50may also include a power supply308. Power supply308may include power conversion circuitry for converting AC power and/or generating a plurality of DC voltages for use by components of the payment service system50. In some embodiments, power supply308may include a backup system such as a battery backup, to avoid interruptions in service during power outages. Although not depicted as physically connected to the other components of the payment service system50inFIG. 5, power supply308may supply a variety of voltages to the components of the payment service system50in accordance with the requirements of those components.

The payment service system50may also include a communication interface310. Although communication interface310may include any suitable communication interface or combination thereof, in some embodiments, the communication interface310may utilize higher speed communication interfaces such as WiFi, cellular, Ethernet, or fiber optics. The communication interface310may establish a secured connection (e.g., via TLS or SSL) with a payment terminal20(e.g., payment reader22via merchant device29) in order to exchange messages relating to transactions to be processed, information relating to clock rates provided to EMV cards, firmware updates, application updates, etc. The communication interface310may also communicate with other servers of the payment server40such as payment servers, which may, in some embodiments, be located remotely from the payment service system50and operated by different entities than those that control the payment service system50. For example, in one embodiment, the payment service system50may be operated by an entity that provides one or more of the payment reader22, merchant device29, or point-of-sale application222. Payment servers may be associated with and operated by one or more of the merchant, issuer, or customer banks.

Memory304may include a plurality of data stores and a plurality of sets of instructions for performing the processing operations of the payment service system50, such as operating instructions320, payment instructions322, EMV clock analysis instructions324, EMV clock rule instructions326, EMV data storage328, and other suitable instructions and data stores for use in operating the payment service system50(e.g., instructions related to the operation of one or more other applications or components of the payment service system50).

Operating instructions320may include instructions for controlling suitable general operations of the payment service system50, such as internal communications, power management, control of communication devices, control of other hardware of the payment service system50, any other suitable instructions, or any combination thereof. In one embodiment, the operating instructions may provide instructions for the operating system of the payment service system50as well as most drivers, programs, and applications operating on the payment service system50.

Operating instructions320may also include instructions for interacting with a merchant device29. In one embodiment, the payment service system50may communicate with the merchant device29via the communication interface310. Operating instructions320may include instructions that when executed by processing unit302control these communications and provide for secure communication by implementing procedures such as TLS, SSL or as encrypted data based on keys.

Payment processing instructions322include instructions for processing payments, and may control the content of messages that are communicated to the merchant device29, payment reader22(e.g., via merchant device29), and/or payment servers. In one embodiment, the payment processing instructions may include information about each payment reader22and merchant device29having an installed point-of-sale application222. In addition to performing payment processing functions such as providing payment information such as amount and a credit card number to a transaction processing system and communicating responses back to the merchant, the payment service system50may also perform complex analysis of merchant data that may be used to provide reports, metrics, or other data to a merchant (e.g., a merchant operating a plurality of merchant devices29at a plurality of locations). Payment processing instructions322may also include instructions for accessing encryption keys such as a shared private key or a key of a public/private key pair for encrypting and decrypting data provided by one or more of a payment device10, payment reader22, or merchant device29.

EMV data storage328may provide a repository for storage of information relating to EMV transactions, such as EMV card clock rate rules, information relating to EMV card clock rates that is used to generate those rules, other data related to the determination and control of EMV clock rates, and any other suitable information related to operation of the payment terminal and payment system. In an embodiment, the stored data may include information relating to specified EMV card rates and other related information from transactions with payment readers that are in communication with the payment service system, message failure rates, related transaction information (e.g., payment system information, issuer information, etc.), store and customer information (e.g., provided by merchant terminals, environmental information, etc.), other suitable data, and associations therebetween. The stored data may also include rules for processing transactions based on such information, which may be organized for selection based on global, national, and local factors, e.g., to determine which EMV card rate rules should be provided to which merchant terminals and payment readers. In an exemplary embodiment, rules may be targeted based on information such as updates to EMV cards, merchant type, particular merchants, locality, customer demographics, environmental factors, etc., that may be associated with particular known or probable EMV cards and appropriate clock rates.

EMV clock analysis instructions324may assist with determining appropriate clock rates during payment transactions with connected payment terminals. Aspects of the processing described for payment reader22(e.g., aspects of clock control instructions136and receive message cache182) and/or merchant terminal29(e.g., EMV clock management instructions224) may be offloaded to the payment service system50. EMV clock analysis instructions324may assist with predictive selection of EMV clock rates, execution of rules for identifying EMV clock rates, parallel processing of payment transaction steps, and identification of information that may be used to determine likely EMV card and clock rate utilization (e.g., customer information, etc.).

EMV clock rule instructions326may provide for the creation, association, and storage of rules for selecting EMV card clock signal frequencies. As described herein, information may be provided from a variety of sources that may be determined to be associated with known or probable EMV cards and appropriate clock rates. Payment service system50may receive this information for a very large number of transactions on a daily basis, from a very large number of merchants and payment terminals. This data may be analyzed using a variety of techniques (e.g., supervised or unsupervised machine learning) in order to identify rules for identifying rules for selecting clock rates, such as initial clock rates and rules for iteratively modifying clock rates. These rules may be hierarchical such that global rules may apply to large categories of payment terminals, with numerous levels of modification and refinement applying to particular sub-categories such as merchant type, location, customer demographics, issuer card types, environmental factors, etc. EMV clock rule instructions326may provide for the generation of software updates that may be provided to payment terminals, e.g., to update instructions and stored record and data object information.

In view of the structures and devices described supra, methods that can be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flowcharts ofFIGS. 6-7. While, for purposes of simplicity of explanation, the methods are shown and described as a series of steps, it is to be understood and appreciated that such illustrations or corresponding descriptions are not limited by the order of the steps, as some steps may occur in different orders and/or concurrently with other steps from what is depicted and described herein. Any non-sequential, or branched, flow illustrated via a flowchart should be understood to indicate that various other branches, flow paths, and orders of the steps, can be implemented which achieve the same or a similar result. Moreover, not all illustrated steps may be required to implement the methods described hereinafter.

FIG. 6depicts a non-limiting flow diagram illustrating exemplary steps for selection of a clock rates for a clock signal to be provided to by a payment terminal to an EMV card in accordance with some embodiments of the present disclosure.

Processing ofFIG. 6may start at step602by establishing a physical connection with an externally-driven processing device such as an EMV chip of an EMV card. As described herein, the EMV card may have various physical connections (e.g. pins) for physically connecting to a payment terminal (e.g., at payment reader22). A physical connection may be established between the payment terminal and EMV card by inserting the EMV card into the payment terminal (e.g., the contact interface of payment reader22). In some embodiments, the physical connections may comprise a power connection, a ground connection, a clock connection, a reset connection, a data connection, and other additional connections. Once the EMV card is inserted, various signals may be exchanged with the EMV card via the physical connection. In some embodiments, the payment terminal may provide a power signal, a ground signal, and a clock signal to the EMV card, which may allow the EMV card to power up end perform operations based on the clock rate of the clock signal. Once the payment terminal has established a physical connection with the EMV card, at step602, processing may continue to step604.

At step604, power may be provided to the EMV card via the power and ground pins of the EMV card and payment terminal. As described herein, the payment terminal may provide a power signal and ground to the EMV card via the physical connection established at step602(e.g., power connection). After the payment terminal provides power to the EMV card, processing may continue to step606.

At step606, a clock signal may be provided to the EMV card's clock connection for use in processing a data signal received at the data connection during a payment transaction. In some embodiments, the first clock signal may be provided having a first clock rate and may be selected based on EMV card clock rate selection rules in a manner that improves processing speed of payment transactions, as described herein. For example, in some embodiments, information may be received before the card is inserted (e.g., merchant information, transaction information, customer information, environmental information, etc.) that may be used to select an initial clock rate. In some embodiments (not depicted inFIG. 6), an initial clock rate may be provided until identifying information is received from the card, after which a new clock rate may be selected. Once the initial clock rate has been selected and provided, processing may continue to step608.

At step608, the payment terminal may provide one or more transmit messages to the EMV card, such as by providing the one or more transmit messages to the physical data connection of the EMV card. The one or more transmit messages may be provided to the EMV card based on the initial clock rate. Once the one or more transmit messages have been provided to the data connection of the EMV card, processing may continue to steps610.

At step610, the payment terminal may monitor the data connection for one or more receive messages from the EMV card to determine whether the EMV card has received the one or more transmit messages correctly and whether the EMV card is able to properly perform processing information (e.g., whether the initial clock rate is excessive). The payment terminal may determine that one or more transmit messages were not received correctly based on information such as the type of receive message (e.g., a request to re-transmit), failure to receive the receive message within a threshold time, or incorrect or corrupt data received within the payload of the receive message (e.g., exceeding a threshold error rate). If it is determined from the receive messages that the EMV card received the one or more transmit messages correctly and was able to properly process a response, processing may continue to step612, at which the receive message is stored in a cache (e.g., in receive message cache182) before continuing to step618. If the one or more receive messages indicate that the one or more transmit messages were not received or processed correctly by the EMV card, processing may continue to step614.

At step614, after it has been determined that processing of the EMV card was not performed properly at the initial clock ate at step610, the payment terminal may select a second clock rate that is less than the initial clock rate. The second clock rate may be determined in a variety of manners as described herein, such as the specified clock rate for the EMV card (if the initial clock rate was greater than the specified clock rate), based on an iterative rate selection process, based on other information (e.g., customer information, merchant information, transaction information, location, environmental information, etc.), measurements of received signals from the EMV card, or information stored off-device (e.g., received from a merchant device or payment server). In some embodiments, other characteristics of the clock signal may change, such as the duty cycle, slew rate, etc. In some embodiments, other signals such as the power signal may be modified (e.g., to increase the voltage provided on the power connection). After the payment terminal determines the second clock rate and/or other signal modifications, the signals provided to the EMV card may be modified and processing may continue to step616.

At step616, the payment terminal may access receive message progress stored in the cache (e.g., receive message cache182) to determine the next transmit message. In some embodiments, the payment terminal may determine message progress based on receive message progress (e.g., with reference to the most recent receive messages or data stored in receive message cache182). After message progress has been accessed and a next step in transaction processing has been determined, processing may return to step608, where messaging may continue using the modified clock signal. As depicted inFIG. 6, in some embodiments this processing may continue through multiple iterations at which the clock rate may be increased (at step620), decreased (at step614), or retained at the same rate (step622).

At step618, after it has been determined that the current clock rate is not excessive, payment terminal may determine whether to increase clock rate, such as based on rate selection rules. For example, if no errors were determined from the receive messages or payload data, or if other information indicates that conditions are suitable for a higher clock rate, processing may continue to step620, where the payment terminal may increase the clock rate (e.g., based on selection rules) and/or other signal characteristics can provide the updated signals to the EMV card. After the rate of the clock signal has been increased, processing may return to step608, where the payment terminal may use the clock signal with increased rate to transmit the one or more transmit messages. If clock rate should not be increased at step618, processing may continue to step622.

At step622, it may be determined whether the processing of the transaction between the payment terminal and the EMV card is complete. If the processing is not complete, processing may return to step608. If the processing is complete, the steps ofFIG. 6may end.

FIG. 7depicts a non-limiting flow diagram illustrating exemplary steps for server-assisted selection of an EMV card clock rate in accordance with some embodiments of the present disclosure. The steps ofFIG. 7may be performed by suitable computing devices and/or software modules that are in communication with device and/or software modules that receive an EMV card, select a clock rate, and process payment transactions based using the selected clock rate. In exemplary embodiments, the processing steps ofFIG. 7may be performed by a merchant device, a payment service system, or a combination thereof.

Processing may begin at step702, at which a communication regarding an EMV card clock rate may be received. As described herein, various information may be communicated regarding EMV card processing, such as requests to assist in processing (e.g., to identify likely EMV card or clock rate utilization information), EMV card communication history information for analysis, and other information such as customer information, merchant information, transaction information, location, environmental information, etc. As described herein, this information may be utilized to assist in determining whether a clock rate should be changed, the type of change to the clock rate (e.g., via iterative or other methods), and modifications to local criteria that are provided to a payment terminal via software updates. Once the communication is received, processing may continue to step704.

At step704, it may be determined whether the communication requires a response. If a response is required, processing may continue to step706. If a response is not required, processing may continue to step708.

At step706, the response to the communication may be identified and transmitted. In some embodiments, the response may include information such as an EMV card clock rate to select, a sequence or range of clock rates to attempt, information to request from the EMV card, a sequence of transaction processing steps, software updates, and/or libraries of known specified EMV card clock signal rates for reference at the transaction processing device. Once the response is transmitted, processing may continue to step708.

At step708, existing clock rate information may be acquired for analysis. As described herein, EMV data storage may include information about clock rate history from numerous EMV cards and transactions, as well other information that may be useful in determining appropriate clock rates for EMV cards under different conditions. Existing information may include the raw data, existing rules, data models, and/or other suitable information. Once the existing record information is acquired, processing may continue to step710.

At step710, the clock rate rules may be updated based on information in the newly received communication. As described herein, a hierarchy of rules may be provided and updated based on newly acquired information. In some embodiments, updates may be performed at different intervals (e.g., periodically) and/or based on a quantity or type of acquired data (e.g., based on a certain volume of new data being acquired). Once the rules are updated, the processing ofFIG. 7may end.

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.