System and method for communication between server and customer using electronic mail messages

System and method for improved client server communication regarding e-mail messages

References to related applications This application benefits from a U.S. application entitled "System and Method for Improved Client-Server Communication" filed on January 3, 2003 (No. 60/437,869, Agent Tag No. 220635), the U.S. The application is included here for reference.

Technical field

The present invention relates generally to computer networks, and more specifically, to methods for communicating between client applications and server applications (e.g., email applications).

Background technique

E-mail has become an important method of communication. E-mail systems usually include server components (for example, Microsoft Exchange Server) and client components (for example, Microsoft Outlook or Microsoft Outlook Express). These components are usually software applications that are configured to execute on computing devices (eg, servers, PCs, portable computers, and PDAs).

To facilitate communication, clients and servers (for example, the client component and server component of an email system) often agree on a communication protocol. The protocol proposes rules that define the expected behavior of each party during the communication, such as the expected order of requests and responses. A mature and complete agreement has rules for dealing with unexpected behavior.

With the improvement of client components and server components, an improved version is distributed to end users. In order to take advantage of new component features and network features, new communication protocols are often invented. In cases where the basis of installed server components is important, the client component may be able to communicate with the selected server component of the previous version via a set of protocols.

Sometimes later agreements build on earlier agreements instead of replacing them all. In this case, the later protocol may consist of protocol elements that can be enabled or disabled in order to simulate the earlier protocol. Likewise, where the basis of installed client components is important, the server component may be able to communicate with the selected client component of the previous version via a certain protocol.

The present invention provides such a system and method. Through the description of the invention provided herein, these and other advantages and additional inventive features of the invention will be clear at a glance.

Summary of the invention

The present invention provides a system and method for improved client-server communication. More specifically, the present invention is directed to an improved protocol that can be used for communication between a client and a server. The present invention has a special relationship with the email server environment, but the various features described here can be used in other client networks and server networks.

According to one aspect of the present invention, the email client component can indicate to the email server component that it is interested in receiving the best message body possessed by the email message. The email server component can receive a message request indicating that the best message body of the email is needed. The e-mail server component can access the data register associated with the e-mail server component, determine the best message body of the message that does not depend on converting the format of the available message body, and retrieve and return the best message body without requiring Convert the format of the best message body. In this way, the processing time at the email server component is reduced because no conversion of the email body occurs at the email server component.

According to another aspect of the present invention, upon a transmission request for a certain or a certain set of special attributes (for example, headers), if this or these attributes are not clearly defined in the entire data object, the email server component can transmit the Data object. The email client component generates a request for the data objects in the folder, the request including an indication that at least one attribute of these data objects is required. The email server component receives the request and accesses the folder and the data objects in the folder. Regarding each data object in the folder, if the at least one attribute is clearly defined in the data object, the email server component retrieves the at least one attribute of that data object and returns it to the email client component. If the at least one attribute is not clearly defined for the data object, the email server component retrieves the data object and returns it to the email client component.

According to another aspect of the present invention, the e-mail client component may force the e-mail server component to provide e-mail messages using Unicode. The e-mail client component sends a request for at least one e-mail message and an instruction indicating that the e-mail client component expects the e-mail message to adopt a uniform character encoding format. The e-mail server component retrieves the at least one message in response to the request and the receipt of the instruction; and, for each e-mail message, if the e-mail message can adopt the uniform character encoding format, the e-mail server component uses the uniform character encoding format. The encoding format is provided to the email client component. If the e-mail message does not adopt the uniform character encoding format, the e-mail server component converts the e-mail message into the uniform character encoding format, and provides the uniform character encoding format to the e-mail client component.

According to another aspect of the present invention, the request sent by the email client component may not indicate the size limit of the response to the request, thereby allowing the email server component to fill the buffer if necessary. The email client component sends multiple subrequests in the request, each of which requires an operation at the email server component and includes size information. In response to each sub-request, if the size information includes a size limit within the expected range of the email server component, then the email server component limits the response to the size limit. If the size information includes a size limit outside the expected range of the email server component, then the email server component looks for a new size limit in the size information. This new size limit may be arbitrary (for example, "fill available buffer").

Description of the drawings

Figure 1 is a schematic diagram of computers connected by a network.

Figure 2 is a schematic diagram showing an exemplary computer system used to implement an embodiment of the present invention.

Figure 3 is a schematic diagram depicting an environment with multiple versions of email client components and email server components.

Figure 4 is a protocol diagram showing an example of the protocol negotiation procedure between the email client component and the email server component.

FIG. 5 is a schematic diagram showing an example email network in which the email client component and the email server component have communication buffers of fixed size.

Figure 6A is a protocol diagram showing an example protocol that requires two request-response cycles to complete a fast transfer operation.

Figure 6B is a protocol diagram showing an example protocol that requires a single request-response cycle to complete a fast transfer operation.

Figure 7A is a flowchart depicting an example program for sending the body of an email message to the email client component.

Figure 7B is a flowchart depicting a procedure for sending an email message body to an email client component according to an aspect of the present invention.

Fig. 8A is a program table showing the complete project transfer mode.

Fig. 8B is a program table showing the head first transfer mode.

Fig. 8C is a program table showing the unique transfer mode of the header.

FIG. 8D is a program table showing the exception of the header first transfer mode or the header only transfer mode.

Figure 9 is a schematic diagram showing the home email server component of the email client component that is changing over time.

FIG. 10 is a protocol diagram showing an exemplary protocol for synchronizing various email folders between the email client component and the email server component.

FIG. 11A is a flowchart depicting an example program for optimizing a part of a state blob.

Fig. 11B is a flowchart depicting a procedure for optimizing a part of a state point according to the present invention.

Figure 12 is a schematic diagram showing the hierarchy of email folders.

Figure 13 is a protocol diagram showing an exemplary protocol for synchronizing and maintaining the storage of email messages in accordance with one aspect of the present invention.

Figure 14A is a protocol diagram showing an example protocol for conveying error messages at the ROP level.

Fig. 14B is a protocol chart showing an exemplary protocol for conveying error information on a per-message basis according to an aspect of the present invention.

Figure 15A is a flowchart depicting the procedure used to generate error messages at the ROP level.

Fig. 15B is a flowchart depicting a procedure for generating error information on a per-message basis according to an aspect of the present invention.

Figure 16A is a protocol diagram showing an example protocol for performing fast transfer operations.

FIG. 16B is a protocol chart showing an exemplary protocol for providing progress information while performing a fast transfer operation according to an aspect of the present invention.

Figure 17A is a flowchart depicting the procedure for streaming a set of messages.

Figure 17B is a flowchart depicting a procedure for streaming a set of messages along with progress information according to one aspect of the present invention.

Fig. 18 is a schematic diagram of multiple e-mail client components, which are being notified due to the change of the same data object at the e-mail server component.

Figure 19A is a flowchart depicting a procedure for notifying multiple subscribers.

Figure 19B is a flowchart depicting a procedure for notifying multiple subscribers according to an aspect of the present invention.

Fig. 20 is a flowchart depicting a procedure for providing an e-mail message using a required code page according to an aspect of the present invention.

detailed description

Before continuing to describe the various embodiments of the present invention, a description will now be made of computers and networking environments in which various embodiments of the present invention can be practiced. Although not required, the present invention can be implemented by a program executed by a computer. Generally, programs include routines, objects, components, data structures, and the like that perform special tasks or implement special abstract data types. The term "program" as used herein can mean a single program module or multiple program modules acting in concert. The term "computer" as used herein includes any device that electronically executes one or more programs (for example, personal computers (PCs), handheld devices, multi-processor systems, microprocessor-based programmable consumer electronic devices) , Network PCs, small computers, tablet PCs, large computers, consumer appliances with microprocessors or microcontrollers, routers, gateways, network hubs and the like). The present invention can also be used in distributed computing environments in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, programs can be located in local memory storage devices and remote memory storage devices.

Now, an example of a networking environment in which the present invention can be used will be described with reference to FIG. 1. This example network includes several computers 10 communicating with each other on a network 11 (represented by the cloud). The network 11 may include many well-known components (for example, routers, gateways, network hubs, etc.), and allow the computer 10 to communicate via wired and/or wireless media. When interacting with each other on the network 11, one or more of these computers can act as clients, servers, or equivalent devices related to other computers. Correspondingly, even if the specific examples contained herein do not mention all these types of computers, the various embodiments of the present invention can also be practiced on clients, servers, equivalent devices, or combinations thereof.

Referring to FIG. 2, an example of the basic configuration of a computer is shown, and all or part of the present invention described herein can be executed on the computer. In its most basic configuration, the computer 10 usually includes at least one processing unit 14 and a memory 16. According to various embodiments of the present invention, the processing unit 14 executes instructions to complete tasks. In the process of performing such tasks, the processing unit 14 may transmit electronic signals to other parts of the computer 10 and transmit the electronic signals to devices other than the computer 10 to produce a certain result. Depending on the exact configuration and type of computer 10, memory 16 may be volatile (e.g., RAM), non-volatile (e.g., ROM or flash memory), or some combination of the two. The dashed line 18 in Figure 2 shows this most basic configuration. In addition, the computer may also have additional features/functionality. For example, the computer 10 may also include additional storage (removable 201 and non-removable 202), and the additional storage includes (but is not limited to) magnetic disks or optical disks or tapes. Computer storage media include volatile and non-volatile removable and non-removable media that are executed by any method or technology for storage of information (including computer-executable instructions, data structures, program modules, or other data). Computer storage media include (but are not limited to) RAM, ROM, EEPROM flash memory, CD-ROM, digital versatile disk (DVD) or other optical storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or Any other medium that is used to store required information and can be accessed by the computer 10. Any such computer storage medium can become a part of the computer 10.

The computer 10 preferably also includes a communication connection 205 that allows the device to communicate with other devices. A communication connection is an example of a communication medium. Communication media usually embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal (for example, a carrier wave or other transmission mechanism), and include any information delivery media. For example (without limitation), the term "communication medium" includes wired media (for example, a wired network or direct connection) and wireless media (for example, sound, RF, infrared, and other wireless media). The term "computer-readable medium" as used herein includes computer storage media and communication media.

The computer 10 may also have an input device 204 (for example, a keyboard, a mouse, a pen, a voice input device, a contact input device, etc.). An output device 203 (for example, a display 20, a speaker, a printer, etc.) may also be included. All these devices are well known in this technical field and need not be discussed in detail here.

The present invention is directed to an improved system and method for client-server communication, and more specifically, to an improved protocol that can be used for communication between client and server. The present invention has a special relationship with the email server environment, but the various features described here can be used in other client networks and server networks. However, for the convenience of description, the present invention can be described with reference to the client/server email environment.

The invention can be implemented in a client/server environment with two or more versions of client applications or components and/or two or more versions of server applications or components. To achieve this goal, Figure 3 shows a block diagram showing multiple versions of client and server components in the network email environment. Generally speaking, the client component and server component are configured so that they are backward compatible. In other words, the client component can communicate with the recent version and the traditional version of the server component, and vice versa. Establish a set of protocols to communicate between these multiple versions. This set of agreements can be composed of several different agreements, and each agreement is self-contained. Alternatively, a set of protocol components can be provided, and special components are used to configure special protocols in the protocol set.

In any case, in the network email environment shown in FIG. 3, the latest version email client component 303 uses the protocol 307 to optimally communicate with the latest version email server component 306. However, the latest email server component 306 can also use other protocols in the protocol set (for example, protocols 308 and 309 in FIG. 3) and selected previous version email client components (for example, email client component 302 and electronic The mail client part 301) communicates. The email client component 303 can also communicate with selected previous version email server components (e.g., email server component 305 and email server component 304) using protocols such as protocols 310 and 311.

Generally, as used herein, for the purpose of describing the protocol of the present invention, the "most recent" email (server or client) component or the latest version of the email (server or client) component is understood to be being described One or more new features of server or client components, and can utilize, execute, and/or act on those features. Although these terms are used throughout this document to describe client components and server components that understand various aspects of the protocol of the present invention, these terms also include components that only understand the specific aspects being described, or include understanding more than what is being described. Describe one aspect of the component. Likewise, the "previous" email component or the previous version of the email component is a component that is not understood and cannot be used in all aspects of the protocol of the present invention.

A protocol negotiation program is often used to establish an agreement between the client and the server (for example, the latest version email server component 306 and the latest version email client component 303). Although this type of agreement negotiation is known, for the benefit of the reader, the agreement negotiation procedure between the email client component 401 (FIG. 4) and the email server component 402 (also FIG. 4) is briefly described. As early as during the communication dialogue between the email client component 401 and the email server component 402, the email client component 401 sends a message 403 to the email server component 402. The message 403 includes, for example, the client in the form of a version feature of the client component. Version Information. The email server component 402 responds to the message 403 with a message 404, which includes, for example, server version information in the form of a server component version feature.

The client and server version information can be used in various ways to try to establish communication between the email client component 401 and the email server component 402. For example, the version information can be used to select an appropriate protocol for continued communication, or to determine whether further communication is possible. For example, in the process of establishing a protocol, version information can be used to enable and/or prohibit the use of special available protocol aspects or components.

The email server component can receive and process requests from multiple email client components in parallel. In the case of showing a single customer, unless expressly specified otherwise, only these drawings and accompanying explanations will be simplified.

The e-mail network of the present invention utilizes request and response exchanges to transfer queries and data between client components and server components in the network. In practice, the performance of the protocol can be achieved through the basic communication network transmission mechanism used to perform the communication between the client and the server in the e-mail network. For example, in an e-mail network that uses remote procedure calls (RPCs) as the basic communication network transmission mechanism, a larger number (for example, 32KB) is executed compared to a few remote procedure calls of a smaller number (for example, 2KB). ) A single remote procedure call may be much more efficient. A known method to improve the performance in such email networks is to buffer multiple requests and/or responses transmitted in a single remote procedure call.

For example, FIG. 5 shows the request and response exchanges between the email client component 501 and the email server component 502. Both the email client part 501 and the email server part 502 have fixed-size communication buffers 503, 504, 505, and 506. Storage areas are reserved for the buffers 503, 504, 505, and 506 for temporary storage of data. By filling the buffer 503 with one or more sub-requests or remote operations (ROPs) before transferring the contents of the buffer 503 to the buffer 504, the email client component 501 starts a request-response cycle.

After each ROP is received in the buffer 504, each ROP is processed in order by the email server component 502, and the corresponding result is written into the buffer 505. Each ROP produces some kind of result. The result may include the data requested by the email client component 501 (e.g., a special set of email messages). The email server component 502 monitors the buffer 505, and when it is almost full (for example, less than 8KB remaining), the email server component 502 writes any unprocessed ROPs to the end of the buffer 505 and sends The buffer 505 is transferred to the buffer 506. Then, by writing the unprocessed ROPs into the buffer 503 so as to resubmit to the email server part 502 when the buffer 503 is full again, the email client part 501 starts a new request-response cycle.

