EP1232625A1

EP1232625A1 - Transferring fitted content for a user from a server

Info

Publication number: EP1232625A1
Application number: EP00972952A
Authority: EP
Inventors: Gabor Paller; Erno Zalka
Original assignee: Nokia Oyj; Nokia Inc
Current assignee: Nokia Oyj; Nokia Inc
Priority date: 1999-11-09
Filing date: 2000-11-01
Publication date: 2002-08-21
Also published as: AU1151001A; CN1408168A; WO2001035595A1

Abstract

A technique for transferring content between a server and a client when the client has a limited CPU capability includes the client forwarding a request for content to the server with a header, the header including the characteristics of the client. The server then scales the requested content according to the client characteristics contained in the header so as to be suitable for use by the client prior to transmitting the content to the client. In addition, the technique for transferring content between a server and a client having a limited memory capacity via a gateway disposed between the server and client includes splitting a page to be sent to the client from the server into two or more sub-pages when the memory of the client is insufficient to store the entire page, the information as to the size of the memory of the client being forwarded to the gateway.

Description

TR_ANSFERRING FITTED CONTENT FOR A USER FROM A SERVER

FIELD OF THE INVENTION

The present invention relates to client/server systems and more particularly, the present invention relates to transferring content between server and client.

DESCRIPTION OF THE RELATED ART

One of the latest innovations in cellular telephone technology that is being pursued by the major cellular telephone manufacturers is the implementation of cellular telephones with larger graphic displays to allow a cellular telephone user to access various databases and services via the Internet.

To operate such a cellular telephone arrangement, the user turns on the telephone and a signal is sent to an antenna which transmits the signal to the nearest cellular receiving base station which picks up the telephone's transmission.

The customer then, for example, dials a request for an internet connection to the base station which then sends the request through a base station controller to a mobile switching center. The switching center routes the request via the appropriate route to the desired destination, e.g. - the web server address defined in the request (URL).

When the server retrieves the information requested by the customer, the information is reformatted to fit on the cellular telephone display screen and the information is passed through the mobile switching center and base station controller and base station to be transmitted back to the cellular telephone where the requested information is then displayed on the display of the cellular telephone.

Unfortunately, the capability of the microprocessor contained within the cellular telephone and the memory capacity of the cellular telephone are relatively limited.

Furthermore, the size of the display and its resolution are also limited. Lastly, the data transmission speeds for transmitting data between the server and the client (that is - the cellular telephone) is presently limited to around 9.6 kilobits per second which is considerably slower than the 56 kilobits per second commonly used by clients communicating with Internet servers via ordinary land based telephone lines and substantially slower than clients communicating with servers utilizing high speed data lines (e.g. - Digital Subscriber Lines).

Thus, there is a need reduce the amount of processing to be performed by the CPU and the cellular telephone by placing more of the processing load on the server. This is particularly true with regard to adjusting the aspect ratio and scaling of graphical content to be transmitted from the server to the client so as to be displayed on the cellular telephone display.

Furthermore, since the information presented on a page in the internet server to be transmitted to the client has usually been prepared without regard for the size of the memory of the client since internet clients normally have sufficient memory size, there is a need for a technique for splitting a page to be transmitted from the server to the client into two or more sub-pages when the memory of the client is insufficient to store the entire page.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide a new technique for transferring content between a server and a client.

More particularly, it is an object of the present invention to provide a technique for transferring content between a server and a client when the client has limited CPU capability by having the server effect conversion of the aspect ratio and scaling of the content so as to be suitable for the display of the client prior to transmitting the content to the client.

Furthermore, it is another object of the present invention to provide a new technique for transferring content between a server and a client having a limited memory capacity via a gateway by having the gateway split a page to be sent to the client into two or more sub-pages when the memory of the client is insufficient to store the entire page. According to a first aspect of the invention there is provided a method of transferring content between a server and a client, the method comprising the steps of: sending a request for content and characteristics of the client from the client to the server; fitting the requested content in the server according to the characteristics of the client forwarded by the client; and sending the fitted requested content from the server to the client. According to a second aspect of the invention there is provided an apparatus for transferring content between a server and a client, the apparatus, disposed within the server, comprising: a receiver for receiving from the client a request for content and characteristics of the client; a memory for storing the content requested by the client; fitting means for fitting the stored content according to the characteristics of the client forwarded by the client; and an output unit for sending the fitted requested content to the client. Further embodiments of the method and apparatus aspect are defined in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 illustrates a telecommunication system to which the present invention may be applied. Fig. 2 is a flowchart of the operation of a portion of the present invention.

Fig. 3 illustrates page splitting in accordance with the present invention.

Fig. 4 is a flowchart illustrating scaling in accordance with the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

The following description of the present invention by way of example has utilized the operation of a cellular telephone connected to an internet web server. However, it is to be understood that the present invention is not limited to such an arrangement but rather is applicable to any client/server arrangement in which the client has a CPU with limited capabilities and/or a limited memory capacity.

Referring to Fig. 1 , which illustrates the configuration of a cellular telephone system, initially, a customer forwards a request for content from an internet web server.

The request is sent by radio waves to a base station which in turn transmits the request to a base station controller which is also connected to other base stations.

The base station controller forwards the request to a mobile switching center which, in the case of an ordinary phone call, sends information to a central telephone office for connection to a requested telephone or, in the case of an internet request, forwards the internet request, for example, through a WAP (Wireless Application Protocol) Gateway, to an internet web server.

The internet web server processes the request and forwards the content back to the cellular telephone of the client essentially tracing the same path back to the cellular telephone.

Normally, a client requesting content from an internet web server is utilizing either a desktop computer having a relatively large display and a reasonably powerful CPU and sufficient memory for both storing and displaying graphical content or a laptop computer which may have a somewhat less powerful CPU and a smaller memory capacity but nevertheless has sufficient power and memory capacity to display graphical content from the internet web server.

On the other hand, the newly developed cellular telephones with internet functions are equipped with CPUs having limited capability and very small size memories used for storing graphical content.

Fig. 2 illustrates a flowchart illustrating an embodiment of the fitting function of the present invention in the form of a page splitting function. Upon starting the page splitting function, the client initiates contact with the web server utilizing an appropriate client/server handshake protocol and further sends a request to the web server for content in Step 10. Included in the handshake protocol is information transmitted to the server as to the memory capability of the client with regard to storing a page of graphical content.

Note that the request and handshake protocol and content are not transmitted directly between the mobile switching center and the internet web server but rather are transferred via a WAP (Wireless Application Protocol) Gateway which serves as an interface between the mobile switching center or cellular network and the internet web server and which actually performs the various functions of the present invention as well as performing various other functions.

In Step 20, a WML (Wireless Markup Language) page is received by the Gateway from the web server in response to the request of the client.

In Step 30, the WML page is formatted and all unnecessary material removed (such as comments, unnecessary line breaks, etc.). This "cleaning" of the WML page reduces the amount of memory needed for the page and allows a more precise estimation as to whether page splitting is needed.

In Step 35, the page size (that is, the amount of memory needed to store such a page) is determined.

In Step 40, the WML page size is compared with the client memory limit which was previously transferred to the Gateway during the aforementioned handshake procedure.

In view of the fact that the WML page must be compiled prior to forwarding to the client, the comparison of the uncompiled WML page size with the client memory limit cannot determine with no uncertainty as to whether the compiled WML page is greater than the client memory limit but rather can only determine with certainty that the uncompiled WML page size is greater than the client memory limit thereby insuring that the compiled WML page size must be greater than the client memory limit.

Accordingly, if the uncompiled WML page size is greater than the client memory limit, the process moves to Step 50 in which the WML page is split into two or more WML sub-pages.

The details of the splitting of the WML page will be discussed in detail below. In Step 60, the split WML sub-pages are compiled in accordance with the usual protocols and in Step 70, the compiled WML sub-pages are sent to the client for display on the client's display.

Alternatively, if in Step 40 the WML page size is not greater than the client memory limit, the process proceeds to Step 80 in which the WML page is compiled using the same protocol utilized in Step 60.

In Step 90, the compiled WML page size is compared with the client memory limit.

If the compiled WML page size is greater than the client memory limit, it is of course necessary to split the WML page into two or more WML sub-pages and accordingly, the process proceeds to Step 50 in which the WML page is split into two or more WLM sub-pages as noted above. Alternatively, if the compiled WML page size is not greater than the client memory limit, then the compiled WML page is then sent to the client as in Step 70. Fig. 3 illustrates an example of WML page splitting in accordance with the present invention.

The original page is unfortunately too large to be stored and displayed on the display of the client.

Accordingly, in accordance with the present invention, the original page is split into sub-page 1/2 and sub-page 2/2.

Note that the Header, the Options, and the Back are common elements to both sub-pages and further note that the Next and Prev link lead to sub-pages of each other.

As to the details of page splitting, the following common elements must appear on each sub-page:

A - Some common tasks (Templates, Time, Go Type = "Accept", etc.);

B - Headers; C - Options; and D - Back.

The following elements are unsplittable elements which must be kept together on the same page:

A - Links, tasks (Go, Do, etc.); B - Some input types (Optgroup, Fieldset, etc.); and C - Words. If it is necessary to split an Optgroup, it can be effected by placing a link to the actual page which points to a separate sub-page with the Optgroup on it. When splitting in the middle of formatting elements, the elements must be closed and reopened on the next page. For example:

<l> Please, Mary, be my wife, I will never leave you! </l>

must be split into the following two parts:

<l> Please, Mary, be my wife, </l> <l> I will never leave you! </l>

A Deck (which is a precisely defined WAP term) is a downloaded unit of content. A WAP link always points to a Deck/Card. The Deck contains one or more Cards. For example, the display unit is the Card and the downloaded unit is the Deck. If there is a link in a Card which points to another Card in the same Deck, then the following link will cause no network traffic. The possible splitting points in a Deck (in the order of from best to worst) are as follows:

A - Between cards (optimal); B - Between paragraphs; C - Between links; D - Between formatters;

E - At line breaks;

F - Between sentences (in the text); and G - Words (in the text). The switching between sub-pages may be implemented with the following: A - Options;

B - Anchor(s) at the top of the sub-page; and C - Anchor(s) at the bottom of the sub-page. Note that the WAP Standard defines at least two buttons for the client. The name of these buttons are Options" and "Back." By pressing the Options" button, the user can reach the functions defined by the web browser, such as "exit browsing," "set bookmark," etc. and functions set by the WAP application. The "Back" button is mostly used to step back, as in the case of an HTML

(hypertext markup language) browser, but the WAP application can assign a different action (and title) to it, or can disable (hide it).

An "Anchor" is a synonym for a link. A WAP link looks very similar to an HTML link, that is, it is underlined and points to a URL. If the memory of the client is extremely limited, it is advisable to reduce the size of the page as much as possible. Accordingly, the following element IDs should be translated to and from one character (or very short) identifiers. A - URL(s); B - card names; and C - variable names.

For example, ID references (first of all, the URL references) are stored in the WMLC without compression. The process of shortening can be:

1. The client is requesting a page, say http://wap.server.com/menu/main.wml"

2. This page contains a link (an anchor...), say http://wap.server.com/apps/banking/welcome.wml

3. The WAP Gateway gets the page and translates it to: http://x166346 and remarks that 166346 is equal to http://wap.server.com/apps/banking/welcome.wml"

4. The clients gets the page with the URL in it: http://x166346

The user clicks the "banking" link.

The client sends a request, asks for the http://x 166346 link selected by the user.

7. The WAP Gateway translates the request to http://wap.server.com/apps/banking/welcome.wml" from its translation table and passes the http request to the application server.

Thus, the client browser will deal with short URLs instead of long ones. A Deck contains at least one URL per Card and usually 5-10 URLs per Card. Thus, the translation of IDs to reduce the size is significant when the client memory is extremely limited.

Fig. 4 is a flowchart illustrating another aspect of the present invention, namely, fitting the content by the scaling of content, such as graphical content, when the client requests such graphical content provided by the server and then displays the received graphical content.

There have been long discussions on the coordinate system model for use with a "thin" client, such as a cellular telephone, in a client/server system.

Two possible approaches were using physical device coordinates and logical coordinates. Using physical device coordinates means that an application programmer uses the actual device coordinates of the screen of the client. For example, if the programmer wishes to draw a line from one end of the screen to another and the width of the client display is 100 screen pixels or dots, then the actual drawing instruction is something like a line (1 , 100).

The disadvantage of the physical device coordinate solution is that the application program must take care of all of the aspect ratio and scaling problems. This is disadvantageous in that programmer must consider all different client displays.

A second solution is the use of a logical coordinate system wherein a graphics submodule of the client takes care of the display scaling. The advantage of this solution is that the application programmer does not have to be concerned with the size or aspect ratio or other characteristics of the display of the client. However, a disadvantage of the logical coordinate approach is that there is a heavy load of scaling on the CPU of the client which can be prohibitive in the case of a CPU having limited capabilities such as that used in a cellular telephone. In the present invention, the load of scaling is placed on the server rather than the client. When a client sends a request to the server for content, such as graphical content, it also provides the physical device characteristics of the client display such as X resolution, Y resolution, and aspect ratio. The server then scales the requested graphical content according to the device characteristics provided by the client and then forwards the scaled requested graphical content to the client.

As illustrated in Fig. 4, in Step 100, the client sends a request for graphical content with a header containing the physical characteristics of the client display to the server. The header, for example an Accept-viewport header, provides the X and Y display sizes or resolution of the display and the aspect ratio of the display.

In Step 110, the server stores the requested graphical content in logical coordinate format.

Upon beginning to process the request from the client, the server scales the graphical elements of the requested graphical content according to the characteristics contained in the header forwarded by the client.

In Step 130, the scaled requested graphical content is sent from the server to the client for display on the client's display.

A concrete example of the above-noted scaling in accordance with the present invention is described below.

Device characteristics are communicated in optional protocol headers. A concrete example would be an HTTP (Hypertext Transfer Protocol) header, as is shown below. An example HTTP request packet looks like: GET/svg/drawing.svg HTTP/1.0 The previous request extended by device characteristics header would be the following:

GET /svg/drawing.svg HTTP/1.0 Accept-viewport: 70 45 1.1 where the numbers are screen width, height and aspect ratio.

The server stores the content in a normalized form. For example, the total width is represented as 1.0, the total height is likewise 1.0. A line that crosses the screen from top left to bottom right corner would look like: line(0.0, 0.0, 1.0, 1.0) When the server receives the request header with device characteristics, it will scale the content. It multiplies the screen width and height in the content with the physical width and height. After scaling the content would look like: line(0,0,70,45)

This scaled content is then sent to the client which displays it. HTTP example

GET/svg/drawing.svg HTTP/1.0 Accept-viewport: 70 45 1.1

or

GET/servlet/drawswrvlet HTTP/1.0 Accept-viewport: 70 45 1.1

posx=10&posy=30

Although HTTP is almost always used in client/server systems, it is of course understood that the present invention is not limited thereto but rather is applicable to other protocols.

By placing the significant load of scaling on the server, the computational load of the graphics operation of the CPU of the client is reduced by as much as 50% which is significant in the case of a CPU having limited capabilities such as those contained in cellular phones. The only disadvantage of scaling in accordance with the present invention is that the CPU of the server must perform the CPU intensive scaling operation for all of the clients connected thereto. This can be a problem in the case of small servers having limited capabilities. As noted above, the actual form of client device characteristics headers may vary depending on the communication protocol used between the client and server. Any transaction-type communication protocol would be suitable.

While the invention has been described in terms of embodiments, those skilled in the art will recognize that the invention can be practiced with modifications within the scope of the appended claims.

Claims

What is claimed is:

1. A method of transferring content between a server and a client, the method comprising the steps of: sending a request for content and characteristics of the client from the client to the server; fitting the requested content in the server according to the characteristics of the client forwarded by the client; and sending the fitted requested content from the server to the client.

2. A method according to claim 1 , wherein the step of fitting the requested content comprises scaling the requested content in the server according to the characteristics of the client forwarded by the client.

3. A method according to claim 2, wherein the step of: sending a request for content includes a header, the header including characteristics of the client; and the method comprises before the step of scaling the step of: storing the content requested by the client in the server in a logical coordinate format; whereby the step of scaling comprises: scaling elements of the stored content in the server according to the characteristics of the client contained in the header forwarded by the client.

4. A method according to claim 1 , the method comprising the steps of: A - performing a handshake procedure between client and server via a gateway disposed therebetween, the handshake procedure including forwarding a capability list to the gateway which in turn forwards portions of the list to the server;

B - forwarding a request for a page from the client to the web server via the gateway;

C - receiving the requested page by the gateway from the web server; D - formatting and cleaning the received page in the gateway; E - determining the size of the cleaned and formatted page in the gateway;

F - if the page size is greater than a client memory limit, proceeding to Step G, the client memory limit being contained within the capability list, and if the page size is not greater than the client memory limit, proceeding to step J;

G - splitting the page into two or more sub-pages, the number of sub- pages being determined by the page size and client memory limit;

H - compiling the sub-pages;

I - sending one of either the compiled page or sub-pages to the client; J - if the page size is not greater than the client memory limit in Step F, compiling the page and determining the page size of the compiled page; and

K - if the compiled page size is greater than the client memory limit, proceeding to Step G and if the compiled page size is not greater than the client memory limit, proceeding to Step I.

5. A method according to claim 1 , the method comprising the steps of:

A - forwarding a capability list to a gateway disposed between the client and server the capability list including a client memory limit;

B - forwarding a request from a page from the client to the web server via the gateway;

C - receiving the requested page by the gateway from the web server and determining the page size;

D - if the page size is greater than the client memory limit, then splitting the page into two or more sub-pages, the number of sub-pages being determined by the page size and client memory limit; and compiling the sub-pages and sending the compiled sub-pages to the client;

E - if the page size is not greater than the client memory limit, then compiling the page and determining the page size of the compiled page; and

F - if the compiled page size is greater than the client memory limit, splitting the page into two or more sub-pages, the number of sub-pages being determined by the page size and client memory limit and compiling the sub- pages and sending them to the client and if the compiled page size is not greater than the client memory, sending the compiled page to the client.

6. A method according to claim 4 or 5, wherein the requested page comprises a WML (Wireless Markup Language) page.

7. A method according to claim 4, wherein the header comprises a

HTTP (Hypertext Transfer Protocol) header.

8. A method according to any of claims 1 to 3, wherein the characteristics comprise an aspect ratio of a display of the client and at least one of display sizes and resolution of the display of the client.

9. A method according to claim 4 or 5, wherein the capability list comprises a client memory limit.

10. A method according to claim 5, further comprising the step of formatting and cleaning the requested page prior to determining its size in Step C.

11. A method according to claim 4 or 10, wherein the step of formatting and cleaning the received page in the Gateway includes the step of shortening element ID'S including URL(s), card names and variable names.

12. An apparatus for transferring content between a server and a client, the apparatus, disposed within the server, comprising: a receiver for receiving from the client a request for content and characteristics of the client; a memory for storing the content requested by the client; fitting means for fitting the stored content according to the characteristics of the client forwarded by the client; and an output unit for sending the fitted requested content to the client.

13. An apparatus according to claim 12, and comprising: the memory being adapted for storing the content requested by the client in a logical coordinate format; a sealer for scaling elements of the stored content according to the characteristics of the client contained in the header forwarded by the client; and the output unit being adapted for sending the scaled requested content to the client.

14. An apparatus according to claim 12, the apparatus comprising: a gateway disposed between the server and the client, the gateway being adapted to receive and forward portions of a capability list to the server; wherein said gateway is further adapted to forward a request for a page from the client to the web server and to receive and format and clean the received page and then determine the size of the cleaned and formatted page; and wherein said gateway is adapted to split the page into two or more sub-pages if the page size is greater than a client memory limit contained with the capability list, the number of sub-pages being determined by the page size and client memory limit and to compile the sub-pages and forward them to the client; and wherein said gateway is adapted to compile the page and determine the page size of the compiled page if the page size is not greater than the client memory limit and if the compiled page size is greater than the client memory limit the gateway is adapted to split the page into two or more sub- pages, the number of sub-pages being determined by the page size and client memory limit and the gateway is then adapted to compile the sub-pages and send them to the client and if the compiled page size is not greater than the memory limit, to send the compiled page to the client.

15. An apparatus according to claim 13, wherein the header comprises an HTTP (Hypertext Transfer Protocol) header.

16. An apparatus according to claim 12 or 13, wherein the characteristics comprise an aspect ratio of a display of said client and at least one of display sizes and resolution of the display of the client.

17. An apparatus according to claim 14, wherein the capability list comprises a client memory list.

18. An apparatus according to claim 14, wherein the requested page comprises a WML (Wireless Markup Language) page.

19. An apparatus according to claim 14, wherein the formatting and cleaning of the received page in the Gateway includes shortening element ID's including URL(s), card names and variable names.