METHOD AND SYSTEM OF OPERATING SYSTEM INDEPENDENCE

[0001] This disclosure relates generally to a technical field of cloud computing and, in one example embodiment, to method and system of operating system independence.

[0002] A Software application may be installed on an operating system of a client device. The software application may be installed such that additional files are added to the operating system and/or files of the operating system are modified. As a result, the software application may be tied to the operating system of the client device.

[0003] The software application may need to be modified and/or updated. Each copy of the software application may be on different client devices. Modifying and/or updating the software application may require an administrator to install a patch through each client device and/or through a central server. It may be time consuming to install each application on each client device of the enterprise. The installation of security patch and/or other update through a central server may be time consuming, because the installation may require the time of the administrator to troubleshoot the update and/or software application. Provisioning a client device of a new user and/or restoring the client device of an existing user may be time consuming, because the software application and/or update may need to be installed on the client device. As a result, time and/or other resources of the administrator may be wasted causing a negative impact on business productivity.

[0004] In one aspect, a method of a client device includes accessing a first application through a first application template. The first application template resides on a server device. The method also includes accessing the first application of a user interface of the client device based on a response to a request. In addition, the method also includes processing the first application such that the first application accesses the first application template such that the client device permits an access of the first application through the first application template through a processor.

[0005] The method includes executing the first application through the first application template such that an execution of the first application through the first application template emulates the execution of the first application installed on an operating system of the client device. The method includes executing a function of the first application template based on a demand of a user through the response to the request of the user such that a file is accessed when required of the first application.

[0006] The method further includes accessing a first file of the user and a second file of the user through the first application. The first file is of a type of the first application and the second file is of the type of a second application. In addition, the method includes translating between the first application template and the operating system of the client device based on the type of the operating system such that the first application is accessible to a user of the client device. The method also includes translating between the second application template and the operating system of the client device based on the type of the operating system such that the second application is accessible to the user of the client device.

[0007] The first application template may include one or more of an executable, a library, an image, a configuration file, and a registry key such that the first application through the first application template may be accessible to the client device and another client through the first application template. The first application template of the client device and the first application template of another client device may be the same. The operating system of the client device and another operating system of another client device may be different such that the first application may be accessible to the client device and the another client device through the first application template.

[0008] The method further may include accessing the first application template through a software as a service model through a cloud environment such that the first application may be accessible through the first application template. The user of the client device and another user of another client device may access the first application through the first application template. The first application template of the user and the first application template of another user may be the same.

[0009] Furthermore, the method may include creating the application template through the user interface of an administrator of the client device. The method may also include creating the first application template such that the first application template may be coupled to one of a registry structure and a directory structure such that the first application may be accessible to the user of the client device.

[0010] The method may further include converting a first installation program to the first application template. The first installation program may include a file, a registry key, and a registry value to install the first application to the client device. The method may also include creating the first application template based on a conversion of the first installation program through an installation of the first installation program such that the client device may access the first application through the first application template.

[0011] In addition, the method may include creating the second application template such that the second application template may be coupled to one of the registry structure and the directory structure such that the second application may be accessible to the user of the client device. The first application template and the second application template share the registry structure and the directory structure.

[0012] In addition, the method may include creating a file system comprising a layer. The layer may manage the first file of the user, such that the first file may be accessible through the first application. The method may also include a setting of the user such that a setting may be customizable through a response of the request of the user such that the setting may be accessible to the user when the first application may be accessed.

[0013] The method may further include creating the file system comprising another layer. The another layer may manage another first file of the first application template, such that the another first file may be accessible through the first application, and the first application template may include the another first file. The method may also include creating the file system comprising yet another layer. The yet another layer may manage a host file. The host file may be the file of the operating system of the client device, such that the host file may be accessible through the first application.

[0014] Furthermore, the method may include marking the another first file of the first application template as deleted based on the response to the request of the user through the user interface of the client device such that the another first file may remain a component of the first application template. The method may also include denying the access to another first file of the first application template through the first application based on a deleted marking. The method of client device may be in a form of a machine-readable medium embodying a set of instructions that, when executed by a machine may cause the machine to perform the method accordingly.

[0015] In another aspect, a method of a server device includes permitting an access of a first application through a first application template. The first application template resides on a server. The method may also include permitting the access of a second application through a second application template. The second application template may reside on the server. The method of a server device also includes processing a request based on the request of a user interface of a client device to access one of the first application and the second application through a processor. The first application and the second application may be accessible through the user interface.

[0016] In addition, the method of the server device includes accessing the first application template and/or the second application template based on the request of the user interface of the client device. The method also includes determining a translation file based on a type of an operating system of the client device such that the application may be accessible to a user of the client device.

[0017] The first application template may include one of an executable, a library, an image, a configuration file, and a registry key such that the first application through the first application template may be accessible to the client device and another client through the first application template. The first application template of the client device and the first application template of another client device may be the same.

