Patent Description:
This present disclosure generally relates to two-factor authentication, and more particularly to systems and methods for providing two-factor authentication as a service.

Traditionally, simple username/password combinations have been used as log-in credentials. For a more secure application, two-factor authentication may be used. For example, two-factor authentication often requires "something you know" (e.g., a password) and "something you have" (e.g., a telephone number or an authentication dongle). Two-factor authentication systems can be problematic for application developers, though, because each application developer maintains its own secure databases to store this information and confirm user identities. Additionally, two-factor authentication can be inconvenient for users. For example, users may not want to use their phone number as part of a two-factor authentication because they desire to keep their phone numbers private. Further, phone numbers may not be applicable for certain devices (e.g., tablets), and reliance on a phone number in two-factor authentication may require additional steps such as receiving and inputting confirmation codes. Finally, it can be inconvenient for a user to carry around an additional device merely to aid in completing a two-part authentication.

Accordingly, there is a need for an authentication process that relieves developers of the burden of authentication and credential storage, does not inconvenience users, and is applicable to a wide range of devices and uses.

<CIT> various systems and methods for implementing password-free authentication, wherein a request to access a network resource is received at a server, from a client device and the request is verified, and an authentication reservation is created for the device, with the authentication reservation allowing the device to access the network resource. Later, when an attempt to access the network resource is received, the attempt is granted access to the network resource in response to matching information contained in the attempt with information stored in the authentication reservation.

According to certain aspects of the present disclosure, there is provided a method including: receiving, from an application executing on a computing device and by an authentication process executing on the computing device, data representative of user credentials corresponding to the application, the authentication process being isolated from the application; packaging, by the authentication process, the data representative of user credentials with a device identification assigned to the computing device and an indication that the user credentials correspond to the application, the device identification being hidden from the application; outputting for transmission, by the authentication process and to an authentication server, an authentication request containing the packaged user credentials and device identification; receiving, by the authentication process and from the authentication server, an indication of authentication of the user credentials; and forwarding the received indication from the authentication process to the application.

The device identification may be used for message routing between the authentication server and the computing device; and the user credentials include a username and password, and the password is not communicated to an application server corresponding to the application.

The method may further include: receiving, by an authentication process executing on a computing device, data representative of user credentials corresponding to an application; packaging, by the authentication process, the data representative of user credentials with a device identification assigned to the computing device; outputting for transmission, by the authentication process and to an authentication server, an authentication request containing the packaged user credentials and device identification; and receiving, by the authentication process and from the authentication server, and in response to the authentication request, an indication of authentication of the user credentials.

The device identification may be hidden from the application.

The method may further include forwarding the indication from the authentication process to the application.

The method may further include outputting for transmission, by the authentication process and to an application server associated with the application, the indication.

The packaging may include packaging the user credentials with the device identification and an indication that the user credentials correspond to the application.

The authentication server may store the user credentials in a table with the device identification serving as a key to an entry in the table.

The device identification may be used for message routing between the authentication server and the computing device.

The user credentials may include a username and password, and the password is not communicated to an application server corresponding to the application.

The method may further include maintaining a persistent secured connection between the computing device and the authentication server. The user device may transmit the authentication request to and receives the indication of authentication of the user credentials from the authentication server over the persistent secured connection.

The receiving data representative of user credentials may include receiving the data from the application.

The authentication process may be isolated from the application.

The method may further include: in response to the indication of authentication of the user credentials indicating that no user credentials are associated with the device identification, outputting for display an indication that no user credentials are associated with the computing device; receiving a user indication to associate the computing device with another computing device; outputting for transmission, by the authentication process and to the authentication server after the device identification assigned to the computing device is associated with a device identification assigned to the another computing device, a new authentication request containing the user credentials packaged with the device identification of the computing device; receiving, by the authentication process and from the authentication server, and in response to the new authentication request, a new indication of authentication of the user credentials; and forwarding the new indication from the authentication process to the application.

The indication received in response to the authentication request may be not forwarded to the application.

