BACKGROUND OF THE INVENTION The next generation mobile networks represent potent business opportuni- ties in the near future. These networks will to some extent meet the users'need for increased bandwidth and terminal functionality, but many more will require advan- ced techniques for managing data across a user client/server infrastructure in which users will want to use a docking station, a wireless local area network con- nection or the infrared communication port of their devices to download data chea- per and faster.

Following the introduction of new mobile infrastructures such as GPRS, Edge and UMTS as well as a growing number of handheld devices with wireless capabilities, a new user group will emerge: mobile users with a high set of expec- tations and demands. They will rely on their mobile IT for work and personal use.

Larger and more critical datasets will be involved. Vertical applications (with enter- prise data models, large spreadsheets and business graphics, massive amounts of historical and statistical data and architectural diagrams) as well as horizontal ones (gaming storyboards, audio, video and pictures) will challenge the available bandwidth and storage spaces of mobile devices.

Enabling users to select (either implicitly, based on their actions, or expli- citly, based on portal-managed profiles) and schedule data to be moved from the Internet/intranet to their mobile devices, offers a great improvement in the useful- ness of these devices for most domains.

The convergence of communications and mobile computing devices will continue to grow significantly. By 2004, there will be more non-PC devices acces- sing the Internet than there will be PCs, and consequently users will demand more

from their software. Operators will offer compelling new services, and in addition, applications with a richer functionally will become available in numbers for indivi- dual users and organizations to download and install for themselves.

Mobile aware portals are becoming widespread and they will become im- portant tools for users who want to streamline users'access to data for communi- cation, entertainment, and business services. Moreover, the wireless market has lately seen a tremendous increase in the interest for, volume of and number of recent market entries of companies providing software of converting and filtering HTML pages so that they become suitable for presentation on mobile devices. It is, however, the opinion of the inventors that the need for a more flexible applica- tion framework comprising integration with wireless connections and predictive, profile-based"aggressive caching"has not been met by previous inventions.

The increasing popularity of wireless terminals and mobile telephony provi- des significant opportunities to provide highly personal, location-aware, interactive data streams to high-volume users. Customers will not accept to work only at their desktops. At the same time, the PC experience will lead them to demand increa- singly sophisticated technologies to enable continual and well-adapted access to their critical data.

Today, we find that mobile handsets have increasing processing power.

Mobile CPU are typically in the 200 MHz range. Bandwidth, however, continues to be meager. GMS data calls have a throughput of a little more than 6-7 kBit (on 9.6 kBit connections), and GPRS will offer only partial improvement over that (20 kBit). We may assume that this relationship will hold well into the proliferation of UMTS networks, which may start as"low"as 50 kBit. At some point in the fut- ure, bandwidth will perhaps be abundant. Due to disappointing progress in battery technology, however, we may at that point start to experience reduced growth in CPU processing power and storage space.

The inventors believe that wireless access will come to all applications, and that mobile applications will need to rely on smart ways of managing their data be- tween the network and the mobile devices. Yet, one of the biggest obstacles to en- abling a widespread adoption of mobile IT is the prohibitive cost and complexity for

users maintaining (and often moving for off-line browsing) their content from the network-based servers or desktop PCs to much smaller storage and display scre- ens of their mobile terminals.

Bandwidth is still limited and costly. As bandwidth increases in the near fut- ure, so will cost. I-MODE in Japan costs approximately 0, 3 cents per 128 bit pac- ket today. This means that a 5 minute continuous download across GPRS on 20 kbit/s may be expected to cost as much as $144.

As a result, mobile data users are becoming very interested in finding ways of making larger amounts of data available to them in a more efficient way.

Users have to trade off the time it takes to prepare data for synchronization with their mobile device, against the cost of downloading it across an expensive GSM or GPRS network connection. Anyway, it is very difficult to anticipate the needs of a mobile work situation (indeed, the need for time-, situation-and location specific action is usually why users go mobile in the first place).

In the mobile future there will be an enormous need for flexible, clean, sim- ple and efficient data management, especially between the desktop computer and the handsets. All mobile applications will require tailored data management, trans- fer and synchronization services. Simple applications for caching web-pages sim- ply will not suffice, because: The users will look for optimal transfer and management of data, relative to location, pricing of the services, time of the day, processing priorities on the CPU and use context. Therefore, the underlying platform must offer intelli- gent, user-profile based and flexible data transfer mechanisms.

The users will want to be able to intelligently combine items of information, such as calendar entries, email messages and documents. Thus, the plat- form needs to provide a query-based cache control.

The users have no time or interest in manually managing available space on the devices. Information items that are stored manually must have higher priority than what is in the cache. On the other hand, if there is, indeed, available space, the user will not accept to be caught in an off-line situation without essential data, but disproportionate free space on a small device.

Users will therefore be highly motivated to use software that can predict and schedule downloads to a local cache when the device is in the cradle or accessing the net via W-LAN or Bluetooth. Moreover, the software should be amenable to filter and adapt content, especially for necessary data man- agement across wireless telecom networks.

This is exactly what the present invention relates to.

The invention is an application development framework for intelligent and efficient data management in a mobile environment.

BRIEF SUMMARY OF THE INVENTION In accordance with the present invention there is provided a system for data management between a server infrastructure and mobile user clients, said system comprising a first plurality of cores and a second plurality of services utilizing one such core to perform various tasks for a user. The system of the invention is char- acterized in that a core comprises at least one special server within said infrastruc- ture and a user PDA in a user mobile device, said at least one special server and said PDA connected by an interface; and that every said service comprises an application running on said user mobile device, and a plug-in on the special server side.

Preferred embodiments of the system of the present invention are presen- ted in the appended dependent claims 2-10.

In another aspect of the present invention there is provided a method for data management between a server infrastructure and mobile user clients, said system comprising a first plurality of cores and a second plurality of services utiliz- ing one such core to perform various tasks for a user. The method of the invention is characterized in that at least one special server within said infrastructure coope- rates with a user PDA in a user mobile device across an interface, to constitute a core; and that an application running on said user mobile device cooperates, via said core, with a plug-in on the special server side, to constitute a service among said second plurality of services.

Favorable embodiments of the method in accordance with the invention will appear from the appended dependent claims 12-20.

The invention makes it possible for user clients to request data to be collec- ted and compiled on the server side according to a combination of profiles corres- ponding to the individual user, application, and system and network characteris- tics. The server side can collect and compile heterogeneous user data from a plur- ality of sources. Through plug-ins, the server side can format and re-format user data in a plurality of ways, determined by the application programmer. The server side responds upon successfully achieving the criteria of the profiles and estab- lishing a connection to the client between potentially intermittent periods of not being connected. The connection uses XML as its exchange protocol formatting method. The connection can roam across network adapters and network types. It can resume after being disconnected before completion. The user can access the repository thus created by the user client locally either through a user program that is separate or fully integrated with said repository.

The system of the invention will work as an integrated part of mobile appli- cations. It will define, retrieve and filter data. The transfer of data will be optimized according to cost and affectivity, so that the workload is moved from the user to the inventive system, and the"payload"is moved from expensive wireless access to the cradle or license-free W-LAN or Bluetooth connections. The system in accordance with the invention is not a synchronization program, but such function- ality can be built into all applications using the system and method of the invention.

In addition, the system of the invention supports trouble free caching by using available space (which it releases upon request) and seamlessly following its tar- get terminal across changing connections.

BRIEF DRAWING DESCRIPTION In the following, embodiments of the invention will be explained in more de- tail, by way of example and with reference to the appended drawings, of which fig. 1 illustrates schematically the system services of the present invention, fig. 2 depicts, in a schematic manner, the two main components of the sys- tem core of the present invention, and the associated services, fig. 3 illustrates schematically system interaction via various interfaces, fig. 4-7 shows possible screen presentation sequences in connection with use of the embodiments of the present invention.

DETAILED DESCRIPTION As more and more users start depending on their mobile data access for business critical and leisure applications, they will also become conscious of the benefit of intelligent mobile data management. There are three essential challen- ges associated with keeping data between the network and the mobile device, which, if resolved, will become strong value drivers for our proposal: 1. Cost of data transfer: Users may be willing to pay almost as much for solu- tions that save bandwidth costs if data transfer needs can be anticipated, prescheduled to when the device is in the cradle, or seamlessly migrate from GPRS to W-LAN connections when that becomes available.

2. Cost of time and attention: This is much harder to fixate in numbers, but our guess is that users will be willing to pay more for an application that helps them move data between the network and the mobile device without explicit effort and the harassment of always having to remember every little item that needs to be synchronized before going offline or onto a more expen- sive connection.

3. Impedance mismatch: Users may be willing to pay more for an application that formats their data according to their profiles, needs in a particular work- ing situation and the devices that they are currently on. The system of the present invention knows which device it sits on and it may come integrated with an application. Compared to the"HTML adaptation"strategy of our competitors, we expect this functionality to receive appraisal.

System Overview The system of the present invention is a highly intelligent and efficient sys- tem for data management between a server infrastructure and mobile clients. It provides mechanisms that utilize the available storage space in a mobile device to cache data in a predictive manner. Referring to figs. 1 and 2, the inventive system consists of a core, and services utilizing the core to perform different tasks for the user. The services are divided into an application running on the mobile device, and a server side plug-in.

The server side plug-in collects, adapts and offers information to the appli- cation. The application is responsible for presenting the information to the user.

The core serves as middleware between the plug-ins and the applications, offering a solution to the problems mentioned in the introduction of this description.

The core is divided into 2 main components: A special server and a PDA ("Personal Digital Assistant"). In figs 2 and 3, the expressions"Cartmel Server" and"Cartmel PDA"designate just the special server and the PDAs.

The PDA client The system PDA sends requests from the applications to the system server when a network connection is available. It is also responsible for receiving the files and data that the server has collected. The PDA is designed to have a small foot- print, which is important when running on a mobile device with limited storage space. Responsibilities such as data processing and scaling have been assigned to server-side plugins, making the PDA as lightweight as possible.

The PDA includes functionality such as: Intelligent network monitoring. The connection to the special server is continu- ously monitored, as well as general connectivity to the Internet. If the user moves from one network to another, one can assume that the mobile device will be assig- ned a new IP address. The PDA senses this immediately, and informs the special server about the changed environment.

Multiple receivers. The PDA can receive data and files from several server plug- ins simultaneously.

Cache handling. The PDA has a special cache folder/repository where incoming data/files can be stored. The system monitors the cache folder and deletes files when the available storage space on the device is becoming scarce. The applica- tions can decide if they want the files returned from the special server stored within a cache repository or somewhere else, protected from being deleted.

The Special Server The special server receives requests from one or many PDAs that want tasks to be performed. Depending on the specified task, the server either performs

the task immediately, or schdules it for later processing. When a task is to be per- formed, the server loads the proper plugin. The plugin is responsible for collecting and compiling/structuring, arranging the data so that the PDA application can use it. When the plugin is finished, the special server sends the result back to the PDA.

The server offers functionality, which is suitable for mobile environments.

Dynamic network redirecting. Because the user is mobile, the current network address of the mobile device may change unpredictably. The special server auto- matically updates the references to all the connected devices when such events occur.

Handling of network failures. Mobile users are often on the move, which may re- sult in lost network connectivity. The system of the invention addresses this prob- lem by catching all exceptions thrown by the operating system and setting up the connection again when the network is available.

Data transfer with auto-resume support. Transferring large files on an unstable connection is cumbersome. Using standard file-transfer methods, a file must be re- sent if connection is lost. This can result in large overhead, and in extreme cases it may be impossible to get a large file transferred to the mobile device. The special server solves this problem by dividing files into smaller packets, which it sends to the mobile device. If the network connection is lost, it waits until the network is available and continues sending packets from where it left off. The PDA recon- structs the files by appending all the incoming packets sequentially.

Task Scheduling. The special server supports both immediate executions of in- coming requests, as well as archiving tasks. These tasks will be performed at a time specified within the task object received from the PDA.

Problems addressed by the server: Connectivity problems. The dynamic redirecting, network failure handling and auto-resume support makes it possible to transfer data even when the underlying network is unstable.

Time issues. The inventive task scheduling facility makes it possible to specify when information is to be collected and transferred. The information can be trans- ferred to the mobile device before the user needs to access it. For instance, rele- vant information about meetings could be transferred automatically before the meeting starts. In addition, auto-resume will often result in reduced transfer times.

Access restrictions. Since it is possible for the special server-side plugins to run in the same environment as the information source, the access restrictions of a mobile client can be bypassed.

The System SDK The inventive system includes an SDK ("Software Development Kit") that enables third party developers to utilize the system model, and therefore simplifies the development of mobile services.

Services implemented using the system SDK are divided into two parts: client applications and server-side plugins. The inventive system is designed as a dynamic architecture, and new plugins can be added to the system at runtime without restarting either the system client or server.

The following description of the SDK is based on the current prototype, im- plemented in Java.

To facilitate application development, all interaction with the system core is done via interfaces. Referring to fig. 3, the system of the invention implements 2 public interfaces; ICartmelPDA and ISender. In addition, the application developer must implement the interfaces lApplication and IPlugin. The communication flow is as follows : The application creates a Task object, which describes which plugin to load on the server side. The task object also contains details on operations the plugin shall perform.

The Task object is sent to the PDA through the interface ICartmelPDA.

The PDA waits until a network connection is available, and sends the Task object to the special server through the interface IServerListen.

The special server analyses the Task object, and decides if the task shall be performed at once or schduled for later execution.

The special server loads the appropriate plugin, and tells the plugin to per- form the task specified within the Task object. This is done through the interface IPlugin.

The plugin performs the task, and send results (either when it's done or continuously) back to the PDA through the interface IPDAListen.

The application is notified when the PDA has received a message/file/folder from the server. This is done through the interface lApplication. Special notice should be taken of the fact that the application receives a request for each file the plugin wants to send, and must decide if the file shall be transferred to the PDA or not.

Examples The system and method of the present invention are currently being evalu- ated with 4 trial version applications. The domains are 1. Information gathering related to implicit user profiles based on e. g. calendar entries, see fig. 4. The application, called"MeetingButler'is described briefly below.

2. Large file download in multiple interrupted sessions, e. g. audio files, see fig. 5. The application, called"MobileMusic"is described briefly below.

3. Systems administration and backup/restore, see fig. 6. The application, called"SysAdm"is described briefly below.

4. Voice capture, review and upload to archive, see fig. 7. The application, called"MobiVoice"is described briefly below.

MeetinqButler With MeetingButler, the user of a mobile device can rely on implicit user profiles built through ordinary use of calendar or remainder tools (such as Microsoft Outlook or similar programs) to govern the synchronization of data over an intermittent connection to the server containing personal or enterprise informa- tion and data files.

For instance, keywords may be collected from a calendar entry ("keyword 1" in fig. 4) or meeting location ("keyword2"). The user can then designate a"caching profile"for these keywords, in our example the user has opted for"Cost free"syn- chronization. This means, then, that upon getting a connection through cradle or WLAN, the underlying infrastructure of the invention described in these documents will fire a request, compile and collect data on the server, and schedule it for retrie- val to the mobile device. In the example of fig. 4, the second screen shows a hit of "keyword1"or"keyword2", which have then (under the constraint of a cost-free connection still, or at a later stage, being in place) been transferred back to the mobile device. The files are converted from a stationary PC-format to a mobile for- mat by our application.

MobileMusic Similarly to MeetingButler, MobileMusic supports the construction of user profiles, albeit explicitly according to the user's taste in music. In fig. 5, the first screen shows a user interface to this application, with one song within the"Rock" genre already uploaded. The second screen shows how the user can specify a task, of fetching one new song within the genre"Electronica", with a high priority and short deadline (for a large MP3-formatted file), which will also be converted to the format chosen by the user.

Upon establishing a connection of the type specified in the"caching profile", the underlying infrastructure of the invention described here, will fire a request, compile and collect data on the server, and schedule it for retrieval to the mobile device. Importantly, for large MP3-formatted files, the underlying infrastructure of the invention described here, will suspend and resume the synchronization pro- cess through interrupted sessions (due to, e. g. network failure) or the user roam- ing from one network infrastructure (e. g. GSM) to another (e. g. WLAN).

SvsAdm SysAdm, as shown in fig. 6, is an application that can greatly alleviate the tro- ubles of a systems administrator in maintaining software updates, code libraries, passwords and scripts, as well as backup and restore data (not shown in the illu- stration) to mobile devices. It works by :

1. Allowing the user to log into a"SysAdm"server (built using the underlying infrastructure of the invention described here), and requesting an offer from the systems administrator of new updates to the mobile system.

2. Allowing the systems administrator to automatically schedule updates that this department wants the users'mobile device to get.

3. The user can then select which ones from the list of offered updates to up- load, and ask to get the selected installation scripts (in CAB-files) transfer- red. Importantly, for large CAB-formatted files, and even more so for back/restore operation that even on a fixed USB connection may take seve- ral hours, the underlying infrastructure of the invention described here, will suspend and resume the synchronization process through interrupted ses- sions (due to, e. g. network failure) or the user roaming from one network in- frastructure (e. g. GSM) to another (e. g. WLAN).

4. After having received all files, the user can review the"caching repository" of the SysAdm application, and: 5. Finally, the user can instruct the SysAdm application to install the selected files, which have now been safely synchronized even across a potentially intermittent mobile or fixed network connection using the underlying infra- structure of the invention described here.

MobiVoice MobiVoice, shown in fig. 7, is a mobile application developed to Capture dictated voice files in a format that represents a small enough file size to be transmitted over wireless networks Allow a physician to'tag'the voice file with meta-information o Physician id # o Work type-a number between 0 and 999999 o Priority-a number between 0 and 9 o All coding information can be delimited in the filename Allow a physician to review dictations prior to sending, potentially Discarding unwanted files

The physician will trigger the sending of the voice files. Files will be transferred via FTP (preferably using SSL), and then upon successful transmission, deleted from the device.

Importantly, for large audio files, the underlying infrastructure of the invention described here, will suspend and resume the synchronization process through in- terrupted sessions (due to, e. g. network failure) or the user roaming from one net- work infrastructure (e. g. GSM) to another (e. g. WLAN).