UA71561C2 - Multimedia terminal for several users - Google Patents

Abstract

A terminal for processing digital audio-visual or multimedia data including a data processing system and a memory, the data processing system storing user profile data (81, 82, 83) relating to the characteristics or preferences of multiple users (80) of the terminal. In a particularly preferred embodiment, the user profiles correspond to modes of operation of the terminal, the user profile data including priority data indicating the priority rights of each user to terminal resources.

Description

Description of the invention

The present invention relates to terminals for processing digital audiovisual or multimedia data. 2 Terminals of this kind are well known in the field of pay-TV systems, in which a decoder or user-defined set-top box (see roh) receives broadcast digital multimedia data, including audiovisual program data, as well as data for generating on-screen menus, data for implementing game applications programs or application programs for remote purchases, etc. Depending on the system, data can be transmitted using broadcast in scrambled or open form. 70 Before the introduction of digital technology, decoders were connected to a limited number of devices, usually only to televisions or, at most, to a TV and VCR UN5. The development of digital technology has led to a dramatic increase in the number of devices that can be connected to the decoder, a dramatic increase in the number of devices that can be connected to the decoder, to the same extent as to the increase in the functionality of the decoder itself. For example, in addition to the analog output Regiiye! to the TV and 12 MN VCR, the decoder can also be connected via a digital bus such as the IEEE 1394 bus to other digital devices such as an OMO recorder, a personal computer (PC), etc.

As a result of the increase in the number of external devices that can be connected to the decoder, the number of device operating modes also increases. For example, in a standard set of a decoder and a TV, the decoder can be used either simply to provide broadcast television information, or to provide Internet connection.

Moving away from traditional analog systems, the architecture of currently known digital decoders, however, retains a tendency to follow the familiar concepts that define their design. In particular, the architecture of standard decoders is not exactly the one that reflects the essence of the terminal, which distributes data in parallel between numerous external devices, as well as the possible operating modes of the decoder and the possible number of users of the system. Gee)

According to the present invention, a terminal for processing digital audiovisual or multimedia data is proposed, which includes a data processing system and a memory, characterized in that said data processing system stores in said memory user profile data related to parameters or settings of numerous types of users of the mentioned terminal. --

Due to the assignment of user profiles, the processing system gets the possibility of flexible work with numerous Ge) users of the terminal. As will be shown, although the user profile may be associated with the attachment of some external device or with the identity of the operator using the terminal, preferably the user profile is associated with a mode of operation, for example, Internet mode or TV mode. "--

The user profile can also be further personalized for one or more operators.

For example, after defining the user profile for the Internet mode of the terminal, you can define - the first Internet operator with certain rights, and the second operator with other rights.

Preferably, user profile data includes resource data indicating the terminal resources available to each user. In the case of a decoder terminal, these resources may include access rights to the demultiplexer to determine the data to download from the broadcast data stream, etc. C 50 In addition, the user profile data preferably includes priority data indicating the priority of each user in relation to access to one or more terminal resources. For example, for

From" the decoder terminal, user profile data may include a priority level indicating the priority of a particular user when accessing the demultiplexer. After that, conflicts between channel access requests, for example, received from a user of a television device and a user of a recording device, can be resolved by the control application based on such priority information. 7 In addition to resource data indicating terminal resources that can be used by a particular device, user profile data may additionally include data relating to certain attributes of the information issued to each user. These attributes may include, for example, i-th indicator of the language that should be used in all dialog messages of the graphical interface for this user.

Additionally, user profile data may include data related to permitted actions

With each user, for example, can this user switch the demultiplexer channel, etc. This data, although closely related to the resource data described above, can be used to determine the possible operations allowed by a device that has access to a given resource on that resource. 29 Preferably, some or all parameters or settings of user profile data may be modified

GF) by the operator during the normal operation of the terminal. For example, the value of the relative priorities of each user when accessing data can be modified by the viewer to prioritize access to the VCR before access to the TV, or the priority of the Internet connection over the TV, etc. Alternatively or additionally, some or all of the user profile data may be determined by the data processing system 60 of the terminal.

The present invention is particularly applicable in the case of a terminal containing a data processing system that includes, among other things, a virtual machine and an object-oriented application program interface layer containing a plurality of class libraries.

