Patent Description:
Remote desktops are often used by business entities to allow employees access to various software applications and services. Prior to establishing a session with a remote server, the user is authenticated for purposes of ensuring that only authorized personal obtain access to certain resources. The user authentication involves using either (a) a user's proximity to a thin client or (b) facial recognition. The user authentication needs to be performed each time the user attempts to obtain access to a thin client.

Despite the advantages of the conventional user authentication techniques, they suffer from certain drawbacks. For example, facial recognition can be spoofed if one holds up a picture of someone else's face. Likewise, a user's proximity to a thin client alone may be insecure due to the possibility of the session accidently launching on an unwanted terminal when the user is simply walking by. <CIT> (<NUM>-<NUM>-<NUM>) discloses a method to log a user on on a computer, to use a remote desktop session. The proximity of the user is detected using either the presence of a secure device or the camera when the user is recognized in the image. If several users are recognized, a user disambiguation is proposed on screen of the host. A full multi factor authentication (including biometric, PIN or secure device presence) is done the first time and session information are saved to be reused when the session resumed after the proximity detection is interrupted and detected again.

<CIT> (<NUM>-<NUM>-<NUM>) discloses a bluetooth token, either wearable or included in a mobile phone or a thumbdrive storing user data.

The token stores authentication data which are needed to connect to a cloud service (media storage, email,.

On proximity detection of the token with a client (cooperating computing device), being either a private or enterprise PC, the authentication data are sent from the token and forwarded by the client to the server (these may be encrypted by the token with the server public key).

A globally-unique user identifier (GUUID) may be used to link the token with the user profile. A session can thus be transferred between two clients or concurrent sessions established. Continuous or recurring authentication possible. The client may use two factor authentication by combining it with a facial recognition or PIN or fingerprint.

The session is paused when the client detects that the token cannot be reached.

The present disclosure concerns implementing systems and methods for obtaining access to a session with a remote cloud service server. In some scenarios, the methods comprise: detecting when a mobile device is in proximity to a first client computing device (e.g., using a beacon); receiving, by the first client computing device, a user unique identifier and/or a partial or full session token sent from the mobile device; initiating facial recognition operations in response to the first client computing device's reception of the user unique identifier; and/or performing the facial recognition operations by the first client computing device.

The facial recognition operations comprise: capturing an image of the mobile device's user; and analyzing the image to obtain a user name associated with the facial features represented therein. In some scenarios, the username is obtained by: comparing facial features of the image to a facial feature database including facial feature information for a plurality of individuals; detecting a match of the image's facial features and the facial features associated with an individual of the plurality of individuals; and retrieving the user name associated with the individual having the matching facial features.

A determination is made as to whether the user name matches the user unique identifier. If so, then the following operations are performed: authenticating the user with the remote cloud service sever using the partial or full session token; and/or automatically launching a first session with the remote cloud service server. Notably, the user obtains access to the first session without entering credentials into the first client computing device. If the user name does not match the user unique identifier, then the user may be allowed access to the first session using a manual user input based authentication scheme (e.g., by entering a username and/or password into the first computing device).

In those or other scenarios, the user is authenticated once by the mobile device prior to obtaining access to a first session at a first time using the first computing device and access to a second session at a second time using a second different computing device. The user may be periodically authenticated by the mobile device in accordance with a timing scheme of a certificate issued to the mobile device.

In those or yet other scenarios, the methods comprise: receiving, by a first computing device, first authentication information; receiving, by a second computing device, second authentication information that is different than the first authentication information; analyzing the second authentication information to verify that the user identified thereby is the same as the user identified by the first authentication information; generating a full resource token based on the first authentication information and the second authentication information, when a verification has been made that the users identified by the first and second authentication information are the same; and providing access to the resource using the full resource token.

The present solution will be described with reference to the following drawing figures, in which like numerals represent like items throughout the figures.

The invention is defined by the independent claims, several embodiments being described by the dependent claims.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Reference throughout this specification to "one embodiment", "an embodiment", or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution.

The present solution concerns systems and methods for providing remote desktop access using proximity and facial recognition as a two-factor authentication. In accordance with the present solution, a user authenticates once on his(her) mobile device (e.g., a smart phone). When the user arrives within proximity of a client computing device (e.g., a thin client), the mobile device transmits a unique identifier for the user (e.g., a username) to the client computing device. The client computing device then initiates facial recognition operations thereof. The user's face is recognized on the client computing device. The client computing device then obtains a username associated with user's face in a datastore. The username is compared to the user's unique identifier received from the mobile device. If a match exists, the user's remote session is launched on the client computing device.

The present solution has many novel features. For example, existing conventional solutions only use one or the other (i.e., proximity or facial recognition), rather than a combination of the two as is done in the present solution. In the present case, users must only authenticate a single time, and then (s)he is able to move from client computing device to client computing device in a secure and efficient manner. This is not the case in conventional systems. The present solution also eliminates the need to distinguish client computing devices that are in close proximity to each other if only beacon authentication was used (i.e., no added Personal Identification Number ("PIN") required).

The present solution overcomes various drawbacks of conventional authentication solutions. For example, the present solution solves the problem of security issues that may arise with facial recognition. As mentioned above, facial recognition can be spoofed if one holds up a picture of someone else's face. Likewise, proximity alone may be insecure due to the possibility of the session accidently launching on an unwanted terminal when the user is simply walking by. Lastly, the present solution minimizes the time that it takes to authenticate and launch a session which is extremely crucial in environments such as hospitals where time is critical.

The present solution solves the problem of facial recognition being insecure by ensuring that the user's face is not only visible but is also within proximity of the client computing device. Likewise, if proximity is used in combination with facial recognition, sessions will not accidentally launch when the user is passing by because the user's face must also be seen at the client computing device. A user will only have to authenticate once to his(her) mobile device, and then (s)he can move from client computing device to client computing device without having to type in credentials or a pin each time to access his(her) remote session. Once the user is within proximity of the client computing device and the client computing device recognizes the user's face as the user who approached it, the session will simply launch (only consisting of a few seconds).

As noted above, the present solution does not require having to tap a badge or enter a pin number into the client computing device. Accordingly, the present solution saves the user time by being able to simply walk up to the client computing device to authenticate and launch a session rather than having to use peripherals to gain access.

Referring now to <FIG>, there is provided an illustration of an illustrative system <NUM>. System <NUM> implements methods for establishing a remote session with a remote cloud service server <NUM>. In this regard, system <NUM> comprises a customer facility <NUM> and a cloud service provider facility <NUM>. The customer facility <NUM> comprises one or more buildings of a customer, such as a business organization (e.g., a hospital). The customer has at least one end user <NUM>. The end user can include, but is not limited to, an employee. The end user <NUM> uses the client computing devices <NUM><NUM>-<NUM>N (e.g., thin clients) for a variety of purposes, such as accessing and using cloud services provided by a cloud service provider. In this regard, the client computing devices <NUM><NUM>-<NUM>N are configured to facilitate access to applications and virtual desktops without interruptions resulting from connectivity loss. Accordingly, the client computing devices <NUM><NUM>-<NUM>N have installed thereon and execute various software applications. These software applications include, but are not limited to, Web Browsers <NUM><NUM>-<NUM>N and/or Web Receivers <NUM><NUM>-<NUM>N. Web Browsers and Web Receivers are well known in the art, and therefore will not be described herein. Any known or to be known Web Browser and Web Receiver can be used herein without limitation.

In some scenarios, the Web Receivers <NUM><NUM>-<NUM>N can respectively include, but are not limited to, Citrix Receivers available from Citrix Systems, Inc. of Florida and Citrix Receivers for a web site available from Citrix Systems, Inc. of Florida. Citrix Receivers comprise client software that is required to access applications and full desktops hosted by servers remote from client devices. The present solution is not limited in this regard.

The client computing devices <NUM><NUM>-<NUM>N also have various information stored internally. This information includes, but is not limited to, account records <NUM><NUM>-<NUM>N. The client computing devices <NUM><NUM>-<NUM>N are able to communicate with each other via an Intranet and with external devices via the Internet. The Intranet and Internet are shown in <FIG> as a network <NUM>.

The external devices include one or more cloud service servers <NUM> located at the cloud service provider facility <NUM>. The cloud service provider facility <NUM> comprises one or more buildings of a cloud service provider. The server(s) <NUM> is(are) configured to facilitate access to applications and virtual desktops without interruptions resulting from connectivity loss. Accordingly, the server <NUM> has installed thereon and executes various software applications. The software applications include, but are not limited to, a StoreFront and a Desktop Delivery Controller ("DDC"). StoreFronts and DDCs are well known in the art, and therefore will not be described herein. Any known or to be known StoreFront and/or DDC can be employed herein.

The server <NUM> is also configured to access the datastore <NUM> in which publishing information <NUM> is stored, and is also able to write/read from the datastore(s) <NUM>. The publishing information <NUM> includes, but is not limited to, software applications, code, media content (e.g., text, images, videos, etc.), and/or user authentication information (e.g., a user name and/or facial feature information).

During operation, a two-factor authentication process is performed for authenticating an end user prior to establishing a session between a client computing device <NUM><NUM>-<NUM>N and the cloud service server <NUM>. The two-factors used herein comprise the end user's proximity to the client computing device and the facial recognition of the end user.

When the end user <NUM> arrives within proximity of a client computing device <NUM><NUM>-<NUM>N, the mobile device <NUM> transmits a unique identifier for the end user <NUM> (e.g., a username) to the client computing device <NUM><NUM>-<NUM>N. The client computing device <NUM><NUM>-<NUM>N then initiates its facial recognition operations. Facial recognition operations are well known in the art, and therefore will not be described in detail herein. Any known or to be known facial recognition operations can be used herein without limitation. In some scenarios, the facial recognition operations involve: capturing an image of the end user's face; and perform image processing to recognize the end user's face by the client computing device. The end user's face is recognized by comparing selected facial features from the captured image and a face database. The client computing device then obtains a username stored in datastore <NUM> so as to be associated with the face database (e.g., information specifying facial features of the user's face). The username is compared to the user's unique identifier received from the mobile device <NUM>. If a match exists, the user's remote session is launched on the client computing device <NUM><NUM>-<NUM>N.

