CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority to U.S. Patent Application No. 62/566, 151 , filed on September 29, 2017, the disclosure of which is herein incorporated by reference in its entirety for all purposes.

BACKGROUND

[0002] When determining whether to approve or decline transactions, an authorization entity often requires a number of details pertaining to the transaction. However, some geographic areas (various countries, military bases, etc.) limit the types of data that may be transmitted outside of the borders of those areas. When a transaction is conducted within these restrictive zones, it is difficult for an authorization entity located outside of the restrictive zone to properly assess the transaction.

Likewise, authorization entities located within the restrictive zone may not be capable of approving a transaction conducted outside of the restrictive zone using current systems. SUMMARY

[0003] Embodiments of the present disclosure address these problems and other problems, individually and collectively.

[0004] One embodiment of the disclosure is directed to a method performed by a processing network computer comprising receiving an authorization request message that includes a token, determining that the token is associated with a restrictive zone, and identifying a processing network proxy located within the restrictive zone, transmitting the authorization request message to the identified processing network proxy, and responding, to the authorization request message, with the authorization response message. In this method the processing network proxy may be caused to: identify an authorization server located within the restrictive zone that maintains an account associated with the token, route the authorization request message to the authorization server, receive an authorization response message from the authorization server, remove, from the authorization response message, sensitive information, and send, to the processing network computer, the authorization response message..

[0005] Another embodiment of the disclosure is directed to a computing device comprising a processor; and a memory including instructions that, when executed with the processor, cause the computing device to, at least: receive an authorization request message that includes a token, determine that the token is associated with a restrictive zone, identify a processing network proxy located within the restrictive zone, transmit the authorization request message to the identified processing network proxy, and respond, to the authorization request message, with the authorization response message. The processing network proxy may be caused to: identify an authorization server located within the restrictive zone that maintains an account associated with the token, route the authorization request message to the authorization server, receive an authorization response message from the authorization server, remove, from the authorization response message, sensitive information, and send, to the processing network computer, the authorization response message.

[0006] Another embodiment of the disclosure is directed to a method comprising: receiving, at a processing network proxy within a restrictive zone, an authorization request message that includes an account identifier, determining that the account identifier is associated with an authorization server located outside of the restrictive zone, identifying a processing network computer located outside of the restrictive zone, removing sensitive data from the authorization request message at least by replacing the account identifier with a token, transmitting the authorization request message to the identified processing network computer, and responding, to the authorization request message, with the authorization response message. The method may further cause the processing network computer to route the authorization request message to the authorization server, receive an authorization response message from the authorization server, and send, to the processing network proxy, the authorization response message.

[0007] Another embodiment of the disclosure is directed to a processing network proxy located within a restrictive zone comprising: a processor; and a memory including instructions that, when executed by the processor, cause the processing network proxy to, at least: receive a transaction request from a processing network computer located outside of the restrictive zone, the transaction request including a token, identify an authorization server located within the restrictive zone that maintains an account associated with the token, route the authorization request message to the authorization server, receive an authorization response message from the authorization server, remove, from the authorization response message, sensitive information, and send, to the processing network computer, the authorization response message.

[0008] Further details regarding embodiments of the disclosure can be found in the Detailed Description and the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 depicts an illustrative example of a system and a flow diagram providing an overview of the various entity interactions within a tokenization system 100 in accordance with at least some embodiments;

[0010] FIG. 2 depicts an example system architecture that may be implemented to enable transactions to be conducted in accordance with embodiments of the disclosure; [0011] FIG. 3 depicts a swim lane diagram illustrating an enrollment process that may be performed in accordance with at least some embodiments;

[0012] FIG. 4 depicts a swim lane diagram illustrating a process for enabling a transaction to be conducted within a restrictive zone that may be performed in accordance with at least some embodiments; [0013] FIG. 5 depicts a swim lane diagram illustrating a process for enabling transactions to occur outside of a restrictive zone that may include an account maintained by an authorization server within the restrictive zone which may be performed in accordance with at least some embodiments;

[0014] FIG. 6 depicts a swim lane diagram illustrating a process for enabling a transaction to be conducted within a restrictive zone that may include an account maintained by an authorization server outside of the restrictive zone which may be performed in accordance with at least some embodiments; and

[0015] FIG. 7 depicts a flow diagram illustrating a process for conducting transactions between components located within and outside of a restrictive zone in accordance with at least some embodiments. DETAILED DESCRIPTION

[0016] Prior to discussing specific embodiments of the disclosure, some terms may be described in detail.

[0017] A "token" may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN). For example, a token may include a series of numeric and/or alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token "4900 0000 0000 0001 " may be used in place of a PAN "4147 0900 0000 1234." In some embodiments, a token may be "format preserving" and may have a numeric format that conforms to the account identifiers used in existing processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0018] A "Bank Identification Number (BIN)" may be assigned by a processing network to an issuer of a payment account. BINs may be consistent with industry account and issuer identification specifications (e.g. ISO 7812) such that the processing network assigning the BIN may be identified based on the BIN and associated account ranges.

