CONDUCTING TRANSACTIONS USING ELECTRONIC DEVICES WITH GEOGRAPHICALLY RESTRICTED NON-NATIVE CREDENTIALS

Info

Publication number: 20170213206
Type: Application
Filed: Jan 25, 2017
Publication Date: Jul 27, 2017
Inventor: Nicholas J. Shearer (San Francisco, CA)
Application Number: 15/415,632

Abstract

Systems, methods, and computer-readable media for conducting a transaction using an electronic device with a geographically restricted non-native credential are provided. In one embodiment, a host electronic device in a system including an administration entity subsystem and a client electronic device communicatively coupled to the host electronic device via the administration entity subsystem may be provided to include a secure element, a host credential application provisioned on the secure element that generates host transaction credential data, a communications component communicatively coupled to the administration entity subsystem, and a processor that determines that the host credential application is subject to a geographical restriction and, based on the determination, communicates to the administration entity subsystem via the communications component the host transaction credential data and an instruction for the administration entity subsystem to generate a unique voucher redeemable by the client electronic device for the host transaction credential data.

Description

Description

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims the benefit of prior filed U.S. Provisional Patent Application No. 62/286,938, filed Jan. 25, 2016, U.S. Provisional Patent Application No. 62/348,958, filed Jun. 12, 2016, and U.S. Provisional Patent Application No. 62/384,059, filed Sep. 6, 2016 each of which is hereby incorporated by reference herein in its entirety.

TECHNICAL FIELD

This disclosure relates to conducting a transaction using an electronic device with a geographically restricted non-native credential, including to conducting a transaction using a client electronic device with a geographically restricted credential from a host electronic device.

BACKGROUND OF THE DISCLOSURE

Portable electronic devices (e.g., cellular telephones) may be provided with near field communication (“NFC”) components for enabling contactless proximity-based communications with another entity (e.g., a merchant). Often times, these communications are associated with commercial transactions or other secure data transactions that require the electronic device to generate, access, and/or share a native payment credential, such as a credit card credential, with the other entity in a contactless proximity-based communication. However, use of such a native payment credential by the electronic device in other types of communications (e.g., online commercial transactions) has often been inefficient.

SUMMARY OF THE DISCLOSURE

This document describes systems, methods, and computer-readable media for conducting a transaction using an electronic device with a geographically restricted non-native credential.

As an example, a method for conducting a transaction may be provided that includes, at an administration entity subsystem, receiving, from a host electronic device, host transaction data including host transaction credential data generated by a host credential application on a secure element of the host electronic device and transaction information including a service provider identifier indicative of a service provider subsystem, obtaining unique voucher data, storing the unique voucher data against administration host transaction credential data that includes the host transaction credential data of the received host transaction data, and communicating the unique voucher data to at least one of the host electronic device, a client electronic device, or the service provider subsystem.

As another example, a non-transitory computer-readable storage medium storing at least one program may be provided, where the at least one program includes instructions, which when executed by an administration entity subsystem, cause the administration entity subsystem to receive, from a host electronic device, host transaction data including host transaction credential data generated by a host credential application on a secure element of the host electronic device and transaction information including a service provider identifier indicative of a service provider subsystem, identify a service provider key that has been stored against the service provider identifier, create administration host transaction credential data by encrypting the host transaction credential data using the identified service provider key, obtain unique voucher data, store the unique voucher data in association with the created administration host transaction credential data, and communicate the unique voucher data to the host electronic device.

As another example, a host electronic device may be provided that includes a secure element, a host credential application provisioned on the secure element that generates host transaction credential data, a communications component communicatively coupled to an administration entity subsystem, and a processor configured to determine that the host credential application is subject to a geographical restriction and, based on the determination, communicate to the administration entity subsystem, via the communications component, the host transaction credential data and an instruction for the administration entity subsystem to generate a unique voucher that can be redeemed by a client electronic device to obtain the host transaction credential data.

This Summary is provided only to summarize some example embodiments, so as to provide a basic understanding of some aspects of the subject matter described in this document. Accordingly, it will be appreciated that the features described in this Summary are only examples and should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Unless otherwise stated, features described in the context of one example may be combined or used with 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 from the following Detailed Description, Figures, and Claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The discussion below makes reference to the following drawings, in which like reference characters refer to like parts throughout, and in which:

FIG. 1 is a schematic view of an illustrative system for conducting a transaction;

FIG. 1A is a more detailed schematic view of the system of FIG. 1;

FIG. 1B is another more detailed schematic view of the system of FIGS. 1 and 1A;

FIG. 2 is a more detailed schematic view of an electronic device of the system of FIGS. 1-1B;

FIG. 2A is another more detailed schematic view of the electronic device of FIGS. 1-2;

FIG. 3 is a front view of the electronic device of FIGS. 1-2A;

FIGS. 3A-3H are front views of screens of a graphical user interface of an electronic device of one or more of FIGS. 1-3 illustrating processes for conducting a transaction;

FIG. 4 is a more detailed schematic view of the AE subsystem of the system of FIGS. 1-1B; and

FIGS. 5 and 6 are flowcharts of illustrative processes for conducting a transaction.

DETAILED DESCRIPTION OF THE DISCLOSURE

A credential (e.g., a payment credential or any other suitable transaction credential) provisioned on a secure element of a credential-enabled host electronic device may be used for generating certain host credential data (e.g., token data and associated crypto data) that may then be used for securely funding or otherwise conducting a transaction (e.g., a financial transaction or any other suitable credential transaction) with a service provider subsystem, either directly or via a client electronic device that may be interfacing with the service provider subsystem. However, certain host credentials may be associated with certain restrictions that may prevent such host credential data from being handled by certain servers of certain entities (e.g., an administration entity subsystem that may be used to encrypt communications between the host device and the client device) that are geographically located in a location that is physically distinct from a geographic location of a source of the host credentials (e.g., servers of a credential issuer subsystem). For example, in certain markets (e.g., China), regulations may prevent certain banking information from being transmitted outside of the country. Therefore, rather than communicating such host credential data between the host device and the client device via a restricted server for that host credential data, such host credential data may be stored against a unique voucher that, on its own, may not be indicative of the host credential data and/or of the host credential and/or of the source of the host credential, and that voucher may then be communicated between the host device and the client device via the restricted server before being redeemed by the client device for the host credential data, which may then be shared by the client device with the service provider subsystem. Thus, the voucher may be used as an effective proxy for the host credential data to abide by certain host credential regulations while also maintaining the security and efficiency of the process.

Description of FIG. 1

FIG. 1 is a schematic view of an illustrative system 1 that may allow for the secure use of a geographically restricted credential provisioned on a host electronic device from a credential issuer subsystem in a transaction (e.g., an online transaction or a contactless proximity-based transaction) with a service provider (or merchant or processor), either directly or via or at the request of a client electronic device. For example, as shown in FIG. 1, system 1 may include an end-user host electronic device 100 (e.g., a smart phone) with at least one geographically restricted credential provisioned thereon (e.g., on a secure element of host electronic device 100), an end-user client electronic device 100′ (e.g., a laptop computer) that may or may not have at least one credential provisioned thereon, an administration (or commercial or trusted) entity subsystem 400, a service provider (or merchant or processing) subsystem 200, and a credential issuer subsystem 300. System 1 may also include an acquiring (or payment processor) subsystem 399 that may utilize credential data generated by a credential provisioned on host device 100 for completing the transaction with issuer subsystem 300 on behalf of SP subsystem 200. Communication of any suitable data between any two of host electronic device 100, client electronic device 100′, service provider (“SP”) subsystem 200, administration entity (“AE”) subsystem 400, acquiring subsystem 399, and credential issuer (or financial institution) subsystem 300 may be enabled via any suitable communications set-up 9, which may include any suitable wired communications path, any suitable wireless communications path, or any suitable combination of two or more wired and/or wireless communications paths using any suitable communications protocol(s) and/or any suitable network(s) and/or cloud architecture(s).

