DE69805044T3

DE69805044T3 - Verfahren und Vorrichtung zur Verwaltung von Dienstinformationen in einem Digitalfernsehsystem

Info

Publication number: DE69805044T3
Application number: DE69805044T
Authority: DE
Inventors: Gilles Straub; Nour-Eddine Tazine
Original assignee: Thomson Multimedia SA
Current assignee: Technicolor SA
Priority date: 1997-12-02
Filing date: 1998-11-20
Publication date: 2006-08-03
Anticipated expiration: 2018-11-21
Also published as: EP0921681A1; FR2771884A1; CN1157948C; FR2771884B1; JP4111255B2; CN1221285A; DE69805044T2; JPH11234633A; DE69805044D1; EP0921681B1; EP0921681B2

Description

Die Erfindung betrifft ein Verfahren zur Verwaltung von Serviceinformationen in einem digitalen Fernsehsystem, insbesondere von Informationen für Programmführer.
Die Erfindung ist unter anderem bei digitalen Fernsehdekodern anwendbar.
Elektronische Programmführer (oder EPGs = electronic programme guides) sind Software-Anwendungen, die in digitalen Fernsehsystemen benutzt werden. Diese Anwendungen bieten dem Betrachter eine Schnittstelle, wodurch er Informationen insbesondere für die gesendeten Programme erlangen kann.
Die Informationen werden dadurch übertragen, indem entsprechende Datenpakete in dem digitalen Datenstrom gemultiplext werden. Ein Name, der häufig für diesen Datentyp verwendet wird, ist "Service Information" (oder einfach "SI").
Die Serviceinformationen werden periodisch gesendet, wobei die Periode insbesondere aufgrund des verfügbaren Durchlaßbandes und der Häufigkeit der Benutzeranforderungen für die Informationen gewählt wird. Das ist der Fall, weil es dann, wenn der Benutzer die Informationen für eine große Anzahl von Programmen schnell sehen möchte, erwünscht ist, daß die Wartezeit zwischen der Anforderung des Benutzers für die Informationen und der Antwort auf diese Anforderung so kurz wie möglich ist. Ein Mittel besteht darin, jeden Empfänger oder Dekoder mit einer großen Speichermenge auszurüsten, um soviel Informationen wie möglich zu speichern, um in der Lage zu sein, auf die Anforderungen des Benutzers unverzüglich zu antworten. Es ergibt sich, daß die Gesamtmenge an Sendeinformationen derart groß ist, daß diese Lösung in einem Massenprodukt für die allgemeine Bevölkerung nicht durchführbar ist, zumindest nicht bei den derartigen Kosten von Halbleiterspeichern. Außerdem würde die Tatsache, daß der Informationsinhalt sich ständig ändert, den Empfänger oder Dekoder dazu zwingen, einen beträchtlichen Teil seiner Mittel für die Aktualisierung der Informationen zu widmen, ob sie danach benutzt werden oder nicht. Insbesondere ist die Anzahl von Datenpaket-Demultiplexfiltern, die gleichzeitig programmiert und ausgeführt werden können, begrenzt.
Die beiden französischen Patentanmeldungen FR 96 10067 (nun veröffentlicht als FR-A-2 752 350) und FR 96 10068 (nun veröffentlicht als FR-A-2 752 351), angemeldet am 09.August 1996 auf den Namen des Anmelders, betreffen ein Modul zur Verwaltung von Serviceinformationen in einem Empfänger, insbesondere einem digitalen Fernsehdekoder. Die Anmeldung FR 96 10067 betrifft einen Fernsehempfänger und ein Verfahren zur Verwaltung der Aktualisierung von bestimmten Typen von Daten, die in einer internen dynamischen Datenbank in dem Empfänger gespeichert sind, während die Anmeldung 96 10068 ein Verfahren zum Indizieren von Daten in der internen Datenbank betrifft, die von dem digitalen Strom empfangen und extrahiert werden. Die Anmeldung WO 98/09430 mit der Benennung von Europa, der Vereinigten Staaten, Japan und China beansprucht die Priorität der Anmeldung FR 96 10068 . Anmeldungen, die die Priorität von FR 96 10067 beanspruchen, wurden in Europa (Veröffentlichungsnummer EP-A-0 823 798), China (Veröffentlichung CN-A-1 175 826), den Vereinigten Staaten (Anmeldung 08/906597), Indonesien (Anmeldung P-972774) und Japan (Veröffentlichung 98508/98) angemeldet.
Diese beiden Patente beschreiben ebenfalls Anforderungen, die eine Anwendung wie ein Programmführer stellen kann, um diesen oder jenen Informationspunkt von dem Modul zur Verwaltung der SI-Daten anzufordern, wobei dieser Modul den Demultiplexer programmiert: ständige oder einmalige Anforderung, erwartet oder unerwartet.
Gemäß diesen beiden Patenten werden Daten für die permanenten Anforderungen in der internen Datenbank bis zur Deprogrammierung der permanenten Anforderung gespeichert, während extrahierte Daten, die auf eine einmalige Anforderung folgen, in dem Speicher nicht über die sofortige Verarbeitung hinaus gespeichert werden.
In dem Fall, wo der Benutzer seine Schritte durch den Programmführer durchführt, ist es möglich, daß kürzlich gelöschte Daten noch einmal extrahiert werden müssen.
Durch die Erfindung wird vorgeschlagen, die Reaktivität des Systems in einem derartigen Fall zu erhöhen.
Der Gegenstand der Erfindung ist in den Ansprüchen angegeben.
Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der Beschreibung einer nicht-einschränkenden Ausführungsform. Diese Ausführungsform wird durch die beigefügten Figuren erläutert. In den Figuren zeigen:
1 ein Blockschaltbild eines Fernsehempfängers gemäß der vorliegenden Ausführungsform,
2a bis 2c Zeitdiagramme der Austauschvorgänge zwischen einer Anwendung, dem Daten-Verwaltungsmodul und dem Demultiplexer des Gerätes von 1,
3a bzw. 3b ein Zustandsdiagramm zur Erläuterung der Betriebsweise einer einmaligen Anforderung bzw. einer permanenten Anforderung,
4 ein Diagramm eines Schirms einer Anwendung, nämlich eines elektronischen Programmführers,
5 ein Diagramm der Datenbank, die in einem bestimmten Zeitpunkt durch das Verwaltungsmodul aufrechterhalten wird.
Für weitere Informationen über das Format und die Inhalte von MPEG- und DVB-Servicedaten, Segmenten und Tabellen wird insbesondere auf die folgenden drei Dokumente verwiesen:

