110 may then continue to service the account using the actual account identifier. For example, in some implementations, processing server 110 may receive a request from a client device to update an account to reflect an action performed on the account. The request may include a network address of the client device but not the actual account identifier. Processing server 110 may access credential vault 160 and convert the network address into the actual account identifier. Processing server 110 may then send an account update message with the actual account identifier to the corresponding account issuer to update the account.

FIG. 2 illustrates a communication flow diagram of a provisioning process, according to some implementations. At operation 202, processing server 210 may submit a request to network authority 270 to obtain a set of network addresses to allocate to processing server 210. In some implementations, processor server 210 may request a particular number of network addresses based on, for example, the processing capacity of processing server 210. For example, if processing server 210 is expected to service up to one million different accounts, processing server 210 may request one million network addresses from network authority 270. In some implementations such as those in which the network address adhere to the Internet protocol such as IPv6, the IP addresses allocated to processing server 210 can be dedicated to processing server 210 such that these addresses are not reused on the Internet. In this manner, the IP addresses allocated to processing server 210 will not interfere with the global routing of Internet traffic to and from existing IP addresses.

At operation 204, network authority 270 may determine a set of network addresses to allocate to processing server 210. The set of network addresses may include one or more address ranges. In some implementations, the network address may include a routing prefix field, a subnet identifier field, and an interface identifier field. Individual account identifiers can be obfuscated in the interface identifier field, and issuer identifiers can be obfuscated in the routing prefix field. Thus, depending on the number of issuers supported by processing server 210, network authority 270 may allocate that number of specific routing prefixes to processing server 210. For each allocated routing prefix, processing server 210 can assign network addresses starting with the specific routing prefix to accounts issued by the corresponding issuer.

At operation 207, a client device 222 can be activated by establishing a connection to communication device 224, and initiating a provisioning process to obtain a network address from processing server 210 via communication device 224. In some implementations, client device 222 can be issued with a preloaded account identifier. In some implementations, an application on communication device 224 may detect the presence of client device 222, and may request a user to provide an account identifier that the user would like to use for provisioning client device 222. Once an account identifier for client device 222 has been determined, communication device may request the user to provide additional security data such as authentication information to verify that the user is the proper owner of the account. The security data may include personal identification information such as a PIN or other information that a user previously registered with the issuer when the user obtained the account.

At operation 208, communication device 224 may initiate a network address request on behalf of client device 222. The network address request may include the account identifier of the account associated with the client device and other account identifying information such as information to identifier the issuer of the account. The network address request may also include security data that the issuer of the account may require to verify the authenticity of the account. In some implementations, communication device 224 may send the network address request to processing server 210 without an intermediary entity. Alternatively, communication device 224 may send the network address request to processing server 210 via a trusted requester (not shown) such as an operating system provider, mobile network provider, or communication device provider.

At operation 212, processor server 210 may verify that the account identifier in the network address request is a valid account supported by processing server 210, and forward the network address request to account issuer 242 to verify the authenticity of the network address request. Processing server 210 may determine the issuer, for example, by examining the account information provided in the network address request. In some implementations, processing server 210 may also provide additional information to account issuer 242 to facilitate the issuer verification process. The additional information may include account activity data such as the number of prior provisioning requests that have been processed for this account, and/or device information of communication device 224 and/or client device 222 to verify that these devices belong to the same owner as the account.

At operation 214, account issuer 242 may perform an issuer verification process on the network address request. This may include verifying that the account identifier corresponds to a valid account in good standing, the security data such as a PIN and other personal identification information submitted with the request corresponds to the information previously registered with account issuer 242, the communication device 224 and/or client device 222 belong to the same owner as the account based on previously registered device information, and/or there are no suspicious activity on the account such as an excessive number of previously received provisioning requests, etc. Once account issuer 242 has verified the account and the network address request, account issuer 242 may send a provisioning approval message to processing server 210 to indicate that processing server 210 can proceed with provisioning client device 222 with a network address. If the network address request is not verified, account issuer 242 may send a provisioning denial message to processing server 210 to terminate the provisioning process.

At operation 216, processing server 210 may select a network address from the network addresses allocated to processing server 210 by network authority 270. As mentioned above, the network address may include a routing prefix field and an network interface identifier field, and an issuer identifier can be embedded as a routing prefix, and the account identifier can be embedded as an interface identifier in the network interface identifier field of the network address. For example, processing serve 210 may select a network address having a routing prefix that corresponds to the issuer of the account being provisioned. To obfuscate the account identifier in the network address, processing server 210 may randomly select an interface identifier, and map the selected interface identifier to the account identifier. Processing server 210 may also sequentially select the next available interface identifier under the corresponding issuer in the order in which provisioning requests are received for this issuer, and map the next available interface identifier to the account identifier. In some implementations, processing server 210 may algorithmically derive the interface identifier from the account identifier. For example, processing server 210 may encrypt the account identifier to derive the interface identifier. Processing server 210 may also perform a series of mathematically operations on the account identifier to derive the interface identifier. Processing server 210 may then combine the routing prefix with the selected interface identifier to generate the network address for provisioning to client device 222. In some implementations, a subnet identifier can also be included in the generated network address. The subnet identifier can be used to embed other account information, or be used by processing server 210 to indicate processing control information when processing actions performed on the account.

In some implementations, processing server 210 may also provision a token to client device 222. A token can be used as a substitute for the account identifier in scenarios in which the network address may not be used for that purpose. This may occur, for example, when legacy infrastructure does not support embedding credentials in network addresses, or when client device 222 is being used in an environment in which client device 222 is communicating using a different mechanism than network packets. Processing server 210 may randomly select a token and map it to the account identifier, or derive the token algorithmically from the account identifier (e.g., using encryption or mathematical operations, etc.). Processing server 210 may then store the selected network address and/or token in a credential vault (not shown), and maintain a mapping of the network address and/or token with the account identifier.

At operation 216, processing server 210 may send the selected network address and/or token to communication device 224. At operation 218, communication device 224 may provision client device 222 with the received network address and/or token. This may include storing the network address and/or token in a secured memory of client device 222 such as a secure element, and may also include accessing a network communication stack of client device 222 to assign the received network address to client device 222. Once client device 222 has been provisioned with the network address and/or token, client device 222 can be used to perform actions on the account associated with client device 222. In some implementations, depending on the environment in which client device 222 is being used, client device may select between the actual account identifier, the token, and/or the network address to provide to another device to identify the underlying account associated with client device 222.

FIG. 3 illustrates the data structure of a network address, according to some implementations. The network address may include a routing prefix field 302, a subnet identifier field 304, and a network interface identifier field 306. For example, the network address can be a 128-bit IP address that adheres to the IPv6 protocol. Routing prefix field 302 can be a 48-bit field, subnet identifier field 304 can be a 16-bit field, and network interface identifier field 306 can be a 64-bit field. It should be understood that depending on the network in which the techniques disclosed herein are implemented, the number of bits in each field can be varied. The network address may also include one or more field not specifically described, or omit one or more fields described herein.

Routing prefix field 302 can be used by network equipment to properly identify the source or destination of a network packet, and to properly route the network packet to the intended recipient through a global network. In some implementations, an issuer identifier corresponding to an issuer of an account can be embedded in routing prefix field 302. As a processing server (e.g., processing server 110 or 210) may process accounts from different issuers, multiple distinct routing prefixes can be allocated to the processing server for assignment to client devices. When network equipment receives a network packet having a destination address that includes one of the allocated routing prefixes, the network equipment can determine that the network packet is intended for a client device provisioned by the processing server, and route the network packet to the proper client device as identified by the network address of the client device. In some implementations, the processing server may have its own assigned routing prefix to allow the client devices to send network packets to the processing server. In some implementations, in addition to an issuer identifier, a processor control record identifier and/or a processing station identifier can also be embedded into the routing prefix field 302. The processor control record identifier and/or a processing station identifier can be used to identify the proper processing server associated with a client device that supports servicing the account of the client device.

