CZ20001197A3 - Data entry - Google Patents

Abstract

A method of loading data into a receiver / decoder that is in the receiver / decoder includes the steps of: receiving a bit stream including data; introducing a boot loader to load data from a bit flow to the receiver / decoder; and loading said data from bit stream using said loaded data stream loaders. The receiver / decoder (2020) includes a receiver (2018) memory means and delivery means.

Description

Data loading

Technical field

The present invention relates to a method of introducing data into a receiver / decoder, and further relates to such a receiver / decoder and a broadcasting system.

BACKGROUND OF THE INVENTION

The term receiver / coder used in this disclosure may include a receiver for receiving either coded or ¹⁰ uncoded signals, for example, television and / or radio signals, which may be transmitted or transmitted by any other means. The term may also include a decoder for decoding the received signals. Embodiments of such receivers / decoders may include a decoder integral with the receiver to decode the received signals, for example, in an STB, or such a decoder that operates in combination with a physically separate receiver, or such a decoder that includes additional functions such as web browser, video recorder, or television.

The advent of digital broadcasting systems intended primarily for broadcasting television signals, in particular, but not exclusively, satellite television systems has opened the possibility of using these systems for other purposes. One of these other purposes or options is to ensure interactivity with the end user. As used herein, the term digital broadcasting system includes any broadcasting system for broadcasting or transmitting, for example, primarily audiovisual or broadcasting

2Q multimedia data. Although the present invention is particularly applicable to a broadcast (air) digital television broadcasting system, the invention may also be applicable to a fixed telecommunications network for multimedia internet applications, closed circuit television and the like.

One way to ensure interactivity, as described above, is to run the application on a receiver / decoder that receives a television signal. The application code could be permanently stored in the receiver / decoder. But that would be rather a limiting factor. Preferably, the receiver / decoder should be able to download code for the desired application. In this way, greater flexibility can be provided and applications can be updated as required without any user involvement.

In an MPEG system, the application code may be loaded in the MPEG tables transmitted in the MPEG bitstream. The term MPEG refers to data transmission standards developed by the International Standardization Organization in the Expert Group on Film and in particular, but not exclusively, the MPEG-2 standard developed for digital television applications and defined in ISO 13818-1, ISO 13818-2, ISO 13818 -3 and ISO 13818-4. In the context of this application, the term includes all variants, modifications, or developments of MPEG formats applicable to the field of digital data transmission.

Software for downloading (loading) MPEG tables must be stored permanently in the receiver / decoder. Complex software is required to load data such as application code or an updated version of an execution agent (program), which usually takes up a large amount of memory. But such software can only be used sporadically, if at all, and so can be a large amount of memory »9

occupied by software that is completely redundant for long periods of time.

Software stored in a decoder receiver for downloading data from a bitstream is commonly referred to as a Bootstrap program. This self-loading program is preferably adapted to download most forms of data, including software from a bitstream for storage, for example, in a flash storage medium of a receiver / decoder. Thus, the self-loading program tends to a somewhat basic structure having a minimum amount of functionality so that all forms of software can be loaded.

The boot loader is usually stored in the ROM storage medium of the receiver / decoder and is not erasable from that memory. Since the boot loader cannot be modified once it has been written to the ROM storage medium, the processing errors that may occur if the boot loader is damaged are not corrected. In addition, the functionality of the boot loader is fixed once it has been written to the ROM, and cannot be updated, for example, to reduce the time it takes to download data from the bitstream. Also, software having an improved or new structure not recognizable for the boot loader cannot be downloaded from the bitstream.

If part of the data stored in the receiver / decoder is corrupted, the boot loader can be used to load a complete undamaged version of the data. If only a very small part of the data is corrupted, it may result in a significant amount of time to download parts of the data that have not been corrupted at all.

t • 0 · ·······

The present invention aims to solve the above and other problems.

SUMMARY OF THE INVENTION

In a first aspect, the present invention provides a method of introducing data into a receiver / decoder, which comprises the steps of:

receiving a bitstream including data;

introducing an inserter for introducing data from the bitstream into the 10 receiver / decoder; and loading said data from the bitstream using said loaded data loader.

In one embodiment, the loaded data loader includes a data loader. At least a portion of the data loader, preferably most, or even the entire data loader, may be in the form of machine code. As used herein, the term machine code includes hardware-specific code, which is code that is specific to a particular receiver / decoder hardware platform, code that is not interpretive, and / or code that is directly executable by the receiver / decoder microprocessor. The structure of the portion of the machine code to be downloaded by the receiver / decoder will therefore depend on the particular device being used in the hardware platform of that receiver / decoder. This is in contrast to the interpretation code, known for example as a pseudocode, which requires interpretation by means of software stored in the receiver / decoder so that it can be executed by a microprocessor and which is therefore functional for a wide range of hardware platforms. The data loaded by the data loader may be in the form of a machine code, a pseudocode, or in the form of a machine code.

any other suitable form, such as data tables.

By means of the above-described procedure, the inserter for introducing data from the bitstream is loaded from the bitstream and stored, preferably temporarily, in the RAM of the receiver / decoder. Following the introduction of the desired data from the bitstream using the data loader, the loaded data loader is preferably deleted from the receiver / decoder. Thus, once the loaded data loader has already served for the purpose, the RAM storage capacity is effectively increased for a period in which data loading is not required.

Of course, it is not essential to erase the loaded data loader once all of the requested data has been loaded from the bitstream. In contrast, the data loader may subsequently be stored in a non-volatile memory of the receiver / decoder, such as a Flash storage medium. This may allow the receiver / decoder to load additional data using the stored data loader without having to reload the data loader from the bitstream, thereby reducing the time required to load the data. Thus, a plurality of different data loaders can be stored at any time in a receiver / decoder.

Because the data loader, written specifically for loading one particular data item, can be loaded by the receiver / decoder from the bitstream as desired, improved receiver / decoder functionality can be achieved because data with an updated or revised structure that differs from the data structure that may be loaded via a self-loading program, may be loaded and stored in a receiver / decoder.

0 «00 ·

In one preferred embodiment, the data loading is performed by the loaded data loader. Thus, for loading data, the self-loading program is actually temporarily replaced by the loaded data loader, allowing the receiver / decoder to use an updated or otherwise improved data loader.

Preferably, only a portion of the data stored in the receiver / decoder is replaced by the corresponding portion of the data loaded via the loaded data loader.

For example, if a portion of the stored data is corrupted or outdated, only an undamaged or updated version of that portion of the data can be loaded by the receiver / decoder, wherein the loaded data loader inserts the loaded portion of the data into the stored data where appropriate. Thus, the loaded data loader 15 does not load the entire version of the data stored in the receiver / decoder. This can provide a significant improvement in the time needed to repair or update the stored data, since loading of undamaged parts of the data is not required. In an alternative embodiment, a portion of the data stored in the receiver / decoder is replaced by a corresponding portion, for example, of the data section transmitted with the loaded data loader.

The bit stream may include at least one data loader and the method may further comprise the steps of a broadcast system:

for said at least one or each data loader, splitting the data loader into a plurality of modules; and for said at least one or each data loader, splitting the data into a plurality of modules, each plurality of data modules being associated with a plurality of data loader modules.

r i * ♦

Thus, the bitstream may include a plurality of data loaders and associated data. This may allow receivers / decoders having different hardware platforms to load appropriate versions of the data loader and associated data. The data, such as the application, may advantageously be composed of a number of modules that can be loaded and, if appropriate, executed as desired.