On average, the size of the response is usually larger than the size of the request. Therefore, the size of the response buffers 505 and 506 is generally configured to be larger than the size of the request buffers 503 and 504. In an embodiment of the present invention, since the size of the request buffers 503 and 504 is 32KB, the optimal size of the response buffer 505 has been determined to be 96KB, and the ratio is 3:1. In one embodiment, the email client component can configure the size of any of the buffers 503, 504, 505, and 506.

Some e-mail networks that utilize buffers (for example, the e-mail network shown in FIG. 5) can use a fast transfer mode between the e-mail client component and the e-mail server component. The fast delivery mode includes client requests (for example, ROPs), which are divided into at least two categories: requests that cause the initialization of the fast delivery data source at the server, and those that cause the data to be efficiently delivered from the fast delivery data source Requests to customers. For example, the source of the fast transfer data may be a database table. The fast transfer data source is used as a ready-made data register, which enables future requests for the data to be serviced with less delay. Sometimes, the second fast transfer mode request seeks to achieve efficient data transfer by clearly specifying the size of the response (for example, the size of the response can be set to the size of the entire client receiving buffer minus the response management fee).

Figure 6A shows a fast transfer operation with at least two request-response cycles. In the first request 601, the ROP (for example, FXPrepare) initializes the fast delivery data source on the server 502. At the server, only FXPrepare is processed (that is, the fast delivery data source is initialized), and the result is returned in the first response 602. In the second request 603, the ROP (for example, FXGetBuffer) asks the server to fill the buffer 505 from the fast data source. The server empties the fast data source, puts all into the buffer, and returns the result in the second response 604. If the output buffer 505 of the email server component is full before emptying the fast data source, then additional FXGetBuffer ROPs can be requested.

Figure 6B shows a fast transfer operation with only a single request-response cycle. In the first request 605, FXPrepare and FXGetBuffer are processed by the email server component 502, and the results of the two operations are returned in the first response 606. The FXGetBuffer at the email server component 502 has the result of FXPrepare because a part of each buffer 503, 504, 505, and 506 is clearly defined as a shared data table. There is a need to reduce the number of request-response cycles because this allows data to be transferred more efficiently. When the buffer 505 is too full to hold the result of FXGetBufferROP, a fast transfer operation with more than a single request-response cycle may occur.

It will be understood that the ROPs in FIGS. 6A and 6B and similar drawings throughout this application are schematic, which is embodied in that unless otherwise specified, they can actually be performed by a series of ROPs.

Generally, the size of the ROP result is different from the size of the ROP request. It is not always possible to predict the size of the ROP result. When data compression techniques are used to reduce the size of the ROP result, it is even more difficult to predict the size of the ROP result. If the size of the ROP result cannot be predicted, manual adjustments to the protocol can be prevented in order to minimize the number of request-response cycles required to complete a specific customer operation, thereby (for example) ensuring that all new messages are received within a single request-response cycle Download to customers. Manually adjusting the protocol includes: manually configuring the order and/or size of protocol requests, responses, and/or ROPs.

According to one aspect of the present invention, by specifying the size of key ROPs (for example, FXGetBuffer) without predicting the size of the result, the number of request-response cycles is automatically minimized. Instead, such ROPs are processed by the email server component 502 until the limit of the buffer 505 (the same as the buffer 506) is reached.

For example, in an environment that includes multiple versions of email server components, separate ROPs can be defined for the previous version server components and the new version server components. These recent versions do not need to predict the size of their results. The following table illustrates the characteristics of these ROPs:

The ROPs of the server components of the previous version are similar in structure to the existing ROPs of the original technology. That is, these ROPs predict and specify the size in the output buffer (e.g., transmit buffer 505) that must be reserved to save the response. In contrast, the prescribed size of the output buffer of the latest version of the server component is not predicted, but the prescribed size is set to a value exceeding the maximum value expected by the server component of the previous version, for example, the prescribed size is set to Value greater than 32KB. The fact that the size of the output buffer is defined to exceed the value expected by the server component signals the server component to look for a new size limit parameter, for example, the size limit parameter may be the filling of the server component's output buffer. These features automatically minimize the number of request-response cycles, but the complexity of the email server component that handles these ROPs is slightly increased.

Note that unless there is a clear provision to the contrary, the order of the parameters shown in the above table and similar tables throughout this application may not necessarily follow (for example) these parameters are transmitted by the email client component or the email server component on the network Or the order stored in the memory is related to each other. In addition, for the sake of clarity, unchanged parameters may be omitted.

In an email network, one of the typical responsibilities of the protocol is to realize the transfer of data objects (for example, email messages) between the email client component and the email server component. Other examples of such data objects include: email folders, which can contain email messages and other data objects; and folder association information (FAI) data objects, which, for example, can contain rules regarding the processing of email messages , Or define how the data objects contained in the folder will be displayed. The data object may be difficult to understand for the e-mail client component, that is, the e-mail client component may not be able to interpret the content of the data object. Alternatively, the data object may consist of named attributes. For example, an email message may include names named "to", "from", "subject", "importance", "subject 1", "subject 2", "subject" 3", "Attachment 1", "Attachment 2" and other attributes.

The e-mail network has an advantage: when the data object is difficult to understand, the data object may consist of named attributes on the e-mail network. With this advantage, it is possible to improve the performance of the protocol because the protocol can only transmit a part of the data object. With named attributes, it is possible to transfer specific attributes of the data object without transferring the entire data object.

For example, an email message may consist of a set of header attributes and a set of body attributes. The requirements of the email client component may cause the protocol to transmit the header attributes first and then the body attributes, or not to transmit the body attributes at all. This feature allows the user to view the header information of several messages before all the messages are downloaded as a whole. By using this feature, client components can obtain more detailed control over bandwidth utilization, which will certainly achieve protocol performance. In addition, the client component can use this feature to generate lower bandwidth utilization (for example, it can download the body only for the selected head), which is particularly desirable in a low-bandwidth environment.

If the server component is configured to send body attributes and header attributes in two separate request-response cycles (ie, one for the header and the other for the body), the performance of the protocol may not necessarily improve. For example, if the requirements of an email client component made it require both header attributes and body attributes at the same time, the situation that both the header and the body can be retrieved according to a single request-response cycle may reduce the performance of the protocol. In this way, the simple act of allowing data objects to be composed of named attributes is not by itself sufficient to automatically improve protocol performance. Achieving improved protocol performance depends on the choice of attributes that can constitute the data object and how the protocol can use these attributes. That choice may depend on many factors, including the requirements of the latest and previous versions of email client components and the requirements of the latest and previous versions of email server components. Examples of e-mail client components include: satisfying different levels of urgency regarding the display of different information, and complying with the parameter selection set by the user of the e-mail client component. Examples of email server components include: efficiently storing and retrieving data, and efficiently processing protocol requests.

The conventional prior art email environment utilizes data objects that may be composed of named attributes (for example, an email message; the email message may include a header set and a subject set of the named attribute, so that the two can be requested and/or processed separately. Sets). Another example of the original technology is an email message, where the subject set of the named attribute includes (for example) using multiple email message formats (for example, plain text, hypertext markup language (HTML), rich-text format) (RTF), etc.) multiple versions of the body of the email message. In this case, the original email server component can respond to the protocol request regarding the body of the email message in many ways. The least complex request may send all versions of the email message body, but this response may result in increased bandwidth utilization.

