Multi-console workstations concurrently supporting multiple users

BACKGROUND

When a user logs in to use a given personal computer system, the operating system running on that computer system establishes a session for that user. Conventional operating systems running on computer systems typically support only one session, regardless of how many monitors and display devices are attached to the computer system or are present in the computer system. Also, conventional computer systems usually provide only one physical console for a user. Generally, in the context of conventional personal computer systems, only one local user can access the computer system at a time.

Technology such as Fast User Switching (FUS) supported by the WINDOWS® XP® operating system, provided by Microsoft Corporation, allows multiple users to access a computer system through respective user accounts. However, FUS does not allow these multiple users to access the computer system simultaneously, and only one user session can be active at a time. In the FUS context, only one user can log-in to the machine at a time, and this user must log out before a second user can log in.

Other technology such as Terminal Services (TS), supported by various versions of the WINDOWS® family of operation systems, allows multiple users to access a computer system concurrently. However, TS is a thin-client solution, and uses a network to connect a host machine to a plurality of terminals on which information is displayed to the users. While the network does enable multiple users to access the host machine concurrently, it can also be a performance bottleneck that constrains the types of applications that the users can run on the terminals. Some applications require real-time, high-bandwidth multi-media capabilities, such as gaming, audio or video streaming, or other types of graphics-intensive applications. For such applications, the performance of a thin-client solution or any other solution involving or deployed over a network may not be entirely satisfactory, because the demands of such applications may exceed the performance capabilities of the network.

SUMMARY

Embodiments of a workstation provided herein include a host machine and a plurality of consoles directly connected to the host machine. Each of the consoles is configured as a separate console accessible to a given user. Each of the separate consoles includes a respective input device adapted to receive input from the user, and a respective output device adapted to provide output to the user. The input device and the output device are connected directly to the host machine.

Because the consoles, which include the input device and the output device, are connected directly to the host machine without intermediate components or communication networks therebetween, users logging into the consoles can access the resources of the host machine with a minimum of performance degradation between the consoles and the host machine. Thus, these users can execute a wider array of bandwidth- and/or graphics-intensive applications on the consoles than would be possible if the consoles were connected to the host machine via a network.

Embodiments of a method provided herein includes configuring the host machine to support a plurality of users concurrently on a plurality of consoles, and connecting each of the consoles directly to the host machine so as to enable direct communication therebetween.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or to essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTIONS OF THE DRAWING FIGURES

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.

<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a multi-console, multi-user workstation system.

<figref idrefs="DRAWINGS">FIG. 2</figref> is a diagram showing data flows and components related to initially configuring the multi-console system shown in <figref idrefs="DRAWINGS">FIG. 1</figref>.

<figref idrefs="DRAWINGS">FIG. 3</figref> is a flowchart illustrating a process performed by the multi-console system when configuring consoles and initializing multiple-console capability for the first time on a given host machine.

<figref idrefs="DRAWINGS">FIG. 4</figref> is a flowchart illustrating a process performed when the host machine is booted or restarted after the consoles have been configured as shown in <figref idrefs="DRAWINGS">FIG. 3</figref>.

<figref idrefs="DRAWINGS">FIG. 5</figref> is a diagram showing data flows and components related to logging users into the multi-console system shown in <figref idrefs="DRAWINGS">FIGS. 1 and 2</figref>.

<figref idrefs="DRAWINGS">FIG. 6</figref> is a flowchart illustrating a process performed by the multi-console system to log a local user into a session created at a given console.

<figref idrefs="DRAWINGS">FIG. 7</figref> is a flowchart illustrating a process by which the multi-console system enables users to connect remotely to sessions supported by the host machine.

<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates a state of the multi-console system after a user logs into a session at a given console.

<figref idrefs="DRAWINGS">FIG. 9</figref> is a flowchart illustrating a process performed by the multi-console system when a session connected to a console is disconnected.

<figref idrefs="DRAWINGS">FIG. 10</figref> is a flowchart illustrating a process performed by the multi-console system to switch from a multi-console mode to a single console, multi-monitor mode.

<figref idrefs="DRAWINGS">FIG. 11</figref> is a flowchart illustrating a process performed by the multi-console system should a new output device be connected to the host machine.

<figref idrefs="DRAWINGS">FIG. 12</figref> is a flowchart illustrating a process performed by the multi-console system should a new input device be connected to the host machine.

<figref idrefs="DRAWINGS">FIG. 13</figref> is a block diagram of an illustrative computing environment within which the teachings herein can be either fully or partially implemented.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a multi-console system <b>100</b>, with a plurality of consoles <b>105</b> or workstations <b>105</b> connected directly to a host machine <b>110</b>. For example, the host machine <b>110</b> can be connected to the consoles <b>105</b> through device ports or other connection points provided by the hardware of the host machine <b>110</b> itself. Host machine <b>110</b> can be implemented as a personal computer (PC) running any of the WINDOWS® family of operating systems, along with suitable application software chosen for a given implementation. <figref idrefs="DRAWINGS">FIG. 13</figref> illustrates components and architecture suitable for implementing the host machine <b>110</b>.

The host machine <b>110</b> typically includes one physical console <b>105</b>(<b>1</b>), comprising input devices <b>115</b>(<b>1</b>) and output devices <b>120</b>(<b>1</b>) and <b>125</b>(<b>1</b>) to enable an administrator <b>130</b> (hereafter admin <b>130</b>) or other authorized users to log in to the host machine <b>110</b>. Using the physical console <b>105</b>(<b>1</b>), the admin <b>130</b> can initially configure the additional consoles <b>105</b>(<b>2</b>) and <b>105</b>(<b>3</b>). Also, the admin <b>130</b> or other authorized users can log in to the host machine <b>110</b> via the physical console <b>105</b>(<b>1</b>) to access the resources of the host machine <b>110</b>.

The physical console <b>105</b>(<b>1</b>) and the additional consoles <b>105</b>(<b>2</b>) and <b>105</b>(<b>3</b>) contain at least a minimal configuration of output devices <b>120</b> and <b>125</b> and input devices <b>115</b> appropriate to enable respective users <b>135</b> to access the resources of the host machine <b>110</b>. A given console <b>105</b> can include visual output device <b>120</b> and/or audio output device <b>125</b>.

A visual output device <b>120</b> suitable for a given physical console <b>105</b>(<b>1</b>) or additional consoles <b>105</b>(<b>2</b>) and <b>105</b>(<b>3</b>) can include any monitor incorporating any display technology appropriate for a given application. Also included, but omitted from <figref idrefs="DRAWINGS">FIG. 1</figref> for clarity, are one or more video cards, and drivers associated with these cards. It is noted that enhanced video cards may enable connection of more than one visual output device <b>120</b> to the card. Therefore, more than one additional console <b>105</b> may be supported using one such enhanced video card.

The physical console <b>105</b>(<b>1</b>) and/or the additional consoles <b>105</b>(<b>2</b>) and <b>105</b>(<b>3</b>) can also include audio output devices <b>125</b> such as speakers, headphones, ear phones, ear buds, or the like. Combined with a corresponding monitor or other visual output device <b>120</b>, these audio output devices <b>125</b> can enable respective users <b>135</b> at the consoles <b>105</b> to, for example, view different movies, play different games, or run different applications at each console <b>105</b>.