(a) ETS 300 468 – Specification for Service Information (SI) in Digital Video Broadcast (DVB) systems – Januar 23, 1996,
(b) ISO/IEC 13818-1 (1994) Generic Coding of Moving Pictures and Associated Audio – Recommendation H.220, auch mit "MPEG2 Systems" bezeichnet, and
(c) ETR 211 – Digital Broadcasting systems for television: Implementation guidelines for the use of MPEG-2 systems; Guidelines on implementation and usage of service information.

1 ist ein Blockschaltbild eines integrierten Dekoders/Empfängers für digitales Fernsehen vom Typ DVB (Digital Video Broadcasting).
Es ist ersichtlich, daß die Erfindung nicht auf dieses Gebiet beschränkt ist, sondern leicht an beliebige andere Übertragungstypen oder Servicedaten angepaßt werden kann, zum Beispiel eine Übertragung durch modulierte Daten innerhalb des Bildrücklaufintervalls.
Der Dekoder von 1 ist mit einer Antenne 1 verbunden, die selbst mit einem Tuner 2 des Dekoders verbunden ist. Das von dem Tuner gelieferte Signal wird durch einen Demodulator 3 demoduliert. Die demodulierten Daten werden durch eine Korrekturschaltung 4 korrigiert und zu einem Demultiplexer 5 übertragen.
Letzterer ist zum Beispiel ein Demultiplexer ähnlich zu demjenigen, der in der französischen Patentanmeldung 95 15767, angemeldet am 29. Dezember 1995 auf den Namen von THOMSON MULTIMEDIA, beschrieben wurde. Der Demultiplexer 5 enthält eine Anzahl von Filterregistern, bezeichnet mit Ausdehnungsfiltern, programmiert durch einen Mikroprozessor 23 in Abhängigkeit von den verschiedenen, durch den Dekoder durchgeführten Anwendungen. Der Demultiplexer vergleicht die Inhalte der Filterregister mit bestimmten Parametern der Datenpakete und lädt die einem positiven Vergleich entsprechenden Datenpakete.
Aus Gründen der Klarheit des Diagramms sind nur die wichtigsten Anschlüsse des Mikroprozessors 23 dargestellt.
Die durch den Demultiplexer gefilterten Audio- oder Video-Pakete oder -Segmente werden in vorbestimmten Bereichen eines die Anwendungen erwartenden Pufferspeichers 6 gespeichert. Sofern notwendig, werden die Informationen zunächst durch eine Entschlüsselungsschaltung 7 in Abhängigkeit von der Berechtigung des Benutzers entschlüsselt, bevor sie in diesem Pufferspeicher 6 gespeichert werden.
Gemäß dem vorliegendem Beispiel gibt es fünf Anwendungen: ein Audiodekoder 16, ein Videodekoder 17, ein Teletextdekoder 18, eine Anordnung zur Zugriffssteuerung (enthaltend den Entschlüsseler 7, einen Prüf-Mikroprozessor 8 und eine Schnittstelle für eine Mikroprozessor-Karte 9, die im normalen Betriebsmodus mit einer Mikroprozessor-Karte 10 verbunden ist) sowie ein Modul für die Verwaltung der Servicedaten.
Der Dekoder enthält außerdem eine Infrarot-Schnittstelle für eine Fernbedienung 24, wobei die Schnittstelle ebenfalls mit dem Mikroprozessor 23 verbunden ist. Letzterer ist mit einem Speicher 12 verbunden, der das Betriebssystem sowie die residenten oder heruntergeladenen Programme zur Durchführung der Anwendungen enthält.
Ein Modem 13, das mit dem geschalteten Telefonnetz 14 verbunden ist, wird ebenfalls durch den Mikroprozessor gesteuert.
Ein Schriftzeichengenerator 15 ermöglicht die Erzeugung von Steuermenüs oder Graphiken für die Parameter des Dekoders oder für eine besondere Anwendung. Das durch diesen Schriftzeichengenerator erzeugte Videosignal wird mit einem der Videosignale, die von dem Videorekoder 17 oder von dem Teletextdekoder 18 kommen, über eine erste SCART-Buchse gemultiplext, die mit einem Fernseher 22 verbunden ist, oder über eine zweite SCART-Buchse, die mit einem Videorekorder 21 verbunden ist. Die Multiplexschaltung 20 wird durch den Mikroprozessor 23 verwaltet.
Gemäß dem vorliegenden Ausführungsbeispiel ist der Modul für die Verwaltung der Servicedaten, räumlich gesprochen, ein durch den Mikroprozessor verwaltetes Programm, wenngleich er begrifflich eine Anwendung ist, die Datenpakete verarbeitet, in der Art eines Audio- oder Videodekoders, für die die speziell gewidmeten Schaltungen benutzt werden.
Der Modul ist eine Schnittstelle zwischen den Servicedaten (MPEG und DVB-Tabellen- und -Segmente) und Benutzeranwendungen (Programmführer, Ferneinkauf, interaktive Spiele usw.). Er verwaltet die Anforderungen von den Benutzeranwendungen und hält eine interne Datenbank mittels der empfangenen Servicedaten aufrecht.
Gemäß dem vorliegendem Ausführungsbeispiel ist die Benutzeranwendung ein Programmführer, der ebenfalls durch den Mikroprozessor verwaltet wird.
Eine Anzahl von Funktionen für die Formulierung der Anforderungen für die durch die Anwendungen benötigten Informationen wird durch das Verwaltungsmodul für die Benutzeranwendungen verfügbar gemacht.
Die Anforderungsfunktionen arbeiten asynchron. Die Anwort auf eine Anforderung, wenn eine Antwort besteht, wird durch den Venwaltungsmodul einer Anwendung mitge teilt, wenn diese Antwort verfügbar ist. Das erfordert die Ausführung einer Vorrichtung zur Identifikation der Anforderungsfunktion. Zu diesem Zweck wird ein Identifizierer durch die Anwendung für jede Anforderung gewählt, die zusammen mit dieser Anforderung ausgegeben und übertragen wird. Dieser Identifizierer ist mit der Mitteilung der Antwort durch das Verwaltungsmodul verknüpft.
2a bis 2c zeigen die drei Fälle von Austauschvorgänge, die auf eine Anforderung folgen, zwischen der Benutzeranwendung, dem Verwaltungsmodul für die Servicedaten und der Quelle dieser Daten, nämlich der Anordnung aus dem Demultiplexer/Puffer Speicher/Mikroprozessor.
2a betrifft den Fall, in dem die interne Datenbank ("cache memory") die durch die Benutzeranwendung geforderten Informationen enthält. Auf die Anforderung des letzteren folgt die Mitteilung der Verfügbarkeit dieser Informationen. Auf die Informationen, die in diesem Fall in der Datenbank anwesend sind, folgt die Mitteilung der Anwort nahezu unverzüglich. In diesem Fall wird kein Datenwort zu oder von dem Demultiplexer übertragen. Die Datenübertragung zu der Anwendung erfolgt durch einen Pufferspeicher, in den das Verwaltungsmodul die Daten schreibt. Der zu verwendende Bereich des Pufferspeichers wird in der Anforderung der Anwendung identifiziert. Die Anwendung liest, nachdem sie mitgeteilt worden ist, die Daten daraus unverzüglich. Dieser Fall wird später im Detail ersichtlich.
2b zeigt den Fall, in dem die angeforderten Informationen nicht in der internen Datenbank erscheinen. In diesem Fall folgt ebenso auf die Anforderung der Anwendung die Mitteilung durch das Verwaltungsmodul zu der Anwendung zur Information über die vorübergehende Unverfügbarkeit der Informationen und dann ein durch das Verwaltungsmodul zu dem Demultiplexer adressierter Befehl. Wenn das Segment oder die Segmente, die den gesuchten Informationen entsprechen, in dem Datenstrom gefunden, demultiplexiert und in dem Pufferspeicher gespeichert sind, informiert der Multiplexer das Venwaltungsmodul SI darüber, daß diese Segmente verfügbar sind. Nach dem Lesen und der Neu-Formatierung der Daten der Segmente informiert das Verwaltungsmodul daraufhin die Benutzeranwendung, daß die gesuchten Informationen verfügbar sind. Wie in dem vorangehenden Fall schreibt der Modul die gesuchten Informationen (die auch einige der Daten von dem Segment sein können) in einen Pufferspei cher, der während seiner anfänglichen Anforderung durch die Benutzeranwendung zugeordnet wird. Somit kommt in diesem Fall diese Mitteilung langsamer an als im Fall 2a.
2c zeigt den Fall, in dem die ursprüngliche Anforderung wie die von 2a angibt, daß die Änderungen in den gesuchten Informationen signalisiert werden müssen. In diesem Fall werden die Filter des Demultiplexers, die es ermöglicht haben, daß das diese Informationen enthaltende Datenpaket aus dem Datenstrom extrahiert wird, bei den vorangehenden Werten aufrechterhalten, anstatt deaktiviert zu werden. Dieser Typ der Anforderung, bezeichnet mit permanenter Anforderung, wird im folgenden im Detail beschrieben.
Gemäß dem vorliegenden Ausführungsbeispiel gibt es vier Typen einer Anforderung:

(a) Einmalige Anforderung: Wenn eine derartige Anforderung durch die Anwendung zu dem Verwaltungsmodul adressiert wird, macht letzterer seine Betriebsmittel oder sogenannten Resourcen (Filter und Speicher) nur bis zu dem Augenblick verfügbar, bei dem die angeforderten Daten zu der Anwendung übertragen werden. Die Betriebsmittel werden im Prinzip unverzüglich freigegeben.
(b) Erwartete einmalige Anforderung: Diese Anforderung besitzt die Eigenschaften der einmaligen Anforderung, besitzt jedoch eine niedrigere Priorität. Das Verwaltungsmodul hält zwei Speicher vom Typ FIFO aufrecht, einer für die erwarteten Anforderungen und der andere für die unerwarteteten Anforderungen. Erwartete Anforderungen, die warten, werden immer nach den unerwarteten Anforderungen verarbeitet.
(c) Permanente Anforderung: Die Betriebsmittel oder Resourcen des Verwaltungsmoduls werden aufrechterhalten, selbst nachdem die angeforderten Daten demultiplexiert und übertragen worden sind. Jedesmal, wenn eine Änderung in diesen Daten erfolgt, wird die Mitteilung zu der Anwendung übertragen. Das Verwaltungsmodul bewirkt daher eine systematische Überwachung, und zwar solange, bis die Anwendung einen Befehl zur Unterbrechung dieser Überwachung sendet.
(d) Erwartete permanente Anforderung: Diese Anforderung ist ähnlich zu der permanenten Anforderung, hat jedoch einen niedrigeren Prioritätswert.

Die den Anforderungen zugeordneten Prioritäten bilden natürlich kein Präjudiz für die Reihenfolge, in der die zu diesen Anforderungen gehörenden Daten tatsächlich empfangen werden. Diese Reihenfolge ist auch von Faktoren abhängig, wie die Periodizität jedes Datenworts und dem Zeitpunkt, bei dem die Anforderung für diese Periode formuliert wird.
3a ist ein Zustandsdiagramm einer einmaligen Anforderung, während 3b ein Zustandsdiagramm einer permanenten Anforderung ist.
Immer wenn eine Anwendung eine Anforderung formuliert, muß dieser ein Anforderungstyp zugeordnet werden.
In dem Fall einer permanenten Anforderung werden die aus dem Strom wiedergewonnenen Daten zusätzlich in der internen Datenbank in dem Verwaltungsmodul gespeichert. Das ist nicht der Fall für die Daten, die nach einer einmaligen Anforderung extrahiert werden, für die keine Kopie der Daten vorgesehen ist. Wenn eine neue Version einer Tabelle, die Daten für eine permanente Anforderung enthält, detektiert wird, werden die entsprechenden Daten von dieser Tabelle mit den Daten in der Datenbank verglichen. Eine Änderung der Version wird durch eine Änderung des Wertes eines mit "version_id" oder "version_number" bezeichneten Parameters angezeigt, der mit jeder Tabelle übertragen wird. Eine Mitteilung der Aktualisierung wird zunächst nicht übertragen, wenn nicht wenigstens einige dieser Daten geändert worden sind. Der Versions-Identifizierer der Tabelle "version_id" wird nämlich unabhängig von der in der Tabelle erfolgenden Änderung modifiziert, selbst wenn er sich nur auf Daten bezieht, die durch eine Anwendung nicht angefordert werden. Dieser Mechanismus vermeidet die Übertragung redundanter Daten zwischen der Anwendung und dem Verwaltungsmodul.
Außerdem werden Anwendungsanforderungen von Elementaranforderungen unterschieden. Anwendungsanforderungen sind, wie ihr Name sagt, durch die Benutzeranwendungen ausgegebene Anforderungen. Eine Anwendungsanforderung wird durch das Verwaltungsmodul SI in so viele Elementaranforderungen übertragen, wie notwen dig sind. In dem vorliegenden Zusammenhang ist eine Elementaranforderung eine Anforderung, die bei einem Demultiplexer-Wert in ein einziges Filter übertragen werden kann. Die Elementaranforderungen werden in einer solchen Weise ermittelt, daß die Daten, auf die sie sich beziehen, einander nicht überlappen.
Die Anforderungstabellen werden durch das SI-Modul aufrechterhalten: Eine Tabelle von Anwendungsanforderungen und eine Tabelle von Elementaranforderungen.
Tabelle der Anwendungsanforderungen
Tabelle der Elementaranforderungen
Die Tabelle der Anwendungsanforderungen enthält die folgenden Elemente für jede Anforderung:

– einen Anforderungs-Identifzierer,
– den Typ der Anforderung (erwartet einmalig, unerwartet einmalig...),
– die Funktion der Anforderung,
– "Warten": Anzahl der entsprechenden wartenden Elementaranforderungen, d.h. diejenigen, die noch keine Antwort verursacht haben ( eine erste Mitteilung zu der Anwendung, die die Anforderung ausgegeben hat, wird dann gesendet, wenn diese Ziffer gleich null ist),
– "SingNB": Anzahl der Elementaranforderungen, die noch keine Übertragung von Daten zu dem Pufferspeicher verursacht haben,
– "SList": Liste der Identifizierer der Elementaranforderungen, die dieser Anwendungsanforderung zugeordnet sind,
– mit den Anwendungsanforderungen verknüpfte Parameter (z. Bsp.

Identifikation eines Service, für den eine Liste von Ereignissen gesucht wird).
Die Tabelle der Elementaranforderungen enthält die folgenden Elemente für jede Elementaranforderung:

– einen Identifzierer für die Anforderung,
– den Typ der Anforderung,
– die Funktion der Anforderung,
– den Zustand der Anforderung,
– die Anzahl der Anwendungsanforderungen, die mit den Elementaranforderungen verknüpft sind,
– das Datum der Inaktivierung der Anforderung (sofern relevant),
– mit der Elementaranforderung verknüpfte Parameter.

Wenn das SI-Verwaltungsmodul eine Anwendungsanforderung in eine Elementaranforderung oder Anforderungen umsetzt, prüft es, ob die Tabelle der Elementaranforderungen bereits diese Anforderungen enthält. Eine neue Elementaranforderung wird nur dann in die entsprechende Tabelle eingefügt, wenn eine identische Anforderung noch nicht existiert. Dadurch wird ermöglicht, die Anwendung von Betriebsmitteln oder Ressourcen des Demultiplexers bei redundanten Enden zu vermeiden.
Die Elementaranforderungen werden als identisch angesehen, wenn sie dieselbe Funktion und dieselben Parameter aufweisen. Wenn eine Elementaranforderung in der entsprechenden Tabelle bereits vorhanden ist, dann prüft der SI-Modul den Typ der bereits existierenden Elementaranforderung. Wenn dieser Typ eine niedrigere Priorität als der Typ der neuen Elementaranforderung hat (das ist der Typ der Anwendungsanforderung, der diese neue Elementaranforderung verursacht), dann wird der Typ der bestehenden Elementaranforderung so modifiziert, daß er den neuen Wert annimmt. Die Klassifikation der Anforderungstypen von der niedrigsten zu der höchsten Priorität ist: erwartet einmalig, erwartet permanent, unerwartet einmalig, unerwartet permanent.
Die darauffolgenden Elemente der Tabelle der Anwendungsanforderungen werden nach der Programmierung oder der Abwandlung der entsprechenden Elementaranforderungen aktualisiert: Warten, SList. Auf diese Weise wird die Verknüpfung mit den Inhalten der Tabelle der Elementaranforderungen gebildet.
Die Tabelle der Elementaranforderungen spielt noch eine andere Rolle: Sie liefert die Möglichkeit, zu ermitteln, ob ein Datenwort in der Datenbank vorhanden ist oder nicht und ob dieses Datenwort zu aktualisieren ist oder nicht.
Das "Zustands"-Feld einer Anforderung von dieser Tabelle kann einen der folgenden Werte annehmen:

– "Warten": die Anforderung ist aktiv, die Daten wurden jedoch noch nicht empfangen,
– "Fertig": die Anforderung ist aktiv, und die Daten wurden in der Datenbank gespeichert und werden aktualisiert,
– "Nicht-aktualisiert": die Anforderung ist nicht mehr aktiv, und die Daten sind in der Datenbank gespeichert, werden jedoch nicht weiter aktualisiert.

