Enhanced authentication based on secondary device interaction

Abstract

The enhanced authentication technique may include receiving, by a primary device, credential data of a secondary device, generating a password using the credential data of 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 verification of the password and an interactive activity pattern of interactions between the primary device and a group of communication devices including the secondary device.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2016 / 027344, international application date April 13, 2016, application number 201680021444.0 entering the Chinese national phase, and name “Enhanced Authentication Based on Secondary Device Interaction”.

[0002] Cross-reference to related applications

[0003] This application claims priority to U.S. Provisional Patent Application No. 62 / 146,881, filed on April 13, 2015, entitled “Enhanced Authentication Based on Secondary Device Interactions,” which is incorporated herein by reference in its entirety for all purposes. Background Art

[0004] Advances in communication technology have allowed virtually any type of device to be enabled using network connectivity. At the same time, the performance of both portable devices and home devices has 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 security-sensitive information to access a user's account. Due to the network-connected nature of such devices, it has also become easy for unauthorized parties to gain access to such devices and the security-sensitive information stored therein. Therefore, it is necessary to provide stronger authentication for such devices to ensure that the user operating the device is an authorized user of the device.

[0005] Embodiments of the present invention address these and other problems individually and collectively. Summary of the invention

[0006] Embodiments of the present invention provide enhanced authentication techniques to authenticate communication devices. In some embodiments, a user may operate a communication device to perform security-sensitive functions. By providing a more powerful authentication scheme to authenticate a communication device, the confidence that a user performing security-sensitive functions through a 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, the latest interactions between a communication device and other devices may be compared with historical interaction activity patterns to provide a risk assessment of whether the communication device is being used in a manner consistent with the user's typical behavior. In some embodiments, a communication device may also utilize interactions with other devices to securely store account credentials and / or utilize the capabilities of other devices to perform cryptographic operations to authenticate the communication device.

[0007] 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 verification of the password and an interactive activity pattern of interaction between the primary device and a group of communication devices including the secondary device.

[0008] According to some embodiments, the credential data of the secondary device may include a device identifier of the secondary device. The primary device may derive a key encryption key using the 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 for authorization using the decrypted cryptographic key to generate a password.

[0009] According to some embodiments, the credential data of the secondary device may include an intermediate password. The primary device may generate a first intermediate password using a first portion of a cryptographic key stored on the primary device, and transmit the first intermediate password to the secondary device. The secondary device may generate a second intermediate password (as credential data) by using the first intermediate password and a second portion of a cryptographic key stored on the secondary device, and transmit 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.

[0010] According to some embodiments, the communication device may include a processor and a memory storing computer-readable instructions for implementing enhanced authentication techniques. The communication device may be a portable communication device or a network-connected communication device. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A conceptual diagram illustrating one example of communication devices interacting with each other according to some embodiments.

[0012] Figure 2 A conceptual diagram illustrating another example of communication devices interacting with each other according to some embodiments.

[0013] Figure 3 An example of an interactive activity mode according to some embodiments is shown.

[0014] Figure 4A A scenario is shown of a communication device interacting with an access device according to some embodiments.

[0015] Figure 4B A scenario is shown of two communication devices cooperatively interacting with an access device according to some embodiments.

[0016] Figure 4C A scenario is shown of three communication devices cooperatively interacting with an access device according to some embodiments.

[0017] Figure 5 A communication flow diagram illustrating a provisioning process for secondary device-assisted credential storage according to some embodiments.

[0018] Figure 6 A communication flow diagram is shown for requesting authorization to use an account utilizing a secondary device-assisted credential store according to some embodiments.

[0019] Figure 7 A communication flow diagram illustrating a process for providing secondary device assisted encryption according to some embodiments.

[0020] Figure 8 A communication flow diagram is shown for requesting authorization to use an account utilizing secondary device-assisted encryption according to some embodiments.

[0021] Fig. 9 A conceptual diagram illustrating an exemplary technique for collaboratively generating a password by two communicating devices, according to some embodiments.

[0022] Fig.10 A flowchart illustrating a process for establishing an interactive activity mode according to some embodiments.

[0023] Fig.11 A flowchart of a process for requesting authorization to use an account according to some embodiments is shown.

[0024] Fig.12 A flow diagram of a process for utilizing secondary device-assisted credential storage is shown according to some embodiments.

[0025] Fig.13 A flow diagram of a process for utilizing secondary device-assisted encryption according to some embodiments is shown.

[0026] Fig.14 A block diagram of a portable communication device according to some embodiments is shown.

[0027] Fig.15 A block diagram of a network-connected communication device is shown according to some embodiments.

[0028] Fig.16 A block diagram of a communication device according to some embodiments is shown.

[0029] Fig.17 A block diagram of an exemplary system is shown according to some embodiments. DETAILED DESCRIPTION

[0030] Embodiments of the present invention provide enhanced authentication techniques to authenticate communication devices. In some embodiments, a user may operate a communication device to perform security-sensitive functions. By providing a more powerful authentication scheme to authenticate a communication device, the confidence that a user performing security-sensitive functions through a 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, the latest interactions between a communication device and other devices may be compared with historical interaction activity patterns to provide a risk assessment of whether the communication device is being used in a manner consistent with the user's typical behavior. In some embodiments, a communication device may also utilize interactions with other devices to securely store account credentials and / or utilize the capabilities of other devices to perform cryptographic operations to authenticate the communication device.

[0031] Before discussing the details of some embodiments of the present invention, a description of some terms may aid in understanding the various embodiments.

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

[0033] A "portable communication device" may be a communication device that can be transported and operated by a user and may include one or more electronic components (e.g., an integrated chip). A portable communication device may provide remote communication capabilities to a network. A portable communication device may be configured to transmit data or communications to and receive data or communications from other devices. A 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 computer, 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 e-reader device, etc., or in the form of a card (e.g., a smart card) or a pendant. Examples of portable communication devices may also include portable computing devices (e.g., laptops, netbooks, ultrabooks, etc.). A portable communication device may also be in the form of a vehicle (e.g., a car), or integrated as part of a vehicle (e.g., an information system of a vehicle).

[0034] A "device identifier" may refer to a unique identifier for a communication device. A 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 a 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, a device identifier may also be a requestor identifier (e.g., a token requestor identifier) ​​that identifies the communication device to an authorization server. The requestor identifier may be generated by an authorization server and assigned to a communication device by the authorization server.

[0035] A "server computer" may include a powerful computer or computer cluster. For example, a server computer may be a large mainframe, a small computer cluster, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a network server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the foregoing 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.

[0036] 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 send account parameters associated with the account to the portable communication device. The issuer may be associated with a host system that performs some or all of the functions of the issuer on behalf of the issuer. In some embodiments, the issuer may refer to a provider of a software application.

[0037] A "merchant" may generally be an entity that participates in a transaction and is able to sell goods or services or provide access to goods or services.

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

[0039] "Access device" can be any suitable device for interacting with a communication device and for communicating with an authorization server. In some embodiments, the access device can communicate with an authorization server via a merchant computer or a transaction processing network. The access device can be located at any suitable location, such as at the location where the merchant is located. The access device can be in any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), information kiosks, security systems, access systems, websites or network servers, etc. The access device can use any suitable contact or contactless, wired or wireless operating mode to send or receive data from a communication device or associated with a communication device. In some embodiments where the access device can include a POS terminal, any suitable POS terminal can be used, and it can include a reader, a processor and a computer-readable medium. The reader can include any suitable contact or contactless operating mode. 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.

[0040] An "authorization request message" may be an electronic message sent to request authorization of a transaction. The authorization request message may be sent to a transaction processing network and / or an issuer of a transaction card (e.g., a payment card). The authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems for exchanging electronic transaction information associated with transactions made by a user using a transaction device or a transaction account. The authorization request message may include information that can be used to identify an account. The authorization request message may also include additional data elements, such as one or more of a service code, an 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 a transaction amount, a merchant identifier, a merchant location, and the like), as well as any other information that can 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 about the location of the access device, and the like.

[0041] An "authorization response message" may be an electronic message reply to an authorization request message. The authorization response message may be generated by the issuing financial institution or a transaction processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is pending and the merchant must call a toll-free authorization phone number for more information. 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's computer in response to the authorization request message in the electronic message (directly or through the transaction processing network) indicating approval of the transaction. The code may be used as evidence of authorization. As described above, in some embodiments, the transaction processing network may generate the authorization response message or forward the authorization response message to the merchant.

[0042] "Token" may include an alternative identifier for a certain information. For example, a transaction token may include an identifier for a transaction account, which is an alternative to an account identifier (such as a primary account number (PAN)). For example, a token may include a series of alphanumeric characters that can be used as a substitute for an original account identifier. For example, the token "4900 0000 0000 0001" may be used in place of PAN "4147 0900 0000 1234". In some embodiments, the token may be format-retaining and may have a digital format (e.g., ISO 8583 financial transaction message format) that conforms to the account identifier used in an existing transaction processing network. In some embodiments, a token may be used to initiate, authorize, settle or resolve a transaction in place of a PAN. In other systems that typically provide an original certificate, a token may also be used to represent an original certificate. In some embodiments, a token value may be generated so that the original PAN or other account identifier cannot be calculated from the token value. Further, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and to identify the entity issuing the token.

[0043] The "real account identifier" may include an original account identifier associated with an account. For example, the real account identifier may be a primary account number (PAN) issued by an issuer for a card account (e.g., a credit card, a debit card, etc.). For example, in some embodiments, the real account identifier may include a sixteen-digit value, such as "4147 0900 0000 1234". The first six digits of the real account identifier (e.g., "414709") may represent an actual issuer identifier (BIN) that may identify the issuer associated with the real account identifier.

[0044] "Account parameters" may refer to information associated with an account that can be used to conduct transactions on the account. Examples of account parameters may include information that can be used to identify a user's account (e.g., a real account identifier, an alternative account identifier, a token, etc.), data or information related to the state of the account, one or more keys used to generate cryptographic information, data or information related to one or more keys, etc. Account parameters may be semi-static or dynamic. Dynamic account parameters may be account parameters with a limited lifespan, and once expired, they can no longer be used to conduct transactions until the account parameters are replenished, refreshed, or updated. Dynamic account parameters may be frequently replenished during the lifespan of an account. Semi-static account parameters may be account parameters with an extended lifespan longer than dynamic account parameters, and may be replenished less frequently than dynamic account parameters, or not replenished at all during the lifespan of an account.

[0045] A "key" may refer to a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm may be an encryption algorithm that transforms original data into an alternative representation, or a decryption algorithm that transforms 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), etc.

[0046] A "limited use key" or "LUK" may refer to a key that may be used only for a limited time or for a limited number of transactions, and may need to be renewed or replenished when the limited use is exhausted. A LUK may be associated with a set of one or more limited use thresholds that restrict 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 remains in good standing. The set of one or more limited use thresholds may include at least one of the following: a number of transactions for which the LUK may be used; a life time indicating the duration for which the LUK is valid; and / or a cumulative transaction amount indicating a total transaction amount of one or more transactions for which the LUK is valid; or any combination thereof.

[0047] A "limited use threshold" may refer to a condition that limits the use of a piece of information. When a base condition is met, the limited use threshold may be exceeded or exhausted. 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 the piece of information may become invalid and may no longer be used. As another example, the limited use threshold may include a number of times that 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.

[0048] A "transaction processing network" may include a network that can process and route transaction request messages. An exemplary transaction processing network may include data processing subsystems, networks, and operations used 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 TM VisaNet is a transaction processing network that processes credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, it may include the VIP system (account integrated payment system) that processes authorization requests and the BaseII system that performs clearing and settlement services.

[0049] The details of some embodiments of the invention will now be described.

[0050] I. Interactive Activity Mode

[0051] A user of a communication device will typically develop a behavioral pattern of operating the communication device and using the communication device to interact with other communication devices. For example, a user may develop a pattern of using a smart phone to check the user's schedule every morning when the user wakes up. The user may also develop a pattern of connecting the smart phone to a wireless speaker to play music every evening around dinner time. This behavioral pattern of how the communication device is operated and how the communication device interacts with other devices can be tracked over time to establish a pattern of interactive activity of the communication device.

[0052] Figure 1 A conceptual diagram illustrating an example of communication devices interacting with each other throughout the day according to some embodiments. The diagram is illustrated from the perspective of a mobile device 101 (e.g., a smartphone) that a user carries with them throughout the day. Figure 1 The example shown. In this example, the mobile device 101 can act as a communication hub that interacts with various other devices. The mobile device 101 can interact with different communication devices at different times and / or interact with more than one communication device at a time.

[0053] refer to Figure 1In the early morning when the user wakes up at home, the user can operate the mobile device 101 to connect to the wireless access point 113 to use the home's WiFi data connectivity, for example, to synchronize the calendar on the mobile device 101 with the remote server and check the user's schedule for the day. The user can also wear the fitness bracelet 112 and turn on the fitness bracelet 112. The fitness bracelet 112 can establish a communication channel with the mobile device 101 so that the user can use the mobile device 101 as a user interface to select an exercise program configured on the fitness bracelet 112, and enable the fitness bracelet 112 to transmit health monitoring data such as the user's heart rate to the mobile device 101.

[0054] Later, in 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 or stream music from the mobile device 101 to the audio system of the vehicle 114 while the user is driving. If the user wears a fitness band 112 throughout the day, the mobile device 101 may also periodically or continuously establish connectivity with the fitness band 112 to obtain health monitoring data.

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

[0056] When the user arrives home, the mobile device 101 can disconnect from the vehicle 114. When the user takes off the fitness band 112, the mobile device 101 can also disconnect from the fitness band 112. In the evening when the user is at home, the mobile device 101 can reestablish the connection with the access point 113 to use the home's Internet data connectivity. The mobile device 101 can also connect to the wireless speaker 119 to stream music to the speaker 119, and connect to the TV 117 to play videos on the TV 117. The mobile device 101 can also connect to smart appliances 118 such as a smart thermostat to adjust the temperature in the home.

[0057] Figure 2 A conceptual diagram illustrating another example of communication devices interacting with each other during a day according to some embodiments. The diagram is illustrated from the perspective of an access point 201 (e.g., an Internet gateway or router) installed at a user's home. Figure 2 The example shown. In this example, the access point 201 can act as a communication hub for interacting with various other devices. The access point 101 can interact with different communication devices at different times and / or interact with more than one communication device at a time.

[0058] In the early morning when the user wakes up at home, the user can operate the mobile device 211 to connect to the wireless access point 201, similar to Figure 1 . Later, in the morning when the user leaves for work, the access point 201 can disconnect from the mobile device 211 and establish a connection with the home monitoring system 212 to allow the user to remotely monitor the home. At noon and while still connected to the home monitoring system 212, the access point 201 can connect with the DVR 213 to start recording a program while the user is not at home. In the afternoon, the access point 201 can disconnect from the DVR 213 after it has finished recording the program, and connect with a smart appliance 214 such as a smart thermostat to preheat the home before the user gets home from get off work. In the evening when the user returns home, the access point 201 can disconnect from the home monitoring system 212. The user can 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 computer 216, and TV 215.

[0059] As shown in these examples, a communication device acting as a primary device may interact with any number of other devices throughout the day, regardless of 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. Since a user's daily life is not expected to vary greatly from day to day, interactions between a 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 device. This interactive activity pattern may be learned over time and may be used as a digital persona to authenticate the user and the user's communication device, as discussed further below.

[0060] Figure 3 An example of an interactive activity pattern 300 of interactions between users' communication devices is shown according to some embodiments. Figure 3 The example interactive activity mode 300 shown is based on Figure 1The device interaction shown, wherein the user's mobile device is used as a communication hub. The interaction activity pattern 300 may provide correlations between device data associated with communication devices interacting with each other during a particular time period at various time periods of the day (e.g., early morning, morning, noon, afternoon, evening, etc.). Figure 3 The time of day 310 is shown divided into five different time periods, but it should be understood that in some embodiments, a finer time period granularity (e.g., each hour of the day representing a time period) or a coarser time period granularity (e.g., morning, daytime, and evening) may be used.

[0061] In its most basic form, the interactive activity pattern 300 may include a correlation between the time of day 310 and the device identifiers (IDs) 320 of the communication devices that interact 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 band. Thus, the interactive activity pattern 300 may associate the device IDs of the mobile device, access point, and fitness band with the early morning time period. Similarly, in the evening, the user's mobile device may interact with the user's home access point, wireless speaker, TV, and smart home appliances. Thus, the interactive activity pattern 300 may associate the device IDs of the mobile device, access point, wireless speaker, TV, and smart home appliances with the evening time period.

[0062] In some embodiments, in addition to associating the device ID, the interactive activity pattern 300 may include a correlation between the time of day 310 and additional device data that may be obtained from the communication device. For example, the interactive activity pattern 300 may include a correlation between the time of day 310 and contextual data 340 that may be obtained from any one of the communication devices. In some embodiments, the contextual data 340 may include sensor data, such as environmental data and / or performance or status data provided by one or more sensors of the device. Additionally or alternatively, the contextual data 340 may include user data representing how the user interacts 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., applications invoked by the user, operational changes and / or configuration changes made by the user, activities performed by the user using the device, etc.).

[0063] refer to Figure 3, the user's mobile device can provide contextual data, such as the location of the mobile device, applications on the mobile device used by the user, phone call logs, and / or text message logs. The contextual data of the mobile device during each time period in the day time 310 can be associated with the corresponding time period in the interactive activity pattern 300. Regarding other communication devices, during the early morning time period, the mobile device interacts with a fitness bracelet and an access point. The fitness bracelet can provide contextual data, such as speed / acceleration data and heart rate data, as well as an exercise program selected by the user. The access point can provide contextual data, such as location and network speed data. These contextual data from the fitness bracelet and the access point can be associated with the early morning time period as part of the interactive activity pattern 300.

[0064] As another example, during the noon time period, a laptop computer of a user in an office may provide contextual data in the form of applications on the laptop computer used by the user, as well as web browser history. A headset of the user may provide contextual data in the form of call logs and volume settings set by the user. These contextual data from the laptop computer and the headset may be associated with the noon time period as part of the interactive activity pattern 300. Similarly, in the evening time period, contextual data (such as the playlist and volume settings of wireless speakers, the viewing channels and volume settings of TVs, and the temperature, humidity, and illumination levels detected by smart home appliance thermostats) may be associated with the evening time period as part of the interactive activity pattern 300.

[0065] According to some embodiments, device data (e.g., device ID, contextual data such as sensor data and / or user data, etc.) of a communication device may be sent to an authorization server to establish an interactive activity pattern at the authorization server. During the day, communication hub devices such as mobile devices, access points, etc. (which may be referred to as "one-time devices") may periodically send device data to the authorization server. The one-time 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 signal between the one-time device and the authorization server to establish a secure communication channel.

[0066] In addition, the primary device may receive device IDs of secondary devices throughout the day as the primary device interacts with other communication devices (which 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 a secondary device, or in response to the primary device requesting a device ID from a secondary device to establish a communication channel. 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 a pattern of interactive activity. In some embodiments, if the primary device sends the device IDs of the secondary devices as it receives them (e.g., substantially in real time), the timestamp may be omitted because the authorization server may make its own determination as to when the primary device interacted with the secondary device (e.g., based on when the authorization server received the device ID).

[0067] In embodiments where the interactive activity pattern includes contextual data (such as sensor data and / or user data of a secondary device), the primary device may receive sensor data and / or user data from the secondary device as part of 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 contextual data and sensor data and / or user data from the secondary device to the authorization server 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.

[0068] In some embodiments, location data provided from primary and secondary devices may also be used by the authorization server to derive a geographic perimeter representing a geo-fence around the user's location throughout the day. For example, the geographic perimeter may be derived by using the locations reported by the devices to extrapolate a route taken by the user and setting the boundaries of the perimeter 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 the geographic perimeter information may be included as part of an interactive activity pattern associated with the user's communication device.

[0069] Although the daily routine of the user will generally remain unchanged every day, there may also be from time to time anomalies and situations that can cause the user to deviate from his or her regular daily routine. In this way, the authorization server can analyze the device data of the primary device and the secondary device over time, and filter out any differences that deviate from the typical behavior of the user when establishing the interactive activity pattern. For example, the original device data from each day can be compared with those of the previous few days, and only the public device data or the device data that has reached the threshold number of days can be used as the interactive activity pattern. In some embodiments, the authorization server can maintain a separate interactive activity pattern for each day of the week to illustrate the difference in the behavior of the user between each day or between weekdays and weekends. Once the interactive activity pattern based on the interaction between the user's communication device has been learned by the authorization server, the authorization server can use the interactive activity pattern to provide enhanced authentication for the user and his / her communication device. In some embodiments, the authorization server can also analyze the trend of the correlation between the device data and different time periods to illustrate the change of the user's behavior over time, and adjust or update the interactive activity pattern accordingly.

[0070] II. Authentication based on interactive activity model

[0071] FIG. 4A to FIG. 4C Different scenarios are shown in which the interactive activity mode can be used to provide enhanced authentication services for a user and his / her communication device.

[0072] refer to Figure 4A, a user may operate a primary device 401 to communicate with an 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 having 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 a compatible application and compatible communication hardware to interact with the access device 460. The access device 460 may be, for example, a remote network server or a POS terminal proximate to the primary device 401. In order to request authorization to use an account associated with the user, the primary device 401 may provide a token or account identifier 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), the primary device 401 may also provide a device ID to the access device 460 so that the primary device 401 can be identified. The access device 460 may forward the token or account identifier (and the device ID (if provided)) to the authorization server 480. The authorization server 480 can be based on a token or account identifier of the primary device 401, a 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 interactive activity pattern associated with the primary device 401.

[0073] In embodiments where the primary device 401 sends device data to the authorization server 480, the authorization server 480 may compare the most recent device data received from the primary device 401 to the interaction activity pattern to assess the risk of whether the primary device 401 is operated by its authorized user. For example, if the most recent device data (e.g., device ID and / or contextual data) received from the primary device 401 is similar to the historical interaction activity pattern for the time of day, the confidence that the primary device 401 is operated by its authorized user will be high, and the authorization server 480 may authorize use of the user's account.

[0074] In embodiments where a 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 the historical interaction activity pattern to determine whether the user typically interacts with or uses the primary device 401 at this time of day, and / or to determine whether the primary device 401 is used at a location within the geographic perimeter of where the user expects to be at this time of day. If the use of the primary device 401 is consistent with the interaction activity pattern, the authorization server 480 may authorize use of the user's account. In some embodiments, the primary device 401 may also provide contextual 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 contextual data to the authorization server 480. The contextual data of the primary device 401 may also be considered when the authorization server 480 assesses the risk of whether the primary device 401 is operated by its authorized user.

[0075] If the authorization server 480 determines that the most recent device data received from the primary device 401 is inconsistent with the interactive activity pattern, or that the primary device 401 is being used in a manner that deviates from the interactive activity pattern, the authorization server 480 may deny the authorization request. In some embodiments, instead of denying the authorization request, authorization may still be allowed if additional data is available to increase confidence that the user using the requester device 401 is an authorized user.

[0076] Figure 4B 401 is a diagram illustrating a scenario in which an additional communication device (which may be referred to as a "secondary device") is used to increase confidence that a user using a primary device 401 is an authorized user, according to some embodiments. Figure 4B In some embodiments, the user may operate the primary device 401 in the presence of an additional communication device that has been previously registered with the authorization server 480. The additional communication device may be a secondary device 412 that acts as a credential device to provide 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., a heart rate monitor) that can be used to establish the continuous presence of the user, the additional credential data provided to the primary device 401 may be an activity or biometric pattern stream (e.g., heart rate data). The activity or biometric pattern stream from the previously registered secondary device 412 may increase confidence that the user is an authorized user because the activity or biometric pattern stream may be used to establish the identity of the user and / or the user of the primary device 401 has two devices associated with the account holder.

[0077] Figure 4C Another scenario is shown in which an additional communication device is used to increase confidence that a user using a primary device 401 is an authorized user according to some embodiments. Figure 4C The scene in is similar to Figure 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. Figure 4C 4, the user is initiating a request for authorization to use an account associated with the user from tertiary device 413 rather than primary device 401. When the user initiates the 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. Tertiary device 413 may be used, for example, to provide an alternative user interface available on primary device 401 when it is more convenient for the user to physically interact with tertiary device 412, or if primary device 401 does not have its own user interface. Because the user has three devices associated with the account holder, the presence of a third communication device further increases confidence that the user is an authorized user.

[0078] like Figure 4C As shown in the example in, the roles and functions of requesting authorization to use an account can be distributed among multiple communication devices associated with a user. In some embodiments, depending on the capabilities of the communication device, the communication device can perform multiple functions and play different roles at different times. For example, in one scenario, a smartphone can be used as a primary requester device, where a fitness bracelet is used as a secondary credential device. In another scenario, a smart watch can be used as a primary requester device, where a smartphone is used as a secondary credential device, and vice versa. In another scenario, a smart watch can be used as a tertiary user interface device that controls a smartphone that acts as a primary requester device, where the user's vehicle is used as a secondary credential device. Therefore, it should be understood that although a specific communication device can be referred to as a primary device, a secondary device, or a tertiary device, the same communication device can play different roles at different times. In other words, a specific communication device can act as any combination of one or more primary devices, secondary devices, or tertiary devices, and can provide any combination of one or more requesters, credentials, or user interface functions.

[0079] III. Enhanced Authentication Using Secondary Device Assisted Credential Storage

[0080] In the above Figure 4B and Figure 4CIn the scenario shown, the secondary device is used to provide an indication of the user's presence to increase confidence that the request to use the account is from an authorized user. In some embodiments, the secondary device can provide enhanced authentication by facilitating secure account credential storage of the primary device. For example, the device data of the secondary device can be used to encrypt the account credentials. The encrypted account credentials can be stored encrypted on the primary device or on the secondary device, or split and stored on both the primary device and the secondary device. When the primary device communicates with the access device to request authorization to use the account, the primary device can obtain the device data of the secondary device (and any account credentials stored on the secondary device). The primary device can then use the device data of the secondary device to decrypt the account credentials, and use the decrypted account credentials to interact with the access device to request authorization to use the account.

[0081] Figure 5 A communication flow chart of a provision process for providing account credentials to a primary device that interacts with a secondary device for secondary secure storage authentication according to some embodiments is shown. A primary device 501 can establish a communication channel with a secondary device 512 to communicate with the secondary device 512. If the secondary device 512 has cryptographic capabilities, the communication channel can 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 can use obfuscation techniques to protect the information exchanged between the devices. In some embodiments, the communication between the primary device and the secondary device can be digitally signed by the corresponding device. The communication channel between the primary device 501 and the authentication server 580 can use end-to-end encryption, for example, using a protocol such as opacity, which does not require a handshake signal between the primary device and the authorization server to establish a secure communication channel.

[0082] At step 532, the secondary device 512 may send 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 in response to the primary device 501 requesting device data from the secondary device 512 to establish a communication channel. At step 534, the primary device 501 may send a provision request to the authorization server 580 to request account credentials for the user's account. In some embodiments, the authorization server 580 may be a token server that manages tokens and provides tokens to communication devices. The provision request may include a device ID of the primary device 501, an account identifier for identifying the account for which the account credentials are being requested, and device data, such as a device ID of the secondary device 512.

[0083] When the authentication server 580 receives the provision request, the authentication server 580 can verify that the account has a good reputation. If the account has a good reputation, the authentication server 580 can generate a shared key for the disposable device 501 and an account credential for the account. In some embodiments, a protocol such as elliptic curve Diffie-Hellman can be used to generate the shared key. The account credential can include a token that can be used as a substitute for an account identifier and / or a cryptographic key that can be used by a disposable device to generate a password when requesting authorization to use the account. In some embodiments, the cryptographic key can be a limited use key associated with a set of one or more limited use thresholds. When the use of a limited use key exceeds one or more of its limited use 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 supplemented from the authentication server 580.

[0084] 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 the device data (e.g., device ID) of the secondary device 512 using the shared key. The authentication server 580 may then use the key encryption key to encrypt the generated account credentials (e.g., token and / or cryptographic key).

[0085] 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 a portion of both) on the primary device 501. At step 540, any portion of the encrypted account credentials not stored on the primary device 501 is 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 completed, 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, instead of using the primary device 501 to forward a portion of the account credentials to be stored on the secondary device 512 (if any) to the secondary device 512, the authentication server 580 can send the portion of the account credentials to be stored on the secondary device 512 directly to the secondary device 512, and can omit sending the portion of the account credentials to the primary device 501.

[0086] In some embodiments, the secondary device 512 may be provisioned asynchronously with the primary device 501. In other words, the secondary device 512 may be provisioned at a different time than when the primary device 501 is provisioned. 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 provision the secondary device 512 independently and separately from the primary device 501. Thus, in some embodiments, when the primary device 501 sends the provisioning request to the authorization server 580, the secondary device 512 may be provisioned without requiring an active connection to the primary device 501.

[0087] Figure 6A communication flow chart for requesting authorization to use an account according to some embodiments is shown, wherein a secondary device provides secondary credential storage to a primary device. A primary device 601 may interact with an access device 660 to request authorization to use an account. The access device 660 may be a remote network server or a POS terminal adjacent to the primary device 601. In some embodiments, as part of an authentication process for verifying the primary device 601, the access device 660 may provide dynamic data associated with a request for authorization to use an account associated with a 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 for authorization to use an account involves a transaction, the dynamic data may include transaction information from the access device 660, such as a transaction amount.

[0088] 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 in which some or all of the encrypted account credentials (e.g., a token and / or cryptographic key) 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.

[0089] At step 638, after the primary device 601 receives the credential data of the secondary device 612, the primary device 601 may derive a key encryption key and decrypt 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 the device data (e.g., device ID) of the secondary device 612 using a shared key previously provided to the primary device 601 to derive the key encryption key. The primary device 601 may then use the key encryption key to decrypt any encrypted account credentials (e.g., tokens and / or cryptographic keys) stored on the primary device 601 and any encrypted account credentials received from the secondary device 612 to obtain an unencrypted token and / or an unencrypted cryptographic key.

[0090] 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 dynamic data related to the authorization request at step 632, the primary device 601 may use a cryptographic key to encrypt some or all of the dynamic data received from the access device 660. In some embodiments, the data input to the cryptographic generation function may also include a count value that counts the number of use account requests initiated by the primary device 601. In embodiments where the request for authorization to use the account does not require the primary device 601 to encrypt the dynamic data from the access device 660, the primary device 601 may use a cryptographic key to encrypt a predetermined static string to generate a password.

[0091] At step 642, the primary device 601 transmits the token and the 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 the authorization request message to the authorization server to obtain authorization for the primary device 601 to use the account.

[0092] When the authorization server receives the authorization request message, the authorization server can convert the token back to the account identifier replaced by the token, determine the cryptographic key associated with the token provided to the one-time 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 password generation). If the regenerated password matches the password received from the one-time device 601, the authorization server can authorize use of the account.

[0093] In some embodiments, the secondary device may be unavailable and may not be present when the primary device interacts with the access device. For example, if the secondary device is a user's vehicle, when the user leaves the vehicle and uses the user's smartphone as a 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 front 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 time period (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 can interact with the access device to request authorization to use the user's account without the secondary device being present with the primary device, as long as the interaction with the access device is performed within a predetermined time period for the primary device to obtain the credential data of the secondary device.

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

[0095] The secondary device auxiliary credential storage technology described above does not need to be limited to using only one secondary device, and can also be extended to multiple secondary devices. In some embodiments, a primary device can be provided with different groups of account credentials (e.g., tokens and / or cryptographic keys) for each secondary device in a group of secondary devices registered with an authorization server. For example, different tokens and / or different cryptographic keys can be generated by the authorization server for each secondary device. In an embodiment in which some or all of the account credentials are stored on a primary device, the account credentials provided for a specific secondary device can be stored on a primary device together with a hash of the device ID of the secondary device. The hash of the device ID can be used as an index to allow a primary device to correctly retrieve the account credentials associated with a specific secondary device. In this way, when a primary device requests credential data from a specific secondary device when interacting with an access device, a primary device can obtain the device ID of the secondary device, generate a hash of the device ID, and use the hash to view the appropriate account credential group associated with a specific secondary device stored on the primary device.

[0096] In some embodiments, a single set of account credentials (e.g., a token and / or cryptographic key) may also be encrypted using a key encryption key derived from device data of multiple secondary devices. For example, device data of a first secondary device may be combined with device data of a 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 multiple secondary devices with a shared key. When a primary device interacts with an access device to request authorization to use an account, the primary device may request device data from each secondary device whose device data was used in the derivation of the key encryption key.

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

[0098] 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 portion is stored on which secondary device so that the primary device can appropriately recover the account credentials. For example, a first portion of the account credentials encrypted using a first key encryption key derived from the device data of a first secondary device may be stored on a second secondary device, and a second portion of the account credentials encrypted using a second key encryption key derived from the 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 credentials 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 credentials and the device data of the second secondary device to the first device. A primary device having knowledge of the mapping of which portion of the account credentials is stored on which secondary device may then use the device data received from the first secondary device to decrypt the portion of the account credentials received from the second secondary device, and use the device data received from the second secondary device to decrypt the portion of the account credentials received from the first secondary device.

[0099] IV. Enhanced Authentication Using Secondary Device Assisted Encryption

[0100] In some embodiments, if the secondary device has password capabilities, the secondary device can also provide enhanced authentication by assisting with password generation on behalf of the primary device. For example, during password generation, the primary device can generate a first intermediate password and send the first intermediate password to the secondary device. The secondary device can 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 sends the final password to the access device to request authorization to use the user's account.

[0101] Figure 7 A communication flow chart of a provision process for providing account credentials to a primary device that interacts with a secondary device for auxiliary encryption authentication according to some embodiments is shown. The primary device 701 can establish a communication channel with the secondary device 712 to communicate with the secondary device 712. The communication channel can use end-to-end encryption to protect the information exchanged between the devices, or can use obfuscation technology to protect the information exchanged between the devices. In some embodiments, the communication between the primary device and the secondary device can be digitally signed by the corresponding device. The communication channel between the primary device 701 and the authentication server 780 can use end-to-end encryption, for example, using a protocol such as opacity, which does not require a handshake signal between the primary device and the authorization server to establish a secure communication channel.

[0102] At step 732, the secondary device 712 may send 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 device data from the secondary device 712 to establish a communication channel. At step 734, the primary device 701 may send a provision request to the authorization server 780 to request account credentials for the user's account. In some embodiments, the authorization server 780 may be a token server that manages tokens and provides tokens to communication devices. The provision request may include a device ID of the primary device 701, an account identifier for identifying the account for which the account credentials are being requested, and device data, such as a device ID of the secondary device 712.

[0103] When the authentication server 780 receives the provision request, the authentication server 780 can verify that the account has a good reputation. If the account has a good reputation, the authentication server 780 can generate an account credential for the account. The account credential may include a cryptographic key that can be used by a one-time device to generate a password when requesting authorization to use the account. The cryptographic key may include multiple parts. For example, the cryptographic key may consist of two partial cryptographic keys. The account credential may also include a token that can be used as a substitute for an 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 use of a limited use key exceeds one or more of its limited use 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 supplemented from the authentication server 780.

[0104] At step 736, the authentication server 780 sends the account credentials including the portion of the cryptographic key to the primary device 501. At step 738, the primary device 701 stores the 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 the 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 forwarding a portion of the account credentials to be stored on the secondary device 712 to the secondary device 712 using the primary device 701, the authentication server 780 may send a portion of the account credentials to be stored on the secondary device 712 directly to the secondary device 712, and may omit sending the portion of the account credentials to the primary device 701.

[0105] In some embodiments, the secondary device 712 may be provisioned asynchronously with the primary device 701. In other words, the secondary device 712 may be provisioned with the second portion of the cryptographic key at a different time than the time when the primary device 701 is provisioned 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 the second portion of the cryptographic key received from the authorization server 780, which is 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 provision the secondary device 712 independently and separately from the primary device 701. Thus, in some embodiments, when the primary device 701 sends the provisioning request to the authorization server 780, the secondary device 712 may be provisioned without requiring an active connection to the primary device 701.

[0106] Figure 8 A communication flow chart for requesting authorization to use an account according to some embodiments is shown, wherein a secondary device provides auxiliary encryption to a primary device. A primary device 801 may interact with an access device 860 to request authorization to use an account. The access device 860 may be a remote network server or a POS terminal adjacent to the primary device 801. In some embodiments, as part of an authentication process for verifying the primary device 801, at step 832, the access device 860 may provide dynamic data associated with a request for authorization to use an account to the primary device 801. 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 for authorization to use an account involves a transaction, the dynamic data may include transaction information from the access device 860, such as a transaction amount.

[0107] At step 834, the primary device 801 may generate a first intermediate cryptogram using a first portion of a 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 the first portion of the 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 account use requests that have been initiated by the primary device 801. In embodiments where the request for authorization to use the user's account does not require the primary device 801 to generate a cryptogram based on the 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 the first portion of the cryptographic key stored on the primary device 801 to generate the first intermediate cryptogram.

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

[0109] At step 842, the primary device 801 may generate a final password from the second intermediate password using a first portion of a cryptographic key stored on the primary device 801. For example, the primary device 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., a token) required 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 the authorization server to obtain authorization to use the user's account according to the techniques described herein.

[0110] Fig. 9 A conceptual diagram illustrating an exemplary technique for generating a password by a primary device cooperating with a secondary device according to some embodiments. The encryption protocol used for encryption and decryption operations may be, for example, DES (Data Encryption Standard), AES (Advanced Encryption Standard), or other suitable encryption / decryption algorithms.

[0111] The cryptographic key provided from the authorization server may be divided 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. The first part of the cryptographic key K1 may be provided to the primary device 901, and the second part 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.

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

[0113] The secondary device 912 then generates a second intermediate cryptogram C2 based on the first intermediate cryptogram C1 received from the primary device 901. In some embodiments, the second intermediate cryptogram C2 can be generated by decrypting C1 with the second intermediate key K4, encrypting the first result with the first intermediate key K3, and then decrypting the second result with the second part of the cryptographic key K2. The second intermediate cryptogram C2 is then provided to the primary device 901, and the primary device 901 can generate a final cryptogram C that is sent to the access device by encrypting C2 with the first part of the cryptographic key K1.

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

[0115] V. Exemplary Procedures

[0116] Fig.10A flow chart of a process 1000 for establishing an interactive activity mode associated with a primary device according to some embodiments is shown. Process 1000 may be repeated for each communication device (e.g., a secondary device or a tertiary device) that interacts with the primary device. At box 1002, a communication channel is established between the primary device and the communication device that interacts with the primary device. At box 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 box 1006, the device data received from the communication device is sent to a server to establish an interactive activity mode at the server. The device data of the primary device (e.g., the 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 an interactive activity mode.

[0117] In some embodiments, a timestamp may be sent with the device data to allow the server to associate interactions between the primary device and the communication device with a time period of the day. Thus, a pattern of interactive activity may be further established based on the time of day at which the primary device interacts with each communication device. In some embodiments, the device data may include location data for the communication device and / or the primary device, and the location data may be used to derive a geographic perimeter representing a geo-fence around locations that the user typically visits. The pattern of interactive activity including the derived geographic perimeter may be used to provide a risk assessment as to whether the primary device attempting to request authorization to use the account is operating in a manner consistent with the typical behavior of the user.

[0118] Fig.11 A flow chart of a process 1100 for requesting authorization to use an account of a user of a primary device according to some embodiments is shown. At box 1102, the primary device may receive credential data of a 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 box 1104, the primary device generates a password using the credential data of the secondary device.

[0119] At box 1106, the primary device transmits the password to the access device to request authorization to use an account associated with the user of the primary device. The request for authorization to use the account can be, for example, a request to access information about the account, a request to use the account to access services or products, a request to use the account to conduct a transaction, etc. In some embodiments, the access device can be a remote network server, and the password can be transmitted to the access device via a computer network such as the Internet. In some embodiments, the access device can be an access terminal such as a POS terminal located near the primary device, and the password can be transmitted to the contactless reader of the access terminal using short or medium contactless communication technology (e.g., NFC, Bluetooth, BLE, etc.) or by presenting an image representing the password (e.g., QR code, barcode, etc.) to the optical reader of the access terminal.

[0120] In some embodiments, the access device may forward the password to an authorization server. The use of an account may be authorized based on the verification of the password and the interactive activity pattern of the interaction between the primary device and a group of communication devices including secondary devices. For example, the authorization server may compare the latest interaction between the primary device and one or more of the communication devices with the interactive activity pattern to determine whether the primary device is used in a manner consistent with the user's typical behavior and / or at a location consistent with the user's typical activities. 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 to be an authorized user, and authorization to use the account may be granted without restriction. 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 the authorization may be granted with restrictions on how the account may be used. For example, restrictions on transaction amounts may be imposed in this scenario.

[0121] Fig.12 A flow chart of a process 1200 for secondary credential storage by a secondary device to enhance authentication of a primary device according to some embodiments is shown. At box 1202, in order to register a secondary device that interacts with the primary device and request provision of the primary device and the secondary device, the primary device may send device data (such as a device ID of the secondary device) to an authorization server. At box 1204, in response to registering the secondary device, the primary device may receive a shared key and an encrypted cryptographic key from the 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.

[0122] At block 1206, the primary device stores the shared key on the primary device. In some embodiments, the encrypted cryptographic key and / or the 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 a remaining portion of the encrypted cryptographic key and / or a remaining portion of the encrypted token may be stored on the secondary device.

[0123] Once the primary device and secondary device have been provisioned, the primary device may interact with the access device to request authorization to use an account associated with a 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. If any portion of the encrypted cryptographic key and / or encrypted token is stored on the secondary device, the primary device may also receive the encrypted cryptographic key and / or encrypted token from the secondary device as part of the credential data for the secondary device.

[0124] At box 1210, 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 box 1212, the primary device uses the derived key encryption key to decrypt the encrypted cryptographic key and / or the encrypted token. At box 1214, the primary device generates a password by encrypting data related to the authorization request using the decrypted cryptographic key. In some embodiments, the data related to the authorization request may include dynamic data received from the access device. In some embodiments, the data related to the authorization request may include a predetermined static string. At box 1216, the primary device transmits the password to the access device to request authorization to use the user's account.

[0125] In some embodiments, the presence of a secondary device may not be required when the primary device interacts with the access device. For example, 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 received in advance by the primary device from the secondary device. Credential data, such as the device ID of the secondary device, may be temporarily stored on the primary device for a predetermined period of time. If the primary device interacts with the access device within a predetermined time period in which the credential data of the secondary device is received by the primary device, this will allow the primary device to interact with the access device to request authorization without the presence of the secondary device. When a predetermined time period has passed since the credential data was received, the credential data may be automatically deleted from the primary device to prevent continued storage of the credential data on the primary device. In some embodiments, if the primary device determines that the secondary device is unavailable, the primary device may also send a request for the credential data of the secondary device to a remote server, and the credential data of the secondary device may be received by the primary device from the remote server.

[0126] Fig.13 A flowchart of a process 1300 for performing auxiliary encryption by a secondary device to enhance the authentication of a primary device according to some embodiments is shown. At box 1302, in order to register a secondary device that interacts with the primary device and request the provision of the primary device and the secondary device, the primary device can send device data (such as the device ID of the secondary device) to an authorization server. At box 1304, in response to registering the secondary device, the primary device can receive a cryptographic key from the authorization server. The cryptographic key can be divided into a first part and a second part. In some embodiments, the primary device can also receive a token. At box 1306, the primary device stores the first part of the cryptographic key on the primary device. At box 1308, the primary device sends the second part of the cryptographic key to the secondary device for storage on the secondary device. The primary device and the secondary device can also be provided with a first intermediate key and a second intermediate key.

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

[0128] At block 1314, the primary device receives a second intermediate cryptogram generated by the secondary device using the first intermediate cryptogram and a second portion of the cryptographic key stored on the secondary device. The second intermediate cryptogram 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 cryptogram by decrypting the first intermediate cryptogram using the second intermediate key, re-encrypting the decrypted first intermediate cryptogram using the first intermediate key, and decrypting the re-encrypted first intermediate cryptogram using the second portion of the cryptographic key. For stronger transmission protection, the second intermediate cryptogram may be generated by further encrypting the result of decrypting the re-encrypted first intermediate cryptogram using the second intermediate key, and decrypting the encrypted result using the first intermediate key.

[0129] At block 1316, the primary device uses the second intermediate password and the first portion of the cryptographic key stored on the primary device to generate a password that is sent to the access device. In some embodiments, the password may be generated by encrypting the second intermediate password using the first intermediate key, decrypting the encrypted second intermediate password using the second intermediate key, and encrypting the decrypted second intermediate password again using the first portion of the cryptographic key. At block 1318, the primary device transmits the password to the access device to request authorization to use the user's account.

[0130] VI. Exemplary Apparatus and Systems

[0131] Fig.14 A block diagram of a portable communication device 1401 is shown in which some embodiments of the processes described herein may be implemented. The portable communication device 1401 may be used 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 different communication devices, as a secondary device that assists another communication device in enhanced authentication, and / or as a tertiary device that is used as a user interface to control or communicate with a primary device.

[0132] Portable communication device 1401 may include device hardware 1404 coupled to memory 1402. Device hardware 1404 may include processor 1405, communication subsystem 1409, user interface 1406, display screen 1407 (which may be part of user interface 1406) and contactless interface 1408. 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 portable communication device 1401. Processor 1405 may execute various programs in response to program codes or computer-readable codes stored in memory 1402, and may maintain multiple programs or processes executed simultaneously. Communication subsystem 1406 may include one or more RF transceivers and / or connectors, which may be used by portable communication device 1401 to communicate with other devices and / or to connect to an external network. User interface 1406 may include any combination of input elements and output elements to allow a user to interact with portable communication device 1401 and call its functionality. In some embodiments, display screen 1407 may be part of user interface 1406 .

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

[0134] 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 media, or a combination thereof. The 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 the processor 1405. In some embodiments, the mobile OS 1414 may implement a set of card emulation APIs 1416 that may be called by the transaction application 1412 in order to access the contactless interface 1408 to interact with the access device.

[0135] 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 the like. The token request function 1434 may be called to request a token from a remote server (e.g., an authorization server such as a cloud-based transaction server, a token server, an issuer, or a host processing system). The token may be used as a substitute for a real account identifier to conduct a transaction (e.g., by sending the token to an access device). Using a token instead of a real account identifier may be safer because the real account identifier is not transmitted when conducting a transaction. The token request function 1434 may be called, for example, at registration time to request an initial token, or when the lifetime of the current token expires.

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

[0137] The password generation function 1438 can be called at transaction time to generate a password, which is provided to the access device to conduct the transaction. The password can be generated by receiving dynamic transaction data (e.g., transaction amount, transaction date, unpredictable amount, etc.) from the access device and encrypting the dynamic transaction data using the LUK. In some embodiments, the password can be generated by encrypting a static string using the LUK (e.g., if the access device does not support transmitting dynamic data to the portable communication device).

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

[0139] Fig.15 A block diagram of a network-connected communication device 1501 is shown, in which some embodiments of the processes described herein may be implemented. The network-connected communication device 1501 may be used 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 is used as a user interface to control a primary device or communicate with a 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 smart home appliance device (such as a set-top box, a smart TV, a smart refrigerator), etc.

[0140] The network-connected communication device 1501 may include a processing subsystem 1520, one or more network interfaces 1509, and a transaction application 1512. The processing subsystem 1520 may be implemented as one or more integrated circuits, such as one or more processors and / or controllers 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, the processing subsystem 1520 may execute various programs and / or processes in response to program codes or instructions, and may maintain multiple programs or processes that are executed simultaneously. At any given time, some or all of the program codes or instructions to be executed by one or more processors / controllers 1505 may reside in the processing subsystem 1520, such as in the processing subsystem memory 1502. Each processor / controller 1505 may be implemented as a microprocessor, a digital signal processor, an application specific integrated circuit, a field programmable gate array, an analog circuit, a digital circuit, and / or a combination thereof.

[0141] The network interface 1509 may include one or more internal network interfaces and / or one or more external network interfaces to facilitate communication exchanges 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 interact with multiple communication devices simultaneously.

[0142] The transaction application 1512 may be implemented to have similar functionality to those described with reference to the transaction application 1412, and therefore a detailed description thereof need not be repeated. The transaction application 1512 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 a general purpose memory of the network-connected communication device 1501.

[0143] Fig.16 A block diagram of a communication device 1601 is shown in which some embodiments of the processes described herein may be implemented. In some embodiments, the communication device 1601 may lack a transaction application and, therefore, may not be able to directly transact with an access device. However, in some embodiments, the communication device 1601 may be used as a communication hub for communicating with different communication devices, as a secondary device to assist another communication device in enhanced authentication, and / or as a tertiary device used 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, etc.

[0144] 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 a user may engage in invoking functions of the communication device 1601 and / or another device communicatively coupled to the communication device 1601.

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

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

[0147] 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. CBP 1780 implements a set of functionalities including account management and account parameter generation and replenishment to enable cloud-based transactions via portable communication device 1710.

[0148] MAP 1770 is used to facilitate communications between CBP 1780 and mobile applications 1714 (e.g., transaction applications) in portable communication device 1710. MAP 1770 may be implemented using one or more computing devices and may be associated with or operated by a service provider (e.g., an issuer, a mobile wallet provider, a merchant, and / or other suitable entity) of 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 application 1714 and CBP 1780 and ensure that requests and responses initiated by either party are fulfilled once connectivity to portable communication device 1710 is established, for example, via communication network 1782 (e.g., the Internet, mobile or cellular network, etc.). It should be understood that in some embodiments, one or more functionalities of CBP 1780, MAP 1770, and / or issuer or host processing system 1772 may be integrated into the same computing system or into different computing systems. In some embodiments, any one or more of CBP 1780, MAP 1770, and / or issuer or host processing system 1772 may act as an authorization server.

[0149] The portable communication device 1710 can be used to conduct cloud-based transactions (e.g., payment transactions) facilitated by the CBP 1780 and / or the MAP 1770. The portable communication device 1710 includes device hardware 1732, a mobile operating system (OS) 1722, and an application environment 1712. The 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 the contactless interface 1734 may include a near field communication (NFC) interface that can send and receive communications using radio frequency or other wireless communication protocols such as Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, etc. Examples of the contactless interface 1734 may also include an optical interface, such as a display for presenting information (such as a quick response (QR) code, a barcode, etc.).

[0150] The application environment 1712 of the portable communication device 1710 may include mobile applications 1714, such as transaction applications provided by a service provider (e.g., an issuer). For example, if the service provider of the mobile application 1714 is an issuer, the 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. With respect to merchants, the mobile application 1714 may be the merchant's own transaction application from which a consumer may conduct e-commerce or point-of-sale transactions, or a mobile wallet application that supports multiple merchants.

[0151] In some embodiments, the mobile application 1714 may include on-device cloud-based transaction logic integrated into the mobile application 1714 to support cloud-based transactions. The on-device cloud-based transaction logic performs 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 on-device cloud-based transaction logic may use a cryptographic key (e.g., a limited-use key) provided from the CBP 1780 to generate a transaction cryptogram that is transmitted to the access device 1760 over the contactless interface to conduct a payment transaction. The transaction cryptogram may be sent to the transaction processing network 1784 to obtain authorization for the payment transaction. The on-device cloud-based transaction logic also manages the initial service profile parameters provided after the account has been provisioned to ensure that requests for account parameter replenishment and other account parameter management activities are initiated.

[0152] In order to provide the portable communication device 1710 for cloud-based payment transactions, CBP 1780 may be used to configure an account portfolio associated with an issuer and provide account parameters to the portable communication device 1710 for use when conducting cloud-based transactions. The account portfolio established by CBP 1780 may include features such as risk parameters (e.g., speed control) that manage triggers for when account parameters on the provided device will need to be refreshed for accounts in each portfolio. To ensure consistent performance and availability, a minimum set of parameters that can be configured in a service profile may be implemented by CBP 1780. In order 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 life of the enabled account. These functions may include provisioning, active account management, confirmation of payment, transaction processing, lifecycle management, and post-payment.

[0153] Before an 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 a real account identifier (e.g., a real PAN), and having established a legacy service profile for the portfolio. Once an account is provisioned, the relevant service profile details are shared with both transaction processing and on-device cloud-based transaction logic to ensure that decisions can be made at transaction processing time and during user use of the mobile application.

[0154] Once an 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 an 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 generated during provisioning (e.g., an alternative account identifier or token) and dynamic information to ensure that the set of account parameters has only limited use or a limited lifespan 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 calculating a cryptogram and limited use dynamic data for supporting legacy dynamic card verification values ​​or code-based implementations.

[0155] During transaction processing, if the service profile parameters maintained by CBP 1780 for a particular account indicate that the account parameters on portable communication device 1710 need to be replaced, then the active account management capabilities of CBP 1780 can connect to portable communication device 1710 via MAP 1770 to replenish the account parameters. Similarly, if the on-device service profile parameters stored on portable communication device 1710 indicate that account parameter replenishment is required or is about to be required (i.e., by monitoring account parameter thresholds), then mobile application 1714 can request account parameter replenishment from CBP 1780.

[0156] Once the portable communication device 1710 has been provided for cloud-based transactions, transactions can 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). 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, the access device 1760 may be a network server associated with a merchant, and the portable communication device 1710 may communicate with the 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 an issuer or main 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 computer cluster. For example, a server computer may be a mainframe, a small computer cluster, or a group of servers that work like 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).

[0157] Transaction processing network 1784 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services. Exemplary transaction processing networks may include VisaNet TM . Such as VisaNet TM VisaNet is a transaction processing network that processes credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, it includes the VIP system (Visa Integrated Payment System) that processes authorization requests and the Base II system that performs clearing and settlement services.

[0158] Each entity (eg, acquirer 1774, transaction processing network 1784, issuer, or host processing system 1772) may include one or more computers to enable communications or to perform one or more of the functions described herein.

[0159] To conduct a cloud-based transaction, a user of the portable communication device 1710 may tap the portable communication device 1710 against a contactless reader 1762 of the access device 1760 (e.g., via NFC), or display an image (such as a barcode or QR code) on the screen of the portable communication device 1710 that can be scanned by the contactless reader 1762 (e.g., an optical scanner or reader) of the access device 1760. 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 the limited-use account parameters). For example, the account identifier or token and / or the additional information (e.g., a transaction password) may be encoded in a barcode or QR code scanned by the access device 1760; or the account identifier or token and / or the additional information may be transmitted to the access device 1760 via NFC. In some embodiments, the limited-use account parameters may include the transaction password.

[0160] Access device 1760 or a merchant computer coupled to access device 1760 may generate an authorization request message including the 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 acquirer 1774. The authorization request message is then sent to transaction processing network 1784. Transaction processing network 1784 then forwards the authorization request message to a corresponding issuer or host processing system 1772 associated with the issuer of the account associated with portable communication device 1710.

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

