System and Method for Decoding as a Service

Abstract

A secure system and method for decrypting a payload is provided. In various embodiments, the systems and methods herein are configured to decode thousands of transactions per second. Furthermore, in certain embodiments, the systems and methods herein are scalable to process thousands of transactions per second when replicating certain architectural components.

Description

Technical Field

[0001] The present disclosure generally relates to point-to-point encryption (P2PE) and the management of point-to-point encryption systems.

Background Art

[0002] Protecting cardholder data during an electronic payment transaction is essential for all entities involved in processing that transaction. It has recently become apparent that significant data breaches occurred at major domestic retailers throughout the fourth quarter of 2013 and in 2014. In each case, the cardholder's account number and related cardholder personal data were illegally obtained by malicious fraudsters, and millions of carefully handled payment records were exposed to potential misuse, including identity theft. As a result, each retailer has suffered damage in terms of lost sales, fines, and potential litigation for alleged negligence regarding payment security standards. Another serious consequence of such breaches is brand erosion.

[0003] Data breaches are not new events in the payment industry, but the increasing number of breaches each year, their severity in terms of the number of records obtained, and the speed and sophistication at which such breaches occur are new.

[0004] The question is not whether a business will be breached, but when. While it is impossible to eliminate the possibility of a data breach, it is currently possible to protect the integrity of cardholder data in the event of a breach through PCI-verified point-to-point encryption (P2PE). PCI-verified P2PE renders any potential cardholder data useless and valueless because the cardholder data cannot be decrypted in the event of a data theft.

Summary of the Invention

Means for Solving the Problems

[0005] In various embodiments, the systems and methods herein include a point-to-point encryption management system configured to receive information from a plurality of franchise terminal devices, the point-to-point encryption management system including: a) a database storing device information; and b) at least one processor operably coupled to the database, the at least one processor being configured to: 1) receive a payload supplied from a franchise terminal device, the payload including encrypted payment information and a device identifier; 2) analyze the payload to extract the device identifier; 3) search an identifier table from the database, the identifier table including one or more device identifiers received by the point-to-point encryption management system; 4) compare the device identifier with the identifier table to determine whether the device identifier is included in the identifier table; and 5) if it is determined that the device identifier is included in the identifier table, be configured to facilitate decryption of the encrypted payment information.

[0006] According to certain embodiments, the systems and methods herein include a point-to-point encryption management system configured to receive information from a plurality of franchise terminal devices, the point-to-point encryption management system including: a) a database storing device information; and b) at least one processor operably coupled to the database, the at least one processor being configured to: 1) receive a payload supplied from a franchise terminal device, the payload including encrypted data and a serial number of the device; 2) analyze the payload to extract the serial number of the device; 3) search a serial number table from the database, the serial number table including one or more serial numbers received by the point-to-point encryption management system; 4) compare the serial number of the device with the serial number table to determine whether the serial number of the device is included in the serial number table; 5) if it is determined that the serial number of the device is included in the table, search from memory a fingerprint associated with the record of the franchise terminal device, the fingerprint being an identifier created by the point-to-point encryption management system of the franchise terminal device based on the format of one or more payloads supplied from the franchise terminal device; 6) compare the payload with the fingerprint to determine whether the franchise terminal device has been accessed illegally; 7) if it is determined that the franchise terminal device has not been accessed illegally, be configured to facilitate decryption of the encrypted payment card information.

[0007] In one or more embodiments, the systems and methods herein include a computer-implemented method for decrypting encrypted data, the computer-implemented method including: A) providing at least one encryption device including at least one processor configured to transmit the encrypted data and the serial number of the device; and B) providing an encryption management system configured to receive information from the encryption device and at least one computer terminal located at a key injection facility, the encryption management system including: a) a database storing device information; and b) at least one processor operatively coupled to the database, the at least one processor being configured to: 1) receive an initial serial number of the device from at least one terminal located at the key injection facility; 2) write the initial serial number of the device to a table in memory and store the table in the database; 3) receive a payload generated at least in part from the encryption device, the payload including the encrypted data and the serial number of the device; 4) analyze the payload to extract the serial number of the device; 5) search the database for the table; 6) compare the serial number of the device with the initial serial number of the device to determine whether the serial number of the device is included in the table; and 7) when it is determined that the serial number of the device and the initial serial number of the device are the same serial number, be configured to facilitate decryption of the encrypted data.

[0008] According to some embodiments, the systems and methods herein include a computer system for point-to-point encryption of payment transactions, the computer system including: A) at least one merchant terminal device including a) one or more magnetic read heads for reading a consumer's payment card, and b) at least one processor configured to transmit the consumer's payment card information and the serial number of the device associated with at least one merchant terminal device; B) a hardware security module configured to decrypt the payment card information; and C) a point-to-point encryption management system configured to receive information from at least one computer terminal located at the merchant terminal device and the key injection facility, the point-to-point encryption management system including a) a database for storing device information, and b) at least one processor operatively coupled to the database, the at least one processor being configured to: 1) receive an initial device serial number from at least one computer terminal located at the key injection facility; 2) write the initial device serial number to a table in memory and store the table in the database; 3) receive a first payload supplied by the merchant terminal device, the first payload including first encrypted payment card information and a device serial number; 4) analyze the payload to extract the device serial number; 5) search the database for the table; 6) compare the device serial number with the initial device serial number to determine whether the device serial number is included in the table; 7) if it is determined that the device serial number and the initial device serial number are the same serial number, then i) facilitate decryption of the payment card information, and ii) create a fingerprint of the merchant terminal device based on the format of the first payload and store a payload identifier in memory; 8) receive a second payload generated by the merchant terminal device, the second payload including encrypted second payment card information and a device serial number; 9) analyze the received second payload to extract the device serial number; 10) search the database for the table,11) Compare the serial number of the device with the initial serial number of the device to determine whether the serial number of the device is included in the table. 12) If it is determined that the serial number of the device and the initial serial number of the device are the same serial number, search for the fingerprint. 13) Compare the second payload with the fingerprint to determine whether the franchise terminal device has been illegally accessed. And 14) If it is determined that the franchise terminal device has not been illegally accessed, it is configured to send the second payment information to the hardware security module for decryption.

[0009] In at least one embodiment, the systems and methods herein include a computer system for decrypting payment transactions, the computer system including: A) at least one merchant terminal device configured to transmit consumer payment card information and the serial number of a device associated with at least one merchant terminal device, and B) a point-to-point encryption management system configured to receive information from the merchant terminal device and at least one computer terminal located at a key injection facility, the point-to-point encryption management system including: a) a database for storing device information, and b) at least one processor operably coupled to the database, the at least one processor being configured to: 1) receive the serial number of an initial device from at least one computer terminal located at a key injection facility; 2) write the serial number of the initial device to a table in memory and store the table in the database; 3) receive a payload at least partially supplied by the merchant terminal device, the payload including encrypted payment card information and the serial number of a device; 4) analyze the payload to extract the serial number of the device; 5) search the database for the table; 6) compare the serial number of the device with the serial number of the initial device to determine whether the serial number of the device is included in the table; and 7) if it is determined that the serial number of the device and the serial number of the initial device are the same serial number, be configured to facilitate decryption of the payment card information.

[0010] In a further embodiment, the systems and methods herein include a computer-implemented method for decrypting payment transactions, the method comprising: 1) providing at least one merchant terminal device including one or more processors configured to transmit consumer payment information and the serial number of a device associated with at least one merchant terminal device; 2) providing a point-to-point encryption management system configured to receive information from the merchant terminal device, the point-to-point encryption management system including: a) a database storing device information; and b) at least one processor operably coupled to the database; 3) receiving, by at least one processor, from at least one computer of a third-party computing device an initial device serial number; 4) writing, by at least one processor, the initial device serial number to a table in memory and storing the table in the database; 5) receiving, by at least one processor, a payload at least partially provided by the merchant terminal device, the payload including encrypted payment information and the serial number of the device; 6) parsing, by at least one processor, the payload to extract the serial number of the device; 7) comparing, by at least one processor, the serial number of the device with the initial device serial number to determine whether the serial number of the device and the initial serial number are the same serial number; and 8) facilitating decryption of the payment information if it is determined that the serial number of the device and the initial device serial number are the same serial number.

[0011] According to various embodiments, the systems and methods herein include a computer system that creates a fingerprint of a device, the computer system including a device operably connected to a device management system, the device management system including at least one processor operably coupled to at least one database, the at least one processor configured to: 1) receive a first payload from the device, the first payload including data of a particular format and a device indicator, the device indicator including a unique identifier used to identify the device; 2) create a fingerprint of the device, the fingerprint including the section format of each of one or more separate sections of a particular format in a particular order; 3) store a record of the fingerprint of the device and the unique identifier in at least one database; and 4) compare the format of each subsequent payload received from the device with the fingerprint of the device to determine whether the device has been accessed illicitly.

[0012] In a particular embodiment, the systems and methods herein include a computer system that creates a fingerprint of a device, the computer system including a device operably connected to a device management system, the device management system including at least one processor operably coupled to at least one database, the at least one processor configured to: 1) receive a payload from a particular device, each payload including encrypted data of a certain format and unencrypted data; 2) compare the format of each payload from the particular device with a fingerprint associated with the particular device; and 3) if it is determined that the particular payload format of the payload received from the particular device does not match the fingerprint associated with the particular device, reject decrypting the encrypted data of the particular payload and send a notification rejecting decrypting the encrypted data to a user computing system associated with the user.

[0013] According to one or more embodiments, the systems and methods herein include a computer-implemented method for creating a fingerprint of a device, the method comprising: A) providing a device capable of encrypting data; B) providing a computer system operably coupled to the device, the computer system including: 1) decryption means for decrypting data received from the device; 2) fingerprint creation means for creating a fingerprint associated with the device; 3) at least one database; and 4) at least one processor operably coupled to the decryption means, the fingerprint creation means, and the at least one database; C) receiving, by the at least one processor, a first payload from the device, the first payload including data in a specific format, a device indicator, and encrypted data, the device indicator including a unique identifier used to identify the device; D) creating, by the fingerprint creation means, a fingerprint of the device, the fingerprint including the section format of each of one or more separate sections in a specific format in a specific order; E) storing a record of the fingerprint of the device and the unique identifier in the at least one database and actively changing the state of the device by the at least one processor; F) comparing, by the at least one processor, a second specific format of a subsequent payload received from the device with the fingerprint of the device to determine whether the device has been accessed illegally; and G) decrypting, by the decryption means, the encrypted data of the subsequent payload if it is determined that the device has not been accessed illegally.

[0014] In at least one particular embodiment, the systems and methods herein include a computer system that includes at least one processor and that manages state changes of an encryption device that is operably connected to a P2PE management system, where the at least one processor is configured to change the state of the encryption device based on transaction information received from the encryption device, and changing the state of the encryption device based on the transaction information includes: 1) receiving a transaction payload from the encryption device, where the transaction payload includes transaction information and non-transaction information; 2) determining whether the transaction information is encrypted; and 3) disabling the encryption device by changing the state of the encryption device to a tampered state in response to determining that the transaction information is not encrypted.

[0015] In a further embodiment, the systems and methods herein include a computer-implemented method for managing state changes of an encryption device, the method including: A) providing a P2PE management system that includes at least one processor and that is operably connected to the encryption device; and B) changing, by the at least one processor, the state of the encryption device based on transaction information received from the encryption device, where changing the state of the encryption device based on the transaction information includes: 1) receiving a transaction payload from the encryption device, where the transaction payload includes transaction information and non-transaction information; 2) determining whether the transaction information is encrypted; and 3) disabling the encryption device by changing the state of the encryption device to a tampered state in response to determining that the transaction information is not encrypted.

[0016] In a further embodiment, the systems and methods herein include a computer system for managing state changes of an encryption device, including a P2PE management system that includes at least one processor and is operably connected to the encryption device. The at least one processor is configured to: A) change the state of the encryption device based on an input from an operator; and B) change the state of the encryption device based on transaction information received from the encryption device. Changing the state of the encryption device based on transaction information includes: 1) receiving a first transaction payload from the encryption device, the first transaction payload including first transaction information and first non-transaction information; 2) upon receiving the first transaction payload from the encryption device, changing the state of the encryption device from a deployed state to an active state and facilitating decryption of the first transaction information; 3) receiving a second transaction payload from the encryption device, the second transaction payload including second transaction information and second non-transaction information; 4) determining whether the second transaction information is encrypted or not; and 5) disabling the encryption device by changing the state of the encryption device from the active state to a tampered state in response to a determination that the second transaction information is not encrypted.

[0017] According to certain embodiments, the systems and methods herein include a system for decrypting payloads, the system including a front-end server operably connected to a read-only database, the front-end server: a) receiving a plurality of payloads from one or more third parties, each payload including at least one encrypted element; b) retrieving authentication data from the read-only database; c) comparing the authentication data with each of the plurality of payloads to determine whether one or more of the plurality of payloads have been accessed illicitly; d) upon determining that one or more of the plurality of payloads have not been accessed illicitly, sending one or more of the plurality of payloads to a hardware security module for decryption of at least one encrypted element; a read-only database operably connected to the front-end server and configured to store read-only authentication data used to determine whether a payload has been accessed illicitly; and a hardware security module operably connected to the front-end server and configured to decrypt one or more of the plurality of encrypted payloads based on an encryption key and send the decrypted one or more payloads to one or more third parties.

[0018] In one or more embodiments, the systems and methods herein include a computer-implemented method for decrypting a payload, the method comprising providing a front-end server operably connected to a read-only database, the front-end server: a) receiving a plurality of payloads from one or more third parties, each of the payloads including at least one encrypted element; b) retrieving authentication data from the read-only database; c) comparing the authentication data with each of the plurality of payloads to determine whether one or more of the plurality of payloads have been accessed without authorization; and d) upon determining that one or more of the plurality of payloads have not been accessed without authorization, providing one or more of the plurality of payloads to a hardware security module for decrypting at least one encrypted element. The method further includes providing a read-only database operably connected to the front-end server and configured to store read-only authentication data used to determine whether a payload has been accessed without authorization, and providing a hardware security module operably connected to the front-end server, the hardware security module being configured to decrypt one or more of the plurality of encrypted payloads based on an encryption key and to transmit the decrypted one or more payloads to one or more third parties.

[0019] According to some embodiments, the systems and methods herein include an extensible system for quickly decrypting a payload, the system being operably connected to one or more front-end servers and including at least one hardware security module configured to decrypt encrypted elements of the payload, one or more front-end servers configured to receive and authenticate a payload based at least in part on a search for authentication data from a particular read-only database of one or more read-only databases, one or more read-only databases operably connected to the one or more front-end servers, the one or more read-only databases including authentication data for authenticating the payload, a read-only master database operably connected to the one or more read-only databases, the read-only master database being configured to refresh authentication data stored in the one or more read-only databases, and a back-end read / write database for logging decryption and authentication, the back-end read / write database being operably connected to the at least one hardware security module and the read-only master database.

[0020] In at least one embodiment, the systems and methods herein include a system for quickly decrypting one or more payloads, the system comprising a message queuing protocol operably connected to a read-only database and a read / write database, the message queuing protocol being configured to receive event notifications from the read-only database, each event notification including one or more notifications regarding the authentication of one or more received payloads, queue the event notifications received from the read-only database, and transmit the event notifications to the read / write database when it is determined that the read / write database is configured to receive the event notifications.

[0021] In a further embodiment, the systems and methods herein include a computer-implemented method for rapidly decrypting one or more payloads, the method including provisioning a message queuing protocol operably connected to a read-only database and a read-write database, the message queuing protocol receiving event notifications from the read-only database, each event notification including one or more notifications regarding the authentication of one or more received payloads, queuing the event notifications received from the read-only database, and, upon determining that the read-write database is configured to receive the event notification, being configured to send the event notification to the read-write database.

[0022] According to various embodiments, the systems and methods herein include a system for rapidly decrypting one or more payloads, the system including: a front-end server that receives an encrypted payload, a plurality of read-only databases operably connected to the front-end server, a master read-only database operably connected to each of the plurality of read-only databases, and a read-write database operably connected to the master database, the read-write database being configured to send an event message to the master read-only database, the system receiving event information at the read-write database and, upon receiving the event information at the read-write database, automatically sending authentication data to the master read-only database, the authentication data being updated by the event information, refreshing the read-only master database, including the authentication data, and refreshing each of the plurality of read-only databases with matching authentication data from the refreshed read-only master database, the authentication data being further configured to determine whether the payload was sent by a device that has been tampered with.

