Vorrichtung und Verfahren zum Erzeugen eines Datenstroms und Vorrichtung und Verfahren zum Lesen eines Datenstroms

Beschreibung

Die vorliegende Erfindung bezieht sich auf die Datenübertragung und insbesondere auf eine einfachere Datenübertragung mit Text für einfache Empfänger und Text plus Daten für aufwändigere Empfänger, wobei der Datenstrom von beiden Empfängerarten ausgewertet werden kann.

Es existieren inzwischen eine Vielzahl von einzelnen Empfänger-Endgeräten, die alle in der Lage sind, übertragene Informationen mobil zu empfangen. Kennzeichnend für dieses große Spektrum ist, dass die Verarbeitungs- und Ausgabekapazitäten solcher unterschiedlicher Informationsempfänger stark unterschiedlich sind. Ein Notebook beispielsweise hat als mobiler Empfänger von übertragenen Informationen eine sehr hohe Verarbeitungs- und Ausgabekapazität, da ein Notebook erhebliche Prozessorressourcen und Speicherressourcen hat. Andererseits hat z.B. ein Mobiltelefon, das ebenfalls an einem Informationsdienst teilnimmt, wie beispielsweise einem Broadcast- oder Rundfunk-Datenkanal sehr begrenzte Verarbeitungsressourcen und Ausgaberessourcen. Noch beschränkter sind die Verarbeitungs- und Ausgaberessourcen in einem kleinen mobilen Rundfunkempfänger, der nicht einmal als Mobiltelefon gedacht ist, sondern lediglich als mobiler Rundfunkempfänger mit dem man Daten empfangen möchte, wie beispielsweise Bundesligaergebnisse, sonstige Sportergebnisse, Schlagzeilen einer Zeitung, Wetternachrichten, etc., wenn man einen entsprechenden Daten-Broadcast-Dienst nutzt.

Ein solcher textbasierter Informationsdienst für den digi- talen Rundfunk, der für eine einfache Datensammlung und Wiederverwendung sowie für eine sehr effiziente Rundfunkübertragung geeignet ist, existiert unter der Bezeichnung „Journaline" . Dieser Datendienst unterstützt einen sehr

breiten Bereich an Empfängertypen, die von preisgünstigen Lösungen mit einem kleinen Textdisplay bis zu High-End- Empfängern mit grafischer Benutzerschnittstelle und optionalen Text-zu-Sprache-Playback gehen.

Der Benutzer kann unmittelbar und interaktiv alle Informationen, die von der Radiostation geliefert werden, verarbeiten. Insofern ist der Dienst vergleichbar mit Videotext für das Fernsehen. Die Basisinformationen werden in einer einfachen Textform geliefert, wobei jedoch gleichzeitig die Option für aufwändigere grafische Darstellungen einschließlich einer Erweiterung zu Multimediaelementen wie Bild- o- der Videosequenzen und sonstigen Funktionserweiterungen möglich sein soll.

Andererseits ist es wichtig, dass ein Datenstrom, der z.B. von einem DAB-Sender ausgesendet wird, rückwärts-kompatibel ist, also sowohl von einfachen Empfängern, als auch von aufwändigeren Empfängern bzw. von Basis-Empfängern, welche einfache Empfänger sind, und Erweiterungs-Empfängern, welche aufwändigere Empfänger sind, gleichermaßen gelesen und verarbeitet werden kann.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein Konzept zum Erzeugen und Verarbeiten eines Datenstroms zu schaffen, der gleichermaßen von einfachen und von aufwändigen Empfängern verarbeitet werden kann, und das eine hohe Flexibilität der Datenübertragung und Verarbeitung erlaubt, und zwar zusätzlich zu den Textdaten, die von einfachen Empfängern und von aufwändigen Empfängern gleichermaßen interpretierbar sein sollen.

Diese Aufgabe wird durch eine Vorrichtung zum Erzeugen eines Datenstroms nach Patentenspruch 1, eine Vorrichtung zum Lesen eines Datenstroms nach Patentanspruch 15 oder 17, ein Verfahren zum Erzeugen eines Datenstroms nach Patentenspruch 28, eine Verfahren zum Lesen eines Datenstroms nach Patentanspruch 29 oder 30, oder ein Computer-Programm nach

Patentanspruch 31 oder einen Datenstrom nach Patentanspruch 32 gelöst.

Ein Datenstrom umfasst neben Textdaten eine Escape-Start- Sequenz, die eine erste Anzahl von Dateneinheiten definiert, die von einem Basis-Decodierer zu überspringen sind, und die von einem Erweiterungs-Decodierer zu interpretieren sind, die erste Anzahl von Dateneinheiten, eine Escape- Fortsetzungs-Sequenz, die eine zweite Anzahl von Datenein- heiten definiert, die wieder von einem Basis-Decodierer zu überspringen sind, und von einem Erweiterungs-Decodierer zusammen mit der ersten Anzahl von Dateneinheiten zu interpretieren sind, sowie die zweite Anzahl von Dateneinheiten und schließlich gegebenenfalls Textdaten.

Damit wird sichergestellt, dass einerseits kurze Start- Sequenzen genommen werden können, da die Anzahl der Dateneinheiten, auf die sich eine Escape-Start-Sequenz bezieht, höchstens so groß oder kleiner als die maximale Anzahl von Dateneinheiten ist, die durch die Escape-Start-Sequenz signalisierbar ist. Für die normalerweise eher wenigeren Fälle, bei denen die Anzahl der Dateneinheiten, die lediglich für bessere Decodierer gedacht sind, größer als die Anzahl von Dateneinheiten ist, die durch die Escape-Start-Sequenz interpretierbar ist, wird ferner eine Escape-Fortsetzungs- Sequenz vorgesehen, die eine Anzahl von Dateneinheiten definiert, die zusammen mit der ersten Anzahl von Dateneinheiten von einem Erweiterungs-Decodierer zu interpretieren sind. Für kürzere Datenblöcke mit einer kleineren Anzahl von Dateneinheiten werden somit immer lediglich nur die Escape-Start-Sequenz benötigt, die ein kurzer Code ist, da sie nicht eine beliebig lange Länge codieren soll, sondern lediglich eine begrenzte Länge der Dateneinheiten. Flexibilität wird erlangt, dass andererseits beliebig lange Daten- einschübe möglich sind, die durch eine beliebig häufige Wiederholung von Escape-Fortsetzungs-Sequenzen und zweiten Dateneinheiten nach einer Escape-Fortsetzungs-Sequenz in den Datenstrom eingebracht werden können.

