CN116235483A - Messaging service - Google Patents

Abstract

A messaging system may receive a plurality of messages in a session. One or more of the messages may be determined to include information indicative of a topic. The association between the information indicative of the topic and the session may be stored in a database. An input may be received indicating a selection of a theme. In response to receiving the input, at least a subset of the session (such as one or more of the messages) may be sent to the messaging application. The messaging application may display a subset of the session.

Description

Messaging service

Background

Communications in workplaces and social circles are increasingly being conducted using internet-based tools. The internet-based tool may be any software or platform. Conventional communication tools such as e-mail may facilitate both internal and external communications. However, due to various limitations, conventional communication tools may not meet the needs of users. As communication devices become more complex, new tools are continually being discovered to improve communication efficiency and efficiency.

Drawings

The following detailed description may be better understood when read in conjunction with the accompanying drawings. For the purpose of illustration, example embodiments of various aspects of the disclosure are shown in the drawings; however, the disclosure is not limited to the specific methods and instrumentalities disclosed.

FIG. 1 illustrates an example cloud computing network on which messaging services may operate.

Fig. 2 illustrates an example messaging system according to this disclosure.

FIG. 3 illustrates an example messaging technique that may be performed by a messaging service and a messaging application/service.

FIG. 4 illustrates an example messaging technique that may be performed by a messaging service and a messaging application/service.

FIG. 5 illustrates an example data model that may be used in accordance with this disclosure.

Fig. 6 illustrates an example process that may be performed by a messaging service according to this disclosure.

Fig. 7 illustrates another example process that may be performed by a messaging service according to this disclosure.

FIG. 8 illustrates an example messaging technique that may be performed by chat services and push services of a messaging service.

FIG. 9 illustrates an example user interface of a messaging application including a session.

FIG. 10 illustrates an example user interface of a messaging application including a conversation.

FIG. 11 illustrates an example technique for adding a theme to a session.

FIG. 12 illustrates an example user interface of a messaging application in which a topic tag can be added to a session.

FIG. 13 illustrates an example user interface of a messaging application in which sessions may be categorized by topic tags.

Fig. 14 illustrates an example technique for creating groups and inviting members.

FIG. 15 illustrates an example user interface of a messaging application in which a new group may be created.

Fig. 16 illustrates a group view in a user interface of a messaging application in which users in the group may be displayed.

FIG. 17 illustrates an example technique for adding new members to an existing group.

FIG. 18 illustrates an example technique for assigning and managing tasks using messaging services.

FIG. 19 illustrates an example user interface of a messaging application in which reminder dates can be scheduled.

FIG. 20 illustrates an example technique for integrating email services and messaging services.

FIG. 21 illustrates an example user interface of a messaging application in which an email address may be added to a conversation.

Fig. 22 shows an example of an email message received at an email address and sent from a messaging service.

FIG. 23 illustrates an example user interface of a messaging application in which messages sent from an email address may be displayed in a corresponding session.

Fig. 24 illustrates an example process that may be performed by a messaging application in accordance with this disclosure.

Fig. 25 illustrates an example user interface of a messaging application in accordance with this disclosure.

Fig. 26 illustrates another example process that may be performed by a messaging application in accordance with this disclosure.

Fig. 27 illustrates an example user interface of a messaging application for creating a new session in accordance with this disclosure.

Fig. 28 illustrates another example user interface of a messaging application for creating a new session in accordance with this disclosure.

Fig. 29 illustrates an example process that may be performed by a messaging application in accordance with this disclosure.

FIG. 30 illustrates an example user interface of a messaging application generated based on attributes of a session and through which a user may provide input to reorganize the session.

FIG. 31 illustrates another example user interface of a messaging application in which a two-dimensional representation is overlaid on another user interface.

FIG. 32 illustrates another example user interface of a messaging application in which a conversation is filtered in response to selection of an intersection point in a two-dimensional representation.

FIG. 33 illustrates an example computing device that can be used to perform any of the techniques disclosed herein.

Detailed Description

FIG. 1 illustrates example components of a cloud computing system 100. By way of example, and not limitation, cloud computing system 100 may be used to perform various aspects of the disclosed subject matter. Cloud-based computing generally refers to a networked computer architecture in which application execution, service provisioning, and data storage may be divided to some extent between client devices and cloud computing devices. A "cloud" may refer to a service or set of services accessible by client devices, server devices, and by other cloud computing systems over a network (e.g., the internet).

In one example, multiple computing devices connected to the cloud may access and use a common pool of computing capabilities, services, applications (applications), storage, and files. Thus, cloud computing enables a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be provided and published by cloud service providers with minimal management effort or interaction.

As an example, a cloud-based application may store copies of data and/or executable program code in a cloud computing system while allowing a client device to download at least some of this data and program code as needed for execution at the client device. In some examples, the downloaded data and program code may be customized for the ability to access a particular client device (e.g., personal computer, tablet computer, mobile phone, and/or smart phone) of the cloud-based application. In addition, for example, dividing application execution and storage between the client device and the cloud computing system allows the cloud computing system to perform more processing, thereby taking advantage of the processing power and performance of the cloud computing system.

Cloud-based computing may also refer to a distributed computing architecture in which data and program code for cloud-based applications are shared in near real-time between one or more client devices and/or cloud computing devices. Portions of this data and program code may be dynamically delivered to various clients accessing the cloud-based application as needed or otherwise. The details of the cloud-based computing architecture may be largely transparent to the user of the client device. By way of example and not limitation, for example, a PC user device accessing a cloud-based application may not be aware that the PC is downloading program logic and/or data from the cloud computing system, or that the PC is offloading processing or storage functions to the cloud computing system.

In fig. 1, cloud computing system 100 includes one or more cloud services 104, one or more cloud platforms 106, cloud infrastructure components 108, and cloud knowledge base 110. Cloud computing system 100 may include more or fewer components, and each of cloud services 104, cloud platform 106, cloud infrastructure components 108, and cloud knowledge base 110 may also include a plurality of computing and storage elements. Thus, one or more of the described functions of cloud computing system 100 may be divided into additional functions or physical components or combined into fewer functions or physical components. In some further examples, additional functional and/or physical components may be added to the example shown in fig. 1. Delivery of cloud computing-based services may involve multiple cloud components communicating with each other through, for example, application programming interfaces (such as web services and multi-tier architectures).

The example cloud computing system 100 shown in fig. 1 is a networked computing architecture. Cloud service 104 may represent a queue for processing requests from client devices. Cloud platform 106 may include a client interface front end for cloud computing system 100, such as a messaging service. Cloud platform 106 may be coupled to cloud service 104 to perform functions for interacting with client devices. Cloud infrastructure 108 may include services, billing, and other operations and infrastructure components of cloud computing system 100. Cloud knowledge base 110 is configured to store data for use by cloud computing system 100, and thus, cloud knowledge base 110 may be accessed by any of cloud services 104, cloud platform 106, and/or cloud infrastructure components 108.

Many different types of client devices, such as devices of users of messaging services, may be configured to communicate with components of cloud computing system 100 for accessing data and executing applications provided by cloud computing system 100. For example, computer 112, mobile device 114, and host 116 are shown as examples of the types of client devices that may be configured to communicate with cloud computing system 100. Of course, more or fewer client devices may be in communication with cloud computing system 100. In addition, other types of client devices may also be configured to communicate with cloud computing system 100.

The computer 112 shown in fig. 1 may be any type of computing device, such as a PC, laptop, tablet, etc., and the mobile device 114 may be any type of mobile computing device, such as a laptop, smartphone, mobile phone, cellular phone, tablet, etc., configured to transmit data to the cloud computing system 100 and/or receive data from the cloud computing system 100. Similarly, host 116 may be any type of computing device having a transmitter/receiver, including a laptop, mobile phone, smart phone, tablet, etc., configured to transmit data to/receive data from cloud computing system 100.

In fig. 1, the communication link between the client device and cloud 100 may include a wired connection, such as a serial or parallel bus, ethernet, optical connection, or other type of wired connection. The communication link may also be a wireless link such as Bluetooth, IEEE802.11 (IEEE 802.11 may refer to IEEE 802.11-2007, IEEE802.11 n-2009, or any other IEEE802.11 revision), CDMA, 3G, GSM, wiMAX, or other wireless-based data communication link.

In other examples, the client device may be configured to communicate with the cloud computing system 100 via a wireless access point. The access point may take various forms. For example, the access point may take the form of a Wireless Access Point (WAP) or a wireless router. As another example, if the client device connects using a cellular air interface protocol (such as CDMA, GSM, 3G, or 4G), the access point may be a base station in a cellular network that provides internet connectivity via the cellular network.

Thus, the client device may include a wired or wireless network interface through which the client device may connect to the cloud computing system 100 directly or via an access point. As an example, a client device may be configured to use one or more protocols, such as 802.11, 802.16 (WiMAX), LTE, GSM, GPRS, CDMA, EV-DO, and/or HSPDA, among others. Further, the client device may be configured to use multiple wired and/or wireless protocols, such as a "3G" or "4G" data connection using a cellular communication protocol (e.g., CDMA, GSM, or WiMAX) and a "WiFi" connection using 802.11. Other types of communication interfaces and protocols may also be used.

Fig. 2 illustrates an example messaging service 220 for performing the disclosed techniques. By way of example and not limitation, messaging service 220 may operate on cloud network 100 in fig. 1. Messaging service 220 may include a combination of cloud network devices and local devices. Messaging service 220 may include chat service 222. Chat service 222 may be a device and/or a program running on a device of messaging service 220.

Chat service 222 may be configured to receive input from user 210. The users 210 may register as users of the messaging service 220 to exchange messages with each other within the messaging service 220. The user 210 may be a user of a messaging application 240 operating on a user device 242. The user input may include a request to start a session (conversation). The session may be initiated by selecting a "start session" icon in a User Interface (UI) of the messaging application 240 operating on any user device 242. The session may be initiated by the creator user without requiring any other participants for which the session has been identified. Participants of a session include any entity that is allowed to participate in the session in any manner. For example, a participant of a session may be a creator user, a group (group) invited to join the session, an allocator user that may allocate a task to another participant (an allocator user), an allocator user, an email participant invited to join the session, and so on.

Chat service 222 may generate and/or manage sessions. For example, chat service 222 may categorize the conversation. Chat service 222 may store the conversation, any associations with the conversation, and/or conversation metadata in one or more databases 260, such as conversation database 230, topic database 236, group database 232, user database 234, search index database 252, task database 256, email user database 237, email message database 238. The input may include a message, such as a message to be added to an existing session or a new session. Chat service 222 may add messages to the conversation. Chat service 222 may store the messages and/or message associations in a database, such as session database 230.

Messaging service 220 may determine that the message includes information identifying the user, such as a user name, a handle (i.e., a user name followed by the @ symbol), an account, and the like. Messaging service 220 may add the identified user to the session. Messaging service 220 may store associations of users with sessions, such as in session database 230, group database 232, user database 234, and/or search index database 252. The user may be granted access permissions to the session, such as to view feedback (feed) of messages in the session that have previous communications.

Messaging service 220 may determine that the message includes information indicating a topic. A topic may be associated with a corresponding session. The messaging service 220 may add the topic to one or more databases, such as the topic database 236. The messaging service 220 may store associations of topics with sessions, such as in the session database 230 and/or the topic database 236.

Messaging service 220 may determine that the message includes information identifying the group. These groups may be groups of users. Messaging service 220 may add the group to the session. Messaging service 220 may store associations of groups with sessions, such as in session database 230, group database 232, user database 234, and/or search index database 252.

Messaging service 220 may determine that the message includes information indicating the task assigned to the user. The messaging service 220 may further receive information indicating an expiration date of the task. Tasks and expiration dates may be associated with users and sessions. Messaging service 220 may add the tasks and expiration dates to a database 260, such as task database 256. Messaging service 220 may store associations of tasks, expiration dates, users, and sessions, such as in session database 230, user database 234, and task database 256.

Messaging service 220 may determine that the message may include an email address. The email address may be associated with a session. The email address may be the intended recipient of the message in the conversation. Messaging service 220 may add an email address to the conversation. Messaging service 220 may store an association of an email address with a conversation, such as in conversation database 230, email user database 237, and/or email message database 238.

Messaging service 220 may include push service 224. The push service 224 may be a device and/or a program running on a device of the messaging service 220. The push service 224 may receive data from the chat service 222, such as an indication of user input. The push service 224 may store and/or access data in the database 260. The push service 224 may push (e.g., send, display, etc.) data, such as an indication of user input, to a user device, such as via the messaging application 240. The push service 224 may push data to email addresses external to the messaging service 220.

Messaging service 220 may include other services. Other services may include group services 251. The group service 251 may manage a user group. The group service 251 may manage the association of the stored groups. The group service 251 may identify the members included in the group by searching the search index database 252. Other services may include reminder/scheduler service 253. The reminder/scheduler service 253 can determine an association between the expiration date and the task. The reminder/scheduler service 253 can send reminders associated with expiration dates and/or tasks. The reminder/scheduler service 253 can manage the stored expiration dates and/or tasks.

Other services may include email service 254. Email service 254 may generate an email message and send the email message to an email address external to messaging service 220. Email service 254 may receive data from an email address external to messaging service 220. Email service 254 may determine the conversation associated with the data received from the email address and generate a corresponding message to send to the user in the conversation. Other services may further include authentication service 226. Authentication service 226 may authorize and verify access to various sessions. Authentication service 226 may grant participants of the session hierarchical rights. For example, only participants with a particular level of rights may be allowed to add other participants, assign tasks, and so forth.

It should be appreciated that messaging service 220 in fig. 2 is merely illustrative and that other implementations may be utilized. It should also be appreciated that the functionality disclosed herein may be implemented by one or more servers or computing devices. In addition, it should be understood that the functions disclosed herein may be implemented in software, hardware, or a combination of software and hardware.

Fig. 3 shows an example of messaging service 220. Messaging service 220 may communicate with network 301. The network 301 may include the internet. Network 301 may include one or more cloud network components. The network 301 may communicate with one or more databases 260 via a network. Database 260 may be the same as or similar to databases 230-238 in fig. 2. By way of example, database 260 may include a subject database, a session database, a user database, and/or a tag database. The messaging service 220 may store the attributes and/or associations in a database 260. The messaging service 220 may access (e.g., query) the database 260 to obtain attributes, associations, or other data.

The messaging service 220 may communicate with one or more user devices 242 via a network 301. The messaging service 220 may communicate with the device 302 via a messaging application 240 operating on the user device 242. The messaging application 240 may be configured to manage data and permissions, such as conversations, conversation topic tags, users, groups, privacy, and the like.

Messaging service 220 may communicate with connected users 210 via network 301. The connected user 210 may be a user engaged in a session of the messaging service 220 and/or messaging application 240. For example, connected user 210 may receive a message associated with the conversation via an external email address. Connected users 210 may send messages from external email addresses to messaging service 220, messaging application 240, sessions, and/or other users.

Fig. 4 illustrates a messaging technique 400. The technique 400 may be performed by a messaging service (e.g., the messaging service 220 of fig. 2 and 3), a messaging application (e.g., the messaging application 240 of fig. 2 and 3), one or more users 210, and/or one or more user devices 242. At 401, a session may be started. The session may be started by a creator user (i.e., a user that caused the creation of the session) by inputting an input requesting to start the session via the messaging application. For example, the user may select a "start session" icon in a UI of a messaging application displayed on the user device. A chat service (e.g., chat service 222 in fig. 2) may receive the input and may generate a session. The session may be initiated without identifying any other participants of the session.