Figure 7A depicts a part of a program that the previous (previous technology) version of the email server component uses to respond in this situation. In step 701, the email server component checks the format of each email message body. If one of these formats is a predetermined standard format (for example, RTF), the procedure proceeds to step 703, and the standard format email message body is sent to the requesting email client component. If none of these formats is a predetermined standard format, then step 701 branches to step 702, where one of the email message body versions is converted into the standard format. If there is only a single version of the email message body, but the email message body may not adopt the standard format required by the protocol, then the subprocedure depicted in FIG. 7A can also be used.

Figure 7B depicts a part of the program used by the latest version of the email server component according to the present invention. In step 704, a check protocol request is marked for BEST_BODY, which will cause the email server component to use this sub-process. The tag in this example and the other tags used here are used for the email server component; the email client component is the most recent version and wants to perform the function associated with the tag. Other instructions can be used. For example, if the most recent email client component is detected, this function can be executed by default.

In any case, if the BEST BODY tag is not found, then step 704 branches to step 701, and continues as described with reference to FIG. 7A.

If the tag is found, the program proceeds to step 705, where the best email message body for sending to the requesting email client component is selected. It is best if there is only a single email message body associated with the requested email message. If there are (for example) several email message bodies in different formats, then the email server component selects from them according to a predetermined arrangement of (for example) email message body formats (for example, RTF, HTML, plain text) The best email message body. Then, the procedure proceeds to step 703, where the selected email message body is sent to the email client component. In this embodiment, the email client component may be able to display multiple email message body formats, so that the email server component does not need to convert the email message body into a standard format. In addition, if needed, the email client component can convert the best email message body into different formats.

Since the email server component does not need to perform the task of converting the body of the email message, the present invention provides improved performance. In addition, the latest version of the email server component can respond to the protocol request from the previous version of the email client component, but the complexity is moderately increased.

You can use ROPs to replicate the email folders between the email server component and the email client component. For example, SynchroFolder ROP can make a request to synchronize folders. In the case that the email client component can display non-standard email message body format, it can set the BEST_BODY flag in the SynchroFolder ROP to indicate that the email server component can choose the best format from various available email message bodies , Instead of requiring the server to return the body of the email message in a standard format. With and without the BEST_BODY tag, the email server component can handle ROPs appropriately, but with a moderate increase in complexity. The ROPs used to communicate with the previous version server and the latest version server can include (for example) the characteristics stated in the following table:

Figures 8A-8C show several different existing modes of transmitting a set of e-mail messages between the e-mail server component and the e-mail client component. Regarding each mode, each e-mail message has a named attribute including a header set and a subject set, and several e-mail messages are contained in a folder. Figure 8A shows the full project transfer mode. The illustration shows the first email message header 801 being transmitted, followed by the first email message body 802 before the second email message header 803, and then the second email message body 804 waits until the group of e-mail messages is transmitted. Figure 8B shows the head first transfer mode. In this mode, the first e-mail message header 805 is transmitted first, then the second e-mail message header 806, etc., until all e-mail message headers are transmitted; the first one is not transmitted until then The email message body 807, then the second email message body 808, etc., until the group of email messages is transmitted. Figure 8C shows the unique transmission mode of the head. As the name implies, in response to a request to transmit a group of e-mail messages, only the e-mail message header 809 is transmitted. In response to an additional explicit request, only the email message body 810 will be transmitted. In any of these modes, the transmission sequence may be temporarily interrupted by, for example, a higher priority email client component request regarding the body of a particular email message.

An email folder is an example of the target of a request to transmit a group of email messages. However, email folders can contain data objects other than email messages. As described above, the transmission mode is often defined with reference to the email message header and the email message body (for example, the header first transmission mode and the header only transmission mode). In this type of transfer mode, if an attempt is made to transfer a data object for which the header set and/or the subject set of the named attribute may not be clearly defined, the protocol may fail. By stipulating that the data object can always be transmitted in whole rather than in part (the header and/or body set for which the named attribute is not clearly defined), one aspect of the present invention avoids this situation. Figure 8D can illustrate this embodiment as an example. In this example, the transmission between the e-mail server component and the e-mail client component may adopt a header-only mode. Accordingly, the first email message header 811 is transmitted, and then the data object 812 becomes the next candidate for transmission. The header set of named attributes is not clearly defined for the data object 812 (for example, FAI), so the entire data object is transmitted. The next candidate for transmission has a clearly defined header set of named attributes (that is, the candidate data object has all named attributes that are clearly defined by the email client component as belonging to the header set of named attributes), so only the electronic Email message header 813.

An example of a method of performing this aspect of the invention is by using flags (e.g., IGNORE_MODE_ON_FAI) that may be included in a synchronous ROP (e.g., the SynchroFolder ROP described above). With and without the IGNORE_MODE_ON_FAI flag, the email server component can handle ROPs appropriately, but the complexity is moderately increased. ROPs can include the features stated in the following table in order to realize the replication of email folders between the email server component and the email client component:

Email messages are usually presented to one or more email network users. If the email message is accepted by the email server component for storage, it may be considered that the email message has been delivered. An email network may have several email server components. Generally, email network protocols have a certain strategy to limit the number of email server components that users of the email network must check for new messages. A common example is the home server policy, which stipulates that e-mail messages presented to a specific e-mail network user will only be accepted by a specific e-mail server component (referred to as the "user's home server"). In this case, when (for example) regularly checking for new email messages or registering for notification of new email messages, the email client component can be configured to only consider the home server.

Figure 9 shows that even a simple example of a home server strategy can be complicated. In the example shown in FIG. 9, the specific email server component 901 is first designated as the home server of the specific email network user. Over time, usually due to management reasons, the user's designated home server is changed to different email server components 903 and 905. For example, the email server components 901, 903, and 905 may be physically or logically different, or different versions. The email client part 902 may only communicate with the email server part 901 from time T0 to time T1. Subsequently, the email client part 904 may only communicate with the email server part 903 before time T2, and then the email client The component 906 may only communicate with the email server component 905. The email client components 902, 904, and 906 may be the same or different. After time T2, the email server components 901 and 903 may or may not exist. These complicating factors have a special relationship with the e-mail message memory duplication discussed next.

E-mail messages can be stored in a clear e-mail message storage by the e-mail server component, for example, the e-mail message storage can be implemented using well-known database technology. The email server component may have one or more such message storages. Email network users may have home message storage. If the home message storage is changed, it may have the same effect as changing the description of the home server.

Some e-mail network protocols include the ability to copy portions of the e-mail message storage to a storage device local to the e-mail client component. By copying some parts of the remote e-mail message storage to the local e-mail storage device, the protocol performance and/or the perceived protocol performance can be improved. For example, this can be used when a clear e-mail network user requests to watch all new e-mails. Copy these e-mail messages to the local e-mail storage device before e-mail messages. This duplication may also provide additional email client component functionality, for example, may allow email network users to view email messages during periods of network connectivity interruption.

