CONDUCTING TRANSACTIONS USING ELECTRONIC DEVICES WITH GEOGRAPHICALLY RESTRICTED NON-NATIVE CREDENTIALS
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.
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 FIELDThis 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 DISCLOSUREPortable 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 DISCLOSUREThis 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.
The discussion below makes reference to the following drawings, in which like reference characters refer to like parts throughout, and in which:
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. 1A 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
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
Referring now to
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
Referring now to
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
SP subsystem 200 may include any suitable service provider (“SP”) server 210, as shown in
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
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
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. 2Referring now to
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
As shown in
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. 2AReferring now to
As shown in
As shown in
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-3HAs shown in
While
Referring now to
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
It is understood that the operations shown in process 500 of
Process 600 may begin at operation 601, where first host access data 651 (e.g., first host access data 651 of
At operation 602, first host credential data 652 (e.g., credential data 652 of
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
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
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
At operation 610, client device 100′ may receive potential transaction data 660 from the accessed SP resource. For example, as shown in
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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-6One, some, or all of the processes described with respect to
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 ConceptsWhile 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.
Type: Application
Filed: Jan 25, 2017
Publication Date: Jul 27, 2017
Inventor: Nicholas J. Shearer (San Francisco, CA)
Application Number: 15/415,632