EP1847078A1

EP1847078A1 - Handling incoming data

Info

Publication number: EP1847078A1
Application number: EP06704375A
Authority: EP
Inventors: Alexander Davydov
Original assignee: Nokia Oyj
Current assignee: Nokia Technologies Oy
Priority date: 2005-02-01
Filing date: 2006-01-30
Publication date: 2007-10-24
Also published as: WO2006082284A1; FI20055046A0; EP1847078A4

Abstract

So-called push technology enables reception of new contents automatically, i.e. without user initiation. In order to enable a connecting party to send data when a receiving application is not even running, and thus cannot receive the data, middleware simulating the application to a connecting party, and an active connection to the application by utilizing buffers is provided. More precisely, the middleware is arranged to buffer incoming (6-7) data on behalf of the application, if the application is not receiving the data, and to allow (6-12) the application to receive (6-13) the buffered data when the application is again willing to receive the data.

Description

HANDLING INCOMING DATA

FIELD OF THE INVENTION

[0001] The present invention relates to handling incoming data, and particularly to buffering incoming data when an application to which the data is targeted is not active or not receiving the data for other reasons.

BACKGROUND OF THE INVENTION

[0002] The evolvement of communication technology and user terminals has enabled versatile communication possibilities. The number of procedures to be carried out by a wireless terminal device, such as a mobile sta- tion or a personal digital assistant (PDA), has increased considerably as a result of advances in mobile communication technology. For example, a mobile station is no longer used for calls exclusively, but the mobile station enables information to be processed and presented in a more and more versatile manner. [0003] Different software applications for versatile communications have also evolved alongside. The introduction of hardware and software independent wireless Java programming language, and especially J2ME (Java 2 Platform, Micro Edition) technology, which is suitable for the range of extremely tiny commodities such as smart cards or a pager all the way up to the appliances as powerful as a computer, has accelerated the usage of web services via different applications called M I Diets. The M I Diets are applications designed to run on wireless Java-enabled devices, and they can access objects across the Internet via URL (Uniform Resource Locator) addresses as easily as on a local file system. Usually, the M I Diets conform to Mobile Infor- mation Device Profile (MIDP) specification that specifies the architecture and the associated application programming interfaces (API) required for enabling an open third-party application development environment for mobile information devices. The MIDP, combined with a connected limited device configuration (CLDC), is the Java runtime environment for today's compact mobile in- formation devices.

[0004] The MIDP 1.0 specified only one way to start a MIDIet: manual activation by the user. This lack of choices limited the range of services that a MIDIet could provide; in particular, there was no way to receive new contents automatically. To overcome this, the MIDP 2.0 specification introduced two new mechanisms to launch a MIDIet: in response to an incoming connec- tion or at a scheduled time, i.e. without user initiation. These mechanisms make whole new classes of services possible by enabling receiving and acting on data asynchronously. The new mechanisms utilize an application management system AMS, in Java environment also called JAM, which is responsible for each application^'s life-cycle (installation, activation, execution, and removal), and especially a component called Push Registry in the AMS. When a MIDIet is active (running), the Ml Diet itself is responsible for all communication events, such as setting up and monitoring inbound connections. When a MIDIet is not active, it can request the AMS to monitor inbound connections on behalf of the MIDIet and when an inbound connection occurs, the AMS activates the MIDIet to handle the inbound connection.

[0005] In MiDP, inbound connections may be message-based, such as short messages, stream-based, such as a TCP socket, or packet-based, such as a datagram. The message-based inbound connections may buffer a pushed message. However, when an inbound connection is not message- based the MIDIet must open the connection promptly because a connecting party may start sending data immediately after the connection has been set up. One of the problems associated with the above arrangement is that it may take some time before the MIDIet is actually auto-launched and able to start to communicate with the connecting party, only after which, data can be received. The delay may be quite significant, especially if a user approval is needed to auto-launch the MIDIet. Situations may then exist in which the connecting party starts to send data although the receiving MIDIet is not yet running, and thus cannot receive the data.

BRIEF DESCRIPTION OF THE INVENTION

[0006] An object of the present invention is to provide a method and an apparatus for implementing the method so as to overcome the above problem. The object of the invention is achieved by a method, an electronic device, a system, and a computer program product that are characterized by what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.

[0007] The invention is based on the idea of realizing the above problem and providing a mechanism for allowing incoming data to be received and stored in corresponding buffer(s) when the targeted application is not run- ning or not receiving for other reasons the data at the time the data begins to corne in, and to enable the application to read the received data from the buffer(s) even when the connection via which the data was received no longer exists. In other words, the invention is based on middleware between the actual application and operating system, the middleware simulating the actual software to the connecting party, and an active connection to the actual software by utilizing buffers.

[0008] An advantage of the above aspect of the invention is that if the receiving application is not launched in time, data is not lost but the application can recover the data, even if the connection is lost. Another advantage is that the connecting party can start sending data immediately after the connection has been established, regardless of whether or not the application is already running.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In the following, the invention will be described in greater de- tail by means of exemplary embodiments and with reference to the accompanying drawings, in which

[0010] Figure 1 is a block diagram illustrating an example of a device and a system according to an embodiment of the invention;

[0011] Figure 2 is a sequence diagram illustrating functionality ac- cording to an exemplary embodiment of the invention;

[0012] Figures 3 and 4 are flow charts depicting simulation according to an embodiment of the invention;

[0013] Figure 5 is a flow chart depicting opening and closing of an accepted connection according to an embodiment of the invention; and [0014] Figure 6 is a sequence diagram illustrating functionality according to another exemplary embodiment of the invention.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

[0015] The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several loca- tions, this does not necessarily mean that each such reference is made to the same embodiment(s), or that a particular feature only applies to a single embodiment.

[0016] The present invention is applicable virtually to any communications environment in which applications need to be started in response to incoming connections. The communications environment may be based on a fixed communications system and/or a wireless communications system and it may be even within a communications device. Applications, communications systems, environments, and devices, such as terminals, especially in wireless communications, develop rapidly. Such development may require extra changes to the invention. Therefore, all words and expressions should be interpreted broadly, and they are intended to illustrate, not to restrict the invention.

[0017] In the following, the present invention is described using, as an example of a system environment whereto the present invention may be applied, an environment relying on J2ME interfacing a CLDC virtual machine environment, wherein Bluetooth API is utilized, without restricting the invention thereto; the invention is programming language independent, as well as environment and API independent. It should be appreciated that the environments and the transmission methods used are irrelevant to the actual invention. Therefore, they need not to be discussed in more detail here. The present invention primarily relates to buffering incoming data on behalf of a target application that was either not active or not willing to receive the data at the moment when the data began to come in. In this respect, the applications have a first mode in which the application is receiving data and a second mode in which the application is not receiving data.

[0018] Figure 1 shows a very simplified system architecture only comprising a communications system 1 , two devices 2, 2' and a network 3. It is apparent to a person skilled in the art that the system also comprises other devices, system entities, functions and structures that need not be described in detail herein.

[0019] A device 2 may be a user terminal or another piece of equipment that supports push technology principles and allows an application to be launched in response to an inbound connection to the application. The push technology principles mean that information may be sent to a target ap- plication/device without a separate request by the target application/device/user of the device. To support the push, the device must support one or more inbound connection types, such as socket, datagram or wireless messaging API (WMA), an example of the latter one being SMS (Short Message Service) messages. Thus, the device 2 may be any node or a host, pro- viding data transmission and/or data and reception preferably capable of communicating over a network and/or with a network (if necessary). The de- vice 2 may be a non-mobile apparatus, such as personal computer PC or a server, connectable to the network 3 wirelessly or via a fixed connection. The device 2 may also be a wireless mobile apparatus, such as a mobile terminal or a PDA. The device is preferably a multi-service device capable of running multiple applications that are able to receive incoming data from several devices, even simultaneously, via a network interface, for example. Such devices are illustrated in US patent application publication US 2004/0186918 A1 , which is incorporated herein by reference. However, the invention is also applicable to devices capable of running one application that supports the push technol- ogy and may receive data only from one connecting party at a time.

[0020] In the example of Figure 1 , the data receiving device 2 comprises one or more applications herein called M I Diets, 21 and an application management system AMS 22, or JAM in a Java environment, and a connecting party, i.e. data sending device 2' comprises an external agent 23'. An agent here covers a remote application, a connecting application, and as well as the part of the system/device that performs information preparation and exchange on behalf of a client or server application in the client-server model. Thus, the external agent is responsible for initiation of inbound connections, among other things. However, it bears no significance to the invention how the connecting party, i.e. the external agent, is implemented and what features the connecting party contains. In some other embodiment of the invention, the sending external agent 23' may locate in the same device as the receiving party. In other words, a device may comprise the agent, the M I Diet and the AMS, in which case the agent is external to the Ml Diet. Naturally, one device may be a send- ing device to a party and a receiving device to another party.

[0021] The AMS 22 is, as described above, middleware that knows how to load MIDIets, where to store them, and how the user can launch them and for a closed M I Diet whether or not there are any connecting parties waiting for a MIDIet launching. A component of the AMS called Push Registry (not shown in Figure 1 ) is in the MIDP 2.0 the component that exposes the push API and keeps track on push registrations, i.e. on connection endpoints registered by MIDIets (below also referred to simply as endpoints). Since the division of functions between the Push Registry and the AMS is rather artificial and implementation dependent, the AMS is herein used as also covering the Push Registry, and no division of functions is performed for the sake of clarity. The AMS, or the push registry of the AMS, according to the invention com- prises one or more buffers 221 for inbound connections. Preferably, a separate data buffer exists or is allocated from a memory in response to an inbound connection to an endpoint (i.e. for each separate external agent/remote device sending data to a certain endpoint), the buffers being maintained endpoint- specifically. The invention does not restrict the number of buffers for one end- point. Furthermore, the buffer size and actions to be taken when the buffer overflows depend on the implementation. However, the buffering technique used bears no significance to the invention. For example, incoming data may be stored in a common buffer as long as from point of view of the M I Diets the data received from an external agent is separate from data received from another external agent, and that the data can be dispatched to a proper M I Diet.

[0022] It is apparent to a person skilled in the art that the device may also comprise other entities, functions and structures that need not be described in detail herein. Examples of these include processor(s), memory, input/output bus, different user interfaces, different APIs, network interfaces, a dispatcher with registry to oversee incoming data, as disclosed in the above mentioned US patent application publication US 2004/0186918 A1 , etc.

[0023] In the example illustrated in Figure 1 , the network providing the connection between the sending device 2' and the receiving device 2 is based on the Bluetooth Wireless Technology. However, the network may be some other near field wireless communication network, such as ultrawideband, Zigbee, IrDA (Infrared Data Association) based data transmission network, a WLAN (Wireless Local Area Network), or any other network implemented using wired or wireless data transmission technology. Wireless data transmission technology herein refers to any system that enables wireless data transmission to mobile terminals within the service area of the system. The system may also be GSM (Global System for Mobile Communications), GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), or any other corresponding mobile system. The network may also be a fixed network. It should be appreciated that the network bears no significance to the invention, and in some embodiments no network is needed because information exchange occurs within a device.

[0024] In the embodiments illustrated with Figures 2 to 4, it is assumed that the AMS maintains a list of inbound connections that the AMS ac- cepted during the time the M I Diet was not running, the list also indicating whether the inbound connection is still active or disconnected (i.e. lost). How- ever, it bears no significance to the invention how the necessary information is maintained.

[0025] Figure 2 is a sequence diagram illustrating functionality according to an embodiment of the invention. More precisely, Figure 2 illustrates how the AMS simulates an active MIDIet to the sending party and an active connection to the MIDIet. In MIDP 2.0 the responsibility for push connections is shared between the MIDIet and the AMS. To become push-enabled, the MIDIet has to register itself with the AMS for connections to a certain, and more precisely, with the Push Registry, with certain attributes, including al- lowed senders. In the example of Figure 2, it is assumed, for the sake of clarity, that the inbound connections are accepted, inbound connections occur successive, and the MIDIet registers only one endpoint.

[0026] In the sequence diagram of Figure 2, the MIDIet registers itself for connections to the endpoint, by sending operation 2-1 (Register Con- nection) to the AMS, whereafter the MIDIet closes, in point 2-2. Because of the registration and the MIDIet closing, the AMS starts to monitor, in point 2-3, connection attempts on behalf of the MIDIet. In other words, the AMS listens to data connections to the registered endpoint.

[0027] When an external agent EA1 , such as the device 1 , sends operation 2-4 (connect) to the MIDIet in order to send data, for example, the AMS accepts the connection (not shown in Figure) and sends operation 2-5 (activate MIDIet) in order to auto-launch the closed MIDIet and, depending on the implementation, may prompt the user about the auto-launch and even request permission to auto-launch. Furthermore, the AMS updates the inbound connection as accepted, in point 2-6, in the list. Since the external agent EA1 assumes that the MIDIet is running, it sends data, in operation 2-7, to the MIDIet although the MIDIet has not yet been launched. The AMS buffers, in point 2-8, the received data. In other words, the AMS allocates a buffer from the memory specifically for this connection and stores the data in the allocated buffer. When the external agent EA1 has nothing more to send, it disconnects (operation 2-9), (or the connection is lost due to other reasons, such as the device 1 moving out of the Bluetooth range) and the AMS updates the list about this accepted connection being closed but some data being stored in the buffer, and continues to monitor, in point 2-13, communication events on be- half of the MIDIet. [0028] Then another external agent EA2, such as the device 2, sends operation 2-4' (connect) to the (same) M I Diet. This may occur parallel or overlapping with the above-described communication of the external agent EA1 , provided that the receiving device supports parallel inbound connections. However, in this example they are successive connections. In response to operation 2-4', the AMS accepts the connection and sends operation 2-5' (activate M I Diet) in order to auto-launch the M I Diet and, depending on the implementation, may prompt the user about the auto-launch and even request permission to auto-launch. The AMS also updates, in point 2-6', the list about in- bound connection now being an accepted connection. Since the external agent EA2 also assumes that the Ml Diet is running, it also sends data, in operation 2- 7', to the MIDIet although the MIDIet has not been launched yet. The AMS, according to the invention, buffers, in point 2-8', the received data. For buffering this received data, the AMS preferably allocates a second buffer in which the data is stored. When the external agent EA2 has nothing more to send, it disconnects (operation 2-9'), and the AMS updates the list about this accepted connection being closed, and continues to monitor, in point 2-3", communication events on behalf of the MIDIet. Another reason for the disconnection may be that the device 2 moved out of the Bluetooth range, for example. [0029] in some other embodiment of the invention, no operation 2-5' is sent, i.e. no attempt to auto-launch a MIDIet having a pending auto-launch request is made twice. However, if the user is prompted about the auto-launch, the prompt is still preferably modified to indicate that another inbound connection has been initiated. [0030] Then the MIDIet is finally launched, in point 2-10, and the monitoring of incoming connection attempts reverses to the responsibility of the MIDIet. The MIDIet then attempts to open all its registered connection end- points, i.e. in this example, the connection corresponding to the only registered endpoint, and sends operation 2-11 (notifier=Connector open()) to the AMS, The AMS recognizes that the MIDIet wishes to open the connection corresponding to a registered endpoint and returns the appropriate connection object. The MIDIet then tries to open the connection by sending operation 2-13 (connection = notifier.acceptAndOpen()). In response to receiving that, the AMS checks, in point 2-14, the contents of the list. In other words, the AMS checks if there are any accepted connections to this registered endpoint or if there is any data buffered for this endpoint. Now the list shows two accepted closed connections, thereby indicating that there is data received from two external agents in the buffers, and the AMS sends operation 2-15 (ι e. immediately returns the first accepted connection, as if it were still active. The M I Diet then sends operation 2-16 (readQ) to read the buffered data. The buffered data in the first buffer is read (2-17) and the AMS removes, in point 2-18, the connection relating to the first buffer from the list The Ml Diet then wishes to answer or perform any other operation on the first connection, and sends operation (2-19) targeted to the external agent 1. Since the inbound connection does no longer exists, the AMS returns an exception 2-20, which tells the M I Diet that the connection is no longer active

[0031] The MIDIet then closes the connection (not shown in Figure 2) and performs the same open, read and close operations on the second connection In other words, the MIDIet opens the second connection by sending operation 2-13' (connection = notifier.acceptAndOpen). In response to re- ceiving that, the AMS checks, in point 2-14', the list, as explained above. Now, because the list indicates that data received from the external agent 2 is in the buffer, the AMS sends operation 2-15', i.e. immediately returns the second accepted connection, as if it were still active. The MIDIet then sends operation 2- 16' (read()) to read the buffered data. The buffered data in the second buffer is read (2-17') and the corresponding connection is removed (2-18') from the list Next, the MIDIet closes this connection (not shown in Figure 2).

[0032] The MIDIet then tries to open another connection and sends operation 2-13" (connection = notifier.acceptAndOpen). In response to receiving that, the AMS checks, in point 2-14", the contents of the list as described above, i.e. the AMS checks whether there are any accepted connections to this endpoint or whether any data is buffered for this endpoint Now the list is empty, indicating that there are no active connections and no buffered data, and the operation acceptAndOpenQ blocks until a remote device connects. In this example, an external agent EA3 connects, and acceptAndOpenQ returns (operation 2-15") and MIDIet can start communicating (2-21 ) directly with the EA3

[0033] If the connection with the EA1 would have been alive when the MIDIet sent operation 2-13 (connection = notifier acceptAndOpen()), the MIDIet could have started to communicate with the remote device The same applies to the connection with the EA2. [0034] In another embodiment of the invention, the AMS may, in response to a buffer relating to a lost connection being read, send the M I Diet an exception or any notification to indicate to the MIDIet to close, i.e. send operation 2-13'. In a further embodiment of the invention, the AMS may send the exception or a corresponding notification only after all buffered data has been read.

[0035] As can be seen from the above, the MIDIet is able to read the data from external agents (for example, two different remote devices, or from two different connections from the same remote device) even after the connections are lost, although the MIDIet performs exactly the same functions as it would have performed in a situation in which the MIDIet would have been running when inbound connections occurred and data were sent. In other words, all the MIDIet has to do is to open all its registered connection end- points. Herein, attempts to open the inbound connections that are still active or those that were lost but contained some data will succeed (i.e. the MIDIet will open these connections), other attempts will block (i.e. the MIDIet will be blocked in waiting for new incoming connections). If the opened connection is in fact a lost one, an exception is thrown once the MIDIet reads the buffered data. After getting this exception, the MIDIet will immediately try to close the connection and to open the same connection again. If there is another lost inbound connection with data on the same endpoint, the MIDIet will again read the data, receive an exception, close the connection, and try to open the connection again, etc., until the MIDIet will be blocked in waiting for a new connection. [0036] As is apparent from the above, the present invention also provides a solution to a problem as how to deliver data received from different connecting parties to a MIDIet when it is finally launched, when a communication protocol used allows several connecting parties to connect and send some data to the same end-point before a MIDIet is auto-launched and able to re- ceive data. Furthermore, it is apparent from the above that although the invention is applicable to all types of inbound connections, it is especially suitable for end-to-end-orientated connections, i.e. for non-messaging-based connections. [0037] Figure 3 is a flowchart illustrating how the AMS simulates a running MIDIet to an external agent according to an embodiment of the inven- tion. In Figure 3 it is also assumed, for the sake of clarity, that all inbound connections are acceptable. Figure 3 starts when a MIDIet is closed and the AMS monitors, in step 301 , communication events, among other things. The AMS notices, in step 302, an inbound connection X for endpoint A, i.e. a connection targeted to the M I Diet that has registered for connections to endpoint A. The AMS then checks, in step 303, whether or not the MIDIet has been activated, i.e. whether or not an auto-launch command has been sent to the MIDIet. If the auto-launch command has not been sent yet, it is sent, in step 304, after which the connection X is accepted, in step 305, and updated, in step 306, in the list as an accepted connection. If the auto-launch command has been sent (step 303), the auto-launch command is not sent again but the AMS proceeds di- rectly to step of accepting the connection (step 305).

[0038] If the MIDIet has been launched (step 307), i.e. it has moved to an active state, is running, and has opened the registered endpoint, the inbound connection X is returned to the MIDIet and the MIDIet is now responsible for the inbound connection X (step 308). [0039] If the application has not been launched (step 307), and data

Xn is received over the connection (step 309), the AMS stores, in step 310, the received data Xn to a first empty buffer for endpoint A as long as the data comes in.

[0040] If the MIDIet is not launched (i.e. has not opened the regis- tered endpoint) during the data reception (step 311 ), and the inbound connection X is not terminated (step 312), the AMS continues the monitoring and repeating the above steps, or some of them, as many times as necessary until the MIDIet is launched after which the MIDIet starts to monitor inbound connections, possible retrieve data from the buffers, as explained above in connection with Figure 2 and will be discussed in more detail in connection with Figure 4.

[0041] If the inbound connection X is terminated (step 312), the AMS updates, in step 313, the list about the inbound connection X being a closed connection with data available, as described above with Figure 2. The AMS then continues the monitoring and repeating the steps as discussed above.

[0042] Although not shown in Figure 3 for the sake of clarity, when the MIDIet is closed again or uninstalled, or the MIDIet's ability to receive data sent without a request from the external agent is disabled by the MIDIet closing the connection or removing the endpoint from the registered ones, or the MIDIet launch is disapproved of, or the device containing the MIDIet is switched off, the AMS preferably empties buffers containing data for this end- point, or for all endpoints registered by the uninstalled MIDIet. Thus, if the M I Diet quits without reading the buffered data, the data buffered for the MIDIet is preferably lost. The fact that the data is not read indicates that the MIDIet is not interested in the data, and the data is thus not buffered in vain. [0043] Figure 4 is a flow chart illustrating an example of how the

AMS simulates an accepted but closed connection with available data as an active connection to a MIDIet. In the example of Figure 4, it is assumed that buffering is performed inbound connection specifically. The situation in Figure 4 starts after the MIDIet has opened a lost connection (with available data) to endpoint A, i.e. after operations in 2-13 and 2-15 in Figure 2. When the AMS receives from the MIDIet an operation relating to this lost connection to end- point A (step 401 ), the AMS checks, in step 402, whether or not the operation was a "close" one (i.e. an operation to close a connection the MIDIet assumes is active). If it was a "close" one, the AMS returns, in step 403, an acknowl- edgement indicating that the connection was closed. Since the connection was already closed, no further functions are required. If it was not a "close", the AMS checks, in step 404, whether or not the operation was "read". If it was not "read", the AMS returns, in step 405, an exception.

[0044] If the operation was "read" one (step 404), the AMS checks, in step 406, whether or not there is any buffered data for endpoint A. If all the buffered data has already been read (step 406), the AMS returns, in step 405, an exception. If there still is buffered data, the AMS sends, in step 407, data Xn from the buffer to which the data send over inbound connection X was buffered. While the data is read/send, the corresponding buffer is emptied. This way it is ensured that the data is stored and read according to FIFO (first in first out) principles. After a closed inbound connection has been simulated to be active, and the relating data is read, the inbound connection is then removed, in step 408, from the list. (There is no reason why the connection should be on the list of accepted connections any more.) [0045] It is apparent from the above that the MIDIet is able to access data sent to it while the MIDIet was not active by looping and reading the data.

[0046] Figure 5 is a flow chart illustrating opening and closing of a registered Bluetooth connection to endpoint A and how a MIDIet may access all received data by looping. Figure 5 starts when the MIDIet opens, in step 501 , a registered connection by sending notifier=Connector.open(). If the MIDIet wishes (step 502) to accept a connection to this endpoint, i e. is willing to communicate with someone, the MIDIet accepts the connection by calling the acceptAndOpenO in step 503. The AMS then checks, in step 504, whether or not there are accepted connections Accepted connections may be active connections or closed connections having buffered data. In other words, if the remote side did not send any data before disconnecting, the AMS behaves as if the push connection was not accepted

[0047] If there are accepted connections, the first accepted connection is returned in step 505 In other words, acceptAndOpen() returns immedi- ately. If the first accepted connection is no longer alive (step 506), the MIDIet may only read the buffered data in step 507. At some point the MIDIet ends the communication and closes the connection in step 508 (regardless of whether the data was read or not) In response to this, the connection is removed, in step 509, from the list of accepted connections After closing the connection, the MIDIet returns to step 502 to decide whether or not it is willing to communicate with someone.

[0048] If the first accepted connection is still alive (step 506), the MIDIet can, in step 510, start communicating with the corresponding device including reading any buffered data received from this device At some point the MIDIet ends the communication and closes the connection, i e. the MIDIet proceeds to the above-described step 508

[0049] If there are no accepted connections (step 504), the Accep- tAnsOpenQ blocks (step 511 ) until a remote device connects When a remote device connects, the corresponding connection is returned and the MIDIet can start communicating with the corresponding device, i e. it proceeds to the above-described step 510

[0050] If the MIDIet is not willing to accept any connections (step 502), the MIDIet closes, in step 512, the endpoint by invoking close() on a noti- fier object associated with the given registered endpoint. In response to the close(), all data related to lost connections to this registered endpoint are preferably discarded.

[0051] Figure 6 shows a sequence diagram illustrating an example according to another embodiment of the invention, the embodiment not being based on current MIDP. In the example of Figure 6, it is assumed, for the sake of clarity, that inbound connections are accepted, inbound connections occur successively, and a MIDIet has registered one endpoint. [0052] The sequence diagram of Figure 6 starts in a situation in which the MIDIet is active (i.e. running) and receiving data (operation 6-1 ) from an external agent EA1. In this example, the external agent EA1 disconnects (operation 6-2). The MIDIet then, after some time or immediately, sends opera- tion 6-3 to the AMS, operation 6-3 indicating to the AMS that the MIDIet, although running, does not wish to receive data. The reason bears no significance to the invention.

[0053] In response to operation 6-3, the AMS starts to monitor, in point 6-4, connection attempts on behalf of the MIDIet. When an external agent EA2 sends operation 6-5 (connect) to the MIDIet in order to send data, for example, the AMS accepts the connection (not shown in Figure 6). Since the external agent EA2 assumes that the MIDIet is willing to receive data, it sends data, in operation 6-6, to the MIDIet. The AMS, according to the invention, buffers, in point 6-7, the received data and updates a list indicating inbound connections having sent data. In other words, the AMS allocates a buffer from the memory specifically for this connection and stores the data in the allocated buffer. When the external agent EA2 has nothing more to send, it disconnects (operation 6-8), (or the connection is lost due to other reasons), and the AMS continues to monitor communication events on behalf of the MIDIet. [0054] The MIDIet then is again willing to receive data and sends operation 6-9 to the AMS. In response to this operation, the AMS stops monitoring, in point 6-10, and sends information on received data in operation 6-11. The MIDIet then wishes to read the data and sends operation 6-12 to read the buffered data. The buffered data in the corresponding buffer is read (6-13) and the AMS updates, in point 6-14, the list indicating inbound connections having sent data, i.e. it removes the connection relating to the emptied buffer from the list.

[0055] If the connection with the EA2 would have been alive when the MIDIet sent operation 6-12, the MIDIet could have started to communicate with the EA2 before or after reading the data in buffer.

[0056] In some other embodiment of the invention, the AMS may, in response to operation 6-9, i.e. instead of operation 6-1 1 , send the received data without any request from the MIDIet.

[0057] The steps, points and operations (function calls) and related functions described above in Figures 2 to 6 are in no absolute chronological order, and some of the steps, and/or points, and/or carrying out operations may be performed simultaneously or in an order differing from the given one. Other functions can also be executed between the steps/points or within the steps/points. Some of the steps/points or part of the steps/points can also be omitted. Other operations can be transmitted and/or other functions/points can also be carried out between the illustrated operations. For example, depending on how the functions are divided between the AMS and the Push Registry and whether the buffers locate in the AMS or in the Push Registry, some operations, such as "clear buffers", in response to a MIDlet closing, may be sent between the AMS and the Push Registry. The operations are only examples and may also comprise other information. Furthermore, the operations may be different from the above-mentioned operations and, instead of operations, some other format may be used.

[0058] The above embodiments uses a FIFO principle, i.e. data is read in the order in which corresponding connections occurred. However, it is possible that data is read in some other order, for example the user may give the order when accepting auto-launch, or the corresponding connections may have priorities, or a LIFO (Last In First Out) principle is used. Depending on the implementation, the AMS may buffer the data in a correct order, or the application may indicate to the AMS also the buffer wherefrom the data is to be read, for example.

[0059] Although in the above, the invention is described using M I Diets as an example of an application and the AMS as an example of middleware, it is obvious for one skilled in the art that the invention is applicable to any other type of user program and middleware. [0060] The system and devices implementing the functionality of the present invention not only comprise prior art means but also means for buffering incoming data on behalf of an application and means for simulating to the application inbound connections relating to the buffered data so that the data can be read by the application. More precisely, they comprise means for im- plementing an embodiment according to the present invention. All modifications and configurations required for implementing the invention may be performed as routines which may be implemented as added or updated software routines, application circuits (ASIC) and/or programmable circuits, such as EPLD (Electrically Programmable Logic Device) and FPGA (Field Programma- ble Gate Array). Generally, program products include routines, programs, modules, objects, components, segments, schemas, data structures, etc. which perform particular tasks or implement particular abstract data types and which can be stored in any computer-readable data storage medium and which may be downloaded into a device.

[0061] It will be obvious to a person skilled in the art that as technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Claims

1. An electronic device supporting push technology principles, the electronic device comprising at least an application having at least a first mode in which the application is arranged at least to receive incoming data targeted to the application and a second mode in which the application is arranged at least not to receive incoming data; and middleware arranged, in response to said application being in the second mode, at least to receive and buffer said incoming data on behalf of said application.

2. An electronic device as claimed in claim 1 , wherein the application is in the first mode when the application is running, and in the second mode when the application is not running.

3. An electronic device as claimed in claim 1 or 2, wherein the mid- dleware is arranged to inform the application on buffered data.

4. An electronic device as claimed in any one of the preceding claims, wherein the middleware is arranged to buffer the data inbound connection specifically.

5. An electronic device as claimed in any one of the preceding claims, further being arranged to indicate to the application an inbound connection relating to the buffered data as an active inbound connection regardless of the state of the connection.

6. An electronic device as claimed in any one of the preceding claims, the application and the middleware further being arranged to perform the buffering and reading the buffers in such an order that the buffers are read in the same order in which the inbound connections occurred.

7. A computer program product embodied in a computer readable medium and comprising program instructions, wherein execution of said program instructions cause a device containing the computer program product to receive and store incoming data in a buffer on behalf of an application to which the data is targeted in response to the application not receiving the data.

8. A computer program product as claimed in claim 7, wherein the execution of said program instructions further cause the device to indicate a connection relating to the buffered data as an active connection to the applica- tion regardless of the state of the connection.

9. A computer program product embodied in a computer readable medium and comprising program instructions, wherein execution of said program instructions cause a device comprising the computer program product to simulate an active application to a connecting party and an active connecting party to an application.

10. A computer program product as claimed in claim 7, 8, or 9 wherein the computer program product is middleware arranged, in response to the application not running, to perform the simulation or the receiving and buffering of said incoming data.

11. A computer program product as claimed in claim 7, 8, 9 or 10, wherein the execution of said program instructions further cause the device, in response to the connection being disconnected, to allow the application to only perform at least one action from the following group of actions: to read the buffered data and to close the connection.

12. A computer program product as claimed in claim 7, 8, 9, 10 or

11 , wherein the computer program product is arranged to perform the simulation or the receiving and buffering in response to the inbound connection relating to the incoming data being other than message-based connection.

13. A communications system supporting push technology princi- pies and comprising at least a first device comprising an application having at least a first mode in which the application is arranged at least to receive incoming data targeted to the application and a second mode in which the application is arranged at least not to receive incoming data; and a second device comprising an agent for sending data to the application over a connection; wherein the middleware is arranged, in response to receiving incoming data to an application, to buffer the data on behalf of the application, if the application is in the second mode, and to allow the application to receive the buffered data when the application is again in the first mode.

14. A communications system as claimed in claim 13, wherein the first device is capable of receiving data simultaneously over one or more connections from one or more second devices and the middleware is arranged to buffer incoming data in an order in which the connections occur and to allow the application to read data in an order in which the data was buffered.

15. A communications system as claimed in claim 13 or 14, wherein the connection is based on Bluetooth, the first device comprises a Java runtime environment based on a mobile information device profile comprising an application management system, and the middleware is arranged to be part of the application management system.

16. A communications system as claimed in claim 13 or 14, wherein the first device and the second device are integrated into one device and the connection is an internal connection.

17. A method for simulating an active connection between an application and a connecting party in communication environment supporting push technology, the method comprising at least: receiving data targeted to the application; buffering, in response to the application not receiving the data, the data on behalf of the application; and allowing, in response to the application willing to receive data after the buffering of the data started, the application to receive the buffered data.

18. A method as claimed in claim 17, further comprising buffering data inbound connection-specifically.

19. A method as claimed in claim 17 or 18, wherein the buffering is performed when the application is not running.

20. A method as claimed in claim 17. 18 or 19, further comprising clearing the buffers in response to an event from the following group of events: disapproving auto-launch of the application, closing the application before the buffered data is read, uninstalling the application, and disabling the support for push technology principles.