Patent Description:
Hosted services can take a wide variety of different forms. For instance, some hosted services host a suite of applications, such as an electronic mail application, a calendar application, task and contact applications, etc. The hosted services can be accessed by client components of the hosted services that reside on a client machine. For instance, a client component may surface user interface functionality that allows a user to perform calendar functions (such as to schedule appointments, etc.), email functions (such as to prepare and send e-mail messages, receive e-mail messages, manage folders in an e-mail system, manage filters, etc.), add, delete and modify contact information, among a wide variety of other things.

When the user performs these operations, the client component generates data that is synchronized to the remote server environment in which the service is deployed. Similarly, the remote server environment may need to synchronize data from its environment to the client. By way of example, if the hosted service is an electronic mail service, and the user has received new messages from other e-mail users, the service will synchronize that information down to the client computing system, the next time the user logs into the e-mail service.

Some hosted electronic mail services provide a draft roaming feature. This feature allows a user to begin drafting an e-mail message and, before the user is finished, save it as a draft. The user may then use a different device to log into the e-mail system at a later time. When the user does this, the e-mail service provides the user with access to the draft, even though the user is accessing the e-mail service through a different device than the one on which the draft was begun. Providing this type of access (through different devices) to draft e-mail messages that a user began on a different device is referred to as a draft roaming feature.

Some e-mail messages are part of a very lengthy thread, which can include a large number of other messages. Similarly, some e-mail messages have rather large attachments. A smart reply feature allows a user to reply to an e-mail message without loading the entire or full content corresponding to the e-mail message, onto the user device through which the user is accessing the service and generating the reply. By way of example, a user may receive an e-mail message that has a large attachment. The user may wish to simply forward that message to a different user, along with the attachment. A smart reply feature maintains the full e-mail message at the service (the body of the e-mail message and the associated attachment) and allows the user to generate a forwarding message, including a message body that has the text that the user inputs. When the user sends that message, the service will automatically attaches the attachment to the forwarding message, and sends it to the recipient. Thus, the user never needs to download the entire attachment in order to generate and send a reply. The same is true of a lengthy e-mail thread. That is, using a smart reply feature, the user need not download the entire e-mail thread in order to reply to or forward a message in that thread. Instead, the service maintains the full e-mail thread and receives the new content of the reply message from the user, and then attaches the full e-mail thread before sending it on to the recipient.

In addition, the synchronization mechanisms in such services often use a particular protocol in order to synchronize content between the service and client devices. When a new synchronization mechanism is deployed, it often uses a different protocol, which is incompatible with the protocol from the previous synchronization mechanism. As one example, when a first synchronization mechanism is used to synchronize data between a service and client systems, it may identify the objects that are synchronized (e.g., the e-mail messages, calendar events, contacts, etc.) using a first type of object identifying mechanism. However, a second synchronization mechanism may use a different type of object identifying mechanism in order to identify those objects. Therefore, if a service is running with the first synchronization mechanism, but wishes to change or upgrade to the second synchronization mechanism, that process often requires the service to synchronize all of the application data with the second mechanism, even though much of it has already been synchronized with the first mechanism. This can take a great deal of time, and cause disruption in the user experience.

Further, some services synchronize data between the service and a client component, upon a user logging into the service. For instance, when a user logs onto his or her e-mail service, the service may, at that time, begin synchronizing the user's inbox from the service to the client device. The synchronization mechanism can be fairly complex. For instance, it may first need to identify the differences between the inbox representations on the client system and the service. This can include enumerating all objects in the inbox of both systems and comparing them to identify items that need to be synchronized. Regardless of the particular synchronization mechanism that is used, it can be relatively computationally expensive and it can be relatively time consuming.

<CIT> discloses an e-mail system that is backward compatible with existing e-mail systems. The system may include various features, including: secure transfer of e-mail messages, without the need for users to replace existing e-mail clients or to change e-mail addresses; tracking of all actions performed in connection with an e-mail transmission; the ability for a recipient to view information about an e-mail message, optionally including information about how other addressees have responded to it, before deciding whether to retrieve the e-mail message; the aggregation of entire e-mail conversations into a single threaded view; the ability to include both private and public messages in a single e-mail communication; sender control over downstream actions performed in connection with an e-mail message; flexible control over cryptographic methods used to encrypt emails messages for storage.

<CIT> discloses a first method whereby, at a server, receiving a new message in a message thread, identifying quoted text (e.g., text from a previous message in the message thread) in the new message, replacing the quoted text with a token that includes information uniquely associated with the previous message to produce a modified incoming message, and sending the modified incoming message to a client. The token includes information identifying the previous message in the message thread. The token identifies a range of text in the previous message, and the text replaced by the token corresponds to the range of text in the previous message identified by the token. The token comprises a tag having text to be displayed by the client. The method includes sending to the client all messages in the message thread, including the modified incoming message.

