JP2019507936A - Execution of transactions using electronic devices with non-native credentials - Google Patents

Abstract

Systems, methods, and computer readable media for performing transactions with electronic devices having non-native credentials are provided. In one embodiment, the client electronic devices in the system, including the credential subsystem, the processing subsystem, and the host electronic device, are an on-line communication component and a processor, and potential transaction data indicative of a transaction from the processing subsystem. And communicate credential request data to the host electronic device using the online communications component based on potential transaction data, and host credentials based on credential request data from the host electronic device using the online communications component A processor that receives data and communicates host payment credential data to a processing subsystem, wherein the host credential data To fund at least part of the Deployment operates to access the funds or other suitable activation elements from credential subsystem. Additional embodiments are also provided. [Selected figure] Figure 1A

Description

This application claims the benefit of US Provisional Patent Application Publication No. 62 / 286,938, filed Jan. 25, 2016, previously filed US Provisional Patent Application Ser. Patent Application Publication No. 62 / 348,958 and U.S. Provisional Patent Application Publication No. 62 / 384,059, filed on September 6, 2016, each of which is incorporated herein by reference. Is hereby incorporated by reference in its entirety.
The present disclosure relates to performing transactions with electronic devices having non-native credentials, and more particularly, performing transactions using client electronic devices with credentials from a host electronic device.

  Portable electronic devices (e.g., mobile phones) can be provided with a near field communication ("NFC") component that enables contactless proximity based communication with another entity (e.g., a retailer). Often, these transactions involve financial transactions or other that require the electronic device to generate, access, and / or share native payment credentials, such as credit card credentials, with other entities in contactless proximity based communication. Associated with a secure data transaction of However, efficient use of native payment credentials by electronic devices in other types of communications (eg, online financial transactions) has often been inefficient.

  Systems, methods, and computer readable media for performing transactions with electronic devices having non-native credentials are described.

  As an example, a method of executing a merchant subsystem and a financial transaction using a commercial entity subsystem, a client electronic device, and a secure element and a host electronic device including a host credential application provisioned on the secure element At the host electronic device, from the client electronic device, payment request data, including: merchant subsystem identifier information identifying the merchant subsystem, and host credential application identifier information identifying the host credential application; Receiving payment request data and using the host credential application identified by the received payment request data on the secure element Generating first data including payment settlement credential data, and encrypting the first data and the retailer subsystem identifier information of the received payment request data with the first key on the secure element Generating the second data, transmitting the second data to the commercial entity subsystem, and transmitting the first data encrypted with the second key associated with the retailer subsystem identifier information Receiving the third data, and transmitting the received third data to fund at least a portion of the financial transaction.

  As another example, a method of executing a merchant subsystem and a financial transaction using a client electronic device and a host electronic device, in the client electronic device, from the merchant subsystem, potential transaction data indicative of a financial transaction. Receiving, sending payment request data to the host electronic device based on the received potential transaction data, and host payment credential data generated by the host electronic device based on the sent payment request data Receiving host transaction data, and sending to the merchant subsystem host settlement credential data of the received host transaction data to fund at least a portion of the financial transaction. And that can include.

  As another example, the merchant subsystem and financial transactions are performed using a commercial entity subsystem, a client electronic device, and a host electronic device including a secure element and a host credential application provisioned on the secure element. The method comprises, in a commercial entity subsystem, receiving from a client electronic device a host availability request identifying at least one payment type acceptable to a retailer subsystem for funding financial transactions; A host based on determining that the device is associated with the client electronic device and determining that the host electronic device is associated with the client electronic device The host credential application provisioned in the secure element of the child device determines that the identified at least one payment type of the received host availability request is satisfied, and the host credential application determines at least one payment type identified. Sending a host availability response identifying the host electronic device to the client electronic device based on the determination of filling.

  As yet another example, a client electronic device in a system including a financial institution subsystem, a retailer subsystem, and a host electronic device may be an online communication component and a processor, which is a merchant using the online communication component. From the subsystem, access the potential transaction data indicating financial transactions, communicate the payment request data based on the potential transaction data to the host electronic device using the on-line communication component, and use the on-line communication component Receiving host payment credential data from the host electronic device based on the payment request data and communicating the host payment credential data to the merchant subsystem using the online communication component; And processor can include a host settlement credential data is to fund at least part of the financial transaction, it operates to access funds from the financial institution subsystems.

  As yet another example, a non-transitory computer readable storage medium storing at least one program may be provided, the at least one program including instructions, the instructions by an electronic device including a user interface output component When executed, causes the electronic device to identify at least one payment type acceptable to the merchant subsystem to fund potential transactions and host availability indicating the identified at least one payment type Request data to be sent, host availability response data from another electronic device is processed based on host availability request data, and depending on the processing, settlement request data to another electronic device using a user interface output component To start sending Thereby providing an optional user-selectable to work.

  As yet another example, a method may be provided to perform transactions with a service provider subsystem using client electronic devices and host electronic devices. The method comprises, in a client electronic device, communicating with a service provider subsystem to define at least part of a transaction for purchasing access to a product of the service provider subsystem, and involving a host electronic device. Generating transaction credentials to fund the transaction.

  The summary of the present invention is provided only to summarize some exemplary embodiments, so as to provide a basic understanding of some aspects of the subject matter described herein. Thus, it should be understood that the features described in the summary of the invention are merely examples and should not be construed as limiting 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 be apparent from the following Detailed Description, the Figures, and the Claims.

The following discussion refers to the following drawings, where like reference numerals refer to like parts throughout.
FIG. 1 is a schematic diagram of an example system for performing transactions. Figure 2 is a more detailed schematic of the system of Figure 1; FIG. 2 is another more detailed schematic of the system of FIGS. 1 and 1A. FIG. 2 is a more detailed schematic view of the electronic device of the system of FIGS. 1 and 1B. FIG. 3 is another more detailed schematic of the electronic device of FIGS. 1 and 2; It is a front view of the electronic device of FIG. 1 and FIG. 2A. FIG. 5 is a front view of a screen of the graphical user interface of the one or more electronic devices of FIGS. 1-3, illustrating the process of performing a transaction. FIG. 5 is a front view of a screen of the graphical user interface of the one or more electronic devices of FIGS. 1-3, illustrating the process of performing a transaction. FIG. 5 is a front view of a screen of the graphical user interface of the one or more electronic devices of FIGS. 1-3, illustrating the process of performing a transaction. FIG. 5 is a front view of a screen of the graphical user interface of the one or more electronic devices of FIGS. 1-3, illustrating the process of performing a transaction. FIG. 5 is a front view of a screen of the graphical user interface of the one or more electronic devices of FIGS. 1-3, illustrating the process of performing a transaction. FIG. 5 is a front view of a screen of the graphical user interface of the one or more electronic devices of FIGS. 1-3, illustrating the process of performing a transaction. FIG. 5 is a front view of a screen of the graphical user interface of the one or more electronic devices of FIGS. 1-3, illustrating the process of performing a transaction. FIG. 5 is a front view of a screen of the graphical user interface of the one or more electronic devices of FIGS. 1-3, illustrating the process of performing a transaction. FIG. 2 is a more detailed schematic of the commercial entity subsystem of the system of FIGS. 6 is a flowchart of an exemplary process for performing a transaction. 6 is a flowchart of an exemplary process for performing a transaction. 6 is a flowchart of an exemplary process for performing a transaction. 6 is a flowchart of an exemplary process for performing a transaction. 6 is a flowchart of an exemplary process for performing a transaction. 6 is a flowchart of an exemplary process for performing a transaction.

  Credential-enabled (or settleable) credentials provisioned on the secure element of the host electronic device (eg, payment credentials or any other suitable transaction credentials) may be securely funded or a transaction (eg, financial transaction) Or any other suitable credential transaction) may be used to perform via the merchant (or service provider or processing) subsystem and the client electronic device that may be interfaced with the merchant subsystem . Interface with a merchant subsystem (eg, via an online resource (eg, an online application or web browser) or via a contactless proximity based communication medium) to access (eg, purchase) a merchant product During this time, the client device may identify the host device as the desired source of credentials used to fund or otherwise advance the transaction to access the merchant product. . The client device then requests the identified host device a credential (or payment) request (eg, a retailer, products to be purchased, cost of the transaction, shipping address of the transaction, etc.) indicating the transaction to be funded. Data) can be transmitted. Specific credential data (eg, token data and associations) of credentials (eg, payment credentials) provisioned on the host device after the user of the host device approves the request in response to the host device receiving the payment request The encrypted data) is provided by the host element's secure element and may include any other suitable transaction information (eg, retailer, product purchased, cost of transaction, transaction currency, transaction shipping address, etc.) Host device to client device, or to a merchant subsystem, or to a financial institution (or issue or credential) subsystem, to fund transactions, as well as data It is trust. Such credential data may not be shared directly between the host electronic device and the merchant subsystem. Alternatively, the client device may receive credential data from the host device, and then the client device may share the credential data with the merchant subsystem. A client device can operate to monitor the status of various credentials of various host devices that may or may not be associated with the client device, a commercial (or operational or trusted) entity subsystem The host device can be identified and communicated with it using any suitable technique, including utilizing an identity management service.

FIG. 1 shows system 1, where credentials provisioned to host electronic device 100 are used by host electronic device 100, possibly in connection with an operational (or commercial or trusted) entity subsystem 400, The transaction may be performed via the service provider (or merchant or processing) subsystem 200 and the client electronic device 100 'or at the request of the client electronic device 100'. FIGS. 1A and 1B show more details of System 1 in which one or more credentials are hosted from a financial institution (or issue or credential) subsystem 350 along with a commercial (or operational or trusted) entity subsystem 400. The electronic device 100 can be provisioned, and there such credentials are used by the host electronic device 100 to bring the merchant (or service provider or processing) subsystem 200 and the associated acquisition subsystem 300 ( For example, transactions can be performed at the request of the acquiring bank subsystem and the client electronic device 100 '. On the other hand, FIGS. 2 and 3 show further details regarding specific embodiments of one or more electronic devices of the system 1. 3A-3H illustrate exemplary screens 190a-190h, which may represent graphical user interfaces of one or more electronic devices of the system 1 during such transactions. FIG. 4 shows further details regarding a particular embodiment of the commercial entity subsystem 400 of system 1. 5-10 are flowcharts of exemplary processes for performing such transactions.
Description of Figure 1

  FIG. 1 is a schematic diagram of an exemplary system 1, which is a transaction (e.g., online payment or contactless) with a service provider (or a retailer or processor) via or at the request of a client electronic device. Proximity-based payment) can enable secure use of credentials on the host electronic device. For example, as shown in FIG. 1, system 1 includes an end-user host electronic device 100 having at least one credential provisioned thereon (eg, on a secure element of host electronic device 100), at least one provisioned thereon. Includes end-user client electronic device 100 ', which may or may not have one credential, operational (or commercial or trusted) entity subsystem 400 and service provider (or retailer or processing) subsystem 200 be able to. Communication of any suitable data between any two of host electronic device 100, client electronic device 100 ', service provider subsystem 200, and operating entity subsystem 400 is enabled through any suitable communication setup 9. Can be implemented using any suitable communication protocol, and / or any suitable network and / or cloud architecture, any suitable wired communication path, wireless communication path, two or more wired and two or more wired A combination of wireless communication paths may be included.

  The credentials (eg, payment credentials or any other suitable transaction credentials) may be issued on the host electronic device 100 (eg, on the secure element or other storage component of the host electronic device 100) of any suitable credential issuing sub It can be provisioned either from a system (e.g., financial institution subsystem), directly from the credential issuing subsystem, or through the operating entity subsystem 400, which secures credential data to the host device 100. Communicate with and manage such credential data. Once provisioned to host device 100, the transaction credentials are then used by host device 100 to securely fund or otherwise service provider subsystem 200 (eg, any suitable Through any suitable subsystem that can operate to provide good access to the subsystem or act as part of a transaction, and the client device 100 'that interfaces with the service provider subsystem 200. A transaction (eg, a financial transaction or any other suitable creditor), either on behalf of or on behalf of the client device 100 'that has initiated the service provider subsystem 200 transaction. Catcher Le transaction) may be performed.

