WO2010117369A1

WO2010117369A1 - Partitioning of compound or composite usb devices in a remote usb environment

Info

Publication number: WO2010117369A1
Application number: PCT/US2009/040200
Authority: WO
Inventors: James M King; Rick E Aulino
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2009-04-10
Filing date: 2009-04-10
Publication date: 2010-10-14
Also published as: GB201115582D0; DE112009004568T5; GB2481153A; CN102388376A; GB2481153B; CN102388376B

Abstract

A system and method are provided for partitioning compound or composite USB devices in a remote USB environment. A first computer host has USB remoting logic and USB device partitioning logic. The USB remoting logic is configured to cause a USB device attached to the first computer host to be accessible to resources running on a second or third computer host. When a compound or composite USB device is connected to the first computer host, the USB device partitioning logic presents a first virtual USB device to the second computer host and a second virtual USB device to the third computer host. The first and second virtual USB devices each contain different parts from a partition of the set of USB functions that are present in the underlying compound or composite USB device.

Description

Partitioning of Compound or Composite USB Devices in a Remote USB Environment

Field of the Invention

[001] This invention relates generally to techniques for causing Universal Serial Bus ("USB") peripheral devices that are attached to a first computer host to be accessible to resources that are running on a second computer host remote from the first.

Background

[002] Protocols exist that enable a user at a local computer to access and share the desktop of a remote computer (e.g. a central server) over a computer network. One such protocol is the Remote Desktop Protocol ("RDP") as provided by Microsoft Corporation, which provides remote display and input capabilities over network connections. Another protocol that can be used in this context is the Remote Graphics Software ("RGS") protocol from the Hewlett Packard Co. RGS is designed to take advantage of the computer and graphics resources of a remote computer to deliver interactive remote access at the local computer. The desktop graphics data of the remote computer are transmitted over a network to the local computer, which displays the desktop graphics data locally in a window at the local computer. RGS captures user keyboard and mouse inputs at the local computer, and sends the keyboard and mouse inputs to the remote computer for processing by the operating system of the remote computer, and by applications running on the remote computer. RGS also allows data of some peripheral devices such as storage devices to be communicated from the local computer to the remote computer.

[003] A modern adjunct for RDP, RGS or similar systems is the ability to cause a USB device that is physically attached to the local computer host to be accessible to resources that are running on the remote computer host. The latter arrangement will be referred to hereinafter as a "remote USB environment."

Brief Description of the Drawings

[004] Fig.l is a block diagram illustrating a system for partitioning compound or composite USB devices in a remote USB environment according to a preferred embodiment of the invention.

[005] Fig. 2 is a block diagram illustrating the computer hosts of Fig. I in greater detail according to a preferred embodiment of the invention.

[006] Fig. 3 is a flow diagram illustrating a method for partitioning compound or composite USB devices in a remote USB environment according to a preferred embodiment of the invention.

[007] Fig. 4 is a table illustrating example state capable of indicating, according to a preferred embodiment of the invention, to which of several hosts the functions of compound or composite USB devices should be presented. [008] Fig. 5 is a block diagram illustrating an example partitioning of the USB functions contained in the compound and composite devices of Fig. 1 according to a preferred embodiment of the invention.

[009] Fig. 6 is a flow diagram illustrating a method for setting the state of Fig. 4 according to one preferred embodiment of the invention.

[010] Fig. 7 is a flow diagram illustrating a method for setting the state of Fig. 4 according to another preferred embodiment of the invention.

[011] Fig. 8 is a flow diagram illustrating a method for setting the state of Fig. 4 according to yet another preferred embodiment of the invention.

Detailed Description of the Preferred Embodiments

[012] Fig.1 illustrates a system 100 for partitioning compound or composite USB devices in a remote USB environment according to a preferred embodiment of the invention. Three computer hosts 102, 104, 106 are pictured. In other embodiments, more computer hosts may be used. Computer host 102 is equipped with USB remoting logic 108, and computer hosts 104, 106 arc equipped with USB remoting logic 109. USB remoting logics 108, 109 will be described in more detail below in relation to Fig. 2. In some embodiments, host 102 may have access to a configuration file 110, such as on a storage device or memory that is local to host 102 or is otherwise available to host 102 by conventional means. Preferably, hosts 102, 104, 106 are able to communicate with one another via a network 114. Network 114 may take any conventional form such as, for example, a TCP/IP network or a UDP/IP network. Except for the presence of USB remoting logic 108/109, hosts 102, 104, 106 may take the form of any conventional computing device, and hosts 102, 104, 106 need not be identical. For example, any or all of the three hosts may take the form of a desktop computer, a server computer, an embedded computer, or a portable computing device such as a laptop or handheld computer. Accordingly, each host would normally be equipped with at least one central processing unit for executing code and a memory for storing the code as well as related data and other information.

