PL183663B1 - Data processing system - Google Patents

Abstract

A receiver/decoder for a broadcast digital television system in which received signals are passed through a receiver to the receiver/decoder and then to a television set. The receiver/decoder decodes a compressed MPEG-type signal, and is controlled by a remote controller handset, through an interface in the receiver/decoder. The operation of the receiver/decoder is controlled by a virtual machine (VM) which includes a run time engine (RTE). The receiver/decoder includes a plurality of interfaces to external units, and logical driver devices for the interfaces. Applications control the external units by the RTE, which receives events from the interfaces via a set of queues. The RTE comprises a plurality of process sequencer units associated with the device means, and means for extracting events from the queue means and actuating the associated process sequencer units accordingly.

Description

The subject of the invention is a receiver-decoder for receiving transmitted signals, in particular for digital television systems.

Digital data transmission systems are known, mainly intended for broadcasting television signals, in particular, but not only, for satellite television systems, also used for other purposes, for example for providing end user interaction. The received signals are sent to the receiver / decoder and then to the television set. The receiver / decoder decodes the compressed MPEG standard signal into a television signal intended for a television set, controlled by a handheld remote control, via an interface on the receiver / decoder.

It is known to provide interactivity by executing an application on a receiver / decoder through which a television signal is received. For example, the application code is permanently stored in the receiver / decoder, but this imposes limitations. The receiver-decoder loads the code of the requested application, provides more variety, and the applications are updated without user interaction.

183 663

Known receiver-decoders share some functional parameters but different design details, including hardware details. However, the overall operation of the receiver-decoder, and in particular the functional way in which it processes applications, is identical for all the receiver-decoders. The design of the parts of their control system related to processing applications is common to all receiver-decoders, which is the responsibility of the system operator.

It is known, for example, from the publication of the Philips Journal of Research, vol.50, no.1, pages 169-184, for a multimedia terminal having a software hierarchy in which the applications are located at the vertex, residing and loaded from master to slave to conform to the connector API protocol. software DAVID application. Below the application layer is the operating system software layer, composed of the DAVID INPUT-OUTPUT management programs, device handlers and the OS-9 kernel. This completes the software hierarchy. Below the operating system software layer is the hardware layer containing specific Philips DET devices. Below the hardware layer is the physical layer interface to the network. It is known from the publication of the Philips Journal of Research, Vol 50, No. 1, pages 185-199 as a similar multimedia terminal. The operating system kernel is responsible for scheduling various requests for the microprocessor in the terminal. The OS-9 kernel also manages interprocess communication between various requests and processes in the terminal.

The receiver device according to the invention comprises a virtual machine arranged between the receiving devices and the at least one application for processing the data received from the receiving devices and restoring data to them, and the virtual machine includes an interpreter for interpreting the at least one application and executing the at least one interpreted application. the application in accordance with data received from the receiving devices for controlling the receiver-decoder function.

Preferably, the virtual machine includes a runtime engine for processing data received from the receiving devices.

Preferably, the time cycle engine is interposed between the at least one application and the at least one receiving device, and includes a queue structure for receiving events generated by the receiving devices and transmitting the events to the time run engine.

Preferably, the runtime engine comprises a plurality of process sequence modules associated with the receiving device and a queue selection system for extracting events from the queues and starting the associated process sequence modules for application execution accordingly.

Preferably, the runtime engine comprises an event filter for matching the event to a list of event types before entering the event into the queue structure.

Preferably, the virtual machine includes an application and data server library.

Preferably, the virtual machine includes an instruction sequence memory.

The advantage of the invention is the freedom in construction and the same functionality of the receiver-decoder circuit.

The subject of the invention is illustrated in the drawing in which Fig. 1 shows the general architecture of the digital television system according to the invention, Fig. 2 - the architecture of the interactive circuit being part of the digital television system, Fig. 3 - the file layout in the module loaded into the interactive memory. Receiver-decoder, Fig. 4 - schematic diagram of the receiver-decoder interfaces, Fig. 5 - arrangement of memory areas of the interactive receiver-decoder, Fig. 6 - functional diagram of the receiver-decoder and Fig. 7 more specifically some virtual machine components and runtime motor.