In the e-mail network environment, simple copying can quickly become very inefficient. For example, if the e-mail server component has an e-mail message associated with a particular e-mail network user, that message has been copied at the customer component of that e-mail network user and is new to that e-mail network user If the email message arrives, it is still required to send two email messages in response to a simple copy request. If another new e-mail message arrives after these two e-mail messages are copied, then it is still required that three e-mail messages must now be sent in response to a simple copy request, etc. Some e-mail network protocols have provided for incremental replication of e-mail message storage to alleviate this problem. In incremental replication, only email message memory changes that occurred after the previous successful incremental replication must be sent in response to the replication request, for example, where the only changes since the last successful incremental replication are new The arrival of the e-mail message, therefore, it is only necessary to send this new e-mail message in response to the incremental copy request.

Figure 10 shows a more detailed example of a protocol that specifies incremental replication. The e-mail message storage can be subdivided into individual e-mail folders. Each e-mail folder can be copied independently of other e-mail folders, which provides for more detailed control over the copying process. In this example, the incremental replication process is called "synchronization" because it includes the propagation of changes from the email client component 501 to the email server component 502 and from the email server component 502 to the email client component 501. After the synchronization request 1001, the email server component 502 handles the SynchroFolder ROP. The ROP includes a folder ID parameter (not shown) and a status point 0 parameter. The folder ID parameter identifies the email folder that is the target of the synchronization request 1001. The status point 0 parameter contains information that allows the email server component 502 to determine what has changed (if any) since the email folder was last synchronized. If the request 1001 represents the first synchronization request for the target folder made by the email client component 501, then the email server component 502 determines whether the target email folder in the email message storage has occurred in comparison with the empty folder Variety. In response 1002 to the request 1001, the email server component 502 sends any changes to the email client component 501, including any email messages and/or other data objects that have been added to the target folder as well as those that have been removed from the target folder. A list of any email messages and/or other data objects that were deleted. The email server component 502 also creates a new status point 1 representing the status of the target folder, because it will be on the email client component 501 immediately after synchronization; and the email server component 502 will also be sent in the response 1002 Status point 1. When the email client component 501 sends the next synchronization request 1003 for the same folder as the request 1001, the request 1003 will include the same status point 1 that was returned with the response 1002 as a parameter. As mentioned earlier, the email server component 502 will use the information contained in status point 1 to determine what changes (if any) have occurred in the target folder, and in response 1004, compare those changes with the newly created The status point 2 is sent back to the email client component 501 together.

If the size of the status point data object is large, it may adversely affect the performance of the protocol because it uses (for example) each email folder synchronization request to be sent to and from the email server component. In some e-mail network protocols that specify e-mail folder synchronization, the status point may be partly composed of a set of message change ID data objects that identify the status of the e-mail message that has been learned by the e-mail client component. Variety. When the changed e-mail message is transmitted to the e-mail client and/or server component, it can be said that the e-mail message change has been learned by that component.

One goal of the message change ID data object may be: to uniquely identify changes in email messages in the context of the entire email network. In an e-mail network that adopts a home server strategy, the user's home server may be responsible for associating the message change ID data object with previously unseen e-mail message changes. For example, a home server can use a message change ID data object including a server ID data object and a serial number. The server ID data object can use a well-known technology (for example, a globally unique identifier) to uniquely identify the email server component in the context of the entire email network. In the case where the size of the identifier itself is large, the server ID data object can be compiled into the identifier lookup table held by the email server component. The sequence number can be provided by, for example, a 6-byte wide counter local to the email server component; as long as the email server component accepts previously unseen email messages for storage, the sequence number can be incremented.

For discussion purposes, the message change ID data object can be represented by, for example, "S1:1", where "S1" represents the server ID data object of the first email server component, and "1" represents the serial number. For example, a group of message change ID data objects can be represented by "S1:1, S1:2, S1:3", where "S1:1", "S1:2", and "S1:3" have server IDs. The continuous message change ID data object used by the email server component of S1.

In the case where the status point is partly composed of a set of message change ID data objects ("message changes seen" set) representing the changes in the email message seen by the email client component, some techniques for encoding this set have been developed , To reduce its size, for example, the set "S1:1, S1:2, S1:3, S1:4" can be coded as "S1:1-4". In addition, the email server component can ensure that the serial numbers it uses are always increasing. In that case, the non-contiguous set of "seen message changes" (for example) "S1:1, S1:3, S1:5, S1:7" can be coded as "S1:1-7", that is, As a range including the smallest serial number and the largest serial number, without loss of functionality.

In the situation depicted in FIG. 9, the "message changes seen" set may include message change ID data objects that have been created by email server components (e.g., S1, S2) other than the current home server (e.g., S3). The message change ID data object created by the current home server can be called "local message change ID", and the message change ID data object created by other email server components can be called "foreign message change ID". It has not yet provided an email network protocol for communicating with the previous version of the email server component, which is used to optimize the non-contiguous foreign message change ID sequence to include the smallest sequence number and the largest sequence number on the basis of each email server component. range. The following table shows the benefits of including this optimization in an embodiment of the present invention:

One embodiment of the present invention uses ROPs that include the features stated in the following table in order to achieve synchronization of email folders between the email server component and the email client component. E-mail server components can implement improved state point coding technology, but the complexity is moderately increased.

Figures 11A and 11B depict the difference between the sub-processes that can be used by the previous version server and the latest version server, respectively, in response to the SynchroFoler ROP. Figure 11A shows steps 1101, 1102, and 1103. In step 1101, the initial set of "changes in messages seen" is compiled. In step 1102, the components of the "message changes seen" set belonging to the local message change ID data object are optimized. In step 1103, the optimized set of "message changes seen" is added to the state point data object, and the state point data object can be sent to the email client component that requested synchronization by using the response. Figure 11B includes an additional step 1104, which represents a component of the "seen message changes" set belonging to the external message change ID data object. Now the improved optimization is used to add the "seen message changes" set to the state in step 1103 Point data objects. Prior to this, these external message change ID data objects are also being optimized.

By subdividing the e-mail message memory into individual e-mail folders, more detailed control of the synchronization process is specified, but this does not automatically provide for improved protocol performance, and may lead to protocol performance degradation. For example, some protocols require separate synchronization of each message storage folder. Each synchronization operation usually has some kind of management cost, which can be a lot. Synchronous operations using state point data objects are an example of operations that may have significant management costs. In the case of synchronizing the entire message memory, a protocol that requires separate synchronization of each message memory folder may be at a disadvantage compared to a protocol that requires less synchronization operations.

For the e-mail client component, it is a desirable goal to synchronize and maintain the entire message memory. Conventional, prior-art email client components have been seeking to achieve this goal, even when it causes a significant adverse impact on the performance of the protocol. One aspect of the present invention is that it can minimize the adverse protocol impact, and at the same time, achieve this goal by using in-depth hierarchical tables. Conventional original technology email server components have been unable to provide in-depth hierarchical tables.

In the case of subdividing the e-mail message storage into individual e-mail folders, those e-mail folders can be organized into various hierarchies. Figure 12 shows an example of the e-mail folder hierarchy. In FIG. 12, the folder 1204 is a subfolder of the folder 1203. The folder 1203 is again a subfolder of the folder 1202. The folder 1201 is the root folder. The root folder is not a subfolder of any other folder. All other folders are part of the folder hierarchy rooted at folder 1201. Generally, every folder in the folder hierarchy cannot directly reference every other folder. A folder may only have direct references to its subfolders. A folder may also directly refer to any folder that is itself a subfolder. In many cases, the only folder that each folder can directly reference may be the root folder of the hierarchy.