For example, to access (eg, purchase) service provider products, via service provider subsystem 200 (eg, via an online resource (eg, an online application or web browser) or via a contactless proximity based communication medium 2.) While interfacing, the client device 100 'identifies the host device 100 as a desired source of transaction credentials used to fund or otherwise advance a transaction to access a service provider product be able to. Whether the client device 100 'is a type of device that may not be configured to store or provision transaction credentials for use in funding transactions (eg, client device 100' May not include a secure element that operates to secure payment credentials), or is configured to store transaction credentials, but used in certain transactions initiated by the client device 100 ' The specific credentials that it is desired to be can be any of the types of devices that are not currently stored. For example, at any suitable point in time during any suitable communication between client device 100 ′ and service provider subsystem 200 to define a transaction for accessing a product of service provider subsystem 200, client device 100. 'Identifies the availability of at least one transaction credential stored on the host device 100 that may instead be available for use in funding transactions (eg, by the operating entity subsystem 400) Or may be identified. Such transaction credentials on the host device 100 then service the client device 100 'to share any appropriate data with the host device 100 to fund the transaction on behalf of the client device 100'. It can be required to be shared with the provider subsystem 200. In response to such a request, host device 100 can generate any suitable transaction credential data that can operate to fund the transaction. Then, in some embodiments, the host device 100 sends such transaction credential data along with any other suitable transaction data (eg, transaction data included in a request from the client device 100 ') to the service provider sub Communicating to the system 200, without the client device 100 'processing transaction credential data (e.g., the client device 100' can hand off control of the transaction to the host device 100 (e.g. )) Can complete transaction funding). Alternatively, in other embodiments, host device 100 may send such transaction credential data back to client device 100 ′, which communicates transaction credential data to service provider subsystem 200. Transactions can be funded (e.g., without the need for the service provider subsystem 200 to communicate with or recognize the host device 100 (e.g., transaction credential data on the client device 100 ') As if generated locally)). In any scenario, operational entity subsystem 400 may be utilized as a conduit between service provider subsystem 200 and any device capable of communicating transaction credential data (eg, any suitable shared To enable a secure communication path using the secret or other security features of the operation provider subsystem 200). Further, client device 100 'may or may not be associated with client device 100' using any suitable technique, including directly through peer-to-peer or other direct links. Identifies host device 100 by using an identity management service or any other suitable operational entity service 200 that can operate to monitor the status of various credentials of various host devices; Or can communicate with it in other ways. (For example, host device 100 and client device 100 'may be paired or associated with each other based on a common user account managed by operational entity subsystem 200 to facilitate any suitable portion of the transaction process Can be
Description of FIG. 1A

  Referring now to FIG. 1A, FIG. 1A shows an expanded view of the system 1 described above with respect to FIG. 1, which is a transaction with a merchant via a client electronic device (eg, online payment or contactless proximity based) Enables the host electronic device to use credentials securely at the time of settlement. For example, as shown in FIG. 1A, system 1 includes end-user host electronic device 100 for securely provisioning one or more credentials to host electronic device 100 as well as a commercial entity subsystem 400 and a financial institution (or credentials or issue ) Subsystem 350 can be included. Further, as shown in FIG. 1A, the system 1 can include an end user client electronic device 100 'and a merchant (or service provider or processing) subsystem 200, such provisioned credentials being a host device Used by 100 to perform financial transactions with merchant subsystem 200 via client device 100 '. For example, upon receipt of a client payment request from client device 100 'for a particular financial transaction with merchant subsystem 200, host device 100 may either host transaction data or host payment credential data of provisioned credentials. The client device 100 ′ can then share it with the client device 100 ′ (eg, as secure host transaction data 684), and then the host payment credential data can be transferred to the contactless proximity based communication 5 (eg, near field communication or Share with the merchant subsystem 200 as a BlueTooth® communication) and / or an online based communication 686 (eg, network telecommunications or otherwise), and It is possible to fund the specific financial transaction with the blanking system 200. System 1 also includes an acquisition bank subsystem 300 that can utilize contactless proximity based communication 5 and / or such online based communication 686 to complete financial transactions with financial institution subsystem 350. Can.

The system 1 obtains a communication path 15 that enables communication between the client device 100 'and the retailer subsystem 200, and a communication path 25 that enables communication between the merchant subsystem 200 and the acquisition bank subsystem 300, and Communication path 35 enabling communication between the banking subsystem 300 and the financial institution subsystem 350, communication between the payment network subsystem 360 of the financial institution subsystem 350 and the issuing bank subsystem 370 of the financial institution subsystem 350 Communication path 45 to activate, communication path 55 to activate communication between financial institution subsystem 350 and commercial entity subsystem 400, communication path to activate communication between commercial entity subsystem 400 and host electronic device 100 65, financial institution subsystem 350 and host electronic Communication path 75 for enabling communication between devices 100, communication path 85 for enabling communication between commercial entity subsystem 400 and retailer subsystem 200, between commercial entity subsystem 400 and client device 100 ' A communication path 95 for enabling communication, and a communication path 99 for enabling communication between the host device 100 and the client device 100 'can be included. One or more of the paths 15, 25, 35, 45, 55, 65, 75, 85, 95 and 99 may be at least partially managed by one or more trusted service managers ("TSMs") . Any suitable circuit, device, system, or combination thereof (e.g., a wireless communication infrastructure that may include one or more communication towers, telecommunications servers, etc.) operable to create a communication network One of the paths 15, 25, 35, 45, 55, 65, 75, 85, 95 and 99 that can be used to provide communication using any suitable wired or wireless communication protocol The above can be provided. For example, one or more of the paths 15, 25, 35, 45, 55, 65, 75, 85, 95 and 99 may be Wi-Fi (eg 802.11 protocol), ZigBee (eg 802.15. 4 protocols), WiDi (registered trademark), Ethernet (registered trademark), Bluetooth (registered trademark), BLE (for example, 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 communication protocol that can be used by wireless and mobile phones and personal e-mail devices (e.g. GSM (Registered trademark), GSM (registered trademark) plus EDGE It can support CDMA, OFDMA, HSPA, multiband etc., low power wireless personal area network ("6LoWPAN") modules, any communication protocol that may be used by other communication protocols, or any combination thereof . One or more of the paths 15, 25, 35, 45, 55, 65, 75, 85, 95 and 99 may be enabled by any suitable communication setting (e.g., communication setting 9 of FIG. 1).
Description of FIG. 1B

  Referring now to FIG. 1B, FIG. 1B shows a more detailed view of the system 1 described above with respect to FIG. 1A. As shown in FIG. 1B, for example, host electronic device 100 may include processor 102, communication component 106, and / or near field communication (NFC) component 120. The NFC component 120 may include or otherwise provide a secure element 145 that may be configured to provide a tamper resistant platform (eg, a single chip or multiple chip secure microcontroller), Applications and their confidential and cryptographic data (eg, according to rules and security requirements that may be set by a well-identified trusted authority (eg, financial institution subsystem and / or industry standard authority such as GlobalPlatform, etc.) A credential applet and associated credential key, such as credential key 155a 'and access key 155a and / or issuer security domain ("ISD") key 156k, as shown in FIG. 1B) It may make it possible to hosting in a secure manner. As described in more detail below, the credential applet or payment application on the secure element 145 (e.g., NFC component 120) of the host device 100, configured to provide host payment credential data in sufficient detail as host transaction data May identify a funding account or other financial instrument or credit source (eg, at the financial institution subsystem 350), where such host payment credential data may be received by the client device 100 'and / or retail. It can be used by host device 100 in one or more communications with commerce subsystem 200 and / or commerce entity subsystem 400 to facilitate financial transactions. The NFC component 120 communicates with the merchant subsystem 200 (e.g., a brick and mortar store, or a user of the host device 100 proximally via contactless proximity based communication using credentials stored on the host device 100) A communication path between the merchant terminal 220 of the retailer subsystem 200 which can be located in a brick and mortar store or any physical location capable of performing financial transactions with the merchant terminal 220 located at Configured to communicate such host payment credential data as contactless proximity based communication (eg, near field communication) with and / or with the NFC component 120 'of the client device 100') It may be done. Alternatively, or additionally, communication component 106 may allow host device 100 to send any suitable host payment data to one or more other electronic devices or servers or subsystems (e.g., one or more subsystems of system 1). Or other components) to communicate (eg via one or more of the communication paths 65, 75 and / or 99) using any suitable wired or wireless protocol Can be provided. Processor 102 of host device 100 may include any processing circuitry operable to control the operation and performance of one or more components of host device 100. For example, processor 102 may be configured to execute one or more applications (eg, application 103 and / or online resource or merchant application 113) on device 100, which may include data (eg, host transactions) Host payment credential data) is communicated by the host device 100 to fund financial transactions with the merchant subsystem 200, such as via the client device 100 '(e.g. Method communicated between client devices 100 '(e.g., via communication path 99), and / or finalized from commercial entity subsystem 400 to client device 100' via communication path 95 It can at least partially indicate how to communicate data (e.g., via communication path 65) between the host device 100 and the commercial entity subsystem 400, which can be communicated, as also shown in FIG. In addition, host device 100 may include any suitable host device identification information 119 accessible to processor 102 or any other suitable portion of device 100. Host device identification information 119 may be client device 100 '. And / or utilized by the user of the commercial entity subsystem 400 and / or the retailer subsystem 200 and / or the financial institution subsystem 350 to uniquely identify the host device 100 with the merchant subsystem 200. Facilitate financial transactions And / or enable any suitable secure communication with host device 100. By way of example only, host device identification information 119 may be associated with a telephone number or an email address, or device 100. It may be any unique identifier.

  The client device 100 ′ can include one, some or all of the same components as the host device 100 or any component not provided by the host device 100. For example, as shown in FIG. 1B, client device 100 ′ may communicate with host device 100 (eg, via communication path 99) and / or with commercial entity subsystem 400 (eg, via communication path 95); And / or any suitable communication component 106 'that may communicate with the merchant subsystem 200 (e.g., via communication path 15) any suitable communication. Additionally or alternatively, as shown in FIG. 1B, the client device 100 ′ may operate any suitable non-contact proximity based communication 5 communication with the terminal 220 of the merchant subsystem 200. A touch proximity base or NFC component 120 'can be included. Additionally or alternatively, as shown in FIG. 1B, the client device 100 ′ may include any suitable processor 102 ′, which is the payment credential data from the host device 100 communicated by the client device 100 ′ Devices and one or more suitable applications (eg, online resources or merchant applications 113 ') that may at least partially specify how financial transactions with the merchant subsystem 200 can be funded It can operate to run on 100 '. Further, as shown in FIG. 1B, client device 100 ′ may include any suitable client device identification information 119 ′, which may access processor 102 ′ or any other suitable portion of device 100 ′. It can be. The client device identification information 119 ′ may be used by the host device 100 and / or the commercial entity subsystem 400 and / or the merchant subsystem 200 and / or the financial institution subsystem 350 to uniquely identify the client device 100 ′. Can be used to facilitate financial transactions with the merchant subsystem 200 and / or enable any suitable secure communication with the client device 100 '. By way of example only, client device identification 119 'may be a telephone number or an email address, or any unique identifier that may be associated with device 100'. Although not shown, the client electronic device 100 'is the same or similar I / O interface as the I / O interface 114 of the electronic device 100 of FIG. 2, the same as or similar to the bus 118 of the electronic device 100 of FIG. , A memory component the same as or similar to the memory component 104 of the electronic device 100 of FIG. 2, and / or a power supply component the same as or similar to the power supply component 108 of the electronic device 100 of FIG.

  Retailer subsystem 200 may include any suitable merchant server 210, as shown in FIG. 1B, which may be any suitable communication protocol (eg, Wi-Fi, Bluetooth, etc.). Communication components of the commercial entity subsystem 400 (eg, via the communication path 85) and / or communication components of the acquisition bank 300 (eg, the communication path 25) via mobile phones, wired network protocols, etc. Any suitable components or sub-systems configured to communicate (eg, via communication path 15) and / or with communication components of client device 100 ') may be included. For example, merchant server 210 may be a third party merchant application 113 operating on client device 100 ′ that may manage potential transaction data 660 and / or updated potential transaction data 672 by merchant server 210. 'Or an Internet application 113' running on a client device 100 'whose target or web resource may be indicated by a Uniform Resource Locator ("URL") that may be managed by the merchant server 210 (e.g. Safari (TM) by Apple Inc. , Etc., any suitable merchant online that may be running on client device 100 ′ in communication with merchant server 210. 'Such as running a financial transaction via the client device 100 in any suitable online context' resource 113 and the communication component 106 'of it can be operable to communicate. Thus, it should be noted that communication between the merchant server 210 and the client device 100 'may occur wirelessly (eg, via the Internet) and / or via a wired path. The merchant server 210 may be provided by a merchant of the merchant subsystem 200 (eg, as a web server for hosting website data and / or managing third party application data). Additionally or alternatively, as shown in FIG. 1B, retailer subsystem 200 may include any suitable retailer terminal 220 (eg, a retailer payment terminal), which may include any suitable data. Any suitable configured to communicate with the contactless proximity based communication component of host device 100 and / or client device 100 '(e.g. contactless proximity based communication 5 with NFC component 120' of client device 100 ') Components or subsystems can be included. Further, as shown in FIG. 1B, the merchant subsystem 200 can include a merchant key 157. Although not shown, the retailer subsystem 200 may be the same as or similar to the processor component 102 of the electronic device 100 of FIGS. 1B and 2 in communication with the electronic device 100 of FIGS. 1B and 2. A retailer communication component that may be the same as or similar to component 106 (eg, as part of server 210), a retailer I / O that may be the same as or similar to I / O interface 114 of electronic device 100 of FIG. Interface, a retail bus that may be the same as or similar to the bus 118 of the electronic device 100 of FIG. 2, a retailer memory component, which may be the same as or similar to the memory component 104 of the electronic device 100 of FIG. Power component 1 of 2 electronic devices 100 8 the same or merchant power components, which may be similar, may also be included.

  The financial institution subsystem 350 may include a payment network subsystem 360 (eg, payment card association or credit card association) and / or an issuing bank subsystem 370. For example, the issuing bank subsystem 370 may be a financial institution that can be primarily responsible for the consumer's ability to redeem the debt that can be incurred with a particular credential. Each specific credential applet of NFC component 120 of host device 100 may be associated with a particular payment card that may be electronically linked to the particular user's account (s). 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 transaction credentials of a particular payment card may be communicated (e.g., directly, or via the merchant entity subsystem 400, and / or via the client device 100 ') with the merchant subsystem 200, e.g. May be provisioned on the host device 100 by the issuing bank subsystem 370 for use in contactless proximity based communication and / or online based communication (e.g., of the credential added security domain of the NFC component 120 as described below) As a credential). Each credential may be a particular brand of payment card that may be branded by payment network subsystem 360. Payment network subsystem 360 may be a network of various issuing banks 370 and / or various acquiring banks 300 that can handle the use of a particular brand of payment card (e.g., transaction credentials).

  In order to make a financial transaction within system 1, at least one commerce credential must be securely provisioned on the secure element of NFC component 120 of host electronic device 100. For example, such commerce credentials may be at least partially provisioned on the secure element of NFC component 120 of host device 100 directly from financial institution subsystem 350 (eg, between financial institution subsystem 350 and device 100). As credential data 654 via communication path 75, it may be passed to NFC component 120 via communication component 106). Additionally or alternatively, such commerce credentials may be at least partially provisioned from the financial institution subsystem 350 to the secure element of the NFC component 120 of the host device 100 via the commercial entity subsystem 400 (eg, financial As credential data 654 via communication path 55 between agency subsystem 350 and commercial entity subsystem 400, it is via communication path 65 between server 410 of commercial entity subsystem 400 and communication component 106 of device 100. The credential data 654 may be passed to the device 100, which may then be passed from the communication component 106 to the NFC component 120). The credential data 654 via the path 75 and / or via the path 55/65 is provisioned on the secure element of the device 100 as at least a part or all of the credential addition security domain of the NFC component 120, the credential information 161a and the credential key A credential application with credential information and / or a credential key may be included, such as a payment application with credential 155a 'or a credential applet 153a. As shown in FIG. 1B, for example, the financial institution subsystem 350 can also access the credential key 155a '(eg, to decrypt data encrypted by the device 100 using the credential key 155a' ). The financial institution subsystem 350 may be responsible for managing the credential key 155a ', which may include such key generation, exchange, storage, use, and substitution. The financial institution subsystem 350 may store that version of the credential key 155a 'in the secure element of the financial institution subsystem 350. The credential key 155 a ′ of the NFC component 120 and the financial institution subsystem 350 may be any suitable shared secret (eg, password, passphrase, random) available to both the secure element of the electronic device 100 and the financial institution subsystem 350. An array of bytes selected into one, one or more symmetric keys, a public-private key (eg, asymmetric key), etc.), which may be used by the financial institution subsystem 350 to generate By the electronic device 100 and the financial institution subsystem 350, such as by using any suitable cryptographic algorithm or cipher whose functional output can be determined at least in part by a shared secret that can be provisioned to Payment data It should be understood that it may be operated to validate that any suitable cryptographic data (eg, ciphertext) or any other suitable data is independently generated to prove. is there. The shared secret is pre-shared between the financial institution subsystem 350 and the host device 100 (eg, during provisioning of credentials on the device 100 by the financial institution subsystem 350), in which case such shared secret is pre-shared. It may be called a shared key, or the shared secret may be identified by using a key sharing protocol (eg using public key cryptography such as Diffie-Hellman or using symmetric key cryptography such as Kerberos) Or may be created prior to being used for a financial transaction. Any suitable cryptographic algorithm or cipher whose functional output may be determined at least in part by the shared secret and shared secret information may be accessible to the secure element of the device 100.

  Commercial entity subsystem 400 may be provided as an intermediary between financial institution subsystem 350 and host device 100, which provides a new security layer and / or a more seamless user experience. It may be configured to provide when credentials are provisioned on the secure element of device 100 and / or such provisioned credentials may then be between device 100 and merchant subsystem 200. Commerce credentials are used as part of data communication. The commercial entity subsystem 400 may have a user-specific account (eg, user-specific) having that commercial entity by a particular commercial entity capable of providing various services to the user of device 100 and / or the user of device 100 '. It may be provided via user-specific login information) via a combination of identification and password. By way of example only, commercial entity subsystem 400 may be Apple Inc. of Cupertino, CA may be provided by various services to the user of device 100 and / or device 100 '(e.g. iTunes (TM) Store for selling / renting media played by device 100) The Apple App StoreTM for selling / renting applications, storing data from the device 100 for use in the device 100, and / or multiple user devices and / or multiple user profiles to each other Apple iCloud (TM) Service for associating, Apple Online Store for purchasing various Apple products online, Ap for communicating media messages between devices It can also be a provider of le iMessage (TM) Service, etc., and that it is the device 100 itself and / or the device 100 'itself (e.g. the device 100 is iPod (R), iPad (R)) , An iPhone (registered trademark), etc., and / or a provider, manufacturer and / or developer of the device 100 and / or the operating system of the device 100 '(eg, the device application 103). The commercial entity that can provide the commercial entity subsystem 400 (eg, Apple Inc.) may be independent of any financial entity of the financial institution subsystem 350. For example, a commercial entity that can provide the commercial entity subsystem 400 can be any payment network sub that can provide and / or manage any credit card or other commerce credentials that are provisioned to the end user host device 100. It may be different and / or independent of the system 360 or the issuing bank subsystem 370. Additionally or alternatively, the commercial entities that can provide the commercial entity subsystem 400 (e.g., Apple Inc.) may be independent of any of the retailers of the retailer subsystem 200 . For example, a commercial entity that can provide the commercial entity subsystem 400 can provide the merchant terminal for NFC communication, the third party application 113, and / or any other aspect of the retail subsystem 200. It may be different and / or independent of any retailer of subsystem 200. Such commercial entities may configure various components of device 100 (e.g., software and / or hardware components of device 100, such as when the commercial entity may at least partially manufacture or manage device 100). Or when the user wishes to provision the credentials provided by the financial institution subsystem 350 on the host device 100, utilizing the potential to control, and / or such provisioned credentials Used as part of commerce credential data communication with retailer subsystem 200 to provide a seamless user experience for the user of device 100 when funding financial transactions Kill. For example, in some embodiments, device 100 communicates with commercial entity subsystem 400 seamlessly and transparently (e.g., via communication path 65) to the user of device 100 to provide a higher level of security. May be configured to share and / or receive specific data (eg, during online based commerce credential data communication between the device 100 and the merchant subsystem 200). Although not shown, the commercial entity subsystem 400 is a processor component that may be the same as or similar to the processor component 102 of the electronic device 100 of FIGS. 1B and 2, the communication component 106 of the electronic device 100 of FIGS. 1B and 2. A communication component that may be the same as or similar to, an I / O interface that may be the same as or similar to I / O interface 114 of electronic device 100 of FIG. 2, a same or similar to bus 118 of electronic device 100 of FIG. A memory component that may be the same as or similar to memory component 104 of electronic device 100 of FIG. 2 and / or a power supply component that may be the same as or similar to power supply component 108 of electronic device 100 of FIG. Also includes Bets can be, one of them, some or all may be at least partially provided by the server 410.

  In addition to the at least one commerce credential that is provisioned on the secure element of the NFC component 120 of the host device 100 (for example, as part of the credential SSD with credential key 155a 'and credential information 161a), it has at least the access key 155b. One access SSD may also be provisioned on the secure element of NFC component 120 of device 100 to enable device 100 to more securely execute financial transactions with merchant subsystem 200. For example, an access SSD may be at least partially provisioned on the secure element of NFC component 120 of host device 100 directly from commercial entity subsystem 400 (e.g., communication between server 410 of commercial entity subsystem 400 and device 100) As access data 652 via communication path 65 between components 106, it may then be passed from communication component 106 to NFC component 120). Access data 652 via path 65 may be provisioned on the secure element of device 100 as at least part or all of the access SSD, and may include access applet 153 b with access key 155 b. As shown in FIG. 1B, commercial entity subsystem 400 may also access access key 155b (eg, to decrypt data encrypted by device 100 using access key 155b). Commercial entity subsystem 400 may be responsible for managing access key 155b, which may include such key generation, exchange, storage, use, and substitution. Commercial entity subsystem 400 may store the version of access key 155 b in the secure element of commercial entity subsystem 400. The access SSD of NFC component 120 with access key 155b determines the user's intent and local authentication of device 100 (eg, via one or more input components 110 of device 100, such as a biometric input component) It may be configured, and in response to such a determination, another particular SSD may be configured to enable performing a payment transaction (e.g., using credentials SSD credential of NFC component 120) . Storing such an access SSD within the secure element of device 100 can enhance its ability to reliably determine the user intent and authentication of a financial transaction. Further, access key 155 b of such an access SSD of NFC component 120 can be utilized to provide enhanced encryption to financial transaction data that can be communicated outside of the secure element of device 100. Additionally or alternatively, as described below, the access data 652 may include an issuer security domain ("ISD") key 156k for the ISD of the secure element of the electronic device 100, which comprises: It may also be maintained by the commercial entity subsystem 400 and may be used in addition to or in place of the access key 155b, as described in.

  Although not explicitly shown or described, commercial entity subsystem 400 may operate to allow commercial entity subsystem 400 to interact with or associate with host device 100. In the same manner, it can operate to interact or associate with client device 100 '(eg, credentials can be on client device 100' such that client device 100 'can operate as a host device) It should be understood that it can be provisioned).

The merchant application or online resource 113 'can be accessed by the client device 100' to enable that an online financial transaction is facilitated between the device 100 'and the merchant subsystem 200. First, such an application 113 'may be approved or otherwise enabled by the commercial entity subsystem 400 before the application 113' may be accessible by the client device 100 '. It is also good. For example, application store 420 of commercial entity subsystem 400 (e.g., Apple App Store (TM)) receives at least some data representative of application 113 'from merchant subsystem 200 via communication path 85. Can. Further, in some embodiments, the commercial entity subsystem 400 can generate or otherwise assign the merchant key 157 'for the application 113', and the merchant subsystem 200 can such A merchant key 157 'can be provided (eg, via path 85). Alternatively, merchant subsystem 200 may generate or otherwise assign a merchant key 157 ′ for application 113 ′, such merchant key 157 ′ to commercial entity subsystem 400 ( For example, it can be provided via the path 85). Either merchant subsystem 200 or commercial entity subsystem 400 can be responsible for merchant key 157 ', including such key generation, exchange, storage, use, and replacement. Regardless of how or where such merchant key 157 'can be generated and / or managed, both the merchant subsystem 200 and the commercial entity subsystem 400 can be configured of the merchant key 157'. The version may be stored (eg, in the secure elements of each merchant subsystem 200 and the commercial entity subsystem 400). In some embodiments, such a merchant key 157 'may be specifically associated with the merchant application 113', and in other embodiments, the merchant key 157 'may be a merchant key 157'. As may be associated with multiple third party applications operated by the same retailer of retailer subsystem 200, it may be specifically associated with the retailer of retailer subsystem 200. A table 430 or other suitable data structure or information source, which may be accessible to the commercial entity subsystem 400, is provided to associate a particular merchant key 157 'with a particular merchant application 113' or merchant entity. It can be done. The table 430 validates that the commercial entity subsystem 400 determines and utilizes the appropriate merchant key 157 ', and with the merchant subsystem 200 via the merchant application 113' associated with the key 157 '. The security of any commerce credential data communicated to the merchant subsystem 200 (eg, commerce credential data that may include native payment credential data to the host device 100) for financial transactions that may include the interfacing client device 100 ' It is possible to provide a layer. Device 100 'may be configured to access application 113' (eg, from application store 420 via communication path 95) and execute application 113 '(eg, with processor 102'). Additionally or alternatively, the merchant key 157 'is not or in addition to the merchant's website (eg, one or more URLs) and / or a third party application of the merchant (eg, application 113') Generally associated with a retailer. For example, a retailer of retailer subsystem 200 may cooperate with commercial entity subsystem 400 to associate a particular merchant website or retailer with a particular merchant key 157 'in table 430 in general. The Internet application or web operating on the device 100 'where the client device 100' can interface with the merchant server 210 and the target or web resource can be indicated a URL to which the merchant key 157 'can be associated. Communicate to the merchant subsystem 200, enabling the commercial entity subsystem 400 to determine and use the appropriate merchant key 157 'for financial transactions that can perform financial transactions via the browser Any commercial credibility Rudeta (e.g., transaction credential data including native settlement credential data to the host device 100) can provide a layer of security to the. Device 100 ′ may be configured to access such a URL from merchant server 210, for example, via communication path 15 (eg, using Internet application 113 ′ on device 100 ′). In other embodiments, application 113 'may not be associated with a particular merchant, merchant subsystem 200, and / or merchant key 157', but instead may be independent available to device 100 '. It may be an application. In some embodiments, as shown, a similar application 113 having a merchant key 157 may be provided to the host device 100, and the application 113 may be the same as or different from the application 113 '. And / or the key 157 may be different from the key 157 '.
Description of Figure 2

  Referring now to FIG. 2, FIG. 2 shows a more detailed view of the electronic device 100 of the system 1 described above with respect to FIGS. As shown in FIG. 2, for example, electronic device 100 may include processor 102, memory 104, communication component 106, power supply 108, input component 110, output component 112, antenna 116, and near field communication (“NFC”) component 120. Can be included. Electronic device 100 may provide one or more wired or wireless communication links or paths for transmission of data and / or power from or between various other components of device 100. Can also be included. Electronic device 100 may also be provided with a housing 101 that may at least partially surround one or more components of device 100 for protection from debris and other degrading forces external to device 100. In some embodiments, one or more components of electronic device 100 may be combined or omitted. Furthermore, the electronic device 100 can include other components that are not combined or included in FIG. For example, electronic device 100 may include any other suitable components or some instances of the components shown in FIG. For simplicity, only one of each component is shown in FIG. One or more input components 110 may be provided to allow the user to interact with or interface with the device 100 and / or one or more output components 112 may be used by the user of the device 100. May be provided to present information (eg, graphical, audible and / or tactile information). One or more input components and one or more output components are collectively referred to herein as input / output ("I / O") components or I / O interfaces 114 (eg, I / O components or I / O). It should be noted that the input component 110 and the output component 112 as interface 114 may also be referred to. For example, the input component 110 and the output component 112 may be touch screens, etc., which allow the user to touch the display screen to receive input information and provide visual information to the user through the same display screen. It may be a single I / O component 114. Processor 102 of electronic device 100 may include any processing circuitry operable to control the operation and performance of one or more components of electronic device 100. For example, processor 102 may receive an input signal from input component 110 and / or a drive output signal via output component 112. As shown in FIG. 2, processor 102 may be used to execute one or more applications, such as application 103 and / or application 113. As one example, application 103 may be an operating system application, and application 113 may be a third party application or other suitable online resource (eg, an application associated with a merchant of merchant subsystem 200). Further, as shown, the processor 102 can access host device identification information 119, which is used by a user of the device 100 and / or the commercial entity subsystem 400 to commerce the identification of the device 100. Subsystem 200 may be provided (eg, to facilitate financial transactions) and / or to client device 100 '(eg, to facilitate secure communication between devices 100 and 100') .

  NFC component 120 may be any suitable proximity communication mechanism, which is contactless proximity between electronic device 100 of merchant subsystem 200 and a merchant terminal (eg, merchant payment terminal 220). Base transactions or communications can be enabled. NFC component 120 may include any suitable module for enabling contactless proximity based communication between electronic device 100 and such a merchant terminal. As shown in FIG. 2, for example, the NFC component 120 can include an NFC device module 130, an NFC controller module 140, and / or an NFC memory module 150. The NFC device module 130 may include an NFC data module 132, an NFC antenna 134, and an NFC booster 136. The NFC data module 132 includes, transmits or otherwise provides any suitable data that may be transmitted by the NFC component 120 to the merchant terminal as part of a contactless proximity basis or NFC communication. Can be configured as follows. Additionally or alternatively, the NFC data module 132 includes, transmits or otherwise includes any suitable data that may be received by the NFC component 120 from the merchant terminal as part of contactless proximity based communication It may be configured to receive. NFC controller module 140 may include at least one NFC processor module 142. The NFC processor module 142 operates in conjunction with the NFC device module 130 to enable, activate, authorize, and / or operate the NFC component 120 to communicate NFC communications between the electronic device 100 and the merchant terminal. Can be controlled. NFC controller module 140 includes at least one NFC processor module 142 that may be used to execute one or more applications, such as NFC low power mode or wallet application 143, which may serve to indicate the functionality of NFC component 120. be able to. NFC memory module 150 may operate in conjunction with NFC device module 130 and / or NFC controller module 140 to enable NFC communication between electronic device 100 and merchant subsystem 200. NFC memory module 150 may be tamper resistant and may provide at least a portion of secure element 145 (see, eg, FIG. 2A). For example, such a secure element may be configured to provide a tamper resistant platform (eg, a single chip or multiple chip secure microcontroller), which may be a well identified trusted authority Secure applications and their sensitive and cryptographic data (eg applets 153 and keys 155) according to rules and security requirements that may be set by a set of industry standard authorities (eg financial institution subsystem and / or GlobalPlatform etc) May allow you to host.

  As shown in FIG. 2, for example, NFC memory module 150 may include one or more issuer security domain ("ISD") 152 and additional security domain ("SSD") 154 (eg, service provider security domain ("SPSD") , Trusted service manager security domain ("TSMSD"), etc.), which may be defined and managed by the NFC specification standard (eg, GlobalPlatform). For example, ISD 152 may be part of NFC memory module 150, where a trusted service manager ("TSM") or issuing financial institution (eg, financial institution subsystem 350) manages credential content, One or more credentials (e.g., various) on the electronic device 100 (e.g., via the communication component 106), storing keys and / or other suitable information for management of the domain and / or security. Credit cards, bank cards, gift cards, access cards, credentials associated with transit paths, etc.) may be generated or otherwise provisioned. Credentials may be assigned to / consumers, such as credit card payment numbers (eg, device primary account number (“DPAN”), DPAN expiration date, CVV, etc. (eg, as a token or otherwise), etc.) It may include credential data (eg, credential information 161a) that may be securely stored on the electronic device 100. The NFC memory module 150 may include at least two SSDs 154 (e.g., at least a first SSD 154a and a second SSD 154b). For example, a first SSD 154a (eg, credential SSD 154a) may provide a particular credential or payment right to electronic device 100 (eg, a particular credit card credential provisioned by financial institution subsystem 350) Or may be associated with a particular public transit card credential), while the second SSD 154 b (eg, access SSD 154 b) may, for example, provide another SSD to provide the electronic device 100 with a particular privilege or payment right. Commercial entity subsystem, which may be a commercial entity (eg, a controlling entity for device 100) that may control access of device 100 to specific credentials of the first SSD 154a (eg, 00 may be associated with commercial entities). Alternatively, each one of the first SSD 154 a and the second SSD 154 b may have their respective specific credentials (eg, provisioned by the financial institution subsystem 350) that may provide the electronic device 100 with specific privileges or payment rights. It may be associated with a particular credit card credential or a particular public transit card credential). Each SSD 154 may include and / or be associated with at least one applet 153 (eg, SSD 154a with applet 153a and SSD 154b with applet 153b). For example, applet 153 of SSD 154 may be an application that may operate on the secure element of NFC component 120 (eg, in a GlobalPlatform environment). The credential applet 153 may include or be associated with credential information 161 (eg, information 161a of applet 153a and / or information 161b of applet 153b). Each SSD 154 and / or applet 153 includes at least one of its own key 155 (e.g., an applet 153a with at least one key 155a and an applet 153b with at least one key 155b), and / or it It may be associated.

  The key 155 of the SSD 154 may be one piece of information that can determine the cryptographic algorithm or the functional output of the cryptography. For example, in encryption, the key can specify a particular conversion of plaintext to ciphertext, or vice versa, during decryption. The key may also be used in other cryptographic algorithms such as digital signature schemes and message authentication codes. The SSD's key can provide any suitable shared secret to other entities. Each key and applet may be incorporated into the secure element of device 100 by the TSM or authorized agent, or may be pre-integrated into the secure element when first provided to device 100. As an example, credential SSD 154a may be associated with a particular credit card credential, but that particular credential has applets 153a of that credential SSD 154a enabled or otherwise activated for such use Or, if unlocked, it may only be communicated as commerce credential data communication from the secure element of device 100 (eg, from NFC component 120) to merchant subsystem 200 for a financial transaction.

A security feature may be provided to validate the use of the NFC component 120, which may transmit confidential payment information, such as credit card information or bank account information of credentials, from the electronic device 100 to the merchant subsystem 200 (eg, It may be particularly useful when transmitting via the commercial entity subsystem 400 and / or via the device 100 '. Such security features may also include secure storage areas that may have limited access. For example, user authentication via personal identification number ("PIN") input or via user interaction with a biometric sensor may need to be provided to access a secure storage area. As an example, access SSD 154b may use applet 153b to determine whether such authentication was performed prior to permitting use of another SSD 154 (eg, credential SSD 154a) to communicate credential information 161a. It can be determined. In particular embodiments, some or all of the security features may be stored in NFC memory module 150. Additionally, security information, such as an authentication key, for communicating commerce credential data with the merchant subsystem 200 may be stored within the NFC memory module 150. In particular embodiments, NFC memory module 150 may include a microcontroller embedded within electronic device 100. By way of example only, applet 153 b of access SSD 154 b may be configured (eg, via one or more input components 110 such as a biometric input component) to determine the user's intent and local authentication of device 100 In response to such a determination, another specific SSD may be configured to validate (e.g., using the credentials of credential SSD 154a) to perform a payment transaction.
Description of Figure 2A

  Referring now to FIG. 2A, FIG. 2A shows another detail view of a portion of the electronic device 100 of the system 1 described above with respect to FIGS. As shown in FIG. 2A, for example, the secure element 145 of the NFC component 120 may include or be associated with an applet 153a, credential information 161a, access key 155a, and / or credential key 155a ', and an applet 154, as well as an applet 153 b, credential information 161 b, access key 155 b, and / or credential key 155 b ′ may include or be associated with an SSD 154 b. In some embodiments, the particular additional security domain ("SSD") 154 (eg, one of SSDs 154a and 154b) may comprise a particular TSM and at least one particular commerce credential (eg, a particular credit card). Credentials or Public Transit Card Credentials), which may provide the electronic device 100 with certain privileges or payment rights. Each SSD 154 can have its own manager key 155 (e.g., one each of keys 155ak and 155bk), which is active to enable the functions of that SSD 154 for use by NFC device module 130 May need to be Additionally or alternatively, each SSD 154 includes and / or associates with at least one of its own credential application or credential applet (eg, Java card applet instance) associated with a particular commerce credential (For example, 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). Here, the credential applet may have its own access key, eg, access key 155a for credential applet 153a and / or access key 155b for credential applet 153b) and / or its own credential key (eg, credential key 155a 'for credential applet 153a). And / or credential key 155 b ′) for credential applet 153 b, where the credential applet may be for NFC communication (eg, with merchant terminal 220) and / or electronic device 100 and merchant subsystem 200. As on-line based communication (eg, via the commercial entity subsystem 400 and / or the client device 100 ') between For use by the C device module 130 may need to be activated to activate its associated transaction credentials. In some embodiments, the credential applet's credential key (e.g., credential applet 153a's credential key 155a 'and / or credential applet 153b's credential key 155b') may be responsible for such credentials. It may be generated by subsystem 350, which are accessible by financial institution subsystem 350 (eg, as shown in FIG. 1B), and may be Secure transmission of the applet's credential information can be enabled (via quotient subsystem 200). Additionally or alternatively, the access key of the credential applet (e.g., the access key 155a of the credential applet 153a and / or the access key 155b of the credential applet 153b) may be generated by the commercial entity subsystem 400, which is Accessible by the entity subsystem 400 (e.g., as shown in FIG. 1B), secure transmission of the credential information of the applet between the secure element 145 and the commercial entity subsystem 400 can be enabled. Additionally or alternatively, as shown, each applet may include its own unique application identifier ("AID"), such as AID 155aa of applet 153a and / or AID 155ba of applet 153b. For example, an AID can identify a particular card scheme and product, program, or network (e.g., MasterCard Cirrus, Visa PLUS, Interac, etc.), where the AID settles credentials associated with the AID. Provider of credentials associated with AID as well as Registered Application Provider Identifier ("RID") that may be used to identify systems (eg, card schemes) or networks (eg, MasterCard, Visa, Interac, etc.) Or may also include a unique application identifier extension ("PIX") that may be used to distinguish products, programs, or applications provided by the payment system Ru. Any suitable specification (eg, Java Card specification) that can operate to manage the firmware of secure element 145 ensures the uniqueness of each AID on secure element 145 or otherwise. (Eg, each credential instance on secure element 145 may be associated with its own unique AID).

  Additionally or alternatively, as shown in FIG. 2A, secure element 145 may include ISD 152, which may be a trust associated with its security domain (eg, commercial entity subsystem 400 as shown in FIG. 1B). May include an ISD key 156k, which may also be known to the service manager. ISD key 156k is utilized by commercial entity subsystem 400 and electronic device 100 as well as and / or in place of access key 155a and / or access key 155b, to secure commercial entity subsystem 400 and electronic device 100. Secure transmission between elements 145 can be enabled. Additionally, as shown in FIG. 2A, various data may be communicated between the processor 102 and the secure element 145. For example, processor 102 of device 100 may be configured to execute device application 103, which may be merchant application 113 of processor 102 as well as secure element 145, I / O interface component 114a (eg, I / O Information may be communicated with the communication component 106 for receiving input data 115i and / or for transmitting I / O output data 115o. Further, as shown, processor 102 may access device identification information 119, which may be utilized to enable secure communication between device 100 and the remote entity.

  Additionally or alternatively, as shown in FIG. 2A, secure element 145 can include a control authority security domain ("CASD") 158, which acts as a root of third party on element trust It can be a specific purpose security domain that can be configured. The associated application of CASD 158 may be configured to provide on-element secret key generation as a global service to other applications and / or specific management layers (eg, GlobalPlatform management layer). Confidential keying material that may be used within the CASD 158 may be configured such that it is not inspected or altered by any entity, including the issuer of the secure element 145. CASD 158 can be a CASD access kit 158k (eg, CASD private key ("CASD-SK"), CASD public key ("CASD-PK"), CASD certificate ("CASD-Cert."), And / or CASD signature module ) And / or may be configured to generate and / or otherwise include them. For example, CASD 158 may use (eg, CASD access kit 158k) prior to providing such data to another portion of device 100 (eg, communication component 106 for sharing with other subsystems of System 1). May be configured to sign specific data on the secure element 145). As one example, CASD 158 may be configured to sign any data provided by secure element 145 such that other subsystems (eg, commercial entity subsystem 400) may have such signed data secure elements. It can be verified that it has been signed by 145 (eg, using the CASD kit 158k associated in the commercial entity subsystem 400).

  Additionally or alternatively, as shown in FIG. 2A, the secure element 145 may include a contactless registry service ("CRS") applet or application 151, which has the lifecycle state of a particular security domain element ( For example, to change activation, deactivation, locking, etc., and specific output information 115o for a particular security domain element with the user of device 100 (eg, via user I / O interface 114a) 2.) The electronic device 100 can be configured to provide local functionality for sharing. For example, CRS application 151 may list the current lifecycle state of each security domain element on secure element 145 (e.g., one, some or all of credential applet 153a of list SSD 154a and / or credential applet 153b of SSD 154b) The CRS application 151 may include the CRS list 151t, which may include a list that may include the CRS application 151, and the CRS application 151 with the application 100 of the device 100 (for example, a daemon etc.) Any suitable application type of can be run as a background process within operating system application 103 Management daemon ("CMD") application 113a and / or card management application 113b (e.g., Passbook (TM) or Wallet (TM) application by Apple Inc.) and / or retailer application 113c (e.g., retail key 157) And / or any appropriate application type, such as a daemon, such as an identification service ("IDS") application 113d, but not necessarily under the control of the interactive user of device 100. Not be shared), which, in turn, provides specific lifecycle state information to the user of device 100 as output information 115o and I / O interface 114a and the user interface. Database ("UI") application (eg, UI of card management application 113b), which enables the user to change the lifecycle state of the security domain element (eg, in financial transactions) CRS list 151t and to update the lifecycle state of the security domain element), such as to validate the commerce credentials of a particular credential applet to use). Additionally or alternatively, CRS 151 may include CRS access key 151k, which may also be known to a trusted service manager associated with CRS 151 (eg, commercial entity subsystem 400 as shown in FIG. 1B). it can. The CRS access key 151k is used by the commercial entity subsystem 400 and the electronic device 100 as well as and / or instead of the access key 155a and / or the access key 155b to secure the secure element of the commercial entity subsystem 400 and the electronic device 100. Secure transmission between 145 can be enabled.

The IDS application 113d may be running as a background process in the operating system application 103 and / or card management application 113b and / or may be provided by the CMD application 113a, with any suitable application type, such as a daemon. And may act as an IDS manager for receiving and responding to IDS messages that may be sent as well as sent via any suitable IDS service. It is Apple Inc. May be similar to any suitable messaging service, such as iMessage.TM., Etc. (eg, Apple Inc.'s FaceTime.TM. Or Continuity.TM.). It can enable unique end-to-end encryption of messages between the IDS application 113d of the host device 100 and a similar IDS application of another device (e.g. the IDS application of the client device 100 ') . Such a message may be one or more unique identifiers of the communication device (e.g. the unique identifier 119 of the host device and / or the unique identifier 119 'of the client device) and / or one of the specific users of the communication device or / or It may be encrypted using both unique identifiers. Such messages may be communicated as a local link or true device-to-device (eg, peer-to-peer) communication, or communicated via the commercial entity subsystem 400 (eg, via the identity management system component 470) May be Such messaging can be enabled as a low latency solution that allows exchanging data in a structured format (eg, protocol buffer) and / or an unstructured format. The IDS application 113d may be launched automatically if it is not running when an IDS message is received. The IDS application 113d may be operable to present the appropriate user interface and to guide the requested data of the received IDS communication back to the requesting device. The host device's IDS application 113d can operate to launch the card management daemon application 113a of the card management application 113b when the initial request is detected from the client device, and the host device can be 'sleep' low power It can be operated in mode. The IDS application 113d additionally or alternatively operates to manage the "time-out" for such requests, and a request for payment from the client device may be for a period of time (eg, responding to such a request) If the IDS application 113d ceases to operate on the host device for 60 seconds because there is no user interaction with the active host device, the IDS application 113d can operate to make a decision to terminate the request; A "cancel" state can be generated and brought back to the client device, and an appropriate message (eg, "timeout error" to the user of the client device) can be displayed.
Description of FIG. 3 and FIG. 3A to FIG. 3H

  As shown in FIG. 3 and as will be described in more detail, a particular example of host electronic device 100 may be a handheld electronic device such as an iPhone®, and housing 101 may be various Access to input components 110a-110i, various output components 112a-112c, and various I / O components 114a-114d may be permitted, through which device 100 and the user and / or the surrounding environment interact with each other. It can be interfaced. For example, touch screen I / O component 114a may include display output component 112a and associated touch input component 110f, where display output component 112a is for displaying a visual or graphic user interface ("GUI") 180. And may allow the user to interact with the electronic device 100. The GUI 180 may include various layers, windows, screens, templates, elements, menus, and / or other components of the currently executing application (eg, application 103 and / or application 113 and / or application 143). , They may be displayed in all or some of the area of the display output component 112a. For example, as shown in FIG. 3, GUI 180 may be configured to display a first screen 190 having one or more graphical elements or icons 182 of GUI 180. When a particular icon 182 is selected, device 100 may be configured to open a new application associated with that icon 182 and display the corresponding screen of GUI 180 associated with that application. For example, if a particular icon 182 labeled with "Commercial Applications" text display 181 (ie, a particular icon 183) is selected by the user of device 100, device 100 may select a particular third party merchant. An application may be launched or otherwise accessed and may display a screen of a particular user interface, which may include one or more tools or features for interacting with device 100 in a particular manner. Any suitable application (e.g., card on host device 100) that may be used by the device user to make a payment (e.g., on credential of NFC component 120 of host device 100 (e.g., credential of credential SSD 154a) A specific example of such a display GUI180 in the use of physical applications 113b and / or client device 100 'on the merchant application 113'), referring to FIG. 3A~ Figure 3H). In each application, a screen may be displayed on display output component 112a and may include various user interface elements. Additionally or alternatively, for each application, various other types of non-visible information may be provided to the user via various other output components 112 of device 100.

