Personalized conference bridge

FIELD OF THE INVENTION

The present invention relates to personal conference bridges, and in particular to allowing a user to customize their personal conference bridge such that conference participants who connect to the bridge are provided conference information selected by the user.

BACKGROUND OF THE INVENTION

Conference bridges are used to facilitate conference calls between two or more conference participants. In operation, multiple calls from multiple communication terminals are terminated at a conference bridge. In simpler conference bridges, the audio signals from each of the communication terminals are mixed together and provided back to each of the communication terminals. In more advanced conference bridges, the audio levels for the audio signals from the different communication devices are monitored and used to identify one or more of the audio signals to provide as an output to the communication devices. In general, the communication terminal or terminals providing the audio signals having the highest level at any given time are selected as the selected communication terminal. The audio signals from the selected communication terminals are mixed together and delivered all of the communication terminals in the conference. The audio signals from the unselected communication terminals are dropped, and thus, are not provided to the communication terminals. As such, only the audio signals provided by the selected communication terminals are presented to the communication terminals in the conference. At any given time, none of the participants will hear any participants other than those using the selected communication terminals. To avoid distractions, the audio signal from a selected communication terminal is generally not provided back to itself.

As communication technology evolves, the availability and use of conference bridges is dramatically increasing. In many corporate environments, many, if not all, employees are allocated a personal conference bridge. Service providers are also providing personal conference bridges to subscribers in large numbers. A given conference system may support virtually any number of personal conference bridges. A personal conference bridge allows an associated user to host a conference call to allow multiple conference participants to communicate with each at the same time. The user may or may not be a participant in a conference call hosted at her personal conference bridge.

Each personal conference bridge is assigned a unique access code, such as an extension, directory number, or telephony address. Conference participants use the access code, and perhaps a password or code, to gain access to the personal conference bridge. Since the personal conference bridges are generally supported in large numbers by a conference system, the access codes for the numerous personal conference bridges are similar in nature. Since the personal conference bridges are often always active, a conference participant can misdial an access code and enter another personal conference bridge. Accessing the wrong personal conference bridge may lead to interrupting another conference or waiting indefinitely for the other conference participants to join in the conference. In many instances, conference participants are not actually joined into the conference until the host or chairperson has joined; therefore, such waiting may not provide an indication of the error. Further, the automated announcement provided when accessing any personal conference bridge in a given conference system generally sounds the same, regardless of whose personal conference bridge is being used. As such, these announcements provide little or no warning to those conference participants who access the wrong personal conference bridge.

As with any personal communication mechanism, users often want to personalize greetings, announcements, and the like that are routinely presented to others. For example, it is commonplace for users to personalize voicemail greetings, out-of-office alerts, and the like. Given the personalized nature of personal conference bridges and the uniform nature of current conference announcements, there is a need for a mechanism to allow personalization or like customization of personal conference bridges. Such customization would also alert conference participants who access the wrong personal conference bridge of their error as well as provide confirmation to those conference participants joining a conference that they have joined the right conference.

SUMMARY OF THE INVENTION

The present invention allows a user to customize her personal conference bridge such that conference participants who connect to the bridge are provided conference information selected by the user. In particular, after each conference participant gains access to the personal conference bridge, the conference information is delivered to a terminal of the conference participant. Although the user associated with the personal conference bridge may be a conference participant, delivery of conference information to the user is optional. The conference information may be any type of media content, or information identifying the location of media content to present to the conference participants. The media content may include any one or a combination of text, graphics, image, voice, audio, or video content, depending on the capabilities of the personal conference bridge and the conference participant terminals. The media content may remain relatively static or may be dynamically updated on a conference-by-conference basis.

Those skilled in the art will appreciate the scope of the present invention and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the invention, and together with the description serve to explain the principles of the invention.

<figref idrefs="DRAWINGS">FIG. 1</figref> is a block representation of a conference environment according to one embodiment of the present invention.

<figref idrefs="DRAWINGS">FIGS. 2A and 2B</figref> show a communication flow diagram illustrating operation of one embodiment of the present invention.

