Single Access to Common User/Application Information

The present invention relates generally to a method for administering and coordinating user and application information in a distributed computer environment operating under a window based operating system and, more particularly, to a method for centrally storing routine user and application information so that an administrator can add, update, or delete users and user information, add, delete, or update applications and/or resources by editing a single file through a user customization interface. The address book information (name, place, number, etc.) is integrated with the application information, both in the database and on the CUI. This is a unique feature of the present invention.

More particularly, the present invention relates to a method for centrally storing user and application information in a database where the information is used to tailor, update, expand and administrate user compute environments with the simple addition, deletion, modification, and/or customization of database enter fields and where a user or administrator interacts with the database fields through a customization interface featuring a window display comprising horizontal and vertical tabbed entries identifying users, user profiles, applications, and user compute environment configurations.

Prior art search techniques for adding users and/or applications as well as updating user and application information has required the user and/or a system administrator to modify and update user information for each user and for each application. This process can be time consuming and because much of the information is identical, the process is highly repetitive and fraught with the possibility of errors in data entry, updated, and/or user environment customization.

A window management system provides many of the important features of modern user computer interfaces. A window management system allows multiple applications to interact with the user on a single computer display, and provides low level functions for the application to display data and collect input from the user. The window management system permits application programs to show results in different areas of the display, to resize the screen areas in which those applications are executing, to pop-up and to pull-down menus. The window management system is a resource manager in much the same way that an operating system is a resource manager, only the types of screen area to various applications that seek to use the screen and then assists in managing these screen areas so that the applications do not interfere with one another. The window management system also allocates the resources of interaction devices to applications that require a user input and then routes the flow of input information from the devices to the event queue of the appropriate application for which the input is destined.

The look and feel of the user computer interface is determined largely by the collection of interaction techniques provided for it. Designing and implementing interaction techniques for each individual application would be a time consuming and expensive task. Furthermore, each application would end up with a different look and feel making it difficult for a user to move from one application to another. Applications sharing a common window management system can utilize a common interactive technique toolkit built for the window management system to assure a common look and feel. An interactive technique toolkit consists of a set of subroutines that provide different types of display objects.

Interactive technique toolkits, which are subroutine libraries of interaction techniques, are mechanisms for making a collection of techniques available for use by application programs. By using interactive technique toolkits, a consistent look and feel among application programs sharing a common window management system can be insured. Using the same toolkit across all applications is a commonly used approach for providing a look and feel that unifies both multiple applications and the window environment itself. Interactive technique toolkits are available for specific windowing management systems. For instance, the menu style used to select window operations should be the same style used within all applications. Basic elements of the toolkit can include menus, dialog boxes, scroll bars, file selection boxes and the like, all which can be conveniently implemented in windows.

The X Window System is an example of a window management system that can be used in association with the present invention. One of the most important features of this type of window management system is that it supports device independence by separating the interactions with the display, keyboard and mouse from the rest of the system. This type of windowing system has three basic parts: a library of routines at the lowest level; a framework which allows the application developer to combine components from the library to produce a complete user interface; and an interactive toolkit that supports a set of user interface components known as widgets and include such things as scroll bars, menus and buttons.

The architecture of this type of window management system is based on the client-server model. A single process, known as the server, is responsible for all input and output devices. The server creates and manages all windows on the screen, produces text and graphics, and handles input devices such as the keyboard and mouse. The server implementation is independent of any application but is hardware specific. In a typical environment the application is a client and uses the services of the server via a network connection using an asynchronous byte stream protocol. Multiple clients can connect to the same server. The server hides the details of the device-dependent implementation of the server from the clients.

A window manager process allows the user to control the size and location of windows on the screen. These operations are generally performed by a window man, another client application. In this configuration, it is possible for the window manager to get events pertaining to the resizing or moving of windows from the server independent of the notification of these events to the application. The window manager acts independently from the application and, together with the server, may cause the user interface to be modified without the application being involved.

The windows system requires that the application developer be intimately familiar with operation of the windows system including the library, framework, the toolkit, the window manager, and the server. The complexity of the windows system and the expertise required makes user interface development more costly and can result in longer application development cycles using more resources. The complexity of the windows system results in code that is more difficult to write, error prone and difficult to maintain.

It thus would represent a significant advance in the art of distributed computing environments operating a windowing type operating system to have a technique where a single, centralized file contains information about users and applications and the file can be readily, easily, and efficiently modified through a customization user interface to add, delete, and/or update user and application information or to tailor user compute environments.

