Facilitates the transfer of funds between user accounts

Abstract

The present disclosure generally relates to facilitating the transfer of funds between user accounts. Systems, methods, and computer-readable media are provided for facilitating the transfer of funds between user accounts.

Description

[0001] This application is a divisional application of the application with international application number PCT / US2018 / 032931, international application date May 16, 2018, entry into the Chinese national phase date November 20, 2019, national application number 201880033494.X, and invention name “Facilitating the transfer of funds between user accounts”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This patent application claims the benefit of previously filed U.S. Provisional Patent Application No. 62 / 507,026, filed May 16, 2017, which is hereby incorporated by reference in its entirety. Technical Field

[0004] The present disclosure relates to facilitating the transfer of funds between user accounts, including utilizing anonymous recipient tokens to facilitate the transfer of funds between user accounts. Background Art

[0005] Portable electronic devices (e.g., cellular phones and laptop computers) may be provided with a secure element for enabling secure transaction communications with another entity. Typically, these communications are associated with commercial transactions or other secure data transactions that require the electronic device to generate, access, and / or transmit native payment credentials, such as credit card credentials, via a merchant terminal or merchant website to be sent from the secure element to the merchant. However, it is often inefficient for electronic devices to use such native payment credentials in other types of communications (e.g., transfers between two user accounts). Summary of the invention

[0006] This document describes systems, methods, and computer-readable media for facilitating the transfer of funds between user accounts.

[0007] For example, a method is provided that uses a first end-user host electronic device and a second end-user host electronic device and a management entity subsystem to facilitate the transfer of funds between a first fund account of a credential issuer subsystem and a second fund account of the credential issuer subsystem, wherein the first fund account is linked to a first sending token and a first receiving token at the credential issuer subsystem, wherein the second fund account is linked to a second sending token and a second receiving token at the credential issuer subsystem, wherein the first end-user host electronic device is associated with a first social token at the management entity subsystem, and wherein the second end-user host electronic device is associated with a second social token at the management entity subsystem. The method may include, when a first user transaction credential associated with the first fund account is requested for use on the first end-user host electronic device, the management entity subsystem links the first receiving token to the first social token, and the management entity subsystem facilitates the provision of the first sending token to the first end-user host electronic device. The method may also include, when a second user transaction credential associated with the second fund account is requested for use on the second end-user host electronic device, the management entity subsystem links the second receiving token to the second social token, and the management entity subsystem facilitates the provision of the second sending token to the second end-user host electronic device. The method may also include, when requesting to transfer funds, receiving device transfer funds request data from a first end-user host electronic device by a management entity subsystem, the device transfer funds request data including device payment credential data, the device payment credential data including a first sending token and a second social token; identifying the second receiving token by the management entity subsystem as a second social token linked to the received device transfer funds request data; and transmitting the management entity transfer funds request data by the management entity subsystem to the credential issuer subsystem, the management entity transfer funds request data including the identified second receiving token and the first sending token of the received device transfer funds request data.

[0008] As another example, a method is provided for facilitating the transfer of funds between a first fund account of a credential issuer subsystem and a second fund account of a credential issuer subsystem using a first end-user host electronic device and a second end-user host electronic device and a management entity subsystem. The method may include, when a first user transaction credential associated with a first fund account is requested to be used on a first end-user host electronic device, the credential issuer subsystem links a first receiving token and a first sending token to a first account token uniquely associated with the first fund account, the credential issuer subsystem transmits the first receiving token to the management entity subsystem, and the credential issuer subsystem supplies the first sending token to the first end-user host electronic device. The method may also include, when a second user transaction credential associated with a second fund account is requested to be used on a second end-user host electronic device, the credential issuer subsystem links a second receiving token and a second sending token to a second account token uniquely associated with a second fund account, the credential issuer subsystem transmits the second receiving token to the management entity subsystem, and the credential issuer subsystem supplies the second sending token to the second end-user host electronic device. The method may also include, when requesting to transfer funds, receiving by the credential issuer subsystem a management entity transfer funds request from the management entity subsystem, the management entity transfer funds request including device payment credential data, the device payment credential data including a first sending token, a funds amount, and a second receiving token; verifying by the credential issuer subsystem the first sending token of the device payment credential data of the management entity transfer funds request; and in response to the verification, transferring by the credential issuer subsystem the funds amount of the funds from a first funds account linked to the verified first sending token to a second funds account linked to the second receiving token of the management entity transfer funds request.

[0009] As another example, a method is provided, the method using a first end-user host electronic device and a second end-user host electronic device and a management entity subsystem to facilitate the transfer of funds between a first fund account of a credential issuer subsystem and a second fund account of the credential issuer subsystem, wherein the first fund account is linked to a first sending token and a first receiving token at the credential issuer subsystem, wherein the second fund account is linked to a second sending token and a second receiving token at the credential issuer subsystem, wherein the first end-user host electronic device is associated with a first social token at the management entity subsystem, wherein the second end-user host electronic device is associated with a second social token at the management entity subsystem, wherein the first end-user host electronic device includes a first user identifier and a first sending token, and wherein the second end-user host electronic device includes a second user identifier and a second sending token. The method may include receiving, by the management entity subsystem, a device transfer funds request from the first end-user host electronic device, the device transfer funds request including device payment credential data, the device payment credential data including the first sending token, a fund amount, a second social token, and a mandate key, the mandate key including a hash of the first user identifier and a hash of the second social token. The method may also include determining, by the management entity subsystem, a task identifier, the task authorization identifier including a hash of a task authorization key and a hash of a first user identifier and a hash of a second user identifier. The method may also include calculating, by the management entity subsystem, a fraud risk of the device transfer funds request using the determined task authorization identifier.

[0010] As another example, a method is provided that uses a first electronic device and a second electronic device and an administrative entity ("AE") subsystem to facilitate the transfer of funds between a first funding account of a first credential issuing subsystem and a second funding account of a second credential issuing subsystem, wherein the first funding account is linked to a first sending token and a first receiving token at the first credential issuing subsystem, wherein the second funding account is linked to a second sending token and a second receiving token at the second credential issuing subsystem, wherein the first electronic device is associated with a first social token, and wherein the second electronic device is associated with a second social token. The method may include, when requesting to supply first device credentials associated with a first funding account on a first electronic device, using the AE subsystem to store a first receiving token for a first social token at the AE subsystem and supplying first device credential data including a first sending token on the first electronic device; when requesting to supply second device credentials associated with a second funding account on a second electronic device, using the AE subsystem to store a second receiving token for a second social token at the AE subsystem and supplying second device credential data including a second sending token on the second electronic device; and when a transfer of funds is initiated by the first electronic device, using the AE subsystem to receive device transfer funds request data at the AE subsystem from the first electronic device, the device transfer funds request data including device payment credential data, the device payment credential data including the first sending token and the second social token; using the second social token of the device transfer funds request data to identify the second receiving token at the AE subsystem; and transmitting the AE transfer funds request data from the AE subsystem to the first credential issuing subsystem, the AE transfer funds request data including the identified second receiving token and the received device payment credential data including the first sending token.

[0011] The present invention is provided only to present some example embodiments, so as to provide a basic understanding of some aspects of the subject matter described herein. Therefore, it should be understood that the features described in the present invention are only examples and should not be interpreted as reducing the scope or essence of the subject matter described herein in any way. Unless otherwise stated, the features described in the context of an example may be combined or used together with the features described in the context of one or more other examples. Other features, aspects and advantages of the subject matter described herein will become apparent through the following detailed description, drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The following discussion refers to the following drawings, wherein like reference numerals refer to like parts throughout, and wherein:

[0013] Figure 1 is a schematic diagram of an illustrative system for facilitating the transfer of funds between user accounts;

[0014] Figure 2 yes Figure 1 A more detailed schematic diagram of an example of one of the electronic devices of the system;

[0015] Figure 2A yes Figure 1 and Figure 2 Another more detailed schematic diagram of the electronics of the;

[0016] Figure 2B yes Figure 1 A more detailed schematic diagram of another example of electronic equipment of the system;

[0017] Figure 3 yes Figure 1 , Figure 2 and Figure 2A A front view of an electronic device;

[0018] Figure 4 yes Figure 1 A more detailed schematic diagram of an example management entity subsystem of a system;

[0019] Figures 4A-4H yes Figure 1 Schematic diagrams of various example data structures of the system; and

[0020] Figure 5 is a flow chart of an illustrative process for facilitating a funds transfer. DETAILED DESCRIPTION

[0021] A first user credential (e.g., a payment credential or any other suitable transaction credential) for a first user fund account of a credential issuer subsystem may be provisioned on a secure element of a first electronic device for use by an authenticated user, while a second user credential for a second user fund account of a credential issuer subsystem may be provisioned on the same first electronic device or on a second electronic device for use by an authenticated user. Unique data, which may be user-anonymous and / or fund account-anonymous, may be linked to a specific user fund account at the credential issuer subsystem and then shared with an administrative entity subsystem to facilitate secure transfers of funds between different user accounts of the credential issuer subsystem. Such an administrative entity subsystem may be operated by an administrative entity to provide a layer of security and / or a more convenient user experience for the use of such user credentials. A device protection subsystem of such a management entity subsystem may be operable to provide one or more device protection services for protecting an electronic device (e.g., if a device is to be reported lost or stolen and / or for shielding an association between a device and the identity of a particular user registered with the device) and / or for enabling certain device-to-device communications, while a credential protection subsystem of such a management entity subsystem may be operable to manage user credentials provisioned on an electronic device from a credential issuer subsystem and facilitate secure use of the user credentials provisioned on a sender device to fund a transfer from a sender user account to a recipient user account in the credential issuer subsystem. The management entity subsystem may be operable to enable a sender user to utilize credentials provisioned on a sending user device and a recipient social token (e.g., an email address or phone number) associated with the recipient user (e.g., as may be identified in a contacts application of the sender user device) to initiate a funds transfer from a sender funds account at the credential issuer subsystem associated with the provisioned credentials to a recipient funds account at the credential issuer subsystem associated with the recipient social token. However, in such embodiments, to limit the potential for privacy and / or security breaches, the management entity subsystem may be operable to prevent any of its specific subsystems (e.g., the device protection subsystem and / or the credential protection subsystem and / or any transaction protection subsystem) from storing any information that could specifically link two or more specific users to a specific funds transfer (e.g., the identity of the sender device and data indicative of the recipient account). In contrast, the system of the present disclosure may use user anonymity and / or fund account anonymity to receive tokens, each of which may be associated with a specific recipient fund account at the credential issuer subsystem and may be associated with a specific user of the electronic device at the credential protection subsystem (e.g., a specific recipient social token) rather than a specific user at the device protection subsystem, such that no subsystem of the management entity subsystem has access to data that can be used to identify two or more specific users regarding a specific transaction.

[0022] Figure 1 Description

[0023] Figure 1 is a schematic diagram of an exemplary system 1 that can facilitate the transfer of funds between user accounts. Figure 1 As shown, system 1 may include a first end-user host electronic device 100 (e.g., a laptop computer (see, e.g., Figure 1 ) or smartphone (for example, Figure 3 ) or a wearable device, etc.), on which at least one first user credential of the first user U1 is provided (for example, on a security element of the first electronic device 100). Figure 1 As shown, the system 1 may include a second end-user host electronic device 200 (e.g., a smart phone (see, e.g., Figure 1 ) or a laptop or wearable device, etc.), on which at least one second user credential of a second user U2 is provisioned (e.g., on a secure element of the second electronic device 200). Additionally or alternatively, in addition to the at least one first user credential of the first user U1 provisioned thereon, the first end-user host electronic device 100 may also have at least one second user credential of a second user U2 provisioned thereon. The system 1 may also include an administrative (or commercial or trusted) entity subsystem 400, and a credential issuer (or financial institution) subsystem 300. Communication of any suitable data between any two of the electronic device 100, the electronic device 200, the administrative entity ("AE") subsystem 400, the credential issuer ("CI") subsystem 300, and / or any other entity of the system 1 (e.g., a service provider (e.g., merchant) subsystem) may be implemented via any suitable communication setup 9, which may include any suitable wired communication path, any suitable wireless communication path, or any suitable combination of two or more wired and / or wireless communication paths using any suitable one or more communication protocols and / or any suitable network and / or one or more cloud architectures. Each communication path between any two devices or subsystems of the system 1 using the communication arrangement 9 may be at least partially managed by one or more trusted service managers ("TSMs"). One or more of such communication paths may be provided using any suitable circuits, devices, systems, or combinations thereof operable to create a communication network (e.g., a wireless communication infrastructure that may include one or more communication towers, telecommunications servers, etc.), and these paths may be capable of providing communication using any suitable wired communication protocol or wireless communication protocol. For example, one or more of such communication paths may support Wi-Fi (e.g., 802.11 protocol), ZigBee (e.g., 802.15.4 protocol), WiDi TM , Ethernet, Bluetooth TM, BLE, high-frequency systems (e.g., 900MHz communication system, 2.4GHz communication system, and 5.6GHz communication system), infrared, TCP / IP, SCTP, DHCP, HTTP, BitTorrent TM , FTP, RTP, RTSP, RTCP, RAOP, RDTP, UDP, SSH, WDS bridging, any communication protocol that can be used by wireless phones and cellular phones and personal email devices (e.g., GSM, GSM plusEDGE, CDMA, OFDMA, HSPA, multi-band, etc.), any communication protocol that can be used by a low-power wireless personal area network ("6LoWPAN") module, any other communication protocol, or any combination thereof. In some implementations, additionally or alternatively, one or more of such communication paths can support any wired communication.

[0024] Transaction credentials (e.g., payment credentials or any other suitable transaction credentials) may be provided from any suitable credential issuer subsystem 300 (e.g., an issuing bank subsystem or financial institution subsystem), directly from the CI subsystem 300, or via the AE subsystem 400 on the first electronic device 100 (e.g., on a secure element or other storage component of the first electronic device 100), which is operable to securely transmit credential data to the first device 100 and manage such credential data. For example, the CI subsystem 300 may include a first issuing subsystem ("IS") 391, which may be operated by at least one first credential issuing institution (e.g., a first issuing bank, such as Wells Fargo of San Francisco, California) with or without a first payment network institution (e.g., a first payment network, such as MasterCard of Purchase of New York) for providing at least one first user transaction credential for the first user U1 on the first device 100 (e.g., directly or via the AE subsystem 400 (e.g., via the credential protection subsystem 491 of the AE subsystem 400)). The CI subsystem 300 may include a second issuing subsystem 392, which may be operated by at least one second credential issuing institution (e.g., a second issuing bank, such as Citibank of Sioux Falls, South Dakota) with or without a second payment network institution (e.g., a second payment network, such as Visa of Foster City, California) for providing at least one second user transaction credential for a second user U2 on the first device 100 and / or the second device 200 (e.g., directly or via the AE subsystem 400 (e.g., via the credential protection subsystem 491 of the AE subsystem 400)). However, it should be understood that the first issuing subsystem 391 is operable to provide one or more first user transaction credentials for the first user U1 on the first device 100 and one or more second user transaction credentials for the second user U2 on the first device 100 and / or the second device 200, wherein no issuing subsystem may be used only to provide transaction credentials for a specific user. In addition, each issuing subsystem is operable to manage one or more user funds accounts (e.g., bank accounts) that may have funds associated therewith for use in funding transactions or may be operable to receive funds in transactions funded by another account, wherein each user funds account may be associated with one or more transaction credentials that may be provisioned on a user electronic device of system 1.Once transaction credentials are provisioned on an electronic device, the device may use the transaction credentials to securely provide funds or otherwise conduct a transaction (e.g., a commercial or financial transaction or any other suitable credential transaction) between a first or sending user funds account of the issuing subsystem of subsystem 300 associated with the transaction credentials provisioned on the electronic device (e.g., first or sending electronic device 100) and any suitable second or receiving user funds account of the issuing subsystem of subsystem 300 (e.g., a receiving user funds account that may be associated with credentials provisioned on another device (e.g., second or receiving electronic device 200)). For example, while any suitable recipient identifier (e.g., any suitable social recipient identifier) ​​that may be associated with at least one recipient user account of the issuing subsystem of subsystem 300 (e.g., identifying a social identifier of a second device 200 on which credentials associated with the recipient user account may be provisioned) is also identified by the first device 100 (e.g., using any suitable user interface of the first device 100 (e.g., a user interface of a contacts application, an electronic address book, or a phone book, etc.)), the first device 100 may also identify specific transaction credentials provisioned on the first device 100, which specific transaction credentials will be used (e.g., used by the CI subsystem 300) to identify the sender user account associated with the provisioned transaction credentials for funding or otherwise further facilitating the transaction.

[0025] The AE subsystem 400 may include a credential protection subsystem 491 that is operable to provide an additional layer of security and / or efficiency to the provisioning of credentials on the first device 100 and / or the utilization of credential data provisioned on the first device 100 to fund a recipient user account of the issuing subsystem 300 of the subsystem (e.g., a recipient user account that may be associated with credentials provisioned on another device (e.g., a second or recipient electronic device 200)). For example, the credential protection subsystem 491 may be used to verify the trustworthiness of one or more issuing subsystems of the CI subsystem 300 on behalf of the device 100 before enabling the provisioning of credentials from the issuing subsystem to the device 100, and / or the credential protection subsystem 491 may be used to encrypt, encode, or otherwise protect the communication of transaction credential information from the issuing subsystem to the device 100 to ensure secure credential provisioning on the device 100. Additionally or alternatively, the credential protection subsystem 491 may be used to verify the trustworthiness of a recipient user account identified by the device 100 before enabling transaction credential data (e.g., sender transaction credential data or sender device payment credential data) from the device 100 to be shared for use in funding the recipient user account. Additionally or alternatively, the credential protection subsystem 491 may be operable to encrypt, encode, or otherwise protect the communication of transaction credential data from the device 100 to the CI subsystem 300 to ensure secure transaction credential data sharing while facilitating transactions between the device 100 and the recipient user account of the issuer subsystem 300. Additionally or alternatively, the credential protection subsystem 491 may be operable to facilitate secure funds transfers between user accounts and / or funding accounts that may be linked to a specific user funding account at the CI subsystem 300 by maintaining data operable to anonymously associate an identifier of a specific registered user of the AE subsystem 400 with at least one specific user.

[0026] Additionally, the AE subsystem 400 may include a device protection subsystem 471 that may be used to provide an additional layer of security to the system device (e.g., if the device 100 were to be lost or stolen). The device protection subsystem 471 may enable a user of the device 100 to register the device 100 with the AE subsystem 400 to receive one or more supporting services of the device protection subsystem 471. One or more services of the device protection subsystem 471 may be used to track the location of the registered device 100 and / or remotely control one or more functions of the registered device 100, such as turning on an alarm and / or wiping or suspending or otherwise terminating the usefulness of certain device content, such as suspending the ability of the device 100's secure element to generate transaction credential data for further transactions with a recipient user account or service provider. Such services may be useful to the device owner when the device 100 may be lost or stolen so that the device may be recovered and / or so that sensitive data on the device may not be accessed. Additionally or alternatively, the device protection subsystem 471 may be operable to associate certain social tokens (e.g., email addresses, phone numbers, etc.) with certain registered devices and / or enable certain secure communications between registered devices and / or associate certain registered devices with certain AE user accounts of the AE subsystem 400. Furthermore, the AE subsystem 400 may include a transaction protection subsystem 481 that is operable to provide an additional layer of security for determining risks associated with proposed transactions facilitated by the AE subsystem 400 and / or store certain user-anonymous and / or account-anonymous data associated with specific transactions facilitated by the AE subsystem 400.

[0027] However, as described above, to limit potential privacy and / or security vulnerabilities, the AE subsystem 400 is operable to prevent any particular subsystem thereof (e.g., device protection subsystem 471, credential protection subsystem 481, and / or transaction protection subsystem 481) from storing (e.g., retaining in memory and / or associating with) any information that could specifically link two or more particular users to a particular funds transfer (e.g., the identity of a sender's device and data indicative of a recipient's account). In contrast, system 1 is operable to anonymously receive tokens using anonymous users and / or funding accounts, each of which can be associated with a specific recipient funding account at CI subsystem 300, and with a specific user and / or device at credential protection subsystem 491 (e.g., associated with a specific device identifier and / or user identifier and / or recipient social token that can be registered to the electronic device), but not associated with a specific user at device protection subsystem 471, such that data that can be used to identify two or more specific users regarding a particular transaction is inaccessible to any subsystem of AE subsystem 400 (e.g., no entry in any table of any subsystem of AE subsystem 400 may be included), and / or such that a sending device that transmits sending device payment credential data to the recipient funding account for funding the transfer transaction may not need to process recipient funding account identification information.

[0028] Figure 2 , Figure 2A and Figure 3 Description