[0019] In some embodiments, the token format may allow entities in a transaction processing system to identify the issuer associated with the token. For example, the format of the token may include a token issuer identifier that allows an entity to identify an issuer. For instance, the token issuer identifier may be associated with an issuer's BIN of the underlying PAN in order to support the existing payment flow. The token issuer identifier may be a different number than the issuer's BIN and may be static. For example, if the issuer's BIN for an issuer is 412345, the token issuer identifier may be a token BIN of 428325 and this number may be static for all tokens issued from or for that issuer. In some embodiments, the token issuer identifier range (e.g., issuer token BIN range) may have the same attributes as the associated issuer card range and can be included in an issuer identifier routing table (e.g., BIN routing table). The issuer identifier routing table may be provided to the relevant entities in the transaction processing system (e.g., merchants and acquirers). [0020] A "token service system" refers to a system that facilitates requesting, generating and issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault). The token service system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN. In various embodiments, the token service system may include a token requestor and a token service provider interacting with the token requestor.

[0021] A "token service provider" may refer to an entity including one or more server computers in a token service system that generates, processes and maintains tokens. The token service provider may include or be in communication with a token vault where the generated tokens are stored. Specifically, the token vault may maintain one-to-one mapping between a token and a primary account number (PAN)

represented by the token. The token service provider may have the ability to set aside licensed BINs as token BINs to issue tokens for the PANs that may be submitted to the token service provider. Various entities of a tokenization system may assume the roles of the token service provider. For example, processing networks and issuers or their agents may become the token service provider by implementing the token services according to embodiments of the present disclosure. A token service provider may provide reports or data output to reporting tools regarding approved, pending, or declined token requests, including any assigned token requestor IDs. The token service provider may provide data output related to token-based transactions to reporting tools and applications and present the token and/or PAN as appropriate in the reporting output. [0022] A "token vault" may refer to a repository that maintains established token- to-PAN mappings. According to various embodiments, the token vault may also maintain other attributes of the token requestor that may be determined at the time of registration and that may be used by the token service provider to apply domain restrictions or other controls during transaction processing. The token vault may be a part of the token service system. In some embodiments, the token vault may be provided as a part of the token service provider. Alternatively, the token vault may be a remote repository accessible by the token service provider. Token vaults, due to the sensitive nature of the data mappings that are stored and managed in them, may be protected by strong underlying physical and logical security.

[0023] An "identification and verification (ID&V) method" may be used to ensure that a token is replacing a PAN that was legitimately being used by the token requestor. Examples of ID&V methods may include, but are not limited to, an account verification message, a risk score based on assessment of the primary account number (PAN) and use of one time password by the issuer or its agent to verify the account holder.

Exemplary ID&V methods may be performed using information such as a user signature, a password, an offline or online personal identification number (PIN), an offline or online enciphered PIN, a combination of offline PIN and signature, a combination of offline enciphered PIN and signature, user biometrics (e.g. voice recognition, fingerprint matching, etc.), a pattern, a glyph, knowledge-based challenge- responses, hardware tokens (multiple solution options), one time passwords (OTPs) with limited use, software tokens, two-channel authentication processes (e.g., via phone), etc. [0024] "Token attributes" may include any feature or information about a token. For example, token attributes may include information that can determine how a token can be used, delivered, issued, or otherwise how data may be manipulated within a transaction system. For example, the token attributes may include a type of token, frequency of use, token expiry date and/or expiry time, a number of associated tokens, a transaction lifecycle expiry date, and any additional information that may be relevant to any entity within a tokenization system. For example, token attributes may include a wallet identifier associated with the token, an additional account alias or other user account identifier (e.g., an email address, username, etc.), a device identifier, an invoice number, etc. In some embodiments, a token requestor may provide token attributes at the time of requesting the generation of tokens. In some embodiments, a network token system, processing network associated with the network token system, an issuer, or any other entity associated with the token may determine and/or provide the token attributes associated with a particular token. [0025] The token attributes may identify a type of token indicating how the token may be used. A token may include a high value token that can be used in place of a real account identifier (e.g., PAN) to generate original and/or subsequent transactions for a consumer account and/or card. Another token type may be a "static" or "dynamic" token type for static and dynamic tokens, respectively.

[0026] A "token presentment mode" may indicate a method through which a token is submitted for a transaction. Some non-limiting examples of the token

presentment mode may include machine readable codes (e.g., quick response code (QRC), barcode, etc.), mobile contactless modes (e.g., near-field communication (NFC) communication), e-commerce remote modes, e-commerce proximity modes, and any other suitable modes in which to submit a token. Tokens may be provided through any number of different methods. For example, in one implementation, a token may be embedded in machine-readable code which may be generated by a wallet provider, mobile application, or other application on mobile device and displayed on a display of the mobile device. The machine readable code can be scanned at the POS through which the token is passed to the merchant. A mobile contactless mode may include passing the token through NFC in a contactless message. An e-commerce remote mode may include submitting a token by a consumer or a wallet provider through an online transaction or as an e-commerce transaction using a merchant application or other mobile application. An e-commerce proximity mode may include submitting a token by a consumer from a wallet application on a mobile device at a merchant location.

[0027] "Tokenization" is a process by which data is replaced with substitute data. For example, an account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a substitute number (e.g. a token) that may be associated with the account identifier. Further, tokenization may be applied to any other-information which may be replaced with a substitute value (i.e., token). Tokenization may be used to enhance transaction efficiency, improve

transaction security, increase service transparency, or to provide a method for third- party enablement.

