Interactive account tokenization system and method

Abstract

The disclosed method includes a tokenization computer receiving a tokenization request message from a processing network computer during an interaction between a first user device and a second user device. The tokenization request message includes first user account data and second user account data. The tokenization computer is capable of selecting one of a plurality of tokenization options in a tokenization matrix based on the first user account data and the second user account data. The tokenization computer is then capable of determining backup first user account data and backup second user account data based on the tokenization option. The tokenization computer is capable of generating a tokenization response message including the backup first user account data and the backup second user account data. The tokenization computer is then capable of providing the tokenization response message to the processing network computer.

Description

[0001] Cross-references to related applications

[0002] none. Technical Field

[0003] This invention relates to the field of computer and information technology, and more particularly to a digital asset management system. Specifically, this invention relates to a tokenization platform for generating, storing, and trading digital tokens, which represent real-world goods or physical assets and establish a cryptographic association with those goods or assets. Background Technology

[0004] User-to-user interaction occurs when one user initiates an interaction with another user to transfer data, share a Wi-Fi connection, transfer funds, etc. Users may or may not know each other. However, during the interaction, sensitive data (such as account names / numbers) may be provided to another user to complete the interaction. Each user's confidentiality is compromised due to the current user-to-user interaction.

[0005] Furthermore, these types of user interactions may also put user security at risk by providing account names / numbers to other users. Malicious users may attempt to fraudulently exploit the received account names / numbers.

[0006] The interaction may also require the recipient or sender, or both, to securely store other users' account names / numbers. Each user needs enhanced security capabilities (e.g., hardware and software) to securely store this sensitive data. This raises not only security issues but also complexity issues.

[0007] The implementation scheme disclosed herein addresses this problem and other issues individually and collectively. Summary of the Invention

[0008] The implementation plan involves methods and systems for interactive account tokenization processing.

[0009] One implementation relates to a method comprising: during an interaction between a first user equipment and a second user equipment, receiving a tokenization request message from a processing network computer, wherein the tokenization request message includes first user account data and second user account data; selecting a tokenization option from a plurality of tokenization options in a tokenization matrix based on the first user account data and the second user account data; determining alternative first user account data and alternative second user account data based on the tokenization option; generating a tokenization response message including the alternative first user account data and the alternative second user account data by the tokenization computer; and providing the tokenization response message to the processing network computer by the tokenization computer.

[0010] Another embodiment relates to a tokenization computer comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: during an interaction between a first user equipment and a second user equipment, receiving a tokenization request message from a processing network computer, wherein the tokenization request message includes first user account data and second user account data; selecting a tokenization option from a plurality of tokenization options in a tokenization matrix based on the first user account data and the second user account data; determining alternative first user account data and alternative second user account data based on the tokenization option; generating a tokenization response message including the alternative first user account data and the alternative second user account data by the tokenization computer; and providing the tokenization response message to the processing network computer by the tokenization computer.

[0011] Another implementation relates to a method comprising: receiving, by an authorized entity computer, an interaction request message including an amount, first user account data, and second user account data from a first user device; determining, by the authorized entity computer, whether to authorize the interaction; if the interaction is authorized, determining, by the authorized entity computer, a tokenization tag indicating whether to tokenize the first user account data; modifying, by the authorized entity computer, the interaction request message to include the tokenization tag; and providing, by the authorized entity computer, the interaction request message to a processing network computer, wherein the processing network computer provides a tokenization request message including the first user account data, the second user account data, and the tokenization tag to a tokenization computer, wherein the tokenization computer: selects one of a plurality of tokenization options in a tokenization matrix based on the first user account data and the second user account data; determines alternative first user account data and alternative second user account data based on the tokenization option; and generates a tokenization response message including the alternative first user account data and the alternative second user account data.

[0012] Further details regarding the embodiments of this disclosure can be found in the detailed description and the accompanying drawings. Attached Figure Description

[0013] Figure 1 A block diagram of a tokenization system according to an implementation scheme is shown.

[0014] Figure 2 A block diagram of the components of a tokenized computer according to an implementation scheme is shown.

[0015] Figure 3 A flowchart illustrating the account tokenization and interaction methods according to the implementation scheme is shown.

[0016] Figure 4 The tokenization matrix according to the implementation scheme is shown.

[0017] Figure 5 A flowchart of the token initiation and interaction method according to the implementation scheme is shown. Detailed Implementation

[0018] Before discussing the implementation schemes of this disclosure, some terms may be described in further detail.

[0019] "User" can include an individual. In some implementations, a user can be associated with one or more personal accounts and / or mobile devices. In some implementations, a user may also be referred to as a cardholder, account holder, or consumer.

[0020] "User equipment" can be a device operated by a user. Examples of user equipment can include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (such as automobiles), simplified client devices, tablet PCs, and so on. Furthermore, user equipment can be any type of wearable technology device, such as watches, headphones, glasses, etc. User equipment can include one or more processors capable of processing user input. User equipment can also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. User equipment can include any electronic device that can be operated by a user, and said electronic device can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (such as the Internet or a private network).

[0021] A "user identifier" may include any piece of data capable of identifying a user. A user identifier may include any suitable alphanumeric string. In some implementations, the user identifier may be derived from user identification information. In some implementations, the user identifier may include an account identifier associated with the user.

[0022] "Interaction" can include mutual effects or influences. Interaction can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some implementations, interaction can include a user requesting access to secure data, a secure webpage, a secure location, etc. In other implementations, interaction can include payment transactions, in which two devices can interact to facilitate payment.

[0023] "User account data" may include one or more pieces of information about a record. User account data may include data identifying an account maintained by the user and / or associated with an account maintained by the user. For example, user account data may be a real account number or a token.

[0024] "Backup user account data" may include one or more other pieces of information about the record. Backup user account data can be user account data. In some implementations, if the user account data is a real account number, then the backup user account data can be a token. As another example, if the user account data is a token, then the backup user account data can be a real account number. However, it should be understood that backup user account data can be the same data as user account data based on, for example, tokenized tokens in a tokenization matrix.

[0025] A "tokenization token" can include variables used to indicate a specific attribute (tokenization) of the data. A tokenization token can indicate whether user account data should be tokenized during an interaction. In some implementations, the tokenization token can be a Boolean value indicating "true" or "false".

