JP2007535204A - 認証プログラム実行方法 - Google Patents

Abstract

従来技術では、プログラムを不揮発性メモリに一旦保存してプログラムを起動する場合、起動直前にそのプログラムを認証する。プログラムの起動開始までには、暗号化された値を復号する等の計算が必要で、計算に要する時間の分だけ応答性が悪くなるという問題を有する。この課題を解決するために、プログラムの保存直前に認証を行い、プログラムの起動時には認証を一切しない、もしくは、証明書の有効性を確認するという認証の一部のみを行っている。

Description

本発明は、ダウンロードしたプログラムの信用性を確認し、信用性が確認されたプログラムを実行する認証プログラム実行方法に関する。

デジタルテレビにおけるプログラムをダウンロードして、そのプログラムの信用性を確認・保証する機能は、ＤＶＢ−ＭＨＰ規格書“ＥＴＳＩ ＴＳ １０１ ８１２ Ｖ１．２．１ ＤＶＢ−ＭＨＰ仕様１．０．２”等に記載されている。ここでは、受信中の放送波に重畳されたプログラムに対し、改竄が行われていないかの検証と、そのプログラムが信用できる機関によって発行されたものであるかの検証を行う機能を有する。これにより、デジタルテレビにダメージを与えるような、書き換えられて本来とは異なる動作をするプログラムや、他人になりすました第三者のプログラムが起動されることを未然に防ぐことができる。

また、特開２０００−２９８３３号では、データを蓄積・送信するサーバ装置と、ネットワークを経由してデータを受信する端末装置とで構成され、受信されたデータは端末装置に蓄積し、蓄積されたデータが不正利用されることを防止する技術について述べている。特開２０００−２９８３３号の図１によると、サーバ装置１０は、端末装置２０からの要求により記憶手段１５に記憶されたデータを記憶手段２３にコピーし、記憶手段２３に記憶されたデータを利用する時、照会手段２６によりサーバ装置１０に問い合わせを行い、認証手段１３によりデータの利用を監査し、問題がなければ、端末装置２０においてデータを利用するという技術が説明されている。上記の装置では、電源のＯＮ／ＯＦＦが発生しても、不揮発性メモリに保存されたデータの信用性を確認後、データの読み込みをすることができる。以下では、プログラムやデータの信用性を確認することを認証と呼ぶ。

しかしながら、従来の技術においては、プログラムを不揮発性メモリに一旦保存し、装置の電源のＯＦＦ／ＯＮ後にプログラムを起動する場合、起動直前にそのプログラムを認証する。この場合、プログラムの起動開始までには、暗号化された値を復号する等の計算が必要で、計算に要する時間の分だけ応答性が悪くなるという問題を有する。特に、プログラムが頻繁に起動される、もしくは、プログラムの容量規模が大きいような場合では、頻度と容量規模に比例して計算量が増えるので応答性が劣化していく。

上記問題点を鑑みて、プログラムの信用性を保証しながらも、プログラムの起動開始までに要する時間を短縮し、応答性の向上したデジタルテレビ等のプログラム認証装置を提供することが望まれる。

本発明は、プログラムの保存直前に認証を行い、プログラムの起動時には認証を一切しない、もしくは、一部のみ認証するだけでも、信用性の保証と応答性の向上が両立可能な認証プログラム実行方法を提供することを目的とする。

前記従来の課題を解決するために、本発明に係る認証プログラム実行方法は、トランスポートストリームに含まれるプログラムのデータファイルの保存に関する情報に従い、前記トランスポートストリームに含まれるプログラムを認証し放送受信装置に保存する認証・保存ステップと、前記認証・保存したプログラムを実行する実行ステップとを有する認証プログラム実行方法であって、前記認証・保存ステップは、前記プログラムに含まれるデータファイルのハッシュ値が前記データファイルに対応するハッシュファイルに格納されたハッシュ値と一致するかどうかをチェックする第１のステップと、前記プログラムに含まれる証明書ファイルの有効性を検証する第２のステップと、前記プログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記プログラムに含まれる署名ファイルの署名値を復号した値と、前記プログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第３のステップと、前記第１のステップにてハッシュ値が一致し、前記第２のステップにて前記証明書ファイルが有効であると判定され、前記第３のステップにてハッシュ値が一致すると判定された場合に前記プログラムを認証し、前記保存に関する情報に従い前記プログラムのデータファイルを保存する第４のステップとを含み、前記実行ステップは、前記保存したプログラムに含まれる証明書ファイルの有効性を検証する第５のステップを含み、前記第５のステップにて、前記保存したプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存したプログラムを再度認証し、実行することを特徴とする。

これによって、信用性を確保しながら起動開始までに要する時間を短縮することができる。

また、前記プログラムがディレクトリ構造を有する場合には、各ディレクトリに含まれる前記データファイルと、対応する前記ハッシュファイルとは同一ディレクトリ内に存在し、前記第１のステップは前記各ディレクトリのデータファイルに対して実行されてもよい。

これによって、各ディレクトリに含まれるデータファイルごとに、データファイルのハッシュ値がデータファイルに対応するハッシュファイルに格納されたハッシュ値と一致するかどうかをチェックすることができる。

また、前記第２のステップは、前記プログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第６のステップを有し、前記プログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定してもよい。

ここで、前記第２のステップは、さらに、前記プログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第７のステップを有し、前記プログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、認証日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定してもよい。

これによって、ルート証明書が一致しない、または証明書の有効期間が過ぎてしまったプログラムを保存するのを防止することができる。

また、前記第５のステップは、前記保存したプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第８のステップを有し、前記保存したプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定してもよい。

ここで、前記第５のステップは、さらに、前記保存したプログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第９のステップを有し、前記保存したプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、実行日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定してもよい。

これによって、ルート証明書が一致しない、または証明書の有効期間が過ぎてしまったプログラムを実行するのを防止することができる。

さらに、本発明は、このような認証プログラム実行方法として実現することができるだけでなく、このような認証プログラム実行方法が含む特徴的なステップを手段として備える認証プログラム実行装置として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。

以上の説明から明らかなように、本発明に係る認証プログラム実行方法によれば、プログラムの信用性を確保しながら起動開始までに要する時間を短縮することができる。

以下本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
本発明に係るケーブルテレビシステムの実施の形態を、図面を参照しながら説明する。図１は、ケーブルシステムを構成する装置の関係を表したブロック図であり、ヘッドエンド１０１及び３個の端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３で構成される。本実施の形態では、１つのヘッドエンドに対して３つの端末装置が結合されているが、任意の数の端末装置をヘッドエンドに結合しても、本発明は実施可能である。

ヘッドエンド１０１は、複数の端末装置に対して映像・音声・データ等の放送信号を送信するとともに、端末装置からのデータ送信を受信する。これを実現するため、ヘッドエンド１０１と端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３間の伝送に用いられる周波数帯域は、分割して用いられる。図２は、周波数帯域の分割の一例を示す表である。周波数帯域は、Ｏｕｔ Ｏｆ Ｂａｎｄ（略称ＯＯＢ）とＩｎ−Ｂａｎｄの２種類に大別される。５〜１３０ＭＨｚがＯＯＢに割り当てられ、主にヘッドエンド１０１と端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３間のデータのやり取りに使用される。１３０ＭＨｚ〜８６４ＭＨｚはＩｎ−Ｂａｎｄに割り当てられ、主として、映像・音声を含む放送チャンネルに使用される。ＯＯＢではＱＰＳＫ変調方式が、Ｉｎ−ＢａｎｄはＱＡＭ６４変調方式が使用される。変調方式技術については、本発明に関与が薄い公知技術であるので、詳細な説明は省略する。図３は、ＯＯＢ周波数帯域の更に詳細な使用の一例である。７０ＭＨｚ〜７４ＭＨｚはヘッドエンド１０１からのデータ送信に使用され、全ての端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３が、ヘッドエンド１０１から同じデータを受け取ることになる。一方、１０．０ＭＨｚ〜１０．１ＭＨｚは端末装置Ａ１１１からヘッドエンド１０１へのデータ送信に使用され、１０．１ＭＨｚ〜１０．２ＭＨｚは端末装置Ｂ１１２からヘッドエンド１０１へのデータ送信に使用され、１０．２ＭＨｚ〜１０．３ＭＨｚは端末装置Ｃ１１３からヘッドエンド１０１へのデータ送信に使用される。これにより、各端末装置固有のデータを各端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３からヘッドエンド１０１に送信することができる。図４は、Ｉｎ−Ｂａｎｄの周波数帯に対する使用の一例である。１５０〜１５６ＭＨｚと１５６〜１６２ＭＨｚはそれぞれテレビチャンネル１とテレビチャンネル２に割り当てられ、以降、６ＭＨｚ間隔でテレビチャンネルが割り当てられている。３１０ＭＨｚ以降は、１ＭＨｚ単位でラジオチャンネルに割り当てられている。これらの各チャンネルはアナログ放送として使用してもデジタル放送として使用してもよい。デジタル放送の場合は、ＭＰＥＧ２仕様に基づいたトラスポートパケット形式で伝送され、音声や映像に加え、各種データ放送用データも送信することができる。

ヘッドエンド１０１は、これらの周波数帯域に適切な放送信号を送信するため、ＱＰＳＫ変調部やＱＡＭ変調部等を有する。また、端末装置からのデータを受信するため、ＱＰＳＫ復調器を有する。また、ヘッドエンド１０１は、これら変調部及び復調部に関連する様々な機器を有すると考えられる。しかし、本発明は主として端末装置に関わるので、詳細な説明は省略する。

端末装置Ａ１１１、端末装置Ｂ１１２、端末装置Ｃ１１３は、ヘッドエンド１０１からの放送信号を受信し再生する。また、ヘッドエンド１０１に対して、各端末装置固有のデータを送信する。３つの、端末装置は本実施の形態では同じ構成を取る。

図５は、端末装置のハードウエア構成を表すブロック図である。５００は端末装置であり、ＱＡＭ復調部５０１、ＱＰＳＫ復調部５０２、ＱＰＳＫ変調部５０３、ＴＳデコーダ５０５、オーディオデコーダ５０６、スピーカ５０７、ビデオデコーダ５０８、ディスプレイ５０９、２次記憶部５１０、１次記憶部５１１、ＲＯＭ５１２、入力部５１３、ＣＰＵ５１４で構成される。また端末装置５００には、ＰＯＤ５０４が着脱できる。

図６は、端末装置５００の外観の一例である薄型テレビである。端末装置は様々な構成で実現できるが、本実施例ではＯｐｅｎＣａｂｌｅ（ＴＭ）及びＯＣＡＰに基づいて構成された端末装置を例にとって説明する。

６０１は、薄型テレビの筐体であり、ＰＯＤ５０４を除く、端末装置５００の構成要素をすべて内蔵している。

６０２はディスプレイであり、図５におけるディスプレイ５０９に相当する。
６０３は複数のボタンで構成されるフロントパネル部であり、図５の入力部５１３に相当する。

６０４は信号入力端子であり、ヘッドエンド１０１との信号の送受信を行うためにケーブル線を接続する。信号入力端子は、図５のＱＡＭ復調部５０１、ＱＰＳＫ復調部５０２、ＱＰＳＫ変調部５０３と接続されている。

６０５は、図５のＰＯＤ５０４に相当するＰＯＤカードである。ＰＯＤ５０４は、図６のＰＯＤカード６０５のように、端末装置５００とは独立した形態を取り、端末装置５００に着脱可能となっている。ＰＯＤ５０４の詳細は後述する。

６０６はＰＯＤカード６０５を挿入する挿入スロットである。
図５を参照して、ＱＡＭ復調部５０１は、ＣＰＵ５１４から指定された周波数を含むチューニング情報で、ヘッドエンド１０１でＱＡＭ変調され送信されてきた信号を復調し、ＰＯＤ５０４に引き渡す。

ＱＰＳＫ復調部５０２は、ＣＰＵ５１４から指定された周波数を含むチューニング情報で、ヘッドエンド１０１でＱＰＳＫ変調され送信されてきた信号を復調し、ＰＯＤ５０４に引き渡す。

ＱＰＳＫ変調部５０３は、ＣＰＵ５１４から指定された周波数を含む復調情報で、ＰＯＤ５０４から渡された信号をＱＰＳＫ復調し、ヘッドエンド１０１に送信する。

ＰＯＤ５０４は、図６のように端末装置本体５００から着脱可能な形態をしている。端末本体５００とＰＯＤ５０４の接続インターフェースは、ＯｐｅｎＣａｂｌｅ（ＴＭ） ＣａｂｌｅＣＡＲＤ（ＴＭ） Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＯＣ−ＳＰ−ＣＣ−ＩＦ−Ｉ１５−０３１１２１）及び、この仕様書から参照されている仕様書で定義されている。なお、仕様書のＣａｂｌｅＣＡＲＤとはＰＯＤのことを指している。ここでは、詳細は省略し、本発明に関する部分のみを解説する。

図７は、ＰＯＤ５０４の内部構成を表すブロック図である。ＰＯＤ５０４は、第１デスクランブラ部７０１、第２デスクランブラ部７０２、スクランブラ部７０３、第１記憶部７０４、第２記憶部７０５、ＣＰＵ７０６で構成される。