At 402, a message may be input. The message may be entered by the user via a messaging application. Messages may be entered in a session, such as via input fields shown in a UI of a messaging application. The message may be entered before any other participants of the session are identified. The message may include text. The chat service may receive the message. Messages may be added to the session. A message may be sent to one or more users associated with the session. A message may be sent to one or more external users, such as external email addresses that have been added to the conversation. The association of the message with the session may be stored in a database (e.g., database 260 in fig. 2-3).

At 403, the message may be parsed to determine content and/or attributes. The message may be parsed by a messaging application (e.g., messaging application 240 in fig. 2-3) and/or a messaging service (e.g., messaging service 220 in fig. 2-3). For example, the messaging application may determine an attribute of the message, such as an attribute identified by a special character in the message, and may send an indication of the attribute to the messaging service.

At 404, the content of the message may be stored in a content database (e.g., database 260 in fig. 2-3). The association of content with one or more users (such as users tagged in a message) may be stored in a database (such as user database 234, group database 232, search index database 252). The content and/or the associations may be stored in a database by a messaging service (e.g., messaging service 220 in fig. 2-3).

At 405, the attributes of the message may be stored in attribute databases (such as topic database 236, user database 234, group database 232, search index database 252, email user database 237, and task database 256). The association of attributes with the content of the message may also be stored in an attribute database and any other database. For example, as shown in fig. 2-3, attributes and/or associations may be stored by messaging service 220 in database 260.

At 406, attributes of the message may be processed. For example, the content of the message may be tagged by the topic associated with the session. As another example, a search may be performed for all users associated with the content. The attributes of the message may be handled by a messaging service.

In some embodiments, messaging systems (e.g., messaging services and messaging applications) according to the present disclosure are more message-centric than most messaging systems based on direct exchange between users, where messages are content and users are attributes of the content. For example, the techniques of this disclosure do not require identifying the recipient or subscriber of the session. In contrast, the present messaging system allows a session (such as a series of messages) to be created by a creator user (e.g., a user that caused the creation of the session) without the need to identify any other participants. Participants to a session are just creator users and not just recipients. The creator user may publish a message, mark the topic of the conversation, add other participants to the conversation, assign tasks to other participants, and so forth.

After the session has been created, other participants may be added to the session. Unlike most messaging systems, which define participants of a session at the beginning of the session, the present messaging system allows participants to join the session at any time. Participants may be brought into an existing session by entering the user name, group name, or email address of the user of the current messaging service in the session. The participants may then be added to the session and receive past and future messages communicated in the session (such as in feedback or notifications). The added participants may participate in the session, such as by publishing messages in the session, by tagging topics for the session, by assigning tasks, and/or by adding other participants to the session.

Fig. 5 illustrates an example embodiment of a data model according to the present disclosure. It should be understood that the example data model in fig. 5 is merely illustrative and that other arrangements may be utilized. As shown, the data model is session-centric. In other words, the session is the primary data in the database. Other data (such as user data, subject date, task data, etc.) are attributes of the session. As shown, the session database 230 of the messaging service includes a plurality of sessions. Session database 230 includes a plurality of tables. For example, thread table 502, message table 504, and content table 506 are all stored in session database 230.

The Thread table 502 contains entries such as thread_id, user_id, and created_time. The thread_id is a primary key that is used to reference other data and attributes. For example, thread_id is used to find a message associated with a particular thread_id. Thread_id is also used to look up attributes in the attribute database that are associated with the Thread identified by thread_id, as explained more fully below. Records stored in session database 230 are more fully interpreted before interpreting the attribute database.

With respect to the session database 230, whenever a User creates a new Thread (e.g., a new session), the message service generates and assigns a new thread_id, and creates a new record in the Thread table along with the user_id of the User creating the Thread and the Time the Thread was Created (created_time). In addition, information associated with each Message in a particular Thread (e.g., a particular session) Is stored in the Message table 504 along with a thread_id, a user_id (User used to create the Message), a message_id identifying each Message, a Time when the Message was Created (created_time), and an entry (is_mentioned) identifying other users or groups that may have been Mentioned and added in the session. The users or groups that have been mentioned in the session (e.g. preceded by the @ symbol) are hereinafter referred to as "mentioned". The content of each message may be stored separately in the content table 506 and referenced by a corresponding message ID. This is because the storage size of a message may vary greatly depending on whether the message contains a short string or some form of media (such as JPEG or video).

As described above, each thread (session) may have an associated attribute. These attributes are referenced by the thread_id of the session. For example, thread_id is a key for each attribute database and can be used to find all associated attributes for a particular session. As shown in fig. 5, the user is an attribute of the session. The user associated with a particular session may be determined by searching the user database 234 for all users associated with a particular thread_id corresponding to the particular session. The search will return all matching userids.

Similarly, a search of email message database 238 will return all userid for users associated with threads via email. That is, each time an email address is added to a conversation, a new record is created in email message database 238. Each record will store the User ID of the User to which the email address was added in the session. In addition, a return_email address corresponding to the session will be assigned by the messaging service (e.g., messaging service 220) and stored in Email message database 238. Each Email participant (i.e., the participant added via the Email Address) will also be assigned a mail_box_user_id, which can be used to find the associated email_address. The email address is stored along with the message_id of the Message that includes the email address. Message content, etc., for each email message is also stored in email message database 238 (e.g., email attribute tables 522 and 520).

The attribute database also includes, for example, a group database (e.g., group database 232). The group database 232 stores information about groups associated with the session (e.g., group attributes). The data stored in the Group database 232 includes one or more of a thread_id, a group_id, and a created_time (Time when the Group was Created). The group_id is further used to point to a record containing the group_name (Name of the Group), the owner_user_id (user_id of the Owner of the Group, e.g., creator of the Group), the Group type (e.g., private or public Group), the joining time (time when the member joined the Group), and the status associated with the Group.

In an embodiment, the attribute database includes a task database (e.g., task database 256) that stores information (e.g., task attributes) indicative of task assignments associated with the session. The task attributes stored in the task database 256 are also referenced by the thread_id of each session. Some of the data and information stored in the task database 256 includes expiration dates (essentially expiration dates), dispatcher and dispatcher User IDs (assigner_user_id and assignee_user_id), and status (e.g., status). Creation time, verification time, and last update time may also be associated with the record stored for the task.

According to an embodiment, the attribute database further includes a topic database (e.g., topic database 236) that stores information indicative of topics associated with the session (e.g., topic attributes). The Topic database is referenced by and associated with each session's thread_id and typically includes a user ID, a topic_id, and a creation time associated with each Topic. Topic_ID is used to reference the Topic Name (Topic_Name). Whenever a new topic is added to the session, for example, by entering a message beginning with a hash tag in the session, a messaging service (e.g., messaging service 220) will store the entry in topic database 236 referenced by the thread_id of the session.

As described above, these various attributes are associated with a thread_id that is generated when a new Thread (e.g., a new session) is created in a messaging service (e.g., messaging service 220). Thus, messaging service 220 may search for and retrieve various attributes associated with the session. Session and thread are used interchangeably herein to some extent. In one example, message thread database 230 and multiple attribute databases (e.g., topic database 236, task database 256, group database 232, email message database 238, and user database 234) may be stored on the same server or device. In another example, the message thread database 230 and the plurality of attribute databases may be stored on different servers or devices, respectively. Message thread database 230 and the plurality of attribute databases may be hosted on one or more physical servers or one or more virtual servers.

Fig. 6 illustrates an example process 600 performed by a messaging service (e.g., messaging service 220) in connection with the data model shown in fig. 5. While depicted in FIG. 6 as a series of acts, one of ordinary skill in the art will appreciate that various embodiments may add, remove, reorder, or modify the depicted acts.

At 602, messaging service 220 receives a request from a messaging application (e.g., messaging application 240 operating on user device 242) indicating at least one of the sessions. For example, the user may have requested, via messaging application 240, information indicating attributes associated with one or more sessions in which the user is engaged. For example, the messaging application 240 operating on the user device 242 may request information indicating attributes (e.g., topic, user, group, task) associated with the user's session. In response to the request, at 604, messaging service 220 will look up all thread_ids associated with the User's user_id in User database 234 and further query other attribute databases to determine various attributes associated with the identified session based on the thread_id. In one example, messaging service 220 may look up all topics associated with the thread ID in a topic database. At 606, messaging service 220 processes the query results to determine that at least one attribute (e.g., a topic attribute) is associated with at least some of the sessions.

At 608, the messaging service 220 will send attribute information associated with the session to the messaging application 240 for displaying an indicator of the attribute on the user device 242. For example, as shown in fig. 12, a plurality of topics associated with a session are displayed on the leftmost column 1205 of the User Interface (UI) 1200. In some embodiments, there may be multiple attributes and they may be assigned different priorities by messaging service 220 or messaging application 240. The messaging service 220 or messaging application 240 may organize the plurality of attributes based on their priorities. In an example, the mention (i.e., user or group added to the session) attribute may have a higher priority than the topic attribute. For example, the mention attributes in fig. 25 (e.g., user E2501 and group 1 2504) may be assigned a higher priority than the topic attribute. The indicators of attributes in fig. 25 are displayed based on the mentioned attributes that may display one or more topics (if any). In an example, there may be multiple topics associated with a session having a particular mention attribute. As shown in fig. 25, there are multiple topics (including a "patent" topic 2502) associated with a session with a mention attribute user E2501, and the multiple topics are displayed under the mention attribute user E2501 because the mention attribute has a higher priority than the topic attribute in this example.

In some embodiments, in response to receiving a request from messaging application 240, messaging service 220 may query database 260 (e.g., user database 234, task database 256, etc.) to determine the tasks associated with any particular user. For example, messaging service 220 receives a request from messaging application 240 that includes identification information (e.g., a user ID) of a particular user. In response, messaging service 220 searches user database 234 based on the user ID to identify a thread_id corresponding to the session in which the user is engaged. Messaging service 220 may then query task database 256 based on the thread_id to find the task associated with the session. The messaging service 220 may identify an assignment_user_id and an assignment_user_id for each task based on searching the task database 256. The messaging service 220 may then determine whether any tasks are associated with a particular User based on determining whether the identified assigner_user_id or assignee_user_id is the same as the User ID of the particular User. Upon determining that any tasks are associated with a particular user, messaging service 220 sends information indicative of the determined tasks to messaging application 240 to display the tasks associated with the particular user. In an example, the messaging application 240 may categorize or order the tasks based on expiration dates associated with the tasks. In another example, the messaging application 240 may categorize or order the tasks based on information associated with the task's distributor or distributor. The messaging application 240 may display the categorized or ordered tasks in a predetermined area of the UI or in a window overlaid on the UI.

In an embodiment, additional interactions between messaging application 240 and messaging service 220 may occur. For example, at 610, the messaging service 220 receives an input from the messaging application 240 indicating that the messaging application 240 has selected an attribute (such as a topic) from the displayed topic list, as shown on the leftmost column in FIG. 12. In response, at 612, messaging service 220 queries message thread database 230 for messages associated with the selected attribute (e.g., topic). Thereafter, messaging service 220 sends the message to messaging application 240 for display of the message on user device 242. For example, as shown in fig. 12, messages associated with the selected topic are displayed on the rightmost column 1204 of the UI 1200.

Fig. 7 shows another example process 700 that illustrates interactions between a messaging application (e.g., messaging application 240) and a data model maintained in messaging service 220. While depicted in FIG. 6 as a series of acts, one of ordinary skill in the art will appreciate that various embodiments may add, remove, reorder, or modify the depicted acts. In another embodiment, at 702, the messaging service 220 receives a request indicating at least one of the sessions from a messaging application associated with the user (e.g., messaging application 240 operating on user device 242). In response, at 704, the messaging service 220 queries the message thread database 230. For example, messaging service 220 will look up the corresponding session that the user has engaged in. Thereafter, at 706, messaging service 220 processes the query results to determine a subset of the messages in each session. In one embodiment, the subset of messages for each session may be the initial message and the final message in the session. Messaging service 220 may create a summary for each session based on a subset of the messages. At 708, messaging service 220 sends a subset of the messages to messaging application 240 to display a summary of each session. For example, as shown in fig. 12, a summary of the session is displayed in the middle area 1216 of the UI 1200.

In some embodiments, at 710, the messaging service 220 may receive a request indicating that the messaging application 240 selected one of the summaries. In this case and in response, messaging service 220 may again query session database 230 to retrieve all messages or multiple messages in the corresponding session at 712. In an embodiment, messaging service 220 may retrieve all messages in the corresponding session. In other embodiments, the messaging service may retrieve a subset of the messages in the corresponding session. For example, when the number of messages and the content of the messages are such that the amount of memory required by the user device (e.g., user device 242) to store the messages is above a threshold, it may be advantageous for messaging service 220 to retrieve only a subset of the messages to send to user device 242. In a non-limiting example, messaging service 220 may retrieve only the most recent message in the corresponding session. At 714, messaging service 220 sends at least a subset of the messages in the retrieved session to messaging application 240 so that messaging application 240 can display the message on user device 242.

Fig. 8 illustrates a messaging technique. The techniques may be performed by a messaging service (e.g., messaging service 220 in fig. 2 and 3), a messaging application (e.g., messaging application 240 in fig. 2 and 3), one or more users 210, and/or one or more user devices 242. At 801, a session may be started. The creator user may start the session by entering an input requesting to start the session via the messaging application. For example, the user may select a "start session" icon in a UI of a messaging application displayed on the user device. A chat service (e.g., chat service 222 in fig. 2) of the messaging service may receive the input and may generate the session. The session may be initiated by the creator user without the need to identify any other participants of the session.

At 802, upon receipt of a message by a messaging service 220 (such as chat service 222), a lookup may be performed for all participants in the session (e.g., creator user and any other participants). The content of the message may be determined. The content may be parsed by a messaging service 220, such as a chat service 222. Parsing the content may include determining one or more attributes of the message and/or session. For example, the content may include text that includes predetermined special characters that represent attributes (such as a topic, a user, and/or a group of users). The lookup may be performed by messaging service 220 (e.g., chat service 222). The lookup may be performed by querying one or more databases 260. Database 260 may include a conversation database 230, a group database 232, a user database 234, a topic database 236, a task database 256, an email user database 237, and/or an email message database 238. The association of the participant with the session may have been stored in database 260, such as in turn chat service 222.

At 803, a topic associated with the session can be determined. The topic may be determined by a messaging service 220, such as chat service 222. The messaging service 220 may determine that the message includes information indicating a topic based on parsing the message and identifying predetermined characters included in the message. By way of example, and not by way of any limitation, the predetermined character may be a hash symbol #. The messaging service 220 may determine whether any messages associated with a session that have been received contain a new topic by searching for existing topics stored in the database 260 (e.g., the topic database 236). Upon determining that the topic is new, the messaging service 220 can store the new topic in a database 260 (e.g., topic database 236). Associations of sessions with topics may also be determined and stored in database 260, such as session database 230 and topic database 236.

At 804, a message and an indication of the new topic may be output (e.g., pushed, sent). An indication of the new topic (e.g., a new topic tag) may be sent by a push service (e.g., push service 224) to a messaging application (e.g., messaging application 240) associated with the participant in the conversation for display. Upon receiving user input indicating a selection of a topic, a message associated with the topic may be output by the push service 224 of the messaging service 220. The message and the subject tag may be output to a user of the messaging application, such as via a session in a UI of the messaging application 240 operating on the user device 242. The message and the subject tag may be sent to a user device (e.g., user device 242). The message and the subject tag may be sent to an external email address that has been added to the conversation.

At 805, a new participant a may be invited to join the session. The new participant a may be invited by an existing participant, such as by entering a user name, group name, or email address associated with the new participant a in an input field of the session. Messaging service 220 (e.g., chat service 222) may add new participant a to the session. The messaging service (e.g., chat service 222) may store the association of the new participant a with the session in database 260, such as in session database 230 and user database 234.

