Patent Application
20070294626
A facility is described for controlling application sharing. In various embodiments, the facility enables a user to request control of an application that is shared during an application sharing session and provides control to the requesting user at an appropriate time without intervention by the sharer. In various embodiments, users (e.g., participants or the sharer) can request control of the application by providing input to their computing devices, such as by clicking a mouse button or typing, moving a mouse pointer, selecting an option to request control, or providing some other indication to request control. As an example, a user can select an option in an application sharing software running on a viewer computing device, depressing a mouse button or typing while a mouse pointer or cursor is in the application sharing software or shared application, and so forth. The facility may then provide control of the shared application to the requesting user. Once a user's computing device receives control, that user becomes the “controller” of the application even though the application is shared by a sharer computing device. The controller can then control the shared application even though the shared application executes on a sharer computer device. A computing device can request control by sending a request control message to the sharer computing device or a sharing server, collectively referred to as an “arbiter.” A sharing server provides various services to an application sharing session, such as a directory of users or computing devices, message transmission and redirection, and so forth. The arbiter, which is a component of application sharing software, may store arriving request control messages, which identify the requesting computing device or requesting user, in a queue of control requests. The arbiter may then provide control to a requesting computing device when the controller relinquishes control. The controller can relinquish control either actively or passively. As examples, the controller can actively relinquish control by selecting an option or can passively relinquish control by failing to provide any input (e.g., via mouse, keyboard, voice, etc.) for a defined period of time, such as two seconds.
The arbiter can select a computing device that will receive control on a first-in-first-out basis or some other manner, such as by using a priority. As an example, the sharer or a particular participant (e.g., manager of a group of people or presenter of a presentation) may receive priority over other participants so that a participant with higher priority receives control before a participant with lower priority even though the participant with lower priority requested control first. Once the arbiter selects a computing device that is to be provided control, it can notify computing devices participating in the application sharing session, such as by sending an indication of the selected computing device in a controller change message. Upon receiving the controller change message from the arbiter, the computing devices can indicate to their users (e.g., sharer and participants) that a new controller has control of the application sharing session. Thus, by enabling users to request and take control without intervention of a sharer, application sharing becomes more collaborative because collaboration does not need to be paused so that the sharer can reconfigure application sharing by explicitly revoking control from one participant to grant it to another participant.
In various embodiments, the sharer can indicate whether participants can take control. As an example, when the sharer indicates that no participant can take control, control requests that participants send can either be ignored or handled manually by the sharer. Alternatively, the participants may receive an error message. In various embodiments, the facility can enable some participants to take control but not others. As an example, the sharer can indicate that only identified participants should be able to take control, such as participants having one or more “roles.” Then, when a participant who is not identified requests control, the facility can automatically deny that participant's request or can enable the sharer to manually provide control to that participant. As examples, a participant having a “presenter” role may be able to take control, but a participant having an “attendee” role may not be able to do so. In some embodiments, participants that are not identified as being able to request control may even be unable to make a request for control.
In various embodiments, the application sharing software's user interface can indicate who has control, who the sharer is, and so forth. The user interface may provide an indication that the controller is changing.
In various embodiments, a controller can explicitly yield control to another user or can return control to a prior controller. As an example, if a first participant takes control from a sharer and then a second participant takes control from the first participant, the arbiter may return control to the first participant when the second participant becomes inactive for a defined period of time and then to the sharer when the first participant becomes inactive. In various embodiments, the facility may transfer control from the second participant to the sharer. In various embodiments, the facility may provide control to a user providing input regardless of whether the active controller pauses for a defined amount of time.
In various embodiments, when the sharer provides input while a participant has control, the facility revokes control from the participant and provides it to the sharer. The participant (or viewer computing device) is identified in the queue as requesting control so that when the sharer relinquishes control, control is given to that participant who was previously the controller.
In various embodiments, the request control or controller change messages can identify a user rather than or in addition to identifying the computing device.
Turning now to the figures,
The sharer computing device shares applications or documents with viewer computing devices so that an application or document that the sharer computing device displays is also displayed by the viewer computing devices. The viewer computing devices and the sharer computing device can participate in an application sharing session that is associated with an application sharing software.
The sharing server is a computer that provides additional services to the application sharing session, such as a directory of users and computing devices that are capable of participating in an application sharing session. The sharing server can also select one of several requesting participants to receive control.
A system for implementing the facility includes a general purpose computing device (“computer”). Components of the computer may include, but are not limited to, a processing unit, a system primary memory, a storage device, a network adapter or interface, a display, and input and output devices.
Computers typically include a variety of computer-readable media that are operable with storage devices connected thereto. Computer-readable media can be any available media that can be accessed by the computer and include both volatile and nonvolatile media and removable and nonremovable media.
The computer may operate in a networked environment using logical connections to one or more remote computers. A remote computer may be a personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above in relation to the computer. A logical connection can be made via a local area network (LAN) or a wide area network (WAN), but may also include other networks. Such networking environments are commonplace in homes, offices, enterprisewide computer networks, intranets, and the Internet. The computer can be connected to a network through a network interface or adapter, such as to a wired or wireless network.
The computer is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the facility. Neither should the computing system be interpreted as having any dependency or requirement relating to any one or a combination of the illustrated components.
The facility is operational with numerous other general purpose or special purpose computing systems or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the facility include, but are not limited to, personal computers, server computers, handheld or laptop devices, cellular telephones, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The facility may be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. The facility may also be employed in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media, including memory storage devices.
While various functionalities and data are shown in the figures as residing on particular computer systems that are arranged in a particular way, those skilled in the art will appreciate that such functionalities and data may be distributed in various other ways across computer systems in different arrangements. While computer systems configured as described above are typically used to support the operation of the facility, one of ordinary skill in the art will appreciate that the facility may be implemented using devices of various types and configurations, and having various components.
The techniques may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
The sharing region also includes a control region 213 to enable the user to select a controller of the sharing session. As an example, the user can select a drop-down control region 216 to display a list of participants that the user can select. An identification of the selected controller would then appear in region 214. In various embodiments, the drop-down control region may indicate the participants that have requested control.
The shared application region 204 can include some or all portions of a shared application, such as a menu region 218, such as a menu provided by the shared application.
At block 504, the routine receives an indication from the user to take control of the shared application. The user may provide the indication by clicking a mouse button, selecting an option or command, typing, and so forth. The user may indicate to take control when, for example, the user desires to manipulate the shared application or document so that other participants and the sharer can readily identify actions the user desires to take.
At block 506, the routine sends a message to the sharer computing device requesting control. The message can include an identity of the user or the user's computing device.
At block 508, the routine returns.
At block 604, the routine receives a message requesting control and identifying the requester. The identification of the requester may include an identity of the requesting user, the requesting user's computing device, or both.
At block 606, the routine adds an indication of the control request to the queue. The indication can also include the received identification of the requester.
At block 608, the routine returns.
At block 704, the routine determines whether there are any pending control requests in the queue. When there are pending control requests in the queue, the routine continues at block 706. Otherwise, the routine either returns to block 704 when the routine is performed in an endless loop, or returns so that it can be invoked again later.
At block 706, the routine retrieves a pending control request from the queue. The control request can also include an identification of the requester that requested to take control. In various embodiments, the facility retrieves the control request in a first-in-first-out, last-in-first-out, random, or some other basis. In various embodiments in which priority is assigned to the incoming control requests (e.g., based on the identity of the requester), the facility may retrieve the highest priority control request from the queue.
At block 708, the routine selects the computing device identified in the control request as the next controller. In various embodiments, the routine may select the user or computing device identified in the control request as the next controller.
At block 710, the routine invokes a handle_control subroutine. The routine may provide the identification of the requester to the subroutine.
At block 804, the routine determines whether input has been received from the controller. Input can include keyboard, mouse, voice, or other input that a user is capable of providing to a computing device. When the controller has provided input, the routine continues at block 806. Otherwise, the routine continues at block 808. The routine is able to distinguish input provided by a controller from input provided by the sharer by using low-level operating system hooks, such as WH_KEYBOARD, WH_KEYBOARD_LL, WH_MOUSE, and WH_MOUSE_LL hooks available in the MICROSOFT WINDOWS operating system. By integrating with these operating system hooks, the facility can determine whether the mouse and keyboard input was provided locally (e.g., by the sharer) or remotely (e.g., by the controller). The facility can distinguish who provided the input so that it can revoke control when the controller provides no input prior to a defined timeout.
At block 806, the routine processes the received input. As an example, the routine can provide the received input to the shared application.
At block 808, the routine determines whether a timeout has been exceeded. The timeout can be a defined period of time, such as two seconds. This period of time can be predetermined or can be configured by a user, such as an administrator or the sharer. If the timeout has been exceeded, the routine continues at block 810. Otherwise, the routine continues at block 804. Thus, when the timeout has not been exceeded, the routine continues to process input received from the controller, and the timeout is reset.
At block 810, the routine determines whether there are any pending control requests in the queue. When there are no further pending requests, the routine continues at block 804. Otherwise, the routine continues at block 812. Thus, even though the timeout may have been exceeded, control does not need to transfer to another user unless a control request is pending.
At block 812, the routine returns.
Those skilled in the art will appreciate that the steps shown in
The sharing server sends two control requested messages to the sharer computing device, such as messages 916 and 918. The control requested messages include the identities of the viewer computing devices that sent the request control messages. The sharer computing device adds indications of the received control requests to a queue 910, such as using operations 920 and 922.
The sharer retrieves 924 the next control request from the queue. The next control message can be the oldest message or a priority message that is stored in the queue. In the illustrated embodiment, the request control message received from viewer computing device 906, having identity 2, is the next control request.
The sharer computing device then sends 926 a set controller message identifying the identity of the next controller (e.g., 2) to the sharing server. The sharing server then sends a controller change message to all viewer computing devices participating in the application sharing session, such as messages 928 and 930. Thus, all viewer computing devices participating in the application sharing session are informed of the controller change.
In various embodiments, the sharer computing device can receive and send messages in lieu of the sharing server.
Viewer computing device 906, which is presently controlling the application sharing session, sends 1002 mouse and keyboard messages to the sharing server. The sharing server may then forward 1004 the received mouse and keyboard messages to the sharer computing device.
The sharer computing device may detect that the controller has not sent any input messages within a defined period of time so that an inactivity timeout 1006 has occurred. When this occurs, the sharer computing device retrieves 1008 the next control request from the queue. The sharer computing device then sets the controller (e.g., having identity 3) by sending 1010 a set controller message to the sharing server. The sharing server may then send a controller change message identifying the new controller (e.g., having identity 3) to viewer computing devices participating in the application sharing session, such as messages 1012 and 1014. Thus, the viewer computing devices participating in the application sharing session are informed of the new controller's identity.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. As an example, the facility can determine which of multiple requesting participants should receive control in various ways, such as round robin, time limits, or specific to each participant or the participants' use. In various embodiments, an installed or configured component can be provided that has arbitrary algorithms for selecting a participant. In some embodiments, control may return to a selected user after a defined period of time. In various embodiments, the arbiter can be distributed so that, for example, it can operate at participant computing devices. The specific features and acts described above are disclosed as example forms of implementing the claims. Accordingly, the invention is not limited except as by the appended claims.
