WO1996027985A1

WO1996027985A1 - Method of transmitting data and method of and apparatus for displaying data

Info

Publication number: WO1996027985A1
Application number: PCT/GB1996/000525
Authority: WO
Inventors: Roy Howarth
Original assignee: Geoworks Limited
Priority date: 1995-03-07
Filing date: 1996-03-07
Publication date: 1996-09-12
Also published as: GB9504521D0; EP0818109A1; JPH11501407A

Abstract

Personnal communication devices can display complex page layouts showing news information, for example. This invention teaches constructing the actual displayed pages from different elements of 'virtual' pages held in a database stored in the receiving device and re-assembled in accordance with detailed formatting rules.

Description

Method of Transmitting Data and Method of and Apparatus for Displaying Data

Field of the invention

This invention relates to a method of transmitting data and a method of and apparatus for displaying data, typically of data broadcast to a message receiving apparatus, such as a receiver for pager transmissions, to enable pages to be displayed on a visual display screen of the message receiving device.

Description of the Prior Art

There are various established approaches to transmitting and receiving data, particularly data that can be processed to generate a display on a screen. For example, the techniques for transmitting data over computer networks form established and wide- ranging fields. Likewise, pager, television and Teletext transmission are broad and ever-developing areas. One characteristic of all such conventional approaches is that the final image that is displayed on a user's receiving unit, for example a television set, is generated direcdy from the received data: namely, the transmiπed/received data directly determines which screen elements, such as pixels or phosphor dots, are "on" or "off. The image perceived by a user is built up of the pattern of such screen elements. One exception to this is with characters. There are a number of different codes, developed in the computer field, which define the shape of a character to be displayed in terms of binary codes. Hence, ASCII defines codes for all commonly used characters. A document in ASCII can be transmitted over a computer, telephone or broadcast network and the original characters displayed at the receiving terminal if the ASCII is de-coded. In addition, page description languages, such as Postscript, are well known in the computing fields and are useful as a standardised format for describing the layout, font styles, etc. of text and graphics images.

Statement of the invention

In a first aspect of the invention, a method of transmitting data, to enable pages to be displayed on a visual display screen of a message receiving device, comprises the steps of: transmitting data elements, each defining a portion of a page or pages to be displayed, to pre-determined address locations in a memory of the message receiving device; wherein the message receiving device is operable to construct a page or pages to be displayed out of some of one or more such data elements in accordance with a set of pre-determined page formatting rules.

Hence, the data service provider [i.e. the organisation that transmits (typically by broadcasting) the data] no longer has to concern itself with the detailed formatting requirements of different recipients' message receiving devices. Instead, it transmits data to what can be regarded as parts of 'virtual' databases common to all message receiving devices. The databases are structured as pages, which are themselves made up of a number of fields; the fields can typically be addressed using row and column addressing. The pages that are actually displayed on the message receiving device are constructed using the data held in different parts of the database as appropriate, and in accordance with detailed formatting rules.

Hence, the invention is based upon the insight that the actual displayed pages can be constructed from different elements of 'virtual' pages held in a database stored in the receiving device. This has numerous advantages to the service provider. Preferably, the service provider provides a number of different information services or categories. Typical categories would be News, Sport, Weather, Stock Exchange and Currency Information; each category may then be served by a particular database. Each page of any given database would relate to a defined subset of information in that category; for example, within the News database, each different story would be allocated its own page. The user is able to navigate between topics or items in each category by conventional navigation techniques, for example selecting menu items. When a user requires a particular topic or item to be displayed on his message receiving device, [typically a pager], for example, the page showing the latest news, then the receiving device retrieves those elements from the relevant pan of the News database that stores the data describing the page or pages with the latest news. The receiving device then constructs a Latest News 'visual page' [i.e. on-screen page] out of the various individual stories, each of which occupies its own 'logical' page within the News database. An example will illustrate one of the advantages of this embodiment. If a lengthy news story is transmitted, it might occupy 2 entire full screens of a large A4 size message receiving device. On a smaller device, the story might occupy 5 full screens. With the present invention, the service provider merely transmits the data defining the story to the appropriate database page; the message receiving device itself automatically handles the detailed formatting involved in determining the actual displayed story length. Hence, the service provider can transmit the same data to all message receiving devices irrespective of screen size, knowing that the message receiving devices themselves will handle the necessary detailed formatting tasks.

