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

Abstract

従来の放送波でダウンロードされたプログラムに対する技術とは異なり、ネットワーク経由でプログラムをダウンロードする場合には、プログラムが改竄されたことに気づかずに、そのプログラムを起動する可能性がある。そこで、ネットワーク経由でプログラムをダウンロードする時、端末装置のローカル領域へ、サーバ上に配置されたプログラムのファイル階層を構築する。そして、プログラムの認証は、ローカル領域で構築したファイル階層に対して行い、プログラムの信用性を保証する。

Description

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

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

以下では、そのようなプログラムの信用性を確認することを認証と呼ぶこととする。

ＤＶＢ−ＭＨＰ規格書“ＥＴＳＩ ＴＳ １０１ ８１２ Ｖ１．２．１ ＤＶＢ−ＭＨＰ仕様１．０．２”等においては、放送波に重畳されたプログラムだけでなく、サーバに配置されたプログラムをインターネット等のネットワーク経由でダウンロードし、それを認証することも考えられている。

しかしながら、従来の放送波でダウンロードされたプログラムに対する場合とは異なり、ネットワーク経由でプログラムをダウンロードする場合にはセキュリティ上の不具合が発生し得る。ここでいうセキュリティ上の不具合とは、プログラムの認証に使用したプログラムを構成するファイル(以下では、構成ファイルと呼ぶ)と、端末装置上でプログラムが起動されるときに使用されるプログラムの構成ファイルとが、一部もしくはすべてのファイルにおいて異なっている可能性があるということである。これは、端末装置がサーバからプログラムの構成ファイルをダウンロードし認証後に、サーバ上に配置されたプログラムの構成ファイルが改竄される場合である。その構成ファイルが改竄され、その後端末装置が再度ダウンロードすると、その構成ファイルから成るプログラムを正常に利用できなくなる。

また、ＪＡＲ（Ｊａｖａ Ａｒｃｈｉｖｅ）という、既知のＺＩＰファイル形式に基づいたファイル形式で、多数のファイルを１つにまとめる技術が存在する。この技術を用いると、ファイルのサイズが圧縮され、ＪＡＲを利用しない場合に比べてダウンロードに要する時間を短縮できる。しかしＪＡＲを使う場合、サーバ上に配置したデータが頻繁に更新していくようなケースでは、データが更新されるたびにＪＡＲ形式のファイルを作り変えなければならなくなる。これはサーバに対する負荷をかけ、好ましくないという課題がある。例えば、株価などの情報はリアルタイムに変化しつづけるので、株価情報を利用するプログラムをサーバが提供するようなケースが該当する。

上記問題点を鑑みて、サーバ上にはＪＡＲで示される圧縮ファイルを利用せずファイル及びディレクトリが階層構造で配置され、そのサーバからネットワーク経由でダウンロードされるプログラムの信用性を保証する、デジタルテレビ等の認証装置が望まれる。

本発明は、ネットワーク経由でプログラムをダウンロードする時、端末装置のローカル領域へ、サーバ上に配置されたプログラムのファイル階層を構築する。そして、ローカル領域で構築したファイル階層に対してプログラムの認証を行うことによって、プログラムの信用性を保証することができる認証プログラム実行方法を提供することを目的とする。

上記目的を達成するために、本発明に係る認証プログラム実行方法は、トランスポートストリームに指定されたプログラムを格納する場所を特定する情報に従い、ディレクトリ構造を用いて改竄チェックが必要なデータファイルを格納したプログラムをネットワークに接続された所定のサーバからダウンロードし、前記ダウンロードした改竄チェックが必要なデータファイルを認証および前記プログラムを放送受信装置内に保存する認証・保存ステップと、前記認証したプログラムを実行する実行ステップとを有する認証プログラム実行方法であって、前記認証・保存ステップは、前記ディレクトリ構造を構成するディレクトリに含まれるハッシュファイルに記述されたディレクトリとデータファイルとを用いて前記サーバ内に格納されたプログラムのディレクトリ構造と同一のディレクトリ構造を有するように前記ハッシュファイルに記述された改竄チェックが必要なデータファイルを全て前記放送受信端末内にダウンロードする第１のステップと、前記改竄チェックが必要なデータファイルのハッシュ値が前記改竄チェックが必要なデータファイルを指定するハッシュファイルに格納されたハッシュ値と一致するかどうかを改竄チェックが必要な全てのデータファイルについてチェックする第２のステップと、前記プログラムに含まれる証明書ファイルの有効性を検証する第３のステップと、前記プログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記プログラムに含まれる署名ファイルの署名値を復号した値と、前記プログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第４のステップと、前記第２のステップにおいてハッシュ値が一致し、前記第３のステップにおいて前記証明書ファイルが有効であると判定され、前記第４のステップにおいてハッシュ値が一致すると判定された場合に前記プログラムを認証し、前記プログラムを保存する第５のステップとを有し、前記実行ステップは、前記保存したプログラムに含まれる証明書ファイルの有効性を検証する検証ステップを有し、前記検証ステップにおいて、前記保存したプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存したプログラムを再度認証し、実行することを特徴とする。