A transaction credential (e.g., a payment credential or any other suitable transaction credential) may be provisioned on host electronic device 100 (e.g., on a secure element or other storage component of host electronic device 100) from any suitable credential issuer subsystem 300 (e.g., an issuing bank subsystem or financial institution subsystem), either directly from the credential issuer subsystem or via AE subsystem 400, which may be operative to securely communicate credential data onto host device 100 and manage such credential data. For example, credential issuer subsystem 300 may include a first issuing subsystem 391 that may be operated by at least one first credential issuing institution (e.g., a first issuing bank, such as Wells Fargo of San Francisco, Calif.) with or without a first payment network institution (e.g., a first payment network, such as MasterCard) for provisioning a first transaction credential on host device 100 (e.g., directly or via AE subsystem 400). Credential issuer subsystem 300 may include a second issuing subsystem 392 that may be operated by at least one second credential issuing institution (e.g., a second issuing bank, such as the People's Bank of China of Beijing, China) with or without a second payment network institution (e.g., a second payment network, such as China UnionPay of Shanghai, China) for provisioning a second transaction credential on host device 100 (e.g., directly or via AE subsystem 400). Once provisioned on host device 100, a transaction credential may then be used by host device 100 for securely funding or otherwise conducting a transaction (e.g., a commercial or financial transaction or any other suitable credential transaction) with SP subsystem 200 (e.g., any suitable subsystem that may be operative to provide access to any suitable good or service as part of a transaction), either directly with SP subsystem 200 or via client device 100′ that may be interfacing with SP subsystem 200 or on behalf of client device 100′ that may have initiated the transaction with SP subsystem 200.

For example, while interfacing with service provider (“SP”) subsystem 200 (e.g., via an online resource (e.g., an online app or web browser) or via a contactless proximity-based communication medium) for accessing (e.g., purchasing) a service provider product or service, client device 100′ may identify host device 100 as a desired source of a transaction credential to be used for funding or otherwise furthering a transaction to access the service provider product. Client device 100′ may be either a type of device that may not be configured to store or otherwise have provisioned thereon a transaction credential for use in funding the transaction (e.g., client device 100′ may not include a secure element operative to securely utilize a payment credential) or a type of device that is configured to store a transaction credential but that does not currently have a particular credential stored thereon that is desired to be used in a particular transaction initiated by client device 100′. For example, at any suitable point during any suitable communication between client device 100′ and SP subsystem 200 for defining a transaction to access a product of SP subsystem 200, client device 100′ may identify or have identified on its behalf, such as by a communication service (e.g., an identity service (“IDS”)) of AE subsystem 400, the availability of at least one transaction credential stored on host device 100 that may be available to client device 100′ for use in funding or otherwise furthering the transaction. In some embodiments, as shown in FIG. 1, AE subsystem 400 may provide an IDS subsystem 471 that may be configured to enable and/or manage any suitable device detection and/or communication between host device 100 and client device 100′, such as an identity services (“IDS”) transport (e.g., using an administration-entity specific (or other entity specific) service (e.g., iMessage™ by Apple Inc.)). For example, certain devices may be automatically or manually registered for such a service (e.g., all devices in an eco-system of an administration entity of AE subsystem 400 (e.g., host device 100 and client device 100′) may be automatically registered for the service). Such a service may be operative to provide an end-to-end encrypted mechanism that may require active registration before device detection may be achieved and/or messages can be sent using the service (e.g., using an IDS application on each participating device). IDS subsystem 471, which may include any suitable processing, data accessing, and data communicating components of AE subsystem 400, may be operative to identify or otherwise lookup the status of any credentials provisioned on any electronic devices associated with a given user account or otherwise, for example, such that AE subsystem 400 may be operative to efficiently and effectively identify one or more non-native transaction credentials that may be available to a particular client device from one or more particular host devices associated with a particular user account (e.g., multiple host devices and the client device may be in a family account with AE subsystem 400). Then, client device 100′ may share any suitable data with an identified and selected host device 100 for requesting that such a transaction credential on host device 100 be shared with SP subsystem 200 for funding the transaction on behalf of client device 100′. Such a request and any other communications between client device 100′ and host device 100 may be facilitated by and through IDS subsystem 471 of AE subsystem 400 for enabling a secure and/or efficient communication path between devices.

In response to receiving such a transaction credential request from client device 100′, host device 100 may generate, using a particular transaction credential on host device 100, any suitable host transaction credential data that may be operative to fiend or otherwise further the transaction. While host device 100 may generate host transaction credential data as encrypted or otherwise modified with any suitable shared secret (e.g., a password, passphrase, array of randomly chosen bytes, one or more symmetric keys, public-private keys (e.g., asymmetric keys), etc.) between/available to host device 100 and the credential issuing subsystem that provisioned the particular transaction credential on host device 100 (e.g., a shared secret between host device 100 and first issuing subsystem 391 when the host transaction credential data is generated by host device 100 using a first transaction credential provisioned on host device 100 by first issuing subsystem 391 or a shared secret between host device 100 and second issuing subsystem 392 when the host transaction credential data is generated by host device 100 using a second transaction credential provisioned on host device 100 by second issuing subsystem 392), host device 100 may utilize AE subsystem 400 to further secure such host transaction credential data before the host transaction credential data is shared with client device 100′ or SP subsystem 200. For example, AE subsystem 400 (e.g., at least one of a first security subsystem 491 and a second security subsystem 492 of AE subsystem 400, each of which may include any suitable processing, data accessing, and data communicating components of AE subsystem 400) may be operative to maintain any suitable shared secret (e.g., a password, passphrase, array of randomly chosen bytes, one or more symmetric keys, public-private keys (e.g., asymmetric keys), etc.) between/available to AE subsystem 400 and SP subsystem 200, and AE subsystem 400 (e.g., at least one of first security subsystem 491 and second security subsystem 492) may be operative to use such a shared secret to encrypt or otherwise modify host transaction credential data generated by host device 100 as SP-secured host transaction credential data (e.g., host transaction credential data from host device 100 that has been secured using a shared secret of SP subsystem 200). Then, AE subsystem 400 may be operative to communicate such SP-secured host transaction credential data back to host device 100. Then, host device 100 may be operative to communicate such SP-secured host transaction credential data to client device 100′, where such communication of shared host transaction credential data from host device 100 to client device 100′ may be facilitated by and through IDS subsystem 471 of AE subsystem 400 for enabling a secure and/or efficient communication path for the data between the devices. Then, client device 100′ may be operative to communicate such SP-secured host transaction credential data to SP subsystem 200 for funding or otherwise furthering the transaction. Alternatively, host device 100 may be operative to communicate such SP-secured host transaction credential data directly to SP subsystem 200, such as when host device 100 initiated the transaction with SP subsystem 200 (e.g., when client device 100′ is not involved in the transaction) or to obviate the need to communicate such SP-secured host transaction credential data via the client device 100′ to SP subsystem 200.

However, in some embodiments, certain transaction credentials provisioned on host device 100 by certain credential issuing subsystems of credential issuer subsystem may be regulated and/or governed by certain geographic and/or political restrictions, which may aim to prevent any host transaction credential data generated on host device 100 by such a “geographically restricted” transaction credential from being handled by any server or component of system 1 (e.g., AE subsystem 400 and/or client device 100′ and/or SP subsystem 200 and/or acquiring bank 399) that is physically located in a different geographical region than the geographical region in which the credential issuing subsystem of the geographically restricted transaction credential is located. For example, as shown in FIG. 1, first issuing subsystem 391 may be physically located in a first geographical region 91 (e.g., first credential issuing institution Wells Fargo and/or first payment network institution MasterCard of first issuing subsystem 391 for provisioning a first transaction credential on host device 100 may be physically located in the United States of America as first geographical region 91), while second issuing subsystem 392 may be physically located in a second geographical region 92 that is at least partially different than first geographical region 91 (e.g., second credential issuing institution People's Bank of China and/or second payment network institution China UnionPay of second issuing subsystem 392 for provisioning a second transaction credential on host device 100 may be physically located in the People's Republic of China as second geographical region 92). Moreover, as shown in FIG. 1, IDS subsystem 471 and first security subsystem 491 of AE subsystem 400 may be physically located in first geographical region 91 while second security subsystem 492 of AE subsystem 400 may be physically located in second geographical region 92 (it is to be understood that each one of host device 100, client device 100′, SP subsystem 200, and acquiring subsystem 399 may be located in one of first geographical region 91 or second geographical region 92 depending on a particular embodiment). Therefore, in such an exemplary system 1, if second issuing subsystem 392 of second geographical region 92 provisions such a geographically restricted transaction credential on host device 100, then system 1 may be configured to avoid any host transaction credential data generated on host device 100 by that geographically restricted transaction credential from being handled by any (or at least a certain one) server or component of system 1 that is physically located in a different geographical region than second geographical region 92 of second issuing subsystem 392 (i.e., system 1 may be configured not to communicate or process or otherwise handle any host transaction credential data generated on host device 100 by such a geographically restricted transaction credential using IDS subsystem 471 and/or first security subsystem 491 of AE subsystem 400 that is physically located outside of second geographical region 92 (e.g., physically located inside of first geographical region 91)). In such embodiments, although, as shown, AE subsystem 400 may be configured to provide in second geographical region 92 a second security subsystem 492 that may be operative to maintain and use any suitable shared secret between AE subsystem 400 and SP subsystem 200 to encrypt or otherwise modify any host transaction credential data as generated on host device 100 by such a geographically restricted transaction credential in order to generate SP-secured host transaction credential data in accordance with the geographical restriction of the geographically restricted transaction credential, AE subsystem 400 may not be configured to provide any IDS subsystem in second geographical region 92 but instead may only provide IDS subsystem 471 in first geographical region 91 (e.g., an IDS subsystem of an administration entity may only be located in the United States and not in China, but can provide coverage for both regions). Therefore, the SP-secured host transaction credential data generated by second security subsystem 492 for the geographically restricted transaction credential (e.g., the “geographically restricted” SP-secured host transaction credential data) may not be communicated through IDS subsystem 471 as might otherwise be done when SP-secured host transaction credential data is to be communicated from host device 100 to client device 100′. In such embodiments, second security subsystem 492 may be configured to generate or otherwise access a unique host transaction voucher in conjunction with generating the geographically restricted SP-secured host transaction credential data and may then be configured to store such a unique host transaction voucher against the SP-secured host transaction credential data (e.g., in any suitable memory component of second security subsystem 492), after which the unique host transaction voucher may be returned to host device 100 instead of the SP-secured host transaction credential data. Then, host device 100 may be operative to communicate that unique host transaction voucher rather than any SP-secured host transaction credential data to client device 100′, where such communication of the unique host transaction voucher from host device 100 to client device 100′ may be facilitated by and through IDS subsystem 471 of AE subsystem 400 for enabling a secure and/or efficient communication path for the voucher between the devices. Such a unique host transaction voucher may be any suitable data element of any suitable size, such as an 8- or 9-character alphanumeric string that may be randomly or uniquely generated by AE subsystem 400 or otherwise for association with the geographically restricted SP-secured host transaction credential data, such that the voucher may not include any data indicative of the geographically restricted transaction credential and/or of the geographically restricted SP-secured host transaction credential data. Therefore, such a unique host transaction voucher may be handled by IDS subsystem 471 without violating the geographical restriction of the geographically restricted transaction credential, even though IDS subsystem 471 is not physically located in second geographic region 92, as the voucher may not include any host transaction credential data generated on host device 100 by the geographically restricted transaction credential and/or any geographically restricted SP-secured host transaction credential data generated by second security subsystem 492 using the geographically restricted transaction credential. However, once the unique host transaction voucher is received by client device 100′, client device 100′ may redeem the voucher for the geographically restricted SP-secured host transaction credential data by communicating the voucher to second geographic region 92. Then, second geographic region 92 may identify the appropriate geographically restricted SP-secured host transaction credential data using the voucher received from client device 100′ (e.g., second geographic region 92 may identify the particular geographically restricted SP-secured host transaction credential data stored against the particular unique host transaction voucher) and may then communicate that identified geographically restricted SP-secured host transaction credential data back to client device 100′, which may then be communicated on from client device 100′ to SP subsystem 200 for funding or otherwise furthering the transaction (e.g., without SP subsystem 200 having to communicate with or even be aware of host device 100 (e.g., as if the SP-secured host transaction credential data had been generated locally on client device 100′)). Alternatively, in other embodiments, AE subsystem 400 may be operative to communicate the voucher on to servicer provider subsystem 200, or host device 100 may be operative to communicate the voucher received from AE subsystem 400 on to servicer provider subsystem 200, or client device 100′ may be operative to communicate the voucher received from host device 100 on to SP subsystem 200, and then SP subsystem 200 may be operative to redeem the voucher at second security subsystem 492 for the SP-secured host transaction credential data. For example, in some embodiments, client device 100′ may also be located in first geographical region 91 and, like IDS subsystem 471, ought not handle the geographically restricted SP-secured host transaction credential data for honoring the applicable geographic restriction(s), such that the voucher ought to be forwarded on from client device 100′ to SP subsystem 200, which may redeem the voucher if SP subsystem 200 is located in second geographical region 92. Otherwise, if SP subsystem 200 is not located in second geographical region 92, then the voucher may be communicated to SP subsystem 200, and SP subsystem 200 may forward the voucher to an appropriate acquiring subsystem 399 that is in second geographical region 92, such that that acquiring subsystem 399 may appropriately redeem the voucher for the geographically restricted SP-secured host transaction credential data for honoring the applicable geographic restriction(s). Therefore, a unique host transaction voucher may be generated and used by system 1 as an effective proxy for any geographically restricted SP-secured host transaction credential data during any suitable portion of a transaction process for honoring the applicable geographic restriction(s), while AE subsystem 400 may be utilized as a conduit for effective communication between host and client devices and/or while AE subsystem 400 may be utilized for enabling a secure communication path of transaction credential data by using any suitable shared secret(s) or other security features of AE subsystem 400 and SP subsystem 200 to generate the geographically restricted SP-secured host transaction credential data.

Description of FIG. 1A

Referring now to FIG. 1A, FIG. 1A shows an expanded view of system 1 described above with respect to FIG. 1 that may allow for the secure use of a credential (e.g., a geographically restricted credential) on host electronic device 100 in a transaction (e.g., an online transaction or a contactless proximity-based transaction) with SP subsystem 200 (e.g., via client electronic device 100′). AE subsystem 400 and credential issuer subsystem 300 may be used for securely provisioning one or more credentials on host device 100, whereby such a provisioned credential may be used by host device 100 for conducting a transaction (e.g., a financial or payment or other suitable data transaction) with SP subsystem 200 via client device 100′. For example, in response to host device 100 receiving a client transaction (or payment) request from client device 100′ (e.g., via an IDS service facilitated by AE subsystem 400) for a particular transaction with SP subsystem 200, host device 100 may share host transaction credential data or host payment credential data of a credential provisioned on host device 100 with AE subsystem 400 in order for the host transaction credential data to be secured as SP-secured host transaction credential data by AE subsystem 400 using a shared secret with SP subsystem 200. That SP-secured host transaction credential data may then be shared with client device 100′ via host device 100 using a unique host transaction voucher communicated from AE subsystem 400 to host device 100 that may then be communicated from host device 100 to client device 100′ (e.g., as secured host transaction data 684) as a proxy for the SP-secured host transaction credential data, while that voucher may then be redeemed by client device 100′ at AE subsystem 400 for the SP-secured host transaction credential data (e.g., to abide by any applicable geographic restriction(s) of the credential that may forbid communication of the SP-secured host transaction credential data between host device 100 and client device 100′ using an IDS service of AE subsystem 400). Then, client device 100′ may share that SP-secured host transaction credential data with SP subsystem 200 as a contactless proximity-based communication 5 (e.g., a near field communication or a Bluetooth™ communication) and/or an online-based communication (e.g., a network telecommunication or otherwise) (e.g., as client transaction data 690) for funding or otherwise furthering the particular transaction with SP subsystem 200. System 1 may also include acquiring bank subsystem 399 that may utilize such SP-secured host transaction credential data received by SP subsystem 200 for completing the transaction with issuer subsystem 300 on behalf of SP subsystem 200.

System 1 may include a communications path 15 for enabling communication between client device 100′ and SP subsystem 200, a communications path 25 for enabling communication between SP subsystem 200 and acquiring bank subsystem 399, a communications path 35 for enabling communication between acquiring bank subsystem 399 and credential issuer subsystem 300, a communications path 41 for enabling communication between a first payment network subsystem 361 of credential issuer subsystem 300 and first issuing subsystem 391 of credential issuer subsystem 300 (e.g., of first geographical region 91 of FIG. 1), a communications path 42 for enabling communication between a second payment network subsystem 362 of credential issuer subsystem 300 and second issuing subsystem 392 of credential issuer subsystem 300 (e.g., of second geographical region 92 of FIG. 1), a communications path 55 for enabling communication between credential issuer subsystem 300 and AE subsystem 400, a communications path 65 for enabling communication between AE subsystem 400 and host electronic device 100, a communications path 75 for enabling communication between credential issuer subsystem 300 and host electronic device 100, a communications path 85 for enabling communication between AE subsystem 400 and SP subsystem 200, a communications path 95 for enabling communication between AE subsystem 400 and client device 100′, and a communications path 99 for enabling communication between host device 100 and client device 100′. One or more of paths 15, 25, 35, 41, 42, 55, 65, 75, 85, 95, and 99 may be at least partially managed by one or more trusted service managers (“TSMs”). Any suitable circuitry, device, system, or combination of these (e.g., a wireless communications infrastructure that may include one or more communications towers, telecommunications servers, or the like) that may be operative to create a communications network may be used to provide one or more of paths 15, 25, 35, 41, 42, 55, 65, 75, 85, 95, and 99, which may be capable of providing communications using any suitable wired or wireless communications protocol. For example, one or more of paths 15, 25, 35, 41, 42, 55, 65, 75, 85, 95, and 99 may support Wi-Fi (e.g., an 802.11 protocol), ZigBee (e.g., an 802.15.4 protocol), WiDi™, Ethernet, Bluetooth™, BLE, high frequency systems (e.g., 900 MHz, 2.4 GHz, and 5.6 GHz communication systems), infrared, TCP/IP, SCTP, DHCP, HTTP, BitTorrent™, FTP, RTP, RTSP, RTCP, RAOP, RDTP, UDP, SSH, WDS-bridging, any communications protocol that may be used by wireless and cellular telephones and personal e-mail devices (e.g., GSM, GSM plus EDGE, CDMA, OFDMA, HSPA, multi-band, etc.), any communications protocol that may be used by a low power Wireless Personal Area Network (“6LoWPAN”) module, any other communications protocol, or any combination thereof. One or more of paths 15, 25, 35, 41, 42, 55, 65, 75, 85, 95, and 99 may be enabled by any suitable communications set-up (e.g., communications set-up 9 of FIG. 1).

Description of FIG. 1B

Referring now to FIG. 1B, FIG. 1B shows a more detailed view of the system 1 described above with respect to FIG. IA. As shown in FIG. 1B, for example, host electronic device 100 may include a processor 102, a communications component 106, and/or a near field communication (“NFC”) component 120. NFC component 120 may include or otherwise provide a secure element 145 that may be capable of securely hosting applications and their confidential and cryptographic data in accordance with rules and security requirements that may be set forth by a set of well-identified trusted authorities. As described below in more detail, a credential applet or a payment application on secure element 145 (e.g., of NFC component 120) of host device 100 may be configured to provide host payment credential data or host transaction credential data with sufficient detail for identifying any suitable funding account or other financial instrument or credit source or the like (e.g., an account at credential issuer subsystem 300 (e.g., at the same issuing subsystem of credential issuer subsystem 300 that may have provisioned the credential applet on host device 100)), where such host transaction credential data may eventually be received by SP subsystem 200 and/or issuer subsystem 300 for funding a financial transaction or otherwise furthering any suitable transaction. NFC component 120 or a similar NFC component 120′ may be configured to communicate such host transaction credential data or an associated voucher or any other suitable data as a contactless proximity-based communication (e.g., near field communication) with each other or with SP subsystem 200 (e.g., with an SP terminal 220 of SP subsystem 200 that may be located at a brick and mortar store or any physical location at which a user of host device 100 or client device 100′ may use a credential to conduct a transaction with a proximately located SP terminal 220 via a contactless proximity-based communication). NFC component 120 may allow for close range communication at relatively low data rates (e.g., 424 kbps), and may comply with any suitable standards, 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 close range communication at relatively high data rates (e.g., 370 Mbps), and may comply with any suitable standards, such as the TransferJet™ protocol. Communication between NFC component 120 or NFC component 120′ and SP subsystem 200 may occur within any suitable close range distance between the NFC component and merchant subsystem 200 (see, e.g., distance D of FIGS. 1A and 1B between NFC component 120′ and terminal 220), 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 an NFC component may take place via magnetic field induction, which may allow the NFC component to communicate with other NFC devices and/or to retrieve information from tags having radio frequency identification (“RFID”) circuitry. While NFC component 120 (and/or component 120′) may be described with respect to near field communication, it is to be understood that component 120 may be configured to provide any suitable contactless proximity-based mobile payment or any other suitable type of contactless proximity-based communication between device 100 and another entity, such as client device 100′ or terminal 220. For example, NFC component 120 may be configured to provide any suitable short-range communication, such as those involving electromagnetic/electrostatic coupling technologies. Communications component 106 may be provided to allow host device 100 to communicate any suitable host transaction credential data or an associated voucher with one or more other electronic devices or servers or subsystems (e.g., one or more subsystems or other components of system 1) using any suitable wired or wireless protocol. Processor 102 of host device 100 may include any suitable processing circuitry that may be operative to control the operations and performance of one or more components of host device 100. For example, processor 102 may be configured to run one or more applications on device 100 (e.g., an application 103 and/or an online resource or SP application 113) that may at least partially dictate the way in which data (e.g., host transaction credential data or an associated voucher) may be communicated by host device 100 for furthering a transaction with SP subsystem 200, such as via client device 100′ (e.g., the way in which data may be communicated between host device 100 and client device 100′ and/or the way in which data may be communicated between host device 100 and AE subsystem 400, which may eventually be communicated from AE subsystem 400 to client device 100′). Moreover, as shown in FIG. 1B, host device 100 may include any suitable host device identification information 119, which may be accessible to processor 102 or any other suitable portion of device 100. Host device identification information 119 may be utilized by a user of client device 100′ and/or AE subsystem 400 and/or SP subsystem 200 and/or issuer subsystem 300 for uniquely identifying host device 100 to facilitate a transaction with SP subsystem 200 and/or to enable any suitable secure communication with host device 100. As just one example, host device identification information 119 may be a telephone number or e-mail address or any unique identifier that may be associated with device 100.

Client device 100′ may include one, some, or all of the same components as host device 100 or any components that are not provided by host device 100. For example, as shown in FIG. 1B, client device 100′ may include any suitable communications component 106′ that may communicate any suitable communications with host device 100 (e.g., via communications path 99) and/or with AE subsystem 400 (e.g., via communications path 95) and/or with SP subsystem 200 (e.g., via communications path 15). Client device 100′ may include any suitable contactless proximity-based or NFC component 120′ that may be operative to communicate contactless proximity-based communications 5 with terminal 220 of SP subsystem 200. Client device 100′ may include any suitable processor 102′ that may be operative to run one or more suitable applications on device 100′ (e.g., online resource or SP application 113′) that may at least partially dictate the way in which host transaction credential data or an associated voucher from host device 100 or otherwise may be redeemed and/or communicated by client device 100′ for furthering a transaction with SP subsystem 200. Moreover, client device 100′ may include any suitable client device identification information 119′, which may be accessible to processor 102′ or any other suitable portion of device 100′, and which may be utilized by a user of host device 100 and/or AE subsystem 400 and/or SP subsystem 200 and/or issuer subsystem 300 for uniquely identifying client device 100′ to facilitate a transaction with SP subsystem 200 and/or to enable any suitable secure communication with client device 100′. As just one example, client device identification information 119′ may be a telephone number or e-mail address or any unique identifier that may be associated with device 100′. Although not shown, client device 100′ may also include an I/O interface that may be the same as or similar to an I/O interface 114 of electronic device 100 of FIG. 2, a bus that may be the same as or similar to a bus 118 of electronic device 100 (see, e.g., FIG. 2), a memory component that may be the same as or similar to a memory component 104 of electronic device 100, and/or a power supply component that may be the same as or similar to a power supply component 108 of electronic device 100.

SP subsystem 200 may include any suitable service provider (“SP”) server 210, as shown in FIG. 1B, which may include any suitable component or subsystem configured to communicate any suitable data via any suitable communications protocol (e.g., Wi-Fi, Bluetooth™, cellular, wired network protocols, etc.) with a communications component of AE subsystem 400 and/or with communications component 106′ of acquiring bank 399 and/or with a communications component of client device 100′. For example, SP server 210 may be operative to communicate potential transaction data 660 with communications component 106′ of client device 100′ within any suitable online-context, such as when a user of client device 100′ is communicating with SP server 210 to conduct a transaction via any suitable SP online resource 113′ that may be running on client device 100′, such as a third party SP application 113′ running on client device 100′ that may be managed by SP server 210 or an internet application 113′ (e.g., Safari™ by Apple Inc.) running on client device 100′ that may be pointed to a uniform resource locator (“URL”) whose target or web resource may be managed by SP server 210. Accordingly, it is noted that communications between SP server 210 and client device 100′ may occur wirelessly and/or via wired paths (e.g., over the internet). SP server 210 may be provided by a merchant or any other controlling entity of SP subsystem 200 (e.g., as a webserver to host website data and/or manage third party application data). As shown in FIG. 1B, SP subsystem 200 may include any suitable SP terminal 220 (e.g., a merchant payment terminal), which may include any suitable component or subsystem configured to communicate any suitable data with a contactless proximity-based communication component of host device 100 and/or of client device 100′ (e.g., a contactless proximity-based communication 5 with NFC component 120′ of client device 100′). SP subsystem 200 may include an SP key 157 and/or an SP key 157′. Moreover, SP subsystem 200 may include any suitable service provider identification (“SP ID”) information 219, which may be accessible to server 210 and/or terminal 220 and/or any other suitable portion of SP subsystem 200. SP ID information 219 may be utilized by client device 100′ and/or host device 100 and/or AE subsystem 400 and/or SP subsystem 200 and/or issuer subsystem 300 for uniquely identifying SP subsystem 200 to facilitate a transaction and/or to enable any suitable secure communication. As just one example, SP ID information 219 may be a telephone number or e-mail address or IP address or any unique identifier that may be associated with SP subsystem 200. Although not shown, SP subsystem 200 may also include an SP processor component that may be the same as or similar to a processor component 102 of electronic device 100 of FIGS. 1B and 2, an SP communications component that may be the same as or similar to a communications component 106 of electronic device 100 of FIGS. 1B and 2 (e.g., as a portion of server 210), an SP I/O interface that may be the same as or similar to an I/O interface 114 of electronic device 100 of FIG. 2, an SP bus that may be the same as or similar to a bus 118 of electronic device 100 of FIG. 2, an SP memory component that may be the same as or similar to a memory component 104 of electronic device 100 of FIG. 2, and/or an SP power supply component that may be the same as or similar to a power supply component 108 of electronic device 100 of FIG. 2.

Issuer subsystem 300 may include at least one issuing subsystem (e.g., issuing bank subsystem), such as first issuing subsystem 391 and second issuing subsystem 392. Additionally, in some embodiments, issuer subsystem 300 may include at least one network subsystem (e.g., payment network subsystem (e.g., a payment card association or a credit card association)), such as first network subsystem 361 and second network subsystem 362. For example, each issuing subsystem may be a financial institution that may assume primary liability for a consumer's capacity to pay off debts they may incur with a specific credential. One or more specific credential applets of NFC component 120 of host device 100 may be associated with a specific payment card that may be electronically linked to an account or accounts of a particular user. Various types of payment cards may be suitable, including credit cards, debit cards, charge cards, stored-value cards, fleet cards, gift cards, and the like. The commerce credential of a specific payment card may be provisioned on host device 100 (e.g., as a credential of a credential supplemental security domain (“SSD”) of NFC component 120, as described below) by an issuing subsystem of issuer subsystem 300 for use in a commerce credential data communication (e.g., a contactless proximity-based communication and/or an online-based communication) with SP subsystem 200 (e.g., directly or via AE subsystem 400 and/or via client device 100′). Each credential may be a specific brand of payment card that may be branded by a network subsystem of issuer subsystem 300. Each network subsystem of issuer subsystem 300 may be a network of various issuing subsystems of issuer subsystem 300 and/or various acquiring banks 399 that may process the use of payment cards (e.g., commerce credentials) of a specific brand. Also known as a payment processor or acquirer, acquiring bank subsystem 399 may be a banking partner of the SP associated with SP subsystem 200, and acquiring bank subsystem 399 may be configured to work with issuer subsystem 300 to approve and settle credential transactions attempted to be funded by host device 100 with host transaction credential data (e.g., via SP subsystem 200). A network subsystem and an issuing subsystem of issuer subsystem 300 (e.g., network subsystem 362 and issuing subsystem 392) may be a single entity or separate entities. For example, American Express may be both a network subsystem and an issuing subsystem, while, in contrast, Visa and MasterCard may be payment subsystems and may work in cooperation with issuing subsystems, such as Chase, Wells Fargo, Bank of America, and the like. Issuer subsystem 300 may also include one or more acquiring banks, such as acquiring bank subsystem 399. For example, acquiring bank subsystem 399 may be the same entity as issuing subsystem 392.

In order for a financial transaction to occur within system 1 (e.g., a particular type of the many suitable types of transactions that may be carried out by system 1 between client device 100′ and/or host device 100 and SP subsystem 200 according to the concepts disclosed herein), at least one commerce credential must be securely provisioned on a secure element of host device 100. For example, such a commerce credential may be at least partially provisioned on secure element 145 of host device 100 directly from issuer subsystem 300 or via AE subsystem 400 (e.g., a first host credential may be provisioned as first host credential data 652 between first issuing subsystem 391 (and/or associated first network subsystem 361) of issuer subsystem 300 and device 100, and/or a second host credential may be provisioned as second host credential data 654 between second issuing subsystem 392 (and/or associated second network subsystem 362) of issuer subsystem 300 and device 100, where any such host credential data may then be passed to NFC component 120 via communications component 106). First host credential data 652 may be provisioned on secure element 145 of device 100 as at least a portion or all of a credential supplemental security domain of NFC component 120 and may include a credential applet with credential information and/or a credential key, such as payment application or credential applet 153a with credential information 161a and credential key 155a′, while second host credential data 654 may be provisioned on secure element 145 of device 100 as at least a portion or all of a credential supplemental security domain of NFC component 120 and may include a credential applet with credential information and/or a credential key, such as payment application or credential applet 153b with credential information 161b and credential key 155b′. As shown in FIG. 1B, for example, issuer subsystem 300 (e.g., first issuing subsystem 391) may also have access to credential key 155a′ (e.g., for decrypting data encrypted by device 100 using credential key 155a′), and issuer subsystem 300 (e.g., second issuing subsystem 392) may also have access to credential key 155b′ (e.g., for decrypting data encrypted by device 100 using credential key 155b′). Issuer subsystem 300 may be responsible for management of credentials key 155a′ and 155b′, which may include the generation, exchange, storage, use, and replacement of such keys. Issuer subsystem 300 may store its version of each credential key in one or more appropriate secure elements of issuer subsystem 300. It is to be understood that each one of credential keys 155a′ and 155b′ of NFC component 120 and of issuer subsystem 300 may be any suitable shared secret (e.g., a password, passphrase, array of randomly chosen bytes, one or more symmetric keys, public-private keys (e.g., asymmetric keys), etc.) available to both the secure element of electronic device 100 and issuer subsystem 300 that may be operative to enable any suitable crypto data (e.g., a cryptogram) or any other suitable data to be independently generated by electronic device 100 and issuer subsystem 300 (e.g., for validating payment data for a financial transaction), such as by using any suitable cryptographic algorithm or cipher whose functional output may be at least partially determined by the shared secret, where such a shared secret may be provisioned on device 100 by issuer subsystem 300. A shared secret may either be shared beforehand between issuer subsystem 300 and host device 100 (e.g., during provisioning of a credential on device 100 by issuer subsystem 300), in which case such a shared secret may be referred to as a pre-shared key, or a shared secret may be created prior to use for a particular financial transaction by using a key-agreement protocol (e.g., using public-key cryptography, such as Diffie-Hellman, or using symmetric-key cryptography, such as Kerberos). The shared secret and any suitable cryptographic algorithm or cipher whose functional output may be at least partially determined by the shared secret may be accessible to the secure element of device 100.

AE subsystem 400 may be provided as an intermediary between issuer subsystem 300 and host device 100, where AE subsystem 400 may be configured to provide a new layer of security and/or to provide a more seamless user experience when a credential is being provisioned on a secure element of device 100 and/or when such a provisioned credential is being used as part of a host transaction credential data communication between device 100 and SP subsystem 200. AE subsystem 400 may be provided by any suitable administration and/or commercial entity that may offer various services to a user of device 100 and/or a user of device 100′ via user-specific log-in information to a user-specific account with that administration entity (e.g., via user-specific identification and password combinations). As just one example, AE subsystem 400 may be provided by Apple Inc. of Cupertino, Calif., which may also be a provider of various administration and/or other services to users of device 100 and/or of device 100′ (e.g., the iTunes™ Store for selling/renting media to be played by device 100, the Apple App Store™ for selling/renting applications for use on device 100, the Apple iCloud™ Service for storing data from device 100 and/or associating multiple user devices and/or multiple user profiles with one another, the Apple Online Store for buying various Apple products online, the Apple iMessage™ Service for communicating media messages between devices, etc.), and which may also be a provider, manufacturer, and/or developer of device 100 itself and/or device 100′ itself (e.g., when device 100 is an iPod™, iPad™, iPhone™, MacBook™, iMac™, Apple Watch™, or the like) and/or of an operating system (e.g., device application 103) of device 100 and/or of device 100′. The administration or commercial entity that may provide AE subsystem 400 (e.g., Apple Inc.) may be distinct and independent from any credential issuing and/or financial entity of issuer subsystem 300. For example, the administration or commercial entity that may provide AE subsystem 400 may be distinct and/or independent from any payment network subsystem 360 or issuing bank subsystem 370 that may furnish and/or manage any credit card or any other commerce credential to be provisioned on end-user host device 100. The entity that may provide AE subsystem 400 (e.g., Apple Inc.) may be distinct and independent from any merchant of SP subsystem 200 (e.g., any SP entity of SP subsystem 200 that may provide an SP terminal 220 for NFC communications, a third party-application 113/113′, and/or any other aspect of SP subsystem 200). Such an AE may leverage its potential ability to configure or control various components of device 100 (e.g., software and/or hardware components of device 100/100′, such as when that entity may at least partially produce or manage device 100/100′) in order to provide a more seamless user experience for a user of device 100/100′ when he or she wants to provision a credential offered by issuer subsystem 300 on host device 100 and/or when such a provisioned credential is being used as part of a host transaction credential data communication with SP subsystem 200 to find a transaction. For example, in some embodiments, device 100 may be configured to communicate with AE subsystem 400 seamlessly and transparently to a user of device 100 for sharing and/or receiving certain data that may enable a higher level of security (e.g., during an online-based host transaction credential data communication between device 100 and SP subsystem 200). Although not shown, AE subsystem 400 may also include or have access to a processor component, a communications component, an I/O interface, a bus, a memory component, and/or a power supply component that may be the same as or similar to such components of device 100, one, some or all of which may be at least partially provided by one, some, or each one of server 410, IDS subsystem 471, first security subsystem 491, and second security subsystem 492 of AE subsystem 400.

In addition to at least one commerce credential being provisioned on a secure element of NFC component 120 of host device 100 (e.g., a first host credential as a portion of a first credential SSD 154a with credential key 155a′ and credential information 161a and/or a second host credential as a portion of a second credential SSD 154b with credential key 155b′ and credential information 161b), at least one access SSD 154c with an access key 155c may also be provisioned on the secure element of NFC component 120 of device 100 in order to more securely enable device 100 to conduct a financial or other secure transaction with SP subsystem 200. For example, access SSD 154c may be at least partially provisioned on secure element 145 of host device 100 directly from AE subsystem 400 (e.g., as access data 651/653 between AE subsystem 400 and communications component 106 of device 100, which may then be passed to NFC component 120 from communications component 106). Access data 651/653 may be provisioned on device 100 as at least a portion or all of access SSD 154c and may include an access applet 153c with access key 155c. As shown in FIG. 1B, AE subsystem 400 may also have access to access key 155c (e.g., for decrypting data encrypted by device 100 using access key 155c). AE subsystem 400 may be responsible for management of access key 155c, which may include the generation, exchange, storage, use, and replacement of such a key. AE subsystem 400 may store its version of access key 155c in a secure element of AE subsystem 400. Access SSD 154c with access key 155c may be configured to determine 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 a determination, may be configured to enable another particular SSD for conducting a payment transaction (e.g., with a host credential of credential SSD 154a or SSD 154b). By storing such an access SSD within secure element 145 of device 100, its ability to reliably determine user intent for and authentication of a secure data transaction may be increased. Moreover, access key 155c may be used to provide increased encryption to any host transaction data that may be communicated outside of the secure element of device 100. Access data 651/653 may include an issuer security domain (“ISD”) key 156k for an ISD 152 of secure element 145, which may also be maintained by AE subsystem 400, and may be used in addition to or as an alternative to access key 155c (or one or more other ones of access keys 155a, 155b, 151k, and 158k). Although not explicitly shown or described, it is to be understood that AE subsystem 400 may be operative to interact with or be associated with client device 100′ in any or all of the same ways that AE subsystem 400 may be operative to interact with or be associated with host device 100 (e.g., when a credential may be provisioned on client device 100′, such that client device 100′ may be operative to operate as a host device).

An SP application or online resource 113′may be accessed by client device 100′ in order to enable an online transaction (e.g., online financial transaction) to be facilitated between device 100′ and SP subsystem 200. First, such an application 113′ may be approved or otherwise enabled by AE subsystem 400 before application 113′ may be accessible by client device 100′. For example, an application store 420 of AE subsystem 400 (e.g., the Apple App Store™) may receive at least some data representative of application 113′ from SP subsystem 200 via communications path 85. Moreover, in some embodiments, AE subsystem 400 may generate or otherwise assign an SP key 157′ for application 113′ and may provide such an SP key 157′ to SP subsystem 200 (e.g., via path 85). Alternatively, SP subsystem 200 may generate or otherwise assign an SP key 157′ for application 113′ and may provide such an SP key 157′ to AE subsystem 400 (e.g., via path 85). Either SP subsystem 200 or AE subsystem 400 may be responsible for management of SP key 157′, which may include the generation, exchange, storage, use, and replacement of such a key. No matter how or where such an SP key 157′ may be generated and/or managed, both SP subsystem 200 and AE subsystem 400 may store a version of SP key 157′ (e.g., in a respective secure element of SP subsystem 200 and AE subsystem 400). In some embodiments, such an SP key 157′ may be specifically associated with SP application 113′, while, in other embodiments, SP key 157′ may be specifically associated with a merchant of SP subsystem 200 such that SP key 157′ may be associated with multiple third party applications operated by the same merchant of SP subsystem 200. A table 430 or any other suitable data structure or source of information that may be accessible to AE subsystem 400 may be provided for associating a particular SP key 157′ with a particular SP application 113′ and/or SP entity using SP ID 219 or otherwise (e.g., each one of security subsystem 491 and 492 may include table 430). Table 430 may enable AE subsystem 400 to determine and utilize an appropriate SP key 157′ for providing a layer of security to any transaction credential data communicated to SP subsystem 200 (e.g., host transaction credential data that may include payment credential data native to host device 100) for a financial transaction that may involve client device 100′ interfacing with SP subsystem 200 via SP application 113′ associated with key 157′. Device 100′ may be configured to access application 113′ (e.g., from application store 420 via communications path 95) and run application 113′ (e.g., with processor 102′). An SP key 157′ may be associated with a merchant's website (e.g., one or more URLs) or with the merchant generally, rather than or in addition to a merchant's third party application (e.g., application 113′). For example, a merchant of SP subsystem 200 may work with AE subsystem 400 to associate a particular merchant website or the merchant generally with a particular SP key 157′ within table 430 (e.g., associated a particular SP ID 219 with a particular SP key), which may enable AE subsystem 400 to determine and utilize an appropriate SP key 157′ for providing a layer of security to any host transaction credential data (e.g., commerce credential data) communicated to SP subsystem 200 (e.g., host transaction credential data that may include payment credential data native to host device 100 for a transaction that may involve client device 100′ interfacing with SP server 210 to conduct a transaction via an internet application or web browser running on device 100′ that may be pointed to a URL whose target or web resource may be associated with that SP key 157′). Device 100′ may be configured to access such a URL, for example, from SP server 210 via communication path 15 (e.g., using an internet application 113′ on device 100′). In other embodiments, an application 113′ may not be associated with a specific SP entity, SP subsystem 200, and/or SP key 157′, but instead may be an independent application available to device 100′. In some embodiments, as shown, a similar application 113 with an SP key 157 may be provided for host device 100 (e.g., via AE subsystem 400), where application 113 may be the same as or different than application 113′ and/or where key 157 may be the same as or different than key 157′.

Description of FIG. 2

Referring now to FIG. 2, FIG. 2 shows a more detailed view of electronic device 100 of system 1 described above with respect to FIGS. 1-1B. As shown in FIG. 2, for example, device 100 may include processor 102, memory 104, communications component 106, power supply 108, input component 110, output component 112, antenna 116, and NFC component 120. Device 100 may also include a bus 118 that may provide one or more wired or wireless communication links or paths for transferring data and/or power to, from, or between various other components of device 100. Device 100 may also be provided with a housing 101 that may at least partially enclose one or more of the components of device 100 for protection 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. Moreover, device 100 may include other components not combined or included in FIG. 2. For example, device 100 may include any other suitable components or several instances of the components shown in FIG. 2. For the sake of simplicity, only one of each of the components is shown in FIG. 2. One or more input components 110 may be provided to permit a user to interact or interface with device 100 and/or one or more output components 112 may be provided to present information (e.g., graphical, audible, and/or tactile information) to a user of device 100. It should be noted that one or more input components and one or more output components may sometimes be referred to collectively herein as an input/output (“I/O”) component or I/O interface 114 (e.g., input component 110 and output component 112 as I/O component or I/O interface 114). For example, input component 110 and output component 112 may sometimes be a single I/O component 114, such as a touch screen, that may receive input information through a user's touch of a display screen and that may also provide visual information to a user via that same display screen. Processor 102 of device 100 may include any processing circuitry that may be operative to control the operations and performance of one or more components of device 100. For example, processor 102 may receive input signals from input component 110 and/or drive output signals through output component 112. As shown in FIG. 2, processor 102 may be used to run one or more applications, such as an application 103 and/or an application 113. As one example, application 103 may be an operating system application while application 113 may be a third party application or any other suitable online resource (e.g., an application associated with a merchant of SP subsystem 200). Moreover, as shown, processor 102 may have access to host device identification information 119, which may be utilized by a user of device 100 and/or AE subsystem 400 for providing identification of device 100 to SP subsystem 200 (e.g., for facilitating a transaction) and/or to AE subsystem 400 and/or client device 100′ (e.g., for facilitating secure communication between devices 100 and 100′).

NFC component 120 may be any suitable proximity-based communication mechanism that may enable contactless proximity-based transactions or communications between electronic device 100 and device 100′ and/or SP terminal 220. NFC component 120 may include any suitable modules for enabling contactless proximity-based communication between device 100 and such an SP terminal. As shown in FIG. 2, for example, NFC component 120 may include an NFC device module 130, an NFC controller module 140, and/or an NFC memory module 150. NFC device module 130 may include an NFC data module 132, an NFC antenna 134, and an NFC booster 136. NFC data module 132 may be configured to contain, route, or otherwise provide any suitable data that may be transmitted by NFC component 120 to an SP terminal as part of a contactless proximity-based or NFC communication. NFC data module 132 may be configured to contain, route, or otherwise receive any suitable data that may be received by NFC component 120 from an SP terminal as part of a contactless proximity-based communication. NFC controller module 140 may include at least one NFC processor module 142. NFC processor module 142 may operate in conjunction with NFC device module 130 to enable, activate, allow, and/or otherwise control NFC component 120 for communicating an NFC communication between device 100 and an SP terminal. 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 dictate the function of NFC component 120. NFC memory module 150 may operate in conjunction with NFC device module 130 and/or NFC controller module 140 to allow for NFC communications between device 100 and SP subsystem 200. NFC memory module 150 may be tamper resistant and may provide at least a portion of secure element 145 of device 100. For example, such a secure element may be configured to provide a tamper-resistant platform (e.g., as a single-chip or multiple-chip secure microcontroller) that may be capable of securely hosting applications and their confidential and cryptographic data (e.g., applets 153 and keys 155) in accordance with rules and security requirements that may be set forth by a set of well-identified trusted authorities (e.g., an authority of a credential issuer subsystem and/or a financial institution subsystem and/or an industry standard, such as GlobalPlatform).

As shown in FIG. 2, for example, NFC memory module 150 may include one or more of an issuer security domain (“ISD”) 152, SSDs 154a-154c (e.g., a service provider security domain (“SPSD”), a trusted service manager security domain (“TSMSD”), credential SSD, access SSD, etc.), which may be defined and managed by an NFC specification standard (e.g., GlobalPlatform). For example, ISD 152 may be a portion of NFC memory module 150 in which a trusted service manager (“TSM”) or issuing financial institution (e.g., issuer subsystem 300) may store one or more keys (e.g., ISD key 156k) and/or other suitable information for creating or otherwise provisioning one or more credentials (e.g., credentials associated with various credit cards, bank cards, gift cards, access cards, transit passes, digital currency (e.g., bitcoin and associated payment networks), etc.) on device 100 (e.g., via communications component 106), for credential content management, and/or security domain management. A credential may include credential data (e.g., credential information 161a) that may be assigned to a user/consumer and that may be stored securely on electronic device 100, such as a credit card payment number (e.g., a device primary account number (“DPAN”), DPAN expiry date, CVV, etc. (e.g., as a token or otherwise)). NFC memory module 150 may include at least three SSDs 154 (e.g., first credential SSD 154a, second credential SSD 154b, and access SSD 154c). For example, first credential SSD 154a and second credential SSD 154b may each be associated with a respective specific credential (e.g., a specific credit card credential or a specific public transit card credential provisioned by issuer subsystem 300) that may provide specific privileges or payment rights to electronic device 100, while access SSD 154c may be associated with a commercial or administration entity (e.g., an entity of AE subsystem 400, which may be a controlling entity for device 100) that may control access of device 100 to a specific credential of another SSD (e.g., first SSD 154a or second SSD 154b), for example, to provide specific privileges or payment rights to electronic device 100. Each SSD 154 may include and/or be associated with at least one applet 153 (e.g., SSD 154a with applet 153a and SSD 154b with applet 153b). For example, an applet 153 of an SSD 154 may be an application that may run on a secure element of NFC component 120 (e.g., in a GlobalPlatform environment). A 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 with at least one access key 155a and at least one credential key 155a′, and applet 153b with at least one access key 155b and at least one credential key 155b′).

