(57)【特許請求の範囲】
【請求項１】
少なくとも１個の受像機を有するディジタルテレビジョン伝送システムにおいてデータに索引を付ける方法であって、上記受像機側で、
伝送されたディジタルデータストリームから、ネットワーク、チャネル、サービス、イベント、又は同種の記述子の階層的に構造化されたリストを抽出する第１の段階と、
抽出されたリスト毎に、上記抽出されたリストの各要素に対するアドレスポインタであって、各要素に関係した付加的な情報が記憶される上記受像機内のメモリ領域を指し示すアドレスポインタを含む配列を作成する第２の段階と、
所与の要素が属する上記抽出されたリスト内の上記所与の要素の索引と、上記階層内で上記所与の要素よりも上方にある要素の索引との連結により構成された論理キーを用いてリスト内の上記所与の要素を参照する第３の段階とを含むことを特徴とする方法。
【請求項２】
上記リストの記憶は、上記リストの要素を同一サイズの数個の配列の系列に亘って配分することにより行われ、上記系列内の各配列は上記系列内の次の配列へのアドレスポインタを収容することを特徴とする請求項１記載の方法。
【請求項３】
各配列は２のべき乗の個数の要素アドレスポインタを含むことを特徴とする請求項１又は２記載の方法。
【請求項４】
索引値のサイズは上記ディジタルテレビジョン伝送システムにおけるネットワーク、チャネル、サービス、イベント、又は記述子の対応するリストのアイテム数に比例することを特徴とする、請求項１記載の方法。
【発明の詳細な説明】
本発明は、ディジタルテレビジョン伝送システムにおいてデータ、特に、サービス情報に索引を付ける方法に関する。本発明はかかるテレビジョンシステムの受像機に使用される。
ＤＶＢ（直接ビデオ放送）のようなある種のディジタルテレビジョンシステムは、例えば、受信されるディジタルデータストリーム若しくは他のディジタルデータストリームの階層構造に関する情報を含むサービス情報（’ＳＩ’データ）の伝送のため準備する。この階層は幾つかの伝送ネットワークにより構成され、各伝送ネットワークは幾つかのチャネルにより構成され、各チャネルは幾つかのサービスにより構成され、以下同様である。
ディジタルテレビジョンの受像機及びデコーダは、伝送されたデータに適切にアクセスするため、この階層を知る必要がある。しかし、この階層の管理は、一方で階層の進化性に特有の問題を、他方で消費者電子製品の制約と必ずしも整合しない標準的な制約に特有の問題を生ずる。例えば、階層（ネットワーク、チャネル、サービス等以下同様）内の各要素は、標準化されたかなり長い識別子によって識別され、記憶容量及び処理の問題を生ずる。一例として、固有にサービスを識別するため、理論的に８バイトが必要である。この８バイトは、このサービスを参照するため毎回使用される必要があるので、受像機のアプリケーションによって多数回に亘って記憶されなければならない。
本発明の目的は、少なくとも１台の受像機を含むディジタルテレビジョン伝送システムにおいてデータに索引を付ける方法を提供することであり、上記方法は、受像機側で、
伝送されたディジタルデータストリームから、ネットワーク、チャネル、サービス、イベント、又は、同種の記述子の階層的に構造化されたリストを抽出し、
抽出されたリスト毎に、上記抽出されたリストの各要素に対するアドレスポインタであって、各要素に関係した付加的な情報が記憶される受像機内のメモリ領域を指し示すアドレスポインタを含む配列を作成し、
所与の要素が属する上記配列内の上記所与の要素の索引と、上記階層内で上記所与の要素よりも上方にある要素の索引との並置により構成された論理キーを用いてリスト内の上記所与の要素を参照する段階を含む。
受像機は、アクセスするデータ階層の少なくとも一部分を表現するイメージを構成する。ネットワークリスト、チャネルリスト、サービスリスト、イベントリスト、又は、他の要素（サービスブーケ等）のリストは、受像機によって記憶され、索引を付けられる。索引付けは、識別子を記憶するため必要なメモリの量をかなり減少させる。
データに階層的な性質がある場合、単に配列索引を並置することにより受像機によって保持されたデータベース内の要素に対し「論理キー」を作成することが正当化される。例えば、受像機によって使用されるようなネットワーク内のサービスの「論理キー」は、ネットワークとサービスが属するチャネルの配列索引、並びに、サービス自体の配列索引によって形成される。要素の操作は、「論理キー」を通じて受像機によって行われる。索引と要素の間の関係が確立された後、索引は、要素を参照するため（要素の識別子の代わりに）受像機によって内部的に使用される。論理キーは、取得されるべきデータのパスを伝達し、高速アクセスを保証する。
本発明の一実施例によれば、要素のリストは同一サイズの数個の配列の系列に亘って分布し、上記系列内の各配列は上記系列内の次の配列へのアドレスポインタを収容する。
本発明の一実施例によれば、各配列は２のべき乗の個数の多数の要素アドレスポインタを含む。
２のべき乗の個数を用いることにより、要素の論理キー中の適当なビット数を適切にマスクすることによって所与の要素を含む配列を容易に入手できるようになる。
本発明の他の特徴及び利点は、本発明の説明の一体的な部分を形成する添付図面に示された具体的な実施例の説明によって、その例に限定されることなく、明らかにされる。
図１は、本発明の一実施例を実施するテレビジョン受像機のブロック図であり、
図２ａ乃至２ｃは、本発明の一実施例に従って、アプリケーションとデータ管理モジュールとデータソースとの間で行われる交信のタイミングチャートであり、
図３ａ及び３ｂは、１回限りの要求及び持続的な要求の動作を説明する状態図であり、
図４は、アプリケーション、すなわち、本発明の一実施例による電子番組案内の画面を示す図であり、
図５は、管理モジュールによって保持されるデータベースの説明図である。
サービスデータのフォーマット及び内容、ＭＰＥＧ、ＤＶＢテーブル及びセクションに関する十分な情報を得るため、特に、以下の３件の文献を参考のため引用する。
文献（ａ）: ETS 300 468 - Specification for Service Information（SI）in Digital Video Broadcast（DVB）systems - January 23, 1996
文献（ｂ）: ISO/IEC 13818-1（1994）Generic Coding of Moving Pictures and Associated Audio - Recommendation H.220,″MPEG II Systems″
文献（ｃ）: ETR 211 - Digital Broadcasting systems for television: Implementation guidelines for the use of MPEG-2 systems; Guidelines on implementation and usage of service information
図１は、ＤＶＢ（ディジタルビデオ放送）タイプのディジタルテレビジョン統合型デコーダ／受像機のブロック図である。
本発明は、この物理的環境に制限されることはなく、別のタイプのサービスデータ伝送に容易に適用される。
図１において、デコーダはアンテナ１に接続され、アンテナ１はデコーダのチューナ２に接続される。チューナにより与えられる信号は復調器３によって復調される。復調されたデータは訂正器回路４によって訂正され、デマルチプレクサ５に伝達される。
デマルチプレクサ５は、例えば、１９９５年１２月２９日に出願人トムソン  マルチメディアの名称で出願された仏国特許出願第９５１５７６７号に記載されているデマルチプレクサと類似している。デマルチプレクサ５は、デコーダによってサポートされる種々のアプリケーションの関数としてマイクロプロセッサ２３によりプログラムされたある程度の数のフィルタを含む。図の簡単化のため、マイクロプロセッサ２３の中の最も重要なコネクションだけが図示されている。
デマルチプレクサによってフィルタされたオーディオ若しくはビデオパケット又はセクションは、上記アプリケーションに対する配慮のためバッファメモリ６の所定の領域に記憶される。必要に応じて、情報はバッファメモリ６に記憶される前に、最初にユーザの資格に依存して暗号解読回路７によって解読される。
本発明の実施例によれば、アプリケーションの数は、オーディオデコーダ１６と、ビデオデコーダ１７と、テレテキストデコーダ１８と、（暗号解読器７、照合器マイクロコントローラ８、及び、通常動作モードでマイクロプロセッサカード１０に接続されるマイクロプロセッサカード用インタフェース９を含む）アクセスコントロール集合部と、サービスデータ管理モジュールの５個である。
デコーダはリモートコントロール用赤外線インタフェース２４を更に有し、この赤外線インタフェースはマイクロプロセッサ２３に接続される。マイクロプロセッサ２３はメモリ１２に接続され、メモリ１２は、オペレーティングシステムと、アプリケーションを実行する常駐又はダウンロードされたプログラムとを含む。
交換式電話網１４に接続されたモデム１３はマイクロプロセッサによって制御される。
キャラクタジェネレータ１５は、デコーダのパラメータ若しくは特定のアプリケーションに関するコマンド又はグラフィックメニューの生成を可能にする。キャラクタジェネレータによって発生されたビデオ信号は、ビデオデコーダ１７若しくはテレテキストデコーダ１８から来るビデオ信号の一つと多重化され、テレビジョン２２に連結された第１のテレビジョン周辺ソケット（ＳＣＡＲＴソケット）又はビデオレコーダ２１に連結された第２のテレビジョン周辺ソケット２１に向けられる。多重化回路２０はマイクロプロセッサ２３によって管理される。
本発明は、特に、サービスデータ管理モジュールの動作に関する。本例の場合、このモジュールは、実際上、マイクロプロセッサにより管理されるプログラムであるが、概念的には、専用回路が使用されるオーディオ又はビデオデコーダと同様にデータパケットを処理するアプリケーションに関係する。
このモジュールは、サービスデータ（ＭＰＥＧとＤＶＢのテーブル及びセクション）と、クライアントアプリケーション（番組案内、電子売買、対話型ゲーム等）との間のインタフェースである。サービスデータ管理モジュールは、クライアントアプリケーションからの要求を管理し、受信されたサービスデータに基づく内部データベースを保持する。
本発明の一実施例によれば、クライアントアプリケーションはマイクロプロセッサによって管理される番組案内である。
管理モジュールは、アプリケーションによって必要とされる情報に関係した要求を定式化するためのある程度の数の機能がクライアントアプリケーションで利用できるようにさせる。
上記の要求機能は同時に動作する。要求が存在する場合、要求に対する応答は、応答が利用できるときに管理モジュールによってアプリケーションに通知される。このため、要求機能識別機構を実現する必要がある。この目的のため、発行された要求毎にアプリケーションによって識別子が選択され、要求と共に伝達される。この識別子は、管理モジュールによって応答の通知と連結される。
図２ａ乃至２ｃは、要求に続く、クライアントアプリケーションと、サービスデータ管理モジュールと、データのソース、すなわち、デマルチプレクサ／バッファメモリ／マイクロプロセッサ集合部との間の３通りの交信を示す。
図２ａは、内部データベース（“キャッシュメモリ”）がクライアントアプリケーションによって要求された情報を含む場合を示す。クライアントアプリケーションからの要求に続いて、この情報の利用可能性の通知が行われる。本例の場合、情報はデータベースに存在し、応答の通知は略即時的である。本例の場合、データ項目はソースとの間で送受されない。
図２ｂには、要求された情報項目が内部データベースに現れない場合が示されている。本例の場合、クライアントアプリケーションからの要求の後に、管理モジュールからアプリケーションに情報項目の一時的な利用不能を知らせるための通知が続き、その後に、管理モジュールによってデータソースに向けられたコマンドが続く。必要とされている情報項目に対応したセクションがバッファメモリに格納された分離（逆多重化）データのストリーム内で見つけられたとき、データソースは、そのセクションが利用可能である旨をＳＩモジュールに通知する。セクションのデータを読み、再フォーマットした後、管理モジュールは、必要とされている情報項目が利用可能である旨をクライアントアプリケーションに通知する。管理モジュールは、（セクションのデータの一部分に過ぎない場合がある）必要とされる情報項目を、クライアントアプリケーションによる最初の要求の間に割り当てられたバッファメモリに書き込む。この通知は、本例の場合、図２ａの場合よりも遅れて到達する。
変形例によれば、管理モジュールは情報項目が利用できない旨を通知しない場合がある。
図２ｃは、図２ａの場合のような最初の要求が、必要とされる情報項目の変更を通知する必要のある旨を指定する場合を示す図である。本例の場合、データストリームからこの情報項目を含むデータパケットを抽出することができるソースのフィルタは、動作を抑止されるのではなく、前の値のまま保たれる。このタイプの要求、いわゆる持続的な要求は後述される。
本発明の一実施例によれば、４種類の要求が存在する。
（ａ）単独要求
この要求がアプリケーションによって管理モジュールに対し指定された場合、管理モジュールは、要求されたデータの転送の時までに限りそのリソース（フィルタ及びメモリ）が利用できるようにする。
（ｂ）先行の１回限りの要求
この要求は、１回限りの要求の特性を有するが、優先度は低い。管理モジュールは、先行要求用と、非先行要求（先行ではない要求）用の２個のＦＩＦＯタイプのメモリを有する。待機中の先行要求は、常に、非先行要求の後に処理される。
（ｃ）持続的な要求
管理モジュールのリソースは、要求されたデータの分離及び転送後まで維持される。これらのデータが変更されたとき、通知がアプリケーションに伝送される。管理モジュールは、系統的な監視を行い、アプリケーションが監視を中断するコマンドを送信するまで監視し続ける。
（ｄ）先行の持続的な要求
この要求は、持続的な要求と類似しているが、優先レベルが低い。
この要求に割り当てられた優先度は、当然、これらの要求に関係したデータの実際の受信の順序を予め決めるものではない。受信順序は、各データ項目の周期性と、要求がこの周期に関して定式化される時点のような要因に依存する。
図３ａは、１回限りの要求の状態図であり、図３ｂは持続的な要求の状態図である。
アプリケーションが要求を定式化するとき、要求タイプを要求に付随させる必要がある。
持続的な要求の場合、ストリームから取得されたデータは、管理モジュールの内部データベースに記憶される。これは、データのコピーが保持されることのない１回限りの要求に従って取得されたデータの場合とは異なる。持続的な要求に関するデータを収容するテーブル又は記述子の新しいバージョンが検出されたとき（すなわち、テーブルのバージョンｉｄパラメータが変更されたとき）、このテーブル又はこの記述子の適当なデータがデータベース内のデータと比較される。更新の通知は、少なくとも１個の上記データ項目が変更された場合に限り伝送される。テーブル又は記述子のバージョン識別子は、実際上、たとえ、アプリケーションによって要求されていないデータだけに関係しているとしても、テーブルに含まれる変更とは無関係に変更される。この機構は、アプリケーションと管理モジュールとの間で冗長なデータの転送を防止する。
要求のタイプの選択はアプリケーションに任せられる。要求のタイプに関するアプリケーションの判定基準の一例として、図４には、番組案内画面が示されている。画面は二つの部分を含み、下側部分４０はリモートコントロールによるコマンド機能へのアクセスを提供し、上側部分４１は上記コマンドを用いて選択されたイベントのリストを含む。各イベント毎に、番組案内は、タイトルと、対応したサービスの名称と、開始時間と、終了時間とを表示する。
上側部分４０は、イベントのリストの一部分だけを表示する場合がある。その場合、他のイベントにアクセスするため、ユーザは、リモートコントロールのスクローリング矢印を使用する。
番組案内アプリケーションがリスト中のイベントの情報に関係した要求を管理モジュールに対して指定するとき、最初に表示されたイベントに関する要求は非先行タイプの要求であり、すなわち、優先される。実際上、この情報は必ず表示される必要がある。リスト中の他のイベントに関する要求は、先行タイプの要求であり、非先行要求の後に管理モジュールによって処理される。ユーザが探している件が最初に表示されたイベントの中に存在する場合、ユーザが実際にイベントをスクロールしたかどうかは確かではないので、実際上、アプリケーションが対応した情報を必要とするかどうかは明確ではない。上記データが要求された場合に、表示を高速化する目的のため、予めロードされる。先行要求に応じたデータが分離されたとき、管理モジュールは、この要求を発信したアプリケーションに対しその旨を通知する。アプリケーションによって利用可能にされたバッファへのデータの転送は、アプリケーションがその転送を要求しない限り行われない。
サービスデータ管理モジュールの一つの役割は、デマルチプレクサのフィルタをプログラムすることである。この機能を実現し、かつ、必要とされるデータへの高速アクセスを可能にするため、サービスデータ管理モジュールは、本発明の一実施例に従って、そのモジュールがアクセスするネットワークの物理的な構造のイメージを保持する。
引用文献（ａ）及び（ｂ）は、ネットワークの構造、バンドル、サービス及び伝送されたイベントに関する情報を与える１０個のテーブルを定義する。テーブルは、ＰＩＤ（パケット識別データ）及びテーブル識別子（table id）の特定の値によって識別され、これらの値は上記の文書によって定義される。各テーブルは、テーブルの伝送からテーブルの別の伝送までに、そのテーブルの内容が変更されたかどうかを判定することができるバージョン識別子を収容する。
バージョン識別子は、記述子又は記述子のグループのレベルで使用され、テーブルの記述子と併行に使用してもよい。
ここで関心のあるテーブルは、いわゆるＮＩＴ（ネットワーク情報テーブル）テーブルである。ＮＩＴテーブルは、所与の伝送ネットワークに関する情報、特に、伝送チャネル（トランスポートストリーム）毎に利用可能なサービスのリストを含む。
データ管理モジュールは、ネットワーク、チャネル及び利用可能なサービスの内部索引を構築する。デコーダがスイッチオンされたとき、又は、ＮＩＴテーブルが更新されたとき、論理キーが利用可能な各サービス毎に割り付けられる。この論理キーはモジュールによって維持されるデータベース内のサービスの索引であり、配列内の要素の索引、或いは、階層内でより上位にある配列内の連結された要素の索引により構成される。
ＤＶＢストリームの場合、サービスは以下の変数により構成されるルートによって個別に識別され得る。
−ネットワーク識別子network＿id
−トランスポートストリーム識別子transport＿stream＿idとオリジナルネットワーク識別子original＿network＿idの対
−サービス（本来の）識別子service＿id
上記の３個の変数は１６ビットで符号化された自然数である。
ネットワーク用のリストと、各ネットワーク毎のチャネルのリストと、各チャネル毎のサービスのリストの３種類のリストが作成される。
ネットワークのリスト中の要素は、新しいネットワークを含むＮＩＴテーブルが分離されるときに作成される。このため、ＰＩＤが0x0010に一致するトランスポートパケットがフィルタ処理される。これらのパケットは、付加的に変数table＿idによって識別されたＮＩＴテーブルを実質的に含む。４ビットのコードは対応したテーブルを分離する順に各ネットワークと関連付けられる。このコードは、ネットワークのリスト内において、このネットワークに関係する情報を含む構造のアドレスポインタの索引である。拡張されたとき、このコードはリスト内のネットワークの索引である。
ＮＩＴテーブルは、このネットワークに対するチャネルのリスト、並びに、各チャネル毎に利用可能なサービスのリストを含む。
ネットワークのリスト中の各ネットワーク毎に、チャネルのリストが作成される。チャネルのリスト中の各要素は、リスト内で５ビットの索引を付けられる。このリストは、各チャネルに特有のデータを含む構造のアドレスポインタを含む。データベース内でチャネルを識別する論理キーは、ネットワークの４個の索引ビットと、このネットワークのチャネルの５個の索引ビットとにより構成される。
各チャネル毎に、ＮＩＴテーブルに記述されたサービスの識別子を含むサービスのリストが作成される。リスト中の各サービスは７ビットで索引を付けられる。したがって、データベース内のサービスの論理キーは、併せて１６ビット、すなわち、４個のネットワーク索引ビットと、５個のチャネルビットと、７個のサービスビットとを含む。
サービスのイベントは、このイベントを表す１６ビット（テーブル中の変数イベント識別子event＿id）を用いて識別され、このイベント識別子には、関連したサービスの１６ビットの論理キーが付加される。かくして要素の論理キーを獲得するため、要素を固有に定義する識別子に対応した索引が並置されるだけで足りる。
データベースの（イベント以外の）の構造は以下の構造に従って構成される。
0004156032.tif 000002
0004156032.tif 000003
0004156032.tif 000004
項目アドレス（Address）を含む名称を有する変数は、データ構造の先頭に対応したメモリアドレスへのポインタである。
他の変数はデータストリームから取り出された情報に対応する。理解を助けるため、上記変数は括弧内の引用符””で示され、引用符に囲まれた名称が引用文献（ａ）で使用されている。
ネットワークのリスト、チャネルのリスト及びサービスのリストは配列として構成され、各配列は、一方で、ネットワーク、チャネル又はサービスタイプのデータ構造への８個のポインタにより構成され、他方で、リストの残りの部分を含む配列へのポインタにより構成される。後者のポインタは、他の配列が無い場合、すなわち、配列がリストの最後の要素を含む場合にヌルポインタである。
各配列は、２のべき乗に対応する８個の要素を含む。これにより、本例の場合、チャネル索引の最後の３ビットをマスキングすることによって所望のチャネルポインタを含む配列を決めることができる。
同一タイプの配列（例えば、全てがネットワーク配列）は、（本例の場合にネットワークリストである）対応したリストを形成する。所与のタイプの配列は、実質的に単一の配列を形成する。索引が割り付けられたとき、索引はリスト中の要素の索引を構成する。実質的な単一配列の各配列は８要素の長さを有するので、索引に関するビットマスクは、所与の要素を含む配列を決定する。
データベース配列は、ネットワークのリストの最初の部分を含む配列へのポインタを収容する。
ネットワークリスト（NetworksList）配列は、最初の８個のネットワークへのポインタを含む。本実施例の場合、ネットワークの完全なリストを収容する最大で２個のネットワークリスト（NetworksList）配列が存在する。
ネットワーク配列は、所与のネットワークに関係する情報と、このネットワークに付随したチャネルのリストへのポインタとを含む。
他の配列の構造は、上記の配列の構造と類似している。さらに、この構造をイベント及び他のタイプのデータに容易に拡張することができる。
他の実施例によれば、ネットワーク、チャネル及びサービスの構造に関するデータに関係した要求は、データベース内のネットワークのイメージを常に最新の状態に維持する目的のための持続的なタイプの要求である。
アプリケーションは、管理モジュールとの交信の際に論理キーだけを使用する。論理キーは、管理モジュールによって情報が記憶されるサイトに対応したメモリアドレスに翻訳される。
図５は管理モジュールのデータベースの説明図であり、同図のデータベースは、１個のネットワークが存在し、ネットワークが２個のチャネルを含み、各チャネルが２個のサービスを有する場合を表す。
配列内の要素の位置によって決定される論理キーは、アプリケーションに通知される。アプリケーションによってＳＩ管理モジュールに要求が出されたとき、例えば、現在イベントに対する要求が行われたとき（現在イベントに関する情報は後述する）、ＳＩ管理モジュールに送信された論理キーは、イベントが見つけられるべきサービスの論理キーである。一例として、論理キーが0000 0001 0000000である場合を想定する。これは、第１のネットワーク（索引０）と、第２のチャネル（索引１）と、第１のサービス（索引０）に対応する。
論理キー内のビットをシフトすることにより、ネットワーク、チャネル及びサービスの索引が決定され、本例の場合、（ネットワークポインタ、チャネルポインタ及びサービスポインタの）３個のポインタが読み取られる。現在イベントが内部データベースに既に記憶されているか、或いは、未だ記憶されていないかに依存して、サービス、トランスポートストリーム等の識別子がデマルチプレクサのフィルタを計算するために読み出される。
他の例では、論理キーが0001 01100 0000000である場合を想定する。これは、所望のサービスが第２のネットワークと、第１２のチャネルに存在することを示す。上記の如く、チャネル配列サイズが８要素に制限される場合、次の４個のポインタが読み出される。
−第２のネットワークへのポインタ
−チャネルリストの第２の配列へのポインタ（第１のチャネル配列の最後のポインタ）
−サービスリストへのポインタ（第２のチャネル配列内の第４のポインタ）
−サービスへのポインタ（適当なサービス配列内の第１のポインタ）
第２のチャネル配列へのポインタは、配列の間のギャップを連結するために必要とされ、本例の場合、第１のチャネル配列は８個の要素だけを収容する。
両方の例の場合、要求されたデータにアクセスする前に少数のポインタだけを計算すればよい。
アプリケーション的な要求のテーブルは、アプリケーションによって現時に定式化された要求のリストを与える。本例によれば、現時点の要求だけが、ネットワーク上に存在するサービスのリストを獲得するための持続的タイプの要求である。
管理モジュールの要求のテーブルは、アプリケーションの要求に応答するプリミティブ要求である。プリミティブ要求は、本例の説明中、デマルチプレクサレベルで単一のフィルタに翻訳され得る要求である。本例において、２個のチャネルがネットワーク内に存在する場合、２個のプリミティブ要求は、アプリケーション要求、すなわち、サービスのリスト毎又はチャネル毎に１個ずつの主要求を翻訳するため必要である。管理モジュールがアプリケーション要求をプリミティブ要求に分離する。
同図において、各プリミティブ要求に対応するフィルタは、管理モジュールの要求のテーブルの左側に示される。
図５に示された時点において、サービスリストが最初に獲得された場合を想定する。アプリケーション要求の持続的な性質を仮定すると、対応したフィルタ、並びに、この要求に関連したデータベースの内容が保持される。
リストと、リスト中の要素を連結する分枝を識別する数字は、リスト中の要素の索引（論理キー）に対応する。
アプリケーションは、ネットワーク内の現時点でのイベントのリストを取得しようとする。サービス毎に現在イベントが１個ずつ存在し、このため、対応したイベント情報テーブルＥＩＴ“ＥＩＴ現在／後続”テーブルをフィルタ処理する必要が生じる。
アプリケーションによって発行された要求は、所与のサービスにたいし、以下のパラメータを含む。
−要求識別子
−要求のタイプ
−関連したサービスの論理キー
−ベースに記憶されるイベント記述子のデータを示すフラグの組
−一方で、イベントの開始時間、期間、アクセスコントロールに関する情報の項目及びイベント名を収容し、他方で、フラグによって識別されたデータが格納され始めるアドレスへのアドレスポインタを収容するためのデータ構造
本実施例によれば、第１のチャネル（ＴＳ識別子＝７）内で現在するイベントに関連した要求は非先行タイプの要求であり、第２のチャネル（ＴＳ識別子＝９）に現在するイベントは先行している場合を想定する。これは、例えば、２個のイベントしか同時に表示できない場合、並びに、サービス１（サービス識別子＝１）のイベント及びサービス３（サービス識別子＝３）のイベントが画面に最初に表示される場合である。
現在イベントに関する細目を獲得するため、アプリケーションは、上記プリミティブ要求である４個の別個の要求を発する必要がある。ここで、上記要求に続く要求は持続的ではない場合を想定する。このとき、イベントに関するデータは、クライアントアプリケーションに転送された後、内部データベースに記憶されない。
管理モジュールは、プリミティブ要求を再検討し、非先行要求を優先して処理する。
アプリケーションによって送信された論理キーは以下の通りである。
０．０．０（１０進表記）
０．０．１
０．１．０
０．１．１
ここで、先頭の数字はネットワークを表し、２番目の数字は（チャネル、オリジナルネットワーク）対を表し、３番目の数字はサービスを表す。
２進表記では、
００００  ０００００  ０００００００
００００  ０００００  ００００００１
００００  ００００１  ０００００００
００００  ００００１  ００００００１
となる。
管理モジュールによって保持されたリストを用いることにより、最初の２個の要求に優先度が与えられた実際の識別子がデマルチプレクサに送信され得る。ＥＩＴテーブルのＰＩＤの値（PID=0x00  12）並びにＥＩＴ現在／後続テーブルの識別子（テーブル識別子=0x4E）は、引用文献（ａ）によって定義され、要求機能により索引を付けられたルックアップテーブルを介してアクセスすることができる。
この情報を用いることにより、デマルチプレクサのフィルタの中の１個のフィルタはプログラムされ得る。
他の実施例によれば、充分なメモリが存在しない場合、持続的な先行要求に対応して記憶されたデータの少なくとも一部分は消去される。
他の実施例によれば、現在の要求のタイプは変更してもよい。予測される具体的な例は、非先行の持続的タイプの要求を先行した持続的タイプの要求に変更することである。このような変更のための特有の機能は、クライアントアプリケーションにより利用することができる。
他の実施例によれば、管理モジュール自体はネットワークの構造（特に、ネットワークのリスト及び関連したチャネルのリスト）に関係したある種の要求を発生し、持続的な形でその要求を保持する。
本発明は、衛星、無線又は有線によるデータの伝送だけに限定されることはなく、データ又はデータパケットがデータストリーム中に周期的に現れる全てのシステムに利用することが可能であることに注意する必要がある。これは、特に、記録され、再読み出しされるデータストリームの場合である。
また、索引の長さは、アプリケーションの要求に従って変更してもよい。一部のテレビジョンシステムは少数のネットワーク及びチャネルだけを許容し、一部のテレビジョンシステムはより多くのネットワーク及びチャネルを許容する。この適合性は、受像機が少なくとも一部のカテゴリー（ネットワーク、チャネル等、．．．）内で最大個数の要素を監視し、リソースの使用を最適化するため監視の結果に応じて索引の長さを調節するという意味でダイナミックである。勿論、索引の長さ、換言すれば、割り付けられたビット数は、階層の同一レベルの全てのリストに対し同一出なければならない（すなわち、トランスポートストリームとは無関係に、全てのサービスがＡビットの索引を有し、全てのイベントはＢビットの索引を有し、以下同様である）。
【図１】
0004156032.tif 000005
【図２ａ】
0004156032.tif 000006
【図２ｂ】
0004156032.tif 000007
【図２ｃ】
0004156032.tif 000008
【図３ａ】
0004156032.tif 000009
【図３ｂ】
0004156032.tif 000010
【図４】
0004156032.tif 000011
【図５】
0004156032.tif 000012