Anders ausgedrückt ist die in dem Text für einen Erweite- rungs-Decodierer einzubringende Datenmenge durch den flexiblen Datenstrom nach oben unbegrenzt. Allerdings geht dies nicht zu Lasten der Länge der Escape-Start-Sequenz, da die Aufgabe der Signalisierung der Länge von sehr langen Dateneinschüben gewissermaßen auf mehrere Sequenzen verteilt wird, nämlich auf die Escape-Start-Sequenz und eine im Datenstrom auftretende spätere Escape-Fortsetzungs- Sequenz und ggf. weitere Escape-Fortsetzungs-Sequenzen, während für doch relativ häufig auftretende Dateneinschübe, die kurz sind, immer nur eine kurze Escape-Start-Sequenz benötigt wird. Der Erweiterungs-Decodierer weiß somit dann, wenn er eine Escape-Fortsetzungs-Sequenz in dem Datenstrom findet, dass die mit dieser Sequenz angezeigten Dateneinheiten zu den ersten Dateneinheiten dazu gehören. In den Dateneinheiten steht im Hinblick auf eine weitere Flexibilisierung bei der Verwendung des Datenstroms ein Datentypindikator, der den Typ der Daten und damit die mit diesen Daten durchzuführende Verarbeitung sowohl der ersten Dateneinheiten als auch der zweiten Dateneinheiten angibt. Der Datentypindikator steht z. B. vor den ersten Dateneinheiten, die durch die Escape-Start-Sequenz referenziert werden, und von den zweiten Dateneinheiten, die durch die Es- cape-Fortsetzungs-Sequenz referenziert werden.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeitungen detailliert erläutert. Es zeigen:

Fig. 1 ein Blockschaltbild einer Vorrichtung eines Datenstroms;

Fig. 2a ein Blockschaltbild eines Basis-Empfängers;

Fig. 2b ein Blockschaltbild eines Erweiterungs- Empfängers;

Fig. 3a eine Darstellung eines Datenstroms;

Fig. 3b eine vergrößerte Darstellung einer Escape-Start- Sequenz und einer Escape-Fortsetzungs-Sequenz ge- maß einem Aspekt;

Fig. 3c eine Darstellung der Daten, die durch die Escape- Start-Sequenz und die Escape-Fortsetzungs-Sequenz von Fig. 3a bzw. Fig. 3b referenziert werden, zu- sammen mit einem Datentyp-Indikator, welcher von einem Erweiterungs-Decodierer interpretierbar ist;

Fig. 4a einen Beispiel-Datenstrom ohne Fortsetzungscode;

Fig. 4b ein Codierbeispiel mit einem Fortsetzungscode;

Fig. 5 ein Flussdiagramm eines Verfahrens zum Erzeugen eines Datenstroms

Fig. 6A ein Flussdiagramm, das von einem Basis-Empfänger ausgeführt wird;

Fig. 6B ein Flussdiagramm, welches von einem Erweite- rungs-Empfänger ausgeführt wird; und

Fig. 7 verschiedene Datentypen, wie sie von einem Datentypindikator angezeigt werden können und wie sie verarbeitet werden können.

Fig. 1 zeigt eine Vorrichtung zum Erzeugen eines Datenstroms, die eine Einrichtung 10 zum Eintragen von Informationen in den Datenstrom aufweist, welcher an einem Ausgang 12 ausgegeben wird. Der Datenstrom wird in eine Einrichtung 14 zum übertragen und/oder Speichern des Datenstroms eingespeist, um im Beispiel einer Rundfunkübertragung über eine Freiraum-übertragungsstrecke 16 zu einem Empfänger bzw. De- codierer des Datenstroms übertragen zu werden. Alternativ

ist der Ausgang 16 der Einrichtung 14 zum übertragen oder Speichern mit einem Computer-lesbaren Speichermedium verbunden, wie beispielsweise einer Speicherkarte, die am Ausgang der Einrichtung angeschlossen ist oder die am anderen Ende einer übertragungsstrecke, beispielsweise in einem Empfänger vorgesehen ist, wenn dieser Empfänger die Daten lediglich speichert, jedoch noch nicht verarbeitet bzw. speichert und gleichzeitig verarbeitet. Ein computerlesbares Speichermedium kann somit eine nicht-flüchtige Spei- cherkarte in einem Empfänger oder Decodierer oder eine Festplatte eines Notebooks sein oder aber ein Arbeitsspeicher eines Decodierers, der so lange seine Daten hält wie er mit Strom bzw. Spannung versorgt wird.

Die Einrichtung 10 zum Eintragen enthält Textdaten IIa und Dateneinheiten IIb. Vorzugsweise wird in Bytes gerechnet. Eine Dateneinheit ist also 8 Bits bzw. 1 Byte lang. Diese Granularität wird bevorzugt, da in dieser Granularität sowohl Text als auch Daten gut handhabbar sind. In diesem Zu- sammenhang wird es bevorzugt zur Textcodierung das UTF8- Codierformat zu verwenden, bei dem typische ASCII-Zeichen jeweils mit einem Byte codiert werden, während z.B. deutsche Umlaute mit 2 Bytes codiert werden und z.B. chinesische Schriftzeichen mit 3, 4 oder mehr Bytes codiert wer- den. Ein Basisempfänger ist daher in der Lage, eine UTF8- Codierung zu decodieren, was beispielsweise durch Hinterlegung einer UTF8-Decodiertabelle geschehen kann. Je nach De- codierung erhält die Einrichtung zum Eintragen Textdaten und Dateneinheiten parallel. In diesem Falle erhält die Einrichtung zum Eintragen auch ein Zeitsteuersignal 11c, das festlegt, zu welchem Zeitpunkt Textdaten und zu welchem Zeitpunkt Dateneinheiten in den z.B. seriellen Datenstrom 12 eingespeist werden sollen. Alternativ kann die Einrichtung 10 zum Eintragen bereits Textdaten und Dateneinheiten über einen einzigen Eingang erhalten, welcher Textdaten und Dateneinheiten bereits in der richtigen gewünschten zeitlichen oder bitstrommäßigen Reihenfolge liefert.

Die Einrichtung zum Eintragen ist ausgebildet, um Textdaten in den Datenstrom einzutragen. Wenn Dateneinheiten eingetragen werden sollen, die von einem einfachen Decodierer übersprungen werden sollen, während die Dateneinheiten von einem aufwändigeren Decodierer gelesen bzw. verarbeitet werden sollen, wird in den Datenstrom eine Escape-Start- Sequenz eingetragen, wie sie beispielsweise in Fig. 3a angedeutet ist. Die Escape-Start-Sequenz 31 definiert eine erste Anzahl von Dateneinheiten, die von einem Basis- Decodierer zu überspringen sind und von einem Erweiterungs- Decodierer zu interpretieren sind. Diese erste Anzahl von Dateneinheiten wird dann ebenfalls in den Datenstrom eingetragen, wie es bei 32 in Fig. 3a zu sehen ist. Enthält der einzutragende Datenblock: mehr Dateneinheiten als sie von der Escape-Start-Sequenz zu definieren sind, so wird die Einrichtung 10 eine Escape-Fortsetzungs-Sequenz 33 einfügen, die eine zweite Anzahl von Dateneinheiten definiert, die von einem Basis-Decodierer zu überspringen sind, die allerdings von einem Erweiterungs-Decodierer zusammen mit der ersten Anzahl von Dateneinheiten zu interpretieren sind. Diese zweite Anzahl von Dateneinheiten wird dann e- benfalls in den Datenstrom eingetragen, wie es in Fig. 3a bei 34 zu sehen ist.

