Method and system for handling media in an instant messaging environment

A method and system for handling media at a communication entity, wherein the media is associated with a communication session that is capable of entering an active state and an inactive state. The method comprises determining when the communication session is in an inactive state, causing the media associated with the communication session to be stored when the communication session has entered an inactive state, and causing the stored media to be conveyed to a user of the communication entity upon determination that the communication session has re-entered an active state.

FIELD OF THE INVENTION

The present invention relates generally to the field of instant messaging (IM), and more particularly to a method and system for handling media associated with a given IM communication session.

BACKGROUND OF THE INVENTION

Instant messaging is commonly used for exchanging text messages between two parties that are connected to a network at the same time. In order to perform the instant messaging, a client program at a user's communication entity (such as a personal computer, or a cell phone) connects to an instant messaging service (such as MSN messenger, iTalk, GoogleTalk, etc . . . ) over a network. The instant messaging service allows the two communication entities to establish a communication session for sending text back and forth in substantially real time.

Instant messaging is known to be a fast, easy and non-intrusive form of communication between individuals, and is becoming increasingly popular among young people, and even in some corporate environments. There are many advantages to communicating via instant messaging. For example, as opposed to email, instant messaging permits almost immediate feedback, and two-way exchange, with another party. In addition, instant messaging facilitates the quick exchange of information, such as Uniform Resource Locators (URLs) or document snippets, that cannot easily be conveyed via other forms of real-time communication, such as phone conversations. A person involved in an instant messaging text conversation can still perform other operations, such as checking email, browsing the web, or working on a word processing file, at the same time that the person is conducting the instant messaging session.

In addition, in the case of text messaging, a user can conduct multiple instant messaging sessions at the same time. In most cases, the user will have a different chat window open for each one of the text sessions in which the user is involved. When one window is active, the user is able to type and send a message to the contact associated with that window. Meanwhile, the other inactive windows are still able to receive incoming text messages, which the user can easily switch to, in order to carry on multiple concurrent text sessions.

A deficiency with existing instant messaging systems is that it takes time for the user to type in an outgoing message. This can be time consuming for the user who is typing the message, and boring for the person who is waiting to receive the message.

In light of the above, it can be seen that there is a need in the industry for an improved system for enabling communication entities to communicate in an instant messaging environment.

SUMMARY OF THE INVENTION

In accordance with a first broad aspect, the present invention provides a method for handling media at a communication entity, the media being associated with a communication session that is capable of entering an active state and an inactive state. The method comprises determining when the communication session is in an inactive state, causing the media associated with the communication session to be stored upon determination that the communication session has entered an inactive state, and causing the stored media to be conveyed to a user of the communication entity upon determination that the communication session has re-entered an active state.

In accordance with a second broad aspect, the present invention provides a communication entity that comprises an input and a processing unit. The input is operative for receiving from a second communication entity, media associated with a communication session, the communication session being capable of entering an active state and an inactive state. The processing unit is operative for determining when the communication session is in an inactive state, causing media associated with the communication session to be stored upon determination that the communication session has entered an inactive state and causing the stored media to be conveyed to a user of the communication entity upon determination that the communication session has re-entered an active state.

In accordance with a third broad aspect, the present invention provides a communication entity that comprises a first functional unit, a second functional unit and a third functional unit. The first functional unit is operative for receiving media from another communication entity, the media being associated with a given communication session occurring at the communication entity. The second functional unit is operative for monitoring at least one communication session occurring at the communication entity for determining whether the at least one communication session is in an active state or an inactive state, identifying the given communication session in the at least one communication session to which the media from the second communication entity is associated, and when the given communication session is in the inactive state, causing the media associated to the given communication session to be stored. Finally, the third functional unit is operative for causing the stored media to be conveyed to a user of the communication entity upon detection by the second functional unit that the given communication session has entered an active state.

In accordance with a fourth broad aspect, the present invention provides a computer-readable storage medium that comprises a program element for execution by a processing entity for handling media associated with a communication session that is capable of entering an active state and an inactive state. The processing entity when executing the program element, being operative for determining when the communication session is in an inactive state, causing media associated with the communication session to be stored upon determination that the communication session has entered an inactive state, and causing the stored media to be conveyed to a user of a communication entity upon determination that the communication session has re-entered an active state.

In accordance with a fifth broad aspect, the present invention provides a method for conducting a communication session, the communication session being capable of entering an active state and an inactive state. The method comprises being attentive to received media associated with the communication session when the communication session is in an active state, causing the communication session to enter an inactive state, wherein media received for the communication session while it is in an inactive state is stored, and having the stored media be conveyed upon causing the communication session to re-enter an active state.

In accordance with a sixth broad aspect, the present invention provides a server system for handling media at a communication entity, the media being associated with a communication session that is capable of entering an active state and an inactive state. The server system stores a program element for execution by a processing unit. The program element comprises a first program element component for determining when the communication session is in an inactive state, a second program element component for causing media associated with the communication session to be stored upon determination that the communication session has entered an inactive state, and a third program element component for causing the stored media to be conveyed to a user of the communication entity upon determination that the communication session has re-entered an active state.

In accordance with a seventh broad aspect, the present invention provides a system comprising a first communication entity, and a second communication entity. The second communication comprises an input for receiving from the first communication entity media associated with a communication session, the communication session being capable of entering an active state and an inactive state, wherein when the communication session is in the active state a user of said second communication entity is attentive to communication with said first communication entity. The second communication entity further comprises a processing unit for determining when the communication session is in an inactive state, causing the media associated with the communication session to be stored upon determination that the communication session has entered an inactive state and causing the stored media to be conveyed to a user of the second communication entity upon determination that the communication session has re-entered an active state.

These and other aspects and features of the present invention will now become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention and the accompanying drawings.

DETAILED DESCRIPTION

Shown inFIG. 1is a non-limiting example of a network architecture10in which a method and system for handling media in accordance with the present invention can be implemented. As shown, the network architecture10comprises a network12, and a plurality of communication entities141-nconnected to one another over the network12. The network12includes a server16that is operative to transmit and receive signals with the communication entities141-nThe server16can process and issue signals concurrently using suitable methods known in the computer related arts. Although only one server16is shown inFIG. 1, it should be appreciated that the network12may include multiple servers16such that the communication entities141-nare interconnected via a server system. The network12may be any suitable network, including but not limited to a global public network such as the Internet, a private network, such as an Intranet, or a wireless network, such as a cellular network, or a combination thereof.

As shown, the communication entities141-nare connected to the network12, via communication links181-n. The communication links181-ncan be metallic conductors, optical fibres or wireless links, without departing from the spirit of the invention. It should be appreciated that communication between communication entities141-ncan occur via the server16of network12, or alternatively can occur over a peer-to-peer (P2P) connection20, as shown between communication entities141, and142. In the peer-to-peer connection, the two communication entities141and142communicate without a server managing the connection. Instead, the two communication entities141and142act as equal nodes that simultaneously function as both “clients” and “servers”. The manner in which peer-to-peer connections function is known in the art, and as such will not be described in more detail herein. It should be appreciated that link20can traverse the network12, and just not go through the server16.

As used herein, the term “communication entity” refers to any device capable of connecting to the network12, for transmitting and/or receiving media. For example, a communication entity can be a personal computer, a smartphone, a personal digital assistant or a cellphone, among other possibilities. Shown inFIG. 2is a non-limiting functional block diagram of a communication entity14from the set of communication entities141-n. For the sake of simplicity, only one communication entity14will be described herein, but it should be appreciated that the components and functionality described with respect to the communication entity14shown inFIG. 2will be substantially the same for each of the communication entities141-n.

For the purposes of the present description, each of the communication entities141-n, executes an instant messaging (IM) client34that is able to access an IM service, such as MSN messenger, GoogleTalk, iTalk, Yahoo Messenger, ICQ, MSN Communicator or Skype run on the server system of the network12. As such, each of the communication entities141-nis able to run an IM communication session for receiving and transmitting text, voice and/or video-conferencing media with other ones of the communication entities141-nthat are connected to the network12. In accordance with the present invention, the voice and/or video conferencing media received for a given communication session at the communication entity14is handled in such a way that the communication session can continue even when a user of the communication entity14is distracted from that communication session for a period of time.

It should be appreciated that the communication entities141-nare also able to run IM communication sessions with communication entities (not shown) that do not include IM capabilities. For example, a communication session can be run at the communication entity14with another communication entity that does not include an IM client. The other communication entity may be a telephone having voice-over-IP (VoIP), or voice-over IM (VoIM) capabilities. In the case where there is a gateway between a Public Switched Telephone Network (PSTN) and an IP network, the other communication entity can be a PSTN telephone. In the scenario where only the communication entity14includes an IM client34, the two communication entities are able to exchange voice media, but the IM communication session occurs only from the perspective of the communication entity14that has the IM client34.