At 806, a lookup may be performed for an existing participant in the session. The lookup may be performed by a messaging service 220, such as chat service 222. Chat service 222 may send an indication of the determined participants of the session to push service 224.

At 807, existing participants in the session may be notified that new participant a has been added to the session. Existing participants may be notified by the push service 224. Notifying the existing participant may include sending a notification to a user device (e.g., user device 242) of the existing participant. Existing participants may be notified via a session and/or UI of a messaging application operating on their device.

At 808, the content of the message associated with the session may be determined. The content may be parsed by a messaging service 220, such as a chat service 222. Parsing the content may include determining one or more attributes of the content of the message. For example, it may be determined that the message includes text that includes text representing special characters of the attribute, such as new participant a. By way of example and not of any limitation, the predetermined special character representing the new user (i.e., new participant) may be the @ symbol. A lookup of the session may be performed, such as by querying a database 260, such as session database 230 and topic database 236. A lookup of the session may be performed to determine the user, message, topic, and other attributes associated with the session. Chat service 222 may send an indication of the results of the parsing and/or session lookup to push service 224.

At 809, the results of the session lookup, such as the message and the topic tag, may be output (e.g., pushed) to the new participant a. The message and the subject tag may be output by the push service 224. Outputting the message and the topic tag may include sending the message and the topic tag to the new participant, such as via a session in a UI of a messaging application (e.g., messaging application 240) operating on a user device (e.g., user device 242). The message and the subject tag may be sent to a user device associated with the new participant a (e.g., user device 242). The messages in the conversation may be sent to an external email address associated with new participant a. A messaging service according to the present disclosure may categorize a conversation based on attributes of topics associated with the conversation and provide content of the conversation to a participant in response to selection of a topic label indicating a topic of the conversation of interest to the participant. This allows current messaging services to more efficiently provide content of interest to users.

In connection with fig. 8, fig. 9 illustrates various aspects of starting a new session and adding a user to the new session. As described with respect to fig. 4, the user begins a new session. The user can start a new session by selecting the "start session" button 917. Fig. 9 illustrates this from the perspective of a user interface 900 operating on a user device (e.g., user device 242). Here, the user (e.g., user a) has started a session 901 and inputs a message "# tag-patent". Because no other users are associated with message 903, the message appears only in session 901 for a single user (user a), who is also the creator of the session (i.e., creator user). In this way, the creator user may continue to add messages to session 901. As explained more fully below, the "# tag-patent" message includes a topic ("patent") that is entered as at least a portion of the first message. In a conversation, messages including topics can be entered at any time. In an embodiment, it is processed by the messaging service and stored in the database as an attribute associated with session 901. Also, as explained, other participants of the session 901 (e.g., users of messaging services having access permissions to the session 901) may also be added to the session 901 as attributes of the session 901.

Referring again to fig. 8, a creator user of a session may invite a new user to participate in the session (i.e., a new participant). In some embodiments, the messaging service communicates with the plurality of databases 260 in question using the chat service 222 and the push service 224 as described above. Continuing with the example, the user may begin a session at 810 that includes one or more messages. The message may include a plurality of characters, symbols, be text strings, or other types of content. As new messages are added to the conversation, the chat service 222 determines which users are attributes of the conversation, i.e., users associated with the conversation. These attributes are stored in one or more databases. Such databases include, but are not limited to, a conversation database (e.g., conversation database 230), a group database (e.g., group database 232), a topic database (e.g., topic database 236), and an email user database (e.g., email user database 237). Participants to the session are identified and may be notified of the session.

Upon receiving a message in a session, a messaging service (e.g., messaging service 220) may determine whether a new topic is included in the message forming the session and may search one or more databases, such as topic database 236, for existing topics. Thus, attributes of the session (such as topic, user, group, etc.) ensure that the session is properly categorized (such as topic-based) and that new sessions are pushed out to the participants. The push service 224 assists in outputting messages, existing topic labels, and new topic labels to the intended participants. In some embodiments, this may occur by pushing the message to a user interface or user display on a device associated with the intended participant of the session.

In another example, a user may be invited to join a session. For example, at 805, a new participant a may be invited to join an existing session, which authorizes a messaging service (e.g., messaging service 220) to share information related to the session with the new participant a. Chat service 222 processes this action, looks up all existing participants associated with this session at 506, similar to the previous example, and communicates with one or more databases 260 (e.g., databases 230-236) as needed to obtain the associated information. Once the participant is identified, the push service 224 notifies the identified existing participant associated with the session at 807 to indicate to the existing participant that a new participant has been added to the session.

After a new participant a has been invited to join the session, messages, content, and/or metadata related to the session are retrieved from, for example, session database 230 and topic database 236 so that the push service may communicate related aspects of the session to the new participant. FIG. 9 illustrates an example User Interface (UI) 900 of aspects of a technique for inviting a new user to participate in a session. In fig. 9, UI 900 is shown as being presented on a user device (e.g., user device 242), such as through a messaging application (messaging application 240). In this case and as shown in UI 900, user a has already started a session 901 comprising one or more messages 902. In this example, the message "hello" has been added to the session 901. In addition, another message including the topic "patent" 903 has been added to the session 901. Session 901 may be stored in database 260 (e.g., session database 230). To add a new user, information indicating the user is entered into the message field 904 of the UI 900 using the @ symbol 905 or any other predetermined special character followed by a text string 906 identifying the user, for example, by a user name. Here, the user name of the user C is entered into the text field beginning with the @ symbol.

In an embodiment, after the user selects the "send" button 907, the message is sent to a messaging service (e.g., messaging service 220). The messaging service then parses the message to determine that the message contains a predetermined @ symbol 905 and interprets the subsequent text 906 of the message as user identification information, as described for the example in fig. 4. The messaging service then interprets the message as a request by the user a authorization system to add the identified user C (i.e., the new participant) to the session. Other embodiments are also contemplated, for example, a messaging application on a user device may parse a message and send an indicator to a messaging service that a user wants to authorize an identified user C (i.e., a new participant) to join a session. In other words, the processing of the message may be partially completed on the user equipment and part of the processing may be completed by the messaging service.

In some cases, once authorized, the cloud service may add information identifying the new participant (e.g., the user name of the new participant) as an attribute of the session. To this end, the user is associated with session 901, and the association is stored in database 260. It should be appreciated that a plurality of symbols, text, characters, etc. may be defined as indicators associated with identifying a particular user. In this particular example, the @ symbol is a predetermined symbol for adding a new user and the user enters a new user name "@ user C (@ UserC)", which is identified by the messaging service as a new participant in the session 901.

Fig. 10 illustrates aspects of this feature from the perspective of UI 1000 after a new participant 1002 (e.g., user C) is added to session 1001. In this example, the user name of the new participant 1002 is another message in the session 1001 as shown. In other words, the fact that the new participant is added to the session 1001 is retained in the text of the session 1001 itself. Thus, the order and time that new participants and other attributes are added to session 1001 can be discerned by parsing the messages in session 1001. For example, after adding the new participant user C, the user (e.g., user a) is also at 09 pm: 31 another message including the topic "# tag-patent1 (#tag-patent 1)" is input to the session 1001. Thus, a user (e.g., user A) may add a new user to the session specifying one or more topics associated with session 1001 by entering messages (e.g., "# tag-patent", "# tag-patent 1"). These particular messages in session 1001 are also attributes of the session that are stored in various attribute databases, such as subject database 236, user database 234, etc., as shown in fig. 2. In an embodiment, different symbols, letters, characters may be used to define the attributes, for example @ is used to indicate the user name or other user identification to be entered, and hash tag # is used to indicate the subject matter to be associated with session 1001. It is contemplated that other symbols may be used to add additional properties to the session.

Fig. 9-10 also illustrate that the sessions may be categorized, for example, by topic, as indicated by leftmost columns 909, 1009. The depicted example illustrates content labeled as a "feedback (Feed)" view 908, 1008, where sessions are categorized by attributes, such as theme attributes. The selection feedback will display a list of one or more sessions associated with the selected topic in a reduced version of the session. In an embodiment, selecting a reduced version of a session will display one or more messages associated with the selected session. Here, for example, a reduction (or summary) of the session is shown, with the creator of the session listed at the top, followed by the initial message "user B hello" 910, 1010 in the session, followed by the last message in the session, which is the message "# tag-patent1"911, 1011 for adding the second topic. The compaction (or summary) of the session shows the user a preview of the session, which allows the user to determine if he/she is interested in the session and if he/she wants to review the entire content of the session by selecting the summary of the session. Topics (shown on the UI as topic tags) serve as short descriptors of the content of the session.

In other embodiments, sessions may be categorized by one or more other categories and categorizations (such as "group" views 912, 1012), where sessions and messages are organized based on the groups to which each of those sessions and messages are directed, as discussed below. These will be further described in other embodiments below.

Fig. 11 illustrates an embodiment for adding a topic tag to a session and adding a new message to a session. As described above, the topic labels corresponding to topics are attributes of the conversation, which are used, for example, in the feedback view to allow simple classification, management, and selection of the conversation. One or more topics may be associated with the session through such topic tags. By way of example and not limitation, a subject tag may be a text string having a leading character that indicates that subsequent text contains a subject. In this embodiment, the hash symbol or "#" is the predetermined character identified by the messaging service for representing the subject. The user (i.e., participant) may begin the session. In this example, the user also adds a theme to the session at 1110. Chat service 222 then receives an indication of the new session and may parse the message to detect the presence of the topic. As mentioned earlier in the description, parsing of the message may be accomplished by a messaging service (e.g., messaging service 220), a messaging application (e.g., messaging application 240), or some combination of both on a user device (e.g., user device 242). After a session is started by entering a message, such as a message that includes a topic, a lookup 830 occurs to determine if any other users (i.e., participants) are associated with the attributes of the session. The lookup may be performed by one or more searches of databases 260, such as session database 230, group database 232, user database 234, and topic database 236.

Once the relevant users (i.e., participants to the session) are identified, the session is added to the topic label classifications of all participants stored and tracked in the various databases at 840. In other words, an association may be stored between the new session and the specified topic label, and an association may be stored with all users associated with the topic label and also associated with the session. Thus, the session 1150 is summarized for all participants in conjunction with the topic label. For example, in the case of adding a user to a session, the user may receive a reduced version of the topic consisting of the first message and the last message. The push service 224 may further process such messages and allow the messages to be output at 1152, for example, on a user display, sent to the respective user, and updated for the respective views of the existing and new tags (e.g., in the feedback view of the session categorized by such tags).

In another embodiment, as shown in FIG. 11, the subject tag feature is incorporated into an existing session. For example, at 1115, a new message including an indication of the topic may be added to the existing session. Similar to the previously described process, at 1135, receiving a message including information indicative of a topic results in finding all participants in the session. The association between the topic and the conversation, as well as the association between the participant and the topic, may be stored in a database 260, such as conversation database 230, topic database 236, user database 234, group database 232, and email user database 237. At 1145, a lookup of other existing topic tags may be performed to determine if the topic is new, e.g., if multiple topic tags exist in and are associated with the session. At 1156, the messaging service 220, such as the push service 224, then pushes the message and the new topic tag corresponding to the new topic to the corresponding participant.

Examples of these techniques are illustrated by the user interface examples of fig. 12-13. FIG. 12 illustrates a feedback view 1208 of an example messaging application, providing a list 1215 of subject tags. In this example, the session 1201 includes a message "#tag-patent" that includes a topic beginning with a predetermined character "#". As described above, the predetermined character representing the theme may be any other special character, such as a% symbol. When the messaging service determines that the message includes a new topic based on determining that the message includes a predetermined character # and searching database 260, the session is added to a list of sessions associated with the new topic. Thus, when a corresponding topic tag is selected from feedback view 1208 via the UI of a messaging application (e.g., messaging application 240), current session 1201, as well as all other sessions associated with a new topic, can be easily viewed and organized by all participants of the session.

Fig. 13 further illustrates this concept, as well as the ability to categorize sessions according to topic. Here, the user has selected the theme tag "# tag-patent"1316 in the leftmost column 1315 of the UI 1300. This causes the messaging service to push a reduced version of each session that is related to the user and the selected topic. Selection of the topic tag "# tag-patent"1316 also causes the messaging service to push the content of the corresponding session to display the messages in the session in the rightmost region 1325 of the UI 1300. Those sessions are then displayed in feedback view 1308, while other irrelevant sessions are not displayed. The order of the topic labels displayed in the feedback view 1308 may be arranged according to user preferences, such as the priority or importance of each topic. Sessions associated with each topic tag can also be categorized based on one or more variables such as time, last received message, priority, user preference, etc. Also, each session includes multiple messages, and a user associated with a particular session can view the messages, send the messages, and add attributes (such as additional users, topics, groups, etc. discussed herein).

In various embodiments, a user may generate a session that includes one or more messages, which may include attributes. The message may be parsed and it is determined that the message includes a string indicating attributes such as user, topic, group, etc., based on the one or more messages being parsed. The attributes may be stored in at least one database as an association between information indicative of the subject and the session. In response to receiving an input from a messaging application (e.g., messaging application 240) indicating a selection of a topic, a messaging service (e.g., messaging service 220) sends at least a subset of sessions associated with the topic to the messaging application 240 for display.

In other embodiments, the messaging service may further determine that the topic is new by searching at least one database that includes information related to the topic and store information indicative of the topic in the at least one database based on the determination that the topic is new. In another example, the second message in the session may be parsed. It may be determined that the second message includes information identifying the second user and, thus, authorizing the second user to add the message to the session. Information indicative of the topic may be sent to one or more messaging applications operated by, for example, one or more other users, and the database may store multiple sessions in addition to multiple attributes (e.g., topics) associated with each session.

One or more features and functions can occur through the use of a messaging service that can include at least one database, at least one computing device in communication with the at least one database, and the at least one computing device configured to perform operations. Further, various aspects of processing may be split between messaging applications and messaging services. In some embodiments, it may be preferable for a messaging application (app) to perform operations, and in other embodiments, the same operations may be performed by a service.

In the feedback view 1308, a session may be initiated, such as by selecting an icon, such as a "start session" icon 1317. Unlike other messaging applications, sessions may be organized by topic, not just by user. The theme may be defined by the user at the beginning of the session. For example, a creator user initiating session 1301 may assign a topic to session 1301. Topics may also be defined by other participants at other stages of the session. The theme may be represented by using special characters or labels, such as "#" symbols. The creator user may then add other participants to the session, or may conduct the session separately.

In the "feedback" view 1308, one or more panels 1315, 1318, 1320 may be displayed. The panels may include an open (e.g., expanded) session panel 1318. Participants may communicate in an open session panel 1318, such as by entering a message in an input field 1304. The entered messages may appear as a log or feedback 1319 of the conversation 1301 (such as in the order in which they were sent, entered, or received). A timestamp may be displayed near a message in session 1301 to indicate the time that the message was sent, entered, or received. The user name of the participant who entered the message may appear next to the message in the conversation.

The panels may include a folded conversation panel 1320. Folded conversation panel 1320 may be adjacent to unfolded conversation panel 1318. Folded conversation pane 1320 may show previews 1321a, 1321b of the conversation, such as a first message of the conversation, a title of the conversation, a last message of the conversation, and/or a plurality of unread messages in the conversation.

Fig. 14-19 illustrate interactions between participants in the context of a group (e.g., a group of users), and various aspects of various techniques and embodiments in which messaging services and applications can categorize, organize, and export messages and sessions related to the group. It should be appreciated that fig. 14-19 are merely illustrative, and that groups may be created and sessions joined in other suitable manners.

