Push-to-talk communications in computing environments

BACKGROUND

The Internet has achieved widespread acceptance with the consuming public. Today people routinely communicate via the Internet using email and instant messaging. Email is considered an asynchronous method of communication because the parties involved in the communication do not necessarily need to be engaged in the communication at the same time. In contrast, in a synchronous method of communication, both parties involved in the communication need to be engaged at the same time (e.g., telephone conversation or a face-to-face conversation). Instant messaging provides another method of communication that is semi-synchronous. Instant messaging is a semi-synchronous method of communication because both parties may be aware of the other party, but do not need to be fully engaged in the conversation. For example, one party may be aware that the other party is engaging in the conversation by observing the status of the other party (e.g., typing text). However, the communication does not occur until the actual typed text is sent. In another example, each party is aware of the other parties that are available for communication based on the other parties' log-on status. While instant messaging is a semi-synchronous method of communication, it may also operate in an asynchronous communication manner. This occurs, for example, when one party sends an instant message to another party who is offline. The other party is unaware of the message until logging on at a later time.

Therefore, one can see that instant messaging provides a communication experience that is different than other communication mechanisms (e.g., email, telephone, etc). However, even with all the communication mechanisms available today, consumers still remain interested in new communication mechanisms that provide them with different communication experiences.

SUMMARY

The present communication mechanism provides push-to-talk functionality for mobile and desktop computing environments and offers a new communication experience for consumers. Mobile and desktop computers are configured as client computers in a client/server architecture. Some of the client computers are configured to handle multiple push-to-talk sessions simultaneously. If multiple streams from different sessions are active at the same time, the client computer may determine which of these overlapped streams to record and then record them for later playback. A server handles the registration of the client computers, manages the multiple sessions for each of the client computers, and performs a floor control process so that each push-to-talk session operates in a half-duplex mode.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

<figref idrefs="DRAWINGS">FIG. 1</figref> is an illustrative computing device that may be used to implement the communication techniques and mechanisms described herein.

<figref idrefs="DRAWINGS">FIG. 2</figref> is an illustrative architecture in which the present push-to-talk communication mechanism may be implemented using several of the computing devices shown in <figref idrefs="DRAWINGS">FIG. 1</figref> configured in a client-server architecture.

<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram illustrating push-to-talk components of the server computing device and the client computing device shown in <figref idrefs="DRAWINGS">FIG. 2</figref>.

<figref idrefs="DRAWINGS">FIG. 4</figref> is a time sequence diagram illustrating a floor control process within the floor control component of the server computing device shown in <figref idrefs="DRAWINGS">FIG. 3</figref>.

<figref idrefs="DRAWINGS">FIG. 5</figref> is a flow diagram illustrating an exemplary process for establishing a push-to-talk session on a client computing device shown in <figref idrefs="DRAWINGS">FIG. 2</figref>.

<figref idrefs="DRAWINGS">FIG. 6</figref> is an exemplary graphical user interface suitable for use in <figref idrefs="DRAWINGS">FIG. 5</figref> to invoke an outgoing session.

<figref idrefs="DRAWINGS">FIG. 7</figref> is another exemplary graphical user interface suitable for use in <figref idrefs="DRAWINGS">FIG. 5</figref> to invoke an outgoing session.

<figref idrefs="DRAWINGS">FIG. 8</figref> is a flow diagram illustrating a monitoring process suitable for use in <figref idrefs="DRAWINGS">FIG. 5</figref> to invoke an outgoing session.

<figref idrefs="DRAWINGS">FIG. 9</figref> is an exemplary graphical user interface for a one-session capable client computing device.

<figref idrefs="DRAWINGS">FIG. 10</figref> is a timing diagram that illustrates logic for handling incoming and outgoing audible streams in a one-session capable client computing device.

<figref idrefs="DRAWINGS">FIG. 11</figref> is an exemplary graphical user interface for a multi-session capable client computing device.

