Patent Publication Number: US-8533611-B2

Title: Browser enabled communication device for conducting conversations in either a real-time mode, a time-shifted mode, and with the ability to seamlessly shift the conversation between the two modes

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of priority to U.S. Provisional Patent Application No. 61/232,627 filed Aug. 10, 2009 and entitled “Methods and Apparatus for Conducting Time-Based Media Conversations In Either A Real-time Mode or a Time-shifted Mode Through a Communication Server and Browser.” The above-listed application is incorporated herein by reference in its entirety for all purposes. 
    
    
     BACKGROUND 
     1. Field of the Invention 
     This invention pertains to communications, and more particularly, to a browser enabled communication device capable of conducting conversations in either a synchronous real-time mode or asynchronously in a time-shifted mode, and with the ability to seamlessly transition between the two modes. 
     2. Description of Related Art 
     Electronic voice communication has historically relied on telephones and radios. Conventional telephone calls required one party to dial another party using a telephone number and waiting for a circuit connection to be made over the Public Switched Telephone Network or PSTN. A full-duplex conversation may take place only after the connection is made. More recently, telephony using Voice over Internet Protocol (VoIP) has become popular. With VoIP, voice communications takes place using IP over a packet-based network, such as the Internet. Radio communication, including Push To Talk (PTT) and PTT over Cellular (PoC) systems, allows a person to communicate with others with the push of a button, without first establishing a two-way connection. Most radio communication is half-duplex, meaning only one person can speak over a single channel at a time. With mobile phones, two-way communication is possible by establishing two channels, each at different frequencies. 
     Many full-duplex telephony systems have some sort of message recording facility for unanswered calls such as voicemail. If an incoming call goes unanswered, it is redirected to a voicemail system. When the caller finishes the message, the recipient is alerted and may listen to the message. Various options exist for message delivery beyond dialing into the voicemail system, such as email or “visual voicemail”, but these delivery schemes all require the entire message to be left by the caller before the recipient can listen to the message. 
     Many home telephones have answering machine systems that record missed calls. They differ from voicemail in that the caller&#39;s voice is often played through a speaker on the answering machine while the message is being recorded. The called party can pick up the phone while the caller is leaving a message, which causes most answering machines to stop recording the message. With other answering machines, however, the live conversation will be recorded unless the called party manually stops the recording. In either recording situation, there is no way for the called party to review the recorded message until after the recording has stopped. As a result, there is no way for the recipient to review any portion of the recorded message other than the current point of the conversation while the conversation is ongoing and is being recorded. Only after the conversation has concluded, and the parties have hung up, or the recipient has manually stopped the recording, can the recipient go back and review the recorded message or conversation. 
     Some more recent call management systems provide a “virtual answering machine”, allowing callers to leave a message in a voicemail system, while giving called users the ability to hear the message as it is being left. The actual answering “machine” is typically a voicemail-style server, operated by the telephony service provider. Virtual answering machine systems differ from standard voice mail systems in that the called party may use either their phone or a computer to listen to messages as they are being left. Similar to an answering machine as described in the preceding paragraph, however, the called party can only listen at the current point of the message as it is being left. There is no way to review previous portions of the message before the message is left in its entirety and the caller hangs up. 
     Certain mobile phone handsets have been equipped with an “answering machine” feature inside the handset itself that behaves similarly to a landline answering machine as described above. With these answering machines, callers may leave a voice message, which is recorded directly on the phone of the recipient. While the answering machine functionality has been integrated into the phone, the limitations of these answering machines, as discussed above, are still present. 
     With most current PTT systems, incoming audio is played on the device as it is received. If the user does not hear the message, for whatever reason, the message is irretrievably lost. Either the sender must resend the message or the recipient must request the sender to retransmit the message. PTT messaging systems are known. With these systems, message that are not reviewed live are recorded. The recipient can access the message from storage at a later time. These systems, however, typically do not record messages that are reviewed live by the recipient. See for example U.S. Pat. No. 7,403,775, U.S. Publications 2005/0221819 and 2005/0202807, EP 1 694 044 and WO 2005/101697. 
     With the growing popularity of the Web, more people are communicating through the Internet. With most of these applications, the user is interfacing through a browser running on their computer or other communication device, such as a mobile or cellular phone or radio, communicating with others through the Internet and one or more communication servers. 
     With email for example, users may type and send text messages to one another through email clients, located either locally on their computer or mobile communication device (e.g., Microsoft Outlook) or remotely on a server (e.g., Yahoo or Google Web-based mail). In the remote case, the email client “runs” on the computer or mobile communication device through a Web browser. Although it is possible to send time-based (i.e., media that changes over time, such as voice or video) as an attachment to an email, the time-based media can never be sent or reviewed in a “live” or real-time mode. Due to the store and forward nature of email, the time-based media must first be created, encapsulated into a file, and then attached to the email before it can be sent. On the receiving side, the email and the attachment must be received in full before it can be reviewed. Real-time communication is therefore not possible with conventional email. 
     Skype is a software application intended to run on computers that allows people to conduct voice conversations and video-conferencing communication. Skype is a type of VoIP system, and it is possible with Skype to leave a voice mail message. Also with certain ancillary products, such as Hot Recorder, it is possible for a user to record a conversation conducted using Skype. However with either Skype voice mail or Hot Recorder, it is not possible for a user to review the previous media of the conversation while the conversation is ongoing or to seamlessly transition the conversation between a real-time and a time-shifted mode. 
     Social networking Web sites, such as Facebook, also allow members to communicate with one another, typically through text-based instant messaging, but video messaging is also supported. In addition, mobile phone applications for Facebook are available to Facebook users. Neither the instant messaging, nor the mobile phone applications, however, allow users to conduct voice and other time-based media conversations in both a real-time and a time-shifted mode and to seamlessly transition the conversation between the two modes. 
     Google Wave is Web based personal communication and collaboration tool and computing platform designed to merge email, wiki, and instant messaging. Instead of sending a message and its entire thread of previous messages as is typical with conventional email, objects known as “waves” contain a complete thread of multimedia messages (blips) maintained on a central server. Waves are shared and collaborators can be added or removed at any point during the existence of a wave. Any participant can reply anywhere in the message, edit the content, or add participants at any point in the duration of a wave. Recipients are notified of any changes or replies in all the waves in which they are active. The changes or replies are automatically visible when the user accesses the wave. The ability to modify a wave at any point or location lets users create collaborative documents, edited in a manner akin to wikis. In addition, replies or edits may be updated, letter-by-letter, as they are typed. Although the update of each keystroke as it occurs gives the appearance of being time-based media that is rendered “live”, in actuality it is not. Rather each keystroke entry is a separate or discrete event. In contrast with time-based media such as voice or video, the media is continuous and changes over time. Multiple participants may edit a single wave simultaneously. When multiple users are online at the same time, waves are similar to instant messaging. Waves, however, do not support the real-time communication of voice or other time-based media. Consequently, there is no ability to conduct a voice and/or video conversation in real-time using Google wave. 
     SUMMARY OF THE INVENTION 
     A browser enabled communication device is disclosed. The communication device includes a processor, a display, a network connection configured to connect the communication device with a remote communication device over a communication network, a browser and a communication application. The communication application and the browser both run on the processor and cooperate to create a user interface that enables a user of the communication device to participate in a conversation with the remote communication device over the communication network. The user interface enables the user to participate in the conversation in either: (i) a real-time mode or (ii) a time-shifted mode and to (iii) seamlessly transition the conversation between the two modes (i) and (ii) so that the media of the conversation may be rendered synchronously when in the real-time mode or asynchronously when in the time-shifted mode. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention may best be understood by reference to the following description taken in conjunction with the accompanying drawings, which illustrate specific embodiments of the invention. 
         FIG. 1  is diagram of a communication system according to the present invention. 
         FIG. 2  is a diagram of a client communication device according to the present invention. 
         FIG. 3  is a diagram of an exemplary graphical user interface for managing and engaging in conversations on a client communication device according to the present invention. 
         FIG. 4  is a block diagram illustrating a communication application for running on a client communication device according to the present invention. 
         FIGS. 5A through 5E  are diagrams illustrating a various Web browser interfaces according to the present invention. 
         FIGS. 6A and 6B  are diagrams of a Web browser user interface displayed on a mobile client communication device according to the present invention. 
     
    
    
     It should be noted that like reference numbers refer to like elements in the figures. 
     DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS 
     The invention will now be described in detail with reference to various embodiments thereof as illustrated in the accompanying drawings. In the following description, specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art, that the invention may be practiced without using some of the implementation details set forth herein. It should also be understood that well known operations have not been described in detail in order to not unnecessarily obscure the invention. 
     Messages and Conversations 
     “Media” as used herein is intended to broadly mean virtually any type of media, such as but not limited to, voice, video, text, still pictures, sensor data, GPS data, or just about any other type of media, data or information. 
     As used herein, the term “conversation” is also broadly construed. In one embodiment, a conversation is intended to mean a thread of messages, strung together by some common attribute, such as a subject matter or topic, by name, by participants, by a user group, or some other defined criteria. In another embodiment, the messages of a conversation do not necessarily have to be tied together by some common attribute. Rather one or more messages may be arbitrarily assembled into a conversation. Thus a conversation is intended to mean two or more messages, regardless if they are tied together by a common attribute or not. 
     Communication System 
     Referring to  FIG. 1 , a communication system including one or more communication servers  10  and a plurality of client communication devices  12  is shown. A communication services network  14  is used to interconnect the individual client communication devices  12  through the servers  10 . 
     The server(s)  10  run an application responsible for routing the metadata used to set up and support conversations as well as the actual media of messages of the conversations between the different client communication devices  12 . In one specific embodiment, the application is the server application described in commonly assigned co-pending U.S. application Ser. No. 12/028,400 (U.S. Patent Publication No. 2009/0003558), Ser. No. 12/192,890 (U.S. Patent Publication No. 2009/0103521), and Ser. No. 12/253,833 (U.S. Patent Publication No. 2009/0168760), each incorporated by reference herein for all purposes. The communication application as described in the above-listed applications enables client communication devices  12  to engage in conversations (i) synchronously in a real-time mode or (ii) asynchronously in a time-shifted mode and to (iii) seamlessly transition the conversation between the two modes (i) and (ii). The conversations may include multiple types of media, including voice, text, video, sensor data, GPS data, etc., and are not limited to just voice media as with conventional telephone conversations. In addition, the server(s)  10  may support conversations between more than two parties, such as conference calls between multiple parties. 
     In various embodiments, each of the server(s)  10  may run only the above-mentioned communication application. In an alternative embodiment, one or more of the server(s) may also be Web servers capable of serving Web content to the client communication devices  12  as well as running the communication application. In yet another alternative embodiment, the communication services network  14  may include, in addition to the Web server(s)  10 , one or more stand-alone Web servers (not illustrated) capable of serving Web content. 
     The client communication devices  12  may be a wide variety of different types of communication devices, such as desktop computes, mobile or laptop computers, mobile or cellular phones, Push To Talk (PTT) devices, PTT over Cellular (PoC) devices, radios, satellite phones or radios, VoIP phones, or conventional telephones designed for use over the Public Switched Telephone Network (PSTN). The above list should be construed as exemplary and should not be considered as exhaustive. Any type of communication device may be used. 
     The network  14  may in various embodiments be the Internet, PSTN, a circuit-based network, a mobile communication network, a cellular network based on CDMA or GSM for example, a wired network, a wireless network, a tactical radio network, a satellite communication network, any other type of communication network, or any combination thereof. The network  14  may also be either heterogeneous or homogeneous network. 
     Clients 
     Referring to  FIG. 2 , a block diagram of a client communication device  12  according to one embodiment of the present invention is shown. The client communication device  12  includes a network connection  20  for connecting the client communication device  12  to the network  14 , a speaker  22  for rendering voice and other audio based media, a mouse  23  for cursor control and data entry, a microphone  24  for voice and other audio based media entry, a keyboard or keypad  25  for text and data entry, a display  26  for rendering image or video based media at the client communication device  12 , and a camera  27  for capturing either still photos or video using the client communication device  12 . It should be noted that elements  22  through  27  are each optional and are not necessarily included on all implementations of a client communication device  12 . In addition, the display  26  may be a touch-sensitive display capable of receiving inputs using a pointing element, such as a pen, stylus or finger. In yet other embodiments, client communication devices  12  may optionally further include other media generating devices (not illustrated), such as sensor data (e.g., temperature, pressure), GPS data, etc. 
     The client communication device  12  also includes a Web browser  28  configured to generate and display HTML/Web content  30  on the display  26 . An optional multimedia platform  32 , such as Adobe Flash, provides audio, video, animation, and other interactivity features within the Web browser  28 . The multimedia platform  32  communicates with an underlying communication application  34  using remote Application Programming Interfaces or APIs, as is well known in the art. 
     The Web browser  28  may be any well-known software application for retrieving, presenting, and traversing information resources on the Web. In various embodiments, well known browsers such as Internet Explorer by Microsoft, Firefox by the Mozilla Foundation, Safari by Apple, Chrome by Google, Opera by Opera Software for desktop, mobile, embedded or gaming systems, or any other browser may be used. Regardless of the browser, information resources are identified by a Uniform Resource Locator (URL) and may be a Web page, image, video, or any other type of content. Hyperlinks present in resources enable users to easily navigate their browsers to related resources. Once content has been retrieved, the browser  28  is responsible for rendering the images, audio, video, data, text and/or related XML files defined by the retrieved Web page, typically creating a user-friendly interface on the display  26  and/or speaker  22  of client communication device  12 . In various embodiments, the browser  28  further includes a host of user interface features, such as backward and forward buttons, refresh or reload buttons, a stop button for stopping the loading of content, a home button to return to a home page, an address bar to input URLs, a search bar to input search terms into a search engine, a status bar, and other features typically found on Web browsers. Although the browser  28  is primarily intended to access the World Wide Web, in alternative embodiments, the browser  28  can also be used to access information provided by servers in private networks or content in file systems. 
     The client communication device  12  also includes a communication application  34  that enables the client communication device  12  to set up and engage in conversations with other client communication devices  12  (i) synchronously in the real-time mode, (ii) asynchronously in the time-shifted mode and to (iii) seamlessly transition the conversation between the two modes (i) and (ii). The conversations may also include multiple types of media, including voice, text, video, sensor data, etc. In one specific embodiment, the communication application is the client application described in commonly assigned co-pending U.S. application Ser. Nos. 12/028,400, 12/192,890, and 12/253,833, each incorporated by reference herein for all purposes. 
     The client communication device  12  also includes a Web browser plug-in  37  and a browser interface layer  38 . The Web-browser plug-in  37  provides well-known “plug-in” functionality of services offered by the browser  28 . The browser interface layer  38  acts as an interface between the Web browser  28  and the core of communication application  34 . The browser interface layer  38  is responsible for (i) invoking the various user interface functions implemented by the communication application  34  and presenting the appropriate user interfaces through the content presented through browser  28  to the user of client communication device  12  and (ii) receiving inputs from the user through the browser and other inputs on the client communication device  12 , such as mouse  23 , keyboard or keypad  25 , or touch display  26  and providing these inputs to the communication application  34 . As a result, the user of the client communication device  12  may control the operation of the communication application  34  when setting up, participating in, or terminating conversations through the Web browser  28  and the other input/output devices  22  through  27  optionally provided on the client communication device  12 . 
     The various software components including the browser  28 , multimedia platform  32 , communication application  34 , Web browser plug-in  37  and browser interface layer  38 , all run or are executed on a underlying processor core  36 . The processor core  36  may be any computing hardware platform, such as those based on, but not limited to, microprocessors developed by Intel or AMD, which are typically used in both desktop and mobile or laptop computers, as well as the microprocessors and/or microcontrollers, such as the ARM processor from ARM, Limited, typically used in mobile communication devices, such as cell or mobile phones. 
     User Interface 
       FIG. 3  is a diagram of an exemplary graphical user interface  40 , rendered by the browser  28  on the display  26  of a client communication device  12 . The interface  40  includes a folders window  42 , an active conversation list window  44 , a window  46  for displaying the history of a conversation selected from the list displayed in window  44 , a media controller window  48 , and a window  49  displaying the current time and date. 
     The folders window  42  includes a plurality of optional folders, such an inbox for storing incoming messages, a contact list, a favorites contact list, a conversation list, conversation groups, and an outbox listing outgoing messages. It should be understood that the list provided above is merely exemplary. Individual folders containing a wide variety of lists and other information may be contained within the folders window  42 . 
     Window  44  displays the active conversations the user of client communication device  12  is currently engaged in. In the example illustrated, the user is currently engaged in three conversations. In the first conversation, a participant named Jane Doe previously left a text message, as designated by the envelope icon, at 3:32 PM on Mar. 28, 2009. In another conversation, a participant named Sam Fairbanks is currently leaving an audio message, as indicated by the voice media bubble icon. The third conversation is entitled “Group  1 ”. In this conversation, the conversation is “live” and a participant named Hank Jones is speaking. The user of the client communication device  12  may select any of the active conversations appearing in the window  44  for participation. 
     Further in this example, the user of client communication device  12  has selected the Group  1  conversation for participation. As a result, a visual indicator, such as the shading of the Group  1  conversation in the window  44  different from the other listed conversations, informs the user that he or she is actively engaged in the Group  1  conversation. Had the conversation with Sam Fairbanks been selected, then this conversation would have been highlighted in the window  44 . It should be noted that the shading of the selected conversation in the window  44  is just one possible indicator. In various other embodiments, any indicator, either visual, audio, a combination thereof, or no indication may be used. 
     Within the selected conversation, a “MUTE” icon and an “END” icon are optionally provided. The mute icon allows the user to disable the microphone  24  of client communication device  12 , preventing any words spoken by the user from being included in the conversation and heard by the other participants. When the end icon is selected, the user&#39;s active participation in the Group  1  conversation is terminated. At this point, any other conversation in the list provided in window  44  may be selected. In this manner, the user may transition from conversation to conversation within the active conversation list. The user may return to the Group  1  conversation at anytime. 
     The conversation window  46  shows the history of the currently selected conversation, which in this example again, is the Group  1  conversation. In this example, a sequence of media bubbles each represent the media contributions to the conversation respectively. Each media bubble represents the media contribution of a participant to the conversation in time-sequence order. In this example, Tom Smith left an audio message that is 30 seconds long at 5:02 PM on Mar. 27, 2009. Matt Jones left an audio message 1 minute and 45 seconds in duration at 9:32 AM on Mar. 28, 2009. Tom Smith left a text message, which appears in the media bubble, at 12:00 PM on Mar. 29, 2009. By scrolling up or down through the media bubbles appearing in window  46 , the entire history of the Group  1  conversation may be viewed. For example, by scrolling upward, the earlier media bubbles of the conversation may be retrieved and displayed in the window. By scrolling downward, the more recent media bubbles of the conversation may be retrieved and displayed in the window  46 . In various embodiments, the scrolling either up or down through the history of the conversation, from the initial or first media bubble to the last or most recent, may be accomplished using a number of well known methods. For example, window scroll bars or a cursor controlled by a mouse may be used by non-touch screen displays, while an input device, such as a stylus, pen, or finger, may be used with touch-sensitive type displays. 
     The window  46  further includes a number of icons allowing the user to control his or her participation in the selected Group  1  conversation. A “PLAY” icon allows the user to render the media of a selected media bubble appearing in the window  46 . For example, if the Tom Smith media bubble is selected, then the corresponding voice message is accessed and rendered through the speaker  22  on the client communication device  12 . With media bubbles containing a text message, the text is typically displayed within the bubble. In either case, when an old message bubble is selected, the media of the conversation is being reviewed in the time-shifted mode. The “TEXT” and the “TALK” icons enable the user of the client communication device  12  to participate in the conversation by either typing or speaking a message respectively. The “END” icon removes the user from participation in the conversation. 
     When another conversation is selected from the active list appearing in window  44 , the history of the newly selected conversation appears in the conversation history window  46 . Thus by selecting different conversations from the list in window  44 , the user may switch participation among multiple conversations. 
     The media controller window  48  enables the user of the client communication device  12  to control the rendering of voice and other media of the selected conversation. The media controller window operates in two modes, the synchronous real-time mode and the asynchronous time shifted mode, and enables the seamless transition between the two modes. 
     When in the real-time mode, the window  48  includes an identifier pertaining to the incoming message, used to identify the sender of the message. In this example as illustrated, the identifier states “Hank Jones Speaking”. A timer  50  showing the current running time of a live message (i.e., “00.12” seconds) when in the real-time mode. 
     The window  48  further includes a number of visual and control icons for reviewing the media of a message in the time-shifted mode. The media controller window may include a “scrubber bar”  52 , which provides a visual indicator of the current point with respect to the duration of the message being reviewed in the time-shifted mode. Another timer  54  shows the time duration of a message when in the time-shifted mode. In addition, the window  48  includes a number of render control icons when in the time-shifted mode, including a render rate control “rabbit” icon  55 , a jump backward icon  56 , a pause icon  57 , and a jump forward icon  58 . 
     In the time-shifted mode, the media of a selected message is identified within the window  48 . For example (not illustrated), if the previous voice message from Tom Smith sent at 5:02 PM on Mar. 27, 2009, is selected, information identifying this message is displayed in the window  48 . The scrubber bar  52  allows the user to quickly traverse a message from start to finish and select a point to start the rendering of the media of the message. As the position of the scrubber bar  52  is adjusted, the timer  54  is updated to reflect the time-position relative to the start time of the message. The pause icon  57  allows the user to pause the rendering of the media of the message. The jump backward icon  56  allows the user to jump back to a previous point in time of the message and begin the rendering of the message from that point forward. The jump forward icon  58  enables the user to skip over media to a selected point in time of the message. The rabbit icon  55  controls the rate at which the media of the message is rendered. The rendering rate can be either faster, slower, or at the same rendering rate the media of the message was originally encoded. 
     In the real-time mode, the participant creating the current message is identified in the window  48 . In the example illustrated, the window identifies Hank Jones as speaking. As the message continues, the timer  50  is updated, providing a running time duration of the message. The jump backward and pause icons  56  and  57  operate as mentioned above. By jumping from the head of the conversation in the real-time mode back to a previous point using icon  56 , the conversation may be seamlessly transitioned from the live or real-time mode to the time-shifted mode The jump forward icon  58  is inoperative when at the head of the message since there is no media to skip over when at the head. 
     The rabbit icon  55  may be used to implement a rendering feature referred to as Catch up To Live or “CTL”. This feature allows a recipient to increase the rendering rate of the media of an incoming message until the recipient catches up to the head of the conversation. For example, if the user of the client device joins an ongoing conversation, the CTL feature may be used to quickly review the previous media contributions of the unheard message or messages until catching up to the head of the conversation. At this point, the rendering of the media seamlessly merges from the time-shifted mode to the real-time mode. 
     It should be noted that the user interface  40  is merely exemplary. It is just one of many possible implementations for providing a user interface for client communication devices  12 . It should be understood that the features and functionality as described herein may be implemented in a wide variety of different ways. Thus the specific interface illustrated herein should not be construed as limiting in any regard. 
     The Communication Application 
     Referring to  FIG. 4 , a block diagram of the core services or functions performed by the communication application  34  on client communication devices  12  is illustrated. The core services and functions of communication application  34  include a Multiple Conversation Management System (MCMS) module  62 , a Store and Stream module  64 , and an interface  66  provided between the two modules. The key features and elements of the communication application  34  are briefly described below. For a more detailed explanation, see U.S. application Ser. Nos. 12/028,400, 12/253,833, 12/192,890, and 12/253,820 (U.S. Patent Publication No. 2009/0168759), all incorporated by reference herein. 
     The MCMS module  62  includes a number of modules and services for creating, managing, and conducting multiple conversations. The MCMS module  62  includes a user interface module  62 A for supporting the audio and video functions on the client communication device  12 , rendering/encoding module  62 B for performing rendering and encoding tasks, a contacts service  62 C for managing and maintaining information needed for creating and maintaining contact lists (e.g., telephone numbers and/or email addresses), a presence status service  62 D for sharing the online status of the user of the client communication device  12  and which indicates the online status of the other users and the MCMS data base  62 E, which stores and manages the metadata for conversations conducted using the client communication device  12 . 
     The Store and Stream module  64  includes a Permanent Infinite Memory Buffer or PIMB  64 A for storing in a time-indexed format the time-based media of received and sent messages, encoder hardware  64 B for encoding the media, such as voice, video or sensor data generated using for example the microphone  24 , touch display  26 , camera  27 , or sensors on client communication device  12 , media drivers  64 C for driving the media generating components, such as speaker  22  and display  26  and a network interface  64 D for connecting the client communication device  12  to the network  14 , either through a wireless or wired connection. 
     The store and stream module  64  also includes modules for encode receive  66 A, net receive  66 B, transmit  66 C and render  66 D. The encode receive function  66 A involves the receiving, encoding, time-indexing and storing in the PIMB  64 A media created using the communication client communication device  12  in a time-indexed format. The net receive function involves the time-indexing and storing in the PIMB the media contained in messages received from others over the network  14  at client communication device  12 . The transmit function  66 C transmits the media of messages created on the client communication device  12  to other recipients over the network  14 . The render module  64 D enables the client communication device  12  to render the media of messages either synchronously in the near real-time mode or asynchronously in the time-shifted mode by retrieving media stored in the PIMB  64 A. The modules  66 A through  66 D enable the Store and Stream module  64  to (i) progressively and simultaneously transmitting time-based media over the network  14  as it is being created using a client communication device  12  and (ii) rendering time-based media either as it is being received over the network  14  in the synchronous mode or from the PIMB  64 A in a time-shifted mode. 
     The persistent storage of messages, regardless if they are discrete or part of a conversation, enables a number of different rendering options. For example, the rendering of media on a client communication device  12  may include rendering options such as play faster (i.e., the media is played faster than it was originally encoded), play slower (i.e., the media is played slower than it was originally encoded), pause, jump backward to a selected previous point in time of a message or conversation, jump to the head of a message or conversation, or Catch-up-To Live (CTL). With the CTL rendering option, the previously received media of an incoming message or messages are rendered out of the PIMB  64 A at a rate faster than it was originally encoded. Eventually, the rendering of the media catches up to the live point of the conversation (i.e., the head of the conversation), at which point, the system seamlessly transitions from the time-shifted to the near real-time mode. 
     The communication application  34  enables a client communication device  12  to engage in one or more conversations. The messages of each conversation, regardless if tied together by a common attribute or not, are persistently stored in the PIMB  64 A in a time-indexed order. When a particular message is selected for rendering, the corresponding media of the selected message is retrieved from the PIMB  64 A and either displayed in the case of text and/or rendered in the case of audio or video. 
     Real-Time Communication Protocols 
     The transmit module  64 C may rely on a number of real-time communication protocols. In one optional embodiment, the module  64 C may use the Cooperative Transmission Protocol (CTP) for near real-time communication, as described in U.S. application Ser. Nos. 12/192,890 and 12/192,899 (U.S. Patent Publication No. 2009/0103560), all incorporated by reference herein for all purposes. In another optional embodiment, a synchronization protocol that maintains the synchronization of time-based media between a sending and receiving client communication device  12 , as well as any intermediate server  10  hops on the network  14 , may be used. In yet another optional embodiment, the module  64 C may use SMTP mail protocol modified to support real-time communication, as described in U.S. application Ser. No. 12/419,861, also incorporated by reference herein for all purposes. 
     With the optional CTP protocol embodiment, media for transmission is ascertained as either time-sensitive or not time-sensitive, depending if the recipient of the media has the intent to review the media either synchronously (i.e., “live”) in the near real-time mode or asynchronously in the time-shifted mode. When network bandwidth is insufficient to transmit a full bit rate representation of time-sensitive media at a bit rate sufficient to support “live” communication, a reduced bit rate representation of the media is transmitted to maintain “live-ness.” Media that is ascertained as not time-sensitive, meaning the recipient has not indicated the intent to review the media in the real-time mode, is transmitted when bandwidth in excess of what is needed for any current time-sensitive media becomes available. When the media ascertained as not time-sensitive is transmitted, the rate of transmission is adjusted at the sending node based on network conditions. Typically, the adjusted rate of transmission for media ascertained as not time-sensitive is set for network efficiency and reliable delivery relative to the timeliness of the delivery of media ascertained as time-sensitive. In various embodiments, the intent of a recipient to review media in the real-time or time-shifted modes may be either a declared intent or inferred from the behavior of the recipient. 
     In addition, CTP includes provisions for making sure that a recipient eventually receives a full bit rate representation of sent media, regardless if the missing media was lost or corrupted during transmission or the recipient previously received only a reduced bit rate version of the media to support “live-ness.” In either case, the CTP defers retransmission of the full bit rate version of the media when the quality of the network is sufficient to support live communication. In other words, the retransmission occurs only when excess bandwidth is available. In situations where bandwidth is limited or is being used substantially for ongoing live communication, the retransmission of any missing full bit rate media may be deferred. 
     With the optional real-time synchronization protocol, the transmit module  64 C maintains real-time synchronization of time-based media between client communication devices  12  and server(s)  10  over the network  14 . See for example U.S. application Ser. Nos. 12/253,816 and 12/253,820, both incorporated by reference herein for all purposes, for more details. 
     With the optional real-time email protocols, the transmit module  64 C may use the existing email infrastructure to support the near real-time transmission of time-based media by modifying the way the SMTP or other proprietary email protocols, such as those used by Microsoft Exchange (hereafter generically referred to as “email protocols”), are used. Current email protocols do not strictly require that an entire message be available for sending before delivery is started, although this is typically how email protocols are used. Time-based media can therefore be delivered progressively, as it is being created, using standard SMTP or other proprietary email protocols. 
     With the real-time email embodiment, the net receive module  66 B supports the receipt of the time-based media associated with an email as the media is received in real-time. Conventional email is typically delivered to user devices through an access protocol like POP or IMAP. These protocols do not support the progressive delivery of messages as they are arriving. However, by making simple modifications to these access protocols, a message may be progressively delivered to a recipient as the media of the message is arriving over the network. Such modifications include the removal of the current requirement that the email server know the full size of the email message before the message can be downloaded to the client communication device  12 . By removing this restriction from network receive module  66 B, a client communication device  12  may begin rendering the time-based media of an email message as the time-based media of the email message is received over the network  14 . 
     Addressing and Route Discovery 
     In one optional embodiment, the recipient(s) of messages may be addressed using telephone numbers and Session Internet Protocol or SIP for setting up and tearing down communication sessions between client communication devices  12  over the network  14 . In various other optional embodiments, the SIP protocol is used to create, modify and terminate either IP unicast or multicast sessions. The modifications may include changing addresses or ports, inviting or deleting participants, or adding or deleting media streams. As the SIP protocol and telephony over the Internet and other packet-based networks, and the interface between the VoIP and conventional telephones using the PSTN are all well known, a detailed explanation is not provided herein. In yet another embodiment, SIP can be used to set up sessions between client communication devices  12  using the CTP protocol described above. 
     An advantage of using email protocols for real-time communication as described above is that email addresses and the existing DNS infrastructure may be used for identifying the participants of a conversation or the recipients of messages, while using the existing DNS infrastructure for route discovery. As a result, real-time conversations and the delivery of messages may occur in real-time, using the existing email infrastructure and global email addressing scheme, without the need of telephone numbers, the PSTN, or the protocols needed to support VoIP calls. 
     Web Sites 
     With the Internet and World Wide Web becoming pervasive, Web sites that create or define communities are become exceedingly popular. For example, Internet users with a common interest tend to aggregate at select Web sites where they can converse and interact with others having the same interests. Social networking sites like facebook.com, online dating sites like match.com, video game sites like addictivegames.com, and other forums, such as stock trading, hobbies, etc., have all become very popular. Up to now, members of these various Web sites could communicate with each other by either email or instant messaging style interactions within the Web page. Some sites support the creation of voice and video messaging, and other sites support live voice and video communication. None, however, allow members to communication either synchronously in the real-time mode or asynchronously in the time-shifted mode or to transition communication between the two modes. 
     By displaying Web pages with the user interface  40 , or variations thereof, embedded into the Web pages appearing on the display of client communication devices  12 , users may communicate time-based media with one another in either the real-time or time-shifted modes, with the ability to seamlessly transition between those modes, within the context of the Web page. In  FIGS. 5A through 5E  for example, the user interface  40  is shown embedded in a social networking site  70 , an online video gaming site  72 , an online dating site  74 , a stock trading forum  76 , and within a Google wave  78  respectively. When users of client communication devices  12  running the communication application  34  access these and similar Web sites, they may conduct conversations, including multiple media types, with other members, in either the real-time or time-shifted modes, as described in detail herein. For example, two friends on Facebook may conduct a conversation through the interface  40  embedded in the Facebook Web pages as they are displayed on the client communication devices  12 . Similarly, two individuals on a dating Web site may connect and begin conversing, either live or in a time-shifted mode, using various media types, such as voice, video and/or text. Although a number of popular Web-based communities have been mentioned herein, it should be understood that this list is not exhaustive. The number of Web sites is virtually unlimited and there are far too many Web sites to list herein. In each case, the Web content appearing within the browser running on the client communication device  12  is served by either server(s)  10  when capable of serving Web content and/or by separate Web servers within the network  14 . 
     Referring to  FIG. 6A , a diagram of a browser-enabled display on a mobile client communication device  12  according to the present invention is shown. In this example, the user interface  40  is provided within the browser-enabled display of a mobile client communication device  12 , such as a mobile phone or radio. It should be understood that the user interface  40  as shown is merely exemplary and is intended to show the various features and functions as described above. In various embodiments, the functions and features as described herein may be implemented in numerous ways. In addition, the mobile client communication device  12  as provide may rely on any real-time communication protocol, such as those discussed herein, including CTP, a modified version of SMTP or other proprietary email protocols. Furthermore, the mobile client communication device  12  may rely on SIP for setting up and tearing down sessions over packet-based and non-packet based networks and/or the existing DNS infrastructure for addressing and route discovery as described herein. 
       FIG. 6B  is a diagram of the mobile client communication device  12  with a keyboard  85  superimposed onto the browser display. With the keyboard  85 , the user may create text messages, for example, after selecting the TEXT option appearing in window  46  in  FIG. 3  for example. In this manner, the user may create a text message during participation in conversations. With mobile client communication devices  12  having a dedicated keyboard, such as with desktop computers, laptops and other mobile computers, and certain mobile phones, there obviously is no need to create a keyboard in the browser-enabled display of the mobile client communication device  12  as illustrated in  FIG. 6B . 
     While the invention has been particularly shown and described with reference to specific embodiments thereof, it will be understood by those skilled in the art that changes in the form and details of the disclosed embodiments may be made without departing from the spirit or scope of the invention. For example, embodiments of the invention may be employed with a variety of components and methods and should not be restricted to the ones mentioned above. It is therefore intended that the invention be interpreted to include all variations and equivalents that fall within the true spirit and scope of the invention.