According to certain aspects of the present disclosure, there is provided a non-transitory computer readable medium having stored thereon computer program code that, when executed by a processor on a computing device, instructs the processor to implement an authentication process including: receiving, from an application executing on the computing device, data representative of user credentials corresponding to the application, the authentication process being isolated from the application; packaging the data representative of user credentials with a device identification assigned to the computing device; outputting for transmission, to an authentication server, an authentication request containing the packaged user credentials and device identification; and receiving, from the authentication server, an indication of authentication of the user credentials.

The authentication process may further include communicating the indication from the authentication process to the application.

The authentication process may further include outputting for transmission, to an application server corresponding to the application, the indication.

The scope of the invention is defined by the independent claims.

Reference will now be made to the accompanying figures, which are not necessarily drawn to scale, and wherein:.

The present disclosure can be understood more readily by reference to the following detailed description of exemplary embodiments and the examples included herein. It is to be understood that embodiments are not limited to those described within this disclosure. Numerous modifications and variations therein will be apparent to those skilled in the art and remain within the scope of the disclosure. It is also to be understood that the specific terminology used herein is for describing specific embodiments only and is not intended to be limiting. Some embodiments of the disclosed technology will be described more fully hereinafter with reference to the accompanying drawings. This disclosed technology may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth therein.

Certain embodiments of the disclosed technology include systems and methods for providing two-factor authentication service for third-party applications. A centralized repository (or credential store) stores username and password pairs in connection with a unique device identifier (ID) (e.g., at an authentication server of an authentication service). Only the authentication service and the device know the device ID. A third-party application executing on the device receives log-in credentials from a user and forwards those credentials to an authentication process executing on the device. The authentication process combines the log-in credentials with the device ID and securely transmits the combination to the authentication service, which then informs the authentication process as to whether the log-in credentials match the stored credentials associated with that device ID. The authentication process then forwards the response to the third-party application. Accordingly, the third-party application is relieved from the burdens of user authentication, and secure two-factor authentication may be provided without additional burdens on the user.

Referring now to the drawings, <FIG> is a block-diagram of an environment <NUM> for implementing certain aspects of the present disclosure. As shown in <FIG>, in some implementations the environment <NUM> includes a user device <NUM>, an authentication server <NUM>, and an application server <NUM>. As non-limiting examples, the user device <NUM> may be a personal computer, a smartphone, a laptop computer, or other personal computing device. The authentications server <NUM> and the application server <NUM> may include one or more physical or logical devices (e.g., servers). The user device <NUM> may be configured to communicate with both the authentication server <NUM> and the application server <NUM>. The user device <NUM> can run an application <NUM> corresponding to or associated with the application server <NUM>. The user device <NUM> may receive log-in credentials (e.g., a username and password) for the application <NUM>. For example, the log-in credentials may be sent as part of a message. The user device <NUM> can then combine the log-in credentials with a device identifier (ID) specific to the user device <NUM>, and then send all three (i.e., username, password, and device ID) to the authentication server <NUM>, for example, as part of a message. The log-in credentials may be identified as corresponding to the application <NUM>.

In certain implementations according to the present disclosure, the authentication server <NUM> stores credentials (e.g., usernames and passwords) for the application <NUM> in association the device ID. For example, the authentication server <NUM> may have one or more data tables with columns of credentials for one or more applications and rows keyed to the device ID. The authentication server <NUM> compares the credentials received from the user device <NUM> with the stored credentials, and returns a response to the user device <NUM>. The response could be SUCCESS, indicating that the username and passwords are valid for the device ID for the application <NUM>. Additional potential responses are discussed below in greater detail.

The user device <NUM> may receive the response from the authentication server <NUM> and forward the received response to the application server <NUM>, for example, as part of a message. If the response is a SUCCESS, the application server <NUM> may then provide access to user-data, e.g., a user account, to the application <NUM> executing on the user device <NUM> (e.g., the user may then use the application <NUM>). In some embodiments, the application server <NUM> may provide access to the user data through the routing of messages that include the user data.

In some embodiments, the user device <NUM> may not communicate the response out to the application server <NUM> but may instead communicate the response directly to the application <NUM> executing on the user device <NUM>. As above, if the response is a SUCCESS, the application <NUM> may provide access to user-data (e.g., the user may then use the application <NUM>).

