System and method for protecting data through stateless tokenization

Abstract

A method of protecting data by stateless tokenization includes receiving a character string, selecting a character window within the character string, accessing a token table at an index equal to a value of the character window, retrieving a tokenized value from the token table at the index, replacing the value of the character window with the tokenized value, and storing the value of the character window with the tokenized value. Shifting the character window by a character in a first direction, accessing the token table at the index equal to the value of the character window, retrieving a tokenized value, replacing the value of the character window with the tokenized value, shifting the character window by a character in a second direction, accessing the token table at the index equal to the value of the character window, retrieving the tokenized value, and replacing the value of the character window with the tokenized value. The token table is accessed at the index equal to the value of the character window, a tokenized value is retrieved, the value of the character window is replaced with the tokenized value, and the character string is returned as a tokenized character string.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of priority to U.S. Application No. 17 / 661,118, filed on April 28, 2022, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to the field of secure network transactions, and more particularly to the stateless generation of such tokens. Background Art

[0004] A reality of the modern Internet-connected world is that the storage and transmission of sensitive and secure electronic data may be susceptible to data breaches. In addition, as electronic systems such as point-of-sale ("POS") systems become more complex, and as hackers become more sophisticated, security issues continue to increase.

[0005] In the early days of electronic transactions, dedicated magnetic card readers would scan unencrypted sensitive data on credit cards and transmit it to a transaction service to complete the transaction. These communications were typically conducted over a dial-up connection and required basic encryption in the reader device to maintain packet security.

[0006] Over time, reader devices have become more advanced, often with Internet connection ports and data input ports that enable malware to infect POS terminals. In addition, as more merchants turn to transmitting data over the Internet, additional security features have been developed.

[0007] Most notably, "tokenization" is a means of replacing sensitive data with "tokens" of data that are not decryptable or detonable (e.g., because they require a third party to decrypt) by the merchant or other tokenized user. For example, the merchant itself may never store sensitive data, thereby enhancing data security.

[0008] However, typical "stateful" tokenization systems maintain a database of plaintext and token pairs. Such a database must be maintained and protected indefinitely to allow detokenization via lookups in the database. As a result, the database will grow monotonically over time as new plaintext token pairs are added. The maintenance requirements and security requirements of the database may impose an ever-increasing processing and storage burden on the tokenization system, potentially causing system performance degradation and increasing expenses for the organization providing the tokenization service.

[0009] The present disclosure is directed to overcoming one or more of these aforementioned challenges. Summary of the invention

[0010] According to certain aspects of the present disclosure, systems and methods for protecting data through stateless tokenization are disclosed.

[0011] In one embodiment, a computer-implemented method for protecting data through stateless tokenization is disclosed, the method comprising: receiving a string, selecting a character window at a starting point within the string, accessing a token table at an index equal to the value of the character window, retrieving a first tokenized value corresponding to the value of the character window from the token table at the index, replacing the value of the character window within the string with the retrieved first tokenized value, shifting the character window within the string by one character in a first direction, accessing the token table at an index equal to the value of the shifted character window, retrieving a second tokenized value corresponding to the value of the shifted character window from the token table at the index, replacing the value of the shifted character window within the string with the retrieved second tokenized value, shifting the shifted character window within the string by one character in a second direction, accessing the token table at an index equal to the value of the shifted character window, retrieving a third tokenized value corresponding to the value of the shifted character window from the token table at the index, replacing the value of the shifted character window within the string with the retrieved third tokenized value, and returning the string as a tokenized string.

[0012] According to another embodiment, a system for protecting data by stateless tokenization is disclosed, the system comprising: a data storage device storing instructions for protecting data by stateless tokenization in an electronic storage medium; and a processor configured to execute the instructions to perform a method comprising: receiving a string, selecting a character window at a starting point within the string, accessing a token table at an index equal to the value of the character window, retrieving a first tokenized value corresponding to the value of the character window from the token table at the index, replacing the value of the character window within the string with the retrieved first tokenized value, and shifting the character window within the string in a first direction. The character window is shifted by one character, the token table is accessed at an index equal to the value of the shifted character window, a second tokenized value corresponding to the value of the shifted character window is retrieved from the token table at the index, the value of the shifted character window within the string is replaced with the retrieved second tokenized value, the shifted character window within the string is shifted by one character in a second direction, the token table is accessed at an index equal to the value of the shifted character window, a third tokenized value corresponding to the value of the shifted character window is retrieved from the token table at the index, the value of the shifted character window within the string is replaced with the retrieved third tokenized value, and the string is returned as a tokenized string.

[0013] According to another embodiment, a non-transitory machine-readable medium storing instructions, which, when executed by a computing system, causes the computing system to perform a method for protecting data through stateless tokenization, the method comprising: receiving a string, selecting a character window at a starting point within the string, accessing a token table at an index equal to the value of the character window, retrieving a first tokenized value corresponding to the value of the character window from the token table at the index, replacing the value of the character window within the string with the retrieved first tokenized value, shifting the character window within the string by one character in a first direction, accessing the token table at an index equal to the value of the shifted character window, retrieving a second tokenized value corresponding to the value of the shifted character window from the token table at the index, replacing the value of the shifted character window within the string with the retrieved second tokenized value, shifting the shifted character window within the string by one character in a second direction, accessing the token table at an index equal to the value of the shifted character window, retrieving a third tokenized value corresponding to the value of the shifted character window from the token table at the index, replacing the value of the shifted character window within the string with the retrieved third tokenized value, and returning the string as a tokenized string.

[0014] Additional objects and advantages of the disclosed embodiments will be set forth in part in the following description, and in part will be apparent from the description, or may be understood by the practice of the disclosed embodiments. The objects and advantages of the disclosed embodiments will be realized and obtained by the elements and combinations particularly pointed out in the appended claims.

[0015] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and, together with the description, serve to explain the principles of the disclosed embodiments.

[0017] Figure 1 Depicted is an exemplary system infrastructure for protecting data through stateless tokenization in accordance with one or more embodiments.

[0018] Figure 2 Depicted is an exemplary distributed system infrastructure for protecting data through stateless tokenization in accordance with one or more embodiments.

[0019] Figure 3A Depicted is an exemplary token table employed in a method of protecting data through stateless tokenization in accordance with one or more embodiments.

[0020] Figure 3B-Figure 3CDepicted is an exemplary process flow for protecting data through stateless tokenization in accordance with one or more embodiments.

[0021] Figure 3D Depicted is an exemplary reverse token table employed in a method of protecting data through stateless tokenization in accordance with one or more embodiments.

[0022] Figure 3E Depicted is an exemplary token table file stored on disk and employed in a method of protecting data through stateless tokenization in accordance with one or more embodiments.

[0023] Figure 4 Depicted is a flow diagram of a method of protecting data through stateless tokenization in accordance with one or more embodiments.

[0024] Figure 5 A specific implementation of a computer system is shown that can perform the techniques presented herein. DETAILED DESCRIPTION

[0025] The following discussion relates to methods and systems for protecting data through stateless tokenization. For example, such methods and systems can enable merchants to use secure sensitive customer data through tokenization without burdening the tokenization service with maintaining a stateful database of tokens and tokenized values.

[0026] Today, tokenization is used as a method to provide data security for sensitive data. With tokenization, non-sensitive reference data can be provided to the requesting client in exchange for sensitive data elements. The reference data can be considered non-sensitive because the associated sensitive data can only be retrieved through security controls that authenticate and authorize the requester. This allows the client to store the non-sensitive reference data and offload any sensitive data storage to the tokenization provider, reducing audit requirements and any potential loss of sensitive data in the event of a security incident.

