MXPA00003214A - Downloading data - Google Patents

Abstract

A method of downloading data to a receiver/decoder comprises the steps, at the receiver/decoder, of:receiving a bitstream including the data;downloading a loader for loading the data from the bitstream into the receiver/decoder;and downloading said data from the bitstream using said loader.

Description

DOWNLOAD DATA This invention relates to: a method for downloading data to a receiver / decoder; • that receiver / decoder by themselves; and • a transmission system. The term "receiver / decoder" used herein may connote a receiver to receive encoded or uncoded signals, for example, television and / or radio signals, which may be broadcast or transmitted by some other element. The term may also connote a decoder to decode the received signals. The embodiments of these receivers / decoders may include an integral decoder with the receiver for decoding the received signals, for example, in a "top box", such as a decoder operating in combination with a physically separate receiver, or including this decoder functions additional, such as a web browser, a video recorder, or a television. The advent of digital transmission systems intended primarily to transmit television signals, particularly, but not exclusively, satellite television systems, has opened the possibility of using these systems for other purposes. One of these is to provide interactivity with the end user. As used herein, the term "digital transmission system" includes any transmission system for transmitting or broadcasting, for example, primarily audio-visual or multimedia digital data. Although the present invention is particularly applicable to a digital broadcast television system, the invention may also be applicable to a fixed telecommunications network for multimedia Internet applications, to a closed circuit television and so on. - One way to do this is to execute an application in the receiver / decoder, through which the television signal is received. The code for the application could be stored permanently in the receiver / decoder. However, this would be rather limiting. Preferably, the receiver / decoder should be able to download the code for a required application. In this way, more variety can be provided, and applications can be updated as required, without any action on the part of the user. In an MPEG system, the application code can be downloaded to MPEG tables transmitted in an MPEG bit stream. The term MPEG refers to the data transmission standards developed by the working group of the International Standards Organization "Motion Pictures Expert Group", and in particular, but not exclusively, the MPEG-2 standard developed for digital television applications , and stipulated in documents ISO 13818-1, ISO 13818-2, ISO 138-18-3, and ISO 13818-4. In the context of the present patent application, the term includes all variants, modifications, or developments of MPEG formats applicable to the field of digital data transmission. The software to download the MPEG tables must be stored permanently in the receiver / decoder. In order to download data, such as the application code, or an updated version of a runtime machine, complex software is required, and this software usually takes a large amount of memory. However, this software can only be used sporadically, if any, and the software can occupy such a large amount of memory that it is redundant over a long period of time. The software stored in the receiver / decoder to download data from the bitstream is commonly referred to as a "Bootstrap" loader. The Bootstrap loader is preferably adapted to download most "forms of data, including software from the bitstream for storage, for example, into the volatile memory volume of the receiver / decoder., Bootstrap loader tends to have a somewhat "basic" structure, having minimal functionality, so that all forms of software can be downloaded. The Bootstrap loader is usually stored in a ROM volume of the receiver / decoder, and can not be deleted from there. Because the Bootstrap loader can not be modified once it has been written to the ROM memory volume, processing errors that may occur if the Bootstrap loader becomes corrupted can not be corrected. In addition, Bootstrap loader functionality is "fixed" once it has been written to the ROM; it can not be updated, for example as to improve the time needed to download data from the bit stream. Therefore, software that has an improved or new structure, which can not be recognized by the Bootstrap loader, can not be downloaded from the bit stream. If a portion of the data stored in the receiver / decoder becomes corrupted, the Bootstrap loader can be used to download a complete non-corrupted version of this data. If only a very small portion of the data has been corrupted, this can result in a significant amount of time spent downloading portions of the data that have not been corrupted. The present invention seeks to solve these and other problems. In a first aspect, the present invention provides a method for downloading data to a receiver / decoder, which comprises the steps, in the receiver / decoder, of: receiving a bit stream that includes the data; download a charger to load the data from the bitstream to the receiver / decoder; and download the data from the bit stream using the downloaded data loader. In one embodiment, the downloaded data loader comprises a data loading program. At least part of the data loader, preferably most of it, or even the entire data loader, may be in the form of native code. As used herein, the term "native code" includes hardware-specific code, code that is specific to a particular hardware platform of the receiver / decoder, code that is not interpretive, and / or code that can be directly executed by a microprocessor of the receiver / decoder. Accordingly, the structure taken by a piece of native code that is to be downloaded by a receiver / decoder, will depend on the particular apparatus used in the hardware plant of that receiver / decoder. This contrasts with the "interpretive code", such as what is known as "p-code" for the applicants, which requires interpretation by the software stored in the receiver / decoder, in such a way that it can be executed by the microprocessor, and that, therefore, be functional over a wide range of hardware platforms. The data downloaded by the data loader may be in the form of native code, p code, or any other suitable form, such as data tables. By means of the above, a charger for loading the data from the bit stream is downloaded from the bit stream, and is stored in, preferably temporarily in the RAM of, the receiver / decoder. Following the download using the data downloader, of the required data, from the bit stream, the downloaded data loader is preferably deleted from the receiver / decoder. Therefore, once the downloaded data loader has served its purpose, the storage capacity of the RAM is effectively increased during the time when the data download is not required. Of course, it is not essential to suppress the downloaded data loader once you have downloaded all the required data from the bit stream. Conversely, the data loading can subsequently be stored in the non-volatile memory of the receiver / decoder, such as a volume of Flash memory. This can make it possible for the receiver / decoder to download additional data using the stored data loader, without having to reload the data loader from the bitstream, thus decreasing the time needed to download that data. Therefore, a plurality of different data chargers can be stored at any time in the receiver / decoder. Because a data load written specifically for the download of a particular data item can be downloaded from the bit stream as required by the receiver / decoder, better receiver / decoder functionality can be provided, because data can be downloaded with an updated or revised structure, which is different from the data structure that can be downloaded by the loaded Bootstrap, and can be stored in the receiver / decoder . In a preferred embodiment, the download of the data is done by the downloaded data loader. Accordingly, for data download, the Bootstrap loader is effectively replaced in a temporary manner by the downloaded data loader, thus making it possible for the receiver / decoder to use an updated or otherwise improved data loader. Preferably, a portion of only the data stored in the receiver / decoder is replaced by a corresponding portion of data downloaded by the downloaded data loading. For example, if a portion of the stored data becomes corrupted or anachronistic, the receiver / decoder may download a non-corrupted or updated version of that portion of the data only, "patching" the loaded data downloaded the downloaded portion. of data in the stored data when appropriate. As a result, the downloaded data loader does not download an 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, because the downloading of non-corrupt data portions is not required. In an alternative embodiment, a portion of data stored in the receiver / decoder is replaced by a corresponding portion of, for example, a section of data transmitted with the downloaded data loader. The bitstream may comprise at least one data loader, and in accordance with the above, the method may further comprise the steps, in a transmission system., Of: for the or each data loader, split the data loader into a plurality of modules; and for the or each data loader, dividing the data into a respective plurality of modules, each plurality of data modules being associated with a respective plurality of data loader modules. Accordingly, the bit stream may include a plurality of associated data and data loaders. This can make it possible for receivers / decoders that have different hardware platforms to download the appropriate versions of the data loader and the associated data. The data, such as an application, can conveniently be made up of a number of modules, which can be downloaded, and if it is appropriate to execute, as required. The method may further comprise the steps, in the transmission system, of: for the or each data loader, format each of the modules as a respective table, the tables having the same respective table identification ("TID"), and respective different table identification extensions ("extensions-TID"); and for the or each plurality of data modules, format each of the data modules as a respective table, the tables having the same respective TID as the tables of the data-loading modules associated with them, and different extensions-TID respective. It is preferred that an MPEG protocol be used, and if so, the download steps may comprise downloading MPEG tables in module. The tables may have respective different TID extensions, which are not a previously determined TID extension; and the method may further comprise the step in the transmission system, of generating a respective directory table for the or each plurality of modules having the same TID, the or each directory table having the previously determined TID-extension and that TID, containing the directory table for each of the modules, a name of that module and the respective TID-extension. The method may further comprise the steps, in the receiver / decoder, of: downloading one of the tables having the previously determined TID extension, to download a directory table; determine, from the contents of the directory table, the TID extensions of the tables in module that have the same TID as the directory table; and in the download steps, download the tables in module that have the same TID as that of the downloaded directory table, and extensions-TID determined from the directory table downloaded. With these features, the directory table can be easily identified, because it has a particular extension-TID, and once it has been downloaded, it can make it possible for the receiver / decoder to identify the tables in the data loader module from of their respective TID extensions. The method may further comprise the step, in the transmission system, of generating a directory table having a previously determined table identification ("TID"), and containing, for each of a plurality of version identifications of a receiver / decoder, a respective TID associated with that version identification. If so, the method may further comprise the steps, in the receiver / decoder, of: downloading the directory table having the previously determined TID; and determining the version identification of the receiver / decoder; wherein the step of downloading a directory table comprises downloading that of the tables having a TID associated with the receiver / decoder version number, and the previously determined TID-extension. - Preferably, the identification of the version includes a code assigned to the manufacturer of the receiver / decoder, and a code assigned to the version of the receiver / decoder. It is expected that the receivers / decoders can be designated and manufactured by several different manufacturers. Each manufacturer can produce a number of different versions of the receiver / decoder. Therefore, the receivers / decoders can have several different hardware designs, although of course, all will conform to the same functional specification. Therefore, it is important that the data, such as an application, behave in the same way in each receiver / decoder, and that a receiver / decoder executes all the applications in the same correct way. In order to ensure that the data is compatible with a particular version of a receiver / decoder, the bit stream can include a data loader, and data for each version identifier of the receiver / decoder, and that the directory table having the TID previously determined, it can make it possible to easily identify the TID of the data loader modules, and the data for each version identification of the receiver / decoder. Preferably, the method further comprises the steps, in the transmission system, of: including in each transmitted directory table, a directory version identification for the same; and in the receiver / decoder: - determining whether the directory version identification of a currently transmitted directory table is more recent than the identification of the directory version of a previously downloaded directory table having the same TID as the table directory currently transmitted, and if not, abort the data download. The Bootstrap loader can be instructed, for example, by an application, to periodically download the directory table, in order to determine whether the identification of the directory version of the previously downloaded directory table has changed. This can ensure that the receiver / decoder immediately downloads any updated data from the bit stream. In order to avoid overwriting the resident data stored in the receiver / decoder with identical received data, an application requesting the update of the resident data may choose to abort the data download if a directory table is the same as that used in an update previous of the resident data. Preferably, at least one of the tables in module is formatted as a plurality of sections that are transmitted separately in the bit stream, each section containing, in a previously determined portion thereof, an identification of that section. in the table, and an indication of the number of sections in a table. The method may further comprise the step, in the transmission system, of cyclically transmitting the tables in a stream of bits. The method may further comprise the step, in a transmission system, of: including, in the bit stream, a data version version of the data; and in the receiver / decoder, the step of: determining whether the data version identification of the received data is more recent than the data version identification of the data currently stored, and if so, performing this step of Download the data from the bitstream. With this feature, the download can be aborted before deleting the resident software and / or starting to download the received data, if the data version identification of the received data is the same as that of the resident data stored in the receiver / decoder. Preferably, the step of determining whether the data version identification of the received data is more recent than the data version identification of the currently stored data, is conducted after determining that the data version identification of a data table The currently transmitted directory is more recent than the data version identification of a previously downloaded directory table that has the same TID as the directory table currently transmitted. In another preferred embodiment, the downloaded data loader modifies the means stored in the receiver / decoder to download the data loader, in such a way that the data can be downloaded by the modified download means. Accordingly, the download means can be conveniently modified by a data loader downloaded from the bit stream, such that, for example, data with a different structure can be downloaded by the download means. Preferably, the method comprises the steps, in a transmission system, of: transmitting a second data loader included in the bit stream; and in the receiver / decoder, of; : download the second data loader; and download one of the aforementioned data loader and data; making the download medium transmitted the download of one of the first mentioned data loader and the data. In one embodiment, the second data loader is provided by another data load program, at least part of the second loader preferably being in the form of native code. This can make it possible to eliminate the download of a data loader by using a different data loader previously downloaded from the bit stream. Therefore, it is not necessary to download a data loader from the bit stream each time new or revised data is to be downloaded, if a previously downloaded data loader can download the data as efficiently as the data loader. This can significantly reduce the time needed to download new or revised data from the bit stream. The second data loader can provide better functionality over the first mentioned data loader, for example, the second data loader can download computer programs. In a second aspect, the present invention provides a receiver / decoder comprising: a receiver for receiving a bitstream including data; a storage element, such as a memory; and a download element, for downloading from the bitstream to the storage element, a charger for charging the data from the bitstream to the receiver / decoder. In a preferred embodiment, the discharge element is provided by a rebound program stored in the receiver / decoder. The receiver / decoder may further comprise an element for suppressing the data loader downloaded from the storage element, after the data has been downloaded from the bit stream. The deletion element may be provided by a central processor and the associated software stored in the receiver / decoder. The receiver / decoder can be arranged to download tables. If so, the download element can be configured to download a table that has a table identification ("TID"), and a previously determined table identification extension ("TID extension"), to download a directory table, in order to determine, from the contents of the directory table, the TID extensions of the tables in module that have the same TID as the directory table, and to download the tables in module that have the same TID as that of the downloaded directory table, and the TID-extensions determined from the downloaded directory table, to download that loader. The download element can be configured to download a directory table having a previously determined TID, and containing, for each of a plurality of version identifications of a receiver / decoder, a respective TID associated with that version identification, in order to determine the version identification of the receiver / decoder, and to download a directory table having a TID associated with the receiver / decoder version number, and the previously determined TID-extension. In a preferred embodiment, the download element is configured to determine whether a version identification of a currently transmitted directory table is more recent than the version identification of a previously downloaded directory table having the same TID as the directory table currently transmitted, and if not, abort the download of that charger. The receiver / decoder may further comprise a parallel port and / or a serial port configured to receive formatted data such as at least one table. Preferably, the download element is configured to download a second data loader included in the bitstream to download one of the first-mentioned data loader and data. In a third aspect, the present invention provides a transmission system comprising: an element, such as a transmitter, for transmitting a bit stream including the native code, comprising at least one data loader for loading the data in a receiver / decoder, and the data associated with the or each data loader; and an element, such as a data server, for dividing the or each data loader into a plurality of modules, and dividing the data associated with the or each data loader into a respective plurality of modules to be transmitted by the data element. transmission.

Preferably, the transmission system further comprises: an element for formatting each of the modules of the or each data loader as a respective table, the tables of the or each data loader having the same respective table identification ("TID") , and respective different table identification extensions ("extensions-TID"); and an element for formatting each of the data modules associated with the or each data loader as a respective table, the tables of the data modules having the same respective TID as the tables of the data loader modules associated with the data modules. same, and respective different TID extensions. The formatting element can conveniently be provided by the data server. The tables may have respective different TID extensions, which are not a previously determined TID extension, and the system may further comprise an element for generating a respective directory table for the or each plurality of modules having the same TID, having each directory table that TID and the extension-TID previously determined, containing the directory for each of the modules, a name of that module and the respective TID-extension. The transmission system may further comprise: an element for generating a directory table having a previously determined table identification ("TID"), and containing, for each of a plurality of version identifications of a receiver / decoder, a respective TID associated with that version identification. The transmission system may further comprise an element to include, in each transmitted table, a version identification for the same. Each of the aforementioned elements can conveniently be provided by the data server. A fourth aspect of the present invention provides a combination of a receiver / decoder as described above, and a transmission system as described above. A fifth aspect of the present invention provides a signal comprising at least one loader for loading data in a receiver / decoder, and data associated with the or each data loader, the or each data loader being divided into a plurality of modules, and the data being associated with the or each data loader divided into a respective plurality of modules. All features of the aspect of the method of the invention can be applied to the apparatus and signal aspects, as appropriate, and vice versa.

The preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which: Figure 1 shows the overall architecture of a digital television system. Figure 2 shows the architecture of an interactive system of the digital television system of Figure 1. Figure 3 is a schematic diagram of the interfaces of a receiver / decoder that is part of the system of Figures 1 and 2. Figure 4 It is a schematic diagram of a remote controller used in the digital television system. Figure 5 shows the configuration of the files inside a module downloaded into the memory of an interactive receiver / decoder. Figure 6 illustrates an interrelation between a number of components of an MPEG stream. Figure 7 illustrates the manner in which an application of modules / tables can be formed, which in turn can be formed of sections. Figure 8 illustrates the authentication of an MPEG table. Figure 9 illustrates different areas of memory in a receiver / decoder of the television system. Figure 10 illustrates a field of parameters.

Figure 11 illustrates a hardware directory table. Figure 12 illustrates a directory table of the loader. Figure 13 illustrates the procedure for downloading data. An overview of a digital television system 1000 is shown in Figure 1. The digital television system 1000 includes a mostly conventional digital television system 2000 which uses the known MPEG-2 compression system to transmit compressed digital signals. In more detail, the 2002 MPEG-2 compressor in a transmission center receives a stream of digital signals (usually a stream of video signals). The compressor 2002 is connected to a multiplexer and a mixer 2004 by the link 2006. The multiplexer 2004 receives a plurality of additional input signals, assembles one or more transport streams, and transmits the compressed digital signals to a transmitter 2008 of the center of transmission through the 2010 link, which of course, can take a wide variety of forms, including telecommunication links. The transmitter 2008 transmits electromagnetic signals via the uplink 2012, to a satellite transponder 2014, where they are processed electronically and transmitted by means of the notional downlink 2016, to the land receiver 2018, conventionally in the form of a dish possessed or rented by the end user. The signals received by the receiver 2018 are transmitted to an integrated receiver / decoder 2020 owned or rented by the end user, and connected to the end user's television set 2022. The receiver / decoder 2020 decodes the compressed MPEG-2 signal into a signal of television for the television set 2022. A conditional access system 3000 is connected to the mutiplexer 2004 and the receiver / decoder 2020, and is located partially in the transmission center, and partially in the decoder. This makes it possible for the end user to have access to digital television transmissions from one or more transmission providers. A smart card can be inserted, which can decode the messages related to the commercial offers (ie, one or more television programs sold by the transmission provider), in the receiver / decoder 2020. Using the decoder 2020 and the smart card , the end user can buy commercial offers either in a subscription mode, or in a pay per view mode. An interactive system 4000, also connected to the multiplexer 2004 and the receiver / decoder 2020, and again partially located in the transmission center and partially in the decoder, makes it possible for the end user to interact with different applications by means of a back channel in Figure 2 shows the general architecture of the interactive television system 4000 of the digital television system 1000. For example, the interaction system 4000 allows an end user to buy catalog items on the screen, check the local news and Weather maps on demand, and play games through your television set. Interactive system 4000 comprises, in overview, four main elements: • an authoring tool 4004 in the transmission center or elsewhere, to enable a transmission provider to create, develop, decode, and test applications; • an application and data server 4006, in the transmission center, connected to the authoring tool 4004, to enable a transmission provider to prepare, authenticate, and format the applications and data to be delivered to the multiplexer and the mixer 2004, to_ insert into the transport stream MPEG-2 (normally the private section thereof), to be transmitted to the end user; • a virtual machine intended as a runtime machine (RTE) 4008, which is an executable code installed in the receiver / decoder 2020 owned or rented by the end user, to enable an end user to receive, authenticate, decompress, and load the applications in the working memory of the decoder 2020 for execution. Machine 4008 also executes resident applications for general purposes. The machine 4008 is independent of the hardware and operating system; Y _ • a modem retrace channel 4002 between the receiver / decoder 2020 and the application and data server 4006, to enable signals that instruct the server 4006 to insert 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 different devices contained in it. The applications are represented on the machine 4008 as "resource files". A "module" is a set of resource and data files. A "memory volume" of the receiver / decoder is a storage space for the modules. The modules can be downloaded to the receiver / decoder 2020 from the MPEG-2 transport stream. Physical interfaces of the receiver / decoder 2020 are used to download data. With reference to Figure 3, the decoder 2020 contains, for example, six discharge devices; the MPEG 4028 flow tuner, the 4030 serial interface, the 4032 parallel interface, the 4034 modem, and two 4036 card readers. The 2020 recceptor / decoder can also include a 4038 visual display. For the purposes of this Descriptive memo, an application is a piece of computer code for controlling high-level preference functions of the receiver / decoder 2020. For example, when the end user places the focus of a remote controller 2026 (as shown in greater detail in the Figure 4) on a button object that can be seen on the screen of the television set 2022, and press the validation key, the sequence of instructions associated with the button is executed. An interactive application proposes menus and executes commands at the request of the end user, and provides data related to the purpose of the application. The applications can be resident applications, that is, they can be stored in the ROM (or FLASH or other non-volatile memory) of the receiver / decoder 2020, or they can be transmitted and downloaded into the RAM (or FLASH) of the decoder 2020. The examples of the applications are: • a startup application. The receiver / decoder 2020 is equipped with a resident start application which is an adaptive collection of modules (this term being defined in more detail hereinafter), which makes it possible for the receiver / decoder 2020 to be immediately operational in the MPEG-2 environment. The application provides nuclear characteristics that can be modified by the transmission provider if required. It also provides an interface between resident applications and downloaded applications. • A Start Application. The boot application allows any application, whether downloaded or resident, to run on the receiver / decoder 2020. This application acts as a bootstrap executed when a service arrives, in order to start the application. The boot is downloaded to RAM, and therefore, can be easily updated. It can be configured in such a way that the interactive applications available on each channel can be selected and executed, either immediately after downloading, or after a previous load. In the case of pre-loading, the application is loaded into the 2024 memory, and activated by the start-up when required. • A Program Guide. The program guide is an interactive application that gives complete information about programming. For example, you can give information about, say, one-week television programs provided on each channel of a digital television package. By pressing a key on the remote controller 2026, the end user has access to an additional screen, superimposed on the event shown on the television set 2022 screen.