[0026] A "token" can be an alternative value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0027] A "payment token" may include an identifier for a payment account, which is a substitute for an account identifier such as a Primary Account Number (PAN). For example, a payment token may include a series of alphanumeric characters that can be used as a substitute for the original account identifier. For instance, the token "4900 0000 0000 0001" can be used in place of the PAN "4147 09000000 1234". In some embodiments, the payment token may be "reserved format" and may have a numerical format conforming to account identifiers used in existing transaction processing networks (e.g., ISO 8583 Financial Transaction Message Format). In some embodiments, the payment token may replace the PAN used to initiate, authorize, settle, or resolve payment transactions, or represent the original document in other systems that typically provide the original document. In some embodiments, the payment token may be generated such that the recovery of the original PAN or other account identifier from the token value can be done without computation. Additionally, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to recognize the entity issuing the token.

[0028] Tokenization is the process of replacing data with alternative data. For example, a payment account identifier can be tokenized by replacing the primary account identifier with an alternative number (e.g., a token) that can be associated with the payment account identifier (e.g., a primary account number (PAN)). Additionally, tokenization can be applied to any other information that can be replaced with an alternative value (i.e., a token). Tokenization improves the efficiency and security of transactions.

[0029] A “tokenization computer” can include a system that serves tokens. In some embodiments, a tokenization computer can facilitate requesting, determining (e.g., generating), and / or issuing tokens, and maintaining the established mapping of tokens to Primary Account Numbers (PANs) in a repository (e.g., a token vault). In some embodiments, a tokenization computer can establish a token assurance level for a given token to indicate the confidence level of the token’s association with a PAN. A tokenization computer can include or communicate with a token vault that stores the generated tokens. A tokenization computer can support token processing for interactions (e.g., payment transactions) submitted using tokens by de-tokenizing the tokens to obtain the actual PAN. In some embodiments, other tokenization computers, such as processing network computers, are also included. Various entities in the tokenization ecosystem can assume the role of a tokenization computer operator. For example, payment networks and issuers or their agents can become tokenization computer operators by implementing token services according to embodiments of the present invention.

[0030] The "token expiration date" can be the expiration date / time of the token. The token expiration date can be passed between entities in the tokenized ecosystem during transaction processing to ensure interoperability. The token expiration date can be a numerical value (e.g., a 4-digit number). In some implementations, the token expiration date can be expressed as a duration measured from the issuance time.

[0031] A "tokenization request message" can be an electronic message used to request a token. A tokenization request message may include information that can be used to identify an account (such as a payment account or digital wallet), and / or information used to generate a token (such as a payment token). For example, a tokenization request message may include first user account data (e.g., first user real account number, first user token, etc.) and second user account data (e.g., second user real account number, second user token, etc.). As an additional example, a tokenization request message may include payment credentials, mobile device identification information (e.g., phone number or MSISDN), digital wallet identifier, information identifying the tokenizing computer, password, and / or any other suitable information. The information included in the tokenization request message may be encrypted (e.g., using an issuer-specific key).

[0032] A "tokenization response message" can be a message responding to a token request. A tokenization response message can include instructions to approve or reject the token request. For example, a tokenization request message can include backup first user account data (e.g., first user real account number, first user token, etc.) and backup second user account data (e.g., second user real account number, second user token, etc.). A tokenization response message can also include a token, mobile device identification information (e.g., phone number or MSISDN), a digital wallet identifier, information identifying the tokenized computer, a password, and / or any other suitable information. Information included in the tokenization response message can be encrypted (e.g., using an issuer-specific key).

[0033] A tokenization matrix may include an array of tokenized data. The tokenization matrix may include multiple rows and columns containing tokenized data. Rows in the tokenization matrix may be tokenization options. The tokenization matrix may be used to determine one or more processes to identify altered user account data derived from user account data. The tokenization matrix may include any suitable number of columns associated with each tokenization option. The tokenization matrix may include columns associated with: first user account data, first tokenized token, second user account data, second tokenized token, alternate first user account data (or a process for obtaining alternate first user account data), and alternate second user account data (or a process for obtaining alternate first user account data).

[0034] "Tokenization options" can include selectable tokenization processes. Tokenization options can be rows in a tokenization matrix. Tokenization options can include one or more tokenization tokens. For example, tokenization options can include a first tokenization token received and set by a first authorized entity computer, and a second tokenization token received and set by a second authorized entity computer. The tokenization computer can determine a specific tokenization option based on the received first and second user account data, and in some embodiments, based on the first and second tokenization tokens. Appropriate tokenization options in the tokenization matrix can be used to determine alternative user account data.

[0035] A “processing network computer” can include a server computer for processing network data. In some embodiments, the processing network computer may be coupled to a database and may include any hardware, software, other logical components, or combinations thereof for serving requests from one or more client computers. The processing network computer may include one or more computing devices and may use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers. In some embodiments, the processing network computer may operate multiple server computers. In such embodiments, each server computer may be configured to process transactions in a given region or to process a specific type of transaction based on transaction data.

[0036] A processing network computer may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception document services, and clearing and settlement services. An exemplary processing network computer may include VisaNet™. Networks including VisaNet™ are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™ specifically includes an integrated payments system for processing authorization requests and a Base II system for performing clearing and settlement services. The processing network computer may use any suitable wired or wireless network, including the Internet.

[0037] A “credential” can include any evidence of authorization, rights, or privileges. For example, an access credential can include permission to access certain tangible or intangible assets, such as buildings or documents. Instances of credentials can include passwords, passcodes, or secret messages. In another instance, a payment credential can include any suitable information associated with and / or identifying an account (e.g., a payment account and / or a payment device associated with that account). This information can be directly related to the account or derived from account-related information. Instances of account information can include “account identifiers” such as PAN (primary account number or “account number”), tokens, sub-tokens, gift card numbers or codes, prepaid card numbers or codes, usernames, expiration dates, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and so on. An instance of a PAN is a 16-digit number, such as “4147 0900 0000 1234”. In some implementations, credentials can be considered sensitive information.

[0038] A “password” can include obscure text, such as encrypted text. A password can be formed by encrypting input data using an encryption key, such as a symmetric encryption key. In some implementations, the password is reversible, allowing the same symmetric key to be used to obtain the input used to form the password for decryption. In some implementations, the password can also be a digital signature if the input data is encrypted using the private key of a public / private key pair. The digital signature can be verified using the public key of the public / private key pair. In some implementations, the password can include a dCVV (Dynamic Card Authentication Value).

[0039] The term "verification" and its derivatives can refer to the process of using information to determine whether a potential subject is valid under a given set of conditions. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0040] An "authorizing entity" can be an entity that requests authorization. Instances of authorizing entities can be publishers, government agencies, document repositories, access administrators, and so on.

[0041] "Issuer" can typically refer to a commercial entity that maintains user accounts (e.g., a bank). Issuers can also issue payment credentials to consumers that are stored on user devices such as cell phones, smart cards, tablets, or laptops.