第１デスクランブラ部７０１は、ＣＰＵ７０６からの指示により、端末装置５００のＱＡＭ復調部５０１から暗号化された信号を受け取り、復号を行う。そして、復号された信号を端末装置５００のＴＳデコーダ５０５に送る。デコードに必要な鍵などの情報はＣＰＵ７０６から適宜与えられる。具体的には、ヘッドエンド１０１はいくつかの有料チャンネルを放送している。ユーザーが、この有料チャンネルを購買すると、第１デスクランブラ部７０１は、ＣＰＵ７０６から鍵等の必要な情報を受け取りデスクランブルすることで、ユーザーは有料チャンネルを閲覧することができる。鍵などの必要な情報が与えられない場合は、第１デスクランブラ部７０１は、デスクランブルを行わず、受け取った信号をそのまま、ＴＳデコーダ５０５に送る。

第２デスクランブラ部７０２は、ＣＰＵ７０６からの指示により、端末装置５００のＱＰＳＫ復調部５０２から暗号化された信号を受け取り、復号を行う。そして、復号されたデータをＣＰＵ７０６に引き渡す。

スクランブラ部７０３は、ＣＰＵ７０６からの指示により、ＣＰＵ７０６から受け取ったデータを暗号化し、端末装置５００のＱＰＳＫ変調部５０３に送る。

第１記憶部７０４は、具体的にはＲＡＭ等の一次記憶メモリで構成され、ＣＰＵ７０６が処理を行う際、一時的にデータを保存するために使用される。

第２記憶部７０５は、具体的にはフラッシュＲＯＭ等の２次記憶メモリで構成され、ＣＰＵ７０６が実行するプログラムを格納し、また、電源ＯＦＦになっても消去されては困るデータの保存に使用される。

ＣＰＵ７０６は、第２記憶部７０５が記憶するプログラムを実行する。プログラムは複数のサブプログラムで構成される。図８は、第２記憶部７０５が記憶するプログラムの一例である。図８では、プログラム８００は、メインプログラム８０１、初期化サブプログラム８０２、ネットワークサブプログラム８０３、再生サブプログラム８０４、ＰＰＶサブプログラム８０５等複数のサブプログラムで構成されている。

ここでＰＰＶとはＰａｙ Ｐｅｒ Ｖｉｅｗの略であり、映画など特定の番組を有料で視聴できるようにするサービスである。ユーザーが暗証番号を入力すると、購入したことがヘッドエンド１０１に通知され、スクランブルが解除され、視聴することが出来る。この視聴により、ユーザーは後日、購入代金を支払うものである。

メインプログラム８０１は、ＣＰＵ７０６が電源投入時に最初に起動するサブプログラムであり、他のサブプログラムの制御を行う。

初期化サブプログラム８０２は、電源投入時にメインプログラム８０１によって起動され、端末装置５００との情報交換等を行い、初期化処理を行う。初期化処理の詳細は、ＯｐｅｎＣａｂｌｅ（ＴＭ） ＣａｂｌｅＣＡＲＤ（ＴＭ） Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＯＣ−ＳＰ−ＣＣ−ＩＦ−Ｉ１５−０３１１２１）及び、この仕様書から参照されている仕様書で定義されている。また、仕様書に定義されていない初期化処理も行う。ここでは、その一部を紹介する。電源が投入されると、初期化サブプログラム８０２は、第２記憶部７０５が記憶する第１の周波数を端末装置５００のＣＰＵ５１４を通して、ＱＰＳＫ復調部５０２に通知する。ＱＰＳＫ復調部５０２は、与えられた第１の周波数でチューニングを行い、信号を第２デスクランブラ部７０２に送る。また、初期化サブプログラム８０２は、第２記憶部７０５が記憶する第１の鍵等の復号情報を第２デスクランブラ部７０２に与える。その結果、第２デスクランブラ部７０２は、デスクランブルを行い、初期化サブプログラム８０２を実行するＣＰＵ７０６に引き渡す。よって、初期化サブプログラム８０２は情報を受け取ることができる。本実施の形態では、初期化サブプログラム８０２はネットワークサブプログラム８０３を通して情報を受け取ることとする。詳細は後述する。

また、初期化サブプログラム８０２は、第２記憶部７０５が記憶する第２の周波数を端末装置５００のＣＰＵ５１４を通して、ＱＰＳＫ変調部５０３に通知する。初期化サブプログラム８０２は第２記憶部７０５が記憶する暗号化情報をスクランブラ部７０３に与える。初期化サブプログラム８０２が送信したい情報を、ネットワークサブプログラム８０３を介して、スクランブラ部７０３に与えると、スクランブラ部７０３は、与えられた暗号化情報を用いて、データを暗号化し、端末装置５００のＱＰＳＫ変調部５０３に与える。ＱＰＳＫ変調部５０３は、与えられた暗号化された情報を変調し、ヘッドエンド１０１に送信する。

この結果、初期化サブプログラム８０２は、端末装置５００、第２デスクランブラ部７０２、スクランブラ部７０３、ネットワークサブプログラム８０３を通して、ヘッドエンド１０１と双方向通信を行うことができる。

ネットワークサブプログラム８０３は、メインプログラム８０１、初期化サブプログラム８０２等の複数のサブプログラムから使用される、ヘッドエンド１０１との双方向通信を行うためのサブプログラムである。具体的には、ネットワークサブプログラム８０３を使用する他のサブプログラムに対して、ＴＣＰ／ＩＰによって、ヘッドエンド１０１と双方向通信を行っているように振舞う。ＴＣＰ／ＩＰは、複数の装置間で情報交換を行うためのプロトコルを規定した公知の技術であり、詳細な説明は省略する。ネットワークサブプログラム８０３は、電源投入時に初期化サブプログラム８０２に起動されると、予め第２記憶部７０５が記憶しているＰＯＤ５０４を識別する識別子であるＭＡＣアドレス（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌアドレスの略）を、端末装置５００を通してヘッドエンド１０１に通知し、ＩＰアドレスの取得を要求する。ヘッドエンド１０１は、端末装置５００を介してＰＯＤ５０４にＩＰアドレスを通知し、ネットワークサブプログラム８０３は、ＩＰアドレスを第１記憶部７０４に記憶する。以降、ヘッドエンド１０１とＰＯＤ５０４は、このＩＰアドレスを、ＰＯＤ５０４の識別子として使用し、通信を行う。

再生サブプログラム８０４は、第２記憶部７０５が記憶する第２の鍵等の復号情報や、端末装置５００から与えられる第３の鍵等の復号情報を第１デスクランブラ部７０１に与えて、デスクランブルを可能にする。また、ネットワークサブプログラム８０３を通して、第１デスクランブラ部７０１に入力されている信号が、ＰＰＶチャンネルであることの情報を受け取る。ＰＰＶチャンネルと知ったときは、ＰＰＶサブプログラム８０５を起動する。

ＰＰＶサブプログラム８０５は、起動されると、端末装置５００に番組の購入を促すメッセージを表示し、ユーザーの入力を受け取る。具体的には、端末装置５００のＣＰＵ５１４に画面に表示したい情報を送ると、端末装置５００のＣＰＵ５１４上で動作するプログラムが、端末装置５００のディスプレイ５０９上にメッセージを表示する。ユーザーは、端末装置５００の入力部５１３を通して暗証番号を入力すると、端末装置５００のＣＰＵ５１４が、それを受け取り、ＰＯＤ５０４のＣＰＵ７０６上で動作するＰＰＶサブプログラム８０５に通知する。ＰＰＶサブプログラム８０５は、受け取った暗証番号をネットワークサブプログラム８０３を通してヘッドエンド１０１に送信する。ヘッドエンド１０１は、暗証番号が正しければ、復号に必要な第４の鍵などの復号化情報をネットワークサブプログラム８０３を介して、ＰＰＶサブプログラム８０５に通知する。ＰＰＶサブプログラム８０５は受け取った第４の鍵などの復号化情報を第１デスクランブラ部７０１に与え、第１デスクランブラ部７０１は、入力されている信号をデスクランブルする。

図５を参照して、ＴＳデコーダ５０５は、ＰＯＤ５０４から受け取った信号のフィルタリングを実施し、必要なデータをオーディオデコーダ５０６及びビデオデコーダ５０８、ＣＰＵ５１４に引き渡す。ここで、ＰＯＤ５０４から来る信号はＭＰＥＧ２トランスポートストリームである。ＭＰＥＧ２トランスポートストリームの詳細はＭＰＥＧ規格書 ＩＳＯ／ＩＥＣ１３８１８１−１に記載されており、本実施の形態では詳細は省略する。ＭＰＥＧ２トランスポートストリームは、複数の固定長パケットで構成され、各パケットには、パケットＩＤが振られている。図９はパケットの構成図である。９００はパケットであり、固定長の１８８バイトで構成される。先頭４バイトがヘッダー９０１で、パケットの識別情報を格納しており、残り１８４バイトがペイロード９０２で、送信したい情報を含んでいる。９０３は、ヘッダー９０１の内訳である。先頭から１２ビット目〜２４ビット目までの１３ビットにパケットＩＤが含まれている。図１０は送られてくる複数のパケットの列を表現した模式図である。パケット１００１は、ヘッダーにパケットＩＤ「１」を持ち、ペイロードには映像Ａの１番目の情報が入っている。パケット１００２は、ヘッダーにパケットＩＤ「２」を持ち、ペイロードには音声Ａの１番目の情報が入っている。パケット１００３は、ヘッダーにパケットＩＤ「３」を持ち、ペイロードには音声Ｂの１番目の情報が入っている。

パケット１００４は、ヘッダーにパケットＩＤ「１」を持ち、ペイロードには映像Ａの２番目の情報が入っており、これはパケット１００１の続きになっている。同様にパケット１００５、１０２６、１０２７も他のパケットの後続データを格納している。このように、同じパケットＩＤを持つ、パケットのペイロードの内容を連結すると、連続した映像や音声を再現することができる。

図１０を参照して、ＣＰＵ５１４がパケットＩＤ「１」と出力先として「ビデオデコーダ５０８」をＴＳデコーダ５０５に指示すると、ＴＳデコーダ５０５はＰＯＤ５０４から受け取ったＭＰＥＧ２トランスポートストリームからパケットＩＤ「１」のパケットを抽出し、ビデオデコーダ５０８に引き渡す。図１０においては、映像データのみをビデオデコーダ５０８に引き渡すことになる。同時に、ＣＰＵ５１４がパケットＩＤ「２」と「オーディオデコーダ５０６」をＴＳデコーダ５０５に指示すると、ＴＳデコーダ５０５はＰＯＤ５０４から受け取ったＭＰＥＧ２トランスポートストリームからパケットＩＤ「２」のパケットを抽出し、オーディオデコーダ５０６に引き渡す。図１０においては、音声データのみをビデオデコーダ５０８に引き渡すことになる。

このパケットＩＤに応じて必要なパケットだけを取り出す処理が、ＴＳデコーダ５０５が行うフィルタリングである。ＴＳデコーダ５０５はＣＰＵ５１４から指示された複数のフィルタリングを同時に実行することができる。

図５を参照して、オーディオデコーダ５０６は、ＴＳデコーダ５０５から与えられたＭＰＥＧ２トランスポートストリームのパケットに埋め込まれたオーディオデータを連結し、デジタル−アナログ変換を行いスピーカ５０７に出力する。

スピーカ５０７は、オーディオデコーダ５０６から与えられた信号を音声出力する。
ビデオデコーダ５０８は、ＴＳデコーダ５０５から与えられたＭＰＥＧ２トランスポートストリームのパケットに埋め込まれたビデオデータを連結し、デジタル−アナログ変換を行いディスプレイ５０９に出力する。

ディスプレイ５０９は、具体的にはブラウン管や液晶等で構成され、ビデオデコーダ５０８から与えられたビデオ信号を出力したり、ＣＰＵ５１４から指示されたメッセージを表示したりする。

２次記憶部５１０は、具体的には、フラッシュメモリーやハードディスク等で構成され、ＣＰＵ５１４から指示されたデータやプログラムを保存したり削除したりする。また、保存されているデータやプログラムはＣＰＵ５１４に参照される。保存されているデータやプログラムは、端末装置５００の電源が切断された状態でも保存しつづける。

１次記憶部５１１は、具体的には、ＲＡＭ等で構成され、ＣＰＵ５１４から指示されたデータやプログラムを一次的に保存したり削除したりする。また、保存されているデータやプログラムはＣＰＵ５１４に参照される。保存されているデータやプログラムは、端末装置５００の電源が切断された際に、抹消される。

ＲＯＭ５１２は、書き換え不可能なメモリーデバイスであり、具体的にはＲＯＭやＣＤ−ＲＯＭ、ＤＶＤなどで構成される。ＲＯＭ５１２は、ＣＰＵ５１４が実行するプログラムが格納されている。

入力部５１３は、具体的には、フロントパネルやリモコンで構成され、ユーザーからの入力を受け付ける。図１１は、フロントパネルで入力部５１３を構成した場合の一例である。１１００はフロントパネルであり、図６のフロントパネル部６０３に相当する。フロントパネル１１００は７つのボタン、上カーソルボタン１１０１、下カーソルボタン１１０２、左カーソルボタン１１０３、右カーソルボタン１１０４、ＯＫボタン１１０５、取消ボタン１１０６、ＥＰＧボタン１１０７を備えている。ユーザーがボタンを押下すると、押下されたボタンの識別子が、ＣＰＵ５１４に通知される。

ＣＰＵ５１４は、ＲＯＭ５１２が記憶するプログラムを実行する。実行するプログラムの指示に従い、ＱＡＭ復調部５０１、ＱＰＳＫ復調部５０２、ＱＰＳＫ変調部５０３、ＰＯＤ５０４、ＴＳデコーダ５０５、ディスプレイ５０９、２次記憶部５１０、１次記憶部５１１、ＲＯＭ５１２を制御する。

