JPH07307928A

JPH07307928A - 文字放送受信装置およびその方法

Info

Publication number: JPH07307928A
Application number: JP7033770A
Authority: JP
Inventors: Shoichi Goto; 昌一後藤; Shuhei Taniguchi; 周平谷口; Hirotoshi Uehara; 宏敏上原; Keiya Miyoshi; 圭哉三好
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 1994-03-17
Filing date: 1995-02-22
Publication date: 1995-11-21
Anticipated expiration: 2018-12-02
Also published as: JP3473151B2

Abstract

(57)【要約】【目的】文字放送番組のデ−タ蓄積において、文字放
送番組のページデータを一つのファイルとしてファイル
管理することで、デ−タの蓄積／削減の管理を柔軟に行
なうことのできる、文字放送受信装置を提供することを
目的とする。【構成】文字放送を受信し、文字信号抜取り部３によ
り文字放送デ−タを抽出し、少なくとも一つの文字放送
番組の文字放送データを文字放送番組選別メモリにより
選別し、選別された文字放送データは、ファイル管理部
８によってメモリ管理部７が管理するデ−タ記憶部６
に、ページデータ毎に一つのファイルとして蓄積され
る。【効果】ファイル毎にメモリを割り当てるので、文字
放送データはリングメモリの様に強制的に削除されるこ
となく、ユ−ザが待ち時間なしに所望の文字放送番組を
視聴できる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、文字放送等のデータ放
送番組を視聴する際に、受信中の番組データを視聴する
だけでなく、番組データを効率良く蓄積することによ
り、任意の番組を自由に選択して見ることのできる文字
放送受信装置およびその方法に関するものである。

【０００２】

【従来の技術】近年、放送電波を利用して、文字や図形
からなるニュース、天気予報、株式市場などの文字図形
情報を、家庭のテレビジョン受像機の画面に映し出すこ
とのできる符号化伝送方式の文字放送が実用化され、こ
の符号化伝送方式の文字放送を受信する受信装置内蔵の
テレビジョン受像機も開発されている。

【０００３】以下に、従来の文字放送受信機について、
図面を参照しながら説明する。図１４は従来の文字放送
受信機の構成を示すものである。図１４において１４１
はシステム全体を制御するＣＰＵ、１４２は動作プログ
ラムを保持する記憶部である。ａはテレビの映像信号
で、１４３は映像信号ａから垂直帰線区間に重畳されて
いる文字放送データを抜き取るための文字信号抜き取り
部、１４４は文字信号抜き取り部１４３で抜き取った文
字放送データのデコードを行ない、表示するための文字
図形の表示データに展開するデコード部である。１４５
は文字信号抜き取り部１４３で抜き取った文字放送デー
タのみを蓄積しておくデータ記憶部、１４６はデータ記
憶部１４５の文字放送データの制御コードにより文字放
送データを管理するためのメモリ管理部、１４７はデコ
ード部１４４で文字図形に展開した表示データを保持す
る表示メモリ、１４８は表示メモリ１４７から表示デー
タを取り出しすためのメモリアドレス制御を行なう表示
制御部、１４９は表示メモリ１４７から文字放送データ
を読み出して実際に表示するためのテレビモニタであ
る。

【０００４】以上のように構成された文字放送受信装置
について、以下その動作について説明する。文字放送信
号抜き取り部１４３は入力された映像信号ａから、垂直
帰線消去区間１４Ｈ（２７７Ｈ）、１５Ｈ（２７８
Ｈ）、１６Ｈ（２７９Ｈ）、２１Ｈ（２８４Ｈ）の４つ
の伝送路に重畳されている文字信号を抜き取る。

【０００５】文字放送データは、４つの垂直帰線消去区
間の伝送路にそれぞれ２２バイトづつ重畳されている
（この２２バイトデータが１パケット）。

【０００６】文字放送に関する規格の詳細は「文字放送
技術ハンドブック、放送技術開発開発協議会、兼六間出
版」に記述されている。明細書で記載している「番
組」、「ページ」の定義は、この文字放送技術ハンドブ
ックに従う。

【０００７】ＣＰＵ１４１は、抜き取った文字放送デー
タをメモリ管理部１４６を介してデータ記憶部１４５に
蓄積する。また、ＣＰＵ１４１は、データ記憶部１４５
からメモリ管理部１４６を介して文字放送データを読み
出す。そしてデコード部１４４により、テレビモニタに
文字や図形を表示するための文字図形データ（表示デー
タ）に変換して、表示メモリ１４７に書き込む。表示制
御部１４８は文字図形データを表示メモリ１４７から読
み出してテレビモニタ１４９に表示する。

【０００８】ＣＰＵ１４１は、あらかじめ予約した文字
放送の番組を優先的にデータ記憶部１４５に蓄積する機
能を有する。さらにデータ記憶部１４５の残りメモリ容
量に応じて、逐次受信した文字放送データを格納する。

【０００９】以下に、図１５、図１６、図１７を用いて
メモリ管理部１４６によるデータ記憶部１４５の制御方
法について、図面を参照しながら説明する。図１５は、
データ記憶部１４５とメモリ管理部１４６の内部構成
で、逐次受信した文字放送データをパケット毎に格納す
るためのＮ個のメモリブロックと、メモリブロックを管
理するための位置テーブルから成る。位置テーブルは、
メモリブロックと１対１に対応しており、メモリブロッ
クに対してリングメモリを形成している。

【００１０】すなわち位置テーブル１は位置テーブル
２、位置テーブル２は位置テーブル３、そして位置テー
ブルＮは位置テーブル１を指している。逐次受信した文
字放送データは、リングメモリに書き込まれる。リング
メモリでは、受信した文字放送データがデータ記憶部１
４５のメモリ容量を越えると、古い文字放送データが格
納されているメモリブロックから順に新しいデータに更
新される。

