WO2007072384A2

WO2007072384A2 - Device for and method of retrieval of a data file

Info

Publication number: WO2007072384A2
Application number: PCT/IB2006/054896
Authority: WO
Inventors: Werner Lane
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-12-22
Filing date: 2006-12-15
Publication date: 2007-06-28
Also published as: TW200805277A; KR20080078074A; EP1966798A2; JP2009521069A; CN101346769A; WO2007072384A3

Abstract

A reading device for reading data from a removable record carrier (11). The device comprises reading means (21, 22, 25) for reading the data recorded on the record carrier and control means (20) for controlling the reading. Further, the device comprises file retrieval means (31). The retrieval of data is independent from the file system under which the data were recorded; it is independent from the file system data on the record carrier. Moreover, for the retrieval, the record carrier does not have to be mounted under control of any file system.

Description

Device for and method of retrieval of a data file

The invention relates to a reading device for reading data from a removable record carrier, which device comprises reading means for reading the data stored on the record carrier and control means for controlling the reading.

The invention further relates to methods of formatting data for storing on a removable record carrier and retrieving the data from the record carrier.

The invention also relates to computer program products for use in formatting data for storing on a removable record carrier and retrieving the data from the record carrier.

A removable record carrier, such as an optical disc like CD, DVD or Blu-Ray, can be used for distributing special data related to a reading device. Common examples of such data are update data for upgrading a firmware controlling operations of the device.

A method of storing and reading update data is disclosed in the international publication WO 03/019562. The use of so-called sub-code data channels is proposed for this purpose. The sub-code data channels are known from the Compact Disc Digital Audio system, CD-DA. They are contained in the so-called main channel in the time-multiplex mode in the audio data stream. The data from the sub-code data channels enable a CD player to playback additional information, such as, for example, the elapsing time during playback of a track stored on a CD or the name of a track and/or the associated interpreters. In addition to this functionality of the sub-code channels, the document WO 03/019562 teaches to encode update data in one of the sub-code data channels. This provides a content independent method of distributing update data. Obviously, the method can be employed only in systems with sub-code data channels. Moreover, it requires special, modified devices for recording update data. Additionally, the capacity of the sub-code data channels is only a small fraction of the total capacity of the CD disc, thus limiting the amount of data that can be transferred in this way.

The published application EP 1049089 provides a different method of distributing update data to a device. A new data structure on a record carrier, so-called disk control block is proposed. It is used for administration and control information for the record carrier. One medium may contain multiple different disk control blocks, each addressing a different function. One example includes a disk control block for updating firmware. It is stored in lead-in and/or lead-out areas of an optical disc, that is, in the areas not accessible for storage of data by a user. Moreover, this solution in fact implements a new standard of storing data on a record carrier; for example, update data have to be recorded in a specific manner at specific locations. This makes the transferring of update data a complex process.

It is an object of the present invention to provide a simple and flexible way of transferring via a record carrier any special data related to a reading device, in particular firmware update data. For this purpose, according to a first aspect of the invention, in the reading device as described in the opening paragraph, the control means comprise file retrieval means for retrieving a data file by:

- controlling the reading means to read consecutive data blocks recorded at addressable locations in a user area on the record carrier; - for each data block, checking the data block for presence of at least one data file packet by localizing within the data block at least one predefined synchronization pattern corresponding to the at least one data file packet;

- in case of presence of the at least one data file packet, checking a data file packet sequence number and a total data file packet sequence number comprised in the at least one data file packet, the data file packet sequence number identifying a part of the data file comprised in the at least one data file packet, the total data file packet sequence number representing a number of data file packets comprising parts of the data file;

- storing in a memory the part of the data file; and

- completing retrieval of the data file upon storing in the memory the parts of the data file comprised in the data file packets of the data blocks.

