The disclosed embodiments relate generally to the field of electronic messaging. In particular, the disclosed embodiments relate to a technique for handling incoming reply messages.
Mobile phone networks have traditionally been limited to voice communications, but new technologies such as GSM (Global System for Mobile Communications) have enabled mobile phone networks to also include data communications. For example, SMS (Short Message Service) messaging provides a software-independent protocol to send short text messages composed of either: 160-7 bit characters; 70-16 bit characters; or 140 octets of binary data. Individual SMS messages thus require a relatively small network bandwidth and devices can receive messages, even when connected to a voice call. The number of SMS messages a user receives has continually increased because many new types of network devices have joined mobile phone networks. These devices include, for example, PDAs, hybrid PDA/mobile phone devices, and other text messaging devices using GSM networks. Additionally, PSTN devices also exist that support messaging applications such as SMS.
Numerous other types of messaging exist on such mobile devices. For example, email and Multimedia Message Service (MMS) are alternative types of messages available on many mobile devices.
Embodiments described herein provide a technique for reducing clutter in an incoming message folder (sometimes called an “inbox”) by automatically combing certain response or reply messages with an outgoing message that generated the response or reply message. According to one embodiment, an incoming message is identified as a reply message, and information contained in that reply message is used to alter the display of the outgoing message that generated the reply message. Sill further, a graphic feature may be associated or displayed with the outgoing message that generated the reply message, where the graphic feature is representative of a state or content of the message. The outgoing message may be altered in how it is listed or presented so as to provide the graphic feature.
In one embodiment, reply messages that are recognized for purpose of being combined with outgoing messages are acknowledgements of successful/failed delivery, or other forms of messages that carry delivery status information. In one embodiment, the reply messages that are handled include acknowledgements or other messages that provide delivery status, and such messages originate from a third-party (e.g. a wireless carrier of the device on which the outgoing message was generated). Alternatively, such messages may be generated by the intended recipient.
As used in this application, the term “response” and “reply message” are interchangeable, and refer to messages that are responsive to another original message. Response or reply message may originate from an intended recipient of the message or from a third-party that was involved in the handling of the message. In one embodiment, the reply message is an acknowledgement message that, originating from a third-party (e.g. not the recipient) that confirms or communicates delivery status of the originating message.
According to an embodiment, messages are handled by a determination that an incoming message is in response to a previous outgoing message, where the previous outgoing message is sent from the computing device. The previous outgoing message is identified, as stored on the computing device. Data that indicates information relating to receiving the incoming message is provided with at least (i) a listing of the previous outgoing message, or (ii) a body of the previous outgoing message.
A specific type of messaging contemplated by one or more embodiments is Short Message Service (SMS) messaging. In come cases, newly transmitted SMS message may return to the user a programmatically generated acknowledgement from another source. For example, some wireless carriers always generate an acknowledgement SMS message when the user transmits his own SMS message. The acknowledgement message may include delivery status information or data indicating whether the original outgoing message was successfully received or not. Such acknowledgement messages may be generated each time an SMS message is sent from a device, even if the device is sending messages when participating in a chat thread. The result is that the acknowledgements clutter the user's inbox. Under one or more embodiments described herein, such acknowledgements may be removed from the inbox, and represented alternatively (e.g. in graphic form) with the message in another folder (e.g. “sent items” folder).
Under embodiments described herein, SMS acknowledgement messages are not listed, but rather represented graphically in association with the original outgoing message in a manner that indicates the acknowledgement was received. The graphic representation of the acknowledgement message may indicate the content of the acknowledgement message. For example, in the example provided, the acknowledgement message may carry indications of whether the outgoing message was successfully received or not. According to an embodiment, a graphic feature indicating success or failure of the outgoing message may be presented with the listing of the outgoing message.
According to an embodiment, a message listed in an incoming message folder may be identified, where the identified message is a reply to a previous outgoing message. The previous outgoing message listed in an outgoing folder may be identified. A feature representing the message for display with a listing of the previous outgoing message may be generated and displayed with the listing of the identified outgoing message.
In one embodiment, the listing of the identified incoming message is removed from the incoming message folder once the feature is generated in the outgoing folder.
Furthermore, one or more embodiments may include monitoring for receipt or storage of an incoming message that is a reply to a previous outgoing message. In response, the feature representing the message may be generated automatically.
According to an embodiment, the generated feature may represent a content of identified message listed in the incoming message folder. In one embodiment, the identified message may correspond to a confirmation message, and the feature generated for display with the listing of the previous outgoing message represents whether that outgoing message was received (confirmation) or not received (non-confirmation).
As used herein, messages may include text or media messages transmitted over data networks or telephony networks. One implementation provides for messages to include email messages, which are typically exchanged over data channels and between servers that operate under email protocols such as POP3 or IMAP. Another implementation provides for messages to include SMS messages, which are transmitted as text over telephony networks, and can be rendered instantly on receipt by the receiving device. Still further, Multimedia Message Service (MMS) and Instant Messaging formats/protocols are also contemplated.
The term “reply message” means any message that is generated or made in response to another message. The reply message may be generated by either a third-party or by the recipient of the message that is replied to. As an example, embodiments are described below in which the reply messages correspond to SMS acknowledgements, each of which may be generated by a carrier that handles the original outgoing SMS message (rather than the recipient or recipient device of the message).
Numerous types of computing devices may be used with embodiments described herein. As mentioned, one type of computer telephony device for use with an embodiment is a wireless, mobile computing device, sometimes called the “smart phone” or hybrid devices. Such devices are generally small enough to fit in one hand, and provide cellular telephony features in combination with other applications, such as contact applications for managing contact records, calendar applications for managing and scheduling events, task applications for keeping lists, and camera applications for capturing images. Many types of messaging transports may be provided on such mobile computing devices, including SMS, MMS, email and instant messaging.
Other types of computing devices are contemplated for use with one or more embodiments described herein. Such computing devices include a desktop computer, laptop, personal digital assistant (PDA) or other computing device that can support messaging and messaging applications.
One or more embodiments described herein provide that methods, techniques and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically means through the use of code, or computer-executable instructions. A programmatically performed step may or may not be automatic.
Additionally, or more embodiments described herein may be implemented using modules. A module may include a program, a subroutine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions, or alternatively, a hardware component configured through software or other programmatic elements. As used herein, a module can exist on a hardware component independently of other modules, or a module can be a shared element or process of other modules, programs or machines.
The use of terms such as “component” or “element”, when presented in the context of software or programming, may refer to code that can be executed to perform a stated function or task. Such code may execute or be shared with other components or elements, even when a component or element is described or shown to be disparate from other components.
Furthermore, one or more embodiments described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown in figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing embodiments of the invention can be carried and/or executed. In particular, the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash memory (such as carried on many cell phones and personal digital assistants (PDAs)), and magnetic memory. Computers, terminals, network enabled devices (e.g. mobile devices such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums.
According to another embodiment, a transmission of an outgoing message to a plurality of intended destinations is recorded. Subsequently, one or more incoming messages are determined to be in response to the outgoing message. Each of the one or more incoming messages may include delivery status information for the outgoing message as transmitted to one or more of the plurality of intended destinations. A graphical data representation may be generated that indicates information relating to the delivery status of the outgoing message as transmitted to all of the plurality of intended destinations, based on the delivery status information of each of the one or more incoming messages.
Overview
In step 110, an incoming message is received on a computing device that executes a messaging application. In an embodiment, the incoming message is an email, received across a cellular network or the Internet. In another embodiment, the message is an SMS message, received over, for example, a wireless cellular network. Other implementations and types of messages are contemplated.
In one implementation, the computing device includes an operating system, one or more messaging applications, and an interface for communication hardware. For example, the computing device may correspond to a wireless telephony device, and the communication hardware may correspond to a radio for transmitting and receiving data over cellular networks. In such an example, the operating system may correspond to a mobile OS, such as PALM OS, manufactured by ACCESS INC. or WINDOWS MOBILE, manufactured by the MICROSOFT CORPORATION.
Step 115 provides that a determination is made as to whether the incoming message is a reply message. In the SMS messaging context, for example, the incoming message will have an identification. As described with embodiments below, the incoming message identification may be used to identify the message is response or reply to a previous outgoing message. For example, the identification may be numerical in nature, and carried in the body or header of the incoming message. Alternatively, the identifier may have its own field in the incoming message.
In another embodiment, features or aspects of the incoming message, other than identification embodied in the message, may be used in making the determination that the incoming message is a reply message. In one embodiment, for example, the incoming message may be identified as a reply message through the words or text string carried in the subject line of the message. For example, the appearance of “re:” in the subject line may denote that the incoming message is a reply to another message that has the same remainder in the subject line. Still further, the original outgoing message may carry an identifier (e.g. numerical, time stamp) generated on the device making the transmission, and the incoming message may provide the entire outgoing message, including the identifier. Numerous other alternatives or context is possible.
If the incoming message is not a reply message, then step 120 provides that the incoming message is listed in the incoming message folder, with no further action.
If the incoming message is determined to be a reply message, step 130 provides that the outgoing message that generated the reply is identified. As described above, for example, this outgoing message may have the same identifier (as is the case of SMS messages), or the same subject line in the case where the messages are emails.
Once the reply message is identified, numerous implementation options exist.
As an alternative or addition to an implementation in which step 140 is performed, step 150 provides that content from the reply message is indicated or displayed with the outgoing message, or at least its listing. For example, if the incoming reply message is an acknowledgement that indicates a positive response (e.g. successful transmission or receipt of the previous outgoing message), one embodiment may provide for a green symbol representative of the positive response to be provided within the outgoing message. Alternatively, such a feature may be listed adjacent to the message as listed in, for example, the “sent items” folder. Still further, text lines in the reply message may be copied and included in the outgoing message that generated the reply.
As another alternative or addition, step 160 provides for the incoming message to be excluded from being listed as a new message in, for example, an inbox. In one embodiment, the incoming message may be deleted entirely if the content of indication provided by the message is carried into the outgoing message that generated the reply. Alternatively, the incoming message may be archived, or moved into a folder that is apart from the inbox. In either case, if the message is a reply message, the incoming message may be ignored, or combined (such as through conversion to graphics or copying of text or other content from that message) with the outgoing message, such that a message or content carried in that incoming message is carried by the outgoing message.
Incoming Reply Messages with Radio-Level Identifiers
A system such as shown by
One or more embodiments utilize the fact that incoming SMS reply messages typically carry the hardware layer identifier 242 of the original outgoing message. In order to identify an incoming message as a reply message, and associate that message with a previously transmitted outgoing message, one or more embodiments provide for use of a bridge component 240 that can cross-reference the hardware layer identifier 242 with the application layer identifier 212.
Likewise, the hardware layer identifier 242 may be maintained in a separate structure 245 that relates the hardware layer identifier to characteristics of an incoming or outgoing SMS message. Incoming reply SMS messages that are acknowledgements often carry certain properties, such as flags 244 and message data 246. The message data 246 may convey an acknowledgement value (e.g. “success” or “failure”). In the case of acknowledgements, the incoming messages may include message data 246 in the form of error codes or pass codes. These characteristics of the SMS message may be identified and stored in the structure 245 as shown.
As mentioned, embodiments described herein provide for incoming messages to be identified as reply messages, and then combined or otherwise presented with the outgoing message. In the SMS example provided by
Under standard implementation, components such as the hardware interface 230 have access to an incoming messages hardware layer identifier 242, but not to the application layer identifier 212. Likewise, the application 210 may be able to use the application layer identifier 212, but not the hardware layer identifier 242. Accordingly, embodiments of the invention provide that the bridge component 240 relates the application layer identifier 212 to the hardware layer identifier 242. According to an embodiment, the bridge component 240 may be coupled to the messaging application 210 and to the hardware interface 230. The bridge component 240 may intercept or receive each of the application layer identifiers 212 and hardware layer identifiers 242.
Since SMS reply messages (particularly acknowledgement messages) have the same hardware layer identifier 242 as that generated for the original outgoing message to which the reply is made, the bridge component 240 may use the hardware layer identifier 242 of any new incoming message to identify a match to other messages with the same hardware layer identifier 242. For example, if a match is identified, the associated application layer identifier 212 is determined for the matched message. The structure 215 is then used to identify the original outgoing message, including the location of that message and its contents and headers etc. For example, the original message may reside in a Sent Item folder, or an archive folder, and have a body, subject line and address line. Once the application layer identifier 212 is identified, such information may be retrieved from the table 215. The structure 245 may be used to identify information from the incoming reply message.
In one embodiment, a message modifier component 250 may use information from table 215 to modify or alter the presentation, rendering or listing of an outgoing message that is identified as being the source of the reply message. The message modifier 250 may access a message store 260 to identify the original message that is the source of the incoming reply message. For example, the original outgoing message may be listed or rendered in whole or in part in a particular folder. In one embodiment, the message modifier component 250 may then use information from the matching incoming reply message, as carried in the structure 245, to generate a graphic that is indicative of the message data 246 or content, and to associate that graphic with the outgoing message. For example, the incoming message may carry delivery status information, indicating whether the previous outgoing message was successfully received by the intended recipient or at the intended destination. Accordingly, an acknowledgement SMS message that indicates the message was received may have no error code, and have text or a flag value that indicates the message was successfully transmitted. In such a case, the message modifier 250 may present a graphic in association with the listing or body of the original outgoing message, indicative of the successful transmission. The listing of the message may be an abbreviated rendering of the message, such as by subject line or other header or address information. Likewise, an acknowledgement message may have an error code and/or a flag value that is indicative of an unsuccessful transmission. In such cases, the graphic generated by the message modifier 250 may represent the outgoing message to have been unsuccessfully transmitted.
As an alternative, the message modifier 250 may display other information, including text. Furthermore, under one embodiment, the information may be presented interactively. For example, the information may represented graphically, and the graphic feature may be selectable to present text corresponding to, for example, the error code presented with message data 244.
Depending on the implementation, message modifier 250 may be functionality provided with one or more of the following components: application 210, operating system (not shown), bridge 240. Alternatively, the message modifier 250 may be provided as an independent component.
An embodiment such as shown by
Methodology
In
Accordingly, the modification to a previously sent outgoing message may be a graphic and/or text item indicating either (i) the previous outgoing message was successfully transmitted, or (ii) the previous outgoing message was not successfully transmitted. In the latter case, the message may be viewed, opened or otherwise manipulated to display, for example, the error code underlying the reason of the failure (e.g. “network was busy”).
Device Illustration
Accordingly, device 400 may be configured to include, for example, bridge component 250 for (i) match the hardware layer identifier 412 of an incoming message 410 with the hardware layer identifier 422 of a previously sent message 420 in order to identify the incoming message as being an acknowledgement reply (or other form of reply) to that previously sent message; (ii) associate the matching hardware layer identifier 412 of the incoming message (now determined to be a reply) to the application layer identifier (not shown in
In
Multiparty Messaging
Messaging applications allow users to address multiple parties at one time, using the body of a single message. In examples such as provided above with SMS messaging, a transmission to multiple parties may (for certain wireless carriers) receive multiple responses. Different protocols may be used to indicate whether a message was successfully transmitted if some, but not all of the recipients successfully received the messages. In one embodiment, the message is marked with graphics or otherwise as having failed to be successfully transmitted if just one recipient did not successfully receive the message. The user may view the sent items in order to see additional information as to which recipients did receive a message successfully.
Under an embodiment, the bridge component 250 may handle multi-party messages by associating application layer identifiers to hardware layer identifiers, as described above. With a multi-party message, an outgoing message may have one application layer identifier and multiple hardware layer identifiers. For example, for an outgoing message addressed to two people, the following may apply:
The above shows one message composed to two people may, at the application layer, be assigned one application layer identifier, but be assigned two hardware layer identifiers (as two messages are actually sent). Acknowledgements to each may carry corresponding hardware layer identifiers, and return acknowledgements to each may map to the same application layer identifier. Thus, two acknowledgements may be compiled for one composed message addressed to two people, and the listing or rendition of that outgoing multiparty message may be modified based on the combined acknowledgements.
Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments. As such, many modifications and variations will be apparent to practitioners skilled in this art. Accordingly, it is intended that the scope of the invention be defined by the following claims and their equivalents. Furthermore, it is contemplated that a particular feature described either individually or as part of an embodiment can be combined with other individually described features, or parts of other embodiments, even if the other features and embodiments make no mentioned of the particular feature. Thus, the absence of describing combinations should not preclude the inventor from claiming rights to such combinations.
This application claims benefit of priority to provisional U.S. Patent Application 60/753,291, filed Dec. 21, 2005; the aforementioned priority application being hereby incorporated by reference for all purposes.
Number | Name | Date | Kind |
---|---|---|---|
5708655 | Toth et al. | Jan 1998 | A |
5844967 | Lee | Dec 1998 | A |
5901211 | Dean et al. | May 1999 | A |
5943401 | Risner et al. | Aug 1999 | A |
5991290 | Malik | Nov 1999 | A |
6055305 | Norman et al. | Apr 2000 | A |
6055510 | Henrick et al. | Apr 2000 | A |
6061346 | Nordman | May 2000 | A |
6081845 | Kanemaki et al. | Jun 2000 | A |
6219413 | Burg | Apr 2001 | B1 |
6229878 | Moganti | May 2001 | B1 |
6279018 | Kudrolli et al. | Aug 2001 | B1 |
6304636 | Goldberg et al. | Oct 2001 | B1 |
6304753 | Hartmaier | Oct 2001 | B1 |
6404860 | Casellini | Jun 2002 | B1 |
6430271 | DeJesus et al. | Aug 2002 | B1 |
6442263 | Beaton et al. | Aug 2002 | B1 |
6463154 | Patel | Oct 2002 | B1 |
6484036 | Sorkin et al. | Nov 2002 | B1 |
6516202 | Hawkins et al. | Feb 2003 | B1 |
6532368 | Hild et al. | Mar 2003 | B1 |
6608637 | Beaton et al. | Aug 2003 | B1 |
6628938 | Rachabathuni et al. | Sep 2003 | B1 |
6633761 | Singhal et al. | Oct 2003 | B1 |
6647108 | Wurster et al. | Nov 2003 | B1 |
6658254 | Purdy et al. | Dec 2003 | B1 |
6671735 | Bender | Dec 2003 | B1 |
6680935 | Kung et al. | Jan 2004 | B1 |
6697473 | Batten | Feb 2004 | B2 |
6751453 | Schemers et al. | Jun 2004 | B2 |
6763235 | Imai | Jul 2004 | B2 |
6768789 | Wilk | Jul 2004 | B1 |
6781575 | Hawkins et al. | Aug 2004 | B1 |
6795530 | Gilbert et al. | Sep 2004 | B1 |
6801955 | Dunlap et al. | Oct 2004 | B2 |
6823184 | Nelson | Nov 2004 | B1 |
6829607 | Tafoya et al. | Dec 2004 | B1 |
6839877 | Iwata | Jan 2005 | B2 |
6895426 | Cortright et al. | May 2005 | B1 |
6928305 | DeWald et al. | Aug 2005 | B2 |
6973299 | Apfel | Dec 2005 | B2 |
7007239 | Hawkins et al. | Feb 2006 | B1 |
7009990 | Adams et al. | Mar 2006 | B1 |
7010288 | Brown et al. | Mar 2006 | B2 |
7013130 | Ku | Mar 2006 | B2 |
7027583 | Uranaka et al. | Apr 2006 | B2 |
7032174 | Montero et al. | Apr 2006 | B2 |
7051099 | Ziegler et al. | May 2006 | B2 |
7117445 | Berger | Oct 2006 | B2 |
7124370 | Fish | Oct 2006 | B2 |
7136466 | Gao | Nov 2006 | B1 |
7139555 | Apfel | Nov 2006 | B2 |
7151952 | Nakatsuchi et al. | Dec 2006 | B2 |
7171236 | Heo | Jan 2007 | B2 |
7190975 | Rho | Mar 2007 | B2 |
7216133 | Wu et al. | May 2007 | B2 |
7218710 | Ali et al. | May 2007 | B1 |
7225409 | Schnarel et al. | May 2007 | B1 |
7231208 | Robertson et al. | Jun 2007 | B2 |
7231229 | Hawkins et al. | Jun 2007 | B1 |
7233813 | Kokubo | Jun 2007 | B2 |
7243163 | Friend et al. | Jul 2007 | B1 |
7254573 | Burke | Aug 2007 | B2 |
7286649 | Nelson et al. | Oct 2007 | B1 |
7287097 | Friend et al. | Oct 2007 | B1 |
7295852 | Davis et al. | Nov 2007 | B1 |
7302270 | Day | Nov 2007 | B1 |
7302280 | Hinckley et al. | Nov 2007 | B2 |
7325032 | Zuberec et al. | Jan 2008 | B2 |
7376846 | Hawkins et al. | May 2008 | B2 |
7418663 | Pettinati et al. | Aug 2008 | B2 |
7430719 | Pettinati et al. | Sep 2008 | B2 |
7447799 | Kushner | Nov 2008 | B2 |
7474298 | Nguyen et al. | Jan 2009 | B2 |
7477908 | Klassen et al. | Jan 2009 | B2 |
7502849 | Roberts et al. | Mar 2009 | B2 |
7522536 | Roberts et al. | Apr 2009 | B2 |
7522913 | Kraft | Apr 2009 | B2 |
7543243 | Schwatrz et al. | Jun 2009 | B2 |
7570747 | Nakatsu | Aug 2009 | B2 |
7634069 | Randall et al. | Dec 2009 | B2 |
7680513 | Haitani et al. | Mar 2010 | B2 |
20010003826 | Iwata | Jun 2001 | A1 |
20010042100 | Guedalia et al. | Nov 2001 | A1 |
20020016735 | Runge et al. | Feb 2002 | A1 |
20020067714 | Crain et al. | Jun 2002 | A1 |
20020118396 | Kawai | Aug 2002 | A1 |
20020187794 | Fostick et al. | Dec 2002 | A1 |
20030033582 | Klein et al. | Feb 2003 | A1 |
20030046256 | Hugosson et al. | Mar 2003 | A1 |
20030210260 | Palmer et al. | Nov 2003 | A1 |
20040024846 | Randall et al. | Feb 2004 | A1 |
20040203794 | Brown et al. | Oct 2004 | A1 |
20040230494 | Lotvin et al. | Nov 2004 | A1 |
20050043036 | Ioppe et al. | Feb 2005 | A1 |
20050043037 | Ioppe et al. | Feb 2005 | A1 |
20050131992 | Goldstein et al. | Jun 2005 | A1 |
20050188312 | Bocking et al. | Aug 2005 | A1 |
20050198144 | Kraenzel et al. | Sep 2005 | A1 |
20050201533 | Emam et al. | Sep 2005 | A1 |
20050216949 | Candelora et al. | Sep 2005 | A1 |
20050227740 | Orbach | Oct 2005 | A1 |
20060015644 | Cernohous et al. | Jan 2006 | A1 |
20060020615 | Keohane et al. | Jan 2006 | A1 |
20060020993 | Hannum et al. | Jan 2006 | A1 |
20060041470 | Fiho et al. | Feb 2006 | A1 |
20060129929 | Weber et al. | Jun 2006 | A1 |
20060215829 | Schwartz | Sep 2006 | A1 |
20060242109 | Pereira et al. | Oct 2006 | A1 |
20060288297 | Haitani et al. | Dec 2006 | A1 |
20060288298 | Haitani et al. | Dec 2006 | A1 |
20070036286 | Champlin et al. | Feb 2007 | A1 |
Number | Date | Country |
---|---|---|
0611239 | Aug 1994 | EP |
1117185 | Jul 2001 | EP |
1503604 | Feb 2005 | EP |
1020060093183 | Aug 2006 | KR |
1020070078369 | Jul 2007 | KR |
WO 9848550 | Oct 1998 | WO |
WO 9926127 | May 1999 | WO |
WO 0150680 | Jul 2001 | WO |
WO 2004104789 | Dec 2004 | WO |
WO 2005111849 | Nov 2005 | WO |
Number | Date | Country | |
---|---|---|---|
20070143429 A1 | Jun 2007 | US |
Number | Date | Country | |
---|---|---|---|
60753291 | Dec 2005 | US |