(57)【特許請求の範囲】
【請求項１】
データ放送局が、互いにデータ名が同一でありかつ、時間経過に応じてその内容が更新される一連のデータを予め定められた時間間隔で配信しており、かかるデータ放送局により配信されるデータに対して所定の処理を実行する端末装置であって、
前記データ放送局により配信されるデータを受信する受信部と、
前記受信部により受信されたデータの管理情報を作成し管理する管理部と、
前記管理部により管理情報が作成されたデータを記憶する記憶装置と、
前記記憶装置に記憶されたデータのうち、ユーザにより要求されるデータを出力する参照部とを備え、
前記管理情報は、前記記憶装置に記憶されたデータを、当該記憶装置から削除するか否かを判断するための保存係数を含み、
前記管理部は、
前記記憶装置に記憶されたデータの保存係数を一定時間毎に減少させると共に、前記参照部が出力したデータの保存係数を増加させ、
前記保存係数が所定値まで減少した時に、対応するデータを前記記憶装置から削除し、
前記記憶装置に記憶された古いデータとデータ名が同一であり、かつ当該記憶装置内のデータの内容を更新した新しいデータが入力された際、前記記憶装置から古いデータを削除し、
入力された新しいデータの管理情報として、前記記憶装置から削除された古いデータの管理情報を使用し、
前記記憶装置に記憶された古いデータとデータ名が同一でない新しいデータが入力された際、前記入力された新しいデータの管理情報を新たに作成する、端末装置。
【請求項２】
前記管理部はさらに、
ユーザにより要求されたデータが前記記憶装置に格納されていない場合には、そのデータについて仮の管理情報を前もって作成し、
ユーザにより要求されたデータが入力された時点で、入力されたデータの管理情報として、対応する仮の管理情報を継承させることを特徴とする、請求項１に記載の端末装置。
【請求項３】
前記管理部はさらに、
ユーザにより要求されるデータと関連性を持つ関連データが前記記憶装置内に存在するか否かを判断し、
前記関連データが存在する場合には、当該関連データの保存係数を増加させる、請求項２に記載の端末装置。
【請求項４】
前記管理部は、前記関連データの保存係数を、前記ユーザにより要求されたデータとの関連性の強さに基づいて増加させる、請求項３に記載の端末装置。
【請求項５】
前記管理部はさらに、
前記記憶装置内に前記関連データが存在しない場合には、当該関連データのために仮の管理情報を作成し、
前記仮の管理情報が作成された関連データが入力された時点で、当該仮の管理情報を、当該関連データの管理情報として使用する、請求項３に記載の端末装置。
【請求項６】
前記管理部はさらに、前記参照部が出力中のデータまたは関連データとデータ名が同一であり、かつ当該データまたは当該関連データの内容を更新した新しいデータが入力された時、入力された新しいデータを前記参照部に出力する、請求項３に記載の端末装置。
【請求項７】
前記管理部はさらに、入力された新しいデータを前記参照部に出力した後に一定時間が経過すると、前記新しいデータの直前に出力されていたデータを前記参照部に再出力する、請求項６に記載の端末装置。
【請求項８】
前記管理部はさらに、前記ユーザによる設定に基づいて、新たに入力されたデータを、前記参照部に出力しない、請求項６に記載の端末装置。
【請求項９】
前記データ放送局により配信されるデータは、所定の符号化形式で符号化されており、
前記受信部が受信したデータを前記符号化形式に従ってデコードして、前記管理部に出力するデコード部をさらに備え、
前記デコード部および前記参照部は互いに独立して動作することを特徴とする、請求項１に記載の端末装置。
【請求項１０】
前記管理部は、前記記憶装置にデータを格納する毎に、前記データを格納したことを表す信号を生成して、前記参照部に出力する、請求項１に記載の端末装置。
【請求項１１】
前記管理部は、前記記憶装置に格納されているデータが前記参照部により出力されている間には、前記データを前記記憶装置から削除しない、請求項１に記載の端末装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、端末装置に関し、より特定的には、遠隔に設置されたデータ放送局により配信されるマルチメディアデータに対して、所定の処理を実行する端末装置に関する。
【０００２】
【従来の技術】
従来より、マルチメディアデータを受信し表示する端末装置が開発されている。端末装置は、以下のようにしてマルチメディアデータを取得する。マルチメディアデータはＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）サーバに予め蓄積されている。端末装置は、ユーザの指示に従って、インターネットを通じてこのＷＷＷサーバにアクセスして、必要なマルチメディアデータを検索し取り出す。従来、マルチメディアデータの取得方法の主流は、いわゆるプル型であり、ユーザがデータを引き出す方法であった。
【０００３】
プル型に対し、近年、ユーザにデータを押し出す方法（いわゆるプッシュ型）、つまり放送形式によるマルチメディアデータ配信の需要が増しつつある。例えば、欧州におけるＥＵＲＥＫＡ−１４７プロジェクトのＤＡＢ（ＤｉｇｉｔａｌＡｕｄｉｏ  Ｂｒｏａｄｃａｓｔｉｎｇ）によるデータ配信はまさに、このプッシュ型に該当する。このマルチメディアデータ配信において、ユーザは、端末装置に対し、必要なデータを配信しているチャンネルを指示する。端末装置は、指示されたチャンネルを介して、データを自動的に受信し表示する。これによって、端末装置のユーザは、従来のテレビやラジオと同様の操作感で容易にマルチメディアデータを取得できる。このマルチメディアデータ配信は、必要なデータを検索し取り出す処理を実行しなくても良い、という利点を有している。
【０００４】
このマルチメディアデータ配信では、放送局側は、リアルタイムにユーザ側（端末装置）の要求を受け取ることができない。その結果、放送されるマルチメディアデータの内容をユーザ側で制御することが難しくなる。具体例を挙げると、ユーザ側は、既に配信されたマルチメディアデータを取得したいと考えても、その要求を放送局側に送信することができないため、当該マルチメディアデータを取得することは難しい。このような問題を解決し、ユーザ側でのマルチメディアデータの参照に自由度を持たせるための一つの方法として、端末装置にマルチメディアデータを蓄積し管理するための記憶装置（典型的には、ハードディスクドライブ）を設置することが考えられる。これによって、端末装置は、放送局側から配信されてくるマルチメディアデータを記憶装置に継続的に蓄積しておけば、例えば、既に配信されたマルチメディアデータをこの記憶装置から取得できるようになる。これによって、ユーザ側におけるマルチメディアデータの参照の自由度が向上する。
【０００５】
【発明が解決しようとする課題】
ところで、マルチメディアデータは、大きなデータ量を有する。端末装置がマルチメディアデータを継続的に蓄積するためには、十分に大きな容量の記憶装置が端末装置に備えられる必要がある。ところが、端末装置が大容量の記憶装置を備えることは、そのスペース及びコストの制約により難しい。そのため、端末装置は、限られた容量の記憶装置を有効利用する必要がある。このような有効利用の一つの方法として、記憶装置は、例えば、端末装置が常に最新のマルチメディアデータを取得できるように、受信したマルチメディアデータを時系列に蓄積し削除するという方法がある。しかしながら、この方法では、ユーザが頻繁に参照するマルチメディアデータも時系列に削除されるという問題点があった。
【０００６】
それゆえに、本発明は、ユーザが頻繁に参照するマルチメディアデータを削除することなく、記憶装置の容量を有効利用できる端末装置を提供することを目的とする。
【０００７】
【課題を解決するための手段および発明の効果】
第１の発明は、データ放送局が、互いにデータ名が同一でありかつ、時間経過に応じてその内容が更新される一連のデータを予め定められた時間間隔で配信しており、かかるデータ放送局により配信されるデータに対して所定の処理を実行する端末装置であって、
データ放送局により配信されるデータを受信する受信部と、
受信部により受信されたデータの管理情報を作成し管理する管理部と、
管理部により管理情報が作成されたデータを記憶する記憶装置と、
記憶装置に記憶されたデータのうち、ユーザにより要求されるデータを出力する参照部とを備え、
管理情報は、記憶装置に記憶されたデータを、記憶装置から削除するか否かを判断するための保存係数を含み、
管理部は、
記憶装置に記憶されたデータの保存係数を一定時間毎に減少させると共に、参照部が出力したデータの保存係数を増加させ、
保存係数が所定値まで減少した時に、対応するデータを記憶装置から削除し、
記憶装置に記憶された古いデータとデータ名が同一であり、かつ記憶装置内のデータの内容を更新した新しいデータが入力された際、記憶装置から古いデータを削除し、
入力された新しいデータの管理情報として、記憶装置から削除された古いデータの管理情報を使用し、
記憶装置に記憶された古いデータとデータ名が同一でない新しいデータが入力された際、前記入力された新しいデータの管理情報を新たに作成することを特徴とする。
【０００８】
第１の発明では、管理部は、ユーザによるマルチメディアデータの参照頻度に基づいて、保存係数を増減させる。つまり、マルチメディアデータが全く参照されなければ、その保存係数はすぐに所定値まで減少する。一方、マルチメディアデータが頻繁に参照されれば、その保存係数は増加する。管理部は、保存係数が所定値になると、対応するマルチメディアデータを記憶装置内から削除する。したがって、参照頻度が小さいマルチメディアデータは、優先的に記憶装置から削除され、逆に、参照頻度が大きいものは、記憶装置に長期間保存される。以上のように第１の発明によれば、ユーザにとって好ましい状態に、記憶装置内のマルチメディアデータをカスタマイズすることができる。また、参照頻度が小さいものはすぐに削除されるので、記憶装置が必要とする容量を抑制することができる。
【０００９】
また、第１の発明では、端末装置には、互いにデータ名が同一であるマルチメディアデータが配信される。管理部は、新しいマルチメディアデータの管理情報として、古いものの管理情報を継承させる。この古いマルチメディアデータが、ユーザにより頻繁に参照されていた場合には、その保存係数は大きな値を有する。したがって、新しいマルチメディアデータは、その保存係数が最初から大きな値に設定されることとなるため、記憶装置から削除されにくくなる。つまり、記憶装置内には、常に、ユーザの関心が高くかつ新しいマルチメディアデータが格納される。これによって、記憶装置内のマルチメディアデータはユーザにとって、さらに好ましい状態にカスタマイズされることとなる。
【００１０】
第２の発明は第１の発明に従属しており、管理部はさらに、
ユーザにより要求されたデータが記憶装置に格納されていない場合には、そのデータについて仮の管理情報を前もって作成し、
ユーザにより要求されたデータが自身に入力された時点で、入力されたデータの管理情報として、対応する仮の管理情報を継承させることを特徴とする。
【００１１】
ユーザは、記憶装置に未格納のマルチメディアデータを管理部に対して要求する場合がある。このような要求されたが未格納であるマルチメディアデータは、将来的に配信され記憶装置に格納される。第２の発明では、管理部は、たとえ要求されたマルチメディアデータが記憶装置に未格納であっても、そのマルチメディアデータのために仮の管理情報を作成しておく。管理部は、かかるマルチメディアデータが記憶装置に格納された時点で、仮の管理情報を引き継ぐような管理情報を作成する。つまり、管理部は、最初から大きな値の保存係数を作成することができる。したがって、このようなマルチメディアデータは、記憶装置から削除されにくくなる。これによって、記憶装置内のマルチメディアデータはユーザにとって、さらに好ましい状態にカスタマイズされることとなる。
【００１２】
第３の発明は第２の発明に従属しており、管理部はさらに、
ユーザにより要求されるデータと関連性を持つ関連データが記憶装置内に存在するか否かを判断し、
関連データが存在する場合には、関連データの保存係数を増加させることを特徴とする。
【００１３】
第３の発明では、データ放送局は、端末装置に対して、互いに関連性を有するマルチメディアデータを配信する。管理部は、参照部により要求されたマルチメディアデータの保存係数だけでなく、それと関連性を有するマルチメディアデータの保存係数も増加させる。そのため、関連マルチメディアデータもまた、記憶装置内に長時間保存されることとなる。これによって、記憶装置内のマルチメディアデータはユーザにとって、さらに好ましい状態にカスタマイズされることとなる。
【００１６】
第４の発明は第３の発明に従属しており、管理部は、関連データの保存係数を、ユーザにより要求されたデータとの関連性の強さに基づいて増加させることを特徴とする。
【００１７】
検索された各関連マルチメディアデータは、参照部に対して一定の関連性の強さを持っているとは限らない。そのため、関連マルチメディアデータの保存係数を一様に増加させると、要求されたマルチメディアデータと関連性の弱い関連マルチメディアデータが記憶装置に長時間格納されたままとなる。そこで、第４の発明によれば、関連マルチメディアデータの保存係数は、参照部により要求されたものとの関連性の強さに基づいて増加する。そのため、要求されたマルチメディアデータを中心として、関連性が強いマルチメディアデータほど記憶装置に長時間残りやすくなる。これによって、記憶装置内のマルチメディアデータはユーザにとって、さらに好ましい状態にカスタマイズされることとなる。
【００１８】
第５の発明は第３の発明に従属しており、管理部はさらに、
記憶装置内に関連データが存在しない場合には、関連データのために仮の管理情報を作成し、
仮の管理情報が作成された関連データが入力された時点で、仮の管理情報を、関連データの管理情報として使用することを特徴とする。
【００１９】
管理部は、記憶装置に未格納のものを、関連マルチメディアデータとして選択する場合がある。このような未格納の関連マルチメディアデータは、将来的に配信され記憶装置に格納される。第５の発明では、管理部は、たとえ選択した関連マルチメディアデータが未格納であっても、このマルチメディアデータのために仮の管理情報を作成しておく。管理部は、その関連マルチメディアデータの格納時に、仮の管理情報を引き継ぐような管理情報を作成する。つまり、管理部は、最初から大きな値の保存係数を作成することができる。したがって、この関連マルチメディアデータは、記憶装置から削除されにくくなる。これによって、記憶装置内のマルチメディアデータはユーザにとって、さらに好ましい状態にカスタマイズされることとなる。
【００２０】
第６の発明は第３の発明に従属しており、管理部はさらに、参照部が出力中のデータまたは関連データとデータ名が同一であり、かつデータまたは関連データの内容を更新した新しいデータが入力された時、入力された新しいデータを参照部に出力することを特徴とする。
【００２１】
第６の発明によれば、管理部は、データ名が同一である新しいマルチメディアデータが入力されるとすぐに、参照部に出力する。したがって、参照部は、管理部に要求することなく、ユーザの関心が高くかつ新しいマルチメディアデータをリアルタイムに管理部から取得し、ユーザに参照させることができる。これによって、端末装置の使い勝手をよくすることができる。
【００２２】
第７の発明は第６の発明に従属しており、管理部はさらに、入力された新しいデータを参照部に出力した後に一定時間が経過すると、新しいデータの直前に出力されていたデータを参照部に再出力することを特徴とする。
【００２３】
第７の発明によれば、管理部は、新しいマルチメディアデータを参照部に出力した後に一定時間経過すると、その直前にユーザが参照していたマルチメディアデータを参照部に再出力する。これによって、新しいマルチメディアデータの入力直前に参照されていたマルチメディアデータは、ユーザにより再度参照される。この一連の処理は、管理部により自動的に行われるので、ユーザに対して特別の操作を要求しない。これによって、端末装置の使い勝手をさらに向上させることができる。
【００２４】
第８の発明は第６の発明に従属しており、管理部はさらに、ユーザによる設定に基づいて、新たに入力されたデータを参照部に出力しないことを特徴とする。
【００２５】
第６の発明の参照部は、管理部から順次継続的に出力されるマルチメディアデータをユーザに参照させる。つまり、マルチメディアデータが参照部に入力される度に、ユーザにより参照されるマルチメディアデータが切り替わる。第８の発明によれば、管理部は、参照部の指示に基づいて、新しく入力されたマルチメディアデータの出力を停止する。これによって、参照部は、必要に応じてマルチメディアデータの出力停止を管理部に対して要求することができる。これによって、参照部は順次継続的に入力されるものの内、特定のマルチメディアデータを長時間、ユーザに参照させることができる。これによって、端末装置の使い勝手をさらに向上させることができる。
【００２６】
第９の発明は第１の発明に従属しており、データ放送局により配信されるデータは、所定の符号化形式で符号化されており、
受信部が受信したデータを符号化形式に従ってデコードして、管理部に出力するデコード部をさらに備え、
デコード部および参照部は互いに独立して動作することを特徴とする。
【００２７】
第９の発明では、デコード部及び参照部が互いに独立して動作するので、参照部が、つまりユーザがマルチメディアデータを記憶装置に格納するための操作を特別に実行する必要が無い。デコード部が配信されたマルチメディアデータを継続的にデコードすることにより、マルチメディアデータを記憶装置に自動的に格納することができる。
【００２８】
第１０の発明は第１の発明に従属しており、管理部は、記憶装置にデータを格納する毎に、データを格納したことを表す信号を生成して、参照部に出力することを特徴とする。
【００２９】
第１０の発明では、参照部には、記憶装置にマルチメディアデータが格納された旨が通知されるため、ユーザは、マルチメディアデータが記憶装置に格納されたことをリアルタイムに知ることができるようになる。
【００３０】
第１１の発明は第１の発明に従属しており、管理部は、記憶装置に格納されているデータが参照部により出力されている間には、データを記憶装置から削除しないことを特徴とする。
【００３１】
第１１の発明では、マルチメディアデータは、参照部によって表示されている間には、管理部によって記憶装置から削除されない。これによって、参照部が表示するマルチメディアデータは、勝手に切り替わることはなくなる。
【００３５】
【発明の実施の形態】
図１は、本発明の一実施形態に係る端末装置１の構成を示すブロック図である。図１において、データ放送局２は端末装置１の遠隔に設置される。データ放送局２は、マルチメディアデータが少なくとも多重化された信号（以下、多重化信号と称す）を放送形式により送信する。マルチメディアデータは、テキストデータ、静止画データ、動画データおよび音声データのいずれか２つ以上のデータの組み合わせと定義される。マルチメディアデータは、典型的には、Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（以下、ＨＴＭＬと略す）で作成される。各マルチメディアデータには、その作成時点でデータ名が付けられている。ＨＴＭＬのデータ名は、典型的には、ｈｔｍｌという固有の拡張子を含む。また、マルチメディアデータは、所定の符号化方式でエンコードされる。なお、マルチメディアデータは単にデータ名のみで記載する場合がある。例えば、Ｔｏｐｉｃ．ｈｔｍｌというデータ名のマルチメディアデータは、単にＴｏｐｉｃ．ｈｔｍｌと記載される場合がある。
【００３６】
データ放送局２は、図２に示すように、ある時間帯ＴＢ1 に、Ｔｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌ、Ｓｕｂ２．ｈｔｍｌ、Ｓｕｂ０．ｈｔｍｌ、ｘｘｘ．ｈｔｍｌ、…を順番に配信する。さらに、時間帯ＴＢ1 よりも後の時間帯ＴＢ2 に、Ｔｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌ、Ｓｕｂ２．ｈｔｍｌ、Ｓｕｂ０．ｈｔｍｌ、ｘｘｘ．ｈｔｍｌ、…が順番に配信される。つまり、同じデータ名のマルチメディアデータが時間をおいて配信される。ただし、同名のマルチメディアデータに含まれるテキストや画像等は、互いに関連性を有するが、時間の経過に伴って更新される。例えば、天気図を表す画像や、天気予報を表すテキストは、時間が経過すると更新される。しかし、この画像やテキストは、一定の場所の天気図や天気予報を表す。このように、本実施形態では、時間をおいて、互いに同一性を持つマルチメディアデータが配信される。この同一性を持つマルチメディアデータとは、互いに相違するテキストや画像等を含んでいるが、それぞれの性質や属性が同一であると端末装置１により判断されるものを意味する。詳細は後述するが、端末装置１は、この同一性の判断を、マルチメディアデータに付されたデータ名に基づいて行う。
【００３７】
端末装置１は、マルチメディアデータに対して下記の処理を実行する。端末装置１は、受信した多重化信号からマルチメディアデータを分離する。マルチメディアデータはエンコードされているので、端末装置１は、分離されたマルチメディアデータをデコードする。端末装置１は、マルチメディアデータを記憶すると共に、必要に応じて各マルチメディアデータを出力する。出力されたマルチメディアデータのテキストや画像は、端末装置１のユーザにより参照される。端末装置１は、以上の処理を実行すべく、図１のように、チューナー１１と、デコーダ１２と、内部にテーブル１３を保持するファイルマネージャ１４と、記憶装置１５と、ブラウザ１６とを備える。なお、チューナー１１、デコーダ１２、ファイルマネージャ１４、記憶装置１５およびブラウザ１６は、請求項における受信部、デコード部、管理部、記憶装置および参照部の一例である。
【００３８】
チューナー１１は、データ放送局２により配信された多重化信号を受信して、端末装置１の内部に取り込む。チューナー１１はさらに、受信した多重化信号から、エンコードされたマルチメディアデータを分離して、分離したマルチメディアデータをデコーダ１２に出力する。デコーダ１２は、入力されたマルチメディアデータを所定の符号化形式に従ってデコードし、デコードしたマルチメディアデータをファイルマネージャ１４に出力する。ファイルマネージャ１４は、入力されたマルチメディアデータをファイル単位で記憶装置１５に格納すると共に、各マルチメディアデータの管理情報をテーブル１３に登録して管理する。ファイルマネージャ１４はさらに、ブラウザ１６により要求されたマルチメディアデータを記憶装置１５から取り出して、ブラウザ１６に出力する。ブラウザ１６は、ユーザと端末装置１とのインターフェイスであり、ユーザにより操作される。ユーザは、ブラウザ１６を操作して、マルチメディアデータのデータ名（参照ラベル）を入力して、そのマルチメディアデータの参照を要求する。ブラウザ１６は、ユーザの入力に応答して、参照要求という信号を生成する。参照要求は、ユーザが参照したいマルチメディアデータをファイルマネージャ１４に要求するための信号である。ブラウザ１６は、ファイルマネージャ１４により取り出されたマルチメディアデータを受け取り、端末装置１のモニタ（図示せず）にテキストや画像として表示させる。また、ブラウザ１６は、マルチメディアデータが音声データを含んでいる場合には、スピーカ（図示せず）から音声を出力させる。
【００３９】
管理情報について説明する。管理情報は、参照ラベル、格納時刻、ファイル名、参照フラグ、未参照時間、および保存係数の組み合わせである。参照ラベル、格納時刻、ファイル名、参照フラグ、未参照時間、および保存係数はそれぞれ、図３（ａ）に示すテーブル１３において、予め定められた領域に登録される。テーブル１３の１列分（紙面の上下方向１列分）が、１ファイル分のマルチメディアデータの管理情報である。
【００４０】
参照ラベルには、対応するマルチメディアデータに予め付けられているデータ名が用いられる。
格納時刻は、対応するマルチメディアデータが記憶装置１５に格納された時刻である。
ファイル名は、ファイルマネージャ１４によりマルチメディアデータに付される。ファイル名は、マルチメディアデータ相互でユニークである。つまり、ファイルマネージャ１４は、同じファイル名を複数のマルチメディアデータに付けない。ファイル名の役割は、参照ラベルのそれと比較して全く相違するので注意を要する。
参照フラグは、対応するマルチメディアデータの現状を区別するための情報である。参照フラグの値Ｎ1 は、初期的には「０」であるが、対応するマルチメディアデータの参照状況に応じて、「０」以上のいずれかの整数をとる。なお、詳細は後述されるが、端末装置１内において、各マルチメディアデータは、大略的に、要求マルチメディアデータ、関連マルチメディアデータおよび無関連マルチメディアデータのいずれかに分類される。要求マルチメディアデータは、ユーザにより現在参照されているものであって、その値Ｎ1 は「１」に設定される。関連マルチメディアデータは、要求マルチメディアデータと関連性を持つとファイルマネージャ１４により判断されたものであって、その値Ｎ1 は「０」および「１」でない数に設定される。無関連マルチメディアデータは、要求マルチメディアデータおよび関連マルチメディアデータに属しないものであって、その値Ｎ1 は「０」に設定される。
【００４１】
未参照時間は、ユーザがマルチメディアデータを参照し終えてから、現在時刻までの時間、つまり、対応するマルチメディアデータが連続して参照されていない時間を示す情報である。未参照時間の値Ｎ2 は、初期的には「０」であるが、対応するマルチメディアデータの参照状況に応じて、「０」から「１０」までのいずれかの整数をとる。この値Ｎ2 は、対応するマルチメディアデータが無関連マルチメディアデータに区分されている間には、一定時間毎（本実施形態では１分毎）に「１」ずつインクリメントされるが、そのマルチメディアデータが参照され始めた時に「０」にリセットされる。さらに、この値Ｎ2 は、対応するマルチメディアデータが参照されている間「０」のまま保たれる。ただし、関連マルチメディアデータは、たとえ参照されていなくとも、そのＮ2 の値はインクリメントされない。
保存係数は、ファイルマネージャ１４が記憶装置１５内のファイルを削除するか否かを判断するための情報である。保存係数の値Ｎ3 は、初期的には「１」であるが、対応するマルチメディアデータの参照頻度に応じて増減する。なお、本実施形態では、値Ｎ3 が「０」以下になると、対応するマルチメディアデータは記憶装置１５から削除される。
以上の値Ｎ1 、Ｎ2 およびＮ3 は、ファイルマネージャ１４により算出される。各算出方法は後述される。
【００４２】
以下、図１の端末装置１の詳細な動作を説明する。データ放送局２により配信された多重化信号はチューナー１１により受信される。チューナー１１は、受信した多重化信号からマルチメディアデータを分離して、デコーダ１２に出力する。デコーダ１２は、入力されたマルチメディアデータをデコードしてファイルマネージャ１４に出力する。このデコーダ１２は、図２のようなマルチメディアデータが入力されると、図４のようにＴｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌ、Ｓｕｂ２．ｈｔｍｌ、…をデコードしてファイルマネージャ１４に出力する。
【００４３】
ファイルマネージャ１４は、１ファイル分のマルチメディアデータの入力というイベントに起因して、図５のフローチャートに示す処理手順を開始する。まず、ファイルマネージャ１４は、入力マルチメディアデータの管理情報がテーブル１３に登録済みか否かを調べる（ステップＳ５１）。ステップＳ５１をより詳細に説明する。まず、データ名が入力マルチメディアデータから取り出される。次に、テーブル１３に既に登録されている参照ラベルのいずれかが、取り出されたデータ名と一致するか否かが判断される。データ名と一致する参照ラベルがテーブル１３にあれば、入力マルチメディアデータの管理情報は登録済みであるので、ファイルマネージャ１４はステップＳ５１１に進む。なお、ステップＳ５１１〜Ｓ５１５は便宜上後述される。一方、そのような参照ラベルがなければ、入力マルチメディアデータの管理情報は未登録である。つまり、全く新規のマルチメディアデータが今回入力されたことになるため、ステップＳ５２が行われる。
【００４４】
ファイルマネージャ１４は、今回入力された新しいマルチメディアデータの管理情報をテーブル１３に登録するために、図３（ｂ）に示すように、テーブル１３を１列分追加して、新規領域１３１を確保する（ステップＳ５２）。新規領域１３１には、入力マルチメディアデータのデータ名が参照ラベルとして登録され（ステップＳ５３）、「０」が参照フラグの初期値Ｎ1 および未参照時間の初期値Ｎ2 としてそれぞれ登録され（ステップＳ５４，Ｓ５５）、「１」が保存係数の初期値Ｎ3 として登録される（ステップＳ５６）。次に、ファイルマネージャ１４は、入力マルチメディアデータに、ユニークなファイル名を付けて、新規領域１３１に登録する（ステップＳ５７）。さらに、ファイルマネージャ１４は、入力マルチメディアデータを記憶装置１５に格納する（ステップＳ５８）。ファイルマネージャ１４は、入力マルチメディアデータの格納時間を新規領域１３１に登録する（ステップＳ５９）。ファイルマネージャ１４は、データ格納通知という信号を作成して、ブラウザ１６に出力する（ステップＳ５１０）。このデータ格納通知は、新たに格納されたマルチメディアデータを参照ラベルにより特定する。ブラウザ１６は、入力されたデータ格納通知を解析して、今回新たに格納されたマルチメディアデータの参照ラベルを、ユーザに通知する。
【００４５】
具体例として、図４のＴｏｐｉｃ．ｈｔｍｌが全く新規にファイルマネージャ１４に入力された場合について説明する。Ｔｏｐｉｃ．ｈｔｍｌには０００１．ｈｔｍというファイル名が付けられ、さらに、Ｔｏｐｉｃ．ｈｔｍｌが午前８時５８分に格納されたと仮定する。この仮定に従うと、新規領域１３１には、図３（ｃ）のように、参照ラベルとしてＴｏｐｉｃ．ｈｔｍｌ、格納時刻として０８：５８、ファイル名として０００１．ｈｔｍ、参照フラグの初期値Ｎ1 として「０」、未参照時間の初期値Ｎ2 として「０」、さらに、保存係数の初期値Ｎ3 として「１」が登録される。ファイルマネージャ１４は、以上のような管理情報をテーブル１３に登録して、記憶装置１５内の各マルチメディアデータをファイル単位で管理する。なお、以下には、マルチメディアデータは単にファイル名のみで記載される場合もある。例えば、０００１．ｈｔｍというファイル名のマルチメディアデータは、単に０００１．ｈｔｍと記載される。
【００４６】
ファイルマネージャ１４は、全く新規なマルチメディアデータが入力される毎にステップＳ５１〜Ｓ５１０を行う。これによって、マルチメディアデータ用の管理情報が１組作成され、テーブル１３に新規登録される。今、現在時刻が午前９時６分であると仮定する。さらに、午前９時６分の時点で、時間帯ＴＢ1 に配信されたマルチメディアデータ（図２参照）の内、Ｔｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌが全く新規にファイルマネージャ１４に入力されていると仮定する。つまり、Ｓｕｂ０．ｈｔｍｌおよびそれより後に配信されたマルチメディアデータは、ファイルマネージャ１４に未だ入力されていない。この仮定に従うと、午前９時６分で、テーブル１３には図３（ｄ）のような管理情報が登録される。各管理情報の未参照時間の値Ｎ2 は、対応するマルチメディアデータが記憶装置１５に格納された直後、つまり初期的には「０」である。しかし、各値Ｎ2 は、各マルチメディアデータがユーザにより全く参照されていないと仮定すると、各格納時刻から１分おきに「１」ずつインクリメントされる。したがって、午前８時５８分に格納されたＴｏｐｉｃ．ｈｔｍｌの値Ｎ2 は、午前９時６分では「８」となる。他の値Ｎ2 も同様に算出される。
【００４７】
ユーザは、ブラウザ１６を操作して参照ラベルを入力する。これによって、この参照ラベルに対応するマルチメディアデータが要求される。ユーザは、ステップＳ５１０のデータ格納通知により、データ名（参照ラベル）をリアルタイムに知ることができる。さらに、ユーザは、ＷＷＷや雑誌を通じて、データ名を知ることができる。ユーザは、データ名をＷＷＷや雑誌を通じて知った場合、その名前のマルチメディアデータが記憶装置１５に格納されているか否かが分からない。つまり、ユーザは、マルチメディアデータの有無を意識せずに、参照ラベルを入力する。さらには、一度は参照ラベルがユーザに通知されたが、対応するマルチメディアデータがファイルマネージャ１４により記憶装置１５から削除される場合もある。
【００４８】
ブラウザ１６は、図６に示すように、ユーザにより入力された参照ラベルを含む参照要求を生成してファイルマネージャ１４に出力する。今、この参照要求は、参照ラベルとしてＴｏｐｉｃ．ｈｔｍｌを含んでおり、その格納時刻（午前８時５８分）から８分後の午前９時６分直後に出力されたと仮定する。
【００４９】
ファイルマネージャ１４は、参照要求の入力というイベントに起因して、図７のフローチャートに示される処理を実行する。ファイルマネージャ１４は、参照要求が入力されると（ステップＳ７１）、その要求に含まれる参照ラベルと一致するものをテーブル１３の中から探して、要求マルチメディアデータがあるか否かを判断する（ステップＳ７２）。要求マルチメディアデータとは、ユーザにより要求されたマルチメディアデータを意味する。ファイルマネージャ１４は、参照要求内の参照ラベルと一致するものがテーブル１３に無い場合、要求マルチメディアデータ（Ｔｏｐｉｃ．ｈｔｍｌ）が記憶装置１５に無いと判断して、後述するＳ７２２に進む。一方、ファイルマネージャ１４は、テーブル１３内に参照ラベルを見つけた場合、要求マルチメディアデータが記憶装置１５にあると判断して、ステップＳ７３に進む。
【００５０】
今、Ｔｏｐｉｃ．ｈｔｍｌは記憶装置１５に格納済みで削除されていない。したがって、ファイルマネージャ１４は、要求マルチメディアデータとしてのＴｏｐｉｃ．ｈｔｍｌを記憶装置１５から取り出してブラウザ１６に出力する（ステップＳ７３）。ブラウザ１６は、入力されたＴｏｐｉｃ．ｈｔｍｌをモニタ（図示せず）に表示させ、これによって、ユーザは、要求マルチメディアデータ（Ｔｏｐｉｃ．ｈｔｍｌ）を参照できる。さらに、ステップＳ７３において、ファイルマネージャ１４は、出力した要求マルチメディアデータの管理情報をテーブル１３から取り出す。取り出された管理情報の内、参照フラグ、未参照時間および保存係数が更新される。要求マルチメディアデータは現在参照中であるから、その参照フラグの値Ｎ1 は「１」に更新され（ステップＳ７４）、その未参照時間の値Ｎ2 は「０」にリセットされる（ステップＳ７５）。また、その保存係数の値Ｎ3 は「１」だけインクリメントされる（ステップＳ７６）。ステップＳ７４〜Ｓ７６の結果、Ｔｏｐｉｃ．ｈｔｍｌの値Ｎ1 、Ｎ2 およびＮ3 は、午前９時６分直後には「１」、「０」および「２」に更新される（図１０（ａ）参照）。
【００５１】
ところで、図２の各マルチメディアデータは、ハイパーリンクにより他のマルチメディアデータとつながっている場合がある。ハイパーリンクは、所定のＨＴＭＬタグにより実現される。このＨＴＭＬタグは、リンク元のマルチメディアデータの中に埋め込まれており、リンク先のデータ名を指示する。各マルチメディアデータには、図８（ａ）のようなハイパーリンクが張られていると仮定する。リンク元のＴｏｐｉｃ．ｈｔｍｌから、リンク先のＳｕｂ０．ｈｔｍｌおよびＳｕｂ１．ｈｔｍｌへとハイパーリンク８１および８２が張られている。この場合、リンク元のＴｏｐｉｃ．ｈｔｍｌの中に、リンク先のＳｕｂ０．ｈｔｍｌおよびＳｕｂ１．ｈｔｍｌを指定したＨＴＭＬタグがそれぞれ埋め込まれている。このハイパーリンク８１または８２により、ユーザは、ブラウザ１６を操作して、Ｔｏｐｉｃ．ｈｔｍｌの特定の場所から、Ｓｕｂ０．ｈｔｍｌまたはＳｕｂ１．ｈｔｍｌを参照することができる。
また、リンク元のＳｕｂ１．ｈｔｍｌの中に、リンク先のＳｕｂ２．ｈｔｍｌを指定したＨＴＭＬタグが埋め込まれており、これによって、Ｓｕｂ１．ｈｔｍｌからＳｕｂ２．ｈｔｍｌへのハイパーリンク８３が張られる。さらに、Ｓｕｂ２．ｈｔｍｌからｘｘｘ．ｈｔｍｌへは、いくつかのハイパーリンクが介在する。なお、便宜上、両者の間に介在するいくつかのハイパーリンクの説明および図示は省略される。
【００５２】
リンクされたマルチメディアデータ同士は互いに関連性を有する。Ｓｕｂ０．ｈｔｍｌおよびＳｕｂ１．ｈｔｍｌは、Ｔｏｐｉｃ．ｈｔｍｌとハイパーリンク８１および８２を介して直接つながっているので、Ｔｏｐｉｃ．ｈｔｍｌと密接に関連する。また、Ｓｕｂ２．ｈｔｍｌは、Ｔｏｐｉｃ．ｈｔｍｌと２個のハイパーリンク８２および８３を介してつながっているので、Ｔｏｐｉｃ．ｈｔｍｌと関連する。ただし、Ｓｕｂ２．ｈｔｍｌの関連性は、Ｓｕｂ０．ｈｔｍｌおよびＳｕｂ１．ｈｔｍｌの関連性と比較して弱い。ｘｘｘ．ｈｔｍｌは、Ｔｏｐｉｃ．ｈｔｍｌとＮ個のハイパーリンクを介してつながっているので、Ｔｏｐｉｃ．ｈｔｍｌとの関連性が弱い。このように、２つのファイルの関連性は、その間に介在するハイパーリンクの個数に比例して弱くなる。
【００５３】
ファイルマネージャ１４は、要求マルチメディアデータを基準として、他のマルチメディアデータの関連性の強弱を規定するためにリンクレベルという単位を用いる。リンクレベルは、要求マルチメディアデータと各マルチメディアデータとの間に介在するハイパーリンクの個数である。例えば、図８（ａ）において、Ｓｕｂ０．ｈｔｍｌはＴｏｐｉｃ．ｈｔｍｌと直接つながっている。したがって、Ｓｕｂ０．ｈｔｍｌのリンクレベルの値ＬはＴｏｐｉｃ．ｈｔｍｌから見た場合「１」である。同様に、Ｓｕｂ１．ｈｔｍｌの値Ｌも「１」である。また、Ｔｏｐｉｃ．ｈｔｍｌとＳｕｂ２．ｈｔｍｌとの間には、２個のハイパーリンクが介在するので、Ｓｕｂ２．ｈｔｍｌの値ＬはＴｏｐｉｃ．ｈｔｍｌから見た場合には「２」である。また、Ｔｏｐｉｃ．ｈｔｍｌとｘｘｘ．ｈｔｍｌとの間には、Ｎ個のハイパーリンクが介在すると仮定すると、ｘｘｘ．ｈｔｍｌの値Ｌは「Ｎ」である。このように、リンクレベルの値Ｌが大きくなるほど、要求マルチメディアデータと他のマルチメディアデータとの関連性は弱くなる。
【００５４】
ユーザは、要求マルチメディアデータと関連が強い（つまり値Ｌが小さい）マルチメディアデータに対して関心を抱く。以下、関連マルチメディアデータとは、リンクレベルの値Ｌが、要求マルチメディアデータから見て所定数Ｍ以下のファイルを意味する。今、Ｍ＝２と仮定する。Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌは、それぞれのリンクレベルの値Ｌが「１」または「２」であるから、関連マルチメディアデータとなる。一方、ｘｘｘ．ｈｔｍｌのリンクレベルの値Ｌは、Ｎ≧３と仮定すると、所定数Ｍより大きくなる。したがって、ｘｘｘ．ｈｔｍｌは、関連マルチメディアデータではなく、無関連マルチメディアデータとなる。本端末装置１の一つの目的は、ユーザが関心を持つマルチメディアデータのみを記憶装置１５に残すことにある。したがって、関連マルチメディアデータは、無関連マルチメディアデータと比較すると、記憶装置１５から削除されにくくした方がよい。そのため、ファイルマネージャ１４は、要求マルチメディアデータの管理情報だけでなく、関連マルチメディアデータの管理情報も更新する。そこで、ファイルマネージャ１４は、どのマルチメディアデータが関連マルチメディアデータであるかを決める。そのため、図７のステップＳ７６終了後、図９のステップＳ７７以降の処理が行われる。
【００５５】
ファイルマネージャ１４は、ブラウザ１６により指定される検索範囲を調べ、この検索範囲が「１」以上か否かを判断する（ステップＳ７７）。検索範囲とは、ファイルマネージャ１４が関連マルチメディアデータと無関連マルチメディアデータとを区別するためしきい値であり、上述した所定数「Ｍ」に相当する。つまり、ファイルマネージャ１４は、リンクレベルの値Ｌと検索範囲Ｍとの関係がＬ≦Ｍの条件を満たすマルチメディアデータを、関連マルチメディアデータとして決定する。なお、このＭは「０」以上の整数であればよい。
【００５６】
ところで、ブラウザ１６は、図１１のような画面を必要に応じて表示して、ユーザに検索範囲の値Ｍを設定するよう促す。ユーザは、ブラウザ１６を操作して検索範囲の値Ｍを入力する。ブラウザ１６は、ユーザにより入力された検索範囲の値Ｍをファイルマネージャ１４に通知する。ファイルマネージャ１４は、通知された検索範囲の値Ｍを、所定の記憶領域にラッチしておく。
【００５７】
ラッチされている検索範囲の値Ｍが「０」を示している場合、ブラウザ１６は、関連マルチメディアデータを探す必要がないと、ファイルマネージャ１４に指示していることになる。この場合、ファイルマネージャ１４は、図９の処理を終了する。検索範囲の値Ｍが「１」以上を示している場合には、ブラウザ１６は、関連マルチメディアデータを探す必要があると指示している。この場合、、ファイルマネージャ１４は、ハイパーリンクのリスト８４を作成する（ステップＳ７８）。このリスト８４は、要求マルチメディアデータとハイパーリンクを介してつながっているマルチメディアデータの名前およびリンクレベルの値Ｌが記載されており、概念的には図８（ｂ）のように表される。
【００５８】
上述したように、ハイパーリンクが張られるには、リンク先のデータ名を指定したＨＴＭＬタグが、リンク元のマルチメディアデータに埋め込まなければならない。したがって、ファイルマネージャ１４は、まず、要求マルチメディアデータの中を解析してこのＨＴＭＬタグを探し、さらに各リンク先のマルチメディアデータの中を解析してＨＴＭＬタグを探すという処理を繰り返す。これによって、ファイルマネージャ１４は、リスト８４の作成に必要な情報（データ名および値Ｌ）を収集する。リスト８４は、図８（ｂ）に示すように、リンクレベルの値「Ｌ」が検索範囲の値「Ｍ」以下のマルチメディアデータ毎に、収集されたリンク先のデータ名およびそのリンクレベルの値Ｌが記載される。ただし、図８（ｂ）は、Ｍ＝２の場合を示している。Ｍ＝２の場合、リンク先のデータ名として、Ｓｕｂ０．ｈｔｍｌ（Ｌ＝１）、Ｓｕｂ１．ｈｔｍｌ（Ｌ＝１）、およびＳｕｂ２．ｈｔｍｌ（Ｌ＝２）が記載される。なお、Ｓｕｂ０．ｈｔｍｌにもＨＴＭＬタグが埋め込まれているが、後述するように、Ｓｕｂ０．ｈｔｍｌは現時点では記憶装置１５に格納されていないので、ファイルマネージャ１４は、Ｓｕｂ０．ｈｔｍｌを解析できない。そのため、Ｓｕｂ０．ｈｔｍｌのリンク先は関連マルチメディアデータとして選択されない。
【００５９】
ファイルマネージャ１４は、リスト８４に記載されたマルチメディアデータを関連マルチメディアデータと決定する。さらに、要求マルチメディアデータと関連マルチメディアデータ以外を無関連マルチメディアデータと決定する。このように、検索範囲の値Ｍは、ファイルマネージャ１４が関連マルチメディアデータを検索する際の範囲を規定する。なお、ファイルマネージャ１４は、ステップＳ７２で要求マルチメディアデータが記憶装置１５にないと判断した場合にはリストを作成できないので、ステップＳ７７以降は行われない。
【００６０】
ファイルマネージャ１４は、リンク先のデータ名およびリンクレベル（Ｌ≧１）がリスト８４に記載されていると（ステップＳ７９）、１組のデータ名およびリンクレベルの値「Ｌ」をリスト８４から取り出し（ステップＳ７１０）、処理対象となる関連マルチメディアデータを選択する。次に、ファイルマネージャ１４は、取り出したデータ名と一致する参照ラベルがテーブル１３に登録済みか否かを判断し、さらに、参照ラベルに対応する格納時刻が登録済みか否かを判断する。これによって、選択された関連マルチメディアデータが記憶装置１５にあるか否かが判断される（ステップＳ７１１）。関連マルチメディアデータが記憶装置１５にない場合には、後述するステップＳ７１６が行われる。一方、関連マルチメディアデータがある場合には、ステップＳ７１２が行われる。今、図８（ｂ）のリスト８４からデータ名としてＳｕｂ１．ｈｔｍｌおよびリンクレベル（Ｌ＝１）が取り出されたと仮定する。参照ラベルとしてのＳｕｂ１．ｈｔｍｌがテーブル１３に登録されており、かつ、その参照ラベルに対応する格納時刻として０８：５９が登録されている。つまり、Ｓｕｂ１．ｈｔｍｌは、記憶装置１５に現在格納されている。その参照フラグ、未参照時間および保存係数は、午前９時６分直前（つまり、参照要求が入力される直前）では「０」、「７」および「１」と設定されている（図３（ｄ）参照）。したがって、今回、ファイルマネージャ１４は、ステップＳ７１１からＳ７１２に進む。
【００６１】
ファイルマネージャ１４は、取り出された参照ラベルに対応する未参照時間、参照フラグおよび保存係数を処理対象の管理情報としてテーブル１３から選択する（ステップＳ７１２）。選択された参照フラグの値Ｎ1 は「ｓ」に設定される（ステップＳ７１３）。ｓの値は（Ｌ＋１）である。Ｌは、ステップＳ７１０で取り出されたリンクレベルである。選択された未参照時間の値Ｎ2 は「０」に設定される（ステップＳ７１４）。選択された保存係数の値Ｎ3 には、「ｐ」が加算される（ステップＳ７１５）。ｐの値は（１／２）L である。
【００６２】
上記仮定に従えば、ステップＳ７１２において、処理対象としてＳｕｂ１．ｈｔｍｌ（Ｌ＝１）の参照フラグ（Ｎ1 ＝０）、未参照時間（Ｎ2 ＝７）および保存係数（Ｎ3 ＝１）が選択される。ステップＳ７１３では、ｓ＝２であるから、値Ｎ1 は「２」に更新される。ステップＳ７１４では、値Ｎ2 は「０」に更新される。さらに、ステップＳ７１５では、ｐ＝１／２であるから、保存係数の値Ｎ3 は、取得された値「１」に「０．５」が加算され、「１．５」に更新される。その結果、Ｓｕｂ１．ｈｔｍｌの管理情報は、午前９時６分直後において図１０（ａ）のようになる。
【００６３】
また、ステップＳ７１２において、処理対象としてＳｕｂ２．ｈｔｍｌ（Ｌ＝２）の管理情報が選択された場合について説明する。Ｓｕｂ２．ｈｔｍｌの参照フラグ、未参照時間および保存係数は、午前９時６分の直前（つまり、参照要求が入力される直前）では、図３（ｄ）に示すように、Ｎ1 ＝０、Ｎ2 ＝４およびＮ3 ＝１である。ステップＳ７１３では、ｓ＝３であるから、値Ｎ1 が「３」に更新される。ステップＳ７１４では、値Ｎ2 が「０」に更新される。ステップＳ７１５では、ｐ＝１／４であるから、値Ｎ3 は、取得された値「１」に「０．２５」が加算され、「１．２５」に更新される。その結果、Ｓｕｂ２．ｈｔｍｌの管理情報は、午前９時６分直後において図１０（ａ）のようになる。
【００６４】
以上のように、リスト８４（図８（ｂ）参照）に記載された関連マルチメディアデータの管理情報は更新される。しかしながら、リスト８４には、記憶装置１５に未登録のマルチメディアデータのデータ名およびリンクレベルが記載される場合がある。なぜなら、リスト８４は、リンク元のマルチメディアデータが記憶装置１５に存在すれば作成できるからである。つまり、リスト８４は、リンク先のマルチメディアデータの有無に関係なく作成することができる。例えば、午前９時６分直前には、Ｓｕｂ０．ｈｔｍｌは未格納であるが、ファイルマネージャ１４は、リンク元のＴｏｐｉｃ．ｈｔｍｌの中に、リンク先としてＳｕｂ０．ｈｔｍｌを指定するＨＴＭＬタグを見つける。同時に、ファイルマネージャ１４は、Ｔｏｐｉｃ．ｈｔｍｌから見た場合の、Ｓｕｂ０．ｈｔｍｌのリンクレベルの値Ｌを知ることができる。したがって、記憶装置１５に未格納の関連マルチメディアデータのデータ名およびリンクレベルがステップＳ７１０において選択される場合がある。
【００６５】
この場合、ファイルマネージャ１４は、ステップＳ７１１において、関連マルチメディアデータが記憶装置１５に未格納であると判断する。以下、未格納・関連ファイルとは、ステップＳ７１１において、記憶装置１５に未格納と判断された関連マルチメディアデータを意味する。次に、ファイルマネージャ１４は、未格納・関連マルチメディアデータのデータ名と一致する参照ラベルがテーブル１３に登録済みか否かを判断して、仮の管理情報の有無を判断する（ステップＳ７１６）。ファイルマネージャ１４は、仮の管理情報がある場合には、ステップＳ７２１（後述）に直接進む。ファイルマネージャ１４は、仮の管理情報が無い場合には、テーブル１３に新規領域を１列分追加する（ステップＳ７１７）。この新規領域には、参照ラベルとして、関連ファイルのデータ名が登録され（ステップＳ７１８）、格納時刻およびファイル名として、ブランクを意味する「−」が登録され（ステップＳ７１９）、さらに、参照フラグの初期値Ｎ1 、および未参照時間の初期値Ｎ2 としてそれぞれ「０」が登録され、保存係数の初期値Ｎ3 として「１」が登録される（ステップＳ７２０）。これによって、仮の管理情報が作成される。なお、格納時刻およびファイル名は、記憶装置１５に格納されていないマルチメディアデータに対しては設定することが不可能であるため、このステップＳ７１９では「−」が登録される。次に、ファイルマネージャ１４は、作成された仮の管理情報を、処理対象としてテーブル１３から選択して（ステップＳ７２１）、ステップＳ７１２以降を行う。
【００６６】
今、ステップＳ７１６において、Ｓｕｂ０．ｈｔｍｌの仮の管理情報が無いと判断された場合について説明する。まず、ステップＳ７１８において、Ｓｕｂ０．ｈｔｍｌが参照ラベルとして新規領域に登録される。ステップＳ７１９において、「−」が格納時刻およびファイル名として登録される。ステップＳ７２０において、「０」が参照フラグの初期値Ｎ1 および未参照時間の初期値Ｎ2 としてそれぞれ登録され、さらに、「１」が保存係数の値Ｎ3 として登録される。その後、ステップＳ７１３において、Ｓｕｂ０．ｈｔｍｌのリンクレベルの値Ｌが「１」の場合にはｓ＝２であるから、値Ｎ1 は「０」から「２」に更新される。値Ｎ2 は、ステップＳ７１４が実行されても「０」のままである。ステップＳ７１５において、Ｌが「１」の場合ｐ＝０．５であるから、値Ｎ3 は「１．５」と更新される。その結果、Ｓｕｂ０．ｈｔｍｌの仮の管理情報は、午前９時６分直後において図１０（ａ）のようになる。
【００６７】
詳細は後述するが、本実施形態では、値Ｎ3 が「０」以下になれば、対応するマルチメディアデータは記憶装置１５から削除される。しかしながら、要求マルチメディアデータの保存係数の値Ｎ3 は、ステップＳ７６において「１」だけ加算される。さらに要求マルチメディアデータだけでなく、関連マルチメディアデータの値Ｎ3 もまた、ステップＳ７１５において「ｐ」（＝（１／２）L ）だけ加算される。さらに、各関連マルチメディアデータの値Ｎ3 は、リンクレベルの値（つまり、要求マルチメディアデータとの関連の強さ）に応じて互いに異なる。つまり、リンクレベルが小さいほど、加算値「ｐ」が大きくなる。これによって、要求マルチメディアデータとの関連性が強い関連マルチメディアデータほど、大きな保存係数に更新されるため記憶装置１５に長時間残るようになる。
以上のように、要求マルチメディアデータおよび関連マルチメディアデータの値Ｎ3 は「０」以下になりにくくなるので、記憶装置１５から削除されにくくなる。これによって、記憶装置１５には、ユーザの関心が高いファイルが残りやすくなり、関心の低いファイルは削除されやすくなる。これによって、記憶装置１５の容量が有効利用されることとなる。
【００６８】
ところで、仮の管理情報が作成された未格納・関連マルチメディアデータは将来的にファイルマネージャ１４に入力される場合が多い。今、Ｓｕｂ０．ｈｔｍｌが午前９時７分直前にファイルマネージャ１４に入力されたと仮定する。ファイルマネージャ１４は、マルチメディアデータ入力というイベントにより、入力マルチメディアデータの管理情報の有無を判断する（図５；ステップＳ５１）。今、入力マルチメディアデータのデータ名Ｓｕｂ０．ｈｔｍｌと一致する参照ラベルＳｕｂ０．ｈｔｍｌが、テーブル１３に登録されている（図１０（ａ）参照）。したがって、ファイルマネージャ１４は、入力マルチメディアデータの管理情報を処理対象としてテーブル１３から選択する（ステップＳ５１１）。今、Ｓｕｂ０．ｈｔｍｌの管理情報は仮のものであるが、ファイルマネージャ１４は、ステップＳ５１１では、仮の管理情報と通常の管理情報とを区別することなく取り扱う。
【００６９】
ファイルマネージャ１４は、次に、参照フラグの値Ｎ1 が「１」か否かを判断する（ステップＳ５１２）。この値Ｎ1 が「１」である場合、入力マルチメディアデータと同じデータ名のマルチメディアデータが現在ユーザにより参照されていることとなる。本実施形態では、図２に示すように、同じデータ名を持つファイルが時間をおいて送信されてくるので、ステップＳ５１２において値Ｎ1 が「１」という場合が起こりうる。しかし、今、Ｔｏｐｉｃ．ｈｔｍｌが参照中であり、Ｓｕｂ０．ｈｔｍｌは、その値Ｎ1 が「１」ではなく（図１０（ａ）参照）、参照されていない。そのため、ステップＳ５１３以降の処理をここでは説明する。なお、値Ｎ1 が「１」の場合の処理は後述される。
【００７０】
ファイルマネージャ１４は、参照フラグの値Ｎ1 、未参照時間の値Ｎ2 および保存係数の値Ｎ3 を承継する（ステップＳ５１３、Ｓ５１４およびＳ５１５）。より具体的には、処理対象の各値Ｎ1 、Ｎ2 およびＮ3 は更新されることなくそのまま用いられる。今、Ｓｕｂ０．ｈｔｍｌの各値Ｎ1 、Ｎ2 およびＮ3 は、「２」、「０」および「１．５」である。したがって、このステップＳ５１３、Ｓ５１４およびＳ５１５の実行後も、Ｎ1 、Ｎ2 およびＮ3 は、「２」、「０」および「１．５」である。
【００７１】
次に、ファイルマネージャ１４は、今回入力されたマルチメディアデータの承継元のマルチメディアデータが記憶装置１５に格納されているか否かを判断する（ステップＳ５１６）。このステップＳ５１６において、ファイルマネージャ１４は、今回入力されたマルチメディアデータの参照ラベルが重複して、つまり二重にテーブル１３に登録されている場合には、承継元のマルチメディアデータが存在すると判断して、ステップＳ５１７に進む。一方、ファイルマネージャ１４は、承継元のマルチメディアデータが記憶装置１５に存在しない場合には、ステップＳ５７に進む。なお、図１０（ａ）に示すように、午前９時７分直前では、Ｓｕｂ０．ｈｔｍｌという参照ラベルはテーブル１３に１つしか登録されていない。そのため、ステップＳ５１７の説明は後でされる。
【００７２】
ファイルマネージャ１４は、入力マルチメディアデータにファイル名を付ける（ステップＳ５７）。そして、入力マルチメディアデータは記憶装置１５に格納され（ステップＳ５８）、ファイルマネージャ１４は、入力マルチメディアデータの格納時間を登録する（ステップＳ５９）。これら、ファイル名および格納時間はテーブル１３において対応するフィールドに登録される。次に、データ格納通知がブラウザ１６に出力される（ステップＳ５１０）。
【００７３】
今、入力されたＳｕｂ０．ｈｔｍｌは、ステップＳ５７においてファイル名０００８．ｈｔｍが付けられた後に、午前９時７分に記憶装置１５に格納されたと仮定する。この仮定に従うと、テーブル１３は、９時７分直後には、図１０（ｂ）に示すように、数組の管理情報を保持する。ここで、注意を要するのは、午前９時６分直後において、Ｓｕｂ０．ｈｔｍｌのファイル名と格納時刻は、未定であり、登録不可能な状態であったため、「−」つまりブランクであった（図１０（ａ）参照）。しかし、午前９時７分直後において、Ｓｕｂ０．ｈｔｍｌのファイル名と格納時刻は登録され、その管理情報が完成する。ここで、Ｓｕｂ０．ｈｔｍｌの値Ｎ1 、Ｎ2 およびＮ3 は、Ｓｕｂ０．ｈｔｍｌの入力時点で新規登録されるのではなく、仮の管理情報から引き継がれる。つまり、本実施形態では、Ｓｕｂ０．ｈｔｍｌのような未格納・関連マルチメディアデータは、記憶装置１５に格納された時点で、「１」を超える保存係数の値Ｎ3 を持つ（図１０（ｂ）参照）。
【００７４】
以上のように、関連マルチメディアデータは、たとえマルチメディアデータがブラウザ１６により要求された時点で、記憶装置１５に格納されていなくとも、仮の管理情報が作成される。このような未格納・関連マルチメディアデータの参照フラグ、未参照時間および保存係数は、それが記憶装置１５に格納された時点で、仮の管理情報から引き継がれる。この引き継がれた保存係数の値Ｎ3 は、初期値「１」よりも大きな値を持つ。つまり、未格納・関連マルチメディアデータには、その格納時点で、相対的に大きな値Ｎ3 がファイルマネージャ１４により与えられることとなる。これによって、この値Ｎ3 は「０」以下になりにくくなるので、記憶装置１５から削除されにくくなる。これによって、記憶装置１５には、ユーザの関心が高いファイルがさらに残りやすくなる。これによって、記憶装置１５の容量が有効利用されることとなる。
なお、図１０（ａ）と（ｂ）の比較において注意を要するのは、要求マルチメディアデータおよび関連マルチメディアデータの未参照時間の値Ｎ2 は、１分が経過してもインクリメントされないことである。つまり、値Ｎ2 は、参照フラグの値Ｎ1 が「０」以下でなければインクリメントされないので（詳細は後述）、保存係数の値Ｎ3 はデクリメントされにくくなり、記憶装置１５から削除されにくくなる（詳細は後述する図１２参照）。
【００７５】
ここで、ｘｘｘ．ｈｔｍｌが午前９時８分直前にファイルマネージャ１４に入力されたと仮定する。ｘｘｘ．ｈｔｍｌもまた、全く新規なマルチメディアマルチメディアデータである。また、このｘｘｘ．ｈｔｍｌは、リスト（図８（ｂ）参照）に記載されていないので、現時点では、無関連マルチメディアデータである。ファイルマネージャ１４は、ｘｘｘ．ｈｔｍｌの入力に起因して、図５のフローチャートに示されたステップＳ５１〜Ｓ５１０を実行する。この全く新規なｘｘｘ．ｈｔｍｌに関する処理は、前述したＴｏｐｉｃ．ｈｔｍｌの入力時（午前８時５８分直前）のそれと同様である。そのため、ｘｘｘ．ｈｔｍｌについて行われるステップＳ５１〜Ｓ５１０の説明は省略される。このステップＳ５１〜Ｓ５１０処理の結果、ｘｘｘ．ｈｔｍｌの管理情報が、図１０（ｃ）に示すように、テーブル１３に新規に追加される。その格納時刻は０９：０８である。そのファイル名は０００９．ｈｔｍである。その参照フラグの初期値Ｎ1 、未参照時間の初期値Ｎ2 、および保存係数の初期値Ｎ3 は、「０」、「０」および「１」である。
【００７６】
図５の処理は、マルチメディアデータ入力に起因する割り込み処理であるので、ファイルマネージャ１４は、図１２のフローチャートに示す処理を、テーブル１３に現在登録されている各管理情報に対して１分毎に開始する。なお、この図１２の処理は、午前８時５８分から午前９時８分直前までの１０分間にも実行されているが、便宜上、図７および図９の処理よりも後で説明している。なお、以下の説明は、午前９時８分直後に実行される処理と仮定する。
まず、ファイルマネージャ１４は、テーブル１３を検索して、処理対象となる管理情報があると（ステップＳ１２１）、管理情報をテーブル１３から１ファイル分選択する（ステップＳ１２２）。今、処理対象としてＴｏｐｉｃ．ｈｔｍｌの管理情報が選択されたとする。ファイルマネージャ１４は、処理対象の参照フラグの値Ｎ1 が「１」以上か否かを判断し（ステップＳ１２３）、当該参照フラグが「１」以上の場合には、ステップＳ１２１に戻る。ここで、図１０（ａ）〜（ｃ）に示すように、Ｔｏｐｉｃ．ｈｔｍｌの値Ｎ1 は、午前９時６分直後から現時点（午前９時８分直後）までの間で「１」である。そのため、ファイルマネージャ１４は、処理対象がＴｏｐｉｃ．ｈｔｍｌの管理情報である場合、ステップＳ１２１に戻って、他の管理情報を選択する。つまり、Ｔｏｐｉｃ．ｈｔｍｌの管理情報は何ら更新されず、現状のまま保たれる。なお、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌおよびＳｕｂ０．ｈｔｍｌもまた、各値Ｎ1 は現時点（午前９時８分直後）で「１」以上であるので、これら関連ファイルの管理情報が処理対象として選択された場合、Ｔｏｐｉｃ．ｈｔｍｌの管理情報の場合と同様に処理され、何ら更新されない。
しかし、ｘｘｘ．ｈｔｍｌの管理情報が処理対象として選択された場合、ｘｘｘ．ｈｔｍｌの値Ｎ1 は、現時点（午前９時８分直後）では、「０」を示している。値Ｎ1 が「１」以上で無い場合、ファイルマネージャ１４は、対応する未参照時間の値Ｎ2 を「１」だけインクリメントする（ステップＳ１２４）。その結果、ｘｘｘ．ｈｔｍｌの未参照時間の値Ｎ2 は「１」に更新される。次に、ファイルマネージャ１４は、処理対象の管理情報である未参照時間の値Ｎ2 が「１０」であるか否かを判断する（ステップＳ１２５）。ファイルマネージャ１４は、値Ｎ2 が「１０」で無い場合には、ステップＳ１２１に戻る。一方、値Ｎ2 が「１０」である場合には、後述するステップＳ１２６が行われる。今、ｘｘｘ．ｈｔｍｌのＮ2 は「１０」で無いので、ファイルマネージャ１４は、ステップＳ１２１に戻る。ファイルマネージャ１４は、現時点（午前９時８分直後）では、全ての管理情報を処理対象と選択し、処理対象の管理情報がなくなったので、一旦図１２の処理を終了する。
【００７７】
今、ブラウザ１６のユーザは、Ｔｏｐｉｃ．ｈｔｍｌの参照を午前９時９分に終了すると仮定する。この終了に応答して、ブラウザ１６は、参照の終了を示す情報である参照終了通知を生成し、ファイルマネージャ１４に出力する。この参照終了通知には、要求マルチメディアデータのデータ名（今回はＴｏｐｉｃ．ｈｔｍｌ）が含まれる。ユーザが要求マルチメディアデータの参照を終了すると、要求マルチメディアデータおよび関連マルチメディアデータの管理情報を更新する。そこで、ファイルマネージャ１４は、参照終了通知の入力というイベントに起因して、図１３のフローチャートで示す処理を行う。まず、ファイルマネージャ１４は、参照終了した要求マルチメディアデータの管理情報を継承すべきマルチメディアデータ（以下、継承先マルチメディアデータと称す）が記憶装置１５に格納されているか否かを判断する（ステップＳ１３１）。この継承先マルチメディアデータは、参照終了した要求マルチメディアデータと同一の参照ラベルを持ち、かつその参照フラグの値Ｎ1 が「０」のものを意味するが、詳細については後述する。ファイルマネージャ１４は、継承先マルチメディアデータが格納済みである場合には、後述するステップＳ１３７に進むが、それが未格納の場合には、ステップＳ１３２に進む。今、Ｔｏｐｉｃ．ｈｔｍｌの継承先マルチメディアデータが記憶装置１５にないと仮定して説明を続ける。この仮定に従うと、ファイルマネージャ１４は、その要求マルチメディアデータについて登録されている管理情報を処理対象としてテーブル１３から選択する（ステップＳ１３２）。ファイルマネージャ１４は、選択した管理情報の参照フラグの値Ｎ1 を「０」に変更する（ステップＳ１３３）。Ｔｏｐｉｃ．ｈｔｍｌは、無関連マルチメディアデータとして区分される。
【００７８】
次に、ファイルマネージャ１４は、リスト８４（図８（ｂ）参照）を参照して、関連マルチメディアデータがあるか否かを判断する（ステップＳ１３４）。ファイルマネージャ１４は、関連ファイルが無い場合には、図１３の処理を終了するが、それがある場合には、ステップＳ１３５に進む。図８（ｂ）を参照すると、Ｔｏｐｉｃ．ｈｔｍｌの関連マルチメディアデータとして、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌがある。したがって、ファイルマネージャ１４は、リスト８４に記載された関連マルチメディアデータのデータ名を１つ選択して、そのマルチメディアデータの管理情報を処理対象としてテーブル１３から選択する（ステップＳ１３５）。ファイルマネージャ１４は、選択した管理情報の参照フラグの値Ｎ1 を「０」に変更する（ステップＳ１３６）。ファイルマネージャ１４は、リスト８４に記載された全てのデータ名を選択するまで、このステップＳ１３４〜Ｓ１３６を行って、図１３の処理を終了する。その結果、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌのＮ1 がそれぞれ「０」に変更される。これにより、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌもまた無関連マルチメディアデータとして区分される。
【００７９】
以上のステップＳ１３１〜１３６が行われた結果、テーブル１３は、図１４（ａ）のような管理情報を保持することとなる。このように、ファイルマネージャ１４は、ユーザが要求マルチメディアデータを参照し終わると、要求マルチメディアデータおよび関連ファイルの値Ｎ1 をそれぞれ「０」に変更して、それらを無関連マルチメディアデータとしてテーブル１３に登録する。
【００８０】
図１３の処理は、参照終了通知の入力に起因する割り込み処理であるから、ファイルマネージャ１４は、この処理の終了直後に（つまり、午前９時９分直後に）、図１２の処理を実行する。テーブル１３は、現時点（午前９時１０分直後）で、図１４（ａ）のような管理情報を保持している。各管理情報の参照フラグの値Ｎ1 は現時点で全て「１」以上でない。したがって、ファイルマネージャ１４は、ステップＳ１２１〜Ｓ１２４のループを５回繰り返し、各ループで互いに異なる参照ラベルを含む管理情報を処理対象として選択する。その結果、各未参照時間の値Ｎ2 は「１」ずつインクリメントされる。これによって、Ｔｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌのＮ2 がそれぞれ「１」に変更される。さらに、ｘｘｘ．ｈｔｍｌのＮ2 は「２」に変更される。
【００８１】
ブラウザ１６のユーザは、午前９時９分直後から９時１８分直後までの９分間、マルチメディアデータを全く参照しないと仮定する。この９分間、テーブル１３の各参照フラグの値Ｎ1 は「１」以上ではない。したがって、最初の８分間では、１分おきに、ステップＳ１２１〜Ｓ１２５のループが８回ずつ繰り返され、各ループで互いに異なる管理情報が処理対象として選択される。その結果、まず、午前９時１７分直後の各未参照時間の値Ｎ2 は、午前９時９分直後のものに対して「７」ずつインクリメントされる。つまり、Ｔｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌのＮ2 がそれぞれ「８」に変更される。ｘｘｘ．ｈｔｍｌのＮ2 は「９」に変更される（図１４（ｂ）参照）。
【００８２】
さらに、午前９時１８分直後に、Ｔｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌまたはＳｕｂ２．ｈｔｍｌの管理情報が処理対象として選択された場合（ステップＳ１２１，Ｓ１２２）、各参照フラグの値Ｎ1 が「１」以上ではないので（ステップＳ１２３）、各未参照時間のＮ2 が「１」だけインクリメントされる（ステップＳ１２４）。その結果、Ｔｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌの値Ｎ2 はそれぞれ「９」となる。
また、午前９時１８分直後に、ｘｘｘ．ｈｔｍｌの管理情報が選択され取り出された場合も（ステップＳ１２１およびＳ１２２）、ｘｘｘ．ｈｔｍｌの値Ｎ1 が「１」以上ではないので（ステップＳ１２３）、ｘｘｘ．ｈｔｍｌの値Ｎ2 が「１」だけインクリメントされる（ステップＳ１２４）。その結果、ｘｘｘ．ｈｔｍｌの値Ｎ2  は「１０」になる。そのため、ファイルマネージャ１４は、ｘｘｘ．ｈｔｍｌを処理対象として選択した場合に、ステップＳ１２５においてその値Ｎ2 が「１０」であると判断して、ステップＳ１２６に進む。
【００８３】
ファイルマネージャ１４は、ステップＳ１２２で選択した管理情報の保存係数の値Ｎ3 を「１」だけデクリメントする（ステップＳ１２６）。その結果、ｘｘｘ．ｈｔｍｌの値Ｎ3 は「０」となる。次に、ファイルマネージャ１４は、未参照時間の値Ｎ2 を「０」にリセットする（ステップＳ１２７）。次に、ファイルマネージャ１４は、デクリメントされた値Ｎ3 が「０」以下か否かを判断する（ステップＳ１２８）。ファイルマネージャ１４は、この値Ｎ3 が「０」以下で無い場合、ステップＳ１２１に戻るが、この値Ｎ3 が「０」以下の場合、ステップＳ１２９に進む。今回の場合、ｘｘｘ．ｈｔｍｌの値Ｎ3 は「０」なので、ファイルマネージャ１４は、ステップＳ１２９に進み、選択された管理情報に対応するマルチメディアデータが記憶装置１５に実際に格納されているか否かをテーブル１３を参照して判断する（ステップＳ１２９）。本端末装置１では、未だ配信されていない未格納のマルチメディアデータに対して仮の管理情報を作成する。このような仮の管理情報が作成されたが、未配信のマルチメディアデータというものが存在しうる。ゆえにステップＳ１２９が必要となる。ファイルマネージャ１４は、ステップＳ１２９において、マルチメディアデータがあると判断した場合には、その管理情報により特定されるマルチメディアデータを記憶装置１５から削除し（ステップＳ１２１０）、テーブル１３から処理対象の管理情報を削除する（ステップＳ１２１１）。ファイルマネージャ１４は、マルチメディアデータがないと判断した場合には、テーブル１３から処理対象の管理情報のみを削除する（ステップＳ１２１１）。今回の場合、ｘｘｘ．ｈｔｍｌおよびその管理情報が削除される。その結果、テーブル１３は、午前９時１８分直後、図１４（ｃ）に示すような管理情報を保持する。
【００８４】
以上説明したように、Ｔｏｐｉｃ．ｈｔｍｌの保存係数の値Ｎ3 は、ユーザの参照により増加するので「０」以下になりにくくなっている。そのため、Ｔｏｐｉｃ．ｈｔｍｌは、記憶装置１５から削除されにくくなっている。一方、ｘｘｘ．ｈｔｍｌは、ユーザにより参照されなかったので、保存係数Ｎ3 が減少しすぐに「０」以下になる。そのため、ｘｘｘ．ｈｔｍｌは、記憶装置１５から削除されやすくなる。したがって、端末装置１は、ユーザによる参照頻度が高かったマルチメディアデータを、記憶装置１５内に残すように処理していることとなる。つまり、ユーザの関心が高いマルチメディアデータが、記憶装置１５内に長時間格納され、そうでないマルチメディアデータは記憶装置１５内からすぐに削除される。これによって、端末装置１は、たとえ小容量の記憶装置１５を備えていても、少ない記憶領域を有効利用することができる。
さらに、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌは、ユーザにより直接参照されていないが、ユーザにより参照されるマルチメディアデータ（Ｔｏｐｉｃ．ｈｔｍｌ）と一定の関連性を持っており、ユーザの関心が高いと、ファイルマネージャ１４により判断される。そのため、Ｓｕｂ０．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌおよびＳｕｂ２．ｈｔｍｌの保存係数の値Ｎ3 がそれぞれ「０」以下になりにくくなっており、これらのマルチメディアデータもまた、記憶装置１５から削除されにくくなっている。つまり、端末装置１は、ユーザにより参照されたマルチメディアデータ（要求マルチメディアデータ）だけでなく、その関連マルチメディアデータも、記憶装置１５内に残すように処理していることとなる。これによって、端末装置１の記憶装置１５には、ユーザの関心が高いマルチメディアデータがより多く格納されることとなる。このように、本端末装置１によれば、記憶装置１５内のマルチメディアデータは、ユーザの好みに応じて自動的にカスタマイズされる。
【００８５】
さて、データ放送局２が時間帯ＴＢ2 に配信したＴｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ１．ｈｔｍｌ、Ｓｕｂ２．ｈｔｍｌ、…が、午前９時１９分直前から順次的に端末装置１に到着すると仮定する。まず、Ｔｏｐｉｃ．ｈｔｍｌがデコーダ１２からファイルマネージャ１４に入力される。この時間帯ＴＢ2 のＴｏｐｉｃ．ｈｔｍｌは、時間帯ＴＢ1 に配信された同じデータ名のものと同一性を持つ。また、現時点で、テーブル１３はＴｏｐｉｃ．ｈｔｍｌの管理情報を保持する（図１４（ｃ）参照）。ファイルマネージャ１４は、今回のＴｏｐｉｃ．ｈｔｍｌの入力に起因して図５の処理を行う。まず、今回入力されたＴｏｐｉｃ．ｈｔｍｌの管理情報は、テーブル１３内に登録済みであるから（ステップＳ５１）、処理対象として選択される（ステップＳ５１１）。その参照フラグの値Ｎ1 は「０」であり（ステップＳ５１２）、Ｔｏｐｉｃ．ｈｔｍｌは参照中でないので、各値Ｎ1 、Ｎ2 およびＮ3 は承継される（ステップＳ５１３〜Ｓ５１５）。次に、古いＴｏｐｉｃ．ｈｔｍｌは、記憶装置１５に格納されていると判断され、つまり、承継元のマルチメディアデータがあると判断される（ステップＳ５１６）。これによって、ファイルマネージャ１４は、ステップＳ５１７に進み、承継元のマルチメディアデータを記憶装置１５から削除すると共に、承継元のマルチメディアデータ用に登録された管理情報を削除する（ステップＳ５１７）。さらに、新しいＴｏｐｉｃ．ｈｔｍｌにはユニークなファイル名が付され、そのファイル名がテーブル１３に登録される（ステップＳ５７）。このファイル名は０００２．ｈｔｍであると仮定する。さらに、新たに入力されたＴｏｐｉｃ．ｈｔｍｌが記憶装置１５に格納される（ステップＳ５８）。さらに、その格納時間がテーブル１３に登録される（ステップＳ５９）。この格納時間は午前９時１９分であると仮定する。そして、データ格納通知が行われる（ステップＳ５１０）。
【００８６】
以上のステップＳ５１、Ｓ５１１〜Ｓ５１７およびＳ５７〜Ｓ５１０により、図１５（ａ）に示すように、古いＴｏｐｉｃ．ｈｔｍｌ（０００１．ｈｔｍ）が記憶装置１５から削除され、新しいＴｏｐｉｃ．ｈｔｍｌ（０００２．ｈｔｍ）が記憶装置１５に新たに格納される。さらに、図１５（ｂ）に示すように、新しいＴｏｐｉｃ．ｈｔｍｌ（０００２．ｈｔｍ）の各値Ｎ1 、Ｎ2 およびＮ3 として、予め定められた初期値が設定されるのではなく、古いもの（０００１．ｈｔｍ）の各値Ｎ1 、Ｎ2 およびＮ3 がそのまま用いられる。これによって、同一性があるマルチメディアデータ間では、古いマルチメディアデータから新しいものへと管理情報が継承される。そのため、ユーザが古いマルチメディアデータに興味を持っていれば、それと同一性がある新しいマルチメディアデータは記憶装置１５から削除されにくくなる。さらに、古いＴｏｐｉｃ．ｈｔｍｌは記憶装置１５から削除されると共に、古いＴｏｐｉｃ．ｈｔｍｌの管理情報はテーブル１３から削除される。これによって、記憶装置１５内には、ユーザによる関心が高くしかも新しいマルチメディアデータが格納されることとなる。
【００８７】
次に、上述と同様に、時間帯ＴＢ2 に配信されたＴｏｐｉｃ．ｈｔｍｌ等が、午前９時１９分直前から順次的に端末装置１に到着すると仮定する。新たに到着したＴｏｐｉｃ．ｈｔｍｌは、既に格納されている古いＴｏｐｉｃ．ｈｔｍｌと同一性を持つ。ただし、上述と異なるのは、現時点で、テーブル１３は、図１６（ａ）に示すようなＴｏｐｉｃ．ｈｔｍｌの管理情報を保持する点である。つまり、現時点で、古いＴｏｐｉｃ．ｈｔｍｌはユーザにより参照されており、その参照フラグの値Ｎ1 が「１」である。この仮定に従うと、新しいＴｏｐｉｃ．ｈｔｍｌが入力されると、古いＴｏｐｉｃ．ｈｔｍｌの管理情報が処理対象として選択される（図５；ステップＳ５１，５１１）。その参照フラグの値Ｎ1 は「１」であり（ステップＳ５１２）、古いＴｏｐｉｃ．ｈｔｍｌが参照中である。そのため、管理情報の継承処理、つまりステップＳ５１３〜Ｓ５１７を行うことができない。なぜなら、ステップＳ５１７において、ユーザが参照中の古いＴｏｐｉｃ．ｈｔｍｌが削除されてしまうからである。
【００８８】
そこで、ファイルマネージャ１４は、ステップＳ５１２で値Ｎ1 が「１」の場合には、ステップＳ５２〜Ｓ５１０を行って、新しいＴｏｐｉｃ．ｈｔｍｌのために、仮の管理情報を作成して、新しいＴｏｐｉｃ．ｈｔｍｌを記憶装置１５に格納して、データ格納通知を出力する。ステップＳ５２〜Ｓ５１０の説明は、前述されているので、ここでは省略される。これによって、テーブル１３には、図１６（ｂ）のように、新しいＴｏｐｉｃ．ｈｔｍｌおよび古いＴｏｐｉｃ．ｈｔｍｌの管理情報、つまり参照ラベルが同一の管理情報が重複して登録されることとなる。この古いＴｏｐｉｃ．ｈｔｍｌおよびその管理情報は、ユーザが古いＴｏｐｉｃ．ｈｔｍｌ（要求マルチメディアデータ）の参照を終了した時に削除される。つまり、ブラウザ１６は、前述したように、Ｔｏｐｉｃ．ｈｔｍｌの参照が終了すると、その参照終了通知をファイルマネージャ１４に出力する。ファイルマネージャ１４は、参照終了通知が入力されると、図１３に示される処理を行う。
【００８９】
ファイルマネージャ１４は、まず、継承先のマルチメディアデータがあるか否かを判断する（ステップＳ１３１）。ファイルマネージャ１４は、まず、テーブル１３に同じ参照ラベルが重複して登録されているか否かを判断する。ファイルマネージャ１４は、重複登録されている場合には、その参照ラベルに対応する格納時刻を比較し、後で格納されたマルチメディアデータを承継先として選択する。例えば、図１６（ｂ）では、Ｔｏｐｉｃ．ｈｔｍｌの管理情報が重複登録されており、それぞれの格納時刻は０８：５８および０９：１９と登録されている。つまり、０００２．ｈｔｍというファイル名が付けられたＴｏｐｉｃ．ｈｔｍｌが承継先として選択される。また、０００１．ｈｔｍというファイル名のＴｏｐｉｃ．ｈｔｍｌが承継元として選択される。
【００９０】
ファイルマネージャ１４は、ステップＳ１３１で継承先があると判断した場合には、継承元の管理情報に含まれる未参照時間の値Ｎ2 および保存係数の値Ｎ3 を、継承先の管理情報へと継承する。より具体的には、継承元の未参照時間の値Ｎ2 および保存係数の値Ｎ3 が取り出される。取り出された値Ｎ2 およびＮ3 は承継先となる未参照時間および保存係数として登録され更新される（ステップＳ１３７，Ｓ１３８）。ただし、参照フラグの値Ｎ1 は、承継先のマルチメディアデータが現在参照でないことから、「０」のまま保たれる。さらに、ファイルマネージャ１４は、承継元のマルチメディアデータを記憶装置１５から削除すると共に、承継元の管理情報をテーブル１３から削除する（ステップＳ１３９）。例えば、ステップＳ１３７の直前では、０００２．ｈｔｍの値Ｎ1 、Ｎ2 およびＮ3 は、図１６（ｂ）に示すように「０」、「０」および「１」であった。さらに、０００１．ｈｔｍの値Ｎ2 およびＮ3 は「０」および「２」であった。ステップＳ１３９の直後では、図１６（ｃ）に示すように、０００２．ｈｔｍの値Ｎ2 およびＮ3 は「０」および「２」に更新され、０００１．ｈｔｍの管理情報は削除される。０００１．ｈｔｍ（マルチメディアデータ）自体も記憶装置１５から削除される。
【００９１】
ファイルマネージャ１４は、ステップＳ１３９の後、関連マルチメディアデータがある場合には、各参照フラグの値Ｎ1 を「０」に更新するため処理を行う（ステップＳ１３４〜Ｓ１３６）。なお、このステップＳ１３４〜Ｓ１３６の説明は既に行われているので、ここでは省略される。
【００９２】
以上説明したように、たとえ、図５のステップＳ５１１の判断の時点で、承継元のマルチメディアデータが現在ユーザにより参照されていたとしても、その参照が終了したときに行われる図１３のステップＳ１３７〜Ｓ１３９により、管理情報の承継がスムーズに行われる。さらに、承継元の、つまり古いマルチメディアデータおよびその管理情報が削除される。これによって、上述と同様に、ユーザが古いマルチメディアデータに興味を持っていれば、それと同一性がある新しいマルチメディアデータは記憶装置１５から削除されにくくなる。さらに、記憶装置１５内には、ユーザによる関心が高くしかも新しいマルチメディアデータが格納される。
【００９３】
ところで、前述したように、ブラウザ１６は、記憶装置１５に未格納のマルチメディアデータをファイルマネージャ１４に要求する場合がある。以下、このようなブラウザ１６により要求されたが、記憶装置１５に未格納のマルチメディアデータのことを、未格納・要求マルチメディアデータと称する。未格納・要求マルチメディアデータは将来的に記憶装置１５に格納される可能性がある。さらに、ユーザが未格納・要求マルチメディアデータを参照したいと思ったのは事実である。したがって、未格納・要求マルチメディアデータは、記憶装置１５に格納された際には、記憶装置１５から削除されにくくしておいた方がよい。今、このような未格納・要求マルチメディアデータのデータ名（つまり参照ラベル）がｘｘｘ．ｈｔｍｌであると仮定する。
【００９４】
そこで、ファイルマネージャ１４は、図７のステップＳ７２において、参照要求に含まれるいるデータ名と一致する参照ラベルをテーブル１３の中から見つけることができなかった場合、現在要求されているファイルを未格納・要求マルチメディアデータと決定する。そして、ファイルマネージャ１４は、マルチメディアデータが無い旨を、参照ラベルと共にブラウザ１６に通知する（ステップＳ７２２）。ブラウザ１６は、この通知を受け取ると、マルチメディアデータが無い旨および参照ラベルを、モニタ（図示せず）に表示させ、そのユーザに通知する。
【００９５】
ファイルマネージャ１４は、未格納・要求マルチメディアデータの仮の管理情報がテーブル１３に登録されているが否かを判断する（ステップＳ７２３）。ファイルマネージャ１４は、仮の管理情報がある場合には、ステップＳ７２８（後述）に直接進む。ファイルマネージャ１４は、仮の管理情報が無い場合には、ステップＳ７２４〜Ｓ７２７を実行して、仮の管理情報を作成する。まず、ファイルマネージャ１４は、テーブル１３に新規領域を１列分追加する（ステップＳ７２４）。この新規フィールドには、参照ラベルとして、未格納・要求マルチメディアデータのデータ名が登録される（ステップＳ７２５）。格納時刻およびファイル名として、「−」が登録される（ステップＳ７２６）。つまり、未格納・要求マルチメディアデータは記憶装置１５に未格納であるから、その格納時刻およびファイル名は未定である。未定であることを示すために、格納時刻およびファイル名にはブランクを意味する「−」が登録される。さらに、参照フラグの初期値Ｎ1 および未参照時間の初期値Ｎ2 として「０」が登録される。また、保存係数の初期値Ｎ3 として「１」が登録される（ステップＳ７２７）。次に、ファイルマネージャ１４は、未格納・要求マルチメディアデータの管理情報の内、未参照時間および保存係数を処理対象として、テーブル１３から選択する（ステップＳ７２８）。選択された未参照時間の値Ｎ2 は「０」に設定される（ステップＳ７２９）。選択された保存係数の値Ｎ3 には、「１」が加算される（ステップＳ７３０）。
【００９６】
このように、未格納・要求マルチメディアデータについても、ブラウザ１６により要求された時点で、ステップＳ７２４〜７２７で仮の管理情報が作成される。これにより、他のマルチメディアデータがファイルマネージャ１４に到着した時と同様に、参照フラグの初期値Ｎ1 、未参照時間の初期値Ｎ2 および保存係数の初期値Ｎ3 として、「０」、「０」および「１」が登録される。さらに、この仮の管理情報の保存係数Ｎ3 は、さらに、この未格納・要求マルチメディアデータがブラウザ１６により要求されたという事実を反映させるため、ステップＳ７３０において「１」だけインクリメントされる。ファイルマネージャ１４は、未格納・要求マルチメディアデータが実際にファイルマネージャ１４に到着した時には、図５のステップＳ５１３〜Ｓ５１５を実行する。これによって、作成された仮の管理情報が通常の管理情報に承継されるので、未格納・要求マルチメディアデータもまた、記憶装置１５から削除されにくくなる。
【００９７】
また、本端末装置１では、デコーダ１２は、データ放送局２から放送形式により送信されてくるマルチメディアデータを継続的にデコードしファイルマネージャ１４に出力し、また、ブラウザ１６は、ユーザの指示に従ってマルチメディアデータをファイルマネージャ１４を介して参照する。つまり、デコーダ１２及びブラウザ１６は互いに独立して動作することとなる。これによって、放送形式により送信されるマルチメディアデータは、一度は記憶装置１５に格納されることとなる。しかしながら、記憶装置１５に格納されたマルチメディアデータは、ブラウザ１６による参照状況により削除される。これによって、記憶装置１５内には、ユーザの関心が高いマルチメディアデータのみが残ることとなる。その結果、記憶装置１５内のマルチメディアデータは、ユーザによってカスタマイズされることとなる。
【００９８】
また、本端末装置１では、ユーザは、現在参照中のマルチメディアデータに対し、新しいマルチメディアデータが記憶装置１５内に格納されたことを、ブラウザ１６に表示されるデータ格納通知により知ることができる（図５；ステップＳ５１０）。そのため、ユーザは、この新しいマルチメディアデータの到着をリアルタイムに知ることができる。また、新しいマルチメディアデータが格納されても、ユーザが古いマルチメディアデータを参照中であれば、当該古いマルチメディアデータは、記憶装置１５から削除されず（図５；ステップＳ５１６，Ｓ５１７）、ロックされることとなる。このように、ユーザが参照中のマルチメディアデータが、他のマルチメディアデータに勝手に切り替わることを防止すると共に、ユーザの望むタイミングで、表示するマルチメディアデータを切り替えることができる。
【００９９】
次に、本発明の第２の実施形態に係る端末装置１について説明する。この端末装置１は、第１の実施形態のそれと比較すると、以下の点でのみ相違する。第１の実施形態の端末装置１は、デコーダ１２から新しいマルチメディアデータが入力された時に、図５の処理を行っていた。しかし、第２の実施形態のファイルマネージャ１４は、新しいマルチメディアデータが入力された時に、図１７のフローチャートに示される処理を行う。これが、第１の実施形態と第２の実施形態との相違点である。第１および第２の実施形態の間には、これ以外に相違点はない。以下には、この相違点が中心に説明される。
【０１００】
今、端末装置１内では、第１の実施形態で説明したようにして、時間帯ＴＢ1 に配信されたＴｏｐｉｃ．ｈｔｍｌが要求マルチメディアデータとしてブラウザ１６により表示されていると仮定する。この仮定に従えば、図８（ｂ）に示すように、Ｓｕｂ１．ｈｔｍｌ、Ｓｕｂ２．ｈｔｍｌおよびＳｕｂ０．ｈｔｍｌが関連マルチメディアデータとして、ファイルマネージャ１４により選択される、テーブル１３には、図１８（ａ）のような管理情報が登録される。また、時間帯ＴＢ1 に配信されたこれらマルチメディアデータが要求マルチメディアデータまたは関連マルチメディアデータとして選ばれている状態で、端末装置１には、データ放送局２により時間帯ＴＢ2 に配信されたＴｏｐｉｃ．ｈｔｍｌ、Ｓｕｂ１、Ｓｕｂ２、Ｓｕｂ０．ｈｔｍｌおよびｘｘｘ．ｈｔｍｌ…が順次的に到着すると仮定する。
【０１０１】
ファイルマネージャ１４は、１ファイル分のマルチメディアデータの入力に起因して、この入力マルチメディアデータの管理情報を作成して記憶装置１５に格納する（ステップＳ１７１）。このステップＳ１７１は、サブルーチンステップであり、その詳細な処理のフローチャートが図１９に示される。この図１９は、ステップＳ１９１〜Ｓ１９１７を含む。このステップＳ１９１〜Ｓ１９１７の処理は、図５のステップＳ５１〜Ｓ５１７のそれと同じである。そのため、ステップＳ１９１〜Ｓ１９１７の説明は省略される。
【０１０２】
ファイルマネージャ１４は、新しいＴｏｐｉｃ．ｈｔｍｌ（時間帯ＴＢ2 に配信）が入力された場合には、ステップＳ１９１、Ｓ１９１１、Ｓ１９１２およびＳ１９２〜Ｓ１９１０を実行する。その結果、新しいＴｏｐｉｃ．ｈｔｍｌ用の仮の管理情報を作成しテーブル１３に登録すると共に、新しいＴｏｐｉｃ．ｈｔｍｌを記憶装置１５に格納する。新しいＴｏｐｉｃ．ｈｔｍｌの仮の管理情報は、参照ラベルとしてＴｏｐｉｃ．ｈｔｍｌ、格納時刻として０９：１９、ファイル名として０００２．ｈｔｍ、参照フラグの値Ｎ1 として「０」、未参照時間の値Ｎ2 として「０」および保存係数の値Ｎ3 として「１」を含む（図１８（ｂ）参照）。
【０１０３】
ところで、ブラウザ１６は、図２０（ａ）のような画面を必要に応じて表示して、表示ロックフラグを設定するか否かを設定するようにユーザを促す。ユーザは、ブラウザ１６を操作して表示ロックフラグをＯＮにするかＯＦＦにするかを設定する。ブラウザ１６は、ユーザにより設定された表示ロックフラグがＯＮかＯＦＦかをファイルマネージャ１４に通知する。ファイルマネージャ１４は、通知された表示ロックフラグを所定の記憶領域にラッチしておく。この表示ロックフラグは、ファイルマネージャ１４の判断で新しく入力されたマルチメディアデータをブラウザ１６に強制的に表示させるか否かを示すための情報である。つまり、表示ロックフラグがＯＮの場合には、ファイルマネージャ１４は、ブラウザ１６からの参照要求が入力されない限り、マルチメディアデータを記憶装置１５から取り出さない。つまり、第１の実施形態と同様である。しかし、表示ロックフラグがＯＦＦの場合には、ファイルマネージャ１４は、ブラウザ１６からの参照要求がなくとも、今回新しく入力されたマルチメディアデータが所定の条件を満たす場合には、この条件を満たすマルチメディアデータをブラウザ１６に強制的に表示させる。この所定の条件は、ステップＳ１７３を意味する。
【０１０４】
ファイルマネージャ１４は、ステップＳ１７１の次に、ラッチされている表示ロックフラグがＯＮであるかＯＦＦであるかを調べる（ステップＳ１７２）。ファイルマネージャ１４は、表示ロックフラグがＯＮの場合には、入力されたマルチメディアデータを強制的にブラウザ１６に表示させる必要がないと判断して、図１７の処理を終了する。一方、ファイルマネージャ１４は、表示ロックフラグがＯＦＦの場合には、ブラウザ１６が入力されたマルチメディアデータをリアルタイムに表示することを要求していると判断して、ステップＳ１７３に進む。
【０１０５】
ステップＳ１７３において、ファイルマネージャ１４は、まず最初に、今回入力されたマルチメディアデータの参照ラベルと一致する参照ラベル、つまり古いマルチメディアデータの参照ラベルがテーブル１３に登録されているか否かを判断する。さらに、ファイルマネージャ１４は、一致する参照ラベルがある場合には、古いマルチメディアデータの参照ラベルに対応する参照フラグの値Ｎ1 が「１」以上か否かを判断する（ステップＳ１７３）。この条件の満たす場合、今回入力されたマルチメディアデータは、ブラウザ１６により現在表示されている要求マルチメディアデータまたは関連マルチメディアデータと同一性があり、かつ新しいものである。
【０１０６】
ファイルマネージャ１４は、ステップＳ１７３の条件が満たされる場合には、ステップＳ１７４に進む。一方、この条件が満たされない場合には、図１７の処理が終了する。上述したように、現在、古いＴｏｐｉｃ．ｈｔｍｌ（ファイル名０００１．ｈｔｍ）がユーザにより参照されているので、その管理情報の参照フラグの値Ｎ1 は「１」に設定されている。また、今回入力されたのは新しいＴｏｐｉｃ．ｈｔｍｌ（ファイル名０００２．ｈｔｍ）であるから、ステップＳ１７３の条件が満たされることとなる。ステップＳ１７３の条件が満たされる場合、後のステップＳ１７７の処理で、今回入力されたマルチメディアデータはブラウザ１６により表示される。そのため、要求マルチメディアデータの場合と同様に、今回入力されたマルチメディアデータもまた、記憶装置１５から削除されにくくする必要がある。
【０１０７】
そこで、ファイルマネージャ１４は、今回入力されたマルチメディアデータの管理情報を処理対象として選択して（ステップＳ１７４）、現時点では、保存係数の値Ｎ3 を「１」だけインクリメントする（ステップＳ１７５）。その結果、新しいＴｏｐｉｃ．ｈｔｍｌ（ファイル名０００２．ｈｔｍ）の保存係数Ｎ3 は「２」となる（図１８（ｃ）参照）。次に、ファイルマネージャ１４は、現時点でブラウザ１６により表示されているマルチメディアデータのファイル名を所定の記憶領域にラッチする（ステップＳ１７６）。
【０１０８】
次に、ファイルマネージャ１４は、今回入力されたマルチメディアデータを記憶装置１５から取り出す。さらに、ファイルマネージャ１４は、データ表示指示という信号を生成して、取り出したマルチメディアデータと共にブラウザ１６に出力する（ステップＳ１７７）。データ表示指示は、同時に出力されたマルチメディアデータをブラウザ１６に強制的に表示させるための信号である。ブラウザ１６は、データ表示指示が入力されると、現在表示されているマルチメディアデータの表示を中止して、新しく入力されたマルチメディアデータを表示する。その結果、今回の場合、ブラウザ１６の表示は、古いマルチメディアデータ（参照ラベルがＴｏｐｉｃ．ｈｔｍｌかつファイル名が０００１．ｈｔｍ）から新しいマルチメディアデータ（参照ラベルがＴｏｐｉｃ．ｈｔｍｌかつファイル名が０００２．ｈｔｍ）に切り替わる。
【０１０９】
以上のように第２の実施形態の端末装置１では、ファイルマネージャ１４は、ブラウザ１６が表示中のマルチメディアデータ（要求マルチメディアデータ）または関連マルチメディアデータと同一性を有する新しいマルチメディアデータが入力されると、その入力された新しいマルチメディアデータをブラウザ１６に出力し表示させることを特徴としている。これによって、ブラウザ１６は、ファイルマネージャ１４に参照要求を出力することなく、ユーザの関心が高くかつ新しいマルチメディアデータをリアルタイムにファイルマネージャ１４から取得し、表示することができる。これによって、端末装置１の使い勝手がよくなる。なお、以上の説明では、表示されていたマルチメディアデータ（参照ラベルがＴｏｐｉｃ．ｈｔｍｌかつファイル名が０００１．ｈｔｍ）と、新規入力されたマルチメディアデータ（参照ラベルがＴｏｐｉｃ．ｈｔｍｌかつファイル名が０００２．ｈｔｍ）とは同一性という関係があった。しかしながら、表示されていたマルチメディアデータ（参照ラベルがＴｏｐｉｃ．ｈｔｍｌかつファイル名が０００１．ｈｔｍ）と、新規入力されたマルチメディアデータ（例えば、参照ラベルがＳｕｂ１．ｈｔｍｌ）とが関連性があるという関係でも、図１７のステップＳ１７１〜Ｓ１７７は同様に行われる。
【０１１０】
ところで、ブラウザ１６は、図２０（ｂ）のような画面を必要に応じて表示して、復帰フラグを設定するか否かを設定するようユーザを促す。ユーザは、ブラウザ１６を操作して復帰フラグをＯＮにするかＯＦＦにするかを設定する。ブラウザ１６は、ユーザにより設定された復帰フラグがＯＮかＯＦＦかをファイルマネージャ１４に通知する。ファイルマネージャ１４は、通知された復帰フラグを所定の記憶領域にラッチしておく。この復帰フラグは、ブラウザ１６がデータ表示指示と共に入力されたマルチメディアデータを継続的に表示するか、一定時間が経過すると元のマルチメディアデータを再表示するかを示す情報である。つまり、ブラウザ１６は、復帰フラグをＯＮに設定して、一定時間が経過すると元のマルチメディアデータを再表示することをファイルマネージャ１４に要求する。一方、ブラウザ１６は、復帰フラグをＯＦＦに設定して、データ表示指示と共に入力されたマルチメディアデータを継続的に表示することを要求する。
【０１１１】
ファイルマネージャ１４は、ステップＳ１７７の次に、ラッチされている復帰フラグがＯＮであるかＯＦＦであるかを調べる（ステップＳ１７８）。ファイルマネージャ１４は、復帰フラグがＯＦＦの場合には、ステップＳ１７７で出力したマルチメディアデータの継続的な表示をユーザが要求していると判断する。つまり、ファイルマネージャ１４は、今回入力されたマルチメディアデータを要求マルチメディアデータと決定する。そこで、ファイルマネージャ１４は、図１８（ｄ）に示すように、ステップＳ１７４で選択された管理情報の参照フラグの値Ｎ1 を「１」に更新する（ステップＳ１７９）。これによって、今回入力されたマルチメディアデータは、現在、ユーザにより参照されている要求マルチメディアデータと決定され、継続的に表示される。
【０１１２】
これによって、ステップＳ１７６でラッチされたファイル名が不必要となるので、ファイルマネージャ１４は、このファイル名を削除する（ステップＳ１７１０）。次に、ファイルマネージャ１４は、決定した要求マルチメディアデータについて関連性を有する関連マルチメディアデータの管理情報を更新する（ステップＳ１７１１）。このステップＳ１７１１は、サブルーチンステップであり、その詳細な処理のフローチャートが図２１に示される。この図２１は、ステップＳ２１１〜Ｓ２１１５を含む。このステップＳ２１１〜Ｓ２１１５の処理は、図９のステップＳ７７〜Ｓ７２１のそれと同じである。そのため、ステップＳ２１１〜Ｓ２１１５の説明は省略される。これによって、関連マルチメディアデータが記憶装置１５から削除されにくくなる。
【０１１３】
また、ファイルマネージャ１４は、ステップＳ１７８において、復帰フラグがＯＮの場合には、一定時間が経過すると元のマルチメディアデータを再表示するようにユーザが要求していると判断する。ファイルマネージャ１４は、次に、表示ロックフラグがＯＮであるかＯＦＦであるかを判断した後に（ステップＳ１７１２）、ステップＳ１７７で今回入力されたマルチメディアデータを出力してから一定時間が経過したか否かを判断する（ステップＳ１７１３）。
【０１１４】
例えば、現在、ユーザは、ステップＳ１７７で出力された新しいマルチメディアデータを参照している。ユーザは、このマルチメディアデータに対して高い関心を持つと、図２０（ａ）に示す表示ロックフラグをＯＮに設定する。ファイルマネージャ１４は、上記一定時間が経過する前に、表示ロックフラグがＯＮに設定されると、上述したステップＳ１７９に進む。これによっても、今回入力されたマルチメディアデータは、現在、ユーザにより参照されている要求マルチメディアデータと決定される。
【０１１５】
以上説明したように、ファイルマネージャ１４は、ブラウザ１６による指示に基づいて、自身に新しく入力されたマルチメディアデータをブラウザ１６へと出力しないようになる。つまり、表示ロックフラグがＯＦＦに設定され続けると、ファイルマネージャ１４は、ステップＳ１７２からＳ１７３に移行するので、新しく到着したマルチメディアデータを順次継続的ブラウザ１６に表示させることとなる。つまり、ブラウザ１６は、マルチメディアデータが入力される度に、その表示を切り換える。しかしながら、ステップＳ１７１１の時点で表示ロックフラグがＯＮであれば、ファイルマネージャ１４は、新しく入力されたマルチメディアデータの出力を停止することとなる。なぜなら、ステップＳ１７２の判断で、表示ロックフラグがＯＮと判断されるからである。このように、ブラウザ１６は、必要に応じてマルチメディアデータの出力停止をファイルマネージャ１４に対して要求することができる。これによって、ブラウザ１６は順次継続的に入力されるものの内、特定のマルチメディアデータを長時間表示することができるようになる。これによって、端末装置の使い勝手がさらに向上させることができる。
【０１１６】
一方、ファイルマネージャ１４は、ステップＳ１７１３で一定時間が経過したと判断すると、ユーザがステップＳ１７７で出力された新しいマルチメディアデータに対して関心を抱かなかったとみなして、ステップＳ１７６で保存されたファイル名を持つマルチメディアデータを記憶装置１５から取り出す。さらに、ファイルマネージャ１４は、データ再表示指示という信号を生成して、取り出したマルチメディアデータと共にブラウザ１６に出力する（ステップＳ１７１４）。データ再表示指示は、同時に出力されたマルチメディアデータをブラウザ１６に強制的に表示させるための信号である。ブラウザ１６は、データ再表示指示が入力されると、現在表示されているマルチメディアデータの表示を中止して、再入力されたマルチメディアデータを表示する。その結果、今回の場合、ブラウザ１６の表示は、新しいマルチメディアデータ（参照ラベルがＴｏｐｉｃ．ｈｔｍｌかつファイル名が０００２．ｈｔｍ）から古いマルチメディアデータ（参照ラベルがＴｏｐｉｃ．ｈｔｍｌかつファイル名が０００１．ｈｔｍ）に切り替わる。
【０１１７】
以上説明したように、ファイルマネージャ１４は、入力された新しいマルチメディアデータをブラウザ１６に表示させた後に一定時間が経過すると、直前に表示されていたマルチメディアデータを再表示させる。これによって、ファイルマネージャ１４は、新しいマルチメディアデータをブラウザ１６にリアルタイムで表示させると共に、一定時間経過後に、その直前に表示されていたマルチメディアデータをブラウザ１６に再表示させる。この一連の処理は、ファイルマネージャ１４により自動的に行われるので、ユーザに対して特別の操作を要求しない。これによって、端末装置の使い勝手をさらに向上させることができる。
【０１１８】
なお、以上の実施形態では、マルチメディアデータを例として説明したが、データ（典型的には、音声データまたは映像データ）に対しても、本端末装置１を適用することができる。
【図面の簡単な説明】
【図１】本発明の第１または第２の実施形態に係る端末装置１の構成を示すブロック図である。
【図２】図１のデータ放送局２により配信されたマルチメディアデータの一例を示す図である。
【図３】図１のファイルマネージャ１４が作成し管理する管理情報を説明するための図である。
【図４】図１に示すデコーダ１２とファイルマネージャ１４との処理の概要を説明するための図である。
【図５】図１のファイルマネージャ１４が、１ファイル分のマルチメディアデータの入力に起因して実行する処理のフローチャートである。
【図６】図１のブラウザ１６とファイルマネージャ１４との処理の概要を説明するための図である。
【図７】図１のファイルマネージャ１４が、参照要求の入力に起因して実行する処理のフローチャートである。
【図８】データ放送局２により配信される各マルチメディアデータのハイパーリンク、およびリンクレベルを説明するための図である。
【図９】図７のフローチャートの続きの処理を示すフローチャートである。
【図１０】図１のファイルマネージャ１４が管理する管理情報の時間遷移を説明するための図である。
【図１１】ブラウザ１６が検索範囲の値Ｍを設定するようにユーザを促すために生じさせる画面を示す図である。
【図１２】図１のファイルマネージャ１４が１分毎に実行する処理のフローチャートである。
【図１３】図１のファイルマネージャ１４が参照終了通知の入力に起因して実行する処理のフローチャートである。
【図１４】図１のファイルマネージャ１４が管理する管理情報の時間遷移を説明するための図である。
【図１５】図１のファイルマネージャ１４が行う承継処理の概要を説明するための図である。
【図１６】図１のファイルマネージャ１４が管理する管理情報の時間遷移を説明するための図である。
【図１７】本発明の第２の実施形態に係る端末装置１が、１ファイル分のマルチメディアデータの入力に起因して実行する処理のフローチャートである。
【図１８】図１のファイルマネージャ１４が管理する管理情報の時間遷移を説明するための図である。
【図１９】図１７のサブルーチンステップＳ１７１の詳細な処理を示すフローチャートである。
【図２０】ブラウザ１６が表示ロックフラグまたは復帰フラグを設定するようにユーザを促すために生じさせる画面を示す図である。
【図２１】図１７のサブルーチンステップＳ１７１０の詳細な処理を示すフローチャートである。
【符号の説明】
１…端末装置
１１…チューナー
１２…デコーダ
１３…テーブル
１４…ファイルマネージャ
１５…記憶装置
１６…ブラウザ
２…データ放送局
【図１】
0004215334.tif 000002
【図２】
0004215334.tif 000003
【図３】
0004215334.tif 000004
【図４】
0004215334.tif 000005
【図５】
0004215334.tif 000006
【図６】
0004215334.tif 000007
【図７】
0004215334.tif 000008
【図８】
0004215334.tif 000009
【図９】
0004215334.tif 000010
【図１０】
0004215334.tif 000011
【図１１】
0004215334.tif 000012
【図１２】
0004215334.tif 000013
【図１３】
0004215334.tif 000014
【図１４】
0004215334.tif 000015
【図１５】
0004215334.tif 000016
【図１６】
0004215334.tif 000017
【図１７】
0004215334.tif 000018
【図１８】
0004215334.tif 000019
【図１９】
0004215334.tif 000020
【図２０】
0004215334.tif 000021
【図２１】
0004215334.tif 000022