【００１１】図１６ａは逐次受信したパケットデータを
実際にメモリブロックに格納する時のパケットフォーマ
ットで、番組、ページ情報とパケットデータから成る。
先にも述べたが、パケットデータは、逐次受信したもの
から格納する。この時、パケットデータは、文字放送番
組の番組の内容が連続しているわけではないので、パケ
ットフォーマットには番組、ページ情報が必要になる。

【００１２】図１６ｂはメモリブロックに逐次パケット
を格納した場合のメモリ内部図である。番組５の２ペー
ジ目をテレビモニタに表示する場合、メモリブロックの
番組とページ情報から、番組５の２ページ目を検索して
パケットデータをデコード部１４４によって、文字図形
に展開して表示メモリ１４７に転送する。

【００１３】このとき、もし番組５の２ページ目がデー
タ記憶部１４５に存在しない時、データが送られてくる
まで待つことになる。

【００１４】次に、予約した場合について図１７を用い
て述べる。図１７は予約を用いる場合のデータ記憶部１
４５とメモリ管理部１４６の内部構成で、図１５で示し
た内容に予約テーブルが付加されている。ユーザが文字
放送番組を予約すると、その番組が優先されてメモリに
格納される。予約テーブルは、予約した番組と優先割り
付けされたメモリブロックの番号からなる。図１７で
は、番組番号１００を予約する場合に、メモリブロック
１、２を確保し、メモリブロック１、２と残りのメモリ
ブロック３〜Ｎはそれぞれ別々のリングメモリを構成し
ていることを示している。

【００１５】予約されている文字放送番組をテレビモニ
タに表示する場合、予約用に確保したメモリから、ペー
ジを検索し、デコード部１４４によって、文字図形に展
開して表示メモリ１４７に転送する。

【００１６】以上のようにして、従来の文字放送受信機
では、文字放送番組を蓄積、表示していた。

【００１７】

【発明が解決しようとする課題】しかしながら従来装置
では、２つの問題点があった。一つは文字放送番組のメ
モリ管理が十分でないことである。これはメモリの使用
効率を上げるために、データ記憶部に対して、リングメ
モリ形式で管理し、また文字放送番組をファイルとして
管理するのではなく、文字放送番組を構成する要素であ
るパケット単位で管理していた。よって、任意の文字放
送番組のページにアクセスする場合には、そのページデ
ータのパケットを集めて表示していた。また、リングメ
モリでは、メモリが一杯になると、古いデータから順番
に消されるので、ページデータの有無の管理ができなか
った。

【００１８】もう一つはメモリ容量におけるコストの問
題である。例えば、ＮＨＫの文字放送番組をすべてメモ
リに格納する場合、少なくとも約１Ｍバイト必要とな
る。従来装置では、文字放送番組の蓄積に２００Ｋバイ
ト程度のメモリしか実装しておらず、１Ｍバイトのメモ
リを実装しようとするとコスト高となっていた。

【００１９】本発明は上記従来の問題点を解決するため
になされたもので、文字放送番組のメモリ管理問題とメ
モリ容量の問題を解決するために、文字放送番組の複数
ページを一つのファイルとしてファイル管理する。そし
て、圧縮して格納することにより、見かけ上のメモリ容
量を増やした。また、ファイル管理を行なう場合に、メ
モリの使用効率をリングメモリ形式と同じ程度にした、
文字放送受信装置及びその方法を提供することを目的と
する。

【００２０】

【課題を解決するための手段】この目的を達成するため
に本発明の文字放送受信装置は、文字放送を受信し、文
字放送データを抽出する信号抽出手段と、前記抽出され
た文字放送データのうち、少なくとも一つの文字放送番
組の文字放送データを選別する文字放送番組選別手段
と、前記選別された文字放送データを蓄積するためのデ
ータ記憶手段と、前記データ記憶手段内を小さなブロッ
クに分割する機能と、前記選択された文字放送データ毎
にそのデータサイズに応じて未使用ブロックからブロッ
クを獲得してデータ蓄積領域を形成する機能と、不必要
なブロックが発生した場合は未使用ブロックとして解放
する機能を持つメモリ管理手段と、前記文字放送データ
の「ページ」を一つのファイルとして管理するファイル
管理手段と、前記文字放送データの「ページ」を一つの
ファイルとして管理するファイル管理手段とファイルデ
ータを圧縮するためのデータ圧縮手段と、圧縮データを
伸長するためのデータ伸長手段とを備えた構成を有して
いる。

【００２１】

【作用】この構成によって、信号抽出手段によって抽出
された文字放送データに対し、ファイル管理手段では、
文字放送番組選別手段で選別された文字放送番組を、文
字放送番組の「ページ」単位を最小ファイル単位とし
て、データ記憶手段に格納する。メモリ管理手段は、デ
ータ記憶手段を小さなブロックに分割しており、ファイ
ル管理手段によってブロックに書き込む場合、ファイル
毎にデータサイズに応じてブロックを割り当て、そのブ
ロックの使用状況、リンク情報を管理する。

【００２２】また、ファイルの削除におけるブロックの
解放も行なう。ファイルは、任意にデータ圧縮手段によ
り圧縮、データ伸長手段により伸長することができる。

【００２３】このような特徴を有する本発明によれば、
文字放送受信装置のメモリ使用効率を最大限に高めるこ
とができる。また、ファイル管理を用いることで文字放
送番組の管理を柔軟に行なうことができる。

【００２４】

【実施例】

