Electronic device and method for selectively applying message actions   

Abstract: An electronic device and method are provided for automatically identifying a message in a message thread to which a selected single-message action is to be applied, without requiring display of individual messages in a separate listing. Each single-message action is associated with one or more message attributes. When a single-message action is selected, a message in the thread having matching attributes is selected. While the selected message may be the most recent message in the thread having those attributes, but may not be the most recently received or most recently sent message in the thread.

TECHNICAL FIELD

This application claims priority to Canadian Patent Application No. ______ filed on 18 Jul. 2011 having attorney docket number 40575-CA-PAT, the entirety of said application is incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates generally to an electronic device and method for applying actions to electronic messages.

A messaging client executing on an electronic device may be configured to display messages to the user in a listing ordered according to a message attribute such as message timestamp, recipient or sender, or subject line. Messages may also be logically or physically grouped in threads (conversations), which are collections of messages having a common thread identifier value, subject line, or other message attribute. The messaging client may thus display an ordered listing of message threads rather than individual messages. This view provides for an efficient display of information to the user, since each entry displayed in the list may represent a group of both sent and received messages. When the user wishes to take an action applicable to a single message, such as replying to a message or forwarding a message, one of the message threads listed in the display must be selected and a further view of the messages contained within that thread displayed so that the user may select the appropriate message to which the action is to be applied.

BRIEF DESCRIPTION OF THE DRAWINGS

In drawings which illustrate by way of example only embodiments of the present application, in which like reference numerals describe similar items throughout the various figures,

FIG. 1 is a block diagram of an embodiment of an electronic device for use with the embodiments described herein.

FIG. 2 is a schematic diagram illustrating interoperation of message data stores, collection objects, and a messaging client executing on the electronic device of FIG. 1.

FIG. 3 is an example of a graphical user interface displaying a message thread listing view on an electronic device.

FIG. 4 is an example of a graphical user interface displaying an individual message list view on an electronic device.

FIG. 5 is a variant of the graphical user interface of FIG. 3 with graphical user interface elements for message actions.

FIG. 6 is an example of a graphical user interface for a message composition screen for a reply message.

FIG. 7 is a flowchart illustrating a process for selecting a message for application of a reply action.

FIG. 8 is a flowchart illustrating a process for selecting a message for application of a reply-all or reply to all action.

FIG. 9 is a flowchart illustrating a process for selecting a message for application of a forward action.

FIG. 10 is a flowchart illustrating a process for selecting a draft message for application of a send or edit action.

FIG. 11 is an example of a graphical user interface for displaying a message thread listing including a message thread with a draft message.

FIG. 12 is a flowchart illustrating a process for selecting a message for application of a single-message action.

DETAILED DESCRIPTION

The embodiments described herein provide a communication device, method and system for applying a selected single-message action applicable to a single message, such as a “reply” or “forward” action, to a single message in a message thread without requiring prior user selection of that single message.

There is thus provided a method, implementable at an electronic device, for applying a single-message action to an email message, the method comprising: displaying a listing of message threads; while said listing of message threads is displayed, detecting selection of one of the message threads, said message thread comprising a plurality of email messages and detecting selection of a single-message action to be applied to a single email message, the selected single-message action being associated with at least one message attribute; identifying one of the plurality of email messages comprising said at least one message attribute; and applying the selected single-message action to said identified email message.

In one aspect, identifying the one of the plurality of email messages comprises identifying a most recent one of the plurality of email messages comprising said at least one message attribute.

In another aspect, the at least one message attribute comprises the message being marked opened.

In still another aspect, selection of one of the message threads comprises selection of a graphical user interface element displayed at the electronic device, the graphical user interface element corresponding to said one of the message threads, and said selection of the single-message action is carried out while said graphical user interface element is selected.

In a further aspect, applying the selected single-message action may comprise displaying a message composition interface comprising content from the identified email message.

In still a further aspect, the selected single-message action comprises a reply action, and the at least one message attribute comprises the message being a received message. Alternatively or additionally, the selected single-message action comprises a forward action, and the at least one message attribute comprises the message being a received message; or the selected single-message action comprises a reply to all action, and the at least one message attribute comprises the message being a received message and the message having a plurality of recipients; or the selected single-message action comprises a send action, and the at least one message attribute comprises the message being a draft message having at least one designated recipient; or the selected single-message action comprises a flag action, and the at least one message attribute comprises either the message being a received message, the message having an attachment, or the message both being a received message and having an attachment. In yet another aspect, the identified email message need not be, and is not a most recent message in the selected message thread.

The embodiments herein also provide an electronic device for handling messages and for applying single-message actions to an email message, the electronic device comprising: a display interface; and a processor in communication with the display interface, the processor being configured to: display a listing of message threads via the display interface; while said listing of message threads is displayed, detect selection of one of the message threads, said message thread comprising a plurality of email messages, and detect selection of a single-message action to be applied to a single email message, the selected single-message action being associated with at least one message attribute; identify one of the plurality of email messages comprising said at least one message attribute; and apply the selected single-message action to said identified email message.

In one aspect of the above electronic device, the processor is configured to identify the one of the plurality of email messages by identifying a most recent one of the plurality of email messages comprising said at least one message attribute.

In another aspect, the at least one message attribute comprises the message being marked opened.

In yet another aspect, selection of one of the message threads comprises selection of a graphical user interface element displayed at the electronic device, the graphical user interface element corresponding to said one of the message threads, and said selection of the single-message action is carried out while said graphical user interface element is selected.

In still another aspect, the processor is configured to apply the selected single-message action by displaying via the display interface a message composition interface comprising content from the identified email message.

In yet another aspect, the selected single-message action comprises a reply action, and the at least one message attribute comprises the message being a received message; alternatively or additionally, the selected single-message action comprises a forward action, and the at least one message attribute comprises the message being a received message; or the selected single-message action comprises a reply to all action, and the at least one message attribute comprises the message being a received message and the message having a plurality of recipients; or the at least one message attribute comprises the message being a draft message having at least one designated recipient; or the selected single-message action comprises a flag action, and the at least one message attribute comprises either the message being a received message, the message having an attachment, or the message both being a received message and having an attachment.

In a further aspect, the identified email message need not be, and is not a most recent message in the selected message thread.

There is also provided an electronic device program product comprising an electronic device-readable medium, which may be a non-transitory or physical medium, storing code which, when executed by an electronic device, causes said electronic device to carry out the methods described herein.

These embodiments will be described and illustrated primarily in relation to electronic devices, which include wireless communication devices, communicating over wireless networks and public networks. It will be appreciated by those skilled in the art, however, that this description is not intended to limit the scope of the described embodiments to implementation on these particular systems or to wireless devices. For example, the methods and systems described herein may be applied to any appropriate electronic device adapted to communicate with another electronic or communication device using a direct or network communication interface. The electronic device may be adapted to communicate over a fixed or wireless connection, and may be portable or wirelessly enabled or not, provided with voice communication capabilities or not, and additionally or alternatively may be adapted to process data and carry out operations on data in response to user commands for any number of purposes, including productivity and entertainment. Thus, the embodiments described herein may be implemented on electronic devices adapted for communication or messaging, including without limitation cellular phones, smartphones, wireless organizers, personal digital assistants, desktop computers, terminals, laptops, tablets, handheld wireless communication devices, notebook computers, portable gaming devices, Internet-connected televisions, set-top boxes, digital picture frames, in-vehicle entertainment systems, entertainment devices such as MP3 or video players, and the like. Unless expressly stated, an electronic device may include any such device or any device capable of sending and receiving, or implementing a messaging client for use in sending and receiving, messages to one or more recipients. As contemplated herein, the electronic device may have an integrated display interface, or may comprise a display interface configured to output data to be rendered or painted to an external display unit such as an external monitor or panel, television screen, projector, or virtual retinal display (via a data port or transmitter, such as a Bluetooth® transceiver, USB port, HDMI port, DVI port, and the like). References herein to a “display” or “display interface” are intended to encompass both integrated and external display units as well as data ports and transmitters used to output signals to external display units.

The embodiments herein will also be described and illustrated primarily in relation to email messages, such as those constructed and implemented in accordance with known Internet messaging standards including Internet Message Format RFC 5322 and RFC 2822, published by the Internet Engineering Task Force, as well as their predecessor, successor, and companion standards. However, it will also be appreciated by those skilled in the art that these embodiments are not intended to be exclusive of other message types or applications, and extend to other types and formats of messages, whether text or multimedia-based. Generally these message formats are adaptable to support the creation of “child” messages based on a “parent” message. A non-limiting example of this is the generation of a reply or forward message (the child message) from an earlier message (the parent message). The child message may comprise an express or implied reference to the parent message, for example by including a value in the child message header expressly referring to a message identifier for the parent, or by including in the child message body content at least an excerpt of the message body content of the parent. Each message may thus be expressly or impliedly associated with another specific message. The definition of such reply or forward messages using various identifiers or techniques will be known to those skilled in the art.

The association of individual messages in this manner may be contrasted to those message protocols in which the messages are delivered between senders and recipients in a single session or stream (“conversation”), in which later messages are not associated with a specific earlier message in the stream, but are generally only associated with the stream itself. However, the person skilled in the art will appreciate that any appropriate message format may be employed, provided it is adaptable for use with the embodiments described herein. Examples of other message formats include private messages, SMS (Short Message Service), MMS (Multimedia Messaging Service), VVM (Visual Voicemail) and the like. The message formats to which these embodiments are applicable need not be restricted to those standardized formats. The formatting and transmission of all such messages, storage and indexing of such messages, and the implementation of suitable messaging infrastructures to support such communications, will also be known to those skilled in the art.

These embodiments are also generally described as being implemented in conjunction with messaging client applications that are configured to display messages both individually and collectively in a display of message “threads”, as discussed below. The messaging client need not be limited to a single-purpose or single-message format application; for example, messages may be generated and transmitted using a social networking client application, or a collaborative or groupware client application.

FIG. 1 is a block diagram of an example embodiment of an electronic device 100 that may be used with the embodiments described herein. The electronic device 100 includes a number of components such as a main processor 102 that controls the overall operation of the electronic device 100. It should be understood that the components described in FIG. 1 are optional and that an electronic device used with various embodiments described herein may include or omit components described in relation to FIG. 1.

Communication functions, including data and voice communications, are performed through one or more communication subsystems 104, 105, and/or 122 in communication with the processor 102. Data received by the electronic device 100 can be decompressed and decrypted by decoder 103, operating according to any suitable decompression techniques, and encryption/decryption techniques according to one or more various encryption or compression standards known to persons of skill in the art.

If equipped with a communication subsystem 104, this subsystem 104 receives data from and sends data to wireless network 200. In this embodiment of the electronic device 100, the communication subsystem 104 is configured in accordance with one or more wireless communications standards. New wireless communications standards are still being defined, but it is believed that they will have similarities to the network behaviour described herein, and it will also be understood by persons skilled in the art that the embodiments described herein are intended to use any other suitable standards that are developed in the future. The wireless link connecting the communication subsystem 104 with the wireless network 200 represents one or more different Radio Frequency (RF) channels, operating according to defined protocols specified for the wireless communications standard, and optionally other network communications.

