Remote connection between intermediary device and computing device via central authority software

BACKGROUND

p-0002In typical networked computing environments, each user is provided with a computing device located near the user and that is networked with the other computing devices and with server computing devices as well as peripheral devices. However, this approach is less than advantageous for hardware management purposes. In particular, when a computing device requires maintenance or repair, IT personnel have to physically visit the location of the computing device to perform the needed maintenance or repair.

p-0003Therefore, techniques have been increasingly employed in computing environments to overcome this problem. Such techniques centralize the computing devices of users within a single location that is more conveniently accessible by IT personnel. However, these prior art techniques can be difficult to employ in relation to an existing networked computing environment in which each user has his or her own computing device located near the user.

p-0004For example, remotization techniques that employ keyboard-video-mouse (KVM) devices to transfer such KVM traffic back and forth to the centralized computing devices may have distance limitations as to how far the KVM devices can be positioned relative to the computing devices. The KVM devices may also not work with certain types of peripheral devices, especially Universal Serial Bus (USB) devices. Furthermore, new cabling may be needed to connect the KVM devices to the centralized computing devices, increasing cost. All these configurations also require management of the connections to and from the user location, which increases cost.

p-0005For this and other reasons, therefore, there is a need for the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0006<figref idrefs="DRAWINGS">FIG. 1</figref> is a diagram of a system, according to an embodiment of the invention.

p-0007<figref idrefs="DRAWINGS">FIG. 2</figref> is a flowchart of a method, according to an embodiment of the invention.

p-0008<figref idrefs="DRAWINGS">FIG. 3</figref> is a rudimentary diagram of an intermediary device, according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

p-0009<figref idrefs="DRAWINGS">FIG. 1</figref> shows a system <b>100</b>, according to an embodiment of the invention. Most components of the system <b>100</b> are located in one of two locations: a user location <b>102</b>, or a remote location <b>104</b>. The network <b>106</b> communicatively connects the components of the system <b>100</b> at the user location <b>102</b> with those at the remote location <b>104</b>, and therefore is not considered to be only at one location.

p-0010The user location <b>102</b> is the location at which end users are located. At the user location <b>102</b> is an intermediary device <b>108</b>. A number of different types of devices are connected to the intermediary device <b>108</b>, including a display device <b>110</b>A, a keyboard device <b>110</b>B, a pointing device <b>110</b>C, and one or more peripheral devices <b>110</b>D. All of these devices are collectively referred to as the devices <b>110</b>, and there may be more or less of the devices than is depicted in <figref idrefs="DRAWINGS">FIG. 1</figref>, of the same or different types. The peripheral devices <b>110</b>D, as well as the keyboard device <b>110</b>B and the pointing device <b>110</b>C, may be Universal Serial Bus (USB) devices, for instance.

p-0011The user interacts directly with the devices <b>110</b> connected to the intermediary device <b>108</b>. Thus, the user provides input on the keyboard device <b>110</b>B and the pointing device <b>110</b>C, and views visual output on the display device <b>110</b>A. The user may also directly interact with the peripheral devices <b>110</b>D. The intermediary device <b>108</b> may be a thin-client computing device, for instance, with no moving parts, a representative example of which is described later in the detailed description. Whereas one instance of an intermediary device <b>108</b> and associated devices <b>110</b> is depicted in <figref idrefs="DRAWINGS">FIG. 1</figref> for illustrative convenience, in actuality there may be one such instance per each user, for example, or at least more than one instance of an intermediary device and associated devices.

p-0012The remote location <b>104</b> is desirably a centralized location that is relatively conveniently accessible to Information Technology (IT) personnel, and may be a secure location not readily accessible by the end users at the user location <b>102</b>. As depicted in the example of <figref idrefs="DRAWINGS">FIG. 1</figref>, one or more server computing devices <b>112</b>, and two computing devices <b>114</b> and <b>116</b> are located at the remote location <b>104</b>. The computing devices <b>114</b> and <b>116</b> are the actual computing devices used by the end users remotely via intermediary devices at the user location <b>102</b>. In the example of <figref idrefs="DRAWINGS">FIG. 1</figref>, the computing device <b>114</b> is particularly that with which the intermediary device <b>108</b> communicates, whereas the computing device <b>116</b> may be considered a spare computing device that is used if the computing device <b>114</b> malfunctions. The computing devices <b>112</b>, <b>114</b>, and <b>116</b> are connected to the network <b>106</b>, and each have a public network address, such as an Internet Protocol (IP) address, which may be obtained using a conventional static or dynamic approach, as can be appreciated by those of ordinary skill within the art.