The service provider handles the higher level tasks such as generating the actual data to be broadcast, and higher level formatting tasks, such as the order in which different items are displayed on screen, updating stories etc. The latter can be readily achieved because of the database structure the service provider transmits to; for example, the 'News' section of the services transmitted may comprise thirty different stories. Each story may, as noted above, be allotted its own 'page' within the database structure. If one line of a given story has to be amended, the old line, which is stored at a given location within the database defined by column and row references within a particular field, can be deleted by an instruction sent by the service provider, together with the new replacement line, each defined by the appropriate row and column locations. When the user navigates to the Latest News section, the receiving device then re-assembles the required Latest News page[s] by extracting the relevant pages from the News database; the user will get the most up to date news since the relevant pages have been updated by the service provider sending specific updating replacement data to the relevant field locations in the appropriate pages of the News database. In this way, the service provider can regularly up date the data held in the database of the receiving device without excessive air-time use or having to cope with re-formatting the layout of the entire Latest News section.

In another aspect, a method of displaying pages on a visual display screen of a message receiving device, comprises the steps of: the transmission of data elements, defining portions of pages, to pre¬ determined address locations in a memory of the message receiving device; the selection, by a user of the device, of a page from a selection of pages indicated as available for display on the visual display screen of the receiving device; the retrieval of data elements from the memory to form the portions of the selected page; the display on the visual display screen of the selected page incorporating the data elements in accordance with a set of pre-determined formatting rules.

In another aspect, message receiving apparatus adapted to display pages on a visual display screen, comprises: a receiver for receiving data sent from a transmitter remote from the apparatus, the data defining various data elements, defining portions of pages that pages to be displayed are constructed from; a memory to store those various elements at locations in dependence on address information in the data; a processor adapted to retrieve required data elements from the memory and to display, in accordance with a set of pre-determined formatting rules, on the visual display screen a page, selected from a selection of pages indicated as available on the visual display screen, incorporating the required data elements.

Detailed Description

This description relates to an implementation of the invention in a pager. The following sections describe the 'view' of the pager database system used for transmission and reception of data. This system allows attractive, flexible display types and provides for the data manipulation capabilities required to maintain the data storage system, both of which are controlled - to a large degree - by the service provider.

The present invention provides a means for the service provider to transmit to Database (Logical) Pages which are quite different than the actual visual pages the end user sees. This enables a fixed and consistent layout to be used which also affords various formatting shortcuts. Thus, the service provider transmits to 'database fields' rather than a visual screen - though there is a concept of row and column addressing. The software in the receiving pager is responsible for the details of formatting and handling of this data for display.

DATABASE ORGANISATION

In a preferred embodiment, the basic scheme allows 96 Databases, each of which can contain up to 9216 Pages (these values are explained later). Some of ihese database have pre-defined structure and functionality though they use database handling type features which can be used in general. Each page of a database is addressed in terms of fields via row and column references, the use of which will become clear when example database types are described later. These row/column references are contained within the messa ^■*goe data.

The first page (Page 0) of each database is used to store special information relating to that database. For example, CELL type databases (see below) contain a lookup table of database/page references for each selection square.

The last two of the 96 databases are allocated for general 'library' use. These are databases in their own right but are referenced by other databases to reduce air-time. As an example, database 94 is the Word Library, each page of which contains a word or phrase, updated by ihe service provider just as any other database. Now, rather ihan transmitting an entire word, a control code references the appropriate page (i.e. word or phrase) which is subsequently replaced for display.

* ^»

Pages (or records) are used to separate the main types of data elements within a database to enable simple, convenient referencing. For example, the General News (see later) considers each story as a separate component, each one being stored in its own page.

Entire pages can be deleted/replaced and new ones automatically created if a message to a non-existent page is specified. PAGE DISPLAY/HANDLING

Following on from the News example above, the page display task simply cycles through the existing pages formatting each story as appropriate. Using page management type instructions within messages enables the service provider to control which 'stories' should be kept/updated/removed without the need for complex re-shuffling of text type elements within a page. Further, the general formatting and extent of the data can be largely controlled by the service provider (given the format control instructions that can be embedded) rather than having to pre-decide on the maximum number of stories etc. only to realise later that more is needed.

It is possible to display different styles of data on the display - e.g. simple text and tabular on same screen. This type of capability is made possible by formatting pages with appropriate embedded references to pre-transmitted Table definitions (see below) and other display type control functions. The use of embedded references is the subject of a further patent application to which reference should be made. This level of sophistication affords a situation whereby the service provider does not have to commit itself to 'hard-coded' layouts and new databases can be added readily to the service which look attractive to the end user.

Certain display type related functions (e.g. a 'More>^* icon at the bottom of the display indicative of fuπher data on a succeeding page) will be implemented by the pager's general handling software. This type of approach should simplify the service providers' task, who^ will basically consider data in a virtual sense. In addition, the actual 'line-breaks' and final visual appearance of pages will be governed by the pager's display functions. This arrangement provides the correct balance between the service provider being able control the general format and appearance - allowing emphasis where required - without having to be concerned with the difficult details of actual display characteristics.

DATABASE USAGE/EXAMPLES

In a embodiment, the database numbers are allocated as follows:

0 Main Menu / Demonstration data I Personal Messages

2 Weather

3 Travel

4 Sport

5 General News 6 Shares 7 City News

8 TV Listings

9 Special Group

10 Exchange Rates

1 1-82 Spare

83-93 Special Group

94 Word Library

95 Table (forms) Library

CONTROL CODES AND DATABASE FORMATS There are two main aims of this section:-

i. To describe how to control the general appearance of the data that will ultimately be displayed on the pager screen using data format commands.

ii. To explain how to maintain the data within the databases. This involves the basic structure of data storage within the databases and how the different elements of a database are referenced.

Basic Message Format

Each database type message contains up to 80 bytes and is of the following formal-

Byte Offset Usage

0 Database number transmitted as an ASCII character in the range 32 to 127.

1 Page number in the range 0-95.

2 Row number in the range 0-95. 3-n Message data.

The binary value for the database is found by subtracting the ASCII bias of 32 from that transmitted, thus allowing 96 (0 - 95) databases to be addressed.

An initial page and row number are specified, though these are both restricted to the a range of 0-95. In the majority of cases, this range will probably be sufficient, thus saving on page and row control instructions. Of course, the row and page can be changed in the normal way by the use of row and page addressing control instructions.

Field Access As described earlier, each page of a database can be accessed in terms of fields. The pre¬ defined databases require (i.e. the internal software expects) certain field layouts to be adhered to. However, this fixing of format has been kept to a minimum so as to enable the service provider to control the appearance where possible.

The control of these field layouts is handled by the use of row and column instructions contained in data messages. As described later, all control instructions are pre-fixed by the carat (^Λ) character, followed by one or more characters which define the type of instruction and provide additional parameters when required.

In addition to the database and page number, a lot of data messages will require at least one of these row/column instructions. There are two families of row/column instructions characterised by the 'range' of pages they can address:-

Code Command

^A f/ column] [row} This is used to replace the contents of a field - the original data in the field (if it existed at all) are replaced by the data following this instruction. A full field reference ([column) and [row]) is supplied, each of which is a single character, transmitted as ASCII. The actual row and column values are found by subtracting 32 in the same fashion as the database number, allowing row/column ranges of 0-95.

"rjrowj This allows just the [row] to be specified, the column is assumed to be 0. This instruction is useful when simple lines of data are being used (e.g. NEWS data). If the specified row contains only one field (i.e. it is a line), then the line is replaced with the data following the instruction. If more than one column exists, then just column 0 is replaced, all other columns are unaffected.

Λ FΓ I column] [row] This instructions is the same as the (^Λf) instruction except that [column] and [row] are each supplied with two-character values using the base 96 representation. This allows row and column references in the range 0-9215. However, wherever possible the (^Λf) instruction should be used as it clearly requires fewer characters.

^AR[row] This is the two-character version of the (^Λr) instruction described above. Once again, the (^Λr) instruction would be used in favour of this base 96 equivalent.

This instruction is used to skip to next column - whether it currently exists or not. Note that this is a column skip for logical pages ONLY and does not affect the visual appearance directly.

^ΛS/ columns] Behaves as the (^Λs) instruction but allows a number of columns to be skipped to be specified - single character in the range 32- 127. There is no base 96 equivalent.

Examples

Each of the following examples assumes that the database and page number have already been supplied as the first three bytes of the message as is ALWAYS required.

^Λf ^*$Roadworks^Λf#$Latest Reports...^ΛZ

The above example replaces the existing contents of the field whose 'address' is column 2, row 4 (i.e. field[2,4]) with the string "Roadworks" and the field[3,4] with the string "Latest Reports...". The ^ΛZ instruction (explained later) is a general message terminator.

^Λf!4^Λf 4^Λr5More prices to follow^ΛZ

In this case, field[l,20] and field[2,20] are 'deleted' (i.e. replaced with nothing), line 21 (i.e. field[0,21]) is replaced with the string "More prices to follow".

Note that the data used in the replace operation is everything (including control instructions) up to the 'next' field type instruction (^Λf, ^Λr, ^ΛF, ^ΛR, ^Λs or ^ΛS) or the end of message instruction (^ΛZ). The following example demonstrates this:-

DNABwill be ^ΛbFREE^Λb today^ΛZ Firstly, in the above example, the ^Λb instructions is used to enclose a string to be displayed in bold type - i.e. it marks the start and end. The ^ΛF instructions - which has the four characters as its parameters - is a bit of handful but is considered as follows.

Firstly, individually the characters "DNAB" lead to the following values (having subtracted the usual 32 ASCII bias):-

D = 36 (dec), 24 (hex), 0100100 (bin) N 46 (dec), 2E (hex), 0101110 (bin)

A = 33 (dec), 21 (hex), 0100001 (bin)

B = 34 (dec), 22 (hex), 0100010 (bin)

Now, DN are the column reference and AB represent the row. Thus,

column = 36 + (46 * 96) = 4452 (decimal) row = 33 + (34 * 96) = 3297 (decimal)

Overall therefore, the instruction replaces the data in field(4452, 3297) with the string "will be ^ΛbFREE^Λb today". Ultimately, this will be displayed with the "FREE" in bold:-

"will be FREE today"

DATABASE (LOGICAL) PAGE FORMATS

General use of Page 0 Page 0 of every database contains 'global' data for the handling of that database. The only exception to this is database 0 which uses page 0 differently. Each page zero contains the following:-

R ow Data

0 At least one character in the range 32- 127 representing the special handling of this database. Additional characters are used to serve as parameters for the special handling. The functionality of each type of handling is described later but the following are the basic special handling types:-

32 NONE (e.g. Sports) 33 PERSONAL (Very special!)

34 CELL (e.g. Weather)

35 PAGE COMBINE (e.g. News)

36 EXCHANGE (e.g. Exchange rates)

37 COLUMN COMBINE (e.g. Shares) 126 WORD LIBRARY

127 TABLE LIBRARY

1 A single character (32-127) used to represent the current version of the data within this database. This is used in conjunction with the overnight and version checked update procedure.

2 Should contain the main and sub-headings for this database. Control instructions are used to define these - e.g.

^Λ(Exchange Rates^Λ)Latest: ^ΛL

Only the first Main header will be used though as many sub-headers as required can be included (the ^Λd is a date/time stamp i.e. will be replaced with the pager date/time).

Database 0 - Main Services Menu

Database 0 is always enabled (cannot be disabled by user). This contains the information to display in the main services page and various information required to 'go' to the actual database required. Additionally, demonstration/teaser data is stored in this database.

Pages 1 to 95 (in theory) contain data relating to each available service as follows:-

Row Data 0 RESERVED. This row should not (cannot) be used by the service provider - it will be used to store user-configured information.

1 This is a two character (base 96 representation) reference of the ICON to be displayed in the selection box.

2 Text for the service selection box. This is limited to 11 characters.

3 May contain a two character (base 96 representation) reference to the 'start' page of the database. The default page will depend on the special handling type associated with the database. For example, CELL type will display the 'map' format by default, NONE (sport) will start at page 1.

Pages 96-(whatever) contain demonstration/teaser data that will be used if this service is selected under the following circumstances:-

i. User is not subscribed to this service - i.e. not entitled. ii. User is entitled but NO data in corresponding database. iii. Factory RIC (same as (i) and (ii) really!).

Basically, there is a one-to-one correspondence with the page number and the demonstration data for that page (i.e. data is contained on page + 96).

Special Handling

The special handling reference contained in page 0 of each database is used to control the behaviour/visual appearance. There are a number of pre-defined special handling types, which although designed to cope .with the fixed services, can be used by any 'new' database. These types are described below in terms of the format for the pages and any other special requirements.

32 - NONE

The handling of a database with no special type depends on the functionality of control functions for appearance and behaviour. There will typically be a 'main menu' page containing various hypertext instructions relating to the main topics available. Other than the usual page 0 control information, no special data is assumed to exist in any page. The Sports and TV Listings will be of this type and will probably make extensive use of the Table formatting.

33 - PERSONAL

Clearly, the handling of personal messages is of special consideration on pagers. Although the arrival of these messages is via a different 'route' than normal database data, the storage and control is kept consistent with the rest the system as possible. Thus the message log exists as a 'database'. When a personal message is received, it is stored in the next available page as well as invoking the usual message display windows.

Each page is as follows:-

Row Data

0 Contains the pager date stamp. Note that this is not transmitted as pan of the message in any way.

Is the actual message data as transmitted by the service provider.

34 - CELL

This is designed to handle 'grid' type selection as used by the Weather and Travel services. Additional data is stored in page 0 to control the behaviour and selection of pages relating to each cell. Normally, the map (or whatever) is displayed with an 8 by 12 grid overlaid. A lookup table is stored in page 0, each 'slot' corresponding to each of the 96 available by selection on the grid. A number of different 'levels' of lookup table can also be used based on the selection of icons displayed at the top of the pager screen - this level selection data is also stored in page 0.

In addition, the default page specification (row 3 of corresponding database 0 page) can be used to choose whether the 'map' display or normal type of page should be the default. If this is BLANK or specifies page 0, then the map and grid will be displayed and the cell type behaviour using the lookup table is used. Alternatively, a page containing 'normal' type ^{•* *} controls (i.e. text, page links etc.) can be specified which will then be displayed as normal. A link to page 0 from any of the pages within this database will result in the map and grid being displayed.

Page 0 Layout ow Data

-2 Standard page 0 information (i.e. type, version and headers).

This contains the 'map' (i.e. graphic displayed under grid) reference - a single character in the range 32-127. The following are currently defined :-

0 UK

1 FRENCH

2 GERMAN

3 ITALIAN

4 SPANISH

This contains references (^Λi instructions) for the 'level select' icons to be displayed at the top of the screen - the first icon corresponds to the first level lookup table (see below). These icons can be selected by the user to select the basic information. The Travel database provides an example of this - e.g. Road, Rail or Air all contained on the 'same' database map display. The pages containing the information for each type will probably be held in the 'same' database though this is not absolutely necessary. Note however, that if the lookup table specifies a link to a page in another database then that page cannot link back to the map and grid display by using a page 0 reference.

- 16 Twelve rows corresponding to those on the display grid. Each row contains eight columns, creating a 'slot' for each selectable box on the grid display. Each slot can contain one or all of the following:-

i. Reference of icon to be displayed 'in' grid square, ii. Link instruction (see control instructions) of the page relating to this cell, iii. Any other text elements that are displayed 'over' the icon.

An example:-

Λ_i4Λ_gS would display icon number 20 in the corresponding display cell and 'go' to page 51 if selected by the user.

When the user selects a square from the display grid, the corresponding cell in this lookup table is used to control the page to be selected. Clearly, cells can share pages and may also be BLANK - resulting in no action.

17... There are 12 rows for each level to be supponed via the grid selection process. Selection of the 'level' icons controls which specific lookup table will be used.

35 - PAGE COMBINE

This type of handling is used by the News and City News pages. Each story is transmitted to a separate page but these are 'combined' on the pager display (separated by a rule). The display order of these stores can be controlled as described below. No extra information is required in page 0 but each page is assumed to contained the following:-

R ow Data

0 Is expected to 'contain' a date/time stamp instruction (^Λd). Note that this instruction is automatically replaced with the internal pager date/time. The stories are displayed, latest time first so this can be used by the service provider to control the order in which they appear.

This row can be written to at any time of course, enabling 'old' stores to become important again if required just by transmitting a (^Λd) instruction.

One or more rows containing the news story. The service provider can use the row mechanism to 'edit' sections of a story if required. All existing rows from this point in the page will be considered to be pan of the story.

36 - EXCHANGE

This is used for the Exchange Rates service though may be of general use in conversion type databases. Row Data

0 Used as the table header.

1... Each row contains two columns containing the 'currency' name and exchange factor - assumed to be compared against a factor of 1 (pound in this case).

37 - COLUMN COMBINE

This type of handling is used by the Shares database which combines the data from different logical pages into one visual display similar to page combine. However, in this case, each page of data is considered to consist of a number of columns which will be combined to a tabular display. In addition, this differs from the normal page combine in that no date is required for each page (^Λd) as each page corresponds to the display order (i.e. page 1 will be display row 1 ).

Two table definitions (pre-defined though they can be changed) are used to control the tabulation of the column headings and main data. These table styles do not have to contain the same number of columns as there are fields in each page of data - for the Shares data there are normally eight in each logical page but only three columns for the visual table.

Thus the number of displayed columns is limited by the table definitions. However, the user may select a row from the 'browse' page which will then be 'expanded' to show all of the columns (within logical page) in a pop-up window - yet another table definition is pre-stored to control this display.

Page 0 Layout

R ow Data

0-2 Standard page 0 information (i.e. type, version and headers).

3 Assumed to contain the headers conesponding to each display column.

These should be separated into different logical columns within this row - a typical transmitted message extract might be:-

& #Stock^ΛsPrice^ΛsChange^ΛOther Pages 1 - n

Row Data

0 Each page contains a number of columns that will be used within the main body of the tabular display. A typical transmission to a page would be:-

&! Amstrad^Λsl32.5^Λs+0.5^Λs250.0^Λsl26.0^Λs41.4

The above messages creates/updates row 0 of page 1 with six fields of data.

Claims

1. A method of transmitting data, to enable pages to be displayed on a visual display screen of a message receiving device, comprising the steps of: transmitting data elements, each defining a portion of a page or pages to be displayed, to pre-determined address locations in a memory of the message receiving device; wherein the message receiving device is operable to construct a page or pages to be displayed out of some of one or more such data elements in accordance with a set of pre-determined page formatting rules.

2. A method of displaying pages on a visual display screen of a message receiving device, comprising the steps of: the transmission of data elements, defining portions of pages, to pre¬ determined address locations in a memory of the message receiving device; the selection, by a user of the device, of a page from a selection of pages indicated as available for display on the visual display screen of the receiving device; the retrieval of data elements from the memory to form the portions of the selected page; the display on the visual display screen of the selected page incorporating the data elements in accordance with a set of pre-determined formatting rules.

3. A message receiving apparatus adapted to display pages on a visual display screen, comprising: a receiver for receiving data sent from a transmitter remote from the apparatus, the data defining various data elements, defining poπions of pages that pages to be displayed are constructed from; a memory to store those various elements at locations in dependence on address information in the data; a processor adapted to retrieve required data elements from the memory and to display, in accordance with a set of pre-determined formatting rules, on the visual display screen a page, selected from a selection of pages indicated as available on the visual display screen, incorporating the required data elements.