A key 155 of an SSD 154 may be a piece of information that can determine a functional output of a cryptographic algorithm or cipher. For example, in encryption, a key may specify a particular transformation of plaintext into ciphertext, or vice versa during decryption. Keys may also be used in other cryptographic algorithms, such as digital signature schemes and message authentication codes. A key of an SSD may provide any suitable shared secret with another entity. Each key and applet may be loaded on the secure element of device 100 by a TSM or an authorized agent or pre-loaded on the secure element when first provided on device 100. As one example, while credential SSD 154a may be associated with a particular credit card credential, that particular credential may only be used to communicate a host transaction credential data communication to SP subsystem 200 from a secure element of device 100 (e.g., from NFC component 120) for a financial transaction when applet 153a of that credential SSD 154a has been enabled or otherwise activated or unlocked for such use.

Security features may be provided for enabling use of NFC component 120 that may be particularly useful when transmitting confidential payment information, such as credit card information or bank account information of a credential, from electronic device 100 to SP subsystem 200 (e.g., via AE subsystem 400 and/or via device 100′). Such security features also may include a secure storage area that may have restricted access. For example, user authentication via personal identification number (“PIN”) entry or via user interaction with a biometric sensor may need to be provided to access the secure storage area. As an example, access SSD 154c may leverage applet 153c to determine whether such authentication has occurred before allowing other SSDs 154 (e.g., credential SSD 154a or credential SSD 154b) to be used for communicating its credential information 161. In certain embodiments, some or all of the security features may be stored within NFC memory module 150. Further, security information, such as an authentication key, for communicating commerce credential data with SP subsystem 200 may be stored within NFC memory module 150. In certain embodiments, NFC memory module 150 may include a microcontroller embedded within electronic device 100. 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 a biometric input component) and, in response to such a determination, may be configured to enable another particular SSD for conducting a payment transaction (e.g., with a credential of credential SSD 154a).

Description of FIG. 2A

Referring now to FIG. 2A, FIG. 2A shows another detailed view of a portion of device 100 of system 1 described above with respect to FIGS. 1-2. As shown in FIG. 2A, for example, a secure element 145 of NFC component 120 may include SSD 154a, which may include or be associated with applet 153a, credential information 161a, access key 155a, and/or credential key 155a′, and SSD 154b, which may include or be associated with applet 153b, credential information 161b, access key 155b, and/or credential key 155b′. In some embodiments, each one of SSDs 154a and 154b may be associated with a particular TSM and at least one specific commerce credential (e.g., a specific credit card credential or a specific public transit card credential) that may provide specific privileges or payment rights to electronic device 100 (e.g., SSD 154a may be associated with a first host transaction credential provisioned from first issuing subsystem 391 of issuer subsystem 300 and SSD 154b may be associated with a second host transaction credential provisioned from second issuing subsystem 392 of issuer subsystem 300, as mentioned with respect to FIG. 1). Each SSD 154 may have its own manager key 155 (e.g., a respective one of keys 155ak and 155bk) that may need to be activated to enable a function of that SSD 154 for use by NFC device module 130. Each SSD 154 may include and/or be associated with at least one of its own credential applications or credential applets (e.g., a Java card applet instances) associated with a particular commerce credential (e.g., credential applet 153a of SSD 154a may be associated with a first commerce credential and/or credential applet 153b of SSD 154b may be associated with a second commerce credential), where a 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/or credential key 155b′ for credential applet 153b), and where a credential applet may need to be activated to enable its associated commerce credential for use by NFC device module 130 as an NFC communication (e.g., with SP terminal 220) and/or as an online-based communication between device 100 and SP subsystem 200 (e.g., via AE subsystem 400 and/or client device 100′). In some embodiments, a credential key of a credential applet may be generated by issuer subsystem 300 that may be responsible for such a credential and may be accessible by that issuer subsystem 300 for enabling secure transmission of that credential information of that applet between secure element 145 and issuer subsystem 300. An access key of a credential applet may be generated by AE subsystem 400 and may be accessible by AE subsystem 400 for enabling secure transmission of that credential information of that applet between secure element 145 and AE subsystem 400. As shown, each applet may include its own unique application identifier (“AID”), such as AID 155a a of applet 153a and/or AID 155b a of 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.), where an AID may include not only a registered application provider identifier (“RID”) that may be used to identify a 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 differentiate between products, programs, or applications offered by a provider or payment system of the credential associated with the AID. Any suitable specification (e.g., a Java Card specification) that may be operative to preside over firmware of secure element 145 may be operative to ensure or otherwise force the uniqueness of each AID on secure element 145 (e.g., each credential instance on secure element 145 may be associated with its own unique MD).

As shown in FIG. 2A, secure element 145 may include ISD 152, which may include an ISD key 156k that may also be known to a trusted service manager associated with that security domain (e.g., AE subsystem 400, as shown in FIG. 1B). ISD key 156k may be leveraged by AE subsystem 400 and device 100 similarly to and/or instead of access key 155a and/or access key 155b for enabling secure transmissions between AE subsystem 400 and secure element 145. Moreover, as shown in FIG. 2A, various data may be communicated between processor 102 and secure element 145. For example, processor 102 of device 100 may be configured to run a device application 103 that may communicate information with an application 113 of processor 102 as well as 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 communications component 106. Moreover, as shown, processor 102 may have access to device identification information 119, which may be utilized for enabling secure communication between device 100 and remote entities.