p-0013While only two computing devices <b>114</b> and <b>116</b> are depicted in the example of <figref idrefs="DRAWINGS">FIG. 1</figref>, in actuality there may be less or more of such computing devices <b>114</b> and <b>116</b>. As suggested by <figref idrefs="DRAWINGS">FIG. 1</figref>, the computing devices <b>114</b> and <b>116</b> are each an actual physical instance of a computing device, having its own case or enclosure, and so on. In another embodiment, however, the computing devices <b>114</b> and <b>116</b> may be “blade” computing devices disposed within the same case or enclosure, and may indeed by installed within the server computing devices <b>112</b>, or another server computing device. Furthermore, the computing devices <b>114</b> and <b>116</b> may alternatively be virtual computing devices running on the same set of hardware, as part of the server computing devices <b>112</b>, or another server computing device.

p-0014An overview of the manner by which the system <b>100</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> is employed is now presented, where the details are presented in relation to a method subsequently described in the detailed description. The server computing devices <b>112</b> include a tangible compute-readable medium <b>118</b>, such as a recordable data storage medium, volatile semiconductor memory, and so on, on which central authority software <b>120</b> resides. The software <b>120</b> may run on one of the server computing devices <b>112</b>, or its execution may be distributed over a number of the server computing devices <b>112</b>.

p-0015When the user turns on the intermediary device <b>108</b>, the central authority software <b>120</b> instructs both the intermediary device <b>108</b> and the computing device <b>114</b> to establish a private tunnel <b>122</b> over the network <b>106</b> with one another. Thereafter, the intermediary device <b>108</b> opens a remote desktop connection with the computing device <b>114</b> through the tunnel <b>122</b>. User interaction with the devices <b>110</b> is communicated between the computing device <b>114</b> and the intermediary device <b>108</b> through the tunnel <b>122</b> as well.

p-0016The central authority software <b>120</b> allows information technology (IT) personnel to manage the computing devices <b>114</b> and <b>116</b> remotely. For instance, if the computing device <b>114</b> develops a malfunction, the IT personnel can have the intermediary device <b>108</b> establish a private tunnel with the computing device <b>116</b> instead of the computing device <b>114</b>. Thus, a visit to the user location <b>102</b> is not necessary (or can be scheduled more flexibly) to fix many types of problems that commonly develop within computing devices. The IT personnel may remain at the remote location <b>104</b>, or, indeed, may be at a location other than the remote location <b>104</b> and the user location <b>102</b>.

p-0017In one embodiment of the invention, the central authority software <b>120</b> can automatically connect the intermediary device <b>108</b> to the computing device <b>116</b> when the software <b>102</b> detects that the computing device <b>114</b> is malfunctioning. Such automatic connection is achieved without the intervention of IT personnel. The central authority software <b>120</b> may detect that the computing device <b>114</b> is malfunctioning by examining the state of the device <b>114</b> itself. Additionally, or alternatively, the software <b>120</b> may detect that the computing device <b>114</b> is malfunctioning by a user informing the software <b>120</b> of an anomalous situation.

p-0018Furthermore, the central authority software <b>120</b> allows a dividing of the devices <b>110</b> connected to the intermediary device <b>108</b> insofar as to which of the computing devices <b>114</b> and <b>116</b> the devices <b>110</b> are virtually connected. For instance, the intermediary device <b>108</b> may enable a user to log on and use the computing device <b>114</b> with respect to the devices <b>110</b>A, <b>110</b>B, and <b>110</b>C, but another user may use one or more of the peripheral devices <b>110</b>D in relation to another computing device, such as the computing device <b>116</b>. In this respect, the system <b>100</b> provides for more flexibility in the division and assignment of peripheral devices among the computing devices.