In particular, the application program interface level may contain one or more class libraries that determine the operation of the virtual machine in relation to user profile data. These classes may include, for example, a class library designed for processing user profile data in the terminal's cache memory. In addition, the specified classes may include the user profile class library or several such libraries, for defining data parameters stored in user profile blocks.

For example, some class method can be used to define preferred language attributes to save in the user's profile.

The behavior of application interface level classes will depend on the chosen programming language. In the case of an application program interface written in the DAMA language, for example, a structure with single inheritance between classes and their subclasses will be followed. 70 In one embodiment of the invention, classes of user profiles may include a generic class library that defines the general characteristics of these user profiles, and one or more subclass libraries that define the characteristics of individual user profiles.

The present invention is particularly applicable to a terminal in the form of a decoder designed to receive data transmitted in a digital data transmission system.

This invention equally extends to the way the terminal works.

The term "decoder" can mean a receiver for receiving either coded or uncoded signals, for example, television and/or radio signals. Implementations of such decoders may include a decoder integrated with the receiver, for example in a user-defined set-top box, for decoding received signals, or a decoder operating in conjunction with a physically separate receiver, or a decoder bundled with additional elements , such as a web browser, VCR or TV.

The term "digital data transmission system" as used herein extends to any system for transmitting or broadcasting, for example, primarily audiovisual or multimedia digital data. Although the present invention is particularly applicable to broadcast systems of digital television, the invention can also be applied in specialized communication networks for multimedia applications for

the Internet, in cable television networks, etc.

A preferred embodiment of the present invention will be described below, by way of example only, i) with reference to the accompanying drawings, in which:

Figure 1 shows a digital television system, which includes a multimedia terminal represented by a decoder; "- zo. Figure 2 shows the physical elements of the decoder shown in Figure 1;

Figure 3 shows the software architecture of the data processing system in the decoder; ise)

Figure 4 shows the structure of the virtual machine used in the data processing system shown in Figure 3;

Fig. 5 shows a set of predefined user profiles defined in this variant (87 of 5 Implementation of the invention; cha

Figure b6 shows the data elements of user profiles stored in the decoder memory for each of the user profiles shown in Figure 5; and

Figure 7 shows the structure of the class libraries of the interface level of the software architecture, which can be used when defining user profiles. "

The diagram of the organization of the digital television system 1 according to the present invention is shown in Fig. 1. This invention pt) c includes a practically conventional digital television system 2, which uses the known MPES-2 compression system to transmit compressed digital signals. In more detail, the sealing device With ;" MPRES-2 in the broadcast center receives a stream of digital signals (usually a stream of video signals). The sealing device C is connected to the multiplexer and scrambler 4 using the communication channel 5.

The multiplexer 4 receives numerous additional input signals, composes the transport stream and transmits -I compressed digital signals to the transmitter 6 of the broadcasting center through the communication channel 7, the type of which, of course, can be different, including telecommunication channels. The transmitter 6 transmits electromagnetic signals through the channel - "Earth-satellite" 8 to the satellite repeater 9, where they are processed by electronic means and broadcast through the virtual channel "satellite-Earth" 10 to the ground receiver 12, which usually has the shape of a dish, which belongs to or leased by the end user. Signals received by the receiver 12,

Me, are transmitted to a combined receiver/decoder 13 owned or leased by the end user and connected to the end user's television set 14. The receiver/decoder 13 decodes the compressed MRESO-2 signal into a television signal for the TV 14.

Of course, other transport channels for data transmission are also possible, such as terrestrial broadcasting, cable transmission, combined satellite and cable communication channels, telephone networks, etc.

In a multi-channel system, the multiplexer 4 processes audio and video information received from a number (F) of parallel sources and interacts with the transmitter b to transmit this information on the appropriate number of ka channels. In addition to the audio-visual information, some or all of these channels may include messages, application programs, or any other type of digital data interspersed with the digital audio or video information being transmitted.

Conditional access system 15 is connected to multiplexer 4 and receiver/decoder 13 and is located partly in the broadcasting center and partly in the decoder. It allows the end user to access digital television broadcasts from one or more broadcasting operators. A smart card can be installed in the receiver/decoder 13, which has the ability to decode messages related to commercial offers 65 (that is, to one or more television programs sold by a broadcast operator). With the help of the decoder 13 and the smart card, the end user can purchase the commercial offers in the subscription mode or in the pay-per-view mode. In practical implementations, the decoder can be configured to work with several access control systems, for example, according to 5itiiisguri or Myisguri schemes.

