(57)【要約】【課題】  メモリ量が制限された環境であっても、ユーザが必要とするデータをより多くキャッシュし、データ画面遷移時のユーザの待ち時間を軽減することがかのうなデータ受信装置を提供すること。  【解決手段】  受信装置は、データ再生部、ＴＳ受信部、ＴＳ分離部、映像音声デコード部、ＥＰＧや静止画表示アプリケーションおよびメニューアプリケーションなどのアプリケーション、ユーザ入力受信部、および出力部から構成される。  データ再生部はデータキャッシュ部を備え、データキャッシュ部は、アプリケーションの起動終了など状態変化通知を受けて、アプリケーション起動時にはそのアプリケーションが使用するメモリ量分のキャッシュを解放し、終了時にはそのメモリ量分のキャッシュを再度確保し、データのキャッシュを行う。【選択図】  図１
2005123942.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークからデータを受信、提示する受信装置であって、
ブラウザと、
ブラウザ以外のアプリケーションとを備え、前記ブラウザが、
データを受信する受信手段と、
前記受信手段が受信したデータをキャッシュするキャッシュ手段と、
キャッシュするデータを記憶するキャッシュ記憶領域と、
他のアプリケーションの状態の通知を受けるアプリケーション状態受信手段と、
前記アプリケーション状態受信手段からの通知を受けて前記キャッシュ手段がキャッシュ可能なデータの合計サイズを決定するキャッシュサイズ決定手段とを、
備えることを特徴とする受信装置。
【請求項２】
ネットワークからデータを受信、提示する受信装置であって、
少なくとも１つ以上のブラウザと、
少なくとも１つ以上のブラウザ以外のアプリケーションと、
前記ブラウザがキャッシュするデータを記憶するキャッシュ記憶領域とを備え、
前記ブラウザが、
データを受信する受信手段と、
前記受信手段が受信したデータをキャッシュするキャッシュ手段と、
他のアプリケーションの状態の通知を受けるアプリケーション状態受信手段と、
前記アプリケーション状態受信手段からの通知を受けて前記キャッシュ手段がキャッシュ可能なデータの合計サイズを決定するキャッシュサイズ決定手段とを、
備えることを特徴とする受信装置。
【請求項３】
前記アプリケーション状態受信手段は、他のアプリケーションが必要とするデータサイズを通知することを特徴とする、
請求項１または２記載の受信装置。
【請求項４】
前記キャッシュ決定手段は、少なくとも前記アプリケーション受信手段が受信した前記データサイズからキャッシュ可能なデータの合計サイズを決定することを特徴とする、
請求項３記載の受信装置。
【請求項５】
前記キャッシュサイズ決定手段は、少なくともアプリケーションを識別するアプリケーション識別情報と、前記アプリケーションが必要とするデータサイズから構成されるデータ利用量リストを保持することを特徴とする、
請求項１または２記載の受信装置。
【請求項６】
前記アプリケーション状態受信手段は、アプリケーションが起動または終了する時に、少なくとも前記アプリケーション識別情報とアプリケーションの状態を受信し、前記キャッシュサイズ決定手段は、前記アプリケーション識別情報と、前記アプリケーションの状態と、前記データ利用量リストから、キャッシュ可能なデータの合計サイズを決定することを特徴とする、
請求項５記載の受信装置。
【請求項７】
前記受信手段は、前記データ利用量リストを受信し、前記キャッシュサイズ決定手段は、前記データ利用量リストのデータサイズを書き換えることを特徴とする、
請求項５記載の受信装置。
【請求項８】
前記キャッシュサイズ決定手段が決定したキャッシュ可能なデータの合計サイズよりもキャッシュ済みのデータサイズが大きい場合に、前記キャッシュ手段は、キャッシュ可能なデータの合計サイズ以下になるようにキャッシュ済みのデータを削除することを特徴とする、
請求項１または２または３または４記載の受信装置。
【請求項９】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、参照回数が少ないデータを優先的に削除することを特徴とする、
請求項８記載の受信装置。
【請求項１０】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、取得日時が古いものを優先的に削除することを特徴とする、
請求項８記載の受信装置。
【請求項１１】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、次に送信される時刻が近いデータを優先的に削除することを特徴とする、請求項８記載の受信装置。
【請求項１２】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、サイズが大きいデータを優先的に削除することを特徴とする、
請求項８記載の受信装置。
【請求項１３】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、有効状態になっていない前記ブラウザのデータを優先的に削除することを特徴とする、
請求項８記載の受信装置。
【請求項１４】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、最後にキャッシュした時刻が古い前記ブラウザのデータを優先的に削除することを特徴とする、
請求項８記載の受信装置。
【請求項１５】
前記キャッシュ手段は、繰り返し送信されるデータの周期をキャッシュすることを特徴とする、
請求項１または２または８記載の受信装置。
【請求項１６】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、繰り返し送信されるデータの周期が短いデータを優先的に削除することを特徴とする、
請求項１５記載の受信装置。
【請求項１７】
前記キャッシュ手段は、サーバーにリクエストして取得するデータの、リクエストしてから取得するまでの時間をキャッシュすることを特徴とする、
請求項１または２または８記載の受信装置。
【請求項１８】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、サーバーにリクエストしてから取得するまでの時間が短いデータを優先的に削除することを特徴とする、
請求項１７記載の受信装置。
【請求項１９】
前記キャッシュ手段がキャッシュ済みのデータを削除するときに、繰り返し送信されるデータの周期の半分と、サーバーにリクエストしてから取得するまでの時間を比較し、最も短いものから優先的に削除することを特徴とする、
請求項１５または１７記載の受信装置。
【請求項２０】
ブラウザ以外のアプリケーションが利用するデータのサイズからキャッシュ可能なデータのサイズを決定するキャッシュサイズ決定手順と、
キャッシュ済みのデータのサイズと前記キャッシュ可能なデータのサイズとを比較しキャッシュ済みのデータの削除が必要かを判定するキャッシュ削除判定手順と、
前記キャッシュ削除判定手順においてキャッシュ済みのデータの削除が必要と判定した場合に、どのキャッシュ済みのデータを削除するかを決定する削除データ決定手順と、
前記削除データ決定手順で決定されたデータを削除するデータ削除手順とを備えることを特徴とするキャッシュデータ管理方法。
【請求項２１】
一つ以上のブラウザが存在し、ブラウザを含むアプリケーションが利用するデータのサイズからキャッシュ可能なデータのサイズを決定するキャッシュサイズ決定手順と、
キャッシュ済みのデータのサイズと前記キャッシュ可能なデータのサイズとを比較しキャッシュ済みのデータの削除が必要かを判定するキャッシュ削除判定手順と、
前記キャッシュ削除判定手順においてキャッシュ済みのデータの削除が必要と判定した場合に、どのキャッシュ済みのデータを削除するかを決定する削除データ決定手順と、
前記削除データ決定手順で決定されたデータを削除するデータ削除手順とを備えることを特徴とするキャッシュデータ管理方法。
【請求項２２】
前記削除データ決定手順は、参照回数が少ないデータを優先的に削除対象にすることを特徴とする、
請求項２０または２１記載のキャッシュデータ管理方法。
【請求項２３】
前記削除データ決定手順は、取得日時が古いものを優先的に削除対象にすることを特徴とする、
請求項２０または２１記載のキャッシュデータ管理方法。
【請求項２４】
前記削除データ決定手順は、次に送信される時刻が近いデータを優先的に削除対象にすることを特徴とする、
請求項２０または２１記載のキャッシュデータ管理方法。
【請求項２５】
前記削除データ決定手順は、サイズが大きいデータを優先的に削除対象にすることを特徴とする、
請求項２０または２１記載のキャッシュデータ管理方法。
【請求項２６】
前記削除データ決定手順は、有効状態でないブラウザのデータを優先的に削除対象にすることを特徴とする、
請求項２１記載のキャッシュデータ管理方法。
【請求項２７】
前記削除データ決定手順は、最後にキャッシュを使用した時刻が古いブラウザのデータを優先的に削除対象にすることを特徴とする、
請求項２１記載のキャッシュデータ管理方法。
【請求項２８】
前記削除データ決定手順は、繰り返し送信されるデータの周期が短いデータを優先的に削除対象にすることを特徴とする、
請求項２０または２１記載のキャッシュデータ管理方法。
【請求項２９】
前記削除データ決定手順は、サーバーにリクエストしてから取得するまでの時間が短いデータを優先的に削除対象にすることを特徴とする、
請求項２０または２１記載のキャッシュデータ管理方法。
【請求項３０】
前記削除データ決定手順は、サーバーにリクエストしてから取得するまでの時間が短いデータを優先的に削除対象にすることを特徴とする、
請求項２０または２１記載のキャッシュデータ管理方法。
【請求項３１】
前記削除データ決定手順は、繰り返し送信されるデータの周期の半分と、サーバーにリクエストしてから取得するまでの時間を比較し、時間が短いデータを優先的に削除対象にすることを特徴とする、
請求項２０または２１記載のキャッシュデータ管理方法。
【請求項３２】
ブラウザ以外のアプリケーションが利用するデータのサイズからキャッシュ可能なデータのサイズを決定するキャッシュサイズ決定処理と、
キャッシュ済みのデータのサイズと前記キャッシュ可能なデータのサイズとを比較しキャッシュ済みのデータの削除が必要かを判定するキャッシュ削除判定処理と、
前記キャッシュ削除判定処理においてキャッシュ済みのデータの削除が必要と判定した場合に、どのキャッシュ済みのデータを削除するかを決定する削除データ決定処理と、
前記削除データ決定手順で決定されたデータを削除するデータ削除処理とを備えることを特徴とするキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項３３】
一つ以上のブラウザが存在し、ブラウザを含むアプリケーションが利用するデータのサイズからキャッシュ可能なデータのサイズを決定するキャッシュサイズ決定処理と、
キャッシュ済みのデータのサイズと前記キャッシュ可能なデータのサイズとを比較しキャッシュ済みのデータの削除が必要かを判定するキャッシュ削除判定処理と、
前記キャッシュ削除判定処理においてキャッシュ済みのデータの削除が必要と判定した場合に、どのキャッシュ済みのデータを削除するかを決定する削除データ決定処理と、
前記削除データ決定手順で決定されたデータを削除するデータ削除処理とを備えることを特徴とするキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項３４】
前記削除データ決定処理は、参照回数が少ないデータを優先的に削除対象にすることを特徴とする、
請求項３２または３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項３５】
前記削除データ決定処理は、取得日時が古いものを優先的に削除対象にすることを特徴とする、
請求項３２または３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項３６】
前記削除データ決定処理は、次に送信される時刻が近いデータを優先的に削除対象にすることを特徴とする、
請求項３２または３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項３７】
前記削除データ決定処理は、サイズが大きいデータを優先的に削除対象にすることを特徴とする、
請求項３２または３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項３８】
前記削除データ決定処理は、有効状態でないブラウザのデータを優先的に削除対象にすることを特徴とする、
請求項３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項３９】
前記削除データ決定処理は、最後にキャッシュを使用した時刻が古いブラウザのデータを優先的に削除対象にすることを特徴とする、
請求項３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項４０】
前記削除データ決定処理は、繰り返し送信されるデータの周期が短いデータを優先的に削除対象にすることを特徴とする、
請求項３２または３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項４１】
前記削除データ決定処理は、サーバーにリクエストしてから取得するまでの時間が短いデータを優先的に削除対象にすることを特徴とする、
請求項３２または３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項４２】
前記削除データ決定処理は、サーバーにリクエストしてから取得するまでの時間が短いデータを優先的に削除対象にすることを特徴とする、
請求項３２または３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【請求項４３】
前記削除データ決定手順は、繰り返し送信されるデータの周期の半分と、サーバーにリクエストしてから取得するまでの時間を比較し、時間が短いデータを優先的に削除対象にすることを特徴とする、
請求項３２または３３記載のキャッシュデータ管理プログラムまたは前記プログラムを記録した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークから送られるデータを受信する受信装置に係り、特に伝送されるデータのキャッシュ制御技術に関する。
【背景技術】
【０００２】
デジタル放送などで放送されるデータ放送は、同一のデータを繰り返し放送することによって実現されている。この繰り返し放送するデータの集合をデータカルーセルと呼び、データカルーセルを送出する方式をデータカルーセル送出方式と呼ぶ。
この方式では、同一のデータを数秒から数十秒の周期で繰り返し送出するため、視聴者がいつデータの視聴要求を出したとしても必要なデータを必ず受信することができる。しかし、同一伝送帯域で大容量のデータを送出する場合、データカルーセル周期が長くなり、このデータ受信待ち時間が画面切替のレスポンスに大きな影響を与えることになる。
【０００３】
そこで、一般的には一度取得したデータのキャッシュ、または先読みしてキャッシュする手法が取られている。しかし、受信機の内蔵メモリの容量は有限であり、伝送される全てのデータを保持することは不可能である。そのため、ユーザが要求するデータがキャッシュに存在する確率すなわちキャッシュヒット率を向上させるための工夫もなされている。
【０００４】
特許文献１の発明では、あらかじめ調べた各データの送出状況を元に、送出される時刻が近いデータをキャッシュから優先的に消去する手法が提案されている。
別のアプローチとしては、特許文献２の発明では、データを圧縮してキャッシュすることにより、見かけ上のキャッシュのサイズを拡張し、キャッシュヒット率の向上を図っている。
【特許文献１】特開２００１−３２６５８１公報
【特許文献２】特開２００３−３２６３０公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
そもそも、送出されるデータのサイズがキャッシュ領域のサイズより大きい場合、キャッシュできないデータが存在し、このデータの取得にユーザが長時間待たされることになる。特許文献１記載の発明では、この問題を解決できない。
また特許文献１記載の発明では、１画面分のデータ画面表示に必要な複数のデータのそれぞれの送出タイミングがそれぞれ離れている場合、十分なキャッシュ効果が期待できない場合がある。
【０００６】
また、現在のデータ放送では、送出側においてデータを圧縮して送る運用が実施されており、特許文献２記載の発明の場合、データに含まれる静止画画像の展開および再圧縮、データ全体の再圧縮処理が必要となり、受信装置のデータ処理能力の低下を招いてしまい、結果としてユーザの待ち時間に影響する。
本発明は、これらの課題を鑑みてなされたものであり、受信装置において、データのキャッシュ領域をより大きく確保することによってキャッシュヒット率を向上させ、ユーザのデータ画面切替の待ち時間を軽減することを目的とする。
【課題を解決するための手段】
【０００７】
上記した目的を達成するために、本発明の受信装置は、ネットワークからデータを受信する受信手段と、前記受信手段が受信したデータをキャッシュするキャッシュ手段と、他のアプリケーションの状態の通知を受けるアプリケーション状態受信手段と、前記アプリケーション状態受信手段からの通知を受けて前記キャッシュ手段がキャッシュ可能なデータの合計サイズを決定するキャッシュサイズ決定手段とを備え、他のアプリケーションが起動していない間には最大限のメモリを確保することにより、より多くのデータをキャッシュし、他のアプリケーションが起動する際にそのアプリケーションが利用する分のメモリを開放し、必要に応じてキャッシュ済みデータを削除するが、ユーザから要求される確率の高いデータを残すことにより、キャッシュヒット率の低下を最小限に抑えることを特徴とする。
【発明の効果】
【０００８】
以上のように、本発明によれば、他のアプリケーションが動作していない間は最大限のメモリを確保できるため、キャッシュを捨てる必要がなく、特許文献１記載の発明に対してキャッシュヒット率を向上させ、キャッシュによるデータ画面切替の時間を短縮することが可能である。
また、本発明は、キャッシュ領域を大きく確保することが可能となるため、データを圧縮・展開する処理は不要となり、特許文献２記載の発明におけるデータ圧縮・展開処理によるパフォーマンス低下およびデータ画面切替時間の増加がない。
【０００９】
また、他のアプリケーションが起動する際にも、ユーザが視聴する可能性の高いデータを保持するため、キャッシュ用メモリ削減によるキャッシュ効果の低下を最小限に防ぐことが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下本発明の実施の形態について、図面を参照しながら説明する。
（実施の形態１）
図１を用いて本発明の実施の形態を詳細に説明する。図１は本発明の一形態である受信装置１００の構成を示すブロック図である。
図１において、受信装置１００は、データ再生部３００、ＴＳ受信部１１０、ＴＳ分離部１２０、映像音声デコード部１３０、ＥＰＧや静止画表示アプリケーションおよびメニューアプリケーションなどのアプリケーション１４０、ユーザ入力受信部１５０、および出力部１６０から構成される。
【００１１】
アプリケーション１４０は、ユーザからのリモコン操作などによって起動または終了され、番組表や、静止画、受信装置１００の設定を行う画面を表示するための画像を生成し、出力部１６０に出力する。例えば、番組表を表示するＥＰＧ（Ｅｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ）や受信装置に装着したメモリカードに記録されている静止画を表示する静止画ビューワ、や受信機設定を行うメニューアプリなどがある。
【００１２】
アプリケーション１４０は、起動時、終了時および、自アプリケーションが必要とするメモリサイズの変更があるときに、データ再生部３００のアプリ通信部３４０に対して、自アプリケーションのメモリサイズの変更量（以下メモリサイズ変化量と呼ぶ）を通知する。例えば、起動時であれば、自アプリケーションが必要なメモリサイズを通知し、終了時であれば、その時点で自アプリケーションが使用していたメモリサイズを通知する。メモリサイズの変更時には変更するメモリサイズを通知する。例えば、メモリサイズ変化量が１メガバイトである場合、アプリケーションは自アプリケーションが動作するために１メガバイト必要とするを意味する。また、メモリサイズ変化量がマイナス１メガバイトである場合、自アプリケーションは１メガバイト分のメモリが不要になったことを意味する。
【００１３】
ユーザ入力受信部１５０は、ユーザからのリモコン操作などによる入力信号を受信し、データ再生部３００のデータ解釈表示部３５０やアプリケーション１４０にその信号を出力する。
受信部３０２は映像信号、音声信号およびデータが多重化されたＭＰＥＧ２−ＴＳ（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）を受信する。ＭＰＥＧ２−ＴＳについては、ＩＳＯ／ＩＥＣ１３８１８−１  ＭＰＥＧ２ＳＹＳＴＥＭＳにて定められている。
【００１４】
ＴＳ分離部１２０は、受信部３０２が受信したＭＰＥＧ２−ＴＳを映像信号、音声信号、データ信号に分離する。
映像音声デコード部１３０は、ＴＳ分離部１２０によって分離された映像信号、音声信号をデコードし、出力部１６０に出力する。
出力部１６０は、映像音声デコード部１３０からの映像信号とデータ解釈表示部３５０やアプリケーション１４０からの表示画像を重畳し、映像音声デコード部１３０からの音声信号とともに出力する。
【００１５】
（データ再生部３００の詳細な説明）
データ再生部３００は、データ受信部３１０、データキャッシュ部３２０、キャッシュ記憶部３３０、アプリ通信部３４０およびデータ解釈表示部３５０から構成される。
データ信号は、ＴＳ分離部１２０が受信したＭＰＥＧ２−ＴＳから分離され、データ受信部３１０に送られる。ＴＳ分離部１２０はＭＰＥＧ２−ＴＳを受信するチューナーおよびトランスポートデコーダなどによって実現されるが、このことに制限されるものではない。
【００１６】
データ受信部３１０は、データストリームからデータモジュールを取り出して、データキャッシュ部３２０に送る。ここで、データモジュールとは、ＩＳＯ／ＩＥＣ１３８１８−６  ＤＳＭＣＣ（Ｄｉｇｉｔａｌ  Ｓｔｏｒａｇｅ  Ｍｅｄｉａ  Ｃｏｍｍａｎｄ  ａｎｄ  Ｃｏｎｔｒｏｌ）にて定められているデータの単位である。
データキャッシュ部３２０は、送られたデータモジュールがキャッシュ記憶部３３０に存在するかを確認し、存在していなければキャッシュ記憶部３３０に蓄積する。データキャッシュ部３２０は、キャッシュリスト４００と、図示しないキャッシュ上限値と、図示しないキャッシュサイズ値を保持し、送られたデータモジュールのサイズとキャッシュサイズ値の合計がキャッシュ上限値を超える場合には、キャッシュリスト４００を元に不要なキャッシュ済みのデータを削除または、送られたデータモジュールを削除するとともにキャッシュリスト４００を更新する。データキャッシュ部３２０は、アプリ通信部ＡＰＣから受け取ったコマンドを元に、キャッシュサイズ上限値を変化させ、キャッシュサイズ値がキャッシュ上限値を超える場合には、キャッシュリスト４００を元に不要なキャッシュ済みのデータを削除するとともにキャッシュリスト４００を更新する。
【００１７】
データキャッシュ部３２０は、データ解釈表示部３５０からのデータモジュールの取得要求にしたがってキャッシュ記憶部３３０からデータを読み出し、データ解釈表示部３５０に出力する。このとき、データキャッシュ部３２０は、取得要求を受けたデータモジュールに対して、キャッシュリスト４００の当該モジュールの参照回数の値をインクリメントする。
【００１８】
キャッシュ記憶部３３０は、データキャッシュ部３２０がキャッシュするデータを格納する。半導体メモリや不揮発性メモリ、ハードディスク、ＤＶＤなどデータの読み書きができる記録媒体で構成されるが、特に種類を制限するものではない。
データ解釈表示部３５０は、ユーザ入力受信部１５０からリモコン入力信号を受け、その信号内容に従ってデータを解釈実行し、表示画像の切替や新たなデータの取得要求を行う。データ解釈表示部３５０は、新たなデータの取得要求が生じた時に、データキャッシュ部３２０またはデータ受信部３１０からデータモジュールを取得し、データを解釈し、表示画像を作成し、出力部１６０に入力する。
【００１９】
アプリ通信部３４０は、アプリケーション１４０（ＥＰＧ、静止画表示アプリ、メニューアプリなど）との通信を行い、アプリケーション１４０からそのアプリケーションが使用するメモリサイズの変化量の通知を受ける。
（キャッシュリスト４００の説明）
以下、キャッシュリスト４００について図２を用いて説明する。キャッシュリスト４００は、キャッシュ記憶部３３０にキャッシュ済みであるデータモジュールの一覧を記述するリストである。
【００２０】
図２において、Ｍｏｄｕｌｅ＿ｉｄはデータモジュールを識別するＩＤであり、Ｍｏｄｕｌｅ＿Ｖｅｒｓｉｏｎは当該データモジュールのバージョンを識別する番号である。Ｍｏｄｕｌｅ＿Ｓｉｚｅは当該データモジュールのサイズを示す。受信日時は当該データモジュールを受信およびキャッシュした日時を示す。参照回数は、当該データモジュールがデータ解釈表示部３５０から読み出し要求を受けた回数を示す。
【００２１】
図２の例では、Ｍｏｄｕｌｅ＿ｉｄ＝００００であるデータモジュールは、バージョンが１であり、サイズが１０００ＫＢであり、受信およびキャッシュした日時が２００１年１２月７日６：００：００、読み出し要求を受けた回数が１００回であることを示す。同様にＭｏｄｕｌｅ＿ｉｄ＝０００１であるデータモジュールは、バージョンが１であり、サイズが１００ＫＢであり、受信日時が２００１年１２月７日７：３３：２２、読み出し要求を受けた回数が５０回であることを示す。
【００２２】
（受信したデータをキャッシュする時のデータキャッシュ部３２０の処理フロー）
以下、データキャッシュ部３２０の処理フローを図面を用いて詳細に説明する。
図３は、受信装置１００がデータを受信し、そのデータをキャッシュする時のデータキャッシュ部３２０の処理フローを示す図である。
まず、データキャッシュ部３２０は、データ受信部３１０が受信したデータモジュールを受け取る（Ｓ１０００）。
【００２３】
データキャッシュ部３２０は、当該データモジュールのＭｏｄｕｌｅ＿ｉｄでキャッシュリスト４００を検索する（Ｓ１００１）。データキャッシュ部３２０は当該データモジュールがキャッシュ済みかどうかを調べる（Ｓ１００２）。
データキャッシュ部３２０は、当該データモジュールがキャッシュ済みでない場合、データキャッシュ部３２０は、受け取ったデータモジュールのサイズを調べ、そのサイズとキャッシュサイズ値の合計（以下、キャッシュサイズ合計値と呼ぶ）を算出する（Ｓ１００３）。データキャッシュ部３２０は、キャッシュサイズ合計値とキャッシュ上限値を比較する（Ｓ１００４）。データキャッシュ部３２０は、キャッシュサイズ合計値がキャッシュ上限値以下である場合、当該データモジュールをキャッシュ記憶部３３０に蓄積し、当該デーモジュールのＭｏｄｕｌｅ＿ｉｄ、Ｍｏｄｕｌｅ＿Ｖｅｒｓｉｏｎ、Ｍｏｄｕｌｅ＿Ｓｉｚｅ、受信日時、参照回数を調べ、キャッシュリスト４００に追加し（Ｓ１００５）、キャッシュサイズ合計値をキャッシュサイズ値に更新する（Ｓ１００６）。
【００２４】
データキャッシュ部３２０は、Ｓ１００２において、当該データモジュールがキャッシュ済みの場合、当該データモジュールとキャッシュリスト４００記載のデータモジュールのＭｏｄｕｌｅ＿Ｖｅｒｓｉｏｎを比較する（Ｓ１００７）。Ｍｏｄｕｌｅ＿Ｖｅｒｓｉｏｎが異なる場合、キャッシュリスト４００記載の同一のデータモジュールに関する情報を削除し、当該モジュールをキャッシュ記憶部３３０から削除する（Ｓ１００８）。データキャッシュ部３３０はキャッシュサイズ値から当該モジュールのサイズを減算し（Ｓ１００９）、Ｓ１００３に行く。Ｓ１００７において、Ｍｏｄｕｌｅ＿Ｖｅｒｓｉｏｎが同一である場合は、受け取ったデータモジュールを破棄する（Ｓ１０１０）。
【００２５】
Ｓ１００４において、キャッシュサイズ合計値がキャッシュ上限値を超える場合、データキャッシュ３２０部は、キャッシュリスト４００において参照回数が最も少ないデータモジュールを検索し（Ｓ１０１１）、そのデータモジュールをキャッシュ記憶部３３０から削除し、当該データモジュールに関する情報をキャッシュリスト４００から削除し（Ｓ１０１２）、キャッシュサイズ値からそのデータモジュールのサイズを差し引く（Ｓ１０１３）。そして、キャッシュサイズ合計値がキャッシュ上限値を下回り、受信したデータモジュールをキャッシュ可能な状態になるまで、Ｓ１００３からＳ１０１３を繰り返す。
【００２６】
（アプリ通信部３４０がアプリケーション１４０から通知を受けた場合のデータキャッシュ部３２０の処理フロー）
以下、アプリ通信部３４０がアプリケーション１４０から通知を受けた場合の、データキャッシュ部３２０の処理フローを図面を用いて詳細に説明する。
図４は、アプリ通信部３４０がアプリケーション１４０から通知を受けてから、その内容にしたがってデータキャッシュ部３２０がキャッシュ記憶部３３０のキャッシュデータを制御する処理フローを示す。
【００２７】
まず、アプリケーション１４０が、自アプリケーションの起動、終了または状態変化などによって、使用するメモリサイズに変化が生じた場合に、アプリ通信部３４０に、使用するメモリサイズの変化量を通知する（Ｓ１５００）。
アプリ通信部３４０は、受け取ったメモリサイズ変化量をデータキャッシュ部３２０に通知する（Ｓ１５０１）。
【００２８】
データキャッシュ部３２０は受け取ったメモリサイズ変化量をキャッシュ上限値から減算する（Ｓ１５０２）。例えば、キャッシュ上限値が８メガバイトであり、メモリサイズ変化量が１メガバイト、すなわちアプリケーション１４０が１メガバイト必要とする場合、キャッシュ上限値は８−１＝７メガバイトとなる。同様にメモリサイズ変化量がマイナス１メガバイトの場合、キャッシュ上限値は８−（−１）＝９メガバイトとなる。
【００２９】
データキャッシュ部３２０はＳ１５０２にて算出したキャッシュ上限値と、キャッシュサイズ値を比較する（Ｓ１５０３）。
データキャッシュ部３２０は、キャッシュサイズ値がキャッシュ上限値以下である場合、は何もしない。
データキャッシュ部３２０は、Ｓ１５０３において、キャッシュサイズ値がキャッシュ上限値を超える場合、データキャッシュ３２０部は、キャッシュリスト４００において参照回数が最も少ないデータモジュールを検索し（Ｓ１５０４）、そのデータモジュールをキャッシュ記憶部３３０から削除し、キャッシュリスト４００から当該モジュールの情報を削除する（Ｓ１５０５）。データキャッシュ部３２０は、キャッシュサイズ値からそのデータモジュールのサイズを差し引く（Ｓ１５０６）。そして、キャッシュサイズ値がキャッシュ上限値を下回り、受信したデータモジュールをキャッシュ可能な状態になるまで、Ｓ１５０３からＳ１５０６を繰り返す。
【００３０】
以上、このようにして、他のアプリケーションが起動していない間には最大限メモリをキャッシュとして利用可能であり、より多くのデータをキャッシュ可能であるためキャッシュヒット率が向上し、データの表示切替時間を短縮することができる。また、キャッシュするときに圧縮処理が不要であるため、データ再生のための圧縮・展開処理が不要であり、パフォーマンスやデータの表示切替時間の短縮を妨げない。
【００３１】
また、他のアプリケーションが起動する際に、そのアプリケーションが必要とする分のメモリを開放することにより、受信装置全体でのメモリ不足を防ぐことが可能となる。さらに、メモリを開放する際に、参照回数が少ないデータを削除することにより、参照回数が多い、ユーザにとって優先度の高いデータはキャッシュに保持されるため、キャッシュ容量の減少によるキャッシュの効果低下を最小限に抑えることが可能となる。
【００３２】
なお、本実施例におけるネットワークとは、通信だけでなく放送も含む。
なお、本実施例では、ＭＰＥＧ２−ＴＳを受信するが、ＭＰＥＧ２−ＴＳに制限するものではなく、サーバーに対してデータ要求リクエストを出し、そのリクエストに対してサーバーから送信されるデータを受信してもよい。この場合、データキャッシュ部はサーバーにリクエストを出してから、データを受信しキャッシュするまでの時間を計測し、その時間をデータモジュールとともに保存してもよい。さらに、当該データ再生部が保持するキャッシュ済みデータのサイズがキャッシュ上限値を超える場合にデータキャッシュ部が、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間が短いデータを優先して削除してもよい。データキャッシュ部は、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時の差分と、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよいし、当該周期の半分とサーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよい。
【００３３】
なお、本実施例では、データキャッシュ部がキャッシュ記憶部から削除するデータを決定する条件として参照回数を用いているが、受信日時が最も古いものを削除するようにしてもよいし、データサイズが最も大きいものを削除するようにしてもよい。
データキャッシュ部は、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して、キャッシュ記憶部に記憶してもよい。このとき、データキャッシュ部はキャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時から最も早く受信することになるデータモジュールを優先的に削除してもよいし、当該周期が最も短いデータモジュールを優先的に削除するようにしてもよい。
【００３４】
なお、本実施例では、受信装置に対して１つのデータ再生部が存在するように記載されているが、複数のデータ再生部が存在してもよい。複数のデータ再生部に対してキャッシュ記憶部を１つに共通化し、当該キャッシュ記憶部には複数のデータ再生部がキャッシュするデータを記憶させ、各データ再生部のデータキャッシュ部がそれぞれキャッシュサイズ上限値およびキャッシュリストを保持してもよい。
【００３５】
このとき、アプリケーションだけでなくデータ再生部から他のデータ再生部のアプリ通信部に対してメモリサイズ変化量を通知し、このメモリサイズ変化量にしたがって、通知を受けたデータ再生部のキャッシュサイズ上限値を変化させてもよい。各データ再生部がキャッシュしているデータ量がキャッシュサイズ上限値を超えた場合に各データキャッシュ部が削除するデータは、参照回数が最も少ないものでもよいし、受信日時が最も古いものでもよいし、データサイズが最も大きいものでもよいし、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時から最も早く受信することになるデータモジュールを優先的に削除してもよいし、当該周期が最も短いデータモジュールを優先的に削除するようにしてもよい。
【００３６】
また、複数のデータ再生部のうち、同時には１つのデータ再生部のみが有効状態となり、その再生内容だけが画面上に表示され、ユーザ入力部からの入力を受け付けるようにしてもよい。
この場合、各データ再生部がキャッシュしているデータ量がキャッシュサイズ上限値を超えた場合に、有効状態でないデータ再生部のキャッシュ済みデータを優先的に削除してもよいし、各データ再生部が最後にキャッシュ記憶部にアクセスした時刻を保持しておき、その時刻が最も古いデータ再生部によって保存されているキャッシュ済みデータを優先的に削除してもよい。さらに、サーバーに対してデータ要求リクエストを出し、そのリクエストに対してサーバーから送信されるデータを受信してもよい。この場合、データキャッシュ部はサーバーにリクエストを出してから、データを受信しキャッシュするまでの時間を計測し、その時間をデータモジュールとともに保存してもよい。
【００３７】
さらに、当該データ再生部が保持するキャッシュ済みデータのサイズがキャッシュ上限値を超える場合にデータキャッシュ部が、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間が短いデータを優先して削除してもよい。データキャッシュ部は、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時の差分と、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよいし、当該周期の半分とサーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよい。
【００３８】
なお、受信装置に対して複数のデータ再生部が存在し、データキャッシュ部とキャッシュ記憶部を１つに共通化し、当該キャッシュ記憶部には複数のデータ再生部がキャッシュするデータを記憶し、データキャッシュ部が複数のデータ再生部全体のキャッシュサイズ上限値およびキャッシュリストを保持してもよい。
このとき、アプリケーションからメモリサイズ変化量を通知し、このメモリサイズ変化量にしたがって、データキャッシュ部がキャッシュサイズ上限値を変化させてもよい。この場合、各データ再生部がキャッシュしているデータ量の合計がキャッシュサイズ上限値を超えた場合に、データキャッシュ部が削除するデータは、参照回数が最も少ないものでもよいし、受信日時が最も古いものでもよいし、データサイズが最も大きいものでもよいし、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時から最も早く受信することになるデータモジュールを優先的に削除してもよいし、当該周期が最も短いデータモジュールを優先的に削除するようにしてもよい。
【００３９】
また、複数のデータ再生部のうち、同時には１つのデータ再生部のみが有効状態となり、その再生内容だけが画面上に表示され、ユーザ入力部からの入力を受け付けるようにしてもよい。この場合、各データ再生部がキャッシュしているデータ量の合計がキャッシュサイズ上限値を超えた場合に、データキャッシュ部は、有効状態でないデータ再生部のキャッシュ済みデータを優先的に削除してもよいし、各データ再生部が最後にキャッシュ記憶部にアクセスした時刻を保持しておき、その時刻が最も古いデータ再生部によって保存されているキャッシュ済みデータを優先的に削除してもよい。さらに、サーバーに対してデータ要求リクエストを出し、そのリクエストに対してサーバーから送信されるデータを受信してもよい。
【００４０】
この場合、データキャッシュ部はサーバーにリクエストを出してから、データを受信しキャッシュするまでの時間を計測し、その時間をデータモジュールとともに保存してもよい。さらに、当該データ再生部が保持するキャッシュ済みデータのサイズがキャッシュ上限値を超える場合にデータキャッシュ部が、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間が短いデータを優先して削除してもよい。データキャッシュ部は、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時の差分と、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよいし、当該周期の半分とサーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよい。
【００４１】
（実施の形態２）
図５は、本発明に係る受信装置の第２の実施の形態を示す構成図である。
図５において、受信装置２０００は、データ再生部２３００、ＴＳ受信部２０１０、ＴＳ分離部２０２０、映像音声デコード部２０３０、ＥＰＧや静止画表示アプリケーションおよびメニューアプリケーションなどのアプリケーション２０４０、ユーザ入力受信部２０５０、および出力部２０６０から構成される。
【００４２】
このうち、ＴＳ受信部２０１０、ＴＳ分離部２０２０、映像音声デコード部２０３０、ユーザ入力部２０５０および出力部２０６０については第１の実施の形態と同様のため、説明を省略する。
アプリケーション２０４０は、ユーザからのリモコン操作などによって起動または終了され、番組表や、静止画、受信装置２０００の設定を行う画面を表示するための画像を生成し、出力部２０６０に出力する。例えば、番組表を表示するＥＰＧ（Ｅｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ）や受信装置に装着したメモリカードに記録されている静止画を表示する静止画ビューワ、や受信機設定を行うメニューアプリなどがある。
【００４３】
アプリケーション２０４０は、起動時、終了時に、データ再生部２３００のアプリ通信部２３４０に対して、自アプリケーションを識別するＩＤ（以下、アプリケーションＩＤ）と、自アプリケーションの起動状態（起動か終了か）を通知する。
（データ再生部２３００の詳細な説明）
データ再生部２３００は、データ受信部２３１０、データキャッシュ部２３２０、キャッシュ記憶部２３３０、アプリ通信部２３４０およびデータ解釈表示部２３５０から構成される。
【００４４】
データ受信部２３１０はデータモジュールだけでなく、メモリ使用量リスト２５００も受信し、データキャッシュ部２３２０に送る。
キャッシュ記憶部２３３０およびデータ解釈表示部２３５０については第１の実施の形態と同様のため説明を省略する。
データキャッシュ部２３２０は、送られたデータモジュールがキャッシュ記憶部２３３０に存在するかを確認し、存在していなければキャッシュ記憶部２３３０に蓄積する。データキャッシュ部２３２０は、キャッシュリスト２４００と、図示しないキャッシュ上限値と、図示しないキャッシュサイズ値と、メモリ使用量リスト２５００を保持する。
【００４５】
データキャッシュ部２３２０は、送られたデータモジュールのサイズとキャッシュサイズ値の合計がキャッシュ上限値を超える場合には、キャッシュリスト２４００を元に不要なキャッシュ済みのデータを削除または、送られたデータモジュールを削除するとともにキャッシュリスト２４００を更新する。データキャッシュ部２３２０は、アプリ通信部ＡＰＣから受け取ったアプリケーションＩＤとそのアプリの起動状態を元に、メモリ使用量リスト２５００を検索し、メモリ使用量リスト２５００に記載のメモリ量に従ってキャッシュサイズ上限値を変化させ、キャッシュサイズ値がキャッシュ上限値を超える場合には、キャッシュリスト２４００を元に不要なキャッシュ済みのデータを削除するとともにキャッシュリスト２４００を更新する。
【００４６】
データキャッシュ部２３２０は、データ解釈表示部３５０からのデータモジュールの取得要求にしたがってキャッシュ記憶部２３３０からデータを読み出し、データ解釈表示部２３５０に出力する。このとき、データキャッシュ部２３２０は、取得要求を受けたデータモジュールに対して、キャッシュリスト２４００の当該モジュールの参照回数の値をインクリメントする。
【００４７】
データキャッシュ部２３２０は、データ受信部２３１０が受信したメモリ使用量リスト２５００を受け取り、すでに保持しているメモリ使用量リストと置き換える。
キャッシュリスト２４００については第１の実施の形態と同様のため説明を省略する。
アプリ通信部２３４０は、アプリケーション２０４０（ＥＰＧ、静止画表示アプリ、メニューアプリなど）との通信を行い、アプリケーション２０４０からそのアプリケーションを識別するＩＤと、そのアプリの状態（起動か終了か）の通知を受ける。
【００４８】
（メモリ使用量リスト２５００の説明）
図はメモリ使用量リスト２５００の一例を示す図である。メモリ使用量リスト２５００は、各アプリケーションが動作するのに必要なメモリ量のリストである。例えば、図において、アプリケーションＩＤが１であるアプリケーションが動作するために必要なメモリ量は１ＭＢであることを示す。他のアプリケーションＩＤのアプリケーションについても同様である。同様にアプリケーションＩＤが２であるアプリケーションについてはメモリ使用量が０．５ＭＢであることを示す。
【００４９】
受信したデータをキャッシュする時のデータキャッシュ部２３２０の処理フローは第１の実施の形態と同様であるため、説明を省略する。
（アプリ通信部２３４０がアプリケーション２０４０から通知を受けた場合のデータキャッシュ部２３２０の処理フロー）
以下、本実施の形態において、アプリ通信部２３４０がアプリケーション２０４０から通知を受けた場合の、データキャッシュ部２３２０の処理フローを、図面を用いて詳細に説明する。
【００５０】
図７は、アプリ通信部２３４０がアプリケーション２０４０から通知を受けてから、その内容にしたがってデータキャッシュ部２３２０がキャッシュ記憶部２３３０のキャッシュデータを制御する処理フローを示す。
まず、アプリケーション２０４０が、起動または終了する場合に、アプリ通信部２３４０に対して、自分のアプリケーションＩＤと起動状態（起動するのか終了するのか）を通知する（Ｓ３０００）。
【００５１】
アプリ通信部２３４０は、受け取ったアプリケーションＩＤと起動状態をデータキャッシュ部２３２０に通知する（Ｓ３００１）。
データキャッシュ部２３２０は、メモリ使用量リスト２５００から当該アプリケーションＩＤのアプリケーションのメモリ使用量を検索する（Ｓ３００２）。
データキャッシュ部２３２０は、アプリ通信部２３４０から受け取った起動状態が、起動か終了か判断する（Ｓ３００３）。
【００５２】
データキャッシュ部２３２０は、アプリ通信部２３４０から受け取った起動状態が、終了であった場合、Ｓ３００２で検索したメモリ使用量をキャッシュサイズ上限値に加算する（Ｓ３００４）。
以下、アプリ通信部２３４０から受け取った起動状態が、起動であった場合のデータキャッシュ部２３２０の処理を説明する。
【００５３】
データキャッシュ部２３２０は、Ｓ３００２で検索したメモリ使用量をキャッシュ上限値から減算し、新たなキャッシュ上限値を算出する（Ｓ３００５）。
データキャッシュ部２３２０はＳ３００５にて算出したキャッシュ上限値と、キャッシュサイズ値を比較する（Ｓ３００６）。
データキャッシュ部２３２０は、キャッシュサイズ値がキャッシュ上限値以下である場合、は何もしない。
【００５４】
データキャッシュ部２３２０は、Ｓ３００６において、キャッシュサイズ値がキャッシュ上限値を超える場合、データキャッシュ２３２０部は、キャッシュリスト４００において参照回数が最も少ないデータモジュールを検索し（Ｓ３００７）、そのデータモジュールをキャッシュ記憶部２３３０から削除し、キャッシュリスト２４００から当該モジュール情報を削除し（Ｓ３００８）、キャッシュサイズ値からそのデータモジュールのサイズを差し引く（Ｓ３００９）。そして、キャッシュサイズ値がキャッシュ上限値を下回り、受信したデータモジュールをキャッシュ可能な状態になるまで、Ｓ３００６からＳ３００９を繰り返す。
【００５５】
以上、このようにして、他のアプリケーションが起動していない間には最大限メモリをキャッシュとして利用可能であり、より多くのデータをキャッシュ可能であるためキャッシュヒット率が向上し、データの表示切替時間を短縮することができる。また、キャッシュするときに圧縮処理が不要であるため、データ再生のための圧縮・展開処理が不要であり、パフォーマンスやデータの表示切替時間の短縮を妨げない。
【００５６】
また、他のアプリケーションが起動する際に、そのアプリケーションが必要とする分のメモリを開放することにより、受信装置全体でのメモリ不足を防ぐことが可能となる。さらに、メモリを開放する際に、参照回数が少ないデータを削除することにより、参照回数が多い、ユーザにとって優先度の高いデータはキャッシュに保持されるため、キャッシュ容量の減少によるキャッシュの効果低下を最小限に抑えることが可能となる。
【００５７】
なお、データ受信部２３１０はメモリ使用量リストを受信し、データキャッシュ部がメモリ使用量リストを置き換えてもよい。
なお、本実施例におけるネットワークとは、通信だけでなく放送も含む。
なお、本実施例では、ＭＰＥＧ２−ＴＳを受信するが、ＭＰＥＧ２−ＴＳに制限するものではなく、サーバーに対してデータ要求リクエストを出し、そのリクエストに対してサーバーから送信されるデータを受信してもよい。
【００５８】
この場合、データキャッシュ部はサーバーにリクエストを出してから、データを受信しキャッシュするまでの時間を計測し、その時間をデータモジュールとともに保存してもよい。さらに、当該データ再生部が保持するキャッシュ済みデータのサイズがキャッシュ上限値を超える場合にデータキャッシュ部が、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間が短いデータを優先して削除してもよい。データキャッシュ部は、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時の差分と、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよいし、当該周期の半分とサーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよい。
【００５９】
なお、本実施例では、データキャッシュ部がキャッシュ記憶部から削除するデータを決定する条件として参照回数を用いているが、受信日時が最も古いものを削除するようにしてもよいし、データサイズが最も大きいものを削除するようにしてもよい。
データキャッシュ部は、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して、キャッシュ記憶部に記憶してもよい。このとき、データキャッシュ部はキャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時から最も早く受信することになるデータモジュールを優先的に削除してもよいし、当該周期が最も短いデータモジュールを優先的に削除するようにしてもよい。
【００６０】
なお、本実施例では、受信装置に対して１つのデータ再生部が存在するように記載されているが、複数のデータ再生部が存在してもよい。複数のデータ再生部に対してキャッシュ記憶部を１つに共通化し、当該キャッシュ記憶部には複数のデータ再生部がキャッシュするデータを記憶させ、各データ再生部のデータキャッシュ部がそれぞれキャッシュサイズ上限値とキャッシュリストおよびメモリ使用量リストを保持してもよい。
【００６１】
このとき、アプリケーションだけでなくデータ再生部から他のデータ再生部のアプリ通信部に対してデータ再生部を含めたアプリケーションを識別するＩＤと起動状態を通知し、このＩＤと起動状態にしたがってメモリ使用量リストを検索して当該アプリケーションまたはデータ再生部のメモリ使用量を調べ、この値を元に、通知を受けたデータ再生部のキャッシュサイズ上限値を変化させてもよい。各データ再生部がキャッシュしているデータ量がキャッシュサイズ上限値を超えた場合に各データキャッシュ部が削除するデータは、参照回数が最も少ないものでもよいし、受信日時が最も古いものでもよいし、データサイズが最も大きいものでもよいし、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時から最も早く受信することになるデータモジュールを優先的に削除してもよいし、当該周期が最も短いデータモジュールを優先的に削除するようにしてもよい。また、複数のデータ再生部のうち、同時には１つのデータ再生部のみが有効状態となり、その再生内容だけが画面上に表示され、ユーザ入力部からの入力を受け付けるようにしてもよい。この場合、各データ再生部がキャッシュしているデータ量がキャッシュサイズ上限値を超えた場合に、有効状態でないデータ再生部のキャッシュ済みデータを優先的に削除してもよいし、各データ再生部が最後にキャッシュ記憶部にアクセスした時刻を保持しておき、その時刻が最も古いデータ再生部によって保存されているキャッシュ済みデータを優先的に削除してもよい。
【００６２】
さらに、サーバーに対してデータ要求リクエストを出し、そのリクエストに対してサーバーから送信されるデータを受信してもよい。この場合、データキャッシュ部はサーバーにリクエストを出してから、データを受信しキャッシュするまでの時間を計測し、その時間をデータモジュールとともに保存してもよい。さらに、当該データ再生部が保持するキャッシュ済みデータのサイズがキャッシュ上限値を超える場合にデータキャッシュ部が、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間が短いデータを優先して削除してもよい。データキャッシュ部は、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時の差分と、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよいし、当該周期の半分とサーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよい。
【００６３】
なお、受信装置に対して複数のデータ再生部が存在し、データキャッシュ部とキャッシュ記憶部を１つに共通化し、当該キャッシュ記憶部には複数のデータ再生部がキャッシュするデータを記憶し、データキャッシュ部が複数のデータ再生部全体のキャッシュサイズ上限値とキャッシュリストおよびメモリ使用量リストを保持してもよい。
このとき、アプリケーションからデータ再生部のアプリ通信部に対してアプリケーションを識別するＩＤと起動状態を通知し、このＩＤと起動状態にしたがってメモリ使用量リストを検索して当該アプリケーションのメモリ使用量を調べ、この値を元に、データキャッシュ部がキャッシュサイズ上限値を変化させてもよい。この場合、各データ再生部がキャッシュしているデータ量の合計がキャッシュサイズ上限値を超えた場合に、データキャッシュ部が削除するデータは、参照回数が最も少ないものでもよいし、受信日時が最も古いものでもよいし、データサイズが最も大きいものでもよいし、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時から最も早く受信することになるデータモジュールを優先的に削除してもよいし、当該周期が最も短いデータモジュールを優先的に削除するようにしてもよい。
【００６４】
また、複数のデータ再生部のうち、同時には１つのデータ再生部のみが有効状態となり、その再生内容だけが画面上に表示され、ユーザ入力部からの入力を受け付けるようにしてもよい。この場合、各データ再生部がキャッシュしているデータ量の合計がキャッシュサイズ上限値を超えた場合に、データキャッシュ部は、有効状態でないデータ再生部のキャッシュ済みデータを優先的に削除してもよいし、各データ再生部が最後にキャッシュ記憶部にアクセスした時刻を保持しておき、その時刻が最も古いデータ再生部によって保存されているキャッシュ済みデータを優先的に削除してもよい。
【００６５】
さらに、サーバーに対してデータ要求リクエストを出し、そのリクエストに対してサーバーから送信されるデータを受信してもよい。この場合、データキャッシュ部はサーバーにリクエストを出してから、データを受信しキャッシュするまでの時間を計測し、その時間をデータモジュールとともに保存してもよい。
さらに、当該データ再生部が保持するキャッシュ済みデータのサイズがキャッシュ上限値を超える場合にデータキャッシュ部が、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間が短いデータを優先して削除してもよい。データキャッシュ部は、同一のデータモジュールを受信した時刻から当該データモジュールが繰り返し送信される周期を計算して記憶しておき、キャッシュ記憶部から削除するデータを決定する条件として、受信日時に周期を加算した日時と現在日時の差分と、サーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよいし、当該周期の半分とサーバーにリクエストを出してからデータを受信しキャッシュするまでの時間とで短い方のデータを優先的に削除してもよい。
【００６６】
なお、上記各実施の形態の構成図を図１、図５に示したが、各構成要素の機能をコンピュータに発揮させるプログラムで記載するようにしてもよい。さらに、このプログラムをコンピュータ読み取り可能な記録媒体に記録し、ファイル読み出し装置にこの記録媒体を適用するようにしてもよい。
【産業上の利用可能性】
【００６７】
本発明にかかる受信装置は、アプリケーションのメモリ使用状況に従って、データキャッシュ部におけるキャッシュ上限値を動的に制御する機能を有し、ネットワークからデータを受信し、再生する機能を有する受信装置全般に適用可能である。
【図面の簡単な説明】
【００６８】
【図１】本発明の実施の形態１における受信装置の構成図
【図２】キャッシュリストの例示図
【図３】データ受信時におけるデータキャッシュ部の処理フロー
【図４】アプリケーションから通知を受けた時のデータキャッシュ部の処理フロー
【図５】本発明の実施の形態２における受信装置の構成図
【図６】メモリ使用量リストの例示図
【図７】アプリケーションから通知を受けた時のデータキャッシュ部の処理フロー
【符号の説明】
【００６９】
１００    受信装置
１１０    ＴＳ受信部
１２０    ＴＳ分離部
１３０    映像音声デコード部
１４０    アプリケーション
１５０    ユーザ入力部
３００    データ受信装置
３１０    データ受信部
３２０    データキャッシュ部
３３０    キャッシュ記憶部
３４０    アプリ通信部
３５０    データ解釈表示部
４００    キャッシュリスト
２０００  受信装置
２０１０  ＴＳ受信部
２０２０  ＴＳ分離部
２０３０  映像音声デコード部
２０４０  アプリケーション
２０５０  ユーザ入力部
２３００  データ受信装置
２３１０  データ受信部
２３２０  データキャッシュ部
２３３０  キャッシュ記憶部
２３４０  アプリ通信部
２３５０  データ解釈表示部
２４００  キャッシュリスト
２５００  メモリ使用量リスト
【図１】
2005123942.tif 000003
【図２】
2005123942.tif 000004
【図３】
2005123942.tif 000005
【図４】
2005123942.tif 000006
【図５】
2005123942.tif 000007
【図６】
2005123942.tif 000008
【図７】
2005123942.tif 000009