p-0019As will become apparent later in the detailed description, the remotization and/or virtualization approach employed by at least some embodiments of the present invention differs from those within the prior art at least in one or more of the following ways. First, the intermediary device <b>108</b> is essentially invisible within the network <b>106</b>. That is, it is not assigned a public network address on the network <b>106</b>, such as a static or a dynamic IP address. As such, network administrators do not have to allocate new network addresses for such intermediary devices being added to the system <b>100</b>. Rather, the intermediary device <b>108</b> is communicated with over the network <b>106</b> via a device-unique address, such as a Media Access Control (MAC) address, rather than with a public network address like an IP address.

p-0020Second, the intermediary device <b>108</b> is essentially transparent to the end user. The user may turn on the intermediary device <b>108</b>, which alerts the central authority software <b>120</b> of this fact. The software <b>120</b> may then cause the computing device <b>114</b> to be turned on remotely, without interaction by the end user. User authentication may be provided only at the computing device <b>114</b>, as opposed to at the computing device <b>114</b> and at the intermediary device <b>108</b>, for instance. The presence of the intermediary device <b>108</b> thus does not affect the end user experience in any way except for the fact that the intermediary device <b>108</b> is located near the user instead of the computing device <b>114</b>. When the user turns off the intermediary device <b>108</b>, the central authority software <b>120</b> is alerted, and may itself remotely turn off the computing device <b>114</b>, without end user interaction.

p-0021As compared to the prior art, at least some embodiments of the present invention are advantageous in that they do not require deployment of new hardware except for the relatively inexpensive intermediary devices, such as the device <b>108</b>. Some of the existing computing devices, like the devices <b>114</b> and <b>116</b>, could simply be moved from the end user location <b>102</b> to the remote location <b>104</b>. By comparison, existing virtualization techniques in particular can require that all new computing devices be purchased to replace the computing devices. Virtualization is where multiple users have virtual computing devices assigned to them and that run on the same one or more server computing devices. As such, the existing computing devices of the users usually cannot be employed in virtualization.

p-0022Furthermore, as compared to prior art remotization techniques, at least some embodiments of the present invention are advantageous in that they do not have the same distance and cabling constraints. The existing networking cables that connect the computing devices at the user location <b>102</b> to the network <b>106</b> can be used when these computing devices are moved to the remote location <b>104</b> and substituted at the user location <b>102</b> with intermediary devices. This is because the intermediary device <b>108</b> establishes the private tunnel <b>122</b> with the computing device <b>114</b> over the network <b>106</b>, such that communication over the private tunnel <b>122</b> is achieved over the network <b>106</b>.

p-0023By comparison, prior art remotization techniques, such as keyboard-video-mouse (KVM) techniques, typically do not achieve communication between the KVM hardware and the remote computing device over a network. Existing network cables may be employed between the KVM hardware and the remote computing device, but there may be distance limitations that are not present with typical network communication. Furthermore, a direct connection between the KVM hardware and the remote computing device may be required, as opposed to typical network communication which can be achieved via hubs, switches, routers, and so on. In some instances, completely new networking cables may have to be run, such as CAT6 cabling instead of the more common CAT5 and CAT5e cabling found in legacy environments.

p-0024Finally, as compared to prior art techniques, at least some embodiments of the present invention are advantageous in that they allow for utilization of nearly any peripheral devices at the intermediary device <b>108</b>. USB peripheral devices in particular have their communication sent over a USB/IP connection through the private tunnel <b>122</b> over the network <b>106</b>. The intermediary device <b>108</b> does not have to have any knowledge of specific details of the USB peripheral devices themselves, which is advantageous where the intermediary device <b>108</b> runs an operating system or other software that does not in actuality support these devices.

p-0025Rather, the intermediary device <b>108</b> simply conveys low-level USB communication at the Host Controller Interface (HCI) level through the private tunnel <b>122</b> to the computing device <b>114</b>. Low-level USB communication at the HCI level means that just simple sequences of data read and write operations are conveyed through the private tunnel <b>122</b>. Application programs running on the computing device <b>114</b> therefore have no knowledge that these peripheral devices are not directly connected to the computing device <b>114</b>, and instead are actually directly connected to the intermediary device <b>108</b>. For legacy serial or parallel devices, readily available and inexpensive serial-to-USB and parallel-to-USB conversion devices can be employed within embodiments of the present invention.