For this purpose, according to a second aspect of the invention, the method of retrieving data, as described in the opening paragraph, provides retrieval of a data file stored in a user area on a record carrier, the method comprising steps of: a) reading a data block out of consecutive data blocks stored at addressable locations in the user area; b) checking the data block for presence of at least one data file packet by localizing within the data block at least one predefined synchronization pattern corresponding to the at least one data file packet; c) in case of presence of the at least one data file packet, checking a data file packet sequence number and a total data file packet sequence number comprised in the at least one data file packet, the data file packet sequence number identifying a part of the data file comprised in the at least one data file packet, the total data file packet sequence number representing a number of data file packets comprising parts of the data file; d) storing in a memory the part of the data file; e) repeating steps from a) to d) for a further data block; and f) completing retrieval of the data file upon storing in the memory the parts of the data file comprised in the data file packets within the data blocks. For this purpose, according to a third aspect of the invention, the method of formatting data, as described in the opening paragraph, provides formatting for storing the data in a user area on a record carrier, the method comprising steps of: a) dividing the data file into data file parts; b) assigning a file sequence number to a data file part out of the data file parts; c) assembling the data file part, the file sequence number and a total sequence number into a data file packet, the total sequence number representing a number of the data file parts; d) providing the data file packet with a predefined synchronization pattern; e) repeating steps from b) to d) for each data file part out of the data file parts; and f) assembling data file packets representing the data file into a storage file for storing in the user area.

For this purpose, according to a fourth aspect of the invention, a computer program product for use in retrieving data, as described in the opening paragraph, is provided, the computer program comprising program code means for causing a processor of a reading device, to perform the method as described in relation to the second aspect of the invention.

For this purpose, according to a fifth aspect of the invention, a computer program product for use in formatting data, as described in the opening paragraph, is provided, the computer program comprising program code means for causing a processor to perform the method as described in relation to the third aspect of the invention. The measures according to the invention have the effect that the reading device can retrieve data without knowledge about their exact positions in the user area, as defined for example by the used file system.

The invention is also based on the following recognition. Software upgrades, or other special data, for disc based products, such as a DVD player, can be distributed efficiently and timely by downloading, for example, updated firmware by end user, burning it onto an empty recordable disc and inserting into the end product to perform the firmware update. Recordable optical media are well known to a man skilled in the art of optical recording of digital data, for example from numerous books, such as "Optical recording: a technical overview " by Alan B. Marchant, ISBN 0-201 -76247- 1.

In many cases, due to limited resources available to the firmware that is responsible for the firmware update or retrieval of the special data, only a particular file system, for example ISO9660 Level 1, on the upgrade disc is used. End users are often unaware that there exist different file systems and often burn discs in such a way that it is incompatible with the firmware upgrade.

Typically, data on a record carrier are organized into files in accordance with rules of a particular file system. Such file system has its own file system data, which include information about all kind of structures relating to user data stored on a record carrier. In particular, file system data may include volume structures representing the structures of logical and/or physical volumes, file entries representing the structures of files containing the data, directory entries describing grouping of files, and a space bitmap representing allocated or unallocated space for storing data on a record carrier. A record carrier may comprise addressable recording units for storing the data. At a level of a file system those units are referenced to with use of logical addresses defining usually a contiguous addressing storage space, a user area, to be used for storing sequences of information blocks, for example files and related file system data such as file/directory entries under control, according to rules, of the file system, for example UDF. File entries comprise information about positioning of file data on a record carrier, for example addresses of recording units comprising relevant information blocks. File system data of different file systems may be incompatible. In particular, this may concern file entries themselves and/or file system structure information related to them. As a consequence, often data recorded according to rules of one file system cannot be retrieved under control of another file system.

The solution of the invention provides for the file system independent transfer of data, such as upgrade data, to the reading device. The retrieval of data is independent from the file system under which the data were recorded; it is independent from the file system data on a record carrier. Moreover, for the retrieval, the record carrier does not have to be mounted under control of any file system.