Fig. 14 illustrates various aspects for inviting an existing or newly created group to join a session and creating a new group. At 1405, an existing or newly created group may be invited to join any session. By way of example and not limitation, as an attribute, a group including multiple members may be invited to join and authorized to participate in multiple sessions. The group attribute also allows the same session to have multiple group participants. In addition, the group participants of the session enable the content of the session to be pushed to all members of the group at once. Thus, the present messaging service provides greater flexibility and efficiency than existing messaging systems.

Participants to any session may invite a group by searching for a group name for the group. By way of example and not limitation, in response to receiving a user input indicating an invitation to a group to join a session, the messaging service stores an association between the group and the session in a database 260 (such as session database 230 and group database 232).

At 1406, information associated with the session may be recorded for all members of the group in a database 260, such as the group database 232 and the search index database 252. The information associated with the session may include messages in the session, attributes of the session, and any other information associated with the session. Information associated with the session may be sent to the push service 224.

At 1407, after the group is invited to participate in the session, at least a subset of the messages in the session are pushed to all members of the group. The message may be pushed by push service 224. Pushing messages may include sending messages to members, such as to their devices. Pushing the message may include causing the message to be displayed in a UI of a messaging application associated with the member.

Fig. 16 illustrates various aspects of a group view 1600 in a UI of a messaging application. In the group view 1600, the group to which the user belongs is displayed to the user. Fig. 16 lists 8 groups to which the user belongs. According to an embodiment, the groups are displayed in a list. The group display shows the attributes of the group and one or more selectable interface elements (e.g., selectable buttons "edit" and "delete"). The attributes include group names 1601. Fig. 16 shows group names including "group 1", "group 2", "group 3", and the like. The information associated with the group is sent to a messaging service (e.g., messaging service 220) and maintained by messaging service 220 in database 260 (e.g., group database 232, search index database 252, etc.).

Once the group is authorized to participate in the session, the association between the group and the session will be stored in database 260. For example, the messaging service 220 stores a thread Identification (ID) of the session and a group Identification (ID) of the group in the group database 232. By way of example and not limitation, the association between a group and a session may be identified based on the thread ID and the group ID of the session. The messaging service may generate a search index based on the information associated with the group and store the search index in a database 260, such as search index database 252. Associations between all members of a group and a session may be determined based on the search index and may be stored in database 260. Information associated with the group and members of the group may be retrieved from database 260 so that messages in the conversation may be sent to the messaging application for display associated with all members of the group (i.e., group participants of the conversation) based on the retrieved information.

After the group is invited to participate in the session (i.e., as a group participant), the identification information of the individual members of the group may not be sent to a messaging application associated with the participants of the session for display unless any particular individual member is invited to participate in the session or directly to participate in the session (e.g., to publish a message in the session) by other participants. If any particular individual member of the group is invited to join the session or directly participate in the session by other participants, sending identification information of the particular individual member to a messaging application associated with the participant of the session to display the identification information of the particular individual member; furthermore, a particular individual member may continue to participate in the session as an individual participant even after the group is removed from the session. Any other member of the group that is not invited to join the session or directly participate in the session by other participants will not receive any further messages in the session after the group is removed from the session or after a single member is removed from the group.

Members may be added to or removed from the group, as described further below. Upon receiving information indicating editing a group (e.g., adding or removing members), a messaging service (e.g., messaging service 220) updates databases 260 (e.g., group database 232 and search index database 252). Messaging service 220 searches database 260 to determine which members are currently included in the group and sends any messages in the session that the group participates in as a group participant to the members currently in the group. If any previous individual member of the group has been invited to the session or directly participated in the session by other participants before this individual member is removed from the group, then this previous individual member may continue to participate in the session as an individual participant; messaging service 220 may continue to send in-session messages to the previous person member that is currently the person participant.

The attributes of the group may include group privacy settings 1602. As shown in fig. 16, group "group 1" is private. Group "group 2" is also private. Privacy settings may also be maintained in a database 260, such as group database 232. For any private group, the private group is only accessible to members of the private group. Unlike private groups, public groups are not limited to members of a group. Instead, the public group is accessible to at least a subset of any participants of the session or other users registered with a messaging service (e.g., messaging service 220).

The attributes of the group may also include personnel 1603 (e.g., members of the group). Fig. 16 shows a "group 1" group having 10 members. "group 2" has three members. In the group view, members of each group may be represented by their profile picture, account header, user name, and/or handle, which may be maintained in a user device (such as user device 242) and/or in database 260 of messaging service 220, as examples.

The group view includes features for the user to manage his group. In addition to the features to create a new group as described above and particularly shown in fig. 15, the features may include an action 1605. Act 1605 includes an "edit" option that enables a user to change properties such as name, privacy settings, and members of a group (e.g., add or remove members). In response to the user selecting the edit option, a window, such as window 1203 similar to that in fig. 12, is displayed. The window includes options to add or remove members. Act 1605 may further include a "delete" option that enables the user to delete the group.

By way of example and not limitation, a new group may be created at 1401. The new group includes a plurality of members. The group may be created by a group service 251 of the messaging service 220. Messaging service 220 may also create a group ID for the new group. A group may be created based on user input. User input may be received via a group view of a UI of a messaging application, such as group view 1501 in fig. 15. The user may switch from the feedback view 1502 to the group view 1501. In the group view, participants to the session may select a "new group" icon 1507. In response to the user selecting icon 1507, a UI (e.g., window 1503) is displayed with an option for creating a new group. A new group may be created via the UI (e.g., window 1503).

Options include privacy settings 1504. Privacy settings 1504 are selected by selecting icon 1508 (such as a slidable icon or a switchable icon) with a privacy option. In an embodiment, the private group may not be searchable to other users across the messaging platform. In other embodiments, non-private groups are found and thus added to various sessions, associated with attributes, and the like.

The options include group name 1505. The group name 1505 is entered by entering a string of text in the input field 1509. As shown in fig. 15, a group name "patent team" is entered in the entry field 1509. Group name 1505 distinguishes the group from other groups. The group may be searched by group name 1505.

Options include users (i.e., members) 1506 in the group. Fig. 15 shows a patent team group with five members. The members 1506 in the group are invited (e.g., added) by searching for information identifying the members 1506. By way of example and not limitation, the information identifying the group member 1506 may include a user name associated with any member, an account in an entity associated with any member, an email address associated with any member, or a telephone number associated with any member. Upon receiving the identification information of the members of the group, messaging service 220 may store the identification information of the members in database 260 (such as group database 232 and search index database 252).

The member 1506 is added by entering a string of text in the input field 1510. For example, FIG. 15 shows a member searching for a member named "user C" to invite him to join a "patent team" group. The window shows the number 1511 of members that have been selected to invite to the group. The options selected in the window become the attributes and/or associations of the group.

The group may be canceled by selecting the cancel button 1507 in the UI. The group may be saved by selecting a "save" button 1508 in the UI. In response to the group being saved, the attributes and associations of the group may be saved to a database.

Referring back to fig. 14, at 1402, group information (e.g., attributes, associations) is recorded (e.g., saved, stored) to one or more databases 260, such as group database 232 in fig. 2. The group information may be recorded by the group service 251. Databases may include a session database 230, a group database 232, a user database 234, and/or a search index database 252.

At 1403, a search index is established for storing an index of search information. The search index may be established by the group service 251. The search index may operate in conjunction with other databases, such as a session database 230, a topic database 236, a group database 232, and a user database 234. The search index allows the messaging service to search for attributes (e.g., group attributes) associated with messages and sessions. The search index allows access permissions to be managed. Based on the search index, group members may access certain sessions and messages.

At 1404, information associated with the group may be output to a messaging application associated with the participant of the conversation for display. Outputting the group information may include sending an indication of the group to the participants, such as their devices. As shown in fig. 16, outputting the group information may include causing the group information to be displayed via a UI of the messaging application.

Fig. 17 illustrates an aspect 1700 for adding a new member to an existing group. At 1701, a new member is added to the existing group. In response to receiving the user input, a new member may be added to the existing group. The user may enter this input by selecting one of the icons in "edit" in the group view of the UI. A window may be displayed with a list of current members of the group. The user may search for the name of a user that is not a member of the group and choose to invite a new member to the group.

The group service 251 of the messaging service may add a new member to the existing group. The group service 251 may add new members based on receiving user input. The group service 251 may save the association of the new member with the group to one or more databases 260. As an example, database 260 may include session database 230, group database 232, user database 234, topic database 236, and/or search index database 252.

At 1702, a lookup of information associated with the group (such as an associated session, a subject tag, etc.) is performed. The group attributes include content of existing group members, etc. The lookup is performed by sending a query to one or more databases 260. Attributes will be imported for the new member. Importing the attributes may include saving the attributes locally, such as to a memory of the group service 251, and saving the new member attributes to the group database 232.

At 1703, the session associated with the group is output to the new member. These sessions may be output by the push service 224. Outputting the session may include sending a message to the new member (such as to the device of the new member) that is included in various sessions associated with the group. Outputting the session may include causing the session to be displayed to the new member via a UI of the messaging application.

At 1704, a member of the group is found. The members of the group may be found by the group service 251 and/or the push service 224. The members of the group may be found by querying database 260. The group service 251 may determine the members of the group and send an indication of the members to the push service 224.

At 1705, existing members of the group are notified of the determined members of the group. The member may be notified via the push service 224. The member may be notified that a new member has been added. Notifying the members may include sending notifications to the members, such as to their devices. Notifying the members may include causing the members of the group to be displayed to the members via a UI of a messaging application (such as in a group view).

In some embodiments, messaging service 220 and/or messaging application 240 may receive a message in a session that includes information specifying a group including a plurality of members. In response to receiving the information, the messaging service 220 can query the database 260 and send at least a subset of the messages in the conversation to the messaging application 240 associated with the members of the group to display at least a subset of the messages in the conversation. In an example, messaging service 220 and/or messaging application 240 may obtain information associated with members of the group by analyzing data associated with the group. In an example, the data associated with the group includes information of members and attributes of the group. In another example, the data associated with the group may further include at least a portion of the content of the session in which the group participates.

According to yet another aspect, a task associated with an expiration date may be created by one participant (the distributor user) and distributed to another participant (the distributed user) within the session. Fig. 18 and 19 illustrate techniques for distributing tasks associated with expiration dates within a session. The messaging service includes chat service 222. Chat service 222 may be provided by a device or program, such as in cloud computing network 100 in fig. 1. Chat service 222 enables users of messaging services to exchange messages in a session and/or to generate a session.

The chat service 222 initiates a task when it receives input from a user. In some embodiments, the task may be first edited by the dispatcher user via a messaging application (e.g., messaging application 240) and then the dispatcher user is invited to join the session in order to dispatch the task to the dispatcher user. In other embodiments, the editing of the task and inviting the dispatcher user to dispatch the task may be performed simultaneously on the same UI of a messaging application associated with the dispatcher user. Chat service 222 may receive input via a session (such as via an input field of the session in a UI of a messaging application on a user device).

To illustrate, fig. 19 shows a UI 1900 of a messaging application in a feedback view, where a user can enter input in an input field 1903. The user may be the creator user of the session, or other participants of the session. The input is a string of text. For example, in FIG. 19, user "user A" is entering a string of text "user B please conclude" for us. The text may describe the task. For example, the text of user a includes "please reach our conclusion", where the task is "reach conclusion". The text may include an indication of another user, such as the user to whom the task is assigned. For example, the text of user a includes the name of another user B. The user identified in the input may be a user registered with a messaging service (e.g., messaging service 220) and engaged in a session. The user identified in the input may not be an entity external to the messaging service (e.g., messaging service 220), such as an email participant of a conversation as will be described further below. In this example, user a is the distributor user and user B is the distributor user.

The input may include a date associated with the message. The date may be an expiration date for the task. The date may be the date on which a reminder for the task should be sent. The date may include a selection of an icon output via a UI of a messaging application on the user device. The icon may represent a calendar, such as icon 1601 in fig. 16.

Referring back to fig. 18, at 1802, allocation information is generated based on the input. Chat service 222 may generate assignment information. The assignment information may include associations between users assigned tasks, messages and/or tasks, and/or expiration dates. The assignment information is stored to one or more databases 260, such as task database 256, session database 230, and user database 234. Chat service 222 may store the assignment information.

At 1803, based on the assignment information, an assigner attribute and/or an assignee attribute is added to the session. Chat service 222 may add attributes. Adding attributes may include storing associations between distributor users, messages and/or tasks, expiration dates, and/or sessions. Attributes are stored in databases 260, such as session database 230, task database 256, user database 234, and group database 232.

According to an embodiment, a task has a state. The status is based on the expiration date of the task and/or attributes describing which completion stage the task is in. For example, when a task and/or expiration date is generated, the status may be set to "open", "incomplete", and/or "not verified". The descriptive attribute of the state may be a pre-populated selectable input in the UI, such as a list of selectable icons or columns of selectable icons. The descriptive attribute may be a string of text entered by the user, such as in an input field of a UI of the messaging application.

The distributor user and/or the distributor user may change state, such as to "closed", "completed", and/or "authenticated". The state may be changed based on whether the task has been completed. For example, if a task has completed, the state may be changed to "complete". The status is saved in database 260 in association with the task and/or expiration date. In response to the state change, the new state is saved to database 260. Messaging service 220 (e.g., chat service 222) may determine status, time stamp (e.g., verification time, last update time, etc.), and other information and store the status, time stamp, and other information in database 260 (e.g., task database 256). In response to the state change, a notification is sent to the user. According to an embodiment, the status is displayed to the dispatcher user, and/or a participant of the conversation, such as in a conversation in a UI of a messaging application displayed on the user device. Upon receiving information indicating the status and expiration date of the task, the messaging application may display the status and expiration date of the task.

At 1804, all participants in the session are found. Chat service 222 may find participants. Participants in a session may be determined by querying database 260. The participant may be sent to the push service 224 of the messaging service. The push service 224 may be a device or program of a messaging service.

At 1806, the status of the task is pushed to the determined participants of the session. The push service 224 may push the status. The push state may include transmitting a state to a device of the participant (e.g., user device 242). The push state may include a state in a UI display session via a messaging application (e.g., messaging application 240) on a user device (messaging application 242). The messaging service (e.g., messaging service 220) may update the status of the task upon receiving information (such as from the distributor user and the distributor user) indicating a change in expiration date or status of the task. The messaging service will then send information indicating the updated status of the task to the user device associated with the participant to display the updated status of the task.

According to an embodiment, the messaging service includes a reminder scheduler service 253. The alert scheduler service 253 may be a device or program of a messaging service. The reminder scheduler service 253 can access the database 260 of the messaging service. The reminder scheduler service 253 determines the assigned task, the session associated with the task, and one or more users associated with the task.

The user (e.g., user a) may enter an input indicating the reminder date. As shown in fig. 19, a user may enter an input indicating a date on which a reminder is to be sent via a UI 1900 of a messaging application. For example, user a selects date selection icon 1902. Based on the selection of the date selection icon 1902, a window 1901 with selectable dates is displayed. Window 1901 may represent a calendar showing days and months of the year. User a selects 28 days of the reminder date 2020, 4 months in window 1901. Based on the user entering the reminder date, the reminder scheduler service 253 of the messaging service 220 sends the reminder date to the database 260 and is stored in the database 260 in association with the task and/or expiration date, such as the task database 256 shown in FIG. 15.

The reminder scheduler service 253 can determine whether the status and/or expiration date of the task has changed. The reminder scheduler service 253 can determine whether the state of a task has changed and the expiration date has passed by querying the database 260 to determine the current descriptive attributes and/or expiration date assigned to the task. Based on the state changing to the "closed", "completed", and/or "verified" state, the reminder scheduler service 253 does not send a reminder. At 1811, the reminder scheduler service 253 sends reminders of tasks and/or expiration dates based on the status of the tasks not changing or remaining "on", "unfinished", or "unverified". A reminder is sent to the distributor user, another participant of the session. A message may be sent to the push service 224. An indication of the state change is sent to the push service 224.