As mentioned above, the programs transmitted by the system are scrambled by the multiplexer 4, and the conditions and encryption keys applied to this transmission are determined by the access control system 15. This method of transmitting scrambled data is well known in the field of pay TV systems.

Usually scrambled data is transmitted together with a control word for descrambling this data, and the control word itself is encrypted with a so-called working key and transmitted in encrypted form.

The scrambled data and encrypted control word are then received by the decoder 13, which has access to the 7/o equivalent of the working key stored on a smart card installed in the decoder, in order to decrypt the encrypted control word and further descrambling the transmitted data. The user who has paid a subscription will receive, for example, in "rights management messages" (ESM - Epiyetepi

Sopigo! Mezzade) transmitted monthly, the working key needed to decrypt the encrypted control word, which allows the transmission to be viewed.

The interactive system 16, which is also connected to the multiplexer 4 and the receiver/decoder 13 and is also located partly in the broadcast center and partly in the decoder, allows the end user to interact with various application programs through the modem reverse channel 17. The modem reverse channel can also be used to communication used in the conditional access system 15. An interactive system may be used, for example, to enable the viewer to immediately contact the Broadcasting Center and request authorization to view a particular broadcast, download an application program, etc.

Below will be described with reference to Fig. 2 the physical elements of the receiver/decoder 13, or set-top box intended for the user, which can be used in this invention. The elements shown in this figure will be described as functional blocks.

The decoder 13 contains a central processing unit 20, which includes memory elements associated with it, which is designed to receive input data from a serial interface 21, a parallel interface 22 and a modem 23 (connected to the modem return channel 17, shown in Fig. 1). (8)

The decoder is made with the additional possibility of receiving input signals from the infrared remote control 25 through the control unit 26 and from the switching contacts 24 on the front panel of the decoder. The decoder also has two smart card readers 27 and 28 adapted to read bank cards and prepaid smart cards, respectively. Input signals can also be received from a keyboard with an infrared interface (not shown). The prepaid smart card reader 28 interacts with the prepaid card installed in it and with the conditional access unit 29 to transmit the necessary control word to the demultiplexer/descrambler 30 and to enable the descramble of the encrypted broadcast signal. The decoder also includes a conventional tuner 31 and demodulator 32 --

For reception and demodulation of the transmission from the satellite before it is filtered and demultiplexed by the block 30.

Data processing in the decoder is generally controlled by the central processor 20. The software architecture of the central processor corresponds to a virtual machine interacting with a lower-level operating system implemented in the hardware components of the decoder. "

Decoder System Architecture c Turning now to the architecture of the receiver/decoder system shown in Figure 3, it can be seen that a multi-level architecture is used. The first level 41 represents the operating system of the equipment;" receiver/decoder. It is the real-time operating system chosen by the manufacturer to control the hardware elements of the receiver/decoder. A real-time operating system has a relatively short response time, which allows for the correct synchronization of operations performed by the hardware. Event messages are passed between this layer and the middleware layer 42 immediately above it. - The mentioned data processing system is located above the level of the hardware operating system and includes the middleware level 42 and the application program interface level 43.

Middleware level 42 is written in a language such as AM5ZI C and includes

Me, a virtual machine 44 and numerous interfaces 45, including a graphical interface 46, an interface 47 of flash memory as well as a PPZP, an interface 48 of protocols and an interface 49 of devices.

The present invention uses a virtual machine to ensure the independence of high-level application programs from the low-level operating system implemented by the manufacturer of the set-top box intended for the user. Interfaces 45 provide communication between the operations of the virtual machine and the low-level operating system 41, and also include a number of intermediate-level application program modules that are more easily

F) are performed at this level. The application program interface (API) level 43 includes a number of high-level modules 50-55 written in an interpreted object-oriented language such as ShChama. These modules provide an interface between the application programs created by the service provider (interactive program guide (program guide), remote purchases, IP browser, etc.) and the virtual machine of the system. Examples of such applications are given below.

