阅读说明：本技术 基于二次装置交互的增强认证 (Enhanced authentication based on secondary device interaction ) 是由 E·勒圣 D·法德罗尼克 C·阿艾拜 于 2016-04-13 设计创作，主要内容包括：增强认证技术可以包括：由一次装置接收二次装置的凭证数据、使用所述二次装置的所述凭证数据生成密码以及将所述密码传送到访问装置以请求授权使用与所述一次装置的用户相关联的账户。可以基于所述密码的验证和在所述一次装置与包括所述二次装置的一组通信装置之间的交互的交互活动模式来授予所述授权。(The enhanced authentication technique may include: receiving, by a primary device, credential data for a secondary device, generating a password using the credential data for the secondary device, and transmitting the password to an access device to request authorization to use an account associated with a user of the primary device. The authorization may be granted based on authentication of the password and an interactivity pattern of interactions between the primary device and a set of communication devices including the secondary device.)

1. A communication device, comprising:

a processor; and

a memory storing computer readable instructions that, when executed by the processor, cause the communication device to act as a primary device and perform operations comprising:

generating a first intermediate password using a first portion of a cryptographic key stored on the primary device;

transmitting the first intermediate password to a secondary device;

receiving credential data of the secondary device, wherein the credential data of the secondary device received by the primary device is a second intermediate password generated by the secondary device using the first intermediate password and a second portion of the cryptographic key stored on the secondary device;

generating a password using the credential data of the secondary device; and

sending the password to an access device to request authorization to use an account associated with a user of the primary device, wherein the authorization is granted based on authentication of the password and an interactivity pattern of historical interactions between the primary device and a set of communication devices including the secondary device.

2. The communication device of claim 1, wherein the operations further comprise:

for each communication device in the set of communication devices:

establishing a communication channel between the primary device and the communication device;

receiving device data from the communication device, the device data including at least one of a device identifier identifying the communication device, sensor data sensed by the communication device, or user data captured by the communication device; and

sending the device data received from the communication device to an authorization server, wherein the device data is used to establish the interactivity mode.

3. The communication device of claim 2, wherein the interactivity mode is further established based on a time of day that the primary device interacts with each communication device.

4. The communication device of claim 2, wherein the authorization is granted based on a comparison of the interactivity pattern to a most recent interaction between the primary device and one or more of the communication devices.

5. The communication device of claim 1, wherein the credential data of the secondary device comprises a device identifier of the secondary device, and the operations further comprise:

deriving a key encryption key using the device identifier of the secondary device and a shared key stored on the primary device; and

the derived key encryption key is used to decrypt the encrypted cryptographic key,

wherein generating the password comprises encrypting data associated with the authorization request using the decrypted password key.

6. The communication device of claim 5, wherein the operations further comprise:

prior to receiving the credential data of the secondary device:

transmitting the device identifier of the secondary device to an authorization server to register the secondary device;

receiving the shared key and the encrypted cryptographic key from the authorization server in response to registering the secondary device; and

storing the shared key on the primary device.

7. The communication device of claim 6, wherein the operations further comprise storing the encrypted cryptographic key on the primary device.

8. The communication device of claim 6, wherein the operations further comprise:

forwarding the encrypted cryptographic key to the secondary device for storage on the secondary device; and

receiving the encrypted cryptographic key from the secondary device as part of the credential data of the secondary device.

9. The communication device of claim 5, wherein the primary device interacts with the access device in the absence of the secondary device.

10. The communication device according to claim 9, wherein the credential data of the secondary device is deleted from the primary device when a predetermined period of time has elapsed since the receipt of the credential data.

11. A communication device, comprising:

a processor; and

a memory storing computer readable instructions that, when executed by the processor, cause the communication device to act as a primary device and perform operations comprising:

determining that a secondary device is not in front of the primary device;

sending a request for credential data of the secondary device to a remote server;

receiving the credential data of the secondary device from the remote server;

generating a password using the credential data of the secondary device; and

sending the password to an access device to request authorization to use an account associated with a user of the primary device, wherein the authorization is granted based on authentication of the password and an interactivity pattern of historical interactions between the primary device and a set of communication devices including the secondary device.

12. The communication device of claim 11, wherein the instructions, when executed by the processor, perform the operations further comprising determining that the secondary device is not in front of the primary device, wherein sending the request is based on determining that the secondary device is not in front of the primary device.

13. The communication device of claim 11, wherein the password is generated by the primary device using a second intermediate password and a first portion of a cryptographic key stored on the primary device.

14. The communication device of claim 11, wherein the first intermediate cryptogram is generated by: the method further includes encrypting data associated with the authorization request using the first portion of the cryptographic key, decrypting the encrypted data using a first intermediate key, and re-encrypting the decrypted data using a second intermediate key.

15. The communication device of claim 14, wherein the second intermediate cryptogram is generated by: decrypting the first intermediate password using the second intermediate key, re-encrypting the decrypted first intermediate password using the first intermediate key, and decrypting the re-encrypted first intermediate password using the second portion of the cryptographic key.

16. The communication device of claim 15, wherein the second intermediate cryptogram is further generated by: encrypting a result of decrypting the re-encrypted first intermediate password using the second intermediate key, and decrypting the encrypted result using the first intermediate key.

17. The communication device of claim 16, wherein the password is generated by: the second intermediate password is encrypted using the first intermediate key, the encrypted second intermediate password is decrypted using the second intermediate key, and the decrypted second intermediate password is re-encrypted using the first portion of the cryptographic key.

18. The communication device of claim 11, wherein an authorization request is initiated from a tertiary device acting as a user interface device communicatively coupled to the primary device.

19. The communication device of claim 11, wherein the communication device is a portable communication device or a network-connected communication device.

20. A method, comprising:

generating, by a primary device, a first intermediate password using a first portion of a cryptographic key stored on the primary device;

transmitting, by the primary device, the first intermediate password to a secondary device;

receiving, by the primary device, credential data of the secondary device, wherein the credential data of the secondary device received by the primary device is a second intermediate password generated by the secondary device using the first intermediate password and a second portion of the cryptographic key stored on the secondary device;

generating, by the primary device, a password using the credential data of the secondary device; and

sending, by the primary device, the password to an access device to request authorization to use an account associated with a user of the primary device, wherein the authorization is granted based on verification of the password and an interactivity pattern of historical interactions between the primary device and a set of communication devices including the secondary device.

Background

Advances in communication technology have allowed virtually any type of device to be enabled using network connectivity. At the same time, the capabilities of both portable and home devices have also expanded to allow such devices to perform an increasing number of functions, including security-sensitive operations. Examples of security-sensitive operations may include storing security-sensitive information (such as account credentials), and using the security-sensitive information to access a user's account. Due to the network-connected nature of such devices, unauthorized parties have also become readily able to gain access to such devices and the security-sensitive information stored therein. Therefore, there is a need to provide more powerful authentication of such devices to ensure that the user operating the device is an authorized user of the device.

Embodiments of the present invention address these and other problems, individually and collectively.

Disclosure of Invention

Embodiments of the present invention provide enhanced authentication techniques to authenticate a communication device. In some embodiments, a user may operate a communication device to perform a security-sensitive function. By providing a more powerful authentication scheme to authenticate a communication device, the confidence that a user performing a security-sensitive function by the communication device is an authorized user of the communication device may be increased. In some embodiments, the enhanced authentication techniques described herein utilize interactions between a communication device and other devices that may communicate with the communication device. For example, recent interactions between the communication device and other devices may be compared to historical interactivity patterns to provide a risk assessment as to whether the communication device is being used in a manner that conforms to typical behavior of a user. In some embodiments, the communication device may also utilize interactions with other devices to securely store account credentials and/or utilize capabilities of other devices to perform cryptographic operations to authenticate the communication device.

According to some embodiments, the enhanced authentication technique may include: receiving, by the primary device, credential data of the secondary device, generating a password using the credential data of the secondary device, and transmitting the password to the access device to request authorization to use an account associated with a user of the primary device. Authorization may be granted based on authentication of a password and an interactivity mode of interaction between a primary device and a set of communication devices including a secondary device.

According to some embodiments, the credential data of the secondary device may comprise a device identifier of the secondary device. The primary device may derive a key encryption key using a device identifier of the secondary device and a shared key stored on the primary device, and decrypt the encrypted cryptographic key using the derived key encryption key. The primary device may then encrypt data related to the request authorization by using the decrypted cryptographic key to generate a password.

According to some embodiments, the credential data of the secondary device may include an intermediate password. The primary device may generate a first intermediate cryptogram using a first portion of a cryptographic key stored on the primary device and transmit the first intermediate cryptogram to the secondary device. The secondary device may generate a second intermediate password (as credential data) using the first intermediate password and a second portion of the cryptographic key stored on the secondary device and send the second intermediate password to the primary device. The primary device may then generate a final password by using the second intermediate password and the first portion of the cryptographic key stored on the primary device.

According to some embodiments, a communication device may include a processor and a memory storing computer-readable instructions for implementing an enhanced authentication technique. The communication device may be a portable communication device or a network connected communication device.

Drawings

Fig. 1 illustrates a conceptual diagram of one example of communication devices interacting with each other, according to some embodiments.

Fig. 2 illustrates a conceptual diagram of another example of communication devices interacting with each other, according to some embodiments.

Fig. 3 illustrates one example of an interactive activity pattern, according to some embodiments.

Fig. 4A illustrates a scenario of a communication device interacting with an access device, according to some embodiments.

Fig. 4B illustrates a scenario of two communication devices cooperatively interacting with an access device, according to some embodiments.

Fig. 4C illustrates a scenario of three communication devices cooperatively interacting with an access device, according to some embodiments.

Fig. 5 illustrates a communication flow diagram of a provisioning process for secondary device assisted credential storage in accordance with some embodiments.

Fig. 6 illustrates a communication flow diagram for requesting authorization to use an account with a secondary device assisted credential store in accordance with some embodiments.

Fig. 7 illustrates a communication flow diagram of a provisioning process for secondary device assisted encryption, in accordance with some embodiments.

Fig. 8 illustrates a communication flow diagram for requesting authorization to use an account using secondary device assisted encryption, according to some embodiments.

Fig. 9 illustrates a conceptual diagram of an example technique for generating a password cooperatively by two communication devices, according to some embodiments.

Fig. 10 illustrates a flow diagram of a process for establishing an interactivity mode, according to some embodiments.

Figure 11 illustrates a flow diagram of a process for requesting authorization to use an account, according to some embodiments.

Fig. 12 illustrates a flow diagram of a process for utilizing a secondary device to assist credential storage, according to some embodiments.

Fig. 13 illustrates a flow diagram of a process for utilizing secondary device assisted encryption, according to some embodiments.

Fig. 14 illustrates a block diagram of a portable communication device according to some embodiments.

Fig. 15 illustrates a block diagram of a network-connected communication device, according to some embodiments.

Fig. 16 illustrates a block diagram of a communication device, according to some embodiments.

Fig. 17 illustrates a block diagram of an exemplary system according to some embodiments.

