Communication system providing enhanced operation protocol selection character and related methods

Communication system and related method including protocol interface device that provides enhanced operating protocol selection feature

[0001] The present invention relates to the field of communication systems, and more specifically, to a communication system and related methods that use multiple operating protocols for data access operations.

Background technique

[0002] A software client operating on a computer system or in conjunction with a computer system is usually used to access data stored on a server, and the computer system can establish communication with the server through, for example, a local area network (LAN). Typically, the client is configured so that a specific protocol supported by the client is used to access data on the data system. However, some data storage devices can also be accessed through other protocols, and each protocol can support different features.

[0003] For example, in an electronic mail (e-mail) system, the user has a corresponding mailbox on the mail server, and can use Outlook network access (OWA), Internet mail access protocol (IMAP) or post office protocol (POP) to access mailbox. Although the user may have configured an email client to use POP to access his or her mailbox, for example, when using another client, or when accessing multiple mailboxes that support different protocols, it is desirable to use More advanced features and more capable 0WA and IMAP for mailbox access.

[0004] A variety of existing technologies have been developed to provide communication between systems and devices that use different operating protocols. One such solution is described in U.S. Patent No. 6,615,212 to Dutta et al., in which a transcoding proxy server receives a request for content from a client. The transcoding proxy server retrieves the content from the originating server. Provide the retrieved content in the first format type. In response to the determination that an increase in efficiency will be obtained by allowing the client to process the content of the first format type before transcoding the content into the second format type, the transcoding proxy server sends the content to the client in the first format type.

[0005] In addition, in response to a determination that the client does not have content processing software for processing content in the first format, the transcoding proxy server sends the content processing software for the first format type together with the content of the first format type to Client. Then, the code conversion proxy server converts the content from the first format type code to the second format type, and sends the content in the second format to the client.

[0006] In addition to these existing technical solutions, in specific applications, additional protocol translation and/or conversion functions are required.

Summary of the invention

[0007] Therefore, in consideration of the foregoing background technology, the purpose of the present invention is to provide a communication system for providing enhanced operating protocol conversion features, and related methods.

[0008] This and other objects, features, and advantages according to the present invention are provided by a communication system. The communication system may include: a plurality of data storage devices, and each data storage device uses at least one of a plurality of operating protocols. One. In addition, at least one of the data storage devices can be operated using multiple operating protocols. The system may also include a plurality of mobile wireless communication devices for accessing the at least one data storage device, and each mobile wireless communication device may use at least one of a plurality of operating protocols.

CN 1823508 Β

[0009] In addition, the system may also include a protocol interface device. The protocol interface device may include a front-end agent module for communicating with multiple mobile wireless communication devices using corresponding operating protocols. The protocol interface may also include a protocol engine module, which is used to communicate with multiple data storage devices using a corresponding operating protocol. The protocol engine module may also select an operating protocol required for communicating with the at least one data storage device from a plurality of operating protocols.

[0010] More specifically, the protocol engine module may select the desired operation protocol according to the ordering of the multiple operation protocols. In addition, the permutation can be based on protocol support elements related to various protocols. As an example, the operating protocol may be an email (e-mai 1) protocol such as Outlook Web Access (OWA), Internet Mail Access Protocol (IMAP), or Post Office Protocol (POP). Similarly, the protocols can be ordered according to their corresponding protocol support elements or features. Therefore, typically, according to the number of elements or features supported by each, OWA ranks higher than POP, and the protocol engine module will use this rank when choosing between the two.

[0011] In addition, the protocol interface device also includes a memory connected to the protocol engine module for storing each account information related to each mobile wireless communication device. For example, each account information can be associated with various protocols supported by each mobile wireless communication device. Therefore, the protocol engine module can not only select the required protocol based on the protocol sequence, it can also select the required protocol according to the capacity of a given mobile wireless communication device.

[0012] In addition, the front-end proxy module and the protocol engine module can advantageously communicate using a common interface protocol capable of exhibiting a required number of protocol support elements for the required operating protocol. More specifically, the common interface protocol may be able to exhibit all protocol support elements for the most capable operating protocol. Therefore, using the above example where OWA is the most capable protocol, the common interface protocol can support all the elements or features of OWA, although it can also support other features. As an example, the public interface protocol may be based on the Web-based Distributed Authors and Version (WebDAV) protocol.

[0013] For example, the plurality of data storage devices, the plurality of mobile wireless communication devices, and the protocol interface device may process electronic mail (e-ma subscription) messages. In addition, the mobile wireless communication device can send an access request, and in response to the access request, the data storage device can send data (e.g., email data). In addition, one or more of the data storage devices can use the root folder and target email box capacity to respond to the access request.

[0014] In response to at least one non-supported operating protocol, the protocol interface may generate an error. In addition, the communication system may also include a wide area network (WAN) (such as the Internet), so that at least one of the mobile wireless communication devices is connected to the protocol interface device. It is also possible to use this wide area network (WAN) to connect at least one of the data storage devices to the protocol interface device.

[0015] The method scheme of the present invention is used to interface multiple mobile wireless communication devices with multiple data storage devices. Each of the mobile wireless communication device and the data storage device may use at least one of multiple operating protocols, and at least one data storage device may operate using multiple operating protocols. The method may also include setting a front-end agent module for communicating with multiple mobile wireless communication devices using a corresponding operating system. The method may further include setting a protocol engine module for communicating with a plurality of data storage devices and communicating with the front-end agent module using corresponding operating protocols. The method further includes causing the protocol engine module to select an operating protocol required for communicating with the at least one data storage device from a plurality of operating protocols.

[0016] The protocol interface device according to the present invention may include a front-end proxy module and a protocol engine module, such as the modules briefly described above. In addition, similarly, the computer-readable medium according to the present invention may include a front-end agent module and a protocol engine module.

Description of the drawings

[0017] FIG. 1 is a schematic block diagram of a communication system according to the present invention.

[0018] FIG. 2 is a schematic block diagram showing the protocol interface device in the communication system shown in FIG. 1 in more detail.

[0019] FIG. 3 is a schematic block diagram showing in more detail the extensible front-end proxy module in the protocol interface device shown in FIG. 2.

[0020] FIGS. 4 and 5 are schematic block diagrams showing alternative embodiments of the communication system according to the present invention that implement an extensible agent architecture similar to that of FIG. 3.

[0021] FIG. 6 is a schematic block diagram of an alternative embodiment of the protocol interface device shown in FIG. 2.

[0022] FIG. 7 is a schematic block diagram showing the protocol engine module and its interface connector module in the protocol interface device shown in FIG. 3.

[0023] FIG. 8 is a schematic block diagram of an alternative embodiment of the protocol engine module and the interface connector module shown in FIG. 7.

[0024] FIG. 9 is a schematic block diagram of another alternative embodiment of the protocol interface device shown in FIG. 2.

[0025] FIG. 10 is a schematic block diagram of another alternative embodiment of the protocol interface device shown in FIG. 2.

[0026] FIG. 11 is a flowchart showing the operation of the protocol interface device shown in FIG. 2.

[0027] FIG. 12 is a flowchart showing the operation of the front-end agent module shown in FIG. 3.

[0028] FIG. 13 is a flowchart showing the operation of the communication system shown in FIG. 5.

[0029] FIG. 14 is a flowchart showing the operation of the protocol interface module shown in FIG. 6.

15 is a flowchart showing the operation of the protocol engine and interface connector module shown in FIG. 7.

[0031] FIG. 16 is a flowchart showing the operation of the protocol interface device shown in FIG. 9.

[0032] FIG. 17 is a flowchart showing the operation of the protocol interface device shown in FIG. 10.

[0033] FIG. 18 is a schematic block diagram of a typical mobile wireless communication device used with the present invention.

Detailed ways

[0034] Now, the present invention will be described more fully with reference to the accompanying drawings. In the accompanying drawings, preferred embodiments of the present invention are shown. However, the present invention can be specifically implemented in a variety of different forms, and should not be construed as being limited to the embodiments described herein. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of the present invention to those of ordinary skill in the art. Throughout the text, similar numbers indicate similar elements, and primary labels and multiple primary labels are used to indicate similar elements in alternative embodiments.

[0035] Turning now to FIG. 1, the communication system 10 includes a protocol interface device 14 that provides access to multiple data storage devices or systems 16, 18, 20. The communication system 10 schematically includes a plurality of communication devices, namely a mobile wireless communication device 11 and a communication device 12 connected to the system through a wired connection. As an example, a variety of mobile wireless communication devices, such as personal data assistants (PDAs), cellular phones, etc., can be used according to the present invention. In the example provided below with reference to FIG. 18, a typical mobile wireless communication device IL suitable for use with the present invention is described. In addition, examples of wired communication devices include personal computers, telephones, facsimile machines, and the like. Of course, multiple wired and wireless devices can be used, although only two are shown in the exemplary embodiment for clarity of illustration.

[0036] The communication devices 11 and 12 typically include software clients, which are software modules or applications that operate on or in combination with the corresponding communication devices, and are used to provide Access to data stored at at least one or more of the data storage devices 16, 18, and 20. Those of ordinary skill in the art should be aware that this communication device also includes other components and/or software modules, which are not shown in Figure 1 for clarity of illustration.

CN 1823508 Β

Shown in detail. For the mobile wireless communication device 11, its software client communicates with the protocol interface device 14 through the wireless communication network 13 (and possibly other networks (for example, the Public Switched Telephone Network (PSTN) or the Internet)), such as those of ordinary skill in the art Well known.

[0037] Preferably, the various functions and operations of the protocol interface device 14 are realized by software operating on or in combination therewith. The protocol interface device 14 graphically bridges the software clients of the communication devices 11 and 12 and the data storage devices 16, 18 and 20. The communication between the protocol interface device 14, the communication devices 11, 12, and the data storage devices 16, 18, 20 is preferably via a wide area network (WAN) such as the Internet. That is, the communication devices 11, 12 can be communicated with the protocol interface device 14 via the Internet Communication, as described above, the protocol interface device can also communicate with the data storage device 16.18.20.

[0038] Of course, other implementations can also be envisaged. For example, data storage devices 16, 18,

20. The protocol interface device 14 is implemented in the communication devices 11, 12 or a dedicated network of data storage devices and communication devices (for example, in a WAN). It should be noted that the present invention is not limited to any specific connection or communication scheme.

[0039] The data storage device 16.18.20 stores data to be accessed by the software client of the communication device 11, 12. Although some software clients can be configured to directly access specific types of data storage devices, they are usually data system-specific or protocol-specific, as briefly described above. More specifically, for example, on constrained electronic devices such as mobile wireless communication devices 11, processor capabilities, memory resources, and communication channel characteristics will prevent having the same capabilities as software clients commonly used on desktop and laptop computer systems. The installation and operation of the software client. In addition, although it is easy for desktop and laptop computer systems to install multiple software clients for accessing data storage devices associated with different protocols, it would be impossible to provide multi-protocol support on such constrained devices of.

[0040] Different operating protocols or access schemes can be used to access the data storage devices 16.18.20. In this way, the protocol interface device 14 accesses the data storage devices 16, 18, 20 through the operating protocols supported by each data storage device, and through corresponding The operating protocol supported by the client, the protocol conversion function that provides data to the communication device protocol interface device 14 provides a unified solution that supports access to multiple types of data systems. As described in detail later, the protocol interface device 14 provides an "any-to-any bridge" between different protocols or access schemes.

[0041] The protocol interface device 14 is shown in detail in FIG. 2. As mentioned above, the protocol interface device 14 bridges different types of communication devices with different types of data storage devices. In the illustrated embodiment, the data storage device 24.26.28 is a system/server for storing electronic mail (e-ma subscription). However, it should be noted that the present invention is not limited to mail system access. Each of the mail systems 24, 26, 28 supports different operating protocols or access schemes. More specifically, the mail system 24 supports Outlook web access (0WA), the mail system 26 supports the Microsoft Messaging Application Programming Interface (MAPI), and the mail system 28 supports proprietary protocols, such as the protocol used by America Online (A0L).

[0042] The protocol interface system 14 schematically includes a front-end agent module 30. The front-end proxy module schematically includes proxy modules 34, 36, 38, 40, which respectively support Wireless Application Protocol (WAP), Post Office Protocol (POP), Internet Message Access Protocol (IMAP) and Hypertext Transfer Protocol (HTTP) to facilitate communication with The client communicates.

[0043] The front-end agent 30 also communicates with the protocol engine module 32. The protocol engine module 32 translates the proprietary protocols of OWA, MAPI, and the mail system 28 (and other protocols, if necessary) into a format compatible with the front-end agent module 30. To this end, for each operating protocol used by the mail system 24.26.28, the corresponding interface connector module 70-77 (FIG. 7) can be connected to the protocol engine module 32, which will be further discussed later. In a preferred embodiment, the front-end proxy module 30 and the protocol engine module 32 are extensible to accommodate these additional operating protocols when they become available, which will be discussed further later.

CN 1823508 Β

[0044] In operation, the user accesses the mailbox on one of the mail systems 24.26.28 through the client software on his communication device. For example, a WAP browser on a mobile wireless communication device communicates with the WAP proxy module 34 to access the mail system 24. The access command or instruction received by the WAP proxy 34 is converted into a format compatible with the protocol engine module 32. Preferably, the communication between the front-end agent module 30 and the protocol engine module 32 is realized through a public interface protocol (which may be a private protocol or an established shared protocol).

[0045] Then, the protocol engine module 32 translates the access command or instruction received from the front-end agent module 30 into a protocol associated with the mail system to be accessed (for example, OWA for the mail system 24). It will be received from the mail system The received data (for example, email messages, new message lists, calendar appointments, tasks, etc., depending on the specific mail system), the features supported by its access protocol, and the features of access commands are translated into a public interface protocol and sent to the front end proxy.

[0046] Then, the effective proxy module (ie, the WAP proxy module 34 in this example) formats the received data or at least part of it for the requesting client. The protocol interface device 14 also translates other commands from the client. Access commands from other types of clients are processed similarly. It should be noted that in the case where the user has enabled multiple mailbox access through the protocol interface device 14, several mail systems can be accessed in response to a single access command.

[0047] Therefore, the protocol interface device 14 allows clients using different operating protocols to access the mail systems 24, 26, 28 that also use different operating protocols. Access commands generated at the client, such as move, delete, create, send, obtain, and view, affect the data stored at 24.26.28 of the mail system instead of a copy of the data. Through the protocol interface device 14, a client compatible with any one of the proxy modules 34, 36, 38, 40 is provided with access to one or more of the mail systems 24, 26, 28. The client itself advantageously does not need to support the access protocol or scheme associated with the mail system to be accessed.

[0048] Since the mail system protocol and the client protocol do not need to be compatible with each other, the features supported between the protocols can also be different. For example, the POP client does not support the same features as 0WA. Preferably, the interface protocol used between the protocol engine module 32 and the front-end agent module 30 is designed so that it can exhibit a required number of protocol support elements or features for the required operating protocol. More specifically, the public interface protocol should best exhibit all protocol support elements for the most "capable" protocol (0WA in this example) to provide the widest possible feature support. In addition, if required, the common interface protocol can support a complete feature set spanning all supported protocols.

[0049] As an example, the public interface protocol may be a private protocol based on the Web-based Distributed Authoring and Versioning (WebDAV: Web-based Distributed Authoring and Versioning) protocol. Hereinafter, an example of an authentication request using this public interface protocol is represented as program list #1. This typical authentication request routine allows the mail system to use the user identifier and password provided by the user to authenticate the protocol interface device 14 and to retrieve the root folder and basic capacity of the target mailbox on the mail system.

[0050] Below, as a program list #2, a typical inbox request according to the WebDAV-based public interface protocol is described. According to this routine, in response to the inbox request, the capacity of the inbox in the target mailbox is queried, and then the content is queried. Below, as program list #3, another example is provided for a folder search request based on the above-mentioned WebDAV-based public interface protocol. Here, in response to this request, a list of subfolders of the given folder is returned. It should be clear to those of ordinary skill in the art that a variety of other requests and operations can also be used.

[0051] It should be noted that the software client does not have to initiate data access requests in all embodiments. For example, in some embodiments, the protocol interface device 14 may include (or communicate with) a polling or aggregation engine module (not shown) that prompts the protocol engine module 32 at predetermined intervals From the mail system 24.26.28, the messages for each user are gathered, as well known by those of ordinary skill in the art. Then, the protocol interface device 14 will cooperate with the front-end agent module 30 to provide the aggregated messages to the corresponding software client, as described above. In addition, the front-end generation

CN 1823508 Β

The management module 30 does not need to directly communicate with the communication devices 11 and 12 in all embodiments, but may also communicate with it through an intermediary mail system or a server. Therefore, in the case of using the aggregation engine module, the front-end agent module 30 can first transmit the aggregated messages to the intermediary mail server, and the intermediary mail server provides the messages to the appropriate communication equipment. This is also known by those of ordinary skill in the art. openly known. Likewise, the front-end agent module 30 will communicate with it using the appropriate protocol supported by this intermediate mail server.

[0052] FIG. 11 shows a method of using the protocol interface device 14 to provide access to multiple data storage devices such as the mail system 24.26.28. Starting at block 110, first at block 111, an access command or data is received. In block 112, the access command or data is translated into a common interface protocol. Then, the access command is translated (block 113) into the data system protocol associated with the data system to be accessed, such as 0WA for the mail system 24_o

[0053] On the other hand, at block 113, the data is translated into a client protocol. According to the specific features supported by the client protocol, during this step, only the part of the data corresponding to the elements of the interface protocol supported by the client protocol is translated. The protocol interface device 14 may generate an error in response to an unsupported operating protocol. More specifically, it is preferable to ignore or process unsupported interface protocol elements according to the default or error handling scheme. Then, at block 114, the translated access command or data is transmitted to the data system or client, thereby ending the method shown (block 115).

[0054] Turning now to FIG. 3, an exemplary embodiment of the front-end agent module 30 will be described. The front-end proxy module 30 schematically includes proxy modules 34, 36, 38, 40; a renderer module 44; an extensible style sheet language conversion (XSLT) engine module 46, a memory or template memory 48, a stream controller module 50, and a processor 52a-52n.

[0055] As described above, each agent module 34, 36, 38, 40 effectively "fronts" the protocol engine module 32, and translates corresponding operating protocols for different client types. For example, the WAP proxy module provides information retrieved from one or more of the processors 52a-52n in the form of an XML document targeting the display on a device such as a cell phone or a PDA. The POP proxy can use at least some of the same proxy components, including the stream controller module 50 and the renderer module 44, in order to reproduce data in the form required by the POP protocol.

[0056] A particularly advantageous benefit of the front-end proxy module 30 shown is that each proxy module 34, 36, 38, 40 uses the same core service to route business, access data, and reproduce data. In other words, the renderer module 44, the XSLT engine module 46, the template memory 48, the stream controller module 50, and the processors 52a-52n provide common core service modules for the proxy modules 34, 36, 38.40. The only difference between the translations of the different proxy modules 34, 36, 38, 40 is the configuration of the flow controller 50, the processors 52a-52n, and the XSL template used to translate the data into its final form. In many cases, the same processor 52a-52n will be reused among the various agent modules 34, 36, 38, 40, as known to those of ordinary skill in the art.

[0057] During operation, a standard mechanism for the client protocol is used to pass the data access request from the client to the appropriate proxy module 34, 36, 38, 40. For example, for WAP clients, parameters are passed through query strings and/or table variables. The WAP proxy module 34 determines the component identifier (identifying target items such as mail folders), the action identifier (identifying the action to be performed), and any parameters based on the data in the request. In the case of WAP, the component and action identifiers are passed in the query string or table. Pack the query string or other parameters in the table into a parameter list.

[0058] Then, the effective proxy module calls the flow controller 50 to pass the identifier and the parameter list. The flow controller finds the appropriate processor through the component and the action identifier, and constructs the processor, and passes the parameters as the argument of the builder (not shown)_oUsing the processor 52a as an example, this processor will use the data layer (Figure 5) to process the request to collect the information needed for the response.

[0059] For example, for mail system access, the data layer is targeted at information related to the user's mailbox, calendar, or address book.

CN 1823508 Β

Information, communicate with the protocol engine module 32. Communication with other components can be established for different types of information, such as information related to authentication services and users' email accounts. Then, the processor 52 decides whether to forward the request to another processor, or whether the result should be reproduced.

[0060] Preferably, all the information passed back by the processors 52a-52n is in a common format, such as org. xml. sax. Inputsource, a provider of extensible markup language (XML) data. Then, the effective proxy module calls the renderer module 44 to pass the InputSource, location information, the name of the template to be reproduced, and the Outputstream. The renderer module 44 uses the XSLT engine 46 to render the page as an Outputstream. Then, the effective proxy module uses the client protocol to provide the Outputstream to the client.

[0061] The above-mentioned system provides a general application framework that follows the classic model/view/controller (MVC) architecture that implements most of the application infrastructure. An important feature is that a set of basic functions can be defined for similar services, and then expanded to provide the service-specific functions required to fully implement a given service. In the given implementation, the flow controller 50, the processors 52a-52n, and/or the data access layer are fully expandable or replaceable.

[0062] With this in mind, supporting a new service only involves defining and implementing the data layer, defining the control flow and discrete actions within the system (ie, the flow controller module 50), and defining and implementing the interface with the service (ie, the renderer). Module 44). On the other hand, using existing services to support new types of clients involves making minor changes to the flow controller module 50 and processors 52a-52n, and extending the actions in them to support additional client functions, as well as definitions and implementations. The interface between the client and the system (ie, the renderer module 44).

[0063] The operation of the front-end proxy module 30 that performs protocol translation will be further described with reference to the block diagram of FIG. 12. Some of the illustrated operations have been described in detail above, so they will be briefly described below to avoid unnecessary repetition. Starting at block 120, at block 121, the proxy module 34, 36, 38, 40 receives an access request or command. At block 122, the access request is translated into a common interface protocol by one or more of the processors 52a-52n.

[0064] At block 123, in response to the request, receive data from the given mail system 24.26.28. The reproduction has been translated into the data of the common interface protocol by the protocol engine module 32 (block 124), and returned to the client at block 125, thereby ending the illustrated method (block 126). According to the specific features supported by the client protocol, only part of the data corresponding to the elements of the public interface protocol supported by the client protocol is reproduced or translated. As mentioned above, the unsupported interface protocol elements can be ignored or processed according to the default or error handling scheme.