A low-level operating system (OS) is usually embedded in the hardware components of the receiver/decoder, although in some implementations the low-level OS may be a bootable one. Middleware 65 and application interface level modules can be loaded into the decoder's RAM or flash memory from the broadcast transmission. Alternatively, some or all elements of the middleware or application interface layer may be stored in the firmware or flash memory (if any) of the decoder. The decoder may even include a hard disk or USB drive as a storage device.

It is clear that the physical organization of the memory elements of the decoder differs from the logical organization of the memory.

Application program interface level

Figure 3C shows the application program interface level 43 mentioned above; modules at this level are written in an object-oriented language such as Ukhdama. Each module defines a set of class libraries that are called during system operation. The following modules are installed in this system.

Module 50 I apoa/SHII (Language/Utilities). This module defines the classes necessary for the operation of a virtual machine with 7/0 objects. Such class libraries usually form part of the standard library associated with the chosen object-oriented language.

Module 51 MNES-5. This module defines classes related to the manipulation of graphic objects on the television screen. Such objects are different from audiovisual data and can form, for example, channel identifiers or text that is superimposed on the images that are displayed on the screen. The definition of classes in this module must meet the requirements of MNES-5, defined by standards ET5 300777-3 and

IZOLZE 13522-5 (and the IBO/LZE 13522-6 standard in the case of a system implemented in the Dama language).

Instrumentation Module 52. This module contains classes used to download and decompress data, classes related to file system and memory management in the receiver/decoder, and classes related to Internet connectivity, etc.

Module 53 devices. This module defines the classes needed to control the peripherals connected to the receiver/decoder mentioned above, including the modem, smart card readers, MPEO stream tuner, etc.

Service Module 54. This module defines the classes needed to perform high-level interactive application development, such as credit card data management, etc. with

Module 55 OZMOS-TSSHY. This module implements the protocols necessary for the exchange of information between the client and the server to find and read data files. The implementation of this module must meet the requirements and)

IZOLES 13818-6 and directives specified in part 9 of SAMIS.

In normal operation, the next layer of interactive application programs, which are created by the service provider and loaded during the broadcast, as in a normal system, will be located above the above-described interface modules. Such application programs usually include a general program manager to manage certain basic decoder operations and one or more additional application programs that implement additional services. In particular, the user manager application can be used to resolve user priority conflicts, as described below.

Depending on the application programs used, some of the named modules may be missing. --

For example, if the service provider is not going to provide a common channel for reading data, the cha

OBMSOS-CI may not be present in the final system.

Modules 43 provide class libraries for an object-oriented programming environment. The behavior of their classes will depend on the selected language. In the case of an application in the checker language, for example, the structure of classes with single inheritance will be followed. "

It is clear that the grouping of a class or a set of classes by modules does not play a significant role as far as the functionality of the class is concerned. Some classes related to peripheral device management can . be, for example, classified as those that are subject to inclusion in the device module 53 or in the service and? module 54.

Interface level

As shown in the illustration, the interface level consists of four modules - a graphics module 46, a memory file management module 47, a protocol module 48 and a device manager 49. Although modules at this level are described as interface modules, their purpose is mainly to provide a binding layer for - the implementation of application program interface modules and for the functioning of the virtual machine as a whole. c Graphics module 46, for example, provides creation of graphic objects and their management. It asks the low-level OS to display basic graphics primitives such as single pixels, lines,

Me, rectangles, etc. The implementation of this module depends on the graphical capabilities of the low-level OS as a manufacturer. Being somewhat complementary to the MNES-5 module 51, these functions can be performed more efficiently at this code level compared to the high-level code chosen for the application program interface layer above it.

Similarly, the memory file management module 47 includes low-level read-write file commands associated with system memory components. Usually, the hardware operating system (F) includes only commands that implement reading-writing of a sector or a page of a memory component. ka As in the case of the graphics module 46, this module allows you to effectively introduce a set of simple low-level application programs into the system. v Module 48 protocol management defines a library of data exchange protocols that can be called when exchanging information through, for example, the TCP/P-layer of the decoder.

The device manager 49 differs slightly from other modules of this layer in that it provides a communication channel or interface between the hardware operating system and the layers above it, including other interface layer modules and the virtual machine. For example, commands or event messages received by the hardware OS from the virtual machine and transmitted to it must be transmitted by the device manager for conversion according to the specifications of the interface between these two layers.

Description of the virtual machine