As shown in FIG. 2A, secure element 145 may include a controlling authority security domain (“CASD”) 158, which may be configured to generate and/or otherwise include CASD access kit 158k (e.g., CASD keys, certificates, and/or signing modules). For example, CASD 158 may be configured to sign certain data on secure element 145 (e.g., using CASD access kit 158k) before providing such data to another portion of device 100 (e.g., communications component 106 for sharing with other subsystems of system 1). Secure element 145 may include a contactless registry services (“CRS”) applet or application 151 that may be configured to provide local functionality to electronic device 100 for modifying a life cycle state (e.g., activated, deactivated, locked, etc.) of certain security domain elements and sharing certain output information 115o about certain security domain elements in certain life cycle states with a user of device 100 (e.g., via a 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 secure element 145 and may be configured to share the life cycle state of one or more security domain elements with an application of device 100 (e.g., with any suitable application type, such as a daemon, such as card management daemon (“CMD”) application 113a that may be miming as a background process inside an operating system application 103 and/or a card management application 113b (e.g., a Passbook™ or Wallet™ application by Apple Inc.) and/or an SP application 113c (e.g., an SP application as may be associated with SP key 157) and/or an identity services (“IDS”) application 113d, but that may not necessarily be under the control of an interactive user of device 100), which in turn may provide certain life cycle state information to a user of device 100 as output information 115o via I/O interface 114a and a user interface (“UI”) application (e.g., a UI of card management application 113b), which may enable a user to change a life cycle state of a security domain element. CRS 151 may include a CRS access key 151k that may also be known to a trusted service manager associated with CRS 151 (e.g., AE subsystem 400, as shown in FIG. 1B) and may be leveraged by AE subsystem 400 and device 100 similarly to and/or instead of access key 155a and/or access key 155b for enabling secure transmissions between AE subsystem 400 and secure element 145.

IDS application 113d may be any suitable application type, such as a daemon, that may be running as a background process inside operating system application 103 and/or card management application 113b and/or that may be provided by CMD application 113a, and may be operative as an IDS manager for listening for and responding to IDS messages that may be sent over any suitable IDS service (e.g., an IDS service of IDS subsystem 471 of AE subsystem 400) to and/or from device 100, which may be similar to any suitable messaging service, such as iMessage™ by Apple Inc., or the like (e.g., FaceTime™ or Continuity™ by Apple Inc.), and/or which may enable unique end-to-end encryption of messages between IDS application 113d of host device 100 and a similar IDS application of another device (e.g., an IDS application of client device 100′). Such messages may be encrypted using unique identifiers for one or both of the communicating devices (e.g., host device unique identifier 119 and/or client device unique identifier 119′) and/or for one or both of the specific users of the communicating devices. Such messages may be communicated as a local link or a true device to device (e.g., peer to peer) communication, or may be communicated via AE subsystem 400 (e.g., via IDS subsystem 471 (e.g., using an identity management system component 470)). Such messaging may be enabled as a low latency solution that may allow data to be exchanged in structured formats (e.g., protocol buffers) and/or unstructured formats. IDS application 113d may be automatically awoken should it not be running when an IDS message is received. IDS application 113d may be operative to present an appropriate user interface and shepherd requested data of a received IDS communication back to the requesting device. IDS application 113d of a host device may be operative to wake up card management daemon application 113a of card management application 113b when an initial request may be detected from a client device, which may allow the host device to operate in a low-power or “sleep” mode. IDS application 113d may be operative to manage a “time out” for such a request, such that, should a request for payment from a client device go unactioned on the host device for a period of time (e.g., 60 seconds, due to no active host device user interaction responsive to such a request), then IDS application 113d may be operative to make a determination to terminate the request that may result in the host device generating and delivering a “cancel” status back to the client device, which may display an appropriate message (e.g., “time out error”) to a user of the client device.

Description of FIG. 3 and FIGS. 3A-3H

As shown in FIG. 3, and as described below in more detail, a specific example of host electronic device 100 may be a handheld electronic device, such as an iPhone™, where 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 device 100 and a user and/or an ambient environment may interface with each other. For example, a touch screen I/O component 114a may include a display output component 112a and an associated touch input component 110f, where display output component 112a may be used to display a visual or graphic user interface (“GUI”) 180, which may allow a user to interact with electronic device 100. GUI 180 may include various layers, windows, screens, templates, elements, menus, and/or other components of a currently running application (e.g., application 103 and/or application 113 and/or application 143) that may be displayed in all or some of the areas of display output component 112a. For example, as shown in FIG. 3, GUI 180 may be configured to display a first screen 190 with one or more graphical elements or icons 182 of GUI 180. When a specific icon 182 is selected, device 100 may be configured to open a new application associated with that icon 182 and display a corresponding screen of GUI 180 associated with that application. For example, when the specific icon 182 labeled with a “Merchant App” textual indicator 181 (i.e., specific icon 183) is selected by a user of device 100, device 100 may launch or otherwise access a specific third party merchant or SP application and may display screens of a specific user interface that may include one or more tools or features for interacting with device 100 in a specific manner (see, e.g., FIGS. 3A-3H for specific examples of such displays of GUI 180 during use of any suitable application (e.g., card management application 113b or SP application 113c on host device 100 and/or SP application 113′ on client device 100′) that may be used by a device user for making a payment with a credential of NFC component 120 (e.g., a credential of credential SSD 154b) of host device 100). As another example, when the specific icon 182 labeled with a “Wallet” textual indicator 181 (i.e., specific icon 185) is selected, device 100 may launch or otherwise access a specific device application (e.g., card management application 113b of FIG. 3 (e.g., as a “Wallet” or “Passbook” application) for managing various credentials on secure element 145) and may display screens of a specific user interface that may include one or more tools or features for interacting with device 100 in a specific manner. For each application, screens may be displayed on display output component 112a and may include various user interface elements. For each application, various other types of non-visual information may be provided to a user via various other output components 112 of device 100.

While FIGS. 2-3 may be described with respect to host device 100, it is to be understood that one, some, or all of the components of device 100 of any one or more of FIGS. 2-3 may similarly be provided by client device 100′. In some embodiments, one or more components of host device 100 may not be provided by client device 100′ (e.g., client device 100′ may not include a secure element with one or more credentials provisioned thereon, while in other embodiments client device 100′ may also include a secure element with one or more native credentials provisioned thereon and yet client device 100′ may still facilitate a financial transaction using a non-native credential (e.g., a credential native to host device 100)). In some embodiments, client device 100′ may not include a user interface component operative to provide a GUI but may instead be considered a more automated device. Host device 100 may not include a user interface component operative to provide a GUI but may instead provide an audio output component and mechanical or other suitable user input components for selecting and authenticating use of a payment credential for funding a transaction.

Description of FIG. 4

Referring now to FIG. 4, FIG. 4 shows further details with respect to various embodiments of AE subsystem 400 of system 1. As shown in FIG. 4, AE subsystem 400 may be a secure platform system and may include a secure mobile platform (“SMP”) broker component 440, an SMP trusted services manager (“TSM”) component 450, an SMP crypto services component 460, an identity management system (“IDMS”) component 470, a fraud system component 480, a hardware security module (“HSM”) component 490, store component 420, and/or one or more servers 410. In some embodiments, one or more components of AE subsystem 400 may be combined or omitted. Moreover, AE subsystem 400 may include other components not combined or included in FIG. 4. For example, AE subsystem 400 may include any other suitable components or several instances of the components shown in FIG. 4. For the sake of simplicity, only one of each of the components is shown in FIG. 4. One, some, or all components of AE subsystem 400 may be implemented using one or more processor components, which may be the same as or similar to processor component 102 of device 100, one or more memory components, which may be the same as or similar to memory component 104 of device 100, and/or one or more communications components, which may be the same as or similar to communications component 106 of device 100. One, some, or all components of AE subsystem 400 may be managed by, owned by, at least partially controlled by, and/or otherwise provided by a single administration or commercial entity (e.g., Apple Inc.) that may be distinct and independent from issuer subsystem 300. The components of AE subsystem 400 may interact with each other and collectively with issuer subsystem 300 and/or host electronic device 100 and/or client electronic device 100′ and/or SP subsystem 200 for providing a new layer of security and/or for providing a more seamless user experience. In some embodiments, ISD subsystem 471, first security subsystem 491, and second security subsystem 492 may each include its own processing component, memory component, communications component, server 410, table 430, SMP broker component 440, SMP TSM component 450, SMP crypto services component 460, IDMS component 470, fraud system component 480, and HSM component 490.

SMP broker component 440 of AE subsystem 400 may be configured to manage user authentication with an administration or commercial entity user account. SMP broker component 440 may also be configured to manage the lifecycle and provisioning of credentials on device 100. SMP broker component 440 may be a primary end point that may control the user interface elements (e.g., elements of GUI 180) on device 100 and/or on device 100′. An operating system or other application of an end user device (e.g., application 103, application 113, and/or application 143 of host device 100) may be configured to call specific application programming interfaces (“APIs”) and SMP broker 440 may be configured to process requests of those APIs and respond with data that may derive the user interface of device 100 and/or respond with application protocol data units (“APDUs”) that may communicate with the secure element of NFC component 120 (e.g., via a communication path 65 between AE subsystem 400 and device 100). Such APDUs may be received by AE subsystem 400 from issuer subsystem 300 via a TSM of system 1 (e.g., a TSM of a communication path 55 between AE subsystem 400 and issuer subsystem 300). SMP TSM component 450 of AE subsystem 400 may be configured to provide GlobalPlatform-based services or any other suitable services that may be used to carry out credential provisioning operations on device 100 from issuer subsystem 300. GlobalPlatform, or any other suitable secure channel protocol, may enable SMP TSM component 450 to properly communicate and/or provision sensitive account data between secure element 145 of device 100 and a TSM for secure data communication between AE subsystem 400 and issuer subsystem 300.

SMP TSM component 450 may be configured to use HSM component 490 to protect its keys and generate new keys. SMP crypto services component 460 of AE subsystem 400 may be configured to provide key management and cryptography operations that may be provided for user authentication and/or confidential data transmission between various components of system 1. SMP crypto services component 460 may utilize HSM component 490 for secure key storage and/or opaque cryptographic operations. A payment crypto service of SMP crypto services component 460 may be configured to interact with IDMS component 470 to retrieve information associated with on-file credit cards or other types of commerce credentials associated with user accounts of the administration entity (e.g., an Apple iCloud™ account). Such a payment crypto service may be configured to be the only component of AE subsystem 400 that may have clear text (i.e., non-hashed) information describing commerce credentials (e.g., credit card numbers) of its user accounts in memory. IDMS component 470 may be configured to enable and/or manage any suitable communication between host device 100 and client device 100% such as an identity services (“IDS”) transport (e.g., using an administration-entity specific (or other entity specific) service (e.g., iMessage™ by Apple Inc.) that may be facilitated by IDS subsystem 471). For example, certain devices may be automatically or manually registered for such a service (e.g., all devices in an eco-system of commercial entity 400 may be automatically registered for the service). Such a service may provide an end-to-end encrypted mechanism that may require active registration before messages can be sent using the service (e.g., using IDS application 113d of host device 100 and IDS subsystem 471). IDMS component 470 and/or any other suitable server or portion of AE subsystem 400 may be operative to identify or otherwise lookup the status of any credentials provisioned on any electronic devices associated with a given user account or otherwise, such that AE subsystem 400 may be operative to efficiently and effectively identify one or more non-native payment credentials that may be available to a particular client device associated with a particular user account (e.g., multiple host devices of a family account with AE subsystem 400). Fraud system component 480 of AE subsystem 400 may be configured to run an administration entity fraud check on a transaction credential based on data known to the administration entity about the transaction credential and/or the user (e.g., based on data (e.g., transaction credential information) associated with a user account with the administration entity and/or any other suitable data that may be under the control of the administration entity and/or any other suitable data that may not be under the control of issuer subsystem 300). Fraud system component 480 may be configured to determine an administration entity fraud score for the credential based on various factors or thresholds. AE subsystem 400 may include store 420, which may be a provider of various services to users of device 100 (e.g., the iTunes™ Store for selling/renting media to be played by devices 100/100′, the Apple App Store™ for selling/renting applications for use on devices 100/100′, the Apple iCloud™ Service for storing data from devices 100/100′ and/or associating multiple user devices and/or multiple user profiles with one another, the Apple Online Store for buying various Apple products online, etc.). As just one example, store 420 may be configured to manage and provide an application 113 to device 100 (e.g., via communications path 65), where application 113 may be any suitable application, such as a banking application, an SP application, an e-mail application, a text messaging application, an internet application, a card management application, or any other suitable communication application. Any suitable communication protocol or combination of communication protocols may be used by AE subsystem 400 to communicate data amongst the various components of AE subsystem 400 (e.g., via at least one communications path 495 of FIG. 4) and/or to communicate data between AE subsystem 400 and other components of system 1 (e.g., issuer subsystem 300 via communications path 55 of FIG. 1B and/or host device 100 via communications path 65 of FIG. 1B and/or SP subsystem 200 via communications path 85 of FIG. 1B and/or client device 100′ via communications path 95 of FIG. 1B).

Description of FIG. 5

FIG. 5 is a flowchart of an illustrative process 500 for conducting a transaction with a service provider subsystem (e.g., using an administration entity subsystem, a client electronic device, and a host electronic device that includes a secure element and a host credential application provisioned on the secure element). At operation 502 of process 500, the administration entity subsystem may receive, from the host electronic device, host transaction data including host transaction credential data generated by the host credential application on the secure element of the host electronic device and transaction information including a service provider identifier indicative of the service provider subsystem (e.g., as described with respect to FIG. 6, second security subsystem 492 may receive, from host device 100, host transaction data 678 that may include host transaction credential data 675/676 generated by second credential applet 153b provisioned on secure element 145 and transaction data 666 indicative of SP subsystem 200). At operation 504 of process 500, the administration entity subsystem may obtain unique voucher data (e.g., as described with respect to FIG. 6, second security subsystem 492 may obtain unique voucher data 682). At operation 506 of process 500, the administration entity subsystem may store the unique voucher data against (or in association with (e.g., such that there may be a relationship between (e.g., such that one can be resolved against))) administration host transaction credential data that includes the host transaction credential data of the received host transaction data (e.g., as described with respect to FIG. 6, second security subsystem 492 may store voucher data 682 against SP credential data 681 that includes host transaction credential data 675/676). At operation 508 of process 500, the administration entity subsystem may communicate the unique voucher data to at least one of the host electronic device, the client electronic device, and the service provider subsystem (e.g., as described with respect to FIG. 6, second security subsystem 492 may communicate voucher data 682 to at least one of host device 100, client device 100′, and SP subsystem 200).

It is understood that the operations shown in process 500 of FIG. 5 are only illustrative and that existing operations may be modified or omitted, additional operations may be added, and the order of certain operations may be altered. Further, in some implementations, two or more operations may occur in parallel or in a different sequence than described.

Description of FIG. 6

FIG. 6 is a flowchart of an illustrative process 600 for conducting a transaction (e.g., a financial transaction) using an electronic device with a geographically restricted non-native payment credential. Process 600 is shown being implemented by host device 100, client device 100′, SP subsystem 200, issuer subsystem 300, and AE subsystem 400. However, it is to be understood that process 600 may be implemented using any other suitable components or subsystems. Process 600 may provide a seamless user experience for securely and efficiently conducting a transaction with SP subsystem 200 via client device 100′ while using a transaction credential from host device 100. To facilitate the following discussion regarding the operation of system 1 for conducting a transaction according to process 600 of FIG. 6, reference is made to various components of system 1 of the schematic diagrams of FIGS. 1-4, and to front views of screens 190-190h of FIGS. 3-3H that may be representative of a graphical user interface of host device (HD) 100 (e.g., a GUI as may be provided by card management application 113b or SP application 113c or any suitable payment application of host device 100) and/or that may be representative of a graphical user interface of client device (CD) 100′ (e.g., a GUI as may be provided by an SP application 113′ of client device 100′ or any suitable payment application of client device 100′) during such a transaction. The operations described may be achieved with a wide variety of graphical elements and visual schemes. Therefore, the embodiments of FIGS. 3-3H are not intended to be limited to the precise user interface conventions adopted herein. Rather, embodiments may include a wide variety of user interface styles.

Process 600 may begin at operation 601, where first host access data 651 (e.g., first host access data 651 of FIG. 1B) may be provisioned on secure element 145 of host device 100 by AE subsystem 400. For example, a first access SSD (e.g., SSD 154c) may be provisioned on secure element 145 of host device 100 as first access data 651 from server 410 of first security subsystem 491 in order to more securely enable host device 100 to conduct a transaction with SP subsystem 200 using first security subsystem 491. As mentioned, access SSD 154c may be at least partially provisioned on secure element 145 of host device 100 directly from AE subsystem 400 (e.g., as host access data 651 via communication path 65 between a server 410 of first security subsystem 491 and communications component 106 of host device 100, which may then be passed to secure element 145 from communications component 106 (e.g., via bus 118)). Host access data 651 via path 65 may be provisioned on secure element 145 of host device 100 as at least a portion or all of access SSD 154c and may include access applet 153c and/or access key 155c. In some implementations, operation 601 may be at least partially carried out when host device 100 is initially configured (e.g., by AE subsystem 400 before host device 100 is sold to a user). Operation 601 may be at least partially carried out in response to a user of host device 100 initially setting up secure element 145 of NFC component 120. Host access data 651 may include ISD key 156k for ISD 152 of secure element 145 and may be used in addition to or as an alternative to access key 155c for enabling secure transmissions between AE subsystem 400 and host device 100. Host access data 651 may include CRS 151k of CRS 151 and/or CASD 158k of CASD 158 of secure element 145 of host device 100 and may be used in addition to or as an alternative to access key 155c and/or access key 155a and/or ISD key 156k for enabling secure transmissions between AE subsystem 400 and host device 100 (e.g., for use as any suitable commercial entity key or shared secret between AE subsystem 400 and host device 100).

At operation 602, first host credential data 652 (e.g., credential data 652 of FIG. 1B) may be provisioned on secure element 145 of host device 100 by first issuing subsystem 391 of issuer subsystem 300, in some embodiments, via AE subsystem 400. For example, such first host credential data 652 may be at least partially provisioned on secure element 145 of host device 100 directly from first issuing subsystem 391 (e.g., via communication path 75 of FIG. 1B between issuer subsystem 300 and device 100, which may be passed to secure element 145 via communications component 106). Such first host credential data 652 may be at least partially provisioned on secure element 145 from first issuing subsystem 391 via AE subsystem 400 (e.g., via communication path 55 of FIG. 1B between first issuing subsystem 391 and first security subsystem 491 of AE subsystem 400, which may be passed to host device 100 as first host credential data 652 via communication path 65 of FIG. 1B between server 410 of first security subsystem 491 and communications component 106 of host device 100, which may then be passed to secure element 145 from communications component 106 (e.g., via bus 118)). First host credential data 652 via path 75 and/or via path 65 may be provisioned on secure element 145 of host device 100 as at least a portion or all of first credential SSD 154a and may include credential applet 153a with credential information 161a and/or credential key 155a′ and/or key 155ak. Operation 602 may be at least partially carried out when a user of host device 100 selects a particular credential of first issuing subsystem 391 to be provisioned on host device 100. In some embodiments, first host credential data 652 may also include access key 155a, which may be initially provided from AE subsystem 400 to issuer subsystem 300 and/or may be added by AE subsystem 400. In some embodiments, such first host credential data 652 may include the primary account number as at least a portion of credential information of a payment credential being provisioned (e.g., credential information 161a of applet 153a), an AID (e.g., AID 155a a for applet 153a of the data of the payment credential being provisioned at SSD 154a), an SSD identifier, and/or an SSD counter.

Process 600 may also include operation 603, at which second host access data 653 may be provisioned on secure element 145 of host device 100 by AE subsystem 400. For example, a second access SSD or additional data for first access SSD 154c may be provisioned on secure element 145 of host device 100 as second access data 653 from server 410 of second security subsystem 492 of AE subsystem 400 in order to more securely enable host device 100 to conduct a transaction with SP subsystem 200 using second security subsystem 492. Therefore, operation 603 may be similar to operation 601, but may be carried out by second security subsystem 492 rather than by first security subsystem 491. Additionally, process 600 may also include operation 604, at which second host credential data 654 may be provisioned on secure element 145 of host device 100 by second issuing subsystem 392 of issuer subsystem 300, in some embodiments, via AE subsystem 400. For example, such second host credential data 654 may be at least partially provisioned on secure element 145 of host device 100 directly from second issuing subsystem 392 of issuer subsystem 300 (e.g., via communication path 75 of FIG. 1B between issuer subsystem 300 and device 100, which may be passed to secure element 145 via communications component 106). Such second host credential data 654 may be at least partially provisioned on secure element 145 of host device 100 from second issuing subsystem 392 of issuer subsystem 300 via AE subsystem 400 (e.g., via communication path 55 of FIG. 1B between second issuing subsystem 392 of issuer subsystem 300 and second security subsystem 492 of AE subsystem 400, which may be passed to host device 100 as second host credential data 654 via communication path 65 of FIG. 1B between server 410 of second security subsystem 492 of AE subsystem 400 and communications component 106 of host device 100, which may then be passed to secure element 145 from communications component 106 (e.g., via bus 118)). Second host credential data 654 via path 75 and/or via path 65 may be provisioned on secure element 145 as at least a portion or all of second credential SSD 154b and may include credential applet 153b with credential information 161b and/or credential key 155b′ and/or key 155bk. Operation 604 may be at least partially carried out when a user of host device 100 selects a particular credential of second issuing subsystem 392 to be provisioned on host device 100. In some embodiments, second host credential data 654 may also include access key 155b, which may be initially provided from AE subsystem 400 to issuer subsystem 300 and/or may be added by AE subsystem 400. In some embodiments, such second host credential data 654 may include the primary account number as at least a portion of credential information of a payment credential being provisioned (e.g., credential information 161b of applet 153b), an AID (e.g., AID 155b a for applet 153b of the data of the payment credential being provisioned at SSD 154b), an SSD identifier, and/or an SSD counter. Therefore, operation 604 may be similar to operation 602, but may be carried out by second issuing subsystem 392 with or without second security subsystem 492 rather than by first issuing subsystem 391 with or without first security subsystem 491.

Each one of the first credential data of operation 602 and the second credential data of operation 604 provisioned on host device 100 may include all data necessary to make a payment with that credential, such as, for example, a primary account number (“PAN”), a card security code (e.g., a card verification code (“CVV”)), PAN expiration date, name associated with the credential, and the like, as well as other data that may be operative for host device 100 to generate appropriate crypto data (e.g., any suitable shared secret and any suitable cryptographic algorithm or cipher whose functional output may be at least partially determined by the shared secret). A “virtual” credential or virtual PAN or device PAN (“D-PAN”) may be provisioned on host device 100 rather than (or in addition to) the user's “actual” credential or actual PAN or funding PAN (“F-PAN”). For example, once it is determined that a credential is to be provisioned on host device 100, it may be requested (e.g., by issuer subsystem 300, by AE subsystem 400, and/or by a user of host device 100) that a virtual credential be generated, linked to the actual credential, and provisioned on host device 100 instead of the actual credential. Such creation and linking of a virtual credential with an actual credential 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 361 or 362 that may be associated with the brand of the actual credential) may define and store a virtual-linking table 312 (e.g., as shown in FIG. 1B) that may create associations between the actual credential and a virtual credential, such that anytime a virtual credential is utilized by host device 100 for a transaction with SP subsystem 200 (e.g., after being provisioned on host device 100), the payment network subsystem may receive an authorization or validation request or otherwise attempt to validate any received data indicative of that virtual credential (e.g., at operation 644 in response to receiving data 692 at operation 642) and may conduct an analysis of that validation attempt request in light of the actual credential associated with the virtual credential as determined by table 312. Alternatively, such a table may be accessible and/or similarly leveraged by an appropriate issuing subsystem (e.g., issuing subsystem 391 or 391) or any other suitable subsystem accessible by issuer subsystem 300. By provisioning a virtual credential on host device 100 rather than an actual credential, issuer subsystem 300 may be configured to limit the fraudulent activity that may result when the virtual credential is intercepted by an unauthorized user, as a payment network subsystem or issuing subsystem may only be configured to utilize table 312 for linking the virtual credential to the actual credential during certain transactions.

At operation 606, an SP's online resource, such as an SP application or an SP website, may be associated with an SP key. For example, AE subsystem 400 may populate a table 430 (e.g., at least a table 430 of second security subsystem 492) to associate an SP key with a merchant's resource (e.g., SP key 157 with an SP ID 219 of SP resource 113 of host device 100 and/or SP key 157′ with an SP ID 219 of SP resource 113′ of client device 100′) for enabling a secure transaction credential data communication between AE subsystem 400 and SP subsystem 200 (e.g., via host device 100 and/or client device 100′) using that SP key during a transaction that may use that SP resource. Both SP subsystem 200 and AE subsystem 400 may store a version of such an SP key (e.g., in a respective secure element of SP subsystem 200 and AE subsystem 400). In some embodiments, in order to participate in an online-resource payment program, a service provider may be required to register as a member of a program run by the administration entity of AE subsystem 400 and/or obtain an SP certificate (e.g., after passing any suitable SP validation process). Service providers may not be able to receive payment data without an SP certificate. Each certificate may contain a unique administration entity SP identifier (e.g., SP ID 219) that may bind the SP to the public key for that SP (e.g., a public SP key 157/157′). An SP may obtain multiple certificates, and thus may hold more than one identity. Such a unique administration entity SP identifier (e.g., SP ID 219) may be provided by SP subsystem 200 to client device 100′ (e.g., at operation 610 as a portion of potential transaction data 660 and/or as an inherent element of the SP online resource running on client device 100′ (e.g., SP application 113′)), and such an administration entity SP identifier (e.g., SP ID 219) may be provided from client device 100′ to AE subsystem 400 via host device 100 during an attempted transaction (e.g., as at least a portion of host transaction data 678 at operation 628 via transaction request data 666). In some embodiments, AE subsystem 400 may generate or otherwise assign an SP key for an SP online resource (e.g., key 157 for application 113 and/or key 157′ for application 113′) and provide such an SP key to SP subsystem 200 (e.g., via path 85). Alternatively, SP subsystem 200 may generate or otherwise assign an SP key for an SP online resource and provide such an SP key to AE subsystem 400 (e.g., via path 85). Either SP subsystem 200 or AE subsystem 400 may be responsible for management of any SP keys, which may include the generation, exchange, storage, use, and replacement of such a key. No matter how or where such an SP key may be generated and/or managed, both SP subsystem 200 and AE subsystem 400 may store a version of an SP key (e.g., in a respective secure element of SP subsystem 200 and AE subsystem 400). This may enable a shared secret between AE subsystem 400 and SP subsystem 200 for securely communicating data therebetween. In some embodiments, host device 100 may be provided with such an SP key for securely encrypting payment data with that key on host device 100.

At operation 608, an SP's resource 658 (e.g., an SP's third party resource 113′ of FIG. 1B) may be accessed by client device 100′. As shown in FIG. 1B, a merchant's resource application 113′ may be loaded onto client device 100′ from AE subsystem 400 (e.g., from an application store 420). For example, as shown in FIG. 3 but with respect to host device 100, a user of client device 100′ may select a “Merchant App” icon 183 of a specific screen 190 of GUI 180 using touch screen input component 110f of I/O component 114a, and this selection may be recognized by client device 100′ as an initiation event for providing the user with the ability to interact with an SP's third party application 113′. Such an SP's resource 658 may be accessed by client device 100′ directly from SP subsystem 200. In response to such a selection of an SP application icon, a GUI may provide an interactive screen where client device 100′ may enable the user to interact with application 113′ to view commercially available items from the SP for purchase. Alternatively, at operation 608, client device 100′ may access an SP's resource 658 as a merchant's webpage from SP subsystem 200 (e.g., via SP server 210) using an internet application of client device 100′, which may also be selectable by an “Internet” icon (i.e., specific icon 184) of specific screen 190 of GUI 180 of FIG. 3) for providing the user with the ability to interact with a merchant's webpage rather than with an SP's third party application. Alternatively, at operation 608, resource 658 may be automatically accessed in any suitable way without active user input (e.g., client device 100′ may be operative to automatically interact with resource 658 in response to detecting any suitable event, such as an autonomous home appliance client device 100′ detecting that it is running low of a particular supply (e.g., a washing machine client device 100′ in response to detecting a low supply of laundry detergent)).

