U.S. patent application number 15/415632 was filed with the patent office on 2017-07-27 for conducting transactions using electronic devices with geographically restricted non-native credentials.
The applicant listed for this patent is Apple Inc.. Invention is credited to Nicholas J. Shearer.
Application Number | 20170213206 15/415632 |
Document ID | / |
Family ID | 57966202 |
Filed Date | 2017-07-27 |
United States Patent
Application |
20170213206 |
Kind Code |
A1 |
Shearer; Nicholas J. |
July 27, 2017 |
CONDUCTING TRANSACTIONS USING ELECTRONIC DEVICES WITH
GEOGRAPHICALLY RESTRICTED NON-NATIVE CREDENTIALS
Abstract
Systems, methods, and computer-readable media for conducting a
transaction using an electronic device with a geographically
restricted non-native credential are provided. In one embodiment, a
host electronic device in a system including an administration
entity subsystem and a client electronic device communicatively
coupled to the host electronic device via the administration entity
subsystem may be provided to include a secure element, a host
credential application provisioned on the secure element that
generates host transaction credential data, a communications
component communicatively coupled to the administration entity
subsystem, and a processor that determines that the host credential
application is subject to a geographical restriction and, based on
the determination, communicates to the administration entity
subsystem via the communications component the host transaction
credential data and an instruction for the administration entity
subsystem to generate a unique voucher redeemable by the client
electronic device for the host transaction credential data.
Inventors: |
Shearer; Nicholas J.; (San
Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Apple Inc. |
Cupertino |
CA |
US |
|
|
Family ID: |
57966202 |
Appl. No.: |
15/415632 |
Filed: |
January 25, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62286938 |
Jan 25, 2016 |
|
|
|
62348958 |
Jun 12, 2016 |
|
|
|
62384059 |
Sep 6, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 2220/00 20130101;
G06Q 20/3223 20130101; G06Q 20/3278 20130101; G06Q 20/401 20130101;
G06Q 20/3821 20130101; G06Q 20/3829 20130101; G06Q 20/10
20130101 |
International
Class: |
G06Q 20/32 20060101
G06Q020/32; G06Q 20/40 20060101 G06Q020/40 |
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.
Description
CROSS-REFERENCE TO RELATED APPLICATION(S)
[0001] This application claims the benefit of prior filed U.S.
Provisional Patent Application No. 62/286,938, filed Jan. 25, 2016,
U.S. Provisional Patent Application No. 62/348,958, filed Jun. 12,
2016, and U.S. Provisional Patent Application No. 62/384,059, filed
Sep. 6, 2016 each of which is hereby incorporated by reference
herein in its entirety.
TECHNICAL FIELD
[0002] This disclosure relates to conducting a transaction using an
electronic device with a geographically restricted non-native
credential, including to conducting a transaction using a client
electronic device with a geographically restricted credential from
a host electronic device.
BACKGROUND OF THE DISCLOSURE
[0003] Portable electronic devices (e.g., cellular telephones) may
be provided with near field communication ("NFC") components for
enabling contactless proximity-based communications with another
entity (e.g., a merchant). Often times, these communications are
associated with commercial transactions or other secure data
transactions that require the electronic device to generate,
access, and/or share a native payment credential, such as a credit
card credential, with the other entity in a contactless
proximity-based communication. However, use of such a native
payment credential by the electronic device in other types of
communications (e.g., online commercial transactions) has often
been inefficient.
SUMMARY OF THE DISCLOSURE
[0004] This document describes systems, methods, and
computer-readable media for conducting a transaction using an
electronic device with a geographically restricted non-native
credential.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] This Summary is provided only to summarize some example
embodiments, so as to provide a basic understanding of some aspects
of the subject matter described in this document. Accordingly, it
will be appreciated that the features described in this Summary are
only examples and should not be construed to narrow the scope or
spirit of the subject matter described herein in any way. Unless
otherwise stated, features described in the context of one example
may be combined or used with features described in the context of
one or more other examples. Other features, aspects, and advantages
of the subject matter described herein will become apparent from
the following Detailed Description, Figures, and Claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The discussion below makes reference to the following
drawings, in which like reference characters refer to like parts
throughout, and in which:
[0010] FIG. 1 is a schematic view of an illustrative system for
conducting a transaction;
[0011] FIG. 1A is a more detailed schematic view of the system of
FIG. 1;
[0012] FIG. 1B is another more detailed schematic view of the
system of FIGS. 1 and 1A;
[0013] FIG. 2 is a more detailed schematic view of an electronic
device of the system of FIGS. 1-1B;
[0014] FIG. 2A is another more detailed schematic view of the
electronic device of FIGS. 1-2;
[0015] FIG. 3 is a front view of the electronic device of FIGS.
1-2A;
[0016] FIGS. 3A-3H are front views of screens of a graphical user
interface of an electronic device of one or more of FIGS. 1-3
illustrating processes for conducting a transaction;
[0017] FIG. 4 is a more detailed schematic view of the AE subsystem
of the system of FIGS. 1-1B; and
[0018] FIGS. 5 and 6 are flowcharts of illustrative processes for
conducting a transaction.
DETAILED DESCRIPTION OF THE DISCLOSURE
[0019] A credential (e.g., a payment credential or any other
suitable transaction credential) provisioned on a secure element of
a credential-enabled host electronic device may be used for
generating certain host credential data (e.g., token data and
associated crypto data) that may then be used for securely funding
or otherwise conducting a transaction (e.g., a financial
transaction or any other suitable credential transaction) with a
service provider subsystem, either directly or via a client
electronic device that may be interfacing with the service provider
subsystem. However, certain host credentials may be associated with
certain restrictions that may prevent such host credential data
from being handled by certain servers of certain entities (e.g., an
administration entity subsystem that may be used to encrypt
communications between the host device and the client device) that
are geographically located in a location that is physically
distinct from a geographic location of a source of the host
credentials (e.g., servers of a credential issuer subsystem). For
example, in certain markets (e.g., China), regulations may prevent
certain banking information from being transmitted outside of the
country. Therefore, rather than communicating such host credential
data between the host device and the client device via a restricted
server for that host credential data, such host credential data may
be stored against a unique voucher that, on its own, may not be
indicative of the host credential data and/or of the host
credential and/or of the source of the host credential, and that
voucher may then be communicated between the host device and the
client device via the restricted server before being redeemed by
the client device for the host credential data, which may then be
shared by the client device with the service provider subsystem.
Thus, the voucher may be used as an effective proxy for the host
credential data to abide by certain host credential regulations
while also maintaining the security and efficiency of the
process.
Description of FIG. 1
[0020] FIG. 1 is a schematic view of an illustrative system 1 that
may allow for the secure use of a geographically restricted
credential provisioned on a host electronic device from a
credential issuer subsystem in a transaction (e.g., an online
transaction or a contactless proximity-based transaction) with a
service provider (or merchant or processor), either directly or via
or at the request of a client electronic device. For example, as
shown in FIG. 1, system 1 may include an end-user host electronic
device 100 (e.g., a smart phone) with at least one geographically
restricted credential provisioned thereon (e.g., on a secure
element of host electronic device 100), an end-user client
electronic device 100' (e.g., a laptop computer) that may or may
not have at least one credential provisioned thereon, an
administration (or commercial or trusted) entity subsystem 400, a
service provider (or merchant or processing) subsystem 200, and a
credential issuer subsystem 300. System 1 may also include an
acquiring (or payment processor) subsystem 399 that may utilize
credential data generated by a credential provisioned on host
device 100 for completing the transaction with issuer subsystem 300
on behalf of SP subsystem 200. Communication of any suitable data
between any two of host electronic device 100, client electronic
device 100', service provider ("SP") subsystem 200, administration
entity ("AE") subsystem 400, acquiring subsystem 399, and
credential issuer (or financial institution) subsystem 300 may be
enabled via any suitable communications set-up 9, which may include
any suitable wired communications path, any suitable wireless
communications path, or any suitable combination of two or more
wired and/or wireless communications paths using any suitable
communications protocol(s) and/or any suitable network(s) and/or
cloud architecture(s).
[0021] A transaction credential (e.g., a payment credential or any
other suitable transaction credential) may be provisioned on host
electronic device 100 (e.g., on a secure element or other storage
component of host electronic device 100) from any suitable
credential issuer subsystem 300 (e.g., an issuing bank subsystem or
financial institution subsystem), either directly from the
credential issuer subsystem or via AE subsystem 400, which may be
operative to securely communicate credential data onto host device
100 and manage such credential data. For example, credential issuer
subsystem 300 may include a first issuing subsystem 391 that may be
operated by at least one first credential issuing institution
(e.g., a first issuing bank, such as Wells Fargo of San Francisco,
Calif.) with or without a first payment network institution (e.g.,
a first payment network, such as MasterCard) for provisioning a
first transaction credential on host device 100 (e.g., directly or
via AE subsystem 400). Credential issuer subsystem 300 may include
a second issuing subsystem 392 that may be operated by at least one
second credential issuing institution (e.g., a second issuing bank,
such as the People's Bank of China of Beijing, China) with or
without a second payment network institution (e.g., a second
payment network, such as China UnionPay of Shanghai, China) for
provisioning a second transaction credential on host device 100
(e.g., directly or via AE subsystem 400). Once provisioned on host
device 100, a transaction credential may then be used by host
device 100 for securely funding or otherwise conducting a
transaction (e.g., a commercial or financial transaction or any
other suitable credential transaction) with SP subsystem 200 (e.g.,
any suitable subsystem that may be operative to provide access to
any suitable good or service as part of a transaction), either
directly with SP subsystem 200 or via client device 100' that may
be interfacing with SP subsystem 200 or on behalf of client device
100' that may have initiated the transaction with SP subsystem
200.
[0022] For example, while interfacing with service provider ("SP")
subsystem 200 (e.g., via an online resource (e.g., an online app or
web browser) or via a contactless proximity-based communication
medium) for accessing (e.g., purchasing) a service provider product
or service, client device 100' may identify host device 100 as a
desired source of a transaction credential to be used for funding
or otherwise furthering a transaction to access the service
provider product. Client device 100' may be either a type of device
that may not be configured to store or otherwise have provisioned
thereon a transaction credential for use in funding the transaction
(e.g., client device 100' may not include a secure element
operative to securely utilize a payment credential) or a type of
device that is configured to store a transaction credential but
that does not currently have a particular credential stored thereon
that is desired to be used in a particular transaction initiated by
client device 100'. For example, at any suitable point during any
suitable communication between client device 100' and SP subsystem
200 for defining a transaction to access a product of SP subsystem
200, client device 100' may identify or have identified on its
behalf, such as by a communication service (e.g., an identity
service ("IDS")) of AE subsystem 400, the availability of at least
one transaction credential stored on host device 100 that may be
available to client device 100' for use in funding or otherwise
furthering the transaction. In some embodiments, as shown in FIG.
1, AE subsystem 400 may provide an IDS subsystem 471 that may be
configured to enable and/or manage any suitable device detection
and/or communication between host device 100 and client device
100', such as an identity services ("IDS") transport (e.g., using
an administration-entity specific (or other entity specific)
service (e.g., iMessage.TM. by Apple Inc.)). For example, certain
devices may be automatically or manually registered for such a
service (e.g., all devices in an eco-system of an administration
entity of AE subsystem 400 (e.g., host device 100 and client device
100') may be automatically registered for the service). Such a
service may be operative to provide an end-to-end encrypted
mechanism that may require active registration before device
detection may be achieved and/or messages can be sent using the
service (e.g., using an IDS application on each participating
device). IDS subsystem 471, which may include any suitable
processing, data accessing, and data communicating components of AE
subsystem 400, may be operative to identify or otherwise lookup the
status of any credentials provisioned on any electronic devices
associated with a given user account or otherwise, for example,
such that AE subsystem 400 may be operative to efficiently and
effectively identify one or more non-native transaction credentials
that may be available to a particular client device from one or
more particular host devices associated with a particular user
account (e.g., multiple host devices and the client device may be
in a family account with AE subsystem 400). Then, client device
100' may share any suitable data with an identified and selected
host device 100 for requesting that such a transaction credential
on host device 100 be shared with SP subsystem 200 for funding the
transaction on behalf of client device 100'. Such a request and any
other communications between client device 100' and host device 100
may be facilitated by and through IDS subsystem 471 of AE subsystem
400 for enabling a secure and/or efficient communication path
between devices.
[0023] 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.
[0024] However, in some embodiments, certain transaction
credentials provisioned on host device 100 by certain credential
issuing subsystems of credential issuer subsystem may be regulated
and/or governed by certain geographic and/or political
restrictions, which may aim to prevent any host transaction
credential data generated on host device 100 by such a
"geographically restricted" transaction credential from being
handled by any server or component of system 1 (e.g., AE subsystem
400 and/or client device 100' and/or SP subsystem 200 and/or
acquiring bank 399) that is physically located in a different
geographical region than the geographical region in which the
credential issuing subsystem of the geographically restricted
transaction credential is located. For example, as shown in FIG. 1,
first issuing subsystem 391 may be physically located in a first
geographical region 91 (e.g., first credential issuing institution
Wells Fargo and/or first payment network institution MasterCard of
first issuing subsystem 391 for provisioning a first transaction
credential on host device 100 may be physically located in the
United States of America as first geographical region 91), while
second issuing subsystem 392 may be physically located in a second
geographical region 92 that is at least partially different than
first geographical region 91 (e.g., second credential issuing
institution People's Bank of China and/or second payment network
institution China UnionPay of second issuing subsystem 392 for
provisioning a second transaction credential on host device 100 may
be physically located in the People's Republic of China as second
geographical region 92). Moreover, as shown in FIG. 1, IDS
subsystem 471 and first security subsystem 491 of AE subsystem 400
may be physically located in first geographical region 91 while
second security subsystem 492 of AE subsystem 400 may be physically
located in second geographical region 92 (it is to be understood
that each one of host device 100, client device 100', SP subsystem
200, and acquiring subsystem 399 may be located in one of first
geographical region 91 or second geographical region 92 depending
on a particular embodiment). Therefore, in such an exemplary system
1, if second issuing subsystem 392 of second geographical region 92
provisions such a geographically restricted transaction credential
on host device 100, then system 1 may be configured to avoid any
host transaction credential data generated on host device 100 by
that geographically restricted transaction credential from being
handled by any (or at least a certain one) server or component of
system 1 that is physically located in a different geographical
region than second geographical region 92 of second issuing
subsystem 392 (i.e., system 1 may be configured not to communicate
or process or otherwise handle any host transaction credential data
generated on host device 100 by such a geographically restricted
transaction credential using IDS subsystem 471 and/or first
security subsystem 491 of AE subsystem 400 that is physically
located outside of second geographical region 92 (e.g., physically
located inside of first geographical region 91)). In such
embodiments, although, as shown, AE subsystem 400 may be configured
to provide in second geographical region 92 a second security
subsystem 492 that may be operative to maintain and use any
suitable shared secret between AE subsystem 400 and SP subsystem
200 to encrypt or otherwise modify any host transaction credential
data as generated on host device 100 by such a geographically
restricted transaction credential in order to generate SP-secured
host transaction credential data in accordance with the
geographical restriction of the geographically restricted
transaction credential, AE subsystem 400 may not be configured to
provide any IDS subsystem in second geographical region 92 but
instead may only provide IDS subsystem 471 in first geographical
region 91 (e.g., an IDS subsystem of an administration entity may
only be located in the United States and not in China, but can
provide coverage for both regions). Therefore, the SP-secured host
transaction credential data generated by second security subsystem
492 for the geographically restricted transaction credential (e.g.,
the "geographically restricted" SP-secured host transaction
credential data) may not be communicated through IDS subsystem 471
as might otherwise be done when SP-secured host transaction
credential data is to be communicated from host device 100 to
client device 100'. In such embodiments, second security subsystem
492 may be configured to generate or otherwise access a unique host
transaction voucher in conjunction with generating the
geographically restricted SP-secured host transaction credential
data and may then be configured to store such a unique host
transaction voucher against the SP-secured host transaction
credential data (e.g., in any suitable memory component of second
security subsystem 492), after which the unique host transaction
voucher may be returned to host device 100 instead of the
SP-secured host transaction credential data. Then, host device 100
may be operative to communicate that unique host transaction
voucher rather than any SP-secured host transaction credential data
to client device 100', where such communication of the unique host
transaction voucher from host device 100 to client device 100' may
be facilitated by and through IDS subsystem 471 of AE subsystem 400
for enabling a secure and/or efficient communication path for the
voucher between the devices. Such a unique host transaction voucher
may be any suitable data element of any suitable size, such as an
8- or 9-character alphanumeric string that may be randomly or
uniquely generated by AE subsystem 400 or otherwise for association
with the geographically restricted SP-secured host transaction
credential data, such that the voucher may not include any data
indicative of the geographically restricted transaction credential
and/or of the geographically restricted SP-secured host transaction
credential data. Therefore, such a unique host transaction voucher
may be handled by IDS subsystem 471 without violating the
geographical restriction of the geographically restricted
transaction credential, even though IDS subsystem 471 is not
physically located in second geographic region 92, as the voucher
may not include any host transaction credential data generated on
host device 100 by the geographically restricted transaction
credential and/or any geographically restricted SP-secured host
transaction credential data generated by second security subsystem
492 using the geographically restricted transaction credential.
However, once the unique host transaction voucher is received by
client device 100', client device 100' may redeem the voucher for
the geographically restricted SP-secured host transaction
credential data by communicating the voucher to second geographic
region 92. Then, second geographic region 92 may identify the
appropriate geographically restricted SP-secured host transaction
credential data using the voucher received from client device 100'
(e.g., second geographic region 92 may identify the particular
geographically restricted SP-secured host transaction credential
data stored against the particular unique host transaction voucher)
and may then communicate that identified geographically restricted
SP-secured host transaction credential data back to client device
100', which may then be communicated on from client device 100' to
SP subsystem 200 for funding or otherwise furthering the
transaction (e.g., without SP subsystem 200 having to communicate
with or even be aware of host device 100 (e.g., as if the
SP-secured host transaction credential data had been generated
locally on client device 100')). Alternatively, in other
embodiments, AE subsystem 400 may be operative to communicate the
voucher on to servicer provider subsystem 200, or host device 100
may be operative to communicate the voucher received from AE
subsystem 400 on to servicer provider subsystem 200, or client
device 100' may be operative to communicate the voucher received
from host device 100 on to SP subsystem 200, and then SP subsystem
200 may be operative to redeem the voucher at second security
subsystem 492 for the SP-secured host transaction credential data.
For example, in some embodiments, client device 100' may also be
located in first geographical region 91 and, like IDS subsystem
471, ought not handle the geographically restricted SP-secured host
transaction credential data for honoring the applicable geographic
restriction(s), such that the voucher ought to be forwarded on from
client device 100' to SP subsystem 200, which may redeem the
voucher if SP subsystem 200 is located in second geographical
region 92. Otherwise, if SP subsystem 200 is not located in second
geographical region 92, then the voucher may be communicated to SP
subsystem 200, and SP subsystem 200 may forward the voucher to an
appropriate acquiring subsystem 399 that is in second geographical
region 92, such that that acquiring subsystem 399 may appropriately
redeem the voucher for the geographically restricted SP-secured
host transaction credential data for honoring the applicable
geographic restriction(s). Therefore, a unique host transaction
voucher may be generated and used by system 1 as an effective proxy
for any geographically restricted SP-secured host transaction
credential data during any suitable portion of a transaction
process for honoring the applicable geographic restriction(s),
while AE subsystem 400 may be utilized as a conduit for effective
communication between host and client devices and/or while AE
subsystem 400 may be utilized for enabling a secure communication
path of transaction credential data by using any suitable shared
secret(s) or other security features of AE subsystem 400 and SP
subsystem 200 to generate the geographically restricted SP-secured
host transaction credential data.
Description of FIG. 1A
[0025] Referring now to FIG. 1A, FIG. 1A shows an expanded view of
system 1 described above with respect to FIG. 1 that may allow for
the secure use of a credential (e.g., a geographically restricted
credential) on host electronic device 100 in a transaction (e.g.,
an online transaction or a contactless proximity-based transaction)
with SP subsystem 200 (e.g., via client electronic device 100'). AE
subsystem 400 and credential issuer subsystem 300 may be used for
securely provisioning one or more credentials on host device 100,
whereby such a provisioned credential may be used by host device
100 for conducting a transaction (e.g., a financial or payment or
other suitable data transaction) with SP subsystem 200 via client
device 100'. For example, in response to host device 100 receiving
a client transaction (or payment) request from client device 100'
(e.g., via an IDS service facilitated by AE subsystem 400) for a
particular transaction with SP subsystem 200, host device 100 may
share host transaction credential data or host payment credential
data of a credential provisioned on host device 100 with AE
subsystem 400 in order for the host transaction credential data to
be secured as SP-secured host transaction credential data by AE
subsystem 400 using a shared secret with SP subsystem 200. That
SP-secured host transaction credential data may then be shared with
client device 100' via host device 100 using a unique host
transaction voucher communicated from AE subsystem 400 to host
device 100 that may then be communicated from host device 100 to
client device 100' (e.g., as secured host transaction data 684) as
a proxy for the SP-secured host transaction credential data, while
that voucher may then be redeemed by client device 100' at AE
subsystem 400 for the SP-secured host transaction credential data
(e.g., to abide by any applicable geographic restriction(s) of the
credential that may forbid communication of the SP-secured host
transaction credential data between host device 100 and client
device 100' using an IDS service of AE subsystem 400). Then, client
device 100' may share that SP-secured host transaction credential
data with SP subsystem 200 as a contactless proximity-based
communication 5 (e.g., a near field communication or a
Bluetooth.TM. communication) and/or an online-based communication
(e.g., a network telecommunication or otherwise) (e.g., as client
transaction data 690) for funding or otherwise furthering the
particular transaction with SP subsystem 200. System 1 may also
include acquiring bank subsystem 399 that may utilize such
SP-secured host transaction credential data received by SP
subsystem 200 for completing the transaction with issuer subsystem
300 on behalf of SP subsystem 200.
[0026] System 1 may include a communications path 15 for enabling
communication between client device 100' and SP subsystem 200, a
communications path 25 for enabling communication between SP
subsystem 200 and acquiring bank subsystem 399, a communications
path 35 for enabling communication between acquiring bank subsystem
399 and credential issuer subsystem 300, a communications path 41
for enabling communication between a first payment network
subsystem 361 of credential issuer subsystem 300 and first issuing
subsystem 391 of credential issuer subsystem 300 (e.g., of first
geographical region 91 of FIG. 1), a communications path 42 for
enabling communication between a second payment network subsystem
362 of credential issuer subsystem 300 and second issuing subsystem
392 of credential issuer subsystem 300 (e.g., of second
geographical region 92 of FIG. 1), a communications path 55 for
enabling communication between credential issuer subsystem 300 and
AE subsystem 400, a communications path 65 for enabling
communication between AE subsystem 400 and host electronic device
100, a communications path 75 for enabling communication between
credential issuer subsystem 300 and host electronic device 100, a
communications path 85 for enabling communication between AE
subsystem 400 and SP subsystem 200, a communications path 95 for
enabling communication between AE subsystem 400 and client device
100', and a communications path 99 for enabling communication
between host device 100 and client device 100'. One or more of
paths 15, 25, 35, 41, 42, 55, 65, 75, 85, 95, and 99 may be at
least partially managed by one or more trusted service managers
("TSMs"). Any suitable circuitry, device, system, or combination of
these (e.g., a wireless communications infrastructure that may
include one or more communications towers, telecommunications
servers, or the like) that may be operative to create a
communications network may be used to provide one or more of paths
15, 25, 35, 41, 42, 55, 65, 75, 85, 95, and 99, which may be
capable of providing communications using any suitable wired or
wireless communications protocol. For example, one or more of paths
15, 25, 35, 41, 42, 55, 65, 75, 85, 95, and 99 may support Wi-Fi
(e.g., an 802.11 protocol), ZigBee (e.g., an 802.15.4 protocol),
WiDi.TM., Ethernet, Bluetooth.TM., BLE, high frequency systems
(e.g., 900 MHz, 2.4 GHz, and 5.6 GHz communication systems),
infrared, TCP/IP, SCTP, DHCP, HTTP, BitTorrent.TM., FTP, RTP, RTSP,
RTCP, RAOP, RDTP, UDP, SSH, WDS-bridging, any communications
protocol that may be used by wireless and cellular telephones and
personal e-mail devices (e.g., GSM, GSM plus EDGE, CDMA, OFDMA,
HSPA, multi-band, etc.), any communications protocol that may be
used by a low power Wireless Personal Area Network ("6LoWPAN")
module, any other communications protocol, or any combination
thereof. One or more of paths 15, 25, 35, 41, 42, 55, 65, 75, 85,
95, and 99 may be enabled by any suitable communications set-up
(e.g., communications set-up 9 of FIG. 1).
Description of FIG. 1B
[0027] Referring now to FIG. 1B, FIG. 1B shows a more detailed view
of the system 1 described above with respect to FIG. IA. As shown
in FIG. 1B, for example, host electronic device 100 may include a
processor 102, a communications component 106, and/or a near field
communication ("NFC") component 120. NFC component 120 may include
or otherwise provide a secure element 145 that may be capable of
securely hosting applications and their confidential and
cryptographic data in accordance with rules and security
requirements that may be set forth by a set of well-identified
trusted authorities. As described below in more detail, a
credential applet or a payment application on secure element 145
(e.g., of NFC component 120) of host device 100 may be configured
to provide host payment credential data or host transaction
credential data with sufficient detail for identifying any suitable
funding account or other financial instrument or credit source or
the like (e.g., an account at credential issuer subsystem 300
(e.g., at the same issuing subsystem of credential issuer subsystem
300 that may have provisioned the credential applet on host device
100)), where such host transaction credential data may eventually
be received by SP subsystem 200 and/or issuer subsystem 300 for
funding a financial transaction or otherwise furthering any
suitable transaction. NFC component 120 or a similar NFC component
120' may be configured to communicate such host transaction
credential data or an associated voucher or any other suitable data
as a contactless proximity-based communication (e.g., near field
communication) with each other or with SP subsystem 200 (e.g., with
an SP terminal 220 of SP subsystem 200 that may be located at a
brick and mortar store or any physical location at which a user of
host device 100 or client device 100' may use a credential to
conduct a transaction with a proximately located SP terminal 220
via a contactless proximity-based communication). NFC component 120
may allow for close range communication at relatively low data
rates (e.g., 424 kbps), and may comply with any suitable standards,
such as ISO/IEC 7816, ISO/IEC 18092, ECMA-340, ISO/IEC 21481,
ECMA-352, ISO 14443, and/or ISO 15693. NFC component 120 may allow
for close range communication at relatively high data rates (e.g.,
370 Mbps), and may comply with any suitable standards, such as the
TransferJet.TM. protocol. Communication between NFC component 120
or NFC component 120' and SP subsystem 200 may occur within any
suitable close range distance between the NFC component and
merchant subsystem 200 (see, e.g., distance D of FIGS. 1A and 1B
between NFC component 120' and terminal 220), such as a range of
approximately 2 to 4 centimeters, and may operate at any suitable
frequency (e.g., 13.56 MHz). For example, such close range
communication of an NFC component may take place via magnetic field
induction, which may allow the NFC component to communicate with
other NFC devices and/or to retrieve information from tags having
radio frequency identification ("RFID") circuitry. While NFC
component 120 (and/or component 120') may be described with respect
to near field communication, it is to be understood that component
120 may be configured to provide any suitable contactless
proximity-based mobile payment or any other suitable type of
contactless proximity-based communication between device 100 and
another entity, such as client device 100' or terminal 220. For
example, NFC component 120 may be configured to provide any
suitable short-range communication, such as those involving
electromagnetic/electrostatic coupling technologies. Communications
component 106 may be provided to allow host device 100 to
communicate any suitable host transaction credential data or an
associated voucher with one or more other electronic devices or
servers or subsystems (e.g., one or more subsystems or other
components of system 1) using any suitable wired or wireless
protocol. Processor 102 of host device 100 may include any suitable
processing circuitry that may be operative to control the
operations and performance of one or more components of host device
100. For example, processor 102 may be configured to run one or
more applications on device 100 (e.g., an application 103 and/or an
online resource or SP application 113) that may at least partially
dictate the way in which data (e.g., host transaction credential
data or an associated voucher) may be communicated by host device
100 for furthering a transaction with SP subsystem 200, such as via
client device 100' (e.g., the way in which data may be communicated
between host device 100 and client device 100' and/or the way in
which data may be communicated between host device 100 and AE
subsystem 400, which may eventually be communicated from AE
subsystem 400 to client device 100'). Moreover, as shown in FIG.
1B, host device 100 may include any suitable host device
identification information 119, which may be accessible to
processor 102 or any other suitable portion of device 100. Host
device identification information 119 may be utilized by a user of
client device 100' and/or AE subsystem 400 and/or SP subsystem 200
and/or issuer subsystem 300 for uniquely identifying host device
100 to facilitate a transaction with SP subsystem 200 and/or to
enable any suitable secure communication with host device 100. As
just one example, host device identification information 119 may be
a telephone number or e-mail address or any unique identifier that
may be associated with device 100.
[0028] Client device 100' may include one, some, or all of the same
components as host device 100 or any components that are not
provided by host device 100. For example, as shown in FIG. 1B,
client device 100' may include any suitable communications
component 106' that may communicate any suitable communications
with host device 100 (e.g., via communications path 99) and/or with
AE subsystem 400 (e.g., via communications path 95) and/or with SP
subsystem 200 (e.g., via communications path 15). Client device
100' may include any suitable contactless proximity-based or NFC
component 120' that may be operative to communicate contactless
proximity-based communications 5 with terminal 220 of SP subsystem
200. Client device 100' may include any suitable processor 102'
that may be operative to run one or more suitable applications on
device 100' (e.g., online resource or SP application 113') that may
at least partially dictate the way in which host transaction
credential data or an associated voucher from host device 100 or
otherwise may be redeemed and/or communicated by client device 100'
for furthering a transaction with SP subsystem 200. Moreover,
client device 100' may include any suitable client device
identification information 119', which may be accessible to
processor 102' or any other suitable portion of device 100', and
which may be utilized by a user of host device 100 and/or AE
subsystem 400 and/or SP subsystem 200 and/or issuer subsystem 300
for uniquely identifying client device 100' to facilitate a
transaction with SP subsystem 200 and/or to enable any suitable
secure communication with client device 100'. As just one example,
client device identification information 119' may be a telephone
number or e-mail address or any unique identifier that may be
associated with device 100'. Although not shown, client device 100'
may also include an I/O interface that may be the same as or
similar to an I/O interface 114 of electronic device 100 of FIG. 2,
a bus that may be the same as or similar to a bus 118 of electronic
device 100 (see, e.g., FIG. 2), a memory component that may be the
same as or similar to a memory component 104 of electronic device
100, and/or a power supply component that may be the same as or
similar to a power supply component 108 of electronic device
100.
[0029] SP subsystem 200 may include any suitable service provider
("SP") server 210, as shown in FIG. 1B, which may include any
suitable component or subsystem configured to communicate any
suitable data via any suitable communications protocol (e.g.,
Wi-Fi, Bluetooth.TM., cellular, wired network protocols, etc.) with
a communications component of AE subsystem 400 and/or with
communications component 106' of acquiring bank 399 and/or with a
communications component of client device 100'. For example, SP
server 210 may be operative to communicate potential transaction
data 660 with communications component 106' of client device 100'
within any suitable online-context, such as when a user of client
device 100' is communicating with SP server 210 to conduct a
transaction via any suitable SP online resource 113' that may be
running on client device 100', such as a third party SP application
113' running on client device 100' that may be managed by SP server
210 or an internet application 113' (e.g., Safari.TM. by Apple
Inc.) running on client device 100' that may be pointed to a
uniform resource locator ("URL") whose target or web resource may
be managed by SP server 210. Accordingly, it is noted that
communications between SP server 210 and client device 100' may
occur wirelessly and/or via wired paths (e.g., over the internet).
SP server 210 may be provided by a merchant or any other
controlling entity of SP subsystem 200 (e.g., as a webserver to
host website data and/or manage third party application data). As
shown in FIG. 1B, SP subsystem 200 may include any suitable SP
terminal 220 (e.g., a merchant payment terminal), which may include
any suitable component or subsystem configured to communicate any
suitable data with a contactless proximity-based communication
component of host device 100 and/or of client device 100' (e.g., a
contactless proximity-based communication 5 with NFC component 120'
of client device 100'). SP subsystem 200 may include an SP key 157
and/or an SP key 157'. Moreover, SP subsystem 200 may include any
suitable service provider identification ("SP ID") information 219,
which may be accessible to server 210 and/or terminal 220 and/or
any other suitable portion of SP subsystem 200. SP ID information
219 may be utilized by client device 100' and/or host device 100
and/or AE subsystem 400 and/or SP subsystem 200 and/or issuer
subsystem 300 for uniquely identifying SP subsystem 200 to
facilitate a transaction and/or to enable any suitable secure
communication. As just one example, SP ID information 219 may be a
telephone number or e-mail address or IP address or any unique
identifier that may be associated with SP subsystem 200. Although
not shown, SP subsystem 200 may also include an SP processor
component that may be the same as or similar to a processor
component 102 of electronic device 100 of FIGS. 1B and 2, an SP
communications component that may be the same as or similar to a
communications component 106 of electronic device 100 of FIGS. 1B
and 2 (e.g., as a portion of server 210), an SP I/O interface that
may be the same as or similar to an I/O interface 114 of electronic
device 100 of FIG. 2, an SP bus that may be the same as or similar
to a bus 118 of electronic device 100 of FIG. 2, an SP memory
component that may be the same as or similar to a memory component
104 of electronic device 100 of FIG. 2, and/or an SP power supply
component that may be the same as or similar to a power supply
component 108 of electronic device 100 of FIG. 2.
[0030] 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.
[0031] In order for a financial transaction to occur within system
1 (e.g., a particular type of the many suitable types of
transactions that may be carried out by system 1 between client
device 100' and/or host device 100 and SP subsystem 200 according
to the concepts disclosed herein), at least one commerce credential
must be securely provisioned on a secure element of host device
100. For example, such a commerce credential may be at least
partially provisioned on secure element 145 of host device 100
directly from issuer subsystem 300 or via AE subsystem 400 (e.g., a
first host credential may be provisioned as first host credential
data 652 between first issuing subsystem 391 (and/or associated
first network subsystem 361) of issuer subsystem 300 and device
100, and/or a second host credential may be provisioned as second
host credential data 654 between second issuing subsystem 392
(and/or associated second network subsystem 362) of issuer
subsystem 300 and device 100, where any such host credential data
may then be passed to NFC component 120 via communications
component 106). First host credential data 652 may be provisioned
on secure element 145 of device 100 as at least a portion or all of
a credential supplemental security domain of NFC component 120 and
may include a credential applet with credential information and/or
a credential key, such as payment application or credential applet
153a with credential information 161a and credential key 155a',
while second host credential data 654 may be provisioned on secure
element 145 of device 100 as at least a portion or all of a
credential supplemental security domain of NFC component 120 and
may include a credential applet with credential information and/or
a credential key, such as payment application or credential applet
153b with credential information 161b and credential key 155b'. As
shown in FIG. 1B, for example, issuer subsystem 300 (e.g., first
issuing subsystem 391) may also have access to credential key 155a'
(e.g., for decrypting data encrypted by device 100 using credential
key 155a'), and issuer subsystem 300 (e.g., second issuing
subsystem 392) may also have access to credential key 155b' (e.g.,
for decrypting data encrypted by device 100 using credential key
155b'). Issuer subsystem 300 may be responsible for management of
credentials key 155a' and 155b', which may include the generation,
exchange, storage, use, and replacement of such keys. Issuer
subsystem 300 may store its version of each credential key in one
or more appropriate secure elements of issuer subsystem 300. It is
to be understood that each one of credential keys 155a' and 155b'
of NFC component 120 and of issuer subsystem 300 may be any
suitable shared secret (e.g., a password, passphrase, array of
randomly chosen bytes, one or more symmetric keys, public-private
keys (e.g., asymmetric keys), etc.) available to both the secure
element of electronic device 100 and issuer subsystem 300 that may
be operative to enable any suitable crypto data (e.g., a
cryptogram) or any other suitable data to be independently
generated by electronic device 100 and issuer subsystem 300 (e.g.,
for validating payment data for a financial transaction), such as
by using any suitable cryptographic algorithm or cipher whose
functional output may be at least partially determined by the
shared secret, where such a shared secret may be provisioned on
device 100 by issuer subsystem 300. A shared secret may either be
shared beforehand between issuer subsystem 300 and host device 100
(e.g., during provisioning of a credential on device 100 by issuer
subsystem 300), in which case such a shared secret may be referred
to as a pre-shared key, or a shared secret may be created prior to
use for a particular financial transaction by using a key-agreement
protocol (e.g., using public-key cryptography, such as
Diffie-Hellman, or using symmetric-key cryptography, such as
Kerberos). The shared secret and any suitable cryptographic
algorithm or cipher whose functional output may be at least
partially determined by the shared secret may be accessible to the
secure element of device 100.
[0032] 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.TM.
Store for selling/renting media to be played by device 100, the
Apple App Store.TM. for selling/renting applications for use on
device 100, the Apple iCloud.TM. 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.TM. 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.TM., iPad.TM., iPhone.TM., MacBook.TM., iMac.TM., Apple
Watch.TM., 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.
[0033] In addition to at least one commerce credential being
provisioned on a secure element of NFC component 120 of host device
100 (e.g., a first host credential as a portion of a first
credential SSD 154a with credential key 155a' and credential
information 161a and/or a second host credential as a portion of a
second credential SSD 154b with credential key 155b' and credential
information 161b), at least one access SSD 154c with an access key
155c may also be provisioned on the secure element of NFC component
120 of device 100 in order to more securely enable device 100 to
conduct a financial or other secure transaction with SP subsystem
200. For example, access SSD 154c may be at least partially
provisioned on secure element 145 of host device 100 directly from
AE subsystem 400 (e.g., as access data 651/653 between AE subsystem
400 and communications component 106 of device 100, which may then
be passed to NFC component 120 from communications component 106).
Access data 651/653 may be provisioned on device 100 as at least a
portion or all of access SSD 154c and may include an access applet
153c with access key 155c. As shown in FIG. 1B, AE subsystem 400
may also have access to access key 155c (e.g., for decrypting data
encrypted by device 100 using access key 155c). AE subsystem 400
may be responsible for management of access key 155c, which may
include the generation, exchange, storage, use, and replacement of
such a key. AE subsystem 400 may store its version of access key
155c in a secure element of AE subsystem 400. Access SSD 154c with
access key 155c may be configured to determine intent and local
authentication of a user of device 100 (e.g., via one or more input
components 110 of device 100, such as a biometric input component)
and, in response to such a determination, may be configured to
enable another particular SSD for conducting a payment transaction
(e.g., with a host credential of credential SSD 154a or SSD 154b).
By storing such an access SSD within secure element 145 of device
100, its ability to reliably determine user intent for and
authentication of a secure data transaction may be increased.
Moreover, access key 155c may be used to provide increased
encryption to any host transaction data that may be communicated
outside of the secure element of device 100. Access data 651/653
may include an issuer security domain ("ISD") key 156k for an ISD
152 of secure element 145, which may also be maintained by AE
subsystem 400, and may be used in addition to or as an alternative
to access key 155c (or one or more other ones of access keys 155a,
155b, 151k, and 158k). Although not explicitly shown or described,
it is to be understood that AE subsystem 400 may be operative to
interact with or be associated with client device 100' in any or
all of the same ways that AE subsystem 400 may be operative to
interact with or be associated with host device 100 (e.g., when a
credential may be provisioned on client device 100', such that
client device 100' may be operative to operate as a host
device).
[0034] 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.TM.) may receive at least some data representative
of application 113' from SP subsystem 200 via communications path
85. Moreover, in some embodiments, AE subsystem 400 may generate or
otherwise assign an SP key 157' for application 113' and may
provide such an SP key 157' to SP subsystem 200 (e.g., via path
85). Alternatively, SP subsystem 200 may generate or otherwise
assign an SP key 157' for application 113' and may provide such an
SP key 157' to AE subsystem 400 (e.g., via path 85). Either SP
subsystem 200 or AE subsystem 400 may be responsible for management
of SP key 157', which may include the generation, exchange,
storage, use, and replacement of such a key. No matter how or where
such an SP key 157' may be generated and/or managed, both SP
subsystem 200 and AE subsystem 400 may store a version of SP key
157' (e.g., in a respective secure element of SP subsystem 200 and
AE subsystem 400). In some embodiments, such an SP key 157' may be
specifically associated with SP application 113', while, in other
embodiments, SP key 157' may be specifically associated with a
merchant of SP subsystem 200 such that SP key 157' may be
associated with multiple third party applications operated by the
same merchant of SP subsystem 200. A table 430 or any other
suitable data structure or source of information that may be
accessible to AE subsystem 400 may be provided for associating a
particular SP key 157' with a particular SP application 113' and/or
SP entity using SP ID 219 or otherwise (e.g., each one of security
subsystem 491 and 492 may include table 430). Table 430 may enable
AE subsystem 400 to determine and utilize an appropriate SP key
157' for providing a layer of security to any transaction
credential data communicated to SP subsystem 200 (e.g., host
transaction credential data that may include payment credential
data native to host device 100) for a financial transaction that
may involve client device 100' interfacing with SP subsystem 200
via SP application 113' associated with key 157'. Device 100' may
be configured to access application 113' (e.g., from application
store 420 via communications path 95) and run application 113'
(e.g., with processor 102'). An SP key 157' may be associated with
a merchant's website (e.g., one or more URLs) or with the merchant
generally, rather than or in addition to a merchant's third party
application (e.g., application 113'). For example, a merchant of SP
subsystem 200 may work with AE subsystem 400 to associate a
particular merchant website or the merchant generally with a
particular SP key 157' within table 430 (e.g., associated a
particular SP ID 219 with a particular SP key), which may enable AE
subsystem 400 to determine and utilize an appropriate SP key 157'
for providing a layer of security to any host transaction
credential data (e.g., commerce credential data) communicated to SP
subsystem 200 (e.g., host transaction credential data that may
include payment credential data native to host device 100 for a
transaction that may involve client device 100' interfacing with SP
server 210 to conduct a transaction via an internet application or
web browser running on device 100' that may be pointed to a URL
whose target or web resource may be associated with that SP key
157'). Device 100' may be configured to access such a URL, for
example, from SP server 210 via communication path 15 (e.g., using
an internet application 113' on device 100'). In other embodiments,
an application 113' may not be associated with a specific SP
entity, SP subsystem 200, and/or SP key 157', but instead may be an
independent application available to device 100'. In some
embodiments, as shown, a similar application 113 with an SP key 157
may be provided for host device 100 (e.g., via AE subsystem 400),
where application 113 may be the same as or different than
application 113' and/or where key 157 may be the same as or
different than key 157'.
Description of FIG. 2
[0035] Referring now to FIG. 2, FIG. 2 shows a more detailed view
of electronic device 100 of system 1 described above with respect
to FIGS. 1-1B. As shown in FIG. 2, for example, device 100 may
include processor 102, memory 104, communications component 106,
power supply 108, input component 110, output component 112,
antenna 116, and NFC component 120. Device 100 may also include a
bus 118 that may provide one or more wired or wireless
communication links or paths for transferring data and/or power to,
from, or between various other components of device 100. Device 100
may also be provided with a housing 101 that may at least partially
enclose one or more of the components of device 100 for protection
from debris and other degrading forces external to device 100. In
some embodiments, one or more components of device 100 may be
combined or omitted. Moreover, device 100 may include other
components not combined or included in FIG. 2. For example, device
100 may include any other suitable components or several instances
of the components shown in FIG. 2. For the sake of simplicity, only
one of each of the components is shown in FIG. 2. One or more input
components 110 may be provided to permit a user to interact or
interface with device 100 and/or one or more output components 112
may be provided to present information (e.g., graphical, audible,
and/or tactile information) to a user of device 100. It should be
noted that one or more input components and one or more output
components may sometimes be referred to collectively herein as an
input/output ("I/O") component or I/O interface 114 (e.g., input
component 110 and output component 112 as I/O component or I/O
interface 114). For example, input component 110 and output
component 112 may sometimes be a single I/O component 114, such as
a touch screen, that may receive input information through a user's
touch of a display screen and that may also provide visual
information to a user via that same display screen. Processor 102
of device 100 may include any processing circuitry that may be
operative to control the operations and performance of one or more
components of device 100. For example, processor 102 may receive
input signals from input component 110 and/or drive output signals
through output component 112. As shown in FIG. 2, processor 102 may
be used to run one or more applications, such as an application 103
and/or an application 113. As one example, application 103 may be
an operating system application while application 113 may be a
third party application or any other suitable online resource
(e.g., an application associated with a merchant of SP subsystem
200). Moreover, as shown, processor 102 may have access to host
device identification information 119, which may be utilized by a
user of device 100 and/or AE subsystem 400 for providing
identification of device 100 to SP subsystem 200 (e.g., for
facilitating a transaction) and/or to AE subsystem 400 and/or
client device 100' (e.g., for facilitating secure communication
between devices 100 and 100').
[0036] NFC component 120 may be any suitable proximity-based
communication mechanism that may enable contactless proximity-based
transactions or communications between electronic device 100 and
device 100' and/or SP terminal 220. NFC component 120 may include
any suitable modules for enabling contactless proximity-based
communication between device 100 and such an SP terminal. As shown
in FIG. 2, for example, NFC component 120 may include an NFC device
module 130, an NFC controller module 140, and/or an NFC memory
module 150. NFC device module 130 may include an NFC data module
132, an NFC antenna 134, and an NFC booster 136. NFC data module
132 may be configured to contain, route, or otherwise provide any
suitable data that may be transmitted by NFC component 120 to an SP
terminal as part of a contactless proximity-based or NFC
communication. NFC data module 132 may be configured to contain,
route, or otherwise receive any suitable data that may be received
by NFC component 120 from an SP terminal as part of a contactless
proximity-based communication. NFC controller module 140 may
include at least one NFC processor module 142. NFC processor module
142 may operate in conjunction with NFC device module 130 to
enable, activate, allow, and/or otherwise control NFC component 120
for communicating an NFC communication between device 100 and an SP
terminal. NFC controller module 140 may include at least one NFC
processor module 142 that may be used to run one or more
applications, such as an NFC low power mode or wallet application
143 that may help dictate the function of NFC component 120. NFC
memory module 150 may operate in conjunction with NFC device module
130 and/or NFC controller module 140 to allow for NFC
communications between device 100 and SP subsystem 200. NFC memory
module 150 may be tamper resistant and may provide at least a
portion of secure element 145 of device 100. For example, such a
secure element may be configured to provide a tamper-resistant
platform (e.g., as a single-chip or multiple-chip secure
microcontroller) that may be capable of securely hosting
applications and their confidential and cryptographic data (e.g.,
applets 153 and keys 155) in accordance with rules and security
requirements that may be set forth by a set of well-identified
trusted authorities (e.g., an authority of a credential issuer
subsystem and/or a financial institution subsystem and/or an
industry standard, such as GlobalPlatform).
[0037] As shown in FIG. 2, for example, NFC memory module 150 may
include one or more of an issuer security domain ("ISD") 152, SSDs
154a-154c (e.g., a service provider security domain ("SPSD"), a
trusted service manager security domain ("TSMSD"), credential SSD,
access SSD, etc.), which may be defined and managed by an NFC
specification standard (e.g., GlobalPlatform). For example, ISD 152
may be a portion of NFC memory module 150 in which a trusted
service manager ("TSM") or issuing financial institution (e.g.,
issuer subsystem 300) may store one or more keys (e.g., ISD key
156k) and/or other suitable information for creating or otherwise
provisioning one or more credentials (e.g., credentials associated
with various credit cards, bank cards, gift cards, access cards,
transit passes, digital currency (e.g., bitcoin and associated
payment networks), etc.) on device 100 (e.g., via communications
component 106), for credential content management, and/or security
domain management. A credential may include credential data (e.g.,
credential information 161a) that may be assigned to a
user/consumer and that may be stored securely on electronic device
100, such as a credit card payment number (e.g., a device primary
account number ("DPAN"), DPAN expiry date, CVV, etc. (e.g., as a
token or otherwise)). NFC memory module 150 may include at least
three SSDs 154 (e.g., first credential SSD 154a, second credential
SSD 154b, and access SSD 154c). For example, first credential SSD
154a and second credential SSD 154b may each be associated with a
respective specific credential (e.g., a specific credit card
credential or a specific public transit card credential provisioned
by issuer subsystem 300) that may provide specific privileges or
payment rights to electronic device 100, while access SSD 154c may
be associated with a commercial or administration entity (e.g., an
entity of AE subsystem 400, which may be a controlling entity for
device 100) that may control access of device 100 to a specific
credential of another SSD (e.g., first SSD 154a or second SSD
154b), for example, to provide specific privileges or payment
rights to electronic device 100. Each SSD 154 may include and/or be
associated with at least one applet 153 (e.g., SSD 154a with applet
153a and SSD 154b with applet 153b). For example, an applet 153 of
an SSD 154 may be an application that may run on a secure element
of NFC component 120 (e.g., in a GlobalPlatform environment). A
credential applet 153 may include or be associated with credential
information 161 (e.g., information 161a of applet 153a and/or
information 161b of applet 153b). Each SSD 154 and/or applet 153
may also include and/or be associated with at least one of its own
keys 155 (e.g., applet 153a with at least one access key 155a and
at least one credential key 155a', and applet 153b with at least
one access key 155b and at least one credential key 155b').
[0038] 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.
[0039] Security features may be provided for enabling use of NFC
component 120 that may be particularly useful when transmitting
confidential payment information, such as credit card information
or bank account information of a credential, from electronic device
100 to SP subsystem 200 (e.g., via AE subsystem 400 and/or via
device 100'). Such security features also may include a secure
storage area that may have restricted access. For example, user
authentication via personal identification number ("PIN") entry or
via user interaction with a biometric sensor may need to be
provided to access the secure storage area. As an example, access
SSD 154c may leverage applet 153c to determine whether such
authentication has occurred before allowing other SSDs 154 (e.g.,
credential SSD 154a or credential SSD 154b) to be used for
communicating its credential information 161. In certain
embodiments, some or all of the security features may be stored
within NFC memory module 150. Further, security information, such
as an authentication key, for communicating commerce credential
data with SP subsystem 200 may be stored within NFC memory module
150. In certain embodiments, NFC memory module 150 may include a
microcontroller embedded within electronic device 100. As just one
example, applet 153c of access SSD 154c may be configured to
determine intent and local authentication of a user of device 100
(e.g., via one or more input components 110, such as a biometric
input component) and, in response to such a determination, may be
configured to enable another particular SSD for conducting a
payment transaction (e.g., with a credential of credential SSD
154a).
Description of FIG. 2A
[0040] Referring now to FIG. 2A, FIG. 2A shows another detailed
view of a portion of device 100 of system 1 described above with
respect to FIGS. 1-2. As shown in FIG. 2A, for example, a secure
element 145 of NFC component 120 may include SSD 154a, which may
include or be associated with applet 153a, credential information
161a, access key 155a, and/or credential key 155a', and SSD 154b,
which may include or be associated with applet 153b, credential
information 161b, access key 155b, and/or credential key 155b'. In
some embodiments, each one of SSDs 154a and 154b may be associated
with a particular TSM and at least one specific commerce credential
(e.g., a specific credit card credential or a specific public
transit card credential) that may provide specific privileges or
payment rights to electronic device 100 (e.g., SSD 154a may be
associated with a first host transaction credential provisioned
from first issuing subsystem 391 of issuer subsystem 300 and SSD
154b may be associated with a second host transaction credential
provisioned from second issuing subsystem 392 of issuer subsystem
300, as mentioned with respect to FIG. 1). Each SSD 154 may have
its own manager key 155 (e.g., a respective one of keys 155ak and
155bk) that may need to be activated to enable a function of that
SSD 154 for use by NFC device module 130. Each SSD 154 may include
and/or be associated with at least one of its own credential
applications or credential applets (e.g., a Java card applet
instances) associated with a particular commerce credential (e.g.,
credential applet 153a of SSD 154a may be associated with a first
commerce credential and/or credential applet 153b of SSD 154b may
be associated with a second commerce credential), where a
credential applet may have its own access key (e.g., access key
155a for credential applet 153a and/or access key 155b for
credential applet 153b) and/or its own credential key (e.g.,
credential key 155a' for credential applet 153a and/or credential
key 155b' for credential applet 153b), and where a credential
applet may need to be activated to enable its associated commerce
credential for use by NFC device module 130 as an NFC communication
(e.g., with SP terminal 220) and/or as an online-based
communication between device 100 and SP subsystem 200 (e.g., via AE
subsystem 400 and/or client device 100'). In some embodiments, a
credential key of a credential applet may be generated by issuer
subsystem 300 that may be responsible for such a credential and may
be accessible by that issuer subsystem 300 for enabling secure
transmission of that credential information of that applet between
secure element 145 and issuer subsystem 300. An access key of a
credential applet may be generated by AE subsystem 400 and may be
accessible by AE subsystem 400 for enabling secure transmission of
that credential information of that applet between secure element
145 and AE subsystem 400. As shown, each applet may include its own
unique application identifier ("AID"), such as AID 155a a of applet
153a and/or AID 155b a of applet 153b. For example, an AID may
identify a specific card scheme and product, program, or network
(e.g., MasterCard Cirrus, Visa PLUS, Interac, etc.), where an AID
may include not only a registered application provider identifier
("RID") that may be used to identify a payment system (e.g., card
scheme) or network (e.g., MasterCard, Visa, Interac, etc.) of the
credential associated with the AID but also a proprietary
application identifier extension ("PIX") that may be used to
differentiate between products, programs, or applications offered
by a provider or payment system of the credential associated with
the AID. Any suitable specification (e.g., a Java Card
specification) that may be operative to preside over firmware of
secure element 145 may be operative to ensure or otherwise force
the uniqueness of each AID on secure element 145 (e.g., each
credential instance on secure element 145 may be associated with
its own unique MD).
[0041] As shown in FIG. 2A, secure element 145 may include ISD 152,
which may include an ISD key 156k that may also be known to a
trusted service manager associated with that security domain (e.g.,
AE subsystem 400, as shown in FIG. 1B). ISD key 156k may be
leveraged by AE subsystem 400 and device 100 similarly to and/or
instead of access key 155a and/or access key 155b for enabling
secure transmissions between AE subsystem 400 and secure element
145. Moreover, as shown in FIG. 2A, various data may be
communicated between processor 102 and secure element 145. For
example, processor 102 of device 100 may be configured to run a
device application 103 that may communicate information with an
application 113 of processor 102 as well as secure element 145, an
I/O interface component 114a (e.g., for receiving I/O input data
115i and/or for transmitting I/O output data 115o), and/or
communications component 106. Moreover, as shown, processor 102 may
have access to device identification information 119, which may be
utilized for enabling secure communication between device 100 and
remote entities.
[0042] As shown in FIG. 2A, secure element 145 may include a
controlling authority security domain ("CASD") 158, which may be
configured to generate and/or otherwise include CASD access kit
158k (e.g., CASD keys, certificates, and/or signing modules). For
example, CASD 158 may be configured to sign certain data on secure
element 145 (e.g., using CASD access kit 158k) before providing
such data to another portion of device 100 (e.g., communications
component 106 for sharing with other subsystems of system 1).
Secure element 145 may include a contactless registry services
("CRS") applet or application 151 that may be configured to provide
local functionality to electronic device 100 for modifying a life
cycle state (e.g., activated, deactivated, locked, etc.) of certain
security domain elements and sharing certain output information
115o about certain security domain elements in certain life cycle
states with a user of device 100 (e.g., via a user I/O interface
114a), and may include a CRS list 151t that may maintain a list of
the current life cycle state of each security domain element on
secure element 145 and may be configured to share the life cycle
state of one or more security domain elements with an application
of device 100 (e.g., with any suitable application type, such as a
daemon, such as card management daemon ("CMD") application 113a
that may be miming as a background process inside an operating
system application 103 and/or a card management application 113b
(e.g., a Passbook.TM. or Wallet.TM. application by Apple Inc.)
and/or an SP application 113c (e.g., an SP application as may be
associated with SP key 157) and/or an identity services ("IDS")
application 113d, but that may not necessarily be under the control
of an interactive user of device 100), which in turn may provide
certain life cycle state information to a user of device 100 as
output information 115o via I/O interface 114a and a user interface
("UI") application (e.g., a UI of card management application
113b), which may enable a user to change a life cycle state of a
security domain element. CRS 151 may include a CRS access key 151k
that may also be known to a trusted service manager associated with
CRS 151 (e.g., AE subsystem 400, as shown in FIG. 1B) and may be
leveraged by AE subsystem 400 and device 100 similarly to and/or
instead of access key 155a and/or access key 155b for enabling
secure transmissions between AE subsystem 400 and secure element
145.
[0043] 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.TM. by Apple Inc., or
the like (e.g., FaceTime.TM. or Continuity.TM. by Apple Inc.),
and/or which may enable unique end-to-end encryption of messages
between IDS application 113d of host device 100 and a similar IDS
application of another device (e.g., an IDS application of client
device 100'). Such messages may be encrypted using unique
identifiers for one or both of the communicating devices (e.g.,
host device unique identifier 119 and/or client device unique
identifier 119') and/or for one or both of the specific users of
the communicating devices. Such messages may be communicated as a
local link or a true device to device (e.g., peer to peer)
communication, or may be communicated via AE subsystem 400 (e.g.,
via IDS subsystem 471 (e.g., using an identity management system
component 470)). Such messaging may be enabled as a low latency
solution that may allow data to be exchanged in structured formats
(e.g., protocol buffers) and/or unstructured formats. IDS
application 113d may be automatically awoken should it not be
running when an IDS message is received. IDS application 113d may
be operative to present an appropriate user interface and shepherd
requested data of a received IDS communication back to the
requesting device. IDS application 113d of a host device may be
operative to wake up card management daemon application 113a of
card management application 113b when an initial request may be
detected from a client device, which may allow the host device to
operate in a low-power or "sleep" mode. IDS application 113d may be
operative to manage a "time out" for such a request, such that,
should a request for payment from a client device go unactioned on
the host device for a period of time (e.g., 60 seconds, due to no
active host device user interaction responsive to such a request),
then IDS application 113d may be operative to make a determination
to terminate the request that may result in the host device
generating and delivering a "cancel" status back to the client
device, which may display an appropriate message (e.g., "time out
error") to a user of the client device.
Description of FIG. 3 and FIGS. 3A-3H
[0044] As shown in FIG. 3, and as described below in more detail, a
specific example of host electronic device 100 may be a handheld
electronic device, such as an iPhone.TM., where housing 101 may
allow access to various input components 110a-110i, various output
components 112a-112c, and various I/O components 114a-114d through
which device 100 and a user and/or an ambient environment may
interface with each other. For example, a touch screen I/O
component 114a may include a display output component 112a and an
associated touch input component 110f, where display output
component 112a may be used to display a visual or graphic user
interface ("GUI") 180, which may allow a user to interact with
electronic device 100. GUI 180 may include various layers, windows,
screens, templates, elements, menus, and/or other components of a
currently running application (e.g., application 103 and/or
application 113 and/or application 143) that may be displayed in
all or some of the areas of display output component 112a. For
example, as shown in FIG. 3, GUI 180 may be configured to display a
first screen 190 with one or more graphical elements or icons 182
of GUI 180. When a specific icon 182 is selected, device 100 may be
configured to open a new application associated with that icon 182
and display a corresponding screen of GUI 180 associated with that
application. For example, when the specific icon 182 labeled with a
"Merchant App" textual indicator 181 (i.e., specific icon 183) is
selected by a user of device 100, device 100 may launch or
otherwise access a specific third party merchant or SP application
and may display screens of a specific user interface that may
include one or more tools or features for interacting with device
100 in a specific manner (see, e.g., FIGS. 3A-3H for specific
examples of such displays of GUI 180 during use of any suitable
application (e.g., card management application 113b or SP
application 113c on host device 100 and/or SP application 113' on
client device 100') that may be used by a device user for making a
payment with a credential of NFC component 120 (e.g., a credential
of credential SSD 154b) of host device 100). As another example,
when the specific icon 182 labeled with a "Wallet" textual
indicator 181 (i.e., specific icon 185) is selected, device 100 may
launch or otherwise access a specific device application (e.g.,
card management application 113b of FIG. 3 (e.g., as a "Wallet" or
"Passbook" application) for managing various credentials on secure
element 145) and may display screens of a specific user interface
that may include one or more tools or features for interacting with
device 100 in a specific manner. For each application, screens may
be displayed on display output component 112a and may include
various user interface elements. For each application, various
other types of non-visual information may be provided to a user via
various other output components 112 of device 100.
[0045] While FIGS. 2-3 may be described with respect to host device
100, it is to be understood that one, some, or all of the
components of device 100 of any one or more of FIGS. 2-3 may
similarly be provided by client device 100'. In some embodiments,
one or more components of host device 100 may not be provided by
client device 100' (e.g., client device 100' may not include a
secure element with one or more credentials provisioned thereon,
while in other embodiments client device 100' may also include a
secure element with one or more native credentials provisioned
thereon and yet client device 100' may still facilitate a financial
transaction using a non-native credential (e.g., a credential
native to host device 100)). In some embodiments, client device
100' may not include a user interface component operative to
provide a GUI but may instead be considered a more automated
device. Host device 100 may not include a user interface component
operative to provide a GUI but may instead provide an audio output
component and mechanical or other suitable user input components
for selecting and authenticating use of a payment credential for
funding a transaction.
Description of FIG. 4
[0046] Referring now to FIG. 4, FIG. 4 shows further details with
respect to various embodiments of AE subsystem 400 of system 1. As
shown in FIG. 4, AE subsystem 400 may be a secure platform system
and may include a secure mobile platform ("SMP") broker component
440, an SMP trusted services manager ("TSM") component 450, an SMP
crypto services component 460, an identity management system
("IDMS") component 470, a fraud system component 480, a hardware
security module ("HSM") component 490, store component 420, and/or
one or more servers 410. In some embodiments, one or more
components of AE subsystem 400 may be combined or omitted.
Moreover, AE subsystem 400 may include other components not
combined or included in FIG. 4. For example, AE subsystem 400 may
include any other suitable components or several instances of the
components shown in FIG. 4. For the sake of simplicity, only one of
each of the components is shown in FIG. 4. One, some, or all
components of AE subsystem 400 may be implemented using one or more
processor components, which may be the same as or similar to
processor component 102 of device 100, one or more memory
components, which may be the same as or similar to memory component
104 of device 100, and/or one or more communications components,
which may be the same as or similar to communications component 106
of device 100. One, some, or all components of AE subsystem 400 may
be managed by, owned by, at least partially controlled by, and/or
otherwise provided by a single administration or commercial entity
(e.g., Apple Inc.) that may be distinct and independent from issuer
subsystem 300. The components of AE subsystem 400 may interact with
each other and collectively with issuer subsystem 300 and/or host
electronic device 100 and/or client electronic device 100' and/or
SP subsystem 200 for providing a new layer of security and/or for
providing a more seamless user experience. In some embodiments, ISD
subsystem 471, first security subsystem 491, and second security
subsystem 492 may each include its own processing component, memory
component, communications component, server 410, table 430, SMP
broker component 440, SMP TSM component 450, SMP crypto services
component 460, IDMS component 470, fraud system component 480, and
HSM component 490.
[0047] 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.
[0048] 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.TM. 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.TM. 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.TM. Store for selling/renting media to be
played by devices 100/100', the Apple App Store.TM. for
selling/renting applications for use on devices 100/100', the Apple
iCloud.TM. Service for storing data from devices 100/100' and/or
associating multiple user devices and/or multiple user profiles
with one another, the Apple Online Store for buying various Apple
products online, etc.). As just one example, store 420 may be
configured to manage and provide an application 113 to device 100
(e.g., via communications path 65), where application 113 may be
any suitable application, such as a banking application, an SP
application, an e-mail application, a text messaging application,
an internet application, a card management application, or any
other suitable communication application. Any suitable
communication protocol or combination of communication protocols
may be used by AE subsystem 400 to communicate data amongst the
various components of AE subsystem 400 (e.g., via at least one
communications path 495 of FIG. 4) and/or to communicate data
between AE subsystem 400 and other components of system 1 (e.g.,
issuer subsystem 300 via communications path 55 of FIG. 1B and/or
host device 100 via communications path 65 of FIG. 1B and/or SP
subsystem 200 via communications path 85 of FIG. 1B and/or client
device 100' via communications path 95 of FIG. 1B).
Description of FIG. 5
[0049] FIG. 5 is a flowchart of an illustrative process 500 for
conducting a transaction with a service provider subsystem (e.g.,
using an administration entity subsystem, a client electronic
device, and a host electronic device that includes a secure element
and a host credential application provisioned on the secure
element). At operation 502 of process 500, the administration
entity subsystem may receive, from the host electronic device, host
transaction data including host transaction credential data
generated by the host credential application on the secure element
of the host electronic device and transaction information including
a service provider identifier indicative of the service provider
subsystem (e.g., as described with respect to FIG. 6, second
security subsystem 492 may receive, from host device 100, host
transaction data 678 that may include host transaction credential
data 675/676 generated by second credential applet 153b provisioned
on secure element 145 and transaction data 666 indicative of SP
subsystem 200). At operation 504 of process 500, the administration
entity subsystem may obtain unique voucher data (e.g., as described
with respect to FIG. 6, second security subsystem 492 may obtain
unique voucher data 682). At operation 506 of process 500, the
administration entity subsystem may store the unique voucher data
against (or in association with (e.g., such that there may be a
relationship between (e.g., such that one can be resolved
against))) administration host transaction credential data that
includes the host transaction credential data of the received host
transaction data (e.g., as described with respect to FIG. 6, second
security subsystem 492 may store voucher data 682 against SP
credential data 681 that includes host transaction credential data
675/676). At operation 508 of process 500, the administration
entity subsystem may communicate the unique voucher data to at
least one of the host electronic device, the client electronic
device, and the service provider subsystem (e.g., as described with
respect to FIG. 6, second security subsystem 492 may communicate
voucher data 682 to at least one of host device 100, client device
100', and SP subsystem 200).
[0050] It is understood that the operations shown in process 500 of
FIG. 5 are only illustrative and that existing operations may be
modified or omitted, additional operations may be added, and the
order of certain operations may be altered. Further, in some
implementations, two or more operations may occur in parallel or in
a different sequence than described.
Description of FIG. 6
[0051] FIG. 6 is a flowchart of an illustrative process 600 for
conducting a transaction (e.g., a financial transaction) using an
electronic device with a geographically restricted non-native
payment credential. Process 600 is shown being implemented by host
device 100, client device 100', SP subsystem 200, issuer subsystem
300, and AE subsystem 400. However, it is to be understood that
process 600 may be implemented using any other suitable components
or subsystems. Process 600 may provide a seamless user experience
for securely and efficiently conducting a transaction with SP
subsystem 200 via client device 100' while using a transaction
credential from host device 100. To facilitate the following
discussion regarding the operation of system 1 for conducting a
transaction according to process 600 of FIG. 6, reference is made
to various components of system 1 of the schematic diagrams of
FIGS. 1-4, and to front views of screens 190-190h of FIGS. 3-3H
that may be representative of a graphical user interface of host
device (HD) 100 (e.g., a GUI as may be provided by card management
application 113b or SP application 113c or any suitable payment
application of host device 100) and/or that may be representative
of a graphical user interface of client device (CD) 100' (e.g., a
GUI as may be provided by an SP application 113' of client device
100' or any suitable payment application of client device 100')
during such a transaction. The operations described may be achieved
with a wide variety of graphical elements and visual schemes.
Therefore, the embodiments of FIGS. 3-3H are not intended to be
limited to the precise user interface conventions adopted herein.
Rather, embodiments may include a wide variety of user interface
styles.
[0052] Process 600 may begin at operation 601, where first host
access data 651 (e.g., first host access data 651 of FIG. 1B) may
be provisioned on secure element 145 of host device 100 by AE
subsystem 400. For example, a first access SSD (e.g., SSD 154c) may
be provisioned on secure element 145 of host device 100 as first
access data 651 from server 410 of first security subsystem 491 in
order to more securely enable host device 100 to conduct a
transaction with SP subsystem 200 using first security subsystem
491. As mentioned, access SSD 154c may be at least partially
provisioned on secure element 145 of host device 100 directly from
AE subsystem 400 (e.g., as host access data 651 via communication
path 65 between a server 410 of first security subsystem 491 and
communications component 106 of host device 100, which may then be
passed to secure element 145 from communications component 106
(e.g., via bus 118)). Host access data 651 via path 65 may be
provisioned on secure element 145 of host device 100 as at least a
portion or all of access SSD 154c and may include access applet
153c and/or access key 155c. In some implementations, operation 601
may be at least partially carried out when host device 100 is
initially configured (e.g., by AE subsystem 400 before host device
100 is sold to a user). Operation 601 may be at least partially
carried out in response to a user of host device 100 initially
setting up secure element 145 of NFC component 120. Host access
data 651 may include ISD key 156k for ISD 152 of secure element 145
and may be used in addition to or as an alternative to access key
155c for enabling secure transmissions between AE subsystem 400 and
host device 100. Host access data 651 may include CRS 151k of CRS
151 and/or CASD 158k of CASD 158 of secure element 145 of host
device 100 and may be used in addition to or as an alternative to
access key 155c and/or access key 155a and/or ISD key 156k for
enabling secure transmissions between AE subsystem 400 and host
device 100 (e.g., for use as any suitable commercial entity key or
shared secret between AE subsystem 400 and host device 100).
[0053] At operation 602, first host credential data 652 (e.g.,
credential data 652 of FIG. 1B) may be provisioned on secure
element 145 of host device 100 by first issuing subsystem 391 of
issuer subsystem 300, in some embodiments, via AE subsystem 400.
For example, such first host credential data 652 may be at least
partially provisioned on secure element 145 of host device 100
directly from first issuing subsystem 391 (e.g., via communication
path 75 of FIG. 1B between issuer subsystem 300 and device 100,
which may be passed to secure element 145 via communications
component 106). Such first host credential data 652 may be at least
partially provisioned on secure element 145 from first issuing
subsystem 391 via AE subsystem 400 (e.g., via communication path 55
of FIG. 1B between first issuing subsystem 391 and first security
subsystem 491 of AE subsystem 400, which may be passed to host
device 100 as first host credential data 652 via communication path
65 of FIG. 1B between server 410 of first security subsystem 491
and communications component 106 of host device 100, which may then
be passed to secure element 145 from communications component 106
(e.g., via bus 118)). First host credential data 652 via path 75
and/or via path 65 may be provisioned on secure element 145 of host
device 100 as at least a portion or all of first credential SSD
154a and may include credential applet 153a with credential
information 161a and/or credential key 155a' and/or key 155ak.
Operation 602 may be at least partially carried out when a user of
host device 100 selects a particular credential of first issuing
subsystem 391 to be provisioned on host device 100. In some
embodiments, first host credential data 652 may also include access
key 155a, which may be initially provided from AE subsystem 400 to
issuer subsystem 300 and/or may be added by AE subsystem 400. In
some embodiments, such first host credential data 652 may include
the primary account number as at least a portion of credential
information of a payment credential being provisioned (e.g.,
credential information 161a of applet 153a), an AID (e.g., AID 155a
a for applet 153a of the data of the payment credential being
provisioned at SSD 154a), an SSD identifier, and/or an SSD
counter.
[0054] Process 600 may also include operation 603, at which second
host access data 653 may be provisioned on secure element 145 of
host device 100 by AE subsystem 400. For example, a second access
SSD or additional data for first access SSD 154c may be provisioned
on secure element 145 of host device 100 as second access data 653
from server 410 of second security subsystem 492 of AE subsystem
400 in order to more securely enable host device 100 to conduct a
transaction with SP subsystem 200 using second security subsystem
492. Therefore, operation 603 may be similar to operation 601, but
may be carried out by second security subsystem 492 rather than by
first security subsystem 491. Additionally, process 600 may also
include operation 604, at which second host credential data 654 may
be provisioned on secure element 145 of host device 100 by second
issuing subsystem 392 of issuer subsystem 300, in some embodiments,
via AE subsystem 400. For example, such second host credential data
654 may be at least partially provisioned on secure element 145 of
host device 100 directly from second issuing subsystem 392 of
issuer subsystem 300 (e.g., via communication path 75 of FIG. 1B
between issuer subsystem 300 and device 100, which may be passed to
secure element 145 via communications component 106). Such second
host credential data 654 may be at least partially provisioned on
secure element 145 of host device 100 from second issuing subsystem
392 of issuer subsystem 300 via AE subsystem 400 (e.g., via
communication path 55 of FIG. 1B between second issuing subsystem
392 of issuer subsystem 300 and second security subsystem 492 of AE
subsystem 400, which may be passed to host device 100 as second
host credential data 654 via communication path 65 of FIG. 1B
between server 410 of second security subsystem 492 of AE subsystem
400 and communications component 106 of host device 100, which may
then be passed to secure element 145 from communications component
106 (e.g., via bus 118)). Second host credential data 654 via path
75 and/or via path 65 may be provisioned on secure element 145 as
at least a portion or all of second credential SSD 154b and may
include credential applet 153b with credential information 161b
and/or credential key 155b' and/or key 155bk. Operation 604 may be
at least partially carried out when a user of host device 100
selects a particular credential of second issuing subsystem 392 to
be provisioned on host device 100. In some embodiments, second host
credential data 654 may also include access key 155b, which may be
initially provided from AE subsystem 400 to issuer subsystem 300
and/or may be added by AE subsystem 400. In some embodiments, such
second host credential data 654 may include the primary account
number as at least a portion of credential information of a payment
credential being provisioned (e.g., credential information 161b of
applet 153b), an AID (e.g., AID 155b a for applet 153b of the data
of the payment credential being provisioned at SSD 154b), an SSD
identifier, and/or an SSD counter. Therefore, operation 604 may be
similar to operation 602, but may be carried out by second issuing
subsystem 392 with or without second security subsystem 492 rather
than by first issuing subsystem 391 with or without first security
subsystem 491.
[0055] Each one of the first credential data of operation 602 and
the second credential data of operation 604 provisioned on host
device 100 may include all data necessary to make a payment with
that credential, such as, for example, a primary account number
("PAN"), a card security code (e.g., a card verification code
("CVV")), PAN expiration date, name associated with the credential,
and the like, as well as other data that may be operative for host
device 100 to generate appropriate crypto data (e.g., any suitable
shared secret and any suitable cryptographic algorithm or cipher
whose functional output may be at least partially determined by the
shared secret). A "virtual" credential or virtual PAN or device PAN
("D-PAN") may be provisioned on host device 100 rather than (or in
addition to) the user's "actual" credential or actual PAN or
funding PAN ("F-PAN"). For example, once it is determined that a
credential is to be provisioned on host device 100, it may be
requested (e.g., by issuer subsystem 300, by AE subsystem 400,
and/or by a user of host device 100) that a virtual credential be
generated, linked to the actual credential, and provisioned on host
device 100 instead of the actual credential. Such creation and
linking of a virtual credential with an actual credential may be
performed by any suitable component of issuer subsystem 300. For
example, a network subsystem of issuer subsystem 300 (e.g., a
particular payment network subsystem 361 or 362 that may be
associated with the brand of the actual credential) may define and
store a virtual-linking table 312 (e.g., as shown in FIG. 1B) that
may create associations between the actual credential and a virtual
credential, such that anytime a virtual credential is utilized by
host device 100 for a transaction with SP subsystem 200 (e.g.,
after being provisioned on host device 100), the payment network
subsystem may receive an authorization or validation request or
otherwise attempt to validate any received data indicative of that
virtual credential (e.g., at operation 644 in response to receiving
data 692 at operation 642) and may conduct an analysis of that
validation attempt request in light of the actual credential
associated with the virtual credential as determined by table 312.
Alternatively, such a table may be accessible and/or similarly
leveraged by an appropriate issuing subsystem (e.g., issuing
subsystem 391 or 391) or any other suitable subsystem accessible by
issuer subsystem 300. By provisioning a virtual credential on host
device 100 rather than an actual credential, issuer subsystem 300
may be configured to limit the fraudulent activity that may result
when the virtual credential is intercepted by an unauthorized user,
as a payment network subsystem or issuing subsystem may only be
configured to utilize table 312 for linking the virtual credential
to the actual credential during certain transactions.
[0056] 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.
[0057] At operation 608, an SP's resource 658 (e.g., an SP's third
party resource 113' of FIG. 1B) may be accessed by client device
100'. As shown in FIG. 1B, a merchant's resource application 113'
may be loaded onto client device 100' from AE subsystem 400 (e.g.,
from an application store 420). For example, as shown in FIG. 3 but
with respect to host device 100, a user of client device 100' may
select a "Merchant App" icon 183 of a specific screen 190 of GUI
180 using touch screen input component 110f of I/O component 114a,
and this selection may be recognized by client device 100' as an
initiation event for providing the user with the ability to
interact with an SP's third party application 113'. Such an SP's
resource 658 may be accessed by client device 100' directly from SP
subsystem 200. In response to such a selection of an SP application
icon, a GUI may provide an interactive screen where client device
100' may enable the user to interact with application 113' to view
commercially available items from the SP for purchase.
Alternatively, at operation 608, client device 100' may access an
SP's resource 658 as a merchant's webpage from SP subsystem 200
(e.g., via SP server 210) using an internet application of client
device 100', which may also be selectable by an "Internet" icon
(i.e., specific icon 184) of specific screen 190 of GUI 180 of FIG.
3) for providing the user with the ability to interact with a
merchant's webpage rather than with an SP's third party
application. Alternatively, at operation 608, resource 658 may be
automatically accessed in any suitable way without active user
input (e.g., client device 100' may be operative to automatically
interact with resource 658 in response to detecting any suitable
event, such as an autonomous home appliance client device 100'
detecting that it is running low of a particular supply (e.g., a
washing machine client device 100' in response to detecting a low
supply of laundry detergent)).
[0058] At operation 610, client device 100' may receive potential
transaction data 660 from the accessed SP resource. For example, as
shown in FIG. 1B, potential transaction data 660 may be provided to
client device 100' from SP subsystem 200 (e.g., from SP server 210)
when client device 100' is interacting with the SP's resource 113'
(e.g., third party application or website or any other suitable
online resource (e.g., resource 658) of the SP). At least a portion
of potential transaction data 660 may be locally accessible by
client device 100' via application 113' local to client device 100'
(e.g., when application 113' is stored in a memory component or
being run by processor 102' of client device 100'), rather than the
data being actively sent to client device 100' from SP server 210
at operation 610. For example, when application 113' may be
initially stored on client device 100' (e.g., at operation 608 as
merchant's resource 658), at least some of potential transaction
data 660 may be generated by that initially stored application 113'
absent any additional information provided to client device 100' by
SP subsystem 200. Potential transaction data 660 may include any
suitable data indicative of any suitable characteristics of a
potential transaction to occur between a user of client device 100'
and an SP of SP subsystem 200, including, but not limited to, (i)
specific SP information, such as a unique SP identifier (e.g., SP
ID 219) (e.g., an acquiring bank SP identifier (e.g., an identifier
of acquiring bank subsystem 399) and/or an administration entity SP
identifier (e.g., SP ID 219)) and/or identification of the
particular SP resource being used (e.g., the particular SP
application 113') and/or identification of a location of SP
subsystem 200 (e.g., identification of a particular geographical
region (e.g., region 91 and/or 92) in which SP subsystem 200 may be
located or operative to handle any transaction credential data for
the transaction), (ii) specific transaction information, such as
identification of a specific currency to be used to pay for the
transaction (e.g., yen, pounds, dollars, etc.) and/or
identification of a specific amount of a currency to be paid for
the transaction and/or identification of the particular product or
service to be purchased or rented or otherwise paid for and/or
identification of a default or initial shipping address to be used,
(iii) information indicative of the one or more types of payment
methods acceptable to the SP for the transaction (e.g., a list of
payment cards that may be used for the purchase (e.g., China
UnionPay but not MasterCard)), and/or (iv) a unique SP-based
transaction identifier (e.g., any suitable data element, such as a
3- or 4-character alphanumeric string, that may be randomly or
uniquely generated by SP subsystem 200 for association with the
transaction being conducted). Such potential transaction data 660
may include any suitable number and types of data fields, with or
without associated data, that may be required or at least used for
completing a financial transaction, such as contact information
fields (e.g., telephone number, e-mail address, mailing address) of
a customer making the purchase, where some fields may be populated
and included as part of such potential transaction data 660, and/or
where some fields may not be populated as part of such potential
transaction data 660 but may be open and awaiting population during
process 600. Such potential transaction data 660 of operation 610
may be referred to herein as a PKPaymentRequest. Alternatively, as
mentioned, a user may not be actively interacting with client
device 100' in order for potential transaction data 660 associated
with SP subsystem 200 to be made available to client device 100' at
operation 610.
[0059] Potential transaction data 660 may define an SP resource's
request for client device 100' to produce a payment token for the
purchase of products and/or services and may encapsulate any
suitable information about the potential transaction including, for
example, information about the SP's payment processing
capabilities, an amount to pay, and the currency code. Potential
transaction data 660 may also include a list of one or more payment
networks (e.g., payment network(s) 361/362) that may be supported
by the SP such that client device 100' may be configured to
determine whether any of such listed one or more payment networks
has an authorized payment credential on client device 100' or on
any suitable host device available to client device 100'. In some
embodiments, once such potential transaction data 660 may be
accessed by client device 100', as shown in FIG. 3A, for example, a
GUI of client device 100' may provide screen 190a, where an SP's
resource may use transaction data 660 to show to a user of client
device 100' any suitable information associated with the potential
transaction, such as the name of the SP or merchant (e.g.,
"Merchant A") with information 307a, the name of the product (e.g.,
"Product B") with information 307b, the price (e.g., "Price C")
with information 307c, and/or initial shipping data (e.g., "Address
D") with information 307d. Potential transaction data 660 that may
be provided to client device 100' by SP subsystem 200 may be
indicative of such information 307a, 307b, 307c, and/or 307d. A
user of client device 100' may interact with device 100' and screen
190a to adjust certain portions of such information (e.g., shipping
address, etc.), which may require updated potential transaction
data to be generated and shared by SP subsystem 200 (e.g., at
another iteration of operation 610). As also shown in FIG. 3A and
described below in more detail, screen 190a may also include a
secure pay prompt 309. At least a portion of potential transaction
data 660 may be provided from SP subsystem 200 to client device
100' via communication path 15 of FIG. 1B and may be received by
communications component 106' of client device 100'. Communications
component 106' may pass this potential transaction data 660 on to
processor 102' (e.g., for displaying on screen 190a as part of a
user interface on client device 100' (e.g., for information
307a-307d)) and/or to NFC component 120'. For example, NFC
component 120' may utilize such potential transaction data 660 for
securely enabling a financial transaction between client device
100' and SP subsystem 200. In some embodiments, potential
transaction data 660 may be referred to as SP payment request data
and/or SP transaction request data and/or a uniform resource
locator ("URL") or any other suitable reference character string
and/or query string.
[0060] 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))).
[0061] 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.TM. and/or iMessage.TM.
or any other suitable identity services transport, which may be
operative to make associations between different devices and/or to
automatically determine the status and/or capabilities of various
devices (e.g., a family may have an account with AE subsystem 400
that may be associated with client device 100' as well as multiple
other devices, including host device 100). As one example, client
device 100' may send host availability request data 662 to IDS
subsystem 471 of AE subsystem 400 for requesting the status of all
other devices associated with an account of client device 100', and
IDS subsystem 471 of AE subsystem 400 may respond by obtaining the
status of one, some, or each one of such devices and sharing each
one of those statuses with client device 100' as host availability
response data 664, where a status may be indicative of the
availability of host device 100 and the identity of at least one
payment type available to host device 100. Each host device may
have its own settings with respect to such requests and potential
responses (e.g., a particular host device may be configured to only
respond to host availability request data 662 received from
particular client devices (e.g., only devices associated with the
same account at AE subsystem 400, only devices associated with
contacts in a contact application of that particular host device,
etc.)). Such requests and/or responses for enabling the
identification of one or more available payment sources at
operations 612 and 614 may be communicated in any suitable manner,
such as directly between client device 100' and host device 100, or
between client device 100' and IDS subsystem 471 of AE subsystem
400 and then between IDS subsystem 471 of AE subsystem 400 and host
device 100. For example, as shown in FIG. 1B, host availability
request data 662 may be communicated from client device 100' to
host device 100 (e.g., via communications path 99 using any
suitable communications protocol or via IDS subsystem 471 of AE
subsystem 400 (e.g., via communications path 95 and communications
path 65 using any suitable communications protocol(s))), and host
availability response data 664 may be communicated to client device
100' from host device 100 (e.g., via communications path 99 using
any suitable communications protocol or via IDS subsystem 471 of AE
subsystem 400 (e.g., via communications path 65 and communications
path 95 using any suitable communications protocol(s))) or from IDS
subsystem 471 of AE subsystem 400 (e.g., via communications path 95
using any suitable communications protocol).
[0062] Host availability request data 662 may be sent automatically
by client device 100' in response to receiving potential
transaction data 660 or periodically independent of the receipt of
such transaction data 660 or in response to a request made by a
user of client device 100' at any suitable time, such as in
response to a user of client device 100' interacting with the GUI
of screen 190a of FIG. 3A. For example, in response to a user
selection of secure pay prompt 309 of screen 190a of client device
100' in order to make a purchase from the SP according to the
details of potential transaction data 660, client device 100' may
generate and transmit host availability request data 662. Moreover,
as shown in FIG. 3B, client device 100' may be configured to
provide screen 190b in response to receiving selection of secure
pay prompt 309 of screen 190a of FIG. 3A and in response to
receiving any suitable host availability response data 664, which
may prompt a user to interact with client device 100' in one or
more ways to choose a specific payment source or credential that
may be available to client device 100' for making the purchase. For
example, as shown, screen 190b may include a payment source
selection prompt 311 that may enable a user to select one of
potentially multiple payment sources that may be available to
client device 100'. Payment source selection prompt 311 may only
include payment sources with credentials that are associated with
payment networks supported by the SP (e.g., as may be determined by
potential transaction data 660, as mentioned above) or may show all
payment sources available to client device 100' (e.g., all sources
associated with all AIDs received as host availability response
data 664) yet may make only those that are associated with
acceptable payment networks able to be selectable by a user.
Payment source selection prompt 311 may include any suitable
payment sources, including, but not limited to, any suitable
payment credentials native to a secure element of client device
100' (not shown), any suitable non-native payment credentials of
any available payment sources (e.g., payment method X of host
device 1 as may be indicated by payment option identifier 311a of
prompt 311 (e.g., the first host credential of SSD 154a of host
device 100 provisioned from first issuing subsystem 391), payment
method Y of host device 1 as may be indicated by payment option
identifier 311b of prompt 311 (e.g., the second host credential of
SSD 154b of host device 100 provisioned from second issuing
subsystem 392), etc.) as may be identified by any received host
availability response data 664, and/or any suitable other payment
source that may be identified by client device 100' (e.g., payment
option identifier 311c of prompt 311 that may enable a user of
client device 100' to manually enter or select any suitable remote
host device for requesting payment (e.g., by entering any suitable
unique host device identifier, such as a telephone number or e-mail
address of a host device, which may be used by client device 100'
to communicate with that remote host, or by selecting a host device
that may be identified in a contacts application of client device
100' or that may be identified as a last selected host device or
otherwise)). In some embodiments, payment source selection prompt
311 may be operative to enable a user of client device 100' to
select a particular payment type of a particular payment source
(e.g., payment method (PM) X (e.g., "a MasterCard credential from
Wells Fargo with an account number ending in 0096") of host device
1 of identifier 311a (e.g., the first host credential of SSD 154a
of host device 100 provisioned from first issuing subsystem 391) or
payment method (PM) Y (e.g., "a China UnionPay credential from the
People's Bank of China with an account number ending in 2587") of
host device 1 of identifier 311b (e.g., the second host credential
of SSD 154b of host device 100 provisioned from second issuing
subsystem 392)) and/or payment source selection prompt 311 may be
operative simply to enable a user of client device 100' to select a
particular payment source (e.g., host device 1 or host device 2)
but not a particular payment type of that payment source (e.g.,
depending on the specificity of host availability response data 664
received by client device 100' or depending on any other suitable
data available to client device 100'). In some embodiments, host
availability response data 664 may be based on cached payment
availability data known by AE subsystem 400 and/or by client device
100' for a particular host device 100 that may currently be
non-responsive (e.g., a host device 100 that may be turned off and
not responsive to the discovery request of operation 612 but may be
known to include a suitable payment credential), where an
identifier (not shown) of prompt 311 may include identification of
that host device and its known payment credential as well as
information alerting the user of client device 100' that such a
host device is currently turned off (e.g., "HD2 must be turned on
to enable use of HD2's PM Z").
[0063] Next, at operation 616 of process 600, client device 100'
may communicate transaction request data 666 (e.g., payment request
data) to at least one particular host device 100. A target host
device 100 of transaction request data 666 may be determined in any
suitable manner by client device 100', such as automatically or in
response to a user selection with respect to payment source
selection prompt 311 of FIG. 3B, and/or such a determination may be
made based on any suitable information, such as potential
transaction data 660 and/or host availability response data 664.
For example, a user of client device 100' may select the target
host device 100 for transaction request data 666 of operation 616
from a list of potential target host devices of payment source
selection prompt 311 of FIG. 3B that may be provided based on the
identification of one or more payment sources using host
availability response data 664 (e.g., "HD1's PM X" of identifier
311a and "HD1's PM Y" of identifier 311b), or client device 100'
may identify any suitable particular target host device in any
suitable manner (e.g., a host device in a contacts application of
client device 100' and/or a host device identified manually by a
user of device 100' (e.g., by a telephone number or e-mail address
or any suitable unique device identifier of the host device (e.g.,
using the option of identifier 311c of FIG. 3B))). As just one
particular example, as shown in FIG. 3C, client device 100' may be
configured to provide screen 190c in response to receiving user
selection of "HD1's PM Y" of identifier 311b of payment source
selection prompt 311 of FIG. 3B (e.g., a China UnionPay credential
from the People's Bank of China of geographical region 92 of FIG. 1
(e.g., the second host credential of SSD 154b of host device 100
provisioned from second issuing subsystem 392)). Screen 190c of
FIG. 3C may prompt a user to interact with client device 100' in
one or more ways to request non-native host device payment for the
selected payment source of payment source selection prompt 311 of
FIG. 3B as indicated by payment method identifier 313 of FIG. 3C,
such as by user selection of request host device (HD) payment
prompt 315 of FIG. 3C. Alternatively, the target host device 100
for transaction request data 666 of operation 616 may be
automatically selected by client device 100' in response to any
identification data obtained by client device 100' at operation 614
(e.g., client device 100' may be customized or otherwise configured
to select one host device from a group of available host devices
based on any suitable characteristic (e.g., the host device with
the shortest distance to client device 100' or the host device with
the highest priority of the available host devices (e.g., as may be
determined by a default or customized setting of an application of
client device 100' in combination with host availability response
data 664 or otherwise), etc.). Therefore, transaction request data
666 of operation 616 may be automatically generated and transmitted
by client device 100' without any user interaction with client
device 100' (e.g., based on transaction data 660 and/or any host
availability response data 664 and/or any application parameters
(e.g., of any application running on client device 100')). Such
transaction request data 666 of operation 616 may be communicated
in any suitable manner at operation 616, as shown in FIG. 1B, such
as directly between client device 100' and host device 100 (e.g.,
via communications path 99 using any suitable communications
protocol), or between client device 100' and IDS subsystem 471 of
AE subsystem 400 (e.g., via communications path 95 using any
suitable communications protocol) and then between IDS subsystem
471 of AE subsystem 400 and host device 100 (e.g., via
communications path 65 using any suitable communications protocol).
Client device 100' may be operative to maintain a local cache
(e.g., on memory local to client device 100') of the various
payment types available to the various host devices associated with
client device 100'(e.g., based on data that may be routinely
collected by AE subsystem 400 and shared with client device 100' at
any suitable times), such that a specific dedicated discovery
request and response cycle may not be necessary when a payment
request is to be made. When one or more available payment types
from native credentials (e.g., on client device 100') and/or
non-native credentials (e.g., on one of more host devices 100) are
determined by client device 100', automatic selection of a
particular payment source and/or prioritization amongst various
payment sources for selection by a user of client device 100' may
be enabled. For example, client device 100' may be operative to
automatically select or prioritize one of at least one available
payment sources to be targeted and identified in a payment request
based on the distance between client device 100' and the host
device that may include the selected payment source (e.g., the host
device with an available payment source that is closest to the
client device (e.g., as may be determined from distance data in a
discovery response or via other suitable communication related data
(e.g., detected communicated signal strength BlueTooth, etc.)) may
be automatically selected to facilitate ease of use to the user of
the client device). Client device 100' may be operative to
automatically select or prioritize one of at least one available
payment sources to be targeted and identified in a payment request
based on the payment sources supported by the SP (e.g., a
corporate-branded payment credential may be prioritized for use in
a transaction with that corporation (e.g., a Disney-branded Visa
card may be prioritized or selected for use in a transaction with a
Disney SP, where such a preference may be expressed by the SP and
made available to client device 100')).
[0064] 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.
[0065] In response to receiving transaction request data 666 from
client device 100' at operation 616, a target host device 100 may
be operative to provide any suitable information to a user of host
device 100 for acting on the payment request. For example, as shown
in FIG. 3D, a push notification screen 190d may be provided by a
GUI of host device 100 that may be operative to indicate to a user
of host device 100 that a client payment request has been received
with an identifier 317 and may include an option 321 that may be
selectable to hide the notification and/or an option 319 that may
be selectable to view more details about the notification. For
example, in response to user selection of view more details option
319 or in lieu of screen 190d, the GUI of host device 100 may
proceed to a screen 190e of FIG. 3E that may enable a user of host
device 100 to respond to the client payment request in one or more
suitable ways. Screen 190e of FIG. 3E may prompt a user of host
device 100 to interact with host device 100 in one or more ways to
choose a specific credential native to host device 100, or
non-native to device 100 but accessible to device 100 through a
process similar to process 600, for making the purchase. As shown
in FIG. 3E, in addition to identifiers 307a-307d that may identify
to a user of host device 100 the same merchant, product, price, and
shipping information for the potential transaction as identified to
the user of client device 100' on screen 190c of FIG. 3C prior to
and/or at operation 616, screen 190e may include a credential
selection prompt 323 that may enable a user to select one of
potentially multiple credentials that may be provisioned on host
device 100 (e.g., the credential of credential SSD 154b) for use in
funding the potential transaction. Prompt 323 may only include
credentials native to host device 100 that are associated with
payment networks supported by the SP (e.g., as may be determined by
transaction request data 666, as mentioned above). As shown, prompt
323 may include a first native payment credential option 325
associated with "Credential X" of host device 100 and a second
native payment credential option 327 associated with "Credential Y"
of host device 100, each of which may be acceptable for use by SP
subsystem 200 of the potential transaction (e.g., based on any
suitable portion of transaction request data 666), and/or where any
suitable technique may be used to identify the credential selected
by client device 100' if applicable (e.g., an "*" may be provided
next to second native payment credential option 327 associated with
"Credential Y" if that "PM Y" may have been selected by client
device 100' (e.g., at screen 190b of FIG. 3B) and specifically
identified in transaction request data 666). As shown in FIG. 3F,
the GUI of host device 100 may be configured to provide screen 190f
in response to receiving host device user selection of a particular
credential from credential selection prompt 323 of screen 190e of
FIG. 3E (e.g., "Credential Y"). Screen 190f of FIG. 3F may identify
that selected or automatically identified default credential with
credential identifier information 329 and may prompt a user of host
device 100 to interact with host device 100 in one or more ways to
authenticate the user and its intent to utilize the selected
credential. This may include prompting the user (e.g., with an
authentication prompt 331) to enter user authentication via
personal identification number ("PIN") entry or via user
interaction with a biometric sensor in order to access the secure
element of host device 100 and, thus, the credential to be used for
the purchase.
[0066] 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.
[0067] If a user of host device 100 is willing and able to select
or confirm a particular payment credential for use in funding the
potential transaction in response to transaction request data 666
received at operation 616, process 600 may proceed to operation
625, at which device 100 may receive intent and authentication by a
user of host device 100 to utilize a specific credential for
carrying out the potential transaction for a particular merchant,
product, price, and shipping destination based on potential
transaction data 666 (e.g., through user selection of
authentication prompt 331 of FIG. 3F). Access SSD 154c may leverage
applet 153c of host device 100 to determine whether such
authentication has occurred before allowing other SSDs 154 (e.g.,
credential SSD 154b) to be used for enabling its credential
information in a commerce credential data communication. As just
one example of operation 625, applet 153c of access SSD 154c may be
configured to determine intent and local authentication of a user
of host device 100 (e.g., via one or more input components 110,
such as a biometric input component 110i of FIG. 3, as may be used
by a user interacting with any application of device 100 (e.g.,
card management application 113b of host device 100)) and, in
response to such a determination, may be configured to enable
another particular SSD for conducting a payment transaction (e.g.,
with the second host transaction credential of second credential
SSD 154b). In some embodiments, after such a determination, but
before such enablement, a GUI of host device 100 may be configured
to provide another screen (e.g., similar to screen 190g of FIG. 3G)
that may prompt a user of host device 100 (e.g., with a prompt
similar to prompt 333 of FIG. 3G) to interact with host device 100
in one or more ways to finally initiate payment using the selected
and authenticated credential.
[0068] 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.TM.
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.TM. by
Apple Inc. (e.g., seamless sharing of application data between
devices) or AirDrop.TM. by Apple Inc. (e.g., a secure ad hoc
transfer protocol) or Continuity.TM. 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.
[0069] Next, once intent and authentication has been received at
operation 625 for a particular host transaction credential in
response to receiving particular payment request data (e.g.,
transaction request data 666 at operation 616), operations 626-628
of process 600 may include host device 100 generating, encrypting,
and transmitting host transaction data 678 for use by AE subsystem
400 (e.g., second security subsystem 492). Once the particular host
transaction credential of credential SSD 154b on secure element 145
of host device 100 has been selected, authenticated, and/or enabled
for use in a transaction (e.g., at operation 625), secure element
145 of host device 100 (e.g., processor module 142 of NFC component
120) may generate and encrypt certain credential data of that
selected host transaction credential for use by AE subsystem 400.
For example, host transaction credential data 675 of credential SSD
154b (e.g., payment card data of SSD 154b, as may be associated
with selected "Credential Y" (e.g., a China UnionPay credential
from the People's Bank of China of geographical region 92 of FIG. 1
provisioned from second issuing subsystem 392)), such as token data
and crypto data, may be generated and/or at least partially
encrypted with credential key 155b' at operation 626 as host
transaction credential data 676 to include at least token data and
crypto data, such that such encrypted host transaction credential
data 676 may only be decrypted by an entity with access to that
credential key 155b' (e.g., second issuing subsystem 392 of issuer
subsystem 300) for accessing host transaction credential data 675.
Such host transaction credential data 675 may include any suitable
data that may be operative to securely prove proper ownership of
the particular secure element credential of host device 100 (e.g.,
the credential of SSD 154b) and necessary to make a payment with
that credential, including, but not limited to, (i) token data
(e.g., an actual FPAN or virtual DPAN, PAN expiry date, a card
security code (e.g., a card verification code ("CVV")), and/or name
and/or address associated with the credential of credential
information 161b of SSD 154b) and (ii) crypto data (e.g., a
cryptogram that may be generated by secure element 145 using a
shared secret of SSD 154b and issuer subsystem 300 (e.g., key 155b'
of second issuer subsystem 392) and any other suitable information
(e.g., some or all of the token data, information identifying host
device 100, information identifying some or all of potential
transaction data 660 of operation 610 and/or of transaction request
data 666 of operation 616, such as cost and/or currency, any
suitable counter values, nonce, etc.) that may be available to host
device 100 and that may also be made available to issuer subsystem
300 (e.g., at operation 642 or otherwise) for independently
generating the crypto data using the shared secret). In some
embodiments, once some or all of that host transaction credential
data 675 of credential SSD 154b has been encrypted with credential
key 155b' at operation 626 as encrypted host transaction credential
data 676, that encrypted host transaction credential data 676 or
host transaction credential data 675, either alone or along with at
least a first portion if not all of the applicable transaction
request data 666 (e.g., a portion or all of potential transaction
data 660 that may include identification of the SP, identification
of the price amount, identification of the currency and/or shipping
and/or product, and/or unique SP-based transaction identifier
and/or unique client-based transaction identifier and/or unique
client-based payment request and/or the like) and/or any other
suitable information (e.g., any information identifying host device
100 itself (e.g., host device identifier 119), any specific host
device-based transaction identifier, and/or the like), may be
encrypted by access information (e.g., by access key 155b of SSD
154b, access key 155c of access SSD 154c, ISD key 156k, and/or CRS
151k and/or signed by CASD 158k) at operation 627 as encrypted host
transaction credential data 677. For example, secure element 145 of
host device 100 (e.g., processor module 142 of NFC component 120)
may use access information to encrypt not only an identification of
the merchant from data 660/666 (e.g., identification of the SP or
its resource being used for the purchase, such as application
113'), but also the identification of the amount of the purchase
and/or currency code from data 660/666, as well as the encrypted
host transaction credential data 675 of SSD 154b (e.g., encrypted
host transaction credential data 676) into encrypted host
transaction credential data 677. In some embodiments, host
transaction credential data 675 of credential SSD 154b (e.g.,
payment card data of SSD 154b, such as token data and crypto data
may be generated but not encrypted with a credential key (e.g., at
operation 626 as data 676) before being encrypted with an
administration entity key or access key (e.g., at operation 627 as
data 677), and, instead, such host payment transaction data 675 may
be encrypted with an administration entity key or access key (e.g.,
at operation 627 as data 677), whereby in such embodiments, any
future reference to data 676 may also be in reference to data 675
that is not encrypted with any credential key. In some embodiments,
such an administration entity key or access key may be an
administration entity public key associated with a scheme of AE
subsystem 400 and of which AE subsystem 400 may have access to an
associated administration entity private key. AE subsystem 400 may
provide such an administration entity public key to issuer
subsystem 300 and issuer subsystem 300 may then share that
administration entity public key with host device 100 (e.g., when
provisioning credential data on host device 100 (e.g., at operation
652/654 of process 600)).
[0070] 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.
[0071] As mentioned, certain host transaction credentials may be
governed by one or more geographic restrictions that may be
operative to restrict the types or location of subsystems that may
be allowed to handle data from those restricted host transaction
credentials. For example, as described with respect to FIG. 1, the
second host transaction credential of credential SSD 154b (e.g.,
payment card data of SSD 154b of selected "Credential Y" (e.g., a
China UnionPay credential from the People's Bank of China of
geographical region 92 provisioned on host device 100 from second
issuing subsystem 392 (e.g., alone or in combination with network
subsystem 362) at operations 603/604)) may be a geographically
restricted transaction credential that may be restricted from being
handled by any server or component of AE subsystem 400 that is
physically located in a different geographical region than the
geographical region (e.g., second geographical region 92) in which
the credential issuing subsystem of the geographically restricted
transaction credential is located. Therefore, the host transaction
credential data of host transaction data 678 as generated by that
restricted host transaction credential should not be handled by
either IDS subsystem 471 or first security subsystem 491 of AE
subsystem 400 but may be handled by second security subsystem 492
of AE subsystem 400. Any suitable target identification data may be
accessible to host device 100 in order for device 100 to be enabled
to determine that second security subsystem 492 is an appropriate
target security subsystem of AE subsystem 400 for receiving and
handling restricted host transaction data 678 at operation 628 in
accordance with the geographic restriction. Such target
identification data may include, but is not limited to, a URL or
other data that may be an address of the target subsystem, such as
a URL from or otherwise associated with the selected credential SSD
154b (or applet 153b) of host device 100 that is generating the
restricted host transaction credential data (e.g., a URL that may
be defined by the subsystem(s) that provisioned the SSD credential
on device 100 (e.g., as a portion of data 653 and/or data 654)
and/or a URL stored in a pass available to processor 102 of host
device 100 associated with the credential and/or a URL stored at
device 100 through any other mechanism (e.g., due to a firmware or
any other software update on device 100 (e.g., from AE subsystem
400))) and/or as a URL that may be derived from a portion of token
data of host transaction credential data 675 (e.g., such token data
may include a PAN of credential information 161b or AID of SSD
154b, whereby at least a portion of such a PAN or AID may be
operative to identify to device 100 (e.g., in combination with any
other suitable data available to device 100 (e.g., data in a look
up table or other up-to-date regulatory information (e.g., that may
be regularly downloaded to device 100') with respect to geographic
restrictions on certain PAN or AID types)) the URL of the
appropriate target security subsystem of AE subsystem 400 (e.g., an
appropriate security subsystem of AE subsystem 400 associated with
that PAN/AID (e.g., a certain subset of alphanumeric characters of
a PAN/AID may be associated with a particular security subsystem
that may be identifiable by device 100 (e.g., using a look-up
table))). Moreover, in addition to identifying an appropriate
target security subsystem of AE subsystem 400 for receiving and
handling restricted host transaction data 678 at operation 628,
device 100 may be operative to generate and include within host
transaction data 678 an instruction that may be operative to
instruct that identified target security subsystem not only to
generate SP-secured host transaction credential data based on
encrypted host transaction credential data 676/677 of host
transaction data 678 (e.g., to generate SP credential data 681 at
operation 631) but also to generate or otherwise access a unique
host transaction voucher in conjunction with generating the
SP-secured host transaction credential data and then store such a
unique host transaction voucher against the SP-secured host
transaction credential data (e.g., to store voucher data 682
indicative of a voucher against SP credential data 681 at operation
632). This instruction may be any suitable data that may be
configured to be appropriately processed by the target security
subsystem of AE subsystem, and device 100 may be operative to
determine the need for such an instruction using any suitable data
that may or may not be the same as any of the target identification
data. In some embodiments, the URL of the target security subsystem
identified by device 100 from the target identification data may be
specifically tied to an appropriate voucher storing process of the
target security subsystem (e.g., the URL used by device 100 to
target the communication of host transaction data 678 to second
security subsystem 492 at operation 628 may be a specific URL at
which any received host transaction data may be processed by second
security subsystem 492 for storing voucher data against SP
credential data (e.g., secured host credential data of the received
host transaction data) rather than just returning such SP
credential data to host device 100, whereas another URL of second
security subsystem 492 may be operative to not store a voucher for
received host transaction data). In some embodiments, any suitable
data portion of request data 666 may be indicative of the use of
IDS subsystem 471 for communication of data between host device 100
and client device 100' and may be used as voucher-indication data
by host device 100 in order to configure host device 100 to
generate host transaction data 678 that may be operative to request
a voucher rather than SP-secured host transaction credential data,
so that the geographic restriction(s) of the host transaction
credential may not be violated by future communication between host
device 100 and client device 100' during process 600 (e.g., at
operation 634). In some embodiments, AE subsystem 400 (e.g.,
security subsystem 492) may be operative to process any suitable
host transaction data 678 to determine whether or not a voucher
(e.g., voucher data 682) or secured host transaction credential
data (e.g., SP credential data 681) ought to be returned to host
device 100 or otherwise provided to another entity of subsystem
1.
[0072] 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.
[0073] 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.
[0074] 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.TM.
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).
[0075] 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'.
[0076] 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.
[0077] 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).
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] Therefore, use of redemption criteria information may be
operative to enable AE subsystem 400 to provide a validation check
after receiving host transaction data 678 at operation 628 and
after receiving redemption request data 686 at operation 636 but
before redeeming a voucher for communicating host transaction
credential data as redeemed host transaction data 688 to client
device 100' at operation 638. AE subsystem 400 may be operative to
process any suitable redemption criteria information in combination
with any other suitable information accessible by AE subsystem 400
in order to determine whether a transaction ought to be enabled for
funding. Such redemption criteria information may be generated by
any suitable entity associated with the transaction and may be
communicated to AE subsystem 400 in any suitable communication,
including communications not shown by FIG. 6. Therefore, if AE
subsystem 400 determines that a particular transaction is no longer
viable or does not meet any suitable redemption criteria, AE
subsystem 400 may prevent the transaction from being funded by not
redeeming a voucher and may update or delete any data associated
with the transaction (e.g., AE subsystem 400 may delete the voucher
or any host transaction credential data stored against the voucher
at AE subsystem 400 and/or edit at least a portion of any
redemption criteria information associated with the transaction).
However, if, at operations 637 and 638, AE subsystem 400 is able to
enable a transaction for funding, AE subsystem 400 may be satisfied
that the transaction is between known devices and/or a known SP
and/or meets any suitable requirements of any suitable redemption
criteria.
[0084] At operation 640, after receiving redeemed host transaction
data 688 from AE subsystem 400 at operation 638, client device 100'
may forward on at least the host transaction credential data of
redeemed host transaction data 688 (e.g., encrypted SP credential
data 681) to SP subsystem 200 as client transaction data 690 (e.g.,
via communications path 15 or as a contactless proximity-based
communication 5). In some embodiments, between operation 634 and
operation 640, a GUI of client device 100' may be configured to
provide another screen 190g of FIG. 3G that may prompt a user of
client device 100' with a prompt 333 to interact with client device
100' in one or more ways to review and reject and/or finally
initiate payment using the selected and authenticated host
transaction credential from host device 100 (e.g., as encrypted
host transaction credential data 676 encrypted within encrypted SP
credential data 681 of redeemed host transaction data 688).
Alternatively, operations 636-638 may occur transparently to a user
of client device 100'. Alternatively, redeemed host transaction
data 688 with SP credential data 681 may be communicated to SP
subsystem 200 from AE subsystem 400 without being communicated via
client device 100'. Operations 631 and 638 may be operative to
ensure that credential data transmitted from the AE subsystem 400
as part of redeemed host transaction data 688 (e.g., token data
and/or crypto data of encrypted SP credential data 681) may be
encrypted in such a way that it cannot be decrypted by a portion of
client device 100'. That is, credential data of redeemed host
transaction data 688 (e.g., token data and/or crypto data of
encrypted merchant credential data 681) may be encrypted with an SP
key (e.g., SP key 157') that may not be exposed to or otherwise
accessible by any portion of client device 100'. Moreover,
credential data of redeemed host transaction data 688 (e.g., token
data and/or crypto data of encrypted SP credential data 681) may be
encrypted with a credential key 155b' that may not be exposed to or
otherwise accessible by any portion of client device 100'.
[0085] 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.
[0086] 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).
[0087] Once SP credential data 681 including host transaction
credential data 675/676 is received by SP subsystem 200 (e.g., as
client transaction data 690 at operation 640), process 600 may also
include operation 642 at which SP subsystem 200 may be configured
to generate and transmit SP transaction data 692 to issuer
subsystem 300 (e.g., via acquiring bank subsystem 399 (e.g., via
communication path 25 between SP subsystem 200 and acquiring bank
subsystem 399 of FIG. 1B and communication path 35 between
acquiring bank 399 and issuer subsystem 300) or directly to second
issuer subsystem 392 of issuer subsystem 300), where data 692 may
include payment information and an authorization request that may
be indicative of the secured host payment credential data of host
device 100 (e.g., host transaction credential data 675/676 of data
681) and the SP's purchase price for the product or service (e.g.,
as may be included in or otherwise associated with client
transaction data 690 or as may be otherwise associated with the
transaction as known by SP subsystem 200 (e.g., by potential
transaction data 660 (e.g., based on a unique transaction
identifier))). For example, at operation 642, SP subsystem 200 may
leverage its known SP key 157' to at least partially decrypt SP
credential data 681 of client transaction data 690 such that SP
transaction data 692 may include the secured host payment
credential data of credential SSD 154b encrypted with its
credential key 155b' (e.g., encrypted payment credential data 676)
but not with a key that is not available to issuer subsystem 300
(e.g., SP key 157').
[0088] Next, at operation 644, when second issuer subsystem 392 of
issuer subsystem 300 receives an authorization request (e.g.,
directly from acquiring bank subsystem 399 or SP subsystem 300 as
data 692 at operation 642, or indirectly via an associated payment
network subsystem 362 as data 405), the payment information (e.g.,
host payment credential data 675 of host device 100 as encrypted by
credential key 155b' by secure element 145 of host device 100
(e.g., encrypted host payment credential data 676)) and the
purchase amount, each of which may be included in the authorization
request data, may be decrypted (e.g., using credential key 155b' at
issuer subsystem 300) and analyzed to determine if the account
associated with the host transaction credential has enough credit
or otherwise to cover the purchase amount. If sufficient funds are
not present, second issuer subsystem 392 may decline the requested
transaction by transmitting a negative authorization response to
acquiring bank subsystem 399/SP subsystem 200. However, if
sufficient funds are present, second issuer subsystem 392 may
approve the requested transaction by transmitting a positive
authorization response to acquiring bank subsystem 399/SP subsystem
200 and the financial transaction may be completed. Either type of
authorization response may be provided by second issuer subsystem
392 to acquiring bank subsystem 399/SP subsystem 200 as
authorization response transaction status data 694 at operation 644
of process 600 (e.g., directly from second issuer subsystem 392 to
acquiring bank subsystem 399/SP subsystem 200, or from payment
network subsystem 362 to acquiring bank subsystem 399/SP subsystem
200 based on authorization response data 415 that may be provided
to payment network subsystem 362 from second issuer subsystem 392
via communication path 42). Next, in response to receiving
authorization response transaction status data 694 at operation
644, process 600 may also include SP subsystem 200 or any other
suitable subsystem sharing such authorization response transaction
status data with client device 100' (e.g., using the SP resource or
otherwise) as confirmed transaction status data 696 at operation
646 and/or with host device 100 as confirmed transaction status
data 698 at operation 648. Such confirmed transaction status data
may be configured to provide any suitable confirmation data to
device 100 and/or 100', such as confirmation data 335 of screen
190h of FIG. 3H. If the transaction is successful, the confirmed
transaction status data may be operative to close the transaction
(e.g., the transaction identified by the unique
RemotePaymentIdentifier of the payment request data) at client
device 100' at operation 646 and/or at host device 100 at operation
648. If the transaction is not successful, the confirmed
transaction status data may or may not be operative to close the
transaction (e.g., close the transaction if no valid funds
available or device identified as fraudulent, but keep open and
allow updates if a non-valid shipping address is determined). Any
non-transaction-terminating transaction status data may allow the
payment process to continue until the process is cancelled by an
application, the process is cancelled by a user, or the process is
completed.
[0089] 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)).
[0090] It is understood that the operations shown in process 600 of
FIG. 6 are only illustrative and that existing operations may be
modified or omitted, additional operations may be added, and the
order of certain operations may be altered. Further, in some
implementations, two or more operations may occur in parallel or in
a different sequence than described. In some embodiments, a
potential transaction (e.g., as identified by potential transaction
data 660) may be at least partially funded by two different payment
credentials. Although not shown, voucher data 682 may be
communicated from AE subsystem 400 directly to client device 100'
(e.g., via communications path 95 and not via host device 100) or
from AE subsystem 400 directly to SP subsystem 200 (e.g., via
communications path 85 and not via host device 100 and/or not via
client device 100') or from AE subsystem 400 directly to issuer
subsystem 300 or its acquiring bank (e.g., via communications path
55 and not via host device 100 and/or not via client device 100'
and/or not via SP subsystem 200) for redemption by any of those
receiving subsystems. Although not shown, voucher data 682 may be
communicated from host device 100 directly to SP subsystem 200
(e.g., not via client device 100') for redemption by SP subsystem
200 or from host device 100 directly to issuer subsystem 300 for
redemption by issuer subsystem 300 (e.g., via communications path
75 and not via client device 100' and/or not via SP subsystem 200).
It is to be understood that when no geographic restriction is
detected for the host transaction credential being used, or if IDS
subsystem 471 is not to be used to handle data communicated from
host device 100 to client device 100', then operations 632 and
636-638 may be skipped, whereby secured host transaction data 683
and 684 may include SP credential data 681 rather than voucher data
682, such that client device 100' does not need to use a voucher to
redeem such SP credential data 681 but may receive such SP
credential data 681 directly from host device 100. As mentioned,
client device 100' may be configured to determine that a particular
product or service ought to be purchased and to interact with one
or more SPs in order to obtain associated potential transaction
data from at least one particular SP for that particular product or
service (e.g., client device 100' may be a home appliance that may
be configured to determine that an appliance product must be
purchased (e.g., detect that more laundry detergent is needed by a
washing machine or detect a calendar event pre-set by a user to buy
more detergent on a particular date) and may automatically identify
a particular SP offering the best deal for that product and may
automatically interact with that SP to obtain potential transaction
data for purchasing that product from that SP), all automatically
and without any active interaction by a user of client device 100'.
After which, client device 100' may be operative to automatically
generate and push a payment request (e.g., transaction request data
666) to one or more particular target host devices. For example,
such a client device 100' may be an automated device that may be
paired to one or more host devices 100 in an ecosystem (e.g., using
a home automation platform, such as HomeKit.TM. by Apple Inc.) and
such a payment request may be at least partially pre-populated or
otherwise populated according to any suitable pre-defined settings
(e.g., request payment for new laundry detergent from host device X
and request payment for new drier sheets from host device Y, or
request payment for any purchase over SG from host device X and
under $G from host device Y, etc.).
[0091] 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.TM., 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.
[0092] 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.TM. by Apple Inc.), the online resource
may be operative to present a payment sheet or any suitable UI on
client device 100' that may enable the user to enter a particular
shipping address or other variable data (e.g., as shown by screen
190a and as may be updated by the user of client device 100'
through one or more additional iterations of requesting and
obtaining updated potential transaction data of operation 610 that
may update other information (e.g., in response to the user of
client device 100' changing a shipping address of information 307d,
the price of information 307c may be updated)). At some point, the
user of client device 100' may select a "Secure Pay" option 309 of
screen 190a, which may result in a discovery process (e.g.,
operations 662 and 664) that may automatically identify (e.g.,
without any further interaction by the user of client device 100')
that client device 100' has no native payment credentials suitable
for funding the purchase of the payment sheet of screen 190a (e.g.,
based on acceptable payment options indicated by potential
transaction data 660) and that "HD1's PM Y" (i.e., Payment Method Y
of Host Device 1) is the only available or preferred non-native
payment credential suitable for use (e.g., preference may be
automatically determined based on the proximity of each available
host device to the client device or any other suitable
characteristics that may be accessible to client device 100' via
the discovery process). After such identification, client device
100' may be operative to automatically present screen 190c of FIG.
3C to the user of client device 100' for enabling the user to
select option 315 of FIG. 3C for sending an appropriate payment
request to that host device or process 600 may automatically make
that selection on the user's behalf (e.g., by automatically sending
appropriate transaction request data 666 to the available target
host device 1 (i.e., host device 100) in response to identification
of the discover process), which may result in screen 190d of FIG.
3D or screen 190e of FIG. 3E automatically being presented by that
host device 100 (e.g., presenting a pay sheet on host device 100
that may be similar to the pay sheet presented on client device
100'). Host device 100 may be a mobile telephone or any other
device that may include a secure element with at least one native
payment credential suitable for funding the transaction initiated
by client device 100'. The user of client device 100' may be
proximate to not only client device 100' but also to host device
100 and may be able to interact with a GUI of one of screens
190d-190f of host device 100 for authorizing the use of a
particular payment credential native to host device 100 for funding
the transaction initiated or otherwise being conducted by client
device 100' and SP subsystem 200 (e.g., by selecting authenticate
option 331 of screen 190f of FIG. 3F). In response to such
authentication on host device 100, host payment credential data for
a credential native to host device 100 may be provided to issuer
subsystem 300 for attempting to fund the transaction (e.g., at
operations 625-642 of process 600) and a confirmation status of the
transaction may then be shared with the user at client device 100'
and/or at host device 100 (e.g., by screen 190h of FIG. 3H). In an
alternative embodiment, multiple host devices may be identified as
available and a payment request may be sent from client device 100'
to each one of the available host devices and the first host device
to respond with host payment credential data may fund the
transaction or each host device may respond with host payment
credential data that may fund a particular portion of the
transaction.
[0093] 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.TM. 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.TM. or any other suitable local
communication protocol.
[0094] 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).
[0095] When client device 100' may be communicating with SP
subsystem 200 via a native application on client device 100' that
may be specific to the SP, then SP application 113c may be provided
by such an application. However, when client device 100' may be
communicating with SP subsystem 200 via an internet browser not
specific to an SP but that may be pointed to a website managed by a
merchant (e.g., on a server under the control of the SP), then SP
application 113c may be a layout engine software component (e.g.,
WebKit) that may forward communications on to a website of the SP
(e.g., via communications component 106). For example, such an
application 113c of client device 100' may be a conduit for any
host transaction data to be provided to SP subsystem 200.
Alternatively, such host transaction data may be communicated to SP
subsystem 200 not via client device 100' but instead directly from
host device 100 (e.g., using a voucher as a proxy) or AE subsystem
400 (e.g., using an SP identifier (e.g., SP ID 219) or address
provided by the SP in potential transaction data and the client
device payment request data).
Further Description of FIGS. 1-6
[0096] One, some, or all of the processes described with respect to
FIGS. 1-6 may each be implemented by software, but may also be
implemented in hardware, firmware, or any combination of software,
hardware, and firmware. Instructions for performing these processes
may also be embodied as machine- or computer-readable code recorded
on a machine- or computer-readable medium. In some embodiments, the
computer-readable medium may be a non-transitory computer-readable
medium. Examples of such a non-transitory computer-readable medium
include but are not limited to a read-only memory, a random-access
memory, a flash memory, a CD-ROM, a DVD, a magnetic tape, a
removable memory card, and a data storage device (e.g., memory 104
and/or memory module 150 of FIG. 2). In other embodiments, the
computer-readable medium may be a transitory computer-readable
medium. In such embodiments, the transitory computer-readable
medium can be distributed over network-coupled computer systems so
that the computer-readable code is stored and executed in a
distributed fashion. For example, such a transitory
computer-readable medium may be communicated from one electronic
device to another electronic device using any suitable
communications protocol (e.g., the computer-readable medium may be
communicated to electronic device 100 via communications component
106 (e.g., as at least a portion of an application 103 and/or as at
least a portion of an application 113 and/or as at least a portion
of an application 143)). Such a transitory computer-readable medium
may embody computer-readable code, instructions, data structures,
program modules, or other data in a modulated data signal, such as
a carrier wave or other transport mechanism, and may include any
information delivery media. A modulated data signal may be a signal
that has one or more of its characteristics set or changed in such
a mariner as to encode information in the signal.
[0097] 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.
[0098] 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).
[0099] Any or each module or component of system 1 (e.g., any or
each module of NFC component 120) may be a dedicated system
implemented using one or more expansion cards adapted for various
bus standards. For example, all of the modules may be mounted on
different interconnected expansion cards or all of the modules may
be mounted on one expansion card. With respect to NFC component
120, by way of example only, the modules of NFC component 120 may
interface with a motherboard or processor 102 of device 100 through
an expansion slot (e.g., a peripheral component interconnect
("PCI") slot or a PCI express slot). Alternatively, NFC component
120 need not be removable but may include one or more dedicated
modules that may include memory (e.g., RAM) dedicated to the
utilization of the module. In other embodiments, NFC component 120
may be integrated into device 100. For example, a module of NFC
component 120 may utilize a portion of device memory 104 of device
100. Any or each module or component of system 1 (e.g., any or each
module of NFC component 120) may include its own processing
circuitry and/or memory. Alternatively, any or each module or
component of system 1 (e.g., any or each module of NFC component
120) may share processing circuitry and/or memory with any other
module of NFC component 120 and/or processor 102 and/or memory 104
of device 100.
Further Applications of Described Concepts
[0100] While there have been described systems, methods, and
computer-readable media for conducting a transaction using an
electronic device with a geographically restricted non-native
credential, it is to be understood that many changes may be made
therein without departing from the spirit and scope of the subject
matter described herein in any way. Insubstantial changes from the
claimed subject matter as viewed by a person with ordinary skill in
the art, now known or later devised, are expressly contemplated as
being equivalently within the scope of the claims. Therefore,
obvious substitutions now or later known to one with ordinary skill
in the art are defined to be within the scope of the defined
elements.
[0101] 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.
* * * * *