English:
[0001] 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.
[0002] 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.
[0003] 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."
[0006] 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.
[0007] 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.
[0008] 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.
[0009] Fig. 6 is a flow diagram illustrating a method for setting the state of Fig. 4 according to one preferred embodiment of the invention.
[0010] Fig. 7 is a flow diagram illustrating a method for setting the state of Fig. 4 according to another preferred embodiment of the invention.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.)
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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."
[0031] 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.

中文:
[0001]本发明一般地涉及用于促使被附着于第一计算机主机的通用串行总线(“USB”)外围设备可访问在远离第一个的第二计算机主机上运行的资源的技术。
[0002]存在使得本地计算机处的用户能够通过计算机网络访问并共享远程计算机(例如中央服务器)的桌面的协议。一个此类协议是由微软公司提供的远程桌面协议(“RDP”),微软公司通过网络连接来提供远程显示和输入能力。能够在本上下文中使用的另一协议是来自Hewlett Packard公司的远程图形软件(“RGS”)协议。RGS被设计为利用计算机和远程计算机的图形资源来在本地计算机处递送交互式远程访问。通过网络将远程计算机的桌面图形数据传送至本地计算机,其在本机计算机处的窗口中本地地显示桌面图形数据。RGS捕捉本地计算机处的用户键盘和鼠标输入,并将该键盘和鼠标输入发送至远程计算机以便由远程计算机的操作系统且由在远程计算机上运行的应用程序来处理。RGS还允许将诸如存储设备的某些外围设备的数据从本地计算机传送至远程计算机。
[0003]用于RDP、RGS或类似系统的现代附件是促使在物理上附着于本地计算机主机的USB设备可访问在远程计算机主机上运行的资源的能力。后一布置在下文中将称为“远程USB环境”。
[0006]图3是根据本发明的优选实施例的举例说明用于将远程USB环境中的混合或复合USB设备划分的方法的流程图。
[0007]图4是举例说明示例性状态的表格,根据本发明的优选实施例,所述示例性状态能够指示混合或复合USB设备的功能应被呈现给多个主机中的哪些。
[0008]图5是根据本发明的优选实施例的举例说明包含在图1的混合和复合设备中的USB功能的示例性划分的方框图。
[0009]图6是根据本发明的一个优选实施例的举例说明用于设置图4的状态的方法的流程图。
[0010]图7是根据本发明的另一优选实施例的举例说明用于设置图4的状态的方法的流程图。
[0011]图8是根据本发明的另一优选实施例的举例说明用于设置图4的状态的方法的流程图。
[0012]图1举例说明根据本发明的优选实施例的用于将远程USB环境中的混合或复合USB设备划分的系统100。描绘了三个计算机主机102、104、106。在其它实施例中,可以使用更多计算机主机。计算机主机102装配有USB远程逻辑100,并且计算机主机104、106装配有USB远程逻辑109。下面将相对于图2更详细地描述USB远程逻辑108、109。在某些实施例中,主机102可以访问配置文件110,诸如在处于主机102本地或可通过常规手段以别的方式可用于主机102的存储设备或存储器上。优选地,主机102、104、106能够经由网络114相互通信。网络114可以采取任何常规形式,诸如,例如TCP/IP网络或UDP/IP网络。除USB远程逻辑108/109的存在之外,主机102、104、106可以采取任何常规计算设备的形式,并且主机102、104、106不需要是相同的。例如,三个主机中的任何一个或全部可以采取台式计算机、服务器计算机、嵌入式计算机或诸如膝上型或手持式计算机的便携式计算设备的形式。因此,每个主机正常地将装配有用于执行代码的至少一个中央处理单元和用于存储代码以及相关数据及其它信息的存储器。
[0013]主机102可以装配有USB主机控制器116,以便可以将其连接至复合USB设备118和/或混合USB设备120。(在实际实施例中,可以将任何数目、类型和混合的USB设备连接至主机102—甚至是单个设备;图中所示的配置仅仅是出于说明性目的。) 复合USB设备118和混合USB设备120可以是常规的。每个包含多个USB功能。例如,复合设备118可以包含USB功能122、124和126,并且复合设备可以包含如所示的USB功能128、130和132。在实际实施例中,复合设备118和混合设备120中的每一个可以包含比所示的那些更少或更多的USB功能。包含在设备中的USB功能可以是任何常规类型的。典型USB功能的示例是键盘、鼠标、音频设备、视频设备、生物计量设备等。依照USB标准,复合USB设备是具有单个设备地址但许多接口描述符的一个。另一方面,混合USB设备具有可经由也具有地址的内部集线器访问的多个设备地址。
[0014]图2更详细地举例说明计算机主机102、104、106。主机102内的USB远程逻辑108可以包含虚拟内插器逻辑200和发送/接收逻辑202。此外,虚拟内插器逻辑200可以包含设备划分逻辑204。同样地,主机104、106内的USB远程逻辑109可以包含虚拟内插器逻辑206、发送/接收逻辑208和(在某些实施例中)仲裁协议逻辑210。优选地,每个主机被装配为用某些手段(诸如用网络接口卡(“NIC”)212)与网络114对接。发送/接收逻辑202、208被配置为经由网络114在相互之间传送分组。该分组可以表示在主机104或106处的用户层级应用程序214与被连接到主机102的USB设备之间传递的命令和数据。该分组还可以表示在主机104、106内的内核空间实体(诸如内核子系统/IO管理器232和/或上USB设备堆栈216)与被连接到主机102的USB设备之间传递的通知和配置命令和数据。(为了获得关于通过网络在主机之间发送USB设备信息的示例性实施方式的更多信息,读者参考题为“Emulation of a Device Protocol”的美国专利申请序号11/343,791,该申请被结合到本文中,如同其在这里完全阐述一样。) 虚拟内插器逻辑206被配置为使发送/接收逻辑208与主机104/106中的至少部分设备驱动程序堆栈(诸如上USB设备堆栈216)对接。虚拟内插器逻辑200被配置为使发送/接收逻辑202与主机102中的至少部分设备驱动程序堆栈(诸如下USB设备堆栈218)对接。在某些实施例中,虚拟内插器逻辑206还可以与驱动USB主机控制器222的下USB设备堆栈220对接。同样在某些实施例中,虚拟内插器逻辑200还可以与上USB设备堆栈224对接,其经由内核子系统/IO管理器228和应用程序设计员的界面(“API”)230与应用程序226对接。上USB设备堆栈216正常地将与内核子系统/IO管理器232对接,其又能够经由API 234与应用程序214对接。
[0015]主机102、104、106内的操作环境不需要是相同的。例如,任一主机可以使用Microsoft Windows操作系统、Unix或Linux操作系统或某个其它类型的操作系统。在Microsoft Windows Driver Foundation的词汇中,可以存在于上USB设备堆栈216中的对象的示例将是功能驱动程序对象(“FDO”)以及可能的一个或多个USB过滤器驱动程序。可以存在于下USB设备堆栈218中的对象的示例将是物理设备对象(“PDO”)以及可能的附加USB过滤器驱动程序。在其它平台上,可以使用不同的术语,并且在堆栈中可以存在不同的对象。图2所示的配置的效果是可以使得被附着于主机102的USB设备可经由网络114访问在主机104、106上运行的资源,诸如内核空间实体和/或诸如应用程序214的应用程序。
[0016]现在将相对于图3~5来描述用于图1和2的系统的优选行为。特别地,图3描述根据本发明的优选实施例的用于将诸如图1和2的远程USB环境中的混合或复合USB设备划分的方法300。在步骤302中,可以在主机102中设置状态400以提供本地USB功能122~132到远程主机104、106的映射。状态400的目的是指示应将USB功能122~132中的至少某些呈现给哪个远程主机,因此,状态400的形式和内容对于不同的实施例可以不同。在某些实施例中,状态400可以使用诸如用设备地址和接口描述符来具体地识别实际上存在的USB功能的条目来将功能122~132的某些或所有映射到主机。可以用任何常规手段来识别主机,诸如用IP地址。在其它实施例中,状态400可以替代地用USB功能类型来提供功能到主机的更一般映射。例如,在此类实施例中,状态400可以包括向主机104呈现所有音频USB功能(按种类识别的第一预定功能类别)并向主机106呈现所有生物计量USB功能(按种类识别的第二预定功能类别)的指令。不需要将每个功能或功能类别映射到主机。在图4所示的状态下,例如,不将视频功能映射到任何主机。后一种技术可以用来防止使得存在于设备118、120中的某些USB功能可用于任何远程主机。并且,映射中的USB功能的类别可以包括不止一个类型。在状态400中,例如,提供“其它”类别,使得可以作为默认将不落在具体地枚举的种类内的任何类型的功能映射到特定主机(在本示例中主机104)。可以用任何常规手段将状态400存储在主机102处,诸如在存储器中。
[0017]在某些实施例中,可以使步骤302、304的顺序相反。在步骤304中,用户将诸如设备118或设备120的多功能USB设备插入主机102。在常规主机中,此动作将调用本地主机的内核子系统中的即插即用功能以加载用于处理新发现的设备的适当的一个或多个驱动程序。但是在本发明的系统中,主机102中的USB远程逻辑108将替代地与主机104或106中的远程逻辑109中的一个或多个通信以调用那些主机的内核子系统中的即插即用功能。结果将是适当的一个或多个驱动程序将被加载在主机104或106中而不是主机102中。
[0018]更特别地,在步骤306中,设备划分逻辑204变成活动的以便以特殊方式完成这一点。即,设备划分逻辑204依照状态400将存在于混合或复合设备中的该组USB功能划分成两个或更多适当的功能子集。在这样做时,其产生对应于划分的该组USB功能的至少一部分的至少一个虚拟USB设备。可以将任何适当的数据结构用于在内部表示虚拟设备并用于虚拟设备与实际上包含正在虚拟设备中表示的功能的相关物理设备之间的转换的目的。
[0019]图5举例说明此类划分的一个示例。在图5的示例中,已将来自复合物理设备118的USB功能122和126混合成虚拟USB设备500,同时已将来自复合物理设备118的USB功能124分离到另一虚拟USB设备502中。同样地,已将来自混合物理设备120的USB功能132分离到虚拟USB设备504中,同时已将USB功能128、130混合成不同的虚拟USB设备506。因此,虚拟设备500、502每个对应于该组USB功能122~126的划分的不同部分。同样地,虚拟设备504、506每个对应于该组USB功能128~132的划分的不同部分。
[0020]在所示的示例中,包含在虚拟设备500、502中的USB功能是该组USB功能122~126的穷举,并且包含在虚拟设备504、506中的USB功能的该组USB功能128~132的穷举。但是在替换实施例中,包含在虚拟设备中的功能不需要是包含在底层物理设备中的该组功能的穷举。(在例如状态400的示例中,可以通过将其包含在虚拟设备中的任何一个中来抑制存在于设备118或129中的任何视频功能)。
[0022]本发明的系统能够保证被使得对于一个远程主机而言可见的虚拟设备500~506中的任何一个未被使得对于另一远程主机而言可见。这可以在步骤310和314中实现。如果不期望主机106能够看到设备500、504,则在步骤310和314中,简单地不向主机106发送对应于那些设备的公告消息。相对于与主机104相对的设备502、506,可以在步骤310、314中实现类似的消息抑制。
[0023]相对于在步骤302中设置状态400,可以使用多种技术。可以使用的一种技术是将状态400或能够用来构造状态400的数据存储在配置文件110中。然后,可以通过在正在对远程USB会话进行初始化时或其后读取配置文件110来设置状态400。
[0024]可以使用的另一技术是使用仲裁协议逻辑210来设置状态400,用图6中的方法600来举例说明其优选行为。具体地,在步骤602中,在正在对远程USB会话进行初始化的时间或其后期间,主机104和106(和任何其他远程主机,如果系统100包括不止两个远程主机)可以经由网络114相互和/或向主机102发送消息以确定哪些远程主机将处理存在(或可能存在)于主机102上的哪些USB功能。可以以任何适当方式来执行仲裁。例如,可以向每个主机分配唯一优先权,使得如果两个主机公告了处理生物计量功能的期望或能力,则专有地将具有较高优先级的主机指定为处理该功能。已参考本公开的本领域的技术人员将认识到可以设计用于执行冲裁的各种方法,并且此类方法为正在实现的分布式应用种类所特有。(例如,刚刚提到的按优先级排列方案在其中将使用单个安全服务器106以生物计量方式来认证用户的分布式应用中可能是适当的,并且一旦经过认证,应允许其访问第二服务器104上的音频和视频资源。) 一旦仲裁已经完成,则可以将仲裁的结果传送至主机102以便实现。例如,在步骤604中,主机104可以向主机102发送消息以将其本身注册为将处理一组USB功能的主机;并且在步骤606中,主机106可以向主机102发送消息以将其本身注册为将处理另一组USB功能的主机。步骤604和/或步骤606中的消息的结果可以是相应地设置状态400。
[0025]用图7中的方法700来举例说明设置状态400的另一方式。在步骤702中,主机102将一个远程主机(诸如主机104或106)选择为诸如功能122~132的一组可用USB功能的受要约者(offeree)。在步骤704中,主机102向所选远程主机发送提供用于分配的可用USB功能的消息。在步骤706中,远程主机向主机102发送响应消息,选择所提供的那些USB功能的某个子集(所选子集可以是空的,其可以是提供的完整集合,或者其可以是所提供的功能的某些非空合适子集。) 在步骤708中,主机102设置或更新状态400以将所选的那些功能分配给所选远程主机。在步骤710中,主机102从可用于分配给其它远程主机的该组USB功能去除所分配的USB功能。在步骤712中,根据是否仍有用于到其它远程主机的可能分配的任何USB功能,该过程可以重复或终止。如果存有任何一个,则主机102可以选择另一主机并继续步骤702。可以根据任何适当标准来选择远程主机,诸如依照远程主机的某个预定或仲裁排序。在设备划分逻辑204中和协议仲裁逻辑210中可以实现方法700中所述的功能。
[0026]用图8中的方法800来举例说明设置状态400的另一方式。在步骤802中,主机102使用任何适当的显示设备136来呈现用户界面134。用户界面134允许用户选择应将可用USB功能122~132中的哪些映射到可用远程主机(诸如主机104、106)中的哪些。在步骤804中,主机102响应于经由用户界面134指示的用户的选择来设置或更新状态400以相应地分配可用USB功能。在设备划分逻辑204中可以实现方法800中所述的功能。用于设置状态400的其它技术也是可能的。
[0027]在大多数实施例中,可以预期虚拟设备500将被作为具有两个功能的复合设备呈现给主机104,而虚拟设备506将被作为具有两个功能的混合设备呈现给主机106。然而,用适当的转换逻辑,可以有其它变化。例如,可以将虚拟设备500呈现为混合体,或者可以将虚拟设备506呈现为复合体。
[0028]应注意的是不需要在如所示的独立组件中实现上述逻辑。例如,可以以等效的效果整体地或单独地实现虚拟内插器200、设备划分逻辑204和发送/接收逻辑202中的任何或全部。并且,可以用等效的效果整体地或单独地实现虚拟内插器206、仲裁协议逻辑210和发送/接收逻辑208中的任何或全部。在此类实施例中,在权利要求、所写的说明及其附图中描述的任何独立组件的活动及其之间的连接应替代地归于整体地或单独地形成且等效的逻辑组件。
[0029]可以在硬件、软件、固件和/或其混合中实现上述逻辑的组件。例如,任何或所有逻辑可以采取存储在计算机可读存储介质上的指令的形式,其在被计算机执行时促使计算机执行该逻辑。此类计算机可读存储介质可以采取现在已知或将开发的任何常规形式,包括例如光盘或磁盘、磁带、固态静态或动态随机存取存储器、固态只读存储器、闪速存储器等。
[0030]在所附权利要求中,将以开放的意义来理解词语“包括”和“包含”以意指“包括以下元素但不排除其它的”。
[0031]虽然已经参考本发明的优选实施例对其进行了详细描述,但所述实施例是以示例的方式且不是以限制的方式提出的。已参考本说明书的本领域的技术人员应理解的是在不脱离如所附权利要求限定的本发明的精神和范围的情况下可以对所述实施例的形式和细节进行各种修改。