The electronic device 100 may be provided with other communication subsystems, such as a wireless LAN (WLAN) communication subsystem 105 or a short-range and/or near-field communications subsystem 122 also shown in FIG. 1. The WLAN communication subsystem 105 may operate in accordance with a known network protocol such as one or more of the 802.11™ family of standards developed or maintained by IEEE. The communications subsystems 105 and 122 provide for communication between the electronic device 100 and different systems or devices without the use of the wireless network 200, over varying distances that may be less than the distance over which the communication subsystem 104 can communicate with the wireless network 200. The subsystem 122 can include an infrared device and associated circuits and/or other components for short-range or near-field communication.

It should be understood that any of the communication subsystems 104, 105, 122 may optionally be included in the electronic device 100. Alternatively, a communication subsystem comprised in a dongle or other peripheral device (not shown) may be connected to the electronic device 100, either wirelessly or by a fixed connection such as a USB port, to provide the electronic device 100 with access to a network. If provided onboard the electronic device 100, the communication subsystems 104, 105 and 122 may be separate from, or integrated with, each other.

The main processor 102 also interacts with additional subsystems, if present, such as a Random Access Memory (RAM) 106, a flash memory 108, a display 110, other data and memory access interfaces such as an auxiliary input/output (I/O) subsystem 112 or a data port 114, a keyboard 116, a speaker 118, a microphone 120, the communications 104, 105, 122 and other device subsystems 124. The communication device may also be provided with an accelerometer 111, which may be used to detect gravity- or motion-induced forces and their direction. Detection of such forces applied to the electronic device 100 may be processed to determine a response of the electronic device 100, such as an orientation of a graphical user interface displayed on the display assembly 110 in response to a determination of the current orientation of the electronic device 100. The electronic device 100 may be a battery-powered device including a battery interface 132 for receiving one or more rechargeable batteries 130.

In embodiments where a display is integrated with the electronic device, the electronic device 100 may comprise a touchscreen-based device, in which the display interface 110 is a touchscreen interface that provides both a display for communicating information and presenting graphical user interfaces, as well as an input subsystem for detecting user input that may be converted to instructions for execution by the device 100. The touchscreen display interface 110 in such embodiments can be the principal user interface provided on the electronic device 100, although in some embodiments, additional buttons, variously shown in the figures or a trackpad, or other input means may be provided. If a touchscreen display interface 110 is provided, then other user input means such as the keyboard 116 may or may not be present. The controller 216 and/or the processor 102 detects touches by any suitable contact member on the touch-sensitive display 110.

A visualization processor or module 125 is included in the electronic device 100. The visualization module 125 analyzes and processes data for visualization on the display 110. Data originally prepared for visualization on a large-screen display may require additional processing prior to visualization on a small-screen display. This additional processing is accomplished by the visualization module 125. As will be appreciated by those of skill in the art, the visualization module can be implemented in hardware, software, or a combination thereof, and can comprise a dedicated image processor and associated circuitry, or can be implemented within main processor 102.

The electronic device 100 also includes an operating system 134 and software components 136 to 152. The operating system 134 and the software components 136 to 152 that are executed by the main processor 102 are typically stored in a persistent store such as the flash memory 108, which can alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that portions of the operating system 134 and the software components 140 to 152, such as specific device applications, or parts thereof, can be temporarily loaded into a volatile store such as the RAM 106. Select other modules 152 may also be included, such as those described herein. Other software components can also be included, as is well known to those skilled in the art.

A subset of software applications 136 that control basic device operations may be installed on the electronic device 100 during its manufacture. Other software applications include a messaging client 140 that can be any suitable software program that allows a user of the electronic device 100 to send and receive electronic messages. Other types of software applications can also be installed on the electronic device 100, such as feed or content readers 150, web browsers 152, other user agents 154, and other modules 156. These software applications may be supplied by the electronic device manufacturer or operating system provider, or may be third party applications. The additional applications can be loaded onto the electronic device 100 through at least one of the communications subsystems 104, 105, 122, the auxiliary I/O subsystem 112, the data port 114, or any other suitable device subsystem 124. This flexibility in application installation increases the functionality of the electronic device 100 and can provide enhanced on-device functions, communication-related functions, or both.

Various alternatives exist for the messaging client 140 as is well known to those skilled in the art. Messages that have been sent or received by the user using the electronic device 100 are typically stored in the flash memory 108 of the electronic device 100 or some other suitable storage element in the electronic device 100. In at least some embodiments, some of the sent and received messages can be stored remotely from the device 100 such as in a data store of an associated host system with which the electronic device 100 communicates, while header information (e.g., sender and recipient identities, subject line if applicable, message identifier or number, and optionally additional metadata such as message size or message content such as an excerpt of the message body) is provided to the device 100 for display via the messaging client 140. In some embodiments message stores are hosted in a remote location, accessible from the electronic device 100 over a network connection using either the messaging client 140 or another user agent 154, or the web browser 152. The electronic device 100 thus provides a user interface to the message stores and messaging services that are hosted remotely.