<figref idrefs="DRAWINGS">FIGS. 3A and 3B</figref> show a communication flow diagram illustrating operation of a second embodiment of the present invention.

<figref idrefs="DRAWINGS">FIGS. 4A and 4B</figref> show a communication flow diagram illustrating operation of a third embodiment of the present invention.

<figref idrefs="DRAWINGS">FIG. 5</figref> is a block representation of a conference bridge according to one embodiment of the present invention.

<figref idrefs="DRAWINGS">FIG. 6</figref> is a block representation of a communication terminal according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the invention and illustrate the best mode of practicing the invention. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.

The present invention allows a user to customize her personal conference bridge such that conference participants who connect to the bridge are provided conference information selected by the user. In particular, after each conference participant gains access to the personal conference bridge, the conference information is delivered to a terminal of the conference participant. Although the user associated with the personal conference bridge may be a conference participant, delivery of conference information to the user is optional. The conference information may be any type of media content, or information identifying the location of media content to present to the conference participants. The media content may include any one or a combination of text, graphics, image, voice, audio, or video content, depending on the capabilities of the personal conference bridge and the conference participant terminals. The media content may remain relatively static or may be dynamically updated on a conference-by-conference basis.

For example, as conference participants gain access to the personal conference bridge of the user, the personal conference bridge may sequentially deliver a uniform resource locator (URL) pointing to a picture of the user as well as stream a personalized greeting provided by the user, a video announcement, and a music selection to the terminals of each of the conference participants. The personalized greeting, the video announcement, and the music selection are sequentially presented to the conference participants through their respective terminals. Each terminal will use the URL to access the picture of the user and present the picture of the user to the respective participants. Alternatively, a simple audio announcement may be presented to the conference participants once they gain access to the personal conference bridge.

Prior to delving into further details of the present invention, an overview of a communication environment <b>10</b> in which the present invention may be employed is described in association with <figref idrefs="DRAWINGS">FIG. 1</figref>. As illustrated, a conference bridge <b>12</b> is capable of supporting conferences involving various conference participants via any number of communication networks, such as the Public Switched Telephone Network (PSTN) <b>14</b>, a voice-over-Internet Protocol (VoIP) network <b>16</b>, as well as a packet-based data network <b>18</b>. Those skilled in the art will recognize various types of wired or wireless communication networks that support packet-based or circuit-switched communications in which the concepts of the present invention may be employed. In particular, the VoIP Network <b>16</b> is merely an example of a voice-over-packet network. Any voice-over-packet network technology may benefit from the present invention.

Users <b>1</b>-<b>5</b> are depicted as being associated with various types of communication terminals, which for clarity are described as either telephony terminals or computing terminals. Those skilled in the art will recognize that a communication terminal may be a dedicated telephony terminal, a dedicated computing terminal, or a hybrid thereof, and may include any type of fixed or mobile telephone, personal computer, personal digital assistant, or the like. As depicted, User <b>1</b> is associated with a telephony terminal <b>20</b> and User <b>2</b> is associated with a telephony terminal <b>22</b>, both of which are supported by the PSTN <b>14</b>. User <b>3</b> is associated with a telephony terminal <b>24</b>, and User <b>4</b> is associated with a computing terminal <b>26</b>, both of which are supported by the VoIP network <b>16</b>. User <b>5</b> is associated with two communication terminals, a computing terminal <b>28</b> and a telephony terminal <b>30</b>. The computing terminal <b>28</b> is supported by the data network <b>18</b>, while the telephony terminal <b>30</b> is supported by the VoIP network <b>16</b>. For the purposes of illustration only, assume the conference bridge <b>12</b> provides one or more personal conference bridges, one of which is allocated to User <b>5</b>. Thus, the conference bridge <b>12</b> provides a personal conference bridge for User <b>5</b>. The personal conference bridge may allow User <b>5</b> to host conference calls involving any conference participants, which may include users <b>1</b>-<b>4</b>.