[0028] "Token exchange" or "de-tokenization" is a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a token with a corresponding primary account number (PAN) that was associated with the token during tokenization of the PAN. Thus, the de-tokenization may refer to the process of redeeming a token for the associated PAN value based on a token-to-PAN mapping stored, for example, in a token vault. The ability to retrieve a PAN in exchange for the associated token may be restricted to specifically authorized entities, individuals, applications, or systems. Further, de-tokenization or token exchange may be applied to any other information. In some embodiments, token exchange may be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request). [0029] A "token domain" may indicate the factors that can be established at the time of token issuance to enable appropriate usage of the token for transactions.

Examples of the token domain may include, but are not limited to, a POS entry mode, and merchant identifiers to uniquely identify where the token can be used. A set of parameters (i.e. token domain restriction controls) may be established as part of token issuance by the token service provider that may allow for enforcing appropriate usage of the token in transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. In some embodiments, the token domain restriction controls may restrict the use of the token at a particular merchant that can be uniquely identified. Some exemplary token domain restriction controls may require the

verification of the presence of a token cryptogram that is unique to a given transaction.

[0030] "Token expiry date" may refer to the expiration date/time of the token that is generated by the token service provider and maintained in the token vault. The token expiry date may be passed among the entities of the tokenization system during transaction processing to ensure interoperability and minimize the impact of

tokenization implementation. The token expiration date may be a numeric value (e.g. a 4-digit numeric value) that is consistent with the industry standards.

[0031] "Token Processing" may refer to transaction processing in which a token is present in lieu of the primary account number (PAN). The token is processed from the point of interaction throughout the network. The token processing further includes using a token vault for de-tokenization of the token in order to complete the transaction. Token processing may span processes that include authorization, capture, clearing, and exception processing. [0032] A "consumer" may include an individual or a user that may be associated with one or more personal accounts and/or consumer devices. The consumer may also be referred to as a cardholder, account holder, or user.

[0033] A "primary account number (PAN)" may be any indication of a primary account. In some embodiments, a PAN may be a variable length, (e.g. 13 to 19-digit) industry standard-compliant account number that is generated within account ranges associated with a BIN by an issuer.

[0034] An "authorization request message" may be an electronic message that is sent to a processing network and/or an issuer of an account to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or a payment account. In some embodiments of the disclosure, an authorization request message may include a payment token, an expiration date, a token presentment mode, a token requestor identifier, a token cryptogram, a token assurance level, and data used to generate the token assurance level. The payment token may include a payment token issuer identifier that may be a substitute for a real issuer identifier for an issuer. An authorization request message may also comprise additional data elements corresponding to "identification information" including, for example, a service code, a CW or CVC (card verification value or code), a dCW or dCVC(dynamic card verification value or code), token cryptogram, an expiration date, etc. An authorization request message may also comprise "transaction information," such as any information associated with a current transaction (e.g. the transaction amount, merchant identifier, merchant location, etc.) as well as any other information that may be utilized in determining whether to identify and/or authorize a payment transaction.

[0035] An "authorization response message" may be an electronic message reply to an authorization request message generated by an issuing financial institution (i.e. issuer) or a processing network. The authorization response message may include an authorization code, which may be a code that an account issuing bank returns in response to an authorization request message in an electronic message (either directly or through the processing network) to the merchant's access device (e.g. POS terminal) that indicates approval of the transaction. The code may serve as proof of authorization. As noted above, in some embodiments, a processing network may generate and/or forward the authorization response message to the merchant.

[0036] A "restrictive zone" may be any area or zone from which certain data is prohibited from being transmitted. In some embodiments, various entities physically located within the restrictive zone may be prohibited from transmitting sensitive data outside of the restrictive zone.

[0037] A "server computer" may typically be a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a

minicomputer cluster, or a group of servers functioning as a unit. The server computer may be associated with an entity such as a processing network, a wallet provider, a merchant, an authentication cloud, an acquirer or an issuer.

[0038] An "authorization server" can include any server operated on behalf of an entity responsible for authorizing transactions. For example, the authorization server may be operated by a payment account issuer. The payment account (which may be associated with one or more payment devices) may refer to any suitable payment account including a credit card account, a checking account, a savings account, a merchant account assigned to a consumer, or a prepaid account.

[0039] A "processing network" or "transaction processing network" may refer to an electronic transaction processing system used to accept, transmit, or process transactions made by payment devices for money, goods, or services. The processing network may transfer information and funds among issuers, acquirers, merchants, and payment device users.

[0040] FIG. 1 depicts an illustrative example of a system and a flow diagram providing an overview of the various entity interactions within a tokenization system 100 in accordance with at least some embodiments. The system 100 depicted in FIG. 1 is capable of implementing one or more embodiments of the disclosure disclosed herein in order to enable a tokenization system to operate inside and outside of a restrictive zone.