This additional screen is a search engine that gives information about the current and next events of each channel of the digital television package. By pressing another key on the 2026 remote controller, the end user has access to an application that displays a list of information about events over a week. The end user can also search and select events with simple criteria and made to measure. The end user can also have direct access to a selected channel. - • An Application for Pay Per View. The pay per view application is an interactive service available on each PPV channel of the digital television package in conjunction with the conditional access system 3000. The end user can access the application using a TV guide or a channel search engine. Additionally, the application starts automatically as soon as a PPV event is detected on the PPV channel. The end user can then buy the current event, either through his daughter 3020 smart card, or through the 3022 communication server (using a modem, a telephone, and DTMF, MINITEL, or similar codes). The application may be resident in the ROM of the receiver / decoder 2020, or it may be downloaded into the RAM of the receiver / decoder 2020. • An Internet Search Engine Application. In an example of the Internet browser application, user instructions are entered, such as a request to view a web page that has a particular URL, using the remote controller 2026, and sent via the back channel in modem 4002 to the application server and data 4006. Then the appropriate web page is included in the transmissions from the transmission center, it is received by the receiver / decoder 2020 through the uplink 2012, the transponder 2014-, and the downlink 2016, and it is displayed on the television 2022. The applications are stored in the memory locations of the receiver / decoder 2020, and are represented as resource files. The resource files comprise files of graphical object description units, variable block unit files, instruction sequence files, application files, and data files. The graphic object description unit files describe the screens, the man-machine interface of the application. Variable block units files describe the data structures managed by the application. The instruction sequence files describe the processing operations of the applications. The application files provide the entry points for the applications. Applications made in this way can use data files, such as icon library files, image files, character type files, color table files, and ASCII text files. An interactive application can also obtain data online by making entries and / or outputs. The machine 4008 only loads in its memory those resource files that it needs in a given moment. These resource files are read from the graphical object description unit files, instruction sequence files, and application files; the variable block drive files are stored in the memory immediately after a call for a procedure to download modules, and remain secured there until a specific call is made for a procedure to download the modules. With reference to Figure 5, a module 4010, such as a tele-shopping module, is a set of resource and data files comprising the follg: a single application file 4012; an indeterminate number of units of description units of graphical objects 4014; an undetermined number of files of variable block units 4016; an indeterminate number of 4018 instruction sequence files; and where appropriate, 4020 data files, such as icon library files, image files, character type files, color table files, and ASCII text files. The concept of the 4010 modules, together with the concept of downloading small pieces of code, allows the easy evolution of the applications. These can be downloaded to the permanent FLASH memory of the decoder 2020 as resident software, or they can be transmitted in order to be downloaded into the RAM of the decoder 2020 only when they are needed by the end user. In the case of the MPEG stream, a 4010 module is transported in a single MPEG table. In the case of modules transmitted to the MPEG 4028 tuner, the MPEG-2 long format is used, with a long header and a CRC code. This is also the case with the other five interfaces (the 4030 serial interface, the 4032 parallel interface, the 4034 modem, and two 4036 card readers), except that the "short" MPEG-2 format with a header is used. shorter, and CRC is not used. Referring in particular to Figure 6, as is known, the MPEG-2 bit stream includes a program access table ("PAT") 10 having a packet identification ("PID") of 0. The PAT contains references to the PIDs of the program map tables ("PMTs") 12 of a number of programs. Each PMT contains a reference to the PIDs of the currents of the MPEG 14 audio tables and the MPEG 16 video tables for that program. A packet that has a PID of zero, which is the program access table 10, provides the entry point for all MPEG access. In order to download applications and data for them, two new stream types are defined, and the relevant PMT also contains references to the PIDs of the streams of the MPEG 18 application tables (or sections of them) and the data tables MPEG 20 (or sections of them). Referring to Figure 7, in order to download an application 22, the application is divided into modules 24, each formed by an MPEG table, some of which are formed by a single section 18, and others of which are they can be formed by a plurality of sections 18. A typical section 18 has a header 26, which includes a byte table identification ("TID") 28, the section number 30 of that section in the table, in total number 32 of sections in that table, and a two-byte TID extension 34. Each section also includes a data part 36 and a CRC 38. For a particular module / table 24, all sections 18 < ? form that table 24 have the same TID 28 and the same extension-TID 34. For a particular application 22, all the tables 24 that form that application 22 have the same TID 28, but different respective TID-extensions.