Detailed Description

Embodiments of the present invention provide enhanced authentication techniques to authenticate a communication device. In some embodiments, a user may operate a communication device to perform a security-sensitive function. By providing a more powerful authentication scheme to authenticate a communication device, the confidence that a user performing a security-sensitive function by the communication device is an authorized user of the communication device may be increased. In some embodiments, the enhanced authentication techniques described herein utilize interactions between a communication device and other devices that may communicate with the communication device. For example, recent interactions between the communication device and other devices may be compared to historical interactivity patterns to provide a risk assessment as to whether the communication device is being used in a manner that conforms to typical behavior of a user. In some embodiments, the communication device may also utilize interactions with other devices to securely store account credentials and/or utilize capabilities of other devices to perform cryptographic operations to authenticate the communication device.

Before discussing the details of some embodiments of the invention, a description of some terms may be helpful in understanding the various embodiments.

A "communication device" may be a device that includes one or more electronic components (e.g., an integrated chip) that may communicate with another device. For example, the communication device may be a computing device including at least one processor coupled to a memory that stores instructions or code executed by the processor. Examples of communication devices may include access points, routers, gateways, networking hubs, desktop computers, intelligent appliances (e.g., set-top boxes, intelligent TVs, intelligent ovens, intelligent thermostats, intelligent refrigerators, intelligent heaters, home detection systems, etc.), and so forth. Other examples of communication devices may include portable communication devices or accessories for portable communication devices (e.g., headsets, earpieces, speakers, etc.).

A "portable communication device" may be a communication device that may be transported and operated by a user and may include one or more electronic components (e.g., an integrated chip). The portable communication device may provide remote communication capabilities to the network. The portable communication device may be configured to transmit data or communications to and receive data or communications from other devices. The portable communication device may be in the form of a mobile device such as: a mobile phone (e.g., a smart phone, a cellular phone, etc.), a tablet, a portable media player, a personal digital assistant device (PDA), a wearable device (e.g., a watch, a health monitoring device such as a fitness bracelet, etc.), an electronic reader device, etc., or in the form of a card (e.g., a smart card) or a pendant, etc. Examples of portable communication devices may also include portable computing devices (e.g., laptops, netbooks, ultrabooks, etc.). The portable communication device may also be in the form of a vehicle (e.g., an automobile) or integrated as part of a vehicle (e.g., an information system of a vehicle).

A "device identifier" may refer to a unique identifier of a communication device. The device Identifier (ID) may be, for example, a serial number, a device alias, an Internet Protocol (IP) address, a Media Access Control (MAC) address, a Mobile Subscriber Integrated Services Digital Network (MSISDN) number or other communication number associated with the communication device, an International Mobile Subscriber Identity (IMSI) number, an international mobile station equipment identity (IMEI) number, or other variable or non-variable device identification characters. In some embodiments, the device identifier may also be a requestor identifier (e.g., a token requestor identifier) that identifies the communication device to the authorization server. The requestor identifier may be generated by the authorization server and assigned to the communication device by the authorization server.

A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers that function as a unit. In one example, the server computer may be a database server coupled to a network server. The server computer may be coupled to the database and may include any hardware, software, other logic, or combination of the preceding for servicing requests from one or more client computers. The server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

An "issuer" may generally refer to a business entity (e.g., a bank) that maintains an account of a user associated with a portable communication device, such as an account registered in a mobile application installed on the portable communication device. The issuer may also issue account parameters associated with the account to the portable communication device. An issuer may be associated with a host system that performs some or all of the issuer's functions on behalf of the issuer. In some embodiments, an issuer may refer to a provider of a software application.

A "merchant" may generally be an entity that participates in a transaction and is capable of selling or providing access to goods or services.

An "acquirer" can generally be a business entity (e.g., a business bank) that has a business relationship with a particular merchant or other entity. Some entities are capable of performing issuer and acquirer functions. Some embodiments may include such a single entity issuer-acquirer.

The "access device" may be any suitable device for interacting with the communication device and for communicating with the authorization server. In some embodiments, the access device may communicate with the authorization server via a merchant computer or a transaction processing network. The access device may generally be located at any suitable location, such as at a location where a merchant is located. The access means may be in any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, Personal Computers (PCs), tablet PCs, handheld application specific readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosks, security systems, access systems, websites or web servers, and the like. The access device may use any suitable contact or contactless, wired or wireless mode of operation to transmit or receive data from or associated with the communication device. In some embodiments where the access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer readable medium. The reader may include any suitable contact or contactless mode of operation. For example, an exemplary card reader may include a Radio Frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader for interacting with a portable communication device.

An "authorization request message" may be an electronic message sent to request authorization of a transaction. The authorization request message may be transmitted to the transaction processing network and/or the issuer of the transaction card (e.g., payment card). The authorization request message according to some embodiments may conform to ISO 8583, ISO 8583 being a standard of systems for exchanging electronic transaction information associated with transactions made by users using transaction devices or transaction accounts. The authorization request message may include information that may be used to identify the account. The authorization request message may also include additional data elements, such as one or more of a service code, expiration date, and the like. The authorization request message may also include transaction information (such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc.), and any other information that may be used to determine whether to identify and/or authorize the transaction. The authorization request message may also include other information, such as information identifying the access device that generated the authorization request message, information regarding the location of the access device, and the like.

The "authorization response message" may be an electronic message reply to the authorization request message. The authorization response message may be generated by the issuing financial institution or the transaction processing network. The authorization response message may include (by way of example only) one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-in response to more information pending, the merchant must call the toll free authorization phone number. The authorization response message may also include an authorization code, which may be a code that the credit card issuing bank returns to the merchant computer (either directly or through the transaction processing network) in response to the authorization request message in the electronic message indicating approval of the transaction. The code may be used as proof of authorization. As described above, in some embodiments, the transaction processing network may generate or forward an authorization response message to the merchant.

A "token" may include an alternative identifier for some information. For example, the transaction token may include an identifier of the transaction account that is a substitute for an account identifier, such as a Primary Account Number (PAN). For example, the token may include a series of alphanumeric characters that may be used as a substitute for the original account identifier. For example, the token "4900000000000001" may be used in place of PAN "4147090000001234". In some embodiments, the token may be in a reserved format and may have a numeric format (e.g., ISO 8583 financial transaction message format) that conforms to an account identifier used in existing transaction processing networks. In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle, or resolve a transaction. In other systems that typically provide an original certificate, a token may also be used to represent the original certificate. In some embodiments, the token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to cause the entity receiving the token to identify it as a token and to identify the entity that issued the token.

The "real account identifier" may include a primary account identifier associated with the account. For example, the real account identifier may be a Primary Account Number (PAN) issued by an issuer for a card account (e.g., credit card, debit card, etc.). For example, in some embodiments, the real account identifier may include a sixteen digit value, such as "4147090000001234". The first six digits of the real account identifier (e.g., "414709") may represent the actual issuer identifier (BIN) that may identify the issuer associated with the real account identifier.

An "account parameter" may refer to information associated with an account that may be used to transact the account. Examples of account parameters may include information that may be used to identify a user's account (e.g., a real account identifier, an alternate account identifier, a token, etc.), data or information related to the status of the account, one or more keys used to generate cryptographic information, data or information related to one or more keys, and so forth. The account parameters may be semi-static or dynamic. Dynamic account parameters may be account parameters that have a limited lifetime and, once expired, are no longer available to conduct transactions until the account parameters are replenished, refreshed, or updated. Dynamic account parameters may be replenished frequently during the lifetime of an account. The semi-static account parameters may be account parameters having a longer lifetime than the dynamic account parameters, and may be replenished less frequently than the dynamic account parameters, or not at all during the lifetime of the account.

A "key" may refer to a piece of information used in a cryptographic algorithm to transform input data into another representation. The cryptographic algorithm may be an encryption algorithm that transforms the original data into an alternate representation, or a decryption algorithm that transforms the encrypted information back into the original data. Examples of cryptographic algorithms may include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), and the like.

A "limited use key" or "LUK" may refer to a key that may only be used for a limited time or for a limited number of transactions, and may need to be updated or replenished when the limited use is exhausted. The LUK may be associated with a set of one or more limited-use thresholds that limit the use of the LUK, wherein once the use of the LUK is exhausted or exceeds the set of one or more limited-use thresholds, further transactions using the LUK will be denied, even if the underlying account is still in good standing. The set of one or more limited-use thresholds may include at least one of: the number of transactions that can use the LUK; a survival time indicating a duration of time that the LUK is effective; and/or a cumulative transaction amount indicating a total transaction amount aggregated for one or more transactions valid for the LUK; or any combination thereof.

A "limited-use threshold" may refer to a condition that restricts the use of a piece of information. The limited use threshold may be exceeded or exhausted when the base condition is satisfied. For example, the limited-use threshold may include a time-to-live indicating an amount of time that a piece of information is valid, and once the amount of time has elapsed, the limited-use threshold is exceeded or exhausted, and this piece of information may become invalid and no longer available for use. As another example, the limited-use threshold may include a number of times a piece of information may be used, and once the piece of information has been used the number of times, the limited-use threshold is exceeded or exhausted, and the piece of information may become invalid and may no longer be used.

A "transaction processing network" may include a network that may process and route transaction request messages. An exemplary transaction processing network may include a data processing subsystem, a network, and operations to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing network may include VisaNet^TM. Such as VisaNet^TMCan process credit card transactions, debit card transactions, and other types of commercial transactions. Visanet^TMSpecifically, a VIP system (account integrated payment system) that processes an authorization request and a Base II system that performs a clearing and settlement service may be included.

Details of some embodiments of the invention will now be described.

I. Interactive activity mode

A user of a communication device will typically develop a behavioral pattern that operates the communication device and uses the communication device to interact with other communication devices. For example, a user may develop a pattern that uses a smartphone to check the user's calendar each morning the user wakes up. The user may also develop a mode of connecting the smartphone to the wireless speaker so that music is played every night, approximately at dinner time. This behavior pattern of how the communication device is operated and how the communication device interacts with other devices may be tracked over time to establish an interactive activity pattern of the communication device.

Fig. 1 illustrates a conceptual diagram of an example of communication devices interacting with each other during a day, according to some embodiments. The example shown in fig. 1 is illustrated from the perspective of a mobile device 101 (e.g., a smartphone) that a user carries with him throughout the day. In this example, the mobile device 101 may act as a communications hub that interacts with various other devices. Mobile device 101 may interact with different communication devices at different times and/or simultaneously with more than one communication device at a time.

Referring to fig. 1, in the early morning when the user wakes up at home, the user may operate mobile device 101 to connect to wireless access point 113 to use the WiFi data connectivity of the home, for example, to synchronize a calendar on mobile device 101 with a remote server and check the user's daily schedule. The user may also wear the exercise bracelet 112 and open the exercise bracelet 112. The workout bracelet 112 may establish a communication channel with the mobile device 101 so that a user may select an exercise program configured on the workout bracelet 112 using the mobile device 101 as a user interface and so that the workout bracelet 112 is able to transmit health monitoring data, such as the user's heart rate, to the mobile device 101.