Illustrative input devices <b>115</b> for the physical console <b>105</b>(<b>1</b>) and/or the additional consoles <b>105</b>(<b>2</b>) and <b>105</b>(<b>3</b>) can include respective instances of a keyboard, mouse, or any other device by which a user <b>135</b> can provide commands or input to the host machine <b>110</b>. Other sources of input can include digital cameras, webcams, microphones, or the like, along with any cards or drivers appropriate for interfacing such devices to the host machine <b>110</b>.

Each console <b>105</b> is supported by any software (e.g., device drivers) appropriate to support or enable full use of the input devices <b>115</b> or output devices <b>120</b> and <b>125</b> included as part of the consoles <b>105</b>. If any of the peripherals connected to the host machine <b>110</b> are serial devices, technology such as Universal Serial Bus (USB) may be useful to connect these peripherals.

The direct connection to the hardware of the host machine <b>110</b> enables each of the consoles <b>105</b> to provide superior performance as compared to thin-client or network-based solutions, especially for graphic intensive applications. Since the additional consoles <b>105</b> do not communicate through a network, network bandwidth limitations do not constrain or degrade the performance of the additional consoles <b>105</b>. Thus, the additional consoles <b>105</b> can perform to the full capability permitted by the resources of the host machine <b>110</b>. Accordingly, the host machine <b>110</b> can be provisioned to support whatever applications are expected to be offered to the users <b>135</b>, and to support the number of additional consoles <b>105</b> and users <b>135</b> configured by the admin <b>130</b>.

The multi-console system <b>100</b> further overcomes shortcomings of conventional systems, which typically limited each host machine to hosting only one physical console and only one session with one user <b>135</b>. A “session” as used herein refers to a connection between a given user <b>135</b> and the host machine <b>110</b>. The hardware resources that are allocated to the given user <b>135</b> are associated with that user's session. If additional input devices <b>115</b> and output devices <b>120</b> and <b>125</b> are attached to the host machine <b>110</b>, then these additional input devices <b>115</b> and output devices <b>120</b> and <b>125</b> can be grouped into additional consoles <b>105</b> that can support additional sessions with users <b>135</b>. Put another way, each console <b>105</b> can be associated with a respective set of input devices <b>115</b> and output devices <b>120</b> and <b>125</b>. Each console <b>105</b> in turn can support a session with a user <b>135</b>.

For convenience and clarity, <figref idrefs="DRAWINGS">FIG. 1</figref> shows the host machine <b>110</b> supporting two additional consoles <b>105</b>(<b>2</b>) and <b>105</b>(<b>3</b>). However, the multi-console system <b>100</b> can be readily be practiced with N additional consoles <b>105</b>, where N is an integer greater than zero. In the non-limiting embodiment shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, N equals two. When a given user <b>135</b> logs in to a given console <b>105</b>, a corresponding session is allocated to that user <b>135</b>. In this manner, N additional users <b>135</b> can access the resources of the host machine <b>110</b> simultaneously.

In this sense, the multi-console system <b>100</b> can be viewed as extending technology such as FUS to support a plurality of concurrent or simultaneous sessions with a plurality of users <b>135</b>. Since these user sessions are local to the host machine <b>110</b> and not remote, they do not depend on protocols such as the Remote Desktop Protocol (RDP). Further, neither the host machine <b>110</b> nor the additional consoles <b>105</b>(<b>2</b>) and <b>105</b>(<b>3</b>) need to be connected to additional network-related hardware, thereby avoiding the cost of such hardware. Finally, because the consoles <b>105</b> are connected directly to the hardware of the host machine <b>110</b> (i.e., directly to ports or cards that are connected to the bus of the host machine), these user sessions are not encumbered by network overhead. By avoiding the performance bottlenecks of networks, the multi-console system <b>100</b> can support the bandwidth and performance demands of applications that might overwhelm network connections.

The multi-console system <b>100</b> also reduces the total cost of ownership associated with enabling multiple users <b>135</b> to access the host machine <b>110</b> concurrently. For example, in residential, home business, or small business scenarios, instead of installing and managing an application that is deployed onto multiple separate, standalone machines, an admin <b>130</b> can install the application only onto the host machine <b>110</b>. The multi-console system <b>100</b> then enables the host machine <b>110</b> to support N additional, separate consoles <b>105</b>, and can support N different sessions and N different users <b>135</b> simultaneously. Thus, each user <b>135</b> can access the single instance of the application as if it were installed on the user's own standalone machine.

<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a data flow <b>200</b> and related components associated with initially configuring the multi-console system <b>100</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. The multi-console system <b>100</b> provides a configuration tool <b>205</b> that is used by the admin <b>130</b> to configure the host machine <b>110</b>. As an initial step the admin <b>130</b> issues configuration commands <b>210</b> that logically group various input devices <b>115</b> and output devices <b>120</b> and <b>125</b> together into consoles <b>105</b>. In turn, these consoles <b>105</b> can support different sessions with respective users <b>135</b>. The grouping of the input devices <b>115</b> and the output devices <b>120</b> and <b>125</b> into respective consoles <b>105</b> is represented in the console configuration data <b>220</b>.

The configuration commands <b>210</b> from the admin <b>130</b> are stored in a registry <b>215</b> or other data store. The registry <b>215</b> stores the console configuration data <b>220</b> that logically defines each of the consoles <b>105</b>, and associates respective output devices <b>120</b> and <b>125</b> and input devices <b>115</b> with each console <b>105</b>. Each console <b>105</b> supported by the host machine <b>110</b> is assigned a unique console ID <b>225</b>. <figref idrefs="DRAWINGS">FIG. 2</figref> shows a non-limiting embodiment of two consoles <b>105</b>(<b>1</b>) and <b>105</b>(<b>2</b>) with corresponding console IDs <b>225</b>(<b>1</b>) and <b>225</b>(<b>2</b>). The registry <b>215</b> is indexed or keyed at least by this console ID <b>225</b>, so that given an input console ID <b>225</b>, the registry <b>215</b> can readily return data representing all input devices <b>115</b> and output devices <b>120</b> and <b>125</b> assigned to or associated with the input console ID <b>225</b>. The unique console IDs <b>225</b> for the physical console <b>105</b>(<b>1</b>) and the additional console <b>105</b>(<b>2</b>) are represented generally by the dashed lines <b>225</b>(<b>1</b>) and <b>225</b>(<b>2</b>) appearing in <figref idrefs="DRAWINGS">FIG. 2</figref>.

The above configuration processes are performed for each of the N additional consoles <b>105</b> supported by a given instance of the multi-console system <b>100</b>. When the admin <b>130</b> has finished configuring the N additional consoles <b>105</b>, the host machine <b>110</b> may be rebooted or restarted if necessary. After configuration is complete, the multi-console system <b>100</b> is ready to accept logins from users <b>135</b>.

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a process <b>300</b> performed by the multi-console system <b>100</b> when initializing multiple-console capability for the first time on a given host machine <b>110</b>. To simplify the discussion, but not to limit the teachings herein, assume that the given host machine <b>110</b> is equipped with two video cards, two monitors, two keyboards, and two mice. Assume further that the registry <b>215</b> reflects this environment. It is noted that this discussion can be easily extended to N instances of the above devices, with N being any number greater than 0.

When the host machine <b>110</b> first boots up (block <b>305</b>), it will typically be in multiple-monitor mode, which means that only a single user <b>135</b> on the host machine <b>110</b> can view displays on multiple monitors connected to the host machine <b>110</b>. Multiple monitor mode is distinguished herein from multiple console mode. The host machine <b>110</b> in multiple-monitor mode hosts only one interactive session, which is labeled as the “first interactive session” for ease of reference. The first interactive session is associated with the physical console <b>105</b>(<b>1</b>) supported by the host machine <b>110</b> when in multiple-monitor mode, and all the input devices <b>115</b> and output devices <b>120</b> and <b>125</b> connected to the host machine <b>110</b> are owned and used by the first interactive session.

The admin <b>130</b> then starts the configuration tool <b>205</b> (block <b>310</b>), which reads the registry <b>215</b> and learns that there are two monitors, two keyboards, and two mice connected to the host machine <b>110</b>. Each of the above devices are referenced or identified to facilitate grouping them into logical groups of devices or consoles <b>105</b> (block <b>315</b>). How the devices are identified or referenced can depend on the nature of the particular devices. For output devices <b>120</b> and <b>125</b> such as monitors, the WINDOWS® family of operating systems provides a “multimon” utility and related user interface (UI) that can display the numbers “1” and “2” in the respective monitors, so that the admin <b>130</b> can identify and reference each monitor separately when issuing configuration commands <b>210</b>.

Input devices <b>115</b> such as a keyboard or mouse can be represented in the UI by appropriate icons. For such input devices <b>115</b>, the admin <b>130</b> can touch a key on the keyboard or move the mouse, and in response the UI can activate, move, or otherwise change the state of the icon. Alternatively, the different input devices <b>115</b> (e.g., keyboards, mice, or the like) can be listed by their Globally Unique Identifiers (GUIDs). However, GUIDs may be difficult for human admins <b>130</b> to understand.

Using the configuration tool <b>205</b>, the admin <b>130</b> logically groups a set of input devices <b>115</b> and output devices <b>120</b> or <b>125</b> (comprising, e.g., a monitor, keyboard, and mouse) as a first console <b>105</b> at block <b>315</b>. For each console <b>105</b> supported by the host machine <b>110</b>, the admin <b>130</b> repeats the foregoing processes (block <b>320</b>), logically grouping additional sets of input devices <b>115</b> and output devices <b>120</b> or <b>125</b> (comprising, e.g., another monitor, keyboard, and mouse) into additional consoles <b>105</b>. The configuration tool <b>205</b> records data in the registry <b>215</b> representing these consoles <b>105</b> and the devices assigned thereto, and stores in the registry <b>215</b> a unique console ID <b>225</b> for each console <b>105</b> (block <b>325</b>).

The configuration tool <b>205</b> then requests that the host machine <b>110</b> be switched from “multi-monitor” mode to “multi-console” mode (block <b>330</b>). The configuration tool <b>205</b> can make this request in response to the admin <b>130</b> clicking on a function such as “Start Different Console Sessions with These Associated Devices” provided by the configuration tool <b>205</b>.

In block <b>335</b>, the process <b>300</b> performs various checks to ensure that the host machine <b>110</b> can support multi-console mode. Such checks can include ensuring that the hardware connected to the host machine <b>110</b> can support multi-console mode. For example, the process <b>300</b> can check that the host machine <b>110</b> is connected to two different output devices <b>120</b> and <b>125</b>, and to two sets of input devices <b>115</b>.

Another check can include ensuring that these two monitors are not configured to be part of the same display device. For example, the WINDOWS® XP® operations system offers “Dualview” feature that allows multiple monitors to be connected to a given machine in a multi-monitor, single-console environment. However, if each of these multiple monitors is attached to a given console, then these multiple monitors may not be sufficient to support the multi-console environment taught herein.

Another check might involve ensuring that the admin <b>130</b> permits configuring and running the host machine <b>110</b> in multi-console mode. The admin <b>130</b> may have established a policy on the host machine <b>110</b> barring it from being run in multi-console mode.

If the host machine <b>110</b> cannot be configured and/or run in multi-console mode, then an appropriate error message or indication is returned to the configuration tool <b>205</b> (block <b>340</b>). Otherwise, if the host machine <b>110</b> can be configured in multi-console mode, then existing ownership rights to the output devices <b>120</b> or <b>125</b> and input devices <b>115</b> are relinquished or released (block <b>345</b>). More particularly, the process <b>300</b> can request that any operating system component associated with the first interactive session remove all references to its input devices <b>115</b> and output devices <b>120</b> or <b>125</b>, besides those input devices <b>115</b> or output devices <b>120</b> or <b>125</b> allocated in the registry <b>215</b> to the first interactive session running on the physical console <b>105</b>(<b>1</b>).

In response to this request, these operating system components related to the first interactive session remove any reference to any output devices <b>120</b> or <b>125</b>, besides the output devices <b>120</b> or <b>125</b> allocated in the registry <b>215</b> to the first interactive session. Similarly, these operating system components remove any reference to any input devices <b>115</b> (e.g., keyboard and mouse), besides the input devices allocated to the first interactive session in the registry <b>215</b>.

In block <b>350</b>, a new session is created to associate with a given new console <b>105</b>. This new session may be viewed as a temporary session in the sense that it runs on the console <b>105</b> awaiting an actual user login. As described further below, when the user logs on, the temporary session transitions to a live or active user session after the logon is complete. A unique session identifier is created for the new session, and can be loaded into the registry <b>215</b> so as to associate the session with the corresponding console <b>105</b>. This temporary session may have the characteristics of the user sessions shown below in <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref>, so all of those teachings apply equally to the user sessions discussed below in <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref>.

Recall that after the console configuration process described above in connection with <figref idrefs="DRAWINGS">FIG. 2</figref>, the registry <b>215</b> associates each console <b>105</b> with corresponding output devices <b>120</b> or <b>125</b> and input devices <b>115</b>. Further, since a new session is being created for each console <b>105</b>, the output devices <b>120</b> or <b>125</b> and input devices <b>115</b> for each console <b>105</b> will, in turn, be associated with a session created for that console <b>105</b>. As discussed above, the configuration tool <b>205</b> creates entries in the registry <b>215</b> in response to commands from the admin <b>130</b> when the admin <b>130</b> configures the various consoles <b>105</b>. These entries associate each console <b>105</b> with the input devices <b>115</b> and output devices <b>120</b> or <b>125</b> assigned to that console <b>105</b> by the admin <b>130</b>.

