DE29816131U1 - Data transfer system and end device - Google Patents

Description

TERMEER STEINMEISTER & PARTNER GbR

PATENT ATTORNEYS-EUROPEAN PATENT ATTORNEYS

Dr. Nicolaus ter Meer, Dipl.-Chem. Peter Urner, Dipl.-Phys. Gebhard Merkle, Dipl.-Ing. (FH) Mauerkircherstrasse 45 D-81679 MUNICH Helmut Steinmeister, Dipl.-Ing. Manfred Wiebusch

Artur-Ladebeck-Strasse 51 D-33617 BI ELEFELD

Case: 12212 EN

Ur/Wa/lö

NOKIA MOBILE PHONES Ltd.

Nokia House

Keilalahdentie

FIN-02150 ESPOO

FINLAND

Data transfer system and terminal device

Priority: Finland 9 Sept. 1997 U970394

Data transfer system and terminal device

The invention discussed here relates to the information transfer system that can be implemented using the formatting languages at the respective application level used, whereby, for example, by using different formatting languages when creating pages, it is possible to transmit a low transmission capacity to a separate data transmission system. In addition, the invention also relates to terminal devices, in particular mobile radio devices.

Electronic data transmission is a growing field. Ever since data was transmitted in electronic form, the same problem has been faced: how to minimize the size of the electronic document. The typical document, which contains text in various formats, images and diagrams, is a huge size when represented as a digital bitmap. A widely used solution to solve this problem was SGML (Structured Generic Markup Language) - a formatting language. It defines the electronic data transmission in a specific framework structure.

The HTML (Hypertext Markup Language) formatting language is by far the most well-known language that adopts the SGML standard due to the great popularity of WWW (World Wide Web) pages. However, there are countless other formatting languages around the world that are based on the SGML standard, such as the SPDL (Standard Page Description Language) language developed for various printers and the SMDL (Standard Music Description Language) language, which is suitable for multimedia applications and supports music and text. The great popularity of WWW pages created using the HTML formatting language is due to their good presentation and user-friendliness. The development of the WWW as a whole is controlled and monitored by the World Wide Web Consortium (W3C).

The HTML formatting language is the document type definition (DTD), which is actually a subset of the SGML formatting language. Like any document type definition, it defines the beginning and end characters of a document using individual data elements, as well as the range in which each data element can appear in sequence. HTML was created in particular to attach hypertext links to documents and to link them to different documents. The HTML standard has become

has also rapidly developed into a data storage and communication standard, especially for large organizations such as companies and municipal and state administrative bodies.

The HTML formatting language was designed in connection with the use of end devices with relatively large data transmission capacities. In the future, HTML language extensions will mainly support larger data capacities than before, even with the aim of transmitting moving video images. This would enable, among other things, worldwide video conferences via the Internet.

The advantage of the HTML language lies in its clear format description (the HTML code can be read and written using a conventional text editor) and its versatility. It is partly because of these factors that it is not particularly effective from the point of view of code optimization. Each document requires a lot of control and control characters, and the pure information portion of the total text length is particularly low, especially in short documents. This is a disadvantage, especially for devices with low transmission capacity, but also particularly in systems in which the system constraints set a certain upper limit for the document size.

Data transmission systems with low transmission capacity are still in use in wireless communication. When using data services, e.g. when browsing the WWW pages of the Internet network, wirelessly e.g. with the computer, the data adapter and the GSM (Global System for Mobile communication) mobile phone, the GSM system has a 9600 bps data transfer channel available. This is quite sufficient if the size of the documents and data to be sent is not particularly large. For the transfer of large pages, e.g. those created in HTML formatting language, it would be a great advantage if it were possible to make the transfer of such pages more effective.

Regardless of the amount of information to be transmitted, the 9600 bps data channel provided by the GSM system is occupied for the entire duration of the data connection. This data channel uses the same service channel that is usually used for telephone traffic. In this sense, the use of the data channel prevents both the establishment of telephone calls and the reception of calls. This is an undesirable situation, especially when the amount of information to be transmitted is particularly small. To solve this problem,

To solve this problem, short message services have been developed, by means of which small information packets can be sent over separate signaling channels. An example of such a service is the SMS (Short Message Service) service of the GSM system, which offers its users the possibility of sending and receiving short messages. The length of SMS messages has been set at an upper limit of 160 characters in the GSM specification. In practice, this prevents the replacement of documents generated using HTML formatting language by SMS short message communication, because the size of documents, especially short ones generated in HTML language, exceeds the mentioned maximum limit of 160 characters.

An SMS extension is planned for the GSM standard that will remove the upper limit of 160 characters. In this case, messages that are longer than 160 characters will be distributed over several separate SMS messages, which will be combined into one message in the receiving device. A possible SMS extension will facilitate data traffic, but will not solve the basic problem that the data transfer capacity in SMS communication is particularly low, for example if you consider the benefits of the services offered by the increasingly popular WWW sites.

There is a great need to make the transfer of documents created in different formatting languages more effective through low-speed data transfer connections, such as at the level of wireless mobile radio systems.

An application-specific terminal and system with compression capabilities has now been developed that can reduce the difficulties described above. This enables, for example, some documents written in SGML formatting language to be efficiently transmitted in data transfer systems with low transmission capacity, especially in systems where a certain, predefined low upper limit has been set for the size of the document to be transferred. Compression is particularly suitable for pagers and mobile radio devices. By using this new development, it is possible to transform pages from the Internet so that they are available in wireless terminals, for example in short message form, even when the normal operating channel of the mobile radio device is busy. The use of this invention is also possible in other applications that use the SGML protocol, even in terminals where high transfer speeds are achieved.

This saves transmission time and costs, especially for large documents. The invention is also suitable for transmitting pages written in different formatting languages between two mobile devices, such as in mobile communications. 5

In the invention, in connection with the formatting language, the start and end characters (control characters, tag) made up of several symbols and used to distinguish the individual information parts of the document are replaced by short identifiers. This is conveniently done via the service provider's server. A table designed in this way, for which the term grammar is used below, is transmitted to the receiving terminal using, for example, the SMS short message. If the required grammar is too large, it is also possible to transmit it via the usual data channel instead of the SiVIS short messages. The grammar is stored both in the service provider's server and in the receiving terminal. If both the sending and the receiving terminal use the same grammar, the web page corresponding to the original can be reconstructed by the receiving terminal using short identifiers. This means that when the same web page is used again, it is sufficient to transmit the information typical for the service that changes between times of use. The invention enables, for example, the presentation of the weather service page, which remains externally constant, with a very small amount of information. Only essential information, such as the temperature, the wind strength and direction, is transmitted, and the website layout is generated with the help of the receiving terminal using the grammar. In addition, the invention can also be used for frequently repeated essential information, such as by compressing the above-mentioned wind direction in such a way that "south wind" is replaced by the character "e" during the transmission time, and on the other hand this is unpacked to "south wind" with the help of the grammar in the receiving terminal, etc.

The invention also enables the presentation of entire sentences and structures of the page layouts by replacing the series of symbols used by short identifiers, as will become apparent from the detailed description of the invention.

Later, in connection with detailed explanations of the invention, the HTMesL (Hyper Text Messaging Language) formatting language based on the HTML formatting language and compressed according to the invention is used.

When transmitting the web page created in HTML language, e.g. within the Internet, an HTTP (HyperText Transfer Protocol) protocol is used for data transfer. For transferring the information contained in the web page in a form compressed according to the invention in short message mode, e.g. from the server to a mobile device or between two mobile devices, the HTTP protocol is not optimal. Therefore, in connection with the invention, the HTTP protocol is replaced by a new protocol, which is referred to below as HTMesTP (HyperText Messaging Transfer Protocol). In connection with the information to be transmitted in the HTMesTP protocol, additional information is added which defines, among other things, the grammar according to which the message was compressed and the type of the message in question. On the basis of this additional information, the receiving terminal is able to process the message it has received correctly, i.e. it can recognize, for example, whether it is a grammar message for updating the grammar or a message within the scope of a service offer. The type of message can also be a combination of the message types mentioned above, a so-called composite message.

What is characteristic of the invention is what is stated in the characterising part of the protection claims and 2.

In the following, the invention is explained in more detail with reference to the accompanying drawings:

Figure 1 Representation of the data transfer system relating to the invention and terminals used therein,

Figure 2 Representation of the different parts of the URL (Uniform Resource Locator) address used on the Internet,

Figure 3 Representation of a web page created with an HTML formatting language,
35

Figure 4 Representation of the transmission of messages between the terminal, the server and the Internet server in the data transfer system according to the invention in the form of a data flow plan,

Figure 5 Representation of the structure of the message according to which the messages compressed according to the invention are sent

Figure 6 Representation of data transmission according to the invention 5

Figure 1 shows the data transmission system, which includes the GSM system, the server and various terminal devices. The core of the GSM system is formed by the mobile telephone exchanges 100 and 101, which in this system are special SMS-GMSC (Short Message Service - Gateway Mobile Switching Centre) centres suitable for the transmission of SMS short messages. They transmit the calls received from other mobile telephone exchanges or fixed telephone networks 110, or the message data that use the data channels offered by the GSM system, via the subordinate base station controllers (BSC, Base Station Controller, references 102, 103) and base transceiver stations (BTS, references 104, 105, 106 and 107) to the connected terminal devices (MS, Mobile Station, references 10, 11 and 12). Accordingly, the mobile telephone exchanges 100 and 101 collect the calls or data messages arriving from the terminals 10, 11, 12 and transmit them to other mobile telephone exchanges or fixed telephone networks 110 based on the number dialed by the subscriber.

Parallel to the GSM system, which transmits calls and data, there is the autonomous short message service, SMS (Short Message Services).

In the following, the abbreviations SMS service and SMS message are also used for this service and the short messages transmitted through it. SMS messages are transmitted as standard between two mobile terminals 10, 11, 12 or between a stationary and a mobile terminal 10, 11, 12. The SMS messages are transmitted in a concentrated manner by the short message service center 20 (SM-SC). The short message service center 20 is also referred to as SMS message center 20 in the following. The SMS message center 20 is connected to the GSM system via the mobile telephone centers 100, 101. The SMS message contains, among other things, the recipient's ID, on the basis of which the SMS message center 20 is able to transmit the SMS message to the correct recipient. The following section describes the transmission of the SMS message from the terminal 11 to the terminal 12 as an example.

When starting the process of sending the SMS message, the terminal device 11 transmits the SMS message through the signaling channel of the GSM system via the base station 105 and the base station controller 102 to the mobile telephone center 100. The mobile telephone center 100 forwards the SMS message to the SMS message center 20, where it is temporarily stored. Receiving the SMS message, the SMS message center 20 attempts to locate the recipient (in this example, terminal device 12) based on the address information contained in the SMS message. If the recipient is found, i.e. identified as a GSM network subscriber, the SMS message center 20 transmits the SMS message via the mobile telephone center 101, the base station controller 103 and the base station 107 to the terminal 12. If the SMS message has been transmitted successfully, the SMS message center 20 deletes the SMS message from its memory. If the terminal 12 cannot be reached, the SMS message center 20 attempts to transmit the SMS message again later. If the SMS message cannot be transmitted within a certain predetermined time, the SMS message center 20 sends the response, also as an SMS message, to the terminal 11, which is informed that the transmission of the SMS message was unsuccessful. The transmission of SMS messages in connection with the GSM system, which is well known to experts in this sector, is described in more detail in the book by Michael Mouly and Marie-Bernadette Pautet "The GSM System for Mobile Communications" from 1992 (ISBN 2-9507190-0-7).

The SMS message center 20 also has a teleconnection to the fixed telephone networks 110, via which, e.g. with the help of a modem, SMS messages can be transmitted to the server 35 offering SMS services. The SMS message center 20 can also be connected to the Internet network 50, e.g. via the server 30. This server 30, which is essential for the operation of the invention, is referred to below as the SMS TCP/IP server 30. This server differs significantly from the other servers of the Internet network 50, e.g. from the server 70 offering Internet services. The SMS TCP/IP server 30 forms a gateway between the SMS message center 20 and the Internet network 50. It is therefore possible to transmit SMS messages between the terminals 10, 11, 12 and the Internet server 70 in order to use the services offered by the Internet network 50.

The data messages on the Internet, such as SMS messages, are transmitted between different servers 30, 70, using the

The TCP/IP (Transmission Control Protocol/Internet Protocol) protocol known to industry experts and the Internet address (URL, Uniform Resource Locator) specific to both servers. Figure 2, for example, shows an Internet address and its various parts. The address thus includes the protocol P1, the designation P2 for the Internet server, the number P3 for the TCP/IP port and the resource name P4. The TCP/IP port number ":80" shown in Figure 2 is optional and does not need to be used.

Usually, the service is requested by asking for a specific SMS message to be forwarded to a provider's service number. From there, the SMS message is directed to the service provider via the SMS message center 20, e.g. via the telecommunications network 110 to the server 35. Since the maximum length of the SMS message is limited to 160 ASCII characters, it is understood that services implemented in this way are forced to reduce the information offered to the bare essentials. For certain service purposes, this may be completely sufficient, e.g. exchange rates and bank account balances can now be queried using the traditional SMS message via mobile phone. In response to the requested service, the server 35 forwards an SMS message consisting of the desired ASCII text to the mobile phone, which the user can read on the display of his mobile phone.

If the services offered by the network are provided using a website formatting language, it is almost impossible to use the services as such using SMS messages. The control characters (tags) used in conjunction with the formatting language take up most of the available data transfer capacity, because they are transmitted as ASCII symbols, just like the information itself. To solve this problem, a terminal including a data transfer system was developed in conjunction with the invention, which reduces the problems caused by limiting SMS messages to a maximum of 160 characters and by using the control characters when using Internet services. Its functionality is described below with the help of some implementations.

In the first implementation of the invention, the mobile telephone network is used with the help of the mobile terminal 10, 11, 12, and the weather service page 60 presented by the Internet server 70 is also used via the Internet network 50 (Figure 3). In this example, the data transfer takes place between the SMS TCP/IP server 30

and the mobile terminal 10, 11, 12 using the HTMesTP protocol characteristic of the invention, the structure of which will be discussed in more detail later. The weather service page 60 offered by the Internet server 70 is, however, transmitted via the Internet network 50 to the SMS-TCP/IP server 30 using the known HTTP protocol. The SMS-TCP/IP server 30 converts the weather service page 60 written in HTML language into HTMesL format according to the invention and composes the required grammar. However, there are no obstacles to the Internet server 70 already offering the service carrying out the conversion mentioned.

SGML (Structured Generic Markup Language) is the international standard (ISO 8879 SGML) introduced in 1986 that defines a specific framework for electronic data traffic. It defines the different parts of the document, as well as how and in what format the different parts of the document are presented. SGML is based on the use of certain control characters (tags) that define functions and operations for minimizing the size of the document. Table 1 below shows, for example, the structure of the page created in SGML language:

<memo>

<address>To: George O'Sullivan</address>

<sender>From:Sysop</sender>

<date>date: March 13, 1996</date>

<subject>RE: Example of SGML</subject>

<text>This is a sample of SGML code.</text>

</memo>

Table 1, an example of the page structure created in SGML language

In this example, the use of control characters (tag) such as 'memo', 'address', 'sender', 'date', 'subject' and 'text' determines the type definition DTD

(Document Type Definition). The syntax used above (<tag>, </tag>) is application-specific. In the SGML formatting language, the 255-character ASCII code is used as standard. The developer of the SGML language can define the characters himself,

which begins and ends a specific unit. This enables the SGML file to be easily edited using traditional text editors even in cases where no special editors are available for planning the editing of specific SGML files.

In Figure 3, a weather service page 60 is shown in the form in which it is shown to the user on the display of the terminal devices 10, 11, 12. The size of the display and the structure of the terminal devices 10, 11, 12 determine whether the weather service page 60 appears on the screen all at once or whether it has to be divided into page sections. In the following, we use the multi-service mobile radio communication 12 based on the Nokia 9000 Communicator as an example in accordance with the invention, on whose large LCD display the entire weather service page 60 can be shown at once. The corresponding weather service page is shown in Table 2 below in HTML language in the so-called source code (document source code).

<html>

<head>

&bull; 4 ·· ·

<title>World Weather Service</title> </head> <body> <h1>Welcome to the World Weather Service</h1> <h2>Weather Today</h2> Cloudy. Probability of rain showers 30%.

<h2>Temperature</h2> 10-14C <h3>

<a>href="htmp:https://weather. world. com:444/cgi bin/tomorrow.pl">Weather Tomorrow</a> </body> </html> Table 2, image of weather service page 60 in source code

This HTML example page contains 294 ASCII characters, which means that it is not possible to transmit it as an SMS message (max. 160 characters). In the invention, a separate identifier is defined for both the control characters (tag, e.g. <html>) and the information line (e.g. Weather Today), which in this implementation example has a size of one byte (8 bits). The creator of the application-related grammar can freely choose the identifiers for the characters and information lines. Identifiers with an example character are presented in Table 3 below. The first character is the special character "&par", which means that according to the invention the message written in HTML language can be distinguished from the message created in conventional HTML language.

Instead of the special character "&par" any other character or character sequence can be used.

Identifier code Sign
number Sign
number &par 4 10 <html> 6 2 12 <head> 6 2 14 <title> 7 2 30 World Weather Service 21 CVl 15 </title> 8th 2 13 </head> 7 2 16 <body> 6 2 18 <h1> 4 2 31 Welcome to the World Weather Service 36 2 19 <ht1> 5 2 IB <h2> 4 2 32 Weather Today 13 2 1A </h2> 5 cvi FF Cloudy. Probability of rain showers 30%. 40 2 1B <h2> 4 2 33 Temperature 11 2 1A </h2> 5 CVl FF 10-14C 9 2 1D <h3> 4 cvi 34 <ahref="htmp:https://weather.world.com:444/cgi-
bin/tomorrow.pl">WeatherTomorrow</a> 17 </body> 7 2 11 </html> 7 2

characters together

294 48

Table 3, Converting an HTML page to an HTML page

The structure of the HTMLesL page formatting language of the invention is described in more detail below. The HTMLesL language works according to the same pattern as the HTTP and HTML protocols known to industry experts from the Internet in the WWW environment.

work together. The HTMesL uses the character types and structure of the HTML language as a basis, as well as the terminal devices 10, 11, 12 and the SMS TCP/IP server 30 at the end, but uses special characters (tags) to indicate that it is a coded page. This special character (tag) can be, for example, the first character or the first character sequence of the HTML page.

The meaning of the special character is to indicate to the recipient that the incoming message is a page created in HTML language.

The special character (e.g. &par) is obligatory so that, according to the invention, the terminal 10, 11, 12 is able to present the desired web page. With the help of the special character, the terminal 10, 11, 12 recognizes that the information received from the TCP/IP server 30 (e.g. the weather service page 60 originally created in HTML language by the Internet server 70) has been coded according to the invention. This special character (tag) makes it possible to store the information contained in the compressed pages of the terminal 10, 11, 12, from which this can later be retrieved and supplemented by receiving the variable parameter information 63, 65 by the terminal 10, 11, 12. This only allows the transmission of the reference code (code that indicates to which website or service the associated information is sent) and the parameter information 63, 65 (the variable information that offers the service itself) in an SMS message.

The numbers on the right-hand side of Table 3 describe the length of the characters and information lines in the form of ASCII symbols before and after their substitution by identifiers. Table 3 shows lines 61-66 (Figure 3) marked in bold on weather service page 60.

With the help of the identifiers, it is possible to reduce the total number of characters of the information specified for the weather service map 60 from the original 294 ASCII characters to 48 characters (identifiers) and 40+9 information characters (Cloudy. Probability of rain showers 30%. And 10-14 C). This results in only 97 ASCII characters in total, so that the information contained in the weather service page 60 can already be transmitted in this form in an SMS message, provided that the information received can be reconstructed in the receiving terminal 12. The

Reconstruction of the message is described in more detail below. In its entirety, the message can be presented in the following form:

&par101214301513161831191B321AFF1B331AFF1D341711 [er] Cloudy. Probability of rain showers 30%.[er]
10-14C

The first line consists of 48 identifiers (4+22*2 characters), each of which is represented by two characters, and the carriage return character [er] that ends the line. [cr] characters are used both to indicate the starting point of the first information parameter and to distinguish the information parameters from each other. The identifier FF (shown in bold) is reserved for indicating the placement of information parameters 63 and 65 ("Cloudy. Probability of rain showers 30%." and "10-14 C") on the web page. In this case, the use of the carriage return character [er] increases the total number of characters by two, so that according to the example, the weather service page 60 presented in this form requires 99 characters. The carriage return character is used here as an example, it can also be replaced by any other special character, e.g. by a rarely used upside-down question mark &igr;, or any combination of several characters. The character or character combination must be defined for the service.

The message shown above can be further compressed by defining the object (A2 in this example) which lists the 44-character identification sequence in the first row.

"A2"="101214301513161831191B321AFF1B331AFF1D341711"

The object A2 is stored in the local mobile terminal 10,11,12, from which it is always retrieved when the weather service page 60 is edited on the display of the terminal 10, 11, 12. If the weather service map 60 is compressed in the manner mentioned above, the total length of the message is 57 characters (4+2+40+9+2 line break characters), i.e.:

&;parA2[cr]

Cloudy. Probability of rain showers 30%.[er]

10-14C

As can easily be seen from the message presented above, the message is formed almost exclusively from the information parameters 63 and 65 ("Cloudy. Probability of rain showers 30%." and "10-14 C"). This is precisely the purpose of the invention - only the changing information 63, 65 offered by the service is transmitted via the data transfer connection used. The other information contained in the weather service page 60 (Figure 3, references 61, 62, 64, 66), which remains unchanged between service usage times, is generated via the terminal 10, 11, 12, using the grammar stored in the terminal 10, 11, 12. The grammar is stored in the terminal 10, 11, 12 when the service is used for the first time, or when the grammar changes, e.g. when the layout of the website changes. The storage of the grammar and the grammar messages 87 used in the storage will be described in detail later.

When using the web pages in the traditional WWW environment, the simple server architecture for customers is used. When using the service he wants (e.g. hypertext page), the customer requests an HTTP protocol (HyperText Transfer Protocol). The HTTP protocol was designed for the transfer of HTML pages, but it is also suitable for other variants of data transfer. The HTTP protocol used proves to be particularly inefficient with regard to the data transfer path. By means of a compression method developed according to the invention (such as the HTMesL described above), the HTMesTP protocol (Hypertext Messaging Transfer Protocol) is used for the transmission of the compressed service pages between the SMS-TiPC/IP server 30 and the terminal 10, 11, 12 according to the invention. This is an example of a new type of message that the SMS-TCP/IP server 30 can set up according to the invention. Such special message types are used when defining the processor and transmitter of the message in the mobile communication system. For example, the message type contains three types of messages. Grammar messages (Syntax Message Header) are used in the service where the new grammar to be used is transmitted from the service provider to the terminal 10, 11, 12, composite messages are used both for transmitting the new grammar and the information parameters 63, 65 and for transmitting the parameters required for the service request messages.

In Figure 4, the operation of the terminal device 10, 11, 12, the SMS-TCP/IP server 30 and the Internet server 70 is shown as a functional diagram in the phase when the terminal device 10, 11, 12 requests the weather service page 60 from the Internet server 70 by means of a service request message (phase 80). The service request message contains the identifier 41, on the basis of which the receiving SMS-TCP/IP server 30 is able to correctly process the received message 40 (among other things, it can recognize from which terminal device 10, 11, 12 the message was received, what type of message it is, how the message should be processed, etc.).

The structure of the message will be described in more detail later, including in connection with the explanations for Figure 5. After receiving the service request message from the terminal 10, 11, 12, the SMS TCP/IP server 30 deletes the identifier 41 of the message (phase 81), uploads the service request to the Internet based on the URL address contained in the service request message 80, and forwards it to the Internet server 70 in the form of a service request message (phase 82). The service request message follows the general HTTP protocol of the Internet, which means that the service request message is no different from the normal data transfer between the servers 30, 70 that takes place on the Internet.

In response to the service request message, the Internet server 70 transmits the requested web page to the SMS-TCP/IP server 30 in HTML format, according to the HTML standard (phase 83), controlled by the URL address. In this phase, the web page is therefore still in HTML format and can therefore still contain a considerable amount of information. The SMS-TCP/IP server 30 transforms parts of the received HTML web page according to the grammar characteristic of the service, stores parts of the HTML page in its database and assigns identifiers to the various parts. In the case of the weather service page 60, this is implemented according to Table 3 (phase 84). By comparing the specific data stock of the terminal 10, 11, 12 with the data stock updated on the basis of the receipt of the HTML page, the SMS-TCP/IP server 30 knows which parts of the HTML web page are already known to the terminal 10, 11, 12 (phase 85). These parts do not have to be transmitted again; it is sufficient that only the identifiers are sent (Table 3). If, by comparing data stocks, the SMS-TCP/IP server 30 notices that the grammar used has changed when the service is transmitted, e.g. new parts have been created from the received HTML page that were not previously transmitted to the terminal 10, 11, 12, these must be updated before the actual message is sent.

Service message can be transmitted. This can be achieved with the help of a special grammar message (phase 87). Before sending the grammar message, the SMS TCP/IP server 30 adds identifiers 41 to the message 87 to be transmitted, on the basis of which the terminal 10, 11, 12 can function correctly. After receiving the grammar message, the terminal 10, 11, 12 updates its database on the basis of the information contained in the identifier 41 and the grammar (phase 88). After updating the database, the terminal 10, 11, 12 is ready to receive the actual service message.

The SMS-TCP/IP server 30 transmits the service message to the terminal 10, 11, 12 if it has determined by comparing its data sets that the data sets of the SMS-TCP/IP server 30 and the terminal 10, 11, 12 correspond to one another. The service message is transmitted as a composite message that contains both the identifiers (the numbers 31, 32, 33 and 34 in the first column of Table 3, which refer to the text lines 61, 62, 64 and 66 in Figure 3) for the desired information lines and the information parameters (63, 65) (phase 89) themselves. The combined messages can also include temporary objects, which are stored in the cache memory of the terminal 10, 11, 12, but not in the object database of the terminal 10, 11, 12. If the same service is used several times in succession, such temporary objects can also be used, for example, to speed up the storage medium. It is also possible to define that if the same temporary object is used several times in succession, it is automatically stored in the object database of the terminal 10, 11, 12. After receiving the combined message, the terminal 10, 11, 12 unpacks the message (phase 90). It sorts the parts of the message 40 and retrieves the equivalents for the identifiers (Table 3) from its database for the receiving devices. Based on this, the terminal device 10, 11, 12 generates the service page 60 for the screen of the terminal device 10, 11, 12.

Figure 5 shows the exemplary structure of the message 40, according to the HTML protocol, which includes the message header field 41 and the information field 42. The message header field 41 includes the parameters describing the structure of the message 40 and address information that is contained in this example message 40:

Address type identifier 43, which defines the structure of the message header field 41, essentially the form in which the address information used is presented when the message 40 is transmitted, the xxxiOxxx listed later in the example in Table 4 means that the address is reported with 4 bytes (so-called ipv4 address type), xxx11xxx would mean that the address is reported with bytes (ipv6 address type),

the message type identifier 44, which defines, among other things, the type of message 40 it is, in the example in Table 4, xxxxxOOO corresponds to the Griammamatic message, xxxxOOI corresponds to the composite message, XXXXX010 corresponds to the service request message, etc.,

Address information 45, on the basis of which the message 40 is transmitted between the Internet server 70, the SMS-TCP/IP server 30 and the mobile terminal 10,11,12, in example 4 is reported with 4 bytes.

Grammar database address 46, which defines which grammar recorded in the memory of the terminal device 10, 11, 12 and the SMS TCP/IP server is used in the reconstruction of the service page 60 for the screen of the terminal device 10, 11, 12, in the example in Table 4 is reported with 1 byte, and

The length information of the message 47.

The compressed web page written in HTMLesL page formatting language is included in the information field 42.

The structure of the message 40 described above is exemplary. If required, for example, the additional information field 48' can be added to the message header field 41. This flexible structure enables the creation of new, structurally different messages as required. The number of different messages that can be transmitted depends on the number of bits used to present the address type identifier 43. The structure of the address field 41 is shown in Table 4 below.

Location

Location

Location

address

Type

address

News
Iffi

Message Iffi

Message IYP.

Ipv4 address

Ipv4 address

Ipv4 address

I pv4 address

Grammar identification

Message length

Table 4, Example of the structure of the message header field 41

The grammar message is sent by the SMS-TCP/IP server 30. The SMS-TCP/IP server 30 uses the grammar message to update the object database of the terminal device 10, 11, 12. The terminal device 10, 11, 12 itself decides whether to accept the updated information from the SMS-TCP/IP server 30 or not. Security aspects should also be taken into account in this phase so that incorrect grammar information cannot disrupt the operation of the system. To ensure the correctness of the grammar messages, it is possible to use, for example, the digital signing of messages of the type RSA public key document (message) signatures. The following example shows two grammar messages which in themselves define all the grammar required in the weather service page example presented above *.

Grammar Note 1:

00001000 F3045644,23,!en(msg) 10 <html> ff12 <head> ff14 <title> ff30 World Weather Service ff15 </title> ff13 </head> Ff16 <body>

Ff18 <h1> Ff31 Welcome to the World Weather Service Ff19 </h1> Ff1b <h2>

Grammar Note 2:

00001000 F3045644,23,len(msg) 32 Weather today Ff1a </h2> fffe Ff33 Temperature Fffe Ff1d <h3> F34 <a href="htmp:https://weather.worlcom:444/cgi-
bin/tomorrow.pl">WeatherTomorrow</a> Ff17 </bodv> Ff11 </html>

The compound message is, as its name suggests, a message that contains two pieces of information. The first part of the message contains the grammar information that is not constantly added to the object database, the second part contains the information parameters. If the same object address is used twice in a row, the new grammar replaces the old grammar in the object database. The compound message contains the object reference to the grammar database and the parameters to complete the page to be generated. The compound message begins with a separate command. The special commands are grammar-dependent and are to be selected by the service provider.

The service request message is transmitted by the terminal 10, 11, 12. It contains the Internet address (URL), the resource identifier of the service and the optional parameters for accessing the service. If the user wants to use the service, he must send a service request message. In this case, the SMS TCP/IP server 30 updates the object database of the

Terminal 10, 11, 12 by adding the grammar definitions to the cache memory of the terminal.

The grammar definition can also contain the HTML text that is more than one character (tag). It can even contain an entire HTML page, a parameter block, or an HTML anchor reference, such as

34

<a href="htmp:https://weather. world.com:444/cgibin/tomorrow.pl">Weather Tomorrow</a>

The object identifier 0x34 has the address (URL) for tomorrow's weather service. It refers to the HTML block that carries out the service request to obtain the weather report.

In the above-described embodiment of the invention, the weather service page was called up from the terminal 70 connected to the Internet network 50 using the terminal 10, 11, 12. According to the invention, the system can also be used for data transfer between two terminals 10, 11, 12. An advantageous embodiment involves the process when users of terminals exchange information with each other using pages created in HTML language. Then, for example, the transmission of a page created in HTML page formatting language, e.g. from a computer 13 connected to the terminal 10 (usually a mobile phone) to the terminal 12, involves the following phases:

&bull; the user of the terminal 11 edits a page with a portable

Computers 13.

&bull; the user decides to send a message when the compression program installed on the computer 13 converts the HTML page into HTMesL format and creates the required grammar.

&bull; the computer generates grammar messages and the

composed message and transmits it to the mobile phone, packed in SMS message format and in a form adapted for the data transfer connection for the HTMLesTP protocol.

&bull; the terminal 10 (mobile phone) transmits the SMS message (SMS messages) via the mobile communication network 105, 102, 100, 20, 101, 103, 107 to the terminal 12.

&bull; the terminal 12 identifies from the received message that it is a compressed HTML page formatting language

# ft * * ft ft « * * ft · *

message and forwards it to the correct processor on the basis of the identifiers 41 placed in the HTMLesTP frame. &bull; since it is a page written in HTMLesL page formatting language, the decompression program installed in the terminal 12 unpacks the page into HTML format and transmits it to a suitable program that enables the reading of pages written in HTML language (generally called a WWW browser) for display on the display of the terminal 12.

Figure 6 shows the parts used to transmit the web page 60 in the information transmission system according to the invention. The terminal 11 includes, among other things, both the processing of the web pages 60 presented in HTML and HTMes page formatting language by the processor 121 and the recording of the grammar presented in Table 3 in the memory 122. Accordingly, the SMS-TCP/IP server 30 includes, among other things, the protocol transformation of the processor 124 between the HTTP and HTMesTP protocols and the recording of the grammar in the memory 125. The data transfer connection 123 describes the base station 101 shown in Figure 1, the base station controller 102, the data transfer running via the mobile telephone center 100 and the SMS message center 20 to the SMS-TCP/IP server 30 and the data transfer connection 126 to the Internet server 70 through the data transfer running via the Internet network.

Here, the implementation and performance forms of the invention were described using examples. It is clear to industry experts that the invention is not limited to the details of the performance forms presented above and that the invention can also be implemented in other forms without deviating from the essential features of the invention. The presentation of the performance forms was explanatory in nature, but not restrictive. The implementation and use options of the invention are only limited by the following protection requirements. These requirements determine various implementation alternatives of the invention, and equivalent implementations also fall within the scope of the invention.

Claims (4)

TERMEER STEINMEISTER & PARTNEfVo'bR"' "* *·"·*·23- Nokia Mobile Phones Ltd. Case: 12212 DE Protection claims 1. Data transfer system for transmitting an information page (60) implemented in page formatting language in a data transmission network (20, 30, 50, 100, 110, 123, 126) from a first terminal (10, 11, 12, 13, 30, 70) to a second terminal (10, 11, 12, 13, 30, 70), wherein the first terminal (10, 11, 12, 13, 30, 70) comprises first processing units (121, 122, 123, 124) for processing and transmitting the information page (60) implemented in page formatting language to the second terminal (10, 11, 12, 13, 30, 70) via the data transmission network (20, 30, 50, 100, 110, 123, 126), the second terminal (10, 11, 12, 13, 30, 70) comprises second processing units (121, 122, 123, 124) for receiving and further processing the information page (60) implemented in page formatting language and - the page formatting language mentioned comprises characters and information lines (61, 62, 63, 64, 65, 66),
characterized in that the first processing units (121, 122, 123, 124) are arranged to assign a specific identifier to each character and the information lines (61, 62, 63, 64, 65, 66) to form a grammar (84), the first processing units (121, 122, 123, 124) are set up to transmit the grammar to the second terminal (10, 11, 12, 13, 30, 70) if it has not already been transmitted earlier (85, 86, 87, 88), - the first processing units (121, 122, 123, 124) are set up to transmit the identifiers to the second terminal (10, 11, 12, 13, 30, 70), and the second processing units (121, 122, 123, 124) are configured to reconstruct the information page (60) on the basis of the received grammar and the identifiers. 2. Terminal for transmitting an information page (60) implemented in page formatting language to a recipient via a data transmission network (20, 30, 50, 100, 110, 123, 126), with processing units TERMEER STEINMEISTER &PARTlWn-ÖbR* ^: " ^! -· ^# ·^4- Nolda MobUe Phones Ltd. Case: 12212 DE ten (121, 122, 123, 124) for processing and forwarding the information page (60) implemented in page formatting language to the recipient, wherein the page formatting language comprises characters and information lines (61, 62, 63, 64, 65, 66),
characterized in that the processing units (121, 122, 123, 124) are arranged to assign a specific identifier to each character and the information lines (61, 62, 63, 64, 65, 66) to form a grammar (84), the processing units (121, 122, 123, 124) are arranged to transmit the said grammar to the recipient if it has not already been transmitted previously (85, 86, 87, 88), and the process units (121, 122, 123, 124) are configured to transmit the identifiers to the second terminal (10, 11, 12, 13, 30, 70).
15 3. Terminal according to claim 2, characterized in that it is a mobile device (10, 11, 12, 13). 4. Terminal according to claim 2, characterized in that it comprises a server (30, 70) connected to the data transmission network (50, 110).