[0042] A “processor” can include a device that performs a task. In some embodiments, a processor can include any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor such as AMD’s Athlon, Duron, and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0043] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include non-transient computer-readable media whose storage can be executed by a processor to implement desired methods. Instances of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0044] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one instance, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0045] The embodiments of this disclosure allow user-to-user interactions utilizing user account data, which may include real account numbers and / or tokens. Various embodiments allow tokenization without requiring any changes to the existing interface by the authorizing entity computer (e.g., various financial institutions), thereby creating a frictionless experience. To this end, a tokenizing computer can be connected (e.g., via a processing network computer) and tokenize and / or de-tokenize originating user (e.g., first user) data and receiving user (e.g., second user) data based on a tokenization matrix. The tokenizing computer can store a tokenization matrix including multiple tokenization options that allow the tokenizing computer to determine which account values ​​to tokenize or which tokens to de-tokenize. Additionally, the tokenization matrix may include tokenization markers for the originating and receiving users, indicating whether to perform the tokenization and / or de-tokenization process to determine alternative user account data. For example, the originating authorizing entity computer (e.g., the first authorizing entity computer) may not be mounted with the tokenizing computer. In this scenario, the initiating authorizing entity computer can provide first user account data as the real account number, along with a tokenized tag indicating that the real account number will not be tokenized (because no token will be available). Since no tokenization will be performed for the current interaction, the tokenizing computer can then use the tokenization matrix to determine alternative first user account data as the real account number.

[0046] Figure 1 A tokenization system 100 according to an embodiment of the present disclosure is illustrated. The tokenization system 100 includes a first user equipment 102, a first authorized entity computer 104, a processing network computer 106, a tokenizing computer 108, a second authorized entity computer 110, and a second user equipment 112. The first user equipment 102 is operatively communicable with the first authorized entity computer 104, which is operatively communicable with the processing network computer 106. The processing network computer 106 is operatively communicable with the tokenizing computer 108 and the second authorized entity computer 110, which is operatively communicable with the second user equipment 112.

[0047] To simplify the explanation, Figure 1 A certain number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 All components shown are either fewer or more.

[0048] At least in Figure 1 Messages between devices in the tokenization system 100 can be transmitted using secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583), and / or similar protocols. The communication network can include any and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a Node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, and / or similar protocols); and / or similar networks. The communication network can use any suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channel can include a secure communication channel that can be established in any known manner, such as by using mutual authentication and session keys, and by establishing a Secure Sockets Layer (SSL) session.

[0049] The first user equipment 102 and the second user equipment 112 may include devices operated by the first user and the second user, respectively. For example, the first user equipment 102 may include a smartphone, a laptop, etc. The first user equipment 102 may be configured to initiate interaction with the second user equipment 112 to obtain, access, provide, or provide access to resources. The first user equipment 102 may connect to the first authorized entity computer 104 via a web page or application installed on the first user equipment 102.

[0050] The second user equipment 112 may be similar to the first user equipment 102. In some embodiments, the second user equipment 112 may initiate interaction with the first user equipment 102 to obtain, access, provide, or provide access to resources. The second user equipment 112 may connect to the second authorized entity computer 110 via a web page or application installed on the second user equipment 112.

[0051] The first authorized entity computer 104 and the second authorized entity computer 110 may include computers, server computers, databases, and / or any combination thereof to provide data between user equipment (e.g., first user equipment 102) and processing network computer 106. In other embodiments, the authorized entity computers may be operated by issuing entities and / or authorizing entities (e.g., issuers). Issuers may maintain accounts on behalf of users. For example, the first authorized entity computer 104 may maintain a first account on behalf of a first user of first user equipment 102. For example, the second authorized entity computer 110 may maintain a second account on behalf of a second user of second user equipment 112. The first account associated with the first user may be identified by first user account data. The first user account data may be a real account number and / or a token. Similarly, the second account associated with the second user may be identified by second user account data. The second user account data may be a real account number and / or a token.

[0052] In some implementations, the first authorized entity computer 104 and the second authorized entity computer 110 may be the same authorized entity computer. For example, a first user of the first user equipment 102 may be associated with a first account maintained by the first authorized entity computer 104, and a second user of the second user equipment 112 may be associated with a second account maintained by the first authorized entity computer 104.

[0053] The processing network computer 106 may include computers, server computers, databases, and / or any combination thereof to coordinate functions for routing, generating, and formatting messages to facilitate the implementation. In other implementations, the processing network computer 106 may be located within a payment processing network. The payment processing network may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception document services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™ specifically includes a VIP system (Visa Integrated Payment System) for processing authorization requests and a Base II system for performing clearing and settlement services. The payment processing network may use any suitable wired or wireless network, including the Internet.

[0054] The network computer 106 can transmit a request message during interactions between the first user equipment 102 and the second user equipment 112. This request message may include first user account data and second user account data.

[0055] In some embodiments, the processing network computer 106 may generate a tokenization request message, or receive a tokenization request message from an authorized entity computer (e.g., a first authorized entity computer 104), and then send the tokenization request message to a tokenization computer 108. The tokenization request message may request a token from the tokenization computer 108 and may include information including first user account data and second user account data. For example, the first user account data may be the PAN of the account to be tokenized. In some embodiments, the tokenization request message may include a first tokenization tag and a second tokenization tag indicating whether the relevant user account data is to be tokenized. In other embodiments, the tokenization request message may include information about the specific circumstances / situation in which the requested alternate user account data (e.g., a token) will be used (e.g., during a specific time period).

[0056] After receiving a tokenization request message from the processing network computer 106, the tokenization computer 108 can select one of a plurality of tokenization options from a tokenization matrix based on first user account data and second user account data. For example, the tokenization matrix may include a plurality of tokenization options with different inputs of first user account data, second user account data, a first tokenization tag, and a second tokenization tag. Utilizing the tokenization option that matches the data received in the tokenization request message allows the tokenization computer to determine alternative first user account data and alternative second user account data.

[0057] The backup user account data can be other user account data associated with the user account. For example, the first user account data can be a real account number, while the backup first user account data can be a token. As another example, the second user account data can be a token, while the backup second user account data can be a real account number. In some implementations, the selected tokenization option can be used to determine that the backup user account data is the same as the user account data. For example, the first user account data can be a real account number, and the backup first user account data can be a real account number.

[0058] The tokenizing computer 108 can then generate a tokenized response message that includes backup first user account data and backup second user account data, and then provide the tokenized response message to the processing network computer 106.

