MXPA00008604A - Multimedia terminal adapted for multiple users - Google Patents

Multimedia terminal adapted for multiple users

Info

Publication number
MXPA00008604A
MXPA00008604A MXPA/A/2000/008604A MXPA00008604A MXPA00008604A MX PA00008604 A MXPA00008604 A MX PA00008604A MX PA00008604 A MXPA00008604 A MX PA00008604A MX PA00008604 A MXPA00008604 A MX PA00008604A
Authority
MX
Mexico
Prior art keywords
data
terminal
user profile
user
terminal according
Prior art date
Application number
MXPA/A/2000/008604A
Other languages
Spanish (es)
Inventor
Francois Rey
Original Assignee
Canal+ Societe Anonyme
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canal+ Societe Anonyme filed Critical Canal+ Societe Anonyme
Publication of MXPA00008604A publication Critical patent/MXPA00008604A/en

Links

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

ULTIMEDIA TERMINAL ADAPTED FOR MULTIPLE USERS The present invention relates to a terminal for processing digital audiovisual multimedia data. Terminals of this type are well known in the field of pay TV systems, where a decoder or upper box receives the transmission of the digital multimedia data, which includes the information of the audiovisual program, as well as the data to generate menus in-screen, the data to implement games or purchase applications, and so on. Depending on the system, the data can be transmitted in a coded or clear way. Before the introduction of digital technology, the encoders were connected to a limited number of devices, usually only a visual display of the associated television, or at most, a visual display of television and a VHS recorder. The arrival of digital technology has caused an explosion in the number of devices that can be connected to the encoder as well as in the functionality of the encoder. For example, in addition to a Peritel analogue output to a TV and the VHS device, the encoder may also include a connection via a digital busbar, such as the IEEE 394 busbar, to other digital devices such as a _DVD recorder, a PC, etcetera.
As a complement to the increase in the number of external devices that can be connected to the encoder, the number of operating modes of a device has been increased. For example, in the standard arrangement of the encoder and the television, the encoder can be used either to simply provide transmission information on television, or to provide a connection to the internet. When evolving from the traditional analog system, the architecture of digital encoders that are currently known tend, however, to follow the preconceived ideas that direct their designs. In particular, the architecture of standard encoders does not exactly reflect the role of a terminal in sending data between. many external devices in parallel, the modes of operation of the encoder and the number of system users that may exist. In accordance with the present invention, there is provided a terminal for processing digital multimedia data or multimedia data that includes a system for processing data and a memory, characterized in that the system for processing data stores in the memory the profile data of user related to the characteristics or preferences of a plurality of types of terminal users.
The definition of a user profile allows the system to process flexibly handle and manage a number of users of the terminal. As will be appreciated, while a user profile may be associated with the connection of an external device or the personal identity of the operator having access to the terminal, it is preferably associated with one mode of operation, for example, the mode of operation. Internet or television mode. The user profile can also be customized for one or more operators. For example, after defining a user profile for the operation mode of the terminal's internet, it is possible to define a first internet operator that has certain rights and a second operator that has other rights. Conveniently, the user profile data includes the resource data indicating the resources within the terminal that are accessible to each user. In the case of a coding terminal, these resources may include access rights to the demultiplexer to determine the download of data from the data stream in the transmission, and so on. More conveniently, the user profile data includes the priority data indicating the priority of each user with respect to accessing one or more resources of the terminal. For example, for a coding terminal, the user profile data may include a priority level that indicates which is the priority that a particular user has for accessing the demultiplexer. The demands of conflicting channels between, for example, a user of a TV device and a user of a recording device can be resolved in the following by means of an administration application based on this information. In addition to the resource data that tells the terminal what resources are available to a specific device, the user profile data also includes the data that relates to the attributes of the information that will be provided to each user. These attributes may include, for example, an indication of the language to be used in all visual displays of the graphical interface for that user. In addition, the user profile data can also include data that is related to the actions allowed by each user, such as if a certain user can change the demultiplexer channel, and so on. Even though it is intimately related to the resource data described above, this data can be used to define the parameters of the operations allowed by each device that has access to a particular resource. Preferably, some or all of the characteristics of the user profile data during the normal operation of the terminal by an operator may be modified. For example, you can modify the relative priority values of each user to access the data through a viewer to give priority to an output of a certain VHS recorder over a television output, or a connection priority to the internet over television, and so on. In addition, alternatively, some or all of the user profile data can be determined previously by means of a system for processing terminal data. The present invention is particularly adapted to a terminal comprising a system for processing data comprising, among other things, a virtual machine and a layer of the application interface oriented to an object comprising a plurality of class libraries. In particular, the layer of the application interface may comprise one or more class libraries that define the operation of the virtual machine with respect to the user profile data. These classes may include, for example, a class library dedicated to the management of the user profile data in the terminal's memory cache. Similarly, the classes may include one or more class libraries of the user profile to define the characteristics of the data to be stored in the user's profiles. For example, you can use a method class to define the attributes of the preferred language to be stored in the user profile. The behavior of the classes within the application interface will depend on the chosen language. In the case of an application interface written in Javanese, for example, you can apply a single structure of succession between a class and its subclasses. In one embodiment, the user profile classes may include a generic class library associated with the definition of generic characteristics of the user profile data, and one or more subclass libraries associated with the definition of the characteristics associated with a profile of specific user. The present invention is particularly applicable to a terminal in the form of an encoder adapted to receive data transmissions in a digital transmission system. Likewise, the present invention can be extended to a method of operation of a terminal. - The term "encoder" can describe a receiver to receive either encoded or non-encoded signals, for example, television and / or radio signals.
Modes such as an encoder may "include an integral encoder with the receiver to encode the received signals, for example, in an upper case, such as an encoder operating in combination with a physically separate receiver, or an integrated encoder with additional elements. , such as a Web browser or a video recorder or a television As used herein, the term "digital transmission system" includes any transmission system for transmitting or broadcasting, for example, primarily audiovisual or digital multimedia data. While the present invention is particularly applicable to a transmission of a digital television system, the invention may also be applicable to a fixed telecommunications network for multimedia internet applications, to a closed circuit television, and so on. Then, a pref option will be described as an example only of the invention in which: Figure 1 shows a digital television system that includes a multimedia terminal in the form of an encoder. Figure 2 shows the physical elements of the encoder of Figure 1. Figure 3 shows the architecture of the system software to process data within the encoder. Figure 4 shows the structure of a virtual machine used in the system to process data of Figure 3.
Figure 5 shows a set of user profiles previously determined to be defined in this embodiment of the invention. Figure 6 shows the elements of the user profile data in the encoder memory for each user profile of Figure 5; and Figure 7 shows the structure of the class libraries within the application interface layer of the software architecture to be used in the definition of user profiles. In Figure 1 there is shown an overview of the digital television system 1 in accordance with the present invention. The invention includes a mostly conventional digital television system 2 which uses the known MPEG-2 compression system to transmit compressed digital signals. In more detail, the MPEG-2 compressor 3 in a transmission center receives a stream of digital signals (typically a stream of video signals). The compressor 3 is connected to a multiplexer and encoder 4 by means of the link 5. The multiplexer 4 receives a plurality of additional input signals, assembles the transport current and transmits the compressed digital signals to a transmitter 6 of the transmission center by means of of link 7, which can, of course, take on a wide variety of forms including telecommunications links. The transmitter 6 transmits electromagnetic signals by means of the uplink 8 to a satellite transmitter-receiver 9, where these are processed electronically and transmitted by means of a national downlink 10 to a terrestrial receiver 12, which conventionally has the form of a dish owned or rented by the end user. The signals received by the receiver 12 are transmitted to an integrated receiver / encoder 13 owned or rented by the end user and connected to the television set 14 of the end user. The receiver / encoder 13 encodes the compressed signal MPEG-2 to a television signal for the television set 14. Of course other transport channels are possible for the transmission of the data, such as a terrestrial transmission, a cable transmission , combined satellite / cable links, telephone networks, etcetera. In a multi-channel system, the multiplexer 4 handles the audio and video information received from a number of sources in parallel and interacts with the transmitter 6 to transmit the information along a number of corresponding channels. In addition to audiovisual information, you can enter messages or applications or any other type of digital data in some or all of these channels interlaced with the digital information transmitted audio and video. A conditional access system 15 is connected to the multiplexer 4 and the receiver / encoder 13, and is located partially in the transmission center and partially in the encoder. The above allows the end user to have access to digital television transmissions from one or more transmission providers. A smart card, capable of deciphering messages that relate to commercial offers (that is, one or many television programs sold by the transmission provider), can be inserted into the receiver / encoder 13. By using the encoder 13 and the smart card, the end user can buy commercial offers either in subscription mode or in a pay-per-event mode. In practice, the encoder can be configured to handle multiple access control systems, for example, the design of the Simulcrypt or the Multicrypt. As mentioned above, the programs transmitted by the system in the multiplexer 4 are coded, the conditions and the coding keys are applied to a certain transmission that has been determined by means of the access control system 15. The transmission of the encoder data are well known in the field of pay TV systems, typically, the encoded data is transmitted together with a control word for the decoding of the data, the control word itself being encoded by the called operation key and transmitted in encoded form, then the encoded data and the coded control word are received by the encoder 13 having access to an equivalent of the operating key stored in a smart card inserted in the encoder to encode the encoded control word and subsequently decode the transmitted data. A paying subscriber will receive, For example, in a monthly ECM transmission (Right Control Message), the exploitation key needed to decode the coded control word to be allowed to see the ansmission. An interactive system 16, also connected to the multiplexer 4 and the receiver / encoder 13 and - again located partially in the center of the transmission and partly in the encoder, allows the end user to interact with various applications by means of a modem backup channel 17. The backup channel modem can also be used for communications used in the conditional access system 15. An interactive system can be used, for example, to allow the viewer to communicate immediately with the transmission center to demand authorization to see a particular event, to download an application, and so on. With reference to Figure 2, the physical elements of the receiver / encoder 13 or upper box adapted to be used in the present invention will be described below. The elements shown in this figure will be described in terms of functional blocks. The encoder 13 comprises a central processor 20 which includes associated memory elements and adapted to receive the input data of a serial interface 21, a parallel interface 22, and a modem 23 (connected to the modem of the backup channel 17 of Figure 1). The encoder is further adapted to receive the inputs of an infrared remote control by means of a control unit 26 and the switch contacts 24 in the front panel of the encoder. The encoder also has two smart card readers 27 and 28 for reading bank or subscriber smart cards 29 and 30, respectively. The entrance can also be received by means of infrared keyboard (not shown). The subscriber smartcard reader 28 is engaged with an inserted subscription card 30 and with a conditional access unit 29 to supply the control word necessary for a demultiplexer / decoder 30 to enable the encoded transmission signal to be decoded The encoder also includes a conventional tuner 31 and a demodulator 32 for receiving and demodulating the satellite transmission before it is filtered and demultiplexed by the unit 30. The central processor 20 generally handles data processing within the encoder. The architecture of the central processor software corresponds to a virtual machine that interacts with a lower-level operating system implemented in the hardware components of the encoder.
ARCHITECTURE OF THE CODING SYSTEM Returning now to the architecture of the system within the receiver / encoder shown in Figure 3, it will be seen that a layered architecture is used. The first layer 41 represents the hardware operating system of the receiver / encoder. This is a real-time operating system selected by the manufacturer to control the hardware elements of the receiver / encoder. The real-time operating system has a relatively fast response time in order to correctly synchronize hardware operations. Event messages are passed between this layer and the middleware layer 42 that is immediately above. The system for processing data sits at the tip of the hardware operating system and comprises a middleware layer 42 and a layer of the application interface 43. The middleware layer 42 is written in a language such as C ANSI and comprises the elements of a virtual machine 44 and a number of interfaces 45 including a graphical interface 46, a memory interface 47 FLASS / PROM, a protocol interface 48 and a device interface 49. The present invention uses a virtual machine in order to provide independence between Top-level applications and the lower-level operating system implemented by the manufacturer of the upper box. The interface 45 provides the link between the operations and the virtual machine and the lower level operating system 41 and also includes a number of intermediate level application modules that are more easily executed at this level. The application interface layer 43 (API) comprises a number of high-level packets 50-55, written in an object-oriented interpretive language, such as Javanese. These packages provide an interface between the applications created by the service provider (interactive program guide, teleshopping, internet browser, etc.) and the virtual machine of the system. Following are examples of such applications. The OS, for its acronym in English, (Operating System) lower level is usually embedded in the hardware components of the encoder, although in some embodiments, you can download the lower level OS. Middleware interface layer packages and applications can be downloaded into the encoder RAM or FLASH from a broadcast transmission. Alternatively, some of the elements of the middleware or application interface layers can be stored in the ROM memory or (if available) the encoder FLASH. The encoder may even include a hard disk or a DVD drive for memory storage purposes. As can be understood, the physical organization of the elements of the encoder memory is distinctive of the logical organization of the memory.
LAYER OF THE APPLICATION INTERFACE Referring to the layer of the application interface 43, and as described above, the packets in this layer are written with a language oriented to an object such as Javanese. Each packet defines a set of class libraries called during the operation of the system. In the present system the following packages are installed. Lang / util 50 package. This package defines the classes that are necessary for the manipulation of objects by means of the virtual machine. These calse libraries are normally part of a standard library associated with the language oriented to an object that has been selected. Package 51 MHEG-5. This package defines the classes associated with the manipulation of graphic objects in the visual display of television. Such objects are distinctive of the audiovisual data and can make, for example, channel identifiers or text that is placed on the images that are displayed visually. The definition of classes within this package must respect the MHEG-5 standards defined by the ETS 300777-3 and ISO / ISE 13522-5 standards (and the ISO / ISE 13522-6 standard in the case that a Javanese system). Toolbox Package 52. This package contains the classes that are used to download and decompress the information as well as the classes associated with the administration of the file system and memory within the receiver / encoder and the classes associated with the connection to the internet, etc. Device Package 53. This package defines the classes that are necessary for the administration of peripherals attached to the receiver / encoder, as discussed above and that includes the modem, the smart card readers, the MPEG stream tuner, and so on. Service Pack 54. This package defines the classes that are necessary for the implementation of develops. higher-level interactive applications, such as the management of credit card data, and so on.
DSMCC-UU 55 package. This package implements the protocols that are necessary to establish communication between a client and a server for searching and reading the file data. The implementation of this package should be subject to ISO / IEC 13818-6 and the directives that are defined in DAVIC part 9. In a normal operation, an additional layer of interactive applications, written by the service provider and downloaded during transmission as in conventional systems, they will travel on the interface packets defined above. These applications typically include a general application administrator to manage the basic defined operations of the encoder, and one or more optional applications that add additional services. In particular, a user administrator application can be used to manage the user's priority conflicts, as described below. Depending on the applications to be introduced, some of the previous packages may be omitted. For example, if the service provider does not attempt to provide a common way of reading the data, the DSMCC-UU package from the last system may be left out. The packets 43 provide class libraries for an object-oriented programming environment. The behavior of your class will depend on the selected language. In the case of a Javanese application, for example, a single structure of inheritance class will be appended to it. As can be understood, the grouping of a class or a set of classes in a package is pure formality with respect to the functionality of a class. Certain classes related to the administration of peripheral devices may be, for example, classified as belonging to Device Pack 53 or Service Pack 54.
LAYER OF THE INTERFACE As shown, the interface layer is composed of four modules, a graphics module 46, a memory file management module 46, a protocol module 48, and a device manager 49. While the modules in this level are described as modules of the interfaces, their function is to provide a layer of "glue" for the implementation of the interface packets and for the operation of the virtual machine in general. The graphics module 46, for example, provides for the creation and administration of graphic objects. The latter requests the lower level OS to visually display basic graphic forms such as simple pixels, lines, rectangles, and so on. The implementation of this module depends on the graphics capability of the lower level OS of the manufacturer. Complementary to package 51 MHEG-5 in some way, these functions can be executed more efficiently at this key level than in the high-level code chosen for the previous application layer. Similarly, the memory file management module 47 includes the read / write file commands associated with the components of the system memory. Typically, the hardware operating system only includes the commands necessary to read / write a sector or page within a memory component. As with the graphics module 46, this module enables a set of simpler low-level applications to be efficiently introduced into the system. The protocol management module 48 defines a library of the communication protocols that can be called upon by entering communication through, for example, the TCP / IP layer of the encoder. The device manager 49 is slightly different from the other modules in this layer in that it provides the link or interface between the hardware operating system and the previous layers, which include the other modules in the interface layer and the virtual machine . The commands or messages of events that are received / sent to the hardware OS from the virtual machine, for example, are necessarily passed by the device administrator for conversion in accordance with the specifications of the interface between the two levels.
DESCRIPTION OF THE VIRTUAL MACHINE Referring now to Figure 4, the structure of the virtual machine 44 used in the system of the present invention will be described. The virtual machine used in the present invention is a type of multiprocessing machine of preference. The general characteristics of such a machine are known in other contexts and the creation of keys for the implementation of such a machine will be within the reach of someone skilled in the art. The virtual machine is composed of a number of elements, which interact widely as shown in Figure 4. Programmer 60, composed of a process management service 61 and a monitor 62 administration service, form the heart of a multiprocessing machine. The scheduler 60 orders the execution of processes created by applications externally of the virtual machine and those created by the same virtual machine (for example, a garbage collection process as discussed below). The event administrator 63 manages a table to route the events and the list of events subscribed through the processes and centralizes the dispatch of event treatments. The memory manager 64 handles the allocation and de-allocation of the memory areas within the system memory and also handles the removal of objects without reference (garbage collection) from the memory. The class manager 65 loads the downloaded application code classes into a transmission signal, which interacts with the security administrator 66 to verify the integrity of the downloaded code and with the file manager 68, which implements the applications. The file manager 68 carries out the implementation of the system files and manages the mechanism of downloading the interactive applications and the data. The security administrator 66 manages the level of access allowed to the downloaded applications, some applications that have the ability to carry out more operations than others in relation to the file system. The interpreter 67 comprising an interpretation service 69 of the byte code and an interpretation service of the "m-code" 70 handles the interpretation of applications written in these two codes, the byte code that is associated with the Java applications and the m-code which is the name that has been given to an owner code developed by the applicants.
USER PROFILE The increasing power to process the hardware available in the encoders has motivated the increasing use of encoders to route information among a number of potential users of the system. For example, a single IRD can serve as the entry point for an MPEG stream, this stream that is being processed and diverted to one or more visual displays of connected televisions, a VHS analog recorder connected through a Peritel link, a PC or DVD device connected through an IEEE 1394 bus, and so on. A central idea of the present modality is the definition of a number of "users" of the encoder, each user having a profile with certain characteristics. For example, a high-level application can define a number of user profiles for a viewer, a VHS recorder, a person who uses the encoder directly to access the internet, a person who uses the encoder to route information to a PC , etc. Figure 5 shows an example of a set of typical user profiles. You can extend this list to include, for example, a DVD device connected to the encoder, and so on. A user profile can be defined in relation to an external device connected to a terminal, for example the television connection, where the terminal simply supplies audiovisual data to the visual display of the television. The user profile can also be defined in relation to the current identity of one or more physical persons or "operators" who have access to the terminal. In the present case, however, a user profile is defined in relation to a mode of operation of the device, such as its operation in an internet mode. Each user profile defined for an arrangement or mode of operation can be customized for the different people who use the coding terminal. For example, one person may have different program preferences than another, or be barred from viewing certain channels. The information regarding the preferences of each person is stored within the user's profile for that mode of operation. - Each user profile will have a singular and characteristic ID (Identification) of user and one or more priority values that determine the priority of this user to obtain one or more resources to encode. In this case, the term "resources" refers to a functionality in the encoder such as access to the demultiplexer to download the selected data. The high-level application administrator defines and stores the characteristics of these profiles and manages the participation of the user's resources and conflicts with reference to the user's priority. For example, a user administrator can give priority to a user of the "RECORDER", for example, in such a way that a demand by this user to use a given resource will have priority over a demand by the user "TELEVIDENTE" to use that resource . In particular, the user of the "RECORDER" may have preference over the "TELEVIDENT" user as regards the choice of the demux channel. In this way, the application prevents the priority of a change of the channel signal received from a viewer by someone who wishes to record a program that is being transmitted at the same time. In this example, where a single priority value is assigned to each user, the user of the "RECORDER" will always have priority over the "TELEVIDENT" to access any resource. Alternatively, multiple priority values can be assigned, such as that "TELEVIDENT" has priority for certain resources, the priority of "RECORDER" for others, and so on. The user manager handles the evaluation of the priority and can be interactive, that is, by programming the encoder with the microtelephone apparatus, an operator can determine whether it gives priority to an internet connection rather than watching television, etc. Each user profile includes, in addition to the user ID value, a set of preferences stored in a cache in the encoder, for example, in the FLASH memory of the encoder. These preferences will be called by the application at each start of the encoder. As shown in Figure 6, the profile data of the user 80 includes the resource data 81, the attribute data 82, and the action data 83. The resource data 81 includes a list of internal resources of the encoder to the which the user can access, for example, access to the MPEG tuner and the decoder. As can be understood, a resource in this context refers to a logical resource that is related to a combination of physical elements associated with a demux process, a conditional access system, and so on. The attribute data 82 includes the preferred attributes to that user, for example, the language (English, French, German, etc.) to be used preferably in visual displays written on the screen, the level of morality of the programs that the user can see, etcetera. The action data 83 includes a list of allowed actions that the user can carry out, which includes the change of channel, and so on.
The user's profile data can include fixed values previously determined by the user's administrator (for example, all users can exercise their ability to access the resources of the tuner, the demultiplexer, etc.) as well as customizable and customizable values to each operator capable of using the terminal in each mode of operation (level of morality of the programs that can be seen, etc.). The values that can be modified by the user can include the values for each user profile established by an operator when the encoder is turned on, as well as the values established by an operator each time a session with a particular user profile is started. The definition of multiple user profiles that correspond to the modes of operation and that include the data related to the priority to the resources of the terminal for "each profile prepares the way for the parallel process of such modes by the terminal in such a way that allows, for example, that a single terminal manages and processes the data to be able to see by means of a television at the same time that it sends different data that an associated recording device must record, or be treated by a PC, etc. In such systems , the terminal effectively becomes a data center for a number of associated peripheral devices operating in parallel.This kind of operation is particularly well handled by a multiprocess system of the type shown in relation to Figures 3 and 4, and as will be described below: In order to allow the creation of a series of user profiles, it is desirable to include within the AP layer I objects of classes adapted to engage with the visual machine to achieve the above. Referring again to Figure 3, and as discussed above, the class libraries defined in the API layer 43 provide the operating parameters within which the applications of the highest level can operate. In particular, when carrying out certain actions, a high-level application will include instructions that refer to the classes of the objects defined in this layer. Each class will respect the rules of the chosen language of object-oriented programming for this layer. Typical object classes include classes that relate to the management of the encoder ports, such as the credit card interface, as well as other operations such as administration of the access control system. A number of standard classes in the API layer have been defined by the DAVIC group in relation to, for example, access to sections and tables in a downloaded MPEG stream. Now, a class structure adapted to provide the possibility of defining user preferences for each such user and to facilitate handling of multiple users by means of a high level application will now be described with reference to Figure 7. The classes that will be described can be included, for example, in Service Pack 54 installed in the API layer 43. Referring to Figure 7, a UserCacheManager class that is shown in number 90 is used for Allow applications to access and manage the user profile data stored in the system cache. This class is a static class. As in the standard architectures of object-oriented programs, the class library includes a list of methods or commands such as an initialise () method to initialize the cache, a getMaxUserProfiles () method to know the maximum number of users that the system will support, a getActiveUserID () method to know the number of currently active users, and so on. The class can also be associated with a list of events, which point out to the application the occurrence of an event, such as the creation or deletion of a user profile. Additionally the classes include a UserProfile class that is shown in the number 91. This class is a generic class, adapted to allow the creation of a number of user profiles. The class includes a list of methods such as getUserID to retrieve the identity of a user, getPriorityLevel () to retrieve the priority of access to resources, setGeneralAttribute () to set the value of a general attribute, and so on. The class is also associated with a list of events that indicate, for example, a channel change requested by a user, and so on. The above methods are methods that allow indirect access to the methods, thus avoiding the need to have a method for each attribute. The number of attributes managed by these methods will depend on the choice of the architect of the system and may evolve over time. In practice, the selection and functionality of the number of methods in this and other classes can also be determined at the discretion of the system architect and depending on the power to process the hardware, the characteristics of the virtual machine, the number of functionalities that the system architect wants to enter, and so on. As will be described, other classes may inherit some of the methods in accordance with the principles of the object-oriented language that has been selected for the layer of the application interface. -In particular, the classes ViewerProfile 92, RecorderProfile 93, InternetProfile 94, DataBridgeProfile 95, define methods specific to the definition of the user profile VIEWER (TELEVIDENTE), RECORDER (RECORDER), INTERNET, DATA_BRIDGE (DATA_TOP) and so on. Classes 92 through 95 can include methods inherited from the generic UserProfile 91 class. For example, by using the setGeneralAtribute command, you can determine the preferred value of an attribute associated with the user profile in question. In the case of a viewer profile in which the level of morality of a viewer is to be defined, the instruction: setGeneralAtribute (Level -Morality, 18) in the context of programming profiles for the user, VIEWER will establish a limit of age authorized for this user. This value will be defined and summoned by a higher level application and can be used to prevent access by the VIEWER user to certain demux channels, unless the operator declares his age. For each person who has access to the encoder in VIEWER mode, a set of preferences can be defined in this way by means of instances within the VIEWER class. As can be understood, the definition in the API of a number of classes specific to the creation of an identified "user" allows the system to easily define a plurality of user profiles for each of these users. The provision of a UserCacheManager class allows the handling of the cache profile data related to a user, while the generic UserProfile classes and the subclasses ViewerProfile, RecorderProfile, etc., provide the necessary tools for the definition of each user profile. However, the composition and exact definition of the methods and events within these classes is discretionary and it will be within the competence of a person skilled in the art to determine the best definition of such objects that depend on the characteristics of the selected virtual machine, etc. .

Claims (19)

1. A terminal for processing audiovisual or multimedia digital data that includes a system for processing data and a memory, characterized in that the system for processing data stores in the memory the user profile data that relate to the characteristics or preferences of a plurality of types of terminal users.
2. A terminal according to claim 1, wherein the user profile is defined in relation to a mode of operation of the terminal.
3. A terminal according to claim 1 or 2, wherein the user profile is defined in relation to the connection to an external device.
4. A terminal according to any of the preceding claims, wherein a user profile is personalized in relation to the identity of the operator.
5. A terminal according to any of the preceding claims, wherein the user profile data includes the resource data indicating the resources within the terminal accessible to each user.
6. A terminal according to claim 5, wherein the user profile data includes the priority data indicating the priority of each user with respect to accessing one or more resources of the terminal.
7. A terminal according to any of the preceding claims, wherein the user profile comprises the data that relates to the information attributes that must be supplied to each user.
8. A terminal according to any of the preceding claims, wherein the user profile comprises the data that is related to the actions allowed by each user.
9. A terminal according to any of the preceding claims, wherein some or all of the characteristics or preferences of the user profile data are modifiable by an operator during the normal operation of the terminal.
10. A terminal according to any of the preceding claims, wherein some or all of the user profile data is previously determined by means of the system to process data from the terminal.
11. A terminal according to any of the preceding claims, wherein the terminal comprises a system for processing data comprising, among other things, a virtual machine and an application interface layer oriented to an object comprising a plurality of libraries of classes.
12. A terminal according to claim 11, wherein the application interface layer may comprise one or more class libraries that defines the operation of the virtual machine with respect to the data of the user profile.
13. A terminal according to claim 11 or 12, wherein the application interface layer comprises a class library dedicated to managing the memory of the user profile data in the terminal cache.
14. A terminal according to claims 11 to 13, wherein the application interface layer comprises one or more class libraries of user profiles adapted to define the characteristics of the data to be stored in the user profiles. . A terminal according to claim 14, wherein the user profile class libraries comprise a generic class library associated with the definition of the generic characteristics of the user profile data, and one or more subclass libraries associated with the definitions of the characteristics associated with a specific user profile. 16. A terminal according to any of the preceding claims comprising an encoder adapted to receive data transmissions in a digital transmission system. 17. A method of operating a terminal to process audiovisual or digital multimedia data that includes a system for processing data and a cache memory characterized by the step of storing in the terminal memo the user profile that is related to the characteristics or preferences of a plurality of terminals of the terminal . 18. A terminal for substantially processing audiovisual or digital multimedia data as described therein. 19. A method of operating a terminal to substantially process the digital audiovisual or multimedia data as described therein.
MXPA/A/2000/008604A 1998-03-06 2000-09-01 Multimedia terminal adapted for multiple users MXPA00008604A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP98400541 1998-03-06

Publications (1)

Publication Number Publication Date
MXPA00008604A true MXPA00008604A (en) 2001-07-31

Family

ID=

Similar Documents

Publication Publication Date Title
US6981042B1 (en) Multimedia terminal adapted for multiple users
USRE40538E1 (en) Downloading of applications in a digital decoder
US7984478B2 (en) Method and apparatus for a receiver/decoder
RU2257687C2 (en) Data table about applications for digital transfer system, offering multiple services
CN100476683C (en) Equipment for processing data, receiver and decoder thereof
US20040100490A1 (en) Skin button enhancements for remote control
EP0908821A1 (en) Digital code interpreter
KR20020035561A (en) Apparatus for and method of testing applications
MXPA00008604A (en) Multimedia terminal adapted for multiple users
Fotschl et al. Interactive applications for the multimedia home platform
EP0909091A1 (en) Memory manager
WO1998043172A2 (en) Access control system
EP1286549A2 (en) Receiver/decoder and module for use with a receiver/decoder
CZ20003254A3 (en) Terminal for processing digital data and operation process thereof
López-Ardao et al. Experiences from implementing a MHP receiver
MXPA01003050A (en) Application data table for a multiservice digital transmission system
MXPA99008545A (en) Access control system