Je nach Implementierung, also wenn der Datenblock: ein großer Datenblock ist, der noch mehr Daten hat als sie durch die Escape-Fortsetzungs-Sequenz definiert werden können, wird eine weitere Escape-Fortsetzungs-Sequenz in den Datenstrom geschrieben, usw. bis alle an dieser Stelle in die Textdaten einzutragenden Dateneinheiten, die zusammen von einem Erweiterungs-Decodierer zu interpretieren sind, eingetragen worden sind.

Dann wird die Einrichtung 10 zum Eintragen von Fig. 1 typi- scherweise wieder Textdaten eintragen, die in Fig. 3a beispielsweise als zweite Textdaten 35 bezeichnet sind, so dass sich ein Datenstrom ergibt, bei dem erste Textdaten 30 und zweite Textdaten 35 vorhanden sind, die gewissermaßen

Daten einklammern, die von dem Basis-Decodierer zu überspringen sind, wobei der Basis-Decodierer zumindest in der Lage ist, die Escape-Start-Sequenz und insbesondere die Anzahl der Dateneinheiten sowie die Escape-Fortsetzungs- Sequenz und zumindest die dort enthaltene Anzahl von Dateneinheiten zu lesen, um die korrekte Anzahl von Dateneinheiten im Datenstrom überspringen zu können.

Fig. 3b zeigt ein Beispiel für eine Escape-Start-Sequenz 31, welche einen Escape-Start-Code 31a sowie einen nachgeschalteten Längen-Code 31b aufweist. Analog hierzu ist die Escape-Fortsetzungs-Sequenz 33 aufgebaut, die einen getrennten Fortsetzungs-Code 33a und einen nachgeschalteten Längencode 33b aufweist. Beispielsweise sind alle Codes 31a, 31b, 33a, 33b jeweils 1 Byte bzw. eine Dateneinheit lang, woraus sich ergibt, dass durch den Längencode 256 Dateneinheiten codierbar sind. Dies bedeutet, dass dann, wenn ein Datenblock mehr als 256 Dateneinheiten lang ist nach den ersten 256 Dateneinheiten der Fortsetzungscode 33a ge- schrieben bzw. in den Datenstrom eingetragen werden soll, um dann mit dem anschließenden Längencode 33b die noch verbleibenden Dateneinheiten des Datenblocks zu codieren.

Wäre eine Dateneinheit entsprechend länger, so könnte durch einen Längencode, der eine Dateneinheit lang ist, eine größere Anzahl von Dateneinheiten codiert werden, was dazu führen würde, dass bei einem solchen Datenstrom insgesamt die Anzahl der Fortsetzungscodes geringer wird. Wird dagegen der Längencode zu weniger als 8 Bits gewählt, so ist die maximale Anzahl der Daten, die durch den Längencode codiert werden kann, entsprechend geringer, so dass sich bei sonst gleichen Verhältnissen die Anzahl der Fortsetzungscodes im Datenstrom entsprechen erhöhen wird. Typischerweise existiert ein Optimum dahin gehend, dass für eine bestimmte mittlere Länge der Datenblöcke eine bestimmte Länge der Dateneinheiten existiert. Würde man den Längencode zu lange machen, so wäre dieses Prozedere ineffizient, da dann selbst für einen nur sehr kurzen Dateneinschub der gesamte

lange Längencode in den Datenstrom geschrieben werden soll. Würde man den Längencode dagegen zu kurz machen, so soll für die übergroße Anzahl von Datenblöcken ein Fortsetzungscode geschrieben werden, der insbesondere bei der in Fig. 3b gezeigten Implementierung dann nicht benötigt werden würde, wenn man gleich einen längeren Längencode genommen hätte.

Fig. 4a zeigt einen Beispiel-Datenstrom, der zu einer An- zeige „This is a great test!" führt, wie es bei 40 in Fig.

4a angezeigt ist. Der dazugehörige Datenstrom hat zunächst erste Textdaten 30 mit dem Text „This is a ". Hierzu werden

10 Bytes benötigt, da für jeden Buchstaben und für die

Leerstellen in der UTF8-Codierung jeweils 1 Byte gebraucht wird. Die ersten Textdaten sind somit 10 Bytes lang.

Dann sollen Daten eingefügt werden. Um dies zu signalisieren, findet sich im Byteindex (nullbasiert) 10 der Escape- Start-Code 31a, der bei dem in Fig. 4a gezeigten Beispiel IA ist, wobei das Präfix „0x" eine hexadezimale Darstellung andeutet. Selbstverständlich könnte für den Escape-Start- Code jeder andere Code eingesetzt werden, der sich von einem Textcode unterscheidet. Anders ausgedrückt, soll sich der Escape-Start-Code 31a, der bei dem Beispiel in Fig. 4a 1 Byte lang ist, von dem Code unterscheiden, der bei einer UTF8-Codierung am Bildschirm anzeigbare Zeichen (Zahlen, Buchstaben, ...) definiert. Die Escape-Codes sind also z. B. UTF8-Steuerzeichen oder sonst festgelegte Zeichen, die zu den Textcodes für am Bildschirm anzeigbare Zeichen un- terschiedlich sind.

An den Escape-Start-Code 31a anschließend findet sich ein Längen-Code 31b, der anzeigt, wie lang das Datenfeld ist, das an den Längecode 31b angeschlossen ist. Das Längenfeld enthält den Code 4, so dass konsequenterweise die ersten Dateneinheiten 32 in Fig. 4a 5 Bytes umfassen. Hintergrund hierfür ist, dass das Längenfeld den Term „-1" implizit um-

fasst, weil ein Längenangabe von Null keinen sinn machen würde.

Dann folgt wieder ein Textfeld, nämlich das Wort „great" mit 5 Bytes, woraufhin wieder, bei Byteindex 22 ein Escape- Start-Code 31a geschrieben ist, dem ein Längen-Code 31b folgt, der einen Wert von 5 hat, da dann, an den Längen- Code anschließenden Byteindizes 24 bis 29 6 Byte Daten geschrieben sind. Ausgangsseitig findet sich wieder ein Text- block 35, welcher 6 Bytes lang ist, da für jeden Buchstaben von „Test" 1 Byte benötigt wird, und da für das Ausrufezeichen ebenfalls 1 Byte benötigt wird.

Damit ergibt sich ein 36 Byte langer Datenstrom, der an zwei unterschiedlichen Stellen insgesamt 11 Byte eingefügte Zusatzdaten enthält.

Ein Basis-Decodierer wird die Daten einlesen und darstellen und wird dann, wenn er auf den Escape-Start-Code 31a stößt, diesen dahin gehend interpretieren, dass er einen zu dem Escape-Start-Code gehörigen Längen-Code sucht. Eine Interpretation dieses Längen-Codes führt den Basis-Decodierer dann dazu, dass er die Dateneinheiten, die durch den Escape-Start-Code und den Längen-Code referenziert werden, ein- fach überspringt, also ignoriert und nicht weiter beachtet. Der Basis-Decodierer liest dann die Textdaten in den Byteindizes 17 bis 21 ein, um dann, wieder einen Code 31a als Escape-Start-Code zu erkennen und eine zugehörige Längenangabe im Code 31b zu suchen, um wieder die Anzahl von Bytes zu überspringen, die im Code 31b signalisiert sind.

Damit wird auf einfache Art und Weise sichergestellt, dass ein Basis-Decodierer selbst einen Datenstrom lesen kann, der für neuere bzw. aufwändigere Erweiterungs-Decodierer geschrieben ist. Die Tatsache, dass der Basis-Decodierer zwar mit den Daten nichts machen kann, allerdings die Escape-Start-Sequenz mit Code und Längenangabe korrekt interpretieren kann, stellt die Rückwärtskompatibilität sicher.

Ein Erweiterungs-Decodierer ist allerdings in der Lage, nicht nur die Startsequenz, also die Codes 31a und 31b, zu interpretieren, sondern auch die Daten nicht nur einfach zu überspringen, sondern zu verarbeiten, um damit neben einer einfachen Textdarstellung zusätzliche Funktionen ausführen zu können, die über den Datenstrom und die zu einer Escape- Sequenz zugehörigen Daten gesteuert werden.

Fig. 4b zeigt ein Codierbeispiel mit Fortsetzungs-Code, wobei bei dem in Fig. 4b gezeigten Beispiel davon ausgegangen wird, dass ein Datenblock länger als 256 Byte ist. Muss ein so großer Datenblock eingefügt werden, so wird zunächst, beim Datenbyteindex 0 eine Escape-Start-Sequenz eingefügt, die wiederum aus einem Escape-Start-Code 31a und einem nachgeschalteten Längen-Code 31b besteht. Der Längenwert im Längen-Code 31b ist nun jedoch nicht, wie in Byteindex 11 oder Byteindex 23 irgendeine Zahl, sondern das Maximum, nämlich „FF". Dann im Anschluss an den Länge-Code 31b wer- den in den Byteindizes 2 bis 257 die 256 ersten Dateneinheiten 32 in den Datenstrom geschrieben. Da noch mehrere weitere Dateneinheiten vorhanden sind, nämlich insgesamt 262 Bytes, wird der Datenstromerzeuger feststellen, dass er noch nicht alle Dateneinheiten in den Datenstrom geschrie- ben hat. Er schreibt daher einen Fortsetzungs-Code 33a in den Datenstrom, der sich von dem Escape-Start-Code 31a unterscheiden wird, damit der Decodierer weiß, dass die Dateneinheiten, die zum Fortsetzungs-Code gehören, die beispielsweise dem Fortsetzungs-Code unmittelbar folgen, noch zu den Dateneinheiten gehören, welche vor dem Fortsetzungs- Code verarbeitet bzw. eingelesen worden sind. Bei dem in Fig. 4b gezeigten Beispiel müssen noch sechs Dateneinheiten untergebracht werden, so dass der an den Fortsetzungs-Code folgende Längen-Code 33b eine Länge von 6 (Code 0x05) sig- nalisiert. Dann, im Anschluss an diesen Längen-Code wird mit dem Schreiben der zweiten Dateneinheiten 34 der Ein- schub in den Datenstrom beendet, wobei dann, ab dem Bytein-

dex 266, das in Fig. 4b gezeigt ist, z. B. ein normaler Text 35 kommen kann.

Es sei darauf hingewiesen, dass je nach Implementierung der Escape-Fortsetzungs-Code 33a nicht unbedingt zum Escape- Start-Code 31a unterschiedlich sein soll. Für den Basis- Decodierer spielt dies nämlich keine Rolle. Er soll lediglich sowohl den Escape-Start-Code 31a als auch den Escape- Fortsetzungs-Code 33a interpretieren und im Anschluss an diese Interpretation den nachgeschalteten Längen-Code lesen, um zu wissen, wie viel Daten zu überspringen sind. Ein Erweiterungs-Decodierer wäre in einem solchen Fall so implementiert, dass er dann, wenn zum ersten Mal ein Escape- Start-Code auftritt, dem ein Längen-Code mit maximaler Län- ge, also z. B. FF folgt, automatisch davon ausgeht, dass die dann wieder folgenden Dateneinheiten noch zu den Dateneinheiten 32 gehören und somit gemeinsam verarbeitet werden müssen. Die Bedeutung des Escape-Start-Codes würde somit dadurch „umgeschaltet" werden, dass der an den Escape- Start-Code 31a anschließende Längen-Code 31b eine maximale Länge anzeigt. Wenn der Escape-Start-Code 31a und der Fortsetzungs-Code 33a den selben Wert haben, so würde der Deco- dierer dann, wenn der Längen-Code 31b nach dem ersten Escape-Start-Code 31a nicht den maximalen Wert, also FF hat, den dann an die Dateneinheiten anschließenden Fortsetzungs- Code nicht als Fortsetzungs-Code, sondern als neuen Start- Code interpretieren, so dass die Daten, die auf den zweiten Start-Code folgen, nicht als Fortsetzung der Daten, die auf den ersten Start-Code folgen, verstanden werden, sondern als neue Daten eines neuen Datenblocks, der wiederum anders verarbeitetet werden kann. Die Interpretation, ob Daten Fortsetzungsdaten sind oder keine Fortsetzungsdaten sind, ist dann von besonderer Bedeutung, wenn in jedem Datenblock, der aus mehreren Dateneinheiten besteht, an einer bestimmten Stelle, wie beispielsweise am Anfang, ein Datentyp-Indikator steht, welcher dann, wenn die Daten keine Fortsetzungsdaten sind, gelesen wird, bzw. der dann, wenn die Daten Fortsetzungsdaten sind, von einem Decodierer

nicht erwartet wird, und auch nicht ausgelesen wird, wie es noch Bezug nehmend auf Fig. 3c erläutert werden wird.

Nachfolgend wird Bezug nehmend auf Fig. 5 eine beispielhaf- te Sequenz von Schritten zum Erzeugen eines Datenstroms dargestellt, wie sie von einem Datenstromgenerator durchgeführt werden kann, der, wie in Fig. 1 gezeigt, aufgebaut ist.