As indicated above, the present invention allows a user, such as User <b>5</b>, to customize her personal conference bridge such that the conference participants who connect to the bridge are provided with conference information that was selected by the user. The conference information provided to those conference participants who access the personal conference bridge may be provided by one or more data servers <b>32</b>, which are accessible by the conference bridge <b>12</b> in a direct or indirect fashion. Although the data server <b>32</b> is shown as being directly connected to the conference bridge <b>12</b>, this orientation is only provided to represent a logical connection or accessibility. The data server <b>32</b> may be supported by the data network <b>18</b> or other network through which the conference bridge <b>12</b> may gain access to the conference information selected by the user. Alternatively, the data server <b>32</b> can be embedded within the conference bridge <b>12</b>.

In other embodiments, the conference bridge <b>12</b> may access other entities, including communication terminals associated with the user or other entity. Thus, the conference bridge <b>12</b> may store or access virtually any other database or server to obtain conference information that is identified by the user, to provide to conference participants once they gain access to the personal conference bridge provided by the conference bridge <b>12</b>. For clarity in the remaining discussion, the personal conference bridge for User <b>5</b> will be referred to as simply the conference bridge <b>12</b>. Those skilled in the art will recognize that the conference bridge <b>12</b> may operate to provide only one personal conference bridge or multiple personal conference bridges for multiple users.

Depending on the capabilities of the conference bridge <b>12</b>, as well as the communication terminals associated with the various conference participants, the conference information may include or identify virtually any type of media content that may be presented to the conference participants via an associated communication terminal. The communication terminal to which the conference information is provided may be the communication terminal through which the conference participant is accessing the conference bridge <b>12</b>. Alternatively, the confirmation information may be sent to a communication terminal that is associated with a conference participant, but is not being used to access the conference bridge <b>12</b>.

The media content provided in the conference information or identified by the conference information may correspond to text, graphics, image, voice, audio, or video content, which is selected from any source or personally created by the user. For example, the user may record a personalized greeting, and identify a favorite song to play to conference participants while they are on hold and waiting for the conference to begin. If actual media content is not provided in the conference information, the conference information may include a URL, uniform resource identifier, address, pointer, or the like to media content. As such, upon receipt of the conference information, the communication terminal associated with the conference participant may access the media content based on the conference information and then present the media content to the conference participant. Regardless of whether the media content is delivered to the conference participant by the conference bridge <b>12</b> or accessed by the communication terminal of the conference participant in light of the conference information, the conference participant receives customized media content that was selected by the user associated with the conference bridge <b>12</b>. The essence of the present invention is providing the user with flexibility in providing conference information to the conference participants. Those skilled in the art will recognize the tremendous flexibility imparted by the present invention, and that the examples provided herein are merely exemplary and are not intended to limit the invention in any manner.

In addition to storing conference information, whether it is media content or information identifying media content, the data server <b>32</b> may provide a user profile that controls customization of the conference bridge <b>12</b> for User <b>5</b>. If the profile is not stored in the data server <b>32</b> or a like database or server, the profile may be stored at the conference bridge <b>12</b>. The profile will generally dictate when and how to provide conference information to the various conference participants as they gain access to the conference bridge <b>12</b>. Multiple profiles may be maintained for a given user, such that a different customization of the conference interface is provided based on various criteria, including the date, time of day, conference participants, and the like. Further, different conference information may be provided to different conference participants for a given conference. As such, there is tremendous flexibility in maintaining a static profile for all conferences, or dynamically customizing the conference interface on a conference-by-conference or participant-by-participant basis.

