Patent Application
20240289138
The present disclosure relates to the integration of mobile and stationary computing.
A system for a mobile computing device and a stationary computing device associated with a user to interwork, wherein: the mobile computing device comprises a device interoperability system having a communications module, wherein a first connection is established between the stationary computing device and the communications module; storage coupled to said communications module, wherein the storage stores an operating system, one or more programs, data associated with the user, further wherein the operating system is booted by the stationary computing device via the first connection, the operating system runs on the stationary computing device, and the operating system uses one or more processing capabilities of the stationary computing device for operation; and one or more processors to support said device interoperability system.
A method for a mobile computing device and a stationary computing device associated with a user to interwork, the method comprising: providing a device interoperability system comprising a communications module, storage coupled to the communications module, and the device interoperability system is installed on the mobile computing device; enabling establishment of a first connection between the stationary computing device and the communications module; enabling the storage to store information comprising an operating system, one or more programs, and data associated with the user; enabling booting of the operating system by the stationary computing device via the first connection; and enabling the operating system to run on the stationary computing device and use one or more processing capabilities of the stationary computing device for operation.
The foregoing and additional aspects and embodiments of the present disclosure will be apparent to those of ordinary skill in the art in view of the detailed description of various embodiments and/or aspects, which is made with reference to the drawings, a brief description of which is provided next.
The foregoing and other advantages of the disclosure will become apparent upon reading the following detailed description and upon reference to the drawings.
While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments or implementations have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the disclosure is not intended to be limited to the particular forms disclosed. Rather, the disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of an invention as defined by the appended claims.
The number of devices owned or operated by a person has grown tremendously.
Typically, a person has a plurality of computing devices, such as:
In addition, many other devices and items have become “smart”, that is, their computing capabilities and processing power have increased, and they have been network enabled. These include, for example:
Furthermore the “Internet of Things” (IoT) has also grown tremendously. The IoT refers to networks of consumer and industrial devices interconnected with each other and with other computing devices.
All of this means that the number of devices which have computing and network capability, and are associated with a particular user, is growing rapidly.
Given the situation shown in
These techniques of document and data synchronization have deficiencies. Cloud connectivity may not always be present. When it is, connectivity may be intermittent or slow. Privacy may also be an issue with cloud-based techniques. Furthermore, aggregating data from a lot of users at a central location, means that the central location poses an attractive target to cyber-criminals, which poses security challenges.
Secondly, synchronization may be imperfect or incomplete due to each computing device and consumer item running different operating systems (OSes) and different platforms. Referring to
It is therefore necessary to address these deficiencies in device synchronization in order to ensure continued growth and adoption of “smart” technology; and interoperability of these user devices.
These problems are also faced by users who work in mobile and stationary work modes. Mobile computing devices such as laptops are often used in a combination of mobile and stationary work modes. Users use laptops in a stationary mode at home or in the office, and they switch to a mobile mode whereby they take their laptop with them, for example, to business meetings, cafes, and to travel.
Currently, mobile computing devices offer tradeoffs between mobility, battery runtime, performance and convenience. In stationary mode, the mobile computing device can be plugged into mains power supply, so battery availability is not such a problem. Then, computing performance and convenience take precedence. A user who wants computing performance and convenience can purchase a high performance laptop, such as, for example, a gaming laptop or a workstation laptop.
However, using a high performance laptop may pose problems to the user in mobile mode. High performance laptops have higher energy consumption, thereby reducing battery runtime. Heat dissipation during operation increases, requiring bigger cooling systems which are heavier and draw more energy, which lead to reduced mobility and further reduce battery runtime. High performance laptops tend to be more expensive as well.
Users can purchase laptops which are designed to be cheaper, smaller and lighter and therefore better suit the mobile mode. However these laptops tend to offer lower performance and less convenience to the user while in stationary mode. Currently users can take some steps to extend the capabilities of such lightweight models. For example, a user can attach a docking station while in stationary mode, so as to extend and simplify the connectivity of the laptop. The user can also connect an external display while in stationary mode to increase the size of the display available for viewing. Finally, a user can connect an external graphics processing unit (eGPU) to the laptop. Typically, this is a normal desktop-grade graphics card placed in a separate case with a power supply unit (PSU) and cooling system. The eGPU is connected to the laptop in a stationary mode via a high-speed interface port such as a Thunderbolt port, to provide additional graphics performance. However these steps can only extend the capabilities so much.
Another potential solution for the user who wants good performance and convenience in the stationary mode, and also good mobility and battery runtime while in mobile mode, is to purchase a combination of a lightweight and long battery runtime laptop for mobile mode; and a desktop which offers high performance and convenience for stationary mode. This laptop-desktop combination offers several advantages over a single high-performance laptop: Typically desktops can deliver much more processing power than a high-performance laptop in stationary mode. The desktop is designed as a stationary mode device, where else the high-performance laptop designer must take mobility and battery runtime into account. Therefore, desktops do not face the energy, space and cooling limitations faced by a high performance laptop, meaning that a desktop designer can optimize for performance of tasks such as gaming and professional tasks in a stationary mode.
While the laptop-desktop combination does offer a potential solution to improve user experience in mobile and stationary modes, it does face some of the general limitations detailed above. For example, a user still needs to synchronize data between the laptop and desktop, which may pose privacy and security issues if the user chooses to use cloud-based techniques. The OSes and installed applications on the laptop and desktop may be configured differently, leading to some switching friction between mobile and stationary modes. Together, this leads to a less than ideal user experience.
The remainder of this specification details a system and a method for device interoperability to address the above problems, and a specific application of such a system and method for the user who works in mobile and stationary modes.
The system and method for device interoperability is detailed first. An example architecture of such a device interoperability system 200 is shown in
Device interoperability system 200 comprises several components necessary for its functioning. An illustration of one embodiment of device interoperability system 200 is shown in
The one or more processors 215 perform the functions of supporting the other elements of device interoperability system 200. This includes, for example:
Communications module 213 participates in the establishment of the one or more connections 201-1 to 201-N. Communications module 213 also works to maintain the one or more connections 201-1 to 201-N to the one or more user devices 101-1 to 101-N.
Communications module 213 also works to perform operations necessary to secure connections 201-1 to 201-N. These include, for example, encryption and access operations. In one embodiment, communications module 213 also manages and optimizes power consumption related to one or more connections 201-1 to 201-N. For example, communications module 213 adjusts the transmission powers used for the one or more connections 201-1 to 201-N based on distances from user devices such as user device 101-1.
Battery 211 supplies power for the operation of device interoperability system 200. Charging module 221 enables charging of battery 211 using an external power source. In one embodiment, charging module 221 enables wireless charging.
As shown in
Referring to
In one embodiment, at least one of the connections 201-1 to 201-N is a direct connection. This direct connection can be, for example, a direct wireless connection.
In some embodiments, user device 101-1 comprises firmware that provides the ability to support booting from device interoperability system 200 via a direct wireless connection. For example, in one embodiment, user device 101-1 comprises a Basic Input Output System (BIOS) or Unified Extensible Firmware Interface (UEFI) which supports the Media Agnostic USB specification. This allows the user device 101-1 to use the USB protocol over the direct wireless connection to facilitate the booting of OS 214 on the user device 101-1 and data transfer between device interoperability system 200 and user device 101-1.
In some embodiments, user device 101-1 does not comprise firmware that provides the ability to support booting from device interoperability system 200 via a direct wireless connection. Then it is necessary to use an intermediary. For example, in one embodiment, the device interoperability system 200 is coupled wirelessly to a miniature USB dongle plugged into a USB port on user device 101-1. Then the miniature USB dongle will simulate a USB flash drive connected to user device 101-1. Then when user device 101-1 is switched on, the direct wireless connection is established between the miniature USB dongle and device interoperability system 200. Then OS 214 is booted on the user device 101-1 from the storage 212 as though it is an ordinary USB flash drive connected to the USB port. In one embodiment, the user must change the BIOS or UEFI settings for user device 101-1 so that user device 101-1 will boot from the device interoperability system 200.
In another embodiment, the direct connection is a direct wired connection. In a further embodiment, the at least one direct wired connection includes, for example, a USB connection. In further embodiments, the direct wired connection is a connection facilitated via docking. In yet another embodiment, at least one of the connections 201-1 to 201-N are direct wireless and at least one of the connections 201-1 to 201-N are direct wired.
When connection 201-1 between user device 101-1 and device interoperability system 200 is facilitated via docking, further embodiments are also possible. In one embodiment, both the device where device interoperability system 200 is installed, and user device 101-1 have direct docking capabilities including, for example, docking ports. Then, device interoperability system 200 interacts with the user device 101-1 via these direct docking capabilities. In yet another embodiment, the device where device interoperability system 200 is installed is coupled to a docking station which is connected to user device 101-1. In a further embodiment, when the docking station is connected to user device 101-1 by, for example, USB cable, the user device 101-1 will recognize the docking station with the device where device interoperability system 200 is installed as a connected external USB drive. In one embodiment, the user must change the BIOS or UEFI settings for user device 101-1 so that user device 101-1 will boot from the USB connected device. In a further embodiment, the docking station provides charging for the device where device interoperability system 200 is installed.
While the above describes situations where connections 201-1 to 201-N are direct connections between two devices, one of skill in the art would know that it is possible to use indirect connections as well. In another embodiment, at least one of the connections 201-1 to 201-N are indirect connections. These indirect connections include, for example, one or more of:
In a further embodiment, when at least two of the described above types of connection are available, the choice between connection types is performed automatically for at least one of the connections 201-1 to 201-N. In one embodiment, the choice is based on the following factors:
In a further embodiment, when the connectivity is lost, either a different type of direct or indirect connection is automatically selected.
In a further embodiment, the at least one connection is secured. The securing is performed by, for example:
In embodiments where the at least one connection is secured, before establishing the connection authentication is performed at the end points, that is, between device interoperability system 200 and user device 101-1.
Device interoperability system 200 can be implemented in a variety of ways. In one embodiment, device interoperability system 200 is implemented using a separate gadget, such as gadget 210 as shown in
In another embodiment, device interoperability system 200 is installed via integration into one of user devices 101-1 to 101-N. For example, as shown in
In a further embodiment, some hardware components of the user device 101-1 with integrated device interoperability system 200 are recognised and used by the OS 214 as connected external devices, when OS 214 runs on a different device which is connected to user device 101-1. For example, in the case where user device 101-1 is a mobile device: When OS 214 runs on user device 101-2 which is connected to user device 101-1, the hardware components of user device 101-1 such as the microphone, sensors, mobile telecommunications module and display are used by OS 214 as external devices.
In yet another embodiment, device interoperability system 200 is implemented as an installed application or an “app” which runs on one of user devices 101-1 to 101-N, for example user device 101-1. For example, as shown in
This image is used on its own or in conjunction with user device 101-1 OS's components stored on storage of user device 101-1 to boot the OS on user device 101-2. Similar to the cases described above, in a further embodiment, some hardware components of the user device 101-1 are recognised and used by the OS 214 as connected external devices, when OS 214 runs on a different device which is connected to user device 101-1.
In some of the embodiments where device interoperability system 200 is installed via integration into user device 101-1 or as an app on user device 101-1, as part of communications module 213, an external wireless adapter is added to user device 101-1 to provide additional communications capabilities not available on user device 101-1, so as to improve performance and/or energy efficiency. This external wireless adapter works with, for example, an integrated controller which is already present on user device 101-1. Then, the communications module 213 comprises the integrated controller and the external wireless adapter of user device 101-1. For example, a USB wireless adapter based on WiGig or Li-Fi communication technology is plugged into a USB port of user device 101-1. This plugged in wireless adapter will interact with an integrated USB controller already present on user device 101-1. Then, the communications module 213 comprises this integrated USB controller and plugged in USB wireless adapter. These added components provide additional communication technology which is not initially available on user device 101-1 to improve performance and/or energy efficiency.
An example of the operation of device interoperability system 200 will be detailed below with reference to a user device, specifically user device 101-1. The descriptions below are applicable to a variety of situations including, for example:
Additionally, there is a need to determine if user device 101-1 will operate in either “stand-alone” or “device interoperability system” mode. In stand-alone mode, the user device 101-1 runs its native OS. In interoperability system mode, the user device 101-1 is connected to device interoperability system 200 and runs OS 214. In a further embodiment, the user device 101-1 is switchable between stand-alone and interoperability system modes.
An example algorithm for switching between stand-alone and interoperability system modes comprising:
In
If the user accepts the option of setting up for interoperability system mode within a predetermined period in step 303, then in step 304 the user performs authentication. In one embodiment, in step 304 the user enters a unique string, password or passphrase specific to the device interoperability system 200. In another embodiment, in step 304 the user enters a login name and a password specific to the OS 214. In yet another embodiment, the user uses login details from another social media site, or web mail site, for example, Facebook®, LinkedIn®, Twitter®, Google®, Gmail®, or others. Additional steps are also possible for authentication. In another embodiment, the user is additionally asked to recognise a combination of letters, numbers and symbols in an image and enter the combination into a box. An example of such a test is the Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) test. In another embodiment, the user is asked a security question, to which the user only knows the answer. In yet another embodiment, the user may be asked additional personal information, such as date of birth and home address. In another embodiment, the user is asked to take a picture of himself or herself and the device interoperability system 200 will match the image to a pre-stored image. In yet another embodiment other biometric measures such as fingerprints scanning are used. The authentication data is used as a pre-shared key and authentication/encryption keys for encrypted connection are built.
In step 306, the user device saves the authentication/encryption keys and connection parameters for future use.
In step 307, connection 201-1 is established.
In step 308, OS 214 boots on user device 101-1.
In step 309, the user device 101-1 works in device interoperability system mode.
If the user does not accept the option of setting up for interoperability system mode in step 303, then in step 305, user device 101-1 determines if it is already set up for interoperability system mode. If in step 305 the user device 101-1 is already set up, then in step 310 the user device tries to establish a connection with device interoperability system 200 using the stored authentication keys and parameters.
Following on from step 310, if the connection establishment is successful in step 311 then the OS 214 boots on user device 101-1 (step 308), and the user device 101-1 works in device interoperability system mode (step 309).
If the connection is unsuccessful in step 311, then user device 101-1 loads its own OS in step 312. In step 313, the user device 101-1 works in stand-alone mode.
If in step 305 the user device is not already set up, then the user device 101-1 loads its own OS (step 312) and works in stand-alone mode (step 313).
In one embodiment, in order to improve speed of operation and to reduce the amount of data transmitted through a connection such as connection 201-1, the swap file or swap partition of OS 214 is placed on the storage of the user device 101-1.
In one embodiment, in order to improve speed of operation, caching is performed by, for example, setting aside a portion of the storage of the connected user device for a cache. In one embodiment, when OS 214 is booted, it will determine if there is a cache on the connected user device. Caching operations will be discussed in detail further below.
In one embodiment, at least some portion of the local storage of a user device connected to device interoperability system 200 is used by OS 214 to store data intended for use only on this particular device. An example is where user device 101-1 is a desktop used by user 100 specifically for running high resource demand applications such as video games. Then, some of the data necessary for running the high resource demand application is stored on the local storage of user device 101-1 instead of storage 212. In a further embodiment, the portion of the user device 101-1 storage which is to be used is recognized by OS 214 as a connected additional drive and presented accordingly.
In one embodiment, a portion of the local storage space of a user device connected to device interoperability system 200 is used by OS 214 to perform a backup of at least some of the data stored in storage 212. The amount of data which is backed up depends on the available capacity of the local storage of the user device. In a further embodiment, the backup is performed using a plurality of user devices. That is, data is backed up from storage 212 to a portion of each local storage space corresponding to each of the plurality of user devices.
In yet another embodiment, a backup status is associated with each portion of data stored in storage 212. Then when a backup operation is performed on that particular portion of data, the backup status is updated.
In a further embodiment, at least some of the data which is stored on the storage of user device 101-1 for either caching, swapping, expanding storage, backups or any combination of these purposes is placed in one or more partitions set up on the storage of user device 101-1. In another embodiment, the data which is stored on the storage of user device 101-1 for either caching, expanding storage, backups or any combination of these purposes is placed in one or more file-containers created in an existing partition of user device 101-1. This eliminates the need for repartitioning or erasing any data from the storage of user device 101-1.
In a further embodiment, the data which is stored on the storage of user device 101-1 for either caching, swapping, expanding storage, backups or any combination of these purposes is encrypted. The decryption keys are stored and managed by OS 214 thus preventing unauthorized access to the data.
In one embodiment, the OS 214 is able to switch between different hardware configurations during booting, such as in step 308 of
When the OS 214 is booted on a user device such as user device 101-1, then in step 3B-01 OS 214 identifies the user device. In step 3B-02, OS 214 determines whether it has stored the configuration set corresponding to the identified user device in storage 212. If yes, then in step 3B-03 OS 214 uses the correct set of drivers and settings for the identified user device. The user device then works in device interoperability system mode in step 3B-07.
If in step 3B-02 OS 214 is unable to find the configuration set corresponding to the identified user device in storage 212, then in step 3B-04 OS 214 will detect all hardware on this user device and install needed drivers automatically.
In step 3B-05, OS 214 prompts the user to enter one or more answers to one or more questions to determine how the user device storage will be used for the functioning of OS 214. Example questions include:
In step 3B-06, OS 214 will save the configuration set and reboot if necessary, before proceeding to work in device interoperability system mode in step 3B-07.
As mentioned previously, example embodiments of caching operations are discussed in detail below with reference to
In step 401, the request type is determined by OS 214.
If the request is determined to be for a read operation, then in step 403 the OS 214 determines if the cache contains the requested data. In one embodiment, OS 214 accesses the cache service database to determine if the cache set up on user device 101-1 contains the requested data. The cache service database describes modification times of the versions of the files stored in at least one of the caches of the user devices 101-1 to 101-N, and modification times of the original versions of those files stored in the storage 212. Determination if the cache contains the requested data is performed by comparison of those modification times. The cache service database is stored in storage 212.
Table 1 shows an example of a cache service database:
In Table 1, column 1C-01 represents the files. Each file corresponds to a separate row of Table 1. With reference to Table 1, file 1 is assigned to row 1R-01, file 2 is assigned to row 1R-02 and so on.
Column 1C-02 of Table 1 represents the modification times of the original versions of those files stored in the storage 212 and in at least one of the caches on the user devices 101-1 to 101-N. Then, referring to Table 1:
Columns 1C-03 and 1C-04 represent the modification times of the versions of the file in the respective caches. For example, column 1C-03 corresponds to the cache 1 stored on user device 101-1, 1C-04 corresponds to cache 2 stored on user device 101-2, and so on. Then:
There are a variety of formats which can be used to represent the times in the cache service database. One example format is a two-digit representation of day/month/year followed by hour:minute:second or “dd/mm/yy HH:MM:SS”.
There is a variety of other information which can be also included in the cache service database. For example, the cache service database can also include file sizes and checksums for data integrity checks.
In another embodiment the cache service database is based on file checksums instead of file modification times. Then, the cache service database describes checksums of the versions of the files stored in at least one of the caches of the user devices 101-1 to 101-N, and checksums of the original versions of those files stored in the storage 212. Determination if the cache contains the requested data is performed by comparison of those checksums.
If the data cannot be found on the cache in step 404, or the data on the cache has a modification time which is different from the modification time of the corresponding data on storage 212 (step 405), or the checksums are different; then OS 214 retrieves the data from storage 212 (step 406). In step 408, the retrieved data is then written into the cache, so that subsequent data read operations are performed using the cache. This also has the advantage of reducing the power consumption of the device where device interoperability system 200 is installed, as data does not have to be transmitted from this device to user device 101-1 via connection 201-1. In step 409, the cache service database is also updated.
If, in step 404 the data is found on the cache, and the data on the cache matches the corresponding data on storage 212 (step 405); then in step 407 the data is read from the cache.
In a further embodiment, if the request type is determined to be a write operation in step 401, then in step 402 OS 214 performs a data write operation. In one embodiment, this data write operation is performed in write-through mode. Then, following from the OS 214 writing the data to storage 212 via connection 201-1 in step 402, OS 214 also writes data to the user device 101-1 cache in step 408. In step 409, the cache service database is also updated.
In another embodiment, one or more additional checks are performed to determine whether the data should be written to the cache.
If the data is determined to be suitable for caching in step 4B-08, then in step 4B-10 the data is written to the cache and in step 4B-11 the cache service database is updated.
In one embodiment, the OS 214 performs additional cache servicing functions, for example:
Then, the above described factors used in step 4B-08 are used to optimize the performance of these additional cache servicing functions as well.
In a further embodiment, if the data is determined to not be suitable for caching in step 4B-08, then in step 4B-09 an additional check to determine the necessity of updating of the cache service database is performed. For example, if the data is determined not to reside in any cache of any user device, then it is unnecessary to update the cache service database.
In one embodiment, when user device 101-1 runs OS 214, data is prefetched from storage 212 and used to update the user device 101-1 cache. That is, data is fetched from storage 212 and transmitted to the user device 101-1 cache in readiness for future use.
If the data stored in the connected cache is determined not to match the data stored in storage 212 in step 4C-02, then in step 4C-03 the OS 214 determines which of the one or more portions of data stored in storage 212 are different compared to the data on the user device 101-1 cache.
In a further embodiment, in step 4C-04, OS 214 selectively prefetches one or more portions of data stored in storage 212 which are different from the data stored in the cache of user device 101-1.
The selection and prioritization of data depends on several factors:
Then in step 4C-05, the cache service database is updated accordingly based on the data stored in the user device 101-1 cache.
In one embodiment, security measures are used so as to reduce the risk of a malicious party gaining access to device interoperability system 200. For example, in one embodiment access to device interoperability system 200 is secured using biometric measures such as fingerprints scanning or facial recognition.
In other embodiments, multi-factor authentication is used to secure device interoperability system 200. In some embodiments, a multi-factor authentication process is based on the following factors, or answering the following questions:
In one embodiment, the OS 214 is able to pause its operation if the connection 201-1 is lost, and resume operation immediately when the connection is reestablished.
In one embodiment, OS 214 includes one or more kernels corresponding to one or more architectures. For example, OS 214 includes kernels for the x86 and ARM architectures. Then depending on the architecture of the connected user device, the appropriate kernel is used automatically. This behavior is completely transparent for the user.
In one embodiment, a graphical user interface (GUI) is generated on user device 101-1 to enable the user to interact and interface with user device 101-1 including OS 214. In one embodiment, the OS 214 automatically optimizes and adapts the GUI according to the following factors:
Examples of GUI optimizations and adaptations include:
In one embodiment, OS 214 is only able to work on one connected user device at a time. An example is when OS 214 is running on user device 101-1. Then, to work on a different user device such as user device 101-2 after establishing connection 201-2, in one embodiment OS 214 must be shut down on user device 101-1, then booted on user device 101-2. In another embodiment, OS 214 operation on user device 101-1 is first paused. Then OS 214 is either booted or, if it was previously paused, resumed on user device 101-2.
In another embodiment, OS 214 is able to work with a plurality of user devices such as, for example, user devices 101-1, 101-2 and 101-3. In order to enable this, in an embodiment communications module 213 is able to establish and simultaneously maintain connections 201-1, 201-2 and 201-3 with user devices 101-1, 101-2 and 101-3 respectively. Then, user devices 101-1, 101-2 and 101-3 are simultaneously connected to the device interoperability system 200 and each one of these user devices runs its instance of OS 214 in parallel with each other. In one embodiment, the transmission capacity of communications module 213 is balanced between connections 201-1, 201-2 and 201-3 according to the current utilization of each connection.
In a further embodiment, different instances of OS 214 which are simultaneously running on user devices 101-1, 101-2 and 101-3 use the distributed lock management approach to coordinate concurrent access to the storage 212. For example, the lock managers of all three instances of OS 214 which are running on the user devices 101-1, 101-2 and 101-3, use the same lock database which is distributed among these instances by means of device interoperability system 200 and connections 201-1, 201-2 and 201-3.
In one embodiment, the interoperability system 200 is used by the different instances of OS 214 which are simultaneously running on different user devices to exchange some details about their current status. This, for example, includes:
This data is used by every running instance of OS 214 to coordinate and optimize its service functions. For example, when three instances of OS 214 are running on user devices 101-1, 101-2 and 101-3, coordination is performed to ensure that the OS update process is not running simultaneously on all three devices. In a further embodiment, this data is used to prioritize the balancing of the transmission capacity of communications module 213 between established connections 201-1 to 201-3. For example, a higher priority is given to that user device which user 100 currently uses.
In yet another embodiment, the OS 214 supports migration of running applications between OS instances running on different user devices. With reference to the example above, OS 214 supports the ability to move a currently running application from user device 101-2 to user device 101-3. After the migration, the application continues to have access to any previously opened files. In a further embodiment, the data described previously is used to present more details to a user if the user opts to migrate applications and the connections 201-2 and 201-3 are used to facilitate the migration process.
The use of device interoperability system 200 offers several other advantages. In some embodiments, device interoperability system 200 is used in conjunction with cloud-based data synchronization capabilities. For example, if cloud-based services are used for synchronization of data between different user devices, device interoperability system 200 reduces the necessity for user devices to connect to the cloud to perform data synchronization. Instead, the user devices use data from storage 212. This reduces the utilization of the cloud connection with the user devices. Furthermore, in some embodiments, the device interoperability system 200 ensures data availability in case cloud connectivity is lost or not available, as the user devices can retrieve data from storage 212. In some embodiments, intelligent approaches to ensuring availability of data which is most likely to be relevant to a user are employed. These include, for example, approaches based on:
In some embodiments, some user data is stored on storage 212 but not within the cloud. This capability is useful if, for example, users want to keep control of sensitive data such as private keys for blockchain-enabled mobile services. This feature enables users to keep control of their sensitive data without exposure to potential security breaches in the cloud.
The security of this feature is enhanced by the addition of device interoperability system 200. In particular, this enhancement is achieved by running device interoperability system 200 on a device or gadget where storage 212 has these secure storage capabilities, and allowing only user devices that are connected to device interoperability system 200 and have been booted up using OS 214 to access the data stored within storage 212. As will be seen below, this enables the creation of a more secure and private ecosystem.
For example: In the case where private keys for blockchain-enabled mobile services are stored on storage 212, only user devices that are connected to device interoperability system 200 and have been booted up using OS 214 are able to access these private keys. This is useful, for example, to ensure that the user is able to securely perform cryptocurrency transactions.
Sensitive data can be further secured through other means. For example, in some embodiments, as explained previously, the sensitive user data is encrypted prior to being stored in storage 212. In some of these embodiments, the user selects the type of encryption to be used.
In other embodiments, sensitive user data is not accessible directly to user devices that have been connected to device interoperability system 200 and have been booted up using OS 214. Instead, only the results of processing or operations performed by, for example, one or more programmes which are part of programmes and data 216 residing on storage 212 and which uses the sensitive data, are made available to the user devices. For example, if the user using user device 101-3 wants to perform cryptocurrency transactions and needs to access private keys to sign transactions, then the transactions which require signing are transmitted from the user device 101-3 over connection 201-3 to the device interoperability system 200. At device interoperability system 200, the transactions are signed using one or more programmes resident on storage 212. The signed transactions are then transmitted back over connection 201-3 to the user device 101-3. This way, user device 101-3 does not access the sensitive user data at all.
In some embodiments, the availability of the sensitive user data or the results of processing or operations which use the sensitive data is based on a security level associated with the user device. This is illustrated with reference to user device 101-3. For example, in some embodiments, the user device 101-3 is considered to have a low security level if it is publicly accessible. If user device 101-3 is only privately accessible and access is secured using, for example, two authentication factors as described previously, it is considered to have a very high security level.
In some embodiments, storage 212 comprises several storage sub-areas, wherein each sub-area has a different associated security level. An example embodiment is shown in
The Samsung Galaxy S10 is an example of this, as it has a secure storage sub-area to store private keys for blockchain-enabled mobile services and a less secure storage sub-area. This can also be used to differentiate the level of access of a user device to data. For example:
The implementation of sub-areas within storage 212 into sub-areas can be carried out in a variety of ways. In some embodiments, the implementation is performed physically, that is, each sub-area corresponds to a different physical storage area. In some embodiments, the implementation is performed virtually, that is, a physical storage area is partitioned into different sub-areas. In yet other embodiments, a combination of virtual and physical implementations is used.
In some embodiments, the above concepts are combined to create a hierarchical or differentiated system of secure storage for a user's data. This hierarchy has a plurality of levels, wherein each level of the hierarchy corresponds to a different level of data sensitivity and therefore required security.
Then the accessibility to the data is based on the security level which has been assigned to the data. An example of this is demonstrated below with reference to
User data can be assigned to one of sensitivity levels 601-604 using different techniques. In some embodiments, assignment is based on user inputs on a user interface presented to the user at a user device. The user interface is, for example, a GUI. An example embodiment is as follows: A user assigns data to one of the levels by selecting a sensitivity setting of Very High, High, Medium, Low corresponding to levels 601-604. Then, based on this setting, one of the security levels described above is assigned to the data.
In other embodiments, user data is assigned to one of levels 601-604 based on the type of data. For example, sensitivity level 601 may be assigned to data related to an ultra-secure cryptocurrency “cold wallet” such as cryptocurrency, public and private keys as well as signing private keys for cryptocurrency transactions. Sensitivity level 602 may be assigned to user Personal Identification Numbers (PINs) and passwords for financial applications. Sensitivity level 603 is assigned to user media files that the user has indicated are sensitive. Finally, sensitivity level 604 is assigned to other user data which the user has allowed many cloud-based applications to use.
The above shows an embodiment where one level of security is assigned based on the sensitivity level of the data. In some embodiments, more than one level of security to be assigned based on the sensitivity level of the data. In some of these embodiments, based on the sensitivity level of the data, a minimum level of security is assigned. Then, any level of security either at or above that minimum level can be assigned to the data. For example, the minimum level for data with sensitivity level 602 is set to security level 612. Therefore, security levels 611 and 612 can be assigned to the data. Similarly, the minimum level for data with sensitivity level 603 is set to security level 613. Then security levels 611, 612 and 613 can be assigned to that data.
The above embodiments enable the creation of a secure, private ecosystem where sensitive data is stored within storage 212 of device interoperability system 200, and only devices which connect to device interoperability system 200 and are booted by OS 214 can access this data. Furthermore, the above details embodiments for a hierarchical or differentiated system of secure storage.
The use of device interoperability system 200 also offers advantages for IoT-enabled user devices. Similar to as with cloud-based services, device interoperability system 200 reduces the need to connect to the cloud to perform data synchronization. Furthermore it reduces the difficulty of having to maintain separate cloud credentials and device settings for user devices.
The hierarchical or differentiated system of secure storage mentioned above is of particular importance for IoT-enabled devices, as many of these devices are publicly accessible and may be difficult to monitor, thereby reducing the level of security associated with these devices. By using a hierarchical or differentiated system of secure storage, such devices can be used as part of a secure and private ecosystem without jeopardizing the overall level of security and privacy of the ecosystem.
It is also possible to perform data restore in the event of damage or loss of the device where device interoperability system 200 is installed. As previously described, in some embodiments OS 214 backs up data from storage 212 to a portion of each local storage space corresponding to each of the user devices connected to device interoperability system 200. Embodiments to perform caching were also previously described above. Then, in some embodiments, OS 214 uses the data stored in the one or more caches corresponding to the user devices connected to device interoperability system 200, in conjunction with the data backed up on a portion of the local storage space of the user devices connected to device interoperability system 200, to perform a data restore.
Once step 704 is completed, in step 705 OS 214 determines if any data from the backup stored on the user device is missing from storage 212. If yes, then in step 706 OS 214 determines the data which is missing from storage 212. Once step 706 is completed, then data is restored from the backup on the user device to storage 212 in step 707.
If in step 705 OS 214 determines that there is no data from the backup on the user device missing from storage 212, then in step 715 of
In step 708, OS 214 determines if there is a cache available on the user device storage. If there is no cache available, then OS 214 progresses to step 713 which will be explained further below. If there is a cache available, then in step 709 OS 214 compares data from the cache with the data stored in storage 212 to see if there is data present in the cache which is missing from storage 212. In one embodiment, the cache service database which is stored on the user device is used to determine if there is data present on the cache which is missing from storage 212 in step 709. If OS 214 determines in step 710 that there is data missing, then in step 711, OS 214 determines which portions of data are missing on storage 212. Once step 711 is completed, then in step 712 OS 214 restores the missing portions of data from the cache to storage 212. OS 214 then progresses to step 713.
If OS 214 determines in step 710 that there is no data missing, then in step 718 of
In step 713 of
Variations on the above are also possible. For example, in some embodiments, only data stored in the cache is used by OS 214 for data restore. An exemplary embodiment is illustrated with reference to
If there is no cache available, then OS 214 progresses to step 813 which is similar to step 713. If there is a cache available, then in step 809 (similar to step 709) OS 214 compares data from the cache with the data stored in storage 212 to see if there is data present in the cache which is missing from storage 212. In one embodiment, the cache service database which is stored on the user device is used to determine if there is data present on the cache which is missing from storage 212 in step 809. If OS 214 determines in step 810 (similar to step 710) that there is data missing, then in step 811 (similar to step 711), OS 214 determines which portions of data are missing on storage 212. Once step 811 is completed, then in step 812 (similar to step 712) OS 214 restores the missing portions of data from the cache to storage 212. OS 214 then progresses to step 813.
If OS 214 determines in step 810 that there is no data missing, then in step 818 (similar to step 718 of
In step 813 of
As previously explained and as shown in step 4C-04 of
In one embodiment, when a portion of the data is about to be deleted from the cache, an additional check of its backup status is performed by OS 214. For example, if there are no more copies of particular portion of the data stored on other user devices or at other backup locations then this portion of data will not be deleted from the cache.
As explained above, the OS 214 supports migration of running applications between OS instances running on different user devices. In some embodiments, migration is performed using a “push”-based technique, that is, where migration is initiated at a source user device, and an application is then pushed from the source device to a destination user device. In further embodiments, a GUI is generated on a source user device to allow the user to select an application for migration, and the destination user device to which the application will be migrated to. An exemplary illustration is shown in
In some embodiments, migration is performed using a “pull”-based technique, that is, where migration is initiated at the destination user device, and an application is then pulled from a source user device for migration to the destination user device. In further embodiments, a GUI is generated on a destination user device to allow the user to select a source user device where an application will be migrated from, and an application for migration. An exemplary illustration is shown in
A specific application of the above described solution for a system and method of mobile and stationary computing device interworking is now discussed. Such a system and method allows a user to work in mobile and stationary work modes.
Many users have mobile computing devices, such as laptops, and stationary computing devices such as desktops. These users often need to work in both mobile and stationary work modes. In some embodiments, a device interoperability system such as the one described above is implemented on the mobile computing device either via integration or as an app. Then, the mobile computing device plays the role of user device 101-1 as shown in
Once the connection is established, the stationary computing device boots up an OS such as OS 214 from the storage of the device interoperability system, as described above.
In some embodiments, the OS uses the processing capabilities of the stationary computing device to run, as described above. The stationary computing device accesses the storage of the mobile computing device. In some embodiments, as explained above, the stationary computing device recognizes one or more of the hardware components of the mobile computing device such as the microphone, speakers, webcam, keyboard, touchpad, wireless adapter, sensors, and display as connected external devices.
In some embodiments, the stationary computing device operates in either stand-alone or device interoperability system mode, as described above. The stationary computing device operates in a stand-alone mode when a connection is not established between the mobile computing device and the stationary computing device. When a connection is established between the mobile computing device and the stationary computing device, then in some embodiments, the stationary computing device operates in device interoperability system mode. In some embodiments, authentication is performed using a modified version of the algorithm shown in
In some embodiments, the OS switches between different hardware configurations when the stationary computing device boots up. To achieve this, the OS uses, for example, the algorithm detailed in
In some embodiments, the connection between the mobile and stationary computing devices is a high-speed wired connection. In some embodiments, the type of technology which is used for this high-speed wired connection is based on one or more factors. These factors comprise, for example:
In some embodiments, the connection between the mobile and stationary computing devices is a Thunderbolt connection. In other embodiments, the connection is based on USB4.
In some embodiments, the stationary computing device requires an expansion card to facilitate the high speed wired connection. Then, the expansion card is installed on the desktop using one or more techniques known to those of skill in the art. For example, in some embodiments the installation comprises plugging in the expansion card to a free slot in a system board of the stationary computing device, such as a Peripheral Component Interconnect express (PCIe) slot.
In some embodiments, the mobile computing device is charged up when it is connected to the stationary computing device. The power for this charging process is delivered through the connection between the mobile and the stationary computing devices, using techniques known to those of skill in the art.
In some embodiments, the mobile computing device operates in a plurality of modes. In a first of these plurality of modes, the mobile computing device boots up the OS stored on its storage and runs using this OS. The user can then perform all the normal functions as necessary.
In a second of these plurality of modes, the mobile computing device operates in a device interoperability system host mode. In this mode, the mobile computing device does not run the OS. Instead, the stationary computing device boots up the OS via the connection between the mobile and stationary devices and uses it as described above. In further embodiments, in this second mode one or more programmes and data stored on the storage of the device interoperability system are used to translate read and write commands and queries from the stationary computing device, thereby enabling access to the storage of the mobile computing device. Then, when the stationary computing device transmits read and write commands and queries via the connection between the two devices, these translation programmes are used to fulfil these commands and queries.
Different methods are possible to enable these functionalities. In some embodiments, as explained above, the stationary computing device recognizes the storage on the mobile computing device as a connected external drive. This can be achieved in a number of ways. In some embodiments, the mobile computing device storage is simulated as an external drive using the mobile computing device's BIOS/UEFI, and therefore the translation program runs as part of mobile computing device's firmware. In other embodiments, the storage is simulated as an external drive by a second OS installed on the mobile computing device's hard drive, and the translation program runs as an app.
A process for the stationary computing device to boot the OS stored in the mobile computing device when both the mobile computing device and the stationary computing device are turned off, is outlined below and in
In step 11-01, the mobile computing device is turned on.
In step 11-02 a mode of operation is selected for the mobile computing device to switch to. In some embodiments, prior to the selecting, one or more options are presented to the user to select a mode of operation. In some embodiments, the presenting of the one or more options comprises the mobile computing device displaying a GUI on its screen with the one or more options. For example:
In other embodiments, the presenting of the one or more options in step 11-02 comprises the mobile computing device performing a timer-based process. In some of these embodiments, the timer-based process comprises the mobile computing device beginning a countdown timer and displaying a GUI on its screen. The GUI comprises, for example:
In yet other embodiments, the selection of the mode of operation in step 11-02 is based on determining if a connection has been established between the mobile computing device and the stationary computing device. If no connection has been detected, then the mobile computing device goes into the first mode and boots the OS in step 11-03. If the connection to the stationary device is detected, then the mobile computing device automatically switches to the second mode which is the device interoperability system host mode in step 11-04.
After step 11-04 is completed, then in step 11-05 the mobile computing device initiates switching the stationary computing device into interoperability mode. In some embodiments, the initiating comprises performing at least one of the following processes:
In some embodiments the at least one or more processes performed as part of the initiating is based on a determination of the state of the connection between the mobile computing device and the stationary computing device. In some of these embodiments, when no connection is detected, or the state of the connection cannot be determined, the mobile computing device sends one or more indications such as visual, audible or haptic indications to the user to perform one or more of:
An example of this is where the mobile computing device displays a message such as “Please make sure that the desktop is connected and turn it on to continue”.
In some embodiments the at least one or more processes performed as part of the initiating is based on the mobile computing device determining the power state of the stationary computing device. For example, in some of these embodiments, based on this determination:
In step 11-06 the stationary computing device boots into the interoperability system mode, that is, it boots the OS stored on the storage of the mobile computing device.
In some embodiments the mobile computing device:
In step 12-01 the user turns on the stationary computing device. In some embodiments this is done by pressing a power-on button.
Then in step 12-02 the mobile computing device detects that the stationary computing device has been turned on, via, for example, one or more signals sent through the connection between the mobile and stationary computer devices. Then the mobile computer device enters the second or device interoperability system host mode. In some embodiments this comprises switching from one of the sleep states such as states S1, S2, S3 or S4 to the working state S0 as explained previously. In other embodiments this comprises switching from the soft off state S5 to another state, for example the working state S0 as explained previously.
In step 12-03, the stationary computing device continues the process of booting into the device interoperability system mode, that is, it boots the OS stored on the storage of the mobile computing device.
After a user wants to end a working session during which the mobile computing device is in device interoperability system host mode, and the stationary computing device is in interoperability mode, the user may want to follow different courses of action for the mobile computing device and the stationary computing device. Examples of these courses of action include:
An example process to enable a user to perform actions after the end of a working session is shown in
In step 13-02, after the user selects one of these options, the stationary computing device sends one or more signals to the mobile computing device to perform one of:
For the embodiments where the mobile computing device either switches to the first mode or turns off in step 13-02, then in steps 13-03 and 13-04, the mobile computing device either restarts and boots the OS or shuts down. When the stationary computing device sends the one or more signals to the mobile computing device to stay in the second mode, then in steps 13-03 and 13-05 the mobile computing device remains in the second mode.
In some embodiments the mobile computing device monitors whether the stationary computing device is turned off. Various methods are possible to achieve this. In some embodiments, the BIOS/UEFI of the mobile computing device monitors whether the stationary computing device is turned off. In other embodiments, the second OS on the mobile computing device monitors whether the stationary computing device is turned off. In some of the embodiments where the second OS monitors whether the stationary computing device is turned off, this functionality is performed by an app. Once the mobile computing device has determined that the stationary computing device is turned off, then the mobile computing device performs a process to either shut down or switch into the first mode as previously described. In some embodiments, the process comprises the mobile computing device displaying a GUI on its screen presenting one or more options to, for example:
In some embodiments, the mobile computing device performs a timer-based process. An example is illustrated in
In steps 14-02 and 14-03, while the user has not made a selection and the timer is running, the mobile computing device monitors the state of the stationary computing device. If the stationary computing device is restarted into the interoperability system mode in step 14-04, then in step 14-05 the GUI disappears and the mobile computing device continues to work in the second mode.
In steps 14-02 and 14-03, if the user has not made a selection and the timer expires, the mobile computing device is automatically switched off in step 14-06.
If in step 14-02 the user selects the option to switch to the first mode, then in some embodiments, in step 14-07 the mobile computing device switches to the first mode.
In some embodiments, in the interoperability system mode the OS disables and hides from its GUI the option to switch to power states which may be incompatible or unsupported by the interoperability system mode. For example, an option to enter the “Sleep” state is disabled to avoid issues caused by disconnecting the laptop, which contains the system drive, from the desktop.
In some embodiments, when the mobile computing device switches from the first mode to the second mode or vice versa, a process of saving the working session is performed. This process is performed by, for example, either the OS or a service app running on the OS.
In some embodiments, the process of saving the working session comprises saving information related to one or more of the following:
In some embodiments, a functionality to restore the saved working session is provided. In some of these embodiments, the user is asked whether the user wants to restore the saved working session after the OS is restarted. If the user accepts, the saved working session is restored.
During a working session in the interoperability mode, a user may either accidentally or intentionally disconnect the mobile computing device from the stationary computing device. This disconnection can lead to problems such as a system crash, data corruption or loss, and may require OS recovery.
This problem may be addressed in several ways. In some embodiments, one or more indicators are used to indicate when it is safe to disconnect the mobile computing device from the stationary computing device. In some embodiments, an indicator such as a visual, audible or haptic indicator is provided to the user to show that it is safe to disconnect the mobile computing device from the stationary computing device. Examples of such indicators comprise:
In other embodiments, a physical lock is used to lock the port and prevent disconnection. This physical lock is, for example, an electro-mechanical lock. Then, the physical lock automatically locks the connector in the port on the mobile computing device when the user starts to work in the interoperability mode. So the user is prevented from disconnecting the mobile computing device from the stationary computing device without physically breaking the lock. In some embodiments, the physical lock comprises an electromechanically controlled mechanism with a “muscle wire” similar to the one described in U.S. Pat. No. 6,461,185 titled “Method and apparatus for an electromechanically controlled electronic interface plug” to James et al, filed Apr. 20, 2001 and issued on Oct. 8, 2002.
In some embodiments, when the connection between the mobile computing device and the stationary computing device is lost, the OS is paused, and resumed when the connection is reestablished. This mitigates the undesired effects of accidental disconnection, such as crashes and data loss. In some embodiments, pausing and resuming when the connection is lost and reestablished is implemented similar to that explained in “What happens if I remove my Windows To Go drive while it is running?”, located at https://docs.microsoft.com/en-us/windows/deployment/planning/windows-to-go-frequently-asked-questions #what-happens-if-i-remove-my-windows-to-go-drive-while-it-is-running-, retrieved on Jun. 7, 2021. That is:
In some embodiments, a direct wireless connection between the mobile computing device and the stationary computing device is set up as a secondary connection, in case the user physically disconnects the mobile computing device from the stationary computing device without shutting down the OS on the stationary computing device. The backup direct wireless connection is set up via, for example, a wireless adapter on the stationary computing device and direct wireless transmission and reception capabilities on the mobile computing device. In some embodiments, an external USB-based Wi-Fi dongle on the stationary mobile computing device is used to set up the direct wireless connection. In yet other embodiments, the installed extension card is used to set up the direct wireless connection through, for example, a Wi-Fi module. In some embodiments, the OS is paused when the main connection is interrupted and resumed after the reserved connection is established, using the pause-and-resume functionality described above. In other embodiments this is enabled via an indirect connection, for example, through a Wi-Fi router.
Although the algorithms described above including those with reference to the foregoing flow charts have been described separately, it should be understood that any two or more of the algorithms disclosed herein can be combined in any combination. Any of the methods, algorithms, implementations, or procedures described herein can include machine-readable instructions for execution by: (a) a processor, (b) a controller, and/or (c) any other suitable processing device. Any algorithm, software, or method disclosed herein can be embodied in software stored on a non-transitory tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or other memory devices, but persons of ordinary skill in the art will readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.). Also, some or all of the machine-readable instructions represented in any flowchart depicted herein can be implemented manually as opposed to automatically by a controller, processor, or similar computing device or machine. Further, although specific algorithms are described with reference to flowcharts depicted herein, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.
It should be noted that the algorithms illustrated and discussed herein as having various modules which perform particular functions and interact with one another. It should be understood that these modules are merely segregated based on their function for the sake of description and represent computer hardware and/or executable software code which is stored on a computer-readable medium for execution on appropriate computing hardware. The various functions of the different modules and units can be combined or segregated as hardware and/or software stored on a non-transitory computer-readable medium as above as modules in any manner, and can be used separately or in combination.
While particular implementations and applications of the present disclosure have been illustrated and described, it is to be understood that the present disclosure is not limited to the precise construction and compositions disclosed herein and that various modifications, changes, and variations can be apparent from the foregoing descriptions without departing from the spirit and scope of an invention as defined in the appended claims.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2022/055501 | 6/14/2022 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63211169 | Jun 2021 | US |
