JP2023535173A - messaging service - Google Patents

Abstract

A messaging system can receive multiple messages during a conversation. It can be determined that one or more of the messages contain information indicative of the topic. Information indicative of topics and associations with conversations can be stored in a database. An input can be received that indicates a topic selection. In response to receiving this input, at least a subset of the conversation, eg, one or more of the messages, can be sent to the messaging application. A messaging application can display a subset of conversations. [Selection drawing] Fig. 5

Description

Interactions in the workplace and social settings are increasingly conducted using Internet-based tools. Internet-based tools can be any software or platform. Traditional communication tools such as email can facilitate internal and external communication. However, conventional communication tools may not be able to meet user needs due to various restrictions. With the increasing sophistication of communication equipment, new tools are continually being discovered to improve the efficiency and effectiveness of communication.

The following detailed description is better understood when read in conjunction with the accompanying drawings. For purposes of explanation, illustrative embodiments of various aspects of this disclosure are shown in the accompanying drawings, but the invention is not limited to the specific methods and instrumentalities disclosed.

1 illustrates an example of a cloud computing network capable of running messaging services; FIG.

1 illustrates an example messaging system according to the present disclosure; FIG.

1 illustrates an example of a messaging technique that may be implemented by a messaging service and messaging applications/services; FIG.

1 illustrates an example of a messaging technique that may be implemented by a messaging service and messaging applications/services; FIG.

FIG. 2 illustrates an exemplary data model usable in accordance with this disclosure;

FIG. 3 illustrates an exemplary process that may be performed by a messaging service consistent with this disclosure;

FIG. 4 illustrates another example process that may be performed by a messaging service consistent with this disclosure;

1 illustrates an example of a messaging technique that may be implemented by a chat service and a push service of messaging services; FIG.

[0014] FIG. 4 illustrates an exemplary user interface of a messaging application that includes conversations;

FIG. 3 shows an exemplary user interface of a messaging application that includes conversations;

FIG. 2 illustrates an example technique for adding topics to a conversation;

FIG. 10 illustrates an example user interface for a messaging application that allows adding topic tags to conversations.

FIG. 3 shows an exemplary user interface of a messaging application that allows conversations to be sorted by topic tags.

FIG. 3 shows an exemplary technique for creating groups and inviting members;

FIG. 10 illustrates an example user interface of a messaging application that allows new groups to be created;

FIG. 3 illustrates a group view within a messaging application user interface that can display users within a group.

FIG. 4 shows an exemplary technique for adding new members to an existing group;

FIG. 1 illustrates an exemplary technique for assigning and managing tasks using a messaging service;

FIG. 12 illustrates an example user interface of a messaging application that allows scheduling reminder dates;

FIG. 1 shows an exemplary technique for integrating email and messaging services;

FIG. 10 illustrates an example user interface of a messaging application that allows adding email addresses to conversations.

FIG. 2 shows an example of an email message received at an email address and sent from a messaging service;

FIG. 3 illustrates an example user interface for a messaging application that allows messages sent from an email address to be displayed with corresponding conversations.

FIG. 3 illustrates an example process that may be performed by a messaging application consistent with this disclosure;

FIG. 3 illustrates an exemplary user interface of a messaging application consistent with this disclosure;

FIG. 4 illustrates another example process that may be performed by a messaging application consistent with this disclosure;

[0014] Fig. 4 illustrates an exemplary user interface of a messaging application for creating a new conversation in accordance with this disclosure;

FIG. 10 illustrates another exemplary user interface of a messaging application for creating a new conversation in accordance with this disclosure;

FIG. 2 illustrates an example process that may be performed by a messaging application consistent with this disclosure;

FIG. 10 illustrates an exemplary user interface for a messaging application that is generated based on attributes of a conversation and that allows a user to provide input to reorganize the conversation.

FIG. 10 illustrates another example user interface of a messaging application with a two-dimensional representation overlaid on another user interface;

FIG. 12 illustrates another example user interface for a messaging application in which conversations are filtered according to selection of intersections in a two-dimensional representation;

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

FIG. 1 is a diagram illustrating exemplary components of a cloud computing system 100. As shown in FIG. By way of example, and not limitation, cloud computing system 100 may be used to implement 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 can be divided to some extent between clients and cloud computing devices. A “cloud” can refer to a service or group of services accessible via a network (eg, the Internet), eg, by clients, server devices, and other cloud computing systems.

In one example, multiple cloud-connected computing devices can access and use a shared pool of computing power, services, applications, storage, and files. Cloud computing thus allows a shared pool of composable computing resources, such as networks, servers, storage devices, applications, and services, that can be provided and released by cloud service providers with minimal administrative effort or interaction. enable

As an example, a cloud-based application may store a copy of data and/or executable program code on the cloud computing system and, if necessary for execution on the client device, copy this data and program code by the client device. may allow the download of at least a portion of the In some instances, the downloaded data and program code may be tailored according to the capabilities of the particular client device (e.g., personal computer, tablet computer, mobile phone and/or smart phone) accessing the cloud-based application. is possible. Additionally, by splitting application execution and storage between the client device and the cloud computing system, the processing power of the cloud computing system is reduced, as it allows the cloud computing system to perform more processing. and functions can be used effectively.

Cloud-based computing is also a distributed computing architecture in which data and program code for cloud-based applications are shared in near real-time among one or more client devices and/or cloud computing devices. can point to Portions of this data and program code can be dynamically distributed 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 users of client devices. By way of example, and not by way of limitation, a PC user device accessing a cloud-based application may assume that the PC downloads program logic and/or data from the cloud computing system or that the PC transfers processing or storage functions to the cloud computing system. without knowing that you are offloading to

In FIG. 1, a cloud computing system 100 comprises one or more cloud services 104, one or more cloud platforms 106, cloud infrastructure components 108, and a cloud knowledge base 110. In FIG. Cloud computing system 100 may include more or fewer components, each of cloud service 104, cloud platform 106, cloud infrastructure component 108, and cloud knowledge base 110 further comprising multiple computing elements and storage. can contain elements. Accordingly, one or more of the aforementioned functions of cloud computing system 100 may be divided into additional functional or physical components or combined into fewer functional or physical components. In some other examples, additional functionality and/or physical components may be added to the example shown in FIG. The delivery of cloud computing-based services may involve multiple cloud components communicating with each other through application programming interfaces such as web services and multi-tier architectures.

The exemplary cloud computing system 100 shown in FIG. 1 is a network 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 client interface front end. Cloud platform 106 can be coupled to cloud service 104 to perform functions for interacting with client devices. Cloud infrastructure 108 may include services, payments, and other operational and infrastructure components of cloud computing system 100 . As cloud knowledge base 110 is configured to store data used by cloud computing system 100, cloud knowledge base 110 may be any of cloud services 104, cloud platform 106, and/or cloud infrastructure components 108. is accessible by

Many different types of client devices, such as those of messaging service users, may communicate with components of cloud computing system 100 to access data and run applications provided by cloud computing system 100 . can be configured. For example, computer 112 , mobile device 114 , and host 116 are shown as examples of the types of client devices that can be configured to communicate with cloud computing system 100 . Of course, more or fewer client devices may communicate with cloud computing system 100 . Additionally, other types of client devices may be configured to communicate with cloud computing system 100 .

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

In FIG. 1, communication links between client devices and cloud 100 may comprise wired connections, such as serial or parallel buses, Ethernet, optical connections, or other types of wired connections. Communication links may also refer to wireless links, such as Bluetooth®, IEEE 802.11 (IEEE 802.11 may refer to IEEE 802.11-2007, IEEE 802.11n-2009, or any other IEEE 802.11 revision). ), CDMA, 3G, GSM, WiMAX, or other radio-based data communication link.

In other examples, client devices may be configured to communicate with cloud computing system 100 via wireless access points. Access points can take various forms. For example, an access point can take the form of a wireless access point (WAP) or wireless router. As another example, when a client device connects using a cellular air interface protocol such as CDMA, GSM, 3G, or 4G, the access point is a base station within the cellular network that provides Internet connectivity over the cellular network. can be

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

FIG. 2 shows an exemplary messaging service 220 for performing the disclosed techniques. By way of example, and not limitation, messaging service 220 may operate on cloud network 100 of FIG. 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 program running on the device of messaging service 220 .

Chat service 222 may be configured to receive input from user 210 . Users 210 may register as users of messaging service 220 in order to exchange messages with each other within messaging service 220 . User 210 may be a user of messaging application 240 running on user device 242 . User input may include a request to initiate a conversation. A conversation may be initiated by selecting a “Start Conversation” icon within the user interface (UI) of messaging application 240 running on any user device 242 . A conversation can be initiated by the creator user without any other participants in the conversation being identified. Conversation participants include any entity that is permitted to participate in the conversation in any way. For example, a conversation participant can be a creator user, a group invited to join the conversation, an assigner user who can assign a task to another participant (assignee user), an assignee user, a conversation e-mail participants invited to

Chat service 222 can generate and/or manage conversations. For example, chat service 222 can categorize conversations. Chat service 222 includes 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, and email message database 238. can store conversations, any associations with conversations, and/or conversation metadata. Inputs can include messages, such as messages to add to an existing conversation or a new conversation. Chat service 222 can add messages to the conversation. Chat service 222 may store messages and/or message associations in a database, such as conversation database 230 .

The messaging service 220 can determine that the message includes information that identifies the user, such as username, handle (ie, username beginning with @), account, and the like. Messaging service 220 can add the identified user to the conversation. Messaging service 220 may store user-conversation associations in conversation database 230, group database 232, user database 234, and/or search index database 252, for example. A user may be granted access to a conversation, for example, to view a feed of messages previously communicated within the conversation.

Messaging service 220 can determine that the message includes information indicative of the topic. Topics can be associated with corresponding conversations. Messaging service 220 may add topics to one or more databases, such as topic database 236 . Messaging service 220 may store topic-conversation associations in conversation database 230 and/or topic database 236, for example.

Messaging service 220 can determine that the message includes information identifying the group. A group may be a user group. The messaging service 220 can add groups to conversations. Messaging service 220 may store associations of groups and conversations in conversation database 230, group database 232, user database 234, and/or search index database 252, for example.

The messaging service 220 can determine that the message contains information indicating the tasks assigned to the user. The messaging service 220 can also receive information indicating due dates for tasks. Tasks and due dates can be associated with users and conversations. Messaging service 220 may add tasks and due dates to database 260 , eg, task database 256 . Messaging service 220 can store task, due date, user and conversation associations in conversation database 230, user database 234, and task database 256, for example.

Messaging service 220 may determine that the message may include an email address. An email address can be associated with the conversation. The email address may be the intended recipient of messages in conversation. The messaging service 220 can add email addresses to conversations. Messaging service 220 may store the association of email addresses with conversations in conversation database 230, email user database 237, and/or email message database 238, for example.

Messaging service 220 may include push service 224 . Push service 224 may be a device and/or program running on the device of messaging service 220 . Push service 224 may receive data, such as user input instructions, from chat service 222 . Push service 224 may store data in and/or access data in database 260 . Push service 224 can push (eg, transmit, display, etc.) data, such as user-input instructions, to the user device, eg, via messaging application 240 . Push service 224 can push data to email addresses outside of messaging service 220 .

Messaging service 220 may include other services. Other services may include group services 251 . Group service 251 can manage user groups. Group services 251 can manage stored group associations. The group service 251 can 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 the association of due dates with tasks. A reminder/scheduler service 253 can send reminders associated with due dates and/or tasks. The reminder/scheduler service 253 can manage stored due dates and/or tasks.

Other services may include email service 254 . Email service 254 can generate email messages and send email messages to email addresses outside of messaging service 220 . Email service 254 can receive data from email addresses external to messaging service 220 . The e-mail service 254 can determine the conversation associated with data received from the e-mail address and generate a corresponding message to be sent to the users in the conversation. Other services may further include authentication services 226 . Authentication service 226 can authorize and verify access to various conversations. The authentication service 226 can grant tiered privileges to conversation participants. For example, only participants with a certain level of authority are allowed to add other participants, assign tasks, etc.

It should be appreciated that the messaging service 220 of FIG. 2 is merely exemplary and that other implementations may be used. It should also be understood that the functionality disclosed herein may be implemented by one or more servers or computing devices. Furthermore, it should be understood that the functionality disclosed herein can be implemented in software, hardware, or a combination of software and hardware.

FIG. 3 shows an example messaging service 220 . Messaging service 220 may communicate with network 301 . Network 301 may include the Internet. Network 301 may include one or more cloud network components. Network 301 may communicate with one or more databases 260 over the network. Database 260 may be the same as or similar to databases 230-238 of FIG. By way of example, databases 260 may include topic databases, conversation databases, user databases, and/or tag databases. Messaging service 220 may store attributes and/or associations in database 260 . Messaging service 220 may access (eg, query) database 260 for attributes, associations, or other data.

Messaging service 220 may communicate with one or more user devices 242 over network 301 . Messaging service 220 may communicate with device 302 via messaging application 240 running on user device 242 . 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 can communicate with users 210 connected via network 301 . A connected user 210 may be a user who is a participant in a conversation of messaging service 220 and/or messaging application 240 . For example, connected user 210 can receive messages associated with the conversation via an external email address. Connected users 210 can send messages to messaging service 220, messaging application 240, conversations, and/or other users from external email addresses.

FIG. 4 shows messaging technique 400 . Technology 400 may include a messaging service (eg, messaging service 220 of FIGS. 2 and 3), a messaging application (eg, messaging application 240 of FIGS. 2 and 3), one or more users 210, and/or one or more It can be performed by multiple user devices 242 . At 401, a conversation can be initiated. A conversation can be initiated by an author user (ie, the user who causes the creation of the conversation) by entering input requesting initiation of the conversation via the messaging application. For example, a user may select a "Start a conversation" icon in the UI of a messaging application displayed on the user device. A chat service (eg, chat service 222 of FIG. 2) can receive input and generate conversations. A conversation can begin without any other participants in the conversation being identified.

At 402, a message can be entered. Messages can be put in by users via messaging applications. Messages can be entered into conversations, for example, via input fields displayed on the UI of the messaging application. This message can be entered before any other participants in the conversation are identified. A message can contain text. A chat service can receive messages. This message can be added to the conversation. A message can be sent to one or more users associated with the conversation. This message can be sent to one or more external users, eg, external email addresses that have been added to the conversation. Associations between messages and conversations can be stored in a database (eg, database 260 of FIGS. 2-3).

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

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

At 405 , attributes of the message can 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 . Associations between attributes and message content can also be stored in the attribute database and any other database. For example, as shown in FIGS. 2-3, attributes and/or associations can be stored in database 260 by messaging service 220 .

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

In contrast to most messaging systems based on direct exchanges between users, in some embodiments, messaging systems (e.g., messaging services and messaging applications) according to the present disclosure are more message-centric, where messages are content and the user is an attribute of the content. For example, the techniques of this disclosure need not identify recipients or subscribers of a conversation. Instead, the messaging system allows a conversation, e.g., a series of messages, to be created by a creator user (e.g., the user who initiates creation of the conversation) without any other participants being identified. do. Conversation participants are the creator users, not just the recipients. Author users can post messages, label conversation topics, add other participants to the conversation, assign tasks to other participants, and so on.

After creating a conversation, other participants can be added to the conversation. Unlike most messaging systems where conversation participants are defined at the beginning of the conversation, our messaging system allows participants to join the conversation at any time. Participants can join an existing conversation by including the username, group name, or email address of a user of the messaging service within the conversation. Participants can then receive past and future messages, such as feeds or notifications, that are added to and conveyed within the conversation. Added participants participate in the conversation by, for example, posting messages within the conversation, labeling topics of the conversation, assigning tasks, and/or adding other participants to the conversation. can do.

FIG. 5 is a diagram illustrating an exemplary embodiment of a data model consistent with this disclosure. It should be appreciated that the exemplary data model of FIG. 5 is merely exemplary and that other configurations can be used. As shown, the data model is conversation-centric. In other words, conversations are the primary data in the database. Other data such as user data, topic data, task data are attributes of the conversation. As shown, the messaging service conversation database 230 includes a plurality of conversations. Conversation database 230 includes multiple tables. For example, thread table 502 , message table 504 , and content table 506 are all stored in conversation database 230 .

Thread table 502 includes items such as Thread_ID, User_ID, and Created_Time. Thread_ID is the primary key that references other data and attributes. For example, Thread_ID is used to look up messages associated with a particular Thread_ID. The Thread_ID is also used to look up attributes in the attribute database associated with the thread identified by the Thread_ID, as described more fully below. Before describing the attribute database, the records stored in the conversation database 230 will be described in greater detail.

For conversation database 230, each time a new thread (e.g., a new conversation) is created by a user, the message service generates and assigns a new Thread_ID, the User_ID of the user who created the thread, and the time the thread was created (Created_Time ) to create a new record in the thread table. Additionally, information associated with each message within a particular thread (e.g., a particular conversation) includes the Thread_ID, User_ID (for the user who created the message), Message_ID identifying each message, the time the message was created (Created_Time ), and an entry (Is_Mentioned) identifying other users or groups that may have been mentioned and added during the conversation. A user or group mentioned (eg, starting with an @ symbol) during a conversation is referred to below as a "mention." The content of each message is stored separately in content table 506 and can be referenced by the corresponding message ID. This is because the stored size of a message can vary greatly depending on whether the message is a short string or contains some form of media such as JPEG or video.

As previously mentioned, each thread (conversation) can have attributes associated with it. These attributes are referenced by the conversation's Thread_ID. For example, Thread_ID is a key included in each attribute database and can be used to look up all attributes associated with a particular conversation. As shown in Figure 5, the user is an attribute of the conversation. The users associated with a particular conversation can be determined by searching the user database 234 for all users associated with a particular Thread_ID corresponding to the particular conversation. The search returns all matching User_IDs.

Similarly, a search of the e-mail message database 238 returns all User_IDs of users associated with the thread via e-mail. That is, each time an email address is added to a conversation, a new record is created in email message database 238 . Each record stores the User_ID of the user who added the email address in the conversation. Additionally, a Return_Email address corresponding to the conversation is assigned by a messaging service (eg, messaging service 220 ) and stored in email message database 238 . Each email participant (participant added by email address) is assigned a Mail_Box_User_ID that can be used to look up the associated Email_Address. The e-mail address is stored with the Message_ID of the message containing this e-mail address. The message content of each e-mail message is also stored in the e-mail message database 238 (e.g., e-mail attribute tables 522, 520).

The attribute database further includes, for example, a group database (eg, group database 232). Group database 232 stores information (eg, group attributes) about groups associated with conversations. The data stored in the group database 232 includes one or more of Thread_ID, Group_ID, Created_Time (the time the group was created). Group_ID includes Group_Name (group name), Owner_User_ID (group owner, e.g. User_ID of the creator of the group), group type (private or public group, etc.), join time (time when a member joined the group), and association with the group. Also used to indicate the record containing the state

In one embodiment, the attribute database includes a task database (eg, task database 256) that stores information (eg, task attributes) indicative of task assignments associated with conversations. Task attributes stored in the task database 256 are also referenced by the Thread_ID of each conversation. Some of the data and information stored in the task database 256 includes due dates (effectively due dates), assignee and assignee user IDs (Assignor_User_ID and Assignee_User_ID), and states (eg, status). be Created time, verified time, and last updated time can also be associated with records stored for a task.

According to one embodiment, the attribute database further includes a topic database (eg, topic database 236) that stores information (eg, topic attributes) indicative of topics associated with the conversation. The topic database is referenced by each conversation's Thread_ID, is associated with the conversation, and generally includes the user ID, Topic_ID, and time created associated with each topic. Topic_ID is used to refer to the topic name (Topic_Name). Each time a new topic is added to a conversation, e.g., by an entry into a message that begins with a hashtag within the conversation, the messaging service (e.g., messaging service 220) stores an entry in topic database 236 referenced by the conversation's Thread_ID. do.

As noted above, all of these various attributes are associated with a Thread_ID that is generated when a new thread (eg, new conversation) is created in a messaging service (eg, messaging service 220). Accordingly, the messaging service 220 can retrieve and retrieve various attributes associated with conversations. Conversation and thread are used somewhat interchangeably herein. In one example, message thread database 230 and multiple attribute databases (eg, topic database 236, task database 256, group database 232, email message database 238, and user database 234) can be stored on the same server or device. is. In another example, message thread database 230 and multiple attribute databases may each be stored on a different server or device. The message thread database 230 and multiple attribute databases can be hosted on one or more physical servers or one or more virtual servers.

FIG. 6 shows an exemplary process 600 performed by a messaging service (eg, messaging service 220) in relation to the data model shown in FIG. Although illustrated as a series of acts in FIG. 6, those of ordinary skill in the art will appreciate that the described acts may be added, removed, reordered, or modified in various embodiments.

At 602 , messaging service 220 receives a request from a messaging application, eg, messaging application 240 running on user device 242 , indicating at least one of the conversations. For example, a user may be requesting information through messaging application 240 indicating attributes associated with one or more conversations in which the user is participating. For example, messaging application 240 running on user device 242 may request information indicating attributes (eg, topics, users, groups, tasks) associated with conversations for the user. In response to this request, at 604 the messaging service 220 looks up all Thread_IDs associated with the user's User_ID in the user database 234 and also queries other attribute databases to identify threads based on these Thread_IDs. Determine various attributes associated with the spoken conversation. In one example, the messaging service 220 can look up all topics in the topic database associated with the Thread_ID. At 606, messaging service 220 processes the query results to determine that at least one attribute (eg, topic attribute) is associated with at least some of the conversations.

At 608 , messaging service 220 transmits attribute information associated with the conversation to messaging application 240 for displaying an indicator of the attribute on user device 242 . For example, as shown in FIG. 12, multiple topics associated with a conversation are displayed in the leftmost column 1205 of a user interface (UI) 1200. In FIG. In some embodiments, multiple attributes may exist and may be assigned different priorities by messaging service 220 or messaging application 240 . Messaging service 220 or messaging application 240 may organize attributes based on their priority. In one example, the mention (ie user or group added to the conversation) attribute may have higher priority than the topic attribute. For example, the mention attributes in FIG. 25 (eg, UserE 2501 and Group1 2504) can be assigned higher priority than topic attributes. The attribute indicators in FIG. 25 are displayed based on the mention attribute and can display one or more topics (if any) under the mention attribute. In one example, multiple topics may be associated with a conversation with a particular mention attribute. As shown in FIG. 25, a conversation having a mention attribute UserE 2501 is associated with multiple topics (including a topic "patent" 2502), and in this example, the mention attribute has higher priority than the topic attribute. Since it is high, multiple topics are displayed under the mention attribute UserE2501.

In some embodiments, in response to receiving a request from messaging application 240, messaging service 220 queries database 260 (e.g., user database 234, task database 256, etc.) to associate any particular user. can determine the tasks to be performed. For example, messaging service 220 receives a request from messaging application 240 that includes identifying information for a particular user (eg, user ID). In response, messaging service 220 searches user database 234 based on the user ID to identify the Thread_ID corresponding to the conversation in which the user is engaged. Messaging service 220 can then query task database 256 based on the Thread_ID to look up the task associated with the conversation. Messaging service 220 may identify the Assignor_User_ID and Assignee_User_ID for each task based on searching task database 256 . The messaging service 220 then determines whether any of the tasks are associated with the particular user based on determining whether the identified Assignor_User_ID or Assignee_User_ID is the same as the particular user's user ID. It is possible to determine whether or not 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 for display of the tasks associated with the particular user. In one example, messaging application 240 can sort or order tasks based on due dates associated with the tasks. In another example, messaging application 240 can sort or order tasks based on information associated with the assignee or assignee of the task. The messaging application 240 can cause the categorized or ordered tasks to be displayed within a predetermined area of the UI or in a window overlaid on the UI.

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

FIG. 7 illustrates another example process 700 that illustrates interactions between a messaging application (eg, messaging application 240) and a data model maintained in messaging service 220. As shown in FIG. Although illustrated as a series of acts in FIG. 6, those of ordinary skill in the art will appreciate that the described acts may be added, removed, reordered, or modified in various embodiments. In another embodiment, messaging service 220 receives a request at 702 from a messaging application associated with a user (eg, messaging application 240 running on user device 242) to indicate at least one of the conversations. In response, messaging service 220 queries message thread database 230 at 704 . For example, the messaging service 220 looks up corresponding conversations in which the user has already participated. The messaging service 220 then processes 706 the query results to determine a subset of messages within each conversation. In one embodiment, the subset of messages in each conversation may be the first and last messages in the conversation. Messaging service 220 can create a summary of each conversation based on a subset of messages. At 708, messaging service 220 sends a subset of the messages to messaging application 240 to display a summary of each conversation. For example, as shown in FIG. 12, a conversation summary is displayed in middle area 1216 of UI 1200 .

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

FIG. 8 is a diagram illustrating a messaging technique. A technology may be a messaging service (eg, messaging service 220 of FIGS. 2 and 3), a messaging application (eg, messaging application 240 of FIGS. 2 and 3), one or more users 210, and/or one or more can be performed by the user device 242 of At 801, a conversation can be initiated. A conversation can be initiated by an author user by entering input requesting the initiation of a conversation via a messaging application. For example, a user may select a "Start a conversation" icon within the UI of a messaging application displayed on the user device. A chat service of the messaging service (eg, chat service 222 of FIG. 2) can receive input and generate conversations. A conversation can be initiated by the creator user without any other participants in the conversation being identified.

At 802, when a message is received via messaging service 220, such as chat service 222, a lookup can be performed for all participants in the conversation (eg, the creator user and any other participants). can. The content of the message can be determined. The content can be parsed by a messaging service 220 such as chat service 222 . Analyzing the content can include determining one or more attributes of the message and/or conversation. For example, content may include text consisting of predetermined special characters representing attributes such as topics, users, and/or user groups. This lookup can be performed by messaging service 220 , eg, chat service 222 . This lookup can be performed by querying one or more databases 260 . Databases 260 may include conversation database 230 , group database 232 , user database 234 , topic database 236 , task database 256 , email user database 237 , and/or email message database 238 . The association of participants with conversations may be stored in database 260 by chat service 222, for example.

At 803, topics associated with the conversation can be determined. Topics may be determined by messaging service 220 , eg, chat service 222 . The messaging service 220 can parse the message and determine that the message contains information indicative of the topic based on identifying predetermined characters in the message. By way of example and not limitation, the predetermined character may be the hash symbol #. Messaging service 220 determines whether any messages associated with previously received conversations include new topics by searching existing topics stored in database 260 (eg, topic database 236). be able to. Upon determining a new topic, messaging service 220 may store the new topic in database 260 (eg, topic database 236). Associations between conversations and topics may also be determined and stored in databases 260 , such as conversation database 230 and topic database 236 .

At 804, the message and indication of the new topic can be output (eg, pushed, sent). The new topic indication (eg, new topic tag) can be sent by a push service (eg, push service 224) to a messaging application (eg, messaging application 240) associated with the conversation participant for display. can. A message associated with the topic may be output by push service 224 of messaging service 220 upon receipt of user input indicating selection of a topic. Messages and topic tags can be output to users of messaging applications, for example, via conversations within the UI of messaging application 240 running on user device 242 . The message and topic tags can be sent to a user device (eg, user device 242). Messages and topic tags can be sent to external email addresses that have been added to the conversation.

At 805, new participant A can be invited to join the conversation. A new participant A can be invited by an existing participant, for example by entering a username, group name, or email address associated with the new participant A in an input field of the conversation. Messaging service 220 (eg, chat service 222) can add the new participant A to the conversation. The messaging service (eg, chat service 222 ) may store the association of new participant A with the conversation in database 260 , eg, in conversation database 230 and user database 234 .

At 806, a lookup of existing participants in the conversation can be performed. This lookup can be performed by messaging service 220 , eg, chat service 222 . Chat service 222 can send an indication of the determined participants in the conversation to push service 224 .

At 807, existing participants in the conversation can be notified that new participant A has been added to the conversation. A push service 224 can notify existing participants. Notifying the existing participants may include sending a notification to the existing participants' user devices (eg, user device 242). Existing participants can be notified via conversations and/or UIs of messaging applications running on their devices.

At 808, the content of messages associated with the conversation can be determined. The content can be parsed by a messaging service 220 such as chat service 222 . Analyzing the content may include determining one or more attributes of the content of the message. For example, it may be determined that the message contains text consisting of special characters representing attributes such as new participant A. As an example and not by way of limitation, a predetermined special character representing a new user (ie, a new participant) may be the @ symbol. Conversation lookups can be performed by querying databases 260, such as conversation database 230 and topic database 236, for example. A conversation lookup can be performed to determine the users, messages, topics, and other attributes associated with the conversation. Chat service 222 may send an indication of the results of parsing and/or conversation lookup to push service 224 .

At 809, conversation lookup results, eg, messages and topic tags, can be output (eg, pushed) to the new participant A. Messages and topic tags can be output by push service 224 . Outputting the message and topic tags may be performed by, for example, adding the message and topic tags to a new participant via a conversation within a UI of a messaging application (eg, messaging application 240) running on a user device (eg, user device 242). can include sending to a person. The message and topic tag can be sent to the user device associated with the new participant A (eg, user device 242). Messages in the conversation can be sent to the external email address associated with the new Participant A. The messaging service according to the present disclosure classifies conversations based on attributes of topics associated with the conversations, and provides the participants with the content of the conversation in response to the selection of topic tags that indicate topics of conversation that the participants are interested in. can provide. This allows the message service to more efficiently provide content of interest to users.

FIG. 9, in conjunction with FIG. 8, illustrates starting a new conversation and adding users to the new conversation. As described with respect to Figure 4, the user initiates a new conversation. A user may initiate a new conversation by selecting the “Start a conversation” button 917 . This is shown in FIG. 9 from the perspective of a user interface 900 operating on a user device (eg, user device 242). Here, a user (eg, User A) initiates a conversation 901 and enters the message “#tag-patent” 903 . Since there are no other users associated with message 903, the message appears only within conversation 901 of a single user, User A, who is also the creator of the conversation (ie, the creator user). This allows the creator user to continue adding messages to conversation 901 . As explained more fully below, the message "#tag-patent" contains the topic ("patent") entered as at least part of the initial message. At any time during the conversation you can enter a message containing the topic. In one embodiment, the messages are processed by a messaging service and stored in a database as attributes associated with conversation 901 . Similarly, as described, other participants in conversation 901 (eg, messaging service users with access permissions to conversation 901) can be added to conversation 901 as attributes of conversation 901. FIG.

Referring back to FIG. 8, a conversation creator user can invite new users (ie, new participants) to join the conversation. In some embodiments, the messaging service communicates with the databases 260 described and uses the chat service 222 and push service 224 described above. Continuing the example, at 810, a user can initiate a conversation that includes one or more messages. A message may include multiple characters, symbols, be a text string, or other type of content. When a new message is added to a conversation, chat service 222 determines which users are attributes of the conversation, ie, users associated with the conversation. These attributes are stored in one or more databases. Such databases include conversation databases (eg, conversation database 230), group databases (eg, group database 232), topic databases (eg, topic database 236), and email user databases (eg, email user database 237). including but not limited to. Conversation participants can be identified and notified of the conversation.

As messages are received during a conversation, the messaging service (e.g., messaging service 220) may determine whether new topics are included in the messages that form the conversation, such as topic database 236. Existing topics may be searched in one or more databases. Thus, the attributes of the conversation, eg, topic, user, group, etc., ensure that the conversation is properly categorized, eg, based on topic, and that new conversations are pushed out to participants. The push service 224 facilitates the output of messages, existing topic tags, and new topic tags to intended participants. In some embodiments, this can occur by pushing a message to a user interface or user display on a device associated with the intended participant of the conversation.

In another example, the user may be invited to join the conversation. For example, at 805, a new Participant A can be invited to join an existing conversation, whereby the messaging service (eg, messaging service 220) shares information related to the conversation with the new Participant A. allowed to do. The chat service 222 handles this actuation and, at 506, looks up all existing participants associated with the conversation, as in the previous example, and optionally one or more databases 260 (e.g., Communicate with databases 230-236) to obtain relevant information. Once the participant is identified, the push service 224 notifies the identified existing participant associated with the conversation to indicate to the existing participant that a new participant has been added to the conversation at 807. .

After a new Participant A is invited to join the Conversation, the message, content, and/or metadata associated with the Conversation can be sent to the new Participant so that the push service can send relevant aspects of the Conversation to the new Participant, e.g. Retrieve from conversation database 230 and topic database 236 . FIG. 9 illustrates an exemplary user interface (UI) 900 of aspects of techniques for inviting new users to join a conversation. In FIG. 9, UI 900 is shown as being presented on a user device (eg, user device 242) through, for example, a messaging application (messaging application 240). In this example, and as shown in UI 900 , User A has initiated a conversation 901 that includes one or more messages 902 . In this example, the message “Hello” has been added to conversation 901 . Additionally, another message was added to conversation 901 with topic “patent” 903 . The conversation 901 can be stored in database 260 , eg, conversation database 230 . To add a new user, the message field 904 of the UI 900 contains information indicating the user using the @ symbol 905 or other predetermined special characters followed by a text string 906 that identifies the user, for example by username. input. Here, User C's username has been entered in the text field beginning with the @ symbol.

In one embodiment, after the user selects the "Send" button 907, the message is sent to a messaging service (eg, messaging service 220). The messaging service then parses the message, for example as shown in FIG. 4, to determine that the message contains a predetermined @ symbol 905, and interprets the text following the message 906 as user identification information. The messaging service then interprets this message as User A's request to allow the system to add identified User C (ie, a new participant) to the conversation. Other embodiments are also envisioned, for example, the messaging application on the user device parses the message and the user wishes to allow an identified user C (i.e., a new participant) to join the conversation. An indicator may be sent to the messaging service indicating that the In other words, the processing of the message can be partly done on the user device and part of the processing can be done by the messaging service.