Das Flussdiagramm in Fig. 5 startet mit einem Schritt des Eintragens von Text 50. In einem Schritt 51 wird überprüft, ob nach dem Eintragen von Text Daten vorhanden sind, die eingetragen werden müssen. Wird diese Frage mit nein beantwortet, so wird das nächste Textobjekt in den Datenstrom eingetragen, wie es durch die Schleife 52 dargestellt ist. Wird die Frage dagegen mit ja beantwortet, so wird von der Einrichtung 10 zum Eintragen eine Escape-Start-Sequenz eingetragen, wie es im Schritt 53 dargestellt ist. Die Escape- Start-Sequenz enthält eine Information über die Länge der Daten, also die Anzahl der Dateneinheiten. Nach dem Eintragen der Escape-Start-Sequenz in den Datenstrom werden die ersten Dateneinheiten eingetragen, wie es bei 54 gezeigt ist. In einem Schritt 55 wird überprüft, ob alle Daten in den Datenstrom eingetragen sind, die zu einem Datenblock gehören. Wird diese Frage mit nein beantwortet, sind also keine Daten mehr vorhanden, so wird wieder ein Textobjekt oder ein Escape-Code eingetragen, wie es durch eine Schleife 56 dargestellt ist.

An dieser Stelle sei darauf hingewiesen, dass die Escape- Startsequenzen vor einem Text, nach einem Text oder zwi ^¬ schen einem Text kommen können. Alternativ kann eine Escape-Start-Sequenz allerdings auch vor oder nach einer anderen Escape-Sequenz sein, wobei eine andere Escape-Sequenz andere Dinge als spezielle Daten anzeigen kann.

Wird dagegen bestimmt, dass noch Daten vorhanden sind, so wird eine Escape-Fortsetzungs-Sequenz eingetragen, wie es

im Schritt 57 gezeigt ist. In dieser Escape-Fortsetzungs- Sequenz wird auch die Länge der Dateneinheiten, die dann in einem Schritt 58 eingetragen werden, festgelegt. In einem Schritt 59 wird dann überprüft, ob noch weitere Daten vor- handen sind. Ist dies der Fall, also werden noch weitere Daten des Datenblocks eingetragen, so wird eine weitere Escape-Fortsetzungs-Sequenz geschrieben, wie es bei 60 gezeigt ist. Sind dagegen nunmehr alle Daten eingetragen, so wird wiederum Text eingetragen, im Prinzip immer auf die selbe Art und Weise, wie es bei Schritt 50 gezeigt ist. Der übersichtlichkeit halber wird dieses Eintragen von Text nach einem Datenblock mit einem Schritt 61 in Fig. 5 bezeichnet.

Es sei darauf hingewiesen, dass die überprüfung im Schritt 55, ob noch Daten vorhanden sind, oder im Schritt 59, ob noch Daten vorhanden sind, nicht unbedingt durchgeführt werden soll, wenn parallel oder in einem Nebenprozess die Länge der einzutragenden Daten bestimmt wird, wie es in Fig. 5 beim Block 62 gezeigt ist. Im Block 62 wird untersucht, wie lange ein einzufügender Datenblock ist. Aufgrund der Anzahl von maximal zu codierenden Dateneinheiten in der Escape-Start-Sequenz weiß der Block 52 unmittelbar, wie viele Fortsetzungs-Sequenzen benötigt werden. In dem in Fig. 4b gezeigten Ausführungsbeispiel stellt der Block 62 fest, dass in die Escape-Start-Sequenz die maximale Länge einzutragen ist, und dass dann eine Fortsetzungs-Sequenz eingetragen wird, deren Länge ebenfalls bestimmt wird, wie es durch die Steuerpfeile 63a und 63b in Fig. 5 angedeutet ist. In diesem Fall soll daher die Prüfung im Block 55 oder im Block 59 nicht durchgeführt werden, wie es durch einen gestrichelten Verbindungspfeil 64 angedeutet ist. Diese Alternative stellt daher bereits eine Lösung dar, bei der die Escape-Start-Sequenz bereits vor dem Eintragen der Daten- einheiten fertig geschrieben ist, während in der zweiten Alternative die Länge in die Escape-Start-Sequenz erst eingetragen wird, nachdem die ersten Dateneinheiten bzw. die zweiten Dateneinheiten eingetragen worden sind.

Nachfolgend wird Bezug nehmend auf Fig. 2a und Fig. 2b auf Empfänger zum Empfangen bzw. Decodieren des Datenstroms eingegangen, wobei dieser Datenstrom prinzipiell so wie in Fig. 3a gezeigt aufgebaut sein kann, dahin gehend, dass er Textdaten enthält, eine Escape-Start-Sequenz enthält, eine Anzahl von Dateneinheiten enthält, dann eine Escape- Fortsetzungs-Sequenz aufweist und anschließend an die Escape-Fortsetzungs-Sequenz wieder eine Anzahl von Dateneinhei- ten aufweist, der dann Textdaten folgen können, oder der eine weitere Escape-Fortsetzungs-Sequenz folgen kann.

Der Basis-Empfänger zum Lesen des Datenstroms umfasst eine Eingangsschnittstelle 70, um den Datenstrom 16 zu erhalten. Der Datenstrom wird dann zu einem Prozessor 71 übermittelt, der mit einer Textanzeige 72 gekoppelt ist, um den Text aus den Datenstrom zu lesen und anzuzeigen, wobei der Prozessor dann, wenn er auf eine Escape-Start-Sequenz stößt, die Länge bzw. Anzahl der Dateneinheiten ermittelt, um diese An- zahl von Dateneinheiten zu überspringen, und wobei der Prozessor ferner dann, wenn er auf eine Escape-Fortsetzungs- Sequenz stößt, ebenfalls die Anzahl der zu der Fortsetzungs-Sequenz gehörigen Dateneinheiten überspringt, wie es im Block 71 von Fig. 2a angezeigt ist.

Ein Erweiterungs-Empfänger, wie er in Fig. 2b gezeigt ist, umfasst zusätzlich zu den Elementen von dem Basis-Empfänger aus Fig. 2a noch einen Modul bzw. eine Funktionalität des Prozessors 71, das die Dateneinheiten nicht einfach über- springen werden, sondern gemeinsam ausgeführt werden.

Zusätzlich zur Textanzeige 72, die beim Erweiterungs- Empfänger genauso funktionieren kann oder wird wie beim Basis-Empfänger, wird beim Erweiterungs-Empfänger, also eine Interpretation der Dateneinheiten nach der Escape-Start- Sequenz und nach der Escape-Fortsetzungs-Sequenz vorgenommen.