[0023] In certain embodiments, the systems and methods herein include a computer-implemented method for rapidly decrypting one or more payloads, the method comprising preparing a front-end server to receive an encrypted payload, preparing a plurality of read-only databases operably connected to the front-end server, preparing a master read-only database operably connected to each of the plurality of read-only databases, preparing a read-write database operably connected to the master database, the read-write database sending an event message to the master read-only database, receiving event information in the read-write database, automatically sending authentication data to the master read-only database upon receiving the event information in the read-write database, the authentication data being updated by the event information, refreshing the read-only master database to include the authentication data, and refreshing each of the plurality of read-only databases with authentication data matching the refreshed read-only master database, the authentication data being for determining whether the payload was sent by a tampered device.

[0024] According to one or more embodiments, the systems and methods herein include a system for decrypting one or more payloads, the system including a hardware security module that decrypts encrypted elements of a received payload, the hardware security module being operably connected to at least one decryption server, at least one decryption server that receives a specific payload including at least one encrypted element, sends the specific payload to the hardware security module for decryption of the at least one encrypted element, upon receiving the specific payload from the hardware security module, analyzes the specific payload, determines whether the at least one encrypted element has been decrypted by the hardware security module, and, upon determining that the at least one encrypted element has not been decrypted by the hardware security module, is configured to send an error message to a read / write database operably coupled to a front-end server.

[0025] In at least one particular embodiment, the systems and methods herein include a computer-implemented method for decrypting one or more payloads, the method comprising providing a hardware security module that decrypts encrypted elements of a received payload, the hardware security module being operably connected to at least one decryption server, providing at least one decryption server, receiving a particular payload, the particular payload including at least one encrypted element, sending the particular payload to the hardware security module for decryption of the at least one encrypted element, upon receiving the particular payload from the hardware security module, parsing the particular payload and determining whether at least one encrypted element has been decrypted by the hardware security module, and upon determining that at least one encrypted element has not been decrypted by the hardware security module, sending an error message to a read / write database operably coupled to a front-end server.

Brief Description of the Drawings

[0026]

Figure 1

Figure 2A

Figure 2B

Figure 2C

Figure 3

Figure 4A

Figure 4B

Figure 5A

Figure 5B

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

DETAILED DESCRIPTION OF THE INVENTION

[0027] To facilitate understanding of the principles of the present disclosure, reference is now made to the embodiments shown in the drawings and specific language is used to describe the embodiments. Nevertheless, it is not intended thereby to limit the scope of the present disclosure, and any alternative and further modifications of the described or illustrated embodiments, as well as any further applications of the principles of the present disclosure as shown in those embodiments, are intended to be commonly contemplated by those skilled in the art to which the present disclosure pertains.

[0028] The accompanying drawings show one or more embodiments and / or aspects of the present disclosure and, together with the specification, serve to explain the principles of the present disclosure. The following plurality of figures are unified modeling language (UML) 2.5 sequence diagrams. UML sequence diagrams focus on message exchanges between multiple lifelines (also known as individual participants). Those skilled in the art will understand that UML diagrams are read from left to right and top to bottom. For more information on UML diagrams, refer to www.uml-diagrams.org / sequence-diagrams-combined-fragment.html.

[0029] Before the detailed description of the present disclosure, the following definitions are provided to assist in the understanding of the subject matter, and the terms of the aspects of the systems and methods of the present invention are exemplary and do not necessarily limit the aspects of the systems and methods described in the claims. Whether a term is described in uppercase or not is not considered to limit or restrict the meaning of the term. As used herein, a term described in uppercase shall have the same meaning as the term described in lowercase unless specifically indicated otherwise by the context in which it is used that a more restricted meaning of the term described in uppercase is intended. However, whether a term is described in uppercase in the remainder of this specification is not necessarily intended to be such a limitation unless the context clearly indicates that a limitation is intended.

[0030] Definitions / Glossary Account data: Can refer to cardholder data and / or authentication data to be handled with care, such as, but not limited to, PAN, bank branch code, cardholder name, expiration date, service code, magnetic stripe data (or chip data), card security code (e.g., CAV2, CVC2, CVV2, CID, etc.), one or more passwords (PIN) numbers and / or PIN block.

[0031] Bank: Any suitable banking entity that can issue one or more cards (e.g., credit cards, debit cards, etc.) to consumers, receive deposits (e.g., from merchants), and manage customers' deposit accounts.

[0032] Fingerprint or device fingerprint: In various embodiments, a set of information used to identify a particular device, which can be based on one or more attributes of the particular device. In at least one embodiment, the set of information is for a POI device and includes the serial number associated with the POI device.

[0033] Hardware Security Module (HSM): In various embodiments, it is a device that protects, houses, and manages digital encryption and decryption keys.

[0034] Key Injection Facility (KIF): It is a secure service facility that injects encryption keys (e.g., symmetric or asymmetric keys) into a device, usually a POI device. In certain embodiments, the injected encryption key is used to encrypt data (e.g., consumer data such as PAN data) received by the POI device.

[0035] Merchant: It is an entity that provides or sells goods and / or services to consumers. In various embodiments, it purchases, orders, and / or employs one or more POI devices and uses a P2PE manager.

[0036] P2PE Manager: In various embodiments, it is an application, software, hardware, and / or virtual machine that manages various state changes of POI devices, reports state changes of the POI device(s), requests decryption key index names, authenticates third - party partners and devices, and / or provides reports to merchants for compliance or other purposes.

[0037] P2PE Payload, Transaction Payload, or Payload: A bundle of information transmitted from a POI device. The payload can contain any of a variety of suitable information. As a non - limiting example, in certain embodiments, the payload includes consumer information such as the card's PAN and the serial number of the POI device. In various embodiments, the payload is sent to the P2PE manager. In at least one embodiment, the payload is sent to the payment processor / payment network before decryption.

[0038] Payment Card Industry (PCI): Generally, the debit, credit, prepaid, e - purse, e - wallet, ATM, and point - of - sale card industries and related businesses.

[0039] Payment Processor / Payment Network: One or more entities (usually third - parties) that process payments to merchants (e.g., credit card transactions). PCI Security Standards Council: A council originally formed by American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International that manages the PCI Data Security Standards. By meeting the various PCI Security Standards Council requirements, a business can be considered "PCI - compliant" or "PCI - valid".

[0040] PCI Validation / Valid (PCI - compliant): An entity can be considered PCI - valid by meeting the various criteria specified by the PCI Security Standards Council. PCI - valid companies and / or solutions can be listed by the PCI Security Standards Council (e.g., on the PCI Security Standards Council's website or other suitable locations).

[0041] Point of Interaction (POI) Device (Point - of - Entry Device): In various embodiments, a component of a point - of - sale system that enables a consumer to make a purchase at a merchant using a payment card, etc. The POI device may or may not be face - to - face with the consumer and may require a PIN number and / or other authentication. Non - limiting examples of POI devices include magnetic card readers (e.g., that read payment cards such as credit cards) and near - field communication (NFC) devices (e.g., that receive a consumer's payment information from an electronic device such as a mobile device). The POI device may or may not be an approved device by the PCI Council.

[0042] Point to Point Encryption (P2PE): A combination of secure devices, applications, and processes that encrypt data from a merchant terminal (e.g., the swipe location) until it reaches the secure decryption environment of the solution provider.

[0043] Primary Account Number (PAN): The account number (e.g., credit card number) typically seen on the front of a payment card. Status (es): The recordable states and / or situations of a particular device such as a POI device. Various states and / or situations can include "new", "active", "lost", "stolen", "tampered", "damaged", "malfunctioning", "isolated", "repaired", "retired", and "destroyed".

[0044] Status change: A recordable change in the state of a device such as a POI device. In a specific example, the state of a POI device can be changed from "active" to "lost" based on various factors. Overview The systems and methods of the present invention comprehensively relate to the management of encryption processes, the management of encryption devices, the verification process of encryption devices (including point-to-point encryption devices), and the reporting of the management, allocation, and status changes of encryption devices. According to certain embodiments, the systems and methods of the present invention track the processing of decryption devices and their respective payloads (e.g., the output of swipe data, etc.). It should be understood from the disclosure herein that the management of the encryption processes described herein can be PCI valid and compliant in some embodiments.

[0045] According to certain embodiments, the systems and methods herein relate to the handling of secure encryption devices. In particular, the systems and methods herein relate to: 1) receiving an indication of the state of a particular device; 2) receiving a payload from a particular device, the payload including the serial number of the device and an encrypted payload; 3) creating a record (e.g., fingerprint) of the format of the payload and storing the record in memory; 4) receiving a second payload from a particular device, the second payload including the serial number of the device and a second encrypted payload; 5) retrieving from memory a record of the format of the payload associated with a particular device; 6) comparing the record of the format of the payload with the format of the second payload; and 7) changing the state of the particular device to a tampered state if it is determined that the format of the second payload does not match the record of the format of the payload.

[0046] In one or more aspects, the systems and methods herein relate to facilitating the decryption of the payload of an encryption device based on the serial number of the device included in the payload. In these (and other) aspects, the system is configured to retrieve various information regarding a particular device from a database based on the serial number of the device. Such data can include, for example, a record of the format of the first payload of a particular device (as described above), a key index number indicating a base key used to encrypt the payload of a particular device, the state of a particular device, and the like.

[0047] According to various aspects, the systems and methods herein further relate to creating a "fingerprint" of a particular device. In particular, the system can create a fingerprint of a particular device for use as a comparison against a payload received from the particular device and determine whether the particular device has been accessed illicitly (e.g., the device has been stolen, hacked, etc.). The system can be configured to create a fingerprint of a particular device in any suitable manner, such as by analyzing a first payload received from the particular device, determining the format of each segment of the first payload, recording the format of each segment of the first payload in the order of the payload, etc.

[0048] In some aspects, the systems and methods herein relate to creating a report regarding the state and location of an encrypted device tracked by the system. In these aspects, the system is configured to receive a report request from a merchant, compile a report based on state information associated with an encrypted device associated with the merchant, request that the merchant attest to the information included in the report, and provide the report to the merchant.

[0049] As will be understood by those skilled in the art, the systems and methods herein can be used by any suitable entity. Further, the systems and methods described herein can be used in any suitable encryption / decryption process, including but not limited to point-to-point encryption, encryption / decryption of medical data, encryption / decryption of social security numbers, etc. The following exemplary functions of the systems and methods herein are included to facilitate understanding of the systems and methods included and are intended to be exemplary and non-limiting.

[0050] Exemplary P2PE Manager and Payment Function Referring now to the drawings, FIG. 1 shows a high-level exemplary P2PE manager as well as a payment environment and process. Generally, FIG. 1 shows an exemplary path of an exemplary point-of-sale (POI) device from a manufacturer (e.g., manufacturer 102) to a merchant (e.g., merchant 132), as well as various processes and state changes associated with the exemplary POI device. FIG. 1 further shows data received by the P2PE system 160, exemplary high-level data processing occurring in the P2PE system, and an exemplary payment cycle.

[0051] FIG. 1 shows an exemplary P2PE manager and process, and (as will be understood by those skilled in the art, data may be typed into the user interface) swipe data is sent from the merchant's swipe terminal (e.g., a POI device) to the payment environment and then to the P2PE payment system.

[0052] FIG. 1 shows manufacturer 102 of a point-of-sale (POI) device (e.g., POI device 104). According to certain embodiments, manufacturer 102 manufactures POI device 104 in response to receiving an order from a merchant or a P2PE system (e.g., P2PE system 160). In various embodiments, manufacturer 102 manufactures POI device 104 (and any other POI device) in any suitable manner, as will be understood by those skilled in the art. In certain embodiments, manufacturer 102 manufactures a POI device configured to output the serial number and information of the device in a specific format, as further described herein.

[0053] POI device 104 can be any device suitable for receiving information from a consumer. In various embodiments, POI device 104 receives payment information as described throughout this specification, but it should be understood by those skilled in the art that POI device 104 should not be considered limited to only payment information.

[0054] The POI device 104 can include any suitable components for receiving payment information (such as magnetic stripe information of a credit card, payment information received from mobile devices such as smartphones, tablets, PDAs, etc., chip information (such as from a card with an embedded chip), payment information received from a checkout station, other sensitive information such as medical records received from an electronic medical record system, etc.). In various embodiments, the POI device 104 reads and / or receives payment information via a magnetic card reader that reads the magnetic stripe of a card (such as a credit card). In one or more embodiments, the POI device 104 includes a pin-pad for receiving secondary consumer identification and verification information, a biometrics scanner (such as a fingerprint or retina scanner), and / or a chip reader. In at least one embodiment, the POI device 104 is configured to receive payment information via one or more wireless communications such as BLUETOOTH (registered trademark), Bluetooth Low Energy (BLE), and / or Wi-Fi wireless, suitable wireless network connections, etc. (for example, the POI device can receive payment information from an application (mobile wallet) included in a mobile device via a "tap").

[0055] As further described herein, the POI device 104 transmits information received from a consumer (e.g., payment information, biometric information, PIN information, etc.) to another system / device for processing. In various embodiments, the POI device 104 is configured to encrypt the received information upon receiving the same. According to a particular embodiment, the POI device 104 transmits information received from a consumer together with device information such as a serial number associated with the POI device 104 for identification of the POI device. In some embodiments, the POI device 104 is configured to transmit the information received from the consumer and the device information in a specific format such that a "fingerprint" (e.g., an identifier based on the format and / or device information of the POI device 104) can be formed by a P2PE system (e.g., P2PE system 160) for identifying a transaction sent from the POI device 104.

[0056] As will be appreciated by those skilled in the art, the POI device 104 can be any POI device approved by the PCI Security Standards Council ("PCI SSC") or other suitable device that receives information to be encrypted. Examples of devices approved by the PCI SSC can be found on the PCI SSC's website at https: / / www.pcisecuritystandards.org / approved_companies_providers / approved_pin_transaction_security.php. In one or more embodiments, the POI device 104 is a stand-alone swipe terminal such as ID TECH's SecuRED™ SRED device. In some embodiments, the POI device 104 is an integrated mobile business solution such as 4P Mobile Data Processing's FDA600-POS device. In at least one embodiment, the POI device 104 is a countertop terminal such as Atos Worldline's Yomani device.

[0057] Referring further to FIG. 1, manufacturer 102 ships the POI device 104 to the key injection facility (KIF) 110 via a secure shipment 106. As will be understood by those skilled in the art, the secure shipment 106 can represent any suitable type of secure shipment known in the art, including, but not limited to, shipments via FedEx, UPS, etc., and / or via air, land, rail, etc.

[0058] Upon being received by the KIF 110, in one or more embodiments, information regarding the POI device 104 is input into the P2PE manager 166. In various embodiments, the information regarding the POI device 104 includes the serial number of the device (e.g., which will later match a swipe transaction). In at least one embodiment, the information regarding the POI device 104 includes the firmware version number. In further embodiments, the information regarding the POI device 104 includes the manufacturing date, the name of the manufacturer (e.g., manufacturer 102), etc.

[0059] The information regarding the POI device 104 can be input into the P2PE manager 166 in any suitable manner, such as, for example, by the user interface 180 or via an API interface. In various embodiments, the KIF employee scans the serial number associated with the POI device 104 via a suitable scanning mechanism (e.g., a handheld barcode scanner, etc.). In some embodiments, the KIF employee types the serial number associated with the POI device 104 via a keyboard (or other suitable key input device such as a touch screen). As will be understood by those skilled in the art, the POI device 104 can be processed via any suitable security protocol, and the information regarding the POI device 104 can be input into any suitable system, such as a separate KIF inventory management system.

[0060] As shown in FIG. 1, the P2PE manager 166 can be operably connected to the user interface 180. The user interface 180 can represent any number of user interfaces configured to interact with the P2PE manager 166, and the user interface 180 can be connected to the P2PE manager 166 in any suitable manner via, for example, the Internet, a LAN, a WAN, Wi-Fi, etc. For example, the user interface 180 can represent the user interface in the KIF 110 that is used to input information regarding the POI device 104 (as described above). Continuing to refer to this example, the user interface 180 can also represent the user interface in the merchant 132 that is used to input information regarding the POI device 104 (e.g., to update the status of the POI device 104 when the POI device 104 is received, etc.). In this example, the user interface 180 can represent the user interface in a third-party “partner” (e.g., a hospital using an electronic medical record system or another entity that desires to encrypt and decrypt data). The user interface 180 can be used to manually change the status of the POI device 104 (e.g., from “stored” to “deployed”), or, as shown at 182, to view the status of the POI device 104. In some embodiments, the user interface 180 can be configured to generate one or more reports 184 via the P2PE manager 166 (as further described herein).

