GB2510199A

GB2510199A - Managing desktop settings using shared and separate modes

Info

Publication number: GB2510199A
Application number: GB1301581.3A
Authority: GB
Inventors: John Sinclair; Ben Staniford; Matthew Pritchard
Original assignee: AppSense Ltd
Current assignee: AppSense Ltd
Priority date: 2013-01-29
Filing date: 2013-01-29
Publication date: 2014-07-30
Also published as: GB201301581D0

Abstract

A method for managing a desktop setting comprises: maintaining, on a server 1111, a container 1120 for storing setting data and a configuration file for storing mode data, where the container comprises a shared portion and an isolated portion; synchronising 1500 the container and configuration file between the server and a client 1115; determining whether a setting is in a shared mode or a separate mode using the mode data; and managing the setting in accordance with the determined mode. Synchronisation may be performed at logoff 1590 and/or logon 1550. The use of a shared portion to store setting data optimises capacity/space usage in the container by not duplicating data. Setting data may be translated for use in different client operating system environments, allowing user preferences to be maintained in a single container.

Description

Improvements in and relating to Desktop Settings The present invention concerns the provision of a method for obtaining, maintaining, preserving, translating, communicating, and applying desktop settings and storing thereof across different Operating System (OS) environments. The method also provides for a space-efficient storage of desktop settings data.

Embodiments of the invention find particular, but not exclusive, use when a user logs on to a computer running on a first OS, logs off, and then logs on to a computer running a second Os, wherein the first and the second OS might be of different versions or types and the user would like to maintain and apply desktop settings across the first and second OS. In particular, the present invention enables: obtaining; maintenance; translation; communication; and application of desktop settings in a plurality of OS environments such as different versions of Windows® using a space-efficient storage.

In Microsoft Windows ®, the user can customise desktop settings related to the appearance and behaviour of the OS. Examples of such desktop settings would be window colours, windows appearances, themes, mouse, keyboard settings and others. Although these desktop settings are configured through a simple Graphical User Interface, the underlying data related to these desktop settings are stored in various parts of a registry or file-system implemented by the OS. This somewhat scattered storing of the desktop settings data and implementation of different desktop settings data, registry or file-system in different versions or types of the OS means it can be difficult to maintain and apply desktop settings across different OS versions or types.

These desktop settings data are maintained using a user profile wherein information required for maintaining and applying such desktop settings data are stored. Two types of user profile are used at present, namely a local profile and a roaming profile. The local profile is a user profile stored on and read from a local machine. The roaming profile is stored on and read from a centralised storage on logoff and logon respectively, wherein an example of the centralised storage would be a server connected to the local machine via a network.

However when the roaming profile is used across different OS versions or types, due to difficulties outlined above, preservation of a configuration of the desktop settings across different OS versions or types becomes problematic. For example, Windows © V.1 profiles are incompatible with Windows V.2 profiles and requires independent maintenance and management thereby making such preservation of the configuration very difficult. Further some desktop settings data can be incompatible between different Windows ® versions adding further difficulty to such preservation.

It is an aim of embodiments of the present invention to address problems mentioned herein and other problems that may be encountered when desktop settings are used. The embodiments of the present invention provide for a method or an apparatus for obtaining, maintaining, preserving, translating, communicating, and applying desktop settings and storing thereof across different Operating System (OS) environments in a space-efficient manner.

According to the present invention there is provided a method and apparatus as set forth in the appended independent claims. Other features of the invention will be apparent from the dependent claims, and the description which follows.

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example, to the accompanying diagrammatic drawings in which: Figure 1 shows a schematic representation of data flow among components of a server 1111 and a client 1115 according to an embodiment of the present invention; Figure 2 shows a logoff process 1590 according to an embodiment of the present invention; Figure 3 shows a logon process 1550 according to an embodiment of the present invention; Figure 4 shows a setting application step 3510 comprising a translation step 3720 according to an embodiment of the present invention; and Figure 5 shows an illustrative environment 1010 according to an embodiment of the invention.

According to embodiments of the present invention, there is provided a method, a system, and a computer readable medium storing a computer program to operate the method for desktop setting management in which data for managing a desktop setting is communicated between and stored in a server and a client. The embodiments provide for managing, communicating and/or synchronising a configuration file and a container between the server and the client so that a desktop setting can be applied and/or implemented across different client environments. The container comprises a shared portion and an isolated portion in which the desktop setting data is stored according to its applicability in different client environments.

The method comprises a logoff process which provides for storing of the desktop setting data in a capacity/space efficient manner in the container in accordance with a mode set specifically for the desktop setting by an administrator. The mode indicates whether a specific desktop setting is to be applied and/or implemented to a specific client environment or across different client environments. The logoff process comprises synchronising of the container between the server and the client.

The method also comprises a logon process which provides for application and/or implementation of the desktop setting using the desktop setting data stored in the container.

The logon process comprises synchronising of the configuration file and the container. The logon process can also comprise translating of incompatible setting data to compatible setting data using the configuration file, so that setting data stored during a logoff process can be used in more than one client environment.

Figure 1 shows a schematic representation of data flow among components of a server 1111 and a client 1115 according to an embodiment of the present invention. The server 1111 comprises a database 1120 whereon configuration data and/or setting data is stored and/or maintained. The client 1115 comprises a cache 1130, a configuration file 1140, and a registry 1150.

According to an embodiment of the present invention, the database 1120 is a Structured Query Language (SQL) based database capable of storing and/or managing the configuration data and the setting data. According to this embodiment, the setting data is desktop setting data which relates to desktop settings but any other data for a setting which is OS environment specific can be obtained, maintained, preserved, translated, communicated, and/or applied according to other embodiments of the present invention.

The configuration file 1140 is an XML configuration based file and comprises configuration data for implementing the setting data in a client environment or an access data for accessing such configuration data. The client environment is an OS environment whereon the client 1115 is running. The configuration data comprises a rule or a mapping for each setting data. The configuration data comprises a mode data wherein it indicates whether a particular setting is to be set to be in a shared mode or a separate mode whereby the implementation of the setting and/or the storage of the setting data can be controlled in accordance with the configuration data. According to an embodiment, the setting data comprises the mode data.

The configuration data may also comprise translation data for translating an incompatible first setting data into a compatible second setting data so that the compatible second setting data can be implemented in the client environment. For example, the first setting data may be compatible with Windows XP ® but incompatible with Windows 7 ®.

When the client is running on Windows 7 ®, the translation data is used to translate any first setting data into the second setting data which is compatible with Windows 7 ®. The translation data comprises information on mapping, path, location, data, value and/or any other parameter whereon setting implementation and/or storage depends, and how the related data in different OS environments differ from one another or at least how they can be translated from one to the other. An administrator of the server 1111 and/or the client 1115 can compile such translation data or a heuristic method might be used to compile the translation data.

The cache 1130 is a local cache on the client 1115 which stores a set of data in a folder of a file-system implemented by the OS environment. It is understood that the cache 1130 can also be located and/or stored elsewhere as long as it remains accessible to the client 1115.

According to an embodiment, the set of data in the cache 1130 is specific to a user of the client 1115 and the local cache 1130 resides in a folder specific to the user of the client 1115 in the file-system. The local cache 1130, in use, stores data comprising at least one of: setting data; configuration data; registry data; file-system data; and any other relevant data items for settings such as icon positions, cursors and others.

