WO2006070067A1

WO2006070067A1 - Push messaging methods and devices

Info

Publication number: WO2006070067A1
Application number: PCT/FI2005/050473
Authority: WO
Inventors: Paul Houghton
Original assignee: Stream Mobile Oy
Priority date: 2004-12-28
Filing date: 2005-12-21
Publication date: 2006-07-06
Also published as: FI20045504A0

Abstract

34 (57) ABSTRACT A server placed freely on a connected network outside the wireless network firewall or other corresponding wireless network security entity, is arranged to push web content, partial updates to web content and messages initiating the pull of web content to a mobile terminal located in the wireless network. The mobile terminal is provided with means, such as software, which initiates and maintains contact with the server using Internet technologies, thereby avoiding cost, latency, contractual and firewall penetration issues of the server contacting the mobile ter- minals by telecommunications messaging or Internet technologies. This mobile-initiated permanent IP connec- tion allows the server to pass or push messages from out- side the operator's firewall to the mobile terminal at any time. If the server would attempt to use IP to contact the mobile device directly, the attempt would fail due to the firewall. (Figure 3)

Description

PUSH MESSAGING METHODS AND DEVICES

FIELD OF THE INVENTION

The invention relates to techniques for delivering web pages to a mobile terminal.

DESCRIPTION OF THE RELATED ART

The Internet is a collection of networks which exchange messages using IP protocol (Internet Protocol) and associated protocols which run on top of IP such as TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Gateways between IP networks automatically route and transmit information over primarily the IP4 and IP6 protocols between two or more end points on any of the connected fixed and mobile networks. Each of these networks may also include or run on top of other network transport protocols such as ATM (Asynchronous Transfer Mode) or a wireless protocol which in turn carry the IP packets over that section of the Internet. Currently, the most common method of transmitting information over the Internet for viewing by the receiving part is the World Wide Web environment or "Web" as it will be referred to in this document. Other Internet information transmission and viewing methods are also in common use such as email, File Transfer Protocol (FTP), Voice over IP (VoIP) and multimedia interactive sessions setup using Session Initiation Protocol (SIP), and various other open standard and proprietary techniques. However, the Web is very widely used because it relies on Hyper Text Transfer Protocol (HTTP) to retrieve information from a remote server at the time the information is being viewed by the recipient, thereby gaining several usability and content creation and transmis- sion benefits over systems such as email which forward the information in advance and then store it in an unchanging form waiting for possible later viewing. Such systems are generally referred to as being part of "store and forward" architecture as opposed to content transmission systems like the Web which can be referred to as "real time" message passing system architecture. Mobile phones and similar mobile communication devices where originally not permanently connected to the Internet. Instead, for the transmission and display of visual information they have relied on different telecommunications standards and proprietary communication systems such as SMS (Short Message Service, also known as text messaging) and MMS (Multimedia Message Service), which were built into mobile terminals. Various techniques have been proposed for using web content by a mobile terminal.

GB2371171 discloses a method for passing caller from a cellular phone to a web page. GB2370728 discloses relates to sending mobile user information via

IP6 or SMS to the party being called prior to starting that telephone call.

US6381645 discloses a method of implementing push techniques in conventional web browsers.

US2003119441 discloses a hierarchical Content Classification in In- formation Transmission.

US2002187775 discloses a WAP service personalization, management and billing object oriented platform.

US2003106022 relates to outputting dynamic local content on mobile terminals. US2004185834 discloses a method for enabling IP push capability to wireless devices on a wireless network.

CA2454222 discloses a system and method for pushing data from an information source to a mobile communication device including transcoding of the data. US2004122907 relates to secure interaction between a mobile client device and an enterprise application in a communication system.

WO0195695 discloses a system for wireless push and pull based services.

US2003224810 discloses an interactive push service. Rodriguez, P. et al., "Continuous multicast push of Web documents over the Internet", IEEE Network, vol. 12, pp. 18-31 , Apr. 1998.

Fielding, R. et al., "Hypertext Transfer Protocol-HTTP/1.1", 2616, pp. 1 -114, Jun. 1999.

Wireless Application Protocol Forum, Ltd., "Wireless Application Environment Specification, Version 2.0", Version 7-Feb-2002, 2002, www.wapforum.org.

Tang, Wenting et al., "Intelligent browser initiated server pushing", IEEE IPCCC ¹OO, pp. 17-23, Feb. 2000.

In DE10000664 a network access device detects web addresses on conventional media, loads associated Internet page on screen of computer, TV or mobile telephone automatically or on command. EP1419459 discloses a web interaction system which enables a mobile telephone to interact with web resources.

DE10157296 discloses an Internet browser for e.g. mobile telephone, includes keypad to preset hotkeys for faster access to web site whose address specified in bar code format is scanned using bar code reader.

Push technology is characterized by the server proactively sending documents or information to a client or user. E-mail (Electronic mail) is actually a special kind of push technology that has been prevalent for a long time. The first and most common general category of mobile content push technologies is SMS (Short Message Service) based technologies. SMS and MMS (Multimedia Messaging Service) are the most common forms of "push" messaging in the mobile industry. These store and forward messaging systems run by mobile telecommunications operators push all or part of the data to the mobile terminal over closed telecommunications signaling networks such as SS7 (Signaling System Seven). These signaling networks are closed; they are not part of the Internet. Each operator controls and encrypts this traffic, charging high prices for their use and limiting their use and usefulness.

FIG 1 shows a generic implementation known in the art for pushing information to mobile terminals. Email, MMS, WAP (Wireless Application Pro- tocol) pages, and custom application data are delivered through existing telecommunications infrastructure to a mobile terminal using SMS as the push messenger medium. First push server software delivers the notification directly or indirectly to an SMS Gateway, as illustrated by the arrow A. The SMS Gateway puts the actual push message in either readable text or compressed binary format into the telecommunications signaling network, usually SS7, which delivers it in a store and forward fashion often involving several intermediate steps to the mobile terminal, as illustrated by the arrow B. The mobile terminal standard software decodes header information in the SMS and based on this delivers this as a normal SMS, an MMS, WAP pages (the arrow C) or a custom application which has registered to receive SMS push messages. In the case of WAP Push messages, several user clicks lead to the web browser being launched and a request to the Wireless Network Gateway, normally a WAP Gateway or proxy server, as illustrated by the arrow D. This gateway then provides a web page request to a web server, as indicated by the arrow E. Besides a high price per message, SMS messages cost different amounts depending on where the sender and receiver are located. In some countries the sender pays for the message, in other countries the receiver pays. Computers called Short Message Service Center (SMS-C) nodes and owned and managed by each mobile operator deliver SMS messages. In many cases, if the sender and receiver are on different continents the operators do not even offer message delivery. Two operators must negotiate, sign and implement a legal contract known as an interconnect agreement before messages flow between SMS-Cs and thus between mobile phones on different operator networks. Since not all operators have such contracts with all other operators, this limited connectivity also means that business applications based on SMS and MMS can not be delivered directly for example from a European location to North American customers. Because of the differences in billing models and arrangements and also variable, high costs when roaming, developing business communication of SMS or SMS-based technologies like WAP Push, SMS application push and MMS is difficult. For example, such business applications within one country or between countries must often rely on expensive arrangements with middlemen or brokers that route computer- originated messages to phones in many locations. These brokered arrange- ments often do not permit mobile-originated replies to these messages to return to the sender.

