+

WO2001090898A2 - Procede de formation et d'utilisation d'une base de donnees d'evenements - Google Patents

Procede de formation et d'utilisation d'une base de donnees d'evenements Download PDF

Info

Publication number
WO2001090898A2
WO2001090898A2 PCT/FR2001/001604 FR0101604W WO0190898A2 WO 2001090898 A2 WO2001090898 A2 WO 2001090898A2 FR 0101604 W FR0101604 W FR 0101604W WO 0190898 A2 WO0190898 A2 WO 0190898A2
Authority
WO
WIPO (PCT)
Prior art keywords
service
events
event
memory
information
Prior art date
Application number
PCT/FR2001/001604
Other languages
English (en)
Other versions
WO2001090898A3 (fr
Inventor
Cyril Fenayrou
Original Assignee
Canal + Technologies
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canal + Technologies filed Critical Canal + Technologies
Priority to AU2001264013A priority Critical patent/AU2001264013A1/en
Publication of WO2001090898A2 publication Critical patent/WO2001090898A2/fr
Publication of WO2001090898A3 publication Critical patent/WO2001090898A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding

Definitions

  • the invention relates to the field of collection and exploitation of digital data relating to events of television channels or services. It relates more particularly to a method used to build a database on such events as well as the use of the database thus constructed. ⁇
  • the providers or broadcasters of service that is to say programs
  • television or radio broadcast tables of data relating to the events which can be picked up by a user of a device for receiving these events, for example a television receiver equipped with a digital decoder or a digital decoder supplying a television receiver.
  • Service broadcasters for example broadcasters of television broadcasts not only events or television programs, such as films, matches, variety shows, but also other information in particular on planned emission programs, in principle according to a pre-established standard.
  • ETS 300 468 and the technical report ETR 211 provide a format for event information tables, (event information tables, EIT).
  • event information tables EIT
  • the examples will be taken from this standard to fix the ideas.
  • the vocabulary used will have the definition provided for by this standard and this report. It is however obvious that the invention is not dedicated solely to an application using this standard.
  • the SI data allows applications of the Electronic Program Guide type to be carried out.
  • the DNB-SI ETS 300 468 standard defines information outside the descriptor, optional information associated with the descriptors and private information contained in private descriptors.
  • the descriptors are information of variable length such as for example a film or program title or a summary describing the program. Information outside the descriptor is present for each event. Some examples are given below.
  • Event Id Unique identifier of an event for a service with a given "Service Id" identification (a string).
  • StartTime Start time of broadcast of the event (UTC GMT format).
  • Duration Duration of the event.
  • FreeCaMode Access criteria to the event. Examples of optional information associated with the DNB-SI descriptors are cited below: short_event_descriptor: Title and summary of the event. content_descriptor: this descriptor corresponds to a classification of the event. Finally, information associated with the descriptors is private, that is to say specific to a broadcaster.
  • a descriptor specific to access control can be used to describe events commonly called PPN (pay per view), requiring, to be seen, a payment from the user
  • EIT "schedule" information relating to the programs of the same broadcaster can be sent for example, on the MPEG-2 stream on a or several tables or under tables each of these tables or under '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.
  • the data transmitted on the first of the tables identified by its Tid corresponds to the first day of the month.
  • the DNB-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 standard. It also recommends that the description of events be organized in sections each comprising a maximum of 4096 bytes with at least one section per three-hour program period. Eight sections form a segment. A subtable does not have more than 32 segments, or 256 sections in total.
  • Program guide applications also known as EPG for Electronic Program Guide
  • EPG Electronic Program Guide
  • This solution consists of only retrieving from the stream of disseminated data the information necessary for a given application, depending on the application and the parameters of this application. For example if a spectator wants to know what will be broadcast the day running on a channel, from 8 p.m., only this information will be sought on the stream, memorized and used to be presented in an orderly and understandable manner for the viewer. As a result, the amount of memory used is reduced.
  • STB set top box
  • the invention therefore relates to a method of collecting, in a memory, information relating to the programs which allows optimal use of a capacity of this collection memory. It aims to allow the collection of this data in parallel. It also aims to organize this memory into a database that is quick and easy to access. By this we mean that the presentation to the spectator of the most commonly sought data requires only few instructions, this because of the way in which the database is organized.
  • 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.
  • the invention relates to a method of constructing a database relating to event information periodically disseminated in the form of a data stream by one or more service providers in which: a) we constitute a file of different identified services likely to broadcast event information, b) extract and temporarily store at least part of a series of information on the events broadcast by each service, c) we select for each event the information that we want to store for a long period of time, d) we determine the number of bytes contained in the information selected for each event as well as the sum of these quantities of information for all the events of each service , e) a memory address area of sufficient size is sought to store therein in a non-fragmented manner all the selected information relating to s to all the events of a first service one after the other, f) we copy into the non-fragmented address areas found in step e) each of the events of the first service one after the other, g) we complete the file of services by adding, in a this file corresponding to said first service of a
  • step d) is completed by taking account of the number of events to define the memory space necessary for the creation of a table of pointers each giving the address of the start of an event of this service, completes step e) by also looking for another group of memory addresses to house the array of pointers, each pointer of which gives the address of the start of an event, and finally during step f) we register in the table of pointers, for each event, the address of the start of the information relating to this event.
  • the space occupied by the selected information is minimum since all information not directly useful to the viewer or to an application for researching or selecting among the events has been removed from the information received.
  • pointers are used for the exploitation of this information at the rate of one pointer per event.
  • operations a) to i) can be executed in a different way without changing the final result. So for example we can only collect information on events relating to a single service, process this information according to steps a) to i) with the exception of step h), then repeat the same processing for each of the others. services.
  • the advantage of this last solution is that the instantaneous volume of memory required is less, which can be useful.
  • the disadvantage of this last way of doing it is that one does not have information from the start as for all the volume necessary for the storage of information.
  • the individual files relating to each service are chained, this means that each file contains a pointer giving the address of a next service, a last file having a pointer giving the address of a first file.
  • each file relating to each service are doubly linked. This means that each file also contains a pointer giving the address of a service preceding a first file having a pointer giving the address of a last file. In this way you can browse the list of services in an increasing or decreasing direction.
  • each server file contains three pointers, a pointer giving the address of the first service event, a pointer giving the address of the start of the next service file and a pointer giving the address of the start from the previous service file.
  • the updating of the data is simplified in the following manner.
  • the service provider (s), or at least some of them, distribute an update table *.
  • This table in addition to identification data, essentially contains indicators relating to version numbers of the service and of each event.
  • the service version numbers are called “service version counter” or “version counter” and the event version number is called version number.
  • version number is called version number.
  • the comparison of the service version counter currently broadcast with a previously stored service version counter makes it possible to know whether or not it is necessary to make a new recording of data for this service.
  • the private update table may also contain a general update flag indicating that a large number of data have changed, which results in a re-recording of the data from this service.
  • FIG. 1 represents a part of a database constituted according to the invention
  • FIG. 2 represents the constitution of a compact zone 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 area 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
  • FIGS. 6 and 7 illustrate stages of the constitution of a file of services
  • FIGS. 8 and 9 illustrate stages of the constitution of a linked list of events
  • FIG. 1 represents a part of a database constituted according to the invention
  • FIG. 2 represents the constitution of a compact zone 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 area 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
  • FIGS. 17 and 18 illustrate stages of the constituti we have a table of pointers for a consultation on determined criteria and the final appearance of this table and its links with the selected events.
  • the SI table acquisition engine module acquires the EITs of all the services so that the data is available from the applications as quickly as possible. To do this, parallel loading is preferred.
  • the table analyzer module is responsible for browsing the EITs tables and extracting the relevant data which are formatted to be stored in memory.
  • the memory management module is responsible for managing the storage of the elementary units representing a program as well as for organizing the memory.
  • the memory consultation module is responsible for giving applications a library of functions intended to browse the event database. and establish lists sorted according to certain criteria.
  • the EIT table acquisition engine module manages the acquisition on the flow of EIT "Schedule" tables, their analysis (via the analyzer), and their storage in memory via the memory manager. This engine also manages, according to an advantageous characteristic of the invention, the updating of the information contained in the memory when modifications to this information or new events are transmitted on the stream.
  • the EIT "Schedule" tables can represent a high data rate depending on the number of events and the number of services present. It follows that, continuously monitoring all the EIT tables to detect changes, represents a relatively long time.
  • GUT Guide Update Table
  • SDT service description tables
  • EIT event information table
  • the GUT table contains the list of all the services containing events present on the transport stream of the data tables (transport streams). These services containing events are identified by their service identifications (service_id). This GUT table makes it possible to monitor the changes in all the events present on the transport flow by monitoring only this single table.
  • service_counter service version counter
  • version_number version number
  • full_update_counter full_update_counter
  • the state machine of the data acquisition engine module is sequenced by demultiplexer drivers.
  • EngineMode a common flag on the type of acquisition
  • EngineState a flag for each filter instance
  • engineModeBuild corresponds to a complete loading of the memory following a complete modification of the diffusion of the EITs tables, detected by a new value of the flag of general update "full_update_counter” in the private table GUT 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 version number
  • the flag for each filter instance, titled “EngineState” has an initial state called “engineState nit”: “engineStatelnit” corresponds to an initial state before asking a filtering request.
  • An “engineStatelnAcq” 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 following a loading failure
  • EIT schedules can be sent over the MPEG-2 stream to several tables or sub-tables with table identifications, table id (several EIT tables for the same service).
  • the identities, tables-id, of the tables to load depend on the number of days of data to memorize in the memory and in the segment table (depending on whether it is used in a fixed or sliding window).
  • the loading order is: "For the current Service__id: For the current Tid: Loading of the EIT
  • This order corresponds to a loading of all the tables of a current service before passing to the loading of the next service according to the order defined by the GUT table.
  • the DNB-SI standard requires that the events be transmitted in chronological order, the events will be memorized in chronological order in the memory. This order is important insofar as a chronological extraction of the various events of a chain avoids a step of sorting information. Thus, the events are in the memory in the logical order of their diffusion.
  • n filters (set by the application, or 10 by default) are used because it is a complete acquisition. If we come 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.
  • the EIT program 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 an EIT section to the analyzer and receives in return the information on the events contained in this EIT.
  • DNB-SI standard information without descriptor is present for each event, they are defined by the DNB-SI ETS 300 468 standard, here is a list for example:
  • the Event Id Unique identifier of an event for a given Id service (chain) .
  • StartTime Start date of broadcast of the event (UTC GMT format).
  • Duration Duration of the event.
  • FreeCaMode Access criteria to the event.
  • DNB-SI descriptors The information associated with the DNB-SI descriptors is optional. All optional descriptors associated with the DNB-SI standard are supported. We can cite as an example: short_event_descriptor: Title and summary of
  • any private descriptor can be supported by the analysis module.
  • a descriptor specific to the control is used to describe PPN (pay per view) type events.
  • 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.
  • Event_id / * 2 bytes identity
  • the data memory SI (SICache) is responsible for storing in memory the information extracted from the information tables on the EIT events.
  • the simplest solution to store this information would be to memorize the sections of each EIT table of each service. As explained above, such a solution requires a lot of memory, and cannot be implemented in an on-board environment of the 8 MB STB type.
  • the SICache module also offers compact storage of information.
  • the principle of storage retained guarantees the compactness of the information, therefore the allocation to the byte close to what must be memorized.
  • memory storage is carried out in three stages.
  • the memory represents a database containing services (strings), themselves containing a series of events. These concepts have been explained above. The entire database is therefore made up of a given number of couples, information on the services - information on the events of these services, or said in an abbreviated manner couples services / lists of events. A brief diagram of these pairs, service - list of events, is shown in Figure 1. Each service numbered lp, p ranging from 1 to an integer n representing the number of services, 11, 12, lp In is associated with a zone compact memory 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, a third pointer gives the address of the start of a data zone containing the information specific to the description of the events of this service.
  • a third pointer gives the address of the start of a data zone containing the information specific to the description of the events of this service.
  • each service element contains information called "Servicelnfo".
  • Servicelnfo An example of information appearing in Servicelnfo is given below: Onld initial identity of the service network
  • the data structure corresponding to the event is made up of two parts. A part containing data which when they are of constant length (number of bytes) and a part whose length varies from one event to another. Some of the constant length data said to be optional at this stage may or may not be present. Likewise, variable length data may or may not be present. Examples of constant length data that appear in all events and that for this reason are said to be common to all the events are given below: event_id; / * 2 bytes identity of the event * / start_time; / * 5 bytes start time of
  • Parental_rating / * 1 byte information code for parents * / evtTitleLen; / * 2 bytes title length in bytes * / evtSummaryLen; / * length in bytes of the event summary. Some optional data have a constant length but do not necessarily appear.
  • an event is of the ppv (pay per view) type
  • 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 transfer number * / purchase_win; / * 1 byte purchase window.
  • Optional data is that which are only present on the stream if certain conditions are met. The extraction engine extracts this data from the stream only if the conditions are met, so that at the data memory level, this optional data may or may not be present.
  • variable length data which 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 therefore represented by this same variable number of bytes.
  • each compact zone 2 comprises, as shown in FIG. 2, a first compact sub-zone 3 containing the data common to all the events, this first sub-zone 3 which groups data always present of constant length is itself of constant capacity. Immediately adjacent to this first sub-zone comes a second sub-zone 4 grouping all the optional data of constant length and finally a third sub-zone 5 immediately adjacent to the second sub-zone grouping all the data of variable length.
  • each arrow 6 is referenced by the number 6 followed by the number of the next service, thus the arrow 612 symbolizes the pointer of the service 11 designating the service 12, and the last service 14 having a pointer 611 designating the first service ll * ⁇
  • each arrow 7 is referenced by the number 7 followed by the number of the preceding service, thus 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 arranged end to end in a memory zone which has, especially, been allocated to them. To keep the time information of each event, pointers referencing them are also stored in an adjacent table.
  • Such a table 8 is represented in FIG. 4 with the compact event memory 2 zone which is associated with it. In FIG. 4, the table has been referenced 8p and the compact memory area 2 has been referenced 2p to mark that there is a table 8p associated with each compact area 2p.
  • the table 8 contains as many pointers as zone 2 contains events, in the case shown 5 referenced 8pl to 8p5 pointing to the start of each event 2pl to 2p5 of the 2p service.
  • This table of pointers allows direct access to the various events of the 2p service.
  • a link is also created between the service elements and the event elements. This link is shown diagrammatically in FIG.
  • Each element of service type lp corresponds to a compact memory area 2p containing the events 2pl to 2p5 and an array 8p of pointers 8pl to 8p5 pointing each of the events 2pl to2p5. It is not reserved from memory by anticipating the worst. We allocate the memory we need to the nearest byte. In addition, the structures are sufficiently accessible for consultation, since the purpose of the cache is to restore the information as quickly as possible.
  • Construction therefore takes place in three stages.
  • a chain or service is identified by its DNB triplet.
  • This triplet consists of the identification of the initial network on which the chain is broadcast "network Id", the identification of the transport stream used by the service "stream Id” and the identification of the service "service Id”.
  • 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”.
  • Several channels can be created at the same time. As shown in Figure 6 a first chain 11 is created. This chain 11 contains, at this stage, no event and the size of the events is zero. Pointers 911 and 912 are empty. The loading of the EIT tables on the stream is carried out in parallel.
  • the cache gives the possibility of building several services at the same time.
  • the construction then follows the same model as the loading of the data: parallelism.
  • the chains 12, 13 can be added to the first 11, each of the chains 12, 13 added is in a first empty phase and therefore presents itself in the same way as the first chain illustrated in FIG. 6.
  • the analysis of the EIT table is carried out 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 created. This list is only used during the cache building phase.
  • FIG. 10 represents a linked list of services 11 to 14.
  • Each service contains information relating to the number of events that have been added to this service and to the size of 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.
  • the cache can then format the data in order to "hide” them definitively. This is done by calling a data formatting function called "fitChannel".
  • fitChannel a data formatting function
  • the number of events is used to calculate the size of the table of pointers referencing the formatted events.
  • the cumulative size of the information on the events allows the necessary and sufficient allocation of memory for the copying of the linked list.
  • the compact area of allocated memory will then contain the events put together. For a chain composed of N events whose cumulative size is K bytes, the following allocations will be made:
  • K is an integer representing the sum of the number of bytes of information relating to each event.
  • FIG. 11 A diagram for a chain for example 14 broadcasting 4 events is represented in FIG. 11.
  • an empty table 8 '4 is reserved in the memory containing just the memory space necessary for the storage of the four pointers and a compact empty area 2 "4 just large enough to contain the number k of bytes representing the sum of the quantities of information in bytes contained in the description of the 4 events.
  • FIG. 12 We then proceed as shown in FIG. 12, for example for the service 14 to the copying of events from the temporary linked list to zone 2 "4 compact and continuous from memory.
  • This area when filled is referenced 24. It contains information on the first 4 th string event. This information is stored in adjacent areas of the compact area 24, 241, 242 ....
  • the table 8'4 of pointers is filled since we know the address of the start of each event and takes the reference 84. To this stage 2 '4 chained list of events is always present. This linked list, which was used to build the cache, is then erased, freeing up the corresponding memory space, so that the chain structure and associated events takes the final appearance shown in Figure 13. This aspect corresponds to that of Figure 5 already described.
  • a Mediahighway type memory was used. 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 handling 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 supplied with the memory by a process known as waste recovery
  • a static part is a conventional memory which is used via pointers).
  • the SI data cache uses dynamic and static memory. This dual use guarantees a minimum of fragmentation and reduced memory consumption.
  • a pointer in a dynamic memory data zone is a handle, that is to say, as explained above, a double pointer. It therefore consumes double in memory than its equivalent consisting of a simple pointer, in static memory (8 bytes instead of 4). So the more pointers there are, the better it is to use static memory.
  • small data ⁇ 40 bytes
  • large data packets > lKo
  • the lists 11 with linked services defined above are found in an area 10 of dynamic memory. Indeed the string element consumes only few bytes. In addition, from one construction of the cache to another, the number of chains can vary.
  • a use of dynamic memory avoids the fragmentation of the static part of the memory.
  • the lists represented by way of example 2'n at 2 '15 and 2' nor at 2'n7 linked of events which, as we recall, are an intermediate tool for constructing static memory, are found in dynamic memory area 10. Since it is temporary, once erased the recovery of waste "garbage collecting" guarantees defragmentation. of all dynamic memory previously used.
  • the compact zones 2 (21, 2n) of events are in a part 100 of the memory corresponding to static memory since these zones are often of large size and can remain stable for durations of the order of 48 hours.
  • each event is referenced by a pointer and not a handle. The saving of 4 bytes per event is significant.
  • Tables 81 to 8n of event pointers are also found in part 100 corresponding to static memory. Insofar as an empty array 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.
  • the cache After erasing the linked lists 2'1 to 2'n the cache has the appearance shown in Figure 16 where part 10 of dynamic memory contains only the linked list of services 11 to In.
  • Tables 8 of pointers and compact areas 2 are in area 100 of static memory while the linked list 1 of services is in part 10 of dynamic memory.
  • protection against memory saturation is provided. Because of its fully dynamic model, the SI data cache can, if too much information is broadcast, saturate the memory of the decoder or the "Set Top Box". Also, in order to protect against this phenomenon, a system of terminals makes it possible to limit the number of hidden elements.
  • the terminals are configurable when the cache is initialized.
  • the possible limits are as follows:
  • This terminal system makes it possible to evaluate the size of the cache once it is constituted. Take for example a string element therefore stored in the dynamic memory part, whose data has a size of N bytes. The size of the data in this string element is therefore N + 2 * 8 bytes (+ 2 * 8 for the two handles which ensure double chaining), ie N + 16.
  • the events have an average size of M bytes. For each event, you must count its associated pointer, so you have M + 4 bytes per event.
  • Cache Size (NbMaxChains * (N + 16) + NbMaxChannels * NbMaxEvtParChaine * (M + 4)) / 1024 kilobytes.
  • Quantified example 200 channels, 80 events per channel, (3 days of program on average) with 20 bytes for chained data of a string and an average of 140 bytes for an event.
  • the cache does not need to be complete, even partially filled, it can be consulted by applications. However, at least one channel must have been formatted before there can be a consultation. Access to the data is carried out by means of iterators. There are two types of iterators:
  • the chain iterator browses ("browse") the doubly linked list found in the dynamic memory section described above. Because of its double chaining back and front movements are simple and fast.
  • the "read and go to next" (readAndGoNext) and “read and go to previous” (readAndGoPrevious) functions allow you to retrieve information on each of the strings browsed. The information is included in an object of the string class. Many functions are also available, such as searching for a channel, positioning a magnifying glass mode.
  • the event iterator allows, as
  • the event iterator associated with a chain makes it possible to browse (“browser”) the events associated with a chain. This type of iterator is used in particular in the construction of program grids.
  • the iterator of events sorted by genre allows, as its name suggests, to sort the events on a very specific criterion that the sorted events meet.
  • Such iterators are used for example to build lists sorted by genre such as all of the films or all of the sporting events, etc.
  • event pointers are memorized in an array of annex pointers.
  • This table is constructed in two stages as shown schematically in figure 17.
  • the set of compact event zones 2 of the set of chains is scanned and analyzed. If the event fulfills the filtering condition, it is marked by a flag ('' tagged '') then a counter is incremented.
  • the marking of the event is represented in FIG. 17 by a first arrow f directed towards an event in zone 2.
  • the first zone 21 of event comprises two films
  • the compact zones 22, 23, 24 , 25, 26, 210, 211 comprise a single film
  • the compact zones 27, 28, 29 do not contain the event sought.
  • the memory consultation module includes a function for verifying the relevance of the data browsed so as to ensure that the information is up to date when it is consulted. This function will be described below.
  • SI data is said to be “relevant” if it is identical in the memory cache or in the MPEG broadcast stream.
  • the SI data cache is relevant if it accurately reflects the data disseminated as a whole. It must therefore be able to detect dynamic updates made on the flow (see The EIT acquisition engine)
  • the chain stores a signature.
  • This signature is delivered by a signature server. This server guarantees never to give two identical signatures after each construction of the same chain.
  • Each instance of the chain class copies this signature into its internal data.
  • the signatures are compared. If they are identical, the data in the chain is relevant and can be browsed. Otherwise, an exception is thrown telling the application that the string object it uses is out of date. The application should therefore request a new instance of the chain class or request an update of its object.
  • each iterator is validated by a boolean. Whenever the database is modified, however small, this Boolean in the form of a flag is positioned at a "false" invalidation position 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. The application should therefore request a new iterator instance or request an update of it. The update requests are sent by the consultation module to the engine module.
  • the cache according to the invention exploits the static and dynamic parts of the memory.
  • SI data coexists with data linked to basic system operations (virtual machine operation, class loading, etc.).
  • static memory becomes fragmented. This is inevitable because the exploitation of the cache allows the partial erasure see total of the SI data.
  • the memory manager does not perform any defragmentation operation on the static part of the memory. This problem of fragmentation of the static area can lead to the impossibility of loading new strings into memory although the space exists physically.
  • a specific memory area is defined for the data cache SI. Only in this space, the SI cache can assess its degree of fragmentation at any time. Similarly, it can reorder SI data blocks and defragment its memory when the system allows it: standby or system not active for a certain time. This mechanism is similar in all respects to the management of the defragmentation of a hard disk on PC.
  • the method for constructing the database relating to the information on the programs and the method for consulting this database are in the form of software installed in the memory of a device, 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 downloading.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Procédé de construction d'une base de données relative à des informations sur des services et évènements diffusés sur un flux de données, par exemple MPEG, caractérisé en ce qu'on calcule exactement la place mémoire nécessaire au stockage de ces données et qu'on réalise une allocation exacte de place mémoire. On gagne ainsi de la place mémoire et on facilite la consultation de la base de données.