In block <b>360</b>, the new temporary session comes up on the console <b>105</b>, and the input devices <b>115</b> are activated to receive input from a user <b>135</b> when that user <b>135</b> seeks to login to the console <b>105</b>. The output device <b>120</b> or <b>125</b> is now responsive to commands issued by the user <b>135</b>, for example, through the input devices <b>115</b>. In block <b>365</b>, the above processes are repeated for each of the other new consoles <b>105</b> configured by the admin <b>130</b>, returning to block <b>350</b> for each new console <b>105</b>.

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a process flow <b>400</b> performed when the host machine <b>110</b> is booted or restarted (block <b>405</b>) after the new consoles <b>105</b> have been configured as shown in <figref idrefs="DRAWINGS">FIG. 3</figref>. In block <b>410</b>, a new session is created for the first interactive session created by default when the host machine <b>110</b> boots. In blocks <b>415</b> and <b>420</b>, the registry <b>215</b> is read to identify the output devices <b>120</b> or <b>125</b> and the input devices <b>115</b> assigned to this first interactive session. Recall that the configuration tool <b>205</b> created these entries in the registry <b>215</b> for the first interactive session when the admin <b>130</b> configured the additional consoles <b>105</b>. It is noted that while blocks <b>415</b> and <b>420</b> are illustrated separately for clarity and convenience, the processing performed therein could be integrated, and/or be performed serially or in parallel relative to one another, or any combination of the foregoing.

In blocks <b>425</b> and <b>430</b>, an output device manager and an input device manager (illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref> and described in connection therewith) are each instantiated for the first interactive session. As before with blocks <b>415</b> and <b>420</b>, while blocks <b>425</b> and <b>430</b> are illustrated separately for clarity and convenience, the processing performed therein could be integrated, and/or be performed serially or in parallel relative to one another, or any combination of the foregoing.

In block <b>435</b>, a terminal manager for the first interactive session is started. The processing performed by the terminal manager is described in greater detail below in <figref idrefs="DRAWINGS">FIG. 5</figref>. In block <b>440</b>, the terminal manager reads the registry <b>215</b> as written by the configuration tool <b>205</b> during setup, and determines whether additional consoles <b>105</b> have been configured and specified in the registry <b>215</b>. If not, the process <b>400</b> completes at block <b>445</b>.

If additional consoles <b>105</b> are defined in the registry <b>215</b>, the foregoing processes are repeated for each additional console <b>105</b> defined in the registry <b>215</b> (block <b>450</b>). Returning to block <b>410</b>, a new temporary session is started for the next one of the additional consoles <b>105</b>. The above processes are repeated for each additional console <b>105</b> specified in the registry <b>215</b>. When a user <b>135</b> logs in to the console <b>105</b>, a new session is created for that user <b>135</b>, and the new session is associated with the console <b>105</b>.

<figref idrefs="DRAWINGS">FIG. 5</figref> illustrates a data flow <b>500</b> and related components associated with logging users <b>135</b> into the multi-console system <b>100</b> shown in <figref idrefs="DRAWINGS">FIGS. 1 and 2</figref>. When a given user <b>135</b> wishes to login to the multi-console system <b>100</b>, he or she chooses a given console <b>105</b> provided by the host machine <b>110</b> and previously configured by the admin <b>130</b>. The given console <b>105</b> includes an input device <b>115</b>, and the user <b>135</b> submits login information <b>505</b> via the input device <b>115</b>. The login information <b>505</b> typically includes a usemame and password as submitted by the user <b>135</b>. The login information <b>510</b> output from the input device <b>115</b> includes the usemame and password, but may also include a console identifier <b>225</b> that indicates the console <b>105</b> that the user <b>135</b> has selected.

The host machine <b>110</b> runs a login process <b>515</b> that receives the login information <b>510</b>. A suitable example of the login process <b>515</b> is the WINLOGON process provided by the WINDOWS® family of operating systems offered by Microsoft. Generally, the login process <b>515</b> is responsible for securely logging authorized users <b>135</b> onto the host machine <b>110</b> to access one of the consoles <b>105</b>.

Assuming the user <b>135</b> is authenticated and the login information <b>505</b>/<b>510</b> is valid, the login process <b>515</b> passes the console identifier <b>225</b> to a terminal manager <b>520</b>, and asks the terminal manager <b>520</b> to create a new session <b>535</b> for the user <b>135</b>. As an optimization discussed further below, the new session <b>535</b> can be created ahead of time as a “temporary” session <b>535</b> that is associated with the console identifier <b>225</b>. These temporary sessions <b>535</b> may be created on boot-up to await user login. This optimization can save the time associated with creating the new session <b>535</b> from scratch when the user <b>135</b> logs in.

The terminal manager <b>520</b> is a server-side component that manages the different sessions <b>535</b> that result when different users <b>135</b> login to the various consoles <b>105</b>. The WINDOWS® family of operating systems offers a suitable example of a terminal manager <b>520</b> in the form of the Terminal Services (TS) service, which may be extended to support the multi-console aspects of the multi-console system <b>100</b>. The session management tasks performed by the terminal manager <b>520</b> can include starting sessions <b>535</b> up, tearing sessions <b>535</b> down, disconnecting users <b>135</b> from sessions <b>535</b>, reconnecting users <b>135</b> to sessions <b>535</b>, and the like.

Given the console identifier <b>225</b>, the terminal manager <b>520</b> knows which console <b>105</b> the user <b>135</b> is accessing. The terminal manager <b>520</b> then accesses the registry <b>215</b> using the console identifier <b>225</b> as a key. The registry <b>215</b> returns data <b>525</b> indicating which input devices <b>115</b> and/or output devices <b>120</b> or <b>125</b> are assigned to the console <b>105</b> corresponding to the input console identifier <b>225</b>. The data <b>525</b> can be a list of the input devices <b>115</b> and the output devices <b>120</b> or <b>125</b> assigned to the console <b>105</b> by the admin <b>130</b> when the admin <b>130</b> configured the console <b>105</b>. The terminal manager <b>520</b> now knows which input devices <b>115</b> and output devices <b>120</b> or <b>125</b> are associated with the console <b>105</b> to which the user <b>135</b> is connected, and therefore which devices are to be allocated to the user <b>135</b>.

The terminal manager <b>520</b> then requests that a session manager <b>530</b> create the new session <b>535</b> for the user <b>135</b>, as represented by the line <b>540</b>. The session manager <b>530</b> creates new sessions <b>535</b> for users <b>135</b> upon command from the terminal manager <b>520</b>. As noted elsewhere herein, the sessions <b>535</b> may have been created ahead of time to await user login at a given console. When the user <b>135</b> logs off, the session <b>535</b> may be torn down and replaced with a temporary session <b>535</b> to await login from a next user <b>135</b>. When the next user <b>135</b> logs in, this temporary session <b>535</b> can become his or her active session <b>535</b>, unless that user <b>135</b> has a disconnection session <b>535</b> from before. A suitable example of the session manager <b>530</b> is the Session Manager process, known as SMSS, in the WINDOWS® family of operating systems.

In response to the request <b>540</b> from the terminal manager <b>520</b>, the session manager <b>530</b> creates the new session <b>535</b>, which is associated with the console <b>105</b> to which the user <b>135</b> is connected. The new session <b>535</b> is assigned a unique session ID <b>545</b>. Also, the new session <b>535</b> is associated with a respective instance of a kernel mode portion <b>550</b> of an operating system running on the host machine <b>110</b>. A suitable example of the kernel mode portion <b>550</b> is the WIN32K kernel mode portion provided by the WINDOWS® family of operating systems. In turn, the kernel mode portion <b>550</b> for the new session <b>535</b> is associated with new instances of an output device manager <b>555</b> and an input device manager <b>560</b>. Thus, the new session <b>535</b> created for a user <b>135</b> upon login includes at least respective instances of a kernel mode portion <b>550</b>, an output device manager <b>555</b>, and an input device manager <b>560</b>.