SMS is also incapable of sending long, complex text messages and can not include graphics or sounds. MMS messaging was invented to fix these difficulties, however unseen to the users it still relies on SMS and each opera- tor's limited MMS interconnectivity agreements to start each message delivery process. And importantly, ike SMS the contents of an MMS message are fixed at the time the message is sent. Therefore services like news, weather, games and business applications which change and create their content in real time at the time the message is actually read suffer from being out of date. These messages are also unchangeable and irrevocable once they have been sent.

The newest telephone company standards-based way to delivery content which has not been explicitly requested to mobile phone is WAP Push. Like MMS, WAP Push technology relies on an SMS to start the message delivery process. Unlike MMS, WAP Push triggers the mobile phone to display web pages normally based on the WML or more recently the XHTML MP standard as defined in the WAP 2.0 specification. The continued reliance of WAP Push on SMS infrastructure and additional reliance on the operator's WAP gateway computer means that operators continue to control this push medium. Each individual operator can choose to block certain types of traffic thought their WAP Gateway, limit the size of downloadable content or charge for spe- cific content. Resolving these issues takes the form of difficult, operator-by- operator negotiations before a content supplier can deliver messages to all customers in a given market. Again, publishing organization and brokers acting as middle men to provide a single interface to content providers are required. The artificial limits placed on mobile terminal content by an operator-controlled gateway computer through restrictions on the delivery of web and WAP Push content to mobile terminals is known in the industry as the "walled garden" approach.

A proprietary technology based on SMS application push and similar to WAP Push has been described in the art whereby an SMS message from the telecommunications operator reconfigures the mobile terminal's background to include updated web or vector graphics and text contents. These services would allow operators to duplicate in a mobile environment the changing desktop background push technologies once offered for personal computers. This information distribution model still requires operator permission and messaging costs, and updating phone backgrounds to create an individual operator portal does not address the other difficulties of individual content producers to get their content to a global or even a cross-operator market within a single country.

SMS messaging standards include the ability to send binary mes- sages to an application installed on the mobile phone. Parameters in the message and the phone are matched at delivery time and the application receives the pushed contents. SMS and MMS work with standard software installed on the phone at time of manufacture. This type of information push system requires different client software to be installed and maintained on each com- puter in the network for each application which the user will run. The cost of developing, maintaining and distributing such single-use programs can be quite high. Each such program can also take for individual users to learn, configure and feel comfortable with creating significant barriers to use for inexperienced user and for an application or content which even and skilled user does not use frequently enough to justify the cost of download, setup and continued use of terminal resources. The Standard SMS-based telecommunications technologies including MMS and WAP Push are also limited in that an application server has no knowledge of other events and changes on the phone. Because of this, one can not use these technologies to for example send an MMS or WAP Push message to the phone each time the phone rings, send a message when the user makes a telephone call, or when a phone, data or fax call ends.

A further limitation of existing messaging technologies is the inability to prioritize and deliver different messages in different ways to a user with different notification sounds based on the sender. More important information may be buried behind several less important messages causing it to be missed or confused. And a user can not specify that they would like to only receive important messages during a given period of time.

A second general category of content push technologies is IP-based technologies. These include IP connections initiated from the server and IP connections initiated from the client. Server-initiated push connections are the most commonly described. These solutions require software to be installed on the terminal and a server to be notified of the IP address of this device. The server then, when a push event is desired, initiates a connection to the terminal and delivers information to it which software in the mobile terminal can then act upon, most commonly to notify the client of an incoming email message. For reasons described below, these push technologies are not generally used on mobile terminals but are more commonly used between servers as in the SMTP mail transport protocol.

In practice, mobile terminals are on sections of the Internet which are usually behind a firewall or gateway server device creating a controlled mobile network. These devices at the connection between the controlled mobile network and the more public Internet frequently restrict computing devices on the public Internet from directly contacting mobile terminals. Additionally, IP connection techniques, such as network address translation, may hide the ac- tual address of the mobile terminal. Further, the mobile terminal may be unavailable at any given time making such messages undeliverable. The public telecommunications operator, company, organization, or private individual setting up this mobile Internet space with one or more users does this to protect the mobile terminals from hostile or unwanted contact common on the public Internet. They may also do so to reduce background traffic, protect their control over this space and limit outside or undesired service providers through tech- nical connection policies set in the firewall or gateway device. The result is, if a fixed or mobile computing device from outside the controlled mobile network tries to contact a mobile terminal inside the controlled mobile network, the connection is not permitted unless the organization or individual controlling the firewall or gateway server device makes an exception to their security policy and explicitly allows the connection. Instead, in standards-based mobile telecommunications, an intermediary computer such as the SMS-C is used to store messages when the mobile terminal is unavailable and deliver them on the senders behalf, possibly later then the terminal becomes available, or to forward them to a difference SMS-C for example if the user is roaming to a different controlled mobile network.

The most common solutions to accessing mobile terminals subject to this mobile network restriction are to either make an agreement with the public or private network operator removing the restriction on a specific outside server contacting mobile terminals, or to move the server inside the controlled network. In the common case of a public mobile network operator, the state of the art and most common solution is to sell the server and associated software to the mobile operator so that they can provide the service to their customers. Both of these solutions require time, effort and often large financial commit- ments. And they must be done for each and every restricted mobile network and operator in a given market to achieve universal access to a service requiring server-initiated IP push.

Client-initiated mobile IP connections are less common in mobile terminals. They involve installing more complex software on each mobile ter- minal and having these devices initiate contact to a server on the public Internet. These connections generally operate in a polling or "content pull" manner, connecting intermittently to the server to ask if any new information is available. Mobile email is a common example of this approach. While the result appears to be push to the end user when they are notified several minutes later of the incoming email, they were not notified immediately by the server when the message is available as in true push technologies. The network settings of the mobile terminal may also need to be adjusted to permit this since Internet access through default gateway devices may not permit this type of connection. Once an IP connection is established between the server and one or more mobile terminals, such a connection can be used to transfer messages to the mobile terminal. Several approaches exist for taking data from an existing external messaging network, then gathering, transforming and locally storing information about these messages in a structured format for later viewing by the mobile terminal user. The most common such use is mobile terminal email access. Because so much of the content in an existing messaging system such as email is not interesting to the recipient when they are in a mobile viewing environment, much effort in these systems must also go into filtering and restricting the legacy system's messages down to only those that should be delivered to a mobile user. In other words, not all of the information these systems push to the user was not designed for mobile consumption so it must be simplified, visually slimmed down or filtered away as unsuitable for mobile use. Further, when a large number messages are delivered, the mobile terminal user is frequently overwhelmed with less important information and not given the tools for sort high priority messages for viewing ahead of low priority messages or the option to for a period of time request audible notification only for high priority messages or messages of a given type.