<figref idrefs="DRAWINGS">FIG. 12</figref> is a series of timing diagrams that illustrate logic for handling incoming and outgoing streams for multiple sessions in a multi-session capable client computing device.

<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow diagram illustrating an exemplary process for managing streams in push-to-talk sessions in accordance with the timing diagrams shown in <figref idrefs="DRAWINGS">FIGS. 10 and 12</figref>.

DETAILED DESCRIPTION

The following description is directed at a communication mechanism for providing push-to-talk functionality on mobile and desktop computing environments. The mobile and desktop computing environments include client computing devices configured in a client-server architecture with a server computing device. The server computing device is configured to handle registration, floor control, and session management. The push-to-talk functionality allows an outgoing session to be initiated upon recognition of a person's name and/or upon selection of a person's name from a user-interface on the client computing device. Incoming push-to-talk streams may be saved to a computer-readable storage media for later playback if another stream is already playing. Specific implementations of the push-to-talk communication concept that operate in various computing environments will now be described.

Exemplary Computing Device

<figref idrefs="DRAWINGS">FIG. 1</figref> is an illustrative computing device that may be used to implement the communication techniques and mechanisms described herein. The system includes a computing device, such as computing device <b>100</b>. In a very basic configuration, computing device <b>100</b> typically includes at least one processing unit <b>102</b> and system memory <b>104</b>. Depending on the exact configuration and type of computing device, system memory <b>104</b> may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.;) or some combination of the two. System memory <b>104</b> typically includes an operating system <b>106</b>, one or more program modules <b>108</b>, and may include program data <b>110</b>. The program modules <b>108</b> may include one or more components <b>140</b> for implementing the present push-to-talk functionality. This basic configuration is illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref> by those components within dashed line <b>112</b>.

Computing device <b>100</b> may have additional features or functionality. For example, computing device <b>100</b> may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref> by removable storage <b>120</b> and non-removable storage <b>122</b>. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory <b>104</b>, removable storage <b>120</b> and non-removable storage <b>122</b> are all examples of computer storage media. Thus, computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device <b>100</b>. Any such computer storage media may be part of device <b>100</b>. Computing device <b>100</b> may also have input device(s) <b>124</b> such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) <b>126</b> such as a display, speakers, printer, etc. may also be included. These devices are well know in the art and need not be discussed at length here.

Computing device <b>100</b> may also contain communication connections <b>128</b> that allow the device to communicate with other computing devices <b>130</b>, such as over a network. Communication connection(s) <b>128</b> is one example of communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Computer readable media can be any available media that can be accessed by a computer. By way of example, and not limitation, computer readable media may comprise “computer storage media”.

Various modules and techniques may be described herein in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. for performing particular tasks or implement particular abstract data types. These program modules and the like may be executed as native code or may be downloaded and executed, such as in a virtual machine or other just-in-time compilation execution environment. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. An implementation of these modules and techniques may be stored on or transmitted across some form of computer readable media.

Exemplary System Architecture

<figref idrefs="DRAWINGS">FIG. 2</figref> is an illustrative architecture <b>200</b> in which two or more computing devices, such as computing device <b>100</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, are arranged to implement the present push-to-talk mechanism. The computing device may be a mobile device, a desktop device, a server computer, or the like. The architecture <b>200</b> includes one or more client computing devices (e.g., client computing devices <b>202</b>-<b>210</b>) and one or more server computing devices (e.g., server computing device <b>212</b>). The server computing device <b>212</b> accesses a member list <b>214</b> to maintain information about members that are registered to utilize a push-to-talk service <b>216</b>. The member list <b>214</b> is stored on computer-readable storage media accessible to the server computing device <b>212</b>. The client computing devices and the server computing devices communicate over a network <b>220</b>, such as a LAN and/or Internet, that implements an internet protocol <b>222</b>. In one embodiment, the client computing devices and the server computing devices are arranged in a client/server architecture. Even though only one server computing device is shown in <figref idrefs="DRAWINGS">FIG. 2</figref>, one skilled in the art will appreciate that the functionality provided by the server computing device may be provided using multiple distributed computing devices. Typically, the server computing device <b>212</b> is positioned in the public domain, instead of behind a firewall, so that the client computing devices may connect to it.

