Patent Publication Number: US-10778656-B2

Title: Sharing resources across multiple devices in online meetings

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a Continuation of U.S. application Ser. No. 14/460,143, filed on Aug. 14, 2014, the contents of which are herein incorporated by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The present disclosure relates generally to improved solutions for sharing resources such as an application, a user environment, or a file in online meetings, and in particular for controlling, from a primary device in an online meeting, one or more secondary devices to share resources of those secondary devices with other participants of the online meeting. 
     BACKGROUND 
     Online meetings serviced by online meeting platforms, such as WebEx® of Cisco Systems, Inc. of San Jose, Calif., have revolutionized the way people share information with each other by allowing users located in geographically dispersed locations to remotely connect to each other and simultaneously communicate through text, audio, and/or video. Sometimes it may be beneficial for a user to connect to a meeting from more than one device. For example, a user may wish to communicate with other meeting participants from her mobile device because of the convenience and mobility that the mobile device offers, but may also want to share information from her desktop computer because her desktop computer offers superior computing power and storage capability. In addition, some resources might only be available on the user&#39;s other devices. 
     However, traditional online meeting solutions do not offer a good way to join an online meeting from more than one device. Moreover, when an additional device belonging to an existing user joins a meeting, the newly added device typically shows up in the participant roster as belonging to a separate and independent user account. This can be often confusing to other meeting participants because it may be difficult for them to identify which one of the multiple devices needs to be engaged when addressing the user behind those multiple devices. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Certain features of the subject technology are set forth in the appended claims. However, the accompanying drawings, which are included to provide further understanding, illustrate disclosed aspects and together with the description serve to explain the principles of the subject technology. In the drawings: 
         FIG. 1  illustrates an example network device; 
         FIG. 2  illustrates an example system embodiment; 
         FIG. 3  illustrates exemplary devices participating in an online meeting; 
         FIG. 4  illustrates generation of exemplary authentication keys; 
         FIGS. 5A-5C  illustrate exemplary participant rosters as displayed on the devices; 
         FIG. 6  illustrates an example of a user interface for sharing a resource; 
         FIG. 7  illustrates an example of resource sharing among devices; 
         FIG. 8  illustrates an example sequence diagram for sharing resources among devices; 
         FIG. 9  illustrates an example method for sharing a resource in an online meeting; 
         FIG. 10  illustrates another example method for sharing a resource in an online meeting; and 
         FIG. 11  illustrates yet another example method for sharing a resource in an online meeting. 
     
    
    
     DESCRIPTION OF EXAMPLE EMBODIMENTS 
     Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure. 
     Overview 
     A system, method, and computer-readable storage devices are disclosed which address the issues raised above regarding sharing contents of a different device in an online meeting. The various embodiments disclosed herein can allow a user to connect to an online meeting server with more than one device at a time and designate one of those devices as the primary device that can establish a control session over any of the user&#39;s secondary devices. Once the control session is established, the primary device can take full or partial control of the secondary device(s), obtain a list of resources, such as applications, desktop environments, contents, etc., available on the secondary device(s), and/or share one or more of those resources of the secondary device(s) with other participants in the meeting. In addition, the user may move from one device to another device at any time to designate the new active device as the primary device. 
     Moreover, multiple devices belonging to one user can be hidden from the other users&#39; view. In other words, from the perspectives of the other users, more than one device that a user may be using to connect to the meeting may simply appear as one device under one user account rather than multiple devices under separate user accounts. Alternatively, the multiple devices can appear as though they are collapsed or consolidated into a single device. 
     In certain aspects, a client device may log into an online meeting service and the server identifies and verifies the user using a security token. When the user joins the meeting, the client device may receive a public-private key pair from the server. The server can identify any other client devices with the same public key that join the meeting as belonging to the same user. The user can use one of the devices to establish a control session with the other devices using the key pair. Once the control session is established, the device that the user is actively using can be designated as the primary device. The primary device may share applications, desktop environments, and other resources that are available on the controlled device(s). 
     In some embodiments, a server can receive from a first client device a command for a second client device to share a resource with a third client device. The first client device, the second client device, and the third device may be participating in an online meeting that is managed by the server. In particular, the first client device and the second device may respectively be the primary device and the secondary device associated with a first user, and the third client device may be associated with a second user. 
     Description 
     The 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 can 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 more thorough understanding of the subject technology. However, it will be clear and apparent that the subject technology is not limited to the specific details set forth herein and may be practiced without these details. In some instances, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology. 
     A computer network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end nodes, such as personal computers and workstations. Many types of networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect the nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), or synchronous digital hierarchy (SDH) links. 
     The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol consists of a set of rules defining how the nodes interact with each other. Computer networks may be further interconnected by an intermediate network node, such as a router, to extend the effective “size” of each network. 
     An online meeting is a service that allows two or more users in disparate or remote locations communicate with each other substantially in real time by simultaneously or sequentially exchanging streams of data including text, audio, video, images, animations, documents, etc. among the participating client devices. For instance, participants in the online meeting can host a live event such as an audio chat session, a video chat session, a slideshow presentation, a virtual whiteboard presentation, etc. and/or share a local resource such as a document, a picture, a recording, a video, etc. 
     Online meetings are typically made possible by the Internet and other network technologies and standards such as the TCP/IP. Online meetings can be conducted on a point-to-point basis or via multicast. Online meetings can be initiated/managed/mediated by a server, to whom various client devices may connect in order to participate in a meeting. The client devices, and hence their respective users, may be situated across geographically dispersed locations. For instance, online meetings enable users that are located in different cities, different states, or even different countries to conduct a virtual meeting over the Internet in real time. The client devices can be equipped with various hardware and software components to facilitate participation in the online meetings. For example, a client device may have hardware components such as one or more processors, a memory, one or more network interfaces, one or more input devices (e.g., a mouse, a keyboard, a keypad, a touchscreen, a microphone, a loudspeaker, a camera), one or more output devices (e.g., a display, a speaker), a storage, etc. The client device may have various software components that enable it to connect to the server. The client device may use stand-alone conferencing software that runs on an operating system to accomplish this. Alternatively, the client device may allow its user to use a web-based solution that runs inside a web browser to participate in meetings. 
     Even though the term “online meeting” is used throughout this disclosure, the utility of the online meetings is not strictly limited to conducting meetings. Rather, online meetings can be used for many other purposes such as conducting presentations, training sessions, lectures, discussions, broadcast events, etc. In addition, other terms such as a web meeting, an online conference, a web conference, a video conference, an interactive conference, a webinar, an online workshop, a remote meeting, a remote conference, a virtual meeting, a virtual conference, etc. or any combination thereof may be used interchangeably. 
     A “resource,” as used throughout this disclosure, may mean any information or data that may be stored or represented in a client device. A resource can be a collection of data bits. A resource can be a file. In some embodiments, a resource can be a text, an audio, a video, a document, a code, a script, or instructions. In other embodiments, a resource can be an application, a dialogue box, a prompt, or a user interface element. In yet other embodiments, a resource can be a desktop environment, a system environment, or a user interface (UI). A resource on one device may be shared on a different device. For example, a finance app running on a desktop computer can be shared on a separate mobile device, from which the app may be viewed, manipulated, and/or interacted with. 
     A “desktop environment” is a visual metaphor employed in computer operating systems (OS) for their users to interact with the underlying data structure. For example, on a Windows® OS, files and folders are represented by icons that are arranged inside a “desktop” space in a graphical user interface (GUI). Various applications and UI elements such as buttons, menus, boxes, bars, panes, icons, input indicator (e.g., mouse pointer, touch indicator, button press indicator, etc.), text can be overlaid on top of the desktop to represent other resources and information. The term “desktop” or “desktop environment” may include any or all of these UI elements that are visible via the GUI to a user. Thus, when a desktop environment of a desktop computer is shared on a mobile device, for example, the user of the mobile device may be able to view some or all of what is displayed on the desktop computer&#39;s user interface such as UI elements, applications, etc. Furthermore, the user may use the mobile device to interact with the various UI elements and/or apps on the desktop computer. Thus, by sharing one client device&#39;s entire desktop environment, what is displayed on a screen of that client device along with its user interface can be substantially duplicated or mirrored onto another client device. 
     A system environment of a client device that does not employ a desktop metaphor can be also shared with other client devices. For example, a smartphone or a tablet device may not rely on traditional desktop environments that are widely used in desktop or laptop computers. However, one of skill in the art will understand that the system environments of such devices including their user interfaces and/or user experiences (UX) may also be shared, duplicated, or mirrored onto other client devices. 
     A “key,” as used throughout this disclosure, may mean a piece of information such as a hexadecimal number used in public-key cryptography or asymmetric cryptography. In public-key cryptography, two separate keys—a public key and a private key—may be generated by one or more mathematical formulas such that the public key may be used for encrypting data and verifying a digital signature while the private key may be used for decrypting data and creating a digital signature. 
     The disclosed technology addresses the need in the art for providing effective means for sharing resources using multiple client devices. Disclosed are methods, systems, and computer-readable storage media for sharing resources in online meetings. A brief introductory description of exemplary systems, as illustrated in  FIGS. 1 and 2 , is disclosed herein. A detailed description of an online meeting server, various client devices, components, and exemplary variations, will then follow. These variations shall be described herein as the various embodiments are set forth. The disclosure now turns to  FIG. 1 . 
       FIG. 1  illustrates an exemplary network device  110  suitable for implementing the present invention. Network device  110  includes master central processing unit (CPU)  162 , interfaces  168 , and bus  115  (e.g., a PCI bus). When acting under the control of appropriate software or firmware, CPU  162  is responsible for executing packet management, error detection, and/or routing functions, such as miscabling detection functions, for example. CPU  162  preferably accomplishes all these functions under the control of software including an operating system and any appropriate applications software. CPU  162  may include one or more processors  163  such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In some alternative embodiments, processor  163  is specially designed hardware for controlling the operations of router  110 . In some embodiments, a memory  161  (such as non-volatile RAM and/or ROM) also forms part of CPU  162 . However, there are many different ways in which memory could be coupled to the system. 
     Interfaces  168  are typically provided as interface cards (sometimes referred to as “line cards”). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with router  110 . Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow master microprocessor  162  to efficiently perform routing computations, network diagnostics, security functions, etc. 
     Although the system shown in  FIG. 1  is one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the router. 
     Regardless of the network device&#39;s configuration, it may employ one or more memories or memory modules (including memory  161 ) configured to store program instructions for the general-purpose network operations and mechanisms for roaming, route optimization and routing functions described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The memory or memories may also be configured to store tables such as mobility binding, registration, and association tables, etc. 
       FIG. 2  illustrates an example of an electronic system with which some aspects of the subject technology can be implemented. As illustrated, system  200  includes a general-purpose computing device  200 , including central processing unit (CPU or processor)  220  and system bus  210  that couples various system components including system memory  230  such as read only memory (ROM)  240  and random access memory (RAM)  250  to processor  220 . System  200  can include a cache  222  of high speed memory connected directly with, in close proximity to, or integrated as part of processor  220 . System  200  copies data from memory  230  and/or storage device  260  to cache  222  for quick access by processor  220 . In this way, cache  222  provides a performance boost that avoids processor  220  delays while waiting for data. These and other modules can control or be configured to control processor  220  to perform various actions. Other system memory  230  may be available for use as well. Memory  230  can include multiple different types of memory with different performance characteristics. It can be appreciated that the disclosure may operate on computing device  200  which includes more than one processor  220  or on a group or cluster of computing devices networked together to provide greater processing capability. 
     Processor  220  can include any general purpose processor and a hardware module or software module, such as module 1 ( 262 ), module 2 ( 264 ), and module 3 ( 266 ) stored in storage device  260 , configured to control processor  220  as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor  220  may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric. 
     System bus  210  may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM  240  or the like, can provide basic routines that help to transfer information between elements within computing device  200 , such as during start-up. Computing device  200  can further include storage devices  260  such as a hard disk drive, a magnetic disk drive, an optical disk drive, tape drive or the like. Storage device  260  can include one or more software modules  262 ,  264 ,  266  for controlling the processor  220 . Storage device  260  is connected to system bus  210  by a drive interface. The drives and the associated computer readable storage media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for computing device  200 . 
     In some aspects, a hardware module that performs a particular function includes the software component stored in a non-transitory computer-readable medium in connection with the necessary hardware components, such as processor  220 , bus  210  and so forth, to carry out the function. The basic components are known to those of skill in the art and appropriate variations are contemplated depending on the type of device, such as whether the device  200  is a handheld computing device, such as a smart phone, or larger computing device, such as a desktop computer, or a computer server. 
     By way of example, processor  220  can be configured to execute operations to receive a command for a client device to share a resource with another client device, forward the command, receive data associated with the resource, forward the data, etc. 
     Although the exemplary embodiment described herein employs storage device  260 , it should be appreciated by those skilled in the art that other types of computer-readable media or devices which can store data that are accessible by a computer, such as magnetic cassettes, magnetic hard disks, flash memory cards, solid-state drives, digital versatile disks, cartridges, random access memories (RAMs)  250 , read only memory (ROM)  240 , a cable or wireless signal containing a bit stream and the like, may also be used in the exemplary operating environment. Non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and transitory signals per se. Storage device  260  may store instructions which, when executed by processor  220 , can cause processor  220  to perform and implement various embodiments set forth herein. 
     To enable user interaction with the computing device  200 , an input device  290  represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, a camera, speech and so forth. An output device  270  can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device  200 . The communications interface  280  generally governs and manages the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed. 
     System  200  can be a server that prepares, initiates, mediates, and/or conduct online meetings. Alternatively, system  200  can be a client device, such as a desktop computer, a laptop computer, a tablet device, a telephone, a smartphone, a Voice-over-Internet Protocol (VoIP) phone, a mobile device, etc. that a user may use to participate in an online meeting. 
     For clarity of explanation, the illustrative system embodiment is presented as including individual functional blocks including functional blocks labeled as a “processor” or processor  220 . The functions these blocks represent may be provided through the use of either shared or dedicated hardware, including, but not limited to, hardware capable of executing software and hardware, such as a processor  220 , that is purpose-built to operate as an equivalent to software executing on a general purpose processor. For example, the functions of one or more processors may be provided by a single shared processor or multiple processors. (Use of the term “processor” should not be construed to refer exclusively to hardware capable of executing software.) Illustrative embodiments may include microprocessor and/or digital signal processor (DSP) hardware, read-only memory (ROM)  240  for storing software performing the operations discussed below, and random access memory (RAM)  250  for storing results. Very large scale integration (VLSI) hardware embodiments, as well as custom VLSI circuitry in combination with a general purpose DSP circuit, may also be provided. 
     The logical operations of the various embodiments are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a general use computer, (2) a sequence of computer implemented steps, operations, or procedures running on a specific-use programmable circuit; and/or (3) interconnected machine modules or program engines within the programmable circuits. The system  200  can practice all or part of the recited methods, can be a part of the recited systems, and/or can operate according to instructions in the recited non-transitory computer-readable storage media. Such logical operations can be implemented as modules configured to control the processor  220  to perform particular functions according to the programming of the module. 
     For example,  FIG. 2  illustrates three modules Mod1 ( 262 ), Mod2 ( 264 ), and Mod3 ( 266 ) that are modules configured to control the processor  220 . These modules may be stored on the storage device  260  and loaded into RAM  250  or memory  230  at runtime or may be stored as would be known in the art in other computer-readable memory locations. 
       FIG. 3  illustrates exemplary devices participating in an online meeting. Exemplary online meeting session  300  is being managed by server  302 , to whom various client devices  306 A-F (collectively “ 306 ”) may connect in order to participate in online meeting session  300 . Server  302  may allow various clients  306  with diverse form factors, manufacturers, platforms, operating systems, communication protocols, versions, computing powers, etc. to join in online meeting session  300 . Server  302  may consist of multiple servers, some of which can be distributed in physically remote locations from each other. Client devices  306  can communicate with one or more servers  302  or with each other via point-to-point or broadcast communication. Client devices  306  can be any device that is capable of communicating with a remote device and conducting an online meeting session. Client devices  306  can be, for example, a network device, a computer (e.g., a desktop computer, a laptop computer, a handheld computer, a wearable computer), a tablet device, a telephone, a Session Initiation Protocol(SIP)-enabled VoIP telephone, a video phone, a conference hub, a smartphone, or a mobile device. Each of client devices  306  can connect to server  302  via various types of networks (not shown) such as LANs, WANs, virtual private networks (VPNs), the Internet, etc. Client devices  306  may be also connected to each other directly (not shown) via various types of networks, without having to go through server  302 . For example, client device  306 C can issue commands directly to client devices  306 A and  306 B without the help of server  302 . Similarly, in some embodiments, a data stream from client device  306 A can circumvent server  302  and be transmitted directly to client device  306 E. 
     Exemplary users Alice  304 A, Bob  304 B, and Carol  304 C (collectively “ 304 ”) are three participants in online meeting session  300 . Although exemplary online meeting session  300  is depicted as having three users  304 , an online meeting may have any number of users or no users at all. Each user  304  may participate in online meeting  300  using one or more client devices  306 . For example, Alice  304 A may use desktop computer  306 A equipped with Windows® operating system, laptop computer  306 B equipped with Mac OS®, and an Android® KitKat®-equipped smartphone  306 C. Meanwhile, user Bob  304  may choose to participate in online meeting session  300  on his iPad® tablet device  306 D with iOS® version 7.1.2 and his iPhone® smartphone  306 E with iOS® version 6.2. Meanwhile, user Carol  304 C may join in online meeting  300  on her office desk telephone  306 F with video conferencing capability. Client devices  306  can be equipped with various sensors, peripheral devices, and/or features that facilitate online conferencing such as a still camera, a video camera, a microphone, a display screen, a loudspeaker, a GUI, a voice recognizer, a text-to-speech converter, an input device (e.g., a mouse, a keyboard, a keypad, a touch sensor, a motion sensor), etc. 
     Each user  304  may be assigned a single user account and its associated username and password. The user account can be assigned and maintained by server  302 . Alternatively, each client device may be assigned a separate username. In other words, Alice  304 A, Bob  304 B, and Carol  304 C may be provided with three usernames, two usernames, and one username, respectively, with one username per client device. Server  302  may store other relevant user information with a corresponding user account. Notably, server  302  may keep track of client devices  306 D,  306 E that Bob  304 B is known to use to connect to online meeting  300 . For example, server  302  can store the device identifiers (e.g., serial numbers, model numbers, network addresses, etc.) of all the client devices that may attempt to connect to server  302  and associate them with corresponding users  304 . Additionally, server  302  may authenticate client devices  306  and/or their users  304  when establishing a connection to them and before allowing them to participate in online meeting  300 . 
     Users  304  can use one or more of their devices concurrently to participate in online session  300 . As an illustration, user Alice  304 A can join online session  300  by logging into server  302  on her office desktop PC  306 A. She then moves away from her desktop to rejoin online session  300  on her laptop PC  306 B while her desktop PC  306 A is still connected to server  302 . Subsequently, she comes home with her laptop computer  306 B and continues to participate in online meeting  300 . She may also use her smartphone  306 C to connect to server  302  to join online meeting  300 . Each time she moves from one client device to another client device, the device that she is currently and actively using may be considered an “active” client device, and server  302  can designate such device as the active or primary client device for user Alice  304 A. Other client devices belonging to user Alice  304 A but currently not being actively used by Alice  304 A then may be designated secondary client devices. In the above example, Alice&#39;s  304 A first primary device was her desktop computer  306 A. When she connects to server  302  on her laptop computer  306 B, her desktop computer  306 A becomes secondary and laptop computer  306 B becomes her new primary client device. Finally, once Alice  304 A uses her smartphone  306 C to join online meeting  300 , smartphone  306 C becomes the new primary client device and desktop PC  306 A and laptop PC  306 B both become secondary client devices. 
     Users  304  may use his or her primary client device to establish a control session over one or more secondary devices and share various resources that are available on the secondary device(s) with client devices of other users. In the example given above, after arriving at home, Alice  304 A may want to share an application that is currently running on her office desktop computer  306 A with her colleagues Bob  304 B and Carol  304 C. Since she is at a remote location (i.e., home) she cannot access her office computer  306 A physically. However, using her laptop computer  306 B or her smartphone  306 C as her primary client device, she can establish a control session over office computer  306 A via server  302  and share the application running on office computer  306 A with Bob&#39;s  304 B client devices  306 D,  306 E, and/or Carol&#39;s  304 C client device  306 F. Various embodiments for sharing resources on other client devices will be discussed in further detail below. 
       FIG. 4  illustrates generation of exemplary authentication keys. Desktop computer  306 A, laptop computer  306 B, and smartphone  306 C are exemplary client devices used by exemplary user Alice  304 A, as illustrated in  FIG. 3 . In order for server  302  to authenticate the identities of user Alice  304 A and/or any client device  306  that purports to belong to Alice  304 A, server  302  may issue a key pair that consists of a public key and a private key to a trusted client device. Once issued a key pair, a client device may connect with server  302  to join an online meeting without having to provide a username and password. For example, user Alice  304 A may log into server  302  from client device  306 A using her username and password. After verifying the username and password, server  302  may issue public key  402 A and private key  404 A pair to client device  306 A. Server  302  may also retain and store a copy of public key  402 A and/or private key  404 A that have been issued to client device  306 A so that client device  306 A can be later authenticated. Moreover, server  302  may associate the issued cryptographic keys  402 A,  404 A with user Alice  304 A so that any client device that may purport to belong to user Alice  304 A in the future can be properly authenticated. 
     Public key  402 A and private key  404 A may be mathematically linked such that ciphertext that has been encrypted with public key  402 A may only be decrypted back into its counterpart plaintext with private key  404 A. Although public key  402 A and private key  404 A are represented by images of physical keys in  FIG. 4 , one of skill in the art will understand that keys  402 A,  404 A are not physical keys, but rather data (i.e., numbers) that function like cryptographic keys. 
     When client device  306 A attempts to log in to the meeting service, an identity server, such as server  302  or in the alternative a separate server, may identify client device  306 A using a security token (i.e., digital signature). The security token can be a challenge response token such as a randomly generated number encrypted with public key  402 A of client device  306 A. In response to receiving the token, client device  306 A may decrypt the challenge response token using its private key  404 A and transmit the result back to server  302  for authentication. Server  302  may then compare the transmitted result with the original random value used in creating the token. When the two values coincide, then server  302  may determine that client device  306 A is in possession of correct private key  404 A, which implies that client device  306 A is associated with Alice&#39;s  304 A user account. Server  302  can register client device  306 A for future reference and store the association between Alice  304 A and client device  306 A. 
     Similar to client device  306 A and its cryptographic keys  402 A,  404 A, other client devices that belong to user Alice  304 A such as client device  306 B and client device  306 B can be also registered with server  302 . For instance, user Alice  304 A may log into server  302  from client device  306 B using her username and password. After verifying her username and password, server  302  can then issue public key  402 B and private key  404 B to client device  306 B. In the alternative, Alice  304 A may register client device  306 B with server  302  using public key  402 A, which has been previously issued to another client device  306 A. Since server  302  already has knowledge of public key  402 A as being associated with user Alice  304 A, server  302  can trust the request to add client device  306 A as a new device of Alice  304 A. In a similar manner, Alice  304 A can also add client device  306 C to the online meeting session. Server  302  may issue public key  402 C and private key  404 C to client device  306 C. In some embodiments, server  302  may issue identical key pairs to each of Alice&#39;s  304 A client devices  306 . In other words, public keys  402 A,  402 B,  402 C may be identical keys. Similarly, private keys  404 A,  404 B,  404 C may be identical private keys. Alternatively, key pairs issued to different client devices  306  may be unique to their devices. Thus, public key  402 A may be different from public key  402 B, and public key  402 C may be different from both public key  402 A and public key  402 B. In addition, private keys  404 A,  404 B,  404 C may be all different from each other. In such embodiments, server  302  may be able uniquely identify client devices  306  by their corresponding keys. Server  302  can also store information about which key pair(s) are associated with a given user. 
     Furthermore, server  302  may authenticate client devices  306  using the key pairs when an active client device attempts to establish itself as a new primary client device. For example, if, after Alice  304 A uses her laptop computer  306 B as the primary computer, moves over to her smartphone  306 C and tries to establish it as the new primary client device, server  302  can use the public key that is associated with Alice  304 A, such as public key  402 B, to generate a challenge response token. Smartphone  306 C may already possess identical public key  402 C and its matching private key  404 C. Once newly active client device  306 C proves to server  302  that it possesses matching private key  404 C by presenting a decrypted plaintext using private key  404 C, server  302  can designate smartphone  306 C as Alice&#39;s  304 A new primary client device. Consequently, laptop computer  306 B, which was Alice&#39;s  304 A previous primary client device, may now be designated as a secondary client device, which can be subsequently controlled by primary client device  306 C. 
     In some embodiments, server  302  may use the key pair when establishing control sessions and sharing various resources as well. In other embodiments, any or all of the commands that are issued through the control session can be encrypted and decrypted using the key pair. For example, primary client device  306 C may encrypt, using public key  402 A, a command for secondary client device  306 A to share a resource with another user&#39;s device. After receiving the encrypted command, client device  306 A can decrypted the message using private key  404 A, thus assuring that no unauthorized client device (without the proper private key) may intercept the message and impersonate a legitimate secondary client device. In yet other embodiments, the media stream associated with sharing of resources may be encrypted with the key pair. 
       FIGS. 5A-5C  illustrate exemplary participant rosters as displayed on the devices. Specifically,  FIG. 5A  shows exemplary meeting participant roster  500 A as may be seen by the user (i.e., Alice  304 A) on client device  306 C of  FIG. 3  via the user interface of the device. In this example, roster  500 A indicates that there are three potential participants, as indicated by the corresponding labels  502 A,  504 A,  506 A, in an ongoing online meeting. In some embodiments, presence indicators accompanying the names of the participants may indicate whether one or more of the users are present and currently available for interaction. In this example, client devices that are connected to server  302  under Alice&#39;s  304 A user account are also listed under her name  502 A as “PC DESKTOP”  508 , “MAC LAPTOP”  510 , and “SMARTPHONE”  512 . Smartphone  306 C is indicated as the active device (i.e., primary device). The presence indicators for the individual client devices may also inform user Alice  304 A of the current statuses of those devices (e.g., online, offline). In some embodiments, the device names can be collapsible by a user input such as a mouse click on user label  502 A. 
     The contents of roster  500 A may change dynamically as the status of the users or client devices changes. For example, if user Bob  304 B goes offline or idle for more than a threshold amount of time, his user label  504 A may disappear or otherwise change its appearance (e.g., gray out). Alternatively, his presence indicator may identify him as being absent or away from the meeting. Furthermore, when another client device, such as client device  306 B, becomes the new active device (i.e., primary device), device labels  510 ,  512  may be updated to reflect the devices&#39; new statuses. For example, device label  510  may read, “MAC LAPTOP (ACTIVE),” while device label  512  may simply read, “SMARTPHONE,” without the “(ACTIVE)” designation. 
     In some embodiments, client devices that belong to anyone else may be hidden from view in roster  500 A. Doing so may advantageously simplify Alice&#39;s  304 A interaction with Bob  304 B or Carol  304 C because Alice  304 A no longer needs to worry about which of the multiple client devices belonging to another user to engage. Moreover, a greater level of privacy may be ensured for Bob  304 B and Carol  304 C because information pertaining to their client devices or the users&#39; whereabouts is not shared with Alice  304 A. For example, since participant roster  500 A is shown on client device  306 C belonging to Alice  304 A, Bob&#39;s  304 B client devices  306 D,  306 E do not need to show up in roster  500 A. For similar reasons, roster  500 A may not identify the individual client device(s)  306 F belonging to Carol  304 C. In other embodiments, however, participant roster  500 A, as shown to Alice  304 A, may still include information (not shown in  FIG. 5A ) about the individual client devices belonging to other users Bob  304 B and Carol  304 C. 
     In  FIG. 5B , exemplary roster  500 B, as may be shown to Bob  304 B through client device  306 D, is depicted in substantially similar ways as roster  500 A of  FIG. 5A . That is to say, the viewing user&#39;s name is displayed as “ME (BOB)”  504 A along with his client devices  514 ,  516 . Bob&#39;s tablet device  306 D is marked as “(ACTIVE)”  514 . On the other hand, no client devices belonging to Alice  304 A or Carol  304 C are individually identified in roster  500 B. 
     By the same token,  FIG. 5C  illustrates exemplary participant roster  500 C, which may be seen by Carol  304 C on her video phone  306 F, in substantially similar manners as participant roster  500 A of  FIG. 5A . Here, the viewing user&#39;s name is displayed as “ME (CAROL)”  506 C along with her client device  518 . Carol&#39;s only client device  306 F is marked as “(ACTIVE)”  518 . On the other hand, client devices belonging to Alice  304 A or Bob  304 B are not individually identified in roster  500 C. 
       FIG. 6  illustrates an example of a user interface for sharing a resource. In particular, exemplary user interface  600  represents a user menu that may be displayed on Alice&#39;s  304 A active client device, which is her smartphone  306 C in this example. In some embodiments, user interface  600  may allow user  304 A to issue a command to share one or more resources from her secondary client devices  306 A,  306 B with other participants in the online meeting. In other embodiments, user interface  600  may additionally let user  304 A to share one or more resources from her primary client device  306 C as well. User interface  600  can be a dialog box, a pop-up, a menu, a list, etc. A user may interact with user interface  600  by using various types of input devices such as a mouse, a keyboard, a keypad, a stylus, a touchscreen, a remote controller, a motion capture device, speech, etc. In other embodiments, user interface  600  can be a non-graphic user interface such as a voice recognition system or an intelligent personal assistant. 
     User  304 A can interact with user interface  600  to issue a command to share one or more resources  602 - 624  that are available on her client devices with one or more participants in the online meeting. The resources available for sharing can be organized by the names of the client devices that those resources are available on. For instance in this example, under MY PC  602 , resources such as DESKTOP  606 , APP1 ( 608 ), AP2 ( 610 ), FILE1 ( 612 ), and FILE2 ( 614 ) are displayed to the user. Similarly, under MY MAC  604 , resources such as DESKTOP  616 , APP1 ( 618 ), APP2 ( 620 ), APP3 ( 622 ), and FILE1 ( 624 ) are shown as being available for sharing. 
     Prior to choosing a resource  602 - 624  to share by user  304 A, user interface  600  may present user  304 A with options (not shown) to establish a control session with another one of her client devices first, such as client device  306 A or client device  306 B. Once the control session is established, the list of available resources ( 600 ) may be generated based on the information supplied by the corresponding client devices. For example, client device  306 C may request to client devices  306 A,  306 B for lists of available resources on the respective devices that may be shared. In response, client device  306 A and client device  306 B may each transmit the list of available resources (e.g., DESKTOP, APP1, APP2, FILE1, FILE2) to client device  306 , which then combine the lists into a master resource list such as the one shown on user interface  600 . User interface  600  can also present user  304 A with options (now shown) to specify to which user(s) the selected resource(s) are to be shared. For example, user  304 A may choose to share APP3 ( 622 ) on MY MAC  604  with user Bob  304 B, but not with user Carol  304 C. 
       FIG. 7  illustrates an example of resource sharing among devices. Continuing from the examples illustrated in  FIGS. 5A and 6 , user Alice  304 A issues a command on her smartphone  306 C to share APP1 from her PC  306 A. Prior to issuing the command, a control session might have been already established by her primary client device  306 C over her secondary client device  306 A. In some aspects, smartphone  306 C can send the command signal to server  302 , which then forwards the signal to desktop PC  306 A. In other aspects, the command can be sent directly to PC  306 A without having to traverse server  302 . Upon receiving the signal, desktop computer  306 A may initiate sharing the selected resource (i.e., APP1) with client device  306 D, which belongs to user Bob  304 B. The resource may be shared with other client devices simultaneously. For example, the resource may be shared with client device  306 E (not shown), client device  306 F (not shown), client device  306 B, and/or even client device  306 C (not shown), which issued the command to share the resource. 
     The resource may be shared in the form of streaming media data, control signals, or the combination of both. The streaming media data can be encoded to reduce the size of the data being transmitted. Additionally, the resource data may be encrypted so that only authorized client devices may decrypt the data. The resource may be shared via server  302  or directly with client device  306 D via point-to-point communication. When client device  306 A shares the resource with more than one client devices, client device  306 A may transmit the resource data (e.g., media stream) via multicast transmission. Alternatively, client device  306 A can transmit the resource data to server  302 , which then distributes the data to other client devices via multicast. The resource data being shared may be manipulated, modified, and/or repackaged in order to meet the technical requirements of each receiving client device. In other words, when a resource from one client device is shared with another client device, the resource may have to be adjusted in order for the receiving client to properly present the resource to its user. Thus, depending on the screen size, screen resolution, screen aspect ratio, processing power, network bandwidth, functionality, etc. of the receiving device, the resource may need to be converted, transformed, truncated, augmented, or compartmentalized. Such adjustments can be made by client device  306 A before transmitting the resource data, by server  302  before distributing the resource data to receiving client devices, or by client device  306 D after receiving the resource data. 
     In the example illustrated in  FIG. 7 , desktop computer  306 A may be equipped with a display device with a higher resolution and a wider aspect ratio than the display screen of tablet device  306 D. Thus, in this example, when APP1 is displayed on tablet device  306 D, some changes have been made to its presentation. For example, the icon layout is altered to facilitate the vertical orientation of the display screen. The sizes and proportions of the menu items may be also adjusted to fit the new screen. In addition, the mouse pointer may be removed in a touchscreen-based device such as tablet  306 D. Finally, APP1 can be maximized to full screen mode on client device  306 D. In other examples, when a text is shared with a client device with no display screen, the text can be converted into audio and played back through a speaker. In another example, when a video clip is shared with a client device with no audio playback capability, the sound in the video clip can be converted into text and overlaid on top of the video as closed caption. In yet another example, a large color image file can be encoded, truncated, or converted to black-and-white before it can be shared with a smaller device with limited storage space or processing power such as a non-smartphone cellular phone. 
       FIG. 8  illustrates an example sequence diagram for sharing resources among devices. In this exemplary scenario for sharing resources ( 800 ), we have User A&#39;s secondary client device  802 , central server  804 , and User A&#39;s primary client device  806 . Although the example scenario  800  identifies the primary device as a mobile device and the secondary device as a computer, one of skill in the art will appreciate that those designations can be reversed. In this example scenario  800 , User A&#39;s computer  802  first joins the meeting by connecting to server  804  ( 808 ). Server  804  may authenticate User A&#39;s computer  802  by verifying the username and password provided by the user or issuing a challenge response token using the public key that is linked to the user&#39;s user account. Once server  804  successfully verifies that the user behind computer  802  is indeed a legitimate user and/or that computer  802  is a trusted device, server  804  may allow computer  802  to join the meeting. In addition, server  802  may designate computer  802  as the primary device (i.e., active device). Now that User A&#39;s computer  802  is fully joined to the meeting, server  804  may now transmit media streams  810  to User A&#39;s computer  802 . Media streams  810  can be, for instance, aggregated audio, video, and/or text data generated based on the audio, video and/or text data feeds received from other participants in the meeting. Alternatively, other client devices may transmit their individual media streams to User A&#39;s computer  802  directly via point-to-point communication. Although media streams  810  is depicted as being transmitted at one specific time in  FIG. 8 , one of skill in the art will understand that the transmission of media streams  810  may occur over an extended period of time in real time during the online meeting. 
     Without leaving the online meeting from computer  802 , User A may choose to join the meeting for the second time from her mobile device  806 . Similar to the join meeting process  808  for computer  802 , User A&#39;s mobile device  806  may also attempt to join the meeting by using a username and password or a key pair with server  804  ( 812 ). After determining that mobile device  806  is the new active device (because the recent join meeting process  812  was presumably initiated by the user), server  804  may automatically designate the new active device (i.e., mobile device  806 ) as the new primary device. Alternatively, server  804  may wait until a control session is established to change the primary device designation, as will be discussed in detail below. Once successfully authenticated, mobile device  806  can start receiving media streams  814  from server  804 . Similar to media streams  810 , mobile device  806  may also receive media streams  814  throughout the online meeting. 
     By this time, server  804  may realize that more than one client device (i.e., computer  802  and mobile device  806 ) from the same user is currently logged into the meeting. Server  804  may at this point send multi-resources updates  816 A-B to computer  802  and mobile device  806 . Multi-resources updates  816 A-B may inform the respective client devices of the existence of the other client device(s). It may also provide additional information that would be necessary for one client device to identify and communicate with other client device(s) such as device identifiers, network addresses, preferred communications protocol(s), etc. Additionally, presence information, activity indications, primary/secondary device designations may be also shared through multi-resource updates  816 A-B. Server  804  may issue multi-resource updates  816 A-B to the client devices on a regular basis according to a predetermined schedule or dynamically whenever a relevant event occurs such as a new client device joining the meeting or an existing client device leaving the meeting. 
     User A may wish to share from her mobile device  806  one or more resources residing on her computer  802 . Server  804  may require that User A first establish a control session between mobile device  806  and computer  802 . In order to establish the session, mobile device  806  can first send a request to server  804  to create a control session ( 818 ). Server  804  may then forward this request to computer  802  ( 820 ). Optionally, before forwarding the request to computer  802 , server  804  may first authenticate mobile device  806  or the request message itself to ensure that mobile device  806  is authorized to create a control session over computer  802 . In some embodiments the request to create a control session can be sent from mobile device  806  directly to computer  802 . Upon receiving the request, computer  802  can send a confirmation message to server  804  ( 822 ). Before sending the confirmation, computer  802  may try to authenticate the request message first to determine whether the request comes from a legitimate client device. In some embodiments, computer  802  can be configured to accept the create control session request automatically. In other embodiments, computer  802  can be configured to accept the request only with User A&#39;s confirmation. The confirmation message may be forwarded to mobile device  806  via server  804  ( 824 ), or the message may be transmitted directly to mobile  806  without going through server  804 . 
     Once the control session is established between computer  802  and mobile  806 , server  804  may designate mobile device as the primary client device, if it has not already done so. Consequently, computer  802  can be designated as a secondary client device that can be controlled by the primary device. Primary client device  806  may now assume partial or full control over secondary client device  802 . In some embodiments, once the control session is established, no data (i.e., media data) need be transported between primary client device  806  and secondary client device  802 . In such embodiments, the amount of data exchanged between primary device  806  and secondary device(s)  802  can be drastically reduced because only control signals need to be exchanged between the devices. 
     Additional media streams  826  may be transmitted from server  804  to primary client device  806 . In some aspects, server  804  may send media stream  826 , which may contain meeting data and control signals, only to primary client device  806 . This helps alleviate the amount of network traffic that travels between server  804  and the multiple client devices  802 ,  806 , and advantageously reduce the server  804  workload. In such embodiments, since it is assumed that User A is actively using primary device  806  only, secondary client device  802  need not receive media stream  826 . If User A chooses to move over to computer  802  at a later time and establish it as the primary client device, then server  804  could transmit media stream  826  only to computer  802  and not to mobile device  806  anymore. In some embodiments, however, server  804  may continue to broadcast media stream  826  to every client device regardless of whether it is a primary client device or a secondary client device. 
     Primary client device  806  may request a resource list from secondary client device  802  ( 828 ). The resource list may contain a list of items on secondary client device  802  that primary client device  806  may request for sharing. For example, the resource list can be a list of applications on secondary client device  802  that may be shared. The resource list may also include any files (e.g., a video, an audio, a text, a slideshow, a document, etc.) or the entire desktop/system environment itself. In some embodiments, primary client device  806  may send the request to server  804  to be forwarded to secondary client device  802 . In other embodiments, primary client device  806  may send the request directly to secondary client device  802  without the help of server  804 . In some aspects, the request for the resource list is sent out by primary client device  806  automatically and without knowledge of User A. In other aspects, User A can explicitly make the request through primary client device  806  to retrieve the list from secondary client device  802 . 
     Once secondary device  802  receives the request, the device may gather information about its sharable resources and send the compiled list back to primary device  806 , either via server  804  or directly to primary device  806  ( 830 ). Primary device  806  may then use the list to populate its user interface so that User A may be able to identify which resources on secondary client device  802  are available for sharing. If there are more than one secondary client device that primary client device  806  has established control sessions with, primary device  806  can combine the resource lists that it received from multiple secondary client devices to create a consolidated resource list such as resource list  600  shown in  FIG. 6 . The resource list can be periodically updated so that primary client device  806  could have up-to-date information about the sharable resources on secondary client device(s)  802 . Alternatively, the resource list can be updated only when User A manually initiates the update process. 
     Once the resource list is populated, User A may now issue a command to share a resource from secondary client device  802  ( 834 ). The request may specify which resource is to be shared, for how long, with which user or client device, with what type of privilege (e.g., for viewing only, partially interactive, fully interactive, etc.), and other specifications. The request may be sent directly to computer  802  to reduce network traffic between client devices and server  804 . In the alternative, the request may be sent to secondary device  802  via server  804 . Upon receiving the request to share one or more resources, secondary client device  802  transmits media data  836  that represents the shared resource to server  804 . Server  804  may then distribute media data  836  to its intended recipients such as other client devices belonging to users other than User A. In some embodiments, server  804  may also distribute resource media data  836  to User A&#39;s primary client device  806  or User A&#39;s other secondary client device(s). 
     Since User A can have full control over the shared resource on secondary client device  802  from her primary client device  806 , after the transmission of media data  836  or anytime during the transmission of media data  836 , primary client device  806  may send one or more control and/or annotation commands to computer  802 , either directly or via server  804  ( 838 ). For example, while sharing a slideshow stored on computer  802 , User A may want to issue a command to move to the next slide. User A can also highlight some of the phrases on the slide with a highlight tool. These control and annotation commands can be sent from primary client device  806  to secondary client device  802 , which can then apply these commands to the appropriate resources. It may appear to other users as if User A is directly controlling secondary device  802  when in fact User A is physically manipulating her primary client device  806  only. Accordingly, subsequent media data  836  may reflect any changes that have been made to the shared resource(s) by such commands. In some embodiments, depending on sharing privileges assigned to the other meeting participants, server  804  may receive control and/or annotation commands from those meeting participants other than User A. For example, in  FIG. 7 , user Bob  304 B may manipulate APP1 from his tablet device  306 D. Tablet device  306 D can then issue the associated control or annotation commands directly to desktop computer  306 A, or to server  302 , which may then forward the commands to desktop computer  306 A. Desktop computer  306 A can then apply those commands to APP1 and transmit the resulting media stream to server  302  for playback at tablet device  306 D. 
     Once the resource sharing is complete, the control session can be terminated. In some embodiments, the user can initiate the destruction of the control session. In other embodiments, a client device can initiate the destruction process, for instance, when there are no more requests to share a resource (i.e. idle control session) for more than a threshold amount of time. In example scenario  800 , computer  802  sends a request to server  804  to destroy the previously established control session with mobile device  806  ( 840 ). Likewise, mobile device  806  can also send the request to destroy the control session. Upon receiving the request, server  804  may then destroy the control session and send out confirmation messages  842 A-B. After control session is over, primary client device  806  can no longer control secondary client device  802 . 
     Having disclosed some basic system components and concepts, the disclosure now turns to some exemplary method embodiments shown in  FIGS. 9-11 . For the sake of clarity, the methods are discussed in terms of an example system  200 , as shown in  FIG. 2 , configured to practice the methods. Alternatively, the methods can be practiced by network device  100 , as shown in  FIG. 1 . It is understood that the steps outlined herein are provided for the purpose of illustrating certain embodiments of the subject technology, but that other combinations thereof, including combinations that exclude, add, or modify certain steps, may be used. 
       FIG. 9  illustrates an example method for sharing a resource in an online meeting. In this exemplary method, system  200  can be a server. In practice, system  200  can receive, at a server from a first client device, a command for a second client device to share a resource with a third client device, wherein the first client device, the second client device, and the third client device are participating in an online meeting managed by the server, and wherein the first client device is a primary device associated with a first user, the second client device is a secondary device associated with the first user, and the third client device is associated with a second user ( 902 ). The first client device, the second client device, and the third client device can each be a computer, a desktop computer, a laptop computer, a tablet device, a telephone, a voice over Internet protocol telephone, a smartphone, or a mobile device. The resource can be an application, a desktop environment, a system environment, a file, a document, a video, an audio, and/or a text. The first client device and the second client device may be associated with the same user account. Alternatively, the devices can be associated with two separate user accounts belonging to the same user (i.e., the first user). 
     Prior to receiving the command, system  200  may have received from the first client device a request to establish a control session with the second client device. System  200  may forward the request to the second client device and receive from the second client device, an acceptance of the request. The acceptance may have been issued by the second client device based on a confirmation from the first user. In the alternative, the acceptance, may have been issued by the second client device without a confirmation from the first user. Once the acceptance is received, a control session may be established between the first client device and the second client device, wherein the control session is configured to allow the first client device to control the second control device. Upon authenticating the first client device, system  200  may designate the first client device as the primary device associated with the first user. Authenticating the first client device can be accomplished by receiving a digital signature created by the first client device using a private key associated with the first client device, and determining, using a public key associated with the first client device, whether the digital signature was created by the first client device. 
     Additionally, system  200  may receive, from the first client device, a request for a list of one or more resources that are available on the second client device for sharing. system  200  may forward the request to the second client device and receive from the second client device the list of one or more resources. Finally, system  200  may forward the list of one or more resources to the first client device, wherein the resource is chosen based on the list of one or more resources. 
     After system  200  receives the command to share the resource, system  200  can forward the command from the server to the second device ( 904 ). System  200  can receive, at the server, data associated with the resource, the data being sent from the second client device in response to the command ( 906 ). System  200  can then forward the data from the server to the third client device ( 908 ). The third client device may be configured to present, to the second user via a user interface on the third client device, only one client device that is associated with the first user. In other words, instead of seeing both the first client device and the second client device, the second user may be able to see one of the two client devices, a new virtual client device, or no client devices at all. Additionally, system  200  can also forward the data from the server to the first client device. 
     System  200  may receive a data stream from the third client device, the data stream being addressed to the first user, wherein the data stream is not specifically addressed to the first client device or the second client device. Since the first and second client devices may be hidden from the view of the second user, the data stream coming from the third client device may not be addressed specifically to either one of the two devices. Instead, the data stream can be addressed to the first user or the user account(s) associated with the first user. The data stream may be a video stream, an audio stream, a text, or any combination thereof. In some embodiments, system  200  may forward the data stream only to the primary device. In other embodiments, system  200  may forward the data stream also to the secondary device. 
     At any time, system  200  may receive, from the second client device, a request to designate the second client device as the primary device associated with the first user. This may happen when the first user decides to use the second client device as the active device. Upon authenticating the second client device, system  200  can designate the second client device as the primary device associated with the first user, and designate the first client device as the secondary device associated with the first user. 
       FIG. 10  illustrates another example method for sharing a resource in an online meeting. In this exemplary method, system  200  can be a controlling client device. System  200  may transmit, from a first client device to a server, a request to establish a control session between the first client device and a second client device, the control session being configured to allow the first client device to control the second control device, wherein the first client device and the second client device are participating in an online meeting managed by the server, and wherein the first client device is a primary device associated with a first user, and the second client device is a secondary device associated with the first user ( 1002 ). System  200  may then receive, from the server, an acceptance of the request issued by the second client device ( 1004 ). Next, system may transmit, from the first client device to the server, a command for the second client device to share a resource with a third client device, wherein the third client device are participating in the online meeting, and wherein the third client device is associated with a second user ( 1006 ). In addition, prior to transmitting the command, system  200  may transmit, from the first client device to the server, a request for a list of one or more resources that are available on the second client device for sharing, and receive from the second client device the list of one or more resources, wherein the resource is selected based on the list of one or more resources. 
       FIG. 11  illustrates yet another example method for sharing a resource in an online meeting. In this exemplary method embodiment, system  200  can be the controlled client device. System  200  may receive, from a first client device and at a second client device, a command for the second client device to share a resource with a third client device, wherein the first client device, the second client device, and the third client device are participating in an online meeting managed by a server, and wherein the first client device is a primary device associated with a first user, the second client device is a secondary device associated with the first user, and the third client device is associated with a second user ( 1102 ). In response to the command, system  200  may transmit, from the second client device to the server, data associated with the resource, wherein the server is configured to forward the data to the third client device ( 1104 ). Optionally, prior to receiving the command to share the resource, system  200  may receive a request from the first client device to establish a control session between the first client device and the second client device, the control session being configured to allow the first client device to control the second control device. System  200  may then transmit, to the first client device, a confirmation message accepting the request. 
     It is understood that any specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged, or that only a portion of the illustrated steps be performed. Some of the steps may be performed simultaneously. For example, in certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. 
     The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. 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. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language claims, wherein 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.” 
     A 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. A phrase such as an aspect may refer to one or more aspects 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 phrase such as a configuration may refer to one or more configurations and vice versa. 
     The 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.