[0041] In FIG. 1 , a restrictive zone 102 may include a geographic region in which a number of the components of the system 100 are physically located. In some embodiments, the system 100 may include local (located within the restrictive zone 102) and external (located outside the restrictive zone 102) counterparts. For example, a local authorization server 104 may be a server operated by an authorization entity that is located within the restrictive zone 102 whereas an external authorization server 106 may be a server operated by an authorization entity that is located outside of the restrictive zone 102. Likewise, a local transport computer 108 may be a computing device operated by an acquirer entity that is located within the restrictive zone 102 whereas an external transport computer 1 10 may be a computing device operated by an acquirer entity that is located outside of the restrictive zone 102. A local resource provider 1 12 may be any resource provider physically located within the restrictive zone 102 whereas an external resource provider 1 14 may be any resource provider physically located outside of the restrictive zone 102. Additionally, a processing network server 1 16 which is located outside of the restrictive zone 102 may be in communication with a processing network proxy 1 18 which is located within the restrictive zone 102. Additionally, the processing network server 1 16 may be in communication with a token service provider 120, that provides tokenization services. In some embodiments, the token service provider 120 may be operated by the same entity that operates the processing network server 1 16. Additionally, the system 100 may be configured to interact with a number of mobile devices 122. In some embodiments, tokens generated using the system 100 described herein may be provisioned onto a mobile device 122, which may then use the token to conduct a transaction with a resource provider (1 12 or 1 14). [0042] The authorization entity 104 and 106 may each represent a processor of a business entity (e.g., a bank) that may have issued an account (e.g. , credit account, debit account, etc.) for payment transactions. In some embodiments, authorization entity 104 and 106 may each be issuers. In some implementations, the business entity (bank) associated with the authorization entity 104 and 106 may also function as a transport computer (e.g., 108 and 1 10). The authorization entities 104 and 106 may issue an account represented by a primary account number (PAN) to a user upon his or her request. The account holder may then use the account to conduct payment transactions. The authorization entities 104 and 106 may each be responsible for authorization and ongoing risk management within the tokenization system 100. [0043] A user may wish to conduct a payment transaction with a resource provider 1 12 or 1 14 using the account (represented by the PAN) issued by the local authorization server 104. For security purposes discussed herein, the local authorization server 104 may be prohibited from sharing the PAN, or other restricted information, outside of the restrictive zone 102. Accordingly, the system 100 may generate a token to be used in accordance with described embodiments. The token may be generated by a token service provider 120.

[0044] According to various embodiments, when the token service provider 120 issues a token for a PAN associated with an account, a user may not be aware that the token has been issued to represent the account. In some embodiments, the token may be provided to a mobile application installed upon, and executed from, the mobile device 122. In some embodiments, the user may be asked to participate in the identification and verification (ID&V) process during an enrollment process. For example, the user may be asked to provide an identification information to ensure that the token is being created for an account rightfully owned by the user.

[0045] In accordance with at least some embodiments, the system may implement a process flow in which transactions may be conducted inside and outside of a restrictive zone 102. When an account is opened with a local authorization server 104 via an enrollment request, the processing network proxy (which is located within the restrictive zone 102) may remove sensitive data from the enrollment request and may provide an authorized subset of data to the processing network server 1 16. In some embodiments, the processing network proxy 1 18 may include an intermediary token in the request in order to map the request to the newly-created account. In some embodiments, the user may have the ability to provide consent to send one or more restricted pieces of information. For example, the user may consent to sending a PAN outside of the restrictive zone 102, in which case the PAN may be provided in the request.

[0046] Once the processing network server 1 16 receives the enrollment request from the processing network proxy 1 18, a token may be generated by the token service provider 120. This token may be stored in a token vault in relation to the intermediary token. In some embodiments, the intermediary token may be format preserving. The token may then be passed back to the processing network proxy 1 18, which may then associate the token with the opened account. In some embodiments, the token is then provisioned onto a mobile device 122 associated with the newly-opened account. For example, the token may be provided to an ewallet application installed on the mobile device 122. [0047] In accordance with embodiments of the disclosure, the token may then be used either within the restrictive zone 102 or outside of the restrictive zone 102. When the token is presented within the restrictive zone 102, the token is routed via the processing network proxy 1 18 in order to complete the transaction. When the token is presented outside of the restrictive zone 102, the token is routed to the processing network server 1 16, where the token service provider 120 provides the intermediary token (or PAN if consent was given). In some cases, the intermediary token acts as a PAN and causes the processing network server 1 16 to route an authorization request that includes the token to the processing network proxy 1 18 as if it were the

authorization entity for the transaction. Once the authorization request message arrives at the processing network proxy 1 18, the processing network proxy 1 18 may identify the PAN associated with the account and may generate a second authorization request message that includes the PAN. The second authorization request message may be forwarded to the local authorization server 104 for approval. [0048] The local authorization server 104 may generate an authorization response message indicating whether the transaction is approved or declined. Upon receiving the authorization response message from the local authorization server 104, the processing network proxy 1 18 may generate a second authorization response message with the PAN (and other sensitive information) removed that includes the token. The processing network proxy 1 18 then transmits the second authorization response message to the processing network server 1 16, which causes the transaction to be either completed or declined based on the response.

[0049] For clarity, a certain number of components are shown in FIG. 1 . It is understood, however, that embodiments of the disclosure may include more than one of each component. In addition, some embodiments of the disclosure may include fewer than or greater than all of the components shown in FIG. 1 . In addition, the components in FIG. 1 may communicate via any suitable communication medium (including the internet), using any suitable communication protocol.

[0050] FIG. 2 depicts an example system architecture that may be implemented to enable transactions to be conducted in accordance with embodiments of the disclosure. In FIG. 2, a processing network proxy 202 may be in communication with a number of client devices 204 and local authorization servers 206 via a connection to a network 208. The processing network proxy 202 may also be in communication with a processing network server 210 which is operated by an entity affiliated with the processing network proxy 202. The processing network server 210 may further be in communication with a number of external authorization servers 212. The network 208 may include some combination of interconnected electronic devices capable of routing communications between the electronic devices. In some embodiments, the processing network proxy 202 may be an example processing network proxy 1 18 of FIG. 1 .