[0061] According to certain embodiments, when information of the POI device 104 is input into the P2PE manager 166, a certain "status" is assigned. Using the status of the POI device 104 as shown in the P2PE manager 166 can help ensure the secure handling and a series of storage of the POI device 104. For example, when the POI device 104 is first input into the P2PE manager 166, a "new" status is assigned in the P2PE manager 166. When a key is injected into the POI device 104, the status can be changed to "injected". If the POI device 104 is received by a merchant (such as merchant 132) but not deployed / used, it can have a "stored" status. Alternatively, if the device is damaged or non-functional, a "DOA (dead on arrival)" status can be assigned to the POI device 104. For example, the P2PE manager 166 can be configured to discard, obstruct, and / or block data (such as card swipe data) from POI devices listed in a "tampered", "dirty", or "flagged" status, and protect the system and / or card swipe data.

[0062] Continuing to refer to FIG. 1, the POI device 104 is stored in a secure storage room in the KIF 110. The storage room can be secure by any suitable method, such as but not limited to dual access by a lock and key or any suitable security protocol.

[0063] According to certain embodiments, upon receipt of an order from a merchant, one or more base derivation keys (“BDK”) are injected into the POI device 104 and securely bagged, tagged, and packaged for shipment to the merchant (e.g., merchant 132). According to at least one embodiment, an array of hardware security modules (“HSM”) generates encryption / decryption keys that encrypt data received by the POI device 104. As will be appreciated by those skilled in the art, the HSM array can be located at the KIF or at a remote location. In the embodiment shown in FIG. 1, the KIF 110 and the HSM array 162 are remote.

[0064] The HSM array 162 shown in FIG. 1 as part of the P2PE system 160 creates a base derivation key (BDK) that, in various embodiments, is security-divided into two parts, BDK 164A and BDK 164B. BDK 164A and 164B are sent to the KIF 110 (via two separate secure paths 186, 188) where they are received by two key part holders. BDK 164A and 164B can be sent to the KIF 110 in any suitable manner, such as by delivery, mail, fax, e-mail (encrypted or otherwise), etc. In certain embodiments, the two key part holders prove receipt of BDK 164A and 164B via a signature at the time of shipment, a delivery receipt, etc.

[0065] In certain embodiments, the process continues with key assembly at step 114. The key assembly process is briefly described below. However, those skilled in the art will understand that this key assembly process is intended to be exemplary and that any suitable key assembly process can be used. The first key part holder (e.g., the person having BDK164A) enters the secure storage room where the POI device 104 is stored and inputs BDK164A into a tamper resistant security module (“TRSM”). The first key part holder exits the secure storage room. The second key part holder (e.g., the person having BDK164B) enters the secure storage room (e.g., after the first key part holder has exited the secure storage room) and inputs BDK164B into the TRSM. According to certain embodiments, a third party separately verifies the inputs of the first key part holder and the second key part holder (e.g., via the key serial number (KSN) and the check digit). When the key parts are authenticated, the TRSM generates a ciphertext representing the (assembled) BDK164 and transmits the ciphertext to the smart card. A unique initial key derived from the BDK (e.g., from the smart card) is injected into the POI device 104 (and each POI device). As described herein, when an encryption key is injected into the POI device 104, its state in the P2PE manager 166 can be changed to “injected” by transmission 122.

[0066] Referring further to FIG. 1, at step 116, the POI device 104 is placed in a tamper evident bag, which is sealed with a tamper evident, serialized sticker. The POI device 104 (placed in the tamper evident bag and sealed with the serialized sticker) is then, at step 118, placed and sealed in a box (e.g., any suitable shipping container) for shipment to the merchant 132, and a tracking number is assigned. According to certain embodiments, the serial number of the serialized sticker and the tracking number for shipment of the POI device 104 are input into the P2PE manager 166 by transmission ......

[0067] At step 120, the POI device 104 is securely shipped to the merchant 132. The POI device 104 can be securely shipped to the merchant 132 in any suitable manner, including by air, land, rail, etc., by FedEx, UPS, USPS, etc.

[0068] Merchant 132 receives the POI device 104 via transmission 126 and registers the receipt of the POI device 104 with the P2PE manager 166 as shown in step 134. In various embodiments, when Merchant 132 receives the POI device 104, Merchant 132 verifies that the unsealed clear bag (see above) and the serialization sticker used to package the POI device 104 have not been tampered with. In certain embodiments, Merchant 132 inputs the serial number of the POI device 104 (such as printed on the outer surface of the shipping box or some other location) and the serial number of the serialization sticker into the P2PE manager 166. In one or more embodiments, the status associated with the POI device 104 is changed to "stored" in the P2PE manager 166. Merchant 132 stores the POI device 104 (in the unsealed clear bag) until it is deployed.

[0069] In step 138, Merchant 132 removes the POI device 104 from the unsealed clear bag for deployment. In various embodiments, Merchant 132 changes the status of the POI device 104 to "deployed" in the P2PE manager 166. It will be understood that in various embodiments, the P2PE manager 166 substantially automatically changes the status of the POI device 104 to "deployed" based on receipt of information (such as that the POI device 104 has been removed from the unsealed clear bag).

[0070] In step 140, the POI device 104 is deployed (e.g., connected to a register, etc.) and payment card information is received. As further described herein, the POI device 104 can be configured to receive any payment (or other) information, but for simplicity and brevity, payment card information in the form of magnetic card swipe data is described with respect to FIG. 1.

[0071] Upon receiving magnetic card swipe data (e.g., a first or initial card swipe), in various embodiments, the POI device 104 substantially automatically encrypts the magnetic card swipe data based on the encryption key injected into the POI device 104 in step 114 above. In various embodiments, the POI device 104 is configured to encrypt the swipe data immediately upon receiving the swipe data. In certain embodiments, the POI device 104 can receive the swipe data in any suitable manner, including via a magnetic read head, via a chip and PIN reader, via near field communication, etc. (when a credit / debit card with a magnetic stripe is swiped).

[0072] In FIG. 1, according to certain embodiments, upon receiving and encrypting the swipe data, the POI device 104 is configured to transmit the swipe data and other information (collectively the "payload") to the payment network 190. According to certain embodiments, the payload of the POI device 104 includes, in addition to the swipe data, a serial number associated with the POI device 104 (e.g., a serial number assigned to the POI device 104 by the manufacturer 102 and recorded in the P2PE manager 166 in the KIF 110). In some embodiments, the payload of the POI device 104 includes other information such as PIN information, biometric information (e.g., the POI device includes or is connected to one or more biometric readers such as a fingerprint scanner), chip information, etc.

[0073] Those skilled in the art will understand that the payload path of the POI device as shown in FIG. 1 is merely exemplary, and the payload of the POI device can be routed through one or more entities and / or via paths not shown in FIG. 1.

[0074] In step 142, in response to receiving the first card swipe, the POI device 104 forwards its first payload to the payment network 190 via the Internet 164 and transmission 146 for verification and decryption of the swipe data to the P2PE manager 166. In certain embodiments, upon receiving the first payload from the POI device 104, the P2PE manager 166 is configured to analyze the first payload of the POI device 104 to extract the serial number of the POI device 104. In some embodiments, the P2PE manager 166 then compares the extracted serial number of the POI device 104 with a table of POI device serial numbers to determine whether the POI device 104 is included in the table. In other words, in certain embodiments, the P2PE manager 166 is configured to determine whether the POI device 104 is an approved device based on its serial number sent to the P2PE manager 166 with each transaction payload.

[0075] If it is determined that the serial number of the POI device 104 is included in the P2PE manager 166, the P2PE manager 166 can be configured to check the status associated with the POI device 104. For example, if the POI device 104 has a "deployed" status in the P2PE manager 166, upon successfully receiving the first swipe transaction, the P2PE manager 166 can change the status of the POI device 104 to "active". The "active" status in the P2PE manager 166 generally indicates a state of securely receiving decrypted swipe transactions.

[0076] As another example, if the POI device 104 has a "tampered", "stolen", or "lost" state in the P2PE manager 166, the P2PE manager 166 discards the received payload and / or reports the receipt of a payload from a POI device not listed as "active" or "deployed" to the merchant 132 or any other suitable interested party, and is configured not to process the encrypted swipe data (e.g., included in the payload). It should be understood from the description herein that the system can assist in detecting fraudulent transactions based at least in part on various states of the P2PE manager 166. An exemplary list of state changes is shown at 182 in FIG. 1 and is further described herein.

[0077] Continuing to refer to the example shown in FIG. 1 where the P2PE manager 166 has received a first payload from the POI device 104, the P2PE manager 166 creates an associated "fingerprint" (in memory) for the POI device 104 at step 170. According to certain embodiments, the fingerprint of the POI device 104 is created by analyzing the payload sent by the POI device 104 and recording the format, order, and number of data items included in the payload (e.g., as opposed to the content of the payload) and / or any firmware version of the software executed in the POI device 104. An exemplary fingerprint creation process is further described herein (e.g., in FIG. 4A). In various embodiments, the fingerprint is stored and used in future transactions to confirm that the data received from the POI device 104 is secure (e.g., the POI device 104 has not been tampered with and / or is not malfunctioning).

[0078] According to the embodiment shown in FIG. 1, after fingerprint analysis 170, the P2PE manager 166 sends the first payload from the POI device 104 to the HSM 162 for decryption (e.g., using the BDK 164). Once the payload is decrypted, the swipe data is re-encrypted into a cipher that can be decrypted by other entities in the payment process. Once re-encrypted, the payload is sent to the payment network 190, where the swipe data (e.g., credit card information) is processed, and the money is withdrawn from the consumer's deposit account associated with the swiped card, sent to the issuing bank 192, the successor bank 194, and ultimately to the receiving bank 144 where the money is paid to the merchant (e.g., the merchant's bank account).

[0079] In certain embodiments, the system operates in essentially the same manner each time a payload is received from the POI device 104 while the state associated with the POI device 104 is “active” (e.g., the POI device 104 receives swipe transactions regularly). For example, a customer of merchant 132 swipes their credit card at the POI device 104. The POI device 104 sends the payload, which includes the serial number of the POI device 104 and the encrypted swipe data, to the P2PE manager 166. Continuing with this example, at step 170, the P2PE manager 166 determines the serial number of the received payload (e.g., the serial number of the POI device 104), searches for the corresponding fingerprint information associated with the serial number of the POI device 104, and confirms that the POI device 104 has not been tampered with. Once the fingerprint of the POI device 104 is confirmed, in this example, the HSM 162 decrypts the payload of the POI device 104 and then re-encrypts the swipe data and sends it to the payment network 190, the issuing bank 192, the successor bank 194, and the receiving bank 144 to complete the payment process.

[0080] Continuing to refer to FIG. 1, if the POI device 104 has been tampered with (e.g., attempting to steal consumer data), the P2PE manager 166 is configured to prevent unauthorized transactions by not passing the payload to the HSM 162 for decryption, as shown in step 174. There are a number of ways in which the P2PE manager 166 can determine that the POI device 104 has been tampered with and refuse to pass the payload to the HSM 162 for decryption. In certain embodiments, the P2PE manager 166 may receive a payload from a POI device 104 that does not match the fingerprint associated with the POI device 104 (e.g., the format of the payload has been changed, the version number of the firmware used by the device has been changed, etc.). In various embodiments, the P2PE manager 166 can determine that the payload from the POI device 104 has been tampered with by receiving a payload from the POI device 104 after the merchant 132 has recorded that the status of the POI device 104 is "repaired", "damaged", "retired", "destroyed", or "stolen" (e.g., the P2PE manager should not receive a payload from the POI device 104 and thus should not decrypt the payload). In many cases, when the P2PE manager 166 determines that the POI device 104 has been tampered with, it will send a notification to the merchant 132 and / or any other appropriate parties, change the status of the POI device 104 to "tampered" in the POI database 168, and stop decrypting any further payloads from the POI device 104.

[0081] System Architecture Figures 2A, 2B, and 2C are block diagrams showing an exemplary system architecture of the exemplary P2PE system of FIG. 1. These architecture components are comprehensive processes for secure processing of devices and payloads (e.g., for decoding), and are embodied in a secure device handling process 300, a merchant data process 400, and a P2PE management system 500. These major components are intended to be solely exemplary and are used to assist in the description of the systems and methods herein. As will be understood, the following architecture components can be operably connected in any suitable manner and can include suitable processors, databases, firewalls, etc. Further, the various components described herein can be distributed and operably connected in any suitable manner. For example, in various embodiments, the architecture components described below can be physically connected and located in the same room, and / or can be connected via the Internet or a private network and located remotely.

[0082] Secure POI Handling System In connection with FIG. 3, a secure POI handling system 300 is described in more detail herein. A secure POI handling system according to a particular embodiment includes a franchise terminal manufacturer 302 (e.g., manufacturer 102 of FIG. 1) that manufactures a POI device 350 and ships it to a key injection facility (KIF) 502 via secure handling procedures. The KIF 502 injects an encryption key into the POI device 350 and securely ships the POI device 350 to the merchant. The POI device 350 is included in a merchant data process 400 as further described herein.

[0083] The POI manufacturer 302 manufactures devices that can be used with the systems and methods described herein. The POI manufacturer 302 can manufacture any suitable device, including any POI device approved by the PCI Security Standards Council (“PCI SSC”) or any other suitable device that receives encrypted information. Examples of devices approved by the PCI SSC can currently be found on the PCI SSC website at https: / / www.pcisecuritystandards.org / approved_companies_providers / approved_pin_transaction_security.php. In one or more embodiments, the POI device 350 is a stand-alone swipe terminal, such as the ID TECH SecuRED™ SRED device. In some embodiments, the POI device 350 is an integrated mobile business solution, such as the 4P Mobile Data Processing FDA600-POS device. In at least one embodiment, the POI device 350 is a countertop terminal, such as the Atos Worldline Yomani device.

[0084] As will be appreciated from the description herein, the POI manufacturer 302 is merely an exemplary manufacturer. In various embodiments, the system can be configured to decrypt any type of encrypted information from any suitable device (e.g., in a “decryption as a service” environment). In these (and other) embodiments, the manufacturer can manufacture any suitable encryption device that encrypts social security numbers, driver's license numbers, personal data, patient information, etc., and thus, need not necessarily manufacture POI devices. However, for clarity and brevity, the POI manufacturer and POI devices are shown in the drawings.

[0085] Those skilled in the art will understand that merchants and key injection personnel typically do not program the POI device (other than for encryption key injection in the key injection facility). Thus, in many of the embodiments described herein, the POI manufacturer 302 loads and / or programs the POI device 350. In various embodiments, the POI manufacturer 302 configures the POI device 350 with specific firmware and / or a specific version of firmware. In further embodiments, the POI manufacturer 302 configures the POI device 350 with various hardware and software security features (e.g., software that encrypts swipe data shortly after it is read by the POI device 350, hardware that destroys / erases any keys stored by the POI device 350 in the event of tampering, etc.).

[0086] In certain embodiments, the POI manufacturer 302 configures the POI device 350 to transmit an information payload, where the payload includes a specific set of information. In these (and other) embodiments, the payload can include the serial number of the device and / or any other unique device identifier, a unique identifier, and any suitable information such as the version number of the firmware installed on the device, the device manufacturing date, the device brand identifier, the device model identifier, etc. In further related embodiments, the POI manufacturer 302 configures the POI device 350 to transmit the payload in a specific format (e.g., a specific order of data parts, numbers in a specific format such as hexadecimal, characters, etc.). These constructs can be used by the P2PE management system 500 (or 166) to identify a specific POI device (e.g., POI device 350 and / or POI device 104 (FIG. 1)) and to confirm the reliability of the data received via the fingerprint, as will be further described with respect to FIGS. 5A and 5B.

[0087] Although not shown in FIGS. 2A, 2B, and 2C, the POI manufacturer 302 can include a computing device operably connected to the P2PE management system 500 via any suitable connection.

[0088] KIF502 includes any suitable computer, machine, etc., receives the encryption key 562, transmits and receives data 512, securely injects the encryption key into the POI device 350, packs the POI device 350 in a serialized anti-tampering bag, and ships the POI device 350 to the merchant. As described herein, in various embodiments, upon receiving the POI device 350, the user inputs (e.g., types, scans, etc.) information related to the POI device 350 (serial number, firmware version number, etc.) into the P2PE manager 166. In these embodiments, the user can input information related to the POI device 350 via a barcode scanner operably connected to the computing device, via a keyboard operably connected to the computing device, via a touch screen interface operably connected to the computing device, etc.