The registry data comprises data relating to any managed setting or desktop setting which reside in the registry 1150 of the OS environment. Depending on the OS environment, such registry data may comprise keys, values, information on hives wherein these are saved and any other data that relates to settings and options available in the OS environment. The file-system data comprises data in relation to any managed desktop setting which reside in the file-system of the OS environment such as folders and/or files. According to an embodiment, the registry 1150 is Windows ® registry and/or file-system proper of the OS environment.

According to an embodiment, the registry data is stored, accessed, and/or communicated in the form of a binary file or a File Based Registry file.

According to an embodiment of the present invention, the configuration data is used to specify which registry keys and/or values in the registry data will be managed, i.e. restored/accessed/applied/implemented by a logon process and saved/stored by a logoff process, for any given OS environment. In this embodiment, the configuration data comprises a path such as V-IKEY_CURRENT_USEMControI Panel\Colors" and the setting data comprises the registry value data related to the path.

For example, in Windows © registry, under the registry key of "HKEY_GURRENT_IJSER\Control Pane/\Co/ors", there are a number of registry values each of which comprises data such as Background, which in turn comprises a string such as "00,0" to indicate a RGB value of a colour for the "Background'. When a user logs off, if the setting to which this key relates, i.e. colour for the "Background', is managed, the logoff process saves/stores the registry/setting data, i.e. string "0,0,0", to a container whereby the registry/setting data is transported/communicated to a server. The server stores/manages the registry/setting data centrally and provides an access thereto to a client. The registry/setting data is read from the Windows © registry and written to the container. When the user logs on, the logon process reads/accesses the container and writes/applies/implements the registry/setting data therein to the Windows® registry.

According to an embodiment of the present invention, the container is stored, accessed, and/or communicated in the form of a binary file or a File Based Registry file. The container comprises a silo, which is a part of the File Based Registry file in the form of a sub-container, wherein the silo is used to store and/or communicate the registry and/or setting data.

It is understood that the data flow shown in Figure 1 can be performed among different components of a server 1111 and a client 1115 according to an alternative embodiment of the present invention. It is also understood that the configuration data and/or the setting data may be maintained or stored on any storage medium capable of communicating the configuration data and/or the desktop setting data to the client 1115. Further, it is understood that other appropriate modifications can be made to the embodiments of the present invention to achieve the same effect. For example, the client can also run in a different OS environment to that related to in information in the configuration data or the setting data when the client runs in a simulated and/or virtualised environment.

According to an embodiment of the present invention, when a user logs on to and/or off from the client 1115, synchronisation 1500 between the server 1111 and the client 1115 occurs.

During a logoff process 1590, the configuration file 1140 provides configuration data; the registry 1150 provides registry data; and the configuration data and the registry data are used to store setting data in the cache 1130. At least the setting data is then communicated to the database 1120 before the logoff 1590 terminates. The database 1120 then stores the setting data therein for future use. Use of the configuration data and/or the registry data for storing the setting data in the cache 1130 enables the setting data to be communicated and/or stored in a capacity/space efficient manner. Depending on the embodiment of the present invention, the configuration data and/or the registry data may also be communicated to and/or stored in the database 1120.

During a logan process 1550, the database 1120 provides configuration data to the configuration file 1140. Depending on the embodiment of the present invention, the database 1120 may communicate the configuration data in advance of any user logon process 1550 whereby the configuration data is retained in the configuration file 1140 for use in later initiated logon process 1550. The database 1120 also provides setting data to the cache 1130 which is then read in conjunction with the configuration data in the configuration file 1140 so that a relevant/managed setting can be implemented and/or translated into the registry 1150 whereby the relevant/managed setting is applied to the client environment or the desktop.

It is understood that according to an embodiment, the configuration data 1140 is only communicated between the server 1111 and the client 1115 during a first communication therebetween and the configuration data 1140 is synchronised only when an update thereof is required. According to an alternative embodiment, the configuration data 1140 is communicated between the server 1111 and the client 1115 whenever the container comprising the registry/setting data is communicated.

The logoff process 1590 and the logon process 1550 will be described in more detail with reference to Figures 2 and 3 respectively.

Referring to Figure 2, when a user logs off from the client 1115, synchronisation 1500 between the server 1111 and the client 1115 occurs according to an embodiment of the present invention. During the logoff process 1590, the synchronisation 1500 comprises a first synchronisation comprising a step of communicating setting data from the cache 1130 of the client 1115 tothedatabase 1120 oftheserver 1111.

The setting data conimunication step further comprises steps of: communicating configuration data from the configuration file 1140 to the cache 1130 or a processor connected to the cache 1130; communicating registry data from the registry 1150 to the cache 1130 or a processor connected to the cache 1130; and using the configuration data and/or the registry data to generate and/or store the setting data in the cache 1130 for the setting data communication step. The configuration data and/or the registry data are used to store the setting data in the cache 1130 in a capacity/space efficient manner which also results in a capacity/space efficient communication thereof to the database 1120. A setting container, which is a binary file comprising setting data stored therein in a specified hierarchy/structure, is used to store and/or communicate the setting data in the capacity/space efficient manner.

According to an embodiment, the first synchronisation occurs after the user prompts the logoff process 1590 and before the termination of the logoff process 1590 so that all necessary setting data required for a future login process 1550 can be stored in the cache 1130, which is then communicated to the database 1120 for storage and access by a client 1115. A portion of the first synchronisation can also occur before the user initiates the logoff process 1590 so that time taken for the logoff process 1590 can be reduced. Such portion of the first synchronisation that occurs before the logoff process 1590 may relate to setting data that is unlikely to be changed more than one time or that requires a restart before further changes to the setting data can be made, i.e. logoff process is required before a further change can be made. According to an alternative embodiment, a portion of the first synchronisation occurs whenever the user applies changes to the setting data so that the setting data in the database 1120 is incrementally updated in accordance with the user's changes to the setting data in the registry 1150 and/or the cache 1130.

According to an embodiment of the present invention, the logoff process 1590 comprises the steps of: accessing/obtaining configuration data in/from the configuration file 2110; accessing/obtaining registry data in/from the registry 2120; storing setting data in a shared portion of a container 2320 or in an isolated portion of a container 2420; and communicating the container to the database of the server 2150, wherein the configuration data and/or the registry data are used to generate and/or store the setting data and to determine whether the setting data is stored in the shared portion or the isolated portion, or not stored at all. According to an embodiment, the first synchronisation comprises the communication step 2150 and the storage/update/maintenance of the setting data in the database. Optionally, the configuration data access step 2110 may further comprise storing of the accessed configuration data and/or registry data in the cache 1130.

The configuration data access step 2110 further comprises the steps of: parsing the configuration data; and identifying a setting to which each parsed configuration data relates.