（実施例１）以下、図１、２、３を用いて、本発明の実
施例１について説明する。図１において、１はシステム
全体を制御するＣＰＵ、２は動作プログラムを保持する
記憶部である。３は映像信号ａから垂直帰線区間に重畳
されている文字放送データを抜き取るための文字信号抜
き取り部、４は文字信号抜き取り部３で抜き取った文字
放送データから、必要なデータを選別するための文字放
送番組選別部、５は文字放送番組選別部４で選別された
文字放送データのデコードを行ない、表示するための文
字図形の表示データに展開するデコード部である。６は
文字放送番組選別部４で選別された文字放送データを蓄
積しておくデータ記憶部、７はデータ記憶部６を小さな
ブロックに分割し、そのブロックの使用状況、リンク情
報を管理するためのメモリ管理部、８は文字放送番組の
「ページ」単位を最小ファイル単位として、ファイルの
作成、削除を管理するファイル管理部、９はデコード部
５で文字図形に展開した表示データを蓄えておく表示メ
モリ、１０は表示メモリ７から表示データの取り出しの
メモリアドレス制御を行なう表示制御部、１１は表示メ
モリ９から読み出して実際に表示するためのテレビモニ
タである。

【００２５】以上のように構成された文字放送受信装置
について、以下その動作について図２、図３を用いて説
明する。文字放送信号抜き取り部３は入力された映像信
号ａから、垂直帰線消去区間１４Ｈ、１５Ｈ、１６Ｈ、
２１Ｈの４つの伝送路に重畳されている文字信号を抜き
取る。文字放送データは、４つの垂直帰線消去区間の伝
送路にそれぞれ２２バイトづつ重畳されている（２２バ
イトデータを１パケットとする）。

【００２６】抜き取られた文字放送データは、文字放送
番組選別部４によって、あらかじめ指定している文字放
送番組のみ（例えば、ユーザが予約した番組）を選別す
る。選別された番組は、その番組の各ページ毎にファイ
ルを作成し、ファイル管理部８がページ単位で管理す
る。

【００２７】ファイル管理部８がファイルを作成する場
合、メモリ管理部７によりデータ記憶部６のメモリブロ
ックを一つ確保する。その後、ファイル管理部８が文字
放送データ（パケットデータ）の書き込みを行ない、メ
モリブロックの容量が一杯になれば、メモリ管理部７に
よって新しいメモリブロックを確保する。

【００２８】図２は、実際にメモリブロックに文字放送
データ（パケットデータ）の書き込みを行なう場合の説
明図である。メモリブロックへの書き込みはパケットデ
ータ単位で行なうので、メモリブロックの大きさはパケ
ットデータの倍数とする。

【００２９】本実施例では、一つのメモリブロックは１
２個のパケットデータを格納でき、本図は、３ページ分
のデータをデータ記憶部６に蓄積している状態を示す。
１ページ目のデータは１０パケット、２ページ目は６パ
ケット、３ページ目は１５パケットからなる。メモリ管
理部７は１、２ページのデータに対してそれぞれ１ブロ
ック獲得し、３ページのデータに対して２ブロック獲得
している。

【００３０】図３は、選別された文字放送データに対し
て、新規ファイルを作成してデータの書き込みを行なう
場合の説明図である。図３において、ファイル管理部８
のファイルテーブル７は、ファイル管理部８が作成した
ファイル名と、そのファイルを蓄積しているデータ記憶
部６の先頭メモリブロックを示すメモリブロックの番号
（メモリ管理テーブルの番号）から構成される。メモリ
管理部７のメモリ管理テーブルは、データ記憶部６のメ
モリブロックと１対１対応しており、メモリブロックの
使用状況とブロック間のリンク情報を格納する。メモリ
ブロックが未使用であれば「０」を格納すし、また使用
中のブロックであれば、リンクした次のブロック番号、
または最終のブロックであれば「−１」を格納する。

【００３１】図３（ａ）の場合、ファイル管理部８で
「ｎａｍｅ１」というページファイルを作成して、デー
タ記憶部６のメモリブロック１から蓄積している。図３
（ｂ）では、メモリブロック１のメモリ容量が一杯にな
ったので、新たに未使用のメモリブロック２を獲得す
る。そしてメモリ管理テーブルにはメモリブロックのリ
ンク情報として、メモリ管理テーブル１に次のブロック
を示す「２」を格納し、メモリ管理テーブル２にファイ
ルの最終ブロックを示す「−１」を格納する。他のペー
ジファイル「ｎａｍｅ２」、「ｎａｍｅ３」についても
同様である。

【００３２】以上により、すべての文字放送の番組デー
タをファイル単位で管理できるので、任意のファイルを
表示メモリ９に展開する際、所定の番組データへのアク
セスが、従来例のリングメモリ形式に比べて速くなる。

【００３３】さらに、文字放送データをファイル単位で
管理するので、データ記憶部６の容量が一杯になって
も、従来例で示したリングメモリ形式のように、強制的
に古い文字放送データから順番に削除されることがな
い。すなわちＣＰＵ１はファイル管理部８を用いて、文
字放送データの蓄積／管理ができる。ファイルの削除の
方法としては、現在ユーザが視聴していない文字放送番
組ファイルから削除する方法等が考えられる。

【００３４】（実施例２）以下、図４、図５、図６を用
いて、本発明の実施例２について説明する。図４は本実
施例２における全体のシステム構成図で、１〜７および
９〜１１は図１の構成と同様のものである。図１の構成
と異なるのは、ファイル管理部８にページ検索機能８ａ
が付加された点である。図５は本実施例２における、デ
ータ記憶部６のメモリ内部構成図である。以下その動作
について説明する。

【００３５】本実施例では、ファイル単位を文字放送の
「番組」とした場合について、図５を用いて説明する。
文字放送番組が、図３と同様に３ページから構成される
場合、メモリ管理部７は１ページ目を書き込む時、メモ
リブロックを１つ獲得する。そしてファイル管理部８に
よって実際にメモリに書き込む。２ページ目を書き込む
場合、メモリブロックはまだ、２パケット分書き込める
ので、２ページ目の始めの２パケットを書き込む。その
後、新たにメモリブロックを獲得して、残りの４パケッ
ト分を書き込む。３ページ目も同様である。複数のペー
ジを一つのファイルとすることにより、メモリブロック
中の未使用メモリを減らすことができる（メモリブロッ
クが1Kバイト前後の場合、ページファイル管理ではメモ
リの使用率は約７０％、番組ファイル管理では約９５
％）。