At a particular event, once authorized, the cloud service can add information identifying the new participant (eg, the new participant's username) as an attribute of the conversation. To this end, the user is associated with conversation 901 and the association is stored in database 260 . It should be appreciated that multiple symbols, text, characters, etc. can be defined as indicators associated with identifying a particular user. In this particular example, the @ sign is the pre-determined symbol for adding a new user, the user enters the new username as "@UserC", and "@UserC" is a new participant in conversation 901 via the messaging service. recognized as a person.

FIG. 10 shows aspects of the properties from the UI 1000 perspective after a new participant 1002 (eg, user C) has been added to the conversation 1001 . In this example, the username of new participant 1002 becomes another message in conversation 1001 as shown. In other words, the addition of a new participant to conversation 1001 is stored within the text of conversation 1001 itself. Therefore, by analyzing the messages in Conversation 1001, the order and time in which new participants and other attributes are added to Conversation 1001 can be discerned. For example, after a new participating User C was added, a user (eg, User A) also put another message into Conversation 1001 at 9:31 PM, including the topic "#tag-patent1". Thus, a user (e.g., user A) adds one or more users associated with conversation 1001 by adding new users to the conversation and putting messages, e.g., "#tag-patent", "#tag-patent1". topic can be specified. As shown in FIG. 2, these particular messages within conversation 1001 also become attributes of the conversation that are stored in various attribute databases, such as topic database 236 and user database 234 . In embodiments, attributes may be defined using different symbols, letters, characters, for example, using @ to indicate that a username or other user identification information is entered and the topic is Conversation 1001 The hashtag # can be used to indicate that it is associated with. It is envisioned that other symbols can be used to add additional attributes to the conversation.

Figures 9-10 also show that conversations can be sorted by topic, as indicated by the leftmost columns 909, 1009, for example. The illustrated example shows conversations labeled as a "Feed" view 908, 1008 sorted by attributes such as topic attributes. Selecting a feed displays a list of one or more conversations in a condensed version associated with the selected topic of the conversation. In one embodiment, selecting a condensed version of a conversation displays one or more messages associated with the selected conversation. Here, for example, a condensed version (or abstract, summary) of the conversation is displayed, with the author of the conversation listed at the top, followed by the first message in the conversation "UserB Hello" 910, 1010, Then follows the last message in the conversation, namely the message "#tag-patent1" 911, 1011 for adding a second topic. The condensed version (or abstract, summary) of the conversation presents the user with a preview of the conversation, which allows the user to view the entire conversation whether he is interested in the conversation or not, by selecting the conversation summary. You can decide whether you want to review the contents of the . Topics (shown as topic tags on the UI) serve as short descriptors of the content of the conversation.

In other embodiments, as described below, conversations may be sorted by one or more other categories and classifications, Groups views 912, 1012, and conversations and messages may be and each of the messages is organized based on a group of subjects. These are further described in other embodiments below.

FIG. 11 illustrates an embodiment for adding topic tags to conversations and adding new messages to conversations. As previously mentioned, topic tags that correspond to topics are attributes of conversations that are used, for example, in feed views to facilitate sorting, managing, and selecting conversations. One or more topics can be associated with a conversation via such topic tags. By way of example, and not limitation, a topic tag can be a text string with a leading character that indicates that the following text contains the topic. In this embodiment, the hash sign or "#" is a predetermined character recognized by the messaging service to represent a topic. A user (ie, a participant) can initiate a conversation. In this example, the user also adds a topic to the conversation at 1110 . The chat service 222 can then receive the new conversation indication and parse the message to detect the presence of the topic. As described above, parsing of messages may be performed by a messaging service (eg, messaging service 220), by a messaging application (eg, messaging application 240) on a user device (eg, user device 242), or by some of the two. It can be done in combination. After a conversation is initiated by entering a message, for example a message containing a topic, a lookup 830 is performed to determine if any other users or participants are relevant attributes of the conversation. . A lookup may be performed by one or more searches of databases 260 such as conversation database 230 , group database 232 , user database 234 , and topic database 236 .

Once the relevant users (ie, participants in the conversation) are identified, at 840 the conversation is added to the topic tag taxonomy of all tracked participants stored in various databases. In other words, an association between the new conversation and the specified topic tag can be stored, and the association can be stored to associate all users who are associated with the topic tag and who are also associated with the conversation. Conversations are therefore summarized for all participants 1150 in relation to topic tags. For example, when a user is added to a conversation, the user can receive a condensed version of the topic consisting of the first and last messages. The push service 224 further processes such messages and at 1152 outputs the messages, eg, on a user display, sends them to respective users, and presents respective views of existing and new tags, eg, such Within the feed view of conversations sorted by tags, it can be possible to make updates.

In another embodiment, shown in FIG. 11, topic tag properties are incorporated into existing conversations. For example, at 1115 a new message with a topic indication can be added to an existing conversation. Similar to the process described above, receipt of a message containing information indicative of a topic causes a lookup of all participants in the conversation at 1135 . Associations between topics and conversations and between participants and topics are stored in databases 260 such as conversation database 230, topic database 236, users database 234, groups database 232, and email users database 237. be able to. At 1145, a lookup of other existing topic tags is performed to determine whether the topic is a new topic, for example, if there are multiple topic tags present in and associated with the conversation. can judge. At 1156, messaging service 220, eg, push service 224, then pushes the message and a new topic tag corresponding to the new topic to each participant.

An example of these techniques will be described using the example user interfaces of FIGS. 12-13. FIG. 12 shows a feed view 1208 of an example messaging application that provides a list 1215 of topic tags. In this example, conversation 1201 includes a message "#tag-patent" that includes a topic that begins with the predetermined character "#". As previously mentioned, the predetermined character representing the topic may be any other special character such as the % sign. If the messaging service determines that the message includes a new topic based on determining that the message includes the predetermined character # and searching database 260, then the conversation is changed to the conversation associated with the new topic. Added to the list. Thus, when the corresponding topic tag is selected from feed view 1208 via the UI of a messaging application (e.g., messaging application 240), current conversation 1201 and all other conversations associated with the new topic are displayed in all of the conversations. can be easily viewed and organized by all participants.

FIG. 13 further illustrates this concept and the ability to sort conversations based on topic. Here, the user has selected the topic tag “#tag-patent” 1316 in the leftmost column 1315 of the UI 1300 . This causes the messaging service to push a condensed version of each conversation related to the user and the selected topic. When the topic tag "#tag-patent" 1316 is selected, the messaging service also pushes the content of the corresponding conversation to the rightmost area 1325 of the UI 1300 to display the messages in the conversation. These conversations are then displayed in the feed view 1308 without displaying other, irrelevant conversations. The order of topic tags displayed in feed view 1308 can be arranged according to user preferences such as the priority and importance of each topic. Conversations associated with each topic tag can also be sorted based on one or more variables, such as time, last message received, priority, user preferences, and the like. Similarly, each conversation contains multiple messages, and users associated with a particular conversation can view messages, send messages, and add attributes such as additional users, topics, groups, etc. described herein. can do.

In various embodiments, a user can generate a conversation consisting of one or more messages that can include attributes. The message may be parsed and based on which one or more messages are parsed, it may be determined that the message includes strings that indicate attributes, such as users, topics, groups, and the like. Attributes can be stored in at least one database as associations between information indicative of topics and conversations. In response to receiving input from a messaging application (e.g., messaging application 240) indicating a selection of a topic, a messaging service (e.g., messaging service 220) renders at least a subset of the conversations associated with that topic to the messaging application for display. 240.

In additional embodiments, the messaging service further determines that the topic is new by searching at least one database containing information related to the topic, and based on determining that the topic is new, provides information indicative of the topic. Stored in the at least one database. In another example, a second message within the conversation can be parsed. It may be determined that the second message contains information identifying the second user, thereby allowing the second user to add the message to the conversation. The information indicative of the topic may be sent, for example, to one or more messaging applications operated by one or more other users, and the database stores a plurality of attributes, such as topic, associated with each conversation. Additionally, multiple conversations may be stored.

By using a messaging service that can include at least one database and at least one computing device in communication with the at least one database and configured to perform operations, one or more characteristics and functions can be realized. Further, various aspects of processing may be split between messaging applications and messaging services. In some embodiments, it is preferable to have the messaging app perform the actions, and in other embodiments the same actions may be performed by the service.

In feed view 1308, a conversation can be started, for example, by selecting an icon, eg, “Start a Conversation” icon 1317 . Unlike other messaging applications, conversations may be organized by topic, not just by user. Topics can be defined by the user at the beginning of the conversation. For example, a creator user who initiates conversation 1301 can assign topics to conversation 1301 . Topics can also be defined by other participants at other stages of the conversation. Topics can be represented by special characters or tags, such as the "#" symbol. The creator user may then add additional participants to the conversation or continue the conversation alone.

One or more panels 1315 , 1318 , 1320 can be displayed in the “Feed” view 1308 . The panels can include an open (eg, expanded) conversation panel 1318 . Participants can communicate within open conversation panel 1318 by, for example, entering messages within input field 1304 . The entered messages can be displayed as a log or feed 1319 of the conversation 1301, eg, in the order in which they were sent, entered, or received. A timestamp may be displayed near the message in conversation 1301 to indicate when the message was sent, put in, or received. The user name of the participant who put the message may be displayed next to the message in the conversation.

The panels can include a folded conversation panel 1320 . Collapsed conversation panel 1320 can be adjacent to open conversation panel 1318 . A collapsed conversation panel 1320 may show a preview 1321a, 1321b of the conversation, such as the first message of the conversation, the title of the conversation, the last message of the conversation, and/or the number of unread messages in the conversation.

14-19 illustrate aspects of interactions between participants in the context of groups (eg, user groups) and the various ways in which messaging services and applications can categorize, organize, and output group-related messages and conversations. techniques and embodiments. It should be understood that Figures 14-19 are merely exemplary and that groups can be created and joined into conversations in other suitable ways.

FIG. 14 illustrates aspects for inviting an existing group or a newly created group into a conversation and creating a new group. At 1405, existing groups or newly created groups can be invited to join any conversation. As an example and not by way of limitation, an attribute may be to invite and allow a group containing multiple members to participate in multiple conversations. Group attributes also allow having multiple group participants in the same conversation. Additionally, group participants in a conversation will be able to push the content of the conversation to all members of the group at once. Thus, the present messaging service offers greater flexibility and efficiency compared to traditional messaging systems.

A group can be invited by any conversation participant by searching for the group name of the group. By way of example and not limitation, in response to receiving user input indicating to invite a group to a conversation, the messaging service creates an association between the group and the conversation in a database 260, such as conversation database 230 and group database 232. store in

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

At 1407, after the group has been invited to join the conversation, at least a subset of the messages in the conversation are pushed to all members of the group. Messages can be pushed by a push service 224 . Pushing the message can include sending the message to the member, eg, to the member's device. Pushing the message can include having the message displayed within a UI of a messaging application associated with the member.

FIG. 16 illustrates aspects of a group view 1600 within the UI of a messaging application. In group view 1600, the groups to which the user belongs are displayed to the user. FIG. 16 lists eight groups to which the user belongs. According to embodiments, groups are displayed in a list. The group view displays the attributes of the group and one or more selectable interface elements (eg, selectable buttons such as "Edit" and "Delete"). Attributes include group name 1601 . FIG. 16 shows group names including "Group1", "Group2", "Group3", and so on. Information associated with the groups is sent to a messaging service (eg, messaging service 220) and maintained by messaging service 220 in databases 260 (eg, group database 232, search index database 252, etc.).

Once a group is admitted to participate in a conversation, the association between the group and the conversation is stored in database 260 . For example, the messaging service 220 stores the conversation's thread identification (ID) and the group's group identification (ID) in the group database 232 . By way of example, and not limitation, an association between a group and a conversation can be identified based on the conversation's thread ID and group ID. The messaging service may generate a search index based on the information associated with the group and store the search index in database 260 , such as search index database 252 . Associations between all members of the group and conversations may be determined based on the search index, and the associations may be stored in database 260 . Because information associated with groups and members of groups can be retrieved from database 260, based on the retrieved information, for display associated with all members of a group (i.e., group participants in a conversation). , can send messages in a conversation to a messaging application.

After a group has been invited to participate in a conversation (i.e., as a group participant), unless any particular individual member is invited to the conversation by another participant or directly participates in the conversation (e.g., posting a message), the identity of individual members of the group may not be sent to the messaging application associated with the conversation participant for display. When any particular individual member of the group is invited to a conversation by another participant or joins the conversation directly, the identity of that particular individual member is sent to the messaging application associated with the conversation participant. to display the identification information of the specific individual member. Additionally, the particular individual member may continue to participate in the conversation as an individual participant even after the group has been removed from the conversation. Any other member of the group who has not been invited to the conversation by another participant or who has not directly participated in the conversation shall No further messages in the conversation will be received.

Members can be added to and removed from groups, as described further below. Upon receiving information indicating group edits (eg, adding or removing members), the messaging service (eg, messaging service 220) updates databases 260 (eg, group database 232 and search index database 252). Messaging service 220 searches database 260 to determine which members are included in the current group, and adds any messages in conversations in which the group participates as a group participant to the current group. Send to members in If any previous individual member of the group was already invited to the conversation by another member or directly participated in the conversation before the individual member was removed from the group, the previous individual member: You can still participate in the conversation as an individual participant. The messaging service 220 can continue to send messages in the conversation to the former individual member as the current individual participant.

Group attributes can include group privacy settings 1602 . As shown in Figure 16, the group "Group1" is private. The group "Group2" is also private. Privacy settings may also be maintained in databases 260 such as group database 232 . For any private group, only members of the private group can access the private group. Unlike private groups, public groups are not limited to members within the group. Alternatively, the public group can be accessed by any participant in the conversation, or at least a subset of other users registered with the messaging service (eg, messaging service 220).

Group attributes may also include persons 1603 (eg, members of the group). FIG. 16 shows a group "Group1" with ten members. "Group2" has three members. In the group view, members of each group may have their profile image, account avatar, username, and user device (e.g., user device 242) and/or database 260 of the messaging service 220, which may be maintained, as examples. /or can be represented by a handle.

The group view contains functionality for users to manage their groups. In addition to the create new group properties described above, and specifically shown in FIG. Action 1605 includes an "edit" option that allows the user to change attributes such as name, privacy settings, and group membership (eg, add or remove members). A window such as window 1203 of FIG. 12 is displayed in response to the user selecting the edit option. This window contains options to add or remove members. Actuation 1605 can also include a "delete" option that allows the user to delete the group.

As an example and not by way of limitation, at 1401 a new group can be created. The new group contains multiple members. Groups can be created by the group service 251 of the messaging service 220 . Messaging service 220 may also create a group ID for the new group. Groups can be created based on user input. User input may be received via a group view of the UI of the messaging application, eg, group view 1501 of FIG. A user can switch from feed view 1502 to group view 1501 . In the group view, conversation participants can select the “New Group” icon 1507 . In response to the user selecting icon 1507, a UI (eg, window 1503) is displayed with options for creating a new group. A new group can be created via the UI (eg, window 1503).

Options include privacy settings 1504 . Privacy settings 1504 are selected by selecting icon 1508, which has privacy options such as a slidable icon and a toggleable icon. In one embodiment, private groups are not searchable by other users across the messaging platform. In other embodiments, non-private groups are discovered and thus added to various conversations associated with attributes and the like.

Options include group name 1505 . A group name 1505 is entered by entering a string of text in the input field 1509 . As shown in FIG. 15, input field 1509 contains the group name "Patent Team". Group name 1505 distinguishes the group from other groups. The group can be searched by the group name 1505 of the group.

Options include users (ie, members) 1506 in groups. FIG. 15 shows a Patent Team group with five members. A member 1506 is invited (eg, added) by retrieving information that identifies the member 1506 within the group. By way of example, and not limitation, information identifying members 1506 of a group may be a username associated with any member, an account within an entity associated with any member, an email address associated with any member, or an email address associated with any member. A phone number associated with the member may be included. Upon receiving group member identification information, messaging service 220 may store the member identification information in databases 260 , such as group database 232 and search index database 252 .

Add a member 1506 by entering a text string in the input field 1510 . For example, Figure 15 shows searching for a member named "UserC" to invite to the "Patent Team" group. The window shows the number 1511 of members selected to be invited to the group. Options selected in the window are group attributes and/or associations.

A group can be canceled by selecting the "Cancel" button 1507 in the UI. A group can be saved by selecting the "Save" button 1508 in the UI. In response to the group being saved, the group's attributes and associations can be saved to the database.

Returning to FIG. 14, at 1402, group information (eg, attributes, associations) is recorded (eg, saved, stored) in one or more databases 260, such as group database 232 of FIG. Group information can be recorded by group services 251 . The databases may include conversation database 230 , group database 232 , user database 234 , and/or search index database 252 .

At 1403, a search index is constructed to store an index of search information. A search index may be built by Group Services 251 . The search index can operate in conjunction with other databases such as conversation database 230 , topic database 236 , group database 232 , and user database 234 . The search index allows the messaging service to search attributes (eg, group attributes) associated with messages and conversations. A search index allows management of permissions. Based on the search index, group members can access specific conversations and messages.

At 1404, information associated with the group can be output to a messaging application associated with the conversation participant for display. Outputting group information can include transmitting an indication of the group to the participant, eg, to the participant's device. As shown in FIG. 16, outputting the group information can include causing the group information to be displayed via a UI of the messaging application.

FIG. 17 shows an aspect 1700 for adding new members to an existing group. At 1701, new members are added to existing groups. New members can be added to existing groups in response to receiving user input. The user can enter input by selecting one of the "edit" icons in the group view of the UI. A list of current members of the group can be displayed in a window. The user can search for the names of users who are not members of the group and choose to invite new members to the group.

The messaging service's group service 251 can add new members to existing groups. Group services 251 can add new members based on receiving user input. Group services 251 may store new member associations with groups in one or more databases 260 . By way of example, databases 260 may include conversation database 230 , group database 232 , user database 234 , topic database 236 , and/or search index database 252 .

At 1702, a lookup of information related to the group, such as associated conversations, topic tags, etc. is performed. Group attributes include existing group members and the like. A lookup is performed by sending a query to one or more databases 260 . Import attributes for new members. Importing the attributes may include storing the attributes locally, eg, in the memory of Group Services 251 , and storing the new member attributes in Group Database 232 .

At 1703, conversations associated with the group are output to new members. Conversations can be output by push service 224 . Outputting the conversations can include sending messages contained in various conversations associated with the group to the new member, eg, to the new member's device. Publishing the conversation can include having the new member view the conversation via the UI of the messaging application.

At 1704, members of the group are discovered. Group members can be discovered by group service 251 and/or push service 224 . Group members can be discovered by querying database 260 . Group service 251 can determine the members of the group and send member indications to push service 224 .

At 1705, the determined group members are communicated to the determined members of the group. Members may be notified by push service 224 . Members can be notified that new members have been added. Notifying the member can include sending a notification to the member, eg, to the member's device. Notifying the member can include displaying the group members to the member via the UI of the messaging application, eg, within a group view.

In some embodiments, messaging service 220 and/or messaging application 240 may receive messages in conversations that include information to identify groups that include multiple members. In response to receiving this information, the messaging service 220 queries the database 260 to display at least a subset of the messages in the conversation with the messaging application 240 associated with the group member. can be sent to In one example, messaging service 220 and/or messaging application 240 can obtain information associated with members of a group by analyzing data associated with the group. In one example, the data associated with the group includes information about the members and attributes of the group. In another example, the data associated with the group can further include at least a portion of the content of conversations in which the group participates.

According to another aspect, a task associated with a due date can be created by one participant (assignee user) and assigned to another participant (assignee user) in the conversation. 18 and 19 illustrate techniques for assigning tasks associated with due dates within a conversation. Messaging services include chat service 222 . Chat service 222 may be provided by a device or program, such as a device or program in cloud computing network 100 of FIG. The chat service 222 allows users of the messaging service to exchange messages in conversations and/or generate conversations.

Tasks are initiated when the chat service 222 receives input from the user. In some embodiments, a task is first edited by an assignee user via a messaging application (e.g., messaging application 240) and then assigned to an assignee user by the assignee user. can be invited to join the conversation. In other embodiments, editing the task and inviting the assignee user to assign the task can be performed simultaneously on the same UI of the messaging application associated with the assignor user. The chat service 222 may receive input via a conversation, for example, via an input field of the conversation within the UI of the messaging application on the user device.

For purposes of illustration, FIG. 19 shows a UI 1900 of a messaging application in feed view where a user can enter input into input fields 1903 . A user can be a conversation creator user or another participant in a conversation. The input is a text string. For example, in FIG. 19, user "UserA" has entered the text "User B Please give us a conclusion." Text can describe the task. For example, User A's text includes "Please give us a conclusion," and its task is "giving a conclusion." The text may include instructions of another user, eg the user to whom the task is assigned. For example, User A's text includes the name of another user, User B. The users identified in the input may be users registered with a messaging service (eg, messaging service 220) and participating in the conversation. The users identified in the input may not be entities external to the messaging service (eg, messaging service 220) (eg, email participants in conversations discussed further below). In this example, user A is the assignor user and user B is the assignee user.

The input may include a date associated with the message. This date may be the due date of the task. This date may be the date when a reminder about the task should be sent. This date may include a selection of icons output via the UI of the messaging application on the user device. The icon can represent a calendar, such as icon 1601 in FIG. 16, for example.

Returning to FIG. 18, at 1802 allocation information is generated based on the input. Chat service 222 can generate assignment information. Assignment information may include associations between users who assign tasks, users to whom tasks are assigned, messages and/or tasks, and/or due dates. Assignment information is stored in one or more databases 260 , such as task database 256 , conversation database 230 , and user database 234 . Chat service 222 can store assignment information.

At 1803, assignor attributes and/or assignee attributes are added to the conversation based on the assignment information. Chat service 222 can add attributes. Adding attributes may include storing associations between assignee users, assignee users, messages and/or tasks, due dates, and/or conversations. Attributes are stored in databases 260 such as conversation database 230 , task database 256 , user database 234 , and group database 232 .

According to embodiments, a task has a status. The status is based on the task's due date and/or attributes indicating what stage of completion the task is in. For example, when tasks and/or due dates are created, the status can be set to "open," "incomplete," and/or "unverified." A status descriptive attribute can be a prefilled selectable input in the UI, such as a selectable icon or a list of selectable icons. A descriptive attribute can be, for example, a text string entered by the user into an input field in the UI of the messaging application.

The assignor user and/or assignee user can change the status to, for example, "closed," "completed," and/or "verified." Status can change based on whether the task is completed or not. For example, if a task is completed, the status can be changed to "completed". Statuses are stored in database 260 in association with tasks and/or due dates. The new status is saved in the database 260 in response to the status change. Messaging service 220 (e.g., chat service 222) determines status, timestamps (e.g., time verified, time last updated, etc.), and other information, and database 260 (e.g., task database 256). can be stored in Send notifications to users in response to status changes. According to one embodiment, the status is displayed to the assignor user, the assignee user, and/or the participants of the conversation within the conversation, for example within the UI of the messaging application on the user device. Upon receiving the information indicating the status and due date of the task, the messaging application can display the status and due date of the task.

At 1804, all participants in the conversation are discovered. Chat service 222 can discover participants. The participants in the conversation can be determined by querying the database 260 . The participants can be sent to the messaging service's push service 224 . Push service 224 may be a messaging service device or program.

At 1806, the status of the task is pushed to the determined participants of the conversation. A push service 224 can push the status. Pushing the status can include sending the status to the participant's device (eg, user device 242). Pushing the status may include displaying the status within the conversation via the UI of the messaging application (eg, messaging application 240) on the user device (messaging application 242). A messaging service (eg, messaging service 220) can update the status of a task upon receiving information, eg, from assignor and assignee users, indicating changes to the due date or status of the task. The messaging service can then send information indicative of the updated status of the task to the user device associated with the participant for display of the updated status of the task.

According to one embodiment, the messaging service includes reminder scheduler service 253 . The reminder scheduler service 253 can be a messaging service device or program. The reminder scheduler service 253 has access to the messaging service's database 260 . Reminder scheduler service 253 determines the assigned task, the conversation associated with the task, and the user or users associated with the task.

A user (eg, User A) can enter an entry indicating a reminder date. As shown in FIG. 19, the user may enter an input via the UI 1900 of the messaging application indicating a due date for sending the reminder. For example, user A selects date selection icon 1902 . Based on selection of the date selection icon 1902, a window 1901 with selectable dates is displayed. Window 1901 may represent a calendar showing the days and months of the year. User A selects the reminder date of April 28, 2020 in window 1901 . Based on the user entering a reminder date, the reminder date is sent to the database 260 and associated with the task and/or due date by, for example, the reminder scheduler service 253 of the messaging service 220 in a task database such as that shown in FIG. stored in a database 260 such as 256.

The reminder scheduler service 253 can determine if the task's status and/or due date has changed. The reminder scheduler service 253 determines the current descriptive attributes and/or due dates assigned to the task by querying the database 260, and determines whether the due date has passed, thereby revising the task. status has changed. Based on the status changing to "closed", "completed", and/or "verified" status, the reminder scheduler service 253 does not send reminders. At 1811, a task and/or due date reminder is sent by the reminder scheduler service 253 based on the status of the task not changing or remaining "open," "incomplete," or "unverified." do. This reminder is sent to the assignor user, the assignee user, and other participants in the conversation. The message can be sent to push service 224 . A status change indication is sent to the push service 224 .

At 1812 , push service 224 receives the message from reminder scheduler service 253 . A messaging service 220 (eg, push service 224) notifies and/or reminds assignee users and/or assignee users of due dates and/or tasks. The messaging service may also notify or remind other participants of due dates and/or tasks. Push service 224 notifies assignee users, assignee users, and other participants of reminders and/or due dates and/or status changes to tasks. According to some embodiments, push service 224 notifies participants by sending a message to the device associated with the user. According to one aspect, the push service 224 may send reminders at predetermined time intervals, such as, for example, one week before the due date, two weeks before the due date, one day before the due date, and one hour before the due date. can be done. The push service 224 can notify the participant by displaying a reminder on the UI output via the participant's device. The push service 224 can stop providing reminders based on due dates and/or task status changes. The task assignment and task reminder features allow messaging services according to the present disclosure to provide more functionality than conventional messaging systems.

A user can respond to a status change by another user. For example, the assignee user marks the task as "verified" in response to the assignee user marking the task as "completed" to indicate that the completion of the task has been verified by the user. Assignor users may reopen tasks marked as "completed", for example, if the user notices that the task is not being satisfactorily performed, or if the user determines that further work is required. be able to. According to embodiments, the due date and/or the color or other indicator of the task displayed in the UI changes based on the status change. Based on the status change, an indication of the change is sent to the conversation participants, for example by push service 224 .

In some embodiments, messaging application 240 may receive information associated with a task within a conversation. This information includes an identifier for identifying the user (for example, the assignee), the content of the task, and information indicating the date. Messaging application 240 can send information associated with the task to messaging service 220 . Upon receiving information from messaging application 240, messaging service 220 can transmit the information to the identified user (eg, assignee). The messaging application 240 can also receive information indicative of task status updates and display the updated task status. The content of the task can include at least part of the content of the conversation.

According to one embodiment, messaging service 220 blends the characteristics of chat and email with email integration capabilities. FIG. 20 shows an example of a messaging service's chat and email integration process. The messaging service according to the present disclosure improves the efficiency of information exchange by realizing the integration of email and messaging services. As illustrated, messaging service (eg, messaging service 220 ) includes chat service 222 . Chat service 222 may be a stand-alone service or may be incorporated as a property of messaging service 220 . Chat service 222 manages conversations on messaging service 220 .

At 2002, chat service 222 receives input, eg, from a user device. Specifically, chat service 222 receives input in the form of messages via a messaging application running on the user device, eg, via an input field in the UI of messaging application 240 . FIG. 21 provides an illustration of an exemplary UI for inviting an email participant to conversation 2101 and entering a message addressed to the email participant. To enter external e-mail participant A into conversation 2101, the user enters a message in the form of an external address, such as an e-mail address. In the particular example of UI 2100 shown in FIG. 21, a user has the email address UserF@gmail. com 2105 entered. Accordingly, the chat service parses the message and recognizes it as an email address associated with an entity (ie, email participant A) external to the messaging service. The e-mail address is also associated with e-mail service 254 . This example shows that the user has entered an email address that includes the domain "gmail.com". Other embodiments may use e-mail aliases previously known by the messaging service, represented by predefined characters, for example.

Returning to FIG. 20, at 2008 chat service 222 stores the email address-conversation association in, for example, conversation metadata 230 and email user database 237 . Once email participant A has been invited and granted access to the conversation, the messaging service (eg, messaging service 220) can generate an identifier to identify the conversation. Identifiers are used to identify conversations by email services external to messaging service 220 and can be associated with the email addresses of email participants. In another example, prior to inviting any email participants to the conversation, the messaging service 220 can generate an identifier to identify the conversation to be used for external email services. The messaging service can send the identifier to an external email service associated with the email participant. By way of example, and not limitation, an identifier for identifying a conversation may be a return email address corresponding to the conversation. The external email service can then send an email to the return email address associated with the conversation. In response to determining that an email has been received from the email address associated with the conversation, the messaging service generates a message based on the email and directs the conversation to display the generated message based on the email. The message can be sent to a messaging application (eg, messaging application 240) associated with the participant of the event. On the other hand, in response to determining that the email is not from the email address associated with the conversation, the messaging service discards the email and/or forwards the email to the return email address corresponding to the conversation. Reply with a notification to the effect that mailing is prohibited.

FIG. 21 shows an exemplary UI 2100 of a messaging application (eg, messaging application 240). UI 2100 can include conversation 2101 . Conversation 2101 may include input fields 2102 . User input may be received via input field 2102 . An exemplary entry 2104 to an email participant includes the content "Hi, external User F." An exemplary input (ie, message in conversation 2101) 2104 is the email address UserF@gmail. com. An email address and content can be entered in input field 2102 .

At 2009, chat service 222 discovers existing participants in the conversation. Existing participants may be messaging service users and/or existing external email users. Chat service 222 discovers participants based on conversation metadata. To this end, chat service 222 discovers participants by querying user database 234 for users associated with the conversation and by querying email user database 237 for users who are participants. After receiving an indication that the email participant has been added to the conversation, subsequent messages can be added to the conversation, and an email message is generated and sent to the email address associated with email participant A: are sent as described more fully in

In some embodiments, when messaging service 220 receives a message in a conversation that includes information identifying email participant A (eg, an email address associated with email participant A), the email message can be generated. The e-mail message is generated according to an e-mail protocol associated with e-mail service 254 . A generated email message includes at least a subset of the received message 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 another example, the messaging service 220 can generate multiple return email addresses each corresponding to multiple conversations. sending the generated e-mail message by messaging service 220 (e.g., e-mail service 254) to an external e-mail service associated with the e-mail address for delivery to e-mail participant A's e-mail inbox; can be done. In other embodiments, external email participants receive a single subsequent message or at least a subset of subsequent messages. In another embodiment, all subsequent messages in the conversation are sent to external email participant A.

The chat service 222 sends the new message along with the conversation participant's instructions to the messaging application's push service 224 . At 2011, the push service 224 notifies the existing participants with a message containing the external email address. Notifying existing participants can include sending a message and/or an indication of an email address to a conversation participant. Notifying existing participants can include having the message and/or email address appear in the conversation.

The push service 224 can send the message instructions to the messaging application's email service 254 . Email service 254 may be a service that is part of a messaging service. In one embodiment, email service 254 formats one or more messages into email format according to an email protocol such as SMTP. This allows the email service to add the external email address associated with Email Participant A to the header fields of the generated email message and add the message content to the body of the generated email message. can. Further, in some embodiments, email service 254 includes information indicative of a conversation resulting from message content, such as a return email address corresponding to the conversation and generated by messaging service 220, in the email message. to add.

Specifically, replies to e-mail messages received by the messaging service, eg, via e-mail service 254, include information indicating an association with the conversation (eg, the return e-mail address corresponding to the conversation). Information associated with the reply can be pushed to a messaging application associated with the conversation participant to cause display of at least one content of the reply to the email message. Thus, information added to an email message and included in any reply to an email message (e.g., a return email address corresponding to a conversation) may change the information associated with the reply to the email message to that of the conversation. Helps identify corresponding conversations to push to messaging applications associated with participants.

As noted above, one example of this association is messaging service 220 (eg, email service 254) generating a corresponding return email address associated with each conversation. By way of example, and not limitation, the generated return email may include at least partially randomly selected text strings. For example, as shown in FIG. 22, the messaging service has email participants UserF@gmail. com 2220 with a return email address calendar-kZNnYBkbywE@feishugroups.com 2220. com 2221 sent an email. As shown in FIG. 21, the return e-mail address is associated with the particular conversation that generated the message to be sent to the external e-mail address 2220 . A return email address 2221 is added to the email header in the sender field of the email message. A messaging service (eg, messaging service 220) can then use the reply to return email address 2221 to associate the return email with a particular conversation.

This method can be used to prevent spoofing of messaging services by return email and junk email. For example, a return email address can be generated in the form of a random email address generator. In this example, the return e-mail address 2221 includes "kZNnYBkbywE", but "kZNnYBkbywE" is randomly selected and cannot be easily predicted or spoofed. Therefore, conversations help reduce the incidence of receiving unwanted spam. In other examples, email headers may include specific information used to identify the conversation, such as in the subject line or other header fields. Such identifiers can include random or unpredictable character sequences that can be used by messaging services to help prevent or control spam. Any or all of the above data can be stored in a database, such as email message database 238, for later correlating and categorizing return email messages.

Accordingly, at 2013, e-mail service 254 can send a formatted e-mail message to the e-mail address associated with e-mail participant A. Sending the email message to the email address can include sending the email message to a domain associated with the email address. As noted above, sending an e-mail message to the e-mail address may include sending other information from the conversation to the e-mail address. FIG. 22 shows an email message being received by an email participant (eg, UserF@gmail.com 2220). The e-mail participant then composes a reply e-mail 2222 containing the text "Hi, there. I am happy!" Send to your email address.

Email service 254 can receive replies to the message from the email address. Replies can be received by email service 254 at the generated return email address corresponding to the conversation. The e-mail service 254 associates the return e-mail address with the corresponding conversation, e.g., by querying a database 260 (e.g., e-mail message database 238), e.g., using information contained in the reply e-mail, and Determine the conversation associated with a reply to an email message. In one embodiment, messaging service 220 (eg, email service 254 ) formats the reply into a message and sends the message to push service 224 via chat service 222 . Push service 224 can then send a message corresponding to the reply to a messaging application associated with the participant in the conversation. In some embodiments, a conversation can include email participant A, as well as other email participants (eg, email participant B). In this case, messaging service 220 may further generate an email message based on the message formatted by messaging service 220 corresponding to the reply from email participant A, and messaging service 220 may then: Send the generated e-mail message to another e-mail participant (e.g., e-mail participant B).

FIG. 23 shows an exemplary UI 2300 of a messaging application (eg, messaging application 240). UI 2300 may be the same as or similar to UI 2100 of FIG. UI 2300 includes a continuation of the conversation from FIG. Based on receiving a reply email 2222 from an email address and an external email system (eg, external email service 2200 of FIG. 22), a messaging service (eg, messaging service 220) generates a message, The message can be added to the conversation and sent to a messaging application associated with the conversation participant to cause the message 2304 corresponding to the reply email 2222 to be displayed. In the example shown, the external email address UserF@email. com is displayed with message 2304 . Other metadata may also be displayed, such as the time the message was sent to the messaging application associated with the conversation participant.

In some embodiments, messaging application 240 may receive information entered by the user during a conversation. This information can include an e-mail address and the content sent to the e-mail address. Messaging application 240 can then send the information to messaging service 220 . Upon receiving this information, messaging service 220 may transmit an identifier to identify the conversation and content to an email service external to messaging service 220 associated with the email address. In other embodiments, messaging service 220 can 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 determining that the email contains an identifier for identifying the conversation. Messaging service 220 can then generate a message containing the email content and send the generated message to messaging application 240 for display.

FIG. 24 illustrates an example process 2400 performed by a messaging application (eg, messaging application 240) consistent with this disclosure. Although described as a series of acts, those skilled in the art should appreciate that the described acts may be added, removed, reordered, or modified in various embodiments.

At 2402, messaging application 240 begins running on a device (eg, user device 242) associated with a user of a messaging service (eg, messaging service 220). At 2404, messaging application 240 sends to messaging service 220 a request for information associated with the conversation (ie, message thread) in which the user is engaged. In some embodiments, the requested information includes metadata associated with the conversations, eg, thread identification information (ID) corresponding to each of the conversations. The requested information further includes information indicating attributes associated with the conversation, such as topics, users, groups, tasks, etc. associated with the conversation. In other embodiments, the requested information may further include data indicative of summaries of conversations, eg, a subset of messages for each conversation. In one example, the subset of messages in each conversation may be the first and last messages in the conversation.

At 2406 , messaging application 240 receives the requested information and stores the requested information locally, eg, within user device 242 . In some embodiments, the received information, including conversation thread IDs and attributes, may be stored in local memory, such as a browser cache. In other embodiments, conversation thread IDs and attributes can be stored in a local database. At 2408, the messaging application 240 displays an indicator of the conversation. Conversation indicators may include topics beginning with a predetermined character (eg, hashtag #) associated with the conversation. Conversation indicators may also include users or groups that begin with other predetermined characters (eg, the @ sign) associated with the conversation. The conversation indicator may also include a summary of the conversation.

FIG. 25 shows an example user interface (UI) 2500 for messaging application 240 . In this example, indicators of conversations categorized by topic (e.g., "patent" 2502) and categorized by user (e.g., "UserA" 2503) or group (e.g., "Group1" 2504) are in the leftmost column. 2506. A summary of the conversation is displayed in area 2508 next to leftmost column 2506 . Conversation task attributes can also be displayed along with the conversation summary. For example, as shown in FIG. 25, task status 2512 and task due date change 2514 are displayed with summaries 2516 and 2518, respectively. It should be appreciated that the UI 2500 of FIG. 25 is exemplary only and that other display arrangements may be used.

Returning to FIG. 24, messaging application 240 may receive user input indicating selection of a conversation indicator or summary of a plurality of conversations. At 2410, upon receiving the user input, messaging application 240 sends a request for messages in the selected conversation to the messaging service. The request contains the thread ID of the selected conversation. At 2412, messaging application 240 receives the messages of the selected conversation and causes the messages of the selected conversation to be displayed. By way of example, and not limitation, the messages of the selected conversation may be displayed in the rightmost area 2520 of the UI 2500 of the messaging application, as shown in FIG. In one example, the messaging application 240 can utilize the digest to send a request for multiple messages within a selected one of the multiple conversations. Message application 240 can then display content associated with the plurality of messages within the selected conversation received in response to a request.

FIG. 26 illustrates another example process 2600 performed by a messaging application (eg, messaging application 240) consistent with this disclosure. Although described as a series of acts, those skilled in the art should appreciate that the described acts may be added, removed, reordered, or modified in various embodiments.

At 2602, messaging application 240 receives input indicating the start of a new conversation. For example, a user can select a "New Conversation" button 2526 on the UI 2500 to start a new conversation, as shown in FIG. In some embodiments, messaging application 240 can generate a thread ID for the new conversation. In other embodiments, upon receiving information indicative of a new conversation sent from messaging application 240, messaging service 220 may generate a thread ID for the new conversation.

At 2604, messaging application 240 receives another input from the user. In some embodiments, user input can be entered via windows 2702 and 2802 shown in FIGS. In response to user input indicating the start of a new conversation, messaging application 240 may cause a user device (eg, user device 242) to display window 2702 overlaid on UI 2700, as shown in FIG. The window contains multiple selectable interface elements.

Window 2702 includes representative symbols (eg, @ symbol 2704, # symbol 2706, and calendar icon 2708) corresponding to attributes associated with the new conversation. In one example, the user can select the @ symbol 2704 to add one or more participants (eg, UserA 2706 and Group1 2708) to the new conversation. In another example, the user can select the # symbol 2706 to add one or more topics (eg, topic "backlog" 2710) to the new conversation. The topic or topics may be any existing topic listed in the leftmost column of UI 2700 . In this example, the existing topic "backlog" 2710 was selected and added to the new conversation. In another example, when the calendar icon 2708 is selected, a calendar UI 2806 with selectable dates is displayed, as shown in FIG. In this example, a due date of July 17, 2020 is selected for the task assigned to the participant. Information indicating the task can be typed into input field 2808 of window 2802 .

In other embodiments, messaging application 240 may receive data indicative of messages submitted by users. This message may be entered by the user within a new or existing conversation, eg, via input area 2522 of UI 2500, as shown in FIG.

At 2606, messaging application 240 can determine that the user input includes information indicative of one or more attributes associated with the conversation. Messaging application 240 may determine that the user input indicates at least one attribute based on determining that the input is associated with a given character. For example, messaging application 240 may determine that user input indicates an attribute (eg, topic, user, or group) based on identifying a predetermined character (eg, #, @, or any other predetermined character). It can be determined to contain information. Each predefined character (or predefined characters) can represent an attribute, eg, a topic, 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 conversation.

In one example, text strings beginning with the # symbol are determined as topics to be associated with the conversation. In another example, text strings beginning with the @ symbol are determined as users or groups invited to the conversation. In another example, messaging application 240 or messaging service 220 recognizes the structure of an email address, e.g., text string (mailbox)+@+domain, and determines that user input includes an email address associated with a conversation. can do.

At 2608, messaging application 240 sends information to messaging service 220 indicating at least one attribute associated with the conversation. Upon receiving the information indicative of the attribute, messaging service 220 stores the attribute in a corresponding attribute database associated with the thread ID of the conversation. This attribute can be the topic, user or group, email address, etc. associated with the conversation. In some embodiments that provide user input by entering a message, messaging application 240 may also send message content and metadata associated with the message to messaging service 220 . The content of the message may be text, image, video, or audio content. Metadata can include a user ID (for the user who created the message), a timestamp indicating when the message was created, and the like. Upon receiving the message content and metadata, messaging service 220 stores the message content and metadata in conversation (message thread) database 230 .

FIG. 29 illustrates another exemplary process 2900 performed by a messaging application (eg, messaging application 240) consistent with this disclosure. Although described as a series of acts, those skilled in the art should appreciate that the described acts may be added, removed, reordered, or modified in various embodiments.

At 2902, messaging application 240 receives input from the user. In one example, user input can be provided by selecting the "Operator" option 2526 of the UI 2500, as shown in FIG. At 2904, in response to user input, messaging application 240 generates an interface based on attributes of the conversation in which the user is engaged. At 2906, messaging application 240 further causes the user to display an interface that allows the user to sort attributes of the conversation based on the priority attribute of the conversation.

Unlike conventional messaging systems that organize messages in a single dimension, eg, by message timing, messaging service 220 and/or messaging application 240 in accordance with the present disclosure can organize conversations in multiple dimensions. Optionally, messaging application 240 can generate an interface that includes two-dimensional representations associated with multiple conversations. Two dimensions in the two-dimensional representation are based on a first attribute associated with the plurality of conversations and a second attribute associated with the plurality of conversations. The messaging device can display an interface in which input can be provided by a user indicating a rearrangement of attributes associated with multiple conversations. The messaging device can reorganize the two-dimensional display in response to receiving input.

By way of example, and not limitation, FIG. 30 shows interface 3000 including two-dimensional table 3002 . Two-dimensional table 3002 comprises vertical axis 3004 and horizontal axis 3006 . In one example, vertical axis 3004 can list all or a subset of topics associated with a conversation in which the user is engaged. The horizontal axis 3006 can list all or a subset of users or groups that have conversations with the user (eg, users or groups that are mentioned in the conversation and begin with the @ symbol, or "mentions"). In another example, the vertical axis may list all or some of the users or groups that have conversations with the user, and the horizontal axis may list all or some of the topics associated with the conversations the user is engaging in. can be listed.

A user can drag a specific topic listed on the vertical axis 3004 or a specific mention listed on the horizontal axis 3006 and drop the specific topic or mention on a different row or column to create a two-dimensional Table 3002 can be reorganized. In one example, two-dimensional table 3002 can be reorganized by messaging application 240 based on the priority of attributes associated with conversations. Topics listed on vertical axis 3004 and/or mentions listed on horizontal axis 3006 may be organized and displayed in any manner to reflect their respective priorities. As an example and not by way of limitation, the most important attribute can be moved to the upper left corner of the two-dimensional table 3002 . In one example, the user can drag the topic that is most important to the user (eg, topic “bugs”) and drop topic “bugs” onto vertical axis 3004 . Similarly, the user can drag the mention that is most important to the user (eg, the mention “Boss”) and drop the mention “Boss” into the leftmost cell of horizontal axis 3006 . The two-dimensional table 3002 has a leftmost column 3008 and a top row 3010 with grayscale or color changes indicating the decreasing importance of the attributes listed from top to bottom and left to right, respectively. can contain. In another embodiment, the most important attribute can be moved to the bottom right corner of the two-dimensional table 3002 . The leftmost column 3008 and top row 3010 with grayscale or color changes may indicate increasing importance of the listed attributes from top to bottom and left to right, respectively.

A two-dimensional table 3002 includes a plurality of cells (intersections) defined by the columns and rows of table 3002 . Each cell in the two-dimensional table 3002 is a selectable button that allows conversations to be filtered based on the corresponding attribute (eg, topic or mention attribute). Each of the multiple intersections is associated with one or more conversations with corresponding attributes. In one example, a cell of the two-dimensional table 3002 can display the number of unread conversations. For example, the number "2" 3012 is displayed in cell 3014, indicating that there are two conversations with unread messages among the conversations with corresponding attributes (ie, Topic1 3016 and UserA 3018). In another example, different cells can have different colors or any other suitable indicators. Different colors or other indicators included in the cells can indicate different statuses of tasks associated with conversations having corresponding attributes.

In some embodiments, the UI 3000 can include an 'Enable' button 3019 that can toggle between enabled and disabled states of the 'Operator' option 2526 . In other embodiments, the UI 3000 includes slidable buttons 3018, 3020 for switching between enabled and disabled states of attributes such as topic (e.g., hashtag) attributes, mention attributes, and task status attributes; 3022 can be further included. UI 3000 includes a one-dimensional table instead of two-dimensional table 3002 when either the topic attribute or the mention attribute is disabled. If the task status attribute is disabled, the two-dimensional table 3002 does not show the task status in a different color or otherwise.

Returning to FIG. 29, at 2908, the messaging application 240 can overlay the reduced size two-dimensional representation over another user interface. The two-dimensional table 3002 shown in Figure 30 presents useful information and attributes associated with conversations to the user and allows the user to reorganize the attributes of the conversations. However, the two-dimensional table 3002 is relatively large and can occupy too much screen space. Accordingly, messaging application 240 can provide a reduced size version of two-dimensional table 3002 in response to user input. User input may be provided by selecting icon 2530 as shown in FIG.

FIG. 31 shows a reduced version 3102 of two-dimensional table 3002 . The reduced table 3102 was overlaid on another user interface 3104, as shown in FIG. Similar to the two-dimensional table 3002, the reduced table 3102 can include numbers in cells indicating unread conversations. The reduced table 3102 may also have different colors within different cells indicating different statuses of the associated tasks. Each cell in the reduced table 3102, like the cells in the two-dimensional table 3002, is also a selectable button that allows conversations to be filtered based on corresponding topic and mention attributes. A reduced two-dimensional table allows the table to be overlaid on the UI so that the user can refer to the table when using the UI. The reduced size may be predetermined based on the screen size, or defined by the user, for example by directly selecting the table and resizing it, or by entering a size range in the form.

Returning to FIG. 29, at 2910, messaging application 240 receives information indicating selection of an intersection within the two-dimensional representation. In one example, a user can select a cell within a two-dimensional table 3002, as shown in FIG. In another example, as shown in FIG. 31, the user can select a cell within the collapsed table 3102 . At 2912 , messaging application 240 can filter conversations according to selection of cells within either two-dimensional table 3002 or reduced table 3102 . Conversations are filtered by the messaging application based on certain attributes corresponding to the selected cell. For example, in response to selection of cell 3036 in two-dimensional table 3002 or cell 3106 in collapsed table 3102, messaging application 240 generates a conversation based on the corresponding attributes: topic "bugs" and mention "Boss." to filter. FIG. 32 shows the filtered results. By way of example and not limitation, conversation summaries 3206 , 3208 , 3210 , and 3212 having attributes of topic “bugs” 3202 and mention “Boss” 3204 are displayed in UI 3200 .

While the above aspects of the disclosure have been described with respect to several examples and embodiments, these are intended to be illustrative of the disclosure and not intended to be limiting. It should be understood that the subject matter presented herein can be embodied as a computer process, computer controlled device or computer system, or product such as a computer readable storage medium.

One of ordinary skill in the art will recognize that the subject matter described herein will apply to multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, handhelds, other than those described herein. It can be implemented on or in connection with other computer system configurations, including computers, personal digital assistants, electronic readers, cellular telephone devices, dedicated hardware devices, net appliances, and the like. The embodiments described herein may also be implemented 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 can be located in both local and remote memory storage devices.

A network built by an entity, such as a corporation or public sector agency, to provide one or more services accessible over the Internet and/or other networks to a set of distributed clients is called a provider network. be able to. Such Provider Network is a collection of physical and/or virtualized computer servers, storage devices, network equipment, etc. necessary to implement and deliver the infrastructure and services provided by the Provider Network. It can contain multiple data centers that host different resource pools. 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 computing instance is one or more servers with specified computing power (which can be defined by indicating the type and number of CPUs, size of main memory, etc.) and a specified software stack (e.g. , a specific version of an operating system capable of running on a hypervisor).

A number of different types of computing devices, including general purpose or special purpose computer servers, storage devices, network devices, etc., may be used individually or in combination to implement the resources and services in different embodiments. In at least some embodiments, a server or A computing device may include a general-purpose computer system that includes or is configured to access one or more databases and/or computer-accessible media.

FIG. 33 depicts such a general purpose computing device 3300 . Computing device 3300 can operate in a virtual environment, such as environment 100 in FIG. Computing device 3300 can be used to host a messaging service or messaging application. Computing device 3300 may be configured to communicate with a messaging application user's device. Computing device 3300 may be a general-purpose computing device. Computing device 3300 may be an on-premises device, such as a node of a distributed system operating within a user's data center. Components of the computing device 3300 may include one or more processors or processing units 3316, a system memory 3328, and a bus 3318 coupling various system components including the system memory 3328 to the processor 3316; It is not limited to these.

Bus 3318 in the example of FIG. 33 is some type of bus structure, 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. represents one or more of By way of example, and not limitation, such architectures include the Industry Standard Architecture (“ISA”) bus, the Micro Channel Architecture (“MCA”) bus, the Enhanced ISA (“EISA”) bus, the Video Electronics Standards Association (“VESA”) bus. ) local bus, and Peripheral Component Interconnect (“PCI”) bus.

Computing device 3300 can include a variety of computer system readable media. Such media can be any available media that can be accessed by computing device 3300 and includes both volatile and nonvolatile media, removable and non-removable media. Computing device 3300 can include system memory 3328 , which includes computer system-readable media in the form of volatile memory, such as random access memory (“RAM”) 3330 and/or cache memory 3332 . can be done. Computing device 3300 may also include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system 3334 may provide for reading from and writing to non-removable, nonvolatile magnetic media (not shown and commonly referred to as a "hard drive"). Not shown are magnetic disk drives for reading from and writing to removable non-volatile magnetic disks such as "floppy disks" and removable non-volatile optical disks such as CD-ROMs, DVD-ROMs or other optical An optical disc drive for reading from and writing to the medium may be provided. In this case, each may be connected to bus 3318 via one or more data media interfaces. Memory 3328 includes at least one program product having a set, eg, at least one, of program modules configured to perform the functions of embodiments of the present invention, as further described and explained below. can include

Computing device 3300 may include programs/utilities 3340 having a set (at least one) of program modules 3342 storable in memory 3328 . Computing device 3300 of FIG. 33 may further include an operating system, one or more messaging applications, other messaging application modules, and messaging application data. An operating system, one or more messaging applications, other messaging application modules, and messaging application data, or some combination thereof, each comprise an implementation of a network environment, such as cloud computing system 100 of FIG. be able to. Program modules 3342 generally perform the functions and/or methods of embodiments of the invention described herein.

Computing device 3300 in FIG. 33 may also communicate with one or more external devices 3314 such as keyboards, pointing devices, displays 3324 that allow a user to interact with computing device 3300 . Computing device 3300 may also include any device, such as a network card, modem, etc., that enables computing device 3300 to communicate with one or more other computing devices. Such communication may occur, for example, via I/O interface 3321 . It should be noted that computing device 3300 may be connected via network adapter 3320 to one or more networks, such as a local area network (“LAN”), a general wide area network (“WAN”), and/or a public network (eg, the Internet). can communicate with any network. As shown, network adapter 3320 communicates with other components of computing device 3300 via bus 3318 . Although not shown, it should be understood that other hardware and/or software components may also be used 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 archival storage systems.

Each of the processes, methods, and algorithms described in the preceding section may be implemented in code modules executed by one or more computers or computer processors, and may thereby be fully or partially automated. . Code modules may be stored in any type of non-transitory computer readable medium or computer storage device such as hard drives, solid state memory, optical disks, or the like. The processes and algorithms may be implemented partially or wholly in application specific circuits. The results of the disclosed processes and process steps can be stored persistently or otherwise in any type of non-transitory computer storage, such as volatile or nonvolatile storage.

The various features and processes described above may be used independently of each other or combined in various ways. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. Additionally, in some implementations, some method or process blocks may be omitted. The methods and processes described herein are not limited to any particular order, and the blocks or states associated therewith may be performed in any other suitable order. For example, blocks or states illustrated may be executed in an order other than the order specifically disclosed, or multiple blocks or states may be combined within a single block or state. Exemplary blocks or states may execute serially, in parallel, or in some other manner. Blocks or states may be added or deleted from the disclosed exemplary embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added, deleted, or rearranged compared to the disclosed exemplary embodiments.

Also, various items are shown to be stored in memory or on a storage device during use, and these items, or portions thereof, may be stored in memory or on a storage device for purposes of memory management and data integrity. It will also be appreciated that it may be transferred to and from other storage devices. Alternatively, in other embodiments, some or all of the software modules and/or system may execute in memory on separate devices and communicate with the illustrated computing system via inter-computer communications. Moreover, in some embodiments, some or all of the systems and/or modules may be implemented or provided in other ways, for example, at least partially in firmware and/or hardware, where the hardware includes: 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, Composite Including, but not limited to, programmable logic devices and the like. Some or all of the modules, systems and data structures may be placed on a computer readable medium such as a hard disk, memory, network or portable media product (e.g., software) for reading by a suitable drive or via a suitable connection. instructions or structured data). Systems, modules, and data structures may be transmitted as data signals (e.g., carrier waves or other analog or digital propagated signals) over various computer-readable transmission media, including wireless-based media and wire/cable-based media. ) and can take various forms (eg, as part of a single or multiplexed analog signal, or as a plurality of discrete digital packets or frames). In other embodiments, such computer program products may take other forms. Accordingly, the invention may be practiced with other computer system configurations.

Conditional language as used herein, e.g., "can", "could", "may", "could", "for example", etc., unless otherwise specified, or Generally, some embodiments include some features, elements and/or steps, while other embodiments generally include some features, elements and/or steps, unless otherwise understood in the context of use. It is meant to convey that it does not contain steps. Such conditional language as a whole thus means that a property, element, and/or step is required in any way by one or more embodiments, or that one or more embodiments logic for determining whether these features, elements, and/or steps are included or performed in any particular embodiment, with or without human input or prompting. It is not meant to include The terms "comprising," "including," "having," etc. are synonymous and are used inclusively and in an open-ended manner and do not exclude additional elements, features, acts, operations, and the like. Also, the term "or" is used in an inclusive (rather than exclusive) sense, so that when the term "or" is used to concatenate element lists, the term "or" means one, some, or all of the elements within.

Although several exemplary embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the inventions disclosed herein. Thus, no part of the above description should be construed as implying that any particular feature, feature, step, module, or block is essential or essential. Indeed, the novel methods and systems described herein can be embodied in various other forms. Moreover, various omissions, substitutions, and modifications may be made in the form of the methods and systems described herein without departing from the spirit of the inventions disclosed herein. The appended claims and their equivalents are intended to cover any such forms or modifications that fall within the scope and spirit of any invention disclosed herein.

Interactions in the workplace and social settings are increasingly conducted using Internet-based tools. Internet-based tools can be any software or platform. Traditional communication tools such as email can facilitate internal and external communication. However, conventional communication tools sometimes fail to meet user needs due to various restrictions. With the increasing sophistication of communication equipment, new tools are constantly being discovered to improve the efficiency and effectiveness of communication.

The following detailed description is better understood when read in conjunction with the accompanying drawings. For purposes of explanation, illustrative embodiments of various aspects of this disclosure are shown in the accompanying drawings, but the invention is not limited to the specific methods and instrumentalities disclosed.

1 illustrates an example of a cloud computing network capable of running messaging services; FIG.

1 illustrates an example messaging system according to the present disclosure; FIG.

1 illustrates an example of a messaging technique that may be implemented by a messaging service and messaging applications/services; FIG.

1 illustrates an example of a messaging technique that may be implemented by a messaging service and messaging applications/services; FIG.

FIG. 2 illustrates an exemplary data model usable in accordance with this disclosure;

FIG. 3 illustrates an exemplary process that may be performed by a messaging service consistent with this disclosure;

FIG. 4 illustrates another example process that may be performed by a messaging service consistent with this disclosure;

1 illustrates an example of a messaging technique that may be implemented by a chat service and a push service of messaging services; FIG.

[0014] FIG. 4 illustrates an exemplary user interface of a messaging application that includes conversations;

[0014] FIG. 4 illustrates an exemplary user interface of a messaging application that includes conversations;

FIG. 2 illustrates an example technique for adding topics to a conversation;

FIG. 10 illustrates an example user interface for a messaging application that enables adding topic tags to conversations.

FIG. 3 shows an exemplary user interface of a messaging application that allows conversations to be sorted by topic tags.

FIG. 3 shows an exemplary technique for creating groups and inviting members;

FIG. 10 illustrates an example user interface of a messaging application that allows new groups to be created;

FIG. 3 illustrates a group view within a messaging application user interface that can display users within a group.

FIG. 4 shows an exemplary technique for adding new members to an existing group;

FIG. 1 illustrates an exemplary technique for assigning and managing tasks using a messaging service;

FIG. 12 illustrates an example user interface of a messaging application that allows scheduling reminder dates;

FIG. 1 shows an exemplary technique for integrating email and messaging services;

FIG. 10 illustrates an example user interface of a messaging application that allows adding email addresses to conversations.

FIG. 2 shows an example of an email message received at an email address and sent from a messaging service;

FIG. 2 illustrates an example user interface of a messaging application that allows messages sent from an email address to be displayed with corresponding conversations.

FIG. 2 illustrates an example process that may be performed by a messaging application consistent with this disclosure;

FIG. 3 illustrates an exemplary user interface of a messaging application consistent with this disclosure;

FIG. 4 illustrates another example process that may be performed by a messaging application consistent with this disclosure;

[0014] Fig. 4 illustrates an exemplary user interface of a messaging application for creating a new conversation in accordance with this disclosure;

FIG. 10 illustrates another exemplary user interface of a messaging application for creating a new conversation in accordance with this disclosure;

FIG. 3 illustrates an example process that may be performed by a messaging application consistent with this disclosure;

FIG. 10 illustrates an exemplary user interface for a messaging application that is generated based on attributes of a conversation and that allows a user to provide input to reorganize the conversation.

FIG. 12 illustrates another example user interface of a messaging application with a two-dimensional representation overlaid on another user interface;

FIG. 12 illustrates another example user interface for a messaging application in which conversations are filtered according to selection of intersections in a two-dimensional representation;

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

FIG. 1 is a diagram illustrating exemplary components of a cloud computing system 100. As shown in FIG. By way of example, and not limitation, cloud computing system 100 may be used to implement 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 can be divided to some extent between clients and cloud computing devices. A “cloud” can refer to a service or group of services accessible via a network (eg, the Internet), eg, by clients, server devices, and other cloud computing systems.

In one example, multiple cloud-connected computing devices can access and use a shared pool of computing power, services, applications, storage, and files. Cloud computing thus allows a shared pool of composable computing resources, such as networks, servers, storage devices, applications, and services, that can be provided and released by cloud service providers with minimal administrative effort or interaction. enable

As an example, a cloud-based application may store a copy of data and/or executable program code on the cloud computing system and, if necessary for execution on the client device, copy this data and program code by the client device. may allow the download of at least a portion of the In some instances, the downloaded data and program code may be tailored according to the capabilities of the particular client device (e.g., personal computer, tablet computer, mobile phone and/or smart phone) accessing the cloud-based application. is possible. Additionally, splitting application execution and storage between the client device and the cloud computing system allows the cloud computing system to perform more processing, thus increasing the processing power of the cloud computing system. and functions can be used effectively.

Cloud-based computing is also a distributed computing architecture in which data and program code for cloud-based applications are shared in near real-time among one or more client devices and/or cloud computing devices. can point to Portions of this data and program code can be dynamically distributed 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 users of client devices. By way of example, and not by way of limitation, a PC user device accessing a cloud-based application may observe that the PC downloads program logic and/or data from the cloud computing system or that the PC transfers processing or storage functions to the cloud computing system. without knowing that you are offloading to

In FIG. 1, a cloud computing system 100 comprises one or more cloud services 104, one or more cloud platforms 106, cloud infrastructure components 108, and a cloud knowledge base 110. In FIG. Cloud computing system 100 may include more or fewer components, each of cloud service 104, cloud platform 106, cloud infrastructure component 108, and cloud knowledge base 110 further comprising multiple computing elements and storage. can contain elements. Accordingly, one or more of the aforementioned functions of cloud computing system 100 may be divided into additional functional or physical components or combined into fewer functional or physical components. In some other examples, additional functionality and/or physical components may be added to the example shown in FIG. The delivery of cloud computing-based services may involve multiple cloud components communicating with each other through application programming interfaces such as web services and multi-tier architectures.

The exemplary cloud computing system 100 shown in FIG. 1 is a network 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 client interface front end. Cloud platform 106 can be coupled to cloud service 104 to perform functions for interacting with client devices. Cloud infrastructure 108 may include services, payments, and other operational and infrastructure components of cloud computing system 100 . As cloud knowledge base 110 is configured to store data used by cloud computing system 100, cloud knowledge base 110 may be any of cloud services 104, cloud platform 106, and/or cloud infrastructure components 108. is accessible by

Many different types of client devices, such as those of messaging service users, may communicate with components of cloud computing system 100 to access data and run applications provided by cloud computing system 100 . can be configured. For example, computer 112 , mobile device 114 , and host 116 are shown as examples of the types of client devices that can be configured to communicate with cloud computing system 100 . Of course, more or fewer client devices may communicate with cloud computing system 100 . Additionally, other types of client devices may be configured to communicate with cloud computing system 100 .

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

In FIG. 1, communication links between client devices and cloud 100 may comprise wired connections, such as serial or parallel buses, Ethernet, optical connections, or other types of wired connections. Communication links may also refer to wireless links, such as Bluetooth®, IEEE 802.11 (IEEE 802.11 may refer to IEEE 802.11-2007, IEEE 802.11n-2009, or any other IEEE 802.11 revision). ), CDMA, 3G, GSM, WiMAX, or other radio-based data communication link.

