FR2809510A1 - METHOD FOR FORMING AND USING AN EVENT DATA BASE - Google Patents

Abstract

The invention concerns a device for constituting a database including data concerning services and events transmitted on a dataflow, for example MPEG, characterised in that it consists in calculating exactly the memory workspace required for storing said data and in carrying out an exact allocation of memory workspace, thereby gaining memory workspace and facilitating consultation of the database.

Description

 METHOD FOR FORMING AND USING AN EVENT DATA BASE.

TECHNICAL FIELD The invention relates to the collection and exploitation of digital data relating to events of television channels or services. It more particularly relates to a method used to consume urië - database on ..., `` c1é `: .tels such events # and the use of the base of <J, - @ dônnés thus'cc ' nstruite.

Description of the technological background Television or radio service providers (or broadcasters) broadcast data tables of events that can be picked up by a user of a receiving apparatus these events, for example a television receiver equipped with a digital decoder or a digital decoder supplying a television receiver. Before describing further the prior art it is appropriate to make a few reminders about the vocabulary and the kind of norms that it is better to know to understand what will be explained next.

Service broadcasters, for example broadcasters, broadcast not only events, but also television programs, such as films, games, variety shows, and other information, including on the planned programs of television programs. emissions, in principle according to a pre-established standard. For example, in Europe the DVB-SI standard ETS 300 468 and the technical report ETR 211, provide a format for event information tables, (possible information tables, EITs). In the explanations which follow, the examples will be drawn from this standard. Similarly, the vocabulary used will have the definition provided by this standard and this report. It is however obvious that the invention is not dedicated solely to an application using this method.

In the rest of the description, your idea will be to use the so-called "schedule" ie program-related EITs. These EIT tables programs can describe up to 31 days of program for a service. The information specific to a program is for example its title, the duration of it, its genre etc.

The SI data makes it possible to implement Electronic Program Guide type applications. The DVB-SI ETS 300 468 standard defines out-of-print information, optional information associated with descriptors, and private information contained in private descriptors. The descriptors are variable length information such as, for example, a film or program title or a summary describing the program. Out of descriptor information is present for each event. Some examples are given below. Event Id: The unique identifier of an event for a service with a given "service Id" (a string).

 StartTime: Start of broadcast instant of the event (UTC GMT format).

Duration: Duration of the event.

 FreeCaMode: Criterion for access to the event.

Examples of optional information associated with DVB-SI descriptors are given below short_eventdéscr-iptor: Title and summary of 1 `-event. @ .` .. _ '-content descriptor: this descriptor corresponds to a classification of the event.

Finally, information associated with the descriptors is private, ie specific to a broadcaster.

For example, an access control specific descriptor can be used to describe events commonly known as pay-per-view (PPV), requiring, in order to be seen, a payment from the user. More complete information about the descriptors of EIT tables are provided in section 4.2.4 of ETSI ETR 211.

The EIT "schedule" information relating to the programs of the same broadcaster can be sent for example on the MPEG-2 stream on one or more tables or sub-tables each of these tables or sub tables having a table identifier "table id" (Tid) in fixed or sliding windows. In a sliding window, the data transmitted on the first of the tables identified by its Tid correspond to the current day.

In fixed window the data transmitted on the first of the tables identified by its Tid correspond to the first day of the month.

The DVB-SI standard recommends that events be transmitted in chronological order. The tables of the different broadcasters are broadcast periodically, with repetition frequencies, the minimums of which are set in paragraph 4.4 of the ETR 211 schedule. It also recommends that the descriptions of the events should be organized into sections each containing one maximum of 4096 bytes with at least one section per three hour program period. Eight sections form a segment. A sub-table has no more than 32 segments, or 256 sections in total.

By application is meant software for performing functions, for example search and presentation of information. Program Guide Applications (also known as EPG for Electronic Program Guide) are installed on decoders that have little memory. Also it is not possible to recover all information at once and memorize them before browsing. The catch-on-fly solution is then retained. This solution consists of recovering only the information necessary for a given application on the stream of data broadcast, depending on the application and the parameters of this application. For example if a viewer wants to know what will be broadcast on the day on a channel, from 20 hours, only this information will be searched on the stream, stored and exploited to be presented in an orderly and understandable for the viewer. As a result, the amount of memory used is reduced. On the other hand, it takes a long time to access new information since it is necessary to wait for the information sought to be disseminated, collected and processed. The exploitation of the requests of the spectator is then very slowed down. This choice also led to not using the tables defined by the DV1 = 1SI standards, but private tables lighter than the "EITs s.ched #".

_: We now see decoders also called "set top box, STB)" with a limited memory, for example 8 megabytes and it becomes possible to store program data and use them to deliver quickly the desired information, for example by a viewer.

<B> Brief description of the invention. </ B>

We note that despite the presence of a significant memory capacity, this capacity is still largely insufficient to store all information tables on events and therefore it is important to select the information that we will memorize, and organize them to better occupy the available memory space. The invention therefore relates to a method of collecting, in a memory, information relating to the programs which allows an optimal use of a capacity of this collection memory. It aims to allow the collection of these data in parallel. It also aims to organize this memory into a database that is quick and easy to access. This means that the presentation of the most commonly searched data to the viewer requires little instruction, because of the way the database is organized. In a preferred embodiment, the method according to the invention makes it possible, on the one hand, to detect very quickly that information stored in memory is not up to date and, on the other hand, to correct it.

For all these purposes, the invention is directed to a method of constructing a database of events relating to periodic event information. form of a data stream by one or more service providers in which a) a file of different identified services is generated capable of broadcasting event information; b) extracting and temporarily storing at least a portion of a series of information on the events broadcast by each service, c) for each event, the information that is to be stored for a long duration is selected, d) the number of octets contained in the information selected for each event, and that the sum of these quantities of information for the set of the events of each service, e) one looks for a zone of addresses memory of sufficient size to store there in an unfragmented way all the selected information relating to all the events of a first service one after the other, f) is copied in the non-fragmented address areas found in step e) each of the events of the first service one after the other others, g) complete the file services by the addition, in a file of this file corresponding to the first service of a pointer giving the address of the first event of this service, h) we repeat steps d) to g) for each of the services in the services file, i) delete the extracted information- <B> at </ B> step.b).

Preferably, step d) is completed by having a count of the number of events to clear the memory space necessary for the creation of a table of pointers, each giving the address of the beginning of an event. this service, we complete step e) by also looking for another group of memory addresses to house the array of pointers where each pointer gives the address of the beginning of an event, and finally in step f) in the table of pointers, for each event, the address of the beginning of the information relating to this event is entered.

When the operations a) to i) described above are completed, the information useful to a viewer is available in memory to know by service the events to which he can have access, and select those which interest him. It will be seen later that it is also possible to easily make a selection among events of several services, these events having a common quality identifiable by means of the information on the events, for example information by type of event, films , sports, varieties.

The place occupied by the selected information is minimal since information received has been removed from all information not directly useful to the viewer or to an application for searching or selecting among the events. In addition to the information specific to the events one uses for the exploitation of this information only the pointers with one pointer by event.

It will be noted, for example, that JAVA -.on, for example, has a pair of handles, one corresponding to a logical address and the other to the physical address. According to the invention there is only one address or pointer per service or in the case where one has created a table of pointers per event, a single address or pointer per event. The advantages of this table of pointers, consumer of a little memory will appear later, when describing a mode of use of the memory. So we also gain the corresponding memory space in the worst case to one address per event.

We also note that the operations a) to i) can be executed in a different way without the final result being changed. For example, only event information for a single service can be collected, process this information according to steps a) to i) with the exception of step h), and then repeat the same treatment for each of the others. services. The advantage of this latter solution is that the instantaneous volume of memory needed is less, which can be useful. The disadvantage of this last way of doing things is that we do not have information from the outset as to the total volume needed to store the information.

Preferably the individual records relating to each service are chained, this means that each record contains a pointer giving the address of a next service, a last record having a pointer giving the address of a first record. In the preferred embodiment the individual cards relating to each service are doubly linked. That is to say that each of the messages contains a pointer giving the address of a service preceding a first form having a pointer giving the address of a last form. In this way we can browse the list of services in an increasing or decreasing direction.

Thus in the preferred embodiment each server sheet contains three pointers, a pointer giving the address of the first event of the service, a pointer giving the address of the beginning of the record of the next service and a pointer giving the address of the beginning. the previous service record.

In an advantageous embodiment, the update of the data is simplified as follows. First of all, it is necessary for this embodiment that the service provider (s), or at least some of them, broadcast an update table. This table, in addition to identifying data, contains, essentially, indicators relating to version numbers of the service and of each event. To distinguish between these version numbers, the version numbers of the service are called the "service version counter" or "version counter" and the version number of the event is called the version number. Obviously, when the information about an event changes, the version number of the event changes and also the version counter of the service. The comparison of the service version counter currently broadcast with a previously stored service version counter allows to know whether it is necessary, -, * or not (make it a new data record of this service. If the event is known, or what event data has changed, it avoids repetition of all the data, and the private update table can also contain a general update flag indicating that a large amount of data has changed, which is followed by a re-registration of the data of this service.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will now be described with reference to the attached diagrams intended to illustrate and facilitate the understanding of the method according to the invention and variant embodiments. In these diagrams, FIG. 1 represents a part of a database constituted according to the invention, FIG. 2 represents the constitution of a compact area of events of a database constituted according to the invention, FIG. 3 represents another part of a database constituted according to the invention, FIG. 4 represents a compact zone and an associated table of a database constituted according to the invention, FIG. 5 illustrates the organization of a Service in a database constituted according to the invention, Figures 6 and 7 illustrate steps of the constitution of a services file Figures 8 and 9 illustrate steps of the constitution of a chain of events list the @ FIG. 10 illustrates steps in the constitution of a succession of lists of events. FIGS. 11 to 13 illustrate steps in the constitution of a compact event area and a table. associated pointers and the final appearance of this zone and the associated links, FIGS. 14 to 16 illustrate steps of the constitution of a succession of compact zones of events and associated pointer arrays and the final aspect of this succession of zones and associated links, figures 17 and 18 illustrate steps of the constitution of a table of pointers for a consultation on specific criteria and the final aspect of this table and its links with the selected events.

In the figures the same elements carry the same reference number possibly associated with a prime index or second index if it is the same element in a construction phase. Description of an embodiment of the invention

An example of a system for carrying out the method according to the invention will now be described. The system that will be described is composed of four separate modules An acquisition engine of information tables on events SI (EIT schedule) - a module analyzer tables (EIT) - a module memory manager - a consultation module The function of each of these modules in relation to the other modules will be described as described and then each of the modules will be described in more detail.

The SI table acquisition engine module (EIT schedule). Acquires the EITs from all services so that data is available to applications as quickly as possible. To do this parallel loading is preferred.

The table analyzer module is responsible for traversing the EIT tables and extracting relevant data that is formatted for storage in memory.

The memory management module is responsible for managing the storage of the elementary units representing a program as well as the organization of the memory.

The memory lookup module is responsible for providing applications with a library of functions for browsing the event database and establishing lists sorted according to certain criteria.

The implementation of these four elements within a decoder or "set top box" allows to have a complete tool ensuring access to all information SI of a bouquet while relying on the DVB standard -IF. Each of these four elements will be discussed in more detail below.

The acquisition engine module of the EIT tables manages the acquisition on the flow of the tables _EIT "Schedule" ,, # their anâ-lysë (via the analyzer) their storage .in memory via the memo @ irë manager: This engine .: also manages, according to an advantageous characteristic of the invention, the updating of the information contained in the memory when changes to this information or new events are transmitted on the stream.

EIT tables "Schedule" can represent a large data flow depending on the number of events and the number of services present. As a result, continuously monitoring all EIT tables to detect changes is a relatively long time.

To shorten the detection time advantageously, the data acquisition of the EIT Schedule tables is based on the use of a private table called Guide Update Table (GUT). This table is established primarily from service description tables (SDTs). These tables give for each service present on, a transport flow general information on the service, in particular a service identification and a version number (version number) on 5 bits which is increased by 1 each time there is a modification in a subtable representing a service. It is then completed by a service counter, which is modified whenever it is detected that the information relating to an event has been changed. This version counter is derived from an Event Information Table (EIT) that has a 5-bit version number, which is incremented by 1 when information about an event has been changed.

As a result, the GUT table contains the list of all services containing events on the transport streams. These services containing events are identified by their service identifications (service_id). This GUT table makes it possible to monitor the evolutions of all the events present on the transport stream by only monitoring this single table. Each service in the GUT table is associated, as indicated above, with a service counter, a version number, and a full update_counter flag. ).

When the events of a given service are modified on the stream, there is a change of the version counter (service çounter) of the corresponding service and the version number of the GUT table.

When services containing events are added to the stream, eyelashes are added to the GUT table and the version number of the GUT table is changed. Services removed from the transport stream do not disappear from the GUT table until a general update of this table. (change of the general update flag "full update_counter").

When the set (or a large part) of the services are modified, it is better to indicate this change by modifying the value of the "full update_counter" (although it is possible to modify only the version number of the table (version number), this for reasons-performances.

In order to optimize the data loading time of the Service Information Tables (EITs) present on the flow, several EIT table requests are managed in parallel.The number of requests used for an acquisition is distinguished. complete data present on the flow during a first load or after modification of the general update flag of the number of requests used for partial updates of the data of the memory The application will set these values to the data acquisition engine.

The state machine of the data acquisition engine module is sequenced by demultiplexer drivers.

The general operation is managed by two internal flags: a common flag on the type of acquisition, called "EngineMode" and a flag for each instance of filter, called EngineState.

The common flag <I> on </ I> the type of acquisition, entitled "EngineMode" has an initial state called "engineModeInit" "engineModeInit" is the first acquisition after initialization. Another "engineModeBuild" state corresponds to a complete memory load after a complete modification of the EITs broadcast, detected by a new value of the "full update" general update flag in the GUT private table on the flow by the service provider. Another state of this flag entitled "enginemodeUpdate" corresponds to an update of the memory following a modification of the data of certain services, this modification being detected @ 'by a new number of-.7' version (version number) of the GUT table while the "update update" * does not change value and new "service counter" service counter values at the service descriptor levels contained in the service descriptors in the GUT private table passed on the stream.

The flag for each filter instance, titled "EngineState", has an initial state called "engineStateI-nit": "engineStateInit" is an initial state preceding a filtering request. An "engineStateInAcq" state of this flag corresponds to the reception of an event following a filtering request. An "engineStateRetry" state of this flag corresponds to a retry processing due to a load failure. The EIT schedule can be sent to the MPEG-2 stream on multiple tables or sub-tables with table identifications, table id (multiple). EIT tables for the same service).

The identities, tables-id, tables to load depend on the number of days of data to be stored in the memory and the segment table (depending on whether it is used as a fixed or sliding window).

If the EITs are to be retrieved from several tables identified by their Tid table identification, the loading order is "For the current service id For the current Tid Loading the EIT Switching to the next TableId (Tid) of the current service Firi for Passage next service in GUT - @FinPour "This order corresponds to a loading of all the tables of a current service before loading the next service according to the order defined by the GUT table.

Since the DVB-SI standard requires that events be transmitted in chronological order, the events will be stored in chronological order in the memory. This order is important insofar as a chronological extraction of the different events of a chain avoids a step of sorting the information. Thus, the events are in the memory in the logical order of their diffusion.

The operation of the engine acquisition scheduler is described below. The processing of the error cases do not appear in this description.

0) Initialization of the acquisition engine, the common flag on the type of acquisition is set to its initial state "encqineModeInit". 1- Acquisition of the GUT user guide table 2- GUT guide table acquired memorization of the version number of the "version number" table and the general update flag "full update_counter" 3- Construction of the list of services and storing the service counter values "service counter".

All services are marked "to acquire.

4- Acquisition of information tables on events - '= for marked services' to be acces- sible'. If we come from (3), n filters (-xé = `@ ar the application, or 10 by default) are used because it is a complete acquisition.