The output device manager <b>555</b> is responsible for associating respective output devices <b>120</b> or <b>125</b> with corresponding sessions <b>535</b>. The output device manager <b>555</b> also manages a list of physical output devices <b>120</b> or <b>125</b> assigned to each session <b>535</b>, and tracks any changes in state or other issues related to the output devices <b>120</b> or <b>125</b>. A suitable example of an output device manager <b>555</b> is the graphics device interface (GDI) layer, which is provided by the WINDOWS® operations systems to manage display devices <b>120</b>.

The input device manager <b>560</b> is responsible for associating respective input devices <b>115</b> with corresponding sessions <b>535</b>. A suitable example of an input device manager <b>560</b> is the NTUSER window manager provided as part of the WINDOWS® family of operating systems.

While not shown in <figref idrefs="DRAWINGS">FIG. 5</figref> in the interests of clarity and conciseness, other components offered as part of the WINDOWS® family of operating systems may be useful for implementing the multi-console system <b>100</b>. The Client Server Runtime System (CSRSS) is a layer provided by a user mode portion of the WINDOWS subsystem. Also, a utility for automatically detecting and configuring peripheral devices, such as input devices <b>115</b>, that may be connected or disconnected from the host machine <b>110</b> may also be useful. A suitable example is the Plug and Play (PnP) layer offered by the WINDOWS® family of operating systems, which can issue notifications regarding entry or exit of various input devices <b>115</b>.

<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates a process <b>600</b> performed by the multi-console system <b>100</b> to log a user <b>135</b> into a temporary session <b>535</b> created at a console <b>105</b>. In block <b>605</b>, the process <b>600</b> detects that a user <b>135</b> has requested to login, for example, by entering a username and password combination. In block <b>610</b>, the process <b>600</b> then determines whether any disconnected sessions <b>535</b> are associated with the user <b>135</b> who is requesting to log in. If no disconnected sessions <b>535</b> are associated with the user <b>135</b> who is currently logging on, then (block <b>615</b>) a new session <b>535</b> is created for the user <b>135</b>, as discussed above in connection with <figref idrefs="DRAWINGS">FIG. 5</figref>. In block <b>620</b>, the user <b>135</b> is connected to the new session <b>535</b>.

Otherwise, if disconnected sessions <b>535</b> are associated with the user <b>135</b> (block <b>625</b>), then the process <b>600</b> proceeds to block <b>625</b>, where it determines how many disconnected sessions <b>535</b> are associated with the user <b>135</b>. If the user <b>135</b> has only one disconnected session <b>535</b>, he or she can be reconnected to this original session <b>535</b>, as shown in block <b>640</b>. Alternatively, as shown by the dashed line labeled “Optional” in <figref idrefs="DRAWINGS">FIG. 6</figref>, a new session <b>535</b> can be created for the user <b>135</b>. In this case, the process proceeds to block <b>615</b>.

If the user <b>135</b> has multiple disconnected sessions <b>135</b>, the process <b>600</b> proceeds to block <b>630</b>, where the user <b>135</b> is presented with a list of the disconnected sessions <b>535</b>. In block <b>635</b>, the process <b>600</b> prompts the user <b>135</b> to choose a session <b>535</b> with which to reconnect. Once the user <b>135</b> has selected a disconnected session <b>135</b>, the process <b>600</b> reconnects the user <b>135</b> to the chosen session <b>135</b> (block <b>640</b>).

As discussed below in connection with <figref idrefs="DRAWINGS">FIG. 9</figref>, when a session <b>535</b> is disconnected, a temporary session <b>535</b> is associated with the console <b>105</b> from which the session <b>535</b> was disconnected. When a user <b>135</b> logs off the multi-console system <b>100</b> completely, as opposed to disconnecting from a session <b>535</b>, the terminal manager <b>520</b> creates a temporary session <b>535</b> and attaches it to the console <b>105</b>, as discussed above in connection with <figref idrefs="DRAWINGS">FIG. 4</figref>. An alternative approach is not to reset the session <b>535</b> completely, but just logoff the current user <b>135</b>, so that the session <b>535</b> will move from an Active state to a Connected state.

In block <b>615</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>, when a new session <b>535</b> is created, this new session <b>535</b> can take the form of the temporary session <b>535</b> that was previously attached to the console <b>105</b>. Also, the new session <b>535</b> created in block <b>410</b> of <figref idrefs="DRAWINGS">FIG. 4</figref> can take the form of this temporary session <b>535</b>. Finally, as an optimization, the sessions <b>535</b> can be pre-created on each of the consoles <b>105</b> configured as part of the multi-console system <b>100</b>, so that the sessions are ready and waiting for the users <b>135</b>. In this optimized scenario, the user <b>135</b> need not wait for the session <b>535</b> to be created before logging in: by pre-creating the session <b>535</b> ahead of time, the overhead associated with creating the session <b>535</b> has been completed when the user requests to log in, and the user <b>135</b> need not wait for this overhead when logging in.

Using the process and data flows shown in <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref>, the new session <b>535</b>, or the reconnected session <b>535</b>, attached to the console <b>105</b> is associated with the set of input devices <b>115</b> and output devices <b>120</b> and <b>125</b> that are specified for that console <b>105</b> by the registry <b>215</b>. The terminal manager <b>520</b> can read this data from the registry <b>215</b>, and notify the input device manager <b>560</b> and the output device manager <b>555</b> which input devices <b>115</b> and output devices <b>120</b> and <b>125</b> belong to the console <b>105</b>. Alternatively, the output device manager <b>555</b> and the input device manager <b>560</b> can read the registry <b>215</b> themselves directly.

<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a process <b>700</b> by which the multi-console system <b>100</b> enables users <b>135</b> to connect remotely to sessions <b>535</b> supported by the host machine <b>110</b>. In block <b>705</b>, the process <b>700</b> detects that a remote user <b>135</b> has requested to log in to the multi-console system <b>100</b>. For example, the remote user <b>135</b> may submit a usemame and password combination to the login process <b>515</b> shown in <figref idrefs="DRAWINGS">FIG. 5</figref>.

Once the login request has been received, the process <b>700</b> determines which of the multiple sessions <b>535</b> supportable by the host machine <b>110</b> to connect to the remote user <b>135</b>. One approach is to determine whether the first interactive session <b>535</b> is available when the remote user <b>135</b> requests to log in (block <b>710</b>). If the first interactive session <b>535</b> is available, the remote user <b>135</b> can be connected to it by default, without further action by the remote user <b>135</b> (block <b>715</b>). If the first interactive session <b>535</b> is not available, the process <b>700</b> can proceed to block <b>720</b>, where the process <b>700</b> enables the remote user <b>135</b> to specify a particular session <b>535</b> to which to connect. In block <b>725</b>, the user <b>135</b> is connected to the specified session <b>535</b>.

