Abstract:
A user&#39;s session with a computing device can be migrated to any of a number of devices under the user&#39;s control. By allowing the user to migrate this session between devices in the user&#39;s device-sphere, much of the seamlessness of the user&#39;s experience in cloud computing is provided in a distributed device-sphere. The session is saved on a first device, sent to a second device, and reconstructed on the second device. A session record includes data, such as URIs, identifying the multiple open files of the session; data identifying the applications within which the files were open; and GUI positions of the windows of each of the open files.

Description:
[0001]    This application claims priority to U.S. Provisional Application No. 61/747,574, filed Dec. 31, 2012, which is fully incorporated herein by reference. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates generally to computer networks and, more particularly, to methods of and systems for improving inter-device data transport efficiency. 
         [0004]    2. Description of the Related Art 
         [0005]    Not too many years ago, an individual might use only one or two computing devices—perhaps one at work and perhaps one at home. Today, individuals use a wide variety of computing devices. For example, it is not at all uncommon for an individual to have multiple computers at work, at home (perhaps a desktop computer and a laptop computer), a smart phone (which includes a pocket-sized, fully functional computer), digital cameras (still and video), and perhaps one or more tablet computers. In addition, many household appliances in use today also incorporate fully functional computers. Such appliances include televisions, set-top boxes, personal video recorders (PVRs), digital media players, and networked music players. 
         [0006]    The multitude of devices used by an individual can be thought as the individual&#39;s device-sphere. One of the challenges associated with an individual&#39;s device-sphere is that the device-sphere is hardly seamless. An individual may which to view a video captured in a video camera on a television. Such typically requires a cabled connection between the two and separate control of each, despite the fact that both are fully capable of communication with one another through a computer network. Similar examples include wanting to watch a movie purchased and downloaded through a computer on the television, wanting to view photos taken with a digital still camera or smart phone&#39;s camera on a tablet computer or a work computer to share the photos with guests. Many, many other examples can be imagined in which data on one device in the device-sphere is desired to be accessible from another device in the device-sphere. 
         [0007]    Many predict that more and more of an individual&#39;s data will be stored in a “cloud”, i.e., in a remotely located server in a wide area network, which is typically drawn in block diagrams as a cloud. By storing all of one&#39;s data in the cloud, all of that individual&#39;s devices would have equal access to the data. Many resources have been, and continue to be, devoted to creating and improving the cloud in which all such data is to be stored. 
         [0008]    However, not everybody is eagerly rushing to migrate all their data to the cloud. One major concern is that of security of the data stored outside an individual&#39;s device-sphere. Photos in an individual&#39;s digital camera or smart phone appear to be secure as long as the individual retains physical possession of the camera and the phone. However, the same photos in the cloud are accessible to numerous employees of the entity providing the cloud service, e.g., information technology employees, data maintenance employees, and user support employees. In addition, instances of security failures regarding servers and services of large, well-known and trusted companies make headlines all too often. 
         [0009]    Perhaps an even more significant reason for the lack of a massive migration to cloud storage of everybody&#39;s personal data is simple convenience. Long gone are the days when someone crafting computer-implemented products and services could assume technological sophistication of the user base. For example, it is simply expected that using a smart phone to make telephone calls, send text messages, browse the web, take photos and video, store and listen to music, and even use the LED flash for photographs as a flashlight to be immediately intuitive and simple. And yet, it seems that producers of such smart phones have succeeded amazingly well in achieving that and similar goals for usability. 
         [0010]    However, when one produces a smart phone, the particulars of the cloud with which the smart phone should be configured to coordinate data migration is not known. So, any such integration is left to the user of the smart phone. Since the smart phone is meant to be an exceedingly easy to use appliance, most smart phone users either don&#39;t know how or don&#39;t want to configure smart phones after purchase to coordinate data migration with a cloud. 
         [0011]    Some smart phones are produced with cloud synchronization built-in. For example, the Android mobile operating system produced by Google, Inc. integrates well with cloud-based services provided by Google, Inc. A user of Android can have all photos captured by the smart phone automatically uploaded to the Google+ social networking service provided by Google, Inc. Similarly, the Windows 7 Mobile operating system provided by Microsoft Corp. integrates well with cloud-based services provided by Microsoft Corp. 
         [0012]    Yet, there is still hesitation by many to agree to automated synchronization of all user data to the cloud. For example, perhaps not all photos captured on a smart phone are suitable for automatic uploading to a social networking site, even if the photos remain private in the site until the user specifies otherwise. 
         [0013]    Whether out of security concerns, privacy concerns, or complexity in configuring interfaces between computing devices and cloud services, a user&#39;s personal data remains distributed across many devices operated by the user. In addition, it seems that this will continue to be the case for the foreseeable future. 
         [0014]    What is needed is a way to improve inter-device communication to facilitate a user&#39;s access to data distributed throughout the user&#39;s device-sphere. 
       SUMMARY OF THE INVENTION 
       [0015]    In accordance with the present invention, a user&#39;s session with a computing device can be migrated to any of a number of devices under the user&#39;s control. Any modern operating system includes a system of windows, each of which can be associated with a user space application processing a data file. The user can have multiple windows, and multiple associated data files, open and active within a session at one time. By allowing the user to migrate this session between devices in the user&#39;s device-sphere, much of the seamlessness of the user&#39;s experience in cloud computing is provided in a distributed device-sphere. 
         [0016]    To migrate a session from one device to another, the session is saved on the first device, sent to the second device, and reconstructed on the second device. 
         [0017]    The first device saves the session in a session record that includes data, such as URIs, identifying the multiple open files of the session. The session record can also include data identifying the applications within which the files were open and GUI positions of the windows of each of the open files. 
         [0018]    The first device sends the session record to the second device by broadcasting the session record to all devices of the user&#39;s device-sphere and/or by storing the session record in a predetermined location known to all devices in the device-sphere. Broadcasting the session record risks that no device connected to the network at the time the first device broadcasts the session record is connected to the network when the second device attempts to retrieve the session record. Storing the session record at a predetermined location requires that (i) at least one device in the device-sphere is always connected or (ii) a device outside the device-sphere be used as the predetermined location. Using both techniques in combination improves availability of the session record to the second device. 
         [0019]    The second device retrieves the session record by broadcasting a request for the session record to all devices of the user&#39;s device-sphere and/or by retrieving the session record from the predetermined location known to all devices in the device-sphere. 
         [0020]    The second device launches applications to open each of the data files represented in the session record and positions the launched applications in windows at approximate positions corresponding to the GUI positions of each data file represented in the session record. 
         [0021]    The end result is that the user&#39;s session on one device in her device-sphere is migrated to another device in her device-sphere. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0022]    Other systems, methods, features and advantages of the invention will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims. Component parts shown in the drawings are not necessarily to scale, and may be exaggerated to better illustrate the important features of the invention. In the drawings, like reference numerals may designate like parts throughout the different views, wherein: 
           [0023]      FIG. 1  is a diagram showing a number of devices that cooperate to migrate a user session from one device to another in accordance with one embodiment of the present invention. 
           [0024]      FIG. 2  is a block diagram showing an example of a user session that can be migrated in accordance with one embodiment of the present invention. 
           [0025]      FIG. 3  is a logic flow diagram showing the saving of a session in accordance with one embodiment of the present invention. 
           [0026]      FIG. 4  is a logic flow diagram showing the restoring of a session in accordance with one embodiment of the present invention. 
           [0027]      FIG. 5  is a transaction diagram illustrating one embodiment according to the invention of a method by which two devices of  FIG. 1  cooperate to open data files represented by URIs in the session record. 
           [0028]      FIG. 6  is a block diagram showing a session record that represents a usage session to be migrated between devices. 
           [0029]      FIG. 7  is a block diagram of MIME-type associations that can be used to ensure that a data file represented by a URI can be properly processed by the recipient device. 
           [0030]      FIG. 8  is a block diagram showing one of the devices of  FIG. 1  in greater detail. 
       
    
    
     DETAILED DESCRIPTION 
       [0031]    In accordance with the present invention, devices  102 A-G ( FIG. 1 ) of an individual&#39;s device-sphere cooperate to migrate a user&#39;s session from any of devices  102 A-G and  108  to any other of devices  102 A-G and  108 .  FIG. 2  shows a simple session involving two applications  202  and  204  on a computer desktop  200 . In this illustrative example, computer desktop  200  is to be migrated from device  102 E to device  102 A. The user has been working on device  102 E, using application  202  ( FIG. 2 ) to edit a text document and application  204  to edit a drawing, and now wishes to continue work using device  102 A using the same applications to edit the same data files. 
         [0032]    In this illustrative example, the user&#39;s device-sphere includes devices  102 A G, device  108 , and server  110 . Devices  102 A-G are coupled to one another through a local area network (LAN)  104 , which can be owned and operated by the individual user in her home. There are a wide variety of computing devices that can be included in one&#39;s device-sphere; the devices shown in  FIG. 1  are merely illustrative. Device  102 A is a laptop computer. Device  102 B is a smart phone. Device  102 C is a modern, networked television. Device  102 D is a networked PVR (Personal Video Recorder). 
         [0033]    Device  102 E is a desktop computer. Device  102 F is a NAS (Network-Attached Storage) appliance. Device  102 G is a tablet computer. 
         [0034]    Device  108  is remotely located, being connected to LAN  104  though a wide area network (WAN)  106 . In this illustrative embodiment, device  108  connects to LAN  104  through WAN  106  through a Virtual Private Network (VPN) connection. In this illustrative embodiment, WAN  106  is the Internet. 
         [0035]    Server  110  is also connected to LAN  104  though WAN  106 . Server  110  provides cloud services to the individual user through any of devices  102 A-G and  108 . Such cloud services can include e-mail, photo and video hosting and sharing, document editing and hosting, social networking, calendaring, and music streaming, for example. 
         [0036]    To migrate session  200  ( FIG. 2 ) from device  102 E to device  102 A, device  102 E first saves data representing session  200  in the manner illustrated by logic flow diagram  300  ( FIG. 3 ). The saving of session  200  can be triggered by a request of the user through physical manipulation of one or more user input devices and known GUI techniques or can be triggered automatically during shut-down of device  102 E 
         [0037]    In step  302 , device  102 E creates a session record such as session record  602  ( FIG. 6 ) to represent session  200  ( FIG. 2 ). User identifier  604  specifies the user name under which the current user is logged in within device  102 E. Digital fingerprint  606  is a globally unique identifier of device  102 E. Digital fingerprints offer the advantage of being more stable and less amenable to spoofing that are IP addresses and MAC addresses. Digital fingerprints are known and described in U.S. Patent Application Publication 2011/0093503 for “Computer Hardware Identity Tracking Using Characteristic Parameter-Derived Data” by Craig S. Etchegoyen (filed Apr. 21, 2011) and that description is incorporated herein in its entirety by reference. Time stamp  608  specifies the current time and date and the creation time and date of session record  602 . 
         [0038]    Loop step  304  ( FIG. 3 ) and next step  310  define a loop in which device  102 E processes each of the user-space applications currently in use in session  200  according to steps  306  and  308 . During each iteration of the loop of steps  304 - 310 , the particular application processed by device  102 E is sometimes referred to as the subject application in the context of logic flow diagram  300 . 
         [0039]    In step  306 , device  102 E creates an application record such as application record  610  ( FIG. 6 ) for the current application. Application  612  identifies the subject application. In some embodiments, application  612  is omitted and associations within device  102 A for MIME (Multipurpose Internet Mail Extensions) types, more recently referred to as Internet media types. 
         [0040]    In step  308  ( FIG. 3 ), device  102 E stores URI (uniform resource identifiers) and GUI (graphical user interface) locations for each open file of the subject application. For each open file of the subject application, device  102 E creates an open file record  614 . URI  616  specifies the location of the open file, including the device on which the open file is stored. MIME-type  618  specifies a type of data of the open file by MIME type. MIME types include a type and a subtype and can also include a number of additional parameters. For example, a web page in textual HTML has the MIME type of “text/html” wherein the type is “text” and the subtype is “html.” A common additional parameter specifies the particular character set of the web page. GUI position  620  specifies the location and size of the window in session  200  ( FIG. 2 ) of the open file of the subject application, including the relative depth of the window so as to indicate the which windows occlude other windows. 
         [0041]    From step  308  ( FIG. 3 ), processing by device  102 E transfers through next step  310  to loop step  304  to process the next application according to the loop of steps  304 - 310 . When all applications of session  200  have been processed, session record  602  ( FIG. 6 ) represents all open files and GUI locations of windows within session  200  ( FIG. 2 ) and processing by device  102 E transfers to step  312  ( FIG. 3 ). 
         [0042]    In step  312 , device  102 E broadcasts session record  602  ( FIG. 6 ) to all devices in the user&#39;s device-sphere, i.e., to devices A-G (excluding itself) and device  108 . In step  314 , device  102 E stores session record  602  in a location known to all devices in the user&#39;s device sphere. Such a location can be in server  110  or device  102 F, which is a NAS appliance, at a predetermined URL. Steps  312  and  314  seem redundant; however, step  312  avoids reliance on an external server for managing one&#39;s own device-sphere and step  314  provides backup for the situation in which none of the other devices of the user&#39;s device-sphere are powered on or at least connected to a network. 
         [0043]    In alternative embodiments, the user can specify—through physical manipulation of one or more user input devices and known GUI techniques—the device within her device-sphere to which session record  602  should be sent. In these alternative embodiments, session record  602  can be sent by e-mail to device  102 A such that device  102 A can receive session record  602  whenever device  102 A is powered up and connected to the network. After step  314 , processing according to logic flow diagram  300  completes. 
         [0044]    To complete migration of session  200  ( FIG. 2 ) from device  102 E to device  102 A, device  102 A uses the data representing session  200  to replication session  200  in the manner illustrated by logic flow diagram  400  ( FIG. 4 ). Session restoration can be triggered automatically at start-up or can be requested by the user. 
         [0045]    In step  402 , device  102 A retrieves the most recent of session records  602  ( FIG. 6 ) for which user identifier  604  specifies the user name under which the current user is logged in within device  102 A. Time stamp  608  is used by device  102 A to determine which of session records is the most recent. 
         [0046]    Device  102 A collects session records  602  by broadcasting a request for session records for the current user to all devices in the user&#39;s device-sphere and by retrieving a session record from the predetermined URL at which session records are stored for the subject user and her device-sphere. 
         [0047]    In an embodiment in which session record  602  is sent directly to device  102 A by direction from the user, an e-mail address for device  102 A is associated with session saving and restoration and the e-mail address is checked by device  102 A in step  402  ( FIG. 4 ) to retrieve the session record. 
         [0048]    Loop step  404  ( FIG. 4 ) and next step  410  define a loop in which device  102 A processes each of the application records  610  of the session record according to step  406  and  408 . During each iteration of the loop of steps  404 - 410 , the particular application record processed by device  102 A is sometimes referred to as the subject application record in the context of logic flow diagram  400 . 
         [0049]    In step  406 , device  102 A launches an application identified by application  612  of the subject application record. As described above, application  612  is omitted and associations within device  102 A for MIME types in some embodiments. In such embodiments, session record  602  includes only open file records  614 , and device  102 A skips step  406 . 
         [0050]    In step  408  ( FIG. 4 ), device  102 A processes all open file records  614  ( FIG. 6 ) to send URI  616  and GUI position  620  to cause the application to open the file identified by URI  616  in a window located at GUI position  620 . In embodiments in which application  612  is omitted, device  102 A uses MIME-type  618  to determine an application predetermined to be the one to process the data file type specified in MIME-type  618  within the operating system of device  102 A and launches an instance of that application, providing URI  616  and GUI position  620 . The result is that a new window opens in a session on device  102 A in which the data file identified by URI  616  at a location specified by GUI position  620  for an application qualified to process the data file. 
         [0051]    This process is illustrated by transaction flow diagram  500  ( FIG. 5 ). In this illustrative example, URI  616  of the subject open file indicates that the file is stored on device  102 F. It should be observed that the open file can be stored on any device at any location that can be specified by URI  616 . 
         [0052]    In step  502 , device  102 A launches a new application instance using URI  616  and GUI position  620  in the manner described above with respect to step  408  ( FIG. 4 ). Devices  102 A-G and  108  can vary widely in display dimensions and display resolutions. Accordingly, GUI positions within the display of each device are approximated and scaled to accommodate opening of multiple windows given each devices display size. In addition, some device, such as smart phones, have such small displays that each new window can use the entire screen in some embodiments. 
         [0053]    In step  504  ( FIG. 5 ), the newly launched application instance attempts to open the data file identified by the URI. 
         [0054]    In attempting to open the data file, device  102 A sends a request in step  506  to the device specified in the URI, e.g., device  102 F in this illustrative example. Along with the request, device  102 A sends a list of MIME types that device  102 A is capable of handling. For some of the MIME types, device  102 A has applications capable of properly processing that MIME type. For other MIME types, device  102 A is capable of converting a data file from that MIME type to one that device  102 A is capable of processing properly. 
         [0055]    In step  508 , device  102 F sends responsive data representing the data file identified by the URI received in step  506  in a MIME type data format that device  102 A supports as indicated by the MIME types specified in the request of step  506 . If the requested data file is not in any of the MIME types supported by device  102 A, device  102 F converts the data file to a MIME type that is supported by device  102 A if device  102 F has the capacity to do so and denies the request otherwise. In some embodiments, device  102 F or device  102 A can determine that the ability to edit the data file in the MIME type received should not be edited. Such can be the case if the received MIME type cannot handle formatting or features of the original format or if device  102 A has no editing applications for the received MIME type. In either case, the data file will be opened in a “read only” mode on device  102 A. 
         [0056]    From step  408  ( FIG. 4 ), processing by device  102 A transfers through next step  410  to loop step  404  to process the next application record according to the loop of steps  404 - 410 . When all applications records of session record  602  have been processed, session  200  ( FIG. 2 ) will have been restored on device  102 A and processing by device  102 A of logic flow diagram  400  ( FIG. 4 ) completes. 
         [0057]    Opening a file in step  408  includes using the URI of the file to retrieve the file from a device in the user&#39;s device-sphere and is illustrated in transaction flow diagram  500  ( FIG. 5 ). In step  502 , device  102 A creates a new instance of the application and, in step  504 , the new application instance attempts to open the file using the URI. The retrieval of the file specified by the URI is handled by the operating system of device  102 A, using a device identifier portion of the URI to identify the particular device within which the file is stored. In this illustrative example, the URI identifies device  102 F as the device on which the file is stored. Accordingly, device  102 A sends the URI request to device  102 F in step  506 . 
         [0058]    In addition to the URI request, device  102 A sends data representing all MIME types that device  102 A can process. Device  102 A determines which MIME types it can process by reference to MIME-type associations  700  ( FIG. 7 ). 
         [0059]    MIME-type associations  700  includes a number of MIME-type records  702 , each of which represents associations for a given MIME-type, which is identified by MIME-type  704 . Each MIME-type record  702  includes a number of associations  706 , which represent an application within device  102 A that can process data files of the given MIME-type. Application  708  identifies the application. Priority  710  specifies a relative priority among all associations  706  of a given MIME-type record  702 . Read only  712  indicates whether (i) the application specified by application  708  can process the file in a manner in which the user can modify the file or (ii) the application and only display the file. The application identified by application  708  can be merely a conversion application that converts data files of the type specified by MIME-type  704  to another type. 
         [0060]    Upon receipt of the URI and MIME types supported by device  102 A in step  506  (FIG.  5 ), device  102 F uses the URI to locate the data file identified by the URI and compares the MIME type of the data file to the MIME types supported by  102 A. If the MIME type of the data file is not one supported by device  102 A, device  102 F uses its own set of MIME-type associations  700  to determine whether device  102 F can convert the requested data file to a MIME type that device  102 A can process. 
         [0061]    In step  508 , device  102 F sends the data file, as converted if converted, to device  102 A as the response to the URI request. Device  102 A performs transaction flow diagram  500  for each URI to be opened. 
         [0062]    The end result is that session  200  is saved from device  102 E and restored to device  102 A. The user can thereafter continue editing the word processing document of window  202  and the drawing of window  204 . 
         [0063]    Device  102 A is shown in greater detail in  FIG. 8 , which is equally representative of devices  102 B-G and  108  unless otherwise noted here. Device  102 A includes one or more microprocessors  802  (collectively referred to as CPU  802 ) that retrieve data and/or instructions from memory  804  and execute retrieved instructions in a conventional manner. Memory  804  can include generally any computer-readable medium including, for example, persistent memory such as magnetic and/or optical disks, ROM, and PROM and volatile memory such as RAM. As used herein, “computer-readable medium” excludes any transitory signals but includes any non-transitory data storage circuitry, e.g., buffers, cache, and queues, within transceivers of transitory signals. 
         [0064]    CPU  802  and memory  804  are connected to one another through a conventional interconnect  806 , which is a bus in this illustrative embodiment and which connects CPU  802  and memory  804  to one or more input devices  808 , output devices  810 , and network access circuitry  812 . Input devices  808  can include, for example, a keyboard, a keypad, a touch-sensitive screen, a mouse, a microphone, and one or more cameras. Output devices  810  can include, for example, a display—such as a liquid crystal display (LCD)—and one or more loudspeakers. Network access circuitry  812  sends and receives data through computer networks such as LAN  104  ( FIG. 1 ). 
         [0065]    A number of components of device  102 A are stored in memory  804 . In particular, user space applications  820 , session migration logic  824  logic, and operating system  826  are each all or part of one or more computer processes executing within CPU  802  from memory  804  in this illustrative embodiment but can also be implemented using digital logic circuitry. As used herein, “logic” refers to (i) logic implemented as computer instructions and/or data within one or more computer processes and/or (ii) logic implemented in electronic circuitry. 
         [0066]    User space applications  820  are applications the user can use to view or edit data files. Session migration logic  824  saves and restores sessions in the manner described above. 
         [0067]    Operating system  826  is the operating system of device  102 A. An operating system is logic implemented in a computing device that provides services used by other logic implemented in the computing device. The services typically include management of computer resources such as file systems, peripheral device support, networking services, and computer process management. Generally, most users don&#39;t directly use an operating system but rather use logic that in turn uses the operating system to perform various tasks. Examples of operating systems in use today include Linux, Unix, MacOS, and various incarnations of the Windows operating system. 
         [0068]    In this illustrative embodiment, operating system  826  optimizes data traffic among devices  102 A-G and  108  in the manner described in co-pending, commonly owned U.S. Patent Application 61/770,662 filed Feb. 28, 2013, by Craig S. Etchegoyen for “Device-Specific Content Delivery” and that description is incorporated herein by reference. 
         [0069]    Digital fingerprint  822 , data files  830 , and MIME-type associations  700  are data stored persistently in memory  804 . Digital fingerprint  822  includes data specific to hardware elements of device  102 A, such as serial numbers and parameters of hardware components of device  102 A, to serve as a globally unique identifier of device  102 A. Data files  830  includes one or more data files that the user might want to view or edit using any of user space applications  820  on any of devices  102 A-G and  108 . MIME-type associations  700  are described above. 
         [0070]    The above description is illustrative only and is not limiting. The present invention is defined solely by the claims which follow and their full range of equivalents. It is intended that the following appended claims be interpreted as including all such alterations, modifications, permutations, and substitute equivalents as fall within the true spirit and scope of the present invention.