The present invention provides a method for centrally storing user and application information and automatically distributing such information to and from the installed applications in a distributed computer environment running a windowing type operating system so that user and application information can be updated, edited, and manipulated through a customization user interface (CUI). The applications are not required to change their current operations. The method includes the step of installing a localized user and application information procedure (LUAIP) comprising a central datafile, a CUI, and methods for manipulating data entries in the datafile. Once installed, the CUI provides a user access to the manipulation methods by pointer-based device or keyboard selection from a series of menus or icons associated with the CUI display window. The manipulation methods include adding user and application profiles, modifying user and application profiles, deleting user and application profiles, and customizing user compute environments. Once activated or selected the manipulation methods cause the LUAIP to invoke the appropriate codes to accomplish the selected task and modify the datafile. The CUI includes a plurality of profiles including at least a user profile and one application profile displayed in a profile display area of the CUI window. Each profile appears as a tab associated with any other profile in the profile display area. The tabs are only displayed when valid, i.e., when an application profile exists for that application. Optionally, each profile may also have one or more other tabs designating information specific to each profile.

For a more complete understanding of the present invention and the features and advantages thereof, reference is now made to the Detailed Description in conjunction with the attached Drawings, in which:

FIG. 1 is a schematic block diagram of the overall arrangement of a workstation that includes a multiwindow presentation control device.

FIG. 2 is a schematic block diagram of a diagram of a single server environment or a server node of a multiple server environment.

FIG. 3 is a window associated with the CUI of the present invention showing a plurality of application tabs opened to a given user tab.

FIG. 4 is a window associated with the CUI of the present invention showing a plurality of application tabs and application specific tabs.

FIG. 5 depicts a flow diagram for a central database interface for storing and manipulating user and application information on a distributed computer system or environment.

FIG. 6 depicts a flow diagram for adding a user to the database and enrolling the user in one or more resident or distributed applications.

FIG. 7 depicts a flow diagram for updating a user's information and the user's enrollment in one or more resident or distributed applications.

FIG. 8 depicts a flow diagram for deleting a user from the database and removing the user from one or more or distributed resident applications.

FIG. 9 depicts a flow diagram for a user directed updating of the user's database information and enrollment in one or more or distributed resident applications.

The inventors have developed an easy, efficient and centralized information repository for user profiles and application profiles so that user and application profiles can be centrally stored, added, deleted, modified, customized, accessed, and generally utilized to facilitate computer environmental management and improve computer and user performance on distributed computer facilities.

The method of the present invention includes installing a customization user interface (CUI) on a computer system preferably having windowing capabilities. Upon installation, the CUI accesses a datafile in a previously installed or presently installed database program. The datafile will contain user and application information for central storage, manipulation, and use. The CUI is then invoked by a user or system administrator. The user or system administrator then selects from a set of procedures for modifying the datafile. The set of procedures available to the user or system administrator include at least an add procedure, a delete procedure, and an update procedure. Users can only perform the update procedure on their own record.

The CUI is a user interface that allows for easy and efficient interaction with the datafile to facilitate datafile manipulation and user environmental design. The CUI includes a window displaying a user definition note book entry or card with tabbed indices indicating associated applications and user profile information. The tabbed indices are selected by pointer-based device or keyboard activation. Once activated the window display changes to the associated window for the selected tab. Each data field associated with each window display can be modified, protected, passworded, or otherwise manipulated by the appropriate user to add, delete, or manipulate user and application information. Each tab is specific to the application selected.

The method and its associated CUI and datafile of the present invention provides a centralized repository for information needed by all application and by system administrators to facilitate system upgrades and to efficiently administer a changing work force and changing user environmental demands. The centrally located user information can be directly accessed during new application installation so that the application becomes defined in the datafile and the application becomes automatically available to all users or to a select class of users defined by their centrally stored user profiles. The application has access to user information if needed.

The method of the present invention and its associated CUI and datafile allow an administrator or user to centrally review, modify, or update data file entries and application entries. When the program implementing the method of the present invention is installed on a computer system already having applications (resident or distributed) and users, the method of the present invention pulls user information from each application, and stores the information in the datafile for subsequent CUI mediated modification. When new applications are added, the method of the present invention pulls the application and creates a CUI tab entry. The administrator then uses the CUI to assign users to the application. Each user and his/her user profile or the appropriate parts thereof are pushed to the application (i.e., transferred from the datafile to the application) making each user "familiar" to the application.