Push-to-Talk Mechanism

<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram illustrating push-to-talk components <b>300</b> and <b>310</b> of the server computing device and client computing device shown in <figref idrefs="DRAWINGS">FIG. 2</figref>, respectively. The server push-to-talk components <b>300</b> correspond to the one or more components <b>140</b> for implementing the present push-to-talk functionality described in the general description of a computing device in <figref idrefs="DRAWINGS">FIG. 1</figref>. The push-to-talk components <b>300</b> include a user registration module <b>302</b>, a session control module <b>304</b>, and a floor control module <b>306</b>. The user registration module <b>302</b> is configured to register users as members of the push-to-talk service. The registration process occurs when users on the client computing devices log on to the server. The server obtains their IP address and other pertinent information. The IP address and other information are then stored in the member list. The registration module <b>302</b> is also configured to provide status of an arbitrary member to any requesting client and to retrieve the member list when queried. This type of registration process is well known and is commonly used for registering members for instant messaging service.

The session control module <b>304</b> is configured to manage the sessions between the client computing devices. As will be described below, some client computing devices are configured for communicating in one session at a time (hereinafter referred to as one session capable computing devices). Other client computing devices are configured for communicating between multiple sessions at a time (hereinafter referred to as multi-session capable computing devices). The session control module is responsible for maintaining each of these sessions. The session control module is responsible for session start-up, session termination, adding a member to a session, and removing a member from a session. The floor control module <b>306</b> is configured to ensure that only one party is talking in a session at one time. Thus, the floor control module ensures that each push-to-talk session operates in a half-duplex mode.

The client push-to-talk components <b>310</b> correspond to the one or more components <b>140</b> for implementing the present push-to-talk functionality described in the general description of a computing device in <figref idrefs="DRAWINGS">FIG. 1</figref>. The client push-to-talk components <b>310</b> include a graphical user-interface module <b>312</b>, a push-to-talk session module <b>314</b>, a recording module <b>316</b>, and a playback module <b>318</b>. The client push-to-talk components <b>310</b> are described below in more detail, as needed.

<figref idrefs="DRAWINGS">FIG. 4</figref> is a time sequence diagram illustrating a floor control process within the floor control component of the server computing device shown in <figref idrefs="DRAWINGS">FIG. 3</figref>. The floor control process occurs after a session has been established between two or more parties. As will be described below in conjunction with <figref idrefs="DRAWINGS">FIG. 5</figref>, there are various ways in which a session can become established. However, once a session is established, the floor control process shown in <figref idrefs="DRAWINGS">FIG. 4</figref> begins processing. The floor control process may be configured to be compatible with the floor control specification in the Open Mobile Alliance Push-to-Talk over Cellular (OMA PoC) standard.

The time sequence diagram has three vertical lines <b>402</b>-<b>406</b>. The first vertical line <b>402</b> (hereinafter referred to as client A) represents a client computing device on which the client push-to-talk components reside. The second vertical line <b>404</b> (hereinafter referred to as server <b>404</b>) represents a server computing device on which the server push-to-talk components reside. The third vertical line <b>406</b> (hereinafter referred to as client B) represents another client computing device on which the client push-to-talk components reside. The time sequence diagram illustrates the floor control process within the floor control component of the server computing device for controlling the floor between client A and client B during one session.