[0027] Tokenization has become a popular method for protecting payment transaction data (e.g., primary account numbers, etc.) and many different token service providers have emerged to provide this functionality. However, typical "stateful" tokenization services rely on the maintenance of a database of plaintext token pairs. Such a database must be maintained and protected indefinitely to allow detokenization by looking up in the database. Therefore, as new plaintext token pairs are added, the database will grow monotonically over time. The maintenance and security requirements of the database may impose an increasing processing and storage burden on the tokenization system, may cause system performance degradation, and increase the cost of the organization providing the tokenization service. In addition, the need to maintain the database and the size of the ever-growing database make distributed processing of the tokenization service impractical. The lack of such distributed processing may result in a single point of failure of the tokenization service, may result in increased processing time for the tokenization service, and increase the cost of the users of the service. In contrast, a "stateless" tokenization system according to one or more embodiments can avoid these problems by not using a database at all. Instead, such a system can use a static token table of limited size to tokenize the plaintext and detokenize the tokens in the computer memory.

[0028] It should be understood that due to the popularity of credit card transactions, special consideration is given herein to credit card transactions. Although this references credit cards, the disclosed systems and methods are equally applicable to the transmission of any sensitive data, whether "card present" or "card not present" (CNP) transactions, or transactions outside of financial transactions. Within the field of financial transactions, the disclosed systems and methods can be applied to online transactions, for example, where the user is not actually present at the merchant's location. Transactions can include credit / debit transactions, gift card transactions, PayPal transactions, Bitcoin transactions, smart card transactions, mobile application transactions, and the use of membership cards, etc. In fact, in any case where sensitive data, such as primary account number (PAN), social security number, bank routing number, driver's license number, etc., or tokens corresponding thereto, are transmitted over a network, the systems and methods disclosed herein can be used. In addition, although the party attempting to initiate a secure transaction may be referred to as a "merchant" herein, the party attempting to initiate a secure transaction does not have to be a merchant, but can be a service provider or any party attempting to perform a transaction.

[0029] Applications of the disclosed tokenization systems and methods may provide benefits for applications in payments, banking, government benefits (EBT), wealth management, healthcare management, travel, and any other scenarios where sensitive information is to be stored, transmitted, or otherwise shared.

[0030] Various non-limiting embodiments of the present disclosure will now be described to provide an overall understanding of the structure, function, and use of the systems and methods for electronic transaction message transfer conversion disclosed herein. One or more examples of these non-limiting embodiments are illustrated in the accompanying drawings. Figure 1-Figure 5 The present invention is shown in selected examples disclosed and described in detail. It will be understood by those skilled in the art that the systems and methods specifically described herein and illustrated in the accompanying drawings are non-limiting embodiments. Features shown or described in conjunction with one non-limiting embodiment may be combined with features of other non-limiting embodiments. Such modifications and variations are intended to be included within the scope of the embodiments of the present disclosure.

[0031] The systems, devices, equipment and methods disclosed herein are described in detail by way of example and with reference to the accompanying drawings. The examples discussed herein are merely examples and are provided to help explain the devices, devices, systems and methods described herein. Unless specifically specified as mandatory, the features or components shown in the drawings or discussed below should not be considered as mandatory for any specific implementation of any of these devices, devices, systems or methods. For ease of reading and clarity, certain components, modules or methods may be described only in conjunction with specific drawings. In the present disclosure, any identification of a specific technology, arrangement, etc. is related to the specific examples presented, or is merely a general description of such technology, arrangement, etc. The identification of specific details or examples is not intended to be and should not be interpreted as mandatory or restrictive unless specifically specified in this way. Any combination or sub-combination that fails to specifically describe a component should not be understood as any combination or sub-combination is impossible. It should be understood that the disclosed and described examples, arrangements, configurations, components, elements, devices, equipment, systems, methods, etc. can be modified and may be desired by a specific application. Furthermore, for any method described, whether or not the method is described in conjunction with a flowchart, it should be understood that, unless otherwise specified or required by the context, any explicit or implicit ordering of steps performed in the execution of the method does not imply that the steps must be performed in the order presented, but may be performed in a different order or in parallel.

[0032] References throughout the specification to "various embodiments," "some embodiments," "one embodiment," "some exemplary embodiments," "an exemplary embodiment," or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with any embodiment is included in at least one embodiment. Thus, the phrases "in various embodiments," "in some embodiments," "in one embodiment," "some exemplary embodiments," "an exemplary embodiment," or "in an embodiment" appearing throughout the specification do not necessarily all refer to the same embodiment. Further, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0033] Throughout this disclosure, reference to a component or module generally refers to an item that can be logically grouped together to perform a function or a group of related functions. Similar reference numerals are generally intended to refer to the same or similar components. Components and modules can be implemented in software, hardware, or a combination of software and hardware. The term "software" is used extensively to include not only executable code, such as machine executable instructions or machine interpretable instructions, but also data structures, data storage, and computing instructions stored in any suitable electronic format, including firmware and embedded software. The terms "information" and "data" are used extensively and include a wide variety of electronic information, including executable code; content such as text, video data, and audio data; and various codes or signs. When the context permits, the terms "information", "data", and "content" are sometimes used interchangeably. It should be noted that although some examples discussed herein may describe specific features or functions as part of a specific component or module for clarity and to aid understanding, or as occurring at a specific layer of a computing device (e.g., a hardware layer, an operating system layer, or an application layer), these features or functions may be implemented as part of different components or modules, or operate at different layers of a communication protocol stack. One of ordinary skill in the art will recognize that the systems, devices, apparatus, and methods described herein may be applied to or readily modified for use with other types of equipment, may use other arrangements of computing systems such as client-server distributed systems, and may use other protocols, or operate at other layers in a communication protocol stack than described.

[0034] For simplicity, the following description will be provided with reference to a "payment instrument", which generally refers to any type of financial substitute for money. As will be clear to those skilled in the art, no aspect of the present disclosure is specifically limited to a particular type of payment instrument. Therefore, the following description is intended to cover the use of the present disclosure with many other forms of financial substitutes for money, including credit cards, debit cards, smart cards, single-purpose cards, prepaid cards, electronic money (such as can be provided by a cellular phone or a personal digital assistant), etc. The payment instrument can be a traditional plastic transaction card, a titanium-containing transaction card or other metal-containing transaction card, a transparent and / or translucent transaction card, a foldable or otherwise unconventionally sized transaction card, a radio frequency enabled transaction card or other type of transaction card, such as a credit card, a charge card, a debit card, a prepaid card or a stored value card or any other similar financial transaction facility. The payment instrument can also have electronic functionality provided by a network of electronic circuits that are printed or otherwise incorporated into or within the payment instrument (and commonly referred to as a "smart card"), or a smart key (fob) with a transponder and an RFID reader.

[0035] As discussed above, tokenization of sensitive data may be of particular interest for financial transactions such as electronic payment transactions. Figure 1 1 is a schematic representation of an exemplary payment system 100 that employs tokenization of sensitive data, such as may be provided by one or more embodiments. The payment system 100 may include a digital wallet host 120, a merchant 140, and an acquirer processor 160. The digital wallet host 120 may include a digital wallet server 122 that hosts / stores digital wallets (not shown) for a plurality of consumers. Each digital wallet may be associated with a consumer and include login credentials and financial account information for at least one personal financial account of the consumer. The digital wallet server 122 may enable content to be sent to / from the digital wallet host 120 in any number of formats, such as html messages, text-based messages, multimedia messages, email messages, smart phone notifications, web pages, etc. The digital wallet server 122 may include a processor (e.g., a CPU), a memory unit (e.g., RAM, ROM), a non-volatile storage system (e.g., a hard drive system), etc. For example, the digital wallet server 122 may utilize an operating system, such as a Solaris, Linux, or Windows server operating system.