If one comes from (7) or (8), (which will be described below) n filters (set by the application, or 3 by default) are used because it is an update.

For each information table on EIT events, up to 3 retry attempts are made if the first attempt fails.

The acquisition ends when all EITs have been acquired (or failed after 3 retry attempts) for an EIT with a given table-id.

The EIT information tables for EIT events not acquired after 3 retry attempts remain marked "to be acquired". They will be reacquired during a next version of GUT table, see below.

If all the tables to be acquired have been acquired, go to (5) described below. Otherwise return to (4) _ for acquisition of the next table and the same filter. 5- Acquiring the GUT user guide table 6- GUT user guide table acquired If the current GUT guide update table has the same version number version and the same update flag value. general day "full update_counter" than a previous GUT user guide table, one returns in (5) after for example 30 seconds (survey of the table GUT every 30 seconds.). - <I> Y </ I> .e. If - * 'the GUT user guide table has the -, --- same version number version # # @ .-' a general update flag values "full update_counter", different from the a previous table is passed to (7) described below.

If the value of the general update flag "full update_counter" of the current GUT user guide table is different from that of a previous table, go to (8) described below.

7- We update service_counter services.

The list of services is completed if new services appear at the end of the GUT.

If at least one "service counter" is different from the previous one or if a new service appeared in the list, the corresponding services are marked "to acquire", and one returns in (4). It is recalled that previously unrecovered EITs are already marked 'to be acquired'.