The method may further comprise the steps of a broadcast system:

Proθ for said at least one or each data formatter of each module as the respective table, wherein the tables have the same appropriate table identification (TID) and different table extension (TID) extensions accordingly; and, for said at least one or each plurality of data module formats, formatting each of the data modules as a respective table, the tables having the same appropriate TID as the data loader module tables associated therewith and correspondingly different TID extensions.

^{20 May}

It is preferred that the MPEG protocol is used and, if so, the loading steps may include loading the modular MPEG tables.

The tables may have correspondingly different TID extensions 25 other than the predetermined TID extensions; and the method may further comprise the step of transmitting in the broadcast system: forming an appropriate directory table for said at least one or each plurality of modules having the same TID, the at least one or each directory table having said predetermined TID extension and the TID, and wherein the directory For each module, the table contains the name of the module and the appropriate TID extension.

The method may further comprise the steps of a receiver / decoder:

introducing one of the tables having predetermined

TID extensions to load a directory table;

determining from the contents of a directory table a TID-extension of module tables having the same TID as a directory table; and, in said loading steps, loading module tables having the same TID as the loaded directory table and a TID extension determined from the loaded directory table.

By means of these features, the directory table 15 can be easily identified because it has a certain TID extension and, once introduced, can allow the receiver / decoder to identify the data loader module tables from their respective TID extensions.

2o The method may further comprise a step in a broadcast system:

creating a directory table having a predetermined table identification (TID) and including, for each of the plurality of receiver / decoder version identifications, the appropriate TID associated with that version identifier.

If the method includes this step, it may further include the steps in the receiver / decoder:

loading said directory table having a predetermined TID; and determining the version of the receiver / decoder;

wherein the step of introducing the directory table includes ···· * · • · ·· "· · · • β a ·« ₉ • · · · · · ·· ·· · ·· ** * the introduction of one of the tables, which has a TID associated with a receiver / decoder version number, and a predetermined TID extension.

Preferably, the version identification includes the code assigned to the receiver / decoder manufacturer and the code assigned to the receiver / decoder version 5.

It is to be expected that receivers / decoders can be designed and manufactured by various different manufacturers. Each manufacturer can create a number of different versions of the receiver / decoder. Receivers / decoders may therefore have different hardware designs, although of course all will meet the same functional specifications. It is therefore important that data, such as an application, behave in the same manner on each receiver / decoder, and that the receiver / decoder perform all applications in the same, correct manner.

To ensure that the data is compatible with a particular version of the receiver / decoder, the bitstream may include a data loader and data for each version identification

A receiver / decoder 2o, and a directory table having a predetermined TID may allow easy identification of the TID modules of the data loader and the data for each identifier of the receiver / decoder version.

Preferably, the method further comprises the steps of a broadcast system:

including in each transmitted directory table a version identification directory for that table; and in the receiver / decoder:

determining if the directory identification of the version 30 of the currently transmitted directory table is newer than the directory identification this is it • to · • · · * ·· ·>

identifying a version of the previously loaded directory table having the same TID as the currently transmitted directory table and, if not, interrupting data loading.

The bootloader can be instructed, for example, through an application, to periodically load a directory table to determine if the directory identification of a version of a previously loaded directory table has changed. This can ensure that the receiver / decoder loads promptly any updated data from the bitstream.

In order to prevent the resident data stored in the receiver / decoder from being overwritten by the same received data, an application requiring resident data update may choose to interrupt data loading if the directory table is the same as the directory table used in the previous 15 resident data update.

Preferably, at least one of the modular tables is formatted as a plurality of slots that are transmitted separately in a bit stream, each slice comprising in its

2Q, a predetermined portion identifying the section in the table and indicating the number of sections in the table.

The method may further comprise the step of transmitting the tables in a bit stream in a broadcast system.

The method may further include the step of transmitting in the broadcast system: 25 incorporating into the bitstream a data identification of the version of the data; and step in receiver / decoder:

determining whether the data identification of the version of the received data is newer than the data identification of the version of the data currently being stored, and

If so, perform said step of retrieving data from the bitstream.

By this feature, the loading can be interrupted before the resident software is deleted and / or the loading of the received data is started if the data identification of the version of the received data is the same as the data identification of the version of the resident data stored in the receiver / decoder.

Preferably, the step of determining whether the data identification of the version of the received data is newer than the data identification of the version of the currently stored data is performed after detecting that the data identification of the version of the currently transmitted directory table is newer than the data identification of the previously loaded directory table having the same TID as the currently transmitted directory table.

In another preferred embodiment of the invention, the loaded data loader modifies the means stored in the receiver / decoder for loading the data loader so that the data can be loaded by the modified loading means. Thus, the inserter may be modified advantageously by means of a data inserter loaded from the bitstream so that, for example, data with a different structure may be introduced via the inserter.

Preferably, the method comprises the steps of a broadcast system:

transmitting a second data loader included in said bitstream; and in the receiver / decoder:

loading the second data loader; and loading one of said first data loader

0000 01 »• · 00 • * ♦ · t * 0 0 0

0 · 00

0 · 0

0 0 0

0 0 ·

00 and data, said second inserter performing the loading of one of said first data inserter and data.

In one embodiment of the invention, the second data loader is provided by another data loader 5, wherein at least a portion of the second loader is preferably in the form of a machine code.

This may allow loading of the data loader by using a different data loader previously loaded from the bit stream. Therefore, it is not necessary to load the data loader from the bitstream each time fresh or revised data is to be loaded if the previously loaded data loader is able to load the data as efficiently as a new data loader. This can substantially reduce the time required to load fresh or revised data from the bitstream. The second data loader may provide improved functionality over the first data loader, for example, the second gift loader may be capable of loading computer programs.

In a second aspect, the present invention provides a receiver / decoder comprising:

a receiver for receiving a bitstream including data;

a storage means, such as memory; and inserter for fitting from the bitstream to the inserter memory means for inserting data from the bitstream to the receiver / decoder.

In one preferred embodiment, the inserter is formed by an initialization program stored in the receiver / decoder.

* ··· 000

0 * 00 · 0 «0 00 00

The receiver / decoder may further include means for deleting the loaded data loader from the memory means after the data has already been loaded from the bitstream. This lubricant may be formed by the base unit and associated software stored in the receiver / decoder.

The receiver / decoder may be arranged to load tables. If so, the loading means may be arranged to load a table having a table identification (TID) and a predetermined table identification extension (TID extension), to load a directory table, to determine from the contents of a directory table a TID extension of module tables having the same TID as a directory table, and for loading module tables having the same TID as the TID of the loaded directory table and a TID extension, determined from the loaded directory table, for loading said loader.

The inserter may be arranged to load a directory table having a predetermined TID and comprising, for each of a plurality of receiver / decoder versions identifications, a respective TID associated with that version identifier, to determine a receiver / decoder version identification, and to load a directory table having a TID. associated with the receiver / decoder version number, and a predetermined TID extension.

In a preferred embodiment, the loading means is arranged to determine whether the version identification of the currently transmitted directory table is newer than the version identification of the previously loaded directory table having the same TID as the currently transmitted directory table and, if not, to interrupt the loading of said loader.

0 · 0 · 0

0 * 00

0000 000

0 0 0 0 0 0

