(57)【要約】  データストリームを生成時、テキストデータと、エスケープ開始シーケンスと、第１の数のデータ単位と、エスケープ継続シーケンスと、第２の数のデータ単位とがデータストリーム中に入力される。基本デコーダは、テキストデータのみを表示し、エスケープ開始シーケンスおよびエスケープ継続シーケンスによって参照されたデータ単位をスキップし、その一方、拡張デコーダは、そういったデータ単位を読み、それらを共に処理する。
2010518766.tif 000002
【特許請求の範囲】
【請求項１】
データストリームを生成するための装置であって、
入力手段（１０）を備え、前記入力手段は、テキストデータ（３０）をデータストリーム中に入力するためのものであり、エスケープ開始シーケンス（３１）を前記データストリーム中に入力するためのものであって、前記エスケープ開始シーケンスは、基本デコーダによってスキップされるべきであって、かつ、拡張デコーダによって解釈されるべきである第１の数のデータ単位を定義し、前記入力手段は、前記第１の数のデータ単位（３２）を前記データストリーム中に入力するためのものであり、エスケープ継続シーケンス（３３）を前記データストリーム中に入力するためのものであって、前記エスケープ継続シーケンスは、基本デコーダによってスキップされるべきであって、かつ、拡張デコーダによって前記第１の数のデータ単位とともに解釈されるべきである第２の数のデータ単位を定義し、前記入力手段は、前記第２の数のデータ単位（３４）を前記データストリーム中に入力するためのものである、装置。
【請求項２】
前記データストリームは、シリアルデータストリームであり、前記入力手段（１０）は、前記エスケープ開始シーケンス（３１）を前記データストリーム中に前記テキストデータ（３０）の後ろまたは前に入力し、かつ、前記エスケープ継続シーケンス（３３）を前記データストリーム中に前記第１の数のデータ単位（３２）の後ろに入力するように実装されている、請求項１に記載の装置。
【請求項３】
前記入力手段（１０）は、まず前記テキストデータ（３０）を、次に前記エスケープ開始シーケンス（３１）を、次に前記第１の数のデータ単位を、次に前記エスケープ継続シーケンス（３３）を、次に前記第２の数のデータ単位（３４）を、前記データストリーム中に置くように実装されている、請求項１または２に記載の装置。
【請求項４】
前記エスケープ開始シーケンス（３１）は、エスケープ開始コード（３１ａ）と長さコード（３１ｂ）とを有し、または前記エスケープ継続シーケンス（３３）は、継続コード（３３ａ）と長さコード（３３ｂ）とを有し、前記エスケープ開始コード（３１ａ）または前記継続コード（３３ａ）は、テキストコードと異なる、請求項１から３のいずれか１項に記載の装置。
【請求項５】
前記長さコード（３１ｂ）は、前記データストリーム中に前記エスケープ開始コード（３１ａ）の直後に入力され、または前記長さコード（３３ｂ）は、前記データストリーム中に前記継続コード（３３ａ）の直後に入力される、請求項４に記載の装置。
【請求項６】
前記データストリーム中に継続コード（３３ａ）の後に入力された長さコード（３３ｂ）と、前記データストリーム中にエスケープ開始コード（３１ａ）の後に入力された長さコード（３１ｂ）とは、長さエンコードのための同じエンコードテーブルから生じている、請求項１から５のいずれか１項に記載の装置。
【請求項７】
前記データストリーム中の前記データ単位は、等しく、予め定義された複数のビットを各々含む、請求項１から６のいずれか１項に記載の装置。
【請求項８】
前記予め定義された複数のビットは、１つのデータ単位が１バイトであるよう８に等しい、請求項７に記載の装置。
【請求項９】
前記データストリームは、第１の型の基本受信機によって、および第２の型の拡張受信機によって読むことができるべきものであり、前記入力手段（１０）は、前記基本受信機および前記拡張受信機によって検出することができるテキストデータコードを用いるよう
に実装されている、請求項１から８のいずれか１項に記載の装置。
【請求項１０】
エスケープ開始コード（３１ａ）は、エスケープ継続シーケンス（３３）内の継続コード（３３ａ）と長さが同じであり、この長さは、１つのデータ単位の長さと等しい、請求項１から９のいずれか１項に記載の装置。
【請求項１１】
長さコードは、１から２５６バイトのコンテンツ長をエンコードするように実装されている、請求項１０に記載の装置。
【請求項１２】
前記手段（１０）は、前記エスケープ開始シーケンス（３１）と予め決定された関係で、前記第１の数のデータ単位と前記第２の数のデータ単位（３４）との両方のデータ型を示すデータ型インジケータ（９０）を、前記データストリーム中に入力するように実装されている、請求項１から１１のいずれか１項に記載の装置。
【請求項１３】
前記データ型インジケータ（９０）は、基本デコーダによって解釈可能でなくともよいが、拡張デコーダによって解釈可能なものである、請求項１２に記載の装置。
【請求項１４】
前記入力手段（１０）は、前記データ型インジケータに続いて、前記データ型インジケータ（９０）によって示されたデータ型を有するデータを入力するように実装されている、請求項１２または１３に記載の装置。
【請求項１５】
前記入力手段（１０）は、前記データ型インジケータ（９０）を、前記データストリーム中に前記エスケープ開始シーケンス（３１）の長さコード（３１ｂ）の直後の第１の数のデータ単位（３２）に入力するように実装されている、請求項１３または１４に記載の装置。
【請求項１６】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリームを読むための装置であって、
テキストデータ（３０）を表示するための手段（７２）と、
プロセッサ（７１）とを備え、前記プロセッサは、前記第１の数のデータ単位をスキップするための前記エスケープ開始シーケンスから前記第１の数のデータ単位が決定されるよう前記エスケープ開始シーケンス（３１）を解釈するためものであり、前記第２の数のデータ単位（３４）をスキップするための前記エスケープ継続シーケンスから前記第２の数のデータ単位（３４）が決定されるよう前記エスケープ継続シーケンス（３３）を解釈するためものである、装置。
【請求項１７】
前記データストリームは、バッファ中にラッチされており、前記プロセッサ（７１）は、前記第１の数のデータ単位（３２）および前記第２の数のデータ単位（３４）を前記バッファから削除し、連続的に前記バッファを読出すように実装されており、または前記バッファを読出すとき、前記第１の数のデータ単位（３２）および前記第２の数のデータ単位（３４）が格納されている前記バッファの領域がスキップされるように前記バッファを制御するように実装されている、請求項１６に記載の装置。
【請求項１８】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリーム読むための装置であって、
前記テキストデータ（３０）を表示するための手段（７２）と、
プロセッサ（７１）とを備え、前記プロセッサは、前記第１の数のデータ単位（３２）が読込まれるよう前記エスケープ開始シーケンス（３１）を解釈するためのものであり、、前記第２の数のデータ単位（３４）が読込まれるよう前記エスケープ継続シーケンス（３３）を解釈するためのものであり、前記テキストデータ（３０）を表示することに加えてまたは代わりに、前記第１の数のデータ単位（３２）と前記第２の数のデータ単位（３４）とを一緒に処理する（７３）ためのものである、装置。
【請求項１９】
前記第１の数のデータ単位（３２）は、前記第１の数のデータ単位（３２）と前記第２の数のデータ単位（３４）とのデータ型を示すためのデータ型インジケータ（９０）を含み、
前記プロセッサ（７１）は、前記データ型インジケータ（９０）を読出し、前記データ型インジケータ（９０）に従って、前記第１の数のデータ単位（３２）と前記第２の数のデータ単位（３４）とを共に処理するように実装されている、請求項１８に記載の装置。
【請求項２０】
前記第１の数のデータ単位（３２）および前記第２の数のデータ単位（３４）は、接続ターゲットを定義し、
前記プロセッサ（７１）は、前記ターゲットへのデータ接続を実行するように実装されている、請求項１８または１９に記載の装置。
【請求項２１】
前記ターゲットは、データストリーム中のテキストデータを備えたオブジェクト、ＤＡＢ／ＤＲＭ多重伝送、サービスまたはサービス要素、インターネットアドレス、インターネット上の文書、または電話番号である、請求項２０に記載の装置。
【請求項２２】
前記プロセッサ（７１）は、前記第１のデータ単位（３２）または前記第２のデータ単位（３４）を、解釈不可能なターゲットをそのデータ単位が定義するとき、無視するように実装されている、請求項２０または２１に記載の装置。
【請求項２３】
前記第１の数のデータ単位（３２）もしくは前記第２の数のデータ単位（３４）、またはさらなる数のデータ単位は、オブジェクトの絶対または相対タイムアウトまでの時間を定義し、
前記プロセッサ（７１）は、前記タイムアウトまでの時間と前記テキストデータおよび拡張されたマルチメディアコンテントを表示するためのプロセッサ時間との比較を有するタイムアウト制御（１００）を、前記タイムアウトまでの時間に前記プロセッサ時間が達していないときにのみ行なうように実装されている、請求項１８から２２のいずれか１項に記載の装置。
【請求項２４】
前記第１の数のデータ単位（３２）および前記第２の数のデータ単位（３４）、またはさらなるデータ単位は、キーワードとして解釈されるテキスト文字を定義し、前記プロセッサ（７１）は、前記キーワードに基づいてデコードするための装置においてデータベース問合せを行なうための検索問合せ生成手段（１０２）を有する、請求項１８から２３のいずれか１項に記載の装置。
【請求項２５】
前記第１の数のデータ単位（３２）もしくは前記第２の数のデータ単位（３４）、またはさらなるデータ単位は、マクロデータを有し、前記プロセッサ（７１）は、前記マクロデータによって定義されたマクロを実行するためのマクロプロセッサ機能（１０３）を行なうように実装されている、請求項１８から２４のいずれか１項に記載の装置。
【請求項２６】
前記第１の数のデータ単位（３２）、前記第２の数のデータ単位（３４）、またはさらなる数のデータ単位は、音声記述を表わすデータ型インジケータ（９０）を有し、前記プロセッサ（７１）は、音声出力に影響を与えるための前記データ単位によって制御するこ
とができる音声プロセッサ（７３、１０４）を有する、請求項１８から２５のいずれか１項に記載の装置。
【請求項２７】
前記第１の数のデータ単位（３２）、前記第２の数のデータ単位（３４）、またはさらなるデータ単位は、音声プロセッサ（７３）のための音声支援データを含むデータ型インジケータ（９０）を有し、前記音声支援データは、テキスト部分の言語を示し、音声音素を含み、音声中断に関連し、または音声文字を有し、
前記プロセッサ（７１）は、音声支援データを出力するように、かつその音声支援データを、音声出力を生成するためまたは音声出力に影響を与えるための前記音声プロセッサに供給するように実装されている、請求項１８から２６のいずれか１項に記載の装置。
【請求項２８】
データストリームを生成する方法であって、
テキストデータ（３０）をデータストリーム中に入力するステップと、
エスケープ開始シーケンス（３１）を前記データストリーム中に入力するステップとを備え、前記エスケープ開始シーケンスは、基本デコーダによってスキップされるべきであって、かつ、拡張デコーダによって解釈されるべき第１の数のデータ単位を定義し、さらに
前記第１の数のデータ単位（３２）を前記データストリーム中に入力するステップと、
エスケープ継続シーケンス（３３）を前記データストリーム中に入力するステップとを備え、前記エスケープ継続シーケンスは、基本デコーダによってスキップされるべきかつ拡張デコーダによって前記第１の数のデータ単位とともに解釈されるべき第２の数のデータ単位を定義し、さらに
前記第２の数のデータ単位（３４）を前記データストリーム中に入力するステップを備える、方法。
【請求項２９】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリームを読む方法であって、
テキストデータ（３０）を表示するステップ（７２）と、
前記第１の数のデータ単位が前記エスケープ開始シーケンスから決定されるよう前記エスケープ開始シーケンス（３１）を解釈するステップと、
前記エスケープ開始シーケンスを解釈するステップに基づいて前記第１の数のデータ単位をスキップするステップと、
前記第２の数のデータ単位（３４）が前記エスケープ継続シーケンスから決定されるよう前記エスケープ継続シーケンス（３３）を解釈するステップと、
前記エスケープ継続シーケンスを解釈するステップに基づいて前記第２の数のデータ単位（３４）をスキップするステップとを備える、方法。
【請求項３０】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリームを読む方法であって、
前記第１の数のデータ単位（３２）が決定されるよう前記エスケープ開始シーケンス（３１）を解釈するステップと、
前記エスケープ開始シーケンスを解釈するステップに基づいて前記第１の数のデータ単位を読込むステップと、
前記第２の数のデータ単位（３４）が決定されるよう前記エスケープ継続シーケンス（３３）を解釈するステップと、
前記エスケープ継続シーケンスを解釈するステップに基づいて前記第２の数のデータ単
位を読込むステップと、
前記テキストデータ（３０）を表示するステップに加えてまたは代わりに、前記第１の数のデータ単位（３２）と前記第２の数のデータ単位（３４）とを一緒に処理する（７３）ステップとを備える、方法。
【請求項３１】
コンピュータ上で実行されるときに、請求項２８、２９、または３０に記載の方法を行なうためのプログラムコードを備えたコンピュータプログラム。
【請求項３２】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリーム。
【請求項３３】
コンピュータ読取可能媒体に格納された、請求項３２に記載のデータストリーム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ伝送に関し、特に、単純な受信機に対してテキストを、より複雑な受信機に対してテキストに加えてデータを用い、どちらの型の受信機もデータストリームを評価することができる、より簡単なデータ伝送に関する。
【背景技術】
【０００２】
今では、個々の受信機端末が数多く存在し、こういった受信機はすべて、伝送された情報をモバイル方式で受信することができる。この幅広い層の特徴は、このようなさまざまな情報受信機の処理および出力能力が非常に異なることである。たとえば、ノートパソコンは、かなりのプロセッサリソースおよびメモリリソースを有するので、伝送されたデータのモバイル受信機として非常に高い処理および出力能力を有している。一方、たとえば、同じく放送データチャネルなどの情報サービスに参加している携帯電話は、非常に制限された処理リソースおよび出力リソースしか有さない。携帯電話として意図されてすらおらず、サッカーリーグの結果、または他のスポーツの結果、新聞の見出し、天気予報などのデータを受信するための単なるモバイル放送受信機として意図されている小型モバイル放送受信機は、それぞれのデータ放送サービスが用いられる場合、処理および出力リソースがさらに一層制限されている。
【０００３】
デジタル放送のためのそのようなテキストベースの情報サービスは、単純なデータ収集および再使用のみならず非常に効率的な放送伝送にも適しており、「Journaline（登録商標）」という呼称で存在している。このデータサービスは、小さなテキスト表示部を有する費用対効果の大きいソリューションから、グラフィカルユーザインターフェイスと任意選択的テキスト‐音声再生とを備えたハイエンド受信機までにわたる非常に広い範囲の受信機型に対応している。
【０００４】
ユーザは、ラジオ局によって提供されたあらゆる情報を、直ちにかつインタラクティブに処理することができる。この点で、このサービスは、テレビのためのビデオテキストと比較することができる。基本的な情報は、単純なテキストフォームで提供されるが、同時に、イメージまたはビデオシーケンスなどのマルチメディア要素への拡張を含むより複雑なグラフィカル表現のオプションおよび他の機能拡張が可能とされる。
【０００５】
一方、たとえばＤＡＢ伝送器によって放送される、データストリームは、下位互換性があることが重要である。これは、このデータストリームを読み、処理することが、単純な受信機によってもより複雑な受信機によっても、すなわち単純な受信機である基本受信機によってもより複雑な受信機である拡張受信機によっても、等しく可能であることを意味する。
【発明の概要】
【課題を解決するための手段】
【０００６】
この発明は、単純な受信機と複雑な受信機との両方によって等しく解釈可能であるべきテキストデータに加えて、単純な受信機および複雑な受信機によって等しく処理することができ、データ伝送および処理の高い柔軟性を可能にするデータストリームを、生成し、処理するための概念を提供することを目的とする。
【０００７】
この目的は、請求項１に従ったデータストリームを生成するための装置、請求項１５または１７に従ったデータストリームを読むための装置、請求項２８に従ったデータストリ
ームを生成するための方法、請求項２９または３０に従ったデータストリームを読むための方法、または請求項３１に従ったコンピュータプログラム、または請求項３２に従ったデータストリームによって達成される。
【０００８】
テキストデータとは別に、データストリームは、基本デコーダによってスキップされるべきかつ拡張デコーダによって解釈されるべきである第１の数のデータ単位を定義するエスケープ開始シーケンスと、第１の数のデータ単位と、基本デコーダによって再びスキップされるべきかつ第１の数のデータ単位とともに拡張デコーダによって解釈されるべきである第２の数のデータ単位を定義するエスケープ継続シーケンスと、さらには第２の数のデータ単位と、最後に、必要な場合、テキストデータとを含む。
【０００９】
このようにして、一方では、エスケープ開始シーケンスが関連付けられているデータ単位の数は、最大でもエスケープ開始シーケンスによって信号通知することができるデータ単位の最大数と同じ多さまたはそれよりも少ないので、短い開始シーケンスを用いることが確実にできるようになる。単に高品位のデコーダのためだけに考慮されているデータ単位の数が、エスケープ開始シーケンスによって解釈可能なデータ単位の数よりも多くなるという、通常ほとんど無い場合については、さらに、拡張デコーダによって第１の数のデータ単位とともに解釈されるべきデータ単位の数を定義するエスケープ継続シーケンスが与えられる。よって、データ単位の数が少ないより短いデータブロックについては、常にエスケープ開始シーケンスが必要とされるにすぎない。このエスケープ開始シーケンスは、任意に長い長さではなく、単なる制限された長さのデータ単位をエンコードすることを意図されているに過ぎないので、短いコードである。他方で、エスケープ継続シーケンスとエスケープ継続シーケンスの後の第２のデータ単位との任意に周期的な繰返しによって、データストリーム中に導入することができる任意の長さのデータ導入が可能であるという点において、柔軟性が得られる。
【００１０】
言い換えれば、柔軟性のあるデータストリームにより、拡張デコーダのためにテキストに導入されるデータ量は無限である。しかしながら、これは、エスケープ開始シーケンスの長さに影響を及ぼさない。なぜなら、非常に長いデータ挿入の長さを信号通知するタスクは、実際にはいくつかのシーケンスに、すなわち、エスケープ開始シーケンスと、データストリーム中で後に出現するエスケープ継続シーケンスと、おそらくさらなるエスケープ開始シーケンスとに分割されており、その一方、比較的頻繁に出現する短いデータ挿入は、非常に短いエスケープ開始シーケンスのみが必要であるためである。よって、拡張デコーダは、データストリーム中にエスケープ継続シーケンスを見つけると、このシーケンス付きで表示されるデータ単位は、第１のデータ単位に属すると知る。いっそうの柔軟化に関しては、データストリームを用いるとき、データの型を、したがって第１のデータ単位と第２のデータ単位との両方からなるこういったデータで実行されるべき処理を通知するデータ型インジケータが、データ単位中に位置する。データ型インジケータは、たとえば、エスケープ開始シーケンスによって参照される第１のデータ単位の前かつエスケープ継続シーケンスによって参照される第２のデータ単位の前に位置する。
【００１１】
この発明の好ましい実施例は、添付の図面を参照して以下に説明される。
【図面の簡単な説明】
【００１２】
【図１】データストリーム装置のブロック図である。
【図２】図２ａは、基本受信機のブロック図であり、図２ｂは、拡張受信機のブロック図である。
【図３】図３ａは、データストリームの説明図であり、図３ｂは、１つの局面に従ったエスケープ開始シーケンスおよびエスケープ継続シーケンスの拡大された説明図であり、図３ｃは、図３ａまたは図３ｂのエスケープ開始シーケンスおよびエスケープ継続シーケンスによって参照されるデータを、拡張デコーダによって解釈可能なデータ型インジケータとともに説明する図である。
【図４】図４ａは、継続コードが無いデータストリーム例を示す図であり、図４ｂは、継続コードがあるエンコード例を示す図である。
【図５】データストリームを生成する方法のフロー図である。
【図６】図６Ａは、基本受信機によって実行されるフロー図であり、図６Ｂは、拡張受信機によって実行されるフロー図である。
【図７】データ型インジケータによって示されることができ、処理されることができる異なるデータ型を示す図である。
【発明を実施するための形態】
【００１３】
図１には、データストリーム中に情報を入力するための手段１０を含む、データストリームを生成するための装置が示されており、このデータストリームは出力１２で出力される。データストリームは、データストリーム伝送および／または格納手段１４へ送られ、データストリームの受信機またはデコーダへそれぞれ、放送伝送の例において自由空間伝送路を介して、伝送される。これに代えて、伝送または格納手段１４の出力１６は、この手段の出力に接続された、または、受信機がデータを格納するのみで処理しないもしくはデータを同時に格納および処理するとき受信機の中などの伝送路の他方の端部に設けられた、メモリカードなどのコンピュータ読取可能記憶媒体に接続されている。よって、コンピュータ読取可能記憶媒体は、受信機もしくはデコーダ中の不揮発性メモリカード、またはノートパソコンのハードディスク、またはデコーダのワーキングメモリであり得、このワーキングメモリは、電流または電圧をそれぞれ供給されている限りそのデータを保持する。
【００１４】
入力手段１０は、テキストデータ１１ａとデータ単位１１ｂとを含む。好ましくは、計算はバイトで行なわれる。よって、１つのデータ単位は、８ビットすなわち１バイト長である。この粒度（granularity）は、テキストおよびデータの両方をこの粒度で簡単に扱うことができるので好ましい。これに関連して、テキストエンコードのためにＵＴＦ８エンコードフォーマットを用いることが好ましく、典型的なＡＳＣＩＩ文字は、各々１バイトでエンコードされ、その一方、たとえばドイツ語のウムラウトは、２バイトでエンコードされ、たとえば漢字は、３、４またはそれ以上のバイトでエンコードされる。したがって、基本受信機は、ＵＴＦ８エンコードをデコードすることができ、これは、たとえば、ＵＴＦ８デコードテーブルを置くことによって行なうことができるということになる。デコードによっては、入力手段は、テキストデータとデータ単位を並列に得る。この場合、入力手段は、時間制御信号１１ｃも受信し、この時間制御信号は、どんな時間にテキストデータが、またどんな時間にデータ単位が、たとえばシリアルデータストリーム１２中に送られるべきかを決定する。これに代えて、入力手段１０は、単一の入力を介してテキストデータおよびデータ単位を予め受信していることができ、この単一の入力は、テキストデータおよびデータ単位を正しい所望の時間的またはビットストリーム順序で予め提供する。
【００１５】
入力手段は、テキストデータをデータストリーム中に入力するように実現される。単純なデコーダによってスキップされるべきだが、より複雑なデコーダによって読まれるまたは処理されるべきデータ単位が入力されるべきとき、エスケープ開始シーケンスが、たとえば図３ａに示すように、データストリーム中に入力される。エスケープ開始シーケンス３１は、基本デコーダによってスキップされるべきかつ拡張デコーダによって解釈されるべき第１の数のデータ単位を定義する。次に、この第１の数のデータ単位も、図３ａの３２に示すようにデータストリームに入力される。入力されるべきデータブロックがエスケープ開始シーケンスによって定義されるべきデータ単位よりも多いデータ単位を含む場合
、手段１０は、基本デコーダによってスキップされるべきだが拡張デコーダによって第１の数のデータ単位とともに解釈されるべきである第２の数のデータ単位を定義するエスケープ継続シーケンス３３を入力する。次に、この第２の数のデータ単位も、図３ａの３４に示すように、データストリーム中に入力される。
【００１６】
実装によっては、すなわち、データブロックがエスケープ継続シーケンスによって定義することができるよりもさらに多いデータを有する大きなデータブロックであると、拡張デコーダによって共に解釈されるべきテキストデータにこの位置で入力されるべきすべてのデータ単位が入力されるまで、もう１つのエスケープ継続シーケンスが、データストリームなどに書込まれる。
【００１７】
次に、図１の入力手段１０は、典型的に、図３ａにたとえば第２のテキストデータ３５として示されているテキストデータを、データストリームが生じるよう再び入力し、第１のテキストデータ３０と第２のテキストデータ３５とは、ある意味では、基本デコーダによってスキップされるべきデータを囲むよう存在し、基本デコーダは、データストリーム中の正しい数のデータ単位をスキップすることができるためには、少なくとも、エスケープ開始シーケンスと、特にデータ単位の数と、さらにはエスケープ継続シーケンスと、少なくとも含まれたデータ単位の数とを読むことができる。
【００１８】
図３ｂには、エスケープ開始コード３１ａのみならずダウンストリーム長さコード３１ｂも含むエスケープ開始シーケンス３１の例が示されている。エスケープ継続シーケンス３３は、同様に構築されており、別個の継続コード３３ａと、ダウンストリーム長さコード３３ｂとを含む。たとえば、コード３１ａ、３１ｂ、３３ａ、３３ｂはすべて、各々１バイトまたはそれぞれ１個のデータ単位の長さであり、その結果、長さコードによって２５６個のデータ単位をエンコードすることができる。これは、データブロックが２５６個のデータ単位よりも長いとき、データブロックの残っているデータ単位を後続の長さコード３３ｂでエンコードするためには、継続コード３３ａが、第１の２５６個のデータの後ろにデータストリーム中に書込まれるまたは入力されるべきであるということを意味する。
【００１９】
データ単位が、それぞれ、より長い場合、１個のデータ単位の長さである長さコードは、多数のデータ単位をエンコードし得、これは、そのようなデータストリーム中で、継続コードの全体数が少なくなる効果があるであろう。しかしながら、８ビット未満の長さコードが選択される場合、長さコードによってエンコードすることができるデータの最大の数は、それぞれ、より少なく、そのため他の点では同じ状況において、データストリーム中の継続コードの数は対応して増加する。典型的に、データブロックのある平均的な長さに対してある長さのデータ単位が存在するのが最適である。長さコードが長くされすぎた場合、単なる非常に短いデータ挿入に対してまで長い長さコード全体をデータストリームに書込まなくてはならないため、この手順は非効率となるであろう。一方、長さコードが短くされすぎた場合、継続コードは、非常に多数のデータブロックについて書かれるであろう。これは、より長い長さコードが開始からすぐに用いられていたならば、特に図３ｂに示される実装において不要であっただろう。
【００２０】
図４ａには、図４ａの４０に示すように、「This is a great test!」という表示をもたらす例示的なデータストリームが示されている。関連付けられたデータストリームは、最初に、テキスト「This is a 」というテキストを備えた第１のテキストデータ３０を有する。これは、ＵＴＦ８エンコードにおいては、各アルファベットおよび空白に１バイトずつ必要とされるので、１０バイトを必要とする。よって、第１のテキストデータは、１０バイト長である。
【００２１】
次に、データが挿入される。これを信号通知するために、図４ａに示す例においては１Ａであるエスケープ開始コード３１ａは、（０ベースの）バイトインデックス１０に置かれており、プレフィックス「０ｘ」は、１６進表示を示す。当然、テキストコードとは異なる任意の他のコードがエスケープ開始コードとして挿入され得る。言い換えれば、図４ａにおける例においては１バイト長であるエスケープ開始コード３１ａは、ＵＴＦ８エンコードで画面に表示可能な文字（数字、アルファベット、…）を定義するコードとは異なるべきである。したがって、エスケープコードは、たとえば、画面に表示可能な文字のためのテキストコードとは異なるＵＴＦ８制御文字または他の固定文字である。
【００２２】
エスケープ開始コード３１ａに続くのは、長さコード３１ｂであり、この長さコードは、長さコード３１ｂに続くデータフィールドがどれぐらいの長さかを示す。長さフィールドは、コード４を含み、その結果、図４ａにおける第１のデータ単位３２は、５バイトを含む。０という長さは意味をなさないであろうため、長さフィールドは暗黙的に「−１」という項を含むということがこの背景にある。
【００２３】
次に、別のテキストフィールド、すなわち５バイトの単語「great」が続くと、再び、バイトインデックス２２に、エスケープ開始コード３１ａが書かれており、５の値を有する長さコード３１ｂがこれに続く。なぜならば、この長さコードに続いて、次に６バイトデータがバイトインデックス２４から２９に書かれているためである。出力側には、別のテキストブロック３５が存在し、「test」の各アルファベットに１バイトが必要とされ、感嘆符にも１バイトが必要とされるので、このテキストブロックは６バイト長である。
【００２４】
これは、２つの異なる位置に挿入された１１バイトの追加データを含む、３６バイト長のデータストリームをもたらす。
【００２５】
基本デコーダは、データを読込み、表現し、次に、エスケープ開始コード３１ａに遭遇すると、このエスケープ開始コードを、基本デコーダはエスケープ開始コードと関連付けられた長さコードを検索する、という意味に解釈する。次に、この長さコードを解釈すると、基本デコーダは、エスケープ開始コードおよび長さコードによって参照されたデータ単位をスキップし、すなわちこのデータ単位を無視し、このデータ単位をそれ以上考慮しなくなる。次に、基本デコーダは、バイトインデックス１７から２１にあるテキストデータを読込んで、次に再びコード３１ａをエスケープ開始コードとして認識し、コード３１ｂの中に信号通知されているバイト数を再びスキップするために、コード３１ｂにある関連付けられた長さインジケータを検索する。
【００２６】
よって、単純な方法で確実に、基本デコーダは、より新しくより複雑な拡張デコーダのために書かれたデータストリームを読むことさえできるようになる。基本デコーダがデータを取扱うことはできないが、コードと長さインジケータと備えたエスケープ開始シーケンスを正しく解釈できるということは、下位互換性を保証する。
【００２７】
しかしながら、拡張デコーダは、開始シーケンスすなわちコード３１ａおよび３１ｂを解釈することができるのみならず、またデータを単にスキップするのみならず、単純なテキスト表示とは別に、データストリームおよびエスケープシーケンスに関連付けられたデータを介して制御することができる追加機能を行うことができるように、開始シーケンスを処理することができる。
【００２８】
図４ｂには、継続コードのあるエンコード例が示されており、図４ｂに示された例においては、１つのデータブロックが２５６バイトよりも長いと想定されている。そのような大きなデータブロックが挿入されるべき場合、まず、エスケープ開始シーケンスが、データバイトインデックス０に挿入され、このエスケープ開始シーケンスは、この場合もエス
ケープ開始コード３１ａとダウンストリーム長さコード３１ｂとからなる。しかしながら、今度は、長さコード３１ｂにある長さ値は、バイトインデックス１１またはバイトインデックス２３におけるように数字ではなく、最大値、すなわち「ＦＦ」である。次に、長さコード３１ｂに続いて、２５６個の第１のデータ単位３２がデータストリーム中にバイトインデックス２から２５７に書込まれる。いくつかのさらなるデータ単位が存在するので、すなわち全体としては２６２バイトなので、データストリーム生成器は、自身がまだデータストリーム中にすべてのデータ単位を書いていないと判断する。結果として、このデータストリーム発生器は、エスケープ開始コード３１ａとは異なる継続コード３３ａをデータストリーム中に書込み、これにより、デコーダは、たとえばこの継続コードの直後に続く、継続コードに属するデータ単位は、継続コードの前に処理されたまたは送られたデータ単位に引続き属すると知る。図４ｂに示す例においては、さらに６個のデータ単位が入力されなくてはならず、そのため継続コードに続く長さコード３３ｂが６という長さ（コード０ｘ０５）を信号通知する。次に、この長さコードに続いて、データストリームへの挿入は、第２のデータ単位３４を書くことで終了され、次に、図４ｂに示すバイトインデックス２６６から開始して、たとえば、通常のテキスト３５が続くことができる。
【００２９】
なお、実装によっては、エスケープ継続コード３３ａは、必ずしもエスケープ開始コード３１ａと異ならなくともよいことに留意されるべきである。これは、基本デコーダにとって重要ではない。基本デコーダは、いくつのデータがスキップされるべきかを知るために、単にエスケープ開始コード３１ａおよびエスケープ継続コード３３ａの両方を解釈し、この解釈に続いて、ダウンストリーム長さコードを読まなくてはならないにすぎない。この場合、拡張デコーダは、後ろに最大長さの長さコードすなわちたとえばＦＦが続くエスケープ開始コードが最初に出現すると、後続のデータ単位が引続きデータ単位３２に属し、よって共に処理されなくてはならないと自動的に見なすよう、実装されるであろう。よって、エスケープ開始コードの意味は、エスケープ開始コード３１ａに続く長さコード３１ｂが最大長さを示す点で「切換えられる」であろう。エスケープ開始コード３１ａと継続コード３３ａとが同じ値を有するとき、デコーダは、第１のエスケープ開始コード３１ａの後の長さコード３１ｂが最大値すなわちＦＦを有さないと、データ単位に続く継続コードを継続コードとしてではなく新しい開始コードとして解釈するであろう。そのため、第２の開始コードに続くデータは、第１の開始コードに続くデータの続きとしてではなく、異なる処理を受けることができる新しいデータブロックの新しいデータとして解釈される。データが継続データか、または非継続データかの解釈は、データ型インジケータが、いくつかのデータ単位からなるどのデータブロックにも、初めなどのある位置に位置するとき特に重要であり、それは、以下に図３ｃを参照して述べるように、データが非継続データのとき読まれ、または、データが継続データのとき、デコーダによって予期されておらず読出されもしない。
【００３０】
以下に、図５を参照して、図１に示すように構成されたデータストリーム生成器が実行できる、データストリームを生成するためのステップの例示的なシーケンスを、説明する。
【００３１】
図５のフロー図は、テキストを入力するステップ５０から始まる。ステップ５１において、テキスト入力後、まだ入力されなければならないデータが存在するかどうかが確認される。この問いの答がｎｏの場合、ループ５２によって示されるように、次のテキストオブジェクトがデータストリーム中に入力される。しかしながら、この問いの答がｙｅｓの場合、ステップ５３に示されるように、入力手段１０は、エスケープ開始シーケンスを入力する。エスケープ開始シーケンスは、データの長さ、すなわちデータ単位の数についての情報を含む。エスケープ開始シーケンスをデータストリーム中に入力した後、５４に示すように、第１のデータ単位が入力される。ステップ５５において、データブロックに属するすべてのデータがデータストリームに入力されたかどうかが確認される。
【００３２】
この問いに対する答がｎｏの場合、すなわちそれ以上データが存在しない場合、ループ５６によって示されるように、テキストオブジェクトまたはエスケープコードが、再び入力される。
【００３３】
なおここで、エスケープ開始シーケンスは、テキストの前、テキストの後、またはテキスト間に位置し得ることが留意されるべきである。しかしながら、これに代えて、エスケープ開始シーケンスは、別のエスケープシーケンスの前または後ろにあることもでき、別のエスケープシーケンスは、特定のデータ以外のものを示すことができる。
【００３４】
しかしながら、データがまだ存在すると判断された場合、ステップ５７に示すように、エスケープ継続シーケンスが入力される。このエスケープ継続シーケンスにおいて、次にステップ５８において入力されるデータ単位の長さも判断される。ステップ５９において、さらなるデータが存在するかどうかが確認される。そうである場合、すなわち、６０に示すようにデータブロックのさらなるデータが入力される場合、もう１つのエスケープ継続シーケンスが書かれる。一方、すべてのデータが入力されている場合、テキストはステップ５０に示すのと基本的にいつも同じ方法で再び入力される。わかりやすくするために、このデータブロックの後へのテキスト入力は、図５のステップ６１によって示されている。
【００３５】
なお、ステップ５５におけるデータがまだ存在するかどうかについての確認、またはステップ５９におけるデータがまだ存在するかどうかについての確認は、図５のブロック６２に示すように、入力されるべきデータの長さが並列にまたは別個のプロセスで判断されるとき、必ずしもは実行されないことが留意されるべきである。ブロック６２において、挿入されるべきデータブロックはどれぐらいの長さかが判断される。エスケープ開始シーケンスにおいて最大でエンコードされるデータ単位の数に基づいて、ブロック５２は、直ちに、いくつの継続シーケンスが必要かを知る。図４ｂに示す実施例において、図５の制御矢印６３ａおよび６３ｂによって示されるように、ブロック６２は、エスケープ開始シーケンスに最大長さが入力されるべきことと、次に継続シーケンスが入力されることとを判断し、この継続シーケンスの長さも判断される。この場合、点線の接続矢印６４によって示されるように、ブロック５５またはブロック５９における確認は行なわれない。この代替例は、エスケープ開始シーケンスがデータ単位の入力の前に既に完了しているソリューションを既に表わしており、第２の代替例においては、長さは、第１のデータ単位または第２のデータ単位がそれぞれ入力された後に、単にエスケープ開始シーケンスに入力される。
【００３６】
以下に、図２ａおよび図２ｂを参照して、データストリームを受信するまたはデコードするための受信機が述べられる。このデータストリームは、基本的に図３ａに示すように、テキストデータと、エスケープ開始シーケンスと、いくつかのデータ単位と、次にエスケープ継続シーケンスと、このエスケープ継続シーケンスに続いて、再びいくつかのデータ単位とを含み、このいくつかのデータ単位に、テキストデータ、またはもう１つのエスケープ開始シーケンスが続くことができるというように構成することができる。
【００３７】
データストリームを読むための基本受信機は、データストリーム１６を得るための入力インターフェイス７０を含む。データストリームは、次に、プロセッサ７１に伝送され、このプロセッサは、データストリームからのテキストを読み、そのテキストを表示するためにテキスト表示部７２に結合されており、このプロセッサは、エスケープ開始シーケンスに遭遇すると、データ単位の長さまたは数を判断し、それはこの数のデータ単位をスキップするためであり、プロセッサはさらに、エスケープ継続シーケンスに遭遇すると、図２ａのブロック７１に示されるように、継続シーケンスに属するいくつかのデータ単位を
スキップもする。
【００３８】
図２ｂに示す拡張受信機は、図２ａの基本受信機の要素に加えて、データ単位が単純にスキップされるのではなく共に実行されるというプロセッサ７１のモジュールまたは機能性を含む。
【００３９】
拡張受信機において基本受信機においてと同じように機能することができるまたは機能するテキスト表示部７２に加えて、拡張受信機は、エスケープ開始シーケンスおよびエスケープ継続シーケンスの後にあるデータ単位の解釈を行なう。
【００４０】
以下に、図６Ａおよび図６Ｂを参照して、データ処理オプションのない基本受信機と、データ処理オプションのある拡張受信機との機能性の比較を行なう。
【００４１】
基本受信機と拡張受信機との両方がテキストデータを読むとき、図２ａまたは図２ｂのプロセッサ７１は、テキストデータを処理し、このテキストデータをデコードし、次に、テキスト表示部７２にそれを提供し、図６Ａおよび図６Ｂのステップ８０に示すように、それを表示する。受信機は、エスケープ開始シーケンスに遭遇した場合、ステップ８２に示されるように、このエスケープ開始シーケンスを読む。特に、基本受信機は、ステップ８２において、エスケープ開始シーケンスによって、すなわちたとえば、図３ｂの長さコード３１ｂによって、いくつのデータ単位が示されているかが分かる。次に、ステップ８３において、基本受信機は、ステップ８２において判断した数のデータ単位をスキップする。対照的に拡張受信機は、ステップ８４においてエスケープ開始シーケンスに続くデータ単位をスキップせず、そのデータ単位を読む。したがって、好ましくは、拡張受信機も、長さ情報を必要とする。しかしながら、データがテキストとは異なる方法でエンコードされていたならば、長さ情報は必ずしも必要ではないであろう。
【００４２】
ステップ８５において、基本受信機と拡張受信機との両方は、図３ａの第１のデータ単位３２に続くエスケープ継続シーケンスを読む。ここで基本受信機は、いくつのデータをスキップするべきかを見つけるために、主に長さコードに興味を持っており、このスキップは、次にステップ８６において基本受信機によって行なわれる。一方、拡張受信機は、ステップ８７において第２の数のデータ単位をスキップせず、８７に示すように、そのデータ単位を読む。次に、並行する基本受信機がないステップ８８において、拡張受信機は、図２ｂの機能性またはモジュール７３を作動させ、第１および第２のデータ単位の共通実行を行なう。すべてのデータ単位が処理されると、基本受信機と拡張受信機との両方は、ステップ８９において第２のテキストデータ、すなわち図３ａに示すデータストリームに続くデータ３５を表示する。しかしながら、第２の長さコード３３ｂも、最大長さ、すなわち、この例においては「ＦＦ」を有する場合、拡張受信機は、もう１つのエスケープ継続コードを読込み、それに続く長さコードを解釈し、次に、再び共通実行を可能にするために、そういった参照されたデータ単位を第１および第２のデータ単位に加える。
【００４３】
続いて、図３ｃを参照して、何を拡張受信機がステップ８８において行なうのか、またはどのようにエスケープ開始コードおよび継続コードの後、抜出されたデータが解釈されるのかを、より詳細に述べる。
【００４４】
１つの例において、第１の数のデータ単位は、データ型インジケータ９０を含み、このデータ型インジケータは、たとえば、１バイト長である。このデータ型インジケータ９０は、エスケープ開始シーケンス３１によって参照される第１の数のデータ単位の、あるバイト、たとえば第１のバイトにのみ置かれる。それに対して、第２の数のデータ単位にはそのようなデータ型インジケータは存在しないが、第２の数のデータ単位３４は、共に実行されるべきデータ単位、またはいわゆる「ペイロード」に完全に関与している。データ
型インジケータ９０が用いられると、拡張デコーダは、継続コードの後に含まれるデータを、第１の数のデータ単位に含まれるデータと同じ型に属すると解釈する。これにより、データストリーム中で継続コードに続く第２の数のデータ単位には、これらが継続データであるかどうか、またはどのデータ型を第２の数のデータ単位は有するかについての情報を含む信号通知が不要であることが可能となる。代わりに、それぞれまるで分離がなかったかのように、第１の数のデータ単位中のデータ型インジケータが単純に第２の数のデータ単位に対しても用いられもしくは適用され、または、第２の数のデータ単位中のデータは、第１の数のデータ単位に単純に加えられ、これにより次にそれらは共に実行もしくは処理される。
【００４５】
この発明のスケーラブルなデータストリームの利点は、一般的な規格に基づいているという点である。したがって、オブジェクトをインポートし、ＸＭＬフォーマットでさらに処理することができる。
【００４６】
データストリームは、リスナーがどこにいようともテキスト情報に直ちにアクセスできるようになったので、リスナーに対し追加の価値を提供する追加のデータチャネルとして、デジタル放送システムに特に適しており、デジタル放送のための受信機は、少なくともテキスト情報を表示する単純な受信機か、または第１の数のデータ単位および第２の数のデータ単位のどんなデータ処理でも行なうことができる、特に複雑で、よって当然より費用集約的な受信機かのいずれかである。費用が嵩まないのみならず、その上したがって大量生産品として利用可能でもあるテキスト表示部を有する受信機は、リスナーに対して追加の価値を生み出すことができるということになる。しかしながら、データストリームは、グラフィカルユーザインターフェイスと任意選択的音声再生とを備えたハイエンド受信機にも適している。こうしたすべては、単純な実装によって、費用の嵩まない受信機においてさえ、どのデータが現在有効であるかにユーザが対処しなくてもよい特に単純な使用方法で得られる。代わりに、データの削除またはデータの実行は、ユーザがそれに対処する必要なしに、どの受信機をユーザが有するかによって完全に自動的に行なわれる。
【００４７】
さらに、ある例においては、テキストデータは、オブジェクト指向に記述されており、こういったオブジェクトはすべて、独立かつ自己完結型の単位である。よって、グローバルデータ構造を受信機中にアセンブルするまたは維持する必要はない。オブジェクトは、データカルーセルの形態で伝送され、データキャッシュは受信機で有利に用いられる。たとえば、メニューデザイン、ニュース記事、速報ニュースであり得るテキストデータは、いわゆるＮＭＬオブジェクトとして伝送され、ＮＭＬとは、ニュースサービスマーク言語（News Service Mark Language）を意味し、ＸＭＬベースの２進エンコードされたコンテンツ表現と似ている。
【００４８】
好ましくは、１６進コード１Ａは、開始エスケープコード３１ａとして用いられ、１６進コード１Ｂは、たとえば、継続コードとして用いられる。図３ｃのデータ型インジケータ９０は、以下に説明するように、いくつかのデータ型を示すことができる。以下のデータ型インジケータ値は、例示的なものにすぎない。「００」というインジケータは、パディングを示す。含まれたデータは、パディングバイトを運び、このコンテンツは、拡張デコーダと基本デコーダとの両方によって無視される。これに代わる型のデータセットは、インジケータ「０１」を有し、絶対タイムアウトをあらわす。ＮＭＬオブジェクトの絶対表示タイムアウトまでの時間が定義される。このタイムアウトが経過すると、ＮＭＬオブジェクトは表示されなくなる。このエスケープ継続コード表現は、個々のＮＭＬオブジェクトを作るために必要とされる。サービス全体に対する一般的なタイムアウトがこれに代えて説明される。データ型インジケータの後のペイロードは、２０００年１月１日からの１５分間の数を符号のない２４ビット整数として含み、これは、４５０年間を超える範囲をカバーする。「０２」型のデータ型インジケータは、相対タイムアウトを示す。ここで
、ＮＭＬオブジェクトの相対表示タイムアウトまでの時間が定義される。この時間が経過すると、ＮＭＬオブジェクトは、表示されなくなる。タイムアウトは、オブジェクトが既にキャッシュに格納されているときでさえ、ＮＭＬオブジェクトの各受付けから始まる。このエスケープシーケンスコードは、個々のＮＭＬオブジェクトを作る役目をする。ペイロードデータは、符号のない（符号なし）１６ビット整数として分数を含み、これは、４５日間を超える範囲をカバーする。一般に、タイムアウトデータは、図７のタイムアウト制御１００によって処理される。
【００４９】
データ型インジケータ「０３」は、一般リンクターゲットに関する。一般リンクターゲットとは、ユーザが明示的に動作の実行を要求すると、すなわち「ホットボタン」機能がユーザインタラクションのために示されるまたは提供されると、たとえば接続制御１０１によって表示されるまたはアクティブにされるターゲットである。一般リンクターゲットは、すべての型のＮＭＬオブジェクトに対して定義することができる。現在表示されているＮＭＬオブジェクトの一般リンクターゲットの利用可能性は、ユーザが拡張受信機を有すると、何らかの方法でユーザへ伝えられる。たとえば図３ｃに示されたペイロードデータは、以下のフォーマットを有する。１バイトは接続型を表わし、ｎバイトは、リンクアドレスを表わす。以下のリンク型値は、たとえば、利用可能である。リンク型が、たとえば「００」である値を有すると、それに続く２バイトは、同じデータサービスにある別のＮＭＬオブジェクトのオブジェクトＩＤである。
【００５０】
たとえば「０１」である別のリンク型バイトには、ＵＲＩ文字列が続き、さまざまなＤＡＢ／ＤＲＭ多重伝送、サービス、またはサービス要素を指し示す。
【００５１】
ＵＲＬ文字列を示す「０２」などの別の接続型は、インターネットアドレスまたは文書を指し示す。
【００５２】
電話番号が後に続く「０３」などの別のリンク型は、電話で連絡を取ることができる音声サービスを指し示す。番号は、ここでは、たとえば、国際識別番号、たとえば「＋［国際国番号］」から始まる。
【００５３】
一般に、拡張受信機は、未知のリンク型値を無視するように設計されている。
もう１つのデータ型インジケータ「ＦＦ」は、たとえば、著作権のあるデータ型インジケータとして考えられ、こういった著作権データを評価することのできる特定の拡張受信機のみに関係したデータの前に付く。
【００５４】
上記のオブジェクト管理型と対照的に、データ単位は、コンテンツ管理型も含むことができる。「２０」というデータ型インジケータは、キーワードとも呼ばれ、後に続くキーワードに任意選択的キーワード記述とともに印を付ける。キーワードは、たとえば、図７の問合せ生成手段１０２によって示されるように、受信者ベースの検索インデックスを生成するために用いることができる。ペイロードデータ部分は、以下のフォーマットを有する。まず、キーワードの長さを有する長さコードがあり、長さ−１と等しい値が符号なし整数として示されている。キーワードとして扱われるべきこのデータ部分に続く視覚的テキスト文字の数が識別されている。次に、ｎバイトある記述が続き、任意選択的記述を、キーワードに加えて索引付けすることができかつ／またはユーザに対して表示することができる。
【００５５】
たとえば「２１」という別のデータ型インジケータは、マクロ定義を表わす。マクロは、単純な参照でコンテンツ部分の任意の場所に何回か挿入することができる任意選択的エスケープシーケンスを含むテキスト部分の定義を可能にする。たとえば、マクロは、文書のテキスト要素に加えて、説明されるべき音声記述を定義することができる。データ部分
は、まず１バイトのマクロＩＤ（０から２５５）が以下のマクロ定義を識別するフォーマットを有する。次にｎバイトあるマクロ定義が続く。このマクロがそのＩＤによって参照されるとき常に挿入されるべきテキスト（エスケープシーケンスを含む）は、ｎバイトあるマクロ定義に含まれている。なお、受信機はマクロを無視することもできるので、マクロは、必ずしも必須情報に対して用いられるべきでないことが留意されるべきである。別のデータ型インジケータ「２２」は、たとえば、マクロ参照を意味する。そのＩＤによって参照されるマクロ定義は、ユーザへ表示するためにエスケープシーケンスのこの位置に実質上導入される。データ部分は、マクロ定義を参照する１バイトのマクロＩＤ（０から２５５）を含む。マクロは、一般に、図７のマクロプロセッサ１０３によって処理される。
【００５６】
データ型の別のグループは、音声支援型を含むことができる。たとえば「Ａ０」というデータ型インジケータは、標準言語または予め設定された言語を定義する。ここで、ＮＭＬオブジェクトの予め設定された言語は、それぞれ記述または参照される。データ部分、すなわち、図３ｃのペイロードは、小文字の３文字ＩＳＯ言語コードを有する。
【００５７】
たとえば「Ａ１」によって参照される別の音声支援型は、言語部分である。これは、特定の数のテキスト部分またはＮＭＬオブジェクトの特定の部分の言語を定義する。ペイロード部分は、以下のフォーマットを有する。１バイトを有するテキスト長が存在し、その値は、符号なし整数として、このテキスト長−１のデータ単位の数の値に等しい。これは、言語定義が適用されるこのデータ部分に続く視覚的テキスト文字の数を識別する。次に、３バイトのグループが言語定義を備えて続き、このグループは、小文字の３文字ＩＳＯ言語コードを有する。
【００５８】
別の言語支援型は、たとえば、データ型インジケータ「Ａ２」によって索引付けされている。このデータ型インジケータは、音声音素に関し、テキスト部分の音素記述を国際音標文字（ＩＰＡ）を用いて定義する。ペイロード部分のフォーマットは、まず値が整数である１バイトのテキスト長を有する。このバイトは、このデータ部分に続く視覚的テキスト文字の数を識別し、これは、音声定義によって表わされる。次に、ＩＰＡ音素を備えたｎバイトのグループが続く。このグループは、ＩＰＡ表記として音素の音素定義を含む。
【００５９】
別の音声支援型は、たとえば、データ型インジケータ「Ａ３」によって参照され、エスケープシーケンスの位置に挿入されるべきテキスト‐音声プロセッサのための中断を定義する音声中断を含む。データ部分は、符号なし整数として１バイトを運び、このバイトは、０．１秒単位で音声時間を定義する。
【００６０】
別の音声支援型は、たとえばデータ型インジケータ「Ａ４」を有することができ、テキスト‐音声プロセッサによって連続した単語または数字ではなく個々の文字または数字として扱われるべき、エスケープ開始シーケンスに続く文字と、特に視覚的テキスト文字の数とを定義する。ペイロード部分は、１バイトを運び、視覚的テキスト文字の数をそれぞれの値を有する符号なし整数として定義する。
【００６１】
なお、すべてのこういったデータ型は、長さコードによって表わすことができる最大の数に応じて、図３ａの第１の数のデータ単位３２に表わすことができるか、またはデータ単位の数がすべてのデータを書くためには不十分なときは、エスケープ継続シーケンスから各々開始されることができる第２の数のデータ単位に含めることができるかのいずれかであることが留意されるべきである。データ型インジケータによって参照されるすべてのデータ型が、エスケープ開始シーケンスの後とエスケープ継続シーケンスの後との両方にデータ単位を有する必要が必ずしもあるわけではないということになる。代わりに、短いデータ型でさえも継続を必要としない単なるデータを含むことができる。なぜならば、こ
ういったデータのデータ単位の数は長さコード３１ｂによって表わすことができるデータ単位の最大の数よりも少ないからである。
【００６２】
状況に応じて、この発明のどの方法も、ハードウェアにおいてまたはソフトウェアにおいて実現することができる。このような方法は、デジタル記憶媒体、特にディスクまたはＣＤ上で、プログラム可能なコンピュータシステムと方法が実行されるよう協働することができる電子的に読取可能な制御信号を用いて実現することができる。よって、一般に、この発明には、機械読取可能媒体に格納された、コンピュータプログラム製品がコンピュータ上で実行されるときこの発明の方法を実行するためのプログラムコードを備えたコンピュータプログラム製品も含まれる。言い換えれば、この発明は、コンピュータプログラムがコンピュータ上で実行されるときこの方法を実行するためのプログラムコードを備えたコンピュータプログラムとして実現化することができる。
【図１】
2010518766.tif 000003
【図２】
2010518766.tif 000004
【図３】
2010518766.tif 000005
【図４】
2010518766.tif 000006
【図５】
2010518766.tif 000007
【図６】
2010518766.tif 000008
【図７】
2010518766.tif 000009
【手続補正書】
【提出日】平成21年10月8日(2009.10.8)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ伝送に関し、特に、単純な受信機に対してテキストを、より複雑な受信機に対してテキストに加えてデータを用い、どちらの型の受信機もデータストリームを評価することができる、より簡単なデータ伝送に関する。
【背景技術】
【０００２】
今では、個々の受信機端末が数多く存在し、こういった受信機はすべて、伝送された情報をモバイル方式で受信することができる。この幅広い層の特徴は、このようなさまざまな情報受信機の処理および出力能力が非常に異なることである。たとえば、ノートパソコンは、かなりのプロセッサリソースおよびメモリリソースを有するので、伝送されたデータのモバイル受信機として非常に高い処理および出力能力を有している。一方、たとえば、同じく放送データチャネルなどの情報サービスに参加している携帯電話は、非常に制限された処理リソースおよび出力リソースしか有さない。携帯電話として意図されてすらおらず、サッカーリーグの結果、または他のスポーツの結果、新聞の見出し、天気予報などのデータを受信するための単なるモバイル放送受信機として意図されている小型モバイル放送受信機は、それぞれのデータ放送サービスが用いられる場合、処理および出力リソースがさらに一層制限されている。
【０００３】
デジタル放送のためのそのようなテキストベースの情報サービスは、単純なデータ収集および再使用のみならず非常に効率的な放送伝送にも適しており、「Journaline（登録商標）」という呼称で存在している。このデータサービスは、小さなテキスト表示部を有する費用対効果の大きいソリューションから、グラフィカルユーザインターフェイスと任意選択的テキスト‐音声再生とを備えたハイエンド受信機までにわたる非常に広い範囲の受信機型に対応している。
【０００４】
ユーザは、ラジオ局によって提供されたあらゆる情報を、直ちにかつインタラクティブ
に処理することができる。この点で、このサービスは、テレビのためのビデオテキストと比較することができる。基本的な情報は、単純なテキストフォームで提供されるが、同時に、イメージまたはビデオシーケンスなどのマルチメディア要素への拡張を含むより複雑なグラフィカル表現のオプションおよび他の機能拡張が可能とされる。
【０００５】
一方、たとえばＤＡＢ伝送器によって放送される、データストリームは、下位互換性があることが重要である。これは、このデータストリームを読み、処理することが、単純な受信機によってもより複雑な受信機によっても、すなわち単純な受信機である基本受信機によってもより複雑な受信機である拡張受信機によっても、等しく可能であることを意味する。
【発明の概要】
【課題を解決するための手段】
【０００６】
この発明は、単純な受信機と複雑な受信機との両方によって等しく解釈可能であるべきテキストデータに加えて、単純な受信機および複雑な受信機によって等しく処理することができ、データ伝送および処理の高い柔軟性を可能にするデータストリームを、生成し、処理するための概念を提供することを目的とする。
【０００７】
この目的は、請求項１に従ったデータストリームを生成するための装置、請求項１５または１７に従ったデータストリームを読むための装置、請求項２８に従ったデータストリームを生成するための方法、請求項２９または３０に従ったデータストリームを読むための方法、または請求項３１に従ったコンピュータプログラム、または請求項３２に従ったデータストリームによって達成される。
【０００８】
テキストデータとは別に、データストリームは、基本デコーダによってスキップされるべきかつ拡張デコーダによって解釈されるべきである第１の数のデータ単位を定義するエスケープ開始シーケンスと、第１の数のデータ単位と、基本デコーダによって再びスキップされるべきかつ第１の数のデータ単位とともに拡張デコーダによって解釈されるべきである第２の数のデータ単位を定義するエスケープ継続シーケンスと、さらには第２の数のデータ単位と、最後に、必要な場合、テキストデータとを含む。
【０００９】
このようにして、一方では、エスケープ開始シーケンスが関連付けられているデータ単位の数は、最大でもエスケープ開始シーケンスによって信号通知することができるデータ単位の最大数と同じ多さまたはそれよりも少ないので、短い開始シーケンスを用いることが確実にできるようになる。単に高品位のデコーダのためだけに考慮されているデータ単位の数が、エスケープ開始シーケンスによって解釈可能なデータ単位の数よりも多くなるという、通常ほとんど無い場合については、さらに、拡張デコーダによって第１の数のデータ単位とともに解釈されるべきデータ単位の数を定義するエスケープ継続シーケンスが与えられる。よって、データ単位の数が少ないより短いデータブロックについては、常にエスケープ開始シーケンスが必要とされるにすぎない。このエスケープ開始シーケンスは、任意に長い長さではなく、単なる制限された長さのデータ単位をエンコードすることを意図されているに過ぎないので、短いコードである。他方で、エスケープ継続シーケンスとエスケープ継続シーケンスの後の第２のデータ単位との任意に周期的な繰返しによって、データストリーム中に導入することができる任意の長さのデータ導入が可能であるという点において、柔軟性が得られる。
【００１０】
言い換えれば、柔軟性のあるデータストリームにより、拡張デコーダのためにテキストに導入されるデータ量は無限である。しかしながら、これは、エスケープ開始シーケンスの長さに影響を及ぼさない。なぜなら、非常に長いデータ挿入の長さを信号通知するタスクは、実際にはいくつかのシーケンスに、すなわち、エスケープ開始シーケンスと、デー
タストリーム中で後に出現するエスケープ継続シーケンスと、おそらくさらなるエスケープ開始シーケンスとに分割されており、その一方、比較的頻繁に出現する短いデータ挿入は、非常に短いエスケープ開始シーケンスのみが必要であるためである。よって、拡張デコーダは、データストリーム中にエスケープ継続シーケンスを見つけると、このシーケンス付きで表示されるデータ単位は、第１のデータ単位に属すると知る。いっそうの柔軟化に関しては、データストリームを用いるとき、データの型を、したがって第１のデータ単位と第２のデータ単位との両方からなるこういったデータで実行されるべき処理を通知するデータ型インジケータが、データ単位中に位置する。データ型インジケータは、たとえば、エスケープ開始シーケンスによって参照される第１のデータ単位の前かつエスケープ継続シーケンスによって参照される第２のデータ単位の前に位置する。
【００１１】
この発明の好ましい実施例は、添付の図面を参照して以下に説明される。
【図面の簡単な説明】
【００１２】
【図１】データストリーム装置のブロック図である。
【図２】図２ａは、基本受信機のブロック図であり、図２ｂは、拡張受信機のブロック図である。
【図３】図３ａは、データストリームの説明図であり、図３ｂは、１つの局面に従ったエスケープ開始シーケンスおよびエスケープ継続シーケンスの拡大された説明図であり、図３ｃは、図３ａまたは図３ｂのエスケープ開始シーケンスおよびエスケープ継続シーケンスによって参照されるデータを、拡張デコーダによって解釈可能なデータ型インジケータとともに説明する図である。
【図４】図４ａは、継続コードが無いデータストリーム例を示す図であり、図４ｂは、継続コードがあるエンコード例を示す図である。
【図５】データストリームを生成する方法のフロー図である。
【図６】図６Ａは、基本受信機によって実行されるフロー図であり、図６Ｂは、拡張受信機によって実行されるフロー図である。
【図７】データ型インジケータによって示されることができ、処理されることができる異なるデータ型を示す図である。
【発明を実施するための形態】
【００１３】
図１には、データストリーム中に情報を入力するための手段１０を含む、データストリームを生成するための装置が示されており、このデータストリームは出力１２で出力される。データストリームは、データストリーム伝送および／または格納手段１４へ送られ、データストリームの受信機またはデコーダへそれぞれ、放送伝送の例において自由空間伝送路を介して、伝送される。これに代えて、伝送または格納手段１４の出力１６は、この手段の出力に接続された、または、受信機がデータを格納するのみで処理しないもしくはデータを同時に格納および処理するとき受信機の中などの伝送路の他方の端部に設けられた、メモリカードなどのコンピュータ読取可能記憶媒体に接続されている。よって、コンピュータ読取可能記憶媒体は、受信機もしくはデコーダ中の不揮発性メモリカード、またはノートパソコンのハードディスク、またはデコーダのワーキングメモリであり得、このワーキングメモリは、電流または電圧をそれぞれ供給されている限りそのデータを保持する。
【００１４】
入力手段１０は、テキストデータ１１ａとデータ単位１１ｂとを含む。好ましくは、計算はバイトで行なわれる。よって、１つのデータ単位は、８ビットすなわち１バイト長である。この粒度（granularity）は、テキストおよびデータの両方をこの粒度で簡単に扱うことができるので好ましい。これに関連して、テキストエンコードのためにＵＴＦ８エンコードフォーマットを用いることが好ましく、典型的なＡＳＣＩＩ文字は、各々１バイ
トでエンコードされ、その一方、たとえばドイツ語のウムラウトは、２バイトでエンコードされ、たとえば漢字は、３、４またはそれ以上のバイトでエンコードされる。したがって、基本受信機は、ＵＴＦ８エンコードをデコードすることができ、これは、たとえば、ＵＴＦ８デコードテーブルを置くことによって行なうことができるということになる。デコードによっては、入力手段は、テキストデータとデータ単位を並列に得る。この場合、入力手段は、時間制御信号１１ｃも受信し、この時間制御信号は、どんな時間にテキストデータが、またどんな時間にデータ単位が、たとえばシリアルデータストリーム１２中に送られるべきかを決定する。これに代えて、入力手段１０は、単一の入力を介してテキストデータおよびデータ単位を予め受信していることができ、この単一の入力は、テキストデータおよびデータ単位を正しい所望の時間的またはビットストリーム順序で予め提供する。
【００１５】
入力手段は、テキストデータをデータストリーム中に入力するように実現される。単純なデコーダによってスキップされるべきだが、より複雑なデコーダによって読まれるまたは処理されるべきデータ単位が入力されるべきとき、エスケープ開始シーケンスが、たとえば図３ａに示すように、データストリーム中に入力される。エスケープ開始シーケンス３１は、基本デコーダによってスキップされるべきかつ拡張デコーダによって解釈されるべき第１の数のデータ単位を定義する。次に、この第１の数のデータ単位も、図３ａの３２に示すようにデータストリームに入力される。入力されるべきデータブロックがエスケープ開始シーケンスによって定義されるべきデータ単位よりも多いデータ単位を含む場合、手段１０は、基本デコーダによってスキップされるべきだが拡張デコーダによって第１の数のデータ単位とともに解釈されるべきである第２の数のデータ単位を定義するエスケープ継続シーケンス３３を入力する。次に、この第２の数のデータ単位も、図３ａの３４に示すように、データストリーム中に入力される。
【００１６】
実装によっては、すなわち、データブロックがエスケープ継続シーケンスによって定義することができるよりもさらに多いデータを有する大きなデータブロックであると、拡張デコーダによって共に解釈されるべきテキストデータにこの位置で入力されるべきすべてのデータ単位が入力されるまで、もう１つのエスケープ継続シーケンスが、データストリームなどに書込まれる。
【００１７】
次に、図１の入力手段１０は、典型的に、図３ａにたとえば第２のテキストデータ３５として示されているテキストデータを、データストリームが生じるよう再び入力し、第１のテキストデータ３０と第２のテキストデータ３５とは、ある意味では、基本デコーダによってスキップされるべきデータを囲むよう存在し、基本デコーダは、データストリーム中の正しい数のデータ単位をスキップすることができるためには、少なくとも、エスケープ開始シーケンスと、特にデータ単位の数と、さらにはエスケープ継続シーケンスと、少なくとも含まれたデータ単位の数とを読むことができる。
【００１８】
図３ｂには、エスケープ開始コード３１ａのみならずダウンストリーム長さコード３１ｂも含むエスケープ開始シーケンス３１の例が示されている。エスケープ継続シーケンス３３は、同様に構築されており、別個の継続コード３３ａと、ダウンストリーム長さコード３３ｂとを含む。たとえば、コード３１ａ、３１ｂ、３３ａ、３３ｂはすべて、各々１バイトまたはそれぞれ１個のデータ単位の長さであり、その結果、長さコードによって２５６個のデータ単位をエンコードすることができる。これは、データブロックが２５６個のデータ単位よりも長いとき、データブロックの残っているデータ単位を後続の長さコード３３ｂでエンコードするためには、継続コード３３ａが、第１の２５６個のデータの後ろにデータストリーム中に書込まれるまたは入力されるべきであるということを意味する。
【００１９】
データ単位が、それぞれ、より長い場合、１個のデータ単位の長さである長さコードは、多数のデータ単位をエンコードし得、これは、そのようなデータストリーム中で、継続コードの全体数が少なくなる効果があるであろう。しかしながら、８ビット未満の長さコードが選択される場合、長さコードによってエンコードすることができるデータの最大の数は、それぞれ、より少なく、そのため他の点では同じ状況において、データストリーム中の継続コードの数は対応して増加する。典型的に、データブロックのある平均的な長さに対してある長さのデータ単位が存在するのが最適である。長さコードが長くされすぎた場合、単なる非常に短いデータ挿入に対してまで長い長さコード全体をデータストリームに書込まなくてはならないため、この手順は非効率となるであろう。一方、長さコードが短くされすぎた場合、継続コードは、非常に多数のデータブロックについて書かれるであろう。これは、より長い長さコードが開始からすぐに用いられていたならば、特に図３ｂに示される実装において不要であっただろう。
【００２０】
図４ａには、図４ａの４０に示すように、「This is a great test!」という表示をもたらす例示的なデータストリームが示されている。関連付けられたデータストリームは、最初に、テキスト「This is a 」というテキストを備えた第１のテキストデータ３０を有する。これは、ＵＴＦ８エンコードにおいては、各アルファベットおよび空白に１バイトずつ必要とされるので、１０バイトを必要とする。よって、第１のテキストデータは、１０バイト長である。
【００２１】
次に、データが挿入される。これを信号通知するために、図４ａに示す例においては１Ａであるエスケープ開始コード３１ａは、（０ベースの）バイトインデックス１０に置かれており、プレフィックス「０ｘ」は、１６進表示を示す。当然、テキストコードとは異なる任意の他のコードがエスケープ開始コードとして挿入され得る。言い換えれば、図４ａにおける例においては１バイト長であるエスケープ開始コード３１ａは、ＵＴＦ８エンコードで画面に表示可能な文字（数字、アルファベット、…）を定義するコードとは異なるべきである。したがって、エスケープコードは、たとえば、画面に表示可能な文字のためのテキストコードとは異なるＵＴＦ８制御文字または他の固定文字である。
【００２２】
エスケープ開始コード３１ａに続くのは、長さコード３１ｂであり、この長さコードは、長さコード３１ｂに続くデータフィールドがどれぐらいの長さかを示す。長さフィールドは、コード４を含み、その結果、図４ａにおける第１のデータ単位３２は、５バイトを含む。０という長さは意味をなさないであろうため、長さフィールドは暗黙的に「−１」という項を含むということがこの背景にある。
【００２３】
次に、別のテキストフィールド、すなわち５バイトの単語「great」が続くと、再び、バイトインデックス２２に、エスケープ開始コード３１ａが書かれており、５の値を有する長さコード３１ｂがこれに続く。なぜならば、この長さコードに続いて、次に６バイトデータがバイトインデックス２４から２９に書かれているためである。出力側には、別のテキストブロック３５が存在し、「test」の各アルファベットに１バイトが必要とされ、感嘆符にも１バイトが必要とされるので、このテキストブロックは６バイト長である。
【００２４】
これは、２つの異なる位置に挿入された１１バイトの追加データを含む、３６バイト長のデータストリームをもたらす。
【００２５】
基本デコーダは、データを読込み、表現し、次に、エスケープ開始コード３１ａに遭遇すると、このエスケープ開始コードを、基本デコーダはエスケープ開始コードと関連付けられた長さコードを検索する、という意味に解釈する。次に、この長さコードを解釈すると、基本デコーダは、エスケープ開始コードおよび長さコードによって参照されたデータ単位をスキップし、すなわちこのデータ単位を無視し、このデータ単位をそれ以上考慮し
なくなる。次に、基本デコーダは、バイトインデックス１７から２１にあるテキストデータを読込んで、次に再びコード３１ａをエスケープ開始コードとして認識し、コード３１ｂの中に信号通知されているバイト数を再びスキップするために、コード３１ｂにある関連付けられた長さインジケータを検索する。
【００２６】
よって、単純な方法で確実に、基本デコーダは、より新しくより複雑な拡張デコーダのために書かれたデータストリームを読むことさえできるようになる。基本デコーダがデータを取扱うことはできないが、コードと長さインジケータと備えたエスケープ開始シーケンスを正しく解釈できるということは、下位互換性を保証する。
【００２７】
しかしながら、拡張デコーダは、開始シーケンスすなわちコード３１ａおよび３１ｂを解釈することができるのみならず、またデータを単にスキップするのみならず、単純なテキスト表示とは別に、データストリームおよびエスケープシーケンスに関連付けられたデータを介して制御することができる追加機能を行うことができるように、開始シーケンスを処理することができる。
【００２８】
図４ｂには、継続コードのあるエンコード例が示されており、図４ｂに示された例においては、１つのデータブロックが２５６バイトよりも長いと想定されている。そのような大きなデータブロックが挿入されるべき場合、まず、エスケープ開始シーケンスが、データバイトインデックス０に挿入され、このエスケープ開始シーケンスは、この場合もエスケープ開始コード３１ａとダウンストリーム長さコード３１ｂとからなる。しかしながら、今度は、長さコード３１ｂにある長さ値は、バイトインデックス１１またはバイトインデックス２３におけるように数字ではなく、最大値、すなわち「ＦＦ」である。次に、長さコード３１ｂに続いて、２５６個の第１のデータ単位３２がデータストリーム中にバイトインデックス２から２５７に書込まれる。いくつかのさらなるデータ単位が存在するので、すなわち全体としては２６２バイトなので、データストリーム生成器は、自身がまだデータストリーム中にすべてのデータ単位を書いていないと判断する。結果として、このデータストリーム発生器は、エスケープ開始コード３１ａとは異なる継続コード３３ａをデータストリーム中に書込み、これにより、デコーダは、たとえばこの継続コードの直後に続く、継続コードに属するデータ単位は、継続コードの前に処理されたまたは送られたデータ単位に引続き属すると知る。図４ｂに示す例においては、さらに６個のデータ単位が入力されなくてはならず、そのため継続コードに続く長さコード３３ｂが６という長さ（コード０ｘ０５）を信号通知する。次に、この長さコードに続いて、データストリームへの挿入は、第２のデータ単位３４を書くことで終了され、次に、図４ｂに示すバイトインデックス２６６から開始して、たとえば、通常のテキスト３５が続くことができる。
【００２９】
なお、実装によっては、エスケープ継続コード３３ａは、必ずしもエスケープ開始コード３１ａと異ならなくともよいことに留意されるべきである。これは、基本デコーダにとって重要ではない。基本デコーダは、いくつのデータがスキップされるべきかを知るために、単にエスケープ開始コード３１ａおよびエスケープ継続コード３３ａの両方を解釈し、この解釈に続いて、ダウンストリーム長さコードを読まなくてはならないにすぎない。この場合、拡張デコーダは、後ろに最大長さの長さコードすなわちたとえばＦＦが続くエスケープ開始コードが最初に出現すると、後続のデータ単位が引続きデータ単位３２に属し、よって共に処理されなくてはならないと自動的に見なすよう、実装されるであろう。よって、エスケープ開始コードの意味は、エスケープ開始コード３１ａに続く長さコード３１ｂが最大長さを示す点で「切換えられる」であろう。エスケープ開始コード３１ａと継続コード３３ａとが同じ値を有するとき、デコーダは、第１のエスケープ開始コード３１ａの後の長さコード３１ｂが最大値すなわちＦＦを有さないと、データ単位に続く継続コードを継続コードとしてではなく新しい開始コードとして解釈するであろう。そのため、第２の開始コードに続くデータは、第１の開始コードに続くデータの続きとしてではな
く、異なる処理を受けることができる新しいデータブロックの新しいデータとして解釈される。データが継続データか、または非継続データかの解釈は、データ型インジケータが、いくつかのデータ単位からなるどのデータブロックにも、初めなどのある位置に位置するとき特に重要であり、それは、以下に図３ｃを参照して述べるように、データが非継続データのとき読まれ、または、データが継続データのとき、デコーダによって予期されておらず読出されもしない。
【００３０】
以下に、図５を参照して、図１に示すように構成されたデータストリーム生成器が実行できる、データストリームを生成するためのステップの例示的なシーケンスを、説明する。
【００３１】
図５のフロー図は、テキストを入力するステップ５０から始まる。ステップ５１において、テキスト入力後、まだ入力されなければならないデータが存在するかどうかが確認される。この問いの答がｎｏの場合、ループ５２によって示されるように、次のテキストオブジェクトがデータストリーム中に入力される。しかしながら、この問いの答がｙｅｓの場合、ステップ５３に示されるように、入力手段１０は、エスケープ開始シーケンスを入力する。エスケープ開始シーケンスは、データの長さ、すなわちデータ単位の数についての情報を含む。エスケープ開始シーケンスをデータストリーム中に入力した後、５４に示すように、第１のデータ単位が入力される。ステップ５５において、データブロックに属するすべてのデータがデータストリームに入力されたかどうかが確認される。
【００３２】
この問いに対する答がｎｏの場合、すなわちそれ以上データが存在しない場合、ループ５６によって示されるように、テキストオブジェクトまたはエスケープコードが、再び入力される。
【００３３】
なおここで、エスケープ開始シーケンスは、テキストの前、テキストの後、またはテキスト間に位置し得ることが留意されるべきである。しかしながら、これに代えて、エスケープ開始シーケンスは、別のエスケープシーケンスの前または後ろにあることもでき、別のエスケープシーケンスは、特定のデータ以外のものを示すことができる。
【００３４】
しかしながら、データがまだ存在すると判断された場合、ステップ５７に示すように、エスケープ継続シーケンスが入力される。このエスケープ継続シーケンスにおいて、次にステップ５８において入力されるデータ単位の長さも判断される。ステップ５９において、さらなるデータが存在するかどうかが確認される。そうである場合、すなわち、６０に示すようにデータブロックのさらなるデータが入力される場合、もう１つのエスケープ継続シーケンスが書かれる。一方、すべてのデータが入力されている場合、テキストはステップ５０に示すのと基本的にいつも同じ方法で再び入力される。わかりやすくするために、このデータブロックの後へのテキスト入力は、図５のステップ６１によって示されている。
【００３５】
なお、ステップ５５におけるデータがまだ存在するかどうかについての確認、またはステップ５９におけるデータがまだ存在するかどうかについての確認は、図５のブロック６２に示すように、入力されるべきデータの長さが並列にまたは別個のプロセスで判断されるとき、必ずしもは実行されないことが留意されるべきである。ブロック６２において、挿入されるべきデータブロックはどれぐらいの長さかが判断される。エスケープ開始シーケンスにおいて最大でエンコードされるデータ単位の数に基づいて、ブロック５２は、直ちに、いくつの継続シーケンスが必要かを知る。図４ｂに示す実施例において、図５の制御矢印６３ａおよび６３ｂによって示されるように、ブロック６２は、エスケープ開始シーケンスに最大長さが入力されるべきことと、次に継続シーケンスが入力されることとを判断し、この継続シーケンスの長さも判断される。この場合、点線の接続矢印６４によっ
て示されるように、ブロック５５またはブロック５９における確認は行なわれない。この代替例は、エスケープ開始シーケンスがデータ単位の入力の前に既に完了しているソリューションを既に表わしており、第２の代替例においては、長さは、第１のデータ単位または第２のデータ単位がそれぞれ入力された後に、単にエスケープ開始シーケンスに入力される。
【００３６】
以下に、図２ａおよび図２ｂを参照して、データストリームを受信するまたはデコードするための受信機が述べられる。このデータストリームは、基本的に図３ａに示すように、テキストデータと、エスケープ開始シーケンスと、いくつかのデータ単位と、次にエスケープ継続シーケンスと、このエスケープ継続シーケンスに続いて、再びいくつかのデータ単位とを含み、このいくつかのデータ単位に、テキストデータ、またはもう１つのエスケープ開始シーケンスが続くことができるというように構成することができる。
【００３７】
データストリームを読むための基本受信機は、データストリーム１６を得るための入力インターフェイス７０を含む。データストリームは、次に、プロセッサ７１に伝送され、このプロセッサは、データストリームからのテキストを読み、そのテキストを表示するためにテキスト表示部７２に結合されており、このプロセッサは、エスケープ開始シーケンスに遭遇すると、データ単位の長さまたは数を判断し、それはこの数のデータ単位をスキップするためであり、プロセッサはさらに、エスケープ継続シーケンスに遭遇すると、図２ａのブロック７１に示されるように、継続シーケンスに属するいくつかのデータ単位をスキップもする。
【００３８】
図２ｂに示す拡張受信機は、図２ａの基本受信機の要素に加えて、データ単位が単純にスキップされるのではなく共に実行されるというプロセッサ７１のモジュールまたは機能性を含む。
【００３９】
拡張受信機において基本受信機においてと同じように機能することができるまたは機能するテキスト表示部７２に加えて、拡張受信機は、エスケープ開始シーケンスおよびエスケープ継続シーケンスの後にあるデータ単位の解釈を行なう。
【００４０】
以下に、図６Ａおよび図６Ｂを参照して、データ処理オプションのない基本受信機と、データ処理オプションのある拡張受信機との機能性の比較を行なう。
【００４１】
基本受信機と拡張受信機との両方がテキストデータを読むとき、図２ａまたは図２ｂのプロセッサ７１は、テキストデータを処理し、このテキストデータをデコードし、次に、テキスト表示部７２にそれを提供し、図６Ａおよび図６Ｂのステップ８０に示すように、それを表示する。受信機は、エスケープ開始シーケンスに遭遇した場合、ステップ８２に示されるように、このエスケープ開始シーケンスを読む。特に、基本受信機は、ステップ８２において、エスケープ開始シーケンスによって、すなわちたとえば、図３ｂの長さコード３１ｂによって、いくつのデータ単位が示されているかが分かる。次に、ステップ８３において、基本受信機は、ステップ８２において判断した数のデータ単位をスキップする。対照的に拡張受信機は、ステップ８４においてエスケープ開始シーケンスに続くデータ単位をスキップせず、そのデータ単位を読む。したがって、好ましくは、拡張受信機も、長さ情報を必要とする。しかしながら、データがテキストとは異なる方法でエンコードされていたならば、長さ情報は必ずしも必要ではないであろう。
【００４２】
ステップ８５において、基本受信機と拡張受信機との両方は、図３ａの第１のデータ単位３２に続くエスケープ継続シーケンスを読む。ここで基本受信機は、いくつのデータをスキップするべきかを見つけるために、主に長さコードに興味を持っており、このスキップは、次にステップ８６において基本受信機によって行なわれる。一方、拡張受信機は、
ステップ８７において第２の数のデータ単位をスキップせず、８７に示すように、そのデータ単位を読む。次に、並行する基本受信機がないステップ８８において、拡張受信機は、図２ｂの機能性またはモジュール７３を作動させ、第１および第２のデータ単位の共通実行を行なう。すべてのデータ単位が処理されると、基本受信機と拡張受信機との両方は、ステップ８９において第２のテキストデータ、すなわち図３ａに示すデータストリームに続くデータ３５を表示する。しかしながら、第２の長さコード３３ｂも、最大長さ、すなわち、この例においては「ＦＦ」を有する場合、拡張受信機は、もう１つのエスケープ継続コードを読込み、それに続く長さコードを解釈し、次に、再び共通実行を可能にするために、そういった参照されたデータ単位を第１および第２のデータ単位に加える。
【００４３】
続いて、図３ｃを参照して、何を拡張受信機がステップ８８において行なうのか、またはどのようにエスケープ開始コードおよび継続コードの後、抜出されたデータが解釈されるのかを、より詳細に述べる。
【００４４】
１つの例において、第１の数のデータ単位は、データ型インジケータ９０を含み、このデータ型インジケータは、たとえば、１バイト長である。このデータ型インジケータ９０は、エスケープ開始シーケンス３１によって参照される第１の数のデータ単位の、あるバイト、たとえば第１のバイトにのみ置かれる。それに対して、第２の数のデータ単位にはそのようなデータ型インジケータは存在しないが、第２の数のデータ単位３４は、共に実行されるべきデータ単位、またはいわゆる「ペイロード」に完全に関与している。データ型インジケータ９０が用いられると、拡張デコーダは、継続コードの後に含まれるデータを、第１の数のデータ単位に含まれるデータと同じ型に属すると解釈する。これにより、データストリーム中で継続コードに続く第２の数のデータ単位には、これらが継続データであるかどうか、またはどのデータ型を第２の数のデータ単位は有するかについての情報を含む信号通知が不要であることが可能となる。代わりに、それぞれまるで分離がなかったかのように、第１の数のデータ単位中のデータ型インジケータが単純に第２の数のデータ単位に対しても用いられもしくは適用され、または、第２の数のデータ単位中のデータは、第１の数のデータ単位に単純に加えられ、これにより次にそれらは共に実行もしくは処理される。
【００４５】
この発明のスケーラブルなデータストリームの利点は、一般的な規格に基づいているという点である。したがって、オブジェクトをインポートし、ＸＭＬフォーマットでさらに処理することができる。
【００４６】
データストリームは、リスナーがどこにいようともテキスト情報に直ちにアクセスできるようになったので、リスナーに対し追加の価値を提供する追加のデータチャネルとして、デジタル放送システムに特に適しており、デジタル放送のための受信機は、少なくともテキスト情報を表示する単純な受信機か、または第１の数のデータ単位および第２の数のデータ単位のどんなデータ処理でも行なうことができる、特に複雑で、よって当然より費用集約的な受信機かのいずれかである。費用が嵩まないのみならず、その上したがって大量生産品として利用可能でもあるテキスト表示部を有する受信機は、リスナーに対して追加の価値を生み出すことができるということになる。しかしながら、データストリームは、グラフィカルユーザインターフェイスと任意選択的音声再生とを備えたハイエンド受信機にも適している。こうしたすべては、単純な実装によって、費用の嵩まない受信機においてさえ、どのデータが現在有効であるかにユーザが対処しなくてもよい特に単純な使用方法で得られる。代わりに、データの削除またはデータの実行は、ユーザがそれに対処する必要なしに、どの受信機をユーザが有するかによって完全に自動的に行なわれる。
【００４７】
さらに、ある例においては、テキストデータは、オブジェクト指向に記述されており、こういったオブジェクトはすべて、独立かつ自己完結型の単位である。よって、グローバ
ルデータ構造を受信機中にアセンブルするまたは維持する必要はない。オブジェクトは、データカルーセルの形態で伝送され、データキャッシュは受信機で有利に用いられる。たとえば、メニューデザイン、ニュース記事、速報ニュースであり得るテキストデータは、いわゆるＮＭＬオブジェクトとして伝送され、ＮＭＬとは、ニュースサービスマーク言語（News Service Mark Language）を意味し、ＸＭＬベースの２進エンコードされたコンテンツ表現と似ている。
【００４８】
好ましくは、１６進コード１Ａは、開始エスケープコード３１ａとして用いられ、１６進コード１Ｂは、たとえば、継続コードとして用いられる。図３ｃのデータ型インジケータ９０は、以下に説明するように、いくつかのデータ型を示すことができる。以下のデータ型インジケータ値は、例示的なものにすぎない。「００」というインジケータは、パディングを示す。含まれたデータは、パディングバイトを運び、このコンテンツは、拡張デコーダと基本デコーダとの両方によって無視される。これに代わる型のデータセットは、インジケータ「０１」を有し、絶対タイムアウトをあらわす。ＮＭＬオブジェクトの絶対表示タイムアウトまでの時間が定義される。このタイムアウトが経過すると、ＮＭＬオブジェクトは表示されなくなる。このエスケープ継続コード表現は、個々のＮＭＬオブジェクトを作るために必要とされる。サービス全体に対する一般的なタイムアウトがこれに代えて説明される。データ型インジケータの後のペイロードは、２０００年１月１日からの１５分間の数を符号のない２４ビット整数として含み、これは、４５０年間を超える範囲をカバーする。「０２」型のデータ型インジケータは、相対タイムアウトを示す。ここで、ＮＭＬオブジェクトの相対表示タイムアウトまでの時間が定義される。この時間が経過すると、ＮＭＬオブジェクトは、表示されなくなる。タイムアウトは、オブジェクトが既にキャッシュに格納されているときでさえ、ＮＭＬオブジェクトの各受付けから始まる。このエスケープシーケンスコードは、個々のＮＭＬオブジェクトを作る役目をする。ペイロードデータは、符号のない（符号なし）１６ビット整数として分数を含み、これは、４５日間を超える範囲をカバーする。一般に、タイムアウトデータは、図７のタイムアウト制御１００によって処理される。
【００４９】
データ型インジケータ「０３」は、一般リンクターゲットに関する。一般リンクターゲットとは、ユーザが明示的に動作の実行を要求すると、すなわち「ホットボタン」機能がユーザインタラクションのために示されるまたは提供されると、たとえば接続制御１０１によって表示されるまたはアクティブにされるターゲットである。一般リンクターゲットは、すべての型のＮＭＬオブジェクトに対して定義することができる。現在表示されているＮＭＬオブジェクトの一般リンクターゲットの利用可能性は、ユーザが拡張受信機を有すると、何らかの方法でユーザへ伝えられる。たとえば図３ｃに示されたペイロードデータは、以下のフォーマットを有する。１バイトは接続型を表わし、ｎバイトは、リンクアドレスを表わす。以下のリンク型値は、たとえば、利用可能である。リンク型が、たとえば「００」である値を有すると、それに続く２バイトは、同じデータサービスにある別のＮＭＬオブジェクトのオブジェクトＩＤである。
【００５０】
たとえば「０１」である別のリンク型バイトには、ＵＲＩ文字列が続き、さまざまなＤＡＢ／ＤＲＭ多重伝送、サービス、またはサービス要素を指し示す。
【００５１】
ＵＲＬ文字列を示す「０２」などの別の接続型は、インターネットアドレスまたは文書を指し示す。
【００５２】
電話番号が後に続く「０３」などの別のリンク型は、電話で連絡を取ることができる音声サービスを指し示す。番号は、ここでは、たとえば、国際識別番号、たとえば「＋［国際国番号］」から始まる。
【００５３】
一般に、拡張受信機は、未知のリンク型値を無視するように設計されている。
もう１つのデータ型インジケータ「ＦＦ」は、たとえば、著作権のあるデータ型インジケータとして考えられ、こういった著作権データを評価することのできる特定の拡張受信機のみに関係したデータの前に付く。
【００５４】
上記のオブジェクト管理型と対照的に、データ単位は、コンテンツ管理型も含むことができる。「２０」というデータ型インジケータは、キーワードとも呼ばれ、後に続くキーワードに任意選択的キーワード記述とともに印を付ける。キーワードは、たとえば、図７の問合せ生成手段１０２によって示されるように、受信者ベースの検索インデックスを生成するために用いることができる。ペイロードデータ部分は、以下のフォーマットを有する。まず、キーワードの長さを有する長さコードがあり、長さ−１と等しい値が符号なし整数として示されている。キーワードとして扱われるべきこのデータ部分に続く視覚的テキスト文字の数が識別されている。次に、ｎバイトある記述が続き、任意選択的記述を、キーワードに加えて索引付けすることができかつ／またはユーザに対して表示することができる。
【００５５】
たとえば「２１」という別のデータ型インジケータは、マクロ定義を表わす。マクロは、単純な参照でコンテンツ部分の任意の場所に何回か挿入することができる任意選択的エスケープシーケンスを含むテキスト部分の定義を可能にする。たとえば、マクロは、文書のテキスト要素に加えて、説明されるべき音声記述を定義することができる。データ部分は、まず１バイトのマクロＩＤ（０から２５５）が以下のマクロ定義を識別するフォーマットを有する。次にｎバイトあるマクロ定義が続く。このマクロがそのＩＤによって参照されるとき常に挿入されるべきテキスト（エスケープシーケンスを含む）は、ｎバイトあるマクロ定義に含まれている。なお、受信機はマクロを無視することもできるので、マクロは、必ずしも必須情報に対して用いられるべきでないことが留意されるべきである。別のデータ型インジケータ「２２」は、たとえば、マクロ参照を意味する。そのＩＤによって参照されるマクロ定義は、ユーザへ表示するためにエスケープシーケンスのこの位置に実質上導入される。データ部分は、マクロ定義を参照する１バイトのマクロＩＤ（０から２５５）を含む。マクロは、一般に、図７のマクロプロセッサ１０３によって処理される。
【００５６】
データ型の別のグループは、音声支援型を含むことができる。たとえば「Ａ０」というデータ型インジケータは、標準言語または予め設定された言語を定義する。ここで、ＮＭＬオブジェクトの予め設定された言語は、それぞれ記述または参照される。データ部分、すなわち、図３ｃのペイロードは、小文字の３文字ＩＳＯ言語コードを有する。
【００５７】
たとえば「Ａ１」によって参照される別の音声支援型は、言語部分である。これは、特定の数のテキスト部分またはＮＭＬオブジェクトの特定の部分の言語を定義する。ペイロード部分は、以下のフォーマットを有する。１バイトを有するテキスト長が存在し、その値は、符号なし整数として、このテキスト長−１のデータ単位の数の値に等しい。これは、言語定義が適用されるこのデータ部分に続く視覚的テキスト文字の数を識別する。次に、３バイトのグループが言語定義を備えて続き、このグループは、小文字の３文字ＩＳＯ言語コードを有する。
【００５８】
別の言語支援型は、たとえば、データ型インジケータ「Ａ２」によって索引付けされている。このデータ型インジケータは、音声音素に関し、テキスト部分の音素記述を国際音標文字（ＩＰＡ）を用いて定義する。ペイロード部分のフォーマットは、まず値が整数である１バイトのテキスト長を有する。このバイトは、このデータ部分に続く視覚的テキスト文字の数を識別し、これは、音声定義によって表わされる。次に、ＩＰＡ音素を備えたｎバイトのグループが続く。このグループは、ＩＰＡ表記として音素の音素定義を含む。
【００５９】
別の音声支援型は、たとえば、データ型インジケータ「Ａ３」によって参照され、エスケープシーケンスの位置に挿入されるべきテキスト‐音声プロセッサのための中断を定義する音声中断を含む。データ部分は、符号なし整数として１バイトを運び、このバイトは、０．１秒単位で音声時間を定義する。
【００６０】
別の音声支援型は、たとえばデータ型インジケータ「Ａ４」を有することができ、テキスト‐音声プロセッサによって連続した単語または数字ではなく個々の文字または数字として扱われるべき、エスケープ開始シーケンスに続く文字と、特に視覚的テキスト文字の数とを定義する。ペイロード部分は、１バイトを運び、視覚的テキスト文字の数をそれぞれの値を有する符号なし整数として定義する。
【００６１】
なお、すべてのこういったデータ型は、長さコードによって表わすことができる最大の数に応じて、図３ａの第１の数のデータ単位３２に表わすことができるか、またはデータ単位の数がすべてのデータを書くためには不十分なときは、エスケープ継続シーケンスから各々開始されることができる第２の数のデータ単位に含めることができるかのいずれかであることが留意されるべきである。データ型インジケータによって参照されるすべてのデータ型が、エスケープ開始シーケンスの後とエスケープ継続シーケンスの後との両方にデータ単位を有する必要が必ずしもあるわけではないということになる。代わりに、短いデータ型でさえも継続を必要としない単なるデータを含むことができる。なぜならば、こういったデータのデータ単位の数は長さコード３１ｂによって表わすことができるデータ単位の最大の数よりも少ないからである。
【００６２】
状況に応じて、この発明のどの方法も、ハードウェアにおいてまたはソフトウェアにおいて実現することができる。このような方法は、デジタル記憶媒体、特にディスクまたはＣＤ上で、プログラム可能なコンピュータシステムと方法が実行されるよう協働することができる電子的に読取可能な制御信号を用いて実現することができる。よって、一般に、この発明には、機械読取可能媒体に格納された、コンピュータプログラム製品がコンピュータ上で実行されるときこの発明の方法を実行するためのプログラムコードを備えたコンピュータプログラム製品も含まれる。言い換えれば、この発明は、コンピュータプログラムがコンピュータ上で実行されるときこの方法を実行するためのプログラムコードを備えたコンピュータプログラムとして実現化することができる。
【００６３】
生成するための装置の実施例に従って、データストリームは、シリアルデータストリームであり、入力手段１０は、エスケープ開始シーケンス３１をデータストリームにテキストデータ３０の後ろまたは前に入力し、かつ、エスケープ継続シーケンス３３をデータストリーム中に第１の数のデータ単位３２の後ろに入力するように実装されている。
【００６４】
生成するための装置の好ましい実施例に従って、入力手段１０は、まずテキストデータ３０を、次にエスケープ開始シーケンス３１を、次に第１の数のデータ単位を、次にエスケープ継続シーケンス３３を、次に第２の数のデータ単位３４を、データストリーム中に置くように実装されている。
【００６５】
生成するための装置の好ましい実施例に従って、長さコード３１ｂは、データストリーム中にエスケープ開始コード３１ａの直後に入力され、または長さコード３３ｂは、データストリーム中に継続コード３３ａの直後に入力される。
【００６６】
生成するための装置の好ましい実施例に従って、データストリーム中に継続コード３３ａの後に入力された長さコード３３ｂと、データストリーム中にエスケープ開始コード３１ａの後に入力された長さコード３１ｂとは、長さエンコードのための同じエンコードテ
ーブルから生じている。
【００６７】
生成するための装置の好ましい実施例に従って、データストリーム中のデータ単位は、等しく、予め定義された複数のビットを各々含む。
【００６８】
生成するための装置の好ましい実施例に従って、予め定義された複数のビットは、１つのデータ単位が１バイトであるよう８に等しい。
【００６９】
生成するための装置の好ましい実施例に従って、データストリームは、第１の型の基本受信機によって、および第２の型の拡張受信機によって読むことができるべきものであり、入力手段１０は、基本受信機および拡張受信機によって検出することができるテキストデータコードを用いるように実装されている。
【００７０】
生成するための装置の好ましい実施例に従って、エスケープ開始コード３１ａは、エスケープ継続シーケンス３３内の継続コード３３ａと長さが同じであり、この長さは、１つのデータ単位の長さと等しい。
【００７１】
生成するための装置の好ましい実施例に従って、長さコードは、１から２５６バイトのコンテンツ長をエンコードするように実装されている。
【００７２】
生成するための装置の好ましい実施例に従って、データ型インジケータ９０は、基本デコーダによって解釈可能でなくともよいが、拡張デコーダによって解釈可能なものである。
【００７３】
生成するための装置の好ましい実施例に従って、入力手段１０は、データ型インジケータに続いて、データ型インジケータ９０によって示されたデータ型を有するデータを入力するように実装されている。
【００７４】
生成するための装置の好ましい実施例に従って、入力手段１０は、データ型インジケータ９０を、データストリーム中にエスケープ開始シーケンス３１の長さコード３１ｂの直後の第１の数のデータ単位３２に入力するように実装されている。
【００７５】
読むための装置の好ましい実施例に従って、データストリームは、バッファ中にラッチされており、プロセッサ７１は、第１の数のデータ単位３２および第２の数のデータ単位３４をバッファから削除し、連続的にバッファを読出すように実装されており、またはバッファを読出すとき、第１の数のデータ単位３２および第２の数のデータ単位３４が格納されているバッファの領域がスキップされるようにバッファを制御するように実装されている。
【００７６】
読むための装置の好ましい実施例に従って、第１の数のデータ単位３２は、第１の数のデータ単位３２と第２の数のデータ単位３４とのデータ型を示すためのデータ型インジケータ９０を含み、プロセッサ７１は、データ型インジケータ９０を読出し、データ型インジケータ９０に従って、第１の数のデータ単位３２と第２の数のデータ単位３４とを共に処理するように実装されている。
【００７７】
読むための装置の好ましい実施例に従って、ターゲットは、データストリーム中のテキストデータを備えたオブジェクト、ＤＡＢ／ＤＲＭ多重伝送、サービスまたはサービス要素、インターネットアドレス、インターネット上の文書、または電話番号である。
【００７８】
読むための装置の好ましい実施例に従って、プロセッサ７１は、第１のデータ単位３２
または第２のデータ単位３４を、解釈不可能なターゲットをそのデータ単位が定義するとき、無視するように実装されている。
【００７９】
読むための装置の好ましい実施例に従って、第１の数のデータ単位３２、第２の数のデータ単位３４、またはさらなるデータ単位は、音声プロセッサ７３のための音声支援データを含むデータ型インジケータ９０を有し、音声支援データは、テキスト部分の言語を示し、音声音素を含み、音声中断に関連し、または音声文字を有し、プロセッサ７１は、音声支援データを出力するように、かつその音声支援データを、音声出力を生成するためまたは音声出力に影響を与えるための音声プロセッサに供給するように実装されている。
【００８０】
好ましい実施例において、データストリームは、コンピュータ読取可能媒体に格納されている。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データストリームを生成するための装置であって、
入力手段（１０）を備え、前記入力手段は、テキストデータ（３０）をデータストリーム中に入力するためのものであり、エスケープ開始シーケンス（３１）を前記データストリーム中に入力するためのものであって、前記エスケープ開始シーケンスは、基本デコーダによってスキップされるべきであって、かつ、拡張デコーダによって解釈されるべきである第１の数のデータ単位を定義し、前記入力手段は、前記第１の数のデータ単位（３２）を前記データストリーム中に入力するためのものであり、エスケープ継続シーケンス（３３）を前記データストリーム中に入力するためのものであって、前記エスケープ継続シーケンスは、基本デコーダによってスキップされるべきであって、かつ、拡張デコーダによって前記第１の数のデータ単位とともに解釈されるべきである第２の数のデータ単位を定義し、前記入力手段は、前記第２の数のデータ単位（３４）を前記データストリーム中に入力するためのものである、装置。
【請求項２】
前記エスケープ開始シーケンス（３１）は、エスケープ開始コード（３１ａ）と長さコード（３１ｂ）とを有し、または前記エスケープ継続シーケンス（３３）は、継続コード（３３ａ）と長さコード（３３ｂ）とを有し、前記エスケープ開始コード（３１ａ）または前記継続コード（３３ａ）は、テキストコードと異なる、請求項１に記載の装置。
【請求項３】
前記入力手段（１０）は、前記エスケープ開始シーケンス（３１）と予め決定された関係で、前記第１の数のデータ単位と前記第２の数のデータ単位（３４）との両方のデータ型を示すデータ型インジケータ（９０）を、前記データストリーム中に入力するように実装されている、請求項１または２に記載の装置。
【請求項４】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリームを読むための装置であって、
テキストデータ（３０）を表示するための手段（７２）と、
プロセッサ（７１）とを備え、前記プロセッサは、前記第１の数のデータ単位をスキップするための前記エスケープ開始シーケンスから前記第１の数のデータ単位が決定されるよう前記エスケープ開始シーケンス（３１）を解釈するためものであり、前記第２の数の
データ単位（３４）をスキップするための前記エスケープ継続シーケンスから前記第２の数のデータ単位（３４）が決定されるよう前記エスケープ継続シーケンス（３３）を解釈するためものである、装置。
【請求項５】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリーム読むための装置であって、
前記テキストデータ（３０）を表示するための手段（７２）と、
プロセッサ（７１）とを備え、前記プロセッサは、前記第１の数のデータ単位（３２）が読込まれるよう前記エスケープ開始シーケンス（３１）を解釈するためのものであり、、前記第２の数のデータ単位（３４）が読込まれるよう前記エスケープ継続シーケンス（３３）を解釈するためのものであり、前記テキストデータ（３０）を表示することに加えてまたは代わりに、前記第１の数のデータ単位（３２）と前記第２の数のデータ単位（３４）とを一緒に処理する（７３）ためのものである、装置。
【請求項６】
前記第１の数のデータ単位（３２）および前記第２の数のデータ単位（３４）は、接続ターゲットを定義し、
前記プロセッサ（７１）は、前記ターゲットへのデータ接続を実行するように実装されている、請求項５に記載の装置。
【請求項７】
前記第１の数のデータ単位（３２）もしくは前記第２の数のデータ単位（３４）、またはさらなる数のデータ単位は、オブジェクトの絶対または相対タイムアウトまでの時間を定義し、
前記プロセッサ（７１）は、前記タイムアウトまでの時間と前記テキストデータおよび拡張されたマルチメディアコンテントを表示するためのプロセッサ時間との比較を有するタイムアウト制御（１００）を、前記タイムアウトまでの時間に前記プロセッサ時間が達していないときにのみ行なうように実装されている、請求項５または６に記載の装置。
【請求項８】
前記第１の数のデータ単位（３２）および前記第２の数のデータ単位（３４）、またはさらなるデータ単位は、キーワードとして解釈されるテキスト文字を定義し、前記プロセッサ（７１）は、前記キーワードに基づいてデコードするための装置においてデータベース問合せを行なうための検索問合せ生成手段（１０２）を有する、請求項５から７のいずれか１項に記載の装置。
【請求項９】
前記第１の数のデータ単位（３２）もしくは前記第２の数のデータ単位（３４）、またはさらなるデータ単位は、マクロデータを有し、前記プロセッサ（７１）は、前記マクロデータによって定義されたマクロを実行するためのマクロプロセッサ機能（１０３）を行なうように実装されている、請求項５から８のいずれか１項に記載の装置。
【請求項１０】
前記第１の数のデータ単位（３２）、前記第２の数のデータ単位（３４）、またはさらなる数のデータ単位は、音声記述を表わすデータ型インジケータ（９０）を有し、前記プロセッサ（７１）は、音声出力に影響を与えるための前記データ単位によって制御することができる音声プロセッサ（７３、１０４）を有する、請求項５から９のいずれか１項に記載の装置。
【請求項１１】
データストリームを生成する方法であって、
テキストデータ（３０）をデータストリーム中に入力するステップと、
エスケープ開始シーケンス（３１）を前記データストリーム中に入力するステップとを備え、前記エスケープ開始シーケンスは、基本デコーダによってスキップされるべきであ
って、かつ、拡張デコーダによって解釈されるべき第１の数のデータ単位を定義し、さらに
前記第１の数のデータ単位（３２）を前記データストリーム中に入力するステップと、
エスケープ継続シーケンス（３３）を前記データストリーム中に入力するステップとを備え、前記エスケープ継続シーケンスは、基本デコーダによってスキップされるべきかつ拡張デコーダによって前記第１の数のデータ単位とともに解釈されるべき第２の数のデータ単位を定義し、さらに
前記第２の数のデータ単位（３４）を前記データストリーム中に入力するステップを備える、方法。
【請求項１２】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリームを読む方法であって、
テキストデータ（３０）を表示するステップ（７２）と、
前記第１の数のデータ単位が前記エスケープ開始シーケンスから決定されるよう前記エスケープ開始シーケンス（３１）を解釈するステップと、
前記エスケープ開始シーケンスを解釈するステップに基づいて前記第１の数のデータ単位をスキップするステップと、
前記第２の数のデータ単位（３４）が前記エスケープ継続シーケンスから決定されるよう前記エスケープ継続シーケンス（３３）を解釈するステップと、
前記エスケープ継続シーケンスを解釈するステップに基づいて前記第２の数のデータ単位（３４）をスキップするステップとを備える、方法。
【請求項１３】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリームを読む方法であって、
前記第１の数のデータ単位（３２）が決定されるよう前記エスケープ開始シーケンス（３１）を解釈するステップと、
前記エスケープ開始シーケンスを解釈するステップに基づいて前記第１の数のデータ単位を読込むステップと、
前記第２の数のデータ単位（３４）が決定されるよう前記エスケープ継続シーケンス（３３）を解釈するステップと、
前記エスケープ継続シーケンスを解釈するステップに基づいて前記第２の数のデータ単位を読込むステップと、
前記テキストデータ（３０）を表示するステップに加えてまたは代わりに、前記第１の数のデータ単位（３２）と前記第２の数のデータ単位（３４）とを一緒に処理する（７３）ステップとを備える、方法。
【請求項１４】
コンピュータ上で実行されるときに、請求項１１〜１３のいずれか１項に記載の方法を行なうためのプログラムコードを含むコンピュータプログラム。
【請求項１５】
テキストデータ（３０）と、第１の数のデータ単位（３２）を定義するエスケープ開始シーケンス（３１）と、前記第１の数のデータ単位（３２）と、第２の数のデータ単位を定義するエスケープ継続シーケンス（３３）と、前記第２の数のデータ単位（３４）とを有するデータストリーム。
【国際調査報告】
2010518766.tif 000010
2010518766.tif 000011
2010518766.tif 000012
2010518766.tif 000013