According to an embodiment, the registry data access step 2120 is a step of selectively accessing/obtaining registry data from the registry comprising the steps of: determining whether an identified setting is a managed setting or not using the configuration data; if the identified setting is a managed setting, accessing/obtaining registry data related to the identified setting in/from the registry; and arranging only setting data of the managed setting to be put forward for the setting data storage steps 2320, 2420, wherein the configuration data indicates whether a setting is a managed setting or not. An administrator or a user can indicate a managed setting in the configuration data manually/arbitrarily or the indication thereof may be added automatically whenever a setting is set or changed by the administrator or the user. The managed settings are settings of interest to the administrator or the user which will be affected by an embodiment of the present invention. According to an embodiment, an existence of a specific configuration data in the configuration data indicates the related setting is a managed setting. In a yet another embodiment, a heuristic method can be used to indicate managed settings.

According to alternative embodiment, at the selective registry data access/obtaining step 2120, if the registry data is stored in the cache, the logoff process 1590 accesses and/or obtains the registry data from the cache instead of the registry.

The logoff process 1590 further comprises a step of client environment applicability determination 2130, wherein whether an identified setting is applicable to the client environment or not is determined. In this embodiment, when a setting is identified in the configuration data access step 2110, a determination is made as to whether or not the identified setting can be applied to a host OS of the client environment, i.e. OS whereon the client environment runs. It is understood that any of the configuration data, the registry data and/or the setting data can be used to make this determination. According to an embodiment, an administrator indicates applicability of a setting to a particular client environment in the configu ration data.

If the outcome of the environment applicability determination step 2130 is negative, the logoff process 1590 proceeds on to a further identified setting determination step 2140 wherein a determination is made as to whether or not a further/another setting was identified in the configuration data access step 2110. If the outcome of the further identified setting determination step 2140 is positive, the logoff process 1590 proceeds to the configuration data access step 2110 in relation to the further identified setting and repeats the steps described to be succeeding thereafter. If the outcome of the further identified setting determination step 2140 is negative, the logoff process 1590 proceeds to the container communication step 2150 whereby the setting data thereof are stored/updated in the database of the server.

According to an embodiment, if the outcome of the environment applicability determination step 2130 is positive, the logoff process 1590 proceeds to the selective registry data access/obtaining step 2120 and an isolated setting determination step 2210, wherein a determination is made as to whether or not the identified setting is specific to the client environment. This isolated setting determination step 2210 ensures only environment specific setting data is considered for storing in the isolated portion of the container and the rest of the setting data is store in the shared portion, whereby capacity/space efficient storage and/or communication of the setting data is achieved.

If the outcome of the isolated setting determination step 2210 is negative, the logoff process 1590 proceeds to store the setting data of the identified setting in the shared portion of the container 2320 and proceeds to the further setting determination step 2140 thereafter.

If the outcome of the isolated setting determination step 2210 is positive, the logoff process 1590 proceeds to a shared value match step 2310 wherein the setting data for the identified setting is compared with setting data thereof stored in the shared portion of the container to determine whether there is a match therebetween.

If the outcome of the shared value match step 2310 is positive, the logoff process 1590 proceeds to store the setting data of the identified setting in the shared portion of the container 2320. This use of the shared portion ensures there is minimal overlap among setting data stored in the container whereby the capacity/space efficiency is achieved.

It is understood that when the setting data of the identified setting is identical to the setting data already stored in the shared portion, the storing of the setting data in the shared portion storage step 2320 comprises no further changes to the setting data already stored in the shared portion. However, according to an embodiment of the present invention, the shared portion storage step 2320 may also comprise a step of adding an indicator to the shared portion to indicate that any other OS environment which is the same version and/or type as the client environment can use the setting data stored in the shared portion.

It is also understood that according to an embodiment of the present invention, if the shared value match step 2310 determines that the shared portion is empty, the logoff process 1590 proceeds to the shared portion storage step 2320 wherein the setting data of the identified setting is stored in the shared portion by default even if it was determined to be specific to the client environment during the isolated setting determination step 2210. This ensures no unnecessary isolated portion is created and/or stored in the container wherever possible so that the size of the container is kept to a minimum.

According to an alternative embodiment, an indicator indicating under which environment the setting data of the identified setting is stored in the shared portion may also be stored in the shared portion.

If the outcome of the shared value match step 2310 is negative, the logoff process 1590 proceeds to store the setting data of the identified setting in the isolated portion of the container 2420 and proceeds to the further setting determination step 2140 thereafter.

According to an embodiment of the present invention, the shared value match step 2310 comprises the steps of: determining if the setting data of the identified setting is the same as the setting data stored in the shared portion; and if they are the same, removing the setting data already stored in an isolated portion related to the identified setting.

It is understood that the presence of an isolated portion can be used as an indicator to indicate whether the user has previously logged off from a particular client environment or not.

If a silo or a sub-container for that particular client environment is present in the isolated portion of the container, for example "XP" or "W7", during a setting data access step 3120 of a logon process it is possible to detect such an indicator whilst parsing the setting data as described with reference to Figure 3. According to an alternative embodiment, an indicator is present and/or stored in the configuration data and the indicator is detected whilst parsing the configuration data during a configuration data access step 3110 of a logon process as described with reference to Figure 3.

According to an alternative embodiment of the present invention, the shared value match step 2310 may also insert an indicator for indicating which client environment the setting data in the shared portion is compatible with or applicable to. This indicator may be stored in the setting data, the configuration data and/or the registry data. According to an embodiment, this indicator may take the form of a silo, a sub-container or an empty registry key stored in a container or a sub-container, whereby it can indicate that a particular client environment has stored its relevant setting data in the container during a previous logoff process.

In a yet another embodiment, if the outcome of the shared value match step 2310 is only partially positive, i.e. only part of the setting data is a match, the logoff process 1590 proceeds to treat the matching portion of the setting data as if it had returned the positive outcome and the remaining portion of the setting data as if it had returned the negative outcome, and the logoff process 1590 proceeds to subsequent steps accordingly in relation to each matching and remaining portion of the setting data.

Referring to Figure 3, when a user logs on to the client 1115, the synchronisation 1500 between the server 1111 and the client 1115 occurs according to an embodiment of the present invention. During the logon process 1550, the synchronisation 1500 comprises a step of communicating data from the database 1120 of the server 1111 to the cache 1130, a processor connected to the cache 1130 and/or the configuration file 1140 of the client 1115. A setting container, which is a binary file comprising data stored therein in a specified hierarchy/structure similar or identical to that used in the logoff process 1590, is used to store and/or communicate the data in a capacity/space efficient manner.

The data communication step 3100 comprises a second synchronisation for configuration data and/or a third synchronisation for setting data.

The data communication step 3100 comprises a second synchronisation comprising a step of communicating the configuration data from the database 1120 of the server 1111 to the configuration file 1140 of the client 1115. The second synchronisation only occurs when the configuration data in the configuration file 1140 is different from the configuration data stored in the database 1120. The second synchronisation is prompted by any change made to the configuration data in the database 1120. According to an alternative embodiment, the second synchronisation occurs at every predetermined time intervals, whenever an administrator of the server 1111 or the client 1115 manually prompts, or at any other instances wherein the configuration data in the configuration file 1140 requires a change or an update. In such embodiments, the server 1111 and the client 1115 communicate regularly to ensure detection of such instances.

The data communication step 3100 further comprises a third synchronisation comprising a step of communicating setting data from the database 1120 of the server 1111 to the cache 1130 or a processor connected to the cache 1130 of the client 1115. The third synchronisation occurs whenever the user logs on to the client 1115 or whenever desktop setting application occurs. According to an alternative embodiment, the third synchronisation occurs at every predetermined time intervals, whenever an administrator of the server 1111 or the client 1115 manually prompts, or at any other instances wherein the setting data in the cache 1130 requires a change or an update. In such embodiments, the server 1111 and the client 1115 communicate regularly to ensure detection of such instances.