8- Reconstruction of the list of services and memorization of the "service counter".

All services are marked "to acquire". The EPG memory is not reset Back to (3).

We can summarize the flowchart just described by saying that after an initialization step - we create an update tracking table listing the services and associating them with a "service counter" service version number. version number "version number" of the events.

- we acquire the tables of information on the events. corresponding to the services appearing in the update table GUT ---- - periodically renewing the acque: i: L: .Qh of the update table GUT, and comparing the current table to the previous table, - if the table is unchanged and all the services have been acquired previously, the acquisition of the GUT table is renewed until a change is made with the previous GUT table, - if the GUT table is changed or if event information tables have not been acquired the necessary acquisitions are made to complete the information on the services, - if a large number of changes have occurred, we redo a complete acquisition of the table GUT and the tables d information on events.

The EITs Information Table Analyzer module will now be examined.

This module allows the analysis of the descriptors contained in an EIT section. The Engine module requests section-by-section analysis in chronological order.

The engine acquisition engine module passes to the analyzer an EIT section and receives feedback on the events contained in this EIT.

Three types of information are retrieved for a given event, standard DVB-SI information out of descriptor, information associated with DVB-SI descriptors and information associated with private descriptors. - the "standard DVB-SI information" out of the box are present for each event - they are defined by the DVB-SI ETS 300 468 standard, here is a list for example The Event Id: Unique identifier of an event for a given Id service (a string).

 StartTime: Event start date (UTC GMT format).

 Duration: Duration of the event. FreeCaMode: Criterion for access to the event.

