referring first to fig1 , a terminal 1 receives audio visual ( a / v ) signals 2 that carry the tv programs on a broadcast channel , as well as related digital data . the terminal decodes the a / v signals received and then supplies the selected tv programs to an associated tv 3 . while the tv programs are playing out , the terminal 1 ( hereinafter referred to as a decoder 1 ) runs onboard software stored within decoder 1 , the onboard software comprising application programs ( e . g . electronic program guide ( epg ), pay - per - view ( ppv ) resident application , video - on - demand ( vod ) resident application etc . ), an intermediate software layer ( middleware ), software layers for controlling the device layer interface that provides an interface between the middleware and the decode hardware controllers , and all other layers that are needed to operate the decoder . decode 1 can receive control commands from a remote control device 5 ( e . g . via infra - red communication ). remote control device 5 is used by a user / subscriber to select tv programs to view , control the volume of tv 3 etc . remote control device 5 is also used by a user / subscriber to put decoder 1 into a standby mode . decoder 1 can also be put into standby mode using a button on decoder 1 . in embodiments of the present invention , a power saving mode is advantageously used in order to reduce the power consumption of decoder 1 without actually shutting down the onboard software . thus decoder 1 does not go into a conventional standby mode as would be previously understood by someone skilled in the art , but instead goes into a frozen mode in which all processes that are being run by the onboard software in decoder 1 are frozen without actually being stopped . in addition , while decoder 1 is in this frozen mode , the ram in decoder 1 is kept powered / refreshed without the need for any specific powered ram hardware architecture ( e . g . independent or additional batteries ) whilst the other hardware components in decoder 1 are stopped . a power saving mode is then achieved by limiting the decoder &# 39 ; s internal clock rates and shutting down hardware not critical for the conservation of the ram . in frozen mode , the ram remains in the same physical state it was in just before all the processes that are being run by the onboard software are frozen . it is to be noted that reduction of the clock rates of the decoder can distort the measurement of time , which may be needed by the various onboard software - processes and to maintain the decoder &# 39 ; s time reference ( in order to , for example , automatically ‘ wake - up ’ the decoder from standby mode ). insofar as the clock rate reduction can be defined , it will be appreciated by someone skilled in the art that a new time reference can be calculated without difficulty . fig2 illustrates the functional modes of decoder 1 as a function of time t . the run mode 21 of decoder 1 is represented by solid lines . when decoder 1 is in run mode 21 , decoder 1 is switched on and powered . while tv programs are playing out , decoder 1 runs the onboard software , which manages the digital data that is broadcast with the a / v data . this data includes eit information about tv program content and used by the epg application , interactive applications and their respective data that can be displayed on tv 3 , and any other digital data that is provided with the a / v data broadcast by the tv channels / stations / operators . the frozen mode 22 of decoder 1 is represented by broken lines 22 . in this mode , decoder 1 has been put into standby mode ( e . g . by a user / subscriber ). this means , for example , that a user / subscriber has decided to stop receiving the broadcast of tv programs . according to the embodiments of the present invention , this standby mode is not a conventional standby mode as would be understood by someone skilled in the art , since the onboard software of decoder 1 is not actually shut down / stopped . rather , the onboard software is frozen and more specifically , execution of the onboard software is suspended and the execution context of the onboard software at the time execution of the onboard software was suspended is stored in the memory . decoder 1 remains in frozen mode 22 until a run command is received by decoder 1 . when such a run command is received , decoder 1 leaves frozen mode 22 and enters run mode 21 . the onboard software is restarted using the execution context previously stored in memory . thus all of the data that was previously stored in ram continues to be useable , thus obviating the need to reacquire this data from the data broadcast to decoder 1 by the operator with the a / v data . as mentioned above , this acquisition process is a lengthy one and thus a decoder operating according to embodiments of the present invention saves the costs of this acquisition process . fig3 illustrates in more detail the operations undergone by decoder 1 when it enters into frozen mode 22 . when decoder 1 receives a standby mode command 30 ( e . g . from remote control device 5 ), decoder 1 launches an acquisition procedure 31 that saves the current interactivity image of the onboard software , that is to say the group of applications ( dvb - mhp , html , java , etc .) and the other digital data ( e . g . eit , image data , xml files , etc .) that have been downloaded to decoder and are being used / run by the onboard software . in contrast to the resident image ( which comprises applications and / or data that are resident in decoder 1 and which change infrequently ), the interactivity image comprises applications and / or data that change frequently ( e . g . every day ). therefore , acquisition procedure 31 may also update the current interactivity image of the onboard software before saving the current interactivity image . for example , the eit forms part of the interactivity image and the eit data is used the resident epg application in decoder 1 . after an interactivity image update , the epg is able to display an updated epg with the most up to date event information . as a further example , a weather data file may form part of the interactivity image and the weather data file is used by a dvb - mhp application that provides local weather forecast information . after an update of the interactivity image , the weather application is able to display the most up to date weather forecast information . once the interactivity image has been saved ( which may be after the interactivity image has been updated ), the execution context of the onboard software ( i . e . the state of the onboard software ) is also acquired and saved in ram memory . when the interactivity image is used by the onboard software , the interactivity image comprises the execution context of the onboard software . the stored interactivity image and execution context are therefore available to decoder 1 when decoder 1 is restarted ( i . e . comes out of frozen mode 21 ) and subsequently re - enters run mode 21 . the acquisition of the interactivity image and execution context can take several minutes ( e . g . 10 - 20 minutes ) and therefore it is possible that a user might launch a decoder run command before the context acquisition program 31 has been completed . for example , if they have put decoder 1 into standby but then changed their mind a short time afterwards . in such a case , since the current interactivity image and execution context have not been acquired , the previous interactivity image and execution context that are already stored in memory are used , typically without any loss of performance quality . referring once again to fig2 , decoder 1 successively controls execution of onboard software when it is run mode 21 , and freezing of the onboard software when it is in frozen mode 22 . since the onboard software never actually stops running , as time goes by it becomes increasingly - unstable , mainly due to memory loss . preferably therefore , in order to maintain the execution stability of the onboard software , a genuine software reset 23 is carried out at regular intervals ( i . e . the onboard software is rebooted ) and is carried out just before decoder 1 goes into frozen mode 22 . it is to be noted however that such a reboot operation 23 is detrimental from a data availability standpoint , mainly due to the loss of information stored in ram . in particular , if the reboot operation 23 is interrupted , no further interactivity image or execution context is available , not even a previously stored interactivity image or execution context . therefore , the reboot operation 23 is preferably carried subject to one or more conditions , including for example : the onboard software has not been rebooted for a predetermined number of days ; and / or decoder 1 is put into standby mode at a late hour of the day ( e . g . after 10 pm , or after 12 am ); and / or decoder 1 has entered the frozen mode 22 a predetermined number of times . other conditions for deciding when to carry out an onboard software reboot 23 will be apparent to someone skilled in the art . decoder 1 applies one of more of these conditions using an internal clock or any other clock , e . g . a clock that is external to decoder 1 . the periods when the decoder is in run mode 21 , which correspond to the running of the onboard software , and the periods when decoder 1 is in frozen mode 22 , which correspond to the freezing of the onboard software , have greatly variable durations . these durations can last anything from a few minutes to several hours and even several days . the status of decoder 1 when it is in run mode 21 can be interpreted differently than when decoder 1 is in frozen mode 22 . for example , when decoder 1 is left running ( i . e . switched on in run mode 21 ) for a lengthy period , this can be attributable to the user watching tv but on the other hand it could also be attributable to the user having forgotten to switch decoder 1 off when the user stops watching tv . decoder 1 then remains on without anyone watching tv . preferably , therefore , decoder 1 has the capacity to run a series of tests in order to detect this infelicitous status . for example , decoder 1 can automatically detect if one of the following occurs : if decoder 1 is running at a late hour , e . g . after midnight ; and / or if decoder 1 remains inactive for a predetermined amount of time ( e . g . 2 - 4 hours ), a status which is conveyed by the fact that decoder 1 does not receive a command ( e . g . from remote control device 5 ) to change channel or change the volume , for example . other ways of detecting whether or not decoder 1 has inadvertently been left running will be apparent to someone skilled in the art . on detecting that decoder 1 has been inadvertently left running , decoder 1 could then reboot the onboard software ( if , for example , one or more of the above mentioned conditions for carrying out a reboot of the onboard software is met ). alternatively , if a reboot of the onboard software is not necessary , decoder 1 can enter frozen mode 22 . preferably , it is possible to disable this type of automatic standby mode by sending a command to decoder 1 , e . g . using remote control device 5 . when decoder 1 remains in frozen mode beyond a predetermined duration ( e . g . when the subscriber is on vacation ), decoder 1 preferably also has the capability to go into run mode 21 for long enough to carry out a reboot 23 of the onboard software . once this reboot has been carried out , decoder 1 preferably automatically goes back into frozen mode 22 after having carried out the acquisition procedure 31 . fig4 illustrates how applications and data acquired from the broadcast data stream , that is to say the acquired interactivity image , which allows for a rapid restart following a reboot of the onboard software , is managed . more particularly , fig4 shows the structure of the data that is stored in ram memory 41 . in decoder 1 , according to embodiments of the present invention , ram memory 41 remains powered when decoder 1 goes into frozen mode 22 for the purpose of interactivity image and execution context acquisition and retention as well for rebooting the onboard software ( if necessary ). the structure of the ram memory 41 also allows for instantaneous restoration of data stored within ram memory 41 following any reboot of the onboard software . the ram memory comprises the cache memory storing the eit information , dvb - mhp type applications , and other types of applications and digital data ( i . e . the interactivity image ). the ram memory also comprises the operating system software for decoder 1 , as well as intermediate software layers ( middleware ) that enable the various applications in the decoder to function . prior to the advent of the present invention , after a software reboot , even if the ram remained powered , the addresses that pointed to the execution context data were deleted or were replaced by other addresses in such a way that the execution context was lost . moreover , launching standby mode involved a software reset , which resulted in a loss of all access to the ram data . as a result , all data that had previously been downloaded from the broadcast data flow , as well as the data that was stored in the ram memory , was lost . if the decoder architecture did not have a hard drive , a systematic reloading of the various caches was unavoidable . if on the other hand the decoder architecture did have a hard drive , this data could be backed up and restored after the decoder came out of standby mode and carried out a software reset . however , this data was not immediately useable since it was necessary for it to be recopied and then transferred to the ram memory , which was a relatively lengthy process . according to embodiments of the present invention , ram memory 41 comprises a secure memory zone 42 , which is addressed using a fixed address 43 that remains unchanged even after a reboot of the onboard software . the secure memory zone 42 comprises dedicated areas 46 , which store data relating to the properties of a backup memory zone 44 . backup memory zone 44 itself comprises data storage areas 54 , which store the data that is to be continuously saved , including the data that is to be saved after a reboot of the onboard software . the properties of backup memory zone 44 that are stored in dedicated areas 46 of secure memory zone 42 include all the information that allows data stored in the data storage areas 54 to be found and parsed , and quota information about backup memory zone 44 for statistical and maintenance operations . these properties relate to , for example , the addresses of data storage areas 54 in backup memory zone 44 , the type of data stored in the data storage areas 54 , the total size of backup memory zone 44 , the memory blocks in backup memory zone 44 that have been allocated ( i . e . used memory blocks ), the memory blocks in backup memory zone 44 that are being used ( i . e . free memory blocks ), and checksums of the aforementioned data storage areas 54 calculated according to any known checksum algorithm . if , for example , the cache is updated with updated data or new applications are loaded onto decoder 1 , particularly during the acquisition procedure 31 that is performed when frozen mode 22 is entered , the updated data / new applications are saved in data storage areas 54 of backup memory zone 44 . the properties of data storage areas 54 as well as a checksum that is computed for each data storage area 54 are then stored in dedicated areas 46 of secure memory zone 42 . when decoder 1 leaves frozen mode 22 , particularly after a reboot of the onboard software , the checksums of the data storage areas 54 of backup memory zone 44 are computed and compared with the checksums that are stored in the dedicated areas 46 of secure memory zone 42 . if these checksums match , the cached updated data or new applications are made available to decoder 1 . fig5 shows the elements of the onboard software architecture in decoder 1 , according to embodiments of the present invention . memory management module 51 , which manages the structure of the data in ram memory 41 , is a software program that is run by a processor not shown in fig5 . the ram data , whose structure is shown both in fig4 and fig5 , is managed by memory management module 51 . when the middleware is initialised , the memory management module 51 retrieves the middleware properties used for program execution from a software component known as a device layer interface 52 ( dli ). dli 52 provides an interface between the middleware layer and decoder hardware controllers 53 . these middleware properties , as well as the size of ram memory 41 and the fixed address 43 remain , in general , unchanged from one reboot to another , except when new onboard software ( or a new version of the onboard software ) is downloaded or in the event that fixed address 43 has to change ( e . g . if the size of ram has to increase in order to accommodate a new feature of decoder 1 ). the organising principle of ram memory 41 , according to embodiments of the present invention , initially comprises reserving a group of dedicated areas 46 in secure memory zone 42 ( which it will be remember is addressed using fixed address 43 ), whereby the sizes of these dedicated areas 46 are defined according to the individual needs of the various applications . the addresses of each of the dedicated areas 46 are identified by an identifier id , which is supplied by the memory management module 51 on the creation of secure memory zone 42 . each dedicated area 46 is allocated a header that describes the properties of an associated data storage area 54 . this header contains the following information ( for example ): the address of the associated data storage area 54 ; the type of data which is stored in the associated data storage area 54 ; the memory blocks of back memory zone 44 that have been allocated ; the memory blocks of backup memory zone 44 that are still free ; the total size of the backup memory zone 44 ; and a checksum . the onboard software in decoder 1 is therefore aware of the effective memory usage and can use this information to manage any errors that occur due to the amount of data exceeding the available memory . the headers are stored using fixed address 43 in secure memory zone 42 . the size of secure memory zone 42 is , for example , 512 octets . in the case of a reboot of the onboard software , the program modules of the onboard software that have reserved for them a part of secure memory zone 42 , store application data in a data storage area 54 of backup memory zone 44 that is associated with the program module ; and also store the properties of the application data and the entry points to this application data . these program modules then signal the memory management module 51 informing it that it can store the properties and addresses of these data storage areas 54 in dedicated areas 46 of secure memory zone 42 . if the application data is saved successfully , the memory management module 51 computes a checksum for the data storage areas 54 , and then stores this checksum in the dedicated areas 46 of secure memory zone 42 . at the end of the rebooting of the onboard software , the allocated data storage areas 54 of backup memory zone 44 , as well as dedicated areas 46 of secure memory zone 42 are in the state that they had been in while decoder 1 was in frozen mode 22 . when the decoder leaves frozen mode 22 , the memory management module 51 analyses dedicated areas 46 of secure - memory zone 42 by recomputing the various checksums of the allocated data storage areas 54 , and compares these checksums to those that were previously stored , thus allowing the system to ensure that the data is coherent . if the checksums match , the memory management module 51 reinitialises the data storage areas 54 in such a way that they revert to their status at the time decoder 1 went into frozen mode 22 . otherwise , these areas are reinitalized in such a way that they become free areas . each dedicated area 46 comprises a generic allocation and clearing function that adopts as a parameter a unique identifier id characterising the area and used to identify a specific data block . the onboard software of decoder 1 provides specific functions that allow program modules to directly access a data block using the unique identifier id . thus , each program module of the onboard software that wishes to save application data can do so using these functions . the memory management module 51 allows for the allocation of memory areas of a fixed size . this is advantageous in that it makes the allocation process much more rapid than a basic allocation process and avoids memory fragmentation ( i . e . data is not fragmented and stored throughout the entire ram but rather is gathered in a specific portion of the ram ). at the end of a rebooting of the onboard software due to an onboard software download or a cold start ( i . e . starting after decoder 1 has been completely powered down ( unplugged )), the previously saved application data is invalidated . this may be because the cache structure may be different for the newly downloaded onboard software or may be because prior to a cold start , the ram was without power and therefore the data needs to be ‘ cleaned ’. in this case , dli 52 deletes the data from secure memory zone 42 . thus , memory management module 51 can consider the dedicated areas 46 of secure memory zone 44 as though they were obsolete , which means that the memory management module 51 need only reinitialise these areas and in so doing handles them like free space . hence , when a program module that has saved application data launches a sequence for retrieving this saved application data , the memory management module 51 indicates that this data is obsolete . when a program module containing application data in an allocated data storage area 54 wishes to access this data , the program module asks the memory management module 51 ( using its identifier id ) to send it the data from the allocated data storage area 54 . numerous onboard systems for decoders simulate standby using a mode known as fake standby , which simply comprises deactivation of the decoder inputs and outputs , resulting in a black / blank screen on the tv . however , new directives require implementation of a genuine power saving mode . the embodiments of the present invention that have been described above allow a decoder to go into such a power saving mode , allow for the instantaneous retrieval of data in a format that can be used immediately by the decoder &# 39 ; s onboard applications , and allow for the passage to a power saving mode without any data loss , irrespective of the decoder architecture used or the presence or absence of a hard drive . the ram memory of the decoder remains powered if the onboard software is rebooted and following a reboot , the onboard software restarts quickly , typically within 10 - 15 seconds . if ram is not managed in accordance with embodiments of the present invention , restart of the onboard software can take longer after a software reboot . this problem does not arise in the case of a freeze standby mode as described above . it is appreciated that various features of the invention which are , for clarity , described in the contexts of separate embodiments may also be provided in combination in a single embodiment conversely , various features of the invention which are , for brevity , described in the context of a single embodiment may also be provided separately or in any suitable subcombination . it will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove . rather the scope of the invention is defined only by the claims which follow :