As will be described in more detail below, each of the communication entities141-nhandles media, such as voice and/or video-conferencing media, received for a communication session in such a way that the communication session can continue even when a user is distracted from that communication session for a period of time. When a user is distracted from a communication session, the communication session becomes inactive, such that incoming media associated with that communication session is not conveyed to a user, and is instead recorded for future use. When a user returns to that communication session, such that the communication session once again becomes active, the stored media is played back to a user. The stored media can be automatically played back when the communication session becomes active once again, or alternatively, the stored media can be played back to a user when the user provides an indication that the stored media should be played.

By playing the stored media back to a user when a previously inactive window becomes active once again, a user does not miss any of the voice conversation or video conferencing feed that was received for that communication session because they were temporarily pre-occupied. This handling of voice and/or video conferencing media allows multiple voice and/or video communication sessions to be conducted by a user of the communication entity14at the same time.

As shown inFIG. 2, the IM client34at the communication entity14is in communication with a memory unit26. The memory unit26includes a communication session list database31that will be described in more detail below. The instant messaging (IM) client34is operative for handling media sent to, and received from, other communication entities141-nin the context of conducting communication sessions. For the purposes of the present description, the term “communication session” generally refers to a session conducted at one of the communication entities141-nfor receiving and transmitting text, voice and/or video media in substantially real-time with another communication entity connected via the server16, or via a peer-to-peer connection20, wherein the session can acquire an active state and an inactive state.

When the communication entity14is connected to the network12, the IM client34is operative for obtaining presence information associated with selected other ones of the communication entities141-n. The selected other ones of the communication entities141-nmay be identified in a buddy list that is created by a user of the communication entity14. The presence information is indicative of whether the communication entities in the buddy list are available for a communication session with the communication entity14. This information can be presented to a user of the communication entity14via a display screen in a variety of different manners which are known in the art and will not be described in more detail herein. In accordance with a non-limiting example of implementation wherein the communication entity14provides the user with a windows-based interface, in order to establish a communication session with another communication entity, the user may simply double click on the name of a buddy whose presence information indicates that he/she is available for a communication session. This will launch a window associated with a communication session with that buddy, such that a communication session may begin. A user of the communication entity14may then terminate the communication session with that buddy, simply by closing the window associated with the communication session.

As shown inFIG. 2, the IM client34includes a media input/output36, a communication session manager38and a media conveyance unit40. The media input/output36is operative for receiving media from other communication entities and for transmitting media to other communication entities. Media input/output36transmits and receives media either via through the network server16or over a peer-to-peer connection20. As described above, the peer-to-peer connection20may go through the network12, but does not go through the server16.

The communication session manager38is operative for establishing the communication sessions, as described above, and for handling the media associated with these communication sessions once they have been established. As shown inFIG. 2, the communication session manager38is in communication with a communication session list database31, which lists all the communication sessions that are currently in progress at the communication entity14at any given time. A non-limiting example of the potential contents of the database31is shown inFIG. 3. As shown, the database31stores a plurality of entries331. . .33neach containing data elements associated with a respective ongoing communication session. In the non-limiting embodiment shown, each of the entries331-nincludes a data element50identifying the communication session, a data element52identifying either the communication entity with whom the communication session is taking place, or the party associated with that communication entity, a data element53indicative of the active or inactive state of the communication session and a data element54indicative of whether there is stored media associated with the communication session. It should be appreciated that the database31may include additional data elements without departing from the spirit of the invention, such as a network identifier, the address of the communication entity in data element52, etc . . . .

Although the database is shown inFIG. 2as being part of the communication entity14, it should be appreciated that a database containing the information described above could instead be maintained in the network12, by the server16, for example. In such an example, the IM client34would communicate with the network server16for storing information in the database and for obtaining information in the database. In yet a further alternative, the information contained in the database31shown inFIG. 3could be spread out over multiple databases stored at different locations. For example, the list of communication sessions may be stored at the server16, without an indication of the active or inactive state of each communication session. In such an embodiment, the operating system of the communication entity14would keep a record of the active and inactive states of the communication sessions. As such, in order to determine whether a communication session is active or inactive, the communication session manager38would query the operating system of the communication entity14.