The structure of the virtual machine 44 used in the system according to the present invention will be described below with reference to Fig.4. The virtual machine used in the present invention is a multi-threaded displacement type machine. The general characteristics of such a machine are known from other industries, and the creation of code for the implementation of such a machine will not go beyond the competence of an ordinary specialist in this field.

A virtual machine consists of a number of elements that interact, in general, as shown in Fig.4.

The scheduler 60, consisting of the thread manager service 61 and the monitor manager service 62, is the central component of the multi-threaded machine. The scheduler 60 specifies the execution order of threads such as those 7/0 created by applications outside the virtual machine and those created by the virtual machine itself (eg, the "garbage collector" thread mentioned below).

The event manager 63 maintains an event routing table and lists events received by threads and centralizes the dispatching of event processing.

The memory manager 64 handles the allocation and freeing of memory areas in the system memory, and also performs /5 removal from memory of objects to which there are no references ("garbage collection" - disposal of freed memory during program or system operation).

The class manager 65 loads the classes of the application program code that is loaded from the broadcast signal, interacting with the security manager 6b to check the integrity of the loaded code and with the file manager 68 that builds the application programs.

The 68 file manager supports the implementation of system files and manages the loading mechanism of interactive application programs and data.

The security manager 66 is responsible for the level of access granted to downloaded applications; some applications may perform more operations on the file system than others.

The interpreter 67, which includes the byte code interpretation service 69 and the "t-code" interpretation service 70, performs the interpretation of application programs written in one of these two codes, and the byte code corresponds to the application programs of the checker, and the t- code is the name given to the applicant's own code. and)

User profiles

The increase in computing power of decoder hardware has led to an increased role of decoders in routing data between numerous potential users of the system. For example, one IKO (Ipiedgayei "pd zo Keseimeg/Oesodeg - combined receiver/decoder) can serve as an entry point for a broadcast MREOS stream, which is processed and directed to one or more connected TVs, with an analog VCR UN5 connected via the communication channel of the Region, a personal computer (PC) or a recording device on the OMO connected via the IEEE 1394 bus, etc.

The central idea of the considered implementation is the definition of a set of "users" of the decoder, and -- zv Each user is assigned a specific user profile. For example, a high-level application program can define multiple user profiles, for a TV viewer, for a person recording on a VCR2, for people directly using the decoder to access the Internet, for people using the decoder to route data to a PC, etc. . Figure 5 shows an example of a set of typical user profiles. This list can be expanded to "

Include, for example, an OMO device connected to a decoder, etc. with c The user profile can be defined as corresponding to some external device connected to . terminal, for example, to a connected TV, when the terminal simply directs audiovisual data to the y? TV. The user profile can also be defined as corresponding to some factual characteristic of one or more natural persons, or "operators", using the terminal.

In the case at hand, however, the user profile is defined as corresponding to some mode of operation of the device, such as Internet mode. Each user profile defined for one configuration or mode of operation can be personalized for different persons using the decoder terminal. For example, one person may have different viewer settings than another person, or they may be prohibited from viewing certain channels. Information related to 5p settings for each person is stored in the mentioned user profile for this mode of operation.

Me, Each user profile has a unique and distinctive user ID and one or more

Kk priority values that determine the priority of this user in receiving one or more decoder resources. In this case, the term "resource" refers to the functionality of the decoder, for example, access to the demultiplexer to download the selected data. A high-level control application program sets and stores the parameters of these profiles, manages resource allocation, and resolves conflicts between users based on user priority.

F) For example, the user manager can give the user "VCR" such priority that the request of this user to use some resource will have priority over the request of the user "VIEWER" to use the same resource. In particular, the "VCR" user may have an advantage over the "VIEWER" user when it comes to selecting the demultiplexer channel. In this way, the application prevents the channel change signal received from the viewer from having a higher priority than the channel selection by the person who wishes to record the program being broadcast at the same time.

In this example, when each user is assigned a single priority value, the user "VCR" will always have priority over the user "COOLER" when accessing any resource 65. Alternatively, multiple priority values may be assigned so that for the same specified resources priority will be given to "LADACH", relative to other resources - "VCR", etc.

Prioritization is performed by the user manager and can be interactive, ie the operator can determine, by programming the decoder with a hand-held remote control, whether to give Internet connection a higher priority than watching TV, etc.