Subnet identifier field 304 can be used for various purposes. For example, subnet identifier field 304 can be used to define different categories or types of accounts under each issuer. The subnet identifier filed 304 can also be used to provide processing control information to define processing options when servicing the account associated with the client device. In some implementations, the number of bits in subnet identifier field 304 can be reduced to provide additional data bits for the routing prefix field 302 if additional distinct routing prefixes are needed for the system. The subnet identifier field 304 can also be optional and can be omitted to provide additional data bits for routing prefix field 302 and/or network interface identifier field 306.

Network interface identifier field 306 can be used to identify the specific client device that has been provisioned with the network address. Network interface identifier field 306 may contain an interface identifier that maps to the account identifier of the account associated with the client device. The interface identifier can be used to obfuscate the actual account identifier. In some implementations, the interface identifier for a particular account can be randomly selected by the processing server or be sequentially selected based on the order in which provisioning requests are received by the processing server. Alternatively, the interface identifier can be algorithmically derived by applying encryption and/or other mathematical operations on the actual account identifier. The interface identifier may also include one or more check bits that are used as a parity or checksum to verify the integrity of the interface identifier. In some implementations, the number of data bits in network interface identifier field 306 may allow for more than one billion accounts to be mapped to a distinct interface identifier.

FIG. 4 illustrates the concept of account ranges that can be implemented using the network addresses described herein, according to some implementations. For a particular issuer, a set of account ranges can be associated with the issuer. In the example shown in FIG. 4, an issuer may have an issuer identifier of “40001” that is embedded in the routing prefix field of network addresses associated with the issuer. This issuer may have four account ranges as shown. The first account range may span interface identifiers of “000000000” to “000999999”; the second account range may span interface identifiers of “001000000” to “001999999”; the third account range may span interface identifiers of “002000000” to “002999999”; and the fourth account range may span interface identifiers of “003000000” to “003999999”. Each of these interface identifiers can be mapped to a distinct account identifier, and the account identifiers that map to the interface identifiers in an account range can be contiguous or non-contiguous depending on the mapping technique employed by the processing server.

Each account range can be associated with different set of account characteristics and/or product category. Although the combination of account characteristics for each account range is different from the other account ranges, different account ranges may share one or more common characteristics. For example, the first three account range may each correspond to a different account type, but share the same account platform. The first and fourth account ranges may share the same account type but correspond to different account platforms. In some implementations, different account types can be associated with different usage limits and/or services, and different account platforms can be associated with a different category of users. The set of account characteristics may also include other properties depending on the context of the accounts. By way of example, in the context of financial card accounts, an account type may correspond to different card levels such as classic, silver, gold, platinum, signature, etc., having different spending limits and/or account services. An account platform may correspond to a category of users such as consumers, merchants, businesses, etc. In some implementations, the account characteristics may also include a funding source type such as whether the account is a credit or debit account.

By utilizing account ranges to identify different characteristics of an account under an issuer, a processing server can readily determine the properties of the account from the network interface identifier field of the source address of a network packet by determining which account range the interface identifier belongs to. This can eliminate the need to have a separate field in the network address to indicate the account characteristics of a particular account.

FIG. 5 illustrates a communication flow diagram of a process for performing an action on an account using a network address embedded with a credential, according to some implementations. In the example shown in FIG. 5, client devices 522 and 526 have previously been provisioned with respective network addresses that are associated with corresponding accounts. Client device 522 can be the initiating device, and client device 526 can be the target device 526. The action being performed on the account associated with client device 522 can be a transfer from that account to the target account associated with client device 526.

A user operating client device may initiate the action by selecting a target account as the intended recipient of the transfer. The account selection can be performed on a user interface of client device 522 or on a user interface of a communication device tethered to client device 522. The account selection can be carried out, for example, by a user inputting the network address of the target client device 526, selecting an alias such as identifying information (e.g., name, phone number, email, etc.) of the user of target client device 526 from a contacts list or address book that maintains a mapping of client devices and network addresses, clicking on a link or image encoded with the network address of target client device 526, etc. In implementations in which the transfer is of an amount of value, the user may indicate the amount to transfer on a user interface.

