WO2002052804A1 - Methods for information delivery in an information delivery system - Google Patents

Abstract

The invention is concerned with a method of delivering information to one or more user terminals in one or more communication networks. Query messages are received from said user terminals, which are converted to a suitable form for further processing. The messages are processed in accordance with their content, the information requested in them is fetched, the information data is processed and replies are constructed. The replies are sent to the user terminals when they have been converted to a form suitable for the network of the user terminals. The fetched information data is processed into a suitable delivery format for the user terminal that receives the reply, e.g. converted into a more suitable display format.

Description

METHODS FOR INFORMATION DELIVERY IN AN INFORMATION DELIVERY SYSTEM

TECHNICAL FIELD

The invention is concerned with a method for information delivery in an information delivery system, which is connected to one or more communications networks.

TECHNICAL BACKGROUND

Computer networks consist of two or more computers which are connected together. A Local Area Network (or internal network) can consist of computers within a company, whereas a Wide Area Network can cover larger areas, such as several cities or even countries. The networks can be interconnected with cables, fibres and/or radio links.

The internet is an example of an intemetworked wide area network. This worldwide network can be used for communication and information delivery and information retrieval. The open and common internet has grown phenomenally during the last few years and a large number of sen/ices for large and small user groups have developed on the internet. Major reasons for the rapid growth of the internet is the openness of the network technology and the possibility for almost everybody to produce their own content and services on the network with small resources. Thus, the internet also allows services which have a relatively very small but globally sufficient user base.

There are also more closed, specialised networks in the world, such as the networks based mostly on telephone technology that are used by wireless communications devices. An example of this kind of network is the GSM cellular telephone network. Typically, the use of the networks and services on it, such as the Short Message Service (SMS), is limited to the customers of a certain telecom operator.

These specialised networks are mostly used for communications between two people as it is technically cumbersome to build general services on them, and different solutions are needed for the networks of different telecom operators. Because of this, only services for large user groups have been built on these networks, and thus there is no large group of information service producers as that of the internet.

Building a service to a network currently requires writing a traditional service program. Traditional programming is difficult, requires programming skills from the creator, and representing of the program in a certain exact form. Visual programming systems are also complex and hard to use and are not very well suited for information delivery between networks of very different types.

Different networks work with differing principles and deliver information in different formats and forms. Communication between computers takes place according to certain rules, which are called protocols and there are many different protocols.

TCP/IP (Transmission Control Protocol/Internet Protocol) is one such protocol and it is widely used on the internet. The IP protocol handles packets of data and determines where to send the packets so that they will reach the correct destination. TCP is a transport protocol which builds a virtual connection between the sender and the receiver. The internet also uses other protocols built on top of the TCP/IP protocol, such as SMTP (Simple Mail Transfer Protocol) for electronic mail, HTTP (Hypertext Transfer Protocol) for transferring web pages and DNS (Domain Name Service) for name and address queries on the network.

In the telephone network, some standards for representing data and services have been built on top of the basic network, such as voice call and data call (in the ISDN or GSM network). In the GSM Short Message network, information is sent as separate 160-character short messages by using the SMS standard. The X.25 network is an old networking technology and complex to attach to a modern network. X.25 is a primitive packet network, where the packet layer is used to share resources between several logically continuous telephone-network-like virtual connections.

Delivering information across these different networks is hard because the networks operate in different ways and the information has to be converted into a form (standard) that is suitable for the communications devices on the target network.

Networks can be interconnected with a gateway that converts information into the format required by another network. Automatic conversion works only with similar networks and sen/ices.

Because connecting different networks is hard to do, the access to the services of e.g. a GSM network is closed except to some few non-customised services targeted at large user groups, which someone sees as financially profitable to build by using expensive traditional methods.

The applicant has constructed a solution for delivering and converting information between different networks in a flexible way, which is presented in PCT/FI00/01036 of the applicant. More in detail, PCT/FI00/01036 presents a system for managing an information delivery system that has a large group of information producers and users, like on the internet.

This solution of the applicant describes an information delivery system which is connected to one or more communications networks. It comprises an information delivery server, which has information receiving modules for receiving query messages from one or several networks and for converting that information to a suitable format for an information processing unit. The information processing unit processes the queries according to their content, fetches the information requested, processes the information and builds replies to the queries. Information sending modules send the replies to one or more networks and convert them to a format suitable for the receiver. The system also includes a user interface, which allows the creating and maintaining of services on the information delivery server from one or more terminals connected to the information delivery system and a service product to be used in the system as well as the use thereof.