[0089] The computing device located at the KIF can be any suitable computing device including a desktop computer, a laptop computer, a server, a tablet, other mobile devices, etc. In various embodiments, at least some of the computing devices located at the KIF are configured to be connected to the P2PE management system 500 via a suitable user interface. In some embodiments, information is exchanged between the computing device located at the KIF and the P2PE management system 500 via email, http, or other suitable protocols.

[0090] According to certain embodiments, KIF502 includes an anti-tampering security module (the "TRSM") that assembles the key parts (as described above, in various embodiments, the base-derived key is sent to the KIF in two parts and reassembled). The TRSM can be any suitable TRSM that incorporates physical protection including, for example, a tamper-evident seal, a hardened casing, and hardware and software that erases the contents of the TRSM upon detection of tampering. In various embodiments, when the key parts are combined and verified, the TRSM generates a ciphertext representing the base-derived key. In some embodiments, the ciphertext is transmitted to a smart card.

[0091] The smart card can be any suitable smart card. In various embodiments, the smart card is a chip-enabled smart card that includes one or more processors for key generation, signature, and / or encryption. In certain embodiments, the smart card is equipped with software for creating suitable algorithms such as a hashing algorithm. In at least one embodiment, the smart card is operable to communicate with the TRSM and a suitable key injection device (e.g., Key Loading Devices (KLD)). The smart card can include other features such as anti-tampering means, tampering notification means, tear prevention means, etc.

[0092] According to certain embodiments, the smart card is not used. In these (and other) embodiments, the base-derived key is sent to the KIF in two parts and reassembled as the KLD without using a smart card.

[0093] In various embodiments, KIF502 includes one or more KLDs that inject an encryption key into a POI device. The KLD can be any suitable key loading / key filling device and, in various embodiments, is a secure cryptographic device (SCD).

[0094] According to various embodiments, when an encryption key is injected, the POI device 350 is packaged in a sealed envelope and shipped to the merchant for deployment. Merchant Data System As shown in the embodiment illustrated in FIG. 2A, the merchant data system 400 includes a POI device 350 deployed to receive payment transactions and a POI device 350 operably connected to a payment transaction processor 416. In FIG. 2A, a third-party transaction processor 416 (e.g., the third-party transaction processor 416 is provided by a party other than the payment system by the merchant or a suitable partner, etc.) excluded from the P2PE management system 500. Exemplary merchant data processes and exemplary merchant P2PE reporting processes are described more fully herein with reference to FIGS. 4A and 4B, respectively. The merchant can include any suitable computing device, point of sale devices, servers, databases, processors, and the like.

[0095] As will be understood by those skilled in the art, the POI device 350 can be operably connected to any suitable merchant's point-of-sale system. In various embodiments, the POI device 350 is operably connected to a register that can be digital, analog, touch screen, etc. According to certain embodiments, the POI device 350 is operably connected to a mobile device such as a cell phone, tablet, etc. that executes software to receive payment information. In further embodiments, the POI device 350 is operably connected to a desktop computing device to complete a sale.

[0096] In the embodiment shown in FIG. 2A, the POI device 350 is operably connected to the payment transaction processor 416. Those skilled in the art will understand that the POI device 350 can be directly connected to the payment transaction processor 416 or can be indirectly connected to the payment transaction processor 416 (e.g., the payload of the POI device 350 is transmitted to the payment transaction processor 416 through other components of the point-of-sale system). In various embodiments, the third-party transaction processor 416 can represent any suitable number of servers, processors, etc., and can be located at any suitable location, including at or remote from the merchant.

[0097] As shown in FIG. 2A, the third-party transaction processor 416 is operably connected to one or more card networks 202, the P2PE management system 500, and the issuer 214 (via the Internet 209 or a private network (PN)). In this (and other) embodiment, the payload of the POI device 350 is transmitted to the third-party transaction processor 416 and then, via the Internet 209, to the P2PE management system 500 for decryption and re-encryption, and then the re-encrypted payment data is transmitted to the card network 202 by the Internet 209 and / or PN.

[0098] The merchant system can include any number of suitable computing devices (not shown in FIG. 2A). These merchant computing devices can be any suitable computing devices such as desktop computers, laptop computers, tablets, etc., and can be operably connected to the P2PE management system 500. In various embodiments, the merchant computing devices enable a user at the merchant to input information (e.g., status change information, tracking information, etc.) regarding the POI device 350 that is transmitted to the P2PE management system 500. In one or more embodiments, the merchant computing devices can also be configured to generate various audit reports regarding P2PE compliance.

[0099] P2PE management system In the embodiments shown in FIGS. 2A, 2B, and 2C, the P2PE management system 500 can include any suitable software and / or hardware components including a server, mobile computing devices, desktop computers, one or more databases, and any number of suitable processors. According to certain embodiments, the P2PE management system 500 is configured to manage the status of various POI devices (e.g., POI device 350). In these (and other) embodiments, the P2PE management system 500 can store a table of information regarding the various statuses of the POI devices using any number of suitable tables and databases. In certain embodiments, the P2PE management system 500 includes one or more processors that receive status changes from computing devices, receive information regarding status changes of various POI devices, and determine whether the status of a particular POI device should be changed based on the received information.

[0100] According to various embodiments, the P2PE management system 500 includes one or more databases that receive identification data related to various POI devices (e.g., POI device 350), such as the serial number of the device, the (encrypted) key serial number of the device, the key sequence number, the version number of the device, the firmware number / indicator of the device, etc., and one or more processors. In one or more embodiments, the P2PE management system 500 is configured to store the received identification information, and in at least one embodiment, index the identification information and other information related to a specific POI device by the serial number of the device. For example, in a specific embodiment, the P2PE management system 500 receives a payload of information including the serial number of a specific device from a third-party payment processor (e.g., the payment payload is sent from a merchant to a third-party payment processor and then to the P2PE management system). Continuing to refer to this example, the P2PE management system 500 is configured to analyze the payload to extract the serial number of the specific device and, based on the serial number of the specific device, search for additional device information to identify the location.

[0101] As a second specific example, the P2PE management system 500 receives a payload of information from a third-party payment processor. However, in this second specific example, the third-party payment processor sends a part of the already-analyzed payload. Continuing to refer to the second specific example, the P2PE management system 500 receives the third-party payment processor identifier, the key sequence number, and any encrypted payment information to be decrypted.

[0102] In various embodiments, the P2PE management system 500 includes at least one database and at least one processor that creates and stores an identifier associated with a POI device (and / or any suitable encryption device or system). In some embodiments, the P2PE management system 500 is configured to create a device identifier or “fingerprint” based on the format of one or more payloads received from a particular POI device (e.g., POI device 350). In these (and other) embodiments, the P2PE management system 500 compares the format of future payloads received from a particular POI device with the fingerprint and is configured to verify the reliability of the payload (e.g., that the payload has not been tampered with and / or accessed illicitly in any way).

[0103] According to one or more embodiments, the P2PE management system 500 includes various processors and databases that create an audit report for a merchant. In these embodiments (and other embodiments), the P2PE management system 500 is configured to receive a request for an audit report from a computing device associated with the merchant and to access one or more tables configured to store information associated with various POI devices associated with the merchant. In these embodiments, the P2PE management system 500 is further configured to gather, summarize, and assist with the display (e.g., display on a screen of a computing device at the merchant, send to a printer of a computing device at the merchant, etc.) of information associated with various POI devices associated with the merchant.

[0104] As will be appreciated by those skilled in the art, any of the processors described above can perform two or more of the described functions, and any of the databases described above can store two or more types of information. Accordingly, the above description is not necessarily limiting the various processors disclosed herein to having only the functions described above.

[0105] Referring now to FIG. 2B, an exemplary architecture of a P2PE management system 500 according to one embodiment of the system of the present invention is shown. In various embodiments, the P2PE management system 500 can authenticate and decrypt payloads received from one or more third-party partners. Each of the payloads received from one or more third-party partners can be assumed to originate from a device such as a POI device, or another suitable system (e.g., a health management system, an administrative body, etc.) that transmits the payload for authentication and decryption.

[0106] According to certain embodiments, one or more third-party partners can receive thousands of payloads per second from a large network of devices, such as in embodiments where one or more third-party partners are one or more payment processors that can service large retailers or many small retailers. Since these payloads may require decryption, one or more third-party partners can process the information contained within the payloads in real time (e.g., real-time payment processing). In various embodiments, the P2PE management system 500 can be configured to authenticate and decrypt thousands of transactions per second. In certain embodiments, as further described herein, the P2PE management system 500 can be configured to decrypt up to 1600 payloads per second. In further embodiments, the P2PE management system 500 can be scalable and configured to process thousands of payloads per second.

[0107] In the embodiment shown in FIG. 2B, the P2PE management system 500 includes a P2PE manager (e.g., P2PE manager 166) and a decryption web server 234. In various embodiments, the P2PE manager has the functions described in FIG. 1 and includes an authentication web server 224, a read-only database 228, a master read-only database 230, and a read-write database 232. In the embodiment shown in FIG. 2B, the P2PE management system 500 is positioned behind a firewall 220 and can be operably connected to a load balancer 222. In various embodiments, the load balancer 222 comprises hardware, software, a virtual machine, or a combination of other similar devices that distribute the workload among several computing devices. In one embodiment, the load balancer 222 can distribute and route the payload from a third-party partner to the authentication web server 224, from the authentication web server 224 to the decryption web server 234, and from the decryption web server 234 to the third-party partner (the payload is not encrypted during processing). As will be understood by those skilled in the art, the P2PE management system 500 is merely an exemplary embodiment, and various other components can be added, removed, or rearranged to provide the functions as described herein.

[0108] The authentication web server 224 (which can also be referred to herein as the "front-end web server") is, in various embodiments, a web server that is a combination of hardware, software, a virtual machine, or other similar devices that store, process, and deliver content to a computing device. In one embodiment, the authentication web server 224 can be hosted on a virtual machine and can authenticate the third-party partner that sends the payload for decryption and the device that generated the payload. In one embodiment, the authentication web server 224 can be operably connected to the read-only database 228 and the load balancer 222.

[0109] In various embodiments, the authentication web server 224 can authenticate each payload received by the P2PE management system 500 for decryption. In one embodiment, the authentication web server 224 can ascertain that the partner making the decryption request is making a valid request and that the format of the payload from a particular device matches the expected format of the payload received from that device. In one embodiment, the authentication web server 224 can determine that the decryption request was sent from an approved IP address or that a third-party partner has sent appropriate identification authentication information or identification authentication by any other suitable method. As will be described in more detail in conjunction with the description of FIG. 5B, the authentication web server 224 can compare the fingerprint of the device that generated a particular payload (e.g., the format, order, and number of data items included in the payload) with the pre-stored device fingerprint of the particular device stored in the read-only database. If the fingerprints do not match, in a particular embodiment, the authentication web server 224 rejects the decryption request and generates an error log to send to the read-write database.

[0110] Generally, when the P2PE management system 500 receives a decryption request, the load balancer 222 sends the request and the corresponding payload to the authentication web server 224. In one embodiment, the authentication web server 224 can first verify the partner that sent the decryption request. In various embodiments, this verification can occur, for example, by checking that the decryption request was generated from a known IP address associated with the partner, or that the partner sent the correct identification number or other similar secure authentication method. In one embodiment, after verifying the partner, the authentication web server can verify the particular device that generated the payload. As will be described in more detail in conjunction with the description of FIG. 5B, in various embodiments, the authentication web server 224 can compare the fingerprint of the payload with the fingerprint of a known device of the particular device. In one embodiment, if the fingerprints do not match, the authentication web server 224 can reject the decryption request and send a decryption exception log to the read / write database 232. According to one embodiment, if the fingerprints match, the authentication web server 224 can send the payload to the load balancer 222 (the load balancer 222 can send the payload to the decryption web server 234), and can send a decryption log to the read / write database 232.

[0111] In various embodiments, the authentication web server 224 includes a plurality of authentication nodes 226. The authentication node 226 can be an application designed to process the authentication of partners and device payloads by accessing a read-only database 228 in one embodiment. In one embodiment, the authentication node 226 can be configured to create authentication and exception logs and send those logs to the read / write database 232. In one embodiment, the authentication web server 224 includes three authentication nodes 226 to process 1600 payloads per second.

[0112] The read-only database 228 includes, in various embodiments, a database that is a combination of hardware, software, a virtual machine, or other similar devices that are a systematized collection of data (e.g., including data tables, etc.). In one embodiment, the read-only database 228 can include data necessary for authenticating payloads and decryption requests and can be hosted as a virtual machine on the authentication web server 224.

[0113] In one embodiment, the read-only database 228 can be operably connected to the authentication web server 224 and the master read-only database 230. The read-only database 228 can, in one embodiment, be configured to determine whether a payload has been accessed illegally and store read-only authentication data used to authenticate third-party partners. In one embodiment, the read-only database 228 can be configured to store read-only authentication data used to determine whether a third-party partner is an appropriate entity to make a decryption request. As will be appreciated by those skilled in the art, since the read-only database 228 can be read-only from the perspective of the authentication web server 224, it can be assumed that it is not configured to write write requests from the authentication web server 224. Instead, write requests can be sent to the master read-only database 230.

[0114] After receiving the payload and the decryption request, in one embodiment, the authentication web server 224 queries the read-only database 228 to determine whether the payload is valid or has been accessed illegally (e.g., by authentication and verification). In one embodiment, the authentication web server 224 queries the read-only database 228 to determine the validity of the third-party partner that sent the payload (e.g., by sending the firmware number or serial number of the device as further described herein). The read-only database 228, in one embodiment, sends a response that queries back to the authentication web server 224. If the response confirms the validity of the third-party partner, the authentication web server 224 can query the read-only database 228 to determine the validity of the device's payload. The read-only database 228, in one embodiment, can send a response that queries back to the authentication web server 224 and includes the data necessary to verify the payload. In one embodiment, the authentication web server 224 can compare the payload with the response from the read-only database 228 to determine the validity of the payload. If the comparison confirms the validity of the device's payload, the authentication web server 224 can send the decryption request log to the read-only database 228. If either the third-party partner or the payload is invalid, the authentication web server 224 can send an exception log to the read-only database 228. In an embodiment where the read-only database 228 is read-only from the perspective of the authentication web server 224, the read-only database 228 can send the exception log and the decryption request log to the master read-only database 230.

[0115] As will be appreciated by those skilled in the art, the read-only perspective of the read-only database 228 can enable the authentication web server 224 to query the read-only database 228, and the read-only database 228 can respond to those queries more quickly than if the read-only database 228 were configured to have read-write capabilities. In one embodiment, the read-only database 228 includes a MONGO-formatted database, or any other NoSQL format that enables the database to process the required requests per second (e.g., up to about 1600 per second). As will be appreciated by those skilled in the art, this type of database is easily refreshable and can be configured to operate quickly because it does not have as robust a data structure as a relational database. In one embodiment, the data stored in the database need not be related to other data (e.g., the data is stored as a collection of individual data objects). Further, in various embodiments, the read-only database 230 can be configured not to validate write requests, so that more write requests can be made per second. In various embodiments, to avoid potential data loss associated with this feature, the read-only database 228 can be operably connected to the master read-only database 230.

[0116] In various embodiments, the master read-only database 230 includes a database that is a combination of hardware, software, virtual machines, or other similar devices that are an organized collection of data (e.g., including data tables, etc.). In one embodiment, the master read-only database 230 can include the data required to refresh the read-only database 228 and can be hosted as a virtual machine on the authentication web server 224.

[0117] In one embodiment, the master read-only database 230 can be operably connected to the read-only database 228, the MQTT queue 231, and the read-write database 232. The master read-only database 230 can be configured, in one embodiment, to receive and store authentication data received from the read-write database 232 to refresh the read-only database 228. In various embodiments, the master read-only database 230 is read-only from the perspective of the read-only database 228 and can be read and written from the perspective of the read-write database 232. As will be appreciated by those skilled in the art, since the master read-only database 230 can be read-only from the perspective of the read-only database 228, it can be configured not to write write requests from the read-only database 228. Instead, the write requests can be sent to the MQTT queue 231 and the read-write database 232.

