(57)【要約】【課題】全体の需要が把握できるシステムを提供する。全体の需要が把握できることにより、カスタマーが最も優良なサービスを選択できる。また、ベンダ側としても事前に損得の計算ができる。【解決手段】ベンダ１４０は、提供している品物やサービスの値段、損益分岐点のノルマ、締め切り時間、実施時間などをサーバー１１０に公開する。潜在カスタマー１２０及び潜在カスタマー１３０のような二つ以上のカスタマーがサーバー１１０にアクセスし、事前に決められたＩＤやパスワードを使用しベンダが提供した情報・ノルマや他の潜在カスタマーが手配した合計などを閲覧し、発注を手配することができる。この発注が締め切り時間以内にノルマを達成すれば、その旨を伝える通知がサーバー１１０を自動的にカスタマーやベンダに配信する。ただしプライバシー保護のため潜在カスタマーの情報はベンダにしか閲覧できず、潜在カスタマー同士は匿名の情報しか閲覧できない。【選択図】図１
2009151736.tif 000002
【特許請求の範囲】
【請求項１】
インターネットのオンライン発注・受注システムであり、前記システムのサーバーに事前に１つ以上のベンダが登録しており、前記ベンダが１つ以上の商品・サービス及び地域を登録することができ、それぞれの前記地域に対し、前記ベンダが前記地域別のノルマと締め切り時間とサービス実施時間を登録することができ、前記システムのサーバーにユーザが登録することができ、前記ユーザが１つ以上のベンダに地域閲覧依頼を要求することができ、前記地域閲覧依頼が許可されれば前記ベンダの前記地域のノルマと締め切り時間と現在の需要が閲覧でき、実際に前記地域にオンラインにて発注を手配し前記地域の需要を増やすことができ、その結果前記締め切り時間までに前記地域のノルマが達成できるか否かオンラインにて通知結果を自動発信できることを特徴とする方法である。
【請求項２】
請求１にて記載の方法において、ベンダが登録する際、前記ベンダの固有名詞（会社名、店の名前）と前記ベンダのＰＲ文言と前記ベンダの住所と前記ベンダのＰＲ用写真（以下これらを「ベンダ情報」という）を登録することができ、請求１にて記載されるユーザが閲覧する際前記の前記ベンダ情報を閲覧することができることを特徴とする方法である。
【請求項３】
請求１にて記載の方法において、前記ベンダが前記商品・サービスを登録する際、前記商品・サービスの固有名詞と前記商品・サービスの説明文と前記商品・サービスの単価と前記商品・サービスの通貨単位と前記商品・サービスのＰＲ用写真（以下これらを「サービス情報」という）を登録することができ、請求１にて記載されるユーザが閲覧する際前記の前記ベンダ情報を閲覧することができることを特徴とする方法である。
【請求項４】
請求１にて記載の方法において、前記ベンダが前記地域を登録する際、前記地域の固有名詞と前記地域の説明文と前記地域の締め切り時間と前記地域のノルマと前記地域のノルマ単位と前記地域のサービス実施時間を登録することができ、請求１にて記載されるユーザが閲覧する際前記ベンダ情報を閲覧することができることを特徴とする方法である。
【請求項５】
請求１にて記載の方法において、前記ユーザが登録する際、前記ユーザのパスワードと前記ユーザの実名と前記ユーザのニックネームと前期ユーザの１つ以上のサービス対象住所と前記サービス対象住所の電話番号を登録する事ができることを特徴とする方法である。
【請求項６】
請求５にて記載の方法において、前記パスワードと前記実名と前記ニックネームが常時変更できることを特徴とする方法である。
【請求項７】
請求５にて記載の方法において、前記サービス対象住所は常時増やせることができることを特徴とする方法である。
【請求項８】
請求５にて記載の方法において、前記サービス対象住所の中から必ず１つの前記サービス対象住所しか有効になっておらず、以下これを「有効なサービス対象住所」ということを特徴とする方法である。
【請求項９】
請求８にて記載の方法において、どの前記サービス対象住所が有効にするかは前記ユーザが常時変更できることを特徴とする方法である。
【請求項１０】
請求５にて記載の方法において、前記ユーザは前記サービス対象住所を前記ベンダに公開することができることを特徴とする方法である。
【請求項１１】
請求１０にて記載の方法において、前記ベンダは前記ユーザの公開された前記サービス対象住所を請求４にて記載された地域に割り当て、その結果割り当て完了通知を前記ユーザに自動発信できることを特徴とする方法である。
【請求項１２】
請求１１にて記載の方法において、前記地域に前記サービス対象住所の前記割り当ては常時変更できることを特徴とする方法である。
【請求項１３】
登録済みの前記ユーザはユーザインタフェース経由にて常時サーバーに登録されてある前記ベンダ情報を閲覧ができ、更に前記サービス情報も閲覧でき、前記サービス情報の中から１つ以上の製品・サービスの発注を手配できることを特徴とする方法である。
【請求項１４】
請求１３にて記載の方法において、前記ユーザが発注を手配した時点での前記有効なサービス対象住所が前記ベンダの地域に割り当たらなければ自動的に有効なサービス対象住所を前記ベンダに公開し自動的に割り当て依頼および請求１にて記載された地域閲覧依頼を前記ベンダに自動発信できることを特徴とする方法である。
【請求項１５】
請求１３にて記載の方法において、前記ユーザが発注を手配した時点での前記有効なサービス対象住所が前記ベンダの地域に割り当たれば前記ユーザが前記地域のサービス実施時間を選択することができることを特徴とする方法である。
【請求項１６】
請求１５にて記載の方法において、前記ユーザが前記サービス実施時間を選択した時点で前記ユーザのニックネームと前記ユーザの発注合計金額及び前記ユーザの発注合計数量を同一地域のユーザに閲覧できるようになることを特徴とする方法である。
【請求項１７】
請求１６にて記載の方法において、同一地域のユーザとはサービス対象住所が同じ地域に割り当たったユーザであることを特徴とする方法である。
【請求項１８】
請求１３にて記載の方法において、前記ユーザの発注は割り当たった地域の締め切り時間までに削除できることを特徴とする方法である。
【請求項１９】
請求１にて記載の方法において、前記地域のノルマが達成できる場合前記発注を手配した前記ユーザから第３者（クレジット会社、オンラインペイメント会社など）経由支払いを確保することができることを特徴とする方法である。
【発明の詳細な説明】
【技術分野】
【０００１】本発明は、オンラインショップの製品やサービスの受発注に関するシステムである。
【背景技術】
【０００２】インターネット技術の進歩やフリーソフトの普及につれて、オンラインショップのビジネスモデルも発展してきた。【０００３】基本的に、今日のオンラインショップというのはサーバーとユーザインタフェースから成り立つシステムである。サーバーには、ベンダの固有名詞、紹介文、ベンダの商品・サービスの紹介などのベンダ情報が格納されている。【０００４】もうひとつのサーバーの役割は、ユーザからの指示を処理し事前に定められたプログラムを実行し、その回答をユーザに返すことである。【０００５】ユーザインタフェースは主にブラウザが使用されているが、それだけとは限らない。場合により、専用ユーザインタフェースを用いられることもある。ユーザは、ユーザインタフェース経由でサーバーに指示を出したりサーバーの回答を確認したりする仕組みになっている。【０００６】これに対し、インターネット世界の全般に知識やナレッジを共有するという動きが見られる。また、ＷｉｋｉｐｅｄｉａやＭｉｘｉやＦｒｉｅｎｄｓｔｅｒなどにて見られるように、安易に共有するだけでなく、範囲を設けて共有する。【０００７】本発明にも、共有及び範囲は大事な概念である。
【発明開示】
【発明が解決しようとする課題】
【０００８】オンラインショップに限らず、一般論としてベンダは利益を生み出さなければならないという宿命を背う。それを満たすのに、ベンダは常に原価を計算し、それに見合った売値を公開する。
【０００９】また、利益を生み出すのにベンダは原価をできるだけ抑える努力を常に行っている。例えば出前業者は、原価を抑えるのに配達地域を限定したり最小注文数量や最低注文金額を設定したり原価を抑える努力を行っている。同様に、地方空港からハブ空港まで小型機を飛ばし運営している航空会社は燃費の良い小型機を運用したり便数を減らしたりし原価を抑える努力を行っている。
【００１０】ところが、このようなさービス制限はビジネスオポチュ二ティを見逃す恐れがある。例えば、ある潜在顧客が６００円のカレーの出前を頼もうとしているとする。しかし、出前業者が設定した最低注文金額が１０００円を知って出前を頼むのをあきらめ近くのコンビニやレストランで食事を済ませることにした。このような潜在顧客が１人しか居ないなら仕方がないかもしれないが、１０人ぐらい居る場合しかも全員同じ地域（つまり、配達コスト的に損益分岐点内にある）に居る場合、かなり大きなビジネスオポチュ二ティのロスが考えられる。
【００１１】同様に、例えばある潜在顧客が小型飛行機を利用し東京からある地方空港へ行こうとしているとする。しかし、便数の少なさ（例えば週に一回）にあまりにも驚き小型飛行機を利用するのが断念した。１人しか居ない場合なら仕方がないかもしれないが、そのような潜在顧客が例えば特別便がたつほど大勢居る場合かなり大きなビジネスオポチュ二ティのロスが考えられる。
【００１２】このように、世の中に個別に考えればなんでもないことのないように見えてもトータル的に考えたら凄く無視できないぐらい大きなビジネスオポチュ二ティはある。本発明は、そのようなビジネスオポチュ二ティを見逃さないように工夫されたビジネスモデルである。
【課題を解決するための手段】
【００１３】上述の課題を解決するのに、本発明のビジネスモデルは潜在的な需要を公開する仕組みを備えている。しかし、安易に需要を公開するだけではかえって的外れになる。そこで、本発明に、地域とその地域の締め切り時間、サービス実施時間及びノルマという概念が導入されている。それによって、地域別の潜在的な需要が定量化され、その地域の最も適切な対応ができると考えられる。
【００１４】ベンダは、自由に１つまたは複数の地域を定義することができる。その地域の範囲は自由である。ひとつのビルがひとつの地域として定義することができれば、ひとつの町をひとつの地域として定義することも可能である。それぞれの地域の締め切り時間、サービス実施時間及びノルマもベンダの自由である。兎に角、ベンダにとって最も損益分岐点を達成しやすい組み合わせが自由自在に設定できる。
【００１５】例えばベンダは次のような地域設定ができる。東京の大手町にあるビル一棟からランチの時間に多数の注文が出ると予測したとするとそのビル一棟をひとつの地域として定義し、出前配達時間（つまりサービス実施時間）を１２時００分に設定し、締め切り時間を１１時３０分に設定し、ノルマを１万円に設定したとする。つまり、１１時３０分までにそのビルから合計１万円以上の出前注文が確認できれば注文が成立しその旨を伝えるオンライン通知が関連したユーザ及びベンダに自動発信され注文した全員に注文した品物を配達され、逆に達成ができなければ前注文が自動的にキャンセルされその旨を伝えるオンライン通知が関連したユーザ及びベンダに自動発信されるという設定である。
【００１６】このような設定をその地域に割り当たったユーザに公開される。そうすると、ユーザが現時点どのぐらいの注文が既に受注され、締め切り時間まで後どのぐらいで、ノルマが達成できるまで後どのぐらいの注文が必要としているのかが閲覧できる。閲覧にて得られた情報に基づいてユーザが需要を増やす行動を起こすことが期待できる。例えば、ユーザが自分の手配した発注を見直し他の品物の注文は要る否か検討したり、同僚に声をかけて今日のお昼はこの出前にするように説得したりする行動が期待できる。
【００１７】別の例にて、地方空港からハブ空港まで小型機を飛ばし運営している航空会社の場合あるひとつの地方空港を地域として定義し、小型飛行機の出発日時（つまりサービス実施時間）を毎日の１２時００分に設定し、締め切り時間を同日の６時００分に設定し、ノルマを小型飛行機の６割満席に設定したとする。つまり、朝６時まで小型飛行機の６割満席が達成できればその旨を伝えるオンライン通知が関連したユーザ及び小型飛行機の運営会社に自動発信されその日の１２時便が予定通り運行し、逆に達成できなければその旨を伝えるオンライン通知が関連したユーザ及び小型飛行機の運営会社に自動発信され自動的に欠航便になるという設定である。
【００１８】このような設定をその地域に割り当たったユーザに公開される。そうすると、ユーザが現時点どのぐらいの予約が既に受注され、締め切り時間まで後どのぐらいで、ノルマが達成できるまで後どのぐらいの予約が必要としているのかが閲覧できる。閲覧にて得られた情報に基づいてユーザが需要を増やす行動を起こすことが期待できる。例えば、ユーザが自分の日程を確認し、ノルマが最も達成しやすい日時にずらぜないか否か、友人や親戚に声をかけて一緒に乗るように説得し地域のノルマが達成できるような行動を起こすことが期待できる。
【発明の効果】
【００１９】このように、本発明により潜在的な需要が吸い上げされ定量化される。また、ユーザを最も需要の大きい方向に促す効果も持っている。もちろん本発明に平行して従来のビジネスモデルにて営業を営んでも構わない。
【発明を実施するための最良の形態】
【００２０】図２にあるようにユーザがログオン画面から１０１及び１０２にそれぞれユーザＩＤ及びパスワードを入力し、１０３を選択する。【００２１】図２の１０３を選択すると図３のロジックが走り、図３の２０４の判定が出たら図２の画面に戻る。逆に図３の２０３の判定が出たら図４の画面が表示される。【００２２】ただし、４０１のベンダ管理は図５に供述されたロジックに従って表示するか否かの仕組みである。ベンダ権限を所有すれば表示され、所有しなければ表示されない。【００２３】図４のベンダ管理が表示された状態にて、それを選択するとメニュが図６のように展開される。７０１〜７０５は、ユーザＩＤが管轄しているベンダの情報をベンダマスタから検索し表示する。【００２４】ユーザが７０１〜７０５までのベンダ情報を必要に応じて変更することができ７０６を選択し実行すると７０１〜７０５までの情報をベンダマスタに上書きする。【００２５】６０１を選択するとユーザＩＤが図５のロジックに従って権限マスタに比較しベンダ権限を持っているか否か判定され、ベンダ権限を持っていれば管轄しているベンダコードを地域マスタに照らし合わせ、ヒットがあれば図７のように表示される。８０２には前記ベンダコード関連の地域情報（地域固有名詞、地域説明文、締め切り時間、サービス実施時間、ノルマ数量若しくはノルマ金額）が表示されている。【００２６】８０１の地域追加を選択し実行すると図８の画面が現れる。すべてのデータが必須のためユーザがすべてのデータを９０１〜９０３まで入力し、最後に９０７を選択し実行すると図７に戻り、その間裏には図１０のようなアルゴリズムが実行される。合格の場合のみ入力されるデータが保存される。【００２７】詳細の９０３は、複数の行から成り立つ場合もある。各行は、次の図９のようなデータから成り立つ。【００２８】図７にての８０３を選択し実行すると図８のような画面が表示されその画面にて登録されてあるデータが編集できる。同様に図９にて詳細が編集できる。ただし保存する際図１０にて述べられたアルゴリズムの後、更にもう一つのチェックが走る。そのチェックとは、前記の地域に確定ではない注文が既に入っているかどうかというチェックである。確定ではない注文が既に入っている場合保存をキャンセルされる。確定ではない注文が入っていなければ保存が実行される。【００２９】なぜ変更の保存のときのみこのようなチェックが走っているかというと、公平性を保てるからである。例えば、ノルマ１万円にて締め切り時間午前１１時の地域にあるユーザが午前１０時３０分に２千円の注文を手配したとする。前記のチェックが施さなければベンダがノルマをあげたり締め切り時間をずらせたり有利な方向に地域設定を変更できてしまう。前記のチェックがあるため、ベンダは注文が確定になってからしか地域の設定を変更することができない。上の例の場合、午前１１時までにノルマが達成できるかどうかが明確になってからしかその地域の設定を変更することができないである。【００３０】図６の画面から６０２を選択するとユーザＩＤが図５のロジックに従って権限マスタに比較しベンダ権限を持っているか否か判定され、ベンダ権限を持っていれば管轄しているベンダコードを地域マスタに照らし合わせ、ヒットがあれば図１１のように表示される。【００３１】図１１の１２０１に複数の割り当て済みの顧客住所がリストアップされている。また、この部分にて割り当ての変更を行うことができる。その場合、１２０１にて必要な変更を行ってから１２０７を選択し実行する。そうすると、図１０のロジックが走る。その後、更にもう一つのチェックが走る。そのチェックというのは、前記の地域に確定ではない注文が既に入っているかどうかというチェックである。確定ではない注文が既に入っている場合、変更の保存がキャンセルされる。確定ではない注文が入っていなければ保存が実行される。【００３２】なぜ変更の保存のときのみこのようなチェックが走っているかというと、やはり公平性を保てるからである。例えば、ノルマ１万円にて締め切り時間午前１１時の地域にあるユーザが午前１０時３０分に２千円の注文を手配したとする。前記のチェックが施さなければベンダがノルマをあげたり締め切り時間をずらせたりユーザの割り当てを変更したり有利な方向に地域設定を変更できてしまう。前記のチェックがあるため、ベンダは注文が確定になってからしか地域の設定を変更することができない。【００３３】図６の画面から６０３を選択するとユーザＩＤが図５のロジックに従い権限マスタに比較されベンダ権限を持っているか否かが判定され、ベンダ権限を持っていれば管轄しているベンダコードがサービスマスタに照らし合わされ、ヒットがあれば図１２のように表示される。１３０２には前記ベンダコード関連のサービス情報（サービス固有名詞、サービス説明文、サービス値段、サービス写真）が表示されている。【００３４】１３０１のサービス追加を選択し実行すると図１３の画面が現れる。ユーザがデータを１４０１〜１４０４まで（１４０４のサービス写真以外すべては必須項目）入力し、最後に１４０７を選択し実行すると図１２に戻り、その間裏には図１４のようなアルゴリズムが実行される。合格の場合のみ入力されるデータが保存される。【００３５】図１２にての１３０３を選択し実行すると図１３のような画面が表示され其の画面にて登録されてあるデータが編集できる。ただし保存する際図１４にて述べられたアルゴリズムの後、更にもう一つのチェックが走る。そのチェックとは、前記のサービスに対し確定ではない注文が既に入っているか否かというチェックである。確定ではない注文が既に入っている場合保存をキャンセルされる。確定ではない注文が入っていなければ保存が実行される。【００３６】なぜ変更の保存のときのみこのようなチェックが走っているかというと、公平性を保てるからである。例えば、ノルマ１万円にて締め切り時間午前１１時の地域にあるユーザが午前１０時３０分に２千円の注文を手配したとする。前記のチェックが施さなければベンダが値段を変更したりし有利な方向に地域設定を変更できてしまう。前記のチェックがあるため、ベンダは注文が確定になってからしか地域の設定を変更することができない。上の例の場合、午前１１時までにノルマが達成できるかどうかが明確になってからしかその地域の設定を変更することができないである。【００３７】図４にある３０２の注文残を選択し実行すると図１５のように注文情報が照会される。１６０２の注文残詳細は１つまたは複数の行から成り立っている。【００３８】図１５の１６０２の各行に以下の図１６に記述されている情報が表示されている。【００３９】図１６の画面では、１７０１の削除フラグを立てたり、１７０９のサービス実施時間を変更したりすることができる。その場合、１７１１の実行を選択された時点でデータベースに反映される。両方を同時に行われ、直後に１７１１の実行を選択されると、削除フラグが優先されデータがデータベースから削除される。【００４０】どちらのケースでももう一つのチェックが走る。そのチェックとは、前記の注文残が既に確定しているか否かというチェックである。確定の注文残の場合、保存がキャンセルされる。確定ではない注文残の場合保存が実行される。【００４１】なぜ変更の保存のときのみこのようなチェックが走っているかというと、公平性を保てるからである。例えば、ノルマ１万円にて締め切り時間午前１１時の地域にあるユーザが午前１０時３０分に２千円の注文を手配したとする。前記のチェックが施さなければユーザが確定した注文のキャンセルや時間の変更ができてしまう。前記のチェックがあるため、ユーザは注文が確定になる前しかキャンセルしたり時間変更したりすることができない。上の例の場合、午前１１時までキャンセルしたり時間変更したりすることができる。【００４２】１７１０のステータスは、締め切り時間の前のとき、締め切り時間が過ぎノルマが達成されないとき及び締め切り時間が過ぎノルマが達成されたときがそれぞれ「注文残」、「自動キャンセル」及び「確定」というステータスであり、サーバーが自動的に割り当てる。【００４３】図４の３０３プロファイル変更を選択し実施すると図１７のような画面が表示される。この画面にて、ユーザが同時に名字変更やニックネーム変更やパスワード変更を行うことができる。ただし、名字と名字のふりがなとニックネームが必須項目なのでこれらのフィルドを空にすることができない。【００４４】図４の３０４の住所変更を選択し実施すると図１８のような画面が表示される。この画面にて、１９０２にサービス対象住所が表示される。複数の住所が登録されれば、１９０２に複数のサービス対象住所が表示される。また、この画面にもサービス対象住所の削除や有効なサービス対象住所の設定を行うことができる。同時に行われる場合、削除操作が優先される。【００４５】削除操作の場合、やはり削除対象となる住所に注文が既に登録されているかどうかというチェックが走る。既に、注文が登録されれば削除ができないことになっている。【００４６】図４にある３０１のベンダ選択を選択し実施すると図１９のような画面が表示される。図では３つのベンダしか表示されないが、実際に表示されるベンダは技術や必要に応じて異なる。また２００１、２００２、２００３などの各ラインに少なくとも図２０のような情報が記載されている。【００４７】また図１９の状態にてユーザは表示されるどのベンダにもジャンプすることができる。図１９どのラインかを選択し実施すると図２１のような画面が表示される。【００４８】また図２１での２２０６のサービスメニュ一覧は図２２のような情報が含まれている。【００４９】ユーザが、手配したい数量を入力の上図２１の２２０７発注を選択し実施すると図２３のような確認画面が現れる。この画面にてユーザが手配内容を確認することができる。ただし、図２３のサービスメニュ一覧は図２２のような情報が含まれているとする。また、２４０８の住所データはユーザが図４の３０４住所変更経由で登録した住所データ一覧が表示される。ユーザがこの一覧からサービス対象住所を選択することができる。【００５０】ユーザが図２３の２４０７の確認を選択し実施すると手配内容とサービス対象住所が図４の３０２にｐｏｓｔｉｎｇされる。【００５１】ユーザが図４の３０６の全体の需要を選択し実施すると図２４のような画面が表示される。この画面にて、ユーザは自分の地域にどのぐらい需要があるのか、ノルマとの差がどのぐらいあるのか、締め切りまでどのぐらい時間があるのか、一目瞭然である。この画面を参考にして、ユーザが自分の注文を追加したり職場の友人に声をかけて注文を追加したりすることが期待できる。【００５２】ただし、操作するユーザに割り当たっていない地域が表示されない。また、図２４の２５０７全ユーザの注文内容は図２５のように展開できるとする。
【図面の簡単な説明】
【００５３】
【図１】オンライン需要定量化システム
【図２】ログオン画面
【図３】ログオンプロセス
【図４】ログオン済み画面
【図５】ベンダ管理権限の判定
【図６】ベンダ管理の画面
【図７】地域管理の画面
【図８】地域追加・変更の画面
【図９】地域の詳細
【図１０】地域追加・変更のアルゴリズム
【図１１】顧客住所の地域割当て画面
【図１２】ベンダのサービスメニュ一覧
【図１３】サービス追加・変更の画面
【図１４】サービス追加・変更のアルゴリズム
【図１５】注文残照会画面
【図１６】注文残詳細
【図１７】プロファイル変更画面
【図１８】住所変更画面
【図１９】ベンダ一覧
【図２０】表示されるベンダ情報
【図２１】選択されたベンダの詳細画面
【図２２】サービスメニュ一覧の詳細
【図２３】選択されたベンダの確認画面
【図２４】全体需要の画面
【図２５】各ユーザの注文内容画面
【図１】
2009151736.tif 000003
【図２】
2009151736.tif 000004
【図３】
2009151736.tif 000005
【図４】
2009151736.tif 000006
【図５】
2009151736.tif 000007
【図６】
2009151736.tif 000008
【図７】
2009151736.tif 000009
【図８】
2009151736.tif 000010
【図９】
2009151736.tif 000011
【図１０】
2009151736.tif 000012
【図１１】
2009151736.tif 000013
【図１２】
2009151736.tif 000014
【図１３】
2009151736.tif 000015
【図１４】
2009151736.tif 000016
【図１５】
2009151736.tif 000017
【図１６】
2009151736.tif 000018
【図１７】
2009151736.tif 000019
【図１８】
2009151736.tif 000020
【図１９】
2009151736.tif 000021
【図２０】
2009151736.tif 000022
【図２１】
2009151736.tif 000023
【図２２】
2009151736.tif 000024
【図２３】
2009151736.tif 000025
【図２４】
2009151736.tif 000026
【図２５】
2009151736.tif 000027