CZ20004081A3 - Client-server system for maintaining application preferences in a hierarchical data structure according to user and user group or terminal and terminal group contexts - Google Patents

Abstract

In a system with a network (100) connecting the server (110) and the amount user stations, the system administrator (108) models system users or user groups, terminals and a group of terminals, as a hierarchy, and sets up the desktop and user application settings for each group and pro individual users. For the selected group context, for example, a group of all system users or one Well, a subgroup under the group that represents all user, the default setting group is specified for the selected user user application. The default group is then modified setting that is specifically specified in the selected group. This setting can then be adjusted by the group again settings that belong specifically to the user.

Description

CLIENT-SERVER SYSTEM TO MAINTAIN APPLICATION SETTINGS IN THE HIERARCHIC DATA STRUCTURE ACCORDING TO THE CONTEXT OF THE USER AND USER GROUP OR TERMINAL AND TERMINAL GROUP

Technical field

The invention generally relates to the fields of personal computers and networks. It relates in detail to a new and evolving area of computer networks in which workstation users use a PC, possibly diskless, connected to a network such as a corporate intranet, the Internet, or a network or Internet service provider (ISP) to gain access to they are then run on a desktop computer. More specifically, the invention relates to server storage with software settings (configuration data) for software retrieved from the server and running on a desktop computer.

BACKGROUND OF THE INVENTION

The computer network area is still in its infancy. However, its rapid development is expected, especially in the corporate environment, for several reasons. It is expected that once companies and possibly individual users have reached hardware and software update points, moving to this new area is more efficient and cheaper than updating traditionally with disk-equipped computers and locally stored and managed software applications. For example, in a corporate environment, a user may be connected to a company intranet, for example, using Internet TCP / IP protocols

80,754 • · *

9 HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP The advantage of this configuration is that computers on the network are considerably cheaper than traditional disk-equipped computers, and it could also be cheaper to buy the required number of program licenses for users rather than buying individual Of course, software management problems that accompany a large number of business users will be significantly reduced, and today each user is often a system administrator on a disk-equipped computer or workstation, a role that often consumes more resources lack of experience it is a great advantage to overcome this problem by effectively relieving the problem for a small number of server management experts rather than letting many users struggle with software installation, update and computer management issues.

As mentioned above, this vision of future personal computers is currently in its infancy. As a result, there are currently many problems and shortcomings in existing systems.

Typically, in network computer systems, an administrator creates user profiles that are stored on a network server. Profiles can contain different types of information, such as user desktop settings and user rights to access various program applications that may be on the server. Once a user logs on to the system, he identifies himself on the server, finds the profile for him, and transfers it to his computer, where he is used to configure the computer and generate the desktop.

·

The workspace can contain many icons representing applications that the user is likely to have access to. The profile may also contain other computer and desktop attributes, such as color, desktop background, or fonts and font sizes in dots used on the desktop, or a list of searchable file locations (list of paths, etc.) that are unique to users . Profiles can be user editable or uneditable.

In an environment in which users can change their own profiles, the modified profile is uploaded back to the server at logoff time, where it is stored for retrieval the next time the user logs on. In some prior art systems, according to the state of the art, users can generate on their desktops any combination of application icons they want, whether or not they exist on the server, and whether or not the user actually has permission to access the application on the server . Lotus Workplace Desktop (formerly called Acting Desktop) is an example of this type of work. On other systems, the server will offer the user a list of all the applications the server has from which to choose. In this case, there is no guarantee that the user actually has permission to access the application that is selected from the list for inclusion on the desktop. Sun Hot Java Views is an example of this type of system. In other words, prior art systems do not monitor the relationship between what a user is allowed to set for a group of application icons on the desktop and applications that the user has the right to access. In this case, when the user clicks the application launch icon, an error message (such as an unauthorized access message) may appear if access permission is not present, or worse

• · · φ

• · ♦ 4 4 4 4

The user's computer may crash.

Another limitation in the existing field is that a flat data structure is used to model users, user groups, terminals, and terminal groups. Following a common user access management scheme for computing resources, known computer implementations (such as Lotus Administration Facility for Desktops, Microsoft Windows NT Profiles and Policies, and Sun Hot Java Views) implement a flat group structure on the program settings management server (or attributes) in different contexts. A context as used herein refers to an individual user, a group of users, a terminal, or a group of terminals. Any grouping structure for managing software settings on the server allows the administrator to define setup attributes for different user groups as well as for individual users. However, flat systems are inflexible in many environments, especially in environments that have a large number of users. It is desirable to provide an administration tool to support the organization of information in a hierarchical structure.

Another limitation of existing systems is that they are limited so that administrators and users have to make custom workstation desktop settings. For example, administrators are currently required to configure user settings using configuration programs that are separate from the user application but associated with the user application. It is desirable to allow vendors to provide only one application. To require only the end user application from the vendor, the central management feature must be able to run the end user application in the user context, or «· Skupiny • ·« user groups. The prior art does not allow this administrative flexibility of work. In other words, in the prior art, an administrator has no ability to run a user application in the user context to set options for that user and application. Further, in the current state of the art, an administrator cannot run a user application to set options in the context of a user group.

Another limitation of the prior art known to the inventors is the way in which the prior art divides the permanent storage space of the server to ensure that a unique space is reserved to store user settings related to various applications on the server. According to the inventors' knowledge, the problem of preventing collisions in information storage with settings for different applications in object-oriented systems in which an object can be queried for its fully qualified class name that uniquely identifies it and distinguishes it from other classes is solved by For example, Seller A could be assigned Seller A from the first organ, and the uniqueness of this designation is guaranteed in the architecture for which the first organ is active. The second authority at Seller A then assigns a second designation for each of its applications in this architecture. For example, one app vendor A may be labeled vendor A. appl; another can be labeled sellerA.App2. This technique maps a unique designation for each application in the system to a location in the system's permanent storage to ensure that data with settings for different applications in the storage does not collide. App once sale ce, label

it runs, informs the network computer server of its unique storage location, and it is the responsibility of the server to divide the region at the start by context (user, user group, terminal, or terminal group) to store setup information so that it does not interfere with setup information in another context. Of course, this way of managing storage is awkward and unwanted. It is desirable to develop a method of automatically generating unique storage locations with settings for the above object-oriented applications without requiring central authorities to assign unique labels to avoid collisions in the storage of settings information and without encoding storage location information device into the application.

Another limitation in the art is the lack of any measure to move existing applications and hardware into a new centrally managed world of networked computers without requiring changes to existing hardware and applications. Existing hardware, such as a terminal in a network environment, obtains its configuration information when booting from a file in a specific format located on the server. The terminal is programmed to know how to access its configuration file. The terminal uses a unique identifier to access the file from the server. The unique identifier is often the terminal media access control address (MAC address). However, in a new centrally managed environment containing protocols and APIs other than those for which the terminal is designed, the terminal cannot access setup information in the new environment, the terminal can only access its configuration file in the way it is designed. This is a serious problem, as many such existing devices are used. The inability to use them in new systems substantially prevents users from moving to new systems.

Another limitation in the prior art contemplates the interface between an administrator and a configuration management system. When configuring the software in the administrative means to configure the setting information for different users and user groups and terminal terminals, the administration software runs the user, terminal, or group set by the administrator who runs and the groups in the context (user, terminal) of the resources. Once the administrator changes the context in which the application is running, you need to reboot the settings with the settings for the new context, restarting the software after each time the administrator context changes, time consuming and inconvenient, on systems with many users.