[0065] It should be noted that the scalable, common core service architecture of the front-end agent module 30 can also be used for multiple applications. One such application is used to solve the multiple shortcomings of the disparate methods used by web applications to respond to HTTP requests. Referring now to FIGS. 4 and 5, a network data access system 100 having a scalable architecture according to the present invention will be described. The components of the network data access system 100 perform two-way communication, which schematically includes a user request 101, a network server 102, a proxy server 104, and an extensible controller system 106.

[0066] More specifically, the user request 101 refers to a user who requests a web page using a web browser or a web application (for example, through a PDA or a personal computer). Once the request is made, the web server 102 will process the request. In the process of processing the request, the proxy server 104 assists the web server 102. For the purpose of comparison, the function of the proxy server 104 here is similar to the protocol interface device 14 described above, and the extensible controller system 106 is implemented as a software module running on or in combination with the proxy server, such as those of ordinary skill in the art. As it is known. Of course, in some embodiments, for example, the proxy server 104 and the extensible controller system 106 may be implemented in different physical devices or servers.

[0067] The proxy server 104 provides the following processing: providing other services that have slower access or more resource-intensive access

CN 1823508 Β

Cache or storage items available on the server. The proxy server 104 accepts URLs with a specific prefix. When it receives a request for such a URL, it strips off the prefix and looks up the obtained URL in its local cache. If it finds it, it immediately returns the document, otherwise it gets the document from the remote server and stores it in the cache. Save a copy in the device and return it to the requesting party. The pages returned by the proxy server 104 may be static or dynamic in nature. The proxy server 104 may communicate with an application server or a data server (in this particular embodiment, the extensible controller system 106).

[0068] More specifically, the components of the proxy server 104 schematically include an aggregation server 202, a renderer module 212, an XSLT engine module 214, and a storage 216 for storing a series of templates, similar to those described above. The components of the extensible controller system 106 include an action map 204 and a series of processors 206, similar to those described above.

[0069] The aggregation server 202 performs processing of input information and, for assistance, passes it to other components. The reproducer module 212 reproduces the obtained data into a visual format. The renderer module 212 uses the XSLT engine module 214 and any required templates from the storage 216 to render the page.

[0070] The aggregation server 202 sends the data to the action map 204, and the action map 204 maintains the control flow and processes the business logic in the system. The action map 204 interacts with a series of processors 206. The processor 206 uses the data layer 208 to retrieve information from other data sources 210. For example, other data sources 210 may include XML for web data, general agents for any information related to user application content (such as email, calendar, or contact information), or authentication services and data related to user accounts. API ο

[0071] The function of the system is to enable a user to submit a URL as a user request 101. This request is received at the web server 102 and passed to the proxy server 104 for processing using standard mechanisms for the protocol. For example, WML requests will pass WAP parameter query strings and/or table variables. The aggregation server 202 component of the proxy server 104 determines the component ID, the action ID, and any parameters based on the data in the request. Using the same WAP example, pass the component and action ID in the query string or table to package all other parameters in the query string or table into a parameter list.

[0072] Then, the aggregation server 202 calls the action map 204 of the extensible controller system 106, and transmits the ID and parameter list. The action map 204 finds the appropriate processor 206 through the component and the action ID, and constructs the processor, and passes the parameters as arguments of the builder. The processor 206 processes the request and uses the data layer 208 to collect the information needed for the response. The data layer 208 will retrieve information from other data sources 210 located within or outside the network. Then, the processor 206 decides whether the request should be forwarded to another processor 206, or whether the result should be reproduced.

[0073] If the system decides to reproduce the data, the data is passed from the processor 206 back to the action map 204, and passed back to the aggregation server 202 of the proxy server 104. Then, the aggregation server 202 calls the renderer module 212, and the renderer module 212 calls the XSLT engine module 214 and any templates required to render the data into a visual output. Then, this output is returned to the web server 102, as a result of the user request 101, this data is used as a visual web page.

[0074] Now, referring to FIG. 13, the multiple steps involved in processing network data using the extensible controller system 106 will be further described. More specifically, this schematic diagram shows the processing and interaction actions of the proxy server 104 and the extensible controller system 106 in more detail. This system flow starts with user request 101. This request is sent to the web server 102, and the web server 102 passes this information to the proxy server 104 for processing. The proxy server 104 calls the aggregation server 202 for processing.

[0075] At block 302, the aggregation server 202 determines whether the context is available. If available, the system will move to the next step to mine the ID (block 306). If it is not available, the system will first create a context in block 304, and then proceed to block 306 to mine ID. Similarly, dig out the action ID and component ID from the system. At box 308,

Pack these IDs together with request parameters and any table data into an envelope and collect them together.

[0076] The calling program is called to transfer data from the aggregation server 202 to the action map 204 of the extensible controller system 106. This calling program passes information related to the envelope, action code, component ID, and context to the action map 204. At block 310, the action map 204 looks for the action, and at block 312, it is determined whether the action exists. If it exists, move to the next step to determine whether the action requires authentication at block 316. If the action does not exist, the system retrieves the default action at block 314, and then at block 316, determines whether the action requires authentication.

[0077] At this point, if the action does not require authentication, the system determines at block 320 whether there are any pending requests. If the action does not require authentication, the system determines at block 318 whether the context is in an authenticated state. If the context is in the authenticated state, the system determines at block 320 whether there are pending requests. However, if the context is not in an authenticated state, the system returns a request at block 314 to retrieve the default action until authentication is accepted.

[0078] At block 320, the system determines whether there are pending requests. If there is a pending request, the system executes the pending request and jumps to the next stage. At block 346, it is determined whether there is a process in the queue. If there are no pending requests, the system executes the action at block 322 and verifies the encapsulated data, and at block 324, passes control of the processor 206 to create an action processor. Once the action processor is created, it is initialized at block 326.

[0079] Then, the system determines whether to allow background processing at block 328. If allowed, the background processor is created at block 344, and at block 346, the system determines whether there is a process in the queue. However, if background processing is not allowed, the system processes the action processor at block 330 and then returns the result at block 332. Returning to the system, at block 346, the system determines whether there is a process in the queue. If there is processing in the queue, then at block 350, it is determined whether the action is completed. If there is no processing in the queue, then at block 348, it is submitted to the queue, and then at block 350, it is determined whether the action processor is complete.

[0080] If the action processor is completed, the system returns the action processor result at block 352. If the action processor is not completed, the system returns the pending rendering result at block 354. The output of the steps shown in blocks 352 and 354 (return action processor results or pending renderer results) is used to determine at block 334 whether to reproduce the results.

[0081] More specifically, the results of the steps shown in blocks 332 (return result), 352 (return action processor result), and 354 (return pending reproduction result) are used to determine whether to reproduce the result (block 334) . If the system decides to reproduce the result, the system sends the data from the extensible controller system 106 to the proxy server 404, and at block 340, reproduces the data at the reproducer module 212. Then, this data is passed to the web server 102 to display the result at block 342 as a response to the user request 101. However, if the system decides not to reproduce the result, but instead decides to forward the request to another action processor for processing, the system retrieves the ID key at block 336, retrieves the encapsulated data at block 338, and then Find the appropriate action at block 310. The system will loop at this point until, at block 334, it is decided to finally accept the reproduction result.

[0082] The above method involves the use of a single resource to define the components within the system. In this particular embodiment, the source is an XML file, but other formats can also be used, as known to those of ordinary skill in the art. This source will define the code for processing the request, URL syntax and parameters, the template or code used to generate the response to the request, and the routing information of the request.

[0083] The system uses the code for processing the request and the parameter definition to create the action handler and pass the correct type of parameter.

CN 1823508 Β

Count and pass control of it for processing. The parameters include type information that allows strongly typed data. You can also define parameters as optional or required. Templates are used to generate responses to requests. If you try to generate a response other than the one defined, an error is generated.

[0084] The source also defines the requested routing information. Usually, a processor is required to perform work within its scope, and then control is passed to another processor to allow it to perform its work. However, if the processor shows to pass control to something else that is not defined in the source, an error is generated.

[0085] Other variants are also possible. For example, the source can be used when generating a URL for use in the system. In addition, request routing can be separated from the actual processing of these requests. Thus, one component in the system handles the control flow, not each processor. The processor will then simply ask the controller to forward the request to another processor. Therefore, the input data can be kept in a known state during a specific request life cycle.

[0086] Another solution involves enhancing the control flow through the system, in which case one processor does not directly call another processor to perform its work. Another solution involves keeping the processor relatively small and simple. That is, this limits the purpose and scope of the processor to receiving requests, and calls appropriate business logic to collect the desired results. Another variant involves keeping each processor focused on one task, and allowing results to be reproduced or forwarded to the next processor when the task is completed.

[0087] Another variant involves providing a scalable mechanism for handling requests capable of handling immediate needs, and which grows over time without becoming overly complex. When loading the system, the user can specify primary and secondary action mapping. In this way, the general business logic and control flow are defined by the primary action mapping, and at the same time, the user is provided with methods for adding or modifying functions. Another solution is to provide developers with a mechanism for quickly responding to long-running requests to avoid timeouts. This allows developers to specify background processing at the processor level or the entire system.

[0088] The above-mentioned extensible controller is particularly helpful in solving the shortcomings of web or HTTP-based applications. Of course, it should be clear to those of ordinary skill in the art that the same architecture can be extended to support other types of non-HTTP-based applications.

[0089] Turning now to FIG. 6, an alternative embodiment of the protocol interface device 14' will be described. In the illustrated embodiment, in the configuration file stored in the configuration file storage or memory 31', all requests to data storage devices such as the mail system 24', 26', 28', etc. are defined. In this way, for a given client category, application developers can easily request support for only those attributes required by the client written for them.

[0090] The resource manager, which can be part of the front-end proxy module 30' or a separate component of the protocol interface device 14, advantageously allows the user to specify primary and secondary profile groups. If a secondary configuration file is specified, any resources defined therein will override those specified in the primary configuration file. This allows the user to specify the core resource set and adapt it to a particular implementation.

[0091] In addition, configuration files can be stored to handle operations at different network layers. For example, the configuration file for the data layer operation used for the interface front-end proxy module 30 and the protocol engine module 32' can be stored in the memory 31', and the configuration file for the upper network layer operation performed by the flow controller module 50 Wait. Other types of configuration files can also be used, as known to those of ordinary skill in the art.

[0092] Preferably, the configuration file also specifies the creation of an implementation class for processing a response to a given request. This makes it easy to slightly change the behavior of objects in the data model (or even completely replace them). The configuration file also specifies the caching behavior and strength for each request. Using the combination of these two attributes, developers can have more control over memory consumption and response/request performance.

[0093] In addition, the configuration file also allows the user to specify multiple requests for a given resource. This enables it to support data systems with different request/response formats. Below, a typical configuration file is provided as program list #4. This configuration file is suitable for data storage that supports the WebDAV interface, as described above, or in the case of the protocol interface device 14, a protocol engine that supports the WebDAV interface. However, it can also be used for other types of interface/data storage.