Also, although FIG. 2, FIG. 3 may be described with respect to host device 100, one, some or all of the components of any one or more of device 100 of FIG. 2, FIG. It should be understood that it can be provided to In some embodiments, one or more components of host device 100 may not be provided by client device 100 '(e.g., client device 100' has one or more credentials provisioned thereon) Although it can not include a secure element, client device 100 'can also include a secure element on which one or more native credentials have been provisioned, yet client device 100' has non-native credentials ( For example, native credentials can be used on the host device 100 to further facilitate financial transactions). In some embodiments, the client device 100 'may not include a user interface component that operates to provide a GUI, but may instead be considered as an automated device. Additionally or alternatively, host device 100 may not include a user interface component that operates to provide a GUI, but instead selects and authenticates the use of payment credentials to fund the transaction. Audio output components and mechanical or other suitable user input components.
Description of Figure 4

  Referring now to FIG. 4, FIG. 4 shows further details regarding a particular embodiment of the commercial entity subsystem 400 of system 1. As shown in FIG. 4, the commercial entity subsystem 400 may be a secure platform system, a secure mobile platform ("SMP") broker component 440, an SMP trusted service manager ("TSM") component 450, an SMP The cryptographic services component 460, ("IDMS") component 470, fraudulent system component 480, hardware security module ("HSM") component 490, storage component 420, and / or one or more servers 410 may be included. One, some, or all components of the commercial entity subsystem 400 may be the same as or similar to one or more processor components of the processor component 102 of the device 100, or the memory components 104 of the device 100. May be implemented using one or more memory components that may be and / or one or more communication components that may be the same as or similar to communication component 106 of device 100. One, some or all components of the commercial entity subsystem 400 are managed by a single commercial entity (eg Apple Inc.) which is distinct from the financial institution subsystem 350 and may be independent. It may be owned, at least partially controlled, and / or otherwise provided. The components of the commercial entity subsystem 400 interact with each other and the financial institution subsystem 350 and / or the host electronic device 100 and / or the client electronic device 100 'and / or the retailer subsystem 200 collectively to provide a new security. Layers can be provided and / or a more seamless user experience can be provided.

  The SMP broker component 440 of the commercial entity subsystem 400 may be configured to manage user authentication using a 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 can be a primary endpoint that can control user interface elements (eg, elements of GUI 180) on device 100 and / or device 100 '. The end user device's operating system or other application (eg, application 103, application 113, and / or application 143 of host device 100) may be configured to invoke a particular application programming interface ("API") An application protocol data unit ("APDU"), which may process requests for those APIs, respond with data that may derive the user interface of the device 100, and / or communicate with the secure element of the NFC component 120, SMP broker 440, (E.g., via the communication path 65 between the commercial entity subsystem 400 and the electronic device 100). Such APDUs may be used by the financial institution subsystem via the trusted service manager ("TSM") of system 1 (e.g., the TSM of communication path 55 between the commercial entity subsystem 400 and the financial institution subsystem 350). The commercial entity subsystem 400 may be received from 350. The SMP TSM component 450 of the commercial entity subsystem 400 is configured to provide GlobalPlatform based services or other suitable services that may be used to perform credential provisioning operations on the device 100 from the financial institution subsystem 350. It can be done. The GlobalPlatform, or any other suitable secure channel protocol, allows the SMP TSM component 450 to secure the secure element 145 of the device 100 and the TSM for secure data communication between the commercial entity subsystem 400 and the financial institution subsystem 350. Appropriate communication and / or provisioning of sensitive account data between can be enabled.