【００３６】図６は、図５に示した番組ファイルの内部
構成である。番組ファイルの１ページ目は、次のデータ
が番組管理データであることを示す番組データヘッダ
と、番組の総ページ数、番組データ長、番組形態など
の、番組管理データからなる。２ページ目は、次のデー
タが文字放送番組の１ページ目であることを示すページ
データヘッダと１ページ目の番組データからなり、３ペ
ージ目は、次のデ−タが文字放送番組の２ページ目であ
ることを示すページデータヘッダと２ページ目の番組デ
ータからなる。

【００３７】なおこの番組ファイルの１ページ目のデー
タは文字放送の番組管理情報であるので、ページデータ
として管理しなくてもよい（他の実施例における「ペー
ジ」ファイルも同様）。

【００３８】図４のページ検索機能８ａは、番組ファイ
ル中の番組データヘッダ、ページデータヘッダをページ
の先頭から検索することで、所定のページを検出するこ
とができる。

【００３９】以上により、ファイル管理を複数の「ペー
ジ」（この場合、文字放送番組単位）で行なうことによ
り、メモリの使用効率を高めることができる。また、所
定のページをアクセスする場合は、ページ検索機能８ａ
を用いればよい。

【００４０】（実施例３）以下、図７を用いて、本発明
の実施例３について説明する。図７は本実施例におい
て、図１のファイル管理部８が管理するファイル単位を
文字放送の「番組」とし、ファイル／ページ変換テーブ
ルを備えた場合のファイル管理を説明するための構成図
である。ファイル管理部８以外は、実施例１のシステム
構成図である図１と同じであるので省略する。以下その
動作について説明する。

【００４１】図７のファイル管理部８のファイルテーブ
ルは、図３のファイルテーブルと同様、ファイル管理部
８が管理するファイルと、そのファイルを蓄積している
データ記憶部６の先頭メモリブロックの番号（メモリ管
理テーブルの番号）と、さらに追加機能としてファイル
／ページ変換テーブルのあるアドレスを示す、変換テー
ブルアドレスから構成される。

【００４２】番組ファイルを作成する時、同時にそのフ
ァイルのファイル／ページ変換テーブルを作成し、ファ
イルテーブルの変換テーブルアドレスにファイル／ペー
ジ変換テーブルの先頭アドレスを格納する。そして、フ
ァイル管理部８がその番組ファイルの文字放送データを
メモリブロックに書き込む時、ページ番号とページのサ
イズを、ファイル／ページ変換テーブルに記録する。

【００４３】文字放送の番組データをメモリブロックに
書き込んだ後、所定のページを検索する場合、ページの
先頭から検索せずに、ファイル／ページ変換テーブルか
ら所定のページの先頭アドレスを得ることができるの
で、高速なファイルアクセスが可能になる。

【００４４】例えば、ページ番号３を検索する場合、ペ
ージ番号１とページ番号２のページサイズを加算するこ
とにより、ページ番号３のページデータの先頭アドレス
を得ることができる。

【００４５】以上により、ファイル管理部８が文字放送
の番組毎にファイルを管理し、ファイル／ページ変換テ
ーブルを持つことで、所定のページデータへの高速アク
セスが可能になる。

【００４６】なお、ファイル／ページ変換テーブル中の
ページサイズは、それぞれのページの先頭アドレスをあ
らかじめ計算しておいて格納しておいてもよいし、ペー
ジ番号を省略して、１ページ目からのページサイズもし
くは先頭アドレスのみを格納してもよい。

【００４７】（実施例４）以下、図８を用いて、本発明
の実施例４について説明する。図８は実施例３のファイ
ル管理部８が備えているファイル／ページ変換テーブル
を、番組ファイルに組み込んだ場合の構成図である。フ
ァイル管理部８以外は、実施例１のシステム構成図であ
る図１の１〜７および９〜１１と同じである。以下その
動作について説明する。

【００４８】図８のデータ記憶部６のメモリブロック中
のファイル／ページ変換テーブル用の領域は、番組ファ
イルを作成する時、その番組ファイルのページ数を番組
ページヘッダで調べて、あらかじめファイル／ページ変
換テーブルで使用するメモリサイズを、メモリブロック
内のファイルの先頭から確保したものである。

【００４９】そして、ファイル管理部８がその番組ファ
イルのパケットデータをメモリブロックに書き込む時、
ページデータヘッダを検出して、ページ番号とページサ
イズを、ファイル／ページ変換テーブルに記録する。

【００５０】この方法を用いると、ファイル管理部８で
ファイル／ページ変換テーブルを保持するための変換テ
ーブルアドレスをファイルテーブル中に設ける必要がな
い。さらに、ファイル／ページ変換テーブル用のファイ
ルを保持する必要がない。

【００５１】（実施例５）以下、図９を用いて、本発明
の実施例５について説明する。図９は本実施例５におけ
る全体のシステム構成図で、１〜１１は図１の構成と同
様のものである。図１の構成と異なるのは、ファイル管
理部８で管理している番組ファイルを圧縮するデータ圧
縮部１２、圧縮された番組ファイルを伸長するデータ伸
長部１３が追加された点である。また、ファイル管理部
８は実施例１〜４のどの機能を持っている場合でもよい
が、本実施例では実施例４の機能を持つファイル管理部
８について説明する。以下その動作について説明する。

【００５２】番組ファイルはテレビモニタに表示する場
合、デコード部５によって表示するための文字図形の表
示データに展開して、表示メモリ９に転送することによ
りテレビモニタ１１に表示するという動作は実施例１と
同じである。