Thereafter, on the morning after the user has completed the morning workout, the user may leave the user's home and commute to work. When the user leaves the home and enters the user's vehicle 114, the mobile device 101 may disconnect from the home's wireless access point 113 and establish a new connection with the vehicle 114, for example, to allow the user to initiate a call from the vehicle 114 while the user is driving or to stream music from the mobile device 101 to the audio system of the vehicle 114. The mobile device 101 may also periodically or continuously establish connectivity with the exercise bracelet 112 to obtain health monitoring data if the user wears the exercise bracelet 112 throughout the day.

When the user arrives at the office, mobile device 101 may be disconnected from vehicle 114. At noon when the user is in the office, the mobile device 101 may connect to the office laptop 115 to synchronize the mobile device 101 with the laptop 115. The mobile device 101 may also be connected to an office headset 116 to allow the user to make hands-free calls in the office. At the same time, the mobile device 101 may periodically or continuously establish connectivity with the health bracelet 112 to obtain health monitoring data for the user. In the afternoon when the user leaves the office and goes home, mobile device 101 may disconnect from laptop 115 and headset 116. Mobile device 101 may reestablish connectivity with vehicle 114 when the user drives home.

When the user arrives at home, mobile device 101 may disconnect from vehicle 114. When the user removes the exercise bracelet 112, the mobile device 101 may also be disconnected from the exercise bracelet 112. At the user's night at home, mobile device 101 may reestablish a connection with access point 113 to use the home's internet data connectivity. The mobile device 101 may also be connected to a wireless speaker 119 to stream music to the speaker 119 and to the TV 117 to play video on the TV 117. The mobile device 101 may also be connected to a smart appliance 118, such as a smart thermostat, to regulate the temperature in the home.

Fig. 2 illustrates a conceptual diagram of another example of communication devices interacting with each other during a day, according to some embodiments. The example shown in fig. 2 is illustrated from the perspective of an access point 201 (e.g., an internet gateway or router) installed at the user's home. In this example, access point 201 may act as a communications hub for interacting with various other devices. Access point 101 may interact with different communication devices at different times and/or simultaneously with more than one communication device at a time.

In the early morning when the user wakes up at home, the user may operate the mobile device 211 to connect to the wireless access point 201, similar to the example of fig. 1. Thereafter, on the morning of the user leaving work, the access point 201 may disconnect from the mobile device 211 and establish a connection with the home monitoring system 212 to allow the user to remotely detect the home. At midday and while still connected to the home monitoring system 212, the access point 201 may connect to the DVR 213 to begin recording programs when the user is not at home. In the afternoon, the access point 201 may disconnect from the DVR 213 after recording of the program has been completed and connect to a smart appliance 214, such as a smart thermostat, to warm up the home before the user goes home from work. On the evening the user goes home, the access point 201 may disconnect from the home monitoring system 212. The user may also connect the access point 212 to various devices that use the access point 201 for data connections, such as the user's mobile device 211, tablet 216, and TV 215.

As these examples illustrate, whether the communication device is a portable communication device such as mobile device 101 or a network-connected communication device such as access point 201, the communication device acting as a primary device may interact with any number of other devices during the day. Since the daily life of a user is not expected to vary greatly from day to day, interactions between the user's communication devices throughout the day may be collected to establish an interactive activity pattern that represents typical behavior of the user and/or the user's communication devices. This pattern of interactivity may be learned over time and may be used as a digital character to authenticate the user and the user's communication device, as discussed further below.

Fig. 3 illustrates an example of an interactivity pattern 300 of interactions between a user's communication devices, according to some embodiments. The example of the interactivity mode 300 shown in fig. 3 is based on the device interaction shown in fig. 1, where the user's mobile device is acting as a communications hub. The interactive activity pattern 300 may provide correlations between various time periods of the day (e.g., early morning, mid-day, afternoon, evening, etc.) and device data associated with communication devices interacting with each other during a particular time period. Although the time of day 310 shown in fig. 3 is divided into five different time periods, it should be understood that in some embodiments, a finer time period granularity (e.g., each hour of a day representing a time period) or a coarser time period granularity (e.g., morning, day, and evening) may be used.

In a most basic form, the interactivity pattern 300 may include a correlation between a time of day 310 and a device Identifier (ID)320 of a communication device interacting with the user's mobile device during different time periods of the day. For example, in the early morning, the user's mobile device may interact with the user's home access point and fitness bracelet. As such, the interactive activity mode 300 may associate device IDs for the mobile device, the access point, and the workout bracelet with the morning time period. Similarly, at night, the user's mobile device may interact with the user's home access point, wireless speakers, TV, and smart appliances. In this way, the interactive activity mode 300 may correlate device IDs for mobile devices, access points, wireless speakers, TVs, and smart appliances to evening time periods.

In some embodiments, in addition to associating device IDs, the interactivity pattern 300 may include correlations between time of day 310 and additional device data available from the communication device. For example, the interactivity pattern 300 may include correlations between time of day 310 and context data 340 available from any of the communication devices. In some embodiments, context data 340 may include sensor data, such as environmental data and/or performance or status data provided by one or more sensors of a device. Additionally or alternatively, the context data 340 may include user data representing how the user interacted with the communication device during each time period. For example, the user data may include user input received by the device during a particular time period (e.g., buttons pressed by the user, keyboard or keypad input by the user, etc.). The user data may also include device functions invoked by the user during a particular time period (e.g., application invoked by the user, operational and/or configuration changes made by the user, activities performed by the user using the device, etc.).

Referring to fig. 3, a user's mobile device may provide context data such as the location of the mobile device, applications on the mobile device used by the user, a phone call log, and/or a text message log. The context data of the mobile device during each time period in the time of day 310 may be associated with a corresponding time period in the interactivity mode 300. With respect to other communication devices, during the early morning hours, the mobile device interacts with the fitness bracelet and access point. The workout bracelet may provide contextual data such as speed/acceleration data and heart rate data, as well as exercise programs selected by the user. The access point may provide context data such as location and network speed data. These contextual data from the workout bracelet and access point may be associated with the early morning time period as part of the interactivity mode 300.

As another example, during a midday period, a user's laptop in an office may provide context data in the form of applications on the laptop used by the user, as well as a web browser history. The user's headset may provide context data in the form of a call log and volume settings set by the user. These context data from the laptop and headset may be associated with a midday period as part of the interactivity mode 300. Similarly, during the evening hours, contextual data (such as playlists and volume settings for wireless speakers, viewing channels and volume settings for TV, and temperature, humidity, and illumination levels detected by the smart home thermostat) may be associated with the evening hours as part of the interactivity mode 300.

According to some embodiments, device data (e.g., device ID, context data such as sensor data and/or user data, etc.) of the communication device may be sent to the authorization server to establish the interactivity mode at the authorization server. A communication hub device (which may be referred to as a "primary device") such as a mobile device, access point, etc. may periodically transmit device data to an authorization server during the day. The primary device may have cryptographic capabilities to communicate with the authorization server using end-to-end encryption. In some embodiments, end-to-end encryption may be implemented using a protocol such as opacity that does not require a handshake between the primary device and the authorization server to establish a secure communication channel.

Further, the primary device may receive a device ID of the secondary device on a day in which the primary device interacts with other communication devices (may be referred to as "secondary devices") and establishes a communication channel with each secondary device. The device ID may be received as part of a protocol to establish a communication channel with the secondary device, or to establish a communication channel in response to the primary device requesting the device ID from the secondary device. The primary device may send its own device ID, the received device ID of the secondary device, and a timestamp indicating when the primary device interacted with the secondary device to an authorization server (e.g., using end-to-end encryption) to establish the interactivity mode. In some embodiments, if the primary device sends the device ID of the secondary device as they are received (e.g., substantially in real-time), the timestamp may be omitted, as the authorization server may itself make the determination as to when the primary device interacts with the secondary device (e.g., based on when the authorization server receives the device ID).

In embodiments where the interactivity mode comprises contextual data, such as sensor data and/or user data of the secondary device, the primary device may receive the sensor data and/or user data from the secondary device as part of a normal interaction with the secondary device. In some embodiments, the primary device may request sensor data and/or user data from the secondary device. The primary device may send its own context data to the authorization server, as well as sensor data and/or user data from the secondary device, in a manner similar to the device ID described above. In some embodiments, the primary device may periodically poll each secondary device for device data (e.g., device ID, sensor data, and/or user data) associated with the secondary device and send the device data to the authorization server according to a predetermined schedule. In some embodiments, if the secondary device has its own cryptographic capability to communicate with the authorization server using end-to-end encryption, the secondary device itself may send its device data to the authorization server.

In some embodiments, the location data provided from the primary and secondary devices may also be used by the authorization server to derive a geographic perimeter that represents a geofence around the user's location for an entire day. For example, the geographic perimeter may be derived by extrapolating a route taken by the user using the location reported by the device and setting the perimeter's boundaries at a predetermined distance around the extrapolated route. This geographic perimeter may provide an indication of where the user may be during each time period of the day, and may include geographic perimeter information as part of the interactivity pattern associated with the user's communication device.

While the user's daily routine will generally remain the same every day, there may be anomalies and situations from time to time that may cause the user to deviate from his or her regular daily routine. In this way, the authorization server may analyze the device data of the primary and secondary devices over time and filter out any differences that deviate from the typical behavior of the user when establishing the interactive activity pattern. For example, raw device data from each day may be compared to those of the previous days, and only public device data or device data that has been consistent for a threshold number of days may be used as the interactive activity pattern. In some embodiments, the authorization server may maintain separate interactivity patterns for each day of the week to account for differences in user behavior between days or weekdays and weekends. Once the interactivity patterns based on interactions between a user's communication devices have been learned by the authorization server, the authorization server may utilize the interactivity patterns to provide enhanced authentication for the user and his/her communication devices. In some embodiments, the authorization server may also analyze trends in the correlation between the device data and different time periods to account for changes in user behavior over time, and adjust or update the interaction activity patterns accordingly.

Authentication based on interactivity patterns

Fig. 4A-4C illustrate different scenarios in which an interactivity mode may be used to provide enhanced authentication services for a user and his/her communication device.

Referring to fig. 4A, a user may operate the primary device 401 to communicate with the access device 460 to perform security-sensitive operations, such as requesting authorization to use an account associated with the user of the primary device 401. In this scenario, the primary device 401 acts as a requestor device with the ability to interact with the access device 460 to request authorization to use an account associated with the user. For example, the primary device 401 may have compatible applications and compatible communication hardware to interact with the access device 460. The access device 460 may be, for example, a remote web server or a POS terminal in proximity to the primary device 401. To request authorization to use an account associated with a user, the primary device 401 may provide a token or account identifier to the access device 460. The primary device 401 may also provide a device ID to the access device 460 if the token or account identifier is not unique to the primary device 401 (e.g., the same token or account identifier is provided to other devices) so that the primary device 401 may be identified. The access device 460 may forward the token or account identifier (and device ID, if provided) to the authorization server 480. The authorization server 480 may be based on the token or account identifier of the primary device 401, the device ID (e.g., as forwarded by the access device 460, or determined from the token or account identifier (if unique to the primary device 401)), and retrieve the interactivity mode associated with the primary device 401.