The method of the present invention also can centrally store generic agents (standard profiles) for interaction with various applications. The method is also designed to support APIs for user defined business applications.

The method of the present invention can be implemented on a single server environment, a multiple server environment, or on any other type of distributed computer system comprising a plurality of users and nodes in a fully or partially networked computer environment having a single or multiple servers and locally resident or globally distributed user applications.

The present invention is designed to operate in an environment that has windowing capabilities associated with it. Although this environment is greatly preferred, one of ordinary skill should realize that the invention could be implemented by the inclusion of routines that would perform the windowing services needed without having an actual window management system. Even in such as environment, the basic routines that would be necessary can be adequately addressed by describing a window management system.

A window management system provides many of the important features of modern user computer interfaces. A window management system allows multiple applications to interact with the user on a single computer display, and provides low level functions for the application to display data and collect input from the user. The window management system permits applications to show results in different areas of the display, to resize the screen areas in which those applications are executing, to pop-up and to pull-down menus. The window management system is a resource manager in much the same way that an operating system is a resource manager, only the types of resources differ. The window management system allocates the resources of screen area to various applications that seek to use the screen and then assists in managing these screen areas so that the applications do not interfere with one another. The window management system also allocates the resources of interaction devices to applications that require user input and then routes the flow of input information from the devices to the event queue of the appropriate application for which the input is destined.

A window management system typically has two important parts, the first is the window manager with which the end user interacts to have windows created, resized, moved, opened, closed and so on. The second is the underlying functional component, the window system, which actually causes windows to be created, resized, moved, opened, closed and so on. The window manager can be built on top of the window system. The window manager uses services provided by the window system. The window manager is to its underlying window system as a command line interpreter is to the underlying operating system kernel. Applications are built on top of the window management system. The applications built on the window management system are sometimes called clients, which in turn use the capabilities of the window management system, itself, sometimes called the server program. In some client/server window management systems, such as the X Window system, the window manager itself appears to the window system as just another client program. In other systems there is a closer relationship between the window manager and the window system than there is between a client and server. Note that multiple clients are supported by a single server, versus linked code which requires a one to one relationship. The client/server model permits clients and servers to execute on different platforms, communicating via interprocess communications or other interconnecting means. The use of interprocess communications allows computation intensive applications to reside on a powerful computer while the user interacts with the application from a workstation. In this regard, the client/server model is just a sophisticated instance of a virtual terminal protocol; such protocols, in general, share this advantage.

A window management system does not need to be built on the client/server model. For instance, the Maclntosh.TM. has no well defined separation between the window manager and the window system. Such separation was not necessary for the single active process, single processor design of the MacIntosh.TM., and would have led to additional runtime overhead. Of course, in window management systems that provide for the use of interprocess communications between the window manager and the window system, such as X Windows, News and Andrew, the interface must be designed to minimize communication delays.

Applications sharing a common window system can utilize a common interactive technique toolkit built for the WMS to assure a common look and feel. An interactive technique toolkit consists of a set of subroutines that provide different types of display objects. Interactive technique toolkits, which are subroutine libraries of interaction techniques, are mechanisms for making a collection of techniques available for use by applications. By using interactive technique toolkits, a consistent look and feel among applications sharing a common WMS can be insured. For instance, the menu style used to select window operations should be the same style used within all applications. Basic elements of the toolkit can include menus, dialog boxes, scroll bars, file selection boxes and the like, all which can conveniently be implemented in windows. Interactive technique toolkits are available for specific WMSs. Widely used toolkits include the Andrew Window Management Systems Toolkit, the Maclntosh.TM. Toolkit, OSF/Motif and InterViews toolkits implement Open/Look and both X Windows and News, Presentation Manager.TM. and the Sun View Window Management Systems Toolkit.

Turning now to the present invention, FIG. 1 schematically illustrates an example of an overall system arrangement of a workstation that includes a multiwindow presentation controlling device usable in conjunction with the method of this invention and embodying a system on which the present method can be implemented. In this system, a keyboard 10 is provided as a means for entering information, such as various control commands, character data, and graphic data, which is used for information processing. The keyboard 10 is connected through an input controller 12 to main CPU 14 that performs various information processing.