expects the administrator to change contexts many times when configuring the application.

application because of

The process is especially for

In these systems,

SUMMARY OF THE INVENTION

In one aspect, the present invention provides, in a network system comprising a network connecting a server and a plurality of user stations, wherein the server stores a plurality of user applications for download to user stations, a method of managing user configuration settings for applications running on the user station. system in a tree hierarchy consisting of a group node

AllUsers, comprising all users of the system, and a plurality of filial group nodes, each comprising a selected one of the users belonging to the group represented by the filial group node, each node including configuration settings for a selected of the applications available in the system; assigning group priority order to each user who is a member of more than one group; with respect to any given user requesting to run the selected application, determining the priority order of the groups for the user; and assembling the configuration setting group from the tree by determining the first group from the group priority list from which the setting group for the selected application can be derived; merging the settings into a group for the selected application by browsing the tree from the AllUsers group node to the first group; merging the settings specified on each node for the selected application; and adjusting the collected settings as each node passes through the settings specified in that node for the selected application.

According to a second aspect, the invention provides, in a network system comprising a network interconnecting a server and a plurality of user stations, wherein the server stores a plurality of user applications for download to user stations, a device for managing user configuration settings for applications running on the user station. all system users in the tree hierarchy consisting of a AllUsers group node containing all system users and a plurality of filial group nodes, each containing a selected user belonging to the group represented by the filial group node, each node containing settings for the selected application available in the system; means for assigning group priority order to each user that is a member of more than one group; due to β ·

to any given user requesting the launch of the selected application, means for determining the priority order of the groups for the user; and means for assembling the configuration settings group from the tree by determining the first group from the list of group priorities from which the settings group for the selected application can be derived; merging the settings into a group for the selected application by browsing the tree from the AllUsers group node to the first group; collecting the settings specified on each node for the selected application; and adjusting the collected settings as each node passes through the settings specified in that node for the selected application.

According to a third aspect, the present invention provides a computer program product stored on a computer readable storage medium for, when running on a computer, executing on a network system comprising a network interconnecting a server and multiple user stations, wherein the server stores a plurality of user applications for download to user stations. user settings for applications running on a user station, the method comprising the steps of: representing all system users in a tree hierarchy consisting of an AllUsers group node that includes all system users; and a plurality of filial group nodes each containing a selected user belonging to a user groups represented by the filial group node, each node including configuration settings for selected from applications available in the system; assigning group priority order to each user who is a member of more than one group; with respect to any given user requesting to run the selected application, determining the priority order of the groups for the user; and constructing the configuration settings group from the tree by determining the first group from the group priority list, which group may be a group of configuration settings.

4 4 settings derived for the selected application; merging the settings into a group for the selected application by browsing the tree from the AllUsers group node to the first group; collecting the settings specified on each node for the selected application; and adjusting the collected settings as each node passes through the settings specified in that node for the selected application.

The system described here provides a common repository for configuration information for users and applets in a client-server environment. This is called managing client profiles. The system allows users to change computers (roaming), that is, log in at any time from any computer in the system and have it set up automatically at runtime according to the settings stored for users on the server. The preferred embodiment is a Java-based system (Java is a trademark of Sun, Inc.), and client computers use a web browser interface arranged to run Java applications. Thus, in a preferred embodiment, it is assumed that the user applets and the desktop applet are Java applets. However, it is not intended to limit the invention to the Java environment. The settings for locally stored applications could be stored locally in a traditional way, while the settings for server applets could be handled as described herein.

The invention allows the system administrator to model system users, or user groups, terminals, and terminal groups as a hierarchy, and to set the desktop and user application settings for each group and for each user separately. For the selected group context, say a group of all users of the system, or a subgroup that contains a group of selected users, the default setting group for the selected • group is specified.

9 9 9

9 9 9 9 9 9 9 9 9 99 9 9 9 user applet. The default group is then adjusted according to the settings that are specifically listed in the selected group. This setting is then adjusted again by a group of settings that belong specifically to the user.

In a preferred embodiment, all system users are represented in a tree hierarchy consisting of an AllUsers group node containing all system users and a plurality of filial group nodes, each of which includes a group of selected users belonging to the group represented by the filial group node. Each node also contains configuration settings for the selected application available on the system. The administrator assigns a group priority order for each user who is a member of more than one group. Once the application is launched by the user, the application requests its settings from the server. First, the order of group priorities for users is determined. Then, the configuration settings group is assembled from the tree by specifying the first group from the group priority list from which the settings group for the selected application can be derived, and then the settings are merged into the group for the selected application. Merging is performed by browsing the tree from the AllUsers group node to the first group, collecting the settings specified in each node for the selected application and modifying the collected settings as each node passes through the settings specified in that node for the selected application.

The invention provides much more organizational flexibility and administration capabilities than a non-hierarchical structure can offer. The hierarchical structure can more accurately describe the organization of most companies. The larger the modeled society, the more important is the ability to organize hierarchically.

BRIEF DESCRIPTION OF THE DRAWINGS

DETAILED DESCRIPTION OF THE INVENTION The invention will be explained in more detail with reference to the drawings, which show an exemplary network and a user station comprising an administrator station, to which the invention can perform an exemplary block diagram of an administrator station. provision and administration Fig. 3 exemplary hierarchical organization of user groups and system users. An exemplary hierarchical organization could also include individual terminals and groups of terminals; however, these are omitted for simplicity in Fig. 4, a single list of individual users and group priority order, which is used to determine a group of settings from the hierarchical organization of Fig. 3 that relate to a user and a specific application run by the user. the administrator and server of FIG. 2;

giant.

sample view of user terminal, application and components

software objects on the user API containing between the application and others that cooperate to establish the user settings while executing the application at the user terminal;

7 to 8 illustrate exemplary operations both on the user terminal and on the user login server and initial user desktop creation, including user settings;

9 to 11 of an exemplary terminal, for administration to log on a work operation both on and on the user-administrator server, establishing an administrator's desktop, and, for example, selecting an application and configuration context; the example also illustrates the context change during the user's desktop configuration and the resulting operation; and FIGS. 12-24 of the various actual captured screens of an administrator at various stages of application management, including building the hierarchy shown in FIG. 3 for example representation, creating and deleting users, etc. establishing application settings for applications and changing context when setting up settings.

DETAILED DESCRIPTION OF THE INVENTION

The system described here provides a common storage for ·· 4 ··

configuration information for all users and applets in a client-server environment. This is called managing client profiles. The system allows users to change. station (roaming), that is, log in at any time from any computer in the system and have it set automatically at startup according to the settings stored on the server. The preferred embodiment is a Java-based system (Java is a trademark of Sun, Inc.), and client computers use a Web browser interface arranged to run Java programs therein.

The terms applet and serviet are well-known terms in the Java programming language and will be used herein because these terms are of interest to those skilled in the art. Applet refers to an independent software module that runs in a web browser with the ability to execute Java code. Serviet refers to a software module located on a Java-enabled Web server. It is to be understood that the use of the terms applets and serviets is not intended in any way to limit the invention. Configuration applet here refers to a software module used to configure settings for an end user program application, such as a word processor, database manager, etc. Because program applications are also Java applets, the phrase user applet or just an applet is used to end user application designation.

In a preferred embodiment, the user applets and the desktop applet are assumed to be Java applets. However, it is to be understood that the invention is not limited to a Java environment. The invention can be used in any client-server system. For example, if desired, the system could be designed to use its own communication protocols and applications • · · · · 9 ·

