Patent Application
20070276913
The same numbers are used throughout the disclosure and figures to reference like components and features.
The following document describes tools capable of enabling participants in a real-time, text-messaging conference to access text messages that they have missed, whether that be because they joined the conference late, were disconnected, or did not receive a message due to some sort of failure. These tools may do so in distributed, centralized, or combined communication topologies.
An environment in which the tools may enable these and other actions is set forth below in a section entitled Exemplary Operating Environment. This section is followed by another section describing one exemplary way in which the tools may act to enable participants in a real-time, centralized text-messaging conference to access text messages that they have missed and is entitled Example Instant Messaging Conference in a Central Communication Topology. A final section describes various other embodiments and manners in which the tools may act to enable participants in a real-time, text-messaging conference to access text messages that they have missed in a centralized, distributed, or combined communication system and is entitled Other Embodiments of the Tools. This overview, including these section titles and summaries, is provided for the reader's convenience and is not intended to limit the scope of the claims or the entitled sections
Before describing the tools in detail, the following discussion of an exemplary operating environment is provided to assist the reader in understanding some ways in which various inventive aspects of the tools may be employed. The environment described below constitutes but one example and is not intended to limit application of the tools to any one particular operating environment or conferencing system. Other environments and systems may be used without departing from the spirit and scope of the claimed subject matter.
The environment also has a communications network 114, such as a company intranet or a global internet (e.g., the Internet) and in some cases has access to a server 116. The participants' devices may be capable of communicating directly to the network (e.g., a wireless-Internet enabled laptop, PDA, or a Tablet PC, a wired Internet-enabled desktop computing device, or VoIP-enabled telephone or cellular phone wired or wirelessly connected to the Internet) or indirectly (e.g., the telephone connected to the phone-to-network device). The conference may be enabled through a distributed (e.g., peer-to-peer) or central network topology (or a combination of these). Exemplary distributed and central network topologies are illustrated in
The server 116 and/or any of these devices, including the phone and the phone-to-network device, may be a computing device having one or more processor(s) 118 and computer-readable media 120 (each device and the server marked with “◯” to indicate this possibility). The computer-readable media comprises a text-messaging conference module 122 (“module”) and a text-message history 124 (“history”). Each of the text messages 126a through 126n in the history may have an associated unique identifier 128a through 128n, respectively. Each of the participants may also have an identifier usable to verify their identity (not shown). Note that the term “participants” is sometimes used interchangeably with the communication device used by the participants, as will be apparent by the context.
The processor(s) are capable of accessing and/or executing the computer-readable media. The module(s) are capable of sending and/or receiving text messages and other actions described in greater detail below. The module(s) and history(s) are shown as a cohesive unit, though each may be disparately placed.
Each of the participants may contribute and receive (through their devices) text messages in real time as part of a real-time, text-messaging conference. In a distributed conferencing system each of the participants includes a module and history, though the history may be incomplete. In the centralized conferencing system the module and the history are accessible by the server, though each of the participants may have a module and history as well. Example centralized and distributed conferencing systems are set forth below.
In either of these topologies or a combined topology, the module receives text messages from conference participants and records at least the most-recently received message or a unique identifier for each message. In a central communication topology, the MCU server records all of the messages, to whom they are sent, from whom they are received, and unique identifiers for each message. Also in the central communication topology, each participant's communication device records at least the last message or a unique identifier for the last message. In a distributed communication topology, each of the participant's modules may record all of the text messages received. As will be discussed below, if any one of the participants recorded a text message missed by another of the participants, the text message may be accessed by the other participant that missed it. For ease in explanation, the following examples cover three participants, though many more may be handled.
In this section three wireless devices A, B, and C of
This example is illustrated in
At arrows 1, 2, and 3, Al joins an instant-messaging conference hosted by the MCU server. Here joining involves sending an invite, receiving an okay, and sending an acknowledgement in response to the okay.
At arrows 4, 5, and 6, Bo joins the same instant-messaging conference. Al then sends Bo a message, namely “hello Bo”, at arrows 7 and 8. To do so, Al sends the message to the MCU server, which responds that it received the message and also gives that message a unique identifier. Here the identifier is simply a “1”, though other types of identifiers could be used (e.g., a unique time-stamp).
The MCU server then sends that message to the other participants, here just Bo at arrows 9 and 10. Bo receives this message and then responds to Al at arrows 11 and 12. Bo responds with a message, namely “hey Al”, which Bo's device sends to the MCU server and in response to which the MCU server responds that it received the message and gives it a unique identifier (here “2”).
The MCU server then sends that message to Al at arrows 13 and 14. The history built up by the MCU server so far is:
This history indicates the text of the messages, their unique identifiers, and their chronology, here through the unique identifier gaining at a set value (e.g., from 1 to 2, from 2 to 3, and so forth) and also by recording that each message after the first is in reply to the immediate-prior message. Note also that each of the device's 102 and 104 may also record the messages, their unique identifiers, and/or their relationship. This information may be stored by each device's module or other software and in a history, such as module 122 and history 124 of
At arrows 15, 16, and 17 Cate joins the same instant-messaging conference and requests the conference's history. The MCU server may require that a participant request history or may just send it to them when they join or rejoin. The MCU server may also require that one or more of the other participants (those participants that sent and received the desired history) assent to another (e.g., new) participant getting the history. Here, however, the MCU server requires only that the history be requested.
At arrows 18 and 20 the MCU server sends the history to Cate. Here the MCU server sends all of the history of the conference, namely the first and second messages and in the order they were first received by the MCU server. The MCU server may send them as a block or message-by-message. At arrows 19 and 21 Cate's device acknowledges receiving each of the messages.
Cate's device also displays these text messages to Cate so that she can get up to speed with the conference. Thus, she can see in her conference user interface first “hello Bo” and then “hey Al”. With these messages she can know that very little has happened (just Al and Bo saying hello to each other).
As is apparent, this is a relatively simple case. There are only three participants and the participant needing the history is a new participant that missed little of the conference. In many cases, however, a new participant will have missed many messages and need these messages to be able to contribute to the conference. In other cases, one of the participants may become disconnected or not receive a message due to some sort of failure. In these cases the MCU server (namely the module and history on the MCU server) may act to provide these missing text messages.
Consider, for example, a case where Al is disconnected or simply does not receive messages for a period of time. Assume that Cate, in this space of time, sends a message: “hello Al, can you send me that Power Point document?”. This message is received by the MCU server, which assigns it a unique identifier “3”, notes that it is in reply to message 2 (“hey Al”), and then sends this message to both Al and Bo. But here Al does not receive it. Here both Al's device and Bo's device record the unique identifier of the last message they received in their local histories. Thus, Al has unique identifier 2 in its history. Bo received the message from Cate and so has unique identifier 3 in its history and also that this message was in reply to message 2. Now assume that Al rejoins or his device is otherwise now receiving messages properly. Bo sends a reply to Cate with a message “Cate, I updated Al's Power Point, I'll send it to you via email”, which the MCU server records, assigns a unique ID of 4, and that it is in reply to message 3. The history at the MCU server is now:
The MCU server then sends Bo's message to both Al and Cate, which Al receives. Note here that Al's history will show a problem:
Al's module determines that a message is missing. Here it may determine this because it has a unique ID=2 and a unique ID=4 but no unique ID=3. By so doing, the module determines that it did not receive the message with unique ID=3. Or it may determine this because it received a message in-reply-to message 3 but it does not have message 3. In either case Al's module knows that it is missing a message.
In response, Al's device automatically requests message 3 from the MCU server. The MCU server previously retained this message and its unique identifier and so can find it and send it to Al's device. Al's device may then display it to Al and as part of the ongoing conference. Al is now up to speed on the conference and so knows that Cate asked him for the Power Point document but that Bo stepped up and sent a newer version instead.
In the above section exemplary ways are described in which the tools may act to enable participants in a real-time, centralized text-messaging conference to access text messages. Below other embodiments of the tools are provided that may be implemented in a centralized, distributed, or combined communication system and for a conference where two or more participants exchange text messages.
These exemplary embodiments are described as part of two processes 500a and 500b of
These processes 500a and 500b are separated by a dashed line through which the entities communicate over a communication network, such as network 114 of
Block 502 sends a text message, which is received at block 504. This text message may include or be sent with an indicator useful in determining that some other message has not been received. This message may be from another participant of the conference's device and sent directly or through an intermediary. If the message is from another participant in a central communication topology, for instance, the message may have been sent to an MCU server before being sent by the server at block 502. If the message if from another participant in a distributed communication topology, it may have been sent directly from the other participant. In any of these cases, the sender or senders may store all of the messages of a conference. In some embodiments they do so in an archives in which case all of the messages may be retrieved even if the number of messages or the storage requirement for the messages are quite large.
Block 506 records this message and/or an included indicator. In the example described above, module 122 records an indicator comprising a unique identifier for that message in a local history 124. This message or identifier may be used to determine if other messages may be missing.
Block 506 may record many or all of the messages and/or indicators that it receives (though this may not be all of the messages or indicators of the conference). This may aid in later displaying messages that were missed in their correct sequence relative to messages that were not missed.
Block 508 sends another message, which is received at block 510. This message may also include or be sent with an indicator that is useful in determining that some other message has not been received.
Block 512 records this message and/or its indicator as previously done at block 506. Block 512 may choose to record just the indicator (e.g., a unique identifier), though in a distributed communication topology the module may record the messages too so as to be able to provide them to another participant at some later time.
Block 514 determines that one or more messages have not been received. Block 514 may do so by comparing indicators of two messages that have been received, such as the message received at block 506 and the message received at block 512. Block 514 may also do so with an indicator indicating a relationship between the second received message and another message that has not been received. In the above example Al's device determines that it did not receive the message from Cate because Bo's message included an indicator indicating that Bo's message was the fourth message and Al's device knew that it had only last received a second message.
Block 516 sends a request for text messages, such as with an indicator indicating that one or more text messages were not received. In some cases this request indicates that all of the history retained by the entity to which it is sent is desired. In this case the request may be from a new participant (which will not have performed prior blocks). This new participant likely desires all of the text messages of the conference. In some other cases the participant that sends the request is not new but desires all of the history. The participant may want all of the history for some other reason, such as to record and forward it in an email. Or the participant's device may think it is missing a message and so intend to compare all of the messages in the conference with its own retained history, determine which have not been shown to the participant, and show those messages to the participant.
In still other cases, the request includes an indicator having a unique identifier of a message last-received in real-time or last-received prior to the message used to determine that a message is missing. If the participant's device knows that there is a problem the device may send this request and indicator, though the device may determine that there is a problem by knowing that a message is or may be missing. A message may be missing if a participant is dropped from the conference and he or she rejoins, though in some cases he or she may rejoin fast enough to not miss a message.
This indicator may also comprise information indicating that the participant was or is a part of the conference. An identifier for the participant, for instance, may be sent with the request so that the entity may determine if the participant should be allowed to see the requested text messages.
The request at block 516 may also indicate at what rate or in which manner to provide the messages, such as one message every five seconds, the messages twice as fast as they were originally made, or all of the messages sent in bulk.
Block 518 receives the request for text messages, which may include an indicator. Block 520 determines that the participant has not had access to at least some of the history. The tools may determine that the participant has not had access to any of the history based on the indicator indicating that the participant just joined the conference for the first time. Or the tools may determine that the participant has had access to some of the history based on the indicator indicating that the participant has rejoined the conference. In this case the indicator may include a verifiable identity for the participant. It may also indicate a time at which the participant was dropped from the conference.
In some cases, the tools determine which messages the device is missing with a unique identifier for the messages or a relationship between them, such as message with ID=3 in the above example. This determination may be trivial when the participant's device indicates with specificity which messages are desired (e.g., by sending each desired message's unique identifier). In some cases, however, the tools compare the unique identifiers of messages that have been received by the participant with unique identifiers for all of the conference's recorded messages and send those that were not received.
Block 522 provides some or all of the history. The tools may provide only those messages indicated by the participant as having been missed (e.g., those subsequent to the last one received in the proper order). Or the tools may provide all of the history and let the participant's device determine which were missed and which were not. To aid the participant's device, the tools may provide information about the messages sufficient to determine which of the messages the participant has not previously had access. In one case the tools do so with unique identifiers for each message provided. With these unique identifiers the participant may sort through and find those that were missed.
The tools may provide the history at various rates or in various manners, such as messages per some unit of time, a speed relative to how fast they were originally received (e.g., faster, the same, or slower), in bulk, and so forth. If a rate or manner was requested at block 516, the tools may provide the messages as requested. This may make handling and display by the participant's device at block 526 easier, such as by the participant's module 122 being able to handle the messages similarly to those sent in the normal course of the conference.
As noted in the above example related to
Block 524 receives the history. In some cases the device receives the history and displays (at block 526) whatever messages were not previously viewed by the participant. As noted in the above example of
Block 528 optionally records the history, whether all of it was received at block 524 or in the normal real-time course of the conference.
The above-described tools enable participants to gain access to text messages in a text-messaging conference. The tools may do so in various types of communication topologies and permit participants to stay up to speed with a conference whether they are new, disconnected, or do not receive messages due to a failure. Although the tools have been described in language specific to structural features and/or methodological acts, it is to be understood that the tools defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the tools.