Such embodiments of the data communication step 3100 enable the database 1120 to provide/communicate the configuration data in advance of any user logon process 1550 whereby the configuration data is retained in the configuration file 1140 for use in later initiated logon process 1550. The database 1120 also provides setting data to the cache 1130 which is then read in conjunction with the configuration data in the configuration file 1140 so that a relevant/managed setting can be applied, implemented and/or translated into the registry 1150 whereby the relevant/managed setting is applied to the client environment or the desktop.

According to an embodiment of the present invention, the logon process 1550 comprises the steps of: accessing/obtaining configuration data in/from the configuration file 3110; accessing/obtaining selling data in/from the cache or the processor 3120; and applying setting to a client environment using the configuration data and the setting data 3510, wherein: a container is used to store and/or communicate the configuration data and/or setting data; the configuration data and/or the selling data are used to access and/or obtain registry data from a shared portion or a isolated portion of the container; and the setting is applied by communicating and/or applying the registry data to a registry of the client environment.

According to an embodiment, the configuration data access step 3110 further comprises the steps of: parsing the configuration data; and identifying a setting whereto each parsed configuration data relates. According to an embodiment, the setting data access step 3120 further comprises the steps of: parsing the configuration data and/or the setting data; and identifying a setting whereto each parsed configuration data and/or setting data relates.

According to an embodiment, the logon process 1550 comprises a step of client environment applicability determination 3130, wherein whether an identified setting is applicable to the client environment or not is determined, whereby a determination is made as to whether or not the identified setting can be applied to the host OS of the client environment, i.e. OS environment whereon the client environment runs.

If the outcome of the environment applicability determination step 3130 is negative, the logon process 1550 proceeds on to a further identified setting determination step 3140 wherein a determination is made as to whether or not a further/another setting was identified in the configuration data access step 3110. If the outcome of the further identified setting determination step 3140 is positive, the logon process 1550 proceeds to the setting data access step 3120 in relation to the further identified setting and repeats the steps described to be succeeding thereafter. If the outcome of the further identified setting determination step 3140 is negative, the logon process 1550 terminates at a termination step 3900.

According to an embodiment, if the outcome of the environment applicability determination step 3130 is positive, the logon process 1550 proceeds to a shared setting determination step 3210 wherein a determination is made as to whether or not the identified setting is a shared setting among different the client environments.

If the outcome of the shared setting determination step 3210 is negative, the logon process 1550 proceeds to an isolated portion determination step 3320, wherein a determination is made as to whether the setting data for the identified setting is stored in the isolated portion of the container or not.

If the identified setting data is stored in the isolated portion, the logon process 1550 proceeds to an isolated portion access step 3410 wherein the identified setting data is accessed and/or read from the isolated portion. The logon process 1550 then proceeds to a setting application step 3510 wherein the identified setting is applied to the client environment.

The setting application step 3510 comprises a step of communicating, applying and/or storing of the registry data to the registry of the client environment. The setting application step 3510 takes the form of applying/implementing registry data, which is related to the identified setting data and obtained from the setting data, in accordance with the configuration data.

Once the setting application step 3510 has been performed, the logon process 1550 proceeds to the further identified setting determination step 3140 and performs the steps thereafter accordingly.

If the isolated portion determination step 3320 determines that the identified setting data is not stored in the isolated portion, the logon process 1550 proceeds to a shared portion access step 3310 wherein the identified setting data is accessed and/or read from the shared portion.

The shared portion access step 3310 comprises a step of determining whether the identified setting data is stored in the shared portion or not. If the identified setting data is stored in the shared portion, the logon process 1550 proceeds to the setting application step 3510 and performs the steps thereafter.

If the shared portion access step 3310 determines that the identified setting data is not in the shared portion, a system default value/setting data for the identified setting is used by the logon process 1550. The system default value may be predetermined by the configuration data, set by the administrator, set by the user, or set by the client environment.

If the outcome of the shared setting determination step 3210 is positive, the logon process 1550 proceeds to the shared portion access step 3310 and performs the steps thereafter accordingly.

These shared setting determination step 3210 and isolated portion determination step 3320 ensure setting data for the identified setting can be accessed and/or read wherever it is stored in the container, namely the shared or the isolated portion.

According to an embodiment, the configuration data or the container indicates whether a previous logoff process 1590 has been performed in the same environment as the present client environment or not. If there has never been a previous logoff process 1590 performed in such environment, the outcome of the isolated portion determination step 3320 is set to be negative. Since it is during the logoff process 1590 that the first setting entry will be created and/or stored in the isolated portion, this ensures efficient progress along the logon process 1550 wherein the number of occurrences of performing the isolated portion access step 3410 in isolated portions which do not exist are reduced. Suitably, during the isolated portion access step 3410 and the shared portion access step 3310, if the identified setting data is not found in the isolated portion or the shared portion respectively, the logon process 1550 uses the system default value.

Referring to Figure 4, the setting application step 3510 comprising a translation step 3720 according to an embodiment of the present invention is described herein.

The setting application step 3510 further comprises performing the steps of: a compatibility determination step 3610; if incompatible, a translation step 3720; and a translated setting application step 3710, wherein the translation step comprises performing a translation of the identified setting data using translation data provided in the configuration data.

If the outcome of the compatibility determination step 3610 is positive, the logon process 1550 proceeds to the translated setting application step 3710 whereby the identified setting is applied and/or implemented to the client environment without translation.

If the outcome of the compatibility determination step 3610 is negative, the logon process 1550 proceeds to the translation step 3720 whereby the identified setting data is translated to registry data compatible with the client environment. The logon process 1550 then proceeds to the translated setting application step 3710 so that the translated registry data can be applied and/or implemented to the client environment.

The translated setting application step 3710 comprises a step of communicating and/or applying the registry data to the registry of the client environment. The translated setting application step 3710 takes the form of applying/implementing translated registry data, which has been translated from registry data related to the identified setting data wherein the registry data is obtained from the setting data in accordance with the configuration data. According to an embodiment of the present invention, the translated setting application step 3710 comprises at least one of the steps of: mapping one path to another; or mapping one data value to another. A look-up table or any other form of storing and/or applying mapping information may be used in the translated setting application step 3710.

An example of the translated setting application step 3710 might comprise a translation of a registry value used to configure a grouping of related Taskbar buttons in Windows®.

Under Windows XP ® the path of the registry value is: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\TaskbarGl omm ing" and registry values are: o -Never group 1-Always group Under Windows 7 ® the path of the registry value is: "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\TaskbarG lomL evel" and registry values are: o -Always group 1 -Group but hide labels 2-Never group According to an embodiment of the present invention, the configuration data comprises translation data which translates the Windows XP ® path to the Windows 7 ® path and vice-versa and the registry values thereof are also translated accordingly. For example, if a user set the registry value under Windows XP ® to be 1, i.e. "Always group", and logged off from the Windows XP ® environment, during a later logon process under Windows 7 ® environment, the logon process translates the path "HKCU\Software\Microsofi*Windows\CurrentVersion\Explorer\Advanced\TaskbarG lomming" to "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\TaskbarG lomLevel" and the registry value 1 to 0, i.e. "Always group", whereby the related Taskbar buttons are always grouped, regardless of whether the user logs on to Windows XP ® or Windows 7 ®.