The information associated with DVB-SI descriptors is optional. All optional descriptors associated with the DVB-SI standard are supported. For example short_event descriptor: Title and summary of the event.

content descriptor: genre of the event.

The information associated with the private descriptors, once specified, any private descriptor can be supported by the analysis module. For example, an access control-specific descriptor is used to describe PPV (pay per view) .type events.

The information extracted for each event is grouped into a specific structure that serves as an exchange structure with the module responsible for storing the data. we then speak of exchange cell. Each exchange cell contains all the information corresponding to an event. The exchange cells vary from one project to another depending on whether they integrate data associated with private descriptors or not.

- As an example, some of the can- = `who can- be associated with and retained to be included in such an exchange cell.

 event_id 2 bytes identity of the event * / start_time; / * 5 bytes start time of event * / eventFlags; / * 1 byte flag for paid events / content nibble 1 byte (obits for a first level and 4 bits for a second level) description of genre 1 and 2 * / duration; / * 3 bytes duration of the event Parental_rating; / * 1 byte information code for parents * / title_id; / * 2 bytes title identity * / taken; / * 4 bytes amount indication / evtTitleLen; / * 2 bytes length of the title in bytes * / Some information appears only conditionally, one of the conditions being that this information is contained in the description contained in the table. By way of non-limiting example, we can cite ppvSession; / * 2 bytes transfer number purchase win; / * 1 byte purchase window * / evtSummaryLen; / * length in bytes of the summary of the event * / - The description of the data memory module (SICache) will now be carried out. - "------ The SI (SICache) data memory is responsible for storing the information extracted from the EIT event information tables in memory.The simplest way to store this information would be to store the Each EIT table of each service requires, as explained above, a lot of memory, and can not be implemented in an 8 MB STB embedded environment.

Also the SICache module offers compact storage of information. The storage principle used guarantees the compactness of the information, therefore the allocation to the byte close to what must be memorized. In order to implement the storage principle, storage is done in three steps.

Before exposing the dynamics of construction of the cache, let us recall the different types of data manipulated. The memory represents a database containing services (strings), themselves containing a sequence of events. These notions have been explained above.

The entire database is therefore made up of a given number of couples, information about the services - information about the events of those services, or said in an abbreviated way services / event lists. A brief diagram of these pairs, service - list of events, is shown in FIG. 1. -A each service numbered 1p, p ranging from 1 to @ixn 'integer n representing the number of services, 11, 12, 1p 1n is associated with a compact memory zone 21, 22, 2p 2n.

Each service element contains three pointers, two pointers, one of which gives the address of a previous service element and the other the address of a next service element, in order to define a doubly-linked list between the different services. third pointer gives the address of the beginning of a data zone containing the information specific to the description of the events of this service. Of course it would be possible to have a pointer giving the address of a service for example a next service instead of the two previous and next pointers. It will be seen later that this choice of two pointers facilitates the journey of services without consuming a lot of memory space. in addition to these three pointers, each service element contains information called ServiceInfo. "The example of information contained in ServiceInfo is given hereafter: OnId initial identity of the service network TsId transport stream identity Transport Id (Transport Stream Id) of the ServId service Service Identity (Service Id) ServNum ServKey Service Number Service Key nbOfEvent Number of events contained in this service Signature service signature * buildEvents Pointer to u ne - = - - chain linked list of events (during build otherwise null) sizeOfBuild: Size in bytes of all events put end to end.

 * eventsDataBase event database put end-to-end ** events Table containing pointers to events.

The data structure corresponding to the event is composed of two parts. A part containing data which, when present, is of constant length (number of bytes) and a part whose length varies from one event to another. Some of the so-called optional constant length data may or may not be present. Similarly, the variable length data may or may not be present.

Examples of constant length data that appear in all events and for this reason are said to be common to all events are given below event_id 2 bytes event identity * / start_time; / * 5 bytes start time of event * / eventFlags; / * 1 byte flag for paid events / content nibble; / * 1 byte (obits for a first level and 4 bits for a second level) description of genre 1 and 2 * / duration; / * 3 bytes duration of the element Parental_rating; / * 1 byte information code for parents * / evtTitleLen; / * 2 bytes length of title in bytes * / evtSummaryLen; / * length in bytes of the summary of the event. Some optional data have a constant length but do not necessarily appear.

If for example an event is of type ppv (pay per view) additional data will be associated with this event such as its price, its reference etc.

 title_id; / * 2 bytes title identity * / price; / * 4 bytes amount indication / ppvSession; / * 2 bytes number of assignment * / purchase win; / * 1 byte purchase window. Unsurprisingly, in the examples of common data and optional data, we find the data already mentioned above in the description of the extraction engine. Optional data is data that is only present on the stream if certain conditions are met. The extraction engine extracts these data from the stream only if the conditions are met, so that at the data memory level, these optional data may or may not be present.

The variable length data that may or may not be present are for example the title of the event or its summary which comprise a variable number of characters and are thus represented by this same variable number of bytes.

In the preferred embodiment of the invention, each compact zone 2 comprises, as represented in FIG. 2, a first compact sub-zone 3 containing the data common to all the events, this first sub-zone 3 which groups always present data of constant length is itself of constant capacity. Immediately adjacent to this first subfield is a second subfield 4 grouping all optional data of constant length and finally a third subfield 5 immediately adjacent to the second subfield grouping all data of variable length.

In order to make the use of the base as flexible as possible, the small data, for example the services requiring a capacity of approximately 20 bytes, are linked to one another and the larger data, for example those relating to events whose size is often greater than 120 bytes' are compactly stored, i.e. in a continuous memory area. The service elements are doubled chained to each other. This double chaining ensures faster navigation between the different services. A schematic representation of this double chaining is shown in FIG. 3 for a number n equal to 4. Each service 11, 12, 13, 1n = 14 is linked by two pointers represented by arrows 6 and 7 to the following service and to the preceding service respectively . In FIG. 3 each arrow 6 is referenced by the number 6 followed by the number of the following service, thus the arrow 61-2 symbolizes the servic pointer 11 denoting the service 12, and the last serving is the same. A pointer 611 denotes the first service 11. Similarly, each arrow 7 is referenced by the number 7 followed by the number of the preceding service, so the arrow 713 symbolizes the pointer of the service 14 designating the service 13, and the first service having a pointer 714 designating the last service 14.

The event elements are large (> 120 bytes). Also in order not to fragment the memory, they are chained or stored end to end in a memory zone which has, especially, been allocated to them. To keep the pointing information of each event, pointers referencing them are also stored in an adjacent table. Such a table 8 is shown in FIG. 4 with the compact event memory zone 2 associated therewith. In FIG. 4 the array has been referenced 8p and the compact memory zone 2 has been referenced 2p to indicate that there is an array 8p associated with each compact zone 2p. If the compact area 2p shown in FIG. 4 contains information on 5 events 2p1, 2p2, 2p3 2p5, the table 8 contains as many pointers as the area 2 contains events, in the case represented 5 referenced 8p1 to 8p5 pointing to the beginning. of each event 2p1 to 2p5 of the service 2p. This table of pointers allows direct access to the different events of the 2p service. There is a one-to-one correspondence between each epi pointer in Table 8p and the start address of an event. For example, the pointer number 8p5 of table 8p points to the fifth event 2p5 of the service 2p associated with this table 8p. A link is also created between the service elements and the event elements. Figure 5 is represented by two pointers, a pointer 9p1 pointing from the service 1p to the beginning of the memory zone 2p and a pointer 9p2 pointing to the beginning of the memory zone 8p containing the array of pointers 8p1 to 8p5. Each service element type 1p corresponds to a compact memory area 2p containing events 2p1 to 2p5 and an array 8p of pointers 8p1 to 8p5 each pointing events 2p1 to 2p5. He is not reserved for memory by anticipating the worst. We allocate to the byte by the memory that we need. In addition the structures are sufficiently accessible for consultation, since the purpose of the cache is to restore the information as quickly as possible.

The construction takes place in three stages. A channel or service is marked by its DVB triplet. This triplet is constituted by the identification of the initial network on which the channel is broadcasted "network Id", the identification of the transport stream used by the "stream Id" service and the identification of the "service Id" service. Once the cache is initialized, a string can be added to the cache. The parameters to be given to the table acquisition engine are the original "network Id", the "transport stream Id", and the "service Id". Multiple channels can be created at the same time. As shown in Figure 6 a first chain 11 is created. This string 11 does not contain any event at this stage and the size of the events is zero. Pointers 911 and 912 are empty. The loading of the EIT tables on the flow is done in parallel. Also the cache gives the possibility to build several services at the same time: The construction then follows the same model as the data loader: the parallelism. As shown in Figure 7 chains 12, 13 can be added to the first 11, each of the chains 12, 13 added is in a first empty phase and is therefore the same way as the first chain shown in Figure 6. When an EIT table is received and its analysis is in progress, the information corresponding to the events is extracted and inserted into the cache. The analysis of the EIT table is done only once. The SICache application does not know in advance how much memory it needs to allocate to receive event information. As a result, a linked list of events is performed. This list is only used during the build phase of the cache. When all the events have been added, its contents will be copied to a compact 2p memory area as explained above and then the linked list of events will disappear. Events can be added to a channel. Each time an event is added, the size in bytes of this event is calculated, and an accumulation of event sizes makes it possible to know how much memory will be allocated when the last event is inserted. The addition of an event to a chain is represented in FIG. 8. The information on the first event for example of the service 13 is inserted in an element 2'31 of a temporary linked list 2'3, the service element 13 receives information on the cumulative number of events and the size of each event. The linked list of events of the service for example 13 is constituted as represented in FIG. 9, by successive additions of the various events 2'32 e @@ # - 3-to-the-chain. A calculation of the sum of the sizes is performed. The same operations are carried out for each of the n chains as represented in FIG. 10. This figure represents a linked list of services 11 to 14. Each service contains information relating to the number of events that have been added in this service and the size of the service. the sum of the information relating to each event. The event elements for example 2'11, 2'12, 2'13 of the first chain 2'1 are like those of the other chains, chained together.

When all the events of a string have been extracted from the EIT table corresponding to this string and simultaneously inserted in the linked list used for the construction, the cache can then format the data in order to "hide" them permanently. This is done by calling a data formatting function called "fitChannel".

At the end of the construction phdse, for each service we are in possession of the following information. the number of events that make up the service.

the cumulative size of all events. The number of events is used to calculate the size of the array of pointers referencing the formatted events. The cumulative size of the event information allows the necessary and sufficient allocation of memory for the copy of the linked list. The compact area of allocated memory will then contain the events put end to end.

For a chain composed of N events. whose accumulative size is TK bytes we will realize: -, the following allocations: --- - `N x 4 for the array of pointers (1 pointer = 4 bytes) K bytes for the compact and continuous memory area. an integer representing the sum of the number of bytes of information relating to each event.