The SMP TSM component 450 can be configured to use the HSM component 490 to protect its key and generate a new key. SMP encryption service component 460 of commercial entity subsystem 400 may be configured to provide key management and encryption operations that may be provided for user authentication and / or confidential data transmission between various components of system 1 . The SMP Cryptographic Services component 460 can utilize the HSM component 490 for secure key storage and / or opaque cryptographic operations. The payment encryption service of the SMP Encryption Service Component 460 is configured to interact with the IDMS Component 470, and the information associated with the credit card on the file or user account of the commercial entity (e.g. Apple iCloud (TM) account) Other types of commerce credentials associated with) can be obtained. Such payment encryption service may be the only one of the commercial entity subsystem 400 that may have clear text (ie, not hashed) information describing the commerce credentials (eg, credit card number) of that user account in memory. Can be configured to be a component of The IDMS component 470 may use a host device 100 and a client device 100 ', such as an identification service ("IDS") transport (e.g., using a commercial entity specific service (e.g., iMessage (R) by Apple Inc.)). , And / or may be configured to enable and / or manage any appropriate communication between them. For example, a particular device may be registered automatically or manually for such a service (eg, all devices in the ecosystem of commercial entity 400 are automatically registered for the service) obtain). Such a service may require an active registration before messages can be sent using that service (eg, using the IDS application 113d of host device 100) end-to-end encryption mechanism Can be provided. The IDMS component 470 and / or any other server or portion of the commercial entity subsystem 400 may state the status of any credentials provisioned on any electronic device associated with a given user account or otherwise. It can operate to identify or otherwise look up and associate with a particular user account (eg, a commercial entity subsystem 400 of a family account having a commercial entity subsystem 400 is a plurality of host devices) Can operate to efficiently and effectively identify one or more non-native payment credentials that may be available to a particular client device. The commercial entity fraud system component 480 of the commercial entity subsystem 400 is based on the commerce credentials and / or data known to the commercial entity about the user (eg, under the control of the commercial entity's user account and / or the commercial entity). Commerce credentials, based on other suitable data that may be, and / or data associated with any other suitable data that may not be under the control of the financial institution subsystem 350 (eg, commerce credential information) May be configured to perform a commercial entity fraud check. Commercial entity fraud system component 480 may be configured to determine the commercial fraud score of the credential based on various factors or thresholds. Additionally or alternatively, the commercial entity subsystem 400 can include a store 420, which sells / rents media played by the various service providers (devices 100/100 'to the users of the device 100) Store for iTunesTM, Apple App StoreTM for selling / renting applications for use with 100/100 'devices, storing data from devices 100/100', and / or multiple users Associate devices and / or multiple user profiles with each other, Apple iCloudTM Service, Apple Online Store for purchasing various Apple products online, etc.). Merely by way of example, store 420 may be configured to manage application 113 and provide it to device 100 (eg, via communication path 65), which may be a bank application, a commercial application, an email application, etc. It may be any suitable application, such as 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 the commercial entity subsystem 400 to communicate data between various components of the commercial entity subsystem 400 (e.g., at least one communication path 495 of FIG. 4). Data and / or between the commercial entity subsystem 400 and other components of the system 1 (eg, via the communication path 55 of FIG. 1A). Host electronic device 100 via communication path 65 of 1A and / or client electronic device 100 'via communication path 95 of FIG. 1A).
Explanation of FIG. 5

  FIG. 5 is a flowchart of an exemplary process 500 for conducting financial transactions using an electronic device having non-native payment credentials. Process 500 is shown to be implemented by host electronic device 100, client electronic device 100 ′, merchant subsystem 200, acquisition bank subsystem 300, commercial entity subsystem 400, and financial institution subsystem 350. However, it should be understood that process 500 may be implemented using any other suitable components or subsystems. Process 500 may provide a seamless user experience for securely and efficiently performing financial transactions with merchant subsystem 200 via client device 100 ′ while using payment credentials from host device 100. it can.

  At step 502 of the process 500, potential transaction data may be communicated from the merchant subsystem 200 to the client device 100 '. For example, at some point during user interaction with the client device 100 'executing the merchant application 113' (eg, while the user is shopping online for the merchant's goods or services) Transaction data may or may not be indicative of any suitable data associated with potential financial transactions between a user of client device 100 'and a retailer of merchant subsystem 200, from or any of merchant subsystem 200 May be communicated to the client device 100 'from any other suitable entity. It is for (i) specific merchant information, such as a unique merchant identifier, (ii) identification of a particular currency (eg, yen, pound, dollar, etc.) used to settle the transaction, and / or for the transaction. Identification of the amount of a particular currency to be settled, and / or identification of a particular item or service to be purchased or rented or otherwise settled, and / or identification of a default or initial shipping address used Etc., (iii) information indicating one or more types of payment methods acceptable to the merchant for the transaction (eg, a list of payment cards that can be used for purchase (eg, MasterCard) Is not Visa)), iv) a unique merchant-based transaction identifier (eg, executed) (A) any suitable data element, such as a three- or four-character alphanumeric string, which may be randomly or uniquely generated by the merchant subsystem 200 for association with the It is not limited. Such potential transaction data may be used to complete financial transactions, such as contact information fields (eg phone number, email address, mailing address) of the purchasing customer, with or without associated data. May contain any suitable number and type of data fields, which may be required or at least be used, and some fields may be captured and included as part of such potential transaction data And / or some fields may not be captured as part of such potential transaction data, and may be opened during process 500 to await capture. Such potential transaction data of step 502 may be referred to herein as a PKPaymentRequest. Alternatively, in some embodiments, at step 502, the user actively interacts with the client device 100 'to make potential transaction data associated with the merchant subsystem 200 available to the client device 100'. You do not have to. Instead, as an example, the client device 100 ′ may determine that a particular product should be purchased and obtain associated transaction data from at least one particular merchant of that particular product To interact with one or more retailers (e.g., client device 100 'may be a consumer electronics product and must purchase a consumer electronics product (e.g. a washing machine requires more laundry detergent) Can be configured to detect (or detect calendar events preset by the user to purchase more detergent on a particular day). You can automatically identify the specific merchant that offers the best deal for you, and automatically interact with that merchant to get products from that merchant It is possible to acquire the transaction data for input), all automatically without any active interaction by the user of the client device 100 'may be configured. The potential transaction data of step 502 includes all data required for the client device 100 'or the available host devices 100 associated with the client device 100', and financial transactions associated with the potential transaction data. The settled credential data may be securely generated and provided to the merchant subsystem 200 to fund the transaction. Such potential transaction data may be communicated by the merchant subsystem 200 to the client device 100 'in any suitable manner at step 502 (eg, such potential transaction data may be From the server 210 of the subsystem 200 to the communication component 106 'of the client device 100' via the communication path 15 using any suitable communication protocol, or with the terminal 220 using any suitable communication protocol It may be transmitted via a contactless proximity based communication channel between NFC components 120 ').

  At step 504 of process 500, at least one available non-native payment source can be identified to potentially fund financial transactions such as the transactions associated with the transaction data of step 502. This may be done automatically by the client device 100 'in response to receiving the transaction data at step 502, or may occur periodically, independently of receiving the transaction data, or the client Depending on the requirements made by the user of device 100 ', this may occur at any suitable time. For example, in response to the transaction data being received by the client device 100 'in step 502, the client device 100' generates payment credential data on at least one host electronic device (eg, host element 100, etc., secure element) Can be configured to attempt to identify any electronic devices (which can be configured to use) to at least partially fund financial transactions associated with the transaction data of step 502 It may be possible. Any suitable non-native payment source can be identified using any suitable technique. For example, a beacon signal may be sent by the client device 100 'as a discovery request that may request a response from any host device that may receive the beacon (eg, the beacon or a particular communication protocol of a beacon Any host device within a particular distance of the client device 100 'that operates to communicate using the can be presented by the client device 100' and can be read by the scanner of one or more host devices, a quick response ( "QR") code or any other suitable code). Additionally or alternatively, client device 100 'can send a discovery request to one or more specific host devices using any suitable communication path and protocol (eg, contact of device 100' One or more devices identified in the destination application and / or manually identified by the user of the device 100 '(eg, a telephone number or an email address or any suitable unique device identifier (eg, a host device) 100) by the device identifier 119)). Such discovery requests may be used to fund information (e.g., the device identifier 119 'of the client device 100') and / or potential financial transactions (e.g., by a merchant) identifying the client device 100 '. It may include any suitable information, such as information identifying one or more specific payment types that may be acceptable (eg, information identifying a payment type that may be identified by the potential transaction data of step 502). Well, accordingly, identify any suitable information identifying the responding host device (eg, device identifier 119 of host device 100), and / or one or more payment types that may be available to that host device Any appropriate information (eg, host device 10) AID 155aa and / or AID 155ba), and such payment type identification of the response can include only each type matching the type of discovery request, or all payment types available to the response host And / or any suitable information identifying the location of the responding host device and / or any suitable information identifying the status of the host device (eg, active, inactive, disconnected, etc.) Any suitable information may be required, such as any suitable information to identify.

  The commercial entity subsystem 400 or any other entity may participate in the identification of the host device 100 by the client device 100 'at step 504. For example, as described above, the commercial entity subsystem 400 may be any suitable service or device made available to the client device 100 'and / or the host device 100, such as iCloudTM and / or iMessageTM. Acting to manage any other identity service transport, making associations between different devices, and / or automatically determining the status and / or capabilities of various devices (E.g., a family can have an account with the commercial entity subsystem 400 that can be associated with a plurality of other devices, including client device 100 'and host device 100). As an example, in step 504, the client device 100 'sends a discovery request to the commercial entity subsystem 400 for the status of all other devices associated with the client device 100's account, and the commercial entity subsystem 400, Get one, several, or each one state of such devices (e.g., using the identification service transport or otherwise), each one of these states with the client device 100 ' Sharing may be included, and the state may indicate the availability of the host device 100 and the identification of at least one payment type available to the host device 100 (e.g. the state of the host device identifier, AID and each payment application) (Eg, in a visa / app Use can and Discover / app not available) and / or status of the device itself). Each host device can have unique settings for such requests and potential responses (e.g., even if a particular host device is configured to respond only to status requests from particular client devices) (E.g., only devices associated with the same account in the commercial entity subsystem 400, only devices associated with contacts in the contact application for that particular host device, etc.). Such discovery request and / or discovery response for validating identification of one or more available payment sources in step 504 may be performed between client device 100 ′ and host device 100 (eg, any suitable Communicate directly (eg, peer-to-peer) using communication protocols (eg, peer-to-peer) or between client device 100 'and commercial entity subsystem 400 (eg, using any suitable communication protocol) Communicated in any suitable manner, such as via path 95) and between commercial entity subsystem 400 and host device 100 (eg, via communication path 65 using any suitable communications protocol) (Eg, identification service transport or commercial entity sub Using any other suitable communication service of the stem 400).

  At step 506 of process 500, client device 100 'can communicate payment request data to at least one specific host electronic device 100. Such payment request data may include any suitable information that may be provided by client device 100 'to identify one or more specific features of the potential transaction being funded. For example, similar to the potential transaction data of step 502, the settlement request data of step 506 can include any suitable data associated with the potential financial transaction to be funded. That is, (i) specific merchant information, such as the identification of a merchant identifier that may identify the particular merchant subsystem 200 that provided at least a portion of the potential transaction data of step 502, (ii) the transaction Identification of the particular currency (eg, yen, pound, dollar, etc.) used to settle the transaction, and / or identification of the particular currency amount to be settled for the transaction, and / or purchased or rented Specific transaction information, such as identification of a specific goods or service to be settled separately or / and identification of a default or initial shipping address used, (iii) acceptable to the merchant for the transaction 1 Information indicating one or more types of payment methods (for example, a list of payment cards that can be used for purchase (eg (E.g., MasterCard but not Visa)), (iv) a unique merchant-based transaction identifier (e.g., randomly or uniquely generated by merchant subsystem 200 for association with the transaction being performed). (V) a unique client-based transaction identifier (e.g., a client device 100 for association with the transaction being executed), such as any three- or four-character alphanumeric string, which may be 'Any suitable data element, such as a three or four character alphanumeric string, which may be randomly or uniquely generated by', and / or (vi) a unique client-based payment request identifier (eg, a row) For association with the payment request being It may be randomly or uniquely generated by cement device 100 ', such as an alphanumeric string of 3 or 4 characters, any suitable data elements), including, but not limited to. In some embodiments, such payment request data may be encrypted or otherwise formatted or processed by the commercial entity subsystem 400 prior to communicating with the target host device 100. The target host device 100 of the payment request data of step 506 may be selected based on the identification of any available payment source at step 504 (eg, based on any suitable discovery response of step 504) Or, it may be selected independently of any identification made in step 504. The payment request data of step 506 can include an identifier of a particular payment type that can be known by client device 100 'that the target host device is available (eg, by client device 100' at step 504 or Any identification data obtained in other ways (e.g. based on host device AID data). The user of client device 100 'selects target host device 100 for payment request data of step 506 from a list of potential target host devices that may be provided based on the identification of one or more payment sources in step 504. Or the client device 100 'may identify any suitable specific target host device in any suitable manner (eg, within the contact application of the device 100', and / or the device Devices that are manually identified (e.g., by telephone number or email address or any suitable unique device identifier) by the 100 'user. Alternatively, target host device 100 of the payment request data of step 506 may be automatically selected by client device 100 'to any identifying data obtained by client device 100' at step 504 (e.g. device 100) 'May be customized or otherwise configured to select one host device from the group of available host devices based on any suitable property, eg, to client device 100'. A host device having the shortest distance, or a host device having the highest priority of available host devices (e.g., as may be determined by the application's default or customized settings of device 100 ') and the like. Such payment request data of step 506 may be referred to herein as PKRemotePaymentRequest, and may include any suitable data. It may (1) be PKPaymentRequest of step 502 (eg, may be wrapped in PKRemotePaymentRequest), (2) any suitable data identifying the selected target host device, which may be referred to herein as PKRemoteDevice ( For example, the host device identifier 119 of the host device 100, which may be included in the discovery response of step 504), (3) a specified or default specification of a target host device, which may be referred to herein as a SelectedApplicationIdentifier Any suitable data identifying the payment (eg, may be included in the discovery response of step 504, either automatically at the client device 100 'or by the user And / or (4) any suitable identifier identifying a unique identifier associated with the payment request, which may be selected, such as the AID 155aa of the secure element 145 of the target host device 100, and / or (4) herein as a RemotePaymentIdentifier Data including, but not limited to, data (eg, unique values that can be used to identify payment requests via clients and host devices of the system, and can be generated by client device 100 or otherwise) . Such payment request data may be directly (eg, peer-to-peer) between the client device 100 'and the host device 100 (eg, via communication path 99 using any suitable communication protocol), or the client Between the device 100 'and the commercial entity subsystem 400 (e.g. via the communication path 95 using any suitable communication protocol) and between the commercial entity subsystem 400 and the host device 100 (e.g. any) Communication may be performed in any suitable manner in step 506, such as via communication path 65 using an appropriate communication protocol (eg, identification service transport or any other appropriate of the commercial entity subsystem 400) Communication service).

  Host payment credential data may be at least partially generated by host device 100 at step 508 of process 500, and then, at step 510, the host payment credential data may be generated by the host device 100 as a commercial entity It may be communicated to the system 400. For example, in response to receiving the payment request data at step 506, the host device 100 operates to identify specific credentials of the secure element 145 used to attempt to fund the transaction. (E.g., based on SelectedApplicationIdentifier of payment request data of step 506), host payment credential data associated with that particular credential is generated at step 508, and then the payment request data of step 506 (e.g., PKPaymentRequest). It may be communicated as host transaction data at step 510 along with at least a portion of the merchant identification information). Such host payment credential data includes any suitable data that can operate to securely prove proper ownership of a particular secure element credential of the host device 100 (eg, credentials of SSD 154a) Can. (I) token data (eg, DPAN, DPAN expiration date, and / or CVV of credential information 161a of SSD 154a); (ii) cryptographic data (eg, SSD 154a and shared secret of financial institution subsystem 350 (eg, key) 155a ′) as well as any other suitable information (eg, part or all of token data, information identifying the host device 100, cost and / or currency, any suitable counter value, nonce, etc., Step 502 A ciphertext that may be generated by the secure element 145 using information identifying part or all of the potential transaction data of the, which is to generate the cryptographic data independently using the shared secret May be made available to the host device 100 and may System 350 (e.g., in step 520, or otherwise) may be made available to), including, but not limited to. The host transaction data may then be communicated from the host device 100 to the commercial entity subsystem 400 at step 510, such host transaction data including the specific host payment credential data and funds generated at step 508. Any other suitable data associated with the potential financial transaction to be provided may be included (eg, as provided to the host device 100 by the payment request data of step 506). It is used for (i) specific merchant information, such as the identification of a retailer identifier that can identify the particular merchant subsystem 200 that provided the potential transaction data of step 502, (ii) transaction settlement Identification of the particular currency being used (eg, yen, pound, dollar, etc.), and / or identification of the particular amount of currency being settled for the transaction, and / or purchased or rented or otherwise settled Specific transaction information, such as the identification of the specific goods or services being performed and / or the identification of the default or initial shipping address used, (iii) a unique merchant-based transaction identifier (eg being performed) Generated by the merchant subsystem 200) for association with the transaction) iv) Unique client-based transaction identifier (e.g. generated by the client device 100 'for association with the transaction being executed), (v) unique client-based payment request identifier (e.g. payment request And / or (vi) a unique host-based transaction identifier (eg, randomly or uniquely by host device 100 for association with a transaction being performed). Including any suitable data element), such as, but not limited to, three or four-character alphanumeric strings that can be generated. Thus, the host transaction data communicated from the host device 100 to the commercial entity subsystem 400 is, at step 510, of the potential transaction data of step 502 and / or the payment request data of step 506 (eg, a merchant identifier). Host payment credential data (eg, received by the financial institution subsystem 350), which may include some or all of the above, and at least two types and / or divisible portions of data based on the specific credentials of the device 100). When done, it may include any suitable token data and any suitable cryptographic data that may enable more secure financial transactions (eg, ciphertext verification).

  The host device 100 communicates all or at least a portion of the host payment credential data of the host transaction data (e.g., token data and / or ciphers of the host payment credential data) before communicating the transaction data to the commercial entity subsystem 400 at step 510. Data) can be encrypted with a financial institution key. For example, secure element 145 may use any suitable credential key or element available to secure element 145 (eg, credential key 155a ') that is also available to financial institution subsystem 350, in any suitable manner. At least a portion of host transaction data may be encrypted or signed. Additionally or alternatively, before communicating the transaction data to the commercial entity subsystem 400 in step 510, the host device 100 either fully or at least partially host transaction data (eg, host payment credential data). May be encrypted with a commercial entity key (e.g., regardless of whether any portion of host transaction data is first encrypted with a financial institution key). For example, secure element 145 may encrypt at least a portion of host transaction data using access key 155a of secure element 145, access key 155b, CRS 151k, and / or ISD key 156k, which may be a commercial entity sub System 400 (eg, any shared secret between host device 100 and commercial entity subsystem 400) may also be accessible. Additionally or alternatively, secure element 145 may sign at least a portion of host transaction data with CASD 158k accessible to commercial entity subsystem 400. In some embodiments, such commercial entity key or access key is a commercial entity public key associated with the scheme of the commercial entity subsystem 400, and the commercial entity subsystem 400 is associated with the commercial entity private key associated with it. You can access to The commercial entity subsystem 400 can provide such a commercial entity public key to the financial institution subsystem 350, and the financial institution subsystem 350 can share the commercial entity public key with the host device 100 (see FIG. For example, when provisioning credential data on host device 100 (eg, at step 604 of process 600)). The host transaction data is transmitted by the host device 100 to the commercial entity subsystem 400 regardless of whether it is at least partially encrypted and / or signed by any suitable financial institution key and / or any commercial entity key. In step 510, for example, such host transaction data may be communicated from communication component 106 of host device 100 to server 410 of commercial entity subsystem 400 in any suitable manner. Can be sent using any suitable communication protocol).

  Next, at step 512, the process 500 includes the commercial entity subsystem 400 to at least host settle host transaction data using the shared transaction with the merchant subsystem 200 with the host transaction data received at step 510. By encrypting the credential data, it can be further secured, and the host payment credential data may not be utilized to fund transactions with entities other than the merchant subsystem 200. For example, if the host transaction data of step 510 is encrypted with any commercial entity key, commercial entity subsystem 400 may operate to decrypt that data at step 512 (eg, commercial entity sub) Server 410 of system 400 can receive host transaction data and then decrypt / design that host transaction data (eg, access key 155a, access key 155b, CRS 151k, CASD 158k, and / or commercial entity subsystem 400) with ISD key 156k)). Communicate host transaction data between host device 100 and commercial entity subsystem 400 in encrypted / signed form using commercial entity key known to both host device 100 and commercial entity subsystem 400 By doing so, process 500 can prevent host transaction data from being intercepted and used by an entity that does not have access to the commercial entity key. Further, at step 512, the commercial entity subsystem 400 can associate at least a portion of the host transaction data with a merchant key (eg, a merchant key that may be associated with the merchant subsystem 200 in which the particular transaction is funded). It may operate to encrypt or otherwise reformat 157 and / or merchant key 157 '). Such a merchant key may be determined by the merchant entity subsystem 400 via the table 430 and may be accessible thereto (eg, identify the merchant key associated with the merchant identifier of the host transaction data of step 510) By doing so, it may be provided from the client device 100 'to the host device 100 by the payment request data of step 506, which is from the merchant subsystem 200 to the client device 100' by the potential transaction data of step 502. May be provided). For example, as described above, in some embodiments, the potential transaction request data communicated from the merchant subsystem 200 to the client device 100 'in step 502 includes a merchant identifier indicative of the merchant subsystem 200. be able to. For example, the merchant identifier may be associated with the online resource 113 'utilized by the client device 100' when the potential transaction data is received at step 502. The merchant identifier may be received by the commercial entity subsystem 400 at step 512 and utilized to identify a particular one of the many merchant keys accessible by the commercial entity subsystem 400 (e.g., , The merchant key 157 ') through the utilization table 430 of the commercial entity subsystem 400, and then the commercial entity subsystem 400 uses at least a portion of the host transaction data using the identified merchant key to Can be encrypted (eg, at least host payment credential data of host transaction data). Such host payment by encrypting such host payment credential data using such merchant key (e.g., a key that only the merchant entity subsystem 400 and the merchant subsystem 200 can know) In a manner that can be securely communicated from the merchant entity subsystem 400 to the merchant subsystem 200 without the credential data being intercepted by other entities and used to fund transactions with another merchant , Can be secured.

  Next, at step 514, process 500 may include a commercial entity subsystem 400 that communicates the secure host transaction data of step 512 to host device 100. For example, such merchant key encryption host payment credential data may be secured host at step 514 from the commercial entity subsystem 400 to the host device 100 via the communication path 65 using any suitable communication protocol. It may be sent as at least part of transaction data. Such secure host transaction data is optional in addition to merchant key encryption host payment credential data, such as any suitable data of step 502 and / or step 506 associated with the funded transaction. Appropriate data can be included. It is used for (i) specific merchant information, such as the identification of a retailer identifier that can identify the particular merchant subsystem 200 that provided the potential transaction data of step 502, (ii) transaction settlement Identification of the particular currency being used (eg, yen, pound, dollar, etc.), and / or identification of the particular amount of currency being settled for the transaction, and / or purchased or rented or otherwise settled Specific transaction information, such as the identification of the specific goods or services being performed and / or the identification of the default or initial shipping address used, (iii) a unique merchant-based transaction identifier (eg being performed) Generated by the merchant subsystem 200) for association with the transaction) iv) Unique client-based transaction identifier (e.g. generated by the client device 100 'for association with the transaction being executed), (v) unique client-based payment request identifier (e.g. payment request Including (i) a unique host-based transaction identifier (eg, generated by host device 100 for host device transaction data), and / or (vi) generated by client device 100 'for association of Not limited to these. Thus, the secure host transaction data communicated from the commercial entity subsystem 400 to the host device 100 at step 514 may be part or all of the potential transaction data of step 502 and / or part of the settlement data of step 506 or All can be included as well as secure host payment credential data.

  Next, at step 516 of process 500, host device 100 receives the secure host transaction data communicated from commercial entity subsystem 400 at step 514 and transmits the secure host transaction data to the client device in any suitable manner. It can be shared with the 100 '. For example, secure host transaction data may include any suitable encryption or otherwise reformatting of a portion of data with a shared secret or key unique to host device 100 and / or client device 100 '. Host device 100 and the client via communication path 99 using a communication protocol (eg, Secure Transport Protocol (eg, Apple Inc.'s iMessage (TM)) or email or any other suitable method) It may be shared between devices 100 '. In some embodiments, such secure host transaction data is communicated between host device 100 and client device 100 'via contactless proximity based communication between NFC component 120 and NFC component 120'. May be Alternatively, although not shown, such secure host transaction data may be transferred from the commercial entity subsystem 400 to the client device 100 'in any suitable manner (e.g., via the host device 100 and step 514). Directly) (via communication path 95) using any suitable communication protocol, the commercial entity subsystem 400 utilizes the optional client device identifier of the host transaction data of step 510 to Device 100 'can be identified. Alternatively, although not shown, such secure host transaction data may be transferred from the commercial entity subsystem 400 to the merchant subsystem 200 without the host device 100 and / or the client device 100 'and steps 514 and 516. , And may be communicated directly in any suitable manner (eg, via communication path 85 using any suitable communication protocol), and the commercial entity subsystem 400 may perform the processing of the host transaction data of step 510. Any merchant identifier may be used to identify the target merchant subsystem 200. Alternatively, although not shown, such secure host transaction data may be transferred from the commercial entity subsystem 400 to the financial institution subsystem 350, the host device 100 and / or the client device 100 'and / or the retailer subsystem 200 and Communication may be performed directly in any suitable manner (eg, via communication path 55 using any suitable communication protocol) without going through steps 514-518. The secure host transaction data that may be received by the client device 100 'at step 516 is any in addition to merchant key encryption host payment credential data such as any appropriate data associated with the funded transaction. Appropriate data can be included. It is used for (i) specific merchant information, such as the identification of a retailer identifier that can identify the particular merchant subsystem 200 that provided the potential transaction data of step 502, (ii) transaction settlement Identification of the particular currency being used (eg, yen, pound, dollar, etc.), and / or identification of the particular amount of currency being settled for the transaction, and / or purchased or rented or otherwise settled Specific transaction information, such as the identification of the specific goods or services being performed and / or the identification of the default or initial shipping address used, (iii) a unique merchant-based transaction identifier (eg being performed) Generated by the merchant subsystem 200) for association with the transaction) iv) Unique client-based transaction identifier (e.g. generated by the client device 100 'for association with the transaction being executed), (v) unique client-based payment request identifier (e.g. payment request Including (i) a unique host-based transaction identifier (eg, generated by host device 100 for host device transaction data), and / or (vi) generated by client device 100 'for association of Not limited to these. Thus, secure host transaction data shared with the client device 100 ′ may be part or all of the potential transaction data of step 502 and / or part or all of the payment request data of step 506, and the secure host It can include payment credential data.

  Next, at step 518 of process 500, client device 100 'may include the merchant key encryption host payment credentials for secure host transaction data using the secure host transaction data shared at step 516. By sending client transaction data to the commerce subsystem 200, transactions with the merchant subsystem 200 can be funded. For example, such client transaction data may be communicated via communication path 15 using any suitable communication protocol and / or as contactless proximity based communication between NFC component 120 'and merchant terminal 220. It may be sent from the communication component 106 'of the client device 100' to the server 210 of the merchant subsystem 200. Client transaction data that may be communicated to the merchant subsystem 200 by the client device 100 '(e.g., using the merchant resource 113') may be any suitable data associated with the funded transaction, etc. In addition to the secure host transaction data retail key encrypted host payment credential data, any suitable data may be included. It is used for (i) specific merchant information, such as the identification of a retailer identifier that can identify the particular merchant subsystem 200 that provided the potential transaction data of step 502, (ii) transaction settlement Identification of the particular currency being used (eg, yen, pound, dollar, etc.), and / or identification of the particular amount of currency being settled for the transaction, and / or purchased or rented or otherwise settled Specific transaction information, such as the identification of the specific goods or services being performed and / or the identification of the default or initial shipping address used, (iii) a unique merchant-based transaction identifier (eg being performed) Generated by the merchant subsystem 200) for association with the transaction) iv) Unique client-based transaction identifier (e.g. generated by the client device 100 'for association with the transaction being executed), (v) unique client-based payment request identifier (e.g. payment request Including (i) a unique host-based transaction identifier (eg, generated by host device 100 for host device transaction data), and / or (vi) generated by client device 100 'for association of Not limited to these. Thus, the client transaction data shared with the merchant subsystem 200 may be partially or wholly of the potential transaction data of step 502 and / or partially or fully of the payment request data of step 506 and secure as at least step 512. Host transaction data retail key encryption host settlement credential data. By communicating the merchant key encrypted host payment credential data of the secure host transaction data as at least a part of the client transaction data, the process 500 retails such merchant key encrypted host payment credential data. The financial transaction can be funded, enabling communication to the subsystem 200, without the merchant subsystem 200 having to communicate with the host device 100, and / or the commercial entity subsystem 400 further step 508. The host payment credential data generated by the host device 100 at the end of the retail entity does not have access to the merchant key (eg, the host device 100 and / or the client device 100 ')). Money transaction can be prevented from being used to supply the. Alternatively, although not shown, at least the merchant key encrypted host payment credential data of the secure host transaction data of step 514 may be in any suitable manner, without going through client device 100 ′ and additional step 518. The host device 100 may be communicated directly to the merchant subsystem 200, which utilizes the optional merchant identifier of the payment request data of step 506 to identify the target merchant subsystem 200. be able to. Additionally or alternatively, although not shown, the host device 100 encrypts the host payment credential data of step 508 with the appropriate merchant key on the host device 100 rather than on the commercial entity subsystem 400 Operation (eg, if such a merchant key is made accessible to host device 100). Alternatively, although not shown, at least the merchant key encrypted host payment credential data of the secure host transaction data of step 512 may be added to host device 100 and / or client device 100 'and thus additional steps 516 and 518 It may be communicated directly from merchant entity subsystem 400 to merchant subsystem 200 in any suitable manner (e.g., via communication path 85 using any suitable communications protocol) without The commercial entity subsystem 400 can use the optional merchant identifier of the host transaction data of step 510 to identify the target merchant subsystem 200. Alternatively, although not shown, at least the merchant key encrypted host payment credential data of the secure host transaction data of step 512 is not shown in FIG. Communicate directly from the commercial entity subsystem 400 to the financial institution subsystem 350 in any suitable manner (e.g., via the communication path 55 using any suitable communication protocol), but not through It may be done. In other embodiments, the host device 100 can communicate secure host transaction data directly to the merchant subsystem 200 at step 516 rather than via the client device 100 '. In yet another embodiment, the commercial entity subsystem 400 can communicate secure host transaction data directly to the client device 100 'at step 514 rather than via the host device 100. In yet another embodiment, the commercial entity subsystem 400 communicates secure host transaction data directly to the merchant subsystem 200 at step 514 rather than through the host device 100 and / or the client device 100 '. can do.

  After the merchant key encrypted host payment credential data of the secure host transaction data of step 512 is received by the merchant subsystem 200, the process 500 may utilize the merchant key encrypted host payment credential data. At 200, financial transactions can be performed with the acquiring bank 300 and / or the financial institution subsystem 350, including 200. For example, the merchant subsystem 200 decrypts the merchant key encryption host payment credential data with a merchant key (eg, the merchant key 157 and / or the merchant key 157 ') accessible to the merchant subsystem 200. Can then be transferred to the acquiring bank 300 and / or financial institution subsystem 350 (eg, via communication path 25 and / or communication path 35), the host settlement credential A funding account associated with the data may be identified and used by the acquiring bank 300 and / or the financial institution subsystem 350 to fund financial transactions. Next, after such a transaction is performed at step 520, process 500 may, at step 522, use any suitable confirmation information to determine the state of the transaction (eg, the transaction's status for client device 100 '). Retailer subsystem 200 may be included (e.g., as any suitable payment receipt data and / or any suitable insufficient funding message data) to confirm (perform or reject). The client device 100 ′ then interacts with the host device 100 with such confirmed transaction status (eg, as any suitable payment receipt data and / or any suitable insufficient funding message data) at step 524. It can operate to share. If the transaction is successful, the confirmation information may close the transaction (eg, the transaction identified by the unique RemotePaymentIdentifier of the payment request data) at the client device 100 'at step 522 and / or at the host device 100 at step 524. Can operate. Additionally or alternatively, if the transaction was not successful, the confirmation may or may not act to close the transaction (eg, no valid funding is available or the host device is fraudulent) Close the transaction, but leave it open to allow updates if an invalid shipping address is determined).

The steps shown in process 500 of FIG. 5 are merely exemplary, and existing steps may be modified or omitted, additional steps may be added, and the order of particular steps may be changed. Be understood. For example, in some embodiments, a process similar to process 500 may be performed without the commercial entity subsystem 400. Instead, the host device 100 accesses the merchant key associated with the merchant subsystem 200 and derives merchant key encryption host payment credential data (e.g., at step 508, the host device 100 proceeds to step 512). Such merchant key encrypted host payment credential data to client device 100 'and / or to enable the operation to be securely funded with host payment credential data), and then the transaction. Or may be operative to communicate with merchant subsystem 200. By communicating the merchant key encryption host payment credential data with the merchant subsystem 200, the process 500 determines that financial transactions initiated between the client device 100 'and the merchant subsystem 200 can be performed by the client device 100'. The host device 100 can be enabled to be at least partially funded with native payment credentials rather than with non-native payment credentials. Process 500 enables communication of such merchant key encrypted host payment credential data to merchant subsystem 200, which is one of host device 100 and / or commercial entity subsystem 400. The financial transaction may be funded without having to communicate with or be aware of the existence, and further, the host payment credential data generated by the host device 100 at step 508 may be used by such a merchant. It can also be prevented from being used by an entity that does not have access to the key. In some embodiments, host device 100 is configured to communicate with commercial entity subsystem 400 seamlessly and transparently to the user of host device 100 (e.g., at steps 510-514) and is at a higher level Specific data may be shared and / or received which may enable the security or efficiency of the After the user of host device 100 chooses to use particular credentials to perform a financial transaction based on the payment request data at step 508, the remaining steps of process 500 are transparent to that user (E.g., steps 510-524 may be performed without any further user interaction with host device 100 and may appear momentarily to the user of host device 100). The process 500 may be made visible to the user of the host device 100 as if the status of the financial transaction has been confirmed by the secure host payment credential data being automatically and momentarily sent to the merchant subsystem 200 after step 508 There is sex. Additionally or alternatively, after the user of client device 100 'has identified a particular payment source to which payment request data is communicated at step 506, the remaining steps of process 500 are transparent to that user. (E.g., steps 508-524 may be performed without any further user interaction with client device 100 'and may appear momentarily to the user of client device 100'). As after process 506 (eg, after selecting a host device), process 500 automatically and momentarily sends secure host payment credential data to retailer subsystem 200 as if the status of the financial transaction has been confirmed. May be visible to the user of the client device 100 '. Alternatively, in some embodiments, process 500 may be performed completely transparent to the user of client device 100 '(e.g., client device 100' is active when financial transactions are performed). To automatically determine when payment request data for such financial transactions should be sent automatically to one or more available payment sources without interaction with the client device 100 'of the client device user Can be configured).
Explanation of FIG.

  FIG. 6 is a flowchart of an exemplary process 600 for performing a financial transaction using an electronic device having non-native payment credentials. Process 600 is shown to be implemented by host electronic device 100, client electronic device 100 ', merchant subsystem 200, acquisition bank subsystem 300, commercial entity subsystem 400, and financial institution subsystem 350. However, it should be understood that process 600 may be implemented using any other suitable components or subsystems. Process 600 provides a seamless user experience for securely and efficiently executing financial transactions with merchant subsystem 200 via client device 100 'while using payment credentials from host device 100. be able to. To facilitate the following discussion of the operation of system 1 for performing a financial transaction according to process 600 of FIG. 6, the various components of system 1 of the schematic of FIGS. Reference is made to the front view of the 3 H screens 190-190 h, which during such a transaction may be displayed on the graphical user interface of the host device (HD) 100 (e.g. the card management application 113 b or any suitable of the host device 100 And / or a graphical user interface of a client device (CD) 100 '(eg, a merchant application 113' or client device of the client device 100 '). It may represent GUI) that may be provided by any suitable settlement application 100 '. The operations described may be accomplished by a wide variety of graphical elements and vision schemes. Thus, the embodiments of FIGS. 3-3H are not intended to be limited to the exact user interface convention adopted herein. Rather, embodiments can include a wide variety of user interface styles.

  Process 600 may begin at step 602, where host access data 652 (eg, host access data 652 of FIG. 1B) may be provisioned by the commercial entity subsystem 400 on the secure element of the host device 100. For example, an access SSD (eg, SSD 154 b) may be provisioned on the secure element 145 of the host device 100 as access data 652 from the server 410 of the commercial entity subsystem 400 so that the host device 100 communicates with the merchant subsystem 200. Execution of financial transactions can be enabled more securely. As mentioned above, the access SSD 154b may be at least partially provisioned directly to the secure element 145 of the host device 100 from the commercial entity subsystem 400 (e.g., the server 410 of the commercial entity subsystem 400 and the host device 100). As host access data 652 via communication path 65 between communication components 106, it may then be passed from communication component 106 to secure element 145 (eg, via bus 118). Host access data 652 via path 65 may be provisioned on secure element 145 of host device 100 as at least part and all of access SSD 154 b and may include access applet 153 b and / or access key 155 b. Step 602 may be performed at least in part when host device 100 is initially configured (eg, by commercial entity subsystem 400 before host device 100 is sold to a user). Alternatively or additionally, step 602 may be performed at least in part depending on the user of host device 100 initializing secure element 145 of NFC component 120. Additionally or alternatively, host access data 652 may include ISD key 156k for ISD 152 of secure element 145, an access to enable secure transmission between commercial entity subsystem 400 and host device 100. It may be used in addition to or instead of the key 155b. Additionally or alternatively, host access data 652 may include CRS 151k of CRS 151 of secure element 145 of host device 100 and / or CASD 158k of CASD 158, and secure between commercial entity subsystem 400 and host device 100. It may be used in addition to or instead of access key 155b and / or access key 155a and / or ISD key 156k for validating transmission (eg, between commercial entity subsystem 400 and host device 100) For use as any suitable commercial entity key or shared secret).

  At step 604, process 600 may, in some embodiments, host credential data 654 on the secure element of host device 100 by financial institution subsystem 350 via commercial entity subsystem 400 (eg, credential data of FIG. 1B). 654) can be included. For example, such host credential data 654 may be at least partially provisioned to secure element 145 of host device 100 directly from financial institution subsystem 350 (eg, financial institution subsystem 350 and device 100). (FIG. 1B), which may be passed to the secure element 145 via the communication component 106). Additionally or alternatively, such host credential data 654 may be at least partially provisioned from the financial institution subsystem 350 to the secure element 145 of the host device 100 via the commercial entity subsystem 400 (eg, Via the communication path 55 of FIG. 1B between the financial institution subsystem 350 and the commercial entity subsystem 400, it communicates with the communication path 65 of FIG. 1B between the commercial entity subsystem 400 server 410 and the communication component 106 of the host device 100. May be passed to the host device 100 as host credential data 654 via the communication component 106, which may then be passed from the communication component 106 to the secure element 145 (eg, via the bus 118) . Host credential data 654 via path 75 and / or path 65 is provisioned on secure element 145 of host device 100 as at least part or all of credential SSD 154a, and credential information 161a and / or credential key 155a 'and / or It may include a credential applet 153a having a key 155ak. Step 604 may be performed at least in part when a user of host device 100 selects particular credentials to be provisioned on host device 100. In some embodiments, host credential data 654 may also include access key 155a and may be initially provided from commercial entity subsystem 400 to financial institution subsystem 350 and / or by commercial entity subsystem 400. It may be added. In some embodiments, such host credential data 654 includes credential information for provisioned payment credentials (eg, credential information 161a for applets 153a), AID (eg, for payment credential data provisioned on SSD 154a). The primary account number may be included as at least part of the AID 155aa) of the applet 153a, the SSD identifier, and / or the SSD counter.

  The credential data provisioned on the host device 100 may be, for example, a primary account number (“PAN”), a card security code (eg, a card authentication code (“CVV”)), a PAN expiration date, a name associated with the credential, Etc., and any other data with which the host device 100 can operate to generate appropriate cryptographic data (eg, any suitable shared secret, and any output whose functional output can be determined at least partially by the shared secret Of the appropriate cryptographic algorithm or cipher), etc., and all the data needed to make the payment. Provision “virtual” credentials or virtual PAN or device PAN (“D-PAN”) on the host device 100 instead of the user's “actual” credentials or actual PAN or funding PAN (“F-PAN”) be able to. For example, if it is determined that the credentials are provisioned on the host device 100, generating virtual credentials, linking to the actual credentials, and provisioning on the host device 100 instead of the actual credentials (eg, It may be required by the financial institution subsystem 350, by the commercial entity subsystem 400, and / or by the user of the host device 100). Such generation and linking of virtual credentials with actual credentials may be performed by any suitable component of the financial institution subsystem 350. For example, payment network subsystem 360 (eg, specific payment network subsystem 360 that may be associated with a brand of actual credentials) may define virtual link table 312, which may generate an association between the actual credentials and the virtual credentials. At any time, virtual credentials may be utilized by host device 100 for financial transactions with merchant subsystem 200 (eg, provisioned to host device 100) (eg, as shown in FIG. 1B). After the payment network subsystem 360 attempts to verify any received data indicating its virtual credentials (eg, in response to the received data 690 at step 640). In flop 642) can be received, it is possible to perform an analysis of the verification attempt request in light of the actual credential associated with the virtual credential determined by the table 312. Alternatively, such a table may be accessible and / or similarly utilized by the appropriate issuing bank subsystem 370 or other suitable subsystem accessible by the financial institution subsystem 350. By provisioning the virtual credentials on the host device 100 instead of the actual credentials, the financial institution subsystem 350 configures the payment network subsystem 360 only to utilize the table 312, and during the specific transaction the virtual credentials Can be linked to the actual credentials, so it can be configured to limit the fraud that can occur if the virtual credentials are intercepted by a fraudulent user.

  At step 606, the process 600 may include associating a merchant online resource, such as the merchant application 113 or a merchant website, with the merchant key 157. For example, the commercial entity subsystem 400 may associate the merchant key with the merchant's resources (e.g., the merchant key 157 with the resource 113 of the host device 100 and / or the merchant key 157 'with the client device 100'. Resource table 113 and the secure commerce credential data communication (eg, via the host device 100 and / or the client device 100 ') between the commercial entity subsystem 400 and the merchant subsystem 200) It can be activated using quotient resources. Both retailer subsystem 200 and commercial entity subsystem 400 may use such retailer key versions (eg, as shown in FIG. 1B, secure elements of retailer subsystem 200 and commercial entity subsystem 400, respectively). ) Can be stored. In some embodiments, to participate in the online resource payment program, the merchant registers as a member of the program executed by the commercial entity of the commercial entity subsystem 400 and / or obtains a merchant certificate. Can be required. Retailers may not be able to receive payment data without credentials. Each credential may include a unique commercial entity merchant identifier that can bind the merchant to the merchant's public key (e.g., public merchant key 157/157 '). The merchant can obtain multiple credentials, and thus can maintain multiple identities. Such a unique commercial entity merchant identifier may be provided by the merchant subsystem 200 to the client device 100 '(eg, as part of potential transaction data 660 at step 610, and / or the client As a unique element of a merchant online resource running on device 100 '(e.g., merchant application 113'), such a commercial entity merchant identifier may be transmitted from client device 100 'during the attempted transaction. The commercial entity subsystem 400 may be provided via the host device 100 (eg, via the payment request data 666 and / or the payment request data 674, host transaction data 6 in step 628). As at least part of the 8). In some embodiments, commercial entity subsystem 400 generates or otherwise generates a merchant key of a merchant online resource (eg, key 157 of application 113 and / or key 157 'of application 113'). The merchant subsystem 200 can be assigned to provide such a merchant key (e.g., via path 85). Alternatively, merchant subsystem 200 may generate or otherwise assign a merchant key for a merchant online resource to provide such merchant key to commercial entity subsystem 400 (eg, , Via the path 85). Either merchant subsystem 200 or commercial entity subsystem 400 may be responsible for managing any merchant key that may include such key generation, exchange, storage, use, and substitution. Regardless of how or where such merchant key is generated and / or managed, both merchant subsystem 200 and commercial entity subsystem 400 can store a version of the merchant key (E.g., within the secure element of each of the merchant subsystem 200 and the commercial entity subsystem 400). This enables the shared secret between the commercial entity subsystem 400 and the retailer subsystem 200 to securely communicate data between them. In some embodiments, host device 100 can be provided with such a merchant key to securely encrypt payment data with that key on host device 100.

  At step 608, process 600 may include the merchant's resource 658 (e.g., the merchant's third party resource 113 'of FIG. 1B) accessed by the client device 100'. As shown in FIG. 1B, the merchant resource application 113 ′ may be loaded from the commercial entity subsystem 400 (eg, from the application store 420) onto the client device 100 ′. For example, as shown in FIG. 3 with respect to the host device 100, the user of the client device 100 'may use the touch screen input component 110f of the I / O component 114a to select the "commerce application" icon on the particular screen 190 of the GUI 180. 183 may be selected, which may be recognized by the client device 100 'as an initiating event to provide the user with the ability to interact with the merchant's third party application 113'. Alternatively, or additionally, such retailer resources 658 may be accessed by the client device 100 'directly from the merchant subsystem 200. In response to the selection of such retailer application icon, the GUI allows the client device 100 'to interact with the application 113' to scrutinize items commercially available from the retailer for purchase. It is possible to provide an interactive screen to be activated. Alternatively, step 608 accesses the merchant's resource 658 as a merchant's web page from the merchant subsystem 200 (e.g., via the merchant server 210) using the internet application of the client device 100 '. The client device 100 'may be included, which is also selectable by the "Internet" icon (e.g., the icon 182 of the particular screen 190 of the GUI 180 of FIG. 3), to the user the third partial application of the merchant. But can provide the ability to interact with the retailer's web page. Alternatively, step 608 may include any suitable automatic access of resources 658 without active user input (eg, such as an autonomous consumer electronics client device 100 'detecting that a particular supply is missing). , Client device 100 'can operate to automatically interact with resource 658 in response to detection of any suitable event (e.g., washing machine client device 100 responsive to detection of a low supply of laundry detergent). ')).

  Next, at step 610, client device 100 'may receive potential transaction data 660 from the accessed merchant resource (eg, as described with respect to step 502 of process 500). For example, as shown in FIG. 1B, potential transaction data 660 may be generated by client device 100 'at retailer's resource 113' (eg, a retailer's third party application or website or any other suitable online resource (eg, For example, when interacting with the resource 658)), it may be provided from the merchant subsystem 200 (eg, from the merchant server 210) to the client device 100 '. Alternatively, or additionally, at least a portion of the potential transaction data 660 is local to the client device 100 'rather than data actively transmitted from the merchant server 210 to the client device 100' at step 610. It may be locally accessible by client device 100 'via application 113' (eg, when application 113 'is stored in a memory component or is being executed by processor 102' of client device 100 ') . For example, if the application 113 'is initially stored on the client device 100' (e.g., as retailer resource 658 at step 608), at least a portion of the potential transaction data 660 may be generated by the merchant subsystem 200. It may be generated by its initially stored application 113 ', where no additional information is provided to the client device 100'. Potential transaction data 660 may include any suitable data indicative of any suitable characteristics of a potential financial transaction performed between a user of client device 100 ′ and a merchant of merchant subsystem 200. it can. It may (i) be a unique merchant identifier (eg, an acquired banking merchant identifier and / or a commercial entity retailer identifier) and / or a particular merchant resource being used (eg, a particular merchant application 113 ') Specific merchant information, such as the identification of (ii) identification of the particular currency (eg, yen, pound, dollar, etc.) used to settle the transaction, and / or the particular currency to be settled for the transaction Specific transaction information, such as identification of quantities, and / or identification of specific goods or services to be purchased, rented or otherwise settled, and / or identification of default or initial shipping addresses used , (Iii) information indicating one or more types of payment methods acceptable to the merchant for the transaction (eg For example, a list of payment cards that may be used for purchase (eg, MasterCard but not Visa)), iv) a unique merchant-based transaction identifier (eg, a merchant for association with the transaction being performed). Including, but not limited to any suitable data element, such as a three or four character alphanumeric string, that may be randomly or uniquely generated by subsystem 200. Such potential transaction data 660 may be financial transactions, such as contact information fields (eg, phone number, email address, mailing address) of the customer making the purchase, with or without associated received data. May include any suitable number and type of data fields that may be required or at least used to complete the process, and some fields may be part of such potential transaction data 660 May be captured and included, and / or some fields may be opened during process 600 and wait for capture without being captured as part of such potential transaction data 660. . Such potential transaction data 660 of step 610 may be referred to herein as a PKPaymentRequest. Alternatively, as described above, at step 610, the user actively interacts with the client device 100 'to make potential transaction data 660 associated with the merchant subsystem 200 available to the client device 100'. You do not have to.

  The potential transaction data 660 may define a merchant resource requirement for the client device 100 ′ to generate a payment token for purchase of a product and / or service, eg, payment processing capabilities of the merchant, Any suitable information about the potential transaction can be encapsulated, including information about the payment amount and the currency code. The potential transaction data 660 may also include a list of one or more payment networks (eg, payment network 360) that may be supported by the merchant, and the client device 100 'may be a client of one or more payment networks. It may be configured to determine whether it has authorized payment credentials on the device 100 'or on any suitable host device available to the client device 100'. In some embodiments, for example, as shown in FIG. 3A, once such potential transaction data 660 can be accessed by client device 100 ′, the GUI of client device 100 ′ provides screen 190a. Here, the merchant's resource uses the transaction data 660 to indicate the name of the retailer (eg, “retailer A”) with information 307 a, the product (eg, “product B "), a price with information 307c (eg" price C "), and / or any initial transaction data associated with a potential transaction, such as initial shipping data with information 307d (eg" address D ") The appropriate information can be shown to the user of the client device 100 '. Potential transaction data 660, which may be provided by the merchant subsystem 200 to the client device 100 ', may indicate such information 307a, 307b, 307c and / or 307d. The user of client device 100 'needs to interact with device 100' and screen 190a to generate and share updated potential transaction data (eg, at step 622) by merchant subsystem 200 Specific portions of such information (eg, shipping address, etc.) may be adjusted. Screen 190a may also include a secure payment prompt 309, as shown in FIG. 3A and described in more detail below. At least a portion of the potential transaction data 660 may be provided from the merchant subsystem 200 to the client device 100 'via the communication path 15 of FIG. 1B and received by the communication component 106' of the client device 100 '. It may be done. The communication component 106 ′ may display this potential transaction data 660 on the processor 102 ′ (eg, on the screen 190a as part of a user interface on the client device 100 ′ (eg, for information 307a-d). ) And / or to the NFC component 120 '. For example, the NFC component 120 'can utilize such potential transaction data 660 to securely enable financial transactions between the client device 100' and the merchant subsystem 200. In some embodiments, potential transaction data 660 is referred to as merchant settlement request data and / or uniform resource locator ("URL") or any other suitable reference string and / or query string. obtain.

  Next, at step 612 of process 600, client device 100 'is any suitable for potentially funding financial transactions, such as the transactions associated with potential transaction data 660 of step 610. An attempt can be made to identify at least one non-native payment source, eg, of at least one host device, by sending host availability request data 662 (eg, discovery request) to any suitable remote source, Then, at step 614 of process 600, in response to any transmitted host availability request data 662, client device 100 ′ may describe any suitable source (eg, described with respect to step 504 of process 500). From Do) may receive any suitable host availability response data 664 (e.g., any suitable discovery response). Any suitable non-native payment source can be identified using any suitable technique. For example, a beacon signal may be sent by client device 100 'as host availability request data 662 that may request a response from any host device that may receive the beacon (eg, identification of that beacon or certain beacons) Any host device within a specific distance of the client device 100 'that can operate to communicate using the communication protocol of the present invention is presented by the client device 100' and read by the scanner of one or more host devices May be a quick response ("QR") code or any other suitable code). Alternatively or additionally, client device 100 'may transmit host availability request data 662 to one or more specific host devices using any suitable communication path and protocol (eg, device Identified in the contact application of 100 'and / or by the user of the device 100' (e.g. by telephone number or email address or any suitable unique device identifier (e.g. device identifier 119 of host device 100)) Manually identified one or more devices).

  Such host availability request data 662 may be used to fund information identifying client device 100 '(eg, device identifier 119' of client device 100 ') and / or potential financial transactions (eg, retail) Any suitable information, such as information identifying one or more specific payment types that may be acceptable (eg, by the quotient) (eg, payment types that may be identified by the potential transaction data 660 of step 610) Information may be included, and accordingly, any suitable information identifying the responding host device (eg, device identifier 119 of host device 100), and / or one or more that may be available to that host device Any appropriate information that identifies the payment type (eg, AID 155aa and / or AID 155ba) of the host device 100, can such payment type identification of host availability response data 664 include only each type that matches the type of discovery request of host availability request data 662? Or any suitable payment type identifying the location of the responding host device, which may include all payment types available to the responding host) and / or any suitable information identifying the status of the host device Any suitable host availability response data 664 may be requested, such as any suitable information that may identify information (eg, activity, sleep, disconnect, etc.). The host availability response data 664 shared by the host device may be the minimum minimum amount of data needed for host discovery, such as using a protocol buffer. The commercial entity subsystem 400 or any other entity may participate in the identification of the host device 100 by the client device 100 'at step 612 and / or step 614. For example, as described above, the commercial entity subsystem 400 may be any suitable service or device made available to the client device 100 'and / or the host device 100, such as iCloudTM and / or iMessageTM. Acting to manage any other identity service transport, making associations between different devices, and / or automatically determining the status and / or capabilities of various devices (E.g., a family can have an account with the commercial entity subsystem 400 that can be associated with a plurality of other devices, including client device 100 'and host device 100). As one example, client device 100 'may send host availability request data 662 to commercial entity subsystem 400 to request the status of all other devices associated with client device 100''s account; By obtaining one, several, or each one of such devices, and sharing each one of those states as host availability response data 664, with the client device 100 ', the entity subsystem 400 A response can be made, where the status can indicate the availability of the host device 100 and the identification of at least one payment type available to the host device 100. Each host device may have unique settings for such requests and potential responses (eg, a particular host device may only be configured with host availability request data 662 received from a particular client device (eg, Only devices associated with the same account of the commercial entity subsystem 400, only devices associated with contacts in the contact application of that particular host device, etc.) may be configured to respond)). Such a request and / or response to validate the identification of one or more available payment sources in steps 612 and 614 may be performed between client device 100 ′ and host device 100 (eg, any suitable communication Between the client device 100 'and the commercial entity subsystem 400 (e.g. via the communication path 95 using the protocol) (e.g. via the communication path 95 using any suitable communication protocol), Communication may be made between commercial entity subsystem 400 and host device 100 in any suitable manner, such as directly (eg, via communication path 65 using any suitable communication protocol). For example, as shown in FIG. 1B, host availability request data 662 may be transmitted from client device 100 ′ to host device 100 (eg, via communication path 99 or using a commercial entity subsystem using any suitable communication protocol) 400) (eg, via communication path 95 and communication path 65 using any suitable communication protocol)) or to commercial entity subsystem 400 (eg, using any suitable communication protocol) Host availability response data 664 may be sent to the client device 100 'from the host device 100 (eg, via communication path 99 using any suitable communication protocol). Through the commercial entity subsystem 400 (eg, any suitable Via the communication path 65 and communication path 95))) or from the commercial entity subsystem 400 (eg via the communication path 95 using any suitable communication protocol) May be

  Host availability request data 612 may be responsive to receipt of potential transaction data 660, or periodically independently of receipt of such transaction data 660, or the user of client device 100 'may view the screen of FIG. 3A. It may be automatically sent by client device 100 'in response to a request made by the user of client device 100' at any appropriate time, such as in response to interacting with the GUI of 190a. For example, depending on the user's selection of the secure payment prompt 309 on the screen 190a of the client device 100 'to make a purchase from a retailer with the details of the potential transaction data 660, the client device 100' may request host availability request data. 662 can be generated and sent. Also, as shown in FIG. 3B, the client device 100 'receives screen 190b in response to the receipt selection of secure payment prompt 309 in screen 190a of FIG. 3A, and in response to receipt of any appropriate host availability response data 664. May be configured to provide specific payment sources or credentials available to the client device 100 'for the user to interact with the client device 100' in one or more ways to make a purchase. Can prompt you to choose For example, as shown, screen 190b includes a payment source selection prompt 311 that may enable the user to select one of potentially multiple payment sources that may be available to client device 100 '. Can. The payment source selection prompt 311 may include only payment sources having credentials associated with a payment network supported by the merchant (eg, as determined by the potential transaction data 660 described above) or the client It can indicate all payment sources available to the device 100 '(eg, all sources associated with all AIDs received as host availability response data 664), and also be associated with an acceptable payment network Only can be made selectable by the user. The payment source selection prompt 311 may be any available payment that may be identified by any suitable payment credentials (not shown) native to the secure element of the client device 100 ', any received host availability response data 664 Source's any suitable non-native payment credentials (e.g. payment method X of host device 1 which may be indicated by payment option identifier 311a of prompt 311, payment method of host device 1 which may be indicated by payment option identifier 311b of prompt 311) , Etc.) and / or any other suitable payment source that may be identified by the client device 100 ′ (eg, any suitable remote host device for the user of the client device 100 ′ to request a payment Of the payment option identifier 311c of the prompt 311 (eg, the phone number or email of the host device that can be used by the client device 100 'to communicate with its remote host) to manually enter or select the It may be identified by entering any suitable unique host device identifier, such as an address, or in the contact application of the client device 100 ', or as the last selected host device or otherwise , By selecting the host device)), including but not limited to any suitable payment source. In some embodiments, the payment source selection prompt 311 indicates that the user of the client device 100 ′ is a particular payment type of a particular payment source (eg, payment method (PM) X of the host device 1 of the identifier 311a (eg, “ Enable selecting American Express Card with account number ending in 0096) or payment method (PM) Y of host device 1 with identifier 311b (for example, MasterCard Card with account number ending in 0035) And / or payment source selection prompt 311 may be a particular payment source (eg, host device 1 or host device) where the user of source client device 100 'is not that payment source of a particular payment type (Eg, depending on the specificity of the host availability response data 664 received by the client device 100 ', or may be available to the client device 100'). Other appropriate data): In some embodiments, host availability response data 664 may be a client device 100 'of a particular host device 100, which may be by a commercial entity subsystem 400 and / or a current date response. Based on the cached payment availability data known by (for example, it may be turned off and not responding to the discovery request of step 612 but may be known to contain appropriate payment credentials) Host device 100), where The identifier of rompt 311 (not shown) identifies (e.g., the host device and its known payment credentials and information that alerts the user of client device 100 'that such a host device is currently off. "HD2 must be turned on to enable HD2's PM Z".

  Next, at step 616 of process 600, client device 100 'may communicate payment request data 666 to at least one specific host device 100 (eg, as described with respect to step 506 of process 500). The target host device 100 of the payment request data 666 may be determined by the client device 100 'in any suitable manner, such as automatically with respect to the payment source selection prompt 311 of FIG. 3B or upon user selection. And / or such 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 use host availability response data 664 (eg, "HD 1's PM X" for identifier 311a and "PM Y for HD 1" for identifier 311b) for one or more payment sources. From the list of potential target host devices of FIG. 3B payment source selection prompt 311, which may be provided based on the identification, target host device 100 may be selected for payment request data 666 in step 616, or a client The device 100 'is manually identified by the host device in the contact application of the client device 100' and / or the user of the device 100 'in any suitable specific target host device (e.g. For example, telephone number or telephone By any suitable unique device identifier for the mail address or a host device (e.g., by using an optional identifier 311c in FIG. 3B)) the host device) can be identified. As just one specific example, as shown in FIG. 3C, the client device 100 ′ may display a screen in response to receiving the user selection of “HD1 ′s PM X” identifier 311a of payment source selection prompt 311 of FIG. 3B. 190c may be configured to be provided. The screen 190c of FIG. 3C prompts the user to interact with the client device 100 'in one or more ways, such as by user selection of the Request Host Device (HD) payment prompt 315 of FIG. 3C, etc. As indicated by payment method identifier 313, non-native host device payment may be requested for the selected payment source of payment source selection prompt 311 of FIG. 3B. Alternatively, target host device 100 of payment request data 666 of step 616 may be automatically selected by client device 100 'in response to any identification data obtained by client device 100' at step 614 (eg, , Client device 100 'may be a host device having a shortest distance from the group of available host devices (e.g., client device 100') based on any suitable characteristic, or Host devices having a priority of (eg, as may be determined by the application's default or customized settings of the client device 100 'in combination with host availability response data 664 or otherwise); The payment request data 666 of step 616 may thus be customized or otherwise configured to select the client device 100 'without any user interaction with the client device 100'. Based on (eg, transaction data 660 and / or any host availability response data 664 and / or any application parameters (eg, of any application operating on client device 100 ')). Such payment request data 666 of step 616 may be between the client device 100 ′ and the host device 100 (eg, using a communication path 99 using any suitable communication protocol, as shown in FIG. 1B). Through) or Between the entity device 100 'and the commercial entity subsystem 400 (eg, via communication path 95 using any suitable communication protocol), and then between the commercial entity subsystem 400 and the host device 100 (eg, May be communicated in any suitable manner in step 616, such as directly via communication path 65, using any suitable communication protocol, etc. Client device 100 'associates with client device 100' Can operate (eg, with memory local to the client device 100 ') to maintain local caches of different payment types available to different host devices (eg, by the commercial entity subsystem 400 periodically) Collected at any appropriate time No specific dedicated discovery request and response cycle is required when a settlement request is to be made) (based on data that may be shared with the client device 100 '). When one or more available payment types are determined by the client device 100 '(eg, on the client device 100') and / or non-native credentials (eg, on one or more host devices 100) Automatic selection of specific payment sources and / or prioritizations among various payment sources for selection by the user of the client device 100 'can be enabled. For example, the client device 100 'may be one of at least one available payment source targeted and identified in the payment request based on the distance between the client device 100' and the host device that may include the selected payment source. Can operate to automatically select or prioritize one (eg, a host device having an available payment source closest to the client device (eg, from distance data in a discovery response, or the like) The appropriate communication related data (such as can be determined via the detected communication signal strength BlueTooth®, etc.) is automatically selected for ease of use to the client device user. Can be easy). Alternatively or additionally, the client device 100 'automatically selects one of at least one available payment source that is targeted and identified in the payment request based on the payment source supported by the merchant. Or can operate to prioritize (eg, corporate branded payment credentials can be prioritized for use in a transaction with the company (eg, Disney brand Visa card, Disney It can be prioritized or selected for use in transactions with the retailer, such preferences can be expressed by the retailer and made available to the client device 100 ')) .

  Settlement request data 666 may include any suitable information that may be provided by the client device 100 ′ to the target host device 100 to identify one or more specific features of the potential transaction being funded. it can. For example, similar to the potential transaction data 660 of step 610, the settlement request data 666 of step 616 can include any suitable data associated with the potential financial transaction being funded. It may include (i) a unique retailer (i.e., "retailer A") retailer identifier and / or identification of the particular merchant resource being used (e.g., the particular merchant application 113 ') Specific merchant information, (ii) identification of a specific currency (eg, yen, pound, dollar, etc.) used to settle the transaction, and / or a specific amount of currency to be settled for the transaction (ie Identification of the price C ") and / or identification of the specific goods or services to be purchased, rented or otherwise settled (ie" Product B ") and / or default or initial used Specific transaction information, such as the identification of the shipping address (ie, “shipping D”), (iii) acceptable to the merchant for the transaction, or Information indicating one or more types of payment methods selected by the client device 100 ′ (ie, “HD1 ′s PM X”) (eg, a list of payment cards that may be used for purchase (eg, MasterCard but Visa) Not)), iv) a unique merchant-based transaction identifier (eg, three or four characters that may be randomly or uniquely generated by the merchant subsystem 200 for association with the transaction being performed) Any suitable data element, such as an alphanumeric string), (v) a unique client-based transaction identifier (eg, randomly or uniquely by the client device 100 'for association with the transaction being performed) 3 or 4 characters that can be generated A client for association with any suitable data element, such as an alphanumeric string) and / or (vi) a unique client-based payment request identifier (eg, payment request being made by payment request data 666) Including, but not limited to) any suitable data element, such as a three or four character alphanumeric string, that may be randomly or uniquely generated by the device 100 '. In some embodiments, the payment request data 666 may be encrypted or otherwise formatted or otherwise processed by the commercial entity subsystem 400 prior to communicating with the target host device 100. . Such payment request data 666 may be referred to herein as PKRemotePaymentRequest, and may include any suitable data. It identifies a selected target host device that may be (1) PKPaymentRequest of the potential transaction data 660 of step 610 (eg, may be wrapped in PKRemotePaymentRequest), (2) herein referred to as PKRemoteDevice Any suitable data (eg, host device identifier 119 of host device 100, which may be included in host availability response data 664 of step 614), (3) target host device, which may be referred to herein as SelectedApplicationIdentifier (E.g., the host availability response data 664 of step 614 may be included in any suitable data identifying the selected or default specific settlement of the And / or may be selected automatically or by the user at the client device 100 ', such as the AID 155aa of the secure element 145 of the target host device 100) and / or (4) a payment, which may be referred to herein as a RemotePaymentIdentifier Any suitable data identifying a unique identifier associated with the request (eg, may be used to identify a settlement request via a client of the system and a host device, and may be generated by the client device 100 or otherwise) , Unique values), but not limited to.