Other settings can also be translated in this manner whereby the users are able to use various OS environments without having to set settings manually every time they log on to a different OS environment.

According to an embodiment, at the termination step 3900, the desktop is refreshed whereby the desktop setting applied and/or implemented is affected for view/use by the user.

According to an alternative embodiment, the termination step 3900 comprises execution of any further function, application or action which depends on the completion of the logon process 1550. Such further application may be a desktop custoniisation application which requires the registry data to be set by the user before the application can further implement its customisations to the settings.

According to an embodiment, once the setting and/or registry data has been applied/implemented to the client environment, at the termination step 3900 the desktop is refreshed and the client environment is informed of this application/implementation of the relevant desktop setting whereby a third-party application may also be informed of this application/implementation.

According to an embodiment of the present invention, there is provided a method for setting management wherein: a setting is set to one of shared mode or separate mode; and setting data related to the setting is communicated/stored/updated/maintained according to the mode. An administrator or a user can set each setting to be at least one of these modes and a mode indicator is added to relevant setting data, registry data and/or configuration data.

It is understood that according to an embodiment, a further mode such as off mode can also be set wherein a setting is set to the off mode by default until one of the other two modes are set. In such embodiment, a setting in the off mode is not treated as a managed setting.

The logoff process 1590 and the logon process 1550 according to the enibodiments described herein further comprises the steps of: determining whether an identified setting is in an off mode, a shared mode, or a separate mode; and accessing/obtaining, communicating, translating, storing, updating, maintaining, and/or applying the setting data thereof in the database, registry, configuration file, cache and/or container accordingly.

According to an embodiment, the administrator sets a setting to be at least one of these modes in the configuration data of the database 1120 on the server 1111. The administrator can configure the configuration data to be universal for all users/clients or to a specific group of users/clients. The administrator can also set a default mode for various settings. For example, settings with larger setting data may be set to the off mode by default, so that the setting data required for the embodiment of the invention can be reduced. Settings with varying degrees of compatibility across different OS environments may also be set to the separate mode by default as they are unlikely to be applicable and/or implementable in the shared mode.

If a setting is set to the off mode, the selective registry data access/obtaining step 2120 determines the setting to be not a managed setting and performs the logoff process 1590 steps accordingly. During the logon process 1550, if a setting is set to the off mode, the configuration data access step 3110 determines the setting to be not a managed setting and performs the logon process 1550 accordingly. According to an embodiment, the logon process 1550 applies and/or implements a system default for any setting set to off mode.

Suitably, the system default may be set by the administrator or the user, and may be client environment specific.

If a setting is set to the shared mode, the isolated setting determination step 2210 determines the setting to be not specific to the client environment and performs the logoff process 1590 steps accordingly. During the logon process 1550, if a setting is set to the shared mode, the shared setting determination step 3210 determines the setting to be a shared setting and performs the logon process 1550 steps accordingly.

If a setting is set to separate mode, the isolated setting determination step 2210 determines the setting to be specific to the client environment and performs the logoff process 1590 steps accordingly. During the logon process 1550, if a setting is set to the separate mode, the shared setting determination step 3210 determines the setting to be not a shared setting and the logon process 1550 proceeds to the isolated portion determination step 3320.

According to embodiments of the present invention, only the configuration data in the database 1120 on the server 1111 needs to be updated and then communicated to the configuration file 1140 on the client 1115 when an OS environment is updated and its related settings are affected by the update. This enables the administrator of the setting management method or apparatus to easily and quickly adopt any changes introduced by any updates to settings in the OS environment whereby the users of the embodiments of the present invention are provided with client environments which appear to seamlessly retain any settings made by the user regardless of the OS environment they are in.

According to an embodiment of the present invention, when a background colour setting is set to the separate mode and a user, who has not previously logged on to or off from any client environment which implements the embodiment, logs on to Windows 7 ® and sets the desktop background colour to green and logs off, since no previous Windows 7 ® data exists in the container and the shared portion is empty, setting data related to the background colour of green is accessed/obtained/read from the registry and stored/written to the shared portion after the shared value match step 2310 and the shared portion storage step 2320 of the logoff process 1590. This use of the shared portion even in the separate mode optimises capacity/space usage in the container. The isolated portion and the setting data storage therein is only used when the shared portion is not empty and the setting data to be stored is different from what is already in the shared portion. The container is then communicated to the database of the server during the container communication step 2150.

When the user then logs on to Windows XP © synchronisation 1500 occurs and, since the background colour setting is set to the separate mode, during the logon process 1550 the isolated portion determination step 3320 determines the background colour setting data to be not stored in the isolated portion for Windows XP © and proceeds to the shared portion access step 3310 whereby the background colour setting data for green is accessed/obtained/read.

The logon process 1550 then performs subsequent steps to apply the background setting of green which may also involve the translation step 3720 depending on the background colour setting compatibility between Windows 7 ® and Windows XP ®.

It is understood that according to an alternative embodiment, when the background colour setting is set to the separate mode, during the logon process 1550 the isolated portion determination step 3320 determines the background colour setting data to be not stored in the isolated portion for Windows XF ® and then determines whether there has ever been a previous logoff process 1590 performed under Windows XP ® environment. According to an embodiment of the present invention, this determination is made using an indicator which comprises a presence of a silo, a sub-container and/or a registry key such as an OS isolation key in the setting data and/or the container. The OS isolation key comprises a string such as "XP" or "W7" which can be used to identify a particular client environment whereon the previous logoff process 1590 was performed.

If no previous logoff process 1590 has been performed under Windows XP ® environment, i.e. there is no indicator or OS isolation key for the Windows XF ® environment present, the logon process 1550 applies default background colour setting data which may be different from that saved during the previous logoff process 1590 under Windows 7 ® environment. If there was a previous logoff process 1590 under Windows XP ®, then the logon process 1550 proceeds to the shared portion access step 3310 whereby the background colour setting data for green stored during the previous logoff process 1590 under Windows 7 ® is accessed/obtained/read. The logon process 1550 then performs subsequent steps to apply the background setting of green which may also involve the translation step 3720 depending on the background colour setting compatibility between Windows 7 ® and Windows XP®.

Whilst under Windows XP ® environment, the user then changes background colour to white and logs off. During the logoff process 1590, setting data related to the background colour of white is accessed/obtained/read from the registry and stored/written to the isolated portion for Windows XP ® after: the isolated setting determination step 2210 determines the setting to be specific to the Windows XP ® environment; the shared value match step 2310 determines there is no match with the setting data in the shared portion; and the background colour setting data for white is stored in the isolated portion 2420. This ensures in the future for the logon process 1550 onto Windows XP © environment, the background colour will be set to white (the isolated portion determination step 3320 for Windows XP ® and the isolated portion access step 3410) whilst for the logon process 1550 onto Windows 7 ® environment the background will be set to green (the isolated portion determination step 3320 for Windows 7 ® and the shared portion access step 3310).