The workstation also includes a pointer-based device 16, constituted by a mouse, a tablet, or the like, with the preferred devices having associated with them one or more buttons designed to provide a mechanism for selecting screen objects such as window, grid elements, data sets, and the like. The pointer-based device 16 is provided as another means for entering information including various control commands, data selection, menu option selection, and the like invocable through pointer-based device positioning and button activation. When the pointer-based device 16 is rolled or moved on a flat surface (not shown) by an operator, a pointer image or a cursor (indicated by the fish-eye of FIG. 2 or the box of FIG. 3) displayed on the display screen S of a CRT display unit 18 moves accordingly to desired coordinates on the screen S or a desired screen location. In the case of a grid as illustrated in FIGS. 2 or 3, the cursor would be used to select a desired grid element. With the use of the pointer-based device 16, therefore, it is possible to easily and quickly specify any desired screen coordinate or location and/or select any desired functional element on the display screen, such as a menu option, a grid element, or a scroll list of search hits.

The pointer-based device 16 is connected to a cursor position calculator 20, which calculates the coordinates of the cursor on the display screen S of the CRT display unit 18 substantially in real time in accordance with the movement of the pointer-based device 16 on the flat surface, and generates cursor position data. The cursor position data is supplied to a cursor image controller 22, which is connected to a cursor image pattern generator 24 and a refresh image memory 26, which may be a bit-mapped memory serving as a video RAM. The refresh image memory 26 has a memory space corresponding to one display screen of the CRT display unit 18, and is connected to the display unit via a typical display controller 28.

The cursor image controller 26 writes a cursor image pattern from the pattern generator 24 into the image memory 26 at a suitable memory address specified by the cursor position data. The cursor image written into the image memory 28 is displayed by display controller 28 at corresponding coordinates on the display screen S of the CRT display unit 18. Since the cursor display process by the cursor image controller 22 is performed substantially in real time (i.e., at a high speed), the cursor continuously and smoothly moves on the display screen in accordance with the movement of the pointer-based device 16 on the flat surface. Accordingly, the faster the pointer-based device movement on the flat surface, the faster the cursor movement on the display screen S.

The main CPU 14 and the pointer-based device 16 are connected to a window presentation controlling section 30, which carries out the general management of windows formed or opened on the screen S of the display unit 18 by the operator, using the pointer-based device 16. More specifically, in response to instructions from the operator or user, the window presentation controlling section 30 may (1) change the window-overlapping order to make any desired window active, (2) change the size of each window or (3) move it around on the screen.

The window presentation controlling section 30 has a random access memory (RAM) 32 to which the cursor position data from the cursor position calculator 20 is also supplied. The RAM 32 temporarily stores the output data of the cursor position calculator 20 as present-cursor position data; it also stores the last-cursor position data. When the cursor position data changes according to the movement of the pointer-based device 16 on the flat surface, the RAM 32 updates its contents so as to store new data from the cursor position calculator 20 as the present-cursor position data. One convenient format for storing cursor position data from the cursor position calculator 20 is in the form of a data table stored in the RAM 32. Obviously, the data table of the RAM 32 is updated with movement of the pointer-based device 16. Throughout the following description, the RAM 32 will be referred to as "cursor position memory."

The window presentation controlling section 30 also has a window forming unit 34, connected to pointer-based device 16. When the operator or user enters data to define the position and the size of a new rectangular window to form or open that window using the pointer-based device 16, this data is transferred to the window forming unit 34. Based on the input data, the window forming unit 34 generates data to specify the new window. This data is supplied to a window managing unit 36. The window managing unit 36 refers to the windows opened already, and determines the window manner and the display priority for the new window. The window number and management codes representing the display priority are affixed to the received window-specifying data and are supplied to two RAMs 38 and 40.

The RAM 38 receives and stores that portion of the output data of the window managing unit 36 which is associated with the window number and the window size (i.e., coordinate data representing the coordinates of two corner points, which diagonally face each other on the display screen and define the area of the new rectangular window). Again it is convenient to store with data as a data table in the RAM 38. That is, the RAM 38 stores data representing the areas of the windows, window attributes, and associated window objects as the window appears on the screen S in the order the windows are opened, defined, or created by the user. In the following description, the RAM 38 will be referred to as "window area memory."

The RAM 40 receives and stores that portion of the output data of the window managing unit 36 which is associated with the display priority. The display priorities of the opened windows on the screen S of the CRT display unit 18 are initially determined by the window managing unit 36 in such a manner as to coincide with the order they have been opened. As the RAM 40 stores data representing the display priority of each window opened on the display screen, it will be referred to as "window priority memory" in the following description.