【００５３】しかしながら、ファイル管理部８の番組フ
ァイルは、テレビモニタに表示する場合と番組更新が発
生した時以外に使用されない。そこで、番組ファイルは
番組ファイルの作成が終了した後、圧縮してデータ記憶
部６に格納することにより、メモリの使用効率を高める
ことができる。番組更新が発生した時は、再度番組ファ
イルを作成して圧縮する。

【００５４】受信した番組ファイル（非圧縮ファイル）
の蓄積が完了すると、データ圧縮部１２は番組ファイル
を圧縮し、圧縮ファイルとして蓄積して非圧縮ファイル
は削除する。

【００５５】圧縮ファイルとなっている番組ファイルを
参照する場合は、データ伸長部１３が圧縮データを伸長
した後、デコード部５によって表示するための文字図形
の表示データに展開して、表示メモリ９に転送すること
によりテレビモニタ１１に表示する。

【００５６】以上のように、番組ファイルを圧縮アルゴ
リズムを用いて圧縮して蓄積し、必要なファイルだけ伸
長することにより、文字放送データを蓄積する場合、メ
モリの使用効率を約４０％上げることができる。

【００５７】文字データ用の圧縮方式としては、ハフマ
ン符号化や”Ｌｅｍｐｅｌ―Ｚｉｖ（ＬＺ）符号化”な
どがある。データ圧縮方式に関しては、「データ圧縮技
術がパソコンと大型機に定着へ（日経エレクトロニクス
／１９９３．５．１０）」などに記述されている。本実
施例では、圧縮方式としてＬＺ符号化を使用している。
ＬＺ符号化は、最近では圧縮率の高い圧縮方式として利
用されることが多い。アルゴリズムとしては、過去の文
字列を辞書として登録し、この辞書内の文字列と現在の
文字列とを比較して、一致する文字列を見つけることに
より、圧縮を実現する。この方式は、辞書サイズが少な
くとも１Ｋバイト程度必要となる。

【００５８】文字放送番組の各「ページ」は、平均長が
１Ｋバイト程度なので、「ページ」単位で圧縮しても圧
縮率が良くない。番組単位の場合は平均１０Ｋバイト程
度なので圧縮率が向上する。

【００５９】（実施例６）以下、図１０、図１１を用い
て、本発明の実施例６について説明する。図１０は本実
施例６における全体のシステム構成図で、１〜１３は図
９の構成と同様のものである。図９と異なるのは、ファ
イル管理部８で管理しているファイルをまとめるファイ
ルアーカイブ部１４が付加された点である。以下その動
作について説明する。

【００６０】図１１は本実施例における複数のファイル
をまとめて圧縮してアーカイブ圧縮ファイルとし、また
アーカイブ圧縮ファイルから所定のファイルを伸長する
動作を説明するための図である。

【００６１】受信した文字放送データが予め定めるペー
ジファイルの蓄積が完了すると、ファイルアーカイブ部
１４はページファイルをまとめる。

【００６２】この時のアーカイブ方法は、ページ番号の
小さいページファイルから順に５ファイル揃った時点で
まとめる。まとめるファイル数は、文字放送番組の平均
ページ数（約１０ページ）、圧縮時の処理時間等から考
慮して５ファイルとする。なお、このファイル数は文字
放送番組毎に設定可能としてもよい。

【００６３】例えば、文字放送番組が８ページからなる
場合は、ファイルアーカイブ部１４は１〜５ページと６
〜８ページをそれぞれまとめて、一つのファイルとす
る。

【００６４】アーカイブファイルを圧縮する場合を、図
１１（ａ）、（ｂ）を用いて説明する。

【００６５】図１１（ａ）は文字放送番組が３ページか
らなる場合、ファイルアーカイブ部１４は、１〜３ペー
ジをまとめる。この時、ファイルアーカイブ部１４は、
まとめたファイル数とファイル名（例えば、ページ番号
名をページファイル名とする）と、それぞれの伸長時の
ファイルの大きさを、圧縮ファイル／ファイル変換テー
ブル１４ａに書き込む。そしてアーカイブファイルは、
データ圧縮部１２によってアーカイブ圧縮ファイルとし
て格納される。

【００６６】図１１（ｂ）は圧縮ファイル／ファイル変
換テーブル１４ａをファイル毎にアーカイブ圧縮ファイ
ル内に持つ場合である。この場合、データ圧縮部１２が
アーカイブファイルの圧縮開始時に、圧縮ファイル／フ
ァイル変換テーブル１４ｂをアーカイブ圧縮ファイル内
に書き込む。

【００６７】ファイルをまとめて圧縮するのは、実施例
５で述べたように、ＬＺ圧縮アルゴリズムの性質によ
る。すなわち文字放送番組の各「ページ」は、平均長が
１Ｋバイト程度なので、ファイル単位が「ページ」の場
合、一つのファイルだけを圧縮しても圧縮率が良くな
い。まとめて圧縮することにより、ＬＺ法での圧縮率が
「ページ」単位の場合より向上する。

【００６８】次にアーカイブ圧縮ファイルから、所定の
ファイルを伸長する場合を、図１１（ｃ）を用いて説明
する。図１１（ｃ）は図１１（ｂ）で説明したアーカイ
ブ圧縮ファイルから、３ページ目のファイルのみを伸長
した時の図である。

【００６９】圧縮ファイル／ファイル変換テーブル１４
ｂは、アーカイブ圧縮ファイル中の特定の圧縮ファイル
だけを伸長するために使用する。データ伸長部１３は、
ＬＺ圧縮アルゴリズムの性質上、伸長時はファイルの先
頭からしか伸長処理できない。

【００７０】よって特定のファイルを伸長する場合、逐
次伸長したデータサイズとの圧縮ファイル／ファイル変
換テーブル１４ｂ中の各ファイルサイズを比較しながら
伸長を行ない、特定ファイルのみの伸長データを保持
し、それ以外の伸長データは捨てる。

