Recommending payment credentials to use based on merchant information

Abstract

The invention relates to recommending payment credentials to be used based on merchant information. A system, method, and computer readable medium are provided for providing recommendations of payment credentials to be used by an electronic device in a commercial transaction based on merchant information received by the electronic device. In one exemplary embodiment, a method includes, among other things, at an electronic device including a secure element having at least one payment credential: accessing credential availability data indicative of the at least one payment credential; accessing merchant context data associated with the merchant subsystem, wherein the merchant context data indicates a preference of the first type of payment credentials with respect to the second type of payment credentials; and presenting payment recommendation data, among other things, based on the accessed credential availability data and the accessed merchant context data. Additional embodiments are also provided.

Description

[0001] This application is a divisional application of the Chinese invention patent application which has entered the Chinese national phase of the PCT application with an international application date of September 30, 2015, national application number 201580051611.1, and invention name “Recommending payment credentials to be used based on merchant information”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This patent application claims the benefit of previously filed U.S. Provisional Patent Application No. 62 / 058,098, filed September 30, 2014, which is hereby incorporated by reference herein in its entirety. Technical Field

[0004] The present disclosure relates to a method for providing a recommendation of payment credentials to be used by an electronic device in a commercial transaction based on merchant information received by the electronic device. Background Art

[0005] Portable electronic devices (e.g., cellular phones) may be provided with near-field communication ("NFC") components for enabling contactless, proximity-based communications with another entity. These communications are often associated with financial transactions or other secure data transactions that require the electronic device to access and share payment credentials or business credentials, such as credit card credentials, with another entity in a contactless, proximity-based communication. However, selecting from a variety of business credentials to use for a transaction is often inefficient. Summary of the Invention

[0006] This document describes a system, method, and computer-readable medium for providing recommendations for payment credentials to be used by an electronic device in a commercial transaction based on merchant information received by the electronic device.

[0007] As an example, a method may include, at an electronic device including a secure element having at least one payment credential: accessing credential availability data indicating at least one payment credential; accessing merchant context data associated with a merchant subsystem, wherein the merchant context data indicates a preference for a first type of payment credential over a second type of payment credential; and presenting payment recommendation data based on the accessed credential availability data and the accessed merchant context data.

[0008] As another example, an electronic device may include: a communication component configured to receive merchant context data from a merchant subsystem; a secure element configured to store credential data for at least one payment credential and generate credential availability data indicating each of the at least one payment credential; an application processor configured to generate payment recommendation data based on the merchant context data from the communication component and the credential availability data from the secure element; and an output component configured to present the payment recommendation data to a user of the electronic device, wherein the payment recommendation data includes information describing the benefits of using particular payment credentials.

[0009] As another example, a non-transitory computer-readable medium may include computer-readable instructions recorded thereon, the computer-readable instructions being used to: access, at an electronic device, credential availability data indicating at least one payment credential; access, at the electronic device, merchant context data associated with a merchant subsystem, wherein the merchant context data indicates a preference for a first type of payment credential over a second type of payment credential; and present, at the electronic device, payment recommendation data based on the accessed credential availability data and the accessed merchant context data.

[0010] The purpose of providing this summary is only to outline some exemplary embodiments in order to provide a basic understanding of some aspects of the subject matter described in this document. Therefore, it should be understood that the features described in this summary are only examples and should not be construed as narrowing the scope or essence 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 together with features described in the context of one or more other examples. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following detailed description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] Figure 1 is a schematic diagram of an exemplary system for recommending payment credentials for an electronic device;

[0013] Figure 1A yes Figure 1 Another more detailed diagram of the system;

[0014] Figure 2 yes Figure 1 and Figure 1A A more detailed schematic diagram of the system's electronics;

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

[0016] Figure 4 yes Figure 1-Figure 3 A front view of an electronic device;

[0017] Figures 4A-4C The process for recommending payment credentials is shown Figures 1-4 a front view of a screen of a graphical user interface of an electronic device; and

[0018] Figure 5-Figure 8 is a flow chart of an exemplary process for recommending payment credentials. DETAILED DESCRIPTION

[0019] Figure 1 and Figure 1A A system 1 is shown in which one or more credentials may be provided from a financial institution subsystem 350 to an electronic device 100 in conjunction with a commercial entity subsystem 400, and in which such credentials are used by the electronic device 100 to conduct financial transactions with a merchant subsystem 200, a location subsystem 170, and an associated acquiring bank subsystem 300. Figure 2-Figure 4 Further details are shown with respect to a particular embodiment of the electronic device 100 of the system 1, Figures 4A-4C Exemplary screens 190a-190c that may represent a graphical user interface of the electronic device 100 during a financial transaction are shown. Figure 5-Figure 8 is a flow chart of an exemplary process for recommending payment credentials to be used in a financial transaction.

[0020] Figure 1 Description

[0021] Figure 1 is a schematic diagram of an exemplary system 1 that can allow for recommendation of payment credentials to be used by an electronic device in a commercial transaction (e.g., NFC or online payment). Figure 1 As shown, the system 1 may include an end-user electronic device 100 for securely providing one or more credentials on the electronic device 100, a commercial entity subsystem 400, and a financial institution subsystem 350. In addition, as shown in FIG. Figure 1As shown, system 1 may further include a location subsystem 170 for providing location-based payment information to electronic device 100, and a merchant subsystem 200 for receiving contactless proximity-based communications 5 (e.g., near field communications) and / or online-based communications 670 (e.g., in-application network telecommunications) from electronic device 100 for enabling payment based on such provided credentials between a user of electronic device 100 and a merchant of merchant subsystem 200. System 1 may further include an acquiring bank subsystem 300 that may utilize such contactless proximity-based communications 5 and / or such online-based communications 670 to complete a financial transaction with financial institution subsystem 350.

[0022] System 1 may include a communication path 15 for implementing communication between device 100 and merchant subsystem 200, a communication path 25 for implementing communication between merchant subsystem 200 and acquiring bank subsystem 300, a communication path 35 for implementing communication between acquiring bank subsystem 300 and financial institution subsystem 350, a communication path 45 for implementing communication between payment network subsystem 360 of financial institution subsystem 350 and issuing bank subsystem 370 of financial institution subsystem 350, and a communication path 50 for implementing communication between financial institution subsystem 350 and commercial entity subsystem 350. 400, a communication path 65 for enabling communication between the commercial entity subsystem 400 and the electronic device 100, a communication path 75 for enabling communication between the financial institution subsystem 350 and the electronic device 100, a communication path 85 for enabling communication between the commercial entity subsystem 400 and the merchant subsystem 200, a communication path 93 for enabling communication between the merchant subsystem 200 and the location subsystem 170, and a communication path 95 for enabling communication between the location subsystem 170 and the electronic device 100. One or more of paths 15, 25, 35, 45, 55, 65, 75, 85, 93, and 95 may be managed, at least in part, by one or more trusted service managers (“TSMs”). One or more of paths 15, 25, 35, 45, 55, 65, 75, 85, 93, and 95 may be provided using any suitable circuitry, devices, systems, or combinations thereof that can be used to create a communication network (e.g., a wireless communication infrastructure including one or more communication towers, telecommunications servers, etc.), and these paths may be capable of providing communication using any suitable wired communication protocol or wireless communication protocol. For example, one or more of paths 15, 25, 35, 45, 55, 65, 75, 85, 93, and 95 may support Wi-Fi (e.g., 802.11 protocol), ZigBee (e.g., 802.15.4 protocol), WiDi TM , Ethernet, Bluetooth TM, BLE, high-frequency systems (e.g., 900MHz communication system, 2.4GHz communication system, and 5.6GHz communication system), infrared, TCP / IP, SCTP, DHCP, HTTP, BitTorrent TM , FTP, RTP, RTSP, RTCP, RAOP, RDTP, UDP, SSH, WDS bridging, any communication protocol that can be used by wireless telephones and cellular phones and personal email devices (for example, GSM, GSM plus EDGE, CDMA, OFDMA, HSPA, multi-band, etc.), any communication protocol that can be used by a low power wireless personal area network ("6LoWPAN") module, any other communication protocol, or any combination thereof.

[0023] Figure 1A Description

[0024] Now refer to Figure 1A , Figure 1A Shown above relative to Figure 1 A more detailed view of the system 1. Figure 1A As shown in , for example, electronic device 100 may include processor 102, communication component 106, and / or near field communication (“NFC”) component 120. NFC component 120 may include a secure element that may be configured to provide a tamper-resistant platform (e.g., as a single or multiple chip secure microcontrollers) that is capable of securely hosting applications and their confidential and encrypted data (e.g., credential applets and associated credential keys such as credential key 155a′ and access key 155a and / or issuer security domain (“ISD”) key 156k, as described above) in accordance with rules and security requirements that may be set forth by a set of well-recognized trusted authorities (e.g., authorities of financial institution subsystems and / or industry standards such as GlobalPlatform). Figure 1A). As described in more detail below, the credential applet of NFC component 120 can be configured to provide sufficient details for identifying a funding account or other financial instrument or credit source, wherein such credential applet can be used by electronic device 100 in one or more communications with merchant subsystem 200 to facilitate financial transactions. NFC component 120 can be configured to transmit such credential information as contactless proximity-based communication 5 (e.g., near field communication) with merchant subsystem 200 (e.g., with a merchant terminal 220 of merchant subsystem 200, wherein merchant terminal 220 can be located at a brick-and-mortar store or at any physical location where a user of electronic device 100 might use credentials stored on electronic device 100 to conduct a financial transaction with a nearby merchant terminal 220 via contactless proximity-based communication 5). Alternatively or in addition, a communication component 106 may be provided to allow the device 100 to communicate any suitable data (e.g., credential information) with one or more other electronic devices or servers or subsystems (e.g., one or more subsystems or other components of system 1) using any suitable wired or wireless protocol (e.g., via one or more of communication paths 15, 65, and / or 75). The processor 102 of the electronic device 100 may include any processing circuitry that may be used to control the operation and performance of one or more components of the electronic device 100. For example, the processor 102 may be configured to run one or more applications on the device 100 (e.g., device application 103 or online resource or merchant application 113), the one or more applications at least partially directing the manner in which online-based communications 670, including credential information of the NFC component 120, may be communicated between the communication component 106 of the device 100 and the merchant server 210 of the merchant subsystem 200 (e.g., to conduct a financial transaction with a remote merchant server of the merchant subsystem 200 over the Internet or any other suitable network that may be provided by the communication path 15).

[0025] Figure 1A The merchant server 210 of the merchant subsystem 200 may include any suitable component or subsystem configured to receive online-based communications 670 from the communication component 106 of the electronic device 100 via the communication path 15 between the device 100 and the server 210. Such online-based communications 670 may be configured to receive online-based communications 670 from the secure element of the NFC component 120 of the device 100 via any suitable communication protocol supported by the communication component 106 of the device 100 (e.g., Wi-Fi, Bluetooth, etc.). TM, cellular, wired network protocols, etc.) to transmit merchant credential data (e.g., credit card credential information from an enabled applet of a credential supplemental security domain (“SSD”), as described in more detail below) to the server 210. The communication may be performed within any suitable online context, such as when a user of the device 100 is communicating with the merchant server 210 via a third-party application 113 running on the device 100 that may be managed by the merchant server 210, or via an internet application or web browser (e.g., Safari from Apple Inc.) running on the device 100 that may point to a uniform resource locator (“URL”) whose destination or web resource may be managed by the merchant server 210. TM ) provides online-based communication 670 when conducting financial transactions. Therefore, it should be noted that online-based communication 670 between the merchant server 210 and the electronic device 100 can occur wirelessly and / or via a wired path (e.g., over the Internet). The merchant server 210 can be provided by the merchant of the merchant subsystem 200 (e.g., as a web server to host website data and / or manage third-party application data). Although not shown, the merchant subsystem 200 may also include a merchant processor component that can be the same as or similar to the processor component 102 of the electronic device 100, a merchant communication component that can be the same as or similar to the communication component 106 of the electronic device 100, a merchant I / O interface that can be the same as or similar to the I / O interface 114 of the electronic device 100, a merchant bus that can be the same as or similar to the bus 118 of the electronic device 100, a merchant memory component that can be the same as or similar to the memory component 104 of the electronic device 100, and / or a merchant power component that can be the same as or similar to the power component 108 of the electronic device 100.