[0094] It should also be noted that, in addition to the content category specified for the resource, the user can also specify a command to further identify a given resource. This allows users to perform many different operations on a given resource type, as is well known to those of ordinary skill in the art.

[0095] Now, with reference to FIG. 14, the operation of the protocol interface device 14' using the configuration file will be further described. Starting at block 140, at block 141, an access request or command is received at the proxy module. At block 142, the processors 52a-52n refer to one or more configuration files to translate the access request into a common interface protocol. At block 144, the data received from the data system in response to the request (block 143) and that has been translated into the common interface protocol by the protocol engine module 32' is formatted as a response and reproduced. Similarly, refer to one or more configuration files to complete. Then, the reproduction response is returned to the client (block 145), thereby ending the method shown at block 146.

[0096] Now, referring to FIG. 7, the protocol engine module 32 will be described in more detail. The protocol engine module 32 provides a framework that incorporates multiple interface connector modules 70-77 that communicate with multiple mail systems using different protocols. The protocol engine module 32 also provides common interfaces XML and WebDAV. For example, the client uses the front-end proxy module 30 to access multiple mail accounts. A common operation similar to only retrieving the basic header of a new mail and determining the existence and size of the attachment without downloading is highly effective. Perform all operations directly on the source, and only retrieve basic data.

[0097] The protocol engine module 32 uses an appropriate one of the plurality of interface connector modules 70-77 to access the mail account. All the connector modules 70-77 preferably support a common application programming interface (API), so that the protocol engine module 32 supports a new protocol volume by simply adding a new interface connector module. For example, the connector modules 70-77 can be written in Java, although other suitable languages or protocols can also be used. For example, the performance and availability of the entire system can be improved by providing multiple dynamic load balancing protocol engines.

[0098] Similarly, the result received by the protocol engine module 32 from the mail system 24.26.28 is translated into a public interface protocol, so that when necessary, it is translated into a protocol supported by the client and transmitted to the client. Preferably, the result of the communication back to the client includes only the data requested by the client. The data corresponding to the features supported by the mail system protocol but not supported by the client protocol can be translated into a public interface protocol, but it can also be ignored or processed according to the default or error handling scheme, as described above.

[0099] Now, referring to FIG. 15, the protocol translation method using the protocol engine module 32 and the interface connector modules 71-77 will be described. Starting at block 150, at block 151, an access request or command is received. In block 152, the access request is translated into a protocol supported by the target data system. In block 153, in response to the request, data is received from the data system, and in block 154, it is translated into a common interface protocol. If necessary, further translation of the data into the client protocol can be performed at block 155, and the data can be transmitted to the client at block 156, thereby ending the illustrated method at block 157.

[0100] Similarly, depending on the specific features supported by the client protocol, only part of the data corresponding to the elements of the public interface protocol supported by the client protocol is translated. As mentioned above, the unsupported interface protocol elements can be ignored or processed according to the default or error handling scheme.

[0101] Turning now to FIG. 8, an optional embodiment of the above-mentioned protocol conversion module architecture is described. Here, the protocol engine module 32 takes the form of a universal agent (UP) servlet module 80, and each interface connector module

Blocks 81, 82, 83 and corresponding supplier modules 84, 85, 86 are associated with different operating protocols. In the example shown, the different protocols are OWA, IMAP and POP. Other or different protocols can be supported by the corresponding vendor/connection pair, as known to those of ordinary skill in the art.

[0102] For the public interface protocol, such as the above-mentioned private interface protocol, the UP servlet module 80 receives the input public format request, and uses the defined interface to translate it into a call to the interface connector modules 81-83. The UP servlet module 80 also receives the results of these calls and formats them into a common format request. Each common format request includes a method request and a path in the form of a URL. It can also include an XML document that provides additional parameters for the request.

[0103] Conceptually, below the UP servlet module 80, there are supplier modules 84-86 for each supported mail system protocol. The supplier handles the calls made by the UP servlet module 80. As shown in the figure, each provider has a connection for communicating with the source mailbox/account on the target mail system. Initially, the connection was also a supplier. [0104] The interface used by the UP servlet 80 and implemented by the supplier modules 84-86 defines a loose folder hierarchy. In fact, it can be conceptualized as a set of items. For example, an item can be a message, a folder, or contact information, or any other data item to be represented. Each item has a defined type (such as mail, contact, appointment, etc.). The interface for each type of project defines the attributes and actions that can be used for that type of project. A folder item includes a group of items and provides a way to list the items in the folder.

[0105] The connector interface modules 81-83 provide a common way for the UP servlet module 80 to communicate with modules of different vendors/interface connector modules. Some connector modules may only implement a subset of the protocol and/or may only support a single folder (collection) of items, as in the case of POP.

[0106] The basic flow for a typical public format request is as follows. The UP servlet module 80 receives the request, which retrieves or creates the appropriate provider/connection. Then, the UP servlet module 80 calls an appropriate "get folder" or similar function associated with the interface connector module to deliver the target mail system identifier, such as the URL included in the public format request. The interface connection module returns references to some objects that implement the folder interface and represent the requested folder. In its simplest implementation (such as POP), a single object can act as an interface connector module and also represent a mailbox folder.

[0107] The UP servlet module 80 uses the returned folder reference and makes additional calls to satisfy the common format request. For example, if the UP servlet module 80 needs to retrieve a specified item, it can first call the "Get Folder" function and pass the requested URL. After it gets the folder, it will call the "Get Item" function and pass the URL again._OThen, format the result of these calls into an appropriate format, such as XML, and return it in the HTTP response.

[0108] The supplier module/interface connection module will interpret the input URL and return an appropriate reference. This is not complicated because the supplier module/interface connection module provides the URL first. The only URL that any interface connection module needs to know is that all other URLs are generated by the supplier/connection. As long as the URL in the hierarchy/collection is unique, the supplier can resolve the correct item when calling the "get" function.

[0109] The supplier modules 84-86 and the interface connection modules 81-83 preferably support root folders. If only the root folder is supported, and if it can be accessed through the protocol engine, the inbox, calendar, and contact items (appropriately) should be the items in that folder.

[0110] According to an aspect of the present invention, a single and advantageous mechanism for accessing multiple protocols is provided. This mechanism is aimed at client protocols with similar capabilities, supports the full functionality of each data system protocol, and degenerates when the client protocol does not support specific data system protocol features. Before forwarding the request to the destination server, the request received in the public format is translated into a vendor/protocol proprietary format. The vendor/protocol-specific format response from the destination server

Should be translated back to the public format.

[0111] It also provides a mechanism for the client to query the support functions of a specific supplier module, and provides the client with greater control over how to generate a request for a supplier. Any client written to support a common protocol format (directly or through a proxy) can easily provide access to any mail storage, regardless of whether it has the details of the mail storage vendor module/protocol.

[0112] Now, another embodiment of the protocol interface device 14" will be described with reference to FIG. 9. Here, user email account information associated with the email account to be accessed through the protocol interface device 14 is stored in the data In the memory 90". The information for each account preferably includes an indication of the access protocol supported by each email account.

[0113] The records in the data storage 90" can be arranged according to account identifiers, such as email addresses, etc., or according to the user names associated with the protocol interface device 14", so that the data storage 90" will target specific All the user's e-mail account information is grouped together. In the case that the access protocol support is the same for all e-mail accounts on each mail system 24", 26", the information for each account may include an indication that each mail system supports The mail system information of the operating protocol.

[0114] The data storage 91" stores a list of all operating protocols supported by the protocol engine module 32" and a corresponding measure (ie, ranking) indicating the degree of protocol preference. These metrics are calculated based on capacity standards, such as the degree of support of the protocol in the features of each mail system 24", 26" and the security level of the protocol. Other standards can also be used, as known to those of ordinary skill in the art. In the data storage 91", OWA will typically have a higher metric or order than MAPI, and IMAP will generally have a higher order than POP. For example, it can be stored on the local hard disk or other storage at the protocol interface device 14" Each of the data storages 90" and 91" can be implemented in the database or on the file server with which the protocol interface device communicates.