The floor control process begins with action <b>402</b>. Action <b>402</b> occurs at client A, such as depressing a talk button on a graphical user interface. Action <b>402</b> invokes a floor request signal <b>412</b> from client A to the server. As long as no other client in the session has already been granted the floor, the server will send a floor grant signal <b>420</b> back to client A and a floor taken signal <b>422</b> to any of the other clients, such as client B. Upon receiving the floor grant signal, client A may hear an audible beep to indicate that it has been granted the floor. Likewise, client B may hear a different audible beep to indicate that someone else has been granted the floor. This process prevents two clients from taking the floor at the same time. Once the floor has been taken, the client who has been granted the floor will begin talking. The talking alerts other clients that the floor has been taken and is unavailable.

However, before the floor has been granted, another client (e.g., client B) may perform an action <b>414</b> that invokes a floor request signal <b>416</b>. When the server receives this floor request signal <b>416</b>, the server is aware that client A has already requested the floor. Therefore, the server sends client B a floor deny signal <b>418</b>. A floor deny signal occurs whenever another client has already started the process for requesting the floor or currently has the floor. For example, later, if client B again performs an action <b>424</b> that invokes a floor request signal <b>426</b>, the server will once again send a floor deny signal <b>428</b> back to client B. Until client A performs an end action <b>430</b>, the server rejects any other client from communicating. When the end action <b>430</b> is initiated, a floor release signal <b>432</b> is sent to the server from client A. The floor release signal <b>432</b> notifies the server that client A no longer wants control of the floor. In other words, client A has ended its audible stream. The server then updates the floor status of the session and sends a floor idle signal <b>434</b> to each of the other clients notifying them that the floor is now open for anyone to communicate. When the floor idle signal <b>434</b> is received by the clients, the clients may hear a distinct beep indicating that the floor is now open.

<figref idrefs="DRAWINGS">FIG. 5</figref> is a flow diagram illustrates an exemplary process <b>500</b> for establishing a push-to-talk session. Process <b>500</b> begins at block <b>502</b> where a push-to-talk session is invoked to establish a push-to-talk session with one or more users. Invoking the push-to-talk session may be performed in various manners. <figref idrefs="DRAWINGS">FIGS. 6-8</figref> provide three exemplary methods for invoking the push-to-talk session. Processing continues at decision block <b>504</b>.

At decision block <b>504</b>, a determination is made whether the other users are registered members with the push-to-talk service. This may involve querying the server to obtain a list of members and then checking whether the users are identified on the list. In another embodiment, information about the other users may be sent to the server who determines whether the users are registered. If it is determined that one of the users is not a registered user, processing continues at block <b>506</b>.

At block <b>506</b>, a message may be displayed that alerts the user who attempted to establish the session that one or more of the users are not registered users. At that point, establishing the push-to-talk session may fail entirely and proceed to the end. Alternatively, the user that was not a registered member may be removed as a party to the session and processing may continue at block <b>508</b>. If all the users are registered users, processing continues at block <b>508</b>.

At block <b>508</b>, an outgoing push-to-talk session is initiated between the user and the other registered users. The connections between the users and the other registered users are made using well known techniques. These connections are between each user and the server. The server then receives the audio streams and relays them to the correct parties. Processing is then complete.

<figref idrefs="DRAWINGS">FIG. 6</figref> is an exemplary graphical user interface suitable for use within <figref idrefs="DRAWINGS">FIG. 5</figref> to invoke an outgoing session. The exemplary graphical user interface may be displayed on a client computing device upon selecting an icon, menu item, or the like. A window <b>600</b> displays a Recent Contacts directory <b>602</b> that lists members that the user has recently communicated using a push-to-talk session. In addition, the window <b>600</b> may display an All Contacts directory <b>604</b> that lists members that are currently logging on the server for the push-to-talk service. Window <b>600</b> may also include other directories, such as a Friends directory (not shown), a Work directory (not shown), and/or the like. A member (e.g., Brian) may be selected from any directory. A key combination may also be used to select multiple members. Once all the members that are desired in the session have been selected, the OK button <b>610</b> is selected. This sends a message to the server so that the server can add an entry to the active session table.