[0018] The operating system of the client device and another operating system of the another client device may be different such that the first application may be accessible to the client device and the another client device through the first application template. The method may also include permitting the access of a first file of the user and a second file of the user through the first application. The first file may be of the type of the first application and the second file may be of the type of the second application.

[0019] Furthermore, the method may include permitting the access of the first application template through a software as a service model through a cloud environment such that the first application may be accessible through the first application template. The user of the client device and another user of another client device may access the first application through the first application template. The first application template of the user and the first application template of the another user may be the same.

[0020] In addition, the method may include permitting the access of the first application and the second application through a binary module coupled to the first application template and the second application template. The binary module may emulate a set of a function call between the first application and the operating system of the client device and the function call between the second application and the operating system of the client device.

[0021] In yet another aspect, a system includes a server to permit an access of a first application based on a response to a request of a user interface. The system also includes a client device to process the first application through a processor such that the first application is accessible to a user based on the response to the request of the user interface. In addition, the system includes a first application template to emulate a function of the first application.

[0022] The first application template includes one of an executable, a library, an image, a configuration file, and a registry key such that the access of the first application through the first application template is accessible to the client device and another client device through the first application template. The first application template of the client device and the first application template of the another client device are the same.

[0023] The system may further include a file system to organize a file such that the file of a second application template may be accessible to the user of the client device through the first application. The first application and a second application may be accessible to the user of the client device. The second application template may include the file of the second application.

[0024] In addition, the system may also include a translation module to permit the access of the first application through an operating system of the client device such that the first application may be accessible to another operating system of the another client device. The operating system of the client device and another operating system of the another client device may be different.

[0025] The methods, systems, and apparatuses disclosed herein may be implemented in any means for achieving various aspects, and may be executed in a form of a machine-readable medium embodying a set of instructions that, when executed by a machine, causes the machine to perform any of the operations disclosed herein. Other features will be apparent from the accompanying drawings and from the detailed description that follows.

[0039] Other features of the present embodiments will be apparent from the accompanying drawings and from the detailed description that follows.

[0040] A method, apparatus, and/or system of operating system independent cloud computing are disclosed. Although the present embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments.

[0041] FIG. 1 illustrates a system 100 of operating system independence, according to one or more embodiments. In one or more embodiments, the system 100 includes a client device 102 in communication with a server device 104 through a network 106. Examples of the network 106 include, but are not limited to a local area network, a wide area network, a wireless network, a wired network, a mobile communication network, a Zigbee, and the like. The client device 102 processes, through a processor, an application 108 such that the application 108 is accessible to a user 110 of the client device 102 based on a response to a request of a user interface. Example of the client device 102 includes, but is not limited to laptop, a desktop, a mobile computing device, a personal digital assistant, and a similar data processing device. The server device 104 may be configured to permit an access of the application 108 based on the response to the request of the user interface.

[0042] The server device 104 may include an application template 112 to emulate a function of the application 108. In one or more embodiments, a virtual container may be created for the client device 102 to virtualize the client device 102. The virtual container may be operatively coupled with the server device 104 and the client device 102. In one or more embodiments, the virtual container may be created through inheritance. Inheritance may include copying of folder structures of the client device 102 to a new location on the server device 104. The folder structure may be used to create a base template and information associated with the base template may be saved in a storage (e.g., a relational database) on the server device 104.

[0043] The application template 112 may include, but is not limited to an executable, a library, an image, a configuration file, and a registry key. The access to the application 108 may be allowed through the application template 112. In one or more embodiments, multiple client devices may be allowed to access one or more applications through one or more application templates in the server device 104. The client devices 102 may be allowed to use a common application template to access the applications through the common application template. The application 108 may include one or more components including a set of DLLs, a set of configuration files, and a set of executable files. The system 100 disclosed herein virtualizes one or more resources including the components and operating system 114 resources to access the application 108 through the client device 102 and provides the virtualized resources on demand to the user 110 of the client device 102.

[0044] In one or more embodiments, a virtual container may run multiple versions of the application 108. The virtual container may run different applications through different application templates. For instance, consider that the administrator of the client device 102 tries to install a gaming application into the client device 102. The files, registry and data associated with the installation and execution of the gaming application may be transferred to an application template created by an administrator, for the gaming application on the server device 104. When the administrator initiates the installation, the gaming application may get installed in the server device 104 and whenever the user tries to execute the gaming application, the gaming application may run in the virtual container using a host operating system associated with the application template on the server device. The user 110 accesses the gaming application running in the virtual container through the client device 102. Similarly, for example, a Windows Powerpoint application can be run on Linux operating system through the virtual container.

[0045] When a user logs on, he may access to the virtual desktop assigned by the administrator to the user. When the user installs an application, the application may be installed on the virtual desktop of the user. Access to the virtual desktop of the user may be limited to the user.