At operation 502, client device 522 may transmit an account activity network packet to target client device 526 to perform an action on the account of client device 522. In some implementations, the account activity network packet can be transmitted via a tethered communication device. The account activity network packet may conform to a network protocol such as IPv6, and may include a source address and a destination address in a packet header of the account activity network packet. The source address may correspond to the network address of client device 522, and the destination address may correspond to the network address of target client device 526. The source address of the account activity network packet may include an issuer identifier of issuer 542 of the account of client device 522 in the routing prefix field, and an interface identifier that maps to the account identifier of the account of client device 522 in the network interface identifier field. Similarly, the destination address of the account activity network packet may include an issuer identifier of issuer 544 of the target account of target client device 526 in the routing prefix field, and an interface identifier that maps to the target account identifier of the target account of target client device 526 in the network interface identifier field. The account activity network packet may also include additional information related to the action such as an amount to transfer in the data payload of the network packet. As the relevant information needed to identify the respective accounts are embedded into the source and destination addresses of the packet header, it is not necessary for the account activity network packet to include any account identifiers in the data payload of the network packet.

At operation 504, client device 522 may transmit an activity log network packet to processing server 510 to notify processing server 510 of the action performed on the account of client device 522. The activity log network packet may include a packer header that has a source address corresponding to the network address of client device 522 and a destination address corresponding to the network address of processing server 510. The data payload of the activity log network packet may include account activity data associated with the action performed on the account associated with client device 522 such as an alias identifying the target account and an amount being transferred to the target account.

At operation 506, target client device 526 may transmit an activity log network packet to processing server 510 to notify processing server 510 that target client device 526 has received an account activity network packet from client device 522 affecting the target account of target client device 526. The activity log network packet may include a packer header that has a source address corresponding to the network address of target client device 526 and a destination address corresponding to the network address of processing server 510. The data payload of the activity log network packet may include account activity data associated with the account activity network packet received from client device 522 such as an alias identifying the account of client device 522 and an amount being transferred to the target account.

At operation 508, processing server 510 may determine the issuer and the account identifier of the account associated with the client device 522 based on the source address in the packet header of the activity log network packet sent in operation 504. Processing server 510 may also determine the issuer and the account identifier of the target account associated with the target client device 526 based on the source address in the packet header of the activity log network packet sent in operation 506. For example, processing server 510 may send a query to credential vault 560 to lookup the corresponding issuers and account identifiers using the relevant network address fields in the source addresses of the activity log network packets. At operation 512, credential vault 560 may provide the corresponding issuers and account identifiers of client device 522 and target client device 526 back to processing server 510.

At operation 514, processing server 510 may generate an account update message including the account identifier of the account associated with client device 522 and processing information based on the account activity data in the activity log network packet received in operation 504, and send the account update message to issuer 542. For example, the processing information may include instructions to update the account of client device 522 to deduct the amount being transferred to the target account from the balance of the account of client device 522.

At operation 516, processing server 510 may generate another account update message including the account identifier of the target account associated with target client device 526 and processing information based on the account activity data in the activity log network packet received in operation 506, and send this account update message to issuer 544. For example, the processing information may include instructions to update the target account of target client device 526 to increment the balance of the target account by the amount being transferred.