<figref idrefs="DRAWINGS">FIG. 7</figref> is an exemplary graphical user interface suitable for use within <figref idrefs="DRAWINGS">FIG. 5</figref> to invoke an outgoing session. Typically, the drop-down menu <b>700</b> appears while within an application that is configured to recognize names. These applications, such as a word processing application or email application, may add an indicator with the recognized name, such as adding a dashed line under the recognized name. The dashed line then indicates that additional actions are available in conjunction with the recognized name. These additional actions appear as menu items in the drop-down menu <b>700</b>, such as sending an email to the recognized name (item <b>702</b>), scheduling a meeting with the recognized name (<b>704</b>), and the like. A script is written to add a menu item <b>710</b> to the drop-down menu <b>700</b> that initiates a push-to-talk session with the recognized name. Upon selecting the “Start Push-to-Talk” menu item, the recognized name is sent to the server to verify that the recognized name is a registered member. If the recognized name is not a registered member, a message may appear stating that the person is not registered for push-to-talk communication. However, if the person is registered, the session control module will initiate a session with that person. In one embodiment, the application may support SMART TAG technology provided within MICROSOFT OFFICE software manufactured by Microsoft Corporation located in Redmond, Wash.

<figref idrefs="DRAWINGS">FIG. 8</figref> is a flow diagram illustrating a monitoring mechanism suitable for use within <figref idrefs="DRAWINGS">FIG. 5</figref> to invoke an outgoing session. Process <b>800</b> begins at block <b>802</b> where a monitoring process is invoked to run on the client computing device. In general, the monitoring process may perform in various ways. For example, the monitoring process may monitor a clipboard provided by the operating system executing on the client computing device. In this embodiment, the monitoring process monitors the clipboard at text is cut or copied to it from within one or more applications. In another embodiment, the monitoring process may monitor each of the windows displayed on the screen of the client computing device. Clipboard monitoring and screen monitoring processes are well known and need not be described in further detail. Processing continues at block <b>804</b>.

At block <b>804</b>, the content obtained from the monitoring process is checked. This may occur upon receiving an event (e.g., event that content had been cut or copied) or may occur based on a time-interval. Processing continues at decision block <b>806</b>.

At decision block <b>806</b>, a determination is made whether the content contains text that is recognized as a person's name. This may be done thru a look-up of common names, heuristics, or the like. If the content does not contain a person's name, the process loops back to block <b>804</b> to continue monitoring. Otherwise, the process continues to block <b>808</b>.

At block <b>808</b>, the recognized name is set as the other user to whom the push-to-talk communication is to be established. Processing then returns. Thus, as described above, the present communication mechanism allows a session to be initiated whenever a name is recognized. Once a name is recognized, an in-context communication may be invoked that initiates the session. The in-context communication allows users to communicate on a specific topic with other users where the topic is presented. For example, a user can discuss a word-processing document with the author of the word-processing document while within the word-processing application. This is in contrast to current technologies where users initiate sessions within a specific messaging application.

<figref idrefs="DRAWINGS">FIG. 9</figref> is an exemplary graphical user interface for a one-session capable client computing device. Because some client computing device may have limited computing capability and/or screen size in certain configurations, the push-to-talk client components may limit the client computing device to one active session at a time. This may occur when the client computing device is a mobile computing device. Client computing devices that are limited to one active session are hereinafter referred to as one-session capable client computing devices.

One embodiment of a graphical user interface for a one-session capable client computing device is shown in <figref idrefs="DRAWINGS">FIG. 9</figref>. The graphical user interface <b>900</b> combines a contact list with an active session window to provide a single user interface for the push-to-talk client application. Thus, graphical user interface <b>900</b> includes a list box <b>902</b> with a scroll bar <b>904</b>. The list box <b>902</b> includes a member push button (e.g., member pushbutton <b>906</b> for Alice) for each member that has been registered on the server. Alternatively, the list box <b>902</b> may include a member push button for each member that has been registered on the server and that has been identified as a member that the user of the client computing device is interested in communicating with at some time. The list box <b>902</b> also includes a check box (e.g., check box <b>908</b>) that is associated with one of the member push buttons. <figref idrefs="DRAWINGS">FIG. 9</figref> illustrates four member push buttons each having their own respective check box. Graphical user interface <b>900</b> also includes a talk push button <b>910</b> and a status field <b>912</b>.