For example, if the new window is given the display priority of "1" (the highest display priority) at the front most position on display screen S, its entire region is visible. A second window with a display priority of "2" that overlaps with the window having the priority "1" will lie behind the later one. Therefore, that portion of the window with the priority "2" which overlaps the window with the priority "1" is invisible. Additionally, a window with a display priority of "3" i.e., a priority lower than those having priorities "2" and "1" will have its portions that overlap the windows having the priority "2" or "1" lying behind those windows and thus those portions will be invisible on the display screen S.

The data in the window priority memory 40 which specifies the window having the highest display priority, (i.e., the active window) is supplied to the input controller 12. Consequently, the input controller 12 can manage in which window on the display screen S the information currently entered by the operator or user through either the keyboard 10 or the pointer-based device 16 is to be written.

An arithmetic and logic unit (ALU) 42 is connected to the cursor position memory 32 and the window area memory 38, so that it can access these memories. Accordingly, the ALU 42 receives the present-cursor position data that is always updated, from the memory 42 over a signal line 44, and receives the position data of all currently opened windows on the screen S, from the memory 38 over a signal line 46. Based on the output from the memories 32 and 38, the ALU 42 automatically detects, in real time, in which window on the display screen S the cursor lies.

Specifically, the ALU 42 compares the present position data of the cursor with the coordinate data defining the position and the size of all currently opened windows, sequentially. Here, the ALU 42 correlates the present-cursor position data, usually in x and y coordinates, with position data that define each rectangular window on the display screen S, usually two corner points (upper left and lower right), and determines whether the cursor has moved within a given window or has moved from one window to another. When the ALU 42 detects a change in the window which contains the cursor, it generates a detection signal 48.

Moreover, the ALU 42 also correlates the cursor position data with specific attributes and objects associated with the window that are stored in the window area memory 38. These attributes and objects can include menu options, grid elements, hits list selections, hot spots, and the like. Thus, the user can move the cursor not only to select which window is active, but also to invoke actions associated with the windows by positioning the cursor at a desired location in a given window. Depending on the window location, the ALU 42 will either directly activate an associated set of instructions for processing on the CPU 14 or secondary CPU or await user selection of an action through the use of the pointer-based device buttons. Thus, in response to a change in cursor position and/or activation of a pointer-based device button, the ALU 42 generates the detection signal 48 representing the associated change in state, i.e., change in active window, selection of a grid element, selection of a window object such as a menu option, or the like. This signal 48 is transferred to the main CPU 14 or to a sub CPU 50.

The main CPU 14 or the sub CPU 50 then performs internal control operations necessary for automatically executing the desired activity. Which of the CPU's is used may depend on the type of action requested, on the number of instruction associated with the action, or other routing criteria for maximizing system efficiency. Of course, the new state of the system will be manifest in the window priority memory 40.

The sub CPU 50 is connected to the window priority memory 32 as well as to the refresh image memory 26. Upon completion of rewriting the contents of the window priority memory 40, the sub CPU 50 secures a memory region in the image memory 26 that corresponds to the position and the size of the currently-active window and all other opened windows.

Information and/or instructions in the form of character data and/or graphic data entered by the user using either the keyboard 10 or the pointer-device 16 are temporarily stored in an internal data memory 54 of the window presentation controlling section 30 through a data bus 52 for keyboard entered information and through a data bus 56 from sub CPU 50 for point-based entered information. Depending on the type of information entered, sub CPU 50 accesses memory 54 and read outs from the memory the information (e.g., character data, menu selections, window object and/or attribute selection, etc.) that has been entered and is either to be written on or in a given window or is being retrieved from the activation of some window object like a grid element of a grid. The entire read-out information is transferred, under the control of the sub CPU 50 or the main CPU 14, to the refresh image memory 26 and stored in the memory region there that has been secured for the active window. In a similar manner, information entered by the user from either input device will cause the system to execute the need instructions to modify the display screen or to update the display screen with additional windows or options depending of the information entered by the user. For example, if the user positions the cursor in the grid shown in FIG. 3 and selects the boxed grid element, the system of the present invention will relate the cursor position to the window coordinates to determine the grid element selected and transfer the information represented by the grid element to the main CPU 14 or the sub CPU 50 for the construction of the search query, generate the instructs necessary to execute the search on the data set, and to display the search results on the display screen S of the CRT 18.