これによって、ローカル記憶領域にサーバと同じファイル階層を構築することができ、プログラムの信用性を保証することができる。また、認証が成功したにも関わらずサーバ上で改竄されたプログラムが放送受信装置へインストールされるのを防止できる。これにより、サーバ上で改竄があっても、放送受信装置上ではそのプログラムを正常に利用できる。そして、再度プログラムをダウンロードしなくて済み、ダウンロードした分の認証を省略できる。これは、認証が完了するまでプログラムの起動完了を待たされるユーザーにとって、利便性が向上する。さらに、本発明では、ＪＡＲで示される圧縮ファイルを利用せずに、ファイル階層の形式でサーバがファイルを公開するので、頻繁にデータがアップデートされるファイルをサーバが含む場合であっても、その都度圧縮ファイルを作り直さなければならないというサーバの負担を軽減できる。

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

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

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

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

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

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

また、前記第２のステップにおいてハッシュ値が一致しない場合、前記第３のステップにおいて前記証明書ファイルが有効でないと判定された場合、または前記第４のステップにおいてハッシュ値が一致しない場合には前記プログラムを保存しなくてもよい。

これによって、例えばサーバ上で改竄されたプログラムを保存するのを防止することができる。

また、前記第１のステップは、前記サーバにおいて前記プログラムを構成する最上位のディレクトリに格納されたハッシュファイルにディレクトリが指定されている場合、前記放送受信装置において最上位のディレクトリの下に当該ハッシュファイルが指定するディレクトリと同一のディレクトリを前記放送受信装置内に構築するとともに、前記サーバの最上位のディレクトリに格納されるハッシュファイルが指定するディレクトリに格納されたハッシュファイルに指定された改竄チェックが必要なデータファイルを前記放送受信装置内に構築した対応するディレクトリにダウンロードする第１０のステップを有してもよい。

これによって、放送受信装置にサーバと同じファイル階層を構築し、改竄チェックが必要なデータファイルを放送受信装置内に構築した対応するディレクトリにダウンロードすることができる。

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

本発明に係る認証プログラム実行方法によれば、ローカル記憶領域にサーバと同じファイル階層を構築することができ、プログラムの信用性を保証することができる。また、認証が成功したにも関わらずサーバ上で改竄されたプログラムが放送受信装置へインストールされるのを防止できる。これにより、サーバ上で改竄があっても、放送受信装置上ではそのプログラムを正常に利用できる。

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

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

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

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

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

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

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

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

ディスプレイ６０２は、図５におけるディスプレイ５０９に相当する。

フロントパネル部６０３は複数のボタンで構成され、図５の入力部５１３に相当する。

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

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

挿入スロット６０６はＰＯＤカード６０５が挿入される挿入スロットである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＪａｖａＶＭ１２０３は、引き渡されたＪａｖａプログラムを実行する。

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

セキュリティマネージャ１２０５ｆは、端末装置上で実行されるプログラムの信用性を保証するために必要とされる。もしプログラムが改竄され、その改竄されたプログラムが端末装置上で動作できてしまうと、端末装置のメモリ等のリソースが浪費されて端末装置全体の動作が不安定になったり、ネットワークといったリソースを使って端末装置上の情報が勝手に送信されてしまうということにもなりかねない。セキュリティマネージャ１２０５ｆは、そのようなことが起こらないように、プログラムの信用性・信頼性を判断する。このような認証機能を提供するセキュリティマネージャ１２０５ｆの詳細については後述する。

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

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

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

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

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