[0059] If the backup first user account data and / or backup second user account data are tokens, the tokenization computer 108 can obtain the tokens in any suitable manner. In some embodiments, the tokens may be pre-generated and stored by the tokenization computer 108 until a request for the token is received. Once the request is received, the real account number, along with the token associated with that real account number, can be stored in a database at the tokenization computer 108. In other embodiments, the tokens may be generated after a request for the token is received. The tokens may be mathematically derived or not mathematically derived from the real account number and / or any other data associated with the user account and / or user device. In either case, in some embodiments, user account data (e.g., the token and the real account number) and any password (and any restrictions associated with the password) may be stored in a database at the tokenization computer 108, or even at the processing network computer 106. Other information that may reside in the database of the processing network computer 106 may also include the balance and / or restrictions associated with the token.

[0060] Figure 2 A block diagram of a tokenization computer 200 according to an embodiment is shown. An exemplary tokenization computer 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, a token store 210, and a computer-readable medium 208. The computer-readable medium 208 may include a tokenization matrix module 208A, a token exchange module 208B, and an authentication module 208C.

[0061] Memory 202 can be used to store data and code. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (such as RAM, DRAM, ROM, flash memory, or any other suitable memory device). For example, memory 202 can store first user account data, second user account data, first tokenized token, second tokenized token, tokenization matrix, and so on.

[0062] The token vault 210 can store tokens and their associated credentials (such as real account numbers) in a database. The database may also include passwords associated with the tokens, as well as any restrictions on the use of such tokens or the balances associated with them. The token vault 210 can store data in a database such as an Oracle™ database.

[0063] The tokenization matrix module 208A may include code or software executable by the processor 204 to create and utilize a tokenization matrix. The tokenization matrix module 208A, in conjunction with the processor 204, can generate a tokenization matrix that can determine what kind of output to indicate based on input data. The input data may include first user account data, a first token, second user account data, and / or a second token. The output determined by the tokenization matrix module 208A in conjunction with the processor 204 may include alternative first user account data and alternative second user account data. The tokenization matrix module 208A, in conjunction with the processor 204, can generate any suitable number of tokenization matrices. For example, the tokenization matrix module 208A, in conjunction with the processor 204, can generate a tokenization matrix for each user. In some embodiments, the tokenization matrix module 208A, in conjunction with the processor 204, can generate a tokenization matrix for each pair of users (e.g., for each initiator / receiver pair).

[0064] The tokenization matrix module 208A, in conjunction with the processor 204, can generate a tokenization matrix when supplying tokens to users (e.g., as referenced). Figure 5 (More detailed description follows). As an example, the tokenization matrix module 208A, in conjunction with the processor 204, can generate multiple tokenization options, including a first token and a second token, and each variation of the first and second user account data for each potential input. For example, the tokenization matrix module 208A, in conjunction with the processor 204, can generate a first tokenization option that includes: first user account data equal to the real account number, a first token set to true, second user account data equal to the real account number, and a second token set to false. In this case, the output determined using the first tokenization option can include alternate first user account data equal to the token and alternate second user account data equal to the real account number. The tokenization matrix module 208A, in conjunction with the processor 204, can generate... Figure 4 The tokenization matrix shown in the image.

[0065] The tokenization matrix module 208A, in conjunction with the processor 204, can utilize the tokenization matrix upon receiving a tokenization request message that includes first user account data and second user account data. The tokenization request message may also include a first token. For example, a first authorized entity computer associated with a first user equipment may provide a first token for the current interaction. In some embodiments, the tokenization request message may also include a second token. For example, the first authorized entity computer may store a second token on behalf of a second authorized entity computer and may provide the second token to the tokenization computer 200 on behalf of the second authorized entity computer.

[0066] In other embodiments, the tokenization matrix module 208A, in conjunction with the processor 204, may receive a first tokenized token and a second tokenized token from the first authorized entity computer and the second authorized entity computer prior to the interaction. If the first tokenized token and / or the second tokenized token are not received in the tokenization request message, the tokenization matrix module 208A, in conjunction with the processor 204, may utilize these first tokenized tokens and / or the second tokenized tokens.

[0067] The token exchange module 208B may include code or software executable by the processor 204 to cause the tokenization computer 200 to provide a token in response to receiving a real account number when the tokenization options of the tokenization matrix instruct the tokenization computer 200 to determine a token associated with a real account number. Alternatively, when the tokenization options of the tokenization matrix instruct the tokenization computer 200 to determine a real account number associated with a token, the token exchange module 208B, in conjunction with the processor 204, may provide a real account number in response to receiving a token. For example, the token exchange module 208B may include logic that causes the processor 204 to generate a token and / or associate the token with a real account number. Token records may then be stored in a token record database and / or a token library 210, indicating that a token is associated with a user or a real account number.

[0068] The verification module 208C may include code or software executable by the processor 204 to verify the tokenization request before providing the token and / or real account number to an external entity. For example, the verification module 208C may include logic that enables the processor 204 to verify the trustworthiness of the tokenization request message by decrypting a password included in the message, by confirming that the credentials in the tokenization request message are trustworthy and associated with the requesting device, and by assessing the risk associated with the requesting device.

[0069] Computer-readable medium 208 may include code executable by processor 204 to perform a method comprising: during an interaction between a first user equipment and a second user equipment, receiving a tokenization request message from a processing network computer, wherein the tokenization request message includes first user account data and second user account data; selecting a tokenization option from a plurality of tokenization options in a tokenization matrix based on the first user account data and the second user account data; determining alternative first user account data and alternative second user account data based on the tokenization option; generating a tokenization response message including the alternative first user account data and the alternative second user account data by the tokenization computer; and providing the tokenization response message to the processing network computer by the tokenization computer.

[0070] In some implementations, the tokenization computer 200 can classify in-network message processing errors into different types. For example, a first type of in-network message processing error may include errors that may occur during tokenization (e.g., unknown account). A second type of in-network message processing error may include errors that may occur during detoxification (e.g., token not found). A third type of in-network message processing error may include limit check failures (e.g., interaction volume exceeded limit, invalid interaction currency code, token usage limit reached, token expired, token counter check failed, invalid token status, etc.).

[0071] These message processing errors can be provided to the authorized entity computer during the interaction. The authorized entity computer can classify token restriction check failures into hard rejection or soft rejection categories. Restriction checks can have different rejection levels for different interaction types (e.g., credit transfer, payment request, remittance notification, etc.) and for different authorized entity computer roles in the interaction (e.g., initiator or recipient). During restriction check execution, if a restriction fails due to soft rejection (e.g., is classified as soft rejection), the restriction check can continue to execute the next restriction until all restrictions are executed or a restriction fails due to hard rejection (e.g., is classified as hard rejection). Each failure reason code from soft rejection and hard rejection can be added to the reason code field of the response message. In some implementations, the authorized entity computer can provide restriction information to the tokenization computer 200, allowing the tokenization computer 200 to determine the execution of token restriction checks based on preferences set by the authorized entity computer.