[0036] The merchant 140 may include a merchant server 142 that facilitates presenting a merchant payment interface 144 to a consumer to facilitate the consumer initiating a purchase transaction at the merchant 140. For example, the merchant payment interface 144 may be presented to the consumer as a graphical user interface on any of a variety of computing devices, such as a mobile device, a kiosk point, or a personal computer. The merchant payment interface 144 may display a digital wallet interface 146 linked to the digital wallet host 120. When the consumer selects the digital wallet interface 146 (e.g., by selecting a button displayed on the merchant payment interface 144), a purchase request 174 may be transmitted to the digital wallet server 122. In response, the digital wallet host 120 may present a request for login credentials to the consumer directly on the merchant payment interface 144 or by redirecting the consumer to a login page hosted by the digital wallet host 120. The digital wallet host 120 may request any of a variety of login credentials, such as, for example, a username and password for the consumer's digital wallet account, biometric data (e.g., fingerprint), etc. When the consumer submits the correct login credentials to the digital wallet host 120 and completes the purchase transaction (e.g., by selecting a "place order" button), the digital wallet host 120 may transmit the encrypted payment payload 176 to the acquirer processor 160 via server-to-server integration. The encrypted payment payload 176 may include identification information of the consumer's payment instrument, such as a BIN number, expiration date, and the first and last name of the account holder. For example, the encrypted payment payload 176 may also include identification information from the purchase, such as an amount and identification information from the merchant 140. For example, the encrypted payment payload 176 may also include encrypted data, such as a network token and ciphertext.

[0037] The encrypted payment payload 176 may be sent to the acquirer processor server 162 of the acquirer processor 160. In response, the acquirer processor server 162 may generate a low-value token 172 and transmit the low-value token 172 to the merchant server 142 via the digital wallet server 122. In one embodiment, the digital wallet server 122 and the acquirer processor server 162 may be backend integrated to facilitate efficient and consistent communication between the servers. The low-value token 172 may be a temporary (limited life) randomized value without consumer financial data (e.g., credit card number, expiration date, or CCV). In one or more embodiments, the acquirer processor server 162 may include a token generator 168 that may generate the low-value token 172 by appropriate cryptographic means. The generation of the low-value token 172 may utilize the token table 164. De-tokenization of the low-value token 172 to retrieve the tokenized consumer financial data may also be performed by the token generator 168, possibly by employing the reverse token table 166. The tokenization of consumer financial data to produce low-value tokens 172 will be discussed in more detail below.

[0038] Once the consumer completes the purchase event, the merchant server 142 can submit an authorization request 182 including the low-value token 172 to the acquirer processor server 162. The acquirer processor server 162 can then decrypt the encrypted payment payload 176 to reveal the consumer's consumer data. The acquirer processor server 162 can then transmit an authorization request 186 for the purchase transaction to the payment network 150, which helps to process the payment of the purchase transaction. For example, the authorization request 186 can include identification information of the consumer's payment instrument, such as a BIN number, an expiration date, and the first and last name of the account holder. For example, the authorization request 186 can also include identification information from the purchase, such as an amount and identification information from the merchant 140. The payment network 150 can be, for example, a network of credit card associations associated with consumer PCI DSS data. Non-limiting examples of credit card associations include VISA, MASTERCARD, DISCOVER, and AMERICAN EXPRESS. Using information from the authorization request 186, an issuer financial institution (not shown) can associate the purchase transaction with an account of the consumer held by the issuer financial institution. The issuing financial institution may then facilitate the transmission of the authorization response 188 from the payment network 150 to the acquirer processor server 162. Upon receiving the authorization response 188, the acquirer processor server 162 may de-tokenize the low-value token 172 received from the merchant server 142, and may convert the de-tokenized low-value token into a high-value token. The high-value token and the authorization response 184 (indicating the authorization response from the payment network 150) may be transmitted to the merchant server 142. The authorization response 184 may be an approval message or a rejection message, either of which may complete the purchase transaction. If the purchase transaction is approved, it may be credited to the consumer's account and later reconciled with the digital wallet host 120.

[0039] The high-value token can be a randomized unique value that does not have the financial data of the consumer subject to PCI DSS (e.g., PCI DSS data), but is used as a substitute for the consumer's financial data. The high-value token can be stored at each of the merchant server 142 and the acquirer processor server 162, so that the same high-value token can be used for other purchase transactions of the consumer until the consumer's financial data changes, such as, for example, when the issuing financial institution issues a different payment instrument, thereby changing the consumer financial data that creates the high-value token. When the consumer's financial data changes, a new high-value token can be generated and used for subsequent transactions. The high-value token can be stored at the merchant server 142 instead of the consumer's financial data, so that the merchant 140 does not interact with the consumer's PCI DSS data, thereby reducing the compliance burden of the merchant 140.

[0040] Merchant server 142 may enable content to be sent to / from merchant 140 in any number of formats that facilitate completing a purchase transaction (such as html messages, text-based messages, multimedia messages, email messages, smartphone notifications, web pages, etc.). Merchant server 142 may include a processor (e.g., CPU), a memory unit (e.g., RAM, ROM), a non-volatile storage system (e.g., a hard drive system), etc. For example, merchant server 142 may also utilize an operating system such as Solaris, Linux, or Windows server operating systems. It should be understood that although merchant server 142 is Figure 1 142 is shown as a single server, but the merchant server 142 may include multiple servers. For example, the merchant server 142 may include a network server for hosting a merchant payment interface and a financial transaction server that communicates with a digital wallet server to exchange transaction-related data.

[0041] It should be understood that there may be multiple different digital wallet hosts (e.g., 120) on the payment system 100, each of which requires different standards and rule sets to process its specific encrypted payment payload (e.g., 176). The acquirer processor server 162 can be configured to process each different encrypted payment payload (e.g., 176) of the digital wallet host (e.g., 120) according to the appropriate standards and rule sets proposed by each digital wallet host (e.g., 120), which can result in a unified mechanism for processing different payment methods for merchants, thereby alleviating the burdens commonly experienced in digital wallet-based transactions in conventional payment networks. For example, in conventional payment networks, when a digital wallet-based transaction is initiated, the encrypted payment payload (e.g., 176) is sent to the merchant (e.g., 140), and then the merchant (e.g., 140) must determine and apply the appropriate standards and rule sets to the encrypted payment payload (e.g., 176) to complete the purchase transaction. This may be time consuming and expensive to implement, and may result in the merchant (e.g., 140) refusing to accept payments from some, if not all, digital wallet platforms. In addition, by receiving and processing the encrypted payment payload (e.g., 176), the merchant (e.g., 140) may be exposed to the consumer PCI DSS data, which may be expensive and time consuming to properly protect (i.e., in accordance with PCI DSS guidelines).

