JP4111255B2 - デジタルテレビジョンシステムにおけるサービス情報を管理するための方法及び受信機 - Google Patents
デジタルテレビジョンシステムにおけるサービス情報を管理するための方法及び受信機 Download PDFInfo
- Publication number
- JP4111255B2 JP4111255B2 JP34164798A JP34164798A JP4111255B2 JP 4111255 B2 JP4111255 B2 JP 4111255B2 JP 34164798 A JP34164798 A JP 34164798A JP 34164798 A JP34164798 A JP 34164798A JP 4111255 B2 JP4111255 B2 JP 4111255B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- request
- information item
- database
- updated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
- H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/426—Internal components of the client ; Characteristics thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
- H04N21/4332—Content storage operation, e.g. storage operation in response to a pause request, caching operations by placing content in organized collections, e.g. local EPG data repository
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
- H04N21/4335—Housekeeping operations, e.g. prioritizing content for deletion because of storage space restrictions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/765—Interface circuits between an apparatus for recording and another apparatus
- H04N5/775—Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television receiver
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/08—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division
- H04N7/087—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division with signal insertion during the vertical blanking interval only
- H04N7/088—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division with signal insertion during the vertical blanking interval only the inserted signal being digital
- H04N7/0887—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division with signal insertion during the vertical blanking interval only the inserted signal being digital for the transmission of programme or channel identifying signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
Description
【０００１】
【発明の属する技術分野】
本発明はデジタルテレビジョンシステムにおけるサービス情報を管理すためのプロセスに関し、特に、プログラムガイドに関係する情報に関する。
本発明はとりわけデジタルテレビジョンデコーダに適用される。
【０００２】
【従来の技術】
電子プログラムガイド（又はＥＰＧｓ）は、デジタルテレビジョンシステムの中で用いられるソフトウェアアプリケーションである。これらのアプリケーションは、視聴者が典型的にはプログラム放送に関係する情報を調べ得る、インタフェースを視聴者に与える。
【０００３】
その情報は、デジタルデータストリームにおける多重に適したデータパケットにより伝送される。この種のデータにしばしば用いられる名前は”サービス情報”（もしくは単に”ＳＩ”）である。
サービス情報は、周期的に放送され、その周期は特に、可能なパスバンド及び情報へのユーザ要求の頻度に基き選択される。なぜならば、ユーザが多量のプログラムに関連する情報を迅速に見たい場合、その情報へのユーザ要求とこの要求への応答との間の待ち時間は可能な限り短いことが望ましいからである。一つの手段は、ユーザ要求に迅速に応答するための可能な限り多くの情報を保持するために多量のメモリを受信機又は送信機にそれぞれ備えることからなる。放送される全情報量は非常に多いため、この解決策は、少なくとも半導体メモリの現在の価格では、一般大衆向けのマス製品としては実現可能でない。更に、情報の項目がコンスタントに変わるという事実があるため、受信機又は送信機は、情報の更新のために、それが続けて使われるかどうかにかかわらず、その資源のかなりの部分の使用を強いられることになる。特に、同時にプログラムされ実装され得るデータパケットの多重分離フィルタの数が制限される。
【０００４】
出願人の名において１９９６年８月９日に提出された２つのフランス特許明細書ＦＲ ９６ １００６７及びＦＲ ９６ １００６８は、受信機におけるサービス情報を管理するためのモジュールに関し、特に、デジタルテレビジョンデコーダに関する。出願ＦＲ ９６ １００６７は、テレビジョン受信機、及び、受信機における内部ダイナミックデータベースに保持されたある種のデータの更新を管理するためのプロセスに関し、出願ＦＲ ９６ １００６８は、その内部データベースにおいて、デジタルストリームから受信、抽出されたデータをインデックスするためのプロセスに関する。ヨーロッパ、米国、日本及び中国を指定した出願ＷＯ９８／０９４３０は、出願ＦＲ ９６ １００６８を基礎とする優先権を主張している。ＦＲ ９６００６７の優先権主張出願は、ヨーロッパ（公開番号０８２３７９８）、中国（公開番号１１７５８２６Ａ）、米国（出願０８／９０６５９７）、インドネシア（出願Ｐ−９７２７７４）及び日本（公開番号９８５０８／９８）に提出されている。
【０００５】
これら２つの特許はまた、プログラムガイドのようなアプリケーションが、ＳＩデータを管理するためのモジュールから情報のこの項目又はその項目を要求するために発出し得る要求を説明している。そのモジュールは多重分離装置をプログラムしている。その要求は、パーマネント又はｏｎｅ- ｏｆｆ要求、予期又は非予期である。
【０００６】
これら２発明によれば、パーマネント要求に相当するデータは、そのパーマネント要求のデプログラミング（deprogramming ）まで、内部データベースに保持され、ｏｎｅ- ｏｆｆ要求に続き抽出されたデータは、即座の処理以上にはメモリに保持されない。
ユーザがプログラムガイドを介してステップをたどる場合、最近削除されたデータは再び抽出され得ることが可能である。
【０００７】
【発明が解決しようとする課題】
本発明は、上記のような場合におけるシステムの反応性を増加させることを提案している。
【０００８】
【課題を解決するための手段】
本発明の主題は、デジタルテレビジョンシステムにおいてサービス情報を管理するためのプロセスであり、そのシステムの受信機に関し、次のステップからなる。
- デジタルデータストリームから選択的に情報を抽出するための手段（５）をプログラミングし、
- 抽出された情報のうち少なくともいくつかを保持し、
- 保持された情報項目を、上記選択的抽出手段の、この情報項目に関連しているプログラミングにより、更新されたものとして又は更新されていないものとしてマーキングする。
【０００９】
ストリームからの情報項目の選択的抽出手段がデプログラムされる時、事前に受信機の内部データベースに保持された情報は、そのデータベースに保たれるが、更新なしとしてマークされる。
それゆえ、一方では、ユーザがステップをたどる場合、新たな抽出を待つ必要無く非常に迅速にこの非更新情報をユーザに供給することができる。受信機のメモリはそれにより忙しい状態になるが、メモリが飽和したら、更新されていないデータを削除することは簡単にできる。
【００１０】
本発明の特定の実施形態によれば、アプリケーションによる情報項目の抽出の要求の作成に続き、プログラミング及び格納のステップは次のように実行される、
- 要求された情報項目がデータベースに有る場合、データストリームからの情報項目抽出に続き、アプリケーションにその情報項目を転送し、データストリームからの情報項目の選択的抽出手段をプログラムし、データベースにおける情報項目を更新し、
- 要求された情報項目がデータベースにない場合、データストリームからの抽出に続き、選択的抽出手段をプログラムし、デコーダのデータベースに情報項目を格納する。
【００１１】
それゆえ、情報項目は、データベースに有る場合、要求を行なったアプリケーションに待ち時間無く転送される。これは、特に、アプリケーションによる最近の要求に従い格納された場合、例えば、ユーザがプログラムガイドを介してステップをたどる場合である。そのように格納された情報項目はまだ現在のものであるか、又は少なくともユーザを満足させる高い可能性がある。
【００１２】
データストリームにおいて情報項目を検索し、及びこの情報項目を格納するためのリソースは、アプリケーションにより要求された情報項目を検索し更新するためだけに使用され、見境無く情報を格納し更新するために使用されるものではない。
特定の実施例によれば、検索手段は多重分離装置からなる。
【００１３】
特定の実施例によれば、格納された情報項目を更新されたものとしてマークすることは、その項目の抽出に続く期間を通して有効であり、その期間、検索手段はそこから新たな値を抽出するようにプログラムされる。一度、１つの項目が抽出され、また、それを抽出するためのフィルタがアクティブである限り、その項目は更新されたものと考えられる。また、ストリームにおいて変わっていないバージョン番号が捕らえられる場合も、更新されたものと考えられ得る。
【００１４】
特定の実施例によれば、ストリームからの抽出に続き、格納された情報項目を更新されていないものとしてマークすることは、この情報項目の検索手段のデプログラミングと同時に実行される。
特定の実施例によれば、情報項目を更新されていないものとしてマークすることは、この情報項目を、その情報項目に対する選択的抽出手段がデプログラムされた日付と関連させることからなる。
【００１５】
この特徴は、情報項目の最後の更新から経過した時間を決定することを可能とする。これにより、特に伝送の周期性が知られている場合に、情報項目が陳腐化したかどうかを判断することが可能となる。
特定の実施例によれば、受信機のデータベースが飽和した場合、更新されていないものとしてマークされた情報は、日付の古さの順に削除される。
【００１６】
変形の実施例によれば、情報項目のマーキングは、この情報項目とともに、その情報項目を要求したアプリケーションに伝えられる。
それゆえ、アプリケーションは、マーキングの状態に応じて、この情報項目からなる使用を決定することができる。
変形の実施例によれば、受信機のデータベースが飽和すると、更新されていないとしてマークされた情報は日付の古い順で削除される。
【００１７】
変形の実施例によれば、アプリケーションにより、スクリーンに表示された更新されていない情報項目は、更新されていないものとしてビジュアルに識別される。
それゆえ、ユーザは情報項目の状態、及び、もしかしたら陳腐化しているかもしれないリスクに対して警告を受ける。
【００１８】
本発明の主題はまた、サービス情報及び、特にプログラムガイド情報が伝送されるデジタルテレビジョンシステムにおける受信機であり、上記受信機は、
データストリーム多重分離装置からなり、その多重分離装置は、上記ストリームから情報を選択的に抽出するためのプログラム可能なフィルタからなり、上記受信機は、
- 前に抽出された情報からなる上記受信機のデータベースを含むためのメモリと、
- データベースの情報を更新又は更新なしとしてマークする手段と
からなる。
【００１９】
変形の実施例によれば、更新又は更新なしとしてマークすることは、上記多重装置のプログラミングの機能として実行される。
変形の実施例によれば、そのデバイスは更に、更新なし情報をマークするために使用されるクロックからなる。
【００２０】
【発明の実施の形態】
本発明の他の特徴および利点は、限定しない実施例の説明を通して明らかになる。この実施例は添付の図に描かれている。
ＭＰＥＧ及びＤＶＢサービスデータ、セグメント及びテーブルのフォーマットと内容に関する更なる情報のために、特に次の３つの文献を参照として挙げる。
【００２１】
（ａ）ＥＴＳ ３００ ４６８ − デジタルビデオ放送（ＤＶＢ）システムにおけるサービス情報（ＳＩ）のための仕様- １９９６年１月２３日。
（ｂ）ＩＳＯ／ＩＥＣ １３８１８−１ （１９９４）動画及び関連する音声の一般的なコーディング - 勧告Ｈ．２２０であり”ＭＰＥＧ II Ｓｙｓｔｅｍｓ”とも呼ばれる。及び、
（ｃ）ＥＴＲ２１１ - テレビジョンのためのデジタル放送システム： ＭＰＥＧ２システムの使用のための実装ガイドライン；サービス情報の実装と使用に関するガイドライン。
【００２２】
図１は、ＤＶＢタイプ（デジタルビデオ放送）のデジタルテレビジョンのための統合されたデコーダ／受信機の図である。
本発明は、この物理的環境に限定されず、サービスデータの伝送のいくつかの他の種類、例えばフレーム帰線間における変調データを介する伝送、に容易に適用され得ることは明らかである。
【００２３】
図１のデコーダは、アンテナ１に接続され、アンテナはデコーダのチューナ２に接続されている。チューナにより伝達される信号は、復調器３により復調される。復調されたデータは、訂正回路４により訂正され、多重分離装置５に転送される。
後者は、例えば、ＴＨＯＭＳＯＮ ＭＵＬＴＩＭＥＤＩＡの名前で１９９５年１２月２９日に提出されたフランス特許出願９５ １５７６７に説明されているものと同様な多重分離装置である。多重分離装置５は、デコーダによりサポートされる種々のアプリケーションの機能としてマイクロプロセッサ２３によりプログラムされる数多くの、機能拡張によるフィルタと呼ばれるフィルタリングレジスタからなる。多重分離装置はフィルタリングレジスタの内容をデータパケットのあるパラメータと比較し、肯定的な比較に対するデータパケットをロードする。
【００２４】
図を明確にするために、マイクロプロセッサ２３の最も重要な接続のみが記述されている。
多重分離装置によりフィルタされた音声又はビデオのパケット又はセグメントは、アプリケーションを待つバッファメモリ６の所定のエリアに格納される。必要であれば、このバッファメモリ６に格納される前に、ユーザの権利の関数として、その情報は最初に復号化回路７により復号化される。
【００２５】
本実施例によれば、５つのアプリケーションがある。すなわち、音声デコーダ１６、ビデオデコーダ１７、テレテキストデコーダ１８、アクセス制御アセンブリ（復号器７、チェックするためのマイクロコントローラ８、及び、通常のオペレーティングモードにおいて、マイクロプロセッサカード１０に接続されたマイクロプロセッサカードのためのインターフェース９からなる。）、また、サービスデータ管理モジュールの５つである。
【００２６】
デコーダはまた、リモートコントロールのための赤外線インタフェース２４からなり、そのインタフェースはまたマイクロプロセッサ２３と接続している。後者は、アプリケーションを実装するための常駐又はダウンロードされたプログラムとともにオペレーティングプログラムを含むメモリ１２に接続している。
交換電話網１４と接続されたモデム１３はまた、マイクロプロセッサにより制御される。
【００２７】
文字生成器１５により、デコーダのパラメータ又は特定のアプリケーションに関係するコマンドメニュー又はグラフィックスの生成を行なう。この文字生成器により生成されたビデオ信号は、ビデオデコーダ１７又はテレテキストデコーダ１８から発生したビデオ信号の１つと共に多重化され、テレビジョン２２と接続された第１のＳＣＡＲＴソケット、又はビデオデコーダ２１と接続された第２のＳＣＡＲＴソケットに向かう。
【００２８】
本実施例によれば、サービスデータ管理モジュールは、概念的には、専用回線が使用され、音声又はビデオデコーダの方法で、データパケットを処理するアプリケーションであるにもかかわらず、物理的には、マイクロプロセッサにより管理されているプログラムである。
そのモジュールは、サービスデータ（ＭＰＥＧ及びＤＶＢテーブル及びセグメント）及びカスタマアプリケーション（プログラムガイド、遠隔購買、インタラクティブゲーム等）である。それはカスタマアプリケーションからの要求を管理し、受信したサービスデータの内部データベースを維持する。
【００２９】
本実施例によれば、カスタマアプリケーションは、マイクロプロセッサによってもまた管理されるプログラムガイドである。
アプリケーションにより必要とされる情報に関係する要求を作成するための多数の機能が、管理モジュールによりカスタマアプリケーションに対して可能になる。
【００３０】
その要求機能は非同期に動作する。応答がある場合、要求へのその応答は、この応答が可能な時に、管理モジュールによりアプリケーションに通知される。これは、要求機能識別メカニズムの実装を必要とする。この目的のために、識別子が、発出される各要求のためにアプリケーションにより選択され、この要求とともに伝送される。この識別子は管理モジュールにより、応答の通知と結び付けられる。
【００３１】
図２ａから２ｃは、要求に続く、カスタマアプリケーション、サービスデータ管理モジュール、及びこれらのデータのソースすなわち多重分離装置／バッファメモリ／マイクロプロセッサアセンブリ、の間の交換における３つのケースを示している。
図２ａは、内部データベース（”キャッシュメモリ”）がカスタマアプリケーションにより要求された情報項目を含むケースに関する。後者の要求に続き、この情報項目が可能かどうかの通知がある。このケースでは、情報項目がデータベースに存在するため、応答の通知はほぼ即座に行なわれる。このケースでは、多重分離装置へ、又は、多重分離装置からデータ項目は伝送されていない。アプリケーションへのデータ伝送は、管理モジュールがデータを書くバッファメモリを介して実行される。使用されるバッファメモリのエリアはアプリケーションの要求の中で識別される。アプリケーションは、一度通知がなされると、順当にそこからデータを読む。このケースについて、詳細は後述する。
【００３２】
図２ｂは、要求された情報項目が内部データベースにないケースを示している。このケースでは、カスタマアプリケーションの要求に同様にして続き、情報項目が一時的に可能でないことを知らせるための通知が管理モジュールからアプリケーションになされ、そして、管理モジュールにより多重分離装置へコマンドが通知される。求められている情報項目に相当するセグメント又は複数のセグメントがデータストリームから見つかると、多重分離され、バッファメモリに格納され、多重分離装置はＳＩ管理モジュールに、これらのセグメントが可能であることを通知する。そのセグメントのデータの読み込み、及び再フォーマットの後、管理モジュールが今度は、求めている情報項目が可能であることをカスタマアプリケーションに通知する。前のケースのように、そのモジュールは、求めている情報項目（セグメントからのデータのちょうどいくつかであり得る）を、カスタマアプリケーションにより最初の要求の間に割り当てられたバッファメモリに書き込む。それゆえに、このケースでは、この通知はケース２ａより遅く到着する。
【００３３】
図２ｃは、図２ａに示すような最初の要求は、求められている情報における変更が合図されるべきであることを明白に示しているケースを示している。このケースでは、この情報項目を含むデータパケットがデータストリームから抽出されるようにした多重分離装置のフィルタは、非活性化される替わりに前の値に保たれる。この種の要求は、パーマネント要求と呼ばれ、詳細は後述する。
【００３４】
本実施例によれば、４種類の要求がある。
（ａ）Ｏｎｅ−ｏｆｆ要求
そのような要求がアプリケーションにより管理モジュールに送られると、後者は、そのリソース（フィルタ及びメモリ）を、要求されたデータがアプリケーションに伝送される時までのみ使用可能とする。そのリソースは原則として即座に開放される。
【００３５】
（ｂ）予期されたｏｎｅ−ｏｆｆ要求
この要求は、ｏｎｅ−ｏｆｆ要求の特徴を有しているが、優先度はｏｎｅ−ｏｆｆ要求より小さい。この管理モジュールは２つのＦＩＦＯタイプのメモリを保持し、１つは予期された要求のためであり、もう１つは予期されない要求のためのものである。待っている予期された要求は、いつも予期されない要求の後に処理される。
【００３６】
（ｃ）パーマネント要求
管理モジュールのリソースは、要求されたデータが多重分離され伝送された後でも、管理モジュールのリソースは維持される。これらのデータにおいて変更が発生するといつでも、通知がアプリケーションに送られる。管理モジュールは、それゆえ、システマチックなモニタリングを、アプリケーションがこのモニタリングを中断するコマンドを送るまで、実行する。
【００３７】
（ｄ）予期されたパーマネント要求
この要求はパーマネント要求と同様であるが、優先レベルはパーマネント要求よりも低い。
要求の優先度は、言うまでもなく、これらの要求に関係しているデータが実際に受信される順番を事前に判断しない。この順番はまた、各データ項目の周期及びこの周期を基準として要求が示される時点等の要因にも依存する。
【００３８】
図３ａは、ｏｎｅ−ｏｆｆ要求の状態図であり、図３ｂはパーマネント要求の状態図である。
アプリケーションが要求を生成するときはいつでも、要求タイプが関係付けられていなければならない。
パーマネント要求のケースにおいて、ストリームから取得されたデータは管理モジュールにおける内部データベースに追加される。これは、ｏｎｅ−ｏｆｆ要求に続き抽出されたデータの場合はそうではなく、データのコピーは保持されない。パーマネント要求に関係するデータを含むテーブルの新しいバージョンが捕捉されると、このテーブルからの適切なデータはデータベースにおけるデータと比較される。バージョンの変更は、各テーブルとともに伝送される”version ＿id" 又は"version＿number" と記述されるパラメータの値の変更により示される。更新の通知は、少なくともこれらのデータのうちの１つが変更されなければ、事前に伝送されない。テーブルのバージョン識別子”version ＿id" は、アプリケーションにより要求されていないデータにのみ関係している場合でも、実際にテーブルに発生する変更にかかわらず変更される。このメカニズムは、アプリケーション及び管理モジュール間の冗長データの伝送を回避する。
【００３９】
更に、アプリケーション要求は、基本要求から区別される。アプリケーション要求は、その名前が示すように、カスタマアプリケーションにより発出される。アプリケーション要求は、ＳＩ管理モジュールにより翻訳され、必要なだけの数の基本要求になる。この状況では、基本要求は多重分離装置レベルにおいて単一のフィルタに翻訳され得るものである。基本要求は、それらが関連するデータが重なり合わないような方法で決定される。
【００４０】
要求の２つのテーブルは、ＳＩモジュールにより保持される。それらは、アプリケーション要求のテーブル及び基本要求のテーブルである。
【００４１】
【表１】
【００４２】
アプリケーション要求のテーブル
【００４３】
【表２】
【００４４】
基本要求のテーブル
アプリケーション要求のテーブルは、各要求のための次の要素からなる。
- Request identifier 要求識別子
- Type 要求の種類（予期されたｏｎｅ−ｏｆｆ、予期されないｏｎｅ−ｏｆｆ … ）
- Function 要求の関数
- ‘Wait‘、これは、対応する待ちの基本要求の数であり、すなわち、まだ応答を引き起こしていない基本要求の数である。（要求を発出したアプリケーションへの最初の通知は、この数字がゼロに等しい時に送られる）
- ‘SingNB‘、これは、バッファメモリへのデータ伝送をまだ引き起こしていない基本要求の数である。
【００４５】
- ‘SList ‘、これは、このアプリケーション要求と関連した基本要求の識別子のリストである。
- Parameters アプリケーション要求と結びついたパラメータ（例えば、事象のリストが探索されているサービスの識別である）
基本要求のテーブルは各基本要求のための次の要素からなる。
【００４６】
- Request identifier 要求のための識別子
- Type 要求の種類
- Function 要求の関数
− State 要求の状態
- Number of applicationrequests 基本要求と結びついたアプリケーション要求の数
- Date 要求の非活性化の日付け（妥当ならば）
- Parameters 基本要求と結びついたパラメータ
ＳＩ管理モジュールがアプリケーション要求を基本要求又は複数の要求に翻訳するとき、それは、基本要求のテーブルがすでにこれらの要求を含むかどうかをチェックする。新たな基本要求は、同一の要求が既に存在する場合のみ対応するテーブルに挿入される。これにより、多重分離装置のリソースを冗長に使用することを回避することが可能となる。
【００４７】
２つの基本要求は、それらが同一の関数及び同一のパラメータを有していれば同一と見なされる。基本要求が既に対応するテーブルに存在すれば、ＳＩモジュールは既に存在する基本要求の種類をチェックする。もし、この種類が新たな基本要求の種類よりも優先度が低ければ（これは、この新しい基本要求を引き起こしたアプリケーション要求の種類である）、存在する基本要求の種類は、新しい値をとるように変更される。要求タイプの最低から最高の優先度の区分は、予期されたｏｎｅ−ｏｆｆ、予期されたパーマネント、予期されないｏｎｅ−ｏｆｆ、予期されないパーマネントである。
【００４８】
アプリケーション要求のテーブルの次の要素は、対応する基本要求のプログラミング又は変更に続き更新される。それらは、Ｗａｉｔ、ＳＬｉｓｔである。基本要求のテーブルの内容とのリンクはこのようにして確立される。
基本要求のテーブルはまた、他の役割を持っている。すなわち、データベースにデータ項目があるかどうか、また、このデータ項目が最新のものであるかどうかを決定する可能性を提供する。
【００４９】
このテーブルからの要求の”State ”フィールドは次の値のうちの１つをとり得る。
- ‘Waiting ‘、要求はアクティブであるが、データがまだ受信されていないことを表す。
- ’Ready ‘、要求はアクティブであり、データはデータベースに格納されており、更新されていることを表す。
【００５０】
- ‘Non-updated ‘、要求はもはやアクティブでなく、データはデータベースに格納されているが、更新されていないことを表す。
基本要求のテーブルはまた、各基本要求毎に、関連する活性化アプリケーション要求の数を合計を出すために数える。この数は、新しいアプリケーション要求のブレークダウン又は古い要求のデプログラミングにより加算又は減算される。基本要求においてこの数が０になるとき、後者の状態は‘non-updated ‘になる（前の状態が‘Ready ‘だった場合）、すなわち、非活性である。前に抽出された日付は、もし日付があれば、データベースに格納されたままである。
【００５１】
アプリケーション要求の数が０になり、１つ又はその他の理由によりデータベースに情報を格納していない基本要求はテーブルから削除される。多重分離装置の対応するフィルタは解放される。この理由は、種々であり得る。すなわち、データが取得される前のデプログラミングが速すぎる、要求データが放送されない、等である。
【００５２】
非活性の基本要求は、適切なアプリケーション要求により再活性化され得、又は、データベースで使用されているメモリにおけるいくらかの領域を解放する必要ができ、それに対応するデータが削除される時に基本要求のテーブルから削除され得る。
要求の非活性化の日付は基本要求のテーブルに格納される。本ケースにおいては、この日付はシステムクロックの値からなり、このクロックはエンコーダのクロックと同期している。しかしながら、他の種類のクロックを採用することもまた考えられる。
【００５３】
（ｏｎｅ- ｏｆｆの、又はパーマネントタイプの）基本要求に対応するデータが多重分離されると、それらはバッファメモリに転送される。この転送は、アプリケーション要求とのリンクの数だけ発生する。関連するアプリケーション要求の各々における基本要求‘SingNB‘の数は減算される。ＳＩ管理モジュールによるアプリケーションへのデータ使用可能性の通知は、この数がこのアプリケーションにおいて０に到達した時に実行される。すなわち、アプリケーションにより発出されたアプリケーション要求とリンクした全ての基本要求が結果を与え、その結果をバッファメモリに転送した時に、上記通知は実行される。
【００５４】
対照的に、基本要求に関するデータベースにおけるデータの次の変更がある場合、この変更は、関連するアプリケーションに即座に通知される。
図５は、後述するが、特定のケースにおける２つのテーブルの例を示している。
基本的要求が‘non-updated ‘として印付けられた場合、これはデータベースにおけるデータがもはや実際に最新でないことを意味するのではなく、それらが発生した元の要求が上述した非活性化の日から決定され得る期間維持されていないとすると、そのようなことである可能性があるということを単に意味している。
【００５５】
アプリケーションへ転送する目的で管理モジュールがデータをバッファメモリへ転送する時、‘Date‘フィールド又は複数フィールド、及び‘State ‘フィールド又は複数フィールドの内容はまたそこに格納される。これらの値はこの情報の使用を決定するアプリケーションにより読まれる。状態が‘Ready ‘の時、データは最新のものである。状態が‘non-updated ‘の時、それらは最新でなく、‘Date‘ フィールドはそれらがどのくらい古いかを示している。アプリケーションがプログラムガイドであるとすると、更新されていないものとして印付けられて表示されるデータは、そのようなものとして識別するためにそのように表示される。例えば、更新された情報項目と区別されるような影付きの表示又はカラーでの表示である。
【００５６】
基本要求の状態が‘Ready ‘であるとき、データは最新である。データの転送の間、これをアプリケーションに示すために、‘Date‘フィールドの転送された値は０である。
本実施例によれば、パーマネント基本要求（予期か予期でないかにかかわらず）のみがデータベースで抽出されたデータの格納を引き起こすが、変形の実施例によれば、ｏｎｅ- ｏｆｆ要求に対応するデータを格納することもできる。このケースにおいてはまた、もちろん、対応するテーブルの中にｏｎｅ- ｏｆｆタイプの基本要求を保持する必要がある。
【００５７】
要求に続き、内部データベースにおいて更新なしのデータが読まれたにせよそうでないにせよ、多重分離装置のフィルタは、ストリームから最も最近の値を抽出する目的でプログラムされる（これがまだ行なわれていなければである）。これらの値は、一度ストリームから抽出されると、データベースに書かれ、必要であれば最も古いデータを上書きする。基本要求の状態の変更は、適切に行なわれる。すなわち、テーブルに既に存在する要求は‘Wait‘状態から‘Ready ‘状態に移り得るが、また、‘non-updated ‘状態から‘Ready ‘状態及びその逆もあり得る。抽出されるデータに対応する基本要求がない場合、それらはもちろん生成される。
【００５８】
本実施例によれば、‘version ＿id' パラメータの管理は多重分離装置のレベルで実行される。２つのタイプのフィルターが使用される。第１のタイプにおいては、取得される情報項目のバージョン番号がマスクされ（バージョン番号を問わず、捕捉された最初のバージョンが多重分離される）、第２のタイプにおいては、バージョン番号は特定の値を有する（このバージョン番号を有する情報項目のみ多重分離される）。
【００５９】
基本要求が生成され、対応するフィルタが存在しない場合、採用されるのは第１のタイプのフィルタである。一度対応する情報項目が捕捉され、抽出されると、基本要求がパーマネントタイプである場合、抽出されたバージョン番号の値は加算され存在するフィルタに追加される。上述した第２のタイプのフィルタはこのようにして生成される。情報項目の次のバージョンが捕捉されることがこのようにして確かになる。
【００６０】
データベースにバージョン番号の値を格納することはもちろん考えられる。
いくらかのメモリを解放する目的でデータベースをきれいにすることは、基本要求のテーブルの‘Date‘ フィールドに示されている日付の助けにより実行される。‘non-updated ‘状態における基本要求は、これらの要求と密接な関係があるデータと共に古い順に削除される。このクリーンアップは、データベースがいっぱいであるときに実行される。それは率先して行なわれ、また、‘non-updated ‘状態における基本要求にのみ関係している限り、ＳＩ管理モジュールの制御の下にある。‘non-updated ‘状態における要求がもはやないにもかかわらずデータベースがいっぱいであるとき、この事実はアプリケーションに通知される。更なるクリーンアップはアプリケーションの制御の下で実行され得る。
【００６１】
サービスデータ管理モジュールの役割のうちの一つは多重分離装置のフィルタをプログラムすることである。この機能を満足し、望んでいるデータに速いアクセスをさせるために、それはアクセスする先のネットワーク又は複数のネットワークの物理構造のイメージを保持している。
ドキュメント（ａ）及び（ｂ）はネットワーク又は複数ネットワーク、マルチチャネルパッケージ、サービス及び転送されたイベントの構成についての情報を与える１０のテーブルを定義する。テーブルは特定のＰＩＤ（パケット識別データ）及び特定のテーブル識別値（table ＿id) により識別され、それらの値は上記ドキュメントにより定義される。各テーブルは、このテーブルの内容がテーブルの１つの伝送から次の伝送へ変わったかどうかを決定することを可能とするバージョン識別子を含む。
【００６２】
ここで関係するテーブルは、ＮＩＴ（ネットワーク情報テーブルを意味する）と呼ばれるテーブルである。ＮＩＴテーブルは与えられた伝送ネットワークについての情報からなり、特に、伝送チャネル（又はトランスポートストリーム）毎に可能なサービスのリストからなる。
データ管理モジュールはネットワーク、チャネル及び可能なサービスの内部索引付け（ｉｎｄｅｘａｔｉｏｎ）を構成する。デコーダがセットされるか、又は、ＮＩＴテーブルが更新されるとき、論理キーが可能な各サービスに割り当てられる。このキーは、モジュールにより保持されるデータベースにおけるこのサービスのためのインデックスである。
【００６３】
ＤＶＢシステムにおいて、サービスは、次の変数からなるパスを介して重ならずに置かれ得る。
- network ＿id （ネットワーク識別子）
- (transport＿stream＿id; original＿network ＿id) ペア
- service＿id（現実のサービス識別子）
この３変数は１６ビット上でコード化された自然数である。
【００６４】
ネットワークのためのリスト、それぞれのネットワークのためのチャネルのリスト及び各チャネルのためのサービスのリストの３タイプのリストが作成される。
ネットワークのリストの要素は、新しいネットワークから構成されるＮＩＴテーブルが多重分離されるときはいつでも生成される。これを行なうために、ＰＩＤが０ｘ００１０に等しいトランスポートパケットがフィルタにかけられる。これらのパケットは実際にＮＩＴテーブルを含み、加えて、変数table ＿idにより識別される。４ビットコードは、対応するテーブルが多重分離される順に各ネットワークと関連している。そのコードは、このネットワークに関係する情報からなる構造のためのアドレスポインタのインデックスである。
【００６５】
ＮＩＴテーブルは、各チャネルにおける可能なサービスのリスト、及びこのネットワークのためのチャネルのリストからなる。
ネットワークのリストにおける各ネットワークのために、チャネルのリストが生成される。チャネルのリストの各エレメントは５ビットの助けによりインデックスされる。そのリストは、各チャネルに特別のデータからなる構造のためのアドレスポインタを含む。データベースにおけるチャネルを識別するための論理キーはネットワークのための４インデックスビットからなり、このネットワークのチャネルのインデックスの５ビットが続く。
【００６６】
各チャネルにおいて、サービスのリストが生成され、そのサービスのリストはＮＩＴテーブルにより記述されたサービスの識別子からなる。リストにおける各サービスは７ビット上でインデックスされる。それゆえ、データベースにおけるサービスの論理キーは合計１６ビットからなる。すなわち、４ネットワークインデックスビット、５チャネルインデックスビット及び７サービスインデックスビットである。
【００６７】
サービスの事象は、この事象（テーブルの変数 event ＿id) を示す１６ビットの助けにより識別され、それには関連するサービスの論理キーの１６ビットが追加される。
データベースの構造（事象を除く）は次の構造により構成される。
【００６８】
【表３】
【００６９】
【表４】
【００７０】
【表５】
【００７１】
名前に”Address"の語を含む変数は、データ構造の開始に対応するメモリエリアへのポインタである。
他の変数は、データストリームから抽出された情報に対応する。理解を助けるために、これらの変数にはドキュメント（ａ）に用いられる名前が括弧と引用符に囲まれて続く。
【００７２】
ネットワーク、チャネル及びサービスのリストはそれぞれ配列に入れられ、各配列は、一方では、ネットワーク、チャネル又はサービスタイプのデータ構造への８ポインタからなり、他方では、リストの残りを含む可能な配列へのポインタからなる。この最後のポインタは、他の配列がない場合、すなわち、配列がリストの最後の要素を含む場合には空文字である。この後者のポインタはインデックスされない。
【００７３】
配列は８要素を含み、これは２の累乗に相当する。これにより、この場合ではチャネルインデックスの最後の３ビットをマスクすることにより、要望されているポインタを含む配列を決定することが可能となる。
データベース配列は、ネットワークのリストの最初の部分を含む配列へのポインタを含む。
【００７４】
NetworksList配列は、最初の８ネットワークへのポインタを含む。本実施例によれば、ネットワークの完全なリストを含む最大で２つのNetworksList配列が存在する。
ネットワーク配列は、このネットワークに関係するチャネルのリストの最初の配列へのポインタと共に、与えられたネットワークに関係する情報を含む。
【００７５】
他の配列の構造は、ちょうど説明されたものと同様である。更に、それを事象及び他のタイプのデータに拡張することは容易である。
変形の実施例によれば、ネットワーク、チャネル及びサービスの構造に関するデータに関係する要求はパーマネントタイプの要求であり、その目的は、配列のイメージをデータベースにおいてコンスタントに最新に保つことである。
【００７６】
管理モジュールにおける交換において、アプリケーションは論理キーを使用する。これらは、そのモジュールにより、情報項目が格納される位置に対応するメモリアドレスへ翻訳される。それらは、要求のテーブルに格納されたパラメータの部分を形成する。
図５は、ネットワークが存在する場合における管理モジュールのデータベースの図であり、そのネットワークは２チャネルからなり、各チャネル自身は２サービスからなる。
【００７７】
アプリケーション要求の上述したテーブルはアプリケーションにより生成される要求のリストを与える。本実施例によれば、進行中の唯一の要求は、ネットワーク上のサービスのリストを取得することを意図するパーマネントタイプの要求である。
今回の場合では、ネットワークにおいて２チャネルがあるとすると、アプリケーション要求を翻訳するために、２つの基本要求が必要である。サービスのリスト当たり又はチャネル当たりの１つの基本要求は、基本要求のテーブルに書き込まれる。
【００７８】
同図において、各基本要求に対応するフィルタは基本要求のテーブルの左に見られる。
図５に示す瞬間においては、サービスリストは最初に入力されている。アプリケーション要求がパーマネント的とすると、この要求に関係するデータベースの内容のみならず対応するフィルタが、予期されたデータが取得された最初の機会の後に、保持される。
【００７９】
リストを結合する枝を識別する数字及びこのリストの中の要素は、リストの中のこの要素のインデックス（論理キー）に相当する。
アプリケーションは、ネットワークにおいて進行中の事象のリストを取得しようとする。サービス毎に進行中の１事象があり、これは、対応する‘Current/Next EIT ' テーブル（”事象情報テーブル”）をフィルタにかけることを必要とする。そのようなテーブルは実際に各サービスのために放送される、すなわち、サービス説明テーブルのフラグEIT ＿present ＿following ＿fragはこれらのサービスに対して値１を有する、ということを残りの説明では仮定する。
【００８０】
アプリケーションにより発出される要求は、特定のサービスにおいては、次のパラメータからなる。
- 要求識別子
- 要求のタイプ
- 関連するサービスの論理キー
- ＳＩモジュールから多重分離されたデータを受信するためのバッファメモリのメモリアドレス
そのデータベースは、進行中の事象又は次の事象に関係したデータ項目を含まない、すなわち、基本要求のテーブルはこれらのデータに関連する基本要求を含まないということを最初に仮定する。
【００８１】
プログラムガイドアプリケーションは、例えば、第１のネットワーク（”０”）の第１のチャネル（”０”）に属する第２のサービス（”１”）の現在及び次の事象を検索する。この要求は、ユーザによる、進行中のプログラムについての情報、及び特定のサービスの進行中のプログラムの直後のプログラム、例えばＣａｎａｌ＋（フランスのテレビチャネル）についての情報を表示するためのコマンドに続いて行なわれる。
【００８２】
関連するサービスの論理キーは、
００００ ０００００ ０００００１
である。
対応するアプリケーション要求はＳＩモジュールに伝送される。この要求はパーマネントタイプである。この実施例のフレームワークの中で、単一サービスの現在及び次の事象のみがアプリケーションにより要求されることとすると、この要求は基本的であり、ＳＩモジュールにより更にブレークダウンされるべきでない。基本要求は要求の対応するテーブルに書き込まれる。
【００８３】
更に、ＳＩモジュールは、この要求に関係するＥＩＴテーブルのフィルタリングが正しく実行されるように、多重分離装置のフィルタをプログラムする。ドキュメント（ａ）によれば、"Current/Next" EIT テーブルからなるパケットのＰＩＤの値は、０ｘ００１２である。放送された中でどれが現在のＥＩＴテーブルかを決定するために必要なサービス識別子("service ＿id")、チャネル識別子("transport ＿stream＿id" 及び "original＿network ＿id")の値は、論理キーによりデータベースの中で使用可能である。基本要求のテーブルにおける基本要求の状態はさらに”Wait”状態にセットされる。
【００８４】
一度、正しいＥＩＴテーブルが捕捉されると、ＳＩモジュールは、そのパケットから、内部データベースに格納されるデータの値を抽出する。本実施例によれば、これらのデータは、上述した"CurrentNextEvent"データ構造にて現れたものである。ＳＩモジュールは、要求しているアプリケーションにデータがあることを通知し、アプリケーションにより予め確保されたバッファメモリにそれらをコピーする。データベースにおいて、論理キーにより示されたパスに対応するサービスデータ構造のアドレスポインタ"CurrentNextEventAddress" は、"CurrentNextEventAddress" 構造に対応するメモリアドレスとプログラムされる。基本要求のテーブルにおける基本要求の状態は”Wait”から”Ready ”にスイッチする。
【００８５】
サービス毎に最大でも１つの現在の事象と１つの次の事象があるということに注意すべきである。したがって、この特定のケースでは、"CurrentNext Event" データ構造の構造をインデックスする理由はない。なぜならば、それが依存するサービスへ向かう論理キーにより既に十分に識別されているからである。
事象の時系列のシリーズを含むＥＩＴテーブルの内容がロードされていれば、そのケースは異なるものとなる。
【００８６】
例えば、ユーザによる、プログラムガイドを再び閉じるコマンドに続き、アプリケーションはその要求をキャンセルする。このケースにおいて、現在／次の事象に関係する基本要求を参照する進行中のアプリケーション要求がこれ以上ないとすると、ＳＩモジュールは、多重分離装置のフィルタを解放し、システムクロックの現在の値を最初の要求のテーブルの"Date"フィールドに書き込む。このケースのように、データが実際に多重分離され、事前にデータベースに格納されると仮定すると、要求の状態は”non-updated ”になる。逆のケースでは、それらは単にテーブルから削除されている。
【００８７】
変形の実施例によれば、管理モジュール自体が、ネットワークの構造（特にネットワークのリスト及びチャネルの関連するリスト）に関係するある要求を生成し、それらをパーマネント的に保持する。
本発明は、衛星、無線中継又はケーブルによるデータの伝送に限定されず、データ又はデータパケットがデータストリーム中に周期的に出現するようないかなるシステムにも実装され得る。特に、記録された、もしくは、事前に記録されたデータストリームの場合にそうである。
【００８８】
更に、ここでの実施例はサービスデータに特に関係しているが、本発明はこのタイプのデータに限定されないことは明らかである。例えば、いわゆるプライベートデータが類似の方法により処理され得る。
【図面の簡単な説明】
【図１】本実施例によるテレビジョン受信機の構成図である。
【図２】アプリケーション、データ管理モジュール及び図１に示す装置の多重分離装置間で発生する交換のタイムチャートである。
【図３】ｏｎｅ- ｏｆｆ要求（３ａ）とパーマネント要求（３ｂ）のそれぞれの動作方法を示す図である。
【図４】アプリケーションのスクリーン、すなわち電子プログラムガイドを示す図である。
【図５】特定の瞬間における、管理モジュールにより維持されているデータベースの図である。
【符号の説明】
１ アンテナ
２ チューナ
３ 復調器
４ 訂正回路
５ 多重分離装置
６ バッファメモリ
７ 復号化回路
８ マイクロコントローラ
９ インターフェース
１０ マイクロプロセッサカード
１２ メモリ
１３ モデム
１４ 交換電話網
１５ 文字生成器
１６ 音声デコーダ
１７ ビデオデコーダ
１８ テレテキストデコーダ
１９ ＳＩモジュール
２１ ビデオデコーダ
２２ テレビジョン
２３ マイクロプロセッサ
２４ 赤外線インタフェース
【発明の属する技術分野】
本発明はデジタルテレビジョンシステムにおけるサービス情報を管理すためのプロセスに関し、特に、プログラムガイドに関係する情報に関する。
本発明はとりわけデジタルテレビジョンデコーダに適用される。
【０００２】
【従来の技術】
電子プログラムガイド（又はＥＰＧｓ）は、デジタルテレビジョンシステムの中で用いられるソフトウェアアプリケーションである。これらのアプリケーションは、視聴者が典型的にはプログラム放送に関係する情報を調べ得る、インタフェースを視聴者に与える。
【０００３】
その情報は、デジタルデータストリームにおける多重に適したデータパケットにより伝送される。この種のデータにしばしば用いられる名前は”サービス情報”（もしくは単に”ＳＩ”）である。
サービス情報は、周期的に放送され、その周期は特に、可能なパスバンド及び情報へのユーザ要求の頻度に基き選択される。なぜならば、ユーザが多量のプログラムに関連する情報を迅速に見たい場合、その情報へのユーザ要求とこの要求への応答との間の待ち時間は可能な限り短いことが望ましいからである。一つの手段は、ユーザ要求に迅速に応答するための可能な限り多くの情報を保持するために多量のメモリを受信機又は送信機にそれぞれ備えることからなる。放送される全情報量は非常に多いため、この解決策は、少なくとも半導体メモリの現在の価格では、一般大衆向けのマス製品としては実現可能でない。更に、情報の項目がコンスタントに変わるという事実があるため、受信機又は送信機は、情報の更新のために、それが続けて使われるかどうかにかかわらず、その資源のかなりの部分の使用を強いられることになる。特に、同時にプログラムされ実装され得るデータパケットの多重分離フィルタの数が制限される。
【０００４】
出願人の名において１９９６年８月９日に提出された２つのフランス特許明細書ＦＲ ９６ １００６７及びＦＲ ９６ １００６８は、受信機におけるサービス情報を管理するためのモジュールに関し、特に、デジタルテレビジョンデコーダに関する。出願ＦＲ ９６ １００６７は、テレビジョン受信機、及び、受信機における内部ダイナミックデータベースに保持されたある種のデータの更新を管理するためのプロセスに関し、出願ＦＲ ９６ １００６８は、その内部データベースにおいて、デジタルストリームから受信、抽出されたデータをインデックスするためのプロセスに関する。ヨーロッパ、米国、日本及び中国を指定した出願ＷＯ９８／０９４３０は、出願ＦＲ ９６ １００６８を基礎とする優先権を主張している。ＦＲ ９６００６７の優先権主張出願は、ヨーロッパ（公開番号０８２３７９８）、中国（公開番号１１７５８２６Ａ）、米国（出願０８／９０６５９７）、インドネシア（出願Ｐ−９７２７７４）及び日本（公開番号９８５０８／９８）に提出されている。
【０００５】
これら２つの特許はまた、プログラムガイドのようなアプリケーションが、ＳＩデータを管理するためのモジュールから情報のこの項目又はその項目を要求するために発出し得る要求を説明している。そのモジュールは多重分離装置をプログラムしている。その要求は、パーマネント又はｏｎｅ- ｏｆｆ要求、予期又は非予期である。
【０００６】
これら２発明によれば、パーマネント要求に相当するデータは、そのパーマネント要求のデプログラミング（deprogramming ）まで、内部データベースに保持され、ｏｎｅ- ｏｆｆ要求に続き抽出されたデータは、即座の処理以上にはメモリに保持されない。
ユーザがプログラムガイドを介してステップをたどる場合、最近削除されたデータは再び抽出され得ることが可能である。
【０００７】
【発明が解決しようとする課題】
本発明は、上記のような場合におけるシステムの反応性を増加させることを提案している。
【０００８】
【課題を解決するための手段】
本発明の主題は、デジタルテレビジョンシステムにおいてサービス情報を管理するためのプロセスであり、そのシステムの受信機に関し、次のステップからなる。
- デジタルデータストリームから選択的に情報を抽出するための手段（５）をプログラミングし、
- 抽出された情報のうち少なくともいくつかを保持し、
- 保持された情報項目を、上記選択的抽出手段の、この情報項目に関連しているプログラミングにより、更新されたものとして又は更新されていないものとしてマーキングする。
【０００９】
ストリームからの情報項目の選択的抽出手段がデプログラムされる時、事前に受信機の内部データベースに保持された情報は、そのデータベースに保たれるが、更新なしとしてマークされる。
それゆえ、一方では、ユーザがステップをたどる場合、新たな抽出を待つ必要無く非常に迅速にこの非更新情報をユーザに供給することができる。受信機のメモリはそれにより忙しい状態になるが、メモリが飽和したら、更新されていないデータを削除することは簡単にできる。
【００１０】
本発明の特定の実施形態によれば、アプリケーションによる情報項目の抽出の要求の作成に続き、プログラミング及び格納のステップは次のように実行される、
- 要求された情報項目がデータベースに有る場合、データストリームからの情報項目抽出に続き、アプリケーションにその情報項目を転送し、データストリームからの情報項目の選択的抽出手段をプログラムし、データベースにおける情報項目を更新し、
- 要求された情報項目がデータベースにない場合、データストリームからの抽出に続き、選択的抽出手段をプログラムし、デコーダのデータベースに情報項目を格納する。
【００１１】
それゆえ、情報項目は、データベースに有る場合、要求を行なったアプリケーションに待ち時間無く転送される。これは、特に、アプリケーションによる最近の要求に従い格納された場合、例えば、ユーザがプログラムガイドを介してステップをたどる場合である。そのように格納された情報項目はまだ現在のものであるか、又は少なくともユーザを満足させる高い可能性がある。
【００１２】
データストリームにおいて情報項目を検索し、及びこの情報項目を格納するためのリソースは、アプリケーションにより要求された情報項目を検索し更新するためだけに使用され、見境無く情報を格納し更新するために使用されるものではない。
特定の実施例によれば、検索手段は多重分離装置からなる。
【００１３】
特定の実施例によれば、格納された情報項目を更新されたものとしてマークすることは、その項目の抽出に続く期間を通して有効であり、その期間、検索手段はそこから新たな値を抽出するようにプログラムされる。一度、１つの項目が抽出され、また、それを抽出するためのフィルタがアクティブである限り、その項目は更新されたものと考えられる。また、ストリームにおいて変わっていないバージョン番号が捕らえられる場合も、更新されたものと考えられ得る。
【００１４】
特定の実施例によれば、ストリームからの抽出に続き、格納された情報項目を更新されていないものとしてマークすることは、この情報項目の検索手段のデプログラミングと同時に実行される。
特定の実施例によれば、情報項目を更新されていないものとしてマークすることは、この情報項目を、その情報項目に対する選択的抽出手段がデプログラムされた日付と関連させることからなる。
【００１５】
この特徴は、情報項目の最後の更新から経過した時間を決定することを可能とする。これにより、特に伝送の周期性が知られている場合に、情報項目が陳腐化したかどうかを判断することが可能となる。
特定の実施例によれば、受信機のデータベースが飽和した場合、更新されていないものとしてマークされた情報は、日付の古さの順に削除される。
【００１６】
変形の実施例によれば、情報項目のマーキングは、この情報項目とともに、その情報項目を要求したアプリケーションに伝えられる。
それゆえ、アプリケーションは、マーキングの状態に応じて、この情報項目からなる使用を決定することができる。
変形の実施例によれば、受信機のデータベースが飽和すると、更新されていないとしてマークされた情報は日付の古い順で削除される。
【００１７】
変形の実施例によれば、アプリケーションにより、スクリーンに表示された更新されていない情報項目は、更新されていないものとしてビジュアルに識別される。
それゆえ、ユーザは情報項目の状態、及び、もしかしたら陳腐化しているかもしれないリスクに対して警告を受ける。
【００１８】
本発明の主題はまた、サービス情報及び、特にプログラムガイド情報が伝送されるデジタルテレビジョンシステムにおける受信機であり、上記受信機は、
データストリーム多重分離装置からなり、その多重分離装置は、上記ストリームから情報を選択的に抽出するためのプログラム可能なフィルタからなり、上記受信機は、
- 前に抽出された情報からなる上記受信機のデータベースを含むためのメモリと、
- データベースの情報を更新又は更新なしとしてマークする手段と
からなる。
【００１９】
変形の実施例によれば、更新又は更新なしとしてマークすることは、上記多重装置のプログラミングの機能として実行される。
変形の実施例によれば、そのデバイスは更に、更新なし情報をマークするために使用されるクロックからなる。
【００２０】
【発明の実施の形態】
本発明の他の特徴および利点は、限定しない実施例の説明を通して明らかになる。この実施例は添付の図に描かれている。
ＭＰＥＧ及びＤＶＢサービスデータ、セグメント及びテーブルのフォーマットと内容に関する更なる情報のために、特に次の３つの文献を参照として挙げる。
【００２１】
（ａ）ＥＴＳ ３００ ４６８ − デジタルビデオ放送（ＤＶＢ）システムにおけるサービス情報（ＳＩ）のための仕様- １９９６年１月２３日。
（ｂ）ＩＳＯ／ＩＥＣ １３８１８−１ （１９９４）動画及び関連する音声の一般的なコーディング - 勧告Ｈ．２２０であり”ＭＰＥＧ II Ｓｙｓｔｅｍｓ”とも呼ばれる。及び、
（ｃ）ＥＴＲ２１１ - テレビジョンのためのデジタル放送システム： ＭＰＥＧ２システムの使用のための実装ガイドライン；サービス情報の実装と使用に関するガイドライン。
【００２２】
図１は、ＤＶＢタイプ（デジタルビデオ放送）のデジタルテレビジョンのための統合されたデコーダ／受信機の図である。
本発明は、この物理的環境に限定されず、サービスデータの伝送のいくつかの他の種類、例えばフレーム帰線間における変調データを介する伝送、に容易に適用され得ることは明らかである。
【００２３】
図１のデコーダは、アンテナ１に接続され、アンテナはデコーダのチューナ２に接続されている。チューナにより伝達される信号は、復調器３により復調される。復調されたデータは、訂正回路４により訂正され、多重分離装置５に転送される。
後者は、例えば、ＴＨＯＭＳＯＮ ＭＵＬＴＩＭＥＤＩＡの名前で１９９５年１２月２９日に提出されたフランス特許出願９５ １５７６７に説明されているものと同様な多重分離装置である。多重分離装置５は、デコーダによりサポートされる種々のアプリケーションの機能としてマイクロプロセッサ２３によりプログラムされる数多くの、機能拡張によるフィルタと呼ばれるフィルタリングレジスタからなる。多重分離装置はフィルタリングレジスタの内容をデータパケットのあるパラメータと比較し、肯定的な比較に対するデータパケットをロードする。
【００２４】
図を明確にするために、マイクロプロセッサ２３の最も重要な接続のみが記述されている。
多重分離装置によりフィルタされた音声又はビデオのパケット又はセグメントは、アプリケーションを待つバッファメモリ６の所定のエリアに格納される。必要であれば、このバッファメモリ６に格納される前に、ユーザの権利の関数として、その情報は最初に復号化回路７により復号化される。
【００２５】
本実施例によれば、５つのアプリケーションがある。すなわち、音声デコーダ１６、ビデオデコーダ１７、テレテキストデコーダ１８、アクセス制御アセンブリ（復号器７、チェックするためのマイクロコントローラ８、及び、通常のオペレーティングモードにおいて、マイクロプロセッサカード１０に接続されたマイクロプロセッサカードのためのインターフェース９からなる。）、また、サービスデータ管理モジュールの５つである。
【００２６】
デコーダはまた、リモートコントロールのための赤外線インタフェース２４からなり、そのインタフェースはまたマイクロプロセッサ２３と接続している。後者は、アプリケーションを実装するための常駐又はダウンロードされたプログラムとともにオペレーティングプログラムを含むメモリ１２に接続している。
交換電話網１４と接続されたモデム１３はまた、マイクロプロセッサにより制御される。
【００２７】
文字生成器１５により、デコーダのパラメータ又は特定のアプリケーションに関係するコマンドメニュー又はグラフィックスの生成を行なう。この文字生成器により生成されたビデオ信号は、ビデオデコーダ１７又はテレテキストデコーダ１８から発生したビデオ信号の１つと共に多重化され、テレビジョン２２と接続された第１のＳＣＡＲＴソケット、又はビデオデコーダ２１と接続された第２のＳＣＡＲＴソケットに向かう。
【００２８】
本実施例によれば、サービスデータ管理モジュールは、概念的には、専用回線が使用され、音声又はビデオデコーダの方法で、データパケットを処理するアプリケーションであるにもかかわらず、物理的には、マイクロプロセッサにより管理されているプログラムである。
そのモジュールは、サービスデータ（ＭＰＥＧ及びＤＶＢテーブル及びセグメント）及びカスタマアプリケーション（プログラムガイド、遠隔購買、インタラクティブゲーム等）である。それはカスタマアプリケーションからの要求を管理し、受信したサービスデータの内部データベースを維持する。
【００２９】
本実施例によれば、カスタマアプリケーションは、マイクロプロセッサによってもまた管理されるプログラムガイドである。
アプリケーションにより必要とされる情報に関係する要求を作成するための多数の機能が、管理モジュールによりカスタマアプリケーションに対して可能になる。
【００３０】
その要求機能は非同期に動作する。応答がある場合、要求へのその応答は、この応答が可能な時に、管理モジュールによりアプリケーションに通知される。これは、要求機能識別メカニズムの実装を必要とする。この目的のために、識別子が、発出される各要求のためにアプリケーションにより選択され、この要求とともに伝送される。この識別子は管理モジュールにより、応答の通知と結び付けられる。
【００３１】
図２ａから２ｃは、要求に続く、カスタマアプリケーション、サービスデータ管理モジュール、及びこれらのデータのソースすなわち多重分離装置／バッファメモリ／マイクロプロセッサアセンブリ、の間の交換における３つのケースを示している。
図２ａは、内部データベース（”キャッシュメモリ”）がカスタマアプリケーションにより要求された情報項目を含むケースに関する。後者の要求に続き、この情報項目が可能かどうかの通知がある。このケースでは、情報項目がデータベースに存在するため、応答の通知はほぼ即座に行なわれる。このケースでは、多重分離装置へ、又は、多重分離装置からデータ項目は伝送されていない。アプリケーションへのデータ伝送は、管理モジュールがデータを書くバッファメモリを介して実行される。使用されるバッファメモリのエリアはアプリケーションの要求の中で識別される。アプリケーションは、一度通知がなされると、順当にそこからデータを読む。このケースについて、詳細は後述する。
【００３２】
図２ｂは、要求された情報項目が内部データベースにないケースを示している。このケースでは、カスタマアプリケーションの要求に同様にして続き、情報項目が一時的に可能でないことを知らせるための通知が管理モジュールからアプリケーションになされ、そして、管理モジュールにより多重分離装置へコマンドが通知される。求められている情報項目に相当するセグメント又は複数のセグメントがデータストリームから見つかると、多重分離され、バッファメモリに格納され、多重分離装置はＳＩ管理モジュールに、これらのセグメントが可能であることを通知する。そのセグメントのデータの読み込み、及び再フォーマットの後、管理モジュールが今度は、求めている情報項目が可能であることをカスタマアプリケーションに通知する。前のケースのように、そのモジュールは、求めている情報項目（セグメントからのデータのちょうどいくつかであり得る）を、カスタマアプリケーションにより最初の要求の間に割り当てられたバッファメモリに書き込む。それゆえに、このケースでは、この通知はケース２ａより遅く到着する。
【００３３】
図２ｃは、図２ａに示すような最初の要求は、求められている情報における変更が合図されるべきであることを明白に示しているケースを示している。このケースでは、この情報項目を含むデータパケットがデータストリームから抽出されるようにした多重分離装置のフィルタは、非活性化される替わりに前の値に保たれる。この種の要求は、パーマネント要求と呼ばれ、詳細は後述する。
【００３４】
本実施例によれば、４種類の要求がある。
（ａ）Ｏｎｅ−ｏｆｆ要求
そのような要求がアプリケーションにより管理モジュールに送られると、後者は、そのリソース（フィルタ及びメモリ）を、要求されたデータがアプリケーションに伝送される時までのみ使用可能とする。そのリソースは原則として即座に開放される。
【００３５】
（ｂ）予期されたｏｎｅ−ｏｆｆ要求
この要求は、ｏｎｅ−ｏｆｆ要求の特徴を有しているが、優先度はｏｎｅ−ｏｆｆ要求より小さい。この管理モジュールは２つのＦＩＦＯタイプのメモリを保持し、１つは予期された要求のためであり、もう１つは予期されない要求のためのものである。待っている予期された要求は、いつも予期されない要求の後に処理される。
【００３６】
（ｃ）パーマネント要求
管理モジュールのリソースは、要求されたデータが多重分離され伝送された後でも、管理モジュールのリソースは維持される。これらのデータにおいて変更が発生するといつでも、通知がアプリケーションに送られる。管理モジュールは、それゆえ、システマチックなモニタリングを、アプリケーションがこのモニタリングを中断するコマンドを送るまで、実行する。
【００３７】
（ｄ）予期されたパーマネント要求
この要求はパーマネント要求と同様であるが、優先レベルはパーマネント要求よりも低い。
要求の優先度は、言うまでもなく、これらの要求に関係しているデータが実際に受信される順番を事前に判断しない。この順番はまた、各データ項目の周期及びこの周期を基準として要求が示される時点等の要因にも依存する。
【００３８】
図３ａは、ｏｎｅ−ｏｆｆ要求の状態図であり、図３ｂはパーマネント要求の状態図である。
アプリケーションが要求を生成するときはいつでも、要求タイプが関係付けられていなければならない。
パーマネント要求のケースにおいて、ストリームから取得されたデータは管理モジュールにおける内部データベースに追加される。これは、ｏｎｅ−ｏｆｆ要求に続き抽出されたデータの場合はそうではなく、データのコピーは保持されない。パーマネント要求に関係するデータを含むテーブルの新しいバージョンが捕捉されると、このテーブルからの適切なデータはデータベースにおけるデータと比較される。バージョンの変更は、各テーブルとともに伝送される”version ＿id" 又は"version＿number" と記述されるパラメータの値の変更により示される。更新の通知は、少なくともこれらのデータのうちの１つが変更されなければ、事前に伝送されない。テーブルのバージョン識別子”version ＿id" は、アプリケーションにより要求されていないデータにのみ関係している場合でも、実際にテーブルに発生する変更にかかわらず変更される。このメカニズムは、アプリケーション及び管理モジュール間の冗長データの伝送を回避する。
【００３９】
更に、アプリケーション要求は、基本要求から区別される。アプリケーション要求は、その名前が示すように、カスタマアプリケーションにより発出される。アプリケーション要求は、ＳＩ管理モジュールにより翻訳され、必要なだけの数の基本要求になる。この状況では、基本要求は多重分離装置レベルにおいて単一のフィルタに翻訳され得るものである。基本要求は、それらが関連するデータが重なり合わないような方法で決定される。
【００４０】
要求の２つのテーブルは、ＳＩモジュールにより保持される。それらは、アプリケーション要求のテーブル及び基本要求のテーブルである。
【００４１】
【表１】
アプリケーション要求のテーブル
【００４３】
【表２】
基本要求のテーブル
アプリケーション要求のテーブルは、各要求のための次の要素からなる。
- Request identifier 要求識別子
- Type 要求の種類（予期されたｏｎｅ−ｏｆｆ、予期されないｏｎｅ−ｏｆｆ … ）
- Function 要求の関数
- ‘Wait‘、これは、対応する待ちの基本要求の数であり、すなわち、まだ応答を引き起こしていない基本要求の数である。（要求を発出したアプリケーションへの最初の通知は、この数字がゼロに等しい時に送られる）
- ‘SingNB‘、これは、バッファメモリへのデータ伝送をまだ引き起こしていない基本要求の数である。
【００４５】
- ‘SList ‘、これは、このアプリケーション要求と関連した基本要求の識別子のリストである。
- Parameters アプリケーション要求と結びついたパラメータ（例えば、事象のリストが探索されているサービスの識別である）
基本要求のテーブルは各基本要求のための次の要素からなる。
【００４６】
- Request identifier 要求のための識別子
- Type 要求の種類
- Function 要求の関数
− State 要求の状態
- Number of applicationrequests 基本要求と結びついたアプリケーション要求の数
- Date 要求の非活性化の日付け（妥当ならば）
- Parameters 基本要求と結びついたパラメータ
ＳＩ管理モジュールがアプリケーション要求を基本要求又は複数の要求に翻訳するとき、それは、基本要求のテーブルがすでにこれらの要求を含むかどうかをチェックする。新たな基本要求は、同一の要求が既に存在する場合のみ対応するテーブルに挿入される。これにより、多重分離装置のリソースを冗長に使用することを回避することが可能となる。
【００４７】
２つの基本要求は、それらが同一の関数及び同一のパラメータを有していれば同一と見なされる。基本要求が既に対応するテーブルに存在すれば、ＳＩモジュールは既に存在する基本要求の種類をチェックする。もし、この種類が新たな基本要求の種類よりも優先度が低ければ（これは、この新しい基本要求を引き起こしたアプリケーション要求の種類である）、存在する基本要求の種類は、新しい値をとるように変更される。要求タイプの最低から最高の優先度の区分は、予期されたｏｎｅ−ｏｆｆ、予期されたパーマネント、予期されないｏｎｅ−ｏｆｆ、予期されないパーマネントである。
【００４８】
アプリケーション要求のテーブルの次の要素は、対応する基本要求のプログラミング又は変更に続き更新される。それらは、Ｗａｉｔ、ＳＬｉｓｔである。基本要求のテーブルの内容とのリンクはこのようにして確立される。
基本要求のテーブルはまた、他の役割を持っている。すなわち、データベースにデータ項目があるかどうか、また、このデータ項目が最新のものであるかどうかを決定する可能性を提供する。
【００４９】
このテーブルからの要求の”State ”フィールドは次の値のうちの１つをとり得る。
- ‘Waiting ‘、要求はアクティブであるが、データがまだ受信されていないことを表す。
- ’Ready ‘、要求はアクティブであり、データはデータベースに格納されており、更新されていることを表す。
【００５０】
- ‘Non-updated ‘、要求はもはやアクティブでなく、データはデータベースに格納されているが、更新されていないことを表す。
基本要求のテーブルはまた、各基本要求毎に、関連する活性化アプリケーション要求の数を合計を出すために数える。この数は、新しいアプリケーション要求のブレークダウン又は古い要求のデプログラミングにより加算又は減算される。基本要求においてこの数が０になるとき、後者の状態は‘non-updated ‘になる（前の状態が‘Ready ‘だった場合）、すなわち、非活性である。前に抽出された日付は、もし日付があれば、データベースに格納されたままである。
【００５１】
アプリケーション要求の数が０になり、１つ又はその他の理由によりデータベースに情報を格納していない基本要求はテーブルから削除される。多重分離装置の対応するフィルタは解放される。この理由は、種々であり得る。すなわち、データが取得される前のデプログラミングが速すぎる、要求データが放送されない、等である。
【００５２】
非活性の基本要求は、適切なアプリケーション要求により再活性化され得、又は、データベースで使用されているメモリにおけるいくらかの領域を解放する必要ができ、それに対応するデータが削除される時に基本要求のテーブルから削除され得る。
要求の非活性化の日付は基本要求のテーブルに格納される。本ケースにおいては、この日付はシステムクロックの値からなり、このクロックはエンコーダのクロックと同期している。しかしながら、他の種類のクロックを採用することもまた考えられる。
【００５３】
（ｏｎｅ- ｏｆｆの、又はパーマネントタイプの）基本要求に対応するデータが多重分離されると、それらはバッファメモリに転送される。この転送は、アプリケーション要求とのリンクの数だけ発生する。関連するアプリケーション要求の各々における基本要求‘SingNB‘の数は減算される。ＳＩ管理モジュールによるアプリケーションへのデータ使用可能性の通知は、この数がこのアプリケーションにおいて０に到達した時に実行される。すなわち、アプリケーションにより発出されたアプリケーション要求とリンクした全ての基本要求が結果を与え、その結果をバッファメモリに転送した時に、上記通知は実行される。
【００５４】
対照的に、基本要求に関するデータベースにおけるデータの次の変更がある場合、この変更は、関連するアプリケーションに即座に通知される。
図５は、後述するが、特定のケースにおける２つのテーブルの例を示している。
基本的要求が‘non-updated ‘として印付けられた場合、これはデータベースにおけるデータがもはや実際に最新でないことを意味するのではなく、それらが発生した元の要求が上述した非活性化の日から決定され得る期間維持されていないとすると、そのようなことである可能性があるということを単に意味している。
【００５５】
アプリケーションへ転送する目的で管理モジュールがデータをバッファメモリへ転送する時、‘Date‘フィールド又は複数フィールド、及び‘State ‘フィールド又は複数フィールドの内容はまたそこに格納される。これらの値はこの情報の使用を決定するアプリケーションにより読まれる。状態が‘Ready ‘の時、データは最新のものである。状態が‘non-updated ‘の時、それらは最新でなく、‘Date‘ フィールドはそれらがどのくらい古いかを示している。アプリケーションがプログラムガイドであるとすると、更新されていないものとして印付けられて表示されるデータは、そのようなものとして識別するためにそのように表示される。例えば、更新された情報項目と区別されるような影付きの表示又はカラーでの表示である。
【００５６】
基本要求の状態が‘Ready ‘であるとき、データは最新である。データの転送の間、これをアプリケーションに示すために、‘Date‘フィールドの転送された値は０である。
本実施例によれば、パーマネント基本要求（予期か予期でないかにかかわらず）のみがデータベースで抽出されたデータの格納を引き起こすが、変形の実施例によれば、ｏｎｅ- ｏｆｆ要求に対応するデータを格納することもできる。このケースにおいてはまた、もちろん、対応するテーブルの中にｏｎｅ- ｏｆｆタイプの基本要求を保持する必要がある。
【００５７】
要求に続き、内部データベースにおいて更新なしのデータが読まれたにせよそうでないにせよ、多重分離装置のフィルタは、ストリームから最も最近の値を抽出する目的でプログラムされる（これがまだ行なわれていなければである）。これらの値は、一度ストリームから抽出されると、データベースに書かれ、必要であれば最も古いデータを上書きする。基本要求の状態の変更は、適切に行なわれる。すなわち、テーブルに既に存在する要求は‘Wait‘状態から‘Ready ‘状態に移り得るが、また、‘non-updated ‘状態から‘Ready ‘状態及びその逆もあり得る。抽出されるデータに対応する基本要求がない場合、それらはもちろん生成される。
【００５８】
本実施例によれば、‘version ＿id' パラメータの管理は多重分離装置のレベルで実行される。２つのタイプのフィルターが使用される。第１のタイプにおいては、取得される情報項目のバージョン番号がマスクされ（バージョン番号を問わず、捕捉された最初のバージョンが多重分離される）、第２のタイプにおいては、バージョン番号は特定の値を有する（このバージョン番号を有する情報項目のみ多重分離される）。
【００５９】
基本要求が生成され、対応するフィルタが存在しない場合、採用されるのは第１のタイプのフィルタである。一度対応する情報項目が捕捉され、抽出されると、基本要求がパーマネントタイプである場合、抽出されたバージョン番号の値は加算され存在するフィルタに追加される。上述した第２のタイプのフィルタはこのようにして生成される。情報項目の次のバージョンが捕捉されることがこのようにして確かになる。
【００６０】
データベースにバージョン番号の値を格納することはもちろん考えられる。
いくらかのメモリを解放する目的でデータベースをきれいにすることは、基本要求のテーブルの‘Date‘ フィールドに示されている日付の助けにより実行される。‘non-updated ‘状態における基本要求は、これらの要求と密接な関係があるデータと共に古い順に削除される。このクリーンアップは、データベースがいっぱいであるときに実行される。それは率先して行なわれ、また、‘non-updated ‘状態における基本要求にのみ関係している限り、ＳＩ管理モジュールの制御の下にある。‘non-updated ‘状態における要求がもはやないにもかかわらずデータベースがいっぱいであるとき、この事実はアプリケーションに通知される。更なるクリーンアップはアプリケーションの制御の下で実行され得る。
【００６１】
サービスデータ管理モジュールの役割のうちの一つは多重分離装置のフィルタをプログラムすることである。この機能を満足し、望んでいるデータに速いアクセスをさせるために、それはアクセスする先のネットワーク又は複数のネットワークの物理構造のイメージを保持している。
ドキュメント（ａ）及び（ｂ）はネットワーク又は複数ネットワーク、マルチチャネルパッケージ、サービス及び転送されたイベントの構成についての情報を与える１０のテーブルを定義する。テーブルは特定のＰＩＤ（パケット識別データ）及び特定のテーブル識別値（table ＿id) により識別され、それらの値は上記ドキュメントにより定義される。各テーブルは、このテーブルの内容がテーブルの１つの伝送から次の伝送へ変わったかどうかを決定することを可能とするバージョン識別子を含む。
【００６２】
ここで関係するテーブルは、ＮＩＴ（ネットワーク情報テーブルを意味する）と呼ばれるテーブルである。ＮＩＴテーブルは与えられた伝送ネットワークについての情報からなり、特に、伝送チャネル（又はトランスポートストリーム）毎に可能なサービスのリストからなる。
データ管理モジュールはネットワーク、チャネル及び可能なサービスの内部索引付け（ｉｎｄｅｘａｔｉｏｎ）を構成する。デコーダがセットされるか、又は、ＮＩＴテーブルが更新されるとき、論理キーが可能な各サービスに割り当てられる。このキーは、モジュールにより保持されるデータベースにおけるこのサービスのためのインデックスである。
【００６３】
ＤＶＢシステムにおいて、サービスは、次の変数からなるパスを介して重ならずに置かれ得る。
- network ＿id （ネットワーク識別子）
- (transport＿stream＿id; original＿network ＿id) ペア
- service＿id（現実のサービス識別子）
この３変数は１６ビット上でコード化された自然数である。
【００６４】
ネットワークのためのリスト、それぞれのネットワークのためのチャネルのリスト及び各チャネルのためのサービスのリストの３タイプのリストが作成される。
ネットワークのリストの要素は、新しいネットワークから構成されるＮＩＴテーブルが多重分離されるときはいつでも生成される。これを行なうために、ＰＩＤが０ｘ００１０に等しいトランスポートパケットがフィルタにかけられる。これらのパケットは実際にＮＩＴテーブルを含み、加えて、変数table ＿idにより識別される。４ビットコードは、対応するテーブルが多重分離される順に各ネットワークと関連している。そのコードは、このネットワークに関係する情報からなる構造のためのアドレスポインタのインデックスである。
【００６５】
ＮＩＴテーブルは、各チャネルにおける可能なサービスのリスト、及びこのネットワークのためのチャネルのリストからなる。
ネットワークのリストにおける各ネットワークのために、チャネルのリストが生成される。チャネルのリストの各エレメントは５ビットの助けによりインデックスされる。そのリストは、各チャネルに特別のデータからなる構造のためのアドレスポインタを含む。データベースにおけるチャネルを識別するための論理キーはネットワークのための４インデックスビットからなり、このネットワークのチャネルのインデックスの５ビットが続く。
【００６６】
各チャネルにおいて、サービスのリストが生成され、そのサービスのリストはＮＩＴテーブルにより記述されたサービスの識別子からなる。リストにおける各サービスは７ビット上でインデックスされる。それゆえ、データベースにおけるサービスの論理キーは合計１６ビットからなる。すなわち、４ネットワークインデックスビット、５チャネルインデックスビット及び７サービスインデックスビットである。
【００６７】
サービスの事象は、この事象（テーブルの変数 event ＿id) を示す１６ビットの助けにより識別され、それには関連するサービスの論理キーの１６ビットが追加される。
データベースの構造（事象を除く）は次の構造により構成される。
【００６８】
【表３】
【表４】
【表５】
名前に”Address"の語を含む変数は、データ構造の開始に対応するメモリエリアへのポインタである。
他の変数は、データストリームから抽出された情報に対応する。理解を助けるために、これらの変数にはドキュメント（ａ）に用いられる名前が括弧と引用符に囲まれて続く。
【００７２】
ネットワーク、チャネル及びサービスのリストはそれぞれ配列に入れられ、各配列は、一方では、ネットワーク、チャネル又はサービスタイプのデータ構造への８ポインタからなり、他方では、リストの残りを含む可能な配列へのポインタからなる。この最後のポインタは、他の配列がない場合、すなわち、配列がリストの最後の要素を含む場合には空文字である。この後者のポインタはインデックスされない。
【００７３】
配列は８要素を含み、これは２の累乗に相当する。これにより、この場合ではチャネルインデックスの最後の３ビットをマスクすることにより、要望されているポインタを含む配列を決定することが可能となる。
データベース配列は、ネットワークのリストの最初の部分を含む配列へのポインタを含む。
【００７４】
NetworksList配列は、最初の８ネットワークへのポインタを含む。本実施例によれば、ネットワークの完全なリストを含む最大で２つのNetworksList配列が存在する。
ネットワーク配列は、このネットワークに関係するチャネルのリストの最初の配列へのポインタと共に、与えられたネットワークに関係する情報を含む。
【００７５】
他の配列の構造は、ちょうど説明されたものと同様である。更に、それを事象及び他のタイプのデータに拡張することは容易である。
変形の実施例によれば、ネットワーク、チャネル及びサービスの構造に関するデータに関係する要求はパーマネントタイプの要求であり、その目的は、配列のイメージをデータベースにおいてコンスタントに最新に保つことである。
【００７６】
管理モジュールにおける交換において、アプリケーションは論理キーを使用する。これらは、そのモジュールにより、情報項目が格納される位置に対応するメモリアドレスへ翻訳される。それらは、要求のテーブルに格納されたパラメータの部分を形成する。
図５は、ネットワークが存在する場合における管理モジュールのデータベースの図であり、そのネットワークは２チャネルからなり、各チャネル自身は２サービスからなる。
【００７７】
アプリケーション要求の上述したテーブルはアプリケーションにより生成される要求のリストを与える。本実施例によれば、進行中の唯一の要求は、ネットワーク上のサービスのリストを取得することを意図するパーマネントタイプの要求である。
今回の場合では、ネットワークにおいて２チャネルがあるとすると、アプリケーション要求を翻訳するために、２つの基本要求が必要である。サービスのリスト当たり又はチャネル当たりの１つの基本要求は、基本要求のテーブルに書き込まれる。
【００７８】
同図において、各基本要求に対応するフィルタは基本要求のテーブルの左に見られる。
図５に示す瞬間においては、サービスリストは最初に入力されている。アプリケーション要求がパーマネント的とすると、この要求に関係するデータベースの内容のみならず対応するフィルタが、予期されたデータが取得された最初の機会の後に、保持される。
【００７９】
リストを結合する枝を識別する数字及びこのリストの中の要素は、リストの中のこの要素のインデックス（論理キー）に相当する。
アプリケーションは、ネットワークにおいて進行中の事象のリストを取得しようとする。サービス毎に進行中の１事象があり、これは、対応する‘Current/Next EIT ' テーブル（”事象情報テーブル”）をフィルタにかけることを必要とする。そのようなテーブルは実際に各サービスのために放送される、すなわち、サービス説明テーブルのフラグEIT ＿present ＿following ＿fragはこれらのサービスに対して値１を有する、ということを残りの説明では仮定する。
【００８０】
アプリケーションにより発出される要求は、特定のサービスにおいては、次のパラメータからなる。
- 要求識別子
- 要求のタイプ
- 関連するサービスの論理キー
- ＳＩモジュールから多重分離されたデータを受信するためのバッファメモリのメモリアドレス
そのデータベースは、進行中の事象又は次の事象に関係したデータ項目を含まない、すなわち、基本要求のテーブルはこれらのデータに関連する基本要求を含まないということを最初に仮定する。
【００８１】
プログラムガイドアプリケーションは、例えば、第１のネットワーク（”０”）の第１のチャネル（”０”）に属する第２のサービス（”１”）の現在及び次の事象を検索する。この要求は、ユーザによる、進行中のプログラムについての情報、及び特定のサービスの進行中のプログラムの直後のプログラム、例えばＣａｎａｌ＋（フランスのテレビチャネル）についての情報を表示するためのコマンドに続いて行なわれる。
【００８２】
関連するサービスの論理キーは、
００００ ０００００ ０００００１
である。
対応するアプリケーション要求はＳＩモジュールに伝送される。この要求はパーマネントタイプである。この実施例のフレームワークの中で、単一サービスの現在及び次の事象のみがアプリケーションにより要求されることとすると、この要求は基本的であり、ＳＩモジュールにより更にブレークダウンされるべきでない。基本要求は要求の対応するテーブルに書き込まれる。
【００８３】
更に、ＳＩモジュールは、この要求に関係するＥＩＴテーブルのフィルタリングが正しく実行されるように、多重分離装置のフィルタをプログラムする。ドキュメント（ａ）によれば、"Current/Next" EIT テーブルからなるパケットのＰＩＤの値は、０ｘ００１２である。放送された中でどれが現在のＥＩＴテーブルかを決定するために必要なサービス識別子("service ＿id")、チャネル識別子("transport ＿stream＿id" 及び "original＿network ＿id")の値は、論理キーによりデータベースの中で使用可能である。基本要求のテーブルにおける基本要求の状態はさらに”Wait”状態にセットされる。
【００８４】
一度、正しいＥＩＴテーブルが捕捉されると、ＳＩモジュールは、そのパケットから、内部データベースに格納されるデータの値を抽出する。本実施例によれば、これらのデータは、上述した"CurrentNextEvent"データ構造にて現れたものである。ＳＩモジュールは、要求しているアプリケーションにデータがあることを通知し、アプリケーションにより予め確保されたバッファメモリにそれらをコピーする。データベースにおいて、論理キーにより示されたパスに対応するサービスデータ構造のアドレスポインタ"CurrentNextEventAddress" は、"CurrentNextEventAddress" 構造に対応するメモリアドレスとプログラムされる。基本要求のテーブルにおける基本要求の状態は”Wait”から”Ready ”にスイッチする。
【００８５】
サービス毎に最大でも１つの現在の事象と１つの次の事象があるということに注意すべきである。したがって、この特定のケースでは、"CurrentNext Event" データ構造の構造をインデックスする理由はない。なぜならば、それが依存するサービスへ向かう論理キーにより既に十分に識別されているからである。
事象の時系列のシリーズを含むＥＩＴテーブルの内容がロードされていれば、そのケースは異なるものとなる。
【００８６】
例えば、ユーザによる、プログラムガイドを再び閉じるコマンドに続き、アプリケーションはその要求をキャンセルする。このケースにおいて、現在／次の事象に関係する基本要求を参照する進行中のアプリケーション要求がこれ以上ないとすると、ＳＩモジュールは、多重分離装置のフィルタを解放し、システムクロックの現在の値を最初の要求のテーブルの"Date"フィールドに書き込む。このケースのように、データが実際に多重分離され、事前にデータベースに格納されると仮定すると、要求の状態は”non-updated ”になる。逆のケースでは、それらは単にテーブルから削除されている。
【００８７】
変形の実施例によれば、管理モジュール自体が、ネットワークの構造（特にネットワークのリスト及びチャネルの関連するリスト）に関係するある要求を生成し、それらをパーマネント的に保持する。
本発明は、衛星、無線中継又はケーブルによるデータの伝送に限定されず、データ又はデータパケットがデータストリーム中に周期的に出現するようないかなるシステムにも実装され得る。特に、記録された、もしくは、事前に記録されたデータストリームの場合にそうである。
【００８８】
更に、ここでの実施例はサービスデータに特に関係しているが、本発明はこのタイプのデータに限定されないことは明らかである。例えば、いわゆるプライベートデータが類似の方法により処理され得る。
【図面の簡単な説明】
【図１】本実施例によるテレビジョン受信機の構成図である。
【図２】アプリケーション、データ管理モジュール及び図１に示す装置の多重分離装置間で発生する交換のタイムチャートである。
【図３】ｏｎｅ- ｏｆｆ要求（３ａ）とパーマネント要求（３ｂ）のそれぞれの動作方法を示す図である。
【図４】アプリケーションのスクリーン、すなわち電子プログラムガイドを示す図である。
【図５】特定の瞬間における、管理モジュールにより維持されているデータベースの図である。
【符号の説明】
１ アンテナ
２ チューナ
３ 復調器
４ 訂正回路
５ 多重分離装置
６ バッファメモリ
７ 復号化回路
８ マイクロコントローラ
９ インターフェース
１０ マイクロプロセッサカード
１２ メモリ
１３ モデム
１４ 交換電話網
１５ 文字生成器
１６ 音声デコーダ
１７ ビデオデコーダ
１８ テレテキストデコーダ
１９ ＳＩモジュール
２１ ビデオデコーダ
２２ テレビジョン
２３ マイクロプロセッサ
２４ 赤外線インタフェース
Claims (11)
- デジタルテレビジョンシステムにおいてサービス情報を管理する方法であって、該システムの受信機に関し、
デジタルデータストリームから情報項目を選択的に抽出する選択的抽出手段をプログラミングし、
上記選択的抽出手段によりデジタルデータストリームから情報項目を抽出し、
少なくともいくつかの抽出された情報項目を、上記受信機のデータベースに格納し、格納された情報項目を更新されたものとしてマーキングし、
上記情報項目をデジタルデータストリームから抽出するための上記選択的抽出手段におけるプログラミングが解除されたときに、格納された当該情報項目を、更新されていないものとしてマーキングする
各ステップを有することを特徴とする方法。 - アプリケーションによる情報項目の抽出の要求の作成に続き、上記プログラミングするステップ及び上記格納するステップは、
要求された情報項目が上記データベースにある場合、アプリケーションへ当該情報項目を転送し、
要求された情報項目がデータベースにない場合、選択的抽出手段のプログラミングを行ない、デジタルデータストリームから情報項目を抽出し、上記データベースに当該情報項目を格納する
ことにより実行されることを特徴とする請求項１に記載の方法。 - 上記選択的抽出手段は多重分離装置からなることを特徴とする請求項１又は２に記載の方法。
- 格納された情報項目を更新されたものとしてマーキングすることは、それの抽出に続く期間有効であり、その期間、選択的抽出手段は上記デジタルデータストリームから新たな値を抽出するようにプログラムされることを特徴とする請求項１ないし３いずれか一項記載の方法。
- 格納された情報項目を、ストリームからのその抽出に続き更新されていないとしてマーキングすることは、この情報項目を探す上記選択的抽出手段のデプログラミングと共に実行されることを特徴とする請求項１ないし４のうちいずれか一項に記載の方法。
- 情報項目を更新されていないものとしてマーキングすることは、この情報項目を、その情報項目に対する上記選択的抽出手段がデプログラムされた日付と関連付けることからなることを特徴とする請求項５記載の方法。
- 上記受信機のデータベースが飽和すると、更新していないとしてマークされた情報は、日付の古い順に削除されることを特徴とする請求項６記載の方法。
- 情報項目のマーキングは、この情報項目と共に、該情報項目を要求したアプリケーションに伝えられることを特徴とする請求項１ないし７のうちいずれか一項記載の方法。
- アプリケーションによりスクリーンに表示される更新されていない情報項目は、更新されていないものとして視覚的に識別されることを特徴とする請求項１ないし８のうちいずれか一項記載の方法。
- サービス情報、特に、プログラムガイド情報が伝送されるデジタルテレビジョンシステムにおける受信機であって、該受信機は、
データストリーム多重分離装置からなり、該多重分離装置はデジタルデータストリームから情報項目を選択的に抽出するためのプログラム可能な手段からなり、
上記受信機は、
上記受信機の、以前に抽出された情報項目を格納するデータベースを含むためのメモリ、
上記データベースに情報項目が格納されたときに、データベースに格納された当該情報項目を更新されたものとしてマーキングし、上記情報項目をデジタルデータストリームから抽出するための上記手段におけるプログラミングが解除されたときに、上記格納された情報項目を更新されていないものとしてマーキングするための手段
とを有することを特徴とする受信機。 - 更に、更新されていないことの情報をマーキングするために用いられる時計を有することを特徴とする請求項１０に記載の受信機。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9715163A FR2771884B1 (fr) | 1997-12-02 | 1997-12-02 | Procede de gestion d'informations de service dans un systeme de television numerique et recepteur mettant en oeuvre ce procede |
| FR9715163 | 1997-12-02 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11234633A JPH11234633A (ja) | 1999-08-27 |
| JP4111255B2 true JP4111255B2 (ja) | 2008-07-02 |
Family
ID=9514056
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP34164798A Expired - Fee Related JP4111255B2 (ja) | 1997-12-02 | 1998-12-01 | デジタルテレビジョンシステムにおけるサービス情報を管理するための方法及び受信機 |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP0921681B2 (ja) |
| JP (1) | JP4111255B2 (ja) |
| CN (1) | CN1157948C (ja) |
| DE (1) | DE69805044T3 (ja) |
| FR (1) | FR2771884B1 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2352914A (en) | 1999-08-03 | 2001-02-07 | Sony Uk Ltd | Data broadcast method |
| FR2803966B1 (fr) * | 2000-01-19 | 2002-11-22 | Sagem | Procede de collecte dans un decodeur de television de signaux de parametres de reglage |
| ES2312417T3 (es) * | 2000-02-23 | 2009-03-01 | Koninklijke Philips Electronics N.V. | Procedimiento, transmisor y sistema de transmision. |
| WO2004010701A1 (en) * | 2002-07-24 | 2004-01-29 | General Instrument Corporation | Method and apparatus for rapid capture of program identifier data in a broadband transcoder multiplexer |
| JP4308546B2 (ja) | 2003-02-20 | 2009-08-05 | パナソニック株式会社 | デジタル放送受信装置、デジタル放送受信方法及びデジタル放送受信プログラム |
| JP2007509517A (ja) * | 2003-10-06 | 2007-04-12 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | サービスを配信するためのシステム、送信機、受信機、信号及び方法 |
| EP1542472A1 (fr) * | 2003-12-10 | 2005-06-15 | Canal + Technologies | Procédé et dispositif de récupération d'information dans des systèmes de TV numérique interactive |
| GB0420814D0 (en) * | 2004-09-18 | 2004-10-20 | Koninkl Philips Electronics Nv | Managing stored service information |
| WO2006035404A1 (en) * | 2004-09-30 | 2006-04-06 | Koninklijke Philips Electronics N.V. | Detection of new software image for download for digital/hybird tv during play mode |
| KR100785177B1 (ko) | 2006-05-08 | 2007-12-11 | 주식회사 대우일렉트로닉스 | Ａｔｓｃ의 아웃밴드를 이용한 데이터 저장 방법 및 그시스템 |
| EP1983744A1 (en) * | 2007-04-20 | 2008-10-22 | Thomson Licensing | Management methods of a video device and corresponding video device |
| US8634310B2 (en) | 2007-06-26 | 2014-01-21 | Qualcomm Incorporated | Methods and apparatus for improved program acquisition for use with MPEG-2 based systems |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5038211A (en) * | 1989-07-05 | 1991-08-06 | The Superguide Corporation | Method and apparatus for transmitting and receiving television program information |
| AU3970595A (en) * | 1994-10-27 | 1996-05-23 | Gemstar Development Corporation | Apparatus and methods for downloading recorder programming data in a video signal |
| KR19990008006A (ko) * | 1995-04-24 | 1999-01-25 | 잔 콘스탄턴 | 생산품을 원격적으로 주문할 수 있는 전자 텔레비젼 프로그램가이드 스케쥴 시스템 및 방법 |
| FR2743245B1 (fr) * | 1995-12-29 | 1998-01-23 | Thomson Multimedia Sa | Dispositif de demultiplexage |
| US5951639A (en) * | 1996-02-14 | 1999-09-14 | Powertv, Inc. | Multicast downloading of software and data modules and their compatibility requirements |
-
1997
- 1997-12-02 FR FR9715163A patent/FR2771884B1/fr not_active Expired - Fee Related
-
1998
- 1998-11-20 DE DE69805044T patent/DE69805044T3/de not_active Expired - Lifetime
- 1998-11-20 EP EP98402880A patent/EP0921681B2/en not_active Expired - Lifetime
- 1998-12-01 JP JP34164798A patent/JP4111255B2/ja not_active Expired - Fee Related
- 1998-12-01 CN CNB981230407A patent/CN1157948C/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CN1221285A (zh) | 1999-06-30 |
| EP0921681B2 (en) | 2006-01-25 |
| EP0921681A1 (en) | 1999-06-09 |
| FR2771884A1 (fr) | 1999-06-04 |
| EP0921681B1 (en) | 2002-04-24 |
| DE69805044T2 (de) | 2002-09-19 |
| CN1157948C (zh) | 2004-07-14 |
| DE69805044T3 (de) | 2006-08-03 |
| JPH11234633A (ja) | 1999-08-27 |
| FR2771884B1 (fr) | 1999-12-31 |
| DE69805044D1 (de) | 2002-05-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4035209B2 (ja) | サイクリックパケットデータ伝送システムの受信機 | |
| KR100641594B1 (ko) | 데이터 전달 제어 방법, 데이터 전송 방법, 데이터 송신장치, 수신 장치 | |
| JP3634425B2 (ja) | プログラム情報を送信する方法、装置および受信方法、装置 | |
| KR100336722B1 (ko) | 위성텔레비젼서비스에관한프로그램가이드를처리하는메모리장치 | |
| JP4111255B2 (ja) | デジタルテレビジョンシステムにおけるサービス情報を管理するための方法及び受信機 | |
| US7590111B1 (en) | Transmission of a multiplex signal comprising a carousel having a plurality of modules | |
| EP1405502A1 (en) | Receiver apparatus and method | |
| JP2002369094A (ja) | 番組情報取得システム、および取得方法 | |
| JP4156032B2 (ja) | ディジタルテレビジョン伝送システムにおけるデータの索引付け方法 | |
| JP4845257B2 (ja) | テレビジョンシステムにおいて展開する要約を伝送し処理する方法、並びに、かかるシステムの受信器及び送信器 | |
| JP2003502953A (ja) | デジタルテレビジョンシステムにおけるサービスリストの整合性を管理するための方法及び受信機 | |
| JP4689041B2 (ja) | アクセスを制限する方法、装置、レシーバ／デコーダ及び送信システム | |
| EP1288781A1 (en) | Receiving/storing device, transmission device, broadcasting system, receiving/storing method, transmission method, broadcasting method, programme and medium | |
| JP4378777B2 (ja) | 放送受信装置、放送受信方法 | |
| JP3671017B2 (ja) | デジタル放送受信方法および装置 | |
| EP1045564A1 (en) | Data source and data sink | |
| JP4184374B2 (ja) | 受信機及び受信方法 | |
| JP2001166941A (ja) | 情報処理装置および方法、並びに記録媒体 | |
| EP3648465B1 (en) | A method for generating a unique event identifier for an epg event | |
| KR100698276B1 (ko) | 디지털 수신기의 소프트웨어 업그레이드 방법 및 장치 | |
| JP2002527954A (ja) | テレビシステムにおけるサービスデータ管理方法及び装置 | |
| JP2000324071A (ja) | デジタルテレビジョンシステムにおけるサービス情報管理方法及び受信機 | |
| JP2002135219A (ja) | 放送局システム、受信機及び放送方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051125 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070521 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070529 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070829 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080304 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080401 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110418 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120418 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120418 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130418 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130418 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140418 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |