Patent Description:
<CIT> describes a method and apparatus for authenticating a user. The method uses a portable I/O device to display a challenge from a kiosk or other multi-user computer and to enter a response to the challenge and transmit that response to the multi-user computer. The portable I/O device interfaces with a hardware security device, which generates the response using data securely stored in therein.

<CIT> describes displaying an image, usage information, and a payment module of an electronic card on a screen; detecting the selection of the payment module; and performing payment by using the electronic card. An electronic device includes a display unit; and a controller connected to the display unit and configured to display an image, usage information, and a payment module of an electronic card on a screen, detect a selection of the payment module, and perform a payment using the electronic card.

<CIT> describes techniques relating to authentication using public key encryption. A computing device is described which includes a secure circuit, a processor, and memory. The secure circuit is configured to generate a public key pair usable to authenticate a user of the computing device. The memory has program instructions stored therein that are executable by the processor to cause the computing device to perform operations including authenticating the user with a server system by sending authentication information supplied by the user. The operations further include, in response to the server system verifying the authentication information, receiving a first token usable to register the public key pair with the server system and sending, to the server system, a request to register the public key pair for authenticating the user.

Methods, systems, apparatuses, and computer program products are provided for performing user authentication to gain access to a resource by using a companion device associated with a mobile computing device. In accordance with embodiments, a first computing device (e.g., a smart watch or other companion device) includes a secure memory within which is stored a signing key pair that includes a private key and a public key, the public key being registered with a user authentication service that comprises one or more user authentication servers. The first computing device receives a user authentication request from the user authentication service via a second computing device (e.g. a smart phone or other mobile computing device with which the first computing device is paired), where the second computing device is connected to the user authentication service and wirelessly connected to the first computing device. The first computing device displays information related to the user authentication request, receives an approval of the user authentication request, and transmits the approval of the user authentication request to the second computing device. The first computing device further receives a token from the second computing device, where the token comprises a value that was obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request, signs the token with the private key to generate a signed token, and provides the signed token to the second computing device for subsequent transmission to the user authentication service. The signed token and the public key are usable by the user authentication service to determine that the user authentication request is to be granted.

In accordance with alternative embodiments, a first computing device (e.g., a smart phone or other mobile computing device) includes a secure memory within which is stored a personal identification code that is registered with a user authentication service that comprises one or more user authentication servers. The first computing device receives a user authentication request from the user authentication service to which the first computing device is connected, transmits the user authentication request to a second computing device to which the first computing device is wirelessly connected (e.g., a smart watch or other companion device that is paired with the first computing device), and receives an approval of the user authentication request form the second computing device. Subsequent to receiving the approval of the user authentication request from the second computing device, the first computing device reads the personal identification code from the secure memory and transmits it to the user authentication service. The personal identification code is usable by the user authentication service to determine that the user authentication request is to be granted.

Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

Example embodiments described herein are directed to techniques for performing user authentication to gain access to a resource by using a companion device that is communicatively connected to a mobile computing device. For example and without limitation, in one scenario the resource may comprise an online web application or service, the mobile computing device may comprise a smart phone, and the companion device may comprise a smart watch that is paired with the smart phone.

As discussed in the Background section above, smart phone applications exist that assist a user in gaining access to a resource via a primary computing device. As used herein, the term "primary computing device" is used to refer to the computing device that the user will ultimately use to interact with the resource once access thereto has been gained. For instance, such applications may enable the user to gain access to the resource using a password-less approach in which the user does not need to enter a password into the primary computing device but instead relies on a credential secured by the smart phone. Alternatively, such applications may enable the user to gain access to the resource using a multi-factor authentication (MFA) user authentication approach in which the user enters a password into the primary computing device to provide a first authentication factor and then one or more additional authentication factors are obtained from the smart phone. In accordance with such approaches, the security of the resource is increased by requiring added interaction with the user's mobile device. Furthermore, the password-less approach makes life easier for users, as they do not have to remember their password to gain access to the resource. This is desirable for numerous reasons including that many passwords are complex and thus difficult for a user to remember. Additionally, since many online applications and services now require passwords and have different rules about what qualifies as an acceptable password, it has become increasingly difficult for a user to remember each of their different passwords.

To help illustrate the foregoing, <FIG> will now be described. In particular, <FIG> is a block diagram of an example system <NUM> that authenticates a user that is seeking to gain access to a resource via her primary computing device in a manner that utilizes the user's smart phone. As shown in <FIG>, system <NUM> includes a first computing device <NUM>, a second computing device <NUM>, a user authentication service <NUM>, and a resource endpoint <NUM> that are all communicatively connected via one or more network(s) <NUM>. System <NUM> further includes a resource <NUM> that is connected to network(s) <NUM> via resource endpoint <NUM>.

First computing device <NUM> is intended to represent a computing device via which the user intends to access resource <NUM>. As discussed above, this computing device may be referred to herein as the "primary computing device. " First computing device <NUM> may comprise, for example and without limitation, a desktop computer, a tablet computer, a laptop computer, a video game console, or the like. As shown in <FIG>, first computing device <NUM> includes a web browser <NUM> that the user may interact with in order to gain access to and ultimately interact with resource <NUM>. Although a web browser <NUM> is shown in <FIG> for the sake of illustration, persons skilled in the art will appreciate that any internet-enabled application may be used to facilitate such interaction.

Second computing device <NUM> is intended to represent a smart phone or other computing device that is owned by or otherwise associated with the user. This computing device may also be referred to herein as the "secondary computing device. " As shown in <FIG>, second computing device <NUM> includes a processing circuit <NUM>, a memory <NUM>, a secure memory <NUM>, and a user interface <NUM>. Processing circuit <NUM> is configured to execute certain computer programs stored in memory <NUM>, including an operating system (OS) <NUM> and an authentication application <NUM>. As will be discussed below, authentication application <NUM> is used to assist in a user authentication process that will ultimately enable the user to gain access to resource <NUM> via first computing device <NUM>. Secure memory <NUM> is configured to store highly-sensitive information, such as one or more credentials that may be used in the aforementioned user authentication process. Secure memory <NUM> may comprise, for example, an encrypted database. Such encrypted database may be protected, for example, by an encryption key that is obtained based on information unique to second computing device <NUM> in combination with a user-defined passcode, although this is only one example. User interface <NUM> comprises a means by which the user can interact with second computing device <NUM> and may comprise, in an example in which second computing device <NUM> is a smart phone, a touch sensitive display and one or more buttons or switches.

Resource <NUM> is intended to represent a resource that the user wishes to access and to which access is allowed only to authenticated users. Resource <NUM> may comprise, for example and without limitation, an online web application or service that requires the user to be authenticated prior to obtaining access, although this example is not intended to be limiting. Such online web application or service may be executing on one or more computing devices, as is known in the art.

Network <NUM> is intended to represent one or more physical links between computing devices or other electronic devices that enable the communication of data there between. Network <NUM> may include any type of network, including but not limited to a local area networks (LAN), wide area network (WAN) such as the Internet, a telecommunication network, or the like. Network <NUM> may further comprise one or more wired and/or wireless networks. Communication over network <NUM> may be carried out using any of a wide variety of well-known wired and wireless network communication protocols.

When a user wishes to access resource <NUM> via first computing device <NUM>, the user may interact with web browser <NUM> in a well-known manner to cause web browser <NUM> to send an access request to resource endpoint <NUM>. Resource endpoint <NUM> comprises one or more computing devices that operate to receive such access requests and to grant or deny access to resource <NUM> based on whether the user associated with the request is authorized to access resource <NUM>. If user authentication is required to access resource <NUM>, then resource endpoint <NUM> will invoke user authentication service <NUM> to authenticate the user prior to determining whether or not to grant or deny access to resource <NUM>. User authentication service <NUM>, which is also implemented on one or more computing devices, may then initiate a user authentication process to authenticate the user in a manner that involves both first computing device <NUM> and second computing device <NUM>.

One such user authentication process, which may be referred to as a password-less user authentication process, will now be described. In accordance with this process, user authentication service <NUM> prompts the user, via web browser <NUM>, to either enter a password required for user authentication or to elect to perform user authentication in a manner that does not require entering such a password. If the user elects to perform password-less user authentication, then user authentication service <NUM> interacts with authentication application <NUM> executing on second computing device <NUM> to obtain therefrom a user credential stored in secure memory <NUM>. Upon receipt of this secured user credential, user authentication service <NUM> may then authorize the user to access resource <NUM>. For example, user authentication service <NUM> may authorize the user to access resource <NUM> by sending a suitable access token back to resource endpoint <NUM>. Upon receipt of the access token, resource endpoint <NUM> then provides the user with access to resource <NUM> via first computing device <NUM>.

Authentication application <NUM> may provide the secured user credential to user authentication service <NUM>, for example, by signing a value (e.g., a blob or cryptographic nonce value) provided by user authentication service <NUM> with a private signing key that is stored in secure memory <NUM> and then returning the signed value to user authentication service <NUM>. User authentication service <NUM> can then verify the signed value using a previously-registered public signing key that corresponds to the private signing key. However, this is only one example of a way in which authentication application <NUM> can provide a user credential to user authentication service <NUM>, and various other user credentials and techniques may be used.

Before providing the user credential to user authentication service <NUM>, authentication application <NUM> requires the user to authorize the access attempt through some form of interaction with user interface <NUM> of second computing device <NUM>. For example, the user may be required to indicate via user interface <NUM> that the access attempt should be allowed. As another example, the user may be required to select a number or code displayed on user interface <NUM> that is identical to one displayed via web browser <NUM> of first computing device <NUM> or provide a response to some other security challenge. Still other means for obtaining user authorization of the access attempt may be used. In an example scenario in which second computing device <NUM> is a smart phone, the user must be able to find and unlock their smart phone in order to carry out such interaction with user interface <NUM>.

An alternative user authentication process, which may be referred to as a multi-factor authentication (MFA) user authentication process, will now be described. In accordance with this process, user authentication service <NUM> prompts the user, via web browser <NUM>, to enter a password required for user authentication. The password serves as a first authentication factor. User authentication service <NUM> then also interacts with authentication application <NUM> executing on second computing device <NUM> to obtain therefrom one or more additional authentication factors. In this example, a personal identification code that is stored in secure memory <NUM> and provided to user authentication service <NUM> provides an additional authentication factor. Upon receipt of the personal identification code, user authentication service <NUM> may then authorize the user to access resource <NUM>. For example, user authentication service <NUM> may authorize the user to access resource <NUM> by sending a suitable access token back to resource endpoint <NUM>. Upon receipt of the access token, resource endpoint <NUM> then provides the user with access to resource <NUM> via first computing device <NUM>.

Authentication application <NUM> may provide the personal identification code to user authentication service <NUM>, for example, by reading the personal identification code from secure memory <NUM> and transmitting the personal identification code to user authentication service <NUM>. User authentication service <NUM> can then compare the personal identification code to a previously-registered personal identification code to make sure that they match.

Before providing the personal identification code to user authentication service <NUM>, authentication application <NUM> may require the user to authorize the access attempt through some form of interaction with user interface <NUM> of second computing device <NUM>. For example, the user may be required to select a number or code displayed on user interface <NUM> that is identical to one displayed via web browser <NUM> of first computing device <NUM> or provide a response to some other security challenge. However, this is not intended to be limiting and other means for obtaining user authorization of the access attempt may be used. As also noted above with respect to the password-less approach, in an example scenario in which second computing device <NUM> is a smart phone, the user must be able to find and unlock their smart phone in order to carry out such interaction with user interface <NUM>.

As previously described, in a scenario in which second computing device <NUM> is a smart phone, authorization application <NUM> assists the user in gaining access to the resource via first computing device <NUM> but requires the user to find and unlock the smart phone in order to interact with authorization application <NUM>. This may be deemed undesirable as a user's smart phone may not be easily located and/or unlocked by the user at the time the user authentication process is taking place. For example, the user's smart phone may be misplaced or otherwise not readily accessible, or the user may be in a situation where finding and unlocking her smart phone is not possible. To address this issue, embodiments described herein enable the user authentication process to be carried out via user interaction with a companion device that is communicatively connected to the smart phone, instead of the smart phone itself. Since the companion device may comprise, for example, a smart watch or other wearable computing device, the user may have better and/or easier access to it. Furthermore, embodiments described herein enable the authentication process to be carried out while the smart phone remains in a locked state, which means that the user does not need to find and/or unlock the smart phone to complete the user authentication process.

As will also be discussed herein, embodiments described herein rely on wireless communication between a mobile computing device, such as a smart phone, and a companion device, such as a smart watch or other wearable computing device, to carry out a user authentication process using credentials that are stored on either the mobile computing device or the wearable computing device. However, in accordance with the embodiments described herein, such credentials are never passed between the mobile computing device and the companion device. This approach advantageously protects the security of those credentials by ensuring that they cannot be obtained by a malicious party by monitoring (or "sniffing") wireless communications between the mobile computing device and the companion device.

To help illustrate the foregoing, <FIG> will now be described. In particular, <FIG> is a block diagram of an example system <NUM> that authenticates a user that is seeking to gain access to a resource via her primary computing device in a manner that utilizes a user's companion device (e.g., a smart watch or other wearable device) paired with the user's mobile computing device (e.g., a smart phone), according to an example embodiment. As shown in <FIG>, system <NUM> includes some of the same components as shown in <FIG>, and these components may operate in a substantially similar manner with exceptions that will now be described.

As shown in <FIG>, second computing device <NUM> of system <NUM> stores a mobile device authentication application <NUM> in memory <NUM> in place of authentication application <NUM>. As will be discussed hereinafter, mobile device authentication application <NUM> is configured to interact with a companion device authentication application <NUM> executing on third computing device <NUM> and user authentication service <NUM> to carry out a user authentication process in which the user interacts with third computing device <NUM>. Furthermore, mobile device authentication application <NUM> is configured to interact with companion device authentication application <NUM> and user authentication service <NUM> while second computing device <NUM> is in an unlocked state or a locked state. As used herein, the term "locked state" is used to refer to a state where the user is prevented from accessing the full functionality of second computing device <NUM> until a credential is entered, such as a biometric identifier or a previously-registered passcode. Furthermore, the term "unlocked state" is used to refer to a state where the user is allowed to access the full functionality of second computing device <NUM>.

In particular, and as shown in <FIG>, system <NUM> further includes third computing device <NUM> that is communicatively connected to second computing device <NUM>. Third computing device <NUM> is intended to represent a companion computing device, such as a smart watch or other wearable computing device, that is owned by or otherwise associated with the user and that may be communicatively linked with second computing device <NUM>. In an embodiment, third computing device <NUM> is connected to second computing device <NUM> via a wireless connection, such as a Bluetooth connection or an IEEE <NUM> connection. However, this is only an example, and any type of wired or wireless connection may be used to facilitate communication between third computing device <NUM> and second computing device <NUM>.

As shown in <FIG>, third computing device <NUM> includes a processing circuit <NUM>, a memory <NUM>, a secure memory <NUM>, and a user interface <NUM>. Processing circuit <NUM> is configured to execute certain computer programs stored in memory <NUM>, including an operating system (OS) <NUM> and companion device authentication application <NUM>. As will be discussed below, companion device authentication application <NUM> is used to assist in a user authentication process that will ultimately enable the user to gain access to resource <NUM> via first computing device <NUM> by interacting with user authentication service <NUM> via mobile device authentication application <NUM> of second computing device <NUM>. Secure memory <NUM> is configured to store highly-sensitive information, such as one or more credentials that may be used in the aforementioned user authentication process. Secure memory <NUM> may comprise, for example, an encrypted database. Such encrypted database may be protected, for example, by an encryption key that is obtained based on information unique to third computing device <NUM> in combination with a user-defined passcode, although this is only one example. User interface <NUM> comprises a means by which the user can interact with third computing device <NUM> and may comprise, in an example in which third computing device <NUM> is a smart watch, a touch sensitive display and one or more buttons. It should be noted that in the example embodiment of <FIG>, third computing device <NUM> is in an "unlocked state," meaning that the user is enabled to fully interact with third computing device <NUM>. For instance, in an example where third computing device <NUM> is a smart watch, the smart watch is unlocked and on the user's wrist.

In the approach represented by system <NUM>, when a user wishes to access resource <NUM> via first computing device <NUM>, the user may interact with web browser <NUM> to cause web browser <NUM> to send an access request to resource endpoint <NUM> and if user authentication is required to access resource <NUM>, resource endpoint <NUM> will invoke user authentication service <NUM> to authenticate the user prior to determining whether or not to grant or deny access to resource <NUM>. However, the user authentication process that is performed will not only involve first computing device <NUM> and second computing device <NUM> but will also involve third computing device <NUM>. As will be described hereinafter, this approach enables the user to interact with third computing device <NUM> while second computing device <NUM> remains in a locked state.

In accordance with the example of <FIG>, one such user authentication process may be a password-less user authentication process. In accordance with this process, user authentication service <NUM> prompts the user, via web browser <NUM>, to either enter a password required for user authentication or to elect to perform user authentication in a manner that does not require entering such a password. If the user elects to perform password-less user authentication, then user authentication service <NUM> interacts with companion device authentication application <NUM> executing on third computing device <NUM> (via mobile device authentication application <NUM>) to obtain therefrom a user credential stored in secure memory <NUM>. Upon receipt of this secured user credential, user authentication service <NUM> may then authorize the user to access resource <NUM>. For example, user authentication service <NUM> may authorize the user to access resource <NUM> by sending a suitable access token back to resource endpoint <NUM>. Upon receipt of the access token, resource endpoint <NUM> then provides the user with access to resource <NUM> via first computing device <NUM>.

Companion device authentication application <NUM> may provide the secured user credential to user authentication service <NUM>, for example, by signing a token that includes a value (e.g., a blob or nonce value) provided by user authentication service <NUM> with a private signing key that is stored in secure memory <NUM> and then returning the signed token to user authentication service <NUM> via mobile device authentication application <NUM>. User authentication service <NUM> can then verify the signed token using a previously-registered public signing key that corresponds to the private signing key. However, this is only one example of a way in which companion device authentication application <NUM> can provide a user credential to user authentication service <NUM>, and various other user credentials and techniques may be used.

Before providing the user credential to user authentication service <NUM>, companion device authentication application <NUM> requires the user to authorize the access attempt through some form of interaction with user interface <NUM> of third computing device <NUM>. For example, the user may be required to simply indicate via user interface <NUM> that the access attempt should be allowed. As another example, the user may be required to select a number or code displayed on user interface <NUM> that is identical to one displayed via web browser <NUM> of first computing device <NUM> or provide a response to some other security challenge. Still other means for obtaining user authorization of the access attempt may be used. In an example scenario in which second computing device <NUM> is a smart phone and third computing device <NUM> is a smart watch, the user is enabled to carry out the authentication process by interacting only with the smart watch, and is not required to find or unlock the smart phone. Furthermore, the private signing key is never passed between the smart watch and the smart phone, which enhances the security of the system.

In further accordance with the example of <FIG>, an alternative user authentication process may be an MFA user authentication process. In accordance with this process, user authentication service <NUM> prompts the user, via web browser <NUM>, to enter a password required for user authentication. The password serves as a first authentication factor. User authentication service <NUM> then also interacts with companion device authentication application <NUM> executing on third computing device <NUM> (via mobile device authentication application <NUM> executing on second computing device <NUM>) to obtain one or more additional authentication factors. In this example, a personal identification code that is stored in secure memory <NUM> and provided to user authentication service <NUM> provides an additional authentication factor. Upon receipt of the personal identification code, user authentication service <NUM> may then authorize the user to access resource <NUM>. For example, user authentication service <NUM> may authorize the user to access resource <NUM> by sending a suitable access token back to resource endpoint <NUM>. Upon receipt of the access token, resource endpoint <NUM> then provides the user with access to resource <NUM> via first computing device <NUM>.

Mobile device authentication application <NUM> may provide the personal identification code to user authentication service <NUM>, for example, by reading the personal identification code from secure memory <NUM> and transmitting the personal identification code to user authentication service <NUM>. Mobile device authentication application <NUM> may read the personal identification code from secure memory <NUM> in response to receiving an approval from companion device authentication application <NUM>. User authentication service <NUM> can then compare the personal identification code to a previously-registered personal identification code to make sure that they match.

Before providing the approval to mobile device authentication application <NUM> such that personal identification code may be read and provided to user authentication service <NUM>, mobile device authentication application <NUM> may require the user to authorize the access attempt through some form of interaction with user interface <NUM> of third computing device <NUM>. For example, the user may be required to select a number or code displayed on user interface <NUM> that is identical to one displayed via web browser <NUM> of first computing device <NUM> or provide a response to some other security challenge. However, this is not intended to be limiting and other means for obtaining user authorization of the access attempt may be used. As also noted above with respect to the password-less approach, in an example scenario in which second computing device <NUM> is a smart phone and third computing device <NUM> is a smart watch, the user is enabled to carry out the authentication process by interacting only with the smart watch and need not find or unlock the smart phone. Furthermore, the personal identification code is never passed between the smart phone and the smart watch, which enhances the security of the system.

The aforementioned approaches may be carried out in various ways. A particular example of how an embodiment may operate in accordance with the foregoing techniques will now be described in reference to <FIG>. In particular, <FIG> is an example sequence diagram <NUM> for generating and securely storing a signing key pair on a companion device and for registering a public key of the signing key pair with an authentication service to facilitate a password-less user authentication process, according to an example embodiment. As shown in <FIG>, sequence diagram <NUM> shows interactions between various components that were described above in reference to <FIG>. In particular, sequence diagram <NUM> shows interactions between third computing device <NUM> and second computing device <NUM>, and between second computing device <NUM> and user authentication service <NUM>.

As shown in <FIG>, companion device authentication application <NUM> executing on third computing device <NUM> generates a signing key pair (<NUM>), wherein the signing key pair comprises a private key and a public key.

In an embodiment, companion device authentication application <NUM> performs operation (<NUM>) only if a personal identification code (such as a PIN) has been enabled for third computing device <NUM>. Such personal identification code may be required, for example, to unlock third computing device <NUM> and interact with companion device authentication application <NUM>. By requiring the enabling of such a personal identification code before performing operation (<NUM>), an embodiment thereby ensures that the user will be required to enter the personal identification code before interacting with companion device authentication application <NUM> to carry out the aforementioned password-less user authentication process.

In further accordance with such an embodiment, if at some later point in time, companion device authentication application <NUM> determines that the personal identification code has been disabled for third computing device <NUM>, then companion device authentication application may delete the signing key pair. Again, this ensures that the password-less user authentication process will only work if third computing device <NUM> requires a personal identification code to be entered before the user may interact with companion device authentication application <NUM>.

In further accordance with this example, companion device authentication application <NUM> executing on third computing device <NUM> transmits the public key to mobile device authentication application <NUM> executing on second computing device <NUM> (<NUM>) such that the public key may be registered with user authentication service <NUM>. The public key may be registered in various ways. For example, and as shown in <FIG>, mobile device authentication application <NUM> first obtains and provides some user authentication input to user authentication service <NUM> (<NUM>). The user authentication input may comprise user input that provides for strong authentication. In response to receiving the user authentication input, user authentication service <NUM> provides a time-limited token to mobile device authentication application <NUM> (<NUM>). Mobile device authentication application <NUM> then utilizes the time-limited token to transmit a request to user authentication service <NUM> to register the public key (<NUM>). In embodiments, the request may include the time-limited token along with the public key. User authentication service <NUM> then registers the public key.

Once the public key has been registered by user authentication service <NUM>, user authentication service <NUM> generates and transmits a server key identifier to mobile device authentication application executing on second computing device <NUM> (<NUM>). The server key identifier may comprise an identifier of the public key that is maintained by the user authentication service <NUM> and that may be used in future communications therewith to identify the public key. The server key identifier may be much shorter than the public key itself and using it in subsequent communications may enhance efficiency. In response to receiving the server key identifier, second computing device <NUM> forwards the server key identifier to third computing device <NUM> (<NUM>). Third computing device <NUM> then stores the signing key pair, a local identifier thereof and the server key identifier (<NUM>).

Following the example of <FIG>, <FIG> is an example sequence diagram <NUM> for carrying out the password-less user authentication process, according to an example embodiment. As shown in <FIG>, user authentication service <NUM> transmits a user authentication request to second computing device <NUM> and operating system <NUM> executing thereon passes the user authentication request to operating system <NUM> executing on third computing device <NUM> (<NUM>). Operating system <NUM> then passes the user authentication request to companion device authentication application <NUM>.

As further shown in <FIG>, companion device authentication application <NUM> executing on third computing device <NUM> transmits an approval of the user authentication request to mobile device authentication application <NUM> executing on second computing device <NUM> (<NUM>). For instance, and with reference to <FIG>, companion device authentication application <NUM> may display information related to the user authentication request to the user via user interface <NUM> such that the user may approve or deny the user authentication request. In an embodiment, the user authentication request may include a challenge such that the approval of the user authentication request includes the user's response to the challenge.

In response to receiving the approval, mobile device authentication application <NUM> executing on second computing device <NUM> sends a value request to user authentication service <NUM> (<NUM>). In response to receiving the value request, user authentication service <NUM> transmits a value to mobile device authentication application <NUM> executing on second computing device <NUM> (<NUM>). In an embodiment, the value may comprise a cryptographic nonce value, although this example is not intended to be limiting.

As further shown in <FIG>, in response to receiving the value, mobile device authentication application <NUM> executing on second computing device <NUM> sends a token to companion device authentication application <NUM> executing on third computing device <NUM> (<NUM>), wherein the token includes the value. Companion device authentication application <NUM> executing on third computing device <NUM> signs the token with the securely-stored private signing key (<NUM>) and then transmits the signed token to mobile device authentication application <NUM> executing on second computing device <NUM> (<NUM>). Mobile device authentication application <NUM> then transmits the signed token to user authentication service <NUM> (<NUM>). User authentication service <NUM> utilizes the signed token and the public key to determine if the user authentication request is to be granted.

In an embodiment, user authentication service <NUM> verifies the signed token using the public key. If the signed token is verified, then the password-less user authentication is deemed successful. As shown in <FIG>, in response to a successful user authentication, user authentication service <NUM> generates and transmits a success message to operating system <NUM> executing on second computing device <NUM> (<NUM>), which forwards the success message to operating system <NUM> executing on third computing device <NUM> (<NUM>).

As noted above, various user authentication processes may be used to authenticate a user. Another example of how an embodiment may operate in accordance with the foregoing techniques will now be described in reference to <FIG>. In particular, <FIG> is an example sequence diagram <NUM> for carrying out a multi-factor authentication (MFA) user authentication process, according to an example embodiment. As shown in <FIG>, sequence diagram <NUM> shows interactions between various components that were described above in reference to <FIG>. In particular, sequence diagram <NUM> shows interactions between third computing device <NUM> and second computing device <NUM>, and between second computing device <NUM> and user authentication service <NUM>.

As shown in <FIG>, user authentication service <NUM> transmits a user authentication request to second computing device <NUM> and operating system <NUM> executing thereon passes the user authentication request to operating system <NUM> executing on third computing device <NUM> (<NUM>). Operating system <NUM> then passes the user authentication request to companion device authentication application <NUM>.

As further shown in <FIG>, companion device authentication application <NUM> executing on third computing device <NUM> transmits an approval of the user authentication request to mobile device authentication application <NUM> executing on second computing device <NUM> (<NUM>). For instance, and with reference to <FIG>, companion device authentication application <NUM> may display information related to the user authentication request to the user via user interface <NUM> such that the user may approve or deny the user authentication request. Obtaining the approval from the user may also entail the user responding to a security challenge in certain embodiments.

In response to receiving the approval, mobile device authentication application <NUM> executing on second computing device <NUM> transmits an authentication details request to user authentication service <NUM> (<NUM>). The authentication details request may represent a request to obtain additional details needed to read a personal identification code securely stored on second computing device <NUM>. As shown in <FIG>, in response to receiving the authentication details request, user authentication service <NUM> transmits authentication details to second computing device <NUM> (<NUM>). In an alternative embodiment, authentication details may not be required and mobile device authentication application <NUM> executing on second computing device <NUM> may read the personal identification code from secure memory immediately after receiving the approval.

As further shown in <FIG>, in response to receiving the authentication details, mobile device authentication application <NUM> executing on second computing device <NUM> reads the personal identification code from secure memory <NUM> (<NUM>). Mobile device authentication application <NUM> then transmits the personal identification code to user authentication service <NUM> as part of a validation request (<NUM>). User authentication service <NUM> then validates the personal identification code by comparing it to a previously-stored copy of the personal identification code. If the codes match, then the personal identification code is validated and user authentication service <NUM> sends a personal identification code valid response to mobile device authentication application <NUM> executing on second computing device <NUM> (<NUM>).

In response to receiving the valid response, mobile device authentication application <NUM> executing on second computing device <NUM> transmits an authentication result request to user authentication service <NUM> (<NUM>). Upon receiving the authentication result request, user authentication service <NUM> generates and transmits a success message to operating system <NUM> executing on second computing device <NUM> (<NUM>). Operating system <NUM> executing on second computing device <NUM> then provides the success message to operating system <NUM> executing on third computing device <NUM> (<NUM>).

<FIG> depicts a flowchart <NUM> of a method performed by a companion device as part of the password-less user authentication process, in accordance with an example embodiment. The method of flowchart <NUM> may be performed, for example, by third computing device <NUM> as described above in reference to <FIG> and <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM> in which a user authentication request is received from the user authentication service via a second computing device, where the second computing device is connected to the user authentication service and wirelessly connected to the first computing device. For example, and with continued reference to <FIG> and <FIG>, second computing device <NUM> is connected to user authentication service <NUM> and wirelessly connected to third computing device <NUM> such that a user authentication request is received from user authentication service <NUM> via second computing device <NUM>. As noted above, second computing device <NUM> may be wirelessly connected to third computing device <NUM> in various ways, such as but not limited to Bluetooth or an IEEE <NUM> connection. In embodiments, the user authentication request may comprise a challenge such as requiring the user to select a number or code displayed on user interface <NUM> that is identical to one displayed via web browser <NUM> of first computing device <NUM> or provide a response to some other security challenge.

At step <NUM>, information related to the user authentication request is displayed. For example, and with continued reference to <FIG> and <FIG>, information related to the user authentication request is displayed to the user via user interface <NUM>. This information may include a prompt for user approval and/or a response to a security challenge.

At step <NUM>, an approval of the user authentication request is received. For example, and with continued reference to <FIG> and <FIG>, an approval is received from the user via user interface <NUM> and transmitted to third computing device <NUM>. In embodiments where the user authentication request comprises a challenge, the approval may comprise a user response to the challenge.

At step <NUM>, the approval of the user authentication request is transmitted to the second computing device for subsequent transmission to the user authentication service. For example, and with continued reference to <FIG>, the approval is transmitted from third computing device <NUM> to user authentication service <NUM> via second computing device <NUM>.

At step <NUM>, a token is received from the second computing device, the token comprising a value that was obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request. For example, and with continued reference to <FIG>, a value is obtained by second computing device <NUM> from user authentication service <NUM> and transmitted to third computing device <NUM> as part of a token. As noted above, the value may comprise a cryptographic nonce value, or some other value.

At step <NUM>, the token is signed with the private key to generate a signed token. For example, and with continued reference to <FIG>, third computing device <NUM> signs the token to generate a signed token.

At step <NUM>, the signed token is provided to the second computing device for subsequent transmission to the user authentication service, the signed token and the public key being usable by the user authentication service to determine that the user authentication request is to be granted. For example, and with reference to <FIG> and <FIG>, third computing device <NUM> provides signed token <NUM> to second computing device <NUM> and second computing device <NUM> transmits signed token <NUM> to user authentication service <NUM>. User authentication service <NUM> then uses the signed token and the public key <NUM> to determine if the user authentication request is to be granted.

As noted above, prior to the password-less process being used, the signing key pair must be generated such that third computing device <NUM> may securely store the signing key pair and the public key may be registered with user authentication service <NUM>. For instance, <FIG> depicts a flowchart <NUM> of a method performed by a companion device for generating and securely storing a signing key pair and for transmitting the public key for registration at a user authentication service via a mobile computing device, in accordance with an example embodiment. The method of flowchart <NUM> may be performed, for example, by third computing device <NUM> as described above in reference to <FIG> and <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM> in which the signing key pair is generated. For example, and with continued reference to <FIG> and <FIG>, companion device authentication application <NUM> generates a signing key pair. In an embodiment, companion device authentication application <NUM> generates the signing key pair only if a personal identification code has been enabled for third computing device <NUM>.

At step <NUM>, the signing key pair is stored in secure memory of the first computing device. For example, and with continued reference to <FIG> and <FIG>, the signing key pair is stored in secure memory <NUM> of third computing device <NUM>. In an embodiment where the signing key pair is generated only if a personal identification code has been enabled for third computing device <NUM>, the signing key pair is deleted in response to determining that the personal identification code has been disabled for third computing device <NUM>.

At step <NUM>, the public key is transmitted to the second computing device such that the second computing device can register the public key with the user authentication service. For example, and with continued reference to <FIG> and <FIG>, third computing device <NUM> transmits a public key to second computing device <NUM> such that second computing device <NUM> registers the public key with user authentication service <NUM>. Second computing device <NUM> may register public key in various ways. For example, and as shown in <FIG>, second computing device <NUM> may first obtain and provide a user authentication input to user authentication service <NUM>. Second computing device <NUM> may further, in response to providing the user authentication input, receive a time-limited token from user authentication service <NUM> and utilize the time-limited token to transmit a request to register the public key with user authentication service <NUM>.

As noted above, embodiments herein describe various user authentication processes. For instance, <FIG> depicts a flowchart <NUM> of a method performed by a mobile computing device as part of the MFA user authentication process, in accordance with an example embodiment. The method of flowchart <NUM> may be performed, for example, by second computing device <NUM> as described above in reference to <FIG> and <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM> in which a user authentication request is received from the user authentication service to which the first computing device is connected. For example, and with continued reference to <FIG>, second computing device <NUM> is connected to user authentication service <NUM> such that a user authentication request is received from user authentication service <NUM>.

At step <NUM>, the user authentication request is transmitted to a second computing device to which the first computing device is wirelessly connected. For example, and with continued reference to <FIG> and <FIG>, the user authentication request is transmitted to third computing device <NUM> to which second computing device <NUM> is wirelessly connected. As noted above, second computing device <NUM> may be wirelessly connected to third computing device <NUM> in various way, such as by Bluetooth or IEEE <NUM> connection.

At step <NUM>, an approval of the user authentication request is received from the second computing device. For example, and with continued reference to <FIG> and <FIG>, the approval is received from third computing device <NUM>.

At step <NUM>, subsequent to receiving the approval of the user authentication request from the second computing device, a personal identification code is read from secure memory and transmitted to the user authentication service, the personal identification code being usable by the user authentication service to determine that the user authentication request is to be granted. For example, and with continued reference to <FIG> and <FIG>, second computing device <NUM> reads the personal identification code from secure memory <NUM> and may transmit the personal identification code to user authentication service <NUM>. As noted above, the personal identification code is usable by user authentication service <NUM> to determine if the user authentication request is to be granted.

As noted above, prior to the personal identification code being read, additional details may be required to be read. For instance, <FIG> depicts a flowchart <NUM> of additional steps that may be performed by a mobile computing device as part of the MFA user authentication process, in accordance with an example embodiment. The method of flowchart <NUM> may be performed, for example, by second computing device <NUM> as described above in reference to <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM> in which an authentication details request is transmitted to the user authentication service in response to receiving the approval of the user authentication request from the second computing device. For example, and with continued reference to <FIG>, an authentication details request is transmitted from second computing device <NUM> to user authentication service <NUM>.

At step <NUM>, authentication details are received from the user authentication service, the authentication details indicating that the personal identification code must be provided. For example, and with continued reference to <FIG>, the authentication details are transmitted from user authentication service <NUM> to second computing device <NUM>.

At step <NUM>, the personal identification code is read from the secure memory and transmitted to the user authentication service in response to receiving the authentication details. For example, and with continued reference to <FIG>, in response to second computing device <NUM> receiving authentication details, second computing device <NUM> reads personal identification code from secure memory and transmits it to user authentication service <NUM>.

Embodiments described herein may be implemented in hardware, or hardware combined with software and/or firmware. For example, embodiments described herein may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. Alternatively, embodiments described herein may be implemented as hardware logic/electrical circuitry.

As noted herein, the embodiments described, including , such as system <NUM> of <FIG>, system <NUM> of <FIG>, sequence diagram <NUM> of <FIG>, sequence diagram <NUM> of <FIG>, and sequence diagram <NUM> of <FIG>, along with any components and/or subcomponents thereof, as well any operations and portions of flowcharts/flow diagrams described herein and/or further examples described herein, may be implemented in hardware, or hardware with any combination of software and/or firmware, including being implemented as computer program code configured to be executed in one or more processors and stored in a computer readable storage medium, or being implemented as hardware logic/electrical circuitry, such as being implemented together in a system-on-chip (SoC), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). A SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits and/or embedded firmware to perform its functions.

Embodiments described herein may be implemented in one or more computing devices similar to a mobile system and/or a computing device in stationary or mobile computer embodiments, including one or more features of mobile systems and/or computing devices described herein, as well as alternative features. The descriptions of mobile systems and computing devices provided herein are provided for purposes of illustration, and are not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

<FIG> is a block diagram of an exemplary mobile system <NUM> that includes a mobile device <NUM> that may implement embodiments described herein. For example, mobile device <NUM> may be used to implement any system, client, or device, or components/subcomponents thereof, in the preceding sections. As shown in <FIG>, mobile device <NUM> includes a variety of optional hardware and software components. Any component in mobile device <NUM> can communicate with any other component, although not all connections are shown for ease of illustration. Mobile device <NUM> can be any of a variety of computing devices (e.g., cell phone, smart phone, handheld computer, Personal Digital Assistant (PDA), etc.) and can allow wireless two-way communications with one or more mobile communications networks <NUM>, such as a cellular or satellite network, or with a local area or wide area network.