At operation 610, client device 100′ may receive potential transaction data 660 from the accessed SP resource. For example, as shown in FIG. 1B, potential transaction data 660 may be provided to client device 100′ from SP subsystem 200 (e.g., from SP server 210) when client device 100′ is interacting with the SP's resource 113′ (e.g., third party application or website or any other suitable online resource (e.g., resource 658) of the SP). At least a portion of potential transaction data 660 may be locally accessible by client device 100′ via application 113′ local to client device 100′ (e.g., when application 113′ is stored in a memory component or being run by processor 102′ of client device 100′), rather than the data being actively sent to client device 100′ from SP server 210 at operation 610. For example, when application 113′ may be initially stored on client device 100′ (e.g., at operation 608 as merchant's resource 658), at least some of potential transaction data 660 may be generated by that initially stored application 113′ absent any additional information provided to client device 100′ by SP subsystem 200. Potential transaction data 660 may include any suitable data indicative of any suitable characteristics of a potential transaction to occur between a user of client device 100′ and an SP of SP subsystem 200, including, but not limited to, (i) specific SP information, such as a unique SP identifier (e.g., SP ID 219) (e.g., an acquiring bank SP identifier (e.g., an identifier of acquiring bank subsystem 399) and/or an administration entity SP identifier (e.g., SP ID 219)) and/or identification of the particular SP resource being used (e.g., the particular SP application 113′) and/or identification of a location of SP subsystem 200 (e.g., identification of a particular geographical region (e.g., region 91 and/or 92) in which SP subsystem 200 may be located or operative to handle any transaction credential data for the transaction), (ii) specific transaction information, such as identification of a specific currency to be used to pay for the transaction (e.g., yen, pounds, dollars, etc.) and/or identification of a specific amount of a currency to be paid for the transaction and/or identification of the particular product or service to be purchased or rented or otherwise paid for and/or identification of a default or initial shipping address to be used, (iii) information indicative of the one or more types of payment methods acceptable to the SP for the transaction (e.g., a list of payment cards that may be used for the purchase (e.g., China UnionPay but not MasterCard)), and/or (iv) a unique SP-based transaction identifier (e.g., any suitable data element, such as a 3- or 4-character alphanumeric string, that may be randomly or uniquely generated by SP subsystem 200 for association with the transaction being conducted). Such potential transaction data 660 may include any suitable number and types of data fields, with or without associated data, that may be required or at least used for completing a financial transaction, such as contact information fields (e.g., telephone number, e-mail address, mailing address) of a customer making the purchase, where some fields may be populated and included as part of such potential transaction data 660, and/or where some fields may not be populated as part of such potential transaction data 660 but may be open and awaiting population during process 600. Such potential transaction data 660 of operation 610 may be referred to herein as a PKPaymentRequest. Alternatively, as mentioned, a user may not be actively interacting with client device 100′ in order for potential transaction data 660 associated with SP subsystem 200 to be made available to client device 100′ at operation 610.

Potential transaction data 660 may define an SP resource's request for client device 100′ to produce a payment token for the purchase of products and/or services and may encapsulate any suitable information about the potential transaction including, for example, information about the SP's payment processing capabilities, an amount to pay, and the currency code. Potential transaction data 660 may also include a list of one or more payment networks (e.g., payment network(s) 361/362) that may be supported by the SP such that client device 100′ may be configured to determine whether any of such listed one or more payment networks has an authorized payment credential on client device 100′ or on any suitable host device available to client device 100′. In some embodiments, once such potential transaction data 660 may be accessed by client device 100′, as shown in FIG. 3A, for example, a GUI of client device 100′ may provide screen 190a, where an SP's resource may use transaction data 660 to show to a user of client device 100′ any suitable information associated with the potential transaction, such as the name of the SP or merchant (e.g., “Merchant A”) with information 307a, the name of the product (e.g., “Product B”) with information 307b, the price (e.g., “Price C”) with information 307c, and/or initial shipping data (e.g., “Address D”) with information 307d. Potential transaction data 660 that may be provided to client device 100′ by SP subsystem 200 may be indicative of such information 307a, 307b, 307c, and/or 307d. A user of client device 100′ may interact with device 100′ and screen 190a to adjust certain portions of such information (e.g., shipping address, etc.), which may require updated potential transaction data to be generated and shared by SP subsystem 200 (e.g., at another iteration of operation 610). As also shown in FIG. 3A and described below in more detail, screen 190a may also include a secure pay prompt 309. At least a portion of potential transaction data 660 may be provided from SP subsystem 200 to client device 100′ via communication path 15 of FIG. 1B and may be received by communications component 106′ of client device 100′. Communications component 106′ may pass this potential transaction data 660 on to processor 102′ (e.g., for displaying on screen 190a as part of a user interface on client device 100′ (e.g., for information 307a-307d)) and/or to NFC component 120′. For example, NFC component 120′ may utilize such potential transaction data 660 for securely enabling a financial transaction between client device 100′ and SP subsystem 200. In some embodiments, potential transaction data 660 may be referred to as SP payment request data and/or SP transaction request data and/or a uniform resource locator (“URL”) or any other suitable reference character string and/or query string.

At operation 612 of process 600, client device 100′ may attempt to identify at least one non-native payment source (e.g., of at least one host device) for potentially funding a financial transaction, such as the transaction associated with potential transaction data 660 of operation 610, by sending any suitable host availability request data 662 (e.g., a discovery request) to any suitable remote source, and, then, at operation 614 of process 600, in response to any sent host availability request data 662, client device 100′ may receive any suitable host availability response data 664 (e.g., any suitable discovery response) from any suitable source. Any suitable technique may be used to identify any available non-native payment sources. For example, a beacon signal may be transmitted by client device 100′ as host availability request data 662 that may request a response from any host device that might receive the beacon (e.g., any host device within a particular distance of client device 100′ that may be operative to communicate using a particular communication protocol of the beacon or a beacon may be a quick response (“QR”) code or any other suitable code that may be presented by client device 100′ and read by a scanner of one or more host devices). Client device 100′ may send host availability request data 662 to one or more particular host devices using any suitable communication path and protocol (e.g., to one or more devices identified in a contacts application of device 100′ and/or identified manually by a user of device 100′ (e.g., by telephone number or e-mail address or any suitable unique device identifier (e.g., device identifier 119 of host device 100))).

Such host availability request data 662 may include any suitable information, such as information identifying client device 100′ (e.g., device identifier 119′ of client device 100′) and/or information identifying one or more particular payment types that may be acceptable (e.g., by the SP) for funding the potential financial transaction (e.g., the payment type(s) that may be identified by potential transaction data 660 of operation 610), and may request any suitable host availability response data 664 in response, such as any suitable information that may identify the responding host device (e.g., device identifier 119 of host device 100) and/or any suitable information identifying one or more particular payment types that may be available to that host device (e.g., AID 155a a and/or AID 155b a of host device 100, where such payment type identification of host availability response data 664 may only include each type that matches a type in the discovery request of host availability request data 662 or may include all payment types available to that responding host) and/or any suitable information identifying a location of the responding host device and/or any suitable information identifying a status of the host device (e.g., awake, asleep, off, etc.). Host availability response data 664 shared by a host device may be the bare minimum amount of data required for host discovery, such as by using protocol buffers. AE subsystem 400 or any other entity may participate in the identification of host device 100 by client device 100′ at operation 612 and/or operation 614. For example, as mentioned, IDS subsystem 471 of AE subsystem 400 may be operative to manage any suitable services made available to client device 100′ and/or host device 100, such as iCloud™ and/or iMessage™ or any other suitable identity services transport, which may be operative to make associations between different devices and/or to automatically determine the status and/or capabilities of various devices (e.g., a family may have an account with AE subsystem 400 that may be associated with client device 100′ as well as multiple other devices, including host device 100). As one example, client device 100′ may send host availability request data 662 to IDS subsystem 471 of AE subsystem 400 for requesting the status of all other devices associated with an account of client device 100′, and IDS subsystem 471 of AE subsystem 400 may respond by obtaining the status of one, some, or each one of such devices and sharing each one of those statuses with client device 100′ as host availability response data 664, where a status may be indicative of the availability of host device 100 and the identity of at least one payment type available to host device 100. Each host device may have its own settings with respect to such requests and potential responses (e.g., a particular host device may be configured to only respond to host availability request data 662 received from particular client devices (e.g., only devices associated with the same account at AE subsystem 400, only devices associated with contacts in a contact application of that particular host device, etc.)). Such requests and/or responses for enabling the identification of one or more available payment sources at operations 612 and 614 may be communicated in any suitable manner, such as directly between client device 100′ and host device 100, or between client device 100′ and IDS subsystem 471 of AE subsystem 400 and then between IDS subsystem 471 of AE subsystem 400 and host device 100. For example, as shown in FIG. 1B, host availability request data 662 may be communicated from client device 100′ to host device 100 (e.g., via communications path 99 using any suitable communications protocol or via IDS subsystem 471 of AE subsystem 400 (e.g., via communications path 95 and communications path 65 using any suitable communications protocol(s))), and host availability response data 664 may be communicated to client device 100′ from host device 100 (e.g., via communications path 99 using any suitable communications protocol or via IDS subsystem 471 of AE subsystem 400 (e.g., via communications path 65 and communications path 95 using any suitable communications protocol(s))) or from IDS subsystem 471 of AE subsystem 400 (e.g., via communications path 95 using any suitable communications protocol).