[0118] In one embodiment, the master read-only database 230 can receive logs from the read-only database 228 and send those logs to the MQTT queue 231 and the read-write database 232. The master read-only database 230 can, in one embodiment, receive updates from the read-write database 232, refresh its data table based on the updates, and send the updates to the read-only database 228. As will be appreciated by those skilled in the art, the master read-only database 230 can prevent data loss between the read-only database 228 and the read-write database 232.

[0119] In one embodiment, the master read-only database 230 includes a MONGO-formatted database, or any other NoSQL format that enables the database to process the required requests per second. As will be recognized by those skilled in the art, this type of database can be easily refreshed and can be configured to operate quickly because it does not have as robust a data structure as a relational database. In one embodiment, the data stored in the database need not be related to other data (e.g., the data is stored in a collection of individual data objects). Further, in various embodiments, the master read-only database 230 can be configured to perform without validating write requests, so more write requests can be made per second. To avoid potential data loss associated with this feature, the master read-only database 230 can be operably connected to the read-write database 232 and the MQTT queue 231.

[0120] The MQTT queue 231 includes a message queuing protocol for storing messages (e.g., log write requests). In one embodiment, the MQTT queue 231 can be operably connected to the master read-only database 230 and the read-write database 232. In one embodiment, the MQTT queue 231 can be in a separate partition within the same hardware, software, virtual machine, or other similar device hosting the master read-only database 230. The MQTT queue 231 can be configured in one embodiment to have a queuing protocol that receives, queues, and transmits messages (e.g., logs, event exceptions, etc.) sent from the master read-only database 230 to the read-write database 232 via the message queuing protocol. In various embodiments, the MQTT queue 231 can process messages to the read-write database 232 via the message queuing telemetry transport messaging protocol (e.g., MQTT).

[0121] In one embodiment, the MQTT queue 231 can receive messages from the master read-only database 230 and store those messages in the queue using the message queuing protocol until a specific set of events or situations occur. In one embodiment, this functionality enables the MQTT queue 231 to function as a backup for messages sent by the authentication web server 224 that are received by the read-write database 232. As will be recognized by those skilled in the art, the MQTT queue 231 can prevent data loss between the master read-only database 230 and the read-write database 232. Further, the MQTT queue 231 can enable the P2PE management system 500 to operate properly even when the read-write database 232 is offline. Generally, the MQTT queue 231 can store log write requests received from the master read-only database 230 and the read-only database 228, and thus, in one embodiment, the log write requests can be queued until the read-write database 232 can write the log write requests, which can prevent any loss of log write requests generated when the read-write database 232 is not operating.

[0122] In one embodiment, when it is determined that the P2PE management system 500 processes less than a specific number of payloads per second, the MQTT queue 231 can send messages from the queue to the read-write database 232. For example, when the P2PE management system 500 processes less than 250 (or, for example, 500, 750, 1000, etc.) payloads per second, the MQTT queue 231 can be configured to send the messages within the queue. In a specific embodiment, when the P2PE management system 500 processes less than 500 payloads per second, the MQTT queue 231 can start sending messages to the read-write database 232 until all of the messages are sent or until the system starts processing more than 500 payloads per second. When all of the messages have been sent, the MQTT queue can stop sending messages and wait to receive more messages from the master read-only database 230. When the P2PE management system 500 starts processing more than 500 payloads per second, the MQTT queue 231 can stop sending messages and wait to start sending messages again until the P2PE management system 500 processes less than 500 payloads per second. As will be appreciated by those skilled in the art, the MQTT queue 231 can receive messages from the master read-only database 230 regardless of whether it is sending messages to the read-write database 232.

[0123] The read / write database 232 (which may also be referred to herein as the "backend read / write database") includes, in various embodiments, a combination of hardware, software, virtual machines, or other similar devices, and is a database that is a systematic collection of data (e.g., including data tables, etc.). In one embodiment, the read / write database 232 can include the payload from a third-party partner, as well as substantially all of the data necessary for the authentication and decryption of messages generated by the authentication web server 224 and the decryption web server 234, and can be hosted as a virtual machine. According to various embodiments, the read / write database 232 can perform the main functions of the P2PE manager 166 as described in connection with FIG. 1, other than the functions of the authentication web server 224 and the database as described above. In various embodiments, the read / write database 232 can receive a change in the state of the device, for example, via transmissions 122, 124, and 126, and can receive the serial number of the device. In one embodiment, the read / write database 232 can update its data table based on the received state change and serial number.

[0124] In one embodiment, the read / write database 232 can be operably connected to the master read-only database 230, the MQTT queue 231, and the decryption web server 234. The read / write database 232, in one embodiment, stores authentication data and transmits it to the master read-only database 230, receives and stores messages from the MQTT queue 231, updates the authentication data based on exception messages, and can be configured to transmit updates to the read-only database 228 to the master read-only database 230. In one embodiment, the read / write database 232 includes a MYSQL-formatted database. As will be appreciated by those skilled in the art, the MYSQL database includes a relational database management system that enables the read / write database 232 to store logs related to third-party partners and the POIs that generated those logs, and can be easily adapted to multiple systems, which enables the P2PE management system 500 to interface with multiple external systems for functions including, but not limited to, auditing, invoicing, etc.

[0125] In one embodiment, the read / write database 232 can receive messages from the MQTT queue 231. If those messages are authentication logs, the read / write database 232 can store the logs and associate the logs with the third-party partner and the device that generated the authenticated payload. If those messages are exception logs, the read / write database can store those logs and can update the records of the third-party partner and the device that generated the payload to reflect the exception. In one embodiment, the read / write database 232 transmits updates to the master read-only database 230 and can refresh both the master read-only database 230 and the read-only database 228.

[0126] According to various embodiments, the read / write database 232 can receive a decryption log and a decryption exception log from the decryption web server 234. The decryption log can indicate a successful decryption of the payload and can be stored in the read / write database 232 with respect to the relevant partner, device, and payload for decryption. The decryption exception log can indicate an unsuccessful decryption of the payload and can be stored in the read / write database 232 with respect to the relevant partner, device, and / or payload for decryption. Those skilled in the art will recognize that these logs enable the P2PE management system 500 to generate reports regarding the number of decrypted payloads, unsuccessful payload decryptions, and the like. In various embodiments, the decryption log and the decryption exception log from the decryption web server 234 can be queued before being sent to the read / write database 232 in a process similar to the process of the authentication log and the exception log on the MQTT queue 231 as described above herein.

[0127] In various embodiments, the decryption web server 234 includes a web server that is a combination of hardware, software, a virtual machine, or other similar devices that store, process, and deliver content to a computing device. In one embodiment, the decryption web server 234 can be hosted on a virtual machine and can decrypt a payload received from a third-party partner. In one embodiment, the decryption web server 234 can be operably connected to the read / write database 232 and the load balancer 222.

[0128] In various embodiments, the decryption web server 234 can decrypt each payload received by the P2PE management system 500 for decryption. According to various embodiments, the decryption web server 234 can be involved in obtaining an appropriate decryption algorithm for decrypting the payload, decrypting the payload, verifying the decryption, sending the decrypted payload back to the load balancer 222, and generating a log of the decryption.

[0129] Generally, when the P2PE management system 500 receives a decryption request, the load balancer 222 sends the request and the corresponding payload to the authentication web server 224. In one embodiment, the authentication web server 224 can analyze the payload and determine the key index for that particular payload before sending the request back to the load balancer 222. Generally, the key index indicates the base key (e.g., algorithm) used as a basis for encrypting the payload of a particular device and will be better understood in connection with the descriptions in FIGS. 6, 11, 12, etc. After authenticating the third-party partner and the payload, in one embodiment, the authentication web server 224 can send the request, key index, and the corresponding payload back to the load balancer 222, and the load balancer 222 can send the request, key index, and the corresponding payload to the decryption web server 234. According to different embodiments, the decryption web server 234 can obtain an appropriate decryption algorithm for decrypting the payload, decrypt the payload, and verify that the decryption was successful (e.g., verify that the decrypted payload contains credit card information as expected non-random data). In various embodiments, the decryption web server 234 can send the decrypted payload back to the load balancer 222, and the load balancer 222 can send the decrypted payload to the third-party partner and generate a log of the decryption. In one embodiment, the decryption web server 234 can send its decryption log to the read-write database 232.

[0130] In various embodiments, the decryption web server 234 includes a hardware security module 238 (e.g., HSM). In various embodiments, the HSM 238 can receive requests, key indexes, and corresponding payloads from the decryption web server 234. Generally, in various embodiments, the HSM 238 can process the key index, determine an appropriate method to use to decrypt the payload, decrypt the payload, verify the decryption, send the decrypted payload back to the load balancer 222, and generate a log of the decryption. In one embodiment, the HSM 238 can obtain an appropriate decryption algorithm to decrypt the payload, decrypt the payload, verify the decryption, send the decrypted payload back to the load balancer 222, and generate a log of the decryption. In various embodiments, the HSM 238 includes one or more processors and one or more databases suitable for creating and storing encryption keys. In certain embodiments, the HSM 238 receives a payload, derives an encryption key from the payload information, decrypts payment data included in such payload, re-encrypts at least a portion of the payload including payment information, and includes at least one processor and at least one database for sending the re-encrypted portion of the payload to a card network (e.g., card network 202) via the Internet 209 and / or a private network (PN). Generally, the HSM 238 can decrypt a payload in any format (e.g., TDES / 3DES, DUKPT, format-preserving encryption (e.g., BPS), base64 encoding, hexadecimal encoding, encrypted value names, etc.). The HSM will be further understood with respect to the descriptions of FIGS. 1, 4, 5, 6, etc.

[0131] According to certain embodiments, the HSM 238 includes an apparatus that provides physical and logical protection at the FIPS 104-2 level 3 for cryptographic keys or other suitable PCI-compliant HSMs. An example of such an HSM is the SafeNet Luna EFT HSM. Other examples of PCI-approved HSMs can be found at https: / / www.pcisecuritystandards.org / approved_companies_providers / approved_pin_transaction_security.php.

[0132] Generally, the HSM can process up to 1600 payloads per second. To understand how the P2PE management system 500 can process more than 1600 payloads per second, an explanation of the scalability of the P2PE management system 500 may be useful.

[0133] Referring now to FIG. 2C, an exemplary architecture of the P2PE management system 500 according to one embodiment of the system of the present invention is shown. In various embodiments, the P2PE management system 500 may be scalable to enable the P2PE management system 500 to decrypt more payloads per second.

[0134] The scalability of the P2PE management system 500 can, in one embodiment, be made independent of any one component of the system, but instead can be based on the desired number of decryptions per second. Thus, in one embodiment, the P2PE management system 500 can scale based on one rate-limiting component, and all other components can scale based on that rate-limiting component. According to various embodiments, the scalability of the P2PE management system 500 can be based on the number of HSMs 238 in the P2PE management system 500 (e.g., the rate-limiting component). For example, an HSM 238 can generally process up to about 1600 decryptions (e.g., payloads) per second. If 3200 decryptions per second are desired, the P2PE management system 500 should, in one embodiment, include two decryption web servers 234 (or alternatively, one decryption web server 234 including two HSMs 238), each operably connected to a load balancer 222 and a read / write database 232. To support two HSMs 238 that can process up to about 3200 decryptions per second, in this case, the P2PE management system 500 includes, in one embodiment, three authentication web servers 224. In this embodiment, each of the three authentication web servers 224 can be operably connected to a load balancer 222 and a read-only database 228. Continuing to refer to this embodiment, the system includes three read-only databases 228 operably connected to a master read-only database 230 that can be operably connected to an MQTT queue 231 and a read / write database 232. In the case of this configuration, in one embodiment, the P2PE management system 500 can authenticate and verify up to about 3200 payloads per second, and the HSM 238 becomes the rate-limiting component of the P2PE management system 500.

[0135] In one embodiment, when the P2PE management system 500 includes a plurality of read-only databases 228, the master read-only database 230 can refresh the read-only databases 228 substantially simultaneously by sending the same updates to each read-only database 228. Similarly, in one embodiment, when the P2PE management system 500 includes a plurality of read-only databases 228, the master read-only database 230 can receive the authentication logs and exception logs from each of the read-only databases 228 substantially simultaneously and pass those messages to the same MQTT queue 231 for transmission to the read / write database 232.

[0136] According to various embodiments, the P2PE management system 500 includes only one master read-only database 230, one MQTT queue 231, and one read / write database 232, regardless of the number of authentication web servers 224, read-only databases 228, decryption web servers 234, and HSMs 238. According to various embodiments, to process up to approximately 6400 payloads per second, the P2PE management system 500 includes four decryption web servers 234, four HSMs 238, six authentication web servers 224, six read-only databases 228, one master read-only database 230, one MQTT queue 231, and one read / write database 232. According to various embodiments, to process up to approximately 12800 payloads per second, the P2PE management system 500 includes eight decryption web servers 234, eight HSMs 238, twelve authentication web servers 224, twelve read-only databases 228, one master read-only database 230, one MQTT queue 231, and one read / write database 232.

[0137] Exemplary System Process Exemplary POI Handling Process (Figure 3) Figure 3 shows a high-level flow diagram of an exemplary secure device handling process 300 as shown in Figure 2A. In various embodiments, this POI handling process can help to ensure a secure chain of custody of the POI device. Briefly summarized, in certain embodiments, when a POI device is transported and handled from different entities, the POI manager assigns various states to the POI device. In these (and other) specific embodiments, the POI manager verifies that a correct sequence of states has been assigned to the POI device before facilitating the decryption of the POI device's payload. This secure POI handling process, in certain embodiments, helps to identify whether the POI device has been tampered with and / or replaced (e.g., with a fraudulent POI device) during transit from the point of manufacture to the point of deployment at the merchant. The POI handling process 300, as shown in Figure 3 and described immediately below, can assist in the description of at least one embodiment of this POI handling process.

[0138] Starting at step 330, the system is configured to receive identification information of a particular POI device in the P2PE management system 500. In various embodiments, the identification information of a particular POI device includes a serial number associated with the particular POI device (e.g., POI device 350 of Figure 2A). In certain embodiments, the identification information of a particular POI device includes the version of the firmware installed on the particular POI device. In further embodiments, the identification information of a particular POI device includes any other suitable information such as the model, type of device, date of manufacture of the device, etc.

[0139] The system can be configured to receive the identification information of a specific POI device from any suitable entity in any suitable manner. In certain embodiments, the identification information of a specific POI device is transmitted from a computing device in a key injection facility (KIF) (e.g., via an encrypted electronic packet). In some embodiments, the identification information of a specific POI device is received from a computing device associated with a manufacturer. In further embodiments, the identification information of a specific POI device is input by a person into a computing device operably connected to the POI manager.

[0140] In step 332, the system is configured to set the state of POI device 350 to indicate that the POI device is ready for new / programming in response to receiving specific information related to POI device 350 (e.g., the system is configured to set the state of a specific POI device to "new"). In various embodiments, the system is configured to change the state of the POI device to new by adding the POI device (or associated identifier) to a table or list of POI devices in a new state. In further embodiments, the system is configured to change the state of the POI device by including the state of the POI device in a table along with the POI device identifier (e.g., the POI device is enumerated by an identifier on the table and a state associated with the change of the POI device). In yet further embodiments, the information related to the POI device in the system can include various bits indicating the state (e.g., the information about the POI device includes bits indicating each state and can be set on or off to indicate the state of the device). In this (and other) embodiment, the system can be configured to change the bit associated with the new state to on or "1".

[0141] In step 334, the system is configured to receive an instruction that an encryption key is to be injected into a specific POI device. As described herein, in various embodiments, the POI device is stored in the KIF until it is injected. In some embodiments, when a specific POI device is ordered from a merchant (or at any other suitable time), an encryption key is injected into the specific POI device under a special security protocol (as described elsewhere in this specification).

[0142] The system can be configured to receive an instruction that an encryption key is to be injected into a specific POI device in any suitable manner. According to a specific embodiment, when injected, the user in the KIF logs in to the P2PE manager (via a suitable computing device) to indicate that it has been injected into the specific POI device. In some embodiments, the system can be configured to receive an instruction that a specific POI device is automatically injected from a computing device that links to a key injection device and / or a specific protocol device related to injecting into the specific POI device.