Web browsers are now included with many new mobile terminals. They can be used to visit web sites on the Internet. The process of a user visiting a website is referred to as pull because user a action triggers a request to the web server which in turn generate the requested page which is then pulled to the phone. This process requires personal initiative and several manual steps and decisions on the part of the user: opening the web browser, selecting which site to visit, entering the URL for that site, and browsing through the site to the content of interest. Because of the limited size, network bandwidth and user interface of mobile terminals, performing these steps is significantly slower than performing the same actions on a larger computer. The process of browsing is also less interesting than on a larger terminal because of the limited capabilities of the mobile browser to display many alternative content formats using browser plug-ins or to launch other programs on the mobile termi- nal.

Given the shortcomings in the prior art, there is a need for a method whereby a computer on the Internet can rapidly and at reasonable cost be permitted to at any time initiate control an individual's web browser to deliver real time information, interactivity and rich media content, regardless of which mobile operator is being used and where the mobile user happens to be at that moment. BRIEF DESCRIPTION OF THE INVENTION

An object of the present invention is a new technique for providing a push-type message and content delivery to a mobile terminal by a server computer. The object is achieved by the invention which is characterized by what is stated in the attached independent claims. The preferred embodiments of the invention are disclosed in the dependent claims.

In a preferred embodiment of the present invention is a system and method for a server placed freely on a connected network outside the wireless network firewall or other corresponding wireless network security entity, to push web content, partial updates to web content and messages initiating the pull of web content to a mobile terminal located in the wireless network. The mobile terminal is provided with means, such as software, which initiates and maintains contact with the server using Internet technologies, thereby avoiding cost, latency, contractual and firewall penetration issues of the server contacting the mobile terminals by telecommunications messaging or Internet technologies. This mobile-initiated permanent IP connection allows the server to pass or push messages from outside the operator's firewall to the mobile terminal at any time. If the server would attempt to use IP to contact the mobile device directly, the attempt would fail due to the firewall(s).

In an embodiment of the invention, the mobile terminal maintains the contact by periodically testing the connection with a suitable keepalive message, "ping", that resets timers in intervening operator stateful firewalls and/or NAT (network address translation) firewalls. The mobile terminal may also automatically re-establish the connection when the connection gets broken.

In an embodiment of the invention, the push messages may include, for example, a message stimulating or triggering the web browser to view a specific URL. In response to receiving such a message a mobile terminal may spontaneously open the web browser or micro browser thereof to a designed web location. In further embodiments of the invention, push messages may include, for example, messages triggering the mobile terminal to play a sound notifying the recipient of the message, or display brief notification information from which the user may select or decline to launch the web browser based on messages recently received. The cost for a client to maintain a connection to the server and receive such messages over mobile Internet connections is minimal, thereby solving the problem of some mobile information services not being economic to offer. The advantages are: all the convenience of standard push services (SMS, MMS, email) together with the interactivity, ease and low cost of making dynamic web services. Anyone can create web pages and use our technology to economically make as many messages as they need to appear on the mobile terminal.

In an embodiment of the invention, the web server can optionally create the resulting message at the time it is viewed, thus solving the problem of SMS, MMS and email information being out of date by the time it is read. Web message display adds to these a display which is graphical and inherently interactive in a manner that is simple and intuitive for most users. And the interactive application display technology does not have to be adapted on a terminal-by-terminal basis as dedicated program interfaces must be since the web browser existing in the terminal already accommodates the terminal's screen and other display limitations.

Web push messages utilizing the principles of the invention delivered rapidly, bypassing the public and often crowded SMS, MMS and email store-and-forward mechanism within an operator and between operators.

The advantages of performing push service in accordance with the present invention include the ability to run such a service from outside the mobile operator's WAP gateway, skip the overhead charges like per-message SMS fees normally associated with "mobile push", and make it easy to create mobile applications as web pages, therefore usually without programming. Thus, interactive push services according to the invention can be created and delivered to phones by anyone capable of creating a web page on a web server, thus allowing new services to be created for small niche markets.

Further, the complete content and service logic governing proc- esses within the mobile application can be changed at any time in the server, thus avoiding logistical difficulties of distributing new client software to mobile terminals in multiple geographically distributed locations. The present invention provides a novel way for getting a push message to a mobile device. All filtering functions, for example, can be performed beforehand on the server by a routing algorithm whereby the server knows what "channels" and content within a specific information channel the user is interested in receiving. The conventional content filtering in the mobile network entities are required. The equivalent of this conventional type of filtering can thus be performed entirely on the server and configured in advance by the user, through a mobile web page, selecting what content channels they would like to turn on and off. After this, all the resulting (routed, but personal server-side filters may also be used within a channel) information in a given channel is sent to the mobile terminal.

The look and feel of these messages can be customized based on message source or message recipient preferences using web and technologies such as cascading style sheets, XML transformations and custom algo- rithms to alter the appearance independent of the message contents. The use of specific sounds played to the recipient along with a message may be part of this presentation customization per message. Such a customized "skin" or visual and/or auditory template provides satisfaction to the messaging parties including personal identification, corporate branding, individual identification or the transmission of a secondary communication channel signaling mood or for conveying and evoking emotion similar to a posted greeting card. These same sound and visual customizations can be used for delivering games and entertainment from a computer to the message recipient and back or between human players optionally mediated by a computer. These messages may be routed automatically to a nearby larger computing display device based on the proximity of the mobile terminal to the larger computing device, both equipped with a near field wireless communication network such as RFID, Bluetooth, ultrawideband, Zigbee, WLAN. This embodiment of the invention alleviates a usability problem that affects the pre- sent-day mobile messaging solutions. A user with a mobile terminal always receives their messages on the mobile terminal, even when a more capable and generally larger communication device is close to them. The limited display size and input methods of the mobile terminal frequently make communication less convenient, however there has been generally no way for the sender to route incoming messages to the fixed device automatically when the recipient is near a device capable of receiving such messages. There has also been no way to automatically stop routing the messages to the more capable communication device when the individual and their mobile communication device leave the proximity of the device to which their individual messages are being sent. Messages may be triggered either by events which the server is aware of, or events which the client is aware of and which the client makes the server aware of. Such client-side events of which the server is informed for the possibility of delivering new web services include the making, receiving, and termination of telephone calls, the transition from presence-to-absence or absence-to-presence of other devices in a geographical area, metropolitan area, local area or personal area wireless communications network, changes in internal state of electronic equipment, taking of measurements, processing of such measurements to see if they match certain criteria, video game actions or events. In some cases a separate server such as a telecommunication service server, original equipment manufacturer device or business information system may notify the server directly of events or messages to be sent using an external application programming interface (API). Such a device connected by external API may also receive information including the results and responses of messages which the user has replied to by terminal software or web page interaction.

The invention provides content and application producers with a cost effective, network-independent and device-independent service for the rapid creation and distribution of interactive mobile media to mobile terminal users.

The invention provides techniques for delivering web pages to a mobile terminal at will by a server computer and without the need for any additional action by the recipient, and more specifically to a system, method and program for sending, receiving and acting upon messages sent to a mobile client device over a packet switched data network for the purpose of initiating web data display based on server-side events and mobile terminal events including phone calls and network proximity events, and local resource changes.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following description, reference is made to the accompanying drawings which form a part hereof, and which illustrate several embodiments of the present invention. In the drawings:

Figure 1 shows an implementation known in the art for pushing information such as email and web links through existing telecommunications infrastructure to a mobile terminal; Figure 2 is a block diagram illustrating an exemplary implementation of the system for pushing web pages to a mobile terminal based on server side and client side events in accordance with one embodiment of the present invention;

Figure 3 is a block diagram illustrating an exemplary implementation of the system for two proximal clients to cooperate in pushing web pages to the preferred display device;

Figure 4A - 4D is a flow chart illustrating an exemplary process by which the mobile terminal maintains an open path for network communication with the server, notifies the server of locally monitored events on the mobile terminal, and responds to messages from the server in accordance with one embodiment of the present invention;

Figure 5 illustrates an example of a "XPUSH" procedure;

Figure 6 illustrates an example of a "PROXY XPUSH" procedure;

Figure 7 illustrates an example of a "XPULL" procedure; Figure 8 illustrates an example of a "PROXY XPULL" procedure;

Figure 9 illustrates an example of a "PROXIMITY XPUSH" procedure;

Figure 10A illustrates another example of a "PROXIMITY XPUSH" procedure; Figure 10B illustrates an example of a "PROXIMITY ROUTING" procedure, and

Figures 11A, 11B and 11C are flow diagrams showing examples of processes by which the server maintains a connection with the client and communicates messages to it.

DETAILED DESCRIPTION OF THE INVENTION

In the above description, the invention is described using various embodiments of the present invention as examples but the invention is not intended to be restricted to these embodiments. It is understood that other embodiments may be utilized and structural and operational changes may be made without departing from the scope of the present invention.

Figure 2 illustrates an exemplary implementation of the system for pushing web pages to a mobile terminal based on server side and client side events in accordance with one embodiment of the present invention. More specifically, Figure 2 illustrates a Push Client basic functionality 210 imple- mented in a mobile terminal 21 as part of a message passing system in coop- eration with a Push Server 22. The push client 210 is preferably implemented in form of a software run in a processor of the mobile terminal 210. The mobile terminal 21 is preferably a commercially available mobile terminal, such as a portable phone capable of running software or personal digital assistant, which provides a platform for downloading application software over air or from a personal computer, installing the software in the terminal, and running the software in the terminal. For example, the Symbian operating system is an open operating system, application framework, and application suite optimised for the needs of wireless information devices such as smartphones and com- municators, and open operating system and drives standards for the interop- eration of data-enabled mobile phones with mobile networks, content applications, and services. The Symbian operating system also includes connectivity software for synchronisation with data on personal computers and servers. The application may be in an appropriate programming language, such as Java, which is an object-oriented programming language developed by Sun Microsystems, or C++.

The push client software 210 preferably launches automatically when the mobile terminal 21 is turned on. The software 210 runs in the background and attempts to log into the push server 22 over a packet switched network 23, normally a wireless network capable of transmitting Internet Protocol (IP) packets. The arrow A in Figure illustrates the login attempt.

The wireless network 23 may be protected by means of a firewall or other appropriate security entity 24, which connects the wireless network 23 to the public networks and filters and selectively discards the data packets enter- ing and exiting the wireless network according to predefined rules. Thus, a firewall is a gateway which operates at the same time as a connector and a separator between networks in a sense that it keeps track of the traffic that passes through it from one network to another and restricts connections and packets that are defined as unwanted by the administrator of the system. Addi- tionally, IP connection techniques, such as Internet Protocol 4 (IP4) network address translation and Internet Protocol 6 (IP6) security, encryption and/or authentication, may hide the actual address of the mobile terminal or make it otherwise difficult for a server to connect to directly to the mobile terminal. The public telecommunications operator, company, organization, or private individ- ual setting up this mobile Internet space with one or more users having greater ability to contact one another and included servers does this to protect the mo- bile terminals from hostile or unwanted contact common on the public Internet. They may also do so to reduce background traffic, protect their control over this space and limit outside or undesired service providers through technical connection policies set in the firewall, gateway or other security device. Physi- cally a firewall may be a machine with appropriate software to do the task assigned to it. It can be a router, a personal computer, a gateway server or whatever that can be used for such purposes.

Consequently, if a fixed or mobile computing device from outside the controlled mobile network tries to contact a mobile terminal inside the con- trolled mobile network 23, the incoming connection is not generally permitted unless the organization or individual controlling the firewall, gateway server or security device 24 makes an adjustment to their security policy and explicitly allows the connection.

From point of view of the wireless packet data network 23, the login attempt and a connection establishment is a normal IP connection established at the request of the mobile terminal. Therefore, the login attempt is normally allowed to pass the firewall 24 since the connection is from the inside the firewall to outside.

After attempting login, if the login is not successful the client 210 may automatically or under supervision of the user of the mobile terminal 21 try several different techniques for contacting the server 22. Since there are numerous variations between mobile terminals and in network connectivity, more than one connection attempt may be needed to best contact the push server 22. Differences in wireless network terminal characteristics, individual push server availability and accessibility, firewall and gateway permissions, connection timeouts, connection level stateful (such as TCP) and stateless (such as UDP) protocol availability and alternate mobile terminal network settings mean that a sequence of connection establishment attempts and connection maintaining steps may required to be made using variations in relevant network pa- rameters.

A second reason for automatically adjusting the network parameters is not simply establishing the connection but establishing the connection in the most cost effective or highest performance configuration available for the individual mobile terminal user account service level. Some customers may be offered more secure or higher performance service while others receive the least cost connectivity from either the mobile terminal's or the push server's standpoint.

As an example, such network parameters may include one or more of the following: - Use of a connection-oriented protocol suitable to the wireless network such as TCP/IP protocol, which is generally preferred in the common situation where an intermediate firewall, Network Address Translation (NAT) or gateway device is present as the periodic message timing.

- Use of a connectionless protocol suitable to the wireless network 23, such as UDP/IP, which is generally preferred when no network device restricting use is present as this reduces resource usage on the server when large number of mobile terminals is served.

- Use of an alternate connection-oriented protocol such as HTTP suitable for mobile push operation through more strict firewalls and proxied Internet connections.

- Use of a secure protocol such as HTTPS, IP-Sec, secure IP6 or a proprietary security protocol to identify the communicating parties, prevent message interception by 3^rd parties, and prevent message modification by 3^rd parties. - Use of a periodic message from the client to the server or server to the client to the effect that client socket, server socket, intermediate Network Address Translation (NAT) devices, intermediate firewalls, and intermediate gateway devices do not time expire the connection. Such periodic keep-alive message is illustrated by means of the arrow B2 in Figure 2. - Use of configuration messages to the firewall (FIG 2, B1 ) using a firewall configuration protocol, such as Universal Plug and Play, to open a path for server-initiated connection-oriented or connectionless messaging to the client.

- Use of a periodic messages initiated by the client 210 or by the server 22 to the effect that the receiving application is informed that their messages are continuing to be received. Such periodic reply message message is illustrated by means of the arrow B2 in Figure 2.

- Use of longer or shorter timing between such periodic messages to match the combined needs of all such network devices and protocols involved in transmitting communication. - Use of an alternate push server network address such as an address accessible with fewer security and performance restrictions which may be more available, more accessible, lower cost or otherwise preferred at the present time and from the present location. - Use of one or more alternative mobile terminal network connection settings, or variation of the parameters within the settings.