[0072] Network interface 206 may include an interface that allows token-based computer 200 to communicate with external computers. Network interface 206 enables token-based computer 200 to transfer data to and from another device (e.g., a network processing computer, one or more authorized entity computers, etc.). Some examples of network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TMData transmitted via network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 206 and other devices via communication paths or channels. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0073] Figure 3 A flowchart illustrating the account tokenization and interaction methods according to the implementation scheme is shown. Figure 3 The method illustrated herein is described in the context of a first user initiating an interaction to transfer funds to a second user. However, it should be understood that the invention can be applied to other situations.

[0074] At step 316, the first user equipment 302 may receive user input from the first user to initiate interaction with the second user of the second user equipment 312. For example, the first user equipment 302 may receive a request from the first user to transfer an amount to the second user. The first user may select second user account data or enter second user account data associated with the second user of the second user equipment 312. The second user account data may include a real account number or a token.

[0075] In some implementations, if the first user equipment 302 has not previously interacted with the second user equipment 312, the first user can enter a real account number associated with the second user equipment 312 (e.g., a second real account number). In other implementations, if the first user equipment 302 has not previously interacted with the second user equipment 312, the first user can enter a token associated with the second user equipment 312 (e.g., a second token). The first user of the first user equipment 302 can obtain the second real account number or the second token from the second user in any suitable manner (e.g., verbal communication, SMS message, secure data transmission, etc.).

[0076] If the first user equipment 302 has previously interacted with the second user equipment 312, the first user equipment 302 may present a list of real account numbers and / or tokens associated with users with whom the first user can interact. For example, the first user equipment 302 may present a second real account number or a second token to the first user (e.g., on a display) for selection.

[0077] In some implementations, the first user equipment 302 may also receive a selection of which first user account data to use for interaction. For example, the first user may be associated with multiple first user accounts maintained by the first authorized entity computer 304. The first user can choose which account they request to use for interaction. For example, the first user equipment 302 may present the first user with a list of real account numbers and / or tokens.

[0078] At step 318, after receiving user input for performing the interaction, the first user equipment 302 may generate an interaction request message including an amount, first user account data, and second user account data. In some embodiments, the first user equipment 302 may obtain the first user account data from memory.

[0079] In step 320, the first user equipment 302 may transmit the interaction request message to the first authorized entity computer 304.

[0080] In some implementations, after receiving an interaction request message, the first authorized entity computer 304 can use the first user account data to determine the first user account maintained by the first authorized entity computer 304.

[0081] At step 322, the first authorizing entity computer 304 may determine whether to authorize the interaction. For example, the first authorizing entity computer 304 may verify whether the first user account includes an amount greater than or equal to the amount included in the interaction request message. The first authorizing entity computer 304 may generate an indication of whether the interaction is authorized. For example, if the interaction is a data transfer, the first authorizing entity computer 304 may determine whether to authorize the data transfer based on the content of the data to be transferred, the amount, the data transfer history of the first user equipment, and / or the data limitations of the first user equipment 302.

[0082] In some implementations, the first authorizing entity computer 304 may generate an indication of whether the interaction is authorized. For example, if the interaction is authorized, the first authorizing entity computer 304 may include an indication that the interaction is authorized in the interaction request message.

[0083] In some implementations, the first authorizing entity computer 304 may determine a first tokenization flag to be included in the interaction request message. The first tokenization flag may instruct the tokenizing computer 308 whether to tokenize the first user account data. The first authorizing entity computer 304 may determine the first tokenization flag based on the current interaction. For example, if the interaction is the first interaction between the first user and the second user, the first authorizing entity computer 304 may determine to set the first tokenization flag to true (to instruct the tokenizing computer 308 to tokenize the first user account data (i.e., the first real account number)) thereby increasing the security and confidentiality of the interaction.

[0084] In other implementations, the first authorizing entity computer 304 may provide a first tokenized token to the tokenizing computer 308 prior to the current interaction. In this case, the first tokenized token may be a default tokenized token that will be used if the first authorizing entity computer 304 does not provide a tokenized token in the interaction request message.

[0085] At step 326, after authorizing the interaction, the first authorizing entity computer 304 can transmit the interaction request message to the processing network computer 306.

[0086] At step 328, after receiving the interaction request message, the processing network computer 306 may generate a tokenized request message that includes first user data and second user data. In some embodiments, the tokenized request message may also include a first tokenized tag. In other embodiments, the tokenized request message may also include a second tokenized tag.

[0087] In step 330, after generating the tokenization request message, the processing network computer 306 can provide the tokenization request message to the tokenization computer 308.

[0088] At step 332, after receiving the tokenization request message from the processing network computer 306, the tokenization computer 308 may select one of a plurality of tokenization options from the tokenization matrix based on the first user account data and the second user account data. The tokenization option may include a tokenization process that can be selected as a row in the tokenization matrix. Each of the plurality of tokenization options may be a row in the tokenization matrix that includes one or more tokenization tokens. The first tokenization option may include a first tokenization token received from and set by the first authorized entity computer 304, and a second tokenization token received from and set by the second authorized entity computer 310.

[0089] At step 334, after selecting the tokenization option, the tokenization computer 308 can determine alternative first user account data and alternative second user account data based on the tokenization option. For example, the tokenization option can instruct the tokenization computer 308 to determine specific alternative first user account data and specific alternative second user account data. The tokenization option can instruct that the alternative first user account data should be a first token (associated with a first user), and the alternative second user account data should be a second real account number (associated with a second user). Therefore, for example, the tokenization computer 308 can tokenize the first real account number to obtain the first token. The tokenization computer 308 can determine that the second real account number should not be tokenized, and that the alternative second account data should be set to the second real account number.

[0090] As an illustrative example, Figure 4 The tokenization matrix is ​​shown according to some implementation schemes. Figure 4 The tokenization matrix shown comprises multiple rows and columns. The tokenization matrix includes the following columns: tokenization option number 402, first user account data 404, first tokenization token 406, second user account data 408, second tokenization token 410, alternate first user account data 412, and alternate second user account data 414.

[0091] Tokenization option number 402 can be a tokenization option identifier that identifies each row of the tokenization matrix (e.g., tokenization options).