[0143] In step 336, based at least in part on receiving an instruction that an encryption key is to be injected into a specific POI device, the system is configured to change the state of the specific POI device to indicate that it has been injected (e.g., assign an "injected" state). In a specific embodiment, the system is configured to receive an instruction that a specific POI device is injected by a user who manually changes the state of the specific POI device from new to "injected". The system can be configured to change the state of the POI device in any suitable manner including, but not limited to, the methods described in connection with changing the state of the specific POI device to "new" in step 332.

[0144] In step 338, the system is configured to receive information regarding the shipment of a particular POI device. In various embodiments, the particular POI device is packaged for shipment from the KIF to the merchant. In these (and other) embodiments, the system is configured to receive various information regarding the shipment of a particular POI device, such as the number of the anti-tampering bag (e.g., serial number), the number of the box, the tracking number, the merchant number, the address / shipping destination, and / or any other suitable information for tracking and / or verifying the shipment of the particular POI device.

[0145] In step 340, the system is configured to receive data from the merchant indicating receipt of a particular POI device. In various embodiments, the system is configured to receive data from the merchant indicating receipt of a particular POI device by receiving the serial number of the particular POI device. In certain embodiments, the system is configured to receive data from the merchant indicating receipt of a particular POI device by receiving the tracking number associated with the POI device and / or the serial number of the anti-tampering bag. In some embodiments, the system can be configured to receive data indicating receipt of a particular POI device in any other suitable manner.

[0146] In step 342, based on the receipt of data from the merchant, the system is configured to determine whether a particular POI device has been illegally accessed during shipment. In various embodiments, the system is configured to determine whether a particular POI device has been illegally accessed during shipment by comparing the data received from the merchant (e.g., in step 340) with information regarding the shipment of the particular POI device (e.g., in step 338). According to a particular embodiment, the system is configured to search for the device based on the serial number of the device and to confirm that the tracking information, the serial number of the anti-tampering bag, etc. match. In these embodiments, the system ensures that a particular POI device (e.g., a POI device programmed to send cardholder information to another location or any other unauthorized task) has been shipped from the KIF to the merchant without being tampered with or replaced by anyone by verifying these numbers / identifiers.

[0147] The system can be configured to compare the data received from the merchant with the information regarding the shipment of the particular POI device in any suitable manner. In various embodiments, the system is configured to store information regarding the shipment of the particular POI device in a table associated with the serial number of the particular POI device (e.g., the serial number created by the manufacturer and entered into the system in the KIF). In these embodiments, upon receiving the serial number and data from the merchant indicating receipt of the particular POI device (e.g., the information in step 340), the system is configured to search for the serial number of the particular POI device and to search for and find the information regarding the shipment of the particular POI device by accessing a table having an appropriate header (e.g., "KIF shipment information", etc.).

[0148] In step 344, the system is configured to change the state of a particular POI device to indicate that the particular POI device has been received (but not yet deployed) by the merchant. In various embodiments, the system is configured to change the state of the POI device to "in storage" to indicate that the particular POI device is in storage at the merchant.

[0149] The system can be configured to change the state of a particular POI device in any suitable manner. In various embodiments, the system is configured to change the state of a particular POI device by receiving an instruction from a computing device associated with the merchant to change the state of the particular POI device (e.g., the user selects or inputs a notification to change the state of the particular POI device). According to a particular embodiment, the system is configured to automatically change the state of a particular POI device if it determines (e.g., in step 342) that the particular POI device has not been accessed illegally during shipment. In a further embodiment, the system is configured.

[0150] In step 346, the system is configured to receive an instruction that a particular POI device is to be deployed. In various embodiments, the system can receive an instruction (e.g., a manual instruction from the user) from a computing device that a particular POI device is to be deployed (e.g., ready to receive a swipe transaction). In one or more embodiments, the system is configured to receive an instruction that a particular POI device is to be deployed by receiving, at the user interface, an instruction that the particular POI device is ready to be deployed, and in response, the system changes the state of the particular POI device to the indicated deployment (e.g., changes the state of the POI device from "in storage" to "deployed").

[0151] Those skilled in the art should understand from the description herein that the state of a specific POI device can be changed and / or varied from the sequence described above. In a specific example, a merchant can receive a specific POI device and determine that the specific POI device is damaged. Continuing to refer to this specific example, the merchant can then indicate to the system that the specific POI device is damaged, and the system can change the state of the specific POI device and indicate that the POI device is damaged (e.g., the "damaged" state). As described below, when in the deployed state, a specific POI device (e.g., POI device 350) is ready to receive swipe data, as will be described later with reference to FIG. 4A.

[0152] Exemplary Merchant Data Process (FIG. 4A) Referring to FIG. 3 above, when a specific POI device (e.g., POI device 350) is received and deployed by a merchant, the specific POI device is ready to receive customer transactions in various embodiments. As will be understood by those skilled in the art, the specific POI device may require further setup by the merchant, such as, for example, connection to a payment processing computing device, additional software setup, etc.

[0153] Referring to FIG. 4, in step 430, a specific POI device receives customer data. As described herein, the specific POI device can receive payment transaction data (such as card swipe data), and other customer verification information such as, for example, biometric data (fingerprint, retina scan, etc.), chip and PIN data, PIN data, etc.

[0154] In step 432, as soon as the customer data is received, a particular POI device is configured to encrypt the customer data. In various embodiments, the particular POI device can be configured to encrypt the customer data based on the injected encryption key(s). In some embodiments, the particular POI device is configured to encrypt the customer data via an internal encryption scheme. In further embodiments, the particular POI device is configured to encrypt the customer data via an encryption key sent to the particular POI device for each transaction.

[0155] In step 434, the particular POI device is configured to compile a payload to be sent to the payment processor. In various embodiments, the payload includes the encrypted customer data. In one or more embodiments, the payload includes the serial number of the device. In at least one embodiment, the payload includes the serial number and / or firmware number of the device. In further embodiments, the payload includes the manufacturing date of the particular POI device. In still further embodiments, the payload includes various other information such as the encrypted PIN or other authentication information related to the customer, and / or other information for identifying the transaction (e.g., transaction date, merchant, cashier number, etc.).

[0156] The particular POI device can be configured to compile the payload in any suitable format that can be used by the system to create a fingerprint of the particular POI device as described herein. In various embodiments, the particular POI device is configured to compile the payload into a string of data representing various data items of the payload. In these (and other) embodiments, the various components of the payload string can be formatted in characters, XML, or hexadecimal format.

[0157] The payload can include any suitable component. In various embodiments, the payload includes an indication of the form of the component (e.g., hexadecimal, XML, etc.). In certain embodiments, the payload indicates, for example, that the payload data has been encrypted using a RAW (e.g., the data is not encrypted), a DES derived unique key per transaction (“DUKPT”) encryption scheme, a triple data encryption standard (“TDES” or “3DES”), or an Advanced Encryption Standard that indicates that the payload data has been encrypted using an AES DUKPT encryption scheme, including an indication of a specific encryption (encoding) algorithm.

[0158] In various embodiments, the P2PE manager includes an indication of a specific type of encryption associated with a particular device based on the serial number of the particular device. In these and other embodiments, the system is configured to send an indication of a specific type of encryption to the HSM based on the serial number of the particular device.

[0159] According to certain embodiments, the payload includes card swipe data. The card swipe data can include any or all of the data of various tracks encoded on the magnetic stripe of the card. As will be understood by those skilled in the art, in various embodiments, the magnetic stripe of the card includes three separate tracks of encoded data, each of which is read by a magnetic card reader. In these embodiments, the system can be configured to encrypt and compile each track of the card data. In some embodiments, each track of the card data can include different information. In further embodiments, each track of the card data can include at least some of the same information.

[0160] A particular POI device can be configured to compile each track of the card data in any suitable way. In various embodiments, a particular POI device is configured to compile each track of the card swipe data in a card track format where each track is formatted as a set of clear data (e.g., without encryption), followed by a set of encrypted data (e.g., card swipe data for a particular track), followed by a set of dummy encrypted data (e.g., encrypted random data that does not represent card swipe data). In a particular embodiment, each of the sets of clear, encrypted, and dummy data can be in character or hexadecimal format.

[0161] A particular POI device can output the data described above, for example, in the following format. FORMAT_CIPHERED_[TRACK1][_TRACK2][_TRACK3] A particular POI device can be configured to include additional data in the payload. According to a particular embodiment, a particular POI device is configured to include a key serial number ("KSN") and / or a device serial number ("DSN") in the payload (e.g., the key serial number indicates how the HSM should decrypt various encrypted tracks and the device serial number as described herein to identify a particular POI device). In these (and other) embodiments, the KSN and DSN can be formatted in alphanumeric or hexadecimal form. In a further embodiment, a particular POI device is configured to include a hardware version number and / or a firmware version number, each of which can be formatted in alphanumeric or hexadecimal form (or can be empty). As will be understood by those skilled in the art, the above components of the payload can be formatted in any suitable form and arranged in the payload in any suitable manner. For example, the above TRACK1 data can come before or after the FORMAT and / or CIPHERED data. Similarly, the track data can be in any other order (e.g., the TRACK3 data can come before the TRACK1 data). Further, the KSN or DSN data can be located anywhere in the payload string.

[0162] In a particular example, the payload string is FORMAT_CIPHERED_[TRACK1][_TRACK2][_TRACK3][_KSN][_DSN][_HWV_HARDWARE][_FMV_FIRMWARE] and can be formatted as.

[0163] As will be further described below, in a particular embodiment, the system uses this payload string and format for each data component to create a unique fingerprint for each device. In step 436, a particular POI device is configured to send a payload to a payment processing system. According to certain embodiments, the particular POI device is configured to send the payload to a third party for payment processing. In at least one embodiment, the system is configured to send the payload to a payment processing system associated with the P2PE management system 500. In some embodiments, the system is configured to send the payload to any suitable intermediate stage for processing before being sent to a payment processor. For the sake of brevity, this section of the present document refers to a payment processing system that may mean any of the above.

[0164] A particular POI device can be configured to send a payload to a payment processing system in any suitable manner. According to some embodiments, the particular POI device is configured to send the payload to the payment processing system via the Internet. In one or more embodiments, the particular POI device is configured to send the payload to the payment processing system via a secure private network. In some embodiments, the particular POI device is configured to send the payload to the payment processing system via a LAN, WAN, Wi-Fi, hard line, or other suitable connection.

[0165] As will be understood from the description herein, a particular POI device is, in various embodiments, a "dumb" device. Thus, the particular POI device is, in these (and other) embodiments, configured to receive data (whatever the data may be), encrypt the data based on the installed firmware, and compile and send the payload without considering where the data is going, whether the POI device has been tampered with, whether the POI device has been stolen, etc. It should also be understood that a particular POI device can have various other security means installed, such as, for example, a tamper-proof casing, a circuit designed to self-destruct upon tampering, various audible or visual alarms, etc.

[0166] Exemplary P2PE Reporting Process (Figure 4B) Referring to FIG. 4A above, when a particular POI device (e.g., POI device 350) is received and deployed by a merchant, in various embodiments, the particular POI device is ready to receive customer transactions. In these (and other) embodiments, the merchant may be required to generate one or more audit reports to guarantee the state of the POI device (and any other POI devices the merchant may possess). According to certain embodiments, the systems and methods herein are configured to collect information and generate such audit reports.

[0167] Referring to FIG. 4B, the system is configured to receive a request for an audit report from a computing device associated with a merchant at step 431. In various embodiments, the system receives login information (e.g., a username, password, and / or other suitable authentication information) associated with a particular user (e.g., that can identify a particular merchant) and an indication that the particular user desires an audit report, and is configured to receive a request for an audit report from a computing device associated with the merchant. In one or more embodiments, the system is configured to receive a request for an audit report from a computing device associated with the merchant by receiving an audit request from a particular computing device dedicated to communication with the system (e.g., a computing terminal configured to function only with the P2PE management system).

[0168] The audit report can be any suitable audit report containing any suitable information. In various embodiments, as described above, the audit report can include information related to one or more devices associated with the merchant and / or the status of each of one or more devices associated with the merchant. According to certain embodiments, the audit report includes certification of the information associated with each of one or more devices associated with the merchant. In further embodiments, the audit report includes certification by the user (e.g., representing the merchant) that the user has read and / or the merchant is in compliance with a compliance manual (e.g., P2PE handling instructions, etc.).

[0169] In step 433, the system is configured to retrieve merchant device information associated with the merchant in response to receiving a request for an audit report. As described herein, in various embodiments, the system is configured to receive information regarding the custody of a series of various devices. In these (and other) embodiments, the system is configured to identify and retrieve the location of information regarding each device associated with the merchant. Such merchant device information can include any suitable information including, but not limited to, device identifiers, device locations, serial numbers of the devices, numbers of transactions processed by the devices, status of the devices (e.g., "active", "lost", "tampered", "in custody", etc.).

[0170] According to certain embodiments, the audit report (e.g., requested in step 431) can include certification that the user (e.g., representing the merchant) has read and / or the merchant is in compliance with a compliance manual. In these (and other) embodiments, the system is configured to search for a copy of the compliance manual and display it to the user.

[0171] In step 435, the system is configured to display merchant device information. In various embodiments, the system is configured to display merchant device information including a merchant device identifier, a merchant device location, and a merchant device status. In a particular embodiment, the system is configured to display a copy of a compliance manual.

[0172] In step 437, the system is configured to request proof of merchant device information. In a particular embodiment, the system is configured to request proof by the user clicking on one or more check boxes. In various embodiments, the system is configured to request proof by the user typing their name or electronically signing. In a further embodiment, the system is configured to request proof by the user entering a code, filling in a document, clicking a button, scrolling to the end of a page or electronic document, etc.

[0173] In step 439, the system is configured to receive an indication of proof (e.g., the system is configured to receive an indication that the user has checked a box, filled in a paper, signed an electronic paper, etc.). In step 441, the system is configured to compile an audit report in response to receiving the indication of proof, the audit report including an identifier for each device associated with the merchant, the status of each merchant device, and the indication of proof. The system can be configured to compile the audit report in any suitable manner, and the audit report can be in any suitable format.

[0174] In step 443, the system is configured to send the audit report to a computing device associated with the merchant. The system can be configured to send the audit report to a computer device associated with the merchant by, for example, displaying the audit report, accessing a computing device associated with the merchant, and causing the audit report to be printed. In various embodiments, the system is configured to send a copy of the certification of the audit report to various other entities, such as an auditing entity.

[0175] Exemplary Payment System Process (FIGS. 5A and 5B) FIGS. 5A and 5B illustrate an exemplary process performed by a P2PE management system (e.g., P2PE management system 500). FIG. 5A illustrates an exemplary payload integrity verification process, and FIG. 5B illustrates an exemplary fingerprint generation process that can be used as part of the payload integrity verification process.

[0176] Exemplary Payload Integrity Verification Process Referring to FIG. 5A, in step 530, the system is configured to receive a payload generated by a device, where the payload includes encrypted information and the serial number of the device. In various embodiments, the system is configured to receive the payload from a payment franchise terminal device (e.g., a credit card swiping device). In certain embodiments, the system is configured to receive the payload from a health record computing device (e.g., a device that transmits health records that should be carefully handled for storage by the system). In further embodiments, the system is configured to receive the payload from a computing device associated with financial information (e.g., deposit account information, etc.). In still further embodiments, the system is configured to receive the payload from any other suitable device, such as a device that transmits information that should be carefully handled, such as a driver's license number, a social security number, etc.

[0177] The payload can include any suitable information (e.g., any suitable string of a particular element). In various embodiments, the payload includes encrypted information and the serial number of the device. In certain embodiments, the payload includes the key serial number used to decrypt the encrypted information. In one or more embodiments, the payload includes the firmware number of the device. In further embodiments, the payload includes any other suitable device or payload information related to the device, the transaction, and / or the merchant storing the device.

[0178] The encrypted information can be any suitable encrypted information, such as, for example, a social security number, a credit card number, payment information, a driver's license number, medical record information, a birthday, a deposit account number, a bank branch code, a name, etc. As described herein, the payload can be in any suitable format that can be used as a fingerprint to identify the device.

[0179] In step 532, the system is configured to analyze the payload to extract the serial number of the device. In various embodiments, the system analyzes the payload to extract the serial number of the device by separating the encrypted information from the unencrypted information and determining which one or more unencrypted numbers are included in the serial number of the device. In certain embodiments, the payload includes a string of numbers and information, and the serial number of the device is located at a particular position in the string (e.g., the serial number of the device can be the first number, the second number, the fifth number, etc.). As will be understood by those skilled in the art, the method of analyzing the payload can depend on the structure / form of the payload.