Another approach is for the process <b>700</b> to present the user <b>135</b> with a list of available sessions <b>535</b>, and prompt the remote user <b>135</b> to select a session <b>535</b> to which he or she wants to connect. This option bypasses decision block <b>710</b>, and disregards the issue of whether the first interactive session <b>535</b> is available. This process flow is represented in <figref idrefs="DRAWINGS">FIG. 7</figref> by the dashed line connecting blocks <b>705</b> and <b>720</b>. In this case, the process <b>700</b> connects the remote user to the selected or specified session in block <b>725</b>.

Another approach is to determine whether the remote user <b>135</b> is associated with any disconnected sessions <b>535</b> on the host machine <b>110</b> (block <b>730</b>). This option, once again, bypasses decision block <b>710</b>, and disregards the issue of whether the first interactive session <b>535</b> is available. This process flow is represented in <figref idrefs="DRAWINGS">FIG. 7</figref> by the dashed line connecting blocks <b>705</b> and <b>730</b>. If the user <b>135</b> has disconnected sessions <b>535</b> on the host machine <b>110</b>, the process <b>700</b> can reconnect the remote user <b>135</b> to the disconnected session <b>535</b> (block <b>735</b>). If the user has no disconnected session <b>535</b>, the process <b>700</b> can proceed to block <b>720</b> or to block <b>715</b>.

Remote reconnection to sessions <b>535</b> can be performed similarly to local connection to sessions <b>535</b>, as discussed above. If a given user <b>135</b> is logged in locally at a given console <b>105</b>, disconnects, and then logs on again from a remote location, he can be reconnected to his original session <b>535</b>.

Yet another approach is to enable the remote user <b>135</b> to start a new session <b>535</b> instead of reconnecting to the previous session <b>535</b>, if desired. This approach was discussed above in connection with <figref idrefs="DRAWINGS">FIG. 6</figref>.

When a user <b>135</b> who is logged into a session <b>535</b> at a local console <b>105</b> disconnects the session <b>535</b>, a temporary session <b>535</b> is created at that local console <b>105</b> to await a login from another user <b>135</b>. The temporary session <b>535</b> created at the local console <b>105</b> takes over those output devices <b>120</b> and <b>125</b> and input devices <b>115</b> associated with that local console <b>105</b>. Again, the terminal manager <b>520</b> can read the appropriate entries for this console <b>105</b> from the registry <b>215</b> and inform the input device manager <b>560</b> and the output device manager <b>555</b> for the temporary session <b>535</b> accordingly. Alternatively, the input device manager <b>560</b> and the output device manager <b>555</b> for the temporary session <b>535</b> can read the registry <b>215</b> directly for themselves.

<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates a state <b>800</b> of the multi-console system <b>100</b> after a user logs in to a session <b>535</b> at a given console <b>105</b>. The console <b>105</b> used by the user <b>135</b> is represented by the unique console ID <b>225</b>, which points to entries in the registry <b>215</b> for the input devices <b>115</b> and output devices <b>120</b> or <b>125</b> associated with the console <b>105</b>. Once the new session <b>535</b> is created for the user <b>135</b> after login, the new session <b>535</b> is associated with the console <b>105</b> at which the user <b>135</b> is logged in, as indicated by the line <b>805</b>. A unique session ID <b>545</b> is associated with the new session <b>535</b>, and the session ID <b>545</b> points to the new processes created for the new session <b>535</b>. <figref idrefs="DRAWINGS">FIG. 8</figref> shows only the input device manager <b>560</b> and the output device manager <b>555</b>. Other aspects of the host machine <b>110</b> and/or the operating system running thereon are omitted from <figref idrefs="DRAWINGS">FIG. 8</figref> for clarity and conciseness, but could be included in implementations of the multi-console system <b>100</b> without departing from the scope of the teachings herein.

In any event, the input device manager <b>560</b> is associated with the input devices <b>115</b> assigned to the console <b>105</b>, as indicated by the line <b>810</b>, and the output device manager <b>555</b> is associated with the output devices <b>120</b> and <b>125</b> assigned to the console, as indicated by the line <b>815</b>. Assuming the teachings herein are implemented in an object-oriented environment, the various components shown in <figref idrefs="DRAWINGS">FIG. 8</figref> could be instantiated as respective objects having attributes and relationships as illustrated.

It is also noted that the data state <b>800</b> shown in <figref idrefs="DRAWINGS">FIG. 8</figref> could also describe the structure resulting after the temporary sessions <b>535</b> are created for each of the consoles <b>105</b> after startup of the host machine <b>110</b>. Also, if the sessions <b>535</b> are pre-created prior to user login, as discussed above as an optimization, then the data state <b>800</b> could also describe the structure resulting after such pre-creation.

<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates a process <b>900</b> performed by the multi-console system <b>100</b> should a session <b>535</b> connected to a console <b>105</b> be disconnected. In block <b>905</b>, the terminal manager <b>520</b> associated with the console <b>105</b> detects that the session <b>535</b> has assumed a disconnected state as indicated by, for example, by a user <b>135</b> logging out from the given console <b>105</b>, or the user <b>135</b> disconnecting a remote session <b>535</b> supported by the multi-console system <b>100</b>. The terminal manager <b>520</b> detects that this session <b>535</b> has become disconnected, and notifies the output device manager <b>555</b> and input device manager <b>560</b> associated with the disconnected session <b>535</b> accordingly.

In block <b>910</b>, in response to this notification from the terminal manager <b>520</b>, the output device manager <b>555</b> disassociates the physical output devices <b>120</b> and <b>125</b> that were formerly associated with the now-disconnected session <b>535</b>. In place of the output devices <b>120</b> and <b>125</b>, the output device manager <b>555</b> attaches a disconnect display device such as the Terminal Server Disconnect Display Driver (TSDDD) to the disconnected session <b>535</b>.

In block <b>915</b>, also in response to this notification from the terminal manager <b>520</b>, the input device manager <b>560</b> dereferences the input devices <b>115</b> that were formerly associated with the now-disconnected session <b>535</b>.

<figref idrefs="DRAWINGS">FIG. 9</figref> shows processes <b>910</b> and <b>915</b> as proceeding in parallel for convenience in illustration and discussion. However, it is noted that these processes <b>910</b> and <b>915</b> could proceed in any order or sequence deemed suitable in a given application, whether serially, in parallel, or any combination of the foregoing.

In block <b>920</b>, a temporary session <b>535</b> as discussed above is created by, for example, the terminal manager <b>520</b>. In block <b>905</b>, this temporary session <b>535</b> is associated with the console <b>105</b> from which the session <b>535</b> was disconnected. In block <b>925</b>, the input devices <b>115</b> and output devices <b>120</b> and <b>125</b> formerly associated with the disconnected session <b>535</b> are now associated with the temporary session <b>535</b>, for example by appropriate entries in the registry <b>215</b>. In block <b>930</b>, this temporary session <b>535</b> then awaits a login either from a new user <b>135</b>, or possibly a reconnection from the same user <b>135</b> who disconnected earlier.