Nachfolgend wird Bezug nehmend auf Fig. 6A und Fig. 6B eine Gegenüberstellung der Funktionalitäten eines Basis- Empfängers ohne Datenverarbeitungsmöglichkeit und eines Erweiterungs-Empfängers mit Datenverarbeitungsmöglichkeit ge- geben.

Wenn sowohl Basis-Empfänger als auch Erweiterungs-Empfänger Textdaten lesen, wird der Prozessor 71 von Fig. 2a oder Fig. 2b die Textdaten verarbeiten, decodieren und dann der Textanzeige 72 liefern und darstellen, wie es bei dem Schritt 80 von Fig. 6A und Fig. 6B gezeigt ist. Stoßen die Empfänger auf eine Escape-Start-Sequenz, so wird diese Escape-Start-Sequenz gelesen, wie es in einem Schritt 82 dargestellt ist. Insbesondere wird der Basis-Empfänger im Schritt 82 sehen, wie viele Dateneinheiten durch die Escape-Start-Sequenz, also beispielsweise durch den Längen-Code 31b von Fig. 3b angezeigt werden. In einem Schritt 83 wird der Basis-Empfänger dann die Anzahl von Dateneinheiten, die er im Schritt 82 herausgefunden hat, überspringen. Dagegen wird der Erweiterungs-Empfänger in einem Schritt 84 die Dateneinheiten nach der Escape-Start-Sequenz nicht überspringen, sondern lesen. Hierzu benötigt der Erweiterungs- Empfänger vorzugsweise ebenfalls die Längen-Information. Wenn die Daten jedoch unterschiedlich zu Text codiert sind, wäre die Längen-Information nicht unbedingt nötig.

In einem Schritt 85 lesen sowohl der Basis-Empfänger als auch der Erweiterungs-Empfänger die Escape-Fortsetzungs- Sequenz, die auf die ersten Dateneinheiten 32 von Fig. 3a folgt. Der Basis-Empfänger ist hierbei hauptsächlich an dem Längen-Code interessiert, um zu wissen, wie viel Daten zu überspringen sind, was der Basis-Empfänger dann in einem Schritt 86 auch tut. Dagegen wird der Erweiterungs- Empfänger in einem Schritt 87 die zweite Anzahl von Daten- einheiten nicht überspringen, sondern einlesen, wie es bei 87 dargestellt ist. Dann, in einem Schritt 88, für den es keinen parallelen Basis-Empfänger gibt, wird der Erweiterungs-Empfänger die Funktionalität bzw. das Modul 73 von

Fig. 2b aktivieren und eine gemeinsame Ausführung der ersten und zweiten Dateneinheiten erreichen. Sind dann alle Dateneinheiten verarbeitet, so wird sowohl der Basis- Empfänger als auch der Erweiterungs-Empfänger in einem Schritt 89 die zweiten Textdaten darstellen, also die Daten 35, die bei dem in Fig. 3a gezeigten Datenstrom folgen. Ist dagegen der zweite Längen-Code 33b ebenfalls mit der Maximallänge versehen, also bei dem Beispiel mit „FF", so kann der Erweiterungs-Empfänger einen weiteren Escape- Fortsetzungs-Code einlesen, den daran anschließenden Längen-Code interpretieren und diese dann referenzierten Dateneinheiten ebenfalls wieder zu den ersten und zweiten Dateneinheiten hinzuzufügen, um wieder eine gemeinsame Ausführung zu ermöglichen.

Nachfolgend wird Bezug nehmend auf Fig. 3c näher darauf eingegangen, was im Schritt 88 vom Erweiterungs-Empfänger durchgeführt wird, bzw. wie die Daten interpretiert werden, die nach dem Escape-Start-Code und dem Fortsetzungs-Code extrahiert worden sind.

Die erste Anzahl von Dateneinheiten umfasst bei einem Beispiel einen Datentyp-Indikator 90, der beispielsweise 1 Byte lang ist. Dieser Datentyp-Indikator 90 findet sich nur in einem bestimmten, z. B. dem ersten Byte der ersten Anzahl von Dateneinheiten, auf die durch eine Escape-Start- Sequenz 31 Bezug genommen wird. Dagegen ist kein solcher Datentyp-Indikator in der zweiten Anzahl von Dateneinheiten vorhanden, sondern die zweite Anzahl von Dateneinheiten 34 trägt voll zu den gemeinsam auszuführenden Dateneinheiten bzw. der so genannten „Nutzdaten-Payload" bei. Ein Erweite- rungs-Decodierer wird dann, wenn ein Datentyp-Indikator 90 verwendet wird, die Daten, die nach dem Fortsetzungs-Code enthalten sind, als zum selben Typ zugehörig interpretieren wie die Daten, die in der ersten Anzahl von Dateneinheiten enthalten sind. Damit wird ermöglicht, dass für die zweite Anzahl von Dateneinheiten, die nach dem Fortsetzungs-Code im Datenstrom auftreten, keinerlei Signalisierungen benö-

tigt werden, die Informationen darüber enthalten, ob dies Fortsetzungs-Daten sind, oder welchen Datentyp die zweite Anzahl von Dateneinheiten hat. Stattdessen wird der Daten ^¬ typ-Indikator in der ersten Anzahl von Dateneinheiten ein- fach für die zweite Anzahl von Dateneinheiten ebenfalls angewendet bzw. übernommen bzw. werden die Daten in der zweiten Anzahl von Dateneinheiten einfach an die erste Anzahl von Dateneinheiten angehängt, als ob es nie eine Trennung gegeben hätte, um dann gemeinsam ausgeführt bzw. verarbei- tet zu werden.

Vorteilhaft am erfindungsgemäßen skalierbaren Datenstrom ist, dass er auf allgemeinen Standards aufbaut. So können Objekte im XML-Format importiert und weiterverarbeitet wer- den.

Der Datenstrom ist besonders geeignet für digitale Rundfunksysteme, und zwar als zusätzlicher Datenkanal, der den Zuhörern einen Zusatzwert schafft, da sie nunmehr einen un- mittelbaren Zugriff auf Textinformationen haben, überall wo sie sich befinden, wobei Empfänger für den digitalen Rundfunk entweder einfache Empfänger sind und dann wenigstens Textinformationen darstellen oder besonders aufwändige und damit aber natürlich auch teurere Empfänger sind, die sämt- liehe Datenverarbeitungen der ersten Anzahl von Dateneinheiten und der zweiten Anzahl von Dateneinheiten durchführen können. Es können also sowohl preisgünstige und damit als Massenprodukt verfügbare Empfänger mit einem Textdisplay bereits einen Zusatzwert für den Zuhörer erzeugen. Ge- eignet ist jedoch der Datenstrom auch für High-End- Empfänger mit grafischer Benutzerschnittstelle und optionaler Sprachwiedergabe. Dies alles wird erreicht durch einfache Implementierungen selbst in preisgünstigen Empfängern und durch eine besonders einfache Benutzung, bei der sich ein Benutzer selbst nicht darum kümmern muss, welche Daten aktuell gültig sind. Stattdessen findet dies, also das Verwerfen der Daten oder das Ausführen der Daten je nachdem,