Figure 1 shows a digital television system 1000 which mainly comprises a conventional digital television system 2000 using an MPEG-2 compression system to transmit compressed digital signals. An MPEG-2 standard compressor 2002 at the broadcasting center receives a stream of digital signals, typically a stream of video signals. Compressor 2002 is connected via link 2006 to multiplexer and encoder 2004. Multiplexer and encoder 2004 receives numerous other input signals, creates one or more transport streams, and transmits compressed digital signals to transmitter 2008 of broadcast center

183 663 link 2010 which adopts different. .forms, including telecommunications links. The broadcast center transmitter 2008 transmits electromagnetic signals over the 2012 link towards the 2014 satellite relay, where they are electronically processed and emitted over the 2016 virtual link to the 2018 terrestrial receiver, usually in the form of a dish, owned or rented by the end user. The signals received by the 2018 terrestrial receiver are transmitted to the integrated receiver / decoder 2020 owned or rented by the end user and connected to the end user's TV 2022. Receiver-decoder 2020 converts the compressed MPEG-2 signal into a TV signal for the TV set 2022.

The conditional access circuit 3000, coupled to the multiplexer and encoder 2004 and the receiver / decoder 2020, is located partly at the broadcasting center and partly at the decoder and allows the end user to access digital television broadcasts from one or more broadcasting providers. A smart card that decrypts information relating to commercial offers, i.e. one or more TV programs sold by the broadcasting provider, is inserted into the 2020 receiver-decoder. Using the 2020 receiver-decoder and the smart card, the end-user purchases commercial offers either in prepaid mode. or by paying for the right to watch the program.

The interactive television chip 4000, also connected to the multiplexer and encoder 2004 and the reflector-decoder 2020, also located partly at the broadcast center and partly at the decoder, allows the end user to interact with various applications via modem channel 4002.

Figure 2 shows the general architecture of the interactive television system 4000 of digital television system 1000 according to the invention.

For example, the interactive television system 4000 allows end users to purchase items from on-screen catalogs, view desired local news and weather maps, and play games on television sets.

The interactive television chip 4000 typically includes four major components. The first component is the authoring tool 4004 at the broadcast center or elsewhere, enabling the broadcast provider to create, develop, improve and test an application. The second component is the application and data server 4006, located in the broadcast center, connected to the authoring tool 4004, enabling the broadcast provider to prepare, legalize and format applications and data for delivery to the multiplexer and encoder system 2004 for inclusion in the MPEG-2 transport stream. , usually to its private section for broadcast to the end user. The third element is a virtual machine containing a runtime engine 4008, which is an execution code, installed in the receiver-decoder 2020, owned or rented by the end user, enabling the end user to receive, validate, decompress and load the application into the working memory 2024 of the receiver-decoder 2020 for their implementation. The runtime motor 4008 also executes general-purpose resident applications. The runtime motor 4008 is independent of the hardware and the operating system. The fourth component is a modem channel 4002 between the receiver / decoder 2020 and the application and data server 4006, allowing signals to be sent instructing the application and data server 4006 to input data and applications into the MPEG-2 transport stream upon request by the end user.

Interactive TV chip 4000 works by using applications that control the functions of the receiver / decoder and the various circuits it contains. Applications are represented in the runtime engine 4008 as resource files. The set of resource and data files is a module, and several modules may be required to build an application. The storage of modules is the receiver-decoder memory area. An interface is used to load modules. The modules are loaded into the receiver / decoder 2020 from, for example, an MPEG-2 transport stream.

183 663

The elements mentioned in the previous paragraph will now be described in more detail. An application is a piece of computer code that is used to control the high level functions of the 2020 receiver-decoder. For example, when an end-user selects a key object displayed on the 2022 TV screen with the remote control and presses the enter key, the instruction sequence associated with the selected key is executed. .

An interactive application proposes menus and executes commands when requested by the end user, and provides data related to the application's purpose. The applications are for example resident applications, i.e., stored in ROM or flash or other persistent memory of the receiver-decoder 2020, or emitted and loaded into the RAM or flash-memory of the receiver-decoder 2020.

An example of an application is the initiator application. The receiver / decoder 2020 is equipped with a resident initiation application, which is an adaptive set of modules to be defined in more detail below, and which allows the receiver / decoder 2020 to operate immediately in an MPEG-2 environment. The application provides basic memory features that are modified as needed by the broadcast provider, and provides an interface between resident applications and load applications.

Another application is a runtime application that allows any application, both loadable and resident, to run in the 2020 receiver-decoder. This application acts as a bootstrap, performed when a service arrives to start the application. The runtime application is loaded into RAM and can therefore be easily upgraded. It is configured so that interactive applications available on each channel can be selected and run, both immediately after loading and after preloading. In the case of preloading, the application is loaded into memory 2024 and is activated as needed by the launch application.

Program Guide is an interactive application that gives you complete information about a TV program. For example, it gives information about TV shows for the whole week that are provided on each digital TV channel. By pressing a key on remote control 2026, the end user accesses an additional screen superimposed on the events shown on the television screen 2022. The additional screen is a viewer giving information about current and future events on each digital television channel. By pressing another key on remote control 2026, the end user accesses an application that displays a list of event information covering the entire week. The end user also searches for and organizes events according to simple and customized criteria. The end user also gets direct access to the selected channel.

The Pay-for-Watch-Right application is an interactive service available on any digital TV channel in conjunction with conditional access 3000. The end user accesses the application using the TV Guide or Channel Browser. Additionally, the application starts automatically as soon as an event is detected in the channel. The end user may purchase the right to view the current event via a smart card or via a communication server using modem, telephone and DTMF codes, MINITEL etc. The application is either resident in the 2020 receiver-decoder ROM or loadable into the 2020 receiver-decoder RAM.

The PC loading application is used to load a computer program by the end user.

The magazine browsing application includes the periodic emission of visual images, with the end user browsing the images using the on-screen buttons.

The quiz application is preferably synchronized with the broadcast quiz program. For example, multiple selectable answer questions are displayed on the television 2022 and the user selects the answer using remote control 2026.

183 663

The quiz app tells the user if the answer is correct or not and counts the scores the user gets.

A teleshopping application is used when offers for goods for sale are sent to the 2020 receiver-decoder and displayed on the 2022 television set screen. Using the remote control system, the user selects the item to be purchased. The order is sent via modem channel 4002 to the application and data server 4006 or to a separate point of sale whose telephone number has been loaded into the receiver-decoder, preferably with an order to debit the credit card account that was inserted into one of the card readers 4036 of the receiver-decoder 2020 .

The telebank application is used when the user inserts a bank card into one of the card readers 4036 of the receiver-decoder 2020. The receiver-decoder 2020 calls the user's bank using the telephone number stored in the bank card or stored in the receiver-decoder, and then the application provides a number of functions to be selected at using remote control 2026, for example, to load account balances over a telephone line, transfer money between accounts, request a check book, etc.

The internet browsing application is used when user instructions, such as a request to view a website with a specific URL, are entered using remote control 2026 and are sent over modem channel 4002 to the application and data server 4006. The broadcasts from the broadcast center contain the relevant website, received by the receiver-decoder 2020 via the link 2012, the satellite transmitter 2014 and the link 2016, and is displayed on the screen of the television receiver 2022.

Applications are stored in the memory cells of the 2020 receiver-decoder and are represented as resource files, which include files with descriptions of graphics objects, files with variable blocks, files with sequences of instructions, and application and data files.

Files with the description of graphic objects present the boards, the application interface between a human and a device. Variable block files represent data structures supported by the application. The instruction sequence files represent the data processing operations of the application. Application files provide entry points to the application.

Applications created this way use data files, such as icon library files, image files, font files, color table files, and ASCII text files. The interactive application also obtains data on the fly by sending and receiving data.

The runtime motor 4008 loads into its memory only those resource files that it needs at any given time. Resource files are read from graphic object description files, instruction sequence files, and application files. The files with the variable blocks are saved in memory by calling the module loading procedure and remain in memory until the module removal procedure is called.

Figure 3 shows a module 4010, such as a teleshopping module, which is a set of resource and data files including a single application file 4012, an indefinite number of graphics files 4014, an indefinite number of variable block files 4016, an indefinite number of sequence files 4018 instruction and other data files 4020, such as icon library files, image files, font files, color table files, and ASCII text files.

In an MPEG data stream, each module contains a group of MPEG tables. Each MPEG table is formatted as a number of sections. In an MPEG data stream, each section is up to 4 kilobytes in size. When transmitting data via a serial or parallel port, the modules, for example, are similarly subdivided into tables and sections, the dimension of the sections varying depending on the mode of transport.

The modules are transported in an MPEG data stream in the form of data packets, typically having 188 bytes in the appropriate data stream types, for example a video data stream, an audio data stream and a teletext data stream. Each packet is preceded by a packet identifier of 13 bits, with one packet identifier for each packet transported in the MPEG data stream. The program map table lists the different data streams and defines the content of each data stream

183 663 according to a proper packet identifier that informs the device about the presence of an application in the data stream, the packet identifier being determined using the PMT table.

In Fig. 4, the receiver-decoder 2020 comprises several interfaces, in particular an MPEG interface 4028 for the MPEG signal stream, a serial interface 4030, a parallel interface 4032, and two card readers 4036, one for the smart card that is part of the chip and one for the bank cards used. for making payments, banking, etc. The receiver / decoder also includes a modem interface 4034 for the modem channel 4002 of the TV signal producer, so that the user can indicate preferences to the producer of the TV signal.

The memory area is the storage location of modules 4010 located in memory 2024 of the receiver-decoder 2020.

In Fig. 5, memory 2024 is partitioned into RAM area 4022, flash memory area 4024, and ROM area 4026, but this physical organization is different from logical organization. The memory may also be divided into memory areas associated with various interfaces through which modules are loaded to the receiver / decoder 2020, for example an MPEG area for storing modules loaded from the MPEG bitstream and a serial interface area for storing modules received via the serial interface. From one point of view, memory is regarded as part of the hardware, from another point of view, memory is regarded as supporting or including all of the circuit shown except the hardware.

The receiver-decoder may have different hardware designs, although they all meet the same functional parameters. It is essential that a given application behaves the same way in every receiver-decoder and that the receiver-decoder executes all applications in the same correct way.

Figure 6 shows that the circuit is focused on the runtime engine 4008, which is part of the virtual machine 4007. It is coupled on the one hand to the applications on the high level, and on the other hand to the applications on the low level, through various intermediate logical units described below. .

In Fig. 4, the receiver-decoder includes various ports or interfaces, including remote control interface 2030 2026, MPEG interface 4028, serial interface 4030, parallel interface 4032, card reader interfaces 4036, and modem channel interface 4034, 4002, among others.

In FIG. 6, various applications 4057 are coupled to virtual machine 4007. Some commonly used applications are more or less resident applications on the chip, while others are loaded onto the chip, for example from an MPEG data stream.

Virtual machine 4007 includes, in addition to runtime engine 4008, some resident library functions for application and data server 4006, which include utilities 4058. The library includes various C-language functions used by runtime engine 4008. These include data manipulations, e.g. compression, extension or comparison of data structures, line drawing, etc. The application and data server 4006 library also contains information in the 2020 receiver-decoder such as hardware and software versions and available RAM space and functions used when loading the new 4062 device. Functions are loaded into libraries after saving to flash memory or RAM.

Runtime motor 4008 is coupled to device management 4068, which is coupled to a set of devices 4062 coupled to device drivers 4066 that are in turn coupled to ports or interfaces. Generally, device driver 4066 is considered to constitute the logical interface, so that two different device drivers 4066 are connected to a common physical port. Device 4062 may be coupled to more than one device controller 4066, and if device 4062 is coupled to one device controller 4066, device 4062 is capable of having all the functionality needed for communication, so the need for a separate device driver 4066 is avoided. Some devices 4062 can communicate with each other.

Devices 4062 communicate with the runtime engine 4008 in three ways: with variables, buffers, and events that are passed to a set of event queues.

183 663

In terms of developers or vendors of different functions, applications are produced by different vendors of services and programs. The runtime motor 4008 is constructed and provided by the system administrator or developer. The device management system 4068, devices 4062, and device drivers 4066 are provided by the decoder receiver manufacturer or hardware supplier. The relationship between the different tiers of receiver-decoder and the three tiers of vendors is usually not precise. For example, the system administrator will in practice also provide certain applications, the receiver-decoder manufacturer may be involved in the construction of the logic devices, etc.

Each receiver / decoder 2020 function is represented as device 4062. Devices 4062 can be either local or remote. Local 4064 devices include smart cards, signals connect SCART, modems, serial and parallel interfaces, MPEG video and audio players, and MPEG section and table separators. Remote device drivers 4066 differ from local devices in that the port and routine are defined by a hardware specialist or builder, not device 4062 and device driver 4066 provided and engineered by the receiver-decoder manufacturer.

When a new device 4062 is created, it can be installed in the existing receiver / decoder 2020 by loading the correct application 4056 from the broadcast center. This load is performed in the receiver-decoder 2020 by the application 4056 which checks the hardware and software version and if correct, loads the program modules representing the new device 4062 and asks the application and data server library routine 4006 to install the new device code in the hardware in flash memory . This can ensure flexible and secure installation of new features in the 2020 receiver-decoder without affecting the rest of the software.

Device management 4068 is a common software interface between application 4056 and receiver / decoder 2020 specific functions. Device management 4068 controls access to device 4062, declares receipt of unexpected events, and manages shared memory.

Run time motor 4008 runs under the control of a microprocessor and a general application programming interface. They are installed in every 2020 receiver-decoder, so that all 2020 receiver-decoders are identical from an application point of view.

Run-time motor 4008 executes applications 4056 at receiver-decoder 2020. Executes interactive applications 4056 and receives events from outside of receiver-decoder 2020, displays graphics and text, calls devices to obtain specific services, and applies functions from application and data server library 4006. coupled to the run time engine 4008 to perform specific calculations.

The runtime motor 4008 is an execution code, installed in each receiver-decoder 2020, and includes an interpreter for interpreting and executing the application. The runtime engine 4008 is adapted to any operating system, including a single tasking operating system such as MS-DOS. Runtime motor 4008 is based on modules with process sequences that respond to various events, such as a keystroke, perform various actions, and contain its own scheduler to manage event queues from various hardware interfaces. The runtime motor 4008 also supports the display of graphics and text. The process sequence module contains a set of action groups. Each event causes the process sequence module to move from the current activity group to a different activity group depending on the nature of the event and perform the activities of the new activity group.

The logical channel is different from the physical port, for example, two different types of logical channels may be used using the same physical port. The events in these two logical channels are forwarded to other process sequence modules. In addition, two other logical channels of the same type using a physical port can be used. In this case, everyone

183,663 of the two channels requires a proprietary process sequence module so that two instances or instances of the same process sequence module are created.

Run time motor 4008 includes a code loader for writing and loading application 4056 to the receiver-decoder memory. The necessary code is saved in RAM or flash memory for optimal operation. The uploaded data is verified by an identification mechanism to avoid any modification of the application 4056 or execution of an illegal application. Run time motor 4008 also includes a decompressor. When the application code or intermediate code form is compressed to save space and load quickly from an MPEG-2 transport stream or by the introduced mica-decoder mode, the code must be decompressed before loading it into RAM. The runtime engine 4008 also includes an interpreter for interpreting the application code for updating the values of various variables and determining changes in status, and an error controller.