[0046] When an administrator logs on, the administrator may install into an application template and/or a user virtual desktop. When the administrator installs an application into a template, the application may be automatically available to all users connected to the application template. When the administrator installs into a user virtual desktop, access to the virtual desktop may be limited to the user.

[0047] In one or more embodiments, the system 100 may also include a file system. The file system may allow organization of one or more files such that a file associated with a second application template of a second application is accessible to the user 110 of the client device 102 through a first application. The first application and the second application may be accessible to the user 110 of the client device 102. In one or more embodiments, the system 100 may also include a translation module to permit the access of the first application through an operating system of the client device 102 such that the first application is accessible to another operating system of the another client device. For example, a Word file can be accessible to a user using an application in linux operating system. The operating system of the client device 102 and another operating system of another client device may be different.

[0048] The client device 102 may include a set of applications and/or user data/settings. To achieve operating system independency, the desktop may be decoupled from the operating system 114 of client device 102 to be able to run it on any operating system of the client device 102. The desktop may include an application, a data, and a setting. The client device may be physical hardware. In one or more embodiments, associating the virtual container with the client device 102 may involve installation and/or execution of an executable application supporting the virtual container, in the client device 102. In one or more embodiments, the user 110 may run the executable application to access the virtual container.

[0049] In one or more embodiments, the system 100 disclosed herein gives the ability to run the user desktop of the client device 102 from any other client devices and recover from a hardware/operating system failure and similar disasters of the client device 102. The system may allow running a user desktop on an upgraded hardware/OS instantly. In addition, the user desktop of the client device 102 can be rendered accessible over the network 106, through one or more of a removable storage (e.g., USB drive), an external hard drive and/or directly on another client device.

[0050] FIG. 2 is a stack diagram of system 100 of FIG. 1, in accordance with one or more embodiments. In one or more embodiments, the system stack includes hardware 212 of the client device 102 as the lowest layer. The system stack includes operating system of the client device 102 as an intermediate layer and a virtual container associated with the client device 102 as a top most layer. In one or more embodiments, one or more elements of the hardware 212 of the client device 102 may be copied into the virtual container to emulate the hardware 212 of the client device 102. The elements may include, for example, data, files, folders and the like associated with the hardware 212 of the client device 102.

[0051] Further, one or more registry and other files and data associated with the operating system 114 may also be extracted into the virtual container. In one or more embodiments, any application accessed/executed through the client device 102 may be decoupled from the operating system 114 of the client device 102 and may be executed through the virtual container on either a host operating system associated with a server device 104 or on the operating system 114 of the client device 102 in accordance with the requirements of the application.

[0052] FIG. 3 illustrates a virtual container 210 associated with the client device 102 of FIG. 1, in accordance with one or more embodiments. In one or more embodiments, the virtual container 210 may include an application programming interface module 314. In one or more embodiments, the application programming interface module 314 is configured to interlock all file, registry, service control, event related calls made by system 100 and application 108 processes to allow the system 100 and application 108 processes to be processed by other subsystems of system 100 before a host kernel handles system 100 and application 108 processes. The interlocking allows redirecting resource request from applications either to the server device 104 or to the client device 102. The virtual container 210 may include a storage layer and a virtualization layer.

[0053] The storage layer may be an abstraction including information regarding components including, for example, a file storage (e.g., a uniform naming convention (UNC) path name of a network drive, and the like), registry storage (e.g., paths to reg.hives, names of reg.keys mapped to the reg.hives), and layer priority. The virtualization layer may be an abstraction including all virtualization components to virtualize one or more storage layers.

[0054] In one or more embodiments, the virtual container 210 may also include a virtual file module 306, a virtual registry module 310, and/or a virtual service control module 312. The virtual file module 306 may be configured to encapsulate native file system application programming interface calls for virtualization. The virtual registry module may be configured to encapsulate native registry application programming interface calls for virtualization. The virtual service control module 312 may be configured to encapsulate native Windows® service calls. Services may be Windows® services that are running in the background of client device.

[0055] In one or more embodiments, the virtual container 210 may be configurable by a list of storage layers (e.g. host layer, template layer, desktop layer). Each of the virtual file module 308, virtual registry module 310 and/or virtual service control module 312 may be software modules and may include one or more virtual engines (e.g., functions). According to the list, the virtual container 210 creates a required number of virtual engine instances that will operate with pair of storages (e.g. desktop-template N, template N-1-template N-2, . . . , template1-host) independently. In one or more embodiments, the virtual engine may use table of content (TOC) trees to keep track of the files in various layers. The TOC may be a tree data structure, representing in shared memory, the content, stored in the pristine storage.

[0056] The TOC provides search capability for a resource requested by the user 110 of the client device 102 in real time. In one or more embodiments, the TOC also keeps track of deleted files from the template and host layers. If the user 110 of the client device 102 deletes any of the files in the layers, though the files may not be physically removed from template/host layers, the files would not appear in the merged file system view for the user 110. Each virtual engine instance operates with one group of TOC trees. Each TOC group includes a virtual TOC, a real TOC and a deleted TOC. The deleted TOC may store information associated with information in the layers marked as deleted.

