(57)【要約】【課題】従来、蓄積型のデータ受信装置においては、記録可能スペースが過去のユーザの使用状態によって必ずしも一定量確保できるとは限らず、サービス提供者側からは、宣伝用のデモ情報を送信しても必要なスペースを確保できず、宣伝効果を必ずしも保証することができないという問題があった。【解決手段】サービスにかかるデータ及びこのデータの再生条件にかかるデータを受信してＨＤＤ５に記録し、このＨＤＤ５で記録されたデータのうち前記再生条件にかかるデータに対して書き込みまたは消去が可能であることをデータ監視／タイマー８にて判断し、書き込みまたは消去可能と判断された場合のみ、ＨＤＤ５から前記サービスにかかるデータの再生を行なうようにした。【選択図】　図１
2004088543.tif 000002
【特許請求の範囲】
【請求項１】
サービスにかかるデータを受信して記録媒体に記録する手段と、この記録媒体に記録された前記データの少なくとも一部に対し書き込みまたは消去が可能であるか否かを検出する手段と、この検出手段で書き込みまたは消去可能と検出された場合に、前記データの再生を行なう再生手段とを具備したことを特徴とするデータ受信装置。
【請求項２】
請求項１記載のデータ受信装置において、前記サービスにかかるデータは、このサービスの再生条件にかかる情報を含むことを特徴とするデータ受信装置。
【請求項３】
サービスの再生条件にかかる情報を含むサービスにかかるデータを受信して記録媒体に記録する手段と、この記録媒体に記録された前記データから前記再生条件にかかる情報を取得し、取得した情報から前記再生条件の有効性を検出する手段と、この検出手段の検出結果に基づき前記記録媒体に記録された前記データを消去もしくは破壊する手段とを具備したことを特徴とするデータ受信装置。
【請求項４】
サービスの再生条件にかかる情報を含むサービスにかかるデータを受信して記録媒体に記録する手段と、この記録媒体に記録された前記データから前記再生条件にかかる情報を取得し、取得した情報から前記再生条件の有効性を検出する手段と、この検出手段の検出結果に基づき前記記録媒体に記録された前記データの少なくとも一部を変更して再生不可能とする手段とを具備したことを特徴とするデータ受信装置。
【請求項５】
請求項２乃至４記載のデータ受信装置において、前記データはサービスの認識情報を有しており、前記記録媒体に記録された前記データから前記認識情報および前記再生条件にかかる情報を取得し、これを表示する手段を具備したことを特徴とするデータ受信装置。
【請求項６】
請求項５記載のデータ受信装置において、前記表示手段での表示が前記サービスにかかるデータの再生前になされるよう構成したことを特徴とするデータ受信装置。
【請求項７】
請求項１乃至４記載のデータ受信装置において、前記記録手段は、前記サービスにかかるデータを暗号化し、その解読情報と共に前記記録媒体に記録するよう構成したことを特徴とするデータ受信装置。
【請求項８】
サービスにかかるデータを受信して記録媒体に記録する工程と、この記録工程で記録媒体に記録された前記データの少なくとも一部に対し書き込みまたは消去が可能であるか否かを検出する工程と、この検出工程で書き込みまたは消去可能と検出された場合に、前記データの再生を行なう工程とを具備したことを特徴とするデータ受信方法。
【請求項９】
サービスの再生条件にかかる情報を含むサービスにかかるデータを受信して記録媒体に記録する工程と、この記録工程で記録媒体に記録された前記データから前記再生条件にかかる情報を取得し、取得した情報から前記再生条件の有効性を検出する工程と、この検出工程での検出結果に基づき前記記録媒体に記録された前記データを消去もしくは破壊する工程とを具備したことを特徴とするデータ受信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、放送波やネットワーク、あるいは記録媒体等を介して各種のサービスにかかるデータ（以下、サービスデータともいう）を受信記録し、記録された前記サービスデータを再生することで各種サービスを享受することの出来るデータ受信装置及びデータ受信方法に関する。
【０００２】
【従来の技術】パーソナルコンピュータや放送技術の進歩に伴い、近年、放送を含む多くのサービスがデジタル化されてきている。このデジタル技術の大きな構成要素のひとつに記憶装置がある。たとえば半導体メモリやハードディスクドライブ（以下、ＨＤＤという）がそれである。もともとはコンピュータの演算あるいはプログラムの格納用に広く利用されていたが、近年になってその記録容量の飛躍的増大とアクセス速度の高速化に伴い、音声や映像向けの記憶装置として利用され始めている。たとえば、ＨＤＤを利用した蓄積型のサービス受信機が検討されている。これは、サービス提供者がニュースや天気予報などの情報を番組電波の中で裏情報として送信し、受信機がこれを受け取る。ユーザから上記のニュースや天気予報にかかる情報の表示要求が出されると、画面に表示するというものである。
【０００３】
ニュースや天気予報は刻々と画面を切り替える必要もなく、受信機側で適宜記録して蓄積させるほうが電波の利用効率としては望ましい。また、ユーザがある番組の視聴を録画したい場合にもＨＤＤ上に番組を記録することが可能になってきている。なお、上記サービスにかかるデータは通常、期限を過ぎても記録装置上に存在し、このことが記録装置の記録可能スペースを圧迫させる結果となっている。
【０００４】
以上のように従来検討されている蓄積型のデータ受信装置では、記録可能スペースが過去のユーザの使用状態によって必ずしも一定量確保できるとは限らない。このことはサービス提供者側から見れば、たとえば宣伝用のデモ情報を送信しても必要な記録可能スペースを確保できず、宣伝効果を必ずしも保証することができないという問題があった。
【０００５】
なお、特開２００１−３０９３３２号公報には、送信側で前記サービスの暗号化を行なうと共に、この暗号化された前記サービスと共に権利情報を送信し、受信側では送信された両者の蓄積を行い、上記権利情報と暗号化された前記サービスを合わせることで初めて視聴が可能となるシステムが開示されている。
【０００６】
【発明が解決しようとする課題】上述したように、従来、蓄積型のデータ受信装置においては、記録可能スペースが過去のユーザの使用状態によって必ずしも一定量確保できるとは限らず、サービス提供者側からは、宣伝用のデモ情報を送信しても必要な上記スペースを確保できず、宣伝効果を必ずしも保証することができないという問題があった。
【０００７】
本発明はこのような問題点を解決するためになされたもので、記録媒体の記録可能領域の確保を容易に行なうことの出来るデータ受信装置及びデータ受信方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
請求項１にかかるデータ受信装置は、サービスにかかるデータを受信して記録媒体に記録する手段と、この記録媒体に記録された前記データの少なくとも一部に対し書き込みまたは消去が可能であるか否かを検出する手段と、この検出手段で書き込みまたは消去可能と検出された場合に、前記データの再生を行なう再生手段とを具備したことを特徴とするものである。
【０００９】
請求項２にかかるデータ受信装置は、請求項１記載のデータ受信装置において、前記サービスにかかるデータは、このサービスの再生条件にかかる情報を含むことを特徴とするものである。
【００１０】
請求項３にかかるデータ受信装置は、サービスの再生条件にかかる情報を含むサービスにかかるデータを受信して記録媒体に記録する手段と、この記録媒体に記録された前記データから前記再生条件にかかる情報を取得し、取得した情報から前記再生条件の有効性を検出する手段と、この検出手段の検出結果に基づき前記記録媒体に記録された前記データを消去もしくは破壊する手段とを具備したことを特徴とするものである。
【００１１】
請求項４にかかるデータ受信装置は、サービスの再生条件にかかる情報を含むサービスにかかるデータを受信して記録媒体に記録する手段と、この記録媒体に記録された前記データから前記再生条件にかかる情報を取得し、取得した情報から前記再生条件の有効性を検出する手段と、この検出手段の検出結果に基づき前記記録媒体に記録された前記データの少なくとも一部を変更して再生不可能とする手段とを具備したことを特徴とするものである。
【００１２】
請求項５にかかるデータ受信装置は、請求項２乃至４記載のデータ受信装置において、前記データはサービスの認識情報を有しており、前記記録媒体に記録された前記データから前記認識情報および前記再生条件にかかる情報を取得し、これを表示する手段を具備したことを特徴とするものである。
【００１３】
請求項６にかかるデータ受信装置は、請求項５記載のデータ受信装置において、前記表示手段での表示が前記サービスにかかるデータの再生前になされるよう構成したことを特徴とするものである。
【００１４】
請求項７にかかるデータ受信装置は、請求項１乃至４記載のデータ受信装置において、前記記録手段は、前記サービスにかかるデータを暗号化し、その解読情報と共に前記記録媒体に記録するよう構成したことを特徴とするものである。
【００１５】
請求項８にかかるデータ受信方法は、サービスにかかるデータを受信して記録媒体に記録する工程と、この記録工程で記録媒体に記録された前記データの少なくとも一部に対し書き込みまたは消去が可能であるか否かを検出する工程と、この検出工程で書き込みまたは消去可能と検出された場合に、前記データの再生を行なう工程とを具備したことを特徴とするものである。
【００１６】
請求項９にかかるデータ受信方法は、サービスの再生条件にかかる情報を含むサービスにかかるデータを受信して記録媒体に記録する工程と、この記録工程で記録媒体に記録された前記データから前記再生条件にかかる情報を取得し、取得した情報から前記再生条件の有効性を検出する工程と、この検出工程での検出結果に基づき前記記録媒体に記録された前記データを消去もしくは破壊する工程とを具備したことを特徴とするものである。
【００１７】
【発明の実施の形態】以下、本発明になるデータ受信装置の実施の形態につき、図面を用いて説明する。
【００１８】
図１は、本発明になるデータ受信装置の実施の形態の一例を示すブロック図である。１はデータ入力端であり、ネットワークを介したサービス提供者からのデータが入力されたり、あるいは地上波受信用のアンテナまたは衛星放送受信用のパラボラアンテナ等を介して放送局からのデータが入力される。２は受信部であり、具体的にはチューナやモデムである。
【００１９】
３は暗号化部であり、受信部２で受信したデータを暗号化する。４は暗号化部３で暗号化されたデータをＨＤＤ５に記録するためのインタフェース制御部である。６は暗号解読部であり、インタフェース制御部４を介して再生されたＨＤＤ５からのデータを解読し、デコーダ７に送信する。なお、暗号化部３と暗号解読部６の暗号方式と暗号に付随するパラメータは機器毎の固有設定になっている。これはハッキング防止のためである。
【００２０】
デコーダ７はデータに応じて復号を行なうもので、ＭＰＥＧ復号やインターネットで用いられている技術（たとえばＨＴＭＬやＢＭＬ等の技術）を応用したものが利用される。また、８はデコーダ７からの映像並びに音声出力を出力するディスプレイ／スピーカ（記載を簡単にするために纏めて示す）である。一方、９はコピー管理部であり、受信部２で受信された信号を暗号化部３を介してＨＤＤ５に記録する前に、ＨＤＤ５への蓄積が許可されているかどうかを判断し、この判断結果に基づいて記録動作の制御を行なう。さらに、１０は詳細を後述するデータ監視部／タイマーである。
【００２１】
１１はリモートコントローラ（以下、リモコンという）であり、１２はリモコン１１からのリモコン信号の受信部である。１３は受信部１２を介したリモコン１１からの制御信号または装置本体に設けられた図示せぬ操作スイッチからの制御信号に基づきデータ受信装置全体を制御するシステム制御部であり、データの記録や再生を指示したり、データ受信装置全体の電源管理等を行なう。１４は、本受信装置の各部間の信号授受に用いられる通信バスであり、システム制御部１３による各種指示あるいは管理用の命令は、このバス１４を使って指示される。このバス１４としては、最も単純なものである２線式のものを利用しても良いし、命令信号の転送速度に高速なものが必要な場合には、ＰＣＩバスを使用しても良い。
【００２２】
次に、図１の装置の記録動作について簡単に説明する。データ入力端１から入力された各種サービスにかかるデータは、受信部２で受信され、暗号化部３で暗号化された上で、ＨＤＤインタフェース制御部４を介してＨＤＤ５に記録される。ここで、受信部２で受信された信号を暗号化部３を介してＨＤＤ５に記録する前には、ＨＤＤ５への蓄積が許可されているかどうかがコピー管理部９で判断され、この判断結果に基づいて記録動作の制御が行なわれる。また、各種サービスにかかるデータは、そのサービスの再生条件にかかる情報を含んでいる（再生制限なしの場合も含む）。なお、暗号化部３での暗号化の動作等については、以下のＨＤＤ５における記録データの構造の説明に関連付けて説明する。
【００２３】
さらに、図１の装置の再生動作を説明する前に、この装置のＨＤＤ５における記録データの構造について説明する。図２は、図１に示す装置（の記録ファイル）における特徴の１つであるサービス・データ・ファイル２１の構造を示している。ファイル２１は大きく分けてサービス開始確認ヘッダープログラム（以下、ヘッダープログラムともいう）２２とサービスデータ２３から構成されている。本実施の形態では、まずサービスを提供するときのサービス再生制限事項を規定した実行許可条件フラグ（サービス再生制限データ領域）２４をサービス・データ・ファイル２１の（ヘッダープログラム２２の）一部に埋め込む。実行許可条件は、ユーザが受けるサービスの再生状態を規定するものである。具体的な例としては、サービスデータの再生回数を規定する回数制限およびサービスが再生できる有効期限を指定する再生期日制限の２つが挙げられる。以上の２つは主に映画などのビデオプログラムや音楽プログラムを対象サービスとするときに広く利用可能である。２５は実行許可条件フラグ２４の内容を示すもので、上記の例を具体的に示している。すなわち、２５１は再生回数制限を、２５２は再生期日制限を示す。
【００２４】
さらにゲームを始めとするインタラクティブなサービスの場合は、どのように参加できるのかを規定することも可能である。ここではその一例として、ゲームに同時参加可能な人数を規定する例を、同じくフラグ２４の内容を示す２５に２５３として示している。この人数制限は、例えばシステム制御部１３にて本受信装置に接続される図示せぬゲーム用のコントローラの接続数を検出して、制限された数のコントローラのみの命令を受け付けるようにすることで対応可能である。
【００２５】
以上の例では上記３つのサービス再生制限項目をひとつのサービス・データ・ファイルが全て保有しているかのように記載しているが、必ずしもこれら３つのサービス再生制限を同時にすべてのサービス・データ・ファイルが保有する必要はない。たとえば、再生回数だけを制限するために、この再生回数制限データのみを保有している場合もありうる。
【００２６】
サービスデータ２３そのものと上記実行許可条件フラグ２４には、サービス制限事項の改ざん防止とサービスデータの漏洩を防ぐ目的で暗号化を行なう。この暗号化はコピー防止目的とは異なり、あくまでも上記サービス再生にかかる実行許可条件フラグ２４とサービスデータ２３そのものが、蓄積されたサービス・データ・ファイル２１、あるいは伝送途中の伝送路から不正に閲覧され、編集作業によって取り出されてしまうことを防止するためのものである。ＨＤＤ５からサービス・データ・ファイル２１そのものが不正にコピーされることを防止するための目的ではない。後者の不正コピー防止手法は、ＨＤＤ５の入出力で暗号化乃至暗号解読を行うことで図られることを前提としている。
【００２７】
上記サービスデータ２３と再生制限のためのフラグ２４に対する暗号化手法としては特に制限はなく、いろいろなものが利用できる。例えば放送系でよく利用されているＤＥＳやＭｕｌｔｉ２と呼ばれる方式が利用できる。一般に暗号化手法には特殊な数値パターンをある演算装置で演算して暗号化する手法と、ある区間のデジタルデータの順番をランダムに入れ替える方法とがある。本サービスデータ２３と再生制限のためのフラグ２４の暗号化手法としては、データの存在場所と順序を離散化してしまう後者の手法がより効果的である。
【００２８】
暗号を解読するための解読手法、あるいは解読のために必要なパラメータ情報は、サービス・データ・ファイル２１自身が保有している。すなわち、図２の２６は暗号化されている実行許可条件フラグ２４に対する暗号解読用のコード及びパラメータであり、２７は暗号化されているサービスデータに対する暗号解読用のコード及びパラメータ、並びにデコーダ７でのデコード用のソフトウェアである。
【００２９】
サービス・データ・ファイル２１が起動されると、まず最初に動作するサービス開始確認ブロック２８にて上記暗号を解くために必要な手法やパラメータをコード２６、２７を用いて発生させる。図３にサービス開始確認ヘッダープログラム２２（正確には、サービス開始確認ブロック２８）を実行するための構成を示す。ヘッダー部分（正確には、ブロック２８）は大きく分けてユーザ・インタフェース・レイヤー（Ｌａｙｅｒ）３１、プロセス・レイヤー３２、データ・アクセス・レイヤー３３の３つのレイヤーに分けられている。ユーザ・インタフェース・レイヤー３１は、実際にユーザが目や耳でこの受信機からの情報に触れるためのインタフェースを与えるもので、たとえば、実行しようとしていたファイルが規定された制限事項を超えていた場合、その旨をユーザに通知するための情報発信源になる。より具体的には、このレイヤー３１から図示せぬグラフィック・ライブラリにアクセスして、上記情報をユーザに通知するべく画面上に表示させるというような働きをする。
【００３０】
上記で説明したヘッダープログラム２２の実行は、実際には図１におけるコピー管理部９やシステム制御部１３に内蔵される演算回路でも実行可能である。しかしながら、サービスデータの保護という観点からすれば、内部の通信バス１４に接続された上記コピー管理部９やシステム制御部１３で実施することは、図１に示した装置で採用されている暗号化方式の漏洩につながる恐れがあり、望ましくない。従って、上記ヘッダープログラム２２は外部からは閲覧困難な個別のハードウェア内で実施されることが望ましい。
【００３１】
図１の装置ではヘッダープログラム２２を実行する装置として通信バス１４には直接接続されない個別のデータ監視部／タイマー１０を持っている。データ監視部／タイマー１０は、暗号解読部６がＨＤＤ５からサービスデータを受け取ると、まず解読したデータを上記データ監視部／タイマー１０に転送させる。このデータ監視部／タイマー１０で上記ヘッダープログラム２２を実行し、サービス限定条件外のサービスを再生している場合には、上述したようにそのサービスデータの上書き、あるいは消去を暗号解読部６を通じてＨＤＤ５に命ずる。このとき、上述したようにデータ監視部／タイマー１０はユーザ・インタフェース・レイヤー３１を通してシステム制御部１３にユーザに対して通知を行うよう指示する。この例では、データ監視部／タイマー１０が通信バス１４とは直接通信せず、外部から完全に隔離されていることが重要である。
【００３２】
次に、図１の装置の具体的動作をプロセス・レイヤー３２の動作例を示す図４に基づいて説明する。この図４は、サービスデータの再生回数に対して制限が規定されている場合の例を示している。
【００３３】
ユーザからの要求によってあるサービスデータの再生要求が出されると、ヘッダープログラム２２は、自身が格納されているサービス・データ・ファイル２１が自身によって書き込み可能であることを確認する（ステップＳ１）。詳細は後述するが、ヘッダープログラム２２は再生許可回数記録が改ざんされる場合、あるいは自身のデータそのものが再生条件を外れている場合にはサービス・データ・ファイル２１を適宜消去、破壊する動作をする。この場合、自身の存在領域であるサービス・データ・ファイル２１があくまで書き込み可能であることが必要である。書き込み不可能な状態では事実上、上記再生制限機能は無意味なものになってしまうことは言うまでも無い。
【００３４】
一般にＨＤＤ上にデータを記録するためにはデータ領域のほかに、どの領域に何のデータを記録しているかを管理している管理テーブルが存在する。この書き込み許可の確認は、管理テーブルとデータ領域のうち、少なくともデータ領域については確認が必要不可欠である。書き込み確認の方法としては、単にその領域のアクセス権だけを確認することでも良いが、実際に現状あるデータを一時的に退避させて、その部分に書き込み及び読み出しをして確認をするほうが望ましい。この場合、一時退避されたデータは、書き込みの確認後に元の領域に戻される。データ領域は、そのサービス内容によっては非常に膨大な量になることが有り得る。例えばＭＰＥＧ２で高精細テレビジョン受像機（以下、ＴＶという）のデータファイルを記録させると、ほんの数分で１ＧＢ程度の容量を浪費してしまう。ＨＤＤやそれを制御する装置の能力によるが、書き込みの確認だけでもかなりの時間を浪費してしまうことが予測される場合には、部分的にデータ領域を確認する方法でも問題ない。この場合はサービスデータのある集中した領域を確認するよりは、全体をランダムに確認する方がデータの破壊動作の場合には効果的である。
【００３５】
さらに、作為的なデータ・ハッキング行為を防止するためには、書き込み許可を確認する際に、そのデータの存在する装置がどういう装置であるかを確認することが望ましい。ＩＥＥＥ１３９４やＤＶＩでは、コピー防止の機能としてあらかじめ認定許可される機器を登録し、これを秘密裏に確認する技術が確立されている。いわゆる機器認証と呼ばれる技術である。自身の記録されている装置が不正なものであるか無いかを同様の技術を使って確認することも有効な手段の一つである。例えば、明らかにランダムアクセスメモリ（以下、ＲＡＭという）領域に存在するのであれば、それは蓄積されたものではないと判断できるので、このような場合には書き込み確認判定は不可と判断すべきである。
【００３６】
ヘッダープログラム２２は、上記書き込み許可確認で問題なしと判断されない限り以降の処理は行わず、この段階でサービスの再生作業をすべて中断する。
【００３７】
書き込み許可が確認できると（ステップＳ１で「Ｙｅｓ」）、次にサービス再生制限事項を読み出すために暗号化手段を取得し（ステップＳ２）、この指示に従って暗号を解読するために準備を実行する。その後、暗号化された制限事項データを取り込み、残りの実行可能な回数を取得する（ステップＳ３）。回数が取得された段階で、プロセス・レイヤー３２は上層のユーザ・インタフェース・レイヤー３１を通じて残りの許可回数を例えばディスプレイ／スピーカ８を通じてユーザに通知（表示）する（ステップＳ４）と共に、ユーザに実際に実行するかどうかの確認を行う（ステップＳ５）。ユーザがもし何らかの偶発的事由もしくは誤ってサービスの実行を命じた場合には、この段階でこの実行動作を停止することが可能である。また、このサービス再生確認は、後述するサービス制限情報だけを取り出す場合にも利用される。これは、この情報を利用してユーザに対して蓄積されたサービス・データ・ファイル２１の管理手段を提供するためである。
【００３８】
ユーザからのサービス再生実行が確認されると、ヘッダープログラム２２は記録されている再生許可回数をひとつ減らすように実行許可条件フラグを更新する（ステップＳ６）。この実行許可条件フラグそのものは上述した通り暗号化されているので、当然暗号化した状態でデータを記録装置側に供給し書き込む。
【００３９】
上記更新後、今回の実行回数が最後の許可回数である場合（ステップＳ７で「Ｙｅｓ」）には、その状態である旨、下層のデータ・アクセス・レイヤー３３にサービスを開始する前に通知する（ステップＳ８）。
【００４０】
以上がサービスをはじめる前にヘッダープログラム２２で実行される事前の確認作業である。この段階まで処理された後に、実際のサービスデータへアクセスを開始することになる。なお、サービスデータも何らかの形式で暗号化されている必要がある。暗号化手法そのものは、上述した実行許可条件フラグを暗号化したものと同じものでも不可能ではない。しかし、例えばサービスデータがＭＰＥＧ圧縮データのように非常に大きなファイルであり、かつサービスデータの取得速度が実行許可条件フラグの取得速度と比較して非常に高いものが要求される。実行許可条件フラグはその取得速度に対しては制限がなく、ユーザが取得のために待っている時間が肝要の範囲であれば、全体の動作としては特に問題は起こらない。しかし、ＭＰＥＧ圧縮された映像や音声ファイルの場合、データ取得時間が規定時間を越えてしまった場合には、画像破壊や音声ノイズといった製品としては致命的な問題を引き起こしてしまう。本実施例ではこのような問題に対処するために、サービスデータを取得する手段を個別に設定するような手法を記載している。
【００４１】
サービスデータ取得手段の準備が完了すると、サービスデータの取得を開始する。サービスデータの取得は、主に下層のデータ・アクセス・レイヤー３３で実行される。図５にサービスデータ取得時のデータ・アクセス・レイヤー３３の動作手順を示している。
【００４２】
データ・アクセス・レイヤー３３は、ＨＤＤ５上に記録された実際のデータを読み込む前に、まず上記許可回数が最後であるかどうかの判断結果によって動作を切り分ける。最終の再生許可回数ではない場合には（ステップＳ２１で「Ｙｅｓ」）、通常と同じく繰り返しデータを読み出し（ステップＳ２２）、サービスデータをデコードするデコーダ７にこれを配布する。最終の再生回数に達していた場合には（ステップＳ２１で「Ｎｏ」）、まずは自身のデータファイルの管理テーブルが保管されている領域を消去する。この部分のデータを消去することで、自身データの存在を次回からシステム全体から見えなくなくするためである。記録機器の記録方式によるが、このような管理テーブルを持たない記録機器を利用する場合には、当然この管理テーブルの消去動作は省略される。また、機器によっては記録媒体の表面に連続的にデータを書き込むのではなく、ある程度離れた別の複数の領域に分けて記録するものもある。この場合には、少なくともこの最後のサービスを実施している最中は異なる領域を示す情報は確保しておかなければならない。しかし、サービスを再生中は必ずしも蓄積媒体の上に保管する必要はなく、例えば図示せぬＲＡＭ上に退避させて、サービスの再生が終了した領域から順次消去させても同じ効果を得ることが可能である。また、極端な例としては、サービスの再生が完全に終了した段階で消去することでも対応することは可能である。具体的には、まず管理テーブルの改ざんを確認し（ステップＳ２３）、改ざんされていなければ、管理データを改ざんすることになる（ステップＳ２４）。
【００４３】
次にデータ・アクセス・レイヤー３３は実際に使用するデータを記録媒体から読み出す（ステップＳ２５）。そして、読み出したデータを上位のプロセス・レイヤー３２、もしくはサービスを再生するデコーダ７に渡す段階で、読み出したデータが書き込まれている記録媒体の領域に異なるデータを上書きで書き込む（ステップＳ２６）。書き込むデータは特に指定はない。この書き込み動作によって、今回使用されているサービスデータそのものを破壊あるいは消去する。通常ＨＤＤに代表されるようなデジタル式の記録機器からの読み込みは、放送電波あるいはアナログ信号のような継続的な通信とは異なる。データそのものにいくつか区切りを設定し、この区切りの単位で読み込み、この量を読み込んだ後に小休止に入ることが多い。
【００４４】
もちろん、サービスデータが非常に膨大で、常に読み込みを継続しなければならない場合もあり得る。上記データの上書き・破壊動作はこのような小休止期間を利用して実行することが可能である。小休止期間が規定量すべてを書き込むだけの時間に足らないということもありえるが、一部でもデータの上書きを実行できれば、サービスデータの少なくとも一部は破壊できるので問題ない。
【００４５】
取得されたサービスデータはデコーダ７でデコードされ、ユーザに提供されることになる。具体的には、サービスデータの解読コードやパラメータを取得し（図４のステップＳ９）、さらにサービスデータのデコード用ソフトウェアやパラメータを取得し（同図ステップＳ１０）、取得した解読コードに基づき実際にサービスデータを解読し（ステップＳ１１）、デコーダ７にてこの解読したデータをデコード（ＭＰＥＧ復号等）する。
【００４６】
最後にサービスが完了すると、再度、今回のサービス再生が最終回であるかどうかを確認し（ステップＳ１３）、最終回である場合には（ステップＳ１３で「Ｙｅｓ」）、自身のサービスデータが記録媒体の管理テーブルから消去され、データが破壊されているかどうかを確認する（ステップＳ１４）。この動作は必ずしも必要とは限らないが、上述したようにサービスデータと記録媒体の読み出し速度のバランスによって、再生中にデータ領域の上書きができない可能性が考えられる。このような場合には、再度データ領域を確認して必要に応じて上書き、破壊することが可能である。
【００４７】
図６には再生時間制限（再生期限）が設定されている場合のプロセス・レイヤー３２の動作例を示している。以下、この例について説明する。再生回数制限の場合と同じようにまず、自身の記録されている領域が自身で書き込み可能であるか否かを判断する（ステップＳ３１）。何らかの理由で書き込み不能か、あるいは書き込み媒体の信頼性が確保できない場合（例えば、図示せぬＲＡＭ領域にある等の場合）には、即座にサービスの再生を停止する。その後、先の図４のフローチャートと同様に再生制限フラグである実行許可条件フラグを取得するための取得・解読手法を取り込み（ステップＳ３２）、実際の制限時間データを取得する（ステップＳ３３）。ここで、ユーザが再生を実際に実行するか否かを再確認する（ステップＳ３４）。実行なら、次に取得した制限時間と自身のもつ時間情報を比較して（ステップＳ３５）、現時間が制限時間を越えている場合にはサービス再生権なしと判断して自身のデータ領域の上書き、あるいは消去動作に移行し、管理テーブルも含めてデータを消去して終了する（ステップＳ３６）。
【００４８】
現在の時間を知る手段としては、例えば、通常のパーソナルコンピュータでは内部に電池と時計を内蔵し自己管理しており、これを利用することが可能である。しかし、この自己管理方式の時計はハッキングされやすい傾向にあり、この例での使用はあまり望ましくない。デジタルＴＶ放送では通常、時間に関するデータが放送電波の中で伝送されている。伝送に要する時間遅れ等も有り得るが、この例では、ここまで正確な時間管理は基本的には必要ない。この放送電波による時間管理の方が、適宜更新されハッキングの恐れも少なく、本受信装置での利用に適当である。
【００４９】
制限時間内であれば、図５と同様にサービスデータを取得し、ユーザに対してサービスの再生を実施する。具体的には、ステップＳ３７からステップＳ４０の動作を行なう。これらステップの動作は図４のステップＳ９乃至Ｓ１２と同様であるので、その説明は割愛する。
【００５０】
図６の例では、サービスを再生している途中にサービスデータ領域を上書き、または消去する必要が無い点で図４の場合とは相違している。また、図６においては時間の確認をサービスの開始前に実施したが、これはサービス再生の途中やサービス再生の後とすることも可能であり、いずれの場合でも、例えばサービス再生が完了した後に自身のデータを消去することが考えられる。これら自身のデータの消去タイミングは技術的観点よりもサービス提供者のビジネス的観点から決定されるのが好ましい。
【００５１】
なお、図４および図６の例では、回数制限の場合と時間制限の場合を別々に説明したが、サービスデータの制限フラグ情報は必ずしも一方だけである必要はない。サービスデータとして上記情報２つが同時に存在する場合も有り得ることは言うまでもない。この場合は、例えば最初に回数制限事項を確認し、さらに時間制限事項を確認し、両方が制限範囲内である場合のみサービスの再生を開始する。どちらか一方でも制限範囲を超えている場合には、サービスデータの消去動作を伴うように動作させればよい。
【００５２】
図７は、図１のデータ受信装置におけるファイル管理機能の画面表示例を示している。上記説明したような制限つきのサービスデータを蓄積するサービスでは、期限切れで事実上、ユーザがサービス再生できない無用なファイルデータを、ユーザが気がつかない間に溜め込んでしまうということが生じやすい。当然このような無用なサービスデータを保管しておくことは記録媒体容量の無駄使いになる。また、サービス提供者側にとっては、宣伝広告やデモ用のサービス・データ・ファイル提供にも支障となる可能性も有る。従って、利用不可能なサービスデータを記録媒体上から極力除去することが必要である。
【００５３】
図７の例は蓄積されているサービスデータの制限事項をユーザに通知することで、ユーザの管理作業を簡略化させるものである。図７（Ａ）の例では、記録媒体上に存在するサービスファイルのリストを表示させ、そのリスト情報の一項目として、上記説明したサービス再生制限フラグ情報を表示させている。すなわち、７１はサービスにかかる認識情報であり、７１１は題名、７１２は記録日、７１３は記録形式、７１４は複写許可情報である。一方、７２はサービス再生制限フラグ情報である再生制限情報である。
【００５４】
サービス情報を表示させるためには、サービスデータ自身あるいはサービス制限事項を管理している管理テーブルからの情報取得が必要になる。図４および図６に示したプロセス・レイヤー３２のフローチャートにおいては、ステップＳ５（図４参照）あるいはステップＳ３４（図６参照）の時点でプロセス・レイヤー３２がユーザ・インタフェース・レイヤー３１を通してサービス制限事項情報を取得して、サービスを本当に開始するかどうかの再確認をする構成になっている。この段階でリスト情報を表示させるプログラム側からプロセス・レイヤー３２にサービス再生停止を連絡することでサービス再生制限情報だけを取り出すことが可能である。
【００５５】
図８（Ａ）は、さらにユーザにサービス再生制限を越えているファイルを強調させることでユーザに対してより注意を促す場合のディスプレイ／スピーカ８での操作用画面表示例である。ユーザが、リモコン１１の図示せぬカーソルキー等を用いて「Ｙｅｓ」を選択すると、図７（Ｂ）あるいは（Ｃ）の如き画面表示がなされる。同図（Ｂ）は、再生制限を越えているファイルのみを表示しており、同図（Ｃ）は再生制限を越えているファイルをその文字を太字で表示することで区別して表示している。なお、文字の表示色を他と変えることで区別することも可能である。図７（Ｂ）あるいは（Ｃ）の如き画面表示がなされた後に、ディスプレイ／スピーカ８の画面上には、図８（Ｂ）に示す如き表示がなされて、実際に再生制限を越えているファイルを消去する。
【００５６】
再生制限日時が規定され、期限切れのファイルは上述したようにその期限を取得し、現在時間と照合すれば自動的に期限切れのファイルを検索することが可能であると共に、期限切れのファイルは確実に自動的にこれを消去する機能を保有する。本実施例におけるこの特性を利用して、自動的に期限切れファイルを検索し消去することで記録媒体上の有効容量を手軽に広げることが可能になる。この自動検索及び消去機能はユーザからの命令で起動させることもあれば、サービス提供者側から定期メンテナンスの一環として受信装置側に起動指示を出しても良い。あるいは、受信装置には時間管理機能が明らかに備わっており、一定時間毎に定期的に起動させることで同様の効果を得ることが可能である。
【００５７】
以上述べた実施の形態によれば、蓄積型のサービス受信機において、サービス再生条件を確実に厳守できるサービスデータ形式を実現することが可能になる。そしてオンライン・　サービスであってもレンタルのような指定期限付きのサービス提供が可能となる。特に上述したサービス再生限定条件（実行許可条件）は、ユーザからの要求にしたがってサービス提供者側が任意に指定して配布することも可能である。このことは、旧来のオンライン・サービスにあるような購買のみのユーザ選択ではなく、たとえば一週間という期間、あるいは５回までの番組の再生・視聴がユーザの持つ受信装置上で可能となり、サービス享受の選択を広げることができる。またサービス提供者側にとっても蓄積型の受信装置を利用することで、繰り返し同じサービスデータを流す必要がなくなるという効果が得られる。
【００５８】
また、受信装置上の再生不能ファイルの管理を簡素化する共に、記録媒体の記録可能領域を簡単に更新させることも可能になり、ひいてはサービス提供者から提供される無償プログラムをより安全に実行させることも可能になる。
【００５９】
図９には図１の受信装置におけるサービス・データ・ファイルの他の実施の形態を示す。この例では図２、図４及び図６で示したようなサービス開始を確認するプログラムや実行許可条件フラグを取得、解読するための解読手順などはまったく含まれず、サービス・データ・ファイル９１として、サービス限定条件である実行許可条件フラグ９２とサービスデータ９３だけが含まれている例である。図１に示したような受信装置を使えば、ＨＤＤ５上でもデータは暗号化され、サービス限定条件の確認動作もデータ監視部／タイマー１０で完全に外部から隔離され、サービスデータ９３の搾取に対して非常に安全な状態でサービスの提供が可能になる。このような場合には、上述したヘッダープログラム２２自身を上記データ監視部／タイマー１０の内部にあらかじめ内蔵して実行させることも可能である。
【００６０】
このようにヘッダープログラム２２自体は必ずしもサービスデータ２３そのものに付随させる必要性はない。サービス制限事項そのものも、必ずしもサービスデータ自身と同一のファイル上に存在させる必要性はない。例えば、受信装置内部で確実に保護できるような方式で実行許可条件フラグとサービスデータを別の形式で保管し、これら制限情報とサービスデータを確実にリンクさせるようなリンク・リストを作成しておいても問題ない。この実施の形態でも、サービスを開始する前にヘッダープログラムによってサービスの開始条件を確認し、サービスデータの保管されている領域が確実に上書き、あるいは消去できることを確認した後にサービスの再生を始める。
【００６１】
【発明の効果】以上述べたように本発明によれば、記録媒体の記録可能領域の確保を容易に行なうことの出来るデータ受信装置及びデータ受信方法を提供することが出来、有用である。
【図面の簡単な説明】
【図１】本発明になるデータ受信装置の実施の形態の一例を示すブロック図。
【図２】図１に示す装置のＨＤＤにおけるサービス・データ・ファイルの構造を示す図。
【図３】図１に示す装置におけるサービス開始確認ヘッダープログラムを実行するための構成を示す図。
【図４】サービスデータの再生回数に対して制限が規定されている場合の図１のデータ監視部／タイマーにおける動作例を示すフローチャート。
【図５】図１のデータ監視部／タイマーにおけるサービスデータ取得時の動作手順を示すフローチャート。
【図６】サービスデータの再生期限が設定されている場合の図１のデータ監視部／タイマーにおける動作例を示すフローチャート。
【図７】図１の装置における蓄積サービスデータの制限事項をユーザに通知する表示例を示す図。
【図８】図１の装置におけるユーザへの通知のための表示例を示す図。
【図９】図１の受信装置におけるサービス・データ・ファイルの他の実施の形態を示す図。
【符号の説明】
２：　受信部
３：　暗号化部
５：　ＨＤＤ
６：　暗号解読部
７：　デコーダ
８：　ディスプレイ／スピーカ
１０：　データ監視部／タイマー
１３：　システム制御部
１４：　通信バス
【図１】
2004088543.tif 000003
【図２】
2004088543.tif 000004
【図３】
2004088543.tif 000005
【図４】
2004088543.tif 000006
【図５】
2004088543.tif 000007
【図６】
2004088543.tif 000008
【図７】
2004088543.tif 000009
【図８】
2004088543.tif 000010
【図９】
2004088543.tif 000011