Turning now to <figref idrefs="DRAWINGS">FIGS. 2A and 2B</figref> through <b>4</b>A and <b>4</b>B, multiple communication flows are provided to illustrate different customization scenarios. In each of these scenarios, the conference bridge <b>12</b> is providing a personal conference bridge for User <b>5</b>. In the different scenarios, different ones of users <b>1</b>-<b>4</b> gain access to the conference bridge <b>12</b> for a conference, and once access is granted, conference information is provided to the corresponding users via their communication terminals. The type of conference information provided to the communication terminals varies based on the capabilities of the respective communication terminals throughout the different communication flows. In each case, User <b>5</b> is also a conference participant, and is the last participant to join the conference. As conference participants other than User <b>5</b> access the conference bridge <b>12</b>, they are effectively placed on hold until User <b>5</b>, the chairperson, joins the conference. When the chairperson joins the conference, the conference bridge <b>12</b> effectively joins all of the conference participants in conference. In another embodiment, the conference participants could receive the conference information when accessing the conference and then join the conference, even though the chairperson has not joined the conference yet. Similarly, conference participants accessing the conference after the chairperson has joined could receive the conference information and then join the conference.

With reference to <figref idrefs="DRAWINGS">FIGS. 2A and 2B</figref>, assume the conference bridge <b>12</b> is configured to provide a prerecorded personal greeting, and then play selected music to each of the conference participants (User <b>1</b> and User <b>2</b>) as they access the conference bridge <b>12</b>. The personal greeting is a voice-based personal greeting. The personal greeting and the music are presented over the bearer path connecting the conference bridge <b>12</b> to the respective telephony terminals <b>20</b> and <b>22</b> via the PSTN <b>14</b>.

Initially, the telephony terminal <b>20</b> of User <b>1</b> will connect to the conference bridge <b>12</b> (step <b>100</b>), wherein a bearer path is established between the conference bridge <b>12</b> and the telephony terminal <b>20</b> (step <b>102</b>). User <b>1</b> will enter an access code identifying the personal conference bridge of User <b>5</b>, and the telephony terminal <b>20</b> will deliver dual-tone multi-frequency (DTMF) digits corresponding to the access code to the conference bridge <b>12</b> over the bearer path (step <b>104</b>). The conference bridge <b>12</b> will grant User <b>1</b> access to the personal conference bridge of User <b>5</b>, as well as send a message to the data server <b>32</b> to retrieve conference information for User <b>5</b> (step <b>106</b>). The data server <b>32</b> will access the conference information for User <b>5</b> and provide it to the conference bridge <b>12</b> (step <b>108</b>). In this instance, the conference information includes the media content for the personal greeting and selected music to present to the conference participants. As such, the conference bridge <b>12</b> will begin playing the personal greeting for User <b>5</b> over the bearer path connecting to telephony terminal <b>20</b> (step <b>110</b>). When the personal greeting is completed, the conference bridge will begin playing the selected music over the bearer path to telephony terminal <b>20</b> (step <b>112</b>).

In similar fashion, User <b>2</b> may initiate a connection to the conference bridge <b>12</b> for the conference via telephony terminal <b>22</b> (step <b>114</b>), and a bearer path is established between the conference bridge <b>12</b> and the telephony terminal <b>22</b> (step <b>116</b>). User <b>2</b> will enter the access code for User <b>5</b>'s personal conference bridge (step <b>118</b>), and the conference bridge will associate the connection with the personal conference bridge and begin playing the personal greeting over the bearer path connected to telephony terminal <b>22</b> (step <b>120</b>). Once the personal greeting is complete, the conference bridge <b>12</b> will begin playing the select music over the bearer path connected to telephony terminal <b>22</b> (step <b>122</b>).

At this point, assume that User <b>5</b> connects to the conference bridge <b>12</b> (step <b>124</b>), and a bearer path is established between the conference bridge <b>12</b> and the telephony terminal <b>30</b> of User <b>5</b> (step <b>126</b>). User <b>5</b> will provide the access code for the personal conference bridge (step <b>128</b>), and the conference bridge <b>12</b> will associate the connection with the personal conference bridge of User <b>5</b>. User <b>5</b> may also enter a passcode, which identifies User <b>5</b> as the chairperson, or owner of the personal conference bridge (step <b>130</b>). The conference bridge <b>12</b> will recognize User <b>5</b> as the chairperson and initiate the conference. Initiating the conference may entail stopping the playback of any music while the conference participants, User <b>1</b> and User <b>2</b>, were on hold, and joining each of the bearer paths connecting to each of the telephony terminals <b>20</b>, <b>22</b>, <b>30</b> for users <b>1</b>, <b>2</b>, and <b>5</b>, respectively, to facilitate the conference call (steps <b>132</b>, <b>134</b>, and <b>136</b>).

Turning now to <figref idrefs="DRAWINGS">FIGS. 3A and 3B</figref>, another communication flow is illustrated. In this example, the conference involves users <b>3</b>, <b>4</b>, and <b>5</b>. The telephony terminals <b>24</b>, <b>26</b>, and <b>30</b> are assumed to have multimedia capability, and are supported by the VoIP network <b>14</b>. The multimedia capability in this example includes presenting audio as well as displaying images and video to the respective users via the telephony terminals <b>24</b>, <b>26</b>. The conference information is again obtained from the data server <b>32</b>; however, in this example the conference information includes a voice-based personal greeting, identification information for a picture of User <b>5</b>, and a video, all of which were selected by User <b>5</b>. All of this information may be retrieved from the data server <b>32</b> or from other sources based on information obtained from the data server <b>32</b>.

Initially, assume that User <b>3</b> connects to the conference bridge <b>12</b> via telephony terminal <b>24</b> (step <b>200</b>), and a bearer path is established therebetween (step <b>202</b>). When the conference bridge <b>12</b> receives the access code, perhaps via DTMF tones, identifying the personal conference bridge for User <b>5</b> (step <b>204</b>), the conference bridge <b>12</b> associates the connection with the personal conference bridge of User <b>5</b>. The conference bridge <b>12</b> will send a message to the data server <b>32</b> to retrieve conference information for User <b>5</b> (step <b>206</b>). The data server <b>32</b> will send the conference information for User <b>5</b> to the conference bridge <b>12</b> (step <b>208</b>).

As noted, the conference information will include a personal greeting, identification of a picture for User <b>5</b>, and a video to present to the conference participants. Accordingly, the conference bridge <b>12</b> will initially stream the personal greeting for User <b>5</b> to the telephony terminal <b>24</b> (step <b>210</b>). Before, during, or after the personal greeting is delivered, the conference bridge <b>12</b> may deliver the identification information for the picture of User <b>5</b> to the telephony terminal <b>24</b> (step <b>212</b>). Since the bearer path is essentially a packet-based communication session, the personal greeting may be delivered over the communication session, while control information, such as the identification of the picture of User <b>5</b>, may be delivered within the communication session or in association with the communication session using any appropriate protocol, such as the Session Initiation Protocol (SIP). If SIP is employed, the identification information for the picture may be provided in a SIP Information (INFO) message. Upon receiving the identification information for the picture of User <b>5</b>, the telephony terminal <b>24</b> may access the data server <b>32</b> or other entity to obtain the actual media content representing the picture or image of User <b>5</b> and present it to User <b>3</b> via the telephony terminal <b>24</b> or other associated communication terminal. After the personal greeting and picture identification are presented, the conference bridge <b>12</b> may deliver the video to User <b>3</b> via telephony terminal <b>24</b> (step <b>214</b>).

A similar process is provided when User <b>4</b> accesses the personal conference bridge for User <b>5</b>. As such, computing terminal <b>26</b> will connect to the conference bridge <b>12</b> (step <b>216</b>), and a bearer path is established therebetween (step <b>218</b>). Upon receiving the access code from User <b>4</b> via the computing terminal <b>26</b> (step <b>220</b>), the conference bride <b>12</b> will begin playing the personal greeting for User <b>5</b> over the bearer path (step <b>222</b>) as well as delivering the identification information for the picture of User <b>5</b> in a SIP INFO message to computing terminal <b>26</b> (step <b>224</b>). As described above, the computing terminal <b>26</b> may use the identification for the picture of User <b>5</b> to obtain the actual content providing the picture or image of User <b>5</b> and present it to User <b>4</b>. When the personal greeting is completed and the picture identification has been delivered, the conference bridge <b>12</b> may begin delivering the video to computing terminal <b>26</b> (step <b>226</b>). Presentation of the personal greeting, the picture of User <b>5</b>, and the video may take place sequentially or simultaneously, depending on the capabilities of the computing terminal <b>26</b> and the conference bridge <b>12</b>, as well as the desires of the user.