[01 The protocol engine module 32" determines which mailbox or account(s) the command or instruction is related to, and then accesses the information of each account in the data storage 90" to determine whether each account to be accessed supports more than one Access agreement. If only one access protocol is supported, select that protocol. In the case that more than one access protocol is supported for the account, the protocol engine module 32 "accesses the data storage 91" to determine which supported protocol is preferred or required, and selects the supported one with the highest metric or ranking Agreement. For the mail system 24", 0WA is selected over MAPI, and for the mail system 26", IMAP is selected over POP.

[0116] Therefore, the protocol interface device 14" allows the use of the most capable supported protocols to access the mail systems 24", 26". Through the protocol interface device 14", the proxy modules 34", 36", 38", Any one of the 40" compatible clients provides access to one or more mail systems 24", 26". The client itself does not need to support the access protocol or scheme associated with the mail system to be accessed.

[0117] Now, referring to FIG. 9, a method for selecting a data system access protocol using the protocol interface device 14" will be described. Starting at block 160, at block 161, an access command is received from the client. OK (party Block 162) Whether each data system to be accessed in response to the command supports more than one access protocol. If so, the most capable supported protocol is selected at block 164. Otherwise, at block 163, select The only supported protocol. At block 165, each data system is accessed using the selected protocol, thereby ending the method shown at block 166. In the case of more than one data system to be accessed, Preferably, the protocol selection steps shown at blocks 162-164 are repeated for each data system.

[0118] It should be noted that the protocol and measurement data storage 91" is only a typical example of the protocol preference ranking techniques that can be used according to the present invention. For example, the protocol preference may be inherent in the ranking of the list of supported protocols.

[0119] When choosing a protocol, other criteria besides measurement or overall preference may also be considered. The type of client from which the access command is received can also influence the protocol choice. For example, in the case of receiving an access command from a POP client, the various enhanced features supported by OWA cannot be displayed in the POP used to transmit to the device. If the user has only one type of client for accessing the protocol interface device 14", the information of each account can be adjusted to reflect the type of client or limit the list of supported protocols according to the type of client. Otherwise, another option in the protocol selection One step may be to determine the type of client from which the access request is received.

[0120] Optionally, the most capable protocol supported by the data system to be accessed is always selected, and during the translation of the data into the client protocol, any protocol between the selected access protocol and the protocol supported by the client is processed. Incompatibility. Translate part of the data corresponding to the interface protocol elements supported by the client protocol, and ignore or process the unsupported interface protocol elements according to the default or error handling scheme.

[0121] Generally speaking, the client usually accesses the server through a proxy. Moreover, the reaction time is usually positively correlated with the cardinality of the collection to be accessed (for example, the number of email messages in the mailbox to be accessed). As can be seen from the following description, the present invention provides a device and technology that can be used by an agent to provide a client with an illusion that the collection to be accessed is smaller than it actually is. For example, an agent may show only the 100 most recent mailbox cancellation message, while the mailbox itself has 2000+ messages. The present invention advantageously allows this agent to select a smaller subset that can be displayed to the client to replace the entire set without causing a greater impact on the user's experience.

[0122] More specifically, now turning to FIG. 10, another advantageous embodiment of the protocol interface device 14 will be described. Generally speaking, when a data access request is received from the client, the protocol interface device 14 is paid for accessing one or more data systems with a 24 premium and a 26 premium for accessing one or more data systems. However, in some cases, accessing the data system and providing a response to the client may cause a specific client protocol to time out, and the waiting time is longer than expected after the user of the client sends the request. According to this solution of the present invention, specific data can be stored in the protocol interface device 14, which can be used to reduce response time.

[0123] More specifically, the protocol engine module 32 salary polls the data system 24 salary and 26 salary to determine whether it currently stores data items associated with the user who has been configured to access it. . For example, by establishing a user account associated therewith, the user is configured in the protocol interface device 14 premium. Preferably, polling is performed according to the polling interval. The polling interval may be a static predetermined polling interval or an adaptive polling interval that can be adjusted according to operating conditions or the occurrence of a specific event, as known to those of ordinary skill in the art.

[0124] In response to the polling from the protocol engine module 32 premium, the given data system 24 premium, 26 premium returns the data item (or at least the data item identifier that can be used to retrieve the data item) to the protocol interface Equipment 14 salaries. Then, the protocol engine module 32 will store these data items or identifiers in the data storage or memory 92.

[0125] Specifically, the protocol engine module 32 premium can determine whether there is any new data for the user stored in the 24 premium, 26 premium of any data system. For example, in the case that the data system 24 premium and 26 premium are an email system, the protocol engine module 32 premium uses the protocol interface device 14 premium to query the mailbox associated with each user configured for email access. For each mailbox query, the mail system returns at least a list of unique identifiers (UID) associated with the email messages stored in the mailbox.

[0126] Then, the current UID list is compared with the previous UID list for the mailbox in the UID storage 92 to determine whether the new message has been stored in the mailbox of the mail system. If a new message is detected, preferably

CN 1823508 Β

The protocol engine module 32 service and the front-end agent module 30 service (or another component of the protocol interface device 14 service) cooperate to send a warning to the user's client and store the current UID list including the new message in the UID memory 92 Salary in salaries.

[0127] One of the most common data access operations is to view a list of data items currently stored at the data system, especially when the data items are messages stored on the mail system. As described above, the protocol engine module 32 will poll one or more of the data system 24 and 26 to detect new data items based on the UID list stored in the UID memory 92. Therefore, the protocol interface device 14 premium has a local UID list of the data items stored at the 24 premium and 26 premium of the data system when the data system was last polled.

[0128] According to this solution of the present invention, the protocol engine module 32 will retrieve the stored UID list from the UID memory 92 when receiving a "view item" or similar access request. Then, the accurate stored UID list within the current polling interval is returned to the requesting client. This provides a faster response time than the 24 premium and 26 premium for accessing the data system when the request is received, as is well known by those of ordinary skill in the art.

[0129] For example, in the case of a POP client, if a response to the request is not received within 30 seconds, the client times out. In the case of a POP client running on a mobile wireless communication device, the response time within the wireless communication network may cause a delay closely related to this limited response time. In this case, the faster response time associated with providing a list of stored UIDs in response to a data access request is particularly advantageous. Even in the absence of this time constraint, a faster response time will improve the user experience at the client by reducing the waiting time between sending a data access request and receiving a response.

[0130] As described above, the stored UID list is accurate within the polling interval. When the stored UID list is provided to the client in response to the data access request, the protocol engine module 32 pays preferably polls the data system 24 pay, 26 pay to determine whether the stored UID list is still accurate. If a new item has been stored in the data system's 24 salary and 26 salary since the last poll, the new UID list is sent to the client. This further polling for the data system's 24 premium and 26 premium can be performed according to the polling interval or initiated by the data access request.

[0131] It should be clear that the above description relates to "view items" or similar data access requests. Other components or modules of the protocol interface device 14 can process other types of data access requests. For example, as described above, the front-end proxy module 30 will translate these data access requests if necessary.

[0132] Thus, the protocol interface device 14 premium allows access to the 24 premium and 26 premium of the data system, and provides a reduced response time for a variety of data access requests. Through the protocol interface device 14 premium, a client compatible with any protocol processed by the front-end agent module 30 premium is provided with access to one or more of the 24 premium and 26 premium of the data system. The client itself does not need to support the access protocol or scheme associated with the 24 premium and 26 premium of the data system to be accessed, as described above. [0133] Now, referring to FIG. 17, the method of using the protocol interface device 14 to reduce the response time to the data system access request will be described. Starting at block 170, a data access request is received at block 171. Then, at block 172, it is determined whether the data related to the data access request (that is, the UID list) is stored locally. In the case where such data is located in the local memory 92 premium, at block 173, the stored data is provided to the requesting client. After the stored data has been transmitted to the client, or if the data has not been stored, at block 174, poll the data system related to the data access request for a 24 salary and a 26 salary.

CN 1823508 Β

[0134] Then, at block 175, an optional step of determining whether the polling data received in response to the polling is different from the stored data may be performed. If they are different, this means that there is new data stored in the data system 24 premium and 26 premium, and at block 176, the data received in response to the polling is provided to the client. At block 177, it is also stored locally in the data storage 92 salary, thereby ending the method shown (block 178).

[0135] As an example, the data access system and method according to the various aspects of the present invention can be applied to other types of data storage devices other than mail systems, and in addition to the protocols and access schemes described in detail above and shown in the drawings. Other agreements and access plans.

[0136] Additional features of the present invention can be found in the following unauthorized application: COMMUNICATIONS SYSTEM PROVIDING REDUCED ACCESS LATENCY ANDREALTED METHODS, Agent volume number ID-494; COMMUNICATIONS SYSTEM INCLUDING PROTOCOL INTERFACE FOR MULTIPLE OPERATING PROTOCOLSAND RELATED METHODS, agent volume number ID-493 COMMUNICATIONS SYSTEMPROVIDING MULTI-LAYERED EXTENSIBLE PROTOCOL INTERFACE ANDRELATED PROTOCOL INTERFACE ANDRELATED PROMETLATION PROMETLATION PROMETL Agent volume number ID-507 COMMUNICATIONS SYSTEM WITH DATASTORAGE DEVICE INTERFACE PROTOCOL CONNECTORS AND RELATEDMETHODS, agent volume number ID-506; and COMMUNICATIONS SYSTEM PROVIDINGEXTENS IBLE PROTOCOL INTERFACE TRANSLATION AND CONFIGURATION FEATURES AND RELATED METHODS, agent volume ID-502, all of which are publicly available here for reference.

[0137] Example

[0138] In the following example with reference to FIG. 18, a typical handheld mobile wireless communication device 1000 that can be used in the present invention is further described. The device 1000 includes a housing 1200, a keyboard 1400, and an output device 1600. The output device shown is a display 1600, preferably a full graphics LCD. Other types of output devices can also be used. The housing 1200 contains a processing device 1800, which is connected between the keyboard 1400 and the display 1600. The processing device 1800 controls the operation of the display 1600 and the overall operation of the mobile device 1000 in response to the user's touch on the keys on the keyboard 1400.

[0139] The shell 1200 may be longitudinally elongated or may adopt other sizes and shapes (including a clam shell structure). The keyboard may include a mode selection key, or other hardware or software for switching between text input and telephone input.

[0140] In addition to the processing device 1800, other components of the mobile device 1000 are schematically shown in FIG. 18. Including communication subsystem 1001; short-distance communication subsystem 1020; keyboard 1400 and display 1600, and other input/output devices 1060, 1080, 1100 and 1120; and storage devices 1160, 1180 and various other device subsystems 120L. Preferably , The mobile device 1000 is a two-way RF communication device with voice and data communication capabilities. In addition, preferably, the mobile device 1000 has the ability to communicate with other computer systems via the Internet.

[0141] Preferably, the operating system software executed by the processing device 1800 is stored in a permanent memory, such as flash memory 1160, etc., but can also be stored in other types of storage devices, such as read-only memory (ROM) or the like Storage element. In addition, system software, special device applications, or part of them can be temporarily loaded into volatile memory, such as random access memory (RAM) 1180. The communication signal received by the mobile device is also stored in RAM1180. [0142] In addition to its operating system functions, the processing device 1800 can also execute software applications 1300A-1300 on the device 1000 ± a predetermined set of applications (such as data and voice communications 1300A and 1300B) that can control basic device operations during manufacturing. ) Installed on the device 1000. In addition, a personal information manager can be installed during manufacturing

CN 1823508 Β

(ΡΙΜ) application. Preferably, PIM can organize and manage data items such as emails, calendar events, voice mails, appointments, and task items. Preferably, the PIM application can also send and receive data items through the wireless network 1401. Preferably, the PIM data items are seamlessly integrated, synchronized, and updated with corresponding data items of the device user stored or associated with the host system through the wireless network 1401.

[0143] Through the communication subsystem 1001 and possibly through the short-range communication subsystem, communication functions including data and voice communication are performed. The communication subsystem 1001 includes a receiver 1500, a transmitter 1520, and one or more antennas 1540 and 1560. In addition, the communication subsystem 1001 also includes a processing module (such as a digital signal processor (DSP) 1580, etc.) and a local oscillator (L0) The specific design and implementation of the 160L·communication subsystem 1001 depends on the communication network in which the mobile device 1000 will operate. For example, the mobile device 100 may include a communication subsystem 1001 designed to operate with Mobitex Data TACT or a general packet radio service (GPRS) mobile data communication network, and may be designed to communicate with any of a variety of voice communication networks. Perform operations such as AMPS, TDMA, CDMA, PCS, GSM, etc. Other types of data and voice networks (separate and integrated) can also be used with the mobile device 1000.

[0144] Network access requirements vary according to the type of communication system. For example, in the Mobitex and DataTAC networks, mobile devices are registered on the network using a unique personal identification number or PIN associated with each device. However, in a GPRS network, network access is associated with the subscriber or user of the device. Therefore, a GPRS device requires a subscriber identity module, usually called a SIM card, in order to operate on the GPRS network.

[0145] When the required network registration or activation procedures have been completed, the mobile device 1000 may send and receive communication signals on the communication network 1401. The signal received from the communication network 1401 through the antenna 1540 is routed to the receiver 1500, which provides signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog-to-digital conversion. The analog-to-digital conversion of the received signal allows the DSP1580 to perform more complex communication functions, such as demodulation and decoding. In a similar way, the DSP 1580 processes the signal to be transmitted to the network 1401 (such as modulation and coding, etc.), and then provides it to the transmitter 1520 for digital-to-analog conversion, frequency up-conversion, filtering, amplification, and passing through the antenna 1560 is transmitted to the communication network 1401 (or network).

[0146] In addition to processing communication signals, the DSP 1580 provides control of the receiver 1500 and the transmitter 1520. For example, the gain applied to the communication signal in the receiver 1500 and the transmitter 1520 can be adaptively controlled through an automatic gain control algorithm implemented in the DSP 1580.

[0147] In the data communication mode, the communication subsystem 1001 processes the received signals (such as text messages or web page downloads, etc.), and inputs them to the processing device 1800. Then, the processing device 1800 performs further processing on the received signal for output to the display 1600, or instead to some other auxiliary I/O device 1060. The device user may also use the keyboard 1400 and/or some other auxiliary I/O devices 1060 (such as a touchpad, rocker switch, thumbwheel, or some other type of input device) to write data items, such as email messages. Then, the written data item can be transmitted on the communication network 1401 through the communication subsystem 1001.