A diagram for a chain 14 for example broadcasting 4 events is shown in FIG. 11. At this stage of the creation of the cache i1 is reserved in the memory an empty array 8'4 containing just the memory space necessary for the storage of the four pointers and one compact empty zone 2 "4 just large enough to contain the number k of bytes representing the sum of the information quantities in bytes contained in the description of the 4 events, and then proceed as shown in FIG. the copying of the events from the temporary linked list to the compact and continuous zone 2 "4 'of memory. This zone when it is filled is referenced 24. It includes the information on the first to fourth event of the chain. This information is stored in adjacent areas of the compact zone 24, 241, 242 .... The array 8'4 of pointers is filled since we know the address of the beginning of each event and takes the reference 84. stage 2'4 chain of events is always present. This linked list, which was used to build the cache, is then erased, releasing the corresponding memory space, so that the associated string and event structure takes on the appearance. This aspect corresponds to that of FIG. 5 already described, and by way of nonlimiting example, the hardware aspect of the memory used will now be commented on.It has been used a Mediahighway cTm type memory. This memory is divided into three parts.

A part reserved for manipulation handles, this part makes it possible to associate with each logical address a physical address in the memory. This part of the memory is reserved for the manipulation of objects.

A dynamic part, it is a part of the memory in which the objects are used via the handles. This part of the memory is defragmented by software provided with the memory by a process known as garbage collecting.