p-0026By comparison, prior art techniques often have difficulty with supporting USB peripheral devices in particular. Where a thin client computing device is used at the user location <b>102</b>, prior art techniques can require that this thin client device itself support the USB peripheral devices, which is problematic where the thin client device runs an operating system or other software for which there are no drivers for the USB peripheral devices in question. KVM solutions also usually do not support peripheral devices besides keyboards, display devices, and pointing devices, which means that environments in which other types of devices have to be accessed by end users are not as suitable for KVM approaches to remotization.

p-0027<figref idrefs="DRAWINGS">FIG. 2</figref> shows a method <b>200</b> for realizing a remote connection between the intermediary device <b>108</b> and the computing device <b>114</b> via the central authority software <b>120</b> and that realizes the advantages that have been described, according to an embodiment of the invention. <figref idrefs="DRAWINGS">FIG. 2</figref> is divided into three columns, indicating which parts of the method <b>200</b> are performed by the intermediary device <b>108</b>, which parts are performed by the central authority software <b>120</b>, and which parts are performed by the computing device <b>114</b>. The intermediary device <b>108</b>, the central authority software <b>120</b>, and the computing device <b>114</b> communicate over the network <b>106</b> in performing the method <b>200</b>.

p-0028The method <b>200</b> is performed upon the intermediary device <b>108</b> being turned on by the end user. For instance, the end user may press a power button on the intermediary device <b>108</b>. The intermediary device <b>108</b> then boots the controlling system software (<b>202</b>) that is stored on the device <b>108</b>. The controlling system software may be operating system software, such as a version of the LINUX® operation system, or a version of the Microsoft Windows® operating system, available from Microsoft Corp., of Redmond, Wash. The controlling system software allows the intermediary device <b>108</b> to communicate over the network <b>106</b>, but the intermediary device <b>108</b> does not ever have assigned to it a public network address. The controlling system software can in one embodiment be considered as that which performs the parts of the method <b>200</b> ascribed to the intermediary device <b>108</b>.

p-0029A public network address as used herein is a network address that identifies a resource on the network <b>106</b> in a public manner in accordance with a predetermined network protocol such that other resources on the network <b>106</b> are able to send data to and receive data from the resource via the predetermined network protocol using this network address. An example of such a public network address is an IP address, which is used to identify resources on the network <b>106</b> so that they are able to communicate data in accordance with the Transmission Control Protocol (TCP)/IP network protocol. IP addresses are typically in the form of a.b.c.d, where each of a, b, c, and d is an integer between 0 and 255.

p-0030IP addresses are typically assigned in a dynamic or a static manner. Dynamic IP address assignment usually means that a resource upon locating the network <b>106</b> sends a request over the network <b>106</b> to receive an IP address. In response, a server, such as a Dynamic Host Configuration Protocol (DHCP) server, provides the resource with a network address that is currently not being used by any other resource on the network. Such dynamic IP addresses are leased to resources, such that the resources have to renew their addresses, or request new ones, based on the period of the lease.

p-0031By comparison, static IP address assignment usually means that a resource is manually assigned a resource during configuration of the resource by a user, such as IT personnel. The user has to take care that the static IP address assigned will be unique as compared to other IP addresses that other resources may have. Because the intermediary device <b>108</b> is not ever assigned such a public network address dynamically or statically, IT personnel thus do not have to ensure that there are sufficient numbers of these network addresses available when adding the intermediary device <b>108</b> to the network <b>106</b>. That is, with respect to the network protocol that utilizes these network addresses, the intermediary device <b>108</b> is effectively invisible.

p-0032The terminology public network address is further public in a way that may be different than the term public is usually employed. For example, all of the resources on the network <b>106</b> (except the intermediary device <b>108</b>) may share the same IP address insofar as communication over or with the Internet is concerned, where the network <b>106</b> is a local-area network (LAN), and network-address translation (NAT) or another approach is employed to allow such sharing. In such instance, conventionally the IP address that identifies these resources on the Internet is referred to as a public IP address. The resources may also have private IP addresses that identify them individually on just the network <b>106</b> to other resources also on the network <b>106</b>.