In an embodiment of the device, the file retrieval means are for retrieving the data file from the data packets each having a size quantized in multiplies of 512 bytes. This allows for efficient application of the invention to modern disk-based file systems, for which the smallest addressable amount of data on a disk is 512 bytes or a multiple thereof. For example, blocks of 512 bytes are often used in hard disks and memory cards, CD and DVD use blocks of 2048 bytes, and Blu-Ray Disc uses blocks of 4096 bytes. It is advantageous, if the file retrieval means are for retrieving the part of the data file from the at least one data packet comprising a header, the header comprising the at least one predefined synchronization pattern, the data file packet sequence number and the total data file packet sequence number. This improves organization of data within data file packets and simplifies the retrieval. In a further embodiment of the device, the file retrieval means are for retrieving the data file in dependence on checksum data comprised in the at least one data file packet, the checksum data comprising at least one of the following: parity data; cyclic redundancy check data; - cryptographic data, in particular a hash function data.

This provides protection against errors and allows for controlled access to the data.

Advantageously, the file retrieval means are for storing in the memory a copy of the part of the data file in case of read errors within the at least one data file packet, the copy comprised in a different data file packet. This further improves protection against errors.

In an embodiment of the device, the file retrieval means are for retrieving the data file based on file identification data identifying the data file, the file identification data comprised in the at least one data file packet, the data file packets comprising parts of plurality of data files. This facilitates retrieval of many data files. In another embodiment of the device, the control means comprise firmware update means for upgrading a software for controlling operations of the device with upgrade data comprised in the data file. This provides for the file system independent upgrade of the device.

Further preferred embodiments of the device and methods according to the invention are given in the appended claims, disclosure of which is incorporated herein by reference. These and other aspects of the invention will be apparent from and elucidated further with reference to the embodiments described by way of example in the following description and with reference to the accompanying drawings, in which:

Figure 1 shows a removable record carrier, Figure 2 shows a reading device, in accordance with the invention,

Figure 3 shows an example of construction of data file packets, in accordance with the invention,

Figure 4 shows another example of construction of data file packets, in accordance with the invention, Figure 5 shows an example of a method of retrieval of a data file, in accordance with the invention,

Figures 6 and 7 show computer pseudo-codes describing other examples of a method of retrieval of a data file, in accordance with the invention,

Figure 8 shows an example of a method of formatting a data file for storing, in accordance with the invention.

Corresponding elements in different Figures have identical reference numerals.