Description

PROCEDE DE FORMATION ET D'UTILISATION D'UNE BASE DE
DONNEES D'EVENEMENTS.
DESCRIPTION
Domaine technique
L'invention se situe dans le domaine du recueil et de l'exploitation de données numériques relatives à des événements de chaînes ou services de télévisions. Elle concerne plus particulièrement un procédé utilisé pour construire une base de données sur de tels événements ainsi que l'emploi de la base de données ainsi construite. ~
Description de l'arrière plan technologique
Les fournisseurs ou diffuseurs de service (c'est-à-dire d'émissions) de télévision ou radio diffusent des tables de données relatives aux événements qui peuvent être captées par un utilisateur d'un appareil de réception de ces événements, par exemple un récepteur de télévision muni d'un décodeur numérique ou d'un décodeur numérique alimentant un récepteur de télévision. Avant de décrire d'avantage l'art antérieur il convient de faire quelques rappels sur le vocabulaire et le genre de normes qu'il est préférable de connaître pour bien comprendre' ce qui sera expliqué ensuite.
Les diffuseurs de services par exemple les diffuseurs d'émissions de télévision diffusent non seulement des événements ou encore programmes de télévisions, tels que des films, des matchs, des émissions de variété, mais aussi d'autres informations notamment sur les programmes prévus d'émissions, en principe selon un standard préétabli. Par exemple en Europe la norme DNB-SI ETS 300 468 et le rapport technique ETR 211, prévoient un format pour des tables d'information sur les événements, (event information tables, EIT) . Dans les explications qui vont suivre, les exemples seront, pour fixer les idées, tirés de cette norme. De même, le vocabulaire employé aura la définition prévue par cette norme et ce rapport. Il est cependant évident que l'invention n'est pas dédiée uniquement à une application utilisant cette norme.
Dans la suite de la description on s'intéressera aux EIT dites "schedule" c'est-à-dire relatives aux programmes . Ces tables EIT programmes permettent de décrire jusqu'à 31 jours de programme pour un service. Les informations spécifiques à un programme sont par exemple son titre, la durée de celui-ci, son genre etc.
Les données SI permettent de réaliser des applications de type Guide Electronique de Programme. La norme DNB-SI ETS 300 468 définit des informations hors descripteur, des informations facultatives associées aux descripteurs et des informations privées contenues dans des descripteurs privés . Les descripteurs sont des informations de longueur variables telles que par exemple un titre de film ou d'émission ou encore un résumé décrivant le programme. Des informations hors descripteur sont présentes pour chaque événement. Quelques exemples en sont donnés ci- dessous. Event Id : Identifiant unique d'un événement pour un service ayant une identification "service Id" donnée (une chaîne) .
StartTime : Instant de début de diffusion de l'événement (format UTC GMT).
Duration : Durée de l'événement. FreeCaMode : Critère d'accès à l'événement. Des exemples d'informations facultatives associées aux descripteurs DNB-SI sont citées ci- dessous : short_event_descriptor : Titre et résumé de 1 ' événement . content_descriptor : ce descripteur correspond à une classification de l'événement. Enfin des informations associées aux descripteurs sont privés c'est à dire spécifiques d'un diffuseur.
A titre d'exemple, un descripteur spécifique au contrôle d'accès peut être utilisé pour décrire des événements couramment appelé PPN (pay per view) , exigeant, pour être vu, un paiement de l'utilisateur
Des informations plus complètes sur les descripteurs de tables EIT figurent au paragraphe 4.2.4 du rapport ETSI ETR 211. Les informations EIT "schedule" relatives aux programmes d'un même diffuseur peuvent être envoyées par exemple, sur le flux MPEG-2 sur une ou plusieurs tables ou sous tables chacune de ces tables ou sous' tables ayant un identifiant de table "table id" (Tid) en fenêtres fixes ou glissantes. En fenêtre glissante les données transmises sur la première des tables identifiée par son Tid correspondent au jour courant.
En fenêtre fixe les données transmises sur la première des tables identifiée par son Tid correspondent au premier jour du mois.
La norme DNB-SI recommande que les événements soient transmis dans l'ordre chronologique. Les tables des différents diffuseurs sont diffusées périodiquement, avec des fréquences de répétition dont les minima sont fixés au paragraphe 4.4 de la norme ETR 211. Elle recommande également que la description des événements soit organisée en sections comportant chacune un maximum de 4096 octets avec au minimum une section par période de trois heures de programme. Huit sections forment un segment. Une sous table ne comporte pas plus de 32 segments, soit 256 sections au total.
On entend par application un logiciel permettant d'exécuter des fonctions, par exemple de recherche et de présentation d'informations. Les applications de guide de programme (connues aussi sous le nom d'EPG pour Electronic Program Guide) sont installées sur des décodeurs qui disposent de peu de mémoire. Aussi il n'est pas possible de récupérer l'ensemble des informations d'un seul coup et de les mémoriser avant de les parcourir. La solution de saisie au vol (catch on the fly) est alors retenue. Cette solution consiste à ne récupérer sur le flux de données diffusées que l'information nécessaire pour une application donnée, en fonction de l'application et des paramètres de cette application. Par exemple si un spectateur souhaite savoir ce qui sera diffusé le jour courant sur une chaîne, à partir de 20 heures, seules ces informations seront recherchées sur le flux, mémorisées et exploitées pour être présentées de façon ordonnée et compréhensible pour le spectateur. De ce fait la quantité de mémoire utilisée est réduite. En revanche, le temps d'accès à de nouvelles informations est long puisqu'il faut attendre que les informations recherchées soient diffusées, recueillies et traitées. L'exploitation des requêtes du spectateur est alors très ralentie. Ce choix a également amené à ne pas utiliser les tables définies par la normes DNB-SI mais des tables privées plus légères que les "EIT schedule" .
On voit maintenant apparaître des décodeurs appelés aussi "set top box, STB) " dotés d'une mémoire limitée, par exemple 8 Mega-octets et il devient possible de mémoriser des données relatives aux programmes et de les exploiter pour délivrer rapidement les informations souhaitées, par exemple par un téléspectateur .
Brève description de l'invention.
On constate que malgré la présence d'une capacité mémoire non négligeable, cette capacité est encore largement insuffisante pour stocker toutes les tables d'information sur les événements et que par conséquent il importe de sélectionner les informations que l'on va mémoriser, et de les organiser pour occuper au mieux la place mémoire disponible. L'invention vise donc un procédé de recueil, dans une mémoire, d'informations relatives aux programmes qui permette une utilisation optimale d'une capacité de cette mémoire de recueil. Elle vise à permettre le recueil de ces données en parallèle. Elle vise aussi à organiser cette mémoire en base de données qui soit d'un accès rapide et facile. On veut dire par là que la présentation au spectateur des données les plus couramment recherchées ne nécessite que peu d'instructions, ceci en raison de la façon dont la base est organisée. Dans un mode préféré de réalisation, le procédé selon l'invention permet d'une part de détecter très rapidement qu'une information stockée en mémoire n'est pas à jour et d'autre part de la corriger.
A toutes ces fins, l'invention est relative à un procédé de construction d'une base de données relative à des information d'événements diffusées périodiquement sous forme d'un flux de données par un ou plusieurs fournisseurs de services dans lequel : a) on constitue un fichier de différents services identifiés susceptibles de diffuser des informations d' événement , b) on extrait et on stocke temporairement une partie au moins d'une série d'informations sur les événements diffusés par chaque service, c) on sélectionne pour chaque événement les informations que l'on souhaite stocker pour une longue durée, d) on détermine le nombre d'octets contenus dans les informations sélectionnées pour chaque événement ainsi que la somme de ces quantités d'informations pour l'ensemble des événements de chaque service, e) on recherche une zone d'adresses mémoire de taille suffisante pour y stocker de façon non fragmentée toutes les informations sélectionnées relatives à tous les événements d'un premier service les uns à la suite des autres, f) on recopie dans les zones d'adresses non fragmentées trouvées à l'étape e) chacun des événements du premier service les uns à la suite des autres, g) on complète le fichier des services par l'adjonction, dans une fiche de ce fichier correspondant audit premier service d'un pointeur donnant l'adresse du premier événement de ce service, h) on recommence les étapes d) à g) pour chacun des services du fichier des services, i) on efface de la mémoire les informations extraites à 1 ' étape b) .
De préférence, on complète l'étape d) en tenant un compte du nombre d'événements pour définir la piace mémoire nécessaire à la création d'un tableau de pointeurs donnant chacun l'adresse du début d'un événement de ce service, on complète l'étape e) en recherchant également un autre groupe d'adresses mémoire pour y loger le tableau de pointeurs dont chaque pointeur donne l'adresse du début d'un événement, et enfin lors de l'étape f) on inscrit dans le tableau des pointeurs, pour chaque événement, l'adresse du début des informations relatives à cet événement .
Lorsque les opérations a) à i) ci-dessus décrites sont terminées, on dispose en mémoire de l'information utile à un téléspectateur pour connaître par service les événements auxquels il peut avoir accès, et sélectionner ceux qui l'intéressent. Il sera vu plus loin qu'il lui est possible aussi de réaliser facilement une sélection parmi des événements de plusieurs services, ces événements ayant une qualité commune identifiable au moyen des informations sur les événements, par exemple une information par genre d'événement, films, sports, variétés.
La place occupée par les informations sélectionnées est minimum puisque l'on a ôté des informations reçues toutes les informations non directement utiles au téléspectateur ou à une application pour faire des recherches ou des sélections parmi les événements . En addition aux informations propres aux événements on utilise pour l'exploitation de ces informations uniquement les pointeurs à raison de un pointeur par événement.
On remarque que, par exemple en environnement JAVA on a une paire de poignées, correspondant l'une à une adresse logique et l'autre à l'adresse physique. Selon l'invention on a une seule adresse ou pointeur par service ou dans le cas où 1 ' on a créé un tableau de pointeurs par événement, une seule adresse ou pointeur par événement . Les avantages de ce tableau de pointeurs, consommateur d'un peu de mémoire apparaîtront plus tard, lors de la description d'un mode d'utilisation de la mémoire. On gagne donc aussi la place mémoire correspondant dans le cas le plus défavorable à une adresse par événement.
On remarque aussi que les opérations a) à i) peuvent être exécutées de façon différente sans que le résultat final soit changé. Ainsi par exemple on peut ne recueillir que les informations sur les événements relatives à un seul service, traiter ces informations selon les étapes a) à i) à l'exception de l'étape h), puis recommencer le même traitement pour chacun des autres services. L'avantage de cette dernière solution est que le volume instantané de mémoire nécessaire est moindre, ce qui peut être utile. L'inconvénient de cette dernière façon de faire est que l'on ne dispose pas dès le départ de l'information quant à tout le volume nécessaire au stockage des informations. De préférence les fiches individuelles relatives à chaque service sont chaînées, cela veut dire que chaque fiche contient un pointeur donnant l'adresse d'un service suivant, une dernière fiche ayant un pointeur donnant l'adresse d'une première fiche. Dans le mode préféré de réalisation les fiches individuelles relatives à chaque service sont doublement chaînées . Cela veut dire que chaque fiche contient en outre un pointeur donnant 1 ' adresse -d'un service précédant une première fiche ayant un pointeur donnant l'adresse d'une dernière fiche. De la sorte on peut parcourir la liste des services dans un sens croissant ou décroissant.
Ainsi dans le mode préféré de réalisation chaque fiche de serveur contient trois pointeurs, un pointeur donnant l'adresse du premier événement du service, un pointeur donnant l'adresse du début de la fiche du service suivant et un pointeur donnant l'adresse du début de la fiche du service précédant.
Dans un mode avantageux de réalisation, on simplifie la mise à jour des données de la façon suivante. Tout d'abord il est nécessaire, pour ce mode de réalisation que le ou les fournisseurs de service, ou au moins certains d'entre eux, diffusent une table* de mise à jour. Cette table, outre des données d'identification, contient essentiellement des indicateurs relatifs à des numéros de version du service et de chaque événement. Pour distinguer l'un de l'autre ces numéros de version, les numéros de version du service sont appelés "compteur de version du service" ou "compteur de version" et le numéro de version de l'événement est appelé numéro de version. Evidemment, lorsque les informations sur un événement changent, le numéro de version de l'événement change et aussi en conséquence le compteur de version du service. La comparaison du compteur de version de service actuellement diffusé avec un compteur de version de service précédemment stocké permet de savoir s'il est nécessaire ou non de faire un nouvel enregistrement de données de ce service. Avec le numéro de version de l'événement on sait quelle ou quelles données d'événement ont changé. On évite ainsi de repeigner systématiquement toutes les données . La table privée de mise à jour peut aussi contenir un drapeau de mise à jour générale indiquant qu'un grand nombre de données ont changé, d'où suit un réenregistrement des données de ce service.
Brève description des dessins
L'invention sera maintenant décrite en regard des schémas annexés destinés à illustrer et faciliter la compréhension du procédé selon l'invention et de variantes de réalisation. Dans ces schémas la figure 1 représente une partie d'une base de données constituée selon l'invention, la figure 2 représente la constitution d'une zone compacte d'événements d'une base de données constituée selon l'invention, la figure 3 représente une autre partie d'une base de données constituée selon l'invention, la figure 4 représente une zone compacte et un tableau associé d'une base de données constituée selon 1' invention, la figure 5 illustre l'organisation d'un service dans une base de données constituée selon 1' invention, les figures 6 et 7 illustrent des étapes de la constitution d'un fichier des services les figures 8 et 9 illustrent des étapes de la constitution d'une liste chaînée d'événements la figure 10 illustre des étapes de la constitution d'une succession de listes chaînées d'événements *— les figures 11 à 13 illustrent des étapes de la constitution d'une zone compacte d'événements et d'un tableau de pointeurs associés et l'aspect final de cette zone et des liens associés, les figures 14 à 16 illustrent des étapes de la constitution d'une succession de zones compactes d'événements et de tableaux de pointeurs associés et l'aspect final de cette succession de zones et des liens associés, les figures 17 et 18 illustrent des étapes de la constitution d'un tableau de pointeurs pour une consultation sur critères déterminés et l'aspect final de ce tableau et de ses liens avec les événements sélectionnés .
Dans les figures les mêmes éléments portent le même numéro de référence éventuellement associé avec un indice prime ou seconde s'il s'agit du même élément dans une phase de construction. Description d'un mode de réalisation de l'invention.
Un exemple de système destiné à réaliser le procédé selon l'invention va être maintenant décrit. Le système qui va être décrit est composé de quatre modules distincts :
Un moteur d'acquisition de tables d'informations sur les événements SI (EIT schedule)
- un module analyseur de tables (EIT)
- un module gestionnaire de mémoire - un module de consultation de mémoire
La fonction de chacun de ces modules en relation avec les autres modules sera tout d'abord décrite puis chacun des modules sera décrit de façon plus détaillée. Le module moteur d'acquisition de table SI (EIT schedule). fait l'acquisition des EITs de l'ensemble des services afin que les données soient disponibles auprès des applications le plus rapidement possible. Pour ce faire le chargement en parallèle est privilégié.
Le module analyseur de table est chargé de parcourir les tables EITs et d'en extraire les données pertinentes qui sont formatées pour être stockées en mémoire . Le module de gestion de mémoire est chargé de la gestion du stockage des unités élémentaires représentant un programme ainsi que de l'organisation de la mémoire.
Le module de consultation de mémoire est chargé de donner aux applications une bibliothèque de fonctions destinées à parcourir la base de données d'événements et d'établir des listes triées suivant certains critères .
La mise en œuvre de ces quatre éléments au sein d'un décodeur ou "set top box" permet d'avoir un outil complet garantissant l'accès à l'ensemble des informations SI d'un bouquet tout en reposant sur le standard DNB-SI . Chacun de ces quatre éléments sera examiné plus en détail ci-après.
Le module moteur d'acquisition des tables EIT gère l'acquisition sur le flux des tables EIT "Schedule", leur analyse (via l'analyseur), et leur stockage en mémoire via le gestionnaire de mémoire. Ce moteur gère également, selon une caractéristique avantageuse de l'invention, la mise à jour des informations contenues dans la mémoire lorsque des modifications à ces informations ou de nouveaux événements sont transmis sur le flux.
Les tables EIT "Schedule" peuvent représenter un débit important de données en fonction du nombre d'événements et du nombre de services présents. Il s'ensuit que, surveiller en permanence l'ensemble des tables EIT pour détecter des évolutions, représente un temps relativement long.
Pour raccourcir le temps de détection avantageusement, l'acquisition des données des tables EIT Schedule est basée sur l'utilisation d'une table privée intitulée GUT (Guide Update Table) . Cette table est établie essentiellement à partir ..des tables de description de service (SDT) . Ces tables donnent pour chaque service présent sur un flux de transport des informations générales sur le service, en particulier une identification du service et un numéro de version (version number) sur 5 bits qui est augmenté de 1 chaque fois qu'il y a une modification dans une sous table représentant un service. Elle est complétée ensuite par un compteur de version (service counter) qui est modifié chaque fois qu'il est détecté que les informations relatives à un événement ont été changée. Ce compteur de version est tiré d'une table d'information sur les événements (EIT) qui comporte un numéro de version sur 5 bits (version number) , qui est incrémenté de 1 lorsque les informations relatives à un événement ont été changées .
En conséquence, la table GUT contient la liste de tous les services contenant des événements présents sur le flux de transport des tables de données (transport streams) . Ces services contenant des événements sont identifiés par leurs identifications de service (service_id) . Cette table GUT permet de surveiller les évolutions de l'ensemble des événements présents sur le flux de transport en ne surveillant que cette seule table. A chaque service présent dans la table GUT est associé, comme indiqué ci-dessus, un compteur de version du service (service_counter) , un numéro de version (version_number) , ainsi qu'un drapeau de mise à jour général (full_update_counter) . Lorsque les événements d'un service donné sont modifiés sur le flux, il y a changement du compteur de version (service_counter) du service correspondant et du numéro de version (version_number) de la table GUT.
Lorsque des services contenant des événements sont ajoutés sur le flux, ils sont ajoutés dans la table GUT et le numéro de version (version_number) de la table GUT est changé. Les services retirés du flux de transport ne disparaissent de la table GUT que lors d'une mise à jour générale de cette table, (modification du drapeau de mise à jour générale "full_update_counter" ) . Lorsque l'ensemble (ou une grande partie) des services sont modifiés, il est préférable d'indiquer ce changement par une modification de la valeur du "full_update_counter" (bien qu'il soit possible de ne modifier que le numéro de version de la table (version_number) , ceci pour des raisons de performances .
Afin d'optimiser le temps de chargement des données des tables d'informations sur les services (EIT) présentes sur le flux, plusieurs requêtes de tables EIT sont gérées en parallèle. On distingue le nombre de requêtes utilisées pour une acquisition complète des données présentes sur le flux lors d'un premier chargement ou après modification du drapeau de mise à jour général (full_update_counter) du nombre de requêtes utilisées pour des mises à jour partielles des données de la mémoire. L'application fixera ces valeurs au moteur d'acquisition de données.
La machine d'état du module moteur d'acquisition de données est séquencée par des pilotes de démultiplexeurs.
Le fonctionnement général est géré par deux drapeaux internes : un drapeau commun sur le type d'acquisition, intitulé "EngineMode" et un drapeau pour- chaque instance de filtre, intitulé EngineState. Le drapeau commun sur le type d'acquisition, intitulé "EngineMode" a un état initial appelé "engineModelnit" : "engineModelnit" correspond à la 8
16
première acquisition après l'initialisation. Un autre état "engineModeBuild" correspond à un chargement complet de la mémoire suite à une modification complète de la diffusion des tables EITs, détectée par une nouvelle valeur du drapeau de mise à jour générale "full_update_counter" dans la table privée GUT sur le flux par le fournisseur du service. Un autre état de ce drapeau intitulé "engineModeUpdate" correspond à une mise à jour de la mémoire suite à une modification des données de certains services, cette modification étant détectée par un nouveau numéro de version
(version_number) de la table GUT alors que le drapeau de mise à jour générale (full_update_counter) ne change pas de valeur et par des nouvelles valeurs de compteur -de service "service_counter" aux niveaux de descripteurs de service "service_descriptors" contenus dans la table privée GUT transmise sur le flux.
Le drapeau pour chaque instance de filtre, intitulé "EngineState" a un état initial appelé "engineState nit" : "engineStatelnit " correspond à un état initial précédant la pose d'une requête de filtrage. Un état "engineStatelnAcq" de ce drapeau correspond à la réception d'un événement suite à une requête de filtrage. Un état "engineStateRetry" de ce drapeau correspond à un traitement de nouvel essais suite à un échec de chargement
Les EIT schedule peuvent être envoyées sur le flux MPEG-2 sur plusieurs tables ou sous-tables ayant des identifications de table, table id (plusieurs tables EIT pour un même service) .
Les identités, tables-id, des tables à charger dépendent du nombre de jours de données à mémoriser dans la mémoire et de la table des segments (selon qu'elle est utilisée en fenêtre fixe ou glissante).
Si les EIT doivent être récupérées sur plusieurs tables identifiées par leur identi ication de table Tid, l'ordre de chargement est : "Pour le Service__id courant : Pour le Tid courant : Chargement de l'EIT
Passage au prochain Tableld (Tid) du service courant
FinPour
Passage service suivant dans la GUT FinPour" -
Cet ordre correspond à un chargement de toutes les tables d'un service courant avant de passer au chargement du service suivant selon l'ordre définit par la table GUT.
La norme DNB-SI imposant que les événements soient transmis dans l'ordre chronologique, les événements seront mémorisés dans l'ordre chronologique dans la mémoire. Cet ordre a son importance dans la mesure où une extraction chronologique des différents événements d'une chaîne évite une étape de tri des informations. Ainsi, les événements sont dans la mémoire dans l'ordre logique de leur diffusion.
Le fonctionnement de l'ordonnanceur d'acquisition du moteur est décrit ci-dessous. Les traitements des cas d'erreur n'apparaissent pas dans cette description. 0) Initialisation du moteur d'acquisition , le drapeau commun sur le type d'acquisition est mis sur son état initial "engineModelnit". 1- Acquisition de la table guide de l'utilisateur GUT
2- Table guide GUT acquise : mémorisation du numéro de version de la table "version_number" et du drapeau de mise à jour général " full_update_counter"
3- Construction de la liste des services et mémorisation des valeurs de compteur de service "service_counter" .
Tous les services sont marqués "à acquérir. 4- Acquisition des tables d'information sur les événements EIT pour les services marqués 'à acquérir'.
Si on vient de (3), n filtres (fixé par l'application, ou 10 par défaut) sont utilisés car il s'agit d'une acquisition complète. Si on vient de (7) ou (8), (qui seront décrites ci-après) n filtres (fixé par l'application, ou 3 par défaut) sont utilisés car il s'agit d'une mise à jour.
Pour chaque table d' information sur les événements EIT, on fait jusqu'à 3 tentatives "retry" en cas d'échec de la première tentative.
L'acquisition se termine lorsque toutes les EIT ont été acquises (ou échecs après 3 tentatives "retry") pour une EIT ayant un table_id donné.
Les tables EIT d'information sur les événements EIT non acquises après 3 tentatives "retry" restent marquées "à acquérir" . Elles seront donc réacquises lors d'une prochaine version de table GUT, voir ci- dessous .
Si toutes les tables à acquérir ont été acquises, on passe en (5) décrit ci-après. Sinon retour en (4) pour l'acquisition de la table suivante et le même filtre. 5- Acquisition de la table guide d'utilisateur GUT
6- table guide d'utilisateur GUT acquise :
Si la table de mise à jour du guide GUT courante a le même numéro de version "version_number" et la même valeur de drapeau de mise à jour général "full_update_counter" qu'une table guide d'utilisateur GUT précédente, on revient en (5) après par exemple 30 secondes (sondage de la table GUT toutes les 30 secondes . )
Si la table guide d'utilisateur GUT courante a le même numéro de version "version_number" et une valeur de drapeau de mise à jour général
"full_update_counter" , différente de celui d'une table précédente on passe en (7) décrit ci-après.
Si la valeur du drapeau de mise à jour général "full_update_counter" de la table guide d'utilisateur GUT courante, est différente de celle d'une table précédente, on passe en (8) décrit plus loin. 7- On met à jour les service_counter des services .
On complète la liste des services si de nouveaux services apparaissent en fin de GUT.
Si au moins un "service_counter" est différent du précédent ou si un nouveau service est apparu dans la liste, les services correspondants sont marqués "à acquérir", et l'on revient en (4). Il est rappelé que les EIT précédemment non acquises après tentative sont déjà marquées 'à acquérir'. 8- Reconstruction de la liste des services et mémorisation des "service_counter" .
Tous les services sont marqués "à acquérir" . La mémoire EPG n'est pas réinitialisée
Retour en (3) .
On peut résumer l'organigramme qui vient d'être décrit en disant que après une étape d'initialisation : - on crée une table de suivi des mises à jour listant les services et leur associant un numéro de version de service "service_counter" et un numéro de version "version_number" des événements.
- on acquiert les tables d'information sur les événements correspondant aux services figurant dans la table de mise à jour GUT,
- on renouvelle périodiquement l'acquisition de la table de mise à jour GUT, et on compare la table courante à la table précédente, - si la table est inchangée et que tous les services ont été acquis précédemment on renouvelle l'acquisition de la table GUT jusqu'à ce que l'on remarque un changement avec la table GUT précédente,
- si la table GUT est changée ou si des tables d'information sur les événements n'ont pas été acquises on fait les acqusitions nécessaires pour compléter les informations sur les services,
- si un grand nombre de changements sont intervenus, on refait une acquisition complète de la table GUT et des tables d'information sur les événements .
Le module analyseur de table d'information sur les programmes EITs sera maintenant examiné. Ce module permet l'analyse des descripteurs contenus dans une section EIT. Le module Engine demande l'analyse section par section dans l'ordre chronologique .
Le module moteur d'acquisition Engine passe à l'analyseur une section d'EIT et reçoit en retour les informations sur les événements contenus dans cet EIT.
Trois types d'informations sont extraites pour un événement donné, les informations DNB-SI standard hors descripteur, les informations associées aux descripteurs DNB-SI et les informations associées aux descriteurs privés. les informations DNB-SI standard hors descripteur sont présentes pour chaque événement, elles sont définies par la norme DNB-SI ETS 300 468, en voici une liste pour exemple : L'Event Id : Identifiant unique d'un événement pour un service Id donné (une chaîne) .
StartTime : Date de début de diffusion de l'événement (format UTC GMT).
Duration : Durée de l'événement. FreeCaMode : Critère d'accès à l'événement.
Les informations associées aux descripteurs DNB-SI sont facultatives. Tous les descripteurs facultatifs associés à la norme DNB-SI sont supportés. On peut citer à titre d'exemple : short_event_descriptor : Titre et résumé de
1 ' événement . content_descriptor : genre de 1 ' événement .
Les informations associées aux descripteurs * privés, une fois spécifiées, n'importe quel descripteur privé peut être supporté par le module d'analyse. A titre d'exemple, un descripteur spécifique au contrôle d'accès est utilisé pour décrire des événements de type PPN (pay per view) .
Les informations extraites pour chaque événement sont regroupées dans une structure spécifique qui sert de structure d'échange avec le module chargé de la mémorisation des données. On parle alors de cellule d'échange. Chaque cellule d'échange contient l'ensemble des informations correspondant à un événement. Les cellules d'échange varient d'un projet à l'autre selon qu'elles intègrent des données associées à des descripteurs privés ou non.
Noici à titre d'exemple quelques données qui peuvent être associées et retenues pour igurer "dans une telle cellule d'échange. event_id ; /* 2 octets identité de
1 ' événement * / start_time ; /* 5 octets heure de début de 1 ' événement * / eventFlags ; /* 1 octet drapeau pour les événements payants*/ content_nibble ; /* 1 octet (4bits pour un premier niveau et 4 bits pour un second niveau) descriptif de genre 1 et 2 */ duration ; /* 3 octets durée de l'événement */
Parental_rating ; /* 1 octet code d'information pour les parents */ title_id ; /* 2 octets identité du titre */ price ; /* 4 octets indication de montant*/ evtTitleLen ; /* 2 octets longueur du titre en octets */ Certaines information ne figurent qu'à titre conditionnel, l'une des conditions étant que cette information soit contenue dans le descriptif figurant dans la table. On peut citer à titre d'exemple non limitatif ppvSession ; /* 2 octets numéro de cession */ purchase_win ; /* 1 octet fenêtre d'achat*/ evtSummaryLen ; /*longueur en octets du résumé de l'événement*/
La description du module mémoire de données (SICache) sera maintenant effectuée.
La mémoire de données SI (SICache) est chargée de stocker en mémoire les informations extraites des tables d'informations sur les événements EIT. La solution la plus simple pour stocker ces informations serait de mémoriser les sections de chaque table EIT de chaque service. Une telle solution requiert comme expliqué plus haut beaucoup de mémoire, et ne peut être mise en œuvre dans un environnement embarqué de type STB 8 Mo.
Aussi le module SICache propose une mise en mémoire de façon compacte des informations. Le principe de stockage retenu garantit la compacité des informations, donc l'allocation à l'octet près de ce qui doit être mémorisé. Afin de mettre en œuvre le principe de stockage la mise en mémoire s'effectue en trois étapes.
Avant d'exposer la dynamique de construction du cache, rapellons les différents types de données manipulées . La mémoire représente une base de données contenant des services (chaînes) , contenant elles mêmes une suite d'événements. Ces notions ont été expliquées plus haut . L'ensemble de la base de données est donc constitué d'un nombre donné de couples, informations sur les services - informations sur les événements de ces services, ou dit d'une façon abrégée couples services/listes d'événements. Un schéma succinct de ces couples, service - liste d'événements, est représenté figure 1. A chaque service numérotés lp, p allant de 1 à un nombre entier n représentant le nombre de services, 11, 12, lp In est associée une zone mémoire compacte 21, 22, 2p 2n. Chaque élément service contient trois pointeurs, deux pointeurs dont l'un donne l'adresse d'un élément service précédent et l'autre l'adresse d'un élément service suivant, afin de définir une liste doublement chaînée entre les différents services, un troisième pointeur donne l'adresse du début d'une zone de données contenant les informations propres à la description des événements de ce service. Naturellement il serait possible de n'avoir qu'un pointeur donnant l'adresse d'un service par exemple un service suivant au lieu des deux pointeurs précédent et suivant. Il sera vu plus loin que ce choix de deux pointeurs facilite le parcours des services sans consommer beaucoup de place mémoire. Outre ces trois pointeurs chaque élément service contient des informations appelées "Servicelnfo" . Un exemple d'information figurant dans Servicelnfo est donné ci-après: Onld identité initiale du réseau du service
Tsld identité du flux de transport (Transport Stream Id) du service Servld identité du service (Service
Id)
ServNum Numéro du service
ServKey Clé du service nbOfEvent Nombre d'événements que contient ce service signature Signature du service
*buildEvents Pointeur vers une liste chaînée d'événements (lors de la construction sinon null) sizeOfBuild : Taille en octets de la totalité des événements mis bout à bout.
*eventsDataBase base de données d'événements mis bout à bout
**events Tableau contenant les pointeurs vers les événements.
La structure de données correspondant à l'événement est composée de deux parties. Une partie contenant des données qui lorsqu'elles figurent sont de longueur (nombre d'octets) constante et une partie dont la longueur est variable d'un - événement à l'autre. Certaines des données de longueur constante dites à ce stade facultatives peuvent être présentes ou non. De même, les données de longueur variable peuvent être présentes ou non. Des exemples de données de longueur constante qui figurent dans tous les événements et qui pour cette raison sont dites communes à tous les événements sont données ci-après : event_id ; /* 2 octets identité de 1 ' événement */ start_time ; /* 5 octets heure de début de
1 ' événement */ eventFlags ; /* 1 octet drapeau pour les événements payants*/ content_nibble ; /* 1 octet (4bits pour un premier niveau et 4 bits pour un second niveau) descriptif de genre 1 et 2 */ duration ; /* 3 octets durée de l'événement *
Parental_rating ; /* 1 octet code d'information pour les parents */ evtTitleLen ; /* 2 octets longueur du titre en octets */ evtSummaryLen ; /*longueur en octets du résumé de l'événement. Certaines données facultatives ont une longueur constante mais ne figurent pas nécessairement.
Si par exemple un événement est de type ppv (pay per view) des données supplémentaires seront associées à cet événement telles que son prix, sa référence etc. title_id ; /* 2 octets identité du titre */ price ; /* 4 octets indication de montant*/ ppvSession ; /* 2 octets numéro de cession */ purchase_win ; /* 1 octet fenêtre d'achat. Sans surprise, on retrouve dans les exemples de données communes et de données facultatives des données déjà citées plus haut lors de la description du moteur d'extraction. Les données facultatives sont celles qui ne sont présentes sur le flux que si certaines conditions sont remplies. Le moteur d'extraction n'extrait ces données du flux que si les conditions sont remplies, ce qui fait qu'au niveau de la mémoire de données, ces données facultatives peuvent ou non être présentes.
Les données de longueur variable qui peuvent ou non être présentes sont par exemple le titre de 1 ' événement ou son résumé qui comportent un nombre variable de caractères et sont donc représentées par ce même nombre variable d'octets.
Dans le mode préféré de réalisation de l'invention chaque zone compacte 2 comporte comme représenté en figure 2 , une première sous zone compacte 3 contenant les données communes à tous les événements, cette première sous zone 3 qui groupe des données toujours présentes de longueur constante est elle même de capacité constante. Immédiatement adjacente à cette première sous zone vient une seconde sous zone 4 groupant toutes les données facultatives de longueur constante et enfin une troisième sous zone 5 immédiatement adjacente à la seconde sous zone groupant toutes les données de longueur variable.
Afin de rendre l'utilisation de la base la plus souple possible, les données de petite taille, par exemple les services nécessitant une capacité de 20 octets environ, sont chaînées les unes aux autres et les données de plus grandes taille par exemple celles relative aux événements dont la taille est souvent supérieure à 120 octets sont stockées de façon compacte, c'est à dire dans une zone mémoire continue. Les éléments service sont doublements chaînés les uns aux autres. Ce double chaînage assure une navigation plus rapide entre les différents services . Une représentation schématique de ce double chaînage est représentée figure 3 pour un nombre n égal à 4. Chaque service 11, 12, 13, In = 14 est lié par deux pointeurs matérialisés par des flèches 6 et 7 au service suivant et au service précédent respectivement. Sur la figure 3 chaque flèche 6 est référencée par le numéro 6 suivi du numéro du service suivant, ainsi la flèche 612 symbolise le pointeur du service 11 désignant le service 12, et le dernier service 14 ayant un pointeur 611 désignant le premier service ll*τ De même chaque flèche 7 est référencée par le numéro 7 suivi du numéro du service précédant, ainsi la flèche 713 symbolise le pointeur du service 14 désignant le service 13, et le premier service ayant un pointeur 714 désignant le dernier service 14.
Les éléments événement sont de grande taille (>120 octets) . Aussi afin de ne pas fragmenter la mémoire, il sont chaînés ou rangés bout à bout dans une zone mémoire qui leur a, tout spécialement, été allouée. Pour garder l'information de pointage de chaque événement, des pointeurs les référençant sont également mémorisés dans un tableau adjacent. Un tel tableau 8 est représenté figure 4 avec la zone compacte mémoire événement 2 qui lui est associée. Sur la figure 4 le tableau a été référencé 8p et la zone compacte mémoire 2 a été référencé 2p pour marquer qu'il y a un tableau 8p associé à chaque zone compacte 2p. Si la zone compacte 2p représentée figure 4 contient des informations sur 5 événements 2pl, 2p2 , 2p3 2p5, le tableau 8 contient autant de pointeurs que la zone 2 contient d'événements, dans le cas représenté 5 référencés 8pl à 8p5 pointant vers le début de chaque événement 2pl à 2p5 du service 2p. Ce tableau de pointeurs permet l'accès direct aux différents événements du service 2p. Il y a une correspondance bi- univoque entre chaque pointeur 8pi du tableau 8p et l'adresse du début d'un événement. Par exemple le pointeur numéro 8p5 du tableau 8p pointe vers le cinquième événement 2p5 du service 2p associé à ce tableau 8p. Il est également créé un lien entres les éléments service et les éléments événement. Ce lien est schématisé figure 5 par deux pointeurs, un pointeur- 9pl pointant du service lp vers le début de la zone mémoire 2p et un pointeur 9p2 pointant vers le début de la zone mémoire 8p contenant le tableau de pointeurs 8pl à 8p5. A chaque élément de type service lp, correspond une zone mémoire compacte 2p contenant les événements 2pl à 2p5 et un tableau 8p de pointeurs 8pl à 8p5 pointant chacun des événements 2pl à2p5. Il n'est pas réservé de la mémoire en prévoyant le pire. On alloue à l'octet près la mémoire dont on a besoin. De plus les structures sont suffisamment accessibles pour consultation, puisque le but du cache est de restituer les informations le plus rapidement possible.
La construction s'opère donc en trois temps.
Une chaîne ou un service est repéré par son triplet DNB . Ce triplet est constitué par l'identification du réseau initial sur lequel la chaîne est diffusée "network Id" , l'identification du flux de transport utilisé par le service "stream Id" et l'identification du service "service Id" . Une fois le cache initialisé, une chaîne peut être ajoutée dans le cache. Les paramètres à donner au moteur d'acquisition de tables sont l'original "network Id" , le "transport stream Id", et le "service Id" . Plusieurs chaînes peuvent être créées en même temps . Comme représenté figure 6 une première chaîne 11 est créée. Cette chaîne 11 ne contient, à ce stade, aucun événement et la taille des événements est nulle. Les pointeurs 911 et 912 sont vides. Le chargement des tables EIT sur le flux s'effectue en parallèle. Aussi le cache donne la possibilité de construire plusieurs services en même temps . La construction suit alors le même modèle que le chargement des données: le parallélisme. Comme représenté sur la figure 7 des chaînes 12, 13 peuvent être ajoutées à la première 11, chacune des chaînes 12, 13 ajoutées est dans une première phase vide et se présente donc de la même façon que la première chaîne illustrée figure 6. Lorsqu'une table EIT est reçue et que son analyse est en cours, les informations correspondant aux événements sont extraites et insérées dans le cache. L'analyse de la table EIT n'est réalisée qu'une seule fois. L'application SICache ne connaît pas à l'avance la quantité de mémoire qu'il lui faut allouer pour recevoir les informations des événements. De ce fait, une liste chaînée d'événements est réalisée. Cette liste sert uniquement pendant la phase de construction du cache. Lorsque tous les événements auront été ajoutés, son contenu sera recopié dans une zone mémoire compacte 2p comme expliqué plus haut puis la liste chaînée d'événements disparaîtra. Des événements peuvent être ajoutés à une chaîne. A chaque ajout d'événement la taille en octets de celui-ci est calculée et un cumul des tailles d'événements permet de savoir quelle quantité de mémoire il faudra allouer lorsque le dernier événement sera inséré. L'ajout d'un événement à une chaîne est représenté figure 8. Les informations sur le premier événement par exemple du service 13 sont insérées dans un élément 2 '31 d'une liste chaînée temporaire 2 '3, l'élément service 13 reçoit l'information relative au nombre cumulé d'événements et à la taille de chaque événement. La liste chaînée des événements du service par exemple 13 est constituée comme représenté figure 9, par additions successives des différents événements 2 '32 et 2 '33 de la chaîne. Un calcul de la somme des tailles- est effectué. Les mêmes opérations sont effectuées pour chacune des n chaînes comme représenté figure 10. Cette figure représente une liste chaînée de services 11 à 14. Chaque service contient des informations relatives aux nombres d'événements qui ont été ajoutés dans ce service et sur la taille de la somme des informations relatives à chaque événement. Les éléments événement par exemple 2 '11, 2 '12, 2 ' 13 de la première chaîne 2'1 sont comme ceux des autres chaînes, chaînés entre eux.
Lorsque l'ensemble des événements d'une chaîne a été extrait de la table EIT correspondant à cette chaîne et simultanément inséré dans la liste chaînée servant à la construction, le cache peut alors formater les données afin de les "cacher" définitivement. Cette opération est réalisée sur appel d'une fonction de formatage des données appelée "fitChannel" . A la fin de la phase de construction, pour chaque service on est en possession des informations suivantes : le nombre d'événements composant le service la taille cumulée de l'ensemble des événements.
Le nombre d'événements sert à calculer la taille du tableau de pointeurs référençant les événements formatés. La taille cumulée des informations sur les événements permet l'allocation nécessaire et suffisante de mémoire pour la recopie de la liste chaînée. La zone compacte de mémoire allouée contiendra alors les événements mis bout à bout. Pour une chaîne composée de N événements dont la taille cumulée est K octets on réalisera les allocations suivantes :
N x 4 pour le tableau de pointeurs- (1 pointeur = 4 octets) K octets pour la zone compacte et continue de mémoire. K est un nombre entier représentant la somme du nombre d'octets des informations relatives à chaque événement .
Un schéma pour une chaîne par exemple 14 diffusant 4 événements est représenté figure 11. A ce stade de la création du cache il est réservé dans la mémoire un tableau vide 8 '4 contenant juste l'espace mémoire nécessaire au stockage des quatre pointeurs et une zone vide compacte 2 "4 juste assez grande pour contenir le nombre k d'octets représentant la somme des quantités d'information en octets contenues dans le descriptif des 4 événements . On procède ensuite comme représenté figure 12, par exemple pour le service 14 à la recopie des événements de la liste chaînée temporaire vers la zone 2 "4 compacte et continue de mémoire. Cette zone lorsqu'elle est remplie est référencée 24. Elle comporte les informations sur les premiers à 4eme événement de la chaîne. Ces informations sont stockées dans des zones adjacentes de la zone compacte 24, 241, 242.... Le tableau 8'4 de pointeurs est rempli puisqu'on connaît l'adresse du début de chaque événement et prend la référence 84. A ce stade la liste 2 '4 chaînée d'événements est toujours présente. Cette liste chaînée, qui a servi à la construction du cache, est ensuite effacée, libérant la place mémoire correspondante, en sorte que la structure chaîne et événements associés prend l'aspect final représenté figure 13. Cet aspect correspond à celui de la figure 5 déjà décrite.
A titre d'exemple non limitatif, l'aspect matériel de la mémoire utilisée sera maintenant commenté. Il a été utilisé une mémoire de type Mediahighway irai. Cette mémoire est divisée en trois parties :
Une partie réservée à des poignées de manipulation, cette partie permet d'associer à chaque adresse logique une adresse physique dans la mémoire.
Cette partie de la mémoire est réservée à la manipulation des objets.
Une partie dynamique, il s'agit d'une partie de la mémoire dans laquelle les objets sont utilisés via les poignées. Cette partie de la mémoire est défragmentée par un logiciel fourni avec la mémoire par un processus dit de récupération des gaspillages
(garbage collecting) .
Une partie statique, cette partie est une mémoire conventionnelle que l'on utilise via des pointeurs) . Le cache de données SI utilise la mémoire dynamique et statique. Cette double utilisation permet de garantir un minimum de fragmentation et une consommation réduite de mémoire. Par définition un pointeur dans une zone de données mémoire dynamique est une poignée, c'est à dire comme expliqué plus haut un double pointeur. Il consomme donc le double en mémoire que son équivalent constitué d'un pointeur simple, en mémoire statique (8 octets au lieu de 4) . Donc plus il y a de pointeurs plus on a intérêt à utiliser de la mémoire statique.
De même afin de minimiser la fragmentation, il convient que les petites données (<40 octets) soient stockées dans la mémoire dynamique et que les paquets importants de données (>lKo) aillent dans la mémoire statique.
La construction du cache et la localisation des éléments dans les parties statique 100 et dynamique 10 de la mémoire sera succinctement revue ci-après en précisant à chaque fois les localisations. Sur les figures 14 à 16, les parties dynamique 10 et statique 100 de la mémoire sont séparées l'unE de l'autre par une ligne pointillée.
Comme représenté figure 14 les listes 11, à In chaînées des services définit plus haut se trouvent dans une zone 10 de mémoire dynamique. En effet l'élément chaîne ne consomme que peu d'octets. De plus, d'une construction du cache à une autre, le nombre de chaînes peut varier. Une utilisation de la mémoire dynamique évite la fragmentation de la partie statique de la mémoire. Les listes représentées à titre d'exemple 2'n à 2 ' 15 et 2 'ni à 2'n7 chaînée d'événements qui, on le rappelle sont un outil intermédiaire de construction de la mémoire statique, se trouvent en zone mémoire dynamique 10. Dans la mesure où elle est temporaire, une fois effacée la récupération de gaspillage "garbage collecting" garantit une défragmentation . de l'ensemble de la mémoire dynamique précédemment utilisée.
Après la recopie des chaînes et comme représenté figure 15 les zones 2 (21, 2n) compactes d'événements se trouvent dans une partie 100 de la mémoire correspondant à de la mémoire statique puisque ces zones sont souvent de taille importante et peuvent rester stables pendant des durées de l'ordre de 48 heures. De plus dans cette partie 100 chaque événement est référencé par un pointeur et non une poignée. L'économie de 4 octets par événement est non négligeable.
Les tableaux 81 à 8n de pointeurs d'événements se trouvent également dans la partie 100 correspondant à de la mémoire statique. Dans la mesure où un tableau vide 8" de pointeurs (non représenté vide) est alloué dans le même temps qu'une zone vide 2" compacte d'événements, peu de risques de fragmentation sont à prévoir. Après effacement des listes chaînées 2'1 à 2'n le cache présente l'aspect représenté figure 16 où la partie 10 de mémoire dynamique ne contient plus que la liste chaînée des services 11 à In. Les tableaux 8 de pointeurs et les zones compactes 2 se trouvent dans la zone 100 de mémoire statique tandis que la liste chaînée 1 des services se trouve dans la partie 10 de mémoire dynamique . Dans le mode préféré de réalisation une protection contre la saturation mémoire est prévue. Du fait de son modèle entièrement dynamique, le cache de données SI peut, si un trop grand nombre d'informations est diffusé, saturer la mémoire du décodeur ou de la "Set Top Box". Aussi, afin d'assurer une protection contre ce phénomène, un système de bornes permet de limiter le nombre d'éléments cachés.
Les bornes sont configurables à l'initialisation du cache. Les bornes possibles sont les suivantes :
Nombre maximum de chaînes ou services .
Nombre maximum d'événements par service. -
Nombre maximum de caractères pour le titre de 1 ' événement .
Nombre maximum de caractères pour le résumé de 1 ' événement .
Ce système de borne permet d'évaluer la taille du cache une fois qu'il est constitué. Prenons par exemple un élément chaîne donc stocké dans la partie de mémoire dynamique, dont les données ont une taille de N octets. La taille des données de cet élément chaîne est donc de N+2*8 octets (+2*8 pour les deux poignées qui assurent le double chaînage) soit N+16. Supposons que les événements aient une taille moyenne de M octets. Pour chaque événement il faut compter son pointeur associé donc on a M+4 octet par événement.
Le calcul de la taille de la base est :
Taille Cache = (NbMaxChaînes* (N+16) + NbMaxChaînes*NbMaxEvtParChaîne* (M+4) ) / 1024 kilooctets.
Exemple chiffré : 200 chaînes, 80 événements par chaîne, (3 jours de programme en moyenne) avec 20 octets pour les données chaînées d'une chaîne et une moyenne de 140 octets pour un événement.
Taille cache = (200* (20+16) + 200*80* (140+4) ) /1024 Taille cache = (7200 + 2.304.000) /1024
Taille cache = 2257 Ko
Taille cache = 2.2 Mo
On voit qu'il est important de bien définir les limites du système. Il convient aussi de noter que, 99,99 % de la base est en mémoire statique et que La mémoire statique accueille également les classes téléchargées donc si celle-ci est saturée, le téléchargement d'applications n'est plus possible. '~
Le module de consultation de mémoire, "browser de données" SI (package eventbrowser) sera maintenant décrit .
Dès que des données sont disponibles dans le cache de SI, elles peuvent être récupérées à l'aide d'un consulteur de mémoire. Le cache n'a pas besoin d'être complet, même partiellement rempli, il peut faire l'objet de consultations de la part des applications. Cependant, il faut au moins qu'une chaîne ait été formatée pour qu'il puisse y avoir une consultation. L'accès aux données s'effectue au moyen d' itérateurs . On distingue deux types d'itérateurs :
Un itérateur sur la base des chaînes ou services
Un itérateur sur la base des événements. L' itérateur de chaînes parcourt ("browse") la liste doublement chaînée se trouvant dans la partie de mémoire dynamique décrite plus haut. Du fait de son chaînage double les mouvements arrière et avant sont simples et rapides. Les fonctions "lit et passe au suivant" (readAndGoNext) et "lit et passe au précédant" (readAndGoPrevious) permettent de récupérer des informations sur chacune des chaînes parcourues (browsées) . Les informations sont incluses dans un objet de la classe chaîne. De multiples fonctionnalités sont également disponibles, telles que la recherche d'une chaîne, le positionnement d'un mode loupe. L' itérateur d'événements permet, comme
1' itérateur de chaînes, de renvoyer des instances (des objets) de la classe événement DNBEvent qui contiennent chacun l'ensemble des informations se reportant *à un événement. Cependant il faut distinguer deux types distincts d' itérateurs , l' itérateur d'événements associés à une chaîne et l' itérateur d'événements triés par genre .
L' itérateur d'événements associés à une chaîne permet de parcourir ("browser") les événements associés à une chaîne. Ce type d' itérateur est notamment utilisé dans la construction des grilles de programmes.
L' itérateur d'événements triés par genre permet comme son nom l'indique de trier les événements sur un critère bien précis que les événements triés remplissent. De tels itérateurs sont utilisés par exemple pour construire des listes triées par genre telles que l'ensemble des films ou l'ensemble des événements sportifs etc.
Lors de la construction d'un tel itérateur il y a mémorisation des pointeurs d'événements dans un tableau de pointeurs annexes . Ce tableau est construit en deux temps comme représenté schématiquement figure 17. L'ensemble des zones compactes 2 d'événements de l'ensemble des chaînes est parcouru et analysé. Si l'événement remplit la condition de filtrage, il est marqué par un drapeau (''taggé'') puis un compteur est incrémenté. Le marquage de l'événement est représenté figure 17 par une première flèche f dirigée vers un événement de la zone 2. Dans l'exemple représenté figure 17 la première zone 21 d'événement comporte deux films, les zones compactes 22 , 23, 24, 25, 26, 210, 211 comportent un seul film, les zones compactes 27, 28, 29 ne comportent pas l'événement recherché. Il a été trouvé 9 événements remplissant le critère de tri et donc le compteur d'événements est à 9. Une fois~ que l'ensemble de la base a été parcouru, on affecte la mémoire statique nécessaire pour recopier les pointeurs des événements marqués. Dans l'exemple représenté il s'agit d'un tableau 200 vide à ce stade contenant juste la place mémoire nécessaire à l'inscription de 9 pointeurs 2001 à 2009 Enfin un deuxième parcourt de la base permet de copier les pointeurs des événements marqués dans l'espace de mémoire statique fraîchement créée et de démarquer ces événements. La recopie des pointeurs est matérialisée par une deuxième flèche g dirigée vers le pointeur d'un événement marqué. Une fois les pointeurs recopiés, un accès direct à tous les événements marqués est construit. Suivant les critères de construction de l' itérateur, un tri par ordre chronologique et/ou par ordre' alphabétique peut ensuite être réalisé. Une illustration d'un tel usage d' itérateur est donnée par la figure 18 dans laquelle le tableau 200 est représenté avec une flèche par pointeur pointant chacune sur l'un des événements triés
Dans le mode préféré de réalisation de l'invention le module de consultation de mémoire comporte une fonction de vérification de la pertinence des données parcourues de façon à s ' assurer que les informations sont à jour au moment où on les consulte. Cette fonction sera décrite ci-après.
Une donnée SI est dite ' 'pertinente' ' si elle est identique dans le cache en mémoire ou dans le flot MPEG de diffusion. Le cache de données SI est pertinent s'il reflète exactement les données diffusées dans leur ensemble. Il doit donc être capable de détecter- les mises à jour dynamique faite sur le flux (cf Le moteur d'acquisition des EIT)
Lorsqu'une instance d'une classe chaîne ou événement est créée via le module de consultation de mémoire (browser) de données SI, celle-ci contient une copie des informations contenue dans le cache. Ces informations sont susceptibles de changer dans la mesure où le cache peut évoluer. Une chaîne peut être reprogrammée, c'est à dire effacée du cache puis rechargée. Les données java représentatives de cette chaîne avant la reprogrammation sont obsolètes . De même un itérateur spécifique d'événement est susceptible d'être mis à jour. Il convient donc de prévenir l'utilisateur. Ceci est accompli via le mécanisme des exceptions .
Dès que les données associées à une chaîne diffusée sur un flux de transport sont formatées, la chaîne mémorise une signature. Cette signature est délivrée par un serveur de signature. Ce serveur garantit de ne jamais donner deux signatures identiques après chaque construction d'une même chaîne. Chaque instance de la classe chaîne recopie cette signature au sein de ses données internes. A chaque appel de méthodes sur cet objet chaîne les signatures sont comparées . Si elles sont identiques les données de la chaîne sont pertinentes et peuvent être parcourues (browsées) . Dans le cas contraire, une exception est levée indiquant à l'application que l'objet chaîne qu'elle utilise est obsolète. Il convient donc que l'application demande une nouvelle instance de la classe chaîne ou qu'elle demande la mise à jour de son objet. _
Dès que les données d'une chaîne sont mises à jour, il faut invalider (rendre obsolète) les itérateurs spécifiques d'événements. Un itérateur contient des adresses d'événements. Il faut donc garantir à chaque opération de consultation (browsing) sur un itérateur que les adresses qu'il contient pointent bien vers des événements actuels et non vers des données obsolètes . Pour ce faire chaque itérateur est validé par un booléen. A chaque modification de la base aussi infime soit-elle, ce booléen sous forme d'un drapeau est positionné à une position d'invalidation "false" afin d'invalider l' itérateur. De la même façon que pour les données d'une chaîne, à chaque opération de consultation (browsing) sur un itérateur, une vérification est faite sur sa validité. S'il est invalide, une exception est levée. Il convient donc que l'application demande une nouvelle instance d' itérateur ou qu'elle demande une mise à jour de celui-ci. Les demandes de mise à jour sont adressées par le module de consultation au module moteur.
Une autre particularité avantageuse de l'invention sera maintenant examinée. Le cache selon l'invention exploite les parties statique et dynamique de la mémoire. Les données SI cohabitent avec des données liées aux fonctionnements basiques du système (fonctionnement machine virtuelle, chargement des classes ...) . Dans le cas d'un fonctionnement prolongé, la mémoire statique se fragmente. Ceci est inévitable car l'exploitation du cache permet l'effacement partiel voir total des données SI. Le gestionnaire de mémoire n'effectue aucune opération de défragmentation sur la partie statique de la mémoire. Ce problème de fragmentation de la zone statique peut conduire à l'impossibilité de charger de nouvelles chaînes en mémoire bien que la place existe physiquement.
Pour remédier à ce problème, selon cette caractéristique de l'invention on définit une zone de mémoire spécifique pour le cache de données SI. Seul dans cet espace, le cache SI peut évaluer à tout moment son degré de fragmentation. De même il peut réordonner les blocks de données SI et défragmenter sa mémoire lorsque le système le lui permet : veille ou système non actif depuis un certain temps . Ce mécanisme est en tous points similaire à la gestion de la défragmentation d'un disque dur sur PC.
Les deux avantages de cette zone spécifique de mémoire sont la garantie de non-fragmentation du cache de données SI d'une part et la non-interférence avec le fonctionnement nominal du système d'autre part. On notera que l'on peut utiliser à cette fin le logiciel implanté de défragmentation de la partie de mémoire dynamique. Pour cela il convient de modifier périodiquement ou sur requête le paramétrage de la partie de mémoire dynamique et de la partie spécifique de mémoire statique, pour rendre dynamique la totalité de la mémoire statique dédiée aux applications SI, puis de fixer à nouveau une limite une fois la défragmentation faites. On peut aussi pour gérer au mieux les données
SI utiliser un disque dur. Naturellement le gestionnaire de fichiers (file System) doit intégrer un outil de défragmentation. •-
Le procédé de construction de la base de données relative aux informations sur les programmes et le procédé de consultation de cette base, sont sous forme de logiciel implanté dans une mémoire d'un appareil, par exemple une télévision, un décodeur ou un magnétoscope. Le logiciel peut aussi être importé par exemple sous forme d'un support contenant le logiciel à introduire dans l'appareil ou encore par téléchargement .

Claims

REVENDICATIONS
1. Procédé de construction d'une base de données relative à des informations d'événements diffusées périodiquement sous forme de flux de données par un ou plusieurs fournisseurs de services dans lequel : a) on constitue un fichier de différents services identifiés susceptibles de diffuser des informations d' événement , b) on extrait et on stocke temporairement une partie au moins d'une série d'informations sur les événements diffusés par chaque service, c) on sélectionne pour chaque événement les informations que l'on souhaite stocker pour une longue durée, d) on détermine le nombre d'octets contenus dans les informations sélectionnées pour chaque événement ainsi que la somme de ces quantités d'informations pour l'ensemble des événements de chaque service, e) on recherche une zone d'adresses mémoire de taille suffisante pour y stocker de façon non fragmentée toutes les informations sélectionnées relatives à tous les événements d'un premier service les uns à la suite des autres, f) on recopie dans les zones d'adresses non fragmentées trouvées à l'étape e) chacun des événements du premier service les uns à la suite des autres, g) on complète le fichier des services par l'adjonction, dans une fiche de ce fichier correspondant audit premier service d'un pointeur donnant l'adresse du pointeur, du premier événement de ce service, h) on recommence les étapes d) à g) pour chacun des services du fichier des services, i) on efface de la mémoire les informations extraites à l'étape b) .
2. Procédé de construction selon la revendication 1, caractérisé en ce qu'à l'étape d) on tient en outre un compte du nombre d'événements pour définir la place mémoire nécessaire à la création d'un tableau de pointeurs donnant chacun l'adresse du début d'un événement et en ce qu'à l'étape e) on constitue en outre une zone mémoire compacte de taille juste suffisante pour y loger ledit tableau de pointeurs, et enfin en ce qu'à l'étape f) on inscrit dans le tabieau des pointeurs, pour chaque événement, l'adresse du début des informations relatives à cet événement.
3. Procédé de construction selon la revendication 1, caractérisé en ce que les éléments services du fichier des services sont chaînées.
4. Procédé de construction selon l'une quelconque des revendications 1 ou 2 , caractérisé en ce que les éléments services du fichier des services sont doublement chaînés .
5. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que pour exécuter les étapes d) à e) à partir des informations extraites à l'étape b) : on commence par créer, pour chaque service, un ensemble temporaire d'éléments (2 ' 1, ....2 'n) événements- chaînes, chaque élément événement contenant les informations sélectionnées (2 ' 11....2 'ni ....2 'n4) relatives à un événement, cet ensemble d'éléments événements chaînés, étant créé par ajouts successifs d'événements (2 '41-2 '44) à la chaîne (2' 4) au fur et à mesure de la réception des informations relatives à chacun de ces événements, jusqu'à réception d'un dernier événement (2 '44) relatif à ce service, en ce qu'un compte du nombre d'événements est incrémenté de 1 à chaque ajout d'événement, en ce que le nombre d'octets contenus dans les informations sélectionnées est incrémenté du nombre d'octets décrivant l'événement, pour chacun des événements ajoutés, le compte du nombre d'événements étant la valeur de ce compte après ajout du dernier événement, la valeur du nombre d'octets nécessaire au stockage des informations relatives aux événements de ce service étant ladite valeur après ajout du dernier événement du service.
6. Procédé selon la revendication 5, caractérisé en ce que les informations effacées à l'étape i) sont celles (2 '11-2 '44) qui constituent l'ensemble temporaire chaîné.
7. Procédé selon l'une des revendications 3 ou 4, caractérisé en ce que la base de données est construite sur une mémoire comportant un logiciel de gestion de la mémoire, ce logiciel réservant :
- une première partie (10) de la mémoire dans laquelle est effectuée une gestion dynamique des éléments qui y sont contenus, au moyen de deux poignées par élément, l'une donnant une adresse logique du début de l'élément et l'autre une adresse physique, cette gestion dynamique comportant une fonction de défragmentation par récupération des gaspillages ; — une seconde partie (100) de la mémoire dans laquelle est effectuée une gestion statique, et en ce que :
- la liste chaînée des services (11-ln) est stockée dans la partie dynamique (10) de la mémoire et en ce que les zones (21-2n) compactes d'événements et éventuellement leurs tableaux de pointeurs (81-8n) associés sont stockés dans la partie statique (100) de la mémoire.
8. Procédé de construction d'une base de données selon l'une des revendications précédentes caractérisé en ce que on définit préalablement à la constitution de la base, une ou plusieurs bornes portant sur le nombre de services ou sur le nombre d'événements par service ou encore sur d'autres données et en ce que les données dont la quantité excède la borne fixée pour cette donnée ne sont pas chargées dans la zone compacte (21_2n).
9. Procédé selon l'une des revendications précédentes caractérisé en ce qu'on stocke des données diffusées par les fournisseurs de service, et donnant un compteur de service et un numéro de version d'événement, on compare périodiquement ces données aux données de même nature actuellement diffusées, on utilise les résultats de la comparaison pour déterminer les services pour lesquels une nouvelle acquisition de données doit être effectuée ou les services qui n'ont pas été enregistrés auparavant.
10. Procédé de consultation d'une base de données constituée selon l'une des revendications précédentes comportant une liste chaînée de service et autant de zones compacte d'événements que de services, ces zones compactes étant associées à un tableau de pointeurs dont chaque pointeur désigne le début de l'adresse d'un événement contenu dans la zone compacte, caractérisé en ce que il comporte une fonction de parcours service par service dans laquelle on extrait et présente des données relatives aux événements d'un service sélectionné.
11. Procédé selon la revendication 10, caractérisé en ce que il comporte en outre une fonction de présentation de données sur des événements sélectionnés en fonction de un ou plusieurs critères identifiables dans les données contenues dans les événements répertoriés dans l'ensemble des zones compactes de stockage de données relatives aux événements des différents services, la sélection étant faite selon les étapes ci-après : on fait un premier parcours de repérage et marquage des événements répondant au critère de sélection et on incrémenté un compteur initialisé à zéro de 1 chaque fois qu'un événement répondant au critère ou aux critères est marqué, on constitue un tableau vide de pointeurs pouvant contenir un nombre de pointeurs égal à la valeur du compteur après parcours de toutes les zones compactes, on effectue un deuxième parcours pour recopier dans le tableau vide les adresses des événements marqués et effacer les marquages, on parcours les données sélectionnées par déplacement dans le tableau de pointeurs .
12. Appareil, notamment décodeur ou récepteur de télévision ou magnétoscope contenant au moins une mémoire et un logiciel résidant ou importable permettant de mettre en œuvre un procédé de construction d'une base de données et/ou de consultation de cette base selon l'une des revendications 1 à 11.
PCT/FR2001/001604 2000-05-24 2001-05-23 Procede de formation et d'utilisation d'une base de donnees d'evenements WO2001090898A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001264013A AU2001264013A1 (en) 2000-05-24 2001-05-23 Method for constituting and using an event database

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0006623A FR2809510A1 (fr) 2000-05-24 2000-05-24 Procede de formation et d'utilisation d'une base de donnees d'evenements
FR00/06623 2000-05-24

Publications (2)

Publication Number Publication Date
WO2001090898A2 true WO2001090898A2 (fr) 2001-11-29
WO2001090898A3 WO2001090898A3 (fr) 2002-02-28

Family

ID=8850559

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/001604 WO2001090898A2 (fr) 2000-05-24 2001-05-23 Procede de formation et d'utilisation d'une base de donnees d'evenements

Country Status (3)

Country Link
AU (1) AU2001264013A1 (fr)
FR (1) FR2809510A1 (fr)
WO (1) WO2001090898A2 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0597198A2 (fr) * 1992-11-12 1994-05-18 Siemens Aktiengesellschaft Méthode pour l'aquisition de données de télétexte
EP0706130A1 (fr) * 1994-10-07 1996-04-10 International Business Machines Corporation Procédé d'allocation de mémoire contigu
WO1998006219A1 (fr) * 1996-08-06 1998-02-12 Starsight Telecast, Incorporated Guide de programme electronique a zones interactives

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0597198A2 (fr) * 1992-11-12 1994-05-18 Siemens Aktiengesellschaft Méthode pour l'aquisition de données de télétexte
EP0706130A1 (fr) * 1994-10-07 1996-04-10 International Business Machines Corporation Procédé d'allocation de mémoire contigu
WO1998006219A1 (fr) * 1996-08-06 1998-02-12 Starsight Telecast, Incorporated Guide de programme electronique a zones interactives

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROSENGREN J: "Electronic programme guides and service information" PHILIPS JOURNAL OF RESEARCH,NL,ELSEVIER, AMSTERDAM, vol. 50, no. 1, 1996, pages 253-265, XP004008215 ISSN: 0165-5817 *

Also Published As

Publication number Publication date
AU2001264013A1 (en) 2001-12-03
WO2001090898A3 (fr) 2002-02-28
FR2809510A1 (fr) 2001-11-30

Similar Documents

Publication Publication Date Title
CN101686368B (zh) 用于远程控制客户机系统的存储和操作的方法和设备
CN100440956C (zh) 广播节目记录超时和欠时排程系统
CA2337144C (fr) Procede de reception de fichiers lors d&#39;un telechargement
US20080028294A1 (en) Method and system for managing and maintaining multimedia content
CN1273669A (zh) 数据自动售货机系统及其方法
EP2343892A1 (fr) Dispositif et procédé de gestion à distance d&#39;un réseau de systèmes de reproduction d&#39;information audiovisuelles
CN101610395A (zh) 对于经由媒体共享服务所共享的媒体内容的自动编辑过程
EP2060084A1 (fr) Architecture d&#39;acces a un flux de donnees au moyen d&#39;un terminal utilisateur
JP2004534335A (ja) 受信器装置及び方法
KR20140044883A (ko) 전자 프로그램 가이드를 캐싱하기 위한 시스템 및 방법
CN101068341B (zh) 流媒体调度系统及其媒体文件调度方法
FR3028631A1 (fr) Procede de classement d&#39;un contenu et recommandation de contenu dans un guide electronique des programmes
US8219634B2 (en) Information distribution system, and information distribution method
EP0878758B1 (fr) Dispositif de tri d&#39;éléments de données à arbre binaire et espaceur ATM comportant un tel dispositif
FR2771884A1 (fr) Procede de gestion d&#39;informations de service dans un systeme de television numerique et recepteur mettant en oeuvre ce procede
FR2933226A1 (fr) Procede et systeme de production d&#39;oeuvres audiovisuelles
EP1433322B1 (fr) Procede de transmission d&#39;emissions audiovisuelles proposees par des utilisateurs, terminal et serveur pour la mise en oeuvre du procede
WO2001090898A2 (fr) Procede de formation et d&#39;utilisation d&#39;une base de donnees d&#39;evenements
FR2983380A1 (fr) Procede de transmission de programmes de video a la demande de type &#34; push &#34; et decodeur associe
FR2927183A1 (fr) Procede de generation de donnees permettant la recherche de complements de contenus, systeme, terminal et serveur pour la mise en oeuvre du procede
EP2109979A2 (fr) Procede et dispositif de gestion de connexions dans un reseau de telecommunications
FR2752351A1 (fr) Procede d&#39;indexation de donnees dans un systeme de transmission de television numerique
FR2952204A1 (fr) Procede de generation d&#39;un flux web et un systeme associe
EP1551191B1 (fr) Procédé de diffusion de messages multimédia à une flotte hétérogène de terminaux
CA2397867C (fr) Procede et systeme pour la diffusion de donnees en boucle

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载