welchen Empfänger ein Benutzer hat, voll automatisch statt, ohne dass der Benutzer sich hierum kümmern müsste.

Ferner sind Textdaten objektorientiert bei bestimmten Bei- spielen dargestellt, wobei diese Objekte alle selber für sich stehen und abgeschlossene Einheiten sind. Damit müssen keine globalen Datenstrukturen im Empfänger assembliert o- der gehalten werden. Objekte werden in der Form eines Datenkarussells gesendet, und es wird ein Daten-Caching im Empfänger vorteilhafter weise eingesetzt. Textdaten, die beispielsweise Menü-Konstruktionen, Nachrichtenartikel oder Ticker-Nachrichten sein können, werden als sog. NML-Objekte übertragen, wobei NML für News Service Mark Language steht und ähnlichkeiten zu XML-basierten binär codierten Inhalts- darstellungen hat.

Als Start-Escape-Code 31a wird vorzugsweise der hexadezimale Code IA verwendet und als Fortsetzungscode wird beispielsweise der hexadezimale Code IB verwendet. Der Daten- typindikator 90 von Fig. 3c kann diverse Datentypen anzeigen, wie es nachfolgend dargestellt wird. Die nachfolgenden Datentypindikator-Werte sind lediglich beispielhaft. Ein Indikator von „00" zeigt Padding an. Die darin enthaltenen Daten tragen Padding-Bytes, wobei dieser Inhalt sowohl vom Erweiterungs-Decodierer als auch vom Basis-Decodierer ignoriert wird. Ein alternativer Datensatztyp hat einen Indikator „01" und stellt einen absoluten Timeout dar. Es wird die absolute Präsentations-Timeout-Dauer eines NML-Objekts definiert. Wenn dieser Timeout geschehen ist, wird das NML- Objekt nicht länger angezeigt. Diese Escape-Sequenz-Code- Darstellung wird benötigt, um einzelne NML-Objekte zu markieren. Ein allgemeiner Timeout für den gesamten Dienst wird alternativ dargestellt. Die Payload nach dem Datentypindikator enthält die Anzahl von 15 Minuten seit dem 1.1.2000, als 24-Bit-Ganzzahl ohne Vorzeichen, wodurch mehr als 450 Jahre umfasst werden. Ein Datentypindikator vom Typ „02" zeigt einen relativen Timeout dar. Hier wird die relative Präsentation-Timeout-Dauer eines NML-Objekts defi-

niert. Wenn diese Dauer verstrichen ist wird das NML-Objekt nicht länger angezeigt. Der Timeout beginnt mit jedem Empfang eines NML-Objekts, selbst wenn das Objekt bereits im Cache gespeichert ist. Dieser Escape-Sequenz-Code dient zum Markieren einzelner NML-Objekte. Die Payload-Daten enthalten die Anzahl von Minuten als lβ-Bit-Ganzzahl ohne Vorzeichen (unsigned) , wodurch mehr als 45 Tage erfasst werden. Die Timeout-Daten werden allgemein gesagt von der Timeoutsteuerung 100 von Fig. 7 verarbeitet.

Der Datentyp-Indikator „03" betrifft ein allgemeines Link- Ziel. Ein allgemeines Link-Ziel ist ein Ziel, das präsentiert oder z. B. durch die Verbindungssteuerung 101 aktiviert wird, wenn der Benutzer explizit die Ausführung einer Aktion verlangt, wenn also eine „Hot Button"-Funktionalität für eine Benutzerinteraktion dargestellt bzw. geschaffen wird. Allgemeine Link-Ziele können für alle Typen von NML- Objekten definiert werden. Die Verfügbarkeit eines allgemeinen Link-Targets für ein gegenwärtig dargestelltes NML- Objekt wird einem Benutzer auf irgendeine Weise mitgeteilt, wenn er einen Erweiterungs-Empfänger hat. Die Payload- Daten, die beispielsweise in Fig. 3c gezeigt sind, haben folgendes Format. 1 Byte stellt einen Verbindungs-Typ dar und n Bytes stellen eine Link-Adresse dar. Die folgenden Link-Typ-Werte sind beispielsweise verfügbar. Wenn der Link-Typ einen Wert von beispielsweise „00" hat, so sind die darauffolgenden 2-Bytes eine Objekt-ID eines anderen NML-Objekts in dem selben Datenservice.

Ein anderes Link-Typ-Byte von beispielsweise „01", dem ein URI-String folgt, zeigt auf andere DAB/DRM-Multiplexes, Dienste oder Dienstelemente.

Ein anderer Verbindungstyp, wie beispielsweise „02" die ein URL-String zeigt, zeigt auf eine Internetadresse oder ein Dokument .

Ein anderer Linktyp wie beispielsweise „03", dem eine Telefonnummer folgt, zeigt auf einen Sprachservice, der über Telefon erreicht werden kann. Die Nummer startet dabei beispielsweise mit einem internationalen Präfix, beispielswei- se „+ [internationale Ländervorwahl]".

Allgemein ist ein Erweiterungs-Empfänger ausgebildet, um unbekannte Link-Typ-Werte zu ignorieren.

Ein weiterer Datentypindikator „FF" wird beispielsweise als proprietärer Datentypindikator aufgefasst, der Daten voran geht, die nur bestimmte Erweiterungs-Empfänger betreffen, die diese proprietären Daten auswerten können.

Die Dateneinheiten können im Gegensatz zu den vorstehenden Objektmanagement-Typen auch Inhalts-Management-Typen umfassen. Ein Datentyp-Indikator von „20", der auch als Schlüsselwort bezeichnet wird, markiert ein folgendes Schlüsselwort zusammen mit einer optionalen Schlüsselwortbeschrei- bung. Das Schlüsselwort kann beispielsweise dazu verwendet werden, um einen Empfänger-basierten Suchindex zu erzeugen, wie es durch die Suchanfrageerzeugungseinrichtung 102 in Fig. 7 gezeigt ist. Der Nutzdaten-Abschnitt hat folgendes Format. Zunächst kommt ein Längencode mit der Schlüssel- wortlänge, wobei der Wert gleich der Länge - 1 als vorzeichenlose Ganzzahl angegeben wird. Es wird die Anzahl der visuellen Textzeichen identifiziert, die diesem Datenabschnitt folgen, und die als Schlüsselwort behandelt werden sollen. Dann folgt eine Beschreibung mit n Bytes, wobei die optionale Beschreibung zusätzlich zu dem Schlüsselwort in- dexiert sein kann und/oder dem Benutzer dargestellt werden kann.