図１２は、ＲＯＭ５１２に記憶され、ＣＰＵ５１４に実行されるプログラムの構成図の一例である。

プログラム１２００は、複数のサブプログラムで構成され、具体的にはＯＳ１２０１、ＥＰＧ１２０２、Ｊａｖａ（登録商標）ＶＭ１２０３、サービスマネージャ１２０４、Ｊａｖａライブラリ１２０５で構成される。

ＯＳ１２０１は、端末装置５００の電源が投入されると、ＣＰＵ５１４が起動するサブプログラムである。ＯＳ１２０１は、オペレーティングシステムの略であり、Ｌｉｎｕｘ等が一例である。ＯＳ１２０１は、他のサブプログラムを平行して実行するカーネル１２０１ａ及びライブラリ１２０１ｂで構成される公知の技術の総称であり、詳細な説明は省略する。本実施の形態においては、ＯＳ１２０１のカーネル１２０１ａは、ＥＰＧ１２０２とＪａｖａＶＭ１２０３をサブプログラムとして実行する。また、ライブラリ１２０１ｂは、これらサブプログラムに対して、端末装置５００が保持する構成要素を制御するための複数の機能を提供する。

機能の一例として、チューニング機能を紹介する。チューニング機能は、他のサブプログラムから周波数を含むチューニング情報を受け取り、それをＱＡＭ復調部５０１に引き渡す。ＱＡＭ復調部５０１は与えられたチューニング情報に基づき復調処理を行い、復調したデータをＰＯＤ５０４に引き渡すことができる。この結果、他のサブプログラムはライブラリ１２０１ｂを通してＱＡＭ復調器を制御することができる。

ＥＰＧ１２０２は、ユーザーに番組一覧を表示及び、ユーザーからの入力を受け付ける番組表示部１２０２ａと、チャンネル選局を行う再生部１１０２ｂで構成される。ここで、ＥＰＧはＥｌｅｃｔｒｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅの略である。ＥＰＧ１２０２は、端末装置５００の電源が投入されると、カーネル１２０１ａによって起動される、起動されたＥＰＧ１２０２の内部では、番組表示部１２０２ａが端末装置５００の入力部５１３を通して、ユーザーからの入力を待つ。ここで、入力部５１３が図１１で示されるフロントパネルで構成されている場合、ユーザーが、入力部５１３のＥＰＧボタン１１０７を押下すると、ＥＰＧボタンの識別子がＣＰＵ５１４に通知される。ＣＰＵ５１４上で動作するサブプログラムであるＥＰＧ１２０２の番組表示部１２０２ａは、この識別子を受け取り、番組情報をディスプレイ５０９に表示する。図１３Ａ及び図１３Ｂは、ディスプレイ５０９に表示された番組表の一例である。図１３Ａを参照して、ディスプレイ５０９には、格子状に番組情報が表示されている。列１３０１には、時刻情報が表示されている。列１３０２には、チャンネル名「チャンネル１」と、列１３０１の時刻に対応する時間帯に放映される番組が表示されている。「チャンネル１」では、９：００〜１０：３０に番組「ニュース９」が放映され、１０：３０〜１２：００は「映画ＡＡＡ」が放映されることを表す。列１３０３も列１３０２同様、チャンネル名「チャンネル２」と、列１３０１の時刻に対応する時間帯に放映される番組が表示されている。９：００〜１１：００に番組「映画ＢＢＢ」が放映され、１１：００〜１２：００は「ニュース１１」が放映される。１３３０は、カーソルである。カーソル１３３０は、フロントパネル１１００の左カーソル１１０３と右カーソル１１０４を押下すると移動する。図１３Ａの状態で、右カーソル１１０４を押下すると、カーソル１３３０は右に移動し、図１３Ｂのようになる。また、図１３Ｂの状態で、左カーソル１１０３を押下すると、カーソル１３３０は左に移動し、図１３Ａのようになる。

図１３Ａの状態で、フロントパネル１１００のＯＫボタン１１０５が押下されると、番組表示部１２０２ａは、「チャンネル１」の識別子を再生部１１０２ｂに通知する。図１３Ｂの状態で、フロントパネル１１００のＯＫボタン１１０５が押下されると、番組表示部１２０２ａは、「チャンネル２」の識別子を再生部１１０２ｂに通知する。

また、番組表示部１２０２ａは、表示する番組情報を、ＰＯＤ５０４を通してヘッドエンド１０１から定期的に、１次記憶部５１１に記憶しておく。一般的に、ヘッドエンドからの番組情報の取得は時間が掛かる。入力部５１３のＥＰＧボタン１１０７が押下された時、１次記憶部５１１に予め保存された番組情報を表示することで、素早く番組表を表示することができる。

再生部１１０２ｂは、受け取ったチャンネルの識別子を用いて、チャンネルを再生する。チャンネルの識別子とチャンネルの関係は、チャンネル情報として、２次記憶部５１０に予め格納されている。図１４は２次記憶部５１０に格納されているチャンネル情報の一例である。チャンネル情報は表形式で格納されている。列１４０１は、チャンネルの識別子である。列１４０２は、チャンネル名である。列１４０３はチューニング情報である。ここで、チューニング情報は周波数や転送レート、符号化率などを含み、ＱＡＭ復調部５０１に与える値である。列１４０４はプログラムナンバーである。プログラムナンバーとは、ＭＰＥＧ２規格で規定されているＰＭＴを識別するための番号である。ＰＭＴに関しては、後述する。行１４１１〜１４１４の各行は、各チャンネルの識別子、チャンネル名、チューニング情報の組となる。行１４１１は識別子が「１」、チャンネル名が「チャンネル１」、チューニング情報に周波数「３１２ＭＨｚ」、プログラムナンバーが「１０１」を含む組となっている。再生部１１０２ｂは、チャンネルの再生を行うため、受け取ったチャンネルの識別子をそのままサービスマネージャに引き渡す。

また、再生部１１０２ｂは、再生中に、ユーザーがフロントパネル１１００の上カーソル１１０１と下カーソル１１０２を押下すると、入力部５１３からＣＰＵ５１４を通して、押下された通知を受け取り、再生しているチャンネルを変更する。まず、再生部１１０２ｂは、１次記憶部５１１に現在再生中のチャンネルの識別子を記憶する。図１５Ａ、図１５Ｂ及び図１５Ｃは、１次記憶部５１１に保存しているチャンネルの識別子の例である。図１５Ａでは識別子「３」が記憶されており、図１４を参照し、チャンネル名「ＴＶ ３」のチャンネルが再生中であることを示す。図１５Ａの状態で、ユーザーが上カーソル１１０１を押下すると再生部１１０２ｂは、図１４のチャンネル情報を参照し、表中の前のチャンネルであるチャンネル名「チャンネル２」のチャンネルに再生を切り変えるため、サービスマネージャにチャンネル名「チャンネル２」の識別子「２」を引き渡す。同時に、１次記憶部５１１に記憶されているチャンネル識別子「２」に書き換える。図１５Ｂは、チャンネル識別子が書き換えられた状態を表す。また、図１５Ａの状態で、ユーザーが下カーソル１１０２を押下すると再生部１１０２ｂは、図１４のチャンネル情報を参照し、表中の次のチャンネルであるチャンネル名「ＴＶ Ｊａｐａｎ」のチャンネルに再生を切り変えるため、サービスマネージャにチャンネル名「ＴＶ Ｊａｐａｎ」の識別子「４」を引き渡す。同時に、１次記憶部５１１に記憶されているチャンネル識別子「４」に書き換える。図１５Ｃは、チャンネル識別子が書き換えられた状態を表す。

ＪａｖａＶＭ１２０３は、Ｊａｖａ（ＴＭ）言語で記述されたプログラムを逐次解析し実行するＪａｖａバーチャルマシンである。Ｊａｖａ言語で記述されたプログラムはバイトコードと呼ばれる、ハードウエアに依存しない中間コードにコンパイルされる。Ｊａｖａバーチャルマシンは、このバイトコードを実行するインタープリタである。また、一部のＪａｖａバーチャルマシンは、バイトコードをＣＰＵ５１４が理解可能な実行形式に翻訳してから、ＣＰＵ５１４に引渡し、実行することも行う。ＪａｖａＶＭ１２０３は、カーネル１２０１ａに実行するＪａｖａプログラムを指定され起動される。本実施の形態では、カーネル１２０１ａは、実行するＪａｖａプログラムとしてサービスマネージャ１２０４を指定する。Ｊａｖａ言語の詳細は、書籍「Ｊａｖａ Ｌａｎｇｕａｇｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ ０−２０１−６３４５１−１）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。また、ＪａｖａＶＭ自体の詳細な動作などは、「Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ ０−２０１−６３４５１―Ｘ）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。

サービスマネージャ１２０４は、Ｊａｖａ言語で書かれたＪａｖａプログラムであり、ＪａｖａＶＭ１２０３によって逐次実行される。サービスマネージャ１２０４は、ＪＮＩ（Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）を通して、Ｊａｖａ言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。ＪＮＩに関しても、書籍「Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ」等の多くの書籍で解説されている。ここでは、その詳細を省略する。

サービスマネージャ１２０４は、ＪＮＩを通して、再生部１１０２ｂよりチャンネルの識別子を受け取る。

サービスマネージャ１２０４は、最初にＪａｖａライブラリ１２０５の中にあるＴｕｎｅｒ１２０５ｃに、チャンネルの識別子を引き渡し、チューニングを依頼する。Ｔｕｎｅｒ１２０５ｃは、２次記憶部５１０が記憶するチャンネル情報を参照し、チューニング情報を獲得する。今、サービスマネージャ１２０４がチャンネルの識別子「２」をＴｕｎｅｒ１２０５ｃに引き渡すと、Ｔｕｎｅｒ１２０５ｃは、図１４の列１４１２を参照して、対応するチューニング情報「１５６ＭＨｚ，」を獲得する。Ｔｕｎｅｒ１２０５ｃは、ＯＳ１２０１のライブラリ１２０１ｂを通して、ＱＡＭ復調部５０１にチューニング情報を引き渡す。ＱＡＭ復調部５０１は与えられたチューニング情報に従ってヘッドエンド１０１から送信されてきた信号を復調し、ＰＯＤ５０４に引き渡す。

次にサービスマネージャ１２０４は、Ｊａｖａライブラリ１２０５の中にあるＣＡ１２０５ｂにデスクランブルを依頼する。ＣＡ１２０５ｄは、ＯＳ１２０１のライブラリ１２０１ｂを通して復号に必要な情報をＰＯＤ５０４に与える。ＰＯＤ５０４は、与えられた情報を元に、ＱＡＭ復調部５０１から与えられた信号を復号しＴＳデコーダ５０５に引き渡す。

次にサービスマネージャ１２０４は、Ｊａｖａライブラリ１２０５の中にあるＪＭＦ１２０５ａにチャンネルの識別子を与え、映像・音声の再生を依頼する。

まず、最初にＪＭＦ１２０５ａは、再生すべき映像と音声を特定するためのパケットＩＤをＰＡＴ、ＰＭＴから取得する。ＰＡＴやＰＭＴはＭＰＥＧ２規格で規定されている、ＭＰＥＧ２トランスポートストリーム内の番組構成を表現するテーブルであり、ＭＰＥＧ２トランスポートストリームに含まれるパケットのペイロードに埋め込まれて、音声や映像と共に送信されるものである。詳細は規格書を参照されたい。ここでは、概略のみ説明する。ＰＡＴは、Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅの略で、パケットＩＤ「０」のパケットに格納され送信されている。ＪＭＦ１２０５ａは、ＰＡＴを取得するため、ＯＳ１２０１のライブラリ１２０１ｂを通して、ＴＳデコーダ５０５にパケットＩＤ「０」とＣＰＵ５１４を指定する。ＴＳデコーダ５０５がパケットＩＤ「０」でフィルタリングを行い、ＣＰＵ５１４に引き渡すことでＪＭＦ１２０５ａは、ＰＡＴのパケットを収集する。図１６は、収集したＰＡＴの情報の一例を模式的に表した表である。列１６０１は、プログラムナンバーである。列１６０２は、パケットＩＤである。列１６０２のパケットＩＤはＰＭＴを取得するために用いられる。行１６１１〜１６１３は、チャンネルのプログラムナンバーと対応するパケットＩＤの組である。ここでは、３つのチャンネルが定義されている。行１６１１はプログラムナンバー「１０１」とパケットＩＤ「５０１」の組が定義されている。今、ＪＭＦ１２０５ａに与えられたチャンネルの識別子が「２」とすると、ＪＭＦ１２０５ａは、図１４の列１４１２を参照して、対応するプログラムナンバー「１０２」を獲得し、次に、図１６のＰＡＴの列１６１２を参照し、プログラムナンバー「１０２」に対応するパケットＩＤ「５０２」を獲得する。ＰＭＴは、Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅの略で、ＰＡＴで規定されたパケットＩＤのパケットに格納され送信されている。ＪＭＦ１２０５ａは、ＰＭＴを取得するため、ＯＳ１２０１のライブラリ１２０１ｂを通して、ＴＳデコーダ５０５にパケットＩＤとＣＰＵ５１４を指定する。ここで、指定するパケットＩＤは「５０２」とする。ＴＳデコーダ５０５がパケットＩＤ「５０２」でフィルタリングを行い、ＣＰＵ５１４に引き渡すことでＪＭＦ１２０５ａは、ＰＭＴのパケットを収集する。図１７は、収集したＰＭＴの情報の一例を模式的に表した表である。列１７０１は、ストリーム種別であり。列１７０２は、パケットＩＤである。列１７０２で指定されるパケットＩＤのパケットには、ストリーム種別で指定された情報がペイロードに格納され送信されている。列１７０３は補足情報である。行１７１１〜１７１４はエレメンタリ−ストリームと呼ばれる、パケットＩＤと送信している情報の種別の組である。行１７１１は、ストリーム種別「音声」とパケットＩＤ「５０１１」の組であり、パケットＩＤ「５０１１」のペイロードには音声が格納されていることを表す。ＪＭＦ１２０５ａは、ＰＭＴから再生する映像と音声のパケットＩＤを獲得する。図１７を参照して、ＪＭＦ１２０５ａは、行１７１１から音声のパケットＩＤ「５０１１」を、行１７１２から映像のパケットＩＤ「５０１２」を獲得する。

次に、ＪＭＦ１２０５ａは、ＯＳ１２０１のライブラリ１２０１ｂを通して、獲得した音声のパケットＩＤと出力先としてオーディオデコーダ５０６、映像のパケットＩＤと出力先としてビデオデコーダ５０８の組を、ＴＳデコーダ５０５に与える。ＴＳデコーダ５０５は与えられたパケットＩＤと出力先に基づいて、フィルタリングを行う。ここではパケットＩＤ「５０１１」のパケットをオーディオデコーダ５０６に、パケットＩＤ「５０１２」のパケットをビデオデコーダ５０８に引き渡す。オーディオデコーダ５０６は、与えられたパケットのデジタル−アナログ変換を行いスピーカ５０７を通して音声を再生する。ビデオデコーダ５０８は、与えられたパケットのデジタル−アナログ変換を行いディスプレイ５０９に映像を表示する。

最後にサービスマネージャ１２０４は、Ｊａｖａライブラリ１２０５の中にあるＡＭ１２０５ｂにチャンネルの識別子を与え、データ放送再生を依頼する。ここで、データ放送再生とは、ＭＰＥＧ２トランスポートストリームに含まれるＪａｖａプログラムを抽出し、ＪａｖａＶＭ１２０３に実行させることである。ＭＰＥＧ２トランスポートストリームにＪａｖａプログラムを埋め込む方法は、ＭＰＥＧ規格書 ＩＳＯ／ＩＥＣ１３８１８１−６に記述されたＤＳＭＣＣという方式を用いる。ここではＤＳＭＣＣの詳細な説明は省略する。ＤＳＭＣＣ方式は、ＭＰＥＧ２トランスポートストリームのパケットの中に、コンピュータで使用されているディレクトリやファイルで構成されるファイルシステムをエンコードする方法を規定している。また、実行するＪａｖａプログラムの情報はＡＩＴと呼ばれる形式で、ＭＰＥＧ２トランスポートストリームのパケットの中に埋め込まれ送信されている。ＡＩＴは、ＤＶＢ−ＭＨＰ規格（正式には、ＥＴＳＩ ＴＳ １０１ ８１２ ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）の１０章に定義されている、Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの略である。

ＡＭ１２０５ｂは、まず、ＡＩＴを獲得するため、ＪＭＦ１２０５ａ同様ＰＡＴ、ＰＭＴを取得し、ＡＩＴが格納されているパケットのパケットＩＤを獲得する。今、与えられたチャンネルの識別子が「２」で、図１６のＰＡＴ、図１７のＰＭＴが送信されていると、ＪＭＦ１２０５ａと同様の手順で、図１７のＰＭＴを獲得する。ＡＭ１２０５ｂは、ＰＭＴからストリーム種別が「データ」で補足情報として「ＡＩＴ」を持つエレメンタリ−ストリームからパケットＩＤを抽出する。図１７を参照して、行１７１３のエレメンタリ−ストリームが該当し、パケットＩＤ「５０１３」を獲得する。

ＡＭ１２０５ｂは、ＯＳ１２０１のライブラリ１２０１ｂを通してＴＳデコーダ５０５にＡＩＴのパケットＩＤと出力先ＣＰＵ５１４を与える。ＴＳデコーダ５０５は、与えられたパケットＩＤでフィルタリングを行い、ＣＰＵ５１４に引き渡す。この結果、ＡＭ１２０５ｂは、ＡＩＴのパケットを収集することができる。図１８は、収集したＡＩＴの情報の一例を模式的に表した表である。列１８０１はＪａｖａプログラムの識別子である。ＭＨＰ規格によれば、この識別子はＡｐｐｌｉｃａｔｉｏｎ ＩＤとして定義され、Ｊａｖａプログラムが端末装置５００のセキュリティマネージャ１２０５ｆによって認証されるべきものであるかが判別できることになっている。識別子の値が、０ｘ０から０ｘ３ｆｆｆの範囲であれば認証は不要で、０ｘ４０００から０ｘ７ｆｆｆであれば認証されなければならない。以降では、識別子の値として、前者をもつＪａｖａプログラムを「ｕｎｓｉｇｎｅｄプログラム」、後者をもつＪａｖａプログラムを「ｓｉｇｎｅｄプログラム」と呼ぶこととする。列１８０２はＪａｖａプログラムの制御情報である。制御情報には「ａｕｔｏｓｔａｒｔ」「ｐｒｅｓｅｎｔ」「ｋｉｌｌ」などがあり、「ａｕｔｏｓｔａｒｔ」は即時に端末装置５００がこのプログラムを自動的に実行することを意味し、「ｐｒｅｓｅｎｔ」は自動実行しないことを意味し、「ｋｉｌｌ」はプログラムを停止することを意味する。列１８０３は、ＤＳＭＣＣ方式でＪａｖａプログラムを含んでいるパケットＩＤを抽出するためのＤＳＭＣＣ識別子である。列１８０４はＪａｖａプログラムのプログラム名である。行１８１１と１８１２は、Ｊａｖａプログラムの情報の組である。行１８１１で定義されるＪａｖａプログラムは、識別子「３０１」、制御情報「ａｕｔｏｓｔａｒｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ａ／ＴｏｐＸｌｅｔ」の組である。行１８１２で定義されるＪａｖａプログラムは、識別子「３０２」、制御情報「ｐｒｅｓｅｎｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ｂ／ＧａｍｅＸｌｅｔ」の組である。ここで２つのＪａｖａプログラムは同じＤＳＭＣＣ識別子を持つが、これは１つのＤＳＭＣＣ方式でエンコードされたファイルシステム内に２つのＪａｖａプログラムが含まれていることを表す。ここでは、Ｊａｖａプログラムに対して４つの情報しか規定しないが、実際にはより多くの情報が定義される。詳細はＤＶＢ−ＭＨＰ規格を参照されたい。

ＡＭ１２０５ｂは、ＡＩＴの中から「ａｕｔｏｓｔａｒｔ」のＪａｖａプログラムを見つけ出し、対応するＤＳＭＣＣ識別子及びＪａｖａプログラム名を抽出する。図１８を参照して、ＡＭ１２０５ｂは行１８１１のＪａｖａプログラムを抽出し、ＤＳＭＣＣ識別子「１」及びＪａｖａプログラム名「ａ／ＴｏｐＸｌｅｔ」を獲得する。

次にＡＭ１２０５ｂは、ＡＩＴから取得したＤＳＭＣＣ識別子を用いて、ＪａｖａプログラムをＤＳＭＣＣ方式で格納しているパケットのパケットＩＤをＰＭＴから獲得する。具体的には、ＰＭＴの中でストリーム種別が「データ」で、補足情報のＤＳＭＣＣ識別子が合致するエレメンタリ−ストリームのパケットＩＤを取得する。

今、ＤＳＭＣＣ識別子が「１」であり、ＰＭＴが図１７とすると、行１７１４のエレメンタリ−ストリームが合致し、パケットＩＤ「５０１４」を取り出す。

ＡＭ１２０５ｂは、ＯＳ１２０１のライブラリ１２０１ｂを通してＴＳデコーダ５０５にＤＳＭＣＣ方式でデータが埋めこめられたパケットのパケットＩＤと出力先としてＣＰＵ５１４を指定する。ここでは、パケットＩＤ「５０１４」を与える。ＴＳデコーダ５０５、与えられたパケットＩＤでフィルタリングを行い、ＣＰＵ５１４に引き渡す。この結果、ＡＭ１２０５ｂは、必要なパケットを収集することができる。ＡＭ１２０５ｂは、収集したパケットから、ＤＳＭＣＣ方式に従ってファイルシステムを復元し、１次記憶部５１１に保存する。ＭＰＥＧ２トランスポート中のパケットからファイルシステム等のデータを取り出し１次記憶部５１１等の記憶手段に保存すことを以降、ダウンロードと呼ぶ。

図１９は、ダウンロードしたファイルシステムの一例である。図中、丸はディレクトリを四角はファイルを表し、１９０１はルートディレクトリ、１９０２はディレクトリ「ａ」，１９０３はディレクトリ「ｂ」，１９０４はファイル「ＴｏｐＸｌｅｔ．ｃｌａｓｓ」、１９０５はファイル「ＧａｍｅＸｌｅｔ．ｃｌａｓｓ」である。

次にＡＭ１２０５ｂは、１次記憶部５１１にダウンロードしたファイルシステム中から実行するＪａｖａプログラムをＪａｖａＶＭ１２０３に引き渡す。今、実行するＪａｖａプログラム名が「ａ／ＴｏｐＸｌｅｔ」とすると、Ｊａｖａプログラム名の最後に「．ｃｌａｓｓ」を付加したファイル「ａ／ＴｏｐＸｌｅｔ．ｃｌａｓｓ」が実行すべきファイルとなる。「／」はディレクトリやファイル名の区切りであり、図１９を参照して、ファイル１９０４が実行すべきＪａｖａプログラムである。次にＡＭ１２０５ｂは、Ｊａｖａプログラム識別子の列１８０１がｕｎｓｉｇｎｅｄプログラムを示しているので、セキュリティマネージャ１２０５ｆにＪａｖａプログラムの認証実行を要求する必要はなく、ファイル１９０４をＪａｖａＶＭ１２０３に引き渡す。

ＪａｖａＶＭ１２０３は、引き渡されたＪａｖａプログラムを実行する。
サービスマネージャ１２０４は、他のチャンネルの識別子を受け取ると、Ｊａｖａライブラリ１２０５に含まれる各ライブラリを通して再生している映像・音声及びＪａｖａプログラムの実行を、同じくＪａｖａライブラリ１２０５に含まれる各ライブラリを通して停止し、新たに受け取ったチャンネルの識別子に基づいて、映像・音声の再生及びＪａｖａプログラムの実行を行う。

Ｊａｖａライブラリ１２０５は、ＲＯＭ５１２に格納されている複数のＪａｖａライブラリの集合である。本実施の形態では、ここでは、Ｊａｖａライブラリ１２０５は、ＪＭＦ１２０５ａ，ＡＭ１２０５ｂ，Ｔｕｎｅｒ１２０５ｃ，ＣＡ１２０５ｄ、ＰＯＤ Ｌｉｂ１２０５ｅ，セキュリティマネージャ１２０５ｆ，ダウンロードモジュール１２０６等を含んでいる。

サービスマネージャ１２０４とダウンロードモジュール１２０６は、Ｊａｖａライブラリ１２０５に含まれるＰＯＤ Ｌｉｂ１２０５ｅを通してヘッドエンド１０１と双方向通信を行う。この双方向通信は、ＰＯＤ Ｌｉｂ１２０５ｅはＯＳ１２０１のライブラリ１２０１ｂ及び、ＰＯＤ５０４を介して、ＱＰＳＫ復調部５０２、ＱＰＳＫ変調部５０３を使用して実現される。

ダウンロードモジュール１２０６は、この通信を用いてヘッドエンド１０１から、コードデータを受け取ることができる。コードデータとは、Ｘ．５０９証明書と端末装置５００のファームウェアのどちらかもしくは両方を含んだバイナリデータのことである。図３７は、本発明に関する部分のみを記述したコードデータの模式図である。ダウンロードモジュール１２０６がコードデータ３７を受け取ると、もしコードデータがルート証明書３７１を含んでいるならば、それを抽出し、セキュリティマネージャ１２０５ｆへ引き渡たす。３７２はファームウェア等その他のデータを示す。

また、ＡＭ１２０５ｂは、ヘッドエンド１０１から、端末装置５００が２次記憶部５１０に保存すべきＪａｖａプログラムの情報を受け取る。この情報をＸＡＩＴ情報と呼ぶ。ＸＡＩＴ情報は、ヘッドエンド１０１とＰＯＤ５０４間で、任意の形式で送信される。どのような送信形式を採用しても、ＸＡＩＴに必要とする情報が含まれていれば、本発明は実施可能である。

図２０は、ヘッドエンド１０１から取得したＸＡＩＴの情報の一例を模式的に表した表である。列２００１はＪａｖａプログラムの識別子である。列２００２はＪａｖａプログラムの制御情報である。制御情報には「ａｕｔｏｓｔａｒｔ」「ｐｒｅｓｅｎｔ」などがあり、「ａｕｔｏｓｔａｒｔ」は端末装置５００が電源投入時にこのプログラムを自動的に実行することを意味し、「ｐｒｅｓｅｎｔ」は自動実行しないことを意味する。列２００３は、ＤＳＭＣＣ方式でＪａｖａプログラムを含んでいるパケットＩＤを抽出するためのＤＳＭＣＣ識別子である。列２００４はＪａｖａプログラムのプログラム名である。列２００５は、Ｊａｖａプログラムの優先度である。行２０１１と２０１２は、Ｊａｖａプログラムの情報の組である。行２０１１で定義されるＪａｖａプログラムは、識別子「０ｘ７００１」、制御情報「ａｕｔｏｓｔａｒｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ａ／ＰＰＶ１Ｘｌｅｔ」の組である。Ｊａｖａプログラムの識別子Ａｐｐｌｉｃａｔｉｏｎ ＩＤから、Ｊａｖａプログラムはｓｉｇｎｅｄプログラムであることが分かる。ここでは、Ｊａｖａプログラムに対して５つの情報しか規定しないが、より多くの情報が定義されていても本発明は実施可能である。