A static part, this part is a conventional memory that we use via pointers). The SI data cache uses dynamic and static memory. This double use makes it possible to guarantee a minimum of fragmentation and a reduced consumption of memory.

By definition a pointer in a dynamic memory data area is a handle, ie as explained above a double pointer. It therefore consumes twice as much memory as its equivalent consisting of a simple pointer, in static memory (8 bytes instead of 4). So the more pointers you have, the more interest you have in using static memory.

Also in order to minimize the fragment-ati @ ri, - small data (<40 bytes) should be stored in the dynamic memory and large data packets (> 1Ko) should go into the static memory.

The construction of the cache and the location of the elements in the static portions 100 and dynamic 10 of the memory will be briefly reviewed below, each time specifying the locations. In FIGS. 14 to 16, the dynamic and static portions 100 of the memory are separated from each other by a dotted line.

As shown in FIG. 14, the lists 11, at 1n chained services defined above are in a zone 10 of dynamic memory. Indeed, the string element consumes only a few bytes. In addition, from one cache build to another, the number of strings can vary. A use of the dynamic memory avoids the fragmentation of the static part of the memory. The lists represented by way of example 2'n to 2'15 and 2'n1 to 2'n7 linked events which, it is recalled, are an intermediate tool for building the static memory, are in the dynamic memory zone 10 Since it is temporary, once erased the waste recovery "garbage collecting" guarantees defragmentation of all the previously used dynamic memory.

After copying the strings and as shown in FIG. 15, the compact areas 2 (21, 2n) of events are in a part 100 of the memory corresponding to static memory-since these areas are often large in size. - can stay stable for periods of about 48 hours. Moreover, in this part 100 each event is referenced by a pointer and not a handle. The economy of 4 bytes per event is not negligible.

Tables 81 to 8n of event pointers are also found in part 100 corresponding to static memory. Since an empty table 8 "of pointers (not shown empty) is allocated at the same time as an empty area 2" compact of events, there is little risk of fragmentation.

After deletion of the linked lists 2'1 to 2'n the cache has the appearance shown in Figure 16 where the portion 10 of dynamic memory contains only the linked list of services 11 to 1n. The pointer tables 8 and the compact areas 2 are in the static memory area 100 whereas the linked list 1 of the services is in the dynamic memory part 10. In the preferred embodiment. protection against memory saturation is provided. Due to its fully dynamic model, the data cache SI can, if too much information is broadcast, saturate the memory of the decoder or the "Set Top Box". Also, to ensure protection against this phenomenon, a system of terminals can limit the number of hidden elements.

The terminals are configurable when the cache is initialized. Possible bounds are as follows Maximum number of channels or services. 'Maximum number of events per service.

Maximum number of characters for the title of the event.

Maximum number of characters for the event summary.

This terminal system makes it possible to evaluate the size of the cache once it is constituted. For example, consider a string element stored in the dynamic memory part, whose data has a size of N bytes. The size of the data of this element chain is thus of N + 2 * 8 bytes (+ 2 * 8 for the two handles which ensure the double chaining) is N + 16. Suppose the events have an average size of M bytes. For each event we must count its associated pointer so we have M + 4 byte per event.