ＡＭ１２０５ｂは、ＸＡＩＴ情報を受け取ると、ＡＩＴ情報からＪａｖａプログラムをダウンロードした手順と同じ手順で、ＭＰＥＧ２トランスポートストリームからファイルシステムを１次記憶部５１１上に展開するか、または、ＸＡＩＴ情報でＪａｖａプログラムを保存する指示がなされているとき、２次記憶部５１０に保存する。１次記憶部５１１への展開または２次記憶部５１０への保存の際は、ＸＡＩＴ情報にダウンロードしたファイルの格納位置を対応づける。

図２１は、１次記憶部５１１または２次記憶部５１０がＸＡＩＴ情報とダウンロードしたファイルシステムが対応づけられて保存されている一例を表す。ここではＯＣＡＰ規格“ＯｐｅｎＣａｂｌｅ（ＴＭ） Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＯＣＡＰ １．０ Ｐｒｏｆｉｌｅ（ＯＣ−ＳＰ−ＯＣＡＰ１．０−Ｉ１１−０４０６０４）”で定義されているファイルを取り上げて説明する。図２１の中で、図２０と同じ番号の要素は図２０と同じなので、説明は省略する。列２１０１は対応するダウンロードしたファイルシステムの保存位置を格納する。図中、保存位置は矢印で示している。２１１０はダウンロードしたファイルシステムであり、内部にトップディレクトリ２１１１、ディレクトリ「ａ」２１１２、ディレクトリ「ｂ」２１１３、ファイル「ＰＰＶ１Ｘｌｅｔ．ｃｌａｓｓ」２１１４、ファイル「ＰＰＶ２Ｘｌｅｔ．ｃｌａｓｓ」２１１５、ファイル「ｏｃａｐ．ｈａｓｈｆｉｌｅ」２１１６〜２１１８、ファイル「ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅｓ．１」２１１９、ファイル「ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１」２１２０を保持する。

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

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

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

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

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

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

Ｊａｖａプログラムが２次記憶部５１０に保存される場合には、端末装置５００の電源ＯＦＦ等により１次記憶部５１１からそれが消去されたとしても、ＡＭ１２０５ｂが図２０で示すＸＡＩＴを受信すれば、ダウンロードを待たずにＪａｖａプログラムが起動される。

図２０では、プログラム“／ａ／ＰＰＶ１Ｘｌｅｔ”が制御情報２００２として「ａｕｔｏｓｔａｒｔ」になっている。そこで、図２１の２０１１において、“／ａ／ＰＰＶ１Ｘｌｅｔ”に対応するファイルシステムの位置２１０１を探し、ファイル２１１４をＪａｖａＶＭ１２０３に引き渡すと、ファイルシステムに保有されているＪａｖａプログラム“ＰＰＶ１Ｘｌｅｔ”が起動される。なお、ＡＭ１２０５ｂは、Ｊａｖａプログラムの起動までに、Ｊａｖａプログラム識別子２００１の値を調べ、ｕｎｓｉｇｎｅｄプログラムであるのか、ｓｉｇｎｅｄプログラムであるのかを判断している。もし、ｓｉｇｎｅｄプログラムであれば、セキュリティマネージャ１２０５ｆに認証の実行を指示することになる。

次に、認証を実施するセキュリティマネージャ１２０５ｆについて説明する。

セキュリティマネージャ１２０５ｆは、ＡＭ１２０５ｂからファイルを認証するように指示されると、Ｊａｖａプログラム識別子２００１の値を調べ、ｕｎｓｉｇｎｅｄプログラムであるのか、ｓｉｇｎｅｄプログラムであるのかを判断する。ここで、Ｊａｖａプログラムはｓｉｇｎｅｄプログラムであるので、“／”ディレクトリ以下のファイルシステムについて、認証を実行する。認証では、図２１のｏｃａｐ．ｈａｓｈｆｉｌｅ（２１１６〜２１１８）、ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅｓ．１（２１１９）、ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１（２１２０）を使用して検証する。

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

通知受取部２６１は、ＡＭ１２０５ｂによるファイルの認証指示を受け取るための手段であり、それを判定部２６２へ伝える。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、ファイルシステムに“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”が存在するとき、ＸＡＩＴ情報で保存指示がシグナルされると、それに記述されたファイルが保存対象となる。例えばＯＣＡＰ規格では、“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”はＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記述される。この一例である図３４に“ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ”の例を示す。

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

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

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

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

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

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

従って、Ｊａｖａプログラムの起動時に証明書交換を考慮して、ルート証明書の照合を行う技術がある。

この技術の構成要素を図２６に示す。構成要素２６１〜２６５については前記したのでここでの説明は省略するが、証明書交換部２６６、交換証明書特定部２６７、証明書受信部２６８を追加する。

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

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

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

また、図３５のフローチャートに引き続いて、図３９と図４０を追加する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、認証失敗の場合はダウンロードし直して実行することにしてもよい。

（実施の形態５）
ここまで、放送波からＪａｖａプログラムをダウンロードする場合について説明してきた。以下から、本発明に関する、インターネットに代表されるネットワークを経由してプログラムをダウンロードする場合の認証について説明する。

ＤＶＢ−ＭＨＰ規格書“ＥＴＳＩ ＴＳ １０１ ８１２ Ｖ１．２．１ ＤＶＢ−ＭＨＰ仕様１．０．２”、またはＯＣＡＰ規格書“ＯｐｅｎＣａｂｌｅ（ＴＭ） Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＯＣＡＰ １．０ Ｐｒｏｆｉｌｅ（ＯＣ−ＳＰ−ＯＣＡＰ１．０−Ｉ１１−０４０６０４）”においても、ネットワークを経由したＪａｖａプログラムのダウンロードは想定されていた。一方、ＪＡＲ（Ｊａｖａ Ａｒｃｈｉｖｅ）という、既知のＺＩＰファイル形式に基づいたファイル形式で、多数のファイルを１つにまとめる技術が存在する。この技術を用いると、ファイルのサイズが圧縮され、ＪＡＲを利用しない場合に比べてダウンロードに要する時間を短縮できる。しかしＪＡＲを使う場合、サーバ上に配置したデータが頻繁に更新していくようなケースでは、データが更新されるたびにＪＡＲ形式のファイルを作り変えなければならなくなる。これはサーバに対する負荷をかけ、好ましくない場合がある。例えば、株価などの情報はリアルタイムに変化しつづけるので、株価情報を利用するプログラムをサーバが提供するようなケースが該当する。以降では、ＪＡＲを利用せずに、サーバ上にはファイル及びディレクトリが階層構造で配置されているケースに焦点を当てる。

端末装置がネットワーク経由でサーバからダウンロードする場合でも、ダウンロード対象のプログラムがｓｉｇｎｅｄプログラムであれば、プログラムを構成するファイルが保証されたものであるか検証しなければならない。また、プログラムを実際にインストールして起動するときにもプログラムの構成ファイルは必要となる。しかし、認証時とインストール時（またはプログラムの起動時）とでサーバからダウンロードしていると、端末装置が認証を完了しても、インストール時にダウンロードするまでに、サーバ上のプログラムが改竄されている可能性がある。ここでは、その問題を克服する発明を以下に説明していく。

ＡＩＴもしくはＸＡＩＴを模式的に表した表を図５０に示す。図２０と比較すると列５００３が異なり、列５００６が加わる。それ以外の列５００１から列５００５までは、図２０の列２００１から列２００５までと同じ意味をもつ。但し列５００３は、値が「１」であれば前述したＤＳＭＣＣ識別子であるが、値が「２」であればＩＰネットワーク経由でＪａｖａプログラムをダウンロードすることを示すＩＰ識別子である。列５００４はＪａｖａプログラムのプログラム名である。列５００５は、Ｊａｖａプログラムの優先度である。列５００６は、ダウンロードすべきＪａｖａプログラムが配置されているサーバとその格納位置を示すＵＲＬである。行５０１１は、Ｊａｖａプログラムの情報の組である。行５０１１で定義されるＪａｖａプログラムは、識別子「０ｘ５００１」、制御情報「ａｕｔｏｓｔａｒｔ」、識別子「２」、プログラム名「ａ／ＰＰＶ３Ｘｌｅｔ」の組である。Ｊａｖａプログラムの識別子Ａｐｐｌｉｃａｔｉｏｎ ＩＤから、Ｊａｖａプログラムはｓｉｇｎｅｄプログラムであることが分かる。ＵＲＬが「ｈｔｔｐ：／／ｐａｎａｓｏｎｉｃ．ｃｏｍ／ａｐｐ」であるから、端末装置はサーバ“ｐａｎａｓｏｎｉｃ．ｃｏｍ”の“ａｐｐ”に割り当てられているディレクトリ及びそのサブディレクトリから、ＨＴＴＰを使用して、Ｊａｖａプログラムをダウンロードする。ここで、ＨＴＴＰは、ＰＣ等の装置を使って、インターネットの先にあるＷｅｂサーバからホームページをダウンロードするときに今日最もよく利用されている既知の技術である。ＨＴＴＰについては、ＲＦＣ２６１６に詳細に記述されている。