[0148] In the voice communication mode, the overall operation of the device is substantially similar to the data communication mode, except that the received signal is output to the speaker 1100, and the signal to be transmitted is generated by the microphone 1120. An optional voice or audio I/O subsystem, such as a voice message recording subsystem, can be implemented on the device 1000. In addition, the display 1600 can also be used in the voice communication mode, for example, to display the identity of the calling party, the duration of the voice call, or other voice call related information. The short-range communication subsystem realizes communication between the mobile device 100 and other nearby systems or devices (not necessarily similar devices). For example, the short-range communication subsystem may include infrared devices and related circuits and components, or BluetoothTM communication modules to provide communication with similarly enabled systems and devices.

[0149] Based on the above description and related drawings, those of ordinary skill in the art will be aware of various modifications and other embodiments of the present invention. Therefore, it should be understood that the present invention is not limited to the specific embodiments disclosed herein, but tends to include modifications and embodiments within the scope of the appended claims.

[0150]

[0151]

[0152]

[0153] Computer Sequential List Sequential List #1-Typical Authentication Request

PROPFIND/ups HTTP/1. 1

Depth :0

<td>[0154]</td><td>Brief:t</td>

<td>[0155]</td><td>Pragma:no-cache</td>

<td>[0156]</td><td>Content-Type:text/xml</td>

<td>[0157]</td><td>X_UP_LOGIN:</td>

<td>[0158] svr =</td><td>= login.oscar. aol. com&amp;prt =</td>

<td>******&amp;pwd =</td><td>******&amp;pwp =</td>

<td>[0159]</td><td>X_UP_SYNC:false</td>

<td>[0160]</td><td>X_UP_REFRESH_CACHE:force</td>

<td>[0161]</td><td>X_UP_NEWCON:1</td>

<td>[0162]</td><td>User-Agent: Mozilla/4. 0 (com)</td>

<td>[0163]</td><td>Connection: Keep-Alive</td>

<td>[0164]</td><td>Host:localhost:9080</td>

<td>[0165]</td><td>Content-Length: 664</td>

<td>[0166]</td><td>&lt;? xml version = ^!f 1.0 ?</td>

<td>[0167]</td><td>&lt;D: propfind xmlns:D =</td>

<td colspan="2">microsoft. com/hotmail/^/z</td>

<td>[0168] xmlns</td><td>:hm = urn:schemas:httpmai1:</td>

<td>versalproxy</td><td>&gt;</td>

<td>[0169]</td><td>&lt;D:prop&gt;</td>

<td>[0170]</td><td>&lt;hm:contacts/&gt;</td>

<td>[0171]</td><td>&lt;hm:calendar/&gt;</td>

<td>[0172]</td><td>&lt;hm:journal/&gt;</td>

<td>[0173]</td><td>&lt;hm:notes/&gt;</td>

<td>[0174]</td><td>&lt;hm:inbox/&gt;</td>

<td>[0175]</td><td>&lt;hm:outbox/&gt;</td>

<td>[0176]</td><td>&lt;hm:sendmsg/&gt;</td>

<td>[0177]</td><td>&lt;hm:sentitems/&gt;</td>

<td>[0178]</td><td>&lt;hm:deleteditems/&gt;</td>

<td>[0179]</td><td>&lt;hm:drafts/&gt;</td>

<td>[0180]</td><td>&lt;hm:msgfolderroot/&gt;</td>

<td>[0181]</td><td>&lt;up:corporatecontacts/&gt;</td>

<td>[0182]</td><td>&lt;h:maxpoll/&gt;</td>

5190&amp;ssi = O&amp;pcol = aol&amp;uid; MSIE 5. 5; Windows NT5. 0)&gt;

DAV: xmlns:h = http://schemas.

xmlns: up = ^/z urn: schemas: corp: uni

CN 1823508 Β

[0183] &lt;h: sig/&gt;

[0184] &lt;/D:prop&gt;

[0185] &lt;/D: propf ind&gt;

[0186] HTTP/1. 1 207 Multi-Status

[0187] Set-Cookie: JSESSIONID = C70CD1AED7D2BE210B34D93F7ACD6935: Path = /ups

[0188] Content-Type: text/xml

[0189] Transfer-Encoding: chunked

[0190] Date. Wed, 06 Aug 2003 18:20:28GMT

[0191] Server. Apache Coyote/1. 0

[0192] &lt;? Xml version = ^!f 1.0 encoding = ^!f UTF-8^!f ? &gt;

[0193] &lt;D:multistatus xmlns:D = ^!f DAV: ^!f xmlns:up = ^!f urn: schemas: corp:uni versalproxy^/z

[0194] xm 1 ns: c = u: schemas: calendar: xm 1 ns: a = urn:schemas:contacts:

[0195] xm 1 ns: hm = urn: schemas:httpmail: xm 1 ns: m = urn: schemas:mailheader. ^!f &gt;

[0196] &lt;D: response&gt;

[0197] &lt;D:href&gt;http://localhost9080/ups/&lt;/D:href&gt;

[0198] &lt;D: propstat&gt;

[0199] &lt;D: status&gt;HTTP/l. 1 200 0K&lt;/D. status&gt;

[0200] &lt;D:prop&gt;

[0201] &lt;hm:inbox&gt;http://localhost9080/ups/INB0X/&lt;/hm:inbox&gt;

[0202] &lt;hm:sendmsg&gt;http://localhost9080/ups/AOL_MAIL_SUBMISSION_

URL/&lt;hm:sendmsg&gt;

[0203] &lt;hm:sentitems&gt;http://localhost:9080/ups/Sent

Items/&lt;hm:sentitems&gt;

[0204] &lt;hm:msgfolderroot&gt;http://localhost:9080/ups/&lt;/hm:msgfolderroot&gt;

[0205] &lt;/D:prop&gt;

[0206] &lt;/D: propstat&gt;

[0207] &lt;/D: response&gt;

[0208] &lt;/D: multi status&gt;

[0209] Program List #2-Typical Inbox Request

[0210] Query Folder Capab Subscriptionities

[0211] REQUEST:

[0212] OPTIONS/ups/INBOX/HTTP/1. 1

[0213] User-Agent: Mozilla/4. 0 (compatible; MSIE 5. 5; Windows NT 5.0)

[0214] Connection: Keep-Alive

CN 1823508 Β

<td>[0215]</td><td colspan="2">Host localhost9080</td>

<td>[0216]</td><td>Cookie:JSESSIONID = C70CD1AED7D2BE210B34D93F7ACD6935</td><td></td>

<td>[0217]</td><td>Content-Length:0</td><td></td>

<td>[0218]</td><td>RESPONSE:</td><td></td>

<td>[0219]</td><td>HTTP/1. 1 200 OK</td><td></td>

<td>[0220]</td><td colspan="2">allow: OPTIONS, PROPFIND, MOVE, DELETE, BDELETE, BMOVE, SEARCH</td>

<td>[0221]</td><td>dasl: &lt;urn:schemas:corp universalproxy:basicsearch&gt;</td><td></td>

<td>[0222]</td><td>Content-Type: text/plain</td><td></td>

<td>[0223]</td><td>Content-Length:0</td><td></td>

<td>[0224]</td><td>Date: Wed,06 Aug 2003 18:20:28GMT</td><td></td>

<td>[0225]</td><td>Server: Apache Coyote/1. 0</td><td></td>

<td>[0226]</td><td>List messages in INBOX:</td><td></td>

<td>[0227]</td><td>REQUEST:</td><td></td>

<td>[0228]</td><td>PROPFIND/ups/INBOX/HTTP/1. 1</td><td></td>

<td>[0229]</td><td>Range:rows = 0-24</td><td></td>

<td>[0230]</td><td>Depth:1, noroot</td><td></td>

<td>[0231]</td><td>Brief:t</td><td></td>

<td>[0232]</td><td>Pragma:no-cache</td><td></td>

<td>[0233]</td><td>Content-Type:text/xml</td><td></td>

<td>[0234]</td><td>X_UP_REFRESH_CACHE:force</td><td></td>

<td>[0235]</td><td>User-Agent: Mozilla/4. 0(compatible; MSIE 5. 5; Windows</td><td>NT5. 0)</td>

<td>[0236]</td><td>Connection: Keep-Alive</td><td></td>