In addition, it should be appreciated that the communication session list database31may include any number of entries331-ndepending on the number of communication sessions that are ongoing at the communication entity14at any given time. The number of entries contained in the communication session list database31, as well as the data elements associated therewith, are dynamic. As a new communication session is started at the communication entity14a new entry will be added to the database31. Likewise, when a communication session at the communication entity14ends, an existing entry will be removed from the database.

As mentioned above, each communication session is capable of acquiring an active state and an inactive state. As used herein, the term “active state” refers to a communication session in which the user is actively involved. In other words, the user is attentive to media being received for that communication session. In contrast, the term “inactive” refers to a communication session in which the user is not actively involved in communicating with the party associated with that communication session. When a communication session is inactive, a user is not attentive to media being received for that communication session. For example, a communication session may be inactive when a user is focused on another communication session, or on another program operating on the communication entity (such as Microsoft Word, Internet Explorer, etc . . . ).

There are a variety of ways for the communication session manager38to determine whether a communication session is active or inactive. In accordance with a non-limiting example of implementation in which the communication entity14provides the user with a window-based environment, each communication session (as well as other programs running at the communication entity14) is associated with an individual window. As such, when a user is not focused on a given window, the communication session associated with that window is considered to be inactive. Shown inFIG. 4Ais a non-limiting example of a display screen in which the user of the communication entity is in the process of conducting three voice communication sessions with three separate parties, namely Cindy, Tom and John. In the example shown, the window56associated with the communication session with Cindy is highlighted, and as such is the window that is currently selected by the user. As such, the communication session with Cindy is the active communication session. Meanwhile, the windows58,60associated with the communication sessions with Tom and John are not currently selected by a user, and as such, are considered to be inactive. By switching back and forth between the three windows, the user is able to switch which communication session is active. It should be appreciated that no more than one communication session can be active at a time. As such, while a selected communication session is active, the remaining sessions are inactive.

A communication session can also become inactive when a user is focused on another type of program application operating at the communication entity. Shown inFIG. 4Bis a non-limiting example of a display screen in which a user of the communication entity is in the process of conducting a communication session with Tom, and is also in the process of browsing the internet. As shown, the user has the window62associated with the internet browsing application selected, such that the window64associated with the communication session with Tom is temporarily inactive. Even when a user is only conducting a single communication session, that communication session can still become inactive when the user focuses their attention on something other than the window associated with that communication session.

In one non-limiting embodiment of the present invention, the communication session manager38is in communication with the operating system of the communication entity14for establishing whether a communication session that is in progress at the communication entity14is active or inactive. The operating system may inform the communication session manager38when a window is selected by a user (i.e. highlighted), such that the communication session manager38can determine that the communication session associated with that window is active. For example, an event is sent to the IM client34by the operating system, or windows management system, indicating that the application window has the focus (i.e. is active or not). Whenever a communication session switches from an active state to an inactive state, or vice versa, the communication session manager28records this change in the communication session list database31. In this manner, the database31is kept up-to-date as to which communication session is active, and which ones are currently inactive.

Detecting when a communication session window is selected or not selected is one way for the communication session manager38to detect when a communication session is active or inactive. It should however be appreciated that other manners of determining the status of a communication session are also included within the scope of the present invention. For example, the communication session manager38may determine that a voice communication session is inactive when a user of the communication entity at which the communication session is operating has not spoken for a certain amount of time, or there has been no mouse or keyboard activity for a certain amount of time. This may signify that a user has left the communication entity, such as to go to the bathroom, but still has the window selected. In the case of video communication, the communication session manager38may determine that a user has left the computer (thus rendering the communication session inactive) if there is no activity or face detected on the web-cam.

Alternatively, whether a communication session is active or not can be detected on the basis of presence information. If the user has provided presence information or if the network has detected presence information, such as “away” or “out to lunch” then the communication session manager38may determine that a communication session is inactive. In yet another alternative, in the case where the communication entity is in the process of conducting a telephone session, then the communication session manager38may also determine that IM communication sessions are inactive. In the case where the communication entity is a cell-phone or a pda that requires that a user move a button or switch in order to toggle between communication sessions, the activation of such a button or switch may provide an indication of a change in activity status.

In addition to handling media received from another communication entity, the communication session manager38is also operative for handling media entered by a user of the communication entity14that is destined to be sent to another communication entity. To this end, the communication session manager38can be in communication with a keyboard (not shown), a video camera42and a microphone44, for receiving media to send to another communication entity14. Although the microphone44and video camera42are shown inFIG. 2to be a part of the communication entity14, it should be appreciated that these components may be external to the communication entity14and connected to the communication entity14via cables or a wireless link, without departing from the spirit of the invention.