0 * »·

The receiver / decoder may further comprise a parallel port and / or a serial port arranged to receive formatted data as at least one table.

Preferably, said inserter is arranged to load a second data inserter included in said bitstream for loading one of the first data inserter and data.

In a third aspect, the present invention provides an IQ broadcast system comprising:

means, such as a transmitter, for transmitting a bitstream including machine code comprising at least one data loader for loading data to a receiver / decoder and data associated with the at least one or each data loader; and 15 means, such as a data service channel, for splitting said at least one or each data loader into a plurality of modules and splitting the data associated with said at least one or each data loader into a plurality of modules for transmission by said transmission means.

Preferably, the broadcast system further comprises: means for formatting each of the modules of said at least one or each data loader as the respective 25 tables, said tables of said at least one or each data loader having the same appropriate table identification (TID) and correspondingly different table identification extensions (TID) -extension); and means for formatting each of the data modules,

3q associated with said at least one or each data loader as the respective tables, said tables being said tables; 9 · · · · · · · · · · · · · ·

9 · ·· data modules have the same appropriate TID as the data loader module tables associated with them and the different TID extensions.

The formatting means may advantageously be provided by a data service channel.

The tables may have correspondingly different TID extensions other than a predetermined TID extension; and the system may further comprise means for generating appropriate directory tables for said at least one or each plurality of modules having the same TID, each directory table having said TID and said predetermined TID extension, and wherein the directory includes for each module a module name and proper TID extension.

The broadcast system may further comprise: a directory table building means having a predetermined table identification (TID) and comprising, for each of the plurality of receiver / decoder version identifications, an appropriate TID associated with that version identifier.

The broadcast system may further include means for including in each transmitted version identification table for that table.

Each of the aforementioned means may advantageously be provided via a data service channel.

A fourth aspect of the present invention provides a combination of a receiver / decoder as described above and a transmission system as described above.

9

9 9

9 9

··· «t · ft

A fifth aspect of the present invention provides a signal comprising at least one loader for inserting data into a decoder receiver and data associated with the at least one or each data loader, said at least one or each data loader being divided into a plurality of modules and data associated with said at least one or each data loader, they are divided into the corresponding corresponding number of modules.

All features of the method aspect of the present invention can be suitably applied to aspects of the device and signal, and vice versa.

Preferred features of the present invention will be described in more detail below, purely by way of example and with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows the overall architecture of a digital television system;

Fig. 2 shows the architecture of the interactive system of the digital television system of Fig. 1;

Fig. 3 is a schematic representation of a receiver / decoder interface forming part of the system of Figs. 1 and 2;

Giant. 4 is a schematic representation of a remote control used in a digital television system;

Giant. 5 illustrates the arrangement of files within a module loaded into the memories of an interactive receiver / decoder;

· Φ φ φ φ · · »» »» t t t φ φ φ

Giant. 6 illustrates the relationship between a plurality of components of an MPEG stream;

Fig. 7 illustrates how an application can be assembled from modules / tables that can further be assembled from sections;

Giant. 8 illustrates MPEG table permissions;

Giant. 9 illustrates various areas of memory in a television system receiver / decoder;

10 illustrates an array of parameters;

Figure 11 illustrates a hardware directory table;

Fig. 12 illustrates a boot loader directory table; and

13 illustrates a procedure for loading data.

DETAILED DESCRIPTION OF THE INVENTION

An overview of the digital television system 1000 is shown in Figure 1. The digital television system 1000 includes a mostly conventional digital television system 2000 that utilizes the known MPEG-2 compression system to transmit compressed digital signals. More specifically, the MPEG-2 compressor 2002 at the broadcast center receives a digital signal stream (usually a video signal stream). The multiplexer 2002 is coupled to the multiplexer and encoder 2004 via a link 2006. The multiplexer 2004 receives a plurality of additional input signals, assembles one or more broadcast streams, and sends compressed digital signals to the broadcast center transmitter 2008 via a link 2010, which of course can be represented by many forms including telecommunication lines. Transmitter 2008 transmits electromagnetic signals via the uplink 2012 in the direction of the satellite transponder 2014, where the signals are electronically processed and transmitted via the theoretical downlink 2016 to the terrestrial receiver 2018, normally in the form of a parabolic antenna owned or rented by the end user. The signals received by receiver 2018 are transmitted to an integrated receiver / decoder 2020 owned or rented by the end user and associated with the end user television equipment 2022. The receiver / decoder 2020 decodes the compressed MPEG-2 signal into a television signal for the television device 2022.

The conditional access system 3000 is coupled to the multiplexer 2004 and receiver / decoder 2020 and is located partly in the broadcast center and partly in the decoder. This system allows the end user to access digital television broadcasts from one or more broadcasters. A smart card capable of decoding messages related to commercial offers (i.e. one or more television programs sold by the broadcaster) may be inserted into the receiver / decoder 2020. Using the decoder 2020 and the smart card, the end user may purchase the broadcast event either subscription or pay-per-view mode.

Also connected to the multiplexer 2004 and the receiver / decoder 2020 is an interactive system 4000, which is again located partially in the broadcast center and partly in the decoder, and which allows the end user to interact with various applications via the modem return channel 4002.

· * Fl fl fl 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

Fig. 2 shows the general architecture of the interactive television system 4000 of the digital television system 1000.

For example, this interactive 4000 system allows end users to purchase items from on-screen catalogs, consult local news and weather maps on demand, and play games through their television devices.

In summary, the interactive system 4000 includes four main elements: • a creative tool 4004 in the broadcast center or elsewhere to allow the broadcaster to create, develop, debug and test applications;

Application and data service channel 4006 in the broadcast center, coupled to the creative tool 4004 to enable the broadcaster to prepare, validate, and format applications and data for delivery to the multiplexer and encoder 2004 for inclusion in the MPEG-2 transport stream (usually its private portions) to be sent to the end user;

A virtual machine including an execution means (RTE) 4008, which is executable code installed in a receiver / decoder 2020 owned or rented by the end user to allow the end user to receive, verify, decompress and download (load) applications to the decoder work memory 2020 for execution. This execution means 4008 also implements resident general purpose applications. The execution means 4008 is hardware and operating system independent; and

«· • *

a modem return channel 4002 between the receiver / decoder

2020 and an application and data server 4006 to enable signals instructing the application and data server 4006 to load data and applications into the MPEG-2 transport stream at the request of the end user.

The interactive television system operates using applications that control the functions of the receiver / decoder and the various devices contained therein. Applications are represented in executing means 4008 as source files. A module is a collection of source files and data. The amount of receiver / decoder memory is the memory space for the modules. The modules may be downloaded to the receiver / decoder 2020 from the MPEG-2 transport stream.

The receiver / decoder physical interfaces 2020 are used to download data. Referring to Fig. 3, it will be seen that the decoder 2020 comprises, for example, six inserter devices; MPEG stream tuner 4028, serial interface 4030, parallel interface 4032, modem 4034, and two smart card readers 4036.

For purposes of this description, the application is a machine code section for controlling the high-level functions of the receiver / decoder 2020. For example, when an end user directs the focus of remote control 2026 (as shown in more detail in FIG. 4) at the button object seen on the television screen the instruction key associated with this button.

0 0 00 00 000 000 00 000 000