For example, some hardware may be replaced where necessary by software program as needed, without departing from the basic technical principle of the aforementioned auto-window presentation. In this example, it is likely that the active window switching speed can be increased by improving the processing ability of involved CPUs. Further, ALU 42 is not restricted to perform the correlation between the present-cursor position data with the window coordinate data defining the position and the size of each window, only in the aforementioned manner; this correlation may also be modified in various ways.

Referring to FIG. 2, a server environment is depicted including a server 60 running a windowing operating system such as OS/2. The server 60 supports an administrator node 62 and two user nodes 64 and 66. The administrator and user nodes can be OS/2 nodes or nodes with other operating systems and appropriate communication software. The server 60 can also support access to local area networks such as an IBM LAN 68 and database access such as database 70. In addition to the associated hardware, the server 60 can support either resident or distributed applications software programs such as cc:Mail 72, Notes 74, TaP 76, VDL 78, mail 80, and Fax 82. In addition, the server 60 can also support open APIs 84.

Referring to FIG. 3, a CUI window display presentation, generally 100, of one embodiment of the CUI of the present invention is shown. The CUI 100, includes a user identification box 102, a plurality of pull down menus 104 including a Person menu 106, a Edit menu 108, and a Help menu 120, and a plurality of function icons 122. The underlined letter of the pull down menu descriptors indicate that the menus can be invoked by merely typing the underlined letter instead to using a pointer-based device to reveal the menu selections. The CUI 100 also includes a user profile window 124 with a plurality of right tabs 126 and optionally a plurality of bottom tabs 128, not shown. The CUI 100 also is shown as a book or set of overlaid fanned cards showing the cards beneath the currently displayed card. The right tabs 126 represent current applications. The bottom tabs 128 can represent other attributes of the user profile window 124 such as special groups and special classes of users.

The user profile window 124 includes last name, first name, middle initial, and preferred name boxes, 130, 132, 134, and 136, respectively. The user profile window 124 also includes network name, user ID, and password boxes 138, 140, and 142, respectively. Further, the user profile window 124 includes office phone, office fax, and fax route code boxes 144, 146, and 148, respectively. The user profile window 124 includes manager and department boxes, and primary mail type, primary mail address, primary calendar address, and alternate IDs or aliases 150, 152, 154, and 156, respectively. Of course, many of these boxes are only representative of a particular user profile window. One of ordinary skill would recognize that the particular box configuration and box descriptions are solely a function of the inventors layout in this embodiment and other presentations and configurations are fully within the teaching and scope of the present invention.

As shown in FIG. 4, the right tabs 126 include one tab for each of the applications which are registered to the server to which the CUI is attached. For the sake of clarity, FIG. 4 shows five right tabs 126: WorkGroup, LS 3, DocLib, cc:Mail, and Notes 158, 160, 162, 164, and 166, respectively. Of course, the tabs could equally well represent other applications used in other compute environments and because the CUI can be tailor made for each particular computer and compute environment, the exact description associated with the tabs may change from environment to environment and are designed at installation or upon updating the datafile as described more completely below.

If a user or administrator wanted to check the current information for the selected user for the WorkGroup tab 158, the user or administrator would either use a pointer-based device to select the WorkGroup tab or type a "w" on the keyboard. Once the WorkGroup tab 158 has been selected the CUI 100 brings a WorkGroup profile window 168 to the forefront of the profile area 170 of CUI 100, as shown in FIG. 4. FIG. 4 shows the depiction of the WorkGroup profile window 168 including an Available Applications box 172 with available entries 174, an Enrollment Applications box 176, and Add and Remove icons 178 and 180, respectively, for adding and removing WorkGroup enrollments or application. Boxes 172 and 176 also include up and down list scrollers 182 for scrolling enrollment and application lists. The WorkGroup profile window 168 shows right tabs 126 and bottom tabs 128. Of course, right tabs 126 are identical to the tabs shown on the user profile window 124. Bottom tabs 128 are profile window specific and designate selections available for a given tabbed application. Of course, bottom tabs 128 are optional for each profile window.

The CUI 100 also includes a close icon 184, a maximize icon 186, a minimize icon 188, and up and down page scroll icons, 190 and 192, respectively.