<figref idrefs="DRAWINGS">FIG. 10</figref> illustrates a process <b>1000</b> performed by the multi-console system <b>100</b> to switch from a multi-console mode to a single console, multi-monitor mode. In block <b>1005</b>, the process <b>1000</b> receives a request to switch modes. To promote system security and integrity, the right to switch modes can be restricted to admins <b>130</b> only, or can be restricted to users <b>135</b> who have the appropriate authority or permission level to reconfigure the multi-console system <b>100</b>.

Having received the request to switch modes, and having determined that the request is valid and/or authorized, in block <b>1010</b> the process <b>1000</b> determines which of the consoles <b>105</b> should be retained when the multi-console system <b>100</b> switches to single-console, multi-monitor mode. An example of single-console, multi-monitor mode is when a given computer system provides access to only one user <b>135</b> at a given time. Thus, this given computer system can be described as operating in a single-console mode. However, the given computer system enables that one user <b>135</b> to control and view more than one monitor from this single console. Accordingly, the given computer system can be described as operating in single-console, multi-monitor mode.

In different embodiments of the process <b>1000</b>, the admin <b>130</b> can specify which console <b>105</b> should be retained on a case-by-case basis, or can specify that the console from which the request originates should be retained.

In other embodiments, one particular console <b>105</b> can be retained by default, regardless of whence the request to switch modes originates. Where a request to switch modes is received from an authorized user <b>135</b> or admin <b>130</b> who is logged into a local console <b>105</b>, the local console <b>105</b> from which the request is received may be retained by default. Where the request to switch modes is received from an authorized user <b>135</b> or admin <b>130</b> who is logged in remotely, the admin <b>130</b> may specify which local console <b>105</b> is to be retained.

In any event, once the console <b>105</b> to be retained is identified, all other console <b>105</b> are reset so that they no longer exist from the viewpoint of the multi-console system <b>100</b> (block <b>1015</b>). To illustrate the process <b>1015</b>, assume for the sake of discussion that the request to switch modes originated from a local console “A”. All console sessions <b>535</b> other than the session from which the request originated (i.e., Session “A”) are reset. After the reset, all input devices <b>115</b> and output devices <b>120</b> and <b>125</b> associated with those sessions <b>535</b> become available to the one remaining session <b>535</b>, or they can remain unattached to any session, depending on how configurations are specified.

In block <b>1020</b>, all output devices <b>120</b> and <b>125</b> and input devices <b>115</b> connected to the host machine <b>110</b> are associated with the console <b>105</b> that was designated for retention above in block <b>1010</b>. In the example above, this association can be performed by the terminal manager <b>520</b> informing the output device manager <b>555</b> of the Session “A” to enumerate all output devices <b>120</b> and <b>125</b> connected to the host machine <b>110</b> and to associate them with Session “A”. Similarly, the terminal manager <b>520</b> can inform the input device manager <b>560</b> to enumerate all input devices <b>115</b> connected to the host machine <b>110</b> and associate them with Session “A”. The registry <b>215</b> is then updated accordingly to reflect this association (block <b>1025</b>). In block <b>1030</b>, the host machine <b>110</b> is rebooted or restarted, if necessary. The host machine <b>110</b> is now in single-session, multi-monitor mode.

<figref idrefs="DRAWINGS">FIG. 11</figref> illustrates a process <b>1100</b> performed by the multi-console system <b>100</b> should a new output device <b>120</b> or <b>125</b> be connected to the host machine <b>110</b>. For example, but not limitation, new output devices <b>120</b> or <b>125</b> can include video cards, monitors or other display devices, speakers, headphones, or the like. When a new output device <b>120</b> or <b>125</b> is added to the host machine <b>110</b> and detected (block <b>1105</b>), the new output device <b>120</b> or <b>125</b> is associated with either a new console <b>105</b> or an existing console <b>105</b>. Until then, existing sessions <b>535</b> running on any console <b>105</b> are not made aware of the new output device <b>120</b> or <b>125</b>, and do not open a reference to the output device <b>120</b> or <b>125</b>.

In block <b>1110</b>, the process <b>1100</b> enables the admin <b>130</b> to configure these new devices into the multi-console system <b>100</b>. To do so, the admin <b>130</b> opens the configuration tool <b>205</b>. Using the configuration tool <b>205</b>, the admin <b>130</b> can add the new output device <b>120</b> or <b>125</b> to an existing console <b>105</b> as an additional output device <b>120</b> or <b>125</b> (block <b>1115</b>). Alternatively, the admin <b>130</b> can group the new output device <b>120</b> or <b>125</b> with a given set of input devices <b>115</b> (e.g., a keyboard-mouse pair) to define a new console <b>105</b> (block <b>1120</b>). In the latter case, the existing console <b>105</b> to which the new output device <b>120</b> or <b>125</b> is added may be viewed as a multi-monitor console.

It is noted that the numbering and arrangement of the blocks <b>1115</b> and <b>1120</b> are chosen for convenience in illustration and discussion, and not to suggest any preference for either scenario represented in those two blocks.

In block <b>1125</b>, the registry <b>215</b> is updated as appropriate to indicate that the new output device <b>120</b> or <b>125</b> is associated with the console <b>105</b> as designed in blocks <b>1115</b> or <b>1120</b> above. In block <b>1130</b>, the process <b>1100</b> notifies the output device manager <b>555</b> for a session <b>535</b> running on the console <b>105</b> that the new output device <b>120</b> or <b>125</b> is now available to that session <b>535</b>.

<figref idrefs="DRAWINGS">FIG. 12</figref> illustrates a process <b>1200</b> performed by the multi-console system <b>100</b> should a new input device <b>115</b> be connected to the host machine <b>110</b>. A utility such as the PnP layer discussed above may detect the connection of the new input device <b>115</b> and may notify all sessions <b>535</b> that the new input device <b>115</b> has been connected. However, until the new input device <b>115</b> has been configured by the admin <b>130</b>, the sessions <b>535</b> ignore it. In block <b>1210</b>, the process <b>1200</b> enables the admin <b>130</b> to execute the configuration tool <b>205</b> to configure the new input device <b>115</b>.

In some embodiments of the multi-console system <b>100</b>, the new input device <b>115</b> can be made visible to a session <b>535</b> used by the admin <b>130</b> so that the admin <b>130</b> can test the operation of the new input device <b>115</b>, as indicated by the dashed lines appearing in <figref idrefs="DRAWINGS">FIG. 12</figref> in connection with block <b>1215</b>.

In any event, turning to blocks <b>1220</b> and <b>1225</b>, the admin <b>130</b> either groups the new input device <b>115</b> with an output devices <b>120</b> or <b>125</b> to form a new console <b>105</b> (block <b>1225</b>), or adds the new input device <b>115</b> to an existing console <b>105</b> to provide this console <b>105</b> with an additional input device <b>115</b> (block <b>1220</b>). In block <b>1230</b>, the registry <b>215</b> is updated to associate the new input device <b>115</b> to the console selected above in block <b>1220</b> or <b>1225</b>. In block <b>1235</b>, the process <b>1200</b> notifies the input device manager <b>555</b> for the console <b>105</b> to which the new input device <b>115</b> is assigned that the new input device <b>115</b> s available.