- Use of an alternate connection route through a second mobile or fixed terminal accessible to the mobile terminal over a wireless network and capable of communication with a push server. In an embodiment of the invention, the mobile terminal 21 keeps a prioritized data structure listing the preferred communication protocols, server addresses, periodic message timings, network access settings, and alternate communication routes which it should use. Automated and manually assisted use of this structure should then result in a connection to one or more push servers, however if one of these connections which the mobile terminal is programmed to expect is not available, the mobile terminal can choose the sleep that function of the client software and attempt re-connection several seconds or minutes later, repeating in like fashion with the same or different network connection parameters as described above until a connection is established. At any time after a connection is established between the client 210 and the server 22, the client 210 may push a message to the server 22 or the server 22 may send a push message to the client 210. This is illustrated by means of the arrow C in Figure 2. These messages through a previously established, connection-oriented protocol such as TCP/IP arrive quite rapidly, more rapidly than if the connection where established only when needed. Thus the associated overhead such as 3-way handshake during connection establishment occurs before the actual message transmission rather than delaying the actual message transmission.

A connectionless protocol, such as UDP/IP, may also used in cases where the connection-oriented protocol is not possible or not desirable because of the push server resources used by every static instance of a connection-oriented protocol. Connectionless communication is also used when a message needs to get through to the server 22 quickly, such as when occurs when the client 210 notifies the server 22 of an incoming phone call but the connection-oriented protocol connection is not connected or is busy already transferring information. Such a selective use of this high priority, low latency communication channel from client 210 to server 22 gives the server 22 the opportunity to in return push to the client 210 a service triggered by the event begin communicated by the client 22, as will be described in more detail below. The sending of such a return message is frequently time critical and the fastest available technique will be used.

In the preferred embodiment of the invention, the most basic message pushed from the server 22 to the client 210 is a Uniform Resource Locator (URL) or equivalent binary information specifying the network address of information to be presented to the user of the mobile terminal 21. Upon recei v- ing such a message, the client 210 will act upon the received message to present this information with the aid of the web browser, audio player, video player, and other programs in the mobile terminal. The most common case is for the URL to be passed (the arrow D in Figure 2) to the local web browser 220 installed in the mobile terminal 21 , causing the display of web or media information. Such a URL display does, in cases where neither silence nor a message-specific sound is indicated by the server, cause the mobile terminal to play a default message notification sound. All sound in the mobile client can be disabled by the user.

The push message from the push server 22 may be triggered by any trigger event, local or remote, defined at the server. The trigger may, among others, include an alarm, notification, or measurement result received to the push server 22 from another device or system. With a push message, the server 22 may direct the web browser 220 directly to an external web site 25, as illustrated by the arrow F in Figure 2, or instead choose to transmit to the client 210 the actual web page to be displayed. This page is then made available to the mobile terminal 21 as a local resource by opening a server network port on the mobile terminal 21 and directing the mobile terminal's web browser 220 to this location, as illustrated by the arrow E in Figure 2. A randomly selected, high numbered TCP/IP port serving HTTP data only to the web browser 220 on this same device 21 serves as the preferred way to accomplish this. With this proxy-like behavior the resulting data display conforms to web transport standards but is displayed much more rapidly as the data does not need to be separately retrieved from a remote web server 25. References to other web resources contained within a resource so served from a local proxy may be either references to similar locally-proxied content or to non-proxied content on regular, external web pages. Analogously, content submission from the web browser 220 based on this proxy content may either return to the push client software 210 or an external web server 25 as permitted by the associated web standard in use.

Figure 5 illustrates an example of an "XPUSH" procedure wherein the push server 22 is triggered by a trigger event to send an URL Push message to the push client 210 and thereby force the web browser 220 of the mobile terminal to display a dynamic web page on the terminal 21. The potential applications of the XPUSH include a mobile marketing and promotion, news with pictures, stock alert and purchase, instant notify mobile webmail, cus- tomer service, web forum message follow-up, alarms, reminders, corporate calendaring, customer service, personal messaging, group messaging, mobile games, community interaction, etc.

Figure 6 illustrates an example of a "PROXY XPUSH" procedure which is similar the XPUSH but the push server 22 sends the client 210 a web content push, i.e. the actual web page to be displayed. This content is optionally compressed by the server and decompressed by the terminal software to speed message transmission and display. The content may further be updated by the push server by sending partial changes to the page which the client software combines with its most recent copy of the web page contents. The client 210 then operates as a proxy in the manner described above, and launches the web browser 220 to get the web page from the proxy. As a proxy, the client software is also be responsible for forwarding users actions such as HTTP get and HTTP post data back to the web server. The proxy included in the mobile terminal software may, on web pages after the first web page, re- quest additional data from the web server. The potential applications of the PROXY XPUSH include in-call web data services, in-call notes, services with locally cached images, responsive multi-page services, electronic dictionaries, business databases, etc.

Figure 7 illustrates an example of an "XPULL" procedure in which the push client 210 can at any time send a (pull/event/push) message to the push server 22 in response to by any trigger event defined in the push client 210. In response to such message the push server 22 may send the URL Push to the client and the procedure continues as in Figure 5. The potential applications of the XPULL include a mobile marketing and promotion, instant notify mobile webmail, customer service, web forum message follow-up, etc. The trigger events may include a made phone call, received call, end of made call, end of received call, SMS send, SMS receive, MMS send, MMS receive, local data acquisition, local computer program event, local mobile terminal data network event, phone mode change, etc.

Figure 8 illustrates an example of a "PROXY XPULL" procedure the push client 210 can at any time send a (pull/event/push) message to the push server 22 in response to by any trigger event defined in the push client 210. In response to such message the push server 22 may send a web content push, i.e. the actual web page to be displayed, and procedure continues as in Figure 6. The proxy included in the mobile terminal software may, on web pages after the first web page, request additional data from the web server.

The push server 22 may optionally display a notification asking permission or presenting information instead of or prior to launching the web presentation. The preferred embodiment is for the behavior, language and content of this information to be configured on the server 22 based on the service and preferences of the individual receiving the message. In such cases the informational message, associated URL or URLs to be displayed, and information messages associated with the menu option selected are transmitted to the client 210 by the server 22.

In an embodiment of the invention, the client 210 is also capable of receiving and storing variables which configure the client 210. The server 22 may thus specify the network connection preferences, notification sounds, and other behavior of the client 210. These changes facilitate the efficient operation of the entire system and can be used for automated remote maintenance of clients, for example changing the usemame, password, and security certifi- cates stored in the mobile terminal.