p-0033By comparison, the terminology public network address as used herein is inclusive of and encompasses such utilization of private IP addresses. That is, the private IP addresses that may be assigned to all the resources on the network <b>106</b> (except the intermediary device <b>108</b>) to identify themselves to the other resources on the network <b>106</b> are considered public network addresses insofar as embodiments of the invention are concerned. Such private IP addresses are considered public network addresses herein because they publicly identify the resources to other resources, even if these resources are on the same network <b>106</b>. By comparison, the terminology private IP addresses and public IP addresses is conventionally used to distinguish IP addresses used on a smaller network (such as a LAN) as compared addresses used on the Internet itself.

p-0034Therefore, that the intermediary device <b>108</b> is not ever assigned a public network address means that it is not ever assigned a network address that identifies the device <b>108</b> to other resources on the network <b>106</b> insofar as a particular network protocol is concerned. For example, the intermediary device <b>108</b> is never dynamically or statically assigned a private or a public IP address as to the network <b>106</b>. As such, the intermediary device <b>108</b> is essentially invisible to the other resources on the network <b>106</b>, insofar as the TCP/IP network protocol is concerned.

p-0035The intermediary device <b>108</b> upon booting sends a boot message to the central authority software <b>120</b> (<b>204</b>). The boot message may be considered a public broadcast message that is sent on the network <b>106</b> by the intermediary device <b>108</b>. Because the intermediary device <b>108</b> does not have a public network address, such as a public IP address, it uses a protocol other than the network protocol that utilizes these network addresses, such as the TCP/IP protocol or the IP protocol. For instance, the intermediary device <b>108</b> may use a lower-level (i.e., different) protocol than TCP/IP, in which the device <b>108</b> identifies itself via a device-unique address of the intermediary device <b>108</b>.

p-0036One example of a device-unique address is a Media Access Control (MAC) address, of the form aa:bb:cc:dd:ee:ff, where each of aa, bb, cc, dd, ee, and ff is a hexadecimal number between 00 and FF. MAC addresses are also known to those of ordinary skill within the art as “Ethernet” addresses, but are different from IP addresses. As is conventional, every piece of hardware intended to directly communicate over a network is assigned a unique MAC address. The device-unique address is not considered a public network address as used herein, however, because the device-unique address does not enable the intermediary device <b>108</b> to communicate in the same manner as devices having network addresses. For instance, communication using a MAC address is achieved using a network protocol that is lower or more fundamental (and thus different) than the TCP/IP protocol.

p-0037The central authority software <b>120</b> receives the boot message over the network <b>106</b> (<b>206</b>). The boot message from the intermediary device <b>108</b> includes the device-unique address of the device <b>108</b>. In response, the central authority software <b>120</b> may first send the intermediary device <b>108</b> a public encryption key of the software <b>120</b> over the network <b>106</b> (<b>210</b>), and the intermediary device <b>108</b> receives this public encryption key (<b>208</b>). The software <b>120</b> sends the public encryption key to the intermediary device <b>108</b> by using the device-unique address of the device <b>108</b>, since the device <b>108</b> does not have a public network address. The intermediary device <b>108</b> may install the public encryption key internally as a Secure SHell (SSH) certificate.

p-0038The public encryption key of the central authority software <b>120</b> may be employed by the intermediary device <b>108</b> to encrypt all communications with the central authority software <b>120</b>. Furthermore, the public encryption key ensures that only the software <b>120</b>, and not any rogue software, will be able to control the intermediary device <b>108</b>. Any management requests sent by the central authority software <b>120</b> to the intermediary device <b>108</b> are checked against the public encryption key, to ensure that it is in fact the central authority software <b>120</b> that originated such requests. As such, security of the system <b>100</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> is ensured insofar as the addition of the intermediary device <b>108</b> into the system <b>100</b> is concerned.

p-0039The central authority software <b>120</b> then selects to which computing device the intermediary device <b>108</b> will connect (<b>212</b>). For example, the software <b>120</b> may store a database of intermediary devices to computing devices to determine which computing device the intermediary device <b>108</b> in particular will connect. For example purposes only, it is presumed that the central authority software <b>120</b> selects the computing device <b>114</b>. The same computing device may always be selected for the same intermediary device, or the next available computing device may be selected for a given intermediary device. Other approaches may further be employed to select computing devices for intermediary devices.

