This invention relates generally to the messaging field, and more specifically to a new and useful system and method for serving a message client in the messaging field.
Email is a ubiquitous form of communication in modern society. Email has grown beyond a tool for corresponding with others to a tool for organizing and managing people's lives and businesses. Despite the importance of email, the email structure is predominately reliant on old email protocols such as IMAP. The protocol was not designed with consideration of the mobile and real-time nature of today's computing environment. However, new messaging protocols are not yet as ubiquitous as email and thus email remains one of the dominant forms of communication despite its many limitations. Thus, there is a need in the messaging field to create a new and useful system and method for serving a message client. This invention provides such a new and useful system and method.
The system and method for serving a message client of a preferred embodiment functions to provide a more efficient and responsive message client application that interfaces with a service provider. The system and method facilitate interfacing client application instances with an email service provider, but may alternatively or additionally interface with a social media messaging service, an instant messaging service, news or media stream service, or any suitable message service. Some primary benefits of the system and method can include intelligent message stream loading, real-time asynchronous messaging actions, message formatting improvements, online-offline synchronization, supporting more responsive client messaging actions, and/or fast attachment loading. Such improvements are preferably enabled by the cooperative management of messages on the device and in the cloud. The system and method can be designed to enable a message client application on a mobile device such as a phone, tablet or wearable computer, but may alternatively be used with any suitable computing device such as a desktop computer application, a browser mail client, TV connected computing device, or any suitable mail application.
The following description of the preferred embodiments of the invention is not intended to limit the invention to these preferred embodiments, but rather to enable any person skilled in the art to make and use this invention.
1. System for Serving a Message Client
As shown in
The system preferably includes a backend server infrastructure that includes the message service layer 110, a first transfer layer 140a, a mailbox service layer 120, and a second transfer layer 140b. The backend infrastructure can be implemented on a managed distributed computing infrastructure, a multitenant computing infrastructure, a computing cluster, or on any suitable infrastructure. The components may include various resources that act as or provide server, load balancing, queuing, cacheing, database, storage, or other suitable components. The backend server infrastructure is preferably implemented to support a client application. The backend infrastructure preferably includes various design features that enable advanced features on the client application that are not natively provided by a message provider. The backend infrastructure can serve as an intermediary layer that coordinates advanced features of the client application.
The message service layer 110 of a preferred embodiment functions to interface with an outside message service. The message service layer 110 is preferably a server in a distributed computing infrastructure. The message service layer 110 preferably manages message communication to and from a message service provider. The message service provider is preferably an email provider such as Google mail, Yahoo mail, Hotmail, or other mail services. The message service provider may alternatively interface with alternative forms of messaging services such as social network messaging, instant messaging, or any suitable messaging service. The message service layer 110 is preferably a collection of servers and services that collectively operate to fulfill tasks that enable coordinating with an outside service provider. The message service layer 110 may include load balancing such that the service of the backend layer can scale to support increased demand. As each message service provider may have a custom implementation, the message service layer 110 can include a provider module or component that defines message handling of the system for at least one specified message service provider. The provider module is preferably configured specifically for the intended service provider and includes rules and processing instructions to account for message format issues, for interpretation of message updates, specialized features or capabilities, and/or any suitable processing that may be specific to the message service provider.
For email service providers, the message service layer 110 preferably uses a persistent IMAP (Internet Message Access Protocol) connection for receiving and manipulating messages. The persistent IMAP connection is preferably made per account. A benefit of the message service layer 110 establishing the IMAP connection is that any number of client applications may now interact with messages without worrying about the IMAP connection restriction. For example, a user may have multiple instances of a client application open on various devices, but each instance can share the IMAP connection instead of the client applications individually maintaining an IMAP connection from the device. Outgoing mail is preferably delivered to the message service provider through typical means such as an SMTP (Simple Mail Transfer Protocol) connection or any suitable outbound message protocol. The message service layer 110 can additionally or alternatively use connections such as POP MAPI/Exchange, Service APIs and/or any suitable connection to interact with a message service provider. The message service layer 110 additionally translates account or message updates, delivered from the client/mailbox service, into appropriate actions to execute on the message provider. Account or message updates can include adding new folders, sorting messages into folders, starring a message, flagging a folder, marking a message as read/unread, and/or any suitable update between the client application and the message service provider. The server of the message service layer 110 preferably manages a plurality of messaging accounts.
The message service layer 110 can additionally convert data from the message provider for use within the system. A conversation parser can extract new portions of emails and convert them to a mailbox native format. Emails from various sources or from various service providers may include different formats or meta data. Some components of the email service format may be set to enable particular features within the service provider. When converting to a mailbox native format, the message format is preferably normalized to a consistent and uniform message format that can be used within the system. Normalizing the message format to a native message format functions to simplify design of other components in the system and enable various message sources to be integrated into the system. Herein, native message format describes a standardized data modeling approach to embody content and parameters of the message. The message service layer 110 additionally includes logic to translate message updates from a client application or other portions of the system into instructions compatible with the message service provider. Actions such as “archive all”, “empty trash”, “mark as unread”, and/or any suitable message update action preferably includes logic that guides the processing and communication of message updates directed at the message service.
The message service layer 110 may additionally store meta data parameters of the message provider such as message count in a folder. In one preferred embodiment, a message thread is the predominant message form. Thus the message service layer 110 may convert or incorporate individual messages into a message thread. A thread may be any suitable related messages such as messages replying to another message, forwarding a message, messages with shared subjects, a message quoting a portion of a message and/or any suitable grouping of a message. The message service 110 preferably uses a provider thread ID or alternatively an inbox scanning process to add messages to a thread.
The mailbox service 120 of a preferred embodiment functions to manage the mailbox for a client application. The mailbox service 120 is preferably an intermediary server that is communicatively coupled to the client application 130 and the message service 110. More preferably, the mailbox service 120 is communicatively coupled to the client application 130 with a first intermediary transfer layer 140a, and communicatively coupled to the message service 110 with a second intermediary transfer layer 140b. The mailbox service 120 preferably leverages a custom network protocol optimized for modem message communication. As one aspect of the protocol, a tokening system may be employed to track what has been transferred, how recently message updates are transferred, and guarantee that data is properly communicated. Alternatively, any suitable protocol may be used such as HTTP. The mailbox service 120 may provide any number of services. A first service may include message windowing. Message windowing preferably describes the transfer of only immediately relevant messages to the client application. For example, the mailbox service 120 preferably only transfers information for the 100 most recent messages when a user accesses his or her inbox even if there are 500 unread messages the user has not seen. The mailbox service layer 120 or alternatively the message service layer 110 can manage state and windowing of multiple message streams. Message streams preferably describe different collections of messages. A client application can be designed to provide frequent access to set message streams. An email inbox folder is preferably one message stream. Other message streams can include archive, message folders, labels, special folders (e.g., starred messages or deferred messages), and/or any suitable collection of messages. Maintaining the message streams in the backend infrastructure avoids delays caused by on demand access of an outside service provider when switching between message streams. Stream or message records may be created and/or modified to appropriately direct message sorting and organization. For example, the system can additionally organize a message according to sorting history. In this way, moving a message to another stream places that message at the top of the stream when presented to a user on a client application. This sorting organization can be an overriding sorting parameter on top of chronological organization. When receiving updates from a client application, the mailbox service 120 may additionally translate the update into a message service update. For example, if a message is moved to a particular list on the client application, the mailbox service may create a “tell Gmail to copy message thread 1048 to folder and expunge” instruction to deliver to the message service.
The mailbox service 120 may additionally include a deferred data engine. The deferred data engine functions to enable messages to be conditionally acted upon when a condition is satisfied. In a first variation, users can place messages in a deferred message list with an assigned reminder condition. The reminder condition is typically a time condition (e.g., “remind me in 24 hours”, “remind me on June 22”, etc.), but the reminder condition may additionally or alternatively use geolocation of the user, absolute geolocation of other users, geolocation of users relative to the device user, response by another recipient of the message, response to another message, device access (e.g., next time on desktop computer), a combination of Boolean logic for multiple conditions, programmatic logic (e.g., accessed through application programming interface or “API”), and/or any suitable conditions. Once a condition or conditions are satisfied the deferred data engine can take the appropriate action. The action or response is preferably moving the message or message thread into the inbox. This may involve sending data to the client application and/or to the mailbox service. The action may alternatively be any suitable action such as moving to another folder, sending a pre-composed response, archiving a message, deleting a message, sharing on a social network, sending an alert, or any suitable action.
The mailbox service 120 may include a message processing module that transforms the message into a suitable format for use within the system. As one preferred message transformation, the body of the email is converted to a uniform format. This preferably can involve converting HTML formatted messages to natively translatable format. The natively translatable format is one that is configured for rendering natively on client applications. This functions to work around slow and resource intensive HTML rendering on a mobile device. HTML content may additionally be normalized, refined, or stripped to simplify and make messages have a consistent presentation. The content of a message may additionally be obfuscated to protect message content within the system. The message service layer 110 can additionally include a component configured to facilitate converting attachment formats. Attachments are preferably media files included in message content, such as photo or file attachment in an email. A service preferably converts the attachments to inline items of the message. An attachment service preferably stores and hosts the media resources reference in the inline items.
The client application 130 of a preferred embodiment functions to provide a user interface and interaction capabilities for the messages. The client application 130 is preferably for a mobile device but may alternatively be for any suitable device application such as an application for a desktop computer, television-connected computing device, a website, a browser plug-in, or any suitable device application. Herein references to a client application refers to an instance of a type of client application installed on a device. Multiple instances of a client application can be active on different devices and/or the same device. The different application instances can additionally include instances operating different applications or versions of applications. The client application 130 preferably interprets the message with natively rendered views as opposed to HTML webviews. HTML views may alternatively be used in client applications where there is little drawback to HTML rendering. The client application 130 preferably includes an asynchronous message communication module which functions to seamlessly synchronize messages between the client application and the mailbox service 120. The asynchronous message communication module preferably alleviates the user pain of waiting for messages to load and send. The asynchronous message communication module preferably performs network communication in the background without blocking user interaction. The client application 130 preferably has at least one message account configured, but may alternatively have a plurality of message accounts and the message accounts may additionally be of different types (e.g., email and social media). Any suitable interface may be used by the client application 130 but a gesture based message-sorting interface preferably leverages the real-time and responsive nature of the message communication system.
The transfer layer 140 of a preferred embodiment functions to coordinate communication between the message service 110, the mailbox service 120, and the client application 130. There are preferably at least two transfer layers 140a and 140b. A first transfer layer 140a preferably communicatively couples the message service 110 and the mailbox service 120. A second transfer layer preferably communicatively couples the mailbox service 120 and the client application 130. The transfer layer 140 preferably queues messages and data communications in both communication directions. The client to mailbox transfer layer preferably queues sent messages, message actions, and other communications in a queue inbound to the mailbox. The client to mailbox transfer layer additionally queues data and responses to client, which may include new email messages, thread updates, and client responses (e.g., email sent OK, defer message OK). The message service to mailbox transfer layer preferably queues email service work from the mailbox in a queue inbound to the message service. The message service to mailbox transfer layer additionally queues message data updates in a queue inbound to the mailbox service. The queues preferably use rabbitMQ but may use any suitable queuing framework. The second transfer layer 140 may additionally include a connection service. The connection service preferably manages all connections from a client application to the mailbox service. The connection service preferably authorizes and establishes stream connections of client applications. Multiple client application instances may have a streaming connection to the connection service, and the connection service multiplexes client bound data to the plurality of client applications. For example, a user may have multiple devices with active client applications (configured for the same account) with a stream connection. An outbound message is preferably simultaneously transmitted across multiple stream connects to deliver to the various client application instances. The connections independently maintained for each device are substantially simultaneously used. The connection service may additionally manage version control of client application and implement size-selective data compression, and/or any other additional connection and streaming services.
The system may additionally include a conflict resolution module that functions to resolve conflicts in message management between the distributed portions of the system. Any action or communication submitted to a service of the system is preferably a transactional unit that includes a revision identifier. The revision identifier is preferably indicative of whether the current message data is the most recent, currently valid message. This is used to make message data objects within the system eventually consistent with the native environment of the message (e.g., the email provider). The revision identifier is additionally applied by the conflict resolution module to order actions taken by a user from within the client application to be the order that those actions are processed within the system to resolve consistency. Additionally, the system is configured such that actions are completed atomically on objects within the system. State in any particular portion of the system may not be consistent with other portions, but the state is preferably eventually consistent with the state of the message provider. For example, if a user moves messages in different folders, those moves may propagate through the system, and eventually the message provider will reflect those changes. When conflicts are encountered, state from particular components are given precedence over other components. In some situations the conflict resolution module may allow any suitable action to win during a race condition. An additional aspect of the conflict resolution module is that any action taken on a message conversation, thread, or collection of messages within the message system preferably has a document level revision that corresponds to the number of new messages that have arrived on the thread, which functions to enforce that new emails from an inbox folder that arrive from any message service provider bring the thread into the inbox.
2. Methods for Serving a Message Client
As shown in
Block S110, which includes at a message service, synchronizing messages with an outside message service, functions to interface with an outside message service provider. In one preferred embodiment, the outside message service is an email service provider such as Gmail, Yahoo Mail, Microsoft Exchange, but may alternatively be a social network API, or instant messaging service, or any suitable messaging service provider. A message service interfacing with an email provider preferably manages a persistent IMAP connection for each account, but the connection may alternatively be a POP, Microsoft Exchange, Service API, and/or any suitable connection. A single IMAP connection is preferably used by multiple mailbox client application instances of the same service account. Synchronizing messages with the outside message service can include retrieving inbound messages from the message service provider. When inbound messages are part of a conversation, synchronizing messages may include parsing a conversation, extracting new portions of a message and converting them to a mailbox service format. Synchronizing messages with the outside message service can additionally include transmitting client message interactions to the messages service provider. This may include sending outbound messages, changing the state of a message (e.g., marking as read), changing the state of message organization (e.g., moving a message to a folder, adding a label, adding reference to a category), and/or any suitable action that may need to be communicated to the message service provider. Synchronizing may additionally manage tracking meta data of messages. For example, the message service may count or track the number of messages and/or unread messages in a particular folder.
Block S120, which includes, at a mailbox service, converting between a provider message format and a client message format, functions to translate to the message format to that of the recipient. Inbound messages from the messaging service are preferably converted to a client native message format. The native message format is preferably a streamlined data format, and is designed for efficient delivery and rendering by a client application. Converting to a native message format may include converting HTML formatted messages to native rendering format. The native message format preferably strips content of undesired content styling attributes and unnecessary information. The native rendering format preferably parameterizes aspects of the message into parameters of a data-interchange object. In one variation, the native message format is a JSON object as shown in
Converting may include uploading attachment files to an attachment service of the system and converting attachments to inline items. This subprocess is particularly applicable to email related use cases. Attachment conversion can similarly be applied to other media messaging message protocols and mediums. Messages can be transmitted more efficiently and attachments used in a more flexible and diverse manner. Uploading to an attachment service can include various applications. In one variation, the message server synchronizes with an online data hosting solution (e.g., the Dropbox service), an interface to the attachment service can enable richer interaction capabilities. For example, sharing the attachment with other users of the client application can result in shared access to the attachment resource. In other words, only one instance of the attachment may be required since both users can access the inline-referenced file. Messages may additionally be obfuscated, which functions to add a level of privacy. The obfuscated messages are in an unreadable format for humans as the messages are passed through the system. The obfuscation process is reversed when delivered to the client application or the messaging service provider. Outbound messages and other client message interactions are preferably translated into message service updates. For example, a new email may be sent, and the email may be converted into a format for delivery to the message service. In another example, a user may archive a message on a client application, a message service update to archive the message.
Block S130, which includes at the mailbox service, managing deferred messages S130, functions to enable automatic deferred message features. A deferred message engine substantially similar to the one described above preferably manages deferred messages. Deferred messages may alternatively be managed by a deferred message engine in any suitable component of the messaging system. Managing deferred messages preferably includes receiving deferred message updates, monitoring deferred messages for condition validation; and triggering a message response when the condition is validated. Managing deferred messages can be used to enable a feature where messages are removed from an inbox until a condition is satisfied. The condition is typically time based, but may alternatively be a condition based on the geolocation of the user, absolute geolocation of other users, geolocation of users relative to the device user, response by another recipient of the message, response to another message, device access (e.g., next time on desktop computer), a combination of Boolean logic for multiple conditions, programmatic logic (e.g., accessed through an API), and/or any suitable conditions. In one variation, the message response is adding the message to the inbox. Other message responses may include moving the message to another folder, sending a pre-composed response, archiving a message, deleting a message, sharing on a social network, sending an alert, or any suitable action.
Managing a deferred message S130 preferably includes receiving a message update that indicates a deferral action, updating message to reflect the deferred state of the message, and upon satisfying the condition invoking a selected action on the message as shown in
Block S140, which includes at a client application, natively interpreting messages in client message format, functions to display and receive message updates and interactions. Messages are preferably received from the mailbox service in a native message format. The message preferably encodes any message formatting in a manner so that native application view tools may be used in creating natively rendered versions of the message content. In some variations, formatting from incoming HTML emails may be completely removed. In other variations, at least a subset of the formatting may be preserved but rendered through native view formatting. Relying on native rendering enables more efficient rendering of display elements, as a benefit the client application appears more responsive. Interactions on the client application preferably aggressively respond to user input and defer communication to connection services. The client application preferably depends on a robust asynchronous data, message, and message update communication. For example, the client application may be able to avoid any progress indicator visual elements (e.g., a spinner) for downloading content or content upload.
Block S150, which includes cooperatively relaying messages amongst the message service, the mailbox service, and the client application, functions to coordinate message distribution of messages between client device and a message service. Relaying messages preferably includes queuing messages inbound to client application, queuing messages outbound from client application, queuing message data to the mailbox service, and queuing message updates for the message service. As described above, there may be two queues to manage the bidirectional communication between the client application and the mailbox service as well as two queues to manage the bidirectional communication between the mailbox service and the messaging service. A queue manages the data and message communication for one direction of communication. Data and message communications are preferably communicated with real-time communication protocols. In one implementation node.js and websockets are used in facilitating the real-time communication. A client application may establish a connection with a connection service that manages connection and data streaming. Additionally messages are preferably windowed in communicating with the client application. As opposed to sending every message in a particular folder or stream, only messages/threads within a particular window are transferred. For example, when a user views a folder on a client application, the mailbox service preferably relays only the 50 most recent messages of the folder. Additionally when relaying messages, a specialized network communication protocol may be used that is designed for message communication; alternatively HTTP or any suitable protocols may be used.
Additionally, the method may include resolving conflicts of relayed messages, which functions to bring messages to a state of eventual consistency. The method is preferably implemented with a plurality of components distributed between different devices. Asynchronous and queued communication can bring considerable speed and responsiveness to the client application, but at times, the state of messages may be inconsistent between different modules. The state of any one component of the message platform preferably maintains internally consistent state. In particular, the client application can perform any number of message interactions while maintaining the state of mail on the client application. If for example, the client application has no access to a network, a user can preferably continue to read, send, delete, and organize messages. These changes are preferably communicated through the mailbox service to the message service provider once the client application has network access. Message actions and data are preferably marked with a revisioning number. Inconsistency of state is preferably resolved according the revisioning number. There may additionally be state priority between different components of the message system. For example, in many cases, message state set by a message service server preferably has priority over other components due to the fact that the message service communicates directly with the message provider.
Additionally, a method of a preferred embodiment may include converting message data attachments to internally routed data files, which functions to handle attachments as accessible resources as opposed to message content. An email or other message attachment is preferably converted to an inline attachment. Attachments are preferably uploaded to an attachment server, and a reference to the attachment resources is included in the message. In a similar variation, superfluous attachments (e.g., email signature images) may be automatically detected and the attachment may be removed or hidden from the message altogether. When a user wants to view an attachment, the user will activate a link or button, which will result in the retrieval of the attachment on the attachment server. The attachment may be unmodified, but can additionally be a modified version of the original file. For example, images may be reduced in size for mobile viewing, or other media types may be converted for viewing on the device. The attachment server/service may automatically generate modified forms of the original file. Pictures may have a set of various sizes generated for use within an application. Text documents may be converted to another format more readily used within email. Music or video files may be converted for streaming to the client application. Additionally, the attachments can be synchronized with a user account of a file hosting service. For example, a user may authenticate an account for a cloud file synchronization platform such as Dropbox, and attachments can be synchronized with the cloud files system of the user account.
As shown in
Block S210, which includes maintaining a plurality of real-time connections between the connection service and a client application, functions to establish communication channels with applications operable on a multitude of remote user devices. Block S210 is preferably implemented at a connection service with managed connections. Preferably, when a user opens a client application, the client application calls out to a host of the backend infrastructure. The connection service then creates an open communication channel. In one variation, the connection service creates a web socket connection. The backend infrastructure is preferably implemented to serve the accounts on shared resources, and thus the connection service preferably maintains the connections for multiple accounts. Additionally, multiple instances of a client application for one account may have two or more connections established. Message updates can be received on any of the connections. When establishing a connection, the account of the client application is preferably authenticated. Block S210 can additionally include managing version control of the client application. When the connection is established with the client application, the connection service verifies the version number of the client application. Based on the version number, client applications can be disabled, features can be disabled/enabled, upgrade notifications can be delivered, or any suitable action can be taken.
Block S220, which includes receiving a message update through a connection with a client application, functions to receive a change to a message, message thread, message organization, or messaging account that was initiated by a client application. Preferably, the initiated message update is transmitted to the backend infrastructure in response to a user action. In one variation, a single message update is delivered to the backend infrastructure at a particular time. In one variation, a client application can be configured to enable off-line message interactions. Within the offline client application, the user can seemingly modify messages, organize messages, delete messages, send or edit messages, or make any suitable message updates without a connection to a network. The client application preferably maintains message state and will mark message updates internally with revision identifiers. When the client application establishes a connection to the network, a batch of message updates can be uploaded through a connection to the connection service. The revision identifiers are preferably included in the message update to infrastructure and can be used in conflict resolution with message updates that were issued by the message service provider while the client application was off-line. As discussed, messages on the client application and the message service provider are eventually consistent.
Block S230, which includes transmitting the message update through an inbound queue of a first transfer layer to a mailbox service layer, functions to transfer message updates to the mailbox service layer in a scalable manner. The message queue handles the influx of message updates from various accounts and over client application instances. In one variation, a single inbound queue is used for all accounts, but alternatively multiple peers can be dynamically delivered message updates to load balance or distribute processing load. The inbound queue can use rabbitMQ or any suitable queuing service. The message updates are preferably dequeued from the inbound queue at a rate based on the available capacity of the mailbox service layer.
Block S240, which includes temporarily storing the message update, functions to cache the message update and perform preliminary processing. Block S230 is preferably performed at the mailbox service, and the mailbox service layer preferably translates message updates into message service instructions. For example, a message update to archive a message can be translated into an email service update that signifies a specific email thread to be archived. Mailbox service can additionally obfuscate the email message, such that the message is in the format substantially unreadable by humans.
Similar to Block S230, block S250, which includes transmitting the message update through a message service queue of a second transfer layer to a messaging service layer, functions to transfer message updates to the message service layer. Block S240 is substantially similar to Block S220. The queue preferably holds the message update as translated by the mailbox service layer. The queue can alternatively hold any suitable form of the message update.
Block S260, which includes translating the message update to a message format compatible with a message service provider, functions to prepare the message for transmission to the message service provider. The translation is substantially similar to that described above. In the scenario where the message update includes new message content, any native message formatting is preferably converted to suitable html elements or plain text content. The translation preferably occurs at the message service layer upon a message update dequeuing and being received at the message service layer. The message service layer may additionally translate the message update to a sequence of instructions that should be relayed to the message service provider to complete the update. This further translation is preferably customized to the particular message service provider that is being used. If the message service provider is an email service provider, then IMAP instructions may be selected or generated. For example, to move an email message to a folder, the instructions may include a copy, store, and expunge IMAP commands to achieve the effects of moving the message. Block S260 may additionally include selecting an appropriate message service module in the scenario where multiple message providers are used.
Block S270, which includes transmitting the translated message update to the message service provider, functions to synchronize the message update with the message service provider. The message service layer preferably transmits the translated message update. An IMAP connection is preferably used to connect with the message service provider, but any suitable connection may alternatively be used. The message update is preferably made on behalf of an account configured on an originating client application. Preferably, a single IMAP connection is maintained. Message updates originating from different client application instances but with the same account can share the IMAP connection. In some scenarios, this can avoid enforcement of an IMAP connection limit.
As shown in
Block S310, which includes receiving a message update from a message service provider, functions to transfer the state of a messaging account to the system. The message update from the message service provider can include any changes on the message service provider. These changes may be based on new incoming messages sent by other entities or changes made by a user of a message account on an outside client device. For example, if the user moves an email to a new folder on a web interface of the outside message service provider, that change can be communicated down to the client application. The client application is preferably kept in a state that is eventually consistent with the message service provider, which can be treated as a definitive source of the state of the messages. Such message updates may be initiated on-demand after a client application requests to access portions of content. In this way, information of the state of the messages is only delivered to the client application as the information is required.
Block S320, which includes translating the message update to message thread format compatible with native rendering on a client application, functions to convert the message update to an internal representation of the message update. The message service layer preferably includes a module or at least a set of rules that determines message translation. Translating the message update preferably normalizes the communication from the message service provider to a format that can be natively interpreted by a client application. The received message update may additionally have a revision identifier assigned. The revision identifier is preferably based on a time stamp of a received message or the time an instruction was received. In one scenario, the message update may be a new message with an attachment. In one variation, translating the message update to a message thread format may include changing a file attachment to an inline attachment. The attachment file is preferably uploaded and hosted on an attachment service, and an attachment inline reference is inserted or added to the message.
Block S340, which includes caching the message update until the message update can be communicated to a client application, functions to hold message updates until the client application is ready to receive the message update. In one variation, the client application may or may not have an active connection to the connection service. For example, the user may not have the application open, or the application may be in a sleep mode. When the client application is ready to receive message updates, a connection is established, and cached message updates can be delivered. In one scenario, the resources used to deliver the message update may be at capacity, and the mailbox service layer holds the message updates until the content is ready for delivery. The message updates can be temporarily cached at the mailbox service layer. This preferably occurs upon dequeuing a message update from the message service queue and receiving the message update at the mailbox service layer. In one variation, the mailbox service layer or alternatively the message service layer can cache a model of the messages of an account, but only deliver relevant portions to the client application, which would reduce latency when needing to pull load content from the message service provider. For example, the messages contained within a rarely accessed folder may be maintained on the backend infrastructure. When the user does access the folder on the client application, the folder can be populated with the content without having to request the folder contents from the message service provider. In a similar manner the messages are preferably windowed/paginated so that only relevant messages are transmitted to the client application. For example, the account may have over one hundred new messages, but instead of transferring all the messages to the client application, the first fifty messages are transmitted. Windows/batches of fifty messages can be dynamically transmitted as the user scrolls or requests more messages.
Block S360 includes communicating the message update to at least one client application. The connection preferably uses a realtime communication protocol such as using node.js and compressed websockets. The connection service preferably implements size-selective data compression to enable rapid delivery to the client application. As one variation, the connection service may include multiple connections to different account instances on a client application (i.e., same account being used on multiple devices). The communicating the message update can include multiplexing the message update to multiple client application instances.
Additionally, method S300 and similarly method S200 can include resolving conflicts. As discussed above, message updates can be assigned a revision identifier. The revision identifier can be used to determine race conditions. Additionally, different layers (e.g., mailbox service layer or the message service layer) or different sources (e.g., initiated by the client application or initiated by a message service provider) can have different weighting or levels of authority such that when revision identifiers cannot be solely used to resolve a conflict, the state of the highest priority source is treated as the current state. As shown in
An alternative embodiment preferably implements the above methods in a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components preferably integrated with a message delivery system. The computer-readable medium may be stored on any suitable non-transitory computer readable storage media such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or any suitable device. The computer-executable component is preferably a processor but the instructions may alternatively or additionally be executed by any suitable dedicated hardware device.
As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.
This application is a continuation of U.S. patent application Ser. No. 14/084,142, filed Nov. 19, 2013, which claims priority to U.S. Provisional Patent Application No. 61/728,635, filed on Nov. 20, 2012, the content of which is herein incorporated by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
5754178 | Johnston et al. | May 1998 | A |
5822526 | Waskiewicz | Oct 1998 | A |
6411684 | Cohn | Jun 2002 | B1 |
6545669 | Kinawi et al. | Apr 2003 | B1 |
6941348 | Petry et al. | Sep 2005 | B2 |
7363345 | Austin-Lane et al. | Apr 2008 | B2 |
7505571 | Bhatia et al. | Mar 2009 | B2 |
7525571 | Ando et al. | Apr 2009 | B2 |
7525691 | Gordon et al. | Apr 2009 | B2 |
7788218 | Gerritsen et al. | Aug 2010 | B2 |
7886236 | Kolmykov-Zotov et al. | Feb 2011 | B2 |
7895537 | Gruen et al. | Feb 2011 | B2 |
8005462 | Roy | Aug 2011 | B2 |
8019863 | Jeide et al. | Sep 2011 | B2 |
8054294 | Sakai et al. | Nov 2011 | B2 |
8250159 | Starbuck et al. | Aug 2012 | B2 |
8255468 | Vitaldevara et al. | Aug 2012 | B2 |
8291349 | Park et al. | Oct 2012 | B1 |
8316095 | Wheeler et al. | Nov 2012 | B1 |
8390577 | Lemort et al. | Mar 2013 | B2 |
8451246 | Scholler | May 2013 | B1 |
8635561 | Bullock et al. | Jan 2014 | B1 |
8775520 | Lewis et al. | Jul 2014 | B1 |
8782566 | Sarkar et al. | Jul 2014 | B2 |
8787335 | Smith et al. | Jul 2014 | B2 |
8793591 | Coleman et al. | Jul 2014 | B1 |
8836147 | Uno et al. | Sep 2014 | B2 |
8839147 | Kang et al. | Sep 2014 | B2 |
8910068 | Shin et al. | Dec 2014 | B2 |
9063989 | Buchheit et al. | Jun 2015 | B2 |
9248376 | Yoshikawa et al. | Feb 2016 | B2 |
9360998 | Bauder et al. | Jun 2016 | B2 |
20020054117 | Van et al. | May 2002 | A1 |
20020087704 | Chesnais et al. | Jul 2002 | A1 |
20030020687 | Sowden et al. | Jan 2003 | A1 |
20050015432 | Cohen | Jan 2005 | A1 |
20050043015 | Muramatsu | Feb 2005 | A1 |
20050068971 | Meisl et al. | Mar 2005 | A1 |
20050081059 | Bandini et al. | Apr 2005 | A1 |
20050181768 | Roy | Aug 2005 | A1 |
20050275638 | Kolmykov-Zotov et al. | Dec 2005 | A1 |
20060090137 | Cheng et al. | Apr 2006 | A1 |
20060155810 | Butcher | Jul 2006 | A1 |
20060190830 | Gerstl et al. | Aug 2006 | A1 |
20060206570 | Heidloff | Sep 2006 | A1 |
20070038707 | Broder et al. | Feb 2007 | A1 |
20070076857 | Chava et al. | Apr 2007 | A1 |
20070229465 | Sakai et al. | Oct 2007 | A1 |
20070277125 | Shin et al. | Nov 2007 | A1 |
20080059590 | Sarafijanovic et al. | Mar 2008 | A1 |
20080074399 | Lee | Mar 2008 | A1 |
20080165145 | Herz et al. | Jul 2008 | A1 |
20080201668 | Roy | Aug 2008 | A1 |
20080208980 | Champan et al. | Aug 2008 | A1 |
20080220798 | Potluri et al. | Sep 2008 | A1 |
20080222540 | Schulz et al. | Sep 2008 | A1 |
20080256179 | Gorty et al. | Oct 2008 | A1 |
20080270548 | Glickstein et al. | Oct 2008 | A1 |
20080294735 | Muntermann | Nov 2008 | A1 |
20090076966 | Bishop et al. | Mar 2009 | A1 |
20090079699 | Sun | Mar 2009 | A1 |
20090093277 | Lee et al. | Apr 2009 | A1 |
20090150905 | Lin et al. | Jun 2009 | A1 |
20090157831 | Tian et al. | Jun 2009 | A1 |
20090172695 | Lazaroff et al. | Jul 2009 | A1 |
20090178008 | Herz et al. | Jul 2009 | A1 |
20090233618 | Bai et al. | Sep 2009 | A1 |
20090244015 | Sengupta et al. | Oct 2009 | A1 |
20090254624 | Baudin et al. | Oct 2009 | A1 |
20090276701 | Nurmi | Nov 2009 | A1 |
20090278806 | Duarte et al. | Nov 2009 | A1 |
20090282360 | Park et al. | Nov 2009 | A1 |
20090307623 | Agarawala et al. | Dec 2009 | A1 |
20090313567 | Kwon et al. | Dec 2009 | A1 |
20100031202 | Morris et al. | Feb 2010 | A1 |
20100070594 | Yoshimura | Mar 2010 | A1 |
20100095249 | Yoshikawa et al. | Apr 2010 | A1 |
20100153493 | Clarke | Jun 2010 | A1 |
20100199226 | Nurmi | Aug 2010 | A1 |
20100210214 | Pawar et al. | Aug 2010 | A1 |
20100214237 | Echeverri et al. | Aug 2010 | A1 |
20100235794 | Ording | Sep 2010 | A1 |
20100241973 | Whiddett | Sep 2010 | A1 |
20100257241 | Hale et al. | Oct 2010 | A1 |
20100295805 | Shin et al. | Nov 2010 | A1 |
20100299638 | Choi | Nov 2010 | A1 |
20110022471 | Brueck | Jan 2011 | A1 |
20110074828 | Capela et al. | Mar 2011 | A1 |
20110081923 | Forutanpour et al. | Apr 2011 | A1 |
20110106880 | Strong et al. | May 2011 | A1 |
20110163970 | Lemay | Jul 2011 | A1 |
20110197153 | King et al. | Aug 2011 | A1 |
20110202616 | Kinoshita | Aug 2011 | A1 |
20110209195 | Kennedy | Aug 2011 | A1 |
20110289162 | Furlong et al. | Nov 2011 | A1 |
20110295958 | Liu et al. | Dec 2011 | A1 |
20110296351 | Ewing et al. | Dec 2011 | A1 |
20110302515 | Kim | Dec 2011 | A1 |
20120023375 | Dutta et al. | Jan 2012 | A1 |
20120030407 | Pandey et al. | Feb 2012 | A1 |
20120124147 | Hamlin et al. | May 2012 | A1 |
20120131458 | Hayes | May 2012 | A1 |
20120131474 | Panchadsaram et al. | May 2012 | A1 |
20120131659 | Roy et al. | May 2012 | A1 |
20120161458 | Sim | Jun 2012 | A1 |
20120185781 | Guzman et al. | Jul 2012 | A1 |
20120185797 | Thorsen et al. | Jul 2012 | A1 |
20120210214 | Yoo et al. | Aug 2012 | A1 |
20120210334 | Sutedja et al. | Aug 2012 | A1 |
20120240054 | Webber | Sep 2012 | A1 |
20120254793 | Briand et al. | Oct 2012 | A1 |
20120256863 | Zhang et al. | Oct 2012 | A1 |
20120290946 | Schrock et al. | Nov 2012 | A1 |
20120304074 | Ooi et al. | Nov 2012 | A1 |
20130035123 | Smith et al. | Feb 2013 | A1 |
20130050118 | Kjelsbak et al. | Feb 2013 | A1 |
20130057902 | Henry et al. | Mar 2013 | A1 |
20130067392 | Leonard et al. | Mar 2013 | A1 |
20130072263 | Kim | Mar 2013 | A1 |
20130100036 | Papakipos et al. | Apr 2013 | A1 |
20130104089 | Rieffel et al. | Apr 2013 | A1 |
20130117713 | Bauder et al. | May 2013 | A1 |
20130125063 | Lee et al. | May 2013 | A1 |
20130145303 | Prakash et al. | Jun 2013 | A1 |
20130167082 | Joo et al. | Jun 2013 | A1 |
20130179517 | Grosu | Jul 2013 | A1 |
20130179801 | Audet et al. | Jul 2013 | A1 |
20130204946 | Forstall et al. | Aug 2013 | A1 |
20130290876 | Anderson et al. | Oct 2013 | A1 |
20130290879 | Greisson | Oct 2013 | A1 |
20130324222 | De Viveiros Ortiz | Dec 2013 | A1 |
20140123043 | Schmidt et al. | May 2014 | A1 |
20140129942 | Rathod | May 2014 | A1 |
20140157182 | Kim | Jun 2014 | A1 |
20140165012 | Shen et al. | Jun 2014 | A1 |
20140304615 | Coe et al. | Oct 2014 | A1 |
20140317545 | Miyazaki | Oct 2014 | A1 |
20150032829 | Barshow et al. | Jan 2015 | A1 |
20150112749 | Erdal | Apr 2015 | A1 |
20150135337 | Fushman et al. | May 2015 | A1 |
20150169068 | Plagemann et al. | Jun 2015 | A1 |
20150277717 | Barabash et al. | Oct 2015 | A1 |
20160026704 | Strong et al. | Jan 2016 | A1 |
20160104089 | Speich et al. | Apr 2016 | A1 |
20160274747 | Bauder et al. | Sep 2016 | A1 |
Number | Date | Country |
---|---|---|
2011253700 | Dec 2011 | AU |
102495692 | Jun 2012 | CN |
1942401 | Jul 2008 | EP |
2116927 | Nov 2009 | EP |
2362592 | Aug 2011 | EP |
2009-151638 | Jul 2009 | JP |
2010-525740 | Jul 2010 | JP |
2011-188327 | Sep 2011 | JP |
2012-038292 | Feb 2012 | JP |
0163875 | Aug 2001 | WO |
2008030970 | Mar 2008 | WO |
2012068401 | May 2012 | WO |
2012068407 | May 2012 | WO |
2013009092 | Apr 2013 | WO |
Entry |
---|
Tsai, Henry, “Getting Started on Astrid's “Remind Me” Gmail Integration,” Astrid.com, [online], Feb. 11, 2013, [retrieved on Jan. 3, 2013], retrieved from the internet: <URL:http://blog.astrid.com/b!og/2013/02/11/getteng-started.on- astrids-remind-me-extension>, 5 pages. |
Tsai, “Getting Started on Astrid's ‘Remind Me’ Gmail Integration,” Astrid.com, retrieved online on Jan. 3, 2013, <URL: http://blog.astrid.com/blog/2013/02/11/getting-started-on-astrids-remind-- me-extension>, Feb. 11, 2013, 5 pgs. |
Orchestra To-do, 2013, [online], [retrieved on May 13, 2013], retrieved from the internet <URL: https://itunes.apple.com/us/app/orchestra-to-do>, 3 pages. |
Klinker, Jacob, “Sliding Messaging Pro,” 2013, [online], [retrieved on May 13, 2013], retrieved from the internet <URL:https://play.google.com/store/apps/details?id=com.klinkerandroid>, 3 pages. |
International Search Report and Written Opinion dated Mar. 18, 2014 in PCT/US2013/071066, 14 pages. |
International Search Report and Written Opinion dated Aug. 13, 2014 in PCT/US2013/071074, 15 pages. |
International Preliminary Report on Patentability received for PCT Patent Application No. PCT/US13/71074, dated Jun. 4, 2015, 10 pages. |
International Preliminary Report on Patentability received for PCT Patent Application No. PCT/US13/71066, dated Jun. 4, 2015, 12 pages. |
Author: Guiding Tech Title: Hold Mouse Right Button for More Options on Drag and Drop Date: Jul. 1, 2012 pp. 1-6. |
“Triage: Email First Aid,” 2013, [online], [retrieved on May 13, 2013], retrieved from the internet <URL: https://www.triage.cc/>, 2 pages. |
“Taskbox: Emails & Task Lists Rolled Into One,” posted Apr. 22, 2013 by Jesse Virgil, [online], [retrieved on Jan 3, 2014], retrieved from the internet <URL: http://iphone.appstorm.net/reviews/productivity/taskbox-emails-task-lists-rolled-into-one/>, 12 pages. |
“Taskbox—Mail,” 2013, [online], [retrieved on May 13, 2013], retrieved from the internet <URL: https://itunes.apple.com/us/app/taskbox-mail>, 3 pages. |
“Move Over Mailbox, Taskbox Is Better for Us Working Folks,” Mar. 9, 2013, Niblitz.com, [online], [retrieved on Jan. 3, 2014], retrieved from the internet <URL: http://nibletz.com/2013/03/09/move-mailbox-taskbox-working-folks>, 2 pages. |
“Browse through your email more efficiently with Swipe for Mail,” posted Feb. 19, 2012 by Cody Lee, [online], [retrieved on May 13, 2013], retrieved from the internet <URL:http://www.idownloadblog.com/2012/02/19/swipemail-jailbreak-tweak/>, 5 pages. |
“Activator: a free and extremely powerful jailbreak app launcher for iPhone,” posted Feb. 1, 2010 by Thomas Wong, iSource.com, [online], [retrieved on May 13, 2013], retrieved from the internet <URL: http://isource.com/2010/02/01/activator-a-free-and-extremely-powerful>, 5 pages. |
“[Quick Tip] Hold Mouse Right Button for More Options on Drag and Drop,” Guiding Tech, Jul. 1, 2012, [online], <URL: http://www.guidingtech.com/12504/hold-mouse-right-button-more-drag- drop-options/>, 6 pages. |
Number | Date | Country | |
---|---|---|---|
20180191661 A1 | Jul 2018 | US |
Number | Date | Country | |
---|---|---|---|
61728635 | Nov 2012 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 14084142 | Nov 2013 | US |
Child | 15901025 | US |