<td>[023 knife</td><td>Host localhost :9080</td><td></td>

<td>[0238]</td><td>Cookie:JSESSIONID = C70CD1AED7D2BE210B34D93F7ACD6935</td><td></td>

<td>[0239]</td><td>Content-Length:586</td><td></td>

<td>[0240]</td><td>&lt;? xml version = ^!f 1.0 ? &gt;</td><td></td>

<td>[0241]</td><td>&lt;D:propfind xmins: D = DAV:?</td><td>xm 1 n</td>

s: hm urn:schemas:httpmai1: xmlns:m = urn:schemas:mailheader:

[0242] xmlns:up = ^!f urn: schemas: corp:universalprroxy^!f &gt;

[0243] &lt;D:prop&gt;

[0244] &lt;D:uid/&gt;

[0245] &lt;D: isfolder/&gt;

[0246] &lt;D: ishidden/&gt;

[0247] &lt;hm:read/&gt;

[0248] &lt;hm: hasattachment/&gt;

[0249] &lt;hm: importance/&gt;

[0250] &lt;m: from/&gt;

[0251]

[0252] &lt;m:subject/&gt;

&lt;m:date/&gt;

CN 1823508 Β

<td>[0253]</td><td>&lt;up:isdeleted/&gt;</td>

<td>[0254]</td><td>&lt;D:getcontenttength/&gt;</td>

<td>[0255]</td><td>&lt;D:contentctass/&gt;</td>

<td>[0256]</td><td>&lt;/D:prop&gt;</td>

<td>[0257]</td><td>&lt;/D:propfind&gt;</td>

<td>[0258]</td><td>RESPONSE:</td>

<td>[0259]</td><td>HTTP/1.1207 Multi-Status</td>

<td>[0260]</td><td>Content-Range:rows 0-8:total = 9</td>

<td>[0261]</td><td>Content-Type:text/xml</td>

<td>[0262]</td><td>Transfer-Encoding: chunked</td>

<td>[0263]</td><td>Date:Wed,06 Aug 2003 18:20:28GMT</td>

<td>[0264]</td><td>Server: Apache Coyote/1. 0</td>

<td>[0265]</td><td>&lt;? xml version = ^!f 1.0 encoding</td>

<td>[0266]</td><td>&lt;D:multistatus xmlns:D = ^!f DAV: ^!f</td>

<td colspan="2">p:universalproxy</td>

<td>[0267]</td><td>xmlns:c = urn:schemas:ca</td>

g =^/z UTF-8^/zxmlns:up =?&gt;

utn:schemas:cor endar.

urn:schemas:httpmai1:

=^!f urn: schemas: mai lheader^!f . &gt;

&lt;D:contentrange&gt;0-8&lt;/D:contentrange&gt;

&lt;D:response&gt;

&lt;D:href&gt;http://localhost:9080/ups/INB0X/6623963:1&lt;/D:href&gt; &lt;D:propstat&gt;

&lt;D:status&gt;HTTP/l. 1 200 0K&lt;/D:status&gt;

&lt;D:prop&gt;

&lt;D:uid&gt;3ac59b38c08ad3356435efeal44660e3&lt;/D:uid&gt;

&lt;D:isfolder&gt;0&lt;/D:isfolder&gt;

&lt;D:ishidden&gt;0&lt;/D:ishddden&gt;

&lt;hm:read&gt;0&lt;/hm:read&gt;

&lt;hm:hasattachment&gt;O&lt;/hm:hasattachment&gt; &lt;hm:importance&gt;l&lt;/hm:importance&gt;

&lt;m:from&gt;MaCertainlyDelivery Subsystem&lt;. MAILER-DAEMON@ao1.

= urn:schemas:contacts: xmlns:hm

[0268] xmlns :m

[0269]

[0270]

[0271]

[0272]

[0273]

[0274]

[0275]

[0276]

[0277]

[0278]

[0279]

[0280]

[0281] com&gt;&lt;/m:from&gt;

[0282]

[0283]

[0284]

[0285]

[0286]

D:contentclass&gt;

[0287] &lt;/D:prop&gt;

&lt;m:subject&gt;Retumed mail: User unknown&lt;/m:subject&gt;

&lt;m:date&gt;2003-08-05T23:12:48Z&lt;/m:date&gt;

&lt;up:isdeleted&gt;O&lt;/up:isdeleted&gt;

&lt;D:getcontentlength&gt;3247&lt;/D:getcontentlength&gt;

&lt;D:contentclass&gt;urn:content-classes:message&lt;/

/D:propstat &lt;/D:response&gt; &lt;D:response&gt;

&lt;D:href&gt;http://localhost:9080/ups/INBOX/6623954:1&lt;/D: href&gt;

D:propstat &lt;D:status&gt;HTTP/l. 1 200 0K/D:status &lt;D:prop&gt;

&lt;D:uid&gt;51073b22a28c2820115bc80d42e8c6ec&lt;/D:uid&gt;

&lt;D:isfolder&gt;0&lt;/D:isfolder&gt;

&lt;D:ishidden&gt;O&lt;/D:ishidden&gt;

&lt;hm:read&gt;1&lt;/hm:read&gt;

&lt;hm:hasattachment&gt;0&lt;/hm:hasattachment&gt; &lt;hm:importance&gt;l&lt;/hm:importance&gt;

&lt;m:from&gt;johnsmith@demo. com&lt;/m:from&gt;

&lt;m:subject&gt;Re:Test#l-All-French template&lt;/m:subject&gt;

&lt;m:date&gt;2003-08-05T2310:30Z&lt;/m:date&gt;

&lt;up:isdeleted&gt;0&lt;/up:isdeleted&gt;

D:getcohtentlength1577/D:getcontentlengthD:contentclassurn:content-classes:message/

[0288]

[0289]

[0290]

[0291]

[0292]

[0293]

[0294]

[0295]

[0296]

[0297]

[0298]

[0299]

[0300]

[0301]

[0302]

[0303]

[0304]

[0305]

[0306]

D:contentclass&gt;

[0307]

[0308]

[0309]

[0310]

[0311]

[0312]

[0313]

[0314]

[0315]

[0316]

[0317]

[0318]

[0319]

[0320]

[0321]

[0322]

[0323]

[0324]

[0325] &lt;/D:prop&gt;

&lt;/D:propsta&gt; &lt;/D:response&gt; &lt;D:response&gt;

&lt;D:href&gt;http://localhost:9080/ups/INBOX/6623926;1&lt;/D: href&gt;

D:propstat &lt;D:status&gt;HTTP/l. 1 200 OK/D:status &lt;D:prop&gt;

&lt;D:uid&gt;b072c3748ceffl320f9fa746f797e64b&lt;/D:uid&gt;

&lt;D:isfolder&gt;0&lt;/D:istolder&gt;

&lt;D:ishidden&gt;0&lt;/D:ishidden&gt;

&lt;hm:read&gt;1&lt;/hm:read&gt;

&lt;hm:hasattachment&gt;O&lt;/hm:hasattachment&gt; &lt;hm:importance&gt;l&lt;/hm:importance&gt;

&lt;m:from&gt;johnsmith@demo. com&lt;/m:from&gt;

&lt;m:subject&gt;Re:xxxFWD:Re:Test#l&lt;/m:subject&gt;

&lt;m:date&gt;2003-08-05T23:07:18Z&lt;/m:date&gt;

&lt;up:isdeleted&gt;0&lt;/up:isdeleted&gt;

D:getcontentlength1927/D:getcontentlength

CN 1823508 Β

[0326] &lt;D:contentclass&gt;urn:content-classes:message&lt;/

D:contentclass&gt;

<td>[0327][0328][0329][0330][0331]</td><td>&lt;/D:prop&gt;&lt;/D:propstat&gt;&lt;/D:response&gt;&lt;D:response&gt;&lt;D:href&gt;http://localhost9080/ups/INB0X/6623922:1&lt;/D:href&gt;</td>

[0332] &lt;D: propstat&gt;

[0333] &lt;D:status&gt;HTTP/l. 1 200 0K&lt;/D:status&gt;

<td>[0334][0335][0336][0337][0338][0339]</td><td>&lt;D:prop&gt;&lt;D:uid&gt;llflc8e69555d33971aeal2c09be5021&lt;/D:uid&gt;&lt;D:isfolder&gt;0&lt;/D:isfolder&gt;&lt;D:ishidden&gt;O&lt;/D:ishidden&gt; &lt;hm:read&gt;l&lt;/hm :read&gt;&lt;hm:hasattachment&gt;0&lt;/hm:hasattachment&gt;</td>

[0340]

[0341]

[0342] &lt;hm:importance&gt;l&lt;/hm:importance&gt;

&lt;m:from&gt;johnsmith@demo. com&lt;/m:from&gt;

&lt;m:subject&gt;Re:xxxFWD:Re:Test#l&lt;/m:subject&gt;

[0343] &lt;m:date&gt;2003-08-05T23:06:45Z&lt;/m:date&gt;

[0344]

[0345]

[0346] &lt;up:isdeleted&gt;0&lt;/up:isdeleted&gt;

&lt;D:getcontentlength&gt;1930&lt;/D:getcontentlength&gt;

&lt;D:contentclass&gt;urn:content-classes:message&lt;/

D:contentclass

<td>[0347][0348][0349][0350][0351]</td><td>&lt;/D:prop&gt;&lt;/D:propstat&gt;&lt;/D:response&gt;&lt;D:response&gt;&lt;D:href&gt;http://localhost:9080/ups/INB0X/6623915; 1&lt;/D:href&gt;</td>

[0352] &lt;D: propstat&gt;

[0353] &lt;D:status&gt;HTTP/l. 1 200 0K&lt;/D:status&gt;

<td>[0354][0355][0356][0357][0358][0359]</td><td>&lt;D:prop&gt;&lt;D:uid&gt;55bc30adfb4fb66f3d 11 b04 16c82b701&lt;/D:uid&gt;&lt;D:isfolder&gt;0&lt;/D:isfolder&gt;&lt;D:ishidden&gt;O&lt;/D:ishidden&gt;&lt;hm:read&gt;l &lt;/hm:read&gt;&lt;hm:hasattachment&gt;l&lt;/hm:hasattachment&gt;</td>

[0360]

[0361]

[0362] &lt;hm:importance&gt;l&lt;/hm:importance&gt;

&lt;m:from&gt;johnsmlthOdemo. com&lt;/m:from&gt;

&lt;m:subject&gt;xxxFWD:Re:Test#l&lt;/m:subject&gt;

[0363]

[0364]

[0365]

[0366]

[0367]

[0368]

[0369]

[0370]

[0371]

[0372]

[0373]

[0374]

[0375]

[0376]

[0377]

[0378]

[0379]

[0380]

[0381]

[0382]

[0383]

[0384]

[0385]

[0386]

[0387]

[0388]

[0389]

[0390]

[0391]

[0392]

[0393]

[0394]

[0395]

[0396]

[0397]

[0398]

[0399]

[0400]

[0401] &lt;m:date&gt;2003-08-05T23:05:27Z&lt;/m:date&gt; &lt;up:isdeleted&gt;0&lt;/up:isdeleted&gt;

&lt;D:getcontentlength&gt; 3254&lt;/D:getcontentlength&gt; &lt;D:contentclass&gt;urn:content-classes:message&lt;/D:contentclass&gt; &lt;/D:prop&gt;

/D:propstat &lt;/D:response&gt;

&lt;D:response&gt;

&lt;D:href&gt;http://localhost:9080/ups/INBOX/6623910:1&lt;/D:href&gt; D:propstat &lt;D:status&gt;HTTP/l. 1 200 0K/D:status &lt; D:prop&gt;

&lt;D:uid&gt;07cdf24a06f8e849754f90fe6dc8bf4f&lt;/D:uid&gt;

&lt;D:isfolder&gt;0&lt;/D:isfolder&gt;

&lt;D:ishidden&gt;O&lt;/D:ishidden&gt;

&lt;hm:read&gt;l&lt;/hm:read&gt;

Hm:hasattachment0/hm:hasattachment &lt;hm:importance&gt;l&lt;/hm:importance&gt;

&lt;m:from&gt;johnsmith@demo. com&lt;/m:from&gt;

&lt;m:subject&gt;Re:Test#l-All&lt;/m:subject&gt;

&lt;m:date&gt;2003-08-05T23:04:31Z&lt;/m:date&gt;

&lt;up:isdeleted&gt;0&lt;/up:isdeleted&gt;

&lt;D:getcontentlength&gt;1258&lt;/D:getcontentlength&gt;

&lt;D:contentclass&gt;urn:content-classes:message&lt;/D:contentclass&gt; &lt;/D:prop&gt;

/D:propstat &lt;/D:response&gt;

&lt;D:response&gt;

&lt;D:href&gt;http://localhost9080/ups/INBOX/6623909 ;1&lt;/D:href&gt; D:propstat &lt;D:status&gt;HTTP/l. 1 200 0K/D:status &lt;D: prop&gt;

&lt;D:uid&gt;0e79a3593253ffb9596bf9d86873f498&lt;/D:uid&gt;

&lt;D:isfolder&gt;0&lt;/D:isfolder&gt;

&lt;D:ishidden&gt;O&lt;/D:ishidden&gt;

&lt;hm:read&gt;1&lt;/hm:read&gt;

&lt;hm:hasattachment&gt;0&lt;/hm:hasattachment&gt; &lt;hm:importance&gt;l&lt;/hm:importance&gt;

&lt;m:from&gt;johnsmith@demo. com&lt;/m:from&gt;

[0402]

[0403]

[0404]

[0405]

[0406]

[0407]

[0408]

[0409]

[0410]

[0411]

[0412]

[0413]

[0414]

[0415]

[0416]

[0417]

[0418]

[0419]

[0420]

[0421]

[0422]

[0423]

[0424]

[0425]

[0426]

[0427]

[0428]

[0429]

[0430]

[0431]

[0432]

[0433]

[0434]

[0435]

[0436]

[0437]

[0438]

[0439]

[0440] &lt;m:subject&gt;Re:Test#l&lt;/m:subject&gt;

&lt;m:date&gt;2003-08-05T23:04:13Z&lt;/m:date&gt;

&lt;up:isdeleted&gt;0&lt;/up:isdeleted&gt;

&lt;D:getcontentlength&gt;1241&lt;/D:getcontentlength&gt;

&lt;D:contentclass&gt;urn:content-classes:message&lt;/D:contentclass&gt; &lt;/D:prop&gt;

/D:propstat &lt;/D:response&gt;

&lt;D:response&gt;

&lt;D:href&gt;http://localhost:9080/ups/INBOX/6605332; 1&lt;/D:href&gt;

D:propstat &lt;D:status&gt;HTTP/l. 1 200 0K/D:status &lt;D:prop&gt;

&lt;D:uid&gt;6060b944e60256c814498af29e5f0e47&lt;/D:uid&gt;

&lt;D:isfolder&gt;0&lt;/D:isfoider&gt;

&lt;D:ishidden&gt;O&lt;/D:ishidden&gt;

&lt;hm:read&gt;0&lt;/hm. read&gt;

&lt;hm:hasattachment&gt;0&lt;/hm:hasattachment&gt; &lt;hm:importance&gt;l&lt;/hm:importance&gt;

&lt;m:from&gt;aolmbrsecurity@aol. com&lt;/m:from&gt;

&lt;m:subjec&gt;Security Notice to AOL Members&lt;/m:subject&gt;

&lt;m:date&gt;2003-08-01T23:00:58Z&lt;/m:date&gt;

&lt;up:isdeleted&gt;0&lt;/up:isdeleted&gt;

D:getcontentlength5137/D:getcontentlength &lt;D:contentclass&gt;urn:content-classes:message&lt;/D:contentclass&gt; &lt;/D:prop&gt;

/D:propstat &lt;/D:response&gt;

&lt;D:response&gt;

&lt;D:href&gt;http://localhost:9080/ups/INBOX/6567082; 1&lt;/D:href&gt;

D:propstat &lt;D:status&gt;HTTP/l. 1 200 0K/D:status &lt;D:prop&gt;

&lt;D:uid&gt;f47b72c8claa91458f40f8 lfce3b5eO5&lt;/D:uid&gt;

&lt;D:isfolder&gt;0&lt;/D:isfolder&gt;

&lt;D:ishidden&gt;O&lt;/D:ishidden&gt;

&lt;hm:read&gt;0&lt;/hm:read&gt;

&lt;hm:hasattachment&gt;0&lt;/hm:hasattachment&gt; &lt;hm:importance&gt;l&lt;/hm:importance&gt;

CN 1823508 Β

[0441]

[0442]

[0443]

[0444]

[0445]

[0446]

[0447]

[0448]

[0449]

[0450]

[0451]

[0452]

[0453]

[0454]

[0455]

[0456]

[0457] &lt;m:from&gt;aolmemberinfo@aol. com&lt;/m:from&gt;

&lt;m:subject&gt;Corning Soon-AOL 9. 0 Optimized&lt;/m:subject&gt;

&lt;m:date&gt;2003-07-25T21:15:22Z&lt;/m:date&gt;

&lt;up:isdeleted&gt;0&lt;/up:isdeleted&gt;

&lt;D:getcontentlength&gt;10012&lt;/D:getcontentlength&gt;

&lt;D:contentclass&gt;urn:content-classes:message&lt;/D:contentclass&gt; &lt;/D:prop&gt;

/D:propstat &lt;/D:response&gt;

/D:multistatus Stalk sequence table #3-typical folder search request

Capabilities of folder:

REQUEST:

OPTIONS/ups HTTP/1. 1

User-Agent:Mozilla/4. 0(compatible; MSIE 5. 5; Windows NT5. 0) Connection: Keep-Alive

Host:localhost:9080

[0458] Cookie:JSESSIONID=C70CD1AED7D2BE210B34D93F7ACD6935

[0459] Content-Length:0

[0460] RESPONSE:

[0461] HTTP/1. 1200 OK

[0462] allow:OPTIONS, PROPFIND, MOVE, DELETE, BDELETE, BMOVE, SEARCH

[0463] dasl:&lt;urn:schemas:corp:universalproxy:basicsearch&gt;

[0464] Content-Type:text/plain

[0465] Content-Length:0

[0466] Date:Wed,06 Aug 2003 18:20:28 GMT

[0467] Server: Apache Coyote/1. 0

[0468] Search for folders:

[0469] REQUEST:

[0470] SEARCH/ups HTTP/1. 1

[0471] Depth:1, noroot

[0472] Brief, t

[0473] Pragma: no-cache

[0474] Content-Type: text/xml

[0475] User-Agent: Mozilla/4. 0 (compatible; MSIE 5. 5; Windows NT 5.0)

[0476] Connection: Keep-Alive

[0477] Host localhost: 9080

[0478] Cookie:JSESSIONID=C70CD1AED7D2BE210B34D93F7ACD6935

[0479] Content-Length:922

[0480] &lt;? Xml version = ^!f 1.0 ? &gt;

[0481] &lt;D: searchrequest xmlns:D = ^!f DAV: ^!f xmlns: t = ^!f urn: schemas: corp: un iversalproxy^/z &gt;

[0482]

[0483]

[0484]

[0485]

[0486]

[0487]

[0488]

[0489]

[0490]

[0491]

[0492]

[0493]

[0494]

[0495]

[0496]

[0497]

[0498]

[0499]

[0500]

[0501]

[0502]

[0503]

[0504]

[0505]

[0506]

[0507]

[0508]

[0509] iversalproxy^/z

[0510] xm 1 ns: c = urn:schemas:contacts:

[0511]

[0512]

[0513]

[0514]

[0515] &lt;t:basicsearch&gt;

&lt;D:select&gt;

&lt;D: propXD: uid/X/D: prop&gt;

&lt;D: propXD: contentclass/X/D: prop&gt;

&lt;D: propXD: displayname/X/D: prop&gt;

&lt;/D:select&gt;

&lt;D:from&gt;

&lt;D:scope&gt;

&lt;D:href&gt;url&lt;/D:href&gt;

&lt;D:depth&gt;l&lt;/D:depth&gt;

&lt;/D:scope&gt;

&lt;/D:from&gt;

&lt;D:where&gt;

&lt;D:eq&gt;

&lt;D: propXD: contentclass/X/D: prop&gt;

&lt;D:literal&gt;urn:content-classes: mail ifolder&lt;/D:literal&gt; &lt;/D:eq&gt;

&lt;/D:where&gt;

&lt;/t:basicsearch&gt;

&lt;/D:searchrequest&gt;

RESPONSE:

HTTP/1. 1 207 Multi-Status Content-Type:text/xml

Transfer-Encoding: chunked

Date:Wed,06 Aug 2003 18:20:28 GMT

Server: Apache Coyote/1. 0 &lt;? Xml version &lt;D:multistatus

1.0 encoding =^/z UTF-8^/z ? &gt;

xmlns:D = ^!f DAV: ^!f xmlns:up = ^!f urn: schemas: corp: un urn: schemas: calendar. xm 1 ns: a xmlns:hm = urn:schemas:httpmai1:

xmlns:m = urn:schemas:mailheader:&gt;

&lt;D:responss&gt;

&lt;D:href&gt;http://localhost:9080/ups/INB0X/&lt;/D:href&gt; &lt;D:propstat&gt;

&lt;D:status&gt;HTTP/l. 1 200 0K&lt;/D:status&gt;

[0516]

[0517]

[0518]

D: contentclass&gt;

[0519]

[0520]

[0521]

[0522]

[0523]

[0524]

[0525]

[0526]

[0527]

[0528]

[0529]

D:contentclass&gt;

[0530]

[0531]

[0532]

[0533]

[0534]

[0535]

[0536]

[0537]

[0538] &lt;D:prop&gt;

&lt;D:uid&gt;c90d66b2362ala0bc3dfl852021a6f63&lt;/D: uid&gt;

&lt;D:contentclass&gt;urn:content-classes:mailfolder&lt;/ D:displaynameINBOX//D:displayname &lt;/D:prop&gt;

/D:propstat &lt;/D:response&gt;

&lt;D:response&gt;

&lt;D:href&gt;http://localhost:9080/ups/VOICE-MAIL/&lt;/D:href&gt;

D:propstat &lt;D:status&gt;HTTP/l. 1 200 0K/D:status &lt;D:prop&gt;

&lt;D:uid&gt;cabbce34709ab79d2ad2d5334d998272&lt;/D:uid&gt;

&lt;D:contentclass&gt;urn:content-classss:mailfolder&lt;/ D:displaynameVOICE-MAIL/D:displayname &lt;/D:prop&gt;

/D:propstat &lt;/D:response&gt;

/D:multistatus Program list #4-Typical configuration file &lt;resgirce contentclass = urn:content-classes:mailfolder javaclass = com. teamon. proxy, data. impl. MailFolderdmpl

<td>[0539]</td><td>responsecacheduration = 0</td>

<td>[0540]</td><td>cachestrength = ^!f 0 &gt;</td>

<td>[0541]</td><td>&lt;request method = ^!f PROPFIND^!f &gt;</td>

<td>[0542]</td><td>&lt;header name = ^!f Brief^/z value = ^!f t /&gt;</td>

<td>[0543]</td><td>&lt;header name = ^!f Content-Type^/z value = ^!f text/xml^!f /&gt;</td>

<td>[0544]</td><td>&lt;header name = ^!f Depth^/z valua = ^!f 1, noroot /&gt;</td>

<td>[0545]</td><td>&lt;header name = Range value = rows</td>

<td colspan="2">$rangeStart$-$rangeEnd$ /&gt;</td>

<td>[0546]</td><td>&lt;header name = ^!f Pragma^!f value = ^!f no-cache /&gt;</td>

<td>[0547]</td><td>&lt;header name = ^!f X_UP_REFRESH_CACHE^!f value = ^!f force^/z /&gt;</td>

<td>[0548]</td><td>&lt;body&gt;&lt;I[CDATA[</td>

<td>[0549]</td><td>&lt;? xml version =^!f 1.0 ? &gt;</td>

<td>[0550]</td><td>&lt;D:propfind</td>

[0551] xmlns:D = DAV:

[0552]

[0553]

[0554]

[0555]

[0556]

[0557]

[0558]

[0559]

[0560]

[0561]

[0562]

[0563]

[0564]

[0565]

[0566]

[0567]

[0568]

[0569]

[0570]

[0571]

[0572]

[0573] xmlns:hm = urn:schemas:httpmai1:

xmlns:m = urn:schemas:mailheader:

xmlns:up = urn:schemas:teamon:universalproxy&gt;

&lt;D:prop&gt;

&lt;D:uid/&gt;

&lt;D:isfolder/&gt;

&lt;D:ishiden/&gt;

&lt;hm:read/&gt;

&lt;hm: hasattachment/&gt; &lt;hm:importance/&gt;

&lt;m:from/&gt;

&lt;m:subject/&gt;

&lt;m:date/&gt;

&lt;up:isdeleted/&gt;

&lt;D:getcontentlength/&gt; &lt;D:contentclass/&gt;

&lt;/D:prop&gt;

&lt;/D:propfind&gt;

]]&gt;

&lt;/body&gt;

&lt;/request&gt;

&lt;/resource&gt;

CN 1823508 Β