At this point, assume that User <b>5</b> connects to the conference bridge <b>12</b> (step <b>228</b>), and a bearer path is established between the conference bridge <b>12</b> and the telephony terminal <b>30</b> of User <b>5</b> (step <b>230</b>). User <b>5</b> will provide the access code for the personal conference bridge (step <b>232</b>), and the conference bridge <b>12</b> will associate the connection with the personal conference bridge of User <b>5</b>. User <b>5</b> may also enter a passcode, which identifies User <b>5</b> as the chairperson, or owner of the personal conference bridge (step <b>234</b>). The conference bridge <b>12</b> will recognize User <b>5</b> as the chairperson and initiate the conference. Initiating the conference may entail stopping the playback of any video while the conference participants, User <b>3</b> and User <b>4</b>, were on hold, and joining each of the bearer paths connecting to each of the telephony terminals <b>24</b>, <b>26</b>, <b>30</b> for users <b>3</b>, <b>4</b>, and <b>5</b>, respectively, to facilitate the conference call (steps <b>236</b>, <b>238</b>, and <b>240</b>).

In the communication flow of <figref idrefs="DRAWINGS">FIGS. 4A and 4B</figref>, the conference bridge <b>12</b> is configured to obtain conference information from computing terminal <b>28</b>, which is associated with User <b>5</b>. Further, the computing terminal <b>28</b> is a multimedia compliant communication terminal that is capable of supporting voice communications, such that User <b>5</b> can participate in a conference via the computing terminal <b>28</b>. In this example, the conference bridge <b>12</b> is configured to automatically connect computing terminal <b>28</b> to the personal conference bridge after one or more conference participants have accessed the personal conference bridge for a conference. The conference may be an audio conference or an audio conference associated with video conferencing.

Initially, assume telephony terminal <b>24</b> of User <b>3</b> connects to the conference bridge <b>12</b> (step <b>300</b>), and a bearer path is established (step <b>302</b>). Upon receiving an access code from User <b>3</b> (step <b>304</b>), the conference bridge <b>12</b> will automatically connect computing terminal <b>28</b> into the conference bridge (step <b>306</b>). As a result, a bearer path is established between the conference bridge <b>12</b> and the computing terminal <b>28</b> (step <b>308</b>). The conference bridge <b>12</b> may be able to obtain caller identification information or other identification information from User <b>3</b>, and provide a SIP INFO message to computing terminal <b>28</b> indicating that User <b>3</b> has joined a conference (step <b>310</b>). The computing terminal <b>28</b> may provide an alert to User <b>5</b> that User <b>3</b> has joined a conference supported by the personal conference bridge (step <b>312</b>).

Meanwhile, the conference bridge <b>12</b> may retrieve conference information from computing terminal <b>28</b> (step <b>314</b>). The computing terminal <b>28</b> will provide the conference information for User <b>5</b> to the conference bridge <b>12</b> (step <b>316</b>). Assuming the conference information includes a personal greeting, identification for a picture of User <b>5</b>, and selected music, the conference bridge <b>12</b> will begin playing the personal greeting (step <b>318</b>) and provide the identification for a picture of User <b>5</b> in a SIP INFO message to telephony terminal <b>24</b> (step <b>320</b>).

In this example, the computing terminal <b>28</b> may maintain control of the particular information that is presented to the conference participants. As such, the computing terminal <b>28</b> may begin playing a “music on hold” selection (step <b>322</b>), which is delivered to the conference bridge <b>12</b> (step <b>324</b>), which in turn forwards the music on hold over the bearer path to the telephony terminal <b>24</b> (step <b>326</b>). Thus, the conference bridge <b>12</b> is effecting delivery of the music on hold, while the computing terminal <b>28</b> acts as the source of the streaming content as well as the conference information used to control the interface presented to the conference participants.

Similarly, User <b>4</b> will connect to the conference bridge <b>12</b> via computing terminal <b>26</b> (step <b>328</b>), and a bearer path is established between the conference bridge <b>12</b> and the computing terminal <b>26</b> (step <b>330</b>). Upon receiving the access code from User <b>4</b> (step <b>332</b>), the conference bridge <b>12</b> will associate the connection with the personal conference bridge of User <b>5</b> and send a SIP INFO message to the computing terminal <b>28</b> to indicate that User <b>4</b> has joined the conference (step <b>334</b>). The computing terminal <b>28</b> may provide an alert to User <b>5</b> indicating that User <b>4</b> has joined the conference (step <b>336</b>).

Meanwhile, the conference bridge <b>12</b> will provide the personal greeting to computing terminal <b>26</b> (step <b>338</b>) as well as deliver the identification information for the picture of User <b>5</b> in a SIP INFO message (step <b>340</b>). Once the personal greeting is complete, the conference bridge <b>12</b> may begin streaming the music on hold to computing terminal <b>26</b> for presentation to User <b>4</b> (step <b>342</b>). Notably, since the computing terminal <b>28</b> is streaming the music on hold content, the conference bridge <b>12</b> may present the music on hold in progress to User <b>4</b>. In other words, the conference bridge <b>12</b> may simply begin replicating the packets received from the computing terminal <b>28</b> to computing terminal <b>26</b> and telephony terminal <b>24</b> when User <b>4</b> joins the conference.

At this point, users <b>3</b> and <b>4</b> are on hold. When User <b>5</b> decides to join the conference, User <b>5</b> may enter the conference via a softclient, which is a communication application running on the computing terminal <b>28</b> (step <b>344</b>). Since the computing terminal <b>28</b> is already connected to the personal conference bridge provided by the conference bridge <b>12</b>, the computing terminal <b>28</b> may only need to send a SIP INFO message or the like to indicate that the chairperson is joining the conference (step <b>346</b>). The conference bridge <b>12</b> will recognize User <b>5</b> as the chairperson and begin receiving voice and associated video from the computing terminal <b>28</b> for a video conference (step <b>348</b>). At this point, the conference bridge <b>12</b> will join each of the users <b>3</b>, <b>4</b>, and <b>5</b> into the conference (steps <b>350</b>, <b>352</b>, and <b>354</b>).

With reference to <figref idrefs="DRAWINGS">FIG. 5</figref>, a block representation of a conference bridge <b>12</b> is illustrated according to one embodiment of the present invention. The conference bridge <b>12</b> includes a control system <b>34</b> having sufficient memory <b>36</b> for the requisite software <b>38</b> and data <b>40</b> to operate as described above. The control system <b>34</b> is also associated with one or more communication interfaces <b>42</b> to facilitate communications with the various communication terminals as well as with other communication nodes directly or indirectly associated with the any of the communication networks. The conference bridge <b>12</b> may represent a single personal conference bridge or a system capable of supporting multiple personal conference bridges.

With reference to <figref idrefs="DRAWINGS">FIG. 6</figref>, a block representation of a communication terminal <b>44</b>, such as the telephony terminals <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b>, and <b>30</b> or the computing terminal <b>28</b>, is depicted. The communication terminal <b>44</b> may include a control system <b>46</b> having sufficient memory <b>48</b> for the requisite software <b>50</b> and data <b>52</b> to operate as described above. The control system <b>46</b> may be associated with a communication interface <b>54</b> to facilitate communications directly or indirectly with the conference bridge <b>12</b> or other communication nodes, as well as a user interface <b>56</b> to facilitate interaction with one or more users associated with the communication terminal <b>44</b>. The user interface <b>56</b> may include an input device <b>58</b>, display <b>60</b>, microphone (MIC) <b>62</b>, and speaker <b>64</b>, to facilitate bidirectional audio communications, including voice, as well as provide information to the user and receive information from the user.

Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present invention. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.