(57)【要約】【課題】購入済み商品を任意のタイミングで引き取ることを可能とするとともに、引き取りの際における購入済み商品の欠品の発生を防止する。【解決手段】ユーザ端末１００は、引き取り対象の購入済み商品を指定し、指定された購入済み商品に係る情報を、食材管理販売サーバ３００に送信する。食材管理販売サーバ３００は、購入済み商品に係る情報をユーザ端末１００から受信し、購入済み商品に係る情報に基づいて、ユーザの引き取り対象の購入済み商品を管理する。【選択図】図１
2014182616.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが所持する端末装置と管理サーバとが通信ネットワークを介して接続される購入済み商品引き取りシステムであって、
前記端末装置は、
引き取り対象の購入済み商品を指定する引き取り対象指定手段と、
前記引き取り対象指定手段により指定された前記購入済み商品に係る情報を、前記管理サーバに送信する引き取り対象情報送信手段とを有し、
前記管理サーバは、
前記購入済み商品に係る情報を前記端末装置から受信する引き取り対象情報受信手段と、
前記引き取り対象情報受信手段により受信された前記購入済み商品に係る情報に基づいて、前記ユーザの引き取り対象の購入済み商品を管理するユーザ管理手段とを有することを特徴とする購入済み商品引き取りシステム。
【請求項２】
前記端末装置は、
購入対象商品を指定する購入対象商品指定手段と、
前記購入対象商品指定手段により指定された前記購入対象商品に係る情報を、前記管理サーバに送信する購入対象商品情報送信手段とを更に有し、
前記管理サーバは、
前記購入対象商品に係る情報を前記端末装置から受信する購入対象商品情報受信手段を更に有し、
前記ユーザ管理手段は、前記購入対象商品情報受信手段により受信された前記購入対象商品に係る情報に基づいて、前記ユーザの購入済み商品を管理することを特徴とする請求項１に記載の購入済み商品引き取りシステム。
【請求項３】
前記管理サーバは、
前記ユーザ管理手段において管理される、前記ユーザの引き取り対象の購入済み商品と、前記ユーザの購入済み商品とに基づいて、前記ユーザによる購入済み商品の引き取りを許可するか否かを判定する引き取り判定手段を更に有することを特徴とする請求項２に記載の購入済み商品引き取りシステム。
【請求項４】
前記端末装置は、
前記ユーザの引き取り対象の購入済み商品の加工を指定する加工指定手段と、
前記加工指定手段により指定された前記加工に係る情報を、前記管理サーバに送信する加工情報送信手段とを更に有し、
前記管理サーバは、
前記加工に係る情報を前記端末装置から受信する加工情報受信手段と、
前記加工情報受信手段により受信された前記加工に係る情報を、前記ユーザの購入済み商品の引き取り先となる店舗の端末装置に送信する加工情報送信手段とを更に有することを特徴とする請求項１乃至３の何れか１項に記載の購入済み商品引き取りシステム。
【請求項５】
前記店舗サーバは、
前記購入対象商品に係る情報と、前記ユーザの購入量を制限するための制限情報とに基づいて、前記ユーザによる当該購入対象商品の購入を許可するか否かを判定する購入判定手段を更に有することを特徴とする請求項１乃至４の何れか１項に記載の購入済み商品引き取りシステム。
【請求項６】
前記管理サーバは、
前記ユーザの引き取り対象の購入済み商品の代替品を選択する代替品選択手段を更に有することを特徴とする請求項１乃至４の何れか１項に記載の購入済み商品引き取りシステム。
【請求項７】
ユーザが所持する端末装置と管理サーバとが通信ネットワークを介して接続される購入済み商品引き取りシステムの制御方法であって、
前記端末装置は、
引き取り対象の購入済み商品を指定する引き取り対象指定ステップと、
前記引き取り対象指定ステップにより指定された前記購入済み商品に係る情報を、前記管理サーバに送信する引き取り対象情報送信ステップとを有し、
前記管理サーバは、
前記購入済み商品に係る情報を前記端末装置から受信する引き取り対象情報受信ステップと、
前記引き取り対象情報受信ステップにより受信された前記購入済み商品に係る情報に基づいて、前記ユーザの引き取り対象の購入済み商品を管理するユーザ管理ステップとを有することを特徴とする購入済み商品引き取りシステムの制御方法。
【請求項８】
請求項１乃至６の何れか１項に記載の購入済み商品引き取りシステムの各手段としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えばスーパー等の店舗で購入した商品を引き取る際に利用される技術に関するものである。
【背景技術】
【０００２】
一人暮らしや大家族の家庭では、スーパーマーケット等で販売されている食材の単位が多すぎたり少なすぎたりするということがよく発生する。結果として、多めに食材を購入し、家庭で保管することになる。生鮮食品であると冷蔵庫に保管するが、当然ながら場所を取ることになり、或いは、冷蔵庫に入れたがために消費期限を見過ごしてしまうこと等、不便もある。
【０００３】
このような不便を改善する目的で、例えば特許文献１のような提案がなされている。これは、販売店で買い物をするときに、販売店において事前の処理を必要とする食材を予約注文する予約注文システムである。その仕組みは、ユーザは店舗が用意した調理メニューを端末等で見て、店舗に出向く前にユーザが端末から人数等を入力すると、店舗では、当該食品の在庫を確認して在庫があれば、そのユーザが指定した人数分の食材を店舗側が準備しておくものである。例えば、店舗では調理メニューを用意しておくことで大量入荷した食材を売りさばくことができ、ユーザも必要量を注文できるため、無駄なく買い物ができるという効果を奏する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０００−３０６０００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来技術において、ユーザは欲しい食材を欲しい量だけ購入することはできるが、店舗側で準備した調理メニューから選択するものであり、ユーザが購入済み商品をいつでも好きなタイミングで引き取れるものではない。
【０００６】
そこで、本発明の目的は、購入済み商品を任意のタイミングで引き取ることを可能とするとともに、引き取りの際における購入済み商品の欠品の発生を防止することにある。
【課題を解決するための手段】
【０００７】
本発明の購入済み商品引き取りシステムは、ユーザが所持する端末装置と管理サーバとが通信ネットワークを介して接続される購入済み商品引き取りシステムであって、前記端末装置は、引き取り対象の購入済み商品を指定する引き取り対象指定手段と、前記引き取り対象指定手段により指定された前記購入済み商品に係る情報を、前記管理サーバに送信する引き取り対象情報送信手段とを有し、前記管理サーバは、前記購入済み商品に係る情報を前記端末装置から受信する引き取り対象情報受信手段と、前記引き取り対象情報受信手段により受信された前記購入済み商品に係る情報に基づいて、前記ユーザの引き取り対象の購入済み商品を管理するユーザ管理手段とを有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、購入済み商品を任意のタイミングで引き取ることが可能となるとともに、引き取りの際における購入済み商品の欠品の発生を防止することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の第１及び第２の実施形態に係る購入済み商品引き取りシステムの構成を示す図である。
【図２】食材管理販売サーバのハードウェア構成を示す図である。
【図３】本発明の第１の実施形態に係る購入済み商品引き取りシステムにおける、商品購入時の処理の流れを示すフローチャートである。
【図４】本発明の第１の実施形態に係る購入済み商品引き取りシステムにおける、購入済み商品の引き取り予約時の処理の流れを示すフローチャートである。
【図５】本発明の第１の実施形態に係る購入済み商品引き取りシステムにおける、購入済み商品の引き取り時の処理の流れを示すフローチャートである。
【図６】ユーザ管理テーブルの構成例を示す図である。
【図７】商品管理テーブルの構成例を示す図である。
【図８】スーパー在庫管理テーブルの構成例を示す図である。
【図９】ユーザ管理テーブルにおける管理内容の推移について具体的に説明するための図である。
【図１０】スーパー在庫管理テーブルにおける管理内容の推移について具体的に説明するための図である。
【図１１】購入済み商品の引き取り予約時にユーザ端末において表示される画面例を示す図である。
【図１２】本発明の第２の実施形態において使用されるグループ管理テーブルの例を示す図である。
【図１３】本発明の第２の実施形態において使用されるユーザ管理テーブルの例を示す図である。
【図１４】本発明の第３の実施形態に係る購入済み商品引き取りシステムの構成を示す図である。
【図１５】本発明の第３の実施形態に係る購入済み商品引き取りシステムにおける、購入済み商品の引き取り時の処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【００１１】
先ず、本発明の第１の実施形態について説明する。図１は、本発明の第１の実施形態に係る購入済み商品引き取りシステムの構成を示す図である。図１に示すように、本実施形態に係る購入済み商品引き取りシステムは、ユーザが所持するスマートフォンや携帯電話等の通信端末であるユーザ端末１００、スーパーマーケット（以下、スーパーと称す）に設置されるＰＣ等の通信端末であるスーパー端末２００、本実施形態に係る購入済み商品引き取りシステムを制御する食材管理販売サーバ３００、及び、冷蔵庫データベース４００を備える。なお、ユーザ端末１００、スーパー端末２００及び食材管理販売サーバ３００は、インターネット等を介して互いに通信可能に接続されている。食材管理販売サーバ３００と冷蔵庫データベース４００とは、専用線により通信可能に接続されている。なお、食材管理販売サーバ３００と冷蔵庫データベース４００とは一つのコンピュータで構成してもよく、また、スーパー端末２００がこれらの機能を備えていてもよい。
【００１２】
図１に示すように、食材管理販売サーバ３００は、ユーザ管理部３０１、スーパー在庫管理部３０２及び商品管理部３０３を備える。冷蔵庫データベース４００は、ユーザ管理テーブル４０１、スーパー在庫管理テーブル４０２及び商品管理テーブル４０３を備える。ユーザ管理部３０１は、ユーザ管理テーブル４０１を用いて、各ユーザの「冷蔵庫」の状況を管理する。ここでいう「冷蔵庫」とは、仮想的な冷蔵庫を意味している。即ち、ユーザがスーパーから既に商品を購入しているが、未だスーパーに引き取りに行っておらず、スーパー側で購入済み商品を預かってもらっている状態にある場合、このときのスーパーの状態は、購入済み商品を保管している「冷蔵庫」と捉えることができる。従って、本実施形態では、スーパー側において購入済み商品を預かってもらっている状態を、仮想的な「冷蔵庫」において購入済み商品を収納している状態とみなすものとする。勿論、「冷蔵庫」からは購入済み商品をいつでも取り出すことができるのと同様に、ユーザは購入済み商品をスーパーの営業時間内にいつでも引き取りに行くことができる。なお、ここでは「冷蔵庫」という表現を用いるが、商品としては冷蔵庫に保管するものに限らない。
【００１３】
スーパー在庫管理部３０２は、スーパー在庫管理テーブル４０２を用いて、スーパーにおける各商品の在庫状況を管理する。商品管理部３０３は、商品管理テーブル４０３を用いて、スーパーで販売されている各商品の商品情報（商品名、産地、価格等）を管理する。
【００１４】
ここで、図６を参照しながら、ユーザ管理テーブル４０１の構成例について説明する。図６に示す例のユーザ管理テーブル４０１では、ユーザＩＤ、ユーザの氏名、ユーザが契約している「冷蔵庫」のサイズ、当該「冷蔵庫」で収納される商品のＩＤ、当該「冷蔵庫」で現在収納している各商品の保有量、当該「冷蔵庫」における商品の保有量の制限値、及び、当該「冷蔵庫」で現在収納している各商品について予約されている引き取り量が管理されている。
【００１５】
より具体的には、図６に示すユーザ管理テーブル４０１は、ユーザＩＤ“Ａ００１”のユーザは、“標準”サイズの「冷蔵庫」を契約しており、この“標準”サイズの「冷蔵庫」には、商品ＩＤ“００１”に該当する商品が“３”個まで、商品ＩＤ“００２”に該当する商品が“５”個まで、商品ＩＤ“００３”に該当する商品が“３”個まで、商品ＩＤ“００４”に該当する商品が“２”個まで収納可能であることを示している。また、図６に示すユーザ管理テーブル４０１は、現在、この冷蔵庫には、商品ＩＤ“００１”に該当する商品が１個、商品ＩＤ“００２”に該当する商品が２個、商品“００３”に該当する商品が０個、商品ＩＤ“００４”に該当する商品が２個収納されていることを示している。さらに、図６に示すユーザ管理テーブル４０１は、現在、ユーザＩＤ“Ａ００１”に該当するユーザが、商品ＩＤ“００１”に該当する購入済みの商品について、スーパーから“０．２５”個引き取ることを予約していることを示している。なお、ユーザ管理テーブル４０１において設定される「冷蔵庫」のサイズは、“大”サイズ、“標準”サイズ及び“小”サイズ等の複数のサイズから所望のサイズを契約に応じて選択することができる。また、いずれかのサイズをひとつ選択するだけでなく、“標準＋小”や例えば標準が３００リットルである場合に、“標準＋１０リットル”等のように、数値で設定するようにしてもよい。
【００１６】
また、図６の例では、商品毎に収容可能な制限値を設定しているが、「冷蔵庫」全体で収容可能な制限値を設定してもよい。或いは、商品毎の制限値の合計値が「冷蔵庫」全体の制限値以下となるように各商品の制限値を設定してもよい。
【００１７】
次に、図７を参照しながら、商品管理テーブル４０３の構成例について説明する。図７に示す例の商品管理テーブル４０３では、商品ＩＤ、当該商品ＩＤに該当する商品の商品名、当該商品の産地、当該商品の規定サイズ、及び、当該商品の価格帯ランクが管理されている。より具体的には、図７に示す商品管理テーブル４０３は、例えば、商品ＩＤ“００１”に該当する商品の商品名は“キャベツ”であり、その産地が“長野県”、１個当たりのサイズ（規定サイズ）が“１０００ｇ”であり、価格帯ランクが“Ａ”であることを示している。ここで、“キャベツ”１個当たりのサイズ（規定サイズ）が“１０００ｇ”というのは、実際に重さが１０００ｇのキャベツ１個を示すものではなく、“キャベツ１個分＝１０００ｇ相当”という単位としての情報である。同様に、商品ＩＤ“００２”の“豚肉”であれば、“豚肉１個分＝１００ｇ相当”となる。なお、価格帯ランクについては後に詳述する。
【００１８】
次に、図８を参照しながら、スーパー在庫管理テーブル４０２の構成例について説明する。図８に示す例のスーパー在庫管理テーブル４０２では、商品ＩＤ、当該商品ＩＤに該当する商品のスーパーにおける在庫量、及び、当該商品について予約されている引き取り量が管理されている。より具体的には、図８に示すスーパー在庫管理テーブル４０２は、例えば、商品ＩＤ“００１”に該当する商品のスーパーにおける在庫量が“３０”個であり、当該商品について予約されている引き取り量が“０．２５”個であることを示している。上術の通り商品ＩＤ“００１”の“キャベツ”は１個当たりのサイズ（規定サイズ）が“１０００ｇ”であるため在庫量が“３０”個の場合、在庫総量は３００００ｇということになる。そして当該商品について予約されている引き取り量が“０．２５”個である場合、“２５０ｇ”が引き取り予定として登録されていることを示している。
【００１９】
図２は、本実施形態における食材管理販売サーバ３００のハードウェア構成を示す図である。図２において、ＣＰＵ２００１は、システムバスに接続される各デバイスやコントローラを統括的に制御する。ＲＯＭ２００３又はＨＤ（ハードディスク）２００８には、ＣＰＵ２００１の制御プログラムであるＢＩＯＳ（Basic Input / Output System）やオペレーティングシステムプログラム、食材管理販売サーバ３００が実行する例えば図３のステップＳ１０１〜Ｓ１０２、図４のステップＳ１０３〜Ｓ１０６、及び、図５のステップＳ１０７に示す処理のプログラム等が記憶されている。
【００２０】
なお、図２の例では、ＨＤ２００８は、食材管理販売サーバ３００の内部に配置された構成としているが、他の実施形態としてＨＤ２００８に相当する構成（例えば、ＤＢサーバ）が食材管理販売サーバ３００の外部に配置された構成としてもよい。また、本実施形態に係る例えば図３のステップＳ１０１〜Ｓ１０２、図４のステップＳ１０３〜Ｓ１０６、及び、図５のステップＳ１０７に示す処理を行うためのプログラムは、ＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体に記録され、それらの記録媒体から供給される構成としてもよいし、インターネット等の通信媒体を介して供給される構成としてもよい。
【００２１】
ＲＡＭ２００２は、ＣＰＵ２００１の主メモリ、ワークエリア等として機能する。ＣＰＵ２００１は、処理の実行に際して必要なプログラム等をＲＡＭ２００２にロードして、プログラムを実行することで各種動作を実現するものである。
【００２２】
ＨＤ２００８は、外部メモリとして機能する。ＣＰＵ２００１は、処理の実行に際して必要なプログラム等をＲＡＭ２００２にロードして、プログラムを実行することで各種動作を実現するものである。
【００２３】
ディスクコントローラ２００７は、ＨＤ２００８等の外部メモリへのアクセスを制御する。通信Ｉ／Ｆコントローラ２００６は、インターネットやＬＡＮと接続し、例えばＴＣＰ／ＩＰによって外部との通信を制御するものである。
【００２４】
ディスプレイコントローラ２００９は、ディスプレイ２０１０における画像表示を制御する。ＫＢコントローラ２００４は、ＫＢ（キーボード）２００５からの操作入力を受け付け、ＣＰＵ２００１に対して送信する。なお、図示していないが、ＫＢ２００５の他に、マウス等のポインティングデバイスもユーザの操作手段として本実施形態に係る食材管理販売サーバ３００に適用可能である。
【００２５】
なお、図１に示す３０１〜３０３の構成は、例えばＨＤ２００８内に記憶され、必要に応じてＲＡＭ２００２にロードされるプログラム及びそれを実行するＣＰＵ２００１によって実現される構成である。
【００２６】
なお、ユーザ端末１００及びスーパー端末２００のハードウェア構成は、図２に示したものと基本的に同じ構成であるため、図示は省略する。即ち、本実施形態に係る例えば図３のステップＳ２０１〜Ｓ２０４、図４のステップＳ２０５〜Ｓ２０９、及び、図５のステップＳ２１０〜Ｓ２１３に示す処理を行うためのプログラムは、ユーザ端末１００内のＲＯＭ等のコンピュータ読み取り可能な記録媒体に記録され、それらの記録媒体からＣＰＵに供給される構成としてもよいし、インターネット等の通信媒体を介してＣＰＵに供給される構成としてもよい。また、図５のステップＳ３０１〜Ｓ３０４に示す処理を行うためのプログラムは、スーパー端末２００内のＨＤ等のコンピュータ読み取り可能な記録媒体に記録され、それらの記録媒体からＣＰＵに供給される構成としてもよいし、インターネット等の通信媒体を介してＣＰＵに供給される構成としてもよい。
【００２７】
次に、図３を参照しながら、本実施形態に係る購入済み商品引き取りシステムにおける、商品購入時の処理の流れについて説明する。
【００２８】
ステップＳ１０１において、ユーザ端末１００は、ユーザの操作に応じて、購入対象商品及びその購入量が入力される。ステップＳ１０２において、ユーザ端末１００は、入力された購入対象商品及び購入量を食材管理販売サーバ３００に対して送信する。
【００２９】
ステップＳ２０１において、食材管理販売サーバ３００は、購入対象商品及び購入量をユーザ端末１００から受信する。ステップＳ２０２において、食材管理販売サーバ３００のユーザ管理部３０１は、受信した購入量を加味した当該購入対象商品の「冷蔵庫」における保有量が制限値以下であるか否かを判定する。即ち、ユーザ管理部３０１は、当該購入対象商品の商品ＩＤに該当する「保有量」及び「制限値」をユーザ管理テーブル４０１から参照する。次に、ユーザ管理部３０１は、受信した購入量と「保有量」に示される値との合計値（購入量を加味した購入対象商品の保有量）が、「制限値」に示される値以下であるか否かを判定する。購入量を加味した購入対象商品の保有量が制限値以下である場合、処理はステップＳ２０４に移行する。一方、購入量を加味した購入対象商品の保有量が制限値を超過している場合、処理はステップＳ２０３に移行する。なお、ステップＳ２０４の前段において、購入対象商品及びその購入量に対応する電子決済処理がユーザ端末１００と食材管理販売サーバ３００との間で実行される。なお、本実施形態では、「制限値」に示される値以下であれば、購入出来る仕組みで説明するが、例えば、「下限値」等を設定しておき、「保有量」が下限値を下回った場合に、自動的にあるいはユーザに確認を行った上で購入処理をするようにしてもよい。このようにすることで、定期購入などを行うことも可能となる。
【００３０】
ステップＳ２０３において、食材管理販売サーバ３００は、指定された購入量で購入対象商品を購入した場合、保有量が制限値を超過することになるため、当該購入対象商品を購入することができない旨をユーザ端末１００に対して通知する。そして、処理は終了する。なお、通知するだけでなく、ユーザに対して購入量の再入力を促し、再度ステップＳ２０２での判断を行うようにしてもよい。ステップＳ２０４において、食材管理販売管理サーバ３００のユーザ管理部３０１は、ユーザ管理テーブル４０１を更新する。ここでは、購入対象商品が購入されることにより、ユーザの当該購入対象商品の保有量が増加或いは新規登録されるため、ユーザ管理テーブル４０１において、当該購入対象商品に該当するレコードの「保有量」が上記購入量の分、加算或いは新規登録される。
【００３１】
次に、図４を参照しながら、本実施形態に係る購入済み商品引き取りシステムにおける、購入済み商品の引き取り予約時の処理の流れについて説明する。
【００３２】
ステップＳ１０３において、ユーザ端末１００は、ユーザの操作に応じて、購入済み商品、当該購入済み商品の引き取り量、及び、当該購入済み商品の引き取り日時を入力する。図１１は、購入済み商品の引き取り予約時にユーザ端末１００において表示される画面例を示す図である。なお、ステップＳ１０３の前段において、ユーザ端末１００は、ユーザにより入力されたユーザＩＤ及びパスワードを用いて食材管理販売サーバ３００にアクセスする。食材管理販売サーバ３００は、ユーザＩＤに基づいて図６に示すユーザ管理テーブルを参照することにより図１１に示す画面を生成し、ユーザ端末１００に対して送信する。これにより、ステップＳ１０３において、図１１に示す画面が表示される。ユーザは、図１１に示す画面上において、購入済み商品リストに掲載された購入済み商品から所望の購入済み商品を選択し、該当するチェックボックス１１０１をチェックする。そして、ユーザは、チェックした購入済み商品の引き取り量を引き取り量入力欄１１０２にて入力し、引き取り日時入力欄１１０３で引き取り日時を入力した後、“ＯＫ”ボタン１１０４を押下する。これにより、今回引き取り予定の購入済み商品、引き取り量、及び、引き取り日時の各情報がユーザ端末１００から食材管理販売サーバ３００に対して送信される。なお、スーパー等で購入した商品は通常であれば１個購入した場合に当該１個を持ち帰ることになるが、本実施形態では図１１の引き取り量入力欄１１０２に示す通り、“０．２５個”等のように、１個に満たない数量での引き取りを可能としている。上述したように、この実施形態ではキャベツ１個当たりのサイズ（規定サイズ）が“１０００ｇ”であるため、引き取り量“０．２５個”であれば、ユーザは“２５０ｇ”分のキャベツを引き取ることができる。
【００３３】
ステップＳ１０４において、ユーザ端末１００は、入力された、今回引き取り予定の購入済み商品、引き取り量及び引き取り日時の各情報を食材管理販売サーバ３００に対して送信する。ステップＳ２０５において、食材管理販売サーバ３００は、今回引き取り予定の購入済み商品、引き取り量及び引き取り日時の各情報をユーザ端末１００から受信する。
【００３４】
ステップＳ２０６において、食材管理販売サーバ３００のユーザ管理部３０１は、ユーザ管理テーブル４０１を参照し、購入済み商品の引き取り量が当該購入済み商品の保有量以下であるか否かを判定する。引き取り量が保有量以下である場合、処理はステップＳ２０７に移行する。一方、引き取り量が保有量を超えている場合、処理はステップＳ２０８に移行する。
【００３５】
ステップＳ２０８において、食材管理販売サーバ３００のユーザ管理部３０１は、指定された購入済み商品の引き取り量が、現在のユーザの購入済み商品の保有量よりも多い旨をユーザ端末１００に対して警告通知し、引き取り量を再入力するよう促す。そして、処理はステップＳ１０３に戻って、一連の処理を再度行う。ステップＳ２０７において、食材管理販売サーバ３００のスーパー在庫管理部３０２は、当該購入済み商品の商品ＩＤに該当するレコードの「予約引き取り量」を、上記引き取り量に更新する。ステップＳ２０９において、食材管理販売サーバ３００のユーザ管理部３０１は、当該ユーザ端末１００を所持するユーザのユーザＩＤ、及び、今回の引き取り予約に対応する引き取りＩＤをユーザ端末１００に対して送信する。なお、ここで送信されたユーザＩＤ及び引き取りＩＤは、ステップＳ２０５で受信された購入済み商品、引き取り量及び引き取り日時に対応付けて冷蔵庫データベース４００で保管される。
【００３６】
ステップＳ１０５において、ユーザ端末１００は、ユーザＩＤ及び引き取りＩＤを食材管理販売サーバ３００から受信する。ステップＳ１０６において、ユーザ端末１００は、ユーザＩＤ及び引き取りＩＤを記録媒体に保管する。
【００３７】
次に、図５を参照しながら、本実施形態に係る購入済み商品引き取りシステムにおける、購入済み商品の引き取り時の処理の流れについて説明する。
【００３８】
ステップＳ１０７において、ユーザ端末１００は、ユーザの操作に応じて、保管しているユーザＩＤ及び引き取りＩＤを画面上に表示する。この処理は、ユーザがスーパーにおいて購入済み商品を引き取る際に行われる処理である。ステップＳ３０１において、スーパー端末２００は、スーパーの従業員の操作に応じて、ユーザ端末１００に表示されたユーザＩＤ及び引き取りＩＤを入力する。このとき、スーパーの従業員は、ユーザ端末１００の画面を参照しながら、ユーザＩＤ及び引き取りＩＤをスーパー端末２００に入力する。なお、ステップＳ１０７において、ユーザ端末１００の画面上にユーザＩＤ及び引き取りＩＤのほか、引き取り対象となる購入済み商品の画像を表示させるようにしてもよい。これにより、ユーザ及びスーパーの従業員はともに、どの商品を引き取るのか容易に把握することができる。また、ユーザＩＤの代わりに、ユーザの指紋や網膜等を用いた生体認証によりユーザを識別するようにしてもよい。さらに、ユーザＩＤ及び引き取りＩＤを二次元コード化して、それをスーパー端末２００に接続される読み取り装置に読み取らせるようにしてもよい。或いは、非接触型の通信機能で、ユーザ端末１００とスーパー端末２００とで通信を行い、ユーザＩＤ及び引き取りＩＤをユーザ端末１００からスーパー端末２００に送信してもよい。
【００３９】
また、ユーザＩＤのみをスーパー端末２００に入力し、このユーザＩＤに基づいて食材管理サーバ３００を検索して引き取りＩＤを読み出すようにしてもよい。そして読み出した引き取りＩＤがスーパー端末２００の画面に表示され、ユーザが選択することで引き取り商品を確定してもよい。
【００４０】
ステップＳ３０２において、スーパー端末２００は、入力したユーザＩＤ及び引き取りＩＤを食材管理販売サーバ３００に対して送信する。ステップＳ２１０において、食材管理販売サーバ３００は、ユーザＩＤ及び引き取りＩＤをスーパー端末２００から受信する。ステップＳ２１１において、食材管理販売サーバ３００は、受信したユーザＩＤ及び引き取りＩＤに対応付けて保管されている購入済み商品、引き取り量及び引き取り日時を冷蔵庫データベース４００から読み出し、スーパー端末２００に対して送信する。
【００４１】
ステップＳ２１２において、食材管理販売サーバ３００のユーザ管理部３０１は、ユーザ管理テーブル４０１を更新する。ここでは、引き取られた分だけユーザの当該購入済み商品の保有量が減少するため、ユーザ管理テーブル４０１において、当該購入済み商品の商品ＩＤに該当するレコードの「保有量」が上記引き取り量だけ減算される。ステップＳ２１３において、食材管理販売サーバ３００のスーパー在庫管理部３０２は、スーパー在庫管理テーブル４０２を更新する。ここでは、引き取られた分だけスーパーにおける当該購入済み商品の在庫が減少するため、ユーザ在庫管理テーブル４０２において、当該購入済み商品の商品ＩＤに該当するレコードの「在庫量」が上記引き取り量の分だけ減算される。なお、説明を簡単にするためにステップＳ２１２とステップＳ２１３とでは、それぞれ順次テーブルを更新するよう記載したが、実際には、ステップＳ２１２は「保有量」が上記引き取り量だけ減算されたという情報を一時的に保管しておき、ユーザが引き取りを完了してスーパー端末２００から引き取りが完了した旨の情報を受信したときに一時保管した情報を確定する。その後引き続き、ステップＳ２１３の処理が行われる。
【００４２】
ステップＳ３０３において、スーパー端末２００は、購入済み商品、引き取り量、及び、引き取り日時を食材管理販売サーバ３００から受信する。ステップＳ３０４において、スーパー端末２００は、購入済み商品、引き取り量、及び、引き取り日時を画面上に表示する。スーパーの従業員は、画面上に表示された購入済み商品、引き取り量、及び、引き取り日時を参照し、その表示内容に沿って、購入済み商品をユーザに渡す。
【００４３】
次に、図９を参照しながら、ユーザ管理テーブル４０１における管理内容の推移について具体的に説明する。図９（ａ）は、商品ＩＤ“００１”に該当する商品が購入される直前のユーザ管理テーブル４０１の状態を示している。従って、商品ＩＤ“００１”に該当するレコードの「保有量」は“０”になっている。次に、商品ＩＤ“００１”に該当する商品が１個購入されると、図９（ｂ）に示すように、商品ＩＤ“００１”に該当するレコードの「保有量」は“１”に更新される。なお、本処理は、図３のステップＳ２０４に対応する処理である。
【００４４】
次に、ユーザにより商品ＩＤ“００１”に該当する商品の引き取りが予約された場合、図９（ｃ）に示すように、その引き取り量が、商品ＩＤ“００１”に該当するレコードの「予約引き取り量」において登録される。なお、本処理は、図４のステップＳ２０７に対応する処理である。次に、商品ＩＤ“００１”に該当する商品がスーパーから引き取られた場合、図９（ｄ）に示すように、商品ＩＤ“００１”に該当するレコードの「保有量」が引き取られた量だけ減算される。なお、本処理は、図５のステップＳ２１２に対応する処理である。
【００４５】
次に、図１０を参照しながら、スーパー在庫管理テーブル４０２における管理内容の推移について具体的に説明する。図１０（ａ）は、商品ＩＤ“００１”に該当する商品の引き取りが予約される直前のスーパー在庫管理テーブル４０２の状態を示している。従って、商品ＩＤ“００１”に該当するレコードの「予約引き取り量」が“０”になっている。次に、商品“００１”に該当する商品について、引き取り量“０．２５”が予約されると、図１０（ｂ）に示すように、商品ＩＤ“００１”に該当するレコードの「予約引き取り量」が“０．２５”に更新される。なお、本処理は、図４のステップＳ２０７に対応する処理である。次に、商品ＩＤ“００１”に該当する商品がスーパーから引き取られた場合、図１０（ｃ）に示すように、商品ＩＤ“００１”に該当するレコードの「在庫量」が“３０”から“２９．７５”に更新される。なお、本処理は、図５のステップＳ２１３に対応する処理である。
【００４６】
本実施形態では、「冷蔵庫」に収納される購入済み商品は、スーパーにおける個々の現物と紐付いているのではなく、例えば“キャベツ”を１個購入して「冷蔵庫」に収納している場合、スーパーにおける在庫の不特定の“キャベツ”から、“キャベツ”１個分を小刻みに引き取れるようにしている。つまり、スーパーに実際に在庫として存在している１個のキャベツであっても、あるユーザＡ００１が“０．２５”を引き取り、別のユーザＡ００２が“０．３５”、更に別のユーザＡ００３が残りの“０．４”を引き取る、と言うように現物が必要な分量を切り分けて各ユーザに提供される。これにより、購入済み商品を任意のタイミングで引き取れる仮想的な「冷蔵庫」を構築している。また、本実施形態では、購入済み商品の引き取り予約が行われるため、スーパー側では、実際の購入済み商品の引き取り時までに、当該購入済み商品を準備しておくことができる。従って、ユーザの引き取り時における在庫切れ（欠品）を防ぐことが可能となり、ユーザは、確実に購入済み商品を受け取ることができる。
【００４７】
しかしながら、どうしても、当該購入済み商品を準備することができない場合には、当該購入済み商品と同等或いはそれ以上の価値を有する商品を提供して手当することが考えられる。その際、当該購入済み商品の価格帯ランクが商品管理テーブル４０３から参照され、その価格帯ランクと同等或いはそれ以上の商品が検索される。例えば、価格帯ランクの上位からの順がＡ、Ｂ、Ｃであり、価格帯ランクＢの商品が在庫切れであるとする。このような場合、価格帯ランクＢの商品と価格帯ランクが同等或いはそれ以上の商品として、 価格帯ランクＡの商品が検索される。
【００４８】
このように代替品が提供された場合、ユーザ管理テーブル４０１からは、購入済み商品の商品ＩＤに該当するレコードの「保有量」から、元の引き取り量に対応する値が減算されるが、スーパー在庫管理テーブル４０２からは、代替品の商品ＩＤに該当するレコードの「在庫量」から、当該代替品の提供料に対応する値が減算されることになる。
【００４９】
また、スーパー端末２００は、スーパーの従業員の操作に応じて、食材管理販売サーバ３００に対して処分対象商品を設定するようにしてもよい。処分対象商品とは、例えば、大量に在庫を処分したい商品である。食材管理販売サーバ３００は、処分対象商品に含まれる商品を「冷蔵庫」に収納しているユーザを、各ユーザのユーザ管理テーブルを参照することにより検索する。そして、食材管理販売サーバ３００は、検索したユーザのユーザ端末１００に対して、当該商品を通常時よりも安く販売している旨を示す販売促進情報を送信する。これにより、当該商品を購入する可能性の高いユーザを対象に、処分対象商品の販売促進を図ることが可能となる。
【００５０】
なお、図１１には図示していないが、ユーザは、引き取り対象に選択した購入済み商品に対して施してもらいたい加工処理を入力することもできる。例えば、引き取り対象に選択した購入済み商品が“キャベツ”であれば、“千切り”、“乱切り”、“下ゆで”等の加工処理や調理処理の情報を入力することができる。この場合、図４のステップＳ１０３において加工処理情報が入力され、当該加工処理情報もユーザ端末１００から食材管理販売サーバ３００に対して送信される。さらに、図５のステップＳ２１１において、当該加工処理情報もスーパー端末２００に対して送信される。このように加工処理情報が入力された場合、購入済み商品の引き取り時において、ユーザに対して加工代金を追加請求処理するようにしてもよい。
【００５１】
次に、本発明の第２の実施形態について説明する。なお、第２の実施形態に係る購入済み商品引き取りシステムの構成は、図１に示した構成と同様であるため、第２の実施形態の説明においても、図１の符号を流用するものとする。また、以下では、第１の実施形態と相違する点に主眼をおいて説明する。
【００５２】
図１２は、第２の実施形態において使用されるグループ管理テーブルの例を示す図である。なお、グループ管理テーブルは、冷蔵庫データベース４００内において格納されている。図１２の例では、ユーザＩＤ“Ａ００１”に対応付けて、個別ユーザＩＤ“Ａ００１−１”、“Ａ００１−２”、“Ａ００１−３”及び“Ａ００１−４”が登録されている。これは、個別ユーザＩＤ“Ａ００１−１”、“Ａ００１−２”、“Ａ００１−３”及び“Ａ００１−４”に夫々該当するユーザが、ユーザＩＤ“Ａ００１”に該当する同一のグループに属することを示している。
【００５３】
本実施形態においては、同一のグループに属するユーザが購入した商品は全て、同一の「冷蔵庫」に収納され、その「冷蔵庫」に収納された商品は、同一のグループに属するどのユーザも引き取ることができる。以下、この処理について図１３を参照しながら詳細に説明する。
【００５４】
図１３は、第２の実施形態において使用されるユーザ管理テーブルの例を示す図である。即ち、第２の実施形態では、図６に示したユーザ管理テーブルに代わって、図１３に示すユーザ管理テーブルが使用される。図１３に示すユーザ管理テーブルの例では、グループＩＤ“Ａ００１”に該当するグループにおいて、商品ＩＤ“００１”に該当する商品が１個、商品ＩＤ“００２”に該当する商品が２個、商品ＩＤ“００３”に該当する商品が０個、及び、商品ＩＤ“００４”に該当する商品が２個購入され、同一の「冷蔵庫」に収納されていることを示している。
【００５５】
個別ユーザＩＤ“Ａ００１−１”、“Ａ００１−２”、“Ａ００１−３”及び“Ａ００１−４”に該当するユーザは互いに何れも、上記同一の「冷蔵庫」に収納されたどの商品も取り出すことができる。より具体的には、商品を購入する場合、図３のステップＳ１０２において、ユーザ端末１００から購入対象商品、購入量及び個別ユーザＩＤが食材管理販売サーバ３００に対して送信される。食材管理販売サーバ３００は、商品の購入が確定すると、図３のステップＳ２０４において、図１３に示すユーザ管理テーブルを参照し、ユーザ端末１００から受信した個別ユーザＩＤがどのユーザＩＤに属するかを判定する。そして、食材管理販売サーバ３００は、判定したユーザＩＤに該当するユーザ管理テーブルにおいて、上記購入量の分、上記購入対象商品の商品ＩＤに該当するレコードの「保有量」を加算する。また、商品の引き取り予約を行う場合、図４のステップＳ１０４において、ユーザ端末１００から購入済み商品、引き取り量、引き取り日時及び個別ユーザＩＤの各情報が食材管理販売サーバ３００に対して送信される。食材管理販売サーバ３００は、図４のステップＳ２０７において、図１３に示すユーザ管理テーブルを参照し、ユーザ端末１００から受信した個別ユーザＩＤがどのユーザＩＤに属するかを判定する。そして、食材管理販売サーバ３００は、判定したユーザＩＤに該当するユーザ管理テーブルにおいて、上記引き取り量で、上記購入済み商品の商品ＩＤに該当するレコードの「予約引き取り量」を更新する。以上により、同一のグループに属するユーザが購入した商品は全て、同一の「冷蔵庫」に収納され、その「冷蔵庫」に収納された商品は、同一のグループに属するどのユーザも引き取ることができる、という処理を実現することができる。
【００５６】
購入済み商品を実際に引き取る際には、第１の実施形態と同様に、図４のステップＳ２０９において発行されたユーザＩＤ及び引き取りＩＤをスーパーの従業員に提示する。引き取りＩＤは、引き取り予約を行う度に発行されるＩＤであるため、同一のグループに属する他のユーザの引き取り予約と混同されることはなく、ユーザ毎及び引き取り予約毎に、購入済み商品を引き取ることができる。
【００５７】
また、図１３に示した第２の実施形態におけるユーザ管理テーブルは、図６に示した第１の実施形態におけるユーザ管理テーブルに対し、同一の「冷蔵庫」に収納された商品であっても、同一グループに属する他のユーザによって取り出されないように設定されたか否かを管理するための「鍵フラグ」と、商品が取り出されないように設定したユーザを管理するための「施錠者」とが追加されている。
【００５８】
図１３の例では、個別ユーザＩＤ“Ａ００１−１”に該当するユーザが、商品ＩＤ“００４”に該当する商品（ビール）を、同一グループに属する他のユーザ（ユーザＩＤ“Ａ００１−２”、“Ａ００１−３”、“Ａ００１−４”に該当するユーザ）によって取り出されないように設定していることを示している。これにより、当該他のユーザのユーザ端末１００上において、図１１に示す購入済み商品引き取り予定画面を表示した場合、「鍵フラグ」に“１”が設定されている商品ＩＤ“００４”に該当する商品（ビール）が購入済み商品リストに列挙されなくなる。従って、当該他のユーザが未成年等である場合に、商品ＩＤ“００４”に該当する商品（ビール）の取り出し予約を行うことができないようにすることが可能となる。
【００５９】
また、第２の実施形態では、食材管理販売サーバ３００において、グループ毎に、或るメニューを作成するのに必要な食材及び加工方法を含むレシピ情報を格納してもよい。レシピ情報は、或るグループ（例えば、家族）に属するユーザ（例えば、母親）のユーザ端末１００から食材管理販売サーバ３００に送信されることにより、当該グループのユーザＩＤと対応付けて食材管理販売サーバ３００に格納される。後に、同一のグループに属する他のユーザ（例えば、子供）のユーザ端末１００から食材管理販売サーバ３００に対してアクセスされた場合、食材管理販売サーバ３００は、図１２に示すグループ管理テーブルを参照することにより、当該ユーザ端末１００のユーザが属するグループを判断し、当該グループのユーザＩＤと対応付けてレシピ情報を格納している場合、そのレシピ情報を他のユーザ（例えば、子供）のユーザ端末１００に対して送信可能な状態にする。これにより、同一のグループ（例えば、家族）内でレシピ情報を共有することが可能となる。
【００６０】
また、このように食材管理販売サーバ３００において格納されたレシピ情報のうち、現在、「冷蔵庫」に収納されている食材で作成することが可能なメニューのレシピ情報が存在する場合、食材管理販売サーバ３００は、そのレシピ情報を同一のグループに属する全ユーザ又は一部のユーザのユーザ端末１００に対して配信するようにしてもよい。これにより、現在「冷蔵庫」に収納している食材で作成することができるメニューを推奨することが可能となる。なお、メニュー情報は、食材管理販売サーバ３００内に予め格納しておいてもよい。そして、食材管理販売サーバ３００において予め格納されるメニュー情報を用いて、現在「冷蔵庫」に収納されている食材から作成可能なメニューの推奨を行うこともできる。即ち、本メニューの推奨処理は、第１の実施形態及び後述する第３の実施形態にも適用可能な処理である。
【００６１】
次に、本発明の第３の実施形態について説明する。図１４は、第３の実施形態に係る購入済み商品引き取りシステムの構成を示す図である。図１に示す第１の実施形態に係る購入済み商品引き取りシステムにおいては、スーパー端末が１台であるのに対し、図１４に示す第３の実施形態に係る購入済み商品引き取りシステムにおいては、スーパー端末が複数台である点が相違する。なお、図１４では、スーパー端末を２台示しているが、複数台であれば任意の数のスーパー端末を配置することができる。
【００６２】
図１４において、２０１は、スーパーＡに設置されたＰＣ等の通信端末であるスーパーＡ端末である。２０２は、スーパーＢに設置されたＰＣ等の通信端末であるスーパーＢ端末である。２０２１は、スーパーＢ端末２０２と専用回線を介して接続され、スーパーＢにおける在庫等を管理するためのスーパーＢデータベースである。スーパーＡとスーパーＢとは例えば系列店のような関係であり、食材管理販売サーバ３００は、これら各スーパーにおける各商品の在庫状況や商品情報を管理するためのサーバである。また、冷蔵庫データベース４００のスーパー在庫管理テーブル４０２は、スーパー毎の在庫を記憶している。ここでは、食材管理販売サーバ３００にアクセスして、スーパーＡの商品を購入するまでの処理は、第１の実施形態と同様であるが、購入済み商品の引き取り予約の際に、ユーザが購入済み商品の引き取り先をスーパーＢに指定するものとする。即ち、図４のステップＳ１０４において、購入済み商品、引き取り量、引き取り日時のほかに、購入済み商品の引き取り先に関する情報がユーザ端末１００から食材管理販売サーバ３００に対して送信される。そして、食材管理販売サーバ３００は、図４のステップＳ２０９におけるユーザＩＤ及び引き取りＩＤの発行の際に、当該ユーザＩＤと引き取りＩＤとの組み合わせと、上記購入済み商品の引き取り先とを対応付けてユーザ端末１００に対して送信する。
【００６３】
次に、図１５を参照しながら、第３の実施形態に係る購入済み商品引き取りシステムにおける、購入済み商品の引き取り時の処理の流れについて説明する。
【００６４】
ステップＳ１０７において、ユーザ端末１００は、ユーザの操作に応じて、保管しているユーザＩＤ及び引き取りＩＤを画面上に表示する。なお、この処理は、スーパーＢにおいて購入済み商品を引き取る際に行われる処理である。ステップＳ３０１´において、スーパーＢ端末２０２は、スーパーＢの従業員の操作に応じて、ユーザ端末１００に表示されたユーザＩＤ及び引き取りＩＤを入力する。
【００６５】
ステップＳ３０２´において、スーパーＢ端末２０２は、入力したユーザＩＤ及び引き取りＩＤを食材管理販売サーバ３００に対して送信する。図１５のステップＳ２１０〜Ｓ２１２は、図５のステップＳ２１０〜Ｓ２１２と同様の処理であるため、説明を省略する。なお、第３の実施形態では、図５のステップＳ２１３に対応する処理は行われない。これは、購入済み商品が引き取られるのはスーパーＢであるため、スーパーＡの在庫量を更新する必要がないためである。
【００６６】
ステップＳ３０３´において、スーパーＢ端末２０２は、購入済み商品、引き取り量、及び、引き取り日時を食材管理販売サーバ３００から受信する。ステップＳ３０４´において、スーパーＢ端末２０２は、購入済み商品、引き取り量、及び、引き取り日時を画面上に表示する。スーパーＢの従業員は、画面上に表示された購入済み商品、引き取り量、及び、引き取り日時を参照し、その表示内容に沿って、購入済み商品をユーザに渡す。ステップＳ３０５において、スーパーＢ端末２０２は、スーパーＢデータベース２０２１にアクセスし、上記引き取り量に応じた値を、スーパーＢにおける上記購入済み商品の在庫量から減算する。以上により、本実施形態においては、所望の店舗で購入済み商品を引き取ることが可能となる。本実施形態では、本来スーパーＡで購入した商品をスーパーＢで引き取ることを例に挙げたが、これに限らない。例えば、商店街全体で食材管理販売サーバ３００を運営し、商店街の各店舗で通信端末を設置し、各店舗における商品の購入及び購入済み商品の引き取りに関する情報を同様に、通信端末から食材管理販売サーバ３００に送信することにより、商店街を仮想的な「冷蔵庫」として扱うことも可能である。
【００６７】
なお、本実施形態においては、スーパーＡ端末２０１とスーパーＢ端末２０２とは食材管理販売サーバ３００を介して情報のやりとりを行っているが、これに限らず、スーパーＡとスーパーＢそれぞれがサーバ３００及び冷蔵庫データベース４００を設置し、当該サーバが、各スーパーの情報管理を制御するようにしてもよい。
【００６８】
また、上述した第１〜第３の実施形態において、食材管理販売サーバ３００がユーザ毎に食材の購入履歴（品目、価格等）を管理し、食材の購入履歴に基づいて、各ユーザの家計簿を作成するようにしてもよい。作成された家計簿は、例えば一月に一回等、定期的に該当するユーザ端末１００に対して送信される。
【００６９】
更に、購入済み商品の購入日時から引き取り日時までの期間や、引き取り予約してから実際に店頭に引き取りにくるまでの期間に応じて制約を設けるようにしてもよい。例えば、商品が旬のものである場合、店舗で何日も保管しておくことは品質の低下や保存のための諸設備費増加を招いてしまうため、購入済み商品の購入日時から引き取り日時までの期間が、予め設定される期限を超過する場合、ユーザに超過料金を支払うか否かを確認して、超過料金を支払うことをユーザ端末１００から受信した場合だけ取引を継続してもよい。或いは購入済み商品の価格帯ランク以下の商品を代替品として渡すようにしてもよい。更に、引き取り日時を過ぎてから引き取りに来た場合に超過料金を加算したり、引き取り日時を一定時間過ぎた場合には商品を廃棄するようにしてもよい。
【符号の説明】
【００７０】
１００：ユーザ端末、２００：スーパー端末、２０１：スーパーＡ端末、２０２：スーパーＢ端末、２０２１：スーパーＢデータベース、３００：食材管理販売サーバ、３０１：ユーザ管理部、３０２：スーパー在庫管理部、３０３：商品管理部、４００：冷蔵庫データベース、４０１：ユーザ管理テーブル、４０２：スーパー在庫管理テーブル、４０３：商品管理テーブル
【図１】
2014182616.tif 000003
【図２】
2014182616.tif 000004
【図３】
2014182616.tif 000005
【図４】
2014182616.tif 000006
【図５】
2014182616.tif 000007
【図６】
2014182616.tif 000008
【図７】
2014182616.tif 000009
【図８】
2014182616.tif 000010
【図９】
2014182616.tif 000011
【図１０】
2014182616.tif 000012
【図１１】
2014182616.tif 000013
【図１２】
2014182616.tif 000014
【図１３】
2014182616.tif 000015
【図１４】
2014182616.tif 000016
【図１５】
2014182616.tif 000017