[0092] The first user account data 404, the first tokenization tag 406, the second user account data 408, and the second tokenization tag 410 can be inputs for selecting tokenization options. For example, the tokenization computer 308 can receive a tokenization request message including: first user account data, which is a first real account number; a first tokenization tag set to true (indicating tokenization of the first real account number); and second user account data, which is a second real account number. The tokenization computer 308 can determine a second tokenization tag associated with the second real account number from a database. For example, the second authorizing entity computer 310 may have previously provided the second tokenization tag to the tokenization computer 308. As an example, the second tokenization tag can be equal to true.

[0093] The tokenization computer 308 can use the aforementioned data to determine which tokenization option to select. In this example, the tokenization computer 308 can determine to select tokenization option number 1.

[0094] Re-reference Figure 4The backup first user account data 412 and backup second user account data 414 can instruct the tokenization computer 308 which outputs to determine. For example, the first tokenization option indicates that the backup first user account data 412 is the first token and the backup second user account data 414 is the second token. After selecting the tokenization option, the tokenization computer 308 can determine the backup first user account data and the backup second user account data.

[0095] Based on the first tokenization option, the tokenization computer 308 can identify the first token as backup first user account data. The tokenization computer 308 is capable of determining and / or generating the first token in any suitable manner. For example, the tokenization computer 308 can retrieve the first token from a token vault or memory. As another example, the tokenization computer 308 can generate the first token based on predetermined inputs to a cryptographic function. For example, the tokenization computer 308 can generate the first token based on any combination of a first real account number, a tokenization computer identifier, a first user device identifier, a first authorized entity computer identifier, a counter, an identifier, a password, a date, time, and / or any other suitable data associated with the first user.

[0096] Similarly, based on the first tokenization option, the tokenization computer 308 can determine the second token as backup second user account data. The tokenization computer 308 is capable of determining and / or generating the second token in any suitable manner. The tokenization computer 308 is capable of generating the second token in a manner similar to or different from the first token.

[0097] At step 336, after determining the alternative user account data (e.g., alternative first user account data and alternative second user account data), the tokenization computer 308 may generate a tokenization response message that includes the alternative first user account data and the alternative second user account data. In some embodiments, the tokenization response message may also include an amount, an indication of whether the interaction is authorized, and / or any other suitable tokenization-related data (e.g., no user message found, tokenization failure flag, etc.).

[0098] In step 338, after generating the tokenized response message, the tokenized computer 308 can provide the tokenized response message to the processing network computer 306.

[0099] At step 340, after receiving the tokenized response message from the tokenized computer 308, the processing network computer 306 may modify the interaction request message to include alternative first user account data and alternative second user account data. For example, the processing network computer 306 may replace the first user account data with the alternative first user account data. The processing network computer 306 may also replace the second user account data with the alternative second user account data.

[0100] At step 342, after including the backup user account data in the interaction request message, the processing network computer 306 may transmit the interaction request message to the second authorized entity computer 310, which maintains the account identified by the backup second user account data.

[0101] At step 344, after receiving the interaction request message, the second authorized entity computer 310 can update the second user account associated with the second user of the second user equipment 312. The second authorized entity computer 310 can update the amount in the second user account using the amount indicated in the interaction request message. For example, the second authorized entity computer 310 can obtain a second standby account identifier (e.g., a real account identifier) ​​from the interaction request message and use this information to determine the second user account before updating it.

[0102] At step 346, after updating the second user account, the second authorized entity computer 310 can notify the second user of the update to the second user account. For example, the second authorized entity computer 310 can transmit any suitable message type to the second user equipment 312, the message type including at least an amount, and in some embodiments, including backup first user account data.

[0103] In some implementations, the second authorized entity computer 310 may execute steps 346 and 344 simultaneously. In other implementations, the second authorized entity computer 310 may execute step 346 first, followed by step 344. For example, the second authorized entity computer 310 may provide an interactive notification to the second user equipment 312. After receiving the notification, the second user equipment 312 may choose to accept or reject the interaction. The second user equipment 312 may then generate a notification response indicating whether the second user accepts the interaction. Once the second authorized entity computer 310 receives this notification response, it may update the second user account at step 344 if the second user accepts the interaction.

[0104] At steps 348 and 350, a clearing and settlement process may occur. For example, at step 348, the first authorized entity computer 304 and the processing network computer 306 may transfer funds between the computers (e.g., between accounts maintained by each respective device). For example, the first authorized entity computer 304 may transfer an amount equal to the amount of the interactive request message plus any fees (if applicable) to the processing network computer 306. At step 350, the processing network computer 306 and the second authorized entity computer 310 may transfer funds between the computers (e.g., between accounts maintained by each respective device). For example, the processing network computer 306 may transfer an amount equal to the amount of the interactive request message to the second authorized entity computer 310. In some embodiments, during step 350, the funds provided to the second authorized entity computer 310 may be provided to the second user account associated with the second user of the second user device 312.

[0105] Figure 5 A flowchart of the token initiation and interaction method according to the implementation scheme is shown. Figure 5 The method illustrated herein is described in the context of a first user initiating a data transmission interaction to transmit a specific amount of data to a second user. The first user's real account number may not yet be associated with a token. During the data transmission interaction, the first user's real account number may be associated with a newly generated token. However, it should be understood that the invention can be applied to other situations.

[0106] Prior to step 514, a first user equipment (not shown) may initiate a data transfer to transmit a certain amount of data to a second user equipment (not shown). The first user's first user account data may not yet be associated with a token. The first user equipment may transmit a token supply request message (e.g., a request to supply a token for specific first user account data) to the first authorizing entity computer 504. The token supply request message may include the real account number associated with the first user. This real account number may be the real account number to which a token will be assigned.

[0107] At step 514, after receiving the token supply request message, the first authorizing entity computer 504 may modify the token supply request message to include a tokenization flag. The tokenization flag may indicate whether user account data (e.g., a real account number) should be tokenized during the interaction. For example, the first authorizing entity computer 504 may insert a tokenization flag into the token supply request message. In some embodiments, the first authorizing entity computer 504 may provide a tokenization flag indicating that any real account number should be tokenized. In other embodiments, the first authorizing entity computer 504 may provide a tokenization flag indicating that no real account number should be tokenized.

[0108] As an illustrative example, a token supply request message could be a request message for a one-time use token that allows a first user equipment to perform a data transfer with a second user equipment. In this case, the first authorizing entity computer 504 can determine that the one-time use token should be used together with a tokenization tag that indicates the tokenization of the real account number. This improves the security of the one-time data transfer because the real account number will be masked from the second user equipment.