In embodiments where the primary device 401 sends device data to the authorization server 480, the authorization server 480 may compare the latest device data received from the primary device 401 with the interaction activity pattern to assess the risk of whether the primary device 401 is operated by its authorized user. For example, if the latest device data (e.g., device ID and/or context data) received from the primary device 401 is similar to the historical interactivity pattern over the time of day, the confidence with which the primary device 401 was operated by its authorized user will be high and the authorization server 480 may authorize use of the user's account.

In embodiments where the primary device does not typically send device data directly to the authorization server 480, the authorization server 480 may compare the device ID of the primary device 401 to historical interactivity patterns to determine whether the user typically interacts with the primary device 401 or uses the primary device 401 during this time of day and/or whether the primary device 401 is used at a location within the geographic vicinity of where the user is expected at this time of day. If the use of the primary device 401 is consistent with the interactive activity pattern, the authorization server 480 may authorize the use of the user's account. In some embodiments, the primary device 401 may also provide context data (e.g., sensor data and/or user data of the primary device 401) to the access device 460, and the access device 460 may forward the context data to the authorization server 480. The context data of the primary device 401 may also be taken into account when the authorization server 480 assesses the risk of whether the primary device 401 is operated by its authorized user.

If the authorization server 480 determines that the latest device data received from the primary device 401 does not coincide with the interactive activity pattern or that the primary device 401 is used in a manner deviating from the interactive activity pattern, the authorization server 480 may reject the authorization request. In some embodiments, instead of rejecting the authorization request, authorization may still be allowed if additional data is available to increase the confidence that the user using requestor device 401 is an authorized user.

Fig. 4B illustrates a scenario in which an additional communication device (which may be referred to as a "secondary device") is used to increase the confidence that the user using the primary device 401 is an authorized user, according to some embodiments. In fig. 4B, the user may operate the primary device 401 in the presence of additional communication devices that have previously registered with the authorization server 480. The additional communication device may be a secondary device 412 acting as a credential device providing credential data to the primary device 401. In some embodiments, if the secondary device 412 is a wearable device with a biometric or activity sensor (e.g., heart rate monitor) that can be used to establish the user's continuous presence, the additional credential data provided to the primary device 401 may be an activity or biometric pattern stream (e.g., heart rate data). The flow of activity or biometric patterns from the previously registered secondary device 412 may increase the confidence that the user is an authorized user, as the flow of activity or biometric patterns may be used to establish the identity of the user and/or that the user of the primary device 401 owns both devices associated with the account holder.

Fig. 4C illustrates another scenario in which an additional communication device is used to increase the confidence that the user using the primary device 401 is an authorized user, according to some embodiments. The scenario in fig. 4C is similar to fig. 4B, except that the third communication device (which may be referred to as a "tertiary device") previously registered with the authorization server 480 acts as a user interface device for controlling or instructing the primary device 401. In fig. 4C, the user is initiating a request from tertiary device 413, rather than primary device 401, to authorize use of an account associated with the user. When a user initiates a request on tertiary device 413, tertiary device 413 establishes a connection with primary device 401 (if not already established) and instructs primary device 401 to send an authorization request to access device 460. When it is more convenient for a user to physically interact with tertiary device 412, or if primary device 401 does not have its own user interface, tertiary device 413 may be used, for example, to provide an alternative user interface available on primary device 401. The presence of the third communication means further increases the confidence that the user is an authorised user, as the user has three devices associated with the account holder.

As shown by example in fig. 4C, the role and function of requesting authorization to use an account may be distributed among multiple communication devices associated with the user. In some embodiments, a communication device may perform multiple functions at different times and assume different roles, depending on the capabilities of the communication device. For example, in one scenario, a smartphone may be used as a primary requestor device, with a fitness bracelet used as a secondary credential device. In another scenario, the smart watch may be used as a primary requester device, with the smart phone used as a secondary credential device, and vice versa. In another scenario, a smart watch may be used as a tertiary user interface device that controls a smartphone acting as a primary requester device, where the user's vehicle is used as a secondary credential device. Thus, it should be understood that although a particular communication device may be referred to as a primary device, a secondary device, or a tertiary device, the same communication device may assume different roles at different times. In other words, a particular communication device may act as any combination of one or more primary, secondary, or tertiary devices, and may provide any combination of one or more supplicant, credential, or user interface functions.

Enhanced authentication using secondary device assisted credential storage

In the scenarios shown in fig. 4B and 4C above, the secondary device is used to provide an indication of the presence of the user to increase the confidence that the request to use the account is from an authorized user. In some embodiments, the secondary device may provide enhanced authentication by facilitating secure account credential storage for the primary device. For example, device data of the secondary device may be used to encrypt the account credentials. The encrypted account credentials may be stored encrypted on the primary device or on the secondary device, or split and stored on both the primary and secondary devices. When the primary device communicates with the access device to request authorization to use the account, the primary device may obtain device data for the secondary device (and any account credentials stored on the secondary device). The primary device may then decrypt the account credentials using the device data of the secondary device and interact with the access device using the decrypted account credentials to request authorization to use the account.

Fig. 5 illustrates a communication flow diagram of a provisioning process for provisioning account credentials to a primary device interacting with a secondary device for secondary secure storage authentication, in accordance with some embodiments. The primary device 501 may establish a communication channel with the secondary device 512 to communicate with the secondary device 512. If the secondary device 512 has cryptographic capabilities, the communication channel may use end-to-end encryption to protect the information exchanged between the devices. If the secondary device 512 lacks cryptographic capabilities, the communication channel between the primary device 501 and the secondary device 512 may employ obfuscation techniques to protect the information exchanged between the devices. In some embodiments, communications between a primary device and a secondary device may be digitally signed by the corresponding device. The communication channel between the primary device 501 and the authentication server 580 may employ, for example, end-to-end encryption using a protocol such as opacity that does not require handshaking signals between the primary device and the authorization server to establish a secure communication channel.

At step 532, the secondary device 512 may transmit device data of the secondary device 512, such as a device ID, to the primary device 501. The device data may be received as part of a process to establish a communication channel between the primary device 501 and the secondary device 512, or the primary device 501 may establish a communication channel in response to requesting device data from the secondary device 512. At step 534, the primary device 501 may send a provisioning request to the authorization server 580 to request account credentials for the user's account. In some embodiments, authorization server 580 may be a token server that manages and provides tokens to communication devices. The provisioning request may include the device ID of the primary device 501, an account identifier for identifying the account for which account credentials are being requested, and device data, such as the device ID of the secondary device 512.

When authentication server 580 receives the provisioning request, authentication server 580 may verify that the account has a good reputation. If the account has a good reputation, the authentication server 580 may generate a shared key for the primary device 501 and account credentials for the account. In some embodiments, a protocol such as elliptic curve Diffie-Hellman may be used to generate the shared secret. The account credentials may include a token that may be used as a substitute for an account identifier and/or a cryptographic key that may be used by a primary device to generate a password when requesting authorization to use the account. In some embodiments, the cryptographic key may be a limited-use key associated with a set of one or more limited-use thresholds. When the usage of the limited-use key exceeds its limited-use threshold or thresholds, the limited-use key and the password generated with the limited-use key will no longer be valid and the new limited-use key should be supplemented from authentication server 580.

Once the shared key and account credentials are generated, the authentication server 580 may then generate a key encryption key from the shared key and the device data of the secondary device 512. For example, the key encryption key may be generated by encrypting device data (e.g., a device ID) of the secondary device 512 using a shared key. Authentication server 580 may then encrypt the generated account credentials (e.g., token and/or cryptographic key) using the key encryption key.

At step 536, the authentication server 580 sends the encrypted account credentials and the shared key associated with the primary device 501 to the primary device 501. At step 538, the primary device 501 stores the shared key on the primary device 501. In some embodiments, the primary device 501 may also store the encrypted account credentials or a portion of the encrypted account credentials (e.g., only the encrypted token, only the encrypted cryptographic key, a portion of the encrypted token, a portion of the encrypted cryptographic key, or portions of both) on the primary device 501. At step 540, any portion of the encrypted account credentials that are not stored on the primary device 501 are sent to the secondary device 512. At step 542, the secondary device 512 stores the encrypted account credentials (e.g., all or part) received from the primary device 501 on the secondary device 512. After the provisioning process is complete, the primary device 501 removes the device data (e.g., device ID) of the secondary device 512 from the memory of the primary device 501. In some embodiments, if the secondary device 512 can communicate directly with the authentication server 580, rather than using the primary device 501 to forward a portion of the account credentials (if any) to be stored on the secondary device 512 to the secondary device 512, the authentication server 580 may send the portion of the account credentials to be stored on the secondary device 512 directly to the secondary device 512, and may omit sending the portion of the account credentials to the primary device 501.

In some embodiments, the secondary device 512 may be provided asynchronously to the primary device 501. In other words, the secondary device 512 may be provided at a different time than the time the primary device 501 is provided. For example, the primary device 501 may store device data received from the secondary device 512 and send a provisioning request to the authorization server 580 at a later time when the primary device 701 is no longer communicatively connected to the secondary device 712. The primary device 501 may also store account credentials received from the authorization server 580 that are intended to be stored on the secondary device 512 until the primary device 501 reestablishes connectivity with the secondary device 512 at a later time. In some embodiments, the authorization server 580 may provide the secondary device 512 independently and separately from the primary device 501. Thus, in some embodiments, when the primary device 501 sends a provisioning request to the authorization server 580, the secondary device 512 may be provisioned without requiring an active connection to the primary device 501.

Fig. 6 illustrates a communication flow diagram for requesting authorization to use an account in which a secondary device provides a secondary credential store to a primary device, according to some embodiments. The primary device 601 may interact with the access device 660 to request authorization to use the account. The access device 660 may be a remote web server or a POS terminal in proximity to the primary device 601. In some embodiments, as part of the authentication process for verifying the primary device 601, the access device 660 may provide dynamic data related to a request for authorization to use an account associated with the user to the primary device 601 at step 632. The dynamic data may include information from the access device 660 that is used as input data for generating a password by the primary device 601. For example, the dynamic data may include unpredictable numbers from the access device 660. In embodiments where the request to authorize use of the account involves a transaction, the dynamic data may include transaction information, such as a transaction amount, from the access device 660.

At step 634, the primary device 601 may send a request for credential data of the secondary device 612 to the secondary device 612. The requested credential data of the secondary device 612 may include device data of the secondary device 612 used to generate a key encryption key, such as a device ID of the secondary device 612. At step 636, the secondary device sends the requested credential data to the primary device 601. As described above, the credential data of the secondary device 612 may include device data, such as a device ID of the secondary device 612. In embodiments where some or all of the encrypted account credentials (e.g., tokens and/or cryptographic keys) are stored on the secondary device 612, any encrypted account credentials stored on the secondary device 612 may also be provided to the primary device 601 as part of the credential data of the secondary device 612.