【００７１】まとめ中のある特定ファイルのみが必要に
なった場合は、他のファイルまでメモリ上に伸長する必
要がない。

【００７２】以上により、「ページ」単位のファイルを
まとめて圧縮／伸長を行なうことにより、圧縮率が高く
なる。また、文字放送の更新に伴う「ページ」毎のペー
ジデータの変更が番組単位のファイルと比較して容易に
なる。

【００７３】なお、圧縮ファイル名を工夫することによ
り、アーカイブ圧縮ファイル中のファイル名を圧縮ファ
イル／ファイル変換テーブルに記憶しなくても済む。

【００７４】例えば、文字放送の番組を小さいページ番
号のファイルから順にまとめる場合、図１１（ｄ）のよ
うにページ１から５までをアーカイブ圧縮したファイル
を「05.Z」、ページ６〜８までをアーカイブ圧縮したフ
ァイルを「08.Z」とする。この時まとめるファイル数は
最大５ファイルとする。それぞれのアーカイブ圧縮ファ
イル中の圧縮ファイル／ファイル変換テーブル１４ｃ、
ｄは、はじめにまとめたファイル数、そして小さいペー
ジからのファイルサイズを格納することにより、ファイ
ル名を格納しなくてもどのページのファイルサイズかが
分かる。「08.Z」の場合、ファイル名からこのまとめに
はページ６からページ８までが格納されていることが分
かる。そして「05.Z」と同様にページに対応したページ
ファイルのサイズが分かる。

【００７５】（実施例７）以下、図１２、図１３を用い
て、本発明の実施例７について説明する。本実施例では
実施例１〜６のファイル管理部８がディレクトリ構造を
持つ場合のファイル管理について述べる。この場合、フ
ァイル単位は文字放送番組の「ページ」とした。

【００７６】図１２（ｂ）はファイル管理部がディレク
トリ構造を持った場合の説明図である。ルートディレク
トリには、チャンネルディレクトリ層を設ける。チャン
ネル数が６個の場合、チャンネルディレクトリが６個存
在する。各チャンネルディレクトリには番組ディレクト
リ層を設ける。番組数が５０番組の場合、番組ディレク
トリが５０個存在する。さらに各番組ディレクトリには
ページファイルを作成する。

【００７７】また、番組ディレクトリ中には、ページフ
ァイルを図１０のファイルアーカイブ部１４でまとめて
データ圧縮部１２で圧縮した、アーカイブ圧縮ファイル
も入れる。

【００７８】図１２（ａ）はディレクトリ構造を持たな
い場合のファイル管理を示す。ディレクトリ構造を持た
ない場合、ルートディレクトリにすべてのファイルが存
在することになる。例えば、文字放送のチャンネル数が
６個、それぞれのチャンネルが番組数が５０番組持ち、
それぞれの番組が１０ページから構成されている場合、
６×５０×１０＝３０００個のファイルが存在する。こ
れらのファイルから一つのファイルを検索するにはかな
りの時間を要し、またファイル管理も複雑になる。

【００７９】以上により、各ページファイルは、ルート
ディレクトリ、チャンネルディレクトリ、番組ディレク
トリの３層ディレクトリ構造を設けることで、ページフ
ァイルの検索、すなわちチャンネル、番組番号、ページ
番号を指定する検索の高速化が図れ、ファイルの管理が
容易になる。

【００８０】また、ディレクトリ構造を持つことによ
り、メモリが一杯になった時など、ファイル管理部８で
管理しているファイルを削除する場合に、各番組ディレ
クトリ内のファイルを一つ以上残して、他のファイルを
削除することが容易にできる。

【００８１】図１２（ｂ）の場合では、チャンネル[1]
の番組[1]のページ[2]、チャンネル[n]の番組[4]のペー
ジ[5]から削除する。

【００８２】これにより、各番組ディレクトリが１ペー
ジファイル以上は存在する可能性が高くなり、ユーザが
見たい番組は待ち時間なしに少なくとも１ページ分は検
索して表示することができる。

【００８３】（実施例８）以下、図１０、図１３を用い
て、本発明の実施例８について説明する。本実施例で
は、図１０のシステムにおいて、マルチタスクＯＳ上で
ファイルの読み書きを行なう時のファイル管理部８、ア
ーカイブファイル管理部１４におけるファイルアクセス
に関して説明する。

【００８４】図１３において、１３１は文字放送番組選
別部４を介して得た文字放送データを、ファイル管理部
８によりページファイルを作成してデータを蓄積、およ
びデータの更新を行なうための蓄積タスク、１３２はフ
ァイルをファイルアーカイブ部１４でアーカイブした後
圧縮し、アーカイブ圧縮ファイルを作成する圧縮タス
ク、１３３はアーカイブ圧縮ファイルから一つ以上のフ
ァイルを伸長する伸長タスク、１３４はファイル管理部
８で管理しているファイルから、所定のファイルを検索
してデコード部５を介して表示メモリ９に展開するため
の検索タスクである。

【００８５】実施例６のデータ圧縮部１２と同様、蓄積
タスクはページファイル１〜５の蓄積が完了すると圧縮
タスク１３２にページファイル１〜５をまとめて圧縮す
るように依頼する。

【００８６】蓄積タスク１３１が依頼した圧縮タスク１
３２は、ページファイル１〜５をまとめて圧縮し、アー
カイブ圧縮ファイルを作成する。この時、ファイルアー
カイブ部１４を用いてまとめるのは、蓄積タスクでも圧
縮タスクのどちらでもよい。圧縮タスクは、圧縮完了と
同時にページファイル１〜５は削除する。圧縮に要する
時間は約0.5秒（4MIPSのCPUでの実測による）である。

【００８７】文字放送は、同一番組のページデータは約
２０秒に１ページづつ伝送している。

