Patent Application
20080215684
The present invention relates to a wireless e-mail system and method for using same. In particular the present invention relates to an e-mail system comprised of an e-mail client which communicates with one or more e-mail servers via a gateway.
As known in the art, e-mail systems typically store e-mail messages on an e-mail server in mail boxes associated with a particular e-mail address or user. Internet Message Access Protocol (IMAP) and Post Office Protocol Version 3 (POP3) are well known standardised client/server protocols designed to operate over TCP/IP. Additionally, a variety of proprietary protocols, such as MSN Hotmail®, etc. are also known in the art for doing the same. These protocols allow Mail User Agents (MUAs) or e-mail clients to examine, manipulate and retrieve e-mail messages stored in mail boxes on an e-mail server. However, although the way in which these protocols are used to manipulate the e-mail messages stored on their respective e-mail servers is well defined, the way in which the e-mail messages are retrieved and displayed to the user is non-standardised. In particular, the sequence of transactions or commands defined in the protocols and which must be exchanged between MUA and e-mail server in order to effect a transfer of message related data, as well as the content and user interface which is presented to the user, are not standardised. In order to present the content to the end-user via standard protocols such as IMAP and POP3, or via proprietary protocols such as Hotmail's MSP, the MUA or client must retrieve the message related data from the e-mail server, and process the data to present it in the desired format. As these protocols were typically designed for use over broadband networks, they are very chatty and as a result, examining, manipulating and retrieving e-mail messages stored in mail boxes on an e-mail server typically requires a significant number of transactions, processing and memory usage on the part of the e-mail client.
POP3, for example, and as described in RFC 1939 the entire contents of which is incorporated herein by reference, provides a limited command set allowing an e-mail client to download a simple list (limited to a reference number and the size of the e-mail in octets) of e-mail messages stored in a mail box on the server, download messages individually using the reference number, or delete a message using the reference number. However, in order for the e-mail client to present a list of e-mails to a user, for example via a display screen or the like, the e-mail client must first download the messages, extract particular fields from the messages (for example the sender and subject) and compile these into a suitable page of information for display to the user.
IMAP, on the other hand and as described in RFC 3501 the entire contents of which is incorporated herein by reference, presents a much richer command set. For example, the FETCH command may be used to retrieve only portions of a series of messages, such as the headers, flags, etc., without requiring the entire messages to be downloaded. As a result, the MUA can be more selective at the outset in determining message related data to be retrieved from the IMAP server, thereby reducing somewhat, at least at an initial step, the amount of data which must be transferred between server and MUA.
IMAP and POP3 compatible e-mail clients are already implemented on a number of wireless mobile devices, allowing these wireless mobile devices to retrieve, transmit and otherwise manipulate e-mail message through direct interaction with the e-mail server. Additionally, web-portal based e-mail, such as that provided by Yahoo! and Hotmail, are also available on wireless mobile devices using Wireless Application Protocol (WAP) browsers. However, the use of chatty e-mail protocols (such as IMAP, POP3, Simple Message Transfer Protocol (SMTP) or other proprietary e-mail protocols) with clients implemented on wireless mobile devices to interface directly with an e-mail server results in a number of significant drawbacks. In particular, as such wireless devices are typically constrained by memory size, processing capabilities as well as the speed of any data interconnection, interfacing directly with such e-mail servers results in high latencies, increased battery consumption and large memory requirements. Furthermore, cellular wireless networks typically impose that radio channels be assigned to the wireless mobile devices for data transactions, rather than to make use of random access channels, which consumes network capacity. In addition, the above channel assignment process takes time, which also adds to latency. Ideally, a minimum amount of channel assignments should be made.
One additional drawback with implementing a e-mail client on wireless mobile devices which communicates directly with the e-mail server is that data traffic related to examining, manipulating or retrieving e-mail messages stored in mail boxes on an e-mail server appears in the mobile network simply as data traffic, and is not distinguishable from other types of data traffic, such as for example data traffic related to web browsing or the like. As a result, mobile operators are typically unable to monitor the usage or to provide specific subscriptions based on such e-mail services.
The above drawbacks are in part a consequence of the design of the described e-mail protocols, which were conceived primarily for use over broadband networks where latency is low, bandwidth relatively cheap and network availability high. Furthermore, IMAP and POP3 amongst other e-mail protocols have been designed to expect the use of a relatively powerful smart (thick) e-mail client (such as that available on a PC) which is able to cope with large amounts of complex data which, given the limited resources, are not readily available with most wireless mobile devices.
In order to address the above and other drawbacks there is provided a wireless e-mail system. The system comprises a wireless mobile device comprising an e-mail client, an e-mail server, a gateway, a wireless network interconnecting the wireless mobile device and the gateway, and a broadband network interconnecting the gateway and the e-mail server. When the client transmits a single self-contained request to the gateway via the wireless network to retrieve a set of e-mail related information from the e-mail server, the gateway retrieves at least the e-mail related information from the e-mail server via the broadband network using a plurality of transactions, compiles the retrieved information into a single self contained response and transmits the single response via the wireless network to the e-mail client.
Additionally, there is disclosed a gateway interconnecting a wireless mobile device and an e-mail server, the wireless mobile device comprising an e-mail client and adapted for data communication with a wireless network, the e-mail server adapted for data communication with a broadband network. The gateway comprises a first stateless interface interconnected with the wireless network, a second interface interconnected with the broadband network, and a channel management function. When the e-mail client transmits a single self-contained request to the first interface via the wireless network to retrieve a set of e-mail related information from the e-mail server, the channel management function retrieves at least the e-mail related information from the e-mail server via the second interface and the broadband network using a plurality of transactions, compiles the retrieved information into a single self contained response and transmits the single response via the first interface and the mobile network to the e-mail client.
There is also disclosed a method for retrieving e-mail related information from an e-mail server via a communications system comprising a wireless network and a broad band network. The method comprises the steps of, in a client e-mail application, forming a single request for the e-mail related information, transmitting the single request to a gateway via the wireless. network, the gateway downloading at least the e-mail related information from the server via the broadband network using a plurality of transactions. The gateway compiles the retrieved information into a single response, transmitting the single response to the client application via the wireless network, and in the client application, retrieving the e-mail related information from the response.
Furthermore, there is disclosed a method for retrieving e-mail related information from an e-mail server via a communications system comprising a wireless network and a broad band network. The method comprises the steps of providing an e-mail gateway comprising a first stateless interface interconnected with the wireless network and a second interface interconnected with the broadband network, in a client e-mail application, transferring a single request for the e-mail related information to the first interface via the wireless network, in the gateway receiving the request at the first interface, retrieving at least the requested e-mail related information from the server via the broadband network using a plurality of transactions; compiling the retrieved information into a single response and transmitting the single response to the client application via the first interface and the wireless network and in the client application, retrieving the e-mail related information from the response.
Also, there is disclosed a method for logging e-mail data traffic between at least one wireless mobile device comprising a client e-mail application and an e-mail server interconnected by a wireless mobile operator network and a broadband network, the mobile network comprised of a wireless network and a ground network, the wireless network interconnecting the at least one wireless mobile device and the ground network and wherein the e-mail data traffic comprises at least one request for e-mail related information generated by the client e-mail application. The method comprises the steps of providing an e-mail gateway between the ground network and the broadband network, for each request generated by the client e-mail application, transferring the request to the gateway via the wireless network, in the gateway receiving each request, logging each received request, retrieving at least the requested e-mail related information from the e-mail server, compiling the retrieved information into a single response, logging the single response and transmitting the single response to the client application via the wireless network.
Other objects, advantages and features of the present invention will become more apparent upon reading of the following non-restrictive description of illustrative embodiments thereof, given by way of example only with reference to the accompanying drawings.
Reference will now be made to the accompanying drawings, showing by way of illustration an illustrative embodiment of the present invention, and in which:
Referring now to
Referring to
Referring now back to
Referring back to
The e-mail client application 40 is illustratively implemented as a JAVA™ midlet which runs on a virtual JAVA machine (not shown) provided by mobile device 12. As known in the art, JAVA applications typically have access to a variety of different services, such as communications, via a JAVA Application Programming Interface (API). Illustratively, one of these services is an HTTP stack for providing communications via the mobile operator network 14, but other stacks, such as TCP or WAP, may also be provided in particular implementation.
The mobile operator network 14 is a network supporting wireless data communication based on GSM, CDMA2000, UMTS, or other such systems. The mobile operator network 14 provides the wireless data communication system (dashed lines) between the various wireless mobile devices 12 and the landline network (solid lines) connecting the various e-mail servers 18 of each service provider 20.
The e-mail service providers 20 and their respective e-mail servers 18 support standard or proprietary e-mail signalling protocols such as IMAP, POP3, Hotmail's MSP, or other such protocols for the management and retrieval of e-mail, as well as standard or proprietary signalling protocols, such as SMTP, Hotmail's MSP or other such protocols for sending e-mail. E-mail service providers may include, but are not limited to, Yahoo! Mail, AOL Mail, Hotmail, or any other common consumer-based Internet Service Provide (ISP) e-mail servers such as POP or IMAP, web-based e-mail providers or corporate e-mail providers. The e-mail servers 18 in the illustrated embodiments operate as they would with standard communications established by prior art wired and wireless devices. However, although the e-mail client application 40 may be implemented using a standard protocol (for example communicating over HTTP), its implementation will be executed in a unique way. For example, if a mail is deleted by the end user, it may or may not be required that the e-mail client application 40 move the e-mail to the “Deleted Items” folder. In this regard, the transactions used in the protocol are standard, but the sequence of the transactions and the overlying structure of the e-mail client application 40 may be unique depending on the implementation.
Illustratively, the primary functions of the e-mail gateway 16 are to offload processing and signalling for e-mail access from multiple wireless mobile devices, as in 12, onto an external platform which forms part of the wired (typically broadband) network (solid lines in
In particular, referring to function (E) above, the gateway may contain configuration options to allow for different behaviour based on mobile operator preferences or on limitations of a specific wireless mobile device 12. The configurable options may comprise:
Referring now to
Referring now to
Still referring to
Note that, in a particular embodiment using HTTP to transmit requests for e-mail related information between the e-mail client application 40 and the gateway 16, Cookies can be taken advantage to store some of the information necessary for completing a transaction. As known in the art, an HTTP server, when returning an HTTP object to a HTTP client, may also send information which the client will store (referred to generally as a Cookie). Any future HTTP objects sent by the client may include a transmittal of the information from the HTTP client back to the HTTP server. In this regard, when the e-mail client application 40 initially transmits a request for e-mail related information to the gateway 16 using HTTP, the gateway 16 (which is also an HTTP server and can thus take advantage of Cookies) may return a Cookie in a subsequent response. In particular, as known in the art, certain e-mail servers
Still referring to
Conversely, interface B can be any interface supported by the various e-mail providers, namely those using such signalling protocols as IMAP, SMTP, POP3 and other common standardised or proprietary protocols, and use multiple transactions 56 in order to complete a single request 58, as common with such protocols. Necessarily, the implementation of the Interface B processor 44 is largely dependent on the particular e-mail service provider 20 the gateway 16 is requested to interact with.
As the gateway 16 is used to complete wireless e-mail transactions requested by an end user using a wireless device 12, the present e-mail system 10 provides a means for the mobile network operator to distinguish e-mail data traffic from other data traffic, such as for example data related to web browsing or the like. This provides for a number of advantages including billing and subscription capabilities which would otherwise be unavailable.
Referring back to
Referring now to
As discussed above, interface A is a request/response interface with the request originating from the e-mail client application 40. The e-mail client application 40 initiates a request via interface A using a format which allows it to retrieve the information it requires to be displayed in a single request/response pair. However, unlike standard e-mail protocols which require multiple transactions and significant processing on the part of the client to extract the required information, interface A allows for a single transaction (or request/response pair) 54 between the e-mail client application 40 and the gateway 16 for each request. As each request is self-contained, there is no need for user-specific information, such as filters, to be stored on the gateway 16. The system performs a transfer of a subset of the data as requested by the user using a single stateless request/response pair 54, illustratively using HTTP objects, for each of the transactions initiated by the e-mail client application 40. Consequently, the e-mail client application 40 is not required to maintain a persistent session with the e-mail server 18, or the gateway 16, in order to initiate subsequent mobile client transactions, as is required for example by IMAP or POP3.
Furthermore, in a particular implementation the e-mail client application 40 can be configured such that each time the e-mail client application 40 is launched it retrieves the most recent e-mail related information via interface A, and as a result the wireless mobile device 12 need not keep persistent storage of the user data (e-mail messages) in memory for extended periods of time. Subsequently, data can be fetched just-in-time for each user request. On the other hand, although no sessions are required between the e-mail client application 40 and the gateway 16 for communication purposes, a session may optionally be used to allow for additional security, for example use of HTTPS between the e-mail client application 40 and the gateway 16.
Transactions between client 40 and gateway 16 may be generally grouped into one of three categories: one for alerts and notifications (see Table 1 below), one for requests for e-mail related information retrieval (see Table 2 below) and the other for requests for sending or modifying e-mail related information (see Table 3 below). Furthermore, as discussed hereinabove, interface A also allows for the piggybacking of multiple requests in a single request/response pair. In practice, interface A may be implemented using an Extensible Mark up Language (XML) structure or SyncML, though other similar structures may also be used. Specific examples of such commands will be discussed further hereinbelow with reference to Tables 1, 2 and 3.
Referring now back to
In Tables 1, 2 and 3, illustrative embodiments of primitives for communication between the e-mail client application 40 and the gateway 16 via interface A are shown. System primitives are relayed from the gateway 16 to the e-mail client application 40 and comprise primarily alerts as to the presence of new e-mail and services and the like (Table 1). This is typically information sent to the e-mail client application 40 without a specific request for the information being received from the e-mail client application 40. Client primitives are grouped into two categories: one for retrieval of e-mails and related content (Table 2), and the other for sending e-mails or modifying related content (Table 3). Each request results in a response (not shown). Necessarily, the content of Interface A may include other components not listed here, without departing from the general concept provided by the wireless e-mail system 10.
As mentioned hereinabove, interface A also includes a response primitive, which occurs for each request generated by the e-mail client application 40. Furthermore, while a single request-response transaction 54 is required and used through interface A to communicate with the gateway 16, multiple transactions 56 through interface B may be used between the gateway 16 and the e-mail server 18 to gather all of the e-mail related information requested by the e-mail client application 40 without generating any latency and/or bandwidth concerns in the system 10. Additionally, and as also discussed hereinabove, in order to reduce data traffic the system primitives are typically piggybacked onto responses which generated are by the gateway 16 in response to each message request received from the e-mail client application 40.
Referring now to
The wireless e-mail transaction starts with a user input at step 64, for example by requesting a particular e-mail for reading or retrieving a list of e-mails available on the server (see Table 2 for other examples of e-mail related information which can be retrieved).
In the following step 66, the e-mail client application 40 of the user's wireless device 12 requests the gateway 16 to either fetch, process, or send a specific set of information (including forward and reply requests) based on the user action of step 64 using the protocol of interface A. This request is sent. over the wireless network as a single self-contained request.
Referring now to
Referring back to
Referring back to
Referring back to
Referring back to
Referring now to
Referring now to
As will now be apparent to a person of skill in the art, the wireless e-mail system 10 described herein allows for low cost thin e-mail client applications 40 to access e-mail via a wireless network. Additionally, the e-mail client applications 40 can be branded to reflect the look and feel of the e-mail service provider 20 the user has selected (for example Hotmail, Yahoo! Mail, AOL Mail or other such e-mail services). The e-mail client applications 40 requires only minimal resources, but can still provide a “PC-like” experience to the end user which is a significant improvement over that offered for example over WAP, which has until now been the typical approach to e-mail on low end and mid range devices.
Referring now to
Again, a thin client approach as illustrated herein allows offloading of processing and signalling to a broadband network that is relatively unconstrained by speed of transmission and other limitations such as memory or battery life. Consequently, the wireless e-mail system 10 reduces latencies and battery consumption as less signalling and processing are required of the mobile device 12. Furthermore, the use of a single just-in-time requesvresponse pair for each query makes much more efficient use of the wireless interface thus minimizing radio use and fragmentation. The resulting traffic flow is consistent with user requests, queries and general use of the system, making service costs transparent and understandable. Finally, the system 10 allows for monitoring and billing of the e-mail service by the mobile operator 14.
While this invention has been described with reference to the illustrative embodiments, this description is not intended to be construed to a limiting sense. Various modifications or combinations of the illustrative embodiments, as well as other embodiments of the invention, will be apparent to persons skilled in the art upon reference to the description. It is therefore intended that the described invention encompass any such modifications or embodiments.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2,493,907 | Jan 2005 | CA | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/CA06/00086 | 1/24/2006 | WO | 00 | 5/17/2006 |
| Number | Date | Country | |
|---|---|---|---|
| 60645614 | Jan 2005 | US |