According to aspects of the present invention there is provided a computing system and a computing implemented method as defined in the accompanying claims.

An electronic mail computing system has a smart reply system that that enables a smart reply feature that surfaces a user input mechanism that allows a user to reply to an e-mail message without downloading full content of the e-mail message to the user's client computing system. A draft roaming system interacts with the client computing system to allow a plurality of different user devices to access a draft electronic mail message, and interacts with the smart reply system so a draft can be generated using the smart reply feature.

The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background.

<FIG> and <FIG> (collectively referred to herein as <FIG>) show a block diagram of one example of a computing system architecture <NUM>. Architecture <NUM> includes service computing system <NUM> and client computing system <NUM> that communicate with one another over network <NUM>. Network <NUM> can be any of a wide variety of different types of networks, such as a wide area network, a local area network, etc..

In one example, service computing system <NUM> hosts a service that is accessed by client computing system <NUM>. Client computing system <NUM> thus generates user interfaces <NUM> with user input mechanisms <NUM> for interaction by user <NUM>. User <NUM> illustratively interacts with user input mechanisms <NUM> in order to control and manipulate client computing system <NUM> and ultimately service computing system <NUM>. Before describing the overall operation of architecture <NUM> in more detail, a brief description of some of the items in architecture <NUM>, and their operation, will first be provided.

<FIG> shows that, in one example, service computing system <NUM> includes processors or servers <NUM>, service functionality <NUM>, on-line view generation system <NUM>, data store <NUM>, view blending logic <NUM>, (which is shown in ghost on system <NUM> and on client computing system <NUM> because it can reside either place) server side application <NUM>, first synchronization system <NUM>, second synchronization system <NUM>, and it can include other items <NUM>. Data store <NUM>, itself, can include first application data <NUM>, second application data <NUM>, and it can include other items <NUM>. Server side application <NUM> can include functionality logic <NUM>, application data location identifier <NUM>, and it can also include other items.

Service functionality <NUM> illustratively includes logic and functionality that performs functions and operations to implement the hosted service or server side application <NUM>. Therefore, functionality <NUM> can manage virtual machines or hardware or other software components. It can also perform a wide variety of other functions to host server side application <NUM>. On-line view generation system <NUM> will be described in greater detail below with respect to <FIG> and <FIG>. Briefly, it illustratively generates an on-line, truncated view of data when a user logs onto the service. This can be displayed to the user while a synchronization system (such as first or second synchronization system <NUM> or <NUM>, respectively) begin synchronizing data between the service and the client system. Once the synchronized data is ready, a view of the synchronized data can be used to replace the on-line view.

View blending logic <NUM> illustratively manages the operation of first displaying the on-line view of the relevant data, and then displaying the synchronized view, once it is ready. This can be done in a variety of different ways, and this is also described in more detail below with respect to <FIG> and <FIG>.

Server side application <NUM> illustratively includes functionality logic <NUM> that implements the functionality of the server side application. For instance, where application <NUM> is an electronic mail (e-mail) application, then logic <NUM>, in conjunction with service functionality <NUM>, can implement e-mail functionality that allows users to access the e-mail application and perform e-mail functions. Where application <NUM> is a calendaring application, then functionality <NUM>, in conjunction with functionality <NUM>, allows the user to access the calendaring functions and perform different calendaring tasks. These are examples only and a wide variety of other services can be embodied in server side application <NUM>.

Application data location identifier <NUM> illustratively identifies, for application <NUM>, where it is to access application data in data store <NUM>. For instance, service computing system <NUM> may be using a first synchronization system <NUM> that synchronizes data between client computing system <NUM> and data store <NUM> in service computing system <NUM> according to a first protocol. It may do that by synchronizing first application data <NUM> which may be, for instance, user mailboxes, calendars, contact lists, tasks, notes, etc. In that case, application data location identifier <NUM> will identify the location of first application data <NUM> in data store <NUM>. It will of course be understood that data store <NUM> can be local to computing system <NUM> or it can be located elsewhere. In addition, it can be located at multiple different locations.

Regardless, it may be that service computing system <NUM> wishes to change (or upgrade) to synchronizing data with a second synchronization system <NUM> that synchronizes data between client computing system <NUM> and service computing system <NUM> according to a second protocol. Therefore, as is described in more detail below with respect to <FIG> and <FIG>, second synchronization system <NUM> may begin synchronizing data, as second application data <NUM>, even while first synchronization system <NUM> is still performing synchronization operations to support server side application <NUM>. When second synchronization system <NUM> has synchronized sufficient data, then it can change application data location identifier <NUM> to point to second application data <NUM> so that server side application <NUM> begins operating off second application data <NUM>, instead of first application data <NUM>. When second synchronization system <NUM> has synchronized all of the first application data <NUM>, then that data can be deleted and first synchronization system <NUM> can be removed from service computing system <NUM> as well.

