BACKGROUND
[0001] Technological advances in computing devices and networking continue to provide greater access to a wide variety of information and services allowing access from virtually anywhere in the world. Virtual offices are becoming more commonplace since the work that needs to be done can be performed from most locations. Businesses recognize the importance of meetings to effectively address customer needs and to move product development forward, for example. However, bringing users together to conduct business from the many remote locations at which the user could be and supporting the many available communications devices and media types remains a challenging prospect. [0002] Conferencing can be an effective means by which employees of a corporate enterprise, for example, can conduct meetings. However, given the location and connection capabilities at any point in time, participants may want to join via different media types. With the advances in storage and computing power of portable wireless computing devices, users now are capable of interacting with many types of disparate data types such as images, video clips, audio data, and textual data, for example. This is facilitated by several types of devices that users can now employ and with which to connect to the session. For example, one user can participate by audio/video from a conference room, another by voice via a desktop computer, and yet another by text input using a cell phone.
[0003] Conventional conferencing systems typically employ a participant passcode and a leader passcode as one way of managing session access and the session, in general. However, these techniques are limited at least insofar as the way in which access and lack of session participant identification is concerned. SUMMARY
[0004] The following presents a simplified summary in order to provide a basic understanding of novel embodiments described herein. This summary is not an extensive overview, and it is not intended to identify key/critical elements or to delineate the scope thereof Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
[0005] The disclosed architecture introduces a session lock and lobby feature in a distributed conferencing framework for a conference session. Under the lock scenario, once a user enters the session, the session can be locked to prevent other individuals from entering, even if the individuals were invited to the session. Locking can be accomplished

manually by an existing session participant (e.g., a session leader) and/or automatically based on criteria (e.g., session start time).
[0006] The lobby feature allows a session participant to become aware of users who may have been locked out by providing notification and/or identification of the user(s) attempting to gain access to the session. In other words, a session leader or presenter (other session participant) can be notified that User A and User B have or are attempting to gain access to the session, but are locked out and standing by in a lobby mode or state. The session leader can then selectively allow access to the session. For example, User A can be allowed session access, while User B is not. In accordance with typical lobby scenarios, however. User B could be scheduled for access at a later time (e.g., 15 minutes later) either automatically or manually.
|0007] The architecture facilitates the lock and lobby features in multiple identical, leaderless, conference servers which together form a distributed conferencing system. Session initiation protocol (SIP) and the centralized conference control protocol (C3P or CCCP) can be employed, for example, to facilitate the lock and/or lobby functionality. The SIP implementation addresses shortcomings in the currently addressed Internet drafts, especially for support of a multiple front-end architecture.
[0008] To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles disclosed herein can be employed and is intended to include all such aspects and their equivalents. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 illustrates a computer-implemented conferencing management system.
[0010] FIG. 2 illustrates a method of managing a conferencing session.
[0011] FIG. 3A and FIG. 3B illustrate a more detailed method of managing a
conferencing session.
[0012] FIG. 4 illustrates a method automatically allowing session access according to
predetermined criteria.
[0013] FIG. 5 illustrates a block diagram of a computing system operable to execute the
lock and lobby protocol architecture in accordance with the disclosed architecture.

[0014] FIG. 6 illustrates a schematic block diagram of an exemplary computing environment for the lock and lobby protocol architecture. DETAILED DESCRIPTION
[0015] The disclosed architecture supports an on-premise conferencing system that can facilitate virtual web meetings. In an actual physical-world analogy, when a meeting occurs in a conference room, the meeting leader (or presenter) can decide to lock the room door to prevent others from entering the meeting, without or without prior permission. When the room is locked, would-be session participants can knock on the door, at which time the session leader can decide whether to allow or deny access to the user. The location from which the would-be participants notify the session leader can be referred to as a lobby, or just outside the conference room. When the conference is set in a locked state no users are admitted into the conference. Moreover, it is possible to also lock out users for gaining access to the lobby. Continuing with the physical analogy, the new users can either be allowed into a lobby or can be denied access to the conference altogether by denying access to the lobby.
[0016] In the virtual example of the subject architecture, when the lobby feature is enabled, would-be participants to the session can enter the meeting (or virtual) lobby, and wait for the session leader (or any session participant) to grant session access. If the session leader had not already been in the session, once the leader enters the meeting, the leader can be notified that the would-be participants are waiting in the lobby. The leader can then selectively grant/deny access to each of the lobby users.
[0017] The leader can also be notified of the would-be participants in the lobby through console alerts or messages, for example, while the meeting is in progress. The leader can then lock the session "door" to prevent further interruptions. As a means for more specific control, the leader (or presenter) can enable or disable the lobby for each individual meeting. Once granted access, the console for the lobby participant automatically launches and the lobby (or would-be) participant is granted access to all session communications. A participant denied access or that may timeout, can be presented with an appropriate message.
[0018] The conferencing architecture is a scalable, pluggable architecture for multi¬party, multimedia conferencing. The lock and lobby functionality is provided via centralized policy and control component (the conferencing component) that allows the seamless plug-in of different distributed media access components. The conferencing

architecture supports multiple pluggable distributed media components for disparate media types (e.g., data, audio/video, instant messaging) for client participation in the session. [0019] Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate a description thereof 10020] Referring initially to the drawings, FIG. 1 illustrates a computer-implemented conferencing management system 100. The system 100 includes a conferencing component 102 for establishing a conferencing session 104 of session participants and would-be participants 106. The participants 106 connect to the conferencing session 104 using clients (or client devices) 108 via distributed media access components 110 (denoted MEDIA ACCESS COMPONENT 1,...,MEDIA ACCESS COMPONENTN, where N is a positive integer) and based on a session protocol.
(0021] The media components 110 can be located anywhere on a network (e.g., the Internet) thereby allowing access via HTTP, for example. The conferencing component 102 can be one of many such components of a network, working separately or cooperatively to provide the session 104, and which do not need to know anything about the other media access components. The media access components 110 include capabilities for connecting with clients that communicate data, audio/video media, audio only, instant messaging, and other media types, combinations, and formats.
[0022] A session management component 112 provides for managing access to the conferencing session 104 of allowed session and would-be session participants relative to a session lobby 114. In other words, users desiring to be part of the session 104 can be processed though the lobby 114, or initially, directly into the session 104. Later would-be participants can then be processed through the session lobby 114.
[0023] The clients (or client devices) 108 can communicate to the appropriate media access component 110 using a media session protocol, which can be session initiation protocol (SIP) and/or centralized conference control protocol (C3P). The session management component 112 facilitates notification of one of the session participants of the would-be session participant when the would-be session participant is associated with the session lobby 114. One or more of the session participants (e.g., presenter or watcher) can

allow or deny access to the session 104 of the would-be session participant from the lobby 114.
[0024] As part of the connection process, the would-be session participant can be authenticated by the conferencing component 102 prior to association with the session lobby 114. In support thereof, the conferencing component 102 signals the corresponding distributed media access component(s) 110 associated with the would-be session participant to allow or deny access to the conferencing session 104 by the would-be session participant, based on respective successful or unsuccessful authentication.
[0025] For example, in order to meet a conferencing need, one or more of the users 106 accesses the centralized conferencing component 102 (e.g., via an Internet connection) to request that the conference session 104 be created, scheduled, or for participation in a current session. The media access components 110 include the capability to connect and allocate the appropriate media interface (e.g., audio, video, data) for the clients 108 (or client device) being used by the users 106, to configure the media interface to meet the requested client media type, provide session management of the conference session 104 and, manage closeout and cleanup of the session 104 for all associated clients 108 and systems.
[0026] The centralized conferencing component 102 can be one of many such components in a network or enterprise, for example, and which also provides scheduling services and creation of the session instance(s). The conferencing component 102 also includes functionality for allocating one or more of the most available distributed media access components 110 for the conference session 104. The conferencing component 102 also functions as a conference policy and roster control service. The conference policy is the overall set of rules governing operation of the conference, and can be broken down into membership policy and media policy. A conference policy service is a logical function which can store and manipulate the conference policy and rosters.
[0027] The conferencing component 102 also includes a conference notification service which is a logical function that allows for notification, accepting subscriptions to the conference state, and notifying subscribers about changes to that state. The conference control component also functions to provide session security via user authorization and/or authentication services based on authentication information such as identity information, enterprise credentials, and/or a PIN.
[0028] The conferencing controller 102 also interfaces to the distributed media access components 110 for conference policy and roster management services. The conferencing

architecture provides conference participants or would-be participants with a single conference picture using a single integrated roster.
[0029] It is to be understood that although the disclosed lock and lobby implementation is described in the context of a conferencing system, the general technology can be applied to other contexts where multiple users seek access to a common location or space. For example, the lock and lobby architecture can be applied to virtual online gaming where many users access a central virtual playing field or environment. Given that in these scenarios where public access can fill the available slots for the game, the lobby can be employed to selectively allow certain players in and to prevent other players from access to the virtual environment. Accordingly, this provides more control over player access as well as notification by the current players, rather than a server administrator needing to access a special console to bump players off the server.
[0030] FIG. 2 illustrates a method of managing a conferencing session. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, for example, in the form of a fiow chart or flow diagram, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation. [0031] At 200, a conference session of session participants is established via one or more of the distributed media access components. At 202, a request for session access is received from a new user, the request received from one of the distributed media access components. At 204, a session lock is enabled to control access to the session, by preventing access to the session. At 206, access to the session for the new user is controlled based on the lock. [0032] FIG. 3A and FIG. 3B illustrate a more detailed method of managing a conferencing session. At 300, the conferencing component establishes a session and initiates a conference lock to prevent other users or would-be participants from entering the session. At 302, one of the session participants enables the lobby feature. At 304, a request is received from a would-be participant (WBP) to join the session via a console interface (e.g., HTTP). The request can be processed from the user client (or client device) to the corresponding media access component, and then to the conference component. The request can be in the form of a join INVITE. At 306, an authentication process is initiated

to authenticate the WBP using authentication data. The data can include enterprise credentials, and/or user information, for example. Based on successful authentication, the conferencing component processes the request from the WBP to join the session, as indicated at 308. At 310, the conferencing component issues minimal session information to the WBP to join the session. The session information can be obtained based on a SUBSCRIBE message to the conference information.
[0033] Moving to FIG. 3B, at 312, the conferencing component sends a notification to one or more session participants about the WBP. At 314, a session participant processes the request. At 316, the system checks to determined if the WBP is to be allowed. If so, at 318, the session participant sends a command to the conferencing component to allow the WBP. At 320, the conferencing component sends the WBP full session details. This can include session participants, session leader, if any, current session state (e.g., topic), and so on. At 322, the conferencing component allows connection of the WBP to the distributed media access component for full media communications from the WBP device (e.g., cell phone, portable computer). Alternatively, if WBP access is not allowed, flow is from 316 to 324 where a session participant sends a command to the conferencing component to deny the WBP. The command can be sent using C3P. At 326, the conferencing component sends the WBP notification of access denial. The WBP can send a BYE on join INVITE dialog and NOTIFY (exp:0) on the SUBSCRIBE dialog with he appropriate and phrase. At 328, the WBP logs out of the console.
|0034] In a more specific context, a WBP that wants to join the meeting session, accesses a join URL via a console interface. The WBP can be authenticated using domain credentials or a PIN-based digest mechanism, for example. The WBP sends a join INVITE, which join INVITE is accepted and marks the WBP state as pending/on-hold in the lobby. The WBP sends a SUBSCRIBE to the conferencing package. Since the WBP is in an on-hold state, the WBP receives a document which has includes a minimum amount of conference details and information stating the WBP is in a pending/on-hold state. [0035] The conferencing component sends a notification to all the session participants (or watchers) of the session about the pending/on-hold WBP in the session lobby. One or more session leaders (or presenters) who receive the notification of pending/on-hold WBPs in the lobby can decide to deny or allow access to one or more of the WBPs to join the session. A presenter sends a C3P request to the conferencing component to allow/deny the WBP into the conference session. If the presenter allows the WBP, the WBP is changed from pending to the allowed state, and the WBP is sent a conference state full notification
8

with all the details. Alternatively, if the presenter denies the WBP, the WBP is a sent a BYE on join INVITE dialog and NOTIFY (exp:0) on the SUBSCRIBE dialog with appropriate reason phrase. This can be C3P using SIP, for example. [0036] An alternative communications dialog utilizes provisional responses. For example, when the conferencing component receives an INVITE from the WBP and the conference is in a locked state, the presenter (or session participant) can approve this new participant. In that case, the INVITE message can be parked on the conferencing component, and provisional responses can be sent to indicate progress. A notification, using the conferencing component notification service, can then be sent to the presenter. The presenter can then allow the WBP to join, in response to which the conferencing component then accepts the INVITE.
[0037] The call flow follows that of FIG. 3 A and 3B, except that the SUBSCRIBE dialog is not established until the participant is authorized. Additionally, the INVITE dialog is on hold and not established until authorized.
[0038] FIG. 4 illustrates a method automatically allowing session access according to predetermined criteria. At 400, a conference session is established for session participants via one or more distributed media access components. At 402, access to the session is enabled for the session participants and then session is then locked to prevent further session access. At 404, criteria can be determined and configured for automatically allowing access for all or selected WBPs. At 406, one or more requests for session access are received from WBPs (or new users) via the distributed media access components. At 408, the WBPs are authenticated, and the state for the successfully authenticated users is set to lobby. At 410, access for the lobby WBPs is automatically allowed based on the criteria. [0039] Following is sample code for a notification to a would-be participant that the participant is in an on-hold state in the session lobby.