Ein anderer Datentypindikator von beispielsweise „21" stellt eine Makrodefinition dar. Ein Makro erlaubt die Definition von Textabschnitten einschließlich optionaler Escape-Sequenzen, die mehrere Male irgendwo in dem Inhaltsabschnitt mit einer einfachen Referenz eingesetzt werden kön-

nen. Beispielsweise kann das Makro Sprachbeschreibungen de ^¬ finieren, die zusätzlich zu textlichen Textelementen darge ^¬ stellt werden sollen. Der Datenabschnitt hat ein Format, bei dem zunächst eine Makro-ID (0 bis 255) von einem Byte, welche die folgende Makrodefinition identifiziert. Dann kommt eine Makro-Definition mit n-Bytes. Der Text (einschließlich Escapesequenzen) , der eingefügt werden soll, immer wenn dieses Makro durch seine ID referenziert werden wird, ist in der Makrodefinition mit n-Bytes enthalten. Es sei darauf hingewiesen, dass die Makros nicht unbedingt für essentielle Informationen verwendet werden sollten, da sie von Empfängern auch ignoriert werden können. Ein anderer Datentypindikator „22" beispielsweise steht für eine Makroreferenz. Die Makrodefinition, die durch seine ID referen- ziert wird, wird an der Position dieser Escape-Sequenz für eine Darstellung dem Benutzer gegenüber virtuell eingeführt. Der Datenabschnitt enthält eine 1-Byte-Makro-ID (0 bis 255), die eine Makrodefinition referenziert. Makros werden allgemein durch den Makroprozessor 103 in Fig. 7 verarbeitet.

Eine andere Gruppe von Datentypen kann Sprachunterstüt- zungstypen umfassen. Ein Datentyp-Indikator von beispielsweise „A0" definiert eine Standard-Sprache bzw. eine vor- eingestellte Sprache. Hier wird die voreingestellte Sprache des NML-Objekts beschrieben bzw. referenziert. Der Datenabschnitt, also die Payload von Fig. 3c trägt einen 3- Buchstaben ISO-Sprachcode aus Kleinbuchstaben.

Ein anderer Sprachunterstützungstyp, der beispielsweise mit „AI" referenziert wird, ist der Sprachabschnitt. Er definiert die Sprache einer spezifizierten Nummer eines Textabschnitts bzw. eines speziellen Teils eines NML-Objekts. Der Payload-Abschnitt hat folgendes Format. Es kommt eine Text- länge mit einem Byte, dessen Wert gleich dem Wert der Anzahl von Dateneinheiten dieser Textlänge - 1 ist als vorzeichenlose Ganzzahl. Dadurch wird die Anzahl von visuellen Textzeichen identifiziert, die diesem Datenabschnitt fol-

gen, für den die Sprachdefinition gilt. Dann folgt eine Gruppe von 3 Bytes mit einer Sprachdefinition, welche einen 3-Buchstaben ISO-Sprachcode aus Kleinbuchstaben trägt.

Ein anderer Sprachunterstützungstyp wird durch den Datentyp-Indikator „A2" beispielsweise indiziert. Er betrifft Sprachphoneme und definiert eine Phonembeschreibung eines Textabschnitts unter Verwendung des internationalen phonetischen Alphabets (IPA) . Der Payload-Abschnitt hat ein For- mat, bei dem zunächst eine Textlänge mit einem Byte kommt, dessen Wert eine Ganzzahl ist. Dieses Byte identifiziert die Anzahl von visuellen Textzeichen, die diesem Datenabschnitt folgen, welche durch eine phonetische Definition repräsentiert werden sollen. Dann folgt eine Gruppe von n- Bytes mit IPA-Phonemen. Diese Gruppe enthält die Phonemdefinitionen der Phoneme als IPA-Notationen.

Ein anderer Sprachunterstützungstyp, der mit dem Datentyp- Indikator „A3" beispielsweise referenziert ist, umfasst ei- ne Sprachpause, wodurch eine Pause für Text-zu-Sprache- Prozessoren definiert wird, die an der Position der Escape- Sequenz eingefügt werden soll. Der Datenabschnitt trägt 1 Byte als vorzeichenlose Ganzzahl, wobei dieses Byte eine Sprachdauer in Einheiten von 0,1 Sekunden definiert.

Ein anderer Sprachunterstützungstyp, der beispielsweise den Datentypindikator „A4" haben kann, definiert Zeichen und insbesondere eine Anzahl von visuellen Textzeichen, die der Escape-Sequenz folgen, die von einem Text-zu-Sprache Pro- zessor als individuelle Zeichen oder Ziffern anstatt durchgehender Worte oder Zahlen behandelt werden sollen. Der Payload-Abschnitt trägt 1 Byte, das die Anzahl von visuellen Textzeichen definiert als vorzeichenlose Ganzzahl mit einem entsprechenden Wert.

Es sei darauf hingewiesen, dass alle diese Datentypen je nach maximaler Zahl, die durch den Längencode dargestellt werden kann, entweder in den der ersten Anzahl von Daten-

einheiten 32 von Fig. 3a dargestellt werden können oder a- ber dann wenn die Anzahl von Dateneinheiten nicht reicht um sämtliche Daten zu schreiben, in der zweiten Anzahl von Dateneinheiten enthalten sind, die jeweils mit einer Escape- Fortsetzungs-Sequenz eingeleitet werden. Es müssen also nicht unbedingt alle Datentypen, die durch einen Datentypindikator referenziert werden, sowohl Dateneinheiten nach einer Escape-Start-Sequenz und einer Escape-Fortsetzungs- Sequenz haben. Stattdessen können auch kurze Datentypen Ie- diglich Daten enthalten, die keine Fortsetzung benötigen, weil die Anzahl der Dateneinheiten dieser Daten kleiner ist als die maximal durch den Längencode 31b darstellbare Anzahl von Dateneinheiten ist.

Abhängig von den Gegebenheiten kann jedes erfindungsgemäße Verfahren in Hardware oder in Software implementiert werden. Die Implementierung kann auf einem digitalen Speichermedium, insbesondere einer Diskette oder CD mit elektronisch auslesbaren Steuersignalen erfolgen, die so mit einem programmierbaren Computersystem zusammenwirken können, dass das Verfahren ausgeführt wird. Allgemein besteht die Erfindung somit auch in einem Computer-Programm-Produkt mit einem auf einem maschinenlesbaren Träger gespeicherten Programmcode zur Durchführung eines erfindungsgemäßen Verfah- rens, wenn das Computer-Programm-Produkt auf einem Rechner abläuft. In anderen Worten ausgedrückt kann die Erfindung somit als ein Computer-Programm mit einem Programmcode zur Durchführung des Verfahrens realisiert werden, wenn das Computer-Programm auf einem Computer abläuft.