(57)【特許請求の範囲】
【請求項１】
ＪａｖａＳｃｒｉｐｔ処理の動作を監視するＪａｖａＳｃｒｉｐｔ側タイマと、
アプリケーションフレームワーク処理に時間を割り当てるためのアプリケーション側タイマとを具備し、
前記ＪａｖａＳｃｒｉｐｔ側タイマは、
前記ＪａｖａＳｃｒｉｐｔ処理の累積消費時間が閾値となる第１の累積消費時間を超えた場合に、前記アプリケーション側タイマを起動させる起動手段を具備し、
前記アプリケーション側タイマは、
前記ＪａｖａＳｃｒｉｐｔ側タイマにより起動されると、処理を前記アプリケーションフレームワーク処理に渡すとともに、前記アプリケーションフレームワーク処理の累積消費時間が閾値となる第２の累積消費時間を超えた場合に、処理を前記ＪａｖａＳｃｒｉｐｔ側タイマに渡すアプリケーション側切替手段を具備し、
前記ＪａｖａＳｃｒｉｐｔ側タイマは、さらに、
前記アプリケーション側切替手段により処理が渡された場合、前記渡された処理を前記ＪａｖａＳｃｒｉｐｔ処理に戻すＪａｖａＳｃｒｉｐｔ側切替手段を具備する、
情報処理装置。
【請求項２】
前記ＪａｖａＳｃｒｉｐｔ側タイマは、
ＪａｖａＳｃｒｉｐｔを受け取り、実行するＪａｖａＳｃｒｉｐｔエンジンから前記ＪａｖａＳｃｒｉｐｔ側タイマがチェックされる毎に、前記ＪａｖａＳｃｒｉｐｔ処理の消費時間が加算される、請求項１記載の情報処理装置。
【請求項３】
前記アプリケーション側切替手段により、前記ＪａｖａＳｃｒｉｐｔ側タイマによる前記ＪａｖａＳｃｒｉｐｔ処理の動作の監視に切り替えた場合、前記ＪａｖａＳｃｒｉｐｔ側タイマ及び前記アプリケーション側タイマをクリアする、請求項１記載の情報処理装置。
【請求項４】
前記第１の累積消費時間及び前記第２の累積消費時間のうちの少なくとも１つは、前記情報処理装置のリソースに基づいて定められる、請求項１記載の情報処理装置。
【請求項５】
前記ＪａｖａＳｃｒｉｐｔ側タイマ及び前記アプリケーション側タイマは、ブラウザに設けられている、請求項１記載の情報処理装置。
【請求項６】
ＪａｖａＳｃｒｉｐｔ処理の動作を監視するＪａｖａＳｃｒｉｐｔ側タイマと、
アプリケーションフレームワーク処理に時間を割り当てるためのアプリケーション側タイマとを具備する情報処理装置のリソース制御方法において、
前記ＪａｖａＳｃｒｉｐｔ側タイマの具備する起動手段が、前記ＪａｖａＳｃｒｉｐｔ処理の累積消費時間が閾値となる第１の累積消費時間を超えた場合に、前記アプリケーション側タイマを起動させ、
前記アプリケーション側タイマの具備するアプリケーション側切替手段が、前記ＪａｖａＳｃｒｉｐｔ側タイマにより起動されると、処理を前記アプリケーションフレームワーク処理に渡すとともに、前記アプリケーションフレームワーク処理の累積消費時間が閾値となる第２の累積消費時間を超えた場合に、処理を前記ＪａｖａＳｃｒｉｐｔ側タイマに渡し、
前記ＪａｖａＳｃｒｉｐｔ側タイマの具備するＪａｖａＳｃｒｉｐｔ側切替手段が、さらに、前記アプリケーション側切替手段により処理が渡された場合、前記渡された処理を前記ＪａｖａＳｃｒｉｐｔ処理に戻す、
リソース制御方法。
【請求項７】
前記ＪａｖａＳｃｒｉｐｔ側タイマは、
ＪａｖａＳｃｒｉｐｔを受け取り、実行するＪａｖａＳｃｒｉｐｔエンジンから前記ＪａｖａＳｃｒｉｐｔ側タイマがチェックされる毎に、前記ＪａｖａＳｃｒｉｐｔ処理の消費時間が加算される、請求項６記載のリソース制御方法。
【請求項８】
コンピュータを、請求項１乃至請求項５いずれか１項に記載の情報処理装置が具備する前記ＪａｖａＳｃｒｉｐｔ側タイマ及び前記アプリケーション側タイマとして機能させるための、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソースの制御を行なうことができる情報処理装置に関する。
【背景技術】
【０００２】
図３は、従来のブラウザを説明するための図である。
【０００３】
同図に示すように、従来のブラウザは、ＪａｖａＳｃｒｉｐｔ（登録商標）エンジン１、レンダリングエンジン２、画面表示・ＵＩ部３及びアプリケーションフレームワーク４を有している（例えば、非特許文献１参照）。
【０００４】
ＪａｖａＳｃｒｉｐｔエンジン１は、ＪａｖａＳｃｒｉｐｔの解析、機械語変換、処理実行を行い、レイアウトを動的に変更するインタプリタである。ＪａｖａＳｃｒｉｐｔエンジン１は、レンダリングエンジン２の命令を受けて駆動される。
【０００５】
レンダリングエンジン２は、ブラウザの主処理部分であり、ＷＥＢサーバ１１からWebコンテンツ取得、HTML/CSS解析、レイアウト・描画等の処理を行なう。
【０００６】
画面表示・ＵＩ部３は、レイアウト情報を取得し、画面表示を行なう。また、ユーザからの入力を待ちうける。
【０００７】
アプリケーションフレームワーク（App FW）４は、Qt, Gtk+等、イベント駆動のプログラミング機構を与え、NW処理や描画処理等を容易に開発可能にするフレームワークである。
【０００８】
ブラウザはユーザの命令を待ちうけ、Webページを読込み、解析し、画面表示を行なうソフトウェアである。
【０００９】
まず、ユーザからの命令（ページ読込やスクロール等）を画面表示・ＵＩ部３にて受け取り、レンダリングエンジン２の所定の関数を呼び出す。レンダリングエンジン２は新たなページの読込が必要な場合、外部のWebサーバ１１とHTTP通信を行いHTMLや画像をはじめとするWebコンテンツを構成するデータをダウンロードする。
【００１０】
レンダリングエンジン２は、ダウンロードが完了したデータから解析を行い、レイアウト情報を抽出する。同時に、ＪａｖａＳｃｒｉｐｔを抽出し、ＪａｖａＳｃｒｉｐｔエンジン１に渡す。ＪａｖａＳｃｒｉｐｔエンジン１は、図４に示すように、ＪａｖａＳｃｒｉｐｔを解析して、機械語の命令リストに変換し（Ｓ１）、その先頭から順番に実行する（Ｓ２）。Ｓ２における命令の実行は、リストの先頭の命令が１つ実行されるごとに、リストから先頭の命令が削除されることを意味する。
【００１１】
そして、その実行結果として、レンダリングエンジン２が保持するレイアウト情報を書き換えることができる。レイアウト情報は変更があるたびに画面表示・ＵＩ部３に渡され、画面描画が行なわれる。
【００１２】
これらの処理の際、ユーザ入力の処理・データのダウンロード・解析・レイアウト処理・画面描画などがそれぞれ並行して処理される。これにはApp FW４のイベント駆動機構が用いられる。
【００１３】
具体的にはレンダリングエンジン２や画面表示・ＵＩ部３にてApp FW４のイベントキューに必要な処理を登録し、App FW４が定期的にキュー内の処理を実行していくことで実現している。
【００１４】
Ｓ２において、命令が実行されると、次に、未実行命令があるか否かの判断が行われる（Ｓ３）。Ｓ３において、未実行命令がないと判断された場合には、ＪａｖａＳｃｒｉｐｔ処理を終了する。一方、未実行命令があると判断された場合には、Ｓ２の処理に移る。
【００１５】
情報処理端末上で、ブラウザによるWeb閲覧を行なう際、ＪａｖａＳｃｒｉｐｔの処理が複雑なページを表示させると動作が遅くなりユーザ体感品質が低下する。これは、従来のブラウザではＪａｖａＳｃｒｉｐｔの処理に割くＣＰＵリソース量に制限が無く、閲覧するページによってはＪａｖａＳｃｒｉｐｔ処理が多くのCPUリソースを占有し、端末のＣＰＵリソースの不足が生じるためである。
【００１６】
このような問題を解決するため、ブラウザにおける過度なＪａｖａＳｃｒｉｐｔ処理によるCPU消費を抑制する技術がある。具体的には、ＪａｖａＳｃｒｉｐｔエンジンで使用しているＣＰＵ時間が一定時間以上になった場合にコールバックを呼ぶことにより、ＪａｖａＳｃｒｉｐｔの負荷の重いページを閲覧して動作が固まってしまったときに、ユーザにＪａｖａＳｃｒｉｐｔを停止させる選択肢を与えるものである（例えば、非特許文献２参照）。
【００１７】
また、上記課題を解決するため、 ブラウザにおける処理をマルチスレッドで動作させる技術もある（例えば、非特許文献３参照）。
【先行技術文献】
【非特許文献】
【００１８】
【非特許文献１】A. Grosskurth and M. W. Godfrey, "A reference architecture for Web browsers“, Proceedings of the 21st  IEEE International Conference on Software Maintenance (ICSM’05), P. 661 (2005).
【非特許文献２】JavaScript Core, https://github.com/aosm/ＪａｖａＳｃｒｉｐｔCore/blob/master/runtime/Watchdog.h
【非特許文献３】Compositor Thread Architecture , http://www.chromium.org/developers/design-documents/compositor-thread-architecture
【発明の概要】
【発明が解決しようとする課題】
【００１９】
しかしながら、従来のブラウザでは、停止させること無く柔軟にＪａｖａＳｃｒｉｐｔ処理のCPUリソース消費量を制御することは難しいという問題があった。
【００２０】
本発明は上記実情に鑑みてなされたものであり、ＪａｖａＳｃｒｉｐｔの動作を制限し、ユーザからの入力処理やレンダリング処理等にＣＰＵリソースを割り当てることにより、ユーザ体感を向上することができる、情報処理装置、情報処置装置のリソース制御方法及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明の第１の観点によれば、ＪａｖａＳｃｒｉｐｔ処理の動作を監視するＪａｖａＳｃｒｉｐｔ側タイマと、アプリケーションフレームワーク処理に時間を割り当てるためのアプリケーション側タイマとを具備し、前記ＪａｖａＳｃｒｉｐｔ側タイマは、前記ＪａｖａＳｃｒｉｐｔ処理の累積消費時間が閾値となる第１の累積消費時間を超えた場合に、前記アプリケーション側タイマを起動させる起動手段を具備し、前記アプリケーション側タイマは、前記ＪａｖａＳｃｒｉｐｔ側タイマにより起動されると、処理を前記アプリケーションフレームワーク処理に渡すとともに、前記アプリケーションフレームワーク処理の累積消費時間が閾値となる第２の累積消費時間を超えた場合に、処理を前記ＪａｖａＳｃｒｉｐｔ側タイマに渡すアプリケーション側切替手段を具備し、前記ＪａｖａＳｃｒｉｐｔ側タイマは、さらに、前記アプリケーション側切替手段により処理が渡された場合、前記渡された処理を前記ＪａｖａＳｃｒｉｐｔ処理に戻すＪａｖａＳｃｒｉｐｔ側切替手段を具備する、情報処理装置、である。
【００２２】
本発明の第２の観点によれば、第１の観点において、前記ＪａｖａＳｃｒｉｐｔ側タイマは、ＪａｖａＳｃｒｉｐｔを受け取り、実行するＪａｖａＳｃｒｉｐｔエンジンから前記ＪａｖａＳｃｒｉｐｔ側タイマがチェックされる毎に、前記ＪａｖａＳｃｒｉｐｔ処理の消費時間が加算される、情報処理装置である。
【００２３】
本発明の第３の観点によれば、第１の観点において、前記アプリケーション側切替手段により、前記ＪａｖａＳｃｒｉｐｔ側タイマによる前記ＪａｖａＳｃｒｉｐｔ処理の動作の監視に切り替えた場合、前記ＪａｖａＳｃｒｉｐｔ側タイマ及びアプリケーション側タイマをクリアする、情報処理装置である。
【００２４】
本発明の第４の観点によれば、第１の観点において、前記第１の累積消費時間及び前記第２の累積消費時間のうちの少なくとも１つは、前記情報処理装置のリソースに基づいて定められる、情報処理装置である。
【発明の効果】
【００２５】
本発明によれば、ＪａｖａＳｃｒｉｐｔの動作を制限し、ユーザからの入力処理やレンダリング処理等にＣＰＵリソースを割り当てることにより、ユーザ体感を向上することができる。
【図面の簡単な説明】
【００２６】
【図１】本実施の形態に係るブラウザの構成を示す図である。
【図２】本実施の形態のブラウザの動作について説明するためのフローチャートである。
【図３】従来のブラウザを説明するための図である。
【図４】従来のブラウザの動作について説明するためのフローチャートである。
【発明を実施するための形態】
【００２７】
＜本発明の実施の形態の概要＞
上述のように、従来のブラウザでは、外部から処理ごとにCPUリソース消費量を制御することは難しい。そこで、本発明は、内部にタイマを設置し、ＪａｖａＳｃｒｉｐｔ処理とその他の処理のCPUリソース消費を個別に制御する仕組みを実現する。
【００２８】
そして、このタイマを利用し、ＪａｖａＳｃｒｉｐｔ処理の消費するCPUリソースを制限することで、上記課題を解決し、ユーザ体感品質を向上させる。
【００２９】
本実施形態では、非特許文献１のアーキテクチャにリソース制御を行なう手段を追加することにより、非特許文献３のようにマルチスレッド化を行なうことなく、シングルスレッドのままで簡易にリソースを配分する。
＜実施の形態＞
以下、実施の形態について、図面を参照して説明する。
【００３０】
図１は、本実施の形態に係るブラウザの構成を示す図である。なお、図３と同一部分には、同一符号を付して説明する。同図において、本実施の形態のＪａｖａＳｃｒｉｐｔ側タイマ２１、App側タイマ２２及びタイマ制御モジュール２３は、ブラウザ内に設けられている。
【００３１】
ＪａｖａＳｃｒｉｐｔエンジン１は、ＪａｖａＳｃｒｉｐｔの解析、機械語変換、処理実行を行い、レイアウトを動的に変更するインタプリタである。ＪａｖａＳｃｒｉｐｔエンジン１は、レンダリングエンジン２の命令を受けて駆動される。
【００３２】
実施形態のＪａｖａＳｃｒｉｐｔエンジン１には、定期的にＪａｖａＳｃｒｉｐｔ側タイマ２１のチェックを行なうチェックポイント１ａが設けられる。チェックポイント１ａは、処理中に頻繁に呼ばれる関数内に設置される。
【００３３】
レンダリングエンジン２は、ブラウザの主処理部分であり、ＷＥＢサーバ１１からWebコンテンツ取得、HTML/CSS解析、レイアウト・描画等の処理を行なう。
【００３４】
画面表示・ＵＩ部３は、レイアウト情報を取得し、画面表示を行なう。また、ユーザからの入力を待ちうける。
【００３５】
App FW４は、Qt, Gtk+等、イベント駆動のプログラミング機構を与え、NW処理や描画処理等を容易に開発可能にするフレームワークである。
【００３６】
ＪａｖａＳｃｒｉｐｔ側タイマ２１は、ＪａｖａＳｃｒｉｐｔの動作を監視するタイマであり、消費したCPU時間が一定時間以上になったらタイムアウトし、App側タイマ２２を呼び出す。
【００３７】
App側タイマ２２は、App FW４用に時間を割り当てるためのタイマであり、一定時間、ＪａｖａＳｃｒｉｐｔに時間を渡さないようにApp FW４のイベント処理に時間を割り当てる。App FW４は、App FW４のイベントキューが空の場合は、短い時間sleepし再度App FW４に時間を割り当てる。前記時間割り当てを繰り返し、累積時間が一定時間以上になったらタイムアウトし、ＪａｖａＳｃｒｉｐｔ側タイマを呼び出す。
【００３８】
タイマ制御モジュール２３は、情報処理端末のリソース状況を測定し、ＪａｖａＳｃｒｉｐｔ側タイマ２１および  App側タイマ２２のタイムアウト値を制御する。
【００３９】
次に、本実施の形態のブラウザの動作について、図２のフローチャートを参照して説明する。本実施の形態のブラウザの動作は、従来のブラウザの動作に加え、ＪａｖａＳｃｒｉｐｔエンジン１の処理実行時に独自の動作を行なう。ＪａｖａＳｃｒｉｐｔエンジン１は、レンダリングエンジン２からＪａｖａＳｃｒｉｐｔを受け取り実行する。
【００４０】
ＪａｖａＳｃｒｉｐｔエンジン１は、ＪａｖａＳｃｒｉｐｔ処理が開始されると、ＪａｖａＳｃｒｉｐｔを解析して、機械語の命令リストに変換する（Ｓ１１）。次に、ＪａｖａＳｃｒｉｐｔ側タイマ２１により、ＪａｖａＳｃｒｉｐｔ処理時間のカウントが開始される（Ｓ１２）。
【００４１】
その後、ＪａｖａＳｃｒｉｐｔ側タイマ２１は、ＪａｖａＳｃｒｉｐｔ処理時間がタイムアウト時間を超えているか否かの判断を行なう（Ｓ１３）。Ｓ１３において、ＪａｖａＳｃｒｉｐｔ処理時間がタイムアウト時間を超えていると判断された場合、ＪａｖａＳｃｒｉｐｔ側タイマ２１は、App側タイマ２２をスタートさせる。App側タイマ２２は、ある一定時間をApp FW４に処理時間として与え、カウントを開始する（Ｓ１４）。
【００４２】
具体的には、上述のように、ＪａｖａＳｃｒｉｐｔエンジン１内で定期的に呼ばれる関数内に、ＪａｖａＳｃｒｉｐｔ側タイマ２１をチェックする処理が加えられている。ＪａｖａＳｃｒｉｐｔ側タイマ２１は、チェックされる度に消費CPU時間を加算して行き、累積消費CPU時間がタイムアウト時間（閾値）以上になったらApp側タイマ２２をスタートさせてカウントを開始させる。
【００４３】
App FW４の処理が終了した際、App側タイマ２２は消費時間を加算していく。Ｓ１４における処理の後、App側タイマ２２は、累積消費時間がタイムアウト時間（閾値）以上であるか否かの判断を行なう（Ｓ１５）。
【００４４】
Ｓ１５において、累積消費時間がタイムアウト時間（閾値）以上ではないと判断された場合、App側タイマ２２は短時間のsleepを行った後、再びApp FW４に一定時間処理時間を与え、App FW４の処理を実行させ（Ｓ１６）、Ｓ１５の処理に戻る。
【００４５】
一方、Ｓ１５において、累積消費時間がタイムアウト時間（閾値）以上であると判断された場合、Ｓ１２の処理に戻る。この場合、App側タイマ２２は、タイマをクリアし、再びＪａｖａＳｃｒｉｐｔ側タイマに処理を戻す。App側タイマ２２からＪａｖａＳｃｒｉｐｔ側タイマ２１に処理が戻ってきたら、ＪａｖａＳｃｒｉｐｔ側タイマ２１は、タイマをクリアし、ＪａｖａＳｃｒｉｐｔエンジン１に処理を戻すとともにカウントを開始する。
【００４６】
一方、Ｓ１３において、ＪａｖａＳｃｒｉｐｔ処理時間がタイムアウト時間を超えていないと判断された場合には、Ｓ１１において作成された命令を実行し（Ｓ１７）、未実行命令があるか否かの判断が行われる（Ｓ１８）。
【００４７】
Ｓ１８において、未実行命令があると判断された場合には、Ｓ１３の処理に移り、未実行命令がないと判断された場合には、ＪａｖａＳｃｒｉｐｔ処理を終了する。
【００４８】
タイマ制御モジュール２３は、ＪａｖａＳｃｒｉｐｔ側タイマ２１のタイムアウト時間（閾値）、App側タイマ２２のタイムアウト時間（閾値）、App側タイマ２２のスリープ時間を制御することが可能である。これにより、ＪａｖａＳｃｒｉｐｔエンジンとその他の処理に消費される時間を制御できる。タイマ制御モジュール２３は、情報処理端末のリソース状況（情報処理端末内の余剰CPUリソース量）を測定し、この測定されたリソース状況に基づいて、これらのパラメータ（タイムアウト時間、スリープ時間）を最適化し、ユーザ体感品質を向上させることができる。
【００４９】
測定するリソース状況としては、CPU情報（コア数、クロック、キャッシュ）、CPU使用率、ロードアベレージ、コンテキストスイッチ数などがある。例えば、コア数とCPU使用率、ロードアベレージからCPUリソース量を把握するようにしてもよい。パラメータの最適化手法としては、CPUリソースの余剰量が増えていればＪａｖａＳｃｒｉｐｔ側のタイマに与える時間を増やし、減っていれば App側のタイマに与える時間を増やすようにしてもよい。
【００５０】
なお、タイマ制御モジュール２３の最適化ロジックは、下記のポリシに基づいて決定しても良い。
【００５１】
画面更新間隔を例えば、16fpsとすると、約60ms毎に入力と出力が一通り終了すればユーザにとって動作の遅れは認識できない。即ち、ＪａｖａＳｃｒｉｐｔのタイムアウト実時間＋AppFW４のタイムアウト実時間の和が更新間隔以下になり、かつAppFW４の全ての処理が終了しているという条件が成り立つ。すると、最適な時間配分は、AppFW４終了までの実時間とＪａｖａＳｃｒｉｐｔエンジン１のタイムアウト時間の和が画面更新間隔以下ということが成り立つ。
【００５２】
しかし、AppFW４の処理量が多いばあいや他のプロセスによる処理量が多い場合は当てはまらないであろう。これらの場合は、AppFW４の処理を優先して行なう。実際には、AppFW４の処理量は推測することしかできないため、その処理時間から適応的な処理を行なうことになる。
【００５３】
即ち、予想よりAppFW４の処理が多ければ、次のＪａｖａＳｃｒｉｐｔ側タイマ２１のタイムアウト時間は短く、AppFW４の処理が少なければ反対にＪａｖａＳｃｒｉｐｔ側タイマ２１のタイムアウト時間を長く取れば良い。
【００５４】
従って、本実施の形態によれば、Ｗｅｂページを読込み、画面表示を行うブラウザにおいて、ＪａｖａＳｃｒｉｐｔ処理の動作を制御するＪａｖａＳｃｒｉｐｔ側タイマ２１とアプリケーションフレームワーク（App FW）４の処理の動作を制御するApp側タイマ２２とを設ける。
【００５５】
そして、ＪａｖａＳｃｒｉｐｔ処理の実行中には、ＪａｖａＳｃｒｉｐｔ側タイマ２１が、定期的にチェックされる度にＣＰＵ消費時間を加算し、ＣＰＵ消費時間の累積値が閾値以上になった時にApp側タイマ２２を起動するとともに、処理の実行をＪａｖａＳｃｒｉｐｔ処理からApp FW処理に移行させる。
【００５６】
App FW４の処理の実行中には、App側タイマ２２が、App FW４の処理が終了する度にＣＰＵ消費時間を加算し、ＣＰＵ消費時間の累積値が閾値以上になった時にＪａｖａＳｃｒｉｐｔ側タイマ２１を起動するとともに、処理の実行をApp FW４の処理からＪａｖａＳｃｒｉｐｔ処理に移行させる。これにより、ＪａｖａＳｃｒｉｐｔ処理が複雑なページを表示させる際のユーザ体感品質の低下を防ぐことができる。
【００５７】
なお、本発明の装置はコンピュータプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを介して提供することも可能である。また、本発明の実施形態を説明したが、実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００５８】
１…ＪａｖａＳｃｒｉｐｔエンジン  １ａ…チェックポイント  ２…レンダリングエンジン  ３…画面表示・ＵＩ部  ４…アプリケーションフレームワーク（App FW）  １１…ＷＥＢサーバ  ２１…ＪａｖａＳｃｒｉｐｔ側タイマ  ２２…App側タイマ  ２３…タイマ制御モジュール。
【図１】
0006295193.tif 000002
【図２】
0006295193.tif 000003
【図３】
0006295193.tif 000004
【図４】
0006295193.tif 000005