Each user profile includes, in addition to the value of the user ID, a set of settings stored in the flash memory of the decoder, for example, in the flash memory of the decoder. These settings will be called by the application every time the decoder is loaded. As shown in Fig. b, data 80 of user profiles include data 81 about resources, data 82 about attributes and data 83 about actions.

The resource data 81 includes a list of internal decoder resources that can be accessed by the 7/0 User, such as the MPEC tuner and descrambler. It is clear that in this context, the term "resource" implies a logical resource, which means a combination of physical elements related to the demultiplexing process, conditional access system, etc.

Attribute data 82 includes preferred attributes specific to a given user, such as the language used (English, French, German, etc.) that should/5 preferably be used for display, the level of programs that may be viewed this user, from the point of view of morality and ethics, etc. Action data 83 includes a list of allowed actions that this user can perform, including channel switching and the like.

User profile data may include preset values defined by the user manager (for example, all users have access to tuner resources, 2o demultiplexer, etc.), as well as values that can be modified and personalized for each of the operators that uses a terminal, for each mode of operation (the level of programs that can be reviewed, from the point of view of morality and ethics, etc.).

Values that can be modified by the operator may include values for each user profile set by the operator at the time the decoder is loaded, as well as values set with the operator each time a session is started with some particular user profile.

The definition of multiple user profiles, corresponding to the modes of operation and including i) data related to the priorities of access to terminal resources for each profile, opens the possibility of parallel processing by the terminal of such modes in order to allow, for example, one terminal to manipulate data and process them for viewing through the TV and, at the same time, send other data to record "- a network connected recording device, send the data to a PC for processing, etc. In such systems, the terminal actually turns into a hub for data transmission to numerous connected peripherals, which are) working in parallel. Control of this type of devices is particularly successfully carried out by a multi-threaded system of the type shown in Fig. 3 and Fig. 4, as will be described below.

In order to make possible the creation of numerous user profiles, it is desirable to include in the ARI-level (87

Zv Classes of objects that would allow, in interaction with the virtual machine, to implement this. As described above, with reference to fig. C, the class libraries defined in API-level 43 define the parameters of functioning within which high-level application programs are executed. In particular, when performing certain operations, a high-level application program will contain instructions that refer to object classes defined at this level. "

Each class will obey the rules of the object-oriented programming language chosen for it from the c level. Standard object classes include classes related to decoder port management, such as

And the interface for credit cards, as well as for other operations, such as managing the access control system. and? A number of standard ARI-level classes are defined by the UAMIS group, for example, those relating to access to sections and tables of the MPEC stream being loaded.

Figure 7 shows the structure of classes that provide the ability to define user-specific settings for each such user, which facilitates the support of numerous users with the help of a high-level application program. The classes that will be described can be included, for example, in - the service module 54, installed in the API-level 43. Figure 7 shows the OzegSaspeMmapadeg class 90, which is used to provide 5p application programs with the ability to access profile data users stored in the flash memory of the system, and

Me, work with them. This class is a static class. As in the usual software architecture, based on the principles of object-oriented design, the class library includes a set of methods or commands, such as the ipiaize() method to initialize flash memory, the deiMaxOzegRgoyevi) method, which allows you to learn the maximum number of users that can be supported by the system, the DeAsiimeOzvegiB method), which allows you to find out the number of users active at the moment of time, etc. This class can also be associated with a set of events that notify the application program of an event that has occurred, such as the creation or