[0051] In at least some embodiments, the processing network proxy 202 may include at least one memory 214 and one or more processing units (or processor(s)) 216. The processor(s) 216 may be implemented as appropriate in hardware, computer- executable instructions, firmware or combinations thereof. Computer-executable instruction or firmware embodiments of the processor(s) 216 may include computer- executable or machine executable instructions written in any suitable programming language to perform the various functions described.

[0052] The memory 214 may store program instructions that are loadable and executable on the processor(s) 216, as well as data generated during the execution of these programs. Depending on the configuration and type of processing network proxy 202, the memory 214 may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.). The processing network proxy 202 may also include additional storage 218, such as either removable storage or non-removable storage including, but not limited to, magnetic storage, optical disks, and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the processing network proxy 202. In some embodiments, the memory 214 may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM) or ROM.

[0053] Turning to the contents of the memory 214 in more detail, the memory 214 may include an operating system and one or more application programs or services for implementing the features disclosed herein including at least a module for routing received authorization request messages to an appropriate authorization server

(request routing module 220) and a module for handling interactions with devices external to the restrictive zone (external transaction module 222). The memory 214 may also include PAN/token data 224, which stores mappings between primary account numbers and tokens generated with respect to those primary account numbers.

Additionally, the processing network proxy 202 may include any number of modules for enabling additional functionality.

[0054] In some embodiments, the request routing module 220 may, in conjunction with the processor 216, be configured to identify an appropriate

authorization entity to be associated with a received authorization request message and route the authorization request message to an authorization server (e.g., authorization server 206 or 212) operated by that authorization entity. In some embodiments, the request routing module 220 may be further configured to determine whether the authorization entity is an external authorization entity or a local authorization entity. In some embodiments, upon determining that the authorization entity is a local authorization entity, the request routing module 220 may be configured to route the authorization request message to that authorization entity. In some embodiments, upon determining that the authorization entity is an external authorization entity, the request routing module 220 may be configured to initiate the external transaction module 222 to process the authorization request message. The request routing module 220 may then be configured to route the authorization request message to an external processing network server 210 to be routed to the determined authorization entity.

[0055] In some embodiments, the external transaction module 222 may, in conjunction with the processor 216, be configured to receive an authorization request message including restricted data and generate a replacement authorization request message without restricted data. To do this, the external transaction module 222 may identify restricted data within the authorization request message and may replace that restricted data with unrestricted data. For example, upon identifying a primary account number in the authorization request message, the external transaction module 222 may identify a token mapped to that primary account number. The external transaction module 222 may then generate a new authorization request message that includes the token in place of the primary account number. In some embodiments, the external transaction module 222 may be configured to nullify or delete a number of restricted data values within the authorization request message.

[0056] The processing network proxy 202 may also contain communications interface(s) 230 that enable the processing network proxy 202 to communicate with a stored database, another computing device or server, one or more remote devices, other application servers, and/or any other suitable electronic devices. In some embodiments, the communication interface 230 may enable the processing network proxy 202 to communicate with other electronic devices on a network (e.g., on a private network). The processing network proxy 202 may also include input/output (I/O) device(s) and/or ports 232, such as for enabling connection with a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc.

[0057] The client device 204 may be any electronic device capable of

communicating with other electronic devices. For example, the client device 204 may be a mobile phone capable of wirelessly communicating with a processing network proxy 202, a processing network server 210, an external authorization server 212, and/or a local authorization server 206 (e.g., via network 208). In some embodiments, the mobile device 122 depicted in FIG. 1 may be an example of a client device 204. In some embodiments, the client device 204 may have installed upon it a number of software applications. One or more of the software applications installed on the client device 204 may cause the client device 204 to transmit an account identifier (e.g., a token) to an access device (e.g., a point-of-sale terminal).

[0058] The processing network server 210 may be any electronic device capable of routing authorization requests to an appropriate authorization server. In some embodiments, the processing network server 210 may be a network node within a processing network. In some embodiments, the processing network server 210 may maintain a database of PAN/token data 226. In some embodiments, the PAN/token data 224 of the processing network proxy 202 may be updated from the PAN/token data 226 on the processing network server 210. In some embodiments, the PAN/token data 224 may be updated each time that the PAN/token data 226 is updated. In some

embodiments, the PAN/token data 224 may be updated on a periodic basis.

[0059] In some embodiments, the local authorization server 206 and/or the external authorization server 212 may be examples of local authorization server 104 and external authorization server 106 depicted in FIG. 1 respectively, which may be configured to authorize transactions associated with payment devices. The

authorization server may maintain a number of accounts, at least one of which may be an account associated with a user and/or client device 204.

[0060] FIG. 3 depicts a swim lane diagram illustrating an enrollment process that may be performed in accordance with at least some embodiments. In accordance with embodiments of the disclosure, the process 300 may involve at least the mobile device 122, a local authorization server 104, a processing network proxy 1 18, and a processing network server 1 16.

[0061] At 302 of process 300, a user may elect to enroll in an implementation of the system described herein. In some embodiments, the user may access a website or other network page via the mobile device 122. For example, the user may access a website operated on behalf of the local authorization server 104 and apply for an account (e.g., a credit line). In some embodiments, the user may install and access a mobile application on the mobile device 122 such as a mobile wallet application (an e- wallet application).

