(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2008/0301250 A1
`Hardy et al.
`(43) Pub. Date:
`Dec. 4, 2008
`
`US 200803 01250A1
`
`(54) THREAD-BASED MESSAGE
`PRIORITIZATION
`
`(76) Inventors:
`
`Michael Thomas Hardy, Waterloo
`(CA); Piotr Konrad Tysowski,
`Waterloo (CA); Atif Khan,
`Waterloo (CA)
`
`Correspondence Address:
`SMARTAND BIGGAR
`438 UNIVERSITY AVENUE, SUITE 1500 BOX
`111
`TORONTO, ON M5G2K8 (CA)
`
`(21) Appl. No.:
`
`11/754,542
`
`(22) Filed:
`
`May 29, 2007
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06F 5/16
`(52) U.S. Cl. ........................................................ T09/207
`(57)
`ABSTRACT
`To perform thread-based message prioritization, metadata
`may be extracted from a received electronic message. Based
`on the extracted message metadata and accumulated meta
`data extracted from previously received messages, a message
`thread to which the received electronic message belongs may
`be identified. Based on a set of thread priority assessment
`criteria, a priority level for the message thread may be deter
`mined. At least part of the message thread may be processed
`according to the priority level. The processing may be altering
`a notification behavior of an electronic messaging client for
`electronic messages of the message thread. Thread priority
`assessment may be based on user-configurable criteria that
`may be set via a graphical user interface. Message thread
`identification may also be based on user-configurable criteria
`that may be set via a graphical user interface.
`
`NeW
`Message
`210
`
`Extract
`metadata
`S212
`
`Extracted
`Message Data
`214
`
`
`
`
`
`
`
`Identify
`message thread
`S218
`
`
`
`Accumulated Metadata
`from Previously Received
`Messages
`216
`D Thread
`Identification
`Criteria
`219
`
`-200
`
`Thread Priority
`ASSeSSment
`Criteria
`224
`
`
`
`Determine
`thread priority
`S226
`
`Thread
`Priority
`228
`
`Identified
`Thread
`220
`
`Identified
`Thread
`220
`
`
`
`Process at
`least part of message
`thread according to its
`priority
`S230
`
`
`
`
`
`Prioritized
`Message Thread
`232
`
`Facebook's Exhibit No. 1015 - Page 1
`
`

`

`Patent Application Publication
`
`Dec. 4, 2008 Sheet 1 of 7
`
`US 2008/030.1250 A1
`
`
`
`Facebook's Exhibit No. 1015 - Page 2
`
`

`

`Patent Application Publication
`
`Dec. 4, 2008 Sheet 2 of 7
`
`US 2008/030.1250 A1
`
`onzº
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Facebook's Exhibit No. 1015 - Page 3
`
`

`

`Patent Application Publication
`
`Dec. 4, 2008 Sheet 3 of 7
`
`US 2008/030.1250 A1
`
`
`
`
`
`808
`
`Facebook's Exhibit No. 1015 - Page 4
`
`

`

`Patent Application Publication
`
`Dec. 4, 2008 Sheet 4 of 7
`
`US 2008/030.1250 A1
`
`ELT?Efzev ºº”
`!?.
`
`
`
`{{#7 “OICH
`
`
`
`Facebook's Exhibit No. 1015 - Page 5
`
`

`

`Patent Application Publication
`
`Dec. 4, 2008 Sheet 5 of 7
`
`US 2008/030.1250 A1
`
`88 #7
`
`
`
`fiu??SOd
`
`Facebook's Exhibit No. 1015 - Page 6
`
`

`

`Patent Application Publication
`
`Dec. 4, 2008 Sheet 6 of 7
`
`US 2008/030.1250 A1
`
`
`
`E. E. E.
`
`Y O
`
`N
`d
`
`<
`l
`C.
`m
`s
`
`Facebook's Exhibit No. 1015 - Page 7
`
`

`

`Patent Application Publication
`
`Dec. 4, 2008 Sheet 7 of 7
`
`US 2008/030.1250 A1
`
`
`
`s
`
`Facebook's Exhibit No. 1015 - Page 8
`
`

`

`US 2008/030 1 250 A1
`
`Dec. 4, 2008
`
`THREAD-BASED MESSAGE
`PRIORITIZATION
`
`FIELD OF TECHNOLOGY
`0001. The present disclosure pertains to electronic mes
`sages such as electronic mail (email) messages, short mes
`sage service (SMS) messages, multimedia message service
`(MMS) messages, or peer-to-peer messages and more par
`ticularly to the thread-based prioritization of such messages.
`
`BACKGROUND
`0002 The practice of defining rules or “filters' that are
`automatically applied by an email client or server in order to
`determine the priority of a received email message is known.
`Typically, filter criteria are based on information extracted
`from the received email message. Such as: the identity of the
`message sender, the identity of one or more message recipi
`ents; the content of Subject line of the message; the email
`importance flag setting; or combinations of these. When a
`received email message meets specified filter criteria, the
`email client or server automatically assigns a high priority (or
`a low priority, depending upon the filter settings) to the mes
`sage. The notification behavior of the email client in respect
`of the message may be altered from a standard notification
`behavior in order to reflect this priority. For example, the
`appearance of the received message in a message list may be
`changed, e.g. by using bold, differently colored, or differently
`sized text than is ordinarily used to represent the message, or
`by applying different audio or vibration notifications depend
`ing upon message priority. For messages that do not meet the
`specified criteria, a standard priority may be assigned to the
`message, and Standard notification may be performed.
`0003. Unfortunately, when the above practice is adopted, a
`message may disadvantageously be treated as a standard pri
`ority message even if contextual factors beyond the message
`itself. Such as the high priority of a previous message to which
`the message is a response, Suggest that the message should
`actually be treated as a high priority message. This may result
`in a mistaken user perception that an email message is unim
`portant when it is not. Conversely, it is also possible for a
`message to be treated as a high priority message when con
`ventional factors suggest it should actually be treated as a
`standard or low priority message. Generally, the priority that
`is assigned to a message may not truly reflect its actual pri
`ority. This problem may also occur for other types of elec
`tronic messages, including SMS messages, MMS messages
`or others. A solution which mitigates or obviates this problem
`would be desirable.
`
`BRIEF DESCRIPTION OF DRAWINGS
`0004. In the figures which illustrate example embodi
`ments:
`0005 FIG. 1 is a schematic diagram of an exemplary email
`system;
`0006 FIG. 2 is a data flow diagram illustrating operation
`of a component of the system of FIG. 1;
`0007 FIG. 3 illustrates a graphical user interface used to
`configure message thread identification criteria within the
`system of FIG. 1;
`0008 FIGS. 4A-4C illustrate a graphical user interface
`used to configure thread priority assessment criteria within
`the system of FIG. 1; and
`
`0009 FIGS. 5A-5D schematically illustrate notification
`behavior for a message list which may result from the opera
`tion of FIG. 2.
`
`DETAILED DESCRIPTION
`
`0010. In one aspect of the below described embodiment,
`there is provided a computer-implemented method compris
`ing: receiving an electronic message; extracting metadata
`from the received electronic message, the extracting resulting
`in extracted message metadata; based on the extracted mes
`sage metadata and accumulated metadata extracted from pre
`viously received messages, identifying a message thread to
`which the received electronic message belongs; based on the
`identified message thread, determining a priority level for the
`message thread; and processing at least part of the message
`thread according to the priority level.
`0011. In another aspect of the below described embodi
`ment, there is provided a computer-implemented method
`comprising: displaying a graphical user interface for config
`uring message thread identification criteria, the criteria for
`use in conjunction with metadata extracted from a received
`electronic message and accumulated metadata extracted from
`previously received electronic messages for identifying a
`message thread to which the received electronic message
`belongs.
`0012. In another aspect of the below described embodi
`ment, there is provided a computer-implemented method
`comprising: displaying a graphical user interface for config
`uring message thread priority assessment criteria, the criteria
`for use in conjunction with information regarding a message
`thread comprised of a plurality of electronic messages for
`determining a priority level of the message thread.
`0013. In another aspect of the below described embodi
`ment, there is provided a machine-readable medium contain
`ing executable instructions that, when executed by a proces
`sor in a computing device, cause the computing device to:
`extract metadata from a received electronic message, the
`extracting resulting in extracted message metadata; based on
`the extracted message metadata and accumulated metadata
`extracted from previously received messages, identify a mes
`sage thread to which the received electronic message belongs;
`based on the identified message thread, determine a priority
`level for the message thread; and process at least part of the
`message thread according to the priority level.
`0014. In another aspect of the below described embodi
`ment, there is provided a machine-readable medium contain
`ing executable instructions that, when executed by a proces
`sor in a computing device, cause the computing device to
`display a graphical user interface for configuring message
`thread identification criteria, the criteria for use in conjunc
`tion with metadata extracted from a received electronic mes
`sage and accumulated metadata extracted from previously
`received electronic messages for identifying a message thread
`to which the received electronic message belongs.
`0015. In another aspect of the below described embodi
`ment, there is provided a machine-readable medium contain
`ing executable instructions that, when executed by a proces
`sor in a computing device, cause the computing device to
`display a graphical user interface for configuring message
`thread priority assessment criteria, the criteria for use in con
`junction with information regarding a message thread com
`prised of a plurality of electronic messages for determining a
`priority level of the message thread.
`
`Facebook's Exhibit No. 1015 - Page 9
`
`

`

`US 2008/030 1 250 A1
`
`Dec. 4, 2008
`
`0016 Referring to FIG. 1, an exemplary email system 10
`that allows a user 12 to access email messages from a desktop
`computer 14 or a wireless communication device 16 is shown.
`The system 10 includes an email server 18 and a middleware
`server 20 which are interconnected to each other and to com
`puter 14 by way of a local area network (LAN) 22. The system
`10 also includes the public Internet 24, a wide area network
`(WAN) 26, and a wireless network 28.
`0017 Computer 14 is a conventional network-enabled
`computer, such as a Intel(R) or AMDTM processor-based desk
`top personal computer or laptop computer having a display,
`Such as a liquid crystal display, which communicates with
`email server 18 over LAN 22. The computer 14 executes an
`email client software application 15 ("email client 15') which
`is stored in memory of the computer 14 (not expressly illus
`trated) and which permits the user 12 to access and monitor
`his email account maintained at email server 18. The email
`client 15 may be a dedicated email client, such as the com
`mercially available EudoraTM application, or a component of
`an overall personal information management (PIM) software
`application, such as Microsoft(R) OutlookR) for example.
`Many other examples of email clients are known in the art.
`The email client 15 comprises executable instructions and
`may be loaded from a machine-readable medium 13 (e.g. an
`optical disk or magnetic storage medium) into Volatile or
`non-volatile memory of computer 14 prior to its execution by
`computer 14.
`0018 Wireless communication device 16 is a two-way
`paging device (a form of computing device) having a proces
`sor in communication with memory storing a mobile email
`client software application (or simply “mobile email client')
`17. Mobile email client 17 is a computer program that permits
`a user 12 to access and monitor the email account maintained
`at email server 18, which is the same account that is accessible
`by way of email client 15 at computer 14. Device 16 has an
`input device (a keyboard), an output device (a liquid crystal
`display), and a speaker (not expressly shown), along with
`various other conventional components. The email client 17
`may be downloaded from a machine-readable medium (not
`expressly shown) to the wireless communication device 16
`via wireless network 28 by way of an over-the-air download.
`0.019
`Email server 18 is a conventional email server
`capable of maintaining an email account for user 12 and other
`users. Email server 18 may be a dedicated email server or may
`be a server which provides email capability as part of a
`collaboration software package. Such as Microsoft(R)
`Exchange Server, Novell(R) Groupwise(R) or Lotus(R) Notes for
`example. Email messages destined for user 12 are received at
`email server 18 and are then forwarded to computer 14 and
`wireless communication device 16 for access by the user 12.
`The software which governs the operation of email server 18
`may be loaded from a machine-readable medium 19 into
`volatile or non-volatile memory of server 18 for execution by
`a processor of server 18.
`0020 Middleware server 20 supports the automatic deliv
`ery of email messages destined for user 12 to wireless com
`munication device 16 by way of the “push” content delivery
`model. In essence, the role of middleware server 20 is to
`monitor the email account of user 12 for new messages and,
`upon the detection of a new message at the server 20, to
`forward that message to wireless communication device 16
`by way of the Internet 24, WAN 26, and wireless network 28.
`Middleware server 20 may be required to encrypt and com
`press messages and perform various other tasks to fulfill this
`
`role. These tasks are well understood in the art and are not a
`focus of the present description. The types of messages for
`warded to device 16 by middleware server 20 may include
`messages other than email messages, such as instant mes
`sages for example. The Software which governs the operation
`of middleware server 20 may be loaded from a machine
`readable medium 21 into volatile or non-volatile memory of
`middleware server 21 for execution by a processor of server
`20.
`0021 Wide area network 26 hosts a relay 30 whose pur
`pose is to store messages destined for user 12 while wireless
`communication device 16 is inaccessible (e.g. powered down
`or out of communication range of wireless network 28) and to
`“push’ the email messages to the device 16 once has become
`accessible. Relay 30 maintains information regarding a cur
`rent network 28 with which the device 16 is communicating
`for this purpose. The identity of the network 28 may change
`over time as the wireless communication device 16 moves
`between geographical areas.
`0022 Wireless network 28 is a mobile data communica
`tion network, such as the MobitexTM, DataTACTM or General
`Packet Radio Service (GPRS) network, which supports data
`communication between the relay 30 and the wireless com
`munication device 16. Wireless network 28 may be designed
`to operate with any of a variety of voice communication
`networks, such as Advanced Mobile Phone Service (AMPS),
`Time Division Multiple Access (TDMA), Code Division
`Multiple Access (CDMA), Personal Communication Ser
`vices (PCS), Global System for Mobile communication
`(GSM), third generation (3G) wireless or Universal Mobile
`Telecommunications Standard (UMTS) for example, to sup
`port Voice communications at the wireless communication
`device 16. The wireless network 28 effects a wireless con
`nection between email server 18 and wireless communication
`device 16. The wireless network 28 could alternatively be an
`IEEE 802.11 compliant (“WiFi") wireless network.
`0023 Operation of the present embodiment is illustrated
`in FIG.2. A data flow diagram 200 illustrates the thread-based
`message prioritization approach that is effected at each of
`email client 15 and email client 17 (generically referred to as
`the “email client'). However, as will become apparent, the
`approach may alternatively be effected in various other com
`ponents of the system 10, such as email server 18 or middle
`ware server 20 for example, in alternative embodiments.
`0024. Initially, when a new message 210 is received, cer
`tain metadata is extracted (S212) from the message. The
`extracted message metadata 214 may include, for example,
`the time at which the message was sent, the time at which the
`message was received, the Subject line of the message, the
`body of the message, the identity of the sender of the message,
`the identity of all recipients of the message (possibly includ
`ing distribution lists comprising multiple addresses), and an
`identifier of a previous email message in response to which
`the new message 210 was sent. The precise metadata that is
`extracted may depend, at least in part, on the currently opera
`tive thread identification criteria 219 and thread priority
`assessment criteria 228 (both described below). For example,
`if an operative thread identification criterion requires a Sub
`ject line of a newly received message to be compared with a
`Subject line of previously received messages in order to deter
`mine whether the new message is responsive to any of the
`previously received messages, then the extracted metadata
`
`Facebook's Exhibit No. 1015 - Page 10
`
`

`

`US 2008/030 1 250 A1
`
`Dec. 4, 2008
`
`214 may include subject line content. Extraction of the meta
`data may be achieved through parsing of the message for
`example.
`0025. Thereafter, the extracted message metadata 214 is
`used in combination with accumulated metadata 216 from
`previously received messages to identify a message thread
`(S218) to which the new message 210 belongs. For clarity, the
`term “message thread” refers to an original message and a set
`of responses to the original message, as well as any responses
`to those responses, any third-order responses, and so forth.
`The original message may be considered to be a root node of
`a tree; each response to that original message may be consid
`ered to be a child of that root node; each response to a
`response may be considered to be a grandchild of the root
`node; and so forth. Using this convention, any descendent
`node of the root node (i.e. any response message that is
`“traceable' to the original message) is considered to be part of
`the message thread. Thus, identifying the message thread
`involves determining that the received electronic message is
`responsive to a previously received message of the message
`thread, be it an original message or otherwise. A response is
`typically generated by pressing a “reply' button in an email
`client. The previously accumulated message metadata 216
`may be an amalgamation of metadata previously extracted
`from earlier messages as the messages were received. The
`accumulated metadata 216 may be maintained in a conven
`tional database to facilitate searching with a database engine,
`using a query language such as SQL for example, or in some
`other type of data store.
`0026. Thread identification (S218) involves determining
`whether or not new message 210 is a response to an original
`message of the thread or another message of the thread, as
`described above. As will be appreciated, the purpose of iden
`tifying the message thread is so that the priority of the
`received message may be assessed not in isolation, but in the
`context of its message thread. That is, the determination of
`message priority will not be based exclusively on the message
`itself, but will also be based on the priority of the thread to
`which it belongs.
`0027. Because the determination of whether or not a mes
`sage constitutes a “response to an earlier message could be
`performed in various ways, the present embodiment employs
`a configurable set of thread identification criteria 219 which
`governs this determination and thus controls thread identifi
`cation. These thread identification criteria 219 may be con
`figured by user 12 via a graphical user interface (GUI) 300
`shown in FIG. 3. In the present embodiment, GUI 300 is
`presented to the user by the component of system 10 which
`applies the criteria 219 (e.g. by email client 15 or at computer
`14 or email client 17 of FIG. 1).
`0028. As illustrated in FIG. 3, GUI 300 contains four
`individually selectable checkboxes 302, 304, 306 and 308.
`Each checkbox represents a single thread identification crite
`rion which may be selected by the user 12 individually or in
`conjunction with one or more other thread identification cri
`teria.
`0029 Selection of the first checkbox 302 of FIG. 3 con
`figures the email client to use Subject line content to identify
`message threads. The exact manner in which Subject line
`content is used to identify message threads may vary from
`embodiment to embodiment. For example, if the subject line
`of an earlier message reads 'status report', then one embodi
`ment may deem any Subsequent messages whose Subject line
`includes that text in its subject line (e.g. “re: status report” or
`
`“fwd: status report') to be responsive to the earlier message.
`Another embodiment may deem any Subsequent messages
`whose Subject line includes a portion of that text, a variation
`of that text or a misspelling of that text (e.g. “re: report”, “fwd:
`status rpt., or “my views on the stattus repor”) to also be
`responsive to the earlier message.
`0030 Selection of the second checkbox 304 of FIG. 3
`configures the email client to use message content to identify
`message threads. For example, messages that echo at least a
`portion of a body of an earlier message may be deemed
`responsive to the earlier message. Each line of the echoed
`message body may be identifiable by a preceding ">" char
`acter, although this is neither required nor always true. Again,
`the exact manner in which message content is used to identify
`message threads may vary from embodiment to embodiment.
`For example, the minimum number of characters of the mes
`sage body of the earlier message that must be copied for the
`latter message to be deemed responsive thereto may differ
`from embodiment to embodiment or may be user-config
`urable.
`0031. Selection of the third checkbox 306 of FIG. 3 con
`figures the email client to use duration between messages to
`identify message threads. This particular thread identification
`criterion may not be preferred for use in messaging systems in
`which the amount of time between messages of a single
`thread can be significant (e.g. on the order of days or weeks),
`as is often the case for, say, email messages. Rather, this
`criterion may be desirable for use in messaging systems. Such
`as instant messaging Systems or other presence-based mes
`saging systems, wherein the messages of a thread are typi
`cally chronologically clustered in a “burst', with each mes
`sage of the thread being sent within a relatively short duration
`D1 (e.g. on the order of minutes) of an earlier message of that
`thread. User selection of this criterion through checking of
`checkbox 306 may be partly motivated by the fact that other,
`perhaps more reliable thread identification criteria are
`unavailable for the message system of the embodiment in
`question. For example, since instant messages have no Sub
`ject lines per se and do not routinely echo the body of a
`previous message to which the message is a response, the
`selection of checkboxes 302 and 304 may not be possible in
`an instant messaging system embodiment (e.g. those check
`boxes may simply not be present in GUI 300 or may be
`“greyed out' or “ghosted in such embodiments).
`0032. By selecting checkbox 306, the user stipulates that
`receipt of a message within a relatively short duration D1 (e.g.
`20 minutes) of an earlier message indicates that the latter
`message is responsive to the earlier message. Duration D1 is
`configurable by the user via edit box 307 in the exemplary
`GUI300 of FIG.3. It is noted that the user may be required to
`accept the occasional unreliability of this criterion, in the
`sense that messages may sometimes be included in a thread
`that should not be included, and vice-versa. This is due to the
`fact that temporal proximity of messages is not always an
`accurate indicator of thread membership. It may be sufficient
`for the purposes of the user that the thread identification be
`“usually correct’. This criterion could be paired with other
`thread identification criteria, such as recipient identity (not
`expressly illustrated in FIG.3). For example, when a message
`is received from person Aless than duration D1 from the time
`at which an earlier message was received from person A, both
`messages could be deemed to be part of the same thread.
`0033 Selection of the fourth checkbox 308 of FIG. 3
`configures the email client to use unique message identifiers
`
`Facebook's Exhibit No. 1015 - Page 11
`
`

`

`US 2008/030 1 250 A1
`
`Dec. 4, 2008
`
`associated with messages to identify message threads. For
`example, in one embodiment, email client 17 may be the
`system component that applies the thread identification cri
`teria that are set by way of graphical user interface 300. By
`conventional operational of the middleware server 20 of this
`"push’ email system, each email message passed to wireless
`communication device 16 may be assigned a unique identifier
`by the middleware server 20. This unique identifier is not
`necessarily visible to the user, but rather may be packaged
`within header information associated with the message. If the
`email message is responsive to an earlier message, the mes
`sage header may additionally contain a unique identifier of
`the earlier message. In Such an embodiment, selection of the
`fourth checkbox 308 configures email client 17 to examine
`the header of each incoming message for Such references to
`earlier unique message IDs, and to use this as a basis for
`identifying message threads. In other embodiments, unique
`message identifiers may be differently assigned or packaged
`but may nevertheless be usable for this purpose.
`0034. By changing the configurable thread identification
`criteria 219 via GUI 300, the user 12 may configure the
`system 10 to identify threads in various ways depending upon
`the requirements of the user 12 at that time. This may even be
`done while the email system 10 is executing, such that the
`grouping of existing messages in one's "inbox” into threads
`(or exclusion from threads) may dynamically change by Vir
`tue of updated thread identification criteria 219. When mul
`tiple thread identification criteria are selected, the user may be
`able to configure whether the multiple criteria are logically
`conjunctive (i.e. each operative criterion must be met for a
`thread to be identified), disjunctive (i.e. meeting any opera
`tive criterion is sufficient for a thread to be identified), or a
`combination. Alternatively, the conjunctive or disjunctive
`relationship between criteria may be “hard-coded”. In some
`embodiments, each criterion could even be assigned a differ
`ent weight, for greater precision. Alternatively, the criteria
`219 may not be user-configurable in some embodiments.
`Moreover, Some embodiments may employ criteria which are
`not expressly illustrated in the GUI 300 of FIG. 3.
`0035. Once the message thread has been identified in
`S218, information regarding the identified thread 220 is used,
`along with a set of thread priority assessment criteria 224, to
`determine (S226, FIG. 2) a thread priority 228, i.e. a priority
`level for the thread generally. Thread priority assessment
`criteria 224 are the criteria by which the priority of a thread is
`determined by the email client (or more generically, by the
`system component that applies them). In the present embodi
`ment, these criteria 224 too are configurable, by way of a GUI
`400, which is illustrated in FIGS. 4A-4C. The GUI 400 may
`be displayed by the same system component which generates
`and displays the GUI300 of FIG.3 (i.e. email client 15 or 17).
`0036) As illustrated in FIGS. 4A-4C, exemplary GUI 400
`contains six individually selectable checkboxes 402, 410.
`416, 422, 428 and 434. Each checkbox represents a single
`thread priority assessment criterion which may be selected by
`a user individually or in conjunction with other priority
`assessment criteria.
`0037 Referring to FIG. 4A, a first screen of the exemplary
`GUI 400 contains checkboxes 402 and 410. Selection of the
`first checkbox 402 configures the email client to use the
`number of messages in a message thread as a criterion for
`setting message thread priority level. The threshold number
`of messages is set by the user 12 via edit box 403. The priority
`level that should result when the threshold number of mes
`
`sages in the thread is exceeded is also user-configurable by
`way of drop-down list 404. In some situations, the priority
`level will be an escalated priority level, for example when a
`large number of messages in the thread reflects the fact that
`the topic is of high importance to the thread participants. In
`other situations, the priority level may be a lowered priority
`level, for example when a large number of messages in the
`thread reflects the fact that the topic has already been
`adequately discussed.
`0038. In the present embodiment, checkbox 402 has an
`associated set of options 405 which only becomes available
`when the checkbox 402 is checked. A first option 406 com
`prises a checkbox which, if selected, requires the number of
`messages specified in edit box 403 to have been received
`within a time period T (e.g. within 20 minutes, indicating a
`“flurry' of messages) in order for the priority level specified
`in drop-down list 404 to be applied. The time period T is
`specified by the user in edit box 407. In alternative embodi
`ments, T could be a predetermined or fixed time. The first
`option 406 may only become available (e.g. may only change
`from a “greyed out condition to a visible condition wherein
`the checkbox 406 is selectable) upon selection of the check
`box 402. A second option 408 comprises a checkbox which,
`if selected, causes the setting of the user-specified priority
`level to be conditional upon the time period T not having
`occurred more than duration D2 since the current time (i.e. the
`“flurry' must have been recent). The duration D2 is specified
`by the user in edit box 409. In alternative embodiments, D2
`could be a predetermined or fixed duration. The second
`option 408 may only become available when the checkbox
`406 associated with the first option is selected.
`0039. Selection of the checkbox 410 of FIG. 4A config
`ures the email client to use recipient identity as a criterion for
`setting message thread priority level. A set of individually
`selectable recipient identities 414 is automatically generated
`and displayed near checkbox 410. If any of the selected
`recipient identities 414 is a named recipient in any message of
`a message thread, the priority level of the thread will be set to
`the user-specified level which has been set via drop-down list
`412. Notably, the recipient identities 414 may include distri
`bution lists identifying multiple recipients (e.g. “marketing
`(DL), wherein “DL is an abbreviation for “distribution
`list').
`0040 Turning to FIG. 4B, a second screen of the exem
`plary GUI 400 contains checkboxes 416,422 and 428. Selec
`tion of the checkbox 416 configures the email client to use
`participant identity as a criterion for setting message thread
`priority level. This criterion is similar to the preceding crite
`rion, except that the party identified using checkboxes 420
`must have participated in the thread (i.e. originated at least
`one message comprising the thread) in order for the priority
`level set via drop-down list 418 to be applied.
`0041) Selection of checkbox 422 configures the email cli
`ent to use recipient quantity as a criterion for setting message
`thread priority level. If the total number of recipients of at
`least one message of a thread is greater than the user-specified
`number of 25 (set by way of edit box 424), the priority of the
`thread is set to high (i.e. the level specified in drop-down list
`426). Drop-down list 423, also permits the user-specified
`priority level to be applied when the total number of recipi
`ents is less than a user-specified number. The threshold num
`ber of recipients could be predetermined or fixed in other
`embodiments.
`
`Facebook's Exhibit No. 1015 - Page 12
`
`

`

`US 2008/030 1 250 A1
`
`Dec. 4, 2008
`
`0042. A similar checkbox 428 configures the email client
`to use the total number of distribution lists named as recipi
`ents of at least one message of the thread as a criterion for
`setting message thread pr