F) deletion of the user profile. ka These classes also include class 91 OzegRgoye. This class is a generic class that allows you to create multiple user profiles. This class includes a set of methods, such as methods deivsegiO(), which allows you to get the user ID, deiRgiogiuG emeI), which allows you to find out the priority for access to resources, ze(bepegaiAcnghirshie(), which allows you to set the value of any general parameter, etc.

This class is also associated with a set of events reporting, for example, a request from the user to switch channels, etc.

These methods allow indirect access to parameters, thereby avoiding the need to have a separate method for each parameter. The number of parameters processed by these methods will depend on the choice of the system architecture developer and may increase over time.

In fact, the choice and functionality of numerous methods in this and other classes can also be determined at the discretion of the system creator and depending on the computing power of the hardware, the characteristics of the virtual machine, the number of functionality that he wants

Suggest system architecture developer, etc.

As will be described below, some methods may be inherited by other classes according to the principles of the object-oriented language chosen for the application interface layer.

In particular, classes 92 MieuzhegRgoie, 93 KesogaegRgoie, 94 Ipiegpe(Rgoie, 95 BraiavgiddeRgoie define methods specific to defining user profiles VIEWER, VCR, INTERNET, 70 DATA gateway, etc. Classes 92-95 may have methods inherited from parent class 91 OzwegRgoie .

For example, using the command zeibSepegai|Angibshe (Айгирше, Майше ой Айгибтсшие) you can determine the value of the preferred attribute associated with one or another user profile.

In the case of a user profile for a viewer, in which the level of programs that this viewer can watch must be set, from the point of view of morality and ethics, in the context of programming profiles for the user 15 VIEWER, the team zeiSepegaiAngivbshe(Mogaiyu-I emei, 18) will set the age limit of authorization for this user. This value will be set and called by the high-level application; it can be used to prevent a VIEWER user from accessing certain demultiplexer channels until that operator reports his 20 Age. For each person who has access to the decoder in VIEWER mode, a set of settings can be defined in instances of the VIEWER class.

It is clear that defining a set of classes in the API for creating an identified "user" allows the system to easily define multiple user profiles for each of these users. Class introduction

OvegSaspeMapadeg allows you to operate with profile data located in the cache memory related to the User account, and generic classes OvegRgoPye and subclasses MiemzhegRgoye, KesogdegRgoPye, etc. provide the tools needed to define individual user profiles. and)

The specific composition and definition of methods and events within these classes is, of course, a matter at the discretion of the developer, and it is within the competence of one of ordinary skill in the art to establish the best definitions of such objects depending on the characteristics of the selected virtual machine, etc. - 30 2 in---- (Se) tt

Ki | she is 35! and | in. !

I Y5 7 St | their pl: | | shi s. » p DY Щ --- - vo And what! Plnvnnny M nn 1 -I zv - tt t i nyu 3 ZI 1 17 (o) V -h ie

Fu name) 60 b5 n Smart I Valkivska,

FI Y - Y KAGTA iy. CARD

I have a TEONER READING READING

SsmlEI-KARE Pachzhivskyi.

CARD 1 is consecutive

Y x--- PTTeREKIAS still I n 2 BO

DEMOCULATOR OF THE CONDITIONAL PRESENT PARTICLE OF THE PRESENT TENSE - PARACHLVNY I: INTERFACE 70 zo: I I PENTRALNAI 23

Demultiplexer

My I LAY in av

SNAU

GRAPHIC

8-3 PROCEDURE 35 7 dya

CUSTOM COLOR LEADING

AND AMPLIFIER RATIVISAM vok that dvotikid OO DAN

BI shchi vim Shch- shch

FIG. From o day I (Z ARY HIGH-LEVEL APPLIED PROGRAMS - 6 (6 F F - --- 50 B va 53 BA 55

MODULE modUL || nstrumen-| module SERVICE mo, in --

LANGUAGE/ МНЕО-5 ТАЛНИЙ | | FASHION DEVICES. MODULE | и зо UTILITIES Module DUL crafts so 46 47 48 49 45 re ayu pyv CHI rn : yu

І GRAPHIC || FILES INTERFACE HER INTERFACE 1! INTERFACE z-ya | INTERFACE || MEMORIES |! PROTOCOLS )| DEVICES

AND A VIRTUAL MACHINE!

AND

- 41

LOW-LEVEL OS - "ul - s dv le t ""SUBSYSTEM"?" ""SUBPROGRAM"" ""SUBPROGRAM"" and" FIG. 4 INTER DOOR FILE MANAGER

THE INTERPRETER OF THE RETATOR

BYTE-CODE t-kOdD x / -1 x of them in shk - 5 z - nok 67 ""SUBSYSTEM"" ""SUBSYSTEM"" ""SUBSYSTEM""

MANAGER MODULE | 4..... | MANAGER MODULE| 4... MODULE sl SECURITY OF INTERPRETER CLASSES -

Ge) 66 - ' / | . / M - in / SHY 6400 "SPIDSSYSTEM"X / : 63

M "SUBSYSTEM"

MANAGER MODULE men, u MANAGER MODULE 7 th. / and /

