Patent Publication Number: US-9413758-B2

Title: Communication session transfer between devices

Description:
RELATED APPLICATIONS 
     This application is a continuation-in-part of U.S. application Ser. No. 14/467,627, filed on Aug. 25, 2014, which is a continuation of U.S. patent application Ser. No. 13/480,191, filed on May 24, 2012, now U.S. Pat. No. 8,850,037, issued on Sep. 30, 2014, both of which are incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     The subject matter of this application relates generally to methods and apparatuses, including computer program products, for communication session transfer between a plurality of computing devices. 
     BACKGROUND 
     Mobile devices such as smart phones, laptops, tablets, and the like have steadily increased in processing power and communication capability, allowing the devices to provide functionality that has previously been limited to desktop computing systems with dedicated network access. For example, mobile devices are able to connect to remove servers wirelessly and establish a communication session according to a protocol (e.g., Hypertext Transfer Protocol (HTTP), Transmission Control Protocol (TCP), and/or Bluetooth) for access to websites and other service offerings. 
     The security of such wireless communication sessions is increasingly important, in view of the potentially sensitive information that can be transmitted during a session. For example, a person may wish to check his bank account balance or apply for a mortgage loan using his smart phone. Eavesdroppers who listen in on the wireless signal must be prevented from gaining access to the sensitive information. The mobile devices have the capability of establishing and managing a communication session in a secure manner, through use of encryption and authentication techniques, such as HTTP Secure (HTTPS), Secure Socket Layer (SSL), public-key infrastructure (PKI), digital certificates, and secure cookies. 
     Also, many people now own a plurality of mobile devices and other personal computing devices and regularly use the devices for the same or similar purposes. For example, a person may carry a smart phone for web access (e.g., shopping, financial transactions, email, and/or job tasks) while commuting to and from work, and the person may switch to a tablet or laptop computer when she arrives home to continue the same activities. For example, if the person is reviewing her investment portfolio on her mobile device through an HTTPS session with Fidelity, she may want to pick up where she left off using a laptop in her home office. However, the person must manually establish another session with Fidelity on the laptop by connecting to the website, providing authentication credentials, and navigating to the same page or section of the website that she had been accessing on her mobile device. 
     SUMMARY OF THE INVENTION 
     What is needed is a wireless transfer of a communication session between devices to provide the user with a seamless transition from the transferring device to the recipient device. The techniques described herein provide for automatic transfer of active communication sessions from one device to another, while providing security and privacy mechanisms to protect the session transfer from unauthorized access and to ensure that the session is only transferred between validated devices. 
     The invention, in one aspect, features a method for communication session transfer between a plurality of computing devices. A first computing device detects a presence of a second computing device in proximity to the first computing device, where the first computing device has established a first communication session with a remote computing device. The first computing device obtains first user authentication data comprising at least one of (i) first biometric information from a user of the first computing device and (ii) a first wearable device identifier from a wearable device in communication with the first computing device. The first computing device establishes a wireless connection to the second computing device. The first computing device transmits a first token generated by the first computing device to the second computing device, where the first token includes a pre-stored shared key and an identifier associated with the first computing device and the first token is configured to render the first token invalid if copied for use as an identifier for another device. The first computing device receives a second token generated by the second computing device from the second computing device, where the second token includes the pre-stored shared key and an identifier associated with the second computing device and the second token is configured to render the second token invalid if copied for use as an identifier for another device. The first computing device authenticates the second token via comparison to the first token. The second computing device obtains second user authentication data comprising at least one of (i) second biometric information from a user of the second computing device and (ii) a second wearable device identifier from a wearable device in communication with the second computing device and transmitting the second user authentication data to the first computing device. The first computing device authenticates the second user authentication data via comparison to the first user authentication data. The first computing device transmits, to the second computing device, information indicating a state of the first communication session to enable the second computing device to establish a second communication session with the remote computing device, where the second communication session is established using the state of the first communication session. 
     The invention, in another aspect, features a system for communication session transfer between a plurality of computing devices. The system comprises a first computing device, a second computing device, and a remote computing device. The first computing device is configured to detect a presence of a second computing device in proximity to the first computing device, where the first computing device has established a first communication session with the remote computing device. The first computing device is configured to obtain first user authentication data comprising at least one of (i) first biometric information from a user of the first computing device and (ii) a first wearable device identifier from a wearable device in communication with the first computing device. The first computing device is configured to establish a wireless connection to the second computing device. The first computing device is configured to transmit a first token generated by the first computing device to the second computing device, where the first token includes a pre-stored shared key and an identifier associated with the first computing device and the first token is configured to render the first token invalid if copied for use as an identifier for another device. The first computing device is configured to receive a second token generated by the second computing device from the second computing device, where the second token includes the pre-stored shared key and an identifier associated with the second computing device and the second token is configured to render the second token invalid if copied for use as an identifier for another device. The first computing device is configured to authenticate the second token via comparison to the first token and authenticate second user authentication data received from the second computing device via comparison to the first user authentication data, where the second computing device obtains the second user authentication data comprising at least one of (i) second biometric information from a user of the second computing device and (ii) a second wearable device identifier from a wearable device in communication with the second computing device. The first computing device is configured to transmit information to the second computing device indicating a state of the first communication session to enable the second computing device to establish a second communication session with the remote computing device, where the second communication session is established using the state of the first communication session. 
     The invention, in another aspect, features a computer program product, tangibly embodied in a non-transitory computer readable storage medium, for communication session transfer between a plurality of computing devices. The computer program product includes instructions operable to cause a first computing device to detect a presence of a second computing device in proximity to the first computing device, where the first computing device has established a first communication session with the remote computing device. The computer program product includes instructions operable to cause the first computing device to obtain first user authentication data comprising at least one of (i) first biometric information from a user of the first computing device and (ii) a first wearable device identifier from a wearable device in communication with the first computing device. The computer program product includes instructions operable to cause the first computing device to establish a wireless connection to the second computing device. The computer program product includes instructions operable to cause the first computing device to transmit a first token generated by the first computing device to the second computing device, where the first token includes a pre-stored shared key and an identifier associated with the first computing device and the first token is configured to render the first token invalid if copied for use as an identifier for another device. The computer program product includes instructions operable to cause the first computing device to receive a second token generated by the second computing device from the second computing device, where the second token includes the pre-stored shared key and an identifier associated with the second computing device and the second token is configured to render the second token invalid if copied for use as an identifier for another device The computer program product includes instructions operable to cause the first computing device to authenticate the second token via comparison to the first token and authenticate second user authentication data received from the second computing device via comparison to the first user authentication data, where the second computing device obtains the second user authentication data comprising at least one of (i) second biometric information from a user of the second computing device and (ii) a second wearable device identifier from a wearable device in communication with the second computing device. The computer program product includes instructions operable to cause the first computing device to transmit information to the second computing device indicating a state of the first communication session to enable the second computing device to establish a second communication session with the remote computing device, where the second communication session is established using the state of the first communication session. 
     Any of the above aspects can include one or more of the following features. In some embodiments, the first communication session is at least one of: an HTTP-based session, an HTTPS-based session, or a TCP-based session. In some embodiments, detecting the presence of a second computing device includes monitoring an area around the first computing device for the presence of the second computing device. In some embodiments, the first token is generated by a security module of the first computing device, and the second token is generated by a security module of the second computing device. 
     In some embodiments, the first computing device determines whether the identifier of the second computing device is on a trusted list stored at the first computing device, establishes the wireless connection if the identifier of the second computing device is on the trusted list, and refuses the wireless connection if the identifier of the second computing device is not on the trusted list. In some embodiments, the first computing device determines whether the second computing device is connected to a same local network as the first computing device, establishes the wireless connection if the second computing device is connected to the same local network, and refuses the wireless connection if the second computing device is not connected to the same local network. 
     In some embodiments, the wireless connection includes at least one of: a Bluetooth connection, a near-field communication (NFC) connection, or a Wi-Fi connection. In some embodiments, the first computing device transmits, to the second computing device, a request to terminate the first communication session and the second computing device terminates the first communication session. In some embodiments, terminating the first communication session includes destroying a cookie associated with the first communication session, transmitting a session termination request to the remote computing device, or both. In some embodiments, the first computing device transmits, to the remote computing device, a request to terminate the first communication session. 
     In some embodiments, establishing a second communication session with the remote computing device includes launching, by the first computing device, an application to establish the second communication session. In some embodiments, the second communication session is established with one or more same security settings as the first communication session. In some embodiments, the first biometric information and the second biometric information comprises a digital image of the user, a sound file of the user&#39;s voice, a fingerprint of the user, or any combination thereof. In some embodiments, the wearable device identifier and the second wearable device identifier comprises a MAC address of the wearable device, a machine ID of the wearable device, a serial number of the wearable device, an IP address of the wearable device, or any combination thereof. 
     Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating the principles of the invention by way of example only. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The advantages of the invention described above, together with further advantages, may be better understood by referring to the following description taken in conjunction with the accompanying drawings. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. 
         FIG. 1  is a block diagram of a system for communication session transfer between a plurality of computing devices. 
         FIG. 2  is a flow diagram of a method for communication session transfer between a plurality of computing devices. 
         FIG. 3  is a flow diagram of a method for creating a secure token for communication session transfer between a plurality of computing devices. 
         FIG. 4  is a workflow diagram of a method for communication session transfer between a plurality of computing devices. 
         FIG. 5  is a workflow diagram of a method for communication session transfer between a plurality of computing devices. 
         FIG. 6  is a workflow diagram of a method for communication session transfer between a plurality of computing devices. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a block diagram of a system  100  for communication session transfer between a plurality of computing devices (e.g., computing devices  102 ,  103 ). The system  100  includes a mobile computing device  102 , a desktop computing device  103 , a communications network  104 , and a server computing device  106 . The mobile computing device  102  can establish a communication session  110  with the server computing device  106  via the network  104 . The mobile computing device  102  can communicate with the desktop computing device  103  via a wireless connection  120  (e.g., Wi-Fi, Bluetooth, and/or near-field communication (NFC)). Although  FIG. 1  depicts only a single mobile computing device  102 , a single desktop computing device  103 , a single communications network  104 , and a single server computing device  106 , the techniques described herein are not limited to this structure. Instead, this system  100  can include any of a number of configurations or components (e.g., multiple mobile and/or desktop computing devices, multiple servers) that do not depart from the scope and spirit of the invention. 
     In addition, it should be appreciated that the system  100  is not required to include a mobile computing device  102  and a desktop computing device  103 . Other computing devices can be introduced in place of the mobile computing device  102  and desktop computing device  103 . For example, the desktop computing device  103  can be replaced with a tablet computing device (e.g., iPad from Apple Computer Corp., Android™-based tablet, and/or other similar devices) without departing from the spirit and scope of the invention. 
     As mentioned above, the mobile computing device  102  communicates with the server computing device  106  via the communications network  104  to establish a communication session  110 . Example mobile computing devices  102  can include, but are not limited to, a smart phone (e.g., Apple iPhone®, BlackBerry®, and/or Android™-based device) or other mobile communications device, a tablet computer, an internet appliance, a personal computer, or the like. In some examples, the mobile device  102  can be installed in a vehicle. The mobile device  102  includes network-interface components to enable the device to connect to a communications network  104 , such as the Internet, wireless network (e.g., GPRS, CDMA, and/or RF), or the like. The mobile device  102  also includes components to enable the device to connect to other devices (e.g., desktop device  103 ) via a short-range frequency connection  120  (e.g., Bluetooth, Wi-Fi, and/or NFC). 
     The desktop computing device  103  also communicates with the server computing device  106  via the communications network  104 . The desktop device  103  can also establish a communication session  115  with the server device  106 . The desktop device  103  includes network-interface components (e.g., modem, Ethernet card, and/or wireless adapter) to enable the device to connect to a communications network  104 , such as the Internet. The desktop device  103  also includes components to enable the device to connect to other devices (e.g., mobile device  102 ) via a short-range frequency connection  120  (e.g., Bluetooth, Wi-Fi, and/or NFC). In some embodiments, the mobile device  102  and the desktop device  103  are located on the same local network. For example, the devices  102 ,  103  can be located at a user&#39;s residence and connect to a broadband cable modem for shared network access. 
     The server computing device  106  communicates with the mobile device  102  and the desktop device  103  via the network  104 . In some embodiments, the server computing device  106  is a web server that is capable of establishing a communication session  110 ,  115  with the mobile device  102  and/or the desktop device  103 —such as receiving HTTP/HTTPS requests from remote devices (e.g., devices  102 ,  103 ) and responding with HyperText Markup Language (HTML) content for presentation on the respective remote devices. For example, a user of the mobile device  102  can enter the Uniform Resource Locator (URL) of a website associated with his investment account, such as http://www.fidelity.com. The mobile device  102  transmits a request to the server computing device  106  via the network  104  (e.g., Internet), and the server device  106  responds with data for presentation of the home page of fidelity.com on the mobile device  102 . 
     The communications network  104  channels communications from the mobile device  102  and/or the desktop device  103  to the server  106 . The network  104  may be a local network, such as a LAN, or a wide area network, such as the Internet or the World Wide Web. The network  104  may utilize cellular, satellite or other wireless communications technology. For example, the mobile device  102  may send and receive information via a communications link to a satellite, which in turn communicates with the server  106 . The mobile device  102  and the server  106  can transmit data using standard formatting and/or transmission protocols, such as XML, HTTP, HTTPS, TCP, SMS, JSON, or other similar data communication techniques. 
     As described above, a user of the mobile device  102  can use the browser software installed on the mobile device  102  to connect to the server device  106  and establish a communication session  110  with the server. For example, the user may wish to review the asset allocation in his personal investment account held at Fidelity Investments. The user can enter the URL (http://www.fidelity.com) and establish a communication session  110  between the mobile device  102  and the server computing device  106  (e.g., web server operated by Fidelity). In some embodiments, the user is required to enter login credentials (e.g., username and/or password) or meet other authentication criteria before he can access his account information. 
     While the user is reviewing his asset allocation using Fidelity&#39;s website, he may want to switch from using the mobile device  102  to using another computing device (e.g., desktop device  103 ) without having to manually initiate another session with the website on the desktop device  103 . For example, the user may have already logged in to his account on the website and prepared an ad-hoc report detailing his present asset allocation. As a result, the user may not want to log in again and prepare the same report on his desktop device  103 . Instead, the user may want to transfer the current page and state of the existing session with Fidelity&#39;s website seamlessly to the desktop device  103 . 
       FIG. 2  is a flow diagram of a method  200  for communication session transfer between a plurality of computing devices using the system  100  of  FIG. 1 . The first computing device (e.g., mobile device  102 ) detects ( 202 ) the presence of a second computing device (e.g., desktop device  103 ) in proximity to the mobile device  102  that has established a first communication session with a remote computing device (e.g., server device  106 ). Continuing with the above example, the mobile device  102  can be configured to monitor an area around the device  102  to determine the existence of any other devices with which the mobile device  102  can communicate. The user can pass the mobile device  102  close to the desktop device  103  (e.g., waving the mobile device in front of the desktop device). Using its monitoring capabilities and associated network interface and antenna components, the mobile device  102 , in conjunction with the device software, determines that the desktop device  103  is in proximity to the mobile device based on a signal emitted by the desktop device  103 . In some embodiments, the desktop device  102  detects the existence of the mobile device  102  using similar techniques. 
     Once the mobile device  102  has detected the existence of the desktop device  103 , the mobile device  102  establishes ( 204 ) a wireless connection  120  to the desktop device  103 . In some embodiments, the mobile device  102  can use wireless communication protocols, such as Bluetooth or NFC, to establish the connection  120 . In another embodiment, the mobile device  102  can use a shared network (e.g., Wi-Fi) to establish the connection  120 . 
     After the mobile device  102  has established the wireless connection to the desktop device  103 , the desktop device  103  receives ( 206 ) information associated with the communication session  110  from the mobile device  102 . The information can include files stored on the mobile device  102  that indicate the state of the user&#39;s interaction with the website, such as HTTP or HTTPS cookies. The information can also include data items related to the communication session  110 , such as the URL and/or other address information (e.g., IP address of the server  106 ). In some embodiments, the information includes a token (or a portion of a token) generated by the mobile device  102  and used by the desktop device  103  to authenticate the identity of the mobile device  102 . More detail about creation and exchange of the token is described below with respect to  FIG. 3 . 
     When the desktop device  103  has received the information from the mobile device  102 , the desktop device  102  establishes ( 208 ) a second communication session  115  with the server computing device  106  using the received information. The second communication session  115  is established with the same state as the first communication session  110 . For example, as mentioned above, the desktop device  103  can automatically open a web browser and establish a communication session  115  with the server device  106  using the received information. The desktop device  103  can also automatically navigate to the same location (e.g., URL) as previously presented on the mobile device  102 , and can automatically provide authentication credentials to the server device  106  using the received information. Upon establishing the second communication session  115 , the desktop device  103  displays the same content as had been delivered from the server device  106  and presented on the mobile device  102 , appearing to the user as a seamless transfer of the session to the new device. 
     As described above, after establishing a connection with the mobile device  102 , the desktop device  103  receives information associated with the communication session  110  from the mobile device  102 . An important consideration in this process is the security and privacy of the connection between the devices  102  and  103 , as well as the identity of the devices  102  and  103 . A user may desire that his communication sessions can only be transferred between devices under his control, and not to other devices that may be in proximity to his transferring device. For example, thieves or hackers may use their own devices in an attempt to intercept a communication session transfer from a user&#39;s mobile device  102 . 
     To provide the desired security and privacy, the devices  102  and  103  can generate tokens, or portions of tokens, to be exchanged and validated during subsequent establishment of the wireless connection  120 .  FIG. 3  is a flow diagram of a method  300  for creating a secure token for communication session transfer between a plurality of computing devices, using the system  100  of  FIG. 1 . Token generation and management software is downloaded ( 302 ) to mobile device  102  and the desktop device  103 . The software can be a proprietary application and/or module that is installed on the respective device. In some embodiments, the software is related to the particular server device  106  and/or website for which the user wishes to transfer a communication session. 
     The software is launched ( 304 ) on each device  102  and  103 , and the user provides a shared ID that is common to all of the devices. For example, the shared ID can be a pass code or other text string that is known only to the user. Use of the shared ID provides a way for the respective devices  102  and  103  to identify each other as valid devices with which a connection can be established and a communication session can be transferred. 
     The device executes ( 306 ) the token generation operation in the software to create the token. The software includes the shared ID in the token structure. The software also incorporates an identifier in the token structure that uniquely identifies the individual device, such as a device ID (e.g., MAC address). The software also includes other parameters in the token structure such as the duration that the token is active, and preferred or required connection protocols to be used when wirelessly connecting to other devices (e.g., NFC, Bluetooth, and/or Wi-Fi). In some embodiments, the token is encrypted to protect the information in the token and increase the level of security associated with the token. 
     The software stores ( 308 ) the generated tokens in a secure area of the respective devices  102  and  103 . Because the token contains the unique identifier of the device on which the token is stored, the token is not valid if relocated to another device—preventing unauthorized copying or use of the token to gain access to a communication session being transferred between devices  102  and  103 . 
       FIG. 4  is a workflow diagram of a method  400  for communication session transfer between a plurality of computing devices, using the system  100  of  FIG. 1 . Each client computing device  102 ,  103  has previously generated a token, as described above with respect to  FIG. 3 . In addition, the mobile device  102  has previously established a communication session (e.g., HTTP) with the server computing device  106 . During creation of the previously-established communication session, the server device  106  provided a cookie (e.g., Cookie=abc  402   a ) to the mobile device  102  that identifies the session. The user now wishes to transfer the previously-established communication session from the mobile device  102  to the desktop device  103 .
         Step 1: The user places the mobile device  102  in proximity to the desktop device  103 , and the mobile device  102  detects the existence of the desktop device  103  via a wireless protocol (e.g., Bluetooth, NFC, and/or Wi-Fi). The mobile device  102  and the desktop device  103  perform a handshake routine using the token generation and management software to validate the identity of each device and validate that a wireless connection to transfer a session between the devices should be established.   In some embodiments, the handshake routine includes the desktop device  103  sending its token (or portion of a token) to the mobile device  102 . The token generation and management software on the mobile device  102  analyzes the token received from the desktop device  103  to validate the identity of the desktop device  103 . For example, the software can validate the unique identifier of the desktop device  103  and the shared ID as stored in the token. In the case where the token is encrypted, the mobile device  102  can decrypt the token prior to analysis. In some embodiments, the mobile device  102  maintains a trusted list of devices with which it can establish wireless connections and transfer communication sessions. The mobile device  102  can compare the unique identifier in the received token against the trusted list to validate the identity of the desktop device  103 . If the received token cannot be validated, the mobile device  102  can refuse to connect with the desktop device  103 . In some embodiments, the handshake route occurs in the reverse fashion, where the desktop device  103  analyzes and validates a token received from the mobile device  102 . Once the software on the mobile device  102  has validated the received token, the handshake routine includes the mobile device  102  sending the credentials associated with Cookie=abc  402   a  to the desktop device  103 .   In some embodiments, in validating the desktop device  103 , the mobile device  102  determines whether the desktop device  103  is located on the same local network (e.g., a Wi-Fi LAN) as the mobile device  102 . For example, the mobile device  102  and the desktop device  103  can both be connected to the user&#39;s personal LAN at his home. The personal LAN may have certain security settings that the devices  102 ,  103  share and that can be validated. If the desktop device  103  is located on the same local network, then the mobile device  102  establishes the wireless connection to the desktop device. If the desktop device  103  is not located on the same local network, then the mobile device  102  refuses to establish the wireless connection.   Step 2: Using the Cookie=abc  402   a  credentials, the desktop device  103  connects to the server device  106  and establishes a new communication session with the server device  106 . Upon establishing the new session, the server device  106  returns another cookie (e.g., Cookie=xyz  402   b ) that identifies the new session. Because the session was initiated by the desktop device  103  using the credentials of Cookie=abc  402   a , the credentials of Cookie=xyz  402   b  returned by the server  106  match the Cookie=abc  402   a  credentials. As a result, the new session retains the attributes and state of the previously-established session.   Step 3: The desktop device  103 , using the token generation and management software, sends an accept session transfer message to the mobile device  102 . The accept session transfer message informs the mobile device  102  that the desktop device  103  has successfully established a session with the server device  106 .   Step 4: Using the previously-established communication session (which remains active), the mobile device  102  sends a session termination message to the server device  106 . The session termination message includes an instruction to destroy the Cookie=abc  402   a  and end the communication session between the mobile device  102  and the server device  106 .   In some embodiments, the mobile device  102  does not send the session transmission message to the server device  106 . The previously-established communication session between the mobile device  102  and the server device  106  remains active for additional interaction by the user.       

     Any of the above-described embodiments can include additional features to enhance the security of the communication session transfer between devices. One feature involves the use of biometric information of the user to authenticate the user and authorize the completion of the session transfer to the receiving device.  FIG. 5  is a workflow diagram of a method  500  for communication session transfer between a plurality of computing devices, using the system  100  of  FIG. 1 . Each client computing device  102 ,  103  has previously generated a token, as described above with respect to  FIG. 3 . In addition, the mobile device  102  has previously established a communication session (e.g., HTTP) with the server computing device  106 . During creation of the previously-established communication session, the server device  106  provided a cookie (e.g., Cookie=abc  402   a ) to the mobile device  102  that identifies the session. The user now wishes to transfer the previously-established communication session from the mobile device  102  to the desktop device  103 .
         Step 1: The user issues a request to transfer the communication session from the mobile device  102  to the desktop device  103  by, e.g., providing user input to activate an application (or a function within an application) to request the transfer. Upon receiving the request to transfer the session, the mobile device  102  obtains biometric information from the user. For example, the mobile device  102  can utilize a camera embedded in the mobile device  102  to capture an image of the user&#39;s face. In some embodiments, the mobile device  102  can prompt the user to position the camera so that it is viewing the user&#39;s face, while in other embodiments the mobile device  102  can automatically capture an image of the user&#39;s face without prompting or alerting the user that it is doing so. In another example, the mobile device  102  can ask the user to utter a specific phrase into a microphone embedded in the mobile device and capture the spoken phrase as a digital sound file. In another example, the mobile device  102  can utilize a fingerprint identity sensor embedded in the mobile device (e.g., Touch ID available in the Apple® iPhone®) to capture a fingerprint map of the user. If the biometric information cannot be obtained from the user, then the communication session transfer process can be halted.   Step 2: The user places the mobile device  102  in proximity to the desktop device  103 , and the mobile device  102  detects the existence of the desktop device  103  via a wireless protocol (e.g., Bluetooth, NFC, and/or Wi-Fi). The mobile device  102  and the desktop device  103  perform a handshake routine using the token generation and management software to validate the identity of each device and validate that a wireless connection to transfer a session between the devices should be established.   In some embodiments, the handshake routine includes the desktop device  103  sending its token (or portion of a token) to the mobile device  102 . The token generation and management software on the mobile device  102  analyzes the token received from the desktop device  103  to validate the identity of the desktop device  103 . For example, the software can validate the unique identifier of the desktop device  103  and the shared ID as stored in the token. In the case where the token is encrypted, the mobile device  102  can decrypt the token prior to analysis. In some embodiments, the mobile device  102  maintains a trusted list of devices with which it can establish wireless connections and transfer communication sessions. The mobile device  102  can compare the unique identifier in the received token against the trusted list to validate the identity of the desktop device  103 . If the received token cannot be validated, the mobile device  102  can refuse to connect with the desktop device  103 . In some embodiments, the handshake route occurs in the reverse fashion, where the desktop device  103  analyzes and validates a token received from the mobile device  102 . Once the software on the mobile device  102  has validated the received token, the handshake routine includes the mobile device  102  sending the credentials associated with Cookie=abc  402   a  to the desktop device  103 .   In some embodiments, in validating the desktop device  103 , the mobile device  102  determines whether the desktop device  103  is located on the same local network (e.g., a Wi-Fi LAN) as the mobile device  102 . For example, the mobile device  102  and the desktop device  103  can both be connected to the user&#39;s personal LAN at his home. The personal LAN may have certain security settings that the devices  102 ,  103  share and that can be validated. If the desktop device  103  is located on the same local network, then the mobile device  102  establishes the wireless connection to the desktop device. If the desktop device  103  is not located on the same local network, then the mobile device  102  refuses to establish the wireless connection.   Step 3: The desktop device  103  also obtains biometric information from the user using similar methods as described above with respect to Step 1. In some embodiments, the desktop device  103  receives the biometric information obtained by the mobile device  102  in Step 1 as part of the handshake routine described in Step 2 above. The desktop device  103  compares the biometric information received as part of the handshake routine with the biometric information that it obtained separately to determine whether the two pieces of biometric information match. For example, the desktop device  103  can utilize specialized software to perform facial recognition techniques on the two captured digital images of the user&#39;s face to determine whether the images (i) depict the same face and (ii) depict the face of the authorized user. Similarly, the desktop device  103  can utilize voice recognition software and speech-to-text software to analyze the two captured digital sound files to determine whether the files (i) represent a voice of the same speaker, (ii) whether that voice belongs to the authorized user, and (iii) whether the words spoken by the user match.   In some embodiments, the desktop device  103  can communicate with, e.g., the server computing device  106  (or another remote computing device such as an authentication server) to retrieve pre-stored authentication information from, e.g., a user profile to validate the comparisons described above. For example, to determine whether two captured digital images contain the same face, the desktop device  103  can simply utilized facial recognition software to analyze the images and determine whether they contain the same face. However, to determine whether the digital images contain the face of the authorized user, the desktop device  103  can request pre-stored metrics (e.g., a validation score) associated with characteristics of the user&#39;s face from the server computing device  106  and compare the metrics against metrics that the desktop device  103  generated during analysis of the captured digital image to determine whether a minimum validation threshold is met. At a previous time, such as establishment of a user account, the user can submit a digital image of himself or herself to the server computing device  106 . The image is then analyzed for facial characteristics to generate the metrics, which are stored at the server computing device  106  in a user profile. Subsequent authentication requests from the mobile device  102  and/or the desktop device  103  reference the user profile, and the server computing device  106  provides the relevant metrics to the requesting device so that device can perform the validation process described above.   If the biometric information is not validated (e.g., the two pieces of biometric information obtained by the mobile device  102  and the desktop device  103  do not match and/or the user cannot be properly authenticated from the biometric information), then the communication session transfer process can be stopped at this point.   Step 4: Using the Cookie=abc  402   a  credentials, the desktop device  103  connects to the server device  106  and establishes a new communication session with the server device  106 . Upon establishing the new session, the server device  106  returns another cookie (e.g., Cookie=xyz  402   b ) that identifies the new session. Because the session was initiated by the desktop device  103  using the credentials of Cookie=abc  402   a , the credentials of Cookie=xyz  402   b  returned by the server  106  match the Cookie=abc  402   a  credentials. As a result, the new session retains the attributes and state of the previously-established session.   Step 5: The desktop device  103 , using the token generation and management software, sends an accept session transfer message to the mobile device  102 . The accept session transfer message informs the mobile device  102  that the desktop device  103  has successfully established a session with the server device  106 .   Step 6: Using the previously-established communication session (which remains active), the mobile device  102  sends a session termination message to the server device  106 . The session termination message includes an instruction to destroy the Cookie=abc  402   a  and end the communication session between the mobile device  102  and the server device  106 .   In some embodiments, the mobile device  102  does not send the session transmission message to the server device  106 . The previously-established communication session between the mobile device  102  and the server device  106  remains active for additional interaction by the user.       

     Another available feature to enhance the security of the communication session transfer between devices involves the use of wearable devices to authenticate the user and authorize the completion of the session transfer to the receiving device. Wearable devices can include, but are not limited to, smart watches (e.g., Apple® Watch), fitness devices (e.g., FitBit®), smart glasses (e.g., Google® Glass) and other types of wearable devices such as sensors embedded in clothing, etc. 
       FIG. 6  is a workflow diagram of a method  600  for communication session transfer between a plurality of computing devices, using the system  100  of  FIG. 1 . Each client computing device  102 ,  103  has previously generated a token, as described above with respect to  FIG. 3 . In addition, the mobile device  102  has previously established a communication session (e.g., HTTP) with the server computing device  106 . During creation of the previously-established communication session, the server device  106  provided a cookie (e.g., Cookie=abc  402   a ) to the mobile device  102  that identifies the session. The user now wishes to transfer the previously-established communication session from the mobile device  102  to the desktop device  103 .
         Step 1: The user issues a request to transfer the communication session from the mobile device  102  to the desktop device  103  by, e.g., providing user input to activate an application (or a function within an application) to request the transfer. Upon receiving the request to transfer the session, the mobile device  102  scans an area in close proximity in order to detect the presence of wearable devices  604 . Upon detecting a wearable device  604 , the mobile device  102  obtains an identifier from the wearable device  604  that uniquely identifies the wearable device. Such identifiers can include, but are not limited to, a MAC address, an IP address, a serial number, a device fingerprint, and so forth. If a wearable device  604  identifier cannot be obtained, then the communication session transfer process can be halted.   Step 2: The user places the mobile device  102  in proximity to the desktop device  103 , and the mobile device  102  detects the existence of the desktop device  103  via a wireless protocol (e.g., Bluetooth, NFC, and/or Wi-Fi). The mobile device  102  and the desktop device  103  perform a handshake routine using the token generation and management software to validate the identity of each device and validate that a wireless connection to transfer a session between the devices should be established.   In some embodiments, the handshake routine includes the desktop device  103  sending its token (or portion of a token) to the mobile device  102 . The token generation and management software on the mobile device  102  analyzes the token received from the desktop device  103  to validate the identity of the desktop device  103 . For example, the software can validate the unique identifier of the desktop device  103  and the shared ID as stored in the token. In the case where the token is encrypted, the mobile device  102  can decrypt the token prior to analysis. In some embodiments, the mobile device  102  maintains a trusted list of devices with which it can establish wireless connections and transfer communication sessions. The mobile device  102  can compare the unique identifier in the received token against the trusted list to validate the identity of the desktop device  103 . If the received token cannot be validated, the mobile device  102  can refuse to connect with the desktop device  103 . In some embodiments, the handshake route occurs in the reverse fashion, where the desktop device  103  analyzes and validates a token received from the mobile device  102 . Once the software on the mobile device  102  has validated the received token, the handshake routine includes the mobile device  102  sending the credentials associated with Cookie=abc  402   a  to the desktop device  103 .   In some embodiments, in validating the desktop device  103 , the mobile device  102  determines whether the desktop device  103  is located on the same local network (e.g., a Wi-Fi LAN) as the mobile device  102 . For example, the mobile device  102  and the desktop device  103  can both be connected to the user&#39;s personal LAN at his home. The personal LAN may have certain security settings that the devices  102 ,  103  share and that can be validated. If the desktop device  103  is located on the same local network, then the mobile device  102  establishes the wireless connection to the desktop device. If the desktop device  103  is not located on the same local network, then the mobile device  102  refuses to establish the wireless connection.   Step 3: The desktop device  103  also scans an area in close proximity in order to detect the presence of wearable devices  604  and obtain an identifier from the wearable device using similar methods as described above with respect to Step 1. In some embodiments, the desktop device  103  receives the identifier obtained by the mobile device  102  in Step 1 as part of the handshake routine described in Step 2 above. The desktop device  103  compares the wearable device  604  identifier received as part of the handshake routine with the identifier that it obtained separately to determine whether the two identifiers match.   In some embodiments, the desktop device  103  can communicate with, e.g., the server computing device  106  (or another remote computing device such as an authentication server) to retrieve pre-stored wearable device  604  identifier information from, e.g., a user profile in order to perform and/or validate the identifier comparison described above. For example, to determine whether the identifier corresponds to a wearable device owned by the authorized user, the desktop device  103  can request a pre-stored wearable device identifier from the server computing device  106  and compare the pre-stored identifier against the identifier that the desktop device  103  obtained (and/or the identifier that the mobile device  102  obtained) in order to determine a match. At a previous time, such as establishment of a user account, the user can submit a wearable device identifier to the server computing device  106 , which is then stored at the server computing device  106  in a user profile. Subsequent authentication requests from the mobile device  102  and/or the desktop device  103  reference the user profile, and the server computing device  106  provides the pre-stored identifier to the requesting device so that device can perform the validation process described above. If the wearable device identifier is not validated, then the communication session transfer process can be stopped at this point.   Step 4: Using the Cookie=abc  402   a  credentials, the desktop device  103  connects to the server device  106  and establishes a new communication session with the server device  106 . Upon establishing the new session, the server device  106  returns another cookie (e.g., Cookie=xyz  402   b ) that identifies the new session. Because the session was initiated by the desktop device  103  using the credentials of Cookie=abc  402   a , the credentials of Cookie=xyz  402   b  returned by the server  106  match the Cookie=abc  402   a  credentials. As a result, the new session retains the attributes and state of the previously-established session.   Step 5: The desktop device  103 , using the token generation and management software, sends an accept session transfer message to the mobile device  102 . The accept session transfer message informs the mobile device  102  that the desktop device  103  has successfully established a session with the server device  106 .   Step 6: Using the previously-established communication session (which remains active), the mobile device  102  sends a session termination message to the server device  106 . The session termination message includes an instruction to destroy the Cookie=abc  402   a  and end the communication session between the mobile device  102  and the server device  106 .       

     In some embodiments, the mobile device  102  does not send the session transmission message to the server device  106 . The previously-established communication session between the mobile device  102  and the server device  106  remains active for additional interaction by the user. 
     The above-described techniques can be implemented in digital and/or analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The implementation can be as a computer program product, i.e., a computer program tangibly embodied in a machine-readable storage device, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, and/or multiple computers. A computer program can be written in any form of computer or programming language, including source code, compiled code, interpreted code and/or machine code, and the computer program can be deployed in any form, including as a stand-alone program or as a subroutine, element, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one or more sites. 
     Method steps can be performed by one or more processors executing a computer program to perform functions of the invention by operating on input data and/or generating output data. Method steps can also be performed by, and an apparatus can be implemented as, special purpose logic circuitry, e.g., a FPGA (field programmable gate array), a FPAA (field-programmable analog array), a CPLD (complex programmable logic device), a PSoC (Programmable System-on-Chip), ASIP (application-specific instruction-set processor), or an ASIC (application-specific integrated circuit), or the like. Subroutines can refer to portions of the stored computer program and/or the processor, and/or the special circuitry that implement one or more functions. 
     Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital or analog computer. Generally, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and/or data. Memory devices, such as a cache, can be used to temporarily store data. Memory devices can also be used for long-term data storage. Generally, a computer also includes, or is operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. A computer can also be operatively coupled to a communications network in order to receive instructions and/or data from the network and/or to transfer instructions and/or data to the network. Computer-readable storage mediums suitable for embodying computer program instructions and data include all forms of volatile and non-volatile memory, including by way of example semiconductor memory devices, e.g., DRAM, SRAM, EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and optical disks, e.g., CD, DVD, HD-DVD, and Blu-ray disks. The processor and the memory can be supplemented by and/or incorporated in special purpose logic circuitry. 
     To provide for interaction with a user, the above described techniques can be implemented on a computer in communication with a display device, e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer (e.g., interact with a user interface element). Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, and/or tactile input. 
     The above described techniques can be implemented in a distributed computing system that includes a back-end component. The back-end component can, for example, be a data server, a middleware component, and/or an application server. The above described techniques can be implemented in a distributed computing system that includes a front-end component. The front-end component can, for example, be a client computer having a graphical user interface, a Web browser through which a user can interact with an example implementation, and/or other graphical user interfaces for a transmitting device. The above described techniques can be implemented in a distributed computing system that includes any combination of such back-end, middleware, or front-end components. 
     The components of the computing system can be interconnected by transmission medium, which can include any form or medium of digital or analog data communication (e.g., a communication network). Transmission medium can include one or more packet-based networks and/or one or more circuit-based networks in any configuration. Packet-based networks can include, for example, the Internet, a carrier internet protocol (IP) network (e.g., local area network (LAN), wide area network (WAN), campus area network (CAN), metropolitan area network (MAN), home area network (HAN)), a private IP network, an IP private branch exchange (IPBX), a wireless network (e.g., radio access network (RAN), Bluetooth, Wi-Fi, WiMAX, general packet radio service (GPRS) network, HiperLAN), and/or other packet-based networks. Circuit-based networks can include, for example, the public switched telephone network (PSTN), a legacy private branch exchange (PBX), a wireless network (e.g., RAN, code-division multiple access (CDMA) network, time division multiple access (TDMA) network, global system for mobile communications (GSM) network), and/or other circuit-based networks. 
     Information transfer over transmission medium can be based on one or more communication protocols. Communication protocols can include, for example, Ethernet protocol, Internet Protocol (IP), Voice over IP (VOIP), a Peer-to-Peer (P2P) protocol, Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MGCP), Signaling System #7 (SS7), a Global System for Mobile Communications (GSM) protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and/or other communication protocols. 
     Devices of the computing system can include, for example, a computer, a computer with a browser device, a telephone, an IP phone, a mobile device (e.g., cellular phone, personal digital assistant (PDA) device, smart phone, tablet, laptop computer, electronic mail device), and/or other communication devices. The browser device includes, for example, a computer (e.g., desktop computer and/or laptop computer) with a World Wide Web browser (e.g., Chrome™ from Google, Inc., Microsoft® Internet Explorer® available from Microsoft Corporation, and/or Mozilla® Firefox available from Mozilla Corporation). Mobile computing device include, for example, a Blackberry® from Research in Motion, an iPhone® from Apple Corporation, and/or an Android™-based device. IP phones include, for example, a Cisco® Unified IP Phone 7985G and/or a Cisco® Unified Wireless Phone 7920 available from Cisco Systems, Inc. 
     Comprise, include, and/or plural forms of each are open ended and include the listed parts and can include additional parts that are not listed. And/or is open ended and includes one or more of the listed parts and combinations of the listed parts. 
     One skilled in the art will realize the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative rather than limiting of the invention described herein.