Die Tabelle der Elementaranforderungen zählt ebenfalls aufwärts, für jede Elementaranforderung, die Anzahl der relevanten aktiven Anwendungsanforderungen. Diese Zahl wird inkrementiert oder dekrementiert, wie es durch den Durchbruch (breaking down) der neuen Anwendungsanforderungen oder die Deprogrammierung der alten Anforderungen bestimmt wird. Wenn diese Anzahl für eine Elementaranforderung auf null fällt, wird der Zustand der letzteren "nicht aktualisiert" (wenn ihr Zustand vorher "Fertig" war): in anderen Worten, er ist inaktiv. Die vorher extrahierten Daten bleiben, wenn Daten vorliegen, in der Datenbank gespeichert.
Eine Elementaranforderung, für die die Anzahl der Anwendungsanforderungen auf null abfällt und die, aus dem einen oder aus dem anderen Grund, keine Informationen in der Datenbank gespeichert hat, wird aus der Tabelle entfernt. Das entsprechende Filter des Demultiplexers wird freigegeben. Die Gründe dafür können unterschiedlich sein: übermäßig schnelle Deprogrammierung, bevor Daten gewonnen werden könnten, angeforderte Daten werden nicht gesendet, usw.
Eine interaktive Elementaranforderung kann durch eine entsprechende Anwendungsanforderung reaktiviert oder aus der Tabelle von Elementaranforderungen entfernt werden, wenn es notwendig wird, Platz in dem eingenommenen Speicher in der Datenbank freizusetzen, und wenn die dazu gehörenden Daten gelöscht werden.
Die Daten der Inaktivierung einer Anforderung werden in der Tabelle der Elementaranforderungen gespeichert. Im vorliegenden Fall enthalten diese Daten den Wert des Systemtaktes, wobei dieser Takt mit dem des Koders synchronisiert ist. Es ist jedoch ebenfalls denkbar, irgendeinen anderen Typ eines Taktes anzuwenden.
Wenn die Daten, die einer Elementaranforderung entsprechen (vom einmaligen oder permanenten Typ) demultiplexiert sind, werden sie zu dem Pufferspeicher übertragen. Diese Übertragung erfolgt so oft, wie Verknüpfungen mit den Anwendungsanforderungen bestehen. Die Anzahl der Elementaranforderungen "SingNB" in jeder der relevanten Anwendungsanforderungen wird dekrementiert. Die Mitteilung der Verfügbarkeit der Daten durch das SI-Verwaltungsmodul zu einer Anwendung erfolgt nur, wenn diese Anzahl für diese Anwendung null erreicht, das heißt, wenn alle Elementaranforderungen, die mit der durch die Anwendung ausgegebenen Anwendungsanforderung verknüpft sind, ein Ergebnis geliefert haben und in den Pufferspeicher übertragen worden sind.
Wenn jedoch, im Gegensatz dazu, eine darauffolgende Änderung der Daten in der Datenbank bezüglich einer Elementaranforderung bestehen sollte, wird diese Änderung unverzüglich den relevanten Anwendungen mitgeteilt.
5, die später beschrieben wird, gibt ein Beispiel von zwei Tabellen in einem speziellen Fall an.
Wenn eine Elementaranforderung als "nicht-aktualisiert" bezeichnet wird, so bedeutet dies nicht, zu sagen, daß die Daten in der Datenbank nicht länger aktualisiert werden, sondern einfach, daß eine Wahrscheinlichkeit besteht, daß dieses so ist, wenn die Anforderung, aus der sie hervorgeht, nicht für eine Zeitperiode aufrechterhalten wurde, die von dem obengenannten Datum der Inaktivierung bestimmt werden kann.
Wenn das Verwaltungsmodul Daten in den Pufferspeicher im Hinblick darauf überträgt, zu der Anwendung die Inhalte des "Daten"-Feldes oder der Felder oder des "Zustands"-Feldes oder Felder zu übertragen, ebenfalls dort gespeichert werden. Diese Werte werden durch die Anwendung gelesen, die über die Anwendung dieser Informationen entscheidet. Wenn der Zustand "Fertig" (Ready) ist, werden die Daten aktualisiert. Wenn der Zustand "Nicht-aktualisiert" ist, sind sie nicht zu aktualisieren, und das "Daten"-Feld zeigt an, wie alt sie sind. Wenn die Anwendung ein Programmführer ist, werden die als nicht aktualisierte Daten bezeichneten wiedergegebenen Daten in einer solchen Weise wiedergegeben, daß sie als solche identifiziert werden: Zum Beispiel eine abgeschattete Wiedergabe oder eine Wiedergabe in einer Farbe, die von einem Informationspunkt abweicht, der aktualisiert werden würde.
Wenn der Zustand einer Elementaranforderung "Fertig" ist, sind die Daten zu aktualisieren. Um dieses der Anwendung während der Übertragung der Daten anzuzeigen, ist der übertragene Wert des "Daten"-Feldes gleich null.
Wenngleich gemäß der vorliegenden Ausführungsform nur die permanenten Elementaranforderungen (ob erwartet oder nicht) eine Speicherung der in der Datenbank extrahierten Daten verursachen, wird gemäß einer anderen Ausführungsform dafür gesorgt, auch die einmaligen Anforderungen entsprechenden Daten zu speichern. Es wird in diesem Fall natürlich notwendig sein, die Elementaranforderungen vom einmaligen Typ in der entsprechenden Tabelle aufrechtzuerhalten.
Unabhängig davon, ob nicht-aktualisierte Daten nach einer Anforderung in der internen Datenbank gelesen worden sind oder nicht, werden die Filter des Demultiplexers im Hinblick auf die Extrahierung der letzten Werte von dem Datenstrom programmiert. Diese Werte, wenn sie einmal aus dem Datenstrom extrahiert worden sind, werden in die Datenbank geschrieben, sofern notwendig mit einem Überschreiben der ältesten Daten. Die Zustandsänderungen der Elementaranforderungen erfolgen entsprechend: eine Anforderung, die in der Tabelle bereits existiert, kann von einem "Warte"-Zustand zu dem "Fertig"-Zustand gehen, jedoch auch von dem Zustand "Nicht-aktualisiert" zu dem Zustand "Fertig" und umgekehrt. Wenn keine Elementaranforderungen für die zu extrahierenden Daten bestehen, werden sie natürlich gebildet.
Gemäß dem vorliegenden Ausführungsbeispiel erfolgt die Verwaltung der Parameter "version_id" bei dem Wert des Demultiplexers. Es werden zwei Filtertypen verwendet: ein erster Typ, in dem die Versionsnummer der wiederzugewinnenden Information verdeckt ist (die erste detektierte Version wird demultiplexiert, unabhängig von ihrer Versionsnummer), und ein zweiter Typ, in dem die Versionsnummer einen bestimmten besonderen Wert hat (nur die Information mit dieser Versionsnummer würde demultiplexiert).
Wenn eine Elementaranforderung erzeugt wird und noch kein entsprechendes Filter existiert, wird der erste Filtertyp angewendet. Sobald die entsprechende Information detektiert und extrahiert worden ist, wenn die Elementaranforderung vom permanenten Typ ist, wird der Wert der extrahierten Versionsnummer inkrementiert und zu dem existierenden Filter hinzugefügt: ein Filter von dem obengenannten zweiten Typ wird dadurch gebildet. Dadurch ist sicher, daß die nächste Version der Information detektiert wird.
Es ist natürlich denkbar, die Werte der Versionsnummern in der Datenbank zu speichern.
Das Löschen oder sogenannte "cleaning up" der Datenbank im Hinblick auf ein Freisetzen bestimmter Speicher erfolgt mit Hilfe der Daten, die in dem "Daten"-Feld der Tabelle der Elementaranforderungen angezeigt werden. Elementaranforderungen in dem "nicht-aktualisierten" Zustand sowie die Daten, die mit diesen Anforderungen verknüpft sind, werden aus Altersgründen beseitigt. Dieses sogenannte "cleanup" erfolgt, wenn die Datenbank voll ist. Sie erfolgt auf Initiative und durch Steuerung durch das SI-Verwaltungsmodul solange, wie nur Elementaranforderungen in dem "nicht-aktualisierten" Zustand betroffen sind. Wenn die Datenbank voll ist, obwohl keine weite ren Anforderungen in dem "nicht-aktualisierten" Zustand vorliegen, wird diese Tatsache den Anwendungen mitgeteilt. Ein zusätzliches "cleanup" kann dann durch Steuerung durch die Anwendungen durchgeführt werden.
Eine der Rollen des Verwaltungsmoduls für die Servicedaten besteht darin, die Filter des Demultiplexers zu programmieren. Um diese Funktion zu erfüllen und einen schnellen Zugriff zu den gewünschten Daten zu ermöglichen, hält er ein Bild der räumlichen Struktur des Netzes oder der Netze, zu denen er Zugriff hat, aufrecht.
Die Dokumente (a) und (b) bestimmen zehn Tabellen, die Informationen ergeben über die Konfiguration des Netzes oder der Netze, die Mehrkanal-Verpackungen, übertragene Dienstleistungen und Ereignisse. Die Tabellen werden durch besondere PID (Packet Identification Data)-Werte und besondere Tabellen-Identifizierungswerte (table_id) identifiziert, deren Werte durch diese Dokumente festgelegt sind. Jede Tabelle enthält eine Identifiziererversion, die es ermöglicht, zu ermitteln, ob die Inhalte dieser Tabelle sich von einer Übertragung der Tabelle zu der nächsten geändert haben.
Die Tabelle, an der wir hier interessiert sind, ist die mit NIT (für Network Information Table) bezeichnete Tabelle. Die NIT-Tabelle enthält Informationen für ein bestimmtes Übertragungsnetz, insbesondere die Liste der je Übertragungskanal (oder Transportstrom) verfügbaren Serviceleistungen.
Das Daten-Verwaltungsmodul bildet eine interne Indexierung der verfügbaren Netze, Kanäle und Serviceleistungen. Wenn der Dekoder arbeitet oder wenn die NIT-Tabelle aktualisiert wird, wird ein logischer Schlüssel jeder der verfügbaren Serviceleistungen zugeordnet. Dieser Schlüssel ist der Index für den durch den Modul in der Datenbank aufrechterhaltenen Service.
In einem DVB-System kann ein Service in einer einzigartigen Weise über dem Weg liegen, der die folgenden Variablen enthält:

– network_id (Netz-Identifizierer),
– (transport_stream_id; original_network_id) pair,
– service_id (aktueller Service-Identifizierer).

Die drei Variablen sind über 16 Bit kodierte natürliche ganze Zahlen.
Es werden drei Typen von Listen gebildet, eine Liste für die Netze, eine Liste von Kanälen für jedes Netz und eine Liste von Serviceleistungen für jeden Kanal.
Ein Element der Liste von Netzen wird immer dann gebildet, wenn eine ein neues Netz enthaltende NIT-Tabelle demultiplexiert wird. Um dies zu tun, werden die Transportpakete, deren PID gleich 0×0010 ist, gefiltert. Diese Pakete enthalten nämlich die NIT-Tabellen, die zusätzlich durch eine Variable table_id identifiziert werden. Jedem Netz wird ein Code mit 4 Bit zugeordnet, in der Reihenfolge, in der die entsprechenden Tabellen demultiplexiert werden. Der Code ist der Index des Adressenzeigers für die Struktur, die die Informationen für dieses Netz enthält.
Die NIT-Tabelle enthält die Liste der Kanäle für jedes Netz sowie die Liste der für jeden Kanal verfügbaren Serviceleistungen.
Für jedes Netz in der Liste von Netzen wird eine Liste von Kanälen gebildet. Jedes Element einer Liste von Kanälen wird mittels 5 Bit indexiert. Die Liste enthält die Adressenzeiger für die Strukturen, die die für jeden Kanal spezifischen Daten enthalten. Der logische Schlüssel zur Identifizierung eines Kanal in der Datenbank ist aus den 4 Index-Bit für jedes Netz zusammengesetzt, gefolgt von den 5 Bit des Index des Kanals dieses Netzes.
Für jeden Kanal wird eine Liste von Serviceleistungen gebildet, die die Identifizierer der durch die NIT-Tabelle beschriebenen Serviceleistungen enthält. Jede Serviceleistung in einer Liste ist über 7 Bit indexiert. Der logische Schlüssel eines Service in der Datenbank enthält daher insgesamt 16 Bit: 4 Netz-Index-Bit, 5 Kanal-Index-Bit und 7 Service-Index-Bit.
Ein Ereignis eines Service wird mittels der 16 Bit identifiziert, die dieses Ereignis anzeigen (event_id-variable der Tabelle), zu denen die 16 Bit des logischen Schlüssels des zugehörigen Service hinzugefügt werden.
Die Struktur der Datenbank (ausschließlich der Ereignisse) ist entsprechend den folgenden Strukturen organisiert:
Die Variablen, deren Name den Ausdruck "Adresse" enthält, sind Zeiger zu den Speicherbereichen, die dem Start einer Datenstruktur entsprechen.
Die anderen Variablen entsprechen den aus dem Datenstrom extrahierten Informationen. Zum besseren Verständnis folgen auf diese Variablen die in dem Dokument (a) benutzten Namen in Klammern und in Anführungsstrichen.
Es sei bemerkt, daß die Listen der Netze, der Kanäle und der Serviceleistungen jede in Reihen organisiert sind, wobei jede Reihe einerseits aus acht Zeigern zu den Datenstrukturen des Netzes, des Kanals oder des Servicetyps und andererseits einen Zeiger zu einer möglichen Reihe enthält, die den übrigen Teil der Liste enthält. Dieser letzte Zeiger ist null, wenn keine andere Reihe besteht, d.h., wenn eine Reihe das letzte Element einer Liste enthält. Dieser letzte Zeiger ist nicht indexiert.
Die Reihen enthalten acht Elemente, die einer Potenz von zwei entsprechen. Das macht es möglich, die Reihe zu ermitteln, die einen gewünschten Zeiger enthält, in diesem Fall durch Maskierung oder Verdeckung der letzten drei Bit des Kanalindex.
Die Datenbank-Reihe enthält einen Zeiger auf die Reihe, die den ersten Teil der Liste von Netzen enthält.
Die Reihe von Netzlisten enthält die Zeiger auf die ersten acht Netze. Gemäß dem vorliegenden Ausführungsbeispiel gibt es wenigstens zwei Reihen von Netzlisten, die die vollständige Liste der Netze enthalten.
Die Netzreihe enthält die Informationen für ein bestimmtes Netz sowie einen Zeiger auf eine erste Reihe der Liste der zu diesem Netz gehörenden Kanäle.
Die Struktur der anderen Reihen ist ähnlich zu dem, was gerade festgestellt wurde. Außerdem ist es leicht, sie auf die Ereignisse und anderen Datentypen auszudehnen.
Gemäß einer anderen Ausführungsform sind die Anforderungen an die die Struktur des Netzwerks betreffenden Daten, die Kanäle und die Serviceleistungen Anforderungen vom permanenten Typ. Der Zweck dafür besteht darin, das Bild der Reihe in der Datenbank konstant aktualisiert zu halten.
In ihren Austauschvorgängen mit dem Verwaltungsmodul verwenden die Anwendungen logische Schlüssel. Diese werden durch das Modul in eine Speicheradresse übertragen, die der Lage entspricht, bei der die Information gespeichert ist. Sie bilden einen Teil von in den Tabellen der Anforderungen gespeicherten Parametern.
5 ist ein Diagramm der Datenbank des Verwaltungsmoduls in dem Fall der Existenz eines Netzes mit zwei Kanälen, wobei jeder Kanal selbst zwei Serviceleistungen enthält.
Die oben erwähnte Tabelle der Anwendungsanforderungen ergibt die Liste der durch die Anwendungen formulierten Anforderungen. Gemäß dem vorliegendem Beispiel ist die einzige Anforderung in dem Fortgang eine Anforderung vom permanenten Typ, die dafür vorgesehen ist, die Liste der auf einem Netz anwesenden Serviceleistungen wiederzugewinnen.
Im vorliegenden Fall sind, wenn zwei Kanäle in dem Netz vorliegen, zwei Elementaranforderungen erforderlich, um die Anwendungsanforderung umzusetzen: eine Elementaranforderung je Liste von Serviceleistungen oder dergleichen je Kanal wird in die Tabelle der Elementaranforderungen geschrieben.
In der Figur sind die jeder Elementaranforderung entsprechenden Filter an der linken Seite der Tabelle der Elementaranforderungen zu finden.
Es wird angenommen, daß in dem in 5 dargestellten Zeitpunkt die Servicelisten zum ersten Male eingegeben worden sind. Bei der permanenten Art der Anwendungsanforderungen werden die entsprechenden Filter sowie die Inhalte der Datenbank für diese Anforderung nach der ersten Gelegenheit aufrechterhalten, bei der die erwarteten Daten gewonnen werden.
Die Ziffern, die die eine Liste verbindenden Zweige und ein Element in dieser Liste identifizieren, entsprechen dem Index (logischer Schlüssel) dieses Elementes in der Liste.
Die Anwendung versucht nun, die Liste der Ereignisse im Ablauf des Netzes zu erhalten. Wenn ein Ereignis je Service im Gange ist, so macht dieses es notwendig, die entsprechende "Current/Next EIT"-Tabelle ("Ereignis-Informations-Tabelle") zu filtern. In dem übrigen Teil der Darstellung wird angenommen, daß eine derartige Tabelle tatsächlich für jeden Service gesendet wird, das heißt, daß die Markierungen EIT_present_following_flag der Service-Beschreibungstabelle für diese Serviceleistungen den Wert 1 haben.
Die durch die Anwendung gelieferte Anforderung enthält für einen bestimmten Service die folgenden Parameter:

– einen Anforderungs-Identifizierer,
– den Typ der Anforderung,
– den logischen Schlüssel des relevanten Service,
– eine Speicheradresse eines Pufferspeichers, der dafür vorgesehen ist, die demultiplexierten Daten von dem SI-Modul zu empfangen.

Es wird zunächst angenommen, daß die Datenbank keine Datenwörter für die im Gange befindlichen Ereignisse oder die nächsten Ereignisse enthält. Das bedeutet, daß die Tabelle der Elementaranforderungen keine Elementaranforderung für diese Daten enthält.
Die Programmführer-Anwendung sucht zum Beispiel nach dem laufenden und dem nächsten Ereignis des zweiten Servives ("1"), das zu dem ersten Kanal ("0") des ersten Netzes ("0") gehört. Auf diese Anforderung folgt ein Befehl durch den Benutzer, eine Information über das im Gange befindliche Programm und das unmittelbar nach dem im Gange befindlichen Programm eines bestimmten Service wiederzugeben, zum Beispiel Kanal+ (Französischer Fernsehkanal).
Der logische Schlüssel des betroffenen Service ist dann:
0000 00000 000001
Eine entsprechende Anwendungsanforderung wird zu dem SI-Modul übertragen. Diese Anforderung ist vom permanenten Typ. Wenn innerhalb des Rahmens dieses Beispiels nur das laufende und das nächste Ereignis eines einzigen Service durch die Anwendung angefragt werden, ist diese Anforderung elementar und sollte durch den SI-Modul nicht weiter durchbrochen werden. Die Elementaranforderung wird in die entsprechende Tabelle der Anforderungen geschrieben.
Zusätzlich programmiert der SI-Modul ein Filter des Demultiplexers derart, daß die Filterung der EIT-Tabelle für diese Anforderung richtig durchgeführt wird. Der Wert des PID der die "laufender/nächster"-EIT-Tabellen enthaltenden Pakete beträgt 0×0012, entsprechend dem Dokument (a). Die Werte des Service-Identifizierers ("service_id"), des Kanal-Identifizierers ("transport_stream_id" und "original_network_id"), die benötigt werden, um zu ermitteln, welche der gesendeten Tabellen die richtige EIT-Tabelle sind, sind aufgrund des logischen Schlüssel in der Datenbank verfügbar. Der Zustand der Elementaranforderung in der Tabelle von Elementaranforderungen wird darüberhinaus auf den "Warte"-Zustand gesetzt.
Sobald die richtige EIT-Tabelle detektiert worden ist, extrahiert der SI-Modul aus den Paketen die Werte der Daten, die in ihrer internen Datenbank gespeichert werden sollen. Gemäß dem vorliegenden Ausführungsbeispiel sind dieses die Daten, die in der oben beschriebenen Datenstruktur "Laufendes nächstes Ereignis" erscheinen. Der SI-Modul benachrichtigt die Anforderungsanwendung über die Anwesenheit der Daten und kopiert sie in den im voraus durch die Anwendung reservierten Pufferspeicher. In der Datenbank wird der "Laufende nächste Ereignisadresse"-Adressenzeiger der Servicedatenstruktur, die dem durch den logischen Schlüssel angezeigten Weg entspricht, mit der Speicheradresse programmiert, die der "laufender nächster Ereignisadressen"-Struktur entspricht. Der Zustand der Elementaranforderung in der Tabelle von Elementaranforderungen schaltet um von "Warten" auf "Fertig".
Es sei bemerkt, daß es wenigstens ein laufendes Ereignis und ein nächstes Ereignis je Service gibt. Es besteht daher in diesem besonderen Fall kein Grund, die Struktur der "Laufendes nächstes Ereignis"-Datenstruktur zu indizieren, da sie bereits durch den logischen Schlüssel identifiziert ist, der zu dem Service führt, von dem er abhängt.
Dieser Fall wäre anders, wenn die Inhalte der EIT-Tabellen, die die chronologischen Reihen von Ereignissen enthalten, geladen würden. In diesem Fall könnte sich eine Indexierung als notwendig erweisen.
Zur einen oder zur anderen Zeit wird die Anwendung ihre Anforderung löschen, zum Beispiel auch einen Befehl durch den Benutzer, den Programmführer wiedereinzuschalten. Wenn in diesem Fall in dem Verlauf keine Anwendungsanforderungen mehr bestehen, die Bezug nehmen auf die Elementaranforderung für das laufende/nächste Ereignis, setzt der SI-Modul die Filter des Demultipelxers frei und schreibt den vorliegenden Wert des Systemtaktes in das "Daten"-Feld der Tabelle der Grundanforderungen. Der Zustand der Anforderung wird "nicht-aktualisiert", unter der Annahme, daß die Daten tatsächlich vorher in der Datenbank demultiplexiert und gespeichert wurden, was hier der Fall ist. Im entgegengesetzten Fall würden sie einfach aus der Tabelle gelöscht.
Gemäß einer anderen Ausführungsform erzeugt der Verwaltungsmodul selbst bestimmte Anforderungen für die Struktur der Netze (insbesondere die Liste der Netze und der zugehörigen Listen der Kanäle) und hält sie permanent aufrecht.
Es sei bemerkt, daß die Erfindung nicht nur auf die Übertragung von Daten über Satelliten, Hochfrequenzstrecken oder Kabel beschränkt ist, sondern in jedem System durchgeführt werden kann, in dem Daten oder Pakete von Daten periodisch in dem Datenstrom erscheinen. Das ist insbesondere für aufgezeichnete oder zwischengespeicherte Datenströme der Fall.
Darüberhinaus ist es, wenngleich die angegebenen Beispiele sich insbesondere auf Servicedaten beziehen, klar, daß die Erfindung nicht auf diesen Datentyp beschränkt ist. Sogenannte private Daten können zum Beispiel in einer analogen Weise verarbeitet werden.