Referring now to <FIG>, there is provided an illustration of an exemplary architecture for the mobile device <NUM> of <FIG>. Mobile device <NUM> may include more or less components than those shown in <FIG>. However, the components shown are sufficient to disclose an illustrative embodiment implementing the present solution. Some or all of the components of the mobile device <NUM> can be implemented in hardware, software and/or a combination of hardware and software. The hardware includes, but is not limited to, one or more electronic circuits. The electronic circuits can include, but are not limited to, passive components (e.g., resistors and capacitors) and/or active components (e.g., amplifiers and/or microprocessors). The passive and/or active components can be adapted to, arranged to and/or programmed to perform one or more of the methodologies, procedures, or functions described herein.

As noted above, the mobile device <NUM> can include, but is not limited to, a notebook computer, a personal digital assistant, a cellular phone or a mobile phone with smart device functionality (e.g., a Smartphone). In this regard, the mobile device <NUM> comprises an antenna <NUM> for receiving and transmitting Radio Frequency ("RF") signals. A receive/transmit ("Rx/Tx") switch <NUM> selectively couples the antenna <NUM> to the transmitter circuitry <NUM> and the receiver circuitry <NUM> in a manner familiar to those skilled in the art. The receiver circuitry <NUM> demodulates and decodes the RF signals received from an external device. The receiver circuitry <NUM> is coupled to a controller (or microprocessor) <NUM> via an electrical connection <NUM>. The receiver circuitry <NUM> provides the decoded signal information to the controller <NUM>. The controller <NUM> uses the decoded RF signal information in accordance with the function(s) of the mobile device <NUM>. The controller <NUM> also provides information to the transmitter circuitry <NUM> for encoding and modulating information into RF signals. Accordingly, the controller <NUM> is coupled to the transmitter circuitry <NUM> via an electrical connection <NUM>. The transmitter circuitry <NUM> communicates the RF signals to the antenna <NUM> for transmission to an external device via the Rx/Tx switch <NUM>.

The mobile device <NUM> also comprises an antenna <NUM> coupled to a Short Range Communications ("SRC") transceiver <NUM> for receiving SRC signals. SRC transceivers are well known in the art, and therefore will not be described in detail herein. However, it should be understood that the SRC transceiver <NUM> processes the SRC signals to extract information therefrom. The SRC transceiver <NUM> may process the SRC signals in a manner defined by the SRC application <NUM> installed on the mobile device <NUM>. The SRC application <NUM> can include, but is not limited to, a Commercial Off the Shelf ("COTS") application (e.g., a Bluetooth application). The SRC transceiver <NUM> is coupled to the controller <NUM> via an electrical connection <NUM>. The controller uses the extracted information in accordance with the function(s) of the mobile device <NUM>. For example, the extracted information can include a unique identifier received from a client computing device <NUM><NUM>,. , <NUM>N of <FIG>. The unique identifier can be used by the mobile device <NUM> to initiate or enable user authentication functions thereof as described herein. The user authentication functions can involve: obtaining a unique identifier for the user (e.g., unique identifier <NUM>) via a user-software interaction or via a datastore read operation; and communicating the unique identifier to a remote cloud service server (e.g., cloud service server <NUM> of <FIG>).

The controller <NUM> may store received and extracted information in memory <NUM> of the mobile device <NUM>. Accordingly, the memory <NUM> is connected to and accessible by the controller <NUM> through electrical connection <NUM>. The memory <NUM> may be a volatile memory and/or a non-volatile memory. For example, memory <NUM> can include, but is not limited to, a Random Access Memory ("RAM"), a Dynamic RAM ("DRAM"), a Read Only Memory ("ROM") and a flash memory. The memory <NUM> may also comprise unsecure memory and/or secure memory. The memory <NUM> can be used to store various other types of data <NUM> therein, such as authentication information, cryptographic information, location information, and various work order related information.

The mobile device <NUM> also may comprise a barcode reader <NUM>. Barcode readers are well known in the art, and therefore will not be described herein. However, it should be understood that the barcode reader <NUM> is generally configured to scan a barcode and process the scanned barcode to extract information therefrom. The barcode reader <NUM> may process the barcode in a manner defined by the barcode application <NUM> installed on the mobile device <NUM>. Additionally, the barcode scanning application can use camera <NUM> to capture the barcode image for processing. The barcode application <NUM> can include, but is not limited to, a COTS application. The barcode reader <NUM> provides the extracted information to the controller <NUM>. As such, the barcode reader <NUM> is coupled to the controller <NUM> via an electrical connection <NUM>. The controller <NUM> uses the extracted information in accordance with the function(s) of the mobile device <NUM>. For example, the extracted information can be used by mobile device <NUM> to enable user authentication functionalities thereof.

As shown in <FIG>, one or more sets of instructions <NUM> are stored in memory <NUM>. The instructions may include customizable instructions and non-customizable instructions. The instructions <NUM> can also reside, completely or at least partially, within the controller <NUM> during execution thereof by mobile device <NUM>. In this regard, the memory <NUM> and the controller <NUM> can constitute machine-readable media. The term "machine-readable media", as used herein, refers to a single medium or multiple media that stores one or more sets of instructions <NUM>. The term "machine-readable media", as used here, also refers to any medium that is capable of storing, encoding or carrying the set of instructions <NUM> for execution by the mobile device <NUM> and that causes the mobile device <NUM> to perform one or more of the methodologies of the present disclosure.

The controller <NUM> is also connected to a user interface <NUM>. The user interface <NUM> comprises input devices <NUM>, output devices <NUM> and software routines (not shown in <FIG>) configured to allow a user to interact with and control software applications (e.g., software applications <NUM>-<NUM> and other software applications) installed on the mobile device <NUM>. Such input and output devices may include, but are not limited to, a display <NUM>, a speaker <NUM>, a keypad <NUM>, a directional pad (not shown in <FIG>), a directional knob (not shown in <FIG>), a microphone <NUM>, and a camera <NUM>. The display <NUM> may be designed to accept touch screen inputs. As such, user interface <NUM> can facilitate a user software interaction for launching applications (e.g., software applications <NUM>-<NUM> and other software applications) installed on the mobile device <NUM>. The user interface <NUM> can facilitate a user-software interactive session for: initiating communications with an external device; writing data to and reading data from memory <NUM>; and/or initiating user authentication operations for authenticating a user such that a remote session between a nearby client computing device and a remote cloud service server.

The display <NUM>, keypad <NUM>, directional pad (not shown in <FIG>) and directional knob (not shown in <FIG>) can collectively provide a user with a means to initiate one or more software applications or functions of the mobile device <NUM>. The application software <NUM>-<NUM> can facilitate the data exchange (a) a user and the mobile device <NUM>, and/or (b) the mobile device <NUM> and a client computing device <NUM><NUM>,. In this regard, the application software <NUM>-<NUM> performs one or more of the following: facilitated verification of the identity of a user of mobile device <NUM> via an two-factor authentication process; and/or present information to the user indicating this his/her identity has or has not been verified.

Referring now to <FIG>, there is provided an illustration of an exemplary architecture for a computing device <NUM>. Computing devices <NUM><NUM>-<NUM>N and/or server(s) <NUM> of <FIG> (is)are the same as or similar to computing device <NUM>. As such, the discussion of computing device <NUM> is sufficient for understanding these components of system <NUM>.

In some scenarios, the present solution is used in a client-server architecture. Accordingly, the computing device architecture shown in <FIG> is sufficient for understanding the particulars of client computing devices and servers.

Computing device <NUM> may include more or less components than those shown in <FIG>. However, the components shown are sufficient to disclose an illustrative solution implementing the present solution. The hardware architecture of <FIG> represents one implementation of a representative computing device configured to enable watermarking of graphics, as described herein. As such, the computing device <NUM> of <FIG> implements at least a portion of the method(s) described herein.

Some or all the components of the computing device <NUM> can be implemented as hardware, software and/or a combination of hardware and software. The hardware includes, but is not limited to, one or more electronic circuits. The electronic circuits can include, but are not limited to, passive components (e.g., resistors and capacitors) and/or active components (e.g., amplifiers and/or microprocessors). The passive and/or active components can be adapted to, arranged to and/or programmed to perform one or more of the methodologies, procedures, or functions described herein.

As shown in <FIG>, the computing device <NUM> comprises a user interface <NUM>, a Central Processing Unit ("CPU") <NUM>, a system bus <NUM>, a memory <NUM> connected to and accessible by other portions of computing device <NUM> through system bus <NUM>, and hardware entities <NUM> connected to system bus <NUM>. The user interface can include input devices and output devices, which facilitate user-software interactions for controlling operations of the computing device <NUM>. The input devices include, but are not limited, a physical and/or touch keyboard <NUM>. The input devices can be connected to the computing device <NUM> via a wired or wireless connection (e.g., a Bluetooth® connection). The output devices include, but are not limited to, a speaker <NUM>, a display <NUM>, and/or light emitting diodes <NUM>.

At least some of the hardware entities <NUM> perform actions involving access to and use of memory <NUM>, which can be a Radom Access Memory ("RAM"), a disk driver and/or a Compact Disc Read Only Memory ("CD-ROM"). Hardware entities <NUM> can include a disk drive unit <NUM> comprising a computer-readable storage medium <NUM> on which is stored one or more sets of instructions <NUM> (e.g., software code) configured to implement one or more of the methodologies, procedures, or functions described herein. The instructions <NUM> can also reside, completely or at least partially, within the memory <NUM> and/or within the CPU <NUM> during execution thereof by the computing device <NUM>. The memory <NUM> and the CPU <NUM> also can constitute machine-readable media. The term "machine-readable media", as used here, refers to a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions <NUM>. The term "machine-readable media", as used here, also refers to any medium that is capable of storing, encoding or carrying a set of instructions <NUM> for execution by the computing device <NUM> and that cause the computing device <NUM> to perform any one or more of the methodologies of the present disclosure.

Referring now to <FIG>, there is shown a flow diagram of an illustrative method <NUM> for providing remote desktop access using proximity and facial recognition as a two-factor authentication. Method <NUM> comprises a plurality of operations <NUM>-<NUM>. The present solution is not limited to the order of operations <NUM>-<NUM> shown in <FIG>. The operations of <NUM>-<NUM> can be performed in a different order (than that shown) in accordance with a given application.

As shown in <FIG>, method <NUM> begins with <NUM> and continues with <NUM> where a mobile device (e.g., mobile device <NUM> of <FIG>) performs operations to authenticate a user (e.g., end user <NUM> of <FIG>). The user authentication is achieved by: receiving a user-software interaction for inputting user authentication information (e.g., a pin and/or password); and comparing the inputted user authentication information to pre-stored user authentication information. If the inputted and pre-stored user authentication information match each other, then the user's identity is authenticated or verified by the mobile device. Notably, the user authentication operations of <NUM> only need to be performed once for purposes of providing the user access to a session with a remote cloud service server (e.g., cloud service server <NUM> of <FIG>) via any one of a plurality of client computing devices (e.g., client computing devices <NUM><NUM>,. , <NUM>N of <FIG>) employing a two-factor authentication process. However, it should be understood that the mobile device's authentication of <NUM> may be performed in accordance with rules or a timing scheme specified by an issued certification (e.g., daily, weekly, monthly, yearly, each time a user moves from one location to another location, and/or each time the user enters a given area or location).

