(57)【特許請求の範囲】
【請求項１】
ネットワークに接続されたソースファイル送信装置、暗号化プログラム配布装置及び実行ファイル受信装置とからなるプログラム配布システムにおいて、
前記ソースファイル送信装置は、
プログラムのソースファイルを前記暗号化プログラム配布装置宛てに送信する第１の送信手段を具備し、
前記暗号化プログラム配布装置は、
前記ソースファイル送信装置から送信された前記ソースファイルを受信する第１の受信手段と、
前記第１の受信手段で受信した前記ソースファイルから前記プログラムの実行ファイルを生成する実行ファイル生成手段と、
前記実行ファイルの少なくとも一部を所定の共通鍵にて暗号化する第１の暗号化手段と、
前記実行ファイル受信装置から該実行ファイル受信装置固有の公開鍵、又は該実行ファイル受信装置のプロセッサ固有の公開鍵のいずれか一方を受信する公開鍵受信手段と、
前記共通鍵を、前記公開鍵受信手段で受信した前記公開鍵で暗号化する第２の暗号化手段と、
前記第１の暗号化手段で暗号化された前記実行ファイル及び前記第２の暗号化手段で暗号化された前記共通鍵を前記実行ファイル受信装置宛てに送信する第２の送信手段と、
前記実行ファイル受信装置から送信された、前記実行ファイルに関する不具合情報の一部を、対応する前記実行ファイルの前記共通鍵にて復号化する第３の復号化手段と、
復号化した前記不具合情報から、予め定められた所定の秘密情報格納領域のデータを削除する削除手段と、
前記削除手段により、前記所定の秘密情報が削除された前記不具合情報を前記ソースファイル送信装置に送信する第３の送信手段
を具備し、
前記実行ファイル受信装置は、
前記公開鍵を前記暗号化プログラム配布装置宛てに送信する暗号化鍵送信手段と、
前記暗号化プログラム配布装置から送信された前記実行ファイル及び暗号化された前記共通鍵を受信する第２の受信手段と、
前記第２の受信手段で受信した前記共通鍵を、前記公開鍵に対応した秘密鍵で復号化する第１の復号化手段と、
前記第１の復号化手段で復号化した前記共通鍵を用いて、前記第２の受信手段で受信した前記実行ファイルを復号化する第２の復号化手段と、
前記不具合情報を送信する第３の送信手段
を具備したことを特徴とするプログラム配布システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、暗号化されたプログラムの配布システムに係り、特に安全であることが保証された暗号化されたプログラムの検証、配布、バグ情報のフィードバックなどを実現するプログラム配布システム、暗号化プログラム配布装置及びその方法に関する。
【０００２】
【従来の技術】
一般にプログラム開発にあたってはＣ言語などの高級言語が使用されることが多い。この高級言語で書かれたソースファイルをコンパイル及びリンクすることで実行ファイルが生成される。
【０００３】
コンパイル及びリンクされた実行ファイルには、メモリに置かれるデータと直接プログラムローダによって解釈されるがメモリには配置されないデータとがある。さらに前者は、ＣＰＵが直接読み取り実行可能な機械語命令列と、命令としては実行されないデータとからなる。
【０００４】
ここでは実行ファイルと呼ぶ場合は、シェルスクリプトなどの機械語以外で書かれたものは含まず、機械語命令列を含むものとする。
【０００５】
近年、このソフトウェア（プログラム）の不正な解析、改変が問題となっている。本発明の発明者らによる特願2000-35898の特許出願明細書に記載されたプログラムとデータを暗号化する機能を備えたマイクロプロセッサ(以下、耐タンパプロセッサと呼ぶ)はその問題を解決する手段の一つである。
【０００６】
このような耐タンパプロセッサでは不正な解析、改変がハードウェアによる実行コードとデータの暗号化によって防止されるためである。その安全性はプロセッサチップに埋め込まれた秘密鍵の安全性に依存する。
【０００７】
ただし、この種の耐タンパプロセッサでは、一部のプロセッサの鍵が暴かれてしまった場合に備えてチップ毎に異なる固有の鍵を用いることが多い。
【０００８】
その場合、暗号化された実行プログラムの少なくとも一部はこれらの耐タンパプロセッサチップが持つ固有の鍵に依存する部分を持たなければならない。このような耐タンパプロセッサチップ毎に異なる実行プログラムの配布にはネットワークによる配布が適している。
【０００９】
また、一方でネットワークを通じて配布されるプログラムにはいわゆるコンピュータウィルスやワームの恐れがある。あるプログラムが有害なものでないことは、その配布者の署名と身元確認によって消極的に確かめることはできるが、一般にプログラムを配布する主体が十分信用できるかを判断することは難しい。
【００１０】
これはそのプログラムが有料であるか否かに関係なくつきまとう問題である。特に現在では無数といえるほどの企業、個人がソフトウエアを開発し、その中には知名度こそ低いものの、有用なものがたくさん含まれている。
【００１１】
よってソフトウエア開発元の知名度だけでこれらソフトウエアの安全性を判定することは逆に多くの有用なソフトウエアを締め出すことになってしまう。
【００１２】
ソフトウエアの実行コードを直接解析するタイプのいわゆるウィルス検査プログラムは、いくつかの限界はあるにせよ直接ネットワーク配布されたプログラムの安全性を検証できる。
【００１３】
ところが、前述した耐タンパプロセッサを用いる環境においてはプログラムはそれぞれの耐タンパプロセッサのチップ固有の鍵に基づいて暗号化されているため、汎用のウィルス検査プログラムによって安全性を検証することが困難であった。
【００１４】
さらにソフトウェアの普及にしたがって、それらソフトウェアがユーザのさまざまなプライバシー情報を扱うようになりつつある。一方で、コンピュータウィルスのようなプログラムも現れている。また、従来の技術で記したようにコンピュータソフトウェアに含まれる秘密が不正に読み出されることもしばしばおきているという問題があった。
【００１５】
また、利用料課金方式を取るプログラムの場合、課金情報を課金サーバに通知する部分がユーザによる解析、改変から安全であることが必要とされる。更に著作権が設定されたコンテンツをユーザシステムに配信するときの不正コピー作成の防止も行われなければならない。
【００１６】
ここで実際にプログラムを使用するユーザの保護は、プログラムの保護が暗号学的に保証される環境、例えば耐タンパプロセッサが導入された環境では解決が困難である。なぜなら、ユーザが入手した暗号化されたプログラムを実行前に検証することはできないという問題があった。
【００１７】
【発明が解決しようとする課題】
上述したように、暗号化されたプログラムを実行できる環境が特定される耐タンパプロセッサなどを利用したシステムでは、それぞれの耐タンパプロセッサのチップ固有の鍵に基づいて暗号化されているため、その実行ファイルの中身を検証することができないという問題があった。
【００１８】
また、あるプログラムがコンピュータウィルスやワームの恐れがあるかどうかを検証することは、耐タンパプロセッサを利用する場合には、耐タンパプロセッサが各々違う固有鍵を有するという問題から、困難であった。
【００１９】
また、耐タンパプロセッサに対しネットワークを経由して、暗号化プログラムを配布する仕組みがなく、更にその暗号化プログラムの不具合情報をユーザの秘密情報を保護してプログラム開発者に提供することも困難であった。
【００２０】
本発明は安全であることが保証されたプログラムの配布、その検証、フィードバックといった一連の情報の流れを、コンピュータネットワークが支援することで従来の方法に比べて安価かつ確実に行うことができるプログラム配布システムを実現することを目的とする。
【００２１】
【課題を解決するための手段】
上記課題を解決するために、本発明では、ネットワークに接続されたソースファイル送信装置、暗号化プログラム配布装置及び実行ファイル受信装置とからなるプログラム配布システムにおいて、ソースファイル送信装置は、プログラムのソースファイルを暗号化プログラム配布装置宛てに送信する第１の送信手段を具備し、暗号化プログラム配布装置は、ソースファイル送信装置から送信されたソースファイルを受信する第１の受信手段と、第１の受信手段で受信したソースファイルからプログラムの実行ファイルを生成する実行ファイル生成手段と、実行ファイル受信装置から該実行ファイル受信装置固有の公開鍵、又は該実行ファイル受信装置のプロセッサ固有の公開鍵のいずれか一方を受信する公開鍵受信手段と、実行ファイルの少なくとも一部を公開鍵にて暗号化する暗号化手段と、暗号化手段で暗号化された実行ファイルを実行ファイル受信装置宛てに送信する第２の送信手段、実行ファイル受信装置から送信された、実行ファイルに関する不具合情報の一部を、対応する実行ファイルの共通鍵にて復号化する第３の復号化手段と、復号化した不具合情報から、予め定められた所定の秘密情報格納領域のデータを削除する削除手段と、削除手段により、所定の秘密情報が削除された不具合情報をソースファイル送信装置に送信する第３の送信手段とを具備し、実行ファイル受信装置は、公開鍵を暗号化プログラム配布装置宛てに送信する暗号化鍵送信手段と、暗号化プログラム配布装置から送信された実行ファイルを受信する第２の受信手段と、公開鍵に対応した秘密鍵を用いて、第２の受信手段で受信した実行ファイルを復号化する第２の復号化手段と、不具合情報を送信する第３の送信手段を具備する。
【００４４】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して詳細に説明する。
【００４５】
（実施例１）
図1において 101 はソフトウェア開発者のコンピュータでありソースファイル送信装置(以下、単に開発者と記す場合もある)、102 はソフトウェア配布者のコンピュータであり暗号化プログラム配布装置 (以下、単に配布者と記す場合もある)、 103 はソフトウェア利用者のコンピュータであり実行ファイル受信装置（以下、単にユーザと記す場合もある）をそれぞれ表す。
【００４６】
これらのコンピュータはそれぞれネットワーク105 に接続され、通信が可能であるものとする。ネットワーク 105 がインターネットの場合、コンピュータからネットワークへの接続は、直接の接続であってもよいし、プロキシサーバ等を通じた間接的接続であっても良い。さらに 認証局104もネットワーク 104 に接続されている。
【００４７】
ここで図2、図3に基づいて本実施例の概略を簡単に説明する。
【００４８】
配布者はユーザ秘密情報保護のガイドライン（秘密情報操作規約など）を公開しており(201,301)、開発者はそのガイドラインを取得し(302-303)、それにしたがってアプリケーションプログラム（ソフトウエア）を作成する(202, 304)。
【００４９】
次に開発者は配布者とオンラインで契約(305〜308)を結び、作成したソースコードを配布者に提出する(203, 309〜311)。配布者はプログラムをコンパイルし、暗号化したロードモジュール（実行ファイル）を作成する(204, 312)。暗号化ロードモジュールは配布者のみが知る暗号化鍵で暗号化される。また、コンパイル完了後にはソースコードは安全な場所に保管される。
【００５０】
暗号化ロードモジュールは、ユーザの持つコンピュータのCPUに対応する復号化鍵を添付されてユーザへと配布される(205-206, 313〜315)。配布されたプログラムをユーザが利用(316)してプログラムに不具合を発見した場合、配布者の元へその不具合が生じたときのメモリ上プログラムイメージ（不具合情報）が送られる(208, 317-318)。
【００５１】
配布者はこのプログラムイメージからあらかじめ開発者が申告したプライバシー情報（秘密情報）に相当する部分（秘密情報格納領域）の情報を抜き取って(319)、開発者へプログラムイメージを送付する(209, 220-221)。開発者はこの情報に基づいてプログラムのデバッグを行う(322)。
【００５２】
プログラムが不正な動作をしている可能性が高いとみなされるとき、配布者はプログラムのソースファイルを審査し、不正がないことを確かめる。また、配布者、開発者、ユーザの処理の概略を示すフローチャートを 図4,5,6にそれぞれ示す。
【００５３】
次に配布者、開発者間の契約関係について説明する。配布者はネットワーク経由で、配布代行にあたっての倫理基準、ユーザ秘密情報保護の技術ガイドライン、契約条件やプログラム開発環境のなどの情報をネットワークを通じて公開している。ここではhtml 形式で記述されたこれらの配布代行条件情報が http サーバを通じて公開されているものとする。
【００５４】
配布者はある特定のプログラム開発環境(例: Linux)のみに対応するだけでもよいし、複数のプログラム開発環境(例: Linux, Windows)に対応していてそれらを選択できるようにしておいてもよい。開発者は複数の配布者から自分に適した開発環境に対応する配布者を選択する。
【００５５】
開発者は配布代行条件情報を web ブラウザによって取得しその内容を知る。そして、配布代行情報に基づいてプログラムを開発し、配布契約に必要な資料を準備する。
【００５６】
プログラムの開発が完了すると、開発者は配布者の web サーバにアクセスして、配布者との間で配布の契約を結び、プログラムのソースコードを提出して、引き換えにソースコード受領証を受け取る。
【００５７】
契約とソースコードの提出は、web クライアントによって行われ、開発者側で特別なプログラムやサーバ装置は必要としない。契約とソースコードの提出では、以下に述べる安全な署名ずみ契約条項の交換とソースコードの委託を保証する手順が用いられるが、開発者自身はこれら手順の詳細を意識することはなく、開発者はソースコードを用意し、 web ブラウザ画面上で締結したい契約の種類を選択して資料を送付するだけで完了する。
【００５８】
契約手順の実行は、開発者が配布者の web サーバ上に用意されたプログラム(例えば JavaScript 形式)を実行するだけでよい。一方、サーバ側では契約、ソースコード受領とその後に続く配布処理までが自動的に処理され、基本的には人間のオペレータの介入を必要としない。実際のシステムにおいては必要に応じてそれぞれの手順において、オペレータが介入してもよい。
【００５９】
契約の完了時において、開発者と配布者はそれぞれ相手の署名がなされた契約条項を交換し、契約識別番号 CID を共有する。
【００６０】
ここで図７に示すようにプログラムの提出には以下の資料が必要である。
【００６１】
1)ロードモジュール作成に必要なソースコード一式(701)
2)取扱説明書(702)
3)秘密情報部分記述資料(703)
4)テスト用スクリプト(704)
この契約にあたっては、一般的な電子商取引の方法が適用できる。具体的には、認証局が配布者、開発者の身元を証明する公開鍵の証明書を発行しておき、配布者、開発者は自らの秘密鍵を安全に管理しておくことで、秘密鍵を持つ相手だけがメッセージを受信できるよう適切な暗号化を行うことで通信の安全を保つ。
【００６２】
さらに契約書面の交換にあたっては、認証局が契約書面の同時交換を行う手段を提供し、詐欺を防止してもよい。ここでは開発者、配布者、ユーザはそれぞれ自身の秘密鍵を安全に保持しており、公証局に身元情報と秘密鍵に対応する公開鍵とが登録されているものとする。
【００６３】
公証手順については、契約書面の同時交換が達成できればよく、必ずしも公証局の存在を前提とするものでなくともよい。例えば文献  岡本、山本著「現代暗号」1997  産業図書で知られる秘密情報段階的交換プロトコルなどを使用してもよい。資料と署名の交換が完了すると、ロードモジュールの配布までは基本的に配布者のサーバ内で処理が行われる。
【００６４】
次にプログラムの審査とこのプログラムのコンパイルに関し説明する。
【００６５】
配布者は提出されたプログラムを形式的に審査する。審査は具体的には次のようにプログラム部分と変数を機械的に抽出する。
【００６６】
1) プログラム中から GUI によってユーザにプライバシー情報の入力を促し、入力結果が格納されるプログラム中の変数のリスト。
【００６７】
2) プログラム中からシステムのデータベースやレジストリにアクセスしてユーザのプライバシー情報を取得し、その結果が格納されるプログラム中の変数のリスト。
【００６８】
これらの情報が格納される部分は後述の不具合情報のフィードバックの際にフィードバック情報から削除されることになる。配布者は審査の結果と、開発者から申告されたプライバシー情報(303)を照合し、一致すればプログラムをコンパイルする。一致しない場合、エラーとして開発者に通知する。
【００６９】
なお、上記 1), 2) と同等の効果を得るプログラムの記述方法は他にも多数あるが、ここでは契約条件において、プライバシー情報を扱う場合にはあらかじめ配布者が指定した形式の記述方法をとることが開発者の義務として盛り込まれているものとする。
【００７０】
もし配布者が、開発者によるプライバシー情報取得の隠蔽を意図的と判断した場合、契約違反として以後の処理を中止し、契約条件に定められた違約時の処理を行う。
【００７１】
つぎに審査が完了すると配布者は提出されたプログラムをコンパイルして、平文ロードモジュール(図8)を作成する。この段階で作成されたロードモジュールはまだ暗号化されていない。
【００７２】
実行コードにはこの後の処理で暗号化される部分(803Pe)と実行時にリロケーションなどの操作を可能にする暗号化されない部分(802Pp)がある。
【００７３】
なお、プログラムの全てについてソースファイルが必要というわけではなく、汎用のライブラリ関数などすでに安全性が配布者で検証された機械語ライブラリなどがロードモジュールにリンクされてもよい。
【００７４】
次に暗号化ロードモジュールの内容を図９に示す。平文ロードモジュールから暗号化ロードモジュールを作成するときは、暗号化対象部分(803Pe)を、を契約に対して配布者が決めたプログラム暗号化鍵（共通鍵） Kx#CID により共通鍵暗号アルゴリズム、たとえば DES アルゴリズムで暗号化し、フィードバック情報904 と契約識別子 CID 905 とを加えて、901〜905 の内容についてハッシュ関数 H[] を計算した結果にプログラム暗号化鍵 Kx#CID で署名した署名 906  を加えた形式が暗号化ロードモジュールとなる。ハッシュ関数はたとえば MD5, SHA1などを使えばよい。
【００７５】
契約識別子 CID は後述する配布者によるユーザのプライバシー情報を除去の際にその範囲を決定するために用いられる。フィードバック情報には不具合情報の送り先が含まれる。ここでは送り先は配布者のURI(Universal Resource Indicator)で記述されるものとする。
【００７６】
ロードモジュールの最後の部分、復号化鍵 907は、プログラム暗号化鍵 Kx#CIDを、プログラムを実行するユーザの実行ファイル受信装置（ターゲットシステム）のＣＰＵ（耐タンパプロセッサなどん）の公開鍵 Kp により、公開鍵アルゴリズム、たとえば RSA アルゴリズムによって暗号化したもの(EKp[Kx#CID]である。
【００７７】
ターゲットシステムのプロセッサは 公開鍵 Kp に対応する秘密鍵 Ks を内部に持っているので、復号化鍵 907 (EKp[Kx#CID])を復号化して Kx#CID をとりだし、暗号化プログラム部分 903 を復号化して実行することができる。
【００７８】
一方、実行ファイル受信装置（ターゲットシステム）を所有するユーザもしくはアドミニストレータは、公開鍵 Kp に対応する秘密鍵 Ks を知らないので直接暗号化プログラム部分 903 を復号化することはできない。ＣＰＵでのプログラムの復号化はチップの中で行われるのでユーザが復号化されたプログラムを盗みとることは不可能であり、プログラムの秘密は守られる。
【００７９】
また、特願2000-35898に記載されたマイクロプロセッサでは、実行中のプログラムが扱うデータについても保護機構が設けられており、ユーザによるデータの盗み読みを防ぐことができる。これらの秘密の保護はプログラムの暗号化鍵 Kx#CID の秘密性に基づいており、逆に Kx#CID がわかれば、メインメモリ中の暗号化されたプログラム、データ、実行状態（レジスタ情報）を読みとることにより、暗号化プログラム  903 も、プログラムが扱うデータも暗号化前の状態に復元することができる。
【００８０】
この原理に基づいて、後述の不具合情報の解析が行われる。このようにプログラムの暗号化により、プログラム自身とそれが扱うデータの秘密をターゲットシステムのユーザから効果的に守ることができるが、一方であるプログラムがターゲットシステムまたはユーザにとって危険なものかどうかを、プログラムの実行前にも実行後にも判断する材料がなくなってしまう。
【００８１】
本発明では、信頼できるプログラム配布者が審査済みのプログラムを配布することにより、この潜在的なユーザの危険を排除する効果がある。以上がプログラムのコンパイルと暗号化ロードモジュールの作成手順である。
【００８２】
ここで前述の過程においてコンパイルに失敗した場合は、開発者にエラーの内容が通知され、開発者はソースファイルを修正して再度ソースファイル委託 309 のシーケンスからやりなおすことになる。
【００８３】
そして、コンパイル後の平文ロードモジュール、それに暗号化を行った暗号化モジュールのそれぞれについて配布者が、開発者の用意した自動化されたテスト用スクリプトに基づいた試験を行い、その結果が条件を満たさない場合も、開発者にはエラーの内容が通知され、開発者はやはりソースファイルの不具合を修正して再度ソースファイル供託 309 のシーケンスからやりなおす。
【００８４】
これで配布前の暗号化ロードモジュールが完成したが、最後にもう一度、開発者による完成したロードモジュールのテストを行ってもよい。この場合、配布者から開発者に暗号化ロードモジュールが配布されると、開発者はロードモジュールを実行するターゲットシステムのCPUに対応する復号化鍵を、配布者に請求する。
【００８５】
この手順については、ユーザへのプログラム配布と同様であり、例えばこれらの一実現方法は特開平10-269078 に開示されている。ダウンロード後、開発者によるテストが配布者に通知され、配布者は通知結果が合格ならばそのまま次のユーザへの配布へと処理を進め、不合格であれば、開発者が再びソースファイル供託 209 のシーケンスからやりなおす。
【００８６】
このテストにより、開発者は配布者の環境におけるコンパイルオプションや暗号化によるプログラムへの性能の影響を実際にユーザの手に渡るものと同じロードモジュールで検証することができる。
【００８７】
ところで配布者と開発者との間の契約は、305-308 の間で締結されており、配布の手数料などもそこで決定される。このとき、ソースファイル検査、コンパイルなどのサーバ負荷を配布手数料に反映させるため、ソースファイル供託を行った回数などに応じて配布手数料を増加させてもよい。
【００８８】
配布者はプログラムが法律や配布業者が定める公序良俗に関する規定に違反がないことを、主に人間によるプログラムの機能と説明書の検査によって確認してもよい。
【００８９】
このようにして全ての検査を終えた暗号化ロードモジュールと配布用説明書と契約に対応する暗号化鍵 Kx#CID は配布者サーバの安全な場所に保存される。ここではプログラム暗号化鍵 Kx#CID は契約毎に１つ発行されるものとする。
【００９０】
開発者がプログラムの秘密を守るため、プログラム暗号化鍵  Kx#CID を更新したり、あるいはプログラムの不具合修正やバージョンアップを配布プログラムに反映させるときは契約を再度行うことになる。もちろん、このような継続契約には審査の簡易化や料金の割引などの規則を設けてもよい。
【００９１】
次にこのプログラムの配布に関し説明する。
【００９２】
暗号化ロードモジュールの作成が完了すると続けて配布の準備が始まる。まずダウンロード画面のhtml 形式記述が用意される。
【００９３】
ブラウザのダウンロード画面で CID に対応するソフトウェアのダウンロードを意味するリンクが選択されると、ユーザのブラウザにそのリンクが指定するサーバに置かれたJava script がダウンロードされ、実行されてプログラムがダウンロードされる。
【００９４】
プログラムのダウンロードにあたっては、上記暗号化鍵 Kx#CID によって暗号化されたプログラムと、その鍵 Kx#CID をユーザ側コンピュータ 103 のプロセッサの公開鍵 Kp#u で暗号化した暗号化鍵情報 E[Kp#u][Kx#CID] をユーザに配布しなければならない。ここで E[X][Y] はあるデータ Y の鍵 X による暗号化を表す。
【００９５】
このとき、暗号化鍵情報を生成するための Kp#u は、プログラムの秘密保護とプログラムが正しく実行されるために、実在するプロセッサに対応するものでなければならない。プロセッサの公開鍵 Kp#u を確認してプログラムをダウンロードする方法の一例は特願2000-35898 に開示されている。
【００９６】
ブラウザのダウンロード画面で契約識別子 CID に対応するソフトウェアのダウンロードを意味するリンクがユーザによって選択されると、それに対応する Java script がユーザのブラウザユーザ側のJava script では図に示す手順が実行され、プロセッサの公開鍵が要求される。一方、配布者側では Java script から発行されたダウンロード要求により、 315 のダウンロード手順が実行される。
【００９７】
このダウンロード手順が完了すると、ユーザに対する課金処理が実行される。web サーバ、クライアント間の安全な課金処理の手順は既にさまざまなものが知られている。例えば特開平10-269078 に開示されている方法である。課金処理はダウンロード処理より先、または処理の間に開始されてもよい。もちろん、配布するファイルが無料で配布されるものであれば課金手続きの必要はない。
【００９８】
次に暗号化ロードモジュールと暗号化鍵情報がダウンロードされ、それらはユーザシステム上で一体となった実行ファイルとして格納される。暗号化ロードモジュールはユーザのシステムで、特願2000-35898に開示されているようにターゲットプロセッサによって復号化、実行され、ユーザによって利用される。
【００９９】
次に配布したプログラムにバグ（不具合）があった場合、この情報を開発元へフィードバックする方法について説明する。
【０１００】
プログラムは機能が複雑であるほど不具合、いわゆるバグを含んでいることが普通である。ユーザの使用状況で発生したバグを修正して、プログラムの完成度を高めることはプログラムの品質を向上させる上で不可欠の作業である。
【０１０１】
ユーザの使用時に発生したプログラムの不具合を解析する手段の代表は、不具合が発生した時のプログラムのメモリイメージ、いわゆるコアダンプを解析する方法である。
【０１０２】
不正なアドレスの参照など、プログラムの実行継続が不可能となったり、不具合を示す兆候があったとき、メモリ上のイメージをファイルに保存し、解析する機構はさまざまなOSに備えられている。こうして保存されたメモリイメージを、開発者が解析することで、不具合の原因を解析し、不具合をなおすことができる。
【０１０３】
だが、このメモリイメージには、ユーザのプライバシーに属する情報、例えば個人の住所録や健康状態、クレジットカード番号などが含まれている可能性がある。このような情報を含むプライバシー情報は、社会的信用と厳密な監査体制の団体にのみ取り扱いが許されるべきだが、一般に優秀なプログラムの開発元が必ずしも社会的信用と厳密な監査体制を備えている場合は稀と言える（ここでの監査体制とはユーザ情報の不正利用に対する監査体制であって、企業会計における監査を意味するものではない）。
【０１０４】
メモリイメージが直接開発元に送られた場合、そこに含まれるユーザのプライバシー情報が取り出され、不正に使用される可能性は開発者が厳密な監査体制を持たない限り排除できない。
【０１０５】
ここで考えうる一つの解決方法は、ユーザのシステムから不具合情報を送付するとき、プライバシー情報を削除してしまうことである。配布されたプログラムの中に、予めユーザのプライバシー情報が格納されるメモリ上の領域を指定する情報、（ここでは秘密情報格納領域の識別子と呼ぶ）を格納しておき、その情報に基づいて不具合を発生したプログラム自身、あるいはユーザ側システムが、そのメモリ領域の情報を削除したメモリイメージを作成し、不具合情報として、送付先に送るものである。
【０１０６】
この削除はユーザのシステムで行われるので、この削除手順がユーザの意図に反して妨害されることはないと考えてよい。ただし、秘密情報格納領域の識別子が正しいことが、削除手順が正しく行われることの前提となる。この可能性は、信頼できるプログラム配布者が、秘密情報格納領域の識別子に対して署名を行っておくことにより排除できる。
【０１０７】
ユーザはプライバシー情報の削除の前に署名を検証し、もし改変が行われている場合は不具合情報の送付をやめる。
【０１０８】
この場合のロードモジュール形式を図16に示す。秘密情報格納領域の識別子 SECはその先頭アドレス（Saddr）と終了アドレス(Eaddr)の組として定義され、記号1608 で示されている。そして SEC を含むロードモジュール全体の配布者による署名 1606 によって、秘密情報格納領域の識別子の改変を防いでいる。
【０１０９】
また別の方法としては次の方法が考えられる。プログラムの不具合情報を以下の手順により一度厳密な監査体制を持つ配布者に送り、そこでプライバシー情報を削除してから開発者に不具合情報を転送する。
【０１１０】
プログラムの動作に不具合が生じた場合、次の２つの方法によってその時のプログラムの内部状態を配布者に送信する。
【０１１１】
（１） プログラム自身による異常状態の検出と、プログラム内部状態の配布者への送信。
【０１１２】
（２）記憶装置に保存されたプログラムイメージの、ユーザシステムによる配布者への送信。
【０１１３】
前者の場合、不具合が検出されるとあらかじめプログラムに組み込まれた通知手続きが呼出され、プログラムの内部状態が配布者に送信される。
【０１１４】
この宛先はプログラムのコンパイル時に配布者によって指定され、直接開発者に内部状態が送信されることはない。プログラムはメモリ上で暗号化された上に、さらに配布者の公開鍵によって暗号化されて送信される。
【０１１５】
後者の場合、ユーザシステムはフィードバック情報 504 の宛先にプログラムイメージを送る。メモリイメージには図9の元プログラムが添付されるものとする。
【０１１６】
このとき、署名が検証され、宛先が正しいかどうか検証される。さらに宛先に対応する証明書を認証局に要求し、その暗号化鍵でプログラムイメージを暗号化して送ればより安全である。
【０１１７】
プログラムイメージを受け取った配布者は、ネットワーク転送のための暗号を復号化した後、契約識別子 905に基づいて配布者の持つデータベースからそのプログラムの暗号化鍵 Kx#CID を検索し、プログラムとデータを復号化する。プログラムにはCPU対応のプログラム復号化鍵 907 が含まれているが、対応するプロセッサのみがそれを復号化可能であり、配布者はこれを復号化することができないことに注意が必要である。
【０１１８】
ここで、配布者のシステムではやはり契約識別子からデータベースに保存されたプライバシー情報の場所をとりだし、プログラムイメージから当該部分のデータを値０で置き換えるなどして消去する。
【０１１９】
そしてプライバシー情報の削除が完了したら、復号化した状態のプログラムイメージを開発者へと送信する。開発者はそれを自身の秘密鍵で復号化し、解析してプログラムの不具合を修正するために使う。
【０１２０】
次にこれらの不具合情報に対する奨励金支払い方法について説明する。
【０１２１】
開発者はより多くの不具合情報を集めるため、ユーザによる不具合情報の提供に報奨金を与えることができる。開発者はあらかじめ不具合情報の提供に対してどのような報奨金を与えるかについての定義を配布者に提出し、契約を行っておく。
【０１２２】
たとえばあるソフトウェアに対する不具合情報を提供すると、その配布者のサイトで使用できる電子的な商品券がユーザに与えられるなどである。つまり、報奨金は実際の貨幣でなくてよい。もちろん、銀行口座に直接報奨金が振り込まれてもよいが、このような報奨金は非常に定額であり、銀行取り引きの手数料に見合う金額ではないことを考慮する必要がある。
【０１２３】
次に不具合情報の選別について説明する。
【０１２４】
報奨金が比較的高額な場合にはまた別の問題が発生する。同一の不具合を複数回送って、多数の報奨金を得ようとするユーザが多くなることである。このような事態が起きると開発者は報奨金の支払いにもかかわらずプログラムを改善するための材料を得ることができないことになる。
【０１２５】
このような事態を防止するため、配布者のサーバに既知の不具合のパターンを記憶しておき、既知の不具合に対応する場合には報奨金を減額する方法をとることができる。ある条件、たとえば変数の値が0の時に不具合が発生することがわかっていれば、その条件に合致する不具合情報の報奨金を減額する。
【０１２６】
ただし、この場合、既知不具合情報をあらかじめ配布者のサーバに掲示しておき、それらに該当する場合には報奨金は減額されることを公開しておくことが望ましい。
【０１２７】
不具合情報の送信では、ユーザの側にもプログラムイメージ送信の際の通信帯域の占有や通信料といった負担が生じる。また、いわゆるプライバシー情報以外にも、プログラムがエディタの場合には編集中の文書全体秘密であるなど、ユーザにとって不具合情報の送信が望ましくない場合がある。プログラムによる不具合情報の送信の際には送信前にユーザの許可を求めることが望ましい。
【０１２８】
次に開発者がソフトウエアのバージョンアップを行う場合を説明する。
【０１２９】
開発者がソフトウェアのバージョンアップを行う場合は、配布者との新たに配布者と契約を行う。その際、オプションとして前回の契約ＩＤを入力することにより、配布手数料の割引などの措置を受けられるとともに、ユーザへのダウンロード方法紹介画面の識別子(URL)に前のバージョンと同じ名前を使うことができる。プログラムは再度コンパイルされ、暗号化鍵  Kx#CID は契約識別子(CID)ごとに新たな値が割り当てられ、暗号化ロードモジュールが作られる。
【０１３０】
バージョンアップのほかに、暗号が破られた場合も契約を新たにやり直す。当然プログラムの暗号化鍵 Kx#CID は変更される。
【０１３１】
その外、配布手数料、使用回数・時間課金などの条件を変更する場合も新たに契約をやりなおし新たにロードモジュールを作成する。ただし、フィードバック情報に対する報奨金の金額や除外リストの変更ではロードモジュールは変更されない。
【０１３２】
次にプログラムの暗号化鍵の決定について説明する。
【０１３３】
本実施例では、プログラムの暗号化部分 903 は、プログラムのコンパイル完了直後に決定された暗号化鍵 Kx#CID によって暗号化されることとなっており、たとえば複数のユーザからプログラムのダウンロード要求があったときは、暗号化プログラム部分 903 は共通だが、復号化鍵 908 はターゲットのＣＰＵ毎に異なる実行ファイルが作られ、ユーザに送られる。
【０１３４】
この手順では、暗号化部分 903 の暗号化処理はプログラムコンパイル直後に一度だけ行われ、ユーザによるダウンロード要求の都度暗号化処理をやりなおす必要はない。
【０１３５】
だが、本発明の実施にあたっては、暗号化鍵 Kx#CID を決め、プログラムを暗号化する手順はかならずしも上記の順序に限定されなくてもよい。
【０１３６】
たとえばユーザのプログラムのダウンロード要求を受け取ってからプログラム暗号化鍵を決定して、暗号化部分 903 の暗号化と、復号化鍵 908 の作成を行ってもよい。
【０１３７】
(実施例２)
実施例１では配布者システムが直接公衆ネットワークに接続されている例を示した。実施例１における配布者システムにはプログラムのソースファイルや、実行プログラムを暗号化して保護するための暗号化鍵 Kx#CID, プログラム上のプライバシー情報の領域などの秘密情報あるいは契約情報のような改竄を防止する必要のある情報が保存されている。
【０１３８】
これらの情報が公衆ネットワーク 105 を通じた攻撃によって読み出されたり、改変されることを防がなければならない。
【０１３９】
そこで、実施例２では配布者システムが図10に示すような、ファイアウォールによりフロントエンドとバックエンドのサーバが分離された構成をとり、ネットワークからの攻撃を防いでいる。
【０１４０】
図10にしたがって本実施例での動作を説明する。配布者は開発者向けサーバ 1004により配布条件情報を公開している。開発者システム 101 は配布条件情報の入手と契約を開発者向けサーバ 1004 との通信により実行する。
【０１４１】
開発者向けサーバは配布条件情報を内部に保持しており、配布者のその他のサーバとは独立に配布を実行する。だが、開発者からの契約の要求は配布者のバックエンドサーバ 1001 に転送され、そこで開発者の身元証明の確認や契約条件の確認、契約終了後の契約文書の保管などの処理が行われる。配布者バックエンドサーバは開発者向けサーバからの要求のみを受け付けるように構成されている。
【０１４２】
そして、バリアセグメント 1007 と配布者システム内部セグメント 602 を接続するファイアウォール  1003 はバリアセグメント 1007 におかれた配布者のサーバ、開発者向けサーバ 1004, 不具合情報受け付けサーバ 1005 、ダウンロードサーバ 1006 以外の要求は転送しない。配布者システムの外部、たとえば開発者 101 やユーザ 103 が直接配布者バックエンドサーバに要求を発行することはできない。
【０１４３】
開発者向けサーバを通じて配布者バックエンドシステムはソースファイルをうけとり、審査してコンパイル、暗号化して配布可能な暗号化ロードモジュールを作成する。そして、配布のために作成された html ドキュメントはダウンロードサーバ 1006 に転送され、公開される。
【０１４４】
ユーザシステム 103 はダウンロードサーバに指定ドキュメントのダウンロード要求を発行し、ダウンロードサーバにシステムの CPU の公開鍵 Kp の証明書を提示する。ダウンロードサーバはバックエンドサーバにダウンロード要求を転送し、暗号化されたロードモジュールに、CPU の公開鍵 Kp で暗号化された ロードモジュール暗号化鍵  EKp[Kx#CID] を添付したファイルを作成する。ダウンロードサーバはこのファイルをユーザにダウンロードする。
【０１４５】
ユーザはユーザシステムでプログラムを実行し、不具合があった場合には不具合情報受け付けサーバに不具合情報を送る。ロードモジュールのフィードバック情報 504 には不具合情報受け付けサーバの URI が書かれている。
【０１４６】
不具合情報受け付けサーバは不具合情報と送信元のユーザ情報をバックエンドサーバに送り、不具合情報の契約 ID からプライバシー情報の領域を決定し、その領域の情報を消去して、開発元へ送付する。
【０１４７】
このように、実施例２の実施形態ではネットワーク外部からの要求を直接受け付けるサーバと、秘密情報を保持するバックエンドサーバを分離することにより、秘密情報をより安全に管理することができる。
【０１４８】
（実施例３）
プログラムの使用権を売り切りで販売するのではなく、実行回数や実行時間によって使用料金を徴収する方法がある。このような目的を実現するにあたっては、プログラム提供側と利用者の双方にとって安全かつ安価なシステムが求められる。プログラム提供側にとっては不正にただで利用されず、利用者側にとっては第３者による不正な課金を防ぐことである。
【０１４９】
使用料を管理する最も単純な方法は、プログラム提供者が課金情報を管理するサーバを運用し、ユーザが実行するプログラムはサーバとの接続なしでは動作しないようにすることである。
【０１５０】
だが、このようなシステムでは次の２つの点が利用者側の不安となる。
【０１５１】
（１）課金は正しく行われるか。
【０１５２】
（２）課金サーバの停止によりソフトウェアが使用不能になるおそれ
これらは課金サーバの運用に対する信頼の問題といえるが、すでに述べたような監査体制の場合と同じように、一般にプログラムの開発元がサーバの運用に十分な経験と管理体制を備えているとはいえない。この問題を解決するため、課金サーバの管理を配布者が代行する実施例を説明する。
【０１５３】
図７が本実施例の構成である。実施例２との違いは配布者システムに課金サーバ 1208 が追加されたことである。以下、実施例１、２との変更点についてのみ説明する。
【０１５４】
まず契約の開始時において開発者は使用料金の徴収代行と料金条件を契約条件として選択する。そして開発者はプログラム中で配布者が用意する課金関数が呼出されるようにプログラムを開発する。
【０１５５】
配布者は提出されたプログラムを審査し、課金関数の呼出しが正しく行われているかを検査する。検査に合格すると、配布者が用意した課金関数がリンクされた暗号化ロードモジュールが作成される。課金関数は悪意のユーザによって改変されないように暗号化領域に置かれる。
【０１５６】
ロードモジュールの案内情報には利用回数、時間による課金が行われることが記述されている。ロードモジュールのダウンロード時に、配布者は課金契約IDを含む、課金の同意を求める同意書をユーザに送付し、ユーザはその同意書にユーザの（ＣＰＵのではなく）秘密鍵で署名してダウンロードサーバに返送する。
【０１５７】
ダウンロードサーバは署名をバックエンドサーバに転送し、バックエンドサーバは図9の暗号化ロードモジュール基本形式に、ユーザ情報 1308 を追加した、図13の形式の暗号化ロードモジュールファイルを作成する。追加された課金契約情報 1308 は、課金契約 ID と1301〜1307 と課金契約IDに対するハッシュから成る。
【０１５８】
ダウンロードされたプログラムが実行され、課金関数が呼出されると、課金関数は課金契約情報 1308 のハッシュを検証し、正しければ課金サーバへの接続を行い、課金要求をしてソフトウェアの正常実行を継続する。
【０１５９】
もし課金契約が別なソフトウェアのものにすりかえられていたり、改変されていた場合、課金関数はハッシュの検証に失敗し、ソフトウェアの実行は停止される。このようにユーザの課金情報書き換えによる意図的な課金の回避が防止されている。
【０１６０】
同時に、実行ファイルのうちでユーザごとに書き換えの必要な部分を1306〜1308に限定することでサーバ側のファイル書き換えの負荷を軽減している。
【０１６１】
（実施例４）
上記のようなプログラムの監査を行っても、ユーザの秘密情報を盗み取るようなプログラムを完全に排除することは困難である。したがって、実際にそのプログラムを使用して発生したトラブルの解決を支援する機構が必要となる。それは同時にユーザのプライバシーと開発者のプログラムの秘密が守られるものでなければならない。
【０１６２】
まず単独の配布者がユーザからのフィードバック情報によって得たデータに基づいて監査を行う例を説明する。配布者はユーザからフィードバック情報として不具合情報とともにコメントや苦情なども受け付ける。
【０１６３】
これらの情報はバックエンドサーバ内のデータベースに蓄積される。また、ソフトウェアを使用しているユーザに定期的にアンケートを取り、「最近SPAM(受信者の意志を無視して送られる広告などのメール)が多くなった」、「個人情報が漏れていると感じる」などの情報を事前に収集してもよい。
【０１６４】
これらの苦情のうち悪質かつ因果関係が容易に推定できるもの、たとえばある健康管理ソフトウェアを使っているユーザの健康状態が漏れて、医療機関のダイレクトメールが届く、あるいは生命保険への加入を断られるなどの場合は、配布者が供託されたソースコードを検査し、不審な部分がないかどうかを検査する。もしプライバシー情報が不正に取り扱われている場合、配布者は配布を中止して、ユーザに通知を行う。
【０１６５】
一般には、苦情とソフトウェアとの因果関係が不明確な場合が覆いと予想される。このような場合でも、ソフトウェアに不正が組み込まれている可能性があるため、苦情内容毎の件数とソフトウェア利用との間に因果関係がある場合、相関の高いものから調査が行われ、不正なソフトウェアが配布されないよう配布業者は管理を行う。
【０１６６】
苦情内容毎の件数とソフトウェア利用との間になんらかの関係があるかどうかを推定する手法は現在データベースの機能としてさまざまなものが利用可能であり、説明を省略する。
【０１６７】
（実施例５）
上記の例ではソフトウェアのフィードバック情報収集とソフトウェアの監査を配布業者が行うこととしていた。だが、ソフトウェアの配布と監査とはある場合には利害が相反する業務である。たとえばあるソフトウェア配布業者で多くの配布手数料を稼いでいるソフトウェアにユーザのプライバシー侵害のおそれがあったとき、その監査に消極的になることは想像に難くない。
【０１６８】
本実施例では図１４、１５および図１３に基づいて監査業者が不具合情報を回収する実施例を説明する。
【０１６９】
監査業者が入った場合でもダウンロード  1506 までのシーケンスは配布者のみの場合と同じである。違いはユーザがダウンロード要求をするとき、監査業者を契約書に指定し自らの契約書に秘密鍵で署名する。
【０１７０】
配布者は指定された監査業者のアドレスがロードモジュール中のフィードバック情報  1304 として格納された暗号化ロードモジュールを作成し、ユーザに配布する。ユーザは配布業者とは関わりなく複数の監査業者の中から好きな業者を選択することができる。
【０１７１】
ユーザで不具合があったときに不具合情報をフィードバック情報の送り先に送るのは前の例と同じである。その後、監査業者でのプライバシー情報の削除には２通りの方法がある。
【０１７２】
監査業者でフィードバック情報を復号化する場合
始めに監査業者でフィードバック情報を復号化する場合について説明する。この場合、監査業者は契約IDに対応する復号化鍵とプライバシー情報領域情報を配布業者に要求する。監査業者はフィードバック情報を復号化してプライバシー情報領域を削除し、開発者へフィードバック情報を送る。
【０１７３】
この方法では監査業者はロードモジュールの平文実行コードの全てとユーザのプライバシー情報の全てを平文で見ることができるため、監査業者が自主的に機械語レベルでの監査行為を行うことができるが、監査業者のプログラムやプライバシー情報の取り扱いに厳密性が求められる。
【０１７４】
次に監査業者でロードモジュールを復号化しない場合を説明する。
【０１７５】
第２の方法は、監査業者がフィードバック情報を復号化することなく、プライバシー領域情報のみをうけとり、フィードバック情報が暗号化された状態でプライバシー領域の情報の削除を行う。
【０１７６】
したがって、この場合はあらかじめプライバシー領域の暗号化は他の領域と関係を持たないような変数は位置、暗号ブロック方式、暗号アルゴリズムが選択されている必要がある。
【０１７７】
この方法では監査業者は配布業者の強力な死には平文の機械語プログラムを解読することができないため、自主的な監査行為は制限される。
【０１７８】
ただ、どちらの方法をとっても最初はすでに説明したようなユーザの苦情などに基づいて状況証拠を収集し、不正の疑いが濃い場合は配布業者にそれらの状況証拠を提示してソースファイルの開示を求める。監査業者には限定された強制捜査権が与えられ、状況証拠に基づいて配布業者に対してソースファイルの開示を強制でキルとしてもよい。
【０１７９】
開示されたソースファイルを検査するのは監査業者であり、不正が発見された場合、配布業者に配布の停止とユーザへのアナウンスを求める。そのソフトウェアによって被害を受けた専門的な知識をもたないユーザに代わってそのソフトウェアの開発者に対する賠償要求などを代行してもよい。
【０１８０】
もし監査の結果、そのソフトウェアに不正がないことがわかった場合、監査業者は配布業者にあらかじめ定められた手数料を支払う。監査業者は監査のために開示されたソースファイルに対して守秘義務を追うのは当然である。
【０１８１】
次にリバースエンジニアリングの権利について説明する。
【０１８２】
ソフトウェアのリバースエンジニアリングは技術の共有化のために広く認められた権利である。特に、ソフトウェアの作成元がメンテナンスを放棄したソフトウェアの不具合を修正する場合などには不可欠な技術である。
【０１８３】
特にいわゆる西暦２０００年問題では１０〜２０年ほど前に作られたコンピュータプログラムをリバースエンジニアリングによって補修した事例が多く見られた。ところが、耐タンパマイクロプロセッサ上のアプリケーションではソフトウェアを解析することは暗号学的に不可能である。
【０１８４】
ソフトウェアの作成元が解散するなどして、ソースコードが行方不明になったりした場合、耐タンパマイクロプロセッサでは機械語を解析することは原則としてできない。
【０１８５】
プロセッサの秘密鍵管理団体がプロセッサの秘密鍵を開示することにより、暗号化された機械語プログラムを平文に戻すことは、そのプロセッサ上で動作する他のプログラムをも危険にさらすことになり、現実的ではない。
【０１８６】
このような場合、配布機関に供託されたソースコードが役に立つ。あるソフトウェアの保守を行いたい者は、そのソフトウェアの作成元が連絡不能であることを確認してソースコードを一般に公開する。
【０１８７】
公開されたソースコードに基づいてソフトウェアの保守を希望するものはその作業を行う。また、配布業者は著作権法上の保護期間を経過したソフトウェアのソースコードを公開して、技術の共有化を促進する。
【０１８８】
これらの作業によって、耐タンパマイクロプロセッサの使用を前提とした場合でもソフトウェアの保守と技術の共有という目的をリバースエンジニアリングという手段をとることなく行うことができる。
【０１８９】
【発明の効果】
以上詳細に説明したように、本発明によれば、耐タンパプロセッサに暗号化されたプログラムを配布する場合でも、実行ファイルの安全が確保できるほか、バグ情報などの不具合情報をユーザーから、プログラム配布装置を介してプログラム作成者へ伝えることができる。
【０１９０】
また、配布したプログラムの不具合情報を提供したユーザに対して、このプログラム毎に報奨を決定することができる。
【図面の簡単な説明】
【図１】  本発明の一実施例のネットワーク構成図
【図２】  本発明の一実施例のシステム間の関係図
【図３】  本発明の一実施例のシーケンス図
【図４】  本発明の一実施例の配布者システムのフローチャート
【図５】  本発明の一実施例の開発者システムのフローチャート
【図６】  本発明の一実施例のユーザシステムのフローチャート
【図７】  本発明の一実施例の提出情報説明図
【図８】  本発明の一実施例の平文ロードモジュール説明図
【図９】  本発明の一実施例の暗号化ロードモジュール説明図
【図１０】  本発明の一実施例のネットワーク構成図
【図１１】  本発明の一実施例のシステム間の関係図
【図１２】  本発明の一実施例のネットワーク構成図
【図１３】  本発明の一実施例の暗号化ロードモジュール説明図
【図１４】  本発明の一実施例のネットワーク構成図
【図１５】  本発明の一実施例のシステム間の関係図
【図１６】  本発明の一実施例のロードモジュール説明図
【符号の説明】
101・・・ソースファイル送信装置
102・・・暗号化プログラム配布装置
103・・・実行ファイル受信装置
104・・・ネットワーク
105・・・認証局
【図１】
0004067757.tif 000002
【図２】
0004067757.tif 000003
【図３】
0004067757.tif 000004
【図４】
0004067757.tif 000005
【図５】
0004067757.tif 000006
【図６】
0004067757.tif 000007
【図７】
0004067757.tif 000008
【図８】
0004067757.tif 000009
【図９】
0004067757.tif 000010
【図１０】
0004067757.tif 000011
【図１１】
0004067757.tif 000012
【図１２】
0004067757.tif 000013
【図１３】
0004067757.tif 000014
【図１４】
0004067757.tif 000015
【図１５】
0004067757.tif 000016
【図１６】
0004067757.tif 000017