ＡＭ１２０５ｂは、ＸＡＩＴ情報を受け取ると、ＡＩＴ情報からＪａｖａプログラムをダウンロードした手順と同じ手順で、ＭＰＥＧ２トランスポートストリームからファイルシステムを１次記憶部５１１上に展開する。その後、ファイルシステムを２次記憶部５１０に保存する直前に、セキュリティマネージャ１２０５ｆへ保存直前通知を行う。このとき、本発明に関するセキュリティマネージャ１２０５ｆの認証が動作するが、詳細は後に述べる。ＡＭ１２０５ｂは、セキュリティマネージャ１２０５ｆより起動許可を通知されると、ファイルシステムを２次記憶部５１０に保存する。次に、ＡＭ１２０５ｂは、ＸＡＩＴ情報にダウンロードしたファイルシステムの格納位置を対応つけて２次記憶部５１０に保存する。図２１は、２次記憶部５１０がＸＡＩＴ情報とダウンロードしたファイルシステムが対応つけられて保存されている一例を表す。ここではＯＣＡＰ規格で定義されているファイルを取り上げて説明する。図２１の中で、図２０と同じ番号の要素は図２０と同じなので、説明は省略する。列２１０１は対応するダウンロードしたファイルシステムの保存位置を格納する。図中、保存位置は矢印で示している。２１１０はダウンロードしたファイルシステムであり、内部にトップディレクトリ２１１１、ディレクトリ「ａ」２１１２、ディレクトリ「ｂ」２１１３、ファイル「ＰＰＶ１Ｘｌｅｔ．ｃｌａｓｓ」２１１４、ファイル「ＰＰＶ２Ｘｌｅｔ．ｃｌａｓｓ」２１１５、ファイル「ｏｃａｐ．ｈａｓｈｆｉｌｅ」２１１６〜２１１８、ファイル「ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１」２１１９、ファイル「ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１」２１２０を保持する。

ファイル２１１６〜２１１８はハッシュファイルで、ファイル名またはディレクトリ名とそれらに対応するハッシュ値を格納している。図２２Ａの２２１は“ｏｃａｐ．ｈａｓｈｆｉｌｅ”２１１６、図２２Ｂの２２２は“ｏｃａｐ．ｈａｓｈｆｉｌｅ”２１１７、図２２Ｃの２２３は“ｏｃａｐ．ｈａｓｈｆｉｌｅ”２１１８の内容をそれぞれ表した模式図である。２２１の“ｏｃａｐ．ｈａｓｈｆｉｌｅ”は、“／”ディレクトリ２１１１に存在し、同じディレクトリ２１１１に存在する“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル２１１９、“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１”ファイル２１２０、“ａ”ディレクトリ２１１２、“ｂ”ディレクトリ２１１３を２２１１列に格納する。２２１２列は、２２１３列にそれぞれ記述されている値が何のハッシュアルゴリズムによって計算された値であるのかを示す。２２１３列は、２２１１列のファイルまたはディレクトリに関し、２２１２列で指定されたアルゴリズムを使って計算されたハッシュ値を格納する。ハッシュアルゴリズムには、ＳＨＡ１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ １）とＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５）というアルゴリズムが現在主に利用されている。これらは、任意の長さのデータを固定長のバイト値に変換する公知技術のアルゴリズムで、次の特徴をもつ。変換後のデータから元データを推測することができず、ファイルが破損もしくは改竄されていないかを確認するために使用される。一方、ハッシュ値とは、ハッシュアルゴリズムで生成された擬似乱数のことである。ハッシュアルゴリズムがＳＨＡ１の時、ハッシュ値の長さは２０バイトで、ＭＤ５の時は、ハッシュ値の長さは１６バイトに換算される。ＳＨＡ１、ＭＤ５の詳細については、それぞれ“ＦＩＰＳ−ＰＵＢ １８６−２ Ｓｅｃｕｒｅ Ｈａｓｈ Ｓｔａｎｄａｒｄ”、“ＩＥＴＦ ＲＦＣ１３２１”を参照されたい。ここで、２２１１列に記述されたディレクトリ“ａ”“ｂ”に対応するハッシュ値はそれぞれ、“ａ”ディレクトリに存在する“ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイル２１１７、“ｂ”ディレクトリに存在する“ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイル２１１８に対して計算されたＳＨＡ１ハッシュ値である。

２２１の“ｏｃａｐ．ｈａｓｈｆｉｌｅ”と同様、２２２の“ｏｃａｐ．ｈａｓｈｆｉｌｅ”は、同じディレクトリ２１１２に存在する“ＰＰＶ１Ｘｌｅｔ．ｃｌａｓｓ”ファイル２１１４のファイル名、ハッシュアルゴリズム、ハッシュ値を格納する。２２３についても同様に、同じディレクトリ２１１３に存在する“ＰＰＶ２Ｘｌｅｔ．ｃｌａｓｓ”ファイル２１１５のファイル名、ハッシュアルゴリズム、ハッシュ値を格納する。

ここでは、本発明に関係する属性のみを取り上げたが、“ｏｃａｐ．ｈａｓｈｆｉｌｅ”の詳細な構成については、ＯＣＡＰ規格書である“ＯｐｅｎＣａｂｌｅ（ＴＭ） Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＯＣＡＰ １．０ Ｐｒｏｆｉｌｅ（ＯＣ−ＳＰ−ＯＣＡＰ１．０−ＩＦ−Ｉ０９−０３１１２１）”を参照されたい。

ファイル２１１９は証明書チェーンである。図２３は、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル２１１９の構成内容を示した構成図である。“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．ｘ”（ｘは正の整数）の一般的な構成を表現している２３１は、ルート証明書２３１１、中間証明書２３１２、リーフ証明書２３１３を内包する。これらは、ルート証明書２３１１の所有者が中間証明書２３１２を発行し、中間証明書２３１２の所有者がリーフ証明書２３１３を発行するといった、連鎖関係にある。なおＯＣＡＰ規格では、署名ファイル“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．ｘ”と関係する証明書チェーンは、同じ値“ｘ”をもつ“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．ｘ”である。図２１の場合、“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１”に対応する証明書チェーンは、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”となる。そして、ルート証明書２３１１、中間証明書２３１２、リーフ証明書２３１３は、共通のＸ．５０９証明書のフォーマットで構成される。Ｘ．５０９証明書は、ＩＴＵ−Ｔのレコメンデーションで、証明書の表現形式のデファクト標準として情報通信の各分野で広く普及している。図２３では３つの証明書のみを図示しているが、中間証明書が複数存在することもある。但し、中間証明書間で相互に関連した連鎖状態になければならない。

図２４はＸ．５０９証明書の構成図である。ここでは、本発明の説明の上で必要な属性のみを列挙している。Ｘ．５０９証明書の詳細については、ＩＥＴＦ ＲＦＣ３２８０“Ｉｎｔｅｒｎｅｔ Ｘ．５０９ Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｃｅｒｔｉｆｉｃａｔｅ ａｎｄ ＣＲＬ Ｐｒｏｆｉｌｅ”を参照されたい。２４１はＸ．５０９証明書の属性領域、２４２はＸ．５０９証明書の署名値を示す。シリアル番号２４１１は証明書を識別するための番号、署名アルゴリズム２４１２は署名値２４２を計算するために使用されたアルゴリズム、今回更新日時２４１３は本Ｘ．５０９証明書の有効開始日時、次回更新時間２４１４は本Ｘ．５０９証明書の有効満了日時、発行者名２４１５は本Ｘ．５０９証明書を発行する機関名、主体者名２４１６は本Ｘ．５０９証明書の所有者、公開鍵２４１７は主体者名２４１６の公開鍵、署名値２４２は本Ｘ．５０９証明書発行者の秘密鍵によって署名（暗号化）された値を表す。公開鍵と秘密鍵を使ったものとして、公開鍵暗号方式が電子商取引等で幅広く利用されている。公開鍵暗号方式では、平文を暗号化するときに使用した鍵と異なる鍵を使用して暗号文を復号する。暗号用の鍵と復号用の鍵が異なり、復号用の鍵を一般公開しても復号用の鍵から暗号用の鍵を推測することは不可能である。この暗号用の鍵が秘密鍵、復号用の鍵が公開鍵に該当する。公開鍵暗号方式の代表例としては、ＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）、ＤＳＡ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ｓｔａｎｄａｒｄ）が挙げられる。

ファイル２１２０は署名ファイルである。図２５は、“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１”ファイル２１２０の模式図である。２５１はどのＸ．５０９証明書と関係するのかを示す証明書識別子、２５２はハッシュ署名アルゴリズム、２５３は２５２で示されるハッシュ署名アルゴリズムを用いて、“ｏｃａｐ．ｈａｓｈｆｉｌｅ”２１１６から計算された署名値を表す。

Ｊａｖａプログラムが２次記憶部５１０に保存されると、チャンネル変更、端末装置５００の電源ＯＦＦ等により１次記憶部５０９からそれが消去されたとしても、ＡＭ１２０５ｂが図２０で示すＸＡＩＴを受信すれば、ダウンロードを待たずにＪａｖａプログラムが起動される。すなわち、図２０では、プログラム“／ａ／ＰＰＶ１Ｘｌｅｔ”が制御情報２００２として「ａｕｔｏｓｔａｒｔ」になっている。そこで、図２１の２０１１において、“／ａ／ＰＰＶ１Ｘｌｅｔ”に対応するファイルシステムの保存位置２１０１を探し、ファイル２１１４をＪａｖａＶＭ１２０３に引き渡すと、ファイルシステムに保有されているＪａｖａプログラム“ＰＰＶ１Ｘｌｅｔ”が起動される。

次に、本発明の主要機能であるセキュリティマネージャ１２０５ｆについて説明する。
セキュリティマネージャ１２０５ｆは、ＡＭ１２０５ｂから図２０の２００４で示される“／ａ／ＰＰＶ１Ｘｌｅｔ”と“／ｂ／ＰＰＶＸｌｅｔ２”が保存されようとしていることを表す保存直前通知を通知される。その通知を受け取ると、Ｊａｖａプログラム識別子２００１の値を調べ、ｕｎｓｉｇｎｅｄプログラムであるのか、ｓｉｇｎｅｄプログラムであるのかを判断する。ここで、Ｊａｖａプログラムはｓｉｇｎｅｄプログラムであるので、“／”ディレクトリ以下のファイルシステムについて、認証を実行する。認証では、図２１のｏｃａｐ．ｈａｓｈｆｉｌｅ（２１１６〜２１１８）、ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１（２１１９）、ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１（２１２０）を使用して検証する。

図２６は、ファイルシステムの認証を実行する際のセキュリティマネージャ１２０５ｆの構成要素を示す。

通知受取手段２６１は、ＡＭ１２０５ｂがファイルシステムを保存しようとする直前に保存直前通知を受け取るための手段であり、それを判定手段２６２へ伝える。

判定手段２６２は、認証結果を決定する。ハッシュ計算手段２６３へファイルシステムのハッシュ計算を要求し、ハッシュ値を受け取る。判定手段２６２は“ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイルに存在するハッシュ値２２１３、２２２３、２２３３から比較すべき値を取り出して、一致するかを確認する。一致しなければ、改竄があったものと判断し、認証は失敗となる。

また、判定手段２６２は、証明書抽出手段２６５を用いて各Ｘ．５０９証明書を取り出し、現在時刻がＸ．５０９証明書の今回更新日時２４１３と次回更新日時２４１４の間にあるかを判断する。なお、現在日時は、ＯＳ１２０１のライブラリ１２０１ｂから取得する。もし、“今回更新日時＜現在日時＜次回更新日時”という期間有効性がなければ、認証は失敗と判断する。

さらに、判定手段２６２は、証明書チェーンの認証を行うために、Ｘ．５０９証明書の属性領域２４１のハッシュ計算をハッシュ計算手段２６３に要求する。そして、署名値復号手段２６４へＸ．５０９証明書に含まれる署名値２４２の復号計算を要求して、得られた復号値とハッシュ計算手段２６３で得られたハッシュ値を比較し、証明書連鎖の状況を確認する。もし不一致であれば、連鎖しておらず、認証は失敗と判断される。一方、一致して連鎖が確認できれば、証明書チェーンのルート証明書が、端末装置５００の２次記憶部５１０に含まれているかを確認する。もし含まれていなければ、照合不可能として、認証は失敗と判断する。

判定手段２６２が認証の成功と判断するのは、（１）改竄なし、（２）期間有効性あり、（３）証明書連鎖あり、（４）ルート証明書が一致、をすべて満たすときである。

ハッシュ計算手段２６３は、判定手段２６２より各ファイルのハッシュ値計算を要求され、ＯＳ１２０１のライブラリ１２０１ｂから各ファイルを取り出して、そのハッシュ計算を行い、結果を判定手段２６２へ渡す。また、証明書チェーン２３１内の各Ｘ．５０９証明書を証明書抽出手段２６５から取得し、属性領域２４１に対してハッシュ計算を行う。

署名値復号手段２６４は、判定手段２６２からＸ．５０９証明書もしくは“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．ｘ”の署名値を復号計算するように要求される。Ｘ．５０９証明書の署名を復号計算する際には、証明書抽出手段２６５から証明書チェーン２３１の各Ｘ．５０９証明書を取得した上で、署名の復号計算を実施し、結果を判定手段２６２へ返す。

証明書抽出手段２６５は、判定手段２６２、ハッシュ計算手段２６３、署名値復号手段２６４から、証明書チェーン２３１の中にある各Ｘ．５０９証明書を抽出するように要求を受けて、Ｘ．５０９証明書を抽出して返す。

図２７は、ファイルシステムの認証を実行する際のセキュリティマネージャ１２０５ｆの動作をまとめたフローチャートである。以下、ファイルシステムの構成が図２１である場合の動作をフローチャートに則して説明する。ＡＭ１２０５ｂからファイルシステムの保存直前通知を受け付けると（ステップＳ２７１）、ファイルシステムの最上位ディレクトリ“／”以下のファイルシステムについて改竄チェックを行う（ステップＳ２７２）。改竄チェックでは、ファイルシステムの各ディレクトリに存在するファイルに対して、破損及び変更がなされていないかをハッシュ値比較で確認する。

図２９と図３０は、ステップＳ２７２の詳細なフローチャートを示す。まず、ステップＳ２９１に示すとおり、“／”ディレクトリに存在するファイル“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”、“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１”と、ディレクトリ“ａ”、“ｂ”のハッシュ値をそれぞれ計算する。なお、ディレクトリ“ａ”、“ｂ”のハッシュ値はそれぞれ、“／ａ／ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイル２２２、“／ｂ／ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイル２２３から計算される。ステップＳ２９３で、ステップＳ２９２で計算したハッシュ値と、“／ｏｃａｐ．ｈａｓｈｆｉｌｅ”中の２２１３のハッシュ値とをそれぞれ比較する。ステップＳ２９４において、一つでも計算したハッシュ値と２２１３のハッシュ値とが異なれば、改竄があったと判断する（ステップＳ２９７）。一方、計算したハッシュ値と２２１３のハッシュ値がすべて一致した場合、ステップ２９５へ移る。ステップ２９５では、改竄チェックが完了していないサブディレクトリがないかを確認する。現時点では、“ａ”と“ｂ”のディレクトリが“／”のサブディレクトリとして存在し、それらはまだ改竄チェックが完了していないので、“ａ”と“ｂ”ディレクトリに対して改竄チェックを行う必要がある。ステップＳ２９６として、まず“ａ”ディレクトリに注目することとし、“／”ディレクトリと同様の処理を行う。“ａ”ディレクトリでの改竄チェック完了後、“ｂ”ディレクトリでの改竄チェックを実施する。“ａ”と“ｂ”のディレクトリに対する改竄チェックが完了すると、“／”ディレクトリに注目して、図３０のステップＳ３０１の処理を行う。ステップＳ３０１では、証明書チェーン２３１である“／ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル２１１９からリーフ証明書２３１３を抽出する。そして、抽出したリーフ証明書２３１３から公開鍵２４１７をステップＳ３０２で取り出す。その後、ステップＳ３０３では、“／ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイル２２１のハッシュ値を計算する。一方、ステップＳ３０４で、“／ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅｆｉｌｅ．１”ファイル２１１９のリーフ証明書２３１３に存在する公開鍵２４１７を用いて、“／ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１”ファイル２１２０の署名値２４２に対して復号を行う。ステップＳ３０５では、ステップＳ３０３で計算したハッシュ値と、ステップＳ３０４で得た署名値を復号した値が等しいかを確かめる。もし、計算値が一致すれば、“／”ディレクトリ以下のファイルシステムは改竄されていないと判断できる（ステップＳ３０６）。一方、計算値が一致しなければ、ファイルシステムは改竄されていると判断できる（ステップＳ３０７）。なお、改竄チェックは、最上位である“／”ディレクトリからサブディレクトリに向かって降順に処理する例を挙げたが、本発明はこれに限定するものではない。最下位ディレクトリから最上位ディレクトリへ向かって昇順に処理することにしても構わない。以上により、図２７中のステップＳ２７２の結果が得られる。

ステップＳ２７３では、もしステップＳ２７２での結果が「改竄あり」であった場合、認証は失敗と判断して通知（ステップＳ２７９）後に終了する。ステップＳ２７２での結果が「改竄なし」の場合には、ステップＳ２７４を処理する。

次に、図３１〜図３３を用いて、証明書チェーンの認証（ステップＳ２７４）を詳細に説明する。まず、中間証明書２３１２とリーフ証明書２３１３間でのチェックを行うこととし、図３１にそのフローチャートを図示する。最初に、証明書チェーン２３１から中間証明書２３１２とリーフ証明書２３１３を抽出する（ステップＳ３１１）。抽出したリーフ証明書２３１３から今回更新日時２４１３、次回更新日時２４１４、発行者名２４１５を抽出する（ステップＳ３１２）。このうち、現在の日時が今回更新日時２４１３から次回更新日時２４１４までの証明書が有効な期間であるかを判断する（ステップＳ３１３）。もし、証明書が有効な期間外であれば、証明書チェーンの認証は失敗（ステップＳ３１９）となる。一方、証明書が有効な期間であると判断すると、中間証明書２３１２の主体者名２４１６と公開鍵２４１７を抽出し（ステップＳ３１４）、中間証明書２３１２の主体者名２４１６とリーフ証明書２３１３の発行者名２４１５を比較して、中間証明書２３１２とリーフ証明書２３１３が連鎖関係にあるかを判別する（ステップＳ３１５）。もし、証明書間で連鎖関係になければ、証明書チェーンの認証は失敗となる。他方、連鎖関係が成り立てば、リーフ証明書２３１３の属性領域２４１のハッシュ値を計算する（ステップＳ３１６）。また、中間証明書２３１２の公開鍵２４１７を利用して、リーフ証明書２３１３の署名値２４２を復号する（ステップＳ３１７）。ステップＳ３１６とステップＳ３１７が完了すると、それぞれから得られるハッシュ値と署名復号値が一致するかどうかを判断する（ステップＳ３１８）。もし、一致しなければ証明書チェーンの認証は失敗となる（ステップＳ３１９）。

次に、ルート証明書２３１１と中間証明書２３１２間でのチェックを行う。図３２にそのフローチャートを図示する。証明書チェーン２３１からルート証明書２３１１と中間証明書２３１２を抽出し（ステップＳ３２１）、中間証明書２３１２とリーフ証明書２３１３間のチェックと同様の処理を、ルート証明書２３１１と中間証明書２３１２に対して行う（ステップＳ３２２〜ステップＳ３２８）。

そして、ステップＳ３２８で一致すると判断された場合、ルート証明書２３１１単独のチェックを行う。図３３は、ルート証明書２３１１単独チェックのフローチャートである。ステップＳ３２１で抽出したルート証明書２３１１から、今回更新日時２４１３、次回更新日時２４１４、発行者名２４１５を抽出する（ステップＳ３３１）。このうち、現在の日時が今回更新日時２４１３から次回更新日時２４１４までの証明書が有効な期間であるかを判断する（ステップＳ３３２）。もし、証明書が有効な期間外であれば、証明書チェーンの認証は失敗となる。一方、証明書が有効な期間であると判断すると、ルート証明書２３１１の属性領域２４１のハッシュ値を計算する（ステップＳ３３４）。また、ルート証明書２３１１の公開鍵２４１７を利用して、ルート証明書２３１１の署名値２４２を復号する（ステップＳ３３５）。ステップＳ３３４とステップＳ３３５が完了すると、それぞれから得られるハッシュ値と署名復号値が一致するかどうかを判断する（ステップＳ３３６）。もし一致すれば、証明書チェーンの認証は成功（ステップＳ３３７）であり、一致しなければ証明書チェーンの認証は失敗（ステップＳ３３８）となる。ここで、ステップＳ２７４の処理が終了する。

ステップＳ２７５では、Ｓ２７４の結果に応じて、処理が異なる。ステップ４の結果が「証明書チェーンの認証失敗」の場合、認証失敗と判断して通知し（ステップＳ２７９）、ファイルシステムとしての認証は終了する。一方、「証明書チェーンの認証成功」の場合、ステップＳ２７６を処理する。

次に、“／ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル２１１９のルート証明書２３１１と同じ証明書を端末装置５００の２次記憶部５１０から探す（ステップＳ２７６）。ステップＳ２７７において、２次記憶部５１０に存在しない場合には、証明書チェーン２３１の認証は失敗と判断し、認証失敗を通知（ステップＳ２７９）後、終了する。一方、そのルート証明書２３１１が含まれている場合には、ファイルシステムの認証は成功と判断し、ＡＭ１２０５ｂへ認証成功を通知する（ステップＳ２７８）。その後、図２８を参照して、Ｊａｖａプログラムの起動直前通知を受けても（ステップＳ２８１）、何もせずに終了する。

この実施の形態１では、保存したＪａｖａプログラムが一定時間経過後に起動されるとき、ファイルシステムの認証は保存直前に実行済みなので、この時点で認証する必要はない。

また、ファイルシステムに図３４で示す“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”が存在し、それに記述されたファイルのみが保存対象である場合について説明する。例えばＯＣＡＰ規格では、“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”はＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記述される。この一例である図３４に“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”の例を示す。図３４では、図２１の“ＰＰＶ２Ｘｅｔ．ｃｌａｓｓ”２１１５が記述されていない。従って、この場合には“ＰＰＶ２Ｘｅｔ．ｃｌａｓｓ”２１１５は保存対象外ということになる。この時、Ｓ２９２で“ＰＰＶ２Ｘｅｔ．ｃｌａｓｓ”２１１５に対してはハッシュ値を計算せず、Ｓ２９３で“ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイル２１１８に記述された２２３３のハッシュ値と比較しない。Ｓ２９４では、保存対象外のファイルは適用除外ということで、Ｓ２９５の処理へ進むことにしてもよい。

（実施の形態２）
ファイルシステムを保存してから一定時間経過後にファイルシステムに含まれるＪａｖａプログラム(ＰＰＶ１Ｘｌｅｔ．ｃｌａｓｓ２１１４もしくはＰＰＶ２Ｘｌｅｔ．ｃｌａｓｓ２１１５)が起動されるとき、“／ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル２１１９に含まれるＸ．５０９証明書のどれかが期限切れ（つまり、Ｊａｖａプログラム起動日時＞次回更新日時２４１４）になっている可能性がある。実施の形態１のままでは、すでに期限切れになってしまったＸ．５０９証明書が証明書チェーン２３１に含まれていても、Ｊａｖａプログラムの起動を許してしまう。

従って本実施の形態では、実施の形態１に、Ｊａｖａプログラムの起動時には証明書チェーン２３１の各証明書２３１１、２３１２、２３１３が有効期限切れになっていないかを確認する機能を追加する。本実施の形態における構成要素を図２６に示す。本実施の形態で必要な構成要素２６１〜２６５の説明は、実施の形態１で行ったのでここでは省略する。

フローチャートにおいては、図２７のフローチャートを図３５のフローチャートに置き換え、図３６のフローチャートを追加する。

図３５を参照して、ファイルシステムの保存直前時の処理（ステップＳ３５１〜ステップＳ３５７）は、実施の形態１で説明した処理（ステップＳ２７１〜ステップＳ２７７）と同じであるので、説明は省略する。認証失敗でなければ、処理は図３６のフローチャートに続く。一定時間経過後に、ＪａｖａプログラムであるＰＰＶ１Ｘｌｅｔ．ｃｌａｓｓ２１１４の起動通知を受けるとき（ステップＳ３６１）、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル２１１９からルート証明書２３１１、中間証明書２３１２、リーフ証明書２３１３の各Ｘ．５０９証明書を抽出する（ステップＳ３６２）。抽出したＸ．５０９証明書をリーフ証明書からルート証明書の順に一つずつ選択して（ステップＳ３６３）、現在日時が選択したＸ．５０９証明書の今回更新日時２４１３と次回更新日時２４１４の間であるかを確認する（ステップＳ３６４）。もし、現在日時が今回更新日時２４１３と次回更新日時２４１４の間でなければ、認証失敗と判断し、それを通知する（ステップＳ３６７）。他方であれば、すべてのＸ．５０９証明書について確認が完了しているかを調べる（ステップＳ３６５）。もし、まだすべてのＸ．５０９証明書を確認完了していない場合、ステップＳ３６３に戻って処理を繰り返す。一方ステップＳ３６５で、すべてのＸ．５０９証明書を確認済みであれば、認証成功と判断し、認証成功を通知してから（ステップＳ３６６）、処理を終了する。図３６のフローチャートに示した処理を追加することによって、証明書の期限切れが発生しているＪａｖａプログラムを起動しないようにＡＭ１２０５ｂに認証失敗を通知可能となる。ＡＭ１２０５ｂは、セキュリティマネージャ１２０５ｆから認証失敗を通知されると、ＪａｖａプログラムをＪａｖａＶＭ１２０３へ渡さず、起動を中止する。

（実施の形態３）
実施の形態１で記述したように、２次記憶部５１０にはルート証明書であるＸ．５０９証明書が含まれており、それは証明書チェーン２３１のルート証明書２３１１と比較される。２次記憶部５１０に格納されたルート証明書は、ハック等によって証明書の信用性が低下する場合に備えて、新しいＸ．５０９証明書と交換される（以降では、証明書交換と呼ぶ）。新しいＸ．５０９証明書は、ヘッドエンド１０１から端末装置５００へ送られ、ダウンロードモジュール１０６が仲介してセキュリティマネージャ１２０５ｆへと運ばれる。