The main loop of the runtime engine 4008 extracts events from the queue means and activates event-related process sequence modules. Each time the main loop goes through, the routine for receiving external events is called, such as pressing one of the remote control keys, receipt of an MPEG-2 section or a serial port message from the event interface. All events either entered into the presentation function discussed below or received by the interface pass through the event interface before being processed by the runtime engine 4008. For each detected event, the procedure includes a message called an event that is placed in one of the 5 queues of the runtime engine 4008, the appropriate priority level from 0 to 4. When the event interface is called, which puts the events in queues, runtime engine 4008 searches the queues in descending priority from level 4 to level 0. The event thus found is removed from the queue and used to activate the sequence module process for which it is intended.

Before using the services of any device 4062, a program, such as an application instruction sequence, must be declared a client, i.e., a method of logically accessing device 4066 or device management 4068. The device management system 4068 assigns the client a customer number which is referenced in all device references. Device 4066 can have several clients, with the number of clients for each device 4066 being determined depending on the type of device 4066. The client is entered into device 4066 via an open channel device procedure. This procedure assigns the customer a customer number. A client can be removed from the device management 4068 client list by an open channel device procedure.

Access to the devices 4062, provided by the device management 4068, can be either synchronous or asynchronous. For synchronous access, a device procedure is used: call. It is either a means of obtaining data that is immediately available or a function that does not include waiting for a requested response. For asynchronous access, the device instruction: input / output is used. It is a data acquisition means that includes waiting for a response, e.g. scanning the frequency of the tuner to find a duplicate or read a table from the MPEG stream. When the desired result is available, the event is placed on the motorized queue to signal its arrival. Another device procedure: Events provides the means to manage unexpected events.

The main loop of the runtime engine 4008 is connected to various process sequence modules, and when the main loop encounters the correct event, control is temporarily transferred to one of the process sequence modules.

Communication between runtime engine 4008 and applications is also mainly performed by two types of process sequence modules: process sequence modules for graphic object descriptions and process sequence modules for sequence instructions.

The operation of the process sequence modules is best described by considering the operation of the graphic object description module and instruction sequence modules. Modules

183,663 process image description process sequences support the device-human interface, and the process instruction sequence module operates in response to instruction sequence execution requests received from the image process description sequence module, the instruction sequence being a decompressed intermediate code instruction sequence.

The presentation function that communicates with the runtime engine 4008 relates to the presentation of text and graphics to the end user and the presentation of end user activities for the runtime motor 4008. The text and graphics are superimposed on the displayed image on the television screen 2022 and the user can interact through the application. 4056 with the remote control keypad 2026.

The graphic object description process sequence module receives query events from the end user television 2022 and processes the query by reading an interface file 4014. It then uses the graphical functions of the interface to trace the graphical object on the television 2022 screen. The end user uses the four keys of the remote control 2026 to move the graphical object across the screen. Each time a key is pressed, the event is processed by the process sequence module of graphic object descriptions. When the user confirms the selection using a valid key in remote control 2026, the event code is processed by the graphic object description process sequence module which generates events requesting the execution of the instruction sequence and sends them to the instruction sequence process sequence module.

When the process instruction sequence module receives a request to execute an instruction sequence from the graphic object description process sequence module, it reads the appropriate instruction sequence file 4018 and loads it completely into memory. It then begins execution of the instruction sequence and continues until the instruction sequence is complete or it encounters a function that causes the route change.

After the instruction sequence is complete, the system returns to circulation in the main loop to obtain events and change the order in which the program is executed.

There are also several load sequence modules whose function is to process protocols related to the various areas containing the 4056 applications.

In Fig. 7, device management 4068 includes a queue 100 to which events from devices are sent for temporary storage. At the correct intervals, the virtual machine sends a signal to the queue to extract the first event from it. This event is moved to the queue structure 101 in the virtual machine. Depending on the priority level, the event is placed in the correct one of five queues numbered 0 through 4. Events are extracted from the queue structure 101 by queue selector 102 under the control of the runtime engine 4008.