[0042] References in the above Figure 1In the described embodiments, tokenization and de-tokenization of sensitive payment information may be performed entirely within an acquirer processor server, such as the acquirer processor server of acquirer processor 160. However, the stateless nature of embodiments of the present invention may allow token tables to be distributed across multiple systems so that compatible tokenization and de-tokenization may be performed by multiple entities, such as, for example, acquirer processors, merchants, and payment providers. Figure 2 Such an exemplary distributed system infrastructure for protecting data through stateless tokenization according to one or more embodiments is depicted. Figure 2 As shown, the tokenization service can be distributed across multiple regions 205 (such as "Region A" 205a, "Region B" 205b, and "Region C" 205c). Each region 205 may include a tokenization service 210, a token table utility 215, and a token table file 220. Each region 205 can provide tokenization services locally within a server operating in the region, such as providing tokenization services to an application 235 instantiated from an application database 230, or can provide tokenization services to external requesters. Alternatively, a region such as "Region C" 205c can be designated as a "failover" service provider, so that if the tokenization service is unavailable from a "primary" tokenization service provider (such as "Region A" 205a or "Region B" 205b), the tokenization service can be seamlessly provided by the "failover" service provider. The applications 235 provided in each area 205 may be the same, such as applications A and B provided as applications 235 in "area A" 205a and "area C" 205c, or may be different in different areas, such as applications A and B provided as applications 235 in "area A" 205a, and applications C and D provided as applications 235 in "area B" 205b.

[0043] Token table (such as Figure 2The token table 225 shown) can be characterized by its entry length n and alphabet base b. For example, 6 digits (base 10) or 3 character alphanumerics (base 62), etc. The number of digits / characters n can determine the minimum plaintext / token length. There may be no theoretical maximum plaintext / token length. The base b can determine the plaintext / token data type. Then, the token table 225 can be, for example, an array of bn random numbers ranging from 0 to bn-1. Each number is unique in the array, randomly assigned to its array index and different from its index. In order to ensure the security and correct operation of the tokenization process, the random number can be generated by cryptographic means, such as by a cryptographically secure counter mode deterministic random bit generator (CTR_DRBG). Such CTR_DRBG can be encrypted using, for example, the Advanced Encryption Standard (AES), such as AES-256 in counter mode with a 384-bit seed. The seed can be derived by any cryptographically secure means, such as, for example, derived from the current time, code / local variables / dynamically allocated memory addresses and / or CPU timing. Reverse tokenization table for retrieving the original plaintext from the tokenized value (in Figure 2 225) can be generated as a reverse copy of the token table 225. To ensure compatibility, and to provide for de-tokenization, a unique acquisition table for each combination of entry length n and alphabet base b can be maintained. A method for optionally associating a generated tokenized string with the token table used to generate it is described below.

[0044] It should be understood that the security of tokenization can increase with the increase of entry length n and alphabet base b. Such security benefits can be achieved at least due to the increase of the size of the token table, which may increase the difficulty of determining the tokenized entries by force or by analytical means. For example, for an entry length of 3 digits (base 10), the resulting token table will have 1,000 entries. For an entry length of 6 digits (base 10), the resulting token table will have 1,000,000 entries. For an entry length of 6 alphanumeric (base 62), the resulting token table will have 56,800,235,584 entries. The Payment Card Industry (PCI) Data Security Standard requires that the primary account number (PAN) be protected by keeping at most the first 6 and last 4 digits as plain text, and the remaining PAN numbers must be shielded, encrypted or tokenized. The most common range of PAN is 16 to 19 digits, but PAN can be made to have up to 28 digits. Therefore, the middle 6 digits of a 16-digit PAN can be tokenized using a static token table of 1 million entries.

[0045] If the token table 225 is to be written to disk, such as the token table file 220, additional measures may be taken to ensure security. For example, a hash of the contents of the token table 225 may be appended to the token table 225. For example, a secure hash algorithm (SHA) hash may be used, such as a SHA-512 hash. The combined token table 225 may then be encrypted by any suitable encryption method, such as, for example, AES-256 with cipher block chaining (AES-256-CBC). The encrypted combined token table 225 may then be encoded, such as by base 64 encoding, and written to a disk file (such as the token table file 220). The table file encryption key may be derived by selecting 32 random bytes from an array of 10,000 random bytes stored in a key file. A 16-byte random initialization vector is also derived. The key file is generated by CTR_DRBG for the table. The key derivation algorithm is encoded in a separate module to allow only object unsigned distributions. Alternatively, the token table file encryption key may be maintained by a hardware host security module.

[0046] The encryption key for the token table file 220 can be derived by, for example, selecting 32 random bytes from an array of 10,000 random bytes stored in the key file. A 16-byte random initialization vector can also be derived. For example, the key file can be generated by CTR_DRBG, which is used to generate random numbers for the token table 225. The algorithm for key derivation can be deployed in a separate module to allow only object unsigned distribution. Alternatively, the token table file encryption key can be maintained by a hardware host security module.

[0047] The token table utility 215 may provide utility services related to, for example, generating a token table from a token table file, generating a token table file, validating tokenized values, validating, encrypting, re-encrypting, exporting and importing token tables and token table files, etc. For example, the token table file 220 may be exported to another region under a transport encryption key and then may be re-encrypted under a local key of the new region.