[0057] In one or more embodiments, the virtual container 210 further includes a template module 306. The template module 306 may be configured to manage one or more applications accessed through the client device 102. One or more administrators of the client device 102 may group applications into one or more templates for ease of management. For example, consider a marketing template containing applications for users in marketing department. The system 100 disclosed herein enables, for example, an administrator to manage marketing applications once instead of managing at multiple client devices. One or more user defined templates may be inherited from one or more system defined root templates. In another embodiment, a user defined template may be inherited from another user defined template.

[0058] The root templates may include registry/directory structure specific to a host operating system. The client devices may be inherited from one or more user defined templates where the changes to templates are reflected in the client devices. The client devices represent a copy-on-write on the templates with the user specific changes. The template module 306 also allows creation of one or more templates by the administrator of the client device. In one or more embodiments, a new template may be created using one or more base templates in the root templates. The creation of the new template may involve a copy operation of the base template. Multiple versions (e.g., application template 112₁-112_N) of a given template may be created and stored. A folder of a given template may include all the versions of the template as sub folders. In one or more embodiments, the virtual container 210 may further include an operating system translation module 304.

[0059] The operating system translation module 304 may be configured to provide mapping between virtual desktop operating system and the operating system of the client device in terms of registry, files, services and the like, during run time. The operating system translation module 304 may also be configured to dynamically link to the root template (e.g., operating system root template 302) containing necessary run time DLLs, the executable, registry and file structure, based on the host operating system for the client device.

[0060] FIG. 4 illustrates a virtual file system (VFS) 450, according to one or more embodiments. In one or more embodiments, the virtual file system 450 may include layers (e.g., desktop layer, template layer, host layer and the like). The template layer contains all the resources associated with a given application (e.g., word template, outlook template, and the like). The VFS 450 virtualizes the files system associated with the resources required for execution, access/or installation of the application. Each application has different resources/files including, for example, exe files, dynamic linked library, data configuration files required, and the like. The VFS 450 combines together all the resources associated with the application. The VFS 450 combines the files from each application template, root template and makes the combination a part of a base template on the server device. In one or more embodiments, the VFS 450 may also be updated.

[0061] Also consider for example, a set of applications including a word processing application having resources virtualized in the desktop layer and the template layer, a database application having resources virtualized in the template layer, and an operating system application having resources virtualized in the host layer. The word processing application may have a text.txt file virtualized in the desktop and template layers and also may have a x.txt file virtualized in the template layer. Similarly, the database application may have a y.xls file virtualized in the template layer and the operating system application may have a z.txt file virtualized in the host layer of the VFS 450. All of the text.txt, x.txt, and z.txt may be organized in a common c directory within the VFS 450 as illustrated in FIG. 4.

[0062] The c drive would be virtualization of a hardware drive of the client device 102 containing the files associated with the word processing, data base and operating system applications. In one or more embodiments, the system 100 allows various applications to access files within application templates of other applications running on same/different operating systems, the application templates residing in same/different directory within the VFS 450. For example, the database application may be allowed to access the test.txt file of the word processing application during execution of the database application in the virtual container 210.

[0063] FIG. 5 is a user interface 550 view of an operating system 114 of the client device 102 of system 100 of FIG. 1, according to one or more embodiments. Particularly, FIG. 5 illustrates the server device 104, the operating system 114, a locally executed desktop 504, a requesting 506, a virtualizing 508, and a virtualized desktop 502, according to one or more embodiments. The locally executed desktop 504 may be a desktop (e.g., computer screen, mobile screen, etc.) on the client device 102 where an application is presented. The requesting 506 may be a request for customization of look and feel from the user to the server device 104 through the client device 102 based on the preference of the user. The virtualizing 508 may be the process of creating the virtual desktop 502 through the virtual container 210. The virtualized desktop may be an application (e.g., the virtual desktop) that may be created through the virtual container 210 of the server device 104.

[0064] In one embodiment, the virtual container may run on the server device 104 through terminal sessions such that multiple virtual containers are running on the server device 104. Each virtual container running on the server device may be associated with a client device 102. In another embodiment, the virtual container may run on the client device 102.

[0065] In an example embodiment, FIG. 5 illustrates communication between the client device 102 and the server device 104. The client device 102 may request (e.g., the requesting 302) for an application from the server device 104. The server device 104 responds the client device 102 by virtualizing 508 through a virtual container 210. In one or more embodiments, the application installed on the server device 104 may be accessed through the client device 102. The application (e.g., client application, software application etc.) from the client device 102 (e.g., personal computer, a laptop etc.) may be executed without installing the application on the client device 102 when requested by a user (e.g., the user of FIG. 1) of the client device 102 through a binary module of the server device 104 that may emulate a set of function calls between the application and the operating system 114 of the client device 102. An application may run on the client device through a virtual container without installing the application on the client device 102, which may mean that the operating system 114 of the client device 102 may not be modified to perform the function calls between the application and the operating system 114.

