Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
  • G06F9/544—Buffers; Shared memory; Pipes
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/16—Arrangements for providing special services to substations
  • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
  • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/16—Arrangements for providing special services to substations
  • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
  • H04L12/1881—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with schedule organisation, e.g. priority, sequence management

Definitions

• 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.
• 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.
• URL Uniform Resource Locator
• 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.
• MIDP Mobile Infor- mation Device Profile
• API application programming interfaces
• the MIDP combined with a connected limited device configuration (CLDC), is the Java runtime environment for today's compact mobile in- formation devices.
• 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.
• 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.
• AMS application management system
• JAM Java environment also called JAM
• a MIDIet is active (running)
• the Ml Diet itself is responsible for all communication events, such as setting up and monitoring inbound connections.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• Figure 1 is a block diagram illustrating an example of a device and a system according to an embodiment of the invention
• Figure 2 is a sequence diagram illustrating functionality ac- cording to an exemplary embodiment of the invention
• Figures 3 and 4 are flow charts depicting simulation according to an embodiment of the invention.
• Figure 5 is a flow chart depicting opening and closing of an accepted connection according to an embodiment of the invention.
• Figure 6 is a sequence diagram illustrating functionality according to another exemplary embodiment of the invention.
• 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.
• 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.
• 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.
• 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.
• 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.
• WMA wireless messaging API
• 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.
• 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.
• the external agent is responsible for initiation of inbound connections, among other things.
• the sending external agent 23' may locate in the same device as the receiving party.
• a device may comprise the agent, the M I Diet and the AMS, in which case the agent is external to the Ml Diet.
• one device may be a send- ing device to a party and a receiving device to another party.
• 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.
• 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.
• the buffer size and actions to be taken when the buffer overflows depend on the implementation.
• 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.
• 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.
• the network providing the connection between the sending device 2' and the receiving device 2 is based on the Bluetooth Wireless Technology.
• 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.
• 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.
• MIDP 2.0 the responsibility for push connections is shared between the MIDIet and the AMS.
• 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.
• the inbound connections are accepted, inbound connections occur successive, and the MIDIet registers only one endpoint.
• 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.
• an external agent EA1 such as the device 1
• 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.
• 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.
• the AMS allocates a buffer from the memory specifically for this connection and stores the data in the allocated buffer.
• the external agent EA1 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.
• another external agent EA2 such as the device 2, sends operation 2-4' (connect) to the (same) M I Diet.
• 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 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.
• the external agent EA2 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.
• no operation 2-5' is sent, i.e. no attempt to auto-launch a MIDIet having a pending auto-launch request is made twice.
• the prompt is still preferably modified to indicate that another inbound connection has been initiated.
• the MIDIet is finally launched, in point 2-10, and the monitoring of incoming connection attempts reverses to the responsibility of the MIDIet.
• the AMS recognizes that the MIDIet wishes to open the connection corresponding to a registered endpoint and returns the appropriate connection object.
• connection notifier.acceptAndOpen()
• 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
• the MIDIet then closes the connection (not shown in Figure 2) and performs the same open, read and close operations on the second connection
• connection notifier.acceptAndOpen
• 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
• the MIDIet closes this connection (not shown in Figure 2).
• connection notifier.acceptAndOpen
• 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.
• an external agent EA3 connects, and acceptAndOpenQ returns (operation 2-15") and MIDIet can start communicating (2-21 ) directly with the EA3
• connection notifier acceptAndOpen()
• 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'.
• the AMS may send the exception or a corresponding notification only after all buffered data has been read.
• 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.
• all the MIDIet has to do is to open all its registered connection end- points.
• 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).
• 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.
• 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.
• 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 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.
• step 304 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).
• step 307 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
• 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.
• 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.
• step 312 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.
• AMS simulates an accepted but closed connection with available data as an active connection to a MIDIet.
• 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.
• 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).
• the AMS 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.
• 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.
• FIFO first in first out
• 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.
• 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.
• 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.
• 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
• step 504 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
• step 502 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- bomb 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.
• Figure 6 shows a sequence diagram illustrating an example according to another embodiment of the invention, the embodiment not being based on current MIDP.
• 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.
• 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.
• the AMS starts to monitor, in point 6-4, connection attempts on behalf of the MIDIet.
• an external agent EA2 sends operation 6-5 (connect) to the MIDIet in order to send data
• 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 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.
• the external agent EA2 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.
• 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.
• 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.
• the operations may be different from the above-mentioned operations and, instead of operations, some other format may be used.
• the above embodiments uses a FIFO principle, i.e. data is read in the order in which corresponding connections occurred.
• 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.
• 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.
• 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.
• 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).
• ASIC application circuits
• EPLD Electrically Programmable Logic Device
• FPGA Field Programma- ble Gate Array
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Electrophonic Musical Instruments (AREA)

Priority Applications (1)

Applications Claiming Priority (2)

Publications (1)

Family

ID=34224257

Family Applications (1)

Country Status (3)

Citations (3)

Family Cites Families (5)

• 2005
  • 2005-02-01 FI FI20055046A patent/FI20055046A0/sv not_active Application Discontinuation
• 2006
  • 2006-01-30 WO PCT/FI2006/050047 patent/WO2006082284A1/en active Application Filing
  • 2006-01-30 EP EP06704375A patent/EP1847078A4/en not_active Ceased

Patent Citations (3)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events