【００８８】この性質から、圧縮タスクがページファイ
ルをリードして圧縮ファイルを作成中に、蓄積タスクが
そのページファイルに対しての書き込み処理が不要とな
り、ファイル制御が容易になる。

【００８９】テレビモニタに文字放送を表示する場合、
検索タスク１３４ファイルは管理部８で管理している伸
長ファイルを検索する。伸長ファイルが存在しない場合
は、アーカイブ圧縮ファイルを検索する。アーカイブ圧
縮ファイルとして存在する場合は、そのファイルを伸長
タスク１３３により伸長してページファイルとして読み
出す。そしてデコード部５を介して表示メモリに書き込
む。

【００９０】次に、ページ更新が発生した場合、まず、
蓄積タスクは伸長ページファイルを検索する。ファイル
が存在しない場合は、新しくページファイルを作成して
ページデータを蓄積する。この時、アーカイブ圧縮ファ
イル中にそのファイルが存在しても新たにページファイ
ルを作成する。また、伸長ページファイルが存在する場
合は、上書きして書く。

【００９１】テレビモニタに文字放送を表示する場合、
検索タスクが伸長タスクにデータ伸長を依頼して、アー
カイブ圧縮ファイルからページファイルを伸長するとい
うことは先にも述べたが、ページファイルを伸長中に同
一ページファイルの更新が発生した場合について説明す
る。

【００９２】この場合、蓄積タスクは強制的にデータ伸
長中のページファイルを削除して、新しく更新ページフ
ァイルを作成する。伸長タスクはファイルにデータが書
けなくなるので、依頼元の検索タスクに伸長エラーを通
知する。検索タスクは、伸長タスクからエラーを通知さ
れると、更新データファイルの蓄積完了を待って、ファ
イルからデータを取り出す。

【００９３】以上により、上記のファイルアクセス制御
を用いることで、マルチタスクＯＳ上で一つファイルに
対して、複数のタスクからの同時書き込みまたは、読み
出し中のファイルへの書き込みが発生した場合の処理を
行なうことができる。

【００９４】これより、ファイルアクセス制御のために
ファイル編集用の一時ファイルを作成する必要がなくな
るので、文字放送データの蓄積のためのメモリ容量を減
少させることがなくなる。

【００９５】

【発明の効果】以上説明したように本発明では、小さな
メモリブロックに分割されたデータ記憶手段とメモリブ
ロックを管理するメモリ管理手段と、文字放送番組の複
数の「ページ」を一つのファイルとして管理するファイ
ル管理手段とデータ圧縮部、データ伸長部を設けること
により、ファイルアクセスに柔軟性ができ、自由に圧縮
ファイルを作成、および伸長ファイルの削除ができる。
またメモリの使用効率が大幅に向上するので、従来の約
７０％のメモリで廉価な文字放送受信装置及びその方法
を供給することができる。

【図面の簡単な説明】

【図１】本発明の第一の実施例における文字放送受信装
置の全体構成を示すブロック図

【図２】同実施例のデータ記憶部のデータ格納状態を示
すメモリ構成図

【図３】同実施例のデータ記憶部へのデータ格納手順を
示すメモリ構成図

【図４】本発明の第２の実施例における文字放送受信装
置の全体構成を示すブロック図

【図５】同実施例のデータ記憶部のデータ格納状態を示
すメモリ構成図

【図６】同実施例のデータ記憶部のデータ格納状態を示
すメモリ構成図

【図７】本発明の第３の実施例のデータ記憶部へのデー
タ格納手順を示すメモリ構成図

【図８】本発明の第４の実施例のデータ記憶部へのデー
タ格納手順を示すメモリ構成図

【図９】本発明の第５の実施例における文字放送受信装
置の全体構成を示すブロック図

【図１０】本発明の第６、７、８の実施例における文字
放送受信装置の全体構成を示すブロック図

【図１１】本発明の第６の実施例におけるアーカイブフ
ァイル管理を示すブロック図

【図１２】本発明の第７の実施例におけるファイル管理
におけるディレクトリ層を示すブロック図

【図１３】本発明の第８の実施例における文字放送受信
装置のソフトウェア構成を示すブロック図

【図１４】従来の文字放送受信装置の一例の全体構成図

【図１５】従来の文字放送受信装置のデータ記憶部の構
成図

【図１６】従来の文字放送受信装置のデータフォーマッ
ト図

【図１７】従来の文字放送受信装置のデータ記憶部の構
成図

【符号の説明】

１ＣＰＵ２記憶部３文字信号抜き取り部４文字放送番組選別部５デコード部６データ記憶部７メモリ管理部８ファイル管理部９表示メモリ１０表示制御部１１テレビモニタ

───────────────────────────────────────────────────── フロントページの続き (72)発明者三好圭哉大阪府門真市大字門真1006番地松下電器産業株式会社内

Claims

【特許請求の範囲】