[013] Host 102 may be equipped with a USB host controller 116 so that it may be connected to a composite USB device 1 18 and/or a compound USB device 120. (Any number, type and combination of USB devices may be connected to host 102 in actual embodiments-even a single device; the configuration show in the drawing is for illustrative purposes only.) Composite USB device 118 and compound USB device 120 may be conventional. Each contains plural USB functions. For example, composite device 118 might contain USB functions 122, 124 and 126, and compound device might contain USB functions 128, 130 and 132 as shown. In actual embodiments, each of composite device 1 18 and compound device 120 might contain fewer or more USB functions than those shown. The USB functions contained in the devices may be of any conventional type. Examples of typical USB functions are keyboards, mice, audio devices, video devices, biometric devices and the like. In accordance with the USB standard, a composite USB device is one mat has a single device address but numerous interface descriptors. A compound USB device, on the other hand, has multiple device addresses accessible via an internal hub, which also has an address. [014] Fig. 2 illustrates computer hosts 102, 104, 106 in greater detail. USB remoting logic 108 within host 102 may contain virtual interposer logic 200 and send/receive logic 202. Moreover, virtual interposer logic 200 may contain device partitioning logic 204. Similarly, USB remoting logic 109 within hosts 104, 106 may contain virtual interposer logic 206, send/receive logic 208 and, in some embodiments, arbitration protocol logic 210. Preferably, each host is equipped to interface with network 114 by some means such as by a network interface card ("NIC") 212. Send/receive logics 202,208 are configured to communicate packets between one another via network 114. The packets may represent commands and data passing between a user-level application 214 at host 104 or 106 and a USB device connected to host 102. The packets may also represent notification and configuration commands and data passing between kernel space entities (such as kernel subsystems/IO manager 232 and/or upper USB device stack 216) within hosts 104, 106 and a USB device connected to host 102. (For more information on an example implementation of sending USB device information between hosts over a network, the reader is referred to U.S. patent application serial number 11/343,791, titled "Emulation of a Device Protocol," which application is hereby incorporated as if entirely set forth herein.) Virtual interposer logic 206 is configured to interface send/receive logic 208 with at least a partial device driver stack in host 104/106 such as upper USB device stack 216. Virtual interposer logic 200 is configured to interface send/receive logic 202 with at least a partial device driver stack in host 102 such as lower USB device stack 218. In some embodiments, virtual interposer logic 206 may also interface with a lower USB device stack 220, which drives a USB host controller 222. Also in some embodiments, virtual interposer logic 200 may also interface with an upper USB device stack 224, which interfaces with an application 226 via kernel subsystems/IO manager 228 and an application programmer's interface ("APF') 230. Upper USB device stack 216 would normally interface with a kernel subsystems/IO manager 232, which in turn can interface with application 214 via an API 234.

[015] The operating environment within hosts 102, 104, 106 need not be the same. For example, either host may use a Microsoft Windows operating system, a Unix or Linux operating system, or some other type of operating system. In the vocabulary of the Microsoft Windows Driver Foundation, an example of an object that might be present in upper USB device stack 216 would be a function driver object ("FDO"), as well as perhaps one or more USB filter drivers. An example of an object that might be present in lower USB device stack 218 would be a physical device object ("PDO"), as well as perhaps additional USB filter drivers. On other platforms, different terminology may be used and different objects might be present in the stacks. The effect of the configuration shown in Fig. 2 is that USB devices attached to host 102 can be made accessible, via network 114, to resources running on hosts 104, 106 such as kernel space entities and/or applications such as application 214.

