JP4035209B2 - サイクリックパケットデータ伝送システムの受信機 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は少なくとも一つの送信機を含むサイクリックパケットデータ伝送システムの受信機に関する。本発明は例えば電子プログラムガイド型のデジタルテレビジョン及びサービス情報の伝送の分野に特に応用される。
【０００２】
【従来の技術】
例えばＤＶＢ（デジタルビデオ放送）規格によるデジタルテレビジョン伝送の基本仕様ではユーザーに送信されたプログラムに関する情報を与え、双方向性をある程度許容することを意図されたある数のデータ項目を送信するための規定が存在する。マルチプレックスされたデータストリームは定期的に更新されたデータベースを形成し、データの型及び割り当てられた帯域に関するデータ依存再送信周期で周期的に再送信される。
【０００３】
このデータベースの効率的な活用のためのツールの開発が必要である一方で受信機の可能性及び限界を考慮に入れることが必要となってきている。これらはメモリー及び計算能力に関して実際上制限される。
伝送に用いられるデータ構造（記述子、テーブル、．．．）は受信機がデータストリーム内で検出された構造が情報の新たな項目を含むか否かを決定することを可能にするバージョン番号を含む。
【０００４】
受信機で更新されたデータは特に表示器のリフレッシュに関する適切なアプリケーションに関して考慮すべき処理を含む。
【０００５】
【発明が解決しようとする課題】
本発明の目的は資源を最適化可能な受信機を提供することにある。
【０００６】
【課題を解決するための手段】
上記目的は少なくとも一つの送信機を含むサイクリックパケットデータ伝送システムの受信機であって、
− 該データパケットをデマルチプレックスし、濾波（フィルター）する手段と、
− 濾波により抽出されたパケットのデータ構造から選択されたデータからデータベースに記憶する手段と、
− データベースに現れるデータを含むデータ構造の更新を検出する手段と、
− データ構造の更新を検出した場合にはデータベースに記憶されたデータと該更新されたデータ構造の対応するデータとを比較し、差が存在する場合にのみこの差をクライアントのアプリケーションに知らせる手段とを含むことを特徴とする受信機により達成される。
【０００７】
データ構造のバージョン番号は構造内のデータの一つのみが変更される場合ですら変更されるものである。更新されたデータがアプリケーションにより用いられたデータではない場合、又はそれ以外の状態で、受信機のデータベースに記憶されているデータが変更されている場合にはアプリケーション又は変化に関するアプリケーションに通知することは利益がないことである。このようにしてその値が実際変化されないデータの冗長な処理が回避される。
【０００８】
一実施例によればデマルチプレックスし、濾波する手段はクライアントのアプリケーションからのリクエストに従ってプログラムされる。
特定の実施例によればクライアントアプリケーションは電子的プログラムガイド型のアプリケーションからなる。
特定の実施例によればアプリケーションは各リクエストに対する優先レベルを決定し、デマルチプレックスし、濾波する手段及び記憶手段の資源は最高の優先レベルを有するリクエストに対して最初の時点で指定される。
【０００９】
内部処理及び資源の配分の観点からあるリクエストを他のリクエストに関して優先させることにより特にこれらのデータが必要とされる時間に依存するその重要度に関してデータを階層化することが可能となった。
特定の実施例によれば先行（ａｄｖａｎｃｅ）優先レベルと非先行優先レベルが設定され、非先行優先レベルは先行優先レベルよりも高い。
【００１０】
特定の実施例によれば非先行優先レベルはそのアプリケーションによる使用が確実であるリクエストに関連したデータに割り当てられ、他方で先行優先レベルはそのアプリケーションによる使用が有望であるが確実ではないリクエストに関連したデータに割り当てられる。
特定の実施例によれば非先行優先レベルはできるだけ早く表示されるリクエストに関連したデータに割り当てられる。
【００１１】
特定の実施例によればアプリケーションはリクエストが恒久的なものか又は一回限りのものかを決定し、恒久的なリクエストは恒久的なリクエストが由来するアプリケーションから反対のインストラクションがあるまでデマルチプレックスし、濾波する手段のプログラミングのレベルで維持され、他方で一回限りのリクエストは対応するデータパケットを得た後にデマルチプレックスし、濾波する手段のプログラミングのレベルで消去される。
【００１２】
特定の実施例によれば記憶手段に記憶されたデータは恒久的なリクエストに対応するデータである。
【００１３】
【発明の実施の形態】
本発明の他の特徴及び利点は本発明の一部を形成する図を参照して非限定的な実施例により以下に詳細に説明される。
サービスデータ、ＭＰＥＧ及びＤＶＢのテーブル及びセクションのフォーマット及び内容に関するより完全な情報に対して以下の３つの文献を特に参照する：（ａ）ＥＴＳ ３００ ４６８ −デジタルビデオ放送（ＤＶＢ）のサービス情報（ＳＩ）に対する明細書−１９９６年１月２３日、
（ｂ）ＩＳＯ／ＩＥＣ １３８１８−１ （１９９４） 動画及び関連するオーディオの一般的なコーディング − 勧告Ｈ．２２０、「ＭＰＥＧ ＩＩシステム」とまた称される、
（ｃ）ＥＴＲ ２１１ − テレビジョン用のデジタル放送システム：ＭＰＥＧ−２システムの使用に対するガイドラインの実施；サービス情報の実施及び使用のガイドライン。
【００１４】
図１はＤＶＢ（デジタルビデオ放送）型のデジタルテレビジョン一体型デコーダ／受信機のブロック図である。
本発明はこの物理的な環境に制限されず、サービスデータ伝送の他の型に容易に適合可能である。
図１のデコーダはアンテナ１に連結され、それ自体はデコーダのチューナー２に連結される。チューナーにより供給される信号は復調器３により復調される。
復調されたデータは補正回路４により補正され、デマルチプレクサ５に転送される。
【００１５】
後者は、例えばトムソンマルチメディアが１９９５年１２月２９日に出願したフランス国特許出願９５ １５７６７号に記載されるようなデマルチプレクサである。デマルチプレクサ５はデコーダにより支持された種々のアプリケーションの機能としてマイクロプロセッサ２３によりプログラムされたある数のフィルタを含む。図をわかりやすくするためにマイクロプロセッサ２３の最も重要な接続のみが示される。
【００１６】
デマルチプレクサにより濾波されたオーディオ又はビデオパケット又はセクションはこれらのアプリケーションのためにバッファメモリー６の所定の領域に記憶される。必要ならば情報はバッファメモリー６に記憶される前にユーザーの権利に応じてデクリプタ回路７によりまずデクリプトされる。
本実施例によればサービスデータ管理モジュールと同様にアプリケーションは符号５で示される：オーディオデコーダ１６、ビデオデコーダ１７、テレテクストデコーダ１８、アクセス制御集合体（デクリプタ７、照合器マイクロ制御器８、マイクロプロセッサカード１０に正常動作モードで連結されるマイクロプロセッサカードに対するインターフェイス９からなる）である。
【００１７】
デコーダはまた遠隔操作用の赤外線インターフェイス２４を含み、該インターフェイスは同様にマイクロプロセッサ２３に連結される。後者はメモリー１２に接続され、それはアプリケーションをランさせる常駐又はダウンロードされたプログラムと同様にオペレーティングシステムに含まれる。
切替電話ネットワーク１４に連結されたモデム１３はマイクロプロセッサによりまた制御される。
【００１８】
キャラクター発生器１５はデコーダのパラメータ又は特定のアプリケーションに関するコマンド又はグラフィックメニューの発生を許容する。このキャラクター発生器により発生されたビデオ信号はビデオデコーダ１７又はテレテキストデコーダ１８から入来し、テレビジョン２２に連結される第一のＴＶ周辺ソケット（ＳＣＡＲＴソケット）又はビデオレコーダ２１に連結される第二のＴＶ周辺ソケットに向かうビデオ信号の一つとマルチプレックスされる。マルチプレックス回路２０はマイクロプロセッサ２３により管理されている。
【００１９】
本発明はサービスデータ管理モジュールの動作に特に関係する。この場合にはこのモジュールは物理的に言ってマイクロプロセッサにより管理されたプログラムであり、概念的にはそれはオーディオ又はビデオデコーダと同じ方法でデータパケットを処理し、それに対して専用回路が用いられるアプリケーションに関する。
【００２０】
このモジュールはサービスデータ（ＭＰＥＧ及びＤＶＢテーブル及びセクション）とクライアントアプリケーション（プログラムガイド、遠隔購買、対話的ゲーム、等々）との間のインターフェイスである。それはクライアントアプリケーションからのリクエストを管理し、受信されたサービスデータの効果で内部データベースを維持する。
【００２１】
本実施例によればクライアントアプリケーションはマイクロプロセッサによりまた管理されたプログラムガイドである。
管理モジュールはクライアントアプリケーションに利用可能なある数の機能を作り、これらの機能はアプリケーションにより必要とされる情報に関するリクエストを形成するよう意図されている。
【００２２】
リクエスト機能は非同期的に動作する。リクエストが存在する場合にリクエストに対する応答はこの応答が利用可能なときに管理モジュールによりアプリケーションに対して通知される。これはリクエスト機能識別メカニズムの実施を必要とする。この目的のために識別子は発行された各リクエストに対してアプリケーションにより選択され、このリクエストと共に伝送される。この識別子は管理モジュールにより応答の通知と緊密に関係する。
【００２３】
図２の（ａ）から（ｃ）はリクエストに続く、クライアントアプリケーションとサービスデータ管理モジュールとこれらのデータのソース、即ちデマルチプレクサ／バッファメモリー／マルチプレクサ集合体との間での交換の３つの場合が示される。
図２の（ａ）は内部データベース（「キャッシュメモリー」）がクライアントアプリケーションによりリクエストされた情報を含む場合に関する。後者からのリクエストに、この情報の利用可能性の通知が続く。この場合に情報はデータベースに現れ、応答の通知は準−即時（ｑｕａｓｉ−ｉｍｍｅｄｉａｔｅ）である。この場合にデータ項目はソースへ又はそれから伝送されていない。
【００２４】
図２の（ｂ）はリクエストされた情報項目は内部データベースに現れない場合を示す。この場合にはクライアントアプリケーションからのリクエストに情報項目が一時的に利用不可能であることを通知するよう意図されたアプリケーションへの管理モジュールによる通知が続き、それからデータソースへの管理モジュールによりアドレスされたコマンドが続く。捜索後情報項目に対応するセクションがバッファメモリーに記憶されるデマルチプレックスされたデータのストリーム内に見いだされたときにソースはこれらのセクションは利用可能であることをモジュールＳＩに通知する。セクションのデータを読み取り、再フォーマットした後に管理モジュールは捜索後情報項目は利用可能であることをクライアントアプリケーションに通知する。モジュールは捜索後情報項目（セクションのデータの一部分でしかない）をクライアントアプリケーションによるその初期リクエスト中に割り当てられたバッファメモリーに書き込む。故にこの通知はこの場合に図２の（ａ）の場合より迅速には到来しない。
【００２５】
変形例によれば管理モジュールは情報項目が利用可能でない通知を受け取らない。
図２の（ｃ）は図２の（ａ）のような初期リクエストは捜索後情報項目での変化が信号として出されることを示す。この場合にはデータストリームからこの情報項目を含むデータパケットを抽出することを可能にするソースのフィルターは不作動とされる代わりに前の値に保持される。いわゆる恒久的なリクエストと称されるこの種のリクエストを以下に詳細に説明する。
【００２６】
本実施例によれば４つの型のリクエストが存在する：
（ａ）唯一のリクエスト
そのリクエストがアプリケーションにより管理モジュールへアドレスされるときに後者はその資源（フィルタ及びメモリ）をリクエストされたデータの転送の時間までにのみ利用可能にする。資源はすぐに自由にされる。
【００２７】
（ｂ）先行一回限りのリクエスト
このリクエストは一回限りのリクエストの特徴を有するが、より低い優先度を有する。管理モジュールは２つのＦＩＦＯ型のメモリーを維持し、一つは先行リクエスト用であり、他は非先行リクエスト用である。待機する先行リクエストは非先行リクエストの後に常に処理される。
【００２８】
（ｃ）恒久的リクエスト
管理モジュールの資源はリクエストされたデータのデマルチプレックス及び転送の後でも維持される。これらのデータが変化を被るときにはいつも通知がアプリケーションに伝送される。故に管理モジュールはシステム的なモニターをなし、アプリケーションがこのモニターを中断するようコマンドを送るまでそのようにする。
【００２９】
（ｄ）先行恒久的リクエスト
このリクエストは恒久的なリクエストと類似であるが、より低い優先レベルを有する。
リクエストに付加されている優先順位はこれらのリクエストに関係するデータの実際の受容の順を予め判断できないことは当然である。この順はまた各データ項目の周期性及びリクエストがこの周期に関して定式化される時点のような要因に依存する。
【００３０】
図３の（ａ）は一回限りのリクエストの状態図であり、一方で図３の（ｂ）は恒久的リクエストの状態図である。
各時間でアプリケーションはリクエストを定式化し、リクエスト型はそれに関連されなければならない。
恒久的リクエストの場合にはストリームから引き出されたデータは更にまた管理モジュールの内部データベースに記憶される。これはデータのコピーが維持されない一回限りのリクエストに続いて抽出されたデータに対する場合とは異なる。恒久的リクエストに関するデータを含むテーブル又は記述子の新たなバージョンが検出されたときに（即ちテーブルのバージョンｉｄ（ｖｅｒｓｉｏｎ＿ｉｄ）パラメータが変化したときに）このテーブル又はこの記述子の適切なデータがデータベースのデータと比較される。更新の通知はこれらのデータ項目の少なくとも一つが変更された場合のみに伝送される。テーブル又は記述子のバージョン識別子がそれがアプリケーションによりリクエストされていないデータにのみ関係する場合にさえテーブルに含まれる変更を無視して実際に変更される。このメカニズムはアプリケーションと管理モジュールとの間の冗長なデータの転送を回避する。
【００３１】
要求の型の選択はアプリケーションに任される。リクエストの型と見なされるアプリケーションの決定基準の例によれば図４はプログラムガイドスクリーンである。このスクリーンは２つの部分を含む：遠隔操作を通してコマンド機能にアクセスする下部４０及び該コマンドを用いるよう選択されたイベントのリストを含む上部４１である。イベントのそれぞれに対してプログラムガイドはタイトル、対応するサービス、開始及び終了時間を表示する。
【００３２】
上部４１はイベントのリストの一部分のみしか表示できない。他のイベントにアクセスするためにユーザーは遠隔操作の矢印のスクロールを用いる。
プログラムガイドアプリケーションが管理モジュールに対してリストのイベントに対する情報に関するリクエストをアドレスするときに最初に表示されたイベントに関するリクエストは非先行型であり、即ち優先権を有する。これは実際絶対に表示されなければならない情報である。リストの他のイベントに関するリクエストは先行型であり、非先行リクエストの後に管理モジュールにより処理される。アプリケーションは実際に対応する情報が必要であるとは限らない。何故ならばユーザーは探している特定のものが最初に表示されたイベントの中にある場合に実際にイベントをスクロールするかは明らかではないからである。しかしながらリクエストされた場合にこれらのデータの表示を加速する目的のためにそれらは予めロードされる。先行リクエストに応答するデータはデマルチプレックスされたときに管理モジュールはこの事態のこのリクエストのどれを開始するかをアプリケーションに通知する。しかしながらアプリケーションにより利用可能にされたバッファへのデータの転送はアプリケーションがこの転送をリクエストしない限り発生しない。
【００３３】
サービスデータ管理モジュールの役割の一つはデマルチプレクサのフィルターをプログラムすることである。この機能を満たし、検索後のデータに速いアクセスを許容するために本実施例によればそれがアクセスするネットワークの物理的構造のイメージを維持する。
文献ａとｂはネットワーク、バンドル、伝送されたサービス及びイベントの構成に関する情報を与える１０のテーブルを決定する。このテーブルはＰＩＤ（パケット識別データ）及びテーブル識別子（テーブルｉｄ（ｔａｂｌｅ＿ｉｄ））の特定の値により識別され、その値は該文献により決められている。各テーブルはテーブルの一の伝送から他への伝送を決めることを可能にし、このテーブルの内容は変化している。
【００３４】
バージョン識別子はまた記述子又は記述子の群のレベルで用いられ、そのようにテーブルの記述子と並列して用いられる。
ここで注目すべきテーブルはいわゆるＮＩＴテーブル（ネットワーク情報テーブルを表す）である。ＮＩＴテーブルは特に伝送チャンネル（伝送ストリーム）毎に利用可能なサービスのリストである所定の伝送ネットワークに関する情報を含む。
【００３５】
データ管理モジュールはネットワーク、チャンネル、利用可能なサービスの内部インデックス化を構成する。デコーダがスイッチオンされ、又はＮＩＴテーブルが更新されるときに論理キーが各利用可能なサービスに割り当てられる。このキーはモジュールにより維持されるデータベース内のこのサービスのインデックスである。
【００３６】
ＤＶＢシステムではサービスは以下の変数からなる路により一義的に配置される：
−ネットワークｉｄ（ｎｅｔｗｏｒｋ＿ｉｄ）（ネットワークの識別子）、
−（転送ストリームｉｄ（ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ）；元のネットワークｉｄ（ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ））の対、
−サービスｉｄ（ｓｅｒｖｉｃｅ＿ｉｄ）（サービス専用の識別子）
３つの変数は１６ビットでコードされる自然数である。
【００３７】
リストの３つの型は形成される：ネットワーク用の一つのリスト、各ネットワーク用のチャンネルの一つのリスト、各チャンネル用のサービスの一つのリストである。
ネットワークのリスト内の要素は各時間に形成され、新たなネットワークを含むＮＩＴテーブルはデマルチプレックスされる。これをなすためにＰＩＤが０ｘ００１０に等しい転送パケットが濾波される。これらのパケットは実際可変なテーブルｉｄにより付加的に識別されるＮＩＴテーブルを含む。４ビットコードは対応するテーブルのデマルチプレックスのオーダーで各ネットワークと関連する。コードはこのネットワークに関連する情報オペレーティング含む構造のアドレスポインタのインデックスである。
【００３８】
ＮＩＴテーブルは各チャンネルに対する利用可能なサービスのリストと同様にこのネットワークに対するチャンネルのリストを含む。
ネットワークのリストの各ネットワークに対してチャンネルのリストが形成される。チャンネルのリストの各要素は５ビットの助けでインデックス化される。リストは各チャンネルに対して特徴的なデータを含む構造のアドレスポインタを含む。データベース内でチャンネルを識別する論理キーはネットワークの４つのインデックスビットからなり、このネットワークのチャンネルのインデックスの５ビットが続く。
【００３９】
各チャンネルに対してサービスのリストが形成され、ＮＩＴテーブルに記載されるサービスの識別子を含む。リスト内の各サービスは７ビットでインデックス化される。故にデータベース内のサービスの論理キーは全部で１６ビットを含む：４つのインデックスビット、５つのチャンネルビット、７つのサービスビット。
【００４０】
このイベント（テーブルの可変イベントｉｄ（ｖａｒｉａｂｌｅ＿ｅｖｅｎｔ＿ｉｄ））を表す１６ビットの助けにより識別され、これに対して関係するサービスの論理キーの１６ビットが付加される。
データベースの構造（イベント以外の）は以下の構造により構成される：
【００４１】
【表１】

