This patent application claims the benefit of previously filed U.S. provisional patent application 62/399,166 filed on 9/23/2016, which is hereby incorporated by reference in its entirety.
Detailed Description
One or more first user credentials (e.g., payment credentials or any other suitable transaction credentials) may be provided on a secure element of a host electronic device for use by an authenticated first user of the device, while one or more second user credentials may also be provided on the device for use by an authenticated second user of the device. The management entity subsystem may be operated by a management entity for providing a layer of security and/or a more convenient user experience for the use of such user credentials. The credential protection subsystem of such a management entity subsystem may be used to manage the provisioning of such user credentials on the electronic device (e.g., from a credential issuer subsystem), while the device protection subsystem of such a management entity subsystem may be used to provide one or more device protection services for protecting the electronic device when the electronic device is reported lost or stolen. However, when such an electronic device may include sensitive data from two or more different users, such as a provisioned first user credential and a provisioned second user credential, such a device protection subsystem may be configured to suspend the functionality of all user credentials provisioned on the device when the device is lost to be protected in order to protect all such sensitive data. Such protection may include the device protection subsystem instructing the credential protection subsystem to suspend or otherwise prevent the use of each user credential on the device, thereby preventing use for any transaction (e.g., with the credential issuer subsystem and/or the service provider subsystem), whereby the credential protection subsystem may be used to prevent secure communication of any credential data from the device and/or instruct the credential issuer subsystem to reject any transaction using the credential provisioned on the protected device. However, in such embodiments, to limit the likelihood of privacy and/or security breaches, the management entity subsystem may be used to prevent the device protection subsystem from storing, at the device protection subsystem, information that may specifically link two or more particular users to a particular electronic device. In contrast, the system of the present disclosure may use user-anonymous suspend tokens, each of which may be associated with a particular user of the electronic device at the credential protection subsystem but may not be associated with a particular user at the device protection subsystem, such that the device protection subsystem may not have access to data that may be used to identify two or more particular users to a single electronic device.
Description of FIG. 1
Fig. 1 is a schematic diagram of anexemplary system 1 that may allow management of credentials for multiple users on an electronic device. For example, as shown in fig. 1,system 1 may include a plurality of end-user host electronic devices 100 (e.g., laptop computers (see, e.g., fig. 1) or smart phones (see, e.g., fig. 3)) having at least one first user credential of first user U1 provisioned thereon (e.g., on a secure element of host electronic device 100) and at least one second user credential of second user U2 provisioned thereon.System 1 may also include a management (or commercial or trusted)entity subsystem 400, a service provider (or merchant or process)subsystem 200, and acredential issuer subsystem 300.System 1 may also include an acquisition (or payment processor) subsystem (not shown) that may utilize credential data generated from credentials provisioned onhost device 100 to complete a transaction withissuer subsystem 300 on behalf ofSP subsystem 200. Communication of any suitable data between any two of hostelectronic device 100, service provider ("SP")subsystem 200, management entity ("AE")subsystem 400, and credential issuer (or financial institution)subsystem 300 may be via any suitable communication arrangement9, the communication arrangement may comprise any suitable wired communication path, any suitable wireless communication path, or any suitable combination of two or more wired and/or wireless communication paths using any suitable communication protocol(s) and/or any suitable network(s) and/or cloud architecture(s). Each communication path between any two devices or subsystems of thesystem 1 using thecommunication arrangement 9 may be at least partially managed by one or more trusted service managers ("TSMs"). One or more of such communication paths may be provided using any suitable circuitry, device, system, or combination of these (e.g., a wireless communication infrastructure that may include one or more communication towers, telecommunication servers, etc.) that can be used to create a communication network, which can provide communications using any suitable wired or wireless communication protocol. For example, one or more of such communication paths may support Wi-Fi (e.g., 802.11 protocol), ZigBee (e.g., 802.15.4 protocol), WiDiTMEthernet, BluetoothTMBLE, high frequency systems (e.g., 900MHz communication system, 2.4GHz communication system, and 5.6GHz communication system), infrared, TCP/IP, SCTP, DHCP, HTTP, BitTorrentTMFTP, RTP, RTSP, RTCP, RAOP, RDTP, UDP, SSH, WDS bridging, any communication protocol usable by wireless and cellular phones and personal email devices (e.g., GSM plus EDGE, CDMA, OFDMA, HSPA, multiband, etc.), any communication protocol usable by a low power wireless personal area network ("6 LoWPAN") module, any other communication protocol, or any combination thereof.
Transaction credentials (e.g., payment credentials or any other suitable transaction credentials) may be provided from any suitable credential issuer subsystem 300 (e.g., an issuing bank subsystem or financial institution subsystem), directly from a credential issuer subsystem, or on hostelectronic device 100 via AE subsystem 400 (e.g., on a secure element or other storage component of host electronic device 100), which may be used to securely transfer credential data ontohost device 100 and manage such credential data. For example, thecredential issuer subsystem 300 may include afirst issuer subsystem 391 that may be operated by at least one first credential issuer (e.g., a first issuer bank, such as Wells Fargo (San Francisco, California)) with or without a first payment network authority (e.g., a first payment network, such as MasterCard (New York)) for provisioning at least one first user transaction credential for the first user U1 on the host device 100 (e.g., either directly or via the AE subsystem 400 (e.g., via thecredential protection subsystem 491 of the AE subsystem 400)). Thecredential issuer subsystem 300 may include a second issuing subsystem 392 that may be operated by at least one second credential issuing authority (e.g., a second issuing bank, such as Citibank) with or without a second payment network authority (e.g., a second payment network, such as Visa (Foster City, California)) for provisioning at least one second user transaction credential for a second user U2 on the host device 100 (e.g., directly or via the AE subsystem 400 (e.g., via thecredential protection subsystem 491 of the AE subsystem 400)). However, it should be understood that the first issuingsubsystem 391 may be used to provision one or more first user transaction credentials ondevice 100 for first user U1 and one or more second user transaction credentials ondevice 100 for second user U2, where no issuing subsystem may be used only to provision transaction credentials for a particular user. Once provisioned onhost device 100, the transaction credentials may be used byhost device 100 to securely fund or otherwise conduct a transaction (e.g., a commercial or financial transaction or any other suitable credential transaction) with SP subsystem 200 (e.g., any suitable subsystem that may be used to provide access to any suitable goods or services that are part of the transaction). For example, upon making a connection with service provider ("SP") subsystem 200 (e.g., via an online resource (e.g., an online application or web browser) or via a proximity-based contactless communication medium) to obtain (e.g., purchase) a service provider product or service,host device 100 may identify a particular transaction credential for funding or otherwise facilitating a transaction to access the service provider product.
AEsubsystem 400 may include acredential protection subsystem 491 which may be used to provide credential provisioning ondevice 100 and/or to provide an additional layer of security and/or efficiency for sharing of credential data fromhost device 100 toSP subsystem 200 to facilitate transactions. For example,credential protection subsystem 491 may be used to verify the trustworthiness of one or more issuing subsystems ofcredential issuer subsystem 300 on behalf ofdevice 100 prior to enabling credential provisioning ondevice 100 from the issuing subsystem, and/orcredential protection subsystem 491 may be used to encrypt, encode, or otherwise protect communications of transaction credential information from the issuing subsystem todevice 100 to ensure secure credential provisioning ondevice 100. Additionally or alternatively,credential protection subsystem 491 may be used to verify trustworthiness ofSP subsystem 200 on behalf ofdevice 100 prior to sharing transaction credential data fromdevice 100 toSP subsystem 200, and/orcredential protection subsystem 491 may be used to encrypt, encode or otherwise protect communication of transaction credential data fromdevice 100 toSP subsystem 200 to ensure secure transaction credential data sharing, facilitating transactions betweendevice 100 andSP subsystem 200.
Further, theAE subsystem 400 may include adevice protection subsystem 471 that may be used to provide an additional layer of security to the host device 100 (e.g., if thedevice 100 is to be lost or stolen).Device protection subsystem 471 may enable a user ofdevice 100 to registerdevice 100 using services ofdevice protection subsystem 471, which may be used to track a location ofdevice 100 and/or remotely control one or more functions ofdevice 100, such as turning on an alarm and/or erasing or pausing or otherwise terminating the usefulness of certain device content, such as pausing the ability of a secure element ofdevice 100 to generate transaction credential data for facilitating a transaction with a service provider. Such services may be useful to device owners whendevice 100 may be lost or stolen, so that the device may be recovered and/or so that sensitive data on the device may not be accessed.
However, whenhost device 100 may include sensitive data from two or more different users, such as a provisioned first user transaction credential of first user U1 and a provisioned second user transaction credential of second user U2,device protection subsystem 471 may be configured to suspend all user transaction credentials provisioned onhost device 100 whendevice 100 is lost, in order to protect all such sensitive data. Such protection may includedevice protection subsystem 471 instructingcredential protection subsystem 491 to suspend or otherwise prevent use of credentials ondevice 100, thereby preventing any transaction being used (e.g., with SP subsystem 200), wherebycredential protection subsystem 491 may be used to prevent secure communication of any credential data fromdevice 100 toSP subsystem 200 and/or instructcredential issuer subsystem 300 to reject any transaction using credentials provisioned ondevice 100. However, in such embodiments, to limit the likelihood of privacy and/or security breaches, theAE subsystem 400 may be used to prevent thedevice protection subsystem 471 from storing information at the device protection subsystem 471 (e.g., in a table or any othersuitable data structure 473 of a server or other suitable component of the device protection subsystem 471), which may specifically link two or more particular users to a particular device (e.g., specifically link first user U1 and second user U2 to host device 100). In contrast,system 1 may use user-anonymous suspend tokens, each of which may be associated with a particular user ofdevice 100 at credential protection subsystem 491 (e.g., in a table of a server or other suitable component ofcredential protection subsystem 491 or in any other suitable data structure 493) but may not be associated with a particular user atdevice protection subsystem 471, such thatdevice protection subsystem 471 may not have access to data that may be used to identify two or more particular users to a single electronic device.
Description of fig. 2, 2A and 3
Referring now to fig. 2, fig. 2 shows a more detailed view of theelectronic device 100 of thesystem 1. As shown in fig. 2, for example,device 100 may include aprocessor 102, amemory 104, acommunication component 106, apower supply 108, aninput component 110, anoutput component 112, anantenna 116, and a nearfield communication component 120.Device 100 may also include abus 118 that may provide one or more wired or wireless communication links or paths for wireless communicationVarious other components of thedevice 100 transmit data and/or power, transmit data and/or power from various other components of the device, or transmit data and/or power between various other components of the device. Theapparatus 100 may also be provided with ahousing 101 that may at least partially enclose one or more of the components of theapparatus 100 to protect it from debris and other degrading forces external to theapparatus 100. In some embodiments, one or more components of theapparatus 100 may be combined or omitted. Further,device 100 may include other components not incorporated or included in FIG. 2. For example,device 100 may include any other suitable components or several instances of the components shown in fig. 2. For simplicity, only one of each component is shown in FIG. 2.Electronic device 100 may be any portable, mobile, or handheld electronic device configured to store one or more transaction credentials for facilitating a transaction with an SP subsystem. Alternatively, theelectronic device 100 may not be portable at all, but may instead be generally stationary. Theelectronic device 100 can include, but is not limited to, a media player, a video player, a still image player, a game player, other media players, a music recorder, a movie or video camera or recorder, a still camera, other media recorder, a radio, a medical device, a home appliance, a vehicle meter, a musical instrument, a calculator, a cellular telephone (e.g., an iPhone available from Apple incTM) Other wireless communication devices, personal digital assistants, remote controls, pagers, computers (e.g., desktop, laptop, tablet, server, etc.), monitors, televisions, sound devices, set-top boxes, wearable devices (e.g., Apple Watch, available from Apple incTM) Small speakers, modems, routers, printers, and any combination thereof.
Memory 104 may include one or more storage media including, for example, a hard disk drive, flash memory, persistent storage such as read only memory ("ROM"), semi-persistent storage such as random access memory ("RAM"), any other suitable type of storage component, or any combination thereof. Thememory 104 may include cache memory, which may be one or more different types of memory for temporarily storing data for electronic device applications.Memory 104 may store media data (e.g., music files and image files), software (e.g., applications for implementing functions on device 100), firmware, preference information (e.g., media playback preferences), lifestyle information (e.g., eating preferences), sports information (e.g., information acquired by a sports monitoring device), transaction information, wireless connection information (e.g., information that may enabledevice 100 to establish a wireless connection), subscription information (e.g., information for tracking podcasts or television shows or other media subscribed to by a user), contact information (e.g., telephone numbers and email addresses), calendar information, any other suitable data, or any combination thereof.Communications component 106 may be operative to enabledevice 100 to communicate with one or more other electronic devices or servers or subsystems (e.g., one or more ofsubsystems 200, 300, and 400) using any suitable one or more communications protocols (e.g., one or more wired and/or wireless protocols via communications arrangement 9). Thepower supply 108 may provide power to one or more components of thedevice 100. In some embodiments, thepower supply 108 may be coupled to a power grid (e.g., when thedevice 100 is not a portable device such as a desktop computer). In some embodiments, thepower supply 108 may include one or more batteries for providing power (e.g., when thedevice 100 is a portable device such as a cellular telephone). As another example, thepower supply 108 may be configured to generate power from a natural source (e.g., solar energy using solar cells). One ormore input components 110 may be provided to allow a user or an ambient environment or data source to interact with or interface withdevice 100, and/or one ormore output components 112 may be provided to present information (e.g., graphical, audible, and/or tactile information) to a user ofdevice 100. It should be noted that the one or more input components and the one or more output components may be referred to collectively at times herein as input/output ("I/O") components or I/O interfaces 114 (e.g.,input component 110 andoutput component 112 act as I/O components or I/O interfaces 114). For example,input component 110 andoutput component 112 may sometimes be a single I/O component 114, such as a touch screen, that may receive input information by a user touching the display screen and may also provide visual information to the user via the same display screen.
Processor 102 ofdevice 100 may include any processing circuitry operable to control the operation and performance of one or more components ofdevice 100. For example,processor 102 may receive input signals frominput component 110 and/or drive output signals throughoutput component 112.Processor 102 ofhost device 100 may include any suitable processing circuitry operable to control the operation and performance of one or more components ofhost device 100. As shown in fig. 2,processor 102 may be used to run one or more applications (e.g.,application 103 and/or application 113) that may at least partially specify the manner in which data may be received, generated, and/or transmitted bydevice 100. As one example,application 103 may be an operating system application, andapplication 113 may be a third party application or any other suitable online resource (e.g., a protection application associated withdevice protection subsystem 471 ofAE subsystem 400, an application associated with a merchant ofSP subsystem 200, etc.). Further, as shown, theprocessor 102 may access hostdevice identification information 119, which may be used by thedevice 100 and/or theAE subsystem 400 and/or theissuer subsystem 300 and/or the user of theSP subsystem 200 to provide identification of thedevice 100. As just one example, hostdevice identification information 119 may be a telephone number or an email address or any unique identifier that may be associated withdevice 100 or a component thereof (e.g., a secure element of device 100).
Near field communication ("NFC")component 120 may be configured to communicate host transaction credential data and/or any other suitable data withSP subsystem 200 as proximity-based contactless communication (e.g., near field communication) (e.g., utilizing an SP NFC terminal ofSP subsystem 200, which may be located at a brick and mortar store or any physical location where a user ofhost device 100 may use credentials to conduct transactions with a proximately located SP terminal via proximity-based contactless communication).NFC component 120 may allow for relatively low data rates (b:e.g., 424kbps) and may conform to any suitable standard such as ISO/IEC 7816, ISO/IEC 18092, ECMA-340, ISO/IEC 21481, ECMA-352, ISO 14443, and/or ISO 15693.NFC component 120 may allow short-range communication at a higher data rate (e.g., 370Mbps) and may comply with any suitable standard, such as TransferJetTMAnd (4) protocol. Communication between theNFC component 120 and the NFC component of theSP subsystem 200 may occur within any suitable close range between the NFC component and theSP subsystem 200, such as a range of approximately 2 to 4 centimeters, and may operate at any suitable frequency (e.g., 13.56 MHz). For example, such near field communication by the NFC component may occur via magnetic field induction, which may allow the NFC component to communicate with other NFC devices and/or retrieve information from tags having radio frequency identification ("RFID") circuitry. AlthoughNFC component 120 has been described with respect to near field communication, it should be understood thatcomponent 120 may be configured to provide any suitable proximity-based contactless mobile payment or any other suitable type of proximity-based contactless communication betweendevice 100 and another entity, such as a terminal ofSP subsystem 200. For example,NFC component 120 may be configured to provide any suitable short-range communication, such as short-range communication involving electromagnetic/electrostatic coupling techniques.
NFC component 120 may include any suitable modules for enabling proximity-based contactless communication betweendevice 100 and such SP terminals. As shown in fig. 2, for example,NFC component 120 may include anNFC device module 130, an NFC controller module 140, and/or an NFC memory module 150.NFC device module 130 may include anNFC data module 132, anNFC antenna 134, and an NFC booster 136. TheNFC data module 132 may be configured to contain, route, or otherwise provide any suitable data that may be transmitted by theNFC component 120 to the SP terminal as part of the proximity-based contactless communication or NFC communication. TheNFC data module 132 can be configured to contain, route, or otherwise receive any suitable data that can be received by theNFC component 120 from an SP terminal as part of proximity-based contactless communication. NFC controller module 140 may include at least one NFC processor module 142. NFC processor module 142 may work in conjunction withNFC device module 130 to enable, activate, enable, and/or otherwise controlNFC component 120 for communicating NFC communications betweendevice 100 and SP terminals. NFC controller module 140 may include at least one NFC processor module 142 that may be used to run one or more applications, such as an NFC low power mode orwallet application 143 that may help indicate the functionality ofNFC component 120. NFC memory module 150 may work in conjunction withNFC device module 130 and/or NFC controller module 140 to allow NFC communication betweendevice 100 andSP subsystem 200. The NFC memory module 150 may be tamper resistant and may provide at least a portion of thesecure element 145 of thedevice 100. For example, thesecure element 145 may be configured to provide a tamper-resistant platform (e.g., as a single-chip or multi-chip secure microcontroller) that may be capable of securely hosting applications and their confidential and encrypted data (e.g., applet 153 and key 155) according to rules and security requirements that may be set forth by a set of recognized trusted authorities (e.g., authorities such as a credential issuer subsystem and/or a financial institution subsystem and/or industry standards such as GlobalPlatform).
As shown, for example, NFC memory module 150 may include one or more of an issuer security domain ("ISD") 152, one or more supplemental security domains ("SSDs") 154a-154c (e.g., service provider security domain ("SPSD"), trusted service manager security domain ("TSMSD"), credential SSD, access SSD, etc.), which may be defined and managed by an NFC specification standard (e.g., GlobalPlatform). For example,ISD 152 may be part of NFC memory module 150, where a trusted service manager ("TSM") or issuing financial institution (e.g., issuer subsystem 300) may store one or more keys (e.g., ISD key 156k) and/or other suitable information for creating or otherwise providing one or more credentials (e.g., credentials associated with various credit cards, bank cards, gift cards, access cards, passes, digital currency (e.g., bitcoins and associated payment networks), etc.) on device 100 (e.g., via communication component 106) for credential content management and/or security domain management. Credentials may include credential data (e.g., credential information 161a) that may be assigned to a user/consumer and that may be securely stored onelectronic 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)). NFC memory module 150 may include at least three SSDs 154 (e.g., afirst credential SSD 154a, asecond credential SSD 154b, and anaccess SSD 154 c). For example, each offirst credential SSD 154a andsecond credential SSD 154b may be associated with a respective particular credential that may provide particular privileges or payment rights to electronic device 100 (e.g., a particular credit card credential or a particular public transportation card credential provided by issuer subsystem 300), whileaccess SSD 154c may be associated with a commercial or administrative entity (e.g., an entity ofAE subsystem 400, which may be a controlling entity of device 100) that may control access bydevice 100 to a particular credential of another SSD (e.g.,first SSD 154a orsecond SSD 154b), e.g., to provide particular privileges or payment rights toelectronic device 100. Each SSD 154 may include and/or be associated with at least one applet 153 (e.g.,SSD 154a withapplet 153a andSSD 154b withapplet 153 b). For example, applet 153 of SSD 154 may be an application that is executable on a secure element of NFC component 120 (e.g., in a GlobalPlatform environment). Credential applet 153 may include or be associated with credential information 161 (e.g., information 161a ofapplet 153a and/or information 161b ofapplet 153 b). Each SSD 154 and/or applet 153 may also include and/or be associated with at least one key 155 of its own (e.g., applet 153a having at least one access key 155a and at least onecredential key 155a ', andapplet 153b having at least one access key 155b and at least one credential key 155 b').
The key 155 of the SSD 154 may be a piece of information that may determine the function output of the encryption algorithm or cipher. For example, in encryption, a key may specify a particular transformation of plaintext into ciphertext or vice versa during decryption. Keys such as digital signature schemes and message authentication codes may also be used in other encryption algorithms. The key of the SSD may provide any suitable shared key with another entity. Each key and applet may be loaded by the TSM or authorized agent on the secure element of thedevice 100 or preloaded on the secure element when first provisioned on thedevice 100. As one example, althoughcredential SSD 154a may be associated with a particular credit card credential, the particular credential may be used to transfer host transaction credential data communications from a secure element of device 100 (e.g., from NFC component 120) toSP subsystem 200 for a financial transaction only whenapplet 153a of thatcredential SSD 154a has been enabled or otherwise activated or unlocked for such use.
Security features may be provided to enable use ofNFC component 120, which may be particularly useful when transferring confidential payment information, such as credit card information or bank account information for a credential, fromelectronic device 100 to SP subsystem 200 (e.g., via AE subsystem 400) and/or fromissuer subsystem 300 to electronic device 100 (e.g., via AE subsystem 400). Such security features may also include a secure storage area that may have limited access rights. For example, it may be desirable to provide user authentication via personal identification number ("PIN") entry or via user interaction with a biometric sensor to access the secure storage area. For example,access SSD 154c may utilize applet 153c to determine whether such authentication has occurred before allowing use of other SSDs 154 (e.g.,credential SSD 154a orcredential SSD 154b) to transfer its credential information 161. In certain implementations, some or all of the security features may be stored within NFC memory module 150. Further, secure information, such as an authentication key, may be stored within NFC memory module 150 for communicating commerce credential data withSP subsystem 200. In certain embodiments, NFC memory module 150 may comprise a microcontroller embedded withinelectronic device 100. As just one example, applet153c accessing SSD 154c may be configured to determine intent and local authentication of the user of device 100 (e.g., via one ormore input components 110 such as biometric input components), and in response to such determination, may be configured to enable another particular SSD to conduct a payment transaction (e.g., utilizing a credential ofcredential SSD 154 a).
As shown in fig. 2A, for example,secure element 145 ofNFC component 120 may include or be associated withSSD 154a andSSD 154b, whereSSD 154a may include or be associated withapplet 153a, credential information 161a, access key 155a, and/or credential key 155a ', andSSD 154b may include or be associated withapplet 153b, credential information 161b, access key 155b, and/or credential key 155 b'. In some embodiments, each of SSDs 154a and 154b may be associated with a particular TSM and at least one particular commerce credential (e.g., a particular credit card credential or a particular public transportation card credential), which may provide particular privileges or payment rights to electronic device 100 (e.g.,SSD 154a may be associated with a first host transaction credential provided fromfirst issuing subsystem 391 ofissuer subsystem 300 for first user U1, andSSD 154b may be associated with a second host transaction credential provided from second issuing subsystem 392 ofissuer subsystem 300 for second user U2, as described with respect to fig. 1). Each SSD 154 may have its own manager key 155 (e.g., a respective one of keys 155ak and 155 bk) that may need to be activated to enable the functionality of that SSD 154 for use byNFC device module 130. Each SSD 154 may include and/or be associated with at least one of its own credential application or a credential applet (e.g., a Java card applet instance) associated with a particular commerce credential (e.g.,credential applet 153a ofSSD 154a may be associated with a first commerce credential and/orcredential applet 153b ofSSD 154b may be associated with a second commerce credential), where a credential applet may have its own access key (e.g., access key 155a forcredential applet 153a and/or access key 155b forcredential applet 153b) and/or its own credential key (e.g.,credential key 155a 'forcredential applet 153a and credential key 155b' forcredential applet 153b), and where activation of a credential applet to enable its associated commerce credential may be required, for use by theNFC device module 130 as NFC communications between thedevice 100 and the SP subsystem 200 (e.g., NFC communications with SP terminals) and/or online-based communications (e.g., via the AE subsystem 400).
The credential key for a credential applet may be generated byissuer subsystem 300, which may be responsible for such credentials, and may be accessible by theissuer subsystem 300 to enable secure transfer of the credential information for the applet betweensecure element 145 andissuer subsystem 300. The access key for a credential applet may be generated byAE subsystem 400 and accessible byAE subsystem 400 to enable secure transfer of the credential information for the applet betweensecure element 145 andAE subsystem 400. As shown, each applet may include its own unique application identifier ("AID"), such as AID 155aa ofapplet 153a and/or AID 155ba ofapplet 153 b. For example, an AID may identify a particular card scheme and product, program, or network (e.g., MasterCard Cirrus, Visa PLUS, Interac, etc.), where the AID may include not only a registered application provider identifier ("RID") that may be used to identify a payment system (e.g., card scheme) or network (e.g., MasterCard, Visa, Interac, etc.) for the credential associated with the AID, but also a proprietary application identifier extension ("PIX") that may be used to distinguish between the provider-provided product, program, or application or the payment system for the credential associated with the AID. Any suitable specification (e.g., a Java card specification) that may be used to manage the firmware ofsecure element 145 may be used to ensure or otherwise enforce the uniqueness of each AID on secure element 145 (e.g., each credential instance onsecure element 145 may be associated with its own unique AID).
As shown in fig. 2A,secure element 145 may includeISD 152, whichISD 152 may include ISD key 156k that may also be known by a trusted service manager (e.g.,AE subsystem 400, shown in fig. 1B) associated with the security domain. ISD key 156k may be utilized byAE subsystem 400 anddevice 100 similarly and/or in place of access key 155a and/or access key 155b to enable secure transmissions betweenAE subsystem 400 andsecure element 145. Further, as shown in FIG. 2A, various data may be transferred between theprocessor 102 and thesecure element 145. For example, theprocessor 102 of thedevice 100 may be configured to run adevice application 103 that may communicate information with theapplication 113 of theprocessor 102, as well as thesecure element 145, the 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 thecommunication component 106. Further, as shown, theprocessor 102 may accessdevice identification information 119, which may be used to enable secure communications between thedevice 100 and a remote entity.
As shown in fig. 2A,secure element 145 may include a control authority security domain ("CASD") 158, which may be configured to generate and/or otherwise include aCASD access suite 158k (e.g., a CASD key, certificate, and/or signature module). For example, prior to providing such data to another portion of device 100 (e.g.,communication component 106 for sharing with other subsystems of system 1),CASD 158 may be configured to tag (e.g., usingCASD access suite 158k) particular data onsecure element 145. Secure element 145 may include a contactless registration service ("CRS") applet or application 151 that may be configured to provide local functionality to electronic device 100 to modify lifecycle states (e.g., activate, deactivate, suspend, lock, etc.) of certain security domain elements and to share certain output information 115O about certain security domain elements with a user of device 100 (e.g., via user I/O interface 114a) in certain lifecycle states, and may include a CRS list 151t that may maintain a list of current lifecycle states of each security domain element on secure element 145, and may be configured to share lifecycle states of one or more security domain elements with applications of device 100 (e.g., using any suitable application type, such as a daemon, such as card management daemon ("CMD") application 113a, which may be operating system applications 103 and/or card management applications 113b (e.g., Passbook by Apple incTMOr WalletTMApplication) and/or device protection ("DP") application 113c (e.g., an application and/or daemon associable with device protection subsystem 471 of AE subsystem 400) and/or a first user credential ("U1C") daemon or application 113d for use by first user U1 to communicate with secure element 145 and/or a second user credential ("U2C") daemon or application 113e for use by second user U2 to communicate with secure element 145A background process running), which in turn may provide certain lifecycle state information to a user of device 100 via I/O interface 114a and a user interface ("UI") application as output information 115O (e.g., the UI of card management application 113 b), which may enable the user to change the lifecycle state of the security domain elements. CRS151 may include a CRS access key 151k, which may also be known to a trusted service manager (e.g., AE subsystem 400) associated with CRS151, and may be utilized byAE subsystem 400 anddevice 100 similarly and/or in place of access key 155a and/or access key 155b for enabling secure transmissions betweenAE subsystem 400 andsecure element 145.
DP application 113c may be any suitable application type, such as a daemon process, that may run as a background process withinoperating system application 103 and/orcard management application 113b and/or may be provided by CMD application 113a, or may be an application provided by any suitable entity (e.g., the entity responsible for device protection subsystem 471) and may be used to enable any suitable device protection service or services to be later activated bydevice protection subsystem 471 in order to protectdevice 100 in one or more ways. For example, DP application 113c may be a "find my device" application (e.g., the "find my iPhone" or "find my Mac" application of Apple inc.) that may be used in conjunction with services of device protection subsystem 471 (e.g., the iCloud service of Apple inc.) to track the location ofdevice 100 and/or to remotely control one or more functions ofdevice 100, such as turning on an alarm and/or the usefulness of erasing or pausing or otherwise terminating certain device content, such as the ability to pause a secure element ofdevice 100 to generate transaction credential data for facilitating a transaction with a service provider. Such services may be useful to device owners whendevice 100 may be lost or stolen, so that the device may be recovered and/or so that sensitive data on the device may not be accessed. Each ofU1C application 113d andU2C application 113e may be any suitable application type, such as a daemon process, that may run as a background process withinoperating system application 103 and/orcard management application 113b and/or may be provided by CMD application 113a, or may be an application provided by any suitable entity (e.g., the entity responsible for credential protection subsystem 491) and may be used to enable a particular user ofdevice 100 to provide user transaction credentials ondevice 100 and/or otherwise manage one or more credentials of the user ondevice 100.
As shown in FIG. 3, one specific example of hostelectronic device 100 may be a handheld electronic device such as an iPhoneTMWherein thehousing 101 may allow access tovarious input components 110a-110I,various output components 112a-112c, and various I/O components 114a-114d through which thedevice 100 and a user and/or the surrounding environment may be connected to one another. For example, touch screen I/O component 114a can include adisplay output component 112a and an associated touch input component 110f, wheredisplay output component 112a can be used to display a visual user interface or graphical user interface ("GUI") 180 that can allow a user to interact withelectronic device 100.GUI 180 may include various layers, windows, screens, templates, elements, menus, and/or other components of the currently running application (e.g.,application 103 and/orapplication 113 and/or application 143), which may be displayed in all or some area ofdisplay output component 112 a. For example, as shown in fig. 3,GUI 180 may be configured to display afirst screen 190 having one or more graphical elements oricons 182 ofGUI 180. When aparticular icon 182 is selected,device 100 may be configured to open a new application associated with thaticon 182 and display a corresponding screen ofGUI 180 associated with that application. For example, upon selection by a user ofdevice 100 of aparticular icon 182 labeled "merchant application" text indicator 181 (i.e., a particular icon 183),device 100 may launch or otherwise access a particular third party merchant or SP application and may display a screen of a particular user interface that may include one or more tools or features for interacting withdevice 100 in a particular manner. As another example, when aparticular icon 182 labeled with a "wallet" text indicator 181 (i.e., a particular icon 185) is selected,device 100 may launch or otherwise access a particular device application (e.g., an instance)As such,card management application 113b of fig. 2A for managing various credentials on secure element 145 (e.g., as a "wallet" or "card voucher" application)), and may display screens of a particular user interface that may include one or more tools or features for interacting withdevice 100 in a particular manner. As another example, when aparticular icon 182 labeled "protect" text indicator 181 (i.e., particular icon 186) is selected,device 100 may launch or otherwise access a particular device application (e.g., device protection application 113c of fig. 2A (e.g., a "find my devices" application)) to enable certain device protection services to be activated (e.g., by device protection subsystem 471) to protect device 100 (e.g., if lost, stolen, etc.). For each application, a screen may be displayed on thedisplay output component 112a and may include various user interface elements. For each application, various other types of non-visual information may be provided to the user via variousother output components 112 ofdevice 100. In some embodiments,device 100 may not include user interface components for providing a GUI, but instead may be considered a more automated device.Device 100 may not include user interface components for providing a GUI, but instead may provide audible and/or tactile output components and mechanical or other suitable user input components to select and authenticate use of payment credentials to fund a transaction.
TheSP subsystem 200 may include any suitable service provider ("SP") server (not shown), which may include a server configured to communicate via any suitable communication protocol (e.g., Wi-Fi, Bluetooth)TMCellular, wired network protocol, etc.) and the communications component of theAE subsystem 400 and/or thecommunications component 106 of thedevice 100. For example, the SP server may be used to communicate potential transaction data withhost device 100 in any suitable online context, such as when a user ofdevice 100 communicates with the SP server to conduct a transaction via any suitable SP online resource that may be running ondevice 100, such as a third party SP application running ondevice 100 that may be managed by the SP server or an internet application running on device 100Programs (e.g., Safari by Apple Inc.)TM) The internet application may point to a uniform resource locator ("URL") whose target or network resource may be managed by the SP server. Thus, it is noted that communication between the SP server and thedevice 100 may occur wirelessly and/or via a wired path (e.g., through the internet). Such SP servers may be provided by a merchant or any other controlling entity of SP subsystem 200 (e.g., as web servers to host website data and/or manage third party application data). Additionally or alternatively,SP subsystem 200 may include any suitable SP terminal (e.g., a merchant payment terminal), which may include any suitable component or subsystem configured to communicate any suitable data with the proximity-based contactless communication component of host device 100 (e.g., proximity-based contactless communication withNFC component 120 of device 100).SP subsystem 200 may include one or more SP keys associated withSP subsystem 200 and/or any suitable service provider identification ("SPID") information that may be utilized bydevice 100 and/orAE subsystem 400 and/orSP subsystem 200 and/orissuer subsystem 300 to uniquely identifySP subsystem 200 to facilitate a transaction and/or enable any suitable secure communication. As just one example, such SPID information may be a telephone number or an email address or an IP address or any unique identifier that may be associated withSP subsystem 200. Although not shown,SP subsystem 200 may also include an SP processor component, which may be the same as or similar toprocessor component 102 ofelectronic device 100, an SP communications component, which may be the same as or similar tocommunications component 106 of electronic device 100 (e.g., as part of an SP server), an SPI/O interface, which may be the same as or similar to I/O interface 114 ofelectronic device 100, an SP bus, which may be the same as or similar tobus 118 ofelectronic device 100, an SP memory component, which may be the same as or similar tomemory component 104 ofelectronic device 100, and/or an SP power component, which may be the same as or similar topower component 108 ofelectronic device 100.
Theissuer subsystem 300 may include at least one issuing subsystem (e.g., an issuing bank subsystem), such as afirst issuing subsystem 391 and a second issuing subsystem 392. Additionally, in some embodiments, theissuer subsystem 300 may include at least one network subsystem (e.g., a payment card association or a credit card association)), such as a first network subsystem and a second network subsystem. For example, each issuing subsystem may be a financial institution that may assume primary liability for a consumer's ability to clear out debts that they may generate using a particular credential. One or more particular credential applets ofhost 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 value cards, gasoline offer cards, gift cards, and the like. Commerce credentials of a particular payment card (e.g., credentials that are a credential supplemental security domain ("SSD") ofNFC component 120, as described below) may be provisioned onhost device 100 by an issuing subsystem of issuingsubsystem 300 for use in commerce credential data communications (e.g., proximity-based contactless communications and/or online-based communications) with SP subsystem 200 (e.g., directly or via AE subsystem 400). Each credential may be a particular brand of payment card that may be branded by the network subsystem of theissuer subsystem 300. Each network subsystem of theissuer subsystem 300 may be a network of the respective issuing subsystem and/or the respective acquiring bank of theissuer subsystem 300 that may handle the use of a particular brand of payment card (e.g., commerce credential). An acquiring bank subsystem, also known as a payment processor or acquiring institution, may be a banking partner of an SP associated withSP subsystem 200, and may be configured to work withissuer subsystem 300 to approve and resolve credential transactions attempted to be funded byhost device 100 through host transaction credential data (e.g., via SP subsystem 200). The network subsystem and the issuing subsystem of theissuer subsystem 300 may be a single entity or may be separate entities. For example, American Express may be both a network subsystem and an issuing subsystem, whereas Visa and MasterCard, in contrast, may be payment subsystems and may cooperate with issuing subsystems, such as Citibank, Wells Fargo, Bank of America, and the like.
In order to conduct a financial transaction within system 1 (e.g., a particular type of many suitable types of transactions thatsystem 1 may conduct betweenhost device 100 andSP subsystem 200 in accordance with the concepts disclosed herein), at least one transaction credential must be securely provisioned on a secure element ofhost device 100. For example, such transaction credentials may be provided at least partially onsecure element 145 ofhost device 100, either directly fromissuer subsystem 300 or via AE subsystem 400 (e.g., via credential protection subsystem 491). For example, first user credential data (e.g.,data 656 of fig. 6) may be provided fromfirst issuing subsystem 391 onsecure element 145 ofdevice 100 for first user U1, as at least a portion or all of a credential supplemental security domain ofNFC component 120, and may include a credential applet having credential information and/or a credential key, such as payment application orcredential applet 153a having credential information 161a and credential key 155a', and second user credential data (e.g.,data 664 of fig. 6) may be provided from the second issuing subsystem 392 on thesecure element 145 of thedevice 100 for the second user U2, as at least a portion or all of the credential supplemental security domain of theNFC component 120, and may include a credential applet having credential information and/or a credential key, such as a payment application orcredential applet 153b having credential information 161b and credential key 155 b'. Issuer subsystem 300 (e.g., first issuing subsystem 391) may also have access to credential key 155a '(e.g., for decrypting data encrypted bydevice 100 usingcredential key 155 a'), and issuer subsystem 300 (e.g., second issuing subsystem 392) may also have access to credential key 155b '(e.g., for decrypting data encrypted bydevice 100 using credential key 155 b').Issuer subsystem 300 may be responsible for managingcredential keys 155a 'through 155b', which may include the generation, exchange, storage, use, and replacement of such keys. Theissuer subsystem 300 may store each credential key of its version in one or more appropriate secure elements of theissuer subsystem 300. It should be appreciated that each ofcredential keys 155a 'and 155b' ofNFC component 120 andissuer subsystem 300 may be any suitable shared key (e.g., a password, a passphrase, a randomly selected array of bytes, one or more symmetric keys, a public-private key (e.g., an asymmetric key), etc.) that may be used to enable any suitable encrypted data (e.g., ciphertext) or any other suitable data to be independently generated byelectronic device 100 and issuer subsystem 300 (e.g., payment data for validating a financial transaction), such as by using any suitable encryption algorithm or password, whose functional output may be at least partially determined by the shared key, where such shared key may be provided byissuer subsystem 300 ondevice 100, andissuer subsystem 300. The shared key may be shared in advance between theissuer subsystem 300 and the host device 100 (e.g., during provisioning of credentials on thedevice 100 by the issuer subsystem 300), in which case such shared key may be referred to as a pre-shared key, or the shared key may be created using a key agreement protocol before use in a particular financial transaction (e.g., using a public key encryption protocol such as Diffie-Hellman, or using a symmetric key encryption protocol such as Kerberos). The shared key and the functional output may be accessible to a secure element ofdevice 100 by any suitable encryption algorithm or cipher that is determined, at least in part, by the shared key.
AE subsystem 400 (e.g., credential protection subsystem 491) may be provided as an intermediary betweenissuer subsystem 300 andhost device 100, whereAE subsystem 400 may be configured to provide a new layer of security and/or provide a more seamless user experience when credentials are provisioned ondevice 100 and/or when such provisioned credentials are used as part of a host transaction credential data communication betweendevice 100 andSP subsystem 200. TheAE subsystem 400 may be provided to a user-specific account with a managing entity by any suitable managing and/or business entity that may provide various services to a user of thedevice 100 via user-specific login information (e.g., via a user-specific identification and password combination). As just one example,AE subsystem 400 may be provided by Apple inc. (Cupertino, CA), which may also be a provider that provides various administrative and/or other services to a user of device 100 (e.g., iTunes for selling/leasing media to be played by device 100)TMShop, for sale/leaseApple App Store for applications used on device 100TM(e.g., store 420 for securely delivering applications to device 100), Apple iCloud for storing data from device 100 and/or associating a user with a device and/or providing device protection services (e.g., using DP application 113c on device 100)TMServices (e.g., of device protection subsystem 471), Apple online stores for online purchasing of various Apple products, Apple iMessage for communicating media messages between devicesTMService, Apple Pay for securing and managing credential provisioning on device 100 and/or securely using host device credential data to facilitate transactions with service providersTMA service (e.g., of credential protection subsystem 491), etc.), and it may also be the provider, manufacturer, and/or developer of device 100 itself and/or device 100' itself (e.g., when device 100 is an iPod)TM、iPadTM、iPhoneTM、MacBookTM、iMacTM、Apple WatchTMEtc.) and/or the provider, manufacturer, and/or developer of the operating system of device 100 (e.g., device application 103) or any other application (e.g., card management application 113b and/or DP application 113 c). A management or business entity (e.g., Apple Inc.) that may provideAE subsystem 400 may be distinct and independent from any credential issuing and/or financial entity ofissuer subsystem 300. For example, a management or business entity that may provideAE subsystem 400 may be distinct and/or independent from any payment network subsystem or issuing bank subsystem, which may provide and/or manage any credit cards or any other transaction credentials to be provisioned on end-user host device 100. The entity that may provide AE subsystem 400 (e.g., Apple Inc.) may be distinct and independent from any merchant of SP subsystem 200 (e.g., any SP entity ofSP subsystem 200 that may provide an SP terminal for NFC communications, a third party application for online communications, and/or any other aspect of SP subsystem 200). Such a management entity may utilize its potential capabilities to configure or control various components of device 100 (e.g., software components and/or hardware components ofdevice 100, such as when the entity may at least partially generate or manage a deviceWhen provisioned 100) to provide a more seamless user experience for the user ofdevice 100 when it wishes to provision credentials provisioned byissuer subsystem 300 onhost device 100 and/or when such provisioned credentials are used as part of a host transaction credential data communication withSP subsystem 200 to fund a transaction and/or whendevice 100 may have any device protection services enabled (e.g., via DP application 113c) to facilitate any suitable device protection services bydevice protection subsystem 471. For example, in some embodiments,device 100 may be configured to communicate seamlessly withAE subsystem 400 and transparently to a user ofdevice 100 for sharing and/or receiving certain data that may enable a higher level of security (e.g., during online-based host transaction credential data communication betweendevice 100 andSP subsystem 200 and/or whendevice 100 has been reported as lost or stolen). Although not shown,AE subsystem 400 may also include or access processor components, communication components, I/O interfaces, buses, memory components, and/or power components, which may be the same as or similar to such components ofdevice 100, one, some, or all of which may be provided, at least in part, by one, some, or each ofdevice protection subsystem 471 andcredential protection subsystem 491 ofAE subsystem 400.
In addition to providing at least one transaction credential on host device 100 (e.g., a first user credential that is part offirst credential SSD 154a and has credential key 155a 'and credential information 161a and/or a second user credential that is part ofsecond credential SSD 154b and has credential key 155b' and credential information 161b), at least oneaccess SSD 154c having access key 155c may also be provided ondevice 100 in order to more securely enabledevice 100 to conduct financial or other secure transactions withSP subsystem 200. For example, access data may be provided ondevice 100 directly fromAE subsystem 400 as at least part ofaccess SSD 154c, and may include access applet 153c with access key 155 c. AE subsystem 400 (e.g., credential protection subsystem 491) may also access key 155c (e.g., for decrypting data encrypted bydevice 100 usingaccess key 155 c).AE subsystem 400 may be responsible for managing access key 155c, which may include the generation, exchange, storage, use, and replacement of such keys. TheAE subsystem 400 may store its version of the access key 155c in a secure element of theAE subsystem 400.Access SSD 154c with access key 155c may be configured to determine the intent and local authentication of the user of device 100 (e.g., via one ormore input components 110 ofdevice 100, such as biometric input components), and in response to such determination, may be configured to enable another particular SSD to conduct a payment transaction (e.g., with the user credentials ofcredential SSD 154a orSSD 154 b). By storing such an access SSD within thesecure element 145 of thedevice 100, its ability to reliably determine user intent and authentication for secure data transactions may be improved. Further, access key 155c may be utilized to provide enhanced encryption of any transaction credential data that may be transmitted outside of the secure element ofdevice 100. The access data may include an issuer security domain ("ISD") key 156k ofISD 152 ofsecure element 145, which may also be maintained byAE subsystem 400, and may be used in addition to or instead of access key 155c (or one or more other ofaccess keys 155a, 155b, 151k, and 158 k).
Description of FIG. 4
Fig. 4 shows further details of various embodiments of theAE subsystem 400 relative to thesystem 1. As shown in fig. 4,AE subsystem 400 may be a secure platform system and may includeserver 410, online store 420, secure mobile platform ("SMP")agent component 440, SMP trusted service manager ("TSM")component 450, SMPcrypto service component 460, identity management system ("IDMS")component 470,rogue system component 480, and/or hardware security module ("HSM")component 490. In some embodiments, one or more components of theAE subsystem 400 may be combined or omitted. Further, theAE subsystem 400 may include other components not incorporated or included in fig. 4. For example, theAE subsystem 400 may include any other suitable components or several instances of the components shown in fig. 4. For simplicity, only one of each component is shown in FIG. 4. One, some, or all of the components of theAE subsystem 400 may be implemented using one or more processor components, which may be the same as or similar to theprocessor component 102 of thedevice 100, one or more memory components, which may be the same as or similar to thememory component 104 of thedevice 100, and/or one or more communication components, which may be the same as or similar to thecommunication component 106 of thedevice 100. One, some, or all of the components ofAE subsystem 400 may be managed by, owned by, at least partially controlled by, and/or otherwise provided by a single management or business entity (e.g., Apple Inc.) that may be distinct and independent fromissuer subsystem 300. The components of theAE subsystem 400 may interact with each other and, together, with theissuer subsystem 300 and/or the hostelectronic device 100 and/or theSP subsystem 200 to provide a new layer of security and/or to provide a more seamless user experience. In some embodiments,device protection subsystem 471 andcredential protection subsystem 491 may each include their own processing components, memory components, communication components, store 420,SMP broker component 440,SMP TSM component 450, SMPcrypto services component 460,IDMS component 470,fraud system component 480, and/orHSM component 490.
SMP broker component 440 ofAE subsystem 400 may be configured to manage user authentication with administrative or business entity user accounts.SMP broker component 440 may also be configured to manage the lifecycle and provisioning of credentials ondevice 100.SMP broker component 440 may be the primary endpoint that may control user interface elements (e.g., elements of GUI 180) ondevice 100. The operating system or other applications of the end-user device (e.g.,application 103, one ormore applications 113, and/orapplication 143 of host device 100) may be configured to invoke specific application programming interfaces ("APIs"), andSMP proxy 440 may be configured to process requests for those APIs and respond with data that may be exported from the user interface ofdevice 100 and/or respond with application protocol data units ("APDUs") that may communicate withsecure element 145 ofdevice 100. Such APDUs may be received by theAE subsystem 400 from theissuer subsystem 300 via a TSM of the system 1 (e.g., a TSM of a communication path between theAE subsystem 400 and the issuer subsystem 300). TheSMP TSM component 450 of theAE subsystem 400 may be configured to provide GlobalPlatform-based services or any other suitable services that may be used to perform credential provisioning operations on thedevice 100 from theissuer subsystem 300. GlobalPlatform or any other suitable secure channel protocol may enable theSMP TSM component 450 to properly communicate and/or provide sensitive account data between thesecure element 145 and the TSM of thedevice 100 for secure data communication between theAE subsystem 400 and theissuer subsystem 300.
SMP TSM component 450 may be configured to useHSM component 490 to protect its keys and generate new keys. The SMPcrypto services component 460 of theAE subsystem 400 may be configured to provide key management and cryptographic operations that may provide for user authentication and/or secure data transfer between components of thesystem 1. SMPcrypto services component 460 may utilizeHSM component 490 for secure key storage and/or opaque cryptographic operations. A payment crypto service of SMPcrypto service component 460 may be configured to interact withIDMS component 470 to retrieve information associated with an on-file credit card or other type of commerce credential associated with a user account of a management entity.IDMS component 470 may be configured to enable and/or manage any suitable communication betweenhost device 100 and one or more other devices, such as identity service ("IDS") transport (e.g., using management-entity-specific (or other entity-specific) services (e.g., iMessage by Apple incTM)). For example, certain devices may automatically or manually register for such a service (e.g., all devices in the ecosystem of theAE subsystem 400 may automatically register for the service). Such services may provide an end-to-end encryption mechanism that may require active registration before sending messages using the service.IDMS component 470 and/or any other suitable server or portion ofAE subsystem 400 may be used to identify or otherwise look up the status of any credentials provisioned on any electronic device associated with a given user account or the like, such thatAE subsystem 400 may be used to efficiently and effectively identify one or more payment credentials that may be used in connection with a particular user accountA particular device of the contact (e.g., multiple host devices of the home account with the AE subsystem 400).Fraud system component 480 ofAE subsystem 400 may be configured to conduct a management entity fraud check on a transaction credential based on data known to the management entity about the transaction credential and/or the user (e.g., based on data associated with the user account with the management entity (e.g., transaction credential information) and/or any other suitable data that may be under the control of the management entity and/or any other suitable data that may not be under the control of issuer subsystem 300). Thefraud system component 480 may be configured to determine a management entity fraud score for a credential based on various factors or thresholds.AE subsystem 400 may include a store 420, which may also be a provider of various services to a user of device 100 (e.g., iTunes for selling/leasing media to be played by device 100)TMStore, Apple App Store for selling/leasing applications for use ondevice 100TMEtc.). As just one example, store 420 may be configured to manageapplication 113 and provide the application todevice 100, whereapplication 113 may be any suitable application, such as a banking application, an SP application, an email application, a text messaging application, an internet application, a card management application, a device protection application, or any other suitable communication application. Theserver 410 may be used to store and/or process any suitable data. For example, the server ofdevice protection subsystem 471 may access and process any suitable data of table ordata structure 473, while the server ofcredential protection subsystem 491 may access and process any suitable data of table ordata structure 493. Thecommunication settings 495 of theAE subsystem 400 may use any suitable communication protocol or combination of communication protocols to communicate data between the various components of theAE subsystem 400 and/or between theAE subsystem 400 and other components of thesystem 1, such as theissuer subsystem 300 and/or thehost device 100 and/or the SP subsystem 200 (e.g., via the communication settings 9).
Description of FIG. 5
Fig. 5 is a flow diagram of anexemplary process 500 for managing a plurality of credentials on an electronic device using a management entity subsystem that includes a device protection server and a credential protection server, where the electronic device is associated with a device identifier and is used by a first user associated with a first user identifier and a second user associated with a second user identifier (e.g., usingAE subsystem 400 that includesdevice protection subsystem 471 and credential protection subsystem 491). Atoperation 502, when the first user authenticates the provision of a first credential of the plurality of credentials on the electronic device, the credential protection server may be operative to store, at the credential protection server, a first pause token for the device identifier and for the first user identifier and for a first credential identifier of the first credential, and to provide the first credential and the first pause token on the electronic device (e.g., as described with respect to fig. 6, thecredential protection subsystem 491 may store a first pause token ST-1 for the device identifier ED-ID and for the first user identifier U1-ID and for the first credential identifier C1-ID, and may provide first user credential data 658 including the first pause token ST-1 on the device 100). Atoperation 504, when the second user authenticates the provision of a second credential of the plurality of credentials on the electronic device, the credential protection server may be operative to store, at the credential protection server, a second pause token for the device identifier and for the second user identifier and for a second credential identifier of the second credential, and to provide the second credential and the second pause token on the electronic device (e.g., as described with respect to fig. 6, thecredential protection subsystem 491 may store a second pause token ST-2 for the device identifier ED-ID and for the second user identifier U2-ID and for the second credential identifier C2-ID, and may provide seconduser credential data 664 including the second pause token ST-2 on the device 100). Atoperation 506, when the second user enables the protection service of the electronic device on the electronic device, the device protection server may be operable to store the first and second pause tokens for the device identifier and for the second user identifier at the device protection server (e.g., thedevice protection subsystem 471 may store the first and second pause tokens ST-1 and ST-2 for the device identifier ED-ID and for the second user identifier U2-ID, as described with respect to fig. 6). Atoperation 508, when a protection mode is activated for a protection service of the electronic device enabled by the second user, the device protection server may be operable to authenticate the second user using the second user identifier and identify each of the first suspend token and the second suspend token as stored at the device protection server for the second user identifier, and share each of the identified first pause token and the identified second pause token with the credential protection server (e.g., as described with respect to fig. 6,device protection subsystem 471 may use second user identifier U2-ID to authenticate second user U2, identify ST-1 and ST-2 as stored for ED-ID and U2-ID, and share ST-1 and ST-2 with credential protection server 491). Atoperation 510, when the device protection server shares each of the identified first pause token and the identified second pause token with the credential protection server, the credential protection server may be used to pause each credential of the plurality of credentials stored at the credential protection server for the identified first pause token and to pause each credential of the plurality of credentials stored at the credential protection server for the identified second pause token (e.g., as described with respect to fig. 6,credential protection subsystem 491 may pause each credential stored for ST-1 and pause each credential stored for ST-2). Atoperation 512, when the second user authenticates the second user on the electronic device using the second user identifier while pausing the second credential, the credential protection server may be used to authenticate the second user using the second user identifier from the electronic device and un-pause each credential of the plurality of credentials having a credential identifier stored at the credential protection server for the second user identifier (e.g., thecredential protection subsystem 491 may authenticate the second user U2 using the second user identifier U2-ID and un-pause each credential having a credential identifier stored for the U2-ID as described with respect to fig. 6).
It should be understood that the operations shown inprocess 500 of fig. 5 are merely illustrative, and that existing operations may be modified or omitted, additional operations may be added, and the order of certain operations may be changed. Further, in some implementations, two or more operations may occur in parallel or in a different order than that described.
Description of FIG. 6
Fig. 6 is a flow diagram of anexemplary process 600 for managing credentials for multiple users on an electronic device.Process 600 is shown as being implemented byhost device 100 andAE subsystem 400. However, it should be understood thatprocess 600 may be implemented using any other suitable components or subsystems.Process 600 may provide a seamless user experience for securely and efficiently managing credentials of multiple users onelectronic device 100 usingdevice protection subsystem 471 andcredential protection subsystem 491 ofAE subsystem 400, while limiting the possibility of privacy and/or security breaches by preventingdevice protection subsystem 471 from storing information atdevice protection subsystem 471, which may specifically link two or more particular users todevice 100. To facilitate the following discussion regarding the operation of thesystem 1 for managing credentials of multiple users on an electronic device according to theprocess 600 of fig. 6, reference is made to the components of thesystem 1 of the schematic diagrams of fig. 1-4 and the contents of thedata structures 473 and 493 of fig. 4A and 4B.
Atoperation 602, the device 100 (e.g., theU1C application 113d) may send first usercredential request data 652 to thecredential protection subsystem 491, which may be used to request provisioning of one or more first user transaction credentials on thedevice 100 for the first user U1. For example,operation 602 may be at least partially undertaken when first user U1 ofdevice 100 selects a particular first user transaction credential of credential issuer subsystem 300 (e.g., of first issuing subsystem 391) to be provisioned on device 100 (e.g., by interacting withdevice 100 in any suitable manner). The first usercredential request data 652 may include any suitable identification of the first user transaction credential to be provisioned (e.g., at least a portion of a primary account number ("PAN"), a PAN expiration date, a CVV, etc.), may be a first user identifier U1-ID that may uniquely identify any suitable data of the first user U1 for theAE subsystem 400 and/or any suitable first user password data U1-PW associated therewith (e.g., user-specific login information provided to a user-specific account with the managing entity (e.g., via a user-specific identification and password combination), may be an electronic device identifier ED-ID (e.g.,device ID 119, etc.) that may uniquely identify any suitable data of theelectronic device 100 for theAE subsystem 400, and so forth.
Atoperation 604,credential protection subsystem 491, e.g., in conjunction withcredential issuer subsystem 300, may be operative to process first usercredential request data 652 to obtain credential information fromcredential issuer subsystem 300 that is provided ondevice 100 of first user U1 based on first user credential request data 652 (e.g., based on an identification of a first user transaction credential) to determine (e.g., generate and/or obtain) a first user transaction credential identifier C1-ID that may uniquely identify the first user transaction credential forAE subsystem 400, to access (e.g., generate and/or obtain) a first suspension token ST-1 unique toAE subsystem 400, and then to access (e.g., generate and/or obtain) a first suspension token ST-1 unique toAE subsystem 400 in any suitable memory component ofcredential protection subsystem 491, such as in a firstlink data entry 493a of table 493 of fig. 1 and 4B, for first user credential identifier C1-ID and/or electronic device identifier ED-ID and/or @ Or the first user identifier U1-ID and/or the first user password data U1-PW, stores the first pause token ST-1 (e.g., by linking such data with any suitable data link or links). Such unique first pause token ST-1 may be any suitable data element of any suitable size, such as an 8-character or 9-character alphanumeric string, which may be randomly or uniquely generated byAE subsystem 400, or otherwise used in association with any suitable data indicative of the first user U1 and/or each first user transaction credential ofdevice 100, such that the first pause token ST-1 may not be associated with another user of device 100 (e.g., with second user U2).
Atoperation 606, the first pause token ST-1 may be transmitted to device 100 (e.g., toU1C application 113d) using credential information fromcredential issuer subsystem 300 for provisioning ondevice 100 as firstuser credential data 656. For example, at least credential information of such firstuser credential data 656 may be provided, at least in part, onsecure element 145 ofdevice 100, either directly from credential issuer subsystem 300 (not shown in fig. 6) or viacredential protection subsystem 491 along with first pause token ST-1. As mentioned, such first user transaction credential information of firstuser credential data 656 may be provided as at least a portion or all offirst credential SSD 154a onsecure element 145 ofdevice 100, and may includecredential applet 153a having credential information 161a and/or credential key 155a' and/or key 155 ak. Firstuser credential data 656 may also include access key 155a, which may be initially provided fromAE subsystem 400 toissuer subsystem 300 and/or may be added byAE subsystem 400. In some embodiments, such first user transaction credential information of firstuser credential data 656 may include a primary account number (e.g., credential information 161a ofapplet 153 a), an AID (e.g., AID 155aa of applet 153a of data of a payment credential provisioned atSSD 154 a), an SSD identifier, and/or an SSD counter as at least a portion of credential information of a provisioned payment credential. Atoperation 608, in response to receiving firstuser credential data 656 having a first pause token ST-1, device 100 (e.g.,U1C application 113d) may register the first pause token ST-1 with DP application 113c as at least a portion of first pause token data 658. The first pause token ST-1 of the first pause token data 658 may be stored in any suitable register or data structure available to the DP application 113c (e.g., in any suitable portion of thememory 104 of the device 100 (e.g., using the keychain of Apple inc.).
Later, after the first user U1 may have interacted with device 100 (e.g., at operation 602) to provide at least one first user transaction credential ondevice 100, the second user U2 may log intodevice 100 as an active user. Then, atoperation 610, the device 100 (e.g., theU2C application 113e) may send second usercredential request data 660 to thecredential protection subsystem 491, which may be used to request provisioning of one or more second user transaction credentials on thedevice 100 for the second user U2. For example,operation 610 may occur, at least in part, when second user U2 ofdevice 100 selects a particular second user transaction credential (e.g., offirst issuing subsystem 391 or of second issuing subsystem 392) ofcredential issuer subsystem 300 to be provisioned on device 100 (e.g., by interacting withdevice 100 in any suitable manner). The second usercredential request data 660 may include any suitable identification of the second user transaction credential to be provisioned (e.g., at least a portion of a primary account number ("PAN"), a PAN expiration date, a CVV, etc.), may be a second user identifier U2-ID that may uniquely identify any suitable data of the second user U2 for theAE subsystem 400 and/or any suitable second user password data U2-PW associated therewith (e.g., user-specific login information provided to a user-specific account with the managing entity (e.g., via a user-specific identification and password combination), may be an electronic device identifier ED-ID (e.g.,device ID 119, etc.) that may uniquely identify any suitable data of theelectronic device 100 for theAE subsystem 400, and so forth.
At operation 612,credential protection subsystem 491, e.g., in conjunction withcredential issuer subsystem 300, may be used to process second usercredential request data 660 to obtain credential information fromcredential issuer subsystem 300 that is provided ondevice 100 of second user U2 based on second user credential request data 660 (e.g., based on identification of the second user transaction credential) to determine (e.g., generate and/or obtain) a second user transaction credential identifier C2-ID that may uniquely identify the second user transaction credential forAE subsystem 400, to access (e.g., generate and/or obtain) a second pause token ST-2 unique toAE subsystem 400, and then in any suitable memory component ofcredential protection subsystem 491, such as in a second link data entry 493B of table 493 of fig. 1 and 4B, for second user credential identifier C2-ID and/or electronic device identifier ED-ID and/or certificate Or the second user identifier U2-ID and/or the second user password data U2-PW, stores the second pause token ST-2 (e.g., by linking such data with any suitable data link or links). Such unique second pause token ST-2 may be any suitable data element of any suitable size, such as an 8-character or 9-character alphanumeric string, which may be randomly or uniquely generated byAE subsystem 400, or otherwise used in association with any suitable data indicative of second user U2 and/or each second user's transaction credentials ofdevice 100, such that second pause token ST-2 may not be associated with another user of device 100 (e.g., with first user U1).
Atoperation 614, the second pause token ST-2 may be transmitted to device 100 (e.g., toU2C application 113e) using credential information from thecredential issuer subsystem 300 for provision ondevice 100 as seconduser credential data 664. For example, at least credential information of such seconduser credential data 664 may be provided, at least in part, onsecure element 145 ofdevice 100, either directly from credential issuer subsystem 300 (not shown in fig. 6) or viacredential protection subsystem 491 along with a second suspend token ST-2. As mentioned, such second user transaction credential information of seconduser credential data 664 may be provided as at least a portion or all ofsecond credential SSD 154b onsecure element 145 ofdevice 100, and may includecredential applet 153b with credential information 161b and/or credential key 155b' and/or key 155 bk. The seconduser credential data 664 may also include an access key 155b that may be initially provided from theAE subsystem 400 to theissuer subsystem 300 and/or may be added by theAE subsystem 400. In some embodiments, such second user transaction credential information of seconduser credential data 664 may include a primary account number (e.g., credential information 161b ofapplet 153b), an AID (e.g., AID 155ba ofapplet 153b of data of a payment credential provisioned atSSD 154b), an SSD identifier, and/or an SSD counter as at least a portion of credential information of a provisioned payment credential. Atoperation 616, in response to receiving seconduser credential data 664 having a second pause token ST-2, device 100 (e.g.,U2C application 113e) may register the second pause token ST-2 with DP application 113c as at least a portion of second pause token data 666. The second pause token ST-2 of the second pause token data 66 may be stored in any suitable register or data structure available to the DP application 113c (e.g., in any suitable portion of thememory 104 of the device 100 (e.g., using the keychain of Apple inc.).
At any suitable time duringprocess 600 before a user ofdevice 100 may activate operation 626 of one or more device protection services ofdevice 100 atdevice protection subsystem 471, any suitable user ofdevice 100 may enable the one or more device protection services ofdevice 100 using DP application 113c ondevice 100. For example, as shown in FIG. 6, the second user U2, when logged into thedevice 100, may be used to interact with thedevice 100 in any suitable manner to enable one or more device protection services of the DP application 113c at operation 618. For example, at operation 618, second user U2 may interact with DP application 113c to enable a "find my device" option facilitated by DP application 113c, which may then configure DP application 113c to enabledevice protection subsystem 471 to remotely instruct DP application 113c to activate one or more device protection services ondevice 100, such as turning on an alarm and/or erasing or pausing or otherwise terminating the usefulness of certain device content (e.g., as described with respect tooperations 634 and 636). When a particular user has interacted withdevice 100 to enable one or more device protection services of DP application 113c (e.g., at operation 618), DP application 113c may be operable to sharedevice pause data 670 withdevice protection subsystem 471 atoperation 620 indicating any pause tokens that DP application 113c has registered withdevice 100. For example, in some embodiments, thedevice pause data 670 may include a first pause token ST-1, a second pause token ST-2, an electronic device identifier ED-ID, and an identification of a second user U2, such as a second user identifier U2-ID and/or second user password data U2-PW, that has enabled one or more device protection services of the DP application 113 c. Alternatively, if the second user U2 enables one or more device protection services of the DP application 113c prior to providing the pause token on thedevice 100 and registering at the DP application 113c (e.g., if operation 618 were to occur prior tooperation 602 and 616), the DP application 113c may be configured to communicate appropriate device pause data to thedevice protection subsystem 471 each time the pause token is registered at the DP application 113c (e.g., device pause data, device identifier ED-ID, and identification of the user that enabled the device protection services, which may include each pause token registered at the DP application 113 c).
Continuing with the example of fig. 6, when DP application 113c sharesdevice pause data 670 withdevice protection subsystem 471 atoperation 620, where the data indicates first pause token ST-1, second pause token ST-2, electronic device identifier ED-ID, and an identification of second user U2, such as second user identifier U2-ID and/or second user password data U2-PW, that has enabled one or more device protection services of DP application 113c,device protection subsystem 471 may be used to process suchdevice pause data 670 and register at least a portion of the device pause data atdevice protection subsystem 471 at operation 622. For example, at operation 622, the device protection subsystem 471 may be used to verify any suitable information associated with the user of the one or more device protection services of the DP-enabled application 113c, such as by verifying or otherwise authenticating the second user identifier U2-ID and the second user password data U2-PW of the device pause data 670, particularly by comparing such data with user-specific account information already available to the AE subsystem 400, and if the user U2 may be authenticated, the device protection subsystem 471 may be used to verify, in any suitable memory component of the device protection subsystem 471, such as in the second link data entry 473b of the table 473 of fig. 1 and 4A, the user password data U2-PW and/or the electronic device identifier ED-ID and/or the second user identifier U2-ID and/or the second user password data U2-PW (e.g., by linking such data with any suitable data link (s)) each pause token (e.g., first pause token ST-1 and second pause token ST-2) of storage device pause data 670 (e.g., where the first link data entry 473a of table 473 may include at least user-specific account information already available to AE subsystem 400 for the first user U1 (e.g., information usable to authenticate the first user U1 in the event that the first user U1 is a user that has enabled one or more device protection services of DP application 113 c). Then, oncedevice pause data 670 has been processed and stored for the identification of the user (e.g., second user U2) who has recently enabled the one or more device protection services of DP application 113c at operation 622,device protection subsystem 471 may be operable to generate and transmit any suitable pausestorage confirmation data 674 to device 100 (e.g., to DP application 113c) atoperation 624,operation 624 may confirm todevice 100 that each pause token ofdevice 100 has been properly registered withdevice protection subsystem 471 for the user(s) who have recently enabled the one or more device protection services of DP application 113 c.
Thus, while thedata entry 473b of the table 473 may include data linking the first and second pause tokens ST-1 and ST-2 and the second user U2 to theelectronic device 100, the table 473 of thedevice protection subsystem 471 may not include sensitive data linking both the first and second users U1 and U2 to theelectronic device 100. In some embodiments, in response to receiving new device pause data fromdevice 100 atoperation 620, any storage of the new pause data bydevice 100 atdevice protection subsystem 471 may first include clearing any previously stored pause data fordevice 100 atdevice protection subsystem 471 at operation 622. For example, if afteroperation 616 but before operation 618-, a later operation 618-622 may be used to first clear such links between first user U1 anddevice 100 and pause tokens ST-1 and ST-2 at device protection subsystem 471 (e.g., delete at least ED-ID and ST-1 and ST-2 fromdata entry 473a of table 473 before storing link data for ED-ID and ST-1 and ST-2 and U2-ID and U2-PW indata entry 473b of table 473) before storing new pause data linking second user U2 anddevice 100 to pause tokens ST-1 and ST-2 to ensure that table 473 ofdevice protection subsystem 471 may not include sensitive data linking both first user U1 and second user U2 toelectronic device 100 and/or pause tokens ST-1 and ST-2.
Continuing with the example of fig. 6, at any suitable time afterdevice pause data 670 has been processed and stored for the identification of the user (e.g., second user U2) that has recently enabled the one or more device protection services of DP application 113c at operation 622 and any suitable pausestorage confirmation data 674 has been transferred todevice 100 atoperation 624, the user (e.g., second user U2) or any other suitable entity that has recently enabled the one or more device protection services of DP application 113c may then connect withdevice protection subsystem 471 at operation 626 in any suitable manner for activating the one or more device protection services of DP application 113 c. For example, second user U2 may log into a server of device protection subsystem 471 (e.g., from a user device external to electronic device 100) using its U2-ID and U2-PW account information, and may then connect with services ofdevice protection subsystem 471 in any suitable manner to identify device 100 (e.g., by providing or selecting the ED-ID), and activate fordevice 100 at least one device protection service that has been previously enabled ondevice 100 by second user U2 (e.g., at operation 618 via DP application 113 c). Such an activation service may be a "find my device" service that may enabledevice protection subsystem 471 to adjust any suitable mode or function ondevice 100, which may help protect the content ofdevice 100 and/or enable a user to locate device 100 (e.g., enter "lost mode"). For example, between operations 622 and 626,device 100 may be misplaced, lost or stolen such that user U2 may wish to protectdevice 100 in one or more ways by activating one or more device protection services ofdevice protection subsystem 471 and DP application 113c, such as activating a service ofdevice protection subsystem 471, which may be used to track the location ofdevice 100 and/or remotely control one or more functions ofdevice 100, such as turning on an alarm and/or erasing or pausing or otherwise terminating the usefulness of certain device content, such as pausing the ability of a secure element ofdevice 100 to generate transaction credential data for facilitating a transaction with a service provider.
In response todevice protection subsystem 471 and the device protection services of DP application 113c being activated bydevice protection subsystem 471 receiving information appropriately identifying user U2 (e.g., U2-ID and/or U2-PW) and information identifying device 100 (e.g., ED-ID) at operation 626,device protection subsystem 471 may be used at operation 628 to identify each pause token associated withdevice 100, and then share paused device pause data 678 withcredential protection subsystem 491. For example, thedevice protection subsystem 471 may be used to identify appropriate pause tokens ST-1 and ST-2 by identifying each pause token that may be stored in table 473 (e.g., in the secondlink data entry 473b of table 473) for the ED-ID and/or U2-ID and/or U2-PW as provided to thedevice protection subsystem 471 at operation 626. Then, at operation 628,device protection subsystem 471 may transmit each of the identified pause tokens ST-1 and ST-2 tocredential protection subsystem 491 as at least a portion of paused device pause data 678, where paused device pause data 678 may include any other suitable data, such as the identification of ED-ID and/or U2-ID and/or U2-PW and/or any suitable instruction that may be used to instructcredential protection subsystem 491 to pause each credential that may be associated with any identified pause token, for execution of at least a portion of the device protection services activated fordevice 100 at operation 626.
Then, at operation 630,credential protection subsystem 491 is operable to process the received paused device pause data 678 for identifying and pausing each credential that may be associated with any pause token identified by paused device pause data 678. In response to receiving device suspend data 678 indicating suspension of suspend token ST-1 and suspend token ST-2, for example,credential protection subsystem 491 may be used to determine, a first user transaction credential uniquely identified by a C1-ID may be associated with first pause token ST-1 (e.g., by identifying the C1-ID in firstlink data entry 493a of table 493 as ST-1 linked to paused device pause data 678) and taking any suitable action to temporarily pause the functionality of that first user transaction credential (e.g., by marking the credential as one that is not securely processed in a transaction if received fromdevice 100, and/or by instructingcredential issuer subsystem 300 to temporarily pause the ability of the credential to fund or otherwise facilitate any transaction with any service provider). Similarly, in response to receiving device pause data 678 indicating the pausing of pause token ST-1 and pause token ST-2,credential protection subsystem 491 may be operative to determine, a second user transaction credential uniquely identified by the C2-ID may be associated with the second suspend token ST-2 (e.g., by identifying the C2-ID in the secondlink data entry 493b of table 493 as ST-2 linked to suspended device suspend data 678) and taking any suitable action to temporarily suspend the functionality of that second user transaction credential (e.g., by marking the credential as one that is not securely processed in a transaction if received fromdevice 100, and/or by instructing thecredential issuer subsystem 300 the ability to temporarily suspend credential funding or otherwise facilitate any transaction with any service provider). Further, in response to receiving device pause data 678 indicative of pause token ST-1 and pause token ST-2,credential protection subsystem 491 may be operative to determine that a third user transaction credential uniquely identified by C3-ID may be associated with a second pause token ST-2 (e.g., by identifying C3-ID in third linked data entry 493C of table 493 as ST-2 linked to paused device pause data 678 (e.g., another three-way credential that may have been provisioned ondevice 100 for second user U2 in another instance of operation 614)) and take any suitable action to temporarily pause the functionality of that second user transaction credential (e.g., by marking a credential as one that is not securely processed in a transaction if received fromdevice 100, and/or by instructingcredential issuer subsystem 300 to temporarily pause credential funding or otherwise facilitate a provider with any service The ability of what to transact) such that two or more credentials may be associated with the same suspend token. However, it should be understood that a particular unique suspend token may only be associated with one or more credentials provisioned on a particular device for a particular user.
Then, once suspended device suspension data 678 has been processed bycredential protection subsystem 491 for suspending the feasibility of each user transaction credential associated with any suspension token identified by suspended device suspension data 678 in operation 630,credential protection subsystem 491 may be operative to generate and transmit todevice protection subsystem 471 any suitable suspended credential validation data 682 that may confirm todevice protection subsystem 471 that the feasibility of each user transaction credential associated with any suspension token identified by suspended device suspension data 678 has been appropriately suspended. Further, oncedevice protection subsystem 471 has been instructed to activate at least one device protection service ofdevice 100,device protection subsystem 471 may be used to transmit any suitable device protection service command data 684 to device 100 (e.g., to DP application 113c) atoperation 634, and device 100 (e.g., to DP application 113c) may be used to receive and process such device protection service command data 684 at operation 636 for activating one or more appropriate device protection services ondevice 100, such as opening an alert (e.g., usingoutput component 112 of device 100) and/orpassword locking device 100 and/or erasing or pausing or otherwise terminating the usefulness of certain device content, such as pausing the ability ofsecure element 145 ofdevice 100 to generate transaction credential data using any user transaction credentials for facilitating a transaction with a service provider (e.g., theCRS application 151 is used to adjust the lifecycle state of each user transaction credential (e.g., the credentials ofapplets 153a and 153b) associated with the suspend token ondevice 100 to the suspended lifecycle state).
At any suitable time after operation 636 (e.g., after finding the lost device), the user ofdevice 100 may properly authenticate himself with device 100 (e.g., with DP application 113c) in any suitable manner to disable any activated suitable device protection services (e.g., as activated at operation 636) at operation 638. For example, user U1 or user U2 may access DP application 113c of device 100 (e.g., using appropriate authentication information (e.g., U1-ID and U1-PW or U2-ID and U2-PW)), which may be transmitted todevice protection subsystem 471 atoperation 639 as at least a portion of device deactivation data 689 to indicate that one or more device protection services previously activated bydevice protection subsystem 471 have been deactivated ondevice 100. Thereafter, any user may properly authenticate himself with the user credential application ofdevice 100, un-pausing one or more credentials associated with the user. For example, as shown in fig. 6, second user U2 may accessU2C application 113e of device 100 (using any suitable authentication information (e.g., U2-ID and U2-PW) at operation 640, which may then be transmitted tocredential protection subsystem 491 at operation 641 as at least a portion of second user authentication data 691, to authenticate second user U2 atcredential protection subsystem 491 for un-pausing each suitable credential ofdevice 100 associated with user U2. for example, second user authentication data 691 may include U2-ID and/or U2-PW and ED-ID, which may be processed bycredential protection subsystem 491 at operation 642 for identifying and un-pausing each credential that may be associated with second user U2 anddevice 100 identified by second user authentication data 691. for example, in response to receiving second user authentication data 691 that may indicate U2-ID (and/or U2-PW) and ED-ID,credential protection subsystem 491 may be used to determine that a second user transaction credential uniquely identified by a C2-ID may be associated with a U2-ID (and/or a U2-PW) and an ED-ID (e.g., by identifying the C2-ID in a second linkeddata entry 493b of table 493 as a U2-ID (and/or a U2-PW) and an ED-ID linked to second user authentication data 691) and taking any suitable action to cancel the function of suspending the second user transaction credential (e.g., by unmarking the credential as a credential that is not securely processed in the transaction if received fromdevice 100 and/or by instructingcredential issuer subsystem 300 to cancel the ability to suspend credential funding or otherwise facilitate any transaction with any service provider). Similarly, in response to receiving second user authentication data 691, which may indicate U2-ID (and/or U2-PW) and ED-ID,credential protection subsystem 491 may be operative to determine that a third user transaction credential uniquely identified by C3-ID may be associated with U2-ID (and/or U2-PW) and ED-ID (e.g., by identifying C3-ID in third link data entry 493C of table 493 as U2-ID (and/or U2-PW) and ED-ID) linked to second user authentication data 691 and taking any suitable action to cancel the function of suspending the third user transaction credential (e.g., by unmarking the credential as a credential that is not securely processed in a transaction if received fromdevice 100 and/or by instructingcredential issuer subsystem 300 to cancel suspending credential or otherwise facilitate any transaction with any service provider Ease of use capability). Then, once the second user authentication data 691 has been processed by thecredential protection subsystem 491 for revoking the feasibility of pausing each user transaction credential associated with the U2-ID (and/or U2-PW) and ED-ID identified by the second user authentication data 691 at operation 642, thecredential protection subsystem 491 may be operative to generate and transmit any suitable un-paused second user credential validation data 693 to the device 100 (e.g., to theU2C application 113e) atoperation 643, which may confirm to the device 100 (and its user (e.g., the second user U2)) that each second user transaction credential on thedevice 100 of the second user U2 has been properly un-paused. Additionally or alternatively, as shown in FIG. 6, at operation 644, first user U1 may accessU1C application 113d of device 100 (using any suitable authentication information (e.g., U1-ID and U1-PW) that may then be communicated tocredential protection subsystem 491 atoperation 645 as at least a portion of first user authentication data 695 to authenticate first user U1 atcredential protection subsystem 491 for un-pausing each suitable credential ofdevice 100 associated with user U1. for example, first user authentication data 695 may include U1-ID and/or U1-PW and ED-ID, which may be processed at operation 646 bycredential protection subsystem 491 for identifying and un-pausing each credential that may be associated with first user U1 anddevice 100 identified by first user authentication data 695. for example, in response to receiving a first user ID 49323-and/or PW 4-ED ID that may indicate U1-ID (and/or U5634-ID) and PW-ID Authentication data 695,credential protection subsystem 491 may be operative to determine that a first user transaction credential uniquely identified by C1-ID may be associated with U1-ID (and/or U1-PW) and ED-ID (e.g., by identifying C1-ID in firstlink data entry 493a of table 493 as U1-ID (and/or U1-PW) and ED-ID linked to first user authentication data 695) and taking any suitable action to cancel the functionality of the first user transaction credential (e.g., by unmarking the credential as a credential that is not securely processed in a transaction if received fromdevice 100 and/or by instructingcredential issuer subsystem 300 to cancel the ability to suspend credential funding or otherwise facilitate any transaction with any service provider). Then, once the first user authentication data 695 has been processed bycredential protection subsystem 491 for revoking the feasibility of pausing each user transaction credential associated with the U1-ID (and/or U1-PW) and ED-ID identified by first user authentication data 695 at operation 646,credential protection subsystem 491 may be operative to generate and transmit any suitable un-paused first user credential validation data 697 to device 100 (e.g., toU1C application 113d) atoperation 647, which may confirm to device 100 (and its user (e.g., first user U1)) that each first user transaction credential ondevice 100 of first user U1 has been properly un-paused. It should be appreciated that operation 644 + 647 may occur before operation 640 + 643 or may occur without operation 640 + 643. In some embodiments, operation 644 plus 647 may occur before operation 638 plus 643 or may occur without operation 638 plus 643.
In some embodiments, only credentials associated with a user that activates any one or more device protection services may be suspended. For example,device protection subsystem 471 and the device protection services of DP application 113c may be activated bydevice protection subsystem 471 at operation 626, which receives information appropriately identifying user U2 (e.g., U2-ID and/or U2-PW) and device 100 (e.g., ED-ID), as well as instructions to suspend credentials associated with the user only when one or more services are activated. Alternatively,AE subsystem 400 may be configured to suspend only the credentials for the user activated service. Thus,device protection subsystem 471 may be operated at operation 628 to identify each pause token associated withdevice 100, and then share paused device pause data 678 withcredential protection subsystem 491, which may indicate a user (e.g., U2-ID and/or U2-PW) that activated one or more services such thatcredential protection subsystem 491 may then only pause credentials associated with the pause token also associated with the user (e.g., in table 493). For example, thedevice protection subsystem 471 may be used to identify appropriate pause tokens ST-1 and ST-2 by identifying each pause token that may be stored in table 473 (e.g., in the secondlink data entry 473b of table 473) for the ED-ID and/or U2-ID and/or U2-PW as provided to thedevice protection subsystem 471 at operation 626.Device protection subsystem 471 may then transmit each of the identified pause tokens ST-1 and ST-2 tocredential protection subsystem 491 as at least a portion of paused device pause data 678 at operation 628, where paused device pause data 678 may include any other suitable data, such as an identification of U2-ID and/or U2-PW and/or any suitable instructions that may be used to instructcredential protection subsystem 491 to pause each credential that may be associated with any identified pause token and that identification of user U2, for execution at operation 626 as at least a portion of the device protection services activated fordevice 100. As such,credential protection subsystem 491 may then be operative to process the received paused device pause data 678 for identifying and pausing each credential that may be associated with any pause token identified by paused device pause data 678 and that is also associated with user U2 at operation 630. For example, in response to receiving suspended device pause data 678 indicative of a pause token ST-1 and pause tokens ST-2 and U2-ID,credential protection subsystem 491 may be operative to determine that, although a first user transaction credential uniquely identified by a C1-ID may be associated with a first pause token ST-1 (e.g., by identifying C1-ID in first linkeddata entry 493a of table 493 as ST-1 linked to suspended device pause data 678), it is also not associated with U2-ID of user U2, and thus may not take any suitable action to temporarily pause the functionality of the first user transaction credential (e.g., by marking a credential as one that is not securely processed in a transaction if received fromdevice 100, and/or by instructingcredential issuer subsystem 300 to temporarily pause the funding of credentials or otherwise facilitate the ability of any transaction with any service provider). However, in response to receiving device pause data 678 indicative of pause token ST-1 and pause token ST-2, and the pause of U2-ID of user U2,credential protection subsystem 491 may be operative to determine that a second user transaction credential uniquely identified by C2-ID may be associated with second pause token ST-2 and U2-ID of user U2 (e.g., by identifying C2-ID in second linkeddata entry 493b of table 493 as ST-2 linked to paused device pause data 678 and U2-ID of user U2) and taking any suitable action to temporarily pause the functionality of the second user transaction credential (e.g., by marking the credential as one that is not securely processed in a transaction if received fromdevice 100, and/or by instructingcredential issuer subsystem 300 to temporarily pause the credential or otherwise facilitate the ability of any transaction with any service provider) . Further, in response to receiving suspended device suspension data 678 indicative of suspended token ST-1 and suspended token ST-2 and the U2-ID of user U2,credential protection subsystem 491 may be operative to determine that a third user transaction credential uniquely identified by C3-ID may be associated with the second suspended token ST-2 and the U2-ID of user U2 (e.g., by identifying C3-ID in third linked data entry 493C of table 493 as ST-2 linked to suspended device suspension data 678 and the U2-ID of user U2 (e.g., another credential that may have been provisioned ondevice 100 for second user U2 in another instance of operation 614)) and take any suitable action to temporarily suspend the functionality of this third user transaction credential (e.g., by marking a credential that is not securely processed in a transaction credential if received fromdevice 100, and/or by instructing thecredential issuer subsystem 300 the ability to temporarily suspend credential funding or otherwise facilitate any transaction with any service provider) so that two or more credentials may be associated with the same suspend token. Accordingly, only credentials associated with the suspend token ofdevice 100 and the user that activated the one or more device protection services at operation 626 may be suspended or otherwise manipulated byAE subsystem 400 at operation 630.
Further, any suitable user ofsystem 1 may be provided administrator ("admin") privileges (e.g., administrator login credentials todevice 100 and/or todevice protection subsystem 471 and/or to credential protection subsystem 491), which may enable that user to have any privileges associated with user U1 and with user U2, such that the administrator user may pause a particular one, some, or each credential of user U1 and/or a particular one, some, or each credential of user U2.
It should be understood that the operations shown inprocess 600 of fig. 6 are merely illustrative, and that existing operations may be modified or omitted, additional operations may be added, and the order of certain operations may be changed. Further, in some implementations, two or more operations may occur in parallel or in a different order than that described.
Description of FIG. 7
Fig. 7 is a flow diagram of anexemplary process 700 for securing an electronic device using a device protection server, where the electronic device includes a device identifier, a first suspend token and associated first credentials for a first user associated with the first user identifier, and a second suspend token and associated second credentials for a second user associated with a second user identifier. Atoperation 702 ofprocess 700, device pause data may be received from the electronic device with the device protection server, where the device pause data may include a first pause token, a second pause token, a device identifier, and a second user identifier (e.g., device pause data 670). Atoperation 704 ofprocess 700, the device suspension data received atoperation 702 may be stored at the device protection server (e.g., similar to operation 622). Atoperation 706 ofprocess 700, afteroperation 704, the device protection server may receive a device protection enablement request, which may include a device identifier and a second user identifier (e.g., similar to operation 626). Atoperation 708 ofprocess 700, the device protection server may use both the device identifier and the second user identifier in the received device protection enablement request to identify each of the first suspension token and the second suspension token in the stored device suspension data as stored at the device protection server. Atoperation 710 ofprocess 700, the device protection server may transmit credential suspension data to the remote subsystem, the credential suspension data indicating that the remote subsystem suspends each credential associated with the identified first suspension token and suspends each credential associated with the identified second suspension token (e.g., device suspension data 678).
It should be understood that the operations shown inprocess 700 of fig. 7 are merely illustrative, and that existing operations may be modified or omitted, additional operations may be added, and the order of certain operations may be changed.
Further description of FIGS. 1-7
One, some, or all of the processes described with respect to fig. 1-7 may be implemented by software, but may also be implemented by hardware, firmware, or any combination of software, hardware, and firmware. The instructions for performing these processes may also be embodied as machine-readable code or computer-readable code recorded on a machine-readable medium or computer-readable medium. In some embodiments, the computer readable medium may be a non-transitory computer readable medium. Examples of such non-transitory computer-readable media include, but are not limited to, read-only memory, random-access memory, flash memory, CD-ROMs, DVDs, tapes, removable memory cards, and data storage devices (e.g.,memory 104 and/or memory module 150 of fig. 2). In other embodiments, the computer readable medium may be a transitory computer readable medium. In such embodiments, the transitory computer-readable medium may be distributed over network-coupled computer systems so that the computer-readable code is stored and executed in a distributed fashion. For example, such transitory computer-readable media may be transferred from one electronic device to another electronic device using any suitable communication protocol (e.g., computer-readable media may be transferred toelectronic device 100 via communication component 106 (e.g., as at least a portion ofapplication 103 and/or as at least a portion ofapplication 113 and/or as at least a portion of application 143)). Such transitory computer-readable media may be embodied as computer-readable code, instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. A modulated data signal may be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
It should be understood that any, each, or at least one of the modules or components or subsystems of thesystem 1 may be provided as a software construct, a firmware construct, one or more hardware components, or a combination thereof. For example, any, each, or at least one of the modules or components or subsystems ofsystem 1 may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers or other devices. Generally, program modules may include one or more routines, programs, objects, components, and/or data structures that may perform one or more particular tasks or that may implement one or more particular abstract data types. It should also be understood that the number, configuration, functionality, and interconnection of the modules and components and subsystems ofsystem 1 are merely exemplary, and that the number, configuration, functionality, and interconnection of existing modules, components, and/or subsystems may be modified or omitted, additional modules, components, and/or subsystems may be added, and the interconnection of particular modules, components, and/or subsystems may be changed.
At least a portion of one or more of the modules or components or subsystems ofsystem 1 may be stored in or accessible by an entity ofsystem 1 in any suitable manner (e.g., inmemory 104 of device 100 (e.g., as at least a portion ofapplication 103 and/or as at least a portion ofapplication 113 and/or as at least a portion of application 143)). For example, any or each module ofNFC component 120 may be implemented using any suitable technology (e.g., as one or more integrated circuit devices), and the different modules may be the same or different in structure, capability, and operation. Any or all of the modules or other components of thesystem 1 may be mounted on an expansion card, directly on the system motherboard, or integrated into a system chipset component (e.g., into a "northbridge" chip).
Any or each module or component of system 1 (e.g., any or each module of NFC component 120) may be a dedicated system implemented using one or more expansion cards adapted for various bus standards. For example, all modules may be mounted on different interconnect expansion cards or all modules may be mounted on one expansion card. With respect toNFC component 120, by way of example only, modules ofNFC component 120 may be connected to a motherboard ofdevice 100 orprocessor 102 through expansion slots (e.g., peripheral component interconnect ("PCI") slots or PCI express slots). Alternatively,NFC component 120 need not be removable, but may include one or more special purpose modules that may include memory (e.g., RAM) specific to the module. In other embodiments,NFC component 120 may be integrated intodevice 100. For example, a module ofNFC component 120 may utilize a portion ofdevice memory 104 ofdevice 100. Any or each module or component of system 1 (e.g., any or each module of NFC component 120) may include its own processing circuitry and/or memory. Alternatively, any or each module or component of system 1 (e.g., any or each module of NFC component 120) may share processing circuitry and/or memory withNFC component 120 ofdevice 100 and/or any other module ofprocessor 102 and/ormemory 104.
The present disclosure recognizes that the use of such personal information data in the present technology, such as the current location of theuser device 100, may be useful to benefit the user. For example, personal information data may be used to provide better security and risk assessment for ongoing financial transactions. Therefore, the security of the financial transaction can be calculated using such personal information data. In addition, the present disclosure also contemplates other uses for which personal information data is beneficial to a user.
The present disclosure also contemplates that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will comply with established privacy policies and/or privacy practices. In particular, such entities should enforce and adhere to the use of privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining privacy and security of personal information data. For example, personal information from a user should be collected for legitimate and legitimate uses by an entity and not shared or sold outside of these legitimate uses. In addition, such collection should only be done after the user has informed consent. In addition, such entities should take any required steps or perform certain actions to secure and protect access to such personal information data, and to ensure that others who have access to the personal information data comply with their privacy policies and procedures. In addition, such entities may subject themselves to third party evaluations to prove compliance with widely accepted privacy policies and practices.
Regardless of the foregoing, the present disclosure also contemplates embodiments in which a user selectively prevents use or access to personal information data. That is, the present disclosure contemplates that hardware elements and/or software elements may be provided to prevent or block access to such personal information data. For example, in the case of financial transaction services, the techniques of the present invention may be configured to allow a user to opt-in to "join" or "opt-out of" participating in the collection of personal information data during registration with such services. As another example, the user may choose not to provide location information to the financial transaction service. As another example, the user may choose not to provide accurate location information, but to permit transmission of location area information.
Thus, while the present disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the present disclosure also contemplates that various embodiments may be implemented without the need to access such personal information data. That is, various embodiments of the present technology do not fail to function properly due to the lack of all or a portion of such personal information data. For example, financial transaction services may be provided by inferring preferences or conditions based on non-personal information data or an absolute minimum amount of personal information, such as financial transactions conducted by a device associated with a user, other non-personal information available to the financial transaction service, or publicly available information.
Further application of the concept
Although systems, methods, and computer-readable media have been described for managing credentials for multiple users on an electronic device, it should be understood that many changes may be made therein in any manner without departing from the spirit and scope of the subject matter described herein. Insubstantial modifications of the claimed subject matter as viewed by a person with ordinary skill in the art, now known or later devised, are expressly contemplated as being equivalently within the scope of the claims. Thus, obvious substitutions now or later known to one with ordinary skill in the art are defined to be within the scope of the defined elements.
Accordingly, those skilled in the art will recognize that the present invention may be practiced by other than the described embodiments, which are presented for purposes of illustration and not of limitation.