[0048] To be used in the new zone, the token table file 220 can be read, decoded, decrypted and SHA verified. Two memory tables can then be created: the token table 225 for tokenization operations and the inverted reverse token table (in Figure 2 Token table 225 and reverse token table may be obfuscated with random numbers which provides additional protection.

[0049] According to Figure 3A-3E One or more embodiments are depicted, and the internal structures of the token table file 220, the token table 225, and the reverse token table are discussed in more detail below in conjunction with an exemplary process flow for protecting data through stateless tokenization.

[0050] According to one or more embodiments, a stateless tokenization method for protecting data may treat two input strings as input: context and plaintext. The method may generate a tokenized string. For example, a portion of a 16-digit financial account number "1234-5612-3456-7812" may be tokenized to provide security for the account number. For example, the middle 8-digit number "xxxx-xx12-3456-78xx" may be tokenized, with the remaining 8-digit number "1234-56xx-xxxx-xx12" serving as the context for tokenization.

[0051] During tokenization, the random number can be used as a table offset to ensure that different tokens are generated for the same plaintext in different contexts. For example, a SHA-256 hash can be calculated in context. The first 6 bytes of the hash can then be used as an index into the token table 225 to retrieve a non-zero n-bit random number. This number can then be used as a table offset during the remainder of the tokenization process.

[0052] In short, given a string of plaintext digits / characters, tokenization can start from the right end, reach the left end, and return to the right end. However, alternatively, the process can start from the left end of the plaintext and initially move right through the plaintext. The process can use a sliding n-bit window. At each step, the currently selected n-digit number can be replaced with a token table value from the token table 225 at an index equal to the selected n-digit number plus the offset. Then, the window can slide a number. Any non-alphabet plaintext characters can be skipped and retained in the output token. Plaintext strings with a length less than n digits / characters may not be tokenized and may be copied directly to the output. The algorithm is conflict-free because the index random number pair is a series of bijections. The reverse operation can use a reverse copy of the token table 225, the same context logic, and the same search, replacement, and shift steps.

[0053] Figure 3A Depicted is a portion of an exemplary token table 225 employed in a method of protecting data through stateless tokenization according to one or more embodiments. Figure 3A As shown, the token table 225 may include a random value 320 at each index 315. For example, in the exemplary token table 225, at index 211111 is the random value 222222. Figure 3A Not shown in , but for a given entry length n and alphabet base b, a random value may be provided at each index from 0 to bn-1.

[0054] Figure 3BAn exemplary process flow 330 for protecting data through stateless tokenization according to one or more embodiments is depicted. This example uses a 6-bit window, but for ease of explanation, no offset is used. Figure 3B As shown, at operation 332, the process may select a 6-bit window at the right end of the plaintext. At operation 334, the process may use the value "345678" of the 6-bit window as an index in the token table 225, retrieve the random number "111111" at the index, and replace the value of the 6-bit window with the retrieved random number. At operation 336, the process may shift the 6-bit window one position to the left. At operation 338, the process may use the value "211111" of the 6-bit window as an index in the token table 225, retrieve the random number "222222" at the index, and replace the value of the 6-bit window with the retrieved random number. At operation 340, the process may shift the 6-bit window one position to the left. At operation 342, the process may use the value "122222" of the 6-bit window as an index in the token table 225, retrieve the random number "333333" at the index, and replace the value of the 6-bit window with the retrieved random number.

[0055] At this point, the process has reached the left end of the plaintext and can continue similarly while shifting the 6-bit window from left to right.

[0056] At operation 344, the process may use the 6-bit window value "333333" as an index in the token table 225, retrieve the random number "444444" at the index, and replace the value of the 6-bit window with the retrieved random number. At operation 346, the process may shift the 6-bit window one position to the right. At operation 348, the process may use the 6-bit window value "444442" as an index in the token table 225, retrieve the random number "555555" at the index, and replace the value of the 6-bit window with the retrieved random number. At operation 350, the process may shift the 6-bit window one position to the right. At operation 352, the process may use the 6-bit window value "555551" as an index in the token table 225, retrieve the random number "666666" at the index, and replace the value of the 6-bit window with the retrieved random number.

[0057] At this point, the process has reached the right end of the plaintext and is complete, producing the tokenized value "45666666".

[0058] Figure 3D An exemplary reverse token table 395 is depicted for use in retrieving plaintext from a tokenized value in a method of protecting data through stateless tokenization according to one or more embodiments. Figure 3DAs shown, for a given entry length n and alphabet base b, the reverse token table 395 may include a random value 320 from 0 to bn-1 at each index 315. Figure 3A and Figure 3D As shown, the index-random number pair in the reverse token table 395 can be the inverse of the index-random number pair in the token table 225. For example, in the example, the reverse token table 395 at index 222222 can be the random number value 211111.

[0059] Figure 3C Depicted is an exemplary process flow for retrieving plaintext from a tokenized value in a method for protecting data through stateless tokenization according to one or more embodiments. This example uses a 6-bit window, but for ease of explanation, no offset is used.

[0060] like Figure 3C As shown, at operation 362, the process can select a 6-bit window at the right end of the plaintext. At operation 364, the process can use the value "666666" of the 6-bit window as an index in the reverse token table 395, retrieve the random number "555551" at the index, and replace the value of the 6-bit window with the retrieved random number. At operation 366, the process can shift the 6-bit window to the left by one position. At operation 368, the process can use the value "555555" of the 6-bit window as an index in the reverse token table 395, retrieve the random number "444442" at the index, and replace the value of the 6-bit window with the retrieved random number. At operation 370, the process can shift the 6-bit window to the left by one position. At operation 372, the process can use the value "444444" of the 6-bit window as an index in the reverse token table 395, retrieve the random number "333333" at the index, and replace the value of the 6-bit window with the retrieved random number.

[0061] At this point, the process has reached the left end of the plaintext and can continue similarly while shifting the 6-bit window from left to right.

[0062] At operation 374, the process may use the value of the 6-bit window "333333" as an index in the reverse token table 395, retrieve the random number "1222222" at the index, and replace the value of the 6-bit window with the retrieved random number. At operation 376, the process may shift the 6-bit window one position to the right. At operation 378, the process may use the value of the 6-bit window "222222" as an index in the reverse token table 395, retrieve the random number "211111" at the index, and replace the value of the 6-bit window with the retrieved random number. At operation 380, the process may shift the 6-bit window one position to the right. At operation 382, ​​the process may use the value of the 6-bit window "111111" as an index in the reverse token table 395, retrieve the random number "345678" at the index, and replace the value of the 6-bit window with the retrieved random number.

[0063] At this point, the process has reached the right end of the tokenized value and is complete, producing the original plaintext value "12345678".

[0064] Figure 3E An exemplary token table file 220 stored on disk and employed in a method of protecting data through stateless tokenization is depicted in accordance with one or more embodiments. Figure 3E As shown, the token table file 220 may include the contents of the token table 225, including the random value 320 at each index 315. The token table file 220 may further include a hash 392 of the contents of the token table 225. The token table 225 and the hash 392 may be encrypted. The encrypted data may be encoded.

[0065] Figure 4 A flow chart of a method for protecting data through stateless tokenization according to one or more embodiments is depicted. Figure 4As shown, at operation 402, the tokenization service may receive an input string for tokenization. At operation 404, the tokenization service may select a portion of the input string as plaintext for tokenization, and at operation 406, the tokenization service may select the remaining portion of the input string as context. The context may be extended by additional strings (such as system IDs, institution / customer IDs, or other groups or global values). At operation 408, the tokenization service may calculate a hash of the context. At operation 410, the tokenization service may use a portion of the hash as a table offset for subsequent table lookup operations. At operation 412, the tokenization service may select an N-character window at one end of the plaintext as a starting point for tokenization. In the following description, the right end of the plaintext is used as a starting point, and the process initially moves left through the plaintext. However, alternatively, the process may start from the left end of the plaintext and initially move right through the plaintext. In operation 414, the tokenization service may access the token table at an index equal to the value of the character window plus the table offset. In operation 416, the tokenization service may retrieve a value in the token table at the index. In operation 418, the tokenization service may replace the value of the character window with the retrieved value from the token table.

[0066] In operation 420, the tokenization service may determine whether the process has reached the left end of the plaintext. If the process has reached the left end of the plaintext, then in operation 422, the tokenization service may continue to operation 426. If the process has not reached the left end of the plaintext, then in operation 422, the tokenization service may shift the window to the left by one character within the plaintext, and in operation 424, the tokenization service may return to operation 414.

[0067] In operation 426, the tokenization service may access the token table at an index equal to the value of the character window plus the table offset. In operation 428, the tokenization service may retrieve the value in the token table at the index. In operation 430, the tokenization service may replace the value of the character window with the retrieved value from the token table.

[0068] In operation 435, the tokenization service may determine whether the process has reached the right end of the plaintext. If the process has reached the right end of the plaintext, the tokenization service may continue to operation 450. If the process has not reached the right end of the plaintext, in operation 440, the tokenization service may shift the window to the right by one character, and in operation 445, the tokenization service may return to operation 426.

[0069] In operation 450, the process can end and the tokenization service can return the tokenized string. Alternatively, Figure 4The method can be applied to the tokenized string, using the same token file or another token file to tokenize the tokenized string to provide even higher security. The same process can be repeated again on the resulting tokenized string, and so on.

[0070] In addition to the tokenization provided by the methods discussed above, additional metadata may be encoded into the tokenized value. Such metadata encoding may preserve the length of the plaintext and the tokenized value, and may, for example, provide an indication that the string is a token compared to the plaintext, identify the token table used to generate the token. Such identifiers may facilitate rotation of token tables.

[0071] Using the techniques discussed above, it is not necessary to rotate or change the token table, but the application may optionally choose to do so. Two or more tables (such as, for example, table a and table b) may be sufficient to implement a token table rotation scheme. However, the example discussed below provides an encoding sufficient to support up to 7 token tables used in rotation. In the example discussed below, the metadata is encoded in the last 3 digits of the tokenized value to reserve the first digit for file partitioning (sharding), which will be discussed in more detail below.

[0072] Examples of metadata encodings for decimal and alphanumeric tokenization are provided.

[0073] For decimal token metadata encoding, a token table ID (such as, for example, a, b, c, d, e, f, or g) can be encoded in the last three digits of the token by converting the last three digits of the tokenized value from a decimal (base 10) number to a two-digit base 62 number and replacing the last three digits of the token with an alphabetic token table ID followed by a two-digit base 64 number. This encoding preserves the token length and expands the token alphabet to be alphanumeric. For example, for a token value of "587315907", a token with metadata could be "587315aeD", where "907" in base 10 is replaced by "eD" base 62, and "a" is the token table ID.

[0074] For alphanumeric token metadata encoding, a token table ID (such as, for example, a, b, c, d, e, f, or g) can be represented as 1-7 in binary (000, 001, 010, ... 111) and encoded in the last three bytes of the token by adding 128 to the byte to represent the binary digit 1. This encoding can maintain the token length and can expand the token alphabet to binary. For example, for a token value of "iQttOS9VZEwByTvRbZC", the token table ID 'b' can be represented as 2 in decimal or 010 in binary. The last three characters of the token are "bZC". For adding metadata to the token value, "b", ASCII code 98, can remain unchanged, encoding the first binary digit 0 (the fact that it is less than 128 tells us that it represents binary 0). The next character "Z" has an ASCII code of 90. To encode the second binary digit 1, 128 can be added to 90, resulting in 218, which is "DA" in hexadecimal and fits into a byte. The last character "C" may remain unchanged, encoding the third binary digit 0. The resulting token with metadata may then be "iQttOS9VZEwByTvRb[0xDA]C", where [0xDA] represents 218 (which is not a printable character).

[0075] Tokenized values ​​such as those provided by one or more embodiments may be employed to efficiently partition large data across multiple storage locations (such as physical disks, regions, etc.). For example, a file or database table may need to be partitioned across multiple physical disks. Such partitions are also referred to as shards. Partitioning may allow applications to scale horizontally and may improve application performance by accessing multiple disks in parallel. However, a practical problem is how to evenly distribute records across all partitions. For example, consider a large database with primary account numbers (PANs) (i.e., debit / credit cards) as the primary keys for files. PANs may not be evenly distributed, and partitions may become unbalanced as new PANs are created and added to files, which may cause disk space and performance issues. Tokenization of PANs using one or more embodiments discussed above may allow for efficient balancing of the database because PAN tokens are uniformly distributed random numbers. For example, partition 1 may include all records with primary keys starting with "000" and less than "333", partition 2 may include all records with primary keys starting with "333" and less than "666", and partition 3 may include all records with primary keys starting with "666" and above. Due to the random number properties of the tokenized PAN value, newly added PANs and records will be evenly distributed across the partitions.

[0076] By using the techniques discussed above, plaintext to be tokenized can be replaced with cryptographically secure tokenized text by using a static token table of limited size. A static token table can avoid the use of an ever-growing token database. While preserving the format and length of the plaintext, the resulting tokenized text may be indistinguishable from a random permutation, such as by preserving non-alphabet characters in the tokenized value. The process can allow for context so that the tokenized value can depend on the plaintext context associated with the tokenized text. Both numeric and alphanumeric tokenization can be supported. The process can provide collision-free tokenization in a horizontally scalable distributed and portable implementation. The process can provide fast in-memory tokenization and de-tokenization operations without disk I / O. The process can protect token tables in memory and dump files and allow for implementations that are resistant to debugging attacks.

[0077] The static token table file on disk can be encrypted using secure software and periodically re-encrypted, allowing export of the static token table to other servers / zones to be provided under a one-time use export key.

[0078] Unless otherwise specifically noted, as will be apparent from the following discussion, it should be understood that throughout the specification discussion, terms such as "processing," "computing," "calculating," "determining," "analyzing," and the like are used to refer to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulates and / or converts data represented as physical quantities (such as electronic quantities) into other data similarly represented as physical quantities.

[0079] In a similar manner, the term "processor" may refer to any device or portion of a device that processes electronic data (e.g., electronic data from registers and / or memory) to transform the electronic data into other electronic data that may be stored, for example, in registers and / or memory. A "computer," "computing machine," "computing platform," "computing device," or "server" may include one or more processors.

[0080] Figure 5 A specific implementation of a general purpose computer system designated as 500 is shown. Computer system 500 may include a set of instructions that may be executed to cause computer system 500 to perform any one or more of the methods or computer-based functions disclosed herein. Computer system 500 may operate as a standalone device or may be connected to other computer systems or peripheral devices, for example using a network.

[0081] In a networked deployment, the computer system 500 can operate as a server, or operate as a client user computer in a server-client user network environment, or operate as a peer-to-peer computer system in a peer-to-peer (or distributed) network environment. The computer system 500 can also be implemented as various devices or incorporated into various devices, such as a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communication device, a wireless phone, a landline phone, a control system, a camera, a scanner, a fax machine, a printer, a pager, a personal trusted device, a web device, a network router, a switch or a bridge, or any other machine that can execute a set of instructions (sequential or otherwise) specifying the action to be taken by the machine. In a specific implementation, the computer system 500 can be implemented using an electronic device that provides voice, video or data communication. In addition, although a single computer system 500 is shown, the term "system" should also be understood to include any set of systems or subsystems that execute one or more sets of instructions to perform one or more computer functions individually or jointly.

[0082] like Figure 5 As shown, computer system 500 may include a processor 502, such as a central processing unit (CPU), a graphics processing unit (GPU), or both. Processor 502 may be a component in a variety of systems. For example, processor 502 may be part of a standard personal computer or workstation. Processor 502 may be one or more general-purpose processors, digital signal processors, application-specific integrated circuits, field programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other devices now known or later developed for analyzing and processing data. Processor 502 may implement a software program, such as manually generated (i.e., programmed) code.

[0083] The computer system 500 may include a memory 504 that can communicate via a bus 508. The memory 504 may be a main memory, a static memory, or a dynamic memory. The memory 504 may include, but is not limited to, computer-readable storage media, such as various types of volatile storage media and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, tape or disk, optical media, etc. In one specific implementation, the memory 504 includes a cache or random access memory for the processor 502. In an alternative specific implementation, the memory 504 is separated from the processor 502, such as a cache memory, system memory, or other memory of the processor. The memory 504 may be an external storage device or database for storing data. Examples include a hard drive, a compact disk ("CD"), a digital video disk ("DVD"), a memory card, a memory stick, a floppy disk, a universal serial bus ("USB") storage device, or any other device operable to store data. The memory 504 is operable to store instructions that can be executed by the processor 502. The functions, actions, or tasks shown in the figures or described herein may be performed by a programmed processor 502 executing instructions stored in the memory 504. The functions, actions, or tasks are independent of the specific type of instruction set, storage medium, processor, or processing strategy, and may be performed by software, hardware, integrated circuits, firmware, microcode, etc. operating alone or in combination. Likewise, processing strategies may include multi-processing, multi-tasking, parallel processing, etc.

[0084] As shown, the computer system 500 may further include a display unit 510, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid state display, a cathode ray tube (CRT), a projector, a printer, or other display devices now known or later developed, for outputting determined information. The display 510 may serve as an interface for a user to view the functions of the processor 502, or specifically serve as an interface with software stored in the memory 504 or the drive unit 506.

[0085] Additionally or alternatively, the computer system 500 may include an input device 512 configured to allow a user to interact with any component of the system 500. The input device 512 may be a numeric keypad, a keyboard, or a cursor control device such as a mouse or joystick, a touch screen display, a remote control, or any other device operable to interact with the computer system 500.

[0086] The computer system 500 may also or alternatively include a disk drive unit or an optical drive unit 506. The disk drive unit 506 may include a computer-readable medium 522 in which one or more sets of instructions 524, such as software, may be embedded. In addition, the instructions 524 may embody one or more methods or logic as described herein. During execution by the computer system 500, the instructions 524 may reside completely or partially within the memory 504 and / or the processor 502. The memory 504 and the processor 502 may also include computer-readable media as discussed above.

[0087] In some systems, the computer-readable medium 522 includes instructions 524, or receives and executes instructions 524 in response to a propagated signal, so that a device connected to the network 570 can transmit voice, video, audio, image, or any other data through the network 570. In addition, instructions 524 can be transmitted or received through the network 570 via a communication port or interface 520 and / or using a bus 508. The communication port or interface 520 can be part of the processor 502, or it can be a separate component. The communication port 520 can be created in software, or it can be a physical connection in hardware. The communication port 520 can be configured to connect to the network 570, external media, display 510, or any other component or combination thereof in the system 500. The connection to the network 570 can be a physical connection, such as a wired Ethernet connection, or it can be wirelessly established as discussed below. Similarly, additional connections to other components of the system 500 can be physical connections or can be wirelessly established. Alternatively, the network 570 can be directly connected to the bus 508.

[0088] Although the computer-readable medium 522 is shown as a single medium, the term "computer-readable medium" may include a single medium or multiple media, such as a centralized database or a distributed database, and / or associated caches and servers storing one or more sets of instructions. The term "computer-readable medium" may also include any medium capable of storing, encoding, or carrying a set of instructions executed by a processor or causing a computer system to perform any one or more of the methods or operations disclosed herein. The computer-readable medium 522 may be non-transitory and may be tangible.

[0089] Computer readable medium 522 may include solid state memory, such as a memory card or other packaging that holds one or more non-volatile read-only memories. Computer readable medium 522 may be a random access memory or other volatile rewritable memory. Additionally or alternatively, computer readable medium 522 may include magnetic-optical media or optical media, such as a disk or tape or other storage device, to capture carrier signals, such as signals transmitted by a transmission medium. The digital file attachments of e-mails or other self-contained information archives or archives may be considered as distribution media of tangible storage media. Therefore, the present disclosure is considered to include any one or more of computer readable media or distribution media and other equivalents and subsequent media in which data or instructions may be stored.

[0090] In alternative implementations, dedicated hardware implementations may be constructed, such as application specific integrated circuits, programmable logic arrays, and other hardware devices, to implement one or more of the methods described herein. Applications that may include various implementations of the apparatus and systems may broadly include various electronic systems and computer systems. One or more implementations described herein may implement functions using two or more specific interconnected hardware modules or devices that have associated control and data signals that can communicate between and through the modules, or as part of an application specific integrated circuit. Therefore, the system of the present invention encompasses software, firmware, and hardware implementations.

[0091] Computer system 500 can be connected to one or more networks 570. Network 570 can define one or more networks, including wired networks or wireless networks. The wireless network can be a cellular telephone network, 802.11, 802.16, 802.20 or WiMAX network. In addition, such networks can include public networks such as the Internet, private networks such as intranets, or combinations thereof, and can utilize various network protocols that are available now or developed later, including but not limited to TCP / IP-based network protocols. Network 570 can include a wide area network (WAN), such as the Internet, a local area network (LAN), a campus network, a metropolitan area network, a direct connection such as through a universal serial bus (USB) port, or any other network that can allow data communication. Network 570 can be configured to connect one computing device to another computing device to enable communication of data between devices. Network 570 is generally capable of using any form of machine-readable media to transfer information from one device to another. Network 570 can include a communication method by which information can be propagated between computing devices. Network 570 can be divided into subnetworks. A subnetwork may allow access to all other components connected thereto, or a subnetwork may restrict access between components. Network 570 may be considered a public network connection or a private network connection, and may include, for example, a virtual private network or encryption or other security mechanisms employed on the public Internet.

[0092] According to various specific implementations of the present disclosure, the methods described herein can be implemented by a software program executable by a computer system. In addition, in an exemplary non-limiting specific implementation, the specific implementation can include distributed processing, component / object distributed processing, and parallel processing. Alternatively, a virtual computer system process can be configured to implement one or more methods or functions as described herein.

[0093] Although this specification describes components and functions that can be implemented in a specific implementation with reference to specific standards and protocols, the present disclosure is not limited to such standards and protocols. For example, standards for Internet and other packet-switched network transmissions (e.g., TCP / IP, UDP / IP, HTML, HTTP) represent examples of the prior art. Such standards are periodically replaced by faster or more efficient equivalents having substantially the same functions. Therefore, alternative standards and protocols having the same or similar functions as those disclosed herein are considered to be their equivalents.

[0094] It should be understood that in one embodiment, the steps of the method discussed are performed by an appropriate processor of a processing (i.e., computer) system executing instructions (computer readable code) stored in a memory. It should also be understood that the present invention is not limited to any particular implementation or programming technique, and that the present invention can be implemented using any appropriate technique for implementing the functions described herein. The present invention is not limited to any particular programming language or operating system.

[0095] It should be understood that in the above description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of simplifying the present disclosure and facilitating understanding of one or more of the various aspects of the present invention. This method of disclosure should not be interpreted as reflecting that the claimed embodiments require the use of more features than those explicitly described in each claim. On the contrary, as reflected in the appended claims, aspects of the present invention are less than all features of a single aforementioned disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into the detailed description, with each claim existing independently as a separate embodiment of the present disclosure.

[0096] In addition, although some embodiments described herein include some but not other features in other embodiments, the combination of features of different embodiments is intended to be within the scope of the present invention and form different embodiments, as understood by those skilled in the art. For example, in the appended claims, any claimed embodiment can be used in any combination.

[0097] In addition, some embodiments are described herein as methods or combinations of elements of methods that can be implemented by a processor of a computer system or by other means for performing the function. Therefore, a processor with necessary instructions for performing such methods or elements of a method forms a device for performing the method or elements of a method. In addition, the elements of the device embodiments described herein are examples of devices for performing the functions performed by the elements for achieving the purposes of the present disclosure.

[0098] In the description provided herein, many specific details are set forth. However, it should be understood that embodiments of the present disclosure may be implemented without these specific details. In other examples, well-known methods, structures, and techniques are also shown in detail in order not to obscure the understanding of this specification.

[0099] Similarly, it should be noted that the term "coupled" when used in the claims should not be interpreted as being limited to direct connections. The terms "coupled" and "connected", and their derivatives, may be used. It should be understood that these terms are not intended to be synonyms of each other. Therefore, the scope of stating that the device A is coupled to device B should not be limited to a device or system in which the output of device A is directly connected to the input of device B. This means that there is a path between the output of A and the input of B, which path may be a path including other devices or apparatuses. "Connected" may mean that two or more elements are in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but still operate or interact with each other.

[0100] Therefore, although what are considered to be preferred embodiments of the present invention have been described, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the present invention, and it is intended to claim all such changes and modifications as fall within the scope of the present invention. For example, any formula given above is merely representative of a program that may be used. Functions may be added or deleted from the block diagram, and operations may be interchanged between function blocks. Within the scope of the present invention, steps may be added or deleted to the described method.

[0101] The subject matter disclosed above should be considered illustrative, not restrictive, and the appended claims are intended to cover all such modifications, improvements, and other specific implementations, which fall within the true spirit and scope of the present disclosure. Therefore, to the maximum extent permitted by law, the scope of the present disclosure will be determined by the broadest permissible interpretation of the appended claims and their equivalents, and should not be restricted or limited by the foregoing detailed description. Although various specific implementations of the present disclosure have been described, it is obvious to those of ordinary skill in the art that more specific implementations and multiple specific implementations are possible within the scope of the present disclosure. Therefore, the present disclosure is not limited except according to the appended claims and their equivalents.

Claims

1. A computer-implemented method for protecting data by stateless tokenization, the method comprising: Receive string; selecting a character window at a starting point within the character string; accessing a token table at an index equal to the value of the character window; retrieving a first tokenized value corresponding to the value of the character window from the token table at the index; replacing said value of said window of characters within said string with a retrieved first tokenized value; shifting the character window within the character string by one character in a first direction; accessing the token table at an index equal to the value of the shifted character window; retrieving from the token table at the index a second tokenized value corresponding to the value of the shifted character window; replacing said value of said shifted window of characters within said string with a retrieved second tokenized value; shifting the shifted character window within the character string by one character in a second direction; accessing said token table at said index equal to said value of said shifted character window; retrieving from the token table at the index a third tokenized value corresponding to the value of the shifted character window; replacing said value of said shifted window of characters within said string with a retrieved third tokenized value; as well as Returns the string as a tokenized string. 2 . The computer-implemented method of claim 1 , wherein the first direction is leftward and the second direction is rightward.

3. The computer-implemented method of claim 1 , further comprising: selecting a portion of the string as plaintext for tokenization; as well as selects the remainder of the string as context, The starting point is within the plaintext. 4 . The computer-implemented method of claim 1 , wherein said shifting said character window within said string by one character in said first direction is repeated until said character window is at a stopping point within said string.

5. The computer-implemented method of claim 3, further comprising: computing a hash of the context; as well as select a portion of said hash as a table index to retrieve a random number as a table offset, Wherein when accessing the token table, the table offset is added to the index.

6. The computer-implemented method of claim 1, wherein the token table comprises bn random numbers ranging from 0 to bn-1, where n is the size of the character window and b is the size of an alphabet base b of the string.

7. The computer-implemented method of claim 1 , further comprising: receiving an encrypted payment payload in response to a transaction initiated by a consumer at a merchant, wherein the encrypted payment payload includes a primary account number (PAN) of a financial account of the consumer; Setting the value of the string to the PAN; transmitting the tokenized string to the merchant; receiving an authorization request for the transaction, the authorization request including the tokenized string; requesting authorization for the transaction from a financial institution that is an issuer of the financial account of the consumer; receiving an authorization decision for the transaction from the issuing financial institution; as well as An authorization response is transmitted to the merchant.

8. A system for protecting data by stateless tokenization, the system comprising: a data storage device storing in an electronic storage medium instructions for protecting data by stateless tokenization; and A processor configured to execute the instructions to perform a method, the method comprising: Receive string; selecting a character window at a starting point within the character string; accessing a token table at an index equal to the value of the character window; retrieving a first tokenized value corresponding to the value of the character window from the token table at the index; replacing said value of said window of characters within said string with a retrieved first tokenized value; shifting the character window within the character string by one character in a first direction; accessing the token table at an index equal to the value of the shifted character window; retrieving from the token table at the index a second tokenized value corresponding to the value of the shifted character window; replacing said value of said shifted window of characters within said string with a retrieved second tokenized value; shifting the shifted character window within the character string by one character in a second direction; accessing said token table at said index equal to said value of said shifted character window; retrieving from the token table at the index a third tokenized value corresponding to the value of the shifted character window; replacing the value of the shifted character window within the string with the retrieved third tokenized value; and Returns the string as a tokenized string.

9. The system of claim 8, wherein the first direction is leftward and the second direction is rightward.

10. The system of claim 8, wherein the system is further configured to: selecting a portion of the string as plaintext for tokenization; and selects the remainder of the string as context, The starting point is within the plaintext.

11. The system of claim 8, wherein said shifting said character window within said character string in said first direction by one character is repeated until said character window is at a stopping point within said character string.

12. The system of claim 10, wherein the system is further configured to: computing a hash of the context; and select a portion of said hash as a table index to retrieve a random number as a table offset, Wherein when accessing the token table, the table offset is added to the index.

13. The system of claim 8, wherein the token table comprises bn random numbers ranging from 0 to bn-1, where n is the size of the character window and b is the size of the alphabet base b of the string.

14. The system of claim 8, wherein the system is further configured to: receiving an encrypted payment payload in response to a transaction initiated by a consumer at a merchant, wherein the encrypted payment payload includes a primary account number (PAN) of a financial account of the consumer; Setting the value of the string to the PAN; transmitting the tokenized string to the merchant; receiving an authorization request for the transaction, the authorization request including the tokenized string; requesting authorization for the transaction from a financial institution that is an issuer of the financial account of the consumer; receiving an authorization decision for the transaction from the issuing financial institution; as well as An authorization response is transmitted to the merchant.

15. A non-transitory machine-readable medium storing instructions that, when executed by a computing system, cause the computing system to perform a method for protecting data through stateless tokenization, the method comprising: Receive string; selecting a character window at a starting point within the character string; accessing a token table at an index equal to the value of the character window; retrieving a first tokenized value corresponding to the value of the character window from the token table at the index; replacing said value of said window of characters within said string with said first retrieved tokenized value; shifting the character window within the character string by one character in a first direction; accessing the token table at an index equal to the value of the shifted character window; retrieving from the token table at the index a second tokenized value corresponding to the value of the shifted character window; replacing said value of said shifted window of characters within said string with a retrieved second tokenized value; shifting the shifted character window within the character string by one character in a second direction; accessing said token table at said index equal to said value of said shifted character window; retrieving from the token table at the index a third tokenized value corresponding to the value of the shifted character window; replacing said value of said shifted window of characters within said string with a retrieved third tokenized value; as well as Returns the string as a tokenized string.

16. The non-transitory machine-readable medium of claim 15, wherein the first direction is leftward and the second direction is rightward.

17. The non-transitory machine-readable medium of claim 15, the method further comprising: selecting a portion of the string as plaintext for tokenization; as well as selects the remainder of the string as context, The starting point is within the plaintext.

18. The non-transitory machine-readable medium of claim 15, wherein the shifting of the character window within the character string in the first direction by one character is repeated until the character window is at a stopping point within the character string.

19. The non-transitory machine-readable medium of claim 17, the method further comprising: computing a hash of the context; as well as select a portion of said hash as a table index to retrieve a random number as a table offset, Wherein when accessing the token table, the table offset is added to the index.

20. The non-transitory machine-readable medium of claim 15, the method further comprising: receiving an encrypted payment payload in response to a transaction initiated by a consumer at a merchant, wherein the encrypted payment payload includes a primary account number (PAN) of a financial account of the consumer; Setting the value of the string to the PAN; transmitting the tokenized string to the merchant; receiving an authorization request for the transaction, the authorization request including the tokenized string; requesting authorization for the transaction from a financial institution that is an issuer of the financial account of the consumer; receiving an authorization decision for the transaction from the issuing financial institution; as well as An authorization response is transmitted to the merchant.

Images