【００４２】
その名前が「アドレス」という語を含む変数はデータ構造の開始に対応するメモリー領域に対するポインタである。
他の変数はデータストリームから抽出される情報に対応する。理解を容易にするためにこれらの変数は後に括弧に入れられ、文献（ａ）で用いられている名前によりクオーテーションマークの間に入れられている。
【００４３】
チャンネル及びサービスのネットワークのリストはそれぞれ配列として構成され、各配列は一方でネットワーク、チャンネル、又はサービス型のデータ構造に対する８つのポインタからなり、他方でリストの残りに含まれる可能な配列に対するポインタからなる。後者のポインタは他の配列がないときは、即ち配列がリストの最終要素を含むときにヌルである。
【００４４】
データベース配列はネットワークのリストの第一の部分を含む配列に対するポインタを含む。
ネットワークリスト配列は最初の８つのネットワークに対するポインタを含む。本実施例によればネットワークの完全なリストを含む多くとも２つのネットワークリスト配列が存在する。
【００４５】
ネットワーク配列はこのネットワークに関連したチャンネルのリストに対するポインタと同様に与えられたネットワークに関する情報を含む。
他の配列の構造は上記のものと類似している。それは更にまたイベント及びデータの他の型に容易に拡張できる。
変形実施例によればチャンネル及びサービスのネットワークの構造に関するデータに関係するリクエストは恒久的な型のリクエストであり、これはデータベース内のネットワークのイメージを定期的に更新するよう保つ目的のためである。
【００４６】
それらの管理モジュールでの交換ではアプリケーションは論理キーのみしか使用できない。これらはモジュールにより情報が記憶されているサイトに対応するメモリーアドレスに翻訳される。
図５は２つのチャンネルを含み、各チャンネルはそれ自体２つのサービスを含むネットワークの存在する場合での管理モジュールのデータベースの図である。
【００４７】
アプリケーションのリクエストのテーブルはアプリケーションにより現在定式化されているリクエストのリストを与える。この例によれば現在のリクエストのみがネットワーク上に存在するサービスのリストを引き出すよう意図された恒久型のリクエストである。
管理モジュールのリクエストのテーブルはアプリケーションのリクエストに応答するプリミティブリクエストを含む。この文脈ではプリミティブリクエストはデマルチプレクサレベルで単一のフィルターに変換されるリクエストである。この場合には２つのチャンネルがネットワーク内に存在することが与えられ、２つのプリミティブリクエストがアプリケーションのリクエストに変換されることが必要である：一つのサービスのリスト当たり又はそうでなければチャンネル当たり一つの第一のリクエストである。
【００４８】
図では各プリミティブリクエストに対応するフィルターは管理モジュールのリクエストのテーブルの左に見いだされる。
図５に示される時点でサービスリストは最初に収集されることが仮定される。
アプリケーションのリクエストは恒久的な性格を与えられるのでこのリクエストに関係するデータベースの内容と同様に対応するフィルターも維持される。
【００４９】
リストと連結するブランチ及びこのリスト内の要素を識別するディジットはリスト内のこの要素のインデックス（論理キー）に対応する。
次にアプリケーションはネットワーク内で現在のイベントのリストを得るよう検索される。サービスにつき現在のイベントが一つ存在する；このために対応する”ＥＩＴ Ｐｒｅｓｅｔ／Ｆｏｌｌｏｗｉｇ”テーブル（”Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ”）をフィルターする必要が生ずる。
【００５０】
アプリケーションにより発行されたリクエストは所定のサービスに対して以下のパラメータを含む：
−リクエスト識別子、
−リクエストの型、
−関連するサービスの論理キー、
−イベント記述子のどのデータがベースに記憶されているかを示す一組のフラグ、
−一方でイベントの開始時間、その持続時間、アクセス制御に関する情報の項目、イベントの名前、他方でフラグにより識別されるデータの記憶が開始されるアドレスに対するアドレスポインタを含むよう意図されたデータ構造。
【００５１】
この例によれば現在第一のチャンネル（ＴＳ＿ｉｄ＝７）にあるイベントに関するリクエストが非先行であり、他方で現在第二のチャンネル（ＴＳ＿ｉｄ＝９）にあるイベントに関するリクエストが先行である。これは例えば２つのイベントのみが同時に表示可能であり、サービス１（Ｓｅｒｖｉｃｅ＿ｉｄ＝１）及び３（Ｓｅｒｖｉｃｅ＿ｉｄ＝３）のイベントが最初にスクリーンに表示される場合である。
【００５２】
現在のイベントに関しての特徴（ｐａｒｔｉｃｕｌａｒ）を得るためにアプリケーションは既にプリミティブリクエストである４つの異なるリクエストを開始しなくてはならない。これらのリクエストが恒久ではないものに続くことが仮定されている。続いてイベントに関係するデータはいったんそれらがクライアントアプリケーションに転送されてしまってから、内部データベースに記憶されない。
【００５３】
管理モジュールはプリミティブリクエストを見直し、優先的に非先行リクエストを処理する。
アプリケーションにより伝送された論理キーはそれぞれ以下のようになる：
【００５４】
【表２】