In other examples, client devices may be configured to communicate with cloud computing system 100 via wireless access points. Access points can take various forms. For example, an access point can take the form of a wireless access point (WAP) or wireless router. As another example, when a client device connects using a cellular air interface protocol such as CDMA, GSM, 3G, or 4G, the access point is a base station within the cellular network that provides Internet connectivity over the cellular network. can be

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

FIG. 2 shows an exemplary messaging service 220 for performing the disclosed techniques. By way of example, and not limitation, messaging service 220 may operate on cloud network 100 of FIG. 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 program running on the device of messaging service 220 .

Chat service 222 may be configured to receive input from user 210 . Users 210 may register as users of messaging service 220 in order to exchange messages with each other within messaging service 220 . User 210 may be a user of messaging application 240 running on user device 242 . User input may include a request to initiate a conversation. A conversation may be initiated by selecting a “Start Conversation” icon within the user interface (UI) of messaging application 240 running on any user device 242 . A conversation can be initiated by the creator user without any other participants in the conversation being identified. Conversation participants include any entity that is permitted to participate in the conversation in any way. For example, a conversation participant can be a creator user, a group invited to join the conversation, an assigner user who can assign a task to another participant (assignee user), an assignee user, a conversation e-mail participants invited to

Chat service 222 can generate and/or manage conversations. For example, chat service 222 can categorize conversations. Chat service 222 includes 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, and email message database 238. can store conversations, any associations with conversations, and/or conversation metadata. Inputs can include messages, such as messages to add to an existing conversation or a new conversation. Chat service 222 can add messages to the conversation. Chat service 222 may store messages and/or message associations in a database, such as conversation database 230 .

The messaging service 220 can determine that the message includes information that identifies the user, such as username, handle (ie, username beginning with @), account, and the like. Messaging service 220 can add the identified user to the conversation. Messaging service 220 may store user-conversation associations in conversation database 230, group database 232, user database 234, and/or search index database 252, for example. A user may be granted access to a conversation, for example, to view a feed of messages previously communicated within the conversation.

Messaging service 220 can determine that the message includes information indicative of the topic. Topics can be associated with corresponding conversations. Messaging service 220 may add topics to one or more databases, such as topic database 236 . Messaging service 220 may store topic-conversation associations in conversation database 230 and/or topic database 236, for example.

Messaging service 220 can determine that the message includes information identifying the group. A group may be a user group. The messaging service 220 can add groups to conversations. Messaging service 220 may store associations of groups and conversations in conversation database 230, group database 232, user database 234, and/or search index database 252, for example.

The messaging service 220 can determine that the message contains information indicating the tasks assigned to the user. The messaging service 220 can also receive information indicating due dates for tasks. Tasks and due dates can be associated with users and conversations. Messaging service 220 may add tasks and due dates to database 260 , eg, task database 256 . Messaging service 220 can store task, due date, user and conversation associations in conversation database 230, user database 234, and task database 256, for example.

Messaging service 220 may determine that the message may include an email address. An email address can be associated with the conversation. The email address may be the intended recipient of messages in conversation. The messaging service 220 can add email addresses to conversations. Messaging service 220 may store the association of email addresses with conversations in conversation database 230, email user database 237, and/or email message database 238, for example.

Messaging service 220 may include push service 224 . Push service 224 may be a device and/or program running on the device of messaging service 220 . Push service 224 may receive data, such as user input instructions, from chat service 222 . Push service 224 may store data in and/or access data in database 260 . Push service 224 can push (eg, transmit, display, etc.) data, such as user input instructions, to the user device, eg, via messaging application 240 . Push service 224 can push data to email addresses outside of messaging service 220 .

Messaging service 220 may include other services. Other services may include group services 251 . Group service 251 can manage user groups. Group services 251 can manage stored group associations. The group service 251 can 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 the association of due dates with tasks. A reminder/scheduler service 253 can send reminders associated with due dates and/or tasks. The reminder/scheduler service 253 can manage stored due dates and/or tasks.

Other services may include email service 254 . Email service 254 can generate email messages and send email messages to email addresses outside of messaging service 220 . Email service 254 can receive data from email addresses external to messaging service 220 . The e-mail service 254 can determine the conversation associated with data received from the e-mail address and generate a corresponding message to be sent to the users in the conversation. Other services may further include authentication services 226 . Authentication service 226 can authorize and verify access to various conversations. Authentication service 226 can grant tiered privileges to conversation participants. For example, only participants with a certain level of authority are allowed to add other participants, assign tasks, etc.

It should be appreciated that the messaging service 220 of FIG. 2 is merely exemplary and that other implementations may be used. It should also be understood that the functionality disclosed herein may be implemented by one or more servers or computing devices. Furthermore, it should be understood that the functionality disclosed herein can be implemented in software, hardware, or a combination of software and hardware.

FIG. 3 shows an example messaging service 220 . Messaging service 220 may communicate with network 301 . Network 301 may include the Internet. Network 301 may include one or more cloud network components. Network 301 may communicate with one or more databases 260 over the network. Database 260 may be the same as or similar to databases 230-238 of FIG. By way of example, databases 260 may include topic databases, conversation databases, user databases, and/or tag databases. Messaging service 220 may store attributes and/or associations in database 260 . Messaging service 220 may access (eg, query) database 260 for attributes, associations, or other data.

Messaging service 220 may communicate with one or more user devices 242 over network 301 . Messaging service 220 may communicate with device 302 via messaging application 240 running on user device 242 . 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 can communicate with users 210 connected via network 301 . A connected user 210 may be a user who is a participant in a conversation of messaging service 220 and/or messaging application 240 . For example, connected user 210 can receive messages associated with the conversation via an external email address. Connected users 210 can send messages to messaging service 220, messaging application 240, conversations, and/or other users from external email addresses.

FIG. 4 shows messaging technique 400 . Technology 400 may include a messaging service (eg, messaging service 220 of FIGS. 2 and 3), a messaging application (eg, messaging application 240 of FIGS. 2 and 3), one or more users 210, and/or one or more It can be performed by multiple user devices 242 . At 401, a conversation can be initiated. A conversation can be initiated by an author user (ie, the user who causes the creation of the conversation) by entering input requesting initiation of the conversation via the messaging application. For example, a user may select a "Start a conversation" icon within the UI of a messaging application displayed on the user device. A chat service (eg, chat service 222 of FIG. 2) can receive input and generate conversations. A conversation can begin without any other participants in the conversation being identified.

At 402, a message can be entered. Messages can be put in by users via messaging applications. Messages can be entered into conversations, for example, via input fields displayed on the UI of the messaging application. This message can be entered before any other participants in the conversation are identified. A message can contain text. A chat service can receive messages. This message can be added to the conversation. A message can be sent to one or more users associated with the conversation. This message can be sent to one or more external users, eg, external email addresses that have been added to the conversation. Associations between messages and conversations can be stored in a database (eg, database 260 of FIGS. 2-3).

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

At 404, the content of the message can be stored in a content database (eg, database 260 of FIGS. 2-3). Associations between content and one or more users (eg, users tagged in messages) can be stored in databases such as user database 234, group database 232, search index database 252, and the like. The content and/or associations can be stored in a database by a messaging service (eg, messaging service 220 of FIGS. 2-3).

At 405 , attributes of the message can 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 . Associations between attributes and message content can also be stored in the attribute database and any other database. For example, as shown in FIGS. 2-3, attributes and/or associations may be stored in database 260 by messaging service 220 .

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

In contrast to most messaging systems based on direct exchanges between users, in some embodiments, messaging systems (e.g., messaging services and messaging applications) according to the present disclosure are more message-centric, where messages are content and the user is an attribute of the content. For example, the techniques of this disclosure need not identify recipients or subscribers of a conversation. Instead, the messaging system allows a conversation, e.g., a series of messages, to be created by a creator user (e.g., the user who initiates creation of the conversation) without any other participants being identified. do. Conversation participants are the creator users, not just the recipients. Author users can post messages, label conversation topics, add other participants to the conversation, assign tasks to other participants, and so on.

After creating a conversation, other participants can be added to the conversation. Unlike most messaging systems where conversation participants are defined at the beginning of the conversation, our messaging system allows participants to join the conversation at any time. Participants can join an existing conversation by including the username, group name, or email address of a user of the messaging service within the conversation. Participants can then receive past and future messages, such as feeds or notifications, that are added to and conveyed within the conversation. Added participants participate in the conversation by, for example, posting messages within the conversation, labeling topics of the conversation, assigning tasks, and/or adding other participants to the conversation. can do.

FIG. 5 is a diagram illustrating an exemplary embodiment of a data model consistent with this disclosure. It should be appreciated that the exemplary data model of FIG. 5 is merely exemplary and that other configurations can be used. As shown, the data model is conversation-centric. In other words, conversations are the primary data in the database. Other data such as user data, topic data, task data are attributes of the conversation. As shown, the messaging service conversation database 230 includes a plurality of conversations. Conversation database 230 includes multiple tables. For example, thread table 502 , message table 504 , and content table 506 are all stored in conversation database 230 .

Thread table 502 includes items such as Thread_ID, User_ID, and Created_Time. Thread_ID is the primary key that references other data and attributes. For example, Thread_ID is used to look up messages associated with a particular Thread_ID. The Thread_ID is also used to look up attributes in the attribute database associated with the thread identified by the Thread_ID, as described more fully below. Before describing the attribute database, the records stored in the conversation database 230 will be described in greater detail.

For conversation database 230, each time a new thread (e.g., a new conversation) is created by a user, the message service generates and assigns a new Thread_ID, the User_ID of the user who created the thread, and the time the thread was created (Created_Time ) to create a new record in the thread table. Additionally, information associated with each message within a particular thread (e.g., a particular conversation) includes the Thread_ID, User_ID (for the user who created the message), Message_ID identifying each message, the time the message was created (Created_Time ), and an entry (Is_Mentioned) identifying other users or groups that may have been mentioned and added during the conversation. A user or group mentioned (eg, starting with an @ symbol) during a conversation is referred to below as a "mention." The content of each message is stored separately in content table 506 and can be referenced by the corresponding message ID. This is because the stored size of a message can vary greatly depending on whether the message is a short string or contains some form of media such as JPEG or video.

As previously mentioned, each thread (conversation) can have attributes associated with it. These attributes are referenced by the conversation's Thread_ID. For example, Thread_ID is a key included in each attribute database that can be used to look up all attributes associated with a particular conversation. As shown in Figure 5, the user is an attribute of the conversation. The users associated with a particular conversation can be determined by searching the user database 234 for all users associated with a particular Thread_ID corresponding to the particular conversation. The search returns all matching User_IDs.

Similarly, a search of the e-mail message database 238 returns all User_IDs of users associated with the thread via e-mail. That is, each time an email address is added to a conversation, a new record is created in email message database 238 . Each record stores the User_ID of the user who added the email address in the conversation. Additionally, a Return_Email address corresponding to the conversation is assigned by a messaging service (eg, messaging service 220 ) and stored in email message database 238 . Each email participant (participant added by email address) is assigned a Mail_Box_User_ID that can be used to look up the associated Email_Address. The e-mail address is stored with the Message_ID of the message containing this e-mail address. The message content of each e-mail message is also stored in the e-mail message database 238 (e.g., e-mail attribute tables 522 and 520).

The attribute database further includes, for example, a group database (eg, group database 232). Group database 232 stores information (eg, group attributes) about groups associated with conversations. The data stored in the group database 232 includes one or more of Thread_ID, Group_ID, Created_Time (the time the group was created). Group_ID contains Group_Name (group name), Owner_User_ID (group owner, e.g. User_ID of the creator of the group), group type (private or public group, etc.), joining time (time when a member joined the group), and association with the group. Also used to indicate the record containing the state

In one embodiment, the attribute database includes a task database (eg, task database 256) that stores information (eg, task attributes) indicative of task assignments associated with conversations. Task attributes stored in the task database 256 are also referenced by the Thread_ID of each conversation. Some of the data and information stored in task database 256 includes due dates (effectively due dates), assignee and assignee user IDs (Assignor_User_ID and Assignee_User_ID), and states (eg, status). be Created time, verified time, and last updated time can also be associated with records stored for a task.

According to one embodiment, the attribute database further includes a topic database (eg, topic database 236) that stores information (eg, topic attributes) indicative of topics associated with the conversation. The topic database is referenced by each conversation's Thread_ID, is associated with the conversation, and generally includes the user ID, Topic_ID, and time created associated with each topic. Topic_ID is used to refer to the topic name (Topic_Name). Each time a new topic is added to a conversation, e.g., by an entry into a message that begins with a hashtag within the conversation, the messaging service (e.g., messaging service 220) stores an entry in topic database 236 referenced by the conversation's Thread_ID. do.

As noted above, all of these various attributes are associated with a Thread_ID that is generated when a new thread (eg, new conversation) is created in a messaging service (eg, messaging service 220). Accordingly, the messaging service 220 can retrieve and retrieve various attributes associated with conversations. Conversation and thread are used somewhat interchangeably herein. In one example, message thread database 230 and multiple attribute databases (eg, topic database 236, task database 256, group database 232, email message database 238, and user database 234) can be stored on the same server or device. is. In another example, message thread database 230 and multiple attribute databases may each be stored on a different server or device. The message thread database 230 and multiple attribute databases can be hosted on one or more physical servers or one or more virtual servers.

FIG. 6 shows an exemplary process 600 performed by a messaging service (eg, messaging service 220) in relation to the data model shown in FIG. Although illustrated as a series of acts in FIG. 6, those of ordinary skill in the art will appreciate that the described acts may be added, removed, reordered, or modified in various embodiments.

At 602 , messaging service 220 receives a request from a messaging application, eg, messaging application 240 running on user device 242 , indicating at least one of the conversations. For example, a user may be requesting information through messaging application 240 indicating attributes associated with one or more conversations in which the user is participating. For example, messaging application 240 running on user device 242 may request information indicating attributes (eg, topics, users, groups, tasks) associated with conversations for the user. In response to this request, at 604 the messaging service 220 looks up all Thread_IDs associated with the user's User_ID in the user database 234 and also queries other attribute databases to identify threads based on these Thread_IDs. Determine various attributes associated with the spoken conversation. In one example, the messaging service 220 can look up all topics in the topic database associated with the Thread_ID. At 606, messaging service 220 processes the query results to determine that at least one attribute (eg, topic attribute) is associated with at least some of the conversations.

At 608 , messaging service 220 transmits attribute information associated with the conversation to messaging application 240 for displaying an indicator of the attribute on user device 242 . For example, as shown in FIG. 12, multiple topics associated with a conversation are displayed in the leftmost column 1205 of a user interface (UI) 1200. In FIG. In some embodiments, multiple attributes may exist and may be assigned different priorities by messaging service 220 or messaging application 240 . Messaging service 220 or messaging application 240 may organize attributes based on their priority. In one example, the mention (ie user or group added to the conversation) attribute may have higher priority than the topic attribute. For example, the mention attributes in FIG. 25 (eg, UserE 2501 and Group1 2504) can be assigned higher priority than topic attributes. The attribute indicators in FIG. 25 are displayed based on the mention attribute and can display one or more topics (if any) under the mention attribute. In one example, multiple topics may be associated with a conversation with a particular mention attribute. As shown in FIG. 25, a conversation having a mention attribute UserE 2501 is associated with multiple topics (including a topic 2502 called "patent"), and in this example, the mention attribute has higher priority than the topic attribute. Since it is high, multiple topics are displayed under the mention attribute UserE 2501 .

In some embodiments, in response to receiving a request from messaging application 240, messaging service 220 queries database 260 (e.g., user database 234, task database 256, etc.) to associate any particular user. can determine the tasks to be performed. For example, messaging service 220 receives a request from messaging application 240 that includes identifying information for a particular user (eg, user ID). In response, messaging service 220 searches user database 234 based on the user ID to identify the Thread_ID corresponding to the conversation in which the user is engaged. Messaging service 220 can then query task database 256 based on the Thread_ID to look up the task associated with the conversation. Messaging service 220 may identify the Assignor_User_ID and Assignee_User_ID for each task based on searching task database 256 . The messaging service 220 then determines whether any of the tasks are associated with the particular user based on determining whether the identified Assignor_User_ID or Assignee_User_ID is the same as the particular user's user ID. It is possible to determine whether or not 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 for display of the tasks associated with the particular user. In one example, messaging application 240 can sort or order tasks based on due dates associated with the tasks. In another example, messaging application 240 can sort or order tasks based on information associated with the assignee or assignee of the task. The messaging application 240 can cause the categorized or ordered tasks to be displayed within a predetermined area of the UI or in a window overlaid on the UI.

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

FIG. 7 illustrates another example process 700 that illustrates interactions between a messaging application (eg, messaging application 240) and a data model maintained in messaging service 220. As shown in FIG. Although illustrated as a series of acts in FIG. 6, those of ordinary skill in the art will appreciate that the described acts may be added, removed, reordered, or modified in various embodiments. In another embodiment, messaging service 220 receives a request at 702 from a messaging application associated with a user (eg, messaging application 240 running on user device 242) to indicate at least one of the conversations. In response, messaging service 220 queries message thread database 230 at 704 . For example, the messaging service 220 looks up corresponding conversations in which the user has already participated. The messaging service 220 then processes 706 the query results to determine a subset of messages within each conversation. In one embodiment, the subset of messages in each conversation may be the first and last messages in the conversation. Messaging service 220 can create a summary of each conversation based on a subset of messages. At 708, messaging service 220 sends a subset of the messages to messaging application 240 to display a summary of each conversation. For example, as shown in FIG. 12, a conversation summary is displayed in middle area 1216 of UI 1200 .

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

FIG. 8 is a diagram illustrating a messaging technique. A technology may be a messaging service (eg, messaging service 220 of FIGS. 2 and 3), a messaging application (eg, messaging application 240 of FIGS. 2 and 3), one or more users 210, and/or one or more can be performed by the user device 242 of At 801, a conversation can be initiated. A conversation can be initiated by an author user by entering input requesting the initiation of a conversation via a messaging application. For example, a user may select a "Start a conversation" icon in the UI of a messaging application displayed on the user device. A chat service of the messaging service (eg, chat service 222 of FIG. 2) can receive input and generate conversations. A conversation can be initiated by the creator user without any other participants in the conversation being identified.

At 802, when a message is received via messaging service 220, such as chat service 222, a lookup can be performed for all participants in the conversation (eg, the creator user and any other participants). can. The content of the message can be determined. The content can be parsed by a messaging service 220 such as chat service 222 . Analyzing the content can include determining one or more attributes of the messages and/or conversations. For example, content may include text consisting of predetermined special characters representing attributes such as topics, users, and/or user groups. This lookup can be performed by messaging service 220 , eg, chat service 222 . This lookup can be performed by querying one or more databases 260 . Databases 260 may include conversation database 230 , group database 232 , user database 234 , topic database 236 , task database 256 , email user database 237 , and/or email message database 238 . The association of participants with conversations may be stored in database 260 by chat service 222, for example.

At 803, topics associated with the conversation can be determined. Topics can be determined by messaging service 220 , eg, chat service 222 . The messaging service 220 can parse the message and determine that the message contains information indicative of the topic based on identifying predetermined characters in the message. By way of example and not limitation, the predetermined character may be the hash symbol #. Messaging service 220 determines whether any messages associated with previously received conversations include new topics by searching existing topics stored in database 260 (eg, topic database 236). be able to. Upon determining a new topic, messaging service 220 may store the new topic in database 260 (eg, topic database 236). Associations between conversations and topics may also be determined and stored in databases 260 , such as conversation database 230 and topic database 236 .

At 804, the message and indication of the new topic can be output (eg, pushed, sent). The new topic indication (eg, new topic tag) can be sent by a push service (eg, push service 224) to a messaging application (eg, messaging application 240) associated with the conversation participant for display. can. A message associated with the topic may be output by push service 224 of messaging service 220 upon receipt of user input indicating selection of a topic. Messages and topic tags can be output to users of messaging applications, for example, via conversations within the UI of messaging application 240 running on user device 242 . The message and topic tags can be sent to a user device (eg, user device 242). Messages and topic tags can be sent to external email addresses that have been added to the conversation.

At 805, new participant A can be invited to join the conversation. A new participant A can be invited by an existing participant, for example by entering a username, group name, or email address associated with the new participant A in an input field of the conversation. Messaging service 220 (eg, chat service 222) can add the new participant A to the conversation. The messaging service (eg, chat service 222 ) may store the association of new participant A with the conversation in database 260 , eg, in conversation database 230 and user database 234 .

At 806, a lookup of existing participants in the conversation can be performed. This lookup can be performed by messaging service 220 , eg, chat service 222 . Chat service 222 can send an indication of the determined participants in the conversation to push service 224 .

At 807, existing participants in the conversation can be notified that new participant A has been added to the conversation. A push service 224 can notify existing participants. Notifying the existing participants may include sending a notification to the existing participants' user devices (eg, user device 242). Existing participants can be notified via conversations and/or UIs of messaging applications running on their devices.

At 808, the content of messages associated with the conversation can be determined. The content can be parsed by a messaging service 220 such as chat service 222 . Analyzing the content may include determining one or more attributes of the content of the message. For example, it may be determined that the message contains text consisting of special characters representing attributes such as new participant A. As an example and not by way of limitation, a predetermined special character representing a new user (ie, a new participant) may be the @ symbol. Conversation lookups can be performed by querying databases 260, such as conversation database 230 and topic database 236, for example. A conversation lookup can be performed to determine the users, messages, topics, and other attributes associated with the conversation. Chat service 222 may send an indication of the results of parsing and/or conversation lookup to push service 224 .

At 809, conversation lookup results, eg, messages and topic tags, can be output (eg, pushed) to the new participant A. Messages and topic tags can be output by push service 224 . Outputting the message and topic tags may be performed by, for example, adding the message and topic tags to a new participant via a conversation within a UI of a messaging application (eg, messaging application 240) running on a user device (eg, user device 242). can include sending to a person. The message and topic tag can be sent to the user device associated with the new participant A (eg, user device 242). Messages in the conversation can be sent to the external email address associated with the new Participant A. The messaging service according to the present disclosure classifies conversations based on attributes of topics associated with the conversations, and provides the participants with the content of the conversation in response to the selection of topic tags that indicate topics of conversation that the participants are interested in. can provide. This allows the message service to more efficiently provide content of interest to users.

FIG. 9, in conjunction with FIG. 8, illustrates starting a new conversation and adding users to the new conversation. As described with respect to Figure 4, the user initiates a new conversation. A user may initiate a new conversation by selecting the “Start a conversation” button 917 . This is shown in FIG. 9 from the perspective of a user interface 900 operating on a user device (eg, user device 242). Here, a user (eg, User A) initiates a conversation 901 and enters the message “#tag-patent” 903 . Since there are no other users associated with message 903, the message appears only within conversation 901 of a single user, User A, who is also the creator of the conversation (ie, the creator user). This allows the creator user to continue adding messages to conversation 901 . As explained more fully below, the message "#tag-patent" contains the topic ("patent") entered as at least part of the initial message. At any time during the conversation you can enter a message containing the topic. In one embodiment, the messages are processed by a messaging service and stored in a database as attributes associated with conversation 901 . Similarly, as described, other participants in conversation 901 (eg, messaging service users with access permissions to conversation 901) can be added to conversation 901 as attributes of conversation 901. FIG.

Referring again to FIG. 8, a conversation creator user can invite new users (ie, new participants) to join the conversation. In some embodiments, the messaging service communicates with the databases 260 described and uses the chat service 222 and push service 224 described above. Continuing with the example, at 810, a user can initiate a conversation that includes one or more messages. A message may contain multiple characters, symbols, be a text string, or other type of content. When a new message is added to a conversation, chat service 222 determines which users are attributes of the conversation, ie, users associated with the conversation. These attributes are stored in one or more databases. Such databases include conversation databases (eg, conversation database 230), group databases (eg, group database 232), topic databases (eg, topic database 236), and email user databases (eg, email user database 237). including but not limited to. Conversation participants can be identified and notified of the conversation.

As messages are received during a conversation, the messaging service (e.g., messaging service 220) may determine whether new topics are included in the messages that form the conversation, such as topic database 236. Existing topics may be searched in one or more databases. Thus, the attributes of the conversation, eg, topic, user, group, etc., ensure that the conversation is properly categorized, eg, based on topic, and that new conversations are pushed out to participants. The push service 224 facilitates the output of messages, existing topic tags, and new topic tags to intended participants. In some embodiments, this can occur by pushing a message to a user interface or user display on a device associated with the intended participant of the conversation.

In another example, the user may be invited to join the conversation. For example, at 805, a new Participant A can be invited to join an existing conversation, whereby a messaging service (eg, messaging service 220) shares information related to the conversation with the new Participant A. allowed to do. The chat service 222 handles this actuation and, at 506, looks up all existing participants associated with the conversation, as in the previous example, and optionally in one or more databases 260 (e.g., Communicate with databases 230-236) to obtain relevant information. Once the participants are identified, the push service 224 notifies the identified existing participants associated with the conversation at 807 to indicate to the existing participants that a new participant has been added to the conversation. .

After a new Participant A is invited to join the Conversation, the message, content, and/or metadata associated with the Conversation can be sent to the new Participant so that the push service can send relevant aspects of the Conversation to the new Participant, e.g. Retrieve from conversation database 230 and topic database 236 . FIG. 9 shows an exemplary user interface (UI) 900 of aspects of techniques for inviting new users to join a conversation. In FIG. 9, UI 900 is shown as being presented on a user device (eg, user device 242) through, for example, a messaging application (messaging application 240). In this example, and as shown in UI 900 , User A has initiated a conversation 901 that includes one or more messages 902 . In this example, the message “Hello” has been added to conversation 901 . Additionally, another message was added to conversation 901 with topic “patent” 903 . The conversation 901 can be stored in database 260 , eg, conversation database 230 . To add a new user, the message field 904 of the UI 900 contains information identifying the user using the @ symbol 905 or other predetermined special characters followed by a text string 906 that identifies the user, for example by username. input. Here, User C's username has been entered in the text field beginning with the @ symbol.

In one embodiment, after the user selects the "Send" button 907, the message is sent to a messaging service (eg, messaging service 220). The messaging service then parses the message, for example as shown in FIG. 4, to determine that the message contains a predetermined @ symbol 905, and interprets the text following the message 906 as user identification information. The messaging service then interprets this message as User A's request to allow the system to add identified User C (ie, a new participant) to the conversation. Other embodiments are also envisioned, for example, the messaging application on the user device parses the message and the user wishes to allow an identified user C (i.e., a new participant) to join the conversation. An indicator can be sent to the messaging service indicating that the In other words, the processing of the message can be partly done on the user device and part of the processing can be done by the messaging service.