In some implementations, the device ID may be a secret known only to the authentication server <NUM> and the user device <NUM>. Thus, in some cases, the device ID is hidden from the application <NUM> executing on the user device <NUM>. In such cases, the application <NUM> may communicate with an authentication process <NUM> executing on the user device <NUM>. The authentication process <NUM> may receive the log-in credentials from the application <NUM> and combine the credentials with the device ID, which can then be communicated to the authentication server <NUM>.

In some cases, the user device <NUM> may not have an existing device ID, and the authentication server <NUM> may provide the device ID to the user device <NUM>. The device ID may be a logical entity (e.g., as opposed to a permanent or quasi-permanent designation like International Mobile Equipment Identity (IMEI)). Accordingly, the device ID may be changed throughout the lifetime of the device. For example, the authentications server <NUM> may provide a new device ID upon factory reset. In some embodiments, user device <NUM> and the authentication server <NUM> may communicate using a secured connection, which prevents eavesdropping. In some cases, the authentication process <NUM> executing on the user device <NUM> may maintain a persistent secured connection with the authentication server <NUM>. The persistent connection allows for real-time authentication needs of various programs. In some embodiments, user device <NUM> and the authentication server <NUM> may communicate using a messaging protocol, and the device ID can be used for routing messages between the authentication server <NUM> and the user device <NUM>.

In some embodiments, the authentication server <NUM> may link device IDs that correspond to a plurality of devices used by the same user. For example, if someone uses a smartphone and a laptop, each having their own unique device ID, the respective device IDs may serve as aliases for the smartphone and the laptop. In some cases, a plurality of device IDs may be associated with a single user device <NUM>, and each respective device ID may correspond to respective user accounts associated with the user device <NUM>.

Referring now to <FIG>, there is illustrated a timing diagram <NUM> of an implementation of certain elements of the present disclosure according to an example embodiment. In the example scenario shown in <FIG>, the user device <NUM> is reset <NUM>. The authentication process <NUM> requests <NUM> a secured connection with the authentication server <NUM>. The authentication server <NUM> establishes <NUM> the secured connection with the authentication process <NUM>. The authentication process <NUM> requests <NUM> a device ID from the authentication server <NUM>, and the authentication server provides <NUM> the device ID to the authentication process <NUM>.

Continuing with the foregoing example, a user of the user device <NUM> may attempt to register with an application (e.g., application <NUM>). Accordingly, as further shown in the <FIG> example, the application <NUM> receives <NUM> registration credentials for the user and submits <NUM> a registration request to the authentication process <NUM>. The authentication process <NUM> packages <NUM> the credentials with the device ID (i.e., the device ID received at <NUM>), and submits <NUM> a registration request to the authentication server <NUM>. For example, the authentication process <NUM> may package <NUM> the credentials with the device ID using a particularized data format. The authentication server <NUM> attempts to store <NUM> the credentials in relation to the device ID and sends <NUM> an appropriate registration response to the authentication process <NUM>. For example, as discussed below in greater detail, the authentication server sends <NUM> a SUCCESS if the authentication server successfully stores <NUM> the credentials. As further shown in <FIG>, the authentication process <NUM> then forwards 260A/260B the registration response to the application <NUM> or the application server <NUM>, as appropriate.

Again, continuing with the foregoing example, after registering with the application <NUM>, the user attempts to access and use the application. Thus, as shown in the <FIG> example, the application <NUM> receives <NUM> log-in credentials and submits <NUM> an authentication request to the authentication process <NUM>. The authentication process packages <NUM> the credentials with the device ID, and submits <NUM> the authentication request to the authentication server <NUM>. The authentication server <NUM> compares <NUM> the credentials to credentials stored in the authentication server <NUM> in relation to the device ID. Depending on the result of the comparison, the authentication server <NUM> sends <NUM> an authentication response (e.g., SUCCESS or other as applicable) to the authentication process <NUM>. The authentication process <NUM> then forwards 295A/295B the authentication response to the application <NUM> or the application server <NUM>, as applicable, and the user can then access the application <NUM> for use.

One of ordinary skill will understand that the timing diagram shown in <FIG> is merely an example, and alternative, fewer, or additional steps may be present in different embodiments. For example, in some cases, the authentication server <NUM> may provide a device ID to the authentication process <NUM> without prompting.