ここでは、Ｊａｖａプログラムに対して６つの情報しか規定しないが、より多くの情報が定義されていても本発明は実施可能である。

図５１は、ＩＰネットワーク経由でＪａｖａプログラムをダウンロードするときの構成を示す模式図である。ヘッドエンド５１０１と端末装置５１０２は、ＣＡＴＶ網５１０４を介して接続されている。また、ヘッドエンド５１０１と、端末装置５１０２と、Ｊａｖａプログラムが配置されたサーバ５１０３とは、インターネット等のＩＰネットワーク５１０５を介して接続されている。

図５２は、ＡＭ１２０５ｂの構成要素を示す。シグナル情報抽出部５２０１は、ＡＩＴもしくはＸＡＩＴのシグナル情報を前記したように抽出し、そのシグナル情報をファイル階層構築部５２０２へ渡す。ファイル階層構築部５２０２は、ＰＯＤ５０４を経由して、サーバ５１０３上に配置されたＪａｖａプログラム及びそのＪａｖａプログラムに関連するファイルを順次ダウンロードし、１次記憶部５１１の領域にサーバ５１０３と同じファイル階層を構築していく。ファイル階層の構築が完了すると、セキュリティマネージャ１２０５ｆへ認証の開始を指示する。認証が成功すると、ファイル階層構築部５２０２はインストール部５２０３へインストールを要求し、インストール部５２０３はインストールを開始する。

図５１及び図５２を参照しながら、ＩＰネットワーク経由でダウンロードするＪａｖａプログラムの認証について説明する。図５１のヘッドエンド５１０１から、Ｊａｖａプログラム識別子５００１として“０ｘ５００１”、Ｊａｖａプログラムの制御情報５００２として“ａｕｔｏｓｔａｒｔ”、ＩＰ識別子５００３として「２」、プログラム名５００４として“／ａ／ＰＰＶ３Ｘｌｅｔ”、優先度５００５として「２００」、ＵＲＬ５００６として「ｈｔｔｐ：／／ｐａｎａｓｏｎｉｃ．ｃｏｍ／ａｐｐ」を表すＸＡＩＴが端末装置５１０２にシグナルされると、まずシグナル情報抽出部５２０１がそのシグナル情報を解釈する。この場合、Ｊａｖａプログラム識別子の値からＪａｖａプログラムはｓｉｇｎｅｄプログラム、ＩＰ識別子からＩＰネットワーク経由でダウンロードすると判断し、サーバ５１０３上のＵＲＬ「ｈｔｔｐ：／／ｐａｎａｓｏｎｉｃ．ｃｏｍ／ａｐｐ」に存在するファイル階層と同じファイル階層を１次記憶部５１１に構築するようにファイル階層構築部５２０２へ指示を送る。図５３は、ＵＲＬ「ｈｔｔｐ：／／ｐａｎａｓｏｎｉｃ．ｃｏｍ／ａｐｐ」のファイル階層の例である。５３０１は「ｈｔｔｐ：／／ｐａｎａｓｏｎｉｃ．ｃｏｍ／ａｐｐ」のファイル階層全体、５３０２は５３０１のルートディレクトリ、５３０３と５３０７、５３０４、５３０５はそれぞれ、２１１６〜２１１８、２１１９、２１２０と同じ意味であるので、説明は省略する。５３０８はＪａｖａプログラム、５３０９はＪａｖａプログラムにより読み込まれるデータを表す。図５４Ａの５４０１と図５４Ｂの５４０２に、「ｏｃａｐ．ｈａｓｈｆｉｌｅ」５３０３と５３０７の内容をそれぞれ図示する。５４０１と５４０２の意味については、図２２での説明と同様であるので、ここでは説明を省略する。