If in the future the user logs on to Windows XP ® environment again and changes the background colour to green, the background colour setting data for white stored in the isolation portion will be removed during the shared value match step 2310 and whenever the user logs on to Windows XP © or Windows 7 ®, the shared portion will be accessed and the background colour of green applied.

According to an embodiment of the present invention, when a background colour setting is set to the shared mode and a user, who has not previously logged on to or off from any client environment which implements the embodiment, logs on to Windows 7 ® and sets the desktop background colour to green and logs off, the isolated setting determination step 2210 determines the setting to be not specific to the client environment and setting data related to the background colour of green is accessed/obtained/read from the registry and stored/written to the shared portion of the container at the shared portion storage step 2320 of the logoff process 1590. The container is then communicated to the database of the server during the container communication step 2150.

When the user then logs on to Windows XP ® synchronisation 1500 occurs and, since the background colour setting is set to the shared mode, during the logon process 1550 the shared setting determination step 3210 determines the background colour setting to be a shared setting and performs the logon process 1550 steps accordingly to proceed to the shared portion access step 3310 whereby the background colour setting data for green is accessed/obtained/read. The logon process 1550 then performs subsequent steps to apply the background setting of green which may also involve the translation step 3720 depending on the background colour setting compatibility between Windows 7 © and Windows XP ©.

When a setting is set to the shared mode, the same setting is applied to a plurality of client environments. It is understood that according to an embodiment, a fourth mode is provided wherein the administrator can specify a subset of client environments so that a particular setting is set to the shared mode for the subset of client environment only.

According to an embodiment, the setting data is stored and/or communicated in a binary file, namely container, which can be stored in the cache of the client and/or the database of the server. A user of the client is identified by a Windows® Security Identifier (SID) or any unique identifier so that setting data for each user can be identified separately. An exemplary hierarchy of setting data in a container might be:

REGISTRY

USER S ID>

--Control Panel [Setting data] --xP --Control Panel [Setting data] --W7 --Control Panel [Setting data] According to an embodiment, when a setting is in the separate mode any setting data related to the setting which is different from setting data stored in the shared portion will be written to the isolated portion. For example if the setting was set in Windows 7 ® environment and it differs from setting data stored in the shared portion, the setting data thereof would be stored in the isolated portion of "REGISTR Y->USER->SID-> WI'.

According to an embodiment, the setting data, the configuration data and/or the registry data are stored in a File Based Registry (FBR) file comprising registry keys and values whereby the setting data, the configuration data and/or the registry data are managed in a single file for access, communication and/or storage thereof. It is understood that the container may be an example of such FBR file.

In order to minimise the size of such FBR file, any data stored therein are encouraged to be stored in the shared portion of the FBR file so that minimum duplication occurs among the data stored in the FBR file.

The logon process 1550 and the logoff process 1590 provide for a setting set in the shared mode to be managed using the shared portion only so that unnecessary isolated portions and setting data stored therein are not stored in the FBR. The isolated setting determination step 2210 of the logoff process 1590 will determine the setting to be in the shared mode and proceed to store the setting data thereof in the shared portion. The shared setting determination step 3210 of the logon process 1550 will determine the setting to be in the shared mode and proceed to the shared portion access step 3310 whereby the setting data thereof in the shared portion is accessed and/or obtained. If the setting data for a setting set in the shared mode is not found in the shared portion, then the logon process 1550 proceeds to apply/implement a system default value/setting data for the setting set in the shared mode. It is understood that the system default value/setting data may be the registry data already present in the registry of the client or that set specifically by an administrator or a user.

The shared value match step 2310 of the logoff process 1590 enables a detection and/or minimisation of any duplication among the data stored in the FBR file. This embodiment of the present invention may be affected by following two algorithms implementing the logon process 1550 and the logoff process 1590 under the separate mode described herein.

-Logon algorithm: IF no host OS isolation key (first logon) Ignore value in FBR, take default

ELSE

IF host OS isolated setting data exists in FBR Take host OS isolated setting data and write to registry

ELSE

IF shared setting data exists in FBR Take shared setting data and write to registry

ELSE

Do nothing, take default

ENDIF

-Logoff algorithm: IF shared setting data not in FBR Write setting data to shared portion in FBR

ELSE

IF current setting data same as that in shared portion IF host OS isolated setting data in FBR Delete isolated setting data in host OS isolated portion in FBR

ENDIF

ELSE

Write setting data to host OS isolated portion in FBR

ENDIF

IF OS isolation key does not exist Create empty host OS isolation key in FBR

ENDIF

For a setting set in the separate mode, use of the presence of an OS isolation key in the FBR, i.e. presence of an isolated portion or a sub-container such as XP" or "W7" in the FBR, as an indicator of a previous logoff process being performed in a specific client environment provides for an efficient storage of such an indicator since the OS isolation key is not required to comprise setting data therein unless the setting concerned is in the separate mode and the setting data thereof is different from setting data stored in the shared portion.

The first OS isolation key detection step of the logon algorithm and the last OS isolation key existence determination step of the logoff algorithm enable the algorithms to distinguish between: setting data set by the user for a specific OS environment; and setting data stored in the shared portion from a previous logoff under a different OS environment. This then enables the OS isolation key detection step to access/obtain the default setting data when a user logs on to the current OS environment for the first time instead of the setting data stored in the shared portion.

For example, with desktop background colour setting set in the separate mode and no previous logoff having taken place in any OS environment, when a user logs on to Windows XP ® the desktop background colour is set to default setting, say blue. Then the user sets the background colour to red and logs off from the Windows XP ® environment, whereby during the logoff process setting data for red is stored in the shared portion of the container or FBR since there is no shared setting data stored is in the container. The OS isolation key existence determination step then also creates an empty, i.e. without registry value, Windows XP ® isolation key in the container. When the user then logs on to Windows 7 © environment, since the desktop background colour setting is in the separate mode and no previous logoff on Windows 7 ® has occurred, which is determined by the OS isolation key detection step wherein no Windows 7 ® isolation key is detected in the container, the default stetting of blue is applied as the desktop background colour. The user is then able to set any colour for the desktop background colour of Windows 7 ® environment, which may or may not be the same as that for the Windows XP ® desktop background colour.

If the same colour of red is set for the Windows 7 ® environment and the user logs off, the logoff process determines the setting data for red to be present in the shared portion and does not re-store the setting data for red. The OS isolation key existence determination step then also creates an empty Windows 7 ® isolation key in the container. When the user then logs on to Windows 7 ® environment again, the logon process determines the background colour setting to be in the separate mode and previous logoff on Windows 7 © had occurred.

The logon process also determines that no setting data is available in the isolated portion for Windows 7 ®, i.e. Windows 7 ® isolation key, and proceeds to access the setting data in the shared portion whereby the colour red is applied to the background.

If the user then sets the background colour to green in the Windows 7 ® environment, the logoff process stores the setting data for the green under the Windows 7 ® isolation key, whereby a future logon process performed on the Windows 7 ® environment accesses the setting data for green in the isolated portion to implement the background colour of green.

Should the user then sets the background colour back to red for the Windows 7 © environment and logs off, the setting data for green under the Windows 7 ® isolation key is deleted so that a future logon process performed on the Windows 7 ® environment accesses the setting data for red in the shared portion to implement the background colour of red as before.