In response to receiving payment request data 666 from the client device 100 'at step 616, the target host device 100 is operative to provide the user of the host device 100 with any suitable information to affect the payment request. It can be possible. For example, as shown in FIG. 3D, a push notification screen 190d may be provided by the GUI of host device 100, which may operate to indicate to the user of host device 100 that a client payment request has been received with identifier 317. And may include options 321 that may be selectable to hide the notification and / or options 319 that may be selectable to display further details regarding the notification. For example, in response to the user's selection of the more detailed view option 319, or instead of screen 190d, the GUI of host device 100 causes the user of host device 100 to respond to the client payment request in one or more appropriate manners You can go to screen 190 e of FIG. The screen 190 e of FIG. 3E instructs the user of the host device 100 to interact with the host device 100 in one or more ways to make a purchase, either native to the host device 100 or the device 100. Specific credentials can be selected that are non-native but accessible to the device 100 through a process similar to the process 600. As shown in FIG. 3E, the retailer, product, price, and shipping information for the same potential transaction as identified on the screen 190c of FIG. 3C to the user of the client device 100 ', prior to step 616 and And / or in addition to the identifiers 307a-307d that may cause the user of the host device 100 to identify, at step 616, the screen 190e on the host device 100 for use by the user to fund potential transactions. A credential selection prompt 323 may be included that may enable the selection of one of the potentially multiple credentials that may be provisioned to (eg, credentials of credential SSD 154a). The prompt 323 may include only credentials native to the host device 100 associated with the payment network supported by the merchant (eg, as determined by payment request data 666 as described above). As shown, prompt 323 indicates a first native payment credential option 325 associated with host device 100's "Credentials X" and a second native payment credential option 327 associated with host device 100's "Credentials Y". May be acceptable (eg, based on any suitable portion of payment request data 666), each of which may be acceptable for use by the merchant subsystem 200 of the potential transaction, and And / or, where applicable, any suitable technique may be used to identify the credentials selected by client device 100 '(e.g., "PM X" by client device 100' Selected (for example, Screen 190b of B), in the case where the obtained are specifically identified in the settlement request data 666 may be provided with a ^"*" next to the first native settlement credential options 325 associated with the "Credential X"). As shown in FIG. 3F, the GUI of host device 100 displays a screen in response to receiving a host device user selection of a particular credential (eg, “Credentials X”) from credential selection prompt 323 of screen 190e of FIG. 3E. 190f may be configured to be provided. Screen 190f of FIG. 3F may use credential identification information 329 to identify the selected or automatically identified default credentials, and the host device 100 to the user of host device 100 in one or more ways. The user can be instructed to interact with to authenticate the user and his intent to use the selected credentials. This is via a personal identification number ("PIN") entry to the user (e.g. using authentication prompt 331) to access the secure element of the host device 100 and thus the credentials used for the purchase, or Directing user authentication to be entered may be included through user interaction with the biometric sensor.

  Different instances of payment request data 666 may be sent to different target host devices at step 616 (eg, to a group of available host devices (eg, children's client devices to increase the opportunity for rapid response) From) to their father's host device and to their mother's host device)). If the dormant host device is the target host device, then the payment request data 666 for that host device may be queued to share with the target host device when it comes online (eg, , Such as by the commercial entity subsystem 400, or by the client device 100 'itself, may have been enabled for a particular time period (eg, such payment request data 666). Two hours after generation, such settlement request data can not be considered as expired and can not be provided to the target host device). As mentioned above, the prompt 311 includes a notification to the client device 100 'that a notification may be provided indicating that the particular host device is not online or that the particular host device is not responding to the payment request data. A request can be generated to perform the steps for enabling the host device for the user of the client device. The commercial entity subsystem 400 operates to manage settings that can operate to block particular discovery requests and / or particular settlement requests from particular client devices from going to particular host devices. Or the particular host device may operate to set such appropriate options to block such requests from particular client devices.

  The user of host device 100 is prepared to select or confirm a particular payment credential to use in funding a potential transaction in response to payment request data 666 received in step 616. If so, process 600 proceeds to step 625, which includes receiving the intent and authentication by the user of host device 100, based on potential transaction data 666 (eg, authentication of FIG. 3F). Specific credentials for performing potential transactions for a particular retailer, product, price, and shipping destination can be utilized via the user's selection of prompt 331. Access SSD 154 b utilizes applet 153 b of host device 100 to allow other SSDs 154 (eg, credential SSD 154 a) to be used to validate its credential information in commerce credential data communication, It can be determined whether such authentication has been done. As just one example of step 625, applet 153b of access SSD 154b may be configured to determine the user's intent and local authentication of host device 100 (eg, device 100, such as biometric input component 110i of FIG. 3). (Eg, via the credential SSD 154a) to perform payment transactions (eg, via one or more input components 110, which may be used by a user interacting with any application (eg, card management application 113b of the host device 100)) of It may be configured to enable another specific SSD (using credentials). In some embodiments, after such determination, but before such activation, the GUI of host device 100 prompts the user of host device 100 (eg, prompt similar to prompt 333 of FIG. 3G Another screen (eg, a diagram that can eventually initiate payment using selected and authenticated credentials), instructing them to interact with host device 100 in one or more ways Can be configured to provide a 3G screen 190g).

  The user of the host device 100 is identified in step 625 by the payment request data 666 (eg, "retailer A" and "product B" and "price C" and "shipment D" of screens 190c and 190e) of step 616. Can provide the host device 100 with the intent and authentication to use native specific payment credentials to fund potential transactions, and step 625 may be performed immediately after step 616. . However, alternatively, the process 600 may enable the user of the host device 100 to adjust one or more characteristics of the potential transaction before any intent and authentication is provided at step 625. it can. For example, after receiving settlement request data 666 in step 616, host device 100 may determine any suitable characteristics of the potential transaction, such as the transaction's shipping address, the transaction's shipping method, and / or the transaction's settlement method, etc. It may be operative to make adjustments either automatically or in response to any suitable user interaction with host device 100 (e.g., with screen 190e). Rather than proceeding from step 616 to step 625, process 600 may include step 618 whereby host device 100 returns host response data 668 to client device 100 'in response to payment request data 666. Can. Such host response data 668 may include any suitable data indicative of any suitable potential transaction data that may be at least partially defined by host device 100. For example, through interaction with screen 190e of FIG. 3E, the user of host device 100 may receive the first native payment credentials option 325 "Credentials X" (eg, the same or a different payment method identified by payment request data 666). Not only can you select the), but also for potential transactions, a new "shipment address" instead of the first "shipment address D" that can be identified by the screen 190c of the client device 100 'and the payment request data 666 You can choose to have it shipped E. Thus, shipping address information or other suitable portion of payment request data may need to be processed by client device 100 'and / or merchant subsystem 200 before process 600 may validate transaction funding. In response to the host device update, the host device 100 generates host response data 668 indicative of the updated shipping information at step 618 and sends it to the client device 100 '(eg, the commercial entity subsystem 400 (As well as any other information communicated between the host device 100 and the client device 100 ') during the process 600) or otherwise. Such host response data 668 is substantially similar to payment request data 666, but any changes identified by host device 100 (e.g., from "shipment address D" to "shipment address E" ) May be shown. Next, the client device 100 'receives such host response data 668 at step 618, and at least a portion of such host response data 668 to the merchant subsystem 200, the updated transaction at step 620. The updated transaction request data 670 may be communicated as request data 670, which may be identified to the merchant subsystem 200 by any one or more desired updates (e.g., by the host device 100) to the potential transaction data 660. Changed from “shipped address D” to “shipped address E” or any change made locally by the client device 100 ′ after step 610 and / or after step 618 but before step 620 ( For example, client device User selection of a particular payment 311a on the screen 190b by the scan 100 'may generate an updated transaction request data 670) can be identified.