図３８Ａ〜図３８Ｃは、セキュリティマネージャ１２０５ｆによって、２次記憶部５１０にあるルート証明書の交換（証明書交換）が行われる様子を示した図である。この場合、証明書Ａ３８１が交換される古い証明書で、証明書Ｂ３８２が新しい証明書である。図３８Ａの３８−１は証明書交換前の２次記憶部５１０にある証明書の状態、図３８Ｂの３８−２は証明書交換中の状態、図３８Ｃの３８−３は証明書交換後の２次記憶部５１０にある証明書の状態である。

実施の形態１及び実施の形態２では、Ｊａｖａプログラムの保存後に証明書交換が行われたとしても、Ｊａｖａプログラムの起動時には、交換後の証明書が考慮されない。例えば、セキュリティマネージャ１２０５ｆがＪａｖａプログラムの保存直前通知を受けて認証した時に、証明書チェーン２３１のルート証明書２３１１が証明書Ａ３８１と一致していたとする。そして、証明書Ａ３８１と証明書Ｂ３８２の証明書交換を経て、Ｊａｖａプログラムの起動直前通知を受け取ったとする。この時点で、信用性のある証明書を格納している２次記憶部５１０には、証明書チェーン２３１のルート証明書２３１１と一致する証明書は存在しないため、その証明書は信用性のないものとなっている。しかし、実施の形態１及び実施の形態２では、Ｊａｖａプログラムの起動直前にルート証明書の照合を行わない（つまり、証明書チェーン２３１のルート証明書２３１１と証明書Ｂ３８２とを比較しない）ので、ＡＭ１２０５ｂに認証失敗を通知しない。その結果、ＡＭ１２０５ｂがＪａｖａプログラムを起動させてしまう。

従って本実施の形態では、Ｊａｖａプログラムの起動時に証明書交換を考慮して、ルート証明書の照合を行う機能を追加する。

本実施の形態における構成要素を図２６に示す。構成要素２６１〜２６５については前記したのでここでの説明は省略するが、証明書交換手段２６６、交換証明書特定手段２６７、証明書受信手段２６８を追加する。

証明書交換手段２６６は、受け取った証明書より古い証明書が２次記憶部５１０に保存されていることを交換証明書特定手段２６７によって判断された場合には、古い証明書と新しい証明書を入れ替える。一方、交換証明書特定手段２６７が古い証明書を保存していないと判断した場合には、２次記憶部５１０に新しい証明書を保存する。

交換証明書特定手段２６７は、証明書受信手段２６８で受信された証明書を受け取る。すると、ＯＳ１２０１のライブラリ１２０１ｂを利用して、２次記憶部５１０に格納している証明書を調べ、発行者が同じで、受け取った証明書より古い証明書を保存しているか確認する。

証明書受信手段２６８は、ダウンロードモジュール１２０６が新しい証明書をヘッドエンド１０１から受信したときに、その新しい証明書を受け取る。証明書を受け取ると、証明書交換手段２６６と交換証明書特定手段２６７に渡す。

また、図３５のフローチャートに引き続いて、図３９と図４０を追加する。
図３９は、証明書交換が行われる際のフローチャートであり、図４０は、証明書交換後のＪａｖａプログラムが起動される際のフローチャートである。図３９を参照して、証明書交換要求を受け付けると（ステップＳ３９１）、受け取った証明書の発行者名を取り出す（ステップＳ３９２）。端末装置５００の２次記憶部５１０に交換されるべき古い証明書が存在するかを確認し（ステップＳ３９３）、もし、存在する場合のみ、その古い証明書を削除する。そして、受け取った証明書を２次記憶部５１０に保存する（ステップＳ３９５）。一定時間経過後、Ｊａｖａプログラムの起動通知を受け取ると（ステップＳ４０１）、２次記憶部５１０から証明書チェーン２３１のルート証明書２３１１と一致する証明書を探し（ステップＳ４０２）、存在すれば（ステップＳ４０３）、認証成功と判断して通知する（ステップＳ４０４）。存在しなければ（ステップＳ４０３）、認証失敗と判断して通知する（ステップＳ４０５）。なお、Ｓ４０４で認証成功と判断する前に、証明書チェーン中の各Ｘ．５０９証明書に対して、“今回更新日時＜現在の日時＜次回更新日時”であるかを確認した上で、認証成功を結論付けることにしてもよい。

また、ルート証明書の一致を確認することに加えて、図３１〜図３３に示した証明書チェーンの証明書連鎖の確認をＳ４０２の前に行った上で、認証の成功・失敗を判断してもよい。

また、発行者名をもとに交換すべき証明書を特定する記述を行っているが、主体者名などの別の属性値で証明書の特定を行ってもよい。

（実施の形態４）
ファイルシステムを保存してから一定時間経過後にファイルシステムに含まれるＪａｖａプログラム(ＰＰＶ１Ｘｌｅｔ．ｃｌａｓｓ２１１４もしくはＰＰＶ２Ｘｌｅｔ．ｃｌａｓｓ２１１５)が起動されるとき、“／ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル２１１９に含まれるＸ．５０９証明書のどれかが、証明書の満了期間を経過した、または、ルート証明書が交換されたこと以外でも無効化されることがある。このままでは、証明書が無効化されているにもかかわらず、Ｊａｖａプログラムが起動されることを許してしまう。

ここで、証明書を無効化するものとして、ＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）が広く知られている。図４１は、ＣＲＬの構成図である。ここでは、本発明の説明の上で必要な属性のみを列挙している。ＣＲＬのより詳細については、ＩＥＴＦ ＲＦＣ３２８０“Ｉｎｔｅｒｎｅｔ Ｘ．５０９ Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｃｅｒｔｉｆｉｃａｔｅ ａｎｄ ＣＲＬ Ｐｒｏｆｉｌｅ”を参照されたい。４１１はＣＲＬの属性領域、４１２は署名値４１３の署名アルゴリズム、４１３はＣＲＬの署名値を示す。発行者名４１１１は本ＣＲＬの発行者、今回更新日時４１１２は本ＣＲＬの有効開始日時、次回更新時間４１１３は本ＣＲＬの有効満了日時、失効証明書リスト４１１４は失効したＸ．５０９証明書の情報を示す。図４２は、失効証明書リスト４１１４の構成図である。ここでも、本発明の説明の上で必要な属性のみを列挙している。失効証明書リスト４１１４は、複数の失効したＸ．５０９証明書の情報を格納する。図４２の場合、失効した“証明書Ａ”４２１には、証明書を一意に特定するシリアル番号４２１１、“証明書Ａ”４２１の失効した日時４２１２が格納されている。他の失効証明書についても、４２１と同様である。

図４３は、ＣＲＬを含むファイルシステム構成の一例である。内部に“／”ディレクトリ４３１、“ａ”ディレクトリ４３２、“ＳｉｍｐｌｅＸｌｅｔ．ｃｌａｓｓ”ファイル４３３、４３４〜４３５は“ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイル、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル４３６、“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１”ファイル４３７、“ｏｃａｐ．ｃｒｌ．２”ファイル４３８、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．２”ファイル４３９を保持する。ＣＲＬを含まないファイルシステムの認証については、実施の形態１で説明したとおりである。よって、本実施の形態では、ＣＲＬのフォーマットで構成される“ｏｃａｐ．ｃｒｌ．２”ファイル４３８と、そのファイルの証明書チェーンである“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．２”ファイル４３９に着目する。なおＯＣＡＰ規格では、“ｏｃａｐ．ｃｒｌ．ｘ”に対応する証明書チェーンは、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．ｘ”である。図４３の場合、“ｏｃａｐ．ｃｒｌ．２”に対応する証明書チェーンは、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．２”である。

図４６は、“ｏｃａｐ．ｈａｓｈｆｉｌｅ”ファイル４３４の模式図である。４６１は４３４のｏｃａｐ．ｈａｓｈｆｉｌｅの内容を表す。４６１のｏｃａｐ．ｈａｓｈｆｉｌｅは、“／”ディレクトリ４３１に存在し、同じディレクトリ４３１に存在する“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル４３６、“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１”ファイル４３７、“ａ”ディレクトリ４３２、“ｏｃａｐ．ｃｒｌ．２”ファイル４３８、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．２”ファイル４３９に関するハッシュ値をそれぞれ格納する。

図４４は、ＣＲＬの認証について説明したフローチャートである。ファイルシステムが図４３の構成を取っているときを例に挙げて以下に説明する。まず、ＣＲＬから今回更新日時４１１２と次回更新日時４１１３を抽出する（ステップＳ４４１）。現在日時が、今回更新日時４１１２と次回更新日時４１１３の間であるかを確認する（ステップＳ４４２）。もし、当てはまらないならば、本ＣＲＬは無効であると判断する（ステップＳ４４７）。当てはまるならば、“ｏｃａｐ．ｃｒｌ．２”ファイル４３８の署名値を検証するために、属性領域４１１部分のハッシュ値を計算する（ステップＳ４４３）。一方、証明書チェーン“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．２”ファイル４３９からリーフ証明書２３１３の公開鍵２４１７を抽出し（ステップＳ４４４）、抽出した公開鍵２４１７を用いて、“ｏｃａｐ．ｃｒｌ．２”ファイル４３８の署名値４１３を復号する（ステップＳ４４５）。そして、ステップＳ４４３で得たハッシュ値とステップＳ４４５での復号値が等しいかを確認し（ステップＳ４４６）、等しくなければＣＲＬは無効だと判断する（ステップＳ４４７）。等しければ、図４５を参照して、証明書チェーン“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．２”ファイル４３９の認証を行う（ステップＳ４５１）。証明書チェーンの認証方法は、前記した図３１〜図３３と同じであるので、ここでは省略する。その後、証明書チェーンの認証が成功したかを判断し（ステップＳ４５２）、もし失敗ならば、本ＣＲＬは無効であると判断する（ステップＳ４５６）。一方、成功ならば、２次記憶部５１０からルート証明書と同じ証明書を探す（ステップＳ４５３）。ここで、一致するルート証明書が存在しないならば、本ＣＲＬは認証失敗で無効と判断し（ステップＳ４５６）、含まれるならば、ＣＲＬは認証成功で有効と判断する（ステップＳ４５５）。

ここから、証明書がＣＲＬによって無効化されているにもかかわらず、Ｊａｖａプログラムが起動されるという問題点の解決方法について記述する。これに対応するため、本実施の形態では、Ｊａｖａプログラムの起動通知が行われたとき、Ｊａｖａプログラムを認証した証明書がＣＲＬによって失効されたか判断する機能を追加する。

本実施の形態における構成要素を図２６に示す。一部追加のある２６２とまだ説明していない２６９以外については、前記しているので説明を省略する。

判定手段２６２は、ＣＲＬを認証する機能をさらに持ち、失効証明書特定手段２６９にＣＲＬによって失効される証明書の特定を要求する。そして、失効証明書特定手段２６９で特定された失効した証明書と関係するＪａｖａプログラムの起動直前通知を通知受取手段２６１で受け付けたとき、判定手段２６２は認証失敗と判断する。一方、判定手段２６２がＣＲＬの認証に失敗してＣＲＬは無効であると判断していれば、Ｊａｖａプログラムの起動直前通知を通知受取手段２６１で受け付けたとき、判定手段２６２は認証成功と判断する。

失効証明書特定手段２６９は、判定手段２６２でＣＲＬの認証が成功であったことを認識するとき、証明書抽出手段２６５で抽出したＸ．５０９証明書のどれが失効した証明書であるかを特定する。

また、フローチャートについては図４７と図４８を追加する。以下に、フローチャートに則して説明する。今、図２１で示されるファイルシステムに対する保存直前通知が発生したとすると、図３５のフローチャートで示される処理を開始し、やがてステップＳ３５７の処理が完了する。その後、図４３で示される別のファイルシステムの保存直前通知を受け付けたとすると、図４４のフローチャートで示す処理を完了後、ステップＳ４７１〜ステップＳ４７７を行う。ステップＳ４７１〜ステップＳ４７７の処理は、ステップＳ３５１〜ステップＳ３５７までと同様である。ステップＳ４７８に到達したとき、“ｏｃａｐ．ｃｒｌ．２”ファイル４３８の認証（図４４、図４５のフローチャート）が成功であれば、それに内在する失効証明書の情報を失効証明書データベースに登録する。図４９は失効証明書データベースの模式図である。４９１列に発行者名、４９２列に証明書のシリアル番号、４９３列に失効した日時を格納する。ここで、図２１の“ＰＰＶ１Ｘｌｅｔ．ｃｌａｓｓ”２１１４の起動直前通知を受け付けると（ステップＳ４８１）、“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”ファイル２１１９の証明書チェーン２３１にあるＸ．５０９証明書が、失効証明書データベースに該当しないか確認する（ステップＳ４８３）。もし、該当する証明書があれば、認証失敗と判断して通知する（ステップＳ４８６）。一方、どの証明書も該当しないならば、すべての証明書チェーンについて確認した後（ステップＳ４８４）、認証成功と判断して通知する（ステップＳ４８５）。以上から、検証時は有効であった証明書が、Ｊａｖａプログラムの起動時にはＣＲＬによってすでに失効されていても、そのファイルシステムは認証失敗と判断され、起動すべきでないＪａｖａプログラムが起動されてしまうという問題点を解決できる。

なお、実施の形態１〜４において、Ｊａｖａプログラムの起動直前通知を受け付けた際、各ディレクトリに配置された“ｏｃａｐ．ｈａｓｈｆｉｌｅ”を利用して、ファイルシステムのツリー構成が正しいかの検証をさらに行ってもよい。