[0162] At the end of the day, conventional clearing and settlement processes may be performed by the transaction processing network 1784. The clearing process is the process of exchanging financial details between acquirers and issuers to facilitate posting to the customer's payment account and to reconcile the user's settlement position.

[0163] Any of the computing devices, communication devices, computers, servers, etc. described herein may be implemented using one or more processors coupled to a memory that stores code or instructions that, when executed by the one or more processors, cause the device to perform one or more of the methods and processes described herein. The memory, storage media, and computer-readable media described herein for containing code or code portions 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 storing and / or transmitting 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 disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium that can be used to store or transmit the desired information and can be accessed by a computer.

[0164] 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 from the order 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, split one or more steps into multiple steps, and / or any combination thereof.

[0165] Any software components or functions described in this application 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 on different computing devices in a system or network.

[0166] 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 present invention.

[0167] Unless clearly indicated to the contrary, references such as “a”, “an”, “the”, or “said” are intended to mean “one or more”.

Claims

1. A communication device, comprising: processor; as well as 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, the operations comprising: generating a first intermediate cryptogram using a first portion of a cryptographic key stored on the primary device; sending 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 cryptogram generated by the secondary device using the first intermediate cryptogram 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 The password is sent 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 interaction activity pattern of historical interactions between the primary device and a group 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 comprising 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; as well as The device data received from the communication device is sent to an authorization server, wherein the device data is used to establish the interactive activity mode.

3. The communication device of claim 2, wherein the interaction activity pattern is further established based on a time of day at which 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 interaction activity pattern with 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; as well as Use the derived key encryption key to decrypt the encrypted cipher key, Wherein generating the cryptogram includes using the decrypted cryptographic key to encrypt data related to the authorization request.

6. The communication device of claim 5, wherein the operations further comprise: Prior to receiving the credential data of the secondary device: sending the device identifier of the secondary device to an authorization server to register the secondary device; receiving the shared secret key and the encrypted cryptographic key from the authorization server in response to registering the secondary device; as well as The shared key is stored 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; as well as The encrypted cryptographic key is received 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 from receiving the credential data.

11. A communication device, comprising: processor; as well as 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, the operations comprising: Determining that the secondary device is not in front of the primary device; sending a request to a remote server for credential data of a secondary device; receiving the credential data of the secondary device from the remote server; generating a password using the credential data of the secondary device; and The password is sent 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 interaction activity pattern of historical interactions between the primary device and a group of communication devices including the secondary device.

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

13. A communication device according to claim 11, wherein the first intermediate cipher is generated by: encrypting data related to the authorization request using a first part of the cipher key, decrypting the encrypted data using the first intermediate key, and re-encrypting the decrypted data using the second intermediate key.

14. A communication device according to claim 13, wherein the second intermediate cipher is generated by: decrypting the first intermediate cipher using the second intermediate key, re-encrypting the decrypted first intermediate cipher using the first intermediate key, and decrypting the re-encrypted first intermediate cipher using the second part of the cipher key.

15. The communication device according to claim 14, wherein the second intermediate cipher is further generated by encrypting a result of decrypting the re-encrypted first intermediate cipher using the second intermediate key, and decrypting the encrypted result using the first intermediate key.

16. A communication device according to claim 15, wherein the password is generated by: encrypting the second intermediate password using the first intermediate key, decrypting the encrypted second intermediate password using the second intermediate key, and re-encrypting the decrypted second intermediate password using the first part of the password key.

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

18. The communication device according to claim 11, wherein the communication device is a portable communication device or a network-connected communication device.

19. A method comprising: generating, by a primary device, a first intermediate cryptogram using a first portion of a cryptographic key stored on the primary device; The primary device sends the first intermediate password to the 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 cryptogram generated by the secondary device using the first intermediate cryptogram 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; as well as The password is sent by the primary device 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 interaction activity pattern of historical interactions between the primary device and a group of communication devices including the secondary device.

Images