Client computing system <NUM>, in the example shown in <FIG>, illustratively includes one or more processors or servers <NUM>, user presence detector <NUM> (which can also be located on service computing system <NUM>), client side application <NUM>, data store <NUM>, user interface logic <NUM>, and it can include a wide variety of other client functionality <NUM>. User presence detector <NUM> can detect a number of different things on client computing system <NUM> to determine whether user <NUM> is present (at least whether the user is present with respect to the service side application <NUM> hosted by service computing system <NUM>). For instance, detector <NUM> can detect whether the user is logged into the service, whether the user has recently used the service, whether the user has used other items on client computing system <NUM>, etc. It illustratively outputs a signal indicative of whether the user <NUM> is present.

Client side application <NUM> can be a client component of server side application <NUM>. Therefore, it can use user interface logic <NUM> to surface user interfaces <NUM> with user input mechanisms <NUM> that allow user <NUM> to access both the client side application <NUM>, and server side application <NUM>. In doing so, it can generate application data <NUM>, and other data <NUM>. For instance, user <NUM> can use client side application <NUM> to generate an appointment on the user's calendar. This may be stored as application data <NUM>. The synchronization system being used by computing system <NUM> then synchronizes that data to data tore <NUM> so that it can be used by server side application <NUM> as well.

<FIG> is a block diagram showing one example of second synchronization system <NUM>, in more detail. In one example, it includes synchronization start logic <NUM>, synchronization logic <NUM>, handoff detection logic <NUM>, and it can include a wide variety of other items <NUM>. Synchronization start logic <NUM> illustratively detects when second synchronization system <NUM> is to synchronize data between service computing system <NUM> and client computing system <NUM>. Synchronization logic <NUM> illustratively performs the actual synchronization operations. It can include difference identifier logic <NUM>, difference synchronization logic <NUM>, and other items <NUM>. Difference identifier logic <NUM> identifies differences in the application data <NUM> and the application data stored on data store <NUM>. Difference synchronizer logic <NUM> illustratively performs operations to synchronize that data between service <NUM> and client computing system <NUM>.

Handoff detection logic <NUM> can be used to detect when the handoff should occur between first synchronization system <NUM> and second synchronization system <NUM>, in a scenario where service computing system <NUM> is in the process of switching from using first synchronization system <NUM> to using second synchronization system <NUM>. In one example, logic <NUM> includes synchronized data volume detector <NUM>, comparison logic <NUM>, handoff control signal generator logic <NUM> and it can include other items <NUM>.

Synchronized data volume detector <NUM> detects a volume of application data that has been synchronized using second synchronization system <NUM>. The volume can be an overall aggregate volume of data, or it can detect when certain key portions of data have been synchronized. For instance, when the server side application <NUM> is an e-mail application, it may detect when the user's last week of e-mail messages have been synchronized. When server side application <NUM> is a calendar application, logic <NUM> may detect when the current month on the user's calendar, the previous month, and the next month, have all been synchronized. Detector <NUM> may detect when other criteria are met as well. Comparison logic <NUM> compares the detected volume (or detected other criteria) and compares them to a threshold value which is to be met before server side application <NUM> is handed off so that it operates on the second application data <NUM>, instead of the first application data <NUM>. Handoff control signal generator logic <NUM> generates a control signal to adjust the application data location identifier <NUM> so that it now identifies second application data <NUM> instead of first application data <NUM>. This is discussed in greater detail below with respect to <FIG>.

<FIG> and <FIG> (collectively referred to herein as <FIG>) show a flow diagram illustrating one example of the operation of architecture <NUM>, and second synchronization system <NUM>, in synchronizing data and controlling server side application <NUM> to switch between using first application data <NUM> that was synchronized using first synchronization system <NUM>, and second application data <NUM> that was synchronized using second synchronization system <NUM>. In doing so, it is first assumed that the service is running with first synchronization system <NUM> synchronizing first application data <NUM>, and that server side application <NUM> is using first application data <NUM> to service requests from the various client computing systems. It is also assumed that the second synchronization system <NUM> is deployed on the service computing system <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>. Sync start logic <NUM> then detects the user presence as indicated by user presence detector <NUM>. This is indicated by block <NUM>. This, as described above, can be detected from a detector <NUM> on client computing system <NUM>, as indicated by block <NUM>, or from a detector on service computing system <NUM>, as indicated by block <NUM>. It can be detected in other ways as well, and this is indicated by block <NUM>.

In one example, second synchronization system <NUM> does not begin synchronizing the application data according to the second protocol while the user is present. Therefore, if the user is not present, as indicated by block <NUM>, then second synchronization system <NUM> begins synchronizing second application data <NUM>. This is indicated by block <NUM>.