Finally, the media conveyance unit40is operative for actually conveying media associated with an active communication session to a user of the communication entity14. A more detailed explanation of the manner in which the IM client34operates in order to handle media associated with one or more communication sessions, will now be described in more detail with respect to the flow charts ofFIGS. 5 and 6.

Process for Incoming Media

Shown inFIG. 5is a flow chart outlining a method performed by the IM client34, and more specifically by the communication session manager38, in order to manage incoming media associated with one or more communication sessions that are in progress at the communication entity14. It should be appreciated that this is only one example of implementation, and that an alternative method for achieving substantially the same result could be implemented at the server16, as will be described in more detail further on in the present application.

It should also be appreciated that this method assumes that media is only received for ongoing communication sessions. A call is considered ongoing, as soon as they have initiated a communication session with another communication entity, or in the case where the other communication entity has initiated the communication session, once the user has accepted commencement of the communication session. Acceptance of a communication session that is initiated via another communication entity may simply be done by clicking on an accept button, upon presentation of a window indicating that another communication entity would like to initiate a communication session.

Alternatively, media may be received from another communication entity in connection with a communication session that is not yet in existence. Upon receipt of such media, a new communication session is created at the communication entity14, and this communication session is considered in an inactive state.

As described above, media received from other communication entities is received at the media input/output36. The received media, whether text, voice and/or video media is then passed to the communication session manager38. At step70, the communication session manager38determines whether media has been received from another communication entity. In the case where received media is passed from the media input/output36to the communication session manager38, the communication session manager38determines that media has been received, and proceeds to step72. Whereas, if no media is received, the communication session manager38simply continues to wait for receipt of media from the media input/output36.