At 1812, the push service 224 receives a message from the alert scheduler service 253. Messaging service 220 (e.g., push service 224) notifies and/or alerts the dispatcher user and/or the dispatcher user of expiration dates and/or tasks. The messaging service may also notify or alert other participants of the expiration date and/or task. The push service 224 notifies the distributor user, the distributed user, and other participants of the reminder and/or expiration date and/or status change of the task. According to some embodiments, the push service 224 notifies the participants by sending a message to a device associated with the user. According to one aspect, the push service 224 may send the reminder for a predetermined period of time (such as one week before the expiration date, two weeks before the expiration date, one day before the expiration date, one hour before the expiration date, etc.). The push service 224 may notify the participant by causing a reminder to appear in the UI output via the participant's device. The push service 224 may stop providing reminders based on the expiration date and/or the status of the task change. The features of the allocation and reminder tasks enable messaging services according to the present disclosure to provide more features than conventional messaging systems.

A user may respond to another user changing state. For example, the task is marked as "completed" for the assigner user, who responds by marking the task as "verified" to show that the user verifies that the task is completed. The distributor user may re-open the task marked as "complete," such as if the user finds that the task did not perform satisfactorily or determines that further work is needed. According to an embodiment, based on the status change, the expiration date and/or the color of the task or other indicator changes as displayed in the UI. Based on the state change, an indication of the change is sent, such as by the push service 224, to the participants of the session.

In some embodiments, messaging application 240 may receive information associated with a task in a session. The information includes an identifier for identifying the user (e.g., the assigner), the content of the task, and information indicating the date. Messaging application 240 may send information associated with the task to messaging service 220. Upon receiving the information from the messaging application 240, the messaging service 220 may send the information to the identified user (e.g., the assignees). The messaging application 240 may further receive updated information indicative of the status of the task and display the updated status of the task. The content of the task may include at least a portion of the content of the session.

According to an embodiment, messaging service 220 combines chat and email features with email integration features. FIG. 20 illustrates an example chat and email integration process for a messaging service. The messaging service according to the present disclosure enables integration of email and messaging services, which improves the efficiency of exchanging information. As shown, the messaging service (e.g., messaging service 220) includes a chat service 222. Chat service 222 may be a stand-alone service or incorporated as a feature of messaging service 220. Chat service 222 manages sessions in messaging service 220.

At 2002, chat service 222 receives input from, for example, a user device. In particular, the chat service 222 receives input in the form of messages via a messaging application operating on the user device (such as via an input field of a UI of the messaging application 240). Fig. 21 provides an illustration of an example UI that invites an email participant to join a session 2101 and enters a message for the email participant. To include external email participant a in session 2101, the user enters a message in the form of an external address, such as an email address. In the particular example UI 2100 illustrated in fig. 21, the user has entered an email address UserF@gmail.com 2105. Thus, the chat service parses the message and identifies it as an email address associated with an entity external to the messaging service (i.e., email participant a). The email address is further associated with email service 254. This example illustrates that the user has entered an email address that includes the field "gcai.com". Other embodiments may employ email aliases previously known to messaging services, e.g., represented by predefined characters.

Referring back to fig. 20, at 2008, chat service 222 stores an association of the email address and the conversation, such as in conversation metadata 230 and email user database 237. Once email participant a is invited and authorized to access the session, a messaging service (e.g., messaging service 220) may generate an identifier that identifies the session. The identifier may be used by an email service external to messaging service 220 to identify the conversation and associated with an email address of the email participant. In another example, messaging service 220 may generate an identifier for identifying a session to be used by an external email service before any email participants are invited to the session. The messaging service may send the identifier to an external email service associated with the email participant. By way of example and not limitation, the identifier used to identify the conversation may be a return email address corresponding to the conversation. The external email service may then send an email to a return email address associated with the session. In response to determining that the email is received from an email address associated with the conversation, the messaging service may generate a message based on the email and send the message to a messaging application (e.g., messaging application 240) associated with the participant of the conversation to display the message generated based on the email. On the other hand, in response to determining that the email is not from an email address associated with the conversation, the messaging service will ignore the email and/or send back a notification that inhibits sending the email to a return email address corresponding to the conversation.

Fig. 21 illustrates an example UI 2100 of a messaging application (e.g., messaging application 240). The UI 2100 may include a session 2101. Session 2101 may include an input field 2102. User input may be received via the input field 2102. Example inputs 2104 addressed to an email participant include content: "hello, external user F". Example inputs (i.e., messages in session 2101) 2104 include an email address: userF@gmail.com. Email addresses and content may be entered into the input field 2102.

At 2009, chat service 222 finds an existing participant in the session. The existing participants may be users of the messaging service and/or existing external email users. Chat service 222 finds participants based on session metadata. To this end, chat service 222 finds participants by querying user database 234 for users associated with the session and querying email user database 237 for users who are participants. After receiving an indication that an email participant has been added to the conversation, a subsequent message may be added to the conversation and an email message generated and sent to an email address associated with email participant a, as explained more fully below.

In some embodiments, messaging service 220 may generate an email message that includes information identifying email participant a (e.g., an email address associated with email participant a) upon receipt of the message in the conversation. The email message is generated in accordance with an email protocol associated with email service 254. The generated email message contains at least a subset of the received messages and an email address. In some embodiments, the generated email message may further include a return email address generated by messaging service 220 and corresponding to the conversation. In a further example, messaging service 220 may generate a plurality of return email addresses corresponding to a plurality of sessions. The generated email message may be sent by messaging service 220 (e.g., email service 254) to an external email service associated with the email address for delivery to the email inbox of email participant a. In other embodiments, the external email participant receives a single subsequent message or at least a subset of the subsequent messages. In other embodiments, all subsequent messages in the conversation are sent to external email participant a.

Chat service 222 sends the new message to push service 224 of the messaging application along with an indication of the participants of the conversation. At 2011, the push service 224 notifies existing participants of messages containing external email addresses. Informing the existing participants may include sending a message and/or an indication of an email address to the participants of the conversation. Informing the existing participants may include causing a message and/or email address to be displayed in the conversation.

The push service 224 may send an indication of the message to the email service 254 of the messaging application. Email service 254 may be a service that is part of a messaging service. In an embodiment, email service 254 formats one or more messages into the form of an email according to an email protocol such as SMTP. Thus, the email service may add an external email address associated with email participant a to the header field of the generated email message and add the message content to the body of the generated email message. Additionally, in an embodiment, email service 254 adds information in the email message indicating a conversation originating from the message content, such as a return email address corresponding to the conversation and generated by messaging service 220.

In particular, replies to email messages received by the messaging service, e.g., via email service 254, include information indicating the association of the conversation (e.g., a return email address corresponding to the conversation). The information associated with the reply may be pushed to a messaging application associated with the participant of the conversation to display at least one content of the reply to the email message. Thus, information added to an email message and also included in any reply to the email message (e.g., a return email address corresponding to the conversation) facilitates identifying the corresponding conversation in order to push information associated with the reply to the email message to a messaging application associated with a participant of the conversation.

As described above, one example of such an association is messaging service 220 (e.g., email service 254) generating a corresponding return email address associated with each session. By way of example, and not by way of limitation, a return email is generatedAn at least partially randomized text string may be included. For example, as shown in FIG. 22, the messaging service directionUserF@gmail.com2220 email participant sent a message with a return email address of calendar- kZNnYBkbywE@feishugroups.com2221 email. The return email address is associated with a particular session that originated a message to be sent to the external email address 2220, as shown in fig. 21. The return email address 2221 is added to the email header from the field of the email message. The reply to the return email address 2221 may then be used by a messaging service (e.g., messaging service 220) to associate the return email with the particular session.

Techniques may be used to prevent spoofing messaging services with reply emails and spam emails. For example, the return email address may be generated in the form of a random email address generator. In this example, return email address 2221 contains "kznybkbbywe" which is randomly selected and not easily predicted or spoofed. Thus, it helps reduce unwanted spam received by the conversation. In other examples, the email header may contain specific information for identifying the conversation, such as in a subject line or other header field. Such identifiers may contain random or unpredictable sequences of characters that may be used by a messaging service to assist in preventing or controlling spam. Any or all of the above data may be stored in a database, such as email message database 238, for later association and classification of reply email messages.

Thus, at 2013, email service 254 may send the formatted email message to an email address associated with email participant a. Sending the email message to the email address may include sending the email message to a domain associated with the email address. As described above, sending an email message to an email address may include sending other information from the conversation to the email address. Fig. 22 illustrates an email message received by an email participant (e.g., userF@gmail.com 2220). Thereafter, the email participant has prepared reply email 2222, including the text "hello". I have great happiness-! And send return email 2222 to a return email address associated with the messaging service and corresponding to the particular session.

Email service 254 may receive a reply to the message from the email address. The reply may be received by email service 254 at the generated return email address corresponding to the conversation. Email service 254 associates the return email address with the corresponding conversation, for example, using information contained in the return email, such as by querying database 260 (e.g., email message database 238) and determining the conversation with which the reply to the email message is associated. In an embodiment, messaging service 220 (e.g., email service 254) formats the reply into the form of a message and sends the message to push service 224 through chat service 222. The push service 224 may then send a message corresponding to the reply to a messaging application associated with the participant in the session. In some embodiments, the conversation may include other email participants (e.g., email participant B) in addition to email participant a. In this case, messaging service 220 may further generate an email message based on the message formatted by messaging service 220 and corresponding to the reply from email participant a; and messaging service 220 then sends the generated email message to the other email participants (e.g., email participant B).

Fig. 23 illustrates an example UI 2300 of a messaging application (e.g., messaging application 240). The UI 2300 may be the same or similar to the UI 2100 in fig. 21. UI 2300 includes continuation of the session from fig. 21. Based on receiving the reply email 2222 from the email address and the external email system (e.g., external email system 2200 in fig. 22), a messaging service (e.g., messaging service 220) may generate a message and add the message to the conversation and send the message to a messaging application associated with the participant of the conversation to display a message 2304 corresponding to the reply email 2222. In the example shown, an external email address UserF@email.com is displayed with the message 2304. Other metadata may also be displayed, such as the time at which a message was sent to a messaging application associated with a participant in the conversation.

In some embodiments, messaging application 240 may receive information entered by a user in a session. The information may include an email address and content to be sent to the email address. Messaging application 240 may then send the information to messaging service 220. Upon receiving the information, the messaging service 220 can send an identifier to an email service external to the messaging service 220 and associated with the email address for identifying the session and the content. In other embodiments, messaging service 220 may receive email from an external email service. In this case, messaging service 220 may determine that the email is associated with the conversation based on a determination that the email includes an identifier for identifying the conversation. The messaging service 220 may then generate a message including the content of the email and send the generated message to the messaging application 240 to display the generated message.

Fig. 24 illustrates an example process 2400 performed by a messaging application (e.g., messaging application 240) in accordance with the present disclosure. While described as a series of acts, one of ordinary skill in the art will appreciate that various embodiments may add, remove, reorder, or modify the acts depicted.

At 2402, messaging application 240 begins operating on a device (e.g., user device 242) associated with a user of a messaging service (e.g., messaging service 220). At 2404, messaging application 240 sends a request to messaging service 220 for information associated with a session (i.e., a message thread) to which the user relates. In some embodiments, the requested information includes metadata associated with the sessions, e.g., thread Identification (ID) corresponding to each of the sessions. The requested information further includes information indicating attributes associated with the session, such as a topic, user, group, task, etc. associated with the session. In other embodiments, the requested information may further include data indicating a summary of the session (e.g., a subset of the messages for each session). In an example, the subset of messages for each session may be the initial message and the final message in the session.