The multi-console system <b>100</b> can also support the connection of new input device <b>115</b>, such as scanners, digital cameras, webcams, microphones, or the like to the host machine <b>110</b>. When such input devices <b>115</b> are initially connected to the host machine <b>110</b>, a utility such as the PnP layer can detect the connection of the new input device <b>115</b> and send a device discovery notification to all consoles <b>105</b> supported by the host machine <b>110</b>. Alternatively, the PnP layer can send the device discovery notification to only one console <b>105</b>, such as a primary console <b>105</b> from which the admin <b>130</b> configured the multi-console system <b>100</b> initially. After this notification, the admin <b>130</b> can open the configuration tool <b>205</b> and associate the new input device <b>115</b> with other consoles <b>105</b> as appropriate.

<figref idrefs="DRAWINGS">FIG. 13</figref> illustrates an exemplary computing environment <b>1300</b> within which systems and methods for implementing multi-console workstations <b>100</b>, as well as the computing, network, and system architectures described herein, can be either fully or partially implemented. For example, the environment <b>1300</b> shown in <figref idrefs="DRAWINGS">FIG. 13</figref> may be suitable for constructing the host machine <b>110</b> disclosed herein. Exemplary computing environment <b>1300</b> is only one example of a computing system and is not intended to suggest any limitation as to the scope of use or functionality of the architectures. Neither should the computing environment <b>1300</b> be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary computing environment <b>1300</b>.

The computer and network architectures in computing environment <b>1300</b> can be implemented with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, client devices, hand-held or laptop devices, microprocessor-based systems, multiprocessor systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, gaming consoles, distributed computing environments that include any of the above systems or devices, and the like.

The computing environment <b>1300</b> includes a general-purpose computing system in the form of a computing device <b>1302</b>. The components of computing device <b>1302</b> can include, but are not limited to, one or more processors <b>1304</b> (e.g., any of microprocessors, controllers, and the like), a system memory <b>1306</b>, and a system bus <b>1308</b> that couples the various system components. The one or more processors <b>1304</b> process various computer executable instructions to control the operation of computing device <b>1302</b> and to communicate with other electronic and computing devices. The system bus <b>1308</b> represents any number of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures.

Computing environment <b>1300</b> includes a variety of computer readable media which can be any media that is accessible by computing device <b>1302</b> and includes both volatile and non-volatile media, removable and non-removable media. The system memory <b>1306</b> includes computer readable media in the form of volatile memory, such as random access memory (RAM) <b>1310</b>, and/or non-volatile memory, such as read only memory (ROM) <b>1312</b>. A basic input/output system (BIOS) <b>1314</b> maintains the basic routines that facilitate information transfer between components within computing device <b>1302</b>, such as during start-up, and is stored in ROM <b>1312</b>. RAM <b>1310</b> typically contains data and/or program modules that are immediately accessible to and/or presently operated on by one or more of the processors <b>1304</b>.

Computing device <b>1302</b> may include other removable/non-removable, volatile/non-volatile computer storage media. By way of example, a hard disk drive <b>1316</b> reads from and writes to a non-removable, non-volatile magnetic media (not shown), a magnetic disk drive <b>1318</b> reads from and writes to a removable, non-volatile magnetic disk <b>1320</b> (e.g., a “floppy disk”), and an optical disk drive <b>1322</b> reads from and/or writes to a removable, non-volatile optical disk <b>1324</b> such as a CD-ROM, digital versatile disk (DVD), or any other type of optical media. In this example, the hard disk drive <b>1316</b>, magnetic disk drive <b>1318</b>, and optical disk drive <b>1322</b> are each connected to the system bus <b>1308</b> by one or more data media interfaces <b>1326</b>. The disk drives and associated computer readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for computing device <b>1302</b>.

Any number of program modules can be stored on RAM <b>1310</b>, ROM <b>1312</b>, hard disk <b>1316</b>, magnetic disk <b>1320</b>, and/or optical disk <b>1324</b>, including by way of example, an operating system <b>1328</b>, one or more application programs <b>1330</b>, other program modules <b>1332</b>, and program data <b>1334</b>. Each of such operating system <b>1328</b>, application program(s) <b>1330</b>, other program modules <b>1332</b>, program data <b>1334</b>, or any combination thereof, may include one or more embodiments of the systems and methods described herein.

Computing device <b>1302</b> can include a variety of computer readable media identified as communication media. Communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, other wireless media, and/or any combination thereof.

A user can interface with computing device <b>1302</b> via any number of different input devices such as a keyboard <b>1336</b> and pointing device <b>1338</b> (e.g., a “mouse”). Other input devices <b>1340</b> (not shown specifically) may include a microphone, joystick, game pad, controller, satellite dish, serial port, scanner, and/or the like. These and other input devices are connected to the processors <b>1304</b> via input/output interfaces <b>1342</b> that are coupled to the system bus <b>1308</b>, but may be connected by other interface and bus structures, such as a parallel port, game port, and/or a universal serial bus (USB).

A display device <b>1344</b> (or other type of monitor) can be connected to the system bus <b>1308</b> via an interface, such as a video adapter <b>1346</b>. In addition to the display device <b>1344</b>, other output peripheral devices can include components such as speakers (not shown) and a printer <b>1348</b> which can be connected to computing device <b>1302</b> via the input/output interfaces <b>1342</b>.

Computing device <b>1302</b> can operate in a networked environment using logical connections to one or more remote computers, such as remote computing device <b>1350</b>. By way of example, remote computing device <b>1350</b> can be a personal computer, portable computer, a server, a router, a network computer, a peer device or other common network node, and the like. The remote computing device <b>1350</b> is illustrated as a portable computer that can include any number and combination of the different components, elements, and features described herein relative to computing device <b>1302</b>.

Logical connections between computing device <b>1302</b> and the remote computing device <b>1350</b> are depicted as a local area network (LAN) <b>1352</b> and a general wide area network (WAN) <b>1354</b>. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When implemented in a LAN networking environment, the computing device <b>1302</b> is connected to a local network <b>1352</b> via a network interface or adapter <b>1356</b>. When implemented in a WAN networking environment, the computing device <b>1302</b> typically includes a modem <b>1358</b> or other means for establishing communications over the wide area network <b>1354</b>. The modem <b>1358</b> can be internal or external to computing device <b>1302</b>, and can be connected to the system bus <b>1308</b> via the input/output interfaces <b>1342</b> or other appropriate mechanisms. The illustrated network connections are merely exemplary and other means of establishing communication link(s) between the computing devices <b>1302</b> and <b>1350</b> can be utilized.

In a networked environment, such as that illustrated with computing environment <b>1300</b>, program modules depicted relative to the computing device <b>1302</b>, or portions thereof, may be stored in a remote memory storage device. By way of example, remote application programs <b>1360</b> are maintained with a memory device of remote computing device <b>1350</b>. For purposes of illustration, application programs and other executable program components, such as operating system <b>1328</b>, are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computing device <b>1302</b>, and are executed by the one or more processors <b>1304</b> of the computing device <b>1302</b>.

Although embodiments for preconditioning the stochastic simulation of computer system performance have been described in language specific to structural features and/or methods, it is to be understood that the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as illustrative implementations for preconditioning input while simulating deployments of computer software.