System and method for providing session-level access management of a redirected device
Summary by NHIP
Session-based device access control
The method manages access to remote devices by traversing a device stack to locate a virtual bus driver. It attaches a restriction object above the stack and grants access only when the request originates from the client's matching session without kernel hooking.
Claim Score by NHIP
Abstract
Managing access restriction to a device is provided. The operations may include determining that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server; attaching a device access restriction object on top of the device stack; receiving, at the device access restriction object, an access request to the device; and determining, at the device access restriction object, whether the access request is allowed access to the device.
Term
6.9 yearsleft in the term
Expires 28 August 2033, including 320 days of term adjustment.
- Priority
- Filed
- Granted
- Today
- Expires
18 claims: 3 independent, 15 dependent
- 1Broadest claimClaim Score 57, average(NHIP)A method for managing access restriction to a device, the method comprising:determining, by traversing a device stack downwards to identify a device object corresponding to a virtual bus driver at the bottom of the device stack, at a server, that the device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server, the device stack including a plurality of device objects each associated with a device driver;attaching a device access restriction object on top of the device stack;receiving, at the device access restriction object, an access request to the device;and determining, at the device access restriction object, whether the access request is allowed access to the device, including: determining whether a session from which the access request is received is the same as a session of the client;and determining that the access request is allowed if the session from which the access request is received is the same as the session of the client.
- 7A non-transitory machine-readable storage medium encoded with instructions executable by one or more processors to perform one or more operations, the one or more operations comprising:determining, by traversing a device stack downwards to identify a device object corresponding to a virtual bus driver at the bottom of the device stack, at a server, that the device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server;attaching a device access restriction object on top of the device stack;receiving, at the device access restriction object, an access request to the device;and determining, at the device access restriction object, whether the access request is allowed access to the device, including: determining whether a session from which the access request is received is the same as a session of the client;and determining that the access request is allowed if the session from which the access request is received is the same as the session of the client.
- 13A server comprising:a processor;a memory communicatively coupled to the processor;a device access restriction driver including instructions in the memory, the instructions executable by the processor, the instructions, when executed, configure the device access restriction driver to: determine, by traversing a device stack downwards to identify a device object corresponding to a virtual bus driver at the bottom of the device stack, that the device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server, the device stack including a plurality of device objects each associated with a device driver;attach a device access restriction object on top of the device stack;the device access restriction object including instructions in the memory, the instructions executable by the processor, the instructions, when executed, configure the device access restriction object to: receive an access request to the device;and determine whether the access request is allowed access to the device, including: determining whether a session from which the access request is received is the same as a session of the client;and determining that the access request is allowed if the session from which the access request is received is the same as the session of the client.
Independent claims3
205 paragraphs in 6 sections, as filed
CROSS-REFERENCES TO RELATED APPLICATIONS
0001The present application claims the benefit of priority from U.S. Provisional Patent Application Ser. No. 61/643,807, entitled “SYSTEM AND METHOD FOR PROVIDING SESSION-LEVEL ACCESS MANAGEMENT OF A REDIRECTED DEVICE,” filed on May 7, 2012, which is hereby incorporated by reference in its entirety for all purposes.
FIELD
0002The disclosure relates in general to remote computing, and more particularly to managing access to a redirected device, and more particularly to providing session-level access management of a redirected device.
BACKGROUND
0003One approach to the design and implementation of computer networks, particularly with regard to the development of client/server applications, includes designing client applications and client terminals so that the majority of the heavily used resources are at a remote computing machine, such as a centralized server, connected via a network. The client terminals generally have minimal memory, disk storage, and processor power, but are designed under the premise that most users connected to a powerful server do not need the additional processing power. With these client terminals, the total cost of ownership is minimized, because of the reduced resources and because the clients can be centrally administered and updated from the server. As such, these client terminals are suited for a network which can handle a significant number of terminals. If the client terminals have devices attached to them, then when the client terminals are connected to the server, not only the client terminals but also the client terminals' devices can become available to the server.
SUMMARY
0004In one aspect, a method for managing access restriction to a device may comprise determining that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server; attaching a device access restriction object on top of the device stack; receiving, at the device access restriction object, an access request to the device; and determining, at the device access restriction object, whether the access request is allowed access to the device.
0005In one aspect, a machine-readable storage medium may be encoded with instructions executable by one or more processors to perform one or more operations. The one or more operations may comprise: determining, at a server, that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server; attaching a device access restriction object on top of the device stack; receiving, at the device access restriction object, an access request to the device; and determining, at the device access restriction object, whether the access request is allowed access to the device.
0006In one aspect, an apparatus may comprise one or more modules configured to perform one or more operations comprising: determining, at a server, that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server; attaching a device access restriction object on top of the device stack; receiving, at the device access restriction object, an access request to the device; and determining, at the device access restriction object, whether the access request is allowed access to the device.
0007In one aspect, an apparatus may comprise: means for determining, at a server, that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server; means for attaching a device access restriction object on top of the device stack; means for receiving, at the device access restriction object, an access request to the device; and means for determining, at the device access restriction object, whether the access request is allowed access to the device.
0008It is understood that various configurations of the subject technology will become readily apparent to those skilled in the art from the disclosure, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the summary, drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
BRIEF DESCRIPTION OF THE DRAWINGS
0009<figref idref="DRAWINGS">FIG. 1</figref> is a conceptual block diagram of an example of a computer network.
0010<figref idref="DRAWINGS">FIG. 2A</figref> is a conceptual block diagram illustrating an example of a local device virtualization system.
0011<figref idref="DRAWINGS">FIG. 2B</figref> is a conceptual block diagram of an example of a computer network providing local device virtualization.
0012<figref idref="DRAWINGS">FIG. 3A</figref> is a conceptual block diagram of an example of a system for managing access to a device in a local device virtualization system.
0013<figref idref="DRAWINGS">FIG. 3B</figref> is a conceptual block diagram of an example of a computer network providing managed access to virtualized local devices.
0014<figref idref="DRAWINGS">FIG. 4A</figref> is a conceptual block diagram of an example of a data structure for storing an object manager namespace.
0015<figref idref="DRAWINGS">FIG. 4B</figref> is a conceptual block diagram of an example of a data structure for storing device configuration data of a virtual bus driver.
0016<figref idref="DRAWINGS">FIG. 4C</figref> is a conceptual block diagram of an example of a printer architecture which may be implemented in a local device virtualization system.
0017<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating an exemplary method for managing access to a device.
0018<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart illustrating an exemplary method for managing access to a device for which requests are sent from a single session.
0019<figref idref="DRAWINGS">FIG. 7</figref> is a conceptual block diagram illustrating an example system in accordance with various aspects of the subject technology.
0020<figref idref="DRAWINGS">FIG. 8A</figref> is a block diagram representing an example of a method for providing session-level access management of a redirected device, in accordance with one aspect of the disclosure.
0021<figref idref="DRAWINGS">FIG. 8B</figref> is a block diagram representing an example of a machine-readable storage medium encoded with instructions executable by a processor to perform a method for providing session-level access management of a redirected device, in accordance with one aspect of the disclosure.
0022<figref idref="DRAWINGS">FIG. 8C</figref> is a block diagram representing an example of an apparatus for providing session-level access management of a redirected device, in accordance with one aspect of the disclosure.
DETAILED DESCRIPTION
0023The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology may be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. However, it will be apparent to those skilled in the art that the subject technology may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology. Like components are labeled with identical element numbers for ease of understanding.
0024Frequently, devices connected to client terminals (also referred to as “clients” or “client-side devices”) are virtualized on a server to provide access to the devices from user sessions on the server. The virtualized devices (or redirected devices), however, are accessible from a large number of user sessions and/or client terminals. For example, in an office environment, multiple user sessions and/or clients may be connected to a server on which the device is virtualized (or redirected), and all of the multiple user sessions and/or clients connected to the server may have access to the device. A user's virtualized device connected to the user's client terminal may thus be subject to unwanted or unauthorized access or use by other users' sessions, and/or from other users' clients.
0025A module may be provided which may hook into the kernel of the server's operating system to block any unwanted or unauthorized accesses. However, in certain operating systems, such hooks are difficult to make. For example, certain versions of the Windows operating system implement Kernel Patch Protection (KPP), which protects the Windows Kernel from hooks and patches.
0026A need therefore exists for systems and methods that allow access to virtualized devices to be restricted, such that secure and private access to such devices can be provided from selected user sessions while access from other user sessions can be blocked.
0027<figref idref="DRAWINGS">FIG. 1</figref> illustrates a simplified diagram of a system <b>100</b> in accordance with an aspect of the present disclosure. The system <b>100</b> may include one or more client terminals <b>102</b><i>a</i>, <b>102</b><i>b</i>, <b>102</b><i>c </i>(referenced generally herein as client(s) <b>102</b>) in communication with a server <b>104</b> via a network <b>106</b>. In one aspect, the server <b>104</b> is configured to support a remote session (e.g., a remote desktop session) wherein a user at a client <b>102</b> can remotely access applications and data at the server <b>104</b> from the client <b>102</b>. Such a connection may be established using any of several well-known techniques such as the Remote Desktop Protocol (RDP) and the Citrix® Independent Computing Architecture (ICA).
0028In one aspect, the client terminal <b>102</b> may represent a computer, a mobile phone (e.g., smart phone), a laptop computer, a thin client terminal, a personal digital assistant (PDA), a portable computing terminal, or a suitable terminal or device with a processor. In one aspect, a server <b>104</b> may represent a computer, a laptop computer, a computing terminal, a virtual machine (e.g., VMware® Virtual Machine), a desktop session (e.g., Microsoft Terminal Server), a published application (e.g., Microsoft Terminal Server) or a suitable terminal with a processor.
0029In one aspect, the client <b>102</b> may initiate a remote session with the server <b>104</b> by sending a request for remote access and credentials (e.g., login name and password) to the server <b>104</b>. If the server <b>104</b> accepts the credentials from the client <b>102</b>, then the server <b>104</b> may establish a remote session, which allows a user at the client <b>102</b> to access applications and data at the server <b>104</b>. During the remote session, the server <b>104</b> sends display data to the client <b>102</b> over the network <b>106</b>, which may include display data of a desktop and/or one or more applications running on the server <b>104</b>. The desktop may include, for example, icons corresponding to different applications that can be launched on the server <b>104</b>. The display data allows the client <b>102</b> to locally display the desktop and/or applications running on the server <b>104</b>.
0030During the remote session, the client <b>102</b> may send user commands (e.g., inputted via a mouse or keyboard at the client <b>102</b>) to the server <b>104</b> over the network <b>106</b>. The server <b>104</b> may process the user commands from the client <b>102</b> similar to user commands received from an input device that is local to the server <b>104</b>. For example, if the user commands include mouse movements, then the server <b>104</b> may move a pointer on the desktop running on the server <b>104</b> accordingly. When the display data of the desktop and/or application changes in response to the user commands, the server <b>104</b> sends the updated display data to the client <b>102</b>. The client <b>102</b> locally displays the updated display data so that the user at the client <b>102</b> can view changes at the server <b>104</b> in response to the user commands. Together, these aspects allow the user at the client <b>102</b> to locally view and input commands to the desktop and/or application that is running remotely on the server <b>104</b>. From the perspective of the client side, the desktop running on the server <b>104</b> may represent a virtual desktop environment.
0031<figref idref="DRAWINGS">FIG. 2A</figref> is a block diagram of a local device virtualization system <b>200</b> according to an aspect of the disclosure. The system <b>200</b> may include the client <b>102</b> in communication with the server <b>104</b> over the network <b>106</b> (illustrated in <figref idref="DRAWINGS">FIG. 1</figref>). The client <b>102</b> may include a proxy <b>210</b>, a stub driver <b>220</b>, and a bus driver <b>230</b>. The client <b>102</b> can be connected to a device <b>240</b>, as shown in <figref idref="DRAWINGS">FIG. 2A</figref>. The server <b>104</b> may include an agent <b>250</b>, and a virtual bus driver <b>260</b>.
0032According to the illustrated configuration, while the device <b>240</b> is not locally or physically connected to the server <b>104</b> and is remote to the server <b>104</b>, the device <b>240</b> appears to the server <b>104</b> as if it is locally connected to the server <b>104</b>, as discussed further below. Thus, the device <b>240</b> appears to the server <b>104</b> as a virtual device <b>290</b>.
0033By way of illustration and not limitation, the device <b>240</b> may be a machine-readable storage medium (e.g., flash storage device), a printer, a scanner, a camera, a facsimile machine, a phone, an audio device (e.g., a headset), a video device (e.g., a camera), a peripheral device, or other suitable device that can be connected to the client <b>102</b>. The device <b>240</b> may be an external device (i.e., external to the client <b>102</b>) or an internal device (i.e., internal to the client <b>102</b>).
0034In one aspect of the disclosure, the device <b>240</b> is a Universal Serial Bus (USB) device that can be locally connected to the client <b>102</b> using a wired USB or wireless USB connection and communicates with the client <b>102</b> according to a USB communications protocol. In another aspect, the device <b>240</b> may be a device other than a USB device.
0035As used herein, a “local” device of a system, or a device “locally” connected to a system, may be a device directly connected to the system using one or more wires or connectors (e.g., physically connected to the system), or a device directly connected to the system using a wireless link (e.g., Bluetooth). For example, device <b>240</b> is a local device of client <b>102</b>. Furthermore, in one aspect of the disclosure, a local device of a system or a device locally connected to a system may include a device within the system (e.g., an internal device of client <b>102</b>).
0036A “remote” device, or a device “remote” to a system, may be a device that is not directly connected to the system. For example, the server <b>104</b> is remote to both client <b>102</b> and device <b>240</b> because server <b>104</b> is not directly connected to client <b>102</b> or device <b>240</b> but connected indirectly through network <b>106</b> (illustrated in <figref idref="DRAWINGS">FIG. 1</figref>), which can include, for example, another server, or the Internet.
0037The bus driver <b>230</b> can be configured to allow the operating system and programs of the client <b>102</b> to interact with the device <b>240</b>. In one aspect, when the device <b>240</b> is connected to the client <b>102</b> (e.g., plugged into a port of the client <b>102</b>), the bus driver <b>230</b> may detect the presence of the device <b>240</b> and read information regarding the device <b>240</b> (“device information”) from the device <b>240</b>. The device information may include features, characteristics and other information specific to the device <b>240</b>. For an example of a USB device, the device information may comprise a device descriptor (e.g., product ID, vendor ID and/or other information), a configuration descriptor, an interface descriptor, an endpoint descriptor and/or a string descriptor. The bus driver <b>230</b> may communicate with the device <b>240</b> through a computer bus or other wired or wireless communications interface.
0038In one aspect, a program (e.g., application) running locally on the client <b>102</b> may access the device <b>240</b>. For example, the device <b>240</b> may be accessed locally when the client <b>102</b> is not connected to the server <b>104</b>. In this aspect, the operating system (e.g., Microsoft Windows®) of the client <b>102</b> may use the device information to find and load an appropriate device driver (not shown) for the device <b>240</b>. The device driver may provide the program with a high-level interface to the device <b>240</b>.
0039In one aspect, the device <b>240</b> may be accessed from the server <b>104</b> as if the device were connected locally to the server <b>240</b>. The device <b>240</b> may be accessed from the server <b>104</b> when the client <b>102</b> is connected to the server <b>104</b> through a user session running on the server <b>104</b>. For example, the device <b>240</b> may be accessible from the desktop running on the server <b>104</b> (i.e., virtual desktop environment). In this aspect, the bus driver <b>230</b> may be configured to load the stub driver <b>220</b> as the default driver for the device <b>240</b>. The stub driver <b>220</b> may be configured to report the presence of the device <b>240</b> to the proxy <b>210</b> and to provide the device information (e.g., device descriptor) to the proxy <b>210</b>.
0040The proxy <b>210</b> may be configured to report the presence of the device <b>240</b>, along with the device information, to the agent <b>250</b> of the server <b>104</b> over the network <b>106</b> (illustrated in <figref idref="DRAWINGS">FIG. 1</figref>). Thus, the stub driver <b>220</b> redirects the device <b>240</b> to the server <b>104</b> via the proxy <b>210</b>.
0041The agent <b>250</b> may be configured to receive the report from the proxy <b>210</b> that the device <b>240</b> is connected to the client <b>102</b> and the device information. The agent <b>250</b> may further be configured to associate with the report from the proxy <b>210</b> one or more identifiers for the client <b>102</b> and/or for a user session through which the client <b>102</b> is connected to the server <b>104</b>, such as a session number or a session locally unique identifier (LUID). The agent <b>250</b> can provide notification of the device <b>240</b>, along with the device information, to the virtual bus driver <b>260</b>. The virtual bus driver <b>260</b> (which may be a TCX USB bus driver, or any other bus driver) may be configured to create and store in memory a record corresponding to the device <b>240</b>, the record including at least part of the device information and session identifiers received from agent <b>250</b>. The virtual bus driver <b>260</b> may be configured to report to the operating system <b>170</b> of the server <b>104</b> that the device <b>240</b> is connected and to provide the device information to the operating system. This allows the operating system of the server <b>104</b> to recognize the presence of the device <b>240</b> even though the device <b>240</b> is connected to the client <b>102</b>.
0042In one aspect, a kernel module (or a kernel) <b>171</b> may be a component of the operating system <b>170</b>, and the virtual bus driver <b>260</b> may be configured to report to the kernel module of the operating system. A kernel module may be a bridge between software applications and data processing performed at hardware devices (e.g., a processor, memory or other physical devices). In one example, a kernel module manages a computer's resources (such as the communication between hardware and software components).
0043The operating system of the server <b>104</b> may use the device information to find and load one or more appropriate device drivers for the device <b>240</b> at the server <b>104</b>. Each driver may have an associated device object (object(s) <b>281</b><i>a</i>, <b>281</b><i>b</i>, . . . , <b>281</b><i>n</i>, referred to generally as device object(s) <b>281</b>), as illustratively shown in <figref idref="DRAWINGS">FIG. 2A</figref>. A device object <b>281</b> is a software implementation of a real device <b>240</b> or a virtualized (or conceptual) device <b>290</b>. Different device objects <b>281</b> layer over each other to provide the complete functionality. The different device objects <b>281</b> are associated with different device drivers (driver(s) <b>282</b><i>a</i>, <b>282</b><i>b</i>, . . . , <b>282</b><i>n</i>, referred to generally as device driver(s) <b>282</b>). In an example, a device <b>240</b> such as a USB flash drive may have associated device objects including objects corresponding to a USB driver, a storage driver, a volume manager driver, and a file system driver for the device. The device objects <b>281</b> corresponding to a same device <b>240</b> form a layered device stack <b>280</b> for the device <b>240</b>. For example, for a USB device, a USB bus driver will create a device object <b>281</b><i>a </i>stating that a new device has been plugged in. Next, a plug-and-play (PNP) component of the operating system kernel (e.g., Windows kernel) will search for and load the best driver for the device <b>240</b>, which will create another device object <b>281</b><i>b </i>that is layered over the previous device object <b>281</b><i>a</i>. The layering of device objects <b>281</b> will create the device stack <b>280</b>.
0044The device objects <b>281</b> may be stored in a memory of the server <b>104</b> associated with the virtual bus driver <b>260</b>. In particular, the device objects <b>281</b> and resulting device stack <b>280</b> may be stored in random-access memory of the server <b>104</b>. Different devices <b>240</b>/<b>290</b> can have device stacks having different device objects and different numbers of device objects. The device stack may be ordered, such that lower level device objects (corresponding to lower level device drivers) have lower numbers than higher level device objects (corresponding to higher level device drivers). The device stack may be traversed downwards by traversing the stack from higher level objects to lower level objects. For example, in the case of an illustrative device stack <b>280</b> corresponding to a USB flash drive, the ordered device stack may be traversed downwards from a high-level file system driver device object, to a volume manager driver device object, to a storage driver device object, to a USB driver device object, and finally to a low-level virtual bus driver device object. Different device stacks <b>280</b> can be layered over each other to provide the functionality of the devices <b>240</b>/<b>290</b> inside devices, like USB Headsets, or USB pen drives. A USB pen drive, for example, can create a USB device stack first, over which it can create a storage device stack, where each of the device stacks have two or more device objects.
0045Once one or more device object(s) <b>281</b> are loaded by the operating system <b>170</b> of the server <b>104</b>, each device object <b>281</b> can create a symbolic link (also referred to as a “device interface”) to the device object <b>281</b> and associated device driver <b>282</b>. The symbolic link is used by applications running on the server <b>104</b> to access the device object <b>281</b> and the device <b>240</b>/<b>290</b>. The symbolic link can be created by a call to a function such as IOCreateSymbolicLink( ) including such arguments as a name for the symbolic link, and a name of the device object <b>281</b> or associated device <b>240</b>. In one example, for example, a symbolic link to a USB flash drive device <b>240</b> is created by a call from a device object <b>281</b> for the device <b>240</b> to the function IOCreateSymbolicLink( ) including arguments “\\GLOBAL??\C:” (i.e., the name for the symbolic link) and “\Device\HarddiskVolume1” (i.e., a name of the device object).
0046A device interface is similar to a symbolic link, and the terms are used interchangeably herein. In Windows-based operating systems, a device interface may be a symbolic link for which the name is chosen by Windows based on device type.
0047The creation of a symbolic link results in an entry being created in an object manager namespace (OMN) (described in more detail in relation to <figref idref="DRAWINGS">FIG. 4A</figref> below) of the operating system <b>170</b>. The OMN stores information on symbolic links created for and used by the operating system <b>170</b>, including symbolic links for devices <b>240</b>, virtualized devices <b>290</b>, and applications <b>270</b> running on the server <b>104</b>.
0048As a result of the symbolic link creation process, a symbolic link to the device <b>240</b> is enumerated in the OMN of the server <b>104</b>. Once the presence of the device <b>240</b> is reported to the operating system <b>170</b> of the server <b>104</b>, the device <b>240</b> may be accessible from a user session (and associated desktop) running on the server <b>104</b> (i.e., virtual desktop environment). For example, the device <b>240</b> may appear as an icon on the virtual desktop environment and/or may be accessed by applications running on the server <b>104</b>.
0049In one aspect, an application <b>270</b> running on the server <b>104</b> may access the device <b>240</b> by sending a transaction request including the symbolic link for the device <b>240</b> to the operating system <b>170</b>. The operating system <b>170</b> may consult the Object Manager Namespace to retrieve an address or other identifier for the device itself <b>240</b> or for a device object <b>281</b> associated with the device <b>240</b>. Using the retrieved address or identifier, the operating system <b>170</b> forwards the transaction request for the device <b>240</b> either directly, through a device object <b>281</b> of the device stack <b>280</b>, and/or through the virtual bus driver <b>260</b>. The virtual bus driver <b>260</b> may direct the transaction request to the agent <b>250</b>, which sends the transaction request to the proxy <b>210</b> over the network <b>106</b>. The proxy <b>210</b> receives the transaction request from the agent <b>250</b>, and directs the received transaction request to the stub driver <b>220</b>. The stub driver <b>220</b> then directs the transaction request to the device <b>240</b> through the bus driver <b>230</b>.
0050The bus driver <b>230</b> receives the result of the transaction request from the device <b>240</b> and sends the result of the transaction request to the stub driver <b>220</b>. The stub driver <b>220</b> directs the result of the transaction request to the proxy <b>210</b>, which sends the result of the transaction request to the agent <b>250</b> over the network <b>106</b>. The agent <b>250</b> directs the result of the transaction request to the virtual bus driver <b>260</b>. The virtual bus driver <b>260</b> then directs the result of the transaction request to the application <b>270</b> either directly or through a device object <b>281</b> of the device stack <b>280</b>.
0051Thus, the virtual bus driver <b>260</b> may receive transaction requests for the device <b>240</b> from the application <b>270</b> and send results of the transaction requests back to the application <b>270</b> (either directly or through a device object <b>281</b> of the device stack <b>280</b>). As such, the application <b>270</b> may interact with the virtual bus driver <b>260</b> in the same way as with a bus driver for a device that is connected locally to the server <b>104</b>. The virtual bus driver <b>260</b> may hide the fact that it sends transaction requests to the agent <b>250</b> and receives the results of the transaction requests from the agent <b>250</b> instead of a device that is connected locally to the server <b>104</b>. As a result, the device <b>240</b> connected to the client <b>102</b> may appear to the application <b>270</b> as if the physical device <b>240</b> is connected locally to the server <b>104</b>.
0052The Object Manager Namespace (OMN) stores information on symbolic links created for use by the operating system <b>170</b>, including symbolic links for devices and for applications running on the server <b>104</b>. The Object Manager Namespace generally includes several different namespaces for storing symbolic link information for applications and devices. For example, the Object Manager Namespace can include namespaces such as: a “Global” namespace used to store symbolic link information for devices and applications that are shared by all user sessions running on the server <b>104</b>; various “Local” namespaces, each associated with a user session running on the server <b>104</b>, used to store information for applications used by (and restricted to) the associated user session; and a “Device” namespace used to store device object names of devices and virtual devices accessible by the server <b>104</b>. A “Global” namespace may be referred to as a global namespace. A “Local” namespace may be referred to as a local namespace. A “Device” namespace may be referred to as a device namespace.
0053As described herein, symbolic links can be stored in a global namespace or a local namespace. Symbolic links stored in a global namespace may be available to the entire system (i.e., to all user sessions running on server <b>104</b>), while symbolic links stored in a local namespace may only be seen and accessed by the session for which they are created. For example, “\\GLOBAL??\c:” may be a symbolic link stored in a global namespace. “\Device\HarddiskVolume1” may be a device object name stored in a device namespace. A symbolic link “\\GLOBAL??\c:” may be pointing to a device object having a device object name of “\Device\HarddiskVolume1”. Because “c:” is a symbolic link in the global namespace directory, such a symbolic link may be accessed by the entire system, including all the users logged in through their respective user sessions. A user application can open “\\GLOBAL??\c:” or just “c:” to access the actual device.
0054In certain operating systems, such as the Windows operating system, the creation of the symbolic link for a device <b>240</b> results in an entry being created in a Global namespace of the Object Manager Namespace. Because the symbolic link is created in the Global namespace, the symbolic link can be accessed from any user session running on server <b>104</b>. As a result, the device <b>240</b> associated with the symbolic link can be accessed from any user session on the server <b>104</b>, and/or from any client terminal having an active user session on server <b>104</b>.
0055<figref idref="DRAWINGS">FIG. 2B</figref> illustratively shows a block diagram of a computer network <b>100</b> providing local device virtualization. As previously described in relation to <figref idref="DRAWINGS">FIG. 1</figref>, network <b>100</b> includes client terminals <b>102</b><i>a</i>, <b>102</b><i>b</i>, and <b>102</b><i>c</i>, communicating through network <b>106</b> with server <b>104</b>. Each client terminal can have one or more connected devices, such as device <b>240</b><i>a </i>connected to client terminal <b>102</b><i>a</i>, and device <b>240</b><i>b </i>connected to client terminal <b>102</b><i>b. </i>
0056As described in relation to <figref idref="DRAWINGS">FIG. 2A</figref> above, each device <b>240</b><i>a</i>, <b>240</b><i>b </i>can be virtualized on the server <b>104</b> to provide access to the device from a user session on the server <b>104</b> through a corresponding virtual device <b>290</b><i>a</i>, <b>290</b><i>b</i>. For example, when device <b>240</b><i>a </i>is connected to client terminal <b>102</b><i>a</i>, drivers for device <b>240</b><i>a </i>may be loaded in operating system <b>170</b> of server <b>104</b>, the device <b>240</b><i>a </i>may be virtualized on server <b>104</b> as virtual device <b>290</b><i>a</i>, and a symbolic link to the device <b>240</b><i>a </i>may be created in the Object Manager Namespace of operating system <b>170</b>. Once the symbolic link is created, a user of client terminal <b>102</b><i>a </i>may be able to access device <b>240</b><i>a </i>through a user session on server <b>104</b>. Similarly, when device <b>240</b><i>b </i>is connected to client terminal <b>102</b><i>b</i>, a symbolic link to the device <b>240</b><i>b </i>may be created in the Object Manager Namespace of operating system <b>170</b> of server <b>104</b>. Once the symbolic link is created, a user of client terminal <b>102</b><i>b </i>may be able to access device <b>240</b><i>b </i>through a user session on server <b>104</b>.
0057The symbolic links to the devices <b>240</b><i>a</i>, <b>240</b><i>b </i>are created in a Global namespace of the Object Manager Namespace of operating system <b>170</b>. As a result, the symbolic links and associated devices can be accessed from and used by any user session running on server <b>104</b>. For example, as illustratively shown in <figref idref="DRAWINGS">FIG. 2B</figref>, a user of client terminal <b>102</b><i>a </i>having a user session on server <b>104</b> may access both device <b>240</b><i>a </i>as well as virtual device <b>240</b><i>b</i>′ from the user session. Similarly, a user of client terminal <b>102</b><i>b </i>having a user session on server <b>104</b> may access both device <b>240</b><i>b </i>as well as virtual device <b>240</b><i>a</i>′ from the user session. Finally, a user of client terminal <b>102</b><i>c </i>having a user session on server <b>104</b> may access both virtual device <b>240</b><i>a</i>′ and <b>240</b><i>b</i>′ from the user session.
0058Hence, the device virtualization described in relation to <figref idref="DRAWINGS">FIGS. 2A and 2B</figref> provides unrestricted access to devices <b>240</b> connected locally to client terminals <b>102</b> from any user session on server <b>104</b>. As such, a redirected device on a terminal server <b>102</b> becomes a local device to the server and can be accessed by all the users' sessions connected to that server. For example a printer or a mass storage device, when redirected by one user connected through a session on the server, will show up as a local device and all the users can read/write the mass storage device and print using the printer.
0059While the unrestricted access enables users of client terminals <b>102</b> to share access to and use of devices <b>240</b>, the device virtualization does not permit a user to restrict access to a device <b>240</b>. In this respect, the unrestricted device virtualization does not permit secure or private access to the device <b>240</b>. The device virtualization thus presents security and privacy concerns, as a device <b>240</b> may be accessed or used by any number of unauthorized users having user sessions on server <b>104</b>. In order to address these security and privacy concerns, a device virtualization system may require that a device connected through a session only be accessible in that session.
0060A device virtualization system that addresses such security and privacy concerns has been developed, by providing a hook into a kernel of an operating system as described, for example, in U.S. patent application Ser. No. 13/287,982, filed on Nov. 2, 2011. However, in one aspect, methods which provide hooks into a kernel of an operating system will fail if the operating system implements features which protect the kernel from such hooks and other types of patches. For example, 64-bit versions of Windows operating system implement a feature called Kernel Patch Protection (KPP) which prevents hooks and patches on the kernel.
0061In order to enable restricting access to a device in a local device virtualization system that implements features which prevent hooks and patches into the kernel, an enhanced server system is represented in <figref idref="DRAWINGS">FIG. 3A</figref>. <figref idref="DRAWINGS">FIG. 3A</figref> is a block diagram of a system <b>300</b>. The system <b>300</b> may include a client <b>102</b> in communication with a server <b>304</b> over network <b>106</b> (illustrated in <figref idref="DRAWINGS">FIG. 1</figref>). The client <b>102</b>, including proxy <b>210</b>, stub driver <b>220</b>, bus driver <b>230</b>, and one or more optional device(s) <b>240</b>, is substantially similar to the client <b>102</b> shown in and described in relation to <figref idref="DRAWINGS">FIG. 2A</figref>. The server <b>304</b> includes agent <b>250</b>, virtual bus driver <b>260</b>, device stack <b>280</b> including device objects <b>281</b><i>a</i>, <b>281</b><i>b</i>, . . . , <b>281</b><i>n</i>, device drivers <b>282</b><i>a</i>, <b>282</b><i>b</i>, <b>282</b><i>n</i>, operating system <b>170</b>, application <b>270</b>, and one or more optional virtualized device(s) <b>290</b>, which function substantially similarly to the corresponding elements of server <b>104</b> of <figref idref="DRAWINGS">FIG. 2A</figref>. In one aspect, the operating system <b>170</b> includes the kernel module <b>171</b>.
0062Server <b>304</b> additionally includes a Device Access Restriction object (DAR object) <b>180</b> at the top of the device stack <b>280</b>. A Device Access Restriction driver (DAR driver) <b>182</b> creates and attaches the DAR object <b>180</b> at the top of the device stack <b>280</b>. The DAR driver <b>182</b> is registered with the operating system <b>170</b> or the kernel module <b>171</b> as the upper filter driver for all selected class(es) of devices for which access restriction is to be made. When the DAR driver <b>182</b> determines that a device of the class for which the DAR driver is registered is redirected to the server <b>304</b>, the DAR driver creates the DAR object <b>180</b> and attaches the DAR object at the top of the device stack <b>280</b>.
0063Server <b>304</b> functions substantially similarly to server <b>104</b> (described in relation to <figref idref="DRAWINGS">FIG. 2A</figref>) in terms of loading drivers and device objects for device <b>240</b> on the server <b>304</b>. However, as discussed above, the DAR driver <b>182</b> is registered as the upper filter driver for all the selected class(es) of devices for which access restriction is to be provided. For example, an image device class which includes webcams may be predetermined to be provided with access restriction. Such device classes may be predetermined by a user. When a device of the class, for which DAR driver <b>182</b> is registered, is plugged in, the DAR driver will be loaded and its add device routine may be called by the operating system <b>170</b>. For example, in cases where the operating system <b>170</b> is a Windows system, a plug-and-play (PNP) component of Windows Kernel will call an add device routine of the DAR driver <b>182</b>. Inside the add device routine, the DAR driver <b>182</b> receives the physical device object of the device stack <b>280</b> as an argument, which is used to verify that the device is a device redirected from the client <b>102</b> using the virtual bus driver <b>260</b>. This verification is done by traversing the device stack <b>280</b> downward until the bottom of the stack is reached or the virtual bus driver <b>260</b> is found.
0064If the virtual bus driver <b>260</b> is found in the device stack <b>280</b>, this signifies that the device is a redirected from the client <b>102</b> using the virtual bus driver. If the device is found to be redirected from the client <b>102</b>, the DAR driver <b>182</b> creates the DAR object <b>180</b> and attaches it (as the top object) onto the device stack <b>280</b>. However, if the bottom of the device stack <b>280</b> is reached and the virtual bus driver <b>260</b> is not found, this signifies that the device stack is not a device that is redirected from the client <b>102</b>, and thus no access restriction is to be provided. If the device is not found to be redirected, then the DAR object <b>180</b> will not be attached on top of the device stack <b>280</b>.
0065Since the DAR object <b>180</b> is attached to the top of the device stack <b>280</b>, all requests for the redirected device are first received by the DAR object <b>180</b>. Thus, the DAR object <b>180</b> can accept or reject the requests. For example, the DAR object <b>180</b> can thus restrict a redirected device to be only accessible from the user session (e.g., a Microsoft windows terminal server session) it is redirected from.
0066When a request is received at the DAR object <b>180</b>, verification is made whether the request belongs to a process in the same session as that of the redirected device. If the request is from the session which is allowed to access the device (e.g., request is from the same session as the redirected device), then the request is forwarded to the original device driver down in the device stack <b>280</b>. If the request belongs to a session which is not allowed access to the redirected device (e.g., request is from a session which is different from the session of the redirected device), then the request is rejected. If the request is rejected, an error may be returned to the requestor indicating that no such device exists. This error makes the applications running in different sessions believe that there is no such device present on the system.
0067In one aspect, a Microsoft terminal server technology and license can provide a way for many users to connect to the same server using the same user account or different user accounts. A device can be redirected to a terminal server, where many users may be connected. The device may only be accessible from the terminal session it was redirected from. All the other user sessions may be able to see the presence of the device using some tools, but may not be able to access the device. The DAR object <b>180</b> may thus keep the device access restricted to a session, which is redirected on the terminal server, and may thus only allow the access to the device to the terminal server session from which it is redirected. The session level restriction can enable the device to be accessed by the tools and processes which are executed in the same session, and/or to be accessed by tools and processes using windows supported interface to devices from the same session. From other users' sessions, however, the device may not be accessible to the tools or processes. By restricting access to the device such that access is only granted to the particular client/session the device is physically connected to/through, DAR object <b>180</b> provides private session-based access to the device. In addition, by verifying the identity of a session seeking to access the device through the symbolic link and by blocking unauthorized access to the device from unauthorized or unassociated user sessions, including both read access and write access, DAR object <b>180</b> provides secure access to the device.
0068<figref idref="DRAWINGS">FIG. 3B</figref> shows a block diagram of a computer network <b>100</b> providing restricted access to virtualized local devices. As previously described in relation to <figref idref="DRAWINGS">FIG. 2B</figref>, network <b>100</b> includes client terminals <b>102</b><i>a</i>, <b>102</b><i>b</i>, and <b>102</b><i>c </i>communicating through network <b>106</b> with a server. Each client terminal can have one or more connected devices, such as device <b>240</b><i>a </i>connected to client terminal <b>102</b><i>a</i>, and device <b>240</b><i>b </i>connected to client terminal <b>102</b><i>b. </i>
0069Referring to <figref idref="DRAWINGS">FIGS. 3A and 3B</figref>, the server <b>304</b> is configured to provide managed access to virtualized local devices. As such, server <b>304</b> includes a Device Access Restriction (DAR) Driver <b>182</b> which is registered for the class of devices for which access restriction is to be provided on server <b>304</b>, and attaches a DAR object <b>180</b> on top of the device stack <b>280</b> to manage access to the device <b>240</b>. When device <b>240</b><i>a </i>is connected to client <b>102</b><i>a</i>, a corresponding virtualized device <b>290</b><i>a </i>is created on server <b>304</b>. When the virtualized device <b>290</b><i>a </i>is created, if the device <b>240</b><i>a </i>is of a class for which the DAR driver is registered, the DAR driver <b>182</b> is loaded. DAR driver <b>182</b> traverses the device stack downwards to identify whether the device <b>240</b><i>a </i>is a redirected device, by finding the virtual bus driver <b>260</b> in the device stack. If the device <b>240</b><i>a </i>is identified as a redirected device, then device configuration data for the device <b>240</b><i>a </i>is obtained. The device configuration data may be stored, for example, at the virtual bus driver <b>260</b> or at a server registry stored in a memory of the server <b>304</b>. The device configuration data stores any user configuration settings which may have been set for the device <b>240</b><i>a</i>. The device configuration data may include, for example, individual access restriction settings for this specific device. Specifically, even though the device <b>240</b><i>a </i>is determined to be a redirected device, the device configuration data may indicate that the device is not to be restricted. In such case, device <b>240</b><i>a </i>will not be restricted and the DAR object <b>180</b> will not be attached.
0070If the device <b>240</b><i>a </i>is identified as a redirected device and the obtained device configuration data allows for restricting access, then the DAR object <b>180</b> is attached to the top of the device stack. Since the DAR object <b>180</b> is attached on top of the device stack, all access requests to the device <b>240</b><i>a </i>is first received by the DAR object <b>180</b>. The DAR object <b>180</b> determines whether the requests are received from the same session as that of the device <b>240</b><i>a</i>. In the example of <figref idref="DRAWINGS">FIGS. 3A and 3B</figref>, the device stack <b>280</b> of the device <b>240</b><i>a </i>includes the virtual bus driver <b>260</b> (signifying that the device <b>240</b><i>a </i>is a redirected device) and the DAR object <b>180</b> is attached on top of its device stack. Because the DAR object <b>180</b> is attached to the top of its device stack, the DAR objects manages the access requests such that device <b>240</b><i>a </i>is only accessible from client terminal <b>102</b><i>a. </i>
0071Rather than being connected to a client <b>102</b> and being redirected to the server <b>304</b> as a virtual device, device <b>240</b><i>b </i>may be physically connected to the server. As in the case of device <b>240</b><i>a </i>described above, when the device <b>240</b><i>b </i>is connected, if the device is of a class for which the DAR driver is registered, the DAR driver <b>182</b> is loaded. However, the DAR driver <b>182</b> will not find the virtual bus driver <b>260</b> within the device stack <b>280</b>, since the device <b>240</b><i>b </i>is not a redirected device. Therefore, the DAR object <b>180</b> will not be attached to the top of the device stack. Because the DAR object <b>180</b> is not present, no access restriction is provided. Thus device <b>240</b><i>b </i>is accessible from all user sessions running on client terminals <b>102</b><i>a</i>, <b>102</b><i>b</i>, and <b>102</b><i>c </i>as device <b>240</b><i>b′. </i>
0072In one aspect, after a device <b>240</b> (e.g., <b>240</b><i>a</i>) is identified as a redirected device and a DAR object <b>180</b> is attached on top of the device stack <b>280</b> as discussed above, extra steps may be performed to provide additional access restriction to the device. After the DAR object <b>180</b> is attached on top of the device stack <b>280</b>, the DAR driver <b>182</b> traverses the device stack to search for all symbolic links to all the device objects <b>281</b> in the device stack which are created in the global namespace of the OMN of the server <b>304</b>. Such symbolic links are moved to the local namespace of the OMN for the session in which the device <b>240</b> is redirected. As discussed above, the symbolic links stored in the local namespace for a specific session is only accessible by processes belonging to the same session. Therefore, users accessing the server <b>304</b> on a session which is different from the session in which the device <b>240</b> is redirected cannot see, and/or have access to, the device <b>240</b>. Searching for the symbolic links in the global namespace and moving them to the local namespace may be repeated multiple times, whenever it is determined that the device drivers <b>282</b> corresponding to the device objects <b>281</b> in the device stack <b>280</b> is likely to create a new device interface in the global namespace.
0073A record of all device interfaces that are moved are kept so that when the device <b>240</b> is removed, the local namespace for the session of the device <b>240</b> may be cleaned up.
0074In one aspect, for certain types of devices, requests made by a process belonging to a session may not be sent to the DAR object <b>180</b> through the same session. For example, operating systems such as, for example, Windows, implement an architecture under which all the print requests are first sent to a service called spooler, and which are then sent to the printer device. <figref idref="DRAWINGS">FIG. 4C</figref> shows a block diagram of an example of a printer architecture that may be implemented at a local device virtualization system. When an application <b>470</b> (e.g., application <b>270</b> of <figref idref="DRAWINGS">FIG. 2A or 3A</figref>) issues a print request, the print request is sent to a graphics device interface (GDI) <b>480</b> and to a spooler service <b>490</b>. The GDI <b>480</b> provides graphics support for generating data which may be received by the spooler service <b>490</b> for fulfilling the print request. The spooler service <b>490</b> receives the print request from the application <b>470</b> and the data generated by the GDI <b>480</b>, and sends the print request and the data generated by the GDI <b>480</b> to a printer. The printer receives the print request and the data generated by the GDI <b>480</b>, and fulfills the print request.
0075However, the spooler service <b>490</b>, under certain implementations such as, for example, under Windows, runs in a predetermined session (e.g., session <b>0</b>). Therefore, all the requests coming to printer device will appear to be coming from the predetermined session, regardless of the session of the original process which had originally sent the print request. However, the DAR object <b>180</b> as discussed above with reference to <figref idref="DRAWINGS">FIGS. 3A and 3B</figref> allows only those requests coming from the same session as that in which the device is redirected. Therefore, in the example of Windows, all the print requests, which are coming from the predetermined session (e.g., session <b>0</b>) regardless of the session of the original processes sending the print requests, will likely be rejected, and the printer device will be unusable. On the other hand, if an exception is made to the DAR object <b>180</b> and all requests coming in from the predetermined session on which the spooler service <b>490</b> runs (e.g., session <b>0</b>) is allowed access to the printer device, any requests made by any session will be granted access and access restriction may not be provided. The descriptions made in this paragraph may also apply to other devices for which access requests are routed through a service running on a predetermined session.
0076Therefore, in another aspect, similar to the aspect discussed above, after the DAR object <b>180</b> is attached to the device stack <b>280</b>, all symbolic links stored in the global namespace of the OMN corresponding to the device objects <b>281</b> of the device stack <b>280</b> are moved to the local namespace for the session in which the device is redirected. In addition, when the DAR object <b>180</b> receives a request, in addition to allowing requests from the same session as that in which the device is redirected, all requests from a predetermined session (e.g., session <b>0</b> for printers on Windows) will also be allowed. By moving the symbolic links to the local namespace and having the DAR object <b>180</b> also allow requests from a predetermined session, access restriction can also be provided for the types of devices (e.g., printer devices) for which all requests are sent by a predetermined session.
0077In this aspect, using a printer device on Windows as an example, when the print spooler service (e.g., spooler service <b>490</b>) gets a print request from a session other than the session in which the printer device is redirected, the spooler service will search for the printer device interface first in the session's local namespace, and then global namespace. However, the spooler service will not find the printer device interface in the local namespace since the request is from a different session. Also, the spooler service will not find the printer device interface in the global namespace since all the device interfaces for the printer have been moved to the local namespace for the session of the printer. Therefore, this request will wait in the print queue until the user in this session redirects a printer, or a printer is physically connected to the server.
0078If the spooler service receives a print request from the same session as that of the printer, the spooler service also searches for the printer device interface, first in the local namespace for the session. However, in this case, since the request is made by the same session as that of the printer, the spooler service will find the printer device interface. Using the printer device interface, the spooler service will send a print request to the printer's device stack <b>280</b> through session <b>0</b>. The DAR object <b>182</b> of the device stack <b>280</b> will receive the request and allow the request, since it is coming from session <b>0</b>.
0079<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> respectively show data structures for storing an object manager namespace <b>401</b> and device configuration data of a virtual bus driver <b>451</b>, in accordance with various aspects of the subject technology.
0080<figref idref="DRAWINGS">FIG. 4A</figref> illustratively shows a data structure for storing an object manager namespace <b>401</b> of server <b>304</b>. The data structure is generally resident in and stored in a memory of server <b>304</b>. For example, object manager namespace <b>401</b> may be stored in a random access memory of server <b>304</b>. The Object Manager Namespace <b>401</b> stores records for devices, applications, and/or other components or objects that are running on or accessible from an associated operating system (such as operating system <b>170</b>) or computer (such as server <b>304</b>). The records contained in the Object Manager Namespace <b>401</b> are organized in one or more of a global namespace <b>403</b>, a local namespace <b>405</b>, and a device namespace <b>407</b>. The records in the global namespace <b>403</b> and local namespace <b>405</b> may include symbolic links which point to device objects (e.g., device objects for the devices, applications and/or other components running on or accessible from the associated operating system or computer). Global namespace <b>403</b> includes records or entries <b>411</b>, <b>413</b> that point to device objects that are shared between all user sessions on the operating system or computer. As such, devices, applications, or other objects having corresponding entries in the global namespace can receive access requests by any user, or from any user session, on the operating system <b>170</b> or computer (e.g., server <b>304</b>). Local namespace <b>405</b> includes records or entries <b>417</b>, <b>418</b>, <b>419</b> that point to device objects that are specific to one or more user sessions on the operating system or computer. As such, devices, applications, or other objects having corresponding entries in the local namespace can only be accessed by the particular session(s) that they are associated with. In the example of <figref idref="DRAWINGS">FIG. 4A</figref>, for example, records or entries <b>417</b> and <b>419</b> are associated with a first user session <b>415</b>, while record or entry <b>418</b> is associated with a different user session <b>416</b>. Finally, device namespace <b>407</b> includes records or entries <b>421</b>, <b>423</b> for all device objects that are running on or accessible from the operating system or computer. As such, the symbolic links from global namespace <b>403</b> or local namespace <b>405</b> point to device object entries in the device namespace <b>407</b>. In an aspect of the subject technology, the device objects may be created and stored in a location other than a device namespace <b>407</b>.
0081<figref idref="DRAWINGS">FIG. 4B</figref> illustratively shows data structure <b>451</b> for storing device configuration data of a virtual bus driver, such as virtual bus driver <b>260</b> of <figref idref="DRAWINGS">FIGS. 2A and 3A</figref>. The data structure <b>451</b> is generally resident in and stored in a memory of the server <b>104</b>, <b>304</b> associated with the virtual bus driver. The data structure <b>451</b> can include a record or entry <b>453</b> for each virtualized device connected to or resident on the virtual bus. Each entry <b>453</b> stores device information <b>455</b> associated with the corresponding virtualized device. The device information can include a physical address for the device, one or more session identifiers associated with the device (e.g., a session LUID or session number), a device descriptor (e.g., product ID, vendor ID, and/or other information), a configuration descriptor, an interface descriptor, an endpoint descriptor and/or a string descriptor. The device information can also include device configuration data, such as the device configuration data used to determine whether a device should be restricted.
0082<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating an exemplary method <b>500</b> for managing access to a device, in accordance with various aspects of the subject technology. Method <b>500</b> can be implemented by one or more processors on server <b>304</b>, for example.
0083Method <b>500</b> begins with operation <b>501</b>, in which the DAR driver <b>182</b> registers itself as an upper filter driver for the class of devices which access restriction is to be provided. This operation allows the DAR driver <b>182</b> to be loaded for each class of device for which a user wishes to manage access restriction. In step <b>502</b>, when a device of the class for which the DAR driver <b>182</b> is registered is plugged in, the DAR driver <b>182</b> will be loaded and its add device routine will be called. For example, the plug-and-play (PNP) component of Windows Kernel will load the DAR driver <b>182</b> and call its add device routine. When the add device routine is called, a physical device object associated with the current device stack is passed in as an argument to the add device routine.
0084In step <b>503</b>, the DAR driver <b>182</b> traverses the device stack <b>280</b> downwards and checks if it finds the virtual driver <b>260</b>. For example, the DAR driver <b>182</b> uses the physical device object that is passed in as an argument to the add device routine, and checks if the device stack <b>280</b> ends at a device object <b>281</b> which is created by the virtual bus driver <b>260</b>. The presence of the device object <b>281</b> created by the virtual bus driver <b>260</b> signifies that the device is a redirected device.
0085If the virtual bus driver <b>260</b> is found, the device configuration from the virtual bus driver is received, and the device configuration is checked to determine if the user has configured the access to the device to be restricted to the session of the device.
0086If yes, in step <b>504</b>, the DAR object <b>180</b> is created and attached to the device stack <b>280</b>. Since the DAR object <b>180</b> is attached to the top of the device stack <b>280</b>, the DAR object will be the first object in the device stack to receive access requests to the device.
0087If the virtual driver <b>260</b> is not found until the bottom of the device stack <b>280</b> is reached, or if the device is configured such that access to the device is not restricted to the session of the device, then the DAR object <b>180</b> is not attached and the method ends.
0088In step <b>505</b>, when a process makes a device request, this request will be intercepted by the DAR object <b>180</b> and the requesting process's session is identified.
0089If the requesting session is the device's own session, in step <b>506</b>, access is allowed, and the request is passed down to the rest of the device stack <b>280</b> to the device object which may respond to the request.
0090However, if the requesting session is not the session which is allowed to access the device (e.g., requesting session is not the device's own session), then in step <b>507</b>, access to the devices is blocked. If the access is blocked, an error may be returned back to the requesting process, indicating that no such device exists.
0091<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart illustrating another exemplary method <b>600</b> for managing access to a device, for which requests are sent from a single session, in accordance with various aspects of the subject technology. Requests that are sent from a single session may be sent, for example, by the spooler service <b>490</b> as described with reference to <figref idref="DRAWINGS">FIG. 4C</figref>, which receives a print request from an application (e.g., application <b>270</b>) and sends the print request to a printer. Method <b>600</b> can be implemented by one or more processors on server <b>304</b>, for example.
0092Method <b>600</b> begins with operation <b>601</b> in which the DAR driver <b>182</b> is registered as the upper filter driver for a device class. This operation allows the DAR driver <b>182</b> to be loaded for each class of device for which a user wishes to manage access restriction. In step <b>602</b>, when a device of the class for which the DAR driver <b>182</b> is registered is plugged in, the DAR driver <b>182</b> will be loaded and its add device routine will be called. For example, the plug-and-play (PNP) component of Windows Kernel will load the DAR driver <b>182</b> and call its add device routine. When the add device routine is called, a physical device object associated with the current device stack is passed in as an argument to the add device routine.
0093In step <b>603</b>, the DAR driver <b>182</b> traverses the device stack <b>280</b> downwards and checks if it finds the virtual bus driver <b>260</b>. For example, the DAR driver <b>182</b> uses the physical device object that is passed in as an argument to the add device routine, and checks if the device stack <b>280</b> ends at a device object <b>281</b> which is created by the virtual bus driver <b>260</b>. The presence of the device object <b>281</b> created by the virtual bus driver <b>260</b> signifies that the device is a redirected device.
0094If the virtual bus driver <b>260</b> is found, the device configuration from the virtual bus driver is received, and the device configuration is checked to determine if the user has configured the access to the device to be restricted to the session of the device.
0095If yes, in step <b>604</b>, the DAR object <b>180</b> is created and attached to the device stack <b>280</b>. Since the DAR object <b>180</b> is attached to the top of the device stack <b>280</b>, the DAR object will be the first object in the device stack to receive access requests to the device.
0096If the virtual bus driver <b>260</b> is not found until the bottom of the device stack <b>280</b> is reached, or if the device is configured such that access to the device is not restricted to the session of the device, then the DAR object <b>180</b> is not attached and the method ends.
0097In operation <b>605</b>, the DAR driver <b>182</b> searches for all the symbolic links in the global namespace of the object manager namespace pointing to any device objects <b>281</b> in the entire device stack <b>280</b> for the device. The symbolic links are searched for each of the device object <b>281</b>. If a device interface is found, in step <b>606</b>, it is moved to local namespace for the session of the device.
0098Since the symbolic links for the device objects <b>281</b> are moved to the local namespace for the session, processes which belong to a session other than the session of the device will not be able to find the symbolic links to the device objects <b>281</b> of the device.
0099In step <b>607</b>, requests for the device are intercepted by the DAR object <b>180</b> and the requesting process's session is identified. For a certain type of device (e.g., printer), all the requests will first be sent to a service (e.g., spooler service <b>490</b>) which runs on a predetermined session (e.g., session <b>0</b>). Therefore, all requests to the device will come from the predetermined session and the requests from such predetermined session will be allowed, even though the request did not come from the session of the device. The requests received from the session of the device are also allowed. If the identified session in operation <b>607</b> is the predetermined session or the session of the device, in step <b>608</b>, the request is allowed. If the request identified in operation <b>607</b> is not the predetermined session or the session of the device, then, in step <b>609</b>, the request is blocked.
0100In addition, when the device has been removed from the server (e.g., device has been unplugged at the client from which it was redirected), in step <b>610</b>, the local namespace of the session of the device is cleaned to remove the symbolic links which had been copied from the global namespace.
0101<figref idref="DRAWINGS">FIG. 7</figref> is a conceptual block diagram illustrating an example of a system <b>700</b>, in accordance with various aspects of the subject technology. The system <b>700</b> may be, for example, a client <b>102</b> (e.g., client <b>102</b><i>a</i>, <b>102</b><i>b</i>, <b>102</b><i>c</i>) or a server <b>104</b>/<b>304</b>.
0102The system <b>700</b> includes a processing system <b>702</b>. The processing system <b>702</b> is capable of communication with a receiver <b>706</b> and a transmitter <b>709</b> through a bus <b>704</b> or other structures or devices. It should be understood that communication means other than busses can be utilized with the disclosed configurations. The processing system <b>702</b> can generate audio, video, multimedia, and/or other types of data to be provided to the transmitter <b>709</b> for communication. In addition, audio, video, multimedia, and/or other types of data can be received at the receiver <b>706</b>, and processed by the processing system <b>702</b>.
0103The processing system <b>702</b> may include a general-purpose processor or a specific-purpose processor for executing instructions and may further include a machine-readable medium <b>719</b>, such as a volatile or non-volatile memory, for storing data and/or instructions for software programs. The instructions, which may be stored in a machine-readable medium <b>710</b> and/or <b>719</b>, may be executed by the processing system <b>702</b> to control and manage access to the various networks, as well as provide other communication and processing functions. The instructions may also include instructions executed by the processing system <b>702</b> for various user interface devices, such as a display <b>712</b> and a keypad <b>714</b>. For the example of a client <b>102</b>, the display <b>712</b> may be used to locally display the virtual desktop environment at the client <b>102</b>, and the keypad <b>714</b> may be used to receive user input command, which may be forwarded to the server <b>104</b>/<b>304</b> over the network <b>106</b>. The processing system <b>702</b> may include an input port <b>722</b> and an output port <b>724</b>. Each of the input port <b>722</b> and the output port <b>724</b> may include one or more ports. The input port <b>722</b> and the output port <b>724</b> may be the same port (e.g., a bi-directional port) or may be different ports.
0104The processing system <b>702</b> may be implemented using software, hardware, or a combination of both. By way of example, the processing system <b>702</b> may be implemented with one or more processors. A processor may be a general-purpose microprocessor, a microcontroller, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, any other suitable device that can perform calculations or other manipulations of information, or a portion(s) or a combination(s) of any of the foregoing. A processor may include one or more processors.
0105A machine-readable medium can be one or more machine-readable media. Software shall be construed broadly to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code).
0106A non-transitory machine-readable medium include one or more volatile memories and/or one or more non-volatile memories.
0107Machine-readable media (e.g., <b>719</b>) may include storage integrated into a processing system, such as might be the case with an ASIC. Machine-readable media (e.g., <b>710</b>) may also include storage external to a processing system, such as a Random Access Memory (RAM), a flash memory, a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable PROM (EPROM), registers, a hard disk, a removable disk, a CD-ROM, a DVD, or any other suitable storage device. In addition, machine-readable media may include a transmission line or a carrier wave that encodes a data signal. Those skilled in the art will recognize how best to implement the described functionality for the processing system <b>702</b>. According to one aspect of the disclosure, a machine-readable medium is a computer-readable medium encoded or stored with instructions and is a computing element, which defines structural and functional interrelationships between the instructions and the rest of the system, which permit the instructions' functionality to be realized. Instructions may be executable, for example, by a client terminal or server or by a processing system of a client terminal or server. Instructions can be, for example, a computer program including code.
0108A network interface <b>716</b> may be any type of interface to a network (e.g., an Internet network interface) and may reside between any of the components shown in <figref idref="DRAWINGS">FIG. 7</figref>. For the example of a client <b>102</b>, the network interface <b>716</b> may be used to send user commands and responses from the device <b>240</b> to the server <b>104</b>/<b>304</b> over the network <b>106</b>, and to receive display data (e.g., display data for the virtual desktop) and instructions (e.g., string descriptor requests) from the server <b>104</b>/<b>304</b> over the network <b>106</b>.
0109A device interface <b>718</b> may be any type of interface to a device and may reside between any of the components shown in <figref idref="DRAWINGS">FIG. 7</figref>. A device interface <b>718</b> may, for example, be an interface to an external device (e.g., USB device) that plugs into a port (e.g., USB port) of the system <b>700</b>. For the example of a client <b>102</b>, the bus driver <b>230</b> may be configured to detect the presence of a device <b>240</b> connected to the client <b>102</b> via the device interface <b>718</b>, and to read device information (e.g., device descriptor) from the device <b>240</b> via the device interface <b>718</b> to identify the device <b>240</b>.
0110A transceiver block <b>707</b> may represent one or more transceivers, and each transceiver may include a receiver <b>706</b> and a transmitter <b>709</b>. A functionality implemented in a processing system <b>702</b> may be implemented in a portion of a receiver <b>706</b>, a portion of a transmitter <b>709</b>, a portion of a machine-readable medium <b>710</b>, a portion of a display <b>712</b>, a portion of a keypad <b>714</b>, or a portion of an interface <b>716</b>, and vice versa.
0111For the example of a client <b>102</b>, the bus driver <b>230</b> may be implemented by the processing system <b>702</b>, the device interface <b>718</b>, the machine-readable medium <b>710</b> or any combination thereof and the proxy <b>210</b> may be implemented by the processing system <b>702</b>, the network interface <b>716</b>, the machine-readable medium <b>710</b> or any combination thereof. The stub driver <b>220</b> may be implemented by the processing system <b>702</b>, the machine-readable medium <b>710</b> or any combination thereof. For example, the machine-readable medium <b>710</b> may comprise software programs that may be executed by the processing system <b>702</b> to realize various functions of the bus driver <b>230</b>, stub driver <b>220</b> and the proxy <b>210</b>.
0112For the example of a server <b>104</b>/<b>304</b>, the virtual bus driver <b>260</b>, device stack <b>280</b>, DAR driver <b>182</b>, and application <b>270</b> may be implemented by the processing system <b>702</b>, the machine-readable medium <b>710</b> or any combination thereof, and the agent <b>250</b> may be implemented by the network interface <b>716</b>, the processing system <b>702</b>, the machine-readable medium <b>710</b> or any combination thereof.
0000Illustration of Apparatus/Method/Machine Readable Storage Medium for Providing Session-Level Access Management of a Redirected Device (Described as Clauses)
0113Various examples of aspects of the disclosure are described as numbered clauses (1, 2, 3, etc.) for convenience. These are provided as examples, and do not limit the subject technology. Identifications of the figures and reference numbers are provided below merely as examples and for illustrative purposes, and the clauses are not limited by those identifications.
01141. A method (see, e.g., <b>800</b>-A in <figref idref="DRAWINGS">FIG. 8A</figref>) for managing access restriction to a device from a server, the method comprising:
0115determining that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server (see, e.g., <b>802</b>-A in <figref idref="DRAWINGS">FIG. 8A</figref>);
0116attaching a device access restriction object on top of the device stack (see, e.g., <b>804</b>-A in <figref idref="DRAWINGS">FIG. 8A</figref>);
0117receiving, at the device access restriction object, an access request to the device (see, e.g., <b>806</b>-A in <figref idref="DRAWINGS">FIG. 8A</figref>); and
0118determining, at the device access restriction object, whether the access request is allowed access to the device (see, e.g., <b>808</b>-A in <figref idref="DRAWINGS">FIG. 8A</figref>).
01192. The method according to clause 1, wherein the determining whether the access request is allowed access to the device comprises:
0120determining whether a session from which the access request is received is the same as a session of the client; and
0121determining that the access request is allowed if the session from which the access request is received is the same as the session of the client.
01223. The method according to clause 2, further comprising determining that the access request is blocked if the session from which the access request is received is not the same as the session of the client; and
0123generating an error message indicating that the device does not exist.
01244. The method according to clause 1, wherein the determining that the device stack corresponds to the device that is remote to the server comprises facilitating traversing the device stack downwards to identify a device object corresponding to a virtual bus driver at the bottom of the device stack.
01255. The method according to clause 1, further comprising determining whether the device is configured to be provided with access restriction, wherein the attaching the access restriction object comprises:
0126attaching the access restriction object on top of the device stack if the device is configured to be provided with access restriction.
01276. The method of clause 1, wherein the method is performed without hooking to a kernel module.
01287. The method according to clause 1, wherein the device is a USB device.
01298. The method of clause 1, wherein the access request is made by a process of an application, and wherein receiving the access request to the device comprises:
0130intercepting the access request made by the process to the device.
01319. A machine-readable storage medium (see, e.g., <b>800</b>-B in <figref idref="DRAWINGS">FIG. 8B</figref>) encoded with instructions executable by one or more processors to perform one or more operations, the one or more operations comprising:
0132determining, at a server, that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server (see, e.g., <b>802</b>-B in <figref idref="DRAWINGS">FIG. 8B</figref>);
0133attaching a device access restriction object on top of the device stack (see, e.g., <b>804</b>-B in <figref idref="DRAWINGS">FIG. 8B</figref>);
0134receiving, at the device access restriction object, an access request to the device (see, e.g., <b>806</b>-B in <figref idref="DRAWINGS">FIG. 8B</figref>); and
0135determining, at the device access restriction object, whether the access request is allowed access to the device (see, e.g., <b>808</b>-B in <figref idref="DRAWINGS">FIG. 8B</figref>).
013610. The machine-readable storage medium according to clause 9, wherein the determining whether the access request is allowed access to the device comprises:
0137determining whether a session from which the access request is received is the same as a session of the client; and
0138determining that the access request is allowed if the session from which the access request is received is the same as the session of the client.
013911. The machine-readable storage medium according to clause 10, wherein the one or more operations further comprises determining that the access request is blocked if the session from which the access request is received is not the same as the session of the client; and
0140generating an error message indicating that the device does not exist.
014112. The machine-readable storage medium according to clause 9, wherein the determining that the device stack corresponds to the device that is remote to the server comprises facilitating traversing the device stack downwards to identify a device object corresponding to a virtual bus driver at the bottom of the device stack.
014213. The machine-readable storage medium according to clause 9, wherein the one or more operations further comprises determining whether the device is configured to be provided with access restriction, wherein the attaching the access restriction object comprises:
0143attaching the access restriction object on top of the device stack if the device is configured to be provided with access restriction.
014414. The machine-readable storage medium according to clause 9, wherein the one or more operations are performed without hooking to a kernel module.
014515. The machine-readable storage medium according to clause 9, wherein the device is a USB device.
014616. The machine-readable storage medium according to clause 9, wherein the access request is made by a process of an application, and wherein receiving the access request to the device comprises:
0147intercepting the access request made by the process to the device.
014817. An apparatus (see, e.g., <b>800</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>), comprising:
0149one or more modules configured to perform one or more operations comprising:
0150determining, at a server, that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server (see, e.g., <b>802</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>);
0151attaching a device access restriction object on top of the device stack (see, e.g., <b>804</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>);
0152receiving, at the device access restriction object, an access request to the device (see, e.g., <b>806</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>); and
0153determining, at the device access restriction object, whether the access request is allowed access to the device (see, e.g., <b>808</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>).
015418. The apparatus according to clause 17, wherein the determining whether the access request is allowed access to the device comprises:
0155determining whether a session from which the access request is received is the same as a session of the client; and
0156determining that the access request is allowed if the session from which the access request is received is the same as the session of the client.
015719. The apparatus according to clause 18, wherein the one or more operations further comprises determining that the access request is blocked if the session from which the access request is received is not the same as the session of the client; and
0158generating an error message indicating that the device does not exist.
015920. The apparatus according to clause 17, wherein the determining that the device stack corresponds to the device that is remote to the server comprises facilitating traversing the device stack downwards to identify a device object corresponding to a virtual bus driver at the bottom of the device stack.
016021. The apparatus according to clause 17, wherein the one or more operations further comprises determining whether the device is configured to be provided with access restriction, wherein the attaching the access restriction object comprises:
0161attaching the access restriction object on top of the device stack if the device is configured to be provided with access restriction.
016222. The apparatus according to clause 17, wherein the one or more operations are performed without hooking to a kernel module.
016323. The apparatus according to clause 17, wherein the device is a USB device.
016424. The apparatus according to clause 17, wherein the access request is made by a process of an application, and wherein receiving the access request to the device comprises:
0165intercepting the access request made by the process to the device.
016625. An apparatus (see, e.g., <b>800</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>), comprising:
0167means for determining, at a server, that a device stack corresponds to a device that is remote to the server and is connected locally to a client that is remote to the server; (see, e.g., <b>802</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>)
0168means for attaching a device access restriction object on top of the device stack (see, e.g., <b>804</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>);
0169means for receiving, at the device access restriction object, an access request to the device (see, e.g., <b>806</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>); and
0170means for determining, at the device access restriction object, whether the access request is allowed access to the device (see, e.g., <b>808</b>-C in <figref idref="DRAWINGS">FIG. 8C</figref>).
017126. The apparatus according to clause 25, wherein the means for determining whether the access request is allowed access to the device comprises:
0172means for determining whether a session from which the access request is received is the same as a session of the client; and
0173means for determining that the access request is allowed if the session from which the access request is received is the same as the session of the client.
017427. The apparatus according to clause 26, further comprising means for determining that the access request is blocked if the session from which the access request is received is not the same as the session of the client; and
0175means for generating an error message indicating that the device does not exist.
017628. The apparatus according to clause 25, wherein the means for determining that the device stack corresponds to the device that is remote to the server comprises means for facilitating traversing the device stack downwards to identify a device object corresponding to a virtual bus driver at the bottom of the device stack.
017729. The apparatus according to clause 25, further comprising means for determining whether the device is configured to be provided with access restriction, wherein the means for attaching the access restriction object comprises:
0178means for attaching the access restriction object on top of the device stack if the device is configured to be provided with access restriction.
017930. The apparatus according to clause 25, wherein the means for determining whether the access request is allowed access to the device comprises:
0180means for determining whether the access request is allowed access to the device without hooking to a kernel module.
018131. The apparatus according to clause 25, wherein the device is a USB device.
018232. The apparatus according to clause 25, wherein the access request is made by a process of an application, and wherein the means for receiving the access request to the device comprises:
0183means for intercepting the access request made by the process to the device.
018433. The method, machine-readable storage medium, or apparatus of any of the foregoing clauses, wherein the session is a predetermined session.
0000Other Remarks
0185In one aspect, any of the clauses herein may depend from any one of the independent clauses or any one of the dependent clauses. In one aspect, any of the clauses (e.g., dependent or independent clauses) may be combined with any other clauses (e.g., dependent or independent clauses). In one aspect, a claim may include some or all of the words (e.g., steps, operations, means or components) recited in a clause, a sentence, a phrase or a paragraph. In one aspect, a claim may include some or all of the words recited in one or more clauses, sentences, phrases or paragraphs. In one aspect, some of the words in each of the clauses, sentences, phrases or paragraphs may be removed. In one aspect, additional words or elements may be added to a clause, a sentence, a phrase or a paragraph. In one aspect, the subject technology may be implemented without utilizing some of the components, elements, functions or operations described herein. In one aspect, the subject technology may be implemented utilizing additional components, elements, functions or operations.
0186In one aspect, any methods, instructions, code, means, logic, components, blocks, modules and the like (e.g., software or hardware) described or claimed herein can be represented in drawings (e.g., flow charts, block diagrams), such drawings (regardless of whether explicitly shown or not) are expressly incorporated herein by reference, and such drawings (if not yet explicitly shown) can be added to the disclosure without constituting new matter. For brevity, some (but not necessarily all) of the clauses/descriptions/claims are explicitly represented in drawings, but any of the clauses/descriptions/claims can be represented in drawings in a manner similar to those drawings explicitly shown. For example, a flow chart can be drawn for any of the clauses, sentences or claims for a method such that each operation or step is connected to the next operation or step by an arrow. In another example, a block diagram can be drawn for any of the clauses, sentences or claims having means-for elements (e.g., means for performing an action) such that each means-for element can be represented as a module for element (e.g., a module for performing an action).
0187Those of skill in the art would appreciate that items such as the various illustrative blocks, modules, elements, components, methods, operations, steps, and algorithms described herein (e.g., client <b>102</b><i>a</i>, <b>102</b><i>b</i>, <b>102</b><i>c</i>, server <b>104</b>/<b>304</b>, and the components therein) may be implemented as hardware, computer software, or a combination of both.
0188To illustrate the interchangeability of hardware and software, items such as the various illustrative blocks, modules, elements, components, methods, operations, steps, and algorithms have been described generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application.
0189In one aspect, “means,” a block, a module, an element, a component or a processor may be an item (e.g., one or more of blocks, modules, elements, components or processors) for performing one or more functions or operations. In one aspect, such an item may be an apparatus, hardware, or a portion thereof. In one example, an item may have a structure in the form of, for example, an instruction(s) encoded or stored on a machine-readable medium, on another device, or on a portion thereof. An instruction(s) may be software, an application(s), a subroutine(s), or a portion thereof. The instructions(s) may be for performing the function(s) or operation(s). The instruction(s) may be executable by one or more processors to perform the function(s) or operation(s). One or more processors may execute the instruction(s) by, for example, transferring or copying and instructions into an executable memory space and executing the instructions. In one example, an item may be implemented as one or more circuits configured to perform the function(s) or operation(s). A circuit may include one or more circuits and/or logic. A circuit may be analog and/or digital. A circuit may be electrical and/or optical. A circuit may include transistors. In an example, one or more items may be implemented as a processing system (e.g., a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc.), as a portion(s) of any of the foregoing, or as a combination(s) of any of the foregoing. Those skilled in the art will recognize how to implement the instructions, circuits, and processing systems.
0190In one aspect of the disclosure, when actions or functions (e.g., hooking, modifying, intercepting, redirecting, determining, traversing, obtaining, creating, operating, deleting, removing, receiving, providing, generating, converting, displaying, notifying, accepting, selecting, controlling, transmitting, reporting, sending, or any other action or function) are described as being performed by an item (e.g., one or more of blocks, modules, elements, components or processors), it is understood that such actions or functions may be performed, for example, by the item directly. In another example, when an item is described as performing an action, the item may be understood to perform the action indirectly, for example, by facilitating such an action (e.g., assisting, allowing, enabling, causing, or providing for, such action to occur; or performing a portion of such an action). For example, determining can refer to facilitating determination, attaching can refer to facilitating attaching, and receiving can refer to facilitating receiving. In one aspect, performing an action may refer to performing a portion of the action (e.g., performing a beginning part of the action, performing an end part of the action, or performing a middle portion of the action).
0191A reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” For example, a client may refer to one or more clients, a server may refer to one or more servers, an operation may refer to one or more operations, and a signal, message, or communication may refer to one or more signals, messages, or communications.
0192Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the invention.
0193The word “exemplary” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. In one aspect, various alternative configurations and operations described herein may be considered to be at least equivalent.
0194A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as an “embodiment” does not imply that such embodiment is essential to the subject technology or that such embodiment applies to all configurations of the subject technology. A disclosure relating to an embodiment may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. A phrase such an embodiment may refer to one or more embodiments and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. A phrase such a configuration may refer to one or more configurations and vice versa.
0195In one aspect, unless otherwise stated, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications that are set forth in this specification, including in the claims that follow, are approximate, not exact. In one aspect, they are intended to have a reasonable range that is consistent with the functions to which they relate and with what is customary in the art to which they pertain.
0196In one aspect, the term “coupled” or the like may refer to being directly coupled. In another aspect, the term “coupled” or the like may refer to being indirectly coupled.
0197Terms such as top, bottom, upward, downward and the like, if used in this disclosure, should be understood as referring to an arbitrary frame of orientation. For example, a top according to one orientation may be a bottom or a side in another orientation. Also, a top may be a portion of top layers, if there are multiple layers.
0198Various items may be arranged differently (e.g., arranged in a different order, or partitioned in a different way) all without departing from the scope of the subject technology. In one aspect of the disclosure, the elements recited in the accompanying claims may be performed by one or more modules or sub-modules. For example, a local link creation module and a local link deletion module may be combined into one module. A hook module and an intercept module may be combined into one module. A device identification module and a stack traverse module may be combined into one module. In another example, these modules may be divided into a larger number of modules.
0199It is understood that the specific order or hierarchy of steps, operations or processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps, operations or processes may be rearranged. Some of the steps, operations or processes may be performed simultaneously. Some or all of the steps, operations, or processes may be performed automatically, without the intervention of a user. The accompanying method claims, if any, present elements of the various steps, operations or processes in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
0200The disclosure is provided to enable any person skilled in the art to practice the various aspects described herein. The disclosure provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects.
0201All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. §112, sixth paragraph, unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.” Furthermore, to the extent that the term “include,” “have,” or the like is used, such term is intended to be inclusive in a manner similar to the term “comprise” as “comprise” is interpreted when employed as a transitional word in a claim.
0202The Title, Background, Summary, Brief Description of the Drawings and Abstract of the disclosure are hereby incorporated into the disclosure and are provided as illustrative examples of the disclosure, not as restrictive descriptions. It is submitted with the understanding that they will not be used to limit the scope or meaning of the claims. In addition, in the Detailed Description, it can be seen that the description provides illustrative examples and the various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed configuration or operation. The following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
0203The claims are not intended to be limited to the aspects described herein, but are to be accorded the full scope consistent with the language claims and to encompass all legal equivalents. Notwithstanding, none of the claims are intended to embrace subject matter that fails to satisfy the requirement of 35 U.S.C. §101, 102, or 103, nor should they be interpreted in such a way. Any unintended embracement of such subject matter is hereby disclaimed.
Contents6
15 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US10387182B2 | Cited by | United States of America | Search report |
| US2002002616A1 | Cites | United States of America | Search report |
| US2002133487A1 | Cites | United States of America | Search report |
| US2003046366A1 | Cites | United States of America | Search report |
| US2003088727A1 | Cites | United States of America | Search report |
| US2004039969A1 | Cites | United States of America | Search report |
| US2005172094A1 | Cites | United States of America | Search report |
| US2007047524A1 | Cites | United States of America | Search report |
| US2010198924A1 | Cites | United States of America | Search report |
| US2011004753A1 | Cites | United States of America | Search report |
| US2011167242A1 | Cites | United States of America | Search report |
| US2012081213A1 | Cites | United States of America | Search report |
| US2012084184A1 | Cites | United States of America | Search report |
| US2012303771A1 | Cites | United States of America | Search report |
| US2012317237A1 | Cites | United States of America | Search report |
| US6421055B1 | Cites | United States of America | Search report |
| US7577838B1 | Cites | United States of America | Search report |
| US7783788B1 | Cites | United States of America | Search report |
| US20020002616A1 | Cites | United States of America | Search report |
| US20020133487A1 | Cites | United States of America | Search report |
| US20030046366A1 | Cites | United States of America | Search report |
| US20030088727A1 | Cites | United States of America | Search report |
| US20040039969A1 | Cites | United States of America | Search report |
| US20050172094A1 | Cites | United States of America | Search report |
| US20070047524A1 | Cites | United States of America | Search report |
| US20100198924A1 | Cites | United States of America | Search report |
| US20110004753A1 | Cites | United States of America | Search report |
| US20110167242A1 | Cites | United States of America | Search report |
| US20120081213A1 | Cites | United States of America | Search report |
| US20120084184A1 | Cites | United States of America | Search report |
| US20120303771A1 | Cites | United States of America | Search report |
| US20120317237A1 | Cites | United States of America | Search report |
| Non-Final Office Action issued in U.S. Appl. No. 13/651,321; 25 pages, Feb. 28, 2014. | Non-patent | – | Applicant |
| Final Office Action issued in U.S. Appl. No. 13/651,321; 22 pages, Jul. 24, 2014. | Non-patent | – | Applicant |
| Notice of Allowance issued in U.S. Appl. No. 13/651,321; 37 pages, Nov. 14, 2014. | Non-patent | – | Applicant |
| Non-Final Office Action issued in U.S. Appl. No. 13/651,321; 25 pages, Feb. 28, 2014. | Non-patent | – | Applicant |
| Final Office Action issued in U.S. Appl. No. 13/651,321; 22 pages, Jul. 24, 2014. | Non-patent | – | Applicant |
| Notice of Allowance issued in U.S. Appl. No. 13/651,321; 37 pages, Nov. 14, 2014. | Non-patent | – | Applicant |
4 members in 1 office
Priority claims1
| Document | Office | Kind | Date |
|---|---|---|---|
| 201261643807 | United States of America | P |
Members4
| Document | Office | Kind | |
|---|---|---|---|
| US2013297792A1 | United States of America | A1 | |
| US2013297813A1 | United States of America | A1 | |
| US8990394B2 | United States of America | B2 | |
| US9479598B2This record | United States of America | B2 |
70 transactions on the USPTO file
Allowed after 2 non-final rejections, 1 final rejection and 1 RCE.
- Non-final rejections
- 2
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 8th Year, Large EntityM1552 | M1552 | |
| Payment of Maintenance Fee, 4th Year, Large EntityM1551 | M1551 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Email NotificationEML_NTR | EML_NTR | |
| Mailing Corrected Notice of AllowabilityMCNOA | MCNOA | |
| Reasons for AllowanceEX.R | EX.R | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Corrected Notice of AllowabilityCNOA | CNOA | |
| Interview Summary - Examiner Initiated - TelephonicEXET | EXET | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Reasons for AllowanceEX.R | EX.R | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Paralegal or electronic terminal disclaimer approvedP574 | P574 | |
| Terminal Disclaimer FiledDIST | DIST | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Correspondence Address ChangeC.ADB | C.ADB | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Email NotificationEML_NTR | EML_NTR | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Application Is Now CompleteCOMP | COMP | |
| Email NotificationEML_NTR | EML_NTR | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Sent to Classification ContractorPGPC | PGPC | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Applicants have given acceptable permission for participating foreignAPPERMS | APPERMS | |
| Initial Exam Team nnIEXX | IEXX |
115 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication
- 9479598
- Application
- 13651318
Titles
- English
- System and method for providing session-level access management of a redirected device
Patent term adjustment
- A delay
- +342 daysthe office missed an examination deadline
- B delay
- +181 dayspendency past three years
- Applicant delay
- −203 days
- Net adjustment
- 320 days
Classification
- CPC, 3
- H04L67/146
- H04L63/10
- H04L67/42
- IPC, 3
- G06F15 16
- H04L29 06
- H04L29 08