The authentication of an MPEG table will now be described with reference to Figure 8. Table 40 includes the data 42 (typically comprising the header 26, the TID 28, the extension-TID 34, and the data part 36) an identifi -Keyname 44 and an encrypted area 46. The key identification 44 comprises an identification of a byte of a particular private key, to be used for the purpose of cryptically encoding the block. The encrypted area 46 comprises a block of 96 bytes of data. The first byte 48 is zero. A signature of 16 bytes 50 starts at a phase shift of typically between 0 and 31 bytes after the first byte. The signature 50 is produced using the signature generation process MD5 known on the data 42. False data 52 is inserted between the first byte and the signature 50, and the block is cryptically encoded using a known cryptic encoding process, and the private key to which the key identification 44 corresponds. If a plurality of MPEG tables are going to be authenticated, then a directory is included that lists the names of the tables and the signatures of those tables in the bearer signal. In the case of the MPEG stream, this directory is transported in a single MPEG table, which normally has a TID-extension of zero. The directory table is authenticated with the mechanism described above. Once the directory has been downloaded from the bearer signal, it is possible for the application to download one or more of the MPEG tables listed in the directory. The operation of the receiver / decoder 2020 will now be described, to deal with the signatures and the cryptic decoding during the download of an application. Referring to Figure 9, the receiver / decoder 2020 includes the EEPROM 68, FLASH 69, ROM 70, and RAM 72. The EEPROM 68 includes a protected region 74 that is used by the virtual machine, and where it can only write the virtual machine (and not a normal application). The protected region 74 includes a key validation bitmap 76, 16 or 256 bits, and a bitmap 80, 32 bits. The ROM 70 includes, in one embodiment, 16 public keys 82, in which case, a 16-bit key validation bitmap is used, and in another embodiment, 256 public keys, in which case a map of the code is used. 256-bit key validation bits. Public keys are identified by their physical locations in ROM 70 or alternatively, they can be included in a look-up table, whereby a particular key identification will produce the corresponding public key. The RAM 72 can be used to store a temporary key 84. When an application is to be downloaded, first the directory table having the previously determined TID for that application is downloaded, and a TID-extension of zero. The key identification 44 is then extracted from the directory table, and a verification of the key validation bitmap 76 in the protected memory 74 is made, of which the bit corresponding to the extracted key identification 44 is set. If this is not the case, then an additional download of the application is aborted. However, if the appropriate key is established, then a public key 82 is selected from the ROM 70 corresponding to the extracted key identification 44. Then the selected public key and a known cryptic decoding process are used to cryptically decode the key. cryptically encoded block 46 in directory table 40, to produce a cryptically decoded block. The offset in the offset bitmap 80 in the protected memory 74 is checked, or if more than one offset bit is set, each out-of-phase bit is checked, and 16 bytes of data are extracted from the cryptically decoded block. , starting with the revised phase shift. For the or each revised phase shift, the 16 bytes are treated as the signature transmitted with the directory table 40. The signature of the entries in the directory 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 cryptically decoded block. If the two signatures for the or each revised phase offset do not match, then an additional download of the application is aborted. However, if one of the signatures matches, then you can proceed with the download of the modules specified in directory 42. As mentioned above, in order to download a particular module, you get the TID extension for that module from directory 42, the MPEG table 24, or sections 18, with the same TID as the directory table, and with the TID extension obtained, is downloaded. Once the MPEG table has been downloaded into module, the receiver / decoder 2020 calculates the signature of the download table using the known MD5 process, and then compares that calculated signature with the signature contained in the directory entry. If the signatures agree, then the module is accepted, but if they do not agree, then the module is rejected. In this way all the modules of the application can be downloaded in the manner specified above, and the application can be executed by the receiver / decoder 2020. The data downloading in the receiver / decoder 2020 will now be described in greater detail with reference to the Figures 9 to 13. The receiver / decoder 2020 includes the loading 100, referred to as a "Bootstrap" loader 100, which is used primarily to download a load to download software, such as the manufacturer's firmware, the runtime machine 4008, and the applications, present in the MPEG data stream, to be stored in the FLASH memory 69 of the receiver / decoder 2020. The Bootstrap 100 loader is stored in the FLASH memory 69 of the receiver / decoder 2020, and can not normally be erased therefrom. . The Bootstrap 100 loader operates under control of the hardware of the receiver / decoder 2020 and of the software stored therein. It is possible to write / update the software stored in the receiver / decoder: • at the request of the user of the receiver / decoder 2020; • at the request of an application stored in the receiver / decoder 2020; or • if the software previously stored in the receiver / decoder 2020 (referred to as "resident" solfware) has been corrupted. To determine if the resident software has been corrupted, the software written by the manufacturer of the receiver / decoder 2020, and stored therein, calculates a checksum on the data of the resident software, and compares it with a checksum written in - the resident software. If the two values of the checksum are not equal, the resident software has been corrupted. The FLASH memory 69 and the EEPROM 68 of the receiver / decoder 2020 contain parameters that make it possible for the Bootstrap loader 100 to download a loader in the form of native code from the bit stream. Parameters can be stored in the Bootstrap 100 loader itself, that is, in the FLASH memory 69, or in the EEPROM 68. Examples of the parameters that can be stored in the FLASH memory 69 include: • the frequency at which the transponde -dor 2014; • different characteristics of the signal that will be demodulated by the receiver / decoder 2020; • the PID on which the software will be transmitted; • a set of public keys (preferably three keys) to be used during authentication; • a time out for loading directory tables from the MPEG bit stream; • the Bootstrap 100 loader version number; AND • a "checksum" parameter of N bytes, used to verify the integrity of the resident software, whose value is determined by the manufacturer of the receiver / decoder 2020. Examples of the parameters stored in the EEPROM 68, and which can be being updated by an application stored in the receiver / decoder 2020, include: • additional characteristics of the signal to be demodulated by the receiver / decoder 2020; • parameters that make it possible to compile a report on a write / update. These parameters are stored in the respective parameter fields in the FLASH memory 69 or in the EEPROM 68. With reference to Figure 10, each parameter field 400 includes a section 402, a reserved byte 404, a set of parameters 406, and a check sum of the Longitudinal Redundancy Code (LRC) 408. The checksum comprises the CRL 410, which is an OR (ó) exclusive of the preceding bytes of the parameter field 400, and NCRL 412, which is the complement of ls of the CRL 410. If an application stored in the receiver / decoder 2020 wants to update the parameters stored in a parameter field, for example, update a PID, it calculates an LRC checksum for the field, and compares it with the sum of LRC 410 check stored in the field. If the two values agree, then the parameter field update is enabled; otherwise, the update of the parameter field is aborted. The MPEG bit stream, which includes the data to be downloaded to the receiver / decoder 2020, carries native code, at least part of which includes an additional charger, referred to as an "In-the-Stream" charger. The Bootstrap 100 loader unloads the charger within the current of the MPEG bit stream to the RAM 72 of the receiver / decoder 2020, and it is this charger within the stream that downloads the data from the MPEG bit stream, for example, in order to update the resident software. The software downloaded to the FLASH memory 69 of the receiver / decoder 2020 may also contain a charger, referred to as a "resident" charger. This charger should be able to perform at least one write / update of the software from the MPEG bitstream, and can offer other features, such as updates from local ports, and can allow the video and audio data to be decoded in the MPEG bitstream. The Resident charger is loaded from the bitstream at the request of an application, for example, to complement the charger that performs the download of the charger Within the Current, or to load data from the bit stream. For example, if an application stored in the receiver / decoder 2020 requests write / update, and the resident software is not corrupted, the loaded Resident is used to perform the update, instead of a charger within the current. This can reduce the time needed to update the software on the receiver / decoder. At least part of the Resident Loader is in the form of native code. The different MPEG tables included in the MPEG bitstream, which allow a receiver / decoder 2020 to locate and download the required software, will now be described with reference to Figures 11 and 12. The MPEG bitstream includes at least one table of hardware directory 200, and a plurality of 300 charger directories. A hardware directory 200 table makes it possible for the Bootstrap 100 loader to locate the correct versions of the In-the-Stream charger, and the software to be downloaded for a number of different versions. of the receiver / decoder 2020. With reference to Figure 11, a hardware directory table 200 includes a DO TID 202 and a TID extension 204 of 0000, the values of which were previously stored in the EEPROM 68 of the receiver / decoder 2020_ for make it possible, for example, for the Bootstrap 100 loader to locate and download the hardware 200 directory table. The directory table of the hard ware 200 includes: a version number, HVERSION 206, of the hardware directory 200. The version number is incremented each time there is a change in the contents of the hardware directory 200; the number NL 208, of the descriptions of the charger within the stream, contained in the hardware directory 200; for each version of the receiver / decoder 2020: an identifier, HVN 210, of a version number of this receiver / decoder 2020; TID 212 of the MPEG tables used for the '. 300 charger directory associated with that HVN 210, the Charger Within the Stream, and the software to be downloaded; one redundant byte, RES 214; a maximum size, LEN SECTION 216, of a section of the MPEG table used for the loader directory 300 associated with that HVN 210; a TIME_FLOOR value 218, of the time out for loading the loader directory 300 associated with the HVTST 210; and the value, SGN_SIGN 220 of the loader directory signature associated with the HVN 210; an identification, KEY 222, of the private key used for the authentication of the hardware directory 200; and an encrypted area, CIF_AREA 224 containing the signature SIGN_H 226 of the hardware directory 200, the signature being offset from the beginning of the CIF_AREA 224 by a signature offset SGN_DESFASING 228. The HVN 210 of the receiver / decoder is 4 bytes of length. A byte is reserved for future use, and two bytes include a code for the hardware version number in the receiver / decoder, and a byte includes a code for the manufacturer rel receiver / decoder. This makes it possible for the Bootstrap loader to download the version of the In-Stream charger that is compatible with the hardware platform of the receiver / decoder. Having downloaded the hardware directory table 200, the Bootstrap 100 loader searches for the table 200, to find a corresponding input with the HVN 210 of the receiver / decoder 2020. If a match is not presented, the download is aborted. If a match is presented, the Bootstrap 100 loader identifies, from Table 200, the TID 212 that has been assigned to the directory of the loader 300 associated with the HVN 210 of the receiver / decoder 2020, the Loader Within the Stream, and the software that will be downloaded. With reference to Figure 12, each loader directory 300 associated with the HVN 210 of the receiver / decoder 2020 includes: a version number LVERSION 302, of the loader directory 300. The version number is incremented each time there is a change in the contents of the 300 loader directory; the number NL 304, from the MPEG tables of the charger Inside the Current; the version number LVERS 306, of the charger Adentro de la Corriente; the number NS 308, of the MPEG tables of the software to be downloaded; the version number, SVERS 310, of the software to be downloaded; for each MPEG table of the magazine Inside the Stream: the identification, SEG_ID 312 of that MPEG table; the TID extension, TID EXT 314, of that table MPEG; two redundant bytes, RES 316; a maximum size, SECTION LEN 318, of an MPEG section of that MPEG table; a value TIME_FORE 312, out of time for loading that MPEG table; and the value, SGN_SIGN 322, of the signature of that table MPEG; for each MPEG table in the software: the identification, SEG ID 324, of that table MPEG; the TID extension, TID EXT 326, of that table MPEG; two redundant bytes, RES 328; a maximum size, SECTION LEN 330, of an MPEG section of that MPEG table; a TIME_FORE value 332 of the time out for loading that MPEG table; and the value, SGN_SIGN 334, of the signature of that MPEG table; an identification, KEY 336, of the private key used for the authentication of the loader directory 300; and an encrypted area, CIF_AREA 338, which contains the signature SIGN_L 340 of the directory of the loader 300, the signature being offset from the beginning of the CIF_AREA 338 by a signature offset SGN_DESFASAMIENTO 342. During the update, a report is compiled, which contains, among other things, the details about each step of the process of writing / updating, for example, if the step was successful or not, so that the step in which the writing / updating may have failed may be identified later. For example, the report includes: HVERSION 206 of the hardware 200 directory; if an error occurred during processing of the hardware directory 200, an indication of the type of error and the TID extension of the MPEG table of the hardware directory 200 in which the error occurred; LVERSION 302 of the loader directory; if an error occurred during the processing of the directory of the loader 300, an indication- of the type of error and the extension-TID of the MPEG table of the loader directory 300 in which the error occurred; and if an error has occurred during the processing of the LOADER IN THE CURRENT, an indication of the type of error and the extension-TID of the MPEG table of the loader In the Current in which the error occurred; and if an error has occurred during software processing, 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 includes the reason for the writing / updating, for example, at the request of an application, the number of software inconsistencies detected, and the number of refinement failures. When the resident software is updated with the software present in the MPEG bitstream at the request of an application, the receiver / decoder 2020 is arranged to compare the SVERS 310 of the software identified in the directory table of the newly downloaded charger 300, with the version number of the resident software. If the SVERS 310 is later, then the modules associated with the resident software of the FLASH memory 69 are deleted, and the updated software modules are downloaded and mounted. A visual display of the light emitting diode of the front panel 4038 of the receiver / decoder 2020 is adapted to display messages to the user of the receiver / decoder 2020 during data download. For example, the following four messages are specified in a parameter field stored in the FLASH memory 69 of the receiver / decoder 2020: • a "LOAD" message, indicating that writing / updating is proceeding in a "normal" state is say, at the request of an application; • a "NATIV" message, indicating that the update is proceeding in a "native" state, that is, because the resident software has been corrupted; • a "000" message, indicating that the Bootstrap 100 loader is unable to perform the write / update, because it can not locate consistent or valid parameters (such as the frequency at which the MPEG 4028 tuner will be set, or the PID of the MPEG-bit stream) in the receiver / decoder memory 2020; and • an "ERRL" message, indicating that an error has occurred, different from those specified with reference to the OOO message, during writing / updating. As an alternative to static messages, messages can be displayed in the form of an animated caricature in the receiver / decoder. The steps in, for example, updating the resident software will now be described, with reference to Figure 13. In step S101, the software stored in the receiver / decoder verifies the integrity of any resident software by performing the calculation of the sum of verification, and comparing the result of that calculation with the value of the checksum stored in the resident software. If the two values are different, then the update continues in the native state; if the two values are the same, or if the resident software is not located, then the update continues in the normal state. In this native state, it is then determined whether the previous update request is still pending in step S102. If this update request is pending-from an application, that request is deleted in step S103, and step S102 is repeated. If this update request is not yet pending, the report of the previous update is deleted in step S104, and initialized in order to start the registration of this update. The report records the reason for the update request, that is, to replace the corrupted software. Following step S104, the message NATIV is displayed on the visual display 4038 of receiver / decoder 2020 in step S105. In step S106, the parameters stored in the EEPROM and memory parameter fields are verified.

