Verify online access to safety device functionality

Abstract

The present disclosure relates to authenticating online access to secure device functionality. Systems, methods, and computer-readable media for authenticating online access to secure device functionality are provided, which can use shared secrets between different subsystems and limited-use authentication data.

Description

[0001] This application is a divisional application of invention patent application No. 201780008311.4, filed on January 3, 2017, and entitled “Verifying Online Access to Security Device Functionality”. Technical Field

[0002] The present disclosure relates to authenticating online access to secure device functionality, and more particularly, to authenticating a third party subsystem for enabling online access by the third party subsystem to secure functionality of an electronic device. Background Art

[0003] Portable electronic devices (e.g., cellular phones) may be equipped with near field communication ("NFC") components for contactless proximity-based communication of sensitive data with another entity (e.g., a merchant), such as data transactions that require the electronic device to generate, access, and / or share native payment credentials (such as credit card credentials) with other entities. However, electronic devices are often ineffective in securely using such native payment credentials in other types of communications (e.g., online transactions). Summary of the invention

[0004] This document describes systems, methods, and computer-readable media for verifying online access to secure device functionality.

[0005] As an example, a method for using a commercial entity subsystem to conduct a secure transaction between the merchant subsystem and an electronic device communicatively coupled to the merchant subsystem via a merchant online resource may be provided. The method may include: at the commercial entity subsystem, receiving a verification request for the merchant online resource from the merchant subsystem; verifying the merchant online resource using the verification request and registration data, the registration data having been initially made available to the commercial entity subsystem prior to receiving; after the verification, generating verification data associated with at least a portion of the verification request; transmitting the verification data to the electronic device; receiving device transaction data from the electronic device; determining that the device transaction data includes the verification data; and after the determination, generating secure transaction data for use by the merchant subsystem based on the device transaction data.

[0006] As another example, a method for using a management entity subsystem to conduct a secure transaction between a processing subsystem and an electronic device communicatively coupled to the processing subsystem via an online resource executed on an electronic device may be provided. The method may include: receiving, at the management entity subsystem, a verification request for the online resource, wherein the verification request includes verification request data; verifying the online resource using the verification request data and registration data, wherein the registration data has been initially made available to the management entity subsystem prior to receiving the verification request; associating verification response data with at least a portion of the verification request data; after verifying the online resource, transmitting the verification response data to the electronic device; after transmitting the verification response data to the electronic device, receiving device transaction data from the electronic device; verifying the device transaction data using the verification response data; and after verifying the device transaction data, generating secure transaction data based on the device transaction data for use by the processing subsystem.

[0007] As another example, a method for using a management entity subsystem to implement a secure transaction between a processing subsystem and an electronic device communicatively coupled to the processing subsystem via an online resource executed on an electronic device may be provided. The method may include: registering the online resource at the management entity subsystem, wherein the registration includes establishing a processing shared secret between the management entity subsystem and the processing subsystem; receiving a verification request for the online resource, wherein the verification request includes a processing identifier indicating the online resource, and wherein the verification request also includes a verification session identifier unique to a potential transaction between the electronic device and the processing subsystem via the online resource; and using the verification session identifier and the processing shared secret to verify the online resource indicated by the processing identifier.

[0008] As another example, a method for using a management entity subsystem to conduct a secure transaction between a processing subsystem and an electronic device communicatively coupled to the processing subsystem via an online resource executed on an electronic device may be provided. The method may include: receiving, at the management entity subsystem, a verification request for the online resource, wherein the verification request includes verification request data, and wherein the verification request data includes potential transaction identification information, the potential transaction identification information indicating a potential transaction between the electronic device and the processing subsystem via the online resource; using at least a portion of the verification request data to verify the online resource; associating verification response data with at least the potential transaction identification information; after the online resource has been verified, transmitting the verification response data to the electronic device; after the verification response data has been transmitted to the electronic device, receiving device transaction data from the electronic device; using the verification response data and the potential transaction identification information to verify the device transaction data; and after the device transaction data has been verified, generating secure transaction data based on the device transaction data for use by the processing subsystem.

[0009] The present disclosure is intended only to summarize some exemplary embodiments in order to provide a basic understanding of some aspects of the object described in this document. Therefore, it should be understood that the features described in this disclosure are only examples and should not be construed as limiting the spirit and scope of the object described in this document in any way. Unless otherwise stated, the features described in the context of an example may be combined or used with the features described in the context of one or more other examples. Other features, aspects, and advantages of the object described in this document will be apparent from the following detailed description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The following discussion refers to the following drawings, in which like reference numerals may refer to like parts throughout the drawings, and in which:

[0011] Figure 1 is a schematic diagram of an illustrative system for verifying online access to functionality of a security device;

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

[0013] Figure 2 yes Figure 1 and Figure 1A A more detailed schematic diagram of an exemplary electronic device of the system;

[0014] Figure 2A yes Figure 1 to Figure 2 Another more detailed schematic diagram of an exemplary electronic device of the system;

[0015] Figure 3 yes Figures 1 to 2A A front view of an exemplary electronic device;

[0016] FIG. 3A to FIG. 3D yes Figures 1 to 3 a front view of a screen of a graphical user interface of one or more exemplary electronic devices of the present invention, showing a procedure for verifying online access to security device functionality;

[0017] Figure 4 yes Figure 1 and Figure 1A A more detailed schematic diagram of an exemplary business entity subsystem of the system; and

[0018] Figures 5 to 9 is a flow chart of an illustrative procedure for verifying online access to security device functionality. DETAILED DESCRIPTION

[0019] Prior to a front-line resource (e.g., a native application or website) using a processing (or merchant) subsystem (with or without a partner payment service provider ("PSP") embedded payment form) securely receiving sensitive data (e.g., secure element payment credential data) from a user electronic device, the processing subsystem (with or without a PSP) may be authenticated by a trusted administrative (or commercial) entity subsystem. Additionally, in addition to authenticating the online resource before the online resource is operable to present the user device with an option to share sensitive data with the processing subsystem in a transaction, an additional session authentication procedure may also be implemented in response to selecting this option to reauthorize the online resource for use in implementing the particular transaction.

[0020] Figure 1 and Figure 1A A system 1 is shown in which one or more credentials may be configured onto an electronic device 100 from a financial institution (or transaction or issuer) subsystem 350 in conjunction with a commercial (or administrative) entity subsystem 400, and in which such credentials may be used by the electronic device 100 to conduct transactions (e.g., financial transactions or any other suitable secure data transactions) with a merchant (or processing) subsystem 200 and an associated acquiring bank (or acquirer) subsystem 300 (e.g., electronic device 100 security device functionality); and Figures 2 to 3 presents further details regarding a particular implementation of the electronic device 100 of the system 1; FIG. 3A to FIG. 3D Exemplary screens 190a through 190d are shown that may represent a graphical user interface of the electronic device 100 of the system 1 during such a transaction; Figure 4 presenting further details regarding a particular embodiment of the commercial entity subsystem 400 of system 1; and Figures 5 to 9is a flow chart of an illustrative procedure for verifying online access to security device functionality (eg, to conduct such a financial transaction).

[0021] Figure 1 Description

[0022] Figure 1 is a schematic diagram of an illustrative system 1 that may allow authentication of a third-party subsystem for enabling online access to an electronic device by the third-party subsystem, such as authentication of a merchant (or processing) subsystem for enabling secure use of credentials on an electronic device in a transaction (e.g., online payment or contactless proximity-based payment) with the merchant subsystem. Figure 1 As shown in FIG. 1 , system 1 may include an electronic device 100 and a commercial (or management) entity subsystem 400 and a financial institution (or transaction or issuer) subsystem 350 for securely configuring one or more credentials on the electronic device 100. Figure 1 As shown in FIG. 1 , system 1 may also include a merchant (or processing) subsystem 200, whereby such configured credentials may be used by electronic device 100 for conducting transactions (e.g., financial transactions or any other suitable secure data transactions) with merchant subsystem 200. For example, in response to receiving potential transaction data from merchant subsystem 200, electronic device 100 may share the secure device data of the configured credentials with merchant subsystem 200 as a contactless proximity-based communication 5 (e.g., near field communication or Bluetooth®). TM The system 1 may also include an acquiring bank (or acquirer) subsystem 300, which may utilize such contactless proximity-based communications 5 and / or such online-based communications 684 to complete the transaction with the financial institution subsystem 350.

[0023] System 1 may include: a communication path 15 for implementing communication between the electronic device 100 and the merchant subsystem 200; a communication path 25 for implementing communication between the merchant subsystem 200 and the acquiring bank subsystem 300; a communication path 35 for implementing communication between the acquiring bank subsystem 300 and the financial institution subsystem 350; a communication path 45 for implementing communication between the payment network subsystem 360 of the financial institution subsystem 350 and the issuing bank subsystem 370 of the financial institution subsystem 350; a communication path 55 for implementing communication between the financial institution subsystem 350 and the commercial entity subsystem 400; a communication path 65 for implementing communication between the commercial entity subsystem 400 and the electronic device 100; a communication path 75 for implementing communication between the financial institution subsystem 350 and the electronic device 100; and a communication path 85 for implementing communication between the commercial entity subsystem 400 and the merchant subsystem 200. One or more of paths 15, 25, 35, 45, 55, 65, 75, and 85 may be managed, at least in part, by one or more trusted service managers ("TSMs"). Any suitable circuitry, devices, systems, or combinations thereof operable to establish a communication network (e.g., a wired and / or wireless communication infrastructure, which may include one or more communication towers, telecommunications servers, or the like) may be used to provide one or more of paths 15, 25, 35, 45, 55, 65, 75, and 85, which may be capable of providing communications using any suitable wired or wireless communication protocol. For example, one or more of paths 15, 25, 35, 45, 55, 65, 75, and 85 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, 2.4GHz, and 5.6GHz communication systems), infrared, TCP / IP, SCTP, DHCP, HTTP, BitTorrent TM , FTP, RTP, RTSP, RTCP, RAOP, RDTP, UDP, SSH, WDS bridging, any communication protocol that can be used by wireless and cellular phones and personal email devices (e.g., 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.

[0024] Figure 1A Description

[0025] Reference now Figure 1A , Figure 1A Show above about Figure 1 A more detailed view of the described system 1. Figure 1A As shown in , for example, the electronic device 100 may include a processor 102, a communication component 106, and / or a near field communication (“NFC”) component 120. The NFC component 120 may include or otherwise provide a secure element 145, which 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 cryptographic 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 set forth in accordance with rules and security requirements that may be set forth by a set of properly identified trusted authorities (e.g., authorities of financial institution subsystems and / or industry standards, such as GlobalPlatform). Figure 1AAs described in more detail below, a credential applet or payment application on a secure element 145 of device 100 (e.g., of NFC component 120) may be configured to provide payment credential data as transaction data containing sufficient details for identifying a funding account or other financial instrument or source of credit (e.g., at financial institution subsystem 350), wherein such payment credential data may be used by device 100 in one or more communications with merchant subsystem 200 and / or commercial entity subsystem 400 to facilitate a financial transaction. NFC component 120 may be configured to communicate such host payment credential data as contactless proximity-based communication 5 (e.g., near field communication) with merchant subsystem 200 (e.g., with merchant terminal 220 of merchant subsystem 200, which may be located in a brick and mortar store or any physical location where a user of device 100 may use credentials stored on device 100 to conduct a financial transaction with the proximally located merchant terminal 220 via contactless proximity-based communication). Alternatively or in addition, communication component 106 may be provided to allow device 100 to communicate any suitable payment credential data (e.g., as online-based communication 684) with one or more other electronic devices or servers or subsystems (e.g., one or more subsystems or other components of system 1, such as with merchant server 210 of merchant subsystem 200 via any suitable online communication) using any suitable wired or wireless protocol (e.g., via one or more of communication paths 15, 65, and / or 75). Processor 102 of device 100 may include any processing circuitry operable to control the operation and performance of one or more components of device 100. For example, processor 102 may be configured to run one or more applications (e.g., application 103 and / or online resource or merchant application 113) on device 100, which may at least partially specify the manner in which data (e.g., payment credential data of transaction data) may be transmitted by device 100 for funding financial transactions with merchant subsystem 200. In addition, as Figure 1A , device 100 may include any suitable device identification information or device identifier 119 accessible to processor 102 or any other suitable portion of device 100. Device identification information 119 may be utilized by commercial entity subsystem 400 and / or merchant subsystem 200 and / or financial institution subsystem 350 to uniquely identify device 100 to facilitate transactions with merchant subsystem 200 and / or to enable any suitable secure communications with device 100. As just one example, device identification information 119 may be a phone number or email address or any unique identifier that may be associated with device 100.

[0026] The merchant subsystem 200 may include any suitable merchant server 210, such as Figure 1A , which may include any suitable components or subsystems that may be configured to communicate via any suitable communication protocol (e.g., Wi-Fi, Bluetooth TM , cellular, wired network protocols, etc.) to communicate any suitable data with: a communication component of commercial entity subsystem 400 (e.g., via communication path 85); and / or a communication component of acquiring bank 300 (e.g., via communication path 25); and / or a communication component of device 100 (e.g., via communication path 15). For example, merchant server 210 may be operable to communicate potential transaction data 660 with communication component 106 of device 100 within any suitable online content context, such as when a user of device 100 communicates with merchant server 210 to conduct a transaction via any suitable merchant online resource 113 that may be run on device 100, such as a third-party merchant application 113 running on device 100, which may be managed by merchant server 210 (e.g., a native application), or a merchant online resource 113 is an Internet application 113 running on device 100 (e.g., Safari provided by Apple Inc.). TM ), which may point to a uniform resource locator (“URL”) of a target or web resource that may be managed by the merchant server 210 (e.g., a merchant website, a merchant application using a web page directed to the merchant website (e.g., an Internet browser bundled within a merchant application, thereby creating what may be referred to as a hybrid app, which may enable the use of web technologies (e.g., HTML, JavaScript, CSS, etc.) to build this application, but still enable the packaging of this application as a native application), and / or a non-merchant application using a web page directed to the merchant website). Therefore, it should be noted that communication between the merchant server 210 and the device 100 may occur wirelessly and / or via a wired path (e.g., over the Internet). The merchant server 210 may be provided by the merchant of the merchant subsystem 200 (e.g., as a website server that hosts website data and / or manages third-party application data). In addition or alternatively, such as Figure 1A As shown in , the merchant subsystem 200 may include any suitable merchant terminal 220 (e.g., a merchant payment terminal), which may include any suitable components or subsystems that can be configured to communicate any suitable data with the contactless proximity-based communication component of the device 100 (e.g., the contactless proximity-based communication 5 of the NFC component 120 of the device 100). In addition, as Figure 1A As shown in FIG. 1 , the merchant subsystem 200 may include a merchant key 157 and / or a merchant identifier (“ID”) 167. Although not shown, the merchant subsystem 200 may also include: a merchant processor component, which may be the same as or similar to Figure 1A and Figure 2 The processor component 102 of the electronic device 100; the merchant communication component, which may be the same as or similar to Figure 1A and Figure 2 The communication component 106 of the electronic device 100 (e.g., as part of the server 210); the merchant I / O interface, which may be the same as or similar to Figure 2 The I / O interface 114 of the electronic device 100; the merchant bus, which may be the same as or similar to Figure 2 The bus 118 of the electronic device 100; the merchant memory component, which may be the same as or similar to Figure 2 The memory component 104 of the electronic device 100 and / or the merchant power supply component may be the same as or similar to Figure 2 The power supply component 108 of the electronic device 100 is shown in FIG.

[0027] The financial institution subsystem 350 may include a payment network subsystem 360 (e.g., a 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 may bear primary responsibility for the consumer's ability to pay off debts incurred with a particular credential. Each particular credential applet of the NFC component 120 of the device 100 may be associated with a particular payment card that may be electronically linked to one or more accounts of a particular user. Various types of payment cards may be suitable, including credit cards, debit cards, charge cards, stored value cards, fleet cards, gift cards, and the like. A commercial credential for a particular payment card may be configured on device 100 by issuing bank subsystem 370 (e.g., as a credential of a credential supplemental security domain of NFC component 120, as described below) for use in commercial credential data communications (e.g., contactless proximity-based communications and / or online-based communications) with merchant subsystem 200 (e.g., directly or via commercial entity subsystem 400). Each credential may be a particular brand of payment card branded by payment network subsystem 360. Payment network subsystem 360 may be a network of various issuing banks 370 and / or various acquiring banks 300 that may process the use of a particular brand of payment card (e.g., commercial credential).

[0028] In order for a financial transaction to occur within system 1, at least one business credential must be securely configured on a secure element of electronic device 100. For example, such business credentials may be at least partially configured on secure element 145 of device 100 directly from financial institution subsystem 350 (e.g., as credential data 654, which may be communicated to secure element 145 via communication component 106 via communication path 75 between financial institution subsystem 350 and device 100). Additionally or alternatively, such business credentials may be at least partially configured on secure element 145 of device 100 from financial institution subsystem 350 via commercial entity subsystem 400 (e.g., as credential data 654, which 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 to secure element 145 from communication component 106). Credential data 654 may be configured on secure element 145 of device 100 via path 75 and / or via path 55 / 65 as at least a portion or all of a credential supplemental security domain of the secure element, and may include a credential applet containing credential information and / or credential keys, such as credential applet 153a or a payment application containing credential information 161a and credential keys 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 generating, exchanging, storing, using, and replacing such credential. Financial institution subsystem 350 may store its version of credential key 155a' in a secure element of financial institution subsystem 350. It should be understood that the credential key 155a' of the device 100 and the financial institution subsystem 350 can be any suitable shared secret (e.g., a password, a passphrase, a randomly selected byte array, one or more symmetric keys, a public-private key (e.g., an asymmetric key), etc.) that can be used by both the security element of the electronic device 100 and the financial institution subsystem 350, and both the security element of the electronic device 100 and the financial institution subsystem 350 can be operated to enable the electronic device 100 and the financial institution subsystem 350 to independently generate any suitable cryptographic data (e.g., a cryptogram) or any other suitable data (e.g., for verifying payment data for a financial transaction), such as by using any suitable cryptographic algorithm or cipher, and the functional output of the cryptographic algorithm or cipher can be determined at least in part by the shared secret, wherein this shared secret can be configured on the device 100 by the financial institution subsystem 350. A shared secret may be shared in advance between the financial institution subsystem 350 and the device 100 (e.g., during configuration of credentials on the device 100 by the financial institution subsystem 350), in which case such a shared secret may be referred to as a pre-shared key, or may be established by using a key agreement protocol (e.g., using public-key cryptography, such as Diffie-Hellman; or using symmetric-key cryptography, such as Kerberos) before the shared secret is used for a particular financial transaction. The secure element of the device 100 may access the shared secret and any suitable cryptographic algorithm or encryption method that may determine its functional output at least in part through the shared secret.

[0029] Commercial entity subsystem 400 may be provided as an intermediary between financial institution subsystem 350 and device 100, wherein commercial entity subsystem 400 may be configured to provide a new layer of security and / or provide a smoother user experience when credentials are configured on a secure element of device 100 and / or when such configured credentials are used as part of commerce credential data communications between device 100 and merchant subsystem 200. Commercial entity subsystem 400 may be provided by a particular commercial entity that may provide various services to users of device 100 via user-specific login information for a user-specific account of that commercial entity (e.g., via a user-specific identification and password combination). As just one example, commercial entity subsystem 400 may be provided by Apple Inc. (Cupertino, CA), which may also be a provider of various services to users of device 100 (e.g., an iTunes service 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 and / or associating multiple user devices and / or multiple user profiles with each other TM services, the Apple Online Store for online purchases of various Apple products, and Apple iMessage for sending media messages between devices TM services, etc.), and it may also be the provider, manufacturer and / or developer of the device 100 itself and / or the operating system of the device 100 (e.g., the device application 103) (e.g., when the device 100 is an iPod TM , iPad TM 、Phone TMor the like). 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 provision and / or manage any credit card or any other commercial credential to be configured on the end-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 contactless proximity-based communications, a third-party application or online resource 113 for online communications, and / or any other aspect of the merchant subsystem 200. Such a business entity may take advantage of the potential capabilities of its configuration or control of various components of device 100 (e.g., software and / or hardware components of device 100, such as when that business entity may at least partially produce or manage device 100) to provide a more seamless user experience for the user of device 100 when the user of device 100 desires to configure credentials provided by financial institution subsystem 350 on device 100 and / or when such configured credentials are being used as part of business credential data communications with merchant subsystem 200 to provide funding for financial transactions. For example, in some embodiments, device 100 may be configured to communicate with business entity subsystem 400 (e.g., via communication path 65) in a manner that is seamless and transparent to the user of device 100 for sharing or receiving certain data that may achieve a higher level of security (e.g., during secure data communications on an online basis between device 100 and merchant subsystem 200). Although not shown, business entity subsystem 400 may also include: a processor component, which may be the same as or similar to a processor component; Figure 1A and Figure 2 The processor component 102 of the electronic device 100; the communication component, which may be the same as or similar to Figure 1A and Figure 2 The communication component 106 of the electronic device 100; I / O interface, which may be the same as or similar to Figure 2 The I / O interface 114 of the electronic device 100; a bus, which may be the same as or similar to Figure 2 The bus 118 of the electronic device 100; the memory component, which may be the same as or similar to Figure 2 The memory component 104 of the electronic device 100 and / or the power supply component may be the same as or similar to Figure 2The power supply component 108 of the electronic device 100 may be at least partially provided by one, some or all of the servers 410.

[0030] In addition to at least the business credentials being configured on the secure element of device 100 (e.g., as part of a credential SSD containing credential key 155a' and credential information 161a), at least an access SSD containing access key 155b may also be configured on the secure element of device 100 to enable device 100 to conduct financial transactions with merchant subsystem 200 in a more secure manner. For example, the access SSD may be at least partially configured on the secure element of device 100 directly from commercial entity subsystem 400 (e.g., as access data 652, via a 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 to secure element 145). Access data 652 may be configured on the secure component of device 100 via path 65 as at least a portion or all of the access SSD, and may include access applet 153b containing access key 155b. As shown in FIG. Figure 1A , commercial entity subsystem 400 may also access access key 155b (e.g., for use in 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 generating, exchanging, storing, using, and replacing such keys. Commercial entity subsystem 400 may store its version of access key 155b in a secure element of commercial entity subsystem 400. An access SSD of device 100 containing access key 155b may be configured to determine the intent and local authentication of a user of device 100 (e.g., via one or more input components 110 of device 100, such as a biometric input component), and in response to such determination, may be configured to enable another specific SSD for conducting a payment transaction (e.g., using credentials of a credential SSD of device 100). By storing this access SSD within the secure element of device 100, the ability to reliably determine the intent and authentication of a user for a financial transaction may be increased. Additionally, access key 155b of this access SSD of device 100 may be utilized to provide enhanced encryption for external transaction data that may be transmitted to the secure element of device 100. Additionally or alternatively, as described below, access data 652 may include an issuer security domain (“ISD”) key 156k of the ISD for the secure element of electronic device 100, which may also be maintained by commercial entity subsystem 400 and may use ISD key 156k in addition to or as a replacement for access key 155b, as described below.

[0031] Merchant applications or online resources 113 may be accessed by device 100 to effectuate online financial transactions between device 100 and merchant subsystem 200, or to effectuate online access to any other suitable secure device functionality of device 100 by merchant subsystem 200. First, before application 113 may be effectively utilized by device 100, application 113 may be approved or registered or otherwise enabled by commercial entity subsystem 400. For example, application store 420 (e.g., Apple App Store TM) may receive at least some data representing application 113 from merchant subsystem 200 via communication path 85. Additionally, in some embodiments, commercial entity subsystem 400 may generate or otherwise assign a merchant key 157 for application 113, and may provide this 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 may provide this 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 key 157, which may include generating, exchanging, storing, using, and replacing this key. Regardless of how or where this merchant key 157 may be generated and managed, both merchant subsystem 200 and commercial entity subsystem 400 may store versions of merchant key 157 (e.g., in respective secure elements of merchant subsystem 200 and commercial entity subsystem 400, where, in some embodiments, the merchant key 157 stored by merchant subsystem 200 may be a private key and the merchant key 157 stored by commercial entity subsystem 400 may be a corresponding public key (e.g., for use in an asymmetric key encryption / decryption procedure)). In some embodiments, this merchant key 157 may be specifically associated with merchant application 113, while in other embodiments, merchant key 157 may be specifically associated with a merchant of merchant subsystem 200, such that merchant key 157 may be associated with multiple third-party applications or web resources operated by the same merchant of merchant subsystem 200. A unique merchant identifier 167 may be generated and / or otherwise assigned to or associated with an application 113 by commercial entity subsystem 400 and / or by merchant subsystem 200. For example, merchant identifier 167 may be an alphanumeric string, a domain (e.g., a URL or otherwise for a web resource type online resource application 113), or any other suitable identifier that may uniquely identify a merchant and / or a particular merchant online resource (e.g., so uniquely identified to commercial entity subsystem 400). A table 430 or any other suitable data structure or source of information accessible to commercial entity subsystem 400 may be provided for associating a particular merchant key 157 with a particular merchant identifier 167 or merchant entity of a merchant application 113. A merchant online resource may be associated with a particular merchant identifier 167 and a particular merchant key 157, each of which may be securely shared between merchant subsystem 200 and commercial entity subsystem 400.Table 430 may enable commercial entity subsystem 400 to determine and utilize an appropriate merchant key 157 for providing a layer of security to any secure device data (e.g., commerce credential data, which may include device 100 native payment credential data) transmitted to merchant subsystem 200 for transactions that may involve device 100 engaging with merchant subsystem 200 via merchant application 113 associated with key 157 and merchant identifier 167. Device 100 may be configured to access application 113 (e.g., access the application from application store 420 via communication path 65) and execute application 113 (e.g., execute the application with processor 102). Alternatively or in addition, merchant key 157 and merchant identifier 167 may be associated with a merchant website (e.g., one or more URLs or domains, which may be referred to herein as merchant online resources, or in some embodiments, merchant applications), or generally associated with a merchant, rather than or in addition to a third-party native application of the merchant. For example, a merchant of merchant subsystem 200 may collaborate with commercial entity subsystem 400 to associate within table 430 a particular merchant website or merchant generally with a particular merchant key 157 and merchant identifier 167, which may enable commercial entity subsystem 400 to determine and utilize the appropriate merchant key 157 for use in providing a layer of security for a transaction to any secure device data (e.g., business credential data that may include payment credential data native to device 100) transmitted to merchant subsystem 200, which may involve device 100 engaging with merchant server 210 to conduct a transaction via an Internet application or web browser executed on device 100, which may be directed to a URL or domain whose target or web resource may be associated with that merchant key 157 and merchant identifier 167 (e.g., a unique domain for that web resource (e.g., store.merchant.com)). Device 100 may be configured to access this URL from merchant server 210, for example, via communication path 15 (e.g., using Internet application 113 on device 100, which may be considered a merchant online resource when targeted to this merchant web resource). In other embodiments, application 113 may not be associated with a particular merchant, merchant subsystem 200, merchant key 157, and / or merchant identifier 167, but may instead be a stand-alone application accessible by device 100 using a web view targeted to this merchant web resource, thereby acting as a merchant online resource.Such registration of a merchant online resource by commercial entity subsystem 400 may be performed in any suitable manner (e.g., securely and authenticated sharing of merchant key 157 and merchant identifier 167 between merchant subsystem 200 and commercial entity subsystem 400 (e.g., for storage in table 430)) such that commercial entity subsystem 400 ensures that merchant subsystem 200 is the valid owner of the online resource. As mentioned, a merchant online resource (e.g., a native application, a domain / URL, or any other suitable web resource, or perhaps even a merchant terminal) may be associated with a particular merchant identifier 167 and a particular merchant key 157 (e.g., in a. Figure 5 Step 501 and / or in Figure 6 During registration (step 606 of ), each of the specific merchant identifier 167 and the specific merchant key 157 may be securely shared between the merchant subsystem 200 and the commercial entity subsystem 400 in any suitable manner, and this association may be accessible to the commercial entity subsystem 400 (e.g., in table 430).

[0032] Figure 2 Description

[0033] Reference now Figure 2 , Figure 2 Show above about Figure 1 and Figure 1A A more detailed view of the electronic device 100 of the described system 1. Figure 2 As shown in , the electronic device 100 may, for example, include a processor 102, a memory 104, a communication component 106, a power supply 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, which may provide one or more wired or wireless communication links or paths for transmitting data and / or power to various other components of the device 100, transmitting data and / or power from the various other components, or transmitting data and / or power between the various other components. The electronic device 100 may also have a housing 101, which may at least partially enclose one or more of the components of the device 100 for protection 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 Figure 2 For example, the electronic device 100 may include any other suitable components or Figure 2 For simplicity, Figure 2Only one of each of such components is shown in FIG. One or more input components 110 may be provided to permit a user to interact or engage with the device 100, and / or one or more output components 112 may be provided to present information (e.g., images, auditory 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 collectively referred to as I / O components or I / O interfaces 114). For example, input components 110 and output components 112 may sometimes be a single I / O component 114 (such as a touch screen) that may receive input information through a user touching a display screen and may also provide visual information to the user via that same display screen. The processor 102 of the electronic device 100 may include any processing circuitry that is operable 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 , processor 102 may be used to execute one or more applications, such as application 103 and / or application 113. As one example, application 103 may be an operating system application, while application 113 may be a third-party application or any other suitable online resource (e.g., an application associated with a merchant of merchant subsystem 200). Additionally, as shown, processor 102 may access device identification information 119, which may be utilized by a user of device 100 and / or commercial entity subsystem 400 for providing identification of device 100.

[0034] The NFC component 120 may be any suitable proximity-based communication mechanism that can implement contactless proximity-based transactions or communications between the electronic device 100 and a merchant terminal (e.g., merchant payment terminal 220) of the merchant subsystem 200. The NFC component 120 may include any suitable module for implementing contactless proximity-based communications between the electronic device 100 and the merchant terminal. Figure 2, the NFC component 120 may include, for example, an NFC device module 130, an NFC controller module 140, and / or an NFC memory module 150. The NFC device module 130 may include an NFC data module 132, an NFC antenna 134, and an NFC enhancer 136. The NFC data module 132 may be configured to contain, route, or otherwise provide any suitable data that may be transmitted by the NFC component 120 to the merchant terminal as part of a contactless proximity-based communication or part of an NFC communication. Additionally or alternatively, the NFC data module 132 may be configured to contain, route, or otherwise receive any suitable data that may be received by the NFC component 120 from the merchant terminal as part of a contactless proximity-based communication. The NFC controller module 140 may include at least one NFC processor module 142. The NFC processor module 142 may operate in conjunction with the NFC device module 130 to enable, initiate, allow, and / or otherwise control the NFC component 120 for transmitting NFC communications between the electronic device 100 and the merchant terminal. The NFC controller module 140 may include at least one NFC processor module 142 that may be used to execute 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 2A 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 cryptographic data (e.g., applet 153 and key 155) in accordance with rules and security requirements that may be set forth by a well-identified set of trusted authorities (e.g., an authority of a financial institution subsystem and / or an industry standard such as GlobalPlatform).

[0035] like Figure 2, the NFC memory module 150 may, for example, 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.), such security domains 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., a financial institution subsystem 350) may store keys and / or other suitable information for establishing or otherwise configuring one or more credentials (e.g., credentials associated with various credit cards, bank cards, gift cards, access cards, transit passes, 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 (e.g., credential information 161a) that may be assigned to a user / consumer and securely stored on the electronic device 100, such as a credit card payment number (e.g., a device primary account number (“DPAN”), a DPAN expiration date, a CVV, etc. (e.g., as a token or otherwise)). The NFC memory module 150 may include at least two SSDs 154 (e.g., at least one first SSD 154a and one second SSD 154b). For example, the first SSD 154a (e.g., credential SSD 154a) may be associated with a specific credential that can provide a specific special authority or payment right to the electronic device 100 (e.g., a specific credit card credential or a specific public transit card credential configured by the financial institution subsystem 350), and 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, which may be a controlling entity for the device 100) that can control the device 100's access to the specific credential of another SSD (e.g., the first SSD 154a), for example, to provide a specific special authority or payment right to the electronic device 100. Alternatively, each of the first SSD 154a and the second SSD 154b may be associated with a corresponding specific credential that can provide a specific special authority or payment right to the electronic device 100 (e.g., a specific credit card credential or a specific public transit card credential configured by the financial institution subsystem 350). Each SSD 154 may include and / or be associated with at least one applet 153 (eg, SSD 154a is associated with applet 153a and SSD 154b is associated with applet 153b).For example, applet 153 of SSD 154 may be an application executable on a secure element of NFC component 120 (e.g., in a GlobalPlatform environment). Credential applet 153 may include credential information 161 or be associated with credential information 161 (e.g., information 161a of applet 153a and / or information 161b of applet 153b). Each SSD 154 and / or applet 153 may also include at least one of its own keys 155 and / or be associated with at least one of its own keys 155 (e.g., applet 153a is associated with at least one key 155a and applet 153b is associated with at least one key 155b).

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

[0037] Security features may be provided to enable the use of the NFC component 120, which may be particularly useful when confidential payment information (such as credit card information or bank account information of a credential) is transmitted 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. For example, user authentication via a personal identification number ("PIN") entry or via user interaction with a biometric sensor may be required to access the secure storage area. As an example, the access SSD 154b may utilize the applet 153b to determine whether such authentication has occurred before allowing other SSDs 154 (e.g., the credential SSD 154a) to be used to transmit its credential information 161a. In some embodiments, some or all of the security features may be stored in the NFC memory module 150. Further, security information (such as an authentication key) used to communicate business credential data with the merchant subsystem 200 may be stored in the NFC memory module 150. In some embodiments, the NFC memory module 150 may include a microcontroller embedded in the electronic device 100. As just one example, a mini-application 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 this determination, may be configured to enable another particular SSD for conducting a payment transaction (e.g., using credentials from credential SSD 154a).

[0038] Figure 2A Description

[0039] Reference now Figure 2A , Figure 2A Show above about Figure 1 to Figure 2 Another detailed view of a portion of the electronic device 100 of the described system 1. Figure 2A, for example, the secure element 145 of the device 100 may include: SSD 154a, which may include or be associated with applet 153a, credential information 161a, access key 155a, and / or credential key 155a'; and SSD 154b, which may include or be associated with applet 153b, credential information 161b, access key 155b, and / or credential key 155b'. In some embodiments, 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 a specific business credential (e.g., a specific credit card credential or a specific public transportation card credential) that may provide specific special permissions or payment rights to the electronic device 100. Each SSD 154 may have its own administrator key 155 (e.g., a corresponding one of keys 155ak and 155bk), which may need to be activated to enable the functionality of that SSD 154 for use by the NFC device module 130. Additionally or alternatively, each SSD 154 may include at least one of its own credential application or credential applet (e.g., a Java card applet instance) associated with a particular business credential and / or be associated with the at least one (e.g., SSD 154). Credential applet 153a of SSD 154a may be associated with a first business credential and / or 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 / or access key 155b for credential applet 153b), and / or its own credential key (e.g., credential key 155a' for credential applet 153a and / or credential key 155b' for credential applet 153b), and wherein it may be necessary to launch the credential applet to enable its associated business credential for use with NFC device module 130 for NFC communication (e.g., NFC communication with merchant terminal 220) and / or as online-based communication between electronic device 100 and merchant subsystem 200 (e.g., via commercial entity subsystem 400). In some embodiments, the credential key 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 the financial institution subsystem 350 that may be responsible for the credential and may be accessed by that financial institution subsystem 350 (e.g., as Figure 1A) for enabling secure transmission of credential information for that applet between secure element 145 and financial institution subsystem 350 (e.g., via merchant subsystem 200). In addition or alternatively, access keys for 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 accessed by commercial entity subsystem 400 (e.g., as shown in FIG. 1 ). Figure 1A ) for enabling secure transmission of that credential information for that applet between secure element 145 and commercial entity subsystem 400. In addition or alternatively, as shown, each applet may include its own unique application identifier ("AID"), such as AID 155aa for applet 153a and / or AID 155ba for applet 153b. For example, an AID may identify a specific card scheme and product, program, or network (e.g., MasterCard Cirrus, Visa PLUS, Interac, etc.), wherein the AID may include not only a registered application provider identifier ("RID") (which may be used to identify the payment system (e.g., card scheme) or network (e.g., MasterCard, Visa, Interac, etc.) of the credential associated with the AID), but may also include a proprietary application identifier extension ("PIX") (which may be used to distinguish products, programs, or applications provided by the provider of the credential or payment system associated with the AID). Any suitable specification operable to govern the firmware of secure element 145 (e.g., the Java Card specification) may be operable to ensure or otherwise enforce the uniqueness of each AID on secure element 145 (e.g., each credential instance on secure element 145 may be associated with its own unique AID).