[0062] At 304, the local authorization server 104 may create an account for the user. The local authorization server 104 may transmit a primary account number (PAN) for the new account to the processing network proxy 1 18. In some embodiments, the processing network proxy 1 18 may create a request for a token at 306. The request may include an intermediary token. In some embodiments, the request may include the PAN (if the user has consented to providing it), but may otherwise be devoid of any sensitive information.

[0063] At 308, the processing network proxy 18 may transmit the request to the processing network server 1 16. In some embodiments, the transmission may be made via a secure connection (e.g., a VPN tunnel). In some embodiments, the transmission may be made over a private network connection.

[0064] At 310, the processing network server 1 16 may generate a token to be associated with the enrollment request. In some embodiments, the token may be generated by a token service provider. Once generated, the token may be stored by the processing network server 1 16 in relation to the new account. In some embodiments, the processing network server 1 16 may also store the intermediary token or the received PAN (if the PAN was sent).

[0065] At 312 the processing network server 1 16 may transmit the generated token to the processing network proxy 1 18. The processing network proxy 1 18 may then store the generated token in relation to the new account. In some embodiments, at 314, the processing network proxy 1 18 may provide the token to the mobile device 122 along with instructions that cause the token to be provisioned onto the mobile device 122. In some embodiments, the processing network proxy 1 18 may not forward the token to other entities.

[0066] FIG. 4 depicts a swim lane diagram illustrating a process for enabling a transaction to be conducted within a restrictive zone that may be performed in accordance with at least some embodiments. The process 400 is depicted as involving only components located within the restrictive zone 102. For example, the process 300 may be initiated with respect to a transaction that includes a payment device associated with the a local authorization server 104 and which is conducted at a resource provider physically located within the restrictive zone 102. The mobile device may be capable of communicating with a local resource provider 1 12, which may, in turn, be in

communication with a local transport computer 108. The local transport computer 108 may communicate with a processing network proxy 1 18 to obtain authorization for a transaction.

[0067] Process 400 may begin at 402, when the local resource provider 1 12 receives a request to conduct a transaction from the mobile device 122. In some embodiments, the mobile device 122 may be presented for payment at a point of sale (POS) terminal within a retail location of the local resource provider 1 12. In some embodiments, a payment device (e.g., an account identifier or token representing an account identifier) may be presented for payment via the mobile device. In some embodiments, the token generated using the process described above with respect to FIG. 3 may be presented using an e-wallet application installed upon the mobile device 122.

[0068] Once the local resource provider 1 12 has received the request to complete the transaction, it may transmit the request (including the payment device or token) to the local transport computer 108 at 404. An authorization request message for the transaction may then be generated, which may be routed to the processing network proxy 1 18 via a network connection at 406.

[0069] Upon receiving the request, the processing network proxy 1 18 may determine that the request is associated with an account maintained by a local authorization server 104. In some embodiments, this may involve the use of a look-up table to identify a status of the PAN from the request or the associated token. In the case that the authorization request includes a token, the processing network proxy 1 18 may generate a new authorization request message during a de-tokenization process that includes the PAN in place of the token. The processing network proxy 1 18 may then send the new authorization request message to the local authorization server 104 at 408.

[0070] If the processing network proxy 1 18 determines that the request is associated with an account maintained by an external authorization server (e.g., authorization server 106 of FIG. 1 ), then the processing network proxy 1 18 may generate a new authorization request message that includes the token generated using the process described above with respect to FIG. 3. The newly generated authorization request may be devoid of a number of sensitive data fields and may include only basic transaction information (e.g., an amount, a resource provider identifier, etc.). The processing network proxy 1 18 may transmit the new authorization request message to an external processing network server (e.g., processing network server 1 16 of FIG. 1 ) to be further processed. This embodiment is described in greater detail with respect to the process depicted in FIG. 6 below. [0071] In the embodiment in which the request is determined to be associated with an account maintained by a local authorization server 104, the processing network proxy 1 18 may route the request to that local authorization server 104. The local authorization server 104 may determine whether to approve or decline the transaction at 410. For example, the local authorization server 104 may determine whether the account has sufficient funds to cover an amount of the transaction. Upon determining whether to approve or decline the transaction, the local authorization server 104 may generate an authorization response message, which it may transmit back to the processing network proxy 1 18 at 412.

[0072] Upon receiving the authorization response message from the local authorization server 104, the processing network proxy 1 18 may transmit the new authorization response message to the local transport computer 108 at 414, which may, in turn, forward the authorization response message to the local resource provider 1 12 at 416. In embodiments in which the authorization request message received at 406 includes a token, the process 400 may involve generating a new authorization response message by replacing the PAN in the current authorization response message with the token from the authorization request message. Upon receiving the authorization response message, the local resource provider 1 12 may determine whether to complete the transaction based on whether the transaction is approved or declined. [0073] FIG. 5 depicts a swim lane diagram illustrating a process for enabling transactions to occur outside of a restrictive zone that may include an account maintained by an authorization server within the restrictive zone which may be performed in accordance with at least some embodiments. The process 500 may involve an interaction between at least some components located outside of the restrictive zone 102 as well as at least some components located within the restrictive zone 102. For example, a mobile device 122 that includes a token associated with the system may be used to conduct a transaction at an external resource provider 1 14. The external resource provider 1 14 may be in communication with an external transport computer 1 10. The external transport computer 1 10 may communicate with a processing network server 1 16 in order to obtain authorization for a transaction. The processing network server 1 16, located outside of the restrictive zone 102, may be in communication with a processing network proxy 1 18 which is located within the restrictive zone 102. The processing network proxy 1 18, in turn, may be in