FLASH 69. If the tuning parameters and / or the PID parameter are not defined, the visual display 4038 is made to display the 000 message, and the update is aborted. If these parameters are defined in the parameter field, the update proceeds to step S107, wherein the Bootstrap 100 loader tunes the MPEG 4028 tuner to the 2014 transponder, according to the parameters stored in the parameter fields. If the tuning fails, the update is aborted, and the ERRL message is displayed. If tuning is successful, the Bootstrap 100 loader downloads and authenticates the hardware directory 200 in step S108. If the hardware directory 200 is not downloaded before the out time is reached, or if the hardware directory 200 is not authenticated (due to an error occurring during the download), the update is aborted, and the ERRL message. If the download and authentication are successful, the loaded Bootstrap 100 searches for an HVN 210 corresponding to the version number of the receiver / decoder 2020, as defined in a parameter field. If an HVN is not located, the update is aborted, and the ERRL message is displayed. If this entry is located, the Bootstrap 100 loader reads TID 212 from the MPEG tables used for the loader directory 300 associated with J3VN 210, the Loaded-In stream, and the software to be downloaded, and in the step S109, download and authenticate the correct charger directory 300. If the download directory 300 is not downloaded before the timeout is reached, or if the charger directory is not authenticated (due to an error occurring during the download ), the update is aborted, and the ERRL message is displayed. If they have the download and authentication, the Bootstrap 100 loader downloads the In-Stream Loader from the MPEG bit stream in the RAM 72 of the receiver / decoder 2020 in step S110. If the In-Stream charger is not discharged before the timeout is reached, or if the In-Stream charger is not authenticated (due to an error during the download), the update is aborted, and the ERRL message is displayed. If the Charger Inside the Charger is successfully loaded and authenticated, the Charger Inside the Stream is executed in step Slll, and in Step S112 the corrupted portion of the resident software is erased, and the software segments that are downloaded are downloaded. will be downloaded using the In-Stream charger, authenticated, and written to the appropriate address location in the FLASH memory 69. If the software is not downloaded before the timeout is reached, or if it is not authenticated the software (due to an error during the download), or if an error occurs while writing the software to the FLASH memory 69, the update is aborted, and the ERRL message is displayed. If the resident software is updated successfully, the writing of the report in step S113 is stopped, and the receiver / decoder 2020 is subtracted to enable an additional update to begin. In any steps in which the update is aborted, the step can alternatively be repeated a prescribed number of times, until it is carried out successfully, or until a timeout is reached to perform that step. If the update is to proceed in the normal state, the Bootstrap loader 100 determines, in step S201, whether an update request from an application is already pending. If not, the update continues normal. If there is already a pending update request, then the pending request is processed first. The report of the previous update is deleted in step S202, and initialized in order to start the registration of this update. The report records the reason for the update request, for example, at the request of an application, and any update options that are selected by the application. Then it is determined, in step S203, if a Resident charger is stored in the FLASH memory 69 of the receiver / decoder 2020. If this charger is stored in the receiver / decoder, it is determined, in step S204, whether the Resident charger has been executed in response to a command from the software stored in the receiver / decoder 2020. If the Resident charger has been executed, then the Resident charger performs the subsequent steps in the update process, which would normally be carried out by the Bootstrap 100 loader. the Resident charger is not present, or has not been executed, then the Bootstrap 100 charger is used. It is also possible that the software stored in the receiver / decoder 2020 will force the Bootstrap 100 loader to continue the update process, even when it is stored a Resident charger in the FLASH memory 69. The message CHARGE is displayed in the visual display 4038 of the receiver / decoder 2020 in Step S205. In step S206, the parameters stored in the parameter fields of the EEPROM and the FLASH memory 69 are verified. If the tuning parameters and / or the PID parameter are not defined, the visual display 4038 is made to display the message OOO , and the update is aborted. If these parameters are defined in the parameter field, the update proceeds to step S207, wherein the Bootstrap or Resident loader tunes the tuner 4028_ for the 2014 transponder, according to the parameters stored in the parameter fields. If the tuning fails, the update is aborted, and the ERRL message is displayed. If tuning is successful, the Boots-trap or Resident loader downloads and authenticates the hardware directory 200 in step S208. If the hardware directory 200 is not downloaded before the timeout is reached, if the hardware directory is not authenticated (due to an error during the download), or, depending on an option selected by the application that asks for the update, if a successful update has been made using a hardware directory that has the same HVERSION 206, the update is aborted, and the ERRL message is displayed. If the download and authentication are successful, and the application enables updating, the Bootstrap or Resident loader searches for an HVN 210 corresponding to the version number of the receiver / decoder 2020, as defined in the_ parameter field. If this HVN is not located, the update is aborted, and the ERRL message is displayed. If this entry is located, the Bootstrap or Resident loader reads TID 212 from the MPEG tables used for the loader directory 300 associated with that HVN 210, the Loader Inside the Stream, and the software to be downloaded, and in step S209, download and authenticate the correct charger directory 300. If the charger directory 300 is not downloaded before the timeout is reached, if the charger directory is not authenticated (due to an error occurring during download), or, depending on an option-selected by the application requesting the update, if a successful update has been performed using a loader directory that has the same LVERS 306, the update is aborted, and the message is displayed ERRL. If the download and authentication are successful, and the application enables updating, the Bootstrap 100 loader downloads the In-Stream Loader from the MPEG bitstream in the RAM 72 of the receiver / decoder 2020 in step S210. If the In-Stream charger is not discharged before the timeout is reached, or if the In-Stream charger does not authenticate (due to an error during the download), the update is aborted, and the ERRL message is displayed, if the loaded In Stream is successfully loaded and authenticated, the charger Inside the Stream is executed in step S211, and in step S212 the number of SVERS 310 versions of the software in the MPEG bitstream is compared with that of the resident software. If the version numbers are the same, the writing of the software is not performed in the FLASH memory 69, and the update request of the application is deleted. If the version numbers are different, the resident software is deleted, and the software segments to be downloaded are downloaded by the In-Stream Loader, authenticated, and written to the FLASH memory 69 in step S213.