In operation, a one to one audible conversation may be initiated by pushing the member push button associated with the desired member. In this scenario, the check boxes are not used and may all be unchecked. Once the desired member's push button is pushed, the push-to-talk conversation is started and the floor control described in <figref idrefs="DRAWINGS">FIG. 4</figref> is implemented throughout the conversation. A one-to-one conversation may also be initiated by checking the check box associated with the desired member and then pushing the talk push button <b>910</b>. The talk push button <b>910</b> is the graphical element responsible for activating the floor signals <b>412</b> and <b>432</b> shown in <figref idrefs="DRAWINGS">FIG. 4</figref>.

A multi-party conversation may be initiated by checking each of the check boxes associated with the desired members. For example, graphical user interface <b>900</b> illustrates the check boxes for Alice and Brian being checked. Once the check boxes for the desired parties have been checked, the user pushes and holds the talk push button <b>910</b> which initiates the multi-party push-to-talk session and starts the conversation. Alternatively, after the check boxes have been checked, the user may push any one of the member push buttons that are associated with a checked check box to initiate the multi-party push-to-talk session and start the conversation.

After a one-to-one or a multi-party session is active, another member may be added to the session by checking the check box associated with the other member or by pushing the push button associated with the other member. This information is then sent to the server. At the server, the session information is updated accordingly.

<figref idrefs="DRAWINGS">FIG. 10</figref> is a timing diagram that illustrates logic for handling incoming and outgoing streams for one push-to-talk session <b>1000</b> in the one-session capable client computing device. Referring to <figref idrefs="DRAWINGS">FIG. 10</figref>, at time t<b>1</b>, incoming stream <b>1004</b> becomes active. If at time t<b>2</b> the user initiates an outgoing stream (e.g., outgoing stream <b>1002</b>), the incoming stream <b>1004</b> ends so that the outgoing stream <b>1002</b> can establish a new session. If the earlier session is a one-to-one session, the session ends. However, if the earlier session is a multi-party session, the other parties may remain in the session, but the current user is removed from that session. When the outgoing stream <b>1002</b> ends at time t<b>3</b>, another session may be established or another stream in the same session as outgoing stream <b>1002</b> may occur.

<figref idrefs="DRAWINGS">FIG. 11</figref> is an exemplary graphical user interface for a multi-session capable client computing device that illustrates one embodiment for an active session window <b>1100</b>. The multi-session capable device may also uses the contact list window <b>500</b> illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref> to first select which members to include in the push-to-talk session. Once the session is active, active session window <b>1100</b> is displayed. The active session window includes indicators for each active session, such as indicator <b>1102</b> and <b>1112</b>. The indicators may also perform the function of the talk push button explained above. In addition, the active session window <b>1100</b> displays a name for each member that is a party to the session. A first icon (e.g., icon <b>1104</b>) may be placed alongside the name to indicate that the member is currently active real-time in the session. A second icon (e.g., icon <b>1106</b>) may be placed along the name to indicate that the audio stream from that member is currently being saved in a playback file. In addition, active session window <b>1100</b> may include a playback message indicator <b>1108</b> that identifies the number of playback messages that are available for the associated member. In <figref idrefs="DRAWINGS">FIG. 11</figref>, the active session window indicates that Brian has two playback messages available. This information is displayed by having “[2]” behind the member's name. Playback messages can be played back by pushing the icon <b>1106</b> to initiate the playing of the recorded stream.