[0066] An application component may be downloaded to the client device 102 when requested by a user (e.g., the user of FIG. 1) of the client device 102. The application component may be downloaded to a memory of the client device 102. The application component may be deleted from the memory (e.g., hard disk, RAM, magnetic disk etc.) of the client device 102 when the application executing on the client device 102 is inactive to prevent unauthorized duplication and/or access of the application. The application may be directly executed from the virtual container 210 through the binary module of the server device 104 emulating a set of function calls between the application and the operating system 114 of the client device 102 without downloading the application to the client device 102 (e.g., workstation, mobile device, etc.). The virtual container 210 may be software (e.g., simulated computer) that creates a virtualized environment that works with a host system (e.g., for executing an application without installing the application in the host device) even though it is independent of the host system (e.g., client device 102).

[0067] In one or more embodiments, look and feel of a desktop preference of the user may be recreated through the virtual container 210. The desktop preference may include an arrangement of files and/or folders in a file system, a color scheme of the file system, a background of the file system, an icon of the file system, an access control preference of the file system, a security preference of the file system, a bookmark associated with the user, a temporary file of the file system, a configuration of applications associated with the user, and a usability preference associated with the user. The desktop preference may be captured and stored to a user specific area of the server device 104 when the desktop preference is in use on the client device 102.

[0068] In one or more embodiments, the template module 306 of the virtual container 210 described in the description of FIG. 3, may be used to combine different application templates of a user desktop. The administrator may log in to a user desktop and/or an application template to install and/or upgrade an application. In case of template, a user desktops connected to the application template may automatically get the upgrade. In case of a user desktop, the user assigned to the desktop may get the upgrade. The update may include a patch installation to the application and/or an upgrade of the application. The binary module may include required resources between the application and the host operating system including a registry data, a file system data, and/or a DLL data. The server device 104 may have an application installed independent of any client-side operating system through the binary module of the server.

[0069] The server device 104 may execute the application directly from the virtual container 210 through the binary module emulating a set of function calls between the application and the host operating system of the server device 104 without downloading the application to the client device 102.

[0070] FIG. 6 is an exploded view of the binary module 610, according to one or more embodiments. Particularly, FIG. 6 illustrates the applications, an emulation module 601, a function analyzer module 602, a resources module 604, a determination module 608, a desktop reconstruction module 612, and a delete module 618, according to one or more embodiments. The emulation module 601 may be a software that may emulate (e.g., duplicate) a set of function calls between the operating system of the client device 104 and the application. The function analyzer module 602 may be software that may analyze the requirement of a particular function for emulation (e.g., may be at the time of access/execution of application). The resources module may allot and/or manage the resources (e.g., memory, etc.) for proper execution of the functions in the binary module 610. The determination module 608 may enable the binary module 610 to detect the client device 102 and/or the client device 102 based on a memory, microprocessor, and/or identification information of the coupled device.

[0071] The desktop reconstruction module 612 may reconstruct a look and feel desktop of the preference of the user. The delete module 618 may delete the application component from the client device 102 memory (e.g., the client device 102) when the application executing on the client device 102 is inactive to prevent unauthorized duplication and/or access of the application. The function analyzer module 602 may communicate with the emulation module 601 and the determination module 608.

[0072] The emulation module 601 may communicate with the resources module 604, the delete module 618, the function analyzer module 602, and the virtual container 210. The desktop reconstruction module 612 may communicate with the function analyzer module 602 and the virtual container 210. The desktop reconstruction module 612, the function analyzer module 601, and the emulation module 601 may communicate with the virtual container 210. The binary module 610 may communicate with the operating system of the client device 102.

[0073] The virtual container 210 may include a virtual file system. In one or more embodiments, the virtual file system may include one or more layers including, for example, a desktop file system layer, a host file system layer and a template file system layer. The layers may have different access modes. The access modes may include a read-only mode and/or a writable mode. In one or more embodiments, the .desktop layer may be accessed in the writable mode. The template layer and/or the host layer may be accessed in read-only mode. Each of the layers may include a file system and/or a registry.

[0074] During run time of an application accessed through the client device 102, the libraries required by the runtime are looked up from the desktop layer down to the host layer. The first match for a requested library is provided for the application. In one or more embodiments the virtual container 210 may be configurable by a list of storage layers (e.g. host, template1 . . . N, desktop). According to the list, the virtual container 210 may create required number of virtual engine instances that will operate with pair of storages (e.g. desktop-template N, template N-1-template N-2, . . . , template1-host) independently. The virtual engine uses TOC tress to keep track of files in different layers. TOC is a tree data structure, which represents in shared memory the content, stored in the pristine storage. TOC provides the search capability for a requested resource as fast as possible. The TOC may also keep track of deleted files from template and host layers.