[0029] Figure 2 A more detailed view of an example user electronic device 100 of system 1 is shown. Figure 2 As shown, for example, device 100 may include a processor 102, a memory 104, a communication component 106, a power source 108, an input component 110, an output component 112, an antenna 116, and a near field communication component 120. Device 100 may also include a bus 118, which may provide one or more wired or wireless communication links or paths for transmitting data and / or power to, from, or between various other components of device 100. Device 100 may also be provided with a housing 101, which may at least partially enclose one or more of the components of device 100 to protect them from debris and other degrading forces external to device 100. In some embodiments, one or more components of device 100 may be combined or omitted. In addition, device 100 may include components that are not combined or included in Figure 2 For example, the device 100 may include any other suitable components or Figure 2 For simplicity, Figure 2Only one component of each type is shown. Electronic device 100 can be any portable, mobile, wearable, implantable or handheld electronic device that is configured to store one or more transaction credentials for further transactions with a recipient user account. Alternatively, electronic device 100 may not be portable during use, but may be generally fixed. Electronic device 100 may include, but is not limited to, a media player, a video player, a still image player, a game console, other media players, a music recorder, a movie or video camera or recorder, a still camera, other media recorders, radio components, medical devices, household appliances, transportation instruments, musical instruments, calculators, cellular phones (e.g., iPhones available from Apple Inc.) TM ), other wireless communication devices, personal digital assistants, remote controls, pagers, computers (e.g., desktops, laptops, tablets, servers, etc.), monitors, televisions, audio equipment, set-top boxes, set-top boxes, wearable devices (e.g., Apple Watch available from Apple Inc. TM ), small speakers, modems, routers, printers, and any combination thereof.

[0030] The memory 104 may include one or more storage media, such as a hard drive, a flash memory, a permanent memory such as a read-only memory ("ROM"), a semi-permanent memory such as a random access memory ("RAM"), any other suitable type of storage component, or any combination thereof. The memory 104 may include a cache memory, which may be one or more different types of memory for temporarily storing data for electronic device applications. The memory 104 may store media data (e.g., music files and image files), software (e.g., applications for implementing functions on the device 100), firmware, preference information (e.g., media playback preferences), lifestyle information (e.g., dietary preferences), exercise information (e.g., information obtained by an exercise monitoring device), transaction information, wireless connection information (e.g., information that enables the device 100 to establish a wireless connection), subscription information (e.g., information for tracking podcasts or television programs or other media to which a user subscribes), contact information (e.g., phone numbers and email addresses), calendar information, any other suitable data, or any combination thereof. The communication component 106 is operable to enable the device 100 to communicate with one or more other electronic devices (e.g., device 200) or a server or subsystem (e.g., one or more of subsystems 300 and 400) using any suitable communication protocol (e.g., a wired and / or wireless protocol via the communication setting 9). The power supply 108 can provide power to one or more components of the device 100. In some embodiments, the power supply 108 can be coupled to a power grid (when the device 100 is charging or is not a portable device such as a desktop computer). In some embodiments, the power supply 108 may include one or more batteries for providing power (e.g., when the device 100 is a portable device such as a cellular phone). As another example, the power supply 108 can be configured to generate power from a natural source (e.g., solar energy using a solar cell). One or more input components 110 may be provided to allow a user or the surrounding environment or a remote data source to interact or connect with the device 100, and / or one or more output components 112 may be provided to present information (e.g., graphical information, audible information, and / or tactile information) to a user of the device 100. It should be noted that one or more input components and one or more output components may sometimes be collectively referred to herein as input / output (“I / O”) components or I / O interfaces 114 (e.g., input components 110 and output components 112 may sometimes be referred to as I / O components or I / O interfaces 114). For example, input components 110 and output components 112 may sometimes be a single I / O component 114 such as a touch screen, which may receive input information by a user touching a display screen and may also provide visual information to the user via the same display screen.

[0031] The processor 102 of the device 100 may include any processing circuitry operable to control the operation and performance of one or more components of the device 100. For example, the processor 102 may receive input signals from the input component 110 and / or drive output signals through the output component 112. The processor 102 of the host device 100 may include any suitable processing circuitry operable to control the operation and performance of one or more components of the host device 100. Figure 2 As shown, processor 102 may be used to run one or more applications (e.g., application 103 and / or application 113), which may at least partially specify the manner in which data may be received, generated, and / or transmitted by device 100. As an example, application 103 may be an operating system application, and application 113 may be a third-party application or any other suitable online resource (e.g., a contact or address book application, a protection application and / or a device-to-device communication application (e.g., a communication application associated with device protection subsystem 471 of AE subsystem 400), a credential issuer application (e.g., a credential issuer application associated with a credential issuance subsystem of CI subsystem 300), an application associated with a merchant of a service provider (“SP”) subsystem (not shown), etc.). In addition, as shown, processor 102 may access any suitable device identification information 119, which may be used by a user of device 100 and / or AE subsystem 400 and / or issuer subsystem 300 and / or any SP subsystem to provide any suitable identification of device 100. As just one example, device identification information 119 may be any suitable social token (e.g., a phone number or email address associated with device 100), or any suitable unique identifier that may be associated with device 100 or a component thereof (e.g., a unique device identifier for device 100 or a unique secure element identifier for a secure element of device 100, etc.).

[0032] Near field communication (“NFC”) component 120 may be configured to transmit transaction credential data (e.g., sender transaction credential data or sender device payment credential data) and / or any other suitable data as proximity-based contactless communication (e.g., near field communication) to communicate with a merchant or SP subsystem (not shown) (e.g., an SP NFC terminal utilizing the SP subsystem, which may be located in a physical store or any physical location where a user of device 100 may use the credential to conduct a transaction with a nearby SP terminal via proximity-based contactless communication). NFC component 120 may allow for short-range communication at a relatively low data rate (e.g., 424 kbps) and may comply with any suitable standard such as ISO / IEC 7816, ISO / IEC 18092, ECMA-340, ISO / IEC 21481, ECMA-352, ISO 14443, and / or ISO 15693. NFC component 120 may allow for short-range communication at a higher data rate (e.g., 370 Mbps) and may comply with any suitable standard such as TransferJet. TM Protocol compatible. Communication between the NFC component 120 and the NFC component of the SP subsystem or any other suitable entity of the system 1 may occur within any suitable close range between the NFC component and the other entity, such as a range of approximately 2 to 4 centimeters, and may operate at any suitable frequency (e.g., 13.56 MHz). For example, such close range communication of the NFC component may occur via magnetic field induction, which may allow the NFC component to communicate with other NFC devices and / or retrieve information from a tag having a radio frequency identification ("RFID") circuit. Although the NFC component 120 has been described with respect to near field communication, it should be understood that the component 120 may be configured to provide any suitable proximity-based contactless mobile payment or any other suitable type of proximity-based contactless communication between the device 100 and another entity such as a terminal of the SP subsystem. For example, the NFC component 120 may be configured to provide any suitable short-range communication such as short-range communication involving electromagnetic coupling technology / electrostatic coupling technology.

[0033] NFC component 120 may include any suitable module for implementing proximity-based contactless communication between device 100 and such a remote terminal (eg, SP terminal). Figure 2As shown, the NFC component 120 may include an NFC device module 130, an NFC controller module 140, and / or an NFC memory module 150. The NFC device module 130 may include an NFC data module 132, an NFC antenna 134, and an NFC enhancer 136. The NFC data module 132 may be configured to contain, route, or otherwise provide any suitable data that may be transmitted by the NFC component 120 to a remote terminal as part of proximity-based contactless communication or NFC communication. The NFC data module 132 may be configured to contain, route, or otherwise receive any suitable data that may be received by the NFC component 120 from the remote terminal as part of proximity-based contactless communication. The NFC controller module 140 may include at least one NFC processor module 142. The NFC processor module 142 may work in conjunction with the NFC device module 130 to enable, activate, allow, and / or otherwise control the NFC component 120 for transmitting NFC communications between the device 100 and the remote terminal. The NFC controller module 140 may include at least one NFC processor module 142 that may be used to run one or more applications, such as an NFC low power mode or wallet application 143 that may help indicate the functionality of the NFC component 120. The NFC memory module 150 may work in conjunction with the NFC device module 130 and / or the NFC controller module 140 to allow NFC communication between the device 100 and a remote terminal. The NFC memory module 150 may be tamper-resistant and may provide at least a portion of a secure element 145 of the device 100. For example, the secure element 145 may be configured to provide a tamper-resistant platform (e.g., as a single-chip or multi-chip secure microcontroller) that may be capable of securely hosting applications and their confidential and encrypted data (e.g., applets 153 and keys 155) in accordance with rules and security requirements that may be set forth by a set of recognized trusted authorities (e.g., authorities of the CI subsystem and / or financial institution subsystem and / or industry standards such as GlobalPlatform).

[0034] As shown, for example, the NFC memory module 150 may include one or more of an issuer security domain (“ISD”) 152, one or more supplemental security domains (“SSD”) 154a-154c (e.g., a service provider security domain (“SPSD”), a trusted service manager security domain (“TSMSD”), a credential SSD, an access SSD, etc.) that may be defined and managed by an NFC specification standard (e.g., GlobalPlatform). For example, the ISD 152 may be part of the NFC memory module 150, where a trusted service manager (“TSM”) or an issuing financial institution (e.g., the issuer subsystem 300) may store one or more keys (e.g., ISD keys 156k) and / or other suitable information for creating or otherwise providing one or more credentials (e.g., credentials associated with various credit cards, bank cards, gift cards, access cards, passes, digital currencies, etc.) on the device 100 (e.g., via the communication component 106) for credential content management and / or security domain management. The credential may include credential data (e.g., credential information 161a), which may be assigned to a user / consumer (e.g., by an issuing subsystem) and may be securely stored on the electronic device 100 and / or uniquely generated on the electronic device 100. For example, such credential data (e.g., credential information 161a) may include a device primary account number (“DPAN”) or a sending token (e.g., a 16- to 19-character token that may be similar to a credit / debit card number that may be compatible with various card networks, or a device account reference (“DAR”) (e.g., a well-formatted string that may include a globally unique identifier (“GUID”), or a universally unique identifier (“UUID”) (e.g., a 128-bit integer that may be used to identify one or more resources) and / or a code (e.g., a bank code) that may identify a particular source (e.g., an issuing subsystem)), a DPAN expiration date, a CVV, and / or the like (e.g., as a token or otherwise). The NFC memory module 150 may include at least three SSDs 154 (eg, a first credential SSD 154 a , a second credential SSD 154 b , and an access SSD 154 c ).For example, each of the first credential SSD 154a and the second credential SSD 154b may be associated with a corresponding specific credential of any suitable type (e.g., a specific credit card credential or a specific stored value account credential or a specific public transportation card credential provided by the issuer subsystem 300) that may provide specific privileges or payment permissions to the electronic device 100, while the access SSD 154c may be associated with a commercial or administrative entity (e.g., an entity of the AE subsystem 400, which may be a controlling entity of the device 100) that may control the device 100's access to the specific credential of the other SSD (e.g., the first SSD 154a or the second SSD 154b), for example, to provide specific privileges or payment permissions to the electronic device 100. Each SSD 154 may include and / or be associated with at least one applet 153 (e.g., SSD 154a having applet 153a and SSD 154b having applet 153b). For example, applet 153 of SSD 154 may be an application that can run on a secure element of NFC component 120 (e.g., in a GlobalPlatform environment). Credential applet 153 may include or be associated with credential information 161 (e.g., information 161a of applet 153a and / or information 161b of applet 153b). Each SSD 154 and / or applet 153 may also include and / or be associated with at least one of its own keys 155 (e.g., applet 153a having at least one access key 155a and at least one access key 155a', and applet 153b having at least one access key 155b and at least one access key 155b').

[0035] The key 155 of SSD 154 can be a piece of information that can determine the function output of the encryption algorithm or password. For example, when encrypting, the key can specify a specific conversion of plaintext to ciphertext during encryption or vice versa. Keys such as digital signature schemes and message authentication codes can also be used in other encryption algorithms. The key of SSD can provide any appropriate shared key with another entity. Each key and applet can be loaded on the security element of device 100 by TSM or authorization agent, or it can be preloaded on the security element before the security element is first provided to device 100. As an example, although the credential SSD 154a can be associated with a specific credit card credential, when the applet 153a of the credential SSD154a has been enabled or otherwise activated or unlocked for such use, the specific credential can only be used to transmit the transaction credential data communication from the security element 145 of the device 100 to the remote entity for financial transactions (for example, for providing funds for the recipient user account). Some keys can be generated on the security element or other suitable parts of the device 100.

[0036] Security features may be provided to enable use of NFC component 120, which may be particularly useful when transmitting credential information (e.g., confidential payment information, such as credentialed credit card information or bank account information) from electronic device 100 to a remote entity (e.g., for funding a recipient user account of CI subsystem 300 (e.g., via AE subsystem 400)) and / or from issuer subsystem 300 to electronic device 100 (e.g., for configuration on a secure element of device 100 (e.g., via AE subsystem 400)). Such security features may also include secure storage areas that may have restricted access rights. For example, user authentication via personal identification number ("PIN") entry or via user interaction with a biometric sensor may be required to access the secure storage area. For example, access SSD 154c may utilize or otherwise use applet 153c to determine whether such authentication has occurred before allowing use of other SSDs 154 (e.g., credential SSD 154a or credential SSD 154b) to transmit its credential information 161. In some embodiments, some or all of the security features may be stored within the NFC memory module 150. Additionally, security information used to communicate commerce credential data with a remote entity, such as an authentication key, may be stored within the NFC memory module 150 of the electronic device 100. In some embodiments, the NFC memory module 150 may include a microcontroller embedded within the electronic device 100. As just one example, an applet 153c accessing an SSD 154c may be configured to determine intent and local authentication of a user of the device 100 (e.g., via one or more input components 110 such as a biometric input component), and in response to such a determination, it may be configured to enable another particular SSD to conduct a payment transaction (e.g., utilizing the credentials of the credential SSD 154a).

[0037] like Figure 2AAs shown, for example, the secure element 145 of the NFC component 120 may include an SSD 154a and an SSD 154b, wherein SSD 154a may include or be associated with an applet 153a, credential information 161a, an access key 155a and / or a credential key 155a', and SSD 154b may include or be associated with an applet 153b, credential information 161b, an access key 155b and / or a credential key 155b'. In some embodiments, each of SSDs 154a and 154b may be associated with a specific TSM and at least one specific business credential (e.g., a specific credit card credential or a specific stored value account credential or a specific public transportation card credential), which may provide specific privileges or payment permissions to the electronic device 100 (e.g., SSD 154a may be associated with a first transaction credential provided for user U1 from the first issuing subsystem 391 of the issuer subsystem 300, and SSD 154b may be associated with a second transaction credential provided for user U1 from the first issuing subsystem 391 of the issuer subsystem 300). Each SSD 154 may have its own manager key 155 (e.g., a corresponding one of keys 155ak and 155bk), which may need to be activated to enable the functionality of the SSD 154 for use by the NFC device module 130. Each SSD 154 may include and / or be associated with at least one of its own credential application or a credential applet (e.g., a Java Card applet instance) associated with a particular business credential (e.g., credential applet 153a of SSD 154a may be associated with a first business credential and / or SSD 154b may be associated with a first business credential. 154b may be associated with a second business credential), wherein the credential applet may have its own access key (e.g., access key 155a for credential applet 153a and / or access key 155b for credential applet 153b) and / or its own credential key (e.g., credential key 155a' for credential applet 153a and credential key 155b' for credential applet 153b), and wherein the credential applet may need to be activated so that its associated business credential can be used by NFC device module 130 for NFC communication (e.g., with a remote terminal) and / or for online-based communication between device 100 and a remote entity (e.g., between device 100 and CI subsystem 300 (e.g., via AE subsystem 400)).

[0038] The credential key for the credential applet may be generated by the CI subsystem 300, which may be responsible for such credentials, and may be accessed by the issuer subsystem 300 so as to enable secure transmission of the credential information for the applet between the secure element 145 and the issuer subsystem 300. The credential key for the credential applet may be generated by the AE subsystem 400 and may be accessed by the AE subsystem 400 so as to enable secure transmission of the credential information for the applet between the secure element 145 and the AE subsystem 400. As shown, each applet may include its own unique application identifier (“AID”), such as AID 155aa for applet 153a and / or AID 155ba for applet 153b. For example, an AID may identify a specific card scheme and product, program, or network (e.g., MasterCard Cirrus, Visa PLUS, Interac, etc.), wherein the AID may include not only a registered application provider identifier ("RID") that identifies the payment system (e.g., card scheme) or network (e.g., MasterCard, Visa, Interac, etc.) of the credential associated with the AID, but also a proprietary application identifier extension ("PIX") that may be used to distinguish between products, programs, or applications provided by the provider or payment system of the credential associated with the AID. Any suitable specification (e.g., Java Card specification) operable to manage the firmware of the secure element 145 may be operable to ensure or otherwise enforce the uniqueness of each AID on the secure element 145 (e.g., each credential instance on the secure element 145 may be associated with its own unique AID).

[0039] like Figure 2A As shown, the secure element 145 may include an ISD 152, which may include an ISD key 156k that may also be known by a trusted service manager associated with the security domain (e.g., the AE subsystem 400). The ISD key 156k may be utilized or otherwise used by the AE subsystem 400 and the device 100 similarly to and / or in place of the access key 155a and / or the access key 155b to enable secure transmissions between the AE subsystem 400 and the secure element 145. In addition, as shown in FIG. Figure 2AAs shown, various data may be communicated between the processor 102 and the secure element 145. For example, the processor 102 of the device 100 may be configured to run a device application 103, which may communicate information with an application 113 of the processor 102 and the secure element 145, an I / O interface component 114a (e.g., for receiving I / O input data 115i and / or for transmitting I / O output data 115o), and / or a communication component 106. In addition, as shown, the processor 102 may have access to device identification information 119, which may be used to enable secure communications between the device 100 and one or more remote entities.

[0040] like Figure 2A As shown, the security element 145 may include a control authority security domain ("CASD") 158, which may be configured to generate and / or otherwise include a CASD access kit 158k (e.g., CASD keys, certificates, and / or signature modules). For example, before providing such data to another portion of the device 100 (e.g., a communication component 106 for sharing with other subsystems of the system 1), the CASD 158 may be configured to (e.g., using the CASD access kit 158k) sign specific data on the security element 145. The secure element 145 may include a contactless registration service (“CRS”) applet or application 151 that may be configured to provide local functionality to the electronic device 100 to modify the life cycle state of certain security domain elements (e.g., activate, deactivate, suspend, lock, etc.) and share certain output information 115o about certain security domain elements in certain life cycle states with a user of the device 100 (e.g., via the user I / O interface 114a), and may include a CRS list 151t that may maintain a list of the current life cycle state of each security domain element on the secure element 145, and may be configured to share the life cycle state of one or more security domain elements with applications of the device 100 (e.g., using any suitable application type, such as a daemon, such as a card management daemon (“CMD”) application 113a, which may be implemented as an operating system application 103 and / or a card management application 113b (e.g., Passbook from Apple Inc.). TM or Wallet TM151a and 151b, respectively. The CRS 151 may include a CRS access key 151k, which may also be known to a trusted service manager (e.g., AE subsystem 400) associated with CRS 151 and / or a device protection (“DP”) application 113c (e.g., an application and / or daemon that may be associated with device protection subsystem 471 of AE subsystem 400) and / or an identity service (“IDS”) application 113d, which in turn may provide certain lifecycle state information to a user of device 100 as output information 115o (e.g., a UI of card management application 113b) via I / O interface 114a and a user interface (“UI”) application, which may enable the user to change the lifecycle state of the security domain element. CRS 151 may include a CRS access key 151k, which may also be known to a trusted service manager (e.g., AE subsystem 400) associated with CRS 151 and may be utilized or otherwise used by AE subsystem 400 and device 100 similarly and / or in place of access key 155a and / or access key 155b for enabling secure transmissions between AE subsystem 400 and secure element 145.

[0041] DP application 113c may be any suitable application type, such as a daemon, which may run as a background process within operating system application 103 and / or card management application 113b, and / or may be provided by CMD application 113a, or may be an application provided by any suitable entity (e.g., an entity responsible for device protection subsystem 471), and may be operable to enable any suitable device protection service to be later activated by device protection subsystem 471 to protect device 100 in one or more ways. For example, DP application 113c may be a "find my device" application (e.g., "find my iPhone" or "find my Mac" application of Apple Inc.), which may be used in conjunction with the services of device protection subsystem 471 (e.g., iCloud service of Apple Inc.) to track the location of device 100 and / or remotely control one or more functions of device 100, such as turning on an alarm and / or erasing or suspending or otherwise terminating the usefulness of certain device content, such as suspending the ability of the secure element of device 100 to generate and / or transmit transaction credential data for further transactions with a remote entity. Such a service may be useful to the device owner when the device 100 may be lost or stolen so that the device may be recovered and / or so that sensitive data on the device may not be accessed. The IDS application 113d may be any suitable application type, such as a daemon that may run as a background process within the operating system application 103, and / or a card management application 113b and / or an application that may be provided by the CMD application 113a, and may be used as an IDS manager to listen for and respond to IDS messages that may be sent to and / or from the device 100 via any suitable IDS service (e.g., an IDS service of the IDS subsystem 471 of the AE subsystem 400), which may be similar to any suitable messaging service, such as iMessage from Apple Inc. TM etc. (e.g., FaceTime by Apple Inc. TM or Continuity TM), and / or it is capable of implementing unique end-to-end encryption of messages between the IDS application 113d of device 100 and a similar IDS application of another device (e.g., the IDS application 213d of device 200). Such messages can be encrypted using a unique identifier of one or both of the communicating devices (e.g., the device unique identifier 119 of device 100 and / or the device unique identifier 219 of device 200) and / or a unique social token of a specific user of one or both of the communicating devices (e.g., a phone number, etc.). Such messages can be communicated as a local link or true device-to-device (e.g., peer-to-peer) communication, or can be communicated via the AE subsystem 400 (e.g., via the IDS subsystem of the AE subsystem 400 (e.g., using an identity management system component)). Such messaging can be implemented as a low-latency solution that enables data to be exchanged between structured formats (e.g., protocol buffers) and / or unstructured formats.

[0042] like Figure 3 As shown, a specific example of the electronic device 100 may be a handheld electronic device such as an iPhone TM , wherein the housing 101 may allow access to various input components 110a-110i, various output components 112a-112c, and various I / O components 114a-114d, through which the device 100 and the user and / or the surrounding environment may be connected to each other. For example, the touch screen I / O component 114a may include a display output component 112a and an associated touch input component 110f, wherein the display output component 112a may be used to display a visual user interface or graphical user interface ("GUI") 180 that allows a user (e.g., a first user UI) to interact with the electronic device 100. The GUI 180 may include various layers, windows, screens, templates, elements, menus, and / or other components of currently running applications (e.g., application 103 and / or application 113 and / or application 143), which may be displayed in all or some areas of the display output component 112a. For example, as Figure 3As shown, the GUI 180 may be configured to display a first screen 190 having one or more graphical elements or icons 182 of the GUI 180. When a specific icon 182 is selected, the device 100 may be configured to open a new application associated with the icon 182 and display a corresponding screen of the GUI 180 associated with the application. For example, when a specific icon 182 (i.e., a specific icon 183) marked with a "Merchant Application" text indicator 181 is selected by a user of the device 100, the device 100 may launch or otherwise access a specific third-party merchant or SP application, and may display a screen of a specific user interface that may include one or more tools or features for interacting with the device 100 in a specific manner. For another example, when a specific icon 182 (i.e., a specific icon 184) marked with a "Messaging" text indicator 181 is selected, the device 100 may launch or otherwise access a specific device application (e.g., a messaging application) that may provide a management entity-specific (or other entity-specific) communication service (e.g., iMessage of Apple Inc. TM ), wherein such services may be operable to provide end-to-end encrypted communications between device 100 and another device (e.g., second user device 200) (e.g., via the identity services (“IDS”) subsystem of AE subsystem 400), and such services may require each device to register (e.g., actively register) before device detection can be achieved and / or messages can be sent between devices using the service (e.g., using an IDS application (e.g., IDS application 113d of device 100) on each participating device). Thus, in some embodiments, certain communications between device 100 and device 200 may be facilitated by and through the IDS subsystem of AE subsystem 400 to achieve a secure and / or efficient communication path between the devices. For another example, when a specific icon 182 labeled with a “Wallet” text indicator 181 (i.e., specific icon 185) is selected, device 100 may launch or otherwise access a specific device application (e.g., for managing various credentials on secure element 145) Figure 2A The card management application 113b of the device 100 (e.g., as a "wallet" or "card book" application) may be displayed, and a screen of a specific user interface may be displayed that may include one or more tools or features for interacting with the device 100 in a specific manner. For another example, when a specific icon 182 marked with a "protect" text indicator 181 (i.e., a specific icon 186) is selected, the device 100 may launch or otherwise access a specific device application (e.g., Figure 2Adevice protection application 113c (e.g., a “Find My Device” application)) to enable certain device protection services to be activated (e.g., by device protection subsystem 471) to protect device 100 (e.g., if lost, stolen, etc.).

[0043] Although Figure 2 , Figure 2A and Figure 3 The description may be made with respect to the first device 100, but it should be understood that Figure 2 , Figure 2A and Figure 3 One, some or all of the components of any one or more of the devices 100 may similarly be provided by the second device 200. For example, Figure 2B As shown, the second device 200 may include one, some, or each of the same elements as the first device 100, wherein, unless otherwise specified, Figure 2B Each element 2XX of the device 200 may be similar to Figure 2AThe corresponding element 1XX of the device 100 of the second device 200. However, in some embodiments, the second device 200 may not supply one or more components of the first device 100 (for example, the second device 200 may not include a security element for which one or more credentials are provided above, and the second device 200 can still use the transaction credentials supplied on the first device 100 and the recipient user account to help facilitate financial transactions). For example, the second device 200 of the second user U2 may not include a security element or any sending token, but can still be contacted by the AE subsystem 400 to accept payment and / or select a recipient account, etc. (for example, in an embodiment in which the AE subsystem 400 can automatically create a stored value account for each user (a stored value account that can be linked to a credit card on file with the AE subsystem 400 (for example, for iTunes or any suitable media store managed by the AE subsystem 400, etc.), but is not associated with credentials on any security element or otherwise on the second device 200 of the second user U2)). For any applicable application, the screen can be displayed on the display output component of the user electronic device (for example, the display output component 112a of the device 100), and can include various user interface elements. For each application, various other types of non-visual information may be provided to the user via various other device output components (e.g., various other device output components 112 of device 100 in addition to display output component 112a). In some embodiments, one or each of devices 100 and 200 may not include a user interface component for providing a GUI, but may instead be considered a more automated device. For example, one or each of devices 100 and 200 may not include a user interface component operable to provide a GUI, but may include one or more user interface components operable to provide audio and / or tactile output to the user and / or provide mechanical or other suitable user input components for selecting and authenticating payment credentials for funding a transaction.

[0044] As described above, the CI subsystem 300 may include at least one issuing subsystem (e.g., at least one issuing bank subsystem), such as the first issuing subsystem 391 and the second issuing subsystem 392. In addition, in some embodiments, the issuer subsystem 300 may include at least one network subsystem (e.g., at least one payment network subsystem (e.g., a payment card association or a credit card association)), such as the first network subsystem and the second network subsystem. For example, each issuing subsystem may be a financial institution that may assume primary responsibility for the ability of associated users to repay debts that they may incur when using a particular payment card and its associated applet on the user's device. One or more specific credential applets of the device 100 may be associated with a specific payment card or fund card that may be electronically linked to one or more fund accounts of a specific user or a group of users (e.g., a joint account of two or more family members) managed by a specific issuing subsystem of the CI subsystem 300. Various types of payment cards may be suitable, including credit cards, debit cards, charge cards, stored value cards or stored value accounts, gas coupon cards, gift cards, etc. Credentials for a particular payment card may be provisioned on device 100 (e.g., as transaction credentials of a Credential Supplementary Security Domain (“SSD”) of NFC component 120) by a particular issuing subsystem of issuer subsystem 300 (e.g., directly or via AE subsystem 400), and such provisioned credentials may subsequently be used by device 100 to generate transaction credential data (e.g., sender device payment credential data) that may be used as part of transaction credential data communications that may be communicated from device 100 to initiate funding of a recipient user fund account that may be managed by the same or another particular issuing subsystem of CI subsystem 300 (e.g., a recipient user fund account that may be associated with credentials for a particular payment card provisioned on second device 200), where such funding may be provided by a sender user fund account that may be associated with the provisioned credentials on device 100 that generated the transaction credential data, which transaction credential data may be used to identify the recipient user fund account. Each credential may be a payment card of a particular brand that may be branded by the network subsystem of issuer subsystem 300. Each network subsystem of the issuer subsystem 300 may be a network of issuing subsystems and / or acquiring banks of the issuer subsystem 300 that may process the use of a particular brand of payment cards (e.g., business credentials). The network subsystem and the issuing subsystem of the issuer subsystem 300 may be a single entity or may be separate entities. For example, in contrast, American Express may be both a network subsystem and an issuing subsystem.Visa and MasterCard may be payment subsystems, and may cooperate with issuing subsystems such as Citibank, Wells Fargo, Bank of America, etc. Although not shown, the CI subsystem 300 may also include or access processor components, communication components, I / O interfaces, buses, memory components, and / or power supply components, which may be the same or similar to such components of the device 100, one, some, or all of which may be at least partially provided by one, some, or each of the first issuing subsystem 391 and the second issuing subsystem 392 of the CI subsystem 300.

[0045] In order for at least some type of transaction to occur within system 1 (e.g., a transaction that can be performed by system 1 between device 100 (e.g., a sender device) and a recipient user account managed by CI subsystem 300 (e.g., a recipient user account that can be associated with credentials for a particular payment card provisioned on second device 200) to fund the recipient user account using transaction credential data from the credentials provisioned on device 100), at least one transaction credential should be securely provisioned on first (sender) device 100 (e.g., directly from issuer subsystem 300 or via AE subsystem 400 (e.g., via credential protection subsystem 491)) and / or at least one transaction credential should be securely provisioned on second (receiver) device 200 (e.g., directly from issuer subsystem 300 or via AE subsystem 400 (e.g., via credential protection subsystem 491)). For example, first user credential data (e.g., first user credential data) can be securely provisioned from CI subsystem 300 (e.g., from first issuing subsystem 391) to first user U1. Figure 5 The data 516d) is supplied to the secure element 145 of the device 100 as at least a portion or all of the credential supplemental security domain of the NFC component 120 (e.g., SSD154a), and may include a credential applet with credential information and / or credential keys, such as a payment application or credential applet 153a with credential information 161a and credential keys 155a'. In addition, in some embodiments, the second user credential data (e.g., from the second issuing subsystem 392) may be transmitted from the CI subsystem 300 (e.g., from the second issuing subsystem 392) to the second user U2. Figure 5The data 532d) is supplied to the secure element 245 of the device 200 as at least part or all of the credential supplemental security domain of the secure element (e.g., SSD 254a), and may include a credential applet having credential information and / or credential keys, such as a payment application or credential applet 253a having credential information 261a and credential key 255a'. The issuer subsystem 300 (e.g., the first issuing subsystem 391) may also access the credential key 155a' (e.g., for decrypting data encrypted by the device 100 using the credential key 155a'), and the issuer subsystem 300 (e.g., the second issuing subsystem 392) may also access the credential key 255a' (e.g., for decrypting data encrypted by the device 200 using the credential key 255a'). The issuer subsystem 300 may be responsible for managing the credential keys 155a' to 255b', which may include the generation, exchange, storage, use, and replacement of such keys. The issuer subsystem 300 may store its version of each credential key in one or more appropriate secure elements of the issuer subsystem 300. It should be understood that each of the credential keys 155a' and 155b' of the device 100 and the issuer subsystem 300 may be any suitable shared secret key (e.g., a password, a passphrase, a randomly selected byte array, one or more symmetric keys, corresponding public-private keys (e.g., asymmetric keys), etc.) available on both or a respective one of the secure element of the electronic device 100 and the issuer subsystem 300, which may be used to enable any suitable encrypted data (e.g., ciphertext) or any other suitable data to be independently generated by the electronic device 100 and the issuer subsystem 300 (e.g., payment data for verifying a financial transaction), such as by using any suitable encryption algorithm or cipher, the functional output of which may be determined at least in part by the shared secret key, wherein such shared secret may be provisioned on the device 100 by the issuer subsystem 300, and / or to allow secure encryption and decryption of data transmitted between the device 100 and the subsystem 300. The shared secret may be previously shared between the issuer subsystem 300 and the device 100 (e.g., during provisioning of credentials by the issuer subsystem 300 on the device 100), in which case such a shared secret may be referred to as a pre-shared key, or the shared secret may be created prior to use in a particular financial transaction by using a key agreement (e.g., using a public key cryptographic protocol such as Diffie-Hellman, or using a symmetric key cryptographic protocol such as Kerberos). The shared secret, as well as any suitable encryption algorithm or cipher whose functional output may be at least partially determined by the shared secret, may be accessible to the secure element of the device 100. Similarly, it should be understood that each of the certificate keys 255a' and 255b' of the device 200 and the issuer subsystem 300 may be any suitable shared secret available to the secure elements of the electronic device 200 and the issuer subsystem 300.