At a particular event, once authorized, the cloud service can add information identifying the new participant (eg, the new participant's username) as an attribute of the conversation. To this end, the user is associated with conversation 901 and the association is stored in database 260 . It should be appreciated that multiple symbols, text, characters, etc. can be defined as indicators associated with identifying a particular user. In this particular example, the @ sign is the pre-determined symbol for adding a new user, the user enters the new username as "@UserC", and "@UserC" is a new participant in conversation 901 via the messaging service. recognized as a person.

FIG. 10 shows aspects of the properties from the UI 1000 perspective after a new participant 1002 (eg, user C) has been added to the conversation 1001 . In this example, the username of new participant 1002 becomes another message in conversation 1001 as shown. In other words, the addition of a new participant to conversation 1001 is stored within the text of conversation 1001 itself. Therefore, by analyzing the messages in Conversation 1001, the order and time in which new participants and other attributes are added to Conversation 1001 can be discerned. For example, after a new participating User C was added, a user (eg, User A) also put another message into Conversation 1001 at 9:31 PM, including the topic "#tag-patent1". Thus, a user (e.g., User A) adds one or more users associated with Conversation 1001 by adding new users to the Conversation and putting messages, e.g., "#tag-patent", "#tag-patent1". topic can be specified. As shown in FIG. 2, these particular messages within conversation 1001 also become attributes of the conversation that are stored in various attribute databases, such as topic database 236 and user database 234 . In embodiments, attributes may be defined using different symbols, letters, characters, for example, using @ to indicate that a username or other user identifying information is entered and the topic is conversation 1001 The hashtag # can be used to indicate that it is associated with. It is envisioned that other symbols can be used to add additional attributes to the conversation.

Figures 9-10 also show that conversations can be sorted by topic, as indicated by the leftmost columns 909, 1009, for example. The illustrated example shows conversations labeled as a "Feed" view 908, 1008 sorted by attributes such as topic attributes. Selecting a feed displays a list of one or more conversations in a condensed version associated with the selected topic of the conversation. In one embodiment, selecting a condensed version of a conversation displays one or more messages associated with the selected conversation. Here, for example, a condensed version (or abstract, summary) of the conversation is displayed, with the author of the conversation listed at the top, followed by the first message in the conversation "UserB Hello" 910, 1010, Then follows the last message in the conversation, namely the message "#tag-patent1" 911, 1011 for adding a second topic. The condensed version (or abstract, summary) of the conversation presents the user with a preview of the conversation, which allows the user to see if he or she is interested in the conversation or not, by selecting the conversation summary. You can decide whether you want to review the contents of the . Topics (shown as topic tags on the UI) serve as short descriptors of the content of the conversation.

In other embodiments, as described below, conversations may be sorted by one or more other categories and classifications, Groups views 912, 1012, and conversations and messages may be and each of the messages is organized based on a group of subjects. These are further described in other embodiments below.

FIG. 11 illustrates an embodiment for adding topic tags to conversations and adding new messages to conversations. As previously mentioned, topic tags that correspond to topics are attributes of conversations that are used, for example, in feed views to facilitate sorting, managing, and selecting conversations. One or more topics can be associated with a conversation via such topic tags. By way of example, and not limitation, a topic tag can be a text string with a leading character that indicates that the following text contains the topic. In this embodiment, the hash sign or "#" is a predetermined character recognized by the messaging service to represent a topic. A user (ie, a participant) can initiate a conversation. In this example, the user also adds a topic to the conversation at 1110 . The chat service 222 can then receive the new conversation indication and parse the message to detect the presence of the topic. As described above, parsing of messages may be performed by a messaging service (eg, messaging service 220), by a messaging application (eg, messaging application 240) on a user device (eg, user device 242), or by some of the two. It can be done in combination. After a conversation is initiated by entering a message, for example a message containing a topic, a lookup 830 is performed to determine if any other users or participants are relevant attributes of the conversation. . A lookup may be performed by one or more searches of databases 260 such as conversation database 230 , group database 232 , user database 234 , and topic database 236 .

Once the relevant users (ie, participants in the conversation) are identified, at 840 the conversation is added to the topic tag taxonomy of all tracked participants stored in various databases. In other words, an association between the new conversation and the specified topic tag can be stored, and the association can be stored to associate all users who are associated with the topic tag and who are also associated with the conversation. Conversations are therefore summarized for all participants 1150 in relation to topic tags. For example, when a user is added to a conversation, the user can receive a condensed version of the topic consisting of the first and last messages. The push service 224 further processes such messages and at 1152 outputs the messages, eg, on a user display, sends them to respective users, and displays respective views of existing and new tags, eg, such Within the feed view of conversations sorted by tags, it can be possible to make updates.

In another embodiment, shown in FIG. 11, topic tag properties are incorporated into existing conversations. For example, at 1115 a new message with a topic indication can be added to an existing conversation. Similar to the process described above, receipt of a message containing information indicative of a topic causes a lookup of all participants in the conversation at 1135 . Associations between topics and conversations and between participants and topics are stored in databases 260, such as conversation database 230, topic database 236, users database 234, groups database 232, and email users database 237. be able to. At 1145, a lookup of other existing topic tags is performed to determine whether the topic is a new topic, for example, if there are multiple topic tags present in and associated with the conversation. can judge. At 1156, messaging service 220, eg, push service 224, then pushes the message and a new topic tag corresponding to the new topic to each participant.

An example of these techniques will be described using examples of user interfaces in FIGS. 12 and 13. FIG. FIG. 12 shows a feed view 1208 of an example messaging application that provides a list 1215 of topic tags. In this example, Conversation 1201 includes a message "#tag-patent" that includes a topic that begins with the predetermined character "#". As previously mentioned, the predetermined character representing the topic may be any other special character such as the % sign. If the messaging service determines that the message includes a new topic based on determining that the message includes the predetermined character # and searching database 260, then the conversation is categorized as a conversation associated with the new topic. Added to the list. Thus, when the corresponding topic tag is selected from feed view 1208 via the UI of a messaging application (e.g., messaging application 240), current conversation 1201 and all other conversations associated with the new topic are all of the conversations. can be easily viewed and organized by all participants.

FIG. 13 further illustrates this concept and the ability to sort conversations based on topic. Here, the user has selected the topic tag “#tag-patent” 1316 in the leftmost column 1315 of the UI 1300 . This causes the messaging service to push a condensed version of each conversation related to the user and the selected topic. When the topic tag “#tag-patent” 1316 is selected, the messaging service also pushes the content of the corresponding conversation to the rightmost area 1325 of the UI 1300 to display the messages in the conversation. These conversations are then displayed in the feed view 1308 without displaying other, irrelevant conversations. The order of topic tags displayed in feed view 1308 can be arranged according to user preferences such as the priority and importance of each topic. Conversations associated with each topic tag can also be sorted based on one or more variables such as time, last message received, priority, user preferences, and the like. Similarly, each conversation contains multiple messages, and users associated with a particular conversation can view messages, send messages, and add attributes such as additional users, topics, groups, etc. described herein. can do.

In various embodiments, a user can generate a conversation consisting of one or more messages that can include attributes. The message may be parsed and based on which one or more messages are parsed, it may be determined that the message includes strings that indicate attributes, such as users, topics, groups, and the like. Attributes can be stored in at least one database as associations between information indicative of topics and conversations. In response to receiving input from a messaging application (e.g., messaging application 240) indicating a selection of a topic, a messaging service (e.g., messaging service 220) renders at least a subset of the conversations associated with that topic to the messaging application for display. 240.

In additional embodiments, the messaging service further determines that the topic is new by searching at least one database containing information related to the topic, and based on determining that the topic is new, provides information indicative of the topic. Stored in the at least one database. In another example, a second message within the conversation can be parsed. It may be determined that the second message contains information identifying the second user, thereby allowing the second user to add the message to the conversation. The information indicative of the topic may be sent, for example, to one or more messaging applications operated by one or more other users, and the database stores a plurality of attributes, such as topic, associated with each conversation. Additionally, multiple conversations may be stored.

By using a messaging service that can include at least one database and at least one computing device in communication with the at least one database and configured to perform operations, one or more characteristics and functions can be realized. Further, various aspects of processing may be split between messaging applications and messaging services. In some embodiments, it is preferable to have the messaging app perform the actions, and in other embodiments the same actions may be performed by the service.

In feed view 1308, a conversation can be started, for example, by selecting an icon, eg, “Start a Conversation” icon 1317 . Unlike other messaging applications, conversations may be organized by topic, not just by user. Topics can be defined by the user at the beginning of the conversation. For example, a creator user who initiates conversation 1301 can assign topics to conversation 1301 . Topics can also be defined by other participants at other stages of the conversation. Topics can be represented by special characters or tags, such as the "#" symbol. The creator user may then add additional participants to the conversation or continue the conversation alone.

One or more panels 1315 , 1318 , 1320 can be displayed in the “Feed” view 1308 . The panels can include an open (eg, expanded) conversation panel 1318 . Participants can communicate within open conversation panel 1318 by, for example, entering messages within input field 1304 . The entered messages can be displayed as a log or feed 1319 of the conversation 1301, eg, in the order in which they were sent, entered, or received. A timestamp may be displayed near the message in conversation 1301 to indicate when the message was sent, put in, or received. The user name of the participant who put the message may be displayed next to the message in the conversation.

The panels can include a folded conversation panel 1320 . Collapsed conversation panel 1320 can be adjacent to open conversation panel 1318 . A collapsed conversation panel 1320 may show a preview 1321a, 1321b of the conversation, such as the first message of the conversation, the title of the conversation, the last message of the conversation, and/or the number of unread messages in the conversation.

14-19 illustrate aspects of interactions between participants in the context of groups (eg, user groups) and the various ways in which messaging services and applications can categorize, organize, and output group-related messages and conversations. techniques and embodiments. It should be understood that Figures 14-19 are merely exemplary and that groups can be created and joined into conversations in other suitable ways.

FIG. 14 illustrates aspects for inviting an existing group or a newly created group into a conversation and creating a new group. At 1405, existing groups or newly created groups can be invited to join any conversation. As an example and not by way of limitation, an attribute may be to invite and allow a group containing multiple members to participate in multiple conversations. Group attributes also allow having multiple group participants in the same conversation. Additionally, group participants in a conversation will be able to push the content of the conversation to all members of the group at once. Thus, the present messaging service offers greater flexibility and efficiency compared to traditional messaging systems.

A group can be invited by any conversation participant by searching for the group name of the group. By way of example and not limitation, in response to receiving user input indicating to invite a group to a conversation, the messaging service creates an association between the group and the conversation in a database 260, such as conversation database 230 and group database 232. store in

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

At 1407, after the group has been invited to join the conversation, at least a subset of the messages in the conversation are pushed to all members of the group. Messages can be pushed by a push service 224 . Pushing the message can include sending the message to the member, eg, to the member's device. Pushing the message can include having the message displayed within a UI of a messaging application associated with the member.

FIG. 16 illustrates aspects of a group view 1600 within the UI of a messaging application. In group view 1600, the groups to which the user belongs are displayed to the user. FIG. 16 lists eight groups to which the user belongs. According to embodiments, groups are displayed in a list. The group view displays the attributes of the group and one or more selectable interface elements (eg, selectable buttons such as "Edit" and "Delete"). Attributes include group name 1601 . FIG. 16 shows group names including "Group1", "Group2", "Group3", and so on. Information associated with the group is sent to a messaging service (eg, messaging service 220) and maintained by messaging service 220 in databases 260 (eg, group database 232, search index database 252, etc.).

Once a group is admitted to participate in a conversation, the association between the group and the conversation is stored in database 260 . For example, the messaging service 220 stores the conversation's thread identification (ID) and the group's group identification (ID) in the group database 232 . As an example and not by way of limitation, an association between a group and a conversation can be identified based on the conversation's thread ID and group ID. The messaging service may generate a search index based on the information associated with the group and store the search index in database 260 , such as search index database 252 . Associations between all members of the group and conversations may be determined based on the search index, and the associations may be stored in database 260 . Because information associated with groups and members of groups can be retrieved from database 260, based on the retrieved information, for display associated with all members of a group (i.e., group participants in a conversation). , can send messages in a conversation to a messaging application.

After a group has been invited to participate in a conversation (i.e., as a group participant), unless any particular individual member is invited to the conversation by another participant or directly participates in the conversation (e.g., posting a message), the identity of individual members of the group may not be sent to the messaging application associated with the conversation participant for display. When any particular individual member of the group is invited to a conversation by another participant or joins the conversation directly, the identity of that particular individual member is sent to the messaging application associated with the conversation participant. to display the identification information of the specific individual member. Additionally, the particular individual member may continue to participate in the conversation as an individual participant even after the group has been removed from the conversation. Any other member of the Group who has not been invited to the Conversation by another participant or who has not directly participated in the Conversation will be removed from the Conversation after the Group has been removed from the Conversation, or after an individual member has been removed from the Group. No further messages in the conversation will be received.

Members can be added to and removed from groups, as described further below. Upon receiving information indicating group edits (eg, adding or removing members), the messaging service (eg, messaging service 220) updates databases 260 (eg, group database 232 and search index database 252). Messaging service 220 searches database 260 to determine which members are included in the current group, and adds any messages in conversations in which the group participates as a group participant to the current group. Send to members in If any previous individual member of the group was already invited to the conversation by another member or directly participated in the conversation before the individual member was removed from the group, the previous individual member: You can continue to participate in the conversation as an individual participant. The messaging service 220 can continue to send messages in the conversation to the former individual member as the current individual participant.

Group attributes can include group privacy settings 1602 . As shown in Figure 16, the group "Group1" is private. The group "Group2" is also private. Privacy settings may also be maintained in databases 260 such as group database 232 . For any private group, only members of the private group can access the private group. Unlike private groups, public groups are not limited to members within the group. Alternatively, public groups can be accessed by any participant in the conversation, or at least a subset of other users registered with the messaging service (eg, messaging service 220).

Group attributes may also include persons 1603 (eg, members of the group). FIG. 16 shows a group "Group1" with ten members. "Group2" has three members. In the group view, members of each group may have their profile image, account avatar, username, and user device (e.g., user device 242) and/or database 260 of the messaging service 220, which may be maintained by way of example. /or can be represented by a handle.

The group view contains functionality for users to manage their groups. In addition to the properties of creating a new group described above and specifically shown in FIG. Action 1605 includes an "edit" option that allows the user to change attributes such as name, privacy settings, and group membership (eg, add or remove members). A window such as window 1203 of FIG. 12 is displayed in response to the user selecting the edit option. This window contains options to add or remove members. Operation 1605 can also include a "delete" option that allows the user to delete the group.

As an example and not by way of limitation, at 1401 a new group can be created. The new group contains multiple members. Groups can be created by the group service 251 of the messaging service 220 . Messaging service 220 may also create a group ID for the new group. Groups can be created based on user input. User input may be received via a group view of the UI of the messaging application, eg, group view 1501 of FIG. A user can switch from feed view 1502 to group view 1501 . In the group view, conversation participants can select the “New Group” icon 1507 . In response to the user selecting icon 1507, a UI (eg, window 1503) is displayed with options for creating a new group. A new group can be created via the UI (eg, window 1503).

Options include privacy settings 1504 . Privacy settings 1504 are selected by selecting icon 1508, which has privacy options such as a slidable icon and a toggleable icon. In one embodiment, private groups are not searchable by other users across the messaging platform. In other embodiments, non-private groups are discovered and thus added to various conversations associated with attributes and the like.

Options include group name 1505 . A group name 1505 is entered by entering a string of text in the input field 1509 . As shown in FIG. 15, input field 1509 contains the group name "Patent Team". Group name 1505 distinguishes the group from other groups. The group can be searched by the group name 1505 of the group.

Options include users (ie, members) 1506 in groups. FIG. 15 shows a Patent Team group with five members. A member 1506 is invited (eg, added) by retrieving information that identifies the member 1506 within the group. By way of example, and not limitation, information identifying members 1506 of a group may be a username associated with any member, an account within an entity associated with any member, an email address associated with any member, or an email address associated with any member. A phone number associated with the member may be included. Upon receiving group member identification information, messaging service 220 may store the member identification information in databases 260 , such as group database 232 and search index database 252 .

Add a member 1506 by entering a text string in the input field 1510 . For example, Figure 15 shows searching for a member named "UserC" to invite to the "Patent Team" group. The window shows the number 1511 of members selected to be invited to the group. Options selected in the window are group attributes and/or associations.

A group can be canceled by selecting the "Cancel" button 1507 in the UI. A group can be saved by selecting the "Save" button 1508 in the UI. In response to the group being saved, the group's attributes and associations can be saved to the database.

Returning to FIG. 14, at 1402, group information (eg, attributes, associations) is recorded (eg, saved, stored) in one or more databases 260, such as group database 232 of FIG. Group information can be recorded by group services 251 . The databases may include conversation database 230 , group database 232 , user database 234 , and/or search index database 252 .

At 1403, a search index is constructed to store an index of search information. A search index may be built by Group Services 251 . The search index can operate in conjunction with other databases such as conversation database 230 , topic database 236 , group database 232 , and user database 234 . The search index allows the messaging service to search attributes (eg, group attributes) associated with messages and conversations. A search index allows management of permissions. Based on the search index, group members can access specific conversations and messages.

At 1404, information associated with the group can be output to a messaging application associated with the conversation participant for display. Outputting group information can include transmitting an indication of the group to the participant, eg, to the participant's device. As shown in FIG. 16, outputting the group information can include causing the group information to be displayed via a UI of the messaging application.

FIG. 17 shows an aspect 1700 for adding new members to an existing group. At 1701, new members are added to existing groups. New members can be added to existing groups in response to receiving user input. The user can enter input by selecting one of the "edit" icons in the group view of the UI. A list of current members of the group can be displayed in a window. The user can search for the names of users who are not members of the group and choose to invite new members to the group.

The messaging service's group service 251 can add new members to existing groups. Group services 251 can add new members based on receiving user input. Group services 251 may store new member associations with groups in one or more databases 260 . By way of example, databases 260 may include conversation database 230 , group database 232 , user database 234 , topic database 236 , and/or search index database 252 .

At 1702, a lookup of information related to the group, such as associated conversations, topic tags, etc. is performed. Group attributes include existing group members and the like. A lookup is performed by sending a query to one or more databases 260 . Import attributes for new members. Importing the attributes may include storing the attributes locally, eg, in the memory of Group Services 251 and storing the new member attributes in Group Database 232 .

At 1703, conversations associated with the group are output to new members. Conversations can be output by push service 224 . Outputting conversations can include sending messages contained in various conversations associated with the group to the new member, eg, to the new member's device. Publishing the conversation can include having the new member view the conversation via the UI of the messaging application.

At 1704, members of the group are discovered. Group members can be discovered by group service 251 and/or push service 224 . Group members can be discovered by querying database 260 . Group service 251 can determine the members of the group and send member indications to push service 224 .

At 1705, the determined group members are communicated to the determined members of the group. Members may be notified by push service 224 . Members can be notified that new members have been added. Notifying the member can include sending a notification to the member, eg, to the member's device. Notifying the member can include displaying the group members to the member via the UI of the messaging application, eg, within a group view.

In some embodiments, messaging service 220 and/or messaging application 240 may receive messages in conversations that include information to identify groups that include multiple members. In response to receiving this information, the messaging service 220 queries the database 260 to display at least a subset of the messages in the conversation with the messaging application 240 associated with the group member. can be sent to In one example, messaging service 220 and/or messaging application 240 can obtain information associated with members of a group by analyzing data associated with the group. In one example, the data associated with the group includes information about the members and attributes of the group. In another example, the data associated with the group can further include at least a portion of the content of conversations in which the group participates.

According to another aspect, a task associated with a due date can be created by one participant (assignee user) and assigned to another participant (assignee user) in the conversation. 18 and 19 illustrate techniques for assigning tasks associated with due dates within a conversation. Messaging services include chat service 222 . Chat service 222 may be provided by a device or program, such as a device or program in cloud computing network 100 of FIG. The chat service 222 allows users of the messaging service to exchange messages in conversations and/or generate conversations.

Tasks are initiated when the chat service 222 receives input from the user. In some embodiments, a task is first edited by an assignee user via a messaging application (e.g., messaging application 240) and then assigned to an assignee user by the assignee user. can be invited to join the conversation. In other embodiments, editing the task and inviting the assignee user to assign the task can be performed simultaneously on the same UI of the messaging application associated with the assignor user. The chat service 222 may receive input via a conversation, for example, via an input field of the conversation within the UI of the messaging application on the user device.

For purposes of illustration, FIG. 19 shows a UI 1900 of a messaging application in feed view where a user can enter input into input fields 1903 . A user can be a conversation creator user or another participant in a conversation. The input is a text string. For example, in FIG. 19, user "UserA" has entered the text "User B Please give us a conclusion." Text can describe the task. For example, User A's text includes "Please give us a conclusion," and its task is "giving a conclusion." The text may include instructions of another user, eg the user to whom the task is assigned. For example, User A's text includes the name of another user, User B. The users identified in the input may be users registered with a messaging service (eg, messaging service 220) and participating in the conversation. The users identified in the input may not be entities external to the messaging service (eg, messaging service 220) (eg, email participants in conversations described further below). In this example, user A is the assignee user and user B is the assignee user.

The input may include a date associated with the message. This date may be the due date of the task. This date may be the date when a reminder about the task should be sent. This date may include a selection of icons output via the UI of the messaging application on the user device. The icon can represent a calendar, such as icon 1601 in FIG. 16, for example.

Returning to FIG. 18, at 1802, allocation information is generated based on the inputs. Chat service 222 can generate assignment information. Assignment information may include associations between users who assign tasks, users to whom tasks are assigned, messages and/or tasks, and/or due dates. Assignment information is stored in one or more databases 260 , such as task database 256 , conversation database 230 , and user database 234 . Chat service 222 can store assignment information.

At 1803, assignor attributes and/or assignee attributes are added to the conversation based on the assignment information. Chat service 222 can add attributes. Adding attributes may include storing associations between assignee users, assignee users, messages and/or tasks, due dates, and/or conversations. Attributes are stored in databases 260 such as conversation database 230 , task database 256 , user database 234 , and group database 232 .

According to embodiments, a task has a status. The status is based on the task's due date and/or attributes indicating what stage of completion the task is in. For example, when tasks and/or due dates are created, the status can be set to "open," "incomplete," and/or "unverified." A descriptive attribute of the status can be a prefilled selectable input in the UI, such as a selectable icon or a list of selectable icons. A descriptive attribute can be, for example, a text string entered by the user into an input field in the UI of the messaging application.

The assignor user and/or assignee user can change the status to, for example, "closed," "completed," and/or "verified." Status can change based on whether the task is completed or not. For example, if a task is completed, the status can be changed to "completed". Statuses are stored in database 260 in association with tasks and/or due dates. The new status is saved in the database 260 in response to the status change. Messaging service 220 (e.g., chat service 222) determines status, timestamps (e.g., verified time, last updated time, etc.), and other information to database 260 (e.g., task database 256). can be stored in Send notifications to users in response to status changes. According to one embodiment, the status is displayed to the assignor user, the assignee user, and/or the participants of the conversation within the conversation, for example within the UI of the messaging application on the user device. Upon receiving the information indicating the status and due date of the task, the messaging application can display the status and due date of the task.

At 1804, all participants in the conversation are discovered. Chat service 222 can discover participants. The participants in the conversation can be determined by querying the database 260 . The participants can be sent to the messaging service's push service 224 . Push service 224 may be a messaging service device or program.

At 1806, the status of the task is pushed to the determined participants of the conversation. A push service 224 can push the status. Pushing the status can include sending the status to the participant's device (eg, user device 242). Pushing the status may include displaying the status within the conversation via the UI of the messaging application (eg, messaging application 240) on the user device (messaging application 242). A messaging service (eg, messaging service 220) can update the status of a task upon receiving information, eg, from assignor and assignee users, indicating changes to the due date or status of the task. The messaging service can then send information indicative of the updated status of the task to the user device associated with the participant for display of the updated status of the task.

According to one embodiment, the messaging service includes reminder scheduler service 253 . The reminder scheduler service 253 can be a messaging service device or program. The reminder scheduler service 253 has access to the messaging service's database 260 . Reminder scheduler service 253 determines the assigned task, the conversation associated with the task, and the user or users associated with the task.

A user (eg, User A) can enter an entry indicating a reminder date. As shown in FIG. 19, the user may enter an input via the UI 1900 of the messaging application indicating a due date for sending the reminder. For example, user A selects date selection icon 1902 . Based on selection of the date selection icon 1902, a window 1901 with selectable dates is displayed. Window 1901 may represent a calendar showing the days and months of the year. User A selects the reminder date of April 28, 2020 in window 1901 . Based on the user entering a reminder date, the reminder date is sent to the database 260 and associated with the task and/or due date by, for example, the reminder scheduler service 253 of the messaging service 220 in a task database such as that shown in FIG. stored in a database 260 such as 256.

The reminder scheduler service 253 can determine if the task's status and/or due date has changed. The reminder scheduler service 253 determines the current descriptive attributes and/or due dates assigned to the task by querying the database 260, and determines whether the due date has passed, thereby revising the task. status has changed. Based on the status changing to "closed", "completed", and/or "verified" status, the reminder scheduler service 253 does not send reminders. At 1811, a task and/or due date reminder is sent by the reminder scheduler service 253 based on the status of the task not changing or remaining "open," "incomplete," or "unverified." do. This reminder is sent to the assignor user, the assignee user, and other participants in the conversation. The message can be sent to push service 224 . A status change indication is sent to the push service 224 .

At 1812 , push service 224 receives the message from reminder scheduler service 253 . A messaging service 220 (eg, push service 224) notifies and/or reminds assignee users and/or assignee users of due dates and/or tasks. The messaging service may also notify or remind other participants of due dates and/or tasks. Push service 224 notifies assignee users, assignee users, and other participants of reminders and/or due dates and/or status changes to tasks. According to some embodiments, push service 224 notifies participants by sending a message to the device associated with the user. According to one aspect, the push service 224 may send reminders at predetermined time intervals, such as, for example, one week before the due date, two weeks before the due date, one day before the due date, and one hour before the due date. can be done. The push service 224 can notify the participant by displaying a reminder on the UI output via the participant's device. The push service 224 can stop providing reminders based on due dates and/or task status changes. The task assignment and task reminder features allow messaging services according to the present disclosure to provide more functionality than conventional messaging systems.

A user can respond to a status change by another user. For example, the assignee user marks the task as "verified" in response to the assignee user marking the task as "completed" to indicate that the completion of the task has been verified by the user. Assignor users may reopen tasks marked "completed", for example, if the user notices that the task is not being satisfactorily performed, or if the user determines that further work is required. be able to. According to embodiments, the due date and/or the color or other indicator of the task displayed in the UI changes based on the status change. Based on the status change, an indication of the change is sent to the conversation participants, for example by push service 224 .

In some embodiments, messaging application 240 may receive information associated with a task within a conversation. This information includes an identifier for identifying the user (for example, the assignee), the content of the task, and information indicating the date. Messaging application 240 can send information associated with the task to messaging service 220 . Upon receiving information from messaging application 240, messaging service 220 can transmit the information to the identified user (eg, assignee). The messaging application 240 can also receive information indicative of task status updates and display the updated task status. The content of the task can include at least part of the content of the conversation.

According to one embodiment, messaging service 220 blends the characteristics of chat and email with email integration capabilities. FIG. 20 shows an example of a messaging service's chat and email integration process. The messaging service according to the present disclosure improves the efficiency of information exchange by realizing the integration of email and messaging services. As shown, messaging service (eg, messaging service 220 ) includes chat service 222 . Chat service 222 may be a stand-alone service or may be incorporated as a property of messaging service 220 . Chat service 222 manages conversations in messaging service 220 .

At 2002, chat service 222 receives input, eg, from a user device. Specifically, chat service 222 receives input in the form of messages via a messaging application running on the user device, eg, via an input field in the UI of messaging application 240 . FIG. 21 provides an illustration of an exemplary UI for inviting an email participant to conversation 2101 and entering a message addressed to the email participant. To enter external e-mail participant A into conversation 2101, the user enters a message in the form of an external address, such as an e-mail address. In the particular example of UI 2100 shown in FIG. 21, a user has the email address UserF@gmail. com 2105 entered. Accordingly, the chat service parses the message and recognizes it as an email address associated with an entity (ie, email participant A) external to the messaging service. The e-mail address is also associated with e-mail service 254 . This example shows that the user has entered an email address that includes the domain "gmail.com". Other embodiments may use e-mail aliases previously known by the messaging service, represented by predefined characters, for example.

Returning to FIG. 20, at 2008 chat service 222 stores the email address-conversation association in, for example, conversation metadata 230 and email user database 237 . Once email participant A has been invited and granted access to the conversation, the messaging service (eg, messaging service 220) can generate an identifier to identify the conversation. Identifiers are used to identify conversations by email services external to messaging service 220 and can be associated with the email addresses of email participants. In another example, prior to inviting any email participants to the conversation, the messaging service 220 can generate an identifier to identify the conversation to be used for external email services. The messaging service can send the identifier to an external email service associated with the email participant. By way of example, and not limitation, an identifier for identifying a conversation may be a return email address corresponding to the conversation. The external email service can then send an email to the return email address associated with the conversation. In response to determining that an email has been received from the email address associated with the conversation, the messaging service generates a message based on the email and directs the conversation to display the generated message based on the email. The message can be sent to a messaging application (eg, messaging application 240) associated with the participant of the event. On the other hand, in response to determining that the email is not from the email address associated with the conversation, the messaging service discards the email and/or forwards the email to the return email address corresponding to the conversation. Reply with a notification to the effect that mailing is prohibited.

FIG. 21 shows an exemplary UI 2100 of a messaging application (eg, messaging application 240). UI 2100 can include conversation 2101 . Conversation 2101 may include input fields 2102 . User input may be received via input field 2102 . An exemplary entry 2104 to an email participant includes the content "Hi, external User F.". An exemplary input (ie, message in conversation 2101) 2104 is the email address UserF@gmail. com. An email address and content can be entered in input field 2102 .

At 2009, chat service 222 discovers existing participants in the conversation. Existing participants may be messaging service users and/or existing external email users. Chat service 222 discovers participants based on conversation metadata. To this end, chat service 222 discovers participants by querying user database 234 for users associated with the conversation and by querying email user database 237 for users who are participants. After receiving an indication that the email participant has been added to the conversation, subsequent messages can be added to the conversation, and an email message is generated and sent to the email address associated with email participant A: are sent as described more fully in

In some embodiments, when messaging service 220 receives a message in a conversation that includes information identifying email participant A (eg, an email address associated with email participant A), the email message can be generated. The e-mail message is generated according to an e-mail protocol associated with e-mail service 254 . A generated email message includes at least a subset of the received message and an email address. In some embodiments, the generated email message can further include a return email address generated by messaging service 220 and corresponding to the conversation. In another example, the messaging service 220 can generate multiple return email addresses each corresponding to multiple conversations. sending the generated e-mail message by messaging service 220 (e.g., e-mail service 254) to an external e-mail service associated with the e-mail address for delivery to e-mail participant A's e-mail inbox; can be done. In other embodiments, external email participants receive a single subsequent message or at least a subset of subsequent messages. In another embodiment, all subsequent messages in the conversation are sent to external email participant A.

The chat service 222 sends the new message along with the conversation participant's instructions to the messaging application's push service 224 . At 2011, the push service 224 notifies the existing participants with a message containing the external email address. Notifying existing participants can include sending a message and/or an indication of an email address to a conversation participant. Notifying existing participants can include having the message and/or email address appear in the conversation.

The push service 224 can send the message instructions to the messaging application's email service 254 . Email service 254 may be a service that is part of a messaging service. In one embodiment, email service 254 formats one or more messages into email format according to an email protocol such as SMTP. This allows the email service to add the external email address associated with Email Participant A to the header fields of the generated email message and add the message content to the body of the generated email message. can. Further, in some embodiments, email service 254 includes information indicative of a conversation resulting from message content, such as a return email address corresponding to the conversation and generated by messaging service 220, in the email message. to add.

Specifically, replies to e-mail messages received by the messaging service, eg, via e-mail service 254, include information indicating an association with the conversation (eg, the return e-mail address corresponding to the conversation). Information associated with the reply can be pushed to a messaging application associated with the conversation participant to cause display of at least one content of the reply to the email message. Thus, information added to an email message and included in any reply to an email message (e.g., a return email address corresponding to a conversation) may change the information associated with the reply to the email message to the conversation. Helps identify corresponding conversations to push to messaging applications associated with participants.

As noted above, one example of this association is messaging service 220 (eg, email service 254) generating a corresponding return email address associated with each conversation. By way of example, and not limitation, the generated return email may include at least partially randomly selected text strings. For example, as shown in FIG. 22, the messaging service has email participants UserF@gmail. com 2220 with a return email address calendar-kZNnYBkbywE@feishugroups.com 2220. com 2221 sent an email. As shown in FIG. 21, the return e-mail address is associated with the particular conversation that generated the message to be sent to the external e-mail address 2220 . A return email address 2221 is added to the email header in the sender field of the email message. A messaging service (eg, messaging service 220) can then use the reply to return email address 2221 to associate the return email with a particular conversation.

This method can be used to prevent spoofing of messaging services by return email and junk email. For example, a return email address can be generated in the form of a random email address generator. In this example, the return e-mail address 2221 includes "kZNnYBkbywE", but "kZNnYBkbywE" is randomly selected and cannot be easily predicted or spoofed. Therefore, conversations help reduce the incidence of receiving unwanted spam. In other examples, email headers may include specific information used to identify the conversation, such as in the subject line or other header fields. Such identifiers can include random or unpredictable character sequences that can be used by messaging services to help prevent or control spam. Any or all of the above data can be stored in a database, such as email message database 238, for later correlating and categorizing return email messages.

Accordingly, at 2013, e-mail service 254 can send a formatted e-mail message to the e-mail address associated with e-mail participant A. Sending the email message to the email address can include sending the email message to a domain associated with the email address. As noted above, sending an e-mail message to the e-mail address may include sending other information from the conversation to the e-mail address. FIG. 22 shows an email message being received by an email participant (eg, UserF@gmail.com 2220). The e-mail participant then composes a reply e-mail 2222 containing the text "Hi, there. I am happy!" Send to your email address.

Email service 254 can receive replies to the message from the email address. Replies can be received by email service 254 at the generated return email address corresponding to the conversation. The e-mail service 254 associates the return e-mail address with the corresponding conversation, e.g., by querying a database 260 (e.g., e-mail message database 238), e.g., using information contained in the reply e-mail, and Determine the conversation associated with a reply to an email message. In one embodiment, messaging service 220 (eg, email service 254 ) formats the reply into a message and sends the message to push service 224 via chat service 222 . Push service 224 can then send a message corresponding to the reply to a messaging application associated with the participant in the conversation. In some embodiments, a conversation can include email participant A, as well as other email participants (eg, email participant B). In this case, messaging service 220 may further generate an email message based on the message formatted by messaging service 220 corresponding to the reply from email participant A, and messaging service 220 may then: Send the generated e-mail message to another e-mail participant (e.g., e-mail participant B).

FIG. 23 shows an exemplary UI 2300 of a messaging application (eg, messaging application 240). UI 2300 may be the same as or similar to UI 2100 of FIG. UI 2300 includes a continuation of the conversation from FIG. Based on receiving a reply email 2222 from an email address and an external email system (eg, external email service 2200 of FIG. 22), a messaging service (eg, messaging service 220) generates a message, The message can be added to the conversation and sent to a messaging application associated with the conversation participant to display message 2304 corresponding to reply email 2222 . In the example shown, the external email address UserF@email. com is displayed with message 2304 . Other metadata may also be displayed, such as the time the message was sent to the messaging application associated with the conversation participant.

In some embodiments, messaging application 240 may receive information entered by the user during a conversation. This information can include an e-mail address and the content sent to the e-mail address. Messaging application 240 can then send the information to messaging service 220 . Upon receiving this information, messaging service 220 may transmit an identifier to identify the conversation and content to an email service external to messaging service 220 associated with the email address. In other embodiments, messaging service 220 can 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 determining that the email contains an identifier for identifying the conversation. Messaging service 220 can then generate a message containing the email content and send the generated message to messaging application 240 for display.

FIG. 24 illustrates an example process 2400 performed by a messaging application (eg, messaging application 240) consistent with this disclosure. Although described as a series of acts, those skilled in the art should appreciate that the described acts may be added, removed, reordered, or modified in various embodiments.

At 2402, messaging application 240 begins running on a device (eg, user device 242) associated with a user of a messaging service (eg, messaging service 220). At 2404, messaging application 240 sends to messaging service 220 a request for information associated with the conversation (ie, message thread) in which the user is engaged. In some embodiments, the requested information includes metadata associated with the conversations, eg, thread identification information (ID) corresponding to each of the conversations. The requested information further includes information indicating attributes associated with the conversation, such as topics, users, groups, tasks, etc. associated with the conversation. In other embodiments, the requested information may further include data indicative of summaries of conversations, eg, a subset of messages for each conversation. In one example, the subset of messages in each conversation may be the first and last messages in the conversation.

At 2406 , messaging application 240 receives the requested information and stores the requested information locally, eg, within user device 242 . In some embodiments, the received information, including conversation thread IDs and attributes, may be stored in local memory, such as a browser cache. In other embodiments, conversation thread IDs and attributes can be stored in a local database. At 2408, the messaging application 240 displays an indicator of the conversation. Conversation indicators may include topics beginning with a predetermined character (eg, hashtag #) associated with the conversation. Conversation indicators may also include users or groups that begin with other predetermined characters (eg, the @ sign) associated with the conversation. The conversation indicator may also include a summary of the conversation.

FIG. 25 shows an example user interface (UI) 2500 for messaging application 240 . In this example, indicators of conversations categorized by topic (e.g., "patent" 2502) and categorized by users (e.g., "UserA" 2503) or groups (e.g., "Group1" 2504) are shown in the leftmost columns. 2506. A summary of the conversation is displayed in area 2508 next to leftmost column 2506 . Conversation task attributes can also be displayed along with the conversation summary. For example, as shown in FIG. 25, task status 2512 and task due date change 2514 are displayed with summaries 2516 and 2518, respectively. It should be appreciated that the UI 2500 of FIG. 25 is exemplary only and that other display arrangements may be used.

Returning to FIG. 24, messaging application 240 may receive user input indicating selection of a conversation indicator or summary of a plurality of conversations. At 2410, upon receiving the user input, messaging application 240 sends a request for messages in the selected conversation to the messaging service. The request contains the thread ID of the selected conversation. At 2412, messaging application 240 receives the messages of the selected conversation and causes the messages of the selected conversation to be displayed. By way of example, and not limitation, the messages of the selected conversation may be displayed in the rightmost area 2520 of the UI 2500 of the messaging application, as shown in FIG. In one example, the messaging application 240 can utilize the digest to send a request for multiple messages within a selected one of the multiple conversations. Message application 240 can then display content associated with the plurality of messages within the selected conversation received in response to a request.

FIG. 26 illustrates another example process 2600 performed by a messaging application (eg, messaging application 240) consistent with this disclosure. Although described as a series of acts, those skilled in the art should appreciate that the described acts may be added, removed, reordered, or modified in various embodiments.

At 2602, messaging application 240 receives input indicating the start of a new conversation. For example, a user can select a "New Conversation" button 2526 on the UI 2500 to start a new conversation, as shown in FIG. In some embodiments, messaging application 240 can generate a thread ID for the new conversation. In other embodiments, upon receiving information indicative of a new conversation sent from messaging application 240, messaging service 220 may generate a thread ID for the new conversation.

At 2604, messaging application 240 receives another input from the user. In some embodiments, user input can be entered via windows 2702 and 2802 shown in FIGS. In response to user input indicating the start of a new conversation, messaging application 240 may cause a user device (eg, user device 242) to display window 2702 overlaid on UI 2700, as shown in FIG. The window contains multiple selectable interface elements.

Window 2702 includes representative symbols (eg, @ symbol 2704, # symbol 2706, and calendar icon 2708) corresponding to attributes associated with the new conversation. In one example, the user can select the @ symbol 2704 to add one or more participants (eg, UserA 2706 and Group1 2708) to the new conversation. In another example, the user can select the # symbol 2706 to add one or more topics (eg, topic "backlog" 2710) to the new conversation. The topic or topics may be any existing topic listed in the leftmost column of UI 2700 . In this example, the existing topic "backlog" 2710 was selected and added to the new conversation. In another example, when the calendar icon 2708 is selected, a calendar UI 2806 with selectable dates is displayed, as shown in FIG. In this example, a due date of July 17, 2020 is selected for the task assigned to the participant. Information indicating the task can be typed into input field 2808 of window 2802 .

In other embodiments, messaging application 240 may receive data indicative of messages submitted by users. This message may be entered by the user within a new or existing conversation, eg, via input area 2522 of UI 2500, as shown in FIG.

At 2606, messaging application 240 can determine that the user input includes information indicative of one or more attributes associated with the conversation. Messaging application 240 may determine that the user input indicates at least one attribute based on determining that the input is associated with a given character. For example, messaging application 240 may determine that user input indicates an attribute (eg, topic, user, or group) based on identifying a predetermined character (eg, #, @, or any other predetermined character). It can be determined that it contains information. Each predefined character (or predefined characters) can represent an attribute, eg, a topic, 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 conversation.

In one example, text strings beginning with the # symbol are determined as topics to be associated with the conversation. In another example, text strings beginning with the @ symbol are determined as users or groups invited to the conversation. In another example, messaging application 240 or messaging service 220 recognizes the structure of an email address, e.g., text string (mailbox)+@+domain, and determines that user input includes an email address associated with a conversation. can do.

At 2608, messaging application 240 sends information to messaging service 220 indicating at least one attribute associated with the conversation. Upon receiving the information indicative of the attribute, messaging service 220 stores the attribute in a corresponding attribute database associated with the thread ID of the conversation. This attribute can be the topic, user or group, email address, etc. associated with the conversation. In some embodiments that provide user input by entering a message, messaging application 240 may also send message content and metadata associated with the message to messaging service 220 . The content of the message may be text, image, video, or audio content. Metadata can include a user ID (for the user who created the message), a timestamp indicating when the message was created, and the like. Upon receiving the message content and metadata, messaging service 220 stores the message content and metadata in conversation (message thread) database 230 .

FIG. 29 illustrates another example process 2900 performed by a messaging application (eg, messaging application 240) consistent with this disclosure. Although described as a series of acts, those skilled in the art should appreciate that the described acts may be added, removed, reordered, or modified in various embodiments.

At 2902, messaging application 240 receives input from a user. In one example, user input can be provided by selecting the "Operator" option 2526 of the UI 2500, as shown in FIG. At 2904, in response to user input, messaging application 240 generates an interface based on attributes of the conversation in which the user is engaged. At 2906, messaging application 240 further causes the user to display an interface that allows the user to sort attributes of the conversation based on the priority attribute of the conversation.

Unlike conventional messaging systems that organize messages in a single dimension, eg, by message timing, messaging service 220 and/or messaging application 240 in accordance with the present disclosure can organize conversations in multiple dimensions. Optionally, messaging application 240 can generate an interface that includes two-dimensional representations associated with multiple conversations. Two dimensions in the two-dimensional representation are based on a first attribute associated with the plurality of conversations and a second attribute associated with the plurality of conversations. The messaging device can display an interface in which input can be provided by a user indicating a rearrangement of attributes associated with multiple conversations. The messaging device can reorganize the two-dimensional display in response to receiving input.

By way of example, and not limitation, FIG. 30 shows interface 3000 including two-dimensional table 3002 . Two-dimensional table 3002 comprises vertical axis 3004 and horizontal axis 3006 . In one example, vertical axis 3004 can list all or a subset of topics associated with a conversation in which the user is engaged. The horizontal axis 3006 can list all or a subset of users or groups that have conversations with the user (eg, users or groups that are mentioned in the conversation and begin with the @ symbol, or "mentions"). In another example, the vertical axis may list all or some of the users or groups that have conversations with the user, and the horizontal axis may list all or some of the topics associated with the conversations the user is engaging in. can be listed.

A user can drag a specific topic listed on the vertical axis 3004 or a specific mention listed on the horizontal axis 3006 and drop the specific topic or mention on a different row or column to create a two-dimensional Table 3002 can be reorganized. In one example, two-dimensional table 3002 can be reorganized by messaging application 240 based on the priority of attributes associated with conversations. Topics listed on vertical axis 3004 and/or mentions listed on horizontal axis 3006 may be organized and displayed in any manner to reflect their respective priorities. As an example and not by way of limitation, the most important attribute can be moved to the upper left corner of the two-dimensional table 3002 . In one example, the user can drag the topic that is most important to the user (eg, topic “bugs”) and drop topic “bugs” onto vertical axis 3004 . Similarly, the user can drag the mention that is most important to the user (eg, the mention “Boss”) and drop the mention “Boss” into the leftmost cell of horizontal axis 3006 . The two-dimensional table 3002 has a leftmost column 3008 and a top row 3010 with grayscale or color changes indicating the decreasing importance of the attributes listed from top to bottom and left to right, respectively. can contain. In another embodiment, the most important attribute can be moved to the bottom right corner of the two-dimensional table 3002 . The leftmost column 3008 and top row 3010 with grayscale or color changes may indicate increasing importance of the listed attributes from top to bottom and left to right, respectively.

A two-dimensional table 3002 includes a plurality of cells (intersections) defined by the columns and rows of table 3002 . Each cell in the two-dimensional table 3002 is a selectable button that allows conversations to be filtered based on the corresponding attribute (eg, topic or mention attribute). Each of the multiple intersections is associated with one or more conversations with corresponding attributes. In one example, a cell of the two-dimensional table 3002 can display the number of unread conversations. For example, the number "2" 3012 is displayed in cell 3014, indicating that there are two conversations with unread messages among the conversations with corresponding attributes (ie, Topic1 3016 and UserA 3018). In another example, different cells can have different colors or any other suitable indicators. Different colors or other indicators included in the cells can indicate different statuses of tasks associated with conversations having corresponding attributes.

In some embodiments, the UI 3000 can include an 'Enable' button 3019 that can toggle between enabled and disabled states of the 'Operator' option 2526 . In other embodiments, the UI 3000 includes slidable buttons 3018, 3020 for switching between enabled and disabled states of attributes such as topic (e.g., hashtag) attributes, mention attributes, and task status attributes; 3022 can be further included. UI 3000 includes a one-dimensional table instead of two-dimensional table 3002 when either the topic attribute or the mention attribute is disabled. If the task status attribute is disabled, the two-dimensional table 3002 does not show the task status in a different color or otherwise.

Returning to FIG. 29, at 2908, the messaging application 240 can overlay the reduced size two-dimensional representation over another user interface. The two-dimensional table 3002 shown in Figure 30 presents useful information and attributes associated with conversations to the user and allows the user to reorganize the attributes of the conversations. However, the two-dimensional table 3002 is relatively large and can occupy too much screen space. Accordingly, messaging application 240 can provide a reduced size version of two-dimensional table 3002 in response to user input. User input may be provided by selecting icon 2530 as shown in FIG.

FIG. 31 shows a reduced version 3102 of two-dimensional table 3002 . The reduced table 3102 was overlaid on another user interface 3104, as shown in FIG. Similar to the two-dimensional table 3002, the reduced table 3102 can include numbers in cells indicating unread conversations. The reduced table 3102 may also have different colors within different cells indicating different statuses of the associated tasks. Each cell in the reduced table 3102, like the cells in the two-dimensional table 3002, is also a selectable button that allows conversations to be filtered based on corresponding topic and mention attributes. A reduced two-dimensional table allows the table to be overlaid on the UI so that the user can refer to the table when using the UI. The reduced size may be predetermined based on the screen size, or defined by the user, for example by directly selecting the table and resizing it, or by entering a size range in the form.

Returning to FIG. 29, at 2910, messaging application 240 receives information indicating selection of an intersection within the two-dimensional representation. In one example, a user can select a cell within a two-dimensional table 3002, as shown in FIG. In another example, as shown in FIG. 31, the user can select a cell within the collapsed table 3102 . At 2912 , messaging application 240 can filter conversations according to selection of cells within either two-dimensional table 3002 or reduced table 3102 . Conversations are filtered by the messaging application based on certain attributes corresponding to the selected cell. For example, in response to selection of cell 3036 in two-dimensional table 3002 or cell 3106 in collapsed table 3102, messaging application 240 generates a conversation based on the corresponding attributes: topic "bugs" and mention "Boss." to filter. FIG. 32 shows the filtered results. By way of example and not limitation, conversation summaries 3206 , 3208 , 3210 , and 3212 having attributes of topic “bugs” 3202 and mention “Boss” 3204 are displayed in UI 3200 .

While the above aspects of the disclosure have been described with respect to several examples and embodiments, these are intended to be illustrative of the disclosure and not intended to be limiting. It should be understood that the subject matter presented herein can be embodied as a computer process, computer controlled device or computer system, or product such as a computer readable storage medium.

One of ordinary skill in the art will recognize that the subject matter described herein will apply to multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, handhelds, other than those described herein. It can be implemented on or in connection with other computer system configurations, including computers, personal digital assistants, electronic readers, cellular telephone devices, dedicated hardware devices, net appliances, and the like. The embodiments described herein may also be implemented 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 can be located in both local and remote memory storage devices.

A network built by an entity, such as a corporation or public sector agency, to provide one or more services accessible over the Internet and/or other networks to a set of distributed clients is called a provider network. be able to. Such Provider Network is a collection of physical and/or virtualized computer servers, storage devices, network equipment, etc. necessary to implement and deliver the infrastructure and services provided by the Provider Network. It can contain multiple data centers that host different resource pools. 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 computing instance is one or more servers with specified computing power (which can be defined by indicating the type and number of CPUs, size of main memory, etc.) and a specified software stack (e.g. , a specific version of an operating system capable of running on a hypervisor).

A number of different types of computing devices, including general purpose or special purpose computer servers, storage devices, network devices, etc., may be used individually or in combination to implement the resources and services in different embodiments. In at least some embodiments, a server or A computing device may include a general-purpose computer system that includes or is configured to access one or more databases and/or computer-accessible media.

FIG. 33 depicts such a general purpose computing device 3300 . Computing device 3300 can operate in a virtual environment, such as environment 100 in FIG. Computing device 3300 can be used to host a messaging service or messaging application. Computing device 3300 may be configured to communicate with a messaging application user's device. Computing device 3300 may be a general-purpose computing device. Computing device 3300 may be an on-premises device, such as a node of a distributed system operating within a user's data center. Components of the computing device 3300 may include one or more processors or processing units 3316, a system memory 3328, and a bus 3318 coupling various system components including the system memory 3328 to the processor 3316; It is not limited to these.

Bus 3318 in the example of FIG. 33 is some type of bus structure, 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. represents one or more of By way of example, and not limitation, such architectures include the Industry Standard Architecture (“ISA”) bus, the Micro Channel Architecture (“MCA”) bus, the Enhanced ISA (“EISA”) bus, the Video Electronics Standards Association (“VESA”) bus. ) local bus, and Peripheral Component Interconnect (“PCI”) bus.

Computing device 3300 can include a variety of computer system readable media. Such media can be any available media that can be accessed by computing device 3300 and includes both volatile and nonvolatile media, removable and non-removable media. Computing device 3300 can include system memory 3328 , which includes computer system-readable media in the form of volatile memory, such as random access memory (“RAM”) 3330 and/or cache memory 3332 . can be done. Computing device 3300 may also include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system 3334 may provide for reading from and writing to non-removable, nonvolatile magnetic media (not shown and commonly referred to as a "hard drive"). Not shown are magnetic disk drives for reading from and writing to removable non-volatile magnetic disks such as "floppy disks" and removable non-volatile optical disks such as CD-ROMs, DVD-ROMs or other optical An optical disc drive for reading from and writing to the medium may also be provided. In this case, each may be connected to bus 3318 via one or more data media interfaces. Memory 3328 includes at least one program product having a set, eg, at least one, of program modules configured to perform the functions of embodiments of the present invention, as further described and explained below. can include

Computing device 3300 may include programs/utilities 3340 having a set (at least one) of program modules 3342 storable in memory 3328 . Computing device 3300 of FIG. 33 may further include an operating system, one or more messaging applications, other messaging application modules, and messaging application data. An operating system, one or more messaging applications, other messaging application modules, and messaging application data, or some combination thereof, each comprise an implementation of a network environment, such as cloud computing system 100 of FIG. be able to. Program modules 3342 generally perform the functions and/or methods of embodiments of the invention described herein.

Computing device 3300 in FIG. 33 may also communicate with one or more external devices 3314 such as keyboards, pointing devices, displays 3324 that allow a user to interact with computing device 3300 . Computing device 3300 may also include any device, such as a network card, modem, etc., that enables computing device 3300 to communicate with one or more other computing devices. Such communication may occur, for example, via I/O interface 3321 . It should be noted that computing device 3300 may be connected via network adapter 3320 to one or more networks, such as a local area network (“LAN”), a general wide area network (“WAN”), and/or a public network (eg, the Internet). can communicate with any network. As shown, network adapter 3320 communicates with other components of computing device 3300 via bus 3318 . Although not shown, it should be understood that other hardware and/or software components may also be used 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 archival storage systems.

Each of the processes, methods, and algorithms described in the preceding section may be implemented in code modules executed by one or more computers or computer processors, and may thereby be fully or partially automated. . Code modules may be stored in any type of non-transitory computer readable medium or computer storage device such as hard drives, solid state memory, optical disks, or the like. The processes and algorithms may be implemented partially or wholly in application specific circuits. The results of the disclosed processes and process steps can be stored persistently or otherwise in any type of non-transitory computer storage, such as volatile or nonvolatile storage.

The various features and processes described above may be used independently of each other or combined in various ways. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. Additionally, in some implementations, some method or process blocks may be omitted. The methods and processes described herein are not limited to any particular order, and the blocks or states associated therewith may be performed in any other suitable order. For example, blocks or states illustrated may be executed in an order other than the order specifically disclosed, or multiple blocks or states may be combined within a single block or state. Exemplary blocks or states may execute serially, in parallel, or in some other manner. Blocks or states may be added or deleted from the disclosed exemplary embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added, deleted, or rearranged compared to the disclosed exemplary embodiments.

Also, various items are shown to be stored in memory or on a storage device during use, and these items, or portions thereof, may be stored in memory or on a storage device for purposes of memory management and data integrity. It will also be appreciated that it may be transferred to and from other storage devices. Alternatively, in other embodiments, some or all of the software modules and/or system may execute in memory on separate devices and communicate with the illustrated computing system via inter-computer communications. Moreover, in some embodiments, some or all of the systems and/or modules may be implemented or provided in other ways, for example, at least partially in firmware and/or hardware, where the hardware includes: 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, Composite Including, but not limited to, programmable logic devices and the like. Some or all of the modules, systems and data structures may be placed on a computer readable medium such as a hard disk, memory, network or portable media product (e.g., software) for reading by a suitable drive or via a suitable connection. instructions or structured data). Systems, modules, and data structures may be transmitted as data signals (e.g., carrier waves or other analog or digital propagated signals) over various computer-readable transmission media, including wireless-based media and wire/cable-based media. ) and can take various forms (eg, as part of a single or multiplexed analog signal, or as a plurality of discrete digital packets or frames). In other embodiments, such computer program products may take other forms. Accordingly, the invention may be practiced with other computer system configurations.

Conditional language as used herein, e.g., "can", "could", "may", "could", "for example", etc., unless otherwise specified, or Generally, some embodiments include some features, elements and/or steps, while other embodiments generally include some features, elements and/or steps, unless otherwise understood in the context of use. It is meant to convey that it does not contain steps. Such conditional language as a whole thus means that a property, element, and/or step is required in any way by one or more embodiments, or that one or more embodiments logic for determining whether these features, elements, and/or steps are included or performed in any particular embodiment, with or without human input or prompting. It is not meant to include The terms "comprising," "including," "having," etc. are synonymous and are used inclusively and in an open-ended manner and do not exclude additional elements, features, acts, operations, and the like. Also, the term "or" is used in an inclusive (rather than exclusive) sense, so that when the term "or" is used to concatenate element lists, the term "or" means one, some, or all of the elements within.

Although several exemplary embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the inventions disclosed herein. Thus, no part of the above description should be construed as implying that any particular feature, feature, step, module, or block is essential or essential. Indeed, the novel methods and systems described herein can be embodied in various other forms. Moreover, various omissions, substitutions, and modifications may be made in the form of the methods and systems described herein without departing from the spirit of the inventions disclosed herein. The appended claims and their equivalents are intended to cover any such forms or modifications that fall within the scope and spirit of any invention disclosed herein.

In summary, the embodiments of the present disclosure can provide the following technical solutions.
[Technical Proposal 1]
a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving a plurality of messages in the first conversation;
determining that user input in the first conversation includes information indicative of a topic;
storing an association between the information indicative of the topic and the first conversation in the at least one database;
at least one computing device configured to perform an operation comprising
A system with
[Technical Proposal 2]
Said action is
at least a subset of the first conversation and at least a subset of the plurality of messages in response to receiving input indicative of the topic selection from a messaging application associated with a first participant in the first conversation; sending to the messaging application for display;
The system according to Technical Plan 1.
[Technical Proposal 3]
The operation is
determining that the topic is new by searching the at least one database containing information related to the topic;
Storing information indicative of the topic in the at least one database based on a determination that the topic is new;
The system according to Technical Plan 1, further comprising:
[Technical Proposal 4]
The operation is
parsing a second message in the first conversation;
determining that the second message includes information identifying a user;
authorizing the user to participate in the first conversation by accessing at least the plurality of messages in the first conversation;
The system according to Technical Plan 1, further comprising:
[Technical Proposal 5]
further comprising sending said information indicative of said topic to one or more messaging applications, said one or more messaging applications including a second messaging application associated with said authorized user;
The system according to technical plan 4.
[Technical plan 6]
The at least one database includes a plurality of conversations including the first conversation, and the at least one database further includes a plurality of topics as attributes associated with the plurality of conversations and participants in the plurality of conversations. further stores associated information and
The system according to Technical Plan 1.
[Technical plan 7]
Determining that the first message includes information indicative of a topic includes determining that the first message includes a predetermined character;
The system according to Technical Plan 1.
[Technical Proposal 8]
a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving input from a messaging application associated with a first participant in a first conversation indicating selecting a topic from among a plurality of topics;
sending at least a portion of the first conversation to the messaging application for display of at least a subset of the plurality of messages in the first conversation;
at least one computing device configured to perform an operation comprising
an association between information indicative of the topic and the first conversation is stored in the at least one database;
system.
[Technical plan 9]
The operation is
sending the separate conversation to the messaging application for display of at least a subset of a plurality of messages in the separate conversation associated with the selected topic;
The system according to Technical Solution 8, further comprising:
[Technical Plan 10]
a method,
receiving multiple messages in a conversation; and
determining that user input within the conversation includes information indicative of a topic;
storing an association between information indicative of the topic and the conversation;
method including.
[Technical Proposal 11]
in response to receiving input from a first user indicating a selection associated with said topic, for displaying at least a subset of said plurality of messages in response to said input from said first user; further comprising transmitting said at least a subset of messages to a first user device associated with said first user;
The method described in technical solution 10.
[Technical Proposal 12]
determining that the topic is new by searching a database containing information related to the topic;
upon determining that the topic is new, storing information indicative of the topic in the database;
The method according to Technical Solution 10, further comprising:
[Technical Proposal 13]
the information indicating the topic includes at least part of a character string indicating the topic;
The method described in technical proposal 12.
[Technical Proposal 14]
determining, based on parsing the second message, that the second message includes information identifying a second user;
authorizing the second user to access the conversation;
The method according to Technical Solution 10, further comprising:
[Technical Proposal 15]
further comprising transmitting information indicative of the topic to a second user device associated with the second user to cause indication of the topic to be displayed;
The method described in technical proposal 14.
[Technical Proposal 16]
receiving a third message from the second user;
adding the third message to the plurality of messages;
The method according to Technical Solution 14, further comprising:
[Technical Proposal 17]
further comprising sending a notification to the first user device indicating the permission for the second user to access the plurality of messages;
The method described in technical proposal 14.
[Technical Proposal 18]
Further comprising storing an association between the conversation and multiple participants of the conversation.
The method described in technical solution 10.
[Technical Proposal 19]
receiving a third message in said conversation;
identifying the plurality of participants in the conversation;
transmitting the third message to a plurality of user devices associated with the plurality of participants to cause the third message to be displayed;
The method according to Technical Solution 18, further comprising:
[Technical plan 20]
the string includes an identifier for determining that the string indicates the topic;
The method described in technical solution 10.
[Technical Proposal 21]
a method,
receiving input from a messaging application associated with a first participant in a first conversation indicating selecting a topic from among a plurality of topics;
sending at least a portion of the first conversation to the messaging application for display of at least a subset of the plurality of messages in the first conversation;
an association between information indicative of the topic and the first conversation is stored in the at least one database;
Method.
[Technical Proposal 22]
sending the separate conversation to the messaging application for display of at least a subset of a plurality of messages in the separate conversation associated with the selected topic;
The method described in Technical Solution 21.
[Technical Proposal 23]
A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving multiple messages;
Based on parsing a first message of the plurality of messages, determining that the first message includes a string indicative of a topic;
storing an association between at least a portion of the string indicative of the topic and the plurality of messages;
A non-transitory computer-readable storage medium that causes
[Technical Proposal 24]
When executed on said computing device, said computing device at least:
in response to receiving input from a first user indicating a selection associated with said topic, for displaying at least a subset of said plurality of messages in response to said input from said first user; causing transmission of said at least a subset of messages to a first user device associated with said first user;
The non-transitory computer-readable storage medium of Technical Solution 23, further storing computer-readable instructions.
[Technical Proposal 25]
When executed on said computing device, said computing device at least:
determining that the topic is new by searching a database containing information related to the topic;
upon determining that the topic is new, storing information indicative of the topic in the database;
The non-transitory computer-readable storage medium of Technical Solution 23, further storing computer-readable instructions.
[Technical Proposal 26]
When executed on said computing device, said computing device at least:
determining, based on parsing the second message, that the second message includes information identifying a second user;
allowing the second user to access the plurality of messages and add one or more new messages to the plurality of messages;
The non-transitory computer-readable storage medium of Technical Solution 23, further storing computer-readable instructions.
[Technical Proposal 27]
When executed on said computing device, said computing device at least:
storing an association between the topic and a plurality of participants in a conversation associated with the topic;
receiving a third message within the conversation associated with the topic;
sending the third message and the topic to a plurality of user devices associated with the plurality of participants;
further comprising computer readable instructions;
A first user device associated with a first participant of the plurality of participants, in response to determining that the first user device previously received any message associated with the topic, said configured to display only the third message without displaying the topic;
The non-transitory computer-readable storage medium according to Technical Solution 23.
[Technical Proposal 28]
A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving input from a messaging application associated with a first participant in a first conversation indicating selecting a topic from among a plurality of topics;
sending at least a portion of the first conversation to the messaging application for display of at least a subset of the plurality of messages in the first conversation;
An association between information indicative of the topic and the first conversation is stored in the at least one database
A non-transitory computer-readable storage medium.
[Technical Proposal 29]
When executed on said computing device, said computing device at least:
causing the separate conversation to be sent to the messaging application for display of at least a subset of a plurality of messages in the separate conversation associated with the selected topic;
The non-transitory computer-readable storage medium of Technical Solution 28, further storing computer-readable instructions.
[Technical plan 30]
a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving a plurality of messages in the first conversation;
determining that user input in the first conversation includes information identifying a first group of users and authorizing the first group to participate in the first conversation;
storing an association between the first group and the first conversation in the at least one database;
Retrieving data associated with the first group, including information identifying the plurality of users within the first group, from the at least one database based on the information identifying the first group. and,
transferring the at least a subset of the first conversation to the first group for display of at least a subset of the plurality of messages based at least in part on the retrieved data associated with the first group; sending to a plurality of messaging applications associated with the plurality of users in
at least one computing device configured to perform an operation comprising
A system with
[Technical Proposal 31]
The operation is
further comprising associating the first conversation with each of the plurality of users in the first group based at least in part on a search index;
The system according to Technical Solution 30.
[Technical Proposal 32]
The operation is
Receiving information indicating adding a first user to or removing the first user from the first group and information identifying the first user. further comprising updating the data associated with the first group in response to
The system according to Technical Solution 31.
[Technical Proposal 33]
The operation is
sending said second message to said first group in response to receiving a second message in a second conversation and determining that said second message includes information identifying said first group; Allowing participation in a conversation; and
storing an association between the first group and the second conversation in the at least one database;
The system according to Technical Solution 30, further comprising:
[Technical Proposal 34]
The operation is
receiving information indicating to add a second user to the first group and information identifying the second user;
updating data associated with the first group;
The system according to Technical Proposal 33, further comprising:
[Technical Proposal 35]
The operation is
identifying the plurality of messages in the first conversation and a second plurality of messages in the second conversation by searching the at least one database;
sending the plurality of messages in the first conversation and the second plurality of messages in the second conversation to a messaging application associated with the second user;
35. The system of Technical Proposal 34, further comprising:
[Technical Proposal 36]
The operation is
sending notifications to the plurality of messaging applications associated with the plurality of users in the first group indicating that the second user has been added to the first group;
35. The system of Technical Proposal 34, further comprising:
[Technical Proposal 37]
The information identifying the plurality of users in the first group includes a username of a registered user, an account within an entity associated with one of the plurality of users, and a user name of the plurality of users. an email address associated with one of the plurality of users associated with one;
The system according to Technical Solution 30.
[Technical Proposal 38]
said data associated with said first group further includes information indicating that said first group is a private group, said private group being accessible only to a plurality of users within said private group;
The system according to Technical Solution 30.
[Technical Proposal 39]
a method,
receiving a plurality of messages in the first conversation;
determining that a first message in the first conversation includes information identifying a first group of users and allowing the first group to participate in the first conversation; ,
storing an association between the first group and the first conversation in the at least one database;
Retrieving data associated with the first group, including information identifying the plurality of users within the first group, from the at least one database based on the information identifying the first group. and,
at least a subset of the first conversation within the first group for display of at least a subset of the plurality of messages based at least in part on retrieved data associated with the first group; sending to a plurality of messaging applications associated with the plurality of users of
method including.
[Technical plan 40]
further comprising associating the first conversation with each of the plurality of users in the first group based at least in part on a search index;
The method described in Technical Proposal 39.
[Technical plan 41]
Receiving information indicating adding a first user to or removing the first user from the first group and information identifying the first user. updating the data and the search index associated with the first group in response to
The method described in Technical Solution 40.
[Technical plan 42]
sending said second message to said first group in response to receiving a second message in a second conversation and determining that said second message includes information identifying said first group; Allowing participation in a conversation; and
storing an association between the first group and the second conversation in the at least one database;
The method according to Technical Proposal 39, further comprising:
[Technical plan 43]
Receiving information indicating adding a second user to the first group or removing the second user from the first group and information identifying the second user. and,
updating data associated with the first group;
The method according to Technical Proposal 39, further comprising:
[Technical plan 44]
identifying the plurality of messages in the first conversation and a second plurality of messages in the second conversation by searching the at least one database;
sending the plurality of messages in the first conversation and the second plurality of messages in the second conversation to a messaging application associated with the second user;
The method according to Technical Proposal 43, further comprising:
[Technical Proposal 45]
Said third user actively participated in said first conversation or by another user before said third user already removed from said first group was removed from said first group further comprising determining to send some new message to the third user based on the determination that he was invited to the first conversation;
The method described in Technical Proposal 39.
[Technical plan 46]
A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving a plurality of messages in the first conversation;
determining that a first message in the first conversation includes information identifying a first group of users and allowing the first group to participate in the first conversation; ,
storing an association between the first group and the first conversation in the at least one database;
Retrieving data associated with the first group, including information identifying the plurality of users within the first group, from the at least one database based on the information identifying the first group. and,
transferring the at least a subset of the first conversation to the first group for display of at least a subset of the plurality of messages based at least in part on the retrieved data associated with the first group; sending to a plurality of messaging applications associated with the plurality of users in
A non-transitory computer-readable storage medium that causes
[Technical plan 47]
When executed on said computing device, said computing device at least:
generating a search index based on the information identifying the plurality of users in the first group;
and associating the first conversation with each of the plurality of users in the first group based at least in part on the search index.
47. The non-transitory computer-readable storage medium of Technical Solution 46, further storing computer-readable instructions.
[Technical Proposal 48]
When executed on said computing device, said computing device at least:
sending said second message to said first group in response to receiving a second message in a second conversation and determining that said second message includes information identifying said first group; Allowing participation in a conversation; and
storing an association between the first group and the second conversation in the at least one database;
47. The non-transitory computer-readable storage medium of Technical Solution 46, further storing computer-readable instructions.
[Technical plan 49]
When executed on said computing device, said computing device at least:
receiving information indicating to add a first user to the first group and information identifying the first user;
identifying the plurality of messages in the first conversation and a second plurality of messages in the second conversation by searching the at least one database;
sending the plurality of messages in the first conversation and the second plurality of messages in the second conversation to a messaging application associated with the first user;
49. The non-transitory computer-readable storage medium of Technical Solution 48, further storing computer-readable instructions.
[Technical plan 50]
a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving a plurality of messages in the conversation, 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;
storing an association between at least the first message, the second user and the date in the at least one database;
at least one computing device configured to perform an operation comprising
A system with
[Technical plan 51]
The operation is
A second messaging application associated with the second user, based at least in part on the date associated with the first message, a reminder that the date is still valid in the at least one database. to send to
51. The system according to Technical Solution 50, further comprising:
[Technical plan 52]
the first message indicates a task assigned to the second user by the first user;
The system according to Technical Solution 50.
[Technical Proposal 53]
the date associated with the first message includes a due date for the task;
The system according to technical proposal 52.
[Technical Proposal 54]
The operation is
determining a status of the task based at least in part on a due date of the task;
sending information indicative of the task status and due date to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the task status and due date;
54. The system according to Technical Proposal 53, further comprising:
[Technical Proposal 55]
The operation is
receiving information from the first messaging application or the second messaging application indicating a due date or status change of the task;
updating the status of the task based on the information indicating a change in due date or status of the task;
55. The system of Technical Proposal 54, further comprising:
[Technical Proposal 56]
The operation is
Sending information indicative of the updated status of the task to the plurality of messaging applications for display of the updated status of the task;
56. The system according to Technical Proposal 55, further comprising:
[Technical Proposal 57]
The operation is
sending the reminder to at least the second messaging application based on at least one of receiving information indicating the status of the task, the due date of the task, or a reminder date;
57. The system of Technical Proposal 56, further comprising:
[Technical Proposal 58]
The operation is
Associate information indicative of the first message and a date associated with the first message with the plurality of participants in the conversation for displaying the first message and a date associated with the first message. sending to multiple messaging applications that can be
51. The system according to Technical Solution 50, further comprising:
[Technical Proposal 59]
a method,
receiving a plurality of messages in a conversation maintained by a messaging service, 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;
storing an association between at least the first message, the second user and the date in at least one database;
method including.
[Technical plan 60]
further comprising sending information to a second messaging application associated with the second user indicating that the date is still valid in the at least one database;
The method described in Technical Proposal 59.
[Technical Proposal 61]
the first message indicates a task assigned to the second user by the first user;
The method described in Technical Proposal 59.
[Technical Proposal 62]
the date associated with the first message includes a due date for the task;
The method described in Technical Proposal 59.
[Technical Proposal 63]
determining a status of the task based at least in part on a due date of the task;
sending information indicative of the task status and due date to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the task status and due date;
The method of Technical Proposal 62, further comprising:
[Technical Proposal 64]
Further sending a reminder to the first messaging application and the second messaging application based on at least one of receiving information indicative of a status of the task, a due date of the task, or a reminder date. include,
The method described in technical proposal 53.
[Technical Proposal 65]
receiving information from the first messaging application or the second messaging application indicating a due date or status change of the task;
updating the status of the task based on the information indicating a change in due date or status of the task;
further comprising sending information indicative of the updated status of the task to the plurality of messaging applications for display of the updated status of the task;
The method described in Technical Solution 63.
[Technical Proposal 66]
A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving a plurality of messages in a conversation maintained by a messaging service, 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;
storing an association between at least the first message, the second user and the date in at least one database;
A non-transitory computer-readable storage medium that causes
[Technical Proposal 67]
When executed on said computing device, said computing device at least:
A second messaging application associated with the second user, based at least in part on the date associated with the first message, a reminder that the date is still valid in the at least one database. cause it to send to
67. The non-transitory computer-readable storage medium of Technical Solution 66, further storing computer-readable instructions.
[Technical Proposal 68]
the first message indicates a task assigned to the second user by the first user, and the date associated with the first message includes a due date for the task;
The non-transitory computer-readable storage medium according to Technical Proposal 66.
[Technical Proposal 69]
When executed on said computing device, said computing device at least:
determining a status of the task based at least in part on a due date of the task;
sending information indicative of the task status and due date to a plurality of messaging applications associated with the plurality of participants in the conversation for display of the task status and due date;
67. The non-transitory computer-readable storage medium of Technical Solution 66, further storing computer-readable instructions.
[Technical plan 70]
a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving a first input in the conversation;
determining, based on parsing the first input, that the first input includes information indicative of a first email address;
generating a first identifier for identifying the conversation;
sending the first identifier to a first external email service associated with the first email address;
at least one computing device configured to perform an operation comprising
A system with
[Technical plan 71]
wherein the first identifier is a first return email address corresponding to the conversation;
The system according to Technical Solution 70.
[Technical plan 72]
wherein the first return email address includes an at least partially randomly chosen text string;
The system according to Technical Solution 71.
[Technical plan 73]
The operation is
receiving from the first external email service a first set of data including the first email address and the first identifier;
71. The system of Technical Proposal 70, further comprising:
[Technical plan 74]
The operation is
determining that the first set of data is associated with the conversation based on the first identifier included in the first set of data; and based on the first set of data. generating a second message; sending the second message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the second message;
73. The system according to Technical Proposal 73, further comprising:
[Technical plan 75]
The operation is
storing an association between the first email address and the conversation in the at least one database;
71. The system of Technical Proposal 70, further comprising:
[Technical plan 76]
The operation is
sending notifications to a plurality of messaging applications associated with the plurality of participants in the conversation indicating that a first email address is associated with a first external entity participating in the conversation;
71. The system of Technical Proposal 70, further comprising:
[Technical plan 77]
The operation is
receiving a third message including information identifying the first email address from a first messaging application associated with the first participant in the conversation;
generating a first email message according to a first email protocol, the first email message including the first email address, the content of the second message, and the first identifier;
sending the first email message to the first external email service associated with the first email address for delivery to a first email inbox;
71. The system of Technical Proposal 70, further comprising:
[Technical Proposal 78]
The operation is
receiving from the first external email service a second set of data including the first identifier, information indicative of a reply to the third message, and content of the reply;
determining that the second set of data is associated with the conversation based on the first identifier included in the second set of data;
generating a fourth message based on the second set of data;
sending the fourth message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the fourth message;
78. The system of Technical Proposal 77, further comprising:
[Technical Proposal 79]
a second external entity associated with a second email address is permitted to participate in said conversation;
The system according to Technical Solution 78.
[Technical plan 80]
The operation is
a second external e-mail service associated with said second e-mail address to identify said second e-mail address, content of said fourth message, and said conversation according to a second e-mail protocol; generating a second email message including a second identifier generated by the messaging service for
sending the second email message to the second external email service associated with the second email address for delivery to a second email inbox;
79. The system according to Technical Proposal 79, further comprising:
[Technical plan 81]
a method,
receiving a first message in the conversation;
determining that the first message includes information indicative of a first email address;
storing an association between the first email address and the conversation in at least one database;
generating a first identifier for identifying the conversation;
sending the first identifier to the first external email service associated with the first email address;
method including.
[Technical plan 82]
wherein the first identifier is a first return email address corresponding to the conversation;
The method described in Technical Solution 81.
[Technical Proposal 83]
receiving a first set of data including the first identifier from the first external email service;
determining that the first set of data is associated with the conversation based on the first identifier included in the first set of data;
generating a second message based on the first set of data;
sending the second message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the second message;
The method according to Technical Solution 81, further comprising:
[Technical Proposal 84]
receiving a third message including information identifying the first email address from a first messaging application associated with the first participant in the conversation;
generating a first email message according to a first email protocol, the first email message including the first email address, the content of the second message, and the first identifier;
sending the first email message to the first external email service associated with the first email address for delivery to a first email inbox;
The method according to Technical Solution 81, further comprising:
[Technical Proposal 85]
receiving from the first external email service a second set of data including the first identifier, information indicative of a reply to the third message, and content of the reply;
determining that the second set of data is associated with the conversation based on the first identifier included in the second set of data;
generating a fourth message based on the second set of data;
sending the fourth message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the fourth message;
The method of Technical Proposal 84, further comprising:
[Technical Proposal 86]
A second external entity associated with a second email address is permitted to participate in the conversation, the method comprising:
generating a second e-mail message according to a second e-mail protocol including said second e-mail address, content of said fourth message, and a second identifier for identifying said conversation; and,
sending the second email message to the second external email service associated with the second email address for delivery to a second email inbox;
The method according to Technical Proposal 85, further comprising:
[Technical Proposal 87]
A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving a first message in the conversation;
determining that the first message includes information indicative of an email address associated with an email participant;
storing associations between said email addresses and said conversations in at least one database;
generating an identifier for identifying said conversation with an external email service associated with said email address;
sending the identifier to the external email service associated with the email address;
A non-transitory computer-readable storage medium.
[Technical Proposal 88]
The identifier is a first return email address corresponding to the conversation
The non-transitory computer-readable storage medium according to Technical Proposal 85.
[Technical Proposal 89]
When executed on said computing device, said computing device at least:
receiving a set of data including the identifier from the external email service;
determining that the set of data is associated with the conversation based on the identifiers included in the set of data;
generating a second message based on the first set of data;
sending the second message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the second message.
86. The non-transitory computer-readable storage medium of Technical Solution 85, further storing computer-readable instructions.
[Technical plan 90]
a system,
a message thread database containing multiple conversations;
a plurality of attribute databases containing attributes associated with the plurality of conversations;
at least one computing device in communication with the message thread database and the plurality of attribute databases,
receiving a plurality of messages in a first one of the plurality of conversations;
storing the plurality of messages in the message thread database;
receiving user input within the first conversation;
determining that the user input includes at least one attribute associated with the first conversation;
storing information in at least one of the plurality of attribute databases based on determining the type of the at least one attribute;
storing an association between the at least one attribute and the first conversation;
at least one computing device configured to perform an operation comprising
A system with
[Technical plan 91]
the message thread database includes metadata and content associated with each of the plurality of conversations;
The system according to Technical Proposal 90.
[Technical plan 92]
The message thread database comprises thread identification information associated with each of the plurality of conversations, at least one message identification information of at least one message included in each of the plurality of conversations, and at least one message identification information included in each of the plurality of conversations. and the at least one message to be
The system according to Technical Proposal 91.
[Technical plan 93]
content of the at least one message includes text data, video content, or audio content;
The system according to Technical Proposal 92.
[Technical plan 94]
The plurality of attribute databases include: a first attribute database storing information indicating topics associated with the plurality of conversations; a second attribute database storing information of users associated with the plurality of conversations; a third attribute database storing information on groups associated with the conversations; a fourth attribute database storing information indicating task assignments associated with the plurality of conversations; and one included in the plurality of conversations or a fifth attribute database storing information associated with a plurality of email addresses;
The system according to Technical Proposal 90.
[Technical plan 95]
each of the plurality of attribute databases further comprising a plurality of thread identification information corresponding to the plurality of conversations for identifying one or more attributes associated with each of the plurality of conversations;
The system according to Technical Proposal 90.
[Technical plan 96]
The operation is
updating the at least one of the plurality of attribute databases based on the new message;
sending information associated with the new message to one or more messaging applications associated with the first conversation;
91. The system of Technical Proposal 90, further comprising:
[Technical Proposal 97]
The operation is
receiving a request from the first messaging application indicating at least one of the plurality of conversations;
querying the message thread database based on information indicative of the at least one of the plurality of conversations;
processing query results to determine at least a subset of messages in said at least one of said plurality of conversations;
Sending, in response to the request, the at least a subset of messages in the at least one of the plurality of conversations to the first messaging application;
91. The system of Technical Proposal 90, further comprising:
[Technical Proposal 98]
The operation is
receiving a request from a second messaging application associated with at least one of the plurality of conversations;
querying the plurality of attribute databases based on the request;
processing query results to determine that at least one attribute is associated with the at least one of the plurality of conversations;
Sending information indicative of the at least one attribute to the second messaging application to cause display of at least one indicator of the at least one attribute;
91. The system of Technical Proposal 90, further comprising:
[Technical Proposal 99]
The operation is
receiving input indicating selection of the at least one indicator of the at least one attribute associated with the at least one of the plurality of conversations;
querying the message thread database based on the input;
identifying and transmitting a plurality of messages in the at least one of the plurality of conversations to cause the plurality of messages to be displayed;
99. The system of Technical Proposal 98, further comprising:
[Technical plan 100]
a method,
Receiving a plurality of messages in a first conversation of a plurality of conversations, wherein a conversation database includes the plurality of conversations, and a plurality of attribute databases includes attributes associated with the plurality of conversations. ,
storing the plurality of messages in the conversation database;
receiving user input within the first conversation;
determining that the user input includes at least one attribute associated with the first conversation;
storing information in at least one of the plurality of attribute databases based on determining the type of the at least one attribute;
storing an association between the at least one attribute and the first conversation;
method including.
[Technical plan 101]
receiving a request from the first messaging application indicating at least one of the plurality of conversations;
querying the conversation database based on information indicative of the at least one of the plurality of conversations;
processing query results to determine at least a subset of messages in said at least one of said plurality of conversations;
Sending, in response to the request, the at least a subset of messages in the at least one of the plurality of conversations to the first messaging application;
The method according to technical scheme 100, further comprising:
[Technical plan 102]
receiving a request from a second messaging application associated with at least one of the plurality of conversations;
querying the plurality of attribute databases based on the request;
processing query results to determine that at least one attribute is associated with the at least one of the plurality of conversations;
Sending information indicative of the at least one attribute to the second messaging application to cause display of at least one indicator of the at least one attribute;
The method of Technical Proposal 90, further comprising:
[Technical Proposal 103]
receiving input indicating selection of the at least one indicator of the at least one attribute associated with the at least one of the plurality of conversations;
querying the conversation database based on the input;
identifying and transmitting a plurality of messages in the at least one of the plurality of conversations to cause the plurality of messages to be displayed;
103. The method according to technical proposal 102, further comprising:
[Technical Proposal 104]
The conversation database comprises: thread identification information associated with each of the plurality of conversations including at least one message; at least one message identification information of the at least one message included in each of the plurality of conversations; and content of the at least one message included in each of the conversations of
The method described in Technical Solution 100.
[Technical plan 105]
each of the plurality of attribute databases further comprising a plurality of thread identification information corresponding to the plurality of conversations for identifying one or more attributes associated with each of the plurality of conversations;
The method described in Technical Solution 100.
[Technical Proposal 106]
A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
Receiving a plurality of messages in a first conversation of a plurality of conversations, wherein a conversation database includes the plurality of conversations, and a plurality of attribute databases includes attributes associated with the plurality of conversations. ,
storing the plurality of messages in the conversation database;
receiving new messages in the first conversation;
parsing the new message to determine that the new message includes at least one attribute associated with the first conversation;
storing information in at least one of the plurality of attribute databases based on determining the type of the at least one attribute;
storing an association between the at least one attribute and the first conversation;
A non-transitory computer-readable storage medium that causes
[Technical Proposal 107]
When executed on said computing device, said computing device at least:
receiving a request from a first messaging application indicating at least one of the plurality of conversations;
querying the conversation database based on information indicative of the at least one of the plurality of conversations;
processing query results to determine at least a subset of messages in said at least one of said plurality of conversations;
sending, in response to the request, the at least a subset of messages in the at least one of the plurality of conversations to the first messaging application;
107. The non-transitory computer-readable storage medium of Technical Solution 106, further storing computer-readable instructions.
[Technical Proposal 108]
When executed on said computing device, said computing device at least:
receiving a request from a second messaging application associated with at least one of the plurality of conversations;
querying the plurality of attribute databases based on the request;
processing query results to determine that at least one attribute is associated with the at least one of the plurality of conversations;
sending information indicative of the at least one attribute to the second messaging application to cause display of at least one indicator of the at least one attribute;
107. The non-transitory computer-readable storage medium of Technical Solution 106, further storing computer-readable instructions.
[Technical Proposal 109]
The conversation database includes thread identification information associated with each of the plurality of conversations and content of one or more messages included in each of the plurality of conversations, and each of the plurality of attribute databases further includes: a plurality of thread identification information corresponding to the plurality of conversations for identifying one or more attributes associated with each of the plurality of conversations;
The non-transitory computer-readable storage medium according to Technical Solution 106.
[Technical plan 110]
A computing device,
at least one processor;
at least one memory communicatively coupled to the at least one processor and storing instructions, wherein when the instructions are executed by the at least one processor, the client computing device:
receiving a first input from the user interface indicating to initiate a first conversation;
receiving a second input by the first user;
determining that the second input indicates at least one attribute associated with the first conversation;
sending information to a messaging service including information indicating the start of a new conversation and information indicating that the at least one attribute is associated with the first conversation. and,
A computing device comprising:
[Technical Proposal 111]
The at least one memory is
When executed by the at least one processor, the client computing device:
sending a request for information to the messaging service;
storing information received in response to the request, including information indicative of a plurality of attributes associated with a plurality of conversations, the plurality of conversations having corresponding thread IDs;
displaying a plurality of indicators associated with the plurality of conversations based on the received information;
111. The computing device of technical solution 110, further storing instructions.
[Technical Proposal 112]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
sending a request for a plurality of messages in a second conversation selected from the plurality of conversations;
displaying content associated with the plurality of messages in the second conversation received in response to the request;
112. The computing device of technical proposal 111, further storing instructions.
[Technical Proposal 113]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
sending a request for information indicative of the plurality of conversations;
displaying a summary of at least some of the plurality of conversations based on the received information;
111. The computing device of technical solution 110, further storing instructions.
[Technical Proposal 114]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
further storing instructions for generating an interface based on attributes of a second plurality of conversations;
The interface includes a two-dimensional representation associated with the second plurality of conversations, wherein two dimensions in the two-dimensional representation are a first attribute associated with the second plurality of conversations and a second plurality of and a second attribute associated with the conversation of
110. The computing device according to technical solution 110.
[Technical Proposal 115]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
displaying an interface for a second user to provide input indicating reorganizing attributes associated with the second plurality of conversations;
reorganizing the two-dimensional representation in response to receiving the input;
115. The computing device of technical proposal 114, further storing instructions.
[Technical Proposal 116]
at least one intersection in the two-dimensional representation comprising:
an indicator indicating the status of at least one task associated with at least one conversation of the second plurality of conversations;
a number indicating conversations with unread messages of the second plurality of conversations;
115. The computing device of Technical Solution 114, comprising:
[Technical Proposal 117]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
receiving information indicating a selection of intersections within the two-dimensional representation;
filtering the second plurality of conversations in response to receiving the information based on attributes corresponding to the selected intersection;
115. The computing device of technical proposal 114, further storing instructions.
[Technical Proposal 118]
the second input is provided by selecting an existing indicator of the at least one attribute;
110. The computing device according to technical solution 110.
[Technical Proposal 119]
said second input is provided by entering a message containing a predetermined character indicating a type of said at least one attribute;
110. The computing device according to technical solution 110.
[Technical plan 120]
the at least one attribute includes at least one of a topic attribute, a user attribute, a group attribute, a task attribute, and an email message attribute;
110. The computing device according to technical solution 110.
[Technical Proposal 121]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
causing determining that the second input indicates at least one attribute based on determining that the second input is associated with a predetermined character;
111. The computing device of technical solution 110, further storing instructions.
[Technical Proposal 122]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
causing display of a third user interface including information associated with at least one group participating in one or more conversations in response to receiving a third input;
111. The computing device of technical solution 110, further storing instructions.
[Technical Proposal 123]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
receiving messages in the first conversation;
determining that the message includes information identifying a second user;
receiving information indicating a date associated with the message;
causing the message service to send the message indicating a task assigned to the second user and the information indicating a date associated with the message to a message service;
111. The computing device of technical solution 110, further storing instructions.
[Technical Proposal 124]
The at least one memory further, when executed by the at least one processor, causes the client computing device to:
displaying the status of tasks associated with a third conversation among the plurality of conversations;
111. The computing device of technical solution 110, further storing instructions.
[Technical Proposal 125]
a method,
receiving a first input from the user interface indicating to initiate a first conversation;
receiving a second input by the first user;
determining that the second input indicates at least one attribute associated with the first conversation;
sending information to a messaging service including information indicating the start of a new conversation and information indicating that the at least one attribute is associated with the first conversation, the messaging service comprising: storing the at least one attribute associated with a thread identifier (ID) of the first conversation in at least one database;
Method.
[Technical Proposal 126]
sending a request for information to the messaging service;
storing information received in response to the request including information indicative of a plurality of attributes associated with a plurality of conversations, each of the plurality of conversations having a corresponding thread ID;
displaying a plurality of indicators associated with the plurality of conversations based on the received information;
The method of Technical Proposal 125, further comprising:
[Technical Proposal 127]
sending a request for a plurality of messages in a second conversation selected from the plurality of conversations;
displaying content associated with the plurality of messages in the second conversation received in response to the request;
The method of Technical Proposal 126, further comprising:
[Technical Proposal 128]
sending a request for information indicative of the plurality of conversations;
displaying summaries of at least some of the plurality of conversations based on the received information;
The method of Technical Proposal 125, further comprising:
[Technical Proposal 129]
further comprising generating an interface based on attributes of the second plurality of conversations;
The interface includes a two-dimensional representation associated with the second plurality of conversations, wherein two dimensions in the two-dimensional representation are a first attribute associated with the second plurality of conversations and a second plurality of conversations. a second attribute associated with the conversation;
The method described in Technical Proposal 125.
[Technical plan 130]
moreover,
receiving information indicating a selection of intersections within the two-dimensional representation;
filtering the second plurality of conversations in response to receiving the information based on attributes corresponding to the selected intersection;
The method according to Technical Proposal 129, comprising:
[Technical Proposal 131]
A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving a first input from the user interface indicating to initiate a first conversation;
receiving a second input by the first user;
determining that the second input indicates at least one attribute associated with the first conversation;
sending data to a messaging service including information indicating the start of a new conversation and information indicating that the at least one attribute is associated with the first conversation; stores the at least one attribute associated with a thread identifier (ID) of the first conversation in at least one database;
A non-transitory computer-readable storage medium.
[Technical Proposal 132]
When executed on said computing device, said computing device at least:
sending a request for information to the messaging service;
storing information received in response to the request including information indicative of a plurality of attributes associated with a plurality of conversations, each of the plurality of conversations having a corresponding thread ID;
displaying indicators of the plurality of conversations based on the received information;
132. The non-transitory computer-readable storage medium of Technical Solution 131, further storing computer-readable instructions.
[Technical Proposal 133]
When executed on said computing device, said computing device at least:
sending a request for a plurality of messages in a second conversation selected from the plurality of conversations;
displaying content associated with the plurality of messages in the second conversation received in response to the request;
133. The non-transitory computer-readable storage medium of Technical Proposal 132, further storing computer-readable instructions.
[Technical Proposal 134]
When executed on said computing device, said computing device at least:
further storing instructions for generating and displaying an interface based on attributes of a second plurality of conversations, said interface including a two-dimensional representation associated with said second plurality of conversations, wherein two a dimension based on a first attribute associated with the second plurality of conversations and a second attribute associated with the second plurality of conversations;
The non-transitory computer-readable storage medium according to Technical Proposition 131.

Claims (134)

a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving a plurality of messages in the first conversation;
determining that user input in the first conversation includes information indicative of a topic;
storing an association between the information indicative of the topic and the first conversation in the at least one database;
at least one computing device configured to perform an operation comprising
A system with Said action renders at least a subset of said first conversation of said plurality of messages in response to receiving input from a messaging application associated with a first participant of said first conversation indicating said topic selection. further comprising sending to the messaging application for display at least a subset;
The system of claim 1. The operation is
determining that the topic is new by searching the at least one database containing information related to the topic;
Storing information indicative of the topic in the at least one database based on a determination that the topic is new;
2. The system of claim 1, further comprising: The operation is
parsing a second message in the first conversation;
determining that the second message includes information identifying a user;
authorizing the user to participate in the first conversation by accessing at least the plurality of messages in the first conversation;
2. The system of claim 1, further comprising: further comprising sending said information indicative of said topic to one or more messaging applications, said one or more messaging applications including a second messaging application associated with said authorized user;
5. The system of claim 4. The at least one database includes a plurality of conversations including the first conversation, and the at least one database further includes a plurality of topics as attributes associated with the plurality of conversations and participants in the plurality of conversations. further stores associated information and
The system of claim 1. Determining that the first message includes information indicative of a topic includes determining that the first message includes a predetermined character;
The system of claim 1. a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving input from a messaging application associated with a first participant in a first conversation indicating selecting a topic from among a plurality of topics;
sending at least a portion of the first conversation to the messaging application for display of at least a subset of the plurality of messages in the first conversation;
at least one computing device configured to perform an operation comprising
an association between information indicative of the topic and the first conversation is stored in the at least one database;
system. The operation is
sending the separate conversation to the messaging application for display of at least a subset of a plurality of messages in the separate conversation associated with the selected topic;
9. The system of claim 8, further comprising: a method,
receiving multiple messages in a conversation; and
determining that user input within the conversation includes information indicative of a topic;
storing an association between information indicative of the topic and the conversation;
method including. in response to receiving input from a first user indicating a selection associated with said topic, for displaying at least a subset of said plurality of messages in response to said input from said first user; further comprising transmitting said at least a subset of messages to a first user device associated with said first user;
11. The method of claim 10. determining that the topic is new by searching a database containing information related to the topic;
upon determining that the topic is new, storing information indicative of the topic in the database;
11. The method of claim 10, further comprising: the information indicating the topic includes at least part of a character string indicating the topic;
13. The method of claim 12. determining, based on parsing the second message, that the second message includes information identifying a second user;
authorizing the second user to access the conversation;
11. The method of claim 10, further comprising: further comprising transmitting information indicative of the topic to a second user device associated with the second user to cause indication of the topic to be displayed;
15. The method of claim 14. receiving a third message from the second user;
adding the third message to the plurality of messages;
15. The method of claim 14, further comprising: further comprising sending a notification to the first user device indicating the permission for the second user to access the plurality of messages;
15. The method of claim 14. 11. The method of claim 10, further comprising storing an association between the conversation and multiple participants of the conversation. receiving a third message in said conversation;
identifying the plurality of participants in the conversation;
transmitting the third message to a plurality of user devices associated with the plurality of participants to cause the third message to be displayed;
19. The method of claim 18, further comprising: the string includes an identifier for determining that the string indicates the topic;
11. The method of claim 10. a method,
receiving input from a messaging application associated with a first participant in a first conversation indicating selecting a topic from among a plurality of topics;
sending at least a portion of the first conversation to the messaging application for display of at least a subset of the plurality of messages in the first conversation;
an association between information indicative of the topic and the first conversation is stored in the at least one database;
Method. sending the separate conversation to the messaging application for display of at least a subset of a plurality of messages in the separate conversation associated with the selected topic;
22. The method of claim 21. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving multiple messages;
Based on parsing a first message of the plurality of messages, determining that the first message includes a string indicative of a topic;
storing an association between at least a portion of the string indicative of the topic and the plurality of messages;
A non-transitory computer-readable storage medium that causes When executed on said computing device, said computing device at least:
in response to receiving input from a first user indicating a selection associated with said topic, for displaying at least a subset of said plurality of messages in response to said input from said first user; causing transmission of said at least a subset of messages to a first user device associated with said first user;
24. The non-transitory computer-readable storage medium of claim 23, further storing computer-readable instructions. When executed on said computing device, said computing device at least:
determining that the topic is new by searching a database containing information related to the topic;
upon determining that the topic is new, storing information indicative of the topic in the database;
24. The non-transitory computer-readable storage medium of claim 23, further storing computer-readable instructions. When executed on said computing device, said computing device at least:
determining, based on parsing the second message, that the second message includes information identifying a second user;
allowing the second user to access the plurality of messages and add one or more new messages to the plurality of messages;
24. The non-transitory computer-readable storage medium of claim 23, further storing computer-readable instructions. When executed on said computing device, said computing device at least:
storing an association between the topic and a plurality of participants in a conversation associated with the topic;
receiving a third message within the conversation associated with the topic;
sending the third message and the topic to a plurality of user devices associated with the plurality of participants;
further comprising computer readable instructions;
A first user device associated with a first participant of the plurality of participants, in response to determining that the first user device previously received any message associated with the topic, said configured to display only the third message without displaying the topic;
24. The non-transitory computer-readable storage medium of claim 23. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving input from a messaging application associated with a first participant in a first conversation indicating selecting a topic from among a plurality of topics;
sending at least a portion of the first conversation to the messaging application for display of at least a subset of the plurality of messages in the first conversation;
An association between the information indicative of the topic and the first conversation is stored in the at least one database on a non-transitory computer-readable storage medium. When executed on said computing device, said computing device at least:
causing the separate conversation to be sent to the messaging application for display of at least a subset of a plurality of messages in the separate conversation associated with the selected topic;
29. The non-transitory computer-readable storage medium of claim 28, further storing computer-readable instructions. a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving a plurality of messages in the first conversation;
determining that user input in the first conversation includes information identifying a first group of users and authorizing the first group to participate in the first conversation;
storing an association between the first group and the first conversation in the at least one database;
Retrieving data associated with the first group, including information identifying the plurality of users within the first group, from the at least one database based on the information identifying the first group. and,
transferring the at least a subset of the first conversation to the first group for display of at least a subset of the plurality of messages based at least in part on the retrieved data associated with the first group; sending to a plurality of messaging applications associated with the plurality of users in
at least one computing device configured to perform an operation comprising
A system with The operation is
further comprising associating the first conversation with each of the plurality of users in the first group based at least in part on a search index;
31. The system of Claim 30. The operation is
Receiving information indicating adding a first user to or removing the first user from the first group and information identifying the first user. further comprising updating the data associated with the first group in response to
32. The system of claim 31. The operation is
sending said second message to said first group in response to receiving a second message in a second conversation and determining that said second message includes information identifying said first group; Allowing participation in a conversation; and
storing an association between the first group and the second conversation in the at least one database;
31. The system of claim 30, further comprising: The operation is
receiving information indicating to add a second user to the first group and information identifying the second user;
updating data associated with the first group;
34. The system of claim 33, further comprising: The operation is
identifying the plurality of messages in the first conversation and a second plurality of messages in the second conversation by searching the at least one database;
sending the plurality of messages in the first conversation and the second plurality of messages in the second conversation to a messaging application associated with the second user;
35. The system of claim 34, further comprising: The operation is
sending notifications to the plurality of messaging applications associated with the plurality of users in the first group indicating that the second user has been added to the first group;
35. The system of claim 34, further comprising: The information identifying the plurality of users in the first group includes a username of a registered user, an account within an entity associated with one of the plurality of users, and a user name of the plurality of users. an email address associated with one of the plurality of users associated with one;
31. The system of Claim 30. said data associated with said first group further includes information indicating that said first group is a private group, said private group being accessible only to a plurality of users within said private group;
31. The system of Claim 30. a method,
receiving a plurality of messages in the first conversation;
determining that a first message in the first conversation includes information identifying a first group of users and allowing the first group to participate in the first conversation; ,
storing an association between the first group and the first conversation in the at least one database;
Retrieving data associated with the first group, including information identifying the plurality of users within the first group, from the at least one database based on the information identifying the first group. and,
at least a subset of the first conversation within the first group for display of at least a subset of the plurality of messages based at least in part on retrieved data associated with the first group; sending to a plurality of messaging applications associated with the plurality of users of
method including. further comprising associating the first conversation with each of the plurality of users in the first group based at least in part on a search index;
40. The method of claim 39. Receiving information indicating adding a first user to or removing the first user from the first group and information identifying the first user. 41. The method of claim 40, further comprising updating the data and the search index associated with the first group in response to. sending said second message to said first group in response to receiving a second message in a second conversation and determining that said second message includes information identifying said first group; Allowing participation in a conversation; and
storing an association between the first group and the second conversation in the at least one database;
40. The method of claim 39, further comprising: Receiving information indicating adding a second user to the first group or removing the second user from the first group and information identifying the second user. and,
updating data associated with the first group;
40. The method of claim 39, further comprising: identifying the plurality of messages in the first conversation and a second plurality of messages in the second conversation by searching the at least one database;
sending the plurality of messages in the first conversation and the second plurality of messages in the second conversation to a messaging application associated with the second user;
44. The method of claim 43, further comprising: Said third user actively participated in said first conversation or by another user before said third user already removed from said first group was removed from said first group further comprising determining to send some new message to the third user based on the determination that he was invited to the first conversation;
40. The method of claim 39. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving a plurality of messages in the first conversation;
determining that a first message in the first conversation includes information identifying a first group of users and allowing the first group to participate in the first conversation; ,
storing an association between the first group and the first conversation in the at least one database;
Retrieving data associated with the first group, including information identifying the plurality of users within the first group, from the at least one database based on the information identifying the first group. and,
transferring the at least a subset of the first conversation to the first group for display of at least a subset of the plurality of messages based at least in part on the retrieved data associated with the first group; sending to a plurality of messaging applications associated with the plurality of users in
A non-transitory computer-readable storage medium that causes When executed on said computing device, said computing device at least:
generating a search index based on the information identifying the plurality of users in the first group;
and associating said first conversation with each of said plurality of users in said first group based at least in part on said search index, further storing computer readable instructions. 47. The non-transitory computer readable storage medium of 46. When executed on said computing device, said computing device at least:
sending said second message to said first group in response to receiving a second message in a second conversation and determining that said second message includes information identifying said first group; Allowing participation in a conversation; and
storing an association between the first group and the second conversation in the at least one database;
47. The non-transitory computer-readable storage medium of claim 46, further storing computer-readable instructions. When executed on said computing device, said computing device at least:
receiving information indicating to add a first user to the first group and information identifying the first user;
identifying the plurality of messages in the first conversation and a second plurality of messages in the second conversation by searching the at least one database;
sending the plurality of messages in the first conversation and the second plurality of messages in the second conversation to a messaging application associated with the first user;
49. The non-transitory computer-readable storage medium of Claim 48, further storing computer-readable instructions. a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving a plurality of messages in the conversation, 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;
storing an association between at least the first message, the second user and the date in the at least one database;
at least one computing device configured to perform an operation comprising
A system with The operation is
A second messaging application associated with the second user, based at least in part on the date associated with the first message, a reminder that the date is still valid in the at least one database. to send to
51. The system of claim 50, further comprising: the first message indicates a task assigned to the second user by the first user;
51. System according to claim 50. the date associated with the first message includes a due date for the task;
53. The system of claim 52. The operation is
determining a status of the task based at least in part on a due date of the task;
sending information indicative of the task status and due date to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the task status and due date;
54. The system of claim 53, further comprising: The operation is
receiving information from the first messaging application or the second messaging application indicating a due date or status change of the task;
updating the status of the task based on the information indicating a change in due date or status of the task;
55. The system of claim 54, further comprising: The operation is
Sending information indicative of the updated status of the task to the plurality of messaging applications for display of the updated status of the task;
56. The system of claim 55, further comprising: The operation is
sending the reminder to at least the second messaging application based on at least one of receiving information indicating the status of the task, the due date of the task, or a reminder date;
57. The system of claim 56, further comprising: The operation is
Associate information indicative of the first message and a date associated with the first message with the plurality of participants in the conversation for displaying the first message and a date associated with the first message. sending to multiple messaging applications that can be
51. The system of claim 50, further comprising: a method,
receiving a plurality of messages in a conversation maintained by a messaging service, 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;
storing an association between at least the first message, the second user and the date in at least one database;
method including. further comprising sending information to a second messaging application associated with the second user indicating that the date is still valid in the at least one database;
60. The method of claim 59. the first message indicates a task assigned to the second user by the first user;
60. The method of claim 59. the date associated with the first message includes a due date for the task;
60. The method of claim 59. determining a status of the task based at least in part on a due date of the task;
sending information indicative of the task status and due date to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the task status and due date;
63. The method of claim 62, further comprising: Further sending a reminder to the first messaging application and the second messaging application based on at least one of receiving information indicative of a status of the task, a due date of the task, or a reminder date. include,
54. The method of claim 53. receiving information from the first messaging application or the second messaging application indicating a due date or status change of the task;
updating the status of the task based on the information indicating a change in due date or status of the task;
further comprising sending information indicative of the updated status of the task to the plurality of messaging applications for display of the updated status of the task;
64. The method of claim 63. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving a plurality of messages in a conversation maintained by a messaging service, 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;
storing an association between at least the first message, the second user and the date in at least one database;
A non-transitory computer-readable storage medium that causes When executed on said computing device, said computing device at least:
A second messaging application associated with the second user, based at least in part on the date associated with the first message, a reminder that the date is still valid in the at least one database. cause it to send to
67. The non-transitory computer-readable storage medium of Claim 66, further storing computer-readable instructions. the first message indicates a task assigned to the second user by the first user, and the date associated with the first message includes a due date for the task;
67. The non-transitory computer-readable storage medium of Claim 66. When executed on said computing device, said computing device at least:
determining a status of the task based at least in part on a due date of the task;
sending information indicative of the task status and due date to a plurality of messaging applications associated with the plurality of participants in the conversation for display of the task status and due date;
67. The non-transitory computer-readable storage medium of Claim 66, further storing computer-readable instructions. a system,
at least one database;
at least one computing device in communication with the at least one database,
receiving a first input in the conversation;
determining, based on parsing the first input, that the first input includes information indicative of a first email address;
generating a first identifier for identifying the conversation;
sending the first identifier to a first external email service associated with the first email address;
at least one computing device configured to perform an operation comprising
A system with wherein the first identifier is a first return email address corresponding to the conversation;
71. The system of Claim 70. wherein the first return email address includes an at least partially randomly chosen text string;
72. The system of claim 71. The operation is
receiving from the first external email service a first set of data including the first email address and the first identifier;
71. The system of claim 70, further comprising: The operation is
determining that the first set of data is associated with the conversation based on the first identifier included in the first set of data; and based on the first set of data. generating a second message; sending the second message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the second message;
74. The system of claim 73, further comprising: The operation is
storing an association between the first email address and the conversation in the at least one database;
71. The system of claim 70, further comprising: The operation is
sending notifications to a plurality of messaging applications associated with the plurality of participants in the conversation indicating that a first email address is associated with a first external entity participating in the conversation;
71. The system of claim 70, further comprising: The operation is
receiving a third message including information identifying the first email address from a first messaging application associated with the first participant in the conversation;
generating a first email message according to a first email protocol, the first email message including the first email address, the content of the second message, and the first identifier;
sending the first email message to the first external email service associated with the first email address for delivery to a first email inbox;
71. The system of claim 70, further comprising: The operation is
receiving from the first external email service a second set of data including the first identifier, information indicative of a reply to the third message, and content of the reply;
determining that the second set of data is associated with the conversation based on the first identifier included in the second set of data;
generating a fourth message based on the second set of data;
sending the fourth message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the fourth message;
78. The system of claim 77, further comprising: a second external entity associated with a second email address is permitted to participate in said conversation;
79. System according to claim 78. The operation is
a second external e-mail service associated with said second e-mail address to identify said second e-mail address, content of said fourth message, and said conversation according to a second e-mail protocol; generating a second email message including a second identifier generated by the messaging service for
sending the second email message to the second external email service associated with the second email address for delivery to a second email inbox;
80. The system of claim 79, further comprising: a method,
receiving a first message in the conversation;
determining that the first message includes information indicative of a first email address;
storing an association between the first email address and the conversation in at least one database;
generating a first identifier for identifying the conversation;
sending the first identifier to the first external email service associated with the first email address;
method including. wherein the first identifier is a first return email address corresponding to the conversation;
82. The method of claim 81. receiving a first set of data including the first identifier from the first external email service;
determining that the first set of data is associated with the conversation based on the first identifier included in the first set of data;
generating a second message based on the first set of data;
sending the second message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the second message;
82. The method of claim 81, further comprising: receiving a third message including information identifying the first email address from a first messaging application associated with the first participant in the conversation;
generating a first email message according to a first email protocol, the first email message including the first email address, the content of the second message, and the first identifier;
sending the first email message to the first external email service associated with the first email address for delivery to a first email inbox;
82. The method of claim 81, further comprising: receiving from the first external email service a second set of data including the first identifier, information indicative of a reply to the third message, and content of the reply;
determining that the second set of data is associated with the conversation based on the first identifier included in the second set of data;
generating a fourth message based on the second set of data;
sending the fourth message to a plurality of messaging applications associated with a plurality of participants in the conversation for display of the fourth message;
85. The method of claim 84, further comprising: A second external entity associated with a second email address is permitted to participate in the conversation, the method comprising:
generating a second e-mail message according to a second e-mail protocol including said second e-mail address, content of said fourth message, and a second identifier for identifying said conversation; and,
sending the second email message to the second external email service associated with the second email address for delivery to a second email inbox;
86. The method of claim 85, further comprising: A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving a first message in the conversation;
determining that the first message includes information indicative of an email address associated with an email participant;
storing associations between said email addresses and said conversations in at least one database;
generating an identifier for identifying said conversation with an external email service associated with said email address;
sending the identifier to the external email service associated with the email address;
A non-transitory computer-readable storage medium. 86. The non-transitory computer-readable storage medium of claim 85, wherein said identifier is a first return email address corresponding to said conversation. When executed on said computing device, said computing device at least:
receiving a set of data including the identifier from the external email service;
determining that the set of data is associated with the conversation based on the identifiers included in the set of data;
generating a second message based on the first set of data;
sending the second message to a plurality of messaging applications associated with a plurality of participants in the conversation to cause the second message to be displayed; 86. The non-transitory computer-readable storage medium of Clause 85. a system,
a message thread database containing multiple conversations;
a plurality of attribute databases containing attributes associated with the plurality of conversations;
at least one computing device in communication with the message thread database and the plurality of attribute databases,
receiving a plurality of messages in a first one of the plurality of conversations;
storing the plurality of messages in the message thread database;
receiving user input within the first conversation;
determining that the user input includes at least one attribute associated with the first conversation;
storing information in at least one of the plurality of attribute databases based on determining the type of the at least one attribute;
storing an association between the at least one attribute and the first conversation;
at least one computing device configured to perform an operation comprising
A system with the message thread database includes metadata and content associated with each of the plurality of conversations;
91. System according to claim 90. The message thread database comprises thread identification information associated with each of the plurality of conversations, at least one message identification information of at least one message included in each of the plurality of conversations, and at least one message identification information included in each of the plurality of conversations. and the at least one message to be
92. The system of claim 91. content of the at least one message includes text data, video content, or audio content;
93. The system of claim 92. The plurality of attribute databases include: a first attribute database storing information indicating topics associated with the plurality of conversations; a second attribute database storing information of users associated with the plurality of conversations; a third attribute database storing information on groups associated with the conversations; a fourth attribute database storing information indicating task assignments associated with the plurality of conversations; and one included in the plurality of conversations or a fifth attribute database storing information associated with a plurality of email addresses;
91. System according to claim 90. each of the plurality of attribute databases further comprising a plurality of thread identification information corresponding to the plurality of conversations for identifying one or more attributes associated with each of the plurality of conversations;
91. System according to claim 90. The operation is
updating the at least one of the plurality of attribute databases based on the new message;
sending information associated with the new message to one or more messaging applications associated with the first conversation;
91. The system of claim 90, further comprising: The operation is
receiving a request from the first messaging application indicating at least one of the plurality of conversations;
querying the message thread database based on information indicative of the at least one of the plurality of conversations;
processing query results to determine at least a subset of messages in said at least one of said plurality of conversations;
Sending, in response to the request, the at least a subset of messages in the at least one of the plurality of conversations to the first messaging application;
91. The system of claim 90, further comprising: The operation is
receiving a request from a second messaging application associated with at least one of the plurality of conversations;
querying the plurality of attribute databases based on the request;
processing query results to determine that at least one attribute is associated with the at least one of the plurality of conversations;
Sending information indicative of the at least one attribute to the second messaging application to cause display of at least one indicator of the at least one attribute;
91. The system of claim 90, further comprising: The operation is
receiving input indicating selection of the at least one indicator of the at least one attribute associated with the at least one of the plurality of conversations;
querying the message thread database based on the input;
identifying and transmitting a plurality of messages in the at least one of the plurality of conversations to cause the plurality of messages to be displayed;
100. The system of claim 98, further comprising: a method,
Receiving a plurality of messages in a first conversation of a plurality of conversations, wherein a conversation database includes the plurality of conversations, and a plurality of attribute databases includes attributes associated with the plurality of conversations. ,
storing the plurality of messages in the conversation database;
receiving user input within the first conversation;
determining that the user input includes at least one attribute associated with the first conversation;
storing information in at least one of the plurality of attribute databases based on determining the type of the at least one attribute;
storing an association between the at least one attribute and the first conversation;
method including. receiving a request from the first messaging application indicating at least one of the plurality of conversations;
querying the conversation database based on information indicative of the at least one of the plurality of conversations;
processing query results to determine at least a subset of messages in said at least one of said plurality of conversations;
Sending, in response to the request, the at least a subset of messages in the at least one of the plurality of conversations to the first messaging application;
101. The method of claim 100, further comprising: receiving a request from a second messaging application associated with at least one of the plurality of conversations;
querying the plurality of attribute databases based on the request;
processing query results to determine that at least one attribute is associated with the at least one of the plurality of conversations;
Sending information indicative of the at least one attribute to the second messaging application to cause display of at least one indicator of the at least one attribute;
91. The method of claim 90, further comprising: receiving input indicating selection of the at least one indicator of the at least one attribute associated with the at least one of the plurality of conversations;
querying the conversation database based on the input;
identifying and transmitting a plurality of messages in the at least one of the plurality of conversations to cause the plurality of messages to be displayed;
103. The method of claim 102, further comprising: The conversation database comprises: thread identification information associated with each of the plurality of conversations including at least one message; at least one message identification information of the at least one message included in each of the plurality of conversations; and content of the at least one message included in each of the conversations of
101. The method of claim 100. each of the plurality of attribute databases further comprising a plurality of thread identification information corresponding to the plurality of conversations for identifying one or more attributes associated with each of the plurality of conversations;
101. The method of claim 100. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
Receiving a plurality of messages in a first conversation of a plurality of conversations, wherein a conversation database includes the plurality of conversations, and a plurality of attribute databases includes attributes associated with the plurality of conversations. ,
storing the plurality of messages in the conversation database;
receiving new messages in the first conversation;
parsing the new message to determine that the new message includes at least one attribute associated with the first conversation;
storing information in at least one of the plurality of attribute databases based on determining the type of the at least one attribute;
storing an association between the at least one attribute and the first conversation;
A non-transitory computer-readable storage medium that causes When executed on said computing device, said computing device at least:
receiving a request from a first messaging application indicating at least one of the plurality of conversations;
querying the conversation database based on information indicative of the at least one of the plurality of conversations;
processing query results to determine at least a subset of messages in said at least one of said plurality of conversations;
sending, in response to the request, the at least a subset of messages in the at least one of the plurality of conversations to the first messaging application;
107. The non-transitory computer readable storage medium of Claim 106, further storing computer readable instructions. When executed on said computing device, said computing device at least:
receiving a request from a second messaging application associated with at least one of the plurality of conversations;
querying the plurality of attribute databases based on the request;
processing query results to determine that at least one attribute is associated with the at least one of the plurality of conversations;
sending information indicative of the at least one attribute to the second messaging application to cause display of at least one indicator of the at least one attribute;
107. The non-transitory computer readable storage medium of Claim 106, further storing computer readable instructions. The conversation database includes thread identification information associated with each of the plurality of conversations and content of one or more messages included in each of the plurality of conversations, and each of the plurality of attribute databases further includes: a plurality of thread identification information corresponding to the plurality of conversations for identifying one or more attributes associated with each of the plurality of conversations;
107. The non-transitory computer-readable storage medium of claim 106. A computing device,
at least one processor;
at least one memory communicatively coupled to the at least one processor and storing instructions, wherein when the instructions are executed by the at least one processor, the client computing device:
receiving a first input from the user interface indicating to initiate a first conversation;
receiving a second input by the first user;
determining that the second input indicates at least one attribute associated with the first conversation;
sending information to a messaging service including information indicating the start of a new conversation and information indicating that the at least one attribute is associated with the first conversation. and,
A computing device comprising: The at least one memory is
When executed by the at least one processor, the client computing device:
sending a request for information to the messaging service;
storing information received in response to the request, including information indicative of a plurality of attributes associated with a plurality of conversations, the plurality of conversations having corresponding thread IDs;
displaying a plurality of indicators associated with the plurality of conversations based on the received information;
111. The computing device of claim 110, further storing instructions. The at least one memory further, when executed by the at least one processor, causes the client computing device to:
sending a request for a plurality of messages in a second conversation selected from the plurality of conversations;
displaying content associated with the plurality of messages in the second conversation received in response to the request;
112. The computing device of claim 111, further storing instructions. The at least one memory further, when executed by the at least one processor, causes the client computing device to:
sending a request for information indicative of the plurality of conversations;
displaying a summary of at least some of the plurality of conversations based on the received information;
111. The computing device of claim 110, further storing instructions. The at least one memory further, when executed by the at least one processor, causes the client computing device to:
further storing instructions for generating an interface based on attributes of a second plurality of conversations;
The interface includes a two-dimensional representation associated with the second plurality of conversations, wherein two dimensions in the two-dimensional representation are a first attribute associated with the second plurality of conversations and a second plurality of and a second attribute associated with the conversation of
111. A computing device as recited in claim 110. The at least one memory further, when executed by the at least one processor, causes the client computing device to:
displaying an interface for a second user to provide input indicating reorganizing attributes associated with the second plurality of conversations;
reorganizing the two-dimensional representation in response to receiving the input;
115. The computing device of claim 114, further storing instructions. at least one intersection in the two-dimensional representation comprising:
an indicator indicating the status of at least one task associated with at least one conversation of the second plurality of conversations;
a number indicating conversations with unread messages of the second plurality of conversations;
115. A computing device as recited in claim 114, comprising: The at least one memory further, when executed by the at least one processor, causes the client computing device to:
receiving information indicating a selection of intersections within the two-dimensional representation;
filtering the second plurality of conversations in response to receiving the information based on attributes corresponding to the selected intersection;
115. The computing device of claim 114, further storing instructions. the second input is provided by selecting an existing indicator of the at least one attribute;
111. A computing device as recited in claim 110. said second input is provided by entering a message containing a predetermined character indicating a type of said at least one attribute;
111. A computing device as recited in claim 110. the at least one attribute includes at least one of a topic attribute, a user attribute, a group attribute, a task attribute, and an email message attribute;
111. A computing device as recited in claim 110. The at least one memory further, when executed by the at least one processor, causes the client computing device to:
causing determining that the second input indicates at least one attribute based on determining that the second input is associated with a predetermined character;
111. The computing device of claim 110, further storing instructions. The at least one memory further, when executed by the at least one processor, causes the client computing device to:
causing display of a third user interface including information associated with at least one group participating in one or more conversations in response to receiving a third input;
111. The computing device of claim 110, further storing instructions. The at least one memory further, when executed by the at least one processor, causes the client computing device to:
receiving messages in the first conversation;
determining that the message includes information identifying a second user;
receiving information indicating a date associated with the message;
sending to a messaging service the message indicating tasks assigned to the second user and the information indicating a date associated with the message;
111. The computing device of claim 110, further storing instructions. The at least one memory further, when executed by the at least one processor, causes the client computing device to:
displaying the status of tasks associated with a third conversation among the plurality of conversations;
111. The computing device of claim 110, further storing instructions. a method,
receiving a first input from the user interface indicating to initiate a first conversation;
receiving a second input by the first user;
determining that the second input indicates at least one attribute associated with the first conversation;
sending information to a messaging service including information indicating the start of a new conversation and information indicating that the at least one attribute is associated with the first conversation, the messaging service comprising: storing the at least one attribute associated with a thread identifier (ID) of the first conversation in at least one database;
Method. sending a request for information to the messaging service;
storing information received in response to the request including information indicative of a plurality of attributes associated with a plurality of conversations, each of the plurality of conversations having a corresponding thread ID;
displaying a plurality of indicators associated with the plurality of conversations based on the received information;
126. The method of claim 125, further comprising: sending a request for a plurality of messages in a second conversation selected from the plurality of conversations;
displaying content associated with the plurality of messages in the second conversation received in response to the request;
127. The method of claim 126, further comprising: sending a request for information indicative of the plurality of conversations;
displaying summaries of at least some of the plurality of conversations based on the received information;
126. The method of claim 125, further comprising: further comprising generating an interface based on attributes of the second plurality of conversations;
The interface includes a two-dimensional representation associated with the second plurality of conversations, wherein two dimensions in the two-dimensional representation are a first attribute associated with the second plurality of conversations and a second plurality of conversations. a second attribute associated with the conversation;
126. The method of claim 125. moreover,
receiving information indicating a selection of intersections within the two-dimensional representation;
filtering the second plurality of conversations in response to receiving the information based on attributes corresponding to the selected intersection;
130. The method of claim 129, comprising: A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, said computer-readable instructions, when executed on a computing device, causing said computing device to at least:
receiving a first input from the user interface indicating to initiate a first conversation;
receiving a second input by the first user;
determining that the second input indicates at least one attribute associated with the first conversation;
sending data to a messaging service including information indicating the start of a new conversation and information indicating that the at least one attribute is associated with the first conversation; stores the at least one attribute associated with a thread identifier (ID) of the first conversation in at least one database;
A non-transitory computer-readable storage medium. When executed on said computing device, said computing device at least:
sending a request for information to the messaging service;
storing information received in response to the request including information indicative of a plurality of attributes associated with a plurality of conversations, each of the plurality of conversations having a corresponding thread ID;
displaying indicators of the plurality of conversations based on the received information;
132. The non-transitory computer-readable storage medium of Claim 131, further storing computer-readable instructions. When executed on said computing device, said computing device at least:
sending a request for a plurality of messages in a second conversation selected from the plurality of conversations;
displaying content associated with the plurality of messages in the second conversation received in response to the request;
133. The non-transitory computer-readable storage medium of Claim 132, further storing computer-readable instructions. When executed on said computing device, said computing device at least:
further storing instructions for generating and displaying an interface based on attributes of a second plurality of conversations, said interface including a two-dimensional representation associated with said second plurality of conversations, wherein two a dimension based on a first attribute associated with the second plurality of conversations and a second attribute associated with the second plurality of conversations;
132. The non-transitory computer-readable storage medium of claim 131.

Images