[0075] FIG. 7 illustrates multiple client devices (e.g., client device 102₁-102_N) accessing multiple applications (e.g., applications 108₁-108₂) through the server device 104, in accordance with one or more embodiments. In one or more embodiments, a provisioning module 702 may provide an application template for execution of each application of the client device 102. For example if a user of the client device 102₁ desires to access an application 108₁, the provisioning module 702 may provide an application template 112₁ to provide all the necessary files and data for execution of the application 108₁ on a host operating system of the server device 104. Depending on the need of the application 108₁, the provisioning module 702 may choose one or more of the application templates (112₁-112_N) to provide to the client device 102 for execution of the application.

[0076] The applications (108₁-108_N) may however be installed on the server device 104 when the user initially tries to install the applications in the client devices (102₁-102_N). On providing appropriate application templates, the applications may be executed on a virtual container 210 of each of the client devices. A virtual container may be created for each of the client devices. In one or more embodiments, different versions of the applications may be executed on different virtual containers for a given client device. The different virtual containers may include, for example, different components to support different operating system components (e.g., windows components, Linux components). On execution, the various versions of a given application executed through different virtual containers may run on different host operating systems.

[0077] FIG. 8 illustrates the virtual registry system 850, in accordance with one or more embodiments. The virtual registry system 850 allows merging of registry trees on the fly. The virtual registry system 850 may also allow programs under virtual container 210 to use registry information from desktop and host/template layers, specifying the rules and mechanisms of keys/values within the registry, and mechanism of accessing the keys and values within the registry from virtual container 210. The virtual registry system 850 may use the TOC tress to keep track of registry keys/values in different layers. The TOC may be a tree data structure, representing in shared memory the content, stored in the registry storage. One or more operations may be performed under registry in the virtual registry system 850. The operations may include, for example, key open operations for read and write operations, create/set operations, delete operations, query/enumeration operations summary, query/enumerate value functions, query/enumerate key functions, enumerate operations and virtual indexes mapping, enumerate key/value and virtual indexes mapping, and the like.

[0078] An example of a virtual index mapping algorithm for registry keys would include the steps including, finding the root key entry in full TOC, iterating sub entries of the root key in full TOC and filling the vector of pointers to the entries, sorting vector with all sub entries by name, iterating through the vector and filling the virtual indexes mapping table. An example of a pseudo-code of mapping table filling algorithm logic for the registry keys is as follows:

// REGISTRY KEYS VIRTUAL INDEXES MAPPING TABLE FILL
PSEUDOCODE
IndexMap - virtual indexes map
RealIndexes[MaxLayers] - array of real indexes on each layer
virtualIndex - virtual index
Iterator iter - vector iterator
do for iter from vector.begin to vector.end // iterating the vector
{
virtualIndex = 0;
updatedFlag = false;
do for layerId from MaxLayer to MinLayer // iterating the layers
{
indexInMap = −1;
if( TestLayer(layerId, iter) )
{
if( not IsDeleted(iter))
{
indexInMap = RealIndexes[layerId];
updatedFlag = true;
}
++(RealIndexes[layerId]);
}
IndexMap+layerId, virtuallndex+ =indexInMap;
}
if(updatedFlag)
{
++virtualIndex;
}
}

FIG. 8 illustrates a set of registry keys, key id and corresponding virtual indexes. The key D with key id 1 is deleted from the template layer and hence does not have a virtual index.

[0079] FIG. 9 illustrates a virtual registry system 950 including registry values, in accordance with one or more embodiments. In the case of registry values, the values of the root key in registry tree may not be stored in sorted order and behave like elements in the vector. In one or more embodiments, the new elements may be pushed to the back of the vector. The deletion of element may be a simple erase of the element from the position of the element that also brings shifting of all other indexes by −1. To perform mapping virtual index to the real one, additional data may be stored and tracked in full TOC, representing the array and order (indexes) of registry values on each layer of the root template.

[0080] In one or more embodiments, for mapping registry values virtual indexes to real indexes on correspondent layer (RT) the one or more operations may be performed. The operations include, finding the root entry for values in fullToc, getting the TOC entry data value indexes struct from root entry, iterating through the value indexes struct vectors starting from a highest layer (e.g., desktop layer) and filling virtual indexes mapping table. An example of a pseudo code of filling mapping table algorithm for the registry values is as follows:

// REGISTRY VALUES VIRTUAL INDEXES MAPPING TABLE FILL
PSEUDOCODE
IndexMap - virtual indexes map
virtualIndex - virtual index
virtualIndex = 0;
// iterating the values in TOC vectors from Desktop to Host
do for tocVector from DesktopTocValuesVector to HostTocValuesVector
{
// resize corresponding layerld array in map to virtualIndex elements
// filled by value −1
IndexMap[layerId].resize(virtualIndex, −1)
realIndex = 0;
// iterating the values in TOC vector
do for tocVeclter from tocVector.begin( ) to tocVector.end( )
{
if( not IsDeleted(tocVecIter))
{
// get existing index that is stored in TOC entry
// or −1 if it doesn't exist
existinglndex = tocVecIter->GetExistingIndex( );
if(existingIndex != −1)
{
IndexMap[layerId, existingIndex] = realIndex;
}
else
{
IndexMap[layerId, virtualIndex] = realIndex;
tocVecIter->SetExistingIndex(virtualIndex);
++virtualIndex;
}
}
++realIndex;
}
}