[0180] In step 534, the system is configured to retrieve a serial number table from the database, and the serial number table contains one or more serial numbers. In step 536, the system is configured to compare the serial number of the device with the serial number table to determine whether the serial number of the device is included in the serial number table. The system can be configured to compare the serial number of the device with the serial number table in any suitable way, including searching for the serial number of the device and comparing the serial number of the device with all the serial numbers in the table, and / or using some other indicator (such as a first number, etc.) to narrow down one or more serial numbers included in the serial number table that can match the serial number of the device. Those skilled in the art should understand that the serial number table can be two or more suitable serial number tables.

[0181] In step 538, when the system determines that the serial number of the device is included in the table, the system is configured to retrieve from the memory a fingerprint related to the device, and the fingerprint is an identifier of the device based on the format of one or more payloads generated by the device (see FIG. 5B for an explanation of fingerprint creation). In certain embodiments, the system is configured to create a fingerprint related to the device as further described herein. In a further embodiment, the system is configured to receive from a third-party system a fingerprint related to the device (for example, the third-party system creates a fingerprint and sends the fingerprint to the system). In yet a further embodiment, the fingerprint of the device is manually input by one or more users.

[0182] In step 540, the system is configured to compare the payload with the fingerprint to determine whether the device has been accessed illegally. In various embodiments, the system compares the format of the payload (e.g., the order of specific elements of the payload) with the fingerprint (e.g., representing the format of the first payload received from the device) to check whether the format matches the fingerprint. In some embodiments, the system compares various elements of the payload with the fingerprint in terms of format, such as the key serial number, the firmware number of the device, etc., and is configured to determine whether the device has been accessed illegally (e.g., if the compared elements do not match the corresponding parts of the fingerprint, the device may have been accessed illegally).

[0183] In step 542, if the system determines that the device has not been accessed illegally, it is configured to facilitate the decryption of the encrypted information. In various embodiments, the system is configured to facilitate the decryption of the encrypted information by sending the encrypted information (and / or the entire payload) to the HSM for decryption. If it is determined that the device has been accessed illegally, the system can discard the payload (e.g., not facilitate the decryption of the encrypted information), notify the merchant, change the state of the device (e.g., as described herein), and / or configure not to accept the payload from the device anymore.

[0184] Exemplary Payload - Fingerprint - Process Generally, FIG. 5B shows an exemplary process for generating a fingerprint of a device. Starting from FIG. 5B, in step 531, the system is configured to receive a payload from the device. The system can be configured to receive the payload from any suitable device, such as any of the suitable devices described above with respect to step 530, for example.

[0185] In step 533, the system is configured to determine whether the received payload is the first payload received from the device. In various embodiments, the system determines whether the received payload is the first payload received from the device by comparing the serial number included in the received payload with a list of serial numbers of the devices from which the payloads were received. In one or more embodiments, the system is configured to determine whether the received payload is the first payload received from the device by comparing a device identifier received from a user interface (e.g., the user enters the serial number of the device) with the identifier included in the payload of the device.

[0186] In step 535, the system is configured to analyze the received payload based on the determination that the received payload is the first payload received from the device. The system can be configured to analyze the payload of the device in any suitable manner as described herein. In step 537, the system is configured to determine the format of the payload. The system can be configured to determine the format of the payload in any suitable manner. Further, the format of the payload can be changed and can be in any suitable form such as those described herein, such as CHR, HEX, Base64, or any other suitable format. In certain embodiments, the system can store only the format of the payload, but not the track data.

[0187] For example, the payload format can be in the following form. FORMAT_CIPHERED_[TRACK1][_TRACK2][_KSN][_DSN] Continuing to refer to the above example, "CIPHERED" is an encryption algorithm and can be, for example, RAW (data is not encrypted), TDES (DES DUKPT), or AES (AES DUKPT). Further, in this example, each TRACK is formatted as 1, 2, or 3 "+" and a CHR string "+" a string of numbers in HEX format "+" a string of numbers in HEX format. Thus, in this example, the above TRACK1 is formatted as 1+CHR+HEX+HEX. In this example, the fingerprint has FORMAT in HEX format, CIPHERED as TDES, TRACK1 in 1+CHR+HEX+HEX format, TRACK2 in 2+CHR+HEX+HEX format, KSN (key serial number) in HEX format, and DSN (serial number of the device) in HEX format. Thus, in this example, the system is, HEX_TDES_1+CHR+HEX+HEX_2+CHR+HEX+HEX_HEX_HEX configured to create a fingerprint of.