At step 638, after the primary device 601 receives the credential data of the secondary device 612, the primary device 601 may derive the key encryption key and decrypt the encrypted account credentials stored on the primary device 601 and/or received from the secondary device 612. For example, the primary device 601 may encrypt device data (e.g., a device ID) of the secondary device 612 using a shared key previously provided to the primary device 601 to derive a key encryption key. The primary device 601 may then decrypt any encrypted account credentials (e.g., token and/or cryptographic key) stored on the primary device 601 and any encrypted account credentials received from the secondary device 612 using the key encryption key to obtain an unencrypted token and/or unencrypted cryptographic key.

At step 640, the primary device 601 may generate a password used by the authorization server to authenticate the primary device 601. In embodiments where the access device 660 provides the dynamic data related to the authorization request at step 632, the primary device 601 may encrypt some or all of the dynamic data received from the access device 660 using a cryptographic key. In some embodiments, the data input to the password generation function may also include a count value that counts the number of usage account requests initiated by the one-time device 601. In embodiments where the primary device 601 is not required to encrypt dynamic data from the access device 660 for a request to authorize use of an account, the primary device 601 may encrypt a predetermined static string using a cryptographic key to generate a password.

At step 642, the primary device 601 transmits the token and generated password to the access device 660 to request authorization to use the account associated with the token. The access device 660 may then generate an authorization request message that includes the token, the password, and any dynamic data related to the request that the access device 660 previously provided to the primary device 601 at step 632. The access device 660 then sends an authorization request message to the authorization server to obtain authorization for the primary device 601 to use the account.

When the authorization server receives the authorization request message, the authorization server may convert the token back to the account identifier replaced by the token, determine the cryptographic key associated with the token provided to the primary device 601, and regenerate the password using the cryptographic key (e.g., by encrypting dynamic data related to the request, or by encrypting a predetermined string if dynamic data from the access device 660 is not used in the password generation). The authorization server may authorize use of the account if the regenerated password matches the password received from the primary device 601.

In some embodiments, the secondary device may not be available and may not be present when the primary device interacts with the access device. For example, if the secondary device is the user's vehicle, when the user leaves the vehicle and uses the user's smartphone as the primary device to conduct a transaction with an access device within a commercial store, the vehicle will not be in front of the smartphone when the mobile device interacts with the access device to request authorization to use the user's account. In such cases where the secondary device may not be in the presence of the primary device, the primary device may request and temporarily store credential data from the secondary device while the primary device is still communicatively coupled to the secondary device. The credential data of the secondary device may be stored for a predetermined period of time (e.g., 10 minutes, 15 minutes, 30 minutes, etc.), after which the credential data of the secondary device is automatically deleted from the primary device. In this way, the primary device may interact with the access device to request authorization to use the user's account without the secondary device having to be present with the primary device, as long as the interaction with the access device is performed within a predetermined time period for which the primary device obtains credential data for the secondary device.

In some embodiments, the credential data of the secondary device may be provided to a secure cloud storage (e.g., a remote server) for backup. Upon interaction between the primary device and the access device to request authorization to use the user's account, the primary device may send a request for credential data of the secondary device to the secure cloud storage if the primary device determines that the secondary device is not in front of or unavailable to the primary device. The secure cloud storage may send credential data of the secondary device to the primary device to enable the primary device to decrypt account credentials that may be needed by the primary device. In some embodiments, the secure cloud storage may require an enhanced authentication scheme, such as requesting a user to enter a PIN, password, or password on the primary device before providing credential data to the primary device.

The secondary device assisted credential storage techniques described above need not be limited to use with only one secondary device, and may also be extended to multiple secondary devices. In some embodiments, the primary device may be provisioned with a different set of account credentials (e.g., a token and/or cryptographic key) for each secondary device in a set of secondary devices registered with the authorization server. For example, a different token and/or a different cryptographic key may be generated by the authorization server for each secondary device. In embodiments where some or all of the account credentials are stored on the primary device, the account credentials provisioned for a particular secondary device may be stored on the primary device along with a hash of the device ID of the secondary device. A hash of the device ID may be used as an index to allow the primary device to correctly retrieve account credentials associated with a particular secondary device. In this manner, when the primary device requests credential data from a particular secondary device while interacting with the access device, the primary device may obtain the device ID of the secondary device, generate a hash of the device ID, and use the hash to view the appropriate set of account credentials associated with the particular secondary device stored on the primary device.

In some implementations, a single set of account credentials (e.g., a token and/or cryptographic key) may also be encrypted using key encryption keys derived from device data of multiple secondary devices. For example, the device data of the first secondary device may be combined with the device data of the second secondary device (e.g., using one or more mathematical operations such as addition and/or one or more logical operations such as XOR, or concatenated together), and a key encryption key may be generated by encrypting the combined device data of the plurality of secondary devices with a shared key. When the primary device interacts with the access device to request authorization to use the account, the primary device may request device data from each secondary device whose device data is used in the derivation of the key encryption key.

In some embodiments, a single set of account credentials may also be divided into multiple portions, and each portion may also be encrypted using a different key encryption key derived from device data of different secondary devices. For example, the token may be encrypted using a first key encryption key derived from device data of the first secondary device, and the cryptographic key may be encrypted using a second key encryption key derived from device data of the second secondary device. As another example, the token may be divided into two parts, and the first token part may be encrypted using a first key encryption key derived from the device data of the first secondary device, and the second token part may be encrypted using a second key encryption key derived from the device data of the second secondary device.

In some embodiments, the storage of different portions of the account credentials on a set of secondary devices may also be randomized, and the primary device may maintain a mapping of which portions are stored on which secondary devices so that the primary device may properly recover the account credentials. For example, a first portion of the account credential encrypted using a first key encryption key derived from device data of the first secondary device may be stored on the second secondary device, and a second portion of the account credential encrypted using a second key encryption key derived from device data of the second secondary device may be stored on the first secondary device. When the primary device requests credential data from two secondary devices, the first secondary device may provide the second portion of the account credential and the device data of the first secondary device to the first device, and the second secondary device may provide the first portion of the account credential and the device data of the second secondary device to the first device. The primary device having knowledge of the mapping of which portion of the account credentials is stored on which secondary device may then decrypt the portion of the account credentials received from the second secondary device using the device data received from the first secondary device and decrypt the portion of the account credentials received from the first secondary device using the device data received from the second secondary device.

Enhanced authentication using secondary device assisted encryption

In some embodiments, if the secondary device has cryptographic capabilities, the secondary device may also provide enhanced authentication by assisting cryptographic generation on behalf of the primary device. For example, during password generation, the primary device may generate a first intermediate password and transmit the first intermediate password to the secondary device. The secondary device may then generate a second intermediate password from the first intermediate password and send the second intermediate password back to the primary device. The primary device then generates a final password from the second intermediate password and transmits the final password to the access device to request authorization to use the user's account.

Fig. 7 illustrates a communication flow diagram of a provisioning process for provisioning account credentials to a primary device interacting with a secondary device for secondary cryptographic authentication, in accordance with some embodiments. The primary device 701 may establish a communication channel with the secondary device 712 to communicate with the secondary device 712. The communication channel may employ end-to-end encryption to protect information exchanged between the devices, or may employ obfuscation techniques to protect information exchanged between the devices. In some embodiments, communications between a primary device and a secondary device may be digitally signed by the corresponding device. The communication channel between the primary device 701 and the authentication server 780 may employ, for example, end-to-end encryption using a protocol such as opacity that does not require handshaking signals between the primary device and the authorization server to establish a secure communication channel.

At step 732, the secondary device 712 may transmit device data of the secondary device 712, such as a device ID, to the primary device 701. The device data may be received as part of a process to establish a communication channel between the primary device 701 and the secondary device 712, or in response to the primary device 701 requesting the device data from the secondary device 712. At step 734, the primary device 701 may send a provisioning request to the authorization server 780 to request account credentials for the user's account. In some embodiments, authorization server 780 may be a token server that manages and provides tokens to communication devices. The provisioning request may include the device ID of the primary device 701, an account identifier for identifying the account for which account credentials are being requested, and device data, such as the device ID of the secondary device 712.

When authentication server 780 receives the provisioning request, authentication server 780 may verify that the account has a good reputation. If the account has a good reputation, authentication server 780 may generate account credentials for the account. The account credentials may include a cryptographic key that may be used by the primary device to generate a password when requesting authorization to use the account. The cryptographic key may comprise a plurality of portions. For example, a cryptographic key may consist of two partial cryptographic keys. The account credentials may also include a token that may be used as a substitute for the account identifier. In some embodiments, the cryptographic key may be a limited-use key associated with a set of one or more limited-use thresholds. When the usage of the limited-use key exceeds its limited-use threshold or thresholds, the limited-use key and the password generated with the limited-use key will no longer be valid and a new limited-use key should be replenished from authentication server 780.

At step 736, the authentication server 780 sends the account credentials including the partial cryptographic key to the primary device 501. At step 738, the primary device 701 stores a first portion of the cryptographic key on the primary device 701. At step 740, the primary device 701 may send the second portion of the cryptographic key to the secondary device 712. At step 742, the secondary device 712 stores a second portion of the cryptographic key on the secondary device 512. In embodiments where the account credentials include a token, the token may be stored on the primary device 701 or the secondary device 712, or may be split and stored on both devices. In some embodiments, if the secondary device 712 can communicate directly with the authentication server 780, rather than using the primary device 701 to forward a portion of the account credentials to be stored on the secondary device 712 to the secondary device 712, the authentication server 780 can send a portion of the account credentials to be stored on the secondary device 712 directly to the secondary device 712, and sending the portion of the account credentials to the primary device 701 can be omitted.

In some embodiments, the secondary device 712 may be provided asynchronously to the primary device 701. In other words, the secondary device 712 may be provided with the second portion of the cryptographic key at a different time than the time the primary device 701 is provided with the first portion of the cryptographic key. For example, the primary device 701 may store the device data received from the secondary device 712 and send a provisioning request to the authorization server 780 at a later time when the primary device 701 is no longer communicatively connected to the secondary device 712. The primary device 701 may also store a second portion of the cryptographic key received from the authorization server 780, the second portion of the cryptographic key intended to be stored on the secondary device 712 until the primary device 701 reestablishes connectivity with the secondary device 712 at a later time. In some embodiments, the authorization server 780 may provide the secondary device 712 separately and apart from the primary device 701. Thus, in some embodiments, when the primary device 701 sends a provisioning request to the authorization server 780, the secondary device 712 may be provisioned without requiring an active connection to the primary device 701.