The push server 22 may have an optional feature of letting the web server 25 know what information is about to be requested, as illustrated by the arrow G in Figure 2. This can be done either through a direct application programming interface to a web server 25 configured to receive such notifications, or when the web server 25 is not so configured by acting as a web client and requesting a page at the same time that page is pushed to the client 210. The result in either case is the content is created and read into web server cache memory and formatted before the actual request arrives from the mobile terminal 21 , thereby speeding the deliver of such content to the mobile terminal 21. A similar mechanism is used allowing the push server to communicate with the web server for security and convenience purposes. As shown in arrow G in Figure 2, the push server can notify the web of additional the parameters affecting the display of a page which the mobile terminal is about to request. Such advance-configuration parameters include for example the user- name and password of the mobile terminal user, thereby avoiding the need for the mobile user to manually log in to the web service. Other users for this advance parameter notification feature include but are not limited to network security to limit web page display to a specific IP address or security key, and the passing of web application-specific parameters to specify data such as application state, process step and display preference information. Referring now to Figure 3, users of mobile terminals 21 are frequently in the proximity of a more capable terminal 31 than their mobile terminal. Such a terminal, which may also be mobile, is referred to here as a large screen terminal 31 and is usually characterized as computing device with superior display and input capabilities and usually a higher performance network connection. The push client according to the invention can also be installed on such a large screen terminal 31. Thus, both devices 21 and 31 have client software 210 and are associated with one another in the server 22. One or both of the wireless terminal 21 and large screen terminal 31 are equipped with the ability to wirelessly detect the physical proximity of the other terminal (using a suitable wireless technology, such as bluetooth, RFID, wavelan, Wi-Max, Zigbee, ultrawideband, infrared) and therefore the user's location, possession of a given object or the presence of an alternate user interface. This presence and information can be transmitted by one or both of the push clients 210 in the terminals 21 and 31 to the push server 22 (as illustrated by means of ar- rows A and B in Figure 3) and/or between the terminals 31 and 21 over the wireless link or network 32 (as illustrated by the arrow C in Figure 3). The large screen terminal 31 may communicate through a network firewall 33 and a broadband network 34. The push server 22, being so informed, may then use this proximity information as a trigger event for sending messages, as illus- trated by the arrow D in Figure 3. It may also use this information to route messages directed to the user of the wireless terminal 21 to the nearby large screen terminal 31. It may also use this information to route messages to the wireless terminal thought the larger terminal over the lower cost or higher performance local wireless network if the network is so capable. Based on the logic of a given service, the server 22 may also choose to for security reasons stop directing messages to the large screen terminal 31 when the wireless terminal 21 is not present or to change the preferences for delivering messages to the mobile terminal based on the recent presence or absence of one or more of these location-specific networks. The service may utilize this information on the server 22 to also direct all messages for a user to the wireless terminal 21 when the large screen terminal is not present 31.

Events on either terminal 21 and 31 can be either transmitted directly to the other device 31 and 21 over the wireless link or network 32 (as illustrated by the arrow C in Figure 3) for relay to the server 22, or they can be sent directly to the server from each terminal. The mere proximity and associa- tion of terminals 21 and 31 may also be used to let the server 22 send and receive associated technical service information, or to trigger a network service for one terminal 21 or 31 associated with events on a nearby terminal 21 or 31. For example, the mobile terminal 21 detects a nearby PC terminal 31 by means of Bluetooth technology, notifies the server 22 of proximity, and the server 22 pushes a web display directly to the PC 31. Further, the proximity push service according to the present invention can be used for providing various applications, such as on-line in-call web data services, call notes, business databases, interactive games, etc.

Figure 9 illustrates an example of a " PROXIMITY XPUSH" proce- dure wherein the push server 22 has been earlier informed (step 2) by either the mobile terminal or the large screen terminal of the proximity condition (step 1 ). Based on this notification and user preferences the push server may choose to route future messages to either device (step 3). Then at some later time the push server is triggered by a trigger event (step 4) to send an URL Push message to the user, and based on user preferences in this case the push message is sent to the push client 310 in the large screen terminal 31 and thereby launches the web browser 320 of the terminal 31.

Figure 10 illustrates an example of a "PROXIMITY XPULL" procedure in which the push client 210 in the mobile terminal 21 , having detected the physical proximity of the large screen terminal 31 , sends a (pull/event/push) message to the push server 22 in response to by any trigger event defined in the push client 210. The push server 22 sends a proximity URL push message to the push client 310 in the large screen terminal 31 and thereby launches the web browser 320 of the terminal 31. Figure 10B illustrates an example of a "PROXIMITY ROUTING" procedure in which the push client 210 in the mobile terminal 21 , having de- tected the physical proximity of a large screen terminal 31 and established a data-transfer capability to the push client 310 in it (step 2). In this particular procedure the network connection, not the screen, is used and thus the device may not actually have any user input or display capability. The large screen terminal push client 310 notifies the push server 22 that it should temporarily route all messages to push client 210 through 310. From this point forward until the server 22 and mobile terminal push client 210 signal otherwise or until a message fails to arrive with this routing, the mobile terminal can route local trigger events (step 4), receive URL push (step 5) and other messages includ- ing large file transfer and web proxy HTTP requests (Figure 6) through this local, high bandwidth connection. In such cases the push client in the large screen terminal 310 sends and receives HTTP and HTTPS communication (step 6 and 7) on behalf of the web proxy in the push client 210 and/or on behalf of the mobile terminal's 21 web browser 220. The result and benefit of this system is that the mobile terminal can browse and use web services over the less expensive and more capable personal area or local area network connection to the large screen terminal's more capable connection.

Figures 4A, 4B, 4C and 4D are flow diagrams showing examples of processes by which the client 210 maintains a connection with the server 22 and communicates messages to it.

Firstly, in step 401 in Figure 4A, the push client 210 initiates an attempts to log into the push server 22 over a packet switched network 23, as indicated by the arrow A in Figure 2. Success of the login is monitored in step 402, and if the network connection shows an error or does not get a response from the server in a reasonably short time the network settings are adjusted in 403 (for example in the manner describe above if the network connection fails). If the server does respond but login fails at 404, the push client may change the login settings in step 405 (for example in the manner described above if the login is rejected) and retry the login. If the login to the server 22 is successful, a connection is opened to the server 22 and the server 22 is informed of the client's its availability and the details by which the client 210 can be contacted until the server 22 is otherwise notified. In association with the login procedure the client 210 may attempt to communicate with the firewall 24 it is behind using a firewall configuration interface, such as the Universal Plug and Play (UPnP) Internet gateway configuration protocol (the arrow B1 in Figure 2). In this manner the client 210 requests the firewall 24 to open a hole allowing the server 22 to initiate contact with the client 210 whenever there is need a need for the server 22 to deliver a URL display message or other command to the client 210. In the preferred embodiment, the configuration of the firewall 24 to allow incoming messages in this manner is attempted in step 406 immediately after login, and if the operation appears successful (step 407) the server 22 is notified. The server 22 then attempts this type of connection to the client 210 (step 408), and if that too is successful (step 409), then one of this test connection is closed and both server 22 and the client 210 mark the second connection as closable (step 410). At any time after this point the server 22 or the cli- ent 210 may choose to close the remaining network-level connection (usually a TCP connection) while keeping the application-level "connection" in the form of knowledge of how the server 22 at this time can contact the client 210 when needed. The advantage of such an application-level connection without the network-level connection is lower use of network resources particularly on the server side thus increasing server scalability by decreasing overhead cost per active user, however opening a connection from the server side for future messages may delay next message transmission by introducing latency.