Figure 1 shows an example of a record carrier 11 having a form of disc with a track 9 and a central hole 10. The track 9, being the position of the series of (to be) recorded marks representing information (data), is arranged in accordance with a spiral pattern of turns constituting substantially parallel tracks on an information layer. The record carrier may be optically readable, called an optical disc. Examples of a recordable disc are the CD-RW, and writable versions of DVD, such as DVD+RW, and the high density writable optical disc using blue lasers, called Blu-ray Disc, BD (a description is available at http://www.blu- raydisc.com). The information is represented on the information layer by recording optically detectable marks along the track, for example crystalline or amorphous marks in phase change material. The track 9 on the recordable type of record carrier is indicated by a pre- embossed track structure provided during manufacture of the blank record carrier. The track structure is constituted, for example, by a pregroove 14, which enables a read/write head to follow the track during scanning. The track structure comprises position information, for example addresses, for indication the location of units of information, usually called information blocks or data blocks. Information blocks can be grouped into larger units. For example, in the DVD system, 16 information blocks each of 2 Kbytes of data are grouped into so-called ECC blocks of 32 Kbytes, for the purpose of error correction.

Further examples of a removable record carrier are solid-state memory cards such as PC Card, CompactFlash, SmartMedia, Miniature Card, SD/MMC or Memory Stick. Figure 2 shows an example of a reading device for reading information from a record carrier 11 such as CD-RW, DVD+RW or BD, in accordance with the invention. The device is provided with reading means for scanning the track on the record carrier, which means include a drive unit 21 for rotating the record carrier 11, a head 22, and a positioning unit 25 for coarsely positioning the head 22 in the radial direction on the track. The head 22 comprises an optical system of a known type for generating a radiation beam 24 guided through optical elements focused to a radiation spot 23 on a track of the information layer of the record carrier. The radiation beam 24 is generated by a radiation source, e.g. a laser diode. The head further comprises (not shown) a focusing actuator for moving the focus of the radiation beam 24 along the optical axis of said beam and a tracking actuator for fine positioning of the spot 23 in a radial direction on the center of the track. The tracking actuator may comprise coils for radially moving an optical element or may alternatively be arranged for changing the angle of a reflecting element. For reading, the radiation reflected by the information layer is detected by a detector of a usual type, e.g. a four-quadrant diode, in the head 22 for generating a read signal and further detector signals including a tracking error and a focusing error signal for controlling said tracking and focusing actuators. The read signal is processed by read processing unit 30 of a usual type including a demodulator, de formatter and output unit to retrieve information (data). Hence reading means for reading information include the drive unit 21, the head 22, the positioning unit 25 and the read processing unit 30. The operation of these units is controlled by a control unit 20. The information can be represented by optically detectable marks in the recording layer. The marks may be in any optically readable form, e.g. in the form of areas with a reflection coefficient different from their surroundings, obtained when recording in materials such as dye, alloy or phase change material, or in the form of areas with a direction of magnetization different from their surroundings, obtained when recording in magneto-optical material. Alternatively, the information can be retrieved from solid-state memory cards such as PC Card, CompactFlash, SmartMedia, Miniature Card, SD/MMC or Memory Stick. In this case, the reading device comprises a card interface (not shown) for transferring data from/to the memory card. The card interface can be additional unit or it can be comprised in the reading device instead of the head 22, the drive unit 21 and the positioning unit 25. The control unit 20, which controls reading of information, may be arranged for receiving commands from a user or from a host computer. The control unit 20 is connected via control lines 26, for example a system bus, to the read processing unit 30, to the drive unit 21, and to the positioning unit 25. The control unit 20 comprises control circuitry, for example a microprocessor, a program memory and control gates, for performing the procedures and functions according to the invention as described below. The control unit 20 may also be implemented as a state machine in logic circuits.

The device may be arranged for writing information on a record carrier 11 of a type, which is writable or rewritable, for example DVD+RW or BD-RE. The device then comprises a write unit 29 for processing input information to generate a write signal to drive the head 22. During the writing operation, marks representing the information are formed on the record carrier. The marks are formed by means of the spot 23 generated on the recording layer via the beam 24 of electromagnetic radiation, usually from a laser diode. The writing operation is controlled by the control unit 20 connected to the write unit 29. Writing and reading of information on/from optical disks and formatting, error correcting and channel coding rules are well-known in the art, e.g. from the CD and DVD systems.

The control unit 20 is arranged for controlling reading of information by locating each block at a physical address in the track. Physical addresses are translated into logical addresses and vice versa. The logical addresses constitute a contiguous data storage space to be used for storing sequences of information blocks, such as files under control of a file management system, for example UDF. In other words, the logical addresses used by the file management system are mapped by the control unit 20 onto corresponding physical addresses of locations on the record carrier. Such file system has its own file system data, which include information about all kind of structures relating to user data stored on a recording medium. In particular, file system data may include volume structures representing the structures of logical and/or physical volumes, file entries representing the structures of files containing the user data, directory entries describing grouping of files, and a space bitmap representing allocated or unallocated space for storing data on a record carrier.

For accessing data on a record carrier under control of a file management system, the record carrier is so-termed mounted under the file management system.

In an embodiment the device is a storage system only, for example an optical disc drive for use in a computer. The control unit 20 is arranged to communicate with a processing unit in the host computer via a standardized interface (not shown). Digital data is interfaced to the write unit 29 and from the read processing unit 30, directly. In this case, the interface acts as an input unit and an output unit.

In an embodiment the device is arranged as a stand alone unit, for example a video playback/recording device for consumer use. The control unit 20, or an additional host control unit included in the device, is arranged to be controlled directly by the user. The device includes application data processing, for example audio and/or video processing circuits. The information presented to the write unit 29 may comprise analog audio and/or video, or digital uncompressed audio/video signals; in this case the write unit 29 may comprise compression means for these signals. The read processing unit 30 may comprise suitable audio and/or video decoding units.

The control unit 20 includes file retrieval unit 31 for file system independent retrieving a data file from data comprised in information blocks recorded on the record carrier. The control unit 20 controls the file retrieval unit 31 to retrieve the data file without mounting the record carrier under control of a file system management. The file retrieval unit 31 controls the reading means to read consecutive data blocks recorded at addressable locations in the user area on the record carrier, starting with the first block in the user area. The physical address of the first block depends on the type of the record carrier. In case of the DVD system the first block physical address is 030000h, whereas it is OOlOOOOOh for the Blu-Ray system. For each data block read from the record carrier, the file retrieval unit 31 checks the data block for presence of at least one data file packet by localizing within the data block at least one predefined synchronization pattern corresponding to said data file packet. Once the synchronization pattern is found, the file retrieval unit 31 checks a data file packet sequence number and a total data file packet sequence number comprised in the data file packet. The total data file packet sequence number represents a number of data file packets comprising parts of the data file. Each data file packet comprises a part of the data file, hereinafter called also a chunk, which part is uniquely identified by corresponding data file packet sequence number. The total data file packet sequence number is used to allocate memory required for storing the data file in a memory unit 32.

The memory unit 32 can be comprised within the file retrieval unit 31 itself, or it can be comprised within the control unit 20, or it can be (a part of) a separate memory unit.

For each data file packet found in data blocks, the file retrieval unit 31 stores corresponding part of the data file in the memory unit 32. The retrieval of the data file is completed upon storing in the memory unit 32 all parts of the data file indicated by the total data file packet sequence number. Thus, instead of checking for a particular file system, the file retrieval unit 31 simply reads sequentially data blocks from the record carrier, starting at the beginning of the user area, for example right after the lead-in area on an optical disc.

Examples of a structure of data file packets, processed by the file retrieval unit 31 of particular embodiments of the reading device, are described with reference to Figure 3 and Figure 4.

In an embodiment of the reading device, the file retrieval unit 31 checks the total data file packet sequence number only in this data file packet, which was found first.

For modern data storage systems the smallest addressable amount of data on a record carrier is 512 bytes or a multiple thereof. In an embodiment of the reading device, the file retrieval unit 31 is adapted to retrieve the data file from the data packets each having a size quantized in multiplies of 512 bytes. This means that each data block comprises integer number of data file packets.

In an embodiment of the reading device, the control unit 20 includes a firmware update unit 33 for upgrading a software for controlling operations of the device with upgrade data comprised in the data file stored in the memory unit 32.

In an embodiment of the reading device, the control unit 20 includes a booting unit 34 for booting, starting up, the reading device using operating system data or application data comprised in the data file. The file retrieval unit 31, the firmware update unit 33 and the booting unit 34 can be implemented in firmware, for example as one unit.

In an embodiment of the reading device, the file retrieval unit 31 is adapted to retrieve the data file from data packets each comprising a header with a synchronization pattern, a corresponding data file packet sequence number and the total data file packet sequence number.

Advantageously, the file retrieval unit 31 can be adapted for retrieving plurality of data files, wherein each data file is identified by file identification data, which file identification data is comprised in each data file packet. The file retrieval unit 31 allocates separate memory parts of the memory unit 32 for different data files and retrieves parts of those data files in dependence of file identification data; each data file is identified by a unique file name.

An example of a structure of data file packets comprising a header with file identification data is described with reference to Figure 3. In an embodiment of the reading device, the file retrieval unit 31 is for retrieving the data file in dependence on checksum data comprised in data file packets, as described with reference to Figure 4.

A further embodiment of the reading device comprises the file retrieval unit 31 adapted for storing in the memory unit 32 a copy of the part of the data file comprised in a different data file packet within the data blocks, in case of read errors within the data file packet which was read first. In this case, more than one data file packet has the same data file packet sequence number, as shown by way of example in Figure 4. If there are read errors during retrieval of a data file packet with a particular data file packet sequence number, the file retrieval unit 31 searches for another data file packet with the same data file packet sequence number.

The file retrieval unit 31 can be adapted for retrieving the data file in dependence on checksum data comprised in data file packets, the checksum data comprising at least one of the following: - parity data; cyclic redundancy check data; cryptographic data, in particular a hash function data. This functionality is described by way of example with reference to Figure 4. The parity data or the cyclic redundancy check data within the data file packets can be used as a second level protection against errors, in addition to error correction data, which may be comprised in data blocks.

Figure 3 shows an example of construction of data file packets, in accordance with the invention. The original data file 41 is split into chunks of 512 bytes minus certain amount of header information. Each of those chunks 42 is preceded by a specially crafted header 43 containing a synchronization pattern 44, file identification data 45 comprising a name of the data file, a data file packet sequence number 46 indicating a part of the data file and a total data file packet sequence number 47, which is the number of chunks for the data file. These elements form a data file packet 48 having a size of 512 bytes, which size is indicated by the reference sign 49 in Figure 3. All data file packets corresponding to the data file form transfer data 50, which are recorded as a transfer data file under control of a particular file system management, in the user area on the record carrier.

An example of a header 43 is given in table 1 below. In this example the header 43 comprises 34 bytes, leaving 478 bytes for a single chunk 42.

Table 1

No matter which file system the user utilizes to write a transfer data file on a record carrier, each data block on the record carrier that belongs to the transfer data file will start with a header as described above.

A single data block on the record carrier may contain more than one data file packet. This happens, when the smallest addressable unit of the record carrier is larger than 512 bytes. For example, in the CD system each data block has a size of 2048 bytes, therefore a single data block will contain four data file packets. However, each data block will always start with a header, since 2048 is a multiple of 512. Alternatively, for the same system, the size of a data file packet 49 can be 2048 bytes, leading to one data file packet per a data block. This gives 2010 bytes for a chunk of a data file, in the case of a header of 38 bytes.

The size of a single chunk of a data file multiplied by the number of chunks for the data file gives the size of memory allocated by the file retrieval unit 31 in the memory unit 32. Sequence numbers of data file packets are used by the file retrieval unit 31 for assembling the data file in the right order, in the memory unit 32.

A computer pseudo-code in Figure 6 describes an example of a method performed by the file retrieval unit 31 to read and re-assemble the data file. In order to provide redundancy, chunks comprising the same data can be repeated at least once among the data file packets. This is demonstrated in Figure 4 by chunks numbered as 1, 2 and 3, appearing twice in transfer data. The added redundancy increases the file size of the transfer data file. This can be compensated by compressing the transfer file, for example by making ZIP file, since the data in the file is simply repeated. The ZIP compression will be very efficient in this case, making the resulting file size only slightly larger than the one without redundancy, yet providing redundancy for the file that is placed on a record carrier.

Figure 4 shows another example of construction of data file packets, in accordance with the invention. The original data file 41 is split into chunks 42 to which headers 43 are added. At the end of each data file packet 48 a checksum 51 is added. This checksum can be a simple parity byte, a Cyclic Redundancy Check data, CRC, or even a cryptographically hash function such as MD5 or SHAl. In the later case, the data 50 can be securely transferred to the reading device. The checksum is generated over the header 43 and payload for each chunk 42. 1 should be noted, that although the addition of the checksum improves protection of data, it also decreases the amount of space available for the payload as the size of the data file packet 49 is not changed.

A computer pseudo-code in Figure 7 describes another example of a method performed by the file retrieval unit 31 to read and re-assemble the data file. In this example a checksum of 4 bytes is assumed, therefore the payload is reduced to 464 bytes as compared with 468 bytes in Figure 6.

Figure 5 shows an example of a method of retrieval of a data file, in accordance with the invention. In a step 101, a data block, out of consecutive data blocks stored at addressable locations in the user area, is read. Next, in a step 102, the data block is checked for presence of at least one data file packet by localizing within the data block at least one predefined synchronization pattern corresponding to said data file packet. If no synchronization pattern is present within the data block, the step 101 is repeated for a next data block. In case of presence of the at least one data file packet, a data file packet sequence number and a total data file packet sequence number comprised in the at least one data file packet are checked, in a step 103. The total data file packet sequence number represents a number of data file packets comprising parts of the data file. In a next step 104, a part of the data file, out of the parts of the data file, is stored in a memory, the part of the data file comprised in the at least one data file packet and identified by corresponding the data file packet sequence number. If more than one synchronization pattern is found in the step 102, the steps 103 and 104 are repeated for one or more data file packets within the data block, in dependence on a number of the synchronization patterns found. Next, in a step 105, it is tested whether the parts of the data file, comprised in data file packets within the data blocks, are stored in the memory. This is done by checking data file packet sequence numbers of retrieved parts of the data file versus the total data file packet sequence number. If the retrieval of the data file is not completed, the steps 101, 102, 103 and 104 are repeated for a further data block.

In an embodiment of the method of retrieval of a data file, the step 103 includes verification of the checksum described above.

Other embodiments of said method correspond to functionalities of the file retrieval unit 31, the firmware update unit 33 and/or the booting unit 34, as described with reference to embodiments of the reading device.

Figure 8 shows an example of a method of formatting a data file for storing, in accordance with the invention. In a first step 201, the data file is divided into data file parts. A total sequence number is given a value representing the number of the data file parts. For each data file part, out of the data file parts, a unique file sequence number is assigned in a step 202. Next, in a step 203, the data file part, the file sequence number and the total sequence number are assembled into a data file packet corresponding to the data file part. The data file packet is also provided with a predefined synchronization pattern. The steps 202 and 203 are repeated for each data file part out of the data file parts. In a next step 204, data file packets representing the data file are assembled into a storage file for storing in a user area on a record carrier.

In an embodiment of the method of formatting the data file, the steps 202 and 203 are combined together.

In another embodiment of said method, the steps 201 and 202 are combined together.

The step 203 can be modified to include a sub-step of generating a header comprising the predefined synchronization pattern, the file sequence number and the total sequence number, so the data file packet is assembled from the header and the data file part. Other embodiments of the method of formatting the data file incorporate examples of construction of data file packets as described with reference to Figures 3 and 4.

In an embodiment of the reading device, the control unit 20 and/or the functions of retrieval of a data file as described above are implemented in a software program. The software program running in suitable processor is controlling the execution of the retrieval process. The software program may be a executable file to be entered in the storage device, for example in the form of an update of the software already present in a program memory, like EPROM flash memory, in the storage device.

Different embodiments of a computer program product for use in retrieval of a data file stored in a user area on a record carrier, according to the invention, are operative to cause the control unit 20 to perform functions as described in reference to embodiments of the reading device and/or the method of retrieval of a data file presented above, when the computer program is executed by the reading device.

Different embodiments of a computer program product for use in formatting a data file for storing in a user area on a record carrier, according to the invention, are operative to cause a processor to perform functions as described in reference to embodiments of the method of formatting a data file storing, when the computer program is run on the processor.

Whilst the invention has been described with reference to preferred embodiments thereof, it is to be understood that these are not limitative examples. Thus, various modifications may become apparent to those skilled in the art, without departing from the scope of the invention, as defined by the claims and the embodiments. Further, the invention lies in each and every novel feature or combination of features described above. It is noted, that the invention may be implemented by means of a general purpose processor executing a computer program or by dedicated hardware or by a combination of both, and that in this document the word "comprising" does not exclude the presence of other elements or steps than those listed and the word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements, that any reference signs do not limit the scope of the claims, that "means" may be represented by a single item or a plurality and that several "means" may be represented by the same item of hardware.

Claims

CLAIMS:

1. A reading device for reading data from a removable record carrier (11), which device comprises:

- reading means (21, 22, 25) for reading the data recorded on the record carrier, and

- control means (20) for controlling the reading, the control means comprising file retrieval means (31) for retrieving a data file by:

- controlling the reading means to read consecutive data blocks recorded at addressable locations in a user area on the record carrier;

- for each data block, checking the data block for presence of at least one data file packet (48) by localizing within the data block at least one predefined synchronization pattern (44) corresponding to the at least one data file packet (48);

- storing in a memory (32) the part of the data file; and

2. A device as claimed in claim 1, wherein the file retrieval means (31) are for retrieving the data file from the data packets each having a size quantized in multiplies of 512 bytes.

3. A device as claimed in claim 1, wherein the file retrieval means (31) are for retrieving the part of the data file from the at least one data packet comprising a header (43), the header comprising the at least one predefined synchronization pattern, the data file packet sequence number and the total data file packet sequence number.

4. A device as claimed in claim 1, wherein the file retrieval means (31) are for retrieving the data file in dependence on checksum data (51) comprised in the at least one data file packet, the checksum data comprising at least one of the following:

- parity data; - cyclic redundancy check data;

- cryptographic data, in particular a hash function data.

5. A device as claimed in claim 1, wherein the file retrieval means (31) are for storing in the memory a copy of the part of the data file in case of read errors within the at least one data file packet, the copy comprised in a different data file packet.

6. A device as claimed in claim 1, wherein the file retrieval means (31) are for retrieving the data file based on file identification data identifying the data file, the file identification data comprised in the at least one data file packet, the data file packets comprising parts of plurality of data files.

7. A device as claimed in claims 3 and 6, wherein the file retrieval means (31) are for retrieving the data file in dependence on the file identification data comprised in the header.

8. A device as claimed in claim 1, wherein the control means comprise firmware update means (33) for upgrading software for controlling operations of the device with upgrade data comprised in the data file.

9. A device as claimed in claim 1, wherein the reading means are for reading the data represented by optically detectable marks on the record carrier.

10. A method of retrieval of a data file stored in a user area on a removable record carrier, the method comprising steps of: a) reading a data block out of consecutive data blocks stored at addressable locations in the user area; b) checking the data block for presence of at least one data file packet by localizing within the data block at least one predefined synchronization pattern corresponding to the at least one data file packet; c) in case of presence of the at least one data file packet, checking a data file packet sequence number and a total data file packet sequence number comprised in the at least one data file packet, the data file packet sequence number identifying a part of the data file comprised in the at least one data file packet, the total data file packet sequence number representing a number of data file packets comprising parts of the data file; d) storing in a memory the part of the data file; e) repeating steps from a) to d) for a further data block; and f) completing retrieval of the data file upon storing in the memory the parts of the data file comprised in the data file packets within the data blocks.

