RADIO MIT ANZEIGE FÜR TEXTINFORMATIONEN-DIE AUF WEITERE TEXTINFORMATIONSOBJEKTEN VERWEISEN
Beschreibung
5 Die vorliegende Erfindung bezieht sich auf Radios und insbesondere auf solche, die eine Anzeige aufweisen, um Textinformationen anzeigen zu kRnnen.
Es existieren bereits textbasierte Nachrichtendienste für 10 digitale Rundfunksysteme, bei denen ein Benutzer eines Radios Textnachrichten an einer Anzeige des Radios ablesen kann. Hierbei werden in dem Rundfunksignal zusammen mit den Audioinformationen für das Radio weitere Informationen, nämlich Textinformationen, ausgestrahlt. Ein HRrfunkstan- 15 dard, der diese Übertragung von Audio-Informationen und Textinformationen nebeneinander in einem Übertragungskanal bzw. Rundfunksignal ermRglicht, ist beispielsweise der DAB- Standard (DAB = Digital Audio Broadcasting) .
20 Textbasierte Nachrichtendienste nutzen diese MRglichkeit des digitalen Rundfunks jetzt schon aus, um an Endgeräte Textnachrichten auszustrahlen. Beispielsweise senden Rundfunkanstalten neben dem eigentlichen Rundfunkprogramm, also den Audio-Informationen, Textinformationen, die auf der An- 25 zeige des Rundfunkempfängers des Benutzers angezeigt werden kRnnen, wie z.B. den Namen des Rundfunkprogramms oder aber aktuelle Nachrichten oder dergleichen. Über die Art und die Reihenfolge der Informationen entschied der Programmverantwortliche. Bisherige textbasierte Nachrichtendienste ermRg- 30 lichten es einem Benutzer hierbei nur beschränkt Einfluss auf die Auswahl der Textnachrichten zu nehmen, die auf seinem Display angezeigt wurden, wie z.B. durch Wechseln des Programms .
Es ist deshalb die Aufgaben der vorliegenden Erfindung ein Textinformationsdienstschema bereitzustellen, das einem Benutzer eine effektivere MRglichkeit bietet, mittels eines Radios an gewünschte Textinformationen über den Rundfunk zu gelangen.
Diese Aufgabe wird durch einen Rundfunkempfänger gemäß Anspruch 1 und Verfahren zum Steuern eines Rundfunkempfängers gemäß Anspruch 16 gelRst.
Eine Erkenntnis der vorliegenden Erfindung besteht darin, dass ein Benutzer eines Rundfunkempfängers bedeutend schneller an Textinformationen gelangt, wenn in einem in dem Rundfunksignal umfassten Textinformationsobjekt, das auf der Anzeige des Rundumrundfunkempfängers gerade angezeigt wird, ein Verweis auf ein anderes Textinformations- Objekt in dem Rundfunksignal enthalten ist, und es dem Be¬ nutzer ermRglicht wird, durch einfache Bedienung einer Be- nutzer-Auswahleinrichtung zu veranlassen, dass die anzuzeigenden Textinformationen von den Textinformationen des aktuellen Textinformationsobjekts auf die Textinformationen des Textinformationsobjekts geändert werden, auf das durch das aktuelle Textinformationsobjekt verwiesen wird. Der Zu- satzaufwand ist hierbei sehr begrenzt, da bei heutigen
Rundfunkempfängern zumeist eine "unbelegte" Taste, die nur in speziellen Situationen der Benutzung des Rundfunkempfängers eine zugewiesene Funktion hat und somit belegt ist, existiert und insoweit als Benutzer-Auswahleinrichtung ver- wendet werden kann.
Gemäß einem speziellen Ausführungsbeispiel der vorliegenden Erfindung werden die Textinformationsobjekte in dem Rund-
funksignal aufeinanderfolgend neben anderen Informationen in dem Rundfunksignal, wie z.B. den Audio-Informationen o- der aber anderen Informationen, von einem Rundfunksender ausgestrahlt, wobei jedes Textinformationsobjekt eine Ob- jekt-ID aufweist. Verweist ein Textinformations-Objekt auf ein anderes Textinformationsobjekt, so unterscheiden sich deren Objekt-IDs. Das Einführen der Objekt-IDs ermRglicht es, die Textinformationsobjekte in dem Rundfunksignal inhaltlich in Gruppen einzuteilen und sie für Empfänger er- kennbar zyklisch wiederholt zu übertragen und dabei zu aktualisieren. Ein Rundfunkempfänger kann somit ohne inhaltlich den Inhalt der Textinformations-Objekte, d.h. die Textinformationen, analysieren zu müssen, erkennen, ob ein bestimmtes soeben empfangenes Textinformationsobjekt, ob- wohl es sich von dem aktuellen angezeigten unterscheidet, den selben Gegenstand betrifft wie ein vorher bereits empfangenes und somit eine Aktualisierung darstellt, oder ob das aktuell empfange Textinformationsobjekt inhaltlich einen vRllig anderen Gegenstand betrifft. Eine Aktualisierung kann auf einfache Weise vorgenommen werden, indem die Ob- jekt-ID eines auf das aktuell angezeigte Textinformations- Objekt unmittelbar oder nicht unmittelbar folgenden Textinformationsobjekts in dem Rundfunksignal mit der Objekt-ID des aktuell angezeigten verglichen wird. Abhängig davon, ob der Vergleich die Identität bei den Objekt-IDs ergibt, wird die Aktualisierung vorgenommen oder nicht.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann die Aktualisierung für die Rundfunkempfänger unaufwen- diger gestaltet werden, indem die Textinformationsobjekte neben der Objekt-ID noch einen Revisionsindex aufweisen, der Auskunft darüber gibt, welche Version der Textinformationen, die dieser Objekt-ID zugeordnet sind, dieses Text-
informationsobjekt betrifft. Ein Radioempfänger ist folglich nicht gezwungen, blind eine Aktualisierung immer dann vorzunehmen, wenn in dem Rundfunksignal wieder ein Textinformationsobjekt ausgestrahlt wird, dessen Objekt-ID mit der Objekt-ID des aktuell angezeigten Textinformations- Objekts übereinstimmt. Vielmehr wird die Aktualisierung noch davon abhängig gemacht, ob sich der Revisionsindex geändert hat. Bildaufbau und andere Aufbereitungsmechanismen unterbleiben folglich, wenn das neue Textinformationsobjekt mit selbiger Objekt-ID sich inhaltlich gar nicht von dem bereits angezeigten unterscheiden kann, da es dieselbe Version der Textinformationen zu dieser Objekt-ID betrifft. Der Zusatzaufwand durch die Belastung des Übertragungskanals durch den Revisionsindex in jedem Textinformationsob- jekt ist vergleichsweise gering.
Die Aktualisierung kann darüber hinaus weiter benutzerfreundlicher gestaltet werden, wenn zwischen den einzelnen Textinformations-Objekten unterschieden wird. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung existieren Menüobjekte, Listenobjekte und reine Textobjekte. Jedes Textinformationsobjekt ist durch einen Objekt-Deskriptor bzw. eine Objekt-Typ-ID einem dieser Typen zugeordnet. In dem Fall, dass es sich um Menü- oder Listen-Objekte han- delt, führt der Rundfunkempfänger die Aktualisierung unmit¬ telbar, d.h. ohne eine Benutzerinteraktion, durch, während anderenfalls die Aktualisierung davon abhängig gemacht wird, ob der Benutzer sein Einverständnis bzw. seine Zustimmung zur Aktualisierung erteilt, damit er nicht wegen einer eventuell nur geringfügigen Aktualisierung beim Lesen eines zusammenhängenden längeren Textes jäh unterbrochen wird.
Gemäß einem weiteren Ausführungsbeispiel ist es ferner vorgesehen, dass die Anzeige bei der Aktualisierung in dem Fall, dass die Menge an Textinformationen des neuen Textinformationsobjekts grRßer als eine anzeigbare GrRße ist, ei- nen Ausschnitt der Textinformationen dieses neuen Textinformationsobjekts anzeigt, der sich zumindest teilweise mit einem Ausschnitt überschneidet, den die Anzeige vor der Aktualisierung von dem alten Textinformationsobjekt zeigte. Insbesondere bei Listen- und Menü-Objekten ergibt dies den Vorteil, dass der Benutzer sich nach erfolgter Aktualisierung nicht neu in der Liste bzw. dem Menü orientieren muss, und dass er aber trotzdem beim Weiterscrollen die Aktualisierung erfährt.
Verfügt der Rundfunkempfänger bzw. das Radio über einen Cache-Speicher zum zeitweiligen Speichern von bereits empfangenen Textinformationsobjekten, so ist es ihm mRglich, bei der Änderung der anzuzeigenden Textinformationen von Textinformationen des aktuellen Textinformations-Objekts auf Textinformationen des Textinformationsobjekts mit anderer Objekt-ID, auf das das aktuelle Textinformations-Objekt verweist, zunächst in dem Cache-Speicher nachzuschlagen, ob sich ein Textinformationsobjekt mit dieser Objekt-ID nicht bereits im Cache-Speicher befindet. Der Benutzer gelangt somit schneller zu den neuen Textinformationen des neuen
Textinformationsobjekts und muss nicht die Zeitdauer abwarten, bis ein Textinformationsobjekt mit der gewünschten Objekt-ID, auf das das aktuelle Textinformationsobjekt verweist, in dem Rundfunksignal wieder ausgestrahlt wird.
Damit der Benutzer beim Durchsehen des Menüs bzw. Scrollen durch dasselbe gleich weiß, welche Menüoptionen auf Objekt- IDs verweisen, für die ein Textinformationsobjekt im Cache-
Speicher gespeichert ist, kann ein Cache-Treffer- Identifizierer vorgesehen sein, der zunächst im Cache- Speicher nach Textinformationsobjekten für alle Objekt-IDs nachschlägt, die den Menüoptionen des Menü-Objekts zugeord- net sind, und dann durch Modifizieren der anzuzeigenden Textinformationen dafür sorgt, dass die Menüoptionen, für die Textinformationsobjekte in dem Cache-Speicher vorhanden sind, für den Benutzer sichtbar von denjenigen unterscheidbar sind, für die noch keine Textinformationsobjekte im Ca- che-Speicher vorhanden sind. Dies beschleunigt für einen Benutzer das Zappen durch die Menüs, d.h. den Knoten des Objektbaumes, gemäß dem die Textinformationsobjekte ange¬ ordnet sind.
Gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung unterstützt ein Rundfunkempfänger eine Favoritenfunktionalität. In einem Favoritenspeicher sind hierzu eine oder mehrere Objekt-IDs von Textinformationsobjekten gespeichert, die Gegenstände betreffen, die den Benutzer wie- derholt, beispielsweise jeden Morgen auf der Fahrt zur Arbeit, interessieren und die er durch Bedienen einer Favoriten-Abfrage-Einrichtung abrufen kann. Um nun zu verhindern, dass der Benutzer Objekt-IDs zu den Favoriten hinzufügt, die aber nicht auf längere Zeit hin einem Textinformations- objekt mit diesem Gegenstand zugeordnet sind, wie z.B. eine einmalige Nachrichtenmeldung, sondern die anschließend wieder einem Textinformationsobjekt mit einem inhaltlich ande¬ ren Gegenstand zugewiesen werden, umfasst ein Textinformationsobjekt beispielsweise ein Statisch-Flag. Die Zu- Favoriten-Hinzufügen-Funktionalität des Rundfunkempfängers wird nur aktiviert, wenn das Statisch-Flag gesetzt ist, sonst nicht, wodurch sinnloses Hinzufügen zufällig zugewiesener Objekt-IDs vermieden wird.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf beiliegende Zeichnungen näher erläutert. Es zeigen:
Fig. 1 ein Übersichtsblockschaltbild mit Sender und Empfänger zu Veranschaulichung eines Textinfor- mationsrundfunkdienstes gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 2 eine exemplarische Baumstruktur, in der die Textinformationsobjekte des Dienstes von Fig. 1 angeordnet sind;
Fig. 3 eine schematische Zeichnung zur Veranschaulichung des Aufbaus der Textinformationsobjekte nach dem Dienst von Fig. 1 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 4a-e schematische Zeichnungen zur Veranschaulichung des Aufbaus exemplarischer Textinformationsobjekte oder von Teilen derselben durch NML- und UTF-8-Codes;
Fig. 5 eine schematische Zeichnung zur Veranschaulichung der seriellen und zyklischen Übertragung der Textinformationsobjekte in dem Rundfunksignal von Figur 1;
Fig. 6a-d exemplarische Bildschirmanzeigen auf der Anzeige des Rundfunkempfängers von Fig. 1;
Fig. 7 ein Flussdiagramm eines Anzeige-Aktualisierungs-Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 8 ein Flussdiagramm eines Cache-Aktualisierungs- Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 9 eine schematische Skizze einer exemplarischen Baumstruktur von Textinformationsobjekten zur Veranschaulichung der Cache-Verdrängungs-Strategie gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 10 ein Flussdiagramm eines Scroll-Prozesses gemäß einem Ausführungsbeispiels der vorliegenden Erfindung;
Fig. 11 ein Flussdiagramm eines Menü-Auswahl-Prozesses gemäß einem Ausführungsbeispiels der vorliegenden Erfindung;
Fig. 12 ein Flussdiagramm einer Objekt-Pfad-Aktualisierung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung; und
Fig. 13 ein Flussdiagramm eines Eine-Hierarchie-Ebene- Zurück-Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung; und
Fig. 14 ein Flussdiagramm eines Favoriten-Hinzufügung- Prozesses gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
Die vorliegende Erfindung wird nachfolgend bezugnehmend auf die Figuren vor dem Hintergrund eines Textinformationsrund- funkdienstes beschrieben, wie er in Figur 1 im Aufbau ge- zeigt ist. Radios gemäß der vorliegenden Erfindung kRnnten jedoch auch im Rahmen anderer Textinformations- Rundfunksysteme Verwendung finden. Bei in unterschiedlichen Figuren gleichermaßen vorkommenden Elementen sind für diese gleiche Bezugszeichen verwendet worden, wobei eine wieder- holte Beschreibung der Elemente vermieden wurde.
Der Textinformationsrundfunkdienst nach Fig. 1, der im Folgenden auch manchmal als "NewsService Journaline" bezeichnet wird, wird in Fig. 1 an einem Paar eines Rundfunksen- ders 10 und eines Rundfunkempfängers 12 veranschaulicht. Der Rundfunksender 10 ist eine stationäre zentrale Rundfunkstation, die über eine Antenne 14, wie z.B. einen Sendemast, Rundfunksignale 16 an eine Vielzahl von Rundfunkempfängern, wie den Rundfunkempfänger 12, ausstrahlt. Das Rundfunksignal 16 umfasst neben Audio-Informationen, die unterschiedliche Rundfunkprogramme betreffen kRnnen, Textinformationen, die für die Rundfunkempfänger bzw. Endgeräte 12 und deren Benutzer im Rahmen des Textnachrichtenrundfunkdienstes bestimmt sind. Das Rundfunksignal 16 ent- spricht beispielsweise dem DAB-Standard.
Der Rundfunksender 10 umfasst neben anderen Komponenten, die für die Audio-Übertragung bzw. für die Übertragung der Audio-Informationen bestimmt sind und hier aus Übersicht- lichkeitsgründen nicht gezeigt sind, einen Speicher 18 und eine Einbindungseinrichtung 20. Der Speicher 18 enthält eine Liste 22 von Textinformationsobjekten. Wie es später noch detaillierter beschrieben werden wird, umfasst jedes
Textinformationsobjekt zumindest eine Objekt- Identifikationsnummer bzw. Objekt-ID sowie den eigentlichen Textinhalt, d.h. die Textinformationen. Daneben umfassen Textinformationsobjekte je nach ihrem Typ auch weitere In- formationen, wie es ebenfalls detaillierter im Folgenden beschrieben werden wird. Die Textinformationsobjekte in der Liste 22 werden von einem Dienstbetreiber gepflegt und aktualisiert. Er trifft die Auswahl an Themen, die die Objekte betreffen, die Struktur, in der die Objekte geordnet sind, und die Zeitdauer, in der dieselben zyklisch wiederholt ausgestrahlt werden.
Die Einbindungseinrichtung 20 ist mit dem Speicher 18 verbunden, um die Textinformationsobjekte von dem Speicher 18 auszulesen und in das Rundfunksignal einzubinden, um dasselbe über die Antenne 14 als das Rundfunksignal 16 auszustrahlen. Die Auslese bzw. Ausstrahlung durch die Einbindungseinrichtung 20 erfolgt für jedes Textinformationsobjekt zyklisch, so dass insgesamt alle Textinformations- Objekte zyklisch nacheinander über in dem Rundfunksignal 16 ausgestrahlt werden, und zwar mit unterschiedlichen Zyklus- Wiederholzeiten, wie es später noch bezugnehmend auf Figur 5 detaillierter beschrieben wird.
Ein Rundfunkempfänger 12 gemäß dem vorliegenden Ausfüh- rungsbeispiel umfasst eine Empfangseinrichtung 24, eine Steuereinrichtung 26, einen Lautsprecher 28, eine Anzeige bzw. ein Display 30, einen Speicher 32, ein erstes Bedienfeld 34 und ein zweites Bedienfeld 36. Die Empfangseinrich- tung 24 ist mit einem Dateneingang mit einer Antenne 38 verbunden, um über dieselbe 38 das Rundfunksignal 16 zu empfangen. Die Empfangseinrichtung 24 ist geeignet ausgebildet, um aus dem Rundfunksignal 16 die Audio-
Informationen und die Textinformationen zu extrahieren und über ihren Datenausgang an die Steuereinrichtung 26 weiterzuleiten.
Die Steuereinrichtung 26, wie z.B. ein Prozessor oder dergleichen, leitet zunächst die Audio-Informationen an den Lautsprecher 28 weiter. Hierbei wird schon eine Auswahl getroffen worden sein unter einem Angebot verschiedener Audioinhalte bzw. Rundfunkprogramme. Die Weiterleitung ausge- wählter Audiosignale kann entweder über eine interne Leitung zu einem integrierten Lautsprecher 28 geschehen, wie es in Figur 1 mit durchgezogenen Linien dargestellt ist, oder über einen Lautsprecheranschluss oder durch Ausgabe geeigneter Audiosignale an einen externen Lautsprecher 40 geschehen, der extern zu dem Rundfunkempfänger 12 angeordnet ist, wie es mit gepunkteten Linien in Figur 1 gezeigt ist.
Über das Bedienfeld 36, das beispielsweise lediglich einen Kippschalter mit zwei Kipppositionen bzw. Kippstellungen umfasst, kann der Benutzer des Rundfunkempfängers 12 beispielsweise von einem Rundfunkprogramm zu dem anderen wechseln. Das Bedienfeld 36 ist hierzu mit der Steuereinrichtung 26 verbunden, die wiederum ausgebildet ist, um je nach vorliegen einer jeweiligen Kippstellung das aktuelle Programm und damit die Audiosignale an den Lautsprecher 28 bzw. 40 zu ändern.
Weitere Steuersignale erhält die Steuereinrichtung 26 von dem Bedienfeld 34. Das Bedienfeld 34 besteht beispielsweise aus vier KnRpfen, einem mit einem Pfeil nach unten, einem mit einem Pfeil nach oben, einem mit einem Pfeil nach links und einem anderen mit einem Pfeil nach rechts, oder aus
zwei Kippschaltern, die senkrecht zueinander angeordnet sind, oder einem rautefRrmigen Kippschalter, wobei jedoch auch andere MRglichkeiten für das Bedienfeld 34 bestehen. Anstatt eines Bedienfeldes mit KnRpfen kRnnte beispielswei- se eine Spracheingabe vorgesehen sein. Das Bedienfeld 34 ist dazu vorgesehen, dass der Benutzer über das Bedienfeld 34 der Steuereinrichtung 26 Steuersignale zuführen kann, mit denen derselbe auf eine Weise, wie sie im Folgenden näher erRrtert werden wird, Einfluss darauf nehmen kann, wel- ehe Textinformationen die Steuereinrichtung 26 als die anzuzeigenden Textinformationen an die Anzeige 30 weiterleitet. Die Textinformationen, die die Steuereinrichtung 26 an die Anzeige 30 weiterleitet, extrahiert dieselbe aus den Textinformationsobjekten, die in dem Rundfunksignal 16 ent- halten sind, und durch die Empfangseinrichtung 24 aus dem Rundfunksignal extrahiert werden. Die Textinformationsan- zeigefunktionalität ist von der Widergabe der Audioinformationen vRllig losgelRst, so dass bei Betätigung des Bedienfeldes 34 die Tonwiedergabe bzw. das aktuell über den Laut- Sprecher 28 oder 40 wiedefgegebene Programm nicht unterbro¬ chen wird.
Der Rundfunkempfänger 12 von Figur 1 umfasst ferner in dem Speicher 32, der im Folgenden auch als Cache-Speicher be- zeichnet wird, und beispielsweise ein RAM ist, eine Liste bereits empfangener Textinformationsobjekte 42, eine Ob¬ jekt-Pfad-Liste 44 von Objekt-IDs, deren Inhalt und Bedeutung im Folgenden noch näher erRrtert werden wird, und eine Liste bzw. ein Array von Objekt-IDs, die als Favoritenliste 46 bezeichnet wird, deren Bedeutung ebenfalls im Folgenden näher spezifiziert werden wird.
Durch den „NewsService Journaline" kann der Benutzer des Radios bzw. Rundfunkempfängers 12 auf einfache Weise und sofort auf Informationen gemäß ihrem oder seinem augenblicklichen Interessentyp zugreifen. Die Informationen lie- gen in einfacher Textform vor. Die Textinformationen sind in den Textinformationsobjekten enthalten. Es existieren verschiedene Textinformationsobjekte, die nach ihrem Typ unterschieden werden kRnnen. Da gibt es einerseits Menü- Objekte, Textobjekte und Listenobjekte. Bevor näher auf den Aufbau der einzelnen Objekttypen eingegangen wird, soll bezugnehmend auf Figur 2 kurz deren hierarchische Struktur veranschaulicht werden.
Figur 2 veranschaulicht, wie die Textinformationsobjekte gemäß dem vorliegenden Ausführungsbeispiel in einer Baumstruktur angeordnet sind. Figur 2 zeigt ein exemplarisches Beispiel eines Objektbaumes 50 aus Textinformationsobjekten. Die Textinformationsobjekte sind in Figur 2 mit eckigen Rechtecken bzw. angerundeten Rechtecken angezeigt. Je- des Textinformationsobjekt ist mit einem "M" , "T" und "L" für Menü-, Text- bzw. Listen-Objekt beschriftet. Wie bereits erwähnt, ist jedem Textinformationsobjekt eine Objekt-ID zugeordnet. Lediglich exemplarisch wird davon ausgegangen, dass dem Textinformationsobjekt an der Wurzel des Objektbaumes 50 die feste Objekt-ID 0 zugewiesen ist, d.h. 0x0000. Dieses Haupt-Menü-Objekt, angezeigt mit 52, befindet sich in der ersten Hierarchieebene des Objektbaums 50 und wird von der Steuereinrichtung 26, sobald es nach dem Einschalten des Radios 12 über das Rundfunksignal 16 ausge- strahlt worden ist, zu aller erst an die Anzeige 30 zur An¬ zeige weitergeleitet. Das Hauptmenü-Objekt 52 wird folglich zu Beginn gezeigt, wenn der Benutzer das Radio oder die „NewsServcie Journaline"-Funktionalität des Radios 12 das
erste Mal einschaltet, ohne dabei eine spezifische Objekt- ID abzufordern.
In dem Ausführungsbeispiel von Figur 2 ist das Textinforma- tionsobjekt an der Wurzel des Objektbaumes 50 ein Menü- Objekt. Wie es im Folgenden noch näher erRrtert werden wird, umfasst jedes Menü-Objekt in seinen Textinformationen mehrere Menü-Optionen bzw. Menüpunkte, denen jeweils ein Verweis auf ein Textinformationsobjekt einer nächsthRheren Hierarchieebene in Form einer Objekt-ID zugeordnet ist. In dem vorliegenden exemplarischen Beispiel umfasst das Menü- Objekt 52 vier Menü-Optionen und damit vier Verweise auf andere Textinformationsobjekte, wie es mit Pfeilen 54 angedeutet ist. Insbesondere verweist in dem vorliegenden Bei- spiel das Menü-Objekt 52 auf zwei weitere Menü-Objekte 56 und 58 sowie zwei Text-Objekte 60 und 62, die all vier die Textinformationsobjekte der zweiten Hierarchieebene bilden. Während die Menü-Objekte 56 und 58 der zweiten Hierarchieebene ihrerseits wiederum Verweise auf weitere Textinforma- tionsobjekte aufweisen, angedeutet durch Pfeile 64 und 66, umfassen Textobjekte, und somit auch die Textobjekte 60 und 62, keinen Verweis auf ein anderes Textinformationsobjekt. Sie enthalten lediglich Textinformation. Die Text-Objekte "T" bilden somit die Blätter des Objektbaumes 50. Selbiges gilt für Listen-Objekte „L" .
Wie es in Figur 2 dargestellt ist, bildet somit der exemplarische Objektbaum 50 von Figur 2 vier Hierarchieebenen, wobei jedoch auch jegliche andere Anzahl denkbar ist. Fer- ner ist es denkbar, dass zwei Menü-Objekte (mRglcherweise unterschiedlicher Hierarchieebenen) auf das selbe Textinformations-Objekt verweisen, wie es auch in Figur 2 bei
Pfeilen 64 und 66 und dem Textinformations-Objekt 68 in der dritten Hierarchieebene gezeigt ist.
Die Anzahl an Hierarchieebenen der Baumstruktur kann auf einen bestimmten Wert, wie z.B. 20, begrenzt sein, damit empfangsseitig bei den Rundfunkempfängern 12 der Speicherplatz zur Speicherung des Datenpfads 44 geeignet dimensioniert werden kann.
Aus der Beschreibung von Fig. 2 wird klar, dass jedes Textinformationsobjekt, im Folgenden auch manchmal einfach als Objekt bezeichnet, von zumindest einem Menü-Objekt referen- ziert sein muss, bzw. dass zumindest ein Menü-Objekt einen Verweis auf dasselbe aufweisen muss. Lediglich für das Ob- jekt 52 an der Wurzel des Objektbaumes 50 muss kein Textinformationsobjekt existieren, das auf das selbe verweist. Freilich wäre dies aber mRglich.
Die Textinformationsobjekte sind demnach wie in Fig. 2 strukturiert. All diese Textinformationsobjekte in dem Objektbaum 50 sind in der Liste 22 in dem Speicher 18 des Rundfunksenders 10 gespeichert. Sollte aus irgendeinem Grunde der Rundfunksender 10 den „NewsService Jouranline"- Dienst nicht anbieten kRnnen, kann das Objekt an der Wurzel des Objektbaums 50 auch ein Textobjekt sein, so dass der
Objektbaum 50 lediglich eine Hierarchieebene aufweist, wobei die Textinformationen in diesem Textobjekt beispielsweise auf den vorübergehenden Ausfall des Dienstes hinweisen.
Fig. 3 zeigt ein Ausführungsbeispiel für den Aufbau von Textinformationsobjekten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Nach Figur 3 gliedert sich ein
Textinformationsobjekt 100 in einen Objekt-Header-Abschnitt 100a und einen Objekt-Inhalt-Abschnitt 100b und ist maximal 2044 Bytes lang. Die maximale Länge ist nicht zwingend. Freilich wäre es auch mRglich unbegrenzte Längen zuzulas- sen. Sie ermRglicht es aber, dass die Abspeicherung der Objekte 100 sowohl empfangsseitig als auch sendeseitig auf einfache Weise in Arrays erfolgen kann, in denen die Objekte mit einem Versatz von 2044 Bytes oder einem Vielfachen davon zueinander angeordnet sind und damit einfach handhab- bar sind.
Der Objekt-Header-Abschnitt 100a gliedert sich beispielsweise wiederum seinerseits in einen 3 Byte langen Standard- Header lOOal und einen Erweiterungs-Header 100a2, wobei an- genommen wird, letzterer habe eine Länge von n Bytes, wobei n eine Ganzzahl grRßer gleich Null ist. Der Objekt-Inhalt- Abschnitt 100b ist m Byte lang, wobei m eine Ganzzahl grRßer Null ist.
Der Standard-Header 100a! zergliedert sich beispielsweise wieder in eine 2 Byte bzw. 16 Bit lange Objekt-ID 102, die beim Haupt-Objekt 52 (Figur 2) wie erwähnt 0x0000 betragen kann, und einen Objekt-Deskriptor 104, der die acht nied- rigwertigeren Bits des Standard-Headers 100 einnimmt. Die Anzahl von 16 Bits der Objekt-ID schränkt die Anzahl an vergebbaren IDs auf 216, also ungefähr 106, ein. Die Bits des Objekt-Deskriptors 104 haben verschiedene Bedeutung. Wie es bei 106 angedeutet ist, bilden die drei MSB (MSB = Most Significant Bits = hRchstwertige Bits) des Objekt- Deskriptors 104 eine Objekt-Typ-ID 108, die drei LSB (LSB = Least Significant Bits = niedrigstwertige Bits) einen Revisions-Index 110 und die beiden Bits dazwischen ein Static- bzw. Statisch-Flag 112 und ein Komprimierungsflag 114.
Die Ob^ekt-Typ-ID 108 zeigt durch ihren Wert den Objekttyp des Textinformationsobjekts 100 an, wie es in nachfolgender Tabelle gezeigt ist.
Die Liste kann freilich jederzeit um neue Objekt-Typen ergänzt werden, die von bisherigen Empfangern zu ignorieren waren.
Wie es im Folgenden noch erRrtert werden wird, hat das Sta- tic-Flag die Bedeutung, dass es, wenn es gesetzt ist, dem Benutzer mRglich ist, die Objekt-ID 102 zu der Favoritenliste 46 hinzuzufügen. Das Static-Flag wird vom Textinforma- tions-Rundfunkdienst-Betreiber gesetzt oder nicht gesetzt, je nachdem, ob die Objekt-ID nur zufallig und temporar zugewiesen wird, also nur zeitlich begrenzt inhaltlich gleiche Informationen anzeigt, im welchem Fall ein Hinzufugen zu den Favoriten nicht sinnvoll wäre, oder ob die Zuweisung der Objekt-ID dauerhaft ist, und damit eine Favoriten- Hmzufugung sinnvoll wäre, wie es im Folgenden noch naher erRrtert werden wird.
Das Kompressionsflag 114 zeigt an, ob der Objekt-Inhalt- Abschnitt 100b auf vorbestimmte Weise komprimiert ist oder nicht. Der Revisions-Index wird von dem Dienstbetreiber ge¬ setzt, um bei den zyklisch wiederholt seriell übertragenen Textinformationsobjekten mit gleicher Objekt-ID anzugeben,
um welche Version der Textinformation bzw. des Gegenstands, auf die sich diese Textinformationsobjekte beziehen, es sich handelt. Bei jeder Aktualisierung wird der Revisions- Index 110 sendeseitig inkrementiert . Betrifft beispielswei- se die Textinformation einer bestimmten Objekt-ID den Fußballspielstand eines Fußballspiels, das augenblicklich stattfindet, würde die Textinformation "0:0", die den Spielstand anzeigt, in den ersten Textinformationsobjekten mit dieser Objekt-ID zusammen mit dem Revisions-Index 000b (b für binär) übertragen werden, während nach einem Tor- schuss in dem Speicher 18 die Textinformation auf "0:1" geändert werden würde und gleichzeitig der Revisions-Index von 000b auf 001b geändert werden würde, so dass nachfolgend übertragene Texinformationsobjekt mit dieser Objekt-ID die Textinformation „0:1" und den Revisionsindex 001b hätten. Der Revisions-Index ermRglicht folglich, wie es im Folgenden noch näher erRrtert werden wird, dass empfangs- seitig Aktualisierungen abhängig davon durchgeführt werden kRnnen, ob sich der Revisions-Index von einem bereits emp- fangenen Textinformationsobjekt zu einem neu empfangenen Textinformationsobjekt geändert hat oder nicht, ohne inhaltlich analysieren zu müssen.
Die Objekt-ID wird sendeseitig mit Textinformationen ver- knüpft, die dann in dem Objekt-Inhalt-Abschnitt 10b enthalten sind, wie es im Folgenden noch erläutert werden wird. Wie bereits erwähnt, gibt es Objekt-IDs die zufällig und nur temporär vergeben werden, und bei denen das Static-Flag 112 nicht gesetzt ist, und solche, bei denen die Objekt-IDs fest mit einer Art von Textinformation (beispielsweise dem aktuellen Wetterbericht einer Stadt) verknüpft sind, die gegebenenfalls aktualisiert wird, wobei dann der Revisions- Index 110 inkrementiert wird.
Der Erweiterungs-Header 100a2 stellt eine Erweiterungsoption für den Nachrichtendienst dar. Falls in den Datenanwen- dungssignalisierungsinformationen des Rundfunksystems, also den Steuerungsinformationen in dem Rundfunksignal neben den Audio-Informationen und den Textinformationen, angezeigt wird, dass der Erweiterungs-Header 100a2 zusätzliche Header-Informationen enthält, kann ein Empfänger, der nicht in der Lage ist, mit dem Erweiterungs-Header zu arbeiten, die- sen Abschnitt ohne weiteres ignorieren. Da die Anzeige in der Benutzung des Erweiterungs-Headers und den üblichen Da- tenanwendungssignalisierungsinformationen des Rundfunksystems erfolgt, ist die Länge des Erweiterungs-Headers 100a2 für alle Objekte des „NewsService Journaline" gleich.
Wie bereits erwähnt, sind der eigentliche Textinhalt bzw. die Textinformationen in den Textinformationsobjekten im Objekt-Inhalt-Abschnitt 100b enthalten. Die Textinformationen sind dabei beispielsweise in einer UTF-8Bit-Kodierung (ÜTF = Unicode Transformation Format) kodiert.
Bevor die Kodierung der Textinformationen und der weiteren Informationen in dem Objekt-Inhalt-Abschnitt 100b bezugnehmend auf Figur 4 näher veranschaulicht wird, wird im Fol- genden bezugnehmend auf Figur 6a bis 6d zunächst jeder Objekt-Typ näher beschrieben. Figur 6a bis 6d zeigen jeweils ein Beispiel für eine Bildschirmanzeige, wie sie sich je nach Objekt-Typ an der Anzeige 30 ergibt. Es sei erwähnt, dass die Beisiele von einer zur Darstellung von mehreren Zeilen auf einem Bildschirm fähigen Anzeige ausgehen, dass der Dienst aber freilich auch auf existierenden Autoradioanzeigen, die zumeist nur 1 Zeile mit 16 Zeichen anzeigen kRnnen, realisiert werden kann.
Figur 6a zeigt den Bildschirmaufbau, wie er sich auf der Anzeige 30 bei Anzeige der Textinformationen eines Text- Objekts, d.h. mit Objekt-Typ-ID = 0x2, ergibt. Wie es zu sehen ist, gliedert sich eine Textinformation bzw. eine Nur-Text-Nachricht eines Text-Objekts in einen Titel 150 und den eigentlichen Text 152, den sog. TextkRrper. Zur Darstellung an den Benutzer werden der Titel 150 und der nachfolgende eigentliche Textabschnitt 152 auf dem Bild- schirm der Anzeige 30 mit automatischem Zeilenumbruch angezeigt bzw. aufbereitet. Der Benutzer kann vertikal durch den Text scrollen, beispielsweise durch Betätigung eines vertikal angeordneten Kippschalters oder dergleichen an dem Bedienfeld 34. Der Titel 150 ist an den Textabschnitt 152 angefügt, so dass derselbe gegebenenfalls zusammen mit dem übrigen Text 152 eventuell aus dem angezeigten Abschnitt der Anzeige 30 geschoben wird. Zur Anzeige kann jegliche Schriftart verwendet werden.
Genauer ausgedrückt wird es der Normalfall sein, dass die Menge an Textinformationen eines Textobjektes grRßer ist als eine anzeigbare Menge bzw. GrRße, so dass nur ein Teil der Textinformationen auf dem Bildschirm der Anzeige 30 angezeigt werden kann. Dieser anzeigbare Abschnitt wird durch Betätigung entsprechender Tasten am Bedienfeld 34 über Titel 150 und Text 152 verschoben. Diese MRglichkeit wird dem Benutzer durch entsprechende Pfeile am rechten Rand des Bildschirms der Anzeige 30 angezeigt, wie es in Figur 6a bei 154 und 156 zu sehen ist. Vorliegend liegt der anzeig- bare Abschnitt am Beginn der gesamten Textnachricht. Ein weiteres Scrollen nach oben ist nicht sinnvoll. Dies wird durch entsprechendes, beispielsweise farbliches Hervorheben des Pfeils 154, der nach oben weist, angedeutet. Entspre-
chende Hervorhebung wird beim Pfeil 156 durchgeführt, wenn sich der anzeigbare Bereich bzw. Abschnitt am Ende der Nachricht befindet und deshalb ein Scrollen nach unten nicht mehr mRglich ist.
Figur 6b zeigt eine Nur-Titel-Nachricht bzw. ein Nur-Titel- Objekt (Objekt-Typ-ID = 0x3) . Nur-Titel-Nachrichten umfassen lediglich einen Titel 150, der auf dem Bildschirm der Anzeige 30 angezeigt wird. Ein Textabschnitt 152 bzw. Body- Text ist nicht vorgesehen. Zur Darstellung an den Benutzer wird der Titel-Text 150 auf dem Bildschirm der Anzeige 30 beispielsweise wieder mit automatischem Zeilenumbruch angezeigt. Gegebenenfalls kann der Benutzer durch den Text scrollen. Vorliegend kann jedoch der Titel vollständig auf dem Bildschirm der Anzeige 30 angezeigt werden, so dass durch Fehlen der Pfeile 154 und 156 dem Benutzer angezeigt wird, dass der Titel 150 vollständig angezeigt worden ist und keine Scroll-MRglichkeit besteht. Die Darstellung einer reinen Titelnachricht kann beispielsweise immer sowohl in Zeilen- als auch in vertikaler Richtung zentriert erfolgen. Als Schriftart ist wiederum jede gleich gut verwendbar.
Figur 6c zeigt eine Listen-Nachricht bzw. die Textinforma¬ tionen eines Listen-Objekts (Objekt-Typ-ID = 0x4). Eine Li- sten-Nachricht enthält einen Titel 160 und eine Liste von Textzeilen 162a bis 162d. Zur Darstellung an den Benutzer sollte der Titel im Unterschied zu den in Figur 6a gezeigten Textnachrichten immer auf dem Bildschirm der Anzeige 30 zu sehen sein, während der Benutzer durch die Zeilen 162a bis 162d von Informationen in dem KRrper-Abschnitt 162 scrollt. Es kann vorteilhaft sein, zur Darstellung von Listen-Objekten eine Schriftart zu verwenden, die einen gleichmäßigen Zeichenwiderholabstand in Zeilenrichtung auf-
weist, um wie in dem Beispiel von Figur 6 zweispaltige Tabellen durch Vorsehen von Leerzeichen zu ermRglich. Falls der Titel 160 oder irgendeine Zeile 162a bis 162d eine Zeilenlänge des Bildschirms der Anzeige 30 überschreitet, wird dieser Listen-Punkt bzw. diese Listenzeile beispielsweise am Zeilenende abgeschnitten.
Figur 6a zeigt eine Menü- bzw. die Textinformation eines Menü-Objektes (Objekt-Typ-ID = 0x1) . Ein Menü enthält einen Titel 170 und eine Liste von Menü-Optionen 172a, 172b und 172 c. Jeder Menü-Option ist ein Verweis auf ein anderes Textinformationsobjekt zugeordnet, und zwar in Form einer Objekt-ID. Wie beim Listen-Objekt von Figur 6c kann der Benutzer durch die Menü-Optionen scrollen. Dabei wird immer eine der Menü-Optionen auf dem Bildschirm der Anzeige 30 hervorgehoben, in diesem Fall die Menü-Option 172b. Zeigt der Benutzer durch Drücken einer geeigneten Taste auf dem Bedienfeld 34, wie z.B. der Taste nach rechts, an, dass er zu dem Textinformationsobjekt will, auf das der Verweis der Menü-Option verweist, die gerade hervorgehoben ist, und dessen Inhalt durch den Text in der hervorgehobenen Zeile des Menüs mRglichst gut umschrieben wird, wie in dem vorliegenden Fall durch den Menü-Optionstext "Zweite Bundesliga 32. Runde", so wird, wie es im Folgenden beschreiben wird, die Textinformation dieses Textinformationsobjekts als Nächstes auf der Anzeige angezeigt, wodurch das augenblickliche Objekt bzw. die augenblickliche Textinformation auf dem Bildschirm der Anzeige 30 durch die neue ersetzt wird.
Genauer ausgedrückt besteht also eine Menü-Option aus einem Verweis auf ein anderes Textinformationsobjekt und einem Etikett, das eine Zeile auf dem Bildschirm der Anzeige 30
darstellt und den Inhalt des referenzierten Textinformationsobjekts bezeichnet bzw. betitelt oder umschreibt. Falls der Titel oder ein Etikett die Länge einer Zeile des Bildschirms der Anzeige 30 überschreitet, kRnnte der entspre- chende Inhalt abgeschnitten werden. Neben den entsprechenden Scroll-Pfeilen 156, 154 werden auf dem Bildschirm der Anzeige 30 in dem Fall eines Menü-Objekts durch eckige Klammern 174 Menü-Optionen hervorgehoben, die nicht sofort angezeigt werden kRnnen, da sie sich noch nicht im Cache- Speicher 32 befinden, wie es im Folgenden noch näher erRrtert werden wird.
Nachdem im Vorhergehenden bezugnehmend auf Figur 6 Beispiele für Textinformationen von Textinformations-Objekten un- terschiedlichen Objekt-Typs beschrieben worden sind, wird im Folgenden bezugnehmend auf Figur 4a-4e exemplarisch die Kodierung dieser Textinformationen im Objekt-Inhalt- Abschnitt 100b (Figur 3) beschrieben. Wegen der starken Limitierung der verfügbaren Bandbreiten gängiger Rundfunksy- steme für Datendienste werden bei der Generierung der zu übertragenden Textinformationsobjekte mRglichst effiziente Codierungen verwendet.
Der Objekt-Inhalt-Abschnitt gliedert sich normalerweise in einen Titel- und einen KRrper- bzw. Body-Abschnitt. Lediglich bei Nur-Titel-Objekten fehlt der Body-Abschnitt im Objekt-Inhalt-Abschnitt. Der Titel- und Body-Abschnitt jedes Objekts sind durch NML-Codes strukturiert (NML = NewsServi- ce Markup Language) , die den Anfang und das Ende eines be- stimmten Informationsblocks innerhalb des Objekt-Inhalt- Abschnitts anzeigen, wie z.B. des Titel- und des Body- Abschnitts .
Innerhalb eines bestimmten Informationsblocks, wie z.B. des Titel- oder Body-Abschnitts, kRnnen Escape-Sequenzen vorgesehen sein, um Textformatierungs-Informationen einzubringen, wie z.B. Texthervorhebung, erzwungenen Zeilenumbruch, usw., sowie zusätzliche Funktionalitäten, wie z.B. Informationsbereiche, die durch Empfänger, die nicht in der Lage sind, mit der zusätzlichen Funktionalität umzugehen bzw. die diese zusätzliche Funktionalität nicht unterstützen, einfach ignoriert werden kRnnen.
Sowohl NML-Codes als auch Escape-Sequenzen sind Ein-Byte- Codes aus dem Bereich von 0x00 bis OxlF, sogenannte UTF-8- Steuercodes . Insbesondere umfassen die NML-Codes den Bereich von 0x00 bis OxOF und die Escape- bzw. Ausweich- Sequenzen einen Bereich von 0x10 bis OxlF.
Im Folgenden werden bezugnehmend auf die Beispiele von Figur 4a bis 4e Beispiele für Textinformationsobjekte (Figur 4a bis 4c) bzw. InformationsblRcke im Objekt-Inhalt- Abschnitt (Figur 4d und 4e) beschrieben.
Zunächst wird der NML-Code näher erläutert. Jeder Objekt- Abschnitt bzw. Objekt-Block in dem Objekt-Inhalt-Abschnitt wird mit einem NML-Code gestartet und durch entweder den NML-Code "End", das Auftreten eines weiteren NML-Codes oder das Ende des Objekt-Inhalt-Abschnitts beendet.
Die NML-Codes sind exemplarisch auf folgende Weise definiert :
0x00 sei der NML-Code für "Ende". Er wird verwendet, um einen Abschnitt bzw. Block innerhalb des Objekt-Inhalt- Abschnitts zu beenden, ohne dass ein weiterer Abschnitt
bzw. weiterer Block begonnen wird. Er ist auf jeden Objekt- Typ anwendbar.
0x01 sei der NML-Code für "Titel" und zeigt durch sein Auf- treten in dem Objekt-Inhalt-Abschnitt 100b empfangsseitig den Beginn des Titel-Abschnittes bzw. Titel-Blockes an. Exakt ein Titel-Block muss pro Objekt für alle bisher definierten Objekt-Arten vorhanden sein, der NML-Code 0x01 also zumindest einmal im Abschnitt 100b auftreten. Der Titel- Block muss zudem der erste Block in dem Objekt-Inhalt- Abschnitt 100b sein. Der NML-Code 0x01 ist ebenfalls bei allen Objekt-Typen anwendbar.
0x02 sei der NML-Code für einen Menü-Options-Block-Beginn. Dieser Code stellt also den Anfang jeder Menü-Option in einem Menü-Objekt dar. Dieser Code ist folglich auch nur für Menü-Objekte vorgesehen. Auf das Auftreten des NML-Codes 0x02 hin erwartet der Empfänger bzw. ein in der Steuereinrichtung 26 vorgesehener Dekodierer (nicht gezeigt) in den nachfolgenden Bytes zunächst die Zieladresse bzw. den Verweis bzw. die Objekt-ID des Textinformationsobjekts, auf das verwiesen wird, und anschließend den Text der Menü- Option, der angezeigt werden soll und den Inhalt das refe- renzierten Objektes beschreibt. Pro Menü-Option eines Menü- Objekts tritt der Code 0x02 einmal in dem Objekt-Inhalt- Abschnitt auf. Genauer ausgedrückt, erwartet empfangsseitig der Dekodierer in der Steuereinrichtung 26, dass auf den Code 0x02 zwei Bytes folgen, die die Objekt-ID des referen- zierten Objekts angeben, d.h. des Objekts, das angezeigt werden soll, falls der Benutzer diese Menü-Option auswählt, und daraufhin noch n Bytes, die die anzuzeigende Menü- Options-Beschreibung anzeigen, die in einer Zeile des Menüs
dem Benutzer angezeigt werden soll und ihm quasi die Auswahl unter allen Menü-Optionen ermRglichen soll.
Figur 4a zeigt beispielsweise ein Textinformationsobjekt für das Menü-Objekt von Figur 6a mit den NML-Codes 0x00 bis 0x02 zur Veranschaulichung. Wie bereits bezugnehmend auf Figur 3 beschrieben, beginnt das Objekt 100 mit einem Objekt-Header 100a, der vorliegend exemplarisch n Byte lang ist. Daraufhin folgt der Objekt-Inhalt-Abschnitt 100b. Das erste Byte des Objekt-Inhalt-Abschnitts 100b ist 0x01, d.h. der NML-Code, der den Beginn des Titel-Blocks anzeigt, dessen Textinhalt auf den NML-Code 0x01 an der Byte-Position 0+1 unmittelbar folgt und sich von Byte 0+2 bis Byte k erstreckt. In diesem Abschnitt 200 ist auf eine Weise, wie sie im Folgenden noch näher spezifiziert werden wird, der Titel des Menüs von Figur 6d gespeichert, nämlich "Sport- Deutschland-Fussball" . Der empfangsseitige Dekodierer weiß, wann der Titel 200 beendet ist, da, wie im Vorhergehenden erwähnt, die Textinformation des Titels nur mit Ein-Byte- bzw. Multi-Byte-UTF-8-CodewRrtern kodiert ist, die nicht NML-Codes oder Escape-Sequenzen sind. Sobald der empfangsseitige Dekodierer folglich beim Byte k+1 wie gezeigt auf den NML-Code 0x02 trifft, weiß er, dass dies der Beginn eines nächsten Blocks ist, nämlich des ersten Menü-Options- Blocks. Die darauffolgenden zwei Bytes k+2 und k+3 zeigen durch Objekt-ID OxAABB das nächste anzuzeigende Textinformationsobjekt an, in dem Fall, dass dieser Menüpunkt ausgewählt wird. Darauf folgt bei 202 innerhalb der Bits k+4 bis p die Textkodierung für die erste Menü-Option des Menü von Figur 6d, nämlich "Bundesliga 32. Runde". Hierauf folgt beim Byte p+1 wiederum ein NML-Code 0x02 zur Anzeige des Beginns eines Menü-Options-Blocks. Zur Veranschaulichung sind die Menü-Options-BIRcke noch einmal bei den Bezugszei-
chen 204a, 204b und 204c angezeigt. Am Ende des Textinformationsobjekts 100 tritt der NML-Code 0x00 am Byte t+1 auf. Er zeigt das Ende von in diesem Fall dem gesamten Textinformationsobjekt 100 an. Dieser NML-Code 0x00 kann fehlen, wenn beispielsweise im Erweiterungs-Header die Länge des gesamten Textinformationsobjekts enthalten ist, so dass empfangsseitig durch entsprechende syntaktische Analyse das Ende des gesamten Objektes festgestellt werden kann.
Weiterhin sei 0x03 der NML-Code, der den Beginn eines Body- Blocks in dem Objekt-Inhalt-Abschnitt anzeige. Dieser enthält also den Text des TextkRrpers, der als der eigentliche Text in einem Text-Objekt angezeigt wird, also als 152 in Figur 6a beispielsweise. Lediglich ein Body-Block ist in jedem Objekt-Inhalt-Abschnitt mRglich und folglich auch nur das Auftreten von nur einmal 0x03. Der Code kommt nur bei Text-Objekten vor. Bei Nur-Titel-Objekten fehlt der NML- Code 0x03 im Objekt-Inhalt-Abschnitt, da diese keinen Text- kRrper aufweisen sondern nur einen Titel. Ein Kodierungs- beispiel für ein Titelinformations-Objekt ist in Figur 4b exemplarisch für das Text-Objekt von Figur 6a gezeigt. Der Body-Block ist bei 206 ersichtlich. Er besteht aus dem NML- Code 0x03 gefolgt von der UTF-8-Kodierung für den Body-Text 152, nämlich "Die Kassenlage der Kommunen ...".
Der NML-Code 0x04 zeige den Beginn eines Listenpunkt-Blocks in dem Objekt-Inhalt-Abschnitt an. Dieser Code tritt nur bei Listen-Objekten in dem Objekt-Inhalt-Abschnitt auf. In den Listenpunkt-BIRcken folgt auf dem NML-Code 0x04 die Ko- dierung für den Text, der für diesen Listenpunkt in einer Zeile der Liste auf dem Bildschirm der Anzeige angezeigt werden soll. Figur 4c zeigt ein Beispiel für eine Kodierung eines Textinformationsobjekts exemplarisch am Beispiel für
das Listen-Objekt von Figur 6c. Die Listenpunkt-BlRcke sind mit 208a, 208b und 208c angezeigt.
Nachdem bezugnehmend auf die Figur 4a bis 4c verschiedene Ausführungsbeispiele für Textinformationsobjekte zur Veranschaulichung der NML-Codes beschrieben worden sind, wird bezugnehmend auf die Figuren 4d und 4e die Kodierung der Textinformationen in den einzelnen BlRcken 204a bis 204c, 206 und 208a bis 208c beschrieben.
Ein Block in dem Inhalt-Abschnitt kann mehrere Escape- Sequenzen aufweisen, die dem Benutzer nicht unmittelbar angezeigt werden sollen. Statt dessen kRnnen Escape-Sequenzen Aufbereitungshinweise für die Anzeige umfassen, wie z.B. einen Hinweis auf einen hervorzuhebenden Textabschnitt, einen erzwungenen Zeilenwechsel, einen bevorzugten Zeilenwechsel, usw., oder Abschnitte von Text markieren, der nicht zur direkten Bildaufbereitung vorgesehen ist, wie z.B. binären Code, also Dinge, die durch Empfänger, die nicht zur Verarbeitung dieser Datenabschnitte in der Lage sind, ignoriert werden müssen.
Escape- bzw. ESC-Codes kRnnen beispielsweise sein:
OxlB Datenab- tet werde soll, der nicht in der Lage schnitt- ist, den Datenabschnitt auszuwerten. Der Fortset- Datenabschnitt kann beispielsweise zung HTML/XML-Konforme Etiketten oder binäre Daten umfassen. Jeder dieser zwei Codes bzw. Codeworte wird durch ein Byte gefolgt, das die Länge des folgenden Datenabschnitts in "Anzahl von Bytes minus Eins" spezifiziert. Ein Beispielstext mit solchen Datenschnitten kRnnte beispielsweise lauten "dies ist ein <big> großartiger </big> Test!" (big = groß), wobei die Darstellung ohne "Datenabschnitf'-Escape-Sequenz "dies ist ein <big> großartiger </big> Test!" lauten würde und die beabsichtigte Darstellung auf einem einfachen Empfänger "dies ist ein großartiger Test!". Im er- steren Fall wäre folglich die Anzeige in der Lage, die in den Klammern angegebenen Befehle bei der Anzeige zu berücksichtigen und auszuführen, d.h. in diesem Fall das Wort "großartig" fettgedruckt oder auf andere Weise groß zu schreiben. Ein Beispiel für den Ausschnitt aus einem Objekt-Inhalt-Abschnitt, der diese Text- Sequenz kodiert, ist beispielsweise in Figur 4d gezeigt. Falls der Datenabschnitt mehr als 256 Bytes aufweist, wird der Escape-Code "Datenabschnitt-Fortsetzung" eingefügt, und zwar direkt nach dem vorhergehenden Datenabschnitt, um den Datenabschnitt um max. 256 Bytes mit jeder Wiederholung zu erweitern. Ein Kodierungsbeispiel hierfür ist in Figur 4e gezeigt. Die Ausführungsbeispiele von Figur 4d und 4e kRnnen folglich dafür verwendet werden, die Textpassagen in den BIRcken 204a bis 204c, 206 und 208a bis 208c für entsprechend ausgerüstete Empfänger mit entsprechenden Anzeigern auf spezielle Weise anzuzeigen.
OxlC ErweiteDiese Escape-Codes ermRglichen die Signarungs- lisierung von erweiterten Escape- Code BeSequenzen. Jeder dieser zwei Codes bzw. ginn CodewRrter wird gefolgt durch einen Er-
OxlD Erweite- weiterte-Code-Wert, der ein Byte lang rungs- ist. Diese Erweiterte-Code-Werte sind für Code Ende zusätzliche Neuerungen vorgesehen, um für alte Empfänger abwärts-kompatibel zu sein. Falls ein "Erweiterungs-Code" in einer "Beginn"- und einer "Ende"-Version existiert, (z.B. wäre ein "Erweiterungs- Code-Wert" 0x00 = <bold> (bold = fettgedruckt) ) , mit der Notwendigkeit, sowohl <bold-Beginn> und <bold-Ende> zu signalisieren, wird derselbe "Erweiterungs-Code- Wert" verwendet: In dem ersten Fall wird mit dem "Erweiterungs-Code-Beginn"- Escape-Code fortgefahren, in dem zweiten Fall mit "Erweiterungs-Code-Ende"-Escape- Code . Falls ein "Erweiterungs-Code" lediglich ein einzelnen Code ohne eine explizite Beginn/Ende-Version enthält, soll immer mit dem "Erweiterungs-Code-Beginn"- Escape-Code fortgefahren werden. Falls ein Empfänger nicht in der Lage ist, "Erweiterungs-Codes" zu interpretieren, kann derselbe den "Erweiterungs- Code-Beginn/Ende"-Escape-Code (1 Byte) sowie den folgenden "Erweiterungs-Code- Wert" (1 Byte) ignorieren.
Bisher ist bezugnehmend auf die Figuren 2 bis 6 folglich der Aufbau der Textinformationsobjekte beschrieben worden. Die Textinformationsobjekte werden von dem Sender 10 in dem Rundfunksignal 16 übertragen, und in der Steuereinrichtung 26 mittels eines darin enthaltenen Dekodierers bzw. Parsers (nicht gezeigt) auf die bezugnehmend auf Figur 3 und 4 erläuterte Art und Weise syntaktisch analysiert. Zudem umfasst die Steuereinrichtung 26 eine nicht gezeigte Bildaufbereitungseinrichtung, die aus den syntaktisch analysierten Textinformationen in dem Objektinhalt-Abschnitt des anzuzeigenden Textinformationsobjekts geeignete Daten, wie z.B. Pixel-Daten generiert, die dann zur Anzeige 30 gesendet
werden. Es ist jedoch darauf hingewiesen, dass die Aufteilung betreffend die Bildgenerierung bzw. -aufbereitung und Textextraktion aus dem anzuzeigenden Textinformations- Objekt auch anteilig auf die Anzeige 30 verlagert sein kann, oder dass eigens vorgesehene Module zwischen Steuereinrichtung 26 und Anzeige 30 geschaltet sind.
Während sich die Figuren 3 und 4 mit dem Aufbau eines einzelnen Textinformationsobjekts beschäftigten, wird bezug- nehmend auf Figur 5 beschrieben, in welcher Reihenfolge die Textinformationsobjekte in dem Rundfunksignal 16 übertragen werden. Figur 5 zeigt exemplarisch in einer Zeile 300 einen Ausschnitt aus einem Rundfunksignal 16. Mit einem Pfeil 302 ist angedeutet, welcher Teil des Rundfunksignals 16 früher bzw. später ausgestrahlt wird, d.h. gemäß Figur 5 der linke Teil vor dem rechten Teil. Innerhalb des Rundfunksignals 300 sind durch BlRcke einzelne Textinformationsobjekte angedeutet. Jedes Textinformationsobjekt ist nummeriert. Die Nummer sei die dem Textinformationsobjekt zugeordnete Ob- jekt-ID.
Obwohl das in Figur 5 so dargestellt ist, als ob die Text¬ informationsobjekte zeitlich hintereinander ausgestrahlt werden würden, ist es freilich mRglich, dass die Ausstrah- lung einzelner Textinformationsobjekte zeitlich quasigleichzeitig erfolgt. Trotzdem ist unter den Textinformationsobjekten jedenfalls eine Reihenfolge definiert, nämlich durch die serielle Weiterleitung der ausgestrahlten und an der Antenne 38 empfangenen Textinformationsobjekte durch den Empfänger 12, so dass die Darstellung in Figur 5 auch für diesen Fall anwendbar ist. Die Textinformationsobjekte sind in dem Rundfunksignal 300 folglich in einer gewissen Reihenfolge aufeinander folgend angeordnet. Der Sender 10
strahlt jedes Textinformationsobjekt je nach Priorität mit einer gewissen Häufigkeit wiederholt aus. In der Figur 5 beispielsweise das Textinformationsobjekt mit der Objekt-ID 1 mit der Wiederhol-Zeitdauer τ1 und das mit der Objekt-ID 25 mit τ25- Die Häufigkeit bzw. Wiederhol-Zeitdauer richtet sich nach der zu erwartenden Häufigkeit, mit der das jeweilige Textinformationsobjekt durch Benutzer von Endgeräten gewünscht wird, d.h. für Wetternachrichten häufiger als für spezielle Nachrichten aus In- oder Ausland. Der Dienst- betreiber aktualisiert hierzu ständig die Textinformationsobjekte in dem Speicher 18. Dies bedeutet zum einem das Hinzufügen von Textinformationsobjekten zu der Liste 22 mit Vergabe neuer Objekt-IDs. Damit einhergehen muss allerdings auch die Änderung mindestens eines Menü-Objektes, das näm- lieh nun einen weiteren Menüpunkt bzw. eine weitere Menü- Option mit einem Verweis auf dieses neue Textinformationsobjekt aufweisen muss. Es erfolgt deshalb auch eine Änderung des entsprechenden Eintrags in der Liste 22 an der entsprechenden Objekt-ID dieses geänderten Menü-Objektes. Es sei beispielsweise das Objekt mit der Objekt-ID 1 in Figur 5 dieses zu verändernde Menü-Objekt, so würde es sich bei der nächsten Ausstrahlung nach der Zyklus-Zeitdauer τx verändert haben, und, wie im Vorhergehenden beschrieben, würde insbesondere der Revisions-Index inkrementiert sein. Ist in Figur 5 beispielsweise das Textinformationsobjekt
304 mit der Objekt-ID 1 das Textinformationsobjekts, dessen Textinformationen gerade auf der Anzeige 30 angezeigt werden, und das Textinformations-Objekt 306 mit ebenfalls der Objekt-ID 1 das soeben von dem Empfänger 12 empfangene Tex- tinformationsobjekt, dann kann der Empfänger anhand des
Revisions-Index des Textinformations-Objekts 306 und Vergleich desselben mit dem Revisions-Index des Textinformati- ons-Objekts 304 bestimmen, ob eine Aktualisierung notwendig
ist oder nicht. Innerhalb einer gewissen, in Figur 5 nicht dargestellten, Gesamtwiederhol-Zeitdauer wird jedes Textinformationsobjekt zumindest einmal ausgestrahlt.
Es sei darauf hingewiesen, dass aus der Beschreibung von
Fig. 5 deutlich wird, dass in der vorliegenden Beschreibung der Begriff „Textinformationsobjekt" doppeldeutig verwendet wird: er bezeichnet einerseits ein Objekt, das in dem Rundfunksignal übertragen wird, aber andererseits auch alle Ob- jekte mit einer speziellen Objekt-ID. So sind genau genommen in Fig. 2 nicht Textinformationsobjekt in der Baumstruktur angeordnet, sondern Objekt-IDs. Jede Objekt-ID steht stellvertretend für mehrere, nacheinander ausgestrahlte Textinformationsobjekte, und zwar die mit der ent- sprechenden Objekt-ID. Diese müssen ihrerseits nicht alle identisch sein, sondern kRnnen im Laufe der Zeit aktualisiert werden. Trotz alledem geht jeweils aus dem Sinnzusammenhang hervor, in welcher Art der Ausdruck „Textinformationsobjekt" gerade verwendet worden ist.
Nachdem nun im Vorhergehenden bezugnehmend auf die Figuren 1 bis 6 der „NewsService Journaline"-Dienst beschreiben worden ist, inklusive des Aufbaus der Textinformations- Objekte und der Art und Weise ihrer Ausstrahlung, wird im Folgenden die Funktionsweise des Empfängers 12 anhand der Figuren 7 bis 13 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung näher beschrieben.
Figur 7 zeigt, wie die Steuereinrichtung 26 in einem Anzei- ge-Aktualisierungs-Prozess ein soeben empfangenes Textinformationsobjekt daraufhin untersucht, ob eine Aktualisie¬ rung des Bildschirminhalts der Anzeige 30 durchgeführt werden soll oder nicht. Auf den Eingang eines Textinformati-
onsobjekts hin überprüft nun die Steuereinrichtung 26 in einem Schritt 400 zunächst, ob die Objekt-ID eines aktuell empfangenen Textinformationsobjekts zu der Objekt-ID eines aktuell angezeigten Textinformationsobjektes identisch ist. Dies würde bedeuten, dass das neu empfangene Textinformationsobjekt eventuelle Änderungen zu dem älteren, aktuell angezeigten beinhalten kRnnte. Ergibt der Vergleich in Schritt 400 keine Identität, endet der Anzeige- Aktualisierungs-Prozess bei 402, um bei Empfang des näch- sten empfangenen bzw. nachfolgenden Textinformationsobjekts wieder zu beginnen. Liegt Identität bei Schritt 400 vor, wird in Schritt 404 durch die Steuereinrichtung 26 geprüft, ob sich der Revisions-Index (110 in Figur 3) in dem aktuell empfangenen und dem aktuell angezeigten Textinformationsob- jekt gleicht. Ist dies der Fall, bedeutet dies, dass empfangsseitig davon ausgegangen werden kann, dass sich inhaltlich keine Änderungen bezüglich dieser Objekt-ID ergeben haben. Auf Feststellung der Identität in Schritt 404 hin endet folglich der Anzeige-Aktualisierungs-Prozess bei 406, um mit dem unmittelbar nachfolgend empfangenen Textin- formationsobjekt wieder zu beginnen. Liegt jedoch Ungleichheit in Schritt 404 vor, überprüft die Steuereinrichtung 26 in einem Schritt 408 die Objekt-Typ-ID (108 in Figur 3) , und zwar entweder des aktuell empfangenen oder des aktuell angezeigten Textinformationsobjekts, daraufhin, ob dasselbe einen Listen-, Menü- oder Nur-Titel-Objekt-Typ anzeigt, d.h. 0x1, 0x3 oder 0x4 ist. Ist dies der Fall, wird in einem Schritt 410 nunmehr das neu empfangene Textinformationsobjekt auf der Anzeige 30 angezeigt, wodurch die Textin- formation auf der Anzeige 30 aktualisiert wird.
Bei der Aktualisierung in Schritt 410 sorgt eine Anzeige- Steuerung (nicht gezeigt) dafür, dass die aktuelle Scroll-
Position des Benutzers beibehalten wird. Das verhindert, dass der Benutzer, der in einer Liste oder einem Menü gerade mühsam einen Teil durchscrollt bzw. durchforstet hat, bei Aktualisierung wieder von Neuem beginnen muss. Bei ei- nem Menü-Objekt führt die Aktualisierung von Schritt 410 folglich dazu, dass eine Menü-Options-Zeile des Menüs vor der Aktualisierung, wie z.B. die Zeile 172b in Figur 6d, auch nach der Aktualisierung dieselbe Bildschirmposition aufweist, vorausgesetzt, dass das neue Menü-Objekt genügend Zeilen bzw. genügend Menü-Optionen aufweist bzw. dass es überhaupt diese Menü-Option noch aufweist. In dem Fall eines Listen-Objekts führt die Aktualisierung nach Schritt 410 entsprechend dazu, dass eine Listen-Zeile der Liste vor der Aktualisierung an derselben Bildschirmposition ange- zeigt wird, wie nach der Aktualisierung, vorausgesetzt, dass das neue Listen-Objekt genügend Zeilen aufweist. Beispielsweise wird die Aktualisierung von Schritt 410 derart durchgeführt, dass die so und so vielte Menü-Option bzw. so und so vielte Listen-Zeile an derselben Bildschirmposition vor und nach der Aktualisierung erscheint. Dies bedeutet auch, dass der anzeigbare Bereich vor und nach der Aktualisierung zumindest teilweise überlappt, so dass Verwirrungen beim Benutzer bei einer Aktualisierung vermieden werden.
Alternativ kann für die Prüfung auf Gleichheit eines Eintrags im neuen Objekt mit dem aktuell angezeigten Eintrag des gerade angezeigten Objekts auch beispielsweise die OB- jekt-ID des Menü-Eintrags oder der Text des Menü- oder Listen-Eintrags herangezogen werden.
In dem Fall eines Nur-Titel-Objektes kann es in Schritt 410 jedoch vorgesehen sein, einfach den aktualisierten Textinhalt des neu empfangenen Objektes wie ein neues Objekt mit
neuer Objekt-ID einfach von vorn anzugeigen, da ja Nur- Titel-Nachrichten ohnehin per Definition keinen grRßeren TextkRrper aufweisen. Ein eventuelles erneutes „Bild- schirmscrollen" schadet also nicht.
Bei Listen-, Menü- und Nur-Titel-Objekten geschieht die Aktualisierung nach 410 folglich unmittelbar, automatisch und ohne, dass der Benutzer seine Zustimmung geben muss. Bei Text-Objekten kann es jedoch mühsam sein, wenn der Benutzer aus seiner augenblicklichen Lese-Position in einem Fließtext wieder an den Anfang zurückversetzt wird oder der aktuell ausgelesene Inhalt im aktualisierten Objekt gar nicht mehr enthalten ist. Deshalb wird in dem Fall, dass die Prüfung bei 408 ergibt, dass es sich bei dem aktuell angezeig- ten oder dem aktuell empfangenen Textinformations-Objekt nicht um eine Listen-, Menü- oder Nur-Titel-Objekt handelt, sondern demnach um ein Text-Objekt, in einem Schritt 410 der Benutzer wie z.B. über eine Anfrage über die Anzeige 30 oder aber über ein blinkendes Lämpchen, ein blinkendes „Ak- tualisierung" auf dem Bildschirm der Anzeige 30 oder eine andere Einrichtung, darüber informiert, dass eine aktualisierte Version dessen vorliegt, was er gerade liest. Der Benutzer wird hierdurch gleichzeitig angefragt, ob er eine Aktualisierung wünscht oder eine solche vermeiden mRchte bzw. ablehnt. Die Zustimmung kann der Benutzer über das Be¬ dienfeld 34 zum Ausdruck bringen, wie z.B. durch Drücken einer gewissen Taste, oder aber durch eine andere Bestätigungseinrichtung. Die Ablehnung kann in einer Keine- Reaktion-Betätigung bzw. -Bedienung bestehen, wie z.B. das Nicht-Drücken einer Taste. Die MRglichkeit, dass der Benutzer seine Zustimmung zum Ausdruck bringt, kann auch zeitlich begrenzt werden, wie z.B. durch eine Zustimmungs- HRchstzeitdauer . In einem Schritt 412 überprüft die Steue-
rungseinrichtung, ob der Benutzer Zustimmung erteilt oder nicht erteilt. In dem Fall, dass der Benutzer eine Aktualisierung ablehnt, endet der Anzeige-Aktualisierungs-Prozess bis zu seinem Neubeginn bei 414. Anderenfalls erfolgt 416 eine Anzeige-Aktualisierung. Die Anzeige-Aktualisierung in Schritt 416 erfolgt jedoch ohne Beibehaltung der aktuellen Anzeigeposition wie bei Schritt 410, sondern vorzugsweise wie bei Anzeige eines Textinformationsobjektes mit neuer Objekt-ID von Beginn an, d.h. in bis an den Anfang ges- crollter Position.
Figur 8 zeigt einen weiteren Prozess, der durch die Steuereinrichtung 26 ständig bei Eintreffen eines neu empfangenen Textinformationsobjekts ausgeführt wird. Der Prozess von Figur 8 ist ein Cache-Aktualisierungs-Prozess . Der Cache- Aktualisierungs-Prozess von Figur 8 dient dazu, dass der Empfänger 12 stets zumindest einen Teil der bereits empfangenen Textinformationsobjekte, genauer gesagt für jede Objekt-ID das Textinformations-Objekt mit der neuesten ver- fügbaren Version, für eine schnelle Anzeige bzw. einen schnellen Zugriff aufweist. Zur Cache-Aktualisierung prüft die Steuereinrichtung 26 im Cache-Aktualisierungsprozess zunächst in einem Schritt 450 anhand der Objekt-ID des neu empfangenen Textinformationsobjekts, ob ein Textinformati- onsobjekt mit dieser Objekt-ID in der Liste 22 in dem Spei¬ cher 32 enthalten ist. Falls dies der Fall ist, d.h. in dem Fall eines Cache-Treffers, wird in einem Schritt 452 überprüft, ob sich der Revisions-Index des neu empfangenen Textinformationsobjektes von dem Revisions-Index des Text- informationsobjekts unterscheidet, der im Speicher 32 gespeichert ist und dieselbe Objekt-ID aufweist. Ergibt der Schritt 452 die Identität der beiden Revisions-Indizes, endet der Cache-Aktualisierungs-Prozess bei 454, um bei Ein-
treffen des nachfolgenden Textinformationsobjekts wieder von vorn zu beginnen. Ergibt die Überprüfung in Schritt 452, dass sich der Revisions-Index des neu empfangenen Textinformationsobjekts von dem in dem Cache-Speicher 32 unterscheidet, erfolgt in Schritt 456 die Ersetzung des entsprechenden Eintrags in der Liste 42 durch das neu empfangene Textinformationsobjekt.
Ergibt der Schritt 450 jedoch, dass in der Liste 42 des Ca- che-Speichers 32 kein Eintrag mit einer solchen Objekt-ID vorhanden ist, d.h. einen Cache-Fehlschlag, überprüft die Steuereinrichtung 26 in einem Schritt 458, ob der für die Liste 42 in dem Speicher 32 vorgesehene Speicherplatz voll ist, oder ob noch genügend Speicherplatz vorhanden ist, um einen Eintrag in der Liste 42 vorzunehmen. Ist der Cache nicht voll, so trägt in einem Schritt 460 die Steuereinrichtung 26 das neu empfangene Textinformationsobjekt in der Liste 22 bzw. dem Cache-Speicher 32 ein. Dies wird jedoch nur in einer Anfangsphase nach dem Einschalten des Empfängers 12 bzw. der „NewsService Journaline"-
Funktionalität des Empfängers 12 der Fall sein. Nach einer gewissen Zeit wird der Cache-Speicher 32 voll sein. In diesem Fall überprüft in einem Schritt 462 die Steuereinrichtung 26 nach einer gewissen Cache-Verdrängungs-Strategie, wie sie im Folgenden bezugnehmend auf Figur 9 näher erläutert werden wird, ob in dem Cache-Speicher 32 in der Liste 42 ein Textinformationsobjekt existiert, das eine niedrigere Cache-Priorität aufweist, als das neu empfangene. Die Überprüfung 462 berücksichtigt die Baumstruktur der Textin- formationsobjekte und definiert unter den Textinformationsobjekten eine Prioritäts-Reihenfolge je nachdem, ob auf dieselben durch das aktuell angezeigte Textinformationsobjekt oder ein Textinformationsobjekt in dem Datenpfad zwi-
sehen dem Wurzel-Objekt bzw. Haupt-Objekt und dem aktuell angezeigten Textinformationsobjekt verwiesen wird oder nicht, bzw. allgemeiner ausgedrückt, aufgrund seiner Position in der Baumstruktur bzw. seiner relativen Lage zu dem aktuell angezeigten Textinformationsobjekt innerhalb der Baumstruktur. Zusätzlich kann zwischen Objekten gleicher Cache-Priorität der Zeitpunkt des letzten Empfangs oder inhaltlichen Updates bzw. die Häufigkeit des Empfangs bzw. der inhaltlichen Updates ausgewertet werden.
Um dies zu veranschaulichen, ist in Figur 9 noch einmal exemplarisch ein Objektbaum dargestellt, wobei Menü-Objekte wiederum mit M und Text-Objekte mit T gekennzeichnet sind. Alle Menü-Objekte sind durch eine Nummer am linken unteren Eck nummeriert, welche die Objekt-ID angebe. Das aktuell angezeigte Textinformationsobjekt sei das Text-Objekt mit der Objekt-ID 100. Es befindet sich in der vierten Hierarchieebene. Um durch Verweise von dem Haupt-Objekt mit der Objekt-ID 0 zu dem aktuell angezeigten Text-Objekt mit der Objekt-ID 100 zu gelangen, musste der Benutzer die Textinformationsobjekte bzw. die Menü-Objekte mit der Objekt-ID 3 in der zweiten Hierarchieebene und der Objekt-ID 12 in der dritten Hierarchieebene durchlaufen. Die Folge von Objekt- IDs der Textinformationsobjekte von dem Haupt-Objekt mit der Objekt-ID 0 bis einschließlich des aktuell angezeigten Objekts mit der Objekt-ID 100, mit den auf dem Weg in dem Objektbaum zwischen denselben liegenden Menü-Objekten bilden den Objekt-Pfad 44, den der Empfänger 12 in dem Speicher 32 speichert, und auf den später noch näher eingegan- gen wird. Er wird eigentlich angelegt, um dem Benutzer das Zurückkehren in hRhere Menü-Ebenen zu ermRglichen, und deshalb auch zu jedem „Favoriten" abgespeichert. In vorliegendem exemplarischen Fall lautet der Objekt-Pfad {0, 3, 12,
100}. Alle Objekte, deren Objekt-ID in dem Objekt-Pfad 44 (Figur 1) enthalten sind, sind in Figur 9 durch eine gestrichelte Linie umkreist. Durch eine Strichpunkt-Linie sind in Figur 9 zusätzlich zu den Objekt-Pfad-Objekten alle Objekte umrahmt, auf die durch zumindest eines der Objekte in dem Objekt-Pfad verweisen wird; dies sind in dem Beispiel von Figur 9 die Objekte mit den Objekt-IDs 1, 2, 4, ..., 9, 13. Lediglich exemplarisch war das aktuell angezeigte Textinformations-Objekt in dem Beispiel von Figur 9 ein Text-Objekt. Wäre es ein Menü-Objekt wären durch die Strichpunkt-Linie auf Objekte eingeschlossen, die sich in der fünften Hierarchieebene des Objektbaumes befinden.
Die Cache-Verdrängungs-Strategie, nach welcher eine Priori- täts-Reihenfolge unter den Objekten festgelegt wird, läuft nun folgendermaßen:
1. Niedrigste Priorität haben Textinformations-Objekte, die sich außerhalb der Strichpunkt-Linie befinden, d.h. Textin- formations-Objekte, auf die nicht durch zumindest eines der Textinformationsobjekte in dem Objektpfad (angezeigt durch die gestrichelte Linie) verwiesen wird. Dies sind bei dem Beispiel von Figur 9 die Textinformationsobjekte 10, 11, 14 bis 20.
2. NächsthRhere Priorität besitzen Textinformations- Objekte, die sich zwischen der Strickpunkt-Linie und der gestrichelten Linie befinden. Dies sind also die Objekte, die sich nicht auf dem Objekt-Pfad befindet, auf die aber zumindest durch ein Objekt in dem Objekt-Pfad verwiesen wird.
2.1. Unter diesen Objekten ist wiederum eine Prioritäts- Reihenfolge definiert, derart, dass Objekte einer hRhe- ren Hierarchieebene eine hRhere Priorität aufweisen als solche einer niedrigeren Hierarchieebene, d.h. in dem Beispiel von Figur 9 das Objekt mit der Objekt-ID 13 eine hRhere Priorität als die mit dem Objekt-IDs 1, 2, 4 bis 9.
2.2 Unter denen gleicher Priorität sollten dann wie- derum Menü-Objekte hRherer Priorität aufweisen als die übrigen Objekt-Typen. Das Objekt mit der Objekt- ID 2 hätte folglich geringere Priorität als die Objekte mit den Objekts-ID 1, 4 bis 9. 2.3 Unter den Verbleibenden mit gleicher Priorität kRnnte wiederum eine Prioritäts-Reihenfolge dadurch definiert werden, dass Objekten, bei denen das Static-Flag gesetzt ist, eine hRhere Priorität zugewiesen wird, als solchen mit nicht gesetzten Static-Flag.
3. NächsthRhere Priorität umfassen wiederum die Menüs bzw. Objekte im Objekt-Pfad, vorliegend folglich die Objekte mit den Objekt-IDs 0, 3, 12 und 100. Unter diesen kRnnte wieder eine Prioritäts-Reihenfolge in Abhängigkeit von der Hierarchieebene definiert werden.
Es kRnnte ferner vorgesehen werden, dass abweichend von der vorhergehend dargestellten Verdrängungs-Strategie spezielle Objekte, und zwar mit Objekt-IDs, die in der Favoritenliste 46 in dem Speicher 32 enthalten sind, die hRchste Priorität aufweisen. HRchste Priorität aufweisen kRnnten ferner diejenigen Objekte, auf die durch das aktuell angezeigte Ob-
jekt, d.h. mit der Objekt-ID 100 verwiesen wird. Ferner kRnnten Objekte in der Strichpunktlinie alle gleich behandelt werden, also auch die Objekte des Objekt-Pfades gleich behandelt werden wie die Objekte, auf die sie verweisen, d.h. Punkt 3 würde fehlen.
Zurückkehrend zu Figur 8 endet der Cache-Aktualisierungs- Prozess bei 464, wenn bei Schritt 462 festgestellt wird, dass in dem Cache-Speicher kein Objekt mit niedrigerer Ca- che-Priorität existiert. Existiert ein solches, wird bei Schritt 466 das Objekt mit niedrigster Priorität durch das aktuell empfangene Objekt ersetzt. Auch wenn mehrere Objekte gleicher Priorität im Speicher diejenigen mit geringster Priorität sind, sollte ältest-empfangenes ersetzt werden.
Figur 10 zeigt einen Prozess, der durch die Steuereinrichtung 26 durchgeführt wird, wenn ein Benutzer am Bedienfeld 34 während der Anzeige eines Textinformationsobjekts an der Anzeige 30 Tasten betätigt, die zum Scrollen vorgesehen sind, wie z.B. die Pfeil-nach-oben- und Pfeil-nach-unten- Taste. In diesem Fall verschiebt die Steuereinrichtung 26 in einem Schritt 500 den anzuzeigenden Textausschnitt der Textinformationen des aktuell angezeigten Objekts nach unten bzw. nach oben, falls dies noch mRglich ist. Im Fall der Menü- und Listen-Objekte, wird, wie beschrieben, der Titel immer auf dem Bildschirm der Anzeige angezeigt.
Figur 11 zeigt einen Prozess, der durch die Steuereinrichtung 26 ausgeführt wird, wenn bei angezeigtem Textinforma- tionsobjekt der Benutzer eine Auswahltaste betätigt, die eine eigens vorgesehene Taste auf dem Bedienfeld 34 sein kann, oder beispielsweise die Pfeil-nach-rechts-Taste ist. Bei Betätigung dieser Taste bzw. Auswahleinrichtung prüft
die Steuereinrichtung 26 in einem Schritt 550, ob es sich bei dem aktuell angezeigten Textinformations-Objekt um ein Menü-Objekt handelt oder nicht. Ist dies nicht der Fall, ist die Auswahltaste nicht belegt, d.h. ihr ist keine Funktion zugewiesen, und der Prozess von Figur 11 endet bei 552. Handelt es sich um ein Menü-Objekt, so schlägt in einem Schritt 554 die Steuereinrichtung 26 im Speicher 32 nach, ob darin ein Objekt mit einer Objekt-ID enthalten ist, die der hervorgehobenen Menü-Option zugeordnet ist (vgl. 172b in Figur 6d) . Ist dies der Fall, d.h. in dem
Fall eines Cache-Treffers, ändert in einem Schritt 556 die Steuereinrichtung 26 die anzuzeigende Textinformation auf die des in dem Cache-Speichers 32 enthaltenen Objekts. Da der Zugriff auf den Cache-Speicher 32 schnell ist, voll- zieht sich die Bildschirmänderung an der Anzeige 30 für den Benutzer folglich unmerklich, d.h. unmittelbar. Ergibt das Nachschlagen bei 554 jedoch einen Cache-Fehlschlag, wartet in einem Schritt 558 die Steuereinrichtung 26 darauf, dass in dem Rundfunksignal 16 ein Objekt mit der gesuchten Ob- jekt-ID ausgestrahlt wird. Während des Schritts 558 werden alle andern Prozesse natürlich wie üblich durchgeführt, insbesondere die Prozesse von Figur 7 und Figur 8 an den inzwischen eingehenden Objekten. Sobald das Objekt mit der gesuchten Objekt-ID empfangen wird, ändert die Steuerein- richtung 26 in einem Schritt 560 die anzuzeigende Textinformation an dem Bildschirm der Anzeige 30 auf die des aktuell empfangenen Objekts mit der gesuchten Objekt-ID. Nach den Schritten 560 bzw. 556 wird in einem Schritt 562 eine Objekt-Pfad-Aktualisierung durchgeführt, wie sie in Figur 12 detaillierter dargestellt ist.
Figur 12 stellt den Objekt-Pfad-Aktualisierungs-Prozess von Schritt 562 dar. In einem Schritt 580 wird zunächst durch
die Steuereinrichtung 26 in dem Speicher 32 nachgeschlagen, ob die neue Objekt-ID, d.h. die Objekt-ID des nun neu auf der Anzeige 30 angezeigten Objekts, die der angewählten Menü-Option zugeordnet war, bereits in den Objekt-Pfad 44 e- xistiert. Falls dies der Fall wäre, würde das einfache
Hinzufügen der neuen Objekt-ID an das Ende der Objekt-Pfad- Liste von Objekt-IDs zu einer zirkulären Referenz führen. Führt der Nachschlag in Schritt 580 folglich zu einem Treffer, sorgt die Steuereinrichtung 26 in einem Schritt 582 dafür, dass die Objekt-Pfad-Liste 44 bis zu dieser Objekt- ID gelRscht wird, d.h. um mit dieser Objekt-ID zu enden. Anderenfalls, d.h. in dem Fall eines Fehlschlags beim nachschlagenden Schritt 580, wird in einem Schritt 584 die neue Objekt-ID an das Ende der Objekt-Pfad-Liste 44 angefügt, falls nicht der Objektpfad längenlimitiert ist und bereits seine maximale Länge erreicht hat.
Die Verwaltung der Objekt-Pf d-Liste 44 ist dazu vorgesehen, um eine Menü-Zurück-Funktionalität zu ermRglichen, wie es bezugnehmend auf Figur 13 näher erläutert wird, die einen Prozess veranschaulicht, den die Steuereinrichtung 26 auf das Drücken einer Zurück-Taste, wie z.B. der NachLinks-Taste auf dem Bedienfeld 34, ausführt, wenn gerade ein Textinformationsobjekt an der Anzeige 30 angezeigt wird. In diesem Fall nämlich ermittelt die Steuereinrichtung 26 in einem Schritt 600 aus der Objekt-Pfad-Liste 44 diejenige Objekt-ID, die in dem Objekt-Pfad der Objekt-ID des aktuell angezeigten Objekts unmittelbar vorausgeht, und dessen Objekt folglich auf dieselbe verweist. Kurz bezug- nehmend auf Figur 9, würde beispielsweise das Drücken der Zurück-Taste dort dazu führen, dass in dem Schritt 600 die Objekt-ID 12 ermittelt werden würde. Daraufhin schlägt in einem Schritt 602 die Steuereinrichtung 26 in dem Speicher
32 nach einem Objekt mit dieser Objekt-ID nach. In dem Fall eines Cache-Treffers ändert die Steuereinrichtung 26 in einem Schritt 604 die anzuzeigende Textinformation auf die des in dem Cache-Speicher 32 enthaltenen Objekts. Anderen- falls, d.h. in dem Fall eines Fehlschlags, wartet die Steuereinrichtung 26 in einem Schritt 606, bis in dem Rundfunksignal 16 ein Objekt mit der gesuchten Objekt-ID ausgestrahlt wird, woraufhin sich wie in einem Schritt 608 die anzuzeigende Textinformation auf die des aktuell empfange- nen Objekts mit gesuchter Objekt-ID ändert. Nach den
Schritten 604 und 608 aktualisiert die Steuereinrichtung 26 in einem Schritt 610 die Objekt-Pfad-Liste 44 durch Kürzen derselben um die letzte Objekt-ID, nämlich die Objekt-ID des Textinformationsobjektes, das vor der Änderung 604, 608 angezeigt worden ist.
Es wird natürlich, wie in Fig. 13 auch angezeigt, vor dem Schritt 600, in einem Schritt 612 geprüft, ob der Objekt- ID-Pfad 44 überhaupt mehr als eine Objekt-ID aufweist. Die Länge wäre eins, wenn sich der Benutzer gerade im Hauptmenü (d.h. z.B. 0x0000) befände. Wäre dies der Fall bliebe die Betätigung der Menü-Zurück-Taste ohne Folgen und der Prozeß endete bei 614. Nur anderenfalls begänne der Prozeß bei 600 wie oben beschrieben zu laufen.
Gemäß dem Ausführungsbeispiel von Figur 14 weist der Empfänger 12 eine Favoriten-Funktionalität auf, um ea einem Benutzer zu ermRglichen, bestimmte Menü- oder Nachrichten- Objekte für einen schnellen und direkten zukünftigen Zugriff zu speichern, indem denselben beispielsweise im Cache-Speicher die hRchste Priorität zugewiesen wird.
Zur Realisierung der Favoriten-Funktionalität umfasst der Empfänger 12 beispielsweise eine eigens vorgesehene Taste, durch deren langes Drücken der Benutzer seinen Wunsch zum Ausdruck bringen kann, die Objekt-ID des aktuell angezeig- ten Textinformationsobjekts der Favoriten-Liste hinzuzufügen, während kurzes Drücken derselben Taste dazu führt, dass die Steuereinrichtung die Favoriten-Objekt-ID in dem Favoriten-Speicher für das nächste anzuzeigende Textinformationsobjekt heranzieht. Freilich kRnnen auch andere Ein- richtungen vorgesehen sein, mit denen der Benutzer eine Favoriten-Hinzufügung oder einen Favoriten-Aufruf hervorrufen kann. Figur 14 stellt einen Favoriten-Hinzufügungs- Tastenaktivierungs-Steuerungsprozess dar. Zeigt der Benutzer den Wunsch des Hinzufügens an, wird in einem Schritt 700 durch die Steuerungseinrichtung 26 zunächst überprüft, ob das aktuell angezeigte Objekt ein gesetztes Static-Flag aufweist. Ist dies der Fall, bedeutet dies, dass die Objekt-ID für ein bestimmtes Menü oder ein bestimmtes Nachrichtenobjekt (z.B. themenbezogen) statisch bzw. ständig vorgesehen ist. Beispielsweise kRnnte ein Menü-Objekt betreffend "Wettervorhersage für Bamberg" immer durch einen bestimmten NewsService bzw. Nachrichtendienst unter der Objekt-ID 0x0020 angeboten werden. Folglich ist es in diesem Fall sinnvoll, es dem Benutzer zu ermRglichen, eine solche Objekt-ID zu einer Favoriten-Liste hinzuzufügen. Folglich fügt die Steuerungseinrichtung 26 in diesem Fall in einem Schritt 702 die Objekt-ID der Favoriten-Liste 46 in dem Speicher 32 hinzu. Sinnvoll wäre dies jedoch beispielsweise nicht bei einer Objekt-ID, die gerade für ein Text-Objekt vergeben ist, das den aktuellen Spielstand eines gerade stattfindenden Fußballspiels angibt. Dies Spiel endet nämlich in endlicher Zeit und die Objekt-ID wird anderweitig vergeben werden, beispielsweise für eine politische Tages-
meidung oder dergleichen. Bei nicht gesetztem Static-Flag endet der Prozess bei 704 folglich ohne Hinzufügung. In diesem Fall kann die Ablehnung 704 durch beispielsweise einen Ton, der das normale Audiosignal aus dem Lautsprecher 28 bzw. 40 übertRnt und dem Benutzer die Ablehnung angezeigt, oder durch eine kurzzeitige Überblendung begleitet werden .
Es wird darauf hingewiesen, dass es bevorzugt wird, dass ein Empfänger 12, der die Favoriten-Funktionalität unterstützt, für jede Favoriten-Objekt-ID auch den vollen Pfad von Objekt-IDs von dem Haupt-Objekt mit der Haupt-Objekt-ID (z.B. 0x0000) bis zu dem jeweiligen Favoriten-Objekt speichert. Anderenfalls wird der Empfänger nicht in der Lage sein, die Menü-Zurück-Funktionalität bzw. Rückkehr-zu- einem-hRheren-Menü-Funktionalität einem Benutzer zur Verfügung zu stellen, wenn ein Benutzer dieses Favoriten-Objekt aufgerufen hat, wenngleich natürlich das Objekt selbst sowie die unmittelbaren Unter-Objekte, in dem Fall dass es sich um ein Menü-Objekt handelt, das auf dieselben verweist, immer noch erreichbar sein würden. Falls ein Menü aus dem Objekt-ID-Pfad bei Restaurieren eines Favoriten- Seichers nicht mehr existieren (versendet werden) sollte, kRnnte die Steuereinrichtung statt dessen direkt in das Standard-Hauptmenü (z.B. 0x0000) springen.
Bei dem in Vorhergehenden beschriebenem Empfänger .wurde eine Aufzeichnung aller Menü-O jekt-IDs von dem augenblicklich angezeigten Menü/Nachrichten-Objekt zurück bis zu dem Hauptmenü-Objekt (z.B. Objekt-ID 0x0000) bewahrt, der so genannte Objekt-ID-Pfad. Auf diese Weise kann derselbe eine "Zurück-zu-hRherer-Menü-Ebene"-Funktionalität liefern.
Falls ein Objekt mit bestimmter Objekt-ID augenblicklich angezeigt wird bzw. dem Benutzer präsentiert wird und gleichzeitig eine aktualisierte Version desselben Objekts, d.h. ein Objekt mit identischer Objekt-ID aber unterschied- lichem Revisions-Index, empfangen wird, kRnnte entgegen vorhergehender Beschreibung dem Benutzer auch unabhängig von dem Objekt-Typ immer zunächst angezeigt werden, dass eine solche aktuelle Version dieses Objekts empfangen worden ist, wie z.B. durch Zeigen eines aufblinkenden "Aktua- lisierung"-Zeichens auf dem Bildschirm. Bevorzugt ist es jedoch, bei Menü- oder Listen-Nachricht-Objekten den Bildschirm der Anzeige unmittelbar mit dem Inhalt des neuen Objekts zu aktualisieren, während die aktuelle Relativ- Position des Benutzers innerhalb der Liste, d.h. der Li- stenzeilen-Index, an derselben Position im Bildschirm beibehalten wird. Anstelle des Listenzeilen-Indexes kRnnte ein Empfänger auf den Listenzeilen- bzw. Gegenstands-Text oder, in dem Fall eines Menü-Objekts, die Objekt-ID des Objekts, auf das verwiesen wird, auswerten. Bei einer Nur-Titel- Nachricht wird es bevorzugt, die Aktualisierung des Bildschirm der Anzeige mit dem Inhalt des neuen Objekts unmittelbar vorzunehmen.
Falls ein Menü-Objekt Verweise auf Objekt-IDs enthält, die noch nicht empfangen worden sind, werden diese Menüpunkte bzw. Menü-Optionen dem Benutzer trotzdem angeboten. Dies kRnnte freilich unterbleiben. Bevorzugt wird es jedoch, alle Menü-Optionen anzubieten, allerdings dabei dem Benutzer klar anzuzeigen, welche Menü-Optionen unmittelbar verfügbar sind, da die Objekte bereits empfangen worden sind und sich im Cache-Speicher befinden, und welche nicht unmittelbar sofort verfügbar sind, wie z.B. durch Umrahmen des Menü-
Options-Etiketts bzw. -Titels mit eckigen Klammern, wie in Figur 6d gezeigt.
Bei Anwendungen mit extremen Speicherengpässen, kRnnte der Empfänger lediglich das aktuell angezeigte Objekt zusammen mit dem Objekt-ID-Pfad, der zu dem aktuell angezeigten Objekt gehRrt, in seinem Speicher behalten. Falls der Benutzer dann ein anderes Objekt anfordert, muss er warten, bis das angeforderte Objekt in der nächsten Zeit empfangen wird.
Wie bereits erwähnt, kann der oben beschriebene „NewsServi- ce Journaline"-Dienst via DAB als eine neue Benutzer- Applikation ausgestrahlt werden. Jedes einzelne "NewsServi- ce Journaline"-Objekt kRnnte als eine "MSC-Datengruppe" transportiert werden, wobei hierzu auf Kapitel 5.3.3 "Pak- ked Mode - Data Group Level" in "Radio Broadcasting Systems, Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers", ETSI EN 301 401 VI.3.2, 2000-09, ver- wiesen wird.
Eine MSC-Datengruppe enthielte dann die folgenden Punkte: Einen MSC-Datengruppen-Heäder zu zwei oder vier Bytes, einen Session- bzw. Sitzung-Header, der optional wäre und 3+n Bytes lang wäre, ein MSC-Datengruppen-Feld, das ein "News- Service Journaline"-Objekt bzw. Textinformationsobjekt beinhaltet, und zwar von beispielsweise m Bytes, max . jedoch 2044 Bytes, und schließlich eine MSC-Datengruppe-CRC zu zwei Bytes, die für „NewsService Journaline" verbindlich ist.
Folgende Einstellungen kRnnten einheitlich für alle Empfänger festgelegt sein. Und zwar kRnnte festgelegt sein, dass es MSC-Datengruppen-Header-Feld folgendes Layout hat:
- Erweiterungs-Flag = 0 (Bei auf Eins gesetztem Flag musste der Empfänger Con- ditional Access bzw. eine Zugriffskontrolle unterstützen, um die Informationen zu dekodieren. Falls ein Empfänger kein Conditional Access unterstützt, musste er die MSC-Datengruppe verwerfen) CRC-Flag = 1 Segment-Flag = 0 (Wert hängt von dem Erweiterungs-Flag ab) Benutzer-Zugriffs-Flag = 0 (Wert hängt von dem Erweiterungs-Flag ab) Datengruppentyp = 0000b ("Allgemeine Daten") Kontinuitäts-Index: Inkrementiert kontinuierlich für jedes Objekt, kann aber ohne weiteres ignoriert werden. Wiederhol-Index: Wird üblicherweise dem Wert 000b aufweisen, kann aber ebenfalls ignoriert werden. Erweiterungs-Feld: Nicht vorhanden, weil das Erweiterungs-Flag auf 0 eingestellt ist.
Die folgenden Informationen kRnnten verwendet werden, um die DAB-Datenanwendung "NewsService Journaline" zu signali- sieren, wobei hierzu auf das Kapital 8.1.20 "User Application Information" aus obigen Dokument bzw. Standard verwiesen wird.
Die Haupt-ll-Bit-"Benutzer-Applikationstyp"-ID für den "NewsService-Journaline" kRnnte bis zu einer offiziellen Standardisierung durch DAB-Gremien 0x44A von dem Bereich der proprietären Benutzeranwendungen sein. Der Wert ent- spricht 10001001010b.
Das Benutzer-Applikationsdaten-Feld kRnnte folgende Struktur aufweisen:
Ein Byte zur Anzeige der Version des „NewsService Journaline" . Zusätzliche Informationen einer neueren Version kRnnten in vollständig abwärts kompatibler Weise an zwei Stellen hinzugefügt werden, nämlich zum einen in der gesamten Dienstsignalisierung, nämlich der "DAB-Benutzer-Applika- tions-Information" durch Erweitern der Länge des "Benutzer- Applikations-Daten"-Abschnitts unter Beibehaltung aller e- xistierender Bytes und deren Definition, wie sie in jeder vorgehenden Version des "NewsService Journaline" definiert ist, oder in dem Objekt-Header-Abschnitt jedes einzelnen Objekts durch Erweitern der Länge des "Erweiterungs-
Header"-Feldes bei gleichzeitiger Beibehaltung aller existierenden Bytes und deren Definitionen, wie sie in einer vorhergehenden Version des „NewsService Journaline" definiert sind.
- Außerdem musste das User-Application-Data-Feld die Länge des Erweiterungs-Headers in Bytes in dem Header-Abschnitt jedes Objekts aufweisen, die zu Lesen jeder Empfänger zumindest in der Lage sein musste, auch wenn er anschließend die Daten in dem Erweiterungs-Header verwirft, weil er zu deren Auswertung nicht in der Lage ist.
Mit identischer Signalisierung kann „NewsService Journaline" auch über DRM („Digital Radio Mondiale") ausgestrahlt werden, sowie über UKW/RDS nach Anpassung der Datendienst- Signalisierung.
Im Bezug auf die vorhergehende Figurenbeschreibung wird darauf hingewiesen, dass verschiedene darin enthaltene Aspekte nicht alle in der beschriebenen Weise kombiniert werden müssen, sondern dass diese Aspekte unabhängig von- einander implementiert oder nicht-implementiert sein kRnnen, wie z.B. insbesondere die Objekt-Pfad-Verwaltung mit zugehRriger "Menü-Zurück"-Funktionalität, die Cache- Speicher-Aktualisierung zur Beschleunigung des Zugriffs auf andere Textinformations-Objekte, die Abhängigkeit der An- zeige-Aktualisierung von dem Revisions-Index, die Abhängigkeit der Aktualisierung von dem Objekt-Typ, die Favoriten- Funktionalität, die Vermeidung von Zirkular-Referenzen in dem Objekt-ID-Pfad, der unterschiedlichen Bildschirm- Aktualisierung je nach Objekt-Typ, das Vorsehen des Revisi- ons-Index und dergleichen.
Abschließend wird darauf hingewiesen, dass abhängig von den Gegebenheiten das erfindungsgemäße Schema zur Steuerung eines Radio auch in Software implementiert sein kann. Die Im- plementierung kann auf einem digitalen Speichermedium, insbesondere einer Diskette oder einer CD mit elektronisch auslesbaren Steuersignalen erfolgen, die so mit einem programmierbaren Computersystem zusammenwirken kRnnen, dass das entsprechende Verfahren ausgeführt wird. Allgemein be- steht die Erfindung somit auch in einem Computerprogrammprodukt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode zur Durchführung des erfindungsgemäßen Verfahrens, wenn das Computerprogrammprodukt auf einem Rechner abläuft. In anderen Worten ausgedrückt kann die Er- findung somit als ein Computerprogramm mit einem Programm-
code zur Durchführung des Verfahrens realisiert werden, wenn das Computerprogramm auf einem Computer abläuft.