In response to receipt and processing of such updated transaction request data 670, merchant subsystem 200 generates any appropriate updated potential transaction data 672 to client device 100 'at step 622. It can operate to transmit, which is substantially similar to the potential transaction data 660, but any updates made by the client device 100 'and / or the host device 100 (eg, "shipment" The change from address D "to" shipping address E ") and additional potential transaction information that may be changed by the retailer subsystem 200 as a result may be indicated (e.g., the price may be less than" potential transaction data 660 "). It is changed from price C "to" price C ^* " Ku, it may be due to different shipping costs associated with the change from the "shipping address D" to "shipping address E"). As another example, after client device 100 'selects payment method option 311a (eg, on screen 190c before selecting request payment prompt 315), it selects payment method option 311b and selects the appropriate updated transaction request Responsive to sending data 670, merchant subsystem 200 may operate to generate any suitable updated potential transaction data 672 at step 622 to send to client device 100 '. But it is substantially similar to the potential transaction data 660, but its update performed by the client device 100 '(eg, option 311a, "method X" to option 311b, "method Y" ) And as a result retailer sub May indicate additional potential transaction information that may be changed by the stem 200 (e.g., the price may be changed from "price C" potential transaction data 660 to the "price C ^*", it is selected The different payment methods being performed (e.g., the selection of a retailer's branded payment method may result in a price savings over the selection of a non-branded payment method by the retailer). Such updated potential transaction data 672 may be received and processed by the client device 100 '(eg, by providing the updated screen 190c) and / or the client device 100' may The updated payment request data 674 may be generated at 624 and sent to the host device 100. Each one of payment request data 666, host response data 668, and updated payment request data 674 are specific other information that changes among such data (eg, shipping address information and / or payment method information and And / or associated with the same unique merchant-based transaction identifier and / or the same unique client-based transaction identifier and / or the same unique client-based payment request identifier (eg, RemotePaymentIdentifier) regardless of Or they may be included. Thus, a change in payment method (e.g., from the first payment credential to a second payment credential), and / or a change in the shipping method (e.g., from the ground delivery method to the two day air delivery method), and / or Any suitable of the potential transaction data 660 by the client device 100 ', such as a change of shipping address (from the first shipping address to the second shipping address), and / or any other suitable data type change. The updated transaction request maintains a consistent transaction identifier, in response to any change in the portion, and / or in response to any change to any appropriate portion of the payment request data 666 by the streaming device 100. , Updated payment request data 674 that may be sent to the host device 100 at step 624. It can result in updated potential transaction data 672 that can result. Both the client device 100 'and the host device 100 operate to change at least a portion of the transaction information (eg, shipping method, shipping address, payment method, etc.) depending on the capabilities of the user interface of each device. It can not work, either or both can work. Any suitable request / response model can be used to enable the appropriate generation of update requests and responses based on any suitable change by any device. For example, updated potential transaction data 672 and / or updated settlement request data 674 may confirm the update, providing updated information including settlement summary items, shipping methods, settlement status, etc. Can. For example, in response to the update transaction request data 670, updated potential transaction data 672 can be obtained, including updated global and shipping methods, or payment status for an "invalid shipping address." Any suitable basic communication protocol between devices (e.g., the identification service transport layer between client device 100 'and host device 100) has each device received and processed by other devices (e.g. It can be operative to provide a completion handler that can operate to ensure that it knows when) (as well as a "read receipt" of iMessage (TM) or other suitable media messaging protocol). For example, a payment continuation service may be provided (eg, by the IDMS component 470 of the commercial entity subsystem 400, etc.) to enable secure communication of payment requests and payment responses between the client device and the host device, the client Each of the device and the host device can use the messaging transport of the service (e.g., an IDS transport such as with the IDS application 113d of the host device 100). Apple Inc. (Eg, seamless sharing of application data between devices) or Apple Inc. By AirDropTM (eg, Secure Ad Hoc Transfer Protocol), or Apple Inc. Any suitable mechanism for communicating such data may be used, such as Continuity (TM) SMS / MMS, etc. Further, any device can operate to cancel the request (eg, client device 100 ′ can cancel the request sent after step 612 and / or after step 624, And / or the host device 100 can cancel the request received after step 612 and / or after step 624), update the presentation of data on each device (eg, update screens 190c and 190e) It can work as well. The common RemotePaymentIdentifier of all requests / responses for a particular transaction can be used by each device to verify that each device is communicating for the same particular transaction. For example, the most recently received payment request using a particular RemotePaymentIdentifier may be used by the host device via any previously received payment request using that same particular RemotePaymentIdentifier.

  Then, upon receipt of the particular payment request data (eg, payment request data 666 in step 616 or updated payment request data 674 in step 624), the intent and Once the authentication is received, steps 626-628 of process 600 may include host device 100 generating, encrypting and transmitting host transaction data 678 for use by commercial entity subsystem 400 (eg, As described for steps 508 and 510 of process 500). The credentials of the credentials SSD 154a on the secure element 145 of the host device 100 are selected, authenticated and / or enabled for use in a financial transaction (eg, step 625), the secure element of the host device 100 145 (eg, processor module 142 of NFC component 120) may generate and encrypt particular credential data of the selected credential for use by the commercial entity subsystem 400. For example, payment card data of SSD 154a (eg, selected “Credentials X”, such as host payment credential data 675 of credential SSD 154a (eg, token data and cryptographic data (eg, as described above for step 508 of process 500)). ) May be generated and / or at least partially encrypted with credential key 155a ′ at step 626 as host payment credential data 676, which may include at least token data and encryption data, such The encrypted host payment credential data 676 is sent to its credential key 155a '(eg, financial institution subsystem 350) to access the host payment credential data 675. Only it is decrypted by an entity having access. The host payment credential data 675 may be, for example, all the data needed to make a payment using a credential, such as a credit card number, for example the primary account number (for example the actual F-PAN or virtual D-PAN) , Card security code (eg, card verification code (“CVV”) ”, expiration date, name associated with credential key, associated cryptographic data (eg, shared secret between secure element 145 and financial institution subsystem 350) And any other suitable information), etc. may be included. In some embodiments, in step 626, some or all of the host payment credential data 675 of the credential SSD 154a is encrypted with the credential key 155a ′ as encrypted host payment credential data 676 Host payment credential data 676 may be alone or applicable payment request data 666/674 (eg, identification of a merchant, identification of a price amount, currency and / or shipment and / or product identification, and / or unique Not all of the potential transaction data 660/672) that may include such as a merchant-based transaction identifier and / or a unique client-based transaction identifier and / or a unique client-based payment request, etc. Even with at least the first part, and / or any other suitable information (eg, any information identifying the host device 100 itself (eg, host device identifier 119), any particular host The device-based transaction identifier, etc., is encrypted as the host payment data 677 in step 627, eg, access information (eg, access key 155a of SSD 154a, access key 155b of access SSD 154b, ISD key 156k, and / or CRS 151k And / or signed by CASD 158k). For example, secure element 145 of host device 100 (eg, processor module 142 of NFC component 120) uses the access information to identify the merchant from data 660/666/672/674 (eg, application 113 ', etc.) Not only the identification of the retailer used for the purchase or its resources), but also the purchase and / or currency code identification from the data 660/666/672/674, and the encrypted host payment data 677 to the SSD 154a The encrypted host payment credential data 675 (eg, encrypted host payment credential data 676) may be encrypted. In some embodiments, host payment credential data 675 of credential SSD 154a (eg, payment card data of SSD 154a, such as token data and cryptographic data (eg, as described above with respect to step 508 of process 500)) is generated It can not be encrypted (e.g., as data 676 in step 626) with a credential key before it is encrypted (e.g., as data 677 in step 627) with a commercial entity key or access key, instead Host payment credential data 675 may be encrypted with a commercial entity key or access key (e.g., as data 677 in step 627), whereby any future reference to data 676 in such an embodiment Is optional In credentials key may be a reference to the data 675 that has not been encrypted. In some embodiments, such commercial entity key or access key is a commercial entity public key associated with the scheme of the commercial entity subsystem 400, and the commercial entity subsystem 400 is associated with the commercial entity private key associated with it. You can access to The commercial entity subsystem 400 can provide such a commercial entity public key to the financial institution subsystem 350, and the financial institution subsystem 350 can share the commercial entity public key with the host device 100 (see FIG. For example, when provisioning credential data on host device 100 (eg, at step 654 of process 600)).

  Second, any of at least some of the payment request data 666/674 (eg, identifying a retailer, identifying a price amount, identifying a currency, identifying a unique merchant-based transaction identifier, identifying a product / service, etc.) The encrypted host payment data 677, and / or any other suitable information (eg, any information identifying the host device 100 itself, a unique host device based transaction identifier, etc.) , As host transaction data 678, may be sent together from the host device 100 to the commercial entity subsystem 400 at step 628 (eg, as described with respect to step 510 of process 500). Thus, at least a portion of host transaction data 678 (eg, encrypted host payment data 677) is encrypted (eg, access key 155a, access) that generated encrypted host payment data 677 of host transaction data 678. The key 155b, ISD key 156k, CRS 151k, and / or CASD 158k) can only be decrypted by an entity (e.g., commercial entity subsystem 400) that has access to its access information. Such host transaction data 678 is generated at steps 626-628 and then at step 628 (eg, from the secure element 145 of the NFC component 120, via the communication component 106 and the communication path 65) the commercial entity subsystem 400 Can be sent to Steps 626, 627 and 628 are generated from secure element 145 of host device 100 as part of host transaction data 678, and the transmitted credential data may be first transmitted in a manner that can not be decrypted by another part of host device 100. It can be ensured that it is encrypted (e.g. by the processor 102). That is, host payment credential data 675 of host transaction data 678 is encrypted using credential key 155 a ′ that can not be exposed to or accessible by any portion of host device 100 outside of the secure element. It may be encrypted as host payment credential data 676. Further, such encrypted host payment credential data 676 of host transaction data 678 may not be exposed to or accessible by any portion of host device 100 external to that secure element. (Eg, access keys 155a, 155b, 156k, 151k, and / or 158k (eg, referred to herein as “access information”)) may be encrypted as encrypted host payment credential data 677 .

  Next, at step 630, process 600 may include a commercial entity subsystem 400 that receives and decodes at least a portion of host transaction data 678. For example, commercial entity subsystem 400 may receive host transaction data 678 and then use the access information (eg, 155a, 155b, 156k, 151k, and / or 158k) available at entity subsystem 400. The encrypted host payment data 677 of the host transaction data 678 can then be decrypted. The commercial entity subsystem 400 may not have access to the credential key 155 a ′ at which the host payment credential data 675 may be encrypted as the encrypted host payment credential data 676 by the secure element 145 of the host device 100 at step 626 Because of the nature, this may enable the commercial entity subsystem 400 to determine the merchant's unencrypted identification (eg, from the decrypted host payment data 677) while encrypting. The host payment credential data 675 is also maintained (eg, as encrypted host payment credential data 676). Additionally or alternatively, the merchant may be identified by potential additional data that may be included in host transaction data 678 along with encrypted host payment data 677. Host transaction data 678 may include information identifying host device 100 or at least its secure element, and when host transaction data 678 is received by commerce entity subsystem 400, commerce subsystem 400 determines which access information ( For example, it may know whether to use the access information 155a, 155b, 156k, 151k and / or 158k) at step 630. For example, commercial entity subsystem 400 can access multiple access keys 155a / 155b and / or multiple ISD keys 156k, each one of which is specific to a particular host device 100 or a particular secure element. It can be

  Next, at step 631, process 600 identifies the merchant key (eg, merchant key 157 ') associated with the merchant by payment request data 666/674 and thus may be identified by host transaction data 678. Commercial entity subsystem 400 may then be included, which then re-encrypts at least a portion of host transaction data 678 using the merchant key. That is, after decrypting at least a portion of host transaction data 678 using appropriate access information in step 630 (eg, encrypted host payment credential data 676 and any that may be encrypted with encrypted host payment data 677) After decrypting the encrypted host payment data 677 to implement other information), the commercial entity subsystem 400 may then, at step 631, be appropriately associated with the merchant information identified in the host transaction data 678. The merchant key may be used to re-encrypt at least a portion of host transaction data 678 (eg, token data and / or encrypted data of encrypted host payment credential data 676). For example, such a merchant key (eg, merchant key 157 ') may be determined by comparing the merchant information of the commercial entity identified in host transaction data 678 with the data in table 430 of FIG. 1B. It is also good. For this determined appropriate merchant key, the commercial entity subsystem 400 uses the merchant key (e.g., merchant key 157 ') to determine at least a portion of the host transaction data 678 (e.g., token data and And / or encrypted data of encrypted host payment credential data 676) may be re-encrypted as encrypted merchant credential data 681. For example, encrypted merchant credential data 681 includes at least encrypted host payment credential data 676 from host transaction data 678, as well as host transaction data 678 and / or payment request data 666/674 (eg, potential It may include any suitable transaction data, such as purchase price data from or based on that which was initially identified by the transaction data 660/672, or other suitable transaction data. The merchant identification information from the host transaction data 678 may already be used to determine the merchant key that may encrypt the encrypted merchant credential data 681 in step 631. , And need not be included in the encrypted retailer credential data 681. The encrypted merchant credential data 681 may be established by the merchant entity subsystem 400 as the creator of such encrypted merchant credential data 681 when received by the merchant subsystem 200. And / or by way of the commercial subsystem 400 in such a way that it may validate that the merchant subsystem 200 has not been altered after such encrypted merchant credential data 681 has been signed. It may be signed. Such encrypted merchant credential data 681 may be generated at step 631 and then sent to host device 100 along with any other suitable data as secure host transaction data 682 at step 632 (Eg, via the path 65 of FIG. 1B from the server 410 of the commercial entity subsystem 400 to the communication component 106 of the host device 100).

  Steps 631 and 632 are the credential data sent from the commercial entity subsystem 400 as part of the secure host transaction data 682 (token data and / or encrypted data of the encrypted merchant credential data 681 of FIG. 1B). , May be operated to ensure that it can be encrypted in such a way that it can not be decrypted by parts of the host device 100 other than the secure element 145. That is, the credential data of secure host transaction data 682 (eg, token data and / or encrypted data of encrypted merchant credential data 681) may, in some embodiments, include secure element 145. May be encrypted with a merchant key (eg, merchant key 157 ') that can not be published to or otherwise accessible by any part of the. Further, credential data of secure host transaction data 682 (eg, token data and / or encrypted data of encrypted merchant credential data 681) may be exposed to any portion of host device 100 external to secure element 145. It may be encrypted with a credential key 155a 'that is not or otherwise accessible by it.

Secure host transaction data 682 is then, in step 634, as secure host transaction data 684 (eg, via communication path 99 and / or via commercial entity subsystem 400 using any suitable protocol) It may be forwarded to client device 100 '(eg, as described with respect to step 516 of process 500). The client device 100 ′ then, at step 636, at least the encrypted merchant credential data of the secure host transaction data 684 as client transaction data 686 (via the communication path 15 or as the contactless proximity based communication 5). 681 may be operative to transfer to merchant subsystem 200 (eg, as described with respect to step 518 of process 500). In some embodiments, between step 634 and step 636, the GUI of client device 100 'may be configured to provide another screen 190g of FIG. 3G, which may be from host device 100. , Using selected and authenticated credentials (eg, as encrypted host payment credential data 676 encrypted in the encrypted merchant credential data 681 of secure host transaction data 682/684) , Prompts the user of the client device 100 'to use the prompt 333 to interact with the client device 100' in one or more ways to examine and reject the payment, and / or eventually initiate be able to. Alternatively, step 636 may be performed transparently to the user of client device 100 '. Alternatively, merchant credential data 681 may be communicated from merchant entity subsystem 400 to merchant subsystem 200 without being communicated via host device 100 and / or via client device 100 '. One, some or all portions of potential transaction data 660/672 may be generated from payment request data 666/674 via client device 100 'and / or host device 100 and / or commercial entity subsystem 400. Carried to host transaction data 678 and / or secure host transaction data 682 and / or secure host transaction data 684 and / or client transaction data 686, the specific identifier of the potential transaction is by each entity during process 600 It can be identified. It may include (i) a unique retailer (i.e., "retailer A") retailer identifier and / or identification of the particular merchant resource being used (e.g., the particular merchant application 113 ') Specific merchant information, (ii) identification of a specific currency (eg, yen, pound, dollar, etc.) used to settle the transaction, and / or a specific amount of currency to be settled for the transaction (ie, “ Identification of the price C "and / or" price C ^* ") and / or identification of the specific goods or services to be purchased, rented or otherwise settled (ie" Product B "), and / or Or specific transaction information, such as the identification of the default or initial shipping address used (ie, “shipment D” and / or “shipment E”), (iii) transaction Information (eg, may be used for purchasing) indicating one or more types of payment methods that are acceptable to the merchant for the transaction or selected by the client device 100 '(ie, "HD 1's PM X") A list of payment cards (eg, MasterCard but not Visa), iv) a unique merchant-based transaction identifier (eg, randomly by merchant subsystem 200 for association with the transaction being performed or Any suitable data element that can be uniquely generated, such as a three or four character alphanumeric string), (v) a unique client-based transaction identifier (eg, for association with a transaction being performed) At random by the client device 100 ' (Vi) a unique client-based payment request identifier (eg, payment request data 666/674), which may be uniquely generated, such as a three or four character alphanumeric string, And / or (vii) any suitable data element, such as a three- or four-character alphanumeric string, which may be generated randomly or uniquely by the client device 100 'for association with an active payment request. ) A unique host-based payment request identifier (e.g., randomly or uniquely by host device 100 for association with a payment request funded by host device 100, such as an alphanumeric string of 3 or 4 characters) Any suitable data element) that may be generated, including but not limited to. Such carried data may include at least a portion of PKRemotePaymentRequest herein, and may include any suitable data. It may optionally (1) identify a selected target host device, which may be referred to herein as PKRemoteDevice, which may be wrapped in PKPaymentRequest of step 610 and / or step 622 (eg, may be wrapped in PKRemotePaymentRequest). (E.g., host device identifier 119 of host device 100, which may be included in the discovery response of step 614), (3) a selected target host device, which may be referred to herein as SelectedApplicationIdentifier Or any suitable data identifying a default specific payment (eg, it may be included in the discovery response of step 614, and may be The AID 155aa of the secure element 145 of the target host device 100, which may be selected dynamically or by the user, and / or (4) a unique identifier associated with the payment request, which may be referred to herein as a RemotePaymentIdentifier Including any suitable data that identifies (eg, unique values that may be used to identify payment requests via clients of the system and the host device, and may be generated by client device 100 or otherwise) However, it is not limited to these. In other embodiments, host device 100 may communicate secure host transaction data 684 directly to merchant subsystem 200 at step 634 rather than via client device 100 '. In yet another embodiment, the commercial entity subsystem 400 may communicate secure host transaction data 682 directly to the client device 100 ′ at step 632 rather than via the host device 100. In yet another embodiment, the commercial entity subsystem 400 directly connects the secure host transaction data 632 to the merchant subsystem 200 in step 621 rather than via the host device 100 and / or the client device 100 '. Can communicate with.

  When merchant credential data 681 including secure host payment credential data 675/676 is received by merchant subsystem 200 (eg, as client transaction data 686 in step 636), process 600 causes merchant subsystem 200 to Step 638 may also be configured to generate payment 688 and send it to the acquisition bank subsystem 300 (eg, via the communication path 25 between the merchant subsystem 200 and the acquisition bank subsystem 300 in FIG. 1B). The data 688 may include secure host payment credential data of the host device 100 and payment information and authorization request that may indicate the retailer's purchase price of the product or service (eg, client data). As may be included in transaction data 686 or otherwise associated with it, or otherwise by merchant subsystem 200 (eg, by potential transaction data 660/672 (eg, unique transaction identifier )) To be associated with known transactions). For example, at step 638, merchant subsystem 200 may at least partially decrypt merchant credential data 681 of client transaction data 686 using its known merchant key 157 ′, payment data 688 The secure host payment credential data (eg, encrypted payment credential data 676) of credential SSD 154a encrypted using that credential key 155a 'rather than with a key that is not available to financial institution subsystem 350 (eg, encrypted payment credential data Can be included.

  If payment data 688 is sent to the acquisition bank subsystem 300 at step 638, then the acquisition bank subsystem 300 sends authorization request information from the payment data 688 to the financial institution subsystem 350 to the authorization request data 690 at step 640. (E.g., via communication path 35 between acquisition bank subsystem 300 and financial institution subsystem 350 in FIG. 1B). Next, at step 642, when the issuing bank subsystem 370 of the financial institution subsystem 350 receives the authorization request (eg, as data 690 at step 640 directly or indirectly from the acquiring bank subsystem 300 as data 405) Payment information (eg, via the secure element 145 of the host device 100), each of which may be included in the authorization request data 690 and in the data 684, 686 and / or 688 (indirectly via the payment network subsystem 360) The host payment credential data 675 (eg, encrypted host payment credential data 676) of the host device 100 encrypted by the key 155a ′) and the purchase price are decrypted (eg, financial institution subsystem 35) In using the credentials key 155a ') are analyzed, it is possible to determine whether it has enough credits to accounts that are associated with the commerce credentials to cover the purchase price. If sufficient funding is not present, the issuing bank subsystem 370 can reject the requested transaction by sending a negative authorization response to the acquiring bank subsystem 300. However, if sufficient funding is present, the issuing bank subsystem 370 can approve the requested transaction by sending a positive authorization response to the obtaining bank subsystem 300, and the financial transaction is completed. obtain. Any type of authorization response may be provided by the user finance subsystem 350 to the acquisition bank subsystem 300 as authorization response transaction state data 692 at step 642 of the process 600 (eg, acquired from the issuing bank subsystem 370) The payment network based on authorization response data 415 which may be provided to the payment subsystem subsystem 360 directly from the issuing bank subsystem 370 via the communication path 35 to the bank subsystem 300 or via the communication path 45 of FIG. 1B. From subsystem 360 to acquisition bank subsystem 300). Next, in response to receiving authorization response transaction state data 692 in step 642, process 600 causes acquisition bank subsystem 300, or any other suitable subsystem, to perform such authorization response transactions in step 644. Sharing state data as authorization response transaction state data 694 with the merchant subsystem 200 can also be included, which is then described as transaction state data 696 identified in step 646 (e.g., described with respect to step 522 of process 500) As transaction status data 698 identified as at client device 100 '(eg, with a merchant resource or otherwise) and / or as And As) the host device 100 has been described with respect to step 524 of 0, may be shared. Such confirmed transaction state 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 state data is a transaction (eg, a transaction identified by the unique RemotePaymentIdentifier of the payment request data) at client device 100 'at step 646 and / or at host device 100 at step 648. Can be operated to close). Additionally or alternatively, if the transaction is not successful, the verified transaction state data may or may not operate to close the transaction (eg, no valid funding is available, Or close the transaction if the host device is identified as fraudulent, but leave it open to allow updates if an invalid shipping address is determined). Any non-transaction termination transaction status data may allow the payment process to continue until the process is canceled by the application, the process is canceled by the user, or the process is complete.

  Thus, merchant subsystem 200 may be configured to process client transaction data 686 or any other carrier of merchant credential data 681 in any suitable manner. For example, to obtain host payment credential data from merchant sub credential data 681, the merchant subsystem 200 validates the signature characteristics of the received merchant credential data 681 and the commercial entity subsystem 400 signs the signature. Can verify that they are Retailer subsystem 200 is used to construct merchant credential data 681 by merchant entity subsystem 400 which retailer key (eg, merchant public key 157 ') using any suitable technology. Can be determined. Retailer subsystem 200 then obtains the corresponding credential private key (eg, retailer private key 157 'of retailer subsystem 200) and encrypts the merchant using the obtained key. Credential data 681 can be decapsulated and / or decrypted to recover encrypted host payment credential data 676. Such data 676 may then be provided to the appropriate payment network 360, which utilizes the appropriate credential key 155 a ′ of the financial institution subsystem 350 to encrypt the encrypted host payment credential data 676. Decapsulation and / or decryption may recover host payment credential data 675 (to recover token data and / or encrypted data of host payment credential data 675 to validate host payment credential data 675 (E.g., independently generate cryptographic data based on token data of the received host payment credential data 675, compare the generated encrypted data with the encrypted data of the received host payment credential data 675, and compare Based on There transaction can be carried out either to Enable or reject it).

  The steps shown in process 600 of FIG. 6 are merely exemplary, and the existing steps may be modified or omitted, additional steps may be added, and the order of particular steps may be changed. It is understood that it may be done. In some embodiments, potential transactions (eg, as identified by potential transaction data 660 or potential transaction data 672) are at least partially funded by two different payment credentials. May be For example, the client device 100 ′ may initiate generation of first host transaction data (eg, first host transaction data 684) that may operate to fund a first portion of a transaction. A second host transaction operable to fund a second portion of the transaction as well as a first payment request (eg, first payment request data 666) to a first host device A second settlement request (eg, second settlement request data 666) to a second host device to initiate generation of data (eg, second host transaction data 684), also to transmit And each instance of host transaction data can be It may be shared by the client device 100 'to fund down. Alternatively, the second part of the transaction may be funded by the client device 100 'with native credential data. Although not shown, secure host transaction data may be directly from the commercial entity subsystem 400 to the client device 100 '(e.g., via communication path 95 and not via host device 100), or a retailer. Directly to subsystem 200 (eg, via communication path 85 and not via host device 100 and / or not via client device 100 '), or directly to financial institution subsystem 350 (eg, Communication may be via communication path 55 and not via host device 100 and / or not via client device 100 ′ and / or not via merchant subsystem 200. Additionally or alternatively, although not shown, secure host transaction data may be directly from the host device 100 to the merchant subsystem 200 (eg, not via the client device 100 ') or a financial institution It may be sent directly to subsystem 350 (e.g., via communication path 75 and not via client device 100 'and / or not via merchant subsystem 200). Additionally or alternatively, although not shown, client transaction data may be communicated directly from client device 100 'to financial institution subsystem 350 (e.g., not via merchant subsystem 200) . As mentioned above, to determine that the client device 100 'should purchase a particular product, to obtain associated potential transaction data from at least one particular merchant of that particular product May be configured to interact with one or more retailers, all automatically and without any active interaction by the user of client device 100 '(eg, client device 100' is a consumer electronics device Yes, and can be a home appliance that can be configured to determine that a home appliance must be purchased (eg, detecting that more laundry detergent is needed by the washing machine, or Detect calendar events preset by the user to purchase more detergent on a particular day), A particular retailer can be automatically identified that provides the best deal for the item, and potential transaction data to automatically interact with the retailer to purchase the product from the retailer You can get The client device 100 'can then operate to automatically generate and push a payment request (e.g., payment request data 666) to one or more specific target host devices. For example, such client device 100 'may be an automated device that may be paired with 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 payment request may be at least partially captured or otherwise captured according to a predetermined setting (e.g., payment of a new laundry detergent from host device X Request payment for a new dryer sheet from host device Y, or request payment for any purchases over $ G from host device X and less than $ G from host device Y, etc. ).

  Data communication between host device 100 and client device 100 ′ of process 600, some or each (eg, one or several of data 662, 664, 666, 668, 674, 684, and / or 698) (Or each communication) may be any suitable communication protocol, such as directly in a peer-to-peer deployment, or through the commercial entity subsystem 400 or any other suitable entity, etc. It may be performed via any suitable communication path using any suitable transport mechanism that may or may not be encrypted in any way. Such data communication may occur via any suitable online messaging, instant messaging, email messaging, text messaging, any suitable proximity messaging, NFC, BlueTooth®, etc. It can be enabled using any suitable device addressing scheme such as phone number, email address, unique device identifier, location based beacons, etc. Each host device and each client device may be a laptop, a cell phone, a home appliance, a retailer accessory device (e.g. a device provided by a gasoline retailer with a gas pump), a user accessory (e.g. a wearable device such as a smart watch) , Etc. may be any suitable device having any suitable UI and I / O capabilities for the user. Any host device with a native payment credential may or may not itself have a native payment credential (for example, with or have its own native payment) System 1 and process 600 have many secure and effective uses by allowing them to receive and respond to payment requests (for example, via the public Internet or in any other suitable way) from Case and user experience can be enabled.

  For example, the user may be an online merchant resource (eg, application 113 ') of merchant subsystem 200 on client device 100' (eg, laptop computer that may not have secure element or any native payment credentials). Use the to shop online and interact with the online resources to identify the specific product (eg, "Product B") to purchase. Online resources in response to the identification of the product (eg, in response to the user selecting “Buy with Secure Credential Payment” (eg, Apple PayTM by Apple Inc.) May be operative to present a payment sheet or any suitable UI on the client device 100 ′ to enable the user to enter a specific shipping address or other variable data (eg, As indicated by screen 190a, and may be updated by the user of client device 100 'through one or more iterations of steps 620 and 622, which may update other information (eg, the user of client device 100' Is information 307d In response to changing the shipping address, the price of the information 307c may be updated): At some point, the user of the client device 100 'selects the "Secure Pay" option 309 on screen 190a. Native payment suitable for the client device 100 'to fund the purchase of the payment sheet on screen 190a (eg, based on acceptable payment options indicated by potential transaction data 660) Automatically having no credentials and that "HD 1's PM X" (eg, payment method X of host device 1) is the only available or preferred non-native payment credentials suitable for use Can be identified (eg, client device A discovery process (eg, steps 662 and 664) may be provided (eg, proximity of each available available host device to a client device, or discovery) without any further interaction by a user of 00 '. The priority may be determined automatically based on any other suitable characteristic that may be accessible to the client device 100 'through the process) After such identification, the client device 100' , To automatically present the screen 190c of FIG. 3C to the user of the client device 100 'and enable the user to select option 315 of FIG. 3C to send the appropriate payment request to that host device. Or the process 600 may select on behalf of the user (E.g., by automatically sending the appropriate payment request data 666/674 to the available target host device 1 (i.e. host device 100) in response to the identification of the discovery process). ), Which may result in the screen 190d of FIG. 3D or the screen 190e of FIG. 3E being automatically presented by the host device 100 (eg, similar to the payment sheet presented to the client device 100 ′) Present a payment sheet on the good host device 100). Host device 100 may be a mobile phone or any other device that may include a secure element having at least one native payment credential suitable to fund transactions initiated by client device 100 '. . The user of the client device 100 'may be in proximity to the host device 100 as well as the client device 100', and interacts with the GUI of one of the screens 190d-190f of the host device 100 to interact with the client device 100 'and Native to host device 100 to fund a transaction that has been initiated or otherwise performed by merchant subsystem 200 (eg, by selecting authentication option 331 of screen 190f of FIG. 3F) You can authorize the use of certain payment credentials. In response to such authentication on host device 100, host payment credential data of native credentials may be provided to financial institution subsystem 350 to attempt to fund the transaction to host device 100 (eg, The transaction's confirmation status may then be shared with the user of client device 100 'and / or host device 100 (eg, via screen 190h of FIG. 3H)) (steps 625-640 of process 600). In an alternative embodiment, multiple host devices are identified as available, and a payment request may be sent from the client device 100 'to each one of the available host devices, and responsive with host payment credential data A first host device can fund the transaction, or each host device can respond with host payment credential data that can fund particular portions of the transaction.

  As another example, a user's home appliance client device 100 '(e.g., a washing machine) communicatively coupled to a communication network using a home automation platform (e.g., Apple Inc.'s HomeKit (TM)) is suitably It can be operated to determine that the resources required to operate are almost gone (e.g. the washing machine client device 100 'has a 20% capacity of its laundry detergent storage Can operate to determine automatically). In response to such a determination, the home appliance client device 100 'can operate to automatically identify the opportunity to purchase more of its resources (eg, the home appliance client device 100' Interact with one or more retailer subsystems via one or more on-line resources to operate to identify the required laundry detergent that is selling at the best price or other appropriate indicator it can). Potential transaction data 660/672 for the purchase opportunity may thereby be obtained by the client device 100 ', the client device 100' having at least one host available to fund the transaction. At least one person capable of operating to automatically discover devices (eg, via the discovery process of steps 662/664) and associated with a home automation platform ecosystem including home appliance client devices 100 ' The appropriate payment request data 666/674 may be automatically shared with each of the at least one discovered host device, such as the user's host device of. The host device 100 can receive such payment request data, and in a transaction identified by the home appliance client device 100 '(e.g., identified without any active user interaction at the client device 100'). A user of host device 100 can be presented with the ability to select and authenticate native payment credentials to that host device for use in funding. This is because the user at any appropriate location for the home appliance client device 100 'and the host device 100 receives a unique payment request from the home appliance client device 100', and the home appliance client device 100 ' Providing host transaction data of native payment credentials to a host device for use in funding transactions associated with the unique payment request can be enabled (eg, host device 100 and its user May be located on the other side of the person from the home appliance client device 100 ′, but still receive a payment request from the home appliance client device 100 ′ and respond with host payment credential data (eg, optional Suitable Such Internet communication path, or any other over an appropriate communication path) may operate). Alternatively, rather than communicating remotely via the Internet, the consumer electronics client device 100 'may be scanned by the sensor of the proximity host device 100 and processed to identify specific payment request data. The QR code can be presented on the display, or the client device 100 'and the host device 100 can communicate via BlueTooth or any other suitable local communication protocol .

  In some embodiments, at least a portion of processes 500 and / or 600 and / or any other processes of the present disclosure operate to remit between a user of host device 100 and a user of client device 100 ' (E.g., client device 100 'can request funding from host device 100 independently of transactions between client device 100' and a merchant subsystem). In some embodiments, this does not require any merchant subsystem by the acquiring bank and / or one or more entities of the financial institution subsystem 350, and host transaction data is associated with the credentials on the host device It may be enabled to facilitate the transfer of funds between the account that has been created and the account associated with the user of the client device. Alternatively, funds can be transferred between the host and the client using stored value cards on the host device and / or stored value cards on the client device (e.g. Transfer the credentials from the credentials on the secure element 145 of the host device 100 to the stored value credentials native to the client device (eg, the credentials on the secure element of the client device 100 '). For example, the client device 100 'may communicate a payment request to the host device 100, which may operate to request the host device 100 to subtract a certain amount of currency from the stored value credentials on the host device 100, any suitable APDU commands can be sent to client device 100 'that can operate to add the appropriate amount of currency to the client device 100' stored value credentials (eg, host transaction shared with client device 100 ' As the data can include such APDU commands and / or can include the actual cryptographic currency).

If the client device 100 'may communicate with the merchant subsystem 200 via the native application on the client device 100', which may be retailer specific, then the merchant application 113c is provided by such application obtain. However, although the client device 100 'is not unique to the retailer, the merchant sub-system via the Internet browser may be shown on a website managed by the retailer (eg, on a server under control of the retailer). If the merchant application 113c can communicate with the system 200, the merchant application 113c can forward the communication to the merchant's website, even via a layout engine software component (eg, WebKit) (eg, via the communication component 106) Good. For example, such an application 113c of client device 100 'can be a conduit for any host transaction data provided to merchant subsystem 200. Alternatively, such host transaction data may be communicated to the merchant subsystem 200 directly (eg, potential) from the host device 100 or the commercial entity subsystem 400 instead of via the client device 100 '. Transactional data and payment request data of the client device (using the merchant identifier or address provided by the merchant)).
Explanation of FIG. 7

  FIG. 7 is an illustration for performing merchant transactions and financial transactions using a host electronic device including a commercial entity subsystem, a client electronic device and a secure element and a host credential application provisioned on the secure element. Flowchart of the process 700. At step 702 of process 700, the host electronic device receives payment request data from the client electronic device including retailer subsystem identifier information identifying a retailer subsystem and host credential application identifier information identifying a host credential application. be able to. For example, host electronic device 100 may receive payment request data 662 that includes the identifier of merchant subsystem 200 and the identifier of credential payment applet 153 a of host electronic device 100. At step 704 of process 700, the host electronic device can generate first data including host payment credential data on the secure element using the host credential application identified by the received payment request data. . For example, credential payment applet 153 a identified by payment request data 666 may generate host payment credential data 675. At step 706 of process 700, the host electronic device encrypts the first data and merchant subsystem identifier information of the received payment request data using the first key on the host electronic device secure element Thus, the second data can be generated. For example, the host electronic device 100 can use the access key as host payment data 677 to encrypt host payment credential data 675 and payment request data including an identifier of the merchant subsystem 200. At step 708 of process 700, the host electronic device can transmit the second data from the host electronic device to the commercial entity subsystem. For example, host electronic device 100 can transmit host payment data 678 to commercial entity subsystem 400. At step 710 of process 700, the host electronic device can receive third data that includes the first data encrypted with the second key associated with the merchant subsystem identifier information. For example, host electronic device 100 may receive secure host transaction 682 which may include host payment credential data 675/676 encrypted with a merchant key associated with merchant subsystem 200. At step 712 of process 700, the host electronic device can transmit the received third data to fund at least a portion of the financial transaction. For example, host electronic device 100 can transmit secure host transaction data 684 (eg, for merchant subsystem 200) to fund at least a portion of a financial transaction.