[0188] In step 539, the system is configured to store the fingerprint of the device in memory, and the fingerprint is based on the format of the received payload. In step 541, the system is configured to compare each subsequent payload received from the device with the fingerprint of the device (e.g., to determine whether the device has been accessed illegally). In various embodiments, the system is configured to determine that the device has been accessed illegally if the format of a particular subsequent payload does not match the fingerprint of the device (e.g., someone has changed something about the output of the device such as the device's firmware version number, etc.).

[0189] Exemplary UML diagram Figures 6 through 14 show UML diagrams depicting various sequences of the system and method of the present invention. In particular, Figures 6 through 14 illustrate an exemplary process for point-to-point encryption (P2PE) transactions, where the payload may include encrypted data, unencrypted data, or both. Those skilled in the art will understand that these exemplary processes can be used in any type of transaction, including but not limited to end-to-end encrypted transactions. Lifelines and key process components are used throughout (e.g., QSAPI, where present, is represented by QSAPI602 throughout Figures 6 through 14).

[0190] In various embodiments, as shown in Figure 6, a customer (e.g., a merchant) posts data to be processed to a web application (e.g., via a web browser) in a post request 616. Based on the data included in the post, the web application selects a script to execute. Generally, Figures 6 through 14 show two script lifelines, qsapi - process - 3.8.php602 and validator.class.php1320, described further below. As shown in Figures 6 through 14, the system uses at least two databases, namely a POI database (Figures 9 and 12) and a Quickswipe database (Figures 6, 8, 9, 10, 12, and 14). In various embodiments, the POI database is the database used by the POI manager to persist information in various devices. According to one or more embodiments, the Quickswipe database is the database operably connected to qsapi - process - 3.8.php602 and used to store various qsapi - process - 3.8.php602 information.

[0191] Exemplary Overall System Sequence Referring to FIG. 6, in the illustrated embodiment, the lifeline qsapi - process - 3.8.php602 implements most of the P2PE management system functions via the Quickswipe API ("QSAPI602"). Those skilled in the art should understand that the QSAPI602 functions may be implemented by any suitable number of APIs, scripts, and / or functions. For simplicity and brevity, only QSAPI602 will be described. According to a particular embodiment, as shown in FIG. 6, QSAPI602 begins by instantiating a special ".PHP class" that encapsulates various processing aspects as described herein, including, but not limited to, instances of devices, device controllers, and poi classes.

[0192] Continuing to refer to FIG. 6, the "device" class 610 is the base class for all supported devices (e.g., POI devices, etc.). In a particular embodiment, each type of device related to the system (e.g., each device brand, model, etc.) has a corresponding child class that inherits from the device class 610 (e.g., each brand of POI device has a separate child class). In various embodiments, each child class includes one or more aspects of the device output inherited from the class, including, but not limited to, the device payload format (e.g., XML or binary format), an indication of whether the data is encrypted, etc. According to a particular embodiment, as shown in FIG. 6, the device class 610 receives information regarding each type of device via the fromString(device output) string and instantiates an instance of the appropriate device child class. In various embodiments, when the device payload contains encrypted data, the device class 610 uses the information in the appropriate child class to parse the device payload for data decryption (see fetch(device output)). In the embodiment shown in FIG. 6, the system uses the HSM device 608 of Luna EFT to decrypt the device payload data.

[0193] In various embodiments, the device class 610 selects a subclass to be instantiated via the method fromString() (e.g., based on the type of the device, etc.), creates a new() instance, and calls the fetch() method. According to certain embodiments, the fetch method parses the payload of the device and stores the parsed data. For example, the method fromString() of the device class 610 returns a reference that includes the parsed data of a particular payload. Continuing to refer to this particular example, the fromString reference can include card track 1, 2, 3 data, the serial number of the device, and / or the firmware and hardware information of the device (as described herein, the payload data of the device can include any suitable information).

[0194] Continuing to refer to FIG. 6, the device controller class 612 is, in certain embodiments, a controller class that encapsulates several activities that QSAPI602 uses to determine whether a particular device has been accessed illegally, tampered with, etc. In certain embodiments, an instance of the device controller class 612 is initialized by a Quickswipe database 606 accessor. In various embodiments, the device controller class 612, upon detection, sends an indication of any indication, such as tampering of the device, to the POI manager (see, e.g., the P2PE management system, FIG. 9). According to one or more embodiments, the device controller class 612 searches for and stores data in a Quickswipe database 606 table titled device_use.

[0195] An instance of the poi class 614 is initialized by the class_construct() method. The construction method, according to certain embodiments, searches for the HSM key index from the POI manager for legacy devices (see Figure 9) (e.g., the payloads of one or more devices are received by the system from one or more non-P2PE-certified devices). As shown in Figures 6-14, exemplary poi processes are loglncident() and getHsmKey(). Generally, in various embodiments, the poi class 614 posts requests to the POI manager and interprets the POI manager responses (see Figure 9).

[0196] As shown in Figure 6, the HSM device 608 of Luna EFT (e.g., HSM device 608) is special hardware for encrypting or decrypting data in various embodiments. As described herein, according to certain embodiments, keys are injected in a key injection facility for certain devices. In these (and other) embodiments, this base key is stored in an internal table in the HSM device (e.g., HSM device 608). Continuing to refer to this embodiment, to decrypt encrypted data from the payload of a particular device, the decrypt() method passes the key index included in the payload of the particular device to the HSM device 608 to derive the associated transaction key. In some embodiments, the POI manager stores the HSM key index in the POI database (as shown in Figure 9), and the QSAPI 602 searches for various base keys by the serial number of the device.

[0197] In various embodiments, upon receiving a child class that inherits from the device class 610 of a particular device, the QSAPI 602 determines which one or more sub - processes (the "options") to complete (e.g., sub - processes 620, 630, and 640). In step 620, if the QSAPI 602 determines that the payload of a particular device does not contain the device's serial number, it treats the particular device as a non - P2PE device (e.g., thus, in these (and other) embodiments, the QSAPI 602 does not search for or request an access key to the POI manager from the Quickswipe database).

[0198] Continuing with step 630, if the QSAPI 602 determines that the payload of a particular device contains the device's serial number, it compares the payload of the device with the fingerprint associated with the device (as described herein) in the "device capture" further described in FIG. 8. In one or more embodiments, upon completion of the device capture process, the QSAPI 602 receives a record of the device_use table in the Quickswipe database 606.

[0199] In step 630, if the QSAPI 602 determines that the payload of a particular device contains encrypted data, it searches the POI manager for an HSM key index for decryption and passes it to the HSM device 608 as further described in FIG. 11 (HSM key index acquisition). When the HSM key index acquisition process returns a non - positive value, the QSAPI 602 sends an error response and terminates. Otherwise, the HSM key index acquisition returns the HSM key index used to decrypt any encrypted data contained in the payload of the particular device. For details regarding the key index update process, refer to FIG. 12.

[0200] According to certain embodiments, upon completion of the key index update process (e.g., in FIG. 12), QSAPI602 returns to the decrypt(key index) method that is passed to device class 610. In various embodiments, device class 610 uses the key index provided by the decrypt(key index) method to decrypt the encrypted data of a particular device's payload and transmits the required data to HSM device 608. In one or more embodiments, device class 610 transmits a DECIPHER2Luna EFT command (including the key index and encoded data) to HSM device 608, and HSM device 608 decrypts the encrypted payload data of a particular device. In a further embodiment, upon decryption, the decrypted payload data is transmitted from HSM device 608 to device class 610, and the decrypted clear track data is parsed by parseDecryptedData(). In these (and other) embodiments, without limitation, relevant data including the parsed card track, PAN data, expiration date, cvv number, card owner data, etc. is included in the data container CardData as shown in FIG. 6.

[0201] In step 640, in some embodiments, upon determining that a particular device's payload does not contain encrypted data, QSAPI602 calls the parseTracks() method of device class 608 and obtains a data container (e.g., CardData container) filled with parsed card number, expiration date, card owner data, etc. In step 650, QSAPI602 verifies the data contained in the CardData container, which is further described with respect to FIG. 13. In step 660, QSAPI602 processes any exceptions in the handling exception process, which is further described with respect to FIG. 14.

[0202] Exemplary Device Capture Sequence Referring to FIG. 8, the exemplary device capture process described herein is embodied in an embodiment where the payload of a particular device includes the serial number of the device. QSAPI 602 calls the device class 608 with a string (e.g., the device fingerprint as described in the exemplary process shown herein and in FIG. 7) that identifies specific characteristics of the payload of a particular device, including, for example, the payload format of the device (e.g., XML, hexadecimal string, etc.), an indication of whether a portion of the payload of the device is encrypted, the number of tracks included, etc. After the payload format of the device has been determined, in various embodiments, QSAPI 602 calls the method captureDevice() of the device controller class 612 with the serial number of the device, the device fingerprint, and a flag indicating whether a portion of the payload of the device is encrypted.

[0203] In one or more embodiments, the device controller class 612 uses the serial number of the device (e.g., in the above CaptureDevice()) for a particular device to look for a record of the particular device in the device_use record table in the Quickswipe database 606. When it finds a record of the particular device in the Quickswipe database 606, the device controller class 612 tests various aspects of the device_use information (e.g., stored in the Quickswipe database 606) in certain embodiments. In some embodiments, the device controller class 612 determines whether the system has marked a particular device as tampered with (e.g., the system has changed the state of a particular device to tampered). In these embodiments, the system is configured to determine that a particular device has been marked as tampered with (e.g., indicated that it has been marked as tampered by the POI manager) when the date_disabled column returns a "NOT NULL" value. Upon receiving a NOT NULL value for the date_disabled column, according to certain embodiments, the captureDevice() method returns a "FALSE" value to the QSAPI 602. In further embodiments, upon receiving a "FALSE" value from the captureDevice() method, the QSAPI 602 sends an error response to the user and terminates the execution of the process (e.g., does not proceed with decrypting any encrypted payload information received from the particular device).

[0204] In various embodiments, when receiving a value other than NOT NULL for the date_disabled column, the system determines whether the encryption flag of a particular device matches the encryption instruction stored in the Quickswipe database 606. In certain embodiments, the system compares the received encrypted flag (such as that received with the payload in captureDevice() above) with the encryption flag stored in the Quickswipe database 606 for a particular device. According to certain embodiments, QSAPI 602 interprets a change in the encrypted flag of a particular device (the output is encrypted, but the data is not encrypted at this point) as an indication that the particular device has been accessed or tampered with illegally and should be disabled. In these embodiments, the captureDevice() method returns FALSE to QSAPI 602, and QSAPI 602 sends an error response to the user and terminates the execution of the process. See Figure 9 for further information regarding the disabling of the device.

[0205] According to one or more embodiments, upon determining that the received encrypted flag matches the stored encryption instruction in the Quickswipe database 606, the system is configured to compare the payload format of the device with the stored fingerprint of the particular device stored in the Quickswipe database 606. According to certain embodiments, QSAPI 602 interprets a change in the fingerprint of the device as a transient failure (for example, several intermittent factors such as an unreliable USB connection of the device to a personal computer that can change the payload format of the device may cause the payload format of the device to be different). See Figure 10 for further details regarding transient failures. In a further embodiment, in response to the system determining that the payload format of a particular device does not match the fingerprint, captureDevice() returns FALSE, as a result of which QSAPI 602 sends an error response to the user and terminates the execution of the process.

[0206] If all of the above checks are evaluated as False, the captureDevice() method returns the value at that point in the DEVICE_USE row to QSAPI602. If it is determined that a particular device is being used for the first time (device_use column NOT FOUND), the device controller class 612 inserts a new device_use column with the encrypted flag and the device fingerprint passed into the Quickswipe database 606.

[0207] Exemplary device disable sequence Referring to FIG. 9, according to various embodiments, the POI manager 910 tracks the storage of a series of devices. According to various embodiments, the POI manager 910 is embodied as a set of ".PHP classes" involved in several activities. In some embodiments, the POI manager 910 returns to an appropriate controller class, such as the device controller class 612, based on the type of request posted by QSAPI602. As shown in FIG. 9, since the payload of a particular device is not encrypted (e.g., but should be decrypted), the POI manager 910 receives an instruction to decrypt a particular device (e.g., the particular device described in the above embodiments). In the embodiment shown in FIG. 9, the particular device is disabled in the Quickswipe database 606, and the disable_date is set to the value of the date and time at that point. The POI manager 910 modifies the status of the particular device to be tampered with in the POI database 920.

[0208] Exemplary failure count increment sequence Referring to FIG. 10, in various embodiments, QSAPI602 tracks each failed encryption attempt for all devices whose serial numbers are known. According to certain embodiments, when information about a particular device is captured for the first time, the system adds a new row to the device_use table, sets the failed_count to 0, and sets the max_failed_count to a hard-coded limit (such as 5, 10, etc.). In one or more embodiments, each time a payload is received from a particular device, QSAPI602 performs a verification check. In further embodiments, QSAPI602 increments the failed_count value each time the verification check fails. In still further embodiments, when the failed_count reaches the max_failed_count hard-coded limit (e.g., 2, 5, 7, 10, 20, etc.), the system disables the particular device (e.g., stops decrypting any payloads received from the particular device). In certain embodiments, the system can be configured to reset the failed_count value to 0 each time the verification check passes. In some embodiments, the system can be configured to increment the failed_count value each time the verification check fails, regardless of whether there were any intermediate passing verification checks. An exemplary device disabling process was described above with respect to FIG. 9.

[0209] Exemplary HSM Key Index Acquisition Sequence When it is determined that the payload of a particular device contains encrypted data, QSAPI602 follows the exemplary process shown in FIG. 11. As described herein, in various embodiments, the payload of a particular device includes an integer value indicating the number of times the decryption key value was derived from the base key. In some embodiments, the HSM device 608 derives the encryption key from its internal copy of the base key and uses the derived encryption key to decrypt the encrypted data within the payload of the particular device.

[0210] According to a particular embodiment, QSAPI602 searches for a poi_accessKey corresponding to a particular device from poi class 614. In one or more embodiments, if it is determined that the poi_accessKey is NULL or empty, poi class 614 returns a legacy_key_index (e.g., indicating that the particular device is a "legacy device" and not part of the P2PE decryption scheme). In various embodiments, if it is determined that the serial number of the particular device is not empty and the poi_accessKey is not NULL, poi class 614 requests an hsm_key_id from the POI manager web server 1110 as shown in FIG. 11.

[0211] As will be appreciated by those skilled in the art, in some embodiments, the HSM device 608 stores two or more base keys in an internal HSM device table. Thus, in these embodiments (and other embodiments), the HSM device 608 requests an indication of which of the two or more base keys to use to decrypt the payload of a particular device. As described above, in some embodiments, the POI manager stores an HSM key index in the POI database (as shown in FIG. 9), and QSAPI602 searches for various base keys by the serial number of the device and sends the HSM key index (indicating the base key to be used to decrypt the payload of the particular device) to the HSM device 608.

[0212] Exemplary key index update sequence FIG. 12 shows an exemplary key index update sequence. As shown in the embodiment of FIG. 12, the system is configured to disable a particular device as described above if it determines that the key index associated with the particular device has changed.

[0213] Exemplary verification sequence Referring to FIG. 13, in the illustrated embodiment, when QSAPI602 receives a payload from a particular device, it determines (e.g., by checking a fingerprint and / or other suitable record associated with the particular device) whether the payload contains track 1 data in the correct format, track 2 data in the correct format, or both. If the payload does not contain track 1 data in the correct format, track 2 data in the correct format, or both, QSAPI602 sends an error response to the user and terminates the execution of the process. Continuing with this sequence, when the system determines that the payload contains track 1 data in the correct format, track 2 data in the correct format, or both (or any suitable number of tracks), in a particular embodiment, QSAPI602 proceeds to verify track 1, track 2, or both. According to a particular embodiment, the card track data is assumed to be a non-empty string of numbers 0-9, which passes the mod10 check in validator.class.php1320. In one or more embodiments, the system is configured such that, in the case of a card whose card track number has been successfully verified, the device controller class 612 resets the device_use.failed_count (as described above) of the particular device to zero (0).

[0214] Further Exemplary Processes FIGS. 15-17 illustrate further exemplary processes of the system described herein. In particular, FIG. 15 illustrates an exemplary queuing process, FIG. 16 illustrates an exemplary update process, and FIG. 17 illustrates an exemplary decryption verification process. Each of these exemplary processes is described below.

[0215] Exemplary Queuing Process Referring now to FIG. 15, an exemplary queuing process is shown. As further described herein, the system can be configured to queue various messages in a queue (e.g., MQTT queue 231). In certain embodiments, the system can queue messages as a backup method when the primary form of the storage device becomes unavailable. For example, in the example shown in FIG. 2B, when the read / write database 232 ceases to function correctly, a queue hosted on the same machine as the master read-only database 230 can store messages sent from the master read-only database 230 to the read / write database 232 until the read / write database 232 functions or at least receives and stores the messages.

[0216] In step 1502, the system generates a message. As described herein, the message can be any suitable message generated by any suitable component of the system. In various embodiments, a front-end server (e.g., authentication web server 224) can generate a log or other suitable event each time a payload is received and / or authenticated (as described herein). In certain embodiments, the front-end server can generate one or more exceptions written to a database (e.g., an exception recording that a particular payload failed authentication). In at least one embodiment, other components of the system, such as a master read-only database (e.g., master read-only database 230), a read-only database (e.g., read-only database 228), or any other server or component described herein, can generate the messages to be queued.

[0217] In step 1504, the system adds the message to the queue. In certain embodiments, the system includes a queue hosted on the same computing device that hosts the master read-only database 230 (FIG. 2). In these embodiments, still referring to FIG. 2, the system is configured to add messages sent from the authentication web server 224 to the queue.

[0218] In step 1506, the system stores the message in the queue. The system can be configured to store the message in the queue for any predetermined amount of time until a particular event occurs and / or until a particular set of conditions are met. In certain embodiments, the system is configured to store the message in the queue for seconds, minutes, hours, over a particular number of days (e.g., until a particular weekend or a specific weekend), etc. In some embodiments, the system is configured to store the message in the queue until it processes less than 250 (or e.g., 500, 750, 1000, etc.) payloads per second, and then the queue can be configured to send the message. In further embodiments, the system can be configured to store the message until a particular amount of resources become available or until the intended recipient of the message (e.g., the read / write database 232) is able to receive the message (e.g., is functioning, not malfunctioning, online, etc.).

[0219] In step 1508, the system determines whether the recipient of the message is configured to receive the message. In step 1510, if the system determines that the recipient of the message is configured to receive the message, it sends the stored message to the recipient of the message (e.g., the read / write database). If it determines that the recipient of the message is not configured to receive the message, the system continues to add the message to the queue but is configured not to send any of the stored messages to the recipient of the message.

[0220] Exemplary update process FIG. 16 shows an exemplary process of an event-driven update according to one embodiment of the system and method of the present invention. In various embodiments, the system is configured to update various databases of the system when a specific event occurs, such as the reception of a part of information. In at least one embodiment, the system is configured to update various databases (such as the master read-only database 230) when it receives information about a new device (such as information about a new POI device received in the P2PE manager 166 as described with respect to FIG. 1).

[0221] In step 1602, the system generates or receives event information. As further described herein, the system can generate or receive any event information. In a particular embodiment, the system can receive (or generate) event information regarding a new device registered in the system (such as described herein), event information regarding a change in the state of a particular device (such as the state of a particular device changes from "active" to "tampered"), event information regarding a particular device that has failed to decrypt, etc.

[0222] In step 1604, the system transmits new authentication data based on the event information. In certain embodiments, the system is configured to generate authentication data from the event information to be transmitted to one or more databases of the system for authentication and verification of the payloads transmitted to the system. In step 1606, the system refreshes the master database and includes the new authentication data. In step 1608, the system refreshes one or more slave databases and includes the new authentication data. As a specific example, the system receives event information that a new device has been registered with the system. In this specific example, the event information includes the serial number (or other suitable identifier) associated with the device. Continuing with this specific example, the system formats or otherwise generates the authentication information associated with the device to be transmitted to the system's database. Thus, in this specific example, when the authentication data is transmitted to the system's database (e.g., to the read-only database 228), the system can use this authentication information to authenticate the payload received from the device.

[0223] Exemplary Decryption Verification Process When the payload is transmitted to and processed by the hardware security module, the system can be configured to confirm that the payload has been decrypted in at least one specific embodiment. An exemplary process for confirming the decryption of the payload is shown in FIG. 17. Starting at step 1702, the decryption server receives a payload that includes at least one encrypted element. In various embodiments, the decryption server is configured to receive the payload from any suitable source, including but not limited to a front-end server (e.g., the authentication web server 224), a load balancer, a read-write database, directly from a third-party partner (e.g., a payment processor, a health management system, an administrative system, etc.).

[0224] In step 1704, the decryption server sends the payload to the hardware security module for decryption of at least one encrypted element. In step 1706, the decryption server receives the payload from the hardware security module (e.g., after the hardware security module decrypts or attempts to decrypt at least one encrypted element of the payload).

[0225] In step 1708, the decryption server analyzes the payload to identify the location of at least one encrypted element. The system can be configured to analyze the payload in any suitable manner, such as by identifying the location of the at least one encrypted element based on its location within a text / code string. In step 1710, the decryption server determines whether the hardware security module has decrypted at least one encrypted element. In various embodiments, the system is configured to determine whether the hardware security module has decrypted at least one encrypted element by comparing the characters of the at least one encrypted element with those of a database. In certain embodiments, the system is configured to determine whether the hardware security module has decrypted at least one encrypted element by comparing the number of characters of the at least one encrypted element (e.g., if it is determined that the at least one encrypted element contains more, fewer, or a specific number of characters, the system determines whether the at least one encrypted element has been encrypted or not). In further embodiments, the system is configured to determine whether the hardware security module has decrypted at least one encrypted element by determining whether a payment card number (e.g., credit card number or other payment information) is included in the payload.

[0226] In step 1712, if it is determined that the hardware security module did not decrypt at least one encrypted element, the decryption server generates an error (e.g., this is sent to the read / write database and / or a third-party partner in some embodiments), and in some embodiments, the payload can be not sent to the third-party partner. In step 1714, if it is determined that the hardware security module decrypted at least one encrypted element, the decryption server sends the payload to the third-party partner.

[0227] Conclusion Aspects, features, and advantages of the invention(s) recited in the claims will be apparent from the information disclosed in the attached sheets and other applications incorporated by reference. Modifications and variations of the disclosed systems and methods can be made without departing from the spirit and scope of the novel concepts of this disclosure.

[0228] Nevertheless, it is understood that no limitation of the scope of this disclosure is intended by the information disclosed in the attached sheets or applications incorporated by reference, and any alternative and further modifications of the described or illustrated embodiments, as well as any further applications of the principles of the disclosure as shown therein, are intended to be readily envisioned by one of ordinary skill in the art to which this disclosure pertains.

[0229] The foregoing description of the exemplary embodiments has been presented for purposes of illustration and description only. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings.

[0230] Embodiments are chosen and described in order to enable those skilled in the art to use the present invention and its various embodiments, to explain the principles of the present invention and their practical applications, and various modifications are suitable for the particular use intended. Alternative embodiments will be apparent to those skilled in the art of the present invention without departing from the spirit and scope of the present invention. Accordingly, the scope of the present invention is defined not by the above description and the exemplary embodiments described therein, but by the appended claims.

Claims

1. A system for decrypting a payload, comprising: A front-end server operably connected to a read-only database, a) receiving a plurality of payloads from one or more third parties, each of the plurality of payloads including at least one encrypted element; b) reading authentication data from the read-only database; c) comparing the authentication data with each of the plurality of payloads to determine whether any of the plurality of payloads has been tampered with; d) if it is determined that one or more of the plurality of payloads have not been tampered with, transmitting the one or more payloads determined not to have been tampered with among the plurality of payloads to a hardware security module for decrypting the at least one encrypted element within the one or more payloads; The read-only database operably connected to the front-end server and configured to store authentication data used to determine whether a payload has been tampered with; The hardware security module operably connected to the front-end server, configured to decrypt the at least one encrypted element from the one or more payloads based on an encryption key and transmit one or more payloads including the decrypted at least one element to the one or more third parties.

2. The system according to claim 1, wherein each payload includes an identifier associated with a source of the payload.

3. Reading authentication data from the read-only database includes: Reading authentication data from the read-only database for each of the plurality of received payloads using each identifier associated with each of the plurality of payloads.

4. The system according to claim 3, wherein the identifier is a serial number or a firmware identifier associated with a specific POI (point of interaction) device. **Claim 5** The system according to claim 3, wherein the identifier is associated with a mobile payment system. **Claim 6** The system according to claim 3, wherein the identifier is an identifier associated with an electronic medical record system. **Claim 7** The read-only database is a first read-only database, a) a second read-only database operably connected to the front-end server and configured to store authentication data used to determine whether the payload has been tampered with; b) a master read-only database operably connected to the first and second read-only databases and the read-write back-end database, the master read-only database being configured to receive the authentication data from the read-write back-end database and refresh the authentication data in each of the first and second read-only databases. The system according to claim 1, further comprising the master read-only database. **Claim 8** The system further comprises a third read-only database operably connected to the front-end server and configured to store authentication data used to determine whether the payload has been tampered with, the master read-only database is operably connected to the first, second, and third read-only databases and the read-write back-end database, and the master read-only database is configured to receive the authentication data from the read-write back-end database and refresh the authentication data in each of the first, second, and third read-only databases. The system according to claim 7. **Claim 9** The hardware security module is a first hardware security module, The system further comprises a second hardware security module operably connected to the front-end server. The second hardware security module is configured to decrypt at least one encrypted element of the one or more payloads based on the encryption key for the one or more payloads, and transmit one or more payloads including the decrypted at least one element to the one or more third parties. The system according to claim 8.

10. The system according to claim 9, configured to process up to about 1600 transactions per second.

11. The system according to claim 9, configured to process twice the number of transactions by doubling the number of the read-only database and the hardware security module.

12. The system according to claim 11, configured to process up to about 3200 transactions per second.

13. A method executed by a computer for decrypting a payload, comprising: A front-end server operably connected to a read-only database, a) receiving a plurality of payloads from one or more third parties, each of the plurality of payloads including at least one encrypted element, receiving the plurality of payloads; b) reading authentication data from the read-only database; c) comparing the authentication data with each of the plurality of payloads to determine whether any of the plurality of payloads has been tampered with; d) when it is determined that one or more of the plurality of payloads have not been tampered with, transmitting the one or more payloads determined not to have been tampered with among the plurality of payloads to a hardware security module for decrypting the at least one encrypted element within the one or more payloads. Preparing the front-end server configured to execute; Preparing the read-only database operably connected to the front-end server and configured to store authentication data used to determine whether a payload has been tampered with. The hardware security module operably connected to the front-end server, which decrypts at least one encrypted element from the one or more payloads among the plurality of payloads based on an encryption key and transmits one or more payloads including the decrypted at least one element to the one or more third parties. Preparing the described hardware security module configured as such, a method comprising this.

14. The method according to claim 13, wherein each payload includes an identifier associated with the source of the payload.

15. Reading authentication data from the read-only database The method according to claim 14, including reading authentication data from the read-only database for each of the plurality of received payloads using each identifier associated with each of the plurality of payloads.

16. The method according to claim 15, wherein the identifier is a serial number or firmware identifier associated with a specific POI (point of interaction) device.

17. The method according to claim 15, wherein the identifier is an identifier associated with a mobile payment system.

18. The method according to claim 15, wherein the identifier is an identifier associated with an electronic medical record system.

19. The read-only database is a first read-only database, a) Preparing a second read-only database operably connected to the front-end server and configured to store authentication data used to determine whether a payload has been tampered with. b) A master read-only database operably connected to the first and second read-only databases and a read-write back-end database, which receives the authentication data from the read-write back-end database and is configured to refresh the authentication data in each of the first and second read-only databases. The method according to claim 13, further comprising preparing the described master read-only database.

20. The method Further comprising preparing a third read-only database that is operably connected to the front-end server and configured to store authentication data used to determine whether the payload has been tampered with. The method according to claim 19, wherein the master read-only database is operably connected to the first, second, and third read-only databases and the read-write back-end database, and the master read-only database is configured to receive the authentication data from the read-write back-end database and refresh the authentication data in each of the first, second, and third read-only databases.

Images