The datafile and CUI are not a built in feature of the operating system and must be first installed on the computer system so that application and user profile information can then be centrally located and accessible for efficient manipulation and system environmental control. Referring now to FIG. 5, a flow chart 200 of the installation protocol for installing the CUI of the present invention is depicted. The installation protocol depicted in the flow chart 200 includes the steps of starting the initialization procedure 210, initializing the system software or operating system 212, obtaining an application list from the system software 214 and obtaining the details for each application from the system software 216.

Once these steps are executed, which normally occurs only one time and generally during the installation of the LUAIP software used to implement the methods of the present invention, the LUAIP is ready for interaction with a user or a system administrator. Of course, the available procedures that the user can access as opposed to the system administrator will be different as further defined below. Additionally, the software of the present invention can provide for user groups with differing access privileges.

With installation complete, the LUAIP goes into a semi-hibernation state or monitoring state 218 awaiting a user or administrator selected event. When the CUI is activated the monitoring state 218 passes the received information onto a user type discriminator or user type conditional branch 220. The conditional branch 220 tests the user name for determine the user's status or type. If the user is an administrator or has administrator privileges, then the conditional branch 220 passes control to an Administrator branch 222, otherwise control is passes to the End User branch 224.

The administrator then can select one of three manipulation methods: an Add User method 226, an Update User method 228, and a Delete User method 230. An end user can only perform one manipulation method, an Update Self method 232. These methods are described more completely below. Each method includes several steps to perform the given or assigned task. Once the selected method has been invoked and appropriate information sent to the datafile, the LUAIP performs the necessary actions in a perform action step 234 which completes the selected task and goes back to the event monitoring step 218. Thus, the LUAIP is an installed methodology which centrally localizes user and application information in a datafile associated with a database previously or currently installed on the computer system and allows for the manipulation of the localized information by the user by and through the activation of menu options and icons associated with the CUI.

Referring now to FIG. 6, a flow chart 240 of the Add User method 226 of FIG. 5 is depicted. If activated from the monitoring loop of FIG. 5, the Add User method 240 adds a designated user to the address book in step 242 and then analyzes the resulting transaction in step 244. The Add User method 240 then performs a conditional branch 246 to determine whether the added user is to be enrolled in any system applications. The conditional branch 246 passes control to a generate enrollment request step 252 due to a yes condition in branch 246 through the yes branch path 248. In the case of a no condition, the branch 246 transfers control to the commit changes to the datafile (DB) step 268 via a no branch path 250. The application enrollment branch 248 begins with step 252 which generate an enrollment request or obtains the information that the administrator has entered through the activation or selection of the appropriate menu options, icons, boxed or tabbed fields associated with the CUI. Once a generate enrollment request has been received the request is sent to the appropriate or designated application in a send to application step 254. The enrollment path 248 then waits for the application to response to the enrollment request in step 256. When the application responds, the response is analyzed in a conditional status check step 258. The status check 258 determines whether the enrollment was successfully accomplished or failed. If the enrollment is successful, the status check 258 passes control to a send next step 266 through a path 260. If the enrollment fails, the status check 258 passes control to an error handling logic unit 264 through path 262. The send next step 266 determines whether additional enrollments have been specified. If additional enrollments are specified, then the send next step 266 transfers control back to the generate enrollment request step 252 via the return path 267. If no further activity is requested, then the sent next step 266 transfers control to the commit step 268 which commits the changes to the datafile in the database DB and then returns control back to the designated part of FIG. 5 in a return step 269.

Referring now to FIG. 7, a flow chart 270 of the Update User method 228 of FIG. 5 is depicted. The Update User method 228 first locks the selected user data entry in the datafile on the installed database in a locking step 272. The system administrator or qualified user then makes the designed changes in a changing step 274. The changes made in step 274 are then analyzed in a transaction analyze step 276. The analyze step 276 analyzes the requested changes to determine whether the changes are directed to the selected user address book (AB in the FIG. 7) or an add or update user enrollments. Once the analysis step 276 is performed, the analysis and change data is passed onto a update AB conditional branch 278 which performs a logical test to determine the type of designated changes. The branch 278 passes control to either an update AB step 284 along a yes path 282, where yes represent that the change is to the user AB entry, or an add or update enrollment conditional branch 286 along a no path 280. Conditional branch 286 operates in an analogous fashion to conditional branch 278. The branch 286 passes control to either a generate enrollment request step 292 along a yes path 288 or a commit changes to the datafile in the installed database DB and unlock the locked record step 308, along a no path 290. In a sequence of flow steps analogous to steps 226 through 269 of FIG. 6, steps 292 through 309 perform the sequence of steps to send the enrollment request to the application, step 294, to wait for the application response, step 296, and to check the application response status in a conditional branch step 298 that passes control to the error handling logic 304, which is generally the same logic unit as that in described and shown in FIG. 6, along an error path 302. If the status check is successful the sequence proceeds to send next request step 306 along a success path 300 which either returns control to the generate enrollment request step 292 or to the commit step 308. The commit step 308 after performing its indicated function, returns control to the flow chart of FIG. 4 via a return step 309.