* 9 written and compiled in any desired programming language. Further, even in a preferred Java-based environment, disk computers could access some applications locally and other applets from the server. The settings for locally stored applications could be stored locally in a traditional way, while the settings for server applets could be handled as described here. Preferably, however, the settings for locally stored applications are stored on a server using the Profile Management Properties API, in addition to the settings for the server applets described herein.

A simple application programming interface (API) allows applets written for the API to easily store and retrieve settings data once the applet is started by a user or administrator. Applet rights and user settings can be defined based on group membership and individual identity.

Client profile management includes the following services:

Login support - mapping to user profile;

User support - the ability of an administrator to create user identifications and provide services and settings directly to users;

User group support - the ability of an administrator to create hierarchical user groups and provide services and settings based on group membership;

Transparency of the user's applet context automatically determines the context of the user's applet execution. That is, specifying user and / or group profiles that relate to running the user applet and automatically creating the profile environment;

User Applet Settings Context Contextual • tt tt tt • tt server storage for user applet settings data;

Dynamic inheritance of user-applet settings hierarchical merging of user-applet settings when loaded by the object-oriented inheritance principle; and

User Applet Access Control - Manage user applet execution based on standard rights through group membership. The administrator can override the default group settings and allow or deny additional access rights for individual users.

Profile management provides a framework for these actions. Some actions are directly supported by profile management, such as user / group management, applet list, context switching, setting inheritance, etc., while user-applet-specific configuration services are usually supported by special configuration applets invoked by the system administrator in the client profile management environment. Some end user applets may provide configuration capability as part of end user applets. If this is the case, the administrator can run the end user applet (as opposed to special configuration applets) in the context of individual users and groups to set the configuration settings for those users and groups.

Giant. 1 shows one rough illustration of a proposed environment for carrying out the invention. The network 100 is provided for interconnecting a plurality of user stations such as desktop personal computers 102, mobile laptop computers 104, workstations 106 (eg, RISC computers), administrator stations 108, and server 110. In one embodiment, network 100 could be a local area network. In another embodiment, the network could 100 • 0 0000 • · · • 00

0 0

0 0

0 • 0 00 00

00 00 00 00

0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0

000 000 0 · ·· include enterprise communications for entities such as companies that have geographically spaced branches that are still included in the system. It is not intended to limit the environment in which the invention may be practiced; in fact, a network of any type that connects many types of stations is foreseen.

A rough diagram of the profile management work environment is shown in FIG. 2. The administration client network computer 200 is shown on the left in the figure and the server 202 for the system is on the right. The client and server communicate through the network shown as 203. The specific example of Fig. 2 assumes that the client computer is a system administrator's computer.

The client-side profile manager 206 allows the administrator to configure user applets both at the user and group level. The administrator can create new users and group hierarchies, add users to different groups, specify applet rights for each group and for individual users. And the administrator can configure the applets in the context of an individual user or group. Administrators can add, remove, and reset passwords for users. Profile management support is transparent to general users. The administrator can invoke the profile manager 206 in the context of any user or group. Only the administrator is out of his context for managing client groups. The server will not allow a user without administrative authority to switch context. When a request comes to the server, it asks for a verified user ID trying to access this feature. If the user does not have administrative privileges (ie, he is not a member of the AllUsers.Admin group), the profile manager serviet 214 can switch (users) and

214 rejects the request.

The profile manager 206 invokes other applets, such as the applet 208, as shown in FIG. 2. In this example, the applet could be an administration applet for configuring user desktop settings. Or, the configuration utility applet could be tied to an end user applet, such as editors, word processors, databases, etc. It is preferred, but does not require, that configuration applets such as 208 exist as modules separately from their corresponding user applets. In the context of Fig. 2, Applet1 is typically a configuration applet for a user applet; the administrator runs the applet configuration applet under the group context to set group settings and default rights or in the user context to customize user applet configurations for individuals. Implementing the appletl as a module separate from its user applet improves performance because the configuration applet appletl is likely to be smaller compared to the user applet. Separate configuration applets also allow the administrator to control the ability of end users to configure the user applet.

Traditional standalone computers store user applet settings information locally. in conjunction with the user applet. Traditional standalone Java-based computers store user applet configuration information in the format provided by the java.util.Properties class. Both layouts require the user applet to specify the name of the local file where the configuration information related to the user applet is to be stored. In other words, the relationship between the computer and the user applet is required

on him. Profile management as described here provides the familiar functionality of the real java.util.Properties object, plus other features that support user roaming and the ability to use it as an add-on in the powerful administration framework (Profile Manager).

ProfileManagementProperties P 210 is an appletl property object and provides an API between the Appletl applet and the server, allowing the server to specify where to store the settings information for the appletl in the context of users and groups. The ProfileManagementProperties object class provides all the functionality of the java.util.properties class with the additional ability to create, store, and retrieve software configuration information from persistent storage. Storing this information in a central location allows you to manage user and group configurations.

Once the user is an administrator, ProfileManagementProperties 210 allows the administrator to configure the user applet according to the appletl configuration applet, or configure the appletl if the applet is an end user applet, and store the configuration information in the correct location on the server in the correct context. This makes it possible to establish a relationship between a user applet and a user rather than a user applet and a computer, as in traditional systems. ProfileManagementProperties 210 is an add-in to the java.util.Properties class. This add-on allows you to associate key / value pairs with information about setting the Properties object to a key, unlike a stream, like java.util.Properties. This in turn allows application developers to use the key to specify a unique location relative to the context for the setup information, rather than using the file name and path. ProfileManagementProperties 210 automatically determines the key. The generation of a new key is described in more detail in Figures 8 and 9. evaluating the default class settings. Thus, this extended class offers a standard group setting function by accumulating settings starting from the current context as described in Fig. 3 and scrolling up the context hierarchy and searching for the default settings.

Server user user

202 includes a database 212 that stores data and group data such as and group settings and access rights to user applets. Web server 218 represents a typical web server supporting Java applets. The profile manager Serviet 214 associates user and group identifications with the setup data. It also maintains an access control list to manage user access to applications on the server.

User and group settings are stored in the tree structure as shown by the system automatically in Fig. 3. All users belong to the top AllUsers group. All users belong to the AllUsers group; this group contains default settings for some or all user applets on the server. In Figure 3, it is assumed that the server includes at least four user applets, designated App3, App4, App5, and Αρρβ. As stated in the AllUsers group, the default background (BG) for App3 is blue, BG = blue. Another exemplary setting designated as x, y, and z is shown to have default values of 1, 2, and 3, respectively. The terms x, y and z are intended to represent any desired setting and the values 1, 2 and 3 are arbitrary and used only to explain the principle. For example, the x setting could be the font used on the desktop screen; value

χ = 1 could point to the default Times-Roman font. Similarly, the default setting for App4 for all users is BG = gray, x = 2, y = 2, and z = 2.