At 2406, the messaging application 240 receives the requested information and stores the requested information locally, for example, within the user device 242. In some embodiments, the received information, including the thread ID and attributes of the session, may be stored in local memory (e.g., browser cache). In other embodiments, the thread ID and attributes of the session may be stored in a local database. At 2408, message application 240 displays an indicator of the session. The indicator of the session may include a theme associated with the session that begins with a predetermined character (e.g., hash tag#). The indicator of the session may also include a user or group associated with the session beginning with another predetermined character (e.g., the @ symbol). The indicator of the session may further comprise a summary of the session.

Fig. 25 illustrates an example User Interface (UI) 2500 of the messaging application 240. In this example, indicators of sessions categorized by a topic (e.g., "patent" 2502) and categorized by a user (e.g., "user a" 2503) or group (e.g., "group 1" 2504) are displayed in the leftmost column 2506. The summary of the session is displayed in an area 2508 next to the leftmost column 2506. The task attributes of the session may also be displayed along with the summary of the session. For example, as shown in FIG. 25, a status 2512 of a task and a change 2514 in a task expiration date are displayed with summaries 2516 and 2518, respectively. It should be understood that the UI 2500 in fig. 25 is merely illustrative and that other display arrangements may be utilized.

Referring back to fig. 24, the messaging application 240 may receive user input indicating an indicator or summary of selecting a session among the plurality of sessions. Upon receiving the user input, at 2410, the messaging application 240 sends a request to the messaging service for a message in the selected session. The request includes the thread ID of the selected session. At 2412, the messaging application 240 receives the message for the selected session and displays the message for the selected session. By way of example and not limitation, the message for the selected session may be displayed in the rightmost region 2520 of the UI 2500 of the messaging application as shown in fig. 25. In an example, messaging application 240 may send a request for a plurality of messages in a session selected from a plurality of sessions having summaries. Message application 240 may then display the content received in response to the request, where the content is associated with the plurality of messages in the selected session.

Fig. 26 illustrates another example process 2600 performed by a messaging application (e.g., messaging application 240) in accordance with this disclosure. While described as a series of acts, one of ordinary skill in the art will appreciate that various embodiments may add, remove, reorder, or modify the acts depicted.

At 2602, the messaging application 240 receives an input indicating to start a new session. For example, the user may select a "new session" button 2526 in the UI 2500 as shown in fig. 25 to start a new session. In some embodiments, messaging application 240 may generate a thread ID for the new session. In other embodiments, the thread ID for the new session may be generated by messaging service 220 upon receiving information sent from messaging application 240 indicating the new session.

At 2604, the messaging application 240 receives another input from the user. In some embodiments, user input may be entered via windows 2702 and 2802 as shown in fig. 27 and 28. In response to a user input indicating to start a new session, messaging application 240 may cause a user device (e.g., user device 242) to overlay display window 2702 on UI 2700, as shown in fig. 27. The window includes a plurality of selectable interface elements.

Window 2702 includes representative symbols (e.g., an @ symbol 2704, # symbol 2706, and calendar icon 2708) corresponding to attributes to be associated with the new session. In an example, the user can select the @ symbol 2704 to add one or more participants (e.g., user a 2706 and group 1 2708) to the new session. In another example, the user may select the # symbol 2706 to add one or more topics (e.g., the topic "backlog" 2710) to the new session. The one or more topics may be any existing topics listed on the leftmost column of the UI 2700. In an example, an existing topic "backlog" 2710 is selected and added to the new session. In another example, upon selection of calendar icon 2708, calendar UI 2806 is displayed with selectable dates, as shown in fig. 28. In this example, the user selects the expiration date 2020, 7, 17 for the task assigned to the participant. Information indicating the task may be entered into the input field 2808 of window 2802.

In other embodiments, messaging application 240 may receive data indicative of a message entered by a user. Messages may be entered by a user (such as via input area 2522 of UI 2500 as shown in fig. 25) in a new or existing session.

At 2606, the messaging application 240 may determine that the user input includes information indicative of one or more attributes associated with the session. The messaging application 240 may determine that the user input indicates at least one attribute based on a determination that the input is associated with a predetermined character. For example, the messaging application 240 may determine that the user input includes information indicating an attribute (e.g., a topic, user, or group) based on identifying a predetermined character (e.g., #, @, or any other predetermined character). Each predetermined character (or characters) may represent an attribute, such as a theme, a user, or a group. In other embodiments, upon receiving information from messaging application 240, messaging service 220 may determine whether the user input includes one or more attributes associated with the session.

In an example, a text string beginning with a # symbol is determined as a topic associated with a conversation. In another example, a text string beginning with the @ symbol is determined to be invited to the user or group of the session. In yet another example, the messaging application 240 or the messaging service 220 may identify a structure of an email address, such as a text string (mailbox) + @ + field, to determine that the user input includes an email address associated with a session.

At 2608, messaging application 240 sends information to messaging service 220 indicating at least one attribute associated with the session. Upon receiving the information indicative of the attributes, the messaging service 220 stores the attributes to a corresponding attribute database associated with the thread ID of the session. The attribute may be a topic, user or group, email address, etc. associated with the session. In some embodiments where user input is provided by entering a message, messaging application 240 may also send the content of the message and metadata associated with the message to messaging service 220. The content of the message may be text, image, video, or audio content. The metadata may include a user ID (user used to create the message), a timestamp indicating the time the message was created, etc. Upon receiving the content and metadata of the message, messaging service 220 stores the content and metadata of the message to session (message thread) database 230.

Fig. 29 illustrates another example process 2900 performed by a messaging application (e.g., messaging application 240) in accordance with this disclosure. While described as a series of acts, one of ordinary skill in the art will appreciate that various embodiments may add, remove, reorder, or modify the acts depicted.

At 2902, the messaging application 240 receives input from a user. In an example, user input may be provided by selecting an "operator" option 2526 in the UI 2500 as shown in fig. 25. At 2904, in response to the user input, the messaging application 240 generates an interface based on the attributes of the session to which the user relates. At 2906, messaging application 240 further displays an interface through which the user may order the attributes of the session based on the priority of the session.

Unlike conventional messaging systems that organize messages in a single dimension, such as through the timing of messages, messaging service 220 and/or messaging application 240 according to the present disclosure may organize sessions in multiple dimensions. Alternatively, messaging application 240 may generate an interface that includes a two-dimensional representation associated with multiple sessions. Two dimensions in the two-dimensional representation are based on a first attribute associated with the plurality of sessions and a second attribute associated with the plurality of sessions. The messaging device may display an interface through which a user may provide input indicating reorganization of attributes associated with the plurality of sessions. The messaging device may reorganize the two-dimensional representation in response to receiving the input.

By way of example, and not limitation, FIG. 30 illustrates an interface 3000 comprising a two-dimensional table 3002. The two-dimensional table 3002 includes a vertical axis 3004 and a horizontal axis 3006. In an example, the vertical axis 3004 may list all or a subset of topics associated with a session to which the user relates; the horizontal axis 3006 may list all or a subset of the users or groups with which the user is in conversation (e.g., already mentioned in the conversation and beginning with the @ symbol, i.e., "mention"). In another example, the vertical axis may list all or some of the users or groups with whom the user is conversational, and the horizontal axis may list all or some of the topics associated with the conversation to which the user is related.

The user may reorganize the two-dimensional table 3002 by dragging a particular topic listed on the vertical axis 3004 or a particular mention listed on the horizontal axis 3006 and dropping the particular topic or mention into a different row or a different column. In an example, the two-dimensional table 3002 can be reorganized by the messaging application 240 based on the priority of the attributes associated with the session. The subject matter listed in the vertical axis 3004 and/or the references listed in the horizontal axis 3006 may be organized and displayed in any manner to reflect their respective priorities. By way of example and not limitation, the most important attribute may be moved to the upper left corner of the two-dimensional table 3002. In an example, the user may drag the topic (e.g., topic "holes") that is most important to the user and drop the topic "holes" on top of the vertical axis 3004. Similarly, the user may drag the most important mention to the user (e.g., mention of "boss") and drop the mention of "boss" at the leftmost cell of the horizontal axis 3006. The two-dimensional table 3002 may include a leftmost column 3008 and a top row 3010 with a change in gray or color indicating a decrease in importance of the properties listed from top to bottom and left to right, respectively. In another embodiment, the most important attribute may be moved to the lower right corner of the two-dimensional table 3002. The leftmost column 3008 and top row 3010 with gray or color changes may indicate increasing importance of the properties listed from top to bottom and left to right, respectively.

The two-dimensional table 3002 includes a plurality of cells (intersections) defined by columns and rows of the table 3002. Each cell in the two-dimensional table 3002 is a selectable button by which sessions can be filtered based on corresponding attributes (e.g., subject and mention attributes). Each intersection of the plurality of intersections is associated with one or more sessions having corresponding attributes. In an example, multiple unread sessions may be displayed in cells of the two-dimensional table 3002. For example, the number "2"3012 is displayed in cell 3014 indicating that there are two sessions with unread messages in the sessions with corresponding attributes (i.e., topic 1 3016 and user A3018). In another example, different cells may have different colors or any other suitable indicator. Different colors or other indicators included in a cell may indicate different states of tasks associated with a session having corresponding attributes.

In some embodiments, UI 3000 may include an "enable" button 3019 that may be switched between an enabled state and a disabled state of "operator" option 2526. In other embodiments, UI 3000 may further include slidable buttons 3018, 3020, 3022 for switching between enabled or disabled states of attributes (e.g., a theme (e.g., hash tag) attribute, a mention attribute, and a task status attribute). When the subject or mention attribute is disabled, the UI 3000 will include a one-dimensional table instead of the two-dimensional table 3002. If the task state attribute is disabled, the two-dimensional table 3002 will not indicate the state of the task by a different color or other means.

Referring back to fig. 29, at 2908, the messaging application 240 may overlay a two-dimensional representation of reduced size on another user interface. The two-dimensional table 3002, as shown in fig. 30, presents the user with useful information and attributes associated with the session and allows the user to reorganize the attributes of the session. However, the two-dimensional table 3002 may be relatively large, taking up too much screen space. Thus, in response to user input, messaging application 240 may provide a reduced-size version of two-dimensional table 3002. As shown in fig. 25, user input may be provided by selecting an icon 2530.

Fig. 31 illustrates a reduced-size version 3102 of the two-dimensional table 3002. As shown in fig. 31, the reduced size table 3102 is overlaid on another user interface 3104. Similar to the two-dimensional table 3002, the reduced-size table 3102 may include an indication of the number of unread sessions in a cell. The reduced size table 3102 may also have different colors in different cells to indicate different states of the associated task. Like the cells in the two-dimensional table 3002, each cell in the reduced-size table 3102 is also a selectable button by which sessions can be filtered based on the corresponding subject and mention attributes. The reduced size two-dimensional form allows the form to be overlaid on the UI so that a user can refer to the form when using the UI. The size of the decrease may be predetermined based on the screen size or defined by the user, for example, by directly selecting and adjusting the size of the form or by entering the size dimension in the form.

Referring back to fig. 29, at 2910, the messaging application 240 receives information indicating a selection of an intersection point in the two-dimensional representation. In an example, the user may select a cell in the two-dimensional table 3002 as shown in fig. 30. In another example, the user may select a cell in the reduced-size table 3102 as shown in fig. 31. At 2912, the messaging application 240 may filter the session in response to a selection of a cell in the two-dimensional table 3002 or the reduced-size table 3102. The messaging application filters the session based on the particular attribute corresponding to the selected cell. For example, in response to selection of a cell 3036 in the two-dimensional table 3002 or a cell 3106 in the reduced-size table 3102, the messaging application 240 filters the session based on the corresponding attributes (i.e., the subject "vulnerability" and reference "boss"). Fig. 32 illustrates the filtered results. By way of example and not limitation, summaries 3206, 3208, 3210, and 3212 of a session having the topic "vulnerability" 3202 and attributes referring to "boss" 3204 are displayed in UI 3200.

The foregoing aspects of the present disclosure have been described with respect to certain examples and embodiments, which are intended to illustrate, but not limit, the present disclosure. It should be appreciated that the subject matter presented herein may be implemented as a computer process, a computer controlled apparatus, or a computing system or article of manufacture, such as a computer readable storage medium.

Those skilled in the art will also appreciate that the subject matter described herein may be practiced with other computer system configurations, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, hand-held computers, personal digital assistants, electronic readers, cellular telephone devices, dedicated hardware devices, network devices, and the like, in addition to or in combination with other computer system configurations described herein. The embodiments described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

A network established by an entity such as a corporate or public sector organization that provides one or more services to a distributed set of clients that are accessible via the internet and/or other networks may be referred to as a provider network. Such provider networks may include multiple data centers hosting various pools of resources, such as a combination of physical and/or virtualized computer servers, storage devices, network equipment, etc., as needed to implement and distribute the infrastructure and services provided by the provider networks. In some embodiments, resources may be provided to clients in units called instances (such as virtual or physical computing instances or storage instances). For example, a virtual compute instance may include one or more servers with specified compute capabilities (which may be specified by indicating the type and number of CPUs, main memory size, etc.) and specified software stacks (e.g., a particular version of an operating system, which may operate on top of a hypervisor).

Many different types of computing devices may be used alone or in combination to implement resources and services in different embodiments, including general purpose or special purpose computer servers, storage devices, network devices, and the like. In at least some embodiments, a server or computing device implementing at least a portion of one or more techniques described herein, including techniques implementing the functionality of messaging service 220 and messaging application 240, may include a general purpose computer system including or configured to access one or more databases and/or computer-accessible media.

Fig. 33 illustrates such a general purpose computing device 3300. Computing device 3300 may operate in a virtual environment (such as environment 100 in fig. 1). Computing device 3300 may be used to host messaging services or messaging applications. Computing device 3300 may be configured to communicate with devices of users of messaging applications. Computing device 3300 may be a general purpose computing device. Computing device 3300 may be an internal device, such as a node of a distributed system running in a user's data center. Components of computing device 3300 can include, but are not limited to, one or more processors or processing units 3316, a system memory 3328, and a bus 3318 that couples various system components including the system memory 3328 to the processor 3316.

Bus 3318 in the example of FIG. 33 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include industry standard architecture ("ISA") bus, micro channel architecture ("MCA") bus, enhanced ISA ("EISA") bus, video electronics standards association ("VESA") local bus, and peripheral component interconnect ("PCI") bus.

Computing device 3300 may include a variety of computer system readable media. Such media can be any available media that is accessible by computing device 3300 and includes both volatile and nonvolatile media, removable and non-removable media. Computing device 3300 can include a system memory 3328 that can include computer-system-readable media in the form of volatile memory (such as random access memory ("RAM") 3330 and/or cache memory 3332). Computing device 3300 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, a storage system 3334 may be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and commonly referred to as a "hard disk drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (such as a "floppy disk"), and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (such as a CD-ROM, DVD-ROM, or other optical media) may be provided. In such cases, each may be connected to bus 3318 by one or more data medium interfaces. As will be further depicted and described below, the memory 3328 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

Computing device 3300 can include a program/utility 3340 having a set (at least one) of program modules 3342 that can be stored in memory 3328. Computing device 3300 of fig. 33 can also include an operating system, one or more messaging applications, other messaging application modules, and messaging application data. Each of the operating system, one or more messaging applications, other messaging application modules, and messaging application data, or some combination thereof, may include an implementation of a network environment, such as cloud computing system 100 in fig. 1. Program modules 3342 generally perform the functions and/or methods of embodiments of the invention as described herein.

Computing device 3300 of fig. 33 can also communicate with one or more external devices 3314 (such as a keyboard, pointing device, display 3324, or the like) to enable a user to interact with computing device 3300. Computing device 3300 may also include any device that enables computing device 3300 to communicate with one or more other computing devices, such as a network card, modem, and the like. Such communication may occur, for example, via the I/O interface 3321. Further, the computing device 3300 can communicate with one or more networks such as a local area network ("LAN"), a general wide area network ("WAN"), and/or a public network (such as the internet) via a network adapter 3320. As shown, the network adapter 3320 communicates with other components of the computing device 3300 via bus 3318. It should be appreciated that although not shown, other hardware and/or software components may be utilized in conjunction with computing device 3300. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

Each of the processes, methods, and algorithms described in the preceding paragraphs may be implemented in, and fully or partially automated by, code modules executed by one or more computers or computer processors. The code modules may be stored on any type of non-transitory computer readable medium or computer storage device (such as a hard disk drive, solid state memory, optical disk, etc.). The processes and algorithms may be implemented in part or in whole in dedicated circuitry. The results of the disclosed processes and process steps may be persistently or otherwise stored in any type of non-transitory computer memory, such as volatile or non-volatile memory.

The various features and processes described above may be used independently of one another or may be used in various combinations. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. Moreover, some methods or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the blocks or states associated therewith may be performed in other suitable orders. For example, the described blocks or states may be performed in an order different than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. Example blocks or states may be performed serially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added, removed, or rearranged as compared to the disclosed example embodiments.

It will also be appreciated that the various items are illustrated as being stored in memory or on a storage device when used, and that these items or portions thereof may be transferred between memory and other storage devices for purposes of memory management and data integrity. Alternatively, in other embodiments, some or all of the software modules and/or systems may execute in memory on another device and communicate with the illustrated computing system via inter-computer communication. Moreover, in some embodiments, some or all of the systems and/or modules may be implemented or provided in other ways, such as at least partially in firmware and/or hardware (including, but not limited to, one or more Application Specific Integrated Circuits (ASICs), standard integrated circuits, controllers (e.g., by executing appropriate instructions, and including microcontrollers and/or embedded controllers), field Programmable Gate Arrays (FPGAs), complex Programmable Logic Devices (CPLDs), etc.). Some or all of the modules, systems, and data structures may also be stored (e.g., as software instructions or structured data) on a computer-readable medium, such as a hard disk, memory, network, or portable media product, for reading by an appropriate drive or via an appropriate connection. The systems, modules, and data structures may also be transmitted as a generated data signal (e.g., as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission media, including both wireless-based and wire/cable-based media, and may take a variety of forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). In other embodiments, such computer program products may take other forms as well. Thus, the invention may be practiced with other computer system configurations.

Conditional language, such as "may," "might," "would," "may," "for example," and the like, as used herein, unless specifically stated otherwise or otherwise understood in the context of use, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that one or more embodiments require features, elements, and/or steps in any way or that one or more embodiments must include logic for deciding, with or without author input or prompting, whether these features, elements, and/or steps are included in or are to be performed in any particular embodiment. The terms "comprising," "including," "having," and the like are synonymous and are used inclusively in an open-ended fashion, and do not exclude additional elements, features, acts, operations, etc. Furthermore, the term "or" is used in its inclusive sense (rather than its exclusive sense) such that the term "or" means one, some, or all of the elements in a list when used, for example, to connect a series of elements.

Although certain example embodiments have been described, these embodiments are presented by way of example only and are not intended to limit the scope of the invention disclosed herein. Thus, the foregoing description does not imply that any particular feature, characteristic, step, module, or block is required or necessary. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions disclosed herein. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of certain inventions disclosed herein.

Claims (134)

1. A system, comprising:

at least one database; and

at least one computing device in communication with the at least one database, the at least one computing device configured to perform operations comprising:

receiving a plurality of messages in a first session;

determining that the user input in the first session includes information indicative of a topic; and

an association between the information indicative of the topic and the first session is stored in the at least one database.

2. The system of claim 1, wherein the operations further comprise:

in response to receiving input indicating selection of the topic from a messaging application associated with a first participant of the first session, at least a subset of the first session is sent to the messaging application for display of the at least a subset of the plurality of messages.

3. The system of claim 1, the operations further comprising:

determining that the topic is new by searching the at least one database, the at least one database including information related to the topic; and

based on determining that the topic is new, information indicative of the topic is stored in the at least one database.

4. The system of claim 1, the operations further comprising:

parsing a second message in the first session;

determining that the second message includes information identifying a user; and

authorizing the user to participate in the first session by accessing at least the plurality of messages in the first session.

5. The system of claim 4, further comprising:

the information indicative of the topic is sent to one or more messaging applications, wherein the one or more messaging applications include a second messaging application associated with the user that is authorized.

6. The system of claim 1, wherein the at least one database comprises a plurality of sessions including the first session, the at least one database further storing information associated with participants of the plurality of sessions and the plurality of topics as attributes associated with the plurality of sessions.

7. The system of claim 1, wherein the determining that the first message includes information indicative of a topic comprises: it is determined that the first message includes a predetermined character.

8. A system, comprising:

at least one database; and

At least one computing device in communication with the at least one database, the at least one computing device configured to perform operations comprising:

receiving input from a messaging application associated with a first participant of a first conversation, the input indicating a selection of a topic from a plurality of topics; and

transmitting at least a portion of the first session to the messaging application for displaying at least a subset of a plurality of messages in the first session,

wherein an association between the information indicative of the topic and the first session is stored in the at least one database.

9. The system of claim 8, wherein the operations further comprise:

a further session associated with the selected topic is sent to the messaging application for displaying at least a subset of the plurality of messages in the further session.

10. A method, comprising:

receiving a plurality of messages in a session;

determining that user input in the session includes information indicative of a topic; and

an association between the information indicative of the topic and the session is stored.

11. The method of claim 10, further comprising:

At least a subset of the plurality of messages is sent to a first user device associated with the first user in response to receiving input from the first user indicating a selection associated with the topic, to display the at least a subset of the plurality of messages in response to the input from the first user.

12. The method of claim 10, further comprising:

determining that a topic is new by searching a database that includes information related to the topic; and

upon determining that the topic is new, information indicative of the topic is stored in the database.

13. The method of claim 12, wherein the information indicative of the topic comprises the at least a portion of a string indicative of the topic.

14. The method of claim 10, further comprising:

determining that the second message includes information identifying a second user based on parsing the second message; and

the second user is authorized to access the session.

15. The method of claim 14, further comprising:

the information indicative of the topic is sent to a second user device associated with the second user for displaying an indication of the topic.

16. The method of claim 14, further comprising:

receiving a third message from the second user; and

the third message is added to the plurality of messages.

17. The method of claim 14, further comprising:

a notification is sent to the first user device indicating the authorization of the second user to access the plurality of messages.

18. The method of claim 10, further comprising:

the association between the session and a plurality of participants of the session is stored.

19. The method of claim 18, further comprising:

receiving a third message in the session;

identifying the plurality of participants of the session; and

the third message is sent to a plurality of user devices associated with the plurality of participants for display of the third message.

20. The method of claim 10, wherein a string includes an identifier for determining that the string indicates the topic.

21. A method, comprising:

receiving input from a messaging application associated with a first participant of a first conversation, the input indicating a selection of a topic from a plurality of topics; and

transmitting at least a portion of the first session to the messaging application for displaying at least a subset of a plurality of messages in the first session,

Wherein an association between the information indicative of the topic and the first session is stored in the at least one database.

22. The method of claim 21, further comprising:

a further session associated with the selected topic is sent to the messaging application for displaying at least a subset of the plurality of messages in the further session.

23. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed on a computing device, cause the computing device to at least:

receiving a plurality of messages;

determining that a first message of the plurality of messages includes a string indicating a topic based on the parsed first message; and

an association between at least a portion of the string indicating the topic and the plurality of messages is stored.

24. The non-transitory computer-readable storage medium of claim 23, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

in response to receiving input from a first user indicating a selection associated with the topic, at least a subset of the plurality of messages is sent to a first user device associated with the first user for display of the at least a subset of the plurality of messages in response to the input from the first user.

25. The non-transitory computer-readable storage medium of claim 23, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

determining that a topic is new by searching a database that includes information related to the topic; and

upon determining that the topic is new, information indicative of the topic is stored in the database.

26. The non-transitory computer-readable storage medium of claim 23, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

determining that the second message includes information identifying a second user based on parsing the second message; and

the second user is authorized to access the plurality of messages and one or more new messages are added to the plurality of messages.

27. The non-transitory computer-readable storage medium of claim 23, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

storing associations between the topic and a plurality of participants of a session associated with the topic;

Receiving a third message in the conversation associated with the topic; and

the third message and the topic are sent to a plurality of user devices associated with the plurality of participants, wherein a first user device associated with a first participant of the plurality of participants is configured to display only the third message and not the topic in response to determining that the first user device previously received any messages associated with the topic.

28. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed on a computing device, cause the computing device to at least:

receiving input from a messaging application associated with a first participant of a first conversation, the input indicating a selection of a topic from a plurality of topics; and

transmitting at least a portion of the first session to the messaging application for displaying at least a subset of a plurality of messages in the first session,

wherein an association between the information indicative of the topic and the first session is stored in the at least one database.

29. The non-transitory computer-readable storage medium of claim 28, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

A further session associated with the selected topic is sent to the messaging application for displaying at least a subset of the plurality of messages in the further session.

30. A system, comprising:

at least one database; and

at least one computing device in communication with the at least one database, the at least one computing device configured to perform operations comprising:

receiving a plurality of messages in a first session;

determining that user input in the first session includes information identifying a first group and authorizing the first group to participate in the first session, the first group including a plurality of users;

storing an association between the first group and the first session in the at least one database;

retrieving data associated with the first group from the at least one database based on the information identifying the first group, the data associated with the first group including information identifying the plurality of users in the first group; and

at least a subset of the first session is sent to a plurality of messaging applications associated with the plurality of users in the first group for displaying the at least a subset of the plurality of messages based at least in part on the retrieved data associated with the first group.

31. The system of claim 30, the operations further comprising:

the first session is associated with each user of the plurality of users in the first group based at least in part on a search index.

32. The system of claim 31, the operations further comprising:

the data associated with the first group is updated in response to receiving information indicating that the first user is added to or removed from the first group and information identifying the first user.

33. The messaging system of claim 30, the operations further comprising:

responsive to receiving a second message in a second session and determining that the second message includes information identifying the first group, authorizing the first group to participate in the second session; and

an association between the first group and the second session is stored in the at least one database.

34. The system of claim 33, the operations further comprising:

receiving information indicating that a second user is added to the first group and information identifying the second user; and

The data associated with the first group is updated.

35. The system of claim 34, the operations further comprising:

identifying the plurality of messages in the first session and a second plurality of messages in the second session by searching the at least one database; and

the plurality of messages in the first session and the second plurality of messages in the second session are sent to a messaging application associated with the second user.

36. The system of claim 34, the operations further comprising:

a notification is sent to the plurality of messaging applications associated with the plurality of users in the first group indicating that the second user is added to the first group.

37. The system of claim 30, wherein the information identifying the plurality of users in the first group comprises at least one of: a user name of a registered user, an account in an entity associated with one of the plurality of users, or an email address associated with one of the plurality of users associated with the one of the plurality of users.

38. The system of claim 30, wherein the data associated with the first group further comprises: information indicating that the first group is a private group, and wherein the private group is only accessible by a plurality of users in the private group.

39. A method, comprising:

receiving a plurality of messages in a first session;

determining that a first message in the first session includes information identifying a first group and authorizing the first group to participate in the first session, the first group including a plurality of users;

storing an association between the first group and the first session in the at least one database;

retrieving data associated with the first group from the at least one database based on the information identifying the first group, the data associated with the first group including information identifying the plurality of users in the first group; and

at least a subset of the first session is sent to a plurality of messaging applications associated with the plurality of users in the first group for displaying the at least a subset of the plurality of messages based at least in part on the retrieved data associated with the first group.

40. The method of claim 39, further comprising:

the first session is associated with each user of the plurality of users in the first group based at least in part on a search index.

41. The method of claim 40, further comprising:

the data associated with the first group and the search index is updated in response to receiving information indicating that the first user is added to or removed from the first group and information identifying the first user.

42. The method of claim 39, further comprising:

responsive to receiving a second message in the second session and determining that the second message includes information identifying the first group, authorizing the first group to participate in a second session; and

an association between the first group and the second session is stored in the at least one database.

43. The method of claim 39, further comprising:

receiving information indicating that a second user is added to or removed from the first group and information identifying the second user; and

The data associated with the first group is updated.

44. The method of claim 43, further comprising:

identifying the plurality of messages in the first session and a second plurality of messages in the second session by searching the at least one database; and

the plurality of messages in the first session and the second plurality of messages in the second session are sent to a messaging application associated with the second user.

45. The method of claim 39, further comprising:

based on a determination that a third user has actively engaged in the first session or has been invited to the first session by another user before the third user is removed from the first group, it is determined to send any new messages to the third user that has been removed from the first group.

46. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed on a computing device, cause the computing device to at least:

receiving a plurality of messages in a first session;

determining that a first message in the first session includes information identifying a first group and authorizing the first group to participate in the first session, the first group including a plurality of users;

Storing an association between the first group and the first session in the at least one database;

retrieving data associated with the first group from the at least one database based on the information identifying the first group, the data associated with the first group including information identifying the plurality of users in the first group; and

at least a subset of the first session is sent to a plurality of messaging applications associated with the plurality of users in the first group for displaying the at least a subset of the plurality of messages based at least in part on the retrieved data associated with the first group.

47. The non-transitory computer readable storage medium of claim 46, further storing computer readable instructions that, when executed on the computing device, cause the computing device to at least:

generating a search index based on the information identifying the plurality of users in the first group; and

the first session is associated with each user of the plurality of users in the first group based at least in part on the search index.

48. The non-transitory computer readable storage medium of claim 46, further storing computer readable instructions that, when executed on the computing device, cause the computing device to at least:

responsive to receiving a second message in the second session and determining that the second message includes information identifying the first group, authorizing the first group to participate in a second session; and

an association between the first group and the second session is stored in the at least one database.

49. The non-transitory computer readable storage medium of claim 48, further storing computer readable instructions that, when executed on the computing device, cause the computing device to at least:

receiving information indicating that a first user is added to the first group and information identifying the first user;

identifying the plurality of messages in the first session and a second plurality of messages in the second session by searching the at least one database; and

the plurality of messages in the first session and the second plurality of messages in the second session are sent to a messaging application associated with the first user.

50. A system, comprising:

at least one database; and

at least one computing device in communication with the at least one database, the at least one computing device configured to perform operations comprising:

receiving a plurality of messages in the session, the plurality of messages including a first message sent from a first messaging application associated with a first user;

determining that the first message includes information identifying a second user;

receiving information indicating a date associated with the first message; and

an association between at least the first message, the second user, and the date is stored in the at least one database.

51. The system of claim 50, the operations further comprising:

based at least in part on the date associated with the first message, a reminder is sent to a second messaging application associated with the second user that the date is still valid in the at least one database.

52. A system as defined in claim 50, wherein the first message indicates a task assigned by the first user to the second user.

53. The system of claim 52, wherein the date associated with the first message comprises an expiration date of the task.

54. The system of claim 53, the operations further comprising:

determining a status of the task based at least in part on the expiration date of the task; and

information indicating the status of the task and the expiration date is sent to a plurality of messaging applications associated with a plurality of participants of the session for displaying the status of the task and the expiration date.

55. The system of claim 54, the operations further comprising:

receiving information from the first messaging application or the second messaging application indicating a change to the expiration date or the status of the task; and

the state of the task is updated based on the information indicating the expiration date or the change to the state of the task.

56. The system of claim 55, the operations further comprising:

information indicative of the updated state of the task is sent to the plurality of messaging applications for displaying the updated state of the task.

57. The system of claim 56, the operations further comprising:

Sending the alert to at least the second messaging application based on at least one of: the status of the task, the expiration date of the task, or receiving information indicating a reminder date.

58. The system of claim 50, the operations further comprising:

the first message and the information indicating the date associated with the first message are sent to a plurality of messaging applications associated with a plurality of participants of the session for displaying the first message and the date associated with the first message.

59. A method, comprising:

receiving a plurality of messages in a session maintained by a messaging service, the plurality of messages including a first message sent from a first messaging application associated with a first user;

determining that the first message includes information identifying a second user;

receiving information indicating a date associated with the first message; and

an association between at least the first message, the second user, and the date is stored in at least one database.

60. The method of claim 59, further comprising:

Information indicating that the date is still valid in at least one database is sent to a second messaging application associated with the second user.

61. The method of claim 59, wherein the first message indicates a task assigned by the first user to the second user.

62. The method of claim 59 wherein the date associated with the first message includes an expiration date of the task.

63. The method of claim 62, further comprising:

determining a status of the task based at least in part on the expiration date of the task; and

information indicating the status of the task and the expiration date is sent to a plurality of messaging applications associated with a plurality of participants in the session for displaying the status of the task and the expiration date.

64. The method of claim 63, further comprising:

sending a reminder to the first messaging application and the second messaging application based on at least one of: the status of the task, the expiration date of the task, or receiving information indicating a reminder date.

65. The method of claim 63, further comprising:

receiving information from the first messaging application or the second messaging application indicating a change to the expiration date or the status of the task; updating the status of the task based on the information indicating the expiration date or the change to the status of the task; and

information indicative of the updated state of the task is sent to the plurality of messaging applications for displaying the updated state of the task.

66. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed on a computing device, cause the computing device to at least:

receiving a plurality of messages in a session maintained by a messaging service, the plurality of messages including a first message sent from a first messaging application associated with a first user;

determining that the first message includes information identifying a second user;

receiving information indicating a date associated with the first message; and

an association between at least the first message, the second user, and the date is stored in at least one database.

67. The non-transitory computer readable storage medium of claim 66, further storing computer readable instructions that, when executed on the computing device, cause the computing device to at least:

based at least in part on the date associated with the first message, a reminder is sent to a second messaging application associated with the second user that the date is still valid in the at least one database.

68. The non-transitory computer-readable storage medium of claim 66, wherein the first message indicates a task assigned by the first user to the second user, and wherein the date associated with the first message includes an expiration date of the task.

69. The non-transitory computer readable storage medium of claim 68, further storing computer readable instructions that, when executed on the computing device, cause the computing device to at least:

determining a status of the task based at least in part on the expiration date of the task; and

information indicating the status of the task and the expiration date is sent to a plurality of messaging applications associated with a plurality of participants of the session for displaying the status of the task and the expiration date.

70. A system, comprising:

at least one database; and

at least one computing device in communication with the at least one database, the at least one computing device configured to perform operations comprising:

receiving a first input in a session;

determining, based on the parsed first input, that the first input includes information indicative of a first email address;

generating a first identifier for identifying the session; and

the first identifier is sent to a first external email service associated with the first email address.

71. The system of claim 70 wherein the first identifier is a first return email address corresponding to the session.

72. The system of claim 71, wherein the first return email address comprises an at least partially randomized text string.

73. The system of claim 70, the operations further comprising:

a first set of data is received from the first external email service, the first set of data including the first email address and the first identifier.

74. The system of claim 73, the operations further comprising:

Determining that the first set of data is associated with the session based on the first identifier included in the first set of data; generating a second message based on the first set of data; and sending the second message to a plurality of messaging applications associated with a plurality of participants of the session for display of the second message.

75. The system of claim 70, the operations further comprising:

an association between the first email address and the conversation is stored in the at least one database.

76. The system of claim 70, the operations further comprising:

a notification is sent to a plurality of messaging applications associated with a plurality of participants of the conversation, the notification indicating the first email address associated with a first external entity participating in the conversation.

77. The system of claim 70, the operations further comprising:

receiving a third message from a first messaging application associated with a first participant of the conversation, the third message including information identifying the first email address;

generating a first email message according to a first email protocol, the first email message comprising the first email address, the content of the second message, and the first identifier; and

The first email message is sent to the first external email service associated with the first email address for delivery to a first email inbox.

78. The system of claim 77, the operations further comprising:

receiving a second set of data from the first external email service, wherein the second set of data includes the first identifier, information indicating a reply to the third message, and content of the reply;

determining that the second set of data is associated with the session based on the first identifier included in the second set of data;

generating a fourth message based on the second set of data; and

the fourth message is sent to a plurality of messaging applications associated with a plurality of participants of the session for display of the fourth message.

79. The system of claim 78 wherein a second external entity associated with a second email address has been authorized to participate in the conversation.

80. The system of claim 79, the operations further comprising:

generating a second email message according to a second email protocol, the second email message comprising the second email address, the content of the fourth message, and a second identifier for identifying the session by a second external email service associated with the second email address, wherein the second identifier is generated by the messaging service; and

The second email message is sent to the second external email service associated with the second email address for delivery to a second email inbox.

81. A method, comprising:

receiving a first message in a session;

determining that the first message includes information indicating a first email address;

storing an association between the first email address and the session in at least one database;

generating a first identifier for identifying the session; and

the first identifier is sent to the first external email service associated with the first email address.

82. The method of claim 81, wherein the first identifier is a first return email address corresponding to the session.

83. The method of claim 81, further comprising:

receiving a first set of data from the first external email service, wherein the first set of data includes the first identifier;

determining that the first set of data is associated with the session based on the first identifier included in the first set of data;

generating a second message based on the first set of data; and

The second message is sent to a plurality of messaging applications associated with a plurality of participants of the session for display of the second message.

84. The method of claim 81, further comprising:

receiving a third message from a first messaging application associated with a first participant of the conversation, the third message including information identifying the first email address;

generating a first email message according to a first email protocol, the first email message comprising the first email address, the content of the second message, and the first identifier; and

the first email message is sent to the first external email service associated with the first email address for delivery to a first email inbox.

85. The method of claim 84, further comprising:

receiving a second set of data from the first external email service, wherein the second set of data includes the first identifier, information indicating a reply to the third message, and content of the reply;

determining that the second set of data is associated with the session based on the first identifier included in the second set of data;

Generating a fourth message based on the second set of data; and

the fourth message is sent to a plurality of messaging applications associated with a plurality of participants of the session for display of the fourth message.

86. The method of claim 85 wherein a second external entity associated with a second email address has been authorized to participate in the session, and wherein the method further comprises:

generating a second email message according to a second email protocol, the second email message comprising the second email address, the content of the fourth message, and a second identifier for identifying the conversation; and

the second email message is sent to the second external email service associated with the second email address for delivery to a second email inbox.

87. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed on a computing device, cause the computing device to at least:

receiving a first message in a session;

determining that the first message includes information indicating an email address associated with an email participant;

Storing an association between the email address and the conversation in at least one database;

generating, by an external email service associated with the email address, an identifier for identifying the conversation; and

the identifier is sent to the external email service associated with the email address.

88. The non-transitory computer-readable storage medium of claim 85, wherein the identifier is a first return email address corresponding to the conversation.

89. The non-transitory computer readable storage medium of claim 85, further storing computer readable instructions that, when executed on the computing device, cause the computing device to at least:

receiving a set of data from the external email service, wherein the set of data includes the identifier;

determining that the set of data is associated with the session based on the identifier included in the first set of data;

generating a second message based on the first set of data; and

the second message is sent to a plurality of messaging applications associated with a plurality of participants of the session for display of the second message.

90. A system, comprising:

a message thread database comprising a plurality of conversations;

a plurality of attribute databases including attributes associated with the plurality of sessions; and

at least one computing device in communication with the message thread database and the plurality of attribute databases, the at least one computing device configured to perform operations comprising:

receiving a plurality of messages in a first session of the plurality of sessions;

storing the plurality of messages in the message thread database;

receiving user input in the first session;

determining that the user input includes at least one attribute associated with the first session;

storing information in at least one of the plurality of attribute databases based on the determination of the type of the at least one attribute; and

an association between the at least one attribute and the first session is stored.

91. The system of claim 90, wherein the message thread database includes metadata and content associated with each of the plurality of sessions.

92. The system of claim 91, wherein the message thread database further comprises: a thread identification associated with each of the plurality of sessions, at least one message identification of at least one message included in each of the plurality of sessions, and the at least one message included in each of the plurality of sessions.

93. The system of claim 92, wherein the content of the at least one message comprises text data, video content, or audio content.

94. The system of claim 90, wherein the plurality of attribute databases includes at least one of: a first attribute database storing information indicative of topics associated with the plurality of sessions, a second attribute database storing information of users associated with the plurality of sessions, a third attribute database storing information of groups associated with the plurality of sessions, a fourth attribute database storing information indicative of task assignments associated with the plurality of sessions, or a fifth attribute database storing information associated with one or more email addresses included in the plurality of sessions.

95. The system of claim 90, wherein each of the plurality of attribute databases further comprises a plurality of thread identifications corresponding to the plurality of sessions for identifying one or more attributes associated with each of the plurality of sessions.

96. The system of claim 90, the operations further comprising:

Updating the at least one of the plurality of attribute databases based on the new message; and

information associated with the new message is sent to one or more messaging applications associated with the first session.

97. The system of claim 90, the operations further comprising:

receiving a request from a first messaging application indicating at least one of the plurality of sessions;

querying the message thread database based on information indicative of the at least one of the plurality of sessions;

processing the query results to determine at least a subset of messages in said at least one of said plurality of sessions; and

in response to the request, the at least a subset of the messages in the at least one of the plurality of sessions is sent to the first messaging application.

98. The system of claim 90, the operations further comprising:

receiving a request from a second messaging application associated with at least one of the plurality of sessions;

querying the plurality of attribute databases based on the request;

processing the query results to determine that at least one attribute is associated with the at least one of the plurality of sessions; and

Information indicative of the at least one attribute is sent to the second messaging application for displaying at least one indicator of the at least one attribute.

99. The system of claim 98, the operations further comprising:

receiving an input indicating a selection of the at least one indicator of the at least one attribute associated with the at least one of the plurality of sessions;

querying the message thread database based on the input; and

a plurality of messages in the at least one of the plurality of sessions are identified and sent for display.

100. A method, comprising:

receiving a plurality of messages in a first session of a plurality of sessions, wherein a session database includes the plurality of sessions and a plurality of attribute databases includes attributes associated with the plurality of sessions;

storing the plurality of messages in the session database;

receiving user input in the first session;

determining that the user input includes at least one attribute associated with the first session;

storing information in at least one of the plurality of attribute databases based on the determination of the type of the at least one attribute; and

An association between the at least one attribute and the first session is stored.

101. The method of claim 100, further comprising:

receiving a request from a first messaging application indicating at least one of the plurality of sessions;

querying the session database based on information indicative of the at least one of the plurality of sessions;

processing the query results to determine at least a subset of messages in said at least one of said plurality of sessions; and

in response to the request, the at least a subset of the messages in the at least one of the plurality of sessions is sent to the first messaging application.

102. The method of claim 100, further comprising:

receiving a request from a second messaging application associated with at least one of the plurality of sessions;

querying the plurality of attribute databases based on the request;

processing the query results to determine that at least one attribute is associated with the at least one of the plurality of sessions; and

information indicative of the at least one attribute is sent to the second messaging application for displaying at least one indicator of the at least one attribute.

103. The method of claim 102, further comprising:

receiving an input indicating a selection of the at least one indicator of the at least one attribute associated with the at least one of the plurality of sessions;

querying the session database based on the input; and

a plurality of messages in the at least one of the plurality of sessions are identified and sent for display.

104. The method of claim 100, wherein the session database comprises: a thread identification associated with each of the plurality of sessions including at least one message, at least one message identification of the at least one message included in each of the plurality of sessions, and content of the at least one message included in each of the plurality of sessions.

105. The method of claim 100, wherein each of the plurality of attribute databases further comprises a plurality of thread identifications corresponding to the plurality of sessions for identifying one or more attributes associated with each of the plurality of sessions.

106. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed on a computing device, cause the computing device to at least:

receiving a plurality of messages in a first session of a plurality of sessions, wherein a session database includes the plurality of sessions and a plurality of attribute databases includes attributes associated with the plurality of sessions;

storing the plurality of messages in the session database;

receiving a new message in the first session;

parsing the new message to determine that the new message includes at least one attribute associated with the first session;

storing information in at least one of the plurality of attribute databases based on the determination of the type of the at least one attribute; and

an association between the at least one attribute and the first session is stored.

107. The non-transitory computer-readable storage medium of claim 106, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

receiving a request from a first messaging application indicating at least one of the plurality of sessions;

Querying the session database based on information indicative of the at least one of the plurality of sessions;

processing the query results to determine at least a subset of messages in said at least one of said plurality of sessions; and

in response to the request, the at least a subset of the messages in the at least one of the plurality of sessions is sent to the first messaging application.

108. The non-transitory computer-readable storage medium of claim 106, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

receiving a request from a second messaging application associated with at least one of the plurality of sessions;

querying the plurality of attribute databases based on the request;

processing the query results to determine that at least one attribute is associated with the at least one of the plurality of sessions; and

information indicative of the at least one attribute is sent to the second messaging application for displaying at least one indicator of the at least one attribute.

109. The non-transitory computer-readable storage medium of claim 106, wherein the session database includes: a thread identification associated with each of the plurality of sessions, and content of one or more messages included in each of the plurality of sessions, and each of the plurality of attribute databases further includes a plurality of thread identifications corresponding to the plurality of sessions for identifying one or more attributes associated with each of the plurality of sessions.

110. A computing device, comprising:

at least one processor; and

at least one memory communicatively coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the client computing device to:

receiving a first input from a user interface indicating to start a first session;

receiving a second input of the first user;

determining that the second input indicates at least one attribute associated with the first session; and

information is sent to a messaging service, the information including information indicating a start of a new session and information indicating that the at least one attribute is associated with the first session.

111. The computing device of claim 110, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

sending a request for information to the messaging service;

storing received information in response to the request, the received information including information indicative of a plurality of attributes associated with a plurality of sessions,

wherein each session of the plurality of sessions has a corresponding thread ID; and

A plurality of indicators associated with the plurality of sessions are displayed based on the received information.

112. The computing device of claim 111, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

sending a request for a plurality of messages in a second session selected from the plurality of sessions; and

content received in response to the request is displayed, the content being associated with the plurality of messages in the second session.

113. The computing device of claim 110, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

transmitting a request for information indicating the plurality of sessions;

a summary for at least some of the plurality of sessions is displayed based on the received information.

114. The computing device of claim 110, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

An interface is generated based on attributes of a second plurality of sessions, wherein the interface includes a two-dimensional representation associated with the second plurality of sessions, wherein two dimensions in the two-dimensional representation are based on a first attribute associated with the second plurality of sessions and a second attribute associated with the second plurality of sessions.

115. The computing device of claim 114, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

displaying the interface through which a second user provides input indicating reorganization of attributes associated with the second plurality of sessions; and

reorganizing the two-dimensional representation in response to receiving the input.

116. The computing device of claim 114, wherein at least one intersection in the two-dimensional representation comprises:

an indicator indicating a status of at least one task associated with at least one session of the second plurality of sessions; or (b)

Indicating a number of sessions in the second plurality of sessions having unread messages.

117. The computing device of claim 114, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

Receiving information indicating a selection of an intersection point in the two-dimensional representation; and

in response to receiving the information, the second plurality of sessions is filtered based on attributes corresponding to the selected intersection points.

118. The computing device of claim 110, wherein the second input is provided by selecting an existing indicator of the at least one attribute.

119. The computing device of claim 110, wherein the second input is provided by entering a message comprising a predetermined character indicating a type of the at least one attribute.

120. The computing device of claim 110, wherein the at least one attribute comprises at least one of: a topic attribute, a user attribute, a group attribute, a task attribute, or an email message attribute.

121. The computing device of claim 110, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

based on a determination that the second input is associated with a predetermined character, it is determined that the second input indicates at least one attribute.

122. The computing device of claim 110, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

In response to receiving the third input, a third user interface is displayed, wherein the third user interface includes information associated with at least one group participating in one or more sessions.

123. The computing device of claim 110, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

receiving messaging in the first session;

determining that the message includes information identifying a second user;

receiving information indicating a date associated with the message; and

the message is sent to a messaging service along with the information indicating the date associated with the message, wherein the message indicates the task assigned to the second user.

124. The computing device of claim 110, the at least one memory further storing instructions that, when executed by the at least one processor, cause the client computing device to:

the status of the task associated with a third session of the plurality of sessions is displayed.

125. A method, comprising:

receiving a first input from a user interface indicating to start a first session;

Receiving a second input of the first user;

determining that the second input indicates at least one attribute associated with the first session; and

transmitting information to a messaging service, the information comprising information indicating a start of a new session and information indicating that the at least one attribute is associated with the first session, wherein the messaging service stores the at least one attribute associated with a thread Identifier (ID) of the first session in at least one database.

126. The method of claim 125, further comprising:

sending a request for information to the messaging service;

storing received information in response to the request, the received information including information indicating a plurality of attributes associated with a plurality of sessions, wherein each session of the plurality of sessions has a corresponding thread ID; and

a plurality of indicators associated with the plurality of sessions are displayed based on the received information.

127. The method of claim 126, further comprising:

sending a request for a plurality of messages in a second session selected from the plurality of sessions; and

content received in response to the request is displayed, the content being associated with the plurality of messages in the second session.

128. The method of claim 125, further comprising:

transmitting a request for information indicating the plurality of sessions; and

a summary for at least some of the plurality of sessions is displayed based on the received information.

129. The method of claim 125, further comprising:

an interface is generated based on attributes of a second plurality of sessions, wherein the interface includes a two-dimensional representation associated with the second plurality of sessions, wherein two dimensions in the two-dimensional representation are based on a first attribute associated with the second plurality of sessions and a second attribute associated with the second plurality of sessions.

130. The method of claim 129, further comprising:

receiving information indicating a selection of an intersection point in the two-dimensional representation; and

in response to receiving the information, the second plurality of sessions is filtered based on attributes corresponding to the selected intersection points.

131. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed on a computing device, cause the computing device to at least:

receiving a first input from a user interface indicating to start a first session;

Receiving a second input of the first user;

determining that the second input indicates at least one attribute associated with the first session; and

transmitting data to a messaging service, the data comprising information indicating a start of a new session and information indicating that the at least one attribute is associated with the first session, wherein the messaging service stores the at least one attribute associated with a thread Identifier (ID) of the first session in at least one database.

132. The non-transitory computer-readable storage medium of claim 131, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

sending a request for information to the messaging service;

storing received information in response to the request, the received information including information indicating a plurality of attributes associated with a plurality of sessions, wherein each session of the plurality of sessions has a corresponding thread ID; and

displaying a plurality of indicators for the plurality of sessions based on the received information.

133. The non-transitory computer-readable storage medium of claim 132, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

Sending a request for a plurality of messages in a second session selected from the plurality of sessions; and

content received in response to the request is displayed, the content being associated with the plurality of messages in the second session.

134. The non-transitory computer-readable storage medium of claim 131, further storing computer-readable instructions that, when executed on the computing device, cause the computing device to at least:

an interface is generated and displayed based on attributes of a second plurality of sessions, wherein the interface includes a two-dimensional representation associated with the second plurality of sessions, wherein two dimensions in the two-dimensional representation are based on a first attribute associated with the second plurality of sessions and a second attribute associated with the second plurality of sessions.

Images