F i ' shk in ""SUBSYSTEM"" to MODULE

SCHEDULER in the "CONTENTS" section of the "UTILITY" section of the UTILITY section. SERVICE MANAGER

SERVICE MANAGER! AND MONITOR FLOWS 61 b5

FIG. 5

Cherofyl I definition

SPECTATOR Traditional cornetupya Fr

VCR The user of the system recording on the device of the UNU Fr

UERPSHTTEVNET 00000 user connected to the Internet FROM 00000000

WITH DATA GATEWAYS The user of the system that sends information to the

FIG. 6 o o o o o

TUNER | 81 in:

VI RESOURCES.

ENGLISH/FR/GERMAN| in 82

And she

Actions.

And with 7 FIG. 7 o'clock "-"so

IC) is a 7 and -

Claims (19)

The formula of the invention "40 1. A decoder made with the possibility of receiving data transmitted in a digital data transmission system, which includes a data processing system and memory, which is characterized by the fact that the data processing system "" is made with the possibility of storage in said profile data memory for each of the plurality of operating modes of the decoder, wherein the data of each profile includes resource data indicating the decoder resources available in the given operating mode and priority data indicating the priority of the given operating mode regarding 45 access to one or more decoder resources. - 2. Decoder according to claim 1, which differs in that the profile is defined as the one related to the connection - an external device. C. A decoder according to any of the preceding claims, wherein the profile is personalized with respect to the personality of the user of the decoder. FO 20 4. The decoder according to any of the previous items, which is characterized by the fact that the profile data includes data related to certain attributes of the information issued in each operating mode of the decoder. -WITH 5. A decoder according to any of the previous items, characterized in that the profile data includes data relating to actions allowed in each mode of operation of the decoder. 6. The decoder according to any of the previous items, which is characterized by the fact that some or all of the parameters or settings included in the profile data can be modified by the user during the normal operation of the decoder. at 7. A decoder according to any of the preceding items, characterized in that some or all of the profile data is predetermined by the data processing system of the decoder. where 8. A decoder according to any of the previous items, characterized in that the data processing system includes, among other things, a virtual machine and an object-oriented application program interface layer that 60 contains a plurality of class libraries. 9. The decoder according to claim 8, which is characterized by the fact that the application program interface layer contains one or more class libraries that define the operation of the virtual machine in relation to the profile data. Decoder according to claim 8 or 9, which is characterized by the fact that the application program interface level contains a class library designed to operate with profile data in the decoder memory. b5 11. Decoder according to any one of claims 8-10, characterized in that the application program interface layer contains one or more profile class libraries designed to define the characteristics of the data to be stored in the profiles. 12 Decoder according to claim 11, which differs in that the profile class libraries include a generic class library that defines the general characteristics of these profiles, and one or more subclass libraries that define the characteristics of individual profiles. 13. The method of functioning of the decoder, which is made with the possibility of receiving data transmitted in a digital data transmission system, and includes a data processing system and memory, which is characterized by the fact that it includes storing in said memory profile data for each of a plurality of decoder modes of operation, wherein the data of each profile includes resource data that indicates the decoder resources available in 7/0 a given mode of operation, and priority data that indicates the priority of the given mode of operation for accessing one or more decoder resources . 14. The method according to claim 13, which is characterized by the fact that the profile is defined as one related to the connection of an external device. 15. The method according to claim 13 or 14, characterized in that the profile is personalized with respect to the personality of the 7/5 User of the decoder. 16. The method according to any one of claims 13-15, which is characterized in that the profile data includes data related to certain attributes of the information issued in each operating mode of the decoder. 17. The method according to any one of claims 13-16, characterized in that the profile data includes data relating to actions allowed in each mode of operation of the decoder. 18. The method according to any one of claims 13-17, characterized in that some or all of the parameters or settings included in the profile data can be modified by the user during normal operation of the decoder. 19. The method according to any one of claims 13-18, characterized in that some or all of the profile data is predetermined by the data processing system of the decoder. Official bulletin "Industrial Property". Book 1 "Inventions, useful models, topographies of integrated microcircuits", 2004, M 12, 15.12.2004. State Department of Intellectual Property of the Ministry of Education and i) Science of Ukraine. "- (Se) IF) "- - - with . and? -I - 1 (o) - name) 60 b5