The calculation of the base size is Cache Size = (NbMaxChannels * (N + 16) + NbMaxChannels * NbMaxEvtParString * (M + 4)) / 1024 kilobytes. Encrypted example: 200 strings, 80 events per string, (3 days of program averaged) with 20 bytes for chained data of a string and. an average of 140 bytes for an event.

Cache Size = (200 * (20 + 16) + 200 * 80 * (140 + 4)) / 1024 Cache Size = (7200 + 2.304.000) / 1024 Cache Size = 2257 KB Cache Size = 2.2 MB we see that it is important to define the limits of the system. It should also be noted that, 99.99% of the database is in static memory and: that Static memory also hosts the keys downloaded so if it is satire; - download of applications is no longer possible.

The memory consultation module, "data browser" IF (eventbrowser package) will now be described.

As soon as data is available in the IS cache, they can be retrieved using a memory viewer. The cache does not have to be complete, even partially filled, it can be consulted by the applications. However, at least one string has to be formatted for consultation. Access to the data is through iterators. There are two types of iterators An iterator based on strings or services An iterator based on events. The chained iterator traverses ("browse") the doubly-linked list in the dynamic memory portion described above. Due to its dual chaining the rear and front movements are simple and fast. The functions "read and go to the next" (readAndGoNext) and "read and pass to the precedent" (readAndGoPrevious) allow you to retrieve information about each of the strings browsed (browsed). The information is included in an object of the string class. Multiple features are also available, such as searching for a channel, positioning a magnifying mode.

 The event iterator allows,,: as the iterator of strings, to return instances; (objects) of the DVBEvent event class, each of which relates to all the information relating to an event, but there are two distinct types of iterators, the iterator of events associated with a string, and the iterator of sorted by genre.

 The event iterator associated with a chain makes it possible to browse ("browser") the events associated with a chain. This type of iterator is particularly used in the construction of program grids.

 The iterator of events sorted by genre allows, as its name indicates, to sort the events on a specific criterion that the sorted events fill. Such iterators are used, for example, to build genre-sorted lists such as all movies or all sports events, etc.

When building such an iterator, event pointers are stored in an array of related pointers. This table is constructed in two stages as shown schematically in FIG. 17. The set of compact areas 2 of events of all the chains is scanned and analyzed. If the event fulfills the filter condition, it is marked with a flag ("tagged") and then a counter is incremented. The marking of the event is represented in FIG. 17 by a first arrow f directed towards an event of zone 2. In the example shown in FIG. 17, the first event zone 21 comprises two films, the compact zones 22, 23, 24 , 25, 26, 210, 211 comprise a single film, the compact areas, -27, 28, 29 do not contain the desired event. 9 events have been found fulfilling the criterion-~ ~ ~ -tri and therefore the event counter is at 9. Once the entire database has been traversed, the static memory necessary for copy the pointers of the marked events. In the example shown it is an empty array 200 at this stage containing just the memory space necessary for the registration of 9 pointers 2001 to 2009 Finally a second runs through the base to copy the pointers of the events marked in the newly created static memory space and to demarcate these events. The mirroring of the pointers is materialized by a second arrow g directed towards the pointer of a marked event.

Once the pointers are copied, direct access to all tagged events is built. According to the criteria of construction of the iterator, a sorting in chronological order and / or in alphabetical order can then be realized.

An illustration of such an iterator use is given in FIG. 18 in which the array 200 is represented with an arrow by pointer each pointing to one of the sorted events. In the preferred embodiment of the invention, the module of FIG. Memory consultation includes a function of verifying the relevance of the data scanned so as to ensure that the information is up-to-date at the time of viewing. This function will be described below.

An SI data is said to be "relevant" if it is identical in the memory cache or in the broadcast MPEG stream. The SI data cache is relevant if it exactly mirrors the data that is broadcast to their set. It must therefore be able to detect dynamic updates made on the stream (see The EIT Acquisition Engine) When an instance of a string or event class is created via the memory browser module. SI data, this contains a copy of the information contained in the cache. This information may change as the cache may change. A channel can be reprogrammed, ie erased from the cache and reloaded. The java data representative of this string before reprogramming are obsolete. Likewise, a specific event iterator can be updated. It is therefore advisable to warn the user. This is accomplished through the exception mechanism.

As soon as the data associated with a channel broadcast on a transport stream is formatted, the channel stores a signature. This signature is issued by a signature server. This server guarantees to never give two identical signatures after each construction of the same chain. Each instance of the string class copies this signature into its internal data. At each method call on this string object the signatures are compared. If they are identical, the data in the chain is relevant and can be browsed. Otherwise, an exception is raised telling the application that the string object it is using is obsolete. It is therefore appropriate for the application to request a new instance of the class, string, or to request the update of the class. As soon as the data of a string are updated, it is necessary to invalidate (render obsolete) event specific iterators. An iterator contains event addresses. It is therefore necessary to guarantee each browsing operation on an iterator that the addresses it contains point to current events and not to obsolete data. To do this each iterator is validated by a boolean. With every modification of the base as small as it is, this boolean in the form of a flag is positioned at a position of invalidation "false" in order to invalidate the iterator. In the same way as for the data of a chain, with each operation of consultation (browsing) on an iterator, a check is made on its validity. If it is invalid, an exception is thrown. Therefore, the application must request a new iterator instance or request an update of it. Update requests are sent by the consultation module to the motor module.

Another advantageous feature of the invention will now be examined.