<figref idrefs="DRAWINGS">FIG. 12</figref> is a series of timing diagrams that illustrate logic for handling incoming and outgoing streams from multiple sessions by a multi-session capable client computing device. One should note that each session will typically have many different incoming and outgoing streams during the session. However, because the floor control process limits each session to having one stream at a time, a session will not have an incoming stream and an outgoing stream at the same time. For multi-session capable computing devices, there may be multiple overlapping streams from different session. In <figref idrefs="DRAWINGS">FIG. 12</figref>, each of the streams from multiple sessions is displayed as a rectangular block along a time axis. For certain streams, a portion of the stream or the entire stream is shown in grey. The grey portion represents the portion of the stream that is recorded as a playback file for later playback. For the timing diagrams illustrated in <figref idrefs="DRAWINGS">FIG. 12</figref>, an outgoing stream is given higher priority than an incoming stream. However, the priorities for different streams may be user-defined in a manner such that a particular member may be given higher priority than other members and/or higher priority than the outgoing stream. In addition, playback messages may be assigned a unique default priority, the same priority has incoming messages, or the like. For convenience, however, the following discussion describes the timing diagrams using the assumption that the outgoing stream is at a higher priority than any of the incoming streams.

Timing diagram <b>1200</b> illustrates an outgoing stream <b>1202</b> initiated at time t<b>1</b> and ending at time t<b>4</b>. During this stream, an incoming stream <b>1204</b> is initiated at time t<b>2</b> and ends at time t<b>3</b>. Because the outgoing stream <b>1202</b> is assigned a higher priority, incoming stream <b>1204</b> is recorded for later playback. One will appreciate that other incoming streams (not shown) may be initiated during outgoing stream <b>1202</b> and/or incoming stream <b>1204</b>. These other incoming streams would also be recorded.

Timing diagram <b>1210</b> illustrates an outgoing stream <b>1212</b> initiated at time t<b>1</b> and ending at time t<b>3</b>. An incoming stream <b>1214</b> is initiated at time t<b>2</b> and ends at time t<b>4</b>. Again, because the outgoing stream <b>1212</b> is assigned a higher priority than the incoming stream <b>1214</b>, incoming stream <b>1214</b> is recorded starting at time t<b>2</b>. Interestingly, however, at time t<b>3</b> when the outgoing stream <b>1212</b> ends, incoming stream <b>1214</b> remains being recorded until time t<b>4</b>. This is done to maintain the time sequence of incoming stream <b>1214</b>.

Timing diagrams <b>1200</b> and <b>1210</b> also illustrate the case when two incoming streams arrive at time t<b>1</b> and t<b>2</b>, instead of an incoming and an outgoing stream as described above. If two incoming streams arrive, the first incoming stream is played and the later incoming stream is recorded as described above.

Timing diagram <b>1220</b> illustrates an incoming stream <b>1222</b> initiated at time t<b>1</b> and ending at time t<b>4</b>. An outgoing stream <b>1224</b> is initiated at time t<b>2</b> and ends at time t<b>3</b>. Because outgoing stream <b>1224</b> is assigned a higher priority than the incoming stream <b>1222</b>, the incoming stream <b>1222</b> starts being recorded at time t<b>2</b> when the outgoing stream <b>1224</b> begins. Again, incoming stream <b>1222</b> remains being recorded even after the outgoing stream <b>1224</b> ends at time t<b>3</b>. Once a stream starts being recorded, the remaining portion of the stream will also be recorded. If incoming stream <b>1222</b> is actually a stream that is being played back, the playback of the stream is paused at time t<b>2</b> and then is resumed at the same position at time t<b>3</b>.

Timing diagram <b>1230</b> illustrates an incoming stream <b>1232</b> initiated at time t<b>1</b> and ending at time t<b>3</b>. An outgoing stream <b>1234</b> is initiated at time t<b>2</b> and ends at time t<b>4</b>. Again, because the outgoing stream <b>1234</b> is assigned a higher priority than the incoming stream <b>1232</b>, the incoming stream <b>1232</b> starts recording at time t<b>2</b> and stops being recorded at time t<b>3</b>.