Referring to steps 411 and 412 in Figure 4B, after the login and connection setup, the push client 210 may send a periodic message (the arrow B2 in Figure 2) from the client to the server to the effect that client socket, server socket, intermediate Network Address Translation (NAT) devices, intermediate firewalls, and intermediate gateway devices do not time expire the connection. The period of time (X seconds) between such periodic messages is set to match the combined needs of all such network devices and network protocols involved in transmitting communication (step 411). The client 210 may then wait for a reply or acknowledgement from the server 22, and if the acknowledgement is received (step 413), the client 210 returns to step 411. If the no acknowledgement is received, the client 210 may return to step 401 in Figure 4A to attempt a new login to the server 22. Referring to Figure 4C, after the login and connection setup, the push client 210 is ready to receive the push messages over the connection from the server outside the operator's firewall (step 414). If a push message is received, the client 210 executes the corresponding function, such as display URL (step 415). If required, the client 210 may also send a message to the server 22 (step 416), such as an acknowledgement or an execution result. Referring to Figure 4D, after the login and connection setup, the push client 210 may monitor the local resources for a state change (a trigger event) in step 417. If a state change is detected in step 418, the push client

210 may send a message to the server 22 (step 419), such as the event mes- sage in Figure 7.

The push server 22 can be server software run on any appropriate computing device. Figures 11 A, 11 B and 11C are flow diagrams showing examples of processes by which the server 22 maintains a connection with the client 210 and communicates messages to it. In step 101 of Figure 11A, the push server 22 receives a login from the client 210 initiates an attempt to log into the push server 22 over a packet switched network 23, as indicated by the arrow A in Figure 2. In step 102, a connection is opened to the server 22 and the server 22 is informed of the client's its availability and the details by which the client 210 can be contacted until the server 22 is otherwise notified. In step 103, the server 22 then attempts this type of connection to the client 210, and if that is successful (step 104), then one of these connections is closed and both the server 22 and the client 210 mark the second connection as closable (step 105).

Referring to steps 111 and 112 in Figure 11 B, after the login and connection setup, the push server 22 may receive a periodic message (the arrow B2 in Figure 2) from the client 210 to the effect that the server updates the respective server object associated with a given client so that the connection is not time expired. The server 22 may send a reply or acknowledgement in step 113. Referring to step 121 Figure 11 C, after the login and connection setup, the push server 22 monitors for trigger events and event messages. If the server 22 is triggered by a trigger event (the result "yes" in step 122), it decides based on application-specific logic and/or user preferences whether the resulting push procedure is a "PROXIMITY ROUTING" procedure in step 124. In case of "PROXIMITY ROUTING", the server 22 sends the URL Push message to the push client 210 through the push client 310 (step 125). If a "PROXIMITY ROUTING" is not selected in step 124, the push server 22 proceeds to step 126 to decide based on application-specific logic and/or user preferences whether the resulting push procedure is a "XPUSH" or a "PROXY XPUSH". In case of "XPUSH", the server 22 sends an URL Push message to the push client 210 and thereby forces the web browser 220 of the mobile ter- minal to display a dynamic web page on the terminal 21 (step 129). In the case of "PROXY XPUSH", the push server 22 sends the client 210 web content push, i.e. the actual web page to be displayed (step 130), optionally in compressed format to speed delivery. If the server 22 is not triggered by a trigger event (the result "no" in step 122), it checks whether an event message has been received from the client 210 (step 123). If not, the process returns to step 121. If an event message has been received from the client 210, the server checks whether a proximity detection is involved indicating that the mobile terminal 21 is close to a large screen terminal 31 (step 127). If the proximity detection is involved, the server 22 performs accordingly, typically by sending an URL Push directly to the large screen terminal in a manner described with reference to Figure 10 (step 128). If the proximity detection is not involved, the server 22 checks whether the resulting push procedure is a "XPULL" or a "PROXY XPULL" in step 124. In case of "XPULL", the server 22 sends an URL Push message to the push client 210 and thereby forces the web browser 220 of the mobile terminal to display a dynamic web page on the terminal 21 (step 125). In the case of "PROXY XPULL", the push server 22 sends the client 210 a web content push, i.e. the actual web page to be displayed (step 126). The above specification, examples and data provide a complete description of the manufacture and use of the system, method, and article of manufacture, i.e., computer program product, of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter ap- pended.

Claims

1. A method of pushing messages to a wireless terminal a push server located outside a wireless system serving the wireless terminal, comprising the push client initiates and maintains over an extended period of time a packet-based data connection through at least one communication security or inter-network connection device of the serving wireless system to the push server using Internet technologies; the push server sends, in response to predetermined trigger events, at any time web push messages to the push client through the communication device by means of said client-iniated and client-maintained permanent connection, whereby avoiding blocking of said server-originated push messages by the security device, the push client, in response to receiving a web push message from the push server, initiates a launch of a web browser in the mobile terminal or in a nearby device so as to view a web content identified by or contained in the received web push message.

2. A method as claimed in claim 1 , comprising the push client sends configuration messages of a security device configuration protocol to the the security device to open a path for later server- initiated connection-oriented or connectionless messaging to the push client.

3. A method as claimed in claim 1 or 2, comprising the security device is a security protocol such as IP6 whereby the client may open the possibility for the server to contact it by exchanging secu- rity keys.

4. A method as claimed in claim 1 , 2 or 3, comprising the push server attempts a server-initiated messaging through the security device to the push client immediately after having being informed of the client-iniatiated connection.

5. A method as claimed in claim 1 , 2, 3 or 4, comprising the push server and the push client mark the maintained network- level connection closeable, the push server and the push client can close the network-level connection while keeping an application level connection.

6. A method as claimed in any one of claims 1 - 5, wherein the step of maintaining further comprises that the push client maintains the permanent connection through the security device by sending periodic keep-alive messages.

7. A method as claimed in any one of claims 1 - 6, comprising the push client or the push server sends a periodic reply to messages initiated by the push server or by the push client, respectively, to the effect that the receiving end is informed that the messages are continuing to be received.

8. A method as claimed in claim 6 or 7, comprising using varying timing between the periodic keep-alive or reply messages to match the combined needs of various network devices involved in transmitting communication.

9. A method as claimed in any one of claims 1 - 8, comprising if an attempt to contact the push server for iniatiating of the permanent connection and login is not successful, the push client automatically or under supervision of the user of the wireless terminal tries one or more other techniques and/or network parameters for contacting the push server.

10. A method as claimed in claim 9, wherein said trying of one or more other techniques and/network parameters include one or more of using an alternate push server network address which may be more available or more accessible at the present time and from the present location, using one or more alternative mobile terminal network connection settings, or variation of the parameters within the settings, using an alternate connection route through a second wireless or fixed terminal accessible to the wireless terminal over a wireless network and capable of communication with the push server, using TCP connection, using UDP connection.

11. A method as claimed in any one of claims 1 - 10, comprising the push client stores in the wireless terminal a prioritized data structure listing preferred communication protocols, server addresses, periodic message timings, network access settings, and/or alternate communication routes and uses this data structure to attempt reconnection to the push server if the connection to the server fails.

12. A method as claimed in any one of claims 1 - 11 , wherein the connected networks on which the push server and mobile terminal are located are private networks allowing greater interconnectivity than they both offer to the public Internet.

13. A method as claimed in any one of claims 1 - 12, wherein the push server sends to the push client include a web push message directing the web browser directly to a web site.

14. A method as claimed in any one of claims 1 - 13, wherein the push server sends to the push client include a web push message including an Uniform Resource Locator URL or similar web location address.

15. A method as claimed in any one of claims 1 - 13, wherein the push server sends to the push client an actual web page to be displayed.

16. A method as claimed in claim 1 - 15, wherein the push client functions as a caching proxy server for the browser.

17. A method as claimed in claim 16 wherein the caching proxy server accepts compressed information and decompresses such information for the web browser.

18. A method as claimed in 17 wherein the caching proxy server accepts partial updates, combines this with the cached information and transmits the resulting complete information to the web browser.

19. A method as claimed in any one of claims 1 - 17, wherein the push server sends to the push client include a web push message triggering the wireless terminal to play a sound notifying the recipient of the message and/or to display notification information from which the user may select or de- dine to launch the web browser based on web push messages recently received.

20. A method as claimed in 19, wherein the notification sound played by the terminal is selected by and deliverable from the server and may be retrieved from the server by the terminal, thereby allowing the push server to indicate though audio signals including note sequences, audio samples and spoken speech the sender, nature, content and other attributes of the received message or the message sender.

21. A method as claimed in 20, wherein the specified notification sound is played from a cache in the terminal and the cache is automatically updated over the air as needed with new notification sounds.

22. A method as claimed in any one of claims 1 - 21 , wherein said trigger events include events which the push server is aware of and/or events which the push client is aware of and which the push client makes the push server aware of.

23. A method as claimed in any one of claims 1 - 22, wherein said trigger events include one or more of: the making, receiving, and termination of telephone calls, the transition from presence-to-absence or absence-to- presence of other devices in a physical contact, RFID, near field, personal area, local area, metropolitan area or geographical area wireless communica- tions network, an alarm, notification, videogame action or event, electronic equipment change of state or measurement result.

24. A method as claimed in any one of claims 1 - 23, comprising upon sending the web push message to push client, the push server notifies a web server about the information content that is to be requested by the push client so that the content is created, formatted and available before an actual request arrives from the browser of the wireless terminal.

25. A method as claimed in any one of claims 1 - 24, comprising upon sending the web push message to the push client, the push server notifies a web server about web request it is about to receive so that secure delivery over the web is limited to the intended recipient.

26. A method as claimed in any one of claims 1 - 25, comprising upon sending the web push message to the push client, the push server notifies a web server about web request it is about to receive so that application-specific, user-specific and display preference-specific information necessary to properly, promptly and conveniently fulfill the request is available to the web server.

27. A method as claimed in any one of claims 1 - 26, comprising the push client in the wireless terminal detects a physical proximity of a device with a larger screen, or the device with a larger screen detects physical proximity of the wireless terminal, the push client is responsive to receipt of the web push message to launch a web browser in said device.

28. A method as claimed in any one of claims 1 - 27, comprising the push client in the wireless terminal detects a physical proximity of a terminal device with a higher display capacity, or the device with a higher display capacity detects physical proximity of the wireless terminal the push client transmits proximity information of the higher capacity device to the push server, or the large screen terminal transmits proximity information of the mobile terminal to the push server, the push server uses the proximity information as a trigger event for sending messages.

29. A method as claimed in any one of claims 1 - 28, comprising the push client in the wireless terminal detects a physical proximity of a terminal device with a higher display capacity, the push client transmits proximity information of the higher capacity device to the push server, the push server uses the proximity information as a trigger event for routing messages directed to the user of the wireless terminal to the higher capacity device.

30. A method as claimed in claim 29, comprising the push server stop directing messages to the higher capacity device when the wireless terminal is not in a physical proximity of the higher capacity terminal.

31. A method as claimed in any one of claims 28 - 30, comprising providing the higher capacity device with a push client similar that in the wireless terminal.

32. A method as claimed in any one of claims 1 - 31 , comprising the push client in the wireless terminal detects a physical proximity of a device with a network connection, or a push client in the device with a network connection detects physical proximity of the wireless terminal, establishing a data-transfer capability between the push clients, routing communication to and from the push client in the wireless terminal through the push client and the network connection of the device.

33. method as claimed in any one of claims 1 - 32, comprising customizing the appearance, notification sound or look and feel of the messages received to based on message source or message recipient preferences.

34. A method of pushing messages to a wireless terminal from a push server, comprising the push server sends, in response to predetermined trigger events, at any time web push messages to a push client in the mobile terminal, the push client in the wireless terminal detects a physical proximity of a device with a larger screen, or the device with a larger screen detects physical proximity of the wireless terminal, the push client is responsive to receipt of the web push message to launch a web browser in said device with a larger screen so as to view a web content identified by or contained in the received web push message.

35. A method of pulling messages to a wireless terminal from a push server, comprising a push client in the wireless terminal detects a physical proximity of a terminal device with a higher display capacity, or the device with a higher display capacity detects physical proximity of the wireless terminal the push client transmits proximity information of the higher capacity device to the push server, or the higher display capacity device transmits proximity information of the wireless terminal to the push server, the push server uses the proximity information as a trigger event for sending messages to the wireless terminal or the higher display capacity device.

36 A method according to claim 35, wherein the push server uses the proximity information as a trigger event for routing messages directed to the user of the wireless terminal to the higher display capacity device.

37. A method as claimed in claim 35 or 36, comprising the push server stops directing messages to the higher capacity device when the wireless terminal is not in a physical proximity of the higher display capacity terminal.

38. A method as claimed in any one of claims 35 - 37, comprising providing the higher capacity device with a push client similar that in the wireless terminal.

39. A method of routing messages to a wireless terminal from a push server, comprising the push server sends, in response to predetermined trigger events, at any time web push messages to a push client in the mobile terminal, a push client in the wireless terminal detects a physical proximity of a device with a network connection, or a push client in the device with a network connection detects physical proximity of the wireless terminal, establishing a data-transfer capability between the push clients, routing communication to and from the push client in the wireless terminal through the push client and the network connection of the device.

40. A method of pushing or pulling messages to a wireless terminal from a push server, comprising the push server sends, in response to predetermined trigger events, at any time web push messages to a push client in the mobile terminal, the push messages including an actual web content to be viewed, the push client functions as a caching proxy server, the push client, in response to receiving a web push message from the push server, initiates a launch of a web browser in the mobile terminal or in a nearby device to contact the caching proxy server so as to view the actual web content received.

41. A method as claimed in claim 40 wherein the caching proxy server accepts compressed information and decompresses such information for the web browser.

42. A method as claimed in 40 or 41 wherein the caching proxy server accepts partial updates, combines this with the cached information and transmits the resulting complete information to the web browser.

43. A method as claimed in any one of claims 40 - 42, wherein said trigger events include events which the push server is aware of and/or events which the push client is aware of and which the push client makes the push server aware of.

44. A server comprising means for performing the server steps as claimed in any one of method claims 1 - 43.

45. A wireless terminal comprising means for performing the push client steps as claimed in any one of method claims 1 - 43.

46. A program product comprising program code means which, when run in a computing unit of a wireless terminal, performs the push client steps as claimed in any one of method claims 1 - 43.

47. A program product comprising program code means which, when run in a computing device, performs the push server steps as claimed in any one of method claims 1 - 43.