[016] Preferred behavior for the system of Figs. 1 and 2 will now be described in relation to Figs. 3-5. In particular, Fig. 3 describes a method 300 for partitioning compound or composite USB devices in a remote USB environment, such as that of Figs. 1 and 2, according to a preferred embodiment of the invention. In step 302, state 400 may be set in host 102 to provide a mapping of local USB functions 122-132 to remote hosts 104, 106. The purpose of state 400 is to indicate to which remote host at least some of USB functions 122-132 should be presented, so the form and contents of state 400 may vary from one embodiment to the other. In some embodiments, state 400 can map some or all of functions 122-132 to hosts using entries that specifically identify USB functions that are actually present, such as by device addresses and interface descriptors. The hosts may be identified by any conventional means, such as by IP address. In other embodiments, state 400 may instead provide a more general mapping of functions to hosts by USB function type. For example, in such embodiments, state 400 may comprise directives to present all audio USB functions (a first predetermined class of functions identified by category) to host 104, and to present all biometric USB functions (a second predetermined class of functions identified by category) to host 106. Not every function or class of functions need be mapped to a host. In the state illustrated in Fig. 4, for example, video functions are not mapped to any host. The latter technique may be used to prevent certain USB functions that exist in devices 118, 120 from being made available to any remote host. Also, classes of USB functions in the mapping may include more than one type. In state 400, for example, an "other" class is provided such that any type of function that does not fall within the specificalty enumerated categories may be mapped, by default, to a particular host (host 104 in the example). State 400 can be stored at host 102 by any conventional means, such as in memory.

[017] In some embodiments, the order of steps 302 and 304 may be reversed, In step 304, a user plugs a multi-function USB device such as device 118 or device 120 into host 102. In a conventional host, this action would invoke plug and play functionality in the kernel subsystems of the local host to load an appropriate driver or drivers for handling the newly-discovered device. But in the system of the present invention, USB remoting logic 108 in host 102 will instead communicate with one or more of remoting logics 109 in host 104 or 106 to invoke plug and play functionality in the kernel subsystems of those hosts. The result will be that an appropriate driver or drivers will be loaded in host 104 or 106 instead of in host 102.

[018] More particularly, in step 306, device partitioning logic 204 becomes active to do this in a special way. Namely, device partitioning logic 204 partitions the set of USB functions that are present in the compound or composite device into two or more proper subsets of functions in accordance with state 400. In doing so, it creates at least one virtual USB device corresponding to at least one part of the partitioned set of USB functions. Any suitable data structures may be used for the purpose of representing the virtual device internally and for translating between the virtual device and the related physical device that actually contains the functions that are being represented in the virtual device.

[019] Fig. 5 illustrates one example of such a partitioning. In the example of Fig. 5, USB functions 122 and 126 from composite physical device 118 have been combined into a virtual USB device 500, while USB function 124 from composite physical device 118 has been separated out into another virtual USB device 502. Similarly, USB function 132 from compound physical device 120 has been separated out into a virtual USB device 504, while USB functions 128, 130 have been combined into a different virtual USB device 506. Virtual devices 500, 502 thus each correspond to different parts of a partition of the set of USB functions 122-126. Likewise, virtual devices 504, 506 each correspond to different parts of a partition of the set of USB functions 128-132.

[020] In the example shown, the USB functions contained in virtual devices 500, 502 are exhaustive of the set of USB functions 122-126, and the USB functions contained in virtual devices 504, 506 are exhaustive of the set of USB functions 128-132. But in alternative embodiments, the functions contained in the virtual devices need not be exhaustive of the set of functions contained in the underlying physical devices. (In the example of state 400 for instance, any video function present in either of devices 118 or 120 could be suppressed by not including it in any one of the virtual devices.)

[021] Assume for the sake of example that the device just plugged in was composite device 118. In step 308 then, host 102 can send a message to host 104 indicating that a new USB device 500 has been plugged in, and in step 312 can send a message to host 106 indicating that a new USB device 502 has been plugged in. If, on the other hand, the device just plugged in were compound device 120, then host 102 could send a message to host 104 in step 308 indicating that a new USB device 504 has been plugged in, and could send a message to host 106 in step 312 indicating that a new USB device 506 has been plugged in. Device partitioning logic 204 can accomplish this by determining, responsive to information stored in state 400, to which remote host each of the functions is to be presented. From that point forward, the conventional plug and play functionality in hosts 104, 106 may be invoked to load drivers that are appropriate to each of the newly-announced devices 500-506.

[022] The system of the invention is capable of ensuring that any one of virtual devices 500-506 that is made visible to one remote host is not made visible to another remote host. This may be accomplished in steps 310 and 314. Ifit is not desired for host 106 to be able to see devices 500, 504, then in steps 310 and 314, the announcement messages corresponding to those devices arc simply not sent to host 106. Similar message suppression may be implemented in steps 310, 314 with respect to devices 502, 506 vis-a-vis host 104.