Claims

Verfahren zur Verwaltung von Serviceinformationen in einem digitalen Fernsehsystem bezüglich eines Empfängers des Systems mit folgenden Schritten: – Programmierung von Verarbeitungsmitteln (5) für die selektive Extrahierung von Informationen aus einem digitalen Datenstrom, dadurch gekennzeichnet dass, es die folgenden Schritte beinhaltet: – Speicherung von wenigstens einigen der extrahierten Informationen in einer Datenbank durch Markierung der gespeicherten Informationen als aktualisiert, – Markierung eines gespeicherten Anteils der gespeicherten Informationen als nicht zu aktualisieren, als Reaktion auf die Verarbeitungsmittel (5), bezogen auf die Extrahierung dieses Informationsanteils, der deprogrammiert wurde.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass nach der Formulierung einer Anforderung einer Extrahierung eines Informationsanteils durch eine Anwendung die Programmier- und Speicherschritte folgendermaßen durchgeführt werden: – wenn der angeforderte Informationsanteil in der Datenbank anwesend ist, Übertragung dieses Informationsanteils zu einer Anwendung, Programmierung der Mittel zur selektiven Extrahierung dieses Informationsanteils aus dem Datenstrom und Aktualisierung des Informationsanteils in der Datenbank, gefolgt von der Extrahierung dieses Informationsanteils aus dem Datenstrom, – wenn der angeforderte Informationsanteil von der Datenbank abwesend ist, Programmierung der Mittel zur selektiven Extrahierung und Speicherung des Informationsanteils in der Datenbank des Dekoders, gefolgt von seiner Extrahierung aus dem Datenstrom.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Mittel zur selektiven Extrahierung einen Demultiplexer enthalten.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Markierung eines gespeicherten Informationsanteils als aktualisiert werdend über die Periode wirksam ist, die auf diese Extrahierung folgt und während der die Mittel der selektiven Extrahierung zum Extrahieren eines neuen Wertes daraus programmiert werden.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Markierung eines gespeicherten Informationsanteils als nicht zu aktualisieren nach ihrer Extrahierung aus dem Datenstrom in Verbindung mit einer Deprogrammierung der Mittel zum Suchen nach diesem Informationsanteil durchgeführt wird.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Markierung eines Informationsanteils als "nicht zu aktualisieren", die Zuordnung dieses Informationsanteils zu den Daten enthält, auf die die Mittel zur selektiven Extrahierung entsprechend dem Informationsanteil deprogrammiert wurden.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass dann, wenn die Datenbank des Empfängers gesättigt ist, als "nicht zu aktualisieren" markierte Informationen aus Altersgründen gelöscht werden.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Markierung eines Informationsanteils mit diesem Informationsanteil zu einer Anwendung kommuniziert wird, die den Informationsanteil angefordert hat.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass ein auf einem Schirm durch eine Anwendung angezeigter Informationsanteil, der als "nicht zu aktualisieren" markiert ist, als "nicht aktualisiert" optisch zu erkennen ist.
Empfänger in einem digitalen Fernsehsystem, in dem Serviceinformationen und insbesondere Programmführer-Informationen mit folgenden Merkmalen übertragen werden, wobei der Empfänger beinhaltet: einem Datenstrom-Demultiplexer (5), wobei der Demultiplexer programmierbare Filter zur selektiven Extrahierung von Informationen aus dem Datenstrom enthält und der Empfänger durch folgende Merkmale gekennzeichnet ist, wobei er beinhaltet: – einen Speicher (12) mit einer Datenbank des Empfängers, wobei die Datenbank vorher extrahierte Informationen enthält, – Mittel (23) zur Markierung der Informationen der Datenbank als "aktualisiert" oder "nicht zu aktualisieren", wobei ein Informationsanteil als aktualisiert markiert wird, wenn er wenigstens das erste Mal in der Datenbank gespeichert wird, und als "nicht zu aktualisieren" markiert wird, als Reaktion auf den Demultiplexer (5) bezüglich des Anteils der deprogrammiert wurde.
Gerät nach Anspruch 10, dadurch gekennzeichnet, dass die Markierung als aktualisiert, oder als nicht zu aktualisieren, in Abhängigkeit von der Programmierung des Demultiplexers (5) erfolgt.
Gerät nach einem der Ansprüche 10 oder 11, dadurch gekennzeichnet, dass es außerdem einen Taktgeber enthält, der für die Markierung der Informationen mit "nicht zu aktualisieren" benutzt wird.