System and Method for Processing Messages in a Messaging Service

• US 20130198296A1
• Filed: 01/31/2012
• Published: 08/01/2013
• Est. Priority Date: 01/31/2012
• Status: Active Grant

• Current Assignee: Global Relay Communications Incorporated
• Original Assignee: Global Relay Communications Incorporated
• Inventors: ROY, Warren, QUON, Colin Shong Chin, SAMPLE, Michael Edward
• Granted Patent: US 8,738,715 B2
• Time in Patent Office: Days
• US Class Current: 709/206
• CPC Class Codes: G06Q 10/107 Computer-aided management of electronic mailing [e-mailing]
• CPC Class Codes: H04L 51/216 Handling conversation history, e.g. grouping of messages in sessions or threads

Abstract

A method, system and server for processing messages sent from a client in a network are provided. The method comprises: for a message for a conversation to be transmitted from a client associated with a first user account of a plurality of user accounts associated with the network to a set of user accounts of the plurality of user accounts, upon activation of a command to send the message, sending to the set of user accounts a request message requesting acceptance of the conversation; receiving replies from the set of user accounts to the request message; and sending the message for the conversation to a first subset of accounts associated with the set of user accounts that generated an acceptance message for the request message and updating a message log associated with the conversation to indicate that the first subset of accounts has accepted the conversation as participants in the conversation. A method, system and server for message archiving are also provided.

Claims

1. A method for processing messages sent from a client in a network, the method comprising:

for a message for a conversation to be transmitted from a client associated with a first user account of a plurality of user accounts associated with the network to a set of user accounts of the plurality of user accounts, upon activation of a command to send the message, sending to the set of user accounts a request message requesting acceptance of the conversation;

receiving replies from the set of user accounts to the request message; and

sending the message for the conversation to a first subset of accounts associated with the set of user accounts that generated an acceptance message for the request message and updating a message log associated with the conversation to indicate that the first subset of accounts has accepted the conversation as participants in the conversation.

2. The method of claim 1, further comprising:

not providing the message to a second subset of accounts associated with the set of user accounts that refused or did not respond to the request message; and

updating the conversation log to indicate that the second subset of accounts has not been sent the message.

3. The method of claim 1, further comprising:

associating a message thread with the message for the conversation and the participants, where responses to the message from the participants are included in the message thread; and

initiating a new message thread associated with the conversation when one participant of the participants forwards a message in the conversation to a new user account of the plurality of user accounts that is participating in the conversation, the new message thread including the new user account once the new user account accepts the conversation invitation message.

4. The method of claim 3, further comprising:

closing the message thread when one of the participants indicates that it is no longer participating in the message thread.

5. The method of claim 3, further comprising:

creating a second new message thread for a set of remaining participants in the conversation.

6. The method of claim 3, further comprising:

assigning the first user account with a moderator role, having authority to end the conversation, remove a participant of the participants from the conversation and change a role of another participant in the conversation;

assigning an account of another participant of the participants one of

a ghost reviewer with a moderator role, having authority to revoke the moderator role from the first user account and to send a warning message to any of the participants determined to have a compliance violation;

a member role having authority to at least write messages, change thread subject, transfer conversations and hold and resume conversations; and

a viewer role, having viewing restrictions on at least one of the messages, a list of the participants and a message thread history.

7. The method of claim 3, further comprising:

assigning an account of a participant of the participants identified in a “

send to”

field for the message as a contributor to the message thread;

assigning an account of a second participant of the participants identified in a “

send cc”

field for the message as a passive contributor to the message thread; and

assigning an account of a third participant of the participants identified in a “

send bcc”

field for the message as an invisible contributor to the message thread that cannot invite or initiate sending of blind copy of a message to other user accounts to the conversation.

8. The method of claim 3, further comprising:

closing the message thread and ending the conversation when either a command to end the conversation is issued by the first user or all participants have left the conversation.

9. The method of claim 3, further comprising:

transferring the conversation to an account of the plurality of user accounts outside the participants upon issuance of a transfer command from the first user account.

10. The method of claim 3, further comprising at least one of:

placing a hold on the message thread upon issuance of a hold command from the first user account, where new messages cannot be submitted to the message thread until the hold is removed;

interrupting the message thread upon issuance of a mark command from the first user account, where a new message from the first user account is provided at the mark point in the message thread;

seizing the message thread upon issuance of a seize command from the first user account, where the participants having only viewer role until the seized message thread is released by the first user account;

merging the message thread with a second message thread of a second conversation into a third message thread for a third conversation involving participants of the first and second conversations; and

splitting the conversation into first and second parts with a first subset of the participants assigned to the first part and a second subset of the participants assigned to the second part.

11. The method of claim 3, further comprising:

for each account of the first subset of accounts, maintaining message status data relating to the each account and updating the message status data to indicate whether the message has been;

received by the network;

received by the each account; and

opened by the each account.

12. The method of claim 3, further comprising:

tracking the conversation in a conversation channel, the conversation channel being discoverable by one of the plurality of accounts; and

where participant roles may be selectively set for the conversation channel to implement social communications such as greeting, walls, feed publishers and feed aggregators.

13. The method of claim 3, further comprising:

specifying a time-to-live time for the conversation indicating a deadline for acceptance of the request message,

wherein

if an account of the first subset of accounts accepts the message prior to the time-to-live time, the account is designated as a participant in the conversation; and

if the account accepts the message after the time-to-live time, the account is not permitted to participate in the conversation.

14. The method of claim 3, further comprising:

providing the message to the participants as either a plurality of one-to-one conversations, a plurality of multi-party conversations, a plurality of blast conversations, or a plurality of broadcast conversations.

15. The method of claim 3, further comprising:

providing access to the first user account through a second client in the network while maintaining access to the first user account through the client;

when the second client reconnects to the network after being disconnected from the network, reconciling any queued actions for the conversation, the message thread and the messages stored at the second client against a current state of the conversation, the message thread and the messages;

re-synchronizing the second client to the current state of the message conversation, the message thread and the messages;

updating a first status indicator in the message log with details whether the message has been sent from the second client; and

updating a second status indicator in the message log with details whether the message has been received or opened by the second client,

wherein the second client is a mobile device.

16. The method of claim 3, further comprising:

forwarding the message to an outside account of the plurality of accounts that is not in the first subset of accounts while a share conversation status is maintained for the outside account,

wherein;

the outside account is a contact in a roster associated with the first user account; and

messages within the conversation submitted by outside user account are formatted to appear to be submitted by the first user account or by the outside account on behalf of first user account.

17. A server for processing messages sent from a client in a network, the server comprising:

a message sending module to

send a message for a conversation to be transmitted from a client associated with a first user account of a plurality of user accounts associated with the network to a set of user accounts of the plurality of user accounts upon activation of a command to send the message;

send to the set of user accounts a request message requesting acceptance of the conversation;

receive replies from the set of user accounts to the request message; and

send the message for the conversation to a first subset of accounts associated with the set of user accounts that generated an acceptance message for the request message and updating a message log associated with the conversation to indicate that the first subset of accounts has accepted the conversation as participants in the conversation,

wherein

the message sending module

does not provide the message to a second subset of accounts associated with the set of user accounts that refused or did not respond to the request message and updating the conversation log to indicate that the second subset of accounts has not been sent message for the conversation;

associates a message thread with the message for the conversation and the participants, where responses to the message from the participants are included in the message thread;

closes the message thread when one of the participants indicates that it is no longer participating in the message thread; and

creates a new message thread for a set of remaining participants in the conversation.

18. The server for processing messages sent from a client in a network, as claimed in claim 17, further comprising:

a message archive server that assembles and stores data of an archive message unit for the conversation, the data comprising the message thread and messages associated with the conversation in a storage system,

wherein for the conversation, the data comprises summary data, system header data and personal header data.

19. The server for processing messages sent from a client in a network, as claimed in claim 18, wherein the message archive server further:

updates a message log associated with the conversation when the client accesses the data of the archive message unit.