The default values in the AllUsers group can be changed in any way you want for other contexts, such as other user groups and individual users. As an example, in addition to the AllUsers context in Figure 3, four other groups (GroupX, GroupY, GroupY1, and GroupY2) are shown. In addition, two users, User1 and UserN, are shown. Users can be members of more than one group. In Fig. 3, User1 is a member of AllUsers, GroupX, and GroupY1; UserN is a member of AllUsers and GroupY2. If a user is a member of more than one group (other than AllUsers), then the groups are sorted by priority to select the settings for that applet for that user. The administrator sets group priorities for users. The priority of the group is shown in Fig. 4. In Fig. 4, the User1 has a GroupX group (marked complete with its group with the highest User1 with the next highest (AllUsers.GroupY.GroupYl).

called AllUsers.GroupX as a priority. User group priority is the GroupYl group

The user1 lowest priority group is the AllUsers group. When a user, e.g., User1, requests to run an applet, e.g., App3, the settings are merged from the tree of Fig. 3 according to the group or groups to which the user belongs and the user applet is configured accordingly on the user's desktop.

The first step in collecting settings for any context is to get default values. The default values for users, if any, are the merged settings group for the applet from the highest priority group from which you can get

· · · · · · · · · · · · · · · ·

Β · • · β φ information with the settings for the applet. The default setting for a group, if any, is the merged group setting for (ie, the AllUsers group is the parent If the group does not have the parent AllUsers at the top level), the applet from the group's AllUsers.GroupX group) When merging settings for the applet in context, overrides the settings for the applet explicitly stored in context, the default settings for the context applet, thus recursively calling from each group node upwards to the group to gather the settings to the default group for the applet in the context of the group. An example is shown in Figure 3. For example, if the context is Allusers.GroupY.GroupYl, the parent of GroupYl, which is GroupY, is called, requesting its default settings for the applet : GroupYl Executes Recursive Vol it your parents, which is AllUsers.

The AllUSers group has no parent groups, so AllUsers returns its group settings for the GroupY applet call. This settings group is changed by the settings stored in the GroupY group for the applet, if any. This is now the default settings group for the GroupYl context applet. This group of default settings is returned to GroupYl as the default values of the GroupYl recursive call to GroupY, and are adjusted by the settings in the GroupYl group for the applet, if any, to become the current group of settings to apply to this instance. A group of settings for a user context is built in the same way, except that the highest priority group from which information with user settings can be obtained is first used to create a group context from which the default values are obtained. Then, the recursive procedure described above is used to build the current set of settings for the user and the applet requested by the user.

The following examples illustrate the above merging settings and belong to Figure 3.

Example 1: The administrator runs the configuration applet for App3 to set the settings for the AllUsers.GroupX group.

To configure the App3 configuration in the Allusers.GroupX context, you need to identify the settings group present. The AllUsers.GroupX group requires default values for its AllUsers parent group. Because AllUsers is a top-level group, it returns its settings for App3 to the GroupX group. These are the default settings for App3 in the GroupX context. Since GroupX has no settings for App3, the default group from Allusers is the actual group of settings to use. In this example, these settings from the AllUsers group are as follows: BG = Blue, x = 1, y = 2, z = 3. The administrator can now modify the merged settings using the configuration applet in any way you want.

Example 2: User1 requests to run com.ibm.App3. The setting must be merged for com.ibm.App3 in the User1 context.

Giant. 4 shows that the group with the highest priority for User1 is the AllUsers.GroupX group; this branch of the group hierarchy will be verified as soon as possible with the setup information related to App3. Hence the example is basically

same as Example 1 above, except that the collected settings group is used to set App3 on the user's workstation. The settings for App3 for Userl users are: BG = Green, x = 1, y = 2, z = 3 because BG = Green settings stored in User3 context for App3 outweigh the default BG = Blue settings obtained from the AllUsers.GroupX tree branch with setting.

Example 3: Merging settings for com.ibm.App6 in the context of User1.

This example illustrates a situation where the highest priority group does not contain any merged settings for the User1 context. The group with the highest priority for User1 users is again the GroupX group. This group and its AllUsers parent group have no settings for App6. Therefore, it is sought in the next group with the next highest priority. Another group with the highest priority for User1 users is the GroupYl group. The settings group can be obtained from this group for App6. The merging of settings continues as described in Example 1. A recursive call is made from the GroupYl group upwards through the tree to the AllUsers root group, and the setting groups are rolled back by recursive calls and changed to create a default group. The default group is then modified by the settings stored in the GroupYl group to create a merged group of settings that apply to this context. In short, the Allusers group returns an empty setting group because it has no settings for App6. GroupY modifies this empty group by a = 1 and b = 2 and returns this group to GroupYl as a standard group. The GroupYl group modifies the default group by a = 33. This group is returned to the Userl context for use as its φφφφφβββ * * * *lllllll Userllllφφ φφφφφ φφφφφφφ φφφφ φφφφφφφφ φφφ φφφ φφ φφ default group. Because there is no setting for App6 stored in the User1 context, the default values obtained from the GroupYl branch of the settings tree represent a fully assembled set of settings for App6. Therefore, the actual set of settings will be in this context a = 33, b = 2.

The above 3 examples described merging settings in response to the load () execution of a software package. If the setting information is stored for the software unit, any setting that has been explicitly written in the stored context is stored in the data storage 212 at a location determined by a combination of the context in which the software runs and the keys for the software whose settings are stored.

The rights work similarly: the new group has access to all the applets allowed by the group itself, and also to all the applets allowed by its parent groups. However, just as Java allows the programmer to override the parent class method, the profile manager allows the system administrator to override the inherited right. This is called overriding the law.

As with the form of inheritance in Java, the form of inheritance is called simple inheritance in managing settings and rights profiles. Simple inheritance means that each group in profile management can have only one parent group (although any given parent group can have multiple subgroups).

Profile management users (end nodes) may require membership in multiple groups, so the inheritance feature is set to a single hierarchical group

999 to minimize the likelihood of corrupted configurations due to the introduction of incompatible subgroups of variables introduced by cross-merge from groups. By allowing you to prioritize user group membership, profile management can track the search order to find settings related to a particular applet. In other words, starting with the highest priority group, the search on the first group for which the configuration data was found for the applet trying to load its settings is stopped.

User inherits software rights from group membership. With careful modeling of the company, the administrator can grant access to the software to many users without having to browse the panels one by one. Profile management controls access by programming the Web server to allow / deny access to applets. The Web server enforces access control. The profile manager serviet is also protected by requiring the Webserver to request user IDs and passwords to be sent to the web server for authentication. Prompting the user for a password is a standard browser feature.

Giant. 5 shows the system of FIG. 2 in more detail. The Applet1 configuration applet is invoked. administrator in the profile management. The Appletl applet can implement application programming interface 515 (API) to query its work environment information (e.g., query context, changed event context, query access control list for that context, etc.) for closer integration within profile management, but this is not configuration applet request. At any event, the appletl designer needs to understand only the basic API methods: enablePersistence (), load (), and absorbent (), except for the basic methods of the java.util.Properties object). · Φφφφ used to get information about the settings to and from the java.util.Properties object. Additionally, API 515 provides list () and getContext () methods. The appletl only needs to register with the ProfileManagementProperties class and call these methods as needed. The load () method can be called to obtain the current state of settings for a user applet that is configured in the context of a user or group selected by the administrator. The administrator can then modify the settings as needed and save them using the save configuration function provided by the applet that uses the save () method of its ProfileManagementProperties object. Similarly, if the applet applet needs a list of user applets authorized for user access, it can use the list () method to retrieve the list from the server. The getContext () method can be used by an applet to display the name of the context in which it runs, or even to ensure that it runs only in a certain context (ie, if the applet wanted to configure a service on a server that uses an export agent) only in the AllUsers context, because the exported information is server-specific as opposed to the user-specific situation. extension of the java.util.Properties class.

The profile manager 506 also provides a context change API 516 for configuration applets. The appletl applet can implement a context change event listener 512. API 516 and event listener 512 allow the administrator to change contexts (users or groups) while the configuration applet is running, without having to stop and restart it. For example, when setting custom applet settings, you may have · 9

