(57)【要約】【課題】ユーザのリソース割当てに対する意見をユーザの負担無く取得し、リソース割当を行うリソース装置を提供する。【解決手段】アプリケーションの使用するリソースの配分を決定する。前記決定された前記リソース配分を基に前記アプリケーションの使用するリソース量を制御する。ユーザからのフィードバック情報を取得する。意図的にリソース配分を変動させ、当該変動後のリソース配分を基に前記アプリケーションの使用するリソース量を制御し、前記リソース配分の変動量に応じたユーザからのフィードバック情報を取得し、当該フィードバック情報に基づいて前記リソース割当を行う。【選択図】図１
2010287045.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションの使用するリソースの配分を決定する配分制御手段と、
前記決定された前記リソース配分を基に前記アプリケーションの使用するリソース量を制御するリソース制御手段と、
ユーザからのフィードバック情報を取得するユーザインターフェースと、を備え、
前記配分制御手段が意図的にリソース配分を変動させ、前記リソース制御手段は当該変動後のリソース配分を基に前記アプリケーションの使用するリソース量を制御し、前記配分制御手段は、前記リソース配分の変動量に応じたユーザからのフィードバック情報を前記ユーザインターフェースを介して取得し、当該フィードバック情報に基づいて前記リソース割当を行うことを特徴とするリソース割当装置。
【請求項２】
前記ユーザインターフェースが取得するフィードバック情報とは、ＯＮ或いはＯＦＦを表す信号、及び、ＯＮ信号の強度であることを特徴とする請求項１に記載のリソース割当装置。
【請求項３】
前記配分制御手段は、アプリケーションの割当リソースを既に割り当てられている配分から減少させ、その変動に応じた前記ＯＮ信号の強度の変化を基にユーザがリソース割当に不満を持つアプリケーションを推測し、当該アプリケーションの割当リソースを増やすことを特徴とする請求項２に記載のリソース割当装置。
【請求項４】
前記リソース変動量を、使用リソース量とユーザ体感品質の対応を示すグラフを基に決定することを特徴とする請求項１乃至３の何れか１項に記載のリソース割当装置。
【請求項５】
前記アプリケーションが複数存在し、前記配分制御手段は、或る第１のアプリケーションと、当該或る第１のアプリケーションとは別のアプリケーションである第２のアプリケーションと、について異なる種別のリソースの配分決定を行うことを特徴とする請求項１乃至４の何れか１項に記載のリソース割当装置。
【請求項６】
アプリケーションの使用するリソースの配分を決定する配分制御ステップと、
前記決定された前記リソース配分を基に前記アプリケーションの使用するリソース量を制御するリソース制御ステップと、
ユーザからのフィードバック情報を取得するユーザインターフェースを用意するステップと、を備え、
前記配分制御ステップにおいて意図的にリソース配分を変動させ、前記リソース制御ステップにおいて当該変動後のリソース配分を基に前記アプリケーションの使用するリソース量を制御し、前記配分制御ステップにおいて、前記リソース配分の変動量に応じたユーザからのフィードバック情報を前記ユーザインターフェースを介して取得し、当該フィードバック情報に基づいて前記リソース割当を行うことを特徴とするリソース割当方法。
【請求項７】
前記ユーザインターフェースが取得するフィードバック情報とは、ＯＮ或いはＯＦＦを表す信号、及び、ＯＮ信号の強度であることを特徴とする請求項６に記載のリソース割当方法。
【請求項８】
前記配分制御ステップにおいて、アプリケーションの割当リソースを既に割り当てられている配分から減少させ、その変動に応じた前記ＯＮ信号の強度の変化を基にユーザがリソース割当に不満を持つアプリケーションを推測し、当該アプリケーションの割当リソースを増やすことを特徴とする請求項７に記載のリソース割当方法。
【請求項９】
前記リソース変動量を、使用リソース量とユーザ体感品質の対応を示すグラフを基に決定することを特徴とする請求項６乃至８の何れか１項に記載のリソース割当方法。
【請求項１０】
前記アプリケーションが複数存在し、前記配分制御ステップにおいて、或る第１のアプリケーションと、当該或る第１のアプリケーションとは別のアプリケーションである第２のアプリケーションと、について異なる種別のリソースの配分決定を行うことを特徴とする請求項６乃至９の何れか１項に記載のリソース割当方法。
【請求項１１】
アプリケーションの使用するリソースの配分を決定する配分制御手段と、
前記決定された前記リソース配分を基に前記アプリケーションの使用するリソース量を制御するリソース制御手段と、
ユーザからのフィードバック情報を取得するユーザインターフェースと、を備え、
前記配分制御手段が意図的にリソース配分を変動させ、前記リソース制御手段は当該変動後のリソース配分を基に前記アプリケーションの使用するリソース量を制御し、前記配分制御手段は、前記リソース配分の変動量に応じたユーザからのフィードバック情報を前記ユーザインターフェースを介して取得し、当該フィードバック情報に基づいて前記リソース割当を行うリソース割当装置としてコンピュータを機能させることを特徴とするリソース割当プログラム。
【請求項１２】
前記ユーザインターフェースが取得するフィードバック情報とは、ＯＮ或いはＯＦＦを表す信号、及び、ＯＮ信号の強度であることを特徴とする請求項１１に記載のリソース割当プログラム。
【請求項１３】
前記配分制御手段は、アプリケーションの割当リソースを既に割り当てられている配分から減少させ、その変動に応じた前記ＯＮ信号の強度の変化を基にユーザがリソース割当に不満を持つアプリケーションを推測し、当該アプリケーションの割当リソースを増やすことを特徴とする請求項１２に記載のリソース割当プログラム。
【請求項１４】
前記リソース変動量を、使用リソース量とユーザ体感品質の対応を示すグラフを基に決定することを特徴とする請求項１１乃至１３の何れか１項に記載のリソース割当プログラム。
【請求項１５】
前記アプリケーションが複数存在し、前記配分制御手段は、或る第１のアプリケーションと、当該或る第１のアプリケーションとは別のアプリケーションである第２のアプリケーションと、について異なる種別のリソースの配分決定を行うことを特徴とする請求項１１乃至１４の何れか１項に記載のリソース割当プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザからのフィードバック情報を用いたリソース割当装置、リソース割当方法及びリソース割当プログラムに関する。
【背景技術】
【０００２】
組込み機器においてパフォーマンスを向上させることを目的として、例えば、ＣＰＵ性能を不用意に上げると、消費電力を大量に浪費してしまう。また、メモリ容量を増加させることは、機器サイズ、コスト増加につながってしまう。すなわち、消費電力削減や小型化、コスト削減などの要請で、ＣＰＵ演算性能やメモリ容量などのリソースが限られているといえる。
【０００３】
そして、使用できるリソースが限られているため、複数のアプリケーション（以下、適宜「アプリ」と表記する。）が起動した場合、各アプリに適切にリソースを割当てなければならない。使用リソースの制御をしないと、複数アプリが限られたリソースを取り合い、各アプリが期待通りに動作しないためである。
【０００４】
しかし、リソース割当ての最適値はユーザによって異なる可能性がある。そのため、ユーザ毎に割当を行う必要がある。なぜならば、どのアプリが重要であるかは、ユーザに嗜好や使用環境によって異なるため、画一的なリソース割当てではユーザの期待に応えることができないからである。
【０００５】
このため、ユーザの意見を基に、ユーザ毎のリソース割当て最適化を行う。現在のリソース割当て対するユーザのフィードバックを取得し、そのフィードバック情報を基にリソース割当てをすることで、ユーザの期待に応えることができる。
【０００６】
このような、リソースの割当に関する技術として、例えば特許文献１に記載がある。
【０００７】
特許文献１では、ユーザに応じたリソース割当を行うリソース割当装置について開示されている。前記装置は、アプリの重要度が設定できるユーザインターフェースを備える。図１３に当該ユーザインターフェースとして、ユーザインターフェース２０００を示す。
【０００８】
前記装置は、ユーザに自らユーザインターフェース２０００を用いアプリの重要度を設定させることで、当該ユーザのリソース割当てに対する意見を取得し、この意見を反映することができる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００８−３０５０８３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、ユーザに全てのアプリのそれぞれ毎にリソース割当を指定、又は、調整させることは、ユーザにとって大きな負担になる。そのため、ユーザの負担にならないように、現在のリソース割当てに対するフィードバックを取得し、このフィードバックを基にユーザに最適化したリソース割当を行うことが必要である。
【００１１】
そこで本発明は、上記問題点に鑑みてなされたもので、ユーザの現在のリソース割当てに対するフィードバックをユーザの負担無く取得し、リソース割当を行うリソース装置、リソース割当方法及びリソース割当プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の第１の観点によれば、アプリケーションの使用するリソースの配分を決定する配分制御手段と、前記決定された前記リソース配分を基に前記アプリケーションの使用するリソース量を制御するリソース制御手段と、ユーザからのフィードバック情報を取得するユーザインターフェースと、を備え、前記配分制御手段が意図的にリソース配分を変動させ、前記リソース制御手段は当該変動後のリソース配分を基に前記アプリケーションの使用するリソース量を制御し、前記配分制御手段は、前記リソース配分の変動量に応じたユーザからのフィードバック情報を前記ユーザインターフェースを介して取得し、当該フィードバック情報に基づいて前記リソース割当を行うことを特徴とするリソース割当装置が提供される。
【００１３】
本発明の第２の観点によれば、アプリケーションの使用するリソースの配分を決定する配分制御ステップと、前記決定された前記リソース配分を基に前記アプリケーションの使用するリソース量を制御するリソース制御ステップと、ユーザからのフィードバック情報を取得するユーザインターフェースを用意するステップと、を備え、前記配分制御ステップにおいて意図的にリソース配分を変動させ、前記リソース制御ステップにおいて当該変動後のリソース配分を基に前記アプリケーションの使用するリソース量を制御し、前記配分制御ステップにおいて、前記リソース配分の変動量に応じたユーザからのフィードバック情報を前記ユーザインターフェースを介して取得し、当該フィードバック情報に基づいて前記リソース割当を行うことを特徴とするリソース割当方法が提供される。
【００１４】
本発明の第３の観点によれば、アプリケーションの使用するリソースの配分を決定する配分制御手段と、前記決定された前記リソース配分を基に前記アプリケーションの使用するリソース量を制御するリソース制御手段と、ユーザからのフィードバック情報を取得するユーザインターフェースと、を備え、前記配分制御手段が意図的にリソース配分を変動させ、前記リソース制御手段は当該変動後のリソース配分を基に前記アプリケーションの使用するリソース量を制御し、前記配分制御手段は、前記リソース配分の変動量に応じたユーザからのフィードバック情報を前記ユーザインターフェースを介して取得し、当該フィードバック情報に基づいて前記リソース割当を行うリソース割当装置としてコンピュータを機能させることを特徴とするリソース割当プログラムが提供される。
【発明の効果】
【００１５】
本発明によれば、ユーザの現在のリソース割当てに対するフィードバックをユーザの負担無く取得できることから当該ユーザに最適化したリソース割当を行うことが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態の基本的構成を表すブロック図である。
【図２】本発明の実施形態のユーザインターフェースの一例を表す図である。
【図３】本発明の実施形態におけるリソースの割当てについて示す図である。
【図４】本発明の実施形態における不満度について示す図である。
【図５】本発明の実施形態における押下頻度について示す図である。
【図６】本発明の実施形態における品質グラフについて示す図である。
【図７】本発明の実施形態におけるコンピュータ１０００について表す図である。
【図８】本発明の実施形態の基本的動作を表すフローチャートである。
【図９】本発明の実施例における不満度について示す図である。
【図１０】本発明の実施例における押下頻度について示す図である。
【図１１】本発明の実施例における不満度について示す図である。
【図１２】本発明の実施例における押下頻度について示す図である。
【図１３】本発明に関連する技術について表すブロック図である。
【発明を実施するための形態】
【００１７】
次に、発明を実施するための形態について図面を参照して詳細に説明する。
【００１８】
図１は、本発明の実施形態におけるリソース割当装置１００の構成を示すブロック図である。
【００１９】
本リソース割当装置１００は、リソース制御モジュール１１０と、配分制御モジュール１２０と、ユーザインターフェース１３０と、を有している。
【００２０】
リソース制御モジュール１１０は、アプリのリソース使用を制御する。配分制御モジュール１２０は、リソースの配分を決定する。ユーザインターフェース１３０は、ユーザからの入力を受け付ける際のインターフェースである。
【００２１】
リソース制御モジュール１１０は、配分制御モジュール１２０の決定するリソース配分に従い各アプリ（図中には、第１のアプリ２１０、第２のアプリ２２０及び第３のアプリ２３０を示す。）にリソースを割り当てる。
【００２２】
配分制御モジュール１２０は、各アプリへのリソース配分の調整及び決定をする。前記配分制御モジュール１２０は、リソース配分の調整が必要な場合に、リソース配分を既に決めている値から意図的に変動させる。この変動量に従い前記リソース制御モジュール１１０はリソース制御を行う。そして、配分制御モジュール１２０は当該変動量に応じたユーザからのフィードバックを、前記ユーザインターフェース１３０を介して得ることで新しいリソース配分を決定する。
【００２３】
前記フィードバックは、ＯＮ／ＯＦＦ信号、及び、ＯＮの強度とする。
【００２４】
ここで、ユーザインターフェース１３０の一例であるユーザインターフェース１３１を図２に示す。図２に示すユーザインターフェース１３１は、１つボタンの簡易なもので、ユーザからの入力はボタン押下などのＯＮ／ＯＦＦの信号とする。なお、図２に示したのはあくまで例示であり、本実施形態におけるユーザインターフェース１３０の形状や配置、大きさを限定するものではない。任意のインターフェースを、ユーザインターフェース１３０として用いることが可能である。
【００２５】
また、ＯＮの強度として、ボタン押下頻度やボタン押下の強度等を用いることができる。以後は、「頻度」をＯＮの強度として用いる場合を例に説明する。
【００２６】
なお、ユーザインターフェース１３０は、ユーザインターフェース１３１のようなボタンに限らず、ＯＮ／ＯＦＦ及びＯＮの強度が入力できるものであれば良い。例えば、眼球運動や瞳孔変異、瞬き、電気的な皮膚反応（ＧＳＲ：galvanic skin response）、心拍、表情、脳波などの生体情報を入力として用いても良い。
【００２７】
配分制御モジュール１２０は、変動の例として、アプリへのリソース配分を既に決定している配分量から減少させるようにリソース制御モジュール１１０に指示する。リソース制御モジュール１１０は、この指示に応じて配分量が減少するように変動させる。
【００２８】
その後、配分制御モジュール１２０は、その変動に応じたユーザフィードバックを基に不満アプリを推測し、当該アプリへのリソース配分を増やす。ここで、不満アプリとは、リソース割当を増やして欲しいなどの、ユーザが性能に不満を持っているアプリのことを指すものとする。
【００２９】
次に、ソース配分の減少及びユーザフィードバックを基にした不満アプリの推測について図３乃至図６を参照して説明する。
【００３０】
今回は、第１のアプリ及び第２のアプリが存在するものとする。そして、アプリが複数ある場合は、リソース配分を順に減少させる。図３を参照すると、まず第２のアプリについての割当リソースを減少させ、次に第１のアプリについての割当リソースを減少させていることが分かる。
【００３１】
ここでユーザには、リソース割当に不満がある場合にはその不満に応じた頻度でボタンを押すように予め要請しておく。ユーザの各アプリに対する不満度は、リソース変動に応じて図４に示す状態であったものとする。
【００３２】
ただし、リソース割当に対する不満は、アプリの不満度がある閾値を超したときに現れる。なぜならば、閾値を超えるまではユーザはボタンを押下しないからである。そのため、押下の頻度は閾値を越した量として観測される。
【００３３】
さらに、複数アプリのリソース割当が不満である場合は、押下頻度はそれらの和として観測される。例えば、閾値が図４の閾値１、閾値２、閾値３であった場合に観測される理想的な押下頻度を図５に示す。閾値１はアプリ１のみ不満、閾値３ではどちらも不満アプリであることを意味する。閾値２は、アプリ２のリソース割当を減らした時に当該アプリが不満アプリになることを意味する。
【００３４】
配分制御モジュール１２０は、変動のない時点ではどのアプリが不満アプリか判別できないが、変動を加えることにより、閾値１及び閾値２では、アプリ１が不満アプリであることが判断できる。これより、配分制御モジュール１２０はアプリ１にリソースを多く配分すると決定する。閾値３では、どちらも不満アプリであることがわかるため、可能な場合は、両アプリへのリソース配分を増やす。
【００３５】
リソース変動量は、使用リソース量とユーザ体感品質の対応グラフ（品質グラフ図６を参照。）を基に決定すると効果的である。ユーザ体感品質変動に応じ、リソース変動量を決められるためである。図３、図４ではリソース量と不満度が線形関係にあるかのように記述しているが、実際には線形とは限らない。品質グラフを用いることで、不満度変動量が一定になるようにリソース変動を決めることができる。品質グラフは、アプリ製作者が予め作成しておく。
【００３６】
なお、図１に示される各機能部は、本実施の形態に係るリソース割当装置１００を実現する場合において、ソフトウェア・プログラム及びハードウェアの何れかによって実現される所定の機能単位である。したがって、これら各処理部の一部または全部をソフトウェア又はハードウェアとして実現しても良い。
【００３７】
更に、本発明の実施形態であるリソース割当装置１００は、ハードウェアにより実現することもできるが、コンピュータをそのリソース割当装置１００として機能させるためのソフトウェア・プログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００３８】
また、本発明の実施形態によるリソース割当方法は、ハードウェアにより実現することもできるが、コンピュータにその方法を実行させるためのソフトウェア・プログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００３９】
ソフトウェア・プログラムとして実現される場合、図７に示されるように、プロセッサ１０１１、メインメモリ１０２１、インターフェース１０３１を備えるコンピュータ装置１０００上でソフトウェア・プログラムは実行される。
【００４０】
ソフトウェア・プログラムは、読み書き可能なメインメモリ（記憶媒体）１０２１に格納されている。プロセッサ１０１１は、ソフトウェア・プログラムをメインメモリ１０２１から読み出して実行する。
【００４１】
このような場合、係るソフトウェア・プログラムのコード或いは記憶媒体によって構成される。
【００４２】
次に、図８に示すフローチャートを参照して、本発明の実施形態におけるリソース割当装置１００の処理について詳細に説明する。
【００４３】
図８に示すフローチャートは、図７に示すコンピュータ１０００におけるプロセッサ１０１１が実行するソフトウェア・プログラムの処理手順を表す。したがって、図１に示される機能部は、プロセッサ１０１１によって実行されるソフトウェア・プログラムとして説明される。
【００４４】
まず、プロセッサ１０１１は、決められた割合で各アプリの使用リソースを制御する（ステップＳ１１）。各アプリへのリソース配分はステップＳ１３で決定されるが、プログラム起動時は予め決められた初期値を用いる。
【００４５】
プロセッサ１０１１は、ユーザが現在のリソース割当に不満を持っているか判断し（ステップＳ１２）、不満が無い場合は（ステップＳ１２においてＮｏ）、現在のリソース割当を継続する（ステップＳ１１）。不満を持っているかは、例えば、ユーザがボタン（ユーザインターフェース１３１）を押したか否かで判断する。
【００４６】
一方、プロセッサ１０１１はユーザが現リソース割当に不満を持つと判断すると（ステップＳ１２においてＹｅｓ）、或るアプリへの配分するリソース量を減少させ（ステップＳ１３）、この配分で当該アプリの使用リソースを制御する（ステップＳ１４）。ステップＳ１３における１回のリソース配分減少量は品質グラフから求めても良い。例えば、予め決めた一定値分の品質減少に対応するリソース配分減少量を１回の量とする。
【００４７】
プロセッサ１０１１は、前記配分リソース量に応じたユーザのフィードバックを基に、当該アプリが不満アプリであるか判断する（ステップＳ１５）。不満アプリが特定できない場合は（ステップＳ１５においてＮｏ）、ステップＳ１３に戻る。ステップＳ１３では、前回リソース配分を減少させたアプリの配分量をさらに減らすか、このアプリへの配分量を元に戻し他のアプリのリソース配分を減少させる。
【００４８】
プロセッサ１０１１は、不満アプリが特定できると（ステップＳ１５においてＹｅｓ）、当該アプリへのリソース配分を増やす（ステップＳ１６）。リソース配分の増加量は、上述した減少量と同様に品質グラフから求めても良い。
【００４９】
リソース制御対象のアプリが起動している間は（ステップＳ１７においてＮｏ）、ステップＳ１１からステップ１６を繰り返す。一方、リソース制御対象のアプリが全て終了した場合は、動作を終了させる（ステップＳ１７においてＹｅｓ）。
【００５０】
このように、リソース配分の変動量に応じたボタン押下などのフィードバック情報を用いることで、ユーザのリソース割当に対する意見を負担無く取得でき、ユーザに最適化したリソース割当を行うことができる。
【００５１】
また、ユーザが、アプリ毎に重要度を設定するなどの煩雑な動作を行う必要がなく、例えば１つのボタンを押す、といった簡便な動作をのみで最適なリソース配分を行うことが可能となる。
【実施例】
【００５２】
次に、本発明における実施例について図面を参照に詳細に説明する。
【００５３】
本実施例は、アプリとして、動画を復号するデコーダ（図中では、「第１のアプリ」と記述する。）と、カメラ画像を解析する画像解析（図中では、「第２のアプリ」と記述する。）の二つがあるとする。また、リソースとして演算リソースを考える。ここで、デコーダには６０％、画像解析には４０％の演算リソースが配分されているとする。
【００５４】
配分制御モジュール１２０は、品質グラフ（図６）を参照し、各アプリの品質が０．１、０．２及び０．３下がるように３段階リソース量を減少させる。つまり、図６より、デコーダは６０％（品質０．７）、５０％（同０．６）、４５％（同０．５）、４０％（同０．４）、画像解析は４０％（同０．８）、３０％（同０．７）、２５％（同０．６）、２０％（同０．５）と減少させる。
【００５５】
各アプリに対する不満度と閾値が図９であったとすると、押下頻度は理想的には図１０のように観測される。これより、配分制御モジュール１２０は、デコーダが不満アプリと判断し、デコーダへのリソース配分量を増やすことを決定する。
【００５６】
増加量は、例えば、品質が０．１上がるように決定する。この場合、品質グラフ（図６）よりデコーダのリソース配分は７０％（品質０．８）となる。画像解析のリソース割当は４０％であったため、デコーダのリソース配分増加に伴いリソース配分を３０％に減少させる。つまり、新しいリソース配分は、デコーダ７０％、画像解析３０％となる。
【００５７】
リソース配分の減少は図６のようにアプリ毎ではなくても良く、図１１のように交互に変動させても良い。この場合、押下頻度は図１２のようになる。これにより、図１１のように変動させることによっても、配分制御モジュール１２０は、デコーダが不満アプリと判断し、デコーダへのリソース配分量を増やすことができる。
【００５８】
本実施例は、２つのアプリへの同一のリソース配分について説明した。しかし、同一リソースである必要は無く、あるアプリへは演算リソースの配分を、別のアプリへはメモリ容量の配分量を決定するなどの、複数の異なる種別のリソースの配分決定に用いることもできる。
【００５９】
以上、実施の形態を説明したが、上述した実施の形態は、本発明の好適な実施の形態ではあるが、上記実施の形態のみに本発明の範囲を限定するものではなく、特許請求の範囲に定義された本発明の広範囲な趣旨および範囲から逸脱することなく、これら実施の形態や具体例に様々な修正および変更が可能である。
【符号の説明】
【００６０】
１００  リソース割当装置
１１０  リソース制御モジュール
１２０  配分制御モジュール
１３０、１３１，２０００  ユーザインターフェース
２１０  第１のアプリ２１０
２２０  第２のアプリ
２３０  第３のアプリ
１０００  コンピュータ
１０１１  プロセッサ
１０２１  メインメモリ
１０３１  インターフェース
【図１】
2010287045.tif 000003
【図２】
2010287045.tif 000004
【図３】
2010287045.tif 000005
【図４】
2010287045.tif 000006
【図５】
2010287045.tif 000007
【図６】
2010287045.tif 000008
【図７】
2010287045.tif 000009
【図８】
2010287045.tif 000010
【図９】
2010287045.tif 000011
【図１０】
2010287045.tif 000012
【図１１】
2010287045.tif 000013
【図１２】
2010287045.tif 000014
【図１３】
2010287045.tif 000015