p-0040The central authority software <b>120</b> may verify that the computing device <b>114</b> that has been selected is turned on. If it is turned off, the central authority software <b>120</b> may thus turn on the computing device <b>114</b> remotely (<b>214</b>). For instance, “wake-on-LAN” capability of the computing device <b>114</b> may be leveraged, so that the software <b>120</b> can send a special message to the computing device <b>114</b> over the network <b>106</b> to boot the computing device <b>114</b>. After waking the computing device <b>114</b>, the central authority software <b>120</b> may wait before sending the messages in part <b>216</b> of the method <b>200</b>, or otherwise stall the intermediary device <b>108</b>, until the computing device <b>114</b> has booted and is ready to accept a remote connection from the intermediary device <b>108</b>.

p-0041Thereafter, the central authority software <b>120</b> sends messages over the network <b>106</b> to the intermediary device <b>108</b> and the computing device <b>114</b> instructing them to establish a private tunnel <b>122</b> with one another (<b>216</b>). The intermediary device <b>108</b> receives its message (<b>218</b>), and the computing device <b>114</b> receives its message (<b>220</b>). The message may be sent to the intermediary device <b>108</b> using a network protocol that allows for the device <b>108</b> to have just a device-unique address, such as a MAC address, and not a public network address, such as an IP address. By comparison, the message may be sent to the computing device <b>114</b> using the public IP address thereof by which the computing device <b>114</b> is known within in the network <b>106</b>.

p-0042The intermediary device <b>108</b> and the computing device <b>114</b> then establish a private tunnel <b>122</b> with one another over the network <b>106</b> (<b>222</b>, <b>224</b>). The private tunnel <b>122</b> is a point-to-point communication tunnel so that the devices <b>108</b> and <b>114</b> can communicate with one another in a secure manner. The private tunnel <b>122</b> may be considered a Virtual Private Network (VPN) between the devices <b>108</b> and <b>114</b>, for instance. The private tunnel <b>122</b> may be comparable to an IP security (Ipsec) tunnel, a Layer 2 Tunneling Protocol (L2TP) tunnel, or a Point-to-Point Tunneling Protocol PPTP (PPTP) tunnel. However, the private tunnel <b>122</b> is different than typical VPN tunnels in that the intermediary device <b>108</b> does not have a public network address, such as an IP address, but just a device-unique address, such as a MAC address. Therefore, the private tunnel <b>122</b> is established with a quasi-custom tunneling protocol that takes this fact into account.

p-0043It is noted, however, that the software running on the intermediary device <b>108</b>, as well as the software running on the computing device <b>114</b>, such as application programs, may be geared towards communication in a TCP/IP network protocol manner, and thus require a destination and/or a source network (i.e., IP) address to function properly. In such embodiments, each of the intermediary device <b>108</b> and the computing device <b>114</b> may assign itself an internal private network address for device-internal and/or tunnel-internal use only by such software. Because these network addresses are specific only to an intermediary device-computing device pair, they may be reused for each such intermediary device-computing device pair. For example, the private IP addresses 10.0.0.1 and 10.0.0.2 may be reused for each such pair. Thus, the private IP network addresses are guaranteed unique only as to the devices <b>108</b> and <b>114</b> at either end of the private tunnel <b>122</b>.

p-0044In this way, software that runs on the devices <b>108</b> and <b>114</b> that requires communication using network addresses, such as IP addresses, is still able to function, because of the internally used private network addresses. It is noted that the terminology private network address is used herein differently than is conventional. For instance, conventionally, a private IP address may connotate an IP address that identifies a resource on a limited network, such as a LAN, but that otherwise does not identify the resource over a broader network, such as the Internet, as has been described. By comparison, a private network address, such as a private IP address, in the context here means that the devices <b>108</b> and <b>114</b> assign themselves private IP addresses for utilization within the scope of the private tunnel <b>122</b> only, for the benefit of any software requiring such network addresses that are running on the devices <b>108</b> and <b>114</b>.

p-0045Therefore, it is still correctly said that the intermediary device <b>108</b> does not have a public network address, even a private network address as that terminology is conventionally understood, on the network <b>106</b>. Rather, the private network address assigned to the intermediary device <b>108</b> is used only in the context of the private tunnel <b>122</b> between the device <b>108</b> and the computing device <b>114</b>, for use by, for instance, application programs running on the devices <b>108</b> and <b>114</b>. This private network address is not comparable to a private IP address as may be employed in NAT and other networking approaches within the prior art.

