(57)【要約】【課題】複数アプリケーション間でリソースを効率的に且つ柔軟に割り付け可能とし、矛盾のなくリソースの排他使用を実現する。【解決手段】アプリケーションＡＰＰ１がリソースを使用しているとき、アプリケーションＡＰＰ２からリソースの取得要求を受け取る（ステップＳ５）と、リソースマネージャ（ＲｅｓＭａｎ）は、アプリケーションＡＰＰ１とＡＰＰ２のリソースの競合判定を行い（ステップＳ６）、優先度の低いアプリケーションＡＰＰ２には取得ＮＧの通知を返す（ステップＳ７）。アプリケーションＡＰＰ２からリソースの開放通知要求（ステップＳ９）を受け取った後、アプリケーションＡＰＰ１から開放完了通知（ステップＳ１１）を受け取ると、リソースマネージャは、他にリソースの競合（ステップＳ１５）がなければ、アプリケーションＡＰＰ２に対してリソースの取得完了通知を発行（ステップＳ１６）する。【選択図】  図５
2005004350.tif 000002
【特許請求の範囲】
【請求項１】
処理手段から送られてくるリソースの取得要求を、受付手段が受け付けるステップと、
上記処理手段からの取得要求に対応するリソースと、他の処理手段で使用するリソースとが競合するかを、競合判定手段が判定するステップと、
上記競合判定手段にてリソースが競合すると判定された各処理手段のうち、何れの処理手段に対してリソースの使用許可を与えるかを、決定手段が決定するステップと、
上記リソースの使用許可が与えられなかった処理手段から、そのリソースの開放通知要求を受け取ったとき、リスト登録手段が、当該開放通知要求に対応するリソースと当該処理手段とを対応付けてリストに登録するステップと、
上記リソースの使用許可が与えられた処理手段から当該リソースの開放完了通知を受け取ったとき、リスト確認手段が、当該開放されたリソースに対応した開放通知要求を行っている処理手段を上記リストから確認するステップと、
上記リスト確認手段が上記リストから確認した処理手段に対して、当該リソースの取得が完了したことを通知するための取得完了通知を、通知発行手段が発行するステップとを有する
ことを特徴とするリソース管理方法。
【請求項２】
請求項１記載のリソース管理方法であって、
上記決定手段が上記リソースの使用許可を決定するステップでは、上記処理手段毎に予め設定されている優先度に基づいて上記リソースの使用許可を与えるか否かの決定を行うことを特徴とするリソース管理方法。
【請求項３】
請求項１記載のリソース管理方法であって、
上記受付手段が上記リソースの取得要求を受け付けるステップでは、所望の処理を実行するのに必要とされる一以上のリソースをまとめた所定機能単位で、上記リソースの取得要求を受け付け、
上記競合判定手段がリソースの競合を判定するステップでは、上記所定機能単位毎にリソースの競合を判定し、
上記決定手段が上記リソースの使用許可を決定するステップでは、上記所定機能単位毎にリソースの使用許可を与えるかの決定を行い、
上記リスト登録手段が上記リストの登録を行うステップでは、上記所定機能単位毎に上記リストへの登録を行い、
上記リスト確認手段が上記リストの確認を行うステップでは、上記所定機能単位毎に上記リストの確認を行い、
上記通知発行手段が上記取得完了通知を発行するステップでは、上記所定機能単位毎に上記取得完了通知を発行することを特徴とするリソース管理方法。
【請求項４】
請求項３記載のリソース管理方法であって、
上記決定手段が上記リソースの使用許可を決定するステップでは、上記所定機能単位毎に予め設定されている優先度に基づいて上記リソースの使用許可を与えるかの決定を行うことを特徴とするリソース管理方法。
【請求項５】
処理手段から送られてくるリソースの取得要求を受け付ける受付手段と、
上記処理手段からの取得要求に対応するリソースと、他の処理手段で使用するリソースとが競合するかを判定する競合判定手段と、
上記競合判定手段にてリソースが競合すると判定された各処理手段のうち、何れの処理手段に対してリソースの使用許可を与えるかを決定する決定手段と、
上記リソースの使用許可が与えられなかった処理手段から、そのリソースの開放通知要求を受け取ったとき、当該開放通知要求に対応するリソースと当該処理手段とを対応付けてリストに登録するリスト登録手段と、
上記リソースの使用許可が与えられた処理手段から当該リソースの開放完了通知を受け取ったとき、当該開放されたリソースに対応した開放通知要求を行っている処理手段を上記リストから確認するリスト確認手段と、
上記リスト確認手段が上記リストから確認した処理手段に対して、当該リソースの取得が完了したことを通知するための取得完了通知を発行する通知発行手段とを有する
ことを特徴とするリソース管理装置。
【請求項６】
請求項５記載のリソース管理装置であって、
上記決定手段は、上記処理手段毎に予め設定されている優先度に基づいて上記リソースの使用許可を与えるか否かの決定を行うことを特徴とするリソース管理装置。
【請求項７】
請求項５記載のリソース管理装置であって、
上記受付手段は、所望の処理を実行するのに必要とされる一以上のリソースをまとめた所定機能単位で、上記リソースの取得要求を受け付け、
上記競合判定手段は、上記所定機能単位毎にリソースの競合を判定し、
上記決定手段は、上記所定機能単位毎にリソースの使用許可を与えるか決定し、
上記リスト登録手段は、上記所定機能単位毎に上記リストへの登録を行い、
上記リスト確認手段は、上記所定機能単位毎に上記リストの確認を行い、
上記通知発行手段は、上記所定機能単位毎に上記取得完了通知を発行することを特徴とするリソース管理装置。
【請求項８】
請求項７記載のリソース管理装置であって、
上記決定手段は、上記所定機能単位毎に予め設定されている優先度に基づいて上記リソースの使用許可を与えるかの決定を行うことを特徴とするリソース管理装置。
【請求項９】
処理手段から送られてくるリソースの取得要求を受け付ける受付手段と、
上記処理手段からの取得要求に対応するリソースと、他の処理手段で使用するリソースとが競合するかを判定する競合判定手段と、
上記競合判定手段にてリソースが競合すると判定された各処理手段のうち、何れの処理手段に対してリソースの使用許可を与えるかを決定する決定手段と、
上記リソースの使用許可が与えられなかった処理手段から、そのリソースの開放通知要求を受け取ったとき、当該開放通知要求に対応するリソースと当該処理手段とを対応付けてリストに登録するリスト登録手段と、
上記リソースの使用許可が与えられた処理手段から当該リソースの開放完了通知を受け取ったとき、当該開放されたリソースに対応した開放通知要求を行っている処理手段を上記リストから確認するリスト確認手段と、
上記リスト確認手段が上記リストから確認した処理手段に対して、当該リソースの取得が完了したことを通知するための取得完了通知を発行する通知発行手段として
コンピュータを機能させることを特徴とするリソース管理プログラム。
【請求項１０】
処理手段から送られてくるリソースの取得要求を受け付ける受付手段と、
上記処理手段からの取得要求に対応するリソースと、他の処理手段で使用するリソースとが競合するかを判定する競合判定手段と、
上記競合判定手段にてリソースが競合すると判定された各処理手段のうち、何れの処理手段に対してリソースの使用許可を与えるかを決定する決定手段と、
上記リソースの使用許可が与えられなかった処理手段から、そのリソースの開放通知要求を受け取ったとき、当該開放通知要求に対応するリソースと当該処理手段とを対応付けてリストに登録するリスト登録手段と、
上記リソースの使用許可が与えられた処理手段から当該リソースの開放完了通知を受け取ったとき、当該開放されたリソースに対応した開放通知要求を行っている処理手段を上記リストから確認するリスト確認手段と、
上記リスト確認手段が上記リストから確認した処理手段に対して、当該リソースの取得が完了したことを通知するための取得完了通知を発行する通知発行手段として
コンピュータを機能させるリソース管理プログラムが記憶されたコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電子機器のハードウェア資源の割り当てを管理するリソース管理方法及び装置、リソース管理プログラム、記憶媒体に関する。
【０００２】
【従来の技術】
従来より、複数の実行タスクによるハードウェア資源（以下、単にリソースとする）の利用要求が競合している場合、当該リソース要求の競合を回避するための方式としては、例えば、予め決められた優先度のみでリソースの使用権を制限する方式（以下、第１の方式とする）、一度に動作可能なアプリケーションを制限する、いわゆるシングルタスク方式（以下、第２の方式とする）、一度にリソースを利用できるのは先にリソースを取得した一つのアプリケーションだけと割り切る先取り方式（以下、第３の方式とする）、ハードウェアを抽象化した階層（レイヤー）をソフトウェアにより実現することで仮想的にリソースの同時アクセスを可能にする方式（以下、第４の方式とする）などが考えられている。
【０００３】
なお、ハードウェア資源の割り付けを行う例として、特許文献１に記載された技術が知られている。この特許文献１には、マルチタスク処理において、資源への処理依頼の輻輳度に応じて待ち時間を調整することで資源の優先割り付けを行うこと、つまり、優先度の低い処理依頼を輻輳度に応じて可変的に遅らせるようにすることで優先度の高い処理依頼に対して資源を優先的に割り付ける資源割り付け方式についての技術が記載されている。
【０００４】
【特許文献１】
特開平９−１６４１６号公報（第１図）
【０００５】
【発明が解決しようとする課題】
しかしながら、上述した第１の方式と第２の方式は、共に、アプリケーションの動作制限が発生してしまうため好ましくなく、そのためより動作制限の少ない方式が望まれる。第３の方式は、リソース要求の優先度がシステム内で均一でなければならず、例えば優先度に差が設けられていてもその優先度の差は無視されてしまう。また、第３の方式において、例えば優先度に応じたリソース割り付けを行う場合には、ユーザの責任による優先度の管理が必要にってしまう。第４の方式は、パーソナルコンピュータのようなハイパフォーマンス環境が必須となってしまい、例えば携帯電話端末のような限られた機能と性能しか有さないものにとっては処理負担が大きすぎる。
【０００６】
本発明は、このような実情に鑑みて提案されたものであり、複数アプリケーション間でハードウェア資源を効率的に且つ柔軟に割り付け可能とし、矛盾のなくリソースの排他使用を実現できる、リソース管理方法及び装置、リソース管理プログラム、記憶媒体を提供することを目的とする。
【０００７】
【課題を解決するための手段】
本発明は、処理手段から送られてくるリソースの取得要求を受け付け、処理手段からの取得要求に対応するリソースと他の処理手段で使用するリソースとが競合するかを判定し、競合すると判定された各処理手段のうち何れの処理手段に対してリソースの使用許可を与えるかを決定し、リソースの使用許可が与えられなかった処理手段から、そのリソースの開放通知要求を受け取ったとき、その開放通知要求に対応するリソースと当該処理手段とを対応付けてリストに登録し、リソースの使用許可が与えられた処理手段から当該リソースの開放完了通知を受け取ったとき、その開放されたリソースに対応した開放通知要求を行っている処理手段をリストから確認し、リストから確認された処理手段に対して、当該リソースの取得が完了したことを通知するための取得完了通知を発行する。
【０００８】
また、本発明によれば、リソースの取得要求の受け付け、リソースの競合判定、リソースの使用許可の決定、リストへの登録、リストの確認、取得完了通知の発行は、それぞれ、所望の処理を実行するのに必要とされる一以上のリソースをまとめた所定機能単位毎に行う。
【０００９】
すなわち本発明によれば、リソースを最終的に取得するのは処理手段であるが、リソースの競合判定や使用許可、リソースの使用権利についての管理をリソース管理装置が行う。また、リソースを取得できなかった処理手段は、そのリソースが開放されたときにその旨を知らせてもらうための開放通知を要求することができる。リソース管理装置は、リソースを使用していた処理手段がそのリソースを開放したとき、そのリソースについて開放通知要求を行っている処理手段が存在する場合には、その処理手段に対して、リソースの開放がなされたことを通知するために取得完了通知を発行する。
【００１０】
【発明の実施の形態】
以下、本発明の好ましい実施の形態について、図面を参照しながら説明する。
【００１１】
本発明の具体的な構成を説明する前に、本発明にかかるリソース管理の概要を説明する。
【００１２】
本発明において、ハードウェアリソース（資源、リソース）の管理は、ファンクションと呼ぶ単位で行われる。ファンクションは、本発明にかかる処理手段に相当するアプリケーションが所望する処理を実現するために使用される、一以上のリソース（以下、使用リソースとする）をまとめた機能単位であり、リソース管理の最小の管理単位である。具体例を挙げて説明すると、ファンクションは、例えば圧縮動画像の再生機能や、デジタルカメラ撮影機能等のように、電子機器の各機能毎に設定されているものである。例えば、上記圧縮動画像の再生機能のファンクションの場合は、当該圧縮動画像を再生をする上で必要な各リソースである、圧縮動画データを例えばメモリから読み出したり、通信回線を使用して取得するためのデータ取得用リソースや、その圧縮動画データを伸張する回路等の伸張処理用リソース、当該伸張処理後の再生動画像を表示するディスプレイ等の表示用リソース、同じく伸張処理後の再生音声を出力するスピーカ等の音声出力用リソースなどが、使用リソースとして設定されている。また、デジタルカメラ撮影機能のファンクションの場合は、当該デジタルカメラ撮影を行う上で必要なリソースである、デジタルカメラ部等の撮影用リソースや、撮影データを圧縮等するための回路等からなる圧縮処理用リソース、圧縮後の撮影データをメモリ等に記録するための回路等からなる記録用リソースなどが、使用リソースとして設定されている。なお、このファンクションのデータは、各使用リソースを例えば３２ビットのビットマップにより表す情報となされている。
【００１３】
図１には、各ファンクションと各リソースの対応関係テーブルを示す。なお、図１は各ファンクションとリソースを一般化して表しており、図１の縦列（縦軸）のＦＡ〜ＦＮはそれぞれ異なるファンクションを示し、横列（横軸）のＲＡ〜ＲＯはそれぞれ異なるリソースを表し、図中の丸印は縦列のファンクション内に当該丸印の付けられた横列のリソースが含まれていることを表している。すなわち図１の例の場合、ファンクションＦＡ〜ＦＤは使用リソースとしてそれぞれリソースＲＣが設定されており、ファンクションＦＥとＦＦは使用リソースとしてそれぞれリソースＲＢが設定され、以下同様に、ファンクションＦＧはリソースＲＨが、ファンクションＦＨはリソースＲＩが、ファンクションＦＩはリソースＲＥ，ＲＧ，ＲＩ，ＲＪ，ＲＬが、ファンションＦＪはリソースＲＡ，ＲＣ，ＲＤ，ＲＥが、ファンクションＦＫはリソースＲＦ，ＲＧ，ＲＩ〜ＲＬ，ＲＮが、それぞれ使用リソースとして設定されている。ファンクションＦＬ〜ＦＮの説明は省略する。
【００１４】
図２には、本発明にかかるリソース管理を実施する電子機器の概略構成を示す。本発明実施形態の電子機器は、本発明のリソース管理装置の機能を実現するリソースマネージャ１と、電子機器が実現可能な様々な処理を実行するためのソフトウェアであるアプリケーション４と、当該電子機器が備える様々なハードウェアであるリソース（ハードウェアリソース）６と、アプリケーション４からリソース６にアクセスする際のインターフェースであるリソースアクセスライブラリ５とを有している。
【００１５】
リソースマネージャ１は、本発明にかかるリソース管理を行う主要部であって、各アプリケーション４からアクセスが可能なリソース６の排他制御を行う部分であり、リソースマネージャプロセス部２と、リソースマネージャアクセスライブラリ３とを有する。リソースマネージャアクセスライブラリ３は、本発明にかかる受付手段や通知発行手段としての機能を有し、アプリケーション４からリソースマネージャプロセス部２にアクセスするためのインターフェースである。したがって、アプリケーション４は当該リソースマネージャアクセスライブラリ３を使い、リソースマネージャプロセス部２に対して例えばリソースの使用権利をリクエストしたり、リソースの開放を通知したりする。リソースマネージャプロセス部２は、本発明にかかる競合判定手段、決定手段、リスト登録手段、リスト確認手段としての各機能を有しており、ハンドル管理部８とリソース管理部７を備え、各ファンクション単位でのリソース管理を行う。ハンドル管理部８は、リソースハンドルとファンクションの対応を管理し、アプリケーション４から要求されたリソースに番号を割り当て、また、アプリケーション４がどのリソースを使用しているのかを管理するため、及び競合判定の際に使用すること等のためのリストを有する。リソース管理部７は、ファンクション単位でリソースの管理を行い、図１に示した各ファンクションと各リソースの対応関係テーブルを有する。すなわち、リソース管理部７は、何れのリソースとどのリソース番号がリンクしていて、ファンクションの単位で何れのリソースが対応しているのか、さらに、何れのアプリケーションに対してリソースの使用権利を与えたりすること等の管理を行う。なお、リソースマネージャ１内のリソースマネージャアクセスライブラリ３、ハンドル管理部８、リソース管理部７は、それぞれが相互に連携して動作するため、これ以降は、それらを区別せずに、リソースマネージャ１としてまとめて説明する。
【００１６】
この図２の構成において、上記アプリケーション４は、それぞれ一つ以上のファンクションを要求することが可能であり、当該ファンクションの要求により、そのファンクションの使用リソースの確保を、リソースマネージャ１へ要求する。そして、例えば二つ以上のアプリケーション４から、同時若しくは異なる時期に、上記ファンクションの要求による使用リソースの確保要求、つまり取得要求がなされた場合、リソースマネージャ１は、図１の対応関係テーブルにより、それらファンクション同士の使用リソースの同否を比較することによって、リソースの競合判定を行う。そして、リソースマネージャ１は、そのリソースの競合判定でリソースの競合が起きると判定した場合には、後述するリソース競合処理を行う。一方、リソースの競合が起こらないと判定した場合、リソースマネージャ１は、各アプリケーション４にそれぞれリソースの取得許可を与える。
【００１７】
ここで、リソースを取得する際、アプリケーション４は、取得したいリソースのファンクション名、優先度、リソースの取得要因、アクセスハンドル、プロセスＩＤの各情報を、リソースマネージャ１に対して指定する。上記優先度は、アプリケーション毎の優先度、ファンクション毎の優先度、リソース毎の優先度が、各アプリケーションにより適宜決められており、リソースマネージャ１は、それらの優先度の情報を、リソースの競合が発生した場合の競合制御に用いる。取得要因の情報は、リソースの確保が失敗した場合やリソース利用の権利の移動が発生した場合に、リソースマネージャ１が、そのリソースを使用するアプリケーション４に対して、当該リソース確保の失敗要因やリソース利用の権利移動の発生要因を知らせるために用いられる。ハンドルは、複数ファンクションを同時にアクセスするために用いられる情報である。プロセスＩＤは、リソースを取得するアプリケーション４の識別に用いられる情報である。なお、本実施形態において、リソースの取得が成功するのは、指定された全てのファンクションの使用リソースが取得できた場合であり、その他は全て取得失敗となる。取得が失敗した場合、既に一部のリソースの取得が成功していたとしても、そのファンクションは開放される。そして、リソースマネージャ１は、アプリケーション４に対して、それら取得結果をファンクション毎に通知する。
【００１８】
一方、使用されなくなったリソースは速やかに開放する必要があり、当該リソースの開放は、そのリソースを使用していたアプリケーション４によりなされる。すなわち、取得されたリソースは、そのリソースを取得したアプリケーション４以外のものにより行われることはない。そして、リソースの開放を行ったアプリケーション４は、リソースマネージャ１に対して、リソースの開放完了を通知する。このとき、リソースの開放完了通知には、リソース取得時に用いたアクセスハンドルとプロセスＩＤが含まれる。なお、ファンクションは同時に複数指定することができるものであるが、処理自体はファンクション毎に行われるため、開放完了通知はファンクション毎の通知となる。
【００１９】
また、アプリケーション４は、ファンクションの使用リソースが全て開放されたときに、その旨を知らせてもらうための開放通知要求を、リソースマネージャ１に対して送ることができる。リソース開放通知要求にかかるファンクションは複数同時に指定でき、同時に指定された全てのファンクションの使用するリソースが全て開放された時に、リソースマネージャ１は上記開放通知要求を行ったアプリケーション４に対して上記開放通知を発行する。上述の開放通知要求を送る場合、アプリケーション４は、開放通知を要求するファンクション名、開放待ちの優先度、通知待ちの時間、アクセスハンドル、プロセスＩＤの各情報を、リソースマネージャ１に対して指定する。なお、リソースマネージャ１が開放通知をアプリケーション４に送信するのは、指定された全てのファンクションの使用リソースが全て開放された時となる。また、通知待ち時間内にリソースが開放されない場合、リソースマネージャ１は、開放通知タイムアウト通知をアプリケーション４に送信する。リソースの開放待ちの解除は、その開放通知要求を行ったアプリケーション４が、リソースマネージャ１に対してリソース取得時に用いたアクセスハンドルとプロセスＩＤを指定することにより行う。つまり、当該リソースの開放待ちの解除は、リソース開放待ちのアプリケーション４以外からは行うことができない。
【００２０】
そして、アプリケーション４は、開放通知を受け取った場合、速やかにリソースを要求するか、又は、リソースが不要であることをリソースマネージャ１に通知しなければならない。ここで、リソースが要求された場合、リソースマネージャ１は、更に次の通知先アプリケーションへのリソース開放通知については、次回のリソース開放時に行う。一方、リソースが不要であるとされた場合、リソースマネージャ１は、次の通知先アプリケーションへリソース開放通知を行う。なお、アプリケーション４がそれらリソースの要不要の通知を怠った場合、リソースマネージャ１は、一定時間経過でタイムアウトとし、リソースが不要であるとみなして、次の通知先アプリケーションへリソース開放通知を行う。また、リソースマネージャ１は、開放通知要求元のアプリケーションによる指定時間を過ぎても、リソースを使用しているアプリケーションから開放完了の通知が来ない場合に、開放要求の待ち状態をキャンセルし、その通知要求元のアプリケーションにタイムアウト通知を行う。また、複数の開放通知要求が存在する場合、それらの開放通知の通知順は、優先度大＞優先度小、設定順後＞設定順前とし、初めに優先度で選別し、同一優先度のものが複数存在するならば、設定順の規則により通知先を決定する。
【００２１】
なお、リソースの取得要求及び開放要求、開放通知要求は、ファンクションを複数同時に指定することができるが、処理は各ファンクション毎に個別に実施され、その結果の通知はファンクション毎となる。このため、複数のファンクションを同時に指定した場合、その結果はファンクション毎に異なるものとなる。
【００２２】
その他、リソースマネージャ１は、登録されたアプリケーションに対して、定期的にヘルスチェックを行うことができる。当該ヘルスチェックによって、アプリケーションの消滅が確認された場合、リソースマネージャ１は、そのアプリケーションの使用リソースを全て開放し、当該アプリケーションに関する登録内容を解除する。
【００２３】
以下、リソースの競合制御時の具体的な動作を個々に説明する。
【００２４】
アプリケーション４がファンクションを要求した際に、そのファンクションに既に別のアプリケーションにより使用されているリソースが含まれているために、当該ファンクションに対する取得要求を実施すると競合が発生してしまう場合、リソースマネージャ１は、優先度の高いアプリケーションにリソースを使用する権利を与える。優先度が同一の場合、リソースマネージャ１は、最後に取得要求を行ったアプリケーションに、リソースを利用する権利を与える。また、リソースの利用権利の移動が発生した場合は、リソースマネージャ１は、そのリソースを使用するアプリケーションにその要因を知らせ、それに対する応答を待つ。なお、権利の移動は、要因通知に対する応答返却、又は要因通知後に開放要求が送られてきた時に行われる。
【００２５】
アプリケーション４が同時に複数のファンクションを取得する場合、リソースマネージャ１は、無駄な開放処理を避けるために、その中にリソース競合により取得が失敗するものが一つでも含まれているならば、当該アプリケーション４に対して、取得失敗として応答を一つだけ通知する。このとき、アプリケーション４は、指定した全てのファンクションのリソース取得を実施しない。一方、リソース競合により取得が失敗しない場合、リソースマネージャ１は、指定されたファンクション毎に取得の判定処理を実施し、それら各ファンクション毎の取得結果をアプリケーション４に通知する。
【００２６】
アプリケーション４が開放通知要求を行っている場合において、開放要求通知の応答の待ち時間内に、同一のリソース要求を受信した場合、リソースマネージャ１は、それら受け付けた要求のうち、より優先度が高く、より後に要求したアプリケーションに対してリソースを取得させる。
【００２７】
また、リソース取得の権利移動のための要因通知に対する応答又は開放要求が、アプリケーション４がリソース取得要求時に指定した「開放処理時間」内に通知されない場合、リソースマネージャ１は、その取得要求を行ったアプリケーションと、リソースを使用しているアプリケーションに対して、「開放異常」を通知する。開放異常となった場合、リソースマネージャ１は、リソースが開放されない限り、その後の取得要求を全て開放異常とする。
【００２８】
次に、図２の各部間で通信されるデータについて説明する。
【００２９】
アプリケーション４からリソースマネージャアクセスライブラリ３へは、初期設定要求データ、終了設定要求データ、内部と外部同期用のリソース取得要求データ、リソース開放要求データ、リソース開放通知要求データ、リソース開放通知要求取り消しデータ等が送られる。初期設定要求データは、メッセージ受信方法と受信先ポインタを示すデータからなる。リソース取得要求データは、各ファンクション名からなるファンクション群データ、優先度データ、取得要因データ、リソース開放最大処理時間データ、リソースハンドルからなる。リソース開放要求データは、リソースハンドルからなる。リソース開放通知要求データは、ファンクション群データ、優先度データ、リソースハンドルからなる。リソース開放通知要求取り消しデータはリソースハンドルからなる。ここで、優先度データは、取得要求及び開放通知要求の優先度を示すデータである。取得要因データは、リソースの取得要因を表すデータである。リソース開放最大処理時間データは、実際に使用リソースをアプリケーションが開放するのにかかる最大時間を表すデータである。
【００３０】
アプリケーション４からハンドル管理部８へは、プロセスＩＤ、メッセージ種別データ、メッセージデータの各データが送られる。プロセスＩＤはアプリケーションのプロセスＩＤである。メッセージ種別データは初期設定要求メッセージ、終了設定要求メッセージ、取得要求メッセージ、開放要求メッセージ、開放通知要求メッセージ、開放通知解除要求メッセージの各種がある。メッセージデータは、メッセージ種別に応じた各メッセージの内容を示すデータである。なお、メッセージ種別において、初期設定要求メッセージはアプリケーションの登録のためのメッセージであり、終了設定要求メッセージはアプリケーションの登録を解除するためのメッセージ、取得要求メッセージはファンクションの取得を要求するためのメッセージ、開放要求メッセージはファンクションの開放を要求するためのメッセージ、開放通知要求メッセージはリソース開放を待つためのメッセージ、開放通知解除要求メッセージはリソース開放待ちを解除するためのメッセージである。また、初期設定要求メッセージの内容としてはメッセージの受信方法と受信ポインタがあり、取得要求メッセージの内容としてはリソースハンドル、取得ファンクション群、取得優先度、取得要因、リソース開放最大処理時間、リソース取得に対する最初の応答メッセージの送信先等がある。開放要求メッセージの内容としては開放するリソースハンドルがあり、開放通知要求メッセージの内容としては開放通知用のリソースハンドル、開放を待つファンクション群、開放通知の優先度、開放通知の待ち時間がある。開放通知解除要求メッセージの内容としては取り消す開放通知のためのリソースハンドルがある。
【００３１】
ハンドル管理部８からアプリケーション４へは、リソースハンドルデータ、メッセージ種別データ、要因データが送られる。要因データは、要求の失敗及び開放要求通知の開放要求発生要因のデータがある。メッセージ種別データは、取得結果ＯＫの通知メッセージ、取得結果ＮＧ通知メッセージ、開放要求通知メッセージ、開放通知メッセージ、開放通知待ちタイムアウト通知メッセージ、開放異常通知メッセージがある。取得結果ＯＫ通知メッセージはリソースの取得に成功したことを示す取得要求許可のメッセージであり、取得結果ＮＧ通知メッセージはリソースの取得に失敗したことを示す取得ＮＧのメッセージである。開放要求通知メッセージはハンドルの開放実施の要求のメッセージ、開放通知メッセージは指定リソースが全て開放されたことを示すメッセージ、開放通知待ちタイムアウト通知メッセージは開放通知待ち時間を経過してもリソースが開放されなかったことを通知するメッセージである。開放異常通知メッセージは取得要求で発生した開放通知に対する開放要求がタイムアウトしたことを通知するメッセージであり、取得要求アプリケーションと開放要求アプリケーションの双方に通知される。
【００３２】
ハンドル管理部８からリソース管理部７へは、メッセージＩＤ、メッセージ種別データ、ファンクション群データ、プロセスＩＤ、優先度データ、要因データ、リソース開放時間データ、開放待ち時間データの各データが送られる。メッセージＩＤは、メッセージの識別子である。送信メッセージに対する応答メッセージが存在する場合、応答メッセージのメッセージＩＤは送信メッセージのＩＤとなる。メッセージ種別データは、取得要求メッセージ、開放要求メッセージ、不用応答メッセージ、開放通知要求メッセージ、要因応答メッセージの各種がある。ファンクション群データは、ファンクションの群を示すデータである。プロセスＩＤは、アプリケーションプロセスのＩＤである。優先度データは、取得要求及び開放通知要求の優先度を示すデータである。要因データは、リソースの取得要因を表すデータである。リソース開放時間データは、実際に使用リソースをアプリケーションが開放するのにかかる最大時間を表すデータである。開放通知待ち時間データは、開放通知要求から開放通知を受け取るまでのタイムアウト時間を表すデータである。なお、メッセージ種別において、取得要求メッセージはファンクションの取得を要求するためのメッセージであり、開放要求メッセージはファンクションの開放を要求するメッセージ、不用応答メッセージは開放通知受信時にそのファンクション群が不用であることの応答に用いるメッセージ、開放通知要求メッセージは指定ファンクションの全リソースが開放されたことを通知するよう依頼するメッセージ、要因応答メッセージは要因通知に対する応答のメッセージである。
【００３３】
リソース管理部７からハンドル管理部８へは、メッセージＩＤ、メッセージ種別データ、ファンクション群データ、プロセスＩＤ、要因データ、要因プロセスデータ、要因優先度データの各データが送られる。メッセージＩＤは、メッセージの識別子であり、ハンドル管理部の送信メッセージのメッセージＩＤとなる。メッセージ種別データは、取得結果ＯＫ通知メッセージ、取得結果ＮＧ通知メッセージ、開放結果ＯＫ通知メッセージ、開放結果ＮＧ通知メッセージ、要因通知メッセージ、開放通知メッセージ、開放通知タイムアウト通知メッセージ、開放異常通知メッセージの各種がある。ファンクション群データは、ファンクションの群を示すデータである。プロセスＩＤは、アプリケーションプロセスのＩＤである。要因データは、リソースの取得失敗、開放失敗、要因通知発生の要因及び開放通知ファンクションの開放前の取得要因の各データである。要因プロセスデータは、リソースの取得失敗、開放失敗、要因通知発生の要因となったプロセス及び開放通知ファンクションの開放以前の取得プロセスのＩＤの各データである。要因優先度データは、リソースの取得失敗、開放失敗、要因通知発生の要因となった優先度及び開放通知ファンクションの開放以前の取得優先度のデータである。なお、メッセージ種別において、取得結果ＯＫ通知メッセージはファンクションの取得が成功したことを示すメッセージであり、取得結果ＮＧ通知メッセージはファンクションの取得に失敗したことを示すメッセージ、開放結果ＯＫ通知メッセージはファンクションの開放が成功したことを示すメッセージ、開放結果ＮＧ通知メッセージはファンクションの開放に失敗したことを示すメッセージ、要因通知メッセージはファンクションリソースの使用権が移動することを通知するメッセージ、開放通知メッセージは開放通知要求の指定ファンクションの全リソースが開放されたことを通知するメッセージ、開放通知タイムアウト通知メッセージは開放通知要求がタイムアウトしたことの通知のメッセージ、開放異常通知メッセージは取得要求で発生した要因通知に対する要因応答がタイムアウトしたことの通知のメッセージであり、要因通知方向と取得要求方向の双方に送信される。
【００３４】
図３は、本実施形態の電子機器の一例としての携帯電話端末の概略構成を示す。なお、この図３において、図２に対応する各構成要素には同じ指示符号を付している。また、図３の各構成要素は、携帯電話端末の主要な構成のみを示している。
【００３５】
図３の例において、携帯電話端末のアプリケーション４は、携帯電話端末の電話機能を実現する電話アプリケーション（Ｔｅｌ  Ａｐｐ）４３、時計機能を実現するクロックアプリケーション（Ｃｌｏｃｋ）４４、ディスプレイ上の表示とスクリーンセーブ機能を実現するスクリーンアプリケーション（Ｓｃｒｅｅｎ  Ａｐｐ）４５、アプリケーションを起動させるためのアプリケーションランチャー（Ａｐｐ  Ｌａｕｎｃｈｅｒ）４６の他に、ユーザにより定義されたアプリケーション（ＡＰＰ１，ＡＰＰ２）４１，４２等からなる。それら各アプリケーションは、アプリケーションの基本部分であるアプリケーションフレームワーク（Ａｐｐｌｉｃａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ）１４、ウインドウマネージャ（Ｗｉｎｄｏｗ  Ｍａｎａｇｅｒ）１３を介し、さらに図２のリソースアクセスライブラリ５を介してオペレーティングシステム（ＯＳ）２１に接続されている。
【００３６】
図３の例の場合、リソース６は、例えば表示を行うための液晶ディスプレイ（ＬＣＤ）デバイス６２とそのドライバ６１、テンキー等のキー（ＫＥＹ）デバイス６４とそのドライバ６３、携帯電話端末における通信のための送受信（Ｃｏｍｍｕｎｉｃａｔｉｏｎ）及びその他（Ｏｔｈｅｒ）の主要な機能に対応したシステムデバイス６６とそのドライバ６５、デジタルカメラのカメラ（Ｃａｍｅｒａ）デバイス６８とそのドライバ６７、本発明の記憶媒体としての機能を有するメモリ（Ｍｅｍ）とそのメモリへのファイル（Ｆｉｌｅ）書き込み読み出し等を行うメモリデバイス７２とそのドライバ７１と、その他、ＬＥＤ（発光ダイオード）やオーディオデバイス等の各種デバイス（Ｍｉｓｃ  Ｈ／Ｗ）７０とそのドライバ６９等からなる。これら各デバイスの制御や各種の演算は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２３が行う。
【００３７】
また図３において、タスクマネージャ（Ｔａｓｋ  Ｍａｎａｇｅｒ）１１は、アプリケーション４の実行時の各タスクを管理し、イベントマネージャ１２（Ｅｖｅｎｔ  Ｍａｎａｇｅｒ）は各種イベントを管理する。リソースマネージャ（Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｒ：ＲｅｓＭａｎ）１は、図２のリソースマネージャ１に対応する。
【００３８】
以下、上述した本実施形態のリソースマネージャが実際にどのようにして各リソースの管理を行うのかの一例を、図４〜図８の各タイムフローチャートを用いて説明する。
【００３９】
図４は、アプリケーションＡＰＰ２より先に、アプリケーションＡＰＰ１がファンクション指定によるリソース取得要求を行っているが、優先度はアプリケーションＡＰＰ１がアプリケーションＡＰＰ２よりも高く（ＡＰＰ１＞ＡＰＰ２）、更にアプリケーションＡＰＰ２が開放通知要求を行わない場合における、本実施形態のリソースマネージャ（ＲｅｓＭａｎ）が行うリソース（Ｒｅｓｏｕｒｃｅ）の競合管理処理のタイムフローチャートを示している。
【００４０】
図４において、例えばアプリケーションＡＰＰ１から、ステップＳ１にてファンクションの指定による新規のリソース取得要求を受け取ると、リソースマネージャは、ステップＳ２にて競合判定を行う。このとき、そのファンクションの使用リソースは他のアプリケーションにより利用されていないため、リソースマネージャは、ステップＳ３にて、アプリケーションＡＰＰ１に対して取得要求許可を返す。これにより、アプリケーションＡＰＰ１は、ステップＳ４にて所望のリソースを取得できることになる。
【００４１】
その後、別のアプリケーションＡＰＰ２から、ステップＳ５にて、同じ使用リソースを含むファンクションの指定による新規のリソース取得要求を受け取ると、リソースマネージャは、ステップＳ６にて競合判定を行う。このとき、そのファンクションの使用リソースは既にアプリケーションＡＰＰ１により利用されているため、リソースマネージャは、ステップＳ７にて、アプリケーションＡＰＰ２に対して取得ＮＧ通知を返す。これにより、アプリケーションＡＰＰ２は、ステップＳ８にて所望のリソースを取得できなかったとしてＮＧ処理を行う。
【００４２】
図５は、アプリケーションＡＰＰ２より先にアプリケーションＡＰＰ１がファンクション指定によるリソースの取得要求を行っているが、優先度はアプリケーションＡＰＰ１がアプリケーションＡＰＰ２よりも高く（ＡＰＰ１＞ＡＰＰ２）、更にアプリケーションＡＰＰ２が開放通知要求を行う場合における、本実施形態のリソースマネージャが行うリソースの競合管理処理のタイムフローチャートを示している。なお、図５において、図４と同じ処理のステップについてはその説明を省略する。
【００４３】
図５において、ステップＳ８によりＮＧ処理を行った後、アプリケーションＡＰＰ２は、開放通知要求をリソースマネージャに送る。このときのリソースマネージャは、当該開放通知要求にかかるファンクションとアプリケーションを対応つけてリストに登録する。その後、アプリケーションＡＰＰ１にて所望の処理が終了し、ステップＳ１０にてリソースの開放が行われ、ステップＳ１１にてアプリケーションＡＰＰ１から開放完了通知を受け取ると、リソースマネージャは、ステップＳ１２にて、他のアプリケーションによる開放通知要求があるか否かの開放通知要求検索を行う。この例の場合、アプリケーションＡＰＰ２からの開放通知要求がリストに登録されているため、リソースマネージャは、ステップＳ１３にて当該アプリケーションＡＰＰ２に対してリソースが開放されたことを通知（開放通知）する。
【００４４】
これにより、アプリケーションＡＰＰ２は、リソースの開放がなされたことを知ることができる。リソースの開放がなされたことを知ったアプリケーションＡＰＰ２は、ステップＳ１４にてファンクションの指定による再度の取得要求を行う。当該ステップＳ１４にて取得要求を受け取ると、リソースマネージャは、ステップＳ１５にて競合判定を行う。このとき、当該ファンクションの使用リソースは他のアプリケーションにより利用されていないことになるため、リソースマネージャは、ステップＳ１６にて、アプリケーションＡＰＰ２に対して取得完了通知を返す。そして、アプリケーションＡＰＰ１は、ステップＳ１７にて所望のリソースを取得できることになる。
【００４５】
図６は、アプリケーションＡＰＰ２より先にアプリケーションＡＰＰ１がファンクション指定によるリソース取得要求を行っているが、優先度はアプリケーションＡＰＰ１とアプリケーションＡＰＰ２で同じであるため取得要求の設定順の遅い方が優先され（ＡＰＰ１≦ＡＰＰ２）、更にアプリケーションＡＰＰ１が開放通知要求を行わない場合における、本実施形態のリソースマネージャが行うリソースの競合管理処理のタイムフローチャートを示している。なお、図６において、図４，図５と同じ処理のステップについてはその説明を省略する。
【００４６】
図６の例の場合、リソースマネージャは、ステップＳ６での競合判定の際に、アプリケーションＡＰＰ２の優先度がアプリケーションＡＰＰ１の優先度以上であり、アプリケーションＡＰＰ１からのリソース取得要求の設定順が「後」であるため、ステップＳ２１にて、アプリケーションＡＰＰ１に対してリソースの開放要求を発行する。アプリケーションＡＰＰ１は、当該開放要求を受け取った場合、ステップＳ２２及びステップＳ２３にてリソースの開放処理を行う。その後、アプリケーションＡＰＰ１は、ステップＳ２４にて、リソースマネージャへ開放完了通知を送る。
【００４７】
アプリケーションＡＰＰ１から開放完了通知を受け取ると、リソースマネージャは、ステップＳ２５にて、アプリケーションＡＰＰ２に対して取得完了通知を送信する。これにより、アプリケーションＡＰＰ２は、ステップＳ２６にて所望のリソースを取得できることになる。
【００４８】
その後、アプリケーションＡＰＰ２にて所望の処理が終了し、ステップＳ２７にてリソースの開放が行われ、ステップＳ２８にてアプリケーションＡＰＰ２から開放完了通知を受け取ると、リソースマネージャは、ステップＳ２９にて、その開放されたリソースをリストに登録する。
【００４９】
図７は、アプリケーションＡＰＰ２より先にアプリケーションＡＰＰ１がファンクション指定によるリソース取得要求を行っているが、優先度はアプリケーションＡＰＰ１とアプリケーションＡＰＰ２で同じであるため取得要求の設定順の遅い方が優先され（ＡＰＰ１≦ＡＰＰ２）、更にアプリケーションＡＰＰ１が開放通知要求を行う場合における、本実施形態のリソースマネージャが行うリソースの競合管理処理のタイムフローチャートを示している。なお、図７において、図４，図５，図６と同じ処理のステップについてはその説明を省略する。
【００５０】
図７の例の場合、アプリケーションＡＰＰ１は、ステップＳ２３にてリソースの開放を行った後、ステップＳ３０にて開放完了通知と開放通知要求をリソースマネージャへ送る。
【００５１】
その後、リソースマネージャは、ステップＳ２８にてアプリケーションＡＰＰ２から開放完了通知を受け取ると、ステップＳ３１にて開放待ちのリストの内容を確認する。このとき、リソースマネージャは、開放待ちリストを元にアプリケーションＡＰＰ１による開放通知要求があることを知り、ステップＳ３２にてリソース開放通知を当該アプリケーションＡＰＰ１へ送信する。
【００５２】
リソースマネージャからリソース開放通知を受け取ったアプリケーションＡＰＰ１は、ステップＳ３３にてリソースの再取得のための再登録準備を行い、当該準備が整うと、ステップＳ３４にて取得要求をリソースマネージャへ送る。
【００５３】
そして、リソースマネージャは、ステップＳ３５にて競合判定を行う。このとき、リソース競合は無いため、リソースマネージャは、ステップＳ３６にて、アプリケーションＡＰＰ１に対して取得完了通知を返す。これにより、アプリケーションＡＰＰ１は、ステップＳ３７にて所望のリソースを再取得できることになる。
【００５４】
図８は、アプリケーションＡＰＰ１とＡＰＰ２の他に更にアプリケーションＡＰＰ３があり、最初にアプリケーションＡＰＰ２がリソースの取得要求を行い、次にアプリケーションＡＰＰ２が、更にその次にアプリケーションＡＰＰ３がリソースの取得要求を行い、また、優先度はアプリケーションＡＰＰ３が最も高く、アプリケーションＡＰＰ１とＡＰＰ２の優先度は同じであるため取得要求の設定順の遅い方が優先され（ＡＰＰ１≦ＡＰＰ２＜ＡＰＰ３）、更にアプリケーションＡＰＰ１が開放通知要求を行う場合における、本実施形態のリソースマネージャが行うリソースの競合管理処理のタイムフローチャートを示している。なお、図８において、図４，図５，図６，図７と同じ処理のステップについてはその説明を省略する。
【００５５】
図８の例の場合、アプリケーションＡＰＰ３の取得要求は、ステップＳ５でアプリケーションＡＰＰ２による取得要求の後に行われることになる。リソースマネージャは、ステップＳ４０にてアプリケーションＡＰＰ３からのリソースの取得要求を受け取ると、アプリケーションＡＰＰ１からステップＳ３０の開放完了通知及び開放通知要求の送信を受け取った後に、ステップＳ４１にてアプリケーションＡＰＰ１，ＡＰＰ２，ＡＰＰ３間でのリソース競合の判定を行う。この場合、リソースマネージャは、優先度がもっとも高いのがアプリケーションＡＰＰ３であるため、ステップＳ４２にて当該アプリケーションＡＰＰ３に取得完了通知を送る。またこの時のリソースマネージャは、アプリケーションＡＰＰ２に対しては、ステップＳ４３にて取得ＮＧを送る。これにより、アプリケーションＡＰＰ３は、ステップＳ４４にて所望のリソースを取得できることになる。
【００５６】
その後、アプリケーションＡＰＰ３は、所望の処理が終了すると、ステップＳ４５にてリソースの開放を行い、更にステップＳ４６にて開放完了通知をリソースマネージャへ送る。
【００５７】
開放完了通知を受け取ったリソースマネージャは、ステップＳ４７にて開放待ちのリストの内容を確認する。このとき、リソースマネージャは、開放待ちリストから、アプリケーションＡＰＰ１が開放通知要求を行っていることを知る。その後は、図７のステップＳ３２〜ステップＳ３７と同様の処理が行われる。
【００５８】
以上説明したように、本発明実施形態のリソースマネージャは、使用状況（条件）に応じた動的な優先度管理と使用権管理を実現することで、柔軟なリソース管理機構を実現している。すなわち、本発明実施形態のリソースマネージャは、リソースの使用権を管理することで、実際のハードウェアリソースの利用アプリケーションと使用権利アプリケーションを柔軟に定義できるようにしている。
【００５９】
また、本実施形態によれば、使用権管理を行う単位として、個別のハードウェアリソースの単体から、或るアプリケーションを構成するために必要な複数リソースをまとめた単位としてファンクションという概念を導入し、このファンクション単位での管理を可能としている。
【００６０】
また、本実施形態によれば、使用アプリケーションの優先度、リソース優先度、などを考慮したリクエストキューを内部に持つことで、単純な後優先アルゴリズムよりも無駄なリソースの奪い合いの回数を減らすことも出来るようになっている。
【００６１】
なお、上述した実施形態の説明は、本発明の一例である。このため、本発明は上述した実施の形態に限定されることなく、本発明に係る技術的思想を逸脱しない範囲であれば、設計等に応じて種々の変更が可能であることはもちろんである。本発明は、携帯電話端末だけでなく、例えばパーソナルコンピュータやＰＤＡ装置（ＰＤＡ：Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ）等に適用することも可能である。また、図１に示した対応関係テーブルのうち、アプリケーション４が所望するファンクションとそのファンクションに対応するリソースの情報は、当該アプリケーション４側がリソース取得要求の際にその都度リソースマネージャ１へ送っても良い。また、優先度は、アプリケーションの優先度だけでなく、ファンクション単位の優先度、更にファンクション内の各リソースの優先度も含まれ、リソースマネージャ１は、ファンクションの優先度に応じたリソースの競合判定や、ファンクション内の各リソースの優先度に応じた競合判定を行い、その競合判定結果に応じてリソースの取得完了等の通知を行っても良い。
【００６２】
【発明の効果】
本発明においては、リソースの競合判定や使用許可、リソースの使用権利についての管理はリソース管理装置が行い、リソースを使用していた処理手段がそのリソースを開放したときに、そのリソースについて開放通知要求を行っている処理手段が存在する場合には、その処理手段に対してリソースの開放がなされたことを通知することにより、複数の処理手段（例えば複数アプリケーション）間でリソースを効率的に且つ柔軟に割り付け可能とし、矛盾のなくリソースの排他使用を実現可能である。
【図面の簡単な説明】
【図１】各ファンクションと各リソースの対応関係の表を示す図である。
【図２】本発明にかかるリソース管理を実施する電子機器の概略構成を示すブロック図である。
【図３】本実施形態の電子機器の一例としての携帯電話端末の概略構成を示すブロック図である。
【図４】優先度がＡＰＰ１＞ＡＰＰ２で開放通知要求無しの場合のリソースマネージャによるリソースの競合管理処理のタイムフローチャートである。
【図５】優先度がＡＰＰ１＞ＡＰＰ２で開放通知要求有りの場合のリソースマネージャによるリソースの競合管理処理のタイムフローチャートである。
【図６】優先度がＡＰＰ１≦ＡＰＰ２で開放通知要求無しの場合のリソースマネージャによるリソースの競合管理処理のタイムフローチャートである。
【図７】優先度がＡＰＰ１≦ＡＰＰ２で開放通知要求有りの場合のリソースマネージャによるリソースの競合管理処理のタイムフローチャートである。
【図８】優先度がＡＰＰ１≦ＡＰＰ２＜ＡＰＰ３で開放通知要求有りの場合のリソースマネージャによるリソースの競合管理処理のタイムフローチャートである。
【符号の説明】
１…リソースマネージャ、２…リソースマネージャプロセス部、３…リソースマネージャアクセスライブラリ、４…アプリケーション、５…リソースアクセスライブラリ、６…ハードウェアリソース
【図１】
2005004350.tif 000003
【図２】
2005004350.tif 000004
【図３】
2005004350.tif 000005
【図４】
2005004350.tif 000006
【図５】
2005004350.tif 000007
【図６】
2005004350.tif 000008
【図７】
2005004350.tif 000009
【図８】
2005004350.tif 000010