[023] With respect to setting state 400 in step 302, a variety of techniques may be used. One technique that may be used is to store state 400, or data from which state 400 can be constructed, in a configuration file 1 10. Then state 400 may be set by reading configuration file 110 when the remote USB session is being initialized or thereafter.

[024] Another technique that may be used is to set state 400 using arbitration protocol logic 210, preferred behavior for which is illustrated by method 600 in Fig. 6. Specifically, in step 602, during the time when the remote USB session is being initialized or thereafter, hosts 104 and 106 (and any other remote hosts if system 100 includes more than two remote hosts) may send messages to one another and/or to host 102 via network 114 to determine which of the remote hosts will handle which of the USB functions that are present (or that might be present) on host 102. The arbitration may be performed in any suitable way. For example, a unique priority may be assigned to each of the hosts such that, if both hosts announce a desire or capability to handle biometric functions, the host with the higher priority will be designated to handle that function exclusively. Persons having ordinary skill in the art and having reference to this disclosure will recognize that various methods for performing the arbitration may be devised, and that such methods may be particular to the kinds of distributed applications being implemented. (For example, the prioritization scheme just mentioned might be appropriate in a distributed application in which users are to be authenticated biometrically using a single secure server 106, and once authenticated should be allowed to access audio and video resources on a second server 104.) Once the arbitration has been completed, results of the arbitration may then be communicated to host 102 for implementation. For example, in step 604, host 104 may send a message to host 102 to register itself as the host that will handle one set of USB functions; and in step 606, host 106 may send a message to host 102 to register itself as the host that will handle another set of USB functions. The result of the messages in step 604 and/or step 606 may be that state 400 is set accordingly.

[025] Yet another way to set state 400 is illustrated by method 700 in Fig. 7. In step 702, host 102 selects one remote host (such as either host 104 or 106) to be an offeree of a set of available USB functions such as functions 122- 132. In step 704, host 102 sends a message to the selected remote host offering the available USB functions for allocation. The remote host, in step 706, sends a responsive message to host 102 choosing some subset of those USB functions offered (The chosen subset may be empty, it may be the complete set offered, or it may be some non-null proper subset of the functions that were offered.) In step 708, host 102 sets or updates state 400 to allocate those functions chosen to the selected remote host In step 710, host 102 removes the allocated USB functions from the set of USB functions that are available for allocation to other remote hosts. In step 712, the process can cither repeat or terminate, depending on whether any USB functions remain for possible allocation to other remote hosts. If any remain, then host 102 can select another host and continue with step 702. The remote hosts can be selected according to any appropriate criteria, such as in accordance with some predetermined or arbitrated ordering of the remote hosts. The functionality described in method 700 may be implemented in device partitioning logic 204 and in protocol arbitration logics 210. [026] Still another way to set state 400 is illustrated by method 800 in Fig. 8. In step 802, host 102 presents a user interface 134 using any suitable display device 136. User interface 134 allows a user to choose which of the available USB functions 122- 132 should be mapped to which of the available remote hosts, such as hosts 104, 106. In step 804, host 102 sets or updates state 400, responsive to the user's choices indicated via user interface 134, to allocate the available USB functions accordingly. The functionality described in method 800 may be implemented in device partitioning logic 204. Other techniques for setting state 400 are also possible.

[027] In most embodiments, it is anticipated that virtual device 500 would be presented to host 104 as a composite device having two functions, while virtual device 506 would be presented to host 106 as a compound device having two functions. With suitable translation logic, however, other variations arc possible. For example, virtual device 500 could be presented as compound, or virtual device 506 could be presented as composite.

[028] It should be noted that the logic described above need not be implemented in discrete components as illustrated. For example, any or all of virtual intcrposer 200, device partitioning logic 204 and send/receive logic 202 may be implemented integrally or separately with equivalent effect. And any or all of virtual interposer 206, arbitration protocol logic 210 and send/receive logic 208 may be implemented integrally or separately with equivalent effect. In such embodiments, the activities of and connections between any discrete components that are described in the claims, written description and drawings hereof should instead be attributed to the integrally or separately formed and equivalent logic component. [029] Components of the logic described above may be implemented in hardware, software, firmware or any combination thereof. For example, any or all of the logic may take the form of instructions stored on a computer-readable storage medium which, when executed by a computer, cause the computer to perform the logic. Such a computer-readable storage medium may take any conventional form now known or yet to be developed including, for example, optical or magnetic disks, magnetic tapes, solid state static or dynamic random access memory, solid state read-only memory, flash memory or the like.