The steps shown in process 700 of FIG. 7 are merely exemplary, and existing steps may be modified or omitted, additional steps may be added, and the order of particular steps may be changed. It is understood that it may be.
Description of FIG. 8

  FIG. 8 is a flow chart of an example process 800 for performing a merchant subsystem and a financial transaction using a client electronic device and a host electronic device. At step 802 of process 800, the client electronic device can receive potential transaction data indicative of a financial transaction from the merchant subsystem. For example, client electronic device 100 ′ may receive potential transaction data 660 indicative of a financial transaction from merchant subsystem 200. At step 804 of process 800, the client electronic device can transmit payment request data from the client electronic device to the host electronic device based on the received potential transaction data. For example, client electronic device 100 ′ can send payment request data 666/674 to host electronic device 100 based on potential transaction data 660/672. At step 806 of process 800, the client electronic device may receive host transaction data at the client electronic device that includes host payment credential data generated by the host electronic device based on the sent payment request data. For example, secure host transaction data 684 including host payment credential data 675 generated by host electronic device 100 may be received by client electronic device 100 '. At step 808 of process 800, the client electronic device sends host settlement credential data of the received host transaction data from the client electronic device to the merchant subsystem to fund at least a portion of the financial transaction. Can. For example, client electronic device 100 'may sub-submit client transaction data 686, including host payment credential data 675, to fund at least a portion of a financial transaction (eg, for merchant subsystem 200). It can be sent to system 200.

The steps shown in process 800 of FIG. 8 are merely exemplary, and existing steps may be modified or omitted, additional steps may be added, and the order of particular steps may be changed. It is understood that it may be.
Description of FIG. 9

  FIG. 9 is an illustration for performing merchant transactions and financial transactions using a host electronic device including a commercial entity subsystem, a client electronic device, and a secure element and a host credential application provisioned on the secure element. Flowchart of the process 900. At step 902 of process 900, the commercial entity subsystem receives a host availability request from the client electronic device identifying at least one payment type acceptable to the merchant subsystem to fund the financial transaction. be able to. For example, commercial entity subsystem 400 identifies at least one payment type acceptable to merchant subsystem 200 to fund financial transactions (eg, based on potential transaction data 660) Host availability request data 662 from client device 100 'may be received. At step 904 of process 900, the commercial entity subsystem may determine in the commercial entity subsystem that the host electronic device is associated with the client electronic device. For example, commercial entity subsystem 400 may associate that host electronic device 100 is associated with client electronic device 100 '(e.g., both devices are associated with the same particular user account of the commercial entity subsystem). It can operate to make a decision. In step 906 of process 900, the commercial entity subsystem receives the host credential application provisioned on the host electronic device's secure element based on the determination that the host electronic device is associated with the client electronic device. It can be determined that the identified at least one payment type of the host availability request is fulfilled. For example, the commercial entity subsystem 400 can operate to determine that the payment credential applet 153a is associated with a payment method (eg, Visa credit card) acceptable to the merchant subsystem 200. In step 908 of process 900, the commercial entity subsystem identifies the host electronic device from the commercial entity subsystem to the client electronic device based on the determination that the host credential application satisfies the at least one payment type identified. Availability response can be sent. For example, commercial entity subsystem 400 operates to send host availability response data 664 to client electronic device 100 'that can identify host electronic device 100 (eg, as an available non-native payment source) Can.

The steps shown in process 900 of FIG. 9 are merely exemplary, and existing steps may be modified or omitted, additional steps may be added, and the order of particular steps may be changed. It is understood that it may be.
Description of FIG.

  FIG. 10 is a flowchart of an example process 1000 for performing transactions with a service provider subsystem using client electronic devices and host electronic devices. At step 1002 of process 1000, the client electronic device can communicate with the service provider subsystem to define at least a portion of a transaction for purchasing access to a product of the service provider subsystem. For example, client electronic device 100 ′ may receive potential transaction data 660 indicative of a financial transaction from merchant subsystem 200. At step 1004 of process 1000, the client electronic device can engage the host electronic device to generate transaction credentials for funding the transaction. For example, client electronic device 100 ′ can send payment request data 666/674 to host electronic device 100 based on potential transaction data 660/672.

The steps shown in process 1000 of FIG. 10 are merely exemplary, and existing steps may be modified or omitted, additional steps may be added, and the order of particular steps may be changed. It is understood that it may be.
Further Description of FIG. 1, FIG. 1A, FIG. 1B, FIG. 2, FIG. 2A, and FIG.

  The credentials of the secure element of the host device 100 are suitably as host payment credential data of host transaction data (eg as contactless proximity based communication to the merchant terminal 220 and / or as online based communication to the merchant server 210) 2.) As provided, the acquisition bank subsystem 300 with the financial institution subsystem 350 when activated (eg, commerce credential data associated with the activated applet 153a of the credential SSD 154a of the NFC component 120) Such host payment credential data may be utilized to complete a financial transaction of For example, after the user of the client device 100 'selects the product for purchase and the user of the host device 100 has properly enabled the use of certain credentials of the device 100 for payment, the merchant subsystem 200 May receive host payment credential data indicating payment credential data for a particular credential. The merchant server 210 and / or the merchant terminal 220 provide products or services to the user of the end-user electronic device in response to the device 100 providing host payment credential data (eg, via the client device 100 ') It may be provided by any suitable retailer or merchant agent of merchant subsystem 200. Based on such received host payment credential data (e.g., as data 686), merchant subsystem 200 (e.g., via communication path 25 between merchant subsystem 200 and acquisition bank subsystem 300). May be configured to generate and send data 688 to the acquisition bank subsystem 300, the data 688 indicating host payment credential data and the purchase price of the host device payment credentials and the retailer of the product or service. May include an authorization request to obtain. The acquisition bank subsystem 300, also known as the payment processor or acquirer, may be a retail banking partner associated with the retailer subsystem 200, and the acquisition bank subsystem 300 cooperates with the financial institution subsystem 350. In operation, host payment credential data may be configured to approve and settle credential transactions that are attempted to be funded by host device 100. Acquisition bank subsystem 300 may then transfer the authorization request from payment data 688 to financial institution subsystem 350 as authorization data 690 (eg, communication path between acquisition bank subsystem 300 and financial institution subsystem 350) Through).

  The payment network subsystem 360 and the issuing bank subsystem 370 may be a single entity or separate entities. For example, American Express may be both a payment network subsystem 360 and an issuing bank subsystem 370. On the other hand, Visa and MasterCard may be a payment network 360 and may operate in cooperation with an issuing bank 370 such as Chase, Wells Fargo, Bank of America and the like. The financial institution subsystem 350 may also include one or more acquisition banks, such as the acquisition bank subsystem 300. For example, the acquisition bank subsystem 300 may be the same entity as the issuing bank system 370. One, some, or all components of the acquisition bank subsystem 300 may be the same as or similar to one or more processor components of the processor component 102 of the device 100, or the memory component 104 of the device 100. May be implemented using one or more memory components that may be, and / or one or more communication components that may be the same as or similar to communication component 106 of device 100. One, some or all components of payment network subsystem 360 are one or more processor components that may be the same as or similar to processor component 102 of device 100, the same as or similar to memory component 104 of device 100 May be implemented using one or more memory components that may be, and / or one or more communication components that may be the same as or similar to communication component 106 of device 100. One, some or all components of the issuing bank subsystem 370 are one or more processor components that may be the same as or similar to the processor component 102 of the device 100, the same as or similar to the memory component 104 of the device 100 May be implemented using one or more memory components that may be, and / or one or more communication components that may be the same as or similar to communication component 106 of device 100. If payment network subsystem 360 and issuing bank subsystem 370 are separate entities, payment network subsystem 360 can receive data 690 from acquiring acquirer subsystem 300 and then issue a request. It may be transferred to the banking subsystem 370 as data 405 (eg, via the communication path 45 between the payment network subsystem 360 and the issuing bank subsystem 370). If the payment network subsystem 360 and the issuing bank subsystem 370 are the same entity, the acquiring bank subsystem 300 can submit data 690 directly to the issuing bank subsystem 370. Further, payment network subsystem 360 may respond to the acquiring bank subsystem 300 on behalf of the issuing bank subsystem 370 (e.g., according to the terms agreed between the payment network subsystem 360 and the issuing bank subsystem 370). ). By interfacing between the acquiring bank subsystem 300 and the issuing bank subsystem 370, the payment network subsystem 360 can determine the number of entities that the acquiring bank subsystem 300 and each issuing bank subsystem 370 must interact directly with. Can be reduced. That is, in order to minimize the direct integration point of the financial institution subsystem 350, the payment network subsystem 360 can function as an aggregator for the various issuing banks 370 and / or the various acquiring banks 300. . The financial institution subsystem 350 may also include one or more acquisition banks, such as the acquisition bank subsystem 300. For example, the acquiring bank subsystem 300 may be the same entity as the issuing bank subsystem 370.

  When the issuing bank subsystem 370 receives the authorization request (eg, directly as data 690 from the acquiring bank subsystem 300 or indirectly as data 405 via the payment network subsystem 360), payment information (eg, device) The purchase amount included in the transaction request information and the authorization request may be analyzed to determine if the account associated with the transaction credential has sufficient credits to cover the purchase amount. If sufficient funding is not present, the issuing bank subsystem 370 can reject the requested transaction by sending a negative authorization response to the acquiring bank subsystem 300. However, if sufficient funding is present, the issuing bank subsystem 370 can approve the requested transaction by sending a positive authorization response to the obtaining bank subsystem 300, and the financial transaction is completed. obtain. Any type of authorization response may be provided by the user financial subsystem 350 to the acquiring bank subsystem 300 as authorization response data or transaction status data 692 (eg, transaction status data 692 may be issued to the issuing bank subsystem 370 The transaction status data 692 may be provided from the issuing bank subsystem 370 to the payment network subsystem 360 via the communication path 45, or may be provided directly to the acquisition bank subsystem 300 via the communication path 35. It may be provided from the payment network subsystem 360 to the acquisition bank subsystem 300 based on the authorization response data or the transaction status data 415).

  As mentioned above, and as shown in FIG. 2, the host electronic device 100 may be a music player (e.g., an iPod (R) available by Apple Inc. of Cupertino, California), a video player, a still image player, a game Players, other media players, music recorders, movie or video cameras or recorders, still cameras, other media recorders, wireless, medical equipment, home or commercial electrical appliances, transport vehicle instruments, musical instruments, calculators, mobile phones (eg , IPhone (R) available by Apple Inc., other wireless communication devices, portable terminals, remote controls, pagers, computers (e.g. desktops, laptops, tablets (e.g. available by Apple Inc.) (Including iPad), servers, etc.) monitors, TVs, stereo equipment, setup boxes, set-top boxes, boom boxes, modems, routers, printers, or any combination thereof. It is not limited to. In some embodiments, electronic device 100 may perform a single function (e.g., a dedicated device performing financial transactions), and in other embodiments, electronic device 100 may perform multiple functions. (Eg, a device that performs financial transactions, plays music, receives and sends calls). Electronic device 100 can be any portable, mobile, handheld or small electronic device that can be configured to perform financial transactions wherever the user moves. Some small electronic devices can have a smaller form factor than that of handheld electronic devices such as iPods. Exemplary small electronic devices include watches (e.g. Apple Watch (TM) by Apple Inc.), rings, necklaces, belts, accessories for belts, headsets, accessories for shoes, virtual reality devices, glasses, other wearable electronics It may be integrated into a variety of objects including, but not limited to, equipment, sports equipment accessories, fitness equipment accessories, key chains, or any combination thereof. Alternatively, host electronic device 100 may not be portable, but instead may be generally stationary.

  As shown in FIG. 2, for example, electronic device 100 may include processor 102, memory 104, communication component 106, power supply 108, input component 110, output component 112, antenna 116, and near field communication (“NFC”) component 120. Can be included. Electronic device 100 may provide one or more wired or wireless communication links or paths for transmission of data and / or power from or between various other components of device 100. Can also be included. In some embodiments, one or more components of electronic device 100 may be combined or omitted. Furthermore, the electronic device 100 can include other components that are not combined or included in FIG. For example, electronic device 100 may include any other suitable components or some instances of the components shown in FIG. For simplicity, only one of each component is shown in FIG.

  Memory 104 may be, for example, a hard drive, flash memory, permanent memory such as read only memory ("ROM"), semi-permanent memory such as random access memory ("RAM"), any other suitable type of storage component, Or one or more storage media including any combination thereof. Memory 104 may include cache memory, which may be one or more different types of memory used to temporarily store data for electronic device applications. The memory 104 may be fixedly incorporated into the electronic device 100 or repeatedly be inserted into and removed from the electronic device 100 with one or more suitable types of cards (eg, a subscriber identity module (“ It may be incorporated into a SIM ") card or a Secure Digital (" SD ") memory card). The memory 104 includes media data (for example, music and image files), software (for example, software for implementing a function on the device 100), firmware, preference information (for example, media playback preference), lifestyle information (for example, food) Preference), (eg, information obtained by the exercise monitoring device), transaction information (eg, information such as credit card information), wireless connection information (eg, information enabling the device 100 to establish a wireless connection) , Subscription information (eg, information tracking a podcast or television show or other media to which the user has subscribed), contact information (eg, telephone number and email address), calendar information, any other suitable Store data, or any combination thereof It is possible.

  Communication component 106 communicates with device 100 with one or more other electronic devices or servers or subsystems (eg, one or more subsystems or other components of system 1) using any suitable communication protocol. It may be provided to be able to communicate. For example, the communication component 106 may be Wi-Fi (e.g. 802.11 protocol), ZigBee (e.g. 802.15.4 protocol), WiDi (R), Ethernet (R), Bluetooth (R), Bluetooth (R) Trademarks Low Energy ("BLE") (eg, 900 MHz, 2.4 GHz and 5.6 GHz communication systems), Infrared, Transmission Control Protocol / Internet Protocol ("TCP / IP") (eg, at each TCP / IP layer) Any of the protocols used), Stream Control Transmission Protocol ("SCTP"), Dynamic Host Configuration Protocol ("DHCP"), hypertext Transmission Protocol ("HTTP") BitTorrent (TM), File Transmission Protocol ("FTP"), Real-Time Transmission Protocol ("RTP"), Real-Time Streaming Protocol ("RTSP"), Real-Time Control Protocol ("RTCP"), Remote Audio Output Protocol ("RAOP"), Real Data Transport Protocol ("RTTP"), User Datagram Protocol ("UDP"), Secure Shell Protocol (SSH), Wireless Delivery System ("WDS") Bridging, Wireless and Portable Telephone and personal e-mail devices (e.g. GSM (Global System for Mobile Communica) Ions))) Any communication protocol that may be used, GSM plus Enhanced Data Rate ("EDGE") for GSM Evolution, Code Division Multiple Access ("CDMA"), Orthogonal Frequency-Division Multiple Access ("OFDMA"), high-speed packet access ("HSPA"), multi-band etc., any communication protocol that may be used by a low power Wireless Personal Area Network ("6LoWPAN") module, or any other communication protocol, or Any combination of them can be supported. Communication component 106 may activate any suitable transceiver circuitry (eg, transceiver circuitry or bus 118) that may enable device 100 to be communicatively coupled to another device (eg, a host computer or accessory device). An antenna 116) may also be included or electrically coupled to it, and may communicate with its other devices wirelessly or via a wired connection (e.g., using a connector port). Communication component 106 may be referred to as an online communication component if it operates to communicate any suitable data to any remote server or other suitable entity (eg, to any suitable internet connection). . Communication component 106 may be configured to determine the geographical location of electronic device 100. For example, communication component 106 may utilize a global positioning system ("GPS"), or a regional or site-wide positioning system that may use cell tower positioning technology or Wi-Fi technology.

  Power supply 108 may include any suitable circuitry for receiving and / or generating power, as well as providing such power to one or more components of electronic device 100. For example, power supply 108 may be coupled to a power grid (e.g., when device 100 is not operating as a portable device or when the device's battery is charged with power generated by a power plant at an electrical outlet). As another example, power supply 108 may be configured to generate power from a natural source (eg, photovoltaic power generation using solar cells). As another example, power supply 108 may include one or more batteries to provide power (eg, when device 100 is operating as a portable device). For example, the power supply 108 may be a battery (eg, gel, nickel metal hydride, nickel cadmium, nickel hydrogen, lead acid, or lithium ion battery), an uninterruptible power supply or a continuous power supply (UPS), and power received from a power generation source. One or more of the circuits (e.g., generated by the power plant and supplied to the user via an electrical socket or the like) can be included. Power may be supplied by the power source 108 as alternating or direct current and may be processed to convert power to particular characteristics or to limit received power thereto. For example, power may be converted to or from direct current, such as average power, active power, peak power, energy per pulse, voltage, current (eg, measured in amperes), or any other characteristic of received power. Can be constrained to one or more values of Power supply 108 may operate to request or provide specific amounts of power at different times, for example, based on the needs or requirements of electronic device 100 or peripheral devices that may be coupled to electronic device 100 (eg, Requires more power when charging the battery, not when the battery is already charged).

  One or more input components 110 may be provided to allow the user to interact or interface with the device 100. For example, the input component 110 can be a touch pad, dial, click wheel, scroll wheel, touch screen, one or more buttons (eg, keyboard), mouse, joystick, trackball, microphone, camera, scanner (eg, barcode scanner) Or bar code, any other suitable scanner that can obtain product identification information from a code such as QR Code (registered trademark), proximity sensor, light detector, motion sensor, biometric sensor (eg, authenticate the user) It can take various forms, including a fingerprint reader or other feature recognition sensor operating with a feature processing application accessible to the electronic device 100) and combinations thereof. Each input component 110 may be configured to provide one or more dedicated control functions for making selections or issuing commands associated with the operating device 100.

  Electronic device 100 can also include one or more output components 112 that can present information (eg, graphical, audible and / or tactile information) to the user of device 100. For example, the output components 112 of the electronic device 100 may include audio speakers, headphones, audio line outs, visual displays, antennas, infrared ports, haptic output components (eg, tumblers, vibrators, etc.), or combinations thereof. It can take various forms, not limited to.

  As a specific example, electronic device 100 can include a display output component as output component 112. Such display output components can include any suitable type of display or interface for presenting visual data to a user. The display output component can include a display integrated into device 100 or a display coupled to device 100 (e.g., a removable display). Display output components can be, for example, liquid crystal displays (LCDs), light emitting diodes ("LEDs") displays, organic light emitting diodes ("OLEDs") displays, surface conduction electron emitting displays ("SEDs"), carbon nanotube displays, nanocrystals A display, any other suitable type of display, or a combination thereof may be included. Alternatively, the display output component may be a movable display or projection for providing display of content on a surface remote from the electronic device 100, such as, for example, a video projector, a head-up display, or a three-dimensional (e.g. holographic) display. System can be included. As another example, the display output component can include a digital or mechanical viewfinder, such as a compact digital camera, a reflex camera, or any other suitable stationary or type found on video cameras. . The display output component may include display driver circuitry, circuitry for driving the display driver, or both, such display output components may include content that may be under the direction of the processor 102 (eg, media playback information, electronic An application screen of an application implemented on the device 100, information on ongoing communication operations, information on incoming communication requests, device operation screens, etc.) may be displayed.

  One or more input components and one or more output components are collectively referred to herein as input / output ("I / O") components or I / O interfaces (e.g., input component 110 and output component 112). It should be noted that the component may be referred to as component or I / O interface 114). For example, the input component 110 and the output component 112 may be touch screens, etc., which allow the user to touch the display screen to receive input information and provide visual information to the user through the same display screen. It may be a single I / O component 114.

  Processor 102 of electronic device 100 may include any processing circuitry that may operate to control the operation and performance of one or more components of electronic device 100. For example, processor 102 may receive an input signal from input component 110 and / or a drive output signal via output component 112. As shown in FIG. 2, processor 102 may be used to execute one or more applications, such as application 103, application 113, and / or application 143. Each application 103/113/143 includes one or more operating system applications, firmware applications, media playback applications, media editing applications, NFC low power mode applications, biometric feature processing applications, or any other suitable application Although it can be, it is not limited to these. For example, processor 102 may load application component 103/113/143 as a user interface program so that instructions or data received via input component 110 or other components of device 100 may store information and / or It can be determined how the methods that can be provided to the user via the output component 112 can be manipulated. Applications 103/113/143 may be accessed by processor 102 from any suitable source, such as from memory 104 (eg, via bus 118) or from another device or server (eg, via communications component 106) It may be done. Processor 102 can include a single processor or multiple processors. For example, processor 102 may include at least one "general purpose" microprocessor, a combination of general and special purpose microprocessors, an instruction set processor, a graphics processor, a video processor, and / or an associated chipset, and / or a special purpose microprocessor Can be included. Processor 102 may also include onboard memory for caching purposes.

  Electronic device 100 may also include near field communication (“NFC”) component 120. NFC component 120 is any suitable proximity based communication mechanism that enables contactless proximity based transactions or communication between electronic device 100 and merchant subsystem 200 (eg, merchant payment terminal 220). It is also good. The NFC component 120 can enable close range communication at relatively low data rates (e.g., 424 kbps), and ISO / IEC 7816, ISO / IEC 18092, ECMA-340, ISO / IEC 21481, ECMA-352, ISO 14443, And / or may conform to any suitable standard, such as ISO 15693. Alternatively or additionally, the NFC component 120 can enable close range communication at relatively high data rates (eg, 370 Mbps) and conform to any suitable standard, such as the TransferJetTM protocol. Can. The communication between the NFC component 120 or NFC component 120 ′ and the merchant subsystem 200 is any suitable proximity distance, such as in the range of about 2 to 4 centimeters, between the NFC component and the merchant subsystem 200. Operating at any suitable frequency (eg, 13.56 MHz), which may be performed within the distance (see, eg, distance D in FIGS. 1A and 1B between NFC component 120 ′ and merchant payment terminal 220) be able to. For example, such close range communication of the NFC component may allow the NFC component to communicate with other NFC devices and / or to obtain information from tags that have radio frequency identification ("RFID") circuitry. It can be done via induction. Such an NFC component can obtain product information, transfer payment information, and provide a way to communicate with the external device in other ways (eg, between the NFC component 120 'and the merchant terminal 220, And / or communicate between the NFC component 120 'and the NFC component 120).

  NFC component 120 may include any suitable module for enabling contactless proximity based communication between electronic device 100 and merchant subsystem 200. As shown in FIG. 2, for example, the NFC component 120 can include an NFC device module 130, an NFC controller module 140, and an NFC memory module 150.

  The NFC device module 130 may include an NFC data module 132, an NFC antenna 134, and an NFC booster 136. The NFC data module 132 includes, routes or otherwise provides any suitable data that may be transmitted to the merchant subsystem 200 by the NFC component 120, either as contactless proximity based or as part of the NFC communication 5. It may be configured to Additionally or alternatively, NFC data module 132 includes, routes, or otherwise includes any suitable data that may be received by NFC component 120 from merchant subsystem 200 as part of contactless proximity based communication. (E.g., communication 5 between the NFC component 120 'and the merchant terminal 220).

  NFC transceiver or NFC antenna 134 may be any suitable antenna or other that generally enables communication of communications from NFC data module 132 to retailer subsystem 200 and / or from NFC subsystem 200 to NFC data module 132. Or any suitable transceiver circuit. Thus, an NFC antenna 134 (eg, a loop antenna) may be specifically provided to enable the contactless proximity based communication capability of the NFC component 120.

  Alternatively or additionally, NFC component 120 can utilize the same transceiver circuitry or antenna (eg, antenna 116) that can be utilized by another communication component (eg, communication component 106) of electronic device 100. For example, communication component 106 may utilize antenna 116 to enable Wi-Fi, Bluetooth, cellular, or GPS communication between electronic device 100 and another remote entity, while NFC component 120 may utilize antenna 116 to enable contactless proximity based or NFC communication between NFC data module 132 of NFC device module 130 and another entity (e.g., merchant subsystem 200). Can. In such embodiments, the NFC device module 130 can include an NFC booster 136 that can be configured to provide appropriate signal amplification to data of the NFC component 120 (eg, data in the NFC data module 132) Such data may be suitably transmitted as a communication to subsystem 200 by shared antenna 116. For example, before shared antenna 116 can be properly enabled to communicate contactless proximity base or NFC communication between electronic device 100 and merchant subsystem 200 before antenna 116 (eg, non-loop antenna) can be properly enabled, It may require amplification from the booster 136 (eg, more power may be required to transmit other types of data using the antenna 116, but using the antenna 116) And may be required to transmit NFC data).

  NFC controller module 140 may include at least one NFC processor module 142. The NFC processor module 142 operates with the NFC device module 130 to enable, activate, authorize, and / or otherwise activate the NFC component 120 to communicate NFC communication between the electronic device 100 and the merchant subsystem 200. It can be controlled by a method. The NFC processor module 142 may be present as a separate component, integrated into another chipset, or integrated with the processor 102, eg as part of a system on chip ("SoC") It is also good. As shown in FIG. 2, the NFC processor module 142 of the NFC controller module 140 may execute one or more applications, such as an NFC low power mode or wallet application 143 that may serve to indicate the function of the NFC component 120. May be used. Applications 143 may include one or more operating system applications, firmware applications, NFC low power applications, or any other suitable application that may be accessible to NFC component 120 (e.g., applications 103/113) However, it is not limited to these. NFC controller module 140 may include one or more protocols, such as Near Field Communication Interface and Protocols ("NFCIP-1"), to communicate with another NFC device (e.g., retailer subsystem 200) . The protocol may be used to adapt the communication rate and designate one of the connected devices as an initiator device to control near field communication.

  The NFC controller module 140 may control the near field communication mode of the NFC component 120. For example, NFC processor module 142 may be in a peer-to-peer mode (e.g. communication 5) to exchange data with another NFC enabled device (e.g. retailer subsystem 200), from an NFC tag (e.g. Reader / writer mode (eg, communication 5) for reading information to NFC data module 132, and another NFC enabling device (eg, merchant subsystem 200) read information from NFC data module 132). The NFC device module 130 may be configured to switch between card emulation modes for enabling (e.g. communication 5). NFC controller module 140 may also be configured to switch NFC component 120 between active and passive modes. For example, the NFC processor module 142 may use an active mode in which the NFC device module 130 may generate its RF field, and another device in which the NFC device module 130 generates data RF fields using load modulation (e.g., retail) The NFC device module 130 may be configured to switch (eg, along with the NFC antenna 134 or the shared antenna 116) between passive modes that can be transferred to the quotient subsystem 200). Such passive mode operation may extend the battery life of the electronic device 100 as compared to such active mode operation. The mode of the NFC device module 130 may be defined or directed by an application (eg, application 103 and / or application 143) operating on device 100 and / or based on user preferences. It may be controlled based on the preference of the person.

  NFC memory module 150 may operate in conjunction with NFC device module 130 and / or NFC controller module 140 to enable NFC communication between electronic device 100 and merchant subsystem 200. NFC memory module 150 may be embedded in NFC device hardware or in an NFC integrated circuit (“IC”). The NFC memory module 150 may be tamper resistant and may provide at least a portion of the secure element. For example, NFC memory module 150 may store one or more applications for NFC communication (eg, application 143) that may be accessed by NFC controller module 140. For example, such applications may include financial payment applications, secure access system applications, point card applications, and other applications that may be encrypted. In some embodiments, the NFC controller module 140 and the NFC memory module 150 are operating systems intended to be used to store and execute confidential applications on the electronic device 100, either independently or in combination. A dedicated microprocessor system can be provided that can include memory, application environment, and security protocols. NFC controller module 140 and NFC memory module 150 may independently or in combination provide at least a portion of secure element 145 that may be tamper resistant. For example, such secure elements 145 may be configured according to rules and security requirements that may be set by a well-identified trusted authority (eg, authority of a financial institution subsystem and / or an industry standard such as GlobalPlatform). May be configured to provide a tamper resistant platform (eg, as a single or multiple chip secure microcontrollers) that can securely host confidential and encrypted data (eg, applets 153 and 155) . NFC memory module 150 may be part of memory 104 or at least one dedicated chip unique to NFC component 120. The NFC memory module 150 may exist as a SIM, a dedicated chip on the motherboard of the electronic device 100, or an external plug in a memory card. NFC memory module 150 may be completely independent of NFC controller module 140, may be provided by different components of device 100, and / or may be provided to electronic device 100 by a different removable subsystem Good. Secure element 145 may be a very secure tamper resistant hardware component within the chip that may be used to store sensitive data or applications on electronic device 100. At least a portion of secure element 145 may be provided in a removable circuit card, such as a Universal Integrated Circuit Card ("UICC") or a Subscriber Identity Module ("SIM") card, which is for mobile communications It may be used in a compatible electronic device 100 within a Global System ("GSM®") network, Universal Mobile Telecommunications System ("UMTS") and / or Long Term Evolution ("LTE") standard network. Alternatively, or additionally, at least a portion of secure element 145 may be provided in an integrated circuit that may be incorporated into electronic device 100 during manufacture of device 100. Alternatively, or additionally, at least a portion of the secure element 145 may be in a peripheral device that may be inserted, inserted or otherwise coupled to an electronic device 100, such as a micro secure digital ("SD") memory card. It may be provided.

  As shown in FIG. 2, the NFC memory module 150 may be an Issuer Security Domain ("ISD") 152 and an Additional Security Domain ("SSD") 154 (eg, "ISD"), which may be defined and managed by the NFC specification (eg, GlobalPlatform). Service provider security domain ("SPSD"), trusted service manager security domain ("TSMSD"), etc.). For example, ISD 152 may be part of NFC memory module 150, where a trusted service manager ("TSM") or issuing financial institution (eg, commercial entity subsystem 400 and / or financial institution subsystem) 350) store keys and / or other appropriate information for credential content management, and / or security domain management, one on electronic device 100 (eg, via communication component 106) Do you want to generate these credentials (eg, commerce credentials associated with various credit cards, bank cards, gift cards, access cards, transit passes, digital currency (eg, bitcoins and associated payment networks), etc.) Or other person In can be provisioned. A particular additional security domain ("SSD") 154 (eg, SSD 154a) may be associated with a particular TSM and at least one particular commerce credential (eg, a particular credit card credential or a public transit card credential), It can provide the electronic device 100 with certain privileges or payment rights. For example, the first payment network subsystem 360 (eg, Visa) is the TSM of the first SSD 154a, and the applet 153a of the first SSD 154a is the commerce credentials managed by the first payment network subsystem 360 The second payment network subsystem 360 (eg, a master card) may be the TSM of another SSD 154, although it may be associated with it.

  A security feature may be provided to activate the use of the NFC component 120 (e.g. to activate activation of the commerce credentials provisioned to the device 100), which may be a bank account of credit card information or credentials. It may be particularly useful when transmitting sensitive payment information, such as information, from the electronic device 100 to the merchant subsystem 200. Such security features may also include secure storage areas that may have limited access. For example, user authentication via personal identification number ("PIN") entry or via user interaction with a biometric sensor may be used to access a secure storage area (e.g. It may need to be provided) to change the life cycle state. In particular embodiments, some or all of the security features may be stored in NFC memory module 150. Further, security information, such as an authentication key, for communicating with subsystem 200 may be stored within NFC memory module 150. In particular embodiments, NFC memory module 150 may include a microcontroller embedded within electronic device 100.

  The merchant terminal 220 of the merchant subsystem 200 of FIG. 1B may communicate with the electronic device 100 or the electronic device 100 ′ (eg, when the client device 100 ′ is within a particular distance or proximity of the merchant terminal 220) From a reader for detecting, reading or receiving NFC communications. Thus, NFC communication between such a merchant terminal and the electronic device 100/100 ′ may occur wirelessly, and thus may not require a clear “line of sight” between each device Please note. As mentioned above, the NFC device module 130 may be passive or active. If passive, the NFC device module 130 can only be activated when within the response range of the appropriate reader of such a merchant terminal. For example, the reader of such a merchant terminal may use relatively low power radio waves that may be used to power the antenna utilized by the NFC device module 130 (e.g., shared antenna 116 or NFC specific antenna 134). The field emits, whereby the antenna transmits the appropriate NFC communication information (e.g. credit card credential information) from the NFC data module 132 to the merchant terminal such as NFC communication via antenna 116 or antenna 134. , Can be enabled to send. When active, the NFC device module 130 can incorporate or access a local power source to the electronic device 100 (e.g., power source 108), such that the shared antenna 116 or NFC-specific antenna 134 can be a passive NFC. Instead of reflecting the radio frequency signal as in the case of the device module 130, the NFC communication information (for example, credit card credential information) is retailed as NFC communication from the NFC data module 132 via the antenna 116 or the antenna 134. Active transmission to the merchant terminal 220 can be enabled. The merchant terminal 220 may be provided by a merchant of the merchant subsystem 200 (e.g., within the merchant's store to sell products or services directly to the user of the device 100 'at the store). Although NFC component 120 has been described for near field communication, component 120 may be any suitable contactless proximity based mobile payment between electronic device 100 and such a merchant terminal or any other suitable type of It should be understood that it may be configured to provide contactless proximity based communication. For example, NFC component 120 may be configured to provide appropriate short-range communications, such as those involving electromagnetic / capacitive coupling techniques.

  Although NFC component 120 has been described for near field communication, component 120 may be any suitable contactless proximity based mobile payment between electronic device 100 and merchant subsystem 200 or any other suitable type of non It should be understood that it may be configured to provide contact proximity based communication. For example, NFC component 120 may be configured to provide appropriate short-range communications, such as those involving electromagnetic / capacitive coupling techniques. Further, in some embodiments, the NFC component 120 'of the client device 100' may be the same as or substantially the same as the NFC component 120 of the host device 100. Alternatively, in some embodiments, the NFC component 120 'of the client device 100' is configured to include any suitable component that can be enabled for the processor 102 'or any other part of the device 100' NFC component 120 ′ may be communicated to host device 100 between NFC component 120 ′ of client device 100 ′ and retailer terminal 220 of retailer subsystem 200 as any suitable contactless proximity based communication. A security that operates to securely store a credential applet for generating secure credential data on the client device 100 'to securely fund financial transactions such as native credential data. It may or may not include an element.

  Electronic device 100 may also be provided with a housing 101 that may at least partially surround one or more components of device 100 for protection from debris and other degrading forces external to device 100. In some embodiments, one or more components may be provided in its own housing (eg, input component 110 may be provided in its own housing wirelessly or via a wire) It may be a separate keyboard or mouse that can communicate with the processor 102). Optional client device 100 ′ may include one, some or all of the features described for electronic device 100 and / or may include additional features not described for electronic device 100. Should be understood. Any host device 100 or any client device 100 'may be two or more devices operating together with each other (e.g. a mobile phone communicatively coupled via any suitable proximity communication protocol (e.g. BlueTooth (R)) It should also be understood that the combination may be provided as a combination of

  As mentioned above, and as shown in FIG. 3, one particular example of the electronic device 100 may be a handheld electronic device such as an iPhone®, and the housing 101 comprises various input components 110a. -110i, which may allow access to various output components 112a-112c, and various I / O components 114a-114d, through which the device 100 and the user and / or the surrounding environment interface with each other can do. The input component 110a may include a button that when pressed causes the device 100 to display the "home" screen or menu of the currently executing application. Input component 110b may be a button to toggle electronic device 100 between sleep mode and wake mode, or any other suitable mode. The input component 110c can include a two position slider that can disable one or more output components 112 in a particular mode of the electronic device 100. The input components 110d and 110e can include buttons for increasing or decreasing the volume output or other characteristic output of the output component 112 of the electronic device 100. Each one of the input components 110a-110e may be a mechanical input component such as a dome switch, a slide switch, a control pad, a key, a knob, a scroll wheel, or a button supported by any other suitable form. Good.

  Output component 112 a may be a display that may be used to display a visual or graphical user interface (“GUI”) 180 that allows the user to interact with electronic device 100. The GUI 180 may include various layers, windows, screens, templates, elements, menus, and / or other components of the currently executing application (eg, application 103 and / or application 113 and / or application 143). , They may be displayed in all or some of the area of the display output component 112a. For example, as shown in FIG. 3, the GUI 180 may be configured to display the first screen 190. One or more user input components 110 a-110 i may be used to navigate through the GUI 180. For example, one user input component 110 can include a scroll wheel that can allow the user to select one or more graphical elements or icons 182 of the GUI 180. The icons 182 may be selected via the touch screen I / O component 114a, which may include the display output component 112a and the associated touch input component 110f. Such touch screen I / O components 114a may use any suitable type of touch screen input technology, such as resistive, capacitive, infrared, surface acoustic wave, electromagnetic, or near field imaging. Additionally, the touch screen I / O component 114a can use single point or multipoint (eg, multi-touch) input sensing.

  Icons 182 may represent various layers, windows, screens, templates, elements, and / or other components that may be displayed in some or all areas of display component 112a upon selection by the user. Additionally, selection of a particular icon 182 can lead to a hierarchical navigation process. For example, selection of a particular icon 182 can lead to a new screen of GUI 180 that includes one or more additional icons or other GUI elements of the same application or a new application associated with that icon 182. A text indicator 181 may be displayed on or near each icon 182 to facilitate user interpretation of each graphical element icon 182. It should be understood that the GUI 180 may include various components arranged in hierarchical layer structures and / or non-hierarchical layer structures. When a particular icon 182 is selected, device 100 may be configured to open a new application associated with that icon 182 and display the corresponding screen of GUI 180 associated with that application. For example, if a particular icon 182 labeled with a “merchant application” text indicator 181 (ie, a particular icon 183) is selected, the device 100 launches or otherwise operates a particular merchant application It can be accessed and can display a screen of a particular user interface, which may include one or more tools or features for interacting with the device 100 in a particular manner. For each application, a screen may be displayed on display output component 112a and may include various user interface elements (e.g., screens 190a-190h of FIGS. 3A-3H). Additionally or alternatively, for each application, various other types of non-visible information may be provided to the user via various other output components 112 of device 100. The operations described for the various GUIs 180 can be implemented using a wide variety of graphical elements and visual schemes. Thus, the described embodiments are not intended to be limited to the exact user interface conventions adopted herein. Rather, embodiments can include a wide variety of user interface styles.

  Electronic device 100 may also include various other I / O components 114 that may enable communication between device 100 and other devices. The I / O component 114b may be a connection port that may be configured to send and receive data files, such as media files or customer order files, from power from remote data sources and / or external power sources. For example, I / O component 114 b may be Apple Inc. It may be a dedicated port such as a LightningTM connector or a 30 pin dock connector from of Cupertino, California. The I / O component 114c may be a connection slot for receiving a SIM card or any other type of removable component. The I / O component 114 d may be a headphone jack for connecting audio headphones that may or may not include a microphone component. The electronic device 100 can also include at least one audio input component 110g, such as a microphone, and at least one audio output component 112b, such as an audio speaker.

  The electronic device 100 may include at least one haptic or tactile output component 112c (eg, tumbler), a camera and / or scanner input component 110h (eg, video or stationary camera, and / or barcode scanner or barcode, QR code ( And any other suitable scanner capable of obtaining product identification information from codes such as, and biometrics input component 110i (eg, feature processing that may be accessible to electronic device 100 to authenticate a user) A fingerprint reader or other feature recognition sensor may also be included that may operate with the application. As shown in FIG. 3, at least a portion of biometric input component 110i may be incorporated or otherwise coupled to input component 110a of device 100 or any other suitable input component 110. For example, the biometric input component 110i may be configured to scan a fingerprint of the user's finger when the user interacts with the mechanical input component 110a by pressing the input component 110a with his finger. It may be As another example, biometric input component 110i may be a fingerprint reader that may be combined with touch input component 110f of touch screen I / O component 114a, and biometric input component 110i allows the user to touch with their finger It may be configured to scan the fingerprint of the user's finger when interacting with the touch screen input component 110f by pressing or sliding along the screen input component 110f. Furthermore, as mentioned above, the electronic device 100 can further include an NFC component 120, which can be communicatively accessible to the subsystem 200 via the antenna 116 and / or the antenna 134 (not shown in FIG. 3) . The NFC component 120 may be at least partially disposed within the housing 101, and an overall position of one or more antennas associated with the NFC component 120 (e.g., the overall position of the antenna 116 and / or the antenna 134). A mark or symbol 121 that can identify the position (a) can be provided outside the housing 101.

  One, some or all of the processes described with respect to FIGS. 1 to 10 may each be implemented by software, but may also be implemented by hardware, firmware or any combination of software, hardware and firmware . The 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, computer readable media may be non-transitory computer readable media. Examples of such non-transitory computer readable media include read only memory, random access memory, flash memory, CD-ROM, DVD, magnetic tape, removable memory cards, and data storage devices (e.g., the memory of FIG. 2). 104 and / or memory module 150), but is not limited thereto. In another embodiment, the computer readable medium may be a temporary computer readable medium. In such embodiments, the temporary computer readable medium may be distributed via a network coupled computer system, and the computer readable code is stored and executed in a distributed fashion. For example, such temporary computer readable media may be communicated from one electronic device to another (e.g., the computer readable medium may communicate component 106) using any suitable communication protocol. It may be communicated to the electronic device 100 (e.g. as at least part of application 103 and / or as at least part of application 113 and / or as at least part of application 143). Such temporary computer readable media 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 any It can include information delivery media. The modulated data signal may be a signal having one or more characteristics set or changed to encode information in the signal.

  It should be understood that any, each or at least one module or component or subsystem of the system 1 may be provided as a software construct, a firmware construct, one or more hardware components, or a combination thereof . For example, in the general context of computer-executable instructions, such as program modules, any, each, or at least one module or component or subsystem of system 1 may be executed by one or more computers or other devices. , May be described. Generally, program modules may perform one or more particular tasks, or implement one or more particular abstract data types, as one or more routines, programs, objects, components, and / or data structures. Can be included. The number, modules, components, and sub-systems of the system 1, configurations, functions, and interconnections are merely exemplary, and existing modules, components, and / or number of modules, configurations, functions, and interconnections, and / or subs The system may be modified or omitted, additional modules, components, and / or subsystems may be added, and interconnections of particular modules, components, and / or subsystems may be altered. It should be understood.

  At least a portion of one or more modules or components or subsystems of system 1 may be stored or otherwise accessible to an entity of system 1 in any suitable manner (e.g., (Eg, as at least a portion of application 103 and / or as at least a portion of application 113 and / or as at least a portion of application 143) memory 104 of device 100). For example, any or each module of NFC component 120 may be implemented using any suitable technology (e.g., one or more integrated circuit devices), and different modules may be configured, function, and operate. It may or may not be the same. Any or all of the modules or other components of system 1 may be mounted on an expansion card, may be mounted directly on a system motherboard, or may be system chipset components (e.g. "Northbridge" chips) May be integrated into the

  Any module or component of system 1 (e.g. any module or modules of NFC component 120) is a dedicated system implemented using one or more expansion cards adapted to various bus standards, It is also good. For example, all modules may be mounted on different expansion cards connected to each other, or all modules may be mounted on one expansion card. With respect to NFC component 120, merely by way of example, the module of NFC component 120 can interface with the motherboard or processor 102 of device 100 via an expansion slot (eg, peripheral component interconnect (PCI) slot or PCI express slot) . Alternatively, NFC component 120 need not be removable, but can include one or more dedicated modules, which may include memory (eg, RAM) dedicated to module usage. In other embodiments, the NFC component 120 may be integrated into the device 100. For example, the module of NFC component 120 can utilize a portion of device memory 104 of device 100. Any module or component of system 1 (eg, any module or modules of NFC component 120) may include its own processing circuitry and / or memory. Alternatively, any module or component of system 1 (e.g., any or each module of NFC component 120) may be processing circuitry and / or memory, of NFC component 120 and / or processor 102 and / or memory 104 of device 100. It can be shared with any other module.

  As mentioned above, input component 110 (eg, input component 110 f) of device 100 includes a touch input component that may receive touch input to interact with other components of device 100 via wired or wireless bus 118. be able to. Such touch input component 110 may be used to provide user input to the device 100 in place of or in combination with other input components such as a keyboard, mouse, etc.

  Touch input component 110 can include a touch sensitive panel that can be fully or partially transparent, translucent, non-transparent, opaque, or any combination thereof. The touch input component 110 may be a touch screen, a touch pad, a touch screen acting as a touch pad (eg, a touch screen replacing a laptop touch pad), a touch combined with or embedded in any other input device It may be embodied as a pad or touch pad (e.g. a touch screen or touch pad located on a keyboard) or any multi-dimensional object with a touch sensitive surface for receiving touch input. In some embodiments, the terms touch sensitive surface and touch pad may be used interchangeably.

  In some embodiments, touch input component 110 embodied as a touch screen may be partially or entirely above, below, and / or within at least a portion of a display (eg, display output component 112a). It may include transparent and / or translucent touch sensitive panels arranged. In other embodiments, the touch input component 110 may be embodied as an integrated touch screen where the touch sensitive component / device is integral with the display component / device. In yet other embodiments, the touch input component 110 may be used as an additional or additional display screen to display additional or similar graphical data of the main display and to receive touch input.

  The touch input component 110 measures capacitive, resistive, optical, acoustic, inductive, mechanical, chemical measurements, or for the occurrence of one or more touches or near touches proximate to the input component 110 It may be configured to detect the position of one or more touches or near touches based on any phenomena that may be taken. Software, hardware, firmware, or any combination thereof may be used to process measurements of the detected touch to identify and track one or more gestures. The gesture may correspond to a stationary or non-stationary, single or multiple touch or near touch on the touch input component 110. The gesture may be one or more fingers or other objects in a particular manner on the touch input component 110, such as tapping, pressing, rocking, scrubbing, rotation, twisting, changing orientation, pressing with a change in pressure, etc. It can be carried out by moving essentially simultaneously, continuously or continuously. A gesture may be characterized by the action of pinching, pulling, sliding, swiping, rotating, bending, dragging, or tapping between or with any other finger (s), to which It is not limited. A single gesture may be performed using one or more hands by one or more users, or any combination thereof.

As mentioned above, the electronic device 100 can drive a display (eg, display output component 112a) using graphical data to display a graphical user interface ("GUI") 180. The GUI 180 may be configured to receive touch input via the touch input component 110 f. Touch I / O component 110 f, embodied as a touch screen (eg, with display output component 112 a as I / O component 114 a), can display GUI 180. Alternatively, the GUI 180 may be displayed on a display (e.g., the display output component 112a) separate from the touch input component 110f. The GUI 180 can include graphical elements displayed at specific locations within the interface. Graphical elements may include various displayed virtual input devices including, but not limited to, virtual scroll wheels, virtual keyboards, virtual knobs, virtual buttons, any virtual user interface ("UI"), etc. I will not. The user may perform the gesture at one or more specific locations on touch input component 110 f associated with the graphical elements of GUI 180. In other embodiments, the user can perform the gesture at one or more locations independent of the locations of the graphical elements of GUI 180. A gesture performed on the touch input component 110 directly or indirectly manipulates and controls graphical elements in the GUI, such as cursors, icons, media files, lists, text, all or part of an image, etc. It can be modified, moved, activated, started, or generally affect them. For example, in the case of a touch screen, the user can interact directly with the graphical element by performing a gesture on the graphical element on the touch screen. Alternatively, the touch pad can generally provide indirect interaction. The gesture can also affect (eg, display a user interface) GUI elements that are not displayed, or affect other operations of the device 100 (eg, state of the GUI, application, or operating system) Or affect the mode). The gesture may or may not be performed on the touch input component 110 with the displayed cursor. For example, when a gesture is performed on the touch pad, a cursor or pointer can be displayed on the display screen or touch screen, and the cursor or pointer is controlled via touch input on the touch pad to display screen It can interact with the above graphical objects. Alternatively, if the gesture is performed directly on the touch screen, the user can interact directly with the object on the touch screen, with or without the cursor or pointer displayed on the touch screen . Feedback may be provided to the user via bus 118 in response to, or based on, a touch or near touch on touch input component 110. The feedback may be transmitted optically, mechanically, electrically, olfactoryly, acoustically, or any combination thereof, in a variable or non-variable manner.
Further Applications of the Described Concept

  Although systems, methods, and computer readable media for performing transactions using electronic devices having non-native credentials have been described, it is to be understood from the spirit and scope of the subject matter described in any manner herein. It should be understood that many changes can be made without departing. Non-essential modifications from the claimed subject matter as currently known or later devised by those skilled in the art are expressly considered to be equivalent within the scope of the claims. Therefore, obvious substitutions that will be known to those skilled in the art from now on are defined as being within the scope of the defined elements.

  Thus, one of ordinary skill in the art will understand that the present invention can be practiced by other than the described embodiments presented for purposes of illustration and not limitation.