The two-factor authentication process is now described in relation to <NUM>-<NUM>. <NUM> involves performing operations to detect when the user is in proximity to a client computing device. Techniques for detecting when a user or device is in proximity to a computing device are well known in the art. Any known or to be known technique for detecting when a user or device is in proximity to a computing device can be used herein without limitation. For example, in some scenarios, the client computing device comprises an iBeacon that transmits a beacon signal comprising a first unique identifier (e.g., a Universal Unique Identifier ("UUID") for a business entity and a second unique identifier (e.g., an IP address of the computing device). When the mobile device is in range of the iBeacon, it receives the beacon signal. A detection is made that the user is in proximity of the CCD when the mobile device receives a beacon signal having the first unique identifier. The present solution is not limited to the particulars of this example. Additionally or alternatively, the operations of <NUM> involve: (A) detecting when there is a break in a beam emitted by a beam brake sensor; and/or (B) prompting the user to place the mobile device in proximity of the client computing device, and detecting when the mobile device is in proximity to the client computing device.

When the detection is made in <NUM>, the user's unique identifier and at least part of a session token is communicated from the mobile device to the client computing device, as shown by <NUM>. In some scenarios, this communication is achieved using a beacon response signal or a SRC (e.g., a Bluetooth communication). The present solution is not limited to the particulars of this example. The partial session token can be used by the client computing device to obtain a full session token. Session tokens are well known in the art, and therefore will not be described herein. Any known or to be known session token (partial or full) can be used herein without limitation.

Facial recognition operations of the client computing device are initiated in <NUM> responsive to the client computing device's reception of the user's unique identifier in <NUM>. Facial recognition operations are well known in the art, and therefore will not be described in detail here. Any known or to be known facial recognition technique can be used herein without limitation. For example, in some scenarios, the facial recognition is achieved by performing operations in <NUM>-<NUM> by the client computing device to: capture an image of the user's face; and analyze the image to identify a user name associated with the face represented in the captured image. The user name is identified by: comparing facial features of the captured image to a facial feature database including facial feature information for a plurality of individuals; detecting a match of the captured image's facial features and those associated with one of the individuals; and retrieving a user name associated with the individual having the matching facial features. The present solution is not limited to the particulars of this example.

In next <NUM>, the user name is compared to the unique identifier communicated in <NUM>. If a match does not exist between the user name and unique identifier [<NUM>:NO], then method <NUM> continues with <NUM> where the user is notified that (s)he has been denied access to the client computing device. Subsequently, <NUM> is performed. In <NUM>, method <NUM> ends or other processing is performed (e.g., the computing device provides the user with another way to be authenticated for purposes of accessing a session, such as via a user-software interaction for inputting a username and password).

In contrast, if a match does exist between the user name and unique identifier [<NUM>:YES], then method <NUM> continues with <NUM> where the user is automatically authenticated with a remote cloud service server (e.g., cloud service server <NUM> of <FIG>) using the partial or full session token obtained in <NUM>. Once authenticated, a session is launched with the remote cloud service server, as shown by <NUM>. Techniques for launching a session are well known in the art, and therefore will not be described herein. Any known or to be known technique for launching a session can be used herein without limitation.

During the session, the cloud service server receives graphics from the datastore, as shown by <NUM>. In <NUM>, the cloud service server performs operations to generate a content display message. The content display message comprises a string of commands for displaying the content obtained in <NUM> and an End-Of-Frame ("EOF") command. The content display message is communicated from the cloud service server (e.g., cloud service server <NUM> of <FIG>) to the client computing device (e.g., to the Web Receiver <NUM><NUM> of <FIG>) in <NUM>. In <NUM>, the client computing device performs operations to construct content in memory for a given frame in accordance with the string of commands contained in the content display message. Next in <NUM>, the client computing device displays the constructed content in response to the EOF command. Subsequently, <NUM> is performed where method <NUM> ends or other processing is performed (e.g., return to <NUM>, <NUM> or <NUM>).

Referring now to <FIG>, there is provided a flow diagram of another illustrative method <NUM> for obtaining access to an access restricted resource. Method <NUM> comprises a plurality of operations <NUM>-<NUM>. The present solution is not limited to the order of operations <NUM>-<NUM> shown in <FIG>. The operations of <NUM>-<NUM> can be performed in a different order (than that shown) in accordance with a given application.

As shown in <FIG>, method <NUM> begins with <NUM> and continues with <NUM> where a MD (e.g., MD <NUM> of <FIG>) performs operations to acquire first Authentication Information ("AI") from a user thereof. The first AI can include, but is not limited to, a username, a password, an access code, a certificate, a pin, biometric information, or another authentication information required by a user authentication process employed by the MD. Such user authentication processes are well known in the art, and therefore will not be described herein. Any known or to be known user authentication process can be used herein without limitation. In <NUM>, the MD uses the first AI to authenticate the user.

Next in <NUM>, a connection is established between the MD and a CCD (e.g., CCD <NUM><NUM> of <FIG>) in proximity to the MD. Techniques for establishing connections between devices are well known in the art, and therefore will not be described herein. Any known or to be known technique for establishing a connection between two devices can be used herein without limitation. The CCD performs operations in <NUM> to acquire second AI. The second AI can include, but is not limited to, a username, a password, an access code, a certificate, a pin, biometric information, smart card information, or another authentication information required by a user authentication process employed by the MD.

In <NUM>, information is exchanged between the MD and the CCD. For example, the first AI and/or first Security Information ("SI") derived from the first AI is communicated from the MD to the CCD. Additionally or alternatively, the second AI or second SI derived from the second AI is communicated from the CCD to the MD. The first and second SI can include, but is not limited to, a hash of the AI, a secondary token unlocked by the AI, and/or a ticket from a credential service.

The first and second AI is analyzed in <NUM> to verify that the users identified thereby are the same. In some scenarios, this verification is made by comparing the first AI directly to the second AI to determine if a match exists therebetween. In other scenarios, this verification is made by: obtaining first user identification information contained in the first AI; obtaining second user identification information stored in a remote datastore (e.g., datastore <NUM> of <FIG>) using the second AI; and comparing the first and second user identification information to determine if a match exists therebetween. In yet other scenarios, this verification is made by: obtaining third user identification information contained in the second AI; obtaining fourth user identification information stored in a remote datastore (e.g., datastore <NUM> of <FIG>) using the first AI; and comparing the third and fourth user identification information to determine if a match exists therebetween. The present solution is not limited to the particulars of these scenarios.

If not [<NUM>:NO], then method <NUM> continues with <NUM> where the user is notified that (s)he has been denied access to the client computing device. This notification can be provided ot the user via the MD and/or the CCD. Subsequently, <NUM> is performed. In <NUM>, method <NUM> ends or other processing is performed (e.g., the computing device provides the user with another way to be authenticated for purposes of accessing a session, such as via a user-software interaction for inputting a username and password).

If the two users match each other [<NUM>:YES], then method <NUM> continues with <NUM> where operations are performed by the MD, CCD or a credential service (e.g., provide by cloud service server <NUM> of <FIG>) to generate a Full Resource Token ("FRT") based on the first AI, the second AI, the first SI and/or the second SI. Techniques for generating tokens are well known in the art, and therefore will not be described herein. Any known or to be known technique for generating tokens can be used herein without limitation. The FRI is then optionally provided to the MD and/or CCD as shown by <NUM>.

Claim 1:
A method for obtaining access to a session with a remote cloud service server via a first client computing device and preventing unintentionally launching the session on the first client computing device, wherein the method uses a mobile device capable of transmitting a user unique identifier to the first client computing device when a user carrying the mobile device walks by the first client computing device, the method comprising:
receiving, by the first client computing device, the user unique identifier from the mobile device located in proximity to the first client computing device, the user unique identifier being a first user name identifying a user of the mobile device;
initiating facial recognition operations by the first client computing device subsequent to the reception of the user unique identifier and in response thereto, where the facial recognition operations comprise
capturing by the first client computing device an image of the mobile device's user, and
analyzing the image to obtain a second user name that is stored in a datastore associated with the facial features represented in the image;
determining, by the first client computing device, if the second user name obtained during the facial recognition operations matches the first user name received from the mobile device; and
automatically launching a first session with the remote cloud service server responsive to a determination that the second user name obtained during the facial recognition operations matches the first user name received from the mobile device.