[0109] At step 516, the first authorized entity computer 504 may provide a token supply request message, including the real account number and the first tokenized token, to the tokenization computer 508.

[0110] At step 518, after receiving the token supply request message, the tokenization computer 508 can determine whether to generate a token. For example, the tokenization computer 508 can determine whether a token has already been created for the real account number. If a token has already been generated for the real account number, the tokenization computer 508 can determine not to generate a token. In some embodiments, the tokenization computer 508 can determine to generate a token even if a previous token has already been generated. For example, in some embodiments, the real account number may be associated with one or more tokens. If the tokenization computer 508 determines not to generate a token, the tokenization computer 508 can skip step 520. If the tokenization computer 508 determines to generate a token, the tokenization computer 508 can generate the token at step 520.

[0111] At step 520, the tokenization computer 508 can generate a token associated with the real account number. The tokenization computer 508 can generate the token in any suitable manner. For example, the tokenization computer 508 can generate a random number, value, string, etc., as the token. In other embodiments, the token can be a derived value. For example, the token can be derived based on the real account number, any other user account data, a user identifier, an authorized entity computer identifier, a tokenization computer identifier, a counter, an index, and / or a password value.

[0112] At step 522, after generating the token, the tokenization computer 508 may store the token in a token store (as described herein) or in any other secure database. The token may be stored in association with a real account number, allowing the tokenization computer 508 to later determine the token based on the real account number or vice versa. In some embodiments, the tokenization computer 508 may store the received token as a default token for the user device.

[0113] At step 524, in some embodiments, the tokenization computer 508 is capable of generating a tokenization matrix. The tokenization computer 508 can generate a tokenization matrix with any suitable number of new tokenization options. The tokenization computer 508 can generate the tokenization matrix by iterating through each change of the first user account data, the second user account data, the first tokenization option, and the second tokenization option. For example, the tokenization computer 508 can generate the following two tokenization options, which can be the first two tokenization options in the tokenization matrix (distinguished as input and output for ease of illustration): Tokenization_Option_1_Input (First_User_Account_Data = "First Real Account Number", First_Tokenization_Token = True, Second_User_Account_Data = "Second Real Account Number", Second_Tokenization_Token = True); Tokenization_Option_1_Output(Alternate_First_User_Account_Data = "First Token", Alternate_Second_User_Account_Data = "Second Token"); Tokenization_Option_2_Input (First_User_Account_Data = "First Real Account Number", First_Tokenization_Flag = True, Second_User_Account_Data = "Second Real Account Number", Second_Tokenization_Flag = False); Tokenization_Option_2_Output(Alternate_First_User_Account_Data = "First Token", Alternate_Second_User_Account_Data = "Second Real Account Number").

[0114] At step 526, after generating the token, the tokenization computer 508 may generate a token supply response message that includes the token. In some embodiments, the token supply response message may include the token and a real account number.

[0115] At step 528, after generating the token supply response message, the tokenizing computer 508 may provide the token supply response message to the first authorizing entity computer 504.

[0116] At step 530, after receiving the token supply response message, the first authorizing entity computer 504 may begin processing data transmission to transfer data from the first user equipment to the second user equipment. In some embodiments, the first authorizing entity computer 504 is able to provide the token supply response message to the first user equipment. In other embodiments, the first authorizing entity computer 504 is able to provide the token from the token supply response message to the first user equipment.

[0117] In some implementations, at step 530, the first authorizing entity computer 504 determines whether to authorize the data transmission based on the content and amount of the data to be transmitted, the data transmission history of the first user equipment, the data restrictions of the first user equipment, and / or any other information and / or data stored by the first authorizing entity computer 504.

[0118] At step 532, the first authorized entity computer 504, the processing network computer 506, the tokenizing computer 508, and the second authorized entity computer 510 can process, for example... Figure 3 The interaction described in [reference] (e.g., data transfer). The steps included in step 532 are similar to those in [reference]. Figure 3 The steps described are already known, so they will not be repeated here.

[0119] The embodiments disclosed herein offer numerous advantages. The first and second users performing the interaction may or may not know each other. However, during current interactions, sensitive data (such as the real account number) needs to be provided to another user to complete the interaction, thus compromising the confidentiality of each user. The embodiments provided by this disclosure offer advantages over previous interaction systems by maintaining the confidentiality of the real account number. During processing, a token-based computer can determine a token for either or both users interacting, thereby hiding the real account number.

[0120] This further enhances security. For example, a malicious user might attempt to fraudulently exploit a received genuine account number. However, the tokenizing computer can identify backup first user account data, which is a token using the tokenization options of a tokenization matrix, including a tokenized tag indicating that the first user's genuine account number should be tokenized when interacting with a second user. This prevents the second user from receiving the first user's genuine account number.