According to an embodiment of the present invention, when a setting is set as a managed setting in the configuration file and any registry data and/or setting data for the managed setting, such as a registry key or a registry value, needs to be stored in the container or the FBR, the entire registry key comprising any sub-keys and/or values is copied over as a sub-container/OS silo of the container/FBR.

It is understood that according to an alternative embodiment of the present invention, when only a subset of registry values in a registry key requires storing in the container/FBR, rather than the entire registry key comprising all the registry values stored therein being copied over, only the registry key comprising the subset of registry values is copied over to the container/FRB as a sub-container/OS silo of the container/FBR.

Figure 5 shows an illustrative environment 1010 according to an embodiment of the invention. The skilled person will realise and understand that embodiments of the present invention may be implemented using any suitable computer system, and the example system shown in Figure 5 is exemplary only and provided for the purposes of completeness only. To this extent, environment 1010 includes a computer system 1020 that can perform a process described herein in order to perform an embodiment of the invention. In particular, computer system 1020 is shown including a program 1030, which makes computer system 1020 operable to implement an embodiment of the invention by performing a process described herein.

Computer system 1020 is shown including a processing component 1022 (e.g., one or more processors), a storage component 1024 (e.g., a storage hierarchy), an input/output (I/O) component 1026 (e.g., one or more I/O interfaces and/or devices), and a communications pathway 1028. In general, processing component 1022 executes program code, such as program 1030, which is at least partially fixed in storage component 1024. While executing program code, processing component 1022 can process data, which can result in reading and/or writing transformed data from/to storage component 1024 and/or I/O component 1026 for further processing. Pathway 1028 provides a communications link between each of the components in computer system 1020. I/O component 1026 can comprise one or more human I/O devices, which enable a human user 1012 to interact with computer system 1020 and/or one or more communications devices to enable a system user 1012 to communicate with computer system 1020 using any type of communications link. To this extent, program 1030 can manage a set of interfaces (e.g., graphical user interface(s), application program interface, and/or the like) that enable human and/or system users 1012 to interact with program 1030.

Further, program 1030 can manage (e.g., store, retrieve, create, manipulate, organize, present, etc.) the data, such as a plurality of data files 1040, using any solution.

In any event, computer system 1020 can comprise one or more general purpose computing articles of manufacture (e.g., computing devices) capable of executing program code, such as program 1030, installed thereon. As used herein, it is understood that "program code" means any collection of instructions, in any language, code or notation, that cause a computing device having an information processing capability to perform a particular action either directly or after any combination of the following: (a) conversion to another language, code or notation; (b) reproduction in a different material form; and/or (c) decompression. To this extent, program 1030 can be embodied as any combination of system software and/or application software.

Further, program 1030 can be implemented using a set of modules. In this case, a module can enable computer system 1020 to perform a set of tasks used by program 1030, and can be separately developed and/or implemented apart from other portions of program 1030. As used herein, the term "component" means any configuration of hardware, with or without software, which implements the functionality described in conjunction therewith using any solution, while the term "module" means program code that enables a computer system 1020 to implement the actions described in conjunction therewith using any solution. When fixed in a storage component 1024 of a computer system 1020 that includes a processing component 1022, a module is a substantial portion of a component that implements the actions. Regardless, it is understood that two or more components, modules, and/or systems may share some/all of their respective hardware and/or software. Further, it is understood that some of the functionality discussed herein may not be implemented or additional functionality may be included as part of computer system 1020.

When computer system 1020 comprises multiple computing devices, each computing device can have only a portion of program 1030 fixed thereon (e.g., one or more modules).

However, it is understood that computer system 1020 and program 1030 are only representative of various possible equivalent computer systems that may perform a process described herein. To this extent, in other embodiments, the functionality provided by computer system 1020 and program 1030 can be at least partially implemented by one or more computing devices that include any combination of general and/or specific purpose hardware with or without program code. In each embodiment, the hardware and program code, if included, can be created using standard engineering and programming techniques, respectively.

Regardless, when computer system 1020 includes multiple computing devices, the computing devices can communicate over any type of communications link. Further, while performing a process described herein, computer system 1020 can communicate with one or more other computer systems using any type of communications link. In either case, the communications link can comprise any combination of various types of optical fibre, wired, and/or wireless links; comprise any combination of one or more types of networks; and/or utilize any combination of various types of transmission techniques and protocols.

In any event, computer system 1020 can obtain data from files 1040 using any solution.

For example, computer system 1020 can generate and/or be used to generate data files 1040, retrieve data from files 1040, which may be stored in one or more data stores, receive data from files 1040 from another system, and/or the like.

Any of the steps in the methods described herein may be omitted or ordered differently in an alternative embodiment of the present invention.

It is understood that the configuration and/or settings data may be stored on a storage medium and transported to and from different components of the server 1111 or the client 1115 physically according to an alternative embodiment of the present invention. In such alternative embodiment, the storage medium may be a USB (Universal Serial Bus) memory stick or a memory card of some kind which the user carries with him or her and plugs into a USB or memory port whereby the configuration or settings data can be communicated between the server 1111 and the client 1115.

It is also understood that according to an embodiment, setting data relates to any data used for a setting management which may comprise a portion of the registry data, the configuration data, the mode data, the translation data and/or any other data used for accessing, obtaining, maintaining, preserving, translating, communicating, applying, and/or implementing the data thereof Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