[0026] The financial institution subsystem 350 may include a payment network subsystem 360 (e.g., 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 assumes primary responsibility for a consumer's ability to use a specific credential to pay off any debts they may incur. Each specific credential applet of the NFC component 120 may be associated with a specific payment card, which may be electronically linked to one or more accounts of a specific user. Various types of payment cards are suitable, including credit cards, debit cards, charge cards, stored-value cards, gas cards, gift cards, and the like. The issuing bank subsystem 370 may provide a commercial credential for a specific payment card on the electronic device 100 (e.g., as a credential in the credential supplemental security domain of the NFC component 120, as described below) for use in commercial credential data communications (e.g., contactless proximity-based communication 5 and / or online-based communication 670) with the merchant subsystem 200. Each credential may be a payment card of a specific brand, which may be branded by the payment network subsystem 360. The payment network subsystem 360 may be a network of various issuing banks 370 and / or various acquiring banks that may process the use of a particular brand of payment card (eg, merchant credentials).

[0027] In order to conduct a financial transaction within system 1, at least one business credential must be securely provisioned on the secure element of NFC component 120 of electronic device 100. For example, such business credential may be at least partially provisioned on the secure element of NFC component 120 of electronic device 100 directly from financial institution subsystem 350 (e.g., as credential data 654 via communication path 75 between financial institution subsystem 350 and device 100, which credential data may be communicated to NFC component 120 via communication component 106). Additionally or alternatively, such commercial credentials may be provided at least in part on a secure element of NFC component 120 of electronic device 100 from financial institution subsystem 350 via commercial entity subsystem 400 (e.g., as credential data 654 via communication path 55 between financial institution subsystem 350 and commercial entity subsystem 400, which credential data may be communicated to device 100 via communication path 65 between server 410 of commercial entity subsystem 400 and communication component 106 of device 100 as credential data 654, which may then be communicated from communication component 106 to NFC component 120). Credential data 654 via path 75 and / or via path 65 may be provided on a secure element of device 100 as at least a portion or all of a credential supplemental security domain of NFC component 120, which may include a credential applet and / or credential keys such as credential key 155a'. Figure 1AAs shown in , for example, financial institution subsystem 350 may also have access to credential key 155a' (e.g., for decrypting data encrypted by device 100 using credential key 155a'). Financial institution subsystem 350 may be responsible for managing credential key 155a', which may include the generation, exchange, storage, use, and replacement of such key. Financial institution subsystem 350 may store its version of credential key 155a' in a secure element of financial institution subsystem 350.

[0028] A commercial entity subsystem 400 may be provided as an intermediary between the electronic device 100 and the financial institution subsystem 350, wherein the commercial entity subsystem 400 may be configured to provide a new layer of security and / or a more seamless user experience when credentials are provided on a secure element of the device 100 and / or when the provided credentials are used as part of a commercial credential data communication between the device 100 and the merchant subsystem 200 (e.g., as part of an online-based communication 670). The commercial entity subsystem 400 may be provided to a user-specific account with the commercial entity by a particular commercial entity that may provide various services to the user of the device 100 via user-specific login information (e.g., via a user-specific identification and password combination). As just one example, the commercial entity subsystem 400 may be provided to the user of the device 100 by Apple Inc. (Cupertino, CA), which may also be a provider of various services (e.g., iTunes for selling / renting media to be played by the device 100). TM Store, Apple AppStore for selling / renting applications for use on device 100 TM , Apple iCloud for storing data from device 100 TM services, Apple online stores for online purchase of various Apple products, etc.), it can also be the device 100 itself (for example, when the device 100 is an iPod TM , iPad TM , iPhone TM100 ). The commercial entity that may provide the commercial entity subsystem 400 (e.g., Apple Inc.) may be distinct from and independent of any financial entity of the financial institution subsystem 350. For example, the commercial entity that may provide the commercial entity subsystem 400 may be distinct from and independent of any payment network subsystem 360 or issuing bank subsystem 370 that may provide and manage any credit card or other commercial credentials to be provided on the user device 100. Additionally or alternatively, the commercial entity that may provide the commercial entity subsystem 400 (e.g., Apple Inc.) may be distinct from and independent of any merchant of the merchant subsystem 200. For example, the commercial entity that may provide the commercial entity subsystem 400 may be distinct from and independent of any merchant of the merchant subsystem 200 that may provide a merchant terminal for NFC communication, a third-party application 113, and / or any other aspect of the merchant subsystem 200. Such a business entity may utilize its potential ability to configure or control various components of device 100 (e.g., software components and / or hardware components of device 100 when the business entity at least partially generates or manages device 100) to provide a more seamless user experience for the user of device 100 when it desires to provision credentials provided by financial institution subsystem 350 on user device 100 and / or when using such provided credentials as part of a commercial credential data communication with merchant subsystem 200 (e.g., as part of communication 5 or communication 670). For example, in some embodiments, device 100 may be configured to communicate seamlessly and transparently to the user of device 100 with commercial entity subsystem 400 (e.g., via communication path 65) for sharing or receiving specific data that may enable a higher level of security (e.g., during online-based commercial credential data communication between device 100 and merchant subsystem 200). Although not shown, the merchant entity subsystem 400 may also include a processor component that may be the same as or similar to the processor component 102 of the electronic device 100, a communication component that may be the same as or similar to the communication component 106 of the electronic device 100, an I / O interface that may be the same as or similar to the I / O interface 114 of the electronic device 100, a bus that may be the same as or similar to the bus 118 of the electronic device 100, a memory component that may be the same as or similar to the memory component 104 of the electronic device 100, and / or a power supply component that may be the same as or similar to the power supply component 108 of the electronic device 100, such as one, some, or all of the above components that may be at least partially provided by the server 410.

[0029] In addition to providing at least one commercial credential on the secure element of the NFC component 120 of the electronic device 100 (e.g., as part of a credential SSD having a credential key 155a'), at least one access SSD having an access key 155b may also be provided on the secure element of the NFC component 120 of the device 100 to more securely enable the device 100 to conduct financial transactions with the merchant subsystem 200. For example, the access SSD may be at least partially provided on the secure element of the NFC component 120 of the electronic device 100 directly from the commercial entity subsystem 400 (e.g., as access data 652 via a communication path 65 between a server 410 of the commercial entity subsystem 400 and the communication component 106 of the device 100, which may then be passed from the communication component 106 to the NFC component 120). The access data 652 via the path 65 may be provided on the secure element of the device 100 as at least a portion or all of the access SSD, and the access data 652 may include an access applet and / or the access key 155b. Figure 1A As shown in , commercial entity subsystem 400 may also have access to access key 155b (e.g., for decrypting data encrypted by device 100 using access key 155b). Commercial entity subsystem 400 may be responsible for managing access key 155b, which may include the generation, exchange, storage, use, and replacement of such key. Commercial entity subsystem 400 may store its version of access key 155b in the secure element of commercial entity subsystem 400. The access SSD of NFC component 120 with access key 155b may be configured to determine the intent and local authentication of the user of device 100 (e.g., via one or more input components 110 of device 100, such as a biometric input component), and in response to such determination, it may be configured to enable another specific SSD to conduct a payment transaction (e.g., using the credentials of the credential SSD of NFC component 120). Storing such an access SSD within the secure element of device 100 may improve its ability to reliably determine user intent and authentication for financial transactions. Furthermore, as described in greater detail below, such SSD-accessing access key 155b of NFC component 120 may be utilized to provide enhanced encryption for financial transaction data that may be transmitted outside of the secure element of device 100. Additionally or alternatively, as described below, access data 652 may include an issuer security domain (“ISD”) key 156k for the ISD of the secure element of electronic device 100, which may also be maintained by commercial entity subsystem 400 and may be used in addition to or in lieu of access key 155b as described below.

[0030] As described above, in addition to at least one credential SSD and at least one access SSD provided on the secure element of electronic device 100, device 100 may access at least one third-party application (e.g., application 113) to enable commercial credential data communication (e.g., communication 5 or online-based communication 670) between device 100 and merchant subsystem 200. First, before device 100 can access application 113, such application 113 may be approved or otherwise enabled by commercial entity subsystem 400. For example, application store 420 (e.g., Apple AppStore) of commercial entity subsystem 400 may be used to store and access commercial credential data. TM) may receive at least some dates representing application 113 from merchant subsystem 200 via communication path 85. Furthermore, in some embodiments, commercial entity subsystem 400 may generate or otherwise assign a merchant key 157 for application 113 and provide such merchant key 157 to merchant subsystem 200 (e.g., via path 85). Alternatively, merchant subsystem 200 may generate or otherwise assign a merchant key 157 for application 113 and provide such merchant key 157 to commercial entity subsystem 400 (e.g., via path 85). Merchant subsystem 200 or commercial entity subsystem 400 may be responsible for managing merchant keys 157, which may include the generation, exchange, storage, use, and replacement of such keys. Regardless of how or where such merchant keys 157 are generated and managed, merchant subsystem 200 and commercial entity subsystem 400 may store a version of merchant key 157 (e.g., in respective secure elements of merchant subsystem 200 and commercial entity subsystem 400). In some embodiments, such merchant keys 157 may be associated specifically with merchant applications 113, while in other embodiments, merchant keys 157 may be associated specifically with a merchant of merchant subsystem 200, such that a merchant key 157 may be associated with multiple third-party applications operated by the same merchant of merchant subsystem 200. A table 430 or any other suitable data structure or information source accessible to commercial entity subsystem 400 may be provided for associating a particular merchant key 157 with a particular merchant application 113 or merchant entity. Table 430 may enable commercial entity subsystem 400 to determine and utilize an appropriate merchant key 157 for providing a security layer for commercial credential data communications (e.g., online-based communications 670) between device 100 and merchant subsystem 200 (e.g., when a user of device 100 is communicating with merchant server 210 to conduct a financial transaction via a third-party application 113 associated with that merchant key 157), as described in more detail below. Device 100 can be configured to access application 113 (e.g., from application store 420 via communication path 65) and run application 113 (e.g., using processor 102). Alternatively or in addition, merchant key 157 can be associated with a merchant's website (e.g., one or more URLs) rather than or in addition to the merchant's third-party application (e.g., application 113).For example, a merchant of merchant subsystem 200 may cooperate with commercial entity subsystem 400 to associate a particular merchant website with a particular merchant key 157 in table 430, which may enable commercial entity subsystem 400 to determine and utilize the appropriate merchant key 157 to provide a layer of security for commercial credential data communications (e.g., online-based communications 670) between device 100 and merchant subsystem 200 (e.g., when a user of device 100 is communicating with merchant server 210 to conduct a financial transaction via an internet application or web browser running on device 100, which internet application or web browser may be directed to a URL whose destination or network resource may be associated with merchant key 157). Device 100 may be configured to access such a URL from merchant server 210 via communication path 15, for example, using an internet application on device 100.

[0031] Figure 2 Description

[0032] Now refer to Figure 2 , Figure 2 Shown above relative to Figure 1 and Figure 1A A more detailed view of the electronic device 100 of the system 1 is shown. Figure 2 As shown, for example, the electronic device 100 may include a processor 102, a memory 104, a communication component 106, a power source 108, an input component 110, an output component 112, an antenna 116, and a near field communication ("NFC") component 120. The electronic device 100 may also include a bus 118 that may provide one or more wired or wireless communication links or pathways for transmitting data and / or power to, from, or between various other components of the device 100. The electronic device 100 may also be provided with a housing 101 that may at least partially enclose one or more of the components of the device 100 to protect them from debris and other degrading forces external to the device 100. In some embodiments, one or more components of the electronic device 100 may be combined or omitted. In addition, the electronic device 100 may include components that are not combined or included in Figure 2 For example, the electronic device 100 may include any other suitable components or Figure 2 For simplicity, Figure 2Only one component of each type is shown. One or more input components 110 may be provided to allow a user to interact or interface with the device 100, and / or one or more output components 112 may be provided to present information (e.g., graphical information, audio information, and / or tactile information) to a user of the device 100. It should be noted that one or more input components and one or more output components may sometimes be collectively referred to herein as input / output ("I / O") components or I / O interfaces 114 (e.g., input components 110 and output components 112 are referred to as I / O components or I / O interfaces 114). For example, the input components 110 and the output components 112 may sometimes be a single I / O component 114 such as a touch screen, which may receive input information by a user touching a display screen and may also provide visual information to the user via the same display screen. The processor 102 of the electronic device 100 may include any processing circuitry that can be used to control the operation and performance of one or more components of the electronic device 100. For example, the processor 102 may receive input signals from the input component 110 and / or drive output signals through the output component 112. As Figure 2 As shown, processor 102 may be operable to run one or more applications such as application 103 and / or application 113. As an example, application 103 may be an operating system application, while application 113 may be a third-party application (e.g., an application associated with a merchant of merchant subsystem 200).

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

[0034] like Figure 2As shown, for example, the NFC memory module 150 may include one or more of an issuer security domain (“ISD”) 152 and a supplemental security domain (“SSD”) 154 (e.g., a service provider security domain (“SPSD”), a trusted service manager security domain (“TSMSD”), etc.), which may be defined and managed by an NFC specification standard (e.g., GlobalPlatform). For example, the ISD 152 may be part of the NFC memory module 150, where a trusted service manager (“TSM”) or an issuing financial institution (e.g., financial institution subsystem 350) may store keys and / or other suitable information for creating or otherwise providing one or more credentials (e.g., credentials associated with various credit cards, bank cards, gift cards, purchase cards, transportation cards, etc.) on the electronic device 100 (e.g., via the communication component 106) for credential content management and / or security domain management. The credentials may include credential data, such as a credit card payment number, that may be assigned to a user / consumer and 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, the first SSD 154a (e.g., credential SSD 154a) may be associated with a specific credential (e.g., a specific credit card credential or a specific public transportation card credential provided by the financial institution subsystem 350 that can provide specific privileges or payment permissions to the electronic device 100), while the second SSD 154b (e.g., access SSD 154b) may be associated with a business entity (e.g., a business entity of the business entity subsystem 400 that can control the entity of the device 100), which can control the device 100's access to the specific credential on the other SSD (e.g., first SSD 154a), for example, to provide the electronic device 100 with specific privileges or payment permissions. Alternatively, each of the first SSD 154a and the second SSD 154b may be associated with a corresponding specific credential that can provide specific privileges or payment permissions to the electronic device 100 (e.g., specific credit card credentials or specific public transportation card credentials provided by the financial institution subsystem 350). Each SSD 154 may include and / or be associated with at least one applet 153 (e.g., SSD 154a having applet 153a and SSD 154b having applet 153b). For example, the applet 153 of the SSD 154 may be an application that can be run on the secure element of the NFC component 120 (e.g., in the GlobalPlatform environment). Each applet 153 may also include and / or be associated with at least one key 155 of its own (e.g., applet 153a having at least one key 155a and applet 153b having at least one key 155b).

[0035] The key 155 of the SSD 154 can be a piece of information output by a function that can determine an encryption algorithm or password. For example, when encrypting, the key can specify a specific conversion of plaintext to ciphertext during encryption, or vice versa. Keys such as digital signature schemes and message authentication codes can also be used in other encryption algorithms. Each key and applet can be loaded on the secure element of the device 100 by the TSM or an authorized agent, or preloaded on the secure element when it is first provided on the device 100. As an example, although the credential SSD 154a can be associated with a specific credit card credential, when the applet 153a of the credential SSD 154a has been enabled or otherwise activated or unlocked for such use, only the specific credential can be transmitted from the secure element of the device 100 (e.g., from the NFC component 120) to the merchant subsystem 200 as a commercial credential data communication (e.g., as a contactless proximity-based communication 5 to the merchant terminal 220 and / or as an online-based communication 670 to the merchant server 210).

[0036] Security features can be provided to enable the use of the NFC component 120, which may be particularly useful when transmitting confidential payment information, such as credit card information or bank account information for credentials, from the electronic device 100 to the merchant subsystem 200. Such security features may also include a secure storage area that may have restricted access rights. For example, user authentication via personal identification number ("PIN") input or user interaction with a biometric sensor may be required to access the secure storage area. For example, accessing the SSD 154b may utilize the applet 153b to determine whether such authentication has occurred before allowing the use of other SSDs 154 (e.g., credential SSD 154a) to transmit its credential information. In certain embodiments, some or all of the security features may be stored within the NFC memory module 150. In addition, security information, such as authentication keys, may be stored within the NFC memory module 150 for use in transmitting commercial credential data to and from the merchant subsystem 200. In certain embodiments, the NFC memory module 150 may include a microcontroller embedded within the electronic device 100. As just one example, an applet 153b accessing SSD 154b may be configured to determine intent and local authentication of a user of device 100 (e.g., via one or more input components 110 such as a biometric input component), and in response to such determination, it may be configured to enable another particular SSD to conduct a payment transaction (e.g., utilizing the credentials of credential SSD 154a).

[0037] Figure 3 Description

[0038] Now refer to Figure 3 , Figure 3 Shown above relative to Figure 1-Figure 2Another detailed view of a portion of the electronic device 100 of the depicted system 1. Figure 3 As shown in , for example, the secure element 145 of the NFC component 120 may include SSD 154a and SSD 154b, the SSD 154a may include or be associated with applet 153a, the applet 153a may include access key 155a and / or credential key 155a', and the SSD 154b may include or be associated with applet 153b, the applet 153b may include access key 155b and / or credential key 155b'. In some embodiments, a specific supplemental security domain ("SSD") 154 (e.g., one of SSDs 154a and 154b) may be associated with a specific TSM and at least one specific commercial credential (e.g., a specific credit card credential or a specific public transportation card credential) that may provide specific privileges or payment permissions to the electronic device 100. Each SSD 154 may have its own manager key 155 (eg, a corresponding one of keys 155ak and 155bk ) that may need to be activated to enable functionality of that SSD 154 for use by the NFC device module 130 . Additionally or alternatively, each SSD 154 may include and / or be associated with at least one of its own credential application or a credential applet (e.g., a Java Card applet example) associated with a particular business credential (e.g., credential applet 153a of SSD 154a may be associated with a first business credential, and credential applet 153b of SSD 154b may be associated with a second business credential), wherein the credential applet may have its own access key (e.g., access key 155a for credential applet 153a and access key 155b for credential applet 153b) and / or its own credential key (e.g., credential key 155a' for credential applet 153a and credential key 155b' for credential applet 153b), and wherein the credential applet may need to be activated to enable its own associated business credential for use by the NFC device module 130 for NFC communication 5 and / or online-based communication 670 between the electronic device 100 and the merchant subsystem 200. In some embodiments, the credential keys for the credential applet (e.g., credential key 155a' for credential applet 153a and / or credential key 155b' for credential applet 153b) may be generated by and used by a financial institution subsystem 350 that may be responsible for such credentials (e.g., Figure 1A) to enable secure transmission of the credential applet between secure element 145 and financial institution subsystem 350. Additionally or alternatively, access keys for the credential applet (e.g., access key 155a for credential applet 153a and / or access key 155b for credential applet 153b) may be generated by commercial entity subsystem 400 and may be used by commercial entity subsystem 400 (e.g., as Figure 1A as shown) to enable secure transmission of the credential applet between the security element 145 and the business entity subsystem 400.

[0039] Additionally or alternatively, Figure 3 As shown, the secure element 145 may include an ISD 152, which may include a trusted service manager (e.g., a business entity subsystem 400, such as Figure 1A ISD key 156k may be used by commercial entity subsystem 400 and electronic device 100 similarly to and / or in place of access key 155a and / or access key 155b to enable secure transmission between commercial entity subsystem 400 and secure element 145 of electronic device 100. Figure 3 , and as described in more detail below, various data can be communicated between the processor 102 and the secure element 145. For example, the processor 102 of the device 100 can be configured to run a device application 103, which can communicate information with the merchant application 113 of the processor 102 as well as the secure element 145, the I / O component 114 a (e.g., for receiving I / O input data 115 i and / or for transmitting I / O output data 115 o), and / or the communication component 106.

[0040] Additionally or alternatively, Figure 3As shown, security element 145 may include control authority security domain ("CASD") 158, which may be a dedicated security domain that may be configured to act as a root of trust on a third-party element. The associated application of CASD 158 may be configured to provide confidentiality key generation on the element as a global service to other applications and / or specific management layers (e.g., GlobalPlatform management layers). The confidentiality key material that can be used within CASD 158 may be configured to make it impossible to detect or modify any entity including the issuer of security element 145. CASD 158 may be configured to include and / or may be configured to generate and / or otherwise include a CASD access toolkit 158k (e.g., CASD private key ("CASD-SK"), CASD public key ("CASD-PK"), CASD certificate ("CASD-Cert") and / or CASD-signature module). For example, CASD 158 may be configured to (e.g., using CASD access suite 158k) tag specific data on secure element 145 before providing such data to another portion of device 100 (e.g., communication component 106 for sharing with other subsystems of system 1). For example, CASD 158 may be configured to tag any data provided by secure element 145 so that other subsystems (e.g., business entity subsystem 400) may be able to confirm that such tagged data was tagged by secure element 145 (e.g., using associated CASD suite 158k at business entity subsystem 400).

[0041] Additionally or alternatively, Figure 3 As shown, the secure element 145 may include a contactless registration service ("CRS") applet or application 151 that may be configured to provide local functionality to the electronic device 100 for modifying the lifecycle state of a particular security domain element (e.g., activated, deactivated, locked, etc.) and sharing specific output information 115o about the particular security domain element in the particular lifecycle state with a user of the device 100 (e.g., via the user I / O interface 114a). Additionally or alternatively, the CRS 151 may include a trusted service manager (e.g., a business entity subsystem 400, such as a business entity subsystem 400) that may also be associated with the CRS 151. Figure 1A CRS access key 151k may be utilized by commercial entity subsystem 400 and electronic device 100 similarly to and / or in place of access key 155a and / or access key 155b to enable secure transmission between commercial entity subsystem 400 and secure element 145 of electronic device 100.

[0042] Figure 4 Description

[0043] like Figure 4 As shown, and as described in detail below, a specific example of electronic device 100 may be a handheld electronic device such as an iPhone TM , wherein the housing 101 may allow access to various input components 110a-110i, various output components 112a-112c, and various I / O components 114a-114d, through which the device 100 and the user and / or the surrounding environment may interact with each other. For example, the touch screen I / O component 114a may include a display output component 112a and an associated touch input component 110f, wherein the display output component 112a may be used to display a visual user interface or graphical user interface ("GUI") 180 that allows 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 running application (e.g., application 103 and / or application 113 and / or application 143), which may be displayed in all or some areas of the display output component 112a. For example, as Figure 4 As shown, GUI 180 can 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 can be configured to open a new application associated with that icon 182 and display a corresponding screen associated with that application of GUI 180. For example, when a particular icon 182 (i.e., particular icon 183) labeled with a "Merchant Application" text indicator 181 is selected, device 100 can launch or otherwise access a particular third-party merchant application (e.g., application 113) and can display a screen of a particular user interface that can include one or more tools or features for interacting with device 100 in a particular manner. As another example, when a specific icon 182 (i.e., specific icon 185) labeled with a "pass" text indicator 181 has been selected, device 100 may launch or otherwise access a specific device application (e.g., a "wallet" or "pass" application 103 that manages various credentials on secure element 145) and may display a screen of a specific user interface that may include one or more tools or features for interacting with device 100 in a specific manner. For example, Figures 4A-4CSpecific examples of such displays of GUI 180 may be shown during use of a merchant application (e.g., application 113) and / or a pass application (e.g., application 103) that can be used by a user of device 100 to make payments using credentials of NFC component 120 (e.g., credentials of credential SSD 154a) via communication 5 and / or communication 670. For 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-visual information may be provided to the user via various other output components 112 of device 100.

[0044] Figures 4A-4C 、 Figure 5 and Figure 6 Description

[0045] To facilitate the following discussion of the operation of the system 1 for recommending payment credentials, refer to Figure 5 and Figure 6 One or more processes of one or more flowcharts, Figures 1-4 1 and a schematic diagram of the various components of the system 1, and a front view of screens 190-190c that may be used to represent the various components of the system 1 during such a payment (e.g., Figure 4-4C A graphical user interface of the electronic device 100 during the operation (shown). A variety of graphical elements and visual schemes can be used to implement the operations. Figure 4-4C The embodiments of the present invention are not intended to limit the exact user interface conventions adopted herein. Instead, these embodiments may include various user interface styles.

[0046] Figure 5is a flow diagram of an exemplary process 500 for recommending payment credentials. Process 500 is shown as being implemented by electronic device 100, location subsystem 170, merchant subsystem 200, acquiring 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 making payments using merchant subsystem 200 on device 100. Process 500 may begin at step 502, where merchant subsystem 200 may share merchant context data with electronic device 100 (e.g., directly or via location subsystem 170). For example, such merchant context data may include any suitable data for identifying one or more specific characteristics of a purchase transaction to be funded. For example, merchant context data transmitted from merchant subsystem 200 directly to device 100 (e.g., via path 15 or via a bidirectional path along which data 5 may also be transmitted) and / or via location subsystem 170 (e.g., via paths 93 and 95) may include a merchant identifier that identifies the particular merchant from which the data was transmitted, a transaction identifier that identifies the particular purchase transaction to be funded, one or more pieces of information specific to such transaction (e.g., the purchase price, a description of the product / service purchased, shipping information, etc.), identification of the currency to be used during such transaction, an identifier that is acceptable or preferred by merchant subsystem 200, or other identifiers that are not acceptable to merchant subsystem 200. a list of financial institutions whose payment credentials are currently recommended in a manner that is at least partially known whether a particular transaction is to be funded between the electronic device 100 and the merchant subsystem 200, and / or one or more fields of customizable information that can be uniquely customized by the merchant subsystem 200 for a particular transaction and / or for a particular time period and / or for a particular type of user electronic device or user / buyer (e.g., information describing why one payment credential may be recommended or preferred over another, additional information that the buyer may request, such as a request to select one of several options as a gift from the merchant to the buyer, etc.). In some embodiments, at least a portion of such data may be transmitted by the location subsystem 170 for receipt by any device 100 that is within a particular distance (e.g., 15 feet) of the location subsystem 170, such that any device 100 that is currently engaged in a financial transaction with the merchant subsystem 200 or that is located in an area that may be suitable for facilitating a potential future financial transaction with the merchant subsystem 200 due to its current location being proximate to the merchant subsystem 200 may receive specific contextual data that may at least partially configure recommendations for the device 100 (e.g., one or more recommendations to use a particular payment credential available to the device 100 relative to another device for any suitable financial transaction with the merchant subsystem 200). In some embodiments, the location subsystem 170 may utilize geofencing or iBeacon TM(e.g., as provided by Apple Inc.) or any other suitable geo- or proximity-based or location-based technology for providing merchant context information to any suitable device 100 having any suitable relationship with the merchant subsystem 200 and / or location subsystem 170. The electronic device 100 may include one or more sensors (e.g., as any suitable input component 110, communication component 106, application 103 / 113, and / or otherwise) that can be used to enable the device 100 to become a location-aware device (e.g., a location-based service that cooperates with the location subsystem 170 or one or more other remote subsystems that can be used to implement a location-based service or any other suitable context-based service). The device 100 can be used to utilize a global positioning system service and / or use any other suitable mechanism to determine its current location, and then use that location to detect any suitable merchant context data that may be associated with that location. Such merchant context data may be included in the information provided to device 100 when device 100 receives local Wi-Fi scan results (e.g., a merchant's Wi-Fi routers may be used to include not only the name of its router and other appropriate information that enables device 100 to join a particular Wi-Fi network, but also any appropriate merchant context data of step 502, regardless of whether device 100 actually joins that network).

[0047] Next, at step 504, process 500 may include device 100 presenting payment recommendation data to the user of device 100 based at least in part on any merchant context data received at step 502. Such recommendation data may be based on at least a portion of the received merchant context data to supplement and / or override any previously defined or default payment preference data of device 100 (e.g., as may have been previously established by the user of device 100 or an application). Then, at step 506, process 500 may include device 100 receiving payment selection data (e.g., from the user of device 100), wherein such payment selection data may be based at least in part on the payment recommendation data provided at step 504. Such payment selection data may identify and, in some embodiments, authenticate specific payment credentials residing on electronic device 100 (e.g., located on secure element 145) for use in funding transactions with merchant subsystem 200.

[0048] Next, at step 508, process 500 may include electronic device 100 transmitting payment card data associated with the identified payment credential of step 506 to merchant subsystem 200. For example, such payment card data may be encrypted by device 100 in any suitable manner and transmitted from NFC component 120 to merchant terminal 220 (e.g., as communication 5) and / or from communication component 106 of electronic device 100 to server 210 of merchant subsystem 200 via communication path 15 (e.g., as communication 670), or transmitted via commercial entity subsystem 400 to merchant subsystem 200 (e.g., as communication 671, as described below). After merchant subsystem 200 receives the payment card data transmitted from electronic device 100 at step 508, process 500 may include merchant subsystem 200 utilizing the payment card data to conduct a financial transaction with acquiring bank 300 and / or financial institution subsystem 350 at step 510. For example, the merchant subsystem 200 may forward the payment card data to the acquiring bank 300 and / or the financial institution subsystem 350 (e.g., via communication path 25 and / or communication path 35) so that the funding account associated with the payment card data can be identified and used by the acquiring bank 300 and / or the financial institution subsystem 350 to fund the financial transaction. Next, after executing such a transaction at step 510, the process 500 may include the merchant subsystem 200 confirming the execution to the electronic device 100 at step 512. For example, the merchant subsystem 200 may transmit any suitable confirmation information to the electronic device 100 via communication path 15.

[0049] Thus, process 500 may utilize the merchant context data of step 502 to suggest or otherwise manipulate the manner in which device 100 may present payment recommendation data and / or enable selection of particular payment credentials for device 100 for funding a transaction with merchant subsystem 200. Such merchant context data may be generated by merchant subsystem 200 and provided directly to device 100 or provided via any other suitable communication arrangement, such as via location subsystem 170, which may share at least a portion of such merchant context data for device 100 based on a location or distance of device 100 relative to at least a portion of merchant subsystem 200.

[0050] It should be understood that Figure 5 The steps shown in process 500 are merely exemplary, and existing steps may be modified or omitted, additional steps may be added, and the order of certain steps may be changed.

[0051] Figure 66 is a flow chart of an exemplary process 600 for making a payment. Process 600 is shown as being implemented by electronic device 100, location subsystem 170, merchant subsystem 200, acquiring 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 may provide a seamless user experience for making payments using merchant subsystem 200 on device 100. Process 600 may begin at step 602, where access data 652 (e.g., Figure 1A 652). For example, at least one access SSD (e.g., SSD 154b) may be provided on a secure element of device 100 (e.g., NFC component 120) as access data 652 from server 410 of commercial entity subsystem 400 to more securely enable device 100 to conduct financial transactions with merchant subsystem 200. As described above, access SSD 154b may be provided, at least in part, on the secure element of NFC component 120 of electronic device 100 directly from commercial entity subsystem 400 (e.g., as access data 652 via communication path 65 between server 410 of commercial entity subsystem 400 and communication component 106 of device 100, which may then be passed from communication component 106 (e.g., via bus 118) to NFC component 120). Access data 652 via path 65 may be provided on the secure element of device 100 as access to at least a portion or all of SSD 154b, and may include access to applet 153b and / or access key 155b. Step 602 may be performed, at least in part, during initial configuration of device 100 (e.g., by commercial entity subsystem 400 before device 100 is sold to a user). Alternatively, step 602 may be performed, at least in part, in response to initial setup of NFC component 120 by a user of device 100. Additionally or alternatively, access data 652 may include ISD key 156k for ISD 152 of the secure element of electronic device 100, which may be used in addition to or in lieu of access key 155b for secure transmissions between commercial entity subsystem 400 and electronic device 100. In addition to or alternatively, the access data 652 may include CRS151k of CRS151 of the security element 145 of the electronic device 100 and / or CASD 158k of CASD 158, and the access data 652 may be used in addition to or as an alternative to the access key 155b and / or access key 155a and / or ISD key 156k for enabling secure transmission between the business entity subsystem 400 and the electronic device 100.

[0052] At step 604, process 600 may include, in some embodiments, provisioning credential data 654 (e.g., Figure 1A For example, such credential data 654 may be provided at least in part directly from the financial institution subsystem 350 on the secure element of the NFC component 120 of the electronic device 100 (e.g., via a secure communication between the financial institution subsystem 350 and the device 100). Figure 1A 75, which may be communicated to NFC component 120 via communication component 106). Additionally or alternatively, such credential data 654 may be provided, at least in part, on the secure element of NFC component 120 of electronic device 100 from financial institution subsystem 350 via commercial entity subsystem 400 (e.g., via a secure communication path between financial institution subsystem 350 and commercial entity subsystem 400). Figure 1A The communication path 55 can be between the server 410 of the business entity subsystem 400 and the communication component 106 of the device 100 Figure 1A 150. In some embodiments, the credential data 654 may be passed to the device 100 via communication path 65 as credential data 654, which may then be passed from the communication component 106 (e.g., via bus 118) to the NFC component 120. The credential data 654 may be provided on the secure element of the device 100 as at least a portion or all of the credential SSD 154a via path 75 and / or via path 65, and may include the credential applet 153a and / or the credential key 155a'. Step 604 may be performed at least in part when a user of the device 100 selects to provide particular credentials on the device 100. In some embodiments, the credential data 654 may also include the access key 155a, which may be initially provided from the commercial entity subsystem 400 to the financial institution subsystem 350 and / or may be added by the commercial entity subsystem 400.

[0053] The credential data provided on device 100 may include all data necessary to make a payment using the credential, such as, for example, a primary account number (“PAN”), a card security code (e.g., a card verification code (“CVV”)), an expiration date, a name associated with the credential, and the like. “Virtual” credentials or virtual PAN or device PAN (“D-PAN”) may be configured on device 100 instead of the user’s “actual” credentials or actual PAN or fund PAN (“F-PAN”). For example, once a determination is made that credentials are to be provided on device 100, a request may be made (e.g., by financial institution subsystem 350, by commercial entity subsystem 400, and / or by a user of device 100) for virtual credentials to be generated, linked to actual credentials, and provided on device 100 without providing the actual credentials. Such generation of virtual credentials and linking to actual credentials may be performed by any suitable component of financial institution subsystem 350. For example, a payment network subsystem 360 (e.g., a particular payment network subsystem 360 that may be associated with a brand of actual credentials) may define and store a virtual link table 312 (e.g., such as a table of virtual links 312) that may form associations between actual credentials and virtual credentials. Figure 1A ), such that whenever the device 100 uses the virtual credential for a financial transaction with the merchant subsystem 200 (e.g., after being configured on the device 100), the payment network subsystem 360 may receive an authorization request indicating the virtual credential (e.g., as Figure 1A 674) and may analyze the authorization request based on the actual credentials associated with the virtual credentials, as determined by table 312. By providing virtual credentials on device 100 rather than actual credentials, financial institution subsystem 350 may be configured to limit fraudulent activity that may result if an unauthorized user intercepts the virtual credentials, because payment network subsystem 360 may only be configured to utilize table 312 to link the virtual credentials to the actual credentials during a particular transaction. Multiple credentials may be provided on device 100 at one or more different instances of step 604, where different credentials may be associated with different payment network subsystems 360 and / or different issuing bank subsystems 370 of financial institution subsystem 350.

[0054] At step 605, device 100 may be configured to set a default priority and / or enable a user to set a user-preferred priority for specific payment credentials provided on device 100 (e.g., the various credentials provided on secure element 145 at one or more iterations of step 604). Such priority may be configured to present specific credentials as default / preferred credentials for all situations or for different specific situations (e.g., prioritizing American Express credentials over Mastercard credentials for all online payments, but prioritizing Mastercard credentials over American Express credentials for local NFC payments, or prioritizing American Express credentials over Mastercard credentials during the first half of each calendar month, but prioritizing Mastercard credentials over American Express credentials for the second half of each calendar month, or prioritizing American Express credentials over Mastercard credentials for payments when device 100 is in a first location, but prioritizing Mastercard credentials over American Express credentials when device 100 is in a second location). Any suitable priority may be defined at step 605 using any suitable technique (eg, via any suitable UI application provided to a user of device 100 , such as via a pass or wallet application of device 100 ).

[0055] At step 606, process 600 may include sharing merchant context data 656 from merchant subsystem 200 with electronic device 100 (directly or via location subsystem 170). As described above with respect to step 502 of process 500 and described in more detail below, such merchant context data 656 may include any suitable data for identifying one or more specific characteristics of merchant subsystem 200 and / or the purchase transaction to be funded. For example, merchant context data 656 may be transmitted from merchant subsystem 200 to device 100 directly (e.g., via path 15 or via a bidirectional path that may also transmit data 5) and / or via location subsystem 170 (e.g., via paths 93 and 95). Merchant context data 656 may include any suitable information, such as a merchant identifier that can identify a particular merchant from which data is transmitted, a transaction identifier that can identify a particular purchase transaction to be funded, one or more pieces of information specific to such transaction (e.g., the purchase price, a description of the product / service purchased, shipping information, etc.), an identification of the currency to be used during such transaction, a list of financial institutions whose payment credentials are acceptable, preferred, or otherwise recommended by merchant subsystem 200 (e.g., whether a particular transaction is currently funded between electronic device 100 and merchant subsystem 200 is at least partially known), and / or one or more fields of customizable information that can be uniquely customized by merchant subsystem 200 for a particular transaction and / or for a particular time period and / or for a particular type of user electronic device or user / buyer (e.g., information describing why one payment credential is recommended or preferred over another, additional information that a buyer may request, such as a request to select one of several options as a gift from the merchant to the buyer, etc.). In some embodiments, at least a portion of such merchant context data 656 may be transmitted by location subsystem 170, which may be located at a particular distance (e.g., Figure 1 15 feet) such that any device 100 that is currently engaged in a financial transaction with the merchant subsystem 200 or that may engage in a potential financial transaction with the merchant subsystem 200 in the future due to its current location being proximate to the merchant subsystem 200 may receive specific contextual data that may at least partially configure recommendations for the device 100 (e.g., one or more recommendations to use a particular payment credential available to the device 100 relative to another device for any suitable financial transaction with the merchant subsystem 200).

[0056] At step 607, process 600 may include associating a merchant's online resource, such as merchant application 113 or merchant website, with merchant key 157. For example, commercial entity subsystem 400 may populate table 430 to associate merchant key 157 with a merchant's resource (e.g., application 113 or website) for enabling secure commercial credential data communication (e.g., communication between device 100 and merchant subsystem 200) using the merchant resource. Figure 1A Both merchant subsystem 200 and commercial entity subsystem 400 may store a version of such merchant key 157 (e.g., in respective secure elements of merchant subsystem 200 and commercial entity subsystem 400, such as Figure 1A ). In some embodiments, in order to participate in the online resource payment program, the merchant may be required to be registered as a member of the program run by the business entity of the business entity subsystem 400 and / or obtain a merchant certificate. The merchant may not be able to receive payment data without a certificate. Each certificate may contain a unique merchant identifier that binds the merchant to a public key for the merchant (e.g., public merchant key 157). A merchant may obtain multiple certificates and, therefore, may maintain more than one identity. Such a unique merchant identifier may be provided by the merchant subsystem 200 to the device 100 (e.g., at step 610, as part of data 660 and / or as an inherent element of the online resource running on the device 100 (e.g., merchant application 113)), and such a merchant identifier may be provided from the device 100 to the business entity subsystem 400 during the attempted transaction (e.g., as at least part of data 664 of step 614 described below).

[0057] At step 608, process 600 may include accessing a merchant's online resources 658 (e.g., Figure 1A third-party applications 113 or websites of merchants). Figure 1A As shown, the merchant's third-party application 113 can be loaded onto the device 100 from the commercial entity subsystem 400 (e.g., from the application store 420). Figure 4As shown, a user may use the touch screen input component 110f of the I / O component 114a to select a "merchant application" icon 183 of a particular screen 190 of the GUI 180, and this selection may be recognized by the electronic device 100 as an initiating event that provides the user with the ability to interact with the merchant's third-party application 113. Alternatively or in addition, such online resources 658 may be accessed by the electronic device 100 directly from the merchant subsystem 200. In response to such selection of the merchant application icon 183, the GUI 180 may provide an interactive screen in which the electronic device 100 may enable the user to interact with the application 113 to peruse commercially available items from the merchant for purchase. Alternatively, step 608 may include the device 100 using an Internet application of the device 100 to access the merchant's online resource 658 as a merchant webpage from the merchant subsystem 200 (e.g., via the merchant server 210), or via Figure 4 The resource may be selected by clicking the "Internet" icon 182 of a particular screen 190 of the GUI 180 to provide the user with the ability to interact with the merchant's web page rather than with the merchant's third-party application.

[0058] Next, at step 610, the device 100 may receive potential transaction data 660 from the visited merchant's online resources. Figure 1AAs shown, potential transaction data 660 may be provided from the merchant subsystem 200 (e.g., from the merchant server 210) to the device 100 while the device 100 is interacting with a merchant's third-party application 113, or the merchant's website, or any other suitable online resource of the merchant (e.g., resource 658). Alternatively, or in addition, at least a portion of the potential transaction data 660 may be locally accessible by the device 100 via an application 113 local to the device 100 (e.g., when the application 113 is stored in the memory component 104 or is being executed by the processor 102 of the device 100), rather than actively sending the data from the merchant server 210 to the device 100 at step 610. For example, when the application 113 is initially stored on the device 100 (e.g., as the merchant's online resource 658 at step 608), at least some of the potential transaction data 660 may be generated by the initially stored application 113 without the merchant subsystem 200 providing any additional information to the device 100. Potential transaction data 660 may include any suitable data indicating one or more specific characteristics of a potential purchase transaction to be funded between a user of device 100 and a merchant of merchant subsystem 200, including, but not limited to, a merchant identifier that identifies the specific merchant used to send the data, identification of the specific merchant resource being used (e.g., a specific merchant application 113 or website being accessed by device 100), a transaction identifier that identifies the specific purchase transaction to be funded, one or more pieces of information specific to the transaction (e.g., the purchase price, a description of the product / service being purchased or leased or otherwise paid for, shipping information, etc.), identification of the currency to be used during the transaction, a list of financial institutions whose payment credentials the merchant subsystem 200 may accept, prefer, or otherwise recommend, and / or one or more fields of customizable information that may be uniquely customized by merchant subsystem 200 for a particular transaction (e.g., additional information that the purchaser may request, such as a request to select one or more options for a prize to be given by the merchant to the purchaser, etc.), and / or any other suitable information. In some embodiments, at least a portion of such transaction data 660 may include data similar to at least a portion of the merchant context data 656 that may be shared (e.g., at step 606), which may at least partially configure recommendations for device 100 (e.g., one or more recommendations to use a particular payment credential available with device 100 relative to another device for a particular financial transaction with merchant subsystem 200). Alternatively, specific potential transaction data may be received via a bidirectional communication path that may also be used to transmit data 5 from device 100 to merchant subsystem 200.

[0059] The merchant context data 656 and / or potential transaction data 660 may define a merchant's request for the device 100 to generate a payment token for the purchase of products and / or services and may encapsulate any suitable information about the potential transaction, including, for example, information about the merchant's payment processing capabilities, the payment amount, and the currency code. The merchant context data 656 and / or potential transaction data 660 may also include a list of one or more financial institutions or payment credential types that may be supported by the merchant subsystem 200 (e.g., credentials supported by one or more payment networks (e.g., one or more payment network subsystems 360) and / or one or more issuing banks (e.g., one or more issuing bank subsystems 370)), such that the device 100 may be configured to determine whether any of such listed one or more payment credential types has an authorized payment credential on the device 100. If there is such a match, for example, Figure 4A As shown in FIG, , GUI 180 may provide screen 190a where a device application (e.g., wallet application 103 and / or merchant online resource 113) may use merchant context data 656 and / or potential transaction data 660 to display to the user the name of the merchant (e.g., "Merchant A") using information 191a, the name of the product (e.g., "Product B") using information 191b, the price (e.g., "Price C") using information 191c, and / or initial shipping data (e.g., "Address D") using information 191d. Merchant context data 656 and / or potential transaction data 660 provided by merchant subsystem 200 to device 100 may indicate such information 191a, 191b, 191c, and / or 191d. Furthermore, based on such merchant context data 656 and / or potential transaction data 660, the device 100 may be configured to provide a screen 190a of the GUI 180 of the device 100, which may also include a purchase prompt 193 that may inquire whether the user wishes to make a purchase from the merchant based on the details of the data 656 / 660. Figure 4A As shown, screen 190a may prompt the user to interact with device 100 in one or more ways to select specific credentials available to device 100 for the purchase, for example, by including a credential selection prompt 195 that allows the user to select one of a plurality of potential credentials available on device 100 (e.g., the credentials of credential SSD 154a). Prompt 195 may only include credentials associated with payment networks supported by the merchant (e.g., as determined by data 656 / 660, as described above).

[0060] As shown, prompt 195 can be configured to prioritize or recommend specific credentials over other credentials based on suggestions that may be provided by data 656 / 660 from merchant subsystem 200. Such suggestions can be configured to override any defaults or preferences that may have been configured by device 100 or its user (e.g., at step 605), so that merchant context data can provide intelligent and / or context-based payment credential recommendations to the user of device 100 (e.g., using screen 190a) at prompt 195 of step 611. At step 611, device 100 can be configured to analyze any received merchant context data in conjunction with data indicating one or more credentials available to device 100 (e.g., on secure element 145) and / or in conjunction with any preferences that may be configured at step 605, or otherwise generate and present prompt 195 (e.g., using screen 190a) based on such analysis. For example, as shown, a first credential Y may be provided at the top of the list of one or more credentials in prompt 195 and may be distinguished by a default identifier “(D)” that may be used to indicate that credential Y is currently the default credential to be used for the transaction, as may be indicated by data 656 / 660 and the processing of step 611. In addition, credential Y may be associated with a reasoning indicator “(R1)” that may provide one or more reasons or motivations for using credential Y (e.g., rather than any other credentials available to device 100). In addition, prompt 195 may include a second credential X that may be provided directly below credential Y in the list of one or more credentials in prompt 195 and may be associated with a reasoning indicator “(R2)” that may provide one or more reasons or motivations for using credential X. Additionally or alternatively, prompt 195 may include a third credential Z, which may be provided directly below credential X in the list of one or more credentials in prompt 195 and may be associated with a reasoning indicator “(R3)” that may provide one or more reasons or motivations for using credential Z.

[0061] It should be understood that the list of credentials and demarcation lines "D" may be the same as or different from a default list that may be generated based solely on any user / device preferences (e.g., defined at step 605) and not based on any merchant context data. For example, a default list (e.g., based on the defaults or preferences of step 605 or otherwise not based on any merchant context data) may be configured to first provide a default demarcation line "D" for credential X, then credential Y, then credential Z without any merchant context information, but such merchant context information of data 656 / 660 may be configured to override such default configuration (if received by an application of device 100 from, and may be provided as such). Figure 4AIn some embodiments, if a credential available to device 100 is not acceptable for use by merchant subsystem 200 (e.g., as determined by device 100 processing merchant context data), such a credential may still be presented at step 611 (e.g., by screen 190a), but the presentation of the credential may convey to the user of device 100 that such a credential is not selectable (e.g., if credential Z is available to device 100 but not acceptable to merchant subsystem 200, the inference indicator (R3) may indicate that credential Z is not selectable for transactions with merchant subsystem 200 or the credential Z indicator may be grayed out). In other embodiments, device 100 may not present such a credential at step 611. Device 100 (e.g., process 102) may be configured to access credential availability data, such as any suitable information indicating one or more credentials available to device 100 (e.g., lifecycle state information from CRS application 151), and may process the credential availability data, along with user preference data (e.g., data based on the user interaction at step 605), and / or any device setting data (e.g., current firmware or application settings and / or rules), at step 611 to determine suitable recommendation data to present to the user and / or determine any suitable credentials to automatically utilize. In some embodiments, the payment recommendation data generated at step 611 may include information indicating credentials that may not currently be available to device 100. For example, the merchant context data may recommend the use of credential Z, but such credential Z may not currently be provided on the device 100, such that the device 100 may process such merchant context data at step 611 based on data indicating that credential Z is not currently available to the device 100 to generate payment recommendation data, which payment recommendation data may include an option for the user to provide such credential Z on the device 100 (for example, the reasoning indicator "(R3)" of the screen 190a may include a description of the benefits of using credential Z for the particular transaction and may alternatively or in addition include a description of the fact that credential Z is not currently provided on the device 100 but the user may initiate such provision by selecting credential Z at prompt 195, in response to which provision of credential Z may begin on the device 100).

[0062] Any inference indicator (e.g., inference indicator "X," and / or inference indicator "Y," and / or inference indicator "Z") may include any suitable information that may indicate one or more reasons why the credential associated with the indicator may be recommended or not recommended for use (e.g., an inference indicator may be "This credential is recommended because it will give you 5% cash back and there are special merchant transactions available only in the next 20 minutes."). For example, such inference may be based on information provided by merchant context data accessible to device 100. Additionally or alternatively, such inference may be based not only on merchant context data but also on any user preference data or other data accessible to device 100 (e.g., credential availability data). For example, an inference indicator may convey "This credential is recommended because it will double airline miles if used with this merchant, but you must first have this card on your device if you wish to use it" or "This credential is recommended because it will double airline miles if used with this merchant, but you must have used another credential for the last five transactions with this merchant."

[0063] Typically, while a user can select a default / preferred card for payment (e.g., based on the configuration of step 605), some merchants may not accept a particular payment card or may offer a discount if a particular payment method is available and used. Process 600 may use GeoFence and / or iBeacon, or any other suitable contextual technology, to indicate options to the payment device and automatically switch on behalf of the user if a different method is available to the user. Thus, smart payment selection or recommendations may utilize location cues or other merchant context information. Since a user with device 100 may enter a merchant's establishment, merchant context information may be accessed by device 100 and used to enable device 100 to automatically select or present options to the user to select an optimal or accepted payment method relative to the default payment method. Additionally or alternatively, smart payment selection using incentives may be provided. When a user with device 100 enters a merchant's establishment, merchant context information or cues may be provided to indicate to device 100 that there are incentives for using a particular payment method relative to the default method. As a specific example, a first payment credential of device 100 (e.g., an American Express payment credential (e.g., credential X)) may be configured (e.g., at step 605) as the default credential for all transactions with device 100, and then device 100 may enter a geo-fenced area (e.g., by device 100 being within distance D′ of location subsystem 170 of merchant subsystem 200) to receive merchant context data 656, wherein merchant subsystem 200 may utilize such merchant context data to indicate that the merchant is offering a 5% discount if the user uses a payment credential that is a Mastercard credential (e.g., credential Y), such that such merchant context data may be processed by device 100 to generate appropriate payment recommendation data, which may be provided to the user (e.g., at step 611), who may prioritize credential Y over credential X (e.g., if device 100 is configured to allow such merchant context data to override any device / user configuration). Process 600 may utilize geo-fencing to automatically update the priority of one card over another in a particular location (e.g., in a particular merchant store). Alternatively, in response to determining the identity of a particular merchant (e.g., via data 656 / 660), device 100 may be configured to determine a prioritized credential to suggest over other credentials (e.g., based on past use of a particular card at that merchant or similar merchants (e.g., by utilizing heuristic information for particular merchant contextual information and / or user history information)). A particular merchant with an appropriate location subsystem 170 may prompt device 100 each time device 100 is within a particular distance that there is a particular special offer in which use of a particular credential offers a particular reward (e.g., 5% cash back).

[0064] Merchant context data may be provided to device 100 in response to device 100 having a particular physical relationship with merchant subsystem 200 (e.g., being able to receive data from location subsystem 170 while at a threshold distance D'), which may help induce a particular type of payment to be made with terminal 5 of merchant subsystem 200 using data 5. Additionally or alternatively, such merchant context data may be provided to device 100 in response to device 100 interacting with a merchant application of merchant subsystem 200 (e.g., via communication path 15). Such merchant context data may be provided to device 100 via a bidirectional path along which data 5 may also be transmitted and / or via communication path 15 (e.g., when device 100 may be running online merchant application 113). Such merchant context data may be defined and / or updated by merchant subsystem 200 at any suitable time based on any suitable circumstances. For example, the merchant context data may change based on the time of day (e.g., between 2:00 PM and 5:00 PM, the merchant subsystem 200 may prefer or incentivize the use of American Express credentials, while at all other times of the day, the merchant subsystem 200 may prefer or incentivize the use of Mastercard credentials). The merchant context data may change based on any suitable information, such as the volume of transactions processed by the merchant subsystem 200 for one or more particular financial institutions over a period of time (e.g., once more than 50% of the transactions processed by the merchant subsystem 200 in a given time period or more than 500 transactions processed by the merchant subsystem 200 in a given time period are of a first type of credential (e.g., an American Express credit card), the merchant context data may be updated to recommend the use of another type of credential (e.g., a Mastercard credit card) over the first type of credential for the remainder of the given time period). Prior use and / or user selection of particular credentials in particular situations may be analyzed and processed by the device 100 (e.g., at step 611) to determine what recommendation data to present. For example, if the last five times device 100 was within distance D' of location subsystem 170, even though merchant context data recommends using credential Y over credential X (e.g., Figure 4A If the user of device 100 (as shown) still selects credential X, the device may be used to present credential X as the default or most recommended credential relative to credential Y, even though the merchant context data indicates otherwise, the processing and generation of recommendation data (e.g., at step 611) may be used to weight the previous user selection data relative to the merchant context data.

[0065] Merchant context data 656 and / or potential transaction data 660 may be provided to device 100 from merchant subsystem 200 (e.g., via terminal 220 and / or server 210 and / or location subsystem 170) via a path along which data 5 may also be transmitted, and may be received by NFC component 120 and / or via Figure 1A 193 and / or 195) and can be received by the communication component 106 of the device 100. The communication component 106 can pass the merchant context data 656 and / or potential transaction data 660 to the processor 102 (e.g., for display on the screen 190a as part of a user interface for an application on the device 100 (e.g., for information 191a-191d, 193 and / or 195)) and / or to the NFC component 120. For example, the NFC component 120 can utilize such merchant context data 656 and / or potential transaction data 660 to securely facilitate financial transactions between the device 100 and the merchant subsystem 200, as further described below. In some embodiments, the merchant context data 656 and / or potential transaction data 660 can be referred to as payment request data, and / or a uniform resource locator ("URL"), or any other suitable reference string and / or query string.

[0066] Furthermore, in addition to presenting such payment recommendation data based on data 656 / 660 (e.g., as prompt 195), step 611 of process 600 may also include receiving the intent and authentication of the user of device 100 to perform a financial transaction based on data 656 / 660 using specific credentials for a specific merchant, product, price, and shipping destination. Figure 4A Screen 190a may prompt the user to interact with device 100 in one or more ways to select a particular credential available to device 100 for use in making the purchase (e.g., by selecting credential Y from the list of credentials in prompt 195). Figure 4B As shown, the output display component 112a can be configured to respond to receiving a Figure 4A The user's selection of credentials from the credential selection prompt 195 of screen 190a provides screen 190b. Figure 4BScreen 190b of may prompt the user to interact with the device 100 in one or more ways to authenticate the user and their intent to utilize the selected credential (i.e., credential Y of credential entry 197 of screen 190b). This may include prompting the user (e.g., utilizing authentication prompt 198) to enter user authentication via a personal identification number ("PIN") or via user interaction with a biometric sensor in order to access the secure element of the device 100 and, therefore, access the credentials to be used for the purchase. Access SSD 154b may utilize applet 153b to determine whether such authentication has occurred before allowing use of other SSDs 154 (e.g., credential SSD 154a) to enable its credential information in commercial credential data communications. As just one example of step 611, applet 153b of access SSD 154b may be configured to determine the intent and local authentication of the user of the device 100 (e.g., via one or more input components 110, such as used for user interaction with application 113 via GUI 180). Figure 4 1) and, in response to such determination, may be configured to enable another particular SSD to conduct the payment transaction (e.g., utilizing the credential of credential SSD 154a, which is available for the selected credential Y). In some embodiments, after such determination but before such enabling, output display component 112a may be configured to provide Figure 4C 190c, which may prompt the user (e.g., using payment prompt 199) to interact with device 100 in one or more ways to ultimately initiate payment to merchant subsystem 200 based on data 656 / 660 using the selected and authenticated credentials.

[0067] Next, at steps 612-614, process 600 may include device 100 generating, encrypting, and transmitting commercial entity credential data 664 for use by commercial entity subsystem 400. Once the credentials of credential SSD 154a on the secure element of device 100 have been selected, authenticated, and / or enabled for use in a financial transaction (e.g., at step 611), the secure element of device 100 (e.g., processor module 142 of NFC component 120) may encrypt the credential data for use by commercial entity subsystem 400. For example, secure element ("SE") credential data 661 (e.g., applet data 153a) of credential SSD 154a may be encrypted into encrypted SE credential data 662 using credential key 155a' at step 612, such that encrypted SE credential data 662 may only be decrypted by an entity (e.g., financial institution subsystem 350) that has access to credential key 155a' for accessing SE credential data 661. SE credential data 661 may include all data necessary to make payments using the credential, such as, for example, a primary account number (e.g., an actual F-PAN or a virtual D-PAN), a card security code (e.g., a card verification code (“CVV”)), an expiration date, a name associated with the credential, etc. Once some or all of the SE credential data 661 of the credential SSD 154a is encrypted into encrypted SE credential data 662 using the credential key 155a' at step 612, the encrypted SE credential data 662 may be encrypted into encrypted commercial entity ("CE") credential data 663 at step 613 by access information (e.g., by the access key 155a of SSD 154a, the access key 155b of access SSD 154b, the ISD key 156k and / or the CRS 151k and / or by the CASD 158k signature). The encrypted SE credential data 662 may be encrypted alone or together with at least a first portion of the potential transaction data 660 (e.g., a first portion of the potential transaction data 660 that may include identification of the merchant, identification of the price and / or identification of the product / service) and / or any other suitable information (e.g., any information identifying the device 100 itself). For example, the secure element 145 of the device 100 (e.g., the processor module 142 of the NFC component 120) may use the access information to encrypt not only an identification of the merchant from the data 660 (e.g., an identification of the merchant or its resources used for purchases such as the application 113), but also an identification of the purchase amount and / or currency code from the data 660 and the encrypted SE credential data 661 of the SSD 154a (e.g., the encrypted SE credential data 662), thereby encrypting them into encrypted business entity credential data 663.

[0068] Next, at step 614, encrypted commercial entity credential data 663, along with any additional information such as at least some underlying transaction data 660 (e.g., identification of the merchant, identification of the price, and / or identification of the product / service) and / or any other suitable information (e.g., any information identifying device 100 itself and / or the merchant in unencrypted form), may be transmitted from device 100 to commercial entity subsystem 400 as commercial entity transaction data 664. Accordingly, at least a portion of commercial entity transaction data 664 (e.g., encrypted commercial entity credential data 663) may be decrypted only by an entity having access to the access information used for encryption (e.g., access key 155a, access key 155b, ISD key 156k, CRS 151k, and / or CASD 158k), thereby generating encrypted commercial entity credential data 663 for commercial entity transaction data 664 (e.g., commercial entity subsystem 400). Such commercial entity transaction data 664 may be generated at steps 612-614 and then transmitted to commercial entity subsystem 400 at step 614 (e.g., from the secure element of NFC component 120 via communication component 106 and communication path 65). Steps 612, 613, and 614 may ensure that any credential data generated and transmitted from the secure element of device 100 as part of commercial entity transaction data 664 is first encrypted so as not to be decrypted by another part of device 100. That is, SE credential data 661 of commercial entity transaction data 664 may be encrypted into encrypted SE credential data 662 using credential key 155a′, which may not be exposed to or accessible by any part of device 100 outside of its secure element. Furthermore, such encrypted SE credential data 662 of business entity transaction data 664 may be encrypted into encrypted business entity credential data 663 using access keys (e.g., access keys 155a, 155b, 156k, 151k and / or 158k (e.g., referred to herein as “access information”)) that may not be exposed or accessible to any portion of device 100 external to its secure element.

[0069] Next, at step 616, process 600 may include commercial entity subsystem 400 receiving and decrypting at least a portion of commercial entity transaction data 664. For example, commercial entity subsystem 400 may receive commercial entity transaction data 664 and then decrypt encrypted commercial entity credential data 663 of commercial entity transaction data 664 using access information (e.g., 155a, 155b, 156k, 151k, and / or 158k) available at commercial entity subsystem 400. This may enable commercial entity subsystem 400 to determine an unencrypted identification of the merchant (e.g., from decrypted commercial entity credential data 663) while also maintaining SE credential data 661 in an encrypted state (e.g., as encrypted SE credential data 662) because commercial entity subsystem 400 may not have access to credential key 155a′ that may be used by the secure element of device 100 to encrypt such SE credential data 661 into encrypted SE credential data 662 at step 612. Additionally or alternatively, the merchant may be identified by additional data that may have been included in commercial entity transaction data 664 and encrypted commercial entity credential data 663. Commercial entity transaction data 664 may include information identifying device 100, or at least its secure element, so that when data 664 is received by commercial entity subsystem 400, commercial entity subsystem 400 may know which access information to use at step 616 (e.g., which of access information 155a, 155b, 156k, 151k, and / or 158k). For example, commercial entity subsystem 400 may have access to multiple access keys 155a / 155b and / or multiple ISD keys 156k, each of which may be specific to a particular device 100 or a particular secure element.

[0070] Next, at step 617, process 600 may include commercial entity subsystem 400 identifying a merchant key 157 associated with a merchant that may be identified from commercial entity transaction data 664, and then using the merchant key 157 to re-encrypt at least a portion of commercial entity credential data 664. That is, after decrypting at least a first portion of commercial entity transaction data 664 using appropriate access information at step 616 (e.g., after decrypting encrypted CE credential data 663 to achieve encrypted SE credential data 662 and any other information that may be encrypted in encrypted CE credential data 663), commercial entity subsystem 400 may then, at step 617, re-encrypt at least a second portion of commercial entity transaction data 664 (e.g., encrypted SE credential data 662) using an appropriate merchant key 157 that may be associated with the merchant information identified in commercial entity transaction data 664. Figure 1A430 to determine such merchant key 157. Using the determined appropriate merchant key 157, commercial entity subsystem 400 may, at step 617, utilize the merchant key 157 to re-encrypt at least a portion of commercial entity transaction data 664 into encrypted merchant credential data 667. For example, encrypted merchant credential data 667 may include at least encrypted SE credential data 662 from commercial entity transaction data 664, and purchase amount data from commercial entity transaction data 664, or other suitable transaction data (e.g., data that may have been initially identified from transaction data 660). Merchant identification information from commercial entity transaction data 664 may not need to be included in encrypted merchant credential data 667, as the merchant identification may have been used to determine the merchant key 157 that may be used to encrypt encrypted merchant credential data 667 at step 617. Encrypted merchant credential data 667 may be signed by commercial entity subsystem 400, thereby establishing commercial entity subsystem 400 as the creator of such encrypted merchant credential data 667 when received by merchant subsystem 200 and / or enabling merchant subsystem 200 to ensure that encrypted merchant credential data 667 has not been modified after signing. Such encrypted merchant credential data 667 may be generated at steps 616 and 617 and then transmitted to electronic device 100 (e.g., from server 410 of commercial entity subsystem 400 via server 410) at step 618 along with any other suitable data as merchant transaction data 668. Figure 1A Path 65 is transmitted to the communication component 106 of the device 100).

[0071] Steps 616, 617 and 618 ensure that the business entity subsystem 400 is used as Figure 1A The credential data transmitted as part of the merchant transaction data 668 (e.g., credential data of the encrypted merchant credential data 667 of the merchant transaction data 668) may be encrypted so that it cannot be decrypted by a part of the device 100 other than the secure element. That is, the merchant transaction data 668 may be encrypted using a merchant key 157 that may not be exposed to or otherwise accessible by any part of the device 100, which in some embodiments includes its secure element. In addition, the credential data of the merchant transaction data 668 (e.g., encrypted SE credential data 662 of the encrypted merchant credential data 667 of the merchant transaction data 668) may be encrypted using a credential key 155a' that may not be exposed to or otherwise accessible by any part of the device 100 outside of the secure element. The merchant transaction data 668 may then be forwarded by the device 100 as an online-based communication 670 to the merchant subsystem 200 (e.g., the merchant server 210) at step 620 (e.g., via Figure 1A6 and communication path 15). Such online-based communication 670 may include at least some merchant transaction data 668 (e.g., encrypted merchant credential data 667) and any other suitable information (e.g., information usable by merchant application 113 or any other merchant resource (e.g., merchant website) such as shipping information 1407d). Alternatively, rather than sharing merchant transaction data 668 as online-based communication 670 with merchant subsystem 200 via device 100 at steps 618 and 620, at step 621, commercial entity subsystem 400 may share merchant transaction data 668 as online-based communication 671 directly with merchant subsystem 200 (e.g., via Figure 1A path 85).

[0072] In some embodiments, if the transaction is to be funded by sharing payment card data via NFC communications between device 100 and merchant subsystem 200 when device 100 is local to merchant terminal 220, and merchant context data may be received by device 100 (e.g., directly by merchant subsystem 200 and / or via location subsystem 170) as merchant context data 656 at step 606, and after presenting payment recommendation data based on such data 656 and receiving a user payment selection at step 611, the payment card data associated with the selection may be shared with merchant terminal 220 via communication 5 at step 620. Alternatively, in some embodiments, if the transaction is to be funded through use of a merchant online resource 113 on device 100, then through online-based communication 670 or 671 between device 100 and merchant subsystem 200, merchant context data may be received by device 100 (e.g., directly by merchant subsystem 200) as transaction data 660 at step 610, and after presenting payment recommendation data based on such data 660 and receiving a user payment selection at step 611, payment card data associated with the selection may be shared with merchant subsystem 200 via communication 670 / 671 through steps 612-620 / 621.

[0073] Once merchant subsystem 200 receives such payment credential data (e.g., as communication 5 and / or online-based communication 670 / 671), process 600 may include step 622, at which merchant subsystem 200 may send confirmation data 672 to device 100 (e.g., via Figure 1ACommunication path 15). Such confirmation data 672 may be received by device 100 to indicate to the user of device 100 that the user's payment instruction has been received by merchant subsystem 200. After the user of device 100 may provide intent and authentication at step 611 to perform a financial transaction using specific credentials based on potential transaction merchant context data 656 / 660, the remaining steps of process 600 may occur transparently to the user. That is, once the user provides authentication and intent at step 611, one or more of steps 612-620 or 621 and steps 622-630 may proceed without any further user interaction and appear to be instantaneous to the user, whereby process 600 appears to the user to be after step 611, resulting in the automatic and instantaneous sending of credential data and confirmation to merchant subsystem 200 at step 622.

[0074] Additionally, once such payment credential data is received by the merchant subsystem 200 (e.g., as a communication system and / or online-based communication 670 / 671), the process 600 may further include step 623, at which the merchant subsystem 200 may be configured to generate and transmit to the acquiring bank subsystem 300 (e.g., via Figure 1A 670 / 671). For example, at step 623, the merchant subsystem 200 may at least partially decrypt the merchant transaction data 668 (e.g., received from communication 671 at step 621 or received from communication 670 at step 620) using its known merchant key 157 so that the payment data 673 may include SE credential data 661 of the credential SSD 154a encrypted using its credential key 155a' (e.g., encrypted SE credential data 662) rather than using a key not available to the financial institution subsystem 350. Then, at step 624, the acquiring bank subsystem 300 may forward the authorization request from the data 673 to the financial institution subsystem 350 as authorization request data 674 (e.g., via Figure 1ANext, at step 626, when the issuing bank subsystem 370 of the financial institution subsystem 350 receives the authorization request (e.g., directly from the acquiring bank subsystem 300 as data 674 at step 624, or indirectly as data 405 via the payment network subsystem 360 as described above), the payment information (e.g., the SE credential data 661 of the device 100 encrypted by the secure element of the device 100 via the credential key 155a' (e.g., encrypted SE credential data 662)) and the purchase amount (each of which may be included in the authorization request data 674 and in the data 673, 664, 668, 670, and / or 671) may be decrypted (e.g., using the credential key 155a' at the financial institution subsystem 350) and analyzed to determine whether the account associated with the commercial credential has sufficient credit to cover the purchase amount. If there are insufficient funds, the issuing bank subsystem 370 may deny the requested transaction by transmitting a negative authorization response to the acquiring bank subsystem 300. However, if there are sufficient funds, the issuing bank subsystem 370 may approve the requested transaction by transmitting a positive authorization response to the acquiring bank subsystem 300, and the financial transaction may be completed. Either type of authorization response as authorization response data 676 may be provided by the user financial subsystem 350 to the acquiring bank subsystem 300 at step 626 of process 600 (e.g., directly from the issuing bank subsystem 370 to the acquiring bank subsystem 300 via communication path 35, or based on a method that may be provided via communication path 35). Figure 1A The process 600 may further include providing authorization response data 415 from the issuing bank subsystem 370 to the payment network subsystem 360 via communication path 45 from the issuing bank subsystem 370 to the payment network subsystem 360. Next, in response to receiving authorization response data 676 at step 626, the process 600 may further include that the acquiring bank subsystem 300, or any other suitable subsystem, may share such authorization response data as authorization response data 678 with the merchant subsystem 200 at step 628, which may then be shared with the electronic device 100 as authorization response data 680 at step 630.

[0075] Thus, merchant subsystem 200 may be configured to process any suitable communication 5 or online-based communication 670 / 671 received from device 100 in any suitable manner. For example, to obtain plaintext payment credentials (e.g., SE credential data 661) from such online-based communications, merchant subsystem 200 may verify that the signature attribute of the received data is valid and that commercial entity subsystem 400 is the issuer of the signature. Merchant subsystem 200 may use any suitable technique to determine which merchant key (e.g., which merchant public key 157) commercial entity subsystem 400 used to construct the encrypted merchant credential data (e.g., data 667). Merchant subsystem 200 may then retrieve the corresponding merchant private key (e.g., merchant private key 157 at merchant subsystem 200) and use the retrieved key to unpack and / or decrypt the encrypted merchant credential data 667 to recover the encrypted SE credential data 662. Such data 662 may then be provided to an appropriate payment network 360, which may utilize an appropriate credential key 155a' of the financial institution subsystem 350 to unencapsulate and / or decrypt the encrypted SE credential data 662 to recover the SE credential data 661 (e.g., to recover plaintext payment information for a payment credential, such as complete EMV ("Europay MasterCard Visa") payment data).

[0076] In some embodiments, once device 100 is ready to prepare CE transaction data (e.g., data 664) to business entity subsystem 400 for a new online resource transaction (e.g., after step 611), but before doing so, device 100 may be configured to request specific data from the business entity subsystem. For example, before step 612 but after step 610, device 100 may request specific CE characteristic information (e.g., an unpredictable quantity or other suitable data) that can be used by device 100 and process 600 to add an additional layer of security to process 600. For example, in response to such a request, such CE characteristic information may be provided from business entity 400 to device 100 (e.g., at a step prior to step 612 (not shown)) and may be encrypted by secure element 145 along with other data. For example, such CE characteristic information may be encrypted as encrypted SE credential data 662 along with SE credential data 661 at step 612. Alternatively or in addition, such CE signature information may be encrypted as encrypted CE credential data 663 along with encrypted SE credential data 662 at step 613. In any case, such CE signature information may be included in CE transaction data 664 to commercial entity subsystem 400 and may be accessed by commercial entity subsystem 400 and compared with its earlier generated CE signature information to confirm a match or determine any potential fraud (e.g., if such CE signature information was encrypted at step 613). Additionally or alternatively, such CE signature information may be included in CE transaction data 664 and communications 670 so that it can be received by merchant subsystem 200 (e.g., via device 100). Furthermore, such CE feature information may be provided directly from commercial entity subsystem 400 to merchant subsystem 200 (e.g., as communication 671 at step 621 or at any other point in process 600 prior to step 622), such that merchant subsystem 200 may compare such CE feature information encrypted by device 100 and received by merchant subsystem 200 as at least part of communication 670 with such CE feature information that may be received by merchant subsystem 200 directly from commercial entity subsystem 400. If there is a match, such comparison may add another layer of security that merchant subsystem 200 may rely on in determining that communication 670 is not spoofed and may be used to perform a financial transaction.Such CE characteristic information (e.g., an initial unpredictable quantity) may be generated by the business entity subsystem 400, may be encrypted on the security element 145 (e.g., at steps 612 and / or 613), and provided to the merchant subsystem 200 (e.g., as part of communication 670 at step 620), and such CE characteristic information may also be provided directly from the business entity subsystem 400 to the merchant subsystem 200 (e.g., as communication 671 at step 621), such that both instances of such CE characteristic information may be used by the merchant subsystem 200 and / or by any remaining steps of the process 600 as a security layer for the process.

[0077] Process 600 may ensure that system 1 may utilize security keys accessible by the secure element of device 100 to securely transmit credential data to merchant subsystem 200 for use by financial institution subsystem 350, while enabling specific keys to be appropriately managed by commercial entity subsystem 400. That is, secure element 145 (e.g., NFC component 120) of device 100 may include credential key 155a′ and access information (e.g., 155a, 155b, 156k, 151k, and / or 158k), commercial entity subsystem 400 may include access information (e.g., 155a, 155b, 156k, 151k, and / or 158k) and merchant key 157, merchant entity 200 may include merchant key 157, and financial institution subsystem 350 may include credential key 155a′. Because device 100 and commercial entity subsystem 400 may each contain or have access to information (e.g., 155a, 155b, 156k, 151k, and / or 158k), device 100 may securely share the encrypted credential data (e.g., as data 664 of step 614) with commercial entity subsystem 400. Similarly, because commercial entity subsystem 400 and merchant subsystem 200 may each contain or have access to merchant key 157, commercial entity subsystem 400 may securely share the encrypted credential data (e.g., as data 671 of step 621 or via device 100 as data 670 of step 620) with merchant subsystem 200. Merchant subsystem 200 may then share the encrypted credential data with financial institution subsystem 350 via acquiring bank subsystem 300, which may ultimately decrypt the encrypted credential data using credential data 155a′. However, in some embodiments, any credential data of the secure element of device 100 (e.g., SE credential data 661 of applet 153a of SSD 154a) may not be shared in a decrypted state with non-secure elements of device 100 (e.g., processor 102 and / or communication component 106), nor may credential key 155a' be used by such non-secure elements of device 100. Credential key 155a' may be managed by financial institution subsystem 350, while certain access information (e.g., 155a, 155b, 156k, 151k, and / or 158k) may be managed or otherwise accessible by commercial entity subsystem 400, and merchant key 157 may be managed by commercial entity subsystem 400 and / or merchant subsystem 200, such that each of these keys may be maintained and / or updated and / or deleted as needed to maintain their validity. Thus, merchant key 157 may never be stored on device 100 or otherwise accessible by device 100. For example, merchant key 157 may not even be stored on the secure element of device 100 .Merchant key 157 may be revoked or expire after a certain amount of time, which may require merchant subsystem 200 and commercial entity subsystem 350 to communicate frequently to manage and / or update merchant key 157. This may enable commercial entity subsystem 400 to indicate which merchant subsystems 200 may use the security credentials of device 100 to conduct online transactions. In addition, certain access information (e.g., 155a, 155b, 156k, 151k, and / or 158k) may not always be stored on merchant subsystem 200 or otherwise accessible to it. For example, certain access information may be revoked or expire after a certain amount of time, which may require device 100 and commercial entity subsystem 400 to communicate frequently to manage and / or update such access information. This may enable commercial entity subsystem 400 to indicate which devices 100 may use the security credentials of device 100 to conduct online transactions with merchant subsystem 200 via commercial entity subsystem 400.

[0078] Thus, process 600 may enable at least one credential provided on a secure element of device 100 to be securely used for online payment transactions with merchant subsystem 200. Process 600 may be configured to provide a virtualized tunnel between the secure element of device 100 and merchant subsystem 200 that may transmit a highly secure, EMV (“Europay, MasterCard, Visa”) standard-level (e.g., “Chip and PIN”) data set of credential data for use in financial transactions. By trusting only data within the secure element of device 100 and not trusting any data or components of device 100 external to such secure element (e.g., processor 102 or application 113 local to device 100), process 600 may require that any credential data transmitted from the secure element (e.g., SE credential data 661 of applet 153a) be encrypted using a credential key 155a' known only to the secure element and financial institution subsystem 350 (e.g., encrypted SE credential data 662 as at step 612), and in some embodiments, then encrypted using access information (e.g., 155a, 155b, 156k, 151k and / or 158k) that may be known only to the secure element 145 and commercial entity subsystem 400 (e.g., encrypted commercial entity credential data 663 as at step 613). Commercial entity subsystem 400 may then utilize this data 663 (e.g., as part of received commercial entity transaction data 664) and its understanding of such access information (e.g., 155a, 155b, 156k, 151k, and / or 158k) along with merchant key 157 to decrypt / re-encrypt credential data transmitted by device 100 (e.g., at steps 616 / 617) for later use by merchant subsystem 200. An additional layer of security is achieved by providing commercial entity subsystem 400 in the middle of process 600. Commercial entity subsystem 400 may not only be aware of certain access information (e.g., 155a, 155b, 156k, 151k, and / or 158k) shared by secure element 145 of device 100, but also be aware of merchant key 157 shared by merchant subsystem 200. Thus, commercial entity subsystem 400 may be in a unique position to manage any online transactions between device 100 secure element and merchant subsystem 200 while being unaware of the credential data used (e.g., unaware of SE credential data 661 of applet 153a which may be encrypted by credential key 155a' at step 612 to encrypted SE credential data 662, e.g., because commercial entity subsystem 400 may not have access to credential key 155a').

[0079] Commercial entity subsystem 400 may be configured to provide a validation check after receiving commercial entity transaction data 664 but before providing merchant transaction data 668 (e.g., at steps 616-618 / 621). For example, commercial entity subsystem 400 may determine that received commercial entity transaction data 664 identifies a merchant whose merchant key 157 has expired or otherwise terminated or is not identified (e.g., by table 430). Thus, if commercial entity subsystem 400 determines at some point prior to steps 618 / 621 that a particular merchant is no longer trustworthy, commercial entity subsystem 400 may remove or otherwise disable its merchant key 157 from table 430 such that, when commercial entity subsystem 400 later identifies a merchant associated with that key 157 from received commercial entity transaction data 664 provided by electronic device 100, commercial entity subsystem 400 may not provide any associated merchant transaction data 668 / 671, thereby preventing the desired financial transaction. Alternatively, the merchant identified in commercial entity transaction data 664 received from electronic device 100 may never have a merchant key 157 associated with form 430, such that commercial entity subsystem 400 may recognize that commercial entity transaction data 664 may attempt to conduct a financial transaction with a merchant not identified by commercial entity subsystem 400, and thus commercial entity subsystem 400 may prevent execution of the transaction. However, if process 600 is able to complete, not only may commercial entity subsystem 400 be satisfied that a financial transaction is being conducted between known device 100 (e.g., due to shared access information (e.g., 155a, 155b, 156k, 151k, and / or 158k)) and known merchant subsystem 200 (e.g., due to known merchant key 157), but merchant subsystem 200 may also be satisfied that a financial transaction is being conducted with trusted device 100 (e.g., due to received communication data 670 / 671 being encrypted using merchant key 157 from trusted commercial entity subsystem 400).

[0080] It should be understood that Figure 6The steps shown in process 600 are exemplary only, and existing steps may be modified or omitted, additional steps may be added, and the order of certain steps may be changed. For example, it will be understood that some shared keys may be public keys, while other shared keys may be private keys or confidentiality keys (e.g., a key pair that includes a public key and a private key that are mathematically related). The public key of the key pair may be used to encrypt data, while the private key of the key pair may be used to decrypt the encrypted data. For example, access key 155a of SSD 154a and / or access key 155b of SSD 154b that may be stored in secure element 145 of device 100 may be a public key, while access key 155a and / or access key 155b available at commercial entity subsystem 400 may be associated with a private key, or vice versa. In addition or alternatively, the ISD key 156k of the ISD 152 that can be stored in the secure element of the device 100 can be a public key, while the ISD key 156k available at the commercial entity subsystem 400 can be associated with a private key, or vice versa. In addition or alternatively, the CRS 151k that can be stored in the secure element of the device 100 can be a public key, while the CRS 151k available at the commercial entity subsystem 400 can be associated with a private key, or vice versa. In addition or alternatively, the CASD 158k that can be stored in the secure element of the device 100 can be a public key, while the CASD 158k available at the commercial entity subsystem 400 can be a private key, or vice versa. In addition or alternatively, the merchant key 157 elsewhere in the table 430 or the commercial entity subsystem 400 can be a public key, while the merchant key 157 available at the merchant subsystem 200 can be associated with a private key, or vice versa. In addition, certain data can be signed by the component that transmits the data. For example, commercial entity transaction data 664 may be tagged by device 100 prior to transmission to commercial entity subsystem 400 at step 614, or encrypted commercial entity credential data 663 may be tagged by a secure element (e.g., by CASD 158k) at step 613 prior to transmission as at least a portion of transaction data 664 at step 614. Such tagging by device 100 may enable commercial entity subsystem 400 to determine with greater confidence that data 664 was generated by trusted device 100. Additionally or alternatively, data 668 may be tagged by commercial entity subsystem 400 prior to transmission to device 100 at step 618 and / or prior to transmission to merchant subsystem 200 at step 621. Such tagging by commercial entity subsystem 400 may enable device 100 and / or merchant subsystem 200 to determine with greater confidence that data 668 / 670 / 671 was generated by trusted commercial entity subsystem 400. It should be understood that device 100 is not required to be configured to handle NFC communications with another device or any other contactless proximity-based communications (eg, NFC communications with a merchant terminal of merchant subsystem 200 ).In contrast, device 100 may include a secure element for storing credential information that may be used for online transactions, as described with respect to process 600, but not for NFC transactions. For example, device 100 may include a secure element (e.g., with controller module 140 and / or memory module 150, but without device module 130).

[0081] Figure 7 Description

[0082] Figure 7 700 is a flowchart of an exemplary process 700 for recommending payment credentials. At step 702 of process 700, the electronic device may access merchant context data. For example, as described above with respect to step 502 of process 500 and / or step 606 of process 600, the electronic device 100 may access any suitable merchant context data (e.g., from merchant subsystem 200 and / or subsystem 170). Next, at step 704 of process 700, it may be determined whether the current settings of the electronic device are configured to allow payment recommendation data to be generated based on merchant context data. If it is determined that the current settings do not allow payment recommendation data to be generated based on merchant context data at step 704, the process 700 may proceed to step 706, where payment recommendation data may be presented by the electronic device, which payment recommendation data prioritizes the first credential based on the current settings of the electronic device. However, if it is determined that the current settings allow payment recommendation data to be generated based on merchant context data at step 704, the process 700 may proceed to step 708, where payment recommendation data may be presented by the electronic device, which payment recommendation data prioritizes the second credential based on merchant context data. For example, as described above with respect to step 605 of process 600, a user may define one or more user settings that may be used to at least partially define a priority among credentials on device 100 (e.g., at least a default credential to be prioritized), and merchant context data may then be processed in conjunction with such user settings at step 611 to determine whether to change the user-defined priority of one or more payment credentials as a result of the merchant context data.

[0083] It should be understood that Figure 7 The steps shown in process 700 are exemplary only, existing steps may be modified or omitted, additional steps may be added, and the order of certain steps may be changed.

[0084] Figure 8 Description

[0085] Figure 8 8 is a flow chart of an exemplary process 800 for recommending payment credentials. At step 802 of process 800, credential availability data indicating at least one payment credential may be accessed. For example, as described above with respect to Figure 4-Figure 6As described above, the secure element 145 may include at least one payment credential stored thereon, and the electronic device 100 (e.g., the processor 102) may be used to access credential availability data that may indicate one or more payment credentials stored on the secure element 145. At step 804 of process 800, merchant context data associated with the merchant subsystem may be accessed, wherein the merchant context data may indicate a preference for a first type of payment credential relative to a second type of payment credential. For example, as described above with respect to step 502 of process 500 and / or step 606 of process 600, the electronic device 100 may access any suitable merchant context data (e.g., from the merchant subsystem 200 and / or subsystem 170), which may indicate a preference or priority of one type of payment credential relative to another type of payment credential (e.g., credential Y relative to credential X). Then, at step 806 of process 800, payment recommendation data based on the accessed credential availability data and the accessed merchant context data may be presented. For example, as described above with respect to step 611 of process 600 , electronic device 100 may be used to present, on secure element 145 , payment recommendation data based on the processing of merchant context data and the availability of one or more credentials.

[0086] It should be understood that Figure 8 The steps shown in process 800 are exemplary only, existing steps may be modified or omitted, additional steps may be added, and the order of certain steps may be changed.

[0087] Figure 1 、 Figure 1A 、 Figure 2 、 Figure 3 and Figure 4 Further description of

[0088] Although not shown, Figure 1ACommercial entity subsystem 400 may be a secure platform system and may include a secure mobile platform ("SMP") agent component, an SMP trusted service manager ("TSM") component, an SMP cryptographic services component, an identity management system ("IDMS") component, a fraud system component, a hardware security module ("HSM") component, and / or a store component. One, some, or all of the components of commercial entity subsystem 400 may be implemented using one or more processor components that may be the same as or similar to processor component 102 of device 100, one or more memory components that may be the same as or similar to memory component 104 of device 100, 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 of the components of commercial entity subsystem 400 may be managed, owned, at least partially controlled, and / or otherwise provided by a single commercial entity (e.g., Apple Inc.) that may be distinct and independent from financial institution subsystem 350. The components of commercial entity subsystem 400 may interact with each other and work together with both financial institution subsystem 350 and electronic device 100 to provide new layers of security and / or to provide a more seamless user experience.

[0089] The SMP proxy component of commercial entity subsystem 400 can be configured to manage user authentication using commercial entity user accounts. Such an SMP proxy component can also be configured to manage the lifecycle and provisioning of credentials on device 100. The SMP proxy component can be a master endpoint that can control user interface elements (e.g., elements of GUI 180) on device 100. The operating system or other applications of device 100 (e.g., application 103, application 113, and / or application 143) can be configured to call specific application programming interfaces ("APIs"), and the SMP proxy component can be configured to process requests of those APIs and respond with data that can be exported to the user interface of device 100 and / or with application protocol data units ("APDUs") that can be communicated to secure element 145 of NFC component 120 (e.g., via communication path 65 between commercial entity subsystem 400 and electronic device 100). Such APDUs may be received by commercial entity subsystem 400 from financial institution subsystem 350 via a trusted service manager (“TSM”) of system 1 (e.g., a TSM of communication path 55 between commercial entity subsystem 400 and financial institution subsystem 350). The SMP TSM component of commercial entity subsystem 400 may be configured to provide GlobalPlatform-based services that may be used to collaborate with financial institution subsystem 35 to perform operations on device 100. GlobalPlatform or any other suitable secure channel protocol may enable such SMP TSM component to appropriately communicate between secure element 145 of device 100 and the TSM and / or provide sensitive account data for secure data communication between commercial entity subsystem 400 and financial institution subsystem 350.

[0090] The SMP TSM component of commercial entity subsystem 400 can be configured to use the HSM component of commercial entity subsystem 400 to protect its keys and generate new keys. The SMP Cryptographic Services component of commercial entity subsystem 400 can be configured to provide key management and cryptographic operations, which may be required for user authentication and / or confidential data transmission between components of system 1. Such an SMP Cryptographic Services component can utilize the HSM component of commercial entity subsystem 400 to perform secure key storage operations and / or opaque cryptographic operations. The payment cryptographic services of the SMP Cryptographic Services component of commercial entity subsystem 400 can be configured to interact with the IDMS component of commercial entity subsystem 400 to retrieve credit cards or other types of business credentials on file associated with user accounts of the commercial entity. Such a payment cryptographic service can be configured to be the only component of commercial entity subsystem 400 that has plaintext (i.e., non-hashed) information describing the business credentials (e.g., credit card numbers) of its user accounts in memory. The commercial entity fraud system component of commercial entity subsystem 400 may be configured to perform a commercial entity fraud check on the commercial credential based on data known to the commercial entity about the commercial credential and / or the user (e.g., based on utilizing data associated with the user account of the commercial entity (e.g., commercial credential information) and / or any other suitable data that may be under the control of the commercial entity and / or any other suitable data that may not be under the control of financial institution subsystem 350). Such commercial entity fraud system component of commercial entity subsystem 400 may be configured to determine a commercial entity fraud score for the credential based on various factors or thresholds. Additionally or alternatively, commercial entity subsystem 400 may include a storage component that may be a provider of various services for users of device 100 (e.g., an iTunes store for selling / renting media to be played by device 100). TM Store, Apple App Store for selling / renting applications for use on device 100 TM , Apple iCloud for storing data from device 100 TM , Apple's online store for purchasing various Apple products online, etc.). As just one example, such a store component of commercial entity subsystem 400 may be configured to manage applications 113 and provide applications 113 to device 100 (e.g., via communication path 65), where applications 113 may be any suitable application such as a banking application, an email application, a text messaging application, an Internet application, or any other suitable application. Any suitable communication protocol or combination of communication protocols may be used by commercial entity subsystem 400 to transmit data between various components of commercial entity subsystem 400 and / or between commercial entity subsystem 400 and other components of system 1 (e.g., via communication path 65). Figure 1AFinancial institution subsystem 350 and / or via communication path 55 Figure 1A Data is transmitted between electronic devices 100) via the communication path 65.

[0091] When the credentials of the secure element of device 100 (e.g., commercial credential data associated with the enabled applet 153a of the credential SSD 154a of NFC component 120) are appropriately enabled for provision to merchant subsystem 200 as commercial credential data communications (e.g., as contactless proximity-based communications to a merchant terminal and / or as presence-based communications 670 to a merchant server 210), acquiring bank subsystem 300 may utilize such commercial credential data communications for completing a financial transaction with financial institution subsystem 350. For example, after a user of electronic device 100 has selected a product to purchase and appropriately enabled a particular credential of device 100 for payment, merchant subsystem 200 may receive a suitable commercial credential data communication indicating commercial credential data for the particular credential. Merchant server 210 and / or merchant terminal 220 may be provided by any suitable merchant or merchant agent of merchant subsystem 200, which may provide products or services to the user of device 100 in response to device 100 providing payment credentials via such commercial credential data communications. Based on such received commercial credential data communications (e.g., communications 5 / 670), the merchant subsystem 200 may be configured to generate and transmit data 673 to the acquiring bank subsystem 300 (e.g., via communication path 25 between the merchant subsystem 200 and the acquiring bank subsystem 300), wherein the data 673 may include payment information and an authorization request that may indicate the user's commercial credential and the merchant purchase price for the product or service. The acquiring bank subsystem 300, also known as a payment processor or acquirer, may be a banking partner of a merchant associated with the merchant subsystem 200, and the acquiring bank subsystem 300 may be configured to collaborate with the financial institution subsystem 350 to approve and process credential transactions attempted by the electronic device 100 via commercial credential data communications with the merchant subsystem 200 (e.g., via contactless proximity-based communications and / or via online-based communications 670). Acquiring bank subsystem 300 may then forward the authorization request from data 673 to financial institution subsystem 350 (eg, via communication path 35 between acquiring bank subsystem 300 and financial institution subsystem 350 ) as data 674 .

[0092] Payment network subsystem 360 and issuing bank subsystem 370 can be a single entity or separate entities. For example, American Express can be both payment network subsystem 360 and issuing bank subsystem 370. In contrast, Visa and MasterCard can be payment network 360 and can work with issuing banks 370 such as Chase, Wells Fargo, Bank of America, etc. Financial institution subsystem 350 may also include one or more acquiring banks, such as acquiring bank subsystem 300. For example, acquiring bank subsystem 300 and issuing bank subsystem 370 may be the same entity. One, some, or all components of acquiring bank subsystem 300 may be implemented using one or more processor components, one or more memory components, and / or one or more communication components. These processor components may be the same as or similar to processor component 102 of device 100, these memory components may be the same as or similar to memory component 104 of device 100, and these communication components may be the same as or similar to communication component 106 of device 100. One, some, or all components of the payment network subsystem 360 may be implemented using one or more processor components that may be the same as or similar to the processor component 102 of the device 100, one or more memory components that may be the same as or similar to the memory component 104 of the device 100, and / or one or more communication components that may be the same as or similar to the communication component 106 of the device 100. One, some, or all components of the issuing bank subsystem 370 may be implemented using one or more processor components that may be the same as or similar to the processor component 102 of the device 100, one or more memory components that may be the same as or similar to the memory component 104 of the device 100, and / or one or more communication components that may be the same as or similar to the communication component 106 of the device 100. In the event that the payment network subsystem 360 and the issuing bank subsystem 370 are separate entities, the payment network subsystem 360 may receive the authorization request for data 674 from the acquiring bank subsystem 300 and may then forward the request to the issuing bank subsystem 370 as data 405 (e.g., via the communication path 45 between the payment network subsystem 360 and the issuing bank subsystem 370). In the event that payment network subsystem 360 and issuing bank subsystem 370 are the same entity, acquiring bank subsystem 300 may submit an authorization request for data 674 directly to issuing bank subsystem 370. In addition, payment network subsystem 360 may respond to acquiring bank subsystem 300 on behalf of issuing bank subsystem 370 (e.g., according to terms agreed upon between payment network subsystem 360 and issuing bank subsystem 370).By interfacing between acquiring bank subsystem 300 and issuing bank subsystem 370, payment network subsystem 360 can reduce the number of entities with which each acquiring bank subsystem 300 and each issuing bank subsystem 370 may have to directly interact. That is, to minimize direct integration points with financial institution subsystem 350, payment network subsystem 360 can act as an aggregator for each issuing bank 370 and / or each acquiring bank 300. Financial institution subsystem 350 may also include one or more acquiring banks, such as acquiring bank subsystem 300. For example, acquiring bank subsystem 300 may be the same entity as issuing bank subsystem 370.

[0093] When issuing bank subsystem 370 receives the authorization request (e.g., directly from acquiring bank subsystem 300 as data 674 or indirectly via payment network subsystem 360 as data 405), the payment information (e.g., the commercial credential information of device 100) and the purchase amount that may be included in the authorization request may be analyzed to determine whether the account associated with the commercial credential has sufficient credit to cover the purchase amount. If there are insufficient funds, issuing bank subsystem 370 may deny the requested transaction by transmitting a negative authorization response to acquiring bank subsystem 300. However, if there are sufficient funds, issuing bank subsystem 370 may approve the requested transaction by transmitting a positive authorization response to acquiring bank subsystem 300, and the financial transaction may be completed. Either type of authorization response as authorization response data 676 may be provided by the user financial subsystem 350 to the acquiring bank subsystem 300 (e.g., the authorization response data 676 may be provided directly from the issuing bank subsystem 370 to the acquiring bank subsystem 300 via communication path 35, or the authorization response data 676 may be provided from the payment network subsystem 360 to the acquiring bank subsystem 300 based on authorization response data 415 that may be provided from the issuing bank subsystem 370 to the payment network subsystem 360 via communication path 45).

[0094] As mentioned and as Figure 2 As shown, the electronic device 100 may include, but is not limited to, a music player (e.g., an iPod available from Apple Inc. (Cupertino, California) TM ), video players, still image players, game consoles, other media players, music recorders, movie or video cameras or recorders, still cameras, other media recorders, radio equipment, medical equipment, household appliances, vehicle instruments, musical instruments, calculators, cellular telephones (e.g., iPhone available from Apple Inc. TM), other wireless communication devices, personal digital assistants, remote controls, pagers, computers (e.g., desktop computers, laptop computers, tablet computers (e.g., iPad available from Apple Inc. TM ), servers, etc.), monitors, televisions, audio equipment, set-top boxes, set-top boxes, small speakers, modems, routers, printers, or any combination thereof. In some embodiments, the electronic device 100 can perform a single function (e.g., a device dedicated to financial transactions), while in other embodiments, the electronic device 100 can perform multiple functions (e.g., a device for conducting financial transactions, playing music, and receiving and transmitting phone calls). The electronic device 100 can be any portable, mobile, handheld, or miniature electronic device that can be configured to conduct financial transactions while the user is on the go. Some miniature electronic devices may have more features than handheld electronic devices such as iPods. TM The exemplary microelectronic device may be integrated into a variety of objects, including but not limited to watches, rings, necklaces, belts, belt attachments, headphones, shoe attachments, virtual reality devices, glasses, other wearable electronic devices, accessories for sports equipment, accessories for fitness equipment, key chains, or any combination thereof. Alternatively, the electronic device 100 may be entirely non-portable, but may generally be stationary.

[0095] like Figure 2 As shown, for example, electronic device 100 may include a processor 102, a memory 104, a communication component 106, a power source 108, an input component 110, an output component 112, an antenna 116, and a near field communication ("NFC") component 120. Electronic device 100 may also include a bus 118 that may provide one or more wired or wireless communication links or pathways for transferring data and / or power to, from, or between the various other components of device 100. In some embodiments, one or more components of electronic device 100 may be combined or omitted. Additionally, electronic device 100 may include components that are not combined or included in the device 100. Figure 2 For example, the electronic device 100 may include any other suitable components or Figure 2 For simplicity, Figure 2 Only one of each type of component is shown.

[0096] The memory 104 may include one or more storage media, including, for example, a hard drive, a flash memory, a permanent memory such as a read-only memory ("ROM"), a semi-permanent memory such as a random access memory ("RAM"), any other suitable type of storage component, or any combination thereof. The memory 104 may include a cache memory, which may be one or more different types of memory for temporarily storing data for electronic device applications. The memory 104 may be fixedly embedded within the electronic device 100, or may be incorporated on one or more suitable types of cards (e.g., a subscriber identity module ("SIM") card or a secure digital ("SD") memory card) that can be repeatedly inserted into and removed from the electronic device 100. Memory 104 may store media data (e.g., music files and image files), software (e.g., for implementing functionality on device 100), firmware, preference information (e.g., media playback preferences), lifestyle information (e.g., dietary preferences), training information (e.g., information obtained by a motion monitoring device), transaction information (e.g., information such as credit card information), wireless connection information (e.g., information that enables device 100 to establish a wireless connection), subscription information (e.g., information for tracking podcasts or television programs or other media to which a user subscribes), contact information (e.g., phone numbers and email addresses), calendar information, any other suitable data, or any combination thereof.

[0097] A communication component 106 may be provided to allow the device 100 to communicate with one or more other electronic devices or servers or subsystems (e.g., one or more subsystems or other components of the system 1) using any suitable communication protocol. For example, the communication component 106 may support Wi-Fi (e.g., 802.11 protocol), ZigBee (e.g., 802.15.4 protocol), WiDi TM , Ethernet, Bluetooth TM 、Bluetooth TM Bluetooth Low Energy ("BLE"), high-frequency systems (e.g., 900 MHz communication systems, 2.4 GHz communication systems, and 5.6 GHz communication systems), infrared, Transmission Control Protocol / Internet Protocol ("TCP / IP") (e.g., any protocol used in each TCP / IP layer), Stream Control Transmission Protocol ("SCTP"), Dynamic Host Configuration Protocol ("DHCP"), Hypertext Transfer Protocol ("HTTP"), BitTorrent TM , File Transfer Protocol ("FTP"), Real-time Transport Protocol ("RTP"), Real-time Streaming Protocol ("RTSP"), Real-time Control Protocol ("RTCP"), Remote Audio Output Protocol ("RAOP"), Actual Data Transfer Protocol TM(“RDTP”), User Datagram Protocol (“UDP”), Secure Shell Protocol (“SSH”), Wireless Distribution System (“WDS”) bridging, any communication protocol that can be used by wireless telephones, cellular telephones, and personal email devices (e.g., Global System for Mobile Communications (“GSM”), GSM plus Enhanced Data Rates for GSM Evolution (“EDGE”), Code Division Multiple Access (“CDMA”), Orthogonal Frequency Division Multiple Access (“OFDMA”), High Speed Packet Access (“HSPA”), multi-band, etc.), any communication protocol that can be used by a low power wireless personal area network (“6LoWPAN”) module, any other communication protocol, or any combination thereof. Communication component 106 can also include or be electrically coupled to any suitable transceiver circuitry (e.g., transceiver circuitry or antenna 116 via bus 118) that can enable device 100 to be communicatively coupled to another device (e.g., a host computer or an accessory device) and communicate with the other device wirelessly or via a wired connection (e.g., using a connector port). Communication component 106 can be configured to determine the geographic location of electronic device 100. For example, communication component 106 can utilize a global positioning system ("GPS") or an area-wide positioning system or a site-wide positioning system that can use cell tower positioning technology or Wi-Fi technology.

[0098] The power supply 108 may include any suitable circuitry for receiving and / or generating power and providing such power to one or more of the other components of the electronic device 100. For example, the power supply 108 may be coupled to a power grid (e.g., when the device 100 is not operating as a portable device or when the device's battery is being charged at an electrical outlet using power generated by a power plant). As another example, the power supply 108 may be configured to generate power from a natural source (e.g., solar energy using a solar cell). As another example, the power supply 108 may include one or more batteries for providing power (e.g., when the device 100 is operating as a portable device). For example, the power supply 108 may include one or more batteries (e.g., gel batteries, nickel metal hydride batteries, nickel cadmium batteries, nickel hydrogen batteries, lead batteries, or lithium ion batteries), an uninterruptible power supply or continuous power supply ("UPS" or "CPS"), and circuitry for processing power received from a power generation source (e.g., power generated by a power plant and delivered to a user via an electrical outlet or otherwise). Power may be provided by the power supply 108 as alternating current (AC) or direct current (DC) and may be processed to convert the power to have specific characteristics or to constrain the received power to have specific characteristics. For example, the power may be converted to or from DC and constrained to one or more values of average power, peak power, energy per pulse, voltage, current (e.g., measured in amperes), or any other characteristic of the received power. For example, based on the needs or demands of the electronic device 100 or peripheral devices that may be coupled to the electronic device 100, the power supply 108 may be configured to request or provide specific amounts of power at different times (e.g., to request more power when charging a battery than when the battery is already charged).

[0099] One or more input components 110 may be provided to allow a user to interact or interact with the device 100. For example, the input components 110 may take a variety of forms, including, but not limited to, a touchpad, a dial, a click wheel, a scroll wheel, a touch screen, one or more buttons (e.g., a keyboard), a mouse, a joystick, a trackball, a microphone, a camera, a scanner (e.g., a barcode scanner or any other suitable scanner that can obtain product identification information from a code such as a barcode, QR code, etc.), a proximity sensor, a light detector, a motion sensor, a biometric sensor (e.g., a fingerprint reader or other feature recognition sensor that can be used in conjunction with a feature processing application accessible to the electronic device 100 to authenticate the user), one or more sensors of any suitable location-aware device that can be used to configure the device 100 to function as a location-based service ("LBS"), 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 operating the device 100.

[0100] The electronic device 100 may also include one or more output components 112 that can present information (e.g., graphical information, auditory information, and / or tactile information) to a user of the device 100. For example, the output components 112 of the electronic device 100 can take a variety of forms, including but not limited to audio speakers, headphones, an audio line-out, a visual display, an antenna, an infrared port, a tactile output component (e.g., a roller, a vibrator, etc.), or a combination thereof.

[0101] As a specific example, the electronic device 100 may include a display output component as the output component 112. Such a display output component may include any suitable type of display or interface for presenting visual data to a user. The display output component may include a display embedded in the device 100 or coupled to the device 100 (e.g., a removable display). The display output component may include, for example, a liquid crystal display (“LCD”), a light emitting diode (“LED”) display, an organic light emitting diode (“OLED”) display, a surface conduction electron emitter display (“SED”), a carbon nanotube display, a nanocrystal display, any other suitable type of display, or a combination thereof. Alternatively, the display output component may include a removable display or projection system for providing a display of content on a surface remote from the electronic device 100, such as a video projector, a head-up display, or a three-dimensional (e.g., holographic) display. As another example, the display output component may include a digital viewfinder or a mechanical viewfinder, such as the type of viewfinder found in compact digital cameras, reflex cameras, or any other suitable still or video cameras. The display output component may include a display driver circuit, a circuit for driving the display driver, or both, and such a display output component may be used to display content (e.g., media playback information, application screens for applications implemented on the electronic device 100, information about ongoing communication operations, information about incoming communication requests, device operation screens, etc.) possibly under the direction of the processor 102.

[0102] It should be noted that one or more input components and one or more output components may sometimes be collectively referred to herein as input / output (“I / O”) components or I / O interfaces (e.g., input component 110 and output component 112 as I / O components or I / O interfaces 114). For example, input component 110 and output component 112 may sometimes be a single I / O component 114, such as a touch screen, which may receive input information by a user touching a display screen and may also provide visual information to the user via the same display screen.

[0103] The processor 102 of the electronic device 100 may include any processing circuitry that may be used to control the operation and performance of one or more components of the electronic device 100. For example, the processor 102 may receive input signals from the input component 110 and / or drive output signals through the output component 112. Figure 2 As shown, processor 102 can be used to run one or more applications such as application 103, application 113 and / or application 143. Each application 103 / 113 / 143 may include, but is not limited to, one or more operating system applications, firmware applications, media playback applications, media editing applications, NFC low power mode applications, biometric processing applications, or any other suitable applications. For example, processor 102 can load application 103 / 113 / 143 as a user interface program to determine how instructions or data received via input component 110 or other components of device 100 can manipulate storable information and / or provide information to the user via output component 112. Application 103 / 113 / 143 can be accessed by processor 102 from any suitable source, such as from memory 104 (e.g., via bus 118) or from another device or server (e.g., via communication component 106). Processor 102 may include a single processor or multiple processors. For example, processor 102 may include at least one "general purpose" microprocessor, a combination of general purpose and special purpose microprocessors, an instruction set processor, a graphics processor, a video processor and / or related chipsets, and / or a special purpose microprocessor. Processor 102 may also include onboard memory for caching purposes.

[0104] The electronic device 100 may also include a near field communication ("NFC") component 120. The NFC component 120 may be any suitable proximity-based communication mechanism that can enable contactless proximity-based transactions or communications between the electronic device 100 and the merchant subsystem 200 (e.g., a merchant payment terminal). The NFC component 120 may allow for short-range communications at relatively low data rates (e.g., 424 kbps) and may comply with any suitable standard such as ISO / IEC 7816, ISO / IEC 18092, ECMA-340, ISO / IEC 21481, ECMA-352, ISO 14443, and / or ISO 15693. Alternatively or in addition, the NFC component 120 may allow for short-range communications at relatively high data rates (e.g., 370 Mbps) and may comply with any suitable standard such as TransferJet. TM The communication between NFC component 120 and merchant subsystem 200 may occur within any suitable short-range distance between device 100 and merchant subsystem 200 (e.g., see Figure 1AThe NFC component 120 may be configured to communicate with an external device (e.g., a merchant terminal of the merchant subsystem 200) by using a short-range communication method (e.g., a distance D) such as approximately 2 cm to 4 cm, and may operate at any suitable frequency (e.g., 13.56 MHz). For example, such short-range communication of the NFC component 120 may be performed via magnetic field induction, which may allow the NFC component 120 to communicate with other NFC devices and / or retrieve information from tags having radio frequency identification ("RFID") circuitry. The NFC component 120 may provide a means for collecting product information, transmitting payment information, and otherwise communicating with external devices (e.g., a merchant terminal of the merchant subsystem 200).

[0105] NFC component 120 may include any suitable module for implementing contactless proximity-based communication between electronic device 100 and merchant subsystem 200. Figure 2 As shown, for example, the NFC component 120 may include an NFC device module 130 , an NFC controller module 140 , and an NFC memory module 150 .

[0106] NFC device module 130 may include NFC data module 132, NFC antenna 134, and NFC booster 136. NFC data module 132 may be configured to contain, route, or otherwise provide any suitable data that may be transmitted by NFC component 120 to merchant subsystem 200 as part of a contactless proximity-based communication or NFC communication 5. Additionally or alternatively, NFC data module 132 may be configured to contain, route, or otherwise receive any suitable data that may be received by NFC component 120 from merchant subsystem 200 as part of a contactless proximity-based communication 5.

[0107] The NFC transceiver or NFC antenna 134 can be any suitable antenna or other suitable transceiver circuitry that can generally enable communications from the NFC data module 132 to the merchant subsystem 200 and / or from the subsystem 200 to the NFC data module 132. Thus, the NFC antenna 134 (e.g., a loop antenna) can be provided to specifically enable the contactless proximity-based communication capabilities of the NFC component 120.

[0108] Alternatively or in addition, NFC component 120 can utilize the same transceiver circuitry or antenna (e.g., antenna 116) as can be utilized by another communication component (e.g., communication component 106) of electronic device 100. For example, communication component 106 can utilize antenna 116 to implement Wi-Fi, Bluetooth, or other similar communication between electronic device 100 and another remote entity. TM, cellular communication, or GPS communication, while the NFC component 120 may utilize the antenna 116 to enable contactless proximity-based communication or NFC communication between the NFC data module 132 of the NFC device module 130 and another entity (e.g., the merchant subsystem 200). In such an embodiment, the NFC device module 130 may include an NFC booster 136 that may be configured to provide suitable signal amplification for data from the NFC component 120 (e.g., data within the NFC data module 132) so that such data can be properly transmitted by the shared antenna 116 as a communication to the subsystem 200. For example, the shared antenna 116 (e.g., a non-loop antenna) may require amplification from the booster 136 before the antenna 116 (e.g., a non-loop antenna) can be properly enabled to transmit contactless proximity-based communication or NFC communication between the electronic device 100 and the merchant subsystem 200 (e.g., more power may be required to transmit NFC data using the antenna 116 than may be required to transmit other types of data using the antenna 116).

[0109] The 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, permit, and / or otherwise control the NFC component 120 to transmit NFC communications between the electronic device 100 and the merchant subsystem 200. The NFC processor module 142 may exist as a standalone component, may be integrated into another chipset, or may be integrated with the processor 102, for example, as part of a system on a chip ("SoC"). Figure 2 As shown, the NFC processor module 142 of the NFC controller module 140 can be used to run one or more applications, such as an NFC low power mode or wallet application 143, which can help dictate the functionality of the NFC component 120. Applications 143 can include, but are not limited to, one or more operating system applications, firmware applications, NFC low power applications, or any other suitable applications accessible to the NFC component 120 (e.g., applications 103 / 113). The NFC controller module 140 can include one or more protocols, such as the Near Field Communication Interface and Protocol ("NFCIP-1"), for communicating with another NFC device (e.g., the merchant subsystem 200). The protocols can be used to adjust the communication speed and designate one of the connected devices as the initiator device for controlling near field communications.

[0110] The NFC controller module 140 can control the near-field communication mode of the NFC component 120. For example, the NFC processor module 142 can be configured to switch the NFC device module 130 between a reader mode / writer mode for reading information from an NFC tag (e.g., from the merchant subsystem 200) to the NFC data module 132 (e.g., Communication 5), a peer mode for exchanging data (e.g., Communication 5) with another NFC-enabled device (e.g., the merchant subsystem 200), and a card emulation mode for allowing another NFC-enabled device (e.g., the merchant subsystem 200) to read information (e.g., Communication 5) from the NFC data module 132. The NFC controller module 140 can also be configured to switch the NFC component 120 between an active mode and a passive mode. For example, the NFC processor module 142 can be configured to switch the NFC device module 130 (e.g., in conjunction with the NFC antenna 134 or the shared antenna 116) between an active mode, in which the NFC device module 130 can generate its own RF field, and a passive mode, in which the NFC device module 130 can use load modulation to transmit data to another device (e.g., the merchant subsystem 200) that generates an RF field. Operation in such a passive mode can extend the battery life of the electronic device 100 compared to operation in such an active mode. The mode of the NFC device module 130 can be controlled based on user preferences and / or based on preferences of the manufacturer of the device 100, which preferences can be defined or otherwise indicated by an application (e.g., application 103 and / or application 143) running on the device 100.

[0111] The NFC memory module 150 can operate in conjunction with the NFC device module 130 and / or the NFC controller module 140 to allow NFC communication between the electronic device 100 and the merchant terminal subsystem 200. The NFC memory module 150 can be embedded in the NFC device hardware or in the NFC integrated circuit ("IC"). The NFC memory module 150 is tamper-resistant and can provide at least a portion of a security element. For example, the NFC memory module 150 can store one or more applications (e.g., application 143) related to NFC communication that can be accessed by the NFC controller module 140. For example, such applications can include financial payment applications that can be encrypted, secure access system applications, membership card applications, and other applications. In some embodiments, the NFC controller module 140 and the NFC memory module 150 can independently or in combination provide a dedicated microprocessor system that can include an operating system, memory, application environment, and security protocols designed to store and execute sensitive applications on the electronic device 100. The NFC controller module 140 and the NFC memory module 150 can independently or in combination provide at least a portion of a secure element 145, which can be tamper-resistant. For example, such a secure element 145 can be configured to provide a tamper-resistant platform (e.g., as a single-chip secure microcontroller or a multi-chip secure microcontroller) that can securely host applications and their confidential and encrypted data (e.g., applets 153 and keys 155) in accordance with rules and security requirements set forth by a set of recognized trusted authorities (e.g., the authorities governing financial institution subsystems and / or industry standards such as the Global Platform). The NFC memory module 150 can be part of the memory 104 or at least one dedicated chip specific to the NFC component 120. The NFC memory module 150 can reside on a SIM card, on a dedicated chip on the motherboard of the electronic device 100, or as an external plug-in in a memory card. The NFC memory module 150 can be completely independent of the NFC controller module 140 and can be provided by a different component of the device 100 and / or can be provided to the electronic device 100 by a different removable subsystem. The secure element 145 may be a highly secure, tamper-resistant hardware component within a chip that may be used to store sensitive data or applications on the electronic device 100. At least a portion of the 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 that may be used for the electronic device 100 to be compatible within a Global System for Mobile Communications ("GSM") network, a Universal Mobile Telecommunications System ("UMTS"), and / or a Long Term Evolution ("LTE") standard network.Alternatively or additionally, at least a portion of the secure element 145 may be provided in an integrated circuit that may be embedded in the electronic device 100 during manufacture of the device 100. Alternatively or additionally, at least a portion of the secure element 145 may be provided in a peripheral device that may be plugged into, inserted into, or otherwise coupled to the electronic device 100, such as a micro Secure Digital (“SD”) memory card.

[0112] like Figure 2 As shown, the NFC memory module 150 may include one or more of an issuer security domain (“ISD”) 152 and a supplemental security domain (“SSD”) 154 (e.g., a service provider security domain (“SPSD”), a trusted service manager security domain (“TSMSD”), etc.), which may be defined and managed by an NFC specification standard (e.g., GlobalPlatform). For example, the ISD 152 may be part of the NFC memory module 150, where a trusted service manager (“TSM”) or an issuing financial institution (e.g., commercial entity subsystem 400 and / or financial institution subsystem 350) may store keys and / or other suitable information for creating or otherwise providing one or more credentials (e.g., commercial credentials associated with various credit cards, bank cards, gift cards, purchase cards, transportation cards, digital currencies, etc.) on the electronic device 100 (e.g., via the communication component 106) for credential content management and / or for security domain management. A specific supplemental security domain (“SSD”) 154 (e.g., SSD 154 a) may be associated with a specific TSM and at least one specific commercial credential (e.g., a specific credit card credential or a specific public transportation card credential) that may provide specific privileges or payment permissions to the electronic device 100. For example, a first payment network subsystem 360 (e.g., Visa) may be the TSM for the first SSD 154 a, and the applet 153 a of the first SSD 154 a may be associated with commercial credentials managed by the first payment network subsystem 360, while a second payment network subsystem 360 (e.g., MasterCard) may be the TSM for another SSD 154.

[0113] Security features may be provided to enable the use of the NFC component 120 (e.g., to enable activation of commercial credentials provided on the device 100), which may be particularly useful when transmitting confidential payment information, such as credit card information or bank account information for a credential, from the electronic device 100 to the merchant subsystem 200. Such security features may also include a secure storage area that may have restricted access rights. For example, user authentication via personal identification number ("PIN") entry or user interaction with a biometric sensor may be required to access the secure storage area (e.g., to enable a user to change the lifecycle state of a security domain element of a secure element). In certain embodiments, some or all of the security features may be stored within the NFC memory module 150. In addition, security information, such as authentication keys, used to communicate with the subsystem 200 may be stored within the NFC memory module 150. In certain embodiments, the NFC memory module 150 may include a microcontroller embedded within the electronic device 100.

[0114] Figure 1AThe merchant terminal of the merchant subsystem 200 may include a reader for detecting, reading, or otherwise receiving NFC communications from the electronic device 100 (e.g., when the electronic device 100 comes within a specified distance or proximity of such a merchant terminal). It should be noted that NFC communications between such a merchant terminal and the electronic device 100 may occur wirelessly, and thus may not require clear "line of sight" between the respective devices. As described above, the NFC device module 130 may be passive or active. When passive, the NFC device module 130 may be activated only when within the response range of a suitable reader of such a merchant terminal. For example, the reader of such a merchant terminal may emit a relatively low-power radio wave field that can be used to power an antenna utilized by the NFC device module 130 (e.g., the shared antenna 116 or the NFC-specific antenna 134), thereby enabling the antenna to transmit suitable NFC communication information (e.g., credit card credential information) from the NFC data module 132 via antenna 116 or antenna 134 to such a merchant terminal as NFC communications. When active, the NFC device module 130 may be combined with or otherwise have access to a power source local to the electronic device 100 (e.g., power source 108), which may enable the shared antenna 116 or the NFC-specific antenna 134 to actively transmit NFC communication information (e.g., credit card credential information) as NFC communication from the NFC data module 132 via antenna 116 or antenna 134 to such a merchant terminal, rather than reflecting radio frequency signals as in the case of a passive NFC device module 130. The merchant terminal may be provided by a merchant of the merchant subsystem 200 (e.g., in a merchant store for selling products or services directly to a user of the device 100 at the store). Although the NFC component 120 has been described with respect to near-field communication, it should be understood that the component 120 may be configured to provide any suitable contactless proximity-based mobile payment or any other suitable type of contactless proximity-based communication between the electronic device 100 and such a merchant terminal. For example, the NFC component 120 may be configured to provide any suitable short-range communication, such as short-range communication involving electromagnetic coupling technology / electrostatic coupling technology.

[0115] Although NFC component 120 has been described with respect to near field communication, it should be understood that component 120 may be configured to provide any suitable contactless proximity-based mobile payment or any other suitable type of contactless proximity-based communication between electronic device 100 and merchant subsystem 200. For example, NFC component 120 may be configured to provide any suitable short-range communication, such as short-range communication involving electromagnetic coupling technology / electrostatic coupling technology.

[0116] The electronic device 100 may also be provided with a housing 101 that may at least partially enclose one or more of the components of the device 100 to protect them from debris and other degradative forces external to the device 100. In some embodiments, one or more of the components may be provided within their own housing (e.g., the input component 110 may be a standalone keyboard or mouse located within its own housing that may communicate wirelessly or via wires with the processor 102, which may be provided within its own housing).

[0117] As mentioned, and as Figure 4 As shown, a specific example of the electronic device 100 may be a handheld electronic device such as an iPhone TM , wherein the housing 101 may provide access to various input components 110a-110i, various output components 112a-112c, and various I / O components 114a-114d, through which the device 100 and the user and / or the surrounding environment can interact with each other. Input component 110a may include a button that, when pressed, causes the device 100 to display a "home" screen or menu of the currently running application. Input component 110b may be a button for switching the electronic device 100 between a sleep mode and a wake mode, or between any other suitable modes. Input component 110c may include a two-position slider that can disable one or more output components 112 in certain modes of the electronic device 100. Input components 110d and 110e may include buttons for increasing and decreasing the volume output or any other feature output of the output component 112 of the electronic device 100. Each of the input components 110a-110e may be a mechanical input component such as a button supported by a dome switch, a slide switch, a control pad, a key, a knob, a scroll wheel, or any other suitable form.

[0118] The output component 112a may be a display that can be used to display a visual user interface or graphical user interface ("GUI") 180 that allows a 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 running application (e.g., application 103 and / or application 113 and / or application 143), which may be displayed in all or some areas of the display output component 112a. For example, Figure 4, the GUI 180 can be configured to display a first screen 190. One or more of the user input components 110a-110i can be used to navigate within the GUI 180. For example, one of the user input components 110 can include a scroll wheel that allows a user to select one or more graphical elements or icons 182 of the GUI 180. Icons 182 can also be selected via a touch screen I / O component 114a that can include a display output component 112a and an associated touch input component 110f. Such touch screen I / O component 114a can employ any suitable type of touch screen input technology, such as, but not limited to, resistive, capacitive, infrared, surface acoustic wave, electromagnetic, or near-field imaging. Furthermore, the touch screen I / O component 114a can employ single-point input sensing or multi-point (e.g., multi-touch) input sensing.

[0119] 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 when selected by the user. In addition, selection of a particular icon 182 may result in a hierarchical navigation process. For example, selection of a particular icon 182 may result in a new screen of GUI 180 that may include one or more additional icons or other GUI elements for the same application or a new application associated with the icon 182. A text indicator 181 may be displayed on or near each icon 182 to help the user interpret each graphical element icon 182. It should be understood that GUI 180 may include various components arranged in a hierarchical structure and / or a non-hierarchical structure. When a particular icon 182 is selected, device 100 may be configured to open a new application associated with the icon 182 and display the corresponding screen of GUI 180 associated with the application. For example, when a specific icon 182 (i.e., specific icon 183) marked with a "Merchant Application" text indicator 181 has been selected, the device 100 may launch or otherwise access a specific merchant application and may display a screen of a specific user interface that may include one or more tools or features for interacting with the device 100 in a specific manner. For each application, the screen may be displayed on the display output component 112a and may include various user interface elements (e.g., Figure 4-4C In addition or alternatively, for each application, various other types of non-visual information may be provided to the user via various other output components 112 of the device 100. A variety of graphical elements and visual schemes may be utilized to implement the operations described with respect to the various GUIs 180. Therefore, the described embodiments are not intended to be limited to the precise user interface scheme employed herein. Rather, these embodiments may include a variety of user interface styles.

[0120] The electronic device 100 may also include various other I / O components 114 that may allow communication between the device 100 and other devices. The I / O component 114b may be a connection port that may be configured to transmit and receive data files such as media files or customer order files from a remote data source and / or transmit and receive power from an external power source. For example, the I / O component 114b may be a proprietary port such as the Lightning jack of Apple Inc. (Cupertino, California). TM The electronic device 100 may further 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.

[0121] The electronic device 100 may further include at least one tactile or tactile output component 112c (e.g., a roller), a camera and / or scanner input component 110h (e.g., a video camera or still camera, and / or a barcode scanner or any other suitable scanner that can obtain product identification information from a code such as a barcode, QR code, etc.), a biometric input component 110i (e.g., a fingerprint reader or other feature recognition sensor that operates in conjunction with a feature processing application accessible to the electronic device 100 for authenticating a user). Figure 4 As shown, at least a portion of the biometric input component 110i can be incorporated into or otherwise combined with the input component 110a of the device 100 or any other suitable input component 110. For example, the biometric input component 110i can be a fingerprint reader that can be configured to scan the fingerprint of a user's finger when the user interacts with the input component 110a by pressing the mechanical input component 110a with the user's finger. As another example, the biometric input component 110i can be a fingerprint reader that can be combined with the touch input component 110f of the touch screen I / O component 114a, so that the biometric input component 110i can be configured to scan the fingerprint of the finger when the user interacts with the touch screen input component 110f by pressing the touch screen input component 110f with the user's finger or sliding along the touch screen input component 110f. In addition, as described above, the electronic device 100 can also include a fingerprint reader that can be read by the subsystem 200 via the antenna 116 and / or the antenna 134 ( Figure 41. The NFC component 120 may be communicatively accessed by the housing 101 (not shown). The NFC component 120 may be located at least partially within the housing 101, and a marking or symbol 121 may be provided on the exterior of the housing 101 that may identify the general location of one or more antennas associated with the NFC component 120 (e.g., the general location of the antenna 116 and / or the antenna 134).

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

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

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

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

[0126] As mentioned, the input components 110 of the device 100 (e.g., input component 110f) may include a touch input component that can receive touch input for interacting with other components of the device 100 via a wired or wireless bus 118. Such a touch input component 110 can 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.

[0127] The touch input component 110 may include a touch-sensitive panel that may be fully transparent or partially transparent, translucent, non-transparent, opaque, or any combination thereof. The touch input component 110 may be implemented as a touch screen, a touchpad, a touch screen that acts as a touchpad (e.g., a touch screen that replaces the touchpad of a laptop), a touch screen or touchpad combined or incorporated with any other input device (e.g., a touch screen or touchpad provided on a keyboard), or any multi-dimensional object having a touch-sensitive surface for receiving touch input. In some embodiments, the terms touch screen and touchpad are used interchangeably.

[0128] In some embodiments, the touch input component 110 implemented as a touch screen can include a transparent and / or translucent touch-sensitive panel positioned partially or completely above, below, and / or within at least a portion of a display (e.g., display output component 112a). In other embodiments, the touch input component 110 can be implemented as an integrated touch screen, in which the touch-sensitive component / device is integral with the display component / device. In other embodiments, the touch input component 110 can be used as a supplemental display or additional display for displaying supplemental graphical data or the same graphical data as the primary display and for receiving touch input.

[0129] Touch input component 110 can be configured to detect the location of one or more touches or near-touches based on capacitive, resistive, optical, acoustic, inductive, mechanical, or chemical measurements, or any phenomenon measurable relative to one or more touches or near-touches occurring near input component 110. Software, hardware, firmware, or any combination thereof can be used to process the measurements of the detected touches to identify and track one or more gestures. A gesture can correspond to stationary or non-stationary, single or multiple touches or near-touches on touch input component 110. A gesture can be performed by moving one or more fingers or other objects on touch input component 110 substantially simultaneously, continuously, or sequentially in a particular manner, such as by tapping, pressing, shaking, rubbing, rotating, twisting, changing orientation, pressing with varying pressure, and the like. A gesture can be characterized by, but not limited to, pinching, dragging, sliding, swiping, rotating, flexing, dragging, or tapping between fingers or with any other finger or fingers. One or more users can perform a single gesture using one or more hands, or any combination thereof.

[0130] As mentioned, electronic device 100 may utilize graphical data to drive a display (e.g., display output component 112a) to display a graphical user interface ("GUI") 180. GUI 180 may be configured to receive touch input via touch input component 110f. Implemented as a touch screen (e.g., utilizing display output component 112a as I / O component 114a), touch I / O component 110f may display GUI 180. Alternatively, GUI 180 may be displayed on a display (e.g., display output component 112a) separate from touch input component 110f. GUI 180 may include graphical elements displayed at specific locations within the interface. Graphical elements may include, but are not limited to, various displayed virtual input devices, including a virtual scroll wheel, a virtual keyboard, a virtual knob, virtual buttons, any virtual user interface ("UI"), and the like. A user may perform gestures at one or more specific locations on touch input component 110f that may be associated with graphical elements of GUI 180. In other embodiments, a user may perform gestures at one or more locations independent of the location of graphical elements of GUI 180. Gestures performed on touch input component 110 may directly or indirectly manipulate, control, modify, move, actuate, initiate, or generally affect graphical elements within the GUI, such as a cursor, icon, media file, list, text, all or part of an image, and the like. For example, with a touch screen, a user may interact directly with a graphical element by performing a gesture over the graphical element on the touch screen. Alternatively, a touchpad may generally provide indirect interaction. Gestures may also affect non-displayed GUI elements (e.g., causing a user interface to appear) or may affect other actions of device 100 (e.g., affecting the state or mode of a GUI, application, or operating system). Gestures may be performed on touch I / O device component 110 with or without a displayed cursor. For example, when performing gestures on a touchpad, a cursor or pointer may be displayed on a display screen or touch screen, and the cursor or pointer may be controlled via touch input on the touchpad to interact with graphical objects on the display screen. Alternatively, when performing gestures directly on the touch screen, the user can interact directly with objects on the touch screen, regardless of whether a cursor or pointer is displayed on the touch screen. Feedback can be provided to the user via bus 118 in response to or based on a touch or near-touch on touch input component 110. Feedback can be transmitted optically, mechanically, electrically, olfactory, acoustically, or any combination thereof, and in a variable or non-variable manner.

[0131] Further applications of the concept

[0132] Although systems, methods, and computer-readable media for recommending payment credentials have been described, it should be understood that numerous modifications may be made thereto without departing in any way from the spirit and scope of the subject matter described herein. Insubstantial variations of the claimed subject matter, whether now known or later devised, considered by one of ordinary skill in the art to be equivalently within the scope of the claims are expressly contemplated. Therefore, obvious substitutions now or later known to one of ordinary skill in the art are defined to be within the scope of the defined elements.

[0133] Therefore, those skilled in the art will appreciate that the present invention can be practiced by embodiments other than those described, which are provided for purposes of illustration and not limitation.

Claims

1. A method comprising: At an electronic device comprising a memory, a separate secure element having at least one payment credential, a communication component, and a near field communication antenna: accessing credential availability data indicative of the at least one payment credential; receiving, in response to the electronic device being within a specified distance of a beacon device associated with a merchant subsystem and receiving merchant context data associated with the merchant subsystem via a broadcast message from the beacon device associated with the merchant subsystem, wherein the merchant context data indicates a merchant subsystem preference having the merchant subsystem, the merchant subsystem preference being a preference for a first type of payment credential accepted by the merchant subsystem relative to a second type of payment credential accepted by the merchant subsystem, the broadcast message being received via the communication component; automatically switching, at the electronic device, a default payment credential stored for a transaction with the wireless terminal of the merchant subsystem to either the first type of payment credential or the second type of payment credential based at least in part on the accessed credential availability data and the received merchant context data; presenting the default payment credential as a recommended payment credential for transactions with the wireless terminal of the merchant subsystem; at the electronic device, in response to presenting the default payment credential as the recommended payment credential for the transaction, receiving a user selection of the presented default payment credential; in response to receiving the user selection, transmitting the default payment credential to the merchant subsystem using the secure element and via the near field communication antenna; as well as The default payment credentials are stored in the secure element.

2. The method of claim 1 , further comprising accessing user preference data at the electronic device, wherein automatically switching comprises automatically switching based further at least in part on the accessed credential availability data, the received merchant context data, and the accessed user preference data. 3 . The method of claim 1 , wherein the merchant context data is received via an online merchant application running on the electronic device. The method of claim 1 , wherein the merchant context data is received by the electronic device directly from the merchant subsystem.

5. The method according to claim 1, wherein: The at least one payment credential includes a payment credential of the first type and a payment credential of the second type; and The presented default payment credential includes information recommending use of the first type of payment credential before the second type of payment credential.

6. The method according to claim 1, wherein: The at least one payment credential includes a payment credential of the first type and a payment credential of the second type; and The presented default payment credential includes information indicating the first type of payment credential rather than the second type of payment credential.

7. The method according to claim 1, wherein: The at least one payment credential includes a payment credential of the first type, a payment credential of the second type, and a payment credential of a third type; and The presented default payment credential includes information indicating the first type of payment credential rather than the third type of payment credential.

8. The method according to claim 1, wherein: the at least one payment credential includes a payment credential of the first type but does not include a payment credential of the second type; and The presented default payment credentials include information indicating the first type of payment credentials and information indicating the second type of payment credentials.

9. The method of claim 1, wherein the presented default payment credential includes information describing a benefit of using the first type of payment credential.

10. A device comprising: Memory; a secure element separate from the memory, the secure element including at least one payment credential; Communication components; Near field communication antenna; and at least one processor configured to: receiving, in response to the device being within a specified distance of a beacon device associated with a merchant subsystem, merchant context data associated with the merchant subsystem via a broadcast message from the beacon device associated with the merchant subsystem and via the communication component, wherein the merchant context data indicates a merchant subsystem preference of the merchant subsystem for a first type of payment credential over a second type of payment credential, both the first type of payment credential and the second type of payment credential being accepted by the merchant subsystem; accessing credential availability data indicative of the at least one payment credential; automatically switching, at the device, a default payment credential stored for a transaction with the wireless terminal of the merchant subsystem to either the first type of payment credential or the second type of payment credential based at least in part on the accessed credential availability data and the received merchant context data; presenting the default payment credential as a recommended payment credential for transactions with the wireless terminal of the merchant subsystem; receiving a user selection of the default payment credential in response to presenting the default payment credential as the recommended payment credential for the transaction; in response to receiving the user selection, transmitting the default payment credential to the merchant subsystem using the secure element and via the near field communication antenna; as well as The default payment credentials are stored in the secure element.

11. The apparatus of claim 10, wherein the at least one processor is further configured to: access user preference data; and Automatic switching is further performed based at least in part on the accessed credential availability data, the received merchant context data, and the accessed user preference data.

12. The apparatus of claim 10, wherein: The at least one payment credential includes a payment credential of the first type and a payment credential of the second type; and The presented default payment credential includes information recommending use of the first type of payment credential before the second type of payment credential.

13. The apparatus of claim 10, wherein: The at least one payment credential includes a payment credential of the first type and a payment credential of the second type; and The presented default payment credential includes information indicating the first type of payment credential rather than the second type of payment credential.

14. The apparatus of claim 10, wherein: The at least one payment credential includes a payment credential of the first type, a payment credential of the second type, and a payment credential of a third type; and The presented default payment credential includes information indicating the first type of payment credential rather than the third type of payment credential.

15. The apparatus of claim 10, wherein: the at least one payment credential includes a payment credential of the first type but does not include a payment credential of the second type; and The presented default payment credentials include information indicating the first type of payment credentials and information indicating the second type of payment credentials.

16. The device of claim 10, wherein the at least one processor is configured to receive the merchant context data directly from the merchant subsystem.

17. The device of claim 10, wherein the merchant context data is received via an online merchant application running on the device.

18. The device of claim 10, wherein the presented default payment credential includes information describing a benefit of using the first type of payment credential.

19. A non-transitory computer-readable medium having computer-readable instructions recorded thereon, the computer-readable instructions, when executed by one or more processors of an electronic device comprising a memory, a separate secure element having at least one payment credential, a communication component, and a near-field communication antenna, causing the one or more processors to perform operations comprising: receiving, in response to the electronic device being within a specified distance of a beacon device associated with a merchant subsystem, merchant context data associated with the merchant subsystem via a broadcast message from the beacon device associated with the merchant subsystem and via the communication component, wherein the merchant context data indicates a merchant subsystem preference having the merchant subsystem, the merchant subsystem preference being a preference for a first type of payment credential accepted by the merchant subsystem relative to a second type of payment credential accepted by the merchant subsystem; accessing credential availability data indicative of the at least one payment credential; automatically switching, at the electronic device, a default payment credential stored for a transaction with a wireless terminal of the merchant subsystem to a payment credential of the first type or a payment credential of the second type based at least in part on the accessed credential availability data and the received merchant context data, the wireless terminal being separate from the beacon device; presenting the default payment credential as a recommended payment credential for transactions with the wireless terminal of the merchant subsystem; at the electronic device, in response to presenting the default payment credential as the recommended payment credential for the transaction, receiving a user selection of the presented default payment credential; in response to receiving the user selection, transmitting the default payment credential to the merchant subsystem using the secure element and via the near field communication antenna; as well as The default payment credentials are stored in the secure element.

20. The method of claim 1 , wherein automatically switching, at the electronic device, the default payment credential for transactions with the merchant subsystem to the first type of payment credential or the second type of payment credential based at least in part on the accessed credential availability data and the received merchant context data further comprises: determining, based at least in part on the received merchant context data, that the merchant subsystem prefers the first type of payment credential; determining, based at least in part on the accessed credential availability data, that the default payment credential stored for transactions with the merchant subsystem corresponds to the second type of payment credential; as well as In response to determining that the stored default payment credential corresponds to the second type of payment credential, automatically switching the default payment credential for transactions with the merchant subsystem to the first type of payment credential.

21. The method of claim 1 , wherein in response to the electronic device being within the specific distance of the beacon device associated with the merchant subsystem and receiving merchant context data associated with the merchant subsystem via the broadcast message from the beacon device associated with the merchant subsystem further comprises: In response to the electronic device being within the specific distance of the beacon device associated with the merchant subsystem, the beacon device being separated from the wireless terminal and physically co-located with the wireless terminal at the same physical location associated with the merchant subsystem, and receiving merchant context data associated with the merchant subsystem via the broadcast message from the beacon device associated with the merchant subsystem.

Images