[0121] The embodiments disclosed herein offer several additional advantages. For example, a particular user (and / or the authorized entity computer maintaining the user's account) may not be registered in the tokenization service and may not yet possess a token associated with the real account number. In this case, the tokenization token associated with the user and provided to the tokenization computer by the authorized entity computer can indicate that a token is not assigned to the real account number. This is advantageous because the system is unaware of the authorized entity computer's registration status and can still allow users to participate in peer-to-peer interactions. Furthermore, registering users of an institution in the tokenization service can be difficult due to the significant workload involved, and users registering within a specific institution (e.g., a banking institution) may join or leave the institution in unpredictable ways.

[0122] Although the steps in the flowcharts and process flows above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and they may still be present in embodiments of the invention.

[0123] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language (such as Java, C, C++, C#, Objective-C, Swift) or scripting language (such as Perl or Python) employing techniques such as conventional or object-oriented methods. This software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media (such as hard disk drives or floppy disks), or optical media (such as optical discs (CDs) or digital versatile optical discs (DVDs)), flash memory, and so on. The computer-readable medium may be any combination of such storage or transmission devices.

[0124] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, a computer-readable medium according to one embodiment of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with compatible devices or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0125] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art after reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the foregoing description, but rather by reference to the pending claims together with their full scope or equivalents.

[0126] Without departing from the scope of the invention, one or more features from any embodiment may be combined with one or more features from any other embodiment.

[0127] As used herein, unless explicitly indicated otherwise, the use of “a,” “an,” or “the” is intended to mean “at least one / a kind.”

Claims

1. A method for tokenized asset management, comprising: During the interaction between the first user equipment and the second user equipment, the tokenizing computer receives a tokenization request message from the processing network computer. The tokenization request message includes first user account data and second user account data. The first user account data is a real account number associated with a first user of the first user equipment. The tokenization request message also includes a first tokenization tag associated with the first user account data and a second tokenization tag associated with the second user account data. The first tokenization tag indicates that the real account number should not be tokenized. The tokenization computer selects one of a plurality of tokenization options from the tokenization matrix based on the first user account data and the second user account data; The tokenization computer determines backup first user account data and backup second user account data based on the tokenization options; The tokenization computer determines standby first user account data based on the tokenization option, wherein determining the standby first user account data includes determining that the first authorized entity computer associated with the first user device is not registered in the tokenization process by the tokenization computer and determining that the first user account data will not be tokenized, and wherein the standby first user account data is a real account number; The tokenizing computer determines standby second user account data based on the tokenizing option, wherein determining the standby second user account data includes determining that a second authorized entity computer associated with the second user device is registered in the tokenizing procedure by the tokenizing computer and determining that the second user account data will be tokenized, and wherein the standby second user account data is a token; The tokenization computer generates a tokenized response message that includes the backup first user account data and the backup second user account data; as well as The tokenized computer provides the tokenized response message to the processing network computer. This results in the use of the backup first user account data and the backup second user account data to transfer funds between the first user device and the second user device, wherein the second user account data is not exposed to the first user device.

2. The method of claim 1, wherein the tokenization request message is received from the first authorized entity computer via the processing network computer.

3. The method of claim 1, wherein the first user account data is a first real account number, the second user account data is a second real account number, the backup first user account data is a first token, and the backup second user account data is a second token.

4. The method of claim 1, wherein the tokenization request message is received from an authorized entity computer via the processing network computer, wherein the first user account data is a token associated with a first user of the first user device, wherein before receiving the tokenization request message during the interaction, the method further comprises: The tokenizing computer receives a token supply request from the authorizing entity computer, the token supply request including the real account number associated with the first user; The token, associated with the real account number, is generated by the tokenizing computer. The tokenization computer generates a token supply response message, which includes the token and the real account number; as well as The token-granting computer provides the token supply response message to the authorized entity computer.

5. The method of claim 4, wherein the token supply request further includes a first tokenization flag indicating whether the real account number is tokenized during the interaction, wherein the method further includes: The tokenization computer generates new tokenization options based on the first tokenization token to be included in the tokenization matrix.

6. The method of claim 1, wherein the tokenization option includes the first user account data, the second user account data, a first tokenization token, and a second tokenization token, wherein the first tokenization token is a first value set by a first authorized entity computer that maintains the first user account on behalf of the first user device, and wherein the second tokenization token is a second value set by a second authorized entity computer that maintains the second user account on behalf of the second user device.

7. A token-based computer, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method comprising: During the interaction between the first user equipment and the second user equipment, a tokenization request message is received from the processing network computer. The tokenization request message includes first user account data and second user account data. The first user account data is a real account number associated with a first user of the first user equipment. The tokenization request message also includes a first tokenization tag associated with the first user account data and a second tokenization tag associated with the second user account data. The first tokenization tag indicates that the real account number should not be tokenized. Select one of the multiple tokenization options in the tokenization matrix based on the first user account data and the second user account data; Determining backup first user account data based on the tokenization option, wherein determining the backup first user account data includes determining that the first authorized entity computer associated with the first user device is not registered in the tokenization process with the tokenization computer and determining that the first user account data will not be tokenized, and wherein the backup first user account data is a real account number; Determining backup second user account data based on the tokenization option, wherein determining the backup second user account data includes determining that a second authorized entity computer associated with the second user device is registered in the tokenization process using the tokenization computer and determining that the second user account data will be tokenized, and wherein the backup second user account data is a token; Generate a tokenized response message including the backup first user account data and the backup second user account data; and The tokenized response message is provided to the processing network computer. This results in the use of the backup first user account data and the backup second user account data to transfer funds between the first user device and the second user device, wherein the second user account data is not exposed to the first user device.

8. The token-based computer of claim 7, further comprising: Token library, wherein the method further includes: The tokenization matrix is ​​obtained from the token store.

9. The tokenized computer of claim 7, wherein the tokenization option includes the first user account data, the second user account data, a first tokenization token, and a second tokenization token, wherein the first tokenization token is a first value set by a first authorized entity computer that maintains the first user account on behalf of the first user device, and wherein the second tokenization token is a second value set by a second authorized entity computer that maintains the second user account on behalf of the second user device.

10. The tokenized computer of claim 7, wherein the method further comprises: Generate the tokenization matrix that includes the plurality of tokenization options, with inputs including the first user account data, the second user account data, the first tokenization token, and the second tokenization token.

11. The tokenization computer of claim 7, wherein each of the plurality of tokenization options is a row in the tokenization matrix that includes one or more tokenization tokens.

12. A method for tokenized asset management, comprising: During the interaction between the first user and the second user, the authorized entity computer receives an interaction request message from the first user's device, which includes the amount, the first user's account data, and the second user's account data; The authorization entity computer determines whether to authorize the interaction; If the interaction is authorized, the authorized entity computer determines whether to tokenize the first user account data. The authorized entity computer modifies the interaction request message to include the tokenized tag; as well as The authorized entity computer provides the interaction request message to the processing network computer, wherein the processing network computer provides a tokenization request message including the first user account data, the second user account data, and the tokenization tag to the tokenization computer, wherein the tokenization computer: selects one of a plurality of tokenization options in the tokenization matrix based on the first user account data and the second user account data, determines alternative first user account data and alternative second user account data based on the tokenization option, and generates a tokenization response message including the alternative first user account data and the alternative second user account data.

13. The method of claim 12, wherein the interaction request message includes a fund amount, wherein the authorized entity computer is a first authorized entity computer, and wherein the processing network computer: receives the tokenized response message, modifies the tokenized response message using the backup first user account data and the backup second user account data, and provides the tokenized response message to the second authorized entity computer, wherein the method further comprises: The first authorized entity computer uses the backup second user account data to provide the amount of funds indicated in the interaction request message to the second authorized entity computer via the processing network computer.

14. The method of claim 12, wherein the second user account data is selected by the first user from a list of account data on the first user device, wherein the first user account data is a real account number, and wherein a first tokenization flag indicates that the real account number is not tokenized.

15. The method of claim 14, wherein the interaction between the first user equipment and the second user equipment is a data transfer between the first user equipment and the second user equipment, wherein the amount is the amount of data to be transferred, and determining whether to authorize the interaction further includes: The authorized entity computer determines whether to authorize the data transmission based on the content of the data to be transmitted, the amount, the data transmission history of the first user equipment, and / or the data restrictions of the first user equipment.

Images