EP1618719A1 - A data access, replication or communication system comprising a message queuing communications platform - Google Patents
A data access, replication or communication system comprising a message queuing communications platformInfo
- Publication number
- EP1618719A1 EP1618719A1 EP04728198A EP04728198A EP1618719A1 EP 1618719 A1 EP1618719 A1 EP 1618719A1 EP 04728198 A EP04728198 A EP 04728198A EP 04728198 A EP04728198 A EP 04728198A EP 1618719 A1 EP1618719 A1 EP 1618719A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- message
- session
- server
- data
- messages
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Definitions
- This invention relates to a data access, replication or communication system comprising a message queuing communications platform.
- TCP/IP session based transport protocols
- TCP/IP has many advantages, in that it gives a reliable connection.
- the TCP algorithm was developed for a wired connection with relatively low latency and presents challenges in some networks, such as wireless networks. For example, in areas of poor coverage the available wireless bandwidth reduces and this is compounded by TCP which assumes the network is congested and "backs off.
- TCP Transmission Control Protocol
- a TCP connection over a cellular wireless network is not an efficient transport. It results in a large overhead of re-sent packets leading to slow and cosdy data transfers.
- These disadvantages apply also to wired networks, although arguably less forcefully.
- the overwhelming technical bias runs in favour of session based protocols and, as a consequence, data access, replication or communication systems have therefore traditionally relied on session based protocols.
- the present invention envisages a data access, replication or communication system comprising a message queuing communications platform that enables delivery of a message over a network to be reliable, even if an unreliable transport protocol is used, in which the platform operates in a session independent manner.
- Session based systems tear down a session in various situations (e.g. when data transfer rates fall below a threshold or there is a period of inactivity (a timeout) or there is a change in PDP context such as switching from internet browsing to media messaging) and then initiate a new session. This may happen frequently (particularly in a GPRS or UMTS wireless network due to the highly variable bandwidth and high latency associated with these kinds of networks). It requires the exchange of data traffic, which is costly if users pay for the amount of data transmitted.
- a 'session independent' platform however does not deliberately tear down a connection if data rates fall because of network performance in order to re-establish a new session with better performance.
- a session independent communications platform accepts the inevitable connection constraints of the network and addresses them in ways which do not require the high overhead tearing down and re-establishing sessions, as occurs in prior art systems. (We distinguish here the situation where the system releases the current underlying PDP context for use by other applications, or the current underlying PDP context is lost or otherwise times out. The system merely suspends communication activity pending re-acquisition of a PDP context — the system does not need to re-establish a "session", as such and is hence still session-independent).
- the system whilst itself session independent, may well use low level protocols such as PDP that are session dependent. But in a conventional system, session dependency is a property that permeates up from the lowest level (e.g. PDP) right up to the highest level, the program the user interacts with.
- session dependency is a property that permeates up from the lowest level (e.g. PDP) right up to the highest level, the program the user interacts with.
- network congestion can trigger a time out in a session based system, with effects felt at the highest application level (e.g. a web browser will simply freeze).
- a very high data overhead is incurred in tearing down and re-establishing a session; that may be acceptable where the priority is to have a network with reliability achieved through diverse routings (the core design requirement behind TCP) That requirement does not apply to all networks however, especially wireless networks.
- the communications platform because it is session independent, is itself unaffected by network vagaries that would in the prior art lead to session tear-down; the platform also insulate
- a key element in achieving this is combining session independence with a message queuing system.
- the communications platform may then provide communications services to a program running on a wireless terminal, in which the program can also operate in a session independent manner because it sends messages using the message queuing system of the communications platform to insulate the program from the state or performance of the network connection.
- an end-user can continue to use the terminal device irrespective of the state or performance of the network: he remains insulated from that.
- the same insulation can apply to a program running on a server that the wireless terminal communicates with.
- session independence in combination with a message queuing system directly addresses many connection constraints, particularly (but not solely) the connection constraints affecting wireless networks (namely variable bandwidth, high latency, unreliable coverage, unpredictable disconnections, and the need to minimise data traffic to reduce end user cost).
- each message that is queued defines part or all of an 'event', in which an event describes a change to the data stored at either the wireless terminal or server; and data replication is achieved by sending events (rather than the conventional approach to data replication, requiring a complete dataset of stored data for synchronisation to be sent over an uninterrupted session for synchronisation against another complete dataset).
- the queued events persist in non- volatile memory until positive confirmation that they have been successfully received and processed and are hence also session independent. This approach is not synchronisation as such since there is no guarantee that terminal and server side initialise with the same datasets: event based data replication simply (and reliably) replicates changes across datasets.
- the transport protocol that is used may be unreliable and may also be session independent (at least at its higher levels — at the lowest level, it is likely to be session based, such as PDP); the features of a session based protocol are then provided by the communications platform itself. (Whilst a reliable protocol could be used, that introduces unnecessary extra layers and hence overhead since reliability will duplicate the reliability provided by the communications platform itself). Placing the features onto the communications platform gives an opportunity to design solutions that fully meet (a) the connection constraints identified above (variable bandwidth, high latency, unreliable coverage, unpredictable disconnections, the need to minimise data traffic to reduce cost) but (b) also terminal resource constraints — particularly important where the terminal is a resource (CPU, memory) constrained wireless device such as a smartphone.
- a resource CPU, memory
- the present invention is not limited in application to such devices and covers any kind of data access, replication or communication system (e.g. PC based as well) using any kind of network (e.g. wire-based).
- the features of a session based protocol that are provided by the communications platform may be one or more of:
- Each message sent from a queue is acknowledged as received and separately acknowledged as processed or consumed by the application making use of the communications platform to give reliability at the individual message level and not at a level which is associated with a superset of messages, such as a session.
- Authentication of a sender occurs at an individual message level by the communications platform and not at a level associated with a superset of messages, such as a session.
- ° Messages are encrypted individually and not solely at a level associated with a superset of messages, such as a session, by the communication platform using a key derived from a cryptographically strong hash function derived from one or more of the following inputs:
- a flow control algorithm is applied by the communications platform that optimises the useful data rate by progressively increasing or decreasing the data rate until the useful data rate peaks/in which the algorithm measures and alters the flow rate of packets to optimise the flow rate to the available bandwidth and not to determine when to terminate and re-establish a new session. .
- the communications platform enables the correct routing of messages addressed to the ID of a wireless terminal by mapping that ID to the actual dynamic address needed to reach the wireless terminal.
- the address might, for example, be a dynamic IP address allocated by a NAT box or similar device and the communications platform only initiates a message transfer if there exists a 'valid' mapping.
- a mapping is refreshed to create a valid mapping whenever a specific kind of small, dedicated message (referred to later as a 'Network Update') is received from the wireless terminal.
- a 'Network Update' Whenever a valid mapping exists, any queued events at either the terminal side or server side of the message queuing system are automatically sent: hence, automatic, timely, background data replication is achieved.
- a sending component simply re-starts sending as soon as it knows how to address its messages to the receiving component of the distributed client.
- This is especially useful in the wireless context since a wireless device does not (unless and until IPv6 is available) have a permanent IP address at all, but instead can only receive IP based messages via an arbitrarily selected IP address that is frequently changed.
- session independence fits well the requirements of sending messages to wireless devices with transitory address, yet with the minimum of overhead needed to cope with these changing addresses, since it avoids the overhead of session re-establishment.
- An advantage of this session independent approach is that, if a connection break occurs, the communication platform allows the next message, in a sequence of related messages held in a message queue, that has not been acknowledged as processed or consumed to be sent as soon as the appropriate message address is known and the connection is re-established, and does not require the entire sequence of related messages to be re-sent, as a session based system would.
- the unreliable transport is selected from the following list of transport protocols: UDP/IP; IP; raw GPRS; raw UMTS; raw Ethernet; ATM.
- UDP is the transport protocol and the network is a GPRS network, in which UDP packet size is sized to be no larger than the path MTU (Maximum Transfer Unit) of IP over GPRS.
- MTU Maximum Transfer Unit
- the communications platform is used by a software application that is distributed across a wireless-terminal-side component running on a wireless terminal and a server-side component; in which the wireless-terminal-side component and the server-side component (i) together constitute a client to a server and (ii) collaborate by sending messages over a network using the message queuing system provided by the communications platform.
- the present invention will be described with reference to an implementation from Psion Digital Limited of London, United Kingdom.
- the implementation comprises a middleware communications platform called MobileMQTM and a distributed application layer called Transcend MailTM.
- Transcend Mail is an end-to-end GPRS-connected application that runs on (i.e. is distributed across both) a SymbianOSTM smartphone wireless terminal and a Windows
- MobileMQ is a message-oriented middleware platform that is again distributed across both the smartphone and the server. It provides the GPRS-efficient, reliable and secure means of communication that enables many aspects of Transcend Mail's user experience. MobileMQ can be used wherever there is a requirement for remote data access, replication or communication over a network (whether wired or wireless). MobileMQ uses an unreliable underlying transport protocol that is session independent.
- Transcend Mail allows mobile workers to access their company email, contacts and calendar entries from their Symbian-based GPRS smartphones. It is designed to meet three needs of the mobile worker:
- Transcend Mail enables the following features:
- the Transcend Mail application that serves as the client in a client-server configuration (for example, in a Microsoft Exchange environment) into component parts that run on two or more physical devices that communicate with each other over a wide area connection using the MobileMQ message oriented middleware.
- the component parts collectively act as a client in a larger client-server arrangement, with the server being the Exchange mail server.
- the server being the Exchange mail server.
- a core advantage of the Distributed Client model is that it allows a terminal, such as mobile device with limited processing capacity, power, and connectivity, to enjoy the functionality of full-featured client access to a server environment using minimum resources on the mobile device by distributing some of the functionality normally associated with the client onto the server side, which is not so resource constrained. But unlike other distributed models, in Transcend Mail, each component part can provide functionality (that goes beyond merely accessing cached/stored data) independently of the other, even when the network connection is absent.
- a conventional distributed client such as e-mail web access using a web browser and a web server distributed client accessing a Microsoft Exchange mail server
- a web server distributed client accessing a Microsoft Exchange mail server
- the browser has no functionality, other than to continue to display any cached e-mails.
- Transcend Mail the user experience of using the e-mail or PIM (contacts, calendar) applications on the smartphone is exactly the same, whether there is a connection or not. The user can continue to create e-mails, edit contacts etc. on his smartphone.
- the user is insulated from the state of the network connection because the terminal can queue messages, using MobileMQ (and its own queue as well if the MobileMQ queue is full), until such time as the connection is re-established and can then automatically send the next queued message. Similarly, the next queued message stored server-side can be automatically sent when the connection is re-established. .
- the Distributed Client model directly address not only the problem of providing a good user experience at the terminal (e.g. always able to interact with his contacts, calendar, and e-mail applications, irrespective of network coverage) despite the terminal having major resource constraints and despite the connection having major constraints. This is schematically illustrated in Figure 1.
- the MobileMQ message oriented middleware (MOM) communications platform enables the component parts to effectively and efficiently store messages to be sent between component parts and actually send them reliably.
- the MobileMQ MOM enables message delivery over a network to be reliable, irrespective of whether the underlying transport protocol used is reliable or not; and independent of any session.
- the transport protocol is therefore referred to as 'session independent'. This again marks a major departure from normal networking protocols, such as WAP, which are session based.
- 'Session independent' (as noted earlier) therefore stands in contrast to session based. Session based protocols tear down a session when data transfer rates fall below a threshold or after a timeout.
- a session independent protocol however does not deliberately tear down a connection. (We distinguish here situations where the underlying PDP context is merely released or reassigned for use by other applications, or the current underlying PDP context is lost or otherwise times out. In these types of cases, the higher layer session-independent protocol merely suspends communication activity pending re- acquisition of a PDP context — it does not need to re-establish a 'session', as such.)
- a sending component simply re-starts sending as soon as it knows how to address its messages to the receiving component of the distributed client.
- This is especially useful in the wireless context since a wireless device does not (unless and until IPv6 is available) have a permanent IP address at all, but instead can only receive IP based messages via an arbitrarily selected IP address that is frequently changed.
- session independence fits well the requirements of sending messages to wireless devices with transitory address, yet with the minimum of overhead need to cope with these changing addresses, since it avoids the overhead of session re-establishment.
- Transcend Mail also adopts 'event' based data replication — i.e. a log is kept of all new events which define a change to the data stored on the client or the server sides and only these events are queued in a log.
- a connection is established between each side of the distributed client, then each queued event (as represented by one or more message depending on the complexity of the event) is sent, with a single message being carried by one or more packets.
- MobileMQ allows the efficient and reliable transfer of messages, it is particularly well matched to an event based data replication system, which itself requires no more than the efficient and reliable transfer of messages.
- the higher level applications using the MOM have no awareness of connection status — i.e.
- MobileMQ is a MOM layer that insulates applications using MobileMQ from needing to be aware of the existence or non-existence of an underlying connection (such as an active PDP context).
- the system is 'connection independent'.
- the term 'session independent' therefore equates at the application layer conceptually to a system in which there is a single session that persists independently of whether an actual connection is established or not in the sense that, when a connection is reestablished after a break, an application can re-commence message transfer at exactly the same place where it ceased — i.e. the next message sent by an application is the same message that would have been sent had there been no connection break. In session based systems, that does not happen.
- MobileMQ MOM when combined with Transcend Mail is a comprehensive and effective solution to the twin problems of efficiently handling terminal resource and connection constraints, as shown in Figure 3.
- Figure 4 shows how the combined design allows session independent features provide by the MOM that would normally be provided by a session based system to be deployed in a manner that is fit for the purpose of resource constrained terminals, such as smart phones. These features include:
- the purpose of the distributed client is to allow a mobile device with limited processing capacity, power, and connectivity, to enjoy the functionality of full-featured client access to a server environment using minimum resources on the mobile device by distributing some of the functionality normally associated with the client onto the server side, which is not so resource constrained.
- the client applications are PIM (calendar, address book etc.) and messaging (e-mail, MMS, fax, SMS etc).
- a typical configuration is to install software on a mobile device such as a smart phone (the small client) and corresponding software on a server device (the small server). These two pieces of software communicate with one another — normally over high latency, low bandwidth, metered wireless connectivity such as GPRS or UMTS, via a MOM, such as MobileMQ.
- the small client and small server collectively act as a client (the "large client” or “distributed client”) in a traditional client-server environment.
- the large client then communicates with the relevant server such as Microsoft Exchange (the large server) as normal.
- Microsoft Exchange the large server
- the large client appears to the large server like any other client with which it normally communicates and the distributed nature of the large client is invisible to the large server. (In a typical configuration, it is assumed that the small server will reside on or near the same device where the large server resides.) Figure 5 schematically illustrates this.
- the small client residing on the mobile device i.e. Transcend Mail, in this case working in conjunction with the local e-mail application
- Transcend Mail in this case working in conjunction with the local e-mail application
- the small client undertakes the following functions:
- the small server resides on other media (typically a LAN connected to the large server) and communicates with the mobile device via a data network connection that traverses wireless infrastructure (e.g. GPRS) and generally acts as the direct interface to the large server (such as Microsoft Exchange) and undertakes many data processing tasks normally associated with the large client.
- wireless infrastructure e.g. GPRS
- the small server undertakes the following functions:
- the Transcend Mail small server and the small client communicate with one another via the MobileMQ MOM.
- This enables the unusual feature of the small server and small client (which together constitute the large client in a distributed client server system) to operate asynchronously of one another.
- the small client could be implemented as a terminal-side component, that either includes or communicates with a client side MOM; the Small Server can then be implemented as a server-side component, that either includes or communicates with a server side MOM.
- Figure 7 shows how the Small Client can include a program — e.g. an e-mail application, plus plug-in linking it to the terminal-side component.
- a program e.g. an e-mail application, plus plug-in linking it to the terminal-side component.
- Figure 8 shows that the Small Client can also exclude the program, e.g. a contacts program.
- the terminal side component then communicates with the contacts program via the contacts database (with event triggers from that database being sent to the terminal side component).
- Figure 9 shows how this is conceptually equivalent to a middleware architecture.
- the distributed client splits the logon function between the small client and the small server.
- the small client obtains the user password from end user input.
- the small client Upon receipt of the password input, the small client sends this data to the small server.
- the small server retains this data locally in memory, and then communicates the logon to the large server.
- Transcend Mail acts as the wireless terminal user's agent on the server; it caches passwords and does other logon-related acts that are normally done by a user when interacting with the mail server. Only when a password is time expired by the mail server administrator will a user therefore need to personally log in again with the new password. This is a big improvement in security over other mail redirection methods which require to log on as a super-user which can access all email accounts.
- Another advantage of distributing the logon in this fashion is that it allows the distributed client to continue communication with the large server without additional logon activity (and associated wireless data traffic) even if there is an interruption in communication between small server and small client.
- This also allows possession and use of the mobile device (which may have its own security protocols) to serve as a substitute for additional large server logon activity.
- Once the small server has the password information it becomes possible to replicate logons to the large server based on the assumption that control of the mobile device serves as a kind of substitute for logon information.
- This allows the distributed client to access the large server after an interruption in service without prompting the user for additional password data.
- This provides advantage by reducing data traffic associated with logon activity, and also speeds up end user access to the large server, particularly on mobile devices with small keyboards that are inconvenient for entering password data.
- Transcend Mail also minimises use of wireless transmission by employing a method of constructing messages remotely.
- the distributed client "retrieves" messages from the large server, some of this data is queued at the small server and the small server then determines how much of this data is sent to the small client.
- the specific amount of data sent to the small client can be influenced by end user configuration and by specific request. For example, the end user can specify a maximum number of lines of email text are delivered to the small client, and the end user can then request that the small server send additional text and/or attachments.
- Remote message construction comes into play when the end user directs an action such as replying to or forwarding an email.
- the small server When forwarding an email with an unmodified attachment, the small server is able to construct the bulk of the email message locally without the need for full transmission from the small client.
- the queued message simply references the relevant unmodified data held on the large server (in this example, an attachment).
- the small client is only required to transmit that part of the message that has been modified by the user at the small client device.
- email replies The small client does not need to transmit the entire body of the original message — the small server constructs the total reply by taking new text transmitted from the small client to the small server and combining this with the original email text — already known to the small server since it is stored on the large server.
- the small client has issued an instruction that results in the small server constructing the total message taking parts from both the small client and the large server. Avoiding unnecessary key input is valuable for a small keyboard smartphone. These are both methods for dramatically reducing the amount of data traffic between the small client and the small server.
- Transcend Mail also helps to conserve memory on the mobile device using an automated memory "tidying" function.
- the small client monitors use of non-volatile memory on the mobile device. When non-volatile memory in use exceeds a trigger amount (for example, 80% of memory capacity in use) then it automatically starts to "tidy" the local data related to email information on the device. This consists of selecting certain emails which have not been accessed locally for a longer period of time and releasing from local memory much of the data associated with these emails (for example, attachments and message text), whilst retaining the email header information in local memory.
- the data released from local memory is selected using pre-set criteria such as age of the relevant email message (oldest first) or history of access by the user to this email; email messages not accessed for long periods of time are removed from local memory before newer or recently accessed email messages.
- Message data is not released from memory if the relevant message is marked as unread, open for user viewing or action, or there is a pending action related to the email requesting additional data from the large server. This removal process continues until the small client detects that non-volatile memory in use has descended below a pre-set "safe" level (for example, 70% of memory in use). The email data is not "deleted” as the large server retains all email data and the small client retains email header data.
- a pre-set "safe” level for example, 70% of memory in use
- the removed data can be replaced in local memory by downloading it once again from the server to the mobile device on user request (a 'Retrieve' action).
- the user is clearly warned before such a Retrieve takes place. This allows the user an opportunity to decide whether or not Retrieving the message data is cost effective.
- the tidy function also includes safety mechanisms that handle the circumstance where a particularly large email or attachment might push the mobile device beyond the trigger point for tidying without an opportunity to review the downloaded.
- the design is meant to avoid a circumstance where the mobile device might remove email data before it is read.
- the system temporarily adjusts the trigger level and the safe level of memory use to allow the end user an opportunity to review the large in-bound email.
- a perennial difficulty in mobile devices that share replicated data with a server is how the user can make best use of the limited memory and processing capacity on the mobile device.
- this problem has traditionally been addressed (in MS ActiveSync and others) through limiting the amount of email data that is shared with the mobile device. This limitation usually takes the form of replicating only limited number of days of email data, and limiting the size of the email data shared.
- One common method of limiting the amount of data replicated is to withhold email attachments from replicating on the mobile device. Typically, the end-user may then request the attachment if they are willing to suffer the delivery time and memory overhead involved.
- Other systems have produced a method of sending only a limited form of attached files to the user which can then be used on a simple viewer program.
- Transcend Mail provides the end-user with two options for downloading email ' attachments to the mobile device. If the user wishes to download the attachment, he or she can choose between downloading:
- a smaller version of the file translated from its original form e.g., a text-only version of an MS Word or PDF file
- a simple viewer program resident on the wireless terminal e.g., a text-only version of an MS Word or PDF file
- Protocols like TCP rely upon the concept of a communications "session" with a server. A session typically will expire if no traffic passes for a defined period of time (a time out). Establishing each new session requires use of additional data traffic and is also time consuming.
- MobileMQ envisages a wireless optimised alternative to TCP using only raw UDP packet transfers.
- MobileMQ delivers UDP based messages between (1) a mobile device using a wireless network and (2) a server in communication with that device (whether or not directly connected to the wireless network), so as to minimise wasted data traffic as a result of the high latency intermittent connectivity.
- MobileMQ focuses upon providing a high level of resilience in the message transmission process, effectively guaranteeing message delivery.
- the invention provides a method of guaranteeing that messages are properly delivered both to the destination device and to the destination application, while minimising the amount of data traffic transmitted. This has the added benefit of assuring a high degree of resilience with a minimum of data traffic.
- MobileMQ is distributed in that it resides on both a sending device and receiving device, typically facilitating message traffic from other systems on the same hardware platforms.
- the sending device takes a Message — the core transmission unit — from the sending application (for example, an email program).
- Each Message is restricted to a maximum size intended to optimise use of data traffic.
- the sending application asks the system to send a Message
- the system first persists (stores) the Message in local non-volatile memory at the sending device. This assures Message survival even if the sending device suffers a reset.
- the Message is then compressed and optionally encrypted.
- the Message is then segmented for transmission.
- Each each segment is positioned in a UDP packet with the intention that each packet does not exceed a relatively short byte length, which is related to the underlying transport protocol of the low bandwidth high latency network.
- the UDP packet length might be restricted to 1500 bytes as 1500 bytes is the typical maximum payload in a GPRS packet. Otherwise if a UDP packet were to occupy, say, 2 GPRS fragments, then a failure of one GPRS packet would mean that both GPRS packets would have to be re-sent. MobileMQ avoids this by scaling the message to match that of the bearer packet.
- Both segment size and transmission rate are controlled by a flow control system that analyses traffic to and from the sending device and strikes a balance between transmission speed and total number of bits transmitted in an effort to keep transmission cost-effective.
- UDP packets can be received in any order by the receiving device, and the receiving device transmits a packet acknowledgement following receipt of each packet.
- the flow-control system delays packet retransmission until a reasonable period has elapsed. The precise length of the delay depends upon network response times observed by the flow control system at the sending device. The delay period and packet size are both continuously recalculated based on changes in observed return times. If a packet acknowledgement is received within a predefined time, the flow control progressively increases the data rate until it peaks.
- the flow control system also serves as a replacement for the normal concepts of "session” and "timeout” often used in data transmission devices. If one of the communicating devices suffers a significant connectivity failure (which could arise, for example, due to moving out of range of a wireless base station or moving between roaming networks) the flow control mechanism interprets this as increasingly slow network response, and steps down transmission rates accordingly. If the service outage continues, the flow control continues to lengthen the period between "retries”. The net effect is that transmission efforts come — almost — to a complete stop until the sending device starts to receive return traffic from the receiving device. As more reply packets make their way back from the receiving device to the sending device the process reverses: the flow control system starts to "wake up” and becomes more adventurous in its willingness to transmit packets.
- MobileMQ does not rely upon the concept of "session” and does not recognise the concept of a "timeout”.
- the receiving device Following receipt of all packets that comprise a Message, the receiving device transmits a brief acknowledgement that the entire Message has been received. Once this Message acknowledgement reaches the sending device, the sending device will not attempt any further resends of packets that made up the Message — even if individual packet acknowledgements have not been sent to or received by the sending device. This is primarily intended to restrict the amount of data traffic. The Message delivery sequence is not yet complete.
- the receiving device After transmitting the Message received acknowledgement, the receiving device then passes the Message to the relevant destination application (such as an email program). The receiving device then awaits a signal from the destination application that the relevant Message has been received and processed in accordance with whatever rule set is employed by the receiving application. The intention is that the receiving application processes the received Message so that it will survive a breakdown in the receiving device — such as a system reset. Once the receiving application is satisfied that it has received the Message irretrievably from MobileMQ, the receiving application then responds with final confirmation that the application has "consumed" the Message. This final confirmation from the receiving application triggers the receiving device side of MobileMQ to send a brief "Message Consumed" acknowledgement to the sending device.
- the relevant destination application such as an email program.
- the receiving device awaits a signal from the destination application that the relevant Message has been received and processed in accordance with whatever rule set is employed by the receiving application. The intention is that the receiving application processes the received Message so that it will survive a breakdown in
- the sending device receives the "Message Consumed" acknowledgement, it forwards this information to the sending application and then prepares to transmit the next available Message from the sending application. In this way, MobileMQ guarantees delivery of the entire Message before accepting any additional Message traffic from a sending application.
- MobileMQ is able to process Messages from multiple applications simultaneously, but will not process more than one Message from the same application simultaneously.
- Synchronisation between servers and mobile devices traditionally takes place using relatively high bandwidth, low latency, un-metered connectivity (e.g., USB or IR).
- un-metered connectivity e.g., USB or IR
- server based dataset synchronisation typically requires all connected devices to download their entire datasets (e.g. all e-mails, all contacts etc) to the server over a single session, which can then perform a comparison against its master copy of the last fully synchronised dataset in order to update the master and hence all other datasets.
- This approach is unattractive for synchronising wireless devices because of the power drain it imposes, the potentially long connection time and costly data transfer.
- Transcend Mail instead of a wireless device downloading its entire dataset, it records only dataset changes (or new 'events') into log (preferably, but not necessarily, time sequential) and sends a log of these events to the server when connected to it.
- An event gives enough detail to enable data replication to take place without the need for a synchronisation engine; data replication (as opposed to true synchronisation) is more simply achieved by sending events rather than a complete dataset (or sub-sets of a dataset) of stored data for synchronisation by a synchronisation engine at the small server.
- the event might be 'delete record no. x', or delete field 'y' in record V. This is enough information for the recipient to replicate the change that occurred at the sender that generated the event.
- the sending device when data subject to replication is entered, modified, or deleted (on either the large server or the small client) the sending device creates and logs an "event" on the sending device.
- the event is sent as one or more messages to the receiving device; messages are sent using UDP packet transfer and not the more conventional TCP.
- TCP provides a reliable connection and is currently a focus of commercial activity, it is not (as explained above) an efficient transport for wireless because of its pronounced back-off during times of perceived network congestion, which arises not infrequently when wireless coverage is poor, leading to a large overhead of re-sent packets, leading to slow and costly data transfers.
- UDP is used (see above) with UDP packet size restricted to 1400 bytes, - just under the transmission packet size available in GPRS.
- the receiving device passes individual messages defining the Event to the relevant destination application (such as an email program).
- the sending device then awaits a signal from the destination application that the relevant message[s] defining the Event has been received and processed in accordance with whatever rule set is employed by the receiving application.
- the intention is that the receiving application processes the received message[s] so that it will survive a breakdown in the receiving device — such as a system reset.
- the receiving application responds with final confirmation that the application has "consumed” the messages. This final confirmation from the receiving application triggers the receiving device side to send a brief "Message Consumed" acknowledgement to the sending device.
- the sending device receives the "Message Consumed” acknowledgement, it repeats the process for all messages defining an Event until it has been safely received and 'consumed' at the receiving device. It then concludes the "event” process by deleting [event instruction information?] from sending device memory. It repeats this process for all other events in the Event log or queue.
- Transcend Mail guarantees delivery of the entire message before accepting any additional message traffic from a sending application. Processing messages from multiple applications simultaneously is possible, but not processing more than one message from the same application simultaneously.
- An entire Event can therefore be sent reliably over a wireless link, despite the use of unreliable UDP.
- each Message [from an application] is transmitted by the sending device with alternating A or B flags.
- the receiving device starts to receive the Message, it writes the A or B flag to local memory.
- the receiving device Upon receiving the complete 1 Message from the sending device and the consumed signal from the destination application, the receiving device writes to local memory the flag identity of the Message just processed before transmitting the Message done / Message consumed acknowledgement. If the receiving device resets after sending a Message done/consumed acknowledgement signal but before an acknowledgment is received back, then it will not know if the message consumed was properly received or not.
- a flag of X signals the receiving device to ignore the flag and no flag is written to receiving device memory. The intention is for a transmitting application to use the X flag if the application is unconcerned about the risk of duplicate message transmission.
- Sending a data transmission to a mobile device on many current mobile data networks is made difficult because the mobile device has no fixed IP address. Instead, when the mobile device connects to a network (either the home network or a roaming network) the network operator dynamically allocates an IP address to the device. Further, this dynamically allocated address is usually a private IP address and not directly usable on the public Internet.
- NAT Network Address Translator
- a mobile device Even if a mobile device retains the same dynamically allocated IP address and ephemeral port number for a longer period (e.g., many hours), it might make use of multiple "public" IP addresses and ephemeral port numbers allocated by the network operator. Further, although the mobile device is aware of the private IP address allocated to it by the network operator it will have no record of the public IP address and ephemeral port number allocated by the NAT. From the perspective of anyone communicating with the mobile device, they will "see” only the public IP address and ephemeral port number allocated by the NAT.
- MobileMQ provides the small server with network address data on a regular basis to enable routine transmissions of, messages from the small server to the mobile device. Examples of implementations would include enabling an office email server to send email traffic to a mobile user without intervention by the mobile user.
- the method involves sending an extremely short message (a TSIetwork Update') from the mobile device to the small server upon the occurrence of any of the following events:
- a TSIetwork Update' an extremely short message
- the small server Upon receipt of the short Network Update message, the small server notes the originating IP address and ephemeral port number of the packet (which will be the assigned public IP address and ephemeral port number from the NAT, assuming that the interested party is not directly connected to the same private IP network) and enters this information in a reverse lookup table.
- the Network Update messages are intentionally short due to the assumption that data traffic is charged on a metered basis.
- a typical implementation might involve only 17 bytes of data transmitted by the mobile device and 5 bytes returned in each Network Update message cycle (assuming no packet loss).
- the small server is then able to attempt its own — unprompted — data transmissions to the small client on the mobile device by using the most recent address for the device found in the reverse lookup table, assuming that the allocated public IP address and ephemeral port number has not been reallocated from the time of the Network Update message.
- receipt at the small server of the Network Update message from a device acts as the trigger to start sending any events queued in the event log (see Event Based Data Replication section 3.9).
- the system can be configured so that only events present in the log at the time the Network Update is received are sent; any later events have to wait until the next Network Update is received. This differs from continuous push e-mail.
- the entry in the reverse lookup table is also timed, and if more than a certain amount of time has elapsed the small server assumes that it is no longer possible to transmit messages to the small client until a new Network Update message is received. In this circumstance, outbound messages from the small server are held in a queue until a new Network Update message is received.
- the time is set at substantially less than the normal interval used by the NAT to re-allocate public IP addresses to mobile devices (e.g. 5 minutes if the NAT re-allocation interval is 20 minutes).
- the system can dynamically adjust the time so that when there is very high network useage, associated with much shorter NAT re-allocation intervals, the time can be shortened.
- the window starts at the time of a Network Update message, and ends when the pre-programmed idle time expires. For example, if Network Update messages are sent by the small client every 60 minutes and the idle timeout is set to 10 minutes, this results in 10 minute communication windows that recur in periods of not less than 60 minutes.
- the small client can also create more or less continual communication transmission opportunities for the small server. 3.12 Security
- MobileMQ provides secure end-to-end messaging between a mobile device and a server using a cryptographic implementation designed specifically for a mobile telecommunications device.
- the process begins when the system is first installed on the mobile telecommunications device.
- the mobile device for example, a mobile email reader connected to wireless network
- the server for example, a corporate email server connected to fixed line Internet service
- the sending device first calculates a message key by using a hash function to calculate a hash from the following inputs: • a code unique to the relevant mobile device, for example the IMEI code of a GSM telephone handset (if the mobile device is the sending device it uses its own unique code and if the server is the sending device it uses the unique code of the intended recipient device) • the shared secret, and • additional data relating to (but not necessarily unique to) each message (i.e., the incrementing message number, application/port number, and session number) that can be calculated independently by both the sending and the receiving devices
- each message is encrypted using a key sequence that is mathematically related to the individual mobile device identity code, the shared secret installed on the mobile device and server, and additional data that can be independently derived by both sending and receiving device that is mathematically related to each message.
- the sending device calculates a Message Authentication Code ('MAC') using a cryptographic hash function where the inputs are the message itself and the key that was used to encrypt the message. The resulting MAC is then appended to the encrypted message.
- 'MAC' Message Authentication Code
- the receiving device calculates the first hash function (the key) for the relevant message (based upon its knowledge of the mobile device unique code number, the shared secret, and the additional traffic data), and uses this key to decrypt the message. Finally, the receiving device takes the decrypted message and the key and uses these to calculate the second hash value for comparison with the MAC appended to the message. If the second hash value is identical to the MAC received with the message, then it is assumed that the message is authentic and unaltered. If, on the other hand, the second hash value calculated by the receiving device does not match the MAC received with the message, then the receiving device issues a challenge to the sending device in an effort to reestablish secure communication. Once security is established, this then triggers retransmission of the message. Thus the authentication system serves in a back-up role to assure the data integrity of the message — any bit errors in transmission would result in failure of the MAC, a security challenge, and message retransmission.
- the security system In addition to assuring confidentiality, authenticity, and integrity of messages themselves, the security system also serves to reduce the cost and performance impact to the mobile device user if third parties attempt to masquerade as the legitimate mobile device user.
- the small server keeps a reverse lookup table with the most recently reported address (and ephemeral port number) assigned to the mobile device. (See description of Network Update at section 3.11)
- the small server operates on the assumption that all in-bound data packets from the mobile device should come from the address and port number that matches the currently-valid address and port number for the device listed in the small server reverse lookup table.
- the small server If data is received that purports to come from the same mobile device but has a new return address (and/or new ephemeral port number), the small server issues a security challenge to the device at the new address using the same cryptographic mechanism outlined above. If the new address returns the correct answer to the challenge, then the small server continues to process in-bound traffic from the new address and also updates the reverse lookup table with the new address. This would normally happen only if the mobile device is assigned a new address or ephemeral port number in such a manner that the mobile device is not aware of the change (e.g., if a network operator NAT box made such an assignment), as changes notified to the mobile device already trigger a Network Update message. (See description of Network Update at section 3.11.)
- the small server does not update the reverse lookup table and simply ignores the data received from the new address; (This could happen if, for example, a malicious third party attempted to interrupt communication to the legitimate mobile device by sending spoof data traffic to the small server.) Communication with the legitimate device (at the old address with the old ephemeral port number) continues uninterrupted and without the need to re-establish security using an additional challenge to the old address. No unwanted data traffic is generated from the small server to the small client; this is important since, with many GPRS and UMTS tariffs, the users' costs depend on the amount of data traffic received, so being able to bar denial of service attacks at the small server is very valuable.
- This system will have a significant cost and performance benefits to the legitimate user because security challenges and responses use relatively large amounts of both processing time and data transfer.
- Mobile communications terminals such as "smart" phones using GRPS
- Loss of the device could result in unauthorised access to communications applications (such as an email client application), which could then have negative consequences for both the end- user and the organisation providing background server capability.
- this security risk is addressed by various systems (1) to lock local access to the mobile device itself— normally at the request of the end user, (2) relying upon mobile operators to deny communications with the device, or (3) deny remote access to the main communications server.
- the first method is inconvenient to the end-user, as locking the device may deprive the user of access to other applications resident on the device.
- the second method relies upon swift and appropriate implementation of blocking instructions by the mobile operator. It is further limited in circumstances (such as a GSM network using SIM cards) where authentication with the wireless network is undertaken independently from the mobile device — the person who possesses the device may still be able to access locally resident data.
- the third method is flawed as it only blocks access to the organisation server, and does not disable access to data locally resident on the mobile device.
- Transcend Mail provides a system to "lock" operation of the entire communications application under prescribed circumstances to protect both the end-user and the organisation responsible for a corresponding communications server, without the need for intervention by the wireless network operator that normally carries traffic from the mobile device.
- Access to the relevant communications application on the mobile device can only proceed after the end-user has entered the appropriate locking code in the mobile device.
- the system can specify a minimum code length, but otherwise allows the end-user to change the locking code.
- the organisation administrator (who also administers the Transcend Mail server) can also change the lock code on a remote basis, thus enabling a code reset if the end-user forgets the code or the device is lost or stolen. This protects e- mail resident on the device and also the mail server, but under the control of the organisation, rather than an end-user or network operator — a critical difference.
- the application lock In its locked state, the application lock can be de-activated by entering the appropriate lock code into the mobile device.
- the lock code is stored locally on the mobile device, it can be stored using a cryptographic hash value based on the following inputs:
- the application lock is then triggered by a number of different events, such as:
- the end-user is unable to access local data and is also unable to access the remote server.
- This concept is already used to separate the transfer of data pertaining to different applications —for example email has a channel that is distinct from that used by contacts or calendar, and is a common multiplexing technique. However, there is no evidence of using this technique to expedite communications within a single application in the prior art.
- Some mail systems may make concurrent connections to a mail relay — one for each email — but again there is no 'sorting' of the mails based on size.
- This function is to allow a peer to temporarily suspend its subscription to synchronisation of events in one or both directions. This may be applied to one, more, or all channels.
- Examples of this include:
- Size exceeds a size set by an administrator
- this function is not new among email clients, both wired and wireless. It is similar to the feature of some email clients that show a paperclip or other icon to indicate the presence of an attachment. In IMAP4 clients, the attachment may or may not be actually present.
- this feature is new in the wireless, distributed client space — particularly if combined with an indication, by different icons or by local inclusion of explanatory body text, of the presence or otherwise of the attachment.
- the intention is that when the number of users in a distribution list exceeds a certain count (e.g. 10), the recipient of the mail is probably not interested in the actual individual users on the list. Hence, data volume may be reduced by not including the names and email addresses of other recipients in the email headers. Rather a simple piece of text (e.g. "38 other recipients") is substituted. The full list of recipients could be downloaded on request.
- a certain count e.g. 10
- the purpose of the function is to hide privileged information until an authorised person completes the security challenge. This aims to protect against the theft of on-screen information.
- the ability to provide the administrator with a list of users who are suitable for Vega account creation In reality this means going to Active directory, and sorting users according to which server they are on, and whether a Vega account already exists for that user.
- the resultant list (displayed in the 'New User' UI) displays only the users that can have a Vega account.
- the ability to remotely display filtered log information of remote servers is not new.
- the 'servers' in this case are components of a distributed system that comprise a Client of a larger Client/Server system.
- the remote display is not part of this Client/Server system, nor is it part of the distributed Client. This is new.
- This function allows some users to operate in a true push mode, others in a strictly polled mode, and others in a mode that is 'effectively push' due to the frequency of polls.
- the purpose of this invention is to direct a provisioning user with a list of possible options that are open to him based on the circumstances presented by the status of existing accounts and the status of the connected handset.
- the application of this invention is to the two components of the distributed client model and the forging and breaking of the links between them: • If the user account selected is permitted to use Vega but does not have a handset allocated o If the handset is currendy allocated to another user ⁇ No configuration is possible: an administrator must remove the allocation o If the handset is currently not provisioned:
- the software is installed and a base synchronisation is performed. • If the user account selected is permitted to use Vega and has a handset allocated o If the handset is currently allocated to the user
- the handset is left unmodified if appropriate o If the handset is currently allocated to another user ⁇ No configuration is possible: an administrator must remove the allocation o If the handset is currently unprovisioned
- This command is to instigate remote deletion of all data on the device. An administrator would take this rather extreme course of action in the event that a handset is lost or stolen. There is little that a user can do to prevent the device from becoming non-functional.
- This feature is to record the time and data of the last data transfer received from the remote component of the distributed client. This provides the user with a confidence check that the system is working in the absence of any application data. Large elements of this feature may be reasonably apparent to a competent person. However, owing to the underlying unreliable nature of the transport, it is not possible to determine the exact time of the last transfer from terminal to server. However, since all communications in either direction result in at least a confirmation of some sorts in the other, recording the last incoming data provides proof that at least some outgoing data was received.
- Symbian SIS file The purpose of the Symbian SIS file is to ease installation in much the same way as is frequently achieved in other software environments through the likes of InstallShield and others.
- the connectivity platform used by SymbianOS devices no longer permits the automatic execution of SIS files, thus it is not possible for an administrator to instigate the installation of software without physically interacting with the device (i.e. pressing buttons, interacting with the Inbox, etc).
- the nature of this feature is to avoid the installation system altogether by copying files into certain folders such that on restarting the device, certain 'run-once' components are executed that complete the installation and configuration of the device. This permits per-device installations that would otherwise require complicated re-compilations of the SIS file.
- the purpose of this invention is to permit the administrator to remotely change certain security credentials of devices without requiring them to be re-provisioned or returned to him to implement the change.
- Such changes may include:
- An administrator may require changing the frequency of polling for certain users in response to:
- This feature is particular to the internal communication of the components of a distributed client in the wireless space.
- the user has no control over the above: the administrator is the sole privilege of these settings.
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GBGB0308989.3A GB0308989D0 (en) | 2003-04-17 | 2003-04-17 | A data access replication or communication system comprising a message queuing communications platform |
PCT/GB2004/001688 WO2004095796A1 (en) | 2003-04-17 | 2004-04-19 | A data access, replication or communication system comprising a message queuing communications platform |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1618719A1 true EP1618719A1 (en) | 2006-01-25 |
Family
ID=9957009
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP04728198A Ceased EP1618719A1 (en) | 2003-04-17 | 2004-04-19 | A data access, replication or communication system comprising a message queuing communications platform |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1618719A1 (en) |
GB (2) | GB0308989D0 (en) |
WO (1) | WO2004095796A1 (en) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7197541B1 (en) | 2001-06-18 | 2007-03-27 | Palm, Inc. | Method and apparatus for automated personality transfer for a wireless enabled handheld device |
EP1734708B1 (en) * | 2005-04-18 | 2010-09-22 | Research In Motion Limited | Method, transmitter, receiver, computer readable medium, communications network and application development environment for providing various levels of reliable messaging between a client and a server |
BRPI0520598A2 (en) * | 2005-10-04 | 2009-10-06 | Ericsson Telefon Ab L M | methods for carrying and receiving an internet message, and device for carrying an internet message |
US7574444B2 (en) | 2006-11-15 | 2009-08-11 | Palm, Inc. | Device-side data de-duping |
US8135798B2 (en) | 2006-11-15 | 2012-03-13 | Hewlett-Packard Development Company, L.P. | Over-the-air device services and management |
US7603435B2 (en) | 2006-11-15 | 2009-10-13 | Palm, Inc. | Over-the-air device kill pill and lock |
US20080115152A1 (en) | 2006-11-15 | 2008-05-15 | Bharat Welingkar | Server-controlled heartbeats |
US8224919B2 (en) | 2007-04-04 | 2012-07-17 | Research In Motion Limited | Mobile communications system including intermediate service provider and related methods |
EP2217995A4 (en) * | 2007-10-26 | 2012-11-21 | Telcordia Tech Inc | Method and system for secure session establishment using identity-based encryption (vdtls) |
US8244609B2 (en) * | 2010-04-02 | 2012-08-14 | Intel Corporation | Payment management on mobile devices |
CN112395624B (en) * | 2019-08-19 | 2022-02-25 | 华控清交信息科技(北京)有限公司 | Data processing method and device and electronic equipment |
CN113296985B (en) * | 2021-06-16 | 2024-03-01 | 北京有竹居网络技术有限公司 | Message processing method and device |
CN114221945A (en) * | 2021-12-15 | 2022-03-22 | 咪咕文化科技有限公司 | Communication method, communication device, computing equipment and computer-readable storage medium |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AUPO323496A0 (en) * | 1996-10-25 | 1996-11-21 | Monash University | Digital message encryption and authentication |
US6721288B1 (en) * | 1998-09-16 | 2004-04-13 | Openwave Systems Inc. | Wireless mobile devices having improved operation during network unavailability |
US6289212B1 (en) * | 1998-09-16 | 2001-09-11 | Openwave Systems Inc. | Method and apparatus for providing electronic mail services during network unavailability |
US6279041B1 (en) * | 1998-11-13 | 2001-08-21 | International Business Machines Corporation | Methods, systems and computer program products for differencing data communications using a message queue |
AU2001250019A1 (en) * | 2000-03-03 | 2001-09-17 | Sri International | Method and apparatus for updating information in a low-bandwidth client/server object-oriented system |
US6965765B2 (en) * | 2001-05-17 | 2005-11-15 | Palmsource, Inc. | Transactional message-queue communication for wirelessly networked devices system and method |
-
2003
- 2003-04-17 GB GBGB0308989.3A patent/GB0308989D0/en not_active Ceased
-
2004
- 2004-04-19 GB GB0408678A patent/GB2401011A/en not_active Withdrawn
- 2004-04-19 EP EP04728198A patent/EP1618719A1/en not_active Ceased
- 2004-04-19 WO PCT/GB2004/001688 patent/WO2004095796A1/en active Search and Examination
Non-Patent Citations (4)
Title |
---|
ANONYMOUS: "Wireless Application Protocol - Wireless session protocol specification", WAP WSP, 5 July 2001 (2001-07-05), pages 1 - 15, XP003024822 |
ANONYMOUS: "Wireless Application Protocol", WAP WIRELESS DATAGRAM PROTOCOL, 14 June 2001 (2001-06-14), pages 1 - 34, XP003024821 |
See also references of WO2004095796A1 |
WAP WDP VERSION: "Wireless Application Protocol; Wireless datagram Protocol Specification", WIRELESS APPLICATION PROTOCOL. WIRELESS DATAGRAM PROTOCOLSPECIFICATION, XX, XX, 5 November 1999 (1999-11-05), pages 1 - 78, XP002979452 * |
Also Published As
Publication number | Publication date |
---|---|
WO2004095796A1 (en) | 2004-11-04 |
GB0408678D0 (en) | 2004-05-19 |
GB2401011A (en) | 2004-10-27 |
GB0308989D0 (en) | 2003-05-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1618727B1 (en) | A data access, replication or communication system comprising a distributed software application | |
US7546453B2 (en) | Certificate management and transfer system and method | |
US20200007527A1 (en) | System and method for controlling configuration settings for mobile communication devices and services | |
US20180324704A1 (en) | Power saving management for mobile devices based on battery charge remaining | |
US8898473B2 (en) | System and method for compressing secure E-mail for exchange with a mobile data communication device | |
US20030131061A1 (en) | Transparent proxy server for instant messaging system and methods | |
US20090287920A1 (en) | Method for establishing bi-directional messaging communications with wireless devices and with remote locations over a network | |
Fong et al. | Towards an open protocol for secure online presence notification | |
US20050039048A1 (en) | Efficient new e-mail discovery | |
EP1618719A1 (en) | A data access, replication or communication system comprising a message queuing communications platform | |
JP2000270012A (en) | Internet mail system and internet mail method using same |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20051117 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR |
|
AX | Request for extension of the european patent |
Extension state: AL HR LT LV MK |
|
17Q | First examination report despatched |
Effective date: 20060627 |
|
DAX | Request for extension of the european patent (deleted) | ||
TPAC | Observations filed by third parties |
Free format text: ORIGINAL CODE: EPIDOSNTIPA |
|
TPAA | Information related to observations by third parties modified |
Free format text: ORIGINAL CODE: EPIDOSCTIPA |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: VISTO CORPORATION |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R003 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20110326 |