If the software is not downloaded before the timeout is reached, or if the software is not authenticated (due to an error during the download), or if an error occurs during writing the software into memory FLASH 69, the update is aborted, and the ERRL message is displayed. If the resident software is successfully updated, the writing of the report in step S214 is stopped, the pending update request is cleared, and the receiver / decoder 2020 is reset, to enable an additional update to begin. As in the native state, in any steps in which the update is aborted, the step can be performed again in an alternative way until it is successfully completed. It will be understood that the present invention has been described above purely by way of example, and that modifications of the detail may be made within the scope of the invention. Each feature disclosed in the description, and (where appropriate), in the claims and in the drawings, may be provided in an independent manner, or in any appropriate combination. In the aforementioned preferred embodiments, certain features of the present invention have been implemented using computer software. However, of course, it will be clear to the expert that any of these features can be implemented using the hardware. Furthermore, it will be readily understood that the functions performed by hardware, computer software, and the like, are performed on, or using, electrical signals and the like.

Claims (42)

1. A method for downloading data to a receiver / decoder, which comprises the steps, in the receiver / decoder, of: receiving a stream of bits including the data; download a charger to load the data from the bitstream to the receiver / decoder; and download the data from the bit stream using the downloaded data loader.

A method according to claim 1, wherein the downloaded data loader is deleted from the receiver / decoder after the data has been downloaded from the bit stream.

3. A method according to claim 1, wherein the subsequently downloaded data loader is stored in the non-volatile memory of the receiver / decoder.

4. A method according to claim 3, wherein the non-volatile memory is a FLASH memory volume of the receiver / decoder.

5. A method according to any of the preceding claims, wherein the download of the data is performed by the downloaded data loader.

A method according to any one of the preceding claims, wherein only a portion of the data stored in the receiver / decoder is replaced by a corresponding portion of data downloaded by the downloaded data loader.

A method according to any one of the preceding claims, wherein the bit stream includes at least one data loader, the method further comprising the steps, in a transmission system, of: for the or each loader data, dividing the data loader in a plurality of modules; and for the or each data loader, dividing the data into a respective plurality of modules, each plurality of data modules being associated with a respective plurality of data loader modules.

A method according to claim 7, which further comprises the steps, in the transmission system, of: for the or each data loader, format each of the modules as a respective table, the tables having the same respective table identification ("TID"), and respective different table identification extensions ("extensions-TID"); and for the or each plurality of data modules, _ formatting each of the data modules as a respective table, the tables having the same respective TID as the tables of the data-loading modules associated with them, and different extensions- Respective TID.