When an event is selected from the queue structure 101, it is passed to the process sequence module engine 104, which consists of a process sequence module driver 105 and a set of process sequence modules 106. Each process sequence module 106 is a set of interconnected action groups, each the transition from one activity group to the next activity group depends on the current activity group and the nature of the event. The various modules of the process sequence 106 have different dimensions and complexity, including those in which the next group of activities, i. E. The group of activities to which the system passes in response to an event, is dependent only on the nature of the event, but is not dependent on the actual group of activities. Also, as seen on the right side of the flowchart of the process sequence modules 106, there may be several copies of the process sequence module; that is, several identical process sequence modules to handle e.g. several separate data streams sent over a single port using identical protocols.

Once an event is selected, it is passed to the appropriate process sequence module 106. It selects the correct output from the current activity group in the process sequence module. This causes the selection of the next appropriate group of activities and execution of activities in a given group of activities

183,663, for example, sending a message to a device management system 4068 or executing a sequence of instructions. Action groups in process sequence module 106 may also send event messages to other process sequence modules 106.

If an instruction sequence is selected, its identification is sent to the instruction sequence selector 107. It receives the requested instruction sequence from the instruction sequence memory 108 and passes it to the instruction sequence interpreter 109 which executes the instruction sequence.

The system also includes an event filter 110, which is loaded with event types, for example, from process sequence modules 106. When an event is forwarded from queue 100 in device management 4068 to queue structure 101 in the virtual machine, its type or nature is compared to the list in the filter. event 110, and if it is of an unrecognized type, it is cleared. If the 4068 device management system or the keyboard generates an event of a type that the virtual machine cannot handle, such events are not passed to the queue structure 101 if such events were passed to the queue structure 101 or accumulated in the queue structure 101 or could cause a malfunction. engine of the process sequence module 104.

Fig.2.

183 663

Fig.3.

183 663

Fig.4.

Fig 5.

and

2024

183 663

Fig. 6.

4056

4061

183 663

183 663

Fig.1

Publishing Department of the UP RP. Mintage 60 copies. Price PLN 4.00.

Claims (7)

Patent claims A receiver-decoder for receiving transmitted signals, comprising receiving devices for receiving signals from a plurality of ports and providing data to those ports, and at least one application for controlling the functions of the receiver-decoder according to the received signals, characterized by comprising a virtual machine ( 4007) located between the receiving devices (4062,4068) and the at least one application (4056) to process and restore data received from the receiving devices (4062,4068), and the virtual machine (4007) includes an interpreter to interpret this at least one application (4056) and executing the at least one interpreted application (4056) in accordance with data received from the receiving devices (4062, 4068) to control receiver-decoder ftm function (2020). 2. A receiver-decoder according to claim The method of claim 1, characterized in that the virtual machine (4007) includes a runtime engine (4008) for processing data received from the receiving devices (4062, 4068). 3. A receiver-decoder according to claim The method of claim 2, wherein the run time engine (4008) is interposed between the at least one application (4056) and the at least one receiving device (4062) and includes a queue structure (101) for receiving events generated by the receiving devices (4062, 4068). ) and sending the events to the run time engine (4008). 4. A receiver-decoder according to claim The method of claim 3, characterized in that the runtime engine (4008) includes a plurality of process sequence modules (106) associated with the receiving device (4062) and a queue selection circuit (102) to extract events from queues (101) and start related related events accordingly. process sequence modules (106) for application execution. 5. A receiver-decoder according to claim The method of claim 3 or 4, characterized in that the runtime engine (4008) includes an event filter (110) for matching the event to a list of event types prior to entering the event into the queue structure (101). 6. A receiver-decoder according to claim 5. The method of any of claims 1 or 2 or 3 or 4, characterized in that the virtual machine (4007) comprises an application and data server library (4006). 7. A receiver-decoder according to claim 3. The virtual machine as claimed in any of the preceding claims, wherein the virtual machine (4007) includes an instruction sequence memory (108).