CLAIMS1. A method for a desktop setting management comprising the steps of: maintaining, on a server, a container for storing setting data and a configuration file for storing mode data; synchronising the configuration file between the server and a client; synchronising the container between the server and the client; determining whether a setting is in a shared mode or a separate mode using the mode data; and managing the setting in accordance with the determined mode, wherein: the container comprises a shared portion and an isolated portion; the client runs a client environment whereon the setting is managed; the setting relates to desktop setting; the mode indicates whether a setting is specific to a client environment or not; the mode data indicates whether a setting is to be managed in the shared mode or the separate mode; the setting data is data used for the desktop setting management; the setting data is stored in either the shared portion or the isolated portion in accordance with the mode of the setting thereof; and the managing of the setting comprises at least one of: accessing, obtaining, maintaining, preserving, translating, storing, communicating, applying, or implementing the setting using the setting data.
2. The method of claim 1 further comprising a logoff process wherein the logoff process comprises the steps of: a logoff configuration data access step wherein configuration data is accessed; a registry data access step wherein registry data related to the setting is accessed; and storing setting data in the shared portion or the isolated portion of the container, wherein: the configuration data is stored in the configuration file; the registry data is stored in a registry of the client; the setting data comprises a portion of the registry data and/or the configuration data; the configuration data and/or the registry data is used to determine whether the setting data is to be stored in the shared portion or the isolated portion; the synchronising of the configuration file comprises communicating the configuration file from the server to the client; and the synchronising of the container comprises communicating the container from the client to the server.
3. The method of claim 2 wherein the logoff configuration data access step comprises the steps of: parsing the configuration data; and identifying a setting whereto each parsed configuration data relates, and the registry data access step comprises the steps of: determining whether the identified setting is a managed setting or not using the configuration data; and if the identified setting is a managed setting, accessing the registry data related to the identified setting in the registry, wherein the managed setting is a setting to be managed with the method for setting management.
4. The method of claim 3 further comprising a step of client environment applicability determination wherein applicability of the identified setting to a client environment on the client is determined whereby only the identified setting applicable to the client environment is considered for the registry data access step.
5. The method of claim 3 or 4 further comprising a step of isolated setting determination wherein a determination is made as to whether or not the identified setting is specific to the client environment, whereby: if the identified setting is not specific to the client environment, the identified setting data is stored in the shared portion; and if the identified setting is specific to the client environment, a shared value match step is performed wherein the identified setting data is compared with setting data stored in the shared portion so that: if the shared portion is empty, the setting data is stored therein; if the shared portion is not empty and the identified setting data is different from the setting data stored in the shared portion, the identified setting data is stored in the isolated portion; and if the shared portion is not empty and the identified setting data is the same as the setting data stored in the shared portion, storing an indicator that the identified setting data for the client environment is stored in the shared portion.
6. The method of claim 5 wherein the shared value match step further comprises the steps of: removing setting data stored in the isolated portion if the identified setting data is the same as the setting data stored in the shared portion; and storing an indicator that the identified setting data for the client environment is stored in the shared portion.
7. The method of claim 5 or 6 wherein: if the identified setting is in the shared mode, the isolated setting determination step determines the identified setting to be not specific to the client environment; and if the identified setting is in the separate mode, the isolated setting determination step determines the identified setting to be specific to the client environment.
8. The method of any preceding claim further comprising a logon process wherein the logon process comprises the steps of: a logon configuration data access step wherein configuration data is accessed; a setting data access step wherein the setting data is accessed; and applying setting to a client environment using the accessed configuration data and the accessed setting data, wherein: setting application step comprises applying registry data to a registry of the client; the configuration data is stored in the configuration file; the setting data is stored in the container; the setting data is data used for the setting management and comprises a portion of the registry data and/or the configuration data; the configuration data and/or the setting data is used to determine whether the setting data is stored in the shared portion or the isolated portion; the synchronising of the configuration file comprises communicating the configuration file from the server to the client; and the synchronising of the container comprises communicating the container from the server to the client.
9. The method of claim 8 wherein the setting data access step comprises the steps of: parsing the configuration data; and identifying a setting whereto each parsed configuration data relates, and the logon process further comprises a step of client environment applicability determination wherein applicability of the identified setting to the client environment is determined whereby only the identified setting applicable to the client environment is considered for the setting application step.
10. The method of claim 8 or 9 wherein the setting data access step further comprises the steps of: a shared setting determination step wherein a determination is made as to whether or not the identified setting is a shared setting or not; an isolated portion determination step wherein a determination is made as to whether the identified setting data is stored in the isolated portion or not; a shared portion access step wherein if the shared portion is not empty, setting data in the shared portion is accessed, and if the shared portion is empty, a default setting data is accessed;and an isolated portion access step wherein setting data in the isolated portion is accessed, wherein: if the shared setting determination step determines the identified setting to be a shared setting, the shared portion access step is performed; if the shared setting determination step determines the identified setting not to be a shared setting and the isolated portion determination step determines the identified setting data is in the isolated portion, the isolated portion access step is performed; and if the shared setting determination step determines the identified setting not to be a shared setting and the isolated portion determination step determines the identified setting data is not in the isolated portion, the shared portion access step is performed.
11. The method of claim 10 wherein: if the identified setting is in the shared mode, the shared setting determination step determines the identified setting to be a shared setting; and if the identified setting is in the separate mode, the shared setting determination step determines the identified setting to be not a shared setting.
12. The method of any one of claims 8 to 11 wherein, when a change is made to a setting, the method further comprises the steps of: storing setting data relating to the setting change in either the shared or the isolated portion of the container in accordance with the mode data; and communicating the container from the client to the server whereby the container on the server is up-to-date with the setting change made at the client.
13. The method of any one of claims 8 to 12 wherein the synchronising of the configuration file comprises communicating the configuration file from the client to the server.
14. The method of any one of claims 8 to 13, wherein the setting application step comprises the steps of: determining whether the accessed setting data is compatible with the client environment; if the accessed setting data is compatible, applying the setting data; and if the accessed setting data is incompatible, performing further steps of: accessing the configuration file for translation data for the setting; if no translation data for the setting is available, applying default setting; and if translation data for the setting is available, translating the setting data using the translation data and applying the translated setting data to the setting, wherein: the configuration file indicates whether the setting data is compatible or not; the configuration data comprises the translation data; and the translation data comprises a mapping information whereby an incompatible setting data is mapped to a compatible setting data for the registry of the client.
15. The method of any preceding claim wherein the mode data is used to indicate an off mode, wherein the off mode indicates that a setting is not a managed setting.
16. The method of any preceding claim wherein: the container is a binary file or a File Based Registry file; and the configuration file is an XML configuration based file.
17. The method of any preceding claim wherein the client environment relate to different versions of operating system.
18. A system comprising: a server configured to maintain a container for storing setting data and a configuration file for storing mode data; and a client configured to determine whether a setting is in a shared mode or a separate mode using the mode data and manage the setting in accordance with the determined mode, wherein the system is configured to: synchronise the configuration file between the server and a client; and synchronise the container between the server and the client, wherein the managing of the setting comprises at least one of: accessing, obtaining, maintaining, preserving, translating, storing, communicating, applying, or implementing the setting using the setting data; the container comprises a shared portion and an isolated portion; the client runs a client environment whereon the setting is managed; the setting relates to desktop setting; the mode indicates whether a setting is specific to a client environment or not; the mode data indicates whether a setting is to be managed in the shared mode or the separate mode; the setting data is data used for the desktop setting management; and the setting data is stored in either the shared portion or the isolated portion in accordance with the mode of the setting thereof.
19. The system of claim 18 configured to implement a logoff process at the client wherein the logoff process comprises the steps of: a logoff configuration data access step wherein configuration data is accessed; a registry data access step wherein registry data related to the setting is accessed; and storing setting data in the shared portion or the isolated portion of the container, wherein: the configuration data is stored in the configuration file; the registry data is stored in a registry of the client; the setting data is data used for the setting management and comprises a portion of the registry data and/or the configuration data; the configuration data and/or the registry data is used to determine whether the setting data is to be stored in the shared portion or the isolated portion; the synchronising of the configuration file comprises communicating the configuration file from the server to the client; and the synchronising of the container comprises communicating the container from the client to the server.
20. The system of claim 18 or 19 configured to implement a logon process at the client wherein the logon process comprises the steps of: a logon configuration data access step wherein configuration data is accessed; a setting data access step wherein the setting data is accessed; and applying setting to a client environment using the accessed configuration data and the accessed setting data, wherein: setting application step comprises applying registry data to a registry of the client; the configuration data is stored in the configuration file; the setting data is stored in the container; the setting data is data used for the setting management and comprises a portion of the registry data and/or the configuration data; the configuration data and/or the setting data is used to determine whether the setting data is stored in the shared portion or the isolated portion; the synchronising of the configuration file comprises communicating the configuration file from the server to the client; and the synchronising of the container comprises communicating the container from the server to the client.
21. A computer readable medium storing a computer program to operate a method according to any one of claims 1 to 17 or a system according to any one of claims 18 to 20.
22. The method, the system or the computer readable medium as substantially described herein with reference to the accompanying drawings.