Abstract:
In one embodiment, the invention utilizes an application within a meeting zone; monitor usage within the meeting zone; detects a resource located outside the meeting zone; dynamically adds the resource within the meeting zone; and updates a database configured to track a status of the resource.

Description:
RELATED APPLICATION  
       [0001]     The present invention is a continuation-in-part of prior U.S. patent application Ser. No. 09/751,807, filed on Dec. 29, 2000 entitled “Fault-Tolerant Distributed System for Collaborative Computing,” by Min Zhu, Jian Shen, and Shi Yan. 
     
    
     BACKGROUND OF THE INVENTION  
       [0002]     1. Field of the Invention  
         [0003]     The present invention relates generally to computer networks and, more particularly, to collaborative computing over a computer network.  
         [0004]     2. Background  
         [0005]     Traditional collaborative computing tools allow computer users at different locations to communicate via a computer network and share documents or applications stored and/or executed on one the user&#39;s computers. While both peer-to-peer and client-server communication models have been used in the past, web-based collaborative tools generally employ a client-server model.  
         [0006]     For example, client-server application sharing (also discussed in the context of “distributed computing”) is described in U.S. Pat. No. 5,434,852 “Distributed Processing Architecture for Control of Broadband and Narrowband Communication Networks;” U.S. Pat. No. 5,887,170 “System for Classifying and Sending Selective Requests . . . ;” and U.S. Pat. No. 6,038,593 “Remote Application Control for Low Bandwidth Application Sharing,” all incorporated herein by reference in their entireties. Other group communication techniques are described by Ulrick Hall and Franz J. Hauck, “Promondia: A Java-Based Framework for Real-time Group Communication in the Web,” Proceedings of Sixth International World Wide Web Conference (Apr. 7-11, 1997); Lane Boyd, “Taking Collaboration Into Orbit,” Computer Graphics World, Vol. 21, No. 9, p. 36 (September 1998); and Eric Ly, “Distributed Java Applets for Project Management on the Web,” IEEE Internet Computing Online, Vol. 1, No. 3 (May/June 1997), all incorporated herein by reference in their entireties.  
         [0007]     International Telecommunications Union (ITU) Standard T.120 is a family of open standards that provides both communications and applications protocols to support real-time multipoint data communications for collaboration and conferencing, among other uses. This standard is outlined in A Primer on the T.120 Series Standard by DataBeam Corp. (May 14, 1997), incorporated herein by reference in its entirety.  
         [0008]      FIG. 1A  is a block diagram illustrating the communication scheme used for an exemplary traditional collaborative computer system  100 . In  FIG. 1A , client computers  110   n  (where n=A, B, C . . . ) can connect to server computers  120   n  over a global-area computer network  130  (e.g., the Internet). As used herein, the numeral n appended to a reference number does not imply any correspondence among elements having different numerals (e.g., client computer  110 A bears no relationship to server computer  120 A).  FIG. 1B  is a block diagram illustrating the actual communications channels established between client computers  110   n  and server computers  120   n  to set up two conferences between users of client computers  110 A and  110 B on the one end and  110 C and  110 D on the other. As is readily apparent from inspection of  FIG. 1B , each conference is handled by a single server computer  120   n . This model performs satisfactorily for conferences having a small number of participants and conferences that do not require fault tolerance. However, as the number of participants in a conference increases, the computing power of server computer  120   n  becomes a bottleneck. Furthermore, if the particular server computer  120   n  that is handling a conference malfunctions, the entire conference is disrupted (i.e., server computer  120   n  represents a single point of failure for the entire system handling that conference). Accordingly, there is a need for an improved collaborative computing system.  
       SUMMARY  
       [0009]     In one embodiment, the invention utilizes an application within a meeting zone; monitor usage within the meeting zone; detects a resource located outside the meeting zone; dynamically adds the resource within the meeting zone; and updates a database configured to track a status of the resource.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0010]     The present disclosure may be better understood and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.  
         [0011]      FIG. 1A  is a block diagram of a prior art collaborative computer system.  
         [0012]      FIG. 1B  is a block diagram illustrating the connections established between the client and server computer of  FIG. 1A  during two conferences.  
         [0013]      FIG. 2A  is a block diagram of a distributed collaborative computer systems, in accordance with some embodiments of the invention.  
         [0014]      FIG. 2B  is a block diagram illustrating the connections established between the client and server computers of  FIG. 2A  during a conference.  
         [0015]      FIG. 3  is a block diagram of the software components of a distributed collaborative computer system, in accordance with some embodiments of the invention.  
         [0016]      FIGS. 4A, 4B , and  4 C are flow diagrams illustrating a start/join conference operation on the distributed collaborative computer system of  FIG. 3 .  
         [0017]      FIG. 5  is a flow diagram of the operation of the log server of  FIG. 3 .  
         [0018]      FIG. 6  is a flow diagram of the operation of the license server of  FIG. 3 .  
         [0019]      FIG. 7  is a flow diagram of the operation of an App server of  FIG. 3 .  
         [0020]      FIGS. 8, 9 ,  10 , and  11  are flow diagrams illustrating the operation of the meeting manager of  FIG. 3 .  
         [0021]      FIG. 12  is a block diagram illustrating the software components of the client and server computers of  FIGS. 2A and 2B .  
         [0022]      FIGS. 13A, 13B , and  13 C are flow diagrams illustrating the operation of the CB server and App servers of  FIG. 3 .  
         [0023]      FIG. 14  is a block diagram illustrating the communication channels established between two client computers of  FIG. 3  during an on-line conference, in accordance with an embodiment of the invention.  
         [0024]      FIG. 15  is a flow diagram of an operation for transmitting data between the client computers of  FIG. 14 .  
         [0025]      FIGS. 16A and 16B  are flow diagram illustrating a skip page operation used to control transmission of pages between a presenter&#39;s client computer and other participants&#39; client computers, in accordance with some embodiments of the invention.  
         [0026]      FIG. 17  is a flow diagram of a client browser operation, in accordance with some embodiment of the invention.  
         [0027]      FIGS. 18A, 18B ,  18 C 1 - 3 ,  19 A,  19 B,  20 A,  20 B and  20 C are views of web pages displayed by client browser of  FIG. 3  during operation of the distributed collaborative computer system of  FIG. 3 .  
         [0028]      FIG. 21  is a simplified block diagram illustrating a system, consistent with one embodiment of the invention.  
         [0029]      FIG. 22  is a simplified block diagram illustrating a system, consistent with one embodiment of the invention.  
         [0030]      FIG. 23  is a flow diagram consistent with one embodiment of the invention. 
     
    
       [0031]     The use of the same reference symbols in different drawings indicates similar or identical items.  
       DETAILED DESCRIPTION OF THE INVENTION  
       [0032]      FIG. 2A  illustrates a distributed collaborative computing system  200 , in accordance to some embodiments of the invention. Client computers  210   n  (where n=A, B, C . . . ) are connected to server computers  220   n  via global-area computer network  130 . Unlike in the prior art system of  FIGS. 1A and 1B , each client computer  210   n  can connect to any server computer  220   n . Server computers  220   n  are in turn connected through a high-speed link  230 . High speed link  230  allows faster throughput and a higher level of security than global-area network  130 . For example, in some embodiments high-speed link  130  is a dedicated T 1  or T 3  or optical carrier-class link, such as one employing the well-known SONET standard and OC-48 or OC-192 framing. One of ordinary skill in the art will readily recognize that many other equivalent high-speed network standards, including non-optical standards, may be employed to create a high bandwidth link.  
         [0033]      FIG. 2B  illustrates the connections established between client computers  210   n  and server computers  220   n  to conduct a conference between participants seated at client computers  210 A and  210 D, respectively. First, client computer  210 A (whose user will host the conference) establishes a connection  225 A to server computer  220 A over global-area network  130 . Server computer  220 A, in turn, is connected to server computer  220 B via high-speed link  230 . Finally, client computer  210 D, whose user will join the conference hosted by the user of client computer  210 A, establishes a connection  225 B to server computer  220 B over global-area network  130 . As a result, information transmitted from client computer  210 A travels through connection  225 A, high-speed link  230  and connection  225 B to reach client computer  210 D. Similarly, information transmitted from client computer  210 D travels through connection  225 B, high-speed link  230  and connection  225 A to reach client computer  210 A. Since high-speed link  230  is several orders of magnitude faster than connections  225 A and  225 B, the delay introduced by high-speed link  230  is transparent to the users of client computers  210 A and  210 B.  
         [0034]      FIG. 3  is a block diagram of the software components of a distributed collaborative computer system  300 , in accordance with some embodiments of the invention.  
         [0035]     Distributed collaborative computer system  300  includes meeting zones  310   n  (where n=A, B, C), client browser  320 , web zone  330  and central operation database  350 . Client browser  320  is a web browser program executed on one of client computers  210   n  ( FIGS. 2A and 2B ). Client browser  320  first connects to web zone  330  to request starting or joining a conference. Web zone  330 , in turn, verifies the user and conference information and updates central operation database  340  accordingly. Once web zone  330  has verified that the user is authorized to start/join a conference, client browser  320  connects to one of meeting zones  310   n  to access the conference. Meeting zone  310   n , in turn, connects client browser  320  to the desired conference and updates central operation database  340  accordingly.  
         [0036]     Web zone  330  includes a web server  335  that maintains a website to allow users to access distributed collaborative computer system  300  and a web database  337  that stores web usage and administrative information about users of distributed collaborative computer system  300 . The information stored in web database  337  is periodically synchronized and/or replicated with the information stored in central operation database  340  to ensure data consistency.  
         [0037]     Each meeting zone  310   n , in turn, includes a meeting manager  350 , a ping server  355 , a license manager  360 , a meeting database  365 , a log server  370 , collaboration (CB) servers  380   n , and application (App) servers  390   n . Furthermore, each meeting zone  310   n  also includes a process manager (PM)  311 . Process manager  311  is the controlling process for all logical servers running on a physical server within the meeting zone. PM  311  thus monitors the health of all logical servers and processes running on the physical server and spawns replacement processes on failure. Alternatively, PM  311  can start new processes on command from remote access service (RAS)  312 .  
         [0038]     In one embodiment of the present invention, a single instance of meeting zone  310 A is implemented on one physical server (i.e., one machine).  
         [0039]     In some embodiments, each meeting zone is implemented on a single physical server. One of ordinary skill will readily appreciate, however, that multiple physical servers could also be used either as hot or warm standby units for redundancy or to spread the logical server loading across multiple machines, each with its own PM. Alternatively, several meeting zones could be implemented on one physical server, either having their own PM, or sharing a single PM.  
         [0040]     PM  311  spawns each logical server (e.g., CB servers  380 A,  380 B,  380 C; App server  390 A,  390 B,  390 C; meeting manager  350 , ping server  35 , log server  370 , and license manager  360 ) as directed by a startup configuration file or operator command through RAS  312 . RAS  312  is, in some embodiments, a real-time messaging service such as TIBCO Rendezvous, available from TIBCO Software, Inc. of Palo Alto, Calif.  
         [0041]     Each logical server has its own communications and control module known as a zone manager (ZM). Conceptually, each ZM  313  is functionally similar although one of ordinary skill in the art will appreciate that implementation optimizations may allow for reduced functionality in some instances of ZM  313 .  
         [0042]     Meeting manager  350  also possesses a special zone manager  314 , so designated because it also acts as a gatekeeper (GK) for the entity meeting zone  310 . The GK maintains a subset of the state of each logical server so that meeting manager  350  has immediately available the detailed status of the entire meeting zone  310 .  
         [0043]     Each ZM, which is spawned (created) in direct correspondence to each logical server or autonomous process on a given physical server machine, monitors the health and status of its corresponding logical server or process. All logical server communications with other logical servers and with the process manager  211  go through the ZM in each logical server and the PM.  
         [0044]     The operational functions of PM  311 , RAS  312 , ZM  313 , and ZM/GK  314  are discussed in further detail below.  
         [0045]     All ZMs report to a single “super ZM”, known as the gatekeeper or ZM/GK. Each ZM sends a subset of its corresponding logical server&#39;s state and traffic capacity to the ZM/GK so that the GK is aware of the status of all elements of the meeting zone. This enables the meeting manager to get coordinated zone state reports and therefore “know” the status of the entire meeting zone.  
         [0046]     Zone status is important to the meeting manager (and thus to the overall health and efficiency of the zone) because the meeting manager uses ZM/GK state reports to manage both the zone&#39;s overall quality of service (QoS) and the load balance across all active collaboration servers (CBs) in the zone.  
         [0047]     QoS, in this context, refers to the zone&#39;s ability to respond to client data requests of all types (e.g., HTTP, application sharing, document sharing, telephony, and so forth). In addition, QoS is an indirect indicator of latency to those requests, caused by high and possibly unbalanced loading of the logical servers in the meeting zone. For example, in some embodiments of the present invention, a meeting manager faced with a need to add more user participants to an in-progress meeting must determine if an additional CB server must be spawned (i.e., brought on-line) to keep overall CB server loading below a certain threshold. This “intelligence” in the MM is implemented through the ZMs in each CB and the coordinating function of the ZM/GK reporting to the MM. The MM can thus decide if the pre-defined QoS for the specific user client (perhaps determined by the time of day, the user&#39;s license, or the type of service purchased by the user or some communication thereof, to name but a few examples), would be unobtainable without additional CB server resources. If so, the meeting manager will request that the process manager spawn a new CB server.  
         [0048]     Once client browser  320  has received authorization to start/join a conference, client browser  320  attempts to connect to ping servers  355  in multiple meeting zones  310   n . Client browser  320  selects the first ping server to respond to the connection request and disconnects other responding ping servers  355 . The selected ping server, in turn, forwards the request to start/join a conference to a meeting manager  350  in the same meeting zone  310   n  as the selected ping server  355 . Meeting manager  350 , in turn, assigns a CB server  380   n  to host/handle the conference. The selected CB server  380   n  connects to client browser  320  and any other CB servers  380   n  handling the conference that the user wishes to start/join. Thus, client browser  320  communicates with other client browsers  320  via the selected CB server  380   n.    
         [0049]     App servers  390   n  are used by CB servers  380   n  and client browsers  320  to support services such as document view, file sharing, video, voice over IP, telephony, polling, chat and application sharing. Collaborative support for these services are further described in the following references, each incorporated herein by reference in its entirety:  
         [0050]     “Instant Document Sharing,” co-pending and commonly-assigned application for a U.S. patent Ser. No. 09/442,424, filed Nov. 17, 1999.  
         [0051]     “Instant Sharing of Documents in a Remote Server,” co-pending and commonly-assigned application for U.S. patent Ser. No. 09/471,938, filed Dec. 23, 1999.  
         [0052]     “Remote Document Serving,” co-pending and commonly-assigned application for a U.S. patent Ser. No. 09/591,377, filed Jun. 9, 2000.  
         [0053]     “Instantaneous Remote Control of an Unattended Server,” co-pending and commonly-assigned application for a U.S. patent Ser. No. 09/515,684, files Feb. 29, 2000.  
         [0054]     “Method for Creating Peer-to-Peer Connections Over an Interconnected Network to Facilitate Conferencing Among Users,” co-pending and commonly-assigned application for a U.S. patent Ser. No. 08/609,025, filed on Feb. 29, 1996.  
         [0055]     “Method for Establishing a Communication Connection Between Two or More Users Via a Network of Interconnected Computers,” co-pending and commonly-assigned application for a U.S. patent Ser. No. 09/195,801, filed on May 12, 2000.  
         [0056]     “Emulating a Persistent Connection Using HTTP,” co-pending and commonly-assigned application for a U.S. patent Ser. No. 09/449,011, filed on Nov. 24, 1999.  
         [0057]     “Method of Transferring Data at Adjustable Levels of Priorities to Provide Optimum Response to User Demands,” U.S. Pat. No. 5,623,603.  
         [0058]     “Method to Provide for Virtual Screen Overlay,” U.S. Pat. No. 5,577,188.  
         [0059]     “Collaborative Web Browser,” U.S. Pat. No. 5,944,791.  
         [0060]     Log server  370  communicates with meeting manager  350  via their respective ZMs  313  and  314  and stores information related to new users joining/leaving conferences and updates meeting database  365 . License manager  360  communicates with meeting manager  350  (again, through ZMs  313  and  314 ) and polls meeting database  360  to ensure that the number of users authorized to join a meeting is not exceed.  
         [0061]     Overall fault tolerance is ensured by providing process-level fault monitoring by the ZM and correction (e.g., process replacement) by the PM. At the logical server level, the MM uses ZM/GK sate monitoring to detect logical server faults and PM commands to spawn replacements. Logical server state replication is also provided by the gatekeeper, using the meeting database. Finally, physical server fault tolerance is provided by operator hardware and environmental status using a combination of manual and RAS monitoring and control methods well-known in the art.  
         [0062]      FIGS. 4A-4C  are flow diagrams illustrating a start/join conference operation  400  on distributed collaborative computer system  300  ( FIG. 3 ).  
         [0063]     First, in stage  402 , client browser  320  connects to a web server  335 . If the connection is successful (stage  404 ), operation  400  proceeds to stage  406 , otherwise stages  402  and  404  are repeated. In stage  406 , the user of client computer  320  logs on to web server  335 . In stage  408 , the information entered by the user in stage  406  is authenticated with information stored in web database  337 . If the information entered by the user cannot be authenticated, stages  406  and  408  may be repeated until the information entered by the user is successfully validated. In some embodiments, client browser  320  is disconnected after a predetermined number of login attempts to prevent unauthorized access to web server  335 . As those skilled in the art are familiar with techniques for preventing/deterring unauthorized access to a website, these techniques are not further discussed herein.  
         [0064]     Once the user has successfully logged on to web server  335 , stage  410  determines whether the user is requesting to start a new conference or join an existing conference. If the user is requesting to join a new conference, operation  400  proceeds to stage  412 , otherwise operation  400  proceeds to stage  450 .  
         [0065]     In stage  412 , meeting parameters are extracted from meeting database  365  through web database  337 . In stage  414 , a plug-in for client browser  320  is launched on client computer  210   n  ( FIGS. 2A and 2B ). The first time the user of client browser  320  connects to web server  335 , the plug-in is downloaded over global-area network  130  and installed on the client computer  210   n . After the plug-in is installed on client computer  210   n , it can be re-used for subsequent conferences without the need for downloading and reinstalling it. In some embodiments, multiple versions of the plug-in are used over time: when a new version of the plug-in becomes available on web server  335 , the new plug-in is downloaded to client computer  210   n  and installed in place of the older version of the plug-in.  
         [0066]     In stage  416 , the meeting parameters are sent from meeting database  365  (via web database  337 ) to client computer  210   n  and operation  400  proceeds to stage  418  ( FIG. 4B ).  
         [0067]     In stage  418 , client browser  320  attempts to connect to any available ping server  355 . In stage  420 , responses are received from one or more ping servers  355 . In some embodiments, if no response is received within a predefined time limit, stages  418  and  420  are repeated until a response is received within either the original time limit or a newly defined time limit. Client browser  320  selects the fastest ping server  355  to respond to the connection request (stage  422 ) and disconnects the non-selected ping servers  355  (stage  424 ). Client browser  320  then sends a request to join a meeting to the selected ping server  355  (stage  426 ) and ping server  355  forwards the request to a meeting manager (MM)  350  (stage  428 ) in the same meeting zone  310   n  ( FIG. 3 ) as ping server  355 .  
         [0068]     Upon receiving the request to join a meeting, meeting manager  350  selects a collaboration (CB) server  380   n  from a pool of available CB servers  380   n  in the meeting zone  310   n  (stage  430 ). In stage  432  ( FIG. 4C ), the selected CB server  380   n  queries other CB servers  380   n  in all meeting zones  310   n  to ascertain which CB server  380   n  is hosting the meeting to which the user of client browser  320  is attempting to connect. Once client CB server  380   n  locates the hosting CB server  380   n , it connects to the hosting CB server  380   n  (stage  434 ). Client CB server  380   n  then makes a local copy of the meeting data from hosting CB server  380   n.    
         [0069]     Stage  438  determines whether meeting manager  350  has received a meeting confirmation from client CB server  380   n , in which case operation  400  proceeds to stage  440 . Otherwise stages  418 - 438  are repeated with a new client CB server  380   n.    
         [0070]     In stage  440 , meeting manager  350  has received confirmation from CB server  380   n  that a connection has been successfully established with the hosting CB server  380   n . The confirmation is then transmitted from meeting manager  350  to ping server  355  and from ping server  355  to client browser  320  (stage  442 ).  
         [0071]     If the user requests starting a new meeting in stage  410 , operation  400  proceeds to stages  450 - 472 . Stages  450 - 466  are analogous to stages  414 - 430  and stages  468 - 472  are analogous to stages  438 - 442 , except that if stage  468  fails, operation  400  proceeds to stage  454  rather than stage  418 .  
         [0072]      FIG. 5  is a flow diagram of the operation  500  of log server  370  of  FIG. 3 . In operation  500 , stage  510  determines whether a new log entry has been posted and stage  520  updates meeting database  365  ( FIG. 3 ).  
         [0073]      FIG. 6  is a flow diagram of the operation  600  of license server  360  of  FIG. 3 . First, stage  610  determines if a new user has requested joining the meeting, in which case operation  600  proceeds to stage  620 . Otherwise, stage  610  is repeated. In stage  620 , license manager  360  compares the number of users in the meeting if the current user were allowed to join the meeting to the user limit for the meeting. Stage  630  then determines whether the user limit is exceed, in which case CB server  380   n  is notified (stage  640 ). Otherwise stages  610 - 630  are repeated.  
         [0074]      FIG. 7  is a flow diagram of the operation  700  of an application (App) server  390   n  of  FIG. 3 . First, App server  390   n  registers with meeting manager  350  in the same meeting zone  310   n  ( FIG. 3 ) in stage  710 . Meeting manager  350 , in turn, allocates App server  390   n  to a CB server  380   n  handling a given conference (stage  720 ). CB server  380   n , in turn, initializes App server  390   n  with the necessary application data required for the conference (stage  730 ) and establishes a connection to App server  390   n  (stage  740 ) via ZMs  313 . CB server  380   n  notifies App server  390   n  of meeting events (e.g., users joining/leaving the meeting or control passing from the host to another user) in stage  750 . Finally, App server  390   n  establishes a connection with client browser  320  via CB server  380   n  (stage  760 ) which allows users of client browsers  320  to access and interact with the application provided by App server  390   n.    
         [0075]      FIGS. 8-11  are flow diagrams illustrating the operation of meeting manager (MM)  350  for providing fault tolerance to distributed collaborative computer system  300 .  
         [0076]      FIG. 8  illustrates CB server failure detection and recovery operation  800 . First, meeting manager  350  checks whether any CB servers  380   n  in the meeting manager&#39;s meeting zone  310   n  have failed (stage  810 ). A variety of techniques known in the art can be employed to detect failure of CB servers  380   n . For example, CB servers  380   n  can periodically transmit a “heartbeat” message to meeting manager  350 . If meeting manager  350  does not receive a heartbeat message from a CB server  380   n  within a predefined time limit, meeting manager  350  attempts to contact CB server  380   n  and if no response is received from CB server  380   n  within a predefined time limit, meeting manager  350  determines that CB server  380   n  has failed. Other failure detection techniques known in the art can be used to detect failure of a CB server  380   n  in accordance one or more embodiments of the present invention. Accordingly, the present invention is not limited to any particular failure detection technique.  
         [0077]     In some embodiments of the present invention, meeting manager  350  employs its zone manager (and meeting zone gatekeeper) (ZM/GK)  214  to exchange heartbeat (or analogous) messages with ZM  313  in each CB server  380   n . When and if ZM/GK  314  detects a CB server (or other logical server failure) by noting a lack of heartbeats, for example, ZM/GK sends a request to process manager (PM)  311  to restart the dead logical server.  
         [0078]     PM  311  also monitors each ZM  313 , including ZM/GK  314 , to evaluate ZM health. Should PM  311  discover a failed or stopped ZM process, the PM will restart (i.e., spawn a replacement for) the ZM.  
         [0079]     In particular, if failure of a CB server  380   n  is detected in stage  810 , operation  800  proceeds to stage  820 . Otherwise stage  810  is repeated until a failure is detected. Meeting manager  350 , in turn, retrieves a list of meetings handled by failed CB server  380   n  from meeting database  365  (stage  820 ) and sends a request to process manager  311  to launch a new CB server  380   n  (stage  830 ).  
         [0080]     The newly-spawned (replacement) CB server recovers its state information (e.g., information describing its configuration, operating or quality of service parameters, and/or current meeting data) from the local meeting zone&#39;s gatekeeper. Typically, this is the ZM/GK  314  within zone manager  350 , but the gatekeeper function may alternately be provided by any designated ZM  313 . Generally speaking, all local state in a logical server is preserved. However, if an application server goes down, the application state is lost. Only the meeting state is preserved in this case.  
         [0081]     Stage  840  then determines if the new CB server  380   n  has successfully come on-line, in which case meeting manager  350  continues to monitor the status of CB servers  380   n  (stage  810 ). Otherwise, stages  830 - 840  are repeated until a new CB server  380   n  successfully comes on-line.  
         [0082]      FIG. 9  illustrates the application server failure detection and recovery operation  900 . First, meeting manager  350  and CB servers  380   n  ( FIG. 3 ) check whether any App servers  390   n  in the same meeting zone  310   n  as meeting manager  350  and CB servers  380   n  have failed. As explained above, this can be accomplished using any failure detection technique known in the art. In case CB server  380   n  detects a failure of an App server  390   n  before meeting manager  350 , CB server  380   n  notifies process manager  311  through the zone manager  313  communication path. In some embodiments, the zone managers communicate with each other and the designated ZM/GK  314  using the well-known TCP/IP protocol and simple messages whose content and format are readily apparent to those of ordinary skill in the interprocess communication arts. In other embodiments, the WebEx Transport Layer protocol is used.  
         [0083]     The WebEx Transport Layer protocol (TP) is responsible for providing point-to-point connectivity between a WebEx client and the WebEx server. The TP layer will attempt to create direct TCP connections and use TCP to communicate between the client and server. For clients that sit behind firewalls, particularly for those that are unable to create direct TCP connections, the WebEx TP layer will automatically create virtual sockets based upon HTTP. This enables the client to communicate with the server through most firewalls.  
         [0084]     Since the HTTP protocol functions on a Request/Response basis, it is always the client that issues the Request command. Hence, in order to provide a bi-directional communication channel, the client actively polls the server in order to fetch the data that may be sent from the server to the client. The details of this implementation are available in the co-pending and commonly-assigned application for a U.S. patent Ser. No. 09/449,011, filed on Nov. 24, 1999, “Emulating a Persistent Connection Using HTTP,” cited and incorporated above.  
         [0085]     If a failure of App server  390   n  is detected, operation  900  proceeds to stage  920 . Otherwise stage  910  is repeated. In stage  920 , meeting manager  350  places any CB servers  380   n  connected to failed App server  390   n  in a suspend state and receives a request for a new App server  390   n  from CB server  380   n  in stage  930 . Meeting manager  350  then requests that process manager  311  launch a new App server  390   n  (stage  940 ). Process manager  311  launches the new App server  390   n  and notifies meeting manager  350  (stage  950 ).  
         [0086]     Once meeting manager  350  has received notification that the new App server  390   n  has been launched, meeting manager  350  resumes (i.e., removes from the suspend state) CB server  380   n  and connects it to the new App server  390   n . (App server state is restored from a backup meeting manager, through any of a number of standard and common means well-known in the art.) Meeting manager continues to monitor the status of App server  390   n  (stage  910 ). Note that all logical server-to-logical server and logical server-to-PM communications employ ZMs  313  and  314 .  
         [0087]      FIG. 10  illustrates the license/log manager failure detection and recovery operation  1000 . First, meeting manager  350  checks whether license manager  360  or log server  370  have failed, using similar techniques to the ones described above in reference to  FIGS. 8 and 9 . If a failure is detected, operation  1000  proceeds to stage  1020 . Otherwise, stage  1010  is repeated until a failure is detected. Meeting manager  350 , in turn, sends a request to process manager  311  to launch a new license manager  360  or log server  370  (stage  1020 ), as required. Stage  1030  then determines whether the new license manager  360  or log server  370  has successfully come on-line, in which case meeting manager  350  continues to monitor the status of license manager  360  and log server  370  (stage  1010 ). Otherwise, stages  1030  and  1040  are repeated until a new license manager  360  or log server  370  has been successfully started.  
         [0088]     Note that the reliable TP layer keeps all data and resends/reloads it into the replacement license and/or log server as needed.  
         [0089]      FIGS. 8-10  thus show how meeting manager  350  monitors the status of other components in its meeting zone  310   n . However, to provide even more effective fault tolerance, the status of meeting manager  350  must also be monitored to prevent a single point of failure in the system. This is accomplished by providing both a primary and one or more standby meeting managers  350  in each meeting zone  310   n . In addition, process manager  311  is responsible for detecting failure of the primary meeting manager  350  and transferring control to one of the backup meeting managers  350 . Operability of the process manager, in turn, is guaranteed by a hardware time-out restart process.  
         [0090]      FIG. 11  illustrates meeting manager failure detection and recovery operation  1100 . In each meeting zone  310   n  (referring to  FIG. 3 ), there is instantiated one primary meeting manager  350  and one or more secondary meeting managers (not shown). Process manager  311  continually checks whether primary meeting manager  350  has failed (stage  1110 ), again using standard failure detection techniques. If a failure of primary meeting manager  350  is in fact detected, operation  1110  proceeds to stage  1120 . Otherwise, stage  1110  is repeated.  
         [0091]     In stage  1120 , process manager  311  launches a new standby meeting manager. The pre-existing standby meeting managers, advised of the failure of primary meeting manager by process manager  311 , elect (through any of several well-known server election or promotion mechanisms) one of their own (step  1140 ) to take over as primary and broadcast an election message (stage  1140 ). One of the standby meeting managers is thus selected as the new primary meeting manager  350  (stage  1150 ). In the event only one standby MM is presently configured, the election message of stage  1140  is simply construed as a command to become the primary MM.  
         [0092]     The standby meeting manager(s)  350 , CB servers  380   n , App server  390   n , ping servers  355 , license manager  360 , and log server  370  in the same meeting zone  310   n  as new primary meeting manager  350  connect to new primary meeting manager  350  (stage  1160 ) and register with it (stage  1170 ) so that the new primary meeting manager can continue to monitor the status of these servers. New primary meeting manager  350  recovers its server state (stage  1180 ) and receives reports from CB servers  380   n  on the status of any active conferences handled by CB servers  380   n  (stage  1190 ). Finally, new primary meeting manager  350  recovers meeting information for all meetings handled in the meeting zone  310   n  (stage  1190 ). Process manager  311  monitors the status of new primary meeting manager  350  (stage  1110 ).  
         [0093]     CB server  380   n  interfaces with client browser  320  through application protocol entities (APEs) joined to agent sessions.  FIG. 12  is a block diagram illustrating the software components of client computers  210   n  and server computers  220   n  ( FIGS. 2A and 2B ) involved in the communications between CB server  380   n  and client browser  320 . In particular, communications channels are established between transaction processing (TP) server  1250  and Application Resource Manager (ARM) server  1240  on server computer  220   n  and TP client  1230  and ARM client  1220  on client computer  210   n . Thus, conference manager  1260  and App server  390   n  (both logically part of CB server  380   n ) communicate with client computer  210   n  via the communication channels maintained by ARM server  1240  and TP server  1250 .  
         [0094]      FIGS. 13A-13C  are flow diagrams illustrating the operation  1300  of CB server  380   n  and App server  390   n  to setup communications with client browser  320  ( FIG. 3 ). First, CB server  380   n  creates an agent session (stage  1305 ). The agent session controls communications from client computer  210   n  to CB server  380   n  and can launch new, additional data sessions if required. To communicate with CB server  380   n , client computer  210   n , in turn, creates an APE (stage  1310 ) and joins the APE to the agent session (stage  1315 ). In stage  1316 , CB server  380   n  sends a list of all existing session to the client computer  210   n ; in stage  1317 , the client must chose whether to join all or only some sessions. If client computer  210   n  joins all sessions, control passes to stage  1320 , shown in  FIG. 13B . If not, stage  1318 , the client joins only selected sessions before control passes to stage  1320 .  
         [0095]     Stage  1320  ( FIG. 13B ) determines whether the user of client computer  210   n  has elected to create a new session (e.g., to share an application), in which case operation  1300  proceeds to stage  1325 . Otherwise, operation  1300  proceeds to stage  1360 . Client computer  210   n  APE then sends a message to the agent session APE of CB server  380   n  requesting a new session (stage  1325 ). CB server  380   n , in turn, requests a new session from App server  390   n  (stage  1330 ) and App server  390   n  creates the new session for the conference (stage  1335 ). App server  390   n  also creates a new APE and joins the new session to the new APE (stage  1340 ). CB server  380   n , in turn, sends the new session&#39;s ID to client computer  210   n  (stage  1345 ). Client computer  210   n  launches an application (stage  1350 ), creates a new APE for the application and joins the new APE to the new session (stage  1355 , referring to  FIG. 13C ).  
         [0096]     Stage  13 G 0  determines if a new client computer  210   n  wants to join an existing session, in which case operation  1300  proceeds to stage  1370 . Otherwise, operation  1300  terminates. Client computer  210   n  requests joining the session (stage  1370 ), concluding operation  1300 .  
         [0097]      FIG. 14  is a block diagram illustrating the communication channels established between client computers  210 A and  210 B during an on-line conference, in accordance with an embodiment of the invention. Client computer  210 A connects to CB server  380 B in meeting zone  310 A via ARM server  1240  and TP server  1250 . In addition, CB server  380 B established a high-speed real-time messaging link  1420  with CB server  380 C in meeting zone  310 B using a real-time messaging service (RTMS)  1410 . In one embodiment of the present invention, RTMS  1410  is implemented using the well-known TCP/IP communications protocol. In some alternate embodiments, the WebEx Transport Protocol, discussed above, is used. CB server  380 C, in turn, connects to client computer  210 B via its own ARM server  1240  and TP server  1250  (not shown).  
         [0098]      FIG. 15  is a flow diagram of operation  1500  for transmitting data from client computer  210 A to client computer  210 B using distributed collaborative computer system  300  ( FIG. 3 ). First, CB server  380 B establishes a link to CB server  380 C using real-time messaging service  1410  (stage  1510 , as illustrated in  FIG. 14 ). The session information is then replicated from CB server  380 B to CB server  380 C (stage  1520 ). Data routed from client computer  210 A is then transmitted from CB server  380 B to CB server  380 C over real-time messaging service  1410  (stage  1530 ). The data received by CB server  380 C is then routed to client computer  210 B using TP server  1250  (stage  1540 ). Stage  1550  then determines if additional data needs to be transmitted from client computers  210 A and  210 B, in which case stages  1530 - 1550  are repeated. Otherwise, operation  1500  terminates.  
         [0099]     Distributed collaborative computer system  300  allows users of client computers  210   n  to participate in on-line conferences by sharing both audio and video signals. In particular, distributed collaborative computer system  300  allows users to share images of a document that can be marked-up by conference participants (document viewing). Document viewing is described in further detail in U.S. Pat. No. 5,577,188 “Method to Provide for Virtual Screen Overlay” and co-pending and commonly-assigned U.S. patent application Ser. Nos. 09/471,938 and 09/591,377 (filed on Dec. 23, 1999 and Jun. 9, 2000, respectively), cited and incorporated above. In addition, users may share control of an application program executed on any of the client computers  210   n  participating in the on-line conference (a process known as application sharing). Application sharing is described in further detail in co-pending and commonly-assigned U.S. patent application Ser. No. 09/442,424 (filed Nov. 17, 1999), cited and incorporated above.  
         [0100]     During document viewing, the presenter may choose to skip one or more pages in the document being viewed.  FIGS. 16A and 16B  are flow diagram illustrating the skip page operation  1600  used to control transmission of pages between the presenter&#39;s client computer  210   n  and other participants&#39; client computers  210   n.    
         [0101]     First, an App server  390   n  providing the document viewing application (also referred to as the docview server) assigns unique IDs to each page in the document being viewed (stage  1605 ,  FIG. 16A ). The page IDs and page content data are then passed to ARM client  1220  and from ARM client  1220  to ARM server  1240  (stage  1610 ). ARM server  1240 , in turn, begins transmitting the document page IDs and data over a shared data queue on high-speed real-time messaging link  1420  (stage  1615 ). The first page ID is then sent to all client computers  210   n  connected to the conference (stage  1620 ). Client computers  210   n , in turn, request the first page data from the shared data queue (stage  1625 ) and CB server  380   n  sends the first page data to client computers  210   n  (stage  1630 ). Stage  1635  then determines whether the presenter has elected to jump to a new page in the shared document, in which case operation  1600  proceeds to stage  1640 . Otherwise, operation  1600  proceeds to stage  1655 . In stage  1640  ( FIG. 16B ), the presenter&#39;s client computer  210   n  broadcasts the new page ID to all client computers  210   n  participating in the conference. The new page data is then transmitted over the shared data queue (stage  1645 ) and client computers  210   n  request the new page from the shared media queue (stage  1650 ).  
         [0102]     Alternatively, stage  1655  determines if all data transmitted on the shared data queue has been received, in which case the docview server is notified (stage  1660 . Otherwise, operation  1600  proceeds to stage  1635 .  
         [0103]     Stage  1665 , in turn, determines whether the shared data queue is no longer needed, in which case the shared data queue is emptied (stage  1670 ) and operation  1600  terminates. Otherwise, operation  1600  proceeds to stage  1635 .  
         [0104]      FIG. 17  is a flow diagram of a client browser operation  1700 , in accordance with some embodiments of the invention. First, client browser  320  receives conference parameters from CB server  380   n  (stage  1710 ). Client browser  320  then connects to CB server  380   n  (stage  1720 ) to participate in the conference. Stage  1730  checks the status of CB server  380   n . If a failure of CB server  380   n  is detected, client browser  320  attempts to reconnect to a new CB server  380   n  (stage  1740 ) and stages  1710 - 1730  are repeated. Otherwise, client browser  320  continues to monitor the status of CB server  380   n.    
         [0105]      FIGS. 18A, 18B ,  18 C 1 - 3 ,  19 A,  19 B,  20 A,  20 B and  20 C are views of web pages displayed by client browser  320  ( FIG. 3 ) during operation of distributed collaborative computer system  300 .  
         [0106]     Meeting center web page  1800  ( FIGS. 18A, 18B  and  18 C 1 - 3 ) is displayed when a user first accesses web server  335  ( FIG. 3 ) through client browser  320 . Meeting center web page  1800  contains a list of current and scheduled meetings the user may want to join. In addition, the user may create a new meeting by selecting create meeting button  1810 , causing a sign in prompt to be displayed in meeting center web page  1800  ( FIG. 18B ). If the user is not already registered with the service, the user can register by selecting new user link  1820 . Otherwise, the user can enter ID and password information in login prompt  1830 . If the user&#39;s data is successfully authenticated with the information stored in web database  337  and/or central operation database  340  ( FIG. 3 ), a create new meeting prompt  1840  is displayed in meeting center web page  1800  (FIGS.  18 C 1 - 3 ). The user can then enter meeting parameters such as date, time, and attendee list by filling in new meeting prompt  1840 . The user can also edit meeting options by selecting edit options button  1850 , thereby causing meeting options web page  1900  ( FIGS. 19A-19B ) to be displayed. Once the user has entered the desired meeting information on meeting center web page  1800 , the user can either schedule the meeting by pressing schedule button  1860  or start the meeting by pressing start now button  1870 .  
         [0107]     Meeting options web page  1900  allows the user to set specific meeting options such as features, client type, frequency and reminders. Once the user is satisfied with the selected options, the user can return to meeting center web page  1800  by pressing submit button  1910 .  
         [0108]     Meeting web page  2000  ( FIGS. 20A-20C ) is displayed to the user during a meeting. Meeting web page  2000  includes a shared pane  2010 , an attendee pane  2020  and a message pane  2030 . Information shared among meeting participants are displayed in shared pane  2010 . The user can share images, documents, applications, web pages, desktops and whiteboards by selecting an appropriate entry from tools menu  2040  ( FIG. 20B ). For example, if the user selects to share an image to be marked up by the meeting participants, the image is displayed in shared pane  2010  ( FIG. 20C ). One or more users can then mark up the image by selecting a drawing tool from drawing menu  2050  and drawing over the image. Attendee pane  2020  contains a list of meeting attendees. Alternatively, attendee pane  2020  can used to display polls taken among the meeting attendees or a video conferencing images. Finally, message pane  2030  can used to compose, send and receive messages among two or more meeting attendees.  
         [0109]     Since conference information is replicated across all CB servers  380   n  handling the conference and can be reconstructed by meeting manager  350 , failure of one or more CB servers  380   n  does not disrupt the conference and can be gracefully recovered. As a result, the distributed collaborative computing system of the present invention eliminates the single point of failure limitation of prior art collaborative computing systems. In addition, since multiple server computers  220   n  are used to handle an on-line conference, the distributed collaborative computing system of the present invention may handle conferences with an arbitrary number of participants, without any limitations imposed by the processing capacity of any single server computer. By contrast, prior art systems were limited to conferences whose participants could all be handled by a single server computer.  
         [0110]      FIG. 21  illustrates one embodiment of a system  2100 . In one embodiment, the system  2100  is embodied within the server  220   n . In another embodiment, the system  2100  is embodied within the electronic device  210   n . In yet another embodiment, the system  2100  is embodied within both the electronic device  210   n  and the server  220   n.    
         [0111]     In one embodiment, the system  2100  includes a resource detection module  2110 , a meeting zone detection module  2120 , a storage module  2130 , an interface module  2140 , a control module  2150 , and a pool manager module  2160 .  
         [0112]     In one embodiment, the control module  2150  communicates with the resource detection module  2110 , the meeting zone detection module  2120 , the storage module  2130 , the interface module  2140 , and the pool manager module  2160 . In one embodiment, the control module  2150  coordinates tasks, requests, and communications between the resource detection module  2110 , the meeting zone detection module  2120 , the storage module  2130 , the interface module  2140 , and the pool manager module  2160 .  
         [0113]     In one embodiment, the resource detection module  2110  detects a pool box that includes resources. In one embodiment, a pool box is a modular container that represents resources for use by the system  2100  for providing collaboration services.  
         [0114]     In one embodiment, the meeting zone detection module  2120  detects a meeting zone that includes resources such as a pool box. In one embodiment, the meeting zone detection module  2120  detects the usage of resources associated with the particular meeting zone.  
         [0115]     In one embodiment, the storage module  2130  stores information relating to the configuration of the pool boxes and the associated meeting zones.  
         [0116]     In one embodiment, the interface module  2140  detects resource requests from clients. Further, the interface module  2140  delivers confirmation signals to the clients.  
         [0117]     In one embodiment, the pool manager module  2160  coordinates and manages resources such as the pool boxes within the meeting zones. In one embodiment, the pool manager module  2160  moves the pool boxes from one meeting zone to another meeting zone depending on demand.  
         [0118]     The system  2100  in  FIG. 21  is shown for exemplary purposes and is merely one embodiment of the invention. Additional modules may be added to the system  2100  without departing from the scope of the invention. Similarly, modules may be combined or deleted without departing from the scope of the invention.  
         [0119]      FIG. 22  illustrates one embodiment of the invention within a system  2200  for use with the system  2100  shown in  FIG. 21 .  
         [0120]     In one embodiment, the system  2200  is embodied within the server  220   n . In another embodiment, the system  2200  is embodied within the electronic device  210   n . In yet another embodiment, the system  2200  is embodied within both the electronic device  210   n  and the server  220   n.    
         [0121]     In one embodiment, the system  2200  includes a pool database  2205 ; pool managers  2210  and  2211 ; a load balancer  2215 ; pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224 ; meeting bridges  2225  and  2226 ; and meeting zone managers  2230  and  2231 . The elements within the system  2200  are shown for illustrative purposes only. For example, the exact number of pool boxes can vary without departing from the invention. Further, elements may be added, deleted, or combined without departing from the invention.  
         [0122]     In one embodiment, the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224  are configured to provide resources. Further, each of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224  are pre-configured with multiple versions of applications such that each of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224  are capable of supporting multiple versions of a collaboration session. For example, any of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224  is capable of supporting multiple versions of a collaboration session. In one embodiment, a pool agent resides within each of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224 . In one embodiment, the pool agent selects the version of the application for use by the pool box for each specific instance.  
         [0123]     In one embodiment, each of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224  is configured to provide resources to one of the meeting zone managers.  
         [0124]     In one embodiment, the meeting bridges  2225  and  2226  are configured to provide interoperability between each of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224  and the meeting zone managers  2230  and  2231 .  
         [0125]     In one embodiment, the meeting zone managers  2230  and  2231  are configured to accept a request from a client to provide resources for a collaboration session. In one embodiment, the meeting zone managers  2230  and  2231  detect the requirements for the collaboration session and request a resource (i.e. one of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224 ) from one of the pool managers  2210  and  2211 . In one embodiment, each of the meeting zone managers  2230  and  2231  are associated with a corresponding meeting zone.  
         [0126]     In one embodiment, the pool managers  2210  and  2211  are configured to detect information relating to the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224  from the pool database  2205 . Further, the pool managers  2210  and  2211  are configured to select one of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224  to provide resources to the client that requests resources from one of the meeting zone managers  2230  and  2231 .  
         [0127]     In one embodiment, the pool database  2205  tracks the status of each of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224 . In one embodiment, the status refers to the availability of the pool boxes  2216 ,  2217 ,  2218 ,  2219 ,  2220 ,  2221 ,  2222 ,  2223 , and  2224 .  
         [0128]     The flow diagram as depicted in  FIG. 23  is one embodiment of the invention. The blocks within the flow diagram can be performed in a different sequence without departing from the spirit of the invention. Further, blocks can be deleted, added, or combined without departing from the spirit of the invention.  
         [0129]     The flow diagram in  FIG. 23  illustrates managing resources within a collaboration system according to one embodiment of the invention.  
         [0130]     In Block  2305 , a resource is requested. In one embodiment, a client requests the resource. Further, the client may be initiating a collaboration session. In one embodiment, the request for a resource is assigned to a particular meeting zone.  
         [0131]     In Block  2310 , the usage of the resources within the requested meeting zone is monitored. In one embodiment, the pool boxes within the requested meeting zone are monitored for usage and capacity.  
         [0132]     In one embodiment, CPU utilization, memory consumption, and bandwidth consumption are parameters monitored on each pool box within the meeting zone to calculate the usage and capacity of this meeting zone. In one embodiment, usage of the pool boxes within a meeting zone is defined by the following equation:  
             Usage   =           (       100   -   CPU     100     )     2     +       (       100   -   Mem     100     )     2     +       (       100   -   Band     100     )     2                 (     Equation   ⁢           ⁢   1     )             
 
 According to Equation 1, the usage measurement on each pool box is calculated utilizing the pool box&#39;s instant availabilities as Euclid&#39;s distance in this three dimensional space as represented by the elements of CPU utilization, memory consumption, and bandwidth consumption. 
 
         [0133]     In one example, the load on each pool box within a meeting zone is equalized such that each pool box within a particular meeting zone carries the same load. In another example, each pool box within the meeting zone is utilized prior to utilizing another pool box within the particular meeting zone.  
         [0134]     In one embodiment, each meeting zone&#39;s capacity and usage is calculated by aggregating the capacity of all of the pool boxes. In another embodiment, each meeting zone&#39;s capacity and usage is calculated based on the number of unused pool boxes assigned to the particular meeting zone.  
         [0135]     In Block  2315 , the capacity of the meeting zone is compared against the upper threshold. In one embodiment, the upper threshold is a percentage of the total capacity of the resource. In one example, the upper threshold is set at 75% such that the upper threshold is set at 75% of the resource&#39;s capacity. Although 75% is utilized as one example, any percentage can be set as the upper threshold.  
         [0136]     If the capacity of the meeting zone is above the upper threshold in Block  2315 , then availability of resources outside of the meeting zone are identified in Block  2320 . In one embodiment, the resource detection module  2110  identifies these resources. In another embodiment, the pool database  2205  and pool managers  2210  and  2211  also identify these resources.  
         [0137]     In Block  2325 , the identified resource outside of the meeting zone is acquired into the particular meeting zone that is above the upper threshold. In one embodiment, the pool managers  2210  and  2211  acquire the resource into the particular meeting zone.  
         [0138]     In Block  2330 , the resource acquired into the meeting zone is provisioned according the client requesting the resource. In one embodiment, the client is requesting the resource for a collaboration session. In one embodiment, the resource is provisioned by the meeting zone manager  2230  or  2231  that corresponds with the particular meeting zone. In one embodiment, each of the resources is pre-configured to support multiple applications such that the particular application requested by the client is readily available from the resources. In another embodiment, each of the resources is pre-configured to support multiple versions of the same application.  
         [0139]     If the capacity of the meeting zone is below the upper threshold in Block  2315 , then the capacity of the meeting zone is compared against the lower threshold in Block  2335 . In one embodiment, the lower threshold is a percentage of the total capacity of the resource. In one example, the lower threshold is set at 25% such that the lower threshold is set at 25% of the resource&#39;s capacity. Although 25% is utilized as one example, any percentage can be set as the lower threshold.  
         [0140]     If the capacity of the meeting zone is below the upper threshold in Block  2335 , then the borrowed resources within the particular meeting zone are identified in Block  2340 . In one embodiment, the resource detection module  2110  identifies these resources. In another embodiment, the pool database  2205  and pool managers  2210  and  2211  also identify these resources. By referring to borrowed resources, there may be any arbitrary number or pool boxes (ie. resources) that are attributed as a core resource of the meeting zone and the remaining resources are borrowed resources. In one example, all the resources within the meeting zone may be considered a borrowed resource.  
         [0141]     In Block  2345 , the borrowed resource within the meeting zone is removed from the particular meeting zone that is below the lower threshold. In one embodiment, the pool managers  2210  and  2211  remove the resource from the particular meeting zone.  
         [0142]     In Block  2350 , the borrowed resource is returned to a general pool of resources where this resource can be acquired into another meeting zone as requested.  
         [0143]     In Block  2355 , the status of the resource whether newly acquired into a meeting zone or removed from a meeting zone is reported and tracked. In one embodiment, the pool database  2205  is utilized for the current status of each resource.  
         [0144]     In use, if a meeting zone&#39;s usage exceeds the upper threshold, then the meeting zone is requesting extra pool box from the pool managers  2210  and  2211 . If meeting zone&#39;s usage drops below the lower threshold, then the meeting zone manager will release the pool box back to one of the pool managers  2210  and  2211 .  
         [0145]     In one embodiment, the meeting zone manager remembers the origin of the pool boxes regarding the pool box&#39;s original zone. In other words, the meeting zone manager is capable of distinguishing between a loaned pool box and an original pool box.  
       ALTERNATE EMBODIMENTS  
       [0146]     The order in which the steps of the present method are performed is purely illustrative in nature. In fact, the steps can be performed in any order or in parallel, unless otherwise indicated by the present disclosure.  
         [0147]     The method of the present invention may be performed in either hardware, software, or any combination thereof, as those terms are currently known in the art. In particular, the present method may be carried out by software, firmware, or microcode operating on a computer or computers of any type. Additionally, software embodying the present invention may comprise computer instructions in any form (e.g., source code, object code, interpreted code, etc.) stored in any computer-readable medium (e.g., ROM, RAM, magnetic media, punched tape or card, compact disc (CD) in any form, DVD, etc.). Furthermore, such software may also be in the form of a computer data signal embodied in a carrier wave, such as that found within the well-known Web pages transferred among computers connected to the Internet. Accordingly, the present invention is not limited to any particular platform, unless specifically stated otherwise in the present disclosure.  
         [0148]     While particular embodiments of the present invention have been shown and described, it will be apparent to those skilled in the art that changes and modifications may be made without departing from this invention in its broader aspect and, therefore, the appended claims are to encompass within their scope all such changes and modifications as fall within the true spirit of this invention.