Many enterprises currently employ computer systems based on the client/server architecture. In a client/server architecture, a client computer (usually a user computer, such as a PC) requests a number of resources from server applications (usually on a larger, specialized computer), such as data, applications, and some processing. Clients and servers are connected over a network, such as a Local Area Network (LAN) or a Wide Area Network (WAN), and many computer systems employ one or more applications servers and one or more database servers to communicate with many clients and to provide them with a full range of applications and data.
Some systems may utilize general-purpose PCs as “fat clients.” In other words, while the client computer will receive some applications and processing from the server, most of the storage and processing will occur at the client, which may include multiple storage devices (hard drive, floppy drive, CR ROM drive, etc.) on which many programs are stored and ready to run with little or no input from the server. In such systems, the server's main function may be that of a remote hard drive, simply storing and retrieving programs and data while doing little processing for client application uses.
Some systems may utilize what are referred to as “thin clients.” Thin clients can be any type of computer, but are usually stripped-down versions of a user computer with very minimal storage capacity. In a thin client arrangement, much of the processing may be accomplished by the server, as well as much of the application storage. Thus, some thin client arrangements may be considered highly centralized because most of the functionality and storage resides on the server side while the clients operate almost as dumb terminals.
Many computers, including servers, clients, stand-alone computers, and the like present an interface to a user that may be referred to as a “shell.” A shell is an interactive interface that defines a maximum amount of system features that are accessible by the user. Some systems may be operable to associate a given shell with a computer (e.g., based on a computer's operating system) and may also allow a user to configure the shell in some way. However, traditional systems do not allow shells to be selected on a per-user basis.
According to at least one embodiment, a system comprises a processor-based device and a startup application that is operable to determine one of a plurality of shells presented by the processor-based device based on a user's identity information. According to at least one other embodiment, a method comprises receiving an identification of a user and determining a shell specified for the user based on the identification. According to at least one other embodiment, a system comprises means for matching user identification information to a corresponding user profile and means for executing a shell specified by the profile
As mentioned above, startup application 103 is operable to determine a shell based on user identity information 104. In many embodiments, such functionality may include matching information 104 to entries in a database or configuration file that may be internal or external to startup application 103 or computer 101. While
Because system 100 determines shell 102 based on user identity information 104, system 100 may be operable to provide a number of different shells to a number of different users. A shell may be appropriate for a particular user based on, for example, security issues and user permissions, as explained more fully below.
Explorer shell 110 provides much functionality (for a thin client system), including start menu 111, which may give a user access to one or more applications, one or more connections, a control panel, and other resources, such as the ability to add, delete, or modify available applications and connections. Explorer shell 110 also may include icons 113, which may be shortcuts to one or more applications or connections. An application may be considered to be a program for use on computer 101, such as INTERNET EXPLORER, which is a web browser application, or WINDOWS® MEDIA® PLAYER, which is a multi-media application. A connection may be considered to be a communication connection to a server, such that by choosing a connection, a user may become connected to a server and be able to access the features offered by that server. An example of a connection is a CITRIX® ICA® server connection, that may allow a user at a client computer to access many licensed applications available through the server, such as word processing or database applications. Some features may be both an application and a connection, such as INTERNET EXPLORER, which may be a program that resides, at least partly, on a thin client, but also connects the client to a specific server for Internet access.
System tray 112 may also be provided by Explorer shell 110, thereby providing a clock and notifications to a user. In addition to allowing a user some degree of latitude in access to connections and other features, Explorer shell 110 may offer the advantage of providing some users with an interface that feels familiar because it resembles a WINDOWS® XP or CE interface, which is a popular business and consumer operating system. Some network administrators may consider the broad access to features offered by Explorer shell 110 to be a disadvantage in that some users may abuse their access to some of the features, such as by frivolously surfing the Web with an INTERNET EXPLORER application or causing security breaches. This illustrates a common theme in Information Technology (IT), which is finding a balance between user access and security, wherein one is usually increased at the expense of the other. Accordingly, an Explorer shell may offer less security to a computer system than a more restrictive shell.
While
Referring to
In one example, startup application 103 determines that shell 110, instead of shell 120, is appropriate for presenting to User A by computer 101. Shell 110 may be more appropriate for User A based on such criteria as User A's preferences or privileges afforded User A by an administrator. In another example, startup application 103 may determine that shell 120 is appropriate for User A because of the limited access that it offers for some features. Thus, system 100 provides a way to execute shells on a per-user basis. Note that users may be grouped according to many criteria (e.g., sales department versus accounting department), and shells may be assigned based on user group.
Blocks 204 and 205 represent functionality of startup manager 201. In block 204, user identity information 104 is matched to corresponding user profile 203. As explained with regard to
In block 204, the shell specified by profile 203 is executed. As explained earlier, user profile 203 specifies a shell for use with the particular user. Startup manager 201 uses that information to determine the appropriate shell. In WINDOWS® CE embodiments, one of the last steps in the initialization chain is to execute the shell. In this case, the shell is executed based on user identity information 104. The result is a WINDOWS® CE-based system that presents a shell to a user based on the user's identity (i.e., shells are executed on a per-user basis). That is, a selected one of a plurality of different shells that are available for execution on the client is executed for a given user based on that user's profile.
It is an advantageous feature of some embodiments to select a particular shell at initialization, rather than at run time, because navigation in each shell may be quite different from navigation in other shells, and such a feature may allow a user to interact with the shell that he or she is most comfortable with up front. Having a runtime selection may be useful in some embodiments; however, a user may have to interact with an interface that is less familiar to him or her before reaching a desired interface.
System 300, in this example, uses WINDOWS® CE as its operating system. WINDOWS® CE has an initialization chain in its registry that begins with various boot routines and ends with executing a shell. In this embodiment, a routine (startup manager 201) is added to the initialization chain that prompts a user (such as user 320 or 330) for a login ID and password. Some embodiments may provide for execution of startup manager 201 at any login, not just at startup. After the user has entered the identity information, startup manager 201 searches stored profiles 202, which is a database in the User Settings part of the registry that includes user profiles 2031-203M to specify a shell for use with a particular user. Startup manager 201 then executes the specified shell. Thus, the embodiment depicted in
For example, in the case of client 3101, image 302, which includes stored profiles 202, is stored on flash memory inside client 3101. When user 320 restarts or logs onto client 3101, user 320 is prompted for a login ID and password by the startup manager. User 320 then identifies himself with ID information 104. Startup manager 201 then compares information 104 to profiles 203, and finds a match with profile 2031. Profile 2031, in this case, specifies that Explorer shell 110 is appropriate for use with user 320. Accordingly, shell 110 is executed. Client 310N operates in a similar manner to compare information 104 for user 330 with profiles 203 to execute shell 120.
Clients 310 and server 301 may belong to an enterprise that employs many people, and therefore, must accommodate many users in system 300. Because image 302 is stored on clients 310 themselves, it is possible to use a different image with different stored profiles on one or more of the N clients in system 300. In order to keep image 302 and stored profiles 202 consistent from client to client, an administrator may reimage all N clients every time a user profile 203 in stored profiles 202 changes. Thus, a user (such as user 320 or 330) may log on to any of the N clients 310, and the same shell will be presented each time.
In this example embodiment, a wizard is an executable (.EXE) file with one or more dialog boxes that link to each other. Each dialog box may be designed to give a user a choice about one or more personal settings preferences. A wizard may be created from scratch, or may be created through modifying the source code of another existing wizard.
In some example embodiments, user 402 is not an administrator, but has authority to set up some of his own settings. User 402 accesses setup wizard 401, which walks him through a routine wherein he is prompted to enter some of his setting preferences. One of the preferences may be which shell he prefers to execute when he logs on. Setup wizard 401 then implements that preference in corresponding user profile 403, which may be one of several stored profiles 202.
In another example, user 402 is an administrator who desires to set preferences for a user other than himself. In that case, user 402 executes setup wizard 401, which prompts him to specify some settings, including which shell to execute for the user in question. Setup wizard 401 then implements the setting in corresponding user profile 403.
System 400 may be implemented in a computer system such as system 300 (
While the example embodiment described in
Further, while the embodiments described with regard to
In block 502, a shell specified for the user is determined based on the identification. The determining may be accomplished, for example, through use of querying a database or configuration file to access a profile corresponding to the user. The database or configuration file may be stored locally on the machine by which the identification was received, or it may be stored remotely from that machine. Further, the shell may be any shell now known or later developed. In many embodiments, method 500 may be performed at startup or login of a computer or computer system. In those embodiments, the determining a shell 502 may be followed by completion of a startup process through execution of the shell. Thus, such a method may be used in some embodiments to execute shells on a per-user basis.
Computer system 600 may also include random access memory (RAM) 603, which may be SRAM, DRAM, SDRAM, or the like. Computer system 600 may include read-only memory (ROM) 604 which may be PROM, EPROM, EEPROM, or the like. In some embodiments, RAM 603 may provide reading and writing of data during an operation, and ROM 604 may accommodate a Basic Input Output System (BIOS).
Computer system 600 may also include input/output (I/O) adapter 605, communications adapter 611, user interface adapter 608, and display adapter 609. I/O adapter 605, user interface adapter 608, and/or communications adapter 611 may, in certain embodiments, enable a user to interact with computer system 600 in order to input information, such as to operate setup wizard 401 of
I/O adapter 605 may connect to storage device(s) 606, such as one or more of a flash memory, hard drive, compact disc (CD) drive, floppy disk drive, tape drive, etc. to computer system 600. In the case of thin clients, local storage may be restricted to RAM 603, ROM 604, and flash memory. In example clients 310 (of
It shall be appreciated that the various embodiments are not limited to the architecture of system 600. For example, many suitable processor-based devices may be utilized for either client 310 or server 301 (