I 9 9 4 »9 9 I • 9 99 9

9 9

9 9 the administrator changes the context many times during configuration.

registered as a listener 506 notifies him

If the configuration applet is such events, the context change manager via the API 516. This allows the appletl applet to reset its settings from the server for each new context. Without the event listener API, the appletl would have to be terminated by the administrator and restarted after choosing a new context to refer to existing information with the settings for the new context and not need to stop and restart the profile manager applet. To register the applet, the appletl calls the method on ProfileManagementProperties addContextChangeListener (API

Once the administrator sets up his 510 object,

516) Because of its registration, context, new context, the profile manager 506 makes a context setting call (API 516) to object 510, which in turn calls the reload method (API 516) on the event listener 512. The event listener 512 now makes a call to load properties on its property object 510 to retrieve new setup data from the server for the new context, and causes the appletl to update the GUI and internal variables to reflect the new setup information.

The above features prevent the network administrator from reading data from one context, changing the context, and accidentally overwriting it with save () when it wants to load () before creating configuration changes in the new context.

Applets that do not register as listeners will be stopped, destroyed, reloaded, and started again by the Profile Manager applet as the administrator forces the context change.

Profile Management also provides an export service

a feature that makes it easy to retrofit existing hardware and software into this profile management environment. The property export service allows profile manager 506 to support user stations (physical hardware) as well as users, groups, and user applications. Because an existing workstation is unaware of ProfileManagementProperties 510, the export service allows workstation vendors to create workstation configuration applets that determine the invocation of the export agent 520 on the server once the vendor applet stores its configuration information. The export label causes the vendor-supplied class instance (export agent 520 object) to be instantiated and the export method invoked on the object to specify that the workstation configuration be saved in any custom file format and file locations that are required by the configured workstation.

Suppose that the applet applet is a configuration applet provided by the vendor for an existing terminal that is incompatible with this profile management system. The vendor also supplies the export agent 520. The administrator can configure the terminal to work on this system by running the profile manager 506, setting the context to the configured terminal, running the vendor-supplied configuration applet appletl, and configuring this applet. Once the administrator saves the configuration, the portion of the information that is transferred to the server is a unique identifier that identifies the configured terminal. Typically, this is the MAC address (media access control) of the terminal. The Serviet 514 Profile Manager detects that the export agent is specified at save. The Serviet 514 profile manager detects this from one of the stored settings that determines the need for the export agent. The setting specifies the export label in the form of the key ·· ···· φ φ · · Φ ·· · ·· · «9 9 9 9

9 9 9 · · φ · ··· · · ········· · · 9 9 9 9

9,999,999 · Φ ·· pair of values

XXXXEXPORT_AGENTXXXX = {Export Agent Class Full Name}

The export agent context (config properties) method of the export agent is called by the profile manager servlet 514 to create one or more files 522 on the server from the stored configuration information. The specific file or files are identified by the unique terminal identifier that came with the property information from the appletl applet. Later, when the terminal boots the system, it uses its unique identifier to find and retrieve its configuration information from the 522 files on the server in the same way it always does, independent of the profile management system.

Figure 6 shows the applet2 applet running on the client computer. The applet2 applet could be an end user applet, such as a text editor. In any case, the applet2 applet has access to some of the same API methods as shown by the symbol 515 in Fig. 5, if needed. The applet2 applet uses the load method to get the settings and the absorbent method to store any settings that the end user may have changed. EnablePersistence initializes the Profile Management Properties object for applet2 with the user context and generates a unique key to identify the storage location of the settings on the server as described above by the administrator.

Giant. 7 shows the situation of a user calling up his desktop. The user on the client 700 points in its browser to the desktop applet URL on server a

00

0 0

0 0

0 0 0 0 0 0

00

0000 in step

704 sends a message to http: //server/Desktop.html).

Because Desktop.html is a file that protects the server, a prompt is sent back to the Web browser on the client at 706. The Web browser on the client responds by prompting the user for a user ID and password. The client then sends the user ID and password to the sender in step 7 08. The user ID and password are shown in bold at step 708 in Fig. 3 to show that they are a web browser, other places to send this information itself. representation of the same thing. Because the user may have permission to run the desktop applet, the request will be granted.

There are several interactions between the client and the server (not shown) where the code for the desktop applet is loaded to the client's desktop from the server. The desktop object is created and started in step 712. The desktop object needs its setup information (i.e., configuration information) to customize the desktop for the end user that invokes it. To this end, as part of the desktop object initialization process, the desktop creates the ProfileManagementProperties P object in step 714, which is used to load, retrieve, cache, set up, and save a copy of the user settings information from the desktop applet server. The desktop object then executes the API call P.enablePersistence (desktopObject (applet)) in step 716, which in step 1) 716 initializes the ProfileManagementProperties P object with the URL of the profile manager serviet 214. This URL is derived from the desktop applet URL that was loaded previously from the server. The ProfileManagementProperties P object sends a request 718 to the servet

214 profile manager to get context for users launching the desktop applet. In this case, the context consists of two components, the context name, which is the ID, and the context type, which is the user in this user.

case

The profile manager serviet retrieves the user ID from request 718 and returns the context in step 2 of 716

ProfileManagementProperties is

User P in step 719. Initialized the object with the context of the user launching the desktop. In step 3 of 716, the ProfileManagementProperties P object generates a unique key for the desktop program by querying the Java desktop P object for its fully qualified class name. All Java objects know their class name. This unique key is combined with user context information to provide a parameter that specifies a unique location in the information storage database 212 with user-specific settings for the desktop applet. Any desired method can be used to map a string consisting of the fully qualified class name and user context information to the location where the data is stored. Further, a request 720 is received from the profile manager serviet 214 to obtain information with user-customized settings for the desktop applet. The context and key are sent as part of the request 720 to identify the requested setup information. The profile manager serviet 214 responds with the requested setup information at step 722 that is captured in the ProfileManagementProperties P 604 object.

Further description relates to Fig. 8, at step 800, the desktop object reads its configuration information from its ProfileManagementProperties P and starts updating the desktop accordingly (i.e., could set the screen color on the modem, get icon position information, etc.) .). The desktop object calls the method of its ProfileManagementProperties P object to retrieve the list

software to which the user has access rights. The ProfileManagmentProperties P object requests information in step 802 from the profile manager serviet 214, which generates a response with the requested information in step 804. For each such applet to which the user has access, the information includes a descriptive user name, applet URL, applet icon URL, etc. (information that is required for the workspace to display the applet and load and run it) and other optional information that is not relevant to the invention. This information is stored in the ProfileManagmentProperties object P and returned to the desktop object. In step 806, the desktop object uses the applet information to build a folder for the applets and to generate a window displaying icons and a descriptive name for each applet to which the user has access.

Suppose that the user previously dragged icons for any programs displayed in the folder just described in the user's previous desktop launch. At this time, the user may no longer have access to applets that have been dragged from the folder to the desktop. However, these desktop objects would normally be part of the user settings that were saved during the last startup and would still be displayed on the desktop. To avoid this situation, the desktop examines its settings from its ProfileManagmentProperties P object and detects applets that are set to appear outside the window that is generated to display all the applets that the user has access to. Giant. 8 assumes that only one applet is generated outside the applet window. If there were more than one such applet outside the applet window, the following procedure would run in a loop for each such applet. In step 810, the workspace verifies each of these applets, which is

Appears outside the applet window opposite the list of applets from the server to which the user has access. If the applet is present in the list, the applet icon is placed on the desktop in step 812 at the same position as before. If the user no longer has access to the applets, the applet is removed from the stage settings in step

814 removes the object

If there are any applets

ProfileManagmentProperties P. removes it as part of this process, tells the ProfileManagmentProperties P object area to save the settings in step 816. The ProfileManagmentProperties P object sends a request 818 with the profile manager settings, key, and context 214 to store the new settings in database 212. response 820 of the ProfileManagmentProperties P object and informs the ProfileManagmentProperties P object that the request completed successfully.

Giant. 9 illustrates the situation of an administrator who runs a configuration applet to configure settings for an applet for other users or user groups. It is understood that the principles described herein also generally relate to the configuration of terminals or groups of terminals. The administrator on the client 900 points to the URLs of the applets 214 of the profile manager on the server to run in its web browser. The URL is sent to the server in step 904. Because ProfileManager.html is the file that the server protects, prompt 906 is sent back to the web browser on the client. The web browser responds with an administrator prompt for a user ID and password. The request to obtain ProfileManager.html is then repeated in step 908 to the server with the user ID and password included in the message. Because probably the administrator has the right to run the profile manager, the request is granted and the profile manager applet is downloaded to the administrator terminal in step 910. There is

• · • • • · · · • • • · • • · ·· • « • • · * • • • • • • • • 4 • • • • • • • • • • · ♦ e · · ·· · · * • ·

several client-server interactions (not shown) where the code for the Profile Manager applet is loaded on the client from the server. The profile manager object is created and starts in step 912.

The ProfileManagementProperties_nonContextFloating object is used by the Profile Manager instead of the normal ProfileManagementProperties object. It behaves like a ProfileManagementProperties object with one exception: when a setting is loaded and saved, it is loaded and stored in and out of the administrator who runs the profile manager, as opposed to loading and saving in and out of (ie, user or user group) for which administrator configures.

An object with the customize administrator settings to initialize profiles of the profile manager needs its information (ie configuration information) in order for the profile manager to invoke it

To this end, as part of the profile manager object process, the manager creates the nonContextFloating P_NCF ProfileManagementProperties object in step 914, which is used to load, capture, capture, set up, and save a copy of the administrator settings information from the server for the profile manager applet. The profile manager object then calls P_NCF.enablePersistence (profileManagerObject (applet)), which in step 1 of 916 initializes the ProfileManagementProperties nonContextFloating P_NCF object with the URL of the profile manager server 214. This URL is derived from the Profile Manager applet URL. Object

ProfileManagementProperties_nonContextFloating P_NCF sends request 918 to the profile manager serviet 214 to obtain the administrator context name (ID) and context type (USER). Serviet

the profile manager gets the administrator ID from request 918. The web browser sends the administrator ID and password in the message, along with the information sent by the object

ProfileManagementProperties_nonContextFloating P_NCF. The ProfileManagementProperties_nonContextFloating P_NCF object is initialized with the context of the administrator who launched the applet in step 2 of 916. In step 3 of 916, the ProfileManagementProperties_nonContextFloating P_NCF generates a unique key for the profile manager applet by querying the Java profileManagerObject (enablePerformance parameter). .getClass (). getName ()). a unique key, in combination with the administrator information, is mapped to determine a unique location in the information database 212 with specific administrator settings for the profile manager applet.

its full name of this context class

Request 922 is sent to the profile manager serviet 214 to obtain setup information adapted to the profile manager applet as set up for the administrator. Request 922 includes the context name and type information and key to identify the relevant information The Serviet 214 responds with the setup information.

captured

924 with the settings that are in the P_NCF object. with settings

ProfileManagementProperties_nonContextFloating The Profile Manager reads its information from ProfileManagementProperties_nonContextFloating and updates accordingly (ie, sets its background color to blue).

The run continues in Figure 10. The Profile Manager requests information about existing users, user groups, and groups of users. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · The profile manager software and builds a tree in the left pane of the profile manager settings window in step 1002. Examples of the left pane of the administrator see fig.

At this point 1004, the administrator selects the desired configuration context by clicking a user or group from the tree on the left panel. The Profile Manager sets the context for the ProfileManagementProperties objects by calling P_NCF.setContext (the selected context). See Fig. 15 for the selected User groups context, which indicates the group of all users of the system, or Fig. 18, where the development group context is selected, or Fig. 21, where the colleend user context is selected. Next, in step 1006, the administrator selects the applet to be configured from the list of all applets on the server. See Figure 17 for an example of choosing an applet. In step 1008, the administrator then clicks the Run / Customize button to launch the applet selected for configuration.

This applet could be a separate configuration applet for the end user applet, or it could be the end user applet itself. The selected applet is requested and loaded from the server in steps 1009 and 1011. In step 1010, the configuration applet object is created and its ProfileManagementProperties P object is executed and generated.

If the applet is assumed to be a separate configuration applet for the end user applet, then at step 1012, the applet calls p.enablePersistence (the Configuration Applet object,

FullConfiguredAppClassName). On the other hand, if the applet is a user applet, rather than a separate configuration applet, the call would be p.enablePersistence because it wants to set its own settings information as opposed to the settings for another applet. The current context is already known to the ProfileManagementProperties P because it was previously • * · • · ♦ fe ·

* Set by the administrator through the ProfileManagementProperties_nonContextFloating PM_NCF object of the administrator. The location of the profile manager serviet 214 was previously generated once enablePersistence was called on the ProfileManagementProperties_nonContextFloating PM_NCF profile manager object. For a configuration applet, the unique key for the applet does not need to be generated because it is passed by the configuration applet of the ProfileManagementProperties P object by calling enablePersistence.

In step 1014, the configuration applet registers with its ProfileManagementProperties P object as a context change listener. As described above, this allows the Applet ProfileManagentProperties object to notify the applet when the administrator makes a context change so that the applet can load the configuration information for the new context and update its graphical user interface to reflect the new configuration information without having to exit and run the applet again in a new context.

The run continues in FIG. 11. In step 1104, the configuration applet tells the ProfileManagementProperties P object to load the settings from the current context for the configured applet. Request 1105 is sent to the profile manager serviet 214 to obtain setup information adapted to the context previously selected by the administrator for the applet being set up. Request 1105 includes the appropriate context name (context selected by the administrator) and context type (USER, USER_GROUP, or ALL_USERS_GROUP, according to and key information, setup information).

of what is specified instead of the Serviet 214 by the administrator) will respond with the required setup information in step

1106 that are captured in the object

ProfileManagementProperties P. The configuration applet retrieves settings from the ProfileManagementProperties P object and updates its graphical user interface accordingly.

The administrator configures the applet in step 1107 and saves the modified settings, for example by clicking the SAVE button provided by the applet. As a result of this operation, the configuration applet calls the absorbent () method on its ProfileManagementProperties P object. The ProfileManagementProperties P object sends the settings and a unique key for the applet being set up and information indicating the current context of the profile manager servlet 214. The profile manager serviet stores the configuration information in database 212 at the location specified by context and key.

Step 1108 is an example of an administrator who now changes the context while the configuration applet is still running. The administrator selects a new context by clicking a user or group of users (for examples of new contexts in the left-hand panel on the screen, see Figure 18). As a result of the context change, the profile manager 506 sends the context setting message of the ProfileMangementProperties P 510 object by calling P_NCF.setContext (the NEW context selected), which in turn causes the P object to notify event listeners 512 of context change 1110. In step 1112, the event listener 512 invokes load () to obtain the settings for the new context, and the P object is updated with the new settings in step 1118. The administrator can now continue to modify the new settings for the new context, if desired and save if necessary and then proceed with the new context as described above.