11. A method as claimed in claim 10, wherein the at least one data packet has a size quantized in multiplies of 512 bytes.

12. A method as claimed in claim 10, wherein the at least one data packet comprises a header (43), the header comprising the at least one predefined synchronization pattern, the data file packet sequence number and the total data file packet sequence number.

13. A method as claimed in claim 10, wherein the at least one data file packet file comprises checksum data (51), the checksum data comprising at least one of the following: - parity data;

- cyclic redundancy check data;

- cryptographic data, in particular a hash function data.

14. A method as claimed in claim 10, wherein in case of read errors within the at least one data file packet, a copy of the part of the data file is stored in the memory, the copy comprised in a different data file packet.

15. A method as claimed in claim 10, wherein retrieval of the data file is based on file identification data identifying the data file, the file identification data comprised in the at least one data file packet, the data file packets comprising parts of plurality of data files.

16. A method as claimed in claims 12 and 15, wherein the file identification data is comprised in the header.

17. A method as claimed in claim 10, wherein the data file comprises upgrade data for upgrading software for controlling operations of a device.

18. A device as claimed in claim 10, wherein the data blocks are represented by optically detectable marks on the record carrier.

19. A method of formatting a data file for storing in a user area on a removable record carrier, the method comprising steps of: a) dividing the data file into data file parts; b) assigning a file sequence number to a data file part out of the data file parts; c) assembling the data file part, the file sequence number and a total sequence number into a data file packet, the total sequence number representing a number of the data file parts; d) providing the data file packet with a predefined synchronization pattern; e) repeating steps from b) to d) for each data file part out of the data file parts; f) assembling data file packets representing the data file into a storage file for storing in the user area.

20. A computer program product for use in retrieval of a data file stored in a user area on a record carrier, the computer program comprising program code means for causing a processor of a reading device, to perform the steps of the method as claimed in claims 10 to 18, when the computer program is run on the processor.

21. A computer program product for use in formatting a data file for storing in a user area on a record carrier, the computer program comprising program code means for causing a processor, to perform the steps of the method as claimed in claim 19, when the computer program is run on the processor.