p-0046Once the private tunnel <b>122</b> between the intermediary device <b>108</b> and the computing device <b>114</b> has been established over the network <b>106</b>, the intermediary device <b>108</b> can then open a remote connection to the computing device <b>114</b> through the private tunnel <b>122</b> (<b>226</b>). Where the computing device <b>114</b> is running a version of the Microsoft Windows® operating system, for instance, this remote connection may be a Remote Desktop Protocol (RDP) connection. Other types of remote connections are also amenable to implementation in relation to embodiments of the invention, such as, the Virtual Network Computing (VNC) protocol described at the Internet web site www.realvnc.com, and the Citrix protocol described at www.citrix.com. The remote connection allows a user at the intermediary device <b>108</b> to interact with the computing device <b>114</b> as if he or she were directly working on the device <b>114</b>.

p-0047User authentication within the system <b>100</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> may be achieved only by virtue of this remote connection. That is, the user may not in one embodiment have to authenticate him or herself at the intermediary device <b>108</b> at all. Rather, once the remote connection from the intermediary device <b>108</b> to the computing device <b>114</b> has been opened through the private tunnel <b>122</b> over the network <b>106</b>, the user authenticates him or herself as if he or she were directly working on the device <b>114</b>. In this way, the intermediary device <b>108</b> is largely invisible to the user insofar as the user experience is concerned. The user does not have to be assigned a new user name and/or password, and does not have to logon to both the intermediary device <b>108</b> and the computing device <b>114</b>. Rather, the user only has to logon to the computing device <b>114</b>, no different than if the intermediary device <b>108</b> were not present.

p-0048The remote connection to the computing device <b>114</b> enables the devices <b>110</b> connected to the intermediary device <b>108</b> to be used in relation to the computing device <b>114</b>. As such, communications of USB peripherals in particular are conveyed through the private tunnel <b>122</b> (<b>228</b>). Such back-and-forth communications from USB peripherals are achieved over a USB/IP connection. When a USB device communicates, the intermediary device <b>108</b> receives this communication, and sends it over the private tunnel <b>122</b> to the computing device <b>114</b>. This transmission may use the private network addresses of the devices <b>108</b> and <b>114</b>, and where these addresses are private IP addresses, the connection is referred to as a USB/IP connection.

p-0049The computing device <b>114</b> receives the USB device communications, and a virtual USB HCI software installed at the device <b>114</b> enables application programs and other software to access the communications and hence the USB device in question. Likewise, when an application program or other software at the computing device <b>114</b> wishes to send communications to a USB device connected to the intermediary device <b>108</b>, the virtual USB HCI software installed at the device <b>114</b> sends the communications via the USB/IP connection to the intermediary device <b>108</b>. The intermediary device <b>108</b> then transmits the communications to the appropriate USB device. Likewise, the USB device connected to the intermediary device <b>108</b> can autonomously initiate communication to the device <b>114</b> using the same approach that has been described.

p-0050This approach of virtualized USB devices insofar as the computing device <b>114</b> is concerned is advantageous in a number of respects. First, the intermediary device <b>108</b> does not need to have any driver specific to any of the USB devices that may be connected thereto. This is desirable, because the intermediary device <b>108</b> may run a different operating system than the computing device <b>114</b>, and the driver software for a given USB device may be available only for the operating system running on the device <b>114</b>, and not for the operating system running on the device <b>108</b>. For instance, some USB devices may only have driver software available for specific versions of the Microsoft Windows® operating system, and not for versions of the LINUX® operating system. Thus, the intermediary device <b>108</b> does not need to have any knowledge of the specific details of the USB devices themselves, but simply transmits communications to and from such devices in relation to the private tunnel <b>122</b> for the computing device <b>114</b>.

p-0051Second, the application programs and other software running on the computing device <b>114</b> do not have any knowledge that the USB devices are not directly connected to the computing device <b>114</b> itself. The virtual USB HCI is used instead of an actual USB HCI for physical (actual) USB ports of the device <b>114</b>. The USB device driver software is installed on the computing device <b>114</b> no different than if the USB device were connected directly to the device <b>114</b>. The USB device driver software indeed itself does not have knowledge that its corresponding USB device is not directly connected to the computing device <b>114</b> itself, because it interacts with the virtual USB HCI no different than with an actual USB HCI for physical USB ports. Therefore, insofar as the virtual USB HCI mimics or virtualizes an actual USB HCI, the USB device driver software requires no modification. As such, USB devices connected to the intermediary device <b>108</b> are used by the computing device <b>114</b> no different than if they were directly connected to the device <b>114</b>.

p-0052At some point, the user of the intermediary device <b>108</b> may log off the computing device <b>114</b> via the remote connection through the private tunnel <b>122</b>, and ultimately turn off the intermediary device <b>108</b> (<b>230</b>). For instance, the user may press the power button on the intermediary device <b>108</b>. In response, the intermediary device <b>108</b> logs the user off the computing device <b>114</b>, and sends an appropriate message to the central authority software <b>120</b>, which receives the message (<b>232</b>). According to a policy established by the system administrator or other IT personnel, the software <b>120</b> may then turn off the computing device <b>114</b> remotely (<b>234</b>). If the user was not logged off the computing device <b>114</b> already, the software <b>120</b> may first log the user off the device <b>114</b> prior to turning it off remotely. The private tunnel <b>122</b> between the devices <b>108</b> and <b>114</b> is thus deleted.

p-0053<figref idrefs="DRAWINGS">FIG. 3</figref> shows a rudimentary diagram of the intermediary device <b>108</b>, according to an embodiment of the invention. The device <b>108</b> is depicted in <figref idrefs="DRAWINGS">FIG. 3</figref> as including a network component <b>302</b>, one or more device ports <b>304</b>, and a computer-readable medium <b>306</b>. As can be appreciated by those of ordinary skill within the art, the device <b>108</b> may include other components, in addition to and/or in lieu of those depicted in <figref idrefs="DRAWINGS">FIG. 3</figref>. For instance, the device <b>108</b> typically will have one or more processors, as well as volatile semiconductor memory. In one embodiment, the device <b>108</b> may be a thin-client computing device, having a minimum amount of hardware processing power needed to perform its functionality. The device <b>108</b> may not have any moving parts, such as no hard disk drives, in one embodiment.

p-0054The network component <b>302</b> is that which enables the intermediary device <b>108</b> to communicate over the network <b>106</b>. As has been described, the intermediary device <b>108</b> is never assigned a public network address, such as a public IP address, to identify the device <b>108</b>. Rather, the device <b>108</b> itself, or the component <b>302</b>, has a device-unique address, such as a MAC address, by which communication is achieved.

p-0055The ports <b>304</b> enable the devices <b>110</b> to be connected directly to the intermediary device <b>108</b>. In one embodiment, the ports <b>304</b> include a display device port, such as a Video Graphics Array (VGA) port or a Digital Visual Interface (DVI) port, to provide for the display device <b>110</b>A connecting to the intermediary device <b>108</b>. In one embodiment, the ports <b>304</b> also include a number of USB ports, to which the keyboard device <b>110</b>B, the pointing device <b>110</b>C, and the other peripheral devices <b>110</b>D are connected. Where keyboards and pointing devices have other types of interfaces, such as PS/2 connectors, instead of USB connectors, simple PS/2-to-USB converters can be employed. Likewise, where peripherals have other types of interfaces, such as serial ports, instead of USB connectors, relatively inexpensive serial-to-USB converters can be employed.

p-0056The computer-readable medium <b>306</b> may be hard disk drive, or another type of non-volatile storage. For instance, where the intermediary device <b>108</b> does not have any moving parts, the medium <b>306</b> may be non-volatile semiconductor memory, such as flash memory. The computer-readable medium <b>306</b> stores the controlling system software <b>308</b> thereon that performs the functionality ascribed to the intermediary device <b>108</b> in the method <b>200</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> that has been described. As such, the software sends a boot message over the network <b>106</b> to the central authority software <b>120</b>, establishes a private tunnel <b>122</b> over the network <b>106</b> with the computing device <b>114</b>, and so on.

p-0057It is noted that, although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This application is intended to cover any adaptations or variations of the disclosed embodiments of the present invention. Therefore, it is manifestly intended that this invention be limited only by the claims and equivalents thereof.