9999 99 9999 99 Φ Φ · Φ Φ Φ

Φ ΦΦΦ ΦΦΦΦ Φ

ΦΦΦ φφφφ φφ φ

Φ Φ · Φ ΦΦ ΦΦ ΦΦΦ

The remaining figures 12 to 24 show actual screenshots from the administrator's workstation while the sections of the profile manager 206 are running.

The main configuration window 1200 is shown in Figure 12. The tree-like panel 1202 on the left side of the window illustrates profile management 1204 as one of several services available on the server. Once this item 1204 is marked as shown in Fig. 12, the right panel 1205 of the main window displays an initial message for this profile management service. Drop-down and roll-out icons such as 1208 are used to control the appearance of nested items below the item in the left panel, if any. The + v 1208 character is called a drop-down icon and indicates that there are nested items under Profile Management. The administrator can view these nested items by clicking the drop-down icon 1208, which then becomes a rollover icon

Giant. 13 depicts the deployment of the Profile Management Item 1208 in FIG. 12, which results in the display of three standard nested items in FIG. 13 - Apples 1300, User Groups 1302, and Users 1304. Drop-down icons indicate that these items can also be deployed. Applets 1300 allow the administrator to define user applets available on the server 202, User groups 1302 allow the administrator to create and populate the user group tree of Figure 3, and set group settings. Users 1304 allow the administrator to create new users and set their settings or change settings for existing users. In the example of Fig. 13, Applets 1300 are labeled. Once this item is selected, panel 1305 to the right of the window displays a list of 1306 user applets that have already been defined in the system. App Attributes

Změna 4.3.2001

• · • · · · 4 »· 444 · • · 4 • · · • · • 4 4 44 • · · • · · 4 4 4 4 • · • • · · · 4 4 · ·

which is selected in step 1306 are shown in step 1308. The administrator defines a new applet by selecting <NAME> in step 1306 and entering the name and location required in step 1308. The existing Database Explorer applet is displayed as marked in step 1306. In step 1308, it displays Applet Name field The name of this applet. The URL (Universal Resource Locator) field displays the Internet or intranet web address of this applet on server 202. The Full Name field of the html file displays the location of the directory and the applet file name in the directory structure on the server disk. The Icon URL field displays the URL of the image file used to generate the icon for the user's desktop. The remaining fields are for optional information that may be required by the software after retrieval. The Import Applet List from File button 1310 allows the administrator to link the applet definitions to an existing list 1306 from an existing text file. When the button 1310 is clicked, the window shown in FIG. 14 is invoked and allows the administrator to specify the location and name of the text file containing the applet definitions to be linked. To save all pending changes, the administrator clicks File 1312 and then Save (not shown).

In the left panel, item 1302 User groups corresponds to the AllUsers group in Figure 3 (User groups and AllUsers are used interchangeably here). Giant. 15 shows the right panel of the administration station when 1302 User Groups is selected. Fig. 15 shows a workbook panel that contains three tabs - the Members tab 1514, the Subgroups tab 1516, and the Applet Rights tab 1518. In Figure 15, a member card is selected. The Members panel lists 1520

Change 4.3.2001 · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Přihlaš · · · · • přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš přihlaš). If an administrator wants to create a new user (who automatically enters membership in the currently selected group context - User Groups), he chooses <New> from list 1520, enters the appropriate information in the input fields 1524 to the right of the list, and clicks 1522 Create. If an existing member is selected in list 1520, the attributes previously stored for that user are displayed in 1524. These attributes include the full name of the selected member, the system member ID, password, and any desired comment. Attributes, other than the ID, can be edited and the changes committed (but not saved) by clicking Edit 1525, or the user can be completely removed from the system by clicking 1526 Delete. To delete any pending change, select an item in the 152Q list and click 1528 Undo.

Giant. 16 shows the right administrator panel that is displayed when the Subgroup tab 1516 is selected. The list of 1620 subgroups shows existing groups that are subgroups of an item labeled in the left pane, which is the User Group in this case. Thus, list 1620 shows all immediate subgroups of the AllUsers group.

On the left panel there is User groups. The subgroups shown in list 1620 are also expanded items under User groups in the left pane. In list 1620, the status field shows the current status of each subgroup, such as! remove,! Edit and Create. An empty status field in list 1620 indicates that a subgroup exists and no actions are waiting to be saved. Symbol! indicates that the status is pending (not yet saved). Attributes for the subgroup selected in list 1620 appear in 1622. These attributes include the subgroup name and the desired subgroup comments. If

Modification 4.3.2001 φφ φφφφφφφφφφφφφφφφφφφφ. The administrator wants to create a new subgroup, select <New> from the list 1620, enter the subgroup name and the desired comment in step 1622, and click the 1628 Create button. Item! create <subgroup name> then appears in list 1620 as a pending action. To save all pending changes, the administrator clicks the File button in the main menu and then Save (not shown).

Giant. 17 shows the right panel, which is shown when the Applet Rights tab 1518 is selected. List 1720 shows all the names of all the applets that have been defined for the system and the permission status (allow or deny access) that are associated with each applet for the group or subgroup (current context) that is indicated in the left panel. As with the other workbook cards that have been described, the exclamation mark indicates that the state is a pending change. In Figure 17, the User Group group that corresponds to the AllUsers group shown in Figure 3 is indicated in the tree shown on the left panel. defined for the system. For example, the default permission status for the Database Explorer applet is permit (meaning access is allowed) for the AllUsers group; likewise, the standard permission status for all users to the TFTP applet is disabled (access is denied). The administrator can change the status of the applet by selecting it in the 1720 list and clicking the 1730 Enable Group Access button or the 1732 Deny Group Access button. Furthermore, regardless of the applet permissions status for the selected context, the administrator can select an applet from 1720 and click the 1734 Run / Customize button to run the user applet under the selected context. The area of the panel that previously displayed

Změna 4.3.2001

0 »0 · 00

0

0 «'0

• 0 0000 0 0 · 0 4 0 »0

0 0 • 0 0

0

0 0 0 0

The 0 workbook for the current context will then be occupied by the running user applet. If the user applet happens to be a configuration applet for other software, the administrator can then save the program settings (using special configuration applet functions) to be saved as the default software settings for the selected context. If the applet is an end user applet, the functions are the same except that the end user applet loads and saves its own settings rather than settings for another separate program unit.

Giant. 18 shows the complete deployment of the subgroup tree in the administrator left panel under User groups. Just below the User groups are two. the Administrators subgroup, the standard subgroup that cannot be deleted, and the IBM subgroup, 'which is a subgroup defined by the administrator.

The IBM subgroup has also been developed and includes three and Software. A subgroup contains at least one Development subgroup, Hardware, Services

The software has been developed and has a subgroup called Development, containing at least one subgroup called NCoD. The NCoD subgroup contains a number of subgroups, such as ConfigFW 58, which does not have sons. Also in this example, the Development subgroup is selected in the tree. Because Development is not at the top of the All Users tree hierarchy, the workbook shown in the right pane is slightly different from the workbook in Figure 15 when the User Groups were marked because all users are not automatically members of the Development group because they are members of the User Group. List 1820 displays the login system IDs of all system members. The status next to each user ID in the 1820 list shows whether the user owns a membership in the Development subgroup. State

Change 4.3.2001 • · • 9

5 • 9

999 9900 99

