Organising data in optically readable data elements
The present invention relates to the organisation of data in data elements, which are suitable for subsequent transfer of information to terminals by means of optically readable codes. The invention relates more particularly to a method for organising data that have to be stored in one of one or more optically readable data elements for transferring a data set from a physical medium to a terminal.
The invention is particularly applicable for organising data that have to be stored in data elements for reading by a terminal in the form of a mobile telephone or other small mobile personal terminal equipped with an optical reader, which can read optical codes such as bar codes and matrix codes.
At present, the transfer of information to mobile terminals is often relatively complicated. It often has to be performed manually by the user entering information by means of a keyboard or by means of a special pen and a touch- sensitive display. At other times the information can be downloaded by means of the terminal's facilities for communication with a telecommunications or data network, as is often the case if the terminal is a mobile telephone, while at other times the terminal is connected to a computer containing software specially designed to administer or program the terminal. Examples of the latter may involve entering or updating of information in an address book stored in the terminal.
The various kinds of information transfer indicated above are encumbered by a number of disadvantages. This is due partly to the fact that they are heterogeneous, with different types of transfer being used for different types of information, partly that they are impractical, involving, for example, the use of small impractical keyboards or connection to a computer, and partly that they involve slow data transfer by means of dial-up connections, which also entail costs for the user.
The basis of the present invention is to provide an alternative method for organising data for storing in one or more optically readable data elements, which are suitable for transferring a data set from a physical medium to a terminal. This is achieved by means of that which is stated in the independent claim 1. The dependent claims indicate further features and advantageous embodiments.
It is previously known to equip mobile terminals such as, for example, mobile telephones with optical readers that can read bar codes. US-A-5 923 735, for example, discloses a system for data transfer between a number of mobile communication terminals and a central unit, where each of the mobile terminals may be a mobile telephone equipped with an optical bar code scanner. In this known solution, however, the bar code scanner is associated with a single function, such as input of bar code data associated with identification of a selected item.
US-5 774 583 discloses a previously known solution for reading and reproducing multimedia information contained in optically readable codes.
In US-5 481 103 there is disclosed a previously known solution for reading data sets divided into several optical data elements.
According to solutions provided by the invention it becomes possible to transfer a great many different kinds of data to such a terminal. Examples of applications that can be implemented by means of the invention are transfer of software or data to the terminal, such as, for example, games, pictures, ringing tones; transfer of warning times for setting an alarm associated with the beginning of a television program or other event; contact information for input in an address book in the terminal; ordering data containing information such as product number, price, address etc., thus enabling the terminal to be utilised for transferring an order; payment information, thus enabling the terminal to be utilised for transferring a payment order; text information, which, for example, supplements information in an advertisement and which can be read by means of the terminal; reference information referring to documents, which can be accessed in other places, such as on the Internet.
Information of the types mentioned above can then be envisaged encoded in the form of an optically readable code, such as a matrix code, and will be able to be printed in advertisements or publications, applied directly to products or presented in connection with program listings for television programs, printed on notepaper or visiting cards, etc.
The invention is based on the fact that the information, which has to be transferred to the terminal, is organised in a manner that permits this kind of flexibility. This information will be referred to as utility data and the total quantity of data representing such a set of information will be referred to as a data set.
First of all, the information concerned, the utility data, which has to be transferred to the terminal, is compressed according to a selected compression algorithm. On the basis of the data set after compression and the storage capacity of each individual data element of the type of optically readable code selected, a minimum number of data elements, which have to be generated, is calculated, taking account of the fact that the data elements also have to contain additional information concerning format as described below.
When it has been decided how many data elements have to be generated, where this number may well be greater than the estimated minimum, data are generated describing the content of the individual data element. This information will hereinafter be called header information. The header information must at least indicate data type for the utility data, and if more than one data element has to be generated, the total number of data elements must be stated and which number each individual data element has in the sequence.
To be able to utilise the method according to the invention universally, it is necessary to generate a global unique identifier for the data set stored in the sequence of data elements concerned. This is to prevent data from two data elements being interpreted as belonging to the same data set even though they actually come from two different data sets.
According to a preferred embodiment of the invention it is possible to include in the header information a reference to further information, which is available, for example, via a data network. This reference may, for example, be in the form of a so-called Uniform Resource Locator (URL). If the reference is in the form of an address locator for the Internet, such as a URL, and if the terminal is provided with known per se software for data communication, the method according to the invention will permit the terminal to be used for retrieving information from the Internet directly to the terminal. It is also possible to arrange for the information to be forwarded from the terminal to an additional communication terminal.
After the relevant header information has been generated, header information and data for each data element are combined and the individual data elements are generated. This can be implemented by the elements being printed, or they can be stored in the form of an image file, for example as a bitmap image (bmp file).
When data elements, which have been generated according to the invention, have to be read and the data have to be employed in a terminal, this is done by scanning in the information for each individual data element by means of an optical reader, which is preferably a part of the terminal, but which may also be connected thereto via a communication interface. On the basis of the header information, the utility data are retrieved from each individual element, and arranged sequentially and decompressed. The data can then be used according to the data type indicated in the header information.
The invention will now be described in greater detail in the form of an embodiment, with reference to the attached drawings.
Fig. 1 is a principle view illustrating possible applications of the invention.
Fig. 2 illustrates an example of data format according to the invention.
Fig. 3 illustrates an example of how utility data are distributed over several data elements and how this is represented in the data elements' headers. Fig. 4 illustrates generation of the optical readable elements.
Fig. 5 illustrates the functional construction of a mobile terminal.
The present invention permits the distribution of information for transfer to mobile terminals such as, for example, mobile telephones. The invention realises a highly efficient utilisation of a combination of specially adapted software, optical readable codes (e.g. matrix codes), scanner technology and cordless telecommunication.
Figure 1 is a principle view illustrating the use of the invention. The information concerned is distributed in the form of an optically readable code 10, for example a matrix code. This matrix code may be provided on a product, in a newspaper or a periodical, on a visiting card or notepaper, or on any other physical object. By means of a portable terminal 11 equipped with an optical reader or scanner, the relevant matrix code 10 is read. By means of software in the mobile terminal, the input data are interpreted, and employed according to the header information as described in greater detail below. The input data may be of a great many types and for a great many applications. In the simplest cases they will be intended for use directly in the mobile terminal. If the mobile terminal is a mobile telephone, for example, the data will be able to indicate an address, which is to be entered in an address book,
it may be an image, which is to be shown in the telephone's display 12, or it may be a ringing tone or melody, which is to be played, for example, as a warning of incoming calls. The data may also be software, which can be run on the mobile terminal, for example in the form of a game or the like. However, the invention also permits the retrieved data to refer to additional information found, for example, on a computer 13, which is available via a data network 14, such as the Internet. This may be relevant, for example, if it is desirable to transfer more data than can easily be entered in a few data elements such as matrix codes 10, or if it is desirable to update the factual information frequently without having to distribute new information carriers with matrix codes 10. Examples of the former may be comprehensive presentation documents, and examples of the latter may be the indication of the address of an information service supplying sports results or share prices, or a reference to additional information for a marketing campaign, for example describing an offer, which is only valid for a short period.
If the additional information, which has to be retrieved via the data network 14 is extremely voluminous, the mobile terminal may not suitable for displaying it. In this case it is possible to establish an additional connection to a computer 15, which may be a personal computer (PC). The communication between mobile terminal 11 and personal computer can then be implemented by means of a data connection such as a data cable, infrared link or Bluetooth, while the communication with the Internet is handled by the terminal's communication facilities, for example with the mobile telephone network and by means of suitable communication protocols such as WAP. The optical readable code 10 will preferably be a matrix code and for the sake of simplicity will be referred to as such hereinafter, even though it should be understood that this is an embodiment, and that any other optically readable codes with a different design but with sufficient storage capacity may also be employed. A matrix code is a variant of traditional bar codes, the difference being that the information is encoded in the form of points in a matrix, and that bar codes traditionally only represent numbers, while matrix codes may be formatted to contain text or binary data in addition to numerical data. In addition, a matrix code has far greater capacity than traditional bar codes. A number of standards
exist for matrix codes, with varying capacity, but those with the highest capacity today can contain around 2000 characters.
In order to implement different areas of application permitted by the invention, as already described, it is necessary to have a standardised formatting of data before they are transformed into matrix code. Figure 2 gives an example of how this format may be. Not all the fields indicated in this format are strictly necessary for implementing the invention, and it will also be possible within the scope of the invention to add extra fields.
The data format 20 is divided into two main parts, a header 21 and a data field 22. The header 21 consists of a number of fields 23, ... 27, which are necessary in order to describe the content. All the fields in the figure apart from the data field 22 form part of the header 21. The various fields and their function will now be described.
The first field is a global unique indicator or GUID 23. This is a unique identifier associated with a data set. In this case data set refers to a type of data, e.g. an image, a ringing tone, a text document or the like, which is complete in the sense that it constitutes a set of utility data that has to be stored on one or more data elements 10. A data set can therefore be distributed over several data elements 10, but all the data elements containing data from the same data set will have the same GUID 23. Moreover, it is important that two identical identifiers are not generated, thus avoiding the possibility of two data sets from two different sources being interpreted as the same data set and attempts made to combine them into one data set. An example of this would be where a first ringing tone is encoded to two data elements and a second ringing tone is encoded to two data elements. If a user tries to read the first data element containing the first ringing tone and the second data element containing the second ringing tone, and the same GUID is used for both data sets, attempts will be made to combine them in the mobile terminal.
In order to prevent this, use may be made, for example, of an algorithm with a corresponding function to that employed by Microsoft for generating interface ID in its Component Object Model (COM).
The next field indicated in the figure is sequence 24. This field is used for separating the respective data elements within the same data set as well as for defining the sequence between them, thus enabling the data to be combined
correctly in the mobile terminal 11. In principle, therefore, this is only a numbering of the data elements in a sequence of data elements.
Sequence number 25 indicates how many data elements exist in the data set to which the data element concerned belongs. By means of this field it will be possible to establish in the mobile terminal 11 when all the data elements in a data set have been input and retrieving and combining the utility data can be implemented.
Data type 26 is a field indicating which type of data exists in the data field 22. Each relevant data type is assigned its own identifier so that the mobile terminal 11 knows how the data should be processed after they are combined and decompressed and possibly which application or resource should receive the data.
01 Ringing tone
02 Image (jpg)
03 Image (bmp)
04 Warning
05 Visiting card
06 Software (e.g. game)
07 Text etc.
The table gives examples of possible identifiers for different data types.
Each data set may be associated with a link 27 referring to additional information or data. This will preferably be in the form of a so-called URL, indicating where the data concerned can be found on the Internet. Other kinds of reference may, of course, also be envisaged, such as, for example, in the form of an address with reference to a relevant protocol, for example an IP address, but it is important to be aware that an IP address in itself does not refer to specific data and that in this case there must be a predetermined set of data, which is always transmitted in response to inquiries to the IP address concerned.
This use of a reference to additional information can be practical for large data sets or for data types that are not suitable for mobile terminals. A large word processing document may be envisaged, for example, which will be unsuitable for reading in today's mobile terminals. If instead a matrix code according to the invention is generated, containing a reference to this word processing document, the document can be downloaded by means of the mobile terminal and transferred to a personal computer or another type of terminal, which is more suited to this type of data. According to the invention the mobile terminal will then comprise communication ports and communication software that is suitable for handling this.
We refer now to figure 3, which illustrates how utility data 30, here in the form of a digital image of bitmap format (bmp), are distributed over a total of five data elements 31. The header 32 of the respective data element contains a unique GUID, which is the same for each data element, a sequence number indicating in which sequence the various data elements have to be arranged, the total number of data elements in the sequence, viz. five, together with data type 03 indicating that the data are a bmp file. In this case there is no reference to other information and the link field is therefore empty.
We refer now to figure 4, which illustrates how the optically readable data elements are generated according to the invention. The actual method will preferably be performed by means of software run on a computer 41 with equipment necessary for retrieval of the data concerned and production of the optically readable data elements.
The utility data concerned are fed into the computer 41 and compressed according to a selected compression algorithm. It will be advantageous if this algorithm is standard for all use of the invention, or otherwise it will be necessary to design the mobile terminals so that they are capable of handling a plurality of such algorithms, and which algorithm is employed must be indicated in a separate field in the header 21. After compression of the data a calculation is made, based on the capacity of the optical code with a deduction for the extent of the header, of how many data elements have to be generated. In a preferred embodiment of the invention the possibility is also offered of specifying how many data elements have to be generated as long as this is equal to or greater than the minimum number.
GUID 23 is then generated by means of a suitable algorithm, as already described. Sequence 24 and number in sequence 25 are determined based on the results of the calculation of the number of data elements. The number of data elements may be indicated as one of several parameters together with other data, for example, such as an indication of data type, if this is not detected automatically by the software performing the method, and indication of any reference to further information.
On the basis of the above, header 21 and compressed data 22 are combined and the optically readable code, preferably a matrix code, is generated. This can then be printed out directly or stored on an image file 44, for example in bitmap format (bmp).
We now refer to figure 5, which illustrates the construction of a mobile terminal according to the present invention. In the embodiment in the figure the mobile terminal is represented as a mobile telephone with integrated CCD scanner, but it may also be another type of mobile unit, such as a PDA. The main components in this terminal will be the scanner, which will preferably be an integrated part of the terminal's software 52, but which in principle may also be connected to the terminal via a communication link, the terminal's operative system 53, which has to be able to receive and interpret the data stream from the scanner 51, and an application 54, which can handle the data.
The scanner 51 is designed to be capable of reading one or more types of high- capacity optically readable codes, preferably matrix codes. The operative system 53 can receive the data stream from the scanner 51 and decompress and decode the data according to a data format standard. It will be possible to incorporate the basic functions with regard to reading headers, combining data sets and decompressing utility data in the operative system, but alternatively the received data can be forwarded to the application 54 as they are received. In the latter case all the functionality with regard to processing of the input data based on information in headers 21 will lie in the application 54. The task of the application 54 is to handle the different data elements and data types. Amongst other things, it may keep track of which data elements have been received in each data set and give the user an overview of this based on the information in GUID 23, sequence 24 and number in sequence 25. A user will thereby be able to obtain an overview of which data sets have been input
and which data elements have been input or are lacking for each individual data set.
In addition there is support in the application 54 for completing the processing of combined data sets. In this connection data sets can be divided into two types, viz. those which can be employed in the mobile terminal and those which can only be employed in other types of terminal.
In the first category there will be data types such as, e.g., ringing tones, logos, automatic warning, visiting cards, etc. For these data types the application 54 has to support transfer to the remaining applications in the mobile terminal, thus enabling them to make use of the data.
For the second category the data have to be transferred to other units, such as, for example, personal computers 15. The application is therefore capable of communicating with other communication software 56 in the mobile terminal to enable it to transfer these data to these other units via the mobile terminal's communication ports.
The application 54 is furthermore preferably designed to be able to communicate with software controlling communication with the Internet 14 or another data network. This is to enable it to retrieve information referred to in the header's 21 link field 27. In addition the application 54 is so designed that it is capable of forwarding this information if the downloaded data are not intended for use in the mobile terminal 11, but in another terminal, for example a personal computer 15.