AU742213B2 - Access control system - Google Patents

Access control system

Info

Publication number
AU742213B2
AU742213B2 AU26385/97A AU2638597A AU742213B2 AU 742213 B2 AU742213 B2 AU 742213B2 AU 26385/97 A AU26385/97 A AU 26385/97A AU 2638597 A AU2638597 A AU 2638597A AU 742213 B2 AU742213 B2 AU 742213B2
Authority
AU
Australia
Prior art keywords
application
receiver
decoder
device
logical device
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
AU26385/97A
Other versions
AU2638597A (en
Inventor
Christophe Declerck
Jerome Meric
Jean-Claude Sarfati
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canal Plus SA
Original Assignee
Canal Plus SA
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
Priority to EP97400650 priority Critical
Priority to EP97400650 priority
Application filed by Canal Plus SA filed Critical Canal Plus SA
Priority to PCT/EP1997/002115 priority patent/WO1998043172A2/en
Publication of AU2638597A publication Critical patent/AU2638597A/en
Application granted granted Critical
Publication of AU742213B2 publication Critical patent/AU742213B2/en
Anticipated expiration legal-status Critical
Application status is Ceased legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00Image coding
    • G06T9/007Transform coding, e.g. discrete cosine transform
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309Transmission or handling of upstream communications

Description

-1- ACCESS CONTROL SYSTEM Field of the Invention The present invention relates to an access control system, in particular to a method of providing access by a program to at least one component of a computer system, more particularly of a computer system used in a receiver/decoder of broadcast digital signals.

Background The advent of digital transmission systems intended primarily for broadcasting television signals, in particular but not exclusively satellite television systems, has opened up the possibility of using such systems for other purposes. One of these is to provide o interactivity with the end user.

One way of doing this is to run an application on the receiver/decoder through which the television signal is received. The code for the application could be permanently stored in the receiver/decoder. However, this would be rather limiting.

is Preferably, the receiver/decoder should be able to download the code for a required application. In this way, more variety may be provided, and applications can be updated as required without any action on the part of the user.

~Applications for execution by a receiver/decoder are generated by various broadcast suppliers. Typically, the receiver/decoder has a number of interfaces, such as a S 20 serial interface and parallel interface, for connection to external units. Device drivers for S: ••these interfaces are supplied by the manufacturer of the receiver/decoder. With multiple sources of applications and multiple manufacturing sources of receiver/decoder, it is important that one application behaves in the same way on every receiver/decoder, and each receiver/decoder should execute every application in the same, correct manner.

Summary of the Invention In accordance with one aspect of the invention, there is disclosed a method of enabling an application stored in and executable on a receiver/decoder to receive a message concerning a function performed by a component of said receiver/decoder, said method comprising the steps of: storing in said receiver/decoder logical devices, each logical device representing a respective function of the receiver/decoder and being separate from the component of said receiver/decoder for performing that function, each logical device having a respective device identifier; TR 4-assigning an application identifier to the application; and [R:\LIB00]051 56.doc:iad -2outputting from the application a signal comprising the application identifier and the device identifier of a logical device from which the application wishes to receive messages concerning the function of the receiver/decoder which that logical device represents; s receiving said signal at a device manager provided between the application and each logical device, said device manager storing for the logical device identified by said identifier said application identifier to enable said application to receive a message output from that logical device concerning the function of the receiver/decoder which that logical device re In accordance with another aspect of the invention, there is disclosed apparatus S1: for enabling an application stored in and executable on a receiver/decoder to receive a message concerning a function performed by a component of said receiver/decoder, said e apparatus comprising: means for storing in said receiver/decoder logical devices, each logical device 15 representing a respective function of the receiver/decoder and being separate from the component of said receiver/decoder for performing that function, each logical device having a respective device identifier; means for assigning an application identifier to the application; and a device manager provided between the application and each logical device for receiving from the application a signal comprising the application identifier and the device identifier of a logical device from which the application wishes to receive messages concerning the function of the receiver/decoder which that logical device represents, and for storing for the logical device identified by said identifier said application identifier to enable said application to receive a message output from that logical device concerning the function of the receiver/decoder which that logical device represents.

By means of the above, a common interface can be provided between the various programs in the computer system and the "hardware" of the receiver/decoder, irrespective of the sources of the programs and the hardware.

The signal may further comprise a command enabling receipt by the program of a message output from a respective logical device indicating a change of state of the component associated with the device.

Thus, a program may be alerted to an "unexpected event" occurring at one of the components, for example, the receipt of a message by a serial interface of the computer I system or the insertion of a smartcard in a smartcard reader of the computer system.

[R:\LIB00]05156.doc:iad This message may be stored temporarily in queue means of said computer system for subsequent transfer to said program. In other words, the program may inform the logical device that it need not be supplied immediately with the message.

Preferably, the queue means comprises a plurality of queues, each queue having a respective priority level indicative of the order in which messages are to be transferred from the queue means to the program, and said signal further comprises the priority level of the queue in which said message is to be stored temporarily.

Thus, the program may specify the "urgency" with which the message is to be dealt with by the queue means by indicating a priority level with which the queue means is to deal with the message.

Thus, the preferred embodiment of the present invention provides a single common interface for communication between a program and one or more logical S• •devices, and for communication between a logical device and one or more programs.

Therefore, once access between the program and the component has been 15 provided, the thus established communication route may be used to provide a route for transmitting data from the program to a component and vice versa.

The program and/or the or each logical device may be input to said computer system via a component. This provides for convenient downloading and "up-dating" of the program and the logical device in the computer system.

20 Preferably, the or each component comprises at least one of an MPEG flow oo tuner, a serial interface, a parallel interface, a modem and a smartcard reader.

.i The apparatus may further comprise means for enabling receipt by the program of a message output from a respective logical device indicating a change of state of the component associated with the device.

Preferably, the computer system further comprises queue means for storing temporarily a message output by said device for subsequent transfer to said program. The queue means may comprise a plurality of queues, each queue having a respective priority level indicative of the order in which messages are to be transferred from the queue means to the program.

The computer system may further comprise means for storing data input to said component by said device and data output by said component to said logical device to said common interface.

Preferably, the or each logical component is connected to the respective associated component via a device driver.

[R:\LIBOO]05156.doc:iad Preferably, the receiver/decoder further comprises means for receiving a compressed MPEG-type signal, means for decoding the received signal to provide a television signal and means for supplying the television signal to a television.

Brief Description of the Drawings Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which: Figure 1 shows the overall architecture of a digital television system according to the preferred embodiment of the present invention; Figure 2 shows the architecture of an interactive system of the digital television system; Figure 3 shows the arrangement of files within a module downloaded into the S- memory of an interactive receiver/decoder; :•.-•Figure 4 shows the arrangement of memory volumes of the memory of the interactive receiver/decoder; Figure 5 is a schematic diagram of interfaces of the receiver/decoder; Figure 6 shows the architecture of the software in the receiver/decoder; and Figure 7 shows an example of connections between a device manager, a plurality of clients and a plurality of devices.

Detailed Description 20 An overview of a digital television system 1000 is shown in Figure 1. The preferred embodiment of the invention includes a mostly conventional digital television system 2000 which uses the known MPEG-2 compression system to transmit compressed digital signals. In more detail, MPEG-2 compressor 2002 in a broadcast centre receives a digital signal stream (typically a stream of video signals). The compressor 2002 is connected to a multiplexer and scrambler 2004 by linkage 2006. The multiplexer 2004 receives a plurality of further input signals, assembles one or more transport streams and transmits compressed digital signals to a transmitter 2008 of the broadcast centre via linkage 2010, which can of course take a wide variety of forms including telecom links.

The transmitter 2008 transmits electromagnetic signals via uplink 2012 towards a satellite transponder 2014, where they are electronically processed and broadcast via notional downlink 2016 to earth receiver 2018, conventionally in the form of a disk owned or rented by the end user. The signals received by receiver 2018 are transmitted to an integrated receiver/decoder 2020 owned or rented by the end user and connected to the end user's television set 2022. The receiver/decoder 2020 decodes the compressed r I MPEG-2 signal into a television signal for the television set 2022.

[R:\LIBOO]05156.doc:iad A conditional access system 3000 is connected to the multiplexer 2004 and the receiver/decoder 2020, and is located partly in the broadcast centre and partly in the decoder. It enables the end user to access digital television broadcasts from one or more broadcast suppliers. A smartcard, capable of deciphering messages relating to commercial offers (that is, one or several television programmes sold by the broadcast supplier), can be inserted into the receiver/decoder 2020. Using the decoder 2020 and smartcard, the end user may purchase commercial offers in either a subscription mode or a pay-per-view mode.

C

C

C

CC C

CC

C

The next page is page 7 [R:\LIBOO]05156.doc:iad WO 98/43172 PCT/EP97/02115 -7- An interactive system 4000, also connected to the multiplexer 2004 and the receiver/decoder 2020 and again located partly in the broadcast centre and partly in the decoder, enables the end user to interact with various applications via a modemmed back channel 4002.

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

For example, the interactive system 4000 allows an end user to buy items from onscreen catalogues, consult local news and weather.maps on demand and play games through his television set.

The interactive system 4000 comprises in overview four main elements: an authoring tool 4004 at the broadcast centre (or elsewhere) for enabling a broadcast supplier to create, develop, debug and test applications; an application and data server 4006 the broadcast centre, connected to the authoring tool 4004 for enabling a broadcast supplier to prepare, authenticate and format applications and data for delivery to the multiplexer and scrambler 2004 for insertion into the MPEG-2 transport stream (typically the private section thereof) to be broadcast to the end user; a virtual machine including a run time engine (RTE) 4008, which is an executable code installed in the receiver/decoder 2020 owned or rented by the end user for enabling an end user to receive, authenticate, decompress, and load applications into the working memory 2024 of the receiver/decoder 2020 for execution. The engine 4008 also runs resident, general-purpose applications. The engine 4008 is independent of the hardware and operating system; and a modemmed back channel 4002 between the receiver/decoder 2020 and the application and data server 4006 to enable signals instructing the server 4006 to insert data and applications into the MPEG-2 transport stream at the request of the end user.

The interactive television system operates using "applications" which control the functions of the receiver/decoder and various devices contained therein. Applications WO 98/43172 PCT/EP97/02115 -8are represented in the engine 4008 as "resource files". A "module" is a set of resource files and data. Several modules may be required to make up an application. A "memory volume" of the receiver/decoder is a storage space for modules. An "interface" is used to download modules.' Modules may be downloaded into the receiver/decode 2020 from the MPEG-2 transport stream.

The elements mentioned in the previous paragraph are now described in more detail.

For the purposes of this specification, an application is a piece of computer code for controlling high level functions of preferably the receiver/decoder 2020. For example, when the end user positions the focus of a remote controller on a button object seen on the screen of the television set 2022 and presses a validation key, the instruction sequence associated with the button is run.

An interactive application proposes menus and executes commands at the request of the end user and provides data related to the purpose of the application. Applications may be either resident applications, that is, stored in the ROM (or FLASH or other non-volatile memory) of the receiver/decoder 2020, or broadcast and downloaded into the RAM or FLASH memory of the receiver/decoder 2020.

Examples of applications are:- S An Initiating Application. The receiver/decoder 2020 is equipped with a resident initiating application which is an adaptable collection of modules (this term being defined in more detail hereunder) enabling the receiver/decoder 2020 to be immediately operative in the MPEG-2 environment. The application provides core features which can be modified by the broadcast supplier if required. It also provides an interface between the resident application and downloaded applications.

A Startup Application. The startup application allows any application, either downloaded or resident, to run on the receiver/decoder 2020. This application acts as a bootstrap executed on arrival of a service in order to start the application. Startup is downloaded into RAM and therefore can be updated WO 98/43172 PCT/EP97/02115 -9easily. It can be configured so that the interactive applications available on each channel can be selected and run, either immediately after downloading or after preloading. In the case of preloading, the application is loaded into the memory 2024 and is activated by the startup when required.

A Program Guide. The Program Guide is an' interactive application which gives full information about programming. For example, it may give information about, say, one week's television programmes provided on each channel of a digital television bouquet. By depressing a key on the remote controller 2026, the end user accesses an add-on screen, overlaid on the event shown on the screen of the television set 2022. This add-on screen is a browser giving information on the current and next events of each channel of the digital TV bouquet. By depressing another key on the remote controller 2026, the end user accesses an application which displays a list of information on events over one week. The end user can also search and sort events with simple and customised criteria. The end user can also access directly a selected channel.

0 A Pay Per View application. The Pay Per View Application is an interactive service available on each PPV channel of the digital TV bouquet in conjunction with the conditional access system 3000. The end user can access the application using a TV guide or channel browser. Additionally, the application starts automatically as soon as a PPV event is detected on the PPV channel. The end user is then able to buy the current event either through his daughter smartcard 3020 or via the communication server 3022 (using a modem, a telephone and DTMF codes, MINITEL or the like). The application may be either resident in the ROM of the receiver/decoder 2020 or downloadable into the RAM of the decoder 2020.

0 A PC Download application. On request, an end user can download computer software using the PC download application.

0 A Magazine Browser application. The magazine browser application comprises a cyclic video broadcast of images with end user navigation via on-screen buttons.

S A Quiz application. The quiz application is preferably synchronised with a WO 98/43172 PCT/EP97/02115 broadcast quiz programme. As an example, multiple choice questions are displayed on the screen of the television 2022, and the user can select an answer using the remote controller 2026. The quiz application can inform the user whether the answer is correct or not, and can keep count of the user's score.

0 A Teleshopping application. In one example of the teleshopping application, offers of goods for sale are transmitted to the receiver/decoder 2020 and displayed on the television 2022. Using the remote controller, the user can select a particular item to buy. The order for the item is sent via the modemmed back channel 4002 to the application and data server 4006 or to a separate sales system the telephone number of which has been downloaded to the receiver/decoder, possibly with an order to debit the account for a credit card which has been inserted into one of the card readers 4036 of the receiver/decoder 2020.

S A Telebanking application. In one example of the telebanking application, the user inserts a bank card into one of the card readers 4036 of the receiver/decoder 2020. The receiver/decoder 2020 dials up the user's bank, using a telephone number stored in the bank card or stored in the receiver/decoder, and then the application provides a number of facilities which can be selected using the remote controller 2026, for example for downloading via the telephone line a statement of account, transferring funds between accounts, requesting a cheque book, etc.

0 An Internet Browser application. In one example of the Internet browser application, instructions from the user, such as a request to view a web page having a particular URL, are entered using the remote controller 2026, and these are sent by the modemmed back channel 4002 to the application and data server 4006. The appropriate web page is then included in the transmissions from the broadcast centre, received by the receiver/decoder 2020 via the uplink 2012, transponder 2014 and downlink 2016, and displayed on the television 2022.

Applications are stored in memory locations in the receiver/decoder 2020 and WO 98/43172 PCT/EP97/02115 11 represented as resource files. The resource files comprise graphic object description unit files, variables block unit files, instruction sequence files, application files and data files.

The graphic object description unit files describe tfie screens, the man-machine interface of the application. The variables block unit files describe the data structures handled by the application. The instruction sequence files describe the processing operations of the applications. The application files provide the entry points for the applications.

The applications constituted in this way can use data files, such as icon library files, image files, character font files, colour table files and ASCII text files. An interactive application can also obtain on-line data by effecting inputs and/or outputs.

The engine 4008 only loads into its memory those resource files it needs at a given time. These resource files are read from the graphic object description unit files, instruction sequence files and application files; variables block unit files are stored in memory following a call to procedure for loading modules and remain locked there until a specific call to an procedure for unloading modules is made.

With reference to Figure 3, a module 4010, such as a tele-shopping module, is a set of resource files and data comprising the following: a single application file 4012; an undetermined number of graphic object description unit files 4014; an undetermined number of variables block unit files 4016; an undetermined number of instruction sequence files 4018; and where appropriate, data files 4020 such as icon library files, image files, character font files, colour table files and ASCII text files.

In the MPEG data stream, each module comprises a group of MPEG tables. Each MPEG table may be formatted as a number of sections. In the MPEG data stream, each section has a "size" of up to 4 kbytes. For data transfer via the serial and WO 98/43172 PCT/EP97/02115 12 parallel port, for example, modules similarly are split into tables and sections, the size of the section varying with the transport medium.

Modules are transported in the MPEG data stream in the form of data packets of typically 188 bytes within respective types of data stream, for example, video data streams, audio data streams and teletext data streams. Each packet is preceded by a Packet Identifier (PID) of 13 bits, one PID for every packet transported in the MPEG data stream. A programme map table (PMT table) contains a list of the different data streams and defines the contents of each data stream according to the respective PID.

A PID may alert a device to the presence of applications in the data stream, the PID being identified using the PMT table.

The concept of modules 4010 together with the concept of downloading small pieces of code allows the easy evolution of applications. They can be downloaded into permanent FLASH memory of the receiver/decoder 2020 as resident software or broadcast in order to be downloaded into the RAM of the decoder 2020 only when needed by the end user.

A memory volume is a storage space for modules 4010. Such storage spaces are located in the memory 2024 of the receiver/decoder 2020. With reference to Figure 4, the memory 2024 is divided into typically a RAM volume 4022, FLASH volume 4024, and ROM volume 4026. The memory may further be divided into memory volumes associated with the various interfaces through which modules are downloaded into the receiver/decoder 2020, for example an MPEG volume for storing modules downloaded from the MPEG bitstream and a serial volume for storing modules received via a serial interface.

The RAM volume 4022 in turn is divided into a zone dedicated to firmware, a working space for the engine 4008 and the buffers. The FLASH and other nonvolatile memory can be accessed either by an application or the engine itself through WO 98/43172 PCT/EP97/02115 13 a device manager.

Each volume contains a list of modules 4010, each module 4010 containing a list of files 4012, 4014, 4016, 4018, 4020. It is possible to have two files bearing the same name and which may be located in distinct modules. 'For example, a version of the application is typically stored in the ROM volume 4026, with later versions being downloadable into the FLASH volume 4024 to substitute the version stored in the ROM volume with that volume stored in the FLASH volume 4024. The contents of files may be compressed in LZW format, however as decompression of files takes a certain period of time they may be received in decompressed format.

Physical interfaces of the receiver/decoder 2020 are used for downloading data. With reference to Figure 5, the receiver/decoder 2020 contains, for example, six downloading media; MPEG flow tuner 4028, serial interface 4030, parallel interface 4032, modem 4034 and two card readers 4036.

With multiple sources of applications and multiple manufacturing sources of receiver/decoder 2020, it is important that one application behaves in the same way on every receiver/decoder, and each receiver/decoder should execute every application in the same, correct manner. With reference to Figure 6, the receiver/decoder 2020 comprises a run time engine 4008 running under the control of a microprocessor and a common application programming interface 4054. They are installed in every receiver/decoder 2020 so that all receiver/decoders 2020 are identical from the application point of view.

Figure 6 shows the architecture of the receiver/decoder 2020 for running applications 4056. The virtual machine 4007 executes applications 4056, which may comprise applications 4056' coupled directly to the virtual machine or applications 4056" downloaded to the receiver/decoder 2020 from, for example, the MPEG data stream.

The run time engine 4008 also displays graphics and text, calls devices for services, receives "events" and65'usdanctions of a library 4058 for specific computation.

WO 98/43172 PCT/EP97/02115 14 With reference to Figure 6, with respect to an application a function of the decoder 2020 is "seen" as a device 4060. There may, therefore, be functions of the receiver/decoder 2020 which may not be seen by any application.

A presentation function communicating with the virtual machine 4007 administers the presentation of text and graphics to the end user, and the presentation of end user actions to the virtual machine 4007. The text and graphics are overlaid on the display on the television set 2022, and the user may interact with the application 4056 by means of a keyboard. The term "keyboard" includes the remote controller 2026.

The run time engine 4008 is an executable code installed in the virtual machine 4007 of the receiver/decoder 2020 and includes a virtual machine for interpreting and running applications. The engine 4008 is adaptable to any operating system, including a single task operating system (such as MS-DOS).

The engine 4008 comprises a process sequencer unit (which take various events such as a key press, to perform various actions) and contains its own scheduler to manage event queues from the different hardware interfaces. It also handles the display of graphics and text.

The engine 4008 comprises a code loader to load and download applications 4056" into the decoder memory 2024. Only the necessary code is loaded into the RAM volume 4022 or FLASH memory volume 4024 in order to ensure optimal use. The downloaded data is verified by an authentication mechanism to prevent any modification of an application 4056 or the execution of any unknown application.

The engine 4008 further comprises a decompressor. As the application code (a form of intermediate code) is compressed for space saving and fast downloading from the MPEG-2 transport stream or via a built-in receiver/decoder mode, the code must be decompressed before loading it into the RAM.

The virtual machine 4007 also comprises an intermediate code interpreter to interpret WO 98/43172 PCT/EP97/02115 15 the application code and which uses a process sequencer unit to update various variable values and determine status changes, and an error checker.

With reference to Figure 6, with respect to' an application a function of the decoder 2020 is "seen" as a device 4060. There may, therefore, be functions of the receiver/decoder 2020 which may not be seen by any application.

A device 4060 comprises a logical device unit which may correspond to a component 4062 or physical interface 4064 of the hardware 4066. Such devices are referred to as "low level devices" 4068. The output of such a device 4068 may be connected to at least one device driver 4070 for converting the logical signals output by the device 4068 into signals required to drive, for example, a hardware interface 4064.

Alternatively, the device 4068 may itself drive a component or interface of the receiver/decoder 2020, that is, the output of the device may be connected directly to the hardware 4066.

Examples of low level devices 4068 are described below.

An LCARD device enables a program to communicate with the smartcard contained in one smartcard reader 4036, and an RCARD device enables a program to communicate with the smartcard contained in the other smartcard reader 4036. For example, these devices enable a program to read the state of the card, read the card history and send an input message to the card. The devices also inform a program of the insertion of a card in to the reader, removal of a card from a reader and card reset if not requested by the program. The LCARD and RCARD devices are specific to the protocol used for running the card. Typically an IS07816 protocol is used.

An SCTV device enables a program to verify and configure of a scart outlet to the television set 2022. For example, this device enables a program to request information about the sound characteristic of the scart outlet, perform a "MUTE" on the sound and dynamically program RGB levels.

WO 98/43172 PCT/EP97/02115 16 A TUNER device enables a program to use the tuner 4028. For example, the device enables a program to perform a scan from either a minimum frequency or a current frequency of the tuner, read the tuner parameters and program the tuner.

A SERIAL device enables a program to communicate with equipment via a serial link and a PARALLEL device enables a program to communicate with equipment via a parallel link. For example, these devices enable a program to send a message via the respective link and inform a program of the reception of a message via that link.

A MODEM device allows the receiver decoder t& communicate with a data service via an internal half-duplex modem supporting V23. The MODEM device requests the dialling of a number, the sending of a message to the data server and disconnection of the modem, and signals reception of a message, the detection of errors and the loss or detection of a carrier.

Remote devices, executed in a remote location, can be any of the local devices, except that a port and protocol must be defined.

In addition to "low level devices" the receiver/decoder 2020 may also include "high level devices" 4072 which control operation of the receiver/decoder 2020.

Examples of high level devices 4072 are described below.

An MLOAD device allows an application to load an MPEG section, a complete MPEG table or a group of MPEG sections from an MPEG bitstream corresponding to hardware and software filtering criteria. For example, the device enables a program to download only those sections of a group that are required at any one time by an application An FDLOAD device manages automatically file downloading via the serial and/or parallel ports. The device may signal both the start and the end of the downloading of files via the serial and/or parallel ports as requested by a program. The device may WO 98/43172 PCT/EP97/02115 17issue a request to the program for an index table which includes the PID of the file to be downloaded and the deciphering PID ECM of the file. The program loads the index table and sends it to the device, which subsequently requests the downloading of the file to the program. The program extracts the PID and PID ECM for the file from the index table and requests demultiplexing to enable the file to be downloaded in its entirety. At any time, a call "fdload_offline" may be issued by the program to instruct the FDLOAD device to stop managing the serial and/or parallel ports.

Devices 4060 are identified with a unique identifier "device_id", for example, "LCARD_DEVICE_ID" identifies the LCARD device and "RCARD_DEVICE ID" identifies the RCARD device.

When a new device 4060 is created, it can be installed in existing receiver/decoders 2020 by downloading the relevant application 4056" from the broadcast centre.

This downloading is performed in the receiver/decoder 2020 by an application 4056 which checks the hardware and software versions and, if correct, loads the software module representing the new device 4060 and asks a procedure of the library 4058 to install the new device code within the firmware (in FLASH memory). This can provide a flexible and secure installation of new functions within the receiver/decoder 2020 without affecting the rest of the software.

Device manager 4074 is a common interface between the application 4056 and the devices 4060 associated with specific functions of the receiver/decoder 2020. By adopting such a common interface, procedures, stored in a "library" of the run time engine 4008, permitting access to the devices 4060, and "events" associated with the devices may be standardised using a limited number of procedures. The device manager 4074 controls access to devices 4060, declares receipt of an unexpected event, and manages shared memory.

There are 18 procedures that give access to the device manager 4074, to a device 4060 itself or to memory management.

WO 98/43172 PCT/EP97/02115 18 Device_Open_Channel 0 Device_Close_Channel 0 Device_Open_Device 0 Device_Close_Device 0 Device_Event 0 Device_Call 0 Device_Io 0 Device_Info 0 Set_Buffer_outline 0 Get_Buffer_outline 0 Pool_Info 0 Device_Alloc_Buffer 0 Device_Free_Buffer 0 Device_Lock_Buffer 0 Device_Info_Free_Buffer 0 Device_Info_Alloc_Buffer 0 Get_BufferSize 0 Opens a channel to the manager Closes a channel to the manager Opens a channel to the device Closes a channel to the device Unexpected event management Synchronous access to a device Asynchronous access to a device Information about a device Defines a memory partitioning for buffers Reads the present buffer partitioning area Provides information about the present buffer partitioning area Allocates memory Frees memory Locks memory Gives the number of free buffers Lists the allocated buffers Gives the size of the allocated buffer With reference to Figure 7, before using the services of any device 4060, a program (such as an application script) has to be declared as a "client" 4076, that is, a logical access-way to the device 4060 or the device manager 4074. The manager gives the client 4076 a client number which is referred to in all accesses to a device.

A device 4060 can have several clients 4076, the number of clients 4076 for each device 4060 being specified depending on the type of device 4060.

A client 4076 is introduced to the device manager 4068 with the procedure Device_Open_Channel 0 4078. With this procedure the device manager gives the client 4076 the client number. The device manager 4074 outputs a "client_id", comprising the address of the variable containing the allocated client number (there should never be two clients with the same number), and an "error_code", comprising WO 98/43172 PCT/EP97/02115 19 either error_code indicating that the procedure has been completed successfully, or errorcode "e_clientmax" indicating that the maximum number of clients that can be handled by the device manager, typically 256, has been reached.

The first client number allocated is 0, increasing by 1 for each call using the procedure "Device_Open_Channel" up to the value of 255. This occurs independently from the removal of any client from the list of clients. When the client number 255 has been allocated and a subsequent "Device_Open_Channel" call occurs, either the error code "e_client_max" is output to indicate that the list of clients is "full" or the client is allocated the smallest client number available, that is, a client number of a client that previously had been removed from the list of clients.

To declare a client 4076 to a device 4060, a client uses the procedure Device_OpenDevice 4080, transmitting therewith its client_id and the device_id.

The device manager outputs an error message if the procedure has been successfully completed, "e_client_inconnu" if the client does not exist, "e_periph_inconnu" if the device does not exist, e_client_max, or "w_deja_vu" if the device has already been declared to the device.

A client 4076 can be removed from a list for a device 4060 with the procedure Device_Close_DeviceO. The client_id and device_id are input to the device manager, which in turn outputs either error_code if the procedure has been completed successfully, error_code "w_client_inconnu" if the client is unknown to the device manager or error code "w_periph_inconnu" if the device is unknown to the device manager.

A client 4076 can be removed from the client list of the device manager 4074 with the procedure Device_Close_Channel 0. The "client_id" is input to the device manager, which in turn outputs either error_code if the procedure has been completed successfully or error_code "w_client_inconnu" if the client is unknown to the device manager. This procedure deletes the client from the list of the device manager 4074 and from the list of each device 4060 for which he is a client, ie. if not WO 98/43172 PCT/EP97/02115 20 already done so by the application, the DeviceClose_Channel 0 procedure calls the Device_Call_Device 0 procedure for each device for which that client is a client. The client number thus freed using this procedure may then be allocated, using the Device_Open Channel 0 procedure, to a new client.

Procedure "DeviceInfo 0" provides information concerning a device 4060 to a client 4076. The clientid and deviceid are input to the device manager 4074, which returns information concerning the device, typically the version of the device, the maximum number of clients for the device and the actual number of clients using the device, to the client, together with error_codes indicating that the procedure has been completed or that either the client or the device is unknown to the device manager 4074.

Procedure "Device_Event" is a means of managing "unexpected events", that is, that a specific circumstance, or something unexpected, has occurred. The "Device-Event" procedure enables a client to declare itself the receiver of an unexpected event from a device.

Messages for applications, called "events", are put into one of, say, five queues of the engine 4008. Each of these queues corresponds to a priority level 0 to 4 (4 maximum priority, 0 minimum priority).

When extracting messages from the queue for transfer to an application, the engine 4008 searches for the queue having the highest priority containing an event. The event is removed from the queue and used to activate the process sequencer unit for which it is intended.

All "external" events, whether input to the presentation function by the keyboard or received through an interface pass through an event interface before being processed by the engine 4008. However, any internal events, typically generated by internal devices, do not pass through the event interface but pass directly to the engine 4008.

WO 98/43172 PCT/EP97/02115 21 For each procedure, the last calling parameter is the address of a variable to be set by the device manager indicating how the command was handled by the device manager.

The reason for the issue of an unexpected- event to a client depends on the device 4060. For example, with respect to the device LCARD DEVICE, unexpected events include: removal of a card from the card reader; insertion of a card in the card reader; or reset of the card by a client.

Each of the above is identified by a respective unique event code ("ev_lcard_extract", "ev_lcard_insert" and "ev_card_reset" respectively).

To receive unexpected events, the client must declare itself as a receiver of each event that it may wish to receive using the procedure "device_event". The following parameters are input to the device manager: client_id; device_id; a command called "getevent" which enables the sending on an unexpected event; the event code; and the event priority, between 0 and 4.

Several devices may declare reception of the same unexpected event, with the same or a different priority. In this case, the event is sent to each client in a specific order (by priority and client number).

For example, client 2 declares himself the receiver of the event ev_card_extract from the LCARD device with priority 2. Client 3 declares himself the receiver of the same event with priority 2, client 1 with priority 4 and finally client 4 with priority 3. If the card is removed from the reader, the following sequences of events occurs; the event ev_card_extract addressed to client 1 is placed in the queue of the run time engine 4008 corresponding to priority 4; WO 98/43172 PCT/EP97/02115 22 the same event addressed to client 4 is placed in the queue of the run time engine 4008 corresponding to priority 3; the same event addressed to client 2 is placed in the queue of the run time engine 4008 corresponding to priority 2; and the same event addressed to client 3 is placed in the queue of the run time engine 4008 corresponding to priority 2.

For some devices a buffer may be involved in an unexpected event. In such a case, the device allocates this buffer via the device manager 4068. In the application programming language, a procedure enables access to parameters that may be associated with events; event_code; clientid: evt_paraml (typically having a size of 4 bytes); and evt_param2 (typically having a length of 2 bytes).

The exact meaning of the evt_param parameters depend on the device and the reason for the posting of the event. The association of a buffer with an unexpected event depends on the device. If the association exist, evt_paraml corresponds to the data zone address of the associated buffer. If there is no buffer, the event will still be issued but with the parameter evt_paraml set at If the device has a buffer for association with an unexpected event, the removal of a client from a list of a device or a list of the device manager results in deallocation of the buffer, except where the buffer has been "locked" by the application using the procedure "device_lock_buffer".

Evtparam2 indicates that the procedure has been successfully completed and that a result has been obtained by the device.

A client may stop the reception of any unexpected event using the command WO 98/43172 PCT/EP97/02115 23 "ret_event" instead of the command "getevent".

The device manager 4074 provides access by clients 4076 to devices 4060 in two different modes: "synchronous access" or "asynchronous access".

Synchronous access, using procedure "Device_Call", is a means of accessing a function specific to a device and which does not involve the placing of the response from the device in a queue of the run time engine 4008; the response is available immediately. Typically, this procedure is used in configuration of the hardware interfaces of the receiver/decoder 2020.

Using this procedure, the client inputs the following parameters to the device via the device manager: clientid; device_id; "call_cmde", which comprises the type of operation to be performed by the device. For example, with respect to the SERIAL device allowing a program to communicate with equipment via the serial link, the command "serial_setup" sets up the serial link configuration; "emadr", which comprises the address of the memory location of the input data; and "rec_adr", which comprises the address of the memory location to which the device must write the output data.

Upon completion of the operation requested by the client, the device outputs a "callreport", which comprises a report of the run. The call_report typically comprises one of a predetermined number of reports that may be issued to the client. In turn, the device manager 4074 issues an errorcode to the client 4076, the errorcode typically comprising one of: e_client_inconnu; e_periph_inconnu; "ecmdeinconnu", which notifies the client that the command was unknown; WO 98/43172 PCT/EP97/02115 24 "e_report_periph", which is an error specific to the device; and which indicates that the procedure was completed successfully.

The device only writes the output data to the address of the memory location identified by the parameter "rec_adr" when the error_code is received.

Device_call blocks all other applications until the run has been completed by the device.

Asynchronous access, using procedure "Device_Io', is a means of accessing a function specific to a device and which involves waiting for a response. For example, with respect to the SERIAL device, the command "serial_send" sends a message via the serial link. Following successful transmission of all of the data (before any pre-set "time-out" parameter is reached) the device sends a report to the program. When this report is available an event is put into a queue of the engine 4008 to signal its arrival.

Using this procedure, the client inputs the following parameters to the device via the device manager: client_id; device_id; "io_cmde", which comprises the type of operation to be performed by the device; the event code associated with the end of the operation; the event priority associated with the event; em_adr; and recadr.

Upon completion of the operation requested by the client, the device outputs an "ioreport", which comprises a report of the run.

The io_report typically comprises one of a predetermined number of reports that may be issued to the client and one of two reports ("enot_done", indicating that the 25 requested information is not yet available to the client, and indicating that the requested information is available) associated with the event.

Upon receipt of the report the device manager issues an error_code to the client 4076, the error_code comprising one of: e_client_inconnu; e_periph_inconnu; e_cmdeinconnu; "e_cmdeinconnue" which indicates that the event code is unknown; "e_prioriteinconnue" which indicates that the priority is unknown; go* 10 e_report_periph; go 0.

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

15 Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

In the aforementioned preferred embodiments, certain features of the present invention have been implemented using computer software. However, it will of course be clear to the skilled man that any of these features may be implemented using hardware.

Furthermore, it will be readily understood that the functions performed by the hardware, the computer software, and such like are performed on or using electrical and like signals.

This page is intentionally blank

C

C

C

C.

0

C

C

C

CC..

C

C C *0 0*C*

C

C

C 0 0 C C. C

C

C C* [R:\LIBOO]051I56.doc:iad

Claims (18)

1. A method of enabling an application stored in and executable on a receiver/decoder to receive a message concerning a function performed by a component of said receiver/decoder, said method comprising the steps of: storing in said receiver/decoder logical devices, each logical device representing a respective function of the receiver/decoder and being separate from the component of said receiver/decoder for performing that function, each logical device having a respective device identifier; assigning an application identifier to the application; and outputting from the application a signal comprising the application identifier and 9 .i the device identifier of a logical device from which the application wishes to receive messages concerning the function of the receiver/decoder which that logical device ,represents; is receiving said signal at a device manager provided between the application and o° o* each logical device, said device manager storing for the logical device identified by said identifier said application identifier to enable said application to receive a message output 9 :from that logical device concerning the function of the receiver/decoder which that logical device represents.
2. A method according to claim 1, wherein the application identifier is assigned to S: the application by the device manager.
3. A method according to claim 1 or 2, wherein said signal further comprises a command enabling receipt by the application of a message output from the logical device indicating a change of state of the component performing the function represented by the logical device.
4. A method according to claim 3, wherein said message is stored temporarily in a queue for subsequent transfer to said application. A method according to claim 4, wherein the receiver/decoder includes a plurality of such queues, each queue having a respective priority level indicative of the order in x which messages are to be transferred from the queues to the application. [R:\LIBOO]05156.doc:iad -28-
6. A method according to claim 5, wherein the signal further comprises the priority level of the queue in which said message is to be stored temporarily.
7. A method according to any one of the preceding claims, said method comprising the further step of: subsequently outputting from the application a signal to the device manager comprising the application identifier and the device identifier of the logical device together with a command instructing operation of the component for performing the function which is represented by that logical device.
8. A method according to claim 7, wherein the signal includes an address for data ego ft to be input to the component by said logical device and an address for data output from said logical device. lgc i i 9. A method according to claim 8, wherein the signal includes the priority level of a queue into which a message output from the logical device is to be stored temporarily prior to transfer to the application.
10. A method according to any one of the preceding claims, wherein at least one of .9 the application and the logical device is input to said receiver/decoder via component of the receiver/decoder. o° °o ft
11. A method according to any one of the preceding claims, wherein said component comprises one of an MPEG flow tuner, a serial interface, a parallel interface, a modem and a smartcard reader.
12. Apparatus for enabling an application stored in and executable on a receiver/decoder to receive a message concerning a function performed by a component of said receiver/decoder, said apparatus comprising: means for storing in said receiver/decoder logical devices, each logical device representing a respective function of the receiver/decoder and being separate from the component of said receiver/decoder for performing that function, each logical device having a respective device identifier; f11means for assigning an application identifier to the application; and [R:\LIBOO]05156.doc:iad -29- a device manager provided between the application and each logical device for receiving from the application a signal comprising the application identifier and the device identifier of a logical device from which the application wishes to receive messages concerning the function of the receiver/decoder which that logical device represents, and for storing for the logical device identified by said identifier said application identifier to enable said application to receive a message output from that logical device concerning the function of the receiver/decoder which that logical device represents.
13. Apparatus according to claim 12, wherein the device manager is arranged to assign the application identifier to the application. .o
14. Apparatus according to claim 12 or 13, comprising a queue for storing temporarily a message output by the logical device for subsequent transfer to said 15 application.
15. Apparatus according to claim 14, comprising a plurality of such queues, each queue having a respective priority level indicative of the order in which messages are to be transferred from the queues to the application.
16. Apparatus according to any one of claims 12 to 15, further comprising means for storing data to be input to the component by said logical device and means for storing data output from said logical device.
17. A receiver/decoder comprising of said apparatus according to any one of claims 12 to 16.
18. A receiver/decoder according to claim 17, further comprising means for receiving a compressed MPEG-type signal, means for decoding the received signal to provide a television signal and means for supplying the television signal to a television.
19. Apparatus for enabling an application stored in and executable on a receiver/decoder to receive a message concerning a function performed by a component ,cRA, of said receiver/decoder, said apparatus substantially as described herein with reference to Figs. 1 to 7 of the accompanying drawings. [R:\LIBOO]051 56.doc:iad A receiver/decoder substantially as described herein with reference to Figs. 1 to 7 of the accompanying drawings.
21. A method of enabling an application stored in and executable on a receiver/decoder to receive a message concerning a function performed by a component of said receiver/decoder, said method substantially as described herein with reference to Figs. 1 to 7 of the accompanying drawings. DATED this Twenty-fifth Day of September, 2001 Canal+ Societe Anonyme Patent Attorneys for the Applicant g. SPRUSON FERGUSON S** o [R:\LBOO]05156.doc:iad
AU26385/97A 1997-03-21 1997-04-25 Access control system Ceased AU742213B2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP97400650 1997-03-21
EP97400650 1997-03-21
PCT/EP1997/002115 WO1998043172A2 (en) 1997-03-21 1997-04-25 Access control system

Publications (2)

Publication Number Publication Date
AU2638597A AU2638597A (en) 1998-10-20
AU742213B2 true AU742213B2 (en) 2001-12-20

Family

ID=26070210

Family Applications (1)

Application Number Title Priority Date Filing Date
AU26385/97A Ceased AU742213B2 (en) 1997-03-21 1997-04-25 Access control system

Country Status (14)

Country Link
EP (1) EP1055176A2 (en)
JP (1) JP2002512713A (en)
CN (1) CN1260056A (en)
AU (1) AU742213B2 (en)
BR (1) BR9714603A (en)
CA (1) CA2284867A1 (en)
HU (1) HU0004141A2 (en)
IL (1) IL131936D0 (en)
NO (1) NO994539L (en)
NZ (1) NZ500205A (en)
PL (1) PL336907A1 (en)
TR (1) TR199902263T2 (en)
WO (1) WO1998043172A2 (en)
ZA (1) ZA9703612B (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0893765A1 (en) 1997-07-24 1999-01-27 CANAL+ Société Anonyme IEEE 1394 Set Top Box device driver
US20020073218A1 (en) * 1998-12-23 2002-06-13 Bill J. Aspromonte Stream device management system for multimedia clients in a broadcast network architecture
EP1304871A3 (en) * 2001-08-21 2003-06-18 Canal+ Technologies Société Anonyme Method and apparatus for a receiver/decoder
CN102768843A (en) * 2012-03-28 2012-11-07 新奥特(北京)视频技术有限公司 User-configurable cataloguing method and system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5448568A (en) * 1994-04-28 1995-09-05 Thomson Consumer Electronics, Inc. System of transmitting an interactive TV signal
US5511169A (en) * 1992-03-02 1996-04-23 Mitsubishi Denki Kabushiki Kaisha Data transmission apparatus and a communication path management method therefor

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63163944A (en) * 1986-09-17 1988-07-07 Ibm Application communication system
US4855905A (en) * 1987-04-29 1989-08-08 International Business Machines Corporation Multiprotocol I/O communications controller unit including emulated I/O controllers and tables translation of common commands and device addresses
US5179708A (en) * 1989-04-07 1993-01-12 At&T Bell Laboratories System inhibiting message delivery to destination process until priority of process excuting on distination processor is no higher than priority of sending process
CA2044022A1 (en) * 1990-06-28 1991-12-29 Miriam A. Nihart Common agent computer management system and method
US5206936A (en) * 1990-08-31 1993-04-27 International Business Machines Corporation Apparatus for exchanging channel adapter status among multiple channel adapters

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5511169A (en) * 1992-03-02 1996-04-23 Mitsubishi Denki Kabushiki Kaisha Data transmission apparatus and a communication path management method therefor
US5448568A (en) * 1994-04-28 1995-09-05 Thomson Consumer Electronics, Inc. System of transmitting an interactive TV signal

Also Published As

Publication number Publication date
JP2002512713A (en) 2002-04-23
NZ500205A (en) 2001-11-30
IL131936D0 (en) 2001-03-19
CN1260056A (en) 2000-07-12
WO1998043172A2 (en) 1998-10-01
CA2284867A1 (en) 1998-10-01
TR199902263T2 (en) 2000-03-21
PL336907A1 (en) 2000-07-17
NO994539L (en) 1999-11-22
AU2638597A (en) 1998-10-20
NO994539D0 (en) 1999-09-17
EP1055176A2 (en) 2000-11-29
WO1998043172A3 (en) 2000-09-21
ZA9703612B (en) 1998-02-23
HU0004141A2 (en) 2001-05-28
BR9714603A (en) 2000-05-16

Similar Documents

Publication Publication Date Title
US5960445A (en) Information processor, method of updating a program and information processing system
AU2003234144B2 (en) Supporting common interactive television functionality through presentation engine syntax
KR100488396B1 (en) System for forming and processing an mpeg compatible datastream incorporating internet information
KR100422103B1 (en) Apparatus and method for preprocessing computer programs prior to transmission across a network
US7133903B2 (en) Event control device and digital broadcasting system
CN1145364C (en) System of downloading computer software with broadcasting program
USRE41257E1 (en) Program information broadcasting system, broadcasting device, and receiving terminal unit
US5530754A (en) Video on demand
EP1402361B1 (en) System and method for a communication terminal to manage memory and maintain a current application version for multiple applications
US6874145B1 (en) Methods and apparatus for implementing an application lifecycle design for applications
CA2441574C (en) Data referencing system
CN1178504C (en) Method of downloading of data to MPEG receiver/decoder and MPEG transmission system for implementing the same
US7032176B2 (en) Method and apparatus for providing a menu structure for an interactive information distribution system
EP1063597A2 (en) Methods and apparatus for data distribution and reception
US20080263611A1 (en) Video interfacing and distribution system and method for delivering video programs
KR100680663B1 (en) Broadcast and reception system, and receiver/decoder and remote controller therefor
US7068266B1 (en) Windowing systems
EP1252758B1 (en) Settop cable television control device and method including bootloader software and code version table for maintaining and updating settop receiver operating system software
RU2321965C2 (en) Mpeg-table structure
US7360233B2 (en) Broadcast carousel system access for remote home communication terminal
US7302693B2 (en) Remote control inputs to Java applications
ES2203070T3 (en) multimedia terminal intended for multiple users.
JP4845263B2 (en) Download the data
JP4162722B2 (en) Transmission and reception of TV programs and other data
JP2009219143A (en) Multimedia terminal and method for realizing multimedia reception

Legal Events

Date Code Title Description
FGA Letters patent sealed or granted (standard patent)
MK14 Patent ceased section 143(a) (annual fees not paid) or expired