[0040] Additionally or alternatively, Figure 2A As shown in FIG. 1 , secure element 145 may include ISD 152, which may include ISD key 156k, which may also be a trusted service administrator associated with that security domain (e.g., business entity subsystem 400, such as Figure 1A Similar to and / or replacing access key 155a and / or access key 155b, ISD key 156k may be utilized by commercial entity subsystem 400 and electronic device 100 to implement secure transmission between commercial entity subsystem 400 and secure element 145 of electronic device 100. Figure 2A, various data communications may be performed between the processor 102 and the secure element 145. For example, the processor 102 of the device 100 may be configured to execute a device application 103, which may communicate information with a merchant application 113 of the processor 102 and the secure element 145, an I / O interface component 114a (e.g., for receiving I / O input data 115i and / or for transmitting I / O output data 115o), and / or a communication component 106. Additionally, as shown, the processor 102 may access device identification information 119, which may be utilized for enabling secure communications between the device 100 and a remote entity.

[0041] Additionally or alternatively, Figure 2A As shown in , the security element 145 may include a control authorization unit security domain ("CASD") 158, which may be a special-purpose security domain that can be configured as a third-party on-element root of trust. The associated application of CASD 158 may be configured to provide on-element confidential key generation as a global service to other applications and / or to a specific management layer (e.g., GlobalPlatform management layer). The confidential key material that can be used in CASD 158 can be configured so that the confidential key material will not be investigated or modified by any entity (including the issuer of the security element 145). CASD 158 may be configured to include and / or may be configured to generate and / or otherwise include a CASD access kit 158k (e.g., CASD private key ("CASD-SK"), CASD public key ("CASD-PK"), CASD certificate ("CASD-certificate"), and / or CASD-signing module). For example, CASD 158 may be configured to sign certain data on secure element 145 (e.g., using CASD access kit 158k) before providing such data to another portion of device 100 (e.g., communications component 106 for sharing with other subsystems of system 1). As an example, CASD 158 may be configured to sign any data provided by secure element 145 so that other subsystems (e.g., business entity subsystem 400) may be able to confirm that such signed data is signed by secure element 145 (e.g., using associated CASD kit 158k at business entity subsystem 400).

[0042] Additionally or alternatively, Figure 2AAs shown in FIG. 1 , the secure element 145 may include a contactless login service (“CRS”) applet or application 151 that may be configured to provide local functionality to the electronic device 100 for modifying the life cycle state of certain security domain elements (e.g., enabled, deactivated, locked, etc.) and sharing certain output information 115o about certain security domain elements in certain life cycle states with a user of the device 100 (e.g., via a user I / O interface 114a). For example, the CRS application 151 may include a CRS list that may maintain a list of the current life cycle states of each security domain element on the secure element 145.

[0043] 151t (e.g., may include the credential applet 153a of SSD 154a and / or the credential applet 153b of SSD 154b).

[0044] The CRS application 151 may be configured to share the lifecycle state of one, some, or all of the security domain elements of the secure element 145 with the applications of the device 100 (e.g., to share the lifecycle state with any suitable application type such as a daemon, such as a card management daemon (“CMD”) application 103a, which may be executed as an operating system application 103 and / or a card management application 103b (e.g., Passbook provided by Apple Inc. TM or Wallet TM Application) and / or merchant application 113 (e.g., a merchant online resource that may be associated with merchant key 157 and merchant identifier 167) and / or identification service ("IDS") application 103c background program, but not necessarily controlled by an interactive user of device 100), CRS application 151 may then provide certain life cycle state information to a user of device 100 as output information 115o via I / O interface 114a and a user interface ("UI") application (e.g., the UI of card management application 103b), the UI application enabling the user to change the life cycle state of security domain elements (e.g., update CRS manifest 151t and the life cycle state of security domain elements, such as business credentials used to implement a particular credential applet for use in financial transactions). In addition or alternatively, CR 151 may include CRS access key 151k, which may also be a trusted service administrator associated with CRS 151 (e.g., commercial entity subsystem 400, such as Figure 1ASimilar to and / or replacing access key 155a and / or access key 155b, CRS access key 151k may be fully utilized by commercial entity subsystem 400 and electronic device 100 to implement secure transmission between commercial entity subsystem 400 and secure element 145 of electronic device 100.

[0045] The IDS application 103c may be any suitable application type, such as a daemon, which may be executed as a background process within the operating system application 103 and / or the card management application 103b, and / or may be provided by the CMD application 103a, and may operate as an IDS administrator that listens for and responds to IDS messages, which may be communicated via any suitable IDS service (which may be similar to any suitable messaging service, such as iMessage provided by Apple Inc. TM , or similar (e.g., FaceTime provided by Apple Inc. TM or Continuity TM)) sends an IDS message, the IDS service can implement unique end-to-end encryption of messages between the IDS application 103c of the host device 100 and a similar IDS application of another device (e.g., a client device). Such messages can be encrypted using a unique identifier for one or both of the communicating devices and / or a unique identifier for one or both of the specific users of the communicating devices. Such messages can be transmitted as a local link or a true device-to-device (e.g., peer to peer) communication, or can be transmitted via the business entity subsystem 400 (e.g., via the identification management system component 470). Such message transmission can be implemented as a low-latency solution, which can allow data to be exchanged in a structured format (e.g., protocol buffer) and / or an unstructured format. If the IDS application 103c is not executing when the IDS message is received, the IDS application 103c can be automatically awakened. The IDS application 103c can be operated to present an appropriate user interface and direct the data requested by the received IDS communication to be transmitted back to the requesting device. The IDS application 103c of the host device is operable to wake up the card management wizard application 103a of the card management application 103b upon detecting an initial request from the client device, which may allow the host device to operate in a low-power "sleep" mode. In addition or alternatively, the IDS application 103c is operable to manage a "timeout" for such a request, such that if a payment request from a client device is inactive on the host device for a period of time (e.g., 60 seconds, due to no active host device user interaction in response to such a request), then the IDS application 103c is operable to determine to terminate the request, which will cause the host device to generate and deliver a "canceled" status back to the client device, which will display an appropriate message (e.g., display a "timeout error" to the user of the client device).

[0046] Figure 3 and FIG. 3A to FIG. 3D Description

[0047] like Figure 3 As shown in FIG. 1 and described in more 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 interface with each other. For example, a touch screen I / O component 114a may include a display output component 112a and an associated touch input component 110f, wherein the display output component 112a may be used to display a visual 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, components, menus, and / or other components of a currently executing application (e.g., application 103 and / or application 113 and / or application 143) that may be displayed in all or some areas of the display output component 112a. For example, as Figure 3 , the GUI 180 may be configured to display a first screen 190 having one or more graphical elements or icons 182 of the GUI 180. When a particular icon 182 is selected, the device 100 may be configured to open a new application associated with that icon 182 and display a corresponding screen of the GUI 180 associated with that application, such as a merchant online resource application. For example, when a user of the device 100 selects a particular icon 182 marked with a "merchant application" text indicator 181 (i.e., a particular icon 183), the device 100 may launch or otherwise access a particular third-party merchant application (e.g., a native application or a hybrid application). For another example, when a user of the device 100 selects a particular icon 182 marked with an "Internet" text indicator (i.e., a particular icon 184), the device 100 may launch or otherwise access an Internet browser application, which may be directed to a URL of a web resource of a particular third-party merchant for providing another type of merchant online resource to the device 100. When accessing any suitable merchant online resource, device 100 may be operable to display a specific user interface screen, which may include one or more tools or features for using device 100 to interact with that merchant online resource in a specific manner (e.g., see FIG. 3A to FIG. 3D, showing a specific example of such a display of GUI 180 during use of any suitable application (e.g., merchant online resource 113), the device user may use the one or more tools or features to perform any security functionality of device 100 (e.g., using credentials of NFC component 120 of device 100 (e.g., credentials of SSD 154a) to pay merchant subsystem 200). For each application, the screen may be displayed on display output component 112a and may include various user interface elements. 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 device 100. For example, in some embodiments, device 100 may not include a user interface component that operates to provide a GUI, but may instead provide an audio output component and a mechanical or other suitable user input component for selecting and authenticating the use of payment credentials for providing funds for a transaction or for performing any other suitable security functionality of the device.

[0048] Figure 4 Description

[0049] Reference now Figure 4 , Figure 4 Further details regarding a specific embodiment of the commercial entity subsystem 400 of system 1 are presented. Figure 4 , commercial entity subsystem 400 may be a secure platform system and may include a secure mobile platform ("SMP") agent component 440, an SMP trusted service manager ("TSM") component 450, an SMP cryptographic service component 460, an identification management system ("IDMS") component 470, a fraud system component 480, a hardware security module ("HSM") component 490, a store component 420, and / or one or more servers 410. Components, some components, or all components of commercial entity subsystem 400 may be implemented using each of the following: one or more processor components, which may be the same as or similar to processor component 102 of device 100; one or more memory components, which may be the same as or similar to memory component 104 of device 100; and / or one or more communication components, which may be the same as or similar to communication component 106 of device 100. A single business entity (e.g., Apple Inc.) that may be distinct and independent from financial institution subsystem 350 and / or merchant subsystem 200 may manage, own, at least partially control, and / or otherwise provide components, some components, or all components of commercial entity subsystem 400. The components of commercial entity subsystem 400 may interact with each other and with financial institution subsystem 350 and / or electronic device 100 and / or merchant subsystem 200 to provide new layers of security and / or to provide a smoother user experience.

[0050] SMP agent component 440 of business entity subsystem 400 may be configured to manage user authentication using business entity user accounts. SMP agent component 440 may also be configured to manage the lifecycle and configuration of credentials on device 100. SMP agent component 440 may be the primary endpoint that may control user interface elements (e.g., elements of GUI 180) on device 100. An operating system or other application of an end-user device (e.g., application 103, application 113, and / or application 143 of device 100) may be configured to call a specific application programming interface ("API"), and SMP agent 440 may be configured to process requests of those APIs and respond with data that may export a user interface of device 100 and / or respond with application protocol data units ("APDUs") that may be communicated with secure element 145 (e.g., via communication path 65 between business 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). SMP TSM component 450 of commercial entity subsystem 400 may be configured to provide services based on GlobalPlatform or any other suitable service that may be used to perform credential configuration operations on device 100 from financial institution subsystem 350. GlobalPlatform or any other suitable secure channel protocol may enable such SMP TSM component 450 to appropriately transmit and / or configure sensitive account data between secure element 145 of device 100 and TSM for secure data communications between commercial entity subsystem 400 and financial institution subsystem 350.

[0051] SMP TSM component 450 may be configured to use HSM component 490 to protect its keys and generate new keys. SMP Cryptographic Services component 460 of business entity subsystem 400 may be configured to provide key management and cryptographic operations that may provide for user authentication and / or confidential data transfer between various components of system 1. SMP Cryptographic Services component 460 may utilize HSM component 490 for secure key storage and / or opaque cryptographic operations. The payment cryptographic services of SMP Cryptographic Services component 460 may be configured to interact with IDMS component 470 to retrieve information associated with credit cards on file or with a business entity's user account (e.g., Apple iCloud). TMThis payment cryptographic compilation service can be configured as a unique component of business entity subsystem 400, which can have in memory clear text (e.g., non-hashed) information describing the business credentials (e.g., credit card numbers) of its user accounts. IDMS component 470 can be configured to implement and / or manage any suitable communication between device 100 and another device, such as identification service ("IDS") transmission (e.g., using a business entity specific service (e.g., iMessage provided by Apple Inc.) TM ). For example, certain devices may automatically or manually register with the service (e.g., all devices in the ecosystem of business entity 400 may automatically register with the service). The service may provide an end-to-end encryption mechanism that requires active registration before messages may be sent using the service (e.g., using IDS application 103c of device 100). IDMS component 470 and / or any other suitable server or portion of business entity subsystem 400 may be operable to identify or otherwise query the status of any credentials configured on any electronic device associated with a given user account or otherwise, such that business entity subsystem 400 may be operable to efficiently and effectively identify one or more non-native payment credentials that may be used by a particular client device associated with a particular user account (e.g., multiple devices of a family account of business entity subsystem 400). Commercial entity fraud system component 480 of commercial entity subsystem 400 may be configured to perform a commercial entity fraud check on a commercial credential based on data known to the commercial entity about the commercial credential and / or the user (e.g., based on data associated with a user account associated with the commercial entity (e.g., commercial credential information), and / or any other suitable data that may be controlled by the commercial entity, and / or any other suitable data that may not be controlled by financial institution subsystem 350). Commercial entity fraud system component 480 may be configured to determine a commercial entity fraud score for a credential based on various factors or thresholds. Additionally or alternatively, commercial entity subsystem 400 may include store 420, which may be a provider of various services to 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 and / or associating multiple user devices and / or multiple user profiles with each other TMAs just one example, store 420 may be configured to manage and provide applications 113 to device 100 (e.g., via communication path 65), where application 113 may be any suitable application, such as a banking application, a merchant application, an email application, a text messaging application, an Internet application, a card management application, or any other suitable communication application. Any suitable communication protocol or combination of communication protocols may be used by commercial entity subsystem 400 to communicate data between the various components of commercial entity subsystem 400 (e.g., via communication path 65). Figure 4 at least one communication path 495) and / or data communication between the commercial entity subsystem 400 and other components of the system 1 (for example, between the commercial entity subsystem 400 and the financial institution subsystem 350 via Figure 1 communication path 55, and / or between the business entity subsystem 400 and the electronic device 100 via Figure 1 communication path 65).

[0052] Figure 5 Description

[0053] Figure 51 is a flow chart of an illustrative process 500 for authenticating online access to secure device functionality. Process 500 is shown as being implemented by electronic device 100, commercial entity subsystem 400, and merchant subsystem 200. However, it should be understood that process 500 may be implemented using any other suitable components or subsystems. Process 500 may provide a smooth user experience for securely and efficiently authenticating a third-party merchant subsystem 200, for enabling online access to secure functionality of electronic device 100 by merchant subsystem 200, such as authenticating merchant subsystem 200 by commercial entity subsystem 400, for enabling secure use of credentials on electronic device 100 in transactions with merchant subsystem 200 (e.g., online payments or contactless proximity-based payments), or for enabling secure access by merchant subsystem 200 from electronic device 100 to any other suitable data (e.g., location data, health data, or any other private data or other that is not suitable to be shared with a third-party subsystem that has not been effectively authenticated). Although the term "merchant" may be used to describe merchant subsystem 200 and / or any features thereof, such as merchant online resources or keys or servers or terminals or identifiers, it should be understood that subsystem 200 may be any suitable subsystem (e.g., a processing subsystem (e.g., a data processing subsystem)) operated by any suitable third-party entity, which may be different from the owner or user of electronic device 100 and / or different from commercial (or administrative) entity subsystem 400. For example, merchant subsystem 200 may be any suitable third-party subsystem that may attempt to access or otherwise receive or interact with secure device functionality of electronic device 100 (e.g., use merchant online resources to load data onto device 100 (e.g., configure payment credentials on device 100), receive data from device 100 (e.g., access payment credential data or health care data or location data or contact data or private media data from device 100), and / or the like). Process 500 is operable to enable more secure and more trusted communication of any suitable data between device 100 and any suitable Web resource of any suitable merchant subsystem. Process 500 is operable to authenticate any suitable Web resource or other online resource to ensure that that resource has a trusted relationship with commercial entity subsystem 400 before enabling such data communication.

[0054] At step 501 of process 500, merchant subsystem 200 may register with commercial entity subsystem 400. As mentioned, merchant online resources 113 (e.g., native applications, domains / URLs, or any other suitable web resources, or perhaps even merchant terminals) of merchant subsystem 200 may be associated with specific merchant identifiers 167 and specific merchant keys 157, each of which may be securely shared between merchant subsystem 200 and commercial entity subsystem 400 in any suitable manner, and this association may be accessible to commercial entity subsystem 400 (e.g., in table 430). In some embodiments, a developer of a native application (e.g., a native application merchant online resource 113) may use an entitlement system to allow the application to access secure device functionality (e.g., push messaging, cloud storage, secure element credential payment, etc.) of the electronic device 100 on which the application is executing, wherein such entitlements may be signed into the application's binary as part of a code signing process that may be required to enable registration of the application by commercial entity subsystem 400 (e.g., for deployment in application store 420, and / or for securely associating the application's merchant key 157 with a merchant identifier 167 in table 430), wherein merchant identifier 167 may, for example, form part of the entitlement for the application. Unlike such native applications, web resources (e.g., website merchant online resources 113) may not have code signing or similar protections that may be provided (e.g., by commercial entity subsystem 400) to native applications operable to execute on electronic device 100. Instead, ownership of the web domain of a web resource may be verified before that web resource may be registered. With respect to registering a website merchant online resource 113 owned or otherwise controlled by merchant subsystem 200, such ownership must be verified to commercial entity subsystem 400 before that merchant online resource 113 is registered with commercial entity subsystem 400 (e.g., before a specific merchant identifier 167 and a specific merchant key 157 are associated with that merchant online resource 113 and shared between merchant subsystem 200 and commercial entity subsystem 400 for future access by commercial entity subsystem 400 (e.g., in form 430)).For example, to verify ownership of the domain of the merchant online resource 113 to be registered to commercial entity subsystem 400, the identification of the domain may be provided to commercial entity subsystem 400, commercial entity subsystem 400 may provide any suitable file (e.g., a static file, such as a JSON file) to merchant subsystem 200, merchant subsystem 200 may sign that file (e.g., using shared merchant key 157) and host that file at a well-known path on the domain to be registered, and then commercial entity subsystem 400 may access the signed file from the domain and remove the signature from the file (e.g., using shared merchant key 157) to confirm that the accessed file corresponds to the file shared with merchant subsystem 200. Some exemplary procedures for registering web resources may be described in U.S. Patent Application Publication No. 2015 / 0350106, entitled “Sharing Account Data Between Different Interfaces To A Service,” which is incorporated herein by reference in its entirety. At step 502, any suitable procedure or procedures may be utilized for securely registering the validity of any suitable type of merchant online resource 113 of merchant subsystem 200 (e.g., any native application, hybrid application, web resource, or even a merchant's merchant terminal to be utilized by the electronic device, whether executed locally on the device, remotely hosted on a server, or located proximate to the device) with commercial entity subsystem 400, whereby at least one merchant identifier 167 and at least one merchant key 157 (e.g., a symmetric or asymmetric key pair) associated with the merchant online resource 113 may be associated with the merchant online resource 113 and accessible to both merchant subsystem 200 and commercial entity subsystem 400 (e.g., in table 430) for future use, and any suitable data communication may be conducted between merchant subsystem 200 and commercial entity subsystem 400 during any such procedure in any suitable manner (e.g., transmitting application 113, key 157, identifier 167, and / or any other suitable data via communication path 85 using any suitable communication protocol). One or more merchant identifiers may be associated with a particular merchant online resource 113, such as a first merchant identifier 167 being uniquely associated with a particular merchant online resource 113 and / or a second merchant identifier 167 being associated with each merchant online resource 113 of a particular merchant subsystem 200. Additionally or alternatively, one or more merchant keys may be associated with a particular merchant identifier or associated with a particular merchant online resource 113. At one or more instances of step 501, the association of all such merchant keys with merchant identifiers may be stored by commercial entity subsystem 400 or otherwise accessible to commercial entity subsystem 400 (e.g., in one or more tables 430).

[0055] At step 502 of process 500, potential transaction data may be communicated between the merchant subsystem 200 and the electronic device 100 using a registered merchant online resource. For example, at some point during a user's interaction with a device 100 executing or otherwise accessing a merchant online resource application 113 (e.g., when the user is purchasing goods or services from a merchant online, or when the user is communicating with a medical professional), potential transaction data may be transmitted from the merchant subsystem 200 or from any other suitable entity to the device 100, which may indicate any suitable data related to a potential secure data transaction that may occur between the device 100 and a merchant (or processor) of the merchant (or processing) subsystem 200, including, but not limited to: (i) specific merchant information, such as at least one or each merchant identifier 167 of the merchant online resource application 113; (ii) specific transaction information, such as identification of a specific type of secure data to be shared between the device 100 and the merchant subsystem 200 (e.g., currency and amount (value) for a financial transaction); amount) and type of payment (e.g., $5 using a Visa payment credential configured on device 100), type and amount of health insurance data for health transactions (e.g., heart rate data for a particular user over the last 3 days as detected or otherwise obtained by device 100), and / or the like); and / or (iii) a unique merchant-based transaction identifier (e.g., any suitable data element, such as a multi-character alphanumeric string, which may be randomly or uniquely generated by merchant subsystem 200 for association with the transaction in progress). Such potential transaction data may include any suitable number and type of data fields (with or without associated data) that may be necessary or at least useful for completing a secure data transaction, such as fields of contact information for the customer making the purchase (e.g., phone number, email address, mail address), some of which may be populated and included as part of such potential transaction data, and / or some of which may not be populated as part of such potential transaction data, but may be open and awaiting population during a later portion of process 500. Such potential transaction data of step 502 may be referred to herein as a PKDataRequest or PKPaymentRequest (e.g., for financial transactions). In some embodiments, the user may not actively interact with device 100 to make potential transaction data associated with merchant subsystem 200 available to device 100 at step 502.Rather, as one example, device 100 may be configured to determine that a particular product is desirable to purchase and interact with one or more merchants to obtain associated transaction data from at least one particular merchant of that particular product (e.g., device 100 may be a household appliance that may be configured to determine that an appliance product must be purchased (e.g., detect that a washing machine needs more laundry detergent, or detect a calendar event preset by a user to buy more detergent on a particular date), and may automatically identify a particular merchant that offers the best deal for that product, and may automatically use merchant online resources to interact with that merchant to obtain transaction data from that merchant for purchasing that product), all automatically and without any active interaction by a user of device 100. The potential transaction data of step 502 may include all data necessary for device 100 to securely generate and / or provide secure device data (e.g., appropriate payment credential data) to merchant subsystem 200 for use in completing a secure data transaction associated with the potential transaction data (e.g., to fund a financial transaction). At step 502, such potential transaction data may be transmitted by the merchant subsystem 200 to the device 100 in any suitable manner (e.g., such potential transaction data may be transmitted from the server 210 of the merchant subsystem 200 to the communication component 106 of the device 100 via the communication path 15 using any suitable communication protocol, or via a contactless proximity-based communication channel between the terminal 220 and the NFC component 120 using any suitable communication protocol).

[0056] At step 504 of process 500, a merchant online resource verification session may be initiated. This may occur in response to the electronic device 100 indicating that a secure data transaction (e.g., a secure data transaction identified by the potential transaction data of step 502) should occur (e.g., in response to a user of the device 100 selecting a GUI element (e.g., a radio button) of the merchant online resource that communicates that the user wants to conduct the secure data transaction identified by the potential transaction data of the merchant online resource of step 502, or automatically based on any suitable requirement being satisfied (e.g., simply in response to the potential transaction data of step 502 being communicated to the device 100)). Upon determining such an intent to conduct a particular secure data transaction with a merchant online resource, the merchant online resource 113 on the device 100 may be operable to generate and send a data transaction request to the card management application 103b or any other suitable device application on the device 100, and at step 504, that device application 103b may be operable to generate and transmit merchant verification session initiation data to the merchant subsystem 200. At step 504, any suitable data may be generated by electronic device 100 and / or transmitted to merchant subsystem 200 as merchant verification session initiation data for initiating a merchant online resource verification session for a particular secure data transaction to be conducted. For example, at step 504, a verification session identifier may be generated by electronic device 100 and transmitted to merchant subsystem 200 as at least a portion of the merchant verification session initiation data, wherein the verification session identifier may be any suitable alphanumeric string or any other suitable identifier that may uniquely identify a merchant online resource verification session currently being initiated (e.g., uniquely identifying such a session to merchant subsystem 200 and / or to commercial entity subsystem 400 for at least a certain period of time). When the verification session identifier is generated by electronic device 100, the verification session identifier may be unique with respect to commercial entity subsystem 400 by utilizing a unique identifier of device 100 (e.g., device identifier 119 or a unique secure element identifier of secure element 145 of device 100, which may be unique to device 100 (e.g., with respect to commercial entity subsystem 400)) to assist in generating the verification session identifier. Additionally or alternatively, at step 504, a challenge request target identifier (e.g., a challenge request URL) may be transmitted from device 100 to merchant subsystem 200 as at least a portion of merchant verification session initiation data, wherein such challenge request target identifier may identify an entity with which merchant subsystem 200 is to communicate to verify the merchant (e.g., identifying a URL of server 410 of commercial entity subsystem 400 that may cooperate with merchant subsystem 200 to verify a merchant online resource for a particular secure data transaction to be conducted).The device application (e.g., card management application 103b (e.g., wallet application)) may have such a challenge request target identifier programmed (as part of any suitable operating system or application update), which may be controlled by commercial entity subsystem 400, such that the challenge request target identifier on device 100 may be updated by commercial entity subsystem 400 at any suitable time. In addition or alternatively, such merchant verification session initiation data may include any other suitable data, such as: any suitable data indicating a request for the merchant to verify itself; any suitable data indicating device 100 (e.g., device identifier 119); and / or any suitable data indicating a specific secure data transaction to be conducted (e.g., any suitable data of the potential transaction data from step 502, such as specific merchant information (e.g., merchant identifier 167), specific transaction information (e.g., currency and amount and payment type for financial transactions or type and amount of health care data for health transactions), and / or a unique merchant-based transaction identifier). At step 504, any suitable merchant verification session initiation data may be transmitted by device 100 to merchant subsystem 200 in any suitable manner (e.g., such merchant verification session initiation data may be transmitted from communication component 106 of device 100 to server 210 of merchant subsystem 200 via communication path 15 using any suitable communication protocol, or via a contactless proximity-based communication channel between NFC component 120 and terminal 220 using any suitable communication protocol).

[0057] At step 506 of process 500, in response to merchant subsystem 200 receiving any suitable merchant authentication session initiation data from device 100 for initiating an authentication session at step 504, merchant subsystem 200 is operable to communicate with commercial entity subsystem 400 to authenticate a merchant online resource. In some embodiments, where the merchant authentication session initiation data of step 504 does not include an authentication session identifier, merchant subsystem 200 is operable to generate such an authentication session identifier that uniquely identifies the current merchant online resource authentication session that is being initiated. When the authentication session identifier is generated by merchant subsystem 200, the authentication session identifier may be unique with respect to commercial entity subsystem 400, which may be ensured by merchant subsystem 200 that the same authentication session identifier is not used twice at least with respect to the same commercial entity subsystem and / or with respect to the same merchant identifier and / or within a period sufficient to ensure that the session identifier is not in limbo for any particular program at the commercial entity subsystem. Step 506 may include any suitable number of subroutines that may enable commercial entity subsystem 400 to authenticate the merchant online resource (e.g., as identified in steps 502 and 504) for the particular secure data transaction to be conducted. Figure 6As described in detail at steps 614 to 622 of procedure 600, the verification at step 506 may include the merchant subsystem 200 transmitting the following items to the commercial entity subsystem 400 (e.g., as may be identified by the merchant verification session initiation data from the device 100 at step 504): a challenge request, which may include a merchant identifier associated with the merchant online resource to be verified (e.g., as the merchant identifier 167 registered at step 501, which may be the domain of the merchant online web resource); a verification session identifier (e.g., as generated by the electronic device 100 at step 504, or generated by the merchant subsystem 200 at step 506); and any other suitable data (e.g., data identifying the device 100 and / or data identifying a specific secure data transaction to be conducted). The challenge request may be signed (e.g., in an HTTP header or otherwise) by the merchant subsystem 200 using a merchant key associated with the merchant identifier of the challenge request (e.g., a merchant key 157 as registered in step 501 along with the merchant identifier 167 (e.g., for the merchant online resource 113 to be authenticated)). The commercial entity subsystem 400 may be operable to receive the challenge request, authenticate the merchant online resource 113 identified by the merchant identifier 167 of the challenge request (e.g., to confirm that the merchant online resource 113 has been registered in step 501 (e.g., by identifying that merchant identifier 167 in form 430) and is still valid), and then verify the signature of the challenge request (e.g., using the merchant key 157 associated with that identified merchant identifier 167 in form 430). In response to the component verifying the challenge request, commercial entity subsystem 400 may: generate challenge data (e.g., any suitable random data via entropy); store the challenge data against identifier data (e.g., one or both of the verification session identifier of the challenge request and the merchant identifier of the merchant) in any suitable data structure (e.g., table 430 or otherwise); encrypt the challenge data using merchant key 157 accessible by commercial entity subsystem 400 (e.g., the merchant key from table 430 used to verify the signature of the challenge request); and then send the challenge data to the merchant. The challenge data is transmitted to the merchant subsystem 200, and the challenge request may include the encrypted challenge data together with any other suitable data, such as a hash of the merchant key used to encrypt the challenge data (e.g., a hashed version of the public merchant key 157 of Table 430, which can be used by the merchant subsystem 200 to identify the appropriate merchant key 157 (e.g., the private key 157 of the merchant subsystem 200 used to decrypt the challenge data), and the hashed version can be provided to assist merchants who may have multiple registered merchant online resources and / or multiple merchant keys); a verification session identifier for the challenge request; and / or the like.In response to receiving such challenge data, merchant subsystem 200 may be operable to decrypt the encrypted challenge data using an appropriate merchant key 157 (e.g., a private merchant key 157 at merchant subsystem 200, as may have been registered in step 501), and then transmit challenge response data (including the decrypted challenge data along with any other suitable data, such as the verification session identifier of the challenge request and an appropriate merchant identifier) ​​to commercial entity subsystem 400, where that challenge response may be signed (e.g., in an HTTP header or otherwise) by merchant subsystem 200 using a merchant key associated with the merchant identifier of the challenge request (e.g., a merchant key 157 as registered in step 501 and a merchant identifier 167 (e.g., for the merchant online resource 113 to be authenticated)). In response to receiving such challenge response data, commercial entity subsystem 400 may be operable to verify the signature of the challenge response (e.g., using merchant key 157 associated with identified merchant identifier 167 in table 430) and confirm that the decrypted challenge data of the challenge response is stored against the verification session identifier of the challenge response and / or against the merchant's identifier (e.g., in table 430). In some embodiments, this stored association between the challenge data and one or both of the verification session identifier and the merchant identifier may be maintained for only a limited amount of time before the association is automatically cleared, such that merchant subsystem 200 may be limited to having to receive challenge data within a certain duration and then send appropriate challenge response data to commercial entity subsystem 400 for authentication of the merchant's online resource for a particular authentication session (e.g., commercial entity subsystem 400 may be operable to remove this association between the challenge data and the verification session identifier and / or merchant identifier at commercial entity subsystem 400 after a certain period of time (e.g., no more than 10 minutes (or any other suitable period of time) after the association is established). 4. The link is removed from form 430), which can increase transaction security. Thus, the association between the merchant key and the merchant identifier at commercial entity subsystem 400 (e.g., as registered at step 501) can be used to complete the verification of the merchant online resource for the specific secure data transaction to be conducted (e.g., as identified at steps 502 and 504) at step 506. Any suitable data communication can be conducted between the merchant subsystem and commercial entity subsystem 400 in any suitable manner at step 506 (e.g., such data can be transmitted between server 210 of merchant subsystem 200 and server 410 of commercial entity subsystem 400 via communication path 85 using any suitable communication protocol).

[0058] At step 508, in response to authenticating the merchant online resource at step 506 based on the authentication session initiated at step 504, commercial entity subsystem 400 may generate authentication data and store the authentication data against identifier data (such as the authentication session identifier and / or a merchant identifier for the authentication session). For example, in response to verifying the signature of the challenge response and in response to confirming that the challenge data and the verification session identifier and / or merchant identifier of the challenge response are also properly linked at commercial entity subsystem 400 (e.g., in table 430), in step 508, commercial entity subsystem 400 may: consume that link (e.g., remove such association between the challenge data and the verification session identifier and / or merchant identifier at commercial entity subsystem 400 (e.g., remove the link from table 430)); generate verification data (e.g., any suitable random data (e.g., a cryptographically compiled nonce (e.g., any suitable random data via entropy)); and then store the verification data against the verification session identifier of the challenge request and / or the verification session identifier of the challenge response, or otherwise associate the verification data with the verification session identifier of the challenge request and / or the verification session identifier of the challenge response, and / or store the verification data against the merchant identifier of the merchant (e.g., in any suitable data structure (such as table 430) or otherwise).

[0059] At step 510, in response to verifying the merchant online resource at step 506 and then storing any suitable verification data against the verification session identifier and / or merchant identifier at step 508, commercial entity subsystem 400 may transmit verification response data to electronic device 100, wherein such verification response data may include any suitable data, including but not limited to: the verification data of step 508; the verification session identifier of step 508; data identifying the merchant online resource verified at step 506 (e.g., merchant identifier 167); and / or any other suitable data. In some embodiments, as Figure 5, such verification response data may be transmitted directly from commercial entity subsystem 400 to electronic device 100 (e.g., via communication path 65 using any suitable communication protocol), wherein data identifying electronic device 100 (e.g., device identifier 119) may be associated with the verification session identifier (e.g., in step 502 or otherwise) and associated through verification in step 506, such that commercial entity subsystem 400 may transmit the verification response data to the appropriate electronic device 100. Alternatively, in some embodiments, such verification response data may be transmitted from commercial entity subsystem 400 to electronic device 100 via merchant subsystem 200, whereby merchant subsystem 200 may receive the verification response data from commercial entity subsystem 400 (e.g., via communication path 85 using any suitable communication protocol) and then pass at least a portion of the verification response data to electronic device 100 (e.g., via communication path 15 using any suitable communication protocol or as a contactless proximity-based communication). Such verification data may be signed (e.g., in an HTTP header or otherwise) by commercial entity subsystem 400 using an access key associated with commercial entity subsystem 400 (e.g., access key 155a, access key 155b, CRS 151k, and / or ISD key 156k of secure element 145, or any key known to a device application (e.g., card management application 103b)), and electronic device 100 may also access the access key so that device 100 may verify the signature upon receiving the signed verification data to confirm that commercial entity subsystem 400 generated the verification data, rather than another entity subsystem that is not trusted by electronic device 100.

[0060] At step 512 of process 500, secure device data may be generated or accessed at least in part by device 100, and then at step 514, such secure device data, along with at least a portion of the validation response data received at step 510 and at least a portion of the potential transaction data of step 502, may be transmitted by device 100 to commercial entity subsystem 400 as device transaction data. For example, in response to receiving validation response data at step 510 (which may indicate the validity of a merchant online resource used for the potential transaction data of step 502), device 100 may be operable to obtain or otherwise identify, at step 512, secure data to be shared with merchant subsystem 200 for use in conducting a particular secure data transaction (e.g., generating payment credential data for use in a financial transaction, or collecting particular health information to be shared in a health transaction). Next, at step 514, device 100 may transmit the secure data of step 512 along with the authentication data and authentication session identifier and merchant identifier of the authentication response data of step 510 and / or along with any suitable material related to the potential secure data transaction to be conducted (e.g., such as specific merchant information (e.g., merchant identifier 167), specific transaction information (e.g., currency and amount and payment type for financial transactions, or type and amount of health insurance data for health transactions), and / or a unique merchant-based transaction identifier, as may be provided to device 100 by the potential transaction data of step 502) as device transaction data to commercial entity subsystem 400. Thus, the device transaction data transmitted from device 100 to commercial entity subsystem 400 at step 514 may include the potential transaction data of step 502 as well as the secure device data of step 512 and some or all of the authentication response data of step 510.

[0061] Before transmitting the device transaction data to commercial entity subsystem 400 at step 514, device 100 may encrypt all or at least a portion of the device transaction data of step 514 (e.g., the secure device data of step 512) using a commercial entity key. For example, device 100 may encrypt at least a portion of the device transaction data using access key 155a, access key 155b, CRS 151k, CASD 158k, and / or ISD key 156k of secure element 145, or any other key accessible to device 100 (e.g., from any device application 103 to processor 102 or otherwise), and commercial entity subsystem 400 may also have access to such key (e.g., any shared secret between device 100 and commercial entity subsystem 400). In some embodiments, this commercial entity key or access key may be a commercial entity public key associated with a scheme of commercial entity subsystem 400 and its associated commercial entity private key accessible to commercial entity subsystem 400. Commercial entity subsystem 400 may provide this commercial entity public key to device 100 in any suitable manner. At step 540, device transaction data (whether or not at least partially encrypted and / or signed by any suitable commercial entity key) may be transmitted by device 100 to commercial entity subsystem 400 in any suitable manner (e.g., such device transaction data may be transmitted from communication component 106 of device 100 to server 410 of commercial entity subsystem 400 via communication path 65 using any suitable communication protocol).

[0062] Next, upon receiving the device transaction data transmitted at step 514, step 516 of procedure 500 may include commercial entity subsystem 400 verifying the authentication data of the received device transaction data received at step 514. For example, in response to receiving such device transaction data, at step 516 commercial entity subsystem 400 may be operable to identify authentication response data from that device transaction data and confirm that the authentication data of that received authentication response data is stored (e.g., in table 430) against an authentication session identifier of the received device transaction data (e.g., authentication response data) and / or against a merchant identifier of the received device transaction data (e.g., authentication response data). In some embodiments, this stored link between the verification data and one or both of the verification session identifier and the merchant identifier may be maintained for only a limited amount of time before the link is automatically cleared, such that electronic device 100 is constrained to receiving verification response data at step 510 and then sending device transaction data to commercial entity subsystem 400 at step 514 within a certain duration for the purpose of implementing secure device data with that device transaction data protected by commercial entity subsystem 400 for use in performing a particular secure data transaction using a verified merchant online resource (e.g., commercial entity subsystem 400 may be operable to remove this association between the verification data and the verification session identifier and / or merchant identifier at commercial entity subsystem 400 after a certain period of time (e.g., removing the link from table 430 no more than 10 minutes (or any other suitable period of time) after the link is established), which may increase transaction security. Additionally or alternatively, at step 508, the stored link between the verification data and one or both of the verification session identifier and the merchant identifier may also be associated with any suitable particular The transaction information (which may be made available to commercial entity subsystem 400 by merchant subsystem 200 during step 506) is associated (e.g., as part of a challenge request) with information such as identification of a specific type of security data to be shared between device 100 and merchant subsystem 200 (e.g., the currency and amount and payment type for a financial transaction (e.g., a $5 payment using a Visa payment credential configured on device 100), the type and amount of health care data for a health transaction (e.g., the last three days of heart rate data of a particular user detected or otherwise obtained by device 100), and / or the like), and similar specific transaction information may also be made available to commercial entity subsystem 400 by electronic device 100 as part of the device transaction data of step 514, so that step 516 may also include commercial entity subsystem 400 confirming that the specific transaction information currently stored against the verification data received in step 514 (e.g., as stored in table 430 in step 508) is at least similar to the specific transaction information received in step 514 to a certain extent, which may increase transaction security.For example, if at step 508 specific verification data is stored against specific transaction information associated with a potential transaction indicating a $5 financial transaction, but then at step 514 specific transaction information received by commercial entity subsystem 400 along with that specific verification data indicates a $2,000 financial transaction, then commercial entity subsystem 400 may be operable to not verify that verification data for the device transaction data due to the magnitude of the difference between $5 and $2,000 being greater than a specific threshold (e.g., more than a 5% difference). Thus, even if the verification data and verification session identifier and / or merchant identifier of the device transaction data received in step 514 are confirmed at commercial entity subsystem 400 to be actively linked (e.g., in table 430), the verification data may still not be verified if the device transaction data does not satisfy other data that may be associated with that link (e.g., if any suitable characteristic of the secure data transaction identified during verification step 506 differs from any suitable characteristic identified in the device transaction data of step 514 by any suitable amount (e.g., differs by more than 10% of the monetary value of the financial transaction, differs by more than 10% of the time frame of the health data, the type of health data is different, etc.)).

[0063] At step 518 of process 500, in response to verifying the verification data of the device transaction data at step 516, commercial entity subsystem 400 may further protect the security of the secure device data of the device transaction data by encrypting at least the secure device data of the device transaction data received at step 514 using a shared secret with merchant subsystem 200 such that the secure device data cannot be received and utilized by any entity other than merchant subsystem 200. For example, in response to verifying the verification data of the device transaction data at step 516 by confirming that the verification data of the device transaction data and the verification session identifier and / or merchant identifier are still properly linked at commercial entity subsystem 400 (e.g., in table 430), commercial entity subsystem 400 may consume that link (e.g., remove such association between the verification data and the verification session identifier and / or merchant identifier at commercial entity subsystem 400 (e.g., remove the link from table 430)) and proceed to step 518 for further protecting the security of the secure device data of the device transaction data. If the device transaction data of step 514 is encrypted using any business entity key, then at step 518, business entity subsystem 400 may be operable to decrypt such data (e.g., server 410 of business entity subsystem 400 may receive the device transaction data and then decrypt / remove the signature of that device transaction data (e.g., using access key 155a, access key 155b, CRS 151k, CASD158k, and / or ISD key 156k of business entity subsystem 400)). By communicating device transaction data between device 100 and business entity subsystem 400 in a form that is encrypted / signed using a business entity key known to both device 100 and business entity subsystem 400, process 500 may inhibit communication of that device transaction data from being intercepted and used by entities that do not have access to the business entity key. Additionally, at step 518, commercial entity subsystem 400 may be operable to encrypt or otherwise reformat at least a portion of the device transaction data with a merchant key (e.g., merchant key 157, which may be associated with merchant subsystem 200 for which funds for the particular transaction are being provided). Commercial entity subsystem 400 may determine and access this merchant key via table 430 (e.g., by identifying a merchant key associated with a merchant identifier of the device transaction data of step 514). At step 518, the merchant identifier may be received and utilized by commercial entity subsystem 400 to identify a particular one of a number of merchant keys accessible by commercial entity subsystem 400 (e.g., merchant key 157, by leveraging table 430 of commercial entity subsystem 400), and commercial entity subsystem 400 may then use that identified merchant key for encrypting at least a portion of the device transaction data (e.g., at least the secure device data of the device transaction data).By encrypting such secure device data with such a merchant key (e.g., a key known to commercial entity subsystem 400 and merchant subsystem 200, but not known to electronic device 100 or any other subsystem of system 1), such secure device data can be protected and securely transmitted from commercial entity subsystem 400 to merchant subsystem 200 without being intercepted by another entity and used for unintended purposes. The merchant key of the secure device data utilized by commercial entity subsystem 400 to encrypt at least the device transaction data at step 518 can be the same merchant key used by commercial entity subsystem 400 to encrypt the challenge data during authentication of the merchant online resource at step 506 (e.g., a key not available to device 100 or any subsystem other than commercial entity subsystem 400 and merchant subsystem 200). Thus, commercial entity subsystem 400 may be operable to facilitate a secure data transaction between device 100 and merchant subsystem 200 using a merchant online resource that has been recently authenticated by commercial entity subsystem 400 during a merchant authentication session specific to the secure data transaction (e.g., the authentication sessions of steps 504 and 506 and the secure data transactions of steps 516 and 518 may use the same authentication session identifier that is actively or otherwise enabled for a limited amount of time (e.g., a link between the authentication session identifier and the challenge data and / or a link between the authentication session identifier and the authentication data may be valid at commercial entity subsystem 400 for a limited amount of time (e.g., any suitable amount of time, such as between 30 seconds and 10 minutes)), which may increase transaction security).

[0064] Next, at step 520, process 500 may include commercial entity subsystem 400 transmitting the secured device data of step 518 to device 100 as secured transaction data. For example, at step 520, such merchant key-encrypted secured device data of device transaction data may be transmitted from commercial entity subsystem 400 to device 100 as at least a portion of the secured transaction data via communication path 65 using any suitable communication protocol. Such secured transaction data may include, in addition to the merchant key encrypted secure device data, any suitable data, such as any suitable data of step 502 associated with a transaction, including, but not limited to: (i) merchant-specific information, such as identification of a merchant identifier, which may identify the particular merchant subsystem 200 providing the potential transaction data of step 502; (ii) transaction-specific information, such as identification of a particular currency or amount used to pay for a financial transaction; (iii) a unique merchant-based transaction identifier (e.g., as generated by merchant subsystem 200 for association with an ongoing transaction); (iv) a unique device-based transaction identifier (e.g., as generated by electronic device 100 for association with an ongoing transaction); (v) the authentication session identifier, and / or the like. Thus, the secured transaction data transmitted from commercial entity subsystem 400 to device 100 at step 520 may include some or all of the potential transaction data of step 502 as well as the secured device data.

[0065] Next, at step 522 of process 500, device 100 may receive the secured transaction data transmitted from commercial entity subsystem 400 at step 520 and may share that secured transaction data with merchant subsystem 200 in any suitable manner. For example, such secured transaction data may be transmitted from communication component 106 of device 100 to server 210 of merchant subsystem 200 via communication path 15 and / or as contactless proximity-based communication between NFC component 120 and merchant terminal 220 using any suitable communication protocol. The securely protected transaction data that may be transmitted by device 100 to merchant subsystem 200 in step 522 (e.g., using merchant online resources 113 (e.g., the same resources used in step 502)) may include, in addition to the secure device data encrypted by the merchant key of step 520, any suitable data, such as any suitable data associated with the transaction, including but not limited to: (i) specific merchant information, such as identification of a merchant identifier that identifies the specific merchant subsystem 200 providing the potential transaction data of step 502; (ii) specific transaction information, such as identification of a specific currency or amount used to pay for the financial transaction; (iii) a unique merchant-based transaction identifier (e.g., as generated by merchant subsystem 200 for association with an ongoing transaction); (iv) a unique device-based transaction identifier (e.g., as generated by electronic device 100 for association with an ongoing transaction); (v) the verification session identifier, and / or the like. Thus, the secured transaction data shared with the merchant subsystem 200 at step 522 may include some or all of the potential transaction data of step 502 and at least the merchant key-encrypted secure device data of step 518. By transmitting the merchant key-encrypted secure device data of the secured transaction data at step 522, the process 500 may enable communication of such merchant key-encrypted secure device data to the merchant subsystem 200 for use in facilitating a particular secure data transaction while preventing the secure device data generated or otherwise identified by the device 100 at step 512 from being used by a merchant (or processor) entity that does not have access to the merchant key (e.g., a merchant subsystem or any other subsystem other than the merchant subsystem 200 of the system 1). Alternatively, although not shown, such secured transaction data may be transmitted directly from commercial entity subsystem 400 to merchant subsystem 200 in any suitable manner (e.g., via communications path 85 using any suitable communications protocol) (rather than via device 100 in steps 520 and 522), where commercial entity subsystem 400 may leverage any merchant identifier in the device transaction data of step 514 to identify the target merchant subsystem 200.After the merchant key-encrypted secure device data protecting the secure transaction data has been received by the merchant subsystem 200, the process 500 may include the merchant subsystem 200 utilizing that merchant key-encrypted secure device data for any suitable purpose (e.g., any suitable secure device data processing or disposal).

[0066] It should be understood that Figure 5 The steps shown in process 500 of are illustrative only, and existing steps may be modified or omitted, additional steps may be added, and the order of certain steps may be changed. It should be understood that if any authentication step of process 500 fails, such failure may be communicated to one or more appropriate entities. For example, if authentication of a merchant online resource fails at step 506 and / or if authentication of authentication data fails at step 516, such failure may be shared by commercial entity subsystem 400 with electronic device 100 so that device 100 may cancel a potential transaction with merchant subsystem 200 and potentially remove the merchant online resource from device 100. After a user of device 100 may select certain security data for use in the security data transaction at step 512, the remaining steps of process 500 may occur transparently to that user (e.g., steps 514 to 522 may occur without any further user interaction with device 100 and as instantaneous to the user of device 100). After step 512, process 500 appears to the user of device 100 as if secure device data was automatically and instantaneously sent to merchant subsystem 200 and the transaction status may be confirmed to device 100 (e.g., by merchant subsystem 200 and / or commercial entity subsystem 400). Additionally or alternatively, authentication of the merchant online resource may occur transparently to device 100 (e.g., steps 506-510 (if step 504 is not also included) may occur without any interaction with the user of device 100, and after step 502 it may appear to the user of device 100 to be instantaneous). Alternatively, in some embodiments, process 500 may occur completely transparently to the user of device 100 (e.g., where device 100 may be configured to automatically determine when a secure device transaction is appropriate and automatically receive authentication response data, and / or automatically send device transaction data, and / or automatically receive and / or send secured transaction data for secure device transactions without any active user interaction with device 100).

[0067] Figure 6 Description

[0068] Figure 66 is a flow chart of an illustrative process 600 for verifying online access to security device functionality for conducting financial transactions. Process 600 is shown as being implemented by electronic device 100, 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 smooth user experience for securely and efficiently conducting financial transactions with merchant subsystem 200 using payment credentials from device 100. To assist in the following discussion of methods for conducting financial transactions based on a payment method, Figure 6 A discussion of the operation of a system 1 for conducting financial transactions in a program 600, with reference to Figures 1 to 4 A schematic diagram of the various components of the system 1, and reference Figures 3 to 3D 190 to 190d, which may represent a graphical user interface of the device 100 during this transaction (e.g., a GUI such as may be provided by the merchant online resource 113 of the device 100 or any suitable application). A wide variety of graphical elements and visual schemes may be used to achieve the described operations. Thus, Figures 3 to 3D Embodiments of the process 600 are not intended to be limited to the precise user interface conventions employed herein. Rather, embodiments may include a wide variety of user interface styles. While the steps of the process 600 are described at least in part in the context of authenticating a merchant subsystem 200 for implementing secure payment functionality of an electronic device 100 accessed by the merchant subsystem 200, it should be understood that many (if not all) portions of the process 600 may be utilized for authenticating any suitable third-party subsystem for implementing any security functionality of the device 100 accessed by that third-party subsystem (e.g., location data, health data, or any other private data that is not appropriate to be shared with or received from a third-party subsystem that has not been validly authenticated, or otherwise).

[0069] Process 600 may begin at step 602, where access data 652 (e.g., Figure 1AFor example, an access SSD (e.g., SSD 154b) may be configured on secure element 145 of device 100 as access data 652 from server 410 of commercial entity subsystem 400 to more securely enable device 100 to conduct transactions with merchant subsystem 200. As mentioned, access SSD 154b may be at least partially configured on secure element 145 of 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 to secure element 145 (e.g., via bus 118)). Access data 652 may be configured on secure element 145 of device 100 via path 65 as at least a portion or all of access SSD 154b, and may include access applet 153b and / or access key 155b. Step 602 may be at least partially performed when device 100 is initially configured (e.g., by commercial entity subsystem 400 before device 100 is sold to a user). Alternatively or in addition, step 602 may be at least partially performed in response to a user of device 100 initially setting up secure element 145 of NFC component 120. In addition or alternatively, access data 652 may include ISD key 156k for ISD 152 of secure element 145, and ISD key 156k may be used in addition to or in lieu of access key 155b for secure transmission between commercial entity subsystem 400 and device 100. In addition or alternatively, access data 652 may include CRS 151k of CRS 151 of secure element 145 of device 100 and / or CASD 158k of CASD 158, and may be used in addition to or as an alternative to access key 155b and / or access key 155a and / or ISD key 156k for enabling secure transmission between commercial entity subsystem 400 and device 100 (e.g., as any suitable commercial entity key or shared secret between commercial entity subsystem 400 and device 100). Alternatively or in addition, access data 652 may include any other suitable commercial entity key or shared secret between commercial entity subsystem 400 and device 100 that may not be stored on the secure element of device 100 but is accessible to other portions of device 100 (such as processor 102) via memory 104.

[0070] At step 604 of process 600, the financial (or issuer or transaction) institution subsystem 350 may configure credential data 654 (e.g., Figure 1Acredential data 654), in some embodiments via commercial entity subsystem 400. For example, such credential data 654 may be at least partially configured on secure element 145 of device 100 directly from financial institution subsystem 350 (e.g., via a communication channel between financial institution subsystem 350 and device 100). Figure 1A In addition or alternatively, such credential data 654 may be at least partially configured on secure element 145 of device 100 via commercial entity subsystem 400 from financial institution subsystem 350 (e.g., via a communication path 75 between financial institution subsystem 350 and commercial entity subsystem 400). Figure 1A The communication path 55 may be between the server 410 of the commercial entity subsystem 400 and the communication component 106 of the device 100. Figure 1A 65 to device 100 as credential data 654, which may then be passed from communication component 106 to secure element 145 (e.g., via bus 118). Credential data 654 may be configured on secure element 145 of device 100 as at least a portion or all of credential SSD 154a via path 75 and / or via path 65, and may include credential applet 153a including credential information 161a and / or credential key 155a' and / or key 155ak. Step 604 may be at least partially performed when a user of device 100 selects a particular credential to be configured on device 100. In some embodiments, credential data 654 may also include access key 155a, which may be initially provided from commercial entity subsystem 400 to financial institution subsystem 350 and / or may be added by commercial entity subsystem 400. In some embodiments, such credential data 654 may include: a primary account number as at least a portion of the credential information for a configured payment credential (e.g., credential information 161a of applet 153a); an AID (e.g., AID 155aa of applet 153a for data of payment credentials configured at SSD 154a); an SSD identifier; and / or an SSD counter.

[0071] The credential data configured on device 100 may include all data necessary to make payments with that credential (when that credential is a financial or payment credential), such as, for example, a primary account number (“PAN”), a card security code (e.g., a card verification code (“CVV”)), a PAN expiration date, a name associated with the credential, and the like, as well as other data operable by device 100 to generate appropriate cryptographic data (e.g., any suitable shared secret and any suitable cryptographic algorithm or encryption method whose functional output may be determined at least in part by the shared secret). A “virtual” credential or virtual PAN or device PAN (“D-PAN”) may be configured on device 100 instead of a user’s “actual” credential or actual PAN or fund PAN (“F-PAN”). For example, once it is determined that a credential is to be configured 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 a virtual credential (rather than an actual credential) to be generated, linked to the actual credential, and configured on device 100. Such establishment and linking of a virtual credential with an actual credential may be performed by any suitable component of the 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 the actual credential) may define and store a virtual link table 312 (e.g., such as a table of virtual links) that may establish an association between the actual credential and the virtual credential. Figure 1A ), such that at any time a virtual credential is utilized by device 100 for a financial transaction with merchant subsystem 200 (e.g., after being configured on device 100), payment network subsystem 360 may receive an authorization or verification request or otherwise attempt to verify any received data indicative of that virtual credential (e.g., at step 640 in response to receiving data 688 at step 638) and may analyze that verification attempt request in accordance with the actual credential associated with the virtual credential as determined by table 312. Alternatively, such table may be accessed and / or likewise utilized by an appropriate issuing bank subsystem 370 or any other suitable subsystem accessible by financial institution subsystem 350. By configuring virtual credentials (rather than actual credentials) on device 100, financial institution subsystem 350 may be configured to limit fraudulent activity that may result when virtual credentials are intercepted by unauthorized users because payment network subsystem 360 may only be configured to utilize table 312 for linking the virtual credential to the actual credential during certain transactions.

[0072] At step 606 of process 600, commercial entity subsystem 400 may register merchant subsystem 200. For example, as described with respect to step 501 of process 500, at step 606, a merchant online resource 113 (e.g., a native application, a domain / URL, or any other suitable web resource, or perhaps even a merchant terminal) of merchant subsystem 200 may be associated with at least a specific merchant identifier 167 and at least a specific merchant key 157, each of the at least one specific merchant identifier 167 and the at least one specific merchant key 157 may be securely shared between merchant subsystem 200 and commercial entity subsystem 400 in any suitable manner, and this association may be accessible to commercial entity subsystem 400 (e.g., in form 430) so that the merchant online resource 113 may be registered with commercial entity subsystem 400. In some embodiments, in order to participate in an online resource payment program, the merchant may be required to register as a member of a program implemented by a commercial entity of commercial entity subsystem 400 and / or obtain merchant credentials. In the absence of credentials or other suitable evidence of registration, the merchant cannot receive payment data. Regardless of how or where such merchant key(s) and / or merchant identifier(s) may be generated and / or managed, both merchant subsystem 200 and commercial entity subsystem 400 may store versions of the merchant key of any merchant key pair (e.g., in respective secure elements of merchant subsystem 200 and commercial entity subsystem 400). This may enable a shared secret between commercial entity subsystem 400 and merchant subsystem 200 for securely transmitting data therebetween. In some embodiments, device 100 may be provided with such a merchant key for securely encrypting payment data using that key on device 100.

[0073] At step 608 of process 600, device 100 may access the merchant's online resources 658 (e.g., Figure 1A Merchant online resources 113 (e.g., as registered in step 606)). Figure 1A The resource application 113 of the merchant shown in FIG. 4 can be loaded onto the device 100 from the commercial entity subsystem 400 (e.g., from the application store 420). Figure 3, a user of device 100 may use touch screen input component 110f of I / O component 114a to select a "Merchant Application" icon 183 of a particular screen 190 of GUI 180, and this selection may be recognized by device 100 as an initiating event for providing the user with the ability to interact with a merchant third-party application 113 (e.g., a native application that executes at least in part on device 100, such as may have been accessed by device 100 via commercial entity subsystem 400 (e.g., as a registered merchant online resource of application store 420)). Alternatively or in addition, the merchant's resources 658 may be accessed by device 100 directly from merchant subsystem 200 (e.g., via server 210 or terminal 220). In response to this selection of the merchant application icon, the GUI may provide an interactive screen in which device 100 may enable the user to interact with application 113 (e.g., to peruse items available from the merchant for purchase, or to determine certain health data or location data or other to be shared with the merchant). Alternatively, step 608 may include device 100 accessing a merchant's resource 658 as a merchant Web resource from merchant subsystem 200 (e.g., via merchant server 210 or any server at least partially controlled by a merchant entity) using: an Internet application of device 100 (which may also be accessed through an "Internet" icon (e.g., Figure 3 Alternatively, step 608 may include any suitable automatic access to resource 658 as merchant online resource 113 without active user input (e.g., device 100 may be operable to automatically interact with resource 658 in response to detecting any suitable event, such as autonomous home appliance device 100 detecting that it is executing in the event that a particular supply is low (e.g., washing machine device 100 responds to detecting a low laundry detergent supply)).

[0074] Next, at step 610, device 100 may receive potential transaction data 660 from the accessed merchant resource (e.g., as described with respect to step 502 of process 500). Figure 1A, potential transaction data 660 may be provided to device 100 from merchant subsystem 200 (e.g., from merchant server 210) while device 100 is interacting with a merchant's resource 113 (e.g., a merchant's third-party application or website or any other suitable online resource (e.g., resource 658)). Alternatively or in addition, at least a portion of potential transaction data 660 may be accessed locally by device 100 via application 113 local to device 100 (e.g., while application 113 is stored in a memory component or being executed by processor 102 of device 100), rather than actively sending data to device 100 from merchant server 210 at step 610. For example, when application 113 may be initially stored on device 100 (e.g., at step 608, as a merchant's resource 658 (e.g., loaded from application store 420)), at least some of potential transaction data 660 may be generated by the initially stored application 113 without any additional information provided to device 100 by merchant subsystem 200. Potential transaction data 660 may include any suitable data indicating any suitable characteristics of a potential financial transaction occurring between a user of device 100 and a merchant of merchant subsystem 200, including, but not limited to: (i) specific merchant information, such as a unique merchant identifier (e.g., an acquiring bank merchant identifier and / or a commercial entity merchant identifier (e.g., merchant identifier 167, as may be registered in step 610)) and / or identification of a specific merchant resource in use (e.g., a specific merchant application 113); (ii) specific transaction information, such as identification of a specific currency used for payment of the transaction (e.g., Japanese Yen, British Pounds, U.S. Dollars, etc.), and / or the transaction The potential transaction data 660 may include any suitable number and type of data fields (with or without associated data) that may be necessary or at least useful for completing a financial transaction, such as fields for contact information of the customer making the purchase (e.g., phone number, email address, mail address), some of which may be populated and included as part of such potential transaction data 660, and / or some of which may not be populated as part of such potential transaction data 660, but may be open and awaiting population during process 600.Such potential transaction data 660 of step 610 may be referred to herein as a PKDataRequest or a PKPaymentRequest (e.g., for financial transactions). Alternatively, as mentioned, the user may not actively interact with device 100 to make potential transaction data 660 associated with merchant subsystem 200 available to device 100 at step 610.

[0075] For communication of secure payment data, potential transaction data 660 may include a request for device 100 to generate a merchant resource for a payment token for purchasing 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, payment amount, and currency code. Potential transaction data 660 may also include a list of one or more payment networks (e.g., payment network(s) 360) that the merchant may support, such that device 100 may be configured to determine whether any of such listed one or more payment networks have authorized payment credentials on device 100 or on any suitable host device that device 100 may use as a client. In some embodiments, once such potential transaction data 660 is accessed by device 100, such as Figure 3A As shown in , for example, the GUI of device 100 may provide screen 190a in which a merchant's resources may use transaction data 660 to display any suitable information associated with a potential transaction to a user of device 100, such as displaying the name of the merchant with information 307a (e.g., "Merchant A"), displaying the name of the product with information 307b (e.g., "Product B"), displaying the price with information 307c (e.g., "Price C"), and / or displaying initial shipping data with information 307d (e.g., "Address D"). Potential transaction data 660 that may be provided to device 100 by merchant subsystem 200 may indicate such information 307a, 307b, 307c, and / or 307d. A user of device 100 may interact with device 100 and screen 190a to adjust certain portions of such information (e.g., shipping address, etc.), which may require updated potential transaction data to be generated and shared by merchant subsystem 200 (e.g., in another instance of step 610). As also shown in FIG. Figure 3A As shown and described in more detail below, screen 190a may also include a secure payment prompt 309. At least a portion of the potential transaction data 660 may be provided via Figure 1AThe communication path 15 is provided from the merchant subsystem 200 to the device 100 and may be received by the communication component 106 of the device 100. The communication component 106 may pass this potential transaction data 660 to the processor 102 (e.g., for display on the screen 190a as part of the user interface on the device 100 (e.g., for information 307a-307d and 309)) and / or to the secure element 145. For example, the secure element 145 may utilize at least a portion of such potential transaction data 660 for securely implementing a financial transaction between the device 100 and the merchant subsystem 200. In some embodiments, the potential transaction data 660 may be referred to as merchant payment request data and / or a uniform resource locator ("URL") or any other suitable reference character string and / or query string.

[0076] At step 612 of process 600, a merchant online resource authentication session may be initiated. As mentioned with respect to step 504 of process 500, step 612 may occur in response to electronic device 100 indicating that a secure data transaction (e.g., a secure data transaction (e.g., a financial transaction) identified by potential transaction data 660 of step 610) should occur. This indication may occur in response to a user of device 100 selecting a GUI element (e.g., a radio button) of a merchant online resource, such as Figure 3A 610, for communicating that the user desires to conduct a secure data transaction identified by the potential transaction data 660 of the merchant online resource of step 610. Alternatively, this indication may occur automatically based on any suitable requirement being satisfied (e.g., simply in response to the potential transaction data 660 of step 610 being transmitted to the device 100). For example, when this indication occurs, the merchant online resource 113 (e.g., a Web kit for Web resources) may be operable to send a secure data transaction request to the card management application 103b (e.g., a pass kit for payment secure data transactions), and then the device 100 (e.g., the card management application 103b of the device 100 or any other suitable application) may be operable to receive and process the secure data transaction request, and in response, at step 612, may then be operable to generate and transmit the merchant online resource verification session initiation data 662 to the merchant subsystem 200.

[0077] At step 612, any suitable data may be generated and / or transmitted by the electronic device 100 to the merchant subsystem 200 as merchant online resource authentication session initiation data 662 for initiating a merchant online resource authentication session for a particular secure data transaction to be conducted (e.g., data 660 and / or Figure 3AFor example, at step 612, a verification session identifier may be generated by the electronic device 100 and transmitted to the merchant subsystem 200 as at least a portion of the merchant online resource verification session initiation data 662, wherein the verification session identifier may be any suitable alphanumeric string or any other suitable identifier that uniquely identifies the merchant online resource verification session currently being initiated (e.g., uniquely identifies such a session to the merchant subsystem 200 and / or to the commercial entity subsystem 400 for at least a certain period of time). In addition or alternatively, at step 612, a challenge request target identifier (e.g., a challenge request URL) may be transmitted from the device 100 to the merchant subsystem 200 as at least a portion of the merchant online resource verification session initiation data 662, wherein the challenge request target identifier may identify the entity with which the merchant subsystem 200 is to communicate to verify the merchant (e.g., a URL identifying a server 410 of the commercial entity subsystem 400 that is to cooperate with the merchant subsystem 200 to verify the merchant online resource for the specific secure data transaction to be conducted). The device application (e.g., card management application 103b) may have such a challenge request target identifier programmed (as part of any suitable operating system or application update), which may be controlled by commercial entity subsystem 400 such that the challenge request target identifier on device 100 may be updated by commercial entity subsystem 400 at any suitable time. In addition or alternatively, such merchant online resource verification session initiation data 662 may include any other suitable data, such as: any suitable data indicating a request for the merchant to verify itself; and / or the specific merchant online resource accessed at step 608 and utilized at step 610 for receiving potential transaction data 660; any suitable data indicating device 100 (e.g., device identifier 119); and / or any suitable data indicating a specific secure data transaction to be conducted (e.g., any suitable data from potential transaction data 660 of step 610, such as specific merchant information (e.g., merchant identifier 167 of the merchant online resource), specific transaction information (e.g., currency and amount and payment type for the financial transaction), and / or a unique merchant-based transaction identifier). At step 612, any suitable merchant online resource authentication session initiation data 662 may be transmitted by the device 100 to the merchant subsystem 200 in any suitable manner (e.g., such merchant online resource authentication session initiation data 662 may be transmitted from the communication component 106 of the device 100 to the server 210 of the merchant subsystem 200 via the communication path 15 using any suitable communication protocol, or via a contactless proximity-based communication channel between the terminal 220 and the NFC component 120 using any suitable communication protocol).

[0078] At step 614 of process 600, in response to the merchant subsystem 200 receiving at step 612 any suitable merchant online resource authentication session initiation data 662 from the device 100 for initiating an authentication session with the merchant online resource 113, the merchant subsystem 200 is operable to transmit any suitable challenge request data 664 to the commercial entity subsystem 400 for authenticating the merchant online resource for the particular secure data transaction to be conducted (e.g., a financial payment transaction as identified at step 610 and / or step 612). The challenge request data 664 transmitted from the merchant subsystem 200 to the commercial entity subsystem 400 at step 614 may include any suitable data for attempting to verify the validity of the merchant subsystem 200 (e.g., the merchant resource 113) to the commercial entity subsystem 400, including, but not limited to: a merchant identifier associated with the merchant online resource to be verified (e.g., at least one merchant identifier 167 as registered at step 606, which may be the domain of the merchant online web resource); a verification session identifier (e.g., as generated by the electronic device 100 at step 504, or generated by the merchant subsystem 200 at step 506); and any other suitable data (e.g., data identifying the device 100 and / or data identifying a specific secure data transaction to be conducted). For example, the merchant identifier of the challenge request data 664 may be any suitable merchant identifier 167 associated with the merchant online resource used at step 610 (which initiated the current merchant online resource verification session). When the merchant online resource verification session initiation data 662 of step 612 includes a verification session identifier (e.g., as generated by the electronic device 100), then that verification session identifier may be provided by the merchant subsystem as at least a portion of the challenge request data 664 at step 614. However, when the merchant online resource verification session initiation data 662 of step 612 does not include a verification session identifier, or when a merchant online resource verification session may be initiated automatically by the merchant subsystem 200 (e.g., in response to transmitting the potential transaction data 660 of step 610) rather than in response to any merchant online resource verification session initiation data 662 of step 612, the merchant subsystem 200 may be operable to generate that verification session identifier that uniquely identifies the merchant online resource verification session currently being initiated, and then may be operable to include that verification session identifier as at least a portion of the challenge request data 664 at step 614.In some embodiments, at step 614, any suitable additional information that may be specific to the secure data transaction to be conducted (e.g., a financial payment transaction as identified in steps 610 and / or 612) may be provided as at least a portion of the challenge request data 664, including, but not limited to, information indicating: "Product B" of information 307b of the potential transaction data, "Price C" of information 307c of the potential transaction data, "Address D" of shipping data of information 307d of the potential transaction data, "Credential X" information 313 identifying payment credentials for the potential transaction data, and / or any other suitable information associated with the secure data transaction to be conducted that may be suitable for sharing with the business entity subsystem 400 (e.g., in accordance with any privacy considerations regarding any person having such data), such as "heart rate information from the last three days" rather than actual heart rate information (if the secure data transaction to be conducted is a health data transaction). Such information, which may be specific to a secure data transaction (which may be referred to herein as potential transaction identification information), may be used during any suitable portion of process 600, for providing any additional security layer(s) to the current data transaction process, and / or for providing any additional security (e.g., fraud detection) services for future data transactions. Challenge request data 664 may be signed (e.g., in an HTTP header or otherwise) by merchant subsystem 200 using a merchant key usable by merchant subsystem 200 and associated with the merchant identifier of the challenge request (e.g., merchant key 157 as registered with merchant identifier 167 at step 606 (e.g., for the merchant online resource 113 to be authenticated)) so that challenge request data 664 may be effectively utilized by commercial entity subsystem 400 for authenticating merchant online resource 113. Any suitable challenge request data 664 may be communicated by merchant subsystem 200 to commercial entity subsystem 400 in any suitable manner at step 614 (e.g., such challenge request data 664 may be transmitted from server 210 of merchant subsystem 200 to server 410 of commercial entity subsystem 400 via communication path 85 using any suitable communication protocol). Such communication of challenge request data 664 may be appropriately addressed to commercial entity subsystem 400 based on a challenge request target identifier (e.g., a challenge request URL) that may be communicated from device 100 to merchant subsystem 200 at step 612 as at least a portion of merchant online resource authentication session initiation data 662.Alternatively or in addition, such communication of challenge request data 664 may be appropriately addressed to commercial entity subsystem 400 based on a challenge request target identifier (e.g., a challenge request URL) that is accessible to merchant subsystem 200 and associated with the potential transaction data 660 of step 610 (e.g., an identifier identifying commercial entity subsystem 400 may be associated with any code (e.g., javascript code for a web resource) or with any suitable "secure transaction" prompt that is usable by merchant subsystem 200 in providing within a merchant online resource (e.g., Figure 3A The secure payment prompt 309)) is associated with others.

[0079] At step 616 of process 600, in response to commercial entity subsystem 400 receiving any suitable challenge request data 664 from merchant subsystem 200 at step 614, commercial entity subsystem 400 may be operable to verify the merchant online resource 113 identified by the merchant identifier 167 of the challenge request. For example, at step 616, commercial entity subsystem 400 may be operable to attempt to confirm that the merchant online resource 113 identified by the merchant identifier 167 of the received challenge request data 664 at commercial entity subsystem 400 is a valid and registered merchant online resource, which may be confirmed by identifying that merchant identifier 167 in form 430 (e.g., to determine that merchant identifier 167 has been registered with commercial entity subsystem 400 (e.g., at step 606), and determining that such registration is still valid (e.g., that commercial entity subsystem 400 has not removed merchant identifier 167 from form 430 or has not entered merchant identifier 167 into form 430). Flag as suspicious or otherwise no longer trusted, and / or determine that credentials associated with merchant identifier 167 (e.g., in table 430) are still valid); and / or by identifying a domain associated with or identified by that merchant identifier 167 and revalidating that domain by revalidating a profile that may be hosted on that domain (e.g., as described with respect to steps 501 and / or 606), wherein such revalidation may alternatively or in addition be performed by commercial entity subsystem 400 at any suitable time (e.g., periodically or otherwise), and not necessarily in response to receiving data 664 at step 616.Additionally or alternatively, at step 616, commercial entity subsystem 400 may be operable to attempt to verify the signature of received challenge request data 664, which may be accomplished by identifying merchant key 157 (which may be associated with merchant identifier 167 of received challenge request data 664 (in table 430 at commercial entity subsystem 400 or otherwise at commercial entity subsystem 400 (e.g., an association that may have been established during registration at step 606))), and then utilizing that identified merchant key 157 to verify the signature of received challenge request data 664 (e.g., to confirm that merchant key 157 is accessible to commercial entity subsystem 400). 157 is one of a paired key group together with a merchant key 157 accessible to merchant subsystem 200. Before transmitting challenge request data 664 to commercial entity subsystem 400 in step 614, merchant subsystem 200 may have used merchant key 157 to sign challenge request data 664 (for example, one of such keys may be a public key and the other may be a private key of the paired key group), which ensures that merchant subsystem 200 holds merchant key 157 that may need to be used by merchant subsystem 200 in (one or more) later parts of process 600 (for example, in step 636, at which step merchant subsystem 200 may decrypt data previously encrypted by commercial entity subsystem 400). After any suitable verification of received challenge request data 664 by commercial entity subsystem 400 (e.g., after verification of a merchant identifier and / or a signature of received challenge request data 664), commercial entity subsystem 400 may also be operable to generate any suitable challenge data and store that challenge data against any suitable identifier data of received challenge request data 664 at step 616. For example, after any suitable verification of received challenge request data 664, commercial entity subsystem 400 may be operable to generate any suitable challenge data (e.g., any suitable random data via entropy) and then store that challenge data against one or both of a verification session identifier of challenge request data 664 and a merchant identifier of challenge request data 664 in any suitable data structure accessible to commercial entity subsystem 400 (e.g., in table 430 or otherwise). This stored link or association between such challenge data and the identifier data of the authentication session (e.g., the authentication session identifier and / or the merchant identifier of the challenge request data 664) may later be used by commercial entity subsystem 400 to further authenticate the merchant online resource of the authentication session (e.g., at step 622) and / or to further secure the secure data transaction to be effected (e.g., at step 630). Additionally, in some embodiments, any or all of the potential transaction identification information of the challenge request data 664 may also be stored against or otherwise associated with the challenge data and the identifier data.

[0080] At step 618 of procedure 600, in response to commercial entity subsystem 400 verifying received challenge request data 664 and generating challenge data against identifier data of the verification session at step 616, commercial entity subsystem 400 may be operable to encrypt the challenge data of step 616 using any suitable key or otherwise and may then be operable to transmit that encrypted challenge data along with any other suitable data as challenge data 668 to merchant subsystem 200. For example, commercial entity subsystem 400 may encrypt the challenge data using any suitable merchant key 157 accessible to commercial entity subsystem 400 and associated with merchant identifier 167 of the received challenge request data 664 (e.g., in table 430 at commercial entity subsystem 400 or otherwise at commercial entity subsystem 400 (e.g., an association that may have been established during registration in step 606)), where this merchant key 157 used by commercial entity subsystem 400 to encrypt the challenge data in step 618 may be the same as or different from the merchant key 157 that may have been used by commercial entity subsystem 400 to verify challenge request data 664 in step 616. In addition to such encrypted challenge data, any other suitable data may be included as part of the challenge data 668 transmitted by commercial entity subsystem 400 to merchant subsystem 200 in step 618, including, but not limited to: a hash of the merchant key 157 used by commercial entity subsystem 400 to encrypt the challenge data (e.g., a hashed version of the public merchant key 157 of table 430, which may be received by merchant subsystem 200 and used to identify the appropriate merchant key 157 (e.g., the private key 157 of merchant subsystem 200 used to decrypt the challenge data), the hashed version may be provided to assist merchants who may have multiple registered merchant online resources and / or multiple merchant keys); a verification session identifier of the challenge request data 664; a merchant identifier of the challenge request data 664; a merchant identifier associated at commercial entity subsystem 400 (e.g., in table 430) with the merchant key 157 used by commercial entity subsystem 400 to encrypt the challenge data; and / or the like. At step 618, any suitable challenge data 668 may be transmitted by commercial entity subsystem 400 to merchant subsystem 200 in any suitable manner (e.g., such challenge data 668 may be transmitted from server 410 of commercial entity subsystem 400 to server 210 of merchant subsystem 200 via communication path 85 using any suitable communication protocol).

[0081] At step 620 of process 600, in response to the merchant subsystem 200 receiving such challenge data 668 at step 618, the merchant subsystem 200 may be operable to process the received challenge data 668 and then generate and transmit challenge response data 670 to the commercial entity subsystem 400 for further authentication of the merchant subsystem 200 during the current authentication session. For example, at step 620, the merchant subsystem 200 may be operable to decrypt the encrypted challenge material of the received challenge data 668 using any suitable merchant key 157 available to the merchant subsystem 200 (e.g., a merchant key 157 registered with the merchant identifier 167 at step 606 (e.g., for the merchant online resource 113 being authenticated during the current authentication session)). This merchant key 157 used by the merchant subsystem 200 to decrypt the encrypted challenge material at step 620 may be identified by the merchant subsystem 200 using: any hash key information of the challenge data 668; and / or any merchant identifier of the challenge data 668; and / or any merchant identifier by using the challenge request data 664 (e.g., as may be associated with a common session identifier of the data 664 and the data 668). This merchant key 157 used by the merchant subsystem 200 to decrypt the encrypted challenge data at step 620 may be the same as or different from the merchant key 157 that may have been used by the merchant subsystem 200 to sign the challenge request data 664 at step 614. After decrypting the encrypted challenge data of the received challenge data 668, at step 620, the merchant subsystem 200 is also operable to generate and transmit challenge response data 670 from the merchant subsystem 200 to the commercial entity subsystem 400, wherein the challenge response data 670 may include the challenge data as decrypted by the merchant subsystem 200 (for further attempting to verify the validity of the merchant subsystem 200 (e.g., merchant resource 113) to the commercial entity subsystem 400) together with any other suitable data, including, but not limited to: an authentication session identifier for the current authentication session (e.g., a valid session identifier for the challenge request data 664); identifier, and / or a valid session identifier for received challenge data 668); a merchant identifier associated with a merchant online resource being authenticated through the current authentication session (e.g., the merchant identifier of challenge request data 664, a merchant identifier associated at commercial entity subsystem 400 (e.g., in table 430) with a merchant key 157 used by commercial entity subsystem 400 to encrypt the challenge data, and / or the like); any or all suitable potential transaction identification information for the secure data transaction to be conducted, which may or may not be included in challenge request data 664 of step 614; and / or the like.The challenge response data 670 may be signed by the merchant subsystem 200 (e.g., in an HTTP header or otherwise) using a merchant key usable by the merchant subsystem 200 (e.g., a merchant key 157 as registered with the merchant identifier 167 at step 606 (e.g., for the merchant online resource 113 currently being authenticated)) so that the challenge response data 670 may be effectively utilized by the commercial entity subsystem 400 for further authentication of the merchant online resource 113. This merchant key 157 that may be used by the merchant subsystem 200 to sign the challenge response data 670 at step 620 may be the same as or different from the merchant key 157 that may have been used by the merchant subsystem 200 to sign the challenge request data 664 at step 614. Additionally or alternatively, this merchant key 157 that may be used by the merchant subsystem 200 to sign the challenge response data 670 at step 620 may be the same as or different from the merchant key 157 that may have been used by the merchant subsystem 200 to decrypt the encrypted challenge material at step 620. At step 620, any suitable challenge response data 670 may be transmitted by merchant subsystem 200 to commercial entity subsystem 400 in any suitable manner (e.g., such challenge response data 670 may be transmitted from server 210 of merchant subsystem 200 to server 410 of commercial entity subsystem 400 via communication path 85 using any suitable communication protocol).

[0082] At step 622 of process 600, in response to commercial entity subsystem 400 receiving any suitable challenge response data 670 from merchant subsystem 200 at step 620, commercial entity subsystem 400 may be operable to further authenticate merchant subsystem 200 and the merchant online resource of interest thereto in the current authentication session. For example, at step 622, commercial entity subsystem 400 may be operable to attempt to authenticate the signature of the received challenge response data 670, which may be accomplished by: identifying merchant key 157 (which may be associated with the authentication session identifier of the received challenge response data 670 in table 430, or merchant key 157 which may be associated with merchant identifier 167 of the received challenge response data 670 in table 430 or otherwise at commercial entity subsystem 400 (e.g., an association that may have been established during registration at step 606); )), and then utilize that identified merchant key 157 to verify the signature of the received challenge response data 670 (e.g., to confirm that the merchant key 157 accessible to commercial entity subsystem 400 is one of a paired key set along with a merchant key 157 accessible to merchant subsystem 200, which may have been signed by merchant subsystem 200 using merchant key 157 (e.g., one of such keys may be a public key and the other may be a private key of the paired key set) before transmitting challenge response data 670 to commercial entity subsystem 400 at step 620). The merchant key 157 that may be used by commercial entity subsystem 400 to verify the signature of challenge response data 670 may be the same as or different from the merchant key 157 that may have been used by commercial entity subsystem 400 to verify the signature of challenge request data 664 at step 616, and / or the merchant key 157 that may be used by commercial entity subsystem 400 to verify the signature of challenge response data 670 at step 622 may be the same as or different from the merchant key 157 that may have been used by commercial entity subsystem 400 to encrypt the challenge data at step 618. Additionally or alternatively, at step 622 , commercial entity subsystem 400 may be operable to attempt to confirm that the decrypted challenge data of received challenge response data 670 is valid challenge data. For example, commercial entity subsystem 400 may be operable to attempt to confirm that the decrypted challenge data of received challenge response data 670 is currently stored or otherwise independently accessible to commercial entity subsystem 400 (e.g., in table 430). In some embodiments, commercial entity subsystem 400 may determine the validity of the decrypted challenge data of received challenge response data 670 by identifying that the same challenge data is currently stored in table 430.Alternatively, commercial entity subsystem 400 may determine the validity of decrypted challenge data of received challenge response data 670 by identifying challenge data that is identical to any suitable identifier data (e.g., a verification session identifier or a merchant identifier) ​​currently against which received challenge response data 670 is compared (as may have been stored in table 430 in step 616). In some embodiments, this stored link between the challenge data and one or both of the verification session identifier and the merchant identifier (or such stored challenge data itself) may be maintained by commercial entity subsystem 400 for only a limited amount of time before automatically clearing the link or stored data, such that merchant subsystem 200 may be constrained to having to receive challenge data 668 and then send appropriate challenge response data 670 to commercial entity subsystem 400 within a certain duration for authenticating the merchant online resource for a particular verification session (e.g., commercial entity subsystem 400 may be operable to remove this association between the challenge data and the verification session identifier and / or merchant identifier at commercial entity subsystem 400 after a certain period of time (e.g., removing the link or challenge data from table 430 no more than 10 minutes after the link or challenge data is established), which may increase transaction security). Thus, one or more associations between a merchant key and a merchant identifier at commercial entity subsystem 400 (e.g., as registered in step 608) may be used to complete verification of a merchant online resource for a particular secure data transaction to be conducted (e.g., as identified in steps 610 and / or 612) in any or all of steps 614 through 622.

[0083] After any suitable verification of the received challenge response data 670 by the business entity subsystem 400 (e.g., after verifying the signature of the received challenge response data 670 and / or after verifying the decrypted challenge data of the received challenge response data 670), in step 622, the business entity subsystem 400 may also be operated to generate any suitable verification data and store that verification data against any suitable identifier data of the received challenge request data 664 and / or any suitable identifier data of the received challenge response data 670. For example, after performing any suitable verification of received challenge request data 664 and / or received challenge response data 670, commercial entity subsystem 400 may be operable to generate any suitable verification data (e.g., any suitable random data via entropy and / or any suitable cryptographic nonce) and then store that verification data against one or both of the verification session identifier and the merchant identifier of any one or both of challenge request data 664 and challenge response data 670 in any suitable data structure accessible to commercial entity subsystem 400 (e.g., in table 430 or otherwise). This stored link or association between such verification data and the identifier data of the verification session (e.g., the verification session identifier and / or the merchant identifier of challenge request data 664 and / or the verification session identifier and / or the merchant identifier of challenge response data 670) may later be used by commercial entity subsystem 400 to further secure the secure data transaction to be conducted (e.g., at step 630). Additionally, in some embodiments, any or all of the potential transaction identifying information of the challenge request data 664 and / or any or all of the challenge response data 670 may also be stored against or otherwise associated with the verification data and identifier data.

[0084] In response to verifying the challenge data by confirming that the decrypted challenge data of challenge response data 670 received at commercial entity subsystem 400 (e.g., in table 430) is linked to identifier information (e.g., verification session identifier and / or merchant identifier information), at step 622, commercial entity subsystem 400 is operable to: consume that link (e.g., remove such association between the challenge data and the verification session identifier and / or merchant identifier at commercial entity subsystem 400 (e.g., remove the link from table 430)); generate verification data (e.g., , any suitable random data (e.g., a cryptographically compiled nonce (e.g., any suitable random data via entropy)); and then storing or otherwise associating the verification data with any suitable identifier information (e.g., a verification session identifier for the challenge request and / or a verification session identifier for the challenge response, and / or a merchant identifier for the challenge request and / or a merchant identifier for the challenge response) at commercial entity subsystem 400 (e.g., in accordance with any suitable data structure, such as table 430 or otherwise). Alternatively, in response to verifying the challenge data by confirming that the decrypted challenge data of the challenge response data 670 received at commercial entity subsystem 400 (e.g., in table 430) is linked to the identifier information (e.g., the verification session identifier and / or the merchant identifier information), commercial entity subsystem 400 may be operable to maintain that link at commercial entity subsystem 400 or otherwise update that link (e.g., reset any timer that may be associated with that link at commercial entity subsystem 400 (e.g., in table 430), or add any additional potential transaction identifying information for association with the link), at step 622, and then utilize the challenge data of that link (e.g., as generated at step 616) as the verification data that may otherwise be generated at step 622. In some embodiments, the challenge data and verification data may differ with respect to size or any other suitable attribute or attributes, in that the challenge data used at steps 618-622 may differ from the verification data used at steps 624-630.

[0085] At step 624 of process 600, in response to commercial entity subsystem 400 validating received challenge request data 664 and / or validating received challenge response data 670 and generating or otherwise defining verification data against identifier data for the verification session at step 622, commercial entity subsystem 400 may be operable to generate and transmit any suitable verification response data 674. For example, verification response data 674 may include the verification data of step 622 along with any other suitable data, including (but not limited to): the verification session identifier (e.g., the verification session identifier of challenge request data 664 and / or the verification session identifier of challenge response data 670 and / or as otherwise associated with the verification session); a merchant identifier (e.g., the merchant identifier of challenge request data 664 and / or the merchant identifier of challenge response data 670; and / or as otherwise associated at commercial entity subsystem 400 (e.g., in table 430) with the merchant online resource being authenticated during the verification session); and / or the like. In some embodiments, as Figure 6As shown in , such verification response data 674 may be transmitted directly from the business entity subsystem 400 to the electronic device 100 (e.g., via the communication path 65 using any suitable communication protocol), wherein data identifying the electronic device 100 (e.g., the device identifier 119) may be associated with or otherwise included in the verification session initiation data 662 and / or the challenge request data 664 and / or the challenge response data 670, or others, so that the business entity subsystem 400 can transmit the verification response data 674 to the appropriate electronic device 100. Alternatively, in some embodiments, verification response data 674 may be transmitted from commercial entity subsystem 400 to electronic device 100 via merchant subsystem 200, whereby merchant subsystem 200 may receive verification response data 674 from commercial entity subsystem 400 (e.g., via communication path 85 using any suitable communication protocol) and then pass at least a portion of verification response data 674 to electronic device 100 (e.g., via communication path 15 using any suitable communication protocol or as a contactless proximity-based communication), such that commercial entity subsystem 400 may not need to establish a secure communication channel directly with device 100 in step 624. The verification response data 674 may be signed (e.g., in an HTTP header or otherwise) by the commercial entity subsystem 400 using an access key associated with the commercial entity subsystem 400 (e.g., access key 155a, access key 155b, CRS 151k, and / or ISD key 156k of the secure element 145, or any key known to a device application (e.g., card management application 103b)), and the electronic device 100 may also access the access key so that the device 100 may verify the signature upon receiving the signed verification data to confirm that the verification response data 674 was generated by the commercial entity subsystem 400 rather than another entity subsystem that is not trusted by the electronic device 100, and / or so that the signed verification data will not be utilized by an entity that does not have access to the access key (e.g., merchant subsystem 200, which may be used to pass the signed verification data from the commercial entity subsystem 400 to the device 100).

[0086] As mentioned, a user of device 100 may select a GUI element (e.g., a radio button) of a merchant online resource, such as Figure 3A The secure payment prompt 309 is used to convey that the user wants to conduct a secure data transaction identified by the potential transaction data 660 of the merchant online resource of step 610. Figure 3B As shown in FIG. 1 , the device 100 and / or the merchant online resource 113 may be configured to provide a screen 190b that is provided in response to receiving a request for Figure 3AIn response to selecting the secure payment prompt 309 of screen 190a or in addition to receiving the verification response data 674 (which may indicate that there was no verification session failure) at step 624, and / or in response to the device 100 verifying the consistency between the session identifier that may have been generated by the electronic device 100 as part of the verification session initiation data 662 at step 612 and the session identifier that may be provided as part of the received verification response data 674 (for example, at step 625), which may enable the device 100 to confirm that the response data 674 is consistent with the verification session initiation data 662 as part of the same verification session in process 600. 62 (e.g., device 100 may store the session identifier of authentication session initiation data 662 in combination with the merchant identifier of merchant subsystem 200 (e.g., at step 612), and may then compare the stored data combination with the session identifier and merchant identifier of authentication response data 674 (e.g., at step 625) to ensure a proper match before allowing the remainder of process 600, wherein device 100 may be operable to ensure that any session identifier generated by electronic device 100 at step 612 is unique to the particular merchant subsystem or merchant online resource being authenticated during the session initiated at step 612). In any case, as Figure 3B , screen 190b may prompt the user to interact with device 100 in one or more ways to select a particular payment source or credentials that may be used by device 100 to make a purchase. For example, as shown, screen 190b may include a payment source selection prompt 311 that may enable the user to select one of a potential plurality of payment sources that may be used by device 100. Payment source selection prompt 311 may include only payment sources that include credentials associated with payment networks supported by the merchant (e.g., as may be determined by potential transaction data 660, as mentioned above), or may display all payment sources that may be used by device 100, but may enable only those associated with networks that may accept payment to be selected by the user. Payment source selection prompt 311 may include any suitable payment source (e.g., a payment method using "credential X", as may be indicated by payment option identifier 311a of prompt 311; a payment method using "credential Y", as may be indicated by payment option identifier 311b of prompt 311, etc.), including but not limited to: any suitable payment credential native to the secure element of device 100 and / or any suitable non-native payment credential of any available payment source accessible to device 100 (e.g., another device that may serve as a host device for device 100 (as a client device)). As just one specific example, Figure 3C As shown in FIG. 1 , the device 100 may be configured to respond to receiving a user's Figure 3B Screen 190c is provided in response to selection of "Credential X" from identifier 311a of payment source selection prompt 311. Figure 3CScreen 190c of the display may identify the selected credential or automatically identified default credential with credential identifier information 313, and may prompt the user of device 100 to interact with device 100 in one or more ways to authenticate the user and his / her intention to utilize the selected credential. This may include prompting the user (e.g., Figure 3C The user authentication prompt 315) may be provided via a personal identification number ("PIN") entry or via user interaction with a biometric sensor to access the secure element of the device 100 and, therefore, access the credentials to be used for the purchase. The user authentication prompt 315 ... a biometric sensor to access the Figure 3A The secure payment prompt 309 of the screen 190a, and / or in response to the user selecting Figure 3B The payment source selection prompt 311 for specific credentials, and / or in response to the presentation Figure 3C 190c), and initiate a merchant online resource authentication session (e.g., at step 612 and / or step 614). Figure 3B The payment source selection prompt 311, such as in response to the user selecting Figure 3A The secure payment prompt 309 of screen 190a is displayed regardless of the status of any verification session (which may occur in steps 612 to 624 (e.g., before or during any of steps 612 to 614)), and / or not only in response to the user selecting Figure 3A The secure payment prompt 309 of screen 190a is also in response to receiving the verification response data 674 (which may indicate that there is no verification session failure) at step 624. It can be presented at any suitable time Figure 3C authentication prompt 315, such as in response to receiving a user selection of a payment identifier at payment source selection prompt 311 regardless of the state of any authentication session (which may occur in steps 612 to 624 (e.g., before or during any of steps 612 to 614)), and / or in response not only to receiving a user selection of a payment identifier at payment source selection prompt 311 but also in response to receiving authentication response data 674 at step 624 (which may indicate that no authentication session failed), and / or screen 190c may be presented before receiving authentication response data 674 at step 624, but Figure 3C The authentication prompt 315 may not be enabled for use until after the verification response data 674 is received at step 624.

[0087] If the user of device 100 is willing and able to select or confirm specific payment credentials to be used in funding the potential transaction in response to potential transaction data 660 (e.g., payment request data) received at step 610, and authentication response data 674 (e.g., data indicating that the merchant online resource authentication session of steps 612 to 622 was successful) has been received by electronic device 100 at step 624, then process 600 may proceed to step 625, at which step, process 600 may include: after any session identifier consistency has been identified (e.g., as mentioned above, at step 625), receiving the user of device 100's intent and authentication (e.g., through the user selecting) to use specific credentials to conduct a potential transaction for a specific merchant, product, price, and shipping destination based on potential transaction data 660. Figure 3C Authentication prompt 315). Access SSD 154b may leverage applet 153b of device 100 to determine whether such authentication has occurred before allowing use of other SSDs 154 (e.g., credential SSD 154a) to be used to enable its credential information in business credential data communications. As just one example of step 625, applet 153b of access SSD 154b may be configured to determine the intent of the user of device 100 and local authentication (e.g., via one or more input components 110, such as Figure 3 The biometric input component 110i of the device 100, such as can be used by a user interacting with any application of the device 100 (e.g., the merchant resource 113 and / or the card management application 103b of the device 100), and in response to this determination, can be configured to enable another specific SSD for use in the payment transaction (e.g., using a credential of the credential SSD 154a). In some embodiments, after this determination, but before such activation, the GUI of the device 100 can be configured to provide another screen (not shown) that can prompt the user of the device 100 (e.g., in a manner similar to Figure 3C The user of device 100 may interact with device 100 in one or more ways to ultimately initiate payment using the selected and authenticated credential. At step 625, the user of device 100 may provide an intent and authentication to use a specific payment credential native to device 100 to fund the potential transaction identified by potential transaction data 660 of step 610 (e.g., "Merchant A" and "Product B" and "Price C" and "Shipping D" for screens 190a-190c). Alternatively, however, process 600 may enable the user of device 100 to adjust one or more characteristics of the potential transaction (e.g., shipping address information may be updated on screens 190a and / or 190b or otherwise through additional updated potential transaction data 660 transmitted between merchant subsystem 200 and device 100) before any intent and authentication may be provided at step 625.

[0088] Next, once the intent and authentication for a particular payment credential has been received at step 625 in response to receiving the particular payment request data of potential transaction data 660, steps 626-628 of process 600 may include device 100 generating, encrypting, and transmitting device transaction data 678 for use by commercial entity subsystem 400 (e.g., as described with respect to steps 512 and 514 of process 500). Once a credential of credential SSD 154a on secure element 145 of device 100 has been selected, authenticated, and / or enabled for use in a financial transaction (e.g., at step 625), secure element 145 of device 100 (e.g., processor module 142 of NFC component 120) may generate and encrypt certain credential data for that selected credential for use by commercial entity subsystem 400. For example, in step 626, device payment credential data 675 of credential SSD 154a (e.g., payment card data of SSD 154a (e.g., as may be associated with the selected “credential X”)), such as token data and cryptographic data, may be generated and / or at least partially encrypted with credential key 155a' as device payment credential data 676 to include at least the token data and cryptographic data, such that such encrypted device payment credential data 676 may be decrypted only by an entity that has access to that credential key 155a' (e.g., the financial institution subsystem 350) for accessing the device payment credential data 675. Such payment credential data 675 may include any suitable data operable to securely verify proper ownership of a particular security element credential of device 100 (e.g., the credential of SSD 154a), including, but not limited to: (i) token data (e.g., the DPAN, DPAN expiration date, and / or CVV of credential information 161a of SSD 154a); and (ii) cryptographic compilation data (e.g., a compilation password, which may be generated by security element 145 using a shared secret (e.g., key 155a') between SSD 154a and financial institution subsystem 350, and any other suitable information available to device 100 and also made available to financial institution subsystem 350 for use in independently generating the cryptographic compilation data using the shared secret (e.g., some or all of the token data, information identifying device 100, information identifying some or all of the potential transaction data 660 of step 610, such as fee and / or currency, any suitable counter value, temporary value (e.g., the temporary value of the verification data of verification response data 674), etc.)).Thus, payment credential data 675 may include all data necessary to make a payment with that 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, associated cryptographic data (e.g., a cryptographic key generated using a shared secret between secure element 145 and financial institution subsystem 350, and any other suitable information), and / or the like. In some embodiments, once some or all of payment credential data 675 for credential SSD 154a has been encrypted as encrypted payment credential data 676 using credential key 155a′ at step 626, the encrypted payment credential data 676 may be accessed by access information (e.g., by access key 155a of SSD 154a, access key 155b of SSD 154b, ISD key 156k, and / or CRS 151k and / or by CASD 158k signed) encrypts as secure device data 677: that encrypted payment credential information 676 (alone or together with at least a first portion (if not all) of applicable potential transaction data 660) (e.g., part or all of the potential transaction data 660, which may include identification of the merchant, identification of the price total, identification of the currency and / or shipping and / or product, and / or a unique merchant-based transaction identifier, and / or a unique user device-based transaction identifier, and / or the like), some or all of the verification response data 674, and / or any other suitable information (e.g., any information identifying the device 100 itself (e.g., the device identifier 119), any specific device-based transaction identifier, and / or the like). For example, the secure element 145 of device 100 (e.g., processor module 142 of NFC component 120) may use the access information to encrypt into secure device data 677 not only an identification of a merchant from data 660 and / or data 674 (e.g., identification of the merchant or a resource it is using for purchases, such as application 113), but also an identification of the purchase total and / or currency code from data 660 and encrypted payment credential data 675 of SSD 154a (e.g., encrypted payment credential data 676).In some embodiments, payment credential data 675 (e.g., payment card data of SSD 154a, such as token data and cryptographic data) may be generated for credential SSD 154a, but not encrypted with a credential key (e.g., at step 626, as data 676) before being encrypted with a business entity key or access key (e.g., at step 627, as data 677), and alternatively, such payment credential data 675 may be encrypted with a business entity key or access key (e.g., at step 627, as data 677), whereby in these embodiments, any future reference to data 676 may also be a reference to data 675 that was not encrypted with any credential key. In some embodiments, this business entity key or access key may be a business entity public key associated with a scheme of business entity subsystem 400 and whose business entity subsystem 400 may have access to an associated business entity private key. Commercial entity subsystem 400 may provide this commercial entity public key to financial institution subsystem 350, and financial institution subsystem 350 may then share that commercial entity public key with device 100 (e.g., when configuring credential data on device 100 (e.g., in step 654 of process 600)).

[0089] Next, at step 628, the secure device data 677, along with any additional information (such as at least some of the potential transaction data 660 or potential transaction identification information (e.g., identification of the merchant, identification of the price total, identification of the currency, a unique merchant-based transaction identifier, identification of the product / service, and / or the like)), and / or at least a portion or all of the verification response data 674, and / or any other suitable information (e.g., any information identifying the device 100 itself, a unique device-based transaction identifier, and / or the like) may be transmitted from the device 100 to the commercial entity subsystem 400 as device transaction data 678 (e.g., as described with respect to step 514 of procedure 500). Thus, at least a portion of device transaction data 678 (e.g., secure device data 677 with or without verification response data 674) may be decrypted only by an entity (e.g., commercial entity subsystem 400) that has access to that access information (e.g., access key 155a, access key 155b, ISD key 156k, CRS 151k, and / or CASD 158k) used to encrypt secure device data 677 that generated device transaction data 678. Such device transaction data 678 may be generated in steps 626-628 and then transmitted to commercial entity subsystem 400 in step 628 (e.g., via communication component 106 and communication path 65, from secure element 145 or otherwise). Steps 626, 627, and 628 may ensure that any credential data generated and transmitted from the secure element 145 of the device 100 (as part of the device transaction data 678) has first been encrypted in a manner that cannot be decrypted by another portion of the device 100 (e.g., by the processor 102). That is, the payment credential data 675 of the device transaction data 678 may be encrypted as encrypted device payment credential data 676 using a credential key 155a' that may not be exposed to or accessible by any portion of the device 100 outside of its secure element. Additionally, such device payment credential data 676 of the transaction data 678 may be encrypted as secure device data 677 using an access key (e.g., access keys 155a, 155b, 156k, 151k, and / or 158k (e.g., referred to herein as "access information")) that may not be exposed to or accessible by any portion of the device 100 outside of its secure element.

[0090] Next, at step 629, process 600 may include commercial entity subsystem 400 receiving and decrypting at least a portion of device transaction data 678. For example, commercial entity subsystem 400 may receive device transaction data 678 and may then use access information (e.g., 155a, 155b, 156k, 151k, and / or 158k) as available at commercial entity subsystem 400 to decrypt secure device data 677 of device transaction data 678. This may enable commercial entity subsystem 400 to determine the identity of the merchant in an unencrypted state (e.g., from decrypted secure device data 677) while also maintaining payment credential data 675 in an encrypted state (e.g., as encrypted device payment credential data 676) because commercial entity subsystem 400 may not have access to credential key 155a', such device payment credential data 675 may have been encrypted by secure element 145 of device 100 as encrypted device payment credential data 676 at step 626. Additionally or alternatively, the merchant may be identified by additional data that may have been included in device transaction data 678 along with secure device data 677. Device transaction data 678 may include information identifying device 100 or at least its secure element, so that when device transaction data 678 is received by commercial entity subsystem 400, commercial entity subsystem 400 may know which access information (e.g., which of access information 155a, 155b, 156k, 151k, and / or 158k) to use in step 629. 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 a key specific to a particular device 100 or a key specific to a particular secure element.

[0091] Additionally, prior to or after step 629, upon receiving device transaction data 678 transmitted at step 628, step 629 of process 600 may include commercial entity subsystem 400 verifying verification data of verification response data 674 that may have been included in device transaction data 678 by device 100. For example, in response to receiving such device transaction data 678, at step 630 (e.g., similar to step 516 of process 500), commercial entity subsystem 400 may be operable to identify at least a portion or all of verification response data 674 from that device transaction data 678 and confirm that the verification data for that received device transaction data 678 is currently stored at commercial entity subsystem 400, or more specifically, in some embodiments, confirm that the verification data for that received device transaction data 678 is currently stored at commercial entity subsystem 400 against the verification session identifier of the received device transaction data 678 and / or against the merchant identifier of the received device transaction data 678 (e.g., in table 430). In some embodiments, this stored link between the verification data and one or both of the verification session identifier and the merchant identifier may be maintained for only a limited amount of time before the link is automatically cleared, so that the electronic device 100 is subject to receiving the verification response data 674 in step 624 and then sending the device transaction data 678 to the commercial entity subsystem 400 in step 628 within a certain duration, for implementing the security of the secure device data 677 that protects the device transaction data 678 by the commercial entity subsystem 400 for use in conducting specific secure data transactions using verified merchant online resources (for example, the commercial entity subsystem 400 may be operable to remove this association between the verification data and the verification session identifier and / or merchant identifier at the commercial entity subsystem 400 after a certain period of time (for example, removing the link from the form 430 no more than 10 minutes after the link is established), which may increase transaction security).Additionally or alternatively, at step 622, the stored link between the authentication data and one or both of the authentication session identifier and the merchant identifier may also be associated (e.g., as part of challenge request data 664 and / or part of challenge response data 670) with any suitable specific potential transaction identifying information (which may be made available to commercial entity subsystem 400 by merchant subsystem 200 during one or more of steps 614 and 620), such as a specific type of secure data to be shared between device 100 and merchant subsystem 200. The identification of the data (e.g., the currency and amount and the type of payment used for the financial transaction, and similar specific potential transaction identification information may also be made available to commercial entity subsystem 400 by electronic device 100 as part of device transaction data 678 of step 628, such that step 630 may also include commercial entity subsystem 400 confirming that the specific potential transaction identification information currently stored against the verification data received in step 614 and / or step 620 (e.g., as stored in table 430 in step 616 and / or step 622) is at least similar to the specific potential transaction identification information received in step 628. Potential transaction identification information. For example, if at step 622 particular verification data is stored against particular potential transaction identification information associated with a potential transaction indicating a $5 financial transaction, but then at step 628 particular potential transaction identification information received by commercial entity subsystem 400 along with that particular verification data indicates a $2,000 financial transaction, commercial entity subsystem 400 may be operable to not verify the verification data of device transaction data 678 due to the magnitude of the difference between $5 and $2,000. Thus, even if the verification data and verification session identifier and / or merchant identifier of device transaction data 678 received at step 628 may be confirmed at commercial entity subsystem 400 as actively linked (e.g., in table 430), the verification data may still not be verified if device transaction data 678 does not satisfy other data that may be associated with that link (e.g., if any suitable characteristic of the secure data transaction identified during steps 616 through 622 differs from any suitable characteristic identified in device transaction data 678 of step 628 by any suitable amount (e.g., a percentage variation of a particular data type). variance), such as a difference of more than 10% in the monetary value of a financial transaction, or a difference of more than 10% in the time frame of the health data); or a difference of a particular type (e.g., a difference in the type of identified data, such as a difference in the type of health data between two instances of the identified data (e.g., heart rate data versus miles walked, or biometric data versus payment data, etc.); and / or a difference in the type of currency being used for the transaction between two instances of the identified data (e.g., U.S. dollars versus Japanese yen, etc.); and / or the location of the shipping address for a payment transaction for the delivery of goods).The data comparison may be between data actually received for a particular transaction and aggregated past data for a particular merchant to detect certain instances of deviation from an expected norm (e.g., detecting a first transaction with biodata from a merchant where only payment credential data has been transacted until then, etc.), where potential transaction identification information may be used by the merchant to verify or detect fraud and not necessarily with respect to the user device (e.g., in some instances, aggregated data from the merchant (rather than the device) may be tracked to respect end-user privacy concerns).

[0092] Next, at step 631, procedure 600 may include commercial entity subsystem 400 identifying a merchant key (e.g., merchant key 157) associated with a merchant that may have been identified via payment request data 610 and / or authentication session (and, therefore, via device transaction data 678), and then using that merchant key to re-encrypt at least a portion of device transaction data 678. That is, after decrypting at least a portion of device transaction data 678 using appropriate access information at step 629 (e.g., after decrypting secure device data 677 to realize device payment credential data 676 and any other information that may have been encrypted in secure device data 677 (e.g., verification response data 674)), then at step 631, commercial entity subsystem 400 may re-encrypt at least a portion of device transaction data 678 (e.g., token data and / or cryptographic data of device payment credential data 676) using an appropriate merchant key (which may be associated with the merchant information identified in device transaction data 678, or may be identified in table 430 as being associated with the linked verification data verified at step 630). For example, the commercial entity merchant information identified using device transaction data 678 may be re-encrypted by comparing the commercial entity merchant information identified using device transaction data 678 with the merchant information in table 430. Figure 1A430 of FIG. 44 . Using the determined appropriate merchant key, commercial entity subsystem 400 may re-encrypt at least a portion of device transaction data 678 (e.g., token data and / or cryptographic data of device payment credential data 676) with that merchant key (e.g., merchant key 157) as encrypted merchant credential material 681. For example, encrypted merchant credential data 681 may include at least encrypted device payment credential data 676 from device transaction data 678 and any suitable transaction data, such as purchase amount data or other suitable transaction data from or based on device transaction data 678 and / or potential transaction data 660. Merchant identification information from device transaction data 678 may not need to be included in encrypted merchant credential data 681 because that merchant identification may have been used to determine the merchant key that may be used to encrypt encrypted merchant credential material 681 at step 631. Encrypted merchant credential data 681 may be signed by commercial entity subsystem 400 so that, when received by merchant subsystem 200, merchant subsystem 200 may establish commercial entity subsystem 400 as the creator of such encrypted merchant credential data 681 and / or may enable merchant subsystem 200 to ensure that such encrypted merchant credential data 681 has not been modified after being signed. Such encrypted merchant credential data 681 may be generated at step 631 and then transmitted to device 100 at step 632 along with any other suitable data as secured transaction data 682 (e.g., via Figure 1A Path 65 is transmitted from the server 410 of the commercial entity subsystem 400 to the communication component 106 of the device 100).

[0093] Steps 631 and 632 are operable to ensure that the data transmitted from the business entity subsystem 400 as Figure 1A The credential data of the portion of the secured transaction data 682 (e.g., the token data and / or cryptographic data of the encrypted merchant credential data 681) may be encrypted such that no portion of the device 100 other than the secure element 145 may decrypt the credential data. That is, the credential data of the secured transaction data 682 (e.g., the token data and / or cryptographic data of the encrypted merchant credential data 681) may be encrypted with a merchant key (e.g., merchant key 157) that may not be exposed to or otherwise accessible by any portion of the device 100 (including the secure element 145 in some embodiments). Additionally, the credential data of the secured transaction data 682 (e.g., the token data and / or cryptographic data of the encrypted merchant credential data 681) may be encrypted with a credential key 155a' that may not be exposed to or otherwise accessible by any portion outside of the secure element 145 of the device 100 (e.g., at step 626).

[0094] Next, at step 634, the secured transaction data 682 may be transferred to the merchant subsystem 200 as secured transaction data 684 (e.g., via communication path 15 or as contactless proximity-based communication 5). Alternatively, the merchant credential data 681 may be transmitted from the commercial entity subsystem 400 to the merchant subsystem 200 without being transmitted via the device 100 (not shown). One, some, or all of the potential transaction data 660 may be transmitted via device 100 and / or commercial entity subsystem 400 to secured transaction data 682 and / or to secured transaction data 684 so that certain identifiers of the potential transaction may be identified by each of the entities during process 600, including, but not limited to: (i) specific merchant information, such as a unique merchant identifier for the merchant (i.e., “Merchant A”), and / or identification of a specific merchant resource being used (e.g., a specific merchant application 113′); (ii) specific transaction information, such as identification of a specific currency to be used to pay for the transaction (e.g., Japanese Yen, British Pounds, U.S. Dollars, etc.), and / or identification of a specific total amount of the currency to be paid for the transaction (i.e., “Price C”), and / or identification of a specific product or service to be purchased or rented or otherwise paid for (i.e., “Product B”), and / or identification of a specific product or service to be used Identification of a default or initial shipping address (i.e., “ShipD”); (iii) information indicating one or more types of payment methods that the merchant may accept for the transaction (e.g., a list of payment cards that may be used for purchases (e.g., MasterCard, rather than Visa)) or selected by device 100 (i.e., “CredentialX”); (iv) a unique merchant-based transaction identifier (e.g., any suitable data element, such as a 3 or 4 character alphanumeric string that may be randomly or uniquely generated by merchant subsystem 200 for association with an ongoing transaction); (v) a unique user-device-based transaction identifier (e.g., any suitable data element, such as a 3 or 4 character alphanumeric string that may be randomly or uniquely generated by device 100 for association with an ongoing transaction); (vi) a unique merchant online resource verification session identifier), and / or the like.

[0095] Once merchant credential data 681 including payment credential data 675 / 676 is received by merchant subsystem 200 (e.g., as secured transaction data 684, at step 634), process 600 may also include step 636, at which merchant subsystem 200 may be configured to generate and transmit payment data 686 to acquiring bank subsystem 300 (e.g., via Figure 1A25 between the merchant subsystem 200 and the acquiring bank subsystem 300), wherein the data 686 may include payment information and an authorization request, which may indicate the secured device payment credential data of the device 100 and the merchant purchase price for the product or service (e.g., as may be included in or otherwise associated with the secured transaction data 684, or as may otherwise be associated with the transaction as known by the merchant subsystem 200 (e.g., through the underlying transaction data 660 (e.g., based on the unique transaction identifier)). For example, at step 636, the merchant subsystem 200 may leverage its known merchant key 157 to at least partially decrypt the merchant credential data 681 of the secured transaction data 684, so that the payment data 686 may include the secured payment credential data (e.g., data 676) of the credential SSD 154a encrypted with its credential key 155a' (rather than with a key that is not available to the financial institution subsystem 350).

[0096] If payment data 686 is transmitted to acquiring bank subsystem 300 at step 636, then, at step 638, acquiring bank subsystem 300 may forward authorization request information from payment data 686 to financial institution subsystem 350 as authorization request data 688 (e.g., via Figure 1ANext, at step 640, when the issuing bank subsystem 370 of the financial institution subsystem 350 receives the authorization request (e.g., at step 640, directly receiving the authorization request from the acquiring bank subsystem 300 as data 688, or indirectly receiving the authorization request via the payment network subsystem 360 as data 405), the payment information (e.g., the payment credential data 675 of the device 100 as encrypted by the secure element 145 of the device 100 via the credential key 155a' (e.g., data 676)), and the purchase amount, each of the authorization request, the payment information, and the purchase amount: may be included in the authorization request data 688, and may be included in the data 682, 684, and / or 686; 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 business credential has sufficient credit to fulfill the purchase amount. If sufficient funds are not present, the issuing bank subsystem 370 may deny the requested transaction by transmitting a negative authorization response to the acquiring bank subsystem 300. However, if sufficient funds are present, 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. At step 640 of process 600, either type of authorization response may be provided by the user financial subsystem 350 to the acquiring bank subsystem 300 as the authorization response transaction status data 690 (e.g., provided directly from the issuing bank subsystem 370 to the acquiring bank subsystem 300 via the communication path 35, or based on a communication path that may be provided via the communication path 350). Figure 1A The communication path 45 from the issuing bank subsystem 370 to the payment network subsystem 360 provides authorization response data 415, which is provided from the payment network subsystem 360 to the acquiring bank subsystem 300). Next, in response to receiving the authorization response transaction status data 690 at step 640, at step 642, the process 600 may also include the acquiring bank subsystem 300 or any other suitable subsystem sharing such authorization response transaction status data with the merchant subsystem 200 as authorization response transaction status data 692, which may then be shared with the device 100 (e.g., using merchant resources or otherwise) as confirmed transaction status data 694 at step 644. Such confirmed transaction status data may be configured to provide any suitable confirmation data to the device 100, such as Figure 3D190d of the screen. If the transaction is successful, at step 644, the confirmed transaction status data may be operable to close the transaction at the device 100. Additionally or alternatively, if the transaction is unsuccessful, the confirmed transaction status data may or may not be operable to close the transaction (e.g., close the transaction if no valid funds are available or if the device identifies fraud, but keep it open and allow updates if an invalid shipping address is determined). Any non-transaction termination transaction status data may allow the payment process to continue until the process is canceled by the application, canceled by the user, or the process is completed.

[0097] Thus, merchant subsystem 200 may be configured to process secured transaction data 684 or any other carrier of merchant credential data 681 in any suitable manner. For example, to obtain device payment credential data from merchant credential data 681, merchant subsystem 200 may verify that a signature attribute of the received merchant credential data 681 is valid and that commercial entity subsystem 400 is the signer of that signature. Merchant subsystem 200 may use any suitable technique to determine which merchant key (e.g., which merchant public key 157) may have been used by commercial entity subsystem 400 to construct merchant credential data 681. Merchant subsystem 200 may then retrieve a corresponding merchant private key (e.g., merchant private key 157 at merchant subsystem 200) and use that retrieved key to unpack and / or decrypt the encrypted merchant credential data 681 to recover encrypted data 676. Such data 676 may then be provided to the appropriate payment network 360, which may leverage the appropriate credential key 155a' of the financial institution subsystem 350 to unpack and / or decrypt the encrypted device payment credential data 676 to recover the device payment credential data 675 (e.g., recover the token data and / or cryptographic data of the device payment credential data 675 for use in verifying the device payment credential data 675 (e.g., to independently generate cryptographic data based on the token data of the received device payment credential data 675, compare the generated cryptographic data with the cryptographic data of the received device payment credential data 675, and verify or deny the transaction based on the comparison)).

[0098] It should be understood that Figure 6The steps shown in process 600 are illustrative only, and existing steps may be modified or omitted, additional steps may be added, and the order of certain steps may be changed. Although not shown, the secured transaction data may be transmitted directly from commercial entity subsystem 400 to merchant subsystem 200 (e.g., in steps 632 and 634, via communication path 85 instead of via device 100), or directly to financial institution subsystem 350 (e.g., in steps 632 to 638, via communication path 55 instead of via device 100 and / or not via merchant subsystem 200 and / or not via acquiring bank 300). In addition or alternatively, although not shown, the secured transaction data may be transmitted directly from device 100 to financial institution subsystem 350 (e.g., without passing through merchant subsystem 200). It should be understood that if any verification step of process 600 fails, such failure may be communicated to one or more appropriate entities. For example, if verification of challenge request data 664 fails at step 616, and / or if verification of challenge response data 670 fails at step 622, and / or if verification of verification response data 674 of device transaction data 678 fails at step 630, such failure may be shared by commercial entity subsystem 400 with merchant subsystem 200 and / or electronic device 100 so that device 100 may cancel the potential transaction with merchant subsystem 200 and potentially remove the merchant online resource from device 100. After a user of device 100 may select certain secure data to use for a secure data transaction (e.g., certain payment credential data for a particular payment credential) at step 625, the remaining steps in process 600 may occur transparently to that user (e.g., steps 626 through 644 may occur without any further user interaction with device 100 and appear instantaneous to the user of device 100). After step 625, process 600 appears to the user of device 100 as if the secure device data was automatically and instantly sent to merchant subsystem 200 and the transaction status can be confirmed to device 100 (e.g., by merchant subsystem 200 and / or commercial entity subsystem 400). In addition or alternatively, authentication of the merchant's online resource can occur transparently to device 100 (e.g., steps 614-624 (if step 612 is not also included) can occur without any interaction with the user of device 100 and after step 610 it appears to the user of device 100 as instantaneous). Alternatively, in some embodiments, process 600 may occur completely transparently to a user of device 100 (e.g., where device 100 may be configured to automatically determine when a secure device transaction is appropriate and automatically receive authentication response data, and / or automatically send device transaction data, and / or automatically receive and / or send secure transaction data for use in a secure device transaction without requiring interaction with any active user of device 100, while merchant online resources may still be authenticated for that particular secure device transaction during the time the authentication session is initiated and conducted).For example, as mentioned, device 100 may be configured to determine that a particular product is desirable to purchase and interact with one or more merchants to obtain associated potential transaction data from at least one particular merchant of that particular product (e.g., device 100 may be a home appliance that may be configured to determine that an appliance product must be purchased (e.g., detecting that a washing machine needs more laundry detergent, or detecting a calendar event preset by a user to buy more detergent on a particular date), and may automatically identify a particular merchant that offers the best deal for that product, and may automatically interact with that merchant to obtain potential transaction data for purchasing that product from that home), all automatically and without any active interaction by the user of device 100. Thereafter, device 100 and / or the particular merchant may be operable to automatically initiate the authentication session of step 612.

[0099] In some embodiments, steps 618 to 622 may be skipped after the challenge request has been authenticated at step 616, and alternatively, authentication data may be generated and stored at step 616, rather than challenge data. Thus, in some embodiments, steps 614 and 616 may be sufficient to authenticate the merchant online resource for a particular authentication session. In some embodiments, the challenge data generated at step 616 may be different from the authentication data generated at step 622. For example, the challenge data may be long enough (e.g., a data string of suitable length, such as 10 or more characters) to provide sufficient randomness for implementing a significant robust challenge of the merchant subsystem 200 with the challenge data 668, whereas the authentication data may be shorter than the challenge data (e.g., the authentication data may be a data string of shorter length than the length of the challenge data, such as 6 characters) to provide sufficient randomness for implementing proof of session authentication with the authentication response data 674 and / or satisfy any suitable standard (e.g., satisfying the data length requirements of the EuropayMasterCardVisa (“EMV”) standard). Alternatively, the challenge data and verification data may be the same and reused in both steps 616 and 622. At step 624, verification data (e.g., a temporary value) of verification response data 674 may be generated and provided by commercial entity subsystem 400 to device 100 based on successful verification of the challenge by merchant subsystem 200 rather than solely based on a determination that a payment transaction will occur between device 100 and the merchant. When device 100 may communicate with merchant subsystem 200 via a native application on device 100 (which may be a merchant-specific application), then merchant application 113 may be provided by such application. However, when the device 100 can communicate with the merchant subsystem 200 via an Internet browser application or hybrid application (which may or may not be a merchant-specific application, but which may be directed to a website managed by the merchant (e.g., on a server controlled by the merchant)), then the merchant application 113 can be a layout engine software component (e.g., WebKit) that can forward communications to the merchant's website (e.g., via the communication component 106). For example, this application 113 of the device 100 can be a conduit for any device transaction data to be provided to the merchant subsystem 200.

[0100] Alternative embodiments of certain portions of process 600 may now be described with respect to different merchant configurations. Merchant subsystem 200 may be equipped to exercise varying degrees of control over handling secure transactions of process 600. In a first merchant configuration, in which merchant subsystem 200 may retain control of the entire process, merchant subsystem 200 may be operable to handle not only authentication of merchant online resources (e.g., at steps 614 and 616 and / or at steps 618 and 620, merchant subsystem 200 itself may communicate with commercial entity subsystem 400 to authenticate the merchant online resources), but may also handle decryption of secure data encrypted by commercial entity subsystem 400 (e.g., at step 636, merchant subsystem 200 may leverage merchant key 157 to at least partially decrypt merchant credential data 681 of secured transaction data 684). In this first merchant configuration, merchant subsystem 200 may act as its own payment service provider ("PSP") and may be the only subsystem that communicates with commercial entity subsystem 400 (to register and authenticate online resources in process 600), as may be typical for large merchants with high transaction volumes (e.g., Amazon.com). Alternatively, in a second merchant configuration, merchant subsystem 200 may hand over payment decryption responsibilities to any suitable merchant-partner subsystem, such as PSP subsystem 310, which may communicate with commercial entity subsystem 400 in a manner that is consistent with the merchant subsystem 400. Figure 1A and Figure 6may be shown as part of acquiring bank 300. In this second merchant configuration, merchant subsystem 200 is operable to handle authentication of merchant online resources (e.g., at step 614 and / or at steps 618 and 620, merchant subsystem 200 itself may communicate with commercial entity subsystem 400 to authenticate the merchant online resource), but PSP subsystem 310 is operable to handle decryption of security data encrypted by commercial entity subsystem 400 (e.g., at step 638, PSP subsystem 310 may leverage merchant key 157 to at least partially decrypt merchant credential data 681 of payment data 686). In this second merchant configuration, merchant subsystem 200 may use a different third-party backend PSP for its payment decryption, such that both merchant subsystem 200 and PSP subsystem 310 may communicate with commercial entity subsystem 400 for registering online resources in program 600, as may be typical for smaller merchants that may utilize a payment service provider (e.g., an acquiring bank (e.g., Chase Paymentech) or a smaller PSP (e.g., Stripe, Braintree, First Data, etc.) that is operable to communicate with multiple acquiring banks, card and payment networks, and / or manage such technical connections and relationships with external networks and bank accounts on behalf of merchant subsystem 200, thereby making merchant subsystem 200 less dependent on financial institutions). The PSP subsystem 310 of this second merchant configuration may be hidden from the user of device 100, who may only interface with the online resources of merchant subsystem 200 (e.g., in FIG. 3A to FIG. 3D190a to 190d). Alternatively, in a third merchant configuration, merchant subsystem 200 may hand over online resource authentication responsibility and payment decryption responsibility to any suitable merchant-partner subsystem, such as PSP subsystem 310. In this third merchant configuration, PSP subsystem 310 may be operable to handle not only authentication of merchant online resources (e.g., at step 614, PSP subsystem 310 itself may communicate challenge request data 664 with commercial entity subsystem 400 to authenticate the merchant online resource (e.g., in response to PSP subsystem 310 receiving session initiation data 662 from merchant subsystem 200)), but also decryption of secure data encrypted by commercial entity subsystem 400 (e.g., at step 638, PSP subsystem 310 may leverage merchant key 157 to at least partially decrypt merchant credential data 681 of payment data 686). In this third merchant configuration, the merchant subsystem 200 may use a different third-party front-end PSP for authentication and payment decryption, so that both the merchant subsystem 200 and the PSP subsystem 310 may communicate with the commercial entity subsystem 400 to register and authenticate online resources in the process 600, as may be typical for "long tail" merchants, which rely on a third-party payment service provider to perform the entire check and payment process on their behalf (e.g., Stripe Checkout, which may be provided by Stripe Inc.'s PSP). Different third-party front-end PSP subsystems 310 may provide an embeddable payment form for desktop computers, tablet computers, and mobile devices (e.g., such as a Java script of the PSP subsystem 310 that may be hosted on a server of the PSP subsystem 310, such as an embedded PSP subsystem 310 in a merchant resource of the merchant subsystem 200), which may be operated within the Web resources of the merchant subsystem 200 for the customer to pay via that payment form of the PSP subsystem 310 without redirecting the customer (e.g., the user of the device 100) away from the Web resources of the merchant subsystem 200 to complete the transaction or the customer may be redirected away from the Web resources of the merchant subsystem 200 to the Web resources of the PSP subsystem 310 to complete the process (e.g., PayPal.com).The PSP subsystem 310 of this third merchant configuration is operable to manage and operate PSP online resources, which may be similar to merchant online resources, but may be utilized by merchant online resources that do not themselves have the ability to process payments, for example, wherein a website merchant online resource 113 may direct a user of a device 100 that is interfaced with that website merchant online resource 113 to an interface of the website PSP online resource 113 (which may be embedded within any portion of the website merchant online resource 113), or may redirect a user from any suitable portion of the website merchant online resource 113 (e.g., may be provided by a website PSP online resource (rather than by the website merchant online resource). FIG. 3A to FIG. 3D 190a to 190d of the system 1). Thus, depending on the configuration of system 1 and the capabilities of merchant subsystem 200, merchant subsystem 200 and PSP subsystem 310 (e.g., acquirer subsystem 300) may together provide a single robust processing subsystem 299 of system 1 or may be used as distinct entities of system 1.

[0101] Registering a merchant online resource with commercial entity subsystem 400 may include merchant subsystem 200 alone or in combination with PSP subsystem 310 (e.g., depending on which of the three merchant configurations is employed) registering with commercial entity subsystem 400 to operationally authenticate the online resource to commercial entity subsystem 400 and also decrypt credential data as encrypted by commercial entity subsystem 400. For example, step 606 may include not only merchant keys 157 shared between commercial entity subsystem 400 and merchant subsystem 200 or PSP subsystem 310 regarding one or more merchant identifiers 167 associated with an online resource, wherein such keys 157 may be used at commercial entity subsystem 400 to encrypt data (e.g., at step 631) and such keys 157 may be used at merchant subsystem 200 or PSP subsystem 310 to decrypt that data (e.g., at step 636 or step 638), but may also include credentials 177 shared between commercial entity subsystem 400 and merchant subsystem 200 or PSP subsystem 310 regarding one or more merchant identifiers 167 associated with the online resource, wherein the credentials 177 may be used to authenticate the online resource (e.g., at steps 614 and 616).

[0102] As just one example, at step 606, a first certificate signing request ("CSR") for a shared secret key for an online resource (e.g., website merchant online resource 113) may be generated and transmitted to commercial entity subsystem 400. This first CSR for the shared secret key may include: at least one merchant identifier 167 associated with the online resource, such as a fully qualified domain name ("FQDN") of the online resource (e.g., a web domain that may specify its exact location, including root and subdomains (e.g., DNS hostname)); and / or any other suitable merchant identifier that may be linked to the domain of the online resource; and / or any other suitable identifier of any suitable merchant-partner that may be associated with the online resource (e.g., a PSP identifier if merchant subsystem 200 may use a PSP to decrypt credential data encrypted by commercial entity subsystem 400)). In step 606, commercial entity subsystem 400 may, in response to a first CSR for sharing a key, facilitate a key pair (e.g., public and private merchant keys 157) as a shared secret between commercial entity subsystem 400 and merchant subsystem 200 or PSP subsystem 310 (which may be associated with one or more of the merchant identifiers 167 of the first CSR). For example, the first merchant key 157 of the key pair may be stored in table 430 of commercial entity subsystem 400 against one, some, or each of the merchant identifiers of the first CSR for the merchant online resource, or otherwise associated with one, some, or each of the merchant identifiers of the first CSR for the merchant online resource, and the second merchant key 157 of the key pair may be stored in merchant subsystem 200 and / or at PSP subsystem 310 against one, some, or each of the merchant identifiers of the first CSR for the merchant online resource, or otherwise associated with one, some, or each of the merchant identifiers of the first CSR for the merchant online resource. One or more merchant identifiers may be associated with a particular merchant online resource 113, such as a first merchant identifier 167 uniquely associated with that particular merchant online resource 113 (e.g., FQDB if a web resource merchant online resource 113), and / or a second merchant identifier 167 associated with each merchant online resource 113 of a particular merchant subsystem 200. Additionally or alternatively, one or more merchant keys may be associated with a particular merchant identifier or associated with a particular merchant online resource 113. In one or more instances of step 606, the association of all such merchant keys with merchant identifiers may be stored by commercial entity subsystem 400 or otherwise made accessible to commercial entity subsystem 400 (e.g., in one or more tables 430).In a first merchant configuration, the merchant subsystem 200 may generate and provide this first CSR to the commercial entity subsystem 400, and the merchant subsystem 200 may store the merchant key 157 against one, some, or each of the merchant identifiers 167 of the first CSR for the online resource, or otherwise associate the merchant key 157 with one, some, or each of the merchant identifiers 167 of the first CSR for the online resource. In the second merchant configuration and the third merchant configuration, the PSP subsystem 310 or the merchant subsystem 200 may generate this first CSR, and either the PSP subsystem 310 or the merchant subsystem 200 may provide this first CSR to the commercial entity subsystem 400, and the PSP subsystem 310 may receive the merchant key 157 from the commercial entity subsystem 400 (e.g., directly or via the merchant subsystem 200) and store the merchant key 157 against one, some, or each of the merchant identifiers 167 of the first CSR for the online resource, or otherwise associate the merchant key 157 with one, some, or each of the merchant identifiers 167 of the first CSR for the online resource.

[0103] Additionally, at step 606, a second CSR for the credential of the online resource (e.g., website merchant online resource 113) may be generated and transmitted to commercial entity subsystem 400. This second CSR for the credential may include: at least one merchant identifier 167 associated with the online resource, such as at least one merchant identifier 167 of the first CSR or otherwise (e.g., the FQDN of the online resource or any other suitable merchant identifier that may be linked to the domain of the online resource), and / or any other suitable identifier of any suitable merchant-partner that may be associated with the online resource (e.g., a PSP identifier if merchant subsystem 200 may use a PSP subsystem to authenticate the online resource)). In step 606, commercial entity subsystem 400 may facilitate credential 177 to be generated and shared between commercial entity subsystem 400 and merchant subsystem 200 or PSP subsystem 310 in response to the second CSR for the credential, wherein credential 177 may include one, some, or all of the merchant identifiers 167 of the second CSR and credential 177 may be generated (e.g., by commercial entity subsystem 400) using a merchant key of the first CSR for the merchant online resource (e.g., as identifiable by one or more of the merchant identifiers of the second CSR). For example, the credential 177 for the online resource of the second CSR may be stored in table 430 of commercial entity subsystem 400 against one, some, or each of the merchant identifiers of the second CSR for the online resource, or otherwise associated with one, some, or each of the merchant identifiers of the second CSR for the online resource, and the credential 177 may also be stored at merchant subsystem 200 and / or at its PSP subsystem 310 against one, some, or each of the merchant identifiers of the second CSR for the online resource, or otherwise associated with one, some, or each of the merchant identifiers of the second CSR for the online resource. Credential 177 may be any suitable digital certificate, such as a Transport Layer Security (“TLS”) credential or a Secure Sockets Layer (“SSL”) credential. In both the first merchant configuration and the second merchant configuration, the merchant subsystem 200 may generate and provide this second CSR to the commercial entity subsystem 400, and the merchant subsystem 200 may store the credential 177 against one, some, or each of the merchant identifiers 167 of the second CSR for the online resource, or otherwise associate the credential 177 with one, some, or each of the merchant identifiers 167 of the second CSR for the online resource.In a third merchant configuration, the PSP subsystem 310 and / or the merchant subsystem 200 may generate this second CSR and may provide this second CSR to the commercial entity subsystem 400, and the PSP subsystem 310 may store the credential 177 against one, some, or each of the merchant identifiers 167 of the second CSR for the online resource, or otherwise associate the credential 177 with one, some, or each of the merchant identifiers 167 of the second CSR for the online resource, wherein this procedure for providing the credential 177 to the PSP subsystem 310 may be completed regardless of the merchant subsystem 200 and may be completed before the merchant subsystem 200 and the PSP subsystem 310 form a partnership (e.g., before the merchant subsystem 200 and the PSP subsystem 310 form a partnership for providing a front-end PSP model, the PSP subsystem 310 may be a trusted PSP of the commercial entity subsystem 400 and have the credential 177, wherein payment occurs via the PSP subsystem 310 and the domain of the PSP subsystem 310). The merchant subsystem 200 may provide the network domain provided by the PSP to the commercial entity subsystem 400 and request the commercial entity subsystem 400 to confirm that the PSP subsystem 310 is trusted and has the certificate 177 for the network domain.

[0104] Additionally, at step 606, the domain (e.g., FQDN) of the website online resource owned by the merchant subsystem 200 or by the merchant-partner PSP subsystem 310 may have been verified or otherwise established to the commercial entity subsystem 400 (e.g., as described with respect to step 501) before, during, or after handling either or both of the first CSR and the second CSR. When registering an online resource, any of the first CSR for a key, the second CSR for a credential, and the domain verification may occur before or after any other of the first CSR for a key, the second CSR for a credential, and the domain verification. However, in some embodiments, verifying the domain before processing the second CSR for a credential may enable an easier and / or more efficient registration process. In both the first merchant configuration and the second merchant configuration, the merchant subsystem 200 may share the FQDN of the website merchant online resource registered with the commercial entity subsystem 400, the commercial entity subsystem 400 may provide any suitable file (e.g., such as a JSON file) to the merchant subsystem 200, the merchant subsystem 200 may sign that file (e.g., using the shared merchant key 157) and host that file on the FQDN, and then the commercial entity subsystem 400 may access the signed file from the FQDN and remove the signature from the file (e.g., using the shared merchant key 157) to confirm that the accessed file matches the file shared with the merchant subsystem 200, and any associated thresholds have been met (e.g., duration, etc.). In a third merchant configuration, the PSP subsystem 310 may share the FQDN of a registered website online resource (e.g., a website online resource of the PSP) with the commercial entity subsystem 400, the commercial entity subsystem 400 may provide any suitable file (e.g., such as a JSON file) to the PSP subsystem 310, the PSP subsystem 310 may sign that file (e.g., using the shared merchant key 157) and host that file on the FQDN, and then the commercial entity subsystem 400 may access that signed file from the FQDN and remove the signature from the file (e.g., using the shared merchant key 157) to confirm that the accessed file matches the file shared with the PSP subsystem 310, and any associated thresholds have been met (e.g., duration, etc.). In a third merchant configuration, the merchant subsystem 200 is operable to transmit data indicating a partnership between the merchant subsystem 200 and the PSP subsystem 310 to the commercial entity subsystem 400, such that the commercial entity subsystem 400 is operable to confirm the validity of the PSP subsystem 310 to the merchant subsystem 200 and store an association between the merchant identifier 167 of the merchant subsystem 200 and the FQDN and / or credentials 177 of the PSP subsystem 310 (e.g., in table 430) for any suitable use during other portions of the procedure 600.In some embodiments, for the second merchant configuration and the third merchant configuration, the merchant key(s) 157 provided to the PSP subsystem 310 may be used globally by the PSP subsystem 310 for decrypting data regarding any partner merchant subsystem 200 . Alternatively, for the second and third merchant configurations, the merchant key(s) 157 provided to the PSP subsystem 310 may be specific to a particular partner merchant subsystem 200, whereby the merchant subsystem 200 may communicate with the commercial entity subsystem 400 (e.g., employing the first CSR for the key), and the PSP subsystem 310 may then be enabled to receive such merchant key(s) 157 specific to that merchant subsystem 200 (e.g., directly from the commercial entity subsystem 400 or from the merchant subsystem 200), wherein such merchant key(s) 157 may be stored or otherwise associated with any suitable merchant identifier 167 of the merchant subsystem 200 at the commercial entity subsystem 400 (e.g., in table 430) and / or at the PSP subsystem 310. This may enable merchant-specific merchant keys 157 to be invalidated at the commercial entity subsystem 400 when the commercial entity subsystem 400 no longer trusts a particular merchant subsystem, while still enabling other merchant-specific keys of the PSP subsystem 310 to be used with respect to other merchant subsystems. In some embodiments, one or more APIs may be provided for enabling the PSP subsystem 310 to directly interface with the commercial entity subsystem 400, for allowing the PSP subsystem 310 to share any merchant keys 157 and / or credentials 177 (which may be specific to a particular partner merchant subsystem 200 of the PSP subsystem 310) with the commercial entity subsystem 400 without requiring the merchant subsystem 200 to be directly involved in that process (e.g., so that the PSP subsystem 310 can onboard a merchant to the commercial entity subsystem 400 as a proxy for that merchant). The credentials 177 may also be global to the PSP subsystem 310 or specific to a particular partner merchant subsystem 200.

[0105] Thus, step 606 and / or step 501 may include not only the domain of the online resource that has been verified by the commercial entity subsystem 400, but may also include storing a merchant identifier 167 associated with or identical to that domain of the online resource at the commercial entity subsystem 400 and at the merchant subsystem 200 and / or at the merchant-partner PSP subsystem 310 against both the merchant key 157 and the credential 177 for registering the online resource at the commercial entity subsystem 400. Thus, at commercial entity subsystem 400 and at merchant subsystem 200 and / or at PSP subsystem 310, the verified FQDN of the online resource and / or any other suitable merchant identifier 167 may be stored against merchant key 157 and credential 177 (e.g., at step 606 of procedure 600 and / or at step 501 of procedure 500) for purposes of not only enabling verification of the FQDN of the online resource during a verification session (e.g., at steps 614 and 616 of procedure 600 and / or at step 506 of procedure 500), but also for enabling encryption of security data by commercial entity subsystem 400 (e.g., at step 631 of procedure 600 and / or at step 518 of procedure 500), and corresponding decryption of that encrypted security data by merchant subsystem 200 or PSP subsystem 310 (e.g., at step 636 or step 638 of procedure 600 and / or after step 522 of procedure 500). For example, in both the first merchant configuration and the second merchant configuration, in response to the merchant subsystem 200 receiving at step 612 any suitable merchant online resource authentication session initiation data 662 from the device 100 for initiating an authentication session with the merchant online resource 113 (wherein such authentication session initiation data 662 may include an identifier of the online resource, e.g., an FQDN of the merchant online resource accessed by the device 100), the merchant subsystem 200 may be operable to transmit at step 614 any suitable challenge request data 664 (including the credential 177 received by the merchant subsystem 200 at step 606 and stored against that FQDN of the authentication session initiation data 662) to the commercial entity subsystem 400 for authenticating the merchant online resource for a particular secure data transaction to be conducted (e.g., a financial payment transaction as identified at steps 610 and / or 612).Alternatively, in a third merchant configuration, in response to the PSP subsystem 310 receiving at step 612 any suitable online resource authentication session initiation data 662 from the device 100 for initiating an authentication session with the PSP online resource 113 (wherein such authentication session initiation data 662 may include an identifier of the online resource, e.g., an FQDN of the PSP online resource accessed by the device 100), at step 614 the PSP subsystem 310 may be operable to transmit to the commercial entity subsystem 400 any suitable challenge request data 664 (including the credential 177 received by the PSP subsystem 310 at step 606 and stored against that FQDN of the authentication session initiation data 662) for authenticating the PSP online resource for a particular secure data transaction to be conducted (e.g., a financial payment transaction as identified at step 610 and / or step 612). Such challenge request data 664 transmitted from merchant subsystem 200 or PSP subsystem 310 to commercial entity subsystem 400 at step 614 may include any suitable data for attempting to verify the validity of the online resource to commercial entity subsystem 400, including, but not limited to: credentials 177, which may include an FQDN and / or any other suitable identifier associated with the online resource, as generated by commercial entity subsystem 400 at step 606; and any other suitable data (e.g., data identifying device 100, and / or data identifying a particular secure data transaction to be conducted (e.g., a financial payment transaction as identified at steps 610 and / or 612, which may be referred to herein as potential transaction identification information, and which may be used during any suitable portion of process 600 for providing any additional security layer(s) to the current data transaction process, and / or for providing any additional security (e.g., fraud detection) services for future data transactions).

[0106] At step 616 of process 600, in response to commercial entity subsystem 400 receiving challenge request data 664 containing any suitable credentials 177 from merchant subsystem 200 or PSP subsystem 310 at step 614, commercial entity subsystem 400 is operable to authenticate the online resource 113 identified by the merchant identifier 167 of the challenge request. For example, in both the first merchant configuration and the second merchant configuration, in response to the business entity subsystem 400 receiving any suitable challenge request data 664 containing a credential 177 from the merchant subsystem 200 in step 614, the business entity subsystem 400 may be operable to verify and check the credential 177 of the received challenge request data 664 to ensure that its trust remains valid and has not expired through any suitable procedure(s) (e.g., the credential 177 may be received by the business entity subsystem 400 in data 664, and then the business entity subsystem 400 may be operable to determine whether that credential 177 is known to the business entity subsystem 400 (e.g., stored in table 430), and whether that credential 177 is still trusted, and / or whether that credential 177 has not expired). Next, if the received credential 177 has been verified, the FQDN and / or another merchant identifier 167 can be extracted from the received credential 177 and cross-checked with any FQDN and credential 177 associations stored in table 430 of the commercial entity subsystem 400 to ensure that the FQDN of the received credential 177 is registered. For example, in step 616, business entity subsystem 400 may be operable to attempt to confirm that the online resource 113 identified by the merchant identifier 167 of the received challenge request data 664 at business entity subsystem 400 is a valid and registered online resource, which may be confirmed by identifying that merchant identifier 167 in table 430 (e.g., to determine that merchant identifier 167 has been registered with business entity subsystem 400 (e.g., in step 606) and that such registration is still valid (e.g., that business entity subsystem 400 has not removed merchant identifier 167 from table 430, or has not flagged merchant identifier 167 in table 430 as suspicious or otherwise no longer trusted)).Similarly, in the third merchant configuration, in response to the commercial entity subsystem 400 receiving any suitable challenge request data 664 containing credentials 177 from the PSP subsystem 310 in step 614, the commercial entity subsystem 400 can be operated to verify and check the credentials 177 of the received challenge request data 664 to ensure that its trust is still valid and has not expired, and if the received credentials 177 are verified, the FQDN and another merchant identifier 167 and the PSP identifier can be extracted from the received credentials 177, so that it can then be determined whether the identified PSP is authorized to conduct transactions on behalf of the identified merchant and whether the FQDN extracted at the commercial entity subsystem 400 is registered to the other extracted merchant identifiers to fully verify the request of step 614. The merchant identifier 167 may be a global merchant identifier for a particular merchant subsystem 200 (e.g., a single merchant identifier 167 may be used to identify both native application merchant online resources and website merchant online resources of a merchant subsystem 200, and / or a single FQDN may be associated with multiple merchant subsystems (e.g., a PSP's FQDN may be used by multiple merchant subsystems)). Both the FQDN and at least one other identifier (such as a unique identifier for a particular merchant subsystem 200 and / or a unique identifier for a particular PSP subsystem 310) may be retrieved from the credential 177 and confirmed at the commercial entity subsystem 400 (e.g., in table 430) as being associated with one another, as may have been accomplished at step 606. After any suitable verification of the received challenge request data 664 by the commercial entity subsystem 400 (e.g., after verifying the received credentials 177, and / or verifying the FQDN of the received credentials 177, and / or confirming an authorized relationship between the identified PSP and the identified merchant of the received credentials 177), in step 616, the commercial entity subsystem 400 may also be operable to generate any suitable verification data and store that verification data against any suitable identifier data of the received challenge request data 664.For example, after performing any suitable verification of the received challenge request data 664 at step 616, commercial entity subsystem 400 may also be operable to generate any suitable verification data (e.g., any suitable random data via entropy and / or any suitable cryptographically compiled temporary value (e.g., similar to the verification data of step 622 described above)) and a verification session identifier (e.g., any suitable alphanumeric string or any other suitable identifier that can uniquely identify the current online resource verification session to commercial entity subsystem 400 (e.g., as may be generated by electronic device 100 at step 612, or may be generated by merchant subsystem 200 or PSP subsystem 310 at step 614, or may be generated by commercial entity subsystem 400 at step 616)) at step 616, and then, at step 616, commercial entity subsystem 400 may store that verification data against one or both of the verification session identifier and the merchant identifier of challenge request data 664 in any suitable data structure accessible to commercial entity subsystem 400 (e.g., in table 430 or otherwise). Thus, in certain embodiments, a verification session identifier may be generated by commercial entity subsystem 400 such that commercial entity subsystem 400 can ensure (at least with respect to a particular merchant identifier) ​​that the verification session identifier is unique to the particular verification procedure being performed by commercial entity subsystem 400. However, if the verification session identifier is generated by merchant subsystem 200 or PSP subsystem 310, commercial entity subsystem 400 may confirm that the verification session identifier is unique to the merchant identifier for that verification session before enabling that verification session identifier for use in that particular verification session. Otherwise, commercial entity subsystem 400 may reject the verification session identifier and request that a new verification session identifier be generated by merchant subsystem 200 or PSP subsystem 310. This stored connection or association between such verification data and the identifier data for the verification session (e.g., the verification session identifier and / or merchant identifier of challenge request data 664) may later be used by commercial entity subsystem 400 to further secure the secure data transaction to be performed (e.g., at step 630). Additionally, in some embodiments, at step 616, any or all of the potential transaction identifying information of the challenge request data 664 may also be stored against or otherwise associated with the verification data and identifier data.

[0107] In any of the first merchant configuration, the second merchant configuration, and the third merchant configuration, after this step 616, steps 618, 620, and 622 may be skipped because the online resource may be authenticated in a single set of steps 614 and 616, and then process 600 may include step 624, at which step commercial entity subsystem 400 may be operable to generate and transmit any suitable authentication response data 674. For example, authentication response data 674 may be a session artifact that may include the authentication data of step 616 together with any other suitable data, including, but not limited to: an authentication session identifier (e.g., an authentication session identifier generated at step 616); one or more merchant identifiers (e.g., any or each merchant identifier of challenge request data 664 (e.g., FQDN, other merchant identifier, PSP identifier, etc.), and / or as may otherwise be associated at commercial entity subsystem 400 (e.g., in table 430) with the online resource authenticated during the authentication session); credentials 177 of challenge request data 664; and / or the like. In some embodiments, as Figure 6As shown in , such verification response data 674 may be transmitted directly from the business entity subsystem 400 to the electronic device 100 (e.g., via the communication path 65 using any suitable communication protocol), where data identifying the electronic device 100 (e.g., the device identifier 119) may be associated with or otherwise included in the verification session initiation data 662 and / or the challenge request data 664, or others, so that the business entity subsystem 400 can transmit the verification response data 674 to the appropriate electronic device 100. Alternatively, in some embodiments (not shown), the verification response data 674 may be transmitted from the commercial entity subsystem 400 to the electronic device 100 via the merchant subsystem 200 (e.g., in the first merchant configuration and the second merchant configuration) and / or via the PSP subsystem 310 (e.g., in the third merchant configuration), whereby the merchant subsystem 200 and / or the PSP subsystem 310 may receive the verification response data 674 from the commercial entity subsystem 400 and then pass at least a portion of the verification response data 674 to the electronic device 100. The session artifact of the verification response data 674 may be signed by the commercial entity subsystem 400 (e.g., in an HTTP header or otherwise) using an access key associated with the commercial entity subsystem 400 and accessible to the electronic device 100 (e.g., access key 155a, access key 155b, CRS 151k, and / or ISD key 156k of the secure element 145, or any key known to a device application (e.g., card management application 103b)), so that the device 100 may verify the signature upon receiving the signed verification data to confirm that the verification response data 674 was generated by the commercial entity subsystem 400 and not by another entity subsystem that is not trusted by the electronic device 100, and / or to prevent another entity that does not have access to such an access key (e.g., merchant subsystem 200 and / or PSP subsystem 310) from using the signed verification data while still enabling other entities to receive and forward such signed verification data to the device 100.

[0108] In any of the first merchant configuration, the second merchant configuration, and the third merchant configuration, if the user of device 100 is willing and able to select or confirm specific payment credentials to be used in funding the potential transaction in response to the potential transaction data 660 (e.g., payment request data) received in step 610, and verification response data 674 (e.g., data that may indicate that the merchant online resource of steps 612 to 616 successfully authenticated the session) has been received by electronic device 100 in step 624, then process 600 may proceed to step 625, at which step, process 600 may include: after any session identifier consistency has been identified (e.g., as mentioned above, in step 625), receiving the user of device 100's intention and authentication (e.g., through the user selecting) to use specific credentials to conduct a potential transaction for a specific merchant, product, price, and shipping destination based on potential transaction data 660 Figure 3CAuthentication prompt 315). In some embodiments, in addition to or as an alternative to step 625 including verifying session identifier consistency prior to such intent and authentication, step 625 may include verifying domain consistency prior to such intent and authentication. For example, in response to the device 100 receiving the verification response data 674 at step 624, the device 100 may be operable to compare the domain identifier of such verification response data 674 (e.g., the FQDN of the verification response data 674) with the domain identifier currently in the URL list of the online resource of the device 100. For example, the web suite of the device 100 (e.g., the online resource application 113) may receive the verification response data 674 and relay that verification response data 674 along with the domain identifier (e.g., the FQDN) currently targeted by the web suite to the pass suite of the device 100 (e.g., the card management application 103b). The pass kit may then verify the signature (if any) of the received authentication response data 674 (e.g., using an access key of device 100), extract a domain identifier (e.g., an FQDN) from the authentication response data 674, and then compare the extracted domain identifier with a domain identifier identified by and provided from the web kit (e.g., the FQDN of a javascript currently hosted by the web kit of device 100 (e.g., the FQDN of a merchant online resource in the first merchant configuration and the second merchant configuration, and the FQDN of a PSP online resource in the third merchant configuration)), which may enable device 100 to confirm that the response data 674 is associated with the same online resource currently accessed by device 100 (e.g., to avoid a replay attack). After any suitable session identifier consistency and / or any suitable domain identifier consistency has been verified at step 625, an intent and authentication for a particular payment credential may be received at step 625. Next, for each of the first merchant configuration, the second merchant configuration, and the third merchant configuration, steps 626 through 629 may occur as described above, where any or all suitable portions of the verification response data 674 (e.g., a session identifier, verification data (e.g., a temporary value), the FQDN, and / or any other suitable merchant identifier or PSP identifier, and / or any other data (e.g., at least a portion of the credentials 177)) may be included as device transaction data 678 along with the secure device data 677 and the transaction data 660.

[0109] In any of the first merchant configuration, the second merchant configuration, and the third merchant configuration, at step 630, commercial entity subsystem 400 may be operable to verify the verification data of verification response data 674 that device 100 may have included in device transaction data 678. For example, in response to receiving such device transaction data 678, at step 630 (e.g., similar to step 516 of process 500), commercial entity subsystem 400 may be operable to identify at least a portion or all of the verification response data 674 from that device transaction data 678 and confirm that the verification data of that received device transaction data 678 is currently stored at commercial entity subsystem 400, or more specifically, in some embodiments, confirm that the verification data of that received device transaction data 678 is currently stored at commercial entity subsystem 400 against the verification session identifier of the received device transaction data 678 and / or against the merchant identifier (e.g., FQDN) of the received device transaction data 678 (e.g., in table 430). This stored link between the verification data and one or both of the verification session identifier and the merchant identifier may be maintained for only a limited amount of time before the link is automatically cleared, such that the electronic device 100 is subject to having to receive the verification response data 674 at step 624 and then send the device transaction data 678 to the commercial entity subsystem 400 at step 628 within a certain duration, for implementing the security of the secure device data 677 that protects the device transaction data 678 by the commercial entity subsystem 400 for use in conducting specific secure data transactions using verified merchant online resources (e.g., the commercial entity subsystem 400 may be operable to remove this association between the verification data and the verification session identifier and / or merchant identifier at the commercial entity subsystem 400 after a certain period of time (e.g., removing the link from the form 430 no more than 10 minutes after the link is established), which may increase transaction security).Additionally or alternatively, at step 622, the stored link between the verification data and one or both of the verification session identifier and the merchant identifier may also be associated (e.g., as part of challenge request data 664) with any suitable specific potential transaction identification information (which may be made available to commercial entity subsystem 400 by merchant subsystem 200 or PSP subsystem 310 at step 614), such as an identification of a specific type of security data to be shared between device 100 and merchant subsystem 200 or PSP subsystem 310 (e.g., the currency and amount and payment type for a financial transaction, and similar specific potential transaction identification information may also be made available to commercial entity subsystem 400 by electronic device 100 as part of device transaction data 678 at step 628), such that step 630 may also include commercial entity subsystem 400 confirming that the specific potential transaction identification information currently stored against the verification data received at step 614 (e.g., as stored in table 430 at step 616) is at least similar to the specific potential transaction identification information received at step 628.

[0110] Next, at step 631, process 600 may include commercial entity subsystem 400 identifying a merchant key (e.g., merchant key 157) associated with merchant subsystem 200 or PSP subsystem 310 (e.g., at step 606, the subsystem may have generated the first CSR for the key to be used for authenticating the online resource of the session). That is, after decrypting at least a portion of the device transaction data 678 using appropriate access information in step 629 (e.g., after decrypting secure device data 677 to materialize device payment credential data 676 and any other information that may have been encrypted in secure device data 677), then, in step 631, commercial entity subsystem 400 may re-encrypt at least a portion of the device transaction data 678 (e.g., token data and / or cryptographic data of device payment credential data 676) as encrypted merchant credential data 681 using an appropriate merchant key 157 of merchant subsystem 200 (e.g., for a first merchant configuration) or using an appropriate merchant key 157 of PSP subsystem 310 (e.g., for a second merchant configuration and a third merchant configuration), where that appropriate merchant key 157 may be identified at commercial entity subsystem 400 using any appropriate identifier data that may be included in the verification data in data 678 and using any pre-stored association associated with that identifier data (e.g., in table 430, as may be defined during step 606). For example, encrypted merchant credential data 681 may include at least encrypted device payment credential data 676 from device transaction data 678 and any suitable transaction data, such as purchase total data or other suitable transaction data from or based on device transaction data 678 and / or potential transaction data 660. Encrypted merchant credential data 681 may be signed by commercial entity subsystem 400 so that when received by merchant subsystem 200 or PSP subsystem 310, that subsystem may establish commercial entity subsystem 400 as the creator of such encrypted merchant credential data 681 and / or may enable that subsystem to ensure that such encrypted merchant credential data 681 has not been modified after being signed. Such encrypted merchant credential data 681 may be generated at step 631 and then transmitted to device 100 along with any other suitable data at step 632 as secured transaction data 682 (e.g., via Figure 1A Path 65 is transmitted from the server 410 of the commercial entity subsystem 400 to the communication component 106 of the device 100).

[0111] Steps 631 and 632 are operable to ensure that the data transmitted from the business entity subsystem 400 as Figure 1AThe credential data of a portion of the secured transaction data 682 (e.g., the token data and / or cryptographic data of the encrypted merchant credential data 681) may be encrypted such that no portion of the device 100 other than the secure element 145 may decrypt the credential data. That is, the credential data of the secured transaction data 682 (e.g., the token data and / or cryptographic data of the encrypted merchant credential data 681) may be encrypted with a merchant key (e.g., merchant key 157) that may not be exposed to or otherwise accessible by any portion of the device 100 (including the secure element 145 in some embodiments). Additionally, the credential data of the secured transaction data 682 (e.g., the token data and / or cryptographic data of the encrypted merchant credential data 681) may be encrypted with a credential key 155a' that may not be exposed to or otherwise accessible by any portion outside of the secure element 145 of the device 100.

[0112] In both the first merchant configuration and the second merchant configuration, the secured transaction data 682 may then be forwarded by device 100 to merchant subsystem 200 as secured transaction data 684 (e.g., via communication path 15 or as contactless proximity-based communication 5) at step 634, or alternatively, merchant credential data 681 may be transmitted from commercial entity subsystem 400 to merchant subsystem 200 without being transmitted via device 100 (not shown). A portion, some portion, or all of the potential transaction data 660 may be transmitted to secured transaction data 682 and / or to secured transaction data 684 by device 100 and / or commercial entity subsystem 400 so that certain identifiers of the potential transaction may be identified by each of the entities during process 600.

[0113] Once the merchant credential data 681 including the payment credential data 675 / 676 is received by the merchant subsystem 200 (e.g., as the secured transaction data 684, at step 634), the process 600 may also include a step 636, at which the merchant subsystem 200 may be configured to generate and transmit the payment data 686. In a first merchant configuration, for example, at step 636, the merchant subsystem 200 may leverage its known merchant key 157 to at least partially decrypt the merchant credential data 681 of the secured transaction data 684, such that the payment data 686 may include the secured payment credential data (e.g., data 676) of the credential SSD 154a encrypted with its credential key 155a' (rather than with a key not available to the financial institution subsystem 350), and such data 686 may then be transmitted by the merchant subsystem 200 to any suitable subsystem (e.g., the acquiring bank subsystem 300 and / or the PSP subsystem 310). Alternatively, in a second merchant configuration, for example, at step 636, the merchant subsystem 200 may forward the re-encrypted merchant credential data 681 of the secured transaction data 684 to the PSP subsystem 310 as the payment data 686, and then the PSP subsystem 310 may leverage its known merchant key 157 to at least partially decrypt that re-encrypted merchant credential data 681 of the payment data 686. Alternatively, in a third merchant configuration, the secured transaction data 682 may be forwarded by the device 100 to the PSP subsystem 310 (e.g., using a PSP online resource currently accessible by the device 100), and then the PSP subsystem 310 may leverage its known merchant key 157 to at least partially decrypt that re-encrypted merchant credential data 681 of the forwarded secured transaction data. The remainder of process 600 may proceed as described above with respect to steps 638 through 644, with one or more appropriate ones of merchant subsystem 200 and PSP subsystem 310 in data communication with device 100, depending on the applicable merchant configuration.

[0114] Figure 7 Description

[0115] Figure 7is a flow chart of steps of an illustrative process 700 for using an entity subsystem to conduct a secure transaction between a processing subsystem and an electronic device communicatively coupled to the processing subsystem via an online resource executed on an electronic device. At step 702 of process 700, the business entity subsystem may receive a verification request for the online resource, where the verification request may include verification request data (e.g., at step 614 of process 600, business entity subsystem 400 may receive challenge request data 664, and / or at step 620, business entity subsystem 400 may receive challenge response data 670). At step 704 of process 700, the administrative entity subsystem may use the verification request data and registration data to verify the online resource, wherein the registration data was initially made available to the administrative entity subsystem prior to receiving the verification request (e.g., at step 616 of process 600, commercial entity subsystem 400 may use challenge request data 664 and registration data from step 606 to verify online resource 113, and / or at step 622 of process 600, commercial entity subsystem 400 may use challenge response data 670 and registration data from step 606 to verify online resource 113). At step 706 of process 700, the administrative entity subsystem may associate verification response data with at least a portion of the verification request data (e.g., at step 616 of process 600 and / or at step 622, commercial entity subsystem 400 may associate verification data with identifier data). At step 708 of procedure 700, the management entity subsystem may transmit the verification response data to the electronic device (e.g., at step 624 of procedure 600, the business entity subsystem 400 may transmit the verification data (as part of the verification response data 674) to the electronic device 100). At step 710 of procedure 700, the management entity subsystem may receive the device transaction data from the electronic device (e.g., at step 628 of procedure 600, the business entity subsystem 400 may receive the device transaction data 678 from the electronic device 100). At step 712 of procedure 700, the management entity subsystem may use the verification response data to verify the device transaction data (e.g., at step 630 of procedure 600, the business entity subsystem 400 may use the verification response data 674 to verify the verification data of the device transaction data 678). In step 714 of procedure 700, after the device transaction data has been verified, the management entity subsystem may generate secure transaction data based on the device transaction data for use by the processing subsystem (for example, in step 631 of procedure 600, the commercial entity subsystem 400 may generate merchant credential data 681 based on the device transaction data 678).

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

[0117] Figure 8 Description

[0118] Figure 8 is a flow chart of steps of an illustrative procedure 800 for using a management entity subsystem to implement a secure transaction between a processing subsystem and an electronic device communicatively coupled to the processing subsystem via an online resource executed on an electronic device. In step 802 of procedure 800, the management entity subsystem may register the online resource by establishing a processing shared secret between the management entity subsystem and the processing subsystem (e.g., in step 606 of procedure 600, the commercial entity subsystem 400 may register the online resource 113 by establishing a shared secret with the merchant subsystem 200). In step 804 of procedure 800, the management entity subsystem may receive a verification request for the online resource, wherein the verification request may include a processing identifier indicating the online resource, and wherein the verification request may also include a verification session identifier unique to a potential transaction between the electronic device and the processing subsystem via the online resource (for example, in step 614 of procedure 600, the business entity subsystem 400 may receive challenge request data 664 including a merchant identifier and a session identifier, and / or in step 620 of procedure 600, the business entity subsystem 400 may receive challenge response data 670 including a merchant identifier and a session identifier). In step 806 of procedure 800, the management entity subsystem may use the verification session identifier and the processing shared secret to verify the online resource indicated by the processing identifier (for example, in step 616 of procedure 600, the business entity subsystem 400 may use the challenge request data 664 and the registration data from step 606 to verify the online resource 113, and / or in step 622 of procedure 600, the business entity subsystem 400 may use the challenge response data 670 and the registration data from step 606 to verify the online resource 113).

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

[0120] Fig. 9 Description

[0121] Fig. 9is a flow chart of steps of an illustrative process 900 for using a management entity subsystem to conduct a secure transaction between a processing subsystem and an electronic device communicatively coupled to the processing subsystem via an online resource executed on an electronic device. At step 902 of process 900, the management entity subsystem may receive a verification request for the online resource, wherein the verification request may include verification request data, and wherein the verification request data may include potential transaction identification information indicating a potential transaction between the electronic device and the processing subsystem via the online resource (e.g., at step 614 of process 600, commercial entity subsystem 400 may receive challenge request data 664, and / or at step 620, commercial entity subsystem 400 may receive challenge response data 670). At step 904 of procedure 900, the management entity subsystem may use at least a portion of the verification request data to verify the online resource (e.g., at step 616 of procedure 600, the business entity subsystem 400 may use the challenge request data 664 to verify the online resource 113, and / or at step 622 of procedure 600, the business entity subsystem 400 may use the challenge response data 670 to verify the online resource 113). At step 906 of procedure 900, the management entity subsystem may associate the verification response data with at least the potential transaction identification information (e.g., at step 616 and / or step 622 of procedure 600, the business entity subsystem 400 may associate the verification data with the potential transaction identification information). At step 908 of procedure 900, the management entity subsystem may transmit the verification response data to the electronic device (e.g., at step 624 of procedure 600, the business entity subsystem 400 may transmit the verification data (as part of the verification response data 674) to the electronic device 100). At step 910 of process 900, the management entity subsystem may receive device transaction data from the electronic device (e.g., at step 628 of process 600, commercial entity subsystem 400 may receive device transaction data 678 from electronic device 100). At step 912 of process 900, the management entity subsystem may use the verification response data and the potential transaction identification information to verify the device transaction data (e.g., at step 630 of process 600, commercial entity subsystem 400 may use verification response data 674 and potential transaction identification information to verify the verification data of device transaction data 678). At step 914 of process 900, after verifying the device transaction data, the management entity subsystem may generate secure transaction data based on the device transaction data for use by the processing subsystem (e.g., at step 631 of process 600, commercial entity subsystem 400 may generate merchant credential data 681 based on device transaction data 678).

[0122] It should be understood that Fig. 9The steps shown in process 900 are illustrative only, and existing steps may be modified or omitted, additional steps may be added, and the order of certain steps may be changed.

[0123] Further description of the embodiments

[0124] When the credential of the secure element of device 100 is appropriately enabled (e.g., commerce credential data associated with the enabled applet 153a of credential SSD 154a) to provide payment credential data as transaction data (e.g., as a contactless proximity-based communication to a merchant terminal 220 and / or as an online-based communication to a merchant server 210), the acquiring bank subsystem 300 may utilize such payment credential data for completing a financial transaction with the financial institution subsystem 350. For example, after a user of electronic device 100 has selected a product to be purchased and has appropriately enabled a particular credential of device 100 to be used for payment, merchant subsystem 200 may receive payment credential data indicating payment credential information for that 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 the end-user electronic device in response to device 100 providing the payment credential data. Based on such received payment credential data (e.g., as data 684), the merchant subsystem 200 may be configured to generate and transmit data 686 to the acquiring bank subsystem 300 (e.g., via the communication path 25 between the merchant subsystem 200 and the acquiring bank subsystem 300), wherein the data 686 may include payment credential information and an authorization request, which may indicate the device payment credential and the merchant's 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 cooperate with the financial institution subsystem 350 to use the payment credential data to approve and settle a credential transaction attempted to be funded by the device 100. The acquiring bank subsystem 300 may then forward the authorization request from the payment data 686 to the financial institution subsystem 350 as authorization request data 688 (e.g., via the communication path 35 between the acquiring bank subsystem 300 and the financial institution subsystem 350).

[0125] The payment network subsystem 360 and the issuing bank subsystem 370 may be a single entity or separate entities. For example, American Express may be both the payment network subsystem 360 and the issuing bank subsystem 370. In contrast, Visa and MasterCard may be payment networks 360 and may work with issuing banks 370, such as Chase, Wells Fargo, Bank of America, and the like. The financial institution subsystem 350 may also include one or more acquiring banks, such as the acquiring bank subsystem 300. For example, the acquiring bank subsystem 300 may be the same entity as the issuing bank subsystem 370. Components, some components, or all components of the acquiring bank subsystem 300 may be implemented using each of the following: one or more processor components, which may be the same as or similar to the processor component 102 of the device 100; one or more memory components, which may be the same as or similar to the memory component 104 of the device 100; and / or one or more communication components, which may be the same as or similar to the communication component 106 of the device 100. Components, some components, or all components of the payment network subsystem 360 may be implemented using each of the following: one or more processor components, which may be the same as or similar to the processor component 102 of the device 100; one or more memory components, which may be the same as or similar to the memory component 104 of the device 100; and / or one or more communication components, which may be the same as or similar to the communication component 106 of the device 100. Components, some components, or all components of the issuing bank subsystem 370 may be implemented using each of the following: one or more processor components, which may be the same as or similar to the processor component 102 of the device 100; one or more memory components, which may be the same as or similar to the memory component 104 of the device 100; and / or one or more communication components, which may be the same as or similar to the communication component 106 of the device 100. In the case where the payment network subsystem 360 and the issuing bank subsystem 370 are separate entities, the payment network subsystem 360 may receive the data 690 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 case where the payment network subsystem 360 and the issuing bank subsystem 370 are the same entity, the acquiring bank subsystem 300 may submit the data 690 directly to the issuing bank subsystem 370. In addition, the payment network subsystem 360 may respond to the acquiring bank subsystem 300 on behalf of the issuing bank subsystem 370 (e.g., according to the terms of an agreement between the payment network subsystem 360 and the issuing bank subsystem 370).By interfacing between the acquiring bank subsystem 300 and the issuing bank subsystem 370, the payment network subsystem 360 can reduce the number of entities that each acquiring bank subsystem 300 and each issuing bank subsystem 370 may have to interact with directly. That is, in order to minimize the direct integration points of the financial institution subsystem 350, the payment network subsystem 360 can act as an aggregator for various issuing banks 370 and / or various acquiring banks 300. The financial institution subsystem 350 can also include one or more acquiring banks, such as the acquiring bank subsystem 300. For example, the acquiring bank subsystem 300 can be the same entity as the issuing bank subsystem 370.

[0126] When the issuing bank subsystem 370 receives the authorization request (e.g., directly from the acquiring bank subsystem 300 as data 688, or indirectly via the payment network subsystem 360 as data 405), the payment information (e.g., the business credentials of the information device 100) and the purchase amount included in the authorization request may be analyzed to determine whether the account associated with the business credentials has sufficient credit to fulfill the purchase amount. If sufficient funds do not exist, the issuing bank subsystem 370 may deny the requested transaction by transmitting a negative authorization response to the acquiring bank subsystem 300. However, if sufficient funds exist, 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. Any type of authorization response may be provided by the user financial subsystem 350 to the acquiring bank subsystem 300 as authorization response data or transaction status data 690 (for example, the transaction status data 690 may be provided directly from the issuing bank subsystem 370 to the acquiring bank subsystem 300 via the communication path 35, or the transaction status data 690 may be provided from the payment network subsystem 360 to the acquiring bank subsystem 300 based on the authorization response data or transaction status data 415 that may be provided from the issuing bank subsystem 370 to the payment network subsystem 360 via the communication path 45).

[0127] As mentioned, and as Figure 2 As shown in FIG. 1 , the electronic device 100 may include, but is not limited to, a music player (e.g., an iPod commercially 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, radios, medical devices, household or business appliances, transportation vehicles, musical instruments, calculators, cellular phones (e.g., the 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, stereo equipment, digital video converter boxes (set up boxes), set-top boxes, 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 conducting secure data transactions), and in other embodiments, the electronic device 100 can perform multiple functions (e.g., a device for conducting secure data transactions, playing music, and making and receiving telephone calls). The electronic device 100 can be any portable, mobile, handheld, or microelectronic device that can be configured to conduct financial transactions wherever the user is. Some microelectronic devices can have a smaller size than a handheld electronic device (such as an iPod). TM ) form factor. The illustrative microelectronic device may be incorporated into a variety of articles, such articles may include, but are not limited to: a wristwatch (e.g., Apple Watch by Apple Inc. TM ), a ring, a necklace, a belt, a belt accessory, a headset, a shoe accessory, a virtual reality device, glasses, other wearable electronic devices, accessories for sports equipment, accessories for fitness equipment, a key chain, or any combination thereof. Alternatively, the electronic device 100 may be completely non-portable and may instead be substantially stationary.

[0128] like Figure 2 , the electronic device 100 may include, for example, a processor 102, a memory 104, a communication component 106, a power supply 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 paths for transmitting data and / or power to, from, or between various other components of the device 100. In some embodiments, one or more components of the electronic device 100 may be combined or omitted. Additionally, the electronic device 100 may include 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 of these components is shown.

[0129] The memory 104 may include one or more storage media, including, for example, a hard disk drive, flash memory, permanent memory such as read-only memory ("ROM"), semi-permanent memory such as random access memory ("RAM"), any other suitable type of storage component, or any combination thereof. The memory 104 may include a cache, which may be one or more different types of memory used to temporarily store data for electronic device applications. The memory 104 may be fixedly embedded in the electronic device 100 or may be incorporated into 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 and image files), software (e.g., for implementing functions on device 100), firmware, preference information (e.g., media playback preferences), lifestyle information (e.g., food preferences), exercise information (e.g., information obtained by an exercise 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 that tracks 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.

[0130] 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, B...

Claims

1. A method for facilitating a transaction between a merchant subsystem and a computing device, the method comprising, at the computing device: Interfacing with the merchant subsystem to initiate the transaction; determining whether first verification data has been received from the commercial entity subsystem, wherein the first verification data indicates that the commercial entity subsystem has authenticated the merchant subsystem; In response to determining that first verification data has been received from the commercial entity subsystem: providing second authentication data and security data to the business entity subsystem, wherein the second authentication data is based at least in part on the first authentication data, determining whether encrypted security data was received from the commercial entity subsystem in response to the commercial entity subsystem authenticating the second verification data, and In response to determining that the encrypted security data has been received from the business entity subsystem: The encrypted security data is provided to the merchant subsystem to complete the transaction.

2. The method according to claim 1, wherein: Before providing the first authentication data, the business entity subsystem: receiving a challenge request from the merchant subsystem, the challenge request including a merchant identifier associated with (1) the merchant subsystem and (2) a merchant online resource of the computing device, wherein the challenge request includes a signature created using a merchant key associated with the merchant subsystem, obtaining the merchant key based on the merchant identifier, and The signature is verified using the merchant key.

3. The method according to claim 2, wherein: Prior to receiving the challenge request, the commercial entity subsystem receives (1) the merchant identifier and (2) the merchant key during a registration process with the merchant subsystem.

4. The method of claim 2, wherein the second authentication data comprises an authentication session identifier, the authentication session identifier: established between the computing device and the merchant subsystem in conjunction with initiating the transaction, and Provided by the merchant subsystem to the commercial entity subsystem in the challenge request.

5. The method of claim 4, wherein the verification session identifier is associated with the merchant key for a threshold amount of time.

6. The method according to claim 1, wherein the security data comprises: Payment credential data to be used in a financial transaction, or Health data to be used in health transactions.

7. The method of claim 1, wherein the encrypted secure data is encrypted using a merchant key associated with the merchant subsystem.

8. The method of claim 1, wherein the second authentication data is authentication data that enables a commercial entity subsystem to authenticate the computing device.

9. A computing device configured to perform a transaction with a merchant subsystem, the computing device comprising: means for interfacing with said merchant subsystem to initiate said transaction; means for determining whether first verification data has been received from the commercial entity subsystem, wherein the first verification data indicates that the commercial entity subsystem has authenticated the merchant subsystem; as well as Means for, in response to determining that first authentication data has been received from the commercial entity subsystem, performing the following operations: providing second authentication data and security data to the business entity subsystem, wherein the second authentication data is based at least in part on the first authentication data, determining whether encrypted security data was received from the commercial entity subsystem in response to the commercial entity subsystem authenticating the second verification data, and In response to determining that the encrypted security data has been received from the business entity subsystem: The encrypted security data is provided to the merchant subsystem to complete the transaction.

10. The computing device according to claim 9, wherein: Before providing the first authentication data, the business entity subsystem: receiving a challenge request from the merchant subsystem, the challenge request including a merchant identifier associated with (1) the merchant subsystem and (2) a merchant online resource of the computing device, wherein the challenge request includes a signature created using a merchant key associated with the merchant subsystem, obtaining the merchant key based on the merchant identifier, and The signature is verified using the merchant key.

11. The computing device according to claim 10, wherein: Prior to receiving the challenge request, the commercial entity subsystem receives (1) the merchant identifier and (2) the merchant key during a registration process with the merchant subsystem.

12. The computing device of claim 10, wherein the second authentication data comprises an authentication session identifier, the authentication session identifier: established between the computing device and the merchant subsystem in conjunction with initiating the transaction, and Provided by the merchant subsystem to the commercial entity subsystem in the challenge request.

13. The computing device of claim 12, wherein the verification session identifier is associated with the merchant key for a threshold amount of time.

14. The computing device of claim 9, wherein the security data comprises: Payment credential data to be used in a financial transaction, or Health data to be used in health transactions.

15. A computing device configured to perform a transaction with a merchant subsystem, the computing device comprising a processor, the processor configured to cause the computing device to perform steps comprising: Interfacing with the merchant subsystem to initiate the transaction; determining whether first verification data has been received from the commercial entity subsystem, wherein the first verification data indicates that the commercial entity subsystem has authenticated the merchant subsystem; as well as In response to determining that first verification data has been received from the commercial entity subsystem: providing second authentication data and security data to the business entity subsystem, wherein the second authentication data is based at least in part on the first authentication data, determining whether encrypted security data was received from the commercial entity subsystem in response to the commercial entity subsystem authenticating the second verification data, and In response to determining that the encrypted security data has been received from the business entity subsystem: The encrypted security data is provided to the merchant subsystem to complete the transaction.

16. The computing device of claim 15, wherein: Before providing the first authentication data, the business entity subsystem: receiving a challenge request from the merchant subsystem, the challenge request including a merchant identifier associated with (1) the merchant subsystem and (2) a merchant online resource of the computing device, wherein the challenge request includes a signature created using a merchant key associated with the merchant subsystem, obtaining the merchant key based on the merchant identifier, and The signature is verified using the merchant key.

17. The computing device of claim 16, wherein: Prior to receiving the challenge request, the commercial entity subsystem receives (1) the merchant identifier and (2) the merchant key during a registration process with the merchant subsystem.

18. The computing device of claim 16, wherein the second authentication data comprises an authentication session identifier, the authentication session identifier: established between the computing device and the merchant subsystem in conjunction with initiating the transaction, and Provided by the merchant subsystem to the commercial entity subsystem in the challenge request.

19. The computing device of claim 18, wherein the verification session identifier is associated with the merchant key for a threshold amount of time.

20. The computing device of claim 15, wherein the security data comprises: Payment credential data to be used in a financial transaction, or Health data to be used in health transactions.

Images