<figref idrefs="DRAWINGS">FIG. 13</figref> is a flow diagram illustrating an exemplary process for managing push-to-talk sessions as graphically depicted in the time sequence diagrams shown in <figref idrefs="DRAWINGS">FIGS. 10 and 12</figref> for one session capable computing devices and multi-session capable computing devices, respectively. At block <b>1302</b>, a push-to-talk session is established as described above in <figref idrefs="DRAWINGS">FIG. 5</figref>. Processing continues at block <b>1304</b>.

At block <b>1304</b>, a default set of priorities are assigned to the outgoing stream and the incoming stream(s). Alternatively, a user may define the priorities for the outgoing stream and each of the incoming streams. For example, a user may define the incoming stream associated with a supervisor at a higher priority than other members in different sessions. Once the priorities are assigned, processing continues at decision block <b>1306</b>.

At decision block <b>1306</b>, a determination is made whether another push-to-talk session has already been established. If the computing device is a one-session capable computing device, the establishment of the push-to-talk session at block <b>1302</b> ends the previously established push-to-talk session. Therefore, if the prior push-to-talk session is a one-to-one session, the session is no longer active. However, if the prior push-to-talk session is a multi-party session, the user is removed from the multi-party session, but the multi-party session remains active for the other members. If there is not another push-to-talk session that is established, processing continues at block <b>1310</b>. Alternatively, if there is another push-to-talk session that is established, processing continues at block <b>1308</b>.

At block <b>1308</b>, the priorities assigned to the incoming streams for the other established push-to-talk session are modified to accommodate the assigned priorities from block <b>1304</b>. Again, default priorities may be applied or a user may assign a priority for the streams for each session. Processing continues at block <b>1310</b>.

At block <b>1310</b>, the client computing device plays the stream with the highest priority in real-time. Processing continues at block <b>1312</b>.

At block <b>1312</b>, the client computing device records other streams that overlap with the highest priority stream as described in the timing diagrams shown in <figref idrefs="DRAWINGS">FIGS. 10 and 12</figref>. As described above, because the communication in one session operates in a half-duplex mode, a one-session capable computing device will not need to record any of the streams. In contrast, a multi-session capable computing device may need to record one or more streams quite often. These recorded streams may then be later played back. The played back streams are also assigned a priority. Processing is then complete.

During the push-to-talk conversations described above, the member who is granted the floor may begin to speak into a microphone associated with their computing device so that the other members can hear their voice at their computing devices. Because the members are able to hear the voice of each member during the push-to-talk communication, the member's communication experience is richer than pure text based messages. In addition, the communication may be more efficient because speaking is typically faster than typing. Another advantage for multi-party capable computing devices is that the user can easily switch between sessions which allow the user to interleave multiple conversations.

The present push-to-talk functionality may be integrated with existing instant messaging systems in order to provide users different communication experiences. In the workplace, having different communication mechanisms available is quite desirable. This allows each individual the option to choose the best communication mechanism for their immediate purpose. In addition, the present push-to-talk functionality may be integrated with existing push-to-talk services over the cellular network to allow push-to-talk technology to operate on any network utilizing an internet protocol.

In one configuration, the server computing device includes a 3 gigahertz central processing unit and 1 megabyte of memory per each 1000 users. Testing showed that the CPU usage was linear with the user registration process. When the user registration process reached approximately 3000 users/second, the CPU was at 100% usage. It appeared that neither the CPU nor the memory created a bottleneck for providing the push-to-talk functionality. Rather, it was determined that the network capacity limited the number of concurrent sessions that could be supported. Using a GSM 6.10 audio codec operating at 13.0 Kbps, the server computing device supported approximately 4,500 sessions with a 100 Mbps connection.

While example embodiments and applications have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and resources described above. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the disclosed embodiments herein without departing from the scope of the claimed invention.