communication with a local authorization server 104 which is associated with a token provisioned onto the mobile device 122 (e.g., the token generated using the process described above with respect to FIG. 3).

[0074] Process 500 may begin at 502, when the external resource provider 1 14 receives a request to conduct a transaction from the mobile device 122. In some embodiments, the mobile device 122 may be presented for payment at a point of sale (POS) terminal within a retail location of the external resource provider 1 14. The token may be presented using an e-wallet application installed upon the mobile device 122.

[0075] Once the external resource provider 1 14 has received the request to complete the transaction, it may transmit the request (including the token) to the external transport computer 1 10 at 504. An authorization request message for the transaction may then be generated, which may be routed to the processing network server 1 16 via a network connection at 506.

[0076] Upon receiving the authorization request message, the processing network server 1 16 may determine that the token is associated with the local authorization server 104 within the restrictive zone 102 at 508. In some embodiments, this determination may be made based on a format or structure of the token. In some embodiments, the processing network server 1 16 may identify an account associated with the token during an enrollment process (described above with respect to FIG. 3) and may determine, based on information related to the account, that the token is associated with the authorization server 104. Upon determining that the token is associated with an authorization server within the restrictive zone 102, the processing network server 1 16 may transmit the authorization request message to the processing network proxy 1 18 within the restrictive zone 102 at 510.

[0077] Upon receiving the authorization request message, the processing network proxy 1 18 may determine that the token is associated with a local authorization server 104. In some embodiments, this may involve the use of a look-up table to identify the actual PAN associated with the token. During a de-tokenization process, the processing network proxy 1 18 may generate a new authorization request message that includes the PAN in place of the token. The processing network proxy 1 18 may then send the new authorization request message to the local authorization server 104 at 512.

[0078] The local authorization server 104 may determine whether to approve or decline the transaction at 514. For example, the local authorization server 104 may determine whether the account has sufficient funds to cover an amount of the transaction. Upon determining whether to approve or decline the transaction, the local authorization server 104 may generate an authorization response message, which it may transmit back to the processing network proxy 1 18 at 516. [0079] Upon receiving the authorization response message from the local authorization server 104, the processing network proxy 1 18 may generate a new authorization response message by replacing the PAN in the current authorization response message with the token and removing any sensitive information at 518. The processing network proxy 1 18 may then transmit the new authorization response message to the processing network server 1 16 at 520, which may, in turn, forward the authorization response message to the external transport computer 1 10 at 522 and subsequently to the external resource provider 1 14 at 524. Upon receiving the authorization response message, the external resource provider 1 14 may determine whether to complete the transaction based on whether the authorization response message indicates that the transaction should be approved or declined.

[0080] FIG. 6 depicts a swim lane diagram illustrating a process for enabling a transaction to be conducted within a restrictive zone that may include an account maintained by an authorization server outside of the restrictive zone which may be performed in accordance with at least some embodiments. The process 600 is depicted as involving components located within the restrictive zone 102 as well as components which are external to the restrictive zone 102. For example, the process 300 may be initiated with respect to a transaction that includes a payment device associated with the external authorization server 104 and which is conducted at a resource provider physically located within the restrictive zone 102. The transaction may be initiated via a mobile device 122 located within a physical proximity of the local resource provider 1 12. The mobile device 122 may be capable of communicating with the local resource provider 1 12 (e.g., via wireless communication), which may, in turn, be in

communication with a local transport computer 108. The local transport computer 108 may communicate with a processing network proxy 1 18 to obtain authorization for a transaction.

[0081] In process 600, the mobile device 122 may have provisioned upon it a token to be used in completing transactions. In some embodiments, the token may be received from an authorization server (local or external) with whom a user of the mobile device 122 maintains an account. In some embodiments, the token may be received from a processing network server (local or external) which provides transaction routing for the authorization server. The token may be provisioned onto the mobile device 122 before the transaction is conducted. In some cases, the token may be provisioned onto the mobile device 122 before the mobile device 122 is brought into or out of the restrictive zone 102. In some embodiments, the authorization server or processing network server may distribute token-account mappings to each processing network proxy 1 18 located within a restrictive zone.

[0082] Process 600 may begin at 602, when the local resource provider 1 12 receives a request to conduct a transaction from the mobile device 122. In some embodiments, the mobile device 122 may be presented for payment at a point of sale (POS) terminal within a retail location of the local resource provider 1 12. In some embodiments, a payment device (e.g., an account identifier or token representing an account identifier) may be presented for payment via the mobile device. In some embodiments, the token generated using the process described above with respect to FIG. 3 may be presented using an e-wallet application installed upon the mobile device 122. [0083] Once the local resource provider 1 12 has received the request to complete the transaction, it may transmit the request (including the payment device or token) to the local transport computer 108 at 604. An authorization request message for the transaction may then be generated, which may be routed to the processing network proxy 1 18 via a network connection at 606.