Fig. 8 illustrates a communication flow diagram for requesting authorization to use an account in which a secondary device provides secondary encryption to a primary device, according to some embodiments. The primary device 801 may interact with the access device 860 to request authorization to use an account. The access device 860 may be a remote web server or a POS terminal in proximity to the primary device 801. In some embodiments, as part of the authentication process for verifying the primary device 801, at step 832, the access device 860 may provide the primary device 801 with dynamic data related to the request for authorization to use the account. The dynamic data may include information from the access device 860 that is used as input data for generating a password by the primary device 801. For example, the dynamic data may include unpredictable numbers from the access device 860. In embodiments where the request to authorize use of the account involves a transaction, the dynamic data may include transaction information, such as a transaction amount, from the access device 860.

At step 834, the primary device 801 may generate a first intermediate password using a first portion of the cryptographic key stored on the primary device 801. For example, the primary device 801 may perform one or more cryptographic operations (e.g., encryption/decryption) on some or all of the dynamic data received from the access device 860 using a first portion of a cryptographic key stored on the primary device 801. In some embodiments, the data input to the cryptographic function may also include a count value that counts the number of usage account requests that have been initiated by the primary apparatus 801. In embodiments where the request to authorize use of the user's account does not require the primary device 801 to generate a password based on dynamic data received from the access device 860, the primary device 801 may perform one or more cryptographic operations on a predetermined static string using a first portion of a password key stored on the primary device 801 to generate a first intermediate password.

At step 836, the primary device 801 sends a first intermediate password 836 to the secondary device 812. At step 838, the secondary device 812 may generate a second intermediate password from the first intermediate password using the second portion of the cryptographic key stored on the secondary device 812. For example, secondary device 812 may perform one or more cryptographic operations on the first intermediate password using the second portion of the cryptographic key to generate a second intermediate password. At step 840, the secondary device 812 sends a second intermediate password to the primary device 801.

At step 842, the primary apparatus 801 may generate a final password from the second intermediate password using the first portion of the cryptographic key stored on the primary apparatus 801. For example, the primary apparatus 801 may perform one or more cryptographic operations on the second intermediate password using the first portion of the cryptographic key to generate the final password. At step 844, the primary device 844 sends the final password and any additional account credentials (e.g., token) needed to the access device 860 to request authorization to use the user's account. The access device 860 may then generate an authorization request message that is sent to an authorization server to obtain authorization to use the user account in accordance with the techniques described herein.

Fig. 9 illustrates a conceptual diagram of an example technique for generating a password by a primary device cooperating with a secondary device, according to some embodiments. The encryption protocol used for the encryption and decryption operations may be, for example, DES (data encryption standard), AES (advanced encryption standard), or other suitable encryption/decryption algorithms.

The cryptographic key provided from the authorization server may be split into a first part K1 and a second part K2. For example, if the cryptographic key is 16 bytes, K1 may be the first 8 bytes of the cryptographic key and K2 may be the last 8 bytes of the cryptographic key. A first portion of the cryptographic key K1 may be provided to the primary device 901 and a second portion of the cryptographic key K2 may be provided to the secondary device 912. In some embodiments, the first intermediate key K3 and the second intermediate key K4 may also be provided to both the primary device 901 and the secondary device 912.

Primary device 901 may begin the password generation process by obtaining input data to the password function (e.g., dynamic data received from an access device, a predetermined static string from memory, etc.). The first intermediate cryptogram C1 may be generated by encrypting the input data with a first portion of the cryptographic key K1, decrypting the first result with a first intermediate key K3, and then re-encrypting the second result with a second intermediate key K4. The first intermediate password C1 is then provided to the secondary device 912.

The secondary device 912 then generates a second intermediate cryptogram C2 from the first intermediate cryptogram C1 received from the primary device 901. In some embodiments, the second intermediate cipher C2 may be generated by decrypting C1 with the second intermediate key K4, encrypting this first result with the first intermediate key K3, and then decrypting this second result with the second portion of the cipher key K2. The second intermediate password C2 is then provided to the primary device 901, and the primary device 901 may generate the final password C sent to the access device by encrypting C2 with the first part of the password key K1.

In some embodiments, for greater transmission protection, the second intermediate cipher C2 may be generated by decrypting C1 with the second intermediate key K4, encrypting this first result with the first intermediate key K3, decrypting this second result with the second portion of the cipher key K2, re-encrypting this third result with the second intermediate key K4, and then decrypting this fourth result again with the first intermediate key K3. In such embodiments, the primary device 901 may generate the final password C sent to the access device by encrypting C2 with the first intermediate key K3, decrypting this first result with the second intermediate key K4, and then re-encrypting this second result with the first portion of the password key K1.

V. exemplary procedure

Fig. 10 illustrates a flow diagram of a process 1000 for establishing an interactivity mode associated with a primary device, according to some embodiments. The process 1000 may be repeated for each communication device (e.g., secondary device or tertiary device) interacting with the primary device. At block 1002, a communication channel is established between a primary device and a communication device interacting with the primary device. At block 1004, the primary device may receive device data from the communication device including at least one of a device ID of the communication device, sensor data sensed by the communication device, or user data captured by the communication device. At block 1006, device data received from the communication device is sent to the server to establish an interactivity mode at the server. Device data of the primary device (e.g., device ID of the primary device, sensor data sensed by the primary device, or user data captured by the primary device) may also be sent to the server to establish the interactivity mode.

In some embodiments, a timestamp may be sent with the device data to allow the server to associate an interaction between a primary device and a communication device with a time period of the day. Thus, the interactivity mode may be further established based on the time of day that the primary device interacted with the respective communication device. In some embodiments, the device data may include location data of the communication device and/or the primary device, and the location data may be used to derive a geographic perimeter representing a geofence around a location typically visited by the user. The pattern of interaction activities including the derived geographic surroundings may be used to provide a risk assessment as to whether a primary device attempting to request authorization to use an account is operating in a manner consistent with typical behavior of a user.

Fig. 11 illustrates a flow diagram of a process 1100 for requesting authorization to use an account of a user of a primary device, according to some embodiments. At block 1102, the primary device may receive credential data for the secondary device. The credential data may be, for example, device data, such as a device identifier of the secondary device or an intermediate password generated by the secondary device. In some embodiments, the credential data may include account credentials (e.g., a full or partial token, and/or a full or partial cryptographic key) associated with an account of the user stored on the secondary device. At block 1104, the primary device generates a password using credential data of the secondary device.

At block 1106, the primary device transmits a password to the access device to request authorization to use an account associated with a user of the primary device. The request to authorize use of the account may be, for example, a request to access information about the account, a request to use the account to access a service or product, a request to use the account to conduct a transaction, etc. In some embodiments, the access device may be a remote network server and the password may be transmitted to the access device over a computer network such as the internet. In some embodiments, the access device may be an access terminal such as a POS terminal located near the primary device, and the password may be communicated to the contactless reader of the access terminal using short or medium-type contactless communication technology (e.g., NFC, bluetooth, BLE, etc.) or by presenting an image representing the password (e.g., a QR code, barcode, etc.) to the optical reader of the access terminal.

In some embodiments, the access device may forward the password to the authorization server. Use of the account may be authorized based on authentication of the password and an interactivity pattern of interactions between the primary device and a set of communication devices including the secondary device. For example, the authorization server may compare the most recent interactions between the primary device and one or more of the communication devices to the pattern of interactivity to determine whether the primary device is being used in a manner consistent with the typical behavior of the user and/or at a location consistent with the location of the typical activity of the user. In some embodiments, if the password is verified and the primary device is used in a manner consistent with the interactive activity pattern, the user of the primary device is likely an authorized user and authorization to use the account may be granted without limitation. In some embodiments, if the password is verified and the primary device appears to be being used in a manner that deviates from the interactive activity pattern, authorization to use the account may still be granted, but with restrictions on how the account may be used. For example, a limit on the amount of transactions may be imposed in such a scenario.

Fig. 12 illustrates a flow diagram of a process 1200 for secondary credential storage by a secondary device to enhance authentication of a primary device, according to some embodiments. At block 1202, to register a secondary device interacting with a primary device and request provisioning of the primary device and the secondary device, the primary device may transmit device data (such as a device ID of the secondary device) to an authorization server. At block 1204, in response to registering the secondary device, the primary device may receive a shared key and an encrypted cryptographic key from an authorization server. In some embodiments, the primary device may also receive an encrypted token. The encrypted cryptographic key and/or the encrypted token may be encrypted by the authorization server using a key encryption key derived from the shared key and the device data of the secondary device.

At block 1206, the primary device stores the shared key on the primary device. In some embodiments, the encrypted cryptographic key and/or encrypted token may also be stored on the primary device. In some embodiments, the primary device may forward the encrypted cryptographic key and/or the encrypted token to the secondary device for storage on the secondary device. In some embodiments, a portion of the encrypted cryptographic key and/or a portion of the encrypted token may be stored on the primary device and the remainder of the encrypted cryptographic key and/or the remainder of the encrypted token may be stored on the secondary device.

Once the primary and secondary devices have been provisioned, the primary device may interact with the access device to request authorization to use an account associated with the user of the primary device. At block 1208, the primary device may receive credential data for the secondary device. The credential data may include device data of the secondary device used to derive a key encryption key, such as a device ID of the secondary device. The primary device may also receive the encrypted cryptographic key and/or the encrypted token from the secondary device as part of the credential data of the secondary device if any part of the encrypted cryptographic key and/or the encrypted token is stored on the secondary device.

The primary device may then derive a key encryption key using the device identifier of the secondary device and a shared key stored on the primary device at block 1210. At block 1212, the primary device decrypts the encrypted cryptographic key and/or the encrypted token using the derived key encryption key. At block 1214, the primary device generates a password by encrypting data related to the authorization request using the decrypted password key. In some embodiments, the data associated with the authorization request may include dynamic data received from the access device. In some embodiments, the data associated with the authorization request may include a predetermined static string. At block 1216, the primary device transmits a password to the access device to request authorization to use the user's account.

In some embodiments, the presence of a secondary device may not be required when the primary device interacts with the access device. For example, credential data, such as a device ID of the secondary device, may be received by the primary device from the secondary device in advance before the primary device interacts with the access device to request authorization. Credential data such as a device ID of the secondary device may be temporarily stored on the primary device for a predetermined period of time. This will allow the primary device to interact with the access device to request authorization without the presence of the secondary device if the primary device interacts with the access device within a predetermined time period during which the credential data of the secondary device is received by the primary device. The credential data may be automatically deleted from the primary device when a predetermined period of time has elapsed since receipt of the credential data to prevent continued storage of the credential data on the primary device. In some embodiments, the primary device may also send a request for credential data of the secondary device to a remote server if the primary device determines that the secondary device is not available, and the credential data of the secondary device may be received by the primary device from the remote server.

Fig. 13 illustrates a flow diagram of a process 1300 for secondary encryption by a secondary device to enhance authentication of a primary device, according to some embodiments. At block 1302, to register a secondary device interacting with a primary device and request provisioning of the primary device and the secondary device, the primary device may transmit device data (such as a device ID of the secondary device) to an authorization server. At block 1304, the primary device may receive a cryptographic key from an authorization server in response to registering the secondary device. The cryptographic key may be divided into a first portion and a second portion. In some embodiments, the primary device may also receive a token. At block 1306, the primary device stores a first portion of the cryptographic key on the primary device. At block 1308, the primary device sends the second portion of the cryptographic key to the secondary device for storage on the secondary device. The primary and secondary devices may also be provided with a first intermediate key and a second intermediate key.