The interactive application offers menus and executes commands at the request of the end user and provides data related to the purpose of the application. The applications may be either resident applications, that is, they are stored in ROM (or FLASH or other non-volatile memory) of the receiver / decoder 2020, or they may be transmitted and downloaded (downloaded) to the RAM (or FLASH) of this decoder 2020.

Examples of applications are: • Initialization applications. The receiver / decoder 2020 is,,,,, equipped with a resident initialization application, which is an adaptable set of modules (this term is defined in more detail below), allowing the receiver / decoder 2020 to operate immediately in an MPEG-2 environment.

This application provides essential features that can be modified by the broadcaster if desired. This app also provides an interface between resident apps and downloaded apps.

• Startup application. The startup application allows any application, whether downloaded or resident, to operate in the receiver / decoder 2020. This application acts as a bootloader executed upon entering the service to run the application. The boot application is loaded into RAM and thus can be easily updated. It can be arranged so that the interactive applications available on each channel can be selected and launched either immediately after downloading or after downloading in advance. In the case of pre-download, the application is downloaded to memory 2024 and activated by the on-demand launcher.

»-« • • · · · · · · · · · · · · · Program Guide is an interactive application that provides comprehensive information about programs. For example, it can provide information, say, about one week TV programs that will be featured on each channel of a digital TV file. By pressing a key on the remote control 2026, the end user enters an additional screen overlaying the event (s) shown on the television screen 2022 This added screen is a browser providing information about current and subsequent events (s) on each channel of the digital television file. By pressing another key on the remote control 2026, the end user enters another application that displays a list of event information within a week.

The end user can also search and sort events according to simple and customized criteria. The end user can also directly access the selected channel.

· Pay per view application. The pay-per-view application is an interactive service available on each PPV channel of a digital television file in conjunction with a conditional access system 3000. The end user can access this application using a program guide or channel finder. In addition, the application will start automatically as soon as the PPV event is detected on the PPV channel. The end-user can then purchase an ongoing event either through his daughter smart card 3020 or through a communication service channel 3022 (using a modem, telephone and DTMF codes). Fefe fe feefefe feef feefefe fe • • • • • • • • • • • • • • • • • • • • • • • • • • • • • This application can be either resident in ROM receiver / decoder 2020 or downloadable to RAM receiver / decoder 2020.

• Internet search engine application. In one example 5 of this web browser application, user instructions, such as a web page tracking request having a certain URL, are entered using remote control 2026 and these instructions are transmitted via modem return channel 4002 to application and data service channel 4006.

The respective website is then integrated into the broadcast from the broadcast center, received by the receiver / decoder 2020 via the uplink 2012, the transponder 2014 and the downlink 2016, and displayed on the television device.

2022.

Applications are stored in receiver / decoder memory locations 2020 and are represented as source files. Source files include graphic object description unit files, variable block unit files, instruction sequence files, application files, and data files.

Graphic object description unit files describe the screens, the human-computer interface of the application.

Units of variable block units describe the data structures handled by the application. The instruction sequence files describe the processing operations of the application. Application files provide entry points for applications.

Applications created in this way can use data files such as library icon files, image files,

0 0 0 0 0 0 0 0 0

00 0 0 00 * character font files, color table files, and ASCII text files. Interactive applications can also obtain direct (on-line) data by performing inputs and / or outputs.

Executing means 4008 only loads into its memory the 5 resource files it needs at any given time. These source files are read from graphic object description unit files, instruction sequence files, and application files; the variable block unit files are stored in memory after the module download procedure is called and remain there until a specific module removal procedure call is made.

Referring to Fig. 5, a module 4010, such as a tele-shopping module, is a source file and data assembly that includes the following:

one application file 4012;

an undetermined number of graphic object description unit files 4014;

an unspecified number of sets 4016 of the variable ²⁰ H1 block variables;

an unspecified number of instruction sequence sets 4018; and, where appropriate, 4020 data files, such as library icon files, image files, character font files, color table files, and ASCII text files.

The concept of modules, together with the concept of loading (downloading) small pieces of code, makes it easy to develop applications. Applications can be downloaded to the permanent FLASH memory of the decoder 2020 as resident software, or they can be • »«

0 000 000 000

0 * · 00 transmitted to be downloaded to the RAM decoder 2020 only when the end user needs it.

In the case of an MPEG stream, one module 4010 is transported in a single MPEG table. In the case of modules transmitted to a 4028 MPEG stream tuner, a long MPEG-2 format with a longer header and a CRC code is used. This is also the case with five other interfaces (serial interface 4030, parallel interface 4032, modem 4034, and two smart card readers 4036), except that a short MPEG-2 format with an η shorter header and no CRC code is used.

6, and as is known, the MPEG-2 bitstream includes a program access table (PAT) having a packet identification (PID) of 0.

The PAT 10 includes references to the PID of the program mapping tables (PMT) of a plurality of programs. Each PMT 12 contains references to the PID streams of the audio MPEG tables 14 and the video MPEG tables 16 for this program. A packet having a PID of zero, i.e., the program access table 10, provides an entry point for all MPEG access.

In order to download (download) applications and data for these applications, two new types of streams are defined and the relevant PMT 12 also includes references to PID streams of the application MPEG tables 18 (or slices thereof) and the MPEG data tables 20 (or slices thereof).

As shown in FIG. 1, in order to download the application 22, the application 22 is divided into modules 24, each of which is made up of an MPEG table, some of which are assembled from one section 18 and others composed of a plurality of sections 18. A typical section 18 has a header 26 that includes a one-byte table identification 28 (TID), a section number 30 for that section in the table, a total of 32 sections in this table, and a two-byte TID. Enlargement 34. Each slot also includes a data portion 36 and a CRC 38. For a particular module / table

24, all of the sections 18 forming this table / module 24 have the same TID 28 and the same TID extension 34. For a particular application 22, all of the tables 24 forming this application 22 have the same TID 28 but different corresponding TID extensions 34θ. with reference to FIG. 8, an MPEG table verification is described. Table 40 includes data 42 (typically including header 26, TID 28, TID extension 34, and data portion 36), key identification 44, coded area 46. Key identification 44 includes a 1-byte identification of a particular private key to be used for encoding. block. The coded area 46 comprises a block of 96 bytes of data. The first byte 48 is zero. The 16 byte signature 50 begins to shift typically between 0 and 31 bytes after the first byte. The signature 50 is created using the known MD5 process to create the signature θ on the data 42. The dummy data 52 is inserted between the first byte and the signature 50 and the block is coded using the known encoding process and the private key corresponding to the key identification 44.

If a plurality of MPEG tables are to be verified, then a directory containing the table names and signatures of the tables is included in the carrier signal. In the case of an MPEG stream, this directory is transported in one separate MPEG table, typically having a TID extension 34 of zero. The directory table is verified by the mechanism described above. Once the directory has been downloaded from the carrier, it is possible for the application to download one or more MPEG tables specified by the directory.

In the following description, the operation of the receiver / decoder 2020 in signature processing and decoding during application download. As shown in FIG. 9, the receiver / decoder 2020 includes EEPROM 68, FLASH 69, ROM 70, and RAM 72. EEPROM 68 includes a protected area 74 that is used by the virtual machine and can only be written by the virtual machine (and not a conventional machine) application). The protected area 74 includes a bit map 76 for verifying a 16 or 256 bit key and a 32 bit offset offset map 80. The ROM 70 includes, in one embodiment, sixteen public keys 82, in which case a 16-bit bitmap 76 is used to verify the key, and in another embodiment 256 public keys 82, in which case the 256-bit bitmap 76 is used to verify the key. Public keys are identified by their physical locations in the ROM 70, or alternatively, may be included in a lookup table, wherein the identification of a particular key will point to the corresponding public key.