また、証明書チェーンの中間証明書は、簡単のため一つにしているが、複数存在していても構わない。但し、証明書チェーンの認証の際には、すべての中間証明書間で連鎖状態になっている必要がある。

また、改竄有無のチェック、証明書チェーンの認証、ルート証明書の２次記憶部に証明書チェーン中のルート証明書が存在するかの確認をこの順序で記述しているが、順序はこれにこだわるものではない。

また、ファイルシステムの保存は、セキュリティマネージャ１２０５ｆがＯＳのライブラリ１２０１ｂを利用して保存してもよい。また、“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”がファイルシステムのトップディレクトリ“／”で提供され、その内容として、ファイルの保存対象としてファイルシステムの一部だけを指示している場合であっても、実施の形態１〜４は適用可能で、保存対象のファイルのみ扱っても問題ない。

また、保存の対象としてプログラムを取り上げているが、プログラム以外のデータであってもよく、データに対して実施の形態１〜実施の形態４を適用してもよい。

また、“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．ｘ”に対応する“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．ｘ”が複数存在することもあり得るが、その場合少なくとも一つの“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．ｘ”で認証が成功すればよい。

また、証明書チェーンとして“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．ｘ”、ハッシュ値をもつファイルとして“ｏｃａｐ．ｈａｓｈｆｉｌｅ”、“／”ディレクトリに存在する“ｏｃａｐ．ｈａｓｈｆｉｌｅ”の改竄チェック用ファイルとして“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．ｘ”を例として挙げたが、本発明はこれらのファイル名に限定されるものではない。

また、認証失敗の場合はダウンロードし直して実行することにしてもよい。
また、認証失敗の場合には、保存領域の容量を確保するために、保存済みのプログラム及び認証に利用した証明書チェーン、署名ファイル、ハッシュファイルを削除してもよい。

また、プログラムを構成するファイルシステムの構成が図５０であるときに、図５１の“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”のように認証に使用するファイルが記述されていない場合について説明する。図５０中の５０１１から５０２０まではそれぞれ、図２１の２１１１から２１２０と同じである。５０２１は、保存対象であるファイルを記述した“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”を表す。図５１の“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”では、認証のために使用される“ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅ．１”５０１９，“ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１”５０２０，“ｏｃａｐ．ｈａｓｈｆｉｌｅ”５０１７が記述されていない。この場合、図５１の“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”のとおりにファイルを保存すると、認証に使用されるファイルが保存されない。すると、保存したファイルだけでは、プログラムの起動時に実施の形態２から実施の形態４で記述した認証ができなくなる。よって、保存したプログラムを起動しようとするとき、保存前と同じ図５０に示すファイルがダウンロードできる状態にあれば、起動するプログラムを構成するファイルは保存先からのものを使用し、認証に使用するファイルはダウンロードしなおしてから認証を行うことにしてもよい。

また、保存前と同じ図５０に示すファイルがダウンロードできるとは限らないことが想定される。よって、認証に使用されるファイルが“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”に記述されていなくても、プログラム起動時の認証に備えて、認証に必要となるファイルは保存しておくことにしてもよい。

本発明にかかる認証プログラム実行方法は、プログラムの信用性の保証と応答性の向上が両立可能であり、デジタルテレビ受信機の一時的な機能向上、機能付加等として有用である。またデジタルテレビに限らずパーソナルコンピュータや携帯電話などソフトウエアによって制御される情報機器の一時的な機能向上、機能付加等の用途にも応用できる。

図１は、本発明に係るケーブルテレビシステムの実施の形態１の構成図である。 図２は、本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例である。 図３は、本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例である。 図４は、本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例である。 図５は、本発明に係るケーブルテレビシステムにおいて端末装置の構成図である。 図６は、本発明に係るケーブルテレビシステムにおいて端末装置の外観の一例である。 図７は、本発明に係るＰＯＤ５０４のハードウエア構成の構成図である。 図８は、本発明に係るＰＯＤ５０４が保存するプログラム構成の構成図である。 図９は、ＭＰＥＧ規格で定義されているパケットの構成図である。 図１０は、ＭＰＥＧ２トランスポートストリームの一例である。 図１１は、入力部５１３をフロントパネルで構成した場合の外観の一例である。 図１２は、本発明に係る端末装置５００が保存するプログラム構成の構成図である。 図１３Ａは、本発明に係るディスプレイ５０９の表示の一例である。 図１３Ｂは、本発明に係るディスプレイ５０９の表示の一例である。 図１４は、本発明に係る２次記憶部５１０が保存する情報の一例である。 図１５Ａは、本発明に係る１次記憶部５１１が保存する情報の一例である。 図１５Ｂは、本発明に係る１次記憶部５１１が保存する情報の一例である。 図１５Ｃは、本発明に係る１次記憶部５１１が保存する情報の一例である。 図１６は、本発明に係るＭＰＥＧ２規格が規定するＰＡＴの内容を表す模式図である。 図１７は、本発明に係るＭＰＥＧ２規格が規定するＰＭＴの内容を表す模式図である。 図１８は、本発明に係るＤＶＢ−ＭＨＰ規格が規定するＡＩＴの内容を表す模式図である。 図１９は、本発明に係るＤＳＭＣＣ方式で送信されるファイルシステムを表す模式図である。 図２０は、本発明に係るＸＡＩＴの内容を表す模式図である。 図２１は、本発明に係る２次記憶部５１０が保存する情報の一例である。 図２２Ａは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例である。 図２２Ｂは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例である。 図２２Ｃは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例である。 図２３は、本発明に係る証明書チェーンの構成図である。 図２４は、本発明に係るＸ．５０９証明書の構成図である。 図２５は、本発明に係る署名ファイルの構成図である。 図２６は、本発明に係るセキュリティモジュールの構成要素を示した図である。 図２７は、本発明に係るファイルシステムの認証を行う際の動作を示したフローチャートである。 図２８は、本発明に係るプログラム起動直前通知を受け付けた際に、認証を行わないときのフローチャートである。 図２９は、本発明に係るファイルシステムの改竄チェックを行う際の動作を示したフローチャートである。 図３０は、本発明に係る署名ファイルを用いて改竄チェックを行う際の動作を示したフローチャートである。 図３１は、本発明に係るリーフ証明書と中間証明書の連鎖関係を確認する際の動作を示したフローチャートである。 図３２は、本発明に係る中間証明書とルート証明書の連鎖関係を確認する際の動作を示したフローチャートである。 図３３は、本発明に係るルート証明書の署名を確認する際の動作を示したフローチャートである。 図３４は、本発明に係る保存対象であるファイルを特定するために利用されるファイルの一例である。 図３５は、本発明に係るファイルシステムの認証を行う際の動作を示したフローチャートである。 図３６は、本発明に係るプログラム起動直前通知を受け付けた際に、Ｘ．５０９証明書の有効性を確認する際の動作を示したフローチャートである。 図３７は、本発明に係るダウンロードモジュールから受け取るコードファイルの簡単な構成図である。 図３８Ａは、本発明に係る端末装置が所有する証明書が交換される際の様子を示した図である。 図３８Ｂは、本発明に係る端末装置が所有する証明書が交換される際の様子を示した図である。 図３８Ｃは、本発明に係る端末装置が所有する証明書が交換される際の様子を示した図である。 図３９は、本発明に係る証明書交換を行う際の動作を示したフローチャートである。 図４０は、本発明に係るプログラム起動直前通知を受け付けた際に、ルート証明書を照合する際の動作を示したフローチャートである。 図４１は、本発明に係るＣＲＬの構成図である。 図４２は、本発明に係るＣＲＬ中の失効証明書リストの模式図である。 図４３は、本発明に係るＣＲＬが存在するファイルシステムの一例である。 図４４は、本発明に係るＣＲＬの有効性をハッシュ値と署名値から確認する際の動作を示すフローチャートである。 図４５は、本発明に係るＣＲＬの有効性を証明書の連鎖関係及びルート証明書の照合によって確認する際の動作を示すフローチャートである。 図４６は、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例である。 図４７は、本発明に係るプログラム保存時にＣＲＬが存在する場合の認証の動作を示したフローチャートである。 図４８は、本発明に係るプログラム起動時にＣＲＬが存在する場合の認証の動作を示したフローチャートである。 図４９は、本発明に係る失効証明書データベースの模式図である。 図５０は、本発明に係る保存対象であるファイルを特定するために利用されるファイルが存在するファイルシステムの一例である。 図５１は、本発明に係る保存対象であるファイルを特定するために利用されるファイルの一例である。

Claims (9)

1. トランスポートストリームに含まれるプログラムのデータファイルの保存に関する情報に従い、前記トランスポートストリームに含まれるプログラムを認証し放送受信装置に保存する認証・保存ステップと、前記認証・保存したプログラムを実行する実行ステップとを有する認証プログラム実行方法であって、
   前記認証・保存ステップは、
   前記プログラムに含まれるデータファイルのハッシュ値が前記データファイルに対応するハッシュファイルに格納されたハッシュ値と一致するかどうかをチェックする第１のステップと、
   前記プログラムに含まれる証明書ファイルの有効性を検証する第２のステップと、
   前記プログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記プログラムに含まれる署名ファイルの署名値を復号した値と、前記プログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第３のステップと、
   前記第１のステップにてハッシュ値が一致し、前記第２のステップにて前記証明書ファイルが有効であると判定され、前記第３のステップにてハッシュ値が一致すると判定された場合に前記プログラムを認証し、前記保存に関する情報に従い前記プログラムのデータファイルを保存する第４のステップとを含み、
   前記実行ステップは、
   前記保存したプログラムに含まれる証明書ファイルの有効性を検証する第５のステップを含み、
   前記第５のステップにて、前記保存したプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存したプログラムを再度認証し、実行する
   ことを特徴とする認証プログラム実行方法。
2. 前記プログラムがディレクトリ構造を有する場合には、
   各ディレクトリに含まれる前記データファイルと、対応する前記ハッシュファイルとは同一ディレクトリ内に存在し、
   前記第１のステップは前記各ディレクトリのデータファイルに対して実行される
   ことを特徴とする請求項１記載の認証プログラム実行方法。
3. 前記第２のステップは、
   前記プログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第６のステップを有し、
   前記プログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定する
   ことを特徴とする請求項１記載の認証プログラム実行方法。
4. 前記第２のステップは、さらに、
   前記プログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第７のステップを有し、
   前記プログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、認証日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定する
   ことを特徴とする請求項３記載の認証プログラム実行方法。
5. 前記第５のステップは、
   前記保存したプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第８のステップを有し、
   前記保存したプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定する
   ことを特徴とする請求項１記載の認証プログラム実行方法。
6. 前記第５のステップは、さらに、
   前記保存したプログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第９のステップを有し、
   前記保存したプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、実行日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定する
   ことを特徴とする請求項５記載の認証プログラム実行方法。
7. 前記第１のステップにてハッシュ値が一致しない場合、前記第２のステップにて前記証明書ファイルが有効でないと判定された場合、または前記第３のステップにてハッシュ値が一致しない場合には、前記プログラムを保存しない
   ことを特徴とする請求項１記載の認証プログラム実行方法。
8. トランスポートストリームに含まれるプログラムのデータファイルの保存に関する情報に従い、前記トランスポートストリームに含まれるプログラムを認証し、保存する認証・保存手段と、前記認証・保存したプログラムを実行する実行手段とを有する認証プログラム実行装置であって、
   前記認証・保存手段は、
   前記プログラムに含まれるデータファイルのハッシュ値が前記データファイルに対応するハッシュファイルに格納されたハッシュ値と一致するかどうかをチェックする第１検証部と、
   前記プログラムに含まれる証明書ファイルの有効性を検証する第２検証部と、
   前記プログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記プログラムに含まれる署名ファイルの署名値を復号した値と、前記プログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第３検証部と、
   前記第１検証部にてハッシュ値が一致し、前記第２検証部にて前記証明書ファイルが有効であると判定され、前記第３検証部にてハッシュ値が一致すると判定された場合に前記プログラムを認証し、前記保存に関する情報に従い前記プログラムのデータファイルを保存する保存部とを備え、
   前記実行手段は、
   前記保存したプログラムに含まれる証明書ファイルの有効性を検証する第４検証部を備え、
   前記第４検証部にて、前記保存したプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存したプログラムを再度認証し、実行する
   ことを特徴とする認証プログラム実行装置。
9. トランスポートストリームに含まれるプログラムのデータファイルの保存に関する情報に従い、前記トランスポートストリームに含まれるプログラムを認証し放送受信装置に保存する認証・保存ステップと、前記認証・保存したプログラムを実行する実行ステップとをコンピュータに実行させるプログラムであって、
   前記認証・保存ステップは、
   前記プログラムに含まれるデータファイルのハッシュ値が前記データファイルに対応するハッシュファイルに格納されたハッシュ値と一致するかどうかをチェックする第１のステップと、
   前記プログラムに含まれる証明書ファイルの有効性を検証する第２のステップと、
   前記プログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記プログラムに含まれる署名ファイルの署名値を復号した値と、前記プログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第３のステップと、
   前記第１のステップにてハッシュ値が一致し、前記第２のステップにて前記証明書ファイルが有効であると判定され、前記第３のステップにてハッシュ値が一致すると判定された場合に前記プログラムを認証し、前記保存に関する情報に従い前記プログラムのデータファイルを保存する第４のステップとを含み、
   前記実行ステップは、
   前記保存したプログラムに含まれる証明書ファイルの有効性を検証する第５のステップを含み、
   前記第５のステップにて、前記保存したプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存したプログラムを再度認証し、実行する
   ことを特徴とするプログラム。

Images