In doing so, it does not yet switch over server side application <NUM> to begin using second application data <NUM>. This is indicated by block <NUM>. As mentioned above, it synchronizes the data using a second synchronization protocol as indicated by block <NUM>. It can synchronize the data in other ways as well, and this is indicated by block <NUM>.

At some point, synchronized data volume detector <NUM> detects a volume (or other characteristic) of the data synchronized. This is indicated by block <NUM>. Again, this can be an aggregate volume metric that identifies the aggregate volume of application data that has been synchronized by second synchronization system <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>. It can also detect whether key data records have been synchronized, as discussed above. This is indicated by block <NUM>. It can detect the volume or other attributes of the data that have been synchronized in other ways as well, and this is indicated by block <NUM>.

Comparison logic <NUM> then determines whether the detected volume meets handoff criteria for switching the application <NUM> from using first application data <NUM> to using second application data <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>. If not, processing returns to block <NUM> where second synchronization system <NUM> continues to synchronize data. The handoff criteria can take a variety of different forms. For instance, it can be a threshold proportion of the application data as indicated by block <NUM>. The criteria can be that all of the application data be synchronized as indicated by block <NUM>. It can be a wide variety of other handoff criteria <NUM>, as indicated by block <NUM>.

Once the detected data that has been synchronized by second synchronization system <NUM> meets the handoff criteria, then handoff control signal generator logic <NUM> generates a control signal to switch the server side application <NUM> to using data at the data location for the second application data <NUM> synchronized using the second synchronization system. This is indicated by block <NUM> in the flow diagram of <FIG>. Second synchronization system <NUM> continues to synchronize application data, as indicated by block <NUM>.

Until all of the application data has been completely synchronized by second synchronization system <NUM>, it may be that server side application <NUM>, even though it is using second application data <NUM>, will receive a call for data that has not yet been synchronized by second synchronization system <NUM>. This is indicated by blocks <NUM> and <NUM> in the flow diagram of <FIG>. When this occurs, then second synchronization system <NUM> directs server side application <NUM> to service the call by accessing first application data <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>.

Once all of the application data has been synchronized by second synchronization system <NUM>, then service computing system <NUM> discontinues synchronizing data with first synchronization system <NUM>. This is indicated by block <NUM> in flow diagram of <FIG>. It then deletes the first application data <NUM>. This is indicated by block <NUM>.

In doing this, it can be seen that second synchronization system <NUM> begins synchronizing data, without the user ever knowing it. The server side application is not switched over to using that synchronization data, until the service calls can most likely be serviced from the data synchronized by second synchronization system <NUM>. All the while, second synchronization system <NUM> continues to synchronize the application data, until it is all synchronized, at which point the service can then run using only second synchronization system <NUM> to synchronize the data. This allows switching to a different synchronization system to obtain all the benefits of such a system, even if it uses a different synchronization protocol, substantially invisible to the user.

<FIG> is a block diagram showing one example of on-line view generation system <NUM> in more detail. In one example, it includes a view call detector <NUM>, data accessing logic <NUM>, truncation logic <NUM>, view generator logic <NUM>, and it can include other items <NUM>. View call detector <NUM> detects when a call for a view of data has been made to server side application <NUM>. For instance, when application <NUM> is an e-mail system, the user <NUM> may log into the system and, at that point, a call to see the user's inbox may be generated by client computing system <NUM>.

Data accessing logic <NUM> then accesses the relevant portion of the application data in data store <NUM> that is to be surfaced for the view. Truncation logic <NUM> truncates that data and view generator logic <NUM> generates a view of the truncated data so that it can be immediately handed to client computing system <NUM> for display to user <NUM>. It will be noted that on-line view generation system <NUM> does not wait for data to be synchronized between client computing system <NUM> and service computing system <NUM>, in order to generate the view. For instance, it may simply take a view of the user's inbox from the data store <NUM> in service computing system <NUM>, before that data is synchronized with the data in client computing system <NUM>. In this way, at least the client will see the version of the inbox stored on service computing system <NUM>, very quickly. At the same time, the synchronization system will be synchronizing data in the client computing system <NUM> with data in the service computing system <NUM> and when the synchronized data is ready, a view of the synchronized data can be generated and that view can replace the on-line view that shows only the view of the data from the service computing system data, before it is synchronized.