RAM 72 may be used to store the temporary key 84.

When an application is to be downloaded, a directory table having a predetermined TID for that application and a TID extension of zero is first downloaded. The key identification 44 is then extracted from the directory table, and the key verification bitmap 76 is verified in the protected area 74 that the bit corresponding to the extracted key identification 44 is set. If it is not, then further download of the application is interrupted. However, if the corresponding key is set, then the public key 82 corresponding to the extracted key identification 44 is selected from the ROM 70. The selected public key 82 and the known decoding process are then used to decode the coded block 46 in the directory table 40 to create the selected key. block. An offset is found in the offset bitmap 80 in the memory protected area 74, or, if more than one offset bit is set, each offset bit is retrieved, and sixteen bytes of data beginning with the offset offset are removed from the decoded block. For said one or each search offset, these 16 bytes are considered to be transmitted with the directory table 40. The signature of the entries in the directory portion 42 of the directory table 40 is calculated using the known MD5 process and this calculated signature is compared with the signature extracted from the decoded block. If the two signatures do not match for the one or each scroll found, then the next download of the application is interrupted. However, if one of the signatures matches, then the download of the modules specified in the directory part 42 can continue. As mentioned above, to download a module, the TID extension for that module is obtained from the directory part 42 and the MPEG table 24 or sections 18 with the same are downloaded. TID, such as a directory table, and with the obtained TID extension. Once the modular MPEG table has been downloaded, the receiver / decoder 2020 calculates the signature of the downloaded table using a known MD5 process, and then compares this calculated signature with the signature contained in the directory entry.

If the signatures match, then the module is accepted, but if they do not, then the module is discarded.

Thus, all of the application modules can be loaded (downloaded) in the manner specified above, and the application can be started by the receiver / decoder 2020.

* ·· ♦ · »v v v ·

The introduction of the data into the receiver / decoder 2020 will be described in more detail in the following description with reference to Figures 9 to 13.

The receiver / decoder 2020 includes a bootloader 100, referred to as a boot loader 100, that is used primarily to load a bootloader to load software such as manufacturer's firmware, execution means 4008, and applications present in the MPEG data stream for storage in the receiver's FLASH memory 69. The bootloader 10Q is stored in the FLASH memory 69 of the receiver / decoder 2020 and is usually not erasable therefrom. The boot loader works under the control of the receiver / decoder 2020 hardware and the software stored therein.

Writing / updating of software stored in the receiver / decoder can be performed by:

• at the request of the user of the receiver / decoder 2020;

• at the request of the application, stored in the receiver / decoder 2020; or • if the software previously stored in the receiver / decoder 2020 (known as resident software) has been damaged.

To determine if the resident software has been corrupted, the software written by the receiver / decoder 2020 manufacturer and stored in the receiver / decoder 2020 calculates a checksum on the resident software data and compares this checksum to the checksum written in the resident software. If the two checksum values are not the same, the resident software has been corrupted.

· · ♦ * ·· ·• · ν ··· · · · +9

The FLASH memory 69 and the EEPROM memory of the receiver / decoder 2020 include parameters that allow the boot loader 100 to boot the boot loader in the form of machine code from the bitstream. The parameters can be stored in the self-loading program 100 itself, i.e. in the FLASH memory 69 or in the EEPROM memory 68. Examples of parameters that can be stored in FLASH memory 69 include:

• the frequency at which the transponder 2014 is tuned;

Various characteristics of the signal to be demodulated by the receiver / decoder 2020;

• the PID with which the software is to be broadcast;

A set of public keys (preferably three keys) to be used during authentication;

• time interval for loading directory tables from

MPEG bit stream;

The version number of the boot loader 100; and a N byte checksum parameter used to check the integrity of the resident software, the value of which is determined by the receiver / decoder manufacturer 2020.

Examples of parameters that can be stored in the EEPROM 68 and which can be updated via an application stored in the receiver / decoder 2020 include:

• further characteristics of the signal to be demodulated by the receiver / decoder 2020; and • parameters that allow you to create a write / update report.

These parameters are stored in the respective parameter fields in FLASH 69 or EEPROM 68. As is φ · * · • · ·

As shown in FIG. 10, each parameter field 400 contains a length of 402, a reserved byte 404, a set of parameters 406, and a longitudinal parity checksum 408 (LRC). ). This checksum includes CRL 410, which is the non-equivalence of the previous bytes of the parameter array 400, and NCRL 412, which is the CRL 410 complementary. If the network application stored in the receiver / decoder 2020 wishes to update the parameters stored in the parameter field, The PID calculates an LRC checksum for this field and compares it to the LRC checksum 410 stored in the field. If these two values match, then updating the parameter field is enabled; if they do not match then the parameter field update is interrupted.

The MPEG bit stream containing data to be loaded into the receiver / decoder 2020 carries machine code, at least a portion of which includes an additional loader, referred to as an input loader (input stream loader). The boot loader 100 loads this input loader from the MPEG bitstream into the receiver / decoder RAM 72, this is the input loader,

0 that loads data from the MPEG bitstream, for example, to update resident software.

The software loaded into the FLASH memory of the receiver / decoder 2020 may also include a boot loader, referred to as a resident boot loader. This resident loader should be able to at least perform software writing / updating from the MPEG bitstream and may offer additional features such as updates from local ports, and may allow decoding of video and audio data in the MPEG bitstream. The resident bootloader is loaded from the bitstream at the request of the application 30, for example, to supplement the bootloader that performs. _ • * ···· ’*! J · »** ································ Loading the input bootloader, or for loading data from the bitstream. For example, if the application writer / update stored in the receiver / decoder 2020 is desired and the resident software is not corrupted, then a resident boot loader is used instead of an input boot loader for this update. This may reduce the time required to update the software in the receiver / decoder. At least a portion of the resident boot loader is in the form of a machine code.

The various MPEG tables included in the MPEG bitstream that allow the receiver / decoder 2020 to locate and load the desired software will be described in the following description with reference to Figs. 11 and 12.

The MPEG bitstream comprises at least one hardware directory table 200 and a plurality of bootloader directories 300.

The directory table 200 hardware allows samozaváděcímu program 100 to locate the correct version of the input and the loader software to be introduced for a number of different versions of the receiver / decoder 2020. As shown in Figure ^2. 11, the directory table 200 hardware includes a TID 202 of value DO and TID- 0000, which values are previously stored in the EEPROM of the receiver / decoder 2020 to allow, for example, a boot loader 10 to locate and load the hardware directory table 200.

The hardware directory table 200 includes:

version number, HVERSION 206, hardware directory table 200. Wherein the version number is incremented each time there is a change in the contents of the hardware directory table 200;

0 0 · «00

0000 000 • 0 0 0 · «· 00 number, NL 208, descriptions of the input loaders contained in the hardware directory table 200;

for each 2020 receiver / decoder version:

the identifier, HVN 210, version numbers of this 5 receiver / decoder 2020;

TID 212 of the MPEG tables used for the bootloader directory 300 associated with this HVN 210, the input loader, and the software to be loaded;

redundant byte, RES 214;