Once the primary and secondary devices have been provisioned, the primary device may interact with the access device to request authorization to use an account associated with the user of the primary device. At block 1310, to request authorization to use the account, the primary device may generate a first intermediate password using a first portion of a password key stored on the primary device. The first intermediate password may be generated by encrypting data associated with the authorization request using a first portion of the cryptographic key, decrypting the encrypted data using a first intermediate key, and re-encrypting the decrypted data using a second intermediate key. At block 1312, the primary device transmits the first intermediate password to the secondary device.

At block 1314, the primary device receives a second intermediate passcode generated by the secondary device using the first intermediate passcode and a second portion of the cryptographic key stored on the secondary device. The second intermediate password may be received by the primary device as credential data for the secondary device. In some embodiments, the secondary device may generate the second intermediate password by decrypting the first intermediate password using the second intermediate key, re-encrypting the decrypted first intermediate password using the first intermediate key, and decrypting the re-encrypted first intermediate password using the second portion of the cryptographic key. For greater transmission protection, the second intermediate password may be generated by further encrypting a result of decrypting the re-encrypted first intermediate password using the second intermediate key, and decrypting the encrypted result using the first intermediate key.

At block 1316, the primary device generates a password to send to the access device using the second intermediate password and the first portion of the cryptographic key stored on the primary device. In some embodiments, the cipher may be generated by encrypting a second intermediate cipher using the first intermediate key, decrypting the encrypted second intermediate cipher using the second intermediate key, and re-encrypting the decrypted second intermediate cipher using the first portion of the cipher key. At block 1318, the primary device transmits a password to the access device to request authorization to use the user's account.

Exemplary devices and systems

Fig. 14 illustrates a block diagram of a portable communication device 1401 in which some embodiments of the processes described herein may be implemented. The portable communication device 1401 may function as a primary device that interacts with an access device (e.g. via a contactless interface or via a network), as a communication hub that communicates with a different communication device, as a secondary device that assists in enhanced authentication by another communication device, and/or as a tertiary device that functions as a user interface to control or communicate with the primary device.

The portable communication device 1401 may include device hardware 1404 coupled to memory 1402. The device hardware 1404 may include a processor 1405, a communication subsystem 1409, a user interface 1406, a display 1407 (which may be part of the user interface 1406), and a contactless interface 1408. The processor 1405 may be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and/or microcontrollers) and is used to control the operation of the portable communication device 1401. The processor 1405 may execute various programs in response to program code or computer readable code stored in the memory 1402, and may maintain multiple concurrently executing programs or processes. The communications subsystem 1406 may include one or more RF transceivers and/or connectors that may be used by the portable communication device 1401 to communicate with other devices and/or to connect to an external network. The user interface 1406 may include any combination of input elements and output elements to allow a user to interact with and invoke the functionality of the portable communication device 1401. In some embodiments, the display 1407 may be part of the user interface 1406.

The contactless interface 1408 may include one or more RF transceivers to interact with a contactless reader of an access device to conduct transactions (e.g., payment transactions, access transactions, information exchanges, etc.). In some embodiments, the contactless interface 1408 may be accessed by the mobile OS 1414 using the card emulation API 1416 without the use of a secure element. In some embodiments, display 1407 may also be part of contactless interface 1408 and used, for example, to perform transactions using QR codes, bar codes, and the like.

The memory 1402 may be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or combination thereof. Memory 1402 may store a mobile OS 1414 and a mobile application environment 1410 in which one or more mobile applications reside, including a transaction application 1412 (e.g., a mobile wallet application, a mobile banking application, a mobile payment application, a merchant application, a web browser, etc.) to be executed by processor 1405. In some embodiments, the mobile OS 1414 may implement a set of card emulation APIs 1416 that may be invoked by the transaction application 1412 to access the contactless interface 1408 to interact with the access device.

According to some embodiments, the transaction application 1412 may implement security-sensitive functions, such as a token request function 1434, an account parameter supplementation function 1436, a password generation function 1438, and so on. Token request function 1434 may be invoked to request a token from a remote server (e.g., an authorization server such as a cloud-based transaction server, token server, issuer, or host processing system). The token may be used as a substitute for the real account identifier to conduct the transaction (e.g., by sending the token to the access device). Using a token instead of a real account identifier may be more secure because the real account identifier is not transmitted when the transaction is conducted. Token request function 1434 may be invoked, for example, at registration time to request an initial token, or upon expiration of the lifetime of a current token.

Account parameter supplementing function 1436 may be invoked to supplement or update account parameters, such as limited-use keys, from a remote server (e.g., an authorization server such as a cloud-based transaction server, token server, issuer, or host processing system). At the time of the transaction, the limited-use key is used to generate a password that is provided to the access device to conduct the transaction. The limited-use key may be associated with a set or one or more limited-use thresholds (e.g., valid for a predetermined period of time, for a predetermined number of transactions, and/or for a predetermined cumulative transaction amount) to limit use of the LUKs. When one or more of the limited-use thresholds for a LUK have expired or are about to expire, the account parameter replenishment function 1436 may be invoked to request a new LUK.

Password generation function 1438 may be invoked at transaction time to generate a password that is provided to the access device to conduct a transaction. The password may be generated by receiving dynamic transaction data (e.g., transaction amount, transaction date, unpredictable number, etc.) from the access device and encrypting the dynamic transaction data with the LUK. In some embodiments, the password may be generated by encrypting the static string with the LUK (e.g., if the access device does not support the transmission of dynamic data to the portable communication device).

In some embodiments, the transaction application 1412 may be automatically activated and ready to conduct a transaction with an access device if the portable communication device 1401 is used in accordance with the interactivity mode of 1401, and/or if a secondary device may provide additional assurance that the portable communication device 1401 is being used by an authorized user. For example, the transaction application 1412 may be activated if the portable communication device 1401 is interacting with a secondary device that typically interacts with the portable communication device 1401 during a particular time of day and/or if the portable communication device 1401 is located at a location within the geographic vicinity of the location where the user typically resides during a particular time of day. In some embodiments, the transaction application 1412 may be activated if the secondary device may provide contextual data (e.g., heart rate or other biometric data) to indicate the presence of the user with the portable communication device 1401. In some embodiments, the transaction application 1412 may be activated if credential data for the secondary device is available to the portable communication device 1401 (e.g., if the secondary device is in front of the portable communication device 1401, or if the portable communication device 1401 has recently acquired and temporarily stored the necessary credential data for the secondary device to conduct a transaction).

Fig. 15 shows a block diagram of a network-connected communications device 1501 in which some embodiments of the processes described herein may be implemented. The network-connected communication device 1501 may function as a primary device that interacts with an access device (e.g., via a network), as a communication hub that communicates with different communication devices, as a secondary device that assists another communication device in enhanced authentication, and/or as a tertiary device that functions as a user interface to control or communicate with the primary device. In some embodiments, the network-connected communication device 1501 may be an access point device, a router device, a gateway device, a network-connected intelligent appliance device (such as a set-top box, a smart TV, an intelligent refrigerator), or the like.

The network-connected communications device 1501 may include a processing subsystem 1520, one or more network interfaces 1509, and a transaction application 1512. Processing subsystem 1520 may be implemented as one or more integrated circuits, such as one or more processors and/or controller 1505 and/or one or more processing subsystem memories 1502. In operation, the processing system 1520 may control the operation of the network connected communication device 1501. In some embodiments, processing subsystem 1520 may execute various programs and/or processes in response to program code or instructions, and may maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code or instructions to be executed by the one or more processors/controllers 1505 may reside within the processing subsystem 1520, such as within the processing subsystem memory 1502. Each processor/controller 1505 may be implemented as a microprocessor, digital signal processor, application specific integrated circuit, field programmable gate array, analog circuitry, digital circuitry, and/or combinations thereof.

Network interface 1509 may include one or more internal network interfaces and/or one or more external network interfaces to facilitate exchange of communications within an internal network (e.g., a local area network, etc.), an external network, and/or between an internal network and an external network. In some embodiments, the network-connected communication device 1501 may interact with different communication devices at different times via the network interface 1509, or may simultaneously interact with multiple communication devices at the same time.

The transaction application 1512 may be implemented to have functionality similar to those described with reference to the transaction application 1412, and thus, detailed descriptions thereof need not be repeated. The transaction application 512 may enable the network-connected communication device 1501 to operate as a primary device to conduct transactions with an access device. In some embodiments, the transaction application 1512 may be stored in the processing subsystem memory 1502 or in general purpose memory of the network-connected communication device 1501.

Fig. 16 shows a block diagram of a communication device 1601 in which some embodiments of the processes described herein may be implemented. In some implementations, the communication device 1601 may lack a transaction application and thus may not be able to directly conduct transactions with the access device. However, in some embodiments, the communication device 1601 may function as a communication hub to communicate with different communication devices, as a secondary device to assist in enhanced authentication by another communication device, and/or as a tertiary device to function as a user interface to control or communicate with a primary device. In some embodiments, the communication device 1601 may be a wearable communication device, a smart home device, a vehicle, or the like.

The communication device 1601 may include a controller or processor 1605, a memory 1602 for storing instructions executable by the controller or processor 1605, and a communication subsystem 1609 for interacting with other communication devices. The communication device 1601 may also include a user interface 1606 that may be used to control the communication device 1601 or another device communicatively coupled to the communication device 1601. The user interface may include a display (e.g., a touch screen) and/or any number of buttons or input devices, such as a keyboard, keypad, etc., that the user may engage in invoking functions of the communication device 1601 and/or another device communicatively coupled to the communication device 1601.

The communication device 1601 may also include a sensor subsystem 1603. The sensor subsystem 1603 can include any number of environmental sensors, such as various electronic, mechanical, electromechanical, optical, or other devices that provide information related to external conditions around the communication device 1601. In some embodiments, sensor subsystem 1603 may provide digital signals to controller or processor 1605, e.g., on a streaming media basis or in response to polling by controller or processor 1605 as needed. Examples of environmental sensors may include accelerometers, magnetometers, altimeters, gyroscopes, satellite positioning receivers (e.g., GPS receivers), and the like. In some embodiments, sensor subsystem 1603 may also include sound sensors, light sensors, cameras, microphones, and the like. In some embodiments, the sensor subsystem may also include a biometric sensor, such as a heart rate sensor, a fingerprint sensor, or the like.

Fig. 17 illustrates a block diagram of an exemplary system 1700 in which the enhanced authentication techniques described herein may be used, according to some embodiments. The system 1700 may be, for example, a cloud-based transaction system for conducting cloud-based transactions. It should be understood that the enhanced authentication techniques described herein may be applied to other types of systems that may or may not be related to transaction processing.