In use, a received signal such as message or information about a message will be processed by the receiving communication subsystem 104, 105, 122 and input to the main processor 102. The main processor 102 will then process the received signal for output to the display 110 or alternatively to the auxiliary I/O subsystem 112. A subscriber can also compose data items, such as messages, using the keyboard 116 in conjunction with the display interface 110 and possibly the auxiliary I/O subsystem 112 (or, in the case of a touchscreen electronic device 100, using only the display interface 110). The auxiliary subsystem 112 can include devices such as: a touchscreen, mouse, track ball, infrared fingerprint detector, or a roller wheel with dynamic button pressing capability. The keyboard 116 may be an alphanumeric keyboard and/or telephone-type keypad. However, other types of keyboards can also be used. It will be appreciated that if the display 110 is a touchscreen, then the electronic may still comprise one or more other auxiliary subsystem 112 devices. A composed item can be transmitted over the wireless network 200 or other network connection using an appropriate communication subsystem.

The communication subsystem component 104 may include a receiver, transmitter, and associated components such as one or more embedded or internal antenna elements, Local Oscillators (LOs), and a processing module such as a Digital Signal Processor (DSP) in communication with the transmitter and receiver. The particular design of the communication subsystems 104, 105, 122, or other communication subsystem is dependent upon the communication network 200 with which the electronic device 100 is intended to operate. Thus, it should be understood that the foregoing description serves only as one example.

A single electronic device 100 may be provisioned for a single or for multiple messaging accounts and be configured to employ one or more messaging formats. For example, the user may wish to access multiple services operating over the same or different networks to send and receive messages in different formats, or multiple services providing messages in the same communication format. An example of this is email messages received both at a user account maintained by a host system with which the electronic device 100 is registered and optionally configured to communicate via an encrypted tunnel, and at a user account provided by a third party service provider whose services are available to the general public. Typically, messages associated with different accounts, services and/or formats are stored in distinct data stores, folders or files at the electronic device 100. For example, each message item received or generated at the electronic device 100 in association with a given service (such as email) can be stored as a separate message or data object in a data store associated with the service, retrievable for presentation to the user using a dedicated application executing at the electronic device 100 and associated with that particular message, service, or content format.

In addition, the message objects may be indexed for retrieval on the electronic device 100 either through the dedicated application itself, through a unified search process implemented in the device operating system, or through another application or process for presentation of message listings or content for multiple accounts, services or formats. An example of this latter type of message application is a “unified inbox” or “unified message box” application, which is configured to present to the user a message listing display that can be considered to be a global message or content list. For clarity, as will be appreciated by those skilled in the art, the term “unified inbox”, unless stated otherwise, is intended to be inclusive of an application providing message listings that can include references not only to received messages, but also to messages originating and/or transmitted from the electronic device 100, drafts, and other messages that are not received at the device or stored in received message folder or inbox data store. The unified inbox thus provides a unified view of message information that serves as an entry point for access to individual messaging services or individual messaging applications associated with each of the message types included in the unified inbox. The message or content elements displayed in the unified inbox display may include, in the case of messages such as email, header data such as sender, timestamp, and subject line. In addition, or alternatively, at least a portion of the message body content may also be displayed in the unified inbox. In the case of other message types, such as instant messages, the information displayed may include message body content in place of message header data.

FIG. 2 provides a more detailed illustration of a possible arrangement of message data stores to facilitate grouping of distinct messages in conversations or threads for presentation by the messaging client 140. These data stores may be maintained at the electronic device 100 or at a remote location accessible to the electronic device 100. In the case of a mobile communication device, message data stores are typically maintained at the device itself, although the data stores at the device may represent only a portion of the complete message data stored in association with a given messaging account. Complete data stores may also be maintained at a remote location as noted above. In FIG. 2, the data accessible to the electronic device 100 is provided in a number of distinct data stores, including first and second email stores 210, 220, first and second IM stores 240, 242, an SMS store 244, PIN message (messages addressed using a personal identification number rather than an email address or telephone number) store 246, MMS store 248, and VVM store 250. Messages of various formats may be stored as objects in their corresponding data store. Multiple data stores for a given type of message format, such as the email stores 210, 220 and the IM stores 240, 242 may be associated with different user accounts or different services. Further, messages may be stored in virtual “folders” within a given message store, as illustrated for the email stores 210, 220. The first email store 210 includes two folders, one for “filed” messages 212 and one for “unfiled” messages 214. “Filed” messages are those that the user has chosen to save in a specific subfolder, either at the electronic device 100 or in a remote data store. Allocation of a message to a folder may be determined from a relationship of the message to others in a specified data structure; for example, all messages in an inbox folder may be appended to a single inbox file, and thus considered to be contained in the inbox “folder”, although no subdirectory or folder containing further message objects is maintained. Allocation to a folder may also be made by setting a flag or other attribute value associated with the message; thus, a message is “filed” if a flag or attribute defining a folder is set. The remaining messages in the email store 210 that are not “filed” are thus unfiled messages 214. The second email store 220 includes an inbox folder 222, which may be a default folder specified for all incoming messages received at the electronic device 100 or at an online service or at the host system on behalf of a user account the electronic device 100; a sent folder 226, which may be another default folder specified for all messages sent successfully from the electronic device 100, or sent on behalf of a user account associated with the communication device; an outbox folder 224, another default folder specified for all messages in the process of being transmitted from the electronic device 100; a deleted folder 228 specified for those messages marked for deletion; and other user-defined folders 230. Implementation of message “folders”—whether by means of an explicitly-set flag value, inclusion of a message in a particular file or physical location, and the like, will be understood by those skilled in the art, and all such embodiments are contemplated herein.