the maximum size, SECTION_LEN 216, of the MPEG table section used for the bootloader directory 300 associated with this HVN 210;

size, TIME OCJT 218, time interval 15 ^- for loading a bootloader directory 300 associated with HVN 210; and a value, SGN_SIGN 220, of the boot directory signature 300 associated with HVN 210;

identifying, KEY 222, the private key used 25 to verify the hardware directory table 200; and a coded region, CIPH_AREA 224, comprising a signature

SIGN_H 226 of the hardware directory table 20Q, this signature being shifted from the beginning of the signature shift CIPH_AREA 224, SGN OFFSET 228.

The HVN 210 of the receiver / decoder has a length of 4 bytes. One byte is reserved for future use, two bytes contain the code for the hardware version number in the receiver / decoder and one byte contains the code for the receiver / decoder manufacturer. This allows the boot loader to load a version of the input boot loader that is compatible with the hardware platform of the receiver / decoder.

Upon loading the hardware directory table 200, the boot loader 100 searches this table 200 for input corresponding to the HVN 210 of the receiver / decoder 2020. If there is no match, the download is aborted. If a match occurs, the bootloader 100 identifies TID 212 from table 20QQ that has been assigned to the bootloader directory 300 associated with the receiver / decoder HVN 210, the input bootter, and the software to be loaded.

As shown in FIG. 12, each boot directory 300 associated with the receiver / decoder HVN 210 includes:

version number, LVERSION 302, directory of 300 loaders. This version number is incremented each time there is a change in the contents of the 300 boot directory;

count, NL 304, MPEG input boot tables; version number, LVERS 306, input boot loader; the number, NS 308, of the MPEG tables of the software to be loaded;

introduction;

version number, SVERS 310, of the software intended for each MPEG input boot table:

identifying, SE_ID 312, this MPEG table;

TID extension, TID EXT 314 of this MPEG table;

two redundant apartments, RES 316;

* · »· Ϊ i i i tt ♦ ····· * ·· <♦

- - · ········ ♦ ♦ ··· ·· ·· ·· ·· ·· · maximum size, SECTION_LEN 318, MPEG section of this MPEG table;

the size, TIME_OUT 320, of the time interval for loading this MPEG table; and a value, SGN_SIGN 322, of signing the MPEG table;

for each MPEG table of software to load:

identifying, SEG_ID 324, this MPEG table; A TID extension, TID_EXT 326, of this MPEG table;

two redundant apartments, RES 328;

the maximum size, SECTION_LEN 330, of the MPEG portion of this MPEG table;

the size, TIME_OUT 332, of the time interval for loading this MPEG table; and a value, SGN_SIGN 334, of signing the MPEG table;

identifying, KEY 336, the private key used to verify the bootloader directory 300; and a coded area, CIPH_AREA 338, comprising a signature of the SIGN_L 340 of the bootloader directory 300, which signature is shifted from the beginning of the signature shift CIPH_AREA 338,

SGN_OFFSET 342.

During the update, a report is generated containing, inter alia, details of each step of the write / update process, for example whether the step has been successfully completed or not, so that a step can later be identified later. »··· ·· to · in which writing / updating might fail. For example, this report includes:

HVERSION 206 hardware directory table 200;

if an error occurred during the processing of the hardware directory table 200, an indication of the type of the error and the TID extension of the MPEG table of the hardware directory table 200 in which the error occurred;

LVERSION 302 directory 300 loaders;

if an error occurred while processing the bootloader directory 300, an indication of the type of error and the TID extension of the MPEG table of the bootloader directory 300 in which the error occurred; and if an error occurred during the processing of the input loader, an indication of the type of the error and the TID extension of the MPEG table of the input loader in which the error occurred; and if there is an error during software processing to load, an indication of the type of error and the TID extension of the MPEG table of the software in which the error occurred.

The report also contains the reason why the write / update was performed, for example at the application's request, the number of detected software outages and the number of update failures.

When updating the resident software by the software present in the MPEG bitstream, at the request of the application, the receiver / decoder 2020 is arranged to compare the SVERS 310 of the software identified in the freshly loaded bootloader directory 300 to the version number of the resident software. If the SVERS 310 is later (higher), then the modules associated with the resident software are deleted. from the 69 FLASH memory, and updated software modules are loaded and installed.

The LED display 4038 on the front panel of the receiver / decoder 2020 is adapted to display messages to the users of the receiver / decoder 2020 during data loading. For example, the following four messages are specified in the parameter field stored in the FLASH memory of the receiver / decoder 2020:

An LOAD message indicating that the write / update is in a normal state, i.e. upon application request;

A NATIV message indicating that the update is in a machine state, i.e. because the resident software has been corrupted;

A message 000 indicating that the boot loader 100 is unable to write / update because it is unable to locate consistent or valid parameters (such as the frequency at which the tuner 4028 MPEG stream or PID MPEG bit stream) is set in the receiver / decoder memory 2020; and an ERRL message indicating that an error other than the error specified in connection with message 000 has occurred during the writing of the update.

As an alternative to these static messages, messages in the form of a cartoon film can be displayed on the receiver / decoder.

Steps taken, for example, to update the resident software will be described in the following with reference to FIG. 13.

· · * * · ♦ · · · <<<<<<<<<<

···

In step S101, the software stored in the receiver / decoder verifies the integrity of any resident software by performing a checksum calculation and comparing the result of that calculation with the checksum value stored in the resident software. If the two values are different, then the update continues in the machine state; if the two values are the same, or if the resident software is not located, then the update continues in its normal state.

In the machine state, it is then determined in step $ 102 whether the previous update request is still valid. If the update request from the application still persists, the request is deleted at step S103 and step S1Q2 is repeated. If no update request is in effect, it is deleted at step S104.

the previous update report and is initiated when the report is created and the new update is started. This report records the reason for the update request, that is, the replacement of the damaged software.

Following step S104, at step 105, the NATIV message is displayed on the receiver / decoder display 4Q38.

In step 516, the parameters stored in the parameter fields of the EEPROM 68 and the FLASH 69 are verified. If the tuning parameters and / or the PID parameter are not defined, then the message 4038 displays 000 and the update is aborted.

If these parameters are defined in the parameter field, the update process proceeds to step S1Q7, in which the boot loader 100 tunes the MPEG stream tuner 4028 to the transponder 2014 according to the parameters stored in the fields.

0

0 ·· *

0 • 00 0 0 * 0 0 • 00 00 Φ 0 ·

00,000 0 * 0

00 0 »00 0 • 0 · 0 0 0 0 0 0 parameters. If this tuning fails, the update is aborted and an ERRL message is displayed.

If the tuning is successful, the boot loader 100 at step S108 loads and verifies the hardware directory table 200.

If this hardware directory table 200 is not loaded before the time interval expires, or if this hardware directory table 200 is not validated (because an error occurred during boot), the update is aborted and an ERRL message is displayed.

If the download and validation is successful, the bootloader 100 searches for an HVN 210 corresponding to the version number of the receiver / decoder 2020 as defined in the parameter field.

If such an HVN is not located, the update is aborted and the ERRL message is displayed.

If this input is located, the boot loader 100 reads the TID 212 of the MPEG tables used for the boot loader directory 30 associated with this HVN 210, the boot loader, and the software to be loaded, and at step S109 loads and validates the correct boot loader directory 300. If this bootloader directory 300 is not loaded before the time interval expires, or if the bootloader directory is not validated (because an error occurred during boot), the update is aborted and an ERRL message is displayed.

If the download and validation is successful, then the boot loader 100 loads and validates the input loader from the MPEG bitstream to the RAM 72 of the receiver / decoder 2020 at step S110. If the input loader is not loaded before the time interval expires, or if the input loader is not verified. *

0 «·· 00 · (because an error occurred during boot), the update is aborted and the ERRL message is displayed.

If the input bootloader is successfully loaded and validated, the input bootloader is executed at step 5111, and in step S112, the corrupted resident software portion is erased, and the software segments to be loaded are loaded through the input bootloader, validated and written to appropriate memory locations. 69 FLASH. If the software is not loaded before the time interval expires, or if the software is not verified (because an error occurred during boot), or if an error occurred while the software was writing to FLASH 69, the update is interrupted and an ERRL message is displayed.

If the resident software is successfully updated, the report generation is stopped at step S113 and the receiver / decoder 20Q is reset to allow the next update to be performed.

In any of the steps in which the update was interrupted, the step may alternatively be re-performed in a prescribed number of times until it is successfully completed or until the time interval for performing this step has elapsed.

If the update is to be in the normal state, the bootloader 100 at step S201 determines whether an application update request is already in progress. If not, the update continues as normal. If an update request is already in progress, then the ongoing request is processed first.

In step Ξ202, the previous update report is cleared and initialization begins when a new update report is created. The report records the reason for the update, for example at the request of the application, and any update conditions that are chosen by the application.

In step 5203, it is then determined whether a resident loader is stored in the FLASH memory 69 of the receiver / decoder 2020. If 5 such a resident loader is stored in a receiver / decoder, it is determined in step S2Q4 whether the resident loader has already been executed in response to a command from the software stored in the receiver / decoder 2020. If the resident loader has already been executed, then this resident loader performs subsequent steps in the update process that would normally be performed by the boot loader 100.

If the resident boot loader is not present in memory or has not yet been executed, then a boot loader 100 is used.

It is also possible for the software in the receiver / decoder 2020 to control the 15 self-loading program 100 to continue the update process even if the resident loader is stored in the FLASH memory 69.

In step S205, the receiver / decoder display 4038 is shown

2020 LOAD.

In step S206, the parameters stored in the parameter fields of EEPROM 68 and FLASH 69 are verified. If the tuning parameters and / or the PID parameter are not defined, then the message 4038 displays 000 and the update is aborted.

If these parameters are defined in the parameter field, the update process proceeds to step S2Q7, in which the bootloader 100 or the resident loader tunes the 4028 MPEG stream tuner to the transponder 2014 according to φ ·

Parametrů φ φ • • Φ Φ Φ Φ φ φ φ parametrů φ φ φ φφ φ, parametrů parametrů parametrů parametrů parametrů parametrů parametrů parametrů, parametrů parametrů parametrů parametrů If this tuning fails, the update is aborted and an ERRL message is displayed.

If the tuning is successful, the bootloader 100 or the resident loader at step S208 loads and verifies 5 the hardware directory table 200. If this hardware directory table 200 is not loaded before the time interval expires, or if this hardware directory table 200 is not validated (because an error occurred during boot), or, depending on the option chosen by the application for,,,.

update, if a successful update has already been performed using a hardware directory table having the same HVERSION 206, the update is aborted and an ERRL message is displayed.

If the download and validation is successful and the update is enabled by the application, the boot loader 100 or the resident boot loader searches for the HVN 210 corresponding to the receiver / decoder version number 2020 as defined in the parameter field. If such an HVN is not located, the update is aborted and the ERRL message is displayed.

If this input is located, the boot loader 10 or the resident boot loader reads the TID 212 of the MPEG tables used for the boot loader directory 300 associated with the HVN 210, the boot loader and the software to be loaded, and at step S209 loads and validates the correct boot loader directory 300.

If this bootloader directory 300 is not loaded before the time interval expires, or if the bootloader directory is not validated (because an error occurred during boot), or, depending on the option selected by the application's update request, if a successful update has already been performed with feefefe Using the boot directory that has the same LVERS 306, the update is aborted and the ERRL message is displayed.

If the download and validation is successful and the update is enabled by the application, then the boot loader 100 loads and validates the input loader from the MPEG bitstream to the 72 RAM of the receiver / decoder 2020 at step S210. If the input loader is not loaded before the timeout input boot not validated (because an error occurred during boot), the update is aborted and ERRL is displayed.

If the input loader is successfully loaded and verified, the input loader is executed at step S211 and at step 5212 the version number of the SVERS 310 software in the MPEG bitstream is compared with the version number of the resident software.

If the version numbers are the same, the software is not written to FLASH 69 and the application's update request is cleared. If the version numbers are different, the resident software is cleared, and the software segments to be loaded are loaded through the input loader, verified and written to appropriate address locations in the FLASH memory 69 at step S213.

If the software is not loaded before the time interval expires, or if the software is not verified (because an error occurred during boot), or if an error occurred while the software was writing to FLASH 69, the update is interrupted and an ERRL message is displayed.

If the resident software is successfully updated, the report generation is stopped at step S114 and the receiver / decoder 2020 is reset to allow another update to be performed.

000 for a machine condition, in any of the steps in the update is interrupted, that step can be performed again until it is successfully completed.

0 0 00 0 0 ·· 0 ·

As they were alternatively

It should be understood that the present invention has been described above purely by way of example, and modifications of various details may be made within the scope of the invention.

r

Each feature described in the description and (where appropriate) in the claims and drawings may be formed independently or in any suitable combination. In the aforementioned preferred embodiments, certain features of the present invention have been implemented using computer software. However, it will be obvious to those skilled in the art that any of these features can be realized using hardware. Moreover, it should be understood that functions performed by hardware, computer software and the like are performed on or using electrical and similar signals.

Claims (5)