The system 1700 includes a portable communication device 1710 (e.g., a mobile device), a cloud-based transaction platform (CBP)1780, and a Mobile Application Platform (MAP) 1770. CBP 1780 may be implemented using one or more computing devices and may be associated with or operated by an issuer, a transaction processor, and/or other suitable entity. The CBP 1780 implements a set of functionalities including account management and account parameter generation and supplementation to enable cloud-based transactions via the portable communication device 1710.

The MAP 1770 is used to facilitate communication between the CBP 1780 and a mobile application 1714 (e.g., a transaction application) in the portable communication device 1710. The MAP 1770 may be implemented using one or more computing devices, and may be associated with or operated by a service provider (such as an issuer, a mobile wallet provider, a merchant, and/or other suitable entity) of a mobile application 1714 (e.g., a mobile software application). In some embodiments, MAP 1770 may be associated with or operated by the same entity as CBP 1780, or they may be separate. MAP 1770 is used to mediate requests between mobile applications 1714 and CBP 1780 and ensure that requests and responses initiated by either party are fulfilled once connectivity is established to portable communication device 1710, e.g., via communication network 1782 (e.g., the internet, mobile or cellular network, etc.). It is to be appreciated that in some embodiments, one or more functionalities of the CBP 1780, MAP 1770, and/or issuer or host processing system 1772 may be integrated into the same computing system or different computing systems. In some embodiments, any one or more of the CBP 1780, MAP 1770, and/or issuer or host processing system 1772 may act as an authorization server.

The portable communication device 1710 may be used to conduct cloud-based transactions (e.g., payment transactions) facilitated by the CBP 1780 and/or the MAP 1770. Portable communication device 1710 includes device hardware 1732, a mobile Operating System (OS)1722, and an application environment 1712. Device hardware 1732 includes a contactless interface 1734 that can contactlessly communicate or otherwise present information to another device, such as a contactless reader 1062 of an access device 1760. Examples of contactless interface 1734 may include a Near Field Communication (NFC) interface, which may send and receive communications using radio frequencies or other wireless communication protocols such as bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, and so forth. Examples of contactless interface 1734 may also include an optical interface, such as a display for presenting information, such as a Quick Response (QR) code, barcode, and so forth.

The application environment 1712 of the portable communication device 1710 can include a mobile application 1714, such as a transaction application provided by a service provider (e.g., an issuer). For example, if the service provider of mobile application 1714 is an issuer, mobile application 1714 may be a mobile banking application or a mobile payment application. If the service provider is a mobile wallet provider (such as a mobile network operator or a third party wallet provider that supports multiple issuers), the mobile application 1714 may be a mobile wallet application. As for merchants, the mobile application 1714 may be a merchant's own transaction application from which consumers may conduct e-commerce or point-of-sale transactions, or a mobile wallet application that supports multiple merchants.

In some embodiments, the mobile application 1714 may include cloud-based transaction logic on a device integrated into the mobile application 1714 to support cloud-based transactions. The cloud-based transaction logic on the device executes functions to facilitate cloud-based transactions, such as obtaining account parameters provided for use in payment transactions and delivering them to the mobile operating system 1722 for transmission over the contactless interface 1734. For example, the cloud-based transaction logic on the device may use a cryptographic key (e.g., limited use key) provided from the CBP 1780 to generate a transaction password that is transmitted over the contactless interface to the access device 1760 in order to conduct the payment transaction. The transaction password may be sent to the transaction processing network 1784 to obtain authorization for the payment transaction. The cloud-based transaction logic on the device also manages initial service profile parameters that are provided after the account has been provisioned to ensure that requests for account parameter replenishment and other account parameter management activities are initiated.

To provide portable communication device 1710 for use in cloud-based payment transactions, CBP 1780 may be used to configure an account portfolio (portfolio) associated with an issuer and provide account parameters to portable communication device 1710 for use in conducting cloud-based transactions. The account portfolios established by the CBP 1780 may include characteristics such as risk parameters (e.g., rate control) that govern the triggers when account parameters on provisioned devices will need to be refreshed for accounts in each portfolio. To ensure consistent performance and availability, a set of minimum parameters that are configurable in the service profile may be enforced by CBP 1780. To ensure that cloud-based payment transactions are processed according to the rules specified in the service profile of the account portfolio, CBP 1780 performs various core functions during the lifetime of an account that has been enabled. These functions may include provisioning, active account management, confirmation of payment, transaction processing, lifecycle management, and post-payment systems.

Before the account is provisioned as a cloud-based transaction account, CBP 1780 may create a service profile for the portfolio. Provisioning may include obtaining a registered account, creating account information, such as an alternate account identifier (e.g., an alternate Primary Account Number (PAN)), or a token that acts as an account identifier substitute that can be used to conduct transactions in place of an actual account identifier (e.g., an actual PAN), and having established an inherited service profile for a portfolio. Once the account is provisioned, relevant service profile details are shared with both the transaction process and the cloud-based transaction logic on the device to ensure that decisions can be made at the time of transaction processing and during the user's use of the mobile application.

Once the account is provisioned, active account management may be performed by the CBP 1780. Active account management may be initiated from a transaction processing activity or from a mobile application activity. After the account has been provisioned, the active account management capability generates an initial set of account parameters to be deployed to the portable communication device 1710. The account parameters may include account information (e.g., alternative account identifiers or tokens) generated during provisioning, as well as dynamic information to ensure that the set of account parameters has only limited use or limited lifetime once delivered to the device. Depending on which type of transaction is supported, the dynamic information may include limited use cryptographic keys or dynamic data. For example, the dynamic information may include a Limited Use Key (LUK) for computing a password and limited use dynamic data for supporting legacy dynamic card authentication values or code-based implementations.

During transaction processing, if the service profile parameters reserved by CBP 1780 for a particular account indicate that account parameters on portable communication device 1710 require replacement, the active account management capabilities of CBP 1080 may connect to portable communication device 1710 via MAP 1770 to supplement the account parameters. Likewise, if the on-device service profile parameters stored on the portable communication device 1710 indicate that account parameter replenishment is needed or soon to be needed (i.e., by monitoring account parameter thresholds), the mobile application 1714 may request account parameter replenishment from the CBP 1780.

Once the portable communication device 1710 has been provided to conduct a cloud-based transaction, the transaction may be conducted via the portable communication device 1710 by interacting with a contactless reader 1762 of an access device 1760 (e.g., at a merchant location). The components of the access device 1760 may include a point-of-sale (POS) terminal 1764 and/or an electronic cash register 1766. In some embodiments, access device 1760 may be a web server associated with a merchant, and portable communication device 1710 may communicate with access device 1760 via a computer network. The access device 1760 may be coupled to an acquirer 1774 (e.g., via a merchant computer not shown). The acquirer 1774 may be connected to the issuer or host processing system 1772 via a transaction processing network 1784. The transaction processing network 1784 may include one or more server computers. A server computer is typically a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers that function as a unit. In one example, the server computer may be a database server coupled to a network server. The transaction processing network 1084 may use any suitable wired or wireless network, including the internet.

The transaction processing network 1784 may include data processing subsystems, networks, and operations to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing network may include VisaNet^TM. Such as VisaNet^TMCan process credit card transactions, debit card transactions, and other types of commercial transactions. Visanet^TMSpecifically including a VIP system (Visa integrated payment system) that processes authorization requests and a Base II system that performs clearing and settlement services.

Each entity (e.g., acquirer 1774, transaction processing network 1784, issuer, or host processing system 1772) may include one or more computers to enable communication or perform one or more of the functions described herein.

To conduct a cloud-based transaction, a user of the portable communication device 1710 may cause the portable communication device 1710 to tap a contactless reader 1762 of an access device 1760 (e.g., via NFC), or display an image (such as a barcode or QR code) on a screen of the portable communication device 1710 that may be scanned by the contactless reader 1762 of the access device 1760 (e.g., an optical scanner or reader). In some embodiments, the portable communication device 1710 may provide the access device 1760 with an account identifier (e.g., an alternative account identifier, a token, etc.) and additional information, such as limited-use account parameters or information derived from limited-use account parameters. For example, the account identifier or token and/or additional information (e.g., a transaction password) may be encoded with a barcode or QR code scanned by the access device 1760; or the account identifier or token and/or additional information may be transmitted to the accessing device 1760 via NFC. In some embodiments, the limited use account parameters may include a transaction password

The access device 1760 or a merchant computer coupled to the access device 1760 may generate an authorization request message including an account identifier and additional information (e.g., limited-use account parameters or information derived from limited-use account parameters) and forward the authorization request message to the acquirer 1774. The authorization request message is then sent to the transaction processing network 1784. The transaction processing network 1784 then forwards the authorization request message to the corresponding issuer or host processing system 1772 associated with the issuer of the account (associated with the portable communication device 1710).

After the issuer or host processing system 1772 receives the authorization request message, the authorization request message may be parsed and the information in the authorization request message may be sent to CBP 1780 for verification. An authorization response message is then sent back to the transaction processing network 1784 to indicate whether the current transaction is authorized (or unauthorized). The transaction processing network 1784 then forwards the authorization response message back to the acquirer 1774. In some embodiments, the transaction processing network 1084 may deny the transaction even if the issuer or host processing system 1772 has authorized the transaction, e.g., depending on the value of the fraud risk score or depending on whether the limited-use account parameters were verified by the CBP 1780. The acquirer 1774 then sends an authorization response message to the merchant computer and/or the access device 1760. The authorization response result may be displayed by the access device 1760 or may be printed on the physical receipt. Alternatively, if the transaction is an online transaction, the merchant may provide a web page or other indication of an authorization response message as a virtual receipt. The receipt may include transaction data for the transaction.

At the end of the day, conventional clearing and settlement processes may be performed by the transaction processing network 1784. The clearing process is a process of exchanging financial details between an acquirer and an issuer to facilitate distribution to a customer's payment account and to check a user's settlement location.

Any of the computing devices, communication devices, computers, servers, etc., described herein may be implemented using one or more processors coupled to memory, the memory storing code or instructions that when executed by the one or more processors cause the devices to perform one or more of the methods and processes described herein. The memory, storage media, and computer-readable media used to contain the code or code portions described herein may include any suitable media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information (such as computer-readable instructions, data structures, program modules, or other data), including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium which can be used to store or transmit the desired information and which can be accessed by a computer.

The methods and processes described herein are exemplary in nature, and methods and processes according to some embodiments may perform one or more steps in an order different than that described herein, include one or more additional steps not specifically described, omit one or more steps, combine one or more steps into a single step, divide one or more steps into multiple steps, and/or any combination thereof.

Any of the software components or functions described herein may be implemented as software code executed by a processor using any suitable computer language, such as, for example, Java, C + + or Perl, using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium, such as a Random Access Memory (RAM), a Read Only Memory (ROM), a magnetic medium, such as a hard disk or a floppy disk, or an optical medium, such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computing device, and may be located on or across different computing devices in a system or network.

One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

The recitation of "a", "an" and "the" is intended to mean "one or more" unless explicitly indicated to the contrary.