Upon receiving the account update messages, issuers 542 and 544 can update the corresponding accounts to complete the action initiated by client device 522. In some implementations, for added security, processing server 510 may generated the account update messages only in response to the processing server 510 verifying that the activity log network packets in operations 504 and 506 correspond to each other. For example, processing server 510 may verify that the source address of the activity log network packet in operation 504 maps to the same account as the alias in the data payload of the activity log network packet in operation 506 identifying the account of client device 522. Processing server 510 may also verify that the source address of the activity log network packet in operation 506 maps to the same account as the alias in the data payload of the activity log network packet in operation 504 identifying the target account of target client device 526. Furthermore, processing server 510 may verify that the amount indicated in the data payload of the activity log network packets in operations 504 and 506 are the same. In some implementations, to further mitigate against unauthorized usage of the accounts (e.g., by IP spoofing), the transfer using network addresses as described above can have a ceiling limit such that only transfers in amount less than that ceiling limit are allowed. Additional measures to mitigate against unauthorized usage may include sending an alert if suspicious activities are detect such as an unusual larger number of transfers in a time window being executed to or from a particular network address.

In the example described above with reference to FIG. 5, the account activity network packet including the network addresses associated with the accounts is transmitted between two client devices to perform a transfer between the accounts. In some implementations, client device 522 may transmits the network address of client device 522 to an access device to conduct a transaction using the account associated with client device 522. Such a transaction flow may proceed as described below.

Client device 522 may provide its network address to an access device by sending a network packet to the access device. The access device may capture the source address of the network packet (which contains the network address of client device 522), and provide the network address of client device 522 to an acquirer associated with the access device. The acquirer may forward the network address of client device 522 to processing server 510. Processing server 510 may then access credential vault 560 to look up the account identifier mapped to the network address of client device 522. After processing server 510 obtain the account identifier, processing sever 510 may generate an authorization request message that includes the account identifier of the account associated with client device 522, and send the authorization request message to account issuer 542 to obtain authorization for the transaction. Upon approval, account issuer 542 may send an authorization response message indicating the transaction has been approved back to processing server 510, and processing serve 510 may forward the authorization response message to the acquirer and the access device.

FIG. 6 illustrates a flow diagram of a process 600 that can be performed, for example, by a server computer associated with a service provider for provisioning and processing credentials embedded in a network address, according to some implementations. At block 602, process 600 may begin by receiving a network address request for a client device. The network address request may include an account identifier of an account associated with the client device. At block 604, the network address request can be verified as being authentic. For example, the account identifier and authentication information can be forwarded to the issuer of the account for verification. At block 606, a network address conforming to a network protocol is selected from a set of network addresses allocated to the service provider by a network address assignment authority. At block 608, the selected network address is provisioned to the client device. The network address may include a routing prefix field and a network interface identifier field. The routing prefix field may include an issuer identifier of the issuer, and the network interface identifier field may include an interface identifier that maps to the account identifier. At this point, the client device can be used to perform actions on the account by providing the network address instead of the actual account identifier. In some implementations, a token that acts as a substitute for the account identifier associated with the client device may also be provisioned to the client device in response to verifying that the network address request is authentic.

At block 610, an activity log network packet can be received from the client device. The activity log network packet may include the network address of the client device as a source address in the packet header of the activity log network packet. The activity log network packet may also include account activity data associated with an action performed on the account of the client device in the data payload of the activity log network packet. The action performed on the account can be, for example, a transfer from the account of the client device to a target account associated with a target device. The action can be executed by the client device transmitting an account activity network packet to the target device. The account activity network packet may include the network address of the client device as a source address in the packet header of the account activity network packet, and a network address of the target device as a destination address in the packet header of the account activity network packet. In some implementations, the network address of the target device can be provisioned by the same server computer that provisioned the client device, and the network address of the target device can be selected from the set of network addresses allocated to the service provider associated with the server computer.

At block 612, the issuer and the account identifier of the account associated with the client device can be determined based on the source address in the packet header of the activity log network packet. At block 614, an account update message can be generated. The account update message may include the account identifier of the account associated with the client device, and processing information based on the account activity data received in the activity log network packet. At block 618, the account update message can be transmitted to the issuer to instruct the issuer to update the account associated with the client device based on the processing information.