シグナル情報抽出部５２０１から指示を受けたファイル階層構築部５２０２は、まず「ｏｃａｐ．ｈａｓｈｆｉｌｅ」５３０３をＨＴＴＰでダウンロードする。なお以下において、ＩＰネットワーク経由でのダウンロードは、ＨＴＴＰの使用を前提にするものとするが、それ以外のプロトコルでもダウンロードできれば十分である。「ｏｃａｐ．ｈａｓｈｆｉｌｅ」５３０３から、「／」５３０２は「ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅｓ．１」、「ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１」と「ａ」を含むことが分かるので、それらを順次ダウンロードする。ここで、「ａ」をダウンロードしようとした時、「ａ」はディレクトリであるのでダウンロードに失敗する。その時は「ａ／ｏｃａｐ．ｈａｓｈｆｉｌｅ」のダウンロードを試みる。実際「ａ／ｏｃａｐ．ｈａｓｈｆｉｌｅ」５３０７が存在するのでダウンロードは成功し、１次記憶部５１１に「ｏｃａｐ．ｈａｓｈｆｉｌｅ」、「ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅｓ．１」と「ｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．１」をファイルとして、また、「ａ」をディレクトリとして配置する。さらに、「ａ／ｏｃａｐ．ｈａｓｈｆｉｌｅ」から「ａ」ディレクトリに「ＰＰＶ３Ｘｌｅｔ．ｃｌａｓｓ」と「ｄａｔａ．ｔｘｔ」が存在することを読み取ると、それらをダウンロードし、１次記憶部５１１にＵＲＬ「ｈｔｔｐ：／／ｐａｎａｓｏｎｉｃ．ｃｏｍ／ａｐｐ」と同じファイル階層を構築する。なお、Ｊａｖａプログラムを２次記憶部５１０に保存する場合、１次記憶部５１１ではなく、２次記憶部５１０にファイル階層を構築してもよい。さらに、Ｊａｖａプログラムを２次記憶部５１０に保存する場合で、もし「ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ」が含まれているならば、「ａｐｐｌｉｃａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｆｉｌｅ」にはファイル階層の情報が含まれるため、「ｏｃａｐ．ｈａｓｈｆｉｌｅ」の代わりにこちらを参照してファイル階層を構築してもよい。

ファイル階層構築部５２０２がファイル階層を構築すると、セキュリティマネージャ１２０５ｆへ構築したファイル階層の認証を指示する。セキュリティマネージャ１２０５ｆは認証指示を受けると、ファイル階層の認証を行うが、認証については前述したのでここでは説明を省略する。

図５５に、ネットワーク経由でダウンロードしたプログラムを認証する時のフローチャートを示す。５０１１で示されるＸＡＩＴを受信すると（ステップＳ５５０１）、Ｊａｖａプログラム識別子５００１からｓｉｇｎｅｄプログラムであるか、ｕｎｓｉｇｎｅｄプログラムであるかを判断する（ステップＳ５５０２）。もしｓｉｇｎｅｄプログラムでなければ、インストールと起動（ステップＳ５５０７）を行う。ｓｉｇｎｅｄプログラムであれば、ＤＳＭＣＣ識別子であるかＩＰ識別子であるかを調べ（ステップＳ５５０３）、ＩＰ識別子ならローカル領域である１次記憶部５１１もしくは２次記憶部５１０上にＵＲＬ５００６で示されるファイル階層を構築する（ステップＳ５５０４）。ステップＳ５５０３でＤＳＭＣＣ識別子であった場合、もしくはステップＳ５５０４を完了すると、ローカル領域に存在するファイル階層に関してセキュリティマネージャ１２０５ｆへ認証を指示する（ステップＳ５５０５）。このステップＳ５５０５は、図２７のフローチャートに相当する。セキュリティマネージャ１２０５ｆが認証に成功したかどうかにより（ステップＳ５５０６）、成功ならばプログラムのインストールと起動を実施する（ステップＳ５５０７）。

また、サーバに配置されているファイルの一部もしくはすべてで、認証が失敗するかもしれない。更新期間中にダウンロードすることが考えられるためである。そのような場合に備えて、一定回数分または時間経過を待ってからダウンロードと認証を再試行しなおすことにしてもよい。さらには、ディスプレイ５０９へ認証が失敗したことを示すメッセージを出力し、ユーザーに再試行するかどうかの判断を仰ぐことにしてもよい。

また、例えば図５６に示すＸＡＩＴのＪａｖａプログラムをダウンロードする際、サーバ５１０３に配置されたプログラムのファイル階層が、図５７で示されるファイル階層をもち、「ｏｃａｐ．ｈａｓｈｆｉｌｅ」５６１１、５６２１、５６３１の内容が図５８Ａの５７１０、図５８Ｂの５７２０、図５８Ｃの５７３０に相当する場合、つまり、ディレクトリ「／ｂ」５６３０とディレクトリ「／」５６１０とで異なる認証用ファイル（ｏｃａｐ．ｃｅｒｔｉｆｉｃａｔｅｓ．ｘ及びｏｃａｐ．ｓｉｇｎａｔｕｒｅｆｉｌｅ．ｘ）によって認証される場合がある。このとき、図５８Ａの５７１０に示すように、ディレクトリ「／ｂ」のハッシュアルゴリズムが「Ｎｏｎ−ａｕｔｈ」で表されることにより指定されないことになる。この条件の下で、「／ｂ」ディレクトリ５６３０ではなく「／ａ」ディレクトリ５６２０下にあるプログラムを起動するシグナルがなされるとき、ファイル階層構築部５２０２は、ローカル領域に空の「／ｂ」ディレクトリを作成し、「／ｂ」ディレクトリ５６３０自体は構築しなくてもよい。「／ｂ」ディレクトリ５６３０をローカル領域に構築するのは、後に「ＰＰＶ４Ｘｌｅｔ．ｃｌａｓｓ」５６２２が「／ｂ」ディレクトリ５６３０以下の「ＰＰＶｖｉｄｅｏ．ｍｐｇ」５６３５を使用しようとする時、もしくは、「／ｂ」ディレクトリ５６３０以下の「ＰＰＶ５Ｘｌｅｔ．ｃｌａｓｓ」５６３４の起動がシグナルされるなど、「／ｂ」ディレクトリ５６３０以下にアクセスがあり認証が必要となるときでよい。なお、ディレクトリに限らずファイルに対しても同様なことを適用し、「Ｎｏｎ−ａｕｔｈ」を指定されたファイルは、サイズ０の空のファイルを一旦ローカル領域に作成することで代用し、ローカル領域のファイル階層にダウンロードしなくてもよい。但し、そのファイルへのアクセスがあるときにはファイル階層へダウンロードを行う。空のディレクトリまたは空のファイルを作成するのは、ハッシュファイルにリストされたファイル名／ディレクトリ名とファイル階層中に存在するファイル名／ディレクトリ名は一致しなければならないからである。

また、ローカル領域に構築されたファイル階層からインストールされて起動したｓｉｇｎｅｄのＪａｖａプログラムは、そのＪａｖａプログラムと同じディレクトリに、ＩＰネットワークを経由して、ファイルをダウンロードできる場合がある。万が一、Ｊａｖａプログラムが端末装置にダメージを与えるプログラムの一部（ｃｌａｓｓファイル）を意図せずにダウンロードしてしまい、それが動作すると致命的な事が発生しかねない。したがって、Ｊａｖａプログラムから、ｃｌａｓｓファイルのインストール要求が発生した場合には、インストール部５２０３がファイル階層構築部５２０２へそのｃｌａｓｓファイルをインストールしてよいかの確認を行う。ファイル階層構築部５２０２は、インストール部５２０３からインストール可否の確認を求められたときには、ファイル階層に存在するｏｃａｐ．ｈａｓｈｆｉｌｅにそのｃｌａｓｓファイルがリストされているかを調べる。もし、リストされていれば、そのｃｌａｓｓファイルのインストールを許可し、そうでなければインストールを拒絶する。さらに、ｏｃａｐ．ｈａｓｈｆｉｌｅを書き換えてしまい、ｃｌａｓｓファイルがリストされていたか不明になるのに備える必要がある。クラスファイルをインストールする際には、セキュリティマネージャ１２０５ｆへ認証を指示し、かつ、ファイル階層構築部５２０２へもｃｌａｓｓファイルのインストール可否を確認して、認証とインストール許可が成功した場合のみにしかできないようにしてもよい。

本発明に係る認証プログラム実行方法は、ローカル記憶領域にサーバと同じファイル階層を構築し、プログラムの信用性を保証することができ、デジタルテレビ受信機の機能向上、機能付加等として有用である。またデジタルテレビに限らずパーソナルコンピュータや携帯電話などソフトウエアによって制御される情報機器の機能向上、機能付加等の用途にも応用できる。

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

Claims (9)

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

Images