The drill-down table may contain information about each folder in the folder hierarchy. Each folder can have a row in this deep level table. The information in the in-depth hierarchy table is such that it can be used to determine whether the content of the email folder has changed within a certain period of time. The changes in the e-mail folder during the period can be determined by simply comparing the copy of the row of the folder used at the beginning of a certain period with the copy of the row of the folder used at the end of the period. In one embodiment, each row of the deep-level table includes the following attributes:

As long as you change the contents of the folder, you can update the attributes of the row of the email folder in the in-depth hierarchy table. In order to perform the update of the deep-level table efficiently, applicants have found that this helps to quickly and directly reference the deep-level table. Applicants have at least discovered that when trying to access this in-depth level table, there should be very few predictable levels of indirection. For example, if the deep-level table is placed at any level in the folder hierarchy, a predictable number of indirect levels will not be specified. In an embodiment of the present invention, for this reason, the in-depth hierarchy table may be associated with the root folder of the e-mail message storage folder hierarchy of the e-mail network user.

The communication between the email client component and the email server component can be divided into communication sessions. For example, during an interruption of network connectivity, a loss of memory synchronization of email messages may occur between sessions. In order to re-establish email message storage synchronization at the beginning of the communication session, some protocols used to communicate with the previous version of the email server component used SynchroFolder ROP for each folder in the folder hierarchy. Generally, the contents of some of these folders will not have changed between sessions. A SynchroFolder ROP with an unchanged folder as its target results in a "null synch". Although the "zero sync signal" will not cause any folder changes to be transmitted to the email client component, it still has potentially significant administrative costs associated with it (for example, status point data objects).

FIG. 13 shows an embodiment of the present invention, which avoids such a "zero sync signal" result by using an in-depth hierarchy table. In the first request 1301, the email client component 501 sends the ROP (for example, GetHierarchyTable) requesting the in-depth hierarchy table to the email server component 502. In the first request 1302, a copy of the in-depth hierarchy table is provided to the email client component 501. Normally, the email client component 501 will have a previous copy of this deep level table. By using the line-by-line comparison of these two copies, the email client component 501 can determine which folders in the user's email message storage on the email server component 502 have changed. Next, use ROPs (for example, SynchroFolder) to synchronize only those folders that have changed. The request 1303 and the response 1304 can be repeated as necessary to synchronize the changed folders. After the synchronization is successful, the copy of the email client component of the deep-level table can be updated to match the most recent copy that was sent in response 1302. If the email client component 501 does not have a previous copy of the deep-level table, then all folders with a row in the most recent copy can be synchronized.

Once the synchronization of the user's e-mail message storage has been established, the synchronization can be maintained by periodically repeating the above-described session start step (ie, polling the e-mail server component), but this solution also has disadvantages. For example, the polling period may be much shorter than the period between changes in the user's email message storage. In that case, a relatively large number of comparisons in the in-depth table comparison will point out that no folder has changed. Such comparisons are actually futile, so agreements that avoid these comparisons may be more efficient.

Some e-mail networks include a device subscribed by the e-mail client component, and the e-mail server component notifies it when, for example, the content of a particular e-mail folder changes. By creating separate subscriptions for change notifications associated with each folder in the user's folder hierarchy, some previous version email client components use this device to keep the user's email message storage synchronized. In one embodiment of the present invention, the email client component may only create a single subscription for the change notification associated with the deep level table. A single subscription is more efficient, because it requires fewer ROPs to establish the single subscription, and consumes fewer server-side resources.

With further reference to FIG. 13, when the latest version email client component 501 uses GetHierarchyTable ROP in the first request 1301 at the beginning of the communication session with the email server component 502 according to an aspect of the present invention, the email client component is automatically subscribed 501 to change the notification associated with the in-depth level table returned in the response 1302. When the e-mail folder in the users e-mail message storage at the e-mail client component changes, for example, when an e-mail message is added to the folder, the deep level table is also updated as described previously . The change of the in-depth level table will trigger a notification alert 1305 to the email client component 501. The notification alert responds to the reservation issued by request 1301, but it is not part of the explicit request-response cycle. In this way, by using the notification system provided by the present invention, the management cost of the e-mail network can be greatly reduced.

A single booking may result in many notifications. In one embodiment, a connectionless network transmission mechanism (eg, "User Datagram Protocol"/"Internet Protocol" (UDP/IP)) is used to deliver the alert, but any suitable network transmission mechanism can also be used . In response to the alert, the email client component 501 sends a request 1306 containing a ROP (for example, GetNotification) to the email server component 502. In response 1307, any changed rows of the deep-level table (ie, rows corresponding to the changed folder that caused the notification) are sent to the email client component 501. Then, the email client component 501 uses ROPs (for example, SynchroFolder) to synchronize only the changed folders.

Multiple e-mail client components can be subscribed for change notifications associated with the same data object (e.g., the same e-mail folder) in order, for example, to provide collaboration functionality. As shown in FIG. 18, the subscription email client components 1801, 1802, and 1803 are notified for changes associated with the same data object (not shown) located on the email server component 1804. The email client component 1803 sends the ROP 1805 to the email server component 1804 that caused the data object to change. As a result of this change, the email server component 1804 sends change notifications 1806, 1807, and 1808 to the email client components 1801, 1802, and 1803. In addition to identifying data objects that have changed, the change notification can carry so little information that, for example, the email client component may not be able to determine whether it was the cause of a particular change. If the data object is, for example, an email folder, the change notifications 1806, 1807, and 1808 may cause each email client component 1801, 1802, and 1803 to initiate synchronization for the changed folder. Since the email client component 1803 was responsible for the change in this example, the result will be "zero sync signal".

For the reasons discussed above, it may be necessary to eliminate the synchronization that causes the "zero sync signal". However, the described notification behavior may not always be undesirable, and some email client components may rely on it. One aspect of the present invention is to specify that the email client component can configure the notification behavior of the latest version of the email server component, so as to improve the protocol performance, while providing the previous version of the email client component with unchanged notification behavior.

Figure 19A depicts the notification behavior that can be provided by the previous version of the email server component. Figure 19B depicts a configurable notification behavior according to an aspect of the present invention. If necessary, the latest e-mail client component can indicate to the e-mail server component: For example, by providing a request for the flag (IGNORE_OWN flag) in the example shown in FIG. 19B, it can perform the notification behavior in FIG. 19B.

In step 1901, the next candidate is selected from the group of subscribers to be notified. In step 1904, the subscription is verified for the IGNORE_OWN flag. If the tag does not exist, step 1904 branches to step 1902, where a notification is sent to the candidate subscriber. If the mark is found, step 1904 branches to step 1905, where the subscription is checked again to determine whether the subscriber has triggered this notification. For example, this determination can be made by checking the communication session identifier ("session ID") of the session that was used to issue the reservation. For example, the session ID may include a globally unique identifier and a 6-byte serial number. The notification is also checked for the session ID associated with its cause. If the two match, then the issuance of the notice is prohibited. The result: the email client component that caused the notification will also not receive that notification. Then, as described below, the sub-process proceeds to step 1903.

If the subscriber has not triggered a notification, the session ID associated with the subscription is different from the session ID associated with the cause of the notification, and step 1905 branches to step 1902, where the notification is sent. Then, the process proceeds to step 1903, where it is determined whether more subscribers will be notified. If more subscribers are to be notified, the sub-process returns to step 1901, otherwise, this sub-process ends.