As illustrated in FIG. 9, number in each cell is real index of a registry value in the corresponding layer. The value is −1 indicates that the value does not exist on the layer or was deleted. In one or more embodiments, the virtual registry system (850/950) includes one or more of a virtualization engine, registry access component, and/or registry storage.

[0081] FIG. 10 illustrates the process of updating an application template 112 in the system 100 of FIG. 1, in accordance with one or more embodiments. In one or more embodiments, an administrator 1008 (e.g., system administrator, network administrator and the like) may be allowed to simultaneously and/or concurrently update the application template 112 across each of the multiple users. The update may include a patch 1006 installation to the application template 112 and/or an upgrade of the application template 112. The update may also be performed in order to update an existing application template 112 with one or more new applications. When an administrator runs the application on the client device 102, the server device 104 may list one or more available application templates (excluding root templates) and user desktops. In one or more embodiments, the administrator may log in to any of the listed application templates or user desktops.

[0082] Upon login, an editable copy of the application template 112 may be created in a new location. The administrator can then perform actions allowed in a typical user desktop including installation of any applications, updates and patches (e.g., patch 1006). During updating the application template 112, in one or more embodiments all file/registry changes happening within a given session may be captured and stored within the template structure instance. Upon exit, the administrator can choose a version for the new template created. The administrator can then choose to publish the new template version. The server device persists the new template version under the template root folder with administrator provided version number. Once published, new client device 102 instances would automatically inherit from the latest template version. In one or more embodiments, the administrator may also have a save as option to give a different name to the template instead of creating a version with the existing template, allowing the administrators to create a replica of the existing template instead of inheriting from the existing template. In the example scenario illustrated in FIG. 10, the administrator 1008 updates the application template 112 with the patch 1006 to create application 1004 including the patch 106.

[0083] FIG. 11 is a process flow diagram detailing the operations of a client device as a part of a method of operating system independent cloud computing, according to one or more embodiments. In one or more embodiments, a first application template may be created through the user interface of an administrator of the client device. The first application template may be created such that the first application template is coupled to a registry structure and/or a directory structure such that the first application is accessible to the user of the client device. In one or more embodiments, a first installation program on the client device may be converted to the first application template. The first installation program may include, but is not limited to a file, a registry key, and a registry value to install the first application to the client device. The first application template may be created based on a conversion of the first installation program through an installation of the first installation program such that the client device accesses the first application through the first application template.

[0084] Further, in one or more embodiments, a second application template may be created such that the second application template is coupled to the registry structure and/or the directory structure such that the second application is accessible to the user of the client device. The first application template and the second application template may share the registry structure and/or the directory structure.

[0085] In one or more embodiments, in operation 1102, a first application is accessed through a first application template. Examples of the first application template may include, but is not limited to, an executable, a library, an image, a configuration file, and a registry key. The first application through the first application template may be accessible to the client device and another client device through the first application template. The operating system of the client device and another operating system of another client device may be different. The first application may be accessible to the client device and another client device through the first application template. In one or more embodiments, the first application template of the client device and the first application template of another client device may be the same.

[0086] The first application template may reside on a server device. In one or more embodiments, the first application template may be accessed through a software as a service model through a cloud environment such that the first application is accessible through the first application template. The user of the client device and another user of another client device access the first application through the first application template. In one or more embodiments, in operation 1104, the first application may be accessed based on a response to a request of a user interface of the client device. In one or more embodiments, in operation 1106, the first application may be processed through a processor, such that the first application accesses the first application template such that the client device permits an access of the first application through the first application template. In one or more embodiments, in operation 1108, the first application may be executed through the first application template such that an execution of the first application through the first application template emulates the execution of the first application installed on an operating system of the client device.

[0087] In one or more embodiments, in operation 1110, a function of the first application template may be executed based on based on a demand of a user through the response to the request of the user such that a file is accessed when required of the first application. In one or more embodiments, in operation 1112, a first file of the user and a second file of the user may be accessed through the first application, wherein the first file is of a type of the first application and the second file is of the type of a second application. In one or more embodiments, in operation 1114, the first application template may be translated to suite the operating system of the client device based on the type of the operating system such that the first application is accessible to a user of the client device. In one or more embodiments, in operation 1116, the second application template may be translated to suite the operating system of the client device based on the type of the operating system such that the second application is accessible to the user of the client device.