Claims (41)

A method of performing merchant transactions and financial transactions using a host electronic device including a commercial entity subsystem, a client electronic device, and a secure element and a host credential application provisioned on said secure element, comprising:
At the host electronic device
Payment request data from the client electronic device,
Retailer subsystem identifier information identifying the merchant subsystem;
Receiving payment request data, including host credential application identifier information identifying the host credential application;
Generating first data including host payment credential data on the secure element using the host credential application identified by the received payment request data;
Generating second data on the secure element by encrypting the merchant subsystem identifier information of the first data and the received payment request data with a first key;
Sending the second data to the commercial entity subsystem;
Receiving third data including the first data encrypted with a second key associated with the merchant subsystem identifier information;
Sending the received third data to fund at least a portion of the financial transaction. The first key is not accessible to the merchant subsystem;
The method of claim 1, wherein the second key is not accessible to the host electronic device.   The method of claim 1, wherein the third data is not encrypted with the first key.   The method of claim 1, wherein the first key is accessible to the commercial entity subsystem. The generating the first data comprises generating the first data by encrypting the host payment credential data using a third key,
The method of claim 1, wherein at least a portion of the third data is encrypted with the third key.   6. The method of claim 5, wherein the third key is not accessible to the merchant subsystem.   6. The method of claim 5, wherein the third key is not accessible to the commercial entity subsystem.   The receiving according to claim 1, wherein the receiving the third data comprises receiving the third data from the commercial entity subsystem after the transmitting the generated second data. Method.   The method of claim 1, further comprising receiving the first key from the commercial entity subsystem at the host electronic device prior to the generating of the second data.   The method of claim 1, wherein the transmitting the received third data comprises transmitting the received third data to the client electronic device. The second key is not accessible to the host electronic device
11. The method of claim 10, wherein the second key is not accessible to the client electronic device. At the client electronic device
Accessing potential transaction data through the online resources of the merchant subsystem;
Identifying the merchant subsystem identifier information from the accessed potential transaction data;
11. The method of claim 10, further comprising: generating the payment request data using the identified merchant subsystem identifier information. At the client electronic device
Receiving the third data sent by the host electronic device;
13. The method of claim 12, further comprising transmitting the received third data to the merchant subsystem using the accessed online resource. At the client electronic device
Identifying at least one payment type acceptable to the merchant subsystem from the accessed potential transaction data;
13. The method of claim 12, further comprising: sending a host availability request identifying the identified at least one payment type. At the host electronic device, prior to the receipt of the payment request data,
Receiving the sent host availability request;
Determining that the host credential application meets the identified at least one payment type of the received host availability request;
Sending a host availability response including the host credential application identifier information based on the determination. At the host electronic device, prior to the receipt of the payment request data,
Receiving a host availability request from the client electronic device;
The method of claim 1, further comprising transmitting a host availability response including the host credential application identifier information to the client electronic device based on the received host availability request.   The method of claim 1, wherein the receiving the payment request data comprises the host electronic device receiving the payment request data from the client electronic device via an online communication path.   The transmission of the received third data may include transmitting the received third data from the host electronic device to the client electronic device via an online communication path. The method described in. The transmitting of the received third data includes transmitting the received third data to the client electronic device;
The method of claim 1, wherein the method further comprises the client electronic device transmitting the third data to the merchant subsystem. The settlement request data further includes a unique settlement request identifier,
The method of claim 1, wherein the transmitting the received third data comprises transmitting the received third data and the unique payment request identifier to the client electronic device. A method of performing merchant transactions and financial transactions using a client electronic device and a host electronic device, the method comprising:
At the client electronic device
Receiving potential transaction data indicative of the financial transaction from the merchant subsystem;
Sending settlement request data to the host electronic device based on the received potential transaction data;
Receiving host transaction data including host payment credential data generated by the host electronic device based on the sent payment request data;
Sending the host settlement credential data of the received host transaction data to the merchant subsystem to fund at least a portion of the financial transaction. The method further includes, at the client electronic device, generating a unique payment request identifier based on the received potential transaction data prior to transmitting the payment request data,
The settlement request data includes the unique settlement request identifier,
22. The method of claim 21, wherein the received host transaction data further comprises the unique payment request identifier. At the client electronic device
Identifying from the received potential transaction data at least one settlement type acceptable to the merchant subsystem for funding the financial transaction;
Before sending the payment request data,
22. The method of claim 21, further comprising: sending a host availability request identifying the identified at least one payment type. At the host electronic device
Receiving the sent host availability request;
Determining that a host credential application provisioned on a secure element of the host electronic device meets the identified at least one payment type of the received host availability request;
24. The method of claim 23, further comprising sending a host availability response to the client device based on the determination.   25. The method of claim 24, wherein the sent host availability response comprises host credential application identifier information identifying the host credential application. At the client electronic device
Receiving the sent host availability response;
26. The method of claim 25, further comprising: generating the payment request data to include the host credential application identifier information of the received host availability response. The received host transaction data includes the host payment credential data encrypted with a key,
The key is not accessible to the client electronic device
22. The method of claim 21, wherein at least one of the key is not accessible to the merchant subsystem and the key is not accessible to the host electronic device.   22. The method of claim 21, wherein the payment request data comprises host credential application identifier information identifying a host credential application on the host electronic device. The host electronic device includes the host credential application and another host credential application,
29. The method of claim 28, wherein the payment request data does not include any information identifying the other host credential application.   22. The method of claim 21, wherein the receiving the host transaction data comprises the client electronic device receiving the host transaction data from the host electronic device via an online communication path. A method of performing merchant transactions and financial transactions using a host electronic device including a commercial entity subsystem, a client electronic device, and a secure element and a host credential application provisioned on the secure element. ,
In the commercial entity subsystem:
Receiving from the client electronic device a host availability request identifying at least one payment type acceptable to the merchant subsystem to fund the financial transaction;
Determining that the host electronic device is associated with the client electronic device;
The host credential application provisioned to the secure element of the host electronic device is identified with the received host availability request based on the determination that the host electronic device is associated with the client electronic device. Determining that at least one payment type is satisfied,
Sending a host availability response identifying the host electronic device to the client electronic device based on the determination that the host credential application satisfies the identified at least one payment type.   32. The method of claim 31, wherein the host availability response includes host credential application identifier information identifying the host credential application provisioned on the secure element of the host electronic device.   The method of claim 31, wherein the host availability response identifies a current state of the host electronic device.   32. The method of claim 31, wherein the host availability response identifies a current location of the host electronic device.   The method of claim 31, wherein the host availability response identifies a distance between the current location of the host electronic device and the current location of the client electronic device.   The determining that the host electronic device is associated with the client electronic device determines that both the host electronic device and the client electronic device are associated with a particular user account of the commercial entity subsystem 32. The method of claim 31, comprising:   The determining that the host electronic device is associated with the client electronic device may determine that configuration of the host electronic device validates identification of the host electronic device shared with the client electronic device. 32. The method of claim 31, comprising. A client electronic device in a system including a financial institution subsystem, a retailer subsystem, and a host electronic device;
Online communication components,
A processor,
Access potential transaction data indicative of financial transactions from the merchant subsystem using the online communication component,
Communicating payment request data to the host electronic device based on the potential transaction data using the online communication component,
Receiving host payment credential data from the host electronic device based on the payment request data using the online communication component;
A processor that communicates the host payment credential data to the merchant subsystem using the online communication component, the host payment credential data to fund at least a portion of the financial transaction An electronic device that operates to access funds from the financial institution subsystem. The settlement request data includes a unique identifier in the settlement request data,
39. The device of claim 38, wherein the client electronic device receives the host payment credential data with the identifier from the host electronic device. Non-transitory computer readable storage medium storing at least one program, the at least one program comprising instructions, the instructions being executed by an electronic device comprising a user interface output component To
Have the retailer subsystem identify at least one acceptable payment type to fund potential transactions,
Sending host availability request data indicating the at least one identified payment type;
Processing host availability response data from another electronic device based on the host availability request data;
A storage medium, responsive to the processing, to provide a user selectable option operable to initiate transmission of payment request data to the other electronic device using the user interface output component. A method of performing transactions with a service provider subsystem using a client electronic device and a host electronic device, the method comprising:
At the client electronic device
Defining at least a portion of a transaction for purchasing access to a product of said service provider subsystem in communication with said service provider subsystem;
Engaging the host electronic device to generate transaction credentials for funding the transaction.

Images