[030] In the appended claims, the words "comprising" and "comprises" are to be read in the open sense to mean "including the following elements but not excluding others."

[031] While the invention has been described in detail with reference to preferred embodiments thereof, the described embodiments have been presented by way of example and not by way of limitation. It will be understood by those skilled in the art and having reference to this specification that various changes may be made in the form and details of the described embodiments without deviating from the spirit and scope of the invention as defined by the appended claims.

Claims

What is claimed is: 1. A system, comprising: a first computer host having USB remoting logic and USB device partitioning logic, wherein: the USB remoting logic is configured to cause a USB device attached to the first computer host to be accessible, via a network, to resources running on a second or third computer host; and when a compound or composite USB device containing a set of plural USB functions is connected to the first computer host, the USB device partitioning logic is configured to present a first virtual USB device to the second computer host and a second virtual USB device to the third computer host, the first and second virtual USB devices each containing different parts of a partition of the set of USB functions.

2. The system of claim 1 , wherein: the first and second virtual USB devices are members of a plurality of virtual USB devices presented by the USB device partitioning logic to at least the second and third computer hosts, each member of the plurality containing different parts of the partition of the set of USB functions; and the functions contained in the plurality are collectively exhaustive of the set.

3. The system of claim 1, wherein: the first and second virtual USB devices are members of a plurality of virtual USB devices presented by the USB device partitioning logic to at least the second and third computer hosts, each member of the plurality containing different parts of the partition of the set of USB functions; and the functions contained in the plurality are not collectively exhaustive of the set.

4. The system of claim 1, wherein: the USB device partitioning logic is configured such that the first virtual USB device is not made visible to the third computer host and the second virtual USB device is not made visible to the second computer host.

5. The system of claim 1, further comprising: state in the first computer host indicating to which of the second and third computer hosts at least some of the plural USB functions should be presented.

6. The system of claim 5, further comprising: arbitration protocol logic in the second and third computer hosts configured to determine, by communication between at least the second and third computer hosts, to which of the second and third computer hosts at least some of the plural USB functions should be presented, and to set the state in the first computer host accordingly.

7. The system of claim 5, wherein: the state comprises directives to present all USB functions falling within in a first predetermined class to the second computer host and to present all USB functions falling within a second predetermined class to the third computer host.

8. The system of claim 5, wherein: the state corresponds to information read from a configuration file accessible by the first computer host.

9. The system of claim 5, wherein: the USB device partitioning logic is configured to offer members of the set of USB functions to at least the second computer host and to allocate certain of the members to the second computer host responsive to a choice communicated by the second computer host, and subsequently to offer non- chosen members to at least the third computer host.

10. The system of claim 5, wherein: the USB device partitioning logic is configured to cause the first computer host to present a user interface that allows a user to select which members of the set of USB functions arc to be made available to which of at least the first and second computer hosts, and to set the state responsive to user choices indicated via the user interface.

11. A method, comprising: attaching, to a first computer host, a compound or composite USB device containing a set of plural USB functions; and causing the first computer host to present a first virtual USB device to a second computer host and a second virtual USB device to a third computer host, the first and second virtual USB devices each containing different parts of a partition of the set of plural USB functions.

12. The method of claim 11, further comprising: causing the first virtual USB device not to be visible to the third computer host; and causing the second virtual USB device not to be visible to the second computer host.

13. The method of claim 11, further comprising: determining, responsive to state stored on the first computer host, to which of at least the second and third computer hosts at least some of the plural USB functions should be presented.

14. The method of claim 13, further comprising setting the state on the first computer host by: offering members of the set of USB functions to at least the second computer host and allocating certain of the members to the second computer host responsive to a choice communicated by the second computer host; and offering non-chosen members to at least the third computer host.

15. A computer-readable storage medium containing program code that, when executed by a first computer host, causes the first computer host to implement USB remoting logic and LTSB device partitioning logic such that: the USB remoting logic is configured to cause a USB device attached to the first computer host to be accessible, via a network, to resources running on a second or third computer host; and when a compound or composite USB device containing a set of plural USB functions is connected to the first computer host, the USB device partitioning logic is configured to present a first virtual USB device to me second computer host and a second virtual USB device to the third computer host, the first and second virtual USB devices each containing different parts of a partition of the set of USB functions.