9 9 99 99 99 9 yes indicates that the user is a member of the Development subgroup, not indicates that the user is not a member of the Development subgroup, and inherited indicates that the user inherits membership in the Development group by belonging to at least one of the Development subgroups below tree. The user's membership status for a subgroup is changed by the administrator by selecting the user in the 1820 list, and then clicking the 1836 Add to Group button or the 1838 Remove from Group button. If the administrator wants to create a new system user or edit or delete an existing member, the administrator clicks the 1840 Create / Edit / Delete User button. This action brings up the workbook page shown in Figure 19. The right panel of Figure 19 is similar to the panel of Figure 15 and allows the administrator to create a new system user by selecting NEW in the 1920 list and then clicking Create. Similarly, an administrator can edit or delete an existing system user by selecting the appropriate user in the 1920 list and clicking the appropriate Edit or Delete button. Users created in the context of any subgroup (eg Development) will not only receive the required membership in the User Group, but will automatically become members of the selected subgroup. Changes to the system user list are saved by clicking File in the top menu bar on the right panel and then clicking Save (not shown).

Giant. Fig. 20 shows a direct way to access the list of users of the edit system, other than by the group and subgroup path shown in Fig. 19. In Fig. 20, the administrator navigates by, for example, selecting Users 1304 in the left panel of Fig. 13. 20, the administrator can create new users and edit and delete existing users as described without

Change 4.3.2001 '99 ················· 99 99 · 9 · 9 «9 9. 9 - 9

9 '· 9 · 9 · · · ·

999 9999 99 9 £ · t 9 «9 9 99 99 9 would be in the context of a group or subgroup.

In Fig. 21, the administrator wants to work directly with the information corresponding to the user whose ID is colleend. This is done, for example, by expanding Users in the left panel of Fig. 21 and then marking the colleend as shown. Then the right panel will appear, which refers to the system information about colleend. The right panel contains three tabs. The first User Information tab is selected by default. On this tab, the administrator can edit the colleend's name, ID, password, and comment.

Giant. 22 shows the right panel when a user selects the second Group Membership tab. List 2220 shows all subgroups of which the colleend is a member. Subgroups are displayed in this list in the order of subgroup priority for colleend users. The administrator can change the priority of colleend's subgroups by selecting the subgroup and using the up and down arrows to the right of list 2220 to move the selected subgroup up or down the list as needed. If the administrator clicks the Add / Remove Group Membership button in Fig. 22, the right panel will begin to display the contents of Fig. 23. The right panel allows the administrator to edit the subgroups of which the colleend is a member. The administrator does this by clicking the appropriate box corresponding to the desired subgroup. If the check box is unchecked (which means colleend is not currently a member), then it is checked to add colleend to the subgroup. Conversely, if a subgroup check box is already selected, the check box clears and the colleend is removed from the subgroup.

Change 4.3.2001 9 9 9 9 9

9 9 9 9 9 9

9 9 9 9 9 9 9 9

Giant. Figure 24 shows the right panel when the Applet Rights tab of Figure 22 is selected by the administrator. In this right panel, list 2420 shows all the applets that are defined in the system. The administrator can allow colleend access to the applet by selecting the applet in list 2420 and then clicking 2430 Allow User Access; or colleend access may be denied by clicking the 2432 Deny User Access button. The administrator can also run the applet in the colleend context by clicking the 2434 Run / Customize button. When this is done, the applet indicated in list 2420 runs on the right panel. The administrator can then modify any settings that the applet allows and save the settings in the manner provided by the applet. A typical scenario is here for the administrator to then run the configuration applet and fill out multiple setup fields. However, if a separate configuration is not provided for the user applet, the administrator can run the user applet in the user context and set the settings from the user applet. A typical scenario here is for an administrator to designate a group or user context and then run the user applet as described above. The administrator can then typically adjust the settings from the options menu and save it in any way that the user applet allows. For example, typically, user settings are stored when the options dialog is closed, or the user applet may provide other ways to save settings. In any case, because the administrator runs the applet in the context of the colleend user in this example, the settings set by the administrator using the user applet are saved to the server as if the colleend user entered it directly by running the applet.

The figures do not show a scenario where the user can

Change 4.3.2001 to modify some settings related to the user applet. For example, a custom applet may allow a user to select a window background color or font and font size so that each user can customize the applet to some extent once the applet runs on the user's desktop. In this case, the user-changed settings are saved in the same way as if the user applet were started by an administrator. One difference, however, is that the administrator can run user applets to change settings in group contexts, while users can only control the settings of their individual contexts.

Represented by:

Dr. Petr Kalenský v.r.

: LAuAA Ilir, '' KAi, '' n

A ΡΑΑΪΝΕΑΠ ún ún ún ún Pra Prague ;! , Halkova 2

Změna 4.3.2001

dofl

Claims (3)

PATENT CLAIMS JUDr. Petr Kalensky attorney 120 00 Prague 2, Halkova 2 For use in a network system comprising a network connecting a server and a plurality of user stations, wherein the server stores a plurality of user applications for download to user stations, a method of managing user configuration settings for applications running on a user station, the method comprising the steps of: representing all system users in a tree hierarchy consisting of an AllUsers group node that contains all system users, and a plurality of group nodes, each of which includes designated users belonging to the group represented by the group node, each node containing configuration settings for the selected the applications available on the system; assigning group priority order to each user who is a member of more than one group; with respect to any user requesting the launch of the selected application, determining the order of group priority for the user; and assembling the configuration setting group from the tree by determining the first group from the group priority list from which the setting group for the selected application can be derived; merging the settings into a group for the selected application by browsing the tree from the AllUsers group node to the first group; merging the settings specified on each node for the selected application; and adjusting the merged setting as each node passes through the setting specified on that node for the selected one 27 80 754 application. 2. For use in a network system comprising a network connecting the server and a plurality of user stations, wherein the server stores a plurality of user applications for download to user stations, a device for managing user configuration settings for applications running on the user station, the device characterized in that contains: means for representing all system users in a tree hierarchy comprising an AllUsers group node that includes all system users, and a plurality of filial group nodes, each comprising a selected one belonging to a group represented by the filial group node, each node including configuration settings for the selected application available on the system; means for assigning group priority order to each user that is a member of more than one group; with respect to any given user requesting the launch of the selected application, means for determining the priority order of the groups for the user; and means for building a configuration configuration group from the tree by determining the first group from the group priority list from which the configuration group can be derived for the selected application; merging the settings into a group for the selected application by browsing the tree from the AllUsers group node to the first group; combining the settings specified in each node for the selected application; and · «·· 9 · · · ♦ · by adjusting the combined settings when passing through each node through the settings specified on that node for the selected application. AllUsers amount A computer program product stored on a computer readable storage medium for executing on a computer, executing on a network system comprising a network connecting the server and a plurality of user stations, wherein the server stores a plurality of user applications for download to user stations, an application running on a user station, the method comprising the steps of: representing all system users in a tree hierarchy consisting of a group node containing all system users and filial group nodes, each containing selected users belonging to the group represented by the filial group node, each node containing configuration settings for selected from applications available in the system ; assigning group priority order to each user who is a member of more than one group; with respect to any given user requesting to run the selected application, determining the priority order of the groups for the user; and assembling the configuration settings group from the tree by determining the first group from the group priority list from which the settings group can be derived for the selected application; merge the settings into the application by browsing the AllUsers tree to the first group; combining the settings specified on each node for the selected application; and groups for the selected from the group node by modifying the merged settings as each node passes through the settings specified in that node for the selected application.