[0084] Upon receiving the request, the processing network proxy 1 18 may determine that the request is associated with an account maintained by a

an external authorization server (e.g., authorization server 106 of FIG. 1 ). 1 608, upon making this determination, the processing network proxy 1 18 may generate a new authorization request message that includes the token generated using the process described above with respect to FIG. 3. The newly generated authorization request may be devoid of a number of sensitive data fields and may include only basic transaction information (e.g., an amount, a resource provider identifier, etc.). The processing network proxy 1 18 may transmit the new authorization request message to an external processing network server 1 16 to be further processed at 610. In the event that the processing network proxy 1 18 determines that the request is associated with an account maintained by a local authorization server (e.g., authorization server 104 of FIG. 1 ), the processing network proxy 1 18 may route the authorization request message to the local authorization server as described with respect to process 400 depicted above.

[0085] Upon receiving the request from the processing network proxy 1 18, the processing network server 1 16 may identify an account associated with the token in the request at 612. In some embodiments, the processing server 1 16 may generate a new authorization request message that includes an identifier the identified account as well as additional transaction details included in the original authorization request message. Upon generating the new authorization request, the processing network server 1 16 may route the generated authorization request to an appropriate external authorization server 106 at 614.

[0086] The external authorization server 106 may determine whether to approve or decline the transaction at 616. For example, the external authorization server 106 may determine whether the account has sufficient funds to cover an amount of the transaction. Upon determining whether to approve or decline the transaction, the external authorization server 106 may generate an authorization response message, which it may transmit back to the processing network server 1 16 at 618.

[0087] Upon receiving the authorization response message from the external authorization server 106, the processing network server 1 16 may generate a new authorization response message by replacing the token in the current authorization response message in place of the PAN and removing any sensitive information at 620. The processing network server 1 16 may then transmit the new authorization response message to the processing network proxy 1 18 at 622, which may, in turn, forward the authorization response message to the local transport computer 108 at 624 and subsequently to the local resource provider 1 12 at 626. Upon receiving the authorization response message, the local resource provider 1 12 may determine whether to complete the transaction based on whether the authorization response message indicates that the transaction should be approved or declined.

[0088] FIG. 7 depicts a flow diagram illustrating a process for conducting transactions between components located inside and outside of a restrictive zone in accordance with at least some embodiments. A restrictive zone may comprise a geographic area from which the sensitive information is prohibited from being transmitted. At least a portion of the process 700 may be performed by a processing network server and a portion of the process 700 may be performed by a processing network proxy. Examples of a processing network server and a processing network proxy are described in FIG. 2 with respect to processing network server 210 and a processing network proxy 202 respectively.

[0089] Process 700 may begin at 702, when a transaction request is received from a resource provider. In some embodiments, the transaction request may be an authorization request message. The transaction request may be received by a processing network server located external to the restrictive zone. The transaction request may include a token. In some embodiments, the token may be provisioned onto a mobile device, and wherein the mobile device is used to conduct a transaction related to the authorization request message [0090] At 704, the process may involve determining that the transaction request is associated with a restrictive zone. In some embodiments, the transaction request may be determined to be associated with the restrictive zone based on a format of the token. In some embodiments, an indication of the association between the token and the restrictive zone is stored in a database, and the token is determined to be associated with the restrictive zone based on querying the database.

[0091] At 706, the process may involve identifying a local proxy within the restrictive zone. In some embodiments, each restrictive zone may be associated with a local proxy for that restrictive zone. The local proxy for a particular restrictive zone may be physically located somewhere within that restrictive zone. A local proxy may be identified by virtue of that local proxy being associated with the restrictive zone. At 708, the process may involve transmitting the transaction request to the identified local proxy. [0092] At 710, the process may involve causing the local proxy to perform a subprocess in which the local proxy obtains an authorization status for the request. At 710(A), the subprocess may involve identifying an authorization server. In some embodiments, the local proxy may map the token in the authorization request message to a primary account number. In some embodiments, an appropriate authorization server may be identified based on a format of the primary account number.

[0093] At 710(B), the subprocess may involve routing the transaction request to the identified authorization server. At 710(C), the subprocess may involve receiving a response from the authorization server and removing any restricted data from that response. In some embodiments, the subprocess may further involve removing any restricted data from the received response. For example, the local proxy may replace the primary account number within the received response with the token.

[0094] At 710(D), the subprocess may involve forwarding the amended response to the processing network server. The processing network server may then continue with process 700 upon receiving the response. At 712, the process may involve forwarding the received response to an originator of the request.

[0095] Embodiments of the disclosure provide for a number of advantages over conventional systems. For example, in conventional systems, transactions that relate to accounts maintained by an authorization server within a restrictive zone cannot generally be used to conduct transactions outside of that restrictive zone and vice versa. In embodiments of the described system, such transactions may be conducted without requiring any architectural changes in the existing systems used by resource providers. The system enables transactions to be conducted seamlessly, regardless of where the account is maintained (inside of or outside of a restrictive zone).

[0096] As described, the inventive service may involve implementing one or more functions, processes, operations or method steps. In some embodiments, the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0097] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

[0098] While certain exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not intended to be restrictive of the broad disclosure, and that this disclosure is not to be limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those with ordinary skill in the art.

[0099] As used herein, the use of "a", "an" or "the" is intended to mean "at least one", unless specifically indicated to the contrary.