<FIG> is a flow diagram illustrating one example of this operation. View call detector <NUM> first detects a call to view application data. This is indicated by block <NUM> in the flow diagram of <FIG>. This can occur, as mentioned above, when the user logs into the service (such as the user's e-mail system). This is indicated by block <NUM>. It can be detected in other way as well, and this is indicated by block <NUM>.

At that point, the synchronization system on service computing system <NUM> (for purposes of the present discussion, it will be assumed that it is second synchronization system <NUM>) begins synchronizing the application data <NUM> on client computing system <NUM> with the second application data <NUM> on service computing system <NUM>. This is indicated by block <NUM>. Once the data has been synchronized, it generates a synchronized view showing the synchronized data. This is indicated by block <NUM>.

While system <NUM> is synchronizing the data, data accessing logic <NUM> accesses the relevant application data <NUM>. This is indicated by block <NUM>. Depending on the particular application <NUM>, this may be data for the user's inbox <NUM>, for the user's calendar <NUM>, or a wide variety of other data <NUM>.

Truncation logic <NUM> generates a truncated form of the relevant data. This is indicated by block <NUM>. Again, the truncated view will be of only non-synchronized data (e.g., server side only data that has not been synchronized service the current call was made to view the data). This is indicated by block <NUM>. The truncated view can include a data limit (such as the top N message threads in the user's inbox). This is indicated by block <NUM>. It can include individual data record truncation, (such as truncating a message thread to only the message headers). This is indicated by block <NUM>. The truncation can take a wide variety of other forms as well, and this is indicated by block <NUM>.

View generator logic <NUM> then generates an on-line view with the truncated data. This is indicated by block <NUM>. For example, the view may be a view of the user's inbox showing only the message thread headers, instead of additional message content. It will be noted that the views can be generated on the client system or on the service.

System <NUM> then uses view blending logic <NUM> to surface the on-line view, through client side application <NUM>, for user <NUM>. Again, it will be noted that logic <NUM>, and thus the view blending, can take place either on system <NUM> or on system <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>.

Once the synchronized view is generated, however, view blending logic <NUM> surfaces the synchronized view. This is indicated by block <NUM>. For instance, as data items in the user's inbox are synchronized, that portion of the on-line view can be replaced by a view of the synchronized data. This is indicated by block <NUM>. In another example, the entire inbox is synchronized before the synchronized view replaces the on-line view. This is indicated by block <NUM>. Surfacing the synchronized view can be done in other ways as well, and this is indicated by block <NUM>.

It can thus be seen that, using this approach, a user very quickly receives the server side view of the user's data (e.g., the user's inbox) as soon as the user logs into the system. That view is not delayed while synchronization takes place. Instead, the view is generated of only the server side data, and when the data is actually synchronized, then a view of the synchronized data is generated and it replaces the on-line view.

<FIG> and <FIG> (collectively referred to herein as <FIG>) show a block diagram showing another example of a computing system architecture <NUM>, in which service computing system <NUM> is an electronic mail computing system <NUM>. It illustratively hosts an electronic mail service for a plurality of different client systems <NUM>-<NUM>. Each of the client systems <NUM>-<NUM> can generate user interfaces <NUM>-<NUM>, with user input mechanisms <NUM>-<NUM> for interaction by users <NUM>-<NUM>, respectively. The users can interact with the user input mechanisms in order to control the corresponding client systems and e-mail computing system <NUM>. Before the operation of architecture <NUM> is described in more detail, a brief description of some of the items in architecture <NUM>, and their operation, will first be described.

E-mail computing system <NUM> can include one or more processors or servers <NUM>, e-mail functionality logic <NUM>, a synchronization system <NUM> (which can be either first or second synchronization system <NUM> or <NUM> from <FIG>, or a different one), smart reply system <NUM>, draft roaming system <NUM>, data store <NUM>, and it can include a wide variety of other items <NUM>.

E-mail functionality logic <NUM> illustratively performs functions and operations to implement the operation of e-mail computing system <NUM>. For instance, it illustratively performs operations that allow users to draft, reply to, delete or modify e-mail messages, perform folder operations, filter operations, send and receive e-mail messages, among a wide variety of other functions.

Synchronization system <NUM> illustratively synchronizes the e-mail data between e-mail computing system <NUM> and the various client systems <NUM>-<NUM>.

Smart reply system <NUM> can include smart reply detection logic <NUM>, message truncation logic <NUM>, full message generation logic <NUM>, draft change detector logic <NUM>, and it can include other items <NUM>. Smart reply detection logic <NUM> detects when a user wishes to use the smart reply feature so that a user can reply to (or forward) an e-mail message without downloading the entire content of the e-mail message onto the user's device. Message truncation logic <NUM> then truncates the message that the user is replying to and downloads only that portion onto the client system. Full message generation logic <NUM> illustratively generates and maintains a full message so that when the user sends the reply, the full message can be sent to the desired recipient, and not just the truncated portion that the user downloaded. Draft change detector logic <NUM> detects when a draft that the user has previously worked on has changed, so that the smart reply features should not be used or so that the full message should be downloaded to the client system.

Draft roaming system <NUM> includes draft detection logic <NUM>, can include draft maintenance logic <NUM>, and it can include other items <NUM>. Draft detection logic <NUM> detects when a user begins to draft an e-mail message (such as a reply). Draft maintenance logic <NUM> illustratively maintains that draft in data store <NUM> so that the user can have access to it, even if the user logs onto the e-mail computing system <NUM> using a different device. This is referred to as roaming the draft across different devices.

Data store <NUM> can include one or more message threads <NUM>-<NUM>, one or more draft messages <NUM>-<NUM>, and it can include a wide variety of other items <NUM>. Each message thread <NUM> can include header data <NUM> that defines one or more headers in the message thread. It can also include one or more messages <NUM> in the thread, as well as any attachments <NUM> that belong to the thread.

Draft messages <NUM>-<NUM> include a unique body portion <NUM> and <NUM>, respectively, as well as an old mail thread portion <NUM>-<NUM>. By way of example, assume that draft <NUM> is a draft that has been started by user <NUM> and is in reply to an old message thread. Unique body portion <NUM> of the draft will be that portion that the user <NUM> is authoring in the reply message. The old mail thread <NUM> will illustratively correspond to the information in a message thread <NUM> or <NUM>, for example, that contains all of the prior information in that thread, to which the user is replying.

Each client system <NUM>-<NUM> can include one or more processors or servers <NUM>, a client component <NUM>, a data store <NUM>, user interface logic <NUM>, and it can include a wide variety of other items <NUM>. Client component <NUM> may be a client component of the electronic mail system being hosted by electronic mail computing system <NUM>. Data store <NUM> can store information generated or maintained by client component <NUM>. User interface logic <NUM>, either by itself or under the control of another item, can illustratively generate user interfaces <NUM> and user input mechanisms <NUM>, and detect user interaction with them.

In overall operation, smart reply system <NUM> detects when a user begins typing a reply message and determines whether the user has selected to use the smart reply feature. When the reply is a draft (in that the user logs out of the computing system or navigates away from the reply before sending the reply), draft detection logic <NUM> detects that the reply is a draft and that the user has invoked the smart reply feature. Draft maintenance logic <NUM> illustratively stores the draft (such as draft <NUM>) in data store <NUM> and maintains it in a way so that it is accessible by user <NUM> using any of a variety of other devices. In doing so, logic <NUM> accesses full message generation logic <NUM> to store the draft as a full message which includes the unique body portion <NUM> and the old mail thread portion <NUM>. When the user again accesses draft <NUM>, the unique body portion <NUM> can be downloaded to the client system <NUM> by message truncation logic <NUM> in smart reply system <NUM> so that the user still need not download the full draft message (including the old mail thread <NUM>). Then, when the user finishes the draft and hits a send actuator, full message generation logic <NUM> again attaches the full message content (e.g., the old message thread <NUM>) to the draft and sends it to the desired recipient.

Draft change detector logic <NUM> can detect whether the draft has changed since it was created by the user. For instance, it may be that, in the message thread, another user has include in-line comments in the old mail thread <NUM>. In that case, when user <NUM> again accesses the draft <NUM>, the full message will be downloaded to the user so that he or she can see that the old message thread has now been modified with the insertion of in-line comments.

<FIG> and <FIG> (collectively referred to herein as <FIG>) show one example of the operation of architecture <NUM>, shown in <FIG>, in implementing both the smart reply feature and the draft roaming feature on the same e-mail service.

Draft detection logic <NUM> first detects creation of a draft response by a user of a client system <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>.

Smart reply detection logic <NUM> then detects that the user has invoked the smart reply feature. This is indicated by block <NUM>. This can be done, for instance, by surfacing a user input mechanism that allows the user to choose the smart reply feature. It can be done in other ways as well.

When the user has created the draft, full message generation logic <NUM> generates a full message of the draft (both containing the unique body portion <NUM> and the old mail thread <NUM> and any attachments), and saves it in data store <NUM>. This is indicated by block <NUM>.

Draft maintenance logic <NUM> then roams the unique portion of the draft to other devices. This is indicated by block <NUM>. For instance, if user <NUM> accesses e-mail computing system <NUM> using a different device, the user will have access to the unique body portion <NUM> in the smart reply mode as well. This is indicated by block <NUM>.

Draft change detector logic <NUM> then detects whether the old mail thread has changed since the user created the draft. This is indicated by block <NUM>. If not, then message truncation logic <NUM> identifies the unique body portion <NUM> and synchronizes that to client system <NUM> so the user can continue to work on the draft. This is indicated by blocks <NUM> and <NUM> in the flow diagram of <FIG>.

However, if, at block <NUM>, it is determined that the old mail thread has changed since the user created the draft, then full message generation logic <NUM> accesses the full content of the draft <NUM> and syncs the full draft to the new device through which the user is currently accessing e-mail computing system <NUM>. This is indicated by blocks <NUM> and <NUM> in the flow diagram of <FIG>.

In either case (whether the user is still accessing the draft using the smart reply feature, or whether the user is accessing the full draft), e-mail computing system <NUM> detects when the user actuates the send actuator to send the draft to the desired recipients. This is indicated by block <NUM> in the flow diagram of <FIG>.

Smart reply detection logic <NUM> determines whether the draft is still being accessed in the smart reply mode as indicated by block <NUM>. If not, then the user is already accessing the full draft and that draft is simply sent to the recipient as indicated by block <NUM>.

However, if, at block <NUM>, it is determined that the user is still accessing the draft in the smart reply mode, then full message generation logic <NUM> again forms the full content of the reply message by adding the old mail threads <NUM> to the unique body portion <NUM> (along with any attachments). Stitching together the full draft in this way is indicated by block <NUM> in <FIG>. Again, the full draft is then sent as indicated by block <NUM>.

It can thus be seen that the present description enables a single e-mail system to include not only a smart reply system <NUM> that implements a smart reply feature, but also to include a draft roaming system <NUM> that implements the draft roaming feature. This improves the computing system itself, as well as the user experience.

The present discussion has mentioned processors and servers. In one embodiment, the processors and servers include computer processors with associated memory and timing circuitry, not separately shown. They are functional parts of the systems or devices to which they belong and are activated by, and facilitate the functionality of the other components or items in those systems.

<FIG> is a block diagram of architecture <NUM>, shown in <FIG>, and architecture <NUM> shown in <FIG> except that the elements are disposed in a cloud computing architecture <NUM>. Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location or configuration of the system that delivers the services. In various embodiments, cloud computing delivers the services over a wide area network, such as the internet, using appropriate protocols. For instance, cloud computing providers deliver applications over a wide area network and they can be accessed through a web browser or any other computing component. Software or components of architectures <NUM> and/or <NUM> as well as the corresponding data, can be stored on servers at a remote location. The computing resources in a cloud computing environment can be consolidated at a remote data center location or they can be dispersed. Cloud computing infrastructures can deliver services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from a conventional server, or they can be installed on client devices directly, or in other ways.

The description is intended to include both public cloud computing and private cloud computing. Cloud computing (both public and private) provides substantially seamless pooling of resources, as well as a reduced need to manage and configure underlying hardware infrastructure.

A public cloud is managed by a vendor and typically supports multiple consumers using the same infrastructure. Also, a public cloud, as opposed to a private cloud, can free up the end users from managing the hardware. A private cloud may be managed by the organization itself and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installations and repairs, etc..

In the example shown in <FIG>, some items are similar to those shown in <FIG> and <FIG> and they are similarly numbered. <FIG> specifically shows that service computing system <NUM> and/or email computing system <NUM> can be located in cloud <NUM> (which can be public, private, or a combination where portions are public while others are private). Therefore, the users can use user devices <NUM> to access those systems through cloud <NUM>.

<FIG> also depicts another example of a cloud architecture. <FIG> shows that it is also contemplated that some elements of architectures <NUM> and <NUM> can be disposed in cloud <NUM> while others are not. By way of example, data stores <NUM>, <NUM> can be disposed outside of cloud <NUM>, and accessed through cloud <NUM>. In another example, synchronization system <NUM>, <NUM> or other items can be outside of cloud <NUM>. Regardless of where they are located, they can be accessed directly by devices <NUM>, through a network (either a wide area network or a local area network), they can be hosted at a remote site by a service, or they can be provided as a service through a cloud or accessed by a connection service that resides in the cloud. All of these architectures are contemplated herein.

It will also be noted that architectures <NUM> and/or <NUM>, or portions of them, can be disposed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices, such as palm top computers, cell phones, smart phones, multimedia players, personal digital assistants, etc..

<FIG> is a simplified block diagram of one illustrative embodiment of a handheld or mobile computing device that can be used as a user's or client's hand held device <NUM>, in which the present system (or parts of it) can be deployed. <FIG> are examples of handheld or mobile devices.

<FIG> provides a general block diagram of the components of a client device <NUM> that can run components of architecture <NUM>, <NUM> or that interacts with architectures <NUM>, <NUM>, or both. In the device <NUM>, a communications link <NUM> is provided that allows the handheld device to communicate with other computing devices and under some embodiments provides a channel for receiving information automatically, such as by scanning. Examples of communications link <NUM> include an infrared port, a serial/USB port, a cable network port such as an Ethernet port, and a wireless network port allowing communication though one or more communication protocols including General Packet Radio Service (GPRS), LTE, HSPA, HSPA+ and other <NUM> and <NUM> radio protocols, 1Xrtt, and Short Message Service, which are wireless services used to provide cellular access to a network, as well as Wi-Fi protocols, and Bluetooth protocol, which provide local wireless connections to networks.

In other examples, applications or systems are received on a removable Secure Digital (SD) card that is connected to a SD card interface <NUM>. SD card interface <NUM> and communication links <NUM> communicate with a processor <NUM> (which can also embody processors or servers from previous Figures) along a bus <NUM> that is also connected to memory <NUM> and input/output (I/O) components <NUM>, as well as clock <NUM> and location system <NUM>.

I/O components <NUM>, in one embodiment, are provided to facilitate input and output operations. I/O components <NUM> for various embodiments of the device <NUM> can include input components such as buttons, touch sensors, multi-touch sensors, optical or video sensors, voice sensors, touch screens, proximity sensors, microphones, tilt sensors, and gravity switches and output components such as a display device, a speaker, and or a printer port. Other I/O components <NUM> can be used as well.

Memory <NUM> stores operating system <NUM>, network settings <NUM>, applications <NUM>, application configuration settings <NUM>, data store <NUM>, communication drivers <NUM>, and communication configuration settings <NUM>. Memory <NUM> can include all types of tangible volatile and non-volatile computer-readable memory devices. It can also include computer storage media (described below). Memory <NUM> stores computer readable instructions that, when executed by processor <NUM>, cause the processor to perform computer-implemented steps or functions according to the instructions. Similarly, device <NUM> can have a client system <NUM> which can run various business applications or embody parts or all of client systems <NUM>, <NUM>, <NUM>. Processor <NUM> can be activated by other components to facilitate their functionality as well.

Examples of the network settings <NUM> include things such as proxy information, Internet connection information, and mappings. Application configuration settings <NUM> include settings that tailor the application for a specific enterprise or user. Communication configuration settings <NUM> provide parameters for communicating with other computers and include items such as GPRS parameters, SMS parameters, connection user names and passwords.

Applications <NUM> can be applications that have previously been stored on the device <NUM> or applications that are installed during use, although these can be part of operating system <NUM>, or hosted external to device <NUM>, as well.

<FIG> shows one embodiment in which device <NUM> is a tablet computer <NUM>. In <FIG>, computer <NUM> is shown with user interface display screen <NUM>. Screen <NUM> can be a touch screen (so touch gestures from a user's finger can be used to interact with the application) or a pen-enabled interface that receives inputs from a pen or stylus. It can also use an on-screen virtual keyboard. Of course, it might also be attached to a keyboard or other user input device through a suitable attachment mechanism, such as a wireless link or USB port, for instance. Computer <NUM> can also illustratively receive voice inputs as well.

<FIG> is one example of a computing environment in which architecture <NUM> and/or <NUM>, or parts of them, (for example) can be deployed. With reference to <FIG>, an example system for implementing some embodiments includes a general-purpose computing device in the form of a computer <NUM>. Components of computer <NUM> may include, but are not limited to, a processing unit <NUM> (which can comprise processors or servers from previous Figures), a system memory <NUM>, and a system bus <NUM> that couples various system components including the system memory to the processing unit <NUM>. The system bus <NUM> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. Memory and programs described with respect to <FIG> and/or <NUM> can be deployed in corresponding portions of <FIG>.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

By way of example only, <FIG> illustrates a hard disk drive <NUM> that reads from or writes to non-removable, nonvolatile magnetic media, and an optical disk drive <NUM> that reads from or writes to a removable, nonvolatile optical disk <NUM> such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.

Operating system <NUM>, application programs <NUM>, other program modules <NUM>, and program data <NUM> are given different numbers here to illustrate that, at a minimum, they are different copies.

These and other input devices are often connected to the processing unit <NUM> through a user input interface <NUM> that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).

The computer <NUM> is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer <NUM>. The remote computer <NUM> may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer <NUM>. The logical connections depicted in <FIG> include a local area network (LAN) <NUM> and a wide area network (WAN) <NUM>, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

The modem <NUM>, which may be internal or external, may be connected to the system bus <NUM> via the user input interface <NUM>, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer <NUM>, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, <FIG> illustrates remote application programs <NUM> as residing on remote computer <NUM>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

It should also be noted that the different embodiments described herein can be combined in different ways. That is, parts of one or more embodiments can be combined with parts of one or more other embodiments. All of this is contemplated herein.

Claim 1:
A computing system, comprising:
electronic mail, email, functionality (<NUM>) on an email service (<NUM>) configured to receive an indication that a user is generating, on a first client device, a second email message comprising a response to a first email message in a mailbox for the user, the first email message including a first content portion and a second content portion;
a smart reply system (<NUM>) configured to:
truncate the first email message, to obtain a truncated email message that includes the first content portion and omits the second content portion, and
send, from the email service to the first client device, the truncated email message for generation of a draft of the second email message on the first client device; and
a draft roaming system (<NUM>) configured to:
receive, from the first client device, an indication of a unique portion entered in the draft of the second email message by the user on the first client device, and
save the draft of the second email message, including the unique portion, on the email service for access by the user from a second client device,
wherein the smart reply system (<NUM>) is configured to:
in response to detection of the user accessing the draft of the second email message from the second client device, and before the second email message is sent to a recipient, send the truncated message and the unique portion to the second client device.