9. A method according to claim 8, which comprises, in the download steps, download tables in module that have the same TID.

10. A method according to claim 9, wherein said tables have respective different TID extensions, which are not a previously determined TID extension; and further comprising the step, in the transmission system, of generating a respective directory table for the or each plurality of modules having the same TID, the or each directory table having the previously determined TID-extension and that TID , the directory table for each of the modules containing a name of that module and the respective extension-TID.

11. A method according to claim 10, which further comprises the steps, in the receiver / decoder, of: downloading one of the tables having the previously determined TID extension, to download a directory table; determine, from the contents of the directory table, the TID extensions of the tables in module that have the same TID as the directory table; and in the download steps, download the tables in module that have the same TID as that of the downloaded directory table, and extensions-TID determined from the directory table downloaded.

12. A method according to any of the preceding claims, which further comprises the step, in the transmission system, of generating a directory table having a previously determined table identification ("TID"), and containing, for each of a plurality of version identifications of a receiver / decoder, ^ a respective TID associated with that identification of version.

13. A method according to claim 12, wherein the version identification comprises a code for the receiver / decoder version, and a code for the receiver / decoder manufacturer. -

14. A method as claimed in the claim 12 or 13, when dependent on claim 11, which further comprises the steps in the receiver / decoder, of: downloading the directory table having the previously determined TID; and determining the version identification of the receiver / decoder; wherein the step of downloading a directory table comprises downloading that of the tables it has, a TID associated with the receiver / decoder version number, and the previously determined TID-extension.

15. A method according to any of claims 10 to 14, which further comprises the steps, in the transmission system, of: including in each transmitted directory table, a directory version identification for the same; and in the receiver / decoder: determining whether the directory version identification of a currently transmitted directory table is more recent than the identification of the directory version of a previously downloaded directory table having the same TID as the directory table. currently transmitted directory, and if not, abort the data download.

16. A method according to any of the preceding claims, which further comprises the step, in a transmission system, of: including, in the bit stream, a data version version of the data; and in the receiver / decoder, the step of: determining whether the data version identification of the received data is more recent than the data version identification of the data currently stored, and if so, performing this step of downloading the data. data from the bitstream.

17. A method according to any of the preceding claims, wherein at least part of the downloaded data loader is in the form of a code that is specific to the hardware of the receiver / decoder.

18. A method according to any of the preceding claims, which further comprises the steps, in a transmission system, of: transmitting a second data loader included in the bit stream; and in the receiver / decoder, of: downloading the second data loader; and downloading one of the aforementioned data loader and data, with the second data loader performing the download of one of the aforementioned data loader and data.

19. A method according to claim 18, wherein at least part of the second data loader is in the form of a code that is specific to the hardware of the receiver / decoder.

20. A. receiver / decoder, which comprises: a receiver for receiving a bitstream including data; a storage element; and a download element, for downloading from the bit stream to the storage element, a charger for charging the data from the bitstream to the receiver / decoder.

21. A receiver / decoder according to claim 20, further comprising an element for suppressing the data loader downloaded from the storage element, after the data has been downloaded from the bit stream.

22. A receiver / decoder according to claim 20, further comprising a non-volatile memory for storing the downloaded data loader after the data has been downloaded from the bit stream.

23. A receiver / decoder according to claim 22, wherein the non-volatile memory is a volume of FLASH memory of the receiver / decoder. 2 .

A receiver / decoder according to any of claims 20 to 23, wherein the downloaded data loader is adapted to perform data download from the bit stream.

25. A receiver / decoder according to any of claims 20 to 24, wherein the downloaded data loader is adapted to replace a portion of only the data stored in the receiver / decoder, by a corresponding portion of data downloaded by the receiver. same.

26. A receiver / decoder according to claims 20 to 25, configured to download tables.

27. A receiver / decoder according to claim 26, wherein the download element is configured to download a table having a table identification ("TID"), and a previously determined table identification extension ("TID extension") , to download a_ directory table, in order to determine, from the contents of the directory table, the TID extensions of the tables in module that have the same »TID as the directory table, and to download the tables in module that has the same TID as that of the downloaded directory table, and the TID-extensions determined from the downloaded directory table, to download that loader.

28. A receiver / decoder according to claim 26 or 27, wherein the download element is configured to download a directory table having a previously determined TID, and containing, for each of a plurality of version identifications. of a receiver / decoder, a respective TID associated with that version identification, in order to determine the version identifier of the receiver / decoder, and to download a directory table having a TID associated with the version number of the receiver. receiver / decoder, and the extension-TID previously determined.

29. A receiver / decoder according to claim 27 or 28, wherein the download element is configured to determine whether a version identification of a currently transmitted directory table is more recent than the version identification of a directory table previously downloaded that has the same TID as the directory table currently transmitted, and if not, abort the download of that charger.

30. A receiver / decoder according to any of claims 20 to 29, wherein the data loader is in the form of a code that is specific to the hardware of the receiver / decoder.

31. A receiver / decoder according to any of claims 20 to 30, wherein the download element is configured to download a second charger included in the data included in the bitstream, to download one of the first-mentioned charger, and the data.

32. A transmission system, comprising: an element for transmitting a bitstream including at least one charger for loading data in a receiver / decoder, and data associated with the or each charger; and an element for dividing the or each data loader into a plurality of modules, and dividing the data associated with the or each data loader into a respective plurality of modules to be transmitted by the transmission element.

33. A transmission system according to claim 32, which further comprises: an element for formatting each of the modules of the or each charger as a respective table, the tables of the or each charger having the same respective table identification ( "TID"), and respective different table identification extensions ("extensions-TID"); and an element for formatting each of the modules of the data associated with the or each loader as a respective table, the tables of the data modules having the same respective TID as the tables of the loader modules associated therewith, and extensions. -TID different respective.

34. A transmission system according to claim 33, wherein the tables have respective different TID extensions, which are not a previously determined TID extension; this system also comprising an element for generating a respective directory table for the or each plurality of modules having the same TID, each directory table having that TID and the extension-TID previously determined, containing the directory for each of the modules , a name of that module and the respective extension-TID.

35. A transmission system according to any of claims 32 to 34, which further comprises: an element for generating a directory table having a previously determined table identification ("TID"), and containing, for each one of a plurality of version identifications of a receiver / decoder, a The respective TID associated with that version identification.

36. A transmission system according to any of claims 32 to 35, which further comprises an element for including, in each transmitted table, a version identification for the same.

37. A transmission system according to any of claims 32 to 36, wherein the or each charger is in the form of a code that is specific to the hardware of the receiver / decoder.

38. A combination of a receiver / decoder according to any of claims 20 to 31, and a transmission system according to any of claims 32 to 37.

39. A signal that includes at least one loader to load data in a receiver / decoder, and data associated with the or each charger, the or each charger being divided into a plurality of modules, and the data being associated with the charger or each charger divided into a respective plurality of modules.

40. A method for downloading data to a receiver / decoder substantially as described herein.

41. A receiver / decoder substantially as described herein.

42. A transmission system substantially as described herein.