【００５５】
ここで最初のデジットはネットワークを表し、第二は（チャンネル、元のネットワーク）の対を、第三はサービスを表す。
管理モジュールにより維持されたリストのために実際の識別子はデマルチプレクサに送られ、最初の２つのリクエストに優先権が与えられる。ＥＩＴ＿ｐｒｅｓｅｎｔ＿ｆｏｌｌｏｗｉｎｇテーブル（ｔａｂｌｅ＿ｉｄ＝０ｘ４Ｅ）の識別子と同様にＥＩＴテーブル（ＰＩＤ＝０ｘ００１２）のＰＩＤの値は文献（ａ）により決定され、リクエスト機能によりインデックスされたルックアップテーブルを介してアクセス可能である。
【００５６】
この情報の助けによりデマルチプレクサのフィルターの一つはプログラムされる。
変形例によればメモリーの不足の場合には恒久的先行リクエストに対応する少なくとも幾つかの記憶されたデータは消去される。
変形例によれば現在のリクエストの型は変化されうる。考えられる特定の例は非先行恒久型のリクエストを先行恒久型のリクエストに変更することからなる。
そのような変更に対する特定の機能はクライアントアプリケーションに対して利用可能である。
【００５７】
変形例によれば管理モジュールそれ自体はネットワークの構造に関してあるリクエストを発生し（特にネットワークのリスト及びチャンネルの関連するリスト）、それらを恒久的な方法で維持する。
本発明は衛星、ラジオ、又はケーブルによるデータの伝送にのみ限定されず、データ又はデータパケットがデータストリーム内に周期的に現れるどのようなシステムにも用いられ得る。
【００５８】
これは記録され、読み返されるデータストリームに対する場合に特にそうである。
【図面の簡単な説明】
【図１】本発明の実施例を実施するテレビジョン受信機のブロック図である。
【図２】本発明の実施例によりアプリケーションとデータ管理モジュールとデータソースとの間で生ずる交換のタイムチャートを示す。
【図３】（ａ）は一回限りの、（ｂ）は恒久的なリクエストの動作を示す状態図である。
【図４】アプリケーションのスクリーン、即ち本発明の実施例による電子プログラムガイドを示す図である。
【図５】管理モジュールにより維持されるデータベースのチャートを示す。
【符号の説明】
１ アンテナ
２ チューナー
３ 復調器
４ 補正回路
５ デマルチプレクサ
６ バッファメモリー
７ デクリプタ
８ 照合器マイクロ制御器
１０ マイクロプロセッサカード
９ インターフェイス
１２ メモリー
１４ 電話ネットワーク
１３ モデム
１５ キャラクター発生器
１７ ビデオデコーダ
１８ テレテクストデコーダ
１６ オーディオデコーダ
２４ 遠隔操作
２２ テレビジョン
２１ ビデオレコーダ
２３ マイクロプロセッサ