[0046] An AE subsystem 400 (e.g., credential protection subsystem 491) may be provisioned as an intermediary between issuer subsystem 300 and one or both of device 100 and device 200, and AE subsystem 400 may be configured to provide a new layer of security and / or provide a more seamless user experience when credentials are provisioned on device 100 or device 200, and / or when such provisioned credentials are used as part of transaction credential data communications from device 100 or device 200 to fund a recipient user account on issuer subsystem 300. AE subsystem 400 may be provided by any suitable administrative and / or commercial entity that may provide various services (e.g., via a user-specific identification and password combination) to users of user devices (e.g., device 100 and / or device 200) via user-specific login information to the administrative entity to a user-specific account. As just one example, AE subsystem 400 may be provided by Apple Inc. (Cupertino, CA), which may also be a provider of various management and / or other services to users of device 100 and / or device 200 (e.g., iTunes for selling / renting media to be played by one or each device). TM Store, Apple App Store for selling / renting applications used on device 100 TM Apple iCloud (e.g., for securely delivering applications to one or each device 420), for storing data from one or each device and / or associating users with devices and / or providing device protection services (e.g., using DP applications 113c on device 100) TM services (e.g., services of the device protection subsystem 471), the Apple online store for online purchase of various Apple products, Apple iMessage for transmitting media messages between devices TM Apple Pay service for securing and managing credential provisioning on one or each device and / or securely using transaction credential data from the device to facilitate further transactions with a recipient user account TM services (e.g., services of the credential protection subsystem 491, etc.), and it may also be a provider, manufacturer, and / or developer of the device 100 itself and / or the device 200 itself (e.g., when the device 100 and / or the device 200 is an iPod TM , iPad TM , iPhone TM , MacBook TM 、iMac TM , Apple Watch TMThe administrative or business entity that may provide the AE subsystem 400 (e.g., Apple Inc.) may be different from and independent of any credential issuing and / or financial entity of the issuer subsystem 300. For example, the administrative or business entity that may provide the AE subsystem 400 may be different from and independent of any payment network subsystem or issuing bank subsystem that may provide and / or manage any user account associated with any payment card or associated with any transaction credential to be provisioned on the user device 100 and / or the user device 200. The entity that may provide the AE subsystem 400 (e.g., Apple Inc.) may be distinct and independent of any merchant or SP subsystem (e.g., any SP entity that may provide a SP terminal for NFC communications, third-party applications for online communications, and / or any other aspect of the SP subsystem). Such a management entity may utilize or otherwise use its potential capabilities to configure or control various components of device 100 and / or device 200 (e.g., software components and / or hardware components of the devices, such as when the entity may at least partially generate or manage device 100 and / or device 200) in order to provide a more seamless user experience for a user of device 100 when it wishes to provision credentials provided by issuer subsystem 300 on device 100 and / or when such provisioned credentials are used as part of transaction credential data communications from device 100 for funding a recipient user account that may be associated with credentials provisioned by issuer subsystem 300 on device 200 and / or when device 100 may have any device protection services enabled (e.g., via DP application 113c) in order to facilitate any suitable device protection services through device protection subsystem 471. For example, in some embodiments, the device 100 may be configured to communicate with the AE subsystem 400 seamlessly and transparently to the user of the device 100 for sharing and / or receiving specific data that may achieve a higher level of security (e.g., during online-based transaction credential data communication between the device 100 and the issuer subsystem 300 and / or when the device 100 has been reported as lost or stolen). Although not shown, the AE subsystem 400 may also include or access processor components, communication components, I / O interfaces, buses, memory components, and / or power supply components, which may be the same or similar to such components of the device 100, one, some, or all of which may be provided at least in part by one, some, or each of the device protection subsystem 471 and the credential protection subsystem 491 and the transaction protection subsystem 481 of the AE subsystem 400.

[0047] In addition to provisioning at least one transaction credential on the first device 100 (e.g., a first user credential that is part of the first credential SSD 154a and has a credential key 155a' and credential information 161a), at least one access SSD 154c having an access key 155c may also be provisioned on the device 100 to more securely enable the device 100 to use the provisioned credentials to conduct financial or other secure transactions with remote entities. For example, access data may be provided on the device 100 directly from the AE subsystem 400 as at least a part of the access SSD 154c and may include an access applet 153c having the access key 155c. The AE subsystem 400 (e.g., the credential protection subsystem 491) may also have access to the access key 155c (e.g., for decrypting data encrypted by the device 100 using the access key 155c). The AE subsystem 400 may be responsible for managing the access keys 155c, which may include the generation, exchange, storage, use, and replacement of such keys. AE subsystem 400 may store its version of access key 155c in the secure element of AE subsystem 400. Access SSD 154c with access key 155c may be configured to determine the intent and local authentication of a user of device 100 (e.g., via one or more input components 110 of device 100, such as a biometric input component), and in response to such determination, it may be configured to implement another specific SSD for payment transactions (e.g., using the user's credentials of credential SSD 154a or SSD 154b). Storing such an access SSD within the secure element 145 of device 100 may improve its ability to reliably determine user intent and authentication for secure data transactions. In addition, access key 155c may be utilized to provide enhanced encryption for any transaction credential data that may be transmitted outside of the secure element of device 100. The access data may include an issuer security domain (“ISD”) key 156k of an ISD 152 of a secure element 145, which may also be maintained by the AE subsystem 400 and may be used in addition to or in lieu of access key 155c (or one or more other of access keys 155a, 155b, 151k, and 158k of device 100). Similarly, in addition to provisioning at least one transaction credential on the second device 200 (e.g., a second user credential that is part of the first credential SSD 254a and has credential key 255a′ and credential information 261a), at least one access SSD 254c having access key 255c may also be provisioned on the device 200 to more securely enable the device 200 to use the provisioned credentials to conduct financial or other secure transactions with a remote entity. For example, access data may be provided on device 200 directly from AE subsystem 400 as at least a portion of access SSD 254c, and may include access applet 253c having access key 255c.The AE subsystem 400 (e.g., the credential protection subsystem 491) may also have access to the access key 255c (e.g., for decrypting data encrypted by the device 200 using the access key 255c). The AE subsystem 400 may be responsible for managing the access key 255c, which may include the generation, exchange, storage, use, and replacement of such keys. The AE subsystem 400 may store its version of the access key 255c in the secure element of the AE subsystem 400. The access SSD 254c with the access key 255c may be configured to determine the intent and local authentication of the user of the device 200 (e.g., via one or more input components of the device 200, such as a biometric input component), and in response to such a determination, it may be configured to enable another specific SSD to conduct a payment transaction (e.g., using the user credentials of the credential SSD 254a or SSD 254b). By storing such an access SSD within the secure element 245 of the device 200, its ability to reliably determine the user's intent and authentication for secure data transactions may be improved. In addition, access key 255c may be utilized to provide enhanced encryption for any transaction credential data that may be transmitted outside of the secure element of device 200. The access data may include an issuer security domain ("ISD") key 256k of the ISD 252 of the secure element 245, which may also be maintained by the AE subsystem 400 and may be used in addition to or in lieu of access key 255c (or one or more other of access keys 255a, 255b, 251k, and 258k of device 200). It should be understood that each of any shared keys between the AR subsystem 400 and one of the devices 100 or 200 may be any suitable shared secret (e.g., a password, a passphrase, a randomly selected byte array, one or more symmetric keys, corresponding public-private keys (e.g., an asymmetric key), etc.) available to both or a respective one of the secure elements of the electronic device and the AE subsystem 400, which may be operable to enable any suitable encrypted data (e.g., a password) or any other suitable data to be independently generated by the electronic device and the AE subsystem 400 for any appropriate security purpose.

[0048] Figure 4 Description

[0049] Figure 4 Further details of various embodiments of the AE subsystem 400 with respect to system 1 are shown. Figure 4As shown, the AE subsystem 400 may be a secure platform system and may include a server 410, an online store 420, a secure mobile platform ("SMP") agent component 440, an SMP trusted service manager ("TSM") component 450, an SMP cryptographic service component 460, an identity management system ("IDMS") component 470, a fraud system component 480, and / or a hardware security module ("HSM") component 490. In some embodiments, one or more components of the AE subsystem 400 may be combined or omitted. In addition, the AE subsystem 400 may include components that are not combined or included in the AE subsystem 400. Figure 4 For example, the AE subsystem 400 may include any other suitable components or Figure 4 For simplicity, Figure 4 Only one component of each component is shown in FIG. One, some, or all components of the AE subsystem 400 may be implemented using one or more processor components, one or more memory components, and / or one or more communication components, wherein the processor components may be the same or similar to the processor component 102 of the device 100, the memory components may be the same or similar to the memory component 104 of the device 100, and the communication components may be the same or similar to the communication component 106 of the device 100. One, some, or all components of the AE subsystem 400 may be managed, owned, at least partially controlled, and / or otherwise provided by a single management or business entity (e.g., Apple Inc.) that may be different from and independent of the issuer subsystem 300. The components of the AE subsystem 400 may interact with each other and together with the issuer subsystem 300 and / or the electronic device 100 and / or the electronic device 200 to provide a new layer of security and / or provide a more seamless user experience. In some embodiments, one, some, or each of the device protection subsystem 471, the credential protection subsystem 491, and the transaction protection subsystem 481 may include its own processing components, memory components, communication components, store 420, SMP proxy component 440, SMP TSM component 450, SMP cryptographic services component 460, IDMS component 470, fraud system component 480, and / or HSM component 490. For example, each of the device protection subsystem 471, the credential protection subsystem 491, and the transaction protection subsystem 481 may be a discrete subsystem having its own processing components, its own memory components (e.g., its own secure element), and its own communication components.

[0050] The SMP agent component 440 of the AE subsystem 400 may be configured to manage user authentication using administrative or business entity user accounts. The SMP agent component 440 may also be configured to manage the lifecycle and provisioning of credentials on the device 100 and / or the device 200. The SMP agent component 440 may be a primary endpoint capable of controlling user interface elements (e.g., elements of the GUI 180) on the device 100 and / or the device 200. The operating system or other applications of the end-user device (e.g., the application 103, application 113, and / or application 143 of the device 100, and / or the application 203, application 213, and / or NFC application of the device 200) may be configured to call specific application programming interfaces ("APIs"), and the SMP agent 440 may be configured to process requests of those APIs and respond with data that may export the user interface of the device 100 and / or the device 200 and / or respond with an application protocol data unit ("APDU") that may communicate with the secure element 145 of the device 100 and / or the secure element 245 of the device 200. Such APDUs may be received by the AE subsystem 400 from the issuer subsystem 300 via the TSM of system 1 (e.g., the TSM of the communication path between the AE subsystem 400 and the issuer subsystem 300). The SMP TSM component 450 of the AE subsystem 400 may be configured to provide GlobalPlatform-based services or any other suitable services that may be used to perform credential provisioning operations on the device 100 and / or the device 200 from the issuer subsystem 300. The GlobalPlatform or any other suitable secure channel protocol may enable the SMP TSM component 450 to appropriately transmit and / or provision sensitive account data between the secure element 145 of the device 100 (or the secure element 245 of the device 200) and the TSM for secure data communication between the AE subsystem 400 and the issuer subsystem 300.

[0051] The SMP TSM component 450 may be configured to use the HSM component 490 to protect its keys and generate new keys (e.g., keys 151k, 155a-155c, 156k, 158k, 251k, 255a-255c, 256k, 258k, etc.). The SMP cryptographic services component 460 of the AE subsystem 400 may be configured to provide key management and cryptographic operations that may provide for user authentication and / or confidential data transfer between components of the system 1. The SMP cryptographic services component 460 may utilize the HSM component 490 for secure key storage and / or opaque cryptographic operations. The payment cryptographic services of the SMP cryptographic services component 460 may be configured to interact with the IDMS component 470 to retrieve information associated with a credit card on file or other types of commercial credentials associated with a user account of an administrative entity. IDMS component 470 or any other suitable component or subsystem of AE subsystem 400 (e.g., identity service (“IDS”) subsystem) may be configured to enable and / or manage any suitable device detection and / or communication between device 100 and one or more other devices (e.g., second user electronic device 200), such as identity service (“IDS”) transmission (e.g., using a management entity-specific service (or other entity-specific service) (e.g., iMessage from Apple Inc.) TM )). For example, certain devices may automatically or manually register with such services (e.g., all user devices in the ecosystem of the AE subsystem 400 may automatically register with the service), for example, using a unique social token of the device (e.g., a phone number associated with the device). Such services may provide end-to-end encryption mechanisms that may require active registration (e.g., using an IDS application (e.g., IDS applications 113d and 213d) on each participating device, such as a device marked with a social token, before device detection is achieved and / or before messages can be sent using the service. Figure 3181 of the device 100 GUI 180 screen 190). Such an IDS component or subsystem and / or any other appropriate server or portion of the AE subsystem 400 is operable to identify or otherwise look up the status of any credential provided on any electronic device associated with a given user account, etc., such that the AE subsystem 400 is operable to efficiently and effectively identify one or more payment credentials that are available for use with a particular device associated with a particular user account (e.g., multiple host devices of a family account with the AE subsystem 400). The fraud system component 480 of the AE subsystem 400 may be configured to perform an administrative entity fraud check on the transaction credential based on data known to the administrative entity regarding the transaction credential and / or the sender user and / or the sender user device and / or the recipient user and / or the associated sender user device (e.g., based on utilizing the administrative entity's data associated with the user account (e.g., transaction credential information) and / or any other appropriate data that may be under the control of the administrative entity and / or any other appropriate data that may not be under the control of the issuer subsystem 300). Fraud system component 480 may be configured to determine an administrative entity fraud score for a credential based on various factors or thresholds. AE subsystem 400 may include store 420, which may also be a provider of various services to users of device 100 and / or device 200 (e.g., iTunes for selling / renting media to be played by the device). TM Store, Apple AppStore for selling / renting applications for use on devices TMAs just one example, store 420 may be configured to manage application 113 and provide the application to device 100, where application 113 may be any suitable application, such as a banking application, an SP application, an email application, a text messaging application, an Internet application, a card management application, a device protection application, or any other suitable communication application. Server 410 may be used to store and / or process any suitable data. For example, a server of device protection subsystem 471 may access and process any suitable data of any suitable table or directory or data structure 473, and a server of credential protection subsystem 491 may access and process any suitable data of any suitable table or directory or data structure 493, and / or a server of transaction protection subsystem 481 may access and process any suitable data of any suitable table or directory or data structure 483. The communication setup 495 of the AE subsystem 400 may use any suitable communication protocol or combination of communication protocols to transmit data between components of the AE subsystem 400 and / or between the AE subsystem 400 and other components of the system 1 (e.g., the issuer subsystem 300 and / or the device 100 and / or the device 200 (e.g., via communication setup 9)).

[0052] Figure 5 Description

[0053] Figure 5is a flow chart of an illustrative process 500 for facilitating the transfer of funds between user accounts. Process 500 is shown as being implemented by a first device 100 (e.g., UI's and / or a sender's device 100 having a storage device 173 (e.g., memory 104 and / or a security element 145)), a second device 200 (e.g., U2's and / or a receiver's device 200 having a storage device 273 (e.g., memory 204 and / or a security element 245)), a CI subsystem 300 (e.g., a first issuing subsystem ("1st IS") 391 having a directory or table or data structure 393, a second issuing subsystem ("2nd IS") 392 having a directory or table or data structure 394, and a network directory or table or data structure 395), and an AE subsystem 400 (e.g., a device protection subsystem ("DPS") 471 having a DPS table 473, a transaction protection subsystem ("TPS") 481 having a TPS table 483, and a credential protection subsystem ("CPS") 491 having a CPS table 493). However, it should be understood that process 500 may be implemented using any other suitable components or subsystems. Process 500 may provide a seamless user experience for securely and efficiently facilitating a back-up transfer between a sender fund account associated with a sender device 100 and a receiver back-up account associated with a social identifier using device protection subsystem 471 and credential protection subsystem 491 of AE subsystem 400, while limiting the potential for privacy and / or security breaches by preventing AE subsystem 400 from storing information on AE subsystem 400 that could specifically link two or more specific users or accounts to a specific transfer. To facilitate the following regarding Figure 5 The following discussion of the operation of the system 1 for facilitating the transfer of funds between user accounts 500 is referenced Figure 1 , Figure 2 , Figure 2A , Figure 2B and Figure 4 A schematic diagram of the various components of the system 1, and reference Figures 4A-4H The contents of each system table or directory or data structure of the user device. A variety of graphical elements and visual schemes can be used to implement the described operations. Therefore, the described embodiments are not intended to be limited to the specific user interface conventions adopted herein. Instead, the embodiments can include a variety of user interface styles, including at least some or all non-visual user interface styles for user devices.

[0054] In operation 502 of process 500, any suitable first user device data 502d may be exchanged between device 100 and AE subsystem 400 (e.g., device protection subsystem 471 (as shown) and / or credential protection subsystem 491) for initializing, registering, and / or authenticating device 100 to AE subsystem 400 in any suitable manner. As described above, AE subsystem 400 may be provided by any suitable administrative and / or commercial entity, which may provide various services (e.g., via a user-specific identification and password combination) to a user of any user device (e.g., user U1 of device 100 and / or user U2 of device 200), such as via user-specific login information to the administrative entity to a user-specific account. Thus, in operation 502, device 100 may be associated with a specific account of user U1 at AE subsystem 400 in any suitable manner. For example, a user U1 of device 100 may log into his account on AE subsystem 400 (e.g., using an online resource on device 100), where user U1 may enter a first user identifier U1-ID, which may be any suitable data that can uniquely identify the first user U1 of AE subsystem 400 and / or any suitable first user password data U1-PW associated therewith (e.g., user-specific login information to a user-specific account of the management entity (e.g., via a user-specific identification and password combination, etc.)), and associate the user account data with any suitable device registration identifier or any suitable device The registration data is provided to the AE subsystem 400 together with a unique electronic device identifier ED1-ID of the device 100 (e.g., any unique identifier assigned to the device 100 (e.g., assigned by the AE subsystem 400), such as when the device is manufactured) and / or at least one social identifier or social token LT-1 associated with the device 100 for the user 1 (e.g., at least one phone number and / or email address) (e.g., any suitable device identification information 119), so that the device registration data of the device 100 can be associated with a verified specific user account of the user U1 on the AE subsystem 400 (e.g., the device protection subsystem 471). For example, as Figure 4A As shown, the storage device 173 of the device 100 may include the first user identifier U1-ID and the unique electronic device identifier ED1-ID and the social token LT-1 (for example, in a portion or entry 173a of the storage device 173), and as shown Figure 4CAs shown, the DPS table 473 of the device protection subsystem 471 can be updated in operation 502 with the unique electronic device identifier ED1-ID and / or the social token LT-1 (e.g., the first user identifier U1-ID and / or the first user password data U1-PW) of the verified user account data storage device 100 for the user U1, for example, by linking such data with any suitable data link in the first link data entry 473a of the DPS table 473. It should be understood that when any first data is described as being stored for any second data, such first data can be stored in association with such second data, so that there may be some relationship between the two data instances (e.g., so that one can be resolved for the other and / or so that one can be identified using the other). The AE subsystem 400 is operable to verify any or all device registration data (e.g., the unique electronic device identifier ED1-ID and / or the social token LT-1) of the device 100 in any suitable manner before linking the device registration data with the verified user account at the device protection subsystem 471.

[0055] In some embodiments of process 500, in addition to storing device registration data of device 100 for an authenticated user account of AE subsystem 400 (e.g., at device protection subsystem 471), access data may be supplied by AE subsystem 400 (e.g., by credential protection subsystem 491) on a secure element 145 of device 100 (e.g., in operation 502) to more securely enable device 100 to transfer funds. Such access data may be provisioned on the secure element 145 of the device 100 as at least a portion or all of access to the SSD 154c, and may include an access applet 153c and / or an access key 155c, an ISD key 156k for the ISD 152 and / or a CRS 151k for the CRS 151 and / or a CASD 158k for the CASD 158 and / or an access key 155a for the SSD 154a and / or an access key 155b for the SSD 155b, for enabling secure transmission between the AE subsystem 400 and the device 100 (e.g., used as any suitable commercial entity key or shared secret between the AE subsystem 400 and the host device 100). In some implementations, such access data may be performed when the device 100 is initially configured (e.g., by the AE subsystem 400 before the device 100 is sold to a user (e.g., user U1)). Alternatively, such accessing data may be performed at least in part in response to a user of device 100 initially setting up secure element 145 of NFC component 120 .

[0056] In operation 504, the device 100 may prompt or otherwise enable the user (e.g., via any suitable user interface) to add payment credentials to the secure element 145. Such prompts may be provided in any suitable manner (e.g., via any suitable user interface of the device 100) at any suitable time based on any suitable event. For example, when the user U1 launches a card management application 113b (e.g., a "wallet" or "card book" application), the application may provide prompt data to the user, which prompt data is operable to ask the user whether to provide new credentials on the device 100. Alternatively or additionally, when a new application (e.g., a new operating system application (e.g., application 103)) is loaded onto the device 100, the application is operable to prompt the user to register a new funds transfer function of the application, which may require or suggest adding at least one credential to the device 100, or otherwise associating a credential with the device 100 (e.g., with a social credential of the device 100). As another example, if the funds transfer request is initiated by another device (e.g., device 200), and the attempt indicates an attempt to transfer funds to a recipient identified by a social token (e.g., social token LT-1) associated with device 100, the AE subsystem 400 may instruct device 100 to prompt a user of device 100 to associate credentials with device 100 and / or at least with the social token to facilitate the attempted transfer of funds (e.g., as described in more detail regarding adding credentials to device 200 (e.g., in operation 543)).

[0057] In operation 506, first-user credential request data 506d may be generated at the device 100 and sent to the AE subsystem 400 (e.g., to the credential protection subsystem 491), wherein such first-user credential request data 506d is operable to request provisioning of one or more first-user credentials for the first user U1 on the device 100. For example, operation 506 may be performed, at least in part, when the first user U1 of the device 100 selects particular first-user credentials of the CI subsystem 300 (e.g., of the first issuance subsystem 391) to be provisioned on the device 100 (e.g., by interacting with the device 100 in any suitable manner). The first user credential request data 506d may include any suitable identification of the first user credentials to be provisioned (e.g., at least a portion of the primary account number (“PAN”) of an associated entity or other existing credentials (e.g., a physical credit card, etc.), PAN expiration date, CVV, etc.) and / or accept a new type of default credential to be added based on a new funds transfer feature enabled by the AE subsystem 400 (e.g., a new stored value credential to be created for the device 100), and the first user identifier U1-ID may be any suitable data that can uniquely identify the first user U1 of the AE subsystem 400, the unique electronic device identifier ED1-ID of the device 100, etc.

[0058] In operation 508, the AE subsystem 400 (e.g., the credential protection subsystem 491) may receive the first user credential request data 506d and process it to generate and send the first user credential request data 508d to the appropriate issuing subsystem of the credential issuer subsystem 300 for further processing of provisioning the requested credentials on the device 100. In some embodiments, the first user credential request data 508d may include any suitable data in addition to any data in the first user credential request data 506d that may identify the credentials to be provisioned. For example, the credential protection subsystem 491 may be operable to determine (e.g., generate and / or obtain (e.g., from the credential issuer subsystem 300 or from the device 100)) a unique user credential identifier (e.g., a unique user credential identifier PID-1a) that may uniquely identify the user credentials provisioned on the device 100 to the AE subsystem 400, but that alone may not enable the holder of the unique user credential identifier to fund a transaction using the user credentials. Such a unique user credential identifier may be any suitable data element of any suitable size, such as an 8 or 9 character alphanumeric string, which may be randomly or uniquely generated by the AE subsystem 400 or otherwise (e.g., by the device 100 or CI subsystem 300) to be associated with any suitable data indicating the first user U1 (e.g., the first user identifier U1-ID) and / or any suitable data indicating the device 100 (e.g., the unique electronic device identifier ED1-ID) that may be associated with the new credential provisioning request of the user credential request data 506d. For example, Figure 4DAs shown, the CPS table 493 of the credential protection subsystem 491 can be updated in operation 508 by storing the first user identifier U1-ID with or without the unique electronic device identifier ED1-ID for the unique user credential identifier PID-1a of the credentials requested to be provisioned on the device 100, for example, by linking such data with any suitable data link in the first link data entry 493a of the CPS table 493. In some embodiments, a verified social token (e.g., LT-1) associated with the device 100 can be stored by the CPS 491 for the unique user credential identifier PID-1a of the credentials requested to be provisioned on the device 100 and / or for the first user identifier U1-ID with or without the unique electronic device identifier ED1-ID (e.g., in the first link data entry 493a of the CPS table 493 in operation 508). In such embodiments, the verified social token may be included in the user credential request data 506d, or the CPS 491 may independently obtain the verified social token from the DPS 471 (e.g., from table 473 using the U1-ID and / or ED1-ID of the data 506d). Alternatively, such verified social token may be stored only by the DPS 471 of the AE subsystem 400 (e.g., in data entry 473a of the DPS table 473 in operation 502). The first user credential request data 508d that may be transmitted from the AE subsystem 400 to the CI subsystem 300 may include any suitable data from the AE subsystem 400 indicating the first device 100, such as the U1-ID, ED1-ID, and / or LT-1 (e.g., a verified social token associated with the device 100 on which the new credentials are to be provisioned). The verified social token (e.g., LT-1) may or may not be stored by the CPS 491 (e.g., in data entry 473a). Alternatively, the first user credential request data 508d that may be transmitted from the AE subsystem 400 (eg, CPS 491) to the CI subsystem 300 may not include a verified social token associated with the device 100 (eg, LT-1) on which the new credentials are to be provisioned.In such an embodiment, the CI subsystem 300 may or may not obtain or store such a verified social token (e.g., LT-1) (e.g., in entry 393a of table 393 and / or in entry 395a of network table 395) via any suitable technique independent of the CPS 491 (e.g., by communicating directly with the device 100 or user 1 of the device 100 (e.g., as may be identified by any suitable information in the first user credential request data 508d (e.g., U1-ID, ED1-ID, PID-1a, etc.) and / or any other information already accessible to the CI subsystem 30 (e.g., due to associating a funding account with the user (e.g., an account associated with the PAN identified by data 506d)))). In operation 508, the AE subsystem 400 may determine that a target issuing subsystem of the CI subsystem 300 will receive the first user credential request data 508d (e.g., based on any suitable target issuing subsystem information of the first user credential request data 506d received from the device 100 and / or based on any other suitable information used by the AE subsystem 400, such as the AE subsystem 400 may select an appropriate target issuing subsystem of the CI subsystem 300, which the AE subsystem 400 may select to generate a funding account on behalf of a user of the device 100 (e.g., a new stored value account will be created for the user)), and may then send the first user credential request data 508d to the target issuing subsystem of the CI subsystem 300.

[0059] In operation 510, the first user credential request data 508d may be received by the CI subsystem 300 and processed thereby (e.g., by the target issuing subsystem 391) to provision the requested user credentials on the device 100 while also associating the user credentials with a particular funding account of the CI subsystem 300, and while also sharing unique information indicative of the funding account with the AE subsystem 400. For example, the first user credential request data 508d transmitted from the AE subsystem 400 to the CI subsystem 300 may be operable to instruct the CI subsystem 300 (e.g., the appropriate issuing subsystem) to: (i) identify an existing funding account or establish a new funding account using a unique account token (“AT”) to be associated with the user credentials to be provisioned on the device 100, (ii) obtain a unique sending token (“AT”) that may be provisioned on the device 100 and associated with the account on the CI subsystem 300 and its unique account token, and (iii) obtain a unique receiving token (“RT”) that may be shared with the AE subsystem 400 and associated with the account on the CI subsystem 300 and its unique account token. The sending token ST can be any suitable data element of any suitable size that can be randomly or uniquely generated or otherwise obtained by the CI subsystem 300 to be associated with the account token AT of the fund account. For example, the sending token ST can be a DPAN or can contain a DPAN (e.g., a 16 to 19 character token that may be similar to a credit / debit card number that may be compatible with various card networks) and / or a device account reference ("DAR") (e.g., a well-formatted string that may contain a globally unique identifier ("GUID"), or a universally unique identifier ("UUID") (e.g., a 128-bit integer that can be used to identify one or more resources, and / or a code (e.g., a bank code) that can identify a specific source (e.g., an issuing subsystem). The sending token can be used to identify and authenticate the sender (e.g., credential data from credentials provisioned on the sender user device) at the sender issuing subsystem of the CI subsystem 300 to initiate a funds transfer from the sender fund account to another fund account, where the sending token can be a device-specific token that can uniquely identify the relationship between the sender device and the fund account. The receipt token RT may be any suitable data element of any suitable size that may be randomly or uniquely generated or otherwise obtained by the CI subsystem 300 to be associated with an account token AT of a fund account. For example, the receipt token RT may be or may include a recipient primary account number ("RPAN") (e.g., a 16 to 19 character token that may be similar to a credit / debit card number that may be compatible with various card networks) and / or a DAR, where the receipt token information itself may be user-anonymous and / or account-anonymous, such that the receipt token may not alone identify a particular user or a particular fund account.A receive token may be generated when an associated send token is provisioned onto a sender device.

[0060] The first user credential request data 508d is operable to enable the first issuing subsystem 391 to identify an existing funding account maintained by the issuing subsystem 391 (e.g., a funding account associated with the credit card credentials identified by user U1 in operation 506) or to generate a new funding account (e.g., a new stored value account or otherwise), wherein the funding account is operable to store and / or transmit and / or receive funds and may be defined, at least in part, by any suitable unique account token AT-1a (e.g., any suitable funding primary account number (“F-PAN”)). In operation 510, the CI subsystem 300 may generate and / or obtain a unique sending token ST-1a and a unique receiving token RT-1a for associating with the account token AT-1a of the funding account associated with the user credentials requested to be provisioned on the device 100, however, each of the unique receiving token RT-1a and the unique sending token ST-1a may not be associated with another account token of the subsystem 391. For example, if Figure 4F As shown, the CI table 393 of the first issuing subsystem 391 can be updated in operation 510 by storing a unique sending token ST-1a and a receiving token RT-1a for a unique account token AT-1a, for example, by linking such data with any suitable data link in the first link data entry 393a of the CI table 393. In some embodiments, in operation 510, any suitable information from the first user credential request data 508d may also be stored for AT-1a, ST-1a and / or RT-1a, such as a unique user credential identifier PID-1a for the credentials requested to be provisioned on device 100, a first user identifier U1-ID, a unique electronic device identifier ED1-ID and / or any suitable social token that may be associated with the owner or verified user of the credential associated with the funding account identified by account token AT-1a (e.g., a social token LT-1 of device 100 that may be provided by AE subsystem 400 (e.g., in data 508d) and / or any social token that may be verifiable by CI subsystem 300 and is independent of AE subsystem 400), for example, by linking such data with any suitable data link in the first link data entry 393a of CI table 393. In some embodiments, rather than being generated by the AE subsystem 400 and shared with the CI subsystem 300 (e.g., in operation 508), a unique user credential identifier PID-1a for credentials requested to be provisioned on the device 100 may be generated by the CI subsystem 300 (e.g., at operation 510) and then shared with the AE subsystem 400 (e.g., as part of data 512d in operation 512).

[0061] In operation 512, first user credential response data 512d can be sent from the CI subsystem 300 (e.g., the first issuance subsystem 391) to the AE subsystem 400 (e.g., the credential protection subsystem 491), wherein the first user credential response data 512d can include at least a unique receiving token RT-1a so as to share unique information linked to the funding account with the AE subsystem 400. The receiving token RT-1a may be unique to the AE subsystem 400 and may be stored by the AE subsystem 400 against any other suitable data for later use by the AE subsystem 400 to facilitate the secure and efficient transfer of funds between user accounts (e.g., the receiving token RT-1a of data 512d may be stored in the AE subsystem 400 such that the AE subsystem 400 is operable to identify the receiving token RT-1a using a particular social token LT-1 that is also associated with the user device 100 involved in the credential request (e.g., the receiving token RT-1a of data 512d may be stored directly against the social token LT-1 in any suitable table of the AE subsystem 400, and / or the receiving token RT-1a may be stored directly against any suitable first user device data associated with the user device 100 in a first table of the AE subsystem 400 (e.g., in a CPS 491 table 493 in entry 493a) (e.g., the first user identifier U1-ID and / or the unique electronic device identifier ED1-ID and / or the user credential identifier PID-1a), and the social token LT-1 can be stored directly in a second table of the AE subsystem 400 (e.g., in entry 473a of table 473 of the DPS 471) for the same first user device data (e.g., the first user identifier U1-ID and / or the unique electronic device identifier ED1-ID and / or the user credential identifier PID-1a))) so that such first user device data is subsequently used by the AE subsystem 400 to identify the receiving token RT-1a of the social token LT-1 (e.g., in operations 538 and 543). For example, in operation 514, the AE subsystem 400 (e.g., the credential protection subsystem 491) may store the received token RT-1a for the unique user credential identifier PID-1a of the credentials provisioned on the device 100 and / or for the first user identifier U1-ID and / or the unique electronic device identifier ED1-ID of the device 100. As described above, in some embodiments, the unique user credential identifier PID-1a may be generated by the CI subsystem 300 and may be included as part of the first user credential response data 512d transmitted to the AE subsystem 400 in operation 512. For example, as Figure 4DAs shown, the CPS table 493 of the credential protection subsystem 491 can be updated in operation 514 by storing a received token RT-1a of first user credential response data 512d for a unique user credential identifier PID-1a of the credentials provisioned on the device 100 and a first user identifier U1-ID with or without a unique electronic device identifier ED1-ID, for example, by linking such data with any suitable data link in the first linked data entry 493a of the CPS table 493. Thus, the CPS table 493 may include a link (e.g., in the first link data entry 493a) between information indicating a verified user of the device 100 (i.e., the first user identifier U1-ID) and unique information (i.e., the receiving token RT-1a) that is linked to but not independently indicating a funding account (i.e., the account token AT-1a) on the CI subsystem 300, and is also associated with user credentials provisioned on the device 100 (e.g., the sending token ST-1a) and other unique information associated with the receiving token but not independently indicating the receiving token (i.e., the unique user credential identifier PID-1a), wherein the link may subsequently be used by the process 500 (e.g., in one or more of operations 543, 544, 545, and 546) to securely and efficiently facilitate the transfer of funds from one user account to another user account.

[0062] In addition or alternatively to operation 512, in operation 513, alternative first user credential response data 513d may be sent from the first issuing subsystem 391 to the network table 395 (e.g., a table of the CI subsystem 300, or other means in the system 1), wherein the alternative first user credential response data 513d may include at least a unique receiving token RT-1a to share unique information indicating a funding account with the network table 395. The receiving token RT-1a may be unique to the network table 395 and may be stored in the network table 395 for any other suitable data for later use by the network table 395 to facilitate the secure and efficient transfer of funds between user accounts. For example, in operation 513, network table 395 (e.g., a portion of CI subsystem 300 that may be different for each issuing subsystem of CI subsystem 300, or may be a portion of a particular issuing subsystem of CI subsystem 300 or any other suitable subsystem of system 1 (not shown)) may store the received token RT-1a for one or more social tokens associated with the funding account of account token AT-1a (e.g., as verified by issuing subsystem 391), such as social token LT-1, and for a unique issuing subsystem identifier BID-1 that may uniquely identify the first issuing subsystem 391 (e.g., the source of the received token RT-1a) on network table 395. For example, as Figure 4HAs shown, the network table 395 can be updated in operation 513 by storing a received token RT-1a of alternative first user credential response data 513d for the unique issuing subsystem identifier BID-1 of the first issuing subsystem 391 and at least one social token LT-1 and / or associated PID-1a provided by the first issuing subsystem 391, for example, by linking such data with any suitable data link in the first link data entry 395a of the network table 395. Thus, the network table 395 may include a link (e.g., in the first link data entry 395a) between information indicating a verified social token of the device 100 (i.e., social token LT-1) and unique information (i.e., receiving token RT-1a) that is linked to, but not independently indicates, a funding account (i.e., account token AT-1a) on the CI subsystem 300, which is also linked to the user credentials provisioned on the device 100 (i.e., sending token ST-1a) and other unique information indicating the source issuing subsystem of the funding account (i.e., the unique issuing subsystem identifier BID-1 of the first issuing subsystem 391), wherein the link may be subsequently used by the process 500 (e.g., in operation 547) to securely and efficiently facilitate the transfer of funds from one user account to another user account. The network directory of the network table 395 may use any appropriate social token (e.g., email address, mobile phone number, etc.) to facilitate the transfer of funds between customers of the same or different financial institutions and payment service providers. The issuing subsystem may register one or more social tokens of a user with a specific account token of a specific funding account of the issuing subsystem, and may be used as a profile identifier in the network directory.

[0063] In operation 516, in some embodiments, via the AE subsystem 400 (e.g., via the CPS 491), first user credential data 516d may be provisioned on the device 100 by the first issuing subsystem 391 of the CI subsystem 300. For example, such first user credential data 516d may be provisioned at least in part on the secure element 145 of the device 100 directly from the first issuing subsystem 391. Such first user credential data 516d may be provisioned on the secure element 145 at least in part as at least a portion or all of the first credential SSD 154a, and may include a credential applet 153a having credential information 161a and / or credential key 155a' and / or key 155ak. In some embodiments, the first user credential data 516d may also include an access key 155a, which may be initially provided from the AE subsystem 400 to the issuer subsystem 300 and / or may be added by the AE subsystem 400. Such first user credential data 516d may include a sending token ST-1a (e.g., a unique identifier associated with an account token AT-1a (e.g., F-PAN) of a funding account on the CI subsystem 300 and which may be specifically used to provision payment credentials on a particular user device) as at least a portion of the credential information of the provisioned payment credential (e.g., credential information 161a of applet 153a), an AID (e.g., AID 155aa of applet 153a that provisions payment credential data on SSD 154a), an SSD identifier, and / or an SSD counter. Additionally, in some embodiments, such first user credential data 516d may include other unique information associated with, but not indicative of, a received token (i.e., a unique user credential identifier PID-1a) associated with the sending token ST-1a, which may be initially provided from the device 100 to the AE subsystem 400 (e.g., in operation 506) and / or initially provided from the AE subsystem 400 to the issuer subsystem 300 (e.g., in operation 508) and / or may be added by the AE subsystem 400 (e.g., in operation 516). For example, Figure 4AAs shown, the storage 173 of the device 100 may be updated to include a sending token ST-1a linked to or stored for a unique user credential identifier PID-1a (e.g., in a portion or entry 173b of the storage 173, which may span the secure element 145 and memory 104 of the device 100), where the link may be later used by the process 500 (e.g., in operation 544, as described with respect to a similar entry 273a of the storage 273 of the device 200) to securely and efficiently facilitate the transfer of funds from one user account to another user account. It should be understood that the sending token ST-1a may be considered or otherwise referred to herein as a "virtual" credential or virtual PAN or device PAN ("D-PAN") or a sending device PAN ("SD-PAN") that may be provisioned on the device 100, rather than a user's "actual" credential or actual PAN or fund PAN ("F-PAN") (e.g., account token AT-1a). For example, once it is determined that credentials are to be provisioned on device 100, a virtual credential (rather than an actual credential) may be requested (e.g., by issuer subsystem 300, by AE subsystem 400, and / or by a user of device 100) to be generated, linked to an actual credential, and provisioned on device 100 for later use in a financial transaction. Similarly, it should be understood that receiving token RT-1a may be considered or otherwise referred to herein as a "virtual" credential or virtual PAN or a receiving PAN ("R-PAN") that may be shared by CI subsystem 300 with AE subsystem 400 and / or with network table 395, rather than a user's "actual" credential or actual PAN or financial PAN ("F-PAN") (e.g., account token AT-1a). For example, once it is determined that credentials are to be provided on device 100, a virtual receipt credential (rather than an actual credential) may be requested (e.g., by issuer subsystem 300, by AE subsystem 400, and / or by a user of device 100) to be generated, linked to the actual credential, and shared with AE subsystem 400 and / or table 395 for later use in a funding transaction. Such creation and linking of one or more virtual credentials with actual credentials may be performed by any suitable component of issuer subsystem 300.For example, a network subsystem of issuer subsystem 300 (e.g., a particular payment network subsystem that may be associated with a brand of actual credentials) may define and store in table 393 a link that may create an association between the actual credential and at least one virtual credential such that any time a transaction is funded using a virtual credential (e.g., sending a token and / or receiving a token), the payment network subsystem may receive an authorization or verification request or otherwise attempt to verify any received data indicative of the virtual credential (e.g., in one or more of operations 548 through 552) and may analyze the verification attempt request in accordance with the actual credential associated with the virtual credential as determined by table 393. Alternatively, such a table may be accessed and / or similarly utilized or otherwise used by an appropriate issuing subsystem (e.g., issuing subsystem 391 or 392) or any other appropriate subsystem accessible to CI subsystem 300. By provisioning virtual credentials rather than actual credentials on device 100 and / or AE subsystem 400, CI subsystem 300 can be configured to limit fraudulent activity that may result when an unauthorized user intercepts the virtual credentials because the payment network subsystem or issuing subsystem can be configured to utilize table 393 to link the virtual credentials to the actual credentials only during specific transactions, such as when the CI subsystem 300 receives the virtual credentials from the AE subsystem 400.

[0064] One or more additional credentials may be provisioned on device 100 similarly (e.g., via AE subsystem 400) from first issuing subsystem 391 and / or from second issuing subsystem 392. Although operations 504 to 516 may be described with respect to provisioning a first payment credential on SSD 154a of device 100 from first issuing subsystem 391 (e.g., via AE subsystem 400), which first payment credential may include various of AT-1a, ST-1a, RT-1a, PID-1a, U1-ID, ED1-ID, LT-1, BID-1, etc. generated and / or stored in one or more of entry 173b of storage 173, entry 493a of table 493, entry 393a of table 393, and entry 395a of table 395, it should be understood that two or more payment credentials may be provisioned on device 100. For example, although not described in Figure 5, but process 500 may include at least one additional iteration of operations similar to operations 504 through 516 that may provision at least one additional payment credential on device 100. As just one specific example, a second credential may be provisioned on SSD 154b of device 100 from first issuing subsystem 391 (e.g., via AE subsystem 400), which second credential may include various AT-1b, ST-1b, RT-1b, PID-1b, U1-ID, ED1-ID, LT-1, BID-1, etc. generated and / or stored in one or more of entry 173c of storage 173, entry 493b of table 493, entry 393b of table 393, and entry 395b of table 395, where the second account token AT-1b may be used similarly to the first account token AT-1a, but with a different value, the second sending token ST-1b may be used similarly to the first sending token ST-1a, but with a different value, the second receiving token RT-1b may be used similarly to the first receiving token RT-1a, but with a different value, and the second unique user credential identifier PID-1b may be used similarly to the first unique user credential identifier PID-1a, but with a different value.

[0065] One or more credentials may similarly be provisioned on device 200 from first issuing subsystem 391 and / or from second issuing subsystem 392 (eg, via AE subsystem 400). Although operations 502 to 516 may be described with respect to registering a first user U1 and device 100 with the AE subsystem 400 and then provisioning first payment credentials on the SSD 154a of the device 100 from the first issuing subsystem 391 (e.g., via the AE subsystem 400), the first payment credentials may include various AT-1a, ST-1a, RT-1a, PID-1a, U1-ID, U1-PW, ED1-ID, LT-1, BID-1, etc. generated and / or stored in one or more of entries 173a and 173b of the storage device 173, table 473 and entry 473a, entry 493a of table 493, entry 393a of table 393, and entry 395a of table 395, it should be understood that a second user U2 and device 200 may be registered with the AE subsystem 400 and one or more payment credentials may be similarly provisioned on the device 200. For example, as shown in operations 518 to 532, which may be similar to operations 502 to 516, the device 200 and the user U2 may register with the AE subsystem 400 (e.g., using U2-ID, U2-PW, ED2-ID and / or LT-2) and may provide payment credentials on the SSD 254a of the device 200 from the second issuance subsystem 392 (e.g., via the AE subsystem 400), which payment credentials may include various of the generated and transmitted data 518d, 522d, 524d, 528d, 529d and / or 532d and entries 273a and 273b of the storage device 273 of the device 200, entry 473b of table 473, entry 493c of table 493, entry 394a of table 394 of the second issuance subsystem 392, and entry 395c of table 395 One or more of AT-2a, ST-2a, RT-2a, PID-2a, U2-ID, U2-PW, ED2-ID, LT-2, BID-2, etc., wherein the second user identifier U2-ID of user U2 can be used similarly to the first user identifier U1-ID of user U1, but with a different value, the second user password data U2-PW of user U2 can be used similarly to the first user password data Ui-PW of user U1, but with a different value, the second unique electronic device identifier ED2-ID of device 200 can be used similarly to the first unique electronic device identifier ED1-ID of device 100, but with a different value, and the second social token LT-2 of device 200 can be used similarly to the first social token LT-1 of device 100, but with a different value.

[0066] One or more additional credentials may be provisioned on device 200 similarly (e.g., via AE subsystem 400) from first issuing subsystem 391 and / or from second issuing subsystem 392. Although operations 520 to 532 may be described with respect to provisioning a first payment credential on SSD 254a of device 200 from second issuing subsystem 392 (e.g., via AE subsystem 400), which first payment credential may include various of AT-2a, ST-2a, RT-2a, PID-2a, U2-ID, ED2-ID, LT-2, BID-2, etc. generated and / or stored in one or more of entry 273b of storage 273, entry 493c of table 493, entry 394a of table 394, and entry 395c of table 395, it should be understood that two or more payment credentials may be provisioned on device 200. For example, although not described in Figure 5 , but process 500 may include at least one additional iteration of operations similar to operations 520 through 532 that may provision at least one additional payment credential on device 200. As just one specific example, another credential can be provisioned on the SSD 254b of the device 200 from the first issuing subsystem 391 (e.g., via the AE subsystem 400), which second credential can include various AT-2b, ST-2b, RT-2b, PID-2b, U2-ID, ED2-ID, LT-2, BID-1, etc. generated and / or stored in one or more of entry 273c of the storage device 273, entry 493d of the table 493, entry 393c of the table 393, and entry 395d of the table 395, where the account token AT-2b can be used similarly to the account token AT-2a, but with a different value, the sending token ST-2b can be used similarly to the sending token ST-2a, but with a different value, the receiving token RT-2b can be used similarly to the receiving token RT-2a, but with a different value, and the unique user credential identifier PID-2b can be used similarly to the unique user credential identifier PID-2a, but with a different value.

[0067] Thus, each user device of system 1 registered with AE subsystem 400 may have payment credentials including a unique sending token provisioned on the user device by the issuing subsystem of CI subsystem 300. Each sending token may be linked to a funding account (e.g., a unique funding account) associated with a unique account token and a unique receiving token at CI subsystem 300. The sending token provisioned on the sending device may be used by the device to identify a uniquely linked funding account on CI subsystem 300 that will be used to fund funds transferred to another funding account. The receiving token for each funding account may be linked at AE subsystem 400 to one or more social tokens of one or more user devices registered at AE subsystem 400. When a social token is identified at AE subsystem 400 for account-to-account transfers, AE subsystem 400 may identify an appropriate receiving token linked to the social token, which may then be shared with CI subsystem 300 so that CI subsystem 300 may use the receiving token to identify a uniquely linked funding account at CI subsystem 300 that will be used to receive funds in account-to-account transfers.

[0068] The funds transfer may be initiated by a user of a user device selecting payment credentials provisioned on the user device, selecting an amount of funds to be transferred from a funding account associated with the selected payment credentials, and identifying a social token of a recipient that may be associated with another funding account for receiving the funds transfer. For example, in operation 534 of process 500, a first or sending device 100 may prompt or otherwise enable user U1 (e.g., via any suitable user interface) to select payment credentials provisioned on device 100 (e.g., one of the first payment credentials provisioned on SSD 154a, which may include a sending token ST-1a (e.g., in entry 173b of storage 173 of device 100), which may be linked to a key of an account token AT-1a of a particular account at a first issuing subsystem 391 (e.g., in table entry 393a of table 393 of subsystem 391), and a key of an account token AT-1a of a particular account at a first issuing subsystem 391 (e.g., in table entry 393a of table 393 of subsystem 391). 154b, which may include a sending token ST-1b (e.g., in entry 173c of storage 173 of device 100), which may be linked to an account token AT-1b of another particular account at first issuing subsystem 391 (e.g., in table entry 393b of table 393 of subsystem 391) and a selection of an amount of funds to be transferred from an account associated with the selected payment credential and a social token identifying a recipient that may be associated with another account to receive the funds to be transferred. Such a prompt may be provided at any suitable time and in any suitable manner (e.g., via any suitable user interface of device 100) based on any suitable event or at the discretion of the user. For example, when user U1 launches a card management application 113b (e.g., a "wallet" or "card book" application (e.g., when a social token provided by Figure 3 185 ), the application may provide prompt data to the user, the prompt data being operable to inquire whether the user wants to use pre-provisioned credentials to transfer funds to a particular user, for example, wherein, along with selecting a particular pre-provisioned payment credential (e.g., Send Token ST-1a or Send Token ST-1b), the user may enter or otherwise select a particular amount of funds (e.g., $50), and the user may enter or otherwise select (e.g., from a drop-down list or UI of a contacts application or other suitable data source available to the device 100) at least a particular social token or a recipient identifier associated with the particular social token. Alternatively or additionally, when the user U1 is using an IDS application 113d (e.g., “Messaging” or other suitable communication application (e.g., in a chat application provided by Figure 3The device 100 may communicate from the device 100 to a specific other user identified by a specific social token (e.g., a specific phone number or email address, etc.) after using a "messaging" application indicated by a specific icon 184 of the device 100, which specific social token may be used by the messaging application to locate the other user (e.g., the recipient user) (e.g., via the IDS application 213d on the identification 200 associated with the social token LT-2), the messaging application of the device 100 may provide prompt data to the user (e.g., the sender user), the prompt data being operable to ask the user whether to transfer funds using pre-provisioned credentials Transfer to a specific user (e.g., a recipient user) with whom the messaging application is currently communicating, for example, where the communication identifies that funds are to be sent to an account associated with a social token for which the messaging application is currently being directed, the user may enter or otherwise select a specific amount of funds (e.g., $50), and the user may select (e.g., from a drop-down list or UI of a wallet application or other suitable data source available to the device 100) specific provisioned payment credentials of the device 100 that will be used to fund the funds transfer (e.g., Send Token ST-1a or Send Token ST-1b). Alternatively or additionally, the details of the funds transfer to be initiated by the device 100 may be identified in any other suitable manner via any suitable user interface scenario, such as in an email or any other suitable communication medium.

[0069] In one specific example of process 500 that may be used in much of the description of the remaining operations of process 500, a funding account identified by account token AT-1a at first issuing subsystem 391 may be created in device 100 (e.g., see Figure 4F 393a) with the funding account identified by the account token AT-2a at the second issuing subsystem 392 (e.g., see Figure 4G For example, user U1 of device 100 (e.g., in operation 534) may identify a sender fund account that should be transferred from the sender fund account associated with the identified first payment credential provisioned on SSD 154a of sender device 100 (e.g., the payment credential provisioned on device 100 including sending token ST-1a (see, e.g., Figure 4A 1)) transfers an amount of $50 to a recipient account associated with the identified social token LT-2 (e.g., a phone number that may be associated with a contact known to user U1 and that may be registered at AE subsystem 400 to user 2 and device 200 (e.g., see Figure 4B The entry 273a of the storage device 273 and / or Figure 4CEntry 473b) of table 473 of

[0070] Once the payment credentials provisioned on device 100 are identified for funding a funds transfer in operation 534, along with the amount of funds to be transferred and any suitable recipient information operable to identify a social token associated with an account for receiving the funds to be transferred, in operation 536, any suitable first user device transfer funds request data 536d may be generated and transmitted from device 100 (e.g., to AE subsystem 400) to perform the transfer. Continuing with the above-mentioned process for transferring funds from a funding account identified by account token AT-1a at first issuing subsystem 391 (e.g., see Figure 4F 393a of table 393 of ) and at the second issuing subsystem 392 from the funding account identified by the account token AT-2a (e.g., see Figure 4GIn the specific example of transferring $50 in entry 394a of table 394 of FIG. 154 , due to user U1 of device 100 identifying $50 to be transferred from a sender funds account associated with a payment credential provisioned on SSD 154a of sender device 100, including sending token ST-1a to a recipient account associated with the identified social token LT-2, specific first user device transfer funds request data 536d may be generated at and transmitted from device 100 indicating such transfer request. That is, for example, device transfer funds request data 536d may include any suitable funds amount data indicating the selected $50 value, any suitable recipient identification data indicating the selected social token LT-2, and any suitable sender device payment credential data indicating the selected provisioned payment credential on device 100 including the sending token ST-1a of SSD 154a. For example, such sender device payment credential data of the device transfer funds request data 536d generated by device 100 may include data operable to securely prove proper ownership of a particular secure element credential of device 100 (e.g., a credential of SSD 154a of secure element 145 of device 100) and any suitable data necessary to make a payment with that credential, including, but not limited to: (i) token data (e.g., a sending token ST-1a (e.g., a virtual DPAN), with or without any other suitable data of SSD 154a, such as a PAN expiration date, a card security code (e.g., a card verification code (“CVV”)), and / or a name and / or address associated with the credential of credential information 161a of SSD 154a); and (ii) encrypted data (e.g., data that may be sent by secure element 145 using SSD 154a); 154a and a shared secret of the issuer subsystem 300 (e.g., a cryptogram generated from the credential key 155a' of the first issuer subsystem 391) and any other suitable information (e.g., some or all of the token data, information identifying device 100 (e.g., ED1-ID), information identifying the selected transfer amount (e.g., $50), any suitable counter value, a random number, etc.), which may be available to device 100 or may be available to the issuer subsystem 300 to independently generate encrypted data using the shared secret (e.g., to verify the sender device payment credential data from device 100 (e.g., in operation 548)).

[0071] If user U1 is willing and able to select or confirm particular payment credentials of device 100 to be used to fund the potential transaction, operation 536 may receive intent and authentication of user U1 of device 100 to use the selected payment credentials through any appropriate user interaction with device 100. Access SSD 154c may utilize or otherwise use applet 153c of device 100 to determine whether such authentication has occurred before allowing other SSDs 154 (e.g., credential SSD 154a) to be used to enable its credential information in device transfer funds request data communications. As just one example, applet 153c of access SSD 154c may be configured to determine intent and local authentication of a user of device 100 (e.g., via one or more input components 110 such as may be used to perform user interactions with any application of device 100 (e.g., card management application 113b of device 100) Figure 3110i), and in response to such a determination, it may be configured to enable another specific SSD to conduct a payment transaction (e.g., utilizing the payment credential of credential SSD 154a). Next, once the intent and authentication for the specific payment credential has been received, operation 536 may include the device 100 generating, encrypting, and transmitting device transfer funds request data 536d for use by the AE subsystem 400. Once the specific payment credential SSD 154a on the secure element 145 of the device 100 has been selected, authenticated, and / or enabled for use in a transaction, the secure element 145 of the device 100 (e.g., the processor module 142 of the NFC component 120) may generate and encrypt specific credential data for the selected payment credential for use by the AE subsystem 400. For example, as described above, the sender device payment credential data of the device transfer funds request data 536d can be generated by the selected SSD 154a to include any suitable token data indicating the sending token ST-1a and encrypted data that can be generated and / or at least partially encrypted using the credential key 155a', such that such encrypted sender device payment credential data can only be decrypted by an entity that has access to the credential key 155a' (e.g., the first issuing subsystem 391 of the issuing subsystem 300) to access the sender device payment credential data. In some embodiments, once some or all of the sender device payment credential data of credential SSD 154a has been encrypted into CI-encrypted sender device payment credential data (e.g., any suitable fund amount data indicating the selected $50 value, any suitable recipient identification data indicating the selected social token LT-2, any suitable sender device data indicating ED1-ID and / or U1-ID, any suitable task authorization key (e.g., any suitable unique identifier of device 100 (e.g., device transfer unique identifier FX1-ID) and any suitable hash of the selected social token LT-2), a unique key can be provided for a specific combination of sender device 100 and recipient social token LT-2 for the current transaction, etc.), then in operation 536, the sender device payment credential data can be encrypted using credential key 155a'. 158k signature) encrypts the CI encrypted sender device payment credential data into AE encrypted sender device payment credential data alone or together with any other appropriate transmission data.For example, the secure element 145 of the device 100 (e.g., the processor module 142 of the NFC component 120) can use the access information to not only encrypt the $50 of funds to be transferred and the identification of the recipient social token LT-2 and / or ED1-ID and / or U1-ID and / or the transfer task authorization key, but also transfer the CI-encrypted sender device payment credential data of the SSD 154a to AE-encrypted sender device payment credential data. Any appropriate sender device payment credential data (e.g., token and encrypted data) of the selected SSD 154a (e.g., CI encrypted sender device payment credential data (e.g., encrypted by credential key 155a'), then whether encrypted as AE encrypted sender device payment credential data (e.g., encrypted by access key)) can then be communicated along with any additional information, such as, identification of the $50 in funds to be transferred and / or identification of the recipient social token LT-2 and / or ED1-ID and / or U1-ID and / or identification of the task authorization key to be transferred, as in operation 536, device transfer funds request data 536d from device 100 to AE subsystem 400.

[0072] Thus, at least a portion of the device transfer funds request data 536d (e.g., AE-encrypted sender device payment credential data) can only be decrypted by an entity that has access to access information for AE encryption (e.g., access key 155a, access key 155c, ISD key 156k, CRS151k and / or CASD 158k), which access information generated the AE encryption of any AE-encrypted sender device payment credential data of the device transfer funds request data 536d (e.g., AE subsystem 400), and / or at least a portion of the device payment funds request data 536d (e.g., CI-encrypted sender device payment credential data) can only be decrypted by an entity that has access to credential key information for CI encryption (e.g., credential key 155a'), which CI encryption generated the token of any CI-encrypted sender device payment credential data of the device transfer funds request data 536d (e.g., CI subsystem 300). Such device transfer funds request data 536d may be generated in operation 536 and then sent to the AE subsystem 400 to ensure that any such device transfer funds request data 536d has first been encrypted so that it cannot be decrypted by another portion of the device 100 (e.g., by the processor 102). That is, at least the sender device payment credential data of the device transfer funds request data 536d may be encrypted as CI-encrypted sender device payment credential data with credential key 155a', which may not be exposed to or accessed by any portion outside of the secure element of the device 100. In addition, at least a portion of the device transfer funds request data 536d may be encrypted as AE-encrypted data (e.g., access keys 155b, 155c, 156k, 151k, and / or 158k (e.g., referred to herein as "access information")) using an access key that may not be exposed to or accessed by any portion outside of the secure element of the device 100. In some embodiments, a transfer may be initiated by a potential recipient sending a request for funds to a sender device (e.g., via a text message, email, etc.), and the social token of the recipient sending the request and / or the amount of funds identified in the recipient's request may be automatically used to define a portion of any device transfer funds request data 536d that may be sent in response to the request. In some embodiments, as described above, the device transfer funds request data 536d may be defined at least in part by or communicated using a messaging application with which a user of device 100 may interact. At least a portion of such device transfer funds request data 536d may include any suitable messaging data (e.g., characters, emoticons, or picture data) selected by the user for communication as part of a message sent to the recipient device along with the funds.

[0073] The device transfer funds request data 536d may be received and processed by the device protection subsystem 471 to generate and transmit updated device transfer funds request data 538d to the credential protection subsystem 491 in operation 538. Such operation 538 may include the device protection subsystem 471 identifying the selected recipient social token from the device transfer funds request data 536d, and using the identified recipient social token to identify the recipient user identifier associated with the identified recipient social token (e.g., identifying the recipient social token LT-2 from the device transfer funds request data 536d, and then identifying the recipient user identifier U2-ID associated with the device protection subsystem 471 (e.g., in the device transfer funds request data 536d). Figure 4CWhen the device transfer funds request data 536d is updated to the updated device transfer funds request data 538d, the recipient social token of the identified device transfer funds request data 536d may be replaced with the identified recipient user identifier, so that the credential protection subsystem 491 may not receive the recipient social token of the device transfer funds request data 536d (e.g., so that the receiving token may not be linked to the recipient social token on the credential protection subsystem 491, but instead, the receiving token may be linked to the recipient user identifier of the AE subsystem 400 at the credential protection subsystem 491, and it may not independently reveal the identity of the recipient user like the receiving social token does (e.g., to prevent any particular subsystem of the AE subsystem 400 from linking information indicating a particular user to information indicating a particular funding account)). In some embodiments, prior to transmitting the updated device transfer funds request data 538d to the credential protection subsystem 491, at least a portion of the device transfer funds request data 536d (e.g., at least a portion of any portion of the data 536d was encrypted by any access information of the device 100) may be decrypted in operation 538 using appropriate access information available to the device protection subsystem 471. Additionally or alternatively, in some embodiments, upon receiving the updated device transfer funds request data 538d, at least a portion of the updated device transfer funds request data 538d (e.g., at least a portion of any portion of the data 536d was encrypted by any access information of the device 100) may be decrypted in operation 538 using appropriate access information available to the credential protection subsystem 491. Prior to communicating with the AE subsystem 400 in operation 536, any such encryption of at least a portion of the device transfer funds request data 536d is performed at the device 100 using the access information as AE-encrypted sender device payment credential data (e.g., access key 155a for SSD 154a, access key 155c for accessing SSD 154c, ISD key 156k, CRS151k and / or CASD 158k), and any such decryption of such information is subsequently performed at the AE subsystem 400 using the counterpart access information, so that at least a portion of the device transfer funds request data 536d between the device 100 and the AE subsystem 400 can be securely communicated.

[0074] In operation 543, the credential protection subsystem 491 may process the recipient user identifier of the updated device transfer funds request data 538d to identify at least one receiving token that may be associated with the recipient user identifier identified on the credential protection subsystem 491. For example, continuing with the main example introduced above, where the recipient user identifier of the updated device transfer funds request data 538d may be a recipient user identifier U2-ID (e.g., a recipient user identifier that may be identified by the device protection subsystem 471 as being associated with the recipient social token LT-2 of the device transfer funds request data 536d (e.g., in entry 473b of table 473)), then the credential protection subsystem 491 may operate in operation 543 to identify that each of the receiving token RT-2a in entry 493c and the receiving token RT-2b in entry 493d of table 493 is linked to the recipient user identifier U2-ID of the updated device transfer funds request data 538d. In such an instance, when more than one receiving token is identified at the credential protection subsystem 491 to be associated with the recipient user identifier U2-ID of the device transfer funds request data, the AE subsystem 400 may then be operable in operation 544 to communicate with at least one user device that may be associated with the recipient user identifier U2-ID (e.g., registered at the AE subsystem 400) to determine (e.g., prompt a user of such device to select) which of the recipient funds accounts associated with the identified receiving tokens should be used to receive the transferred funds. For example, using the recipient user identifier U2-ID and / or the unique electronic device identifier ED2-ID and / or the unique user credential identifier PID-2a and / or any other suitable data associated with the receiving token RT-2a of entry 493c (e.g., in Table 473 and / or Table 493), and using the recipient user identifier U2-ID and / or the unique electronic device identifier ED2-ID and / or the unique user credential identifier PID-2b and / or any other suitable data associated with the receiving token RT-2b of entry 493d (e.g., in Table 473 and / or Table 493), the AE subsystem 400 can communicate with the device 200 to determine which of the payment credentials provisioned on the device 200 and associated with such unique user credential identifiers PID-2a and PID-2 (e.g., one of the payment credentials on the SSD 254a with ST-2a and the payment credentials on the SSD 254b with ST-2b) should be used to determine the funding account that will receive the funds to be transferred.Such determination may be accomplished by providing any suitable prompt to a user of device 200 via any suitable user interface of device 200 (e.g., via a push notification or other means to card management application 213b, etc.) that may enable the user of device 200 to selectively select a particular one of those provisioned payment credentials in order to identify its associated funding account as the account to receive the funds to be transferred. Such selection by device 200 may return a particular unique user credential identifier (e.g., a selected one of unique user credential identifiers PID-2a and PID-2b) to AE subsystem 400, which credential protection subsystem 491 may then ultimately identify an appropriate receiving token for conducting the funds transaction (e.g., if device 200 selects provisioned payment credentials associated with unique user credential identifier PID-2a, then in operation 544, unique user credential identifier PID-2a may be transmitted back to AE subsystem 400, and device protection subsystem 491 may utilize the selected one of the provisioned payment credentials to identify its associated funding account as the account to receive the funds to be transferred). The device 200 may then select a receipt token RT-2a associated with the unique user credential identifier PID-2a (e.g., from entry 493c) to proceed with the funds transaction, or, alternatively, if the device 200 selects to provision payment credentials associated with the unique user credential identifier PID-2b, then in operation 544, the unique user credential identifier PID-2b may be sent back to the AE subsystem 400, and the device protection subsystem 491 may utilize the receipt token RT-2b associated with the selected unique user credential identifier PID-2b (e.g., from entry 493d) to proceed with the funds transaction. In some embodiments, such a prompt of operation 544 may also enable the user of the device 200 to select a new credential to be provisioned on the device 200 (e.g., similar to operation 520), and the device 200 may then select the unique user credential identifier of the new credential to transmit to the AE subsystem 400 for identifying the receipt token associated with the unique user credential identifier of the new credential. Alternatively, if operation 543 occurs before any credentials have been provisioned on device 200, such that in operation 543 the credential protection subsystem 491 (e.g., in table 493) does not recognize any receiving token associated with the recipient user identifier of the updated device transfer funds request data 538d, then operation 544 is similar to operation 520, such that one or more suitable user devices (e.g., device 200) associated with the recipient user identifier of the updated device transfer funds request data 538d can be prompted to provision credentials thereon, and, in some embodiments, the AE subsystem 400 can simultaneously notify the sender device 100 that the recipient social token of the device transfer funds request data 536d has not yet been associated with an account for receiving funds, and that system 1 is working on a solution.In other embodiments, rather than communicating with one or more recipient devices in operation 544 to determine which of a plurality of identified receiving tokens (e.g., identified from table 493) should be used to conduct a funds transaction, the AE subsystem 400 may be operable to apply one or more rules or settings to automatically select one of the identified receiving tokens for use (e.g., using predefined default and / or user-customized and / or AE-customized settings). For example, a user associated with the plurality of receiving tokens or the AE subsystem 400 may be operable to define one or more rules to automatically select one of the plurality of receiving tokens using any suitable factors, such as any identifier associated with a sender (e.g., a sender user or a sender issuing subsystem), a transfer amount, a current time of day, a day of the week, a month of the year, or any other transfer characteristic.

[0075] Once the credential protection subsystem 491 identifies a single specific receiving token that is associated with the recipient user identifier of the updated device transfer funds request data 538d (e.g., in operation 543, with or without operation 544), the credential protection subsystem 491 may communicate the specific receiving token along with at least a portion of the updated device transfer funds request data 538d as AE transfer funds request data 546d to the appropriate target issuing subsystem in operation 546. For example, continuing with the example below, in this example, the credential protection subsystem 491 may identify the receiving token RT-2a (e.g., the token of table entry 493c) as the specific receiving token to be used for further transfer, and then, in operation 546, the receiving token RT-2a may be transmitted to the specific issuing subsystem along with any appropriate data from the updated device transfer funds request data 538d as data 546d. The credential protection subsystem 491 may identify, in operation 546, a target issuing subsystem to receive such data 546d by analyzing any suitable information from the data 538d, which may indicate an issuing subsystem responsible for an account associated with the provisioned payment credential on the device 100, which account is identified by the data 536d as an account for obtaining the transferred funds (e.g., the first issuing subsystem 391, which may be associated with the sending token ST-1a of the payment credential data of the sender device of the data 536d). The AE transfer funds request data 546d may include the specific receiving token (e.g., RT-2a) identified in operations 543 / 544 and any suitable data 536d, such as funds amount data indicating a selected $50 value, and any suitable sender device payment credential data indicating the selected provisioned payment credential on the device 100, including the sending token ST-1a of the SSD 154a (e.g., CI encrypted sender device payment credential data (e.g., ST-1a token data and encrypted data)). In some embodiments, prior to transmitting the data 546d to the target issuing subsystem 391 in operation 546, the credential protection subsystem 491 may encrypt at least a portion of such AE transfer funds request data 546d (e.g., any sending device payment credential data and / or at least a portion of the received token and / or amount) in operation 545 using any suitable shared secret between the credential protection subsystem 491 and the target issuing subsystem 391 (e.g., any shared secret that may have been established in any appropriate prior operation (e.g., in operations 508 and / or 512 or otherwise)), after which the target issuing subsystem 391 may decrypt the encrypted portion of the received data 546d in step 546.Any such encryption of at least a portion of the AE device transfer funds request data 546d using the AE-CI shared secret prior to transmitting the data 546d to the CI subsystem 300, and any such decryption of such data using the appropriate AE-CI shared secret at the CI subsystem 300, may enable secure and trusted communication of at least that portion of the device transfer funds request data 546d between the AE subsystem 400 and the CI subsystem 300. For example, any receive token (e.g., RT-2a) communicated between the AE subsystem 400 and the CI subsystem 300 (e.g., as part of the data 546d at operation 546) may first be encrypted using any suitable AE-CI shared secret between the subsystems 300 and 400, and the CI subsystem 300 may be configured to decrypt such encrypted receive token using any suitable AE-CI shared secret, such that the CI subsystem 300 (e.g., IS 391 and / or IS 392) may be configured to use only receive tokens that are part of authenticated communications from the AE subsystem 400, and not other sources. The data 546d transmitted to the issuing subsystem 391 in operation 546 may include a received token (e.g., received token RT-2a, as identified using one or more links in table 493) identified by the credential protection subsystem 391 in operations 543 / 544. Alternatively, the recipient social token identified by the AE subsystem 400 in operation 538 and / or a unique user credential identifier PID associated with the recipient social token that may be identified by the AE subsystem 400 in operations 543 and / or 544 (e.g., instead of the receiving token (e.g., by identifying a PID in table 493 that may be associated with a user identifier that is associated with the recipient social token)) may be transmitted to the issuing subsystem 391 (e.g., as part of data 546d or in other forms), and the issuing subsystem 391 may use the recipient social token (e.g., LT-2) and / or the unique user credential identifier (e.g., PID-2a or PID-2b) to identify at least one receiving token associated with the recipient social token on the network table 395 in operation 547 (e.g., the receiving token RT-2a and issuing subsystem identifier BID-2 in entry 395c and / or the receiving token RT-2b and issuing subsystem identifier BID-1 in entry 395d). Thus, table 395 can be used by the sender issuing subsystem (e.g., the first IS 391) to identify the correct received token (e.g., received token RT-2a) rather than by the AE subsystem 400 to identify the correct received token (e.g., received token RT-2a), for example, so that the AE subsystem 400 may not store any received token data at the AE subsystem 400.

[0076] In operation 548, issuing subsystem 391 may process any suitable portion of transfer funds request data 546d to potentially verify the transfer of funds from an account of issuing subsystem 391 that may be identified by such data 546d. For example, as described above, data 546d may include CI-encrypted sender device payment credential data generated using ST-1a data from a payment credential provisioned on SSD 154a of device 100, which may be processed in any suitable manner by issuing subsystem 391 alone or in conjunction with any other suitable transfer data (e.g., any suitable funds amount data indicating a selected $50 value, any suitable sender device data indicating an ED1-ID and / or U1-ID, etc.), such as by decrypting (e.g., using credential key 155a' at issuing subsystem 391) and analyzing to determine whether an account associated with the sender device payment credential data (e.g., an account associated with a sending token ST-1a on subsystem 391) has sufficient credit or otherwise covers the amount to be transferred. For example, the issuing subsystem 391 may be operable in operation 548 to attempt to verify the sender device payment credential data of the transfer funds request data 546d in any suitable manner to determine whether to use the account identified by the payment credential data of the sender device of the transfer funds request data 546d to fund the transfer. As just one example, the issuing subsystem 391 may be operable in operation 548 to independently generate encrypted data based on token data of the sender device payment credential data of the transfer funds request data 546d (e.g., using a shared secret of the SSD 154a and the issuing subsystem 391), compare the generated encrypted data with the encrypted data of the sender device payment credential data of the transfer funds request data 546d, and confirm or deny the transfer of funds based on the comparison. If the sending account is not verified in operation 548, a transfer rejection notification can be transmitted from CI subsystem 300 to AE subsystem 400 using state data 556d in operation 556, and such state can be shared by AE subsystem 400 with one or more user devices (e.g., with device 100 as state data 558d in operation 558, and / or with device 200 as state data 560d in device 560) that are associated with the transfer.

[0077] If the sender account is verified in operation 548 and sufficient funds are identified in the verified sender account to satisfy the specific fund amount (e.g., $50) from request data 546d, the account-to-account transfer can be performed in operation 550 by transmitting transfer data 550d between the issuing subsystem 391 responsible for using the verified sender account to fund the transfer (the account identified by the account token AT-1a associated with the sending token ST-1 of data 546d as verified in operation 548) and the issuing subsystem (e.g., issuing subsystem 392) associated with the receiving token for the transfer (e.g., token RT-2a identified by subsystem 391 received in operation 546 or operation 547). The receiving token (e.g., receiving token RT-2a) can be configured to identify (e.g., to the issuing subsystem 391) a specific recipient target issuing subsystem that is responsible for the account associated with the receiving token and is used to receive the transferred funds (e.g., the receiving token can be a PAN or DAR that is operable to identify a specific recipient target issuing subsystem to which the sending issuing subsystem can perform an account-to-account transfer). The transfer data 550d can include any suitable funds data that is operable to transfer appropriate funds (e.g., $50) from the sender account in the issuing subsystem 391 (identified and associated with the verified sending token ST-1A of the request data 536d / 538d / 546d in operation 548) to the recipient target issuing subsystem 392 (which can be identified by the receiving token (e.g., receiving token RT-2a) that is transferred), and the transfer data 550d can also include at least a portion of the receiving token that is transferred itself (e.g., receiving token RT-2a). In operation 552, the recipient target issuing subsystem 392 is operable to receive and process the transfer data 550d so as to use the receiving token of the data 550d (e.g., the receiving token RT-2a) to identify the specific recipient account at the recipient target issuing subsystem 392 associated with the receiving token of the data 550d (e.g., the account associated with the account token AT-2a has been linked as the receiving token RT-2a in the entry 394a of the table 394), and then use the funding data of the data 550d to add the appropriate funds (e.g., $50) to the identified recipient account. Thus, the recipient target issuing subsystem 392 is operable to convert the receiving token of the data 550d into a specific recipient account token of the entry of the table 394 so as to identify the account to receive the transferred funds.If such an account-to-account transfer is successfully made in operations 550 and 552, a transfer acceptance notification may be communicated from subsystem 392 to subsystem 391 using state data 554d in operation 554, and such state may then be shared by CI subsystem 300 with AE subsystem 400 using state data 556d in operation 556, and such state may be shared by AE subsystem 400 with one or more user devices (e.g., with device 100 as state data 558d in operation 558, and / or with device 200 as state data 560d at device 560) that are associated with the transfer. The sender issuing subsystem (e.g., subsystem 391) may only need to know the receiving token (e.g., receiving token RT-2a) for the transfer, which the sender issuing subsystem may use to identify the appropriate target receiving issuing subsystem in operation 550, wherein the receiving token may be in any suitable format that is routable through any suitable existing network of any CI subsystem 300. The sender issuing subsystem may be operable to maintain a record of what funds it sends to what receiving token (e.g., for the purpose of maintaining any appropriate records for compliance purposes), but the receiving token may protect the security and / or privacy of the recipient funds account (e.g., the identity of the account token for the recipient account and / or the identity of any user associated with that account).

[0078] Therefore, when the CI subsystem 300 supplies payment credentials including a sending token ST associated with a specific funding account on a user electronic device that can be registered with the AE subsystem 400, the CI subsystem 300 can maintain a link between the sending token ST and the receiving token RT and the account token AT of the specific funding account, wherein the receiving token RT can be shared by the CI subsystem 300 and the AE subsystem 400 to facilitate the transfer of funds from a secure account to an account to the specific funding account. The AE subsystem 400 can link the receiving token RT to any suitable AE device registration identifier or AE device registration data (e.g., a user identifier U-ID and / or an electronic device identifier ED-ID and / or a social token LT), which identifier or AE device registration data can be associated with a user device on which payment credentials (e.g., a linked sending token) are provisioned, so that when the AE subsystem 400 receives a request to transfer funds to a recipient identified by any suitable AE device registration data (e.g., the recipient's social token LT), the AE subsystem 400 can operate to determine the specific receiving token RT associated with the identified recipient, and then share the specific receiving token RT with the CI subsystem 300, so that the CI subsystem 300 can use the receiving token RT to identify an appropriate funding account to the CI subsystem 300 to receive funds for the requested funds transfer. The CI subsystem 300 (e.g., IS 392) can only share such a receive token RT with the AE subsystem 400 (and / or network table), and the CI subsystem 300 (e.g., IS 392) can be configured to only accept receive tokens RT from the AE subsystem 400 or possibly from the network table 395 to facilitate the transfer of funds, so that individual user devices may not need to identify or otherwise obtain the receive token RT used to perform the transfer of funds to the recipient account. Such a virtual receive token may not separately include any data that can be used to access funds from an account associated with the receive token and / or that can be used to identify a specific fund account and / or a specific user. In some embodiments, the AE subsystem 400 can maintain two or more different subsystems, such as a device protection subsystem 471 and a credential protection subsystem 491, each of which can maintain links between different types of data to further limit the type of information that can be determined by analyzing the data on a particular one of those subsystems.For example, as described above, the device protection subsystem 471 may be operable to maintain links between two or more types of AE registration data, but not to maintain a link between any data and any received token RT (e.g., an entry in table 473 of the device protection subsystem 471 may maintain a link between a social token LT and one or more of a user identifier U-ID and / or an electronic device identifier ED-ID and / or any other suitable AE registration data at the AE subsystem 400, which may be associated with a user device registered in the AE subsystem 400, but such an entry in table 473 may not maintain any link between such data and any received token RT), while the credential protection subsystem 491 may Operate to maintain a link between the receiving token RT and certain types of AE registration data, but not maintain a link between the receiving token RT and any social token LT (e.g., an entry of table 493 of credential protection subsystem 491 may maintain a link between the receiving token RT and one or more of a user identifier U-ID and / or an electronic device identifier ED-ID and / or any other suitable AE registration data at AE subsystem 400, which may be associated with a user device registered in AE subsystem 400, but such an entry of table 493 may not maintain any link between such data and any social token LT, which may itself identify a particular user (e.g., an email address)). This may enable table 493 of credential protection subsystem 491 to link the receiving token RT with data of a social token that may not specifically identify a particular user, while enabling AE subsystem 400 to use generic data types (e.g., user identifier U-ID and / or electronic device identifier ED-ID) of table 493 of credential protection subsystem 491 and table 473 of device protection subsystem 471 to identify a particular receiving token RT for a particular social token LT during a funds transfer process. Alternatively, table 493 of credential protection subsystem 491 and / or table 473 of device protection subsystem 471 may be used to maintain a link between a receiving token RT and a social token LT. For example, table entry 493c of table 493 may include a link between RT-2a, U2-ID, ED2-ID, PID-2a, and LT-2, and / or table entry 473b of table 473 may include a link between ED2-ID, LT-2, U2-ID, U2-PW, and RT-2a. CI subsystem 300 is operable to use only a receiving token transmitted from AE subsystem 400 (or in some embodiments, from network table 395) to identify a funding account that will receive funds in a funds transfer. The receiving token need not be used by a user device of system 1 or otherwise.Instead, the sender device may only need to identify the recipient funding account by identifying the recipient social token, and the AE subsystem 400 may be operable to securely identify and use the receiving token associated with the recipient social token to facilitate the transfer of funds from the sender account to the recipient account.

[0079] Further steps may be taken to detect fraud risk associated with a particular account to transfer funds without maintaining sensitive data linking two particular users and / or user account data for a particular transfer. For example, when sending a transfer request, a sender device (e.g., device 100 in the example of a payment credential using a social token ST-1a with SSD 154a, for transferring $50 from an account of account token AT-1a to an account associated with social token LT-2) may be operable to generate and share certain information (e.g., a task authorization key) with the AE subsystem 400, wherein such shared information may be unique to the combination of the sender device and the social token LT that the sender device has identified for receiving the transferred funds, and wherein the AE subsystem 400 (e.g., transaction protection subsystem 481) may use such shared information to detect fraud risk associated with the transfer and / or store historical data associated with the transfer without being able to link a specific sender to a specific recipient of the AE subsystem 400. As described above, the transfer funds request data 536d transmitted from the sender device 100 to the AE subsystem 400 may include a task authorization key for the transfer request, wherein the task authorization key may be unique to a combination of the sender device 100 and the recipient social token (e.g., LT-2) identified in the transfer funds request data 536d. For example, the task authorization key that may be generated by the sender device 100 and included as part of the transfer funds request data 536d may be any suitable hash value of: (i) any suitable unique identifier of the device 100, and (ii) the requested recipient social token, wherein the unique identifier may be an electronic device identifier ED1-ID, a user identifier U1-ID, or any other suitable universally unique identifier ("UUID"), which may be a unique, one-time device-generated UUID (e.g., a device transfer unique identifier FX1-ID, which may be stored in entry 173a of the storage device 173 of the device 100). Such a device transfer unique identifier FX1-ID may be shared with and used by all devices associated with a particular user account, such that a first user's cellular phone and the same first user's desktop computer may both generate the same task authorization key when each device attempts to transfer funds to the same recipient social token. The task authorization key generated by the sender device 100 (e.g., using any suitable hash function) and transmitted from the sender device 100 in the transfer funds request data 536d for a particular recipient social token for a particular funds transfer may or may not be stored on the sender device 100.

[0080] A task authorization key for a particular transfer may be received in the credential protection subsystem 491 from the device protection subsystem 471 (e.g., as a first part of the transfer funds request data 538d, which may initially be provided to the device protection subsystem 471 from the device 100 in data 536d), as well as the sender's AE account user identifier (e.g., as a second part of the transfer funds request data 538d, which may initially be provided to the device protection subsystem 471 from the device 100 in data 536d, or determined by the device protection subsystem 471 in operation 538) and the recipient's AE account user identifier (e.g., as a third part of the transfer funds request data 538d, which may be determined and provided by the device protection subsystem 471 in operation 538 (e.g., based on the recipient's social token LT-2 in the data 536d from the device 100)). The credential protection subsystem 491 may process such a task authorization key, a sender user identifier, and a recipient user identifier of data 538d received by the credential protection subsystem 491 for a particular transfer in operation 539 to determine a task authorization identifier for the transfer. Such a task authorization identifier may be any suitable hash of (i) the task authorization key and (ii) the sender user identifier and (iii) the user identifier of the data 538d for that particular transfer. Generating a task authorization identifier based on the task key and the sender user identifier and / or the recipient user identifier may allow different task authorization identifiers to be generated for a first transfer between a first device registered to a first user and a recipient social token associated with a second user, and for a second transfer between a first device registered to a user different from the first user and a recipient social token associated with a user different from the second user (e.g., if a phone number once associated with the first registered user is later registered to a user different from the first user). Then, in operation 539, a task authorization identifier (“MANDATE-ID”) generated by the credential protection subsystem 491 (e.g., using any suitable hash function) may be transmitted from the credential protection subsystem 491 to the transaction protection subsystem 481 in operation 540 as part of the fraud request data 540d.In addition to the MANDATE-ID, the fraud request data 540d may also include any suitable transfer information, including, but not limited to: the amount of the funds transferred (e.g., $50, as may be indicated by data 538d); identification of the issuing subsystem associated with the sender account of the transfer (e.g., first issuing subsystem 391, which may be identified from data 538d); identification of the issuing subsystem associated with the recipient account of the transfer (e.g., second issuing subsystem 392, which may be identified in operations 543 / 544, which may be indicated by an appropriate receiving token for the transfer (e.g., RT-2a), which may occur prior to operation 540); the date / time of operation 540 and / or any other suitable operation for the transfer being processed; the location of the sender device 100 at the time of operation 536 (e.g., as may be included in data 536d); the type of sender device; a device identifier of the sender device, etc. The task authorization identifier that may be derived in operation 539 may or may not be stored in the credential protection subsystem 491 (e.g., in table 493). Alternatively, in some embodiments, the task authorization identifier of the current transfer can be derived at the transaction protection subsystem 481, where instead of including the task authorization identifier in the data 540d, the data 540d can include the following: the task authorization key and (ii) the sender user identifier and (iii) the recipient user identifier, and this information can be used by the transaction protection subsystem 491 (for example, using any suitable hash function) to derive the task authorization identifier ("MANDATE-ID").

[0081] In operation 541, any suitable data of the task authorization identifier and the fraud request data 540d received at the transaction protection subsystem 481 may be stored relative to each other at the transaction protection subsystem 481 (e.g., at Figure 4E483 of entry 483a). Moreover, in operation 541, transaction protection subsystem 481 is operable to run any appropriate analysis on the fraud request data of the current transfer in conjunction with any previously stored fraud request data of the currently processed transfer. For example, transaction protection subsystem 481 may attempt to identify how many other instances of the task authorization identifier of the current transfer may be stored at transaction protection subsystem 491 (e.g., in table 483 (not shown)), to determine how many other transfers have been processed by the same sender device and recipient social token combination as the current transfer, and / or compare the fraud risk data of the current transfer with the fraud risk data of one or more earlier transfers that may share the same task authorization identifier (i.e., MANDATE-ID). Transaction protection subsystem 481 may perform any appropriate processing in operation 541 to determine one or more fraud risk indicators or fraud scores for the current transfer based on at least the task identifier of the current transfer and any other appropriate data previously obtained by transaction protection subsystem 481 for one or more earlier transfers. The task authorization identifier (and / or task authorization key) can be used by the AE subsystem 400 to uniquely represent a sender / receiver combination of a transfer without requiring the AE subsystem 400 to store any data that identifies or can be used to identify the sender and receiver, for example, to protect the privacy of end users of the system 1. Thus, the AE subsystem 400 can maintain trust between the sender and receiver while also retaining certain transaction data to facilitate real-time fraud scoring and detection based on certain transaction history data for each transfer transaction stored for an identifier (e.g., a task authorization identifier and / or a task authorization key), which identifier itself may not identify the sender or receiver, but can uniquely represent a specific sender / receiver social token combination. Any suitable fraud detection results from operation 541 may be provided from transaction protection subsystem 481 to credential protection subsystem 491 as at least a portion of fraud risk result data 542d in operation 542, which may then be used by credential protection subsystem 491 to determine whether to continue processing the current transfer (e.g., whether the fraud detection results meet any suitable threshold for feasibility, or whether the fraud detection results indicate that the transfer should be deemed too risky and should be rejected). If such fraud risk result data 542d does not result in the rejection of the current transfer, at least a portion of such fraud risk result data 542d may be transmitted to the sender issuing subsystem as part of the AE transfer funds request data 546d of operation 546, which may then be used by the sender issuing subsystem in operation 548 (e.g., if the sender issuing subsystem may perform any other fraud detection).

[0082] In operations 550 and 552, regardless of whether the transfer from account to account was successful, accepted, rejected, or denied, in operation 556, the CI subsystem 300 may share transfer status data 556d indicating the status of the transfer with the AE subsystem 400, and the AE subsystem 400 may use the status data to send updated fraud risk data 540d for the particular transfer, which the transaction protection subsystem 481 may use to update its fraud data for the transfer (e.g., update the fraud data stored for the MANDATE-ID at entry 483a (e.g., indicating whether the transfer was ultimately approved or rejected, etc.), which may then be used in another iteration of operation 541 when analyzing fraud risk for later transfers that may be associated with the same MANDATE-ID). Additionally or alternatively, at least a portion of such transfer status data and / or at least a portion of any other data indicating any characteristics of the transfer may be stored at the transaction protection subsystem 481 for use in commemorating the transfer in one or more suitable manners. For example, the credential protection subsystem 491 may be operable to generate a unique transfer identifier (e.g., any suitable UUID) that may be unique for a transfer processed by the AE subsystem 400 (e.g., such transfer identifier may be uniquely generated by the AE subsystem 400 at the beginning or at any other time during the transfer process (e.g., at operations 538, 539, and / or at any other appropriate time during processing of a particular transfer)), and then such transfer identifier (“TRANSFER-ID”) may be used in operation 561 to generate two new, distinct transaction identifiers (i.e., a sending transaction identifier and a receiving transaction identifier). Each of the sending transaction identifier (“SENDX-ID”) and the receiving transaction identifier (“RECVX-ID”) may be generated for a particular transfer in any suitable manner. For example, the sending transaction identifier may be any suitable hash (e.g., using any suitable hash function) of: (i) the transfer identifier of the current transfer and (ii) the sending transaction salt (e.g., random data), and the receiving transaction identifier may be any suitable hash value (e.g., using any suitable hash function) of: (i) the transfer identifier of the current transfer and (ii) the receiving transaction salt (e.g., random data), wherein the sending transaction salt and the receiving transaction salt may be generated in the same or different manners, and the sending transaction salt and the receiving transaction salt may be different from each other to decouple the sender-side transaction information from the receiver-side transaction information for a particular transaction. Although the same sending transaction salt may be used for all transactions of all users and / or the same receiving transaction salt may be used for all transactions of all users, the sending transaction salt may be different from the receiving transaction salt so that the sender-side transaction information may be decoupled from the receiver-side transaction information for a particular transaction, which may enable separate transaction scoring for the sender and the receiver.Then, in operation 562, any suitable send transaction data (e.g., data 562d-s) currently being transferred may be transmitted to the transaction protection subsystem 481 as at least a portion of the transaction fraud data 562d associated with the SENDX-ID currently being transferred, and may then be stored relative to each other on the transaction protection subsystem 481 in operation 563 (e.g., in entry 483b of table 483), while in operation 562, any suitable receive transaction data (e.g., data 562d-r) currently being transferred may be transmitted to the transaction protection subsystem 481 as at least a portion of the transaction fraud data 562d associated with the RECVX-ID currently being transferred, and may then be stored relative to each other on the transaction protection subsystem 481 in operation 563 (e.g., in entry 483c of table 483). Such sent transaction data 562d-s can be any suitable data associated with the current transfer, including, but not limited to: any suitable sender identifier (e.g., U1-ID, ED1-ID, etc.); any suitable sender PII (e.g., the location of the sender device during the transaction, the country / region associated with the sender device, etc.); any suitable sender function; any suitable recipient function; any suitable set of recipients; the amount of the transfer (e.g., $50); the date / time stamp of the transfer (e.g., the timestamp of operation 562); any bank response data; any identifier of the sender's issuing subsystem; any suitable identifier of the sender's funding account; any identifier of the recipient's issuing subsystem, and suitable fraud risk result data 542d, etc. Such received transaction data 562d-r may be any suitable data associated with the current transfer, including, but not limited to: any suitable recipient identifier (e.g., social token LT-2); any suitable recipient PII (e.g., location of the recipient device during the transaction, country / region associated with the recipient device, identifier of the recipient device, etc.); any suitable recipient function; any suitable sender function; any suitable sender set; transfer amount (e.g., $50); transfer date / time stamp (e.g., timestamp of operation 562); any bank response data; any identifier of the sender issuing subsystem; any identifier of the recipient issuing subsystem; any suitable identifier of the recipient funding account, and suitable fraud risk outcome data 542d, etc. The transfer identifier for the current transaction may or may not be stored or maintained by the credential protection subsystem 491 and / or by any other portion of the AE subsystem 400. In operation 541 or otherwise, the transfer identifier for the transfer may also be stored against the task authorization identifier and / or fraud request data (e.g., in entry 483a).Alternatively, transaction protection subsystem 481 may not retain the transfer identifier so as to prevent any data linking the sender's identity to the recipient's identity from being available to transaction protection subsystem 481 in particular and / or to AE subsystem 400 more generally.

[0083] Thus, while the AE subsystem 400 (e.g., the transaction protection subsystem 481) is operable to store certain data about a particular transfer transaction, no stored data about the transaction is operable to link a particular sender to a particular recipient. For example, the mission authorization identifier MANDATE-ID or the fraud request data 540d of entry 483a of table 483 for a particular transfer may not include data operable to link the identity of the particular sender to the particular recipient of the transfer. For another example, the sending transaction identifier SENDX-ID or the sending transaction fraud data 562d-s of entry 483b of table 483 for a particular transfer may not include data operable to link the identity of the particular sender to the particular recipient of the transfer. For another example, the receiving transaction identifier RECVX-ID or the receiving transaction fraud data 562d-r of entry 483c of table 483 for a particular transfer may not include data operable to link the identity of the particular sender to the particular recipient of the transfer. However, such stored transfer transaction data may be retained for use in making any suitable fraud risk determinations for future transfer transactions (e.g., at subsequent iterations of operation 541), and / or for use in making any other suitable determinations, including, but not limited to: maintaining graphs to capture and close fraud circles without infringing the privacy of users; determining how much money was transferred across the network during any suitable time period; determining the number of unique sets of transaction parties that facilitated the transfer, etc., without allowing any data available to transaction protection subsystem 481 (e.g., any data in table 483) to be used to answer specific questions about a specific user (e.g., a specific user of AE subsystem 400 and / or a specific device and / or a specific account of CI subsystem 300). Thus, for a particular transaction, sender-side transaction information may be decoupled or uncoupled from receiver-side transaction information, which may enable separate transaction scoring for the sender and receiver.

[0084] Although a particular Fund Account of a particular Issuing Subsystem can only be associated with a single specific Account Token and a single specific Receiving Token, such a Fund Account can be associated with two or more unique Sending Tokens, such that a particular Fund Account can be used by two or more different User Devices, each of which may have pre-provisioned thereon a respective one of the unique Sending Tokens associated with that Fund Account. Figure 1 and / or Figure 5, but the system 1 may include a third user device that may be under the control of the user U1, similar to the first device 100 (e.g., the first device 100 may be a personal portable device of the user U1, and the third device may be a desktop device of the user U1), and the user U1 may provision one or more payment credentials on the third device, wherein the third device may be associated with the user U1 and any suitable registration data registered in the AE subsystem 400 (e.g., a third unique electronic device identifier ED3-ID that may be used similarly to the first unique electronic device identifier ED1-ID of the device 100 but having a different value). The third device may receive and store the same device transfer identifier FX1-ID as the first device 100 (e.g., the device transfer identifier FX-ID may be shared between multiple devices registered to the same user identifier U-ID on the AE subsystem 400), or the third device may generate and store its own unique device transfer identifier (e.g., the device transfer identifier FX3-ID). In some embodiments, the credentials provisioned on the third device may be associated with the same funding account that is associated with the payment credentials provisioned on the device 100 (e.g., the user U1 wishes to have credentials associated with a specific credit card account provisioned on each of the first device 100 and the third device). As a specific example, user U1 may also supply payment credentials associated with a funding account of account token AT-1a on a third device (e.g., as described in operations 504-518 with respect to supplying a sending token ST-1 on first device 100). Figure 5 , but process 500 may include iterations of operations similar to operations 504 through 516 that may provide such payment credentials on such third device and may include generating and / or storing various AT-1a, ST-3a, RT-1a, PID-3a, U1-ID, ED3-ID, LT-3, BID-1, etc. in one or more of a storage device entry of the third device, entry 493e of table 493, entry 393d of table 393, and entry 395e of table 395, where the sending token ST-3a may be used similarly to the first sending token ST-1a, but with a different value, and the unique user certificate identifier PID-3a may be used similarly to the first unique user certificate identifier PID-1a, but with a different value. Thus, as Figure 4C , Figure 4D , Figure 4F and Figure 4HAs shown, a first account token AT-1a for a particular funding account may be linked to only one unique receiving token RT-1a at the issuing subsystem 391 (e.g., at table 393), but such first account token AT-1a and / or such unique receiving token RT-1a may be linked to each of a unique sending token ST-1 (e.g., as may be provisioned on the first device 100) and a unique sending token ST-3 (e.g., as may be provisioned on the third device) at the issuing subsystem 391 (e.g., at table 393), while such unique receiving token ST-1a may be linked to each of a unique sending token ST-3 (e.g., as may be provisioned on the third device) at the issuing subsystem 391 (e.g., at table 393), and such unique receiving token ST-1a may be linked to each of a unique sending token ST-1 (e.g., as may be provisioned on the first device 100) and a unique sending token ST-3 (e.g., as may be provisioned on the third device). Token RT-1a may be linked to each of the unique social token ST-1 of device 100 and the social token ST-3 of the third device at network table 395, while such unique receiving token RT-1a may be linked to U1-ID and each of ED1-ID, ED3-ID, PID-1a, and PID-3a at credential protection subsystem 493 (e.g., at table 493), and while U1-ID may be linked to each of LT-1 and LT-3 at device protection subsystem 471 (e.g., at table 473). Thus, the third device may be used similarly to the first device 100 to initiate a transfer of funds from a funding account associated with account token AT-1a to another funding account, and / or the funding account associated with account token AT-1a may be used to receive funds from another funding account during a funds transfer identified as being received by a recipient associated with the social token LT-1 of device 100 and / or the social token LT-3 of the third device.

[0085] It should be understood that Figure 5The operations shown in the process 500 are merely illustrative, and existing operations may be modified or omitted, additional operations may be added, and the order of certain operations may be changed. In addition, in some specific implementations, two or more operations may occur in parallel or in an order different from the order described. It should be understood that for reasons of clarity and not limitation, the first user U1 and the second user U2 may be referenced. For example, in some embodiments, the user U1 and the user U2 may be the same user using both the first device 100 and the second device 200 (e.g., an account of the user is associated with the device 100, and transaction credential data is generated with the device 100 for funding another account of the user associated with the credential on the device 200). Additionally or alternatively, it should be understood that for reasons of clarity and not limitation, the first device 100 and the second device 200 may be referenced. For example, in some embodiments, the first device 100 and the second device 200 may be the same device (e.g., a first credential associated with a first account may be supplied on the device, and may be used to generate transaction credential data with the device 100 for funding another account associated with the second credential, which is also supplied on the same device). The unique receiving token RT associated by the CI subsystem 300 with a particular account token AT of a funding account may only be known to (e.g., available therein) the CI subsystem 300 and the AE subsystem 400, and not to any user device (such as device 100 and device 200). The receiving token need not be known to any user or used by any user device to perform a transaction. Instead, a social token may be used by a sender user, and such social token may be used by the AE subsystem 400 and / or the CI subsystem 300 to identify an appropriate receiving token, which the CI subsystem 300 may then use to identify an appropriate account token for funding the associated funding account. The CI subsystem 300 may be configured to perform a transaction (e.g., as encrypted or otherwise authenticated using a shared secret of the CI subsystem 300 and the AE subsystem 400) in response to receiving a receiving token only from the AE subsystem 400 or, in some embodiments, from the network table 395 of the CI subsystem 300, and not from other entities (such as user devices). Thus, the receiving token can only be used by the CI subsystem 300 to identify the appropriate funding account to receive funds, making the receiving token potentially useless to any other entity (e.g., an attacker or spoofer or other potential bad actor). A sending user may be enabled at a sending user device (e.g., device 100) to merely identify the recipient's social token without registering or even realizing that it may be using a specific funding facilitation service to send funds from an account associated with the sending user to an account associated with the recipient user.In contrast, as one example, a sender user may interact with a messaging communication application on a sender user device (e.g., an instant messaging software application, such as Messages by Apple Inc.) simply by selecting a particular recipient user to communicate with (e.g., by selecting an appropriate recipient social token, such as a phone number or email address) and by entering any appropriate communication message (e.g., text and / or emoticons, etc.) to be transmitted to the particular user recipient and any appropriate amount of funds (e.g., $50). The sender user's device may use a default send token (e.g., in response to some user authentication event) and communicate with an appropriate communication message from the sender user's device for the benefit of the particular recipient identified by the selected recipient social token. The sender user need not know any receiving token or any recipient banking information, as the messaging communication application and the AE subsystem 400 and CI subsystem 300 may handle the facilitation of the funds transfer and the communication of the communication message to the recipient user, which is transparent to the sender user.

[0086] Figures 1 to 5 Further description of

[0087] Relative to Figures 1 to 5 One, some, or all of the processes described may be implemented by software, but may also be implemented by hardware, firmware, or any combination of software, hardware, and firmware. Instructions for performing the processes may also be implemented as machine-readable code or computer-readable code recorded on a machine-readable medium or a computer-readable medium. In some embodiments, the computer-readable medium may be a non-transitory computer-readable medium. Examples of such non-transitory computer-readable media include, but are not limited to, read-only memory, random access memory, flash memory, CD-ROM, DVD, magnetic tape, removable memory card, and data storage devices (e.g., Figure 2104 and / or memory module 150). In other embodiments, the computer-readable medium may be a transient computer-readable medium. In such embodiments, the transient computer-readable medium may be distributed on a network-coupled computer system so that the computer-readable code is stored and executed in a distributed manner. For example, any appropriate communication protocol may be used to transmit such a transient computer-readable medium from one electronic device or subsystem to another electronic device or subsystem (e.g., a computer-readable medium may be transmitted to the electronic device 100 via the communication component 106 (e.g., as at least a part of the application 103 and / or as at least a part of the application 113 and / or as at least a part of the application 143)). Such a transient computer-readable medium may be implemented as a computer-readable code, instruction, data structure, program module, or other data in the form of a modulated data signal, such as a carrier wave or other transmission mechanism, and may include any information delivery medium. A modulated data signal may be a signal whose one or more characteristics are set or changed to encode information in the signal.

[0088] It should be understood that any, each, or at least one module or component or subsystem of system 1 may be provided as a software construct, a firmware construct, one or more hardware components, or a combination thereof. For example, any, each, or at least one module or component or subsystem of system 1 may be described in the general context of computer-executable instructions such as program modules that may be executed by one or more computers or other devices. Generally speaking, a program module may include one or more routines, programs, objects, components, and / or data structures that may perform one or more specific tasks or may implement one or more specific abstract data types. It should also be understood that the number, configuration, functionality, and interconnection of the modules and components and subsystems of system 1 are merely exemplary, and the number, configuration, functionality, and interconnection of existing modules, components, and / or subsystems may be modified or omitted, additional modules, components, and / or subsystems may be added, and the interconnection of specific modules, components, and / or subsystems may be changed.

[0089] At least a portion of one or more of the modules or components or subsystems of system 1 may be stored in an entity of system 1 or accessible to it in any other manner (e.g., in memory 104 of device 100 (e.g., as at least a portion of application 103 and / or as at least a portion of application 113 and / or as at least a portion of application 143)) in any suitable manner. For example, any or each module of NFC component 120 may be implemented using any suitable technology (e.g., as one or more integrated circuit devices), and different modules may be the same or different in structure, capabilities, and operation. Any or all modules or other components of system 1 may be installed on an expansion card, directly on a system motherboard, or integrated into a system chipset component (e.g., integrated into a "North Bridge" chip).

[0090] Any or each module or component of system 1 (e.g., any or each module of NFC component 120 and / or any or each module of NFC component of device 200) may be a dedicated system implemented using one or more expansion cards suitable for various bus standards. For example, all modules may be installed on different interconnect expansion cards or all modules may be installed on one expansion card. With respect to NFC component 120, by way of example only, the modules of NFC component 120 may interact with the motherboard or processor 102 of device 100 through an expansion slot (e.g., a peripheral component interconnect ("PCI") slot or a PCI express slot). Alternatively, NFC component 120 need not be removable, but may include one or more dedicated modules, which may include memory (e.g., RAM) dedicated to the use of the modules. In other embodiments, NFC component 120 may be integrated into device 100. For example, the modules of NFC component 120 may utilize a portion of device memory 104 of device 100. Any or each module or component of system 1 (e.g., any or each module of NFC component 120) may include its own processing circuitry and / or memory. Alternatively, any module or component or each module or component of system 1 (e.g., any module or each module of NFC component 120) may share processing circuitry and / or memory with any other module of NFC component 120 and / or processor 102 and / or memory 104 of device 100.

[0091] The present disclosure recognizes that the use of such personal information data, such as the current location of device 100 and / or device 200, in the present technology can be used to benefit the user. For example, the personal information data can be used to provide better security and risk assessment for ongoing financial transactions. Therefore, the use of such personal information data can calculate the security of financial transactions. In addition, the present disclosure also anticipates other uses of personal information data that benefit users.

[0092] The disclosure also contemplates that entities responsible for the collection, analysis, disclosure, transmission, storage or other purposes of such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities should implement and adhere to the use of privacy policies and practices that are recognized as meeting or exceeding the industry or government requirements for maintaining the privacy and security of personal information data. For example, personal information from users should be collected for the legal and reasonable purposes of the entity, and not shared or sold outside these legal purposes. In addition, such collection should only be carried out after the user's informed consent. In addition, such entities should take any required steps or perform certain operations to safeguard and protect access to such personal information data, and ensure that others who can access personal information data comply with their privacy policies and procedures. In addition, such entities can subject themselves to third-party assessments to prove that they comply with widely accepted privacy policies and practices.

[0093] Regardless of the foregoing, the present disclosure also contemplates implementation schemes in which users selectively block the use or access of personal information data. That is, the present disclosure contemplates providing hardware elements and / or software elements to prevent or block access to such personal information data. For example, with respect to financial transaction services, the technology of the present invention may be configured to allow users to choose to "opt in" or "opt out" of participating in the collection of personal information data during registration for such services. For another example, a user may choose not to provide location information to a financial transaction service. For another example, a user may choose not to provide precise location information, but permit the transmission of location area information.

[0094] Thus, while the present disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the present disclosure also contemplates that various embodiments may also be implemented without access to such personal information data. That is, the various embodiments of the present technology will not fail to function properly due to the lack of all or a portion of such personal information data. For example, financial transaction services may be provided by inferring preferences or circumstances based on non-personal information data or an absolute minimum measure of personal information (such as financial transactions conducted by a device associated with a user, other non-personal information available to the financial transaction service, or publicly available information).

[0095] Further applications of the concept

[0096] Although systems, methods, and computer-readable media for facilitating the transfer of funds between user accounts have been described, it should be understood that many changes may be made therein without departing from the spirit and scope of the subject matter described herein in any manner. Insubstantial variations of the claimed subject matter considered by one of ordinary skill in the art, whether now known or later devised, are expressly contemplated as being equivalently within the scope of the claims. Therefore, obvious substitutions now or later known to one of ordinary skill in the art are defined to be within the scope of the defined elements.

[0097] Accordingly, those skilled in the art will recognize that the present invention may be practiced otherwise than in the described embodiments, which are provided for purposes of illustration and not limitation.

Claims

1. A server device, comprising: Memory; and at least one processor, the at least one processor being configured to: in conjunction with a first credential issuing system, facilitating provision of a first transaction credential on a first electronic device, the first transaction credential corresponding to a first funding account at the first credential issuing system; as well as In conjunction with said providing, receiving, at said first credential issuing system, a first receipt token corresponding to said first funding account; storing the first received token in association with a first user identifier corresponding to a first user of the first electronic device and a first user communication identifier corresponding to the first user of the first electronic device; receiving, from a second electronic device corresponding to a second user identifier, a request to send a funding amount to the first user communications identifier using a second transaction credential provided on the second electronic device, wherein the request includes a task authorization key corresponding to a device identifier of the second electronic device and the first user communications identifier; retrieving the first user identifier and the first received token using the first user communication identifier; generating a task authorization identifier based at least in part on the task authorization key, the first user identifier, and the second user identifier; determining, based at least in part on the task authorization identifier, a fraud risk associated with the request to send the fund amount, the fraud risk being specific to the second electronic device, the first user communications identifier, the first user identifier, and the second user identifier; When the determined fraud risk meets a predetermined threshold: providing a request to transfer the fund amount to a second credential issuing system corresponding to the second transaction credential, the request including the first receiving token, the second transaction credential, and an indication of the fund amount; receiving an indication from the second credential issuing system whether the transfer is complete; as well as storing the indication of whether the transfer is complete in association with the task authorization identifier; as well as When the determined fraud risk fails to satisfy the predetermined threshold, the determined fraud risk is stored in association with the task authorization identifier.

2. The server device according to claim 1, wherein the at least one processor is further configured to: A request is received from the first electronic device to provide the first transaction credential on the first electronic device, the request including the first user identifier and the first user communication identifier.

3. The server device according to claim 1, wherein the at least one processor is further configured to: receiving, from the second electronic device, a request to provide the second transaction credential on the second electronic device, the request including the second user identifier corresponding to a second user of the second electronic device and a second user communication identifier corresponding to the second user of the second electronic device; in conjunction with the second credential issuing system, facilitating provision of the second transaction credential on the second electronic device, the second transaction credential corresponding to a second funding account at the second credential issuing system; receiving, from the second credential issuing system and in conjunction with the providing, a second receipt token corresponding to the second funding account at the second credential issuing system; as well as The second received token is stored in association with the second user identifier and the second user communications identifier. 4 . The server device according to claim 3 , wherein the first electronic device is registered at the server device to the first user identifier, and the second electronic device is registered at the server device to the second user identifier.

5. The server device of claim 1, wherein the first user communication identifier comprises at least one of an email address or a telephone number.

6. The server device of claim 1 , wherein the at least one processor is further configured to determine the fraud risk associated with the request to send the fund amount based at least in part on the task authorization identifier by: sending a fraud risk request to another server device, the fraud risk request including the task authorization identifier and transfer information; and An indication of the fraud risk associated with the request to send the amount of funds is received from the other server device.

7. The server device of claim 6, wherein the device identifier of the second electronic device, the first user communication identifier, the first user identifier, and the second user identifier are not provided to the other server device and can be accessed by the other server device.

8. A server device according to claim 6, wherein the transfer information includes at least one of the following: the amount of funds, an identifier of a second credential issuing system corresponding to the second transaction credential, an identifier of the first credential issuing system, a location of the second electronic device, or a type of the second electronic device.

9. The server device of claim 6, wherein the at least one processor is configured to store the determined fraud risk in association with the task authorization identifier by: The determined fraud risk and the task authorization identifier are sent to the another server device for storage.

10. The server device according to claim 6, wherein the server device, the another server device, the first electronic device, the second electronic device, the first credential issuing system, and the second credential issuing system are separate devices.

11. The server device of claim 1, wherein the at least one processor is configured to provide an identifier of the first credential issuing system to the second credential issuing system in conjunction with the transfer request.

12. A method for transferring an amount of money, the method comprising: In the management entity system: in conjunction with a first credential issuing system, facilitating provision of a first transaction credential on a first electronic device, the first transaction credential corresponding to a first funding account at the first credential issuing system; as well as In conjunction with said providing, receiving, at said first credential issuing system, a first receipt token corresponding to said first funding account; storing the first received token in association with a first user identifier corresponding to a first user of the first electronic device and a first user communication identifier corresponding to the first user of the first electronic device; receiving, from a second electronic device corresponding to a second user identifier, a request to send a funding amount to the first user communications identifier using a second transaction credential provided on the second electronic device; retrieving the first received token using the first user communication identifier; providing a request to transfer the fund amount to a second credential issuing system corresponding to the second transaction credential, the request including the first receiving token, the second transaction credential, an indication of the fund amount, and an identifier of the first credential issuing system; as well as An indication is received from the second credential issuing system as to whether the transfer is complete.

13. The method of claim 12, wherein the request to send the fund amount further includes a task authorization key corresponding to a device identifier of the second electronic device and the first user communication identifier, and the method further includes: generating a task authorization identifier based at least in part on the task authorization key, the first user identifier, and the second user identifier; as well as Based at least in part on the task authorization identifier, a fraud risk associated with the request to send the financial amount is determined, the fraud risk being specific to the second electronic device, the first user communications identifier, the first user identifier, and the second user identifier.

14. The method of claim 13, wherein providing the request to transfer the amount of funds to the second credential issuing system corresponding to the second transaction credential comprises: When the determined fraud risk meets a predetermined threshold: providing said request to transfer said amount of funds to said second credential issuing system corresponding to said second transaction credential; and The indication of whether the transfer is complete is stored in association with the task authorization identifier.

15. The method of claim 13, wherein the first electronic device is registered at the management entity system to the first user identifier, and the second electronic device is registered at the management entity system to the second user identifier.

16. The method of claim 13, wherein the first user communication identifier comprises at least one of an email address or a telephone number.

17. A system, comprising: a memory configured to store a first received token associated with a first user identifier corresponding to a first user of a first electronic device and a first user communications identifier corresponding to the first user of the first electronic device, wherein the first received token corresponds to a first funding account at a first credential issuing system; and at least one processor, the at least one processor being configured to: receiving, from a second electronic device corresponding to a second user identifier, a request to send a funding amount to the first user communications identifier using a second transaction credential provided on the second electronic device, wherein the request includes a task authorization key and encrypted secondary transaction credential data; retrieving the first received token using the first user communication identifier; determining, based at least in part on the task authorization key, a fraud risk associated with the request to send the amount of funds, the fraud risk being specific to the second electronic device, the first user communications identifier, the first user identifier, and the second user identifier; as well as When the determined fraud risk meets a predetermined threshold: providing a request to transfer the fund amount to a second credential issuing system corresponding to the second transaction credential, the request including the first receiving token associated with the first user communications identifier, the encrypted second transaction credential data, and an indication of the fund amount; receiving an indication from the second credential issuing system whether the transfer is complete; as well as The indication of whether the transfer is complete is stored in association with the task authorization key.

18. The system of claim 17, wherein the task authorization key corresponds to a device identifier of the second electronic device and the first user communication identifier.

19. The system of claim 18, wherein the at least one processor is further configured to: A task authorization identifier is generated based at least in part on the task authorization key, the first user identifier, and the second user identifier, wherein the indication of whether the transfer is complete is also stored in association with the task authorization identifier.

20. The system of claim 19, wherein the encrypted second transaction credential data is encrypted using a key accessible to the second credential issuing system and inaccessible to the system.

Images