The information processing unit processes the queries according to their content, and fetches the information requested from one or more networks or databases connected to the server.

The operation of this service product can be described as a binary program module which is stored on the server or on the network. The operation program of the service can be presented as a list of selected operations (in some database) or in text form. For service providers, it can be presented in a form, where they can add command parameters. For service users it is presented in a ready-to-use form.

The queries are processed with a program, which has been created as a command list in the server, as a list of simple operations. The program is stored into a database on the server or at another location on a connected network.

The service description is stored in a database and its operation program is presented and processed by the system. The service can be modified and/or created for a private and/or public and/or restricted user group by using parameters, which are typed into input fields in the service program. The operation of the service can also be described by a binary program module, which is transferred to the information delivery server. The service can also be described by a program stored elsewhere on the network.

Such an information delivery service, which is created on the service program, can consist of fetching information from the internet, e.g. fetching of a home page or a news page, or fetching information using some other internet protocol. A service can also fetch information from a database, which is on the server or on a network.

The server has a number or an address on the network through which requests can be sent to it when a user wishes to use the services. Different networks have different ways of finding the information delivery server's address, name or identity and for sending a request. The request can be sent from e.g. the GSM network as an SMS message, from an iMode device, from a computer connected to the internet using a www page, of through e-mail.

The configuring services on the information delivery server can be open to all users. In addition, the solution offers a simple way to create services, e.g. with a programming list interface as described.

The object of this invention is to further develop the methods for information delivery in form of services in such an information delivery system.

SUMMARY OF THE INVENTION

In the method of the invention for delivering information to one or more user terminals in one or more communication networks, query messages are received from said user terminals. The received messages are converted to a suitable form for further processing in accordance with their content. The information requested in them is fetched, processed and replies to them are constructed. The replies are sent to the user terminals when they have been converted to a form suitable for the network of the user terminals. The method is characterized in that the fetched information data is processed into a suitable delivery format for the user terminal that receives the replies.

In this invention, information that is sent between different networks, images, sound and other media is converted to suit the terminal device, just like text data is processed according to PCT/FI00/01036.

Criteria for a suitable format are such a format that a user terminal can support with respect to the total size of the collected result, the lay-out for the terminal display and/or the sound. The invention also provides a solution, by means of which the delivery format is constructed by means of a format template, with which the delivery can e.g. be made as nice or as functional as possible.

Typical formats for sound on the internet are those having high fidelity, stereo sound chanels and no practical time limits for the length of a song. On mobile devices, typically all what is available is a short sequence of beeping sounds, to be used as a ringing tone or message reception tone.

In the invention, the fetched information might comprise a sound file. Possible transformations applied to the sound might of the above reasons consist of adjusting the volume or taking only a part of. the fetched sound. It might be suitable to run it through fast fourier transformation and/or taking only the loudest note. The sound is converted into a format that can be sent to e.g. a mobile device, as e. g. a ring tone, a new message tone, a pager tone, or a sound message.

A ring tone message typically consists of some general information followed by a list of notes and note lengths and repetition information, according to which the device will play a series of beeps when the ring tone is activated.

An internet sound file typically consists of digital samples of the audio information, compressed with some algorithm. The sound file can be uncompressed and then the audio signal samples used for processing of the sound.

An operation provided for sound processing can e.g. be in the form: "Get from internet, sound file, address". This command would be for fetching a sound file from the internet. "Select, sound from second-to second" could be a command for selection of only a part of the sound file for later processing. Commands like " Adjust, sound volume / pitch / transpose sound / filter sound frequencies" operate on the sound data, allowing you to process it into a form which will work well when converted to the simple mobile device format. "Convert, high-fidelity sound to a list of strongest frequencies and times" could be a command for allowing the user to take a sound file, run it through the Fast Fourier Transformation (FFT) algorithm to get, as a result, a list of sound frequencies and times for each "note" in the input sound file. The FFT algorithm, applied to short parts of the sound data at a time, will give out the frequency distribution of the sound data, allowing the system to pick out the strongest frequency at different times in the sound.

"Send note list to terminal device" could be a command for converting the note list to a format that is understood by the user's terminal device, and sending it as a special message, if necessary, to the user's device for use.

The above operations can be combined to simple convenience commands for the users, e.g. fetch a sound file, process it with default values and send it as a ring tone to the terminal device.

The fetched information might also comprise an image. Before constructing the reply it is usually proper to make some transformations to said image, if the user terminal is not a PC since images fetched from internet are usually designed for PC:s. Images on the internet, that have been designed to be diplayed on a large color PC display, can e.g. have the characteristics of 1024 x 768 pixels and 2 ^Λ16 colors . Many other terminal devices have much smaller capabilities to display images. For example current mobile phones can display minuscule black-and-white images, e.g. with the characteristics of 72 x 14 pixels, and in black and white only. The image might in the invention be converted into a graphic that can be displayed by a mobile device. Thus, said transformations might consist of e. g. scaling, cropping and/or adjusting pixel values in the image.

For the time being, mobile phone images can only be of a few types, one of which is the operator logo, which is displayed on the screen, when the phone is not in active use, or a caller group logo, which is displayed when someone in that group is calling. In the invention converting of the graphic can consist of changes in e. g. the operator logo or a graphic message.

Same kind of operations can be used for image data as was described above for sound files. Examples of commands are "Crop (select a part of the image)", "Adjust brightness/contrast/color balance", "Convert to fewer colors with threshold/ dithering "/", send as a operator group logo", etc.

If the fetched information comprises a text file, the letters in the fetched text can e.g. be changed to better fit in the user terminal. If the maximum size of the reply to be sent is limited, some part of the result can be removed. Compression for source and result data that can be used to tailor the result according to the storage, transmission and display space available on the user terminal. The compression is made e. g. by shortening of sentences or by choosing a suitable format for an item of data. Several compression methods can be combined and alternative results be achived and the operation results can be ranked in importance, so that the best alternative is then chosen depending on the user terminal.

Compared to the previous invention of the applicant presented in PCT/FIOO/01036, which worked particularly well for fetching information in text form, the system is now expanded with special solutions for fetching, processing of and choosing other types of media, such as images, sound files etc. A goal is to add a possibility to construct services in a delivery server between different networks, which services fetch, configure etc, media data, that then can be sent in a suitable form to the user terminal.

The invention provides media-related command operations in the context of an open and flexible information processing gateway, allows building of services, which in a customized way process also non-text media data and convert it to a format the user terminal device can use. In the following, the invention will be described by means of some embodiment examples, as implemented in a system of figures 1 - 2. The intention is not to restrict the invention in any way, as the presentation is for illustrative purposes only.

FIGURES

Figure 1 is a general architecture view of an information delivery system, wherein this invention can be used.

Figure 2 shows the general format of a command list that can be used in the invention.

Figures 3 - 5 are embodiment examples of the invention for command lists wherein the fetched information is transformed into a format suitable for the user terminal.

DETAILED DESCRIPTION

An example of an information delivery system earlier developed by the applicant is presented in figure 1. The system has information delivery connections 1 , through which the system receives 1 requests from the networks N1 , N2, N3 and sends 6 replies to those.

Information receiving modules A1 , A2, A3 receive 1 information, requests and replies from a certain network N2, N2, N3 and convert the information data to a uniform internal format of the system, so that the later modules in the system would not need to know about different properties of different networks.

An information routing module B (not always necessary) receives the requests coming to the system and directs 3 them according to the data in the request to a suitable processing module.

The information processing modules C process data, fetch data from different networks, modify the format of the data and form replies to the questions. The data sending control module E receives 4 the replies created by the system and sends 5 them to a suitable sending module of the network. Also the information processing module can convert the information data approximately to a form needed by the network. The sending module can then make a more technical conversion on a lower level.

The information sending modules F1 , F2, F3 send 6 data, requests and replies to a given network by converting them to a suitable form for the network in question. In some of the networks, the receiving and sending modules can be in one single module.

The delivery server can work in one centralised server or these functions can be spread among several servers.

The service program is such that by feeding given parameters to it, a list of commands are achieved, which are performed in order to carry out the function of the service.

The principle of such a command list is presented in figure 2. Each element in the command list consists of the command, specifications and parameters as well as of additional information for the command in question. These are presented for the user in form of clear selection menus, so that the user would not need to remember the names of the commands or any special way of presentation of the commands. Each command is a simple individual function, easy to understand.

In the third parameter part of all commands, the results of other command lines, as well as the words and data in the request, can be used in a flexible way, for example the words used in the request for fetching data from a www-address can be used as words for the www-service.

The command list can be stored in a data base for example in a form according to figure 2. The command list is presented in the data base of the delivery server in form of simple lines, which are processed by the user interface and the performance module uses these commands in its performance.

The performing module performs the stored instructions in the delivery server and thus performs the function of the service in practise.

When the routing module of the system has drawn the conclusion that the request should be sent to some certain performance module or processing module, the request is routed and, depending on which service it is question about, the performing module downloads the command list of the service from a data base or some other storage form and performs the functions in them in accordance with the instructions in the command lines.

In this way, the execution module can perform the function of the masscustomised service.

Command list operations like the above will allow the users to creatively build services which process multimedia data and convert it into a format suitable for mobile terminals.

The command list can be built by any user to define the working of a information conversion service and operates in accordance with the description of PCT/FIOO/01036.

In this invention desired information in a query message from a user terminal is fetched and processed to different delivery formats for user terminals for constructing of the reply to the query.

If the data that fetched from a network contains an image, sound or other media (i.e. other than text-style data), then media-specific operations can be applied on the data fetched. These operations can be available as figure 2 like additional commands in the service scripting system. For example, if a command in the command list is "Scale image", then the service module executing the service script can save the image data into an image file, execute an external program that will scale the image data, and then read the image data back for further use in the service script.

Figures 3 is an embodiment example of the invention wherein the fetched information is an image, which is transformed into a format suitable for a mobile device.

It is assumed that the user wants to have a personalized operator logo image on his/her cellular phone. The user first locates an image he likes on the internet, and using the service of the invention the images are fetched, with command 1. of figure 3, i.e. Get from internet, image file, http://example.com/images/(argument 1 ) jpg. The command first states the network from which the information is to be fetched, which in this case is the internet. Thereafter the type of file is specified, which is an image file in command 1. of figure 3. The image is then fetched by means of the internet address, wherein the desired image is.

After the image is fetched, transformations are applied to the image. Scaling, cropping and adjusting pixel values is performed to convert it into a graphic that can be displayed by a mobile device, in this case an operator logo.

It is resized to the small size required by a mobile device by using an algorithm striving to provide a good quality small picture. Command 2. adjusts the contrast of the image with 10%. In command 2, the type of processing is first specified, which in this case is adjusting of the image. The kind of adjusting is specified next, i.e. change of contrast, and thereafter how much the contrast is to be changed (here 10%).

Several adjusting commands can be performed one after another. The image is adjusted in commands 2 - 5 in figure 3. The adjusting in command 3 consists of filtering of the image through a gaussian blur filter, with which the colors of the image are adjusted with 5.5 pixels radius. Gaussian blur is an example of a well known standard algorithm for image manipulation. Commands 4 -5 adjusts the size of the image, i.e. the width to 72 pixels in command 4. and the height to 14 pixels in command 5.

In command 6., the image is then sent to the mobile device in a special "operator logo" (or other special) service message created by the operator in question, so that the phone will save the logo to be displayed on the screen of the phone.

If command 6. failed, a message is sent to the user (command 7.), wherein the user is informed that, the image could not be fetched or converted or sent, whatever was the reason.

For sound data, a possible use on a mobile device is a ring tone. A service to provide a set of ring tones based on music sound files could comprise of operations such as those presented in figure 4.

In figure 4 it is assumed that the user sends the request "senticename songname" to a service built from the script below to fetch a sound file. Transformations are then applied to the sound.

Command 1. in figure 4 will fetch the music file located at http://www.example.com/getmusic?name=songname (after having first specified the network from which the information shall be fetched and the type of file.

The volume is then adjusted and only a part is taken of it. The command 2 operation will choose only the first 15 seconds of the sound file (after having first specified that it is question about a sound operation). Command 3 will slightly lower the volume of the sound file, i.e. with 5%.

Only the loudest note of the sound fetched can be taken to convert the sound into a format that can be sent to a mobile device as e.g. a ring tone, a new message tone, a pager tone, or a sound message. The command 4 operation runs the sound through fast fourier transformation. This operation will run the sound file, a small piece at a time, through the FFT algorithm to learn the strongest frequency at any given time. Similar frequencies next to each other will be joined to a longer note. The result will be a text representation of the strongest note in the music file, e.g. C#3 D1 E1 C#8 C.

The reply is then sent to the user (command 5) as e.g. a ring tone. This will load, from the users preferences, information about the users mobile device, convert the note list to a ring tone special for that device type, and then send the ring tone message to the device. The user will then receive the special media message and choose to use it on his/her mobile device.

If the sending of the ring tone failed (e.g. there was no music or the device does not support sound), then a descriptive error message is sent to the user (command 6), wherein it is explained that the sound could not be converted.

The commands can also be performed as a set of operations that further operate on the result of the last operation. These can as above be used to convert the data into a more suitable format for display or later use. If the previous result was an image, the image can be cropped, scaled and changed. If the previous result was a sound, different alternatives are adjusting of the volume, taking a part of it, running it through Fast Fourier Transformation (FFT), or taking only the loudest note. If the service for example fetches information, and the result of the fetch is presented with small letters, it can be amended to capitals. The next command could be to remove a perl of the text from the fetched result. Also a looping operation can be used, that collects the result of the previous operation until end criteria is satisfied and which then repeats the operations starting from a specified operation.

In one such embodiment, the command line script stores the result of each command line operation for later use. These results can then be filled in a display format template, constructed in forward. The template is filled with information from selected lines of the command script. This allows the service creator to select pieces of data and place them in a template for nice display on more capable terminal devices. For example, a command line script could extract pieces of information from a web page by using the normal find, select, etc. operations available in the command line script system. Then the service creator could define a template, into which selected results from the command lines will be placed, each (result N) being replaced with the result of operation N when the template is applied, e.g.

The link to item (result 10) is: <A HREF="(result 2)">(result 5)</A> And the short reply is (result 8). This service was <A HREF="/service/name.html">name</A>.

When the template is constructed, the items are placed into it, thereby creating a fully filled-in document, which can then be sent to the mobile device or other terminal, providing a better user interface than just plain text.

Figure 5 illustrates the using of such a template. The intention in figure 5 is to fetch certain information from a web page, as appears from command line 1 in part A. Reference A refers to the command list part. Reference B refers to the results of each command. The result of command 1 is the web page fetched, i.e. result 1 in part B. The next command strives to find the news from the web page fetched, which results in result 2 of part B, the tilte of the news. The task of the third command is to select 10 lines of said news, e.g.the 10 first lines, whereafter result 3 of part B is the selected 10 lines. The task of command 4 is to fetch an image from a certain internet address. This command 4 results in result 4 of part B, which is a large image. The task of command 5 is to scale the width of the image to 100 pixels to get result 5 of part B as a narrow image. A further command, i.e. command 6 further scales the image height to 20 pixels to get a small image as result 6 of part B. The use of the template is performed with command 7, whcih as apeears is constructed in HTML. The template can be constructed as e.g. in figure 5 reference C, which defines the template. When this template is used, the result is that the results of command line 3 and command line 6 are combined in a way defined in the template with respect to line changes, >BR> etc. (P) means paragraph change and the template example of figure 5 is constructed so that the result of command line 6 is written first and then the result of command line 3 on the next line. The next paragraph is a permanent text appearing in each result.

References E and D are intended to show more in detail how the template C is filled. Reference E shows what command 7 does and D shows the final content. First, the result of command line 3 and the result of command line 6 are placed as is shown in reference E. D shows the final appearance of the result shown for the user.

In some embodiments of the invention, compression is used to convert the delivery information in a form suitable for a mobile device or other terminal.

Compression of source and result data can e.g. be used to tailor the result according to the storage, transmission and display space available on a mobile device. This allows the content or service creator to choose how the data is compressed if it does not fit in the device.

Embodiments using automatic adjustment of the result size is very useful when the service generates results and when it does not know how much information the terminal device can accept. The sen ice can generate a general result message with mark-up that allows the message to be shortened when sending, if necessary.

One possible way for information compression are compressing the content by prioritizing some parts of the content in front of other parts.

Content compression for information to be delivered to the user can be performed by putting a part of the information into brackets. If there is not enough space, then the content marked with the brackets is removed one element at a time, until the reply size is small enough.

Examples of compression implementations are described in the following: If the resulting message is too long, parts marked with [ ] are removed. For example if the message is "hello [world]" and there is less than 11 characters space to display it, only "hello" is displayed.

A compression can also be used in a recursive way. For example the message "[The] price [of the book is [going to be]] $120" will be rendered as whole, or as "The price of the book is $120" or as "price $120".

Gradual compressions are made so that the compression results can be ranked after importance, so that the most important data will be kept as long as possible. Data to be displayed in the compression process and less important data will be removed before important data. For example:

Hello [3: Nice] [2: World]

can be compressed, in ascending order of compression to:

Hello Nice World Hello World

Hello

so that the exact behaviour of the result compression can be controlled by the service developer.

Also selection between similar choices can be encoded. For example [100 Marks|100mk|100J would give the result "100 Marks, "100mk" or "100" depending on how much space is available.

One or more of the compression methods above can also be combined.

Some parts of the content can be prioritized in front of other parts by priotizing by means of numbers. The removal of different parts of the information content can be prioritized, so that a marked piece of the content will be removed first (e.g. the one with the smallest priority number) before more important data (e.g. one with a higher priority number).

Parts of the content can also be prioritized in front of other parts by choosing between different representations of the content, out of which the longest is selected that can fit within the message.

The following text is an example of content compression by choosing between different ways of presentation. If a part of the information is put into brackets in forward, the system can automatically choose the right way of presentation according to the user terminal to which the reply is sent without the need of thinking of different terminal device limitations each time.

"[2:The price of] oil [Wednesday, 20 December|Dec 20]

[1 :at the Western Oil Market was] USD 13.42 [per barrel]".

According to the space available (which is defined according to the user terminal to which the reply is sent) in the reply, the elements within the brackets would be removed starting with the lowest-numbered element, the full reply, if enough space is available, being:

"The price of oil Wednesday, 20 December at the Western Oil Market was USD 13.42 per barrel"

If there is less space, the compression commands will first remove information in [ ]s without any priority number, i.e. [per barrel] so that the reply would be

"The price of oil Wednesday, 20 December at the Western Oil Market was USD 13.42" If there is still not enough space, the shorter form of different representations is selected, i.e. selecting "Dec 20" instead of "Wednesday, December 20", the reply now being

"The price of oil 20 Dec at the Western Oil Market was USD 13.42"

Next, if the message is still too long, the prioritized parts are removed in order, first starting with the element with priority 1 , i.e. removing [1 :at the Western Oil Market was], whereby the reply would be

"The price of oil 20 Dec USD 13.42"

and finally removing the element with priority 2, i.e. removing [2:The price of], whereby the shortest possible reply would be

"oil 20 Dec USD 13.42".

In this way, the service can generate a single reply in a standard format, which will work for any terminal device as the information delivery system can adjust the message in a service-specified way to fit the terminal device in use.

After that the message is short enough, all the remaining compression mark-up characters are removed without altering the content itself, leaving only the final content. When calculating the length, the compression markers ([ ] etc) are not counted in the content length.

The removing of the part of the content is done by a simple string modification algorithm, that looks for " [ " characters, the optional number or the character "|" after that. If the algorithm finds some of these characters, then the text after that character is not copied (or only one of the choices is copied) until a " ] " character is reached. This algorithm is called repeatedly which performs the deletions or choices in accordance with priority until the message is short enough. In a further embodiment of the invention, when the method of the invention is used to send information to a terminal device with limited capability for a reply message, the user can request "more" of the last reply with a "more" command.

This works in the way, that the system generates a longer reply than that can fit in the terminal device. From this longer reply, initially only the beginning part, as much as can fit the terminal device, is sent to the terminal device. The rest is stored in a user-specific or service-specific "more storage" in a database. When the user sends the "more" command, more data from the "more storage", and sent to the user in one more or several more steps. In this way, the user can use the replies in the longer form. If some reply is cut short because of terminal device limitation, the user can then request more data with one or more "more" commands.

Thus, the reply can be sent to the user terminal in several parts as needed.

Claims

1. Method of delivering information to one or more user terminals in one or more communication networks, in which method query messages are received from said user terminals, the received messages are converted to a suitable form for further processing, the messages are processed in accordance with their content, the information requested in them is fetched, the information data is processed and replies to them are constructed, the replies are sent to the user terminals when they have been converted to a form suitable for the network of the user terminals, characterised in that the fetched information data is processed into a suitable delivery format for the user terminal that receives the reply.

2. Method of claim ^ ch aracte ri sed in that the fetched information is converted into a more suitable display format for delivery to the user terminal.

3. Method of claim 1 or 2, characterised in that the information fetched by means of each command in the list are stored for later use.

4. Method of claim 3, ch ara cte ri sed in that stored results from each command in the list are filled in a display format template, which is then sent to the user terminal.

5. Method of claim 1 or 2, characterised in that the criteria for a suitable format are such a format that the user terminal can support with respect to the total size of the collected result, the lay-out for the terminal display and/or the sound.

6. Method of claim 5, ch a ra ct e r i s e d in that the size of the reply is automatically adjusted in accordance with the user terminal.

7. Method of any of claims 1 - 3, c h a r a c t e r i s e d in that the fetched information comprises an image.

8. Method of claim 7, characterised in that transformations are applied to said image before constructing the reply.

9. Method of claim 8, characterised in that said transformations consist of scaling, cropping and/or adjusting pixel values in the image.

10. Method of any of claims 7 - 9, c h a ra ct e r i s e d in that the image is converted into a graphic that can be displayed by a mobile device.

11. Method of claim 10, characterised in that the converting of the graphic consists of making changes in an operator logo or a graphic message.

12. Method of any of claims 1 - 3, c h a r a c t e r i s e d in that the fetched information comprises a sound file.

13. Method of claim 12, characterised in that transformations are applied to the sound.

14. Method of claim 13, characterised in that the transformations consist of adjusting the volume, taking only a part of the fetched sound, running it through fast fourier transformation and/or taking only the loudest note.

15. Method of any of claims 12 - 14, ch a ra cte ri se d in that the sound is converted into a format that can be sent to a mobile device, as e. g. a ring tone, a new message tone, a pager tone, or a sound message.

16. Method of any of claims 1 - 3, c h a r a c t e r i s e d in that the fetched information comprises a text file.

17. Method of any of claims 1 -3, characterised by compression for source and result data that can be used to tailor the result according to the storage, transmission and display space available on the user terminal.

18. Method of claim 17, characterised in that the compression is performed by shortening of sentences in the fetched information or by choosing a suitable format for an item of data.

19. Method of claim 17, characterised in that compression of the information content is performed by prioritizing some parts of the content in front of others.

20. Method of claim 17, characterised in that compression of the content is performed in a recursive way.

21. Method of claim 17, characterised in that compression of the content is performed by selection between similar choises.

22. Method of claim 17, characterised in that compression of the content is performed by selection between different representations of the content.

23. Method of claim 17characterisedin that the gradual compressions are made to rank compression results in accordance with importance.

24. Method of any of claims 17 -26, characterised by combining one or more compression methods.

25. Method of any of claims 1 -3, characterised in that the reply can be sent to the user terminal in several parts. AMENDED CLAIMS

[received by the International Bureau on 26 April 2002 (26.04.02); original claim 1 amended; remaining claims unchanged (1 page)]

1. Method of delivering information to one or more user terminals in one or more communication networks, in which method query messages are received from said user terminals, the received messages are converted to a suitable form for further processing, the messages are processed in accordance with their content, the information requested in them is fetched, the information data is processed and replies to them are constructed, the replies are sent to the user terminals when they have been converted to a form suitable for the network of the user terminals, characterised in that, the fetched information data is processed by means of a service program, the service program being processed by the user interface so that by feeding given parameters to the service program a list of commands is achieved and these commands being built in the program by any user for processing desired type of multimedia data and convert it into a suitable delivery format for the user terminal that receives the reply.

2. Method of claim ^ c h a racter i sed in that the fetched information is converted into a more suitable display format for delivery to the user terminal.

3. Method of claim 1 or 2, characterised in that the information fetched by means of each command in the list are stored for later use.

4. Method of claim 3, c h a ra c te r i s e d in that stored results from each command in the list are filled in a display format template, which is then sent to the user terminal.

5. Method of claim 1 or 2, characterised in that the criteria for a suitable format are such a format that the user terminal can support with respect to the total size of the collected result, the lay-out for the terminal display and/or the sound.