PATENT CLAIMS A method of introducing data into a receiver / decoder, characterized in that it comprises the steps of a receiver / decoder: receiving a bitstream including data; introducing an inserter for introducing data from the bitstream into the receiver / decoder; and loading said data from the bitstream using said loaded data loader. The method of claim 1, wherein the loaded data loader is deleted from the receiver / decoder after the data has already been loaded from the bitstream. The method of claim 1, wherein the loaded data loader is then stored in a non-volatile memory of the receiver / decoder. The method of claim 3, wherein the non-volatile memory is a flash storage medium of a receiver / decoder. A method according to any one of the preceding claims, characterized in that the loading of the data is performed by means of an established data loader. Method according to any one of the preceding claims, characterized in that only part of the data stored in the receiver / decoder is replaced by the corresponding part of the data loaded by the loaded data loader. Method according to any one of the preceding claims, characterized in that the bitstream comprises at least one The data loader and method further comprises the steps of a transmit φ φ φ ·· φφ Systému · «·· ·· system; for said at least one or each data loader, splitting the data loader into a plurality of modules; and, for said at least one or each data loader 5, splitting the data into a plurality of modules, each plurality of data modules being associated with a plurality of data loader modules. The method of claim 7, further comprising the steps of a broadcast system: for said at least one or each data loader formatting each of the modules as a respective table, wherein the tables have the same appropriate table identification (TID) and correspondingly different table identification extensions (TID-extensions); and 15 for said at least one or each plurality of data modules formatting each of the data modules as a respective table, said tables having the same appropriate TID as the tables of the data loader modules associated therewith and the correspondingly different TID extensions. 9. The method of claim 8, comprising in said loading steps loading module tables having the same TID. The method of claim 9, wherein said 25 tables have correspondingly different TID extensions other than a predetermined TID extension; and the method further comprises the step of transmitting in the broadcast system: creating an appropriate directory table for said at least one or each plurality of modules having the same TID, the at least one or each directory 30 of the table has said predetermined TID extension and this TID, φ φ φ φ φ φ φ φ φ • · φφ φφφ φφ · «and the directory table contains for each module the module name and the appropriate TID extension. The method of claim 10, further comprising the steps of a receiver / decoder: loading one of the tables having predetermined TID extensions to load a directory table; determining from the contents of a directory table a TID-extension of module tables having the same TID as a directory table; and, in said bootstrap, loading module tables having the same TID as the loaded directory table and a TID extension determined from the loaded directory table. The method of any preceding claim, further comprising the step of in a broadcast system: creating a directory table having a predetermined table identification (TID) and comprising, for each of a plurality of receiver / decoder version identifications, 20 is the appropriate TID associated with the toutc version identification. The method of claim 12, wherein the version identification includes a code for a receiver / decoder version and a code for a receiver / decoder manufacturer. A method according to claim 12 or 13 and at the same time according to claim 11, further comprising the steps of a receiver / decoder: loading said directory table having a predetermined TID; and 55 determining a version of the receiver / decoder; wherein the step of loading the directory table comprises loading one of the tables having a TID associated with a receiver / decoder version number and a predetermined TID extension. The method of any one of claims 10 to 14, further comprising the steps of a broadcast system: including in each transmitted directory table a version identification directory for that table; and in the receiver / decoder: determining whether the directory identification of the version of the currently transmitted directory table is newer than the directory identification of the version of the previously loaded directory table having the same TID as the currently transmitted directory table and, if not, the interruption of data loading. The method of any one of the preceding claims, further comprising the step of a transmission system: including in the bitstream a data version identification of the data; and 20 steps in receiver / decoder: determining whether the data identification of the version of the received data is newer than the data identification of the version of the currently stored data, and if so, performing said step of introducing data from the bitstream. o 5 A method according to any preceding claim, wherein at least a portion of the loaded data loader is in the form of code that is specific to the receiver / decoder hardware. A method according to any one of the preceding claims, further comprising the steps of a broadcast system: transmitting a second data loader included in said bitstream; and in the receiver / decoder: loading the second data loader; and loading one of said first data loader and data, said second introducing means performing loading of one of said first data loader and data 19. The method of claim 18, wherein at least a portion of the second data loader is in the form of code that is specific to the receiver / decoder hardware. 20. A receiver / decoder, comprising: a receiver for receiving a bitstream including data; memory device; and a loading means for loading from the bitstream to the storage means of the loader for loading data from the bitstream to the receiver / decoder. 21. The receiver / decoder of claim 20, further comprising means for deleting the loaded data loader from the storage means after the data has already been loaded from the bitstream. 22. The receiver / decoder of claim 20, further comprising a non-volatile memory for storing the loaded data loader after the data has already been loaded from the bitstream. 23. The receiver / decoder of claim 22, wherein the non-volatile memory is a flash storage medium of the receiver / decoder. • to · tototo * · * ·· this this this ·· tototo A receiver / decoder according to any one of claims 20 to 23, wherein the loaded data loader is adapted to perform loading of data from the bitstream. A receiver / decoder according to any one of claims 20 to 24, wherein the loaded data loader is adapted to replace only a portion of the data stored in the receiver / decoder corresponding to a portion of the data loaded by the loader. 26. A receiver / decoder according to claims 20 to 25, characterized in that it is adapted to load tables. 27. A receiver / decoder according to claim 26, wherein said loading means is arranged to load a table having a table identification (TID) and a predetermined table identification extension (TID-extension), for loading a directory table, to determine from the contents of a directory TID extension tables of module tables having the same TID as the directory table, and for loading module tables having the same TID as the TID of the loaded directory table, and TID extensions, determined from the loaded directory table, for loading said loader. 28. A receiver / decoder according to claim 26 or 28, wherein said inserter is arranged to load a directory table having a predetermined TID and comprising, for each of a plurality of receiver / decoder version identifications, a respective TID associated with said version identifier. for determining a receiver / decoder version identification, and for loading a directory table having a TID associated with a receiver / decoder version number and a predetermined TID extension. 0 · 0 0 0 • · 00 0000 0 0 0 0 00 00 00 0 0 0 0 0 0 0 0 00 00 Receiver / decoder according to claim 27 or 28, characterized in that said loading means is arranged to determine whether the version identification of the currently transmitted directory table is newer than the version identification previously loaded 5 of a directory table having the same TID as the currently transmitted directory table and, if not, to interrupt loading of said loader. A receiver / decoder according to any one of claims 20 to 29, characterized in that the data loader is in the form of a code that is specific to the hardware of the receiver / decoder. Receiver / decoder according to any one of claims 20 to 30, characterized in that said inserter is arranged to insert a second inserter included in the data. 25 included in said bit stream, for loading one of the first mentioned loader and data. 32. A transmission system comprising: means for transmitting a bit stream including at least one data loader for loading data into a data stream. A receiver / decoder and data associated with the at least one or each data loader; and means for splitting said at least one or each data loader into a plurality of modules and splitting the data associated with said at least one or each data loader into a plurality of modules for transmission by said transmission means. 33. The broadcast system of claim 32, further comprising: 30 means for formatting each of the modules of said at least one or each data loader as appropriate 9 · · · · · · - - · · 0 0 0 0 · 0 · * 00 · 0 * 000 000 00 00 0> * * tables, wherein the tables of said at least one or each data loader have the same appropriate table identification (TID) and correspondingly different table identification extensions (TID-extensions); and 5 means for formatting each of the data modules associated with said at least one or each data loader as appropriate tables, said data module tables having the same appropriate TID as the data loader module tables associated therewith and 10 different TID extensions. 34. The broadcast system of claim 33, wherein said tables have correspondingly different TID extensions other than a predetermined TID extension; and said system further comprises means for generating appropriate directory tables for said at least one or each plurality of modules having the same TID, each directory table having said TID and said predetermined TID extension, and wherein said directory includes for each module a module name and the appropriate TID extension. 35. The broadcast system of any one of claims 32 to 34, further comprising: means for creating a directory table having a predetermined table identification (TID); and 25 comprising, for each of a plurality of receiver / decoder version identifications, an appropriate TID associated with said version identifier, 36. A broadcast system as claimed in any one of claims 32 to 35, further comprising means for incorporating into each transmitted table. version identification for this table. The broadcast system of any one of claims 32 to 36, wherein said at least one or each loader is in the form of a code that is specific to the receiver / decoder hardware. A combination of a decoder receiver according to any one of claims 20 to 31 and a broadcast system according to any one of claims 32 to 37. 39. A signal comprising at least one loader for loading data to a receiver / decoder and data associated with the at least one or each loader, said at least one or each loader being divided into a plurality of modules and data associated with said at least one module. by one or each of the inserters, they are divided into the respective corresponding number of modules. 40. A method of introducing data into a receiver / decoder substantially as described herein. 41. A receiver / decoder substantially as described herein. 42. A broadcast system substantially as described herein.