Referring now to FIG. 8, a flow chart 310 of the Delete User method 230 of FIG. 5 is depicted. If activated from the monitoring loop of FIG. 5, the Delete User method 310 deletes a designated user from the address book in step 312 and then analyzes the resulting transaction in step 314. The Delete User method 310 then performs a conditional branch 316 to determine whether the deleted user is to be de-enrolled from any system applications to which that user had been previously enrolled. The conditional branch 316 passes control to a generate delete request step 322 due to a yes condition in branch 316 through a yes branch path 318. In the case of a no condition, the branch 316 transfers control to a commit changes to the datafile in the installed database (DB) step 338 via a no branch path 320. The application delete branch 318 begins with the step 322 which generate an delete request or obtains the information that the administrator has entered through the activation or selection of the appropriate menu options, icons, boxed or tabbed fields associated with the CUI. Once a generate delete request has been received the request is sent to the appropriate or designated application in a send to application step 324. The delete path 318 then waits for the application to response to the delete request in a wait for response step 326. When the application responds, the response is analyzed in a conditional status check step 328. The status check 328 determines whether the delete was successfully accomplished or failed. If the delete is successful, the status check 328 passes control to a send next step 336 through a success path 330. If the delete fails, the status check 328 passes control to an error handling logic unit 334 (generally, the same error handling logic unit in FIGS. 5-7) through an error path 332. The send next step 336 determines whether additional deletes have been specified. If additional deletes are specified, then the send next step 336 transfers control back to the generate delete request step 322 via a return path 337. If no further activity is requested, then the sent next step 336 transfers control to the commit step 338 which commits the changes to the datafile in the datafile on the installed database DB and then returns control back to the designated part of FIG. 5 in a return step 339.

Referring now to FIG. 9, a flow chart 340 of the Update Self method 232 of FIG. 5 is depicted. The Update Self method 340 first locks the selected user data entry in the datafile on the installed database in a locking step 342. The user then makes the designed changes in a changing step 344. The changes made in step 344 are then analyzed in a transaction analyze step 346. The analyze step 346 analyzes the requested changes to determine whether the changes are directed to the selected user address book (AB in the FIG. 9) or to an add or update user enrollments. Once the analysis step 346 is performed, the analysis and change data is passed onto a update AB conditional branch 348 which performs a logical test to determine the type of designated changes to be made. The branch 348 passes control to either an update AB step 354 along a yes path 352, where yes represent that the change is to the user AB entry, or an add or update enrollment conditional branch 356 along a no path 350. The conditional branch 356 operates in an analogous fashion to conditional branch 348. The branch 356 passes control to either a generate enrollment request step 362 along a yes path 358 or a commit changes to the datafile in the installed database DB and unlock the locked record step 378, along a no path 360. In a sequence of flow steps analogous to steps 226 through 269 of FIG. 6, steps 362 through 379 perform the sequence of steps to send the enrollment request to the application, step 364, to wait for the application response, step 366, and to check the application response status in a conditional branch step 368 that passes control to the error handling logic 374, which is generally the same logic unit as that in described and shown in FIG. 6, along an error path 372. If the status check is successful the sequence proceeds to send next request step 376 along a success path 370 which either returns control to the generate enrollment request step 362 or to the commit step 378. The commit step 378 after performing its indicated function, returns control to the flow chart of FIG. 5 via a return step 379.

Although several manipulation methods have been described in detail and shown in flow chart format in relationship to the start flow chart shown in FIG. 5, one of ordinary skill in the art would recognize that other manipulation methods could easily be added to the flow chart of FIG. 5.

While in accordance with the patent statutes, the best mode and preferred embodiments of the invention have been described, it is to be understood that the invention is not limited thereto, but rather is to be measured by the scope and spirit of the appended claims.