[0088] In one or more embodiments, a file system may be created such that the file system includes a layer to manage the first file of the user, such that the first file is accessible through the first application and a setting of the user such that a setting is customizable through a response of the request of the user. The setting may be accessible to the user when the first application is accessed. In one or more embodiments, the file system including another layer may be created such that another layer manages another first file of the first application template. Also another first file may be accessible through the first application, and the first application template may include another first file.

[0089] In one or more embodiments, the file system including yet another layer may be created such that yet another layer manages a host file. The host file may be the file of the operating system of the client device. The host file may be accessible through the first application. In one or more embodiments, the another first file of the first application template may be marked as deleted based on the response to the request of the user through the user interface of the client device such that the another first file remains a component of the first application template. In one or more embodiments, the access to the another first file of the first application template through the first application may be denied based on a deleted marking.

[0090] FIG. 12 is a process flow diagram detailing the operations of a server device as a part of a method of operating system independent cloud computing, according to one or more embodiments. In one or more embodiments, in operation 1202, a client may be permitted to access a first application through a first application template residing on the server device. Examples of the first application template may include, but is not limited to, an executable, a library, an image, a configuration file, and a registry key. The first application may be accessible through the first application template to the client device and/or another client device. The first application template of the client device and the first application template of another client device may be the same.

[0091] In one or more embodiments, in operation 1204, the client may be permitted to access a second application through a second application template residing on the server. A request based on the request of a user interface of a client device to access the first application and/or the second application may be processed through a processor coupled to the server device. The first application and/or the second application may be accessible through the user interface.

[0092] In one or more embodiments, in operation 1206, the first application template and/or the second application template may be accessed based on the request of the user interface of the client device. In one or more embodiments, the server device may permit the access of a first file of the user and/or a second file of the user through the first application, where the first file is of the type of the first application and the second file is of the type of the second application. In one or more embodiments, in operation 1208, a translation file may be determined based on a type of an operating system of the client device such that the application is accessible to a user of the client device. The operating system of the client device and another operating system of the another client device may be different such that the first application is accessible to the client device and the another client device through the first application template.

[0093] In one or more embodiments, the server device may permit the access of the first application template through a software as a service model through a cloud environment such that the first application is accessible through the first application template. The user of the client device and another user of another client device may access the first application through the first application template. The first application template of the user and the first application template of the another user may be same.

[0094] In one or more embodiments, the server device may permit access of the first application and the second application through a binary module coupled to the first application template and the second application template. The binary module may emulate a set of a function call between the first application and the operating system of the client device and the function call between the second application and the operating system of the client device.

[0095] Although the present embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments. For example, the various devices, modules, analyzers, generators, etc. described herein may be enabled and operated using hardware circuitry (e.g., CMOS based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (e.g., embodied in a machine readable medium). For example, the various electrical structure and methods may be embodied using transistors, logic gates, and electrical circuits (e.g., application specific integrated (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).

[0096] With the above embodiments in mind, it should be understood that one or more embodiments of the invention may employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing. Any of the operations described herein that form part of one or more embodiments of the invention are useful machine operations. One or more embodiments of the invention also relates to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, such as the carrier network discussed above, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

[0097] The programming modules and software subsystems described herein can be implemented using programming languages such as Flash, JAVA™, C++, C, C#, Visual Basic, JavaScript, PHP, XML, HTML etc., or a combination of programming languages. Commonly available protocols such as SOAP/HTTP may be used in implementing interfaces between programming modules. As would be known to those skilled in the art the components and functionality described above and elsewhere herein may be implemented on any desktop operating system such as different versions of Microsoft Windows, Apple Mac, Unix/X-Windows, Linux, etc., executing in a virtualized or non-virtualized environment, using any programming language suitable for desktop software development.

[0098] The programming modules and ancillary software components, including configuration file or files, along with setup files required for providing the method and apparatus for troubleshooting subscribers on a telecommunications network and related functionality as described herein may be stored on a computer readable medium. Any computer medium such as a flash drive, a CD-ROM disk, an optical disk, a floppy disk, a hard drive, a shared drive, and storage suitable for providing downloads from connected computers, could be used for storing the programming modules and ancillary software components. It would be known to a person skilled in the art that any storage medium could be used for storing these software components so long as the storage medium can be read by a computer system.

[0099] One or more embodiments of the invention may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The invention may also be practiced in distributing computing environments where tasks are performed by remote processing devices that are linked through a network. One or more embodiments of the invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data, which can thereafter be read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, DVDs, Flash, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

[0100] While one or more embodiments of the present invention have been described, it will be appreciated that those skilled in the art upon reading the specification and studying the drawings will realize various alterations, additions, permutations and equivalents thereof. It is therefore intended that embodiments of the present invention include all such alterations, additions, permutations, and equivalents as fall within the true spirit and scope of the invention as defined in the following claims. Thus, the scope of the invention should be defined by the claims, including the full scope of equivalents thereof.