In some implementations, for example, when the action being performed is a transfer to a target account, an activity log network packet can also be received from the target device. The target device may send the activity log network packet in response to the target device receiving the account activity network packet indicating the transfer from the client device. Similar to the activity log network packet from the client device, an issuer and an account identifier of the target account can be determined based on a source address of the activity log network packet from the target device. An account update message including the account identifier of the target account and processing information associated with the transfer can be generated and transmitted to the issuer of the target account to update the target account associated with the target device based on the processing information. In some implementations, to mitigate against unauthorized activity, the two account update messages can be generated in response to verifying that the activity log network packet from the client device and the activity log network packet from the target device corresponds to the same action being performed on the account associated with the client device. In other words, if either the accounts or the account activity data in the activity log network packets do not match up, the account update messages to the issuers are not generated to prevent the underlying accounts from being updated with potentially unauthorized activity.

FIG. 7 illustrates a flow diagram of a process 700 that can be performed, for example, by a client device for utilizing credentials embedded in a network address, according to some implementations. At block 702, a network address for the client device can be requested by providing an account identifier identifying an account associated with the client device to a server computer associated with a service provider. At block 704, a network address assigned to the client device by the server computer can be received in response to the server computer verifying the account identifier and selecting the network address from a set of network addresses allocated to the service provider by a network address assignment authority. The network address may include a routing prefix field and a network interface identifier field. The routing prefix field may include an issuer identifier of an issuer of the account, and the network interface identifier field may include an interface identifier that maps to the account identifier. In some implementations, a token that can be used as a substitute for the account identifier can also be received from the server computer in response to the server computer verifying the account identifier in the request of block 702. The client device may store the network address, token, and/or account identifier in a secure memory of the client device.

At block 706, the client device may be used to perform an action on the account, and a determination is made as to whether the client device is using the network interface of the client device to perform the action. For example, if input is received on the user interface of the client device or on a user interface of a tethered communication device to send a network packet, then it can be determined that the network interface is being used to perform the action on the account.

If the network interface is being used, then at block 708, an account activity network packet can be transmitted to a target device to perform the action on the account. For example, the action being performed on the account can be a transfer from the account associated with the client device to a target account associated with the target device. The account activity network packet may have a source address corresponding to the network address of the client device, and a destination address corresponding to a network address of the target device. The destination address of the account activity network packet may include a routing field an issuer identifier of an issuer of the target account, and a network interface identifier field having an interface identifier that maps to a target account identifier associated with the target account. Because the relevant accounts can be determined from the source and destination addresses, it is not necessary for the account activity network packet to include the account identifiers of the client and target devices.

At block 710, an activity log network packet can be transmitted to the server computer to update the account of the client device. The activity log network packet may include account activity data associated with the action performed on the account. The server computer can then determine the issuer and the account identifier of the account based on the source address in the packet header of the activity log network packet, and transmit an account update message including the account identifier and processing information based on the account activity data to the issuer. The issuer may then update the account of the client device using the processing information. Because the account of the client device can be determined from the source address of the activity log network packet, it is not necessary for the activity log network packet to include the account identifier of the client device.

Referring back to block 706, if it is determined that the client device is not using the network interface to perform an action on the account, then a determination is made at block 712 as to whether the client device is using the contactless interface of the client device to perform an action on the account. The contactless interface can be, for example, a proximity interface that communicates using a shorter range communication protocol such as near field communications (NFC), Bluetooth, etc. The determination at block 712 can be made, for example, by sensing the presence of a contactless reader of an access device within the proximity of the client device, and interacting with the access device using the contactless interface of the client device. If it is determined that the client device is performing an action on the account using the contactless interface, then at block 714, the token is selected instead of the network address to provide to the access device, and the token is provided to the access device via the contactless interface to perform the action on the account.

If it is determined that the client device is not performing an action on the account using the contactless interface of the network interface, then it is determined that the client device is interacting with an access device using a contact interface of the client device. The contact interface can be, for example, electrical contacts of an integrated circuit chip of the client device, or a magnetic stripe, etc. Then at block 716, the account identifier is selected instead of the network address to provide to the access device, and the account identifier is provided to the access device via the contact interface to perform the action on the account.