|Publication number||US7203905 B2|
|Application number||US 10/322,094|
|Publication date||Apr 10, 2007|
|Filing date||Dec 17, 2002|
|Priority date||Dec 17, 2002|
|Also published as||US20040113940|
|Publication number||10322094, 322094, US 7203905 B2, US 7203905B2, US-B2-7203905, US7203905 B2, US7203905B2|
|Inventors||Brandon Brockway, Michael Richard Cooper, Jason Robert Kersten, Kumar Ravi|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (61), Non-Patent Citations (7), Referenced by (5), Classifications (6), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Technical Field
The present invention relates in general to a system and method for controlling user access to a computer operating environment. In particular, the present invention relates to a system and method for providing a platform-neutral shell application that prevents user access to an underlying operating system.
2. Description of the Related Art
Modern computer software systems often include distributed computing components such as client computer systems and server computer systems. Large organizations may, through time, deploy a number of operating system environments on computer systems distributed throughout the organization. For example, one area of the organization may use Microsoft Windows™ based operating systems on client computers, while another area may use a UNIX-based operating system, such as Linux. Areas may choose different operating system platforms based upon the work being performed by such areas, or based upon purchasing decisions made by management or IT staff.
Computer software systems have computer systems that are often linked to one another using a computer network, such as a local area network (LAN) and/or a wide area network (WAN). Computer systems distributed throughout the organization may communicate with one another using a global computer network, such as the Internet. Communication between computer systems, also called nodes, may be encrypted using technology such as Virtual Private Networks (VPNs) that use encryption to safeguard data that travels over the Internet. In a client/server environment, end-users typically use client computer systems to communicate with applications stored on server computer systems using the computer network.
One challenge in developing software that is deployed on a variety of operating system platforms is designing a user interface that is similar across the various platforms. An enterprise-based system is often deployed across a variety of operating systems. Users of the enterprise-based application are more efficient and productive if the interface, or “look and feel”, of the application remains consistent regardless of the underlying operating system. In addition, a challenge of traditional systems is providing a consistent interface for launching native applications. In a banking example, a teller function may be a native application with a different native application used depending on the underlying operating system. Interface consistency and a common look and feel are helpful, therefore, in launching native applications from a variety of operating systems.
Another challenge in developing software that is deployed on a variety of platforms, is insulating the end-user from the underlying operating system. The computer systems distributed throughout the organization often allow the end-user to access the underlying operating system. As a result, end-users make changes to the operating system attributes and may deliberately or unintentionally add or delete files stored on the computer system used by the end-user. These changes may detrimentally affect the operation of the end-user's computer. In addition, these changes are often unexpected, and therefore unanticipated, by IT staff. As a result, IT staff may spend considerable time analyzing and troubleshooting the client computer system. This challenge is aggravated in environments where more than one person, or user, uses the same computer system to perform their job functions.
What is needed, therefore, is a system and method that provides a platform-neutral desktop environment that is deployed on client computer systems. Furthermore, what is needed is a system and method that locks the platform-neutral desktop environment, thus preventing the end-user from making changes to the computer's underlying operating system.
It has been discovered that the aforementioned challenges are resolved using a system and method that provides a platform-neutral shell application for a user interface. The platform neutral shell application is performed in a way that prevents the user from accessing the underlying operating system.
The desktop shell application executes as a middleware application, such as a Java virtual machine (JVM). The operating system residing on the client computer system is booted when the user turns the client computer system on, or resets the client computer system. The virtual machine middleware application (e.g., JVM) is loaded on the operating system platform. The virtual machine middleware application is programmed for the particular operating system being used by the client. The virtual machine middleware application is adapted to run platform-neutral software applications (e.g., Java applications). The shell application is invoked on the virtual machine middleware application. The shell application prevents the user from accessing the underlying operating system. The user is prevented from accessing the underlying operating system by maximizing the window in which the shell application is running, pinning the shell application window to the foreground, and removing controls from the desktop window which would otherwise allow the user to bypass the desktop shell.
In one embodiment, the platform-neutral shell application is used to receive and display desktop components included in self-contained desktop packages. The desktop components correspond to the functions performed by the user. In a banking example, one set of desktop components are provided for a teller, another set of desktop components are provided for a loan officer, and a third set of desktop components are provided for a branch manager. The desktop shell application receives the self-contained desktops from a server, unpacks the components, and displays them on the desktop shell application window. In addition, a user may perform multiple roles, in which case the user receives multiple desktops corresponding to the different roles. The desktop shell application provides a pop-up window allowing the user to switch from one set of desktop components to another.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.
The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention which is defined in the claims following the description.
Self-contained desktops 110 are transmitted to one or more servers 150 for dissemination to clients. Servers 150 combine user roles 155 with workstation roles 160 to determine which self-contained desktops to send to clients. Clients 165 perform login function 170 during which the user ID, and password are gathered and transmitted to servers 150 to effectuate a login. Clients 165 perform login function 170 during which the user ID and machine ID are gathered and transmitted to servers 150 to receive a list of allowed desktops.
Servers 150 receive the user ID, password, and machine ID from clients and determine which self-contained desktops to transmit to the clients based upon the user roles 155 and the workstation roles 160 that correspond to the particular user ID and the particular workstation being used by the client. The identified self-contained desktops are responsively transmitted from server 150 to client 165.
Client 165 performs load shell process 175 to load shell application 180 onto the client workstation. The shell process is an application that is loaded onto a middleware application, such as a Java virtual machine (JVM). In this manner, the shell application appears consistent and substantially similar regardless of the operating system platform being used by the client workstation. Shell application 180 is adapted to retrieve and display self-contained desktops 190. Client 165 receives self-contained desktops based upon the intersection of the user and the workstation identifiers. The self-contained desktops are received and displayed using process 185. A given client can therefore utilize multiple self-contained desktops. These self-contained desktops include toolbars, menus, and other graphical user interface items used to communicate with the user. Some of these user interfaces include functionality that communicate with server applications hosted by servers 150. Other user interfaces include extensions that map to client-based applications 195. When a user clicks on a desktop component that maps to a client-based application, functionality exists within the self-contained desktop to invoke, or otherwise use, the client-based application. If a client has multiple self-contained desktops at its disposal, the user can switch between the various self-contained desktops by using a menu provided by shell application 180. For example, in a banking environment if a user is both a loan officer and a branch manager both of the corresponding self-contained desktops for these roles would be loaded into shell 180 provided that the workstation is capable of performing both of these roles. To perform loan officer functions, the user selects the loan officer desktop from shell application 180. Likewise, to perform branch manager functions, the user selects the branch manager desktop from shell application 180. In addition, a default role can be provided so that the initially displayed desktop corresponds to the user's primary, or default, role.
User definitions 220 are used to define the users of the system and the roles such users perform. User definitions 220 include user data 225 and assigned group data 230. User data 225 includes user identifiers and user passwords. Assigned group data 230 includes the roles a particular user is allowed to perform. For example, a branch manager may be allowed to perform branch manager, loan officer, and teller functions while a teller may only be allowed to perform teller functions.
Site definitions 235 include information about a particular site. In a banking environment, a site may be a branch office of the bank. Site definitions 235 include group desktop map 240 that provides a common desktop for users at a particular site as well as site information 245 that provides details concerning the site.
Desktop definitions 250 include components used to create self-contained desktops that are used by clients. Desktop definitions 250 include images 252 that are displayed on the self-contained desktop, and application extensions 254 that provide details about client-based applications that are accessible from the self-contained desktop. Desktop definitions 250 also include resources, such as national language translations 256, so that users are able to select the resources, such as a language preference, that best fits their needs. Desktop definitions 250 also include client configurations 258 and server configurations 260. These configurations include information about the components included with a particular self-contained desktop.
Administrator 200 creates self-contained desktops and publishes the self-contained desktops on one or more servers 265 that are accessible by clients. Server 265 includes persistent storage 270 and authentication function 280. Persistent storage 270 includes user data 272, topology information 274, and self-contained desktops 276. The user data and topology data are used to determine which self-contained desktops 276 are allowed to be used by a given client using a given workstation. Server 265 provides desktops which are authorized for particular user/workstation to client 290. The self-contained desktops are received by the client and displayed on platform independent shell 295. In this manner, server 265 sends identified desktops to client 290 without regard to the particular operating system platform being used by the client.
Resources that are needed by clients, such as national language translations, are set up so that the resources can be included in self-contained desktops (predefined process 330). Application extensions corresponding to applications available from a workstation are defined (predefined process 340, see
A determination is made as to whether a new site is being added (decision 360). If a new site is being added, decision 360 branches to “yes” branch 365 whereupon a new site is defined (predefined process 370, see
The defined desktop is mapped to one or more sites and one or more roles (predefined process 380). In this manner, a single desktop can be used at multiple sites for multiple roles. Conversely, a different desktop can be defined and used at each site and for each role. The desktop components are packaged into a self-contained desktop and the self-contained desktop is published to one or more servers for dissemination to the various clients (predefined process 390, see
Policies that were either retrieved or set for a particular site can be modified according to the particular site's needs (step 430). In this manner, a site can have slightly different policies from those of a parent site. Sites have one or more roles that are performed by users working at sites. In a banking environment, a branch office site may have roles such as a teller, a loan officer, and a branch manager. The first role for the site is selected (step 435). A determination is made as to whether the role needs to be modified (decision 440). If the role needs to be modified, decision 440 branches to “yes” branch 445 whereupon a self-contained desktop is selected for the role (step 450). On the other hand, if the desktop does not have to be modified for the role, decision 440 branches to “no” branch 455 bypassing step 450. In this manner, the child site uses the same desktop as the parent site for a particular role, yet the administrator has the flexibility to assign a different desktop to the child site for a given role.
A determination is made as to whether there are more roles for the site (decision 460). If there are more roles, decision 460 branches to “yes” branch 465 whereupon the next role for the site is selected (step 470) and processing loops back to process the next role. This looping continues until there are no more roles for the site, at which point decision 460 branches to “no” branch 475 whereupon the desktops and other data selected for the site are stored (step 480). Processing then returns at 495.
A role is selected for the user (step 525) from a list of roles that has been created by the administrator and stored in data store 530. A determination is made as to whether the selected role is the default role for the user (decision 540). If the selected role is the default role for the user, decision 540 branches to “yes” branch 545 whereupon the selected role is assigned as the default role for the user (step 550). On the other hand, if the selected role is not the default role, decision 540 branches to “no” branch 555 bypassing step 550.
A determination is made as to whether there are more roles to assign to the user (decision 560). If there are more roles to assign to the user, decision 560 branches to “yes” branch 565 which loops back to select and process the next role for the user. This looping continues until there are no more roles to assign to the user, at which point decision 560 branches to “no” branch 570 whereupon the roles assigned to the user are stored (step 580). Processing then returns at 595.
The first role for the workstation is selected (step 650) from a list of roles that was created by the administrator and stored in data store 660. For example, in a banking environment, roles may include a teller, a loan officer, and a branch manager. One workstation may be capable of performing all three roles, while another is only capable of performing one or two of the roles. Furthermore, confidential or sensitive functions may be restricted to a particular workstation even though other workstations may be physically capable of performing such functions. A determination is made as to whether there are more roles to assign to the workstation (decision 670). If there are more roles to assign to the workstation, decision 670 branches to “yes” branch 675 whereupon the next role for the workstation is selected (step 680). This looping continues until there are no more roles to assign to the workstation, at which point decision 670 branches to “no” branch 685. The assigned roles and workstation data are stored (step 690) in a nonvolatile storage area. Processing then returns at 695.
A determination is made as to whether the extension is provided by the system or is provided by the user (decision 720). If the extension is provided by the user, decision 720 branches to user branch 725 whereupon the Java archive (JAR) filenames corresponding to the extension are entered (step 730). On the other hand, if the extension is system supplied, decision 720 branches to system branch 735 bypassing step 730.
A determination is made as to whether an administrator object oriented class is needed (decision 740). If an administrator class is needed, decision 740 branches to “yes” branch 745 whereupon the administrator class name is entered (step 750). On the other hand, if an administrator class is not needed decision 740 branches to “no” branch 755 bypassing step 750.
The application extension is created using the supplied information (step 760). A determination is made as to whether there are any default properties for the application extension (decision 770). If there are default properties, decision 770 branches to “yes” branch 775 whereupon the default properties are entered for the application extension (step 780). On the other hand if there are no default properties for the application extension, decision 770 branches to “no” branch 785 bypassing step 780.
The application extension, along with any default properties, is stored (step 790) in a nonvolatile storage area. Processing then returns at 795.
Application references that will be available from the desktop are selected (step 940) from application references 945 included in desktop component library 925. In a banking environment, a teller's desktop can include application references to look up customer bank balances and operate the teller's cash drawer, while a loan officer's desktop can include application references that provide access to the bank's loan approval software application. National language data, such as text and resources, are provided for each supported locale (step 950). These resources are selected from resources 955 that are included in desktop component library 925.
The desktop configuration is stored detailing the files and resources included the desktop (step 960). A client configuration file describing the desktop is created and the desktop data is packaged (step 970) resulting in self-contained desktop 975. The resulting self-contained desktop is published to client-accessible servers (step 980) by transmitting the desktops to servers 990. Processing then returns at 995.
A determination is made as to whether any roles assigned to the user match any roles assigned to the workstation (decision 1030). If there are no roles in common, decision 1030 branches to “no” branch 1035 whereupon an error is returned to the client (step 1038) and processing returns at 1095. On the other hand, if there are one or more roles in common, decision 1030 branches to “yes” branch 1040 whereupon the first desktop for the selected role is retrieved from desktop/role map 1050 and the corresponding self-contained desktop is retrieved from data store 1055. A determination is made as to whether there any more roles in common between the user and the workstation (decision 1060). If there are more roles in common, decision 1060 branches to “yes” branch 1070 whereupon the next common role is selected (step 1080) and processing loops back to retrieve the corresponding self-contained desktop. This looping continues until there are no more roles in common between the user and workstation, at which point decision 1060 branches to “no” branch 1065 whereupon the retrieved desktop identifiers (i.e. those identifiers in common for both the user and the workstation) are sent to the client (step 1090). Processing then returns at 1095.
Desktop frame 1140 includes information about the roles and desktops available at the site. Desktop frame 1140 includes role data 1155, desktop data 1160, and inheritance data 1170. The inheritance data includes the name of the desktop that is inherited 1175 and the name of the ancestor 1180 from which the desktop is inherited. In the example shown, the roles included at the site include the administrator, a branch manager, a guest, a loan officer, and a teller. Each of the desktops is inherited from the parent site as shown by the “[Inherited]” value for the desktop field. The administrator, branch manager, and loan officer desktops are inherited from “BranchA” site, while the guest and teller desktops are inherited from the “root” site. In this manner, self-contained desktops can be selected from a variety of parent sites or can be specifically configured for the child site.
When the new site data has been entered, the administrator selects “Create Site” command button 1190 to create the new site. If the administrator makes mistakes and wishes to reset the values, the administrator can select “Reset Values” command button 1195.
Desktop frame 1225 includes role data 1230, desktop data 1235, and desktop inheritance data 1240. In the banking example that is shown in
If the administrator changes the site data and wishes to store the changed site information, the administrator selects “Submit Changes” command button 1245. If the administrator wishes to reset the site values, the administrator selects “Reset Values” command button 1250. If the administrator wishes to delete the site, the administrator selects “Delete Site” command button 1255.
When the administrator is ready to publish the site to the servers, the administrator selects “Publish” command button 1260. If the administrator wishes to publish the site along with any sites that are children of the site, the administrator selects “Publish with Children” command button 1265.
Child sites frame 1270 includes data regarding any sites that are children of the site. Child site data includes site name 1272 and site policies 1278. To create a new child site, the administrator can select “<New Site>” hyperlink 1275 which will allow the administrator to identify a new child site.
Machines frame 1280 includes data about workstations included at the site. Workstation data includes the workstation identifier 1282, the host name for the workstation 1284, the workstation type 1286, the roles provided by the workstation 1288, the workstation's IP address 1290, and the workstation description 1292. To add a new machine (workstation) to the site the administrator selects “<New machine>” hyperlink 1295.
A new initial password is entered for the user in text box 1320. This new initial password is confirmed by the administrator by reentering the password in text box 1325. A default locale is selected by the administrator for the user using list box 1330. In the example shown, the locale has been selected to be a U.S. locale for a user speaking U.S. English. However, if the user's primary language was Spanish or some other language, the appropriate locale is selected from the list provided in list box 1330.
Frame 1332 is used by the administrator to select the roles that correspond to the user. Default role 1335 includes a number of radio buttons corresponding to each of the available roles. Radio buttons are used so that the administrator only selects one default role for the user. Select column 1340 includes a number of checkboxes corresponding to each of the available roles. The administrator selects each of the checkboxes corresponding to each role that is performed by the user. Name column 1345 includes the name of each of the available roles. In the example shown, the available roles include an administrator, branch manager, the guest, a loan officer, and a teller. The administrator can select one or more of these roles by selecting the corresponding checkboxes in column 1340. In addition, the administrator can establish a new role by selecting “<New Role>” hyperlink 1350.
When the administrator is finished entering the user data and assigning roles to the user, the administrator selects “Create User” command box 1355 to create and store the user data and assigned roles. If the administrator makes mistakes and wishes to reset the values, “Reset Values” command button 1360 is selected.
A description of the application that is being defined is entered in description text box 1410. Icon attributes frame 1415 is used to define the attributes corresponding to the icon that will appear on the desktop and be used by the user to select the application. Icon attributes include a title that is entered in text box 1420 and an icon filename that is entered in text box 1425.
Platform properties frame 1430 includes data for each of the supported operating system platforms from which the application can be invoked. Win32 frame 1435 includes data which is used to invoke and execute the application from a Microsoft Windows operating system platform. The Win32 data includes a path and filename identifying the executable form of the application in the Win32 environment. The path and filename is entered in text box 1440. Any parameters that are needed for the application are supplied in parameters text box 1445. A working directory that corresponds to the application, if needed, is entered in text box 1455.
Platform properties frame 1430 also includes data for the OS/2 operating system platform, the fields for which are located in frame 1460. The OS/2 fields correspond to the Win32 fields described above. These include path and filename text box 1465, parameters text box 1470, and working directory text box 1475. Likewise, a Linux set of fields is provided in frame 1480 which includes path and filename text box 1482, parameters text box 1484, and working directory text box 1486.
When the application information has been entered by the administrator, the administrator can create the application by selecting “Create Application” command button 1490. If the administrator makes mistakes, a new application values can be reset by selecting “Reset Values” command button 1495.
A launch mode for the self-contained desktop is selected by the administrator using list box 1515. The launch mode indicates the number of mouse clicks needed to activate a component from the desktop. In the example shown, the launch mode selected is “2” (i.e., a double-click). Icon attributes are entered in frame 1520. Maximum allowable and displayable icon title lengths are entered by the administrator in the appropriate text boxes.
Background appearance information is entered by the administrator in frame 1525. The color, image file, and image display mode are provided by the administrator for the background of the self-contained desktop. For example, desktop background data can include the name and logo of the organization. Icon appearance information is entered by the administrator in frame 1530. Icon appearance data includes the text color of the icon, the font that is used with the icon, the font size that is used with the icon, the font style that is used to the icon, the icon flow, the origination point of the icon flow, and the text position for the icon text.
When the administrator has completed setting up the self-contained desktop, the administrator selects “Submit Changes” command button 1540 to save the desktop settings. If the administrator makes mistakes or wishes to reset the values, the administrator selects “Reset Values” command button 1545. If the administrator wishes to delete the self-contained desktop definition, the administrator selects “Delete Desktop” command button 1550.
Hyperlink 1560 is used to add, modify, or delete references that are available from the self-contained desktop. The references that are available include applications 1570, folders 1580, and toolbars 1590. In the example shown, the applications that had been included consist of “acroread,” “calculator,” and “browser.” The folders that are included consist of an applications folder, and two administrator folders. One toolbar, the Admin Toolbar, is also included.
The identifiers shown in column 1610 are unique for each workstation. In the example shown in
Server responses resulting from the previously sent desktop request are received by the administrator (step 1730). A determination is made based upon the response as to whether the desktop already exists at the server (decision 1735). If the desktop does not yet exist at the server, decision 1735 branches to “no” branch 1738 whereupon the identified desktop is sent to the server in a data stream (step 1740). On the other hand, if the desktop already exists at the server decision 1735 branches to “yes” branch 1742 bypassing step 1740.
A determination is made as to whether there are more responses to receive from servers regarding the desktop request (decision 1745). If there are more responses, decision 1745 branches to “yes” branch 1746 to loop back and process the responses. This looping continues until there are no more responses to process, at which time decision 1745 branches to “no” branch 1748 and administrator desktop distribution processing ends at 1750.
Server desktop collection processing commences at 1755 whereupon the server receives the desktop distribution request sent by the administrator (step 1760). The unique identifier for the desktop included in the administrator's request is compared with desktop data 1768 that is currently on hand at the server (step 1765). A determination is made based upon the comparison as to whether the desktop is needed by the server (decision 1770). If the desktop is not needed (i.e. the desktop already exists at the server) decision 1770 branches to “no” branch 1772 whereupon a message is sent to the administrator indicating that the server already has the desktop (step 1775) and server processing ends at 1795.
On the other hand, if the server does not yet have the desktop decision 1770 branches to “yes” branch 1778 whereupon the server request the desktop (step 1780). The server receives the desktop data stream in response to the request (step 1785). The server then creates a self-contained desktop file from the received data stream and stores the desktop file in desktop data storage area 1768 (step 1790). Server desktop collection processing then ends at 1798.
Server desktop distribution processing commences at 1840 whereupon the server receives the desktop list request from the client (step 1845). The server looks up the roles that have been assigned to the user (step 1850) by searching user roles data store 1852. The server also looks up the roles that have been assigned to the workstation being used by the user (step 1855) by searching machine roles data store 1858.
The server retrieves desktop information based upon the intersection, or overlap, between the user roles and the machine roles (step 1860) and locates the desktops that correspond to the overlapping roles in desktop data store 1862. The desktop information that is retrieved includes a desktop identifier and a desktop signature, such as a CRC, that is used to uniquely identify the desktop. A user may have a default role and a default desktop that corresponds that role. If the user has a default role, the server determines the default role (step 1865).
The server creates a response string (step 1870) of valid roles, desktop signatures, a default desktop identifier (if applicable), and a default role (if applicable). The server then returns the response string to the client (step 1875).
The client receives the desktop list that includes the roles that have been assigned to both the user and the workstation along with any default role and default desktop information from the server (step 1810). The client compares the desktops included in the desktop list with desktops that have already been cached on the client workstation (step 1815). This is done so that the client only needs to request those desktops that have not previously been transmitted to the client workstation and cached in the workstations volatile or nonvolatile storage areas.
The client determines whether additional components, or desktops, are needed from the server by identifying such desktops or components that have not yet been cached on the client workstation (decision 1820). If the client determines that no additional desktop components are needed, decision 1820 branches to “no” branch 1832 (bypassing the steps used to request and retrieve additional desktop information) and client processing ends at 1835.
On the other hand, if the client needs additional components or desktops, decision 1820 branches to “yes” branch 1822 whereupon the needed desktops are requested from the server (step 1825). This request is received by the server at server step 1885. The server responds by retrieving the request desktop information from desktop data store 1862 and returning it to the client workstation (step 1890). The server desktop distribution processing then ends at 1895.
Returning to client processing, the client receives and caches the requested desktop information at step 1830 and client desktop reception processing ends at 1835.
A determination is made as to whether additional resources are needed for the custom application extensions (decision 1950). If additional resources are needed, decision 1950 branches to “yes” branch 1955 whereupon the additional resources used by the application extension are provided (step 1960). The additional resources may include images, property files, and other class files used by the application extension. On the other hand, if additional resources are not needed decision 1950 branches to “no” branch 1965 bypassing step 1960.
The client classes, server classes, and any additional resources are packaged in Java archive (JAR) files (step 1970). The packaged custom extensions are stored in custom extensions library 1980. The creation of custom application extension process ends at 1995.
During the next phase of the application extension lifecycle, the application extension initializes (step 2050). During the initialization phase, the initialized method corresponding to the application extension is defined in the component interface. References to component configuration items, initial locale information, and desktop references are also provided. Desktop references are preferably saved as instance variables during this phase.
During the final phase of the application extension lifecycle, the start method corresponding to the application extension is invoked (step 2075). The start method is called by the desktop. For example the start method may be called when the icon corresponding to the application extension is selected by a user. During this phase, the application extension may use desktop references as well as references to other desktop components. In addition the application extension may at this time start threads and perform I/O operations.
In the example shown in
In the example shown in
The components and resources are packaged (step 2215) into various self-contained desktops for use by various users based upon the users' roles. The self-contained desktops are stored in self-contained desktop library 2225. The self-contained desktops are distributed (step 2220) to various servers. Administrator distribution processing ends at 2230. Further detail regarding the distribution of self-contained desktops can be found in
Server reception of self-contained desktops commences at 2235 whereupon the server receives the self-contained desktop packages (step 2240) and stores the received packages in nonvolatile storage area 2245. The server then distributes self-contained desktops to clients has needed (step 2250). Further detail regarding the distribution of self-contained desktops to clients can be found in
At some point, a disaster event occurs destroying packages, resources, and components from the computer system and storage devices use by the administrator (step 2255). The self-contained desktop information is then recovered by the administrator using the recovery process commencing at step 2260. The administrator identifies unique packages that have been destroyed and are no longer stored on the administrator's computer system (step 2265). The identified packages are requested from the various servers (step 2270).
The servers receive desktop package requests from the administrator (step 2275). The requested desktop packages are retrieve from the server's nonvolatile storage area 2245 and transmitted to the administrator's computer system (step 2280) and server recovery processing ends at 2295.
The administrator computer systems receives the self-contained desktop packages sent by the servers and stores the received desktop packages in package library 2225 (step 2285). The self-contained desktop packages are unpacked and the components and resources that are included in self-contained desktop packages are used to repopulate components and resource libraries 2210 (step 2290). At this point, all packages, components, and resources that were previously distributed by the administrator have been recovered and stored in the appropriate libraries. Administrator recovery processing then ends at 2298.
A determination is made as to whether the received desktop is the default desktop for the client (decision 2320). If the receive desktop is the default desktop, decision 2320 branches to “yes” branch 2325 whereupon the received desktop is displayed on the client's display device (step 2330). On the other hand, if the received desktop is not the default desktop, decision 2320 branches to “no” branch 2335 bypassing step 2330.
A determination is made as to whether there are more desktops for the client machine to receive from the server (decision 2340). If there are more desktops to receive, decision 2340 branches to “yes” branch 2345 whereupon processing loops back to receive the next desktop (step 2350) and determine whether the next desktop is the default desktop. This looping continues until all needed desktops have been received from the server, at which point decision 2340 branches to “no” branch 2355.
A determination is made as to whether more than one desktop is accessible by the client (decision 2380). If more than one desktop is accessible, decision 2380 branches to “yes” branch 2385 whereupon the available desktop descriptions are inserted as items within a pop-up selection window that is accessible by the client (step 2390). For example, the user could “right” click in the desktop area using appointing device, such as a mouse, which would cause the pop-up menu to be displayed. The user could then select the desired desktop from the list provided in the pop-up menu (see
The server looks up the client's MAC address (step 2415) from workstation table 2420 that includes the roles that are allowed to be performed on various workstations. In the example shown, the workstation with a MAC address of “123” is allowed to perform both teller and loan officer functions, while the workstation with a MAC address of “456” is only allowed to perform branch manager functions.
A determination is made as to whether the client's MAC address was found in the workstation table (decision 2425). If the MAC address was not found, decision 2425 branches to “no” branch 2428 whereupon a determination is made as to whether client workstation registration is required by the system (decision 2430). If workstation registration is required, decision 2430 branches to “yes” branch 2430 whereupon an error is returned to the client (step 2435) indicating that the client's workstation is not registered and server processing ends at 2440. On the other hand, if workstation registration is not required decision 2430 branches to “no” branch 2442 and processing continues. Returning to decision 2425, if the client's MAC address was found in the workstation table, decision 2425 branches to “yes” branch 2445 and processing continues.
The first desktop that has been assigned to the user's identifier (user ID) is retrieved (step 2450) from user desktop table 2455. In the example shown, the user ID “Able” has been assigned to the “teller” role, while the user ID “Jones” has been assigned to the “teller,” “loan officer,” and “branch manager” roles. A determination is made as to whether the retrieved desktop assigned to the user is allowed to be used on the workstation that is being used by the user (decision 2460). If the desktop is allowed to be used to the workstation, decision 2460 branches to “yes” branch 2465 whereupon the desktop is sent to the client (step 2470). On the other hand, if the retrieved desktop is not allowed to be used on the workstation, decision 2460 branches to “no” branch 2472 bypassing step 2470.
A determination is made as to whether there are more roles, or desktops, that have been assigned to the user (decision 2475). If there are more roles that have been assigned to the user, decision 2475 branches to “yes” branch 2480 whereupon the next desktop assigned to the user is selected (step 2485) and processing loops back to determine whether the next desktop should be set to client. This looping continues until all desktops assigned to the user have been processed, at which point decision 2475 branches to “no” branch 2490 and server processing ends at 2495.
Server 2500 also performs desktop collection processing 2580 by receiving desktop information from administrator 2575. The desktop information is stored in desktop definition data store 2590. The desktop information includes self-contained desktops that, in turn, included desktop components and resources for use by client 2525.
Server 2500 receives authentication information from client 2525, such as a user ID and password, which is used to authenticate the client. Server 2500 performs authentication processing 2510 by checking the client's authentication information with authentication data that is located in authentication data store 2520. Once the client has been authenticated, the client receives access to client's data storage area 2540 which is stored on server 2500. The server provides access to the client's data storage by performing home directory access process 2530. In this manner, a user can access his or her data regardless of which workstation he or she is using.
Server 2500 performs desktop distribution process 2550 to determine which self-contained desktops to send to client 2525. Desktop distribution process 2550 is performed by comparing user roles stored in user role data store 2555 with workstation roles stored in workstation role data store 2560. Desktops, or roles, that are assigned to both the user and the workstation are distributed to the client. Server 2500 retrieves the desktop information from desktop data store 2590 and transmits the desktop information to client 2525.
Shell 2605 is a Java-based application that is adapted to run on any of the operating system platforms used in the system (e.g., Windows XP™, OS/2™, or Linux™). The shell makes a determination as to whether the client login is performed remotely through a server or locally (decision 2620). If the login is performed remotely, decision 2620 branches to “yes” branch 2622 whereupon the client receives desktops from the server (step 2625). In one embodiment, the desktops are received by first receiving a list of desktops and then retrieving individual desktops from the list.
The list, or map, of desktops is cached to local storage located on the client machine (step 2630). The received desktops are also cached to local storage (step 2635). Returning to decision 2620, if the desktops are not retrieved remotely, decision 2620 branches to “no” branch 2638 bypassing steps 2625, 2630, and 2635.
The desktops that have been assigned to both the user and the workstation are retrieved from local storage (step 2640). Local storage is used to store user desktop map 2660 and desktops 2670. Desktops are self-contained packages that include desktop components and resources needed to display and execute the desktop. The retrieved desktop information is used to create desktop objects (step 2645). Desktop class loader 2650 is used to create the desktop objects. Resources, such as national language translations, are loaded from the desktop information (step 2655). Desktop class loader 2650 is also used to load the needed resources.
At this point, the desktops assigned to the user in workstation have been retrieved and made available to the user within shell 2605. Desktop objects and resources have been extracted from the self-contained desktops and have been made available to the user through shell 2605.
Pop-up menu 2710 includes two items allowing the user to either change the desktop or display the shell version. Selecting the “Change Desktop” item causes the display of desktop selection menu 2720. The user selects the desktop that is desired by placing a check mark in the box beside the desired desktop. In the example shown, the “administrator” desktop is being displayed on the client display as evidenced by the check mark shown in desktop selection menu 2720. If the user wishes to change the desktop, for example to the branch manager desktop, the user simply uses a pointing device, such as a mouse, and places a check mark in the box next to the “branch manager” menu item.
Components 2750 may change depending upon the desktop that has been selected. For example, the “Branch Desktop Administrator” desktop component is displayed because the “Administrator” desktop has been selected. However, if another desktop, such as the “Teller” desktop, is selected, the “Branch Desktop Administrator” will no longer appear and will not be accessible from the display. In this manner, components for a selected role are displayed and accessible, while components used by a different role are not displayed and are not accessible. Moreover, components that are used by multiple roles are each available from the various desktops that correspond to the roles.
Desktop subdirectory 2815 is the directory in which self-contained desktop files are stored. In one embodiment, self-contained desktop files are packaged into Java archive (JAR) files. In this manner, all components and resources used by particular desktop are packaged and included in a self-contained desktop JAR file. Log subdirectory 2820 is used to store client-based logs that detail the actions taken by the client. “Conf” subdirectory 2825 is used to store initialization information used by the shell application. “Bin” subdirectory 2830 is used to store executables, such as program files, that are used to launch the shell application.
A Java-based lockdown shell is invoked (step 2940) to provide a desktop environment and prevent the user from accessing the underlying operating system being used by the client machine. Desktops that are assigned to both the workstation and the user are requested from a server (step 2945). Server 2950 receives requests and responds by sending self-contained desktops to the client. The client receives a response from the server (step 2955). The response may be an error or a list of desktops.
A determination is made as to whether an error was received from the server (decision 2960). If an error was received, decision 2960 branches to “yes” branch 2962 whereupon an error message is displayed on the client's display device (step 2965) and processing ends at 2995. On the other hand, if an error was not receive, decision 2960 branches to “no” branch 2968 whereupon a determination is made as to whether there are any desktops to display on the client's display device (decision 2970). If there are no desktops display on the client's display device, decision 2970 branches to “yes” branch 2972, the user is informed that there are no desktops to displayed (step 2975), and processing ends at 2995. On the other hand, if there are desktops assigned to the user and the workstation, decision 2970 branches to “no” branch 2978 whereupon the desktops are displayed on the client's display device (predefined process 2980) and processing ends at 2995.
A determination is made as to whether the user was authenticated (decision 3020). If the user was not authenticated, decision 3020 branches to “no” branch 3025 whereupon processing ends at 3030. On the other hand, if the user was authenticated, decision 3020 branches to “yes” branch 3035 to continue initialization.
The virtual machine application, such as a Java virtual machine, is invoked on the client workstation (step 3040). A lockdown process is launched in the Java environment in order to lock the shell and prevent the user from using the underlying operating system without using the shell environment (step 3045). The server is queried for the desktops have been assigned to the user/workstation (step 3050). The client receives a list of available desktops and compares the listed desktop information with desktop data that has already been cached on the client workstation (step 3060). Desktops that are included in list but not yet cached on the client workstation are retrieve from the server and cached on the client workstation (step 3070). The received desktops are stored in client accessible cache 3075. An initial, or default, desktop is selected from the list of available desktops (step 3080). The components that comprise the default desktop are then displayed on the client display device with other available desktops made available to the user through a pop-up window (predefined process 3090, see
A determination is made as to whether the client was authenticated (decision 3160). If the user was not authenticated, decision 3160 branches to “no” branch 3165 whereupon an error is displayed on the client's display device (step 3170) and processing ends at 3195. On the other hand, if the user was authenticated, decision 3160 branches to “yes” branch 3175 whereupon the Java shell launcher is invoked (predefined process 3180, see
A determination is made as to whether the Jshell application is launched remotely or locally (decision 3230). If the Jshell application is launched locally, decision 3230 branches to “local” branch 3235 whereupon the Jshell application is launched with the user's user ID as a parameter (step 3240). On the other hand, if the Jshell application is launched remotely, decision 3230 branches to “remote” branch 3245 whereupon the Jshell application is launched remotely by providing the server hostname, the user ID, and the platform ID as parameters (step 3250).
After the Jshell application has been launched, JSL enumerates the OS window list to find the window corresponding to the Java shell (step 3260). The Java shell window is pinned to the bottom of the Z-order list of the operating system windows so that the Java shell window will always remain in the foreground (step 3270). The Java shell window is maximized to fit the display screen and all frame controls, such as minimize and resize buttons, are removed from the Java shell window (step 3280). In this manner, the shell application appears as the foreground page on the display and the user is prevented from using the shell page provided by the native operating system platform. Java shell launching processing ends at 3295.
The appearance and behavior of the smart component is determined by the classtype of it's parent container. For example, a smart icon will display a text description if it's parent classtype is a desktop. However, the same smart icon will not display the text description if it's parent classtype is a toolbar. Furthermore, the smart icons behavior may differ depending on the type of parent container. For example, if the icond is placed in a toolbar it may be programmed to draw a border around itself when the user places the mouse pointer over it. However, if the same icon is placed on the desktop it may be programmed to not display a border when the pointer passes over it. In addition, the smart icon may be programmed to execute different code related to the component upon activation depending upon the type of container to which it belongs.
Screen image 3300 includes two examples of a smart graphical component in the form of a time clock. Time clock 3305 is a component that has been placed in a toolbar container. Time clock 3330 is the same component, but this time the time clock has been placed in the desktop container. The appearance and behavior of the object changes depending upon the type of parent object, or container, to which the object belongs. In the example shown, time clock 3305 is displayed as a digital time because of the smaller area available in the parent toolbar container. Conversely, time clock 3330 displays an analog time because of the greater area available in the desktop container. In addition, time clock 3330 displays additional information such as the digital time and date underneath the analog clock image. Furthermore, time clock 3330 displays the name of the object (i.e. “clock”) underneath the object.
When the user selects time clock 3305 located in the toolbar, pop-up window 3320 is displayed. Pop-up window 3320 displays the day of the week, date, and has menu items to adjust the time/date and to set notifications.
As the name implies, container objects 3470 include objects that can include, or hold, other objects. Container objects include folders 3480 and toolbars 3490. Visual components such as icons can be included in container objects.
Component appearance data, such as the icon size and other display characteristics, are retrieved along with object behavior characteristics that correspond to the selected class type (step 3575). For example, if the retrieved class type is a toolbar then the icon size and display characteristics would be based upon the smaller area available to an icon that is displayed in a toolbar. However, if the retrieved class type is the desktop then the icon size and display characteristics are based upon the larger area available in the desktop.
The component is displayed using the retrieved appearance data that corresponds to the class type. The system waits for the component to be invoked (step 3585, i.e. until the component is selected by the user). When the component is invoked, the component is executed using behavior attributes that correspond to the class type (step 3590).
If the class type is not a toolbar, decision 3605 branches to “no” branch 3630 whereupon a determination is made as to whether the class type is a folder (decision 3635). If the class type is a folder, decision 3635 branches to “yes” branch 3640 whereupon the folder icon for 30 the component is retrieved and displayed in the folder (step 3645), a short component description is displayed underneath the icon (step 3650), and processing ends at 3655.
If the class type is not a toolbar or a folder, decision 3635 branches to “no” branch 3660 whereupon a determination is made as to whether the class type is the desktop (decision 3665). If the class type is the desktop, decision 3665 branches to “yes” branch 3668 whereupon the larger icon is retrieved in displayed on the desktop (step 3670), a longer component description is displayed under the icon (decision 3675), and processing ends at 3680.
If the class type is not a toolbar, a folder, or desktop, then decision 3665 branches to “no” branch 3682 whereupon a default icon is retrieved and displayed (step 3685), other default display characteristics are retrieved and applied to the icon (step 3690), and processing ends at 3695.
If the invoked component does not have a parent with a toolbar class type, decision 3705 branches to “no” branch 3730 whereupon a determination is made as to whether the invoked component has a parent with a folder class type (decision 3735). If the invoked component has a folder parent class type, decision 3735 branches to “yes” branch 3740 whereupon the component's folder behavior is retrieved (step 3745), executed (step 3750), and processing ends at 3755.
If the invoked component does not have any parent with a toolbar or folder class type, decision 3735 branches to “no” branch 3760 whereupon a determination is made as to whether the invoked component has a parent with a desktop class type (decision 3765). If the invoked component has a desktop parent class type, decision 3765 branches to “yes” branch 3768 whereupon the component's desktop behavior is retrieved (step 3770), executed (step 3775), and processing ends at step 3780.
If the invoked component does not have a parent with a class type of toolbar, folder, or desktop, decision 3765 branches to “no” branch 3782 whereupon the components default behavior is retrieved (step 3785), executed (step 3790), and processing ends at step 3795.
BIOS 3880 is coupled to ISA bus 3840, and incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions. BIOS 3880 can be stored in any computer readable medium, including magnetic storage media, optical storage media, flash memory, random access memory, read only memory, and communications media conveying signals encoding the instructions (e.g., signals from a network). In order to attach computer system 3801 to another computer system to copy files over a network, LAN card 3830 is coupled to PCI bus 3825 and to PCI-to-ISA bridge 3835. Similarly, to connect computer system 3801 to an ISP to connect to the Internet using a telephone line connection, modem 3875 is connected to serial port 3864 and PCI-to-ISA Bridge 3835.
While the computer system described in
One of the preferred implementations of the invention is an application, namely, a set of instructions (program code) in a code module which may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, on a hard disk drive, or in removable storage such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.
While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For a non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US583207||Mar 10, 1897||May 25, 1897||Seat-lock for vehicles|
|US4102822 *||Jul 26, 1976||Jul 25, 1978||Chevron Research Company||Hydrocarbon hydroconversion catalyst and the method for its preparation|
|US4845644||Jun 9, 1987||Jul 4, 1989||International Business Machines Corporation||Data display system|
|US5243697||May 13, 1992||Sep 7, 1993||Sun Microsystems, Inc.||Method and apparatus for selecting button functions and retaining selected options on a display|
|US5287502||Sep 11, 1991||Feb 15, 1994||Kabushiki Kaisha Toshiba||Computer system for executing application programs by a combination of picture symbols|
|US5347626||May 21, 1993||Sep 13, 1994||Sun Microsystems, Inc.||Method and apparatus for selecting and executing defaults in window based displayed system|
|US5386564||Feb 24, 1993||Jan 31, 1995||Hewlett-Packard Company||Conversion of data and objects across classes in an object management system|
|US5425140||Mar 20, 1992||Jun 13, 1995||International Business Machines Corporation||Method and apparatus for providing conditional cascading in a computer system graphical user interface|
|US5448729||May 25, 1994||Sep 5, 1995||Cisgem Technologies, Inc.||Office system with audit history|
|US5564002||Aug 1, 1994||Oct 8, 1996||International Business Machines Corporation||Method and apparatus for implementing a virtual desktop through window positioning|
|US5706456||Apr 18, 1995||Jan 6, 1998||Unisys Corporation||Application specific graphical user interface (GUI) that is window programmable and capable of operating above a windows operating system GUI|
|US5765153||Jan 3, 1996||Jun 9, 1998||International Business Machines Corporation||Information handling system, method, and article of manufacture including object system authorization and registration|
|US5845090||Sep 30, 1996||Dec 1, 1998||Platinium Technology, Inc.||System for software distribution in a digital computer network|
|US5859969||Jan 11, 1996||Jan 12, 1999||Fujitsu Limited||Remote installation system and method|
|US5867163||Oct 6, 1997||Feb 2, 1999||Silicon Graphics, Inc.||Graphical user interface for defining and invoking user-customized tool shelf execution sequence|
|US5874952||Nov 12, 1996||Feb 23, 1999||Sony Corporation||Method and apparatus for improved graphical user interface with function icons|
|US5926631 *||Aug 15, 1997||Jul 20, 1999||International Business Machines Corporation||Network computer emulator systems, methods and computer program products for personal computers|
|US6044465||Jul 7, 1997||Mar 28, 2000||International Business Machines Corporation||User profile storage on and retrieval from a non-native server domain for use in a client running a native operating system|
|US6061795||May 12, 1997||May 9, 2000||Pinnacle Technology Inc.||Network desktop management security system and method|
|US6105063||May 5, 1998||Aug 15, 2000||International Business Machines Corp.||Client-server system for maintaining application preferences in a hierarchical data structure according to user and user group or terminal and terminal group contexts|
|US6105066||May 5, 1998||Aug 15, 2000||International Business Machines Corp.||Client-server system with central application management and using fully qualified class names of object-oriented applications for determining permanent server storage locations for application configuration information|
|US6108332||Sep 12, 1997||Aug 22, 2000||Ericsson Inc.||Local number portability for interexchange carriers|
|US6108712||May 5, 1998||Aug 22, 2000||International Business Machines Corp.||Client-server system with central application management and providing export agent capability for retrofitting existing hardware and applications into the system|
|US6123737||May 21, 1997||Sep 26, 2000||Symantec Corporation||Push deployment of software packages using notification transports|
|US6138153||Dec 18, 1997||Oct 24, 2000||Computer Associates Think, Inc.||System for software distribution in a digital computer network|
|US6205476||May 5, 1998||Mar 20, 2001||International Business Machines Corporation||Client—server system with central application management allowing an administrator to configure end user applications by executing them in the context of users and groups|
|US6208342||Jan 18, 2000||Mar 27, 2001||Sony Corporation||Graphical user interface for enabling selection of a selectable graphic image|
|US6212564||Jul 1, 1998||Apr 3, 2001||International Business Machines Corporation||Distributed application launcher for optimizing desktops based on client characteristics information|
|US6237092||May 5, 1998||May 22, 2001||International Business Machines Corp.||Client-server system with central application management allowing an administrator to configure user and group contexts during application configuration without relaunching the application|
|US6249883||Jun 29, 1998||Jun 19, 2001||Netpro Computing, Inc.||System and method for monitoring domain controllers|
|US6282568 *||Dec 4, 1998||Aug 28, 2001||Sun Microsystems, Inc.||Platform independent distributed management system for manipulating managed objects in a network|
|US6282711||Aug 10, 1999||Aug 28, 2001||Hewlett-Packard Company||Method for more efficiently installing software components from a remote server source|
|US6286041||Sep 11, 2000||Sep 4, 2001||Computer Associates Think, Inc.||System for software distribution in a digital computer network|
|US6310603||Nov 5, 1999||Oct 30, 2001||Xsides Corporation||Overscan user interface|
|US6330010||Nov 13, 1998||Dec 11, 2001||Xsides Corporation||Secondary user interface|
|US6337717||Feb 5, 1999||Jan 8, 2002||Xsides Corporation||Alternate display content controller|
|US6339826||May 5, 1998||Jan 15, 2002||International Business Machines Corp.||Client-server system for maintaining a user desktop consistent with server application user access permissions|
|US6344859||Mar 31, 1998||Feb 5, 2002||International Business Machines Corporation||Data processor controlled display system with a plurality of selectable basic function interfaces for the control of varying types of customer requirements and with additional customized functions|
|US6389589||Sep 21, 1998||May 14, 2002||Microsoft Corporation||Class store schema|
|US6417869||Mar 15, 1999||Jul 9, 2002||Citicorp Development Center, Inc.||Method and system of user interface for a computer|
|US6426762||Jul 16, 1999||Jul 30, 2002||Xsides Corporation||Secondary user interface|
|US6446071||Apr 26, 1999||Sep 3, 2002||International Business Machines Corporation||Method and system for user-specific management of applications in a heterogeneous server environment|
|US6476833||Mar 30, 1999||Nov 5, 2002||Koninklijke Philips Electronics N.V.||Method and apparatus for controlling browser functionality in the context of an application|
|US6636250||Apr 12, 2000||Oct 21, 2003||Emc Corp||Methods and apparatus for presenting information to a user of a computer system|
|US6829732||Jan 22, 2001||Dec 7, 2004||Hewlett-Packard Development Company, L.P.||Network-based software recovery for computing devices|
|US6901403||Sep 14, 2001||May 31, 2005||Quovadx, Inc.||XML presentation of general-purpose data sources|
|US6918056||Feb 15, 2001||Jul 12, 2005||High Antivirus Research Inc.||Internet-based service system and method for remotely restoring damaged data and files|
|US6947943||Oct 11, 2002||Sep 20, 2005||Zeosoft Technology Group, Inc.||System for development, management and operation of distributed clients and servers|
|US20010011341||May 5, 1998||Aug 2, 2001||Kent Fillmore Hayes Jr.||Client-server system for maintaining a user desktop consistent with server application user access permissions|
|US20020112090 *||Feb 15, 2001||Aug 15, 2002||International Business Machines Corporation||Method, system, and product for a java-based desktop to provide window manager services on UNIX|
|US20020178271||Nov 20, 2001||Nov 28, 2002||Graham Todd D.||Dynamic file access control and management|
|US20030035006||Apr 16, 2002||Feb 20, 2003||Kodosky Jeffrey L.||Graphical association of a device icon with a graphical program|
|US20030149557||Feb 7, 2002||Aug 7, 2003||Cox Richard Vandervoort||System and method of ubiquitous language translation for wireless devices|
|US20030160815||Feb 28, 2002||Aug 28, 2003||Muschetto James Edward||Method and apparatus for accessing information, computer programs and electronic communications across multiple computing devices using a graphical user interface|
|US20030182656||Sep 6, 2001||Sep 25, 2003||Burton Leathers||Deployment manager for organizing and deploying an application in a distributed computing environment|
|US20040024610||Jun 6, 2003||Feb 5, 2004||Sergey Fradkov||Transaction execution system interface and enterprise system architecture thereof|
|US20050156939||Mar 15, 2005||Jul 21, 2005||Microsoft Corporation||Application programming interface for changing the visual style|
|EP1050813A2||May 4, 2000||Nov 8, 2000||Sun Microsystems, Inc.||Method and apparatus for implementing deployment descriptions in an enterprise environment|
|EP1077411A1||Mar 6, 2000||Feb 21, 2001||Fairbanks Systems Group||System and method for restoring computer files over a wide area computer network|
|EP1227400A2||Jan 16, 2002||Jul 31, 2002||Hewlett-Packard Company||Network-based software recovery for computing devices|
|WO1999057863A1||Dec 21, 1998||Nov 11, 1999||International Business Machines Corporation||Client-server system for maintaining a user desktop consistent with server application user access permissions|
|1||"Invisible Logical Desktop Views," IBM Research Disclosure, No. 34947, May 1993.|
|2||"JAR File Specification," 1999, Sun Microsystems, Inc., pp. 1-13.|
|3||Fitzpatrick et al., "Dynamic Icon Presentation," IBM TDB, vol. 35, No. 4B, Sep. 1992 (p. 227-232).|
|4||Fitzpatrick et al., "Method for Automatic Presentation Shift Change," IBM TDB, vol. 35, No. 6, Nov. 1992 (p. 326-327).|
|5||*||Hayes et al. (WO 99/57863, published Nov. 11, 1999).|
|6||*||Motifdeveloper.com, "How dow I disable the Minimize . . . window,?" pp. 1-4, Dec. 2000.|
|7||*||TriTeal Corporation, SoftNC Java Desktop Environment form TriTeal, 1998, http://web.archive.org/web/19980419075356/softnc.triteal.com/softnc/summary.html.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8312201||Jun 9, 2008||Nov 13, 2012||International Business Machines Corporation||Managing memory allocations loans|
|US8799892||Jun 9, 2008||Aug 5, 2014||International Business Machines Corporation||Selective memory donation in virtual real memory environment|
|US20050049989 *||Aug 29, 2003||Mar 3, 2005||International Business Machines Corporation||Autonomic user interface widgets|
|US20090307432 *||Jun 9, 2008||Dec 10, 2009||Fleming Matthew D||Memory management arrangements|
|US20090307686 *||Jun 9, 2008||Dec 10, 2009||International Business Machines Corporation||Selective memory donation in virtual real memory environment|
|International Classification||G09G5/00, G06F21/00, G06F3/00|
|Dec 17, 2002||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BROCKWAY, BRANDON;COOPER, MICHAEL R.;KERSTEN, JASON R.;AND OTHERS;REEL/FRAME:013596/0986
Effective date: 20021216
|Jul 16, 2010||FPAY||Fee payment|
Year of fee payment: 4
|Sep 26, 2014||FPAY||Fee payment|
Year of fee payment: 8