【請求項１】文字放送を受信し、文字放送データを抽出
する信号抽出手段と、前記抽出された文字放送データのうち、少なくとも一つ
の文字放送番組の文字放送データを選別する文字放送番
組選別手段と、前記選別された文字放送データを蓄積す
るためのデータ記憶手段と、前記データ記憶手段内を小
さなブロックに分割する機能と、前記選択された文字放
送データ毎にそのデータサイズに応じて未使用ブロック
からブロックを獲得してデータ蓄積領域を形成する機能
と、不必要なブロックは未使用ブロックとして解放する
機能を持つメモリ管理手段と、前記文字放送データのペ
ージを一つのファイルとして管理するファイル管理手段
とを備えることを特徴とする文字放送受信装置。
【請求項２】前記ファイル管理手段が階層ディレクトリ
構造を持ち、ルートディレクトリはチャンネルディレク
トリ、前記チャンネルディレクトリは番組ディレクト
リ、前記番組ディレクトリはページファイルを持つこと
を特徴とする請求項１記載の文字放送受信装置。
【請求項３】前記ファイル管理手段が、所定のサイズだ
けファイル削除する場合、複数のページファイルを持つ
番組ディレクトリから優先してファイルを削除し、前記
番組ディレクトリ中の少なくとも一つの前記ファイルは
残すファイル削除手段を持つことを特徴とする請求項２
記載の文字放送受信装置。
【請求項４】前記データ記憶手段内の文字放送データの
蓄積に際し、前記ファイル管理手段が、さらに文字放送
番組のページデータを一つ以上組み合わせることにより
一つのファイルとして管理する機能と、前記ファイルか
ら所定のページデータを検索する機能を備えることを特
徴とする請求項１、２または請求項３記載の文字放送受
信装置。
【請求項５】前記ファイル管理手段が、ファイル内の所
定のページデータを検索する代りに、ファイル内のペー
ジ開始位置情報を持つ、ファイルからページに変換する
管理テーブルを備えることを特徴とする請求項４記載の
文字放送受信装置。
【請求項６】前記ファイル管理手段が、ファイルと前記
ファイルからページに変換する管理テーブルとを一つの
ファイルとして蓄積、管理することを特徴とする請求項
５記載の文字放送受信装置。
【請求項７】ファイルを圧縮して圧縮ファイルを作成す
るデータ圧縮手段と、圧縮されたファイルを伸長して伸
長ファイルを作成するデータ伸長手段とを備えることを
特徴とする請求項１〜６のいづれかに記載の文字放送受
信装置。
【請求項８】前記データ圧縮手段がファイルデータの圧
縮完了と同時に前記ファイルデータを消去し、データ伸
長手段が圧縮ファイルデータを伸長完了と同時に前記圧
縮ファイルデータを消去することを特徴とする請求項７
記載の文字放送受信装置。
【請求項９】前記ファイル管理手段が、文字放送の番組
を一つのファイルとして管理する機能を備えることを特
徴とする請求項４、５、６、７または請求項８記載の文
字放送受信装置。
【請求項１０】前記ファイル管理手段で管理される一つ
以上のファイルを、まとめるファイルアーカイブ手段を
備え、前記ファイルアーカイブ手段でまとめたアーカイ
ブファイルを前記データ圧縮手段により圧縮することを
特徴とする請求項７、８または請求項９記載の文字放送
受信装置。
【請求項１１】前記ファイルアーカイブ手段が、アーカ
イブファイルを圧縮した圧縮ファイル内の各ファイルの
開始位置情報を管理する、圧縮ファイルと圧縮前ファイ
ルを対応づける管理テーブルを持つことを特徴とする請
求項１０記載の文字放送受信装置。
【請求項１２】前記データ圧縮部がアーカイブファイル
を圧縮する時、前記圧縮ファイルと圧縮前ファイルを対
応づける管理テーブルと前記アーカイブファイルの圧縮
データを一つのファイルとして蓄積、管理することを特
徴とする請求項１０記載の文字放送受信装置。
【請求項１３】前記データ伸長手段が、アーカイブファ
イルを圧縮した圧縮ファイルから、前記ファイルアーカ
イブ手段内もしくは圧縮ファイル内に存在する、圧縮フ
ァイルと圧縮前ファイルを対応づける管理テーブルを用
いて指定した少なくとも一つのファイルを伸長すること
を特徴とする請求項１１または１２記載の文字放送受信
装置。
【請求項１４】文字放送を受信し、文字放送データを抽
出し、前記抽出された前記文字放送データのうち、少な
くとも一つの文字放送番組の文字放送データを選別し、
前記選別された文字放送データを少なくとも１つ以上の
ブロックに蓄積し、前記蓄積された文字放送データのペ
ージを一つのファイルとして管理することを特徴とする
文字放送受信方法。
【請求項１５】前記選択された文字放送デ−タを少なく
とも１つ以上のブロックに蓄積する際に、前記選択され
た文字放送データ毎にそのデータサイズに応じて未使用
ブロックからブロックを獲得してデータ蓄積領域を形成
し、不必要なブロックは未使用ブロックとして解放する
ことを特徴とする請求項１４記載の文字放送受信方法。
【請求項１６】ファイルを管理する際に階層ディレクト
リ構造を持たせ、ルートディレクトリにはチャンネルデ
ィレクトリ、前記チャンネルディレクトリには番組ディ
レクトリ、前記番組ディレクトリにはページファイルを
持たせることを特徴とする請求項１４記載の文字放送受
信方法。
【請求項１７】所定のサイズだけファイル削除する場
合、複数のページファイルを持つ番組ディレクトリから
優先してファイルを削除し、前記番組ディレクトリ中の
少なくとも一つのファイルを残すことを特徴とする請求
項１６記載の文字放送受信方法。
【請求項１８】ファイルを圧縮、伸長することを特徴と
する請求項１４、１５、１６または請求項１７記載の文
字放送受信方法。
【請求項１９】マルチタスク動作が可能なオペレーティ
ングシステムを用いて、文字放送データをファイルとし
て蓄積、更新する蓄積タスクと、前記ファイルを検索し
て読み出す検索タスクと、一つ以上の前記ファイルをま
とめて圧縮して圧縮ファイルをつくる圧縮タスクと、前
記圧縮ファイルを伸長して一つ以上の前記ファイルを作
る伸長タスクとを備えて文字放送データを前記ファイル
に読み書きする場合、前記圧縮タスクの起動権を前記蓄
積タスクに限定し、前記伸長タスクの起動権を前記検索
タスクに限定して文字放送データファイルを蓄積、検索
することを特徴とする請求項１８記載の文字放送受信方
法。
【請求項２０】伸長タスクが圧縮ファイルから圧縮デー
タを伸長中、蓄積タスクによる更新が発生して、伸長中
の同一ファイルに書き込みが生じた場合、前者の書き込
みはエラーとすることを特徴とする請求項１９記載の文
字放送受信方法。