The cache according to the invention exploits the static and dynamic parts of the memory. The SI data coexists with data related to the basic functions of the system (virtual machine operation, class loading ...). In the case of prolonged operation, static memory; is fragmenting. ' This is inevitable because the exploitation of the cache: _. allows partial erasure see soon-to-r - data 'SI. The memory manager does not perform any defragmentation operation on the static part of the memory. This problem of fragmentation of the static zone can lead to the impossibility of loading new strings in memory although the place exists physically.

To remedy this problem, according to this characteristic of the invention defines a specific memory area for the data cache SI. Only in this space, the SI cache can evaluate at any moment its degree of fragmentation. Similarly, it can reorder the data blocks IF and defragment its memory when the system allows it: standby or system not active for some time. This mechanism is in all respects similar to managing the defragmentation of a hard disk on a PC.

The two advantages of this specific area of memory are the guarantee of non-fragmentation of the data cache SI on the one hand and the non-interference with the nominal operation of the system on the other hand. Note that one can use for this purpose the implanted software defragmentation of the dynamic memory part. To do this, it is necessary to modify periodically or on request the setting of the dynamic memory part and the specific part of static memory, to make all of the static memory dedicated to the SI applications dynamic, then to set a limit once again. defragmentation done.

It is also possible to better manage the data if you use a hard disk. Of course .. the file system manager must be a defragmentation tool.

The method for constructing the program information database and the consultation method of this database are in the form of software implanted in a memory of an apparatus, for example a television, a decoder or a video recorder. The software can also be imported for example in the form of a medium containing the software to be introduced into the device or by download.

Claims (9)

A method of constructing a database of periodically broadcasted event information in the form of a data stream by one or more service providers in which a) a file of different identified services is made capable of broadcasting information. b) extract and store a part of the information for each event, c) select for each event the information that is to be stored for a given event. long duration, d) we determine the number of bytes contained in the information selected for each event as well as the sum of these amounts of information for all the events of each service, e) we search a memory address area large enough to store in an unfragmented manner all the selected information relating to all the events of a first service one after the other, f) copy in the unfragmented address areas found in step e) each of the events of the first service one after the other, g) complete the file of the services by adding, in a file of this file corresponding to the first service of a pointer giving the address of the pointer, the first event of this service, h) repeating steps d) to g) for each of the services of the service. service file, i) the information extracted in step b) is erased from the memory. 2. Construction method according to claim 1, characterized in that in step d) an account is also kept of the number of events to define the memory space necessary for the creation of a table of pointers each giving the the address of the beginning of an event and in that in step e) there is furthermore a compact memory area of a size just sufficient to accommodate said table of pointers, and finally that step f) is entered in the table pointers, for each event, the address of the beginning of the information relating to this event. 3. Construction method according to claim 1, characterized in that the service elements of the services file are chained. 4. Construction method according to any one of claims 1 or 2, characterized in that the service elements of the services file are doubly linked. 5. Method according to any one of claims 1 to 3, characterized in that for performing steps d) to e) from the information extracted in step b). we start by creating, for each service, a temporary set of elements (2'1, .... 2'n) chained events, each event element containing the selected information (2'11 .... 2'n1. ... 2'n4) relating to an event, this set of chain events elements being created by successive additions of events (2'41-2'44) to the chain (2'4) as and when receiving information relating to each of these events, until a last event (2'44) related to this service is received, in that an account of the number of events is incremented by 1 each time the event, in that the number of bytes contained in the selected information is incremented by the number of bytes describing the event, for each of the added events, the count of the number of events being the value; of this account after adding the last event, the value of the number of octets necessary for the storage of information relating to the events of this service being said value after adding the last event of the service. 6. Method according to claim 5, characterized in that the information erased in step i) are those (2'11-2'44) which -constituent the temporary set chained. 7. Method according to one of claims 3 or 4, characterized in that the database is built on a memory with a memory management software, the software reserving - a first part (10) of the memory in which a dynamic management of the elements contained therein, by means of two handles per element, one giving a logical address of the beginning of the element and the other a physical address, this dynamic management including a defragmentation function by recovery of wastes; a second part (100) of the memory in which static management is performed, and in that the linked list of services (11-1n) is stored in the dynamic part (10) of the memory and in that the compact areas (21-2n) of events and possibly their associated pointer arrays (81-8n) are stored in the static part (100) of the memory. 8. A method of constructing a database according to one of the preceding claims, characterized in that before defining the constitution of the base, one or more terminals portârit on the number of services or re-number events by service or on other data and in that the data whose quantity exceeds the limit fixed for this datum are not loaded in the compact zone (21_2n). 9. Method according to one of the preceding claims characterized in that stores data broadcast by the service providers, and giving a service counter and an event version number, periodically comparing these data to the data of the same currently being disseminated, the results of the comparison are used to determine the services for which a new data acquisition is to be performed or the services that were not previously recorded. A method of consulting a database constituted according to one of the preceding claims comprising a linked service list and as many compact areas of events as services, these compact areas being associated with a table of pointers whose pointer each designates the beginning of the address of an event contained in the compact zone, characterized in that it comprises a service-by-service browse function in which data relating to the events of a selected service are extracted and presented. 11. Method according to claim 10, characterized in that it further comprises a function of presenting data on selected events according to one or more identifiable criteria in the data contained in the events listed in the set of. Compact data storage areas relative to the events of the various services, the selection being made according to the following steps is a first course of marking and marking events meeting the selection criterion and increments an initialized counter to zero of 1 Whenever an event meeting the criterion or criteria is marked, an empty table of pointers is created which can contain a number of pointers equal to the value of the counter after all the compact zones have been run, a second run is made to copy in the table empties the addresses of the marked events and erases the markings, the selected data is traversed by moving in the table of pointers. 12. Apparatus, especially a decoder or television receiver or video recorder containing at least one memory and a resident or importable software for implementing a method of constructing a database and / or consulting this database according to the invention. one of claims 1 to 11.