Mobile device <NUM> can include a controller or processor <NUM> (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system <NUM> can control the allocation and usage of the components of mobile device <NUM> and provide support for one or more application programs <NUM> (also referred to as "applications" or "apps"). Application programs <NUM> may include common mobile computing applications (e.g., e-mail applications, calendars, contact managers, web browsers, messaging applications) and any other computing applications (e.g., word processing applications, mapping applications, media player applications).

Mobile device <NUM> can include memory <NUM>. Memory <NUM> can include non-removable memory <NUM> and/or removable memory <NUM>. Non-removable memory <NUM> can include RAM, ROM, flash memory, a hard disk, or other well-known memory devices or technologies. Removable memory <NUM> can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in GSM communication systems, or other well-known memory devices or technologies, such as "smart cards. " Memory <NUM> can be used for storing data and/or code for running operating system <NUM> and application programs <NUM>. Example data can include web pages, text, images, sound files, video data, or other data to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. Memory <NUM> can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.

A number of programs may be stored in memory <NUM>. These programs include operating system <NUM>, one or more application programs <NUM>, and other program modules and program data. Examples of such application programs or program modules may include, for example, computer program logic (e.g., computer program code or instructions) for implementing one or more of system <NUM> of <FIG>, system <NUM> of <FIG>, sequence diagram <NUM> of <FIG>, sequence diagram <NUM> of <FIG>, and sequence diagram <NUM> of <FIG>, along with any components and/or subcomponents thereof, as well any operations and portions of flowcharts/flow diagrams described herein and/or further examples described herein.

Mobile device <NUM> can support one or more input devices <NUM>, such as a touch screen <NUM>, a microphone <NUM>, a camera <NUM>, a physical keyboard <NUM> and/or a trackball <NUM> and one or more output devices <NUM>, such as a speaker <NUM> and a display <NUM>. Other possible output devices (not shown) can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, touch screen <NUM> and display <NUM> can be combined in a single input/output device. Input devices <NUM> can include a Natural User Interface (NUI).

One or more wireless modems <NUM> can be coupled to antenna(s) (not shown) and can support two-way communications between processor <NUM> and external devices, as is well understood in the art. Modem <NUM> is shown generically and can include a cellular modem <NUM> for communicating with the mobile communication network <NUM> and/or other radio-based modems (e.g., Bluetooth <NUM> and/or Wi-Fi <NUM>). At least one wireless modem <NUM> is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a public switched telephone network (PSTN).

Mobile device <NUM> can further include at least one input/output port <NUM>, a power supply <NUM>, a satellite navigation system receiver <NUM>, such as a Global Positioning System (GPS) receiver, an accelerometer <NUM>, and/or a physical connector <NUM>, which can be a USB port, IEEE <NUM> (FireWire) port, and/or RS-<NUM> port. The illustrated components of mobile device <NUM> are not required or all-inclusive, as any components can be deleted and other components can be added as would be recognized by one skilled in the art.

In an embodiment, mobile device <NUM> is configured to implement any of the above-described features of flowcharts/embodiments herein. Computer program logic for performing any of the operations, steps, and/or functions described herein may be stored in memory <NUM> and executed by processor <NUM>.

<FIG> is a block diagram of an example computing device that may be used to implement various embodiments. For example, embodiments described herein may be implemented in one or more computing devices similar to computing device <NUM> in stationary or mobile computer embodiments, including one or more features of computing device <NUM> and/or alternative features. The description of computing device <NUM> provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems and/or game consoles, etc., as would be known to persons skilled in the relevant art(s).

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system <NUM>, one or more application programs <NUM>, other programs <NUM>, and program data <NUM>. Application programs <NUM> or other programs <NUM> may include, for example, computer program logic (e.g., computer program code or instructions) for implementing embodiments described herein, such as system <NUM> of <FIG>, system <NUM> of <FIG>, sequence diagram <NUM> of <FIG>, sequence diagram <NUM> of <FIG>, and sequence diagram <NUM> of <FIG>, along with any components and/or subcomponents thereof, as well any operations and portions of flowcharts/flow diagrams described herein and/or further examples described herein.

Display screen <NUM> may be external to or incorporated in computing device <NUM>.

As used herein, the terms "computer program medium," "computer-readable medium," and "computer-readable storage medium," etc., are used to refer to physical hardware media such as the hard disk associated with hard disk drive <NUM>, removable magnetic disk <NUM>, removable optical disk <NUM>, other physical hardware media such as RAMs, ROMs, flash memory cards, digital video disks, zip disks, MEMs, nanotechnology-based storage devices, and further types of physical/tangible hardware storage media (including memory <NUM> of <FIG>). Such computer-readable media and/or storage media are distinguished from and non-overlapping with communication media and propagating signals (do not include communication media and propagating signals).

Embodiments are also directed to computer program products comprising computer code or instructions stored on any computer-readable medium or computer-readable storage medium.

A system includes a first computing device. The first computing device includes a processing circuit; a secure memory connected to the processing circuit, the secure memory storing a signing key pair that includes a private key and a public key, the public key being registered with a user authentication service that comprises one or more user authentication servers; and a memory connected to the processing circuit, the memory storing computer program instructions, the computer program instructions being executable by the processing circuit to cause the processing circuit to: receive via a second computing device a user authentication request from the user authentication service, the second computing device being connected to the user authentication service and wirelessly connected to the first computing device; display information related to the user authentication request; receive an approval of the user authentication request; transmit the approval of the user authentication request to the second computing device; receive a token from the second computing device, the token comprising a value that was obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request; sign the token with the private key to generate a signed token; and provide the signed token to the second computing device for subsequent transmission to the user authentication service, the signed token and the public key being usable by the user authentication service to determine that the user authentication request is to be granted.

In one embodiment of the foregoing system, the user authentication request comprises a challenge and wherein the approval of the user authentication request includes a user response to the challenge.

In another embodiment of the foregoing system, the first computing device comprises a wearable computing device.

In further accordance with such an embodiment, the wearable computing device comprises a smart watch.

In still a further embodiment of the foregoing system, the wearable computing device is in an unlocked state.

In another embodiment of the foregoing system, the second computing device comprises a smart phone.

In yet another embodiment of the foregoing system, the smart phone is in a locked state.

In still another embodiment of the foregoing system, the first computing device is wirelessly connected to the second computing device via a Bluetooth connection.

In a further embodiment of the foregoing system, the first computing device is wirelessly connected to the second computing device via an IEEE <NUM> connection.

In still another further embodiment of the foregoing system, the value comprises a cryptographic nonce value.

In another embodiment of the foregoing system, the system further comprises the second computing device; wherein the computer program instructions are further executable by the processing circuit to cause the processing circuit to: generate the signing key pair; store the signing key pair in the secure memory; and transmit the public key to the second computing device; and wherein the second computing device is configured to: register the public key with the user authentication service.

In yet another embodiment of the foregoing system, the computer program instructions are further executable by the processing circuit to cause the processing circuit to: generate the signing key pair only if a personal identification code has been enabled for the first computing device.

In yet another embodiment of the foregoing system, the computer program instructions are further executable by the processing circuit to cause the processing circuit to: delete the signing key pair in response to determining that the personal identification code has been disabled for the first computing device.

In yet another embodiment of the foregoing system, the second computing device is configured to register the public key with the user authentication service by: obtaining user authentication input; providing the user authentication input to the user authentication service; receiving a time-limited token from the user authentication service in response to providing the user authentication input; and utilizing the time-limited token to register the public key with the user authentication service.

Another system comprising a first computing device is also described herein. a first computing device, including: a processing circuit; a secure memory connected to the processing circuit, the secure memory storing a personal identification code, the personal identification code being registered with a user authentication service that comprises one or more user authentication servers; a memory connected to the processing circuit, the memory storing computer program instructions, the computer program instructions being executable by the processing circuit to cause the processing circuit to: receive a user authentication request from the user authentication service to which the first computing device is connected; transmit the user authentication request to a second computing device to which the first computing device is wirelessly connected; receive an approval of the user authentication request from the second computing device; and subsequent to receiving the approval of the user authentication request from the second computing device, read the personal identification code from the secure memory and transmit it to the user authentication service, the personal identification code being usable by the user authentication service to determine that the user authentication request is to be granted.

In another embodiment of the foregoing system, the computer program instructions are further executable by the processing circuit to cause the processing circuit to: transmit an authentication details request to the user authentication service in response to receiving the approval of the user authentication request from the second computing device; receive authentication details from the user authentication service, the authentication details indicating that the personal identification code must be provided; and read the personal identification code from the secure memory and transmit it to the user authentication service in response to receiving the authentication details.

In yet another embodiment of the foregoing system, the second computing device comprises a wearable computing device.

In yet another embodiment of the foregoing system, the wearable computing device comprises a smart watch.

In yet another embodiment of the foregoing system, the wearable computing device is in an unlocked state.

In yet another embodiment of the foregoing system, the first computing device comprises a smart phone.

In yet another embodiment of the foregoing system, the first computing device is wirelessly connected to the second computing device via a Bluetooth connection.

In yet another embodiment of the foregoing system, the first computing device is wirelessly connected to the second computing device via an IEEE <NUM> connection.

A method in a first computing device that stores a signing key pair that includes a private key and a public key, the public key being registered with a user authentication service that comprises one or more user authentication servers is also described herein. The method comprises receiving, via a second computing device, a user authentication request from the user authentication service, the second computing device being connected to the user authentication service and wirelessly connected to the first computing device; displaying information related to the user authentication request; receiving an approval of the user authentication request; transmitting the approval of the user authentication request to the second computing device; receiving a token from the second computing device, the token comprising a value that was obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request; signing the token with the private key to generate a signed token; and providing the signed token to the second computing device for subsequent transmission to the user authentication service, the signed token and the public key being usable by the user authentication service to determine that the user authentication request is to be granted.

In another embodiment of the foregoing method, the user authentication request comprises a challenge and wherein the approval of the user authentication request includes a user response to the challenge.

In yet another embodiment of the foregoing method, the first computing device comprises a wearable computing device.

In yet another embodiment of the foregoing method, the wearable computing device is in an unlocked state.

In yet another embodiment of the foregoing method, the second computing device comprises a smart phone.

In yet another embodiment of the foregoing method, the smart phone is in a locked state.

In yet another embodiment of the foregoing method, the first computing device is wirelessly connected to the second computing device via a Bluetooth connection.

In yet another embodiment of the foregoing method, the first computing device is wirelessly connected to the second computing device via an IEEE <NUM> connection.

In yet another embodiment of the foregoing method, the value comprises a cryptographic nonce value.

In yet another embodiment of the foregoing method, the method further comprises generating the signing key pair; storing the signing key pair in secure memory of the first computing device; and transmitting the public key to the second computing device such that the second computing device can register the public key with the user authentication service.

In yet another embodiment of the foregoing method, generating the signing key pair only if a personal identification code has been enabled for the first computing device.

In yet another embodiment of the foregoing method, deleting the signing key pair in response to determining that the personal identification code has been disabled for the first computing device.

Claim 1:
A system (<NUM>), comprising:
a user authentication service (<NUM>), that comprises one or more user authentication servers;
a first computing device (<NUM>), including:
a processing circuit (<NUM>);
a secure memory (<NUM>) connected to the processing circuit (<NUM>), the secure memory storing a signing key pair that includes a private key and a public key, the public key being registered with the user authentication service (<NUM>); and
a memory (<NUM>) connected to the processing circuit (<NUM>), the memory (<NUM>) storing computer program instructions, the computer program instructions being executable by the processing circuit (<NUM>) to cause the processing circuit (<NUM>) to:
receive via a second computing device (<NUM>) a user authentication request from the user authentication service (<NUM>), the second computing device (<NUM>) being connected to the user authentication service (<NUM>) and the first computing device being wirelessly connected to the second computing device;
in response to receiving the user authentication request, display information related to the user authentication request;
receive an approval of the user authentication request, based on the displayed information;
in response to receiving the approval, transmit the approval of the user authentication request to the second computing device (<NUM>) to cause the second computing device to obtain a value from the user authentication service;
in response to receiving a token from the second computing device, the token comprising the value obtained from the user authentication service, sign the token with the private key to generate a signed token; and
provide the signed token to the second computing device (<NUM>) to cause the second computing device to transmit the signed token to the user authentication service (<NUM>), the signed token and the public key being used by the user authentication service (<NUM>) to determine that the user authentication request is to be granted.