As mentioned above, the e-mail client component that utilizes the cache of e-mail messages may, for example, via the ROP, request messages or messages between the local client data register and the available data register at the e-mail server component. Synchronization of other data objects. The email client component may also request that the message be copied from the server storage to the client storage. Either way, the fast transfer mode can be used to make the request.

Generally, when a message or other data (for example, a file) is required to be synchronized or copied, the request (for example, ROP) includes an indication of all messages that need to be synchronized. For example, by using the status point features described above, this list can be automatically compiled by the email server component. Regarding the previous version (original technology) of the email server component, if an error occurs in a message or data object in a ROP request, it will cause all items in the request to malfunction. This process is shown in FIG. 14A, in which a request containing a ROP (for example, FXPrepare) is transmitted in step 1401 using a message ID set designated for copying or synchronization. The fast delivery mechanism is set up at the email server part 502, and in step 1402, the fast delivery ID is transmitted to the email client part 501. Then, the email client component 501 requests the copy or synchronization of these data objects by including, for example, a request of FXGetBufferROP (step 1403). When the email server component 502 attempts to open the requested message, an error occurs in one or more of these messages or other data objects. Examples of errors include: the message or data object is destroyed; the server fails; the email server component 502 is forgotten; or, a virus is detected for the data object.

After this error occurs, the email server component 502 sends a fatal ROP error in the data flowing to the email client component 501 in step 1404. As such, the synchronization is not successful, the messages in the message ID set are not synchronized or copied, and the email client component 501 does not receive the status point or similar update information. Then, the email client component 501 must request that these data objects be synchronized or copied at another time. The situation may be that if the error is not corrected at the email server component 502, error messages may continue to be sent, and the messages in the message ID set may never be synchronized or copied.

According to one aspect of the present invention, the latest email server component may send error information about a specific data object (e.g., email message) instead of a fatal ROP error, so that only the synchronization of that data object will fail. Even if erroneous messages or other data objects are included in the response, this feature allows messages or other data objects in the ROP or other requests to be transmitted and synchronized or copied.

An example of how to handle specific object errors is: the most recent email server component can send error messages in the data stream for data objects with object errors. In this example, for ease of reference, the error is called "FXErrorInfo". If necessary, as described further below, FXErrorInfo may include information such as the message ID of the data object with the error, and additional information about why the message failed.

Fig. 14B shows a synchronization in which an error occurs in the message M3. This error results in an FXGetBuffer response 1405 including message M1, message M2 before FXErrorInfo, and message M4. The FXErrorInfo information allows the email client component 501 to know which message has an error, and allows the email client component 501 to synchronize all other messages in the response. If the error message FXErrorInfo includes information about the cause of the error, for example, by displaying the error message to the user, the client component can act on the information accordingly.

The following table shows an example of the format that FXErrorInfo can take:

It can be seen that this example format includes version attributes, error codes, and message IDs. In addition, one or more attributes can be added if necessary. In addition, as described above, auxiliary fields can be defined to convey error details. As such, attributes can be defined for specifying the field size of the error details (e.g., array), and a field can be provided, which may be, for example, an unorganized array used to convey the error details. As described above, the email client component 501 can handle these error details as needed.

The FXErrorInfo allows the synchronization of the first response to be completed, for example, resulting in status points or other information being provided to the email client component 501. Since the email client component is now synchronized through message M4, the next request 1406 for synchronization may result in a response 1407 with various messages after M4 (for example, M5 and M6).

In order to indicate that the e-mail client component 501 is the most recent version and can therefore process FXErrorInfo messages, a flag (for example, FXRecoverMode) can be defined, which can be transmitted using a ROP requesting synchronization or copying. Other instructions can be used for the email client component 501 to convey to the email server component 502 that it can process the FXErrorInfo message.

When the email server component 502 sends one or more messages or other data objects to the email client component 501, the data flow to the email client component can be separated or defined by attribute tags (e.g., ptags). For example, the message list may include a start message ptag and an end message ptag about each message. Between the start ptag and the end ptag may be an attribute list ptag and a theme ptag, and they may have string attributes. The subject ptag may be followed by the subject itself. Can include other attribute tags.

In the event that an error occurs during message transmission, FXErrorInfo can be provided as a ptag and can have binary attributes (for example, as defined in the above table). An example of the following data flow has a success message and a message in which an error occurred. In the case of this error, the end message ptag is not used for that particular message, and the ptag FXErrorInfo is the last ptag of that message.

<pre listing-type="program-listing"> ptagMessageListStart ptagMessageStart ptagPropList ptagSubj ect[PT_STRING] Re:Your email"... ptagMessageEnd ptagMessageStart ...... ptagFXErrorInfo[PT_BINARY] [Contents as described by table] ptagMessageStart ...... ptagMessageEnd ptagMessageListEnd</pre> FIG. 15A shows some steps, and the email server component 502 can use these steps to transmit the message to the previous version email client component 501. Starting from step 1501, the message set is prepared, for example, by placing the message set in the fast transfer data register. In step 1502, for example, after being put into the sending buffer of the email server component 502, the message starts to flow out immediately. If an error occurs when the message is flowed, then in step 1504, a fatal ROP error is flowed to the email client component 501. Then, the sub-process ends. If no error occurs when the message is streamed, then in step 1503, it is determined whether there are more messages in the message set. If so, the process returns to step 1502, where the next message is flowed out. If not, then the sub-process ends.

FIG. 15B shows a procedure for processing a message set regarding the latest version of the email server component 502. Depending on whether the e-mail client component is the latest version or the previous version, the steps taken are different. Steps 1501-1504 are the steps taken in the case of the email client component of the previous version, and these steps are equivalent to the steps with the same reference numbers in the previous paragraph.

If in step 1502, an error is found in the process of outgoing the message, then in step 1505, it is determined whether the request includes a flag (for example, FXRecoverMode). If the request contains the tag, then the email client component 501 is the latest version, and step 1505 branches to step 1506, where FXErrorInfo is flowed to the email client component 501. Then, the process can continue to step 1503. If the request does not include the tag, then step 1505 branches to step 1504, where a fatal ROP error is flowed out. Then, the sub-process ends.

It can be seen that if the tag exists in the request, the flow process can be allowed to continue by streaming FXErrorInfo (instead of discarding and sending a fatal ROP error). The mark is sent by the latest version of the email client part 501. Earlier versions of the email client component did not include this tag, so, as described above, the error would cause a fatal ROP error.

If desired, in alternative embodiments, an error message (e.g., FXErrorInfo) can be issued for a specific attribute of the message or other data object (rather than for the entire message). For example, FXErrorInfo can be issued for the body of the message, or for the attachment of the message. Then, the email client component 501 can synchronize or copy the attributes that are successfully sent without errors, and only the attributes with errors are not synchronized or copied.

Sometimes, the size of a message or other data object may be large enough to make it span multiple FXGetBuffer responses. In order to process this type of message, the email client component 501 may include reverse logic so that it can process any partially received message, and then continue to receive additional messages appropriately after receiving the error message.

Sometimes, it may be necessary to provide email client components with feedback on the progress of copying or synchronization of data objects (e.g., email messages). According to one aspect of the present invention, the latest version of the email client component 501 can indicate: for example, by sending a flag (for example, PROGRESS MODE) to the email server component 502 when requesting synchronization or copying of a data object, it can Processing progress mode. In response, the latest version of the email server component 502 can send various information and messages (for example, the total size of all these messages, the total number of messages and the total size of each message, or any one of these contents or The combination of these contents).