In some embodiments, the application server <NUM> may confirm receipt of the authentication response by communicating directly with the authentication server <NUM>. For example, the response may be time stamped, and an application server <NUM> may confirm a response for a certain username at a certain timestamp with the authentication server <NUM>. In some implementations, the authentication server <NUM> may communicate the response directly to the application server <NUM>, bypassing the user device <NUM> altogether.

In some implementations, the authentication process <NUM> may react to function calls from the application <NUM>. As non-limiting examples, the authentication process <NUM> may respond to function calls such as register, newpassword (i.e., a function call for a new or updated password), and authenticate (i.e., a function call to authenticate credentials). In certain implementations, function calls may be provided as an application programming interface (API) associated with the authentication process <NUM>, and the application <NUM> may make these function calls to the authentication process <NUM>. In the example of a register call, the application <NUM> may provide registration credentials (e.g., username and password) for the application <NUM> to the authentication process <NUM>. As discussed above, the authentication process <NUM> may package these registration credentials with the device ID and transmit the package to the authentication server <NUM>. Depending on the outcome of a comparison between the received package and the stored credentials, the authentication server <NUM> may provide various responses. For example, SUCCESS: the credentials are successfully registered, ALREADY_REGISTERED: the credentials are already registered in association with the device ID, FAILURE: the credentials were unable to be registered (e.g., if a desired username already exists for the application), or other response as appropriate. The authentication process <NUM> may then forward the received response to the application <NUM> or directly to the application server <NUM>.

In the example of a newpassword call, the application <NUM> may provide the authentication process <NUM> new credentials (e.g., the username and a new password) for the application <NUM> when a user creates a new password. In some cases, the newpassword call must include the new password in addition to the existing password. The authentication process <NUM> may package the credentials (i.e., new password, username, and/or existing password) with the device ID and transmit the package to the authentication server <NUM>. The authentication server <NUM> may respond with SUCCESS: the credentials have been updated, UNREGISTERED: credentials are not currently stored in association with the device ID, MISMATCH: the credentials were not updated because the old password does not match the currently stored password, or FAILURE: the credentials were otherwise unable to be updated. The authentication process <NUM> may then forward the response from the authentication server <NUM> to the application <NUM> or directly to the application server <NUM>.

In the example of an authenticate call, the application <NUM> may provide the authentication process <NUM> log-in credentials (e.g., username and password) for the application <NUM> when a user wants access to their account. As discussed above, the authentication process <NUM> may package the credentials with the device ID and transmit the package to the authentication server <NUM>. The authentication server <NUM> compares the credentials with stored credentials associated with the device ID, and may respond with SUCCESS: the credentials are valid for the device ID for the application <NUM>, UNREGISTERED: credentials are not currently stored in association with the device ID, MISMATCH: credentials do not match the stored credentials for the device ID for the application <NUM>, and FAILURE: no comparison could be made for the credentials. The authentication process <NUM> may then forward the response from the authentication server <NUM> to the application <NUM> or directly to the application server <NUM>. One of ordinary skill will recognize that these calls and responses are merely examples, and various changes may be made within the scope of the present disclosure.

<FIG> illustrates example storage tables (i.e., <NUM>, <NUM>) in the authentication server <NUM> according to an example embodiment. Referring to <FIG>, the authentication server <NUM> can store alias table <NUM> and credentials table <NUM>. Alias table <NUM> indicates device IDs that are known aliases (e.g., a user has multiple devices, so more than one device ID corresponds to that user's account). For example, as shown in <FIG>, device IDs <NUM>, <NUM>, and <NUM> are aliases to each other, as is the case for device IDs <NUM> and <NUM>.

As further shown in <FIG>, credentials table <NUM> stores credentials (e.g., username and password combinations) associated with various device IDs. As can be seen, device IDs <NUM>, <NUM> and <NUM> have credentials associated with a first second application, device ID <NUM>, <NUM>, <NUM>, and <NUM> have credentials associated with a second application, device IDs <NUM>, <NUM>, and <NUM> have credentials associated with a third application, and device IDs <NUM> and <NUM> have no credentials associated with the applications. However, alias table <NUM> shows that certain aliases of device ID <NUM> (i.e., device IDs <NUM> and <NUM>) have credentials associated with the first, second, and third applications.

As a non-limiting example, if an authentication server <NUM> receives a log-in request with credentials for the first application associated with device ID <NUM>, the authentication server <NUM> would refer to alias table <NUM> and compare the received credentials to credentials stored for the first application in the row corresponding to device ID <NUM> as well as the rows corresponding to device ID <NUM> and device ID <NUM>. As another example, if an authentication server <NUM> receives a log-in request with credentials for the third application associated with device ID <NUM>, the authentication server <NUM> would refer to alias table <NUM>, observe that device ID <NUM> is not listed as having any aliases, and compare the received credentials to credentials stored for the third application in the rows corresponding to device ID <NUM> only.

<FIG> illustrates additional example storage tables (i.e., <NUM>, <NUM>) in the authentication server <NUM> according to another example embodiment. Similar to <FIG>, in <FIG>, an alias table <NUM> and a credentials table <NUM>. It will be recognized that credential table <NUM> of <FIG> includes the same credentials as credential table <NUM> of <FIG> but in a different organization. In credentials table <NUM>, the credentials for aliased device IDs are stored in a single row corresponding to a single device ID. For example, the row corresponding to device ID <NUM> includes credentials for the first through third applications and the row corresponding to device ID <NUM> is empty. Likewise, the row corresponding to device ID <NUM> includes credentials for the first and second applications and the row corresponding to device ID <NUM> is empty. In view of this different organization of credentials table <NUM>, alias table <NUM> need only includes device IDs that must reference an alias device ID for credentials. Thus, referring to alias table <NUM>, device IDs <NUM> and <NUM> refer to device ID <NUM>, and device ID <NUM> refers to device ID <NUM>.

Using the same examples as above but with reference to storage tables <NUM> and <NUM> of <FIG>, if an authentication server <NUM> receives a log-in request with credentials for the first application associated with device ID <NUM>, the authentication server <NUM> would refer to alias table <NUM> and compare the received credentials to credentials stored for the first application in the row corresponding to device ID <NUM> only. Meanwhile, if an authentication server <NUM> receives a log-in request with credentials for the third application associated with device ID <NUM>, the authentication server <NUM> would refer to alias table <NUM>, observe that device ID <NUM> is not listed as having any aliases, and compare the received credentials to credentials stored for the third application in the rows corresponding to device ID <NUM> only.

One of ordinary skill will recognize that alternative formats from the tables illustrated in <FIG> and <FIG> may be used to store credentials associated with the device IDs. For example, in some cases, multiple users may access one or more applications <NUM> on a same user device <NUM>. Accordingly, multiple credentials for a same application <NUM> may be associated with a same device ID.

<FIG> is a flowchart of a method <NUM> executed by the user device <NUM> according to an example embodiment. The user device <NUM> receives <NUM> user credentials (e.g., username and password). For example, user device <NUM> may display a log-in screen for application <NUM> executing on the user device <NUM>, and a user may input the credentials into the log-in screen. As another example, the user device <NUM> may receive <NUM> the credentials from an external device. User device <NUM> may communicate <NUM> the credentials to authentication process <NUM> executing on the user device <NUM>. For example, application <NUM> may perform an authentication call that invoked the authentication process <NUM> and provides authentication process <NUM> with the credentials.

As shown in the <FIG> embodiment, the authentication process <NUM> combines <NUM> the credentials with a device ID of the user device <NUM>, and the user device <NUM> transmits <NUM> a request (e.g., an authentication request) to authentications server <NUM>. User device <NUM> receives <NUM> a response from the authentication server <NUM>, and processes <NUM> the response. In some cases, the authentication process <NUM> may receive <NUM> the response and process <NUM> the response by communicating the response to the application <NUM> as a return for the authentication call. Alternatively, the response may bypass the authentication process <NUM> and be communicated to the application <NUM>. In some embodiments, user device <NUM> may then communicate the response to application server <NUM> and access user data associated with the username.

In some cases, the user device <NUM> may process <NUM> the response based on a type of response and/or a type of request. For example, if the response is a SUCCESS, MISMATCH, or ALREADY_REGISTERED, the response may be communicated to the application <NUM> or to the application server <NUM> as discussed above. Meanwhile, if the response is a FAILURE, the response may be communicated to the application <NUM> or to the application server <NUM>, and, additionally, the user device <NUM> may output a notification that the authentication server <NUM> is not currently accessible.

However, if the response is UNREGISTERED, the processing <NUM> may include the user device <NUM> outputting a prompt indicating that no account is associated with user device <NUM> for application <NUM>. The prompt may provide a user interface or otherwise guide the user in associating the device ID of user device <NUM> with an existing device ID (e.g., set device ID of user device <NUM> as an alias of a device ID of another user device <NUM>). For example, the prompt may ask if the user has registered with the application on another user device <NUM>, and, if so, facilitate aliasing with the device ID of another user device <NUM> using traditional two-factor authentication of a trusted account associated with the authentication server <NUM>. Once the device ID of the user device <NUM> is established as an alias of the device ID of the another user device <NUM>, the authentication server <NUM> may again attempt to process the credentials associated with the device ID, and the user device <NUM> may receive <NUM> a new response from the authentication server <NUM>. The new response may be received after a new request is transmitted <NUM> to the authentications server <NUM>. In some cases, the new response may then be communicated to the application <NUM> or the application server <NUM> without communicating the original UNREGISTERED response.

In certain embodiments, the application server <NUM> never receives or knows the password or the device ID. In some embodiments, however, the authentication process <NUM> may communicate the response to authentication server <NUM> directly. In some embodiments, the user device <NUM> maintains a persistent secured connection with authentication server <NUM>, and communicates with the authentication server <NUM> over the maintained channel.

<FIG> is a block diagram of an illustrative computing device architecture <NUM>, according to an example implementation. The computing device architecture <NUM> may be used to implement one or more of a user device <NUM>, authentication server <NUM>, and applications server <NUM> according to some example embodiments. It will be understood that the computing device architecture <NUM> is provided for example purposes only and does not limit the scope of the various implementations of the present disclosure. In some embodiments, the user device <NUM>, authentication server <NUM>, and applications server <NUM> may have fewer, alternative, or additional components as that illustrated in <FIG>.

The computing device architecture <NUM> of <FIG> includes a central processing unit (CPU) <NUM>, where computer instructions are processed, and a display interface <NUM> that acts as a communication interface and provides functions for rendering video, graphics, images, and texts on the display. In certain example implementations of the disclosed technology, the display interface <NUM> may be directly connected to a local display, such as a touch-screen display associated with a mobile computing device. In another example implementation, the display interface <NUM> may be configured for providing data, images, and other information for an external/remote display <NUM> that is not necessarily physically connected to the mobile computing device. For example, a desktop monitor may be used for mirroring graphics and other information that is presented on a mobile computing device. In certain example implementations, the display interface <NUM> may wirelessly communicate, for example, via a Wi-Fi channel or other available network connection interface <NUM> to the external/remote display <NUM>.

In an example implementation, the network connection interface <NUM> may be configured as a communication interface and may provide functions for digital virtual assistant using voice, rendering video, graphics, images, text, other information, or any combination thereof on the display. In one example, a communication interface may include a microphone, camera, serial port, a parallel port, a general-purpose input and output (GPIO) port, a game port, a universal serial bus (USB), a micro-USB port, a high definition multimedia (HDMI) port, a video port, an audio port, a Bluetooth port, a near-field communication (NFC) port, another like communication interface, or any combination thereof. In one example, the display interface <NUM> may be operatively coupled to a local display, such as a touch-screen display associated with a mobile device or voice enabled device. In another example, the display interface <NUM> may be configured to provide video, graphics, images, text, other information, or any combination thereof for an external/remote display <NUM> that is not necessarily connected to the mobile computing device. In one example, a desktop monitor may be used for mirroring or extending graphical information that may be presented on a mobile device. In another example, the display interface <NUM> may wirelessly communicate, for example, via the network connection interface <NUM> such as a Wi-Fi transceiver to the external/remote display <NUM>.

The computing device architecture <NUM> may include a keyboard interface <NUM> that provides a communication interface to a keyboard. In one example implementation, the computing device architecture <NUM> may include a presence sensitive input interface <NUM> for connecting to a presence sensitive display <NUM>. According to certain example implementations of the disclosed technology, the presence sensitive input interface <NUM> may provide a communication interface to various devices such as a pointing device, a touch screen, a depth camera, microphone, etc. which may or may not be associated with a display.

The computing device architecture <NUM> may be configured to use an input device via one or more of input/output interfaces (for example, the keyboard interface <NUM>, the display interface <NUM>, the presence sensitive input interface <NUM>, network connection interface <NUM>, camera interface <NUM>, sound interface <NUM>, etc.) to allow a user to capture information into the computing device architecture <NUM>. The input device may include a mouse, a trackball, a directional pad, a track pad, a touch-verified track pad, a presence-sensitive track pad, a presence-sensitive display, a scroll wheel, a digital camera, a digital video camera, a web camera, a microphone, a sensor, a smartcard, and the like. Additionally, the input device may be integrated with the computing device architecture <NUM> or may be a separate device.

Example implementations of the computing device architecture <NUM> may include an antenna interface <NUM> that provides a communication interface to an antenna; a network connection interface <NUM> that provides a communication interface to a network. As mentioned above, the display interface <NUM> may be in communication with the network connection interface <NUM>, for example, to provide information for display on a remote display that is not directly connected or attached to the system. In certain implementations, camera interface <NUM> acts as a communication interface and provides functions for capturing digital images from a camera. In certain implementations, a sound interface <NUM> is provided as a communication interface for converting sound into electrical signals using a microphone and for converting electrical signals into sound using a speaker. In certain implementations, a sound interface <NUM> is utilized to capture voice inputs for consumption by of other components connected to the BUS <NUM>. According to example implementations, a random-access memory (RAM) <NUM> is provided, where computer instructions and data may be stored in a volatile memory device for processing by the CPU <NUM>.

According to an example implementation, the computing device architecture <NUM> includes a read-only memory (ROM) <NUM> where invariant low-level system code or data for basic system functions such as basic input and output (I/O), startup, or reception of keystrokes from a keyboard are stored in a non-volatile memory device. According to an example implementation, the computing device architecture <NUM> includes a storage medium <NUM> or other suitable type of memory (e.g. such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, flash drives), where the files include an operating system <NUM>, application programs <NUM> (including, for example, a web browser application, a widget or gadget engine, and or other applications, as necessary) and data files <NUM> are stored. According to an example implementation, the computing device architecture <NUM> includes a power source <NUM> that provides an appropriate alternating current (AC) or direct current (DC) to power components.

According to an example implementation, the computing device architecture <NUM> includes a telephony subsystem <NUM> that allows the computing device to transmit and receive sound over a telephone network. The constituent devices and the CPU <NUM> communicate with each other over a bus <NUM>.

According to an example implementation, the CPU <NUM> has appropriate structure to be a computer processor. In one arrangement, the CPU <NUM> may include more than one processing unit. The RAM <NUM> interfaces with the computer BUS <NUM> to provide quick RAM storage to the CPU <NUM> during the execution of software programs such as the operating system application programs, and device drivers. More specifically, the CPU <NUM> loads computer-executable process steps from the storage medium <NUM> or other media into a field of the RAM <NUM> to execute software programs. Data may be stored in the RAM <NUM>, where the data may be accessed by the computer CPU <NUM> during execution.

The storage medium <NUM> itself may include a number of physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, a flash memory, a USB flash drive, an external hard disk drive, thumb drive, pen drive, key drive, a High-Density Digital Versatile Disc (HD-DVD) optical disc drive, an internal hard disk drive, a Blu-Ray optical disc drive, or a Holographic Digital Data Storage (HDDS) optical disc drive, an external mini-dual in-line memory module (DIMM) synchronous dynamic random access memory (SDRAM), or an external micro-DIMM SDRAM. Such computer readable storage media allow a computing device to access computer-executable process steps, application programs and the like, stored on removable and non-removable memory media, to off-load data from the device or to upload data onto the device. A computer program product, such as one utilizing a communication system may be tangibly embodied in storage medium <NUM>, which may include a machine-readable storage medium.

According to one example implementation, the term computing device, as used herein, may be a CPU, or conceptualized as a CPU (for example, the CPU <NUM> of <FIG>). In this example implementation, the computing device (CPU) may be coupled, connected, and/or in communication with one or more peripheral devices, such as display. In another example implementation, the term computing device, as used herein, may refer to a mobile computing device such as a smart phone, tablet computer, or smart watch. In this example implementation, the computing device may output content to its local display and/or speaker(s). In another example implementation, the computing device may output content to an external display device (e.g., over Wi-Fi) such as a TV or an external computing system.

In example implementations of the disclosed technology, a computing device may include any number of hardware and/or software applications that are executed to facilitate any of the operations. In example implementations, one or more I/O interfaces may facilitate communication between the computing device and one or more input/output devices. For example, a universal serial bus port, a serial port, a disk drive, a CD-ROM drive, and/or one or more user interface devices, such as a display, keyboard, keypad, mouse, control panel, touch screen display, microphone, etc., may facilitate user interaction with the computing device. The one or more I/O interfaces may be used to receive or collect data and/or user instructions from a wide variety of input devices. Received data may be processed by one or more computer processors as desired in various implementations of the disclosed technology and/or stored in one or more memory devices.

One or more network interfaces may facilitate connection of the computing device inputs and outputs to one or more suitable networks and/or connections; for example, the connections that facilitate communication with any number of sensors associated with the system. The one or more network interfaces may further facilitate connection to one or more suitable networks; for example, a local area network, a wide area network, the Internet, a cellular network, a radio frequency network, a Bluetooth enabled network, a Wi-Fi enabled network, a satellite-based network any wired network, any wireless network, etc., for communication with external devices and/or systems.

In the present description, numerous specific details are set forth. However, it is to be understood that embodiments of the disclosed technology may be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail in order not to obscure an understanding of this description. References to "one embodiment," "an embodiment," "example embodiment," "some embodiments," "certain embodiments," "various embodiments," etc., indicate that the embodiment(s) of the disclosed technology so described may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase "in one embodiment" does not necessarily refer to the same embodiment, although it may.

Unless otherwise noted, the terms used herein are to be understood according to conventional usage by those of ordinary skill in the relevant art. In addition to any definitions of terms provided below, it is to be understood that as used in the specification and in the claims, "a" or "an" can mean one or more, depending upon the context in which it is used. Throughout the specification and the claims, the following terms take at least the meanings explicitly associated herein, unless the context clearly dictates otherwise. The term "or" is intended to mean an inclusive "or. " Further, the terms "a," "an," and "the" are intended to mean one or more unless specified otherwise or clear from the context to be directed to a singular form.

Unless otherwise specified, the use of the ordinal adjectives "first," "second," "third," etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

Also, in describing example embodiments, certain terminology is used for the sake of clarity. It is intended that each term contemplates its broadest meaning as understood by those skilled in the art and includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

While certain embodiments of the disclosed technology have been described, it is to be understood that the disclosed technology is not to be limited to the disclosed example embodiments, but covers various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claim 1:
A method comprising:
receiving (<NUM>), from an application executing on a computing device and by an authentication process (<NUM>) executing on the computing device, data representative of user credentials corresponding to the application (<NUM>);
packaging (<NUM>), by the authentication process (<NUM>), the data representative of user credentials with a device identification assigned to the computing device,
wherein packaging comprises packaging the user credentials with the device identification and an indication that the user credentials correspond to the application; outputting (<NUM>) for transmission, by the authentication process (<NUM>) and to an authentication server (<NUM>), an authentication request containing the packaged user credentials and device identification; and
receiving (<NUM>), by the authentication process (<NUM>) and from the authentication server (<NUM>), and in response to the authentication request, an indication of authentication of the user credentials;
wherein the authentication process (<NUM>) is isolated from the application (<NUM>), and
wherein the device identification is hidden from the application (<NUM>); and wherein in response to the indication of authentication of the user credentials indicating that no user credentials are associated with the device identification, outputting for display an indication that no user credentials are associated with the computing device;
receiving a user indication to associate the computing device with another computing device;
outputting for transmission, by the authentication process (<NUM>) and to the authentication server (<NUM>) after the device identification assigned to the computing device is associated with a device identification assigned to the another computing device, a new authentication request containing the user credentials packaged with the device identification of the computing device;
receiving, by the authentication process (<NUM>) and from the authentication server (<NUM>), and in response to the new authentication request, a new indication of authentication of the user credentials; and
forwarding the new indication from the authentication process to the application.