Claims (9)

1. 少なくとも一つの送信機を含むサイクリックパケットデータ伝送システムにおける受信機であって、
   − 該データパケットをデマルチプレックスし、濾波する手段と、
   − 濾波により抽出されたパケットのデータ構造から選択されたデータからデータベースに記憶し、該データ構造はバージョンパラメータにより参照される手段と、
   − 該バージョンパラメータの新たな値を検出することを含み、データベースに現れるデータを含むデータ構造の更新を検出する手段と、
   − データ構造の更新を検出した場合にはデータベースに記憶されたデータと該更新されたデータ構造の対応するデータとを比較し、差が存在する場合にのみこの差をクライアントのアプリケーションに知らせる手段とを含むことを特徴とする受信機。
2. デマルチプレックスし、濾波する手段はクライアントのアプリケーションからのリクエストに従ってプログラムされることを特徴とする請求項１記載の受信機。
3. クライアントのアプリケーションは電子的プログラムガイド型のアプリケーションを有することを特徴とする請求項１又は２記載の受信機。
4. アプリケーションは各リクエストに対する優先レベルを決定し、デマルチプレックスし、濾波する手段及び記憶手段の資源は最高の優先レベルを有するリクエストに対して最初の時点で予約されることを特徴とする請求項２記載の受信機。
5. 先行優先レベルと非先行優先レベルが設定され、非先行優先レベルは先行優先レベルよりも高いことを特徴とする請求項４記載の受信機。
6. 非先行優先レベルはそのアプリケーションによる使用が確実であるリクエストに関連したデータに割り当てられ、他方で先行優先レベルはそのアプリケーションによる使用が有望であるが確実ではないリクエストに関連したデータに割り当てられることを特徴とする請求項５記載の受信機。
7. 非先行優先レベルはできるだけ早く表示されるリクエストに関連したデータに割り当てられることを特徴とする請求項５又は６記載の受信機。
8. アプリケーションはリクエストが恒久的なものか又は一回限りのものかを決定し、恒久的な型のリクエストは恒久的なリクエストが由来するアプリケーションから逆のインストラクションがあるまでデマルチプレックスし、濾波する手段のプログラミングのレベルで維持され、他方で一回限りの型のリクエストは対応するデータパケットを得た後にデマルチプレックスし、濾波する手段のプログラミングのレベルで消去されることを特徴とする請求項２乃至７のうちのいずれか一項記載の受信機。
9. 記憶手段に記憶されたデータは恒久的なリクエストに対応するデータであることを特徴とする請求項８記載の受信機。

Images