Host availability request data 662 may be sent automatically by client device 100′ in response to receiving potential transaction data 660 or periodically independent of the receipt of such transaction data 660 or in response to a request made by a user of client device 100′ at any suitable time, such as in response to a user of client device 100′ interacting with the GUI of screen 190a of FIG. 3A. For example, in response to a user selection of secure pay prompt 309 of screen 190a of client device 100′ in order to make a purchase from the SP according to the details of potential transaction data 660, client device 100′ may generate and transmit host availability request data 662. Moreover, as shown in FIG. 3B, client device 100′ may be configured to provide screen 190b in response to receiving selection of secure pay prompt 309 of screen 190a of FIG. 3A and in response to receiving any suitable host availability response data 664, which may prompt a user to interact with client device 100′ in one or more ways to choose a specific payment source or credential that may be available to client device 100′ for making the purchase. For example, as shown, screen 190b may include a payment source selection prompt 311 that may enable a user to select one of potentially multiple payment sources that may be available to client device 100′. Payment source selection prompt 311 may only include payment sources with credentials that are associated with payment networks supported by the SP (e.g., as may be determined by potential transaction data 660, as mentioned above) or may show all payment sources available to client device 100′ (e.g., all sources associated with all AIDs received as host availability response data 664) yet may make only those that are associated with acceptable payment networks able to be selectable by a user. Payment source selection prompt 311 may include any suitable payment sources, including, but not limited to, any suitable payment credentials native to a secure element of client device 100′ (not shown), any suitable non-native payment credentials of any available payment sources (e.g., payment method X of host device 1 as may be indicated by payment option identifier 311a of prompt 311 (e.g., the first host credential of SSD 154a of host device 100 provisioned from first issuing subsystem 391), payment method Y of host device 1 as may be indicated by payment option identifier 311b of prompt 311 (e.g., the second host credential of SSD 154b of host device 100 provisioned from second issuing subsystem 392), etc.) as may be identified by any received host availability response data 664, and/or any suitable other payment source that may be identified by client device 100′ (e.g., payment option identifier 311c of prompt 311 that may enable a user of client device 100′ to manually enter or select any suitable remote host device for requesting payment (e.g., by entering any suitable unique host device identifier, such as a telephone number or e-mail address of a host device, which may be used by client device 100′ to communicate with that remote host, or by selecting a host device that may be identified in a contacts application of client device 100′ or that may be identified as a last selected host device or otherwise)). In some embodiments, payment source selection prompt 311 may be operative to enable a user of client device 100′ to select a particular payment type of a particular payment source (e.g., payment method (PM) X (e.g., “a MasterCard credential from Wells Fargo with an account number ending in 0096”) of host device 1 of identifier 311a (e.g., the first host credential of SSD 154a of host device 100 provisioned from first issuing subsystem 391) or payment method (PM) Y (e.g., “a China UnionPay credential from the People's Bank of China with an account number ending in 2587”) of host device 1 of identifier 311b (e.g., the second host credential of SSD 154b of host device 100 provisioned from second issuing subsystem 392)) and/or payment source selection prompt 311 may be operative simply to enable a user of client device 100′ to select a particular payment source (e.g., host device 1 or host device 2) but not a particular payment type of that payment source (e.g., depending on the specificity of host availability response data 664 received by client device 100′ or depending on any other suitable data available to client device 100′). In some embodiments, host availability response data 664 may be based on cached payment availability data known by AE subsystem 400 and/or by client device 100′ for a particular host device 100 that may currently be non-responsive (e.g., a host device 100 that may be turned off and not responsive to the discovery request of operation 612 but may be known to include a suitable payment credential), where an identifier (not shown) of prompt 311 may include identification of that host device and its known payment credential as well as information alerting the user of client device 100′ that such a host device is currently turned off (e.g., “HD2 must be turned on to enable use of HD2's PM Z”).

Next, at operation 616 of process 600, client device 100′ may communicate transaction request data 666 (e.g., payment request data) to at least one particular host device 100. A target host device 100 of transaction request data 666 may be determined in any suitable manner by client device 100′, such as automatically or in response to a user selection with respect to payment source selection prompt 311 of FIG. 3B, and/or such a determination may be made based on any suitable information, such as potential transaction data 660 and/or host availability response data 664. For example, a user of client device 100′ may select the target host device 100 for transaction request data 666 of operation 616 from a list of potential target host devices of payment source selection prompt 311 of FIG. 3B that may be provided based on the identification of one or more payment sources using host availability response data 664 (e.g., “HD1's PM X” of identifier 311a and “HD1's PM Y” of identifier 311b), or client device 100′ may identify any suitable particular target host device in any suitable manner (e.g., a host device in a contacts application of client device 100′ and/or a host device identified manually by a user of device 100′ (e.g., by a telephone number or e-mail address or any suitable unique device identifier of the host device (e.g., using the option of identifier 311c of FIG. 3B))). As just one particular example, as shown in FIG. 3C, client device 100′ may be configured to provide screen 190c in response to receiving user selection of “HD1's PM Y” of identifier 311b of payment source selection prompt 311 of FIG. 3B (e.g., a China UnionPay credential from the People's Bank of China of geographical region 92 of FIG. 1 (e.g., the second host credential of SSD 154b of host device 100 provisioned from second issuing subsystem 392)). Screen 190c of FIG. 3C may prompt a user to interact with client device 100′ in one or more ways to request non-native host device payment for the selected payment source of payment source selection prompt 311 of FIG. 3B as indicated by payment method identifier 313 of FIG. 3C, such as by user selection of request host device (HD) payment prompt 315 of FIG. 3C. Alternatively, the target host device 100 for transaction request data 666 of operation 616 may be automatically selected by client device 100′ in response to any identification data obtained by client device 100′ at operation 614 (e.g., client device 100′ may be customized or otherwise configured to select one host device from a group of available host devices based on any suitable characteristic (e.g., the host device with the shortest distance to client device 100′ or the host device with the highest priority of the available host devices (e.g., as may be determined by a default or customized setting of an application of client device 100′ in combination with host availability response data 664 or otherwise), etc.). Therefore, transaction request data 666 of operation 616 may be automatically generated and transmitted by client device 100′ without any user interaction with client device 100′ (e.g., based on transaction data 660 and/or any host availability response data 664 and/or any application parameters (e.g., of any application running on client device 100′)). Such transaction request data 666 of operation 616 may be communicated in any suitable manner at operation 616, as shown in FIG. 1B, such as directly between client device 100′ and host device 100 (e.g., via communications path 99 using any suitable communications protocol), or between client device 100′ and IDS subsystem 471 of AE subsystem 400 (e.g., via communications path 95 using any suitable communications protocol) and then between IDS subsystem 471 of AE subsystem 400 and host device 100 (e.g., via communications path 65 using any suitable communications protocol). Client device 100′ may be operative to maintain a local cache (e.g., on memory local to client device 100′) of the various payment types available to the various host devices associated with client device 100′(e.g., based on data that may be routinely collected by AE subsystem 400 and shared with client device 100′ at any suitable times), such that a specific dedicated discovery request and response cycle may not be necessary when a payment request is to be made. When one or more available payment types from native credentials (e.g., on client device 100′) and/or non-native credentials (e.g., on one of more host devices 100) are determined by client device 100′, automatic selection of a particular payment source and/or prioritization amongst various payment sources for selection by a user of client device 100′ may be enabled. For example, client device 100′ may be operative to automatically select or prioritize one of at least one available payment sources to be targeted and identified in a payment request based on the distance between client device 100′ and the host device that may include the selected payment source (e.g., the host device with an available payment source that is closest to the client device (e.g., as may be determined from distance data in a discovery response or via other suitable communication related data (e.g., detected communicated signal strength BlueTooth, etc.)) may be automatically selected to facilitate ease of use to the user of the client device). Client device 100′ may be operative to automatically select or prioritize one of at least one available payment sources to be targeted and identified in a payment request based on the payment sources supported by the SP (e.g., a corporate-branded payment credential may be prioritized for use in a transaction with that corporation (e.g., a Disney-branded Visa card may be prioritized or selected for use in a transaction with a Disney SP, where such a preference may be expressed by the SP and made available to client device 100′)).

Transaction request data 666 may include any suitable information that may be provided by client device 100′ to the target host device 100 for identifying one or more particular characteristics of the potential transaction to be financed. For example, like potential transaction data 660 of operation 610, transaction request data 666 of operation 616 may include any suitable data related to the potential financial transaction to be funded, including, but not limited to, (i) specific SP information, such as a unique SP identifier (e.g., SP ID 219) of the SP (i.e., “Merchant A”) and/or identification of the particular SP resource being used (e.g., the particular SP application 113′), (ii) specific transaction information, such as identification of a specific currency to be used to pay for the transaction (e.g., yen, pounds, dollars, etc.) and/or identification of a specific amount of a currency to be paid for the transaction (i.e., “Price C”) and/or identification of the particular product or service to be purchased or rented or otherwise paid for (i.e., “Product B”) and/or identification of a default or initial shipping address to be used (i.e., “Shipping D”), (iii) information indicative of the one or more types of payment methods acceptable to the SP for the transaction (e.g., a list of payment cards that may be used for the purchase (e.g., China UnionPay but not MasterCard)) or selected by client device 100′ (i.e., “HD1's PM Y”), (iv) a unique SP-based transaction identifier (e.g., any suitable data element, such as a 3- or 4-character alphanumeric string, that may be randomly or uniquely generated by SP subsystem 200 for association with the transaction being conducted), (v) a unique client-based transaction identifier (e.g., any suitable data element, such as a 3- or 4-character alphanumeric string, that may be randomly or uniquely generated by client device 100′ for association with the transaction being conducted), and/or (vi) a unique client-based payment request identifier (e.g., any suitable data element, such as a 3- or 4-character alphanumeric string, that may be randomly or uniquely generated by client device 100′ for association with the payment request being made by transaction request data 666). In some embodiments, transaction request data 666 may be encrypted or otherwise formatted or handled by AE subsystem 400 before communication to the target host device 100 (e.g., by IDS subsystem 471 using any suitable IDS formatting procedure (e.g., for end to end encryption of the communication)). Such transaction request data 666 may be referred to herein as a PKRemotePaymentRequest and may include any suitable data, including, but not limited to, (1) the PKPaymentRequest and/or any other data of potential transaction data 660 of operation 610 (e.g., which may be wrapped inside the PKRemotePaymentRequest), (2) any suitable data identifying the selected target host device (e.g., host device identifier 119 of host device 100, as may be included in host availability response data 664 of operation 614), which may be referred to herein as PKRemoteDevice, (3) any suitable data identifying a selected or default particular payment credential of the target host device (e.g., AID 155b a of secure element 145 of host device 100, as may be included in host availability response data 664 of operation 614 and/or as may be automatically or user-selected at client device 100′), which may be referred to herein as a SelectedApplicationIdentifier, and/or (4) any suitable data identifying a unique identifier to be associated with the payment request (e.g., a unique value that can be used to identify the payment request across the client and host devices of the system and that may be generated by client device 100 or otherwise), which may be referred to herein as a RemotePaymentIdentifier. Such transaction request data 666 may be communicated in any suitable manner at operation 616, such as directly (e.g., peer to peer) between client device 100′ and host device 100 (e.g., via communications path 99 using any suitable communications protocol), or between client device 100′ and IDS subsystem 471 of AE subsystem 400 (e.g., via communications path 95 using any suitable communications protocol) and between IDS subsystem 471 of AE subsystem 400 and host device 100 (e.g., via communications path 65 using any suitable communications protocol) (e.g., using identity services transport or any other suitable communication services of IDS subsystem 471 of AE subsystem 400). One, some, or all portions of potential transaction data 660 and/or transaction request data 666 may be carried through client device 100′ and/or host device 100 and/or AE subsystem 400 from transaction request data 666 to host transaction data 678 and/or to secured host transaction data 683 and/or to secured host transaction data 684 and/or to client transaction data 690, such that certain identifiers of the potential transaction may be identified by one, some, or each of the entities during process 600.

In response to receiving transaction request data 666 from client device 100′ at operation 616, a target host device 100 may be operative to provide any suitable information to a user of host device 100 for acting on the payment request. For example, as shown in FIG. 3D, a push notification screen 190d may be provided by a GUI of host device 100 that may be operative to indicate to a user of host device 100 that a client payment request has been received with an identifier 317 and may include an option 321 that may be selectable to hide the notification and/or an option 319 that may be selectable to view more details about the notification. For example, in response to user selection of view more details option 319 or in lieu of screen 190d, the GUI of host device 100 may proceed to a screen 190e of FIG. 3E that may enable a user of host device 100 to respond to the client payment request in one or more suitable ways. Screen 190e of FIG. 3E may prompt a user of host device 100 to interact with host device 100 in one or more ways to choose a specific credential native to host device 100, or non-native to device 100 but accessible to device 100 through a process similar to process 600, for making the purchase. As shown in FIG. 3E, in addition to identifiers 307a-307d that may identify to a user of host device 100 the same merchant, product, price, and shipping information for the potential transaction as identified to the user of client device 100′ on screen 190c of FIG. 3C prior to and/or at operation 616, screen 190e may include a credential selection prompt 323 that may enable a user to select one of potentially multiple credentials that may be provisioned on host device 100 (e.g., the credential of credential SSD 154b) for use in funding the potential transaction. Prompt 323 may only include credentials native to host device 100 that are associated with payment networks supported by the SP (e.g., as may be determined by transaction request data 666, as mentioned above). As shown, prompt 323 may include a first native payment credential option 325 associated with “Credential X” of host device 100 and a second native payment credential option 327 associated with “Credential Y” of host device 100, each of which may be acceptable for use by SP subsystem 200 of the potential transaction (e.g., based on any suitable portion of transaction request data 666), and/or where any suitable technique may be used to identify the credential selected by client device 100′ if applicable (e.g., an “*” may be provided next to second native payment credential option 327 associated with “Credential Y” if that “PM Y” may have been selected by client device 100′ (e.g., at screen 190b of FIG. 3B) and specifically identified in transaction request data 666). As shown in FIG. 3F, the GUI of host device 100 may be configured to provide screen 190f in response to receiving host device user selection of a particular credential from credential selection prompt 323 of screen 190e of FIG. 3E (e.g., “Credential Y”). Screen 190f of FIG. 3F may identify that selected or automatically identified default credential with credential identifier information 329 and may prompt a user of host device 100 to interact with host device 100 in one or more ways to authenticate the user and its intent to utilize the selected credential. This may include prompting the user (e.g., with an authentication prompt 331) to enter user authentication via personal identification number (“PIN”) entry or via user interaction with a biometric sensor in order to access the secure element of host device 100 and, thus, the credential to be used for the purchase.

Different instances of transaction request data 666 may be sent to different target host devices at operation 616 (e.g., to a group of available host devices (e.g., from a child's client device to its father's host device and to its mother's host device) in order to increase the chances of a quick response). If an asleep host device is a target host device, then transaction request data 666 for that host device may be queued up for sharing with that target host device when it comes online (e.g., by AE subsystem 400 or by client device 100′ itself), where such queuing may only be enabled for a certain period of time (e.g., 2 hours after generation of such transaction request data 666, after which such payment request data may be deemed expired and may not be provided to its target host device). As mentioned, prompt 311 may include a notice to client device 100′ that a particular host device is not online or a notification may be provided indicating that a particular host device is not responding to payment request data and may generate a request for a user of the client device to take steps or conduct operations to enable that host device. AE subsystem 400 may be operative to manage settings that may be operative to block certain discovery requests and/or certain payment requests from certain client devices from going to certain host devices, or a certain host device may be operative to set any suitable options to block such requests from certain client devices.

If a user of host device 100 is willing and able to select or confirm a particular payment credential for use in funding the potential transaction in response to transaction request data 666 received at operation 616, process 600 may proceed to operation 625, at which device 100 may receive intent and authentication by a user of host device 100 to utilize a specific credential for carrying out the potential transaction for a particular merchant, product, price, and shipping destination based on potential transaction data 666 (e.g., through user selection of authentication prompt 331 of FIG. 3F). Access SSD 154c may leverage applet 153c of host device 100 to determine whether such authentication has occurred before allowing other SSDs 154 (e.g., credential SSD 154b) to be used for enabling its credential information in a commerce credential data communication. As just one example of operation 625, applet 153c of access SSD 154c may be configured to determine intent and local authentication of a user of host device 100 (e.g., via one or more input components 110, such as a biometric input component 110i of FIG. 3, as may be used by a user interacting with any application of device 100 (e.g., card management application 113b of host device 100)) and, in response to such a determination, may be configured to enable another particular SSD for conducting a payment transaction (e.g., with the second host transaction credential of second credential SSD 154b). In some embodiments, after such a determination, but before such enablement, a GUI of host device 100 may be configured to provide another screen (e.g., similar to screen 190g of FIG. 3G) that may prompt a user of host device 100 (e.g., with a prompt similar to prompt 333 of FIG. 3G) to interact with host device 100 in one or more ways to finally initiate payment using the selected and authenticated credential.

A user of host device 100 may provide intent and authentication at operation 625 for use of a particular payment credential native to host device 100 for funding a potential transaction identified by transaction request data 666 of operation 616 (e.g., for “Merchant A” and “Product B” and “Price C” and “Shipping D” of screens 190c and 190e), whereby operation 625 may occur immediately after operation 616. Any suitable underlying communication protocol between devices (e.g., an identity services transport layer of IDS subsystem 471 between client device 100′ and host device 100) may be operative to provide completion handlers that may be operative to ensure that each device knows when the other device has received and processed request data and/or response data (e.g., similarly to “read receipts” of iMessage™ or other suitable media messaging protocols). For example, a payment continuity service may be provided (e.g., by IDMS component 470 of IDS subsystem 471 of AE subsystem 400 or otherwise) for enabling the secure communication of payment requests and payment responses between client and host devices, where each of the client device and the host device may be capable of using the messaging transport of that service (e.g., the IDS transport, such as with IDS application 113d of host device 100). Any suitable mechanisms for communicating such data may be employed, such as Handoff™ by Apple Inc. (e.g., seamless sharing of application data between devices) or AirDrop™ by Apple Inc. (e.g., a secure ad hoc transfer protocol) or Continuity™ SMS/MMS by Apple Inc. or the like. Moreover, either device may be operative to cancel a request (e.g., client device 100′ may cancel a transmitted request after operation 612 and/or host device 100 may cancel a received request after operation 612), which may be operative to update the presentation of data on each device (e.g., update screens 190c and 190e). A common RemotePaymentIdentifier of all request/responses for a particular transaction may be used by each device to confirm that each device is communicating with respect to the same particular transaction. For example, the most recently received payment request with a particular RemotePaymentIdentifier may be used by a host device over any previously received payment request with that same particular RemotePaymentIdentifier.

Next, once intent and authentication has been received at operation 625 for a particular host transaction credential in response to receiving particular payment request data (e.g., transaction request data 666 at operation 616), operations 626-628 of process 600 may include host device 100 generating, encrypting, and transmitting host transaction data 678 for use by AE subsystem 400 (e.g., second security subsystem 492). Once the particular host transaction credential of credential SSD 154b on secure element 145 of host device 100 has been selected, authenticated, and/or enabled for use in a transaction (e.g., at operation 625), secure element 145 of host device 100 (e.g., processor module 142 of NFC component 120) may generate and encrypt certain credential data of that selected host transaction credential for use by AE subsystem 400. For example, host transaction credential data 675 of credential SSD 154b (e.g., payment card data of SSD 154b, as may be associated with selected “Credential Y” (e.g., a China UnionPay credential from the People's Bank of China of geographical region 92 of FIG. 1 provisioned from second issuing subsystem 392)), such as token data and crypto data, may be generated and/or at least partially encrypted with credential key 155b′ at operation 626 as host transaction credential data 676 to include at least token data and crypto data, such that such encrypted host transaction credential data 676 may only be decrypted by an entity with access to that credential key 155b′ (e.g., second issuing subsystem 392 of issuer subsystem 300) for accessing host transaction credential data 675. Such host transaction credential data 675 may include any suitable data that may be operative to securely prove proper ownership of the particular secure element credential of host device 100 (e.g., the credential of SSD 154b) and necessary to make a payment with that credential, including, but not limited to, (i) token data (e.g., an actual FPAN or virtual DPAN, PAN expiry date, a card security code (e.g., a card verification code (“CVV”)), and/or name and/or address associated with the credential of credential information 161b of SSD 154b) and (ii) crypto data (e.g., a cryptogram that may be generated by secure element 145 using a shared secret of SSD 154b and issuer subsystem 300 (e.g., key 155b′ of second issuer subsystem 392) and any other suitable information (e.g., some or all of the token data, information identifying host device 100, information identifying some or all of potential transaction data 660 of operation 610 and/or of transaction request data 666 of operation 616, such as cost and/or currency, any suitable counter values, nonce, etc.) that may be available to host device 100 and that may also be made available to issuer subsystem 300 (e.g., at operation 642 or otherwise) for independently generating the crypto data using the shared secret). In some embodiments, once some or all of that host transaction credential data 675 of credential SSD 154b has been encrypted with credential key 155b′ at operation 626 as encrypted host transaction credential data 676, that encrypted host transaction credential data 676 or host transaction credential data 675, either alone or along with at least a first portion if not all of the applicable transaction request data 666 (e.g., a portion or all of potential transaction data 660 that may include identification of the SP, identification of the price amount, identification of the currency and/or shipping and/or product, and/or unique SP-based transaction identifier and/or unique client-based transaction identifier and/or unique client-based payment request and/or the like) and/or any other suitable information (e.g., any information identifying host device 100 itself (e.g., host device identifier 119), any specific host device-based transaction identifier, and/or the like), may be encrypted by access information (e.g., by access key 155b of SSD 154b, access key 155c of access SSD 154c, ISD key 156k, and/or CRS 151k and/or signed by CASD 158k) at operation 627 as encrypted host transaction credential data 677. For example, secure element 145 of host device 100 (e.g., processor module 142 of NFC component 120) may use access information to encrypt not only an identification of the merchant from data 660/666 (e.g., identification of the SP or its resource being used for the purchase, such as application 113′), but also the identification of the amount of the purchase and/or currency code from data 660/666, as well as the encrypted host transaction credential data 675 of SSD 154b (e.g., encrypted host transaction credential data 676) into encrypted host transaction credential data 677. In some embodiments, host transaction credential data 675 of credential SSD 154b (e.g., payment card data of SSD 154b, such as token data and crypto data may be generated but not encrypted with a credential key (e.g., at operation 626 as data 676) before being encrypted with an administration entity key or access key (e.g., at operation 627 as data 677), and, instead, such host payment transaction data 675 may be encrypted with an administration entity key or access key (e.g., at operation 627 as data 677), whereby in such embodiments, any future reference to data 676 may also be in reference to data 675 that is not encrypted with any credential key. In some embodiments, such an administration entity key or access key may be an administration entity public key associated with a scheme of AE subsystem 400 and of which AE subsystem 400 may have access to an associated administration entity private key. AE subsystem 400 may provide such an administration entity public key to issuer subsystem 300 and issuer subsystem 300 may then share that administration entity public key with host device 100 (e.g., when provisioning credential data on host device 100 (e.g., at operation 652/654 of process 600)).

Next, encrypted host transaction credential data 677 along with any additional information, such as at least some of transaction request data 666 (e.g., identification of the SP, identification of the price amount, identification of the currency, a unique SP-based transaction identifier, identification of the product/service, and/or the like) and/or any other suitable information (e.g., any information identifying host device 100 itself, a unique host device-based transaction identifier, and/or the like) may together be transmitted as host transaction data 678 from host device 100 to AE subsystem 400 at operation 628. Therefore, at least portions of host transaction data 678 (e.g., encrypted host transaction credential data 677) may only be decrypted by an entity with access to that access information used for the encryption (e.g., access key 155b, access key 155c, ISD key 156k, CRS 151k, and/or CASD 158k) that generated encrypted host transaction credential data 677 of host transaction data 678 (e.g., AE subsystem 400). Such host transaction data 678 may be generated at operations 626-628 and then transmitted to AE subsystem 400 (e.g., to second security subsystem 492) at operation 628 (e.g., from secure element 145, via communications component 106 and communication path 65). Operations 626, 627, and 628 may ensure that any host transaction credential data generated and transmitted from secure element 145 of host device 100 as part of host transaction data 678 has first been encrypted in such a way that it cannot be decrypted by another portion of host device 100 (e.g., by processor 102). That is, host transaction credential data 675 of host transaction data 678 may be encrypted as encrypted host transaction credential data 676 with a credential key 155b′ that may not be exposed to or accessible by any portion of host device 100 outside of its secure element. Moreover, such encrypted host transaction credential data 676 of host transaction data 678 may be encrypted as encrypted host transaction credential data 677 with an access key (e.g., access key 155b, 155c, 156k, 151k, and/or 158k (e.g., referred to herein as “access information”)) that may not be exposed to or accessible by any portion of host device 100 outside of its secure element.

As mentioned, certain host transaction credentials may be governed by one or more geographic restrictions that may be operative to restrict the types or location of subsystems that may be allowed to handle data from those restricted host transaction credentials. For example, as described with respect to FIG. 1, the second host transaction credential of credential SSD 154b (e.g., payment card data of SSD 154b of selected “Credential Y” (e.g., a China UnionPay credential from the People's Bank of China of geographical region 92 provisioned on host device 100 from second issuing subsystem 392 (e.g., alone or in combination with network subsystem 362) at operations 603/604)) may be a geographically restricted transaction credential that may be restricted from being handled by any server or component of AE subsystem 400 that is physically located in a different geographical region than the geographical region (e.g., second geographical region 92) in which the credential issuing subsystem of the geographically restricted transaction credential is located. Therefore, the host transaction credential data of host transaction data 678 as generated by that restricted host transaction credential should not be handled by either IDS subsystem 471 or first security subsystem 491 of AE subsystem 400 but may be handled by second security subsystem 492 of AE subsystem 400. Any suitable target identification data may be accessible to host device 100 in order for device 100 to be enabled to determine that second security subsystem 492 is an appropriate target security subsystem of AE subsystem 400 for receiving and handling restricted host transaction data 678 at operation 628 in accordance with the geographic restriction. Such target identification data may include, but is not limited to, a URL or other data that may be an address of the target subsystem, such as a URL from or otherwise associated with the selected credential SSD 154b (or applet 153b) of host device 100 that is generating the restricted host transaction credential data (e.g., a URL that may be defined by the subsystem(s) that provisioned the SSD credential on device 100 (e.g., as a portion of data 653 and/or data 654) and/or a URL stored in a pass available to processor 102 of host device 100 associated with the credential and/or a URL stored at device 100 through any other mechanism (e.g., due to a firmware or any other software update on device 100 (e.g., from AE subsystem 400))) and/or as a URL that may be derived from a portion of token data of host transaction credential data 675 (e.g., such token data may include a PAN of credential information 161b or AID of SSD 154b, whereby at least a portion of such a PAN or AID may be operative to identify to device 100 (e.g., in combination with any other suitable data available to device 100 (e.g., data in a look up table or other up-to-date regulatory information (e.g., that may be regularly downloaded to device 100′) with respect to geographic restrictions on certain PAN or AID types)) the URL of the appropriate target security subsystem of AE subsystem 400 (e.g., an appropriate security subsystem of AE subsystem 400 associated with that PAN/AID (e.g., a certain subset of alphanumeric characters of a PAN/AID may be associated with a particular security subsystem that may be identifiable by device 100 (e.g., using a look-up table))). Moreover, in addition to identifying an appropriate target security subsystem of AE subsystem 400 for receiving and handling restricted host transaction data 678 at operation 628, device 100 may be operative to generate and include within host transaction data 678 an instruction that may be operative to instruct that identified target security subsystem not only to generate SP-secured host transaction credential data based on encrypted host transaction credential data 676/677 of host transaction data 678 (e.g., to generate SP credential data 681 at operation 631) but also to generate or otherwise access a unique host transaction voucher in conjunction with generating the SP-secured host transaction credential data and then store such a unique host transaction voucher against the SP-secured host transaction credential data (e.g., to store voucher data 682 indicative of a voucher against SP credential data 681 at operation 632). This instruction may be any suitable data that may be configured to be appropriately processed by the target security subsystem of AE subsystem, and device 100 may be operative to determine the need for such an instruction using any suitable data that may or may not be the same as any of the target identification data. In some embodiments, the URL of the target security subsystem identified by device 100 from the target identification data may be specifically tied to an appropriate voucher storing process of the target security subsystem (e.g., the URL used by device 100 to target the communication of host transaction data 678 to second security subsystem 492 at operation 628 may be a specific URL at which any received host transaction data may be processed by second security subsystem 492 for storing voucher data against SP credential data (e.g., secured host credential data of the received host transaction data) rather than just returning such SP credential data to host device 100, whereas another URL of second security subsystem 492 may be operative to not store a voucher for received host transaction data). In some embodiments, any suitable data portion of request data 666 may be indicative of the use of IDS subsystem 471 for communication of data between host device 100 and client device 100′ and may be used as voucher-indication data by host device 100 in order to configure host device 100 to generate host transaction data 678 that may be operative to request a voucher rather than SP-secured host transaction credential data, so that the geographic restriction(s) of the host transaction credential may not be violated by future communication between host device 100 and client device 100′ during process 600 (e.g., at operation 634). In some embodiments, AE subsystem 400 (e.g., security subsystem 492) may be operative to process any suitable host transaction data 678 to determine whether or not a voucher (e.g., voucher data 682) or secured host transaction credential data (e.g., SP credential data 681) ought to be returned to host device 100 or otherwise provided to another entity of subsystem 1.

Next, at operation 630 of process 600, once host transaction data 678 has been sent to the appropriate target second security subsystem 492 for storing a voucher in accordance with the restriction of the selected and utilized host transaction credential, second security subsystem 492 may be operative to receive and decrypt at least a portion of host transaction data 678. For example, second security subsystem 492 may receive host transaction data 678 and may then decrypt encrypted host transaction credential data 677 of host transaction data 678 using access information (e.g., 155b, 155c, 156k, 151k, and/or 158k) as may be available at second security subsystem 492. This may enable second security subsystem 492 to determine an unencrypted identification of the SP (e.g., from decrypted host transaction credential data 677), while also maintaining host transaction credential data 675 in an encrypted state (e.g., as encrypted host transaction credential data 676), because second security subsystem 492 may not have access to credential key 155b′ with which such host transaction credential data 675 may have been encrypted by secure element 145 of host device 100 at operation 626 as encrypted host transaction credential data 676. The SP may be identified by the additional data (e.g., data 666) that may have been included in host transaction data 678 along with encrypted host transaction credential data 677. Host transaction data 678 may include information (e.g., host device identifier 119) identifying host device 100 or at least its secure element, such that, when host transaction data 678 is received by second security subsystem 492, second security subsystem 492 may know which access information (e.g., which of access information 155b, 155c, 156k, 151k, and/or 158k) to use at operation 630. For example, second security subsystem 492 may have access to multiple access keys 155b/155c and/or multiple ISD keys 156k, each one of which may be particular to a specific host device 100 or to a specific secure element.

Next, at operation 631, second security subsystem 492 may be operative to identify an SP key (e.g., SP key 157′) associated with the SP that may have been identified by transaction request data 666 and, thus, by host transaction data 678, and then re-encrypting at least a portion of host transaction data 678 using that SP key. That is, after decrypting at least a portion of host transaction data 678 using suitable access information at operation 630 (e.g., after decrypting encrypted host transaction credential data 677 to realize encrypted host transaction credential data 676 and any other information that may have been encrypted in encrypted host transaction credential data 677 (e.g., data 666)), second security subsystem 492 may then, at operation 631, re-encrypt at least a portion of host transaction data 678 (e.g., the token data and/or the crypto data of encrypted host transaction credential data 676) with an appropriate SP key that may be associated with SP information identified in host transaction data 678. For example, such an SP key (e.g., SP key 157′) may be determined by comparing administration entity SP information identified in host transaction data 678 (e.g., SP ID 219) with data in table 430 of second security subsystem 492 (e.g., SP key 157′ may be stored against SP ID 219 in table 430 (e.g., at operation 606)). With this determined appropriate SP key, second security subsystem 492 may re-encrypt with that SP key (e.g., SP key 157′) at least a portion of host transaction data 678 (e.g., encrypted host transaction credential data 676 (e.g., inclusive of the token data and/or the crypto data of host transaction credential data 675)) as encrypted SP credential data 681 (e.g., SP-secured host transaction credential data). For example, encrypted SP credential data 681 may include at least encrypted host transaction credential data 676 from host transaction data 678 as well as any suitable transaction data, such as the purchase amount data or other suitable transaction data from or based on host transaction data 678 and/or transaction request data 666 (e.g., data that may have been initially identified by potential transaction data 660). In some embodiments, prior to such encryption of operation 631, AE subsystem 400 may be operative to confirm the validity of and/or trust that AE subsystem 400 has in the SP subsystem identified for use in determining SP key 157′. The SP identification information from host transaction data 678 may not need to be included in encrypted SP credential data 681 as that SP identification may have already been used to determine the SP key with which encrypted SP credential data 681 may be encrypted at operation 631. Encrypted SP credential data 681 may be signed by AE subsystem 400 in such a way that, when received by SP subsystem 200, may establish AE subsystem 400 as the creator of such encrypted SP credential data 681 and/or may enable SP subsystem 200 to ensure that such encrypted SP credential data 681 has not been modified after being signed. Such encrypted SP credential data 681 may be generated at operation 631 and then transmitted along with any other suitable data as secured host transaction credential data from AE subsystem 400 to host device 100 or to client device 100′ or to SP subsystem 200 for furthering (e.g., financing) the transaction, for example, if no redeemable voucher ought to be used for satisfying any geographic restriction(s) of the host transaction credential.

However, if a voucher ought to be used, encrypted SP credential data 681 generated at operation 631 may then be stored against such a voucher by AE subsystem 400 at operation 632. In such embodiments, at operation 632, second security subsystem 492 may be configured to generate or otherwise access voucher data 682 that may be indicative of a unique host transaction voucher and then to store such a voucher against encrypted SP credential data 681 (e.g., by linking the voucher of voucher data 682 and SP credential data 681 with any suitable data link) in any suitable memory component of second security subsystem 492, such as in a table 435 or any other suitable data structure. Such a unique host transaction voucher may be any suitable data element of any suitable size, such as an 8- or 9-character alphanumeric string that may be randomly or uniquely generated by AE subsystem 400 or otherwise for association with encrypted SP credential data 681, such that the voucher may not include any data indicative of the host transaction credential data of encrypted SP credential data 681. Such voucher data 682 used at operation 632 may then be transmitted along with any other suitable data, such as a URL of second security subsystem 492 or other data indicative of the entity at which to redeem the voucher, as secured host transaction data 683 from AE subsystem 400 to host device 100 at operation 633. Then, at least voucher data 682 of secured host transaction data 683 along with any other suitable data (e.g., any suitable data of data 666 or otherwise available to host device 100 that may be indicative of the transaction) may be communicated from host device 100 to client device 100′ as secured host transaction data 684 at operation 634, where such data 684 may be communicated from host device 100 to client device 100′ through IDS subsystem 471 without violating any restriction(s) of the restricted host transaction credential data, as neither voucher data 682 nor any other portion of secured host transaction data 684 may include any host transaction credential data of credential SSD 154b, such that IDS subsystem 471 may handle secured host transaction data 684. In some embodiments, any additional data, such as redeemer data may be stored against encrypted SP credential data 681 along with the voucher at operation 632. For example, certain redeemer data may be any suitable identifier of client device 100′ associated with the transaction being processed (e.g., any suitable client device ID (e.g., client device ID 119′ and/or a token associated with a client user account at AE subsystem 400 (e.g., an iCloud™ account token), which may be common to both a user of host device 100 and a user of client device 100′) that may be passed (e.g., from data 662 and/or data 666) on to AE subsystem 400 at operation 628), such that client device 100′ may be operative to provide that client device identifier redeemer data along with the voucher in order to redeem the voucher for encrypted SP credential data 681 (e.g., at operation 637, AE subsystem 400 may only provide encrypted SP credential data 681 to client device 100′ if client device 100′ provided the voucher along with that client device identifier redeemer data to AE subsystem 400 and AE subsystem 400 determines that the voucher and that client device identifier redeemer data are both stored against or otherwise associated with each other and encrypted SP credential data 681). As another example, certain redeemer data may be any suitable identifier of SP subsystem 200 of the transaction being processed (e.g., an SP certificate of SP subsystem 200 (e.g., from operation 606) or any suitable SP ID (e.g., SP ID 219) that may be passed (e.g., from data 660) on to AE subsystem 400 at operation 628), such that SP subsystem 200 (or an associated acquiring bank 399) may be operative to provide that SP identifier redeemer data along with the voucher in order to redeem the voucher for encrypted SP credential data 681 (e.g., at operation 637, AE subsystem 400 may only provide encrypted SP credential data 681 to SP subsystem 200 or acquiring bank 399 if that entity provided the voucher along with that SP identifier redeemer data to AE subsystem 400 and AE subsystem 400 determines that the voucher and that SP identifier redeemer data are both stored against or otherwise associated with each other and encrypted SP credential data 681).

Secured host transaction data 683 including voucher data 682 may be forwarded on to client device 100′ by host device 100 at operation 634 as secured host transaction data 684 (e.g., via communications path 99 and/or via IDS subsystem 471 of AE subsystem 400 using any suitable protocol(s)). Then, at operation 636, client device 100′ may be operative to detect voucher data 682 of host transaction data 684 and then to attempt to redeem the voucher of voucher data 682 at second security subsystem 492 for host transaction credential data that may fund or otherwise further the transaction, such as encrypted SP credential data 681, by communicating host transaction data voucher redemption request data 686 that may include voucher data 682 to second security subsystem 492 (e.g., an entity identified by redemption entity identification data of data 683/684). Client device 100′ may be operative to detect voucher data 682 and/or the identity of target second security subsystem 492 and/or the manner in which to redeem voucher data 682 using any suitable data that may be communicated to client device 100′ from host device 100 as part of host transaction data 683 (e.g., data 683 may include an appropriate URL for second security subsystem 492 (e.g., as may be determined and used by host device 100 at operation 628)). Host transaction data voucher redemption request data 686 may include voucher data 682 and any data indicative of client device 100′ (e.g., client device ID 119′) such that second security subsystem 492 may communicate the host transaction credential data redeemed by the voucher back to client device 100′.

At operation 637, second security subsystem 492 may redeem the voucher for host transaction credential data by receiving host transaction data voucher redemption request data 686 from client device 100′, identifying the voucher defined by voucher data 682 of host transaction data voucher redemption request data 686, and identifying any host transaction credential data stored against that voucher (e.g., encrypted SP credential data 681 as stored against the voucher at operation 632). Then, at operation 638, second security subsystem 492 may communicate the host transaction credential data identified at operation 637 (e.g., encrypted SP credential data 681) to client device 100′ as at least a portion of redeemed host transaction data 688 for completing redemption of the voucher. One or more of the voucher and the host transaction credential data stored against the voucher (e.g., encrypted SP credential data 681) may then be deleted from second security subsystem 492 once the voucher has been redeemed for the host transaction credential data, such that AE subsystem 400 may not store host transaction credential data after it has been redeemed (e.g., such that the host transaction credential data is transient on subsystem 400), and/or such that a voucher may be configured as a one-time redeemable voucher.

In some embodiments, one or more limits or redemption criteria may be applied to the redemption of the voucher, where such criteria may be defined by AE subsystem 400 and/or host device 100 (e.g., in data 678 provided to AE subsystem 400) and/or issuer subsystem 30 (e.g., in data 653/654 at the time of provisioning the host transaction credential (e.g., as a portion of any restriction on that host transaction credential)) and may be used to provide an additional layer of security to a transaction, for example, by defining one or more limits or requirements that must be satisfied in order for the voucher to be redeemed for host transaction credential data at operation 637. For example, as mentioned, such redemption criteria may include client device identifier redeemer data, where an identifier of client device 100′ may be stored against or otherwise associated with the link created at operation 632 between the voucher of voucher data 682 and encrypted SP credential data 681, such that second security subsystem 492 may be operative to require that host transaction data voucher redemption request data 686 include such a client device identifier in order to redeem the voucher for encrypted SP credential data 681 (e.g., to validate that client device 100′ is an intended/approved recipient of encrypted SP credential data 681). As another example, as mentioned, such redemption criteria may include SP identifier redeemer data, where an identifier of SP subsystem 200 may be stored against or otherwise associated with the link created at operation 632 between the voucher of voucher data 682 and encrypted SP credential data 681, such that second security subsystem 492 may be operative to require that host transaction data voucher redemption request data 686 include such an SP identifier (e.g., if voucher redemption request data 686 is communicated to AE subsystem 400 by SP subsystem 200 or an associated acquiring subsystem 399 instead of by client device 100′) in order to redeem the voucher for encrypted SP credential data 681 (e.g., to validate that SP subsystem 200 and/or its associated acquiring subsystem 399 is an intended/approved recipient of encrypted SP credential data 681). Additionally or alternatively, such redemption criteria may include temporal redemption criteria, where the stored link between the voucher and the host transaction credential data may be valid for only a limited duration of time before the link may be deleted and the voucher may not be redeemable (e.g., the time at which host transaction data voucher redemption request data 686 is received by second security subsystem 492 at operation 637 must be no more than 5 minutes or any other suitable temporal criterial time limit after the time at which the voucher was initially stored against the host transaction credential data at operation 632 in order for the host transaction credential data initially stored against the voucher to be identified by and communicated from second security subsystem 492 at operation 638). Such temporal redemption criteria may prevent AE subsystem 400 from enabling a transaction to be funded that was initiated more than a particular duration of time in the past or that was initiated with the intent of only being funded with respect to a particular time (e.g., temporal redemption criteria may be operative to define a time frame during which or before which or after which a transaction is valid and able to be funded).

As another example, redemption criteria may include SP identification redemption criteria information, such as an indication of the particular SP associated with the transaction (e.g., any suitable SP ID 219), whereby AE subsystem 400 may identify a first SP identifier provided by host device 100 from data 678 and store such a first SP identifier against the voucher and host transaction credential data at operation 632, whereby AE subsystem 400 may identify a second SP identifier provided by client device 100′ from data 686 at operation 636 along with the voucher, and AE subsystem 400 may only release the host transaction credential data to client device 100′ at operation 638 if the first SP identifier stored against the voucher matches the second SP identifier received at operation 636 (e.g., in order to confirm that the SP hasn't changed during the transaction process). As yet another example, redemption criteria may include amount-based redemption criteria, such as an indication of a particular amount or a maximum amount of a particular currency that may be defined and associated with a transaction prior to the voucher being stored against the host transaction credential data at operation 631, whereby AE subsystem 400 may identify a first amount identifier provided by host device 100 from data 678 and store such a first amount identifier against the voucher and host transaction credential data at operation 632, whereby AE subsystem 400 may identify a second amount identifier provided by client device 100′ from data 686 at operation 636 along with the voucher, and AE subsystem 400 may only release the host transaction credential data to client device 100′ at operation 638 if the first amount identifier stored against the voucher matches or is within a pre-defined threshold amount of the second amount identifier received at operation 636 (e.g., in order to prevent AE subsystem 400 from enabling a transaction to be funded for an amount that differs from the amount(s) satisfying the limitation(s) initially associated with the transaction). As yet another example, redemption criteria may include credential restriction redemption criteria, whereby AE subsystem 400 may identify a geographic region restriction for handling of the geographically restricted host transaction credential data of encrypted SP credential data 681 (e.g., from data 678 or as may be otherwise determined by host device 100 and/or AE subsystem 400 and AE subsystem 400 may store data indicative of the credential restriction redemption criteria (e.g., data indicative of “only to be redeemed by entity located in second geographical region 92”), whereby AE subsystem 400 may identify a location or other requesting device situation information of a redemption requesting entity (e.g., the location of the entity communicating voucher redemption request data 686 to AE subsystem 400 may be included in or otherwise detectable from data 686 (e.g., an IP address of the requesting entity)) at operation 636 along with the voucher, and AE subsystem 400 may only release the host transaction credential data to the requesting entity at operation 638 if the restriction redemption criteria stored against the voucher is satisfied by the identified location or other requesting device situation information of the redemption requesting entity (e.g., to prevent redemption of a voucher for release of encrypted SP credential data 681 to an entity that would violate a restriction of the host transaction credential data of encrypted SP credential data 681). Additionally or alternatively, second security subsystem 492 may include a particular voucher redemption URL with voucher data 682 in data 683, where that URL may only address a portion (e.g., server) of second security subsystem 492 that may be associated with redeeming vouchers for host transaction credential data geographically restricted for use within second geographical region 92, and that portion (e.g., server) of second security subsystem 492 may be configured not to receive any voucher redemption request data 686 from any requesting entity located outside of second geographical region 92 (e.g., second security subsystem 492 may use a firewall or other suitable technology to only receive voucher redemption request data 686 for geographically restricted host credential data that is transmitted from within second geographical region 92 (e.g., to restrict allowed traffic only from entities that are suitable for redeeming a voucher for geographically restricted host credential data)). As yet another example, redemption criteria may include device-situation redemption criteria, whereby AE subsystem 400 may identify a first location identifier indicative of the location of host device 100 as may be provided by host device 100 in data 678 and store such a first location identifier against the voucher and host transaction credential data at operation 632, whereby AE subsystem 400 may identify a second location identifier indicative of the location of client device 100′ as may be provided by client device 100′ in data 686 at operation 636 along with the voucher, and AE subsystem 400 may only release the host transaction credential data to client device 100′ at operation 638 if the first location identifier stored against the voucher matches or is within a pre-defined threshold distance of the second location identifier received at operation 636 (e.g., in order to prevent AE subsystem 400 from enabling a transaction to be funded using devices that are not within an appropriate distance range of one another, whereby AE subsystem 400 may be operative to process such device-situation redemption criteria in order to enable an associated transaction to be funded only if the environmental information of that device-situation redemption criteria being processed meets any suitable risk analysis (e.g., common fraud indicators) available to AE subsystem 400 (e.g., administration account information associated with one or more of the devices of the transaction that may be accessible to AE subsystem 400 (e.g., address information associated with an account owner) may be analyzed in combination with such device-situation redemption criteria information to determine if any risk exists that may warrant the funding of the transaction to be denied or flagged for further review (e.g., if the address of the owner of device 100 is determined by AE subsystem 400 to be in New York but the location of device 100 identified by device-situation redemption criteria is in China, the transaction may be flagged for further risk analysis prior to enabling the transaction to be funded)). Other suitable device-situation redemption criteria information may include geo-location of one or each device (e.g., country location or more specific location such as state or city or street), internet protocol (“IP”) address of one or each device, and/or the like.

The present disclosure recognizes that the use of such personal information data, in the present technology, such as current location of a user device 100, can be used to the benefit of users. For example, the personal information data can be used to provide better security and risk assessment for a financial transaction being conducted. Accordingly, use of such personal information data enables calculated security of a financial transaction. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure.

The present disclosure further contemplates that the entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and/or privacy practices. In particular, such entities should implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining personal information data private and secure. For example, personal information from users should be collected for legitimate and reasonable uses of the entity and not shared or sold outside of those legitimate uses. Further, such collection should occur only after receiving the informed consent of the users. Additionally, such entities would take any needed steps or conduct certain operations for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices.

Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of financial transaction services, the present technology can be configured to allow users to select to “opt in” or “opt out” of participation in the collection of personal information data during registration for such services. In another example, users can select not to provide location information for financial transaction services. In yet another example, users can select to not provide precise location information, but permit the transfer of location zone information.

Therefore, although the present disclosure broadly covers use of personal information data to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such personal information data. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such personal information data. For example, financial transaction services can be provided by inferring preferences or situations based on non-personal information data or a bare minimum amount of personal information, such as the financial transaction being conducted by the device associated with a user, other non-personal information available to the financial transaction services, or publicly available information.

Therefore, use of redemption criteria information may be operative to enable AE subsystem 400 to provide a validation check after receiving host transaction data 678 at operation 628 and after receiving redemption request data 686 at operation 636 but before redeeming a voucher for communicating host transaction credential data as redeemed host transaction data 688 to client device 100′ at operation 638. AE subsystem 400 may be operative to process any suitable redemption criteria information in combination with any other suitable information accessible by AE subsystem 400 in order to determine whether a transaction ought to be enabled for funding. Such redemption criteria information may be generated by any suitable entity associated with the transaction and may be communicated to AE subsystem 400 in any suitable communication, including communications not shown by FIG. 6. Therefore, if AE subsystem 400 determines that a particular transaction is no longer viable or does not meet any suitable redemption criteria, AE subsystem 400 may prevent the transaction from being funded by not redeeming a voucher and may update or delete any data associated with the transaction (e.g., AE subsystem 400 may delete the voucher or any host transaction credential data stored against the voucher at AE subsystem 400 and/or edit at least a portion of any redemption criteria information associated with the transaction). However, if, at operations 637 and 638, AE subsystem 400 is able to enable a transaction for funding, AE subsystem 400 may be satisfied that the transaction is between known devices and/or a known SP and/or meets any suitable requirements of any suitable redemption criteria.

At operation 640, after receiving redeemed host transaction data 688 from AE subsystem 400 at operation 638, client device 100′ may forward on at least the host transaction credential data of redeemed host transaction data 688 (e.g., encrypted SP credential data 681) to SP subsystem 200 as client transaction data 690 (e.g., via communications path 15 or as a contactless proximity-based communication 5). In some embodiments, between operation 634 and operation 640, a GUI of client device 100′ may be configured to provide another screen 190g of FIG. 3G that may prompt a user of client device 100′ with a prompt 333 to interact with client device 100′ in one or more ways to review and reject and/or finally initiate payment using the selected and authenticated host transaction credential from host device 100 (e.g., as encrypted host transaction credential data 676 encrypted within encrypted SP credential data 681 of redeemed host transaction data 688). Alternatively, operations 636-638 may occur transparently to a user of client device 100′. Alternatively, redeemed host transaction data 688 with SP credential data 681 may be communicated to SP subsystem 200 from AE subsystem 400 without being communicated via client device 100′. Operations 631 and 638 may be operative to ensure that credential data transmitted from the AE subsystem 400 as part of redeemed host transaction data 688 (e.g., token data and/or crypto data of encrypted SP credential data 681) may be encrypted in such a way that it cannot be decrypted by a portion of client device 100′. That is, credential data of redeemed host transaction data 688 (e.g., token data and/or crypto data of encrypted merchant credential data 681) may be encrypted with an SP key (e.g., SP key 157′) that may not be exposed to or otherwise accessible by any portion of client device 100′. Moreover, credential data of redeemed host transaction data 688 (e.g., token data and/or crypto data of encrypted SP credential data 681) may be encrypted with a credential key 155b′ that may not be exposed to or otherwise accessible by any portion of client device 100′.

In other embodiments, host device 100 may communicate secured host transaction data 684 directly to SP subsystem 200 at operation 634 rather than via client device 100′, or AE subsystem 400 may communicate secured host transaction data 683 directly to client device 100′ at operation 633 rather than via host device 100 (e.g., using any suitable client device target address information that may be provided by data 666 or otherwise at operation 630), or AE subsystem 400 may communicate secured host transaction data 683 directly to SP subsystem 200 at operation 621 rather than via host device 100 and/or via client device 100′ (e.g., using any suitable SP target address information that may be determined from SP ID 219 used at operation 631), where the voucher of such communicated secured host transaction data 683/684 may be redeemed by the receiver of data 683/684. Rather than a voucher being stored against SP credential data 681 for later redemption, in other embodiments, it is to be appreciated that such a voucher may be stored by second security subsystem 492 against host transaction data 678 after receiving data 678 but before operation 630, where redemption of that voucher (e.g., at operation 637) may include second security subsystem 492 then identifying and processing data 678 at operations 630 and 631 for revealing encrypted SP credential data 681 to be returned as redemption for the voucher, and/or that such a voucher may be stored by second security subsystem 492 against data 666, 675, and/or 676 after operation 630 but before operation 631, where redemption of that voucher (e.g., at operation 637) may include second security subsystem 492 then identifying and processing data 666, 675, and/or 676 at operation 631 for revealing encrypted SP credential data 681 to be returned as redemption for the voucher.

In some embodiments, HSM component 490 may be configured as a tamper proof component of AE subsystem 400 (e.g., of second security subsystem 492) that may be operative to physically destroy itself if tampered with so data thereon may be protected. HSM component 490 of second security subsystem 492 may be operative to include storage for table 430 with any SP keys linked to any SP IDs, storage for table 435 with any vouchers linked to any host transaction credential data, as well storage for any suitable access keys that may be linked to any suitable device IDs, such that each one of operations 630, 631, 632, and 637 may be performed by HSM component 490. This may prevent any other portions of second security subsystem 492 and/or of AE subsystem 400 entirely from being operative to access data 675 and/or data 666 (e.g., because the access key for revealing such data from data 677 of data 678 may only be available at AE subsystem 400 within HSM component 490 and/or because the SP key for revealing such data from data 681 may only be available at AE subsystem 400 within HSM component 490). As the voucher may be redeemed for SP credential data 681, which may include host transaction credential data that has been uniquely encrypted to an SP key of a particular SP, the voucher may be redeemed by an entity other than an entity with that SP key without risking the security of the host transaction credential data. Therefore, HSM component 490 may be configured to release SP credential data 681 to an entity that presents the voucher to HSM component 490 while the link between that voucher and SP credential data 681 is still viable (e.g., not expired due to temporal redemption criteria).

Once SP credential data 681 including host transaction credential data 675/676 is received by SP subsystem 200 (e.g., as client transaction data 690 at operation 640), process 600 may also include operation 642 at which SP subsystem 200 may be configured to generate and transmit SP transaction data 692 to issuer subsystem 300 (e.g., via acquiring bank subsystem 399 (e.g., via communication path 25 between SP subsystem 200 and acquiring bank subsystem 399 of FIG. 1B and communication path 35 between acquiring bank 399 and issuer subsystem 300) or directly to second issuer subsystem 392 of issuer subsystem 300), where data 692 may include payment information and an authorization request that may be indicative of the secured host payment credential data of host device 100 (e.g., host transaction credential data 675/676 of data 681) and the SP's purchase price for the product or service (e.g., as may be included in or otherwise associated with client transaction data 690 or as may be otherwise associated with the transaction as known by SP subsystem 200 (e.g., by potential transaction data 660 (e.g., based on a unique transaction identifier))). For example, at operation 642, SP subsystem 200 may leverage its known SP key 157′ to at least partially decrypt SP credential data 681 of client transaction data 690 such that SP transaction data 692 may include the secured host payment credential data of credential SSD 154b encrypted with its credential key 155b′ (e.g., encrypted payment credential data 676) but not with a key that is not available to issuer subsystem 300 (e.g., SP key 157′).

Next, at operation 644, when second issuer subsystem 392 of issuer subsystem 300 receives an authorization request (e.g., directly from acquiring bank subsystem 399 or SP subsystem 300 as data 692 at operation 642, or indirectly via an associated payment network subsystem 362 as data 405), the payment information (e.g., host payment credential data 675 of host device 100 as encrypted by credential key 155b′ by secure element 145 of host device 100 (e.g., encrypted host payment credential data 676)) and the purchase amount, each of which may be included in the authorization request data, may be decrypted (e.g., using credential key 155b′ at issuer subsystem 300) and analyzed to determine if the account associated with the host transaction credential has enough credit or otherwise to cover the purchase amount. If sufficient funds are not present, second issuer subsystem 392 may decline the requested transaction by transmitting a negative authorization response to acquiring bank subsystem 399/SP subsystem 200. However, if sufficient funds are present, second issuer subsystem 392 may approve the requested transaction by transmitting a positive authorization response to acquiring bank subsystem 399/SP subsystem 200 and the financial transaction may be completed. Either type of authorization response may be provided by second issuer subsystem 392 to acquiring bank subsystem 399/SP subsystem 200 as authorization response transaction status data 694 at operation 644 of process 600 (e.g., directly from second issuer subsystem 392 to acquiring bank subsystem 399/SP subsystem 200, or from payment network subsystem 362 to acquiring bank subsystem 399/SP subsystem 200 based on authorization response data 415 that may be provided to payment network subsystem 362 from second issuer subsystem 392 via communication path 42). Next, in response to receiving authorization response transaction status data 694 at operation 644, process 600 may also include SP subsystem 200 or any other suitable subsystem sharing such authorization response transaction status data with client device 100′ (e.g., using the SP resource or otherwise) as confirmed transaction status data 696 at operation 646 and/or with host device 100 as confirmed transaction status data 698 at operation 648. Such confirmed transaction status data may be configured to provide any suitable confirmation data to device 100 and/or 100′, such as confirmation data 335 of screen 190h of FIG. 3H. If the transaction is successful, the confirmed transaction status data may be operative to close the transaction (e.g., the transaction identified by the unique RemotePaymentIdentifier of the payment request data) at client device 100′ at operation 646 and/or at host device 100 at operation 648. If the transaction is not successful, the confirmed transaction status data may or may not be operative to close the transaction (e.g., close the transaction if no valid funds available or device identified as fraudulent, but keep open and allow updates if a non-valid shipping address is determined). Any non-transaction-terminating transaction status data may allow the payment process to continue until the process is cancelled by an application, the process is cancelled by a user, or the process is completed.

Therefore, SP subsystem 200 may be configured to process client transaction data 690 or any other carrier of SP credential data 681 in any suitable way. For example, to obtain host transaction credential data from SP credential data 681, SP subsystem 200 may verify that a signature property of the received SP credential data 681 is valid and that AE subsystem 400 is the signer of that signature. SP subsystem 200 may use any suitable technique to determine which SP key (e.g., which merchant public key 157′) may have been used by AE subsystem 400 to construct SP credential data 681. Then, SP subsystem 200 may retrieve the corresponding SP private key (e.g., SP private key 157′ at SP subsystem 200) and use that retrieved key to de-encapsulate and/or decrypt encrypted SP credential data 681 to recover encrypted host transaction credential data 676. Then such data 676 may be provided to the appropriate payment network/issuing subsystem, which may leverage the appropriate credential key 155b′ of issuer subsystem 300 to de-encapsulate and/or decrypt encrypted host transaction credential data 676 to recover host transaction credential data 675 (e.g., to recover the token data and/or the crypto data of host transaction credential data 675 for validating host transaction credential data 675 (e.g., to independently generate the crypto data based on the token data of received host transaction credential data 675, compare that generated crypto data to the crypto data of the received host transaction credential data 675, and either validate or reject the transaction based on the comparison)).

It is understood that the operations shown in process 600 of FIG. 6 are only illustrative and that existing operations may be modified or omitted, additional operations may be added, and the order of certain operations may be altered. Further, in some implementations, two or more operations may occur in parallel or in a different sequence than described. In some embodiments, a potential transaction (e.g., as identified by potential transaction data 660) may be at least partially funded by two different payment credentials. Although not shown, voucher data 682 may be communicated from AE subsystem 400 directly to client device 100′ (e.g., via communications path 95 and not via host device 100) or from AE subsystem 400 directly to SP subsystem 200 (e.g., via communications path 85 and not via host device 100 and/or not via client device 100′) or from AE subsystem 400 directly to issuer subsystem 300 or its acquiring bank (e.g., via communications path 55 and not via host device 100 and/or not via client device 100′ and/or not via SP subsystem 200) for redemption by any of those receiving subsystems. Although not shown, voucher data 682 may be communicated from host device 100 directly to SP subsystem 200 (e.g., not via client device 100′) for redemption by SP subsystem 200 or from host device 100 directly to issuer subsystem 300 for redemption by issuer subsystem 300 (e.g., via communications path 75 and not via client device 100′ and/or not via SP subsystem 200). It is to be understood that when no geographic restriction is detected for the host transaction credential being used, or if IDS subsystem 471 is not to be used to handle data communicated from host device 100 to client device 100′, then operations 632 and 636-638 may be skipped, whereby secured host transaction data 683 and 684 may include SP credential data 681 rather than voucher data 682, such that client device 100′ does not need to use a voucher to redeem such SP credential data 681 but may receive such SP credential data 681 directly from host device 100. As mentioned, client device 100′ may be configured to determine that a particular product or service ought to be purchased and to interact with one or more SPs in order to obtain associated potential transaction data from at least one particular SP for that particular product or service (e.g., client device 100′ may be a home appliance that may be configured to determine that an appliance product must be purchased (e.g., detect that more laundry detergent is needed by a washing machine or detect a calendar event pre-set by a user to buy more detergent on a particular date) and may automatically identify a particular SP offering the best deal for that product and may automatically interact with that SP to obtain potential transaction data for purchasing that product from that SP), all automatically and without any active interaction by a user of client device 100′. After which, client device 100′ may be operative to automatically generate and push a payment request (e.g., transaction request data 666) to one or more particular target host devices. For example, such a client device 100′ may be an automated device that may be paired to one or more host devices 100 in an ecosystem (e.g., using a home automation platform, such as HomeKit™ by Apple Inc.) and such a payment request may be at least partially pre-populated or otherwise populated according to any suitable pre-defined settings (e.g., request payment for new laundry detergent from host device X and request payment for new drier sheets from host device Y, or request payment for any purchase over SG from host device X and under $G from host device Y, etc.).

One, some, or each data communication between host device 100 and client device 100′ of process 600 (e.g., communication of one, some, or each of data 662, 664, 666, 684, and/or 698) may be made over any suitable communications path(s) using any suitable communications protocol(s), such as directly in a peer-to-peer arrangement or via IDS subsystem 471 of AE subsystem 400 or any other suitable entity, using any suitable transport mechanism that may be encrypted in any suitable fashion or not at all. Such data communication may occur via any suitable online messaging, instant messaging, e-mail messaging, text message, any suitable proximity-based messaging, NFC, BlueTooth™, and/or the like and may be enabled using any suitable device addressing schemes, such as telephone numbers, e-mail addresses, unique device identifiers, location-based beacons, and the like. Each host device and each client device may be any suitable device with any suitable UI and I/O capabilities for a user, such as a laptop, smartphone, home appliance, SP accessory device (e.g., a device provided at a gas pump by a gasoline merchant), user accessory (e.g., wearable device, such as a smart watch), and the like. By allowing any host device with a native payment credential to receive and respond to a payment request (e.g., over the public internet or in any other suitable fashion) from any other suitable device (e.g., a client device with or without its own native payment credentials) that may or may not itself have a native payment credential, system 1 and process 600 may enable many secure and effective use cases and user experiences, even while respecting any suitable geographic restrictions of the native payment credential.

For example, a user is shopping online using an online SP resource of SP subsystem 200 (e.g., application 113′) on client device 100′ (e.g., a laptop computer that may not have a secure element or any native payment credentials) and interacts with the online resource to identify a particular product to purchase (e.g., “Product B”). In response to identification of that product (e.g., in response to the user selecting a “Buy with Secure Credential Payment” (e.g., Apple Pay™ by Apple Inc.), the online resource may be operative to present a payment sheet or any suitable UI on client device 100′ that may enable the user to enter a particular shipping address or other variable data (e.g., as shown by screen 190a and as may be updated by the user of client device 100′ through one or more additional iterations of requesting and obtaining updated potential transaction data of operation 610 that may update other information (e.g., in response to the user of client device 100′ changing a shipping address of information 307d, the price of information 307c may be updated)). At some point, the user of client device 100′ may select a “Secure Pay” option 309 of screen 190a, which may result in a discovery process (e.g., operations 662 and 664) that may automatically identify (e.g., without any further interaction by the user of client device 100′) that client device 100′ has no native payment credentials suitable for funding the purchase of the payment sheet of screen 190a (e.g., based on acceptable payment options indicated by potential transaction data 660) and that “HD1's PM Y” (i.e., Payment Method Y of Host Device 1) is the only available or preferred non-native payment credential suitable for use (e.g., preference may be automatically determined based on the proximity of each available host device to the client device or any other suitable characteristics that may be accessible to client device 100′ via the discovery process). After such identification, client device 100′ may be operative to automatically present screen 190c of FIG. 3C to the user of client device 100′ for enabling the user to select option 315 of FIG. 3C for sending an appropriate payment request to that host device or process 600 may automatically make that selection on the user's behalf (e.g., by automatically sending appropriate transaction request data 666 to the available target host device 1 (i.e., host device 100) in response to identification of the discover process), which may result in screen 190d of FIG. 3D or screen 190e of FIG. 3E automatically being presented by that host device 100 (e.g., presenting a pay sheet on host device 100 that may be similar to the pay sheet presented on client device 100′). Host device 100 may be a mobile telephone or any other device that may include a secure element with at least one native payment credential suitable for funding the transaction initiated by client device 100′. The user of client device 100′ may be proximate to not only client device 100′ but also to host device 100 and may be able to interact with a GUI of one of screens 190d-190f of host device 100 for authorizing the use of a particular payment credential native to host device 100 for funding the transaction initiated or otherwise being conducted by client device 100′ and SP subsystem 200 (e.g., by selecting authenticate option 331 of screen 190f of FIG. 3F). In response to such authentication on host device 100, host payment credential data for a credential native to host device 100 may be provided to issuer subsystem 300 for attempting to fund the transaction (e.g., at operations 625-642 of process 600) and a confirmation status of the transaction may then be shared with the user at client device 100′ and/or at host device 100 (e.g., by screen 190h of FIG. 3H). In an alternative embodiment, multiple host devices may be identified as available and a payment request may be sent from client device 100′ to each one of the available host devices and the first host device to respond with host payment credential data may fund the transaction or each host device may respond with host payment credential data that may fund a particular portion of the transaction.

As another example, a user's home appliance client device 100′ (e.g., a washing machine) that may be communicatively coupled to a communication network using a home automation platform (e.g., HomeKit™ by Apple Inc.) may be operative to determine that it is almost out of a resource needed to operate properly (e.g., washing machine client device 100′ may be operative to determine automatically that its reserve of laundry detergent is at 20% capacity). In response to such a determination, home appliance client device 100′ may be operative to automatically identify an opportunity to purchase more of that resource (e.g., home appliance client device 100′ may be operative to interact with one or more SP subsystems via one or more online resources to identify the needed laundry detergent for sale at the best price or other suitable metric). Potential transaction data 660 for that purchase opportunity may thereby be obtained by client device 100′ and client device 100′ may be operative to automatically discover at least one host device that may be available to fund that transaction (e.g., via a discovery process of operations 662/664) and may automatically share appropriate transaction request data 666 with each of the at least one discovered host devices, such as a host device of at least one user associated with the home automation platform ecosystem containing home appliance client device 100′. Host device 100 may receive such payment request data and may present a user of host device 100 with the ability to select and authenticate a payment credential native to that host device for use in funding the transaction identified by home appliance client device 100′ (e.g., as identified without any active user interaction at client device 100′). This may enable a user and a host device 100 at any suitable location with respect to home appliance client device 100′ to receive a request a unique payment request from home appliance client device 100′ and to provide home appliance client device 100′ with host transaction data for a payment credential native to the host device for use in funding the transaction associated with the unique payment request (e.g., host device 100 and its user may be positioned on the other side of the country or world from home appliance client device 100′ yet may still be operative to receive a payment request from home appliance client device 100′ and respond with host payment credential data (e.g., via any suitable internet communications path(s) or any other suitable communication path(s), such as via a service of IDS subsystem 471 of AE subsystem 400)). Alternatively, rather than communicating over large distances via the internet, home appliance client device 100′ may present a QR code on a display of client device 100′ that may be scanned by a sensor of a proximate host device 100 and processed to identify particular payment request data or client device 100′ and host device 100 may communicate via BlueTooth™ or any other suitable local communication protocol.

In some embodiments, at least a portion of process 600 and/or any other process of this disclosure may be operative to transfer money between a user of host device 100 and a user of client device 100′ (e.g., client device 100′ may request funds from host device 100 independent of any transaction between client device 100′ and an SP subsystem). In some embodiments, this may be enabled by an acquiring bank and/or one or more entities of issuer subsystem 300 to enable host transaction data to facilitate the transfer of funds between an account associated with a credential on a host device and an account associated with a user of a client device, without the need for any SP subsystem. Alternatively, a stored value card on a host device and/or a stored value card on a client device may be leveraged to transfer funds between a host and a client (e.g., to transfer funds from a stored value credential native to a host device (e.g., a credential on secure element 145 of host device 100) to a stored value credential native to a client device (e.g., a credential on a secure element of client device 100′)). For example, client device 100′ may communicate a payment request to host device 100 that may be operative to request that host device 100 deduct an amount of currency from a stored value credential on host device 100 and send any appropriate APDU commands to client device 100′ that may be operative to add the appropriate amount of currency to a stored value credential of client device 100′ (e.g., such that host transaction data shared with client device 100′ may include such APDU commands and/or may include actual crypto-currency).

When client device 100′ may be communicating with SP subsystem 200 via a native application on client device 100′ that may be specific to the SP, then SP application 113c may be provided by such an application. However, when client device 100′ may be communicating with SP subsystem 200 via an internet browser not specific to an SP but that may be pointed to a website managed by a merchant (e.g., on a server under the control of the SP), then SP application 113c may be a layout engine software component (e.g., WebKit) that may forward communications on to a website of the SP (e.g., via communications component 106). For example, such an application 113c of client device 100′ may be a conduit for any host transaction data to be provided to SP subsystem 200. Alternatively, such host transaction data may be communicated to SP subsystem 200 not via client device 100′ but instead directly from host device 100 (e.g., using a voucher as a proxy) or AE subsystem 400 (e.g., using an SP identifier (e.g., SP ID 219) or address provided by the SP in potential transaction data and the client device payment request data).

Further Description of FIGS. 1-6

One, some, or all of the processes described with respect to FIGS. 1-6 may each be implemented by software, but may also be implemented in hardware, firmware, or any combination of software, hardware, and firmware. Instructions for performing these processes may also be embodied as machine- or computer-readable code recorded on a machine- or computer-readable medium. In some embodiments, the computer-readable medium may be a non-transitory computer-readable medium. Examples of such a non-transitory computer-readable medium include but are not limited to a read-only memory, a random-access memory, a flash memory, a CD-ROM, a DVD, a magnetic tape, a removable memory card, and a data storage device (e.g., memory 104 and/or memory module 150 of FIG. 2). In other embodiments, the computer-readable medium may be a transitory computer-readable medium. In such embodiments, the transitory computer-readable medium can be distributed over network-coupled computer systems so that the computer-readable code is stored and executed in a distributed fashion. For example, such a transitory computer-readable medium may be communicated from one electronic device to another electronic device using any suitable communications protocol (e.g., the computer-readable medium may be communicated to electronic device 100 via communications component 106 (e.g., as at least a portion of an application 103 and/or as at least a portion of an application 113 and/or as at least a portion of an application 143)). Such a transitory computer-readable medium may embody computer-readable code, instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. A modulated data signal may be a signal that has one or more of its characteristics set or changed in such a mariner as to encode information in the signal.

It is to be understood that any, each, or at least one module or component or subsystem of system 1 may be provided as a software construct, 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, a program module may include one or more routines, programs, objects, components, and/or data structures that may perform one or more particular tasks or that may implement one or more particular abstract data types. It is also to be understood that the number, configuration, functionality, and interconnection of the modules and components and subsystems of system 1 are only illustrative, and that 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 certain modules, components, and/or subsystems may be altered.

At least a portion of one or more of the modules or components or subsystems of system 1 may be stored in or otherwise accessible to an entity of system 1 in any suitable manner (e.g., in memory 104 of device 100 (e.g., as at least a portion of an application 103 and/or as at least a portion of an application 113 and/or as at least a portion of an application 143)). For example, any or each module of NFC component 120 may be implemented using any suitable technologies (e.g., as one or more integrated circuit devices), and different modules may or may not be identical in structure, capabilities, and operation. Any or all of the modules or other components of system 1 may be mounted on an expansion card, mounted directly on a system motherboard, or integrated into a system chipset component (e.g., into a “north bridge” chip).

Any or each module or component of system 1 (e.g., any or each module of NFC component 120) may be a dedicated system implemented using one or more expansion cards adapted for various bus standards. For example, all of the modules may be mounted on different interconnected expansion cards or all of the modules may be mounted on one expansion card. With respect to NFC component 120, by way of example only, the modules of NFC component 120 may interface with a 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 that may include memory (e.g., RAM) dedicated to the utilization of the module. In other embodiments, NFC component 120 may be integrated into device 100. For example, a module 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 or each module or component of system 1 (e.g., any 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.

Further Applications of Described Concepts

While there have been described systems, methods, and computer-readable media for conducting a transaction using an electronic device with a geographically restricted non-native credential, it is to be understood that many changes may be made therein without departing from the spirit and scope of the subject matter described herein in any way. Insubstantial changes from the claimed subject matter as viewed by a person with ordinary skill in the art, 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 with ordinary skill in the art are defined to be within the scope of the defined elements.

Therefore, those skilled in the art will appreciate that the invention can be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation.

Claims

1. A method for conducting a transaction, the method comprising:

at an administration entity subsystem: receiving, from a host electronic device, host transaction data comprising: host transaction credential data generated by a host credential application on a secure element of the host electronic device; and transaction information comprising a service provider identifier indicative of a service provider subsystem; obtaining unique voucher data; storing the unique voucher data against administration host transaction credential data that comprises the host transaction credential data of the received host transaction data; and communicating the unique voucher data to at least one of the host electronic device, a client electronic device, or the service provider subsystem.

2. The method of claim 1, further comprising:

at the administration entity subsystem: after the receiving and before the storing, generating the administration host transaction credential data, wherein the generating comprises: identifying a service provider key that has been stored against the service provider identifier; and creating the administration host transaction credential data by encrypting the host transaction credential data using the identified service provider key.

3. The method of claim 2, wherein the communicating the unique voucher data comprises communicating the unique voucher data to the host electronic device.

4. The method of claim 1, further comprising:

at the administration entity subsystem: after the communicating the unique voucher data, receiving the unique voucher data from one of the client electronic device or the service provider subsystem; identifying, using the received unique voucher data, the administration host transaction credential data that has been stored against the received unique voucher data; and communicating, to at least one of the client electronic device and the service provider subsystem, service provider host transaction credential data that comprises the identified administration host transaction credential data.

5. The method of claim 4, wherein:

the communicating the unique voucher data comprises communicating the unique voucher data to the host electronic device;

the receiving the unique voucher data comprises receiving the unique voucher data from the client electronic device; and

the communicating the service provider host transaction credential data comprises communicating the service provider host transaction credential data to the client electronic device.

6. The method of claim 4, wherein the communicating the service provider host transaction credential data comprises communicating the service provider host transaction credential data to the client electronic device.

7. The method of claim 4, wherein the communicating the service provider host transaction credential data comprises communicating the service provider host transaction credential data to the service provider subsystem.

8. The method of claim 4, further comprising:

at the administration entity subsystem: after the identifying and before the communicating the service provider host transaction credential data, generating the service provider host transaction credential data, wherein the generating comprises: identifying a service provider key that has been stored against the service provider identifier; and creating the service provider host transaction credential data by encrypting the identified administration host transaction credential data using the identified service provider key.

9. The method of claim 8, wherein:

the communicating the unique voucher data comprises communicating the unique voucher data to the host electronic device;

the receiving the unique voucher data comprises receiving the unique voucher data from the client electronic device; and

the communicating the service provider host transaction credential data comprises communicating the service provider host transaction credential data to the client electronic device.

10. The method of claim 8, wherein the communicating the service provider host transaction credential data comprises communicating the service provider host transaction credential data to the client electronic device.

11. The method of claim 8, wherein the communicating the service provider host transaction credential data comprises communicating the service provider host transaction credential data to the service provider subsystem.

12. The method of claim 1, further comprising:

at the administration entity subsystem: after the communicating, receiving the unique voucher data from one of the client electronic device or the service provider subsystem; identifying, using the received unique voucher data, the administration host transaction credential data that has been stored against the received unique voucher data; determining a duration of time that has elapsed between the storing the unique voucher data and the receiving the unique voucher data from the client electronic device; determining that the duration of time satisfies temporal redemption criteria associated with the voucher; and when the determined duration of time satisfies the temporal redemption criteria associated with the voucher, communicating, to the one of the client electronic device or the service provider subsystem, service provider host transaction credential data that comprises the identified host transaction credential data.

13. The method of claim 1, wherein:

the host transaction data further comprises host credential information indicating whether a geographical restriction is associated with the host credential application; and

the method further comprises: at the administration entity subsystem: determining whether the host credential information of the received host transaction data indicates a geographical restriction of the host credential application; when the received host transaction data indicates a geographical restriction of the host credential application, carrying out the obtaining, the storing, and the communicating; and when the received host transaction data does not indicate a geographical restriction of the host credential application, carrying out the following: identifying a service provider key that has been stored against the service provider identifier; generating service provider host transaction credential data by encrypting the host transaction credential data using the identified service provider key; and sending the generated service provider host transaction credential data to one of the host electronic device, the client electronic device, or the service provider subsystem.

14. The method of claim 13, wherein the sending the generated service provider host transaction credential data comprises sending the generated service provider host transaction credential data to the host electronic device.

15. The method of claim 1, wherein the communicating the unique voucher data comprises communicating the unique voucher data to the host electronic device.

16. The method of claim 15, wherein the host electronic device is communicatively coupled to the client electronic device via the administration entity subsystem.

17. A non-transitory computer-readable storage medium storing at least one program, the at least one program comprising instructions, which when executed by an administration entity subsystem, cause the administration entity subsystem to:

receive, from a host electronic device, host transaction data comprising: host transaction credential data generated by a host credential application on a secure element of the host electronic device; and transaction information comprising a service provider identifier indicative of a service provider subsystem;

identify a service provider key that has been stored against the service provider identifier;

create administration host transaction credential data by encrypting the host transaction credential data using the identified service provider key;

obtain unique voucher data;

store the unique voucher data in association with the created administration host transaction credential data; and

communicate the unique voucher data to the host electronic device.

18. The non-transitory computer-readable storage medium of claim 17, wherein the instructions, when executed by the administration entity subsystem, further cause the administration entity subsystem to:

after the unique voucher data has been communicated, receive the unique voucher data from one of a client electronic device or a service provider subsystem;

identify, using the received unique voucher data, the administration host transaction credential data that has been stored in association with the received unique voucher data; and

communicate, to at least one of the client electronic device or the service provider subsystem, the identified administration host transaction credential data.

19. The non-transitory computer-readable storage medium of claim 18, wherein:

the unique voucher data is received from the client electronic device; and

the identified administration host transaction credential data is communicated to the client electronic device.

20. A host electronic device comprising:

a secure element;

a host credential application provisioned on the secure element that generates host transaction credential data:

a communications component communicatively coupled to an administration entity subsystem; and

a processor configured to: determine that the host credential application is subject to a geographical restriction; and based on the determination, communicate to the administration entity subsystem, via the communications component, the host transaction credential data and an instruction for the administration entity subsystem to generate a unique voucher that can be redeemed by a client electronic device to obtain the host transaction credential data.