The presence of a message in a folder may thus be associated with an attribute of the message; those messages in the inbox folder 222 are messages having the attribute of being a received message, while messages in the outbox folder 224 are messages having the attribute of being in transmission (“transmitting” messages), and messages in the sent folder 226 have the attribute of being sent messages, i.e. messages originating from a message account accessible at the electronic device 100. However, the presence of a message in a folder need not be used to determine whether a message possesses a given attribute. For example, messages need not be stored in the folders defined in FIG. 2, but instead may be stored in association with one or more flags or attribute values defining whether the message is a received, sent, or transmitting message. The message data stores include not only the message data itself (i.e., the message header and the message payload or content), but also ancillary information about the message such as metadata, including select message attributes. Some metadata may be provided within the header of the message. Other metadata such as internal message and thread identifiers (which may be different from message-ID, thread-ID or other message or in-reply-to values inserted into a message header for delivery), flags and timestamps, may be generated at the electronic device 100 and stored in association with the message upon receipt of the message or upon initial storage of the message in a communication device message store, and are not necessarily delivered with the message itself when the message is sent.

Attributes may be set by a message server, electronic device, or sender, such as flags indicating an importance or priority level, flags representing labels or tags assigned to a message (which may be set manually by a recipient or automatically by a communication device upon receipt), and flags or other values representing common message states or attributes such as “read”, “new”, “recent”, “draft”, “transmitting” or “pending”, “draft”, “deleted” and “error”. The meanings of such attributes will be known to those skilled in the art, and as those skilled in the art will appreciate, these attributes are not intended to be limited by a single literal meaning and other terminology may be considered to be synonymous with these attributes. For example, “opened” may be considered to be synonymous with “read” and “unopened” with “unread”. The existence of a flag or attribute associated with a given message may imply that its converse does not apply; for example, if a message is marked “read”, it is not “unread” or “new”, and thus it is not necessary to set a status value or flag indicating that the message “unread” or “new”. Select attributes may transition through a series of values during the life cycle of a message, either in direct response to a user action or automatically in response to external or automated events, without requiring direct user action. For example, when a message is received at the electronic device 100, it may be stored in its corresponding data store 210 . . . 250 with a flag or status value indicating that it is “new”. When the message is accessed and read by the user, the “new” status value is deleted, and a new status value of “read” is stored with the message. This updating of the message status is thus carried out in response to the user\'s actions. As another example, when a message composed at the electronic device 100 is initially transmitted over the network 120 for delivery to a recipient, it may be stored in its corresponding data store 210 . . . 250 with a “transmitting” status value or flag, indicating that the message is in the process of being transmitted from the electronic device 100, but no confirmation of successful transmission has been received. The “transmitting” status may be equivalent to a “pending” status, in that the status of the message is temporary pending a change to a more persistent status. This status may also be referred to as an “outbox” status, as the device\'s queue for outbound messages for transmission may be known as or represented by an outbox folder. Select attributes may be alterable or reversible by the user invoking a direct command to alter the attribute. A message that is originally “new” is changed to have a “read” or “opened” attribute once the user selects that particular message for display or other presentation (such as text-to-speech rendering), but this latter attribute may be altered by the user to “unread” or “unopened” even after it has been rendered for presentation at the electronic device 100.

The various message stores 210 . . . 250, whether they are maintained at the electronic device 100 and/or at a remote location, comprise a set of data sources that may be directly accessed from the electronic device 100 and processed in diverse ways for customized presentation using a client application, such as the aforementioned messaging client 140. The messaging client 140 may directly access the data store, as illustrated in FIG. 2, for example, where the messaging client 140 directly accesses the email store 210. Further, the messaging client 140 may register as a listener for each store 210 . . . 250 of interest, and receive notifications from each store 210 . . . 250 upon a change (such as storage of a new message in the message store or an update to the status of an existing message). This may result in a large number of listeners registered for each message store 210 . . . 250, and requires the messaging client 140 to identify and register with each store of interest.

For convenience, a merged message collection object 270 can be defined to create an aggregate master index of references for any messages stored in one of the message stores 210 . . . 250. An example of such an object is identified in U.S. Pat. No. 7,568,011, issued Jul. 28, 2009, the entirety of which is incorporated herein by reference. Briefly, an instance of a merged message collection class serves as a message aggregating object which registers as a listener with one or more of the various message stores 210 . . . 250 and/or folders within these stores. Each such store and/or folder returns to the merged message collection object 270 an index of references to each of the messages contained in that store and/or folder comprising references to messages stored in the respective message store, as well as other optional metadata such as the message\'s status or timestamp. The merged message collection object 270 aggregates these indices to define an aggregated or merged collection of messages, which is then provided to the messaging client 140 to identify and retrieve message data directly from one of the data stores 210 . . . 250, and to generate message listing displays using techniques known in the art.

One or more filter or search collection objects 272, 274, which are defined with reference to one or more filter criteria to define a filtered collection of messages, may be provided. The filter collection object 272, 274 registers as a listener with the merged message collection object 270, and receives notifications when the aggregated index changes (by addition or removal of a message or a change to a message status). Optionally, the filter collection object 272, 274 may register directly with one or more of the data stores, and receive notification from the data stores when a change is detected. The filter criteria may comprise particular values of specific message attributes or header values. Examples of filter criteria include the “sent” attribute, or a keyword or string that may be contained in the message body content. The filter can operate to either exclude messages having an attribute matching the filter criteria, or to pass through only those messages with attributes matching the filter criteria.