For example, as shown in FIG. 16A, regarding the previous version email client part 501, in response to a fast delivery request (1601 and 1603) regarding a group of messages, the email client part 501 receives these messages. In Figure 16A, the message is received in two responses 1604 and 1606. In the previous version of the email client component 501 that used the fast delivery mechanism, no progress indication of the message being flowed to the client was provided.

However, as shown in FIG. 16B, in the response 1607 to the request for the message set made by the email client component, the email server component 502 can provide the total number of data objects to be transferred and all the data to be transferred. The total size of the object. This information is represented by "Pall" in FIG. 16B. The latest version of the email server component 502 may also provide the size of each message indicated by "P1, P2, P3, ..." in FIG. 16B. In addition, if necessary, the information associated with each message and the entire set of messages may include additional information about whether each message is FAI or an actual email message. In one embodiment, even if zero data objects are transmitted, the information represented by "Pall" in FIG. 16B is always transmitted in response to a fast transmission request in order to simplify the processing of the data stream.

The following table shows an example of the format for the size and number of all data objects being transferred.

It can be seen that separate attributes can be defined for the number of FAI data objects, the total size of all FAI data objects, the number of e-mail messages to be transmitted, and the total size of all e-mail messages to be transmitted. You can add other combinations and additional attributes to the format as needed.

The following table shows the size and format of other information that can be provided for each message.

It can be seen that the format includes the size of the next message and whether the next message is FAI.

17A and 17B show the steps for streaming the message set based on the previous version of these email components and the latest version of these email components, respectively. The steps in FIG. 17A are similar to steps 1501-1503 in FIG. 15A. Regarding FIG. 17B, for example, using ROP, the most recent email client component 501 has sent the PROGRESS_MODE flag. After preparing the message set in step 1701, it is determined whether the tag exists. If it exists, then the total number of progress data is sent in step 1702, and then the process proceeds to step 1502, where the first message is flowed out. If the tag does not exist, then step 1701 branches directly to step 1502.

After allowing the first message to flow out, the process proceeds to step 1703, where it is determined whether the flag is available. If so, then step 1703 branches to step 1704, where the progress data of each message is flowed out. Then, as previously described, the process proceeds to step 1503. If there is no such mark, step 1703 branches directly to step 1503.

The following is an example of the data flow in which the most recent server component sends data to the most recent client component. The data flow is similar to the data flow described above, but additionally includes ptags (ptagIncrSyncProgressMode) of the total progress data, which may have, for example, binary attributes. In addition, for each message, the progress data of each message is provided, for example, as <pre listing-type="program-listing"> ptagIncrSyncPreogressModePerMsg. PtagIncrSyncProgressMode[PT_BINARY] [Contents as described by table] ptagMessageListStart PtagIncrSyncProgressModePerMsg[PT_BINARY] [Contents as described by table] ptagMessageStart ptagPropList ptagSubject[PT_STRING] "Re: Your email" ...... ptagMessageEnd ptagIncrSyncProgressModePerMsg[PT_BINARY] [Contents as described by table] ptagMessageStart ...... ptagMessageEnd ptagMessageListEnd</pre> In the example shown, the ptags(ptagIncrSyncProgressMode) of the total progress data and the value of the message progress data are included ptags (ptagIncrSyncProgressModePerMsg) are located before the message list and before each message. However, the flow structure of these data objects can be modified so that progress data can be included in these messages or the message list. The flow structure of these data objects can be further modified to completely eliminate the ptags that delimit the message and/or message list.

The email client component that receives the progress data can use this data to determine the progress of the synchronization or copy of the data object from the email server component, and can use each message progress data to determine the progress of each individual message. For example, in the process of monitoring real-time information about the progress of synchronization, this information may be helpful.

There are several different character sets that can be used to store email messages or other data objects. For example, ASCII is most commonly used to store English characters. However, ASCII is not enough to store characters in all languages, because it is based on 8-bit characters. In this way, the ASCII code can only be used for 256 characters, which is sufficient for English, but not enough for languages with more characters. On the other hand, Unicode uses a 16-bit (two-byte) character set for each character, so it can include more characters than ASCII. The Unicode can have 65,536 characters, so it can be used to encode almost all languages in the world. The Unicode includes the ASCII character set within it.

Generally speaking, the email client component 501 of the previous version has a specified code page or a character set and/or language associated with it. For example, a special version of the email client part 501 may have a German code page, and another version may have an ANSI code page. Sometimes, the email client component 501 may need to receive emails in a character set other than the specified code page. According to one aspect of the present invention, the latest client component may force the email server component to provide all emails using Unicode. Once the email client component 501 receives these emails, the Unicode email can be converted into the code page of the client, or, alternatively, the Unicode format can be used to maintain the Unicode email.

In order to indicate that the e-mail client component 501 requires uniform character encoding to provide e-mails, for example, the e-mail client component 501 may provide a mark (for example, FORCEUNICODE) to the e-mail server component 502. A request (e.g., ROP) can be provided for the mark. If the email server component 502 is the most recent version, the email server component 502 may provide a Unicode version of the email (if any), or may convert email messages in other character sets into Unicode.

Figure 20 shows the steps for providing a special character set for a message according to an aspect of the present invention. Starting from step 2001, the email server component 502 retrieves messages from its data register. In step 2002, it is determined whether the FORCEUNICODE flag exists. If it does not exist, then step 2002 branches to step 2003, where the e-mail server component 502 provides the e-mail message in the designated code page of the e-mail client component, and can be converted if necessary.

If the FORCEUNICODE flag exists, then step 2002 branches to step 2004, where it is determined whether the message is stored as a Unicode. If so, step 2004 branches to step 2005, where the message is provided to the email client component 501 in the Unicode character set. If the message is not stored in Unicode, then step 2004 branches to step 2006, where the message is converted to Unicode; then, the process continues to step 2005, where Unicode is used Provide the message to the email client component.

All references including the publications, patent applications and patents cited herein are included here for reference purposes, as if each reference material is individually and clearly stated to be included here for reference, and is stated here as a whole .

Unless otherwise indicated herein or the context clearly contradicts, the terms "a" (a), "an" (an) and "the" (the) in the context of describing the present invention (especially in the context of the following claims) ) And similar use of referents will be interpreted to include both singular and plural. Unless specifically indicated otherwise, the terms "comprising" (comprising), "having", "including" and "containing" will be interpreted as open-ended terms (ie, meaning "including, but Not limited to"). Unless otherwise indicated herein, the enumeration of the range of values herein is only intended to be used as a shorthand method for individually referring to each individual value within the range; and, each individual value is incorporated into the specification as if It is listed separately here. Unless otherwise indicated here or there is an obvious conflict of context, all methods described herein can be executed in any suitable order. Unless otherwise stated, the use of any and all examples or demonstrative language (for example, "for example") provided herein is only intended to better clarify the present invention, and does not limit the scope of the present invention. The language in this specification should not be interpreted as saying that any undeclared element is indispensable for practicing the present invention.

The preferred embodiments of the present invention are described here, including the best mode known to the inventors for carrying out the present invention. By reading the foregoing, those with ordinary skills in the technical field will understand the changes to the preferred embodiments. These inventors expect skilled craftsmen to appropriately use such changes, and these inventors intend to practice the present invention in a manner different from that specifically described herein. Accordingly, applicable laws and regulations allow: the present invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto. Moreover, unless otherwise indicated herein or there is an obvious conflict of context, the present invention includes any combination of the above-mentioned elements in all possible modifications thereof.