At step72, the communication session manager38identifies the communication session to which the received media is associated. In the case where more than one communication session is ongoing at the same time, such as in the example shown inFIG. 4Awherein the user of the communication entity14is in the process of conducting three different communication sessions, media can be received at any time for any one of the ongoing communication systems. As such, in order for received media to be linked to the appropriate communication session, the media includes an identifier associated therewith. The identifier can be indicative of the communication session to which that media is associated, or the identifier can be indicative of the sender of the media. By verifying the identifier against the information contained in each entry33of the communication session list database31, the communication session manager38is able to determine the communication session to which the media is associated. For example, if the received media includes an identifier indicating that it was sent by Cindy (the identifier may be a unique network identifier, a serial number associated with Cindy's communication entity, or just the name or alias of the party) the communication session manager38is able to determine that that media is associated with the communication session with Cindy (identified as communication session #2inFIG. 3).

At step74, once the communication session manager38has identified the communication session to which the received media is associated, the communication session manager38then determines whether that communication session is active. This can be done by consulting the database31. As mentioned above, and as shown inFIG. 3, each of the entries331-nin the database31includes a data element53indicative of whether the communication session associated with the corresponding entry is active or inactive. The data element53may be a text indication, such as “active” or “inactive”, as represented inFIG. 3, or the data element53may simply be a binary code, such as “10” for an active communication session, and “11” for an inactive communication session. Other manners of labelling a communication session as active or inactive can also be used without departing from the spirit of the invention.

In an alternative example, instead of checking the status of the communication session in the database31, the status of each communication session could be continually checked in real-time.

At step74, the communication session manager38is able to process the information contained in the database31, and specifically data element53, in order to determine whether the communication session to which the received media is associated is active or inactive.

In the case where the communication session for which media has been received is active, the communication session manager38proceeds to step76, wherein it causes the received media to be conveyed to a user of the communication entity14. This is done by passing the received media to the media conveyance unit40(shown in FIG.2), which in turn passes the media to the appropriate speakers and/or display screen46. In this manner, the media is displayed and/or broadcast to the user of the communication entity14.

If the communication session is inactive, the communication session manager38proceeds to step78, wherein it causes the received media to be stored. In accordance with a non-limiting example of implementation, the media is stored in the memory26, such that, as will be described below, it can be accessed at a later time by the communication session manager38. When the media is stored in the memory26, the data element54in entry331indicates that media has been stored in connection with the communication session. For the sake of example, and referring toFIGS. 3 and 4a, in the case where the received media is associated with the communication session with Tom, which is an inactive communication session, the communication session manager38causes the media to be stored and causes data element54to indicate that media is stored. It should be appreciated that the data element54may be a text indication, such as “yes” or “no”, or the data element53may simply be a binary code, such as “0” for no stored media, and “1” for stored media. In an alternative embodiment, the media can be stored at the server16, and then accessed by the IM client when required.

By storing media associated with an inactive communication session, the communication session manager38ensures that a user of the communication entity14does not miss a portion of a voice and/or video conversation when the user is focussed on a different communication session, or on another type of computer related task.

In accordance with a non-limiting embodiment, when the communication session manager38receives media associated with an inactive communication session, it can advise the user when media for that inactive communication session is being received, and/or when stored media for that inactive communication session is available. Take for example the situation shown inFIG. 4A, wherein the user is in the progress of having three separate voice conversations; namely with Cindy, Tom and John. The voice conversation with Cindy is the communication session that is currently active, but media may still be received from both Tom and John. As such, in the case where media is being received from Tom while the communication session with Cindy is active, the user may receive a text message in a separate window saying “message being received from Tom”. Alternatively, the user may be presented with an icon in the window associated with Tom, such as an opening letter, or an incoming arrow, which would advise the user that media is being received from Tom. Alternatively, the window associated with Tom may change colour when media from Tom is being received. It should be appreciated that any manner of alerting the user to the fact that media is being received is included within the scope of the present invention. For example, a user may be provided with an indication in an active window that media is currently being received in connection with a communication session in a non-active window.

In addition, the communication session manager38can advise the user of the communication entity14when stored media is available. Keeping with the above example, when media from Tom has been fully received, and is stored in the memory26of the communication entity14, the communication session manager38can advise the user of the communication entity14that stored media from Tom is available. Again, this can be done by providing the user with a text message in a separate window, or in the window associated with Tom, stating that “stored media is available”. Alternatively, an icon representing stored media can be provided in the window associated with Tom. In still another alternative, the window associated with Tom may change colour when stored media is available. In the case where colour is used to advise the user when media is being received and when stored media is available, an inactive window may be green when there is no media associated with that window. Then the window may turn orange as media is being received, and finally turn red once the received media has been stored and is available for playback. It should be appreciated that any manner of alerting the user to the fact that media has been stored is included within the scope of the present invention. For example, a user may be provided with an indication in an active window that there is stored media available in connection with a communication session in a non-active window.

In accordance with an optional embodiment, in the case where voice media is received for an inactive communication session, the communication session manager38further determines whether the received media has had a silence suppression operation performed on it. In one non-limiting example, in the case where the sending communication entity has performed silence suppression on the media prior to transmission, a data bit is included in the header information such that the receiving communication entity knows that a silence suppression operation has been performed on the media. Alternatively, the communication entity14can process the media according to known processing methods in order to determine whether a silence suppression operation has been performed on it. In the case where no silence suppression has been performed on the voice media, the communication session manager38then proceeds to perform a silence suppression operation on the media prior to storing it in the memory26. In this manner, breaks, or pauses in the voice media are removed, such that useless silences are not played back to a user of the communication entity14when the stored media is played back.

In the case where the communication entity14is connected to another communication entity over the network12, each of the communication entities can be provided with presence information associated with the other communication entity. As described previously, the presence information for each communication entity is provided to the IM client34by the network server16. In addition, in certain cases, the network server16may also provide the IM client of each communication entity with information about the state of the communication session at the other communication entity. As such, in the case where the communication entity14(shown inFIG. 2) is involved in a communication session with another communication entity, that other communication entity may be aware when its associated communication session at the communication entity14is in an active state and an inactive state. This information may be provided to the user of the other communication entity via a visual representation on a user interface of the communication entity. In alternative embodiments, the other communication entity may become aware of this information without conveying it to the user. In the case where the other communication entity knows that its associated communication session at the communication entity14is in an inactive state, then it may optionally perform silence suppression on media that it sends to the communication entity14prior to sending it, given that this media will simply be stored upon receipt at the communication entity14. By performing silence suppression on the transmitted media, less bandwidth is required to transmit the media.

However, in the case where the other communication entity is not aware when its associated communication session at the communication entity14is in an active state or an inactive state, then the media sent over the network12(or over a peer-to-peer connection20) is not silence suppressed. For example, in the case where the communication entity14is in the process of conducting a communication session with a communication entity that does not have an IM client but instead simply communicates with the communication entity14via a VoIP connection, then the communication entity that does not run an IM client will not silence suppress voice media that is sent to the communication entity14.

Although not specifically illustrated in the flow chart, it should be appreciated that throughout the course of operation, the IM client34, and specifically the communication session manager38, monitors the communication sessions in progress at the communication entity14to determine when there is a change in the active/inactive state of a communication session.

At step80, the communication session manager38determines whether there is an active communication session, and whether there is stored media associated with the active communication session. This can be checked by continuously polling the entries331-nin the database31, or alternatively, by simply periodically checking the data element54in the entry associated with the active communication session. Alternatively, the communication session manager38simply checks the data element54when a previously inactive communication system becomes active. Alternatively, in the case where an indication is not included within the database31, the communication session manager38can determine whether there is stored media associated with an active communication session by checking directly with the operating system of the communication entity14. This can be done by polling the operating system when new media is received for a communication session.

As mentioned above, when a previously inactive communication session becomes active, media that was stored for that communication session is played for the user of the communication entity14. Therefore, upon detection at step80that there is stored media associated with an active communication session, the communication session manager38proceeds to step76which is to cause the stored media to be conveyed to the user of the communication entity14. As described above, this is done by passing the received media to the media conveyance unit40(shown inFIG. 2), which in turn passes the media to the appropriate speakers and/or display screen46. In this manner, the media is displayed and/or played back to the user of the communication entity14.

In accordance with a first non-limiting embodiment, the stored media for a given communication session is played back to a user of the communication entity14automatically when the window associated with that communication session is re-activated. However, in an alternative non-limiting embodiment, in the case where there is stored media available for a given communication session, when a user of the communication entity re-activates the window associated with that communication session, the communication session manager38may prompt the user to cause the stored media to be played. For example, upon re-activation of a previously inactive window, the user may be provided with a prompt asking “would you like to play back a stored message?”. In order to hear the stored message, the user may have to click on a “yes” button. In yet a further alternative, a user may not be prompted to play back the stored media, and instead is required to pro-actively provide an indication that media stored in connection with that window should be played. For example, the user may have to click on a “play media” button. Or the user may have to select the playback feature from a menu list. For example, the user would have to select MENU→FILE→Play Back.

After step76, or in the case where at step80there is no stored media associated with the active communication session, the process cycles back to step70and starts again.

Process for Outgoing Media

As mentioned above, the communication session manager38of the communication entity14is also operative for handling media that is intended to be sent to another communication entity. A non-limiting example of a process used by the communication session manager38in order to handle outgoing media will now be described in further detail with respect to the flow chart shown inFIG. 6.

At step90, the communication session manager38of the communication entity14receives media destined for another communication entity. As shown inFIG. 2, this media can be received from the microphone44, the video camera42, or in the case of a traditional instant messaging communication session, the keyboard (not shown). As mentioned above, the microphone44and video camera42may be an integral part of the communication entity14or they may be external to the communication entity14and connected via cables and/or a wireless link.

At step92, the communication session manager38of the communication entity14determines whether it is aware of the state of the communication session at the other communication entity. In other words, is the communication session manager38of the communication entity14aware of whether its communication session with the other communication entity is in an active state or an inactive state at the other communication entity. As described above, the communication session manager38may receive presence information from the network server16indicative of whether the communication session between the communication entity14and the other communication entity is in an active state or an inactive state at the other communication entity. However, in other cases, the communication session manager38will not receive this information, and as such will not be aware of the active or inactive state of the communication session at the other communication entity.

In the case where the communication session manager38is not aware of the active or inactive state of the communication session between the communication entity14and the other communication entity at the other communication entity, the communication session manager38proceeds to step94, which is to send the outgoing media to the other communication entity. This is done by passing the outgoing media to the media input/output36and sending this media over either communication link18or20.

However, in the case where the communication session manager38is aware of the active or inactive state of the communication session between the communication entity14and the other communication entity at the other communication entity, the communication session manager38then proceeds to step96, at which point it determines whether the communication session at the other communication entity is in the active or inactive state.

In the case where the communication session between the communication entity14and the other communication entity is in an active state at the other communication entity, the communication session manager38proceeds to step94wherein the outgoing media is sent to the other communication entity. More specifically, given that the communication session is in an active state at the other communication entity, communication between the two entities is happening in substantially real time. As such the communication session manager38at the communication entity14simply sends the outgoing media to the other communication entity14as soon as it is received from the microphone44and/or the video camera42. As described above, the communication session manager38forwards the outgoing media to the media input/output36, which in turn sends the media to the other communication entity over either communication link18or20.

In the case where the communication session manager38at the communication entity14determines at step96that the communication session is in an inactive state at the other communication entity14, meaning that the user of the other communication entity is distracted from the present communication session and is not actively waiting to hear from the user of the communication entity14, then there is no need to send the outgoing media to the other communication entity38immediately. In addition, there is no need to send any silences contained in a voice media message to the other communication entity. As such, when the communication session is inactive at the other communication entity, the communication session manager38at the communication entity14proceeds to step98, which is to perform silence suppression on the media intended to be sent to the other communication entity. Any method suitable for performing silence suppression can be used without departing from the spirit of the invention. In accordance with a non-limiting embodiment, a data element can be included in the header information of the media indicating that it has been silence suppressed.

Once the silence suppression operation has been performed on the outgoing media, the communication session manager38proceeds to step94wherein the silence suppressed media is sent to the other communication entity. More specifically, the silence suppressed media is forwarded to the media input/output36, which in turn sends the media to the other communication entity over either communication link18or20. Since the communication session with the communication entity14is inactive at the other communication entity, when a user at the other communication entity eventually returns to the communication session with the communication entity14, the silence suppressed media has the advantage that it does not take as long to play back to the user of the other communication entity as it took the user of the communication entity14to record. In this manner, even though the user of the other communication entity was distracted for a period of time, it is possible for that user to “catch-up” with the communication session that was previously inactive. In some circumstances, the user of the communication entity14that sent the silence suppressed media, may not even realise that the communication session at the other communication entity was ever inactive.

The method described above with respect toFIG. 6assumes that silence suppression is only performed on outgoing media when it is known that the communication session at the receiving communication entity is in an inactive state. It should, however, be appreciated that silence suppression could be performed on all media being sent between the two communication entities regardless of whether the communication session is active or inactive. In addition, silence suppression can be performed on outgoing media even if the sending communication entity is unaware of the status of the communication session at the receiving communication entity. This is similar to the manner voice media is transmitted in VoIP in order to conserve bandwidth.

In yet a further alternative, it is possible that no silence suppression is performed on outgoing media, regardless of the active or inactive state of the communication session at the receiving communication entity.

Although not shown in the drawings, it should be appreciated that the communication entity14may include a processing unit having suitable hardware, software or firmware for processing data and program instructions in order to execute the various functions of the IM client34described above. Those skilled in the art should appreciate that the program instructions may be written in a number of programming languages for use with many computer architectures or operating systems. For example, some embodiments may be implemented in a procedural programming language (e.g., “C”) or an object oriented programming language (e.g., “C++” or “JAVA”).

Process Performed at Server

It will be appreciated that the system for handling media as described above with respect to the IM client34may also be done by a server unit that is operative for implementing the methods as described above with respect toFIGS. 5 and 6. In order to perform the steps of conveying media to a user of a communication entity14, the server unit may transmit a signal for causing the media to be conveyed via the speakers and/or screen46at the communication entity.FIG. 1illustrates a network-based client-server system10wherein the server16can implement the above described methods for handling media sent between two communication entities14in the client-server system10.

In such an embodiment, the server16can become aware of whether a given communication session is active or inactive at a communication entity by communicating with the operating system, or the IM client34at the communication entity14. Alternatively, the server16can detect inactivity by analysing whether media content is going back and forth between two communication entities, or whether there is a long period of silence following media being received for a given communication session. In yet a further alternative embodiment, the server16may compare a given communication session to other communication sessions taking place at the communication entity. The server could then deduce which communication session is active on the basis of this comparison.

In order to implement the above-described methods, the server16includes a program element for execution by a CPU. The program element implements similar functionality to that described above with respect to the IM client34, and includes the necessary networking functionality to allow the server16to communicate with the communication entities141-nover network12. In a non-limiting example of implementation, the program element includes a number of program element components, each program element component implementing a respective portion of the functionality of IM Client34. Broadly stated, the program element includes 3 program element components:1. The first program element component is for determining when a communication session associated with one of the communication entities is in an inactive state.2. The second program element component is for causing media associated with the communication session to be stored upon determination that the communication session has entered an inactive state; and3. The third program element component is for causing the stored media to be conveyed to a user of a communication entity upon determination that the communication session has re-entered an active state.

Although the present invention has been described in considerable detail with reference to certain preferred embodiments thereof, variations and refinements are possible without departing from the spirit of the invention. Therefore, the scope of the invention should be limited only by the appended claims and their equivalents.