Messages are often presented in a message application in a “conversation” or “threaded” mode, in which messages identified as belonging to a common thread are grouped together and presented in a single entry in a view comprising a listing of message threads. Accessing one of these single entries then invokes a further individual message list view in which the messages identified as belonging to that thread are displayed. Examples of the first message listing view and the further individual message list view are shown in FIGS. 3 and 4 respectively, which are discussed in further detail below. The categorization or grouping of messages may be carried out using a variety of different rules and heuristics. A simple method of categorizing messages as belonging to a single “thread” is to assign all messages containing the same subject line (after excluding prefixes and tokens such as “Re:”, “Fw:”, and other strings denoting that a message is a reply or forward of a previously received message) to one thread. Another method of grouping parent and child (i.e., reply and forward) messages together in a thread is to determine whether messages are linked through an In-Reply-To value included in the message header, since the value would identify at least the immediately previous message in the message thread. Threads defined in this manner or in a similar manner may be referred to as “conversations”, since it is presumed that the messages are linked through common topics, as is typical of oral conversation.

However, the term “thread” is used herein to refer not only to specific groups or subcollections of messages that are determined to be related with each other through common topics or through assignment of a common thread identifier or other common token, but also to groups or subcollections of messages that are determined to be related with each other through other specifically defined common message characteristics or attributes. Messages that include a specific, predefined string of characters in their subject or body (for example, all messages that contain “Banff” in the subject or body) may be determined to belong to a single group or thread, or all messages identifying the same group of addresses or contacts in its header (whether they are identified in a To:, Cc: or From: line) may be determined to belong to a single group or thread. Identification of a thread in these examples may be carried out using a filtered or search collection from one of the filter objects 272, 274, although a search could be executed directly on a given message store, such as the email message store 210, rather than using the aggregated index.

Membership in a thread may be established by defining and storing a thread identifier in association with each message for later retrieval; however, in some embodiments, no express thread identifier may be set, and instead the message threads or groupings are determined by executing a search using a defined keyword or selected attribute on the unthreaded message collection.

Determination of thread membership may be carried out by the messaging client 140 based on the message collection it accesses from the data stores 210 . . . 250, the aggregate index of messages received from the merged message collection object 270, or from a filtered collection obtained from the filter collection object 280. The threading function is thus integrated with the client application. The threading function need not be integrated with the client application, and may instead be carried out by a separate module at the electronic device 100. These options are represented by the conversation or threading manager 280 depicted in FIG. 2. The operation of the threading manager 280 is described in further detail below. The threading manager 280 may directly register with individual message stores 210 . . . 250 to obtain message updates, but may also register with the merged message collection object 270 or the filter collection object 272, 274, and make user of the aggregated index or filtered index to classify messages into threads or other related categories. The threading manager 280 then generates a threaded index of messages derived from the merged index or from the individual message stores, querying the individual message stores 210 . . . 250 as necessary to obtain any message attributes required to determine membership of a given message in a thread. The messaging client 140 would then register with the threading manager to obtain the threaded message index to obtain thread data to display a listing of threads in an inbox or other message listing display. A fuller description of the interoperation of the threading manager 280, the merged collection 270, filter collection objects 272, 274, messaging client 140, and various stores 210 . . . 250 is provided in U.S. patent application Ser. No. 13/025,822 filed on Feb. 11, 2011, the entirety of which is incorporated herein by reference.

FIGS. 3 and 4 provide example results of the processes described above as they may be depicted in a unified message box or unified inbox. The messaging client 140 is configured to generate a view comprising graphical user interface elements for display on the electronic device display 110 representing individual messages and threads of messages. The user may interact with the graphical user interface elements through commands input via one of the input interfaces provided for the electronic device 100 (e.g., the keyboard 116 or a touchscreen display interface, where the display interface 110 comprises a touchscreen) to invoke actions to be applied to a selected message or message thread.

FIG. 3 illustrates a message thread listing view 300 of the messaging client 140. In this example, membership of a message is defined based on a common root subject line (i.e., the subject line of the message, omitting prefixes such as “Re:” and “Fw:”, and the like). Data for the threads represented in the view 300 may be obtained by the messaging client 140 from a threaded indexed received form the threading manager 280 as described above. The thread listing is constructed by the messaging client 140 by traversing the threaded index to identify all messages corresponding to each thread identifier, and to determine message thread attributes for the listing entry such as a thread status (described in detail in the aforementioned U.S. patent application) and thread timestamp based on the individual timestamps and statuses of messages that are identified as members of that thread. A thread\'s timestamp, for example, is typically the latest timestamp associated with any individual message belonging to the thread. The thread\'s status may be derived from a single message\'s attributes (e.g., if the most recently received message in the thread is unread, then the thread\'s status is unread). Alternatively, the messaging client 140 may track message threads and the membership of each message received at or sent from the electronic device 100 in an associated thread.

Once the messaging client 140 has identified the various message threads and their associated attributes, the message threads are collated according to a selected collating criterion. In the example of FIG. 3, the typical collation criterion of thread timestamp is used, and the thread entries 310a . . . 310i are listed in reverse chronological order, as illustrated by the timestamps depicted in FIG. 3. Each thread entry, as illustrated with reference to the first entry 310a, includes an identifier of a last sender and/or recipient in the thread 312a, a root subject line (when available) 312b, and the thread timestamp 312c. For those threads comprising messages that typically do not include a subject line, such as instant messages or SMS messages, the thread entry may instead comprise the most recent message sent or received in the thread, or an excerpt thereof.

The identifier 312a may be the email address or friendly name (as may be stored in an address book at the electronic device 100 in association with the sender/recipient\'s email address) of the sender of the message with the latest timestamp in the thread (in which case the identifier 312a could identify the user of the electronic device 100, since the user may have been the last sender in the thread), of the sender of the most recent message in the thread that was sent by a party other than the user of the electronic device 100, or of the sender and all recipients of messages in the thread, which may or may not exclude the user of the electronic device 100. In the example of FIG. 3, the identifier 312a references the sender of the most recent message in the thread that was not sent by the communication device user. Thus, the thread entry 310a in this embodiment indicates at a glance what other participant had last contributed a message to the thread, but does not indicate to the user who the recipients of that message other than the user him- or herself may have been.

This example illustrates that detailed information relevant to the state of the message thread is sometimes omitted due to design choice, space constraints in the view 300, and/or the size of the display interface 110. In order to determine who the individual recipients or other senders of messages in a thread may have been, a further view must be generated by the messaging client 140 to list the individual messages of the thread. In addition, it will be appreciated that certain actions that are generally applied to a single message—such as opening an individual message for reading, replying to a message, forwarding a message, flagging or deleting a message, and so forth—require that a specific message be identified for that action. The listing of message threads in FIG. 3 efficiently displays consolidated information for a number of messages by displaying thread entries, but because the only entries listed are for message threads, a single message contained within a thread consisting of multiple messages cannot be expressly selected by the user using the view 300.

Accordingly, one solution is to display a further individual message view in response to the selection of a particular message thread in the view 300. An example of such a further individual message view is illustrated in FIG. 4, which shows an individual message view 400 invoked upon selection of the first thread entry 310a in FIG. 3. This new message view 400 shows that there are three messages in the thread 410a, 410b, 410c. In this example, the information displayed for each message entry in the view identifies the sender and recipient of the message, along with an excerpt from the message body content. From this view the user can select an individual message in order to carry out a single-message action, such as opening the selected message to read it, deleting the selected message, replying to the selected message, and so forth. A “single-message” action, in this context, is a message processing or handling action that is typically applied to a single identified message, whether that message is contained within a message thread or not. For example, the third message displayed 410a may be selected using input means provided at the electronic device 100—as represented by the highlight box 420—and a context menu 430 invoked, from which one of a number of possible actions such as “open” (to display the message for viewing), “reply”, “forward”, and so forth can be selected. Once selection of an action is detected, that action is applied to the specific selected message.

The display of the further individual message view 400 adds an extra step to the process of applying an action to a selected individual message. Thus, while the threaded view 300 showing the listing of message threads provides efficiencies in display, that efficiency is reduced since the messaging client 140 must listen for a further input command (to select the thread 310a) and retrieve message data from the appropriate message stores to render the further message view 400 before a command can be received to apply a single-message action to a selected message in the thread. This results in a possible increase in processing overhead, since additional memory reads are required to retrieve the message information required for the further individual message view 400, and since the electronic device 100 must be configured to detect both the selection of a message thread as well as selection of a message with the thread, in addition to selection of an action to be applied to the message.

To address this inefficiency, the messaging client 140 can be configured to automatically and intelligently identify a specific message in a message thread when a selection of a single-message action is detected, and to apply the selected single-message action to the identified message without requiring the intermediate display of the further individual message view 400. The message that is identified may vary according to the type of single-message action selected, even if the different actions are to be applied to a message in the same thread.

An example of this solution is illustrated in FIGS. 5 and 6. FIG. 5 illustrates a similar view 500 to that shown in FIG. 3. The view 500 comprises a listing of message threads, just as in FIG. 3. When a given message thread entry (such as the thread entry 310a) is selected (as indicated by highlight box 520) and a command to invoke an action applicable to a single message is detected by the electronic device 100, rather than merely displaying a view listing the individual messages in the selected message thread, one of the individual messages in the thread is automatically selected by the messaging client 140 for application of the single-message action. In the example of FIGS. 5 and 6, the “reply” action is selected (i.e., a command is received by the electronic device 100 to create a new message for transmission from the electronic device 100 as a response to an existing message).

The next view displayed by the messaging client 140 is therefore a view such as the message composition view 600 of FIG. 6, rather than a list of individual messages in the thread as in FIG. 4. As is conventional in the art, the message composition view 600 includes an address field 610 in which addresses or names of addressees may be input; a subject line field 620, and a message body input field 630, where message content can be entered by the user. Since the selected action was “reply”, the address field 610 is automatically populated with the address and/or name of the sender of a particular message in the thread. Also, since the example of FIGS. 5 and 6 is of an email thread and reply, the subject line field 620 is populated with the root subject line of the thread, in this case preceded by a token indicating that the message being generated is a reply to an earlier message in the thread. Further, because the message thread in this example is an email thread, the message body further comprises an automatically-inserted quoted copy of the message 635 for which the new reply message is being generated; this quoted copy 635 is the message in the thread automatically selected by the messaging client 140. It will be appreciated, though, that while conventionally in email correspondence the messaging client 140 typically inserts a copy of the message to which a reply is being composed, the addition of the quoted copy 635 is not necessary. In some embodiments, for example, the quoted copy 635 is not inserted at the electronic device 100, but rather by the messaging server associated with the device 100 once the message is transmitted from the device 100 to the messaging server for routing to the recipient(s).

The process of selecting an individual thread entry from the message thread listing view 500 will be illustrated with reference to FIG. 7. At 700, a message thread listing is displayed, for example in the message thread listing view 500 of FIG. 5. At 710, selection of a single thread entry listed in the message thread listing is detected. Once a message thread has been selected in this manner, at 720 selection of a single-message action is detected. In this example, the single-message action is a reply action. A reply command, as those skilled in the art appreciate, typically comprises invocation of a message composition screen, for composing a message, but the message body field of the composition screen is automatically populated with content from a single message that is selected as the parent of the reply or forward message. The reply message action is thus considered to be a “single-message” action. The selection of the single-message action can take place while the single thread entry remains selected, and more specifically, before any single message in the message thread is selected or otherwise identified.

The selected single-message action is associated with one or more message attributes. In FIG. 7, the one or more message attributes consists of the message being a received message, rather than a sent message. At 730, message attributes for the messages in the selected message thread are retrieved, for example from the corresponding message store or stores. This step may be carried out in the sequence illustrated in FIG. 7, although it may have been carried out prior to detection of the reply action selection 720. At 740, a message having message attributes matching the one or more message attributes is identified. There may be more than one message having matching attributes, in which case the most recent message in the message thread (i.e., the message with the most recent timestamp) having those matching attributes is identified. The identification of the most recent message may be explicitly determined by comparing timestamps of messages with matching attributes in the thread or by evaluating the messages of the thread in a chronological or reverse chronological order. The selected action is then applied at 750 to the message identified at block 740.

A further example of this process with multiple message attributes is illustrated with reference to the set of representative messages set out in Table 1 below:

TABLE 1 # Attribute Sender Recipient Timestamp Body In Reply To 1 Read Reffelle Violet 11:50 It\'s painful trying to keep n/a (received) up with your . . . 2 Sent Violet Reffelle 11:51 I\'m just responding to 1 what you\'re sending . . . 3 Unread Reffelle Violet 11:53 Nice try. You get bored 2 (received) and cleave the thread . . .

Table 1 sets out message data (both metadata and content, i.e., body excerpt) for the messages in the thread represented by the thread entry 310a of FIG. 5. These individual messages are also listed in the individual message listing view 400 of FIG. 4. As can be seen by the various status icons in FIG. 4 and in the table above, the three messages in the thread have different attributes, such as different statuses: the first message 410b (message 1 in the above table), which is the first one received in the thread at the electronic device 100, has been marked read, i.e. has been opened for viewing on a display, although not necessarily literally read or otherwise consumed by the user. Message also has the attribute of being a received message, i.e., it was received at an account associated with a user of the electronic device 100 (in Table 1, the recipient “Violet” is a name associated with a user of the electronic device 100 or the account at which the message was received). The second message (410b, or message 2 in the above table) was sent by the user and thus has the attribute of a sent message. The third message (410c, or message 3) is a received message but marked unread (i.e., either never opened for viewing on the display, or previously opened but subsequently marked unread).

Referring to FIG. 5 and the process of FIG. 7 again, at 700 a message thread listing is displayed and. at 710 selection of a single thread entry listed in the message thread listing is detected. In a view such as the view 500 of FIG. 5, the various thread entries are selectable through a user interface. In the case of a touchscreen electronic device 100 an individual entry can be selectable by a touch detected on the surface of the display interface 110 corresponding to the area in which the individual thread entry is displayed (i.e., a graphical user interface element corresponding to that thread entry). Other input means that may be available at the electronic device such as an external or integrated keyboard, trackball, or optical joystick, etc., not shown in FIG. 5, can also be used to select a single message thread in the view 500.

Next, at 720, selection of the single-message action—again, a reply action—is detected. This selection can take place while the graphical user interface element corresponding to the message thread continues to be displayed as “selected” in the message thread listing view 500, as indicated by the highlight box 520 in FIG. 5. The command to invoke the single-message action can be input at and detected by the electronic device 100 by a variety of means. As illustrated in FIG. 5, for example, graphical user interface elements, such as buttons 512, 514, 516, 518 can be displayed overlaying the view 500 (in this example, in an overlay 510). Actuation of one of these elements 512, 514, 516, 518, for example by touch (via a touchscreen interface) or clicking or other selection actions (via other input mechanisms at the electronic device 100) results in invocation of the corresponding action. In FIG. 5, element 512 represents a compose message command; element 514 a reply command; element 516 a forward command; and 518 a flag command. Other means may be used to invoke the single-message action. For example, an input received via keyboard (such as actuation of a lower-case “r” key for “reply”), or selection of a reply command in a context menu (not shown in FIG. 5) may be used.

Again, the selected single-message action is associated with one or more message attributes, but in this example the one or more message attributes are that the message is a received message and that the message has been marked open or read. Again at 730, message attributes for the messages in the selected message thread are retrieved, and at 740 a message having message attributes matching the one or more message attributes is identified (although in this example the attributes include the message being marked read). As can be seen from Table 1, both messages 1 and 3 are messages that were sent by a user other than a user of the electronic device 100, and are considered to be “received” messages, but only the message 1 is both received and marked read or open. Thus in this case only message 1 meets the message attributes, so it is the most recent message matching those attributes. Had more than one message met the specified message attributes—for example, had message 3 also been marked read—then a determination is also made at 740 which of those messages is the most recent in the thread, since typically the user would wish to apply an action to a more recent message in the thread.

Next, at 750, the selected action is applied to the message identified at 740. The result in this reply example is the invocation of a compose reply message view such as that shown in FIG. 6 and described above. As a result, a fourth message is added to the thread, as shown in Table 2 below. The fourth message, as indicated by the “In Reply To” column, is generated in reply to message 1 rather than message 3 since message 1 was the most recent message in the thread that possessed the attributes associated with the reply action.

TABLE 2 # Attribute Sender Recipient Timestamp Body In Reply To 1 Read Reffelle Violet 11:50 It\'s painful trying to keep n/a (received) up with your . . . 2 Sent Violet Reffelle 11:51 I\'m just responding to 1 what you\'re sending . . . 3

Download full PDF for full patent description/claims.




You can also Monitor Keywords and Search for tracking patents relating to this Electronic device and method for selectively applying message actions patent application.
###


Other recent patent applications listed under the agent Research In Motion Limited: