JP2012248125A - 情報処理装置及びその制御方法、プログラム - Google Patents

Abstract

【課題】 ユーザの災害後のライフスタイルを示すライフスタイル情報と、該ユーザとその同居人を示すユーザ情報とに従って、災害後の生活で必要な備品の名称と、その数をユーザに提示させること。
【解決手段】 災害後のライフスタイルを示すライフスタイル情報と、該ライフスタイル情報に示されるライフスタイルでの災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定するための備品情報とが関連付けられて記憶された必要備品決定情報と、クライアント端末から受信したライフスタイル情報とユーザ情報とに従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定し、当該決定された備品の名称と、該備品の数と、を前記クライアント端末の表示部に表示させるべく出力することを特徴とする。
【選択図】図１

Description

本発明は、情報処理装置及びその制御方法、プログラムに関し、特に、災害後の生活に必要な備品を決定ための技術に関するものである。

従来、例えば、家族は、地震や津波などの災害が発生した場合に必要となる災害用の備品（食糧、毛布など）を、予め購入しておき、災害が発生した場合に備えている。
また、各自治体や会社なども、災害用の備品を、予め購入しておき、災害が発生したときに備えている。

このように購入済みの備品を管理する技術として、例えば、特許文献１には、各自治体などの各備蓄者がそれぞれ備蓄している災害用物資の備蓄情報を一元管理することが開示されている。

特開２００６−９２０７１号公報

しかしながら、従来、例えば、自身（ユーザ）の家族には、どの災害用の備品が必要で、その備品が幾つ必要であるかを考えて、その結果、必要と考えられる備品、及びその備品を必要と考えられる数、購入している。

そのため、各自が、どの災害用の備品が、どのくらいの数、必要であるかを考え、適切に、必要な災害用の備品、及びその数を導き出すためには、よく考えなければならず、煩雑であった。

また、各自の考え方に誤りがあると、本来必要となる備品を購入しないケースや、必要としない備品を購入してしまうケース等がそれぞれ発生する可能性がある。そのような場合、いざ災害が発生した際に、必要な備品が無く、災害生活に対応することが難しくなってしまう。

また、例えば、災害を受けた後にどのような生活をおくるかを示す災害後のライフスタイル（自宅で暮らす場合、避難所で暮らす場合など）に応じて、必要な災害用の備品、及びその数が異なる場合がある。そのため、各自の考え方に誤りがあると、本来必要となる備品を購入しないケースや、必要としない備品を購入してしまうケース等がそれぞれ発生する可能性が増してしまう。

また、更に、例えば、家族の各自の年齢に応じて、必要となる備品や不要になる備品が発生する場合があるため、必要な災害用の備品、及びその数を導き出すことが煩雑となり、各自の考え方に誤りがあると、必要となる備品を購入しないケースや、必要としない備品を購入してしまうケース等がそれぞれ発生する可能性が発生する。

また、備品を購入してから時間が経過するのに伴い、家族の各自の年齢が変わり、必要となる備品や不要になる備品が発生する場合がある。そのため、ユーザは、その都度、どの災害用の備品が、どのくらいの数、必要であるかを考えなければならず、煩雑となる。

更に、購入済みの備品の消費期限（使用期限を含む）や賞味期限が切れた場合は、再度、該備品を購入しなければならないため、ユーザは、購入済みの備品が期限切れになっていないかを、定常的に確認しなければならず、その作業が煩雑であった。

そこで、本発明は、ユーザの災害後のライフスタイルを示すライフスタイル情報と、該ユーザとその同居人を示すユーザ情報とに従って、災害後の生活で必要な備品の名称と、その数をユーザに提示させることにより、ユーザによる煩雑な作業を低減させると共に、適切に、災害後の生活で必要な備品をユーザに把握させることを目的とする。

本発明は、クライアント端末と通信可能に接続され、災害後の生活に必要な備品の名称を前記クライアント端末に出力する情報処理装置であって、災害後のライフスタイルを示すライフスタイル情報と、該ライフスタイル情報に示されるライフスタイルでの災害後の生活に必要となる備品の名称と、前記クライアント端末から受信される、ユーザと該ユーザの同居人とを示すユーザ情報から、災害後の生活で必要となる該備品の数を決定するための備品情報とが関連付けられた必要備品決定情報を記憶する記憶手段と、ユーザと該ユーザの同居人とを示すユーザ情報と、該ユーザ情報に示されるユーザと該ユーザの同居人の災害後のライフスタイルを示すライフスタイル情報と、を前記クライアント端末から受信する受信手段と、前記記憶手段に記憶された必要備品決定情報と、前記受信手段で受信したライフスタイル情報と前記ユーザ情報とに従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定する決定手段と、前記決定手段で決定された備品の名称と、該備品の数とを前記クライアント端末の表示部に表示させるべく出力する出力手段と、を備えることを特徴とする。

また、本発明は、クライアント端末と通信可能に接続され、災害後のライフスタイルを示すライフスタイル情報と、該ライフスタイル情報に示されるライフスタイルでの災害後の生活に必要となる備品の名称と、前記クライアント端末から受信される、ユーザと該ユーザの同居人とを示すユーザ情報から、災害後の生活で必要となる該備品の数を決定するための備品情報とが関連付けられた必要備品決定情報を記憶する記憶手段を備えており、災害後の生活に必要な備品の名称を前記クライアント端末に出力する情報処理装置の制御方法であって、前記情報処理装置の受信手段が、ユーザと該ユーザの同居人とを示すユーザ情報と、該ユーザ情報に示されるユーザと該ユーザの同居人の災害後のライフスタイルを示すライフスタイル情報と、を前記クライアント端末から受信する受信工程と、前記情報処理装置の決定手段が、前記記憶手段に記憶された必要備品決定情報と、前記受信工程で受信したライフスタイル情報と前記ユーザ情報とに従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定する決定工程と、前記情報処理装置の出力手段が、前記決定工程で決定された備品の名称と、該備品の数とを前記クライアント端末の表示部に表示させるべく出力する出力工程と、を備えることを特徴とする。

また、本発明は、クライアント端末と通信可能に接続され、災害後のライフスタイルを示すライフスタイル情報と、該ライフスタイル情報に示されるライフスタイルでの災害後の生活に必要となる備品の名称と、前記クライアント端末から受信される、ユーザと該ユーザの同居人とを示すユーザ情報から、災害後の生活で必要となる該備品の数を決定するための備品情報とが関連付けられた必要備品決定情報を記憶する記憶手段を備えており、災害後の生活に必要な備品の名称を前記クライアント端末に出力する情報処理装置で読み取り実行可能なプログラムであって、前記情報処理装置を、ユーザと該ユーザの同居人とを示すユーザ情報と、該ユーザ情報に示されるユーザと該ユーザの同居人の災害後のライフスタイルを示すライフスタイル情報と、を前記クライアント端末から受信する受信手段と、前記記憶手段に記憶された必要備品決定情報と、前記受信手段で受信したライフスタイル情報と前記ユーザ情報とに従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定する決定手段と、前記決定手段で決定された備品の名称と、該備品の数とを前記クライアント端末の表示部に表示させるべく出力する出力手段として機能させることを特徴とする。

本発明によれば、ユーザの災害後のライフスタイルを示すライフスタイル情報と、該ユーザとその同居人を示すユーザ情報とに従って、災害後の生活で必要な備品の名称と、その数をユーザに提示させることにより、ユーザによる煩雑な作業を低減させると共に、適切に、災害後の生活で必要な備品をユーザに把握させることができる。

本発明の実施の形態に係るシステム構成を概略的に示すブロック図である。 図１に示したサーバ１０１、クライアント端末１０２、１０３災害備品ベンダーサーバ１０４、１０５のハードウェア構成を概略的に示すブロック図である。 会員情報登録画面の一例を示す図である。 同居人情報登録画面の一例を示す図である。 コース情報登録画面の一例を示す図である。 必要備品リスト表示画面の一例を示す図である。 ステップＳ１７０５で備品の購入内容が入力された必要備品リスト表示画面の一例を示す図である。 会員情報テーブルの一例を示す図である。 同居人情報テーブルの一例を示す図である。 災害備品リストテーブルの一例を示す図である。 ステップＳ１７１１で更新された災害備品リストテーブルの一例を示す図である。 災害備品販売サイトのＵＲＬテーブルの一例を示す図である。 必要備品決定テーブルの一例を示す図である。 図１におけるサーバ１０１、クライアント端末１０２、災害備品ベンダーサーバ１０４のＣＰＵ２０１が実行する第１の制御処理手順を示すフローチャートである。 ステップＳ１４０１の会員情報登録処理の詳細処理を示すフローチャートである。 ステップＳ１４０２の備品リスト決定処理の詳細処理を示すフローチャートである。 ステップＳ１４０３の備品リスト表示・更新処理の詳細処理を示すフローチャートである。 ステップＳ１７０７の詳細処理を示すフローチャートである。 購入時期通知処理の一例を示すフローチャートである。

以下、添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。

図１は、本発明の実施の形態に係るシステム構成を概略的に示すブロック図である。

図１に示すように、サーバ１０１と、クライアント端末１０２と、クライアント端末１０３と、災害備品ベンダーサーバ１０４と、災害備品ベンダーサーバ１０５とは、インターネット回線などのネットワーク１０６を介して相互に通信可能に接続されている。

クライアント端末１０２、１０３は、パソコンやスマートフォンなどの情報処理装置である。

サーバ１０１は、ＷＥＢサーバとしての機能を備えており、クライアント端末１０２、１０３に、ＨＴＭＬ等のマークアップ言語で記述された表示情報を送信する機能を備えた情報処理装置である。サーバ１０１は、本発明の情報処理装置の適用例である。また、サーバ１０１は、クライアント端末１０２、１０３のユーザの認証処理を行うための認証機能も備えている。

災害備品ベンダーサーバ１０４、１０５は、ＷＥＢサーバとしての機能を備え、災害時等に用いられる備品を、インターネット上で販売するオンラインショップ（ネットショップとも言う）のサービスを提供している情報処理装置である。

災害備品ベンダーサーバ１０８は、複数のオンラインショップのサービスを提供しており、複数台の災害備品ベンダーサーバがネットワーク１０６に接続されている。

クライアント端末１０２、クライアント端末１０３等のクライアント端末１０７は、ユーザが所持している情報処理装置である。

クライアント端末１０２、１０３には、ＷＥＢブラウザソフトウエア（以下、単にブラウザとも言う）がインストールされている。

クライアント端末１０２、１０３は、サーバ１０１、又は災害備品ベンダーサーバ１０４等から取得した、ＷＥＢページを表示するための表示情報をブラウザが解釈して表示部に表示する機能を備えている。ここで、表示情報とは、ＷＥＢページを表示するための、マークアップ言語で記述されたデータファイルであり、ＨＴＭＬファイル、ＸＭＬファイルなどのＷＥＢブラウザが解釈可能なファイルである。

上述したように、本システム構成は、サーバ１０１上で実行している各種サービス、及び災害備品ベンダーサーバ上で実行している各種サービスを、クライアント端末にインストールされたブラウザを利用して、ユーザが利用する仕組みである。

以下、図２を用いて、図１に示したサーバ１０１、クライアント端末１０２、１０３災害備品ベンダーサーバ１０４、１０５のハードウェア構成について説明する。

図２は、図１に示したサーバ１０１、クライアント端末１０２、１０３災害備品ベンダーサーバ１０４、１０５のハードウェア構成を概略的に示すブロック図である。

図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣ（情報処理装置）の実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

また、２０５は入力コントローラで、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。２０６はビデオコントローラで、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器（表示部）への表示を制御する。なお、図２では、ＣＲＴ２１０と記載しているが、表示器はＣＲＴだけでなく、液晶ディスプレイ等の他の表示器であってもよい。これらは必要に応じて管理者が使用するものである。

２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

２０８は通信Ｉ／Ｆコントローラで、ネットワーク１０６を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられるファイル及び各種テーブル等も、外部メモリ２１１に格納されている。

次に、図１４に示すフローチャートに従って本実施の形態を説明する。

図１４は、図１におけるサーバ１０１、クライアント端末１０２、災害備品ベンダーサーバ１０４のＣＰＵ２０１が実行する第１の制御処理手順を示すフローチャートである。

ステップＳ１４０１において、クライアント端末１０２に入力された会員情報と、同居人情報と、コース情報（ここで、コース情報とは、災害後のライフスタイルを示すライフスタイル情報のことである）とをクライアント端末１０２がサーバ１０１に送信すると、サーバ１０１は、クライアント端末１０２から受信した会員情報と、同居人情報と、コース情報とを、サーバ１０１の外部メモリ２１１に記憶されている会員情報テーブル（図８）、同居人情報テーブル（図９）に登録して記憶する。ステップＳ１４０１の詳細処理は、図１５に示す。

次に、ステップＳ１４０２において、サーバ１０１は、ステップＳ１４０１で、会員情報テーブル（図８）、同居人情報テーブル（図９）に登録された会員情報と同居人情報とコース情報と、サーバ１０１の外部メモリ２１１に記憶されている必要備品決定テーブル（図１３）とを用いて、ステップＳ１４０１で登録された会員（ユーザ）、及びその同居人が災害時等に必要とする備品などを決定する処理を行う。なお、決定された備品などの情報は、サーバ１０１の外部メモリ２１１に記憶される災害備品リストテーブル（図１０）に登録される。ステップＳ１４０２の詳細処理は、図１６に示す。

次に、ステップＳ１４０３において、サーバ１０１は、ステップＳ１４０２で決定された備品のリストをクライアント端末１０２に送信すると、クライアント端末１０２は、該リストをクライアント端末１０２のＣＲＴ２１０等の表示部に表示する。そして、ユーザが必要な備品を確認して、クライアント端末１０２が、オンラインショップなどで購入した備品の数やその期限（消費期限、使用期限、賞味期限など）などの入力を行うと、入力された内容をサーバ１０１に送信し、サーバ１０１は、サーバ１０１の外部メモリ２１１に記憶される災害備品リストテーブル（図１０）に登録して更新する。更新された災害備品リストテーブルは図１１に示す。ステップＳ１４０３の詳細処理は、図１７に示す。

次に、図１５に示すフローチャートを用いてステップＳ１４０１の詳細処理について説明する。

図１５は、ステップＳ１４０１の会員情報登録処理の詳細処理を示すフローチャートである。

ステップＳ１５０１、ステップＳ１５０４からステップＳ１５０７、ステップＳ１５１１からステップＳ１５１４、ステップＳ１５１８からステップＳ１５２１に示す処理は、クライアント端末１０２のＣＰＵ２０１によって実行され実現される。

また、ステップＳ１５０２、ステップＳ１５０３、ステップＳ１５０８からステップＳ１５１０、ステップＳ１５１５からステップＳ１５１７、ステップＳ１５２２からステップＳ１５２４に示す処理は、サーバ１０１のＣＰＵ２０１によって実行され実現される。

まず、クライアント端末１０２は、ＷＥＢブラウザ（単にブラウザとも言う）を起動して、会員情報登録画面（図３）を表示するためのＵＲＬの入力をユーザから受け付けると、該ＵＲＬのＷＥＢページ（該会員情報登録画面（図３））を表示するための表示情報（ＨＴＭＬなど）の取得要求をサーバ１０１に送信する（ステップＳ１５０１）。クライアント端末１０２は、ここで起動されたブラウザに、後述する図３、図４、図５、図６、図７に示す画面を表示する。

そして、サーバ１０１は、クライアント端末１０２から、該会員情報登録画面（図３）を表示するための表示情報（ＨＴＭＬなど）の取得要求を受信すると（ステップＳ１５０２）、該表示情報をクライアント端末１０２に送信する（ステップＳ１５０３）。

次に、クライアント端末１０２は、サーバ１０１から、該表示情報を受信すると（ステップＳ１５０４）、該表示情報に従って、クライアント端末１０２のＣＲＴ２１０等の表示部に会員情報登録画面（図３）を表示する（ステップＳ１５０５）

図３は、会員情報登録画面の一例を示す図である。

会員情報登録画面（図３）には、図３に示すように、ユーザ（顧客）のユーザＩＤを入力する入力欄３０１、パスワードを入力する入力欄３０２、ユーザの性別を選択するラジオボタン３０３、ユーザの生年月日を選択するプルダウン３０４、ユーザの第１の通知先としての電子メールアドレスを入力する入力欄３０５、ユーザの第２の通知先（たとえば、同居人の通知先なども含む）としての電子メールアドレスを入力する入力欄３０６、キャンセルボタン３０７、登録（次へ）ボタン３０８が表示される。

クライアント端末１０２は、ユーザの操作による、入力欄３０１へのユーザＩＤの入力、入力欄３０２へのパスワードの入力、ラジオボタン３０３からの性別の入力、プルダウン３０４からの生年月日の入力、入力欄３０５、３０６への通知先の入力を受け付ける（ステップＳ１５０６）。このように、クライアント端末１０２は、会員情報登録画面（図３）でユーザの操作により入力される情報を会員情報として受け付ける。

そして、クライアント端末１０２は、ユーザの操作により、キャンセルボタン３０７、又は登録（次へ）ボタン３０８が押下されると、会員情報登録画面（図３）を介して入力された内容の情報（ユーザにより入力された情報と共に、ユーザにより押下されたボタンの種類（キャンセルボタン３０７、又は登録（次へ）ボタン３０８））をサーバ１０１に送信する（ステップＳ１５０７）。

サーバ１０１は、クライアント端末１０２から、会員情報登録画面（図３）を介して入力された内容の情報を受信すると（ステップＳ１５０８）、受信した情報に、登録（次へ）ボタン３０８が押下された旨の情報が含まれているか、キャンセルボタン３０７が押下された旨の情報が含まれているかを判定し（ステップＳ１５０９）、登録（次へ）ボタン３０８が押下された旨の情報が含まれていると判定された場合は（ステップＳ１５０９：ＹＥＳ）、同居人情報登録画面（図４）を表示するための表示情報をクライアント端末１０２に送信する（ステップＳ１５１０）。一方、キャンセルボタン３０７が押下された旨の情報が含まれていると判定された場合は（ステップＳ１５０９：ＮＯ）、処理をステップＳ１５０２に戻し、クライアント端末１０２から送信される会員情報登録画面（図３）の表示情報の取得要求の受信を待つ。ステップＳ１５０８は、本発明の受信手段の適用例である。

クライアント端末１０２は、サーバ１０１から、同居人情報登録画面（図４）を表示するための表示情報を受信すると（ステップＳ１５１１）、該表示情報に従って同居人情報登録画面（図４）を表示部に表示する（ステップＳ１５１２）。

図４は、同居人情報登録画面の一例を示す図である。

同居人情報登録画面（図４）には、図４に示すように、ユーザ（顧客）以外の同居人の人数（同居人数）を入力するためのプルダウン４０１と、同居人の性別を入力するプルダウン４０２と、同居人の生年月日を入力するためのプルダウン４０３と、登録（次へ）ボタン４０４、キャンセルボタン４０５が表示される。

プルダウン４０１で入力された同居人数の分、プルダウン４０２．プルダウン４０３が表示される。図４の例では、同居人数が「３」人と入力されているため、プルダウン４０２．プルダウン４０３が、それぞれ３人分の入力できるように表示されている。

クライアント端末１０２は、ユーザの操作による、プルダウン４０１からの同居人数の入力、プルダウン４０２からの同居人の性別の入力、プルダウン４０３からの生年月日の入力を受け付ける（ステップＳ１５１３）。

このように、クライアント端末１０２は、同居人情報登録画面（図４）を介してユーザの操作により入力される情報を同居人情報として受け付ける。

そして、クライアント端末１０２は、ユーザの操作により、キャンセルボタン４０５、又は登録（次へ）ボタン４０４が押下されると、同居人情報登録画面（図４）を介して入力された内容の情報（ユーザにより入力された情報と共に、ユーザにより押下されたボタンの種類（キャンセルボタン４０５、又は登録（次へ）ボタン４０４））をサーバ１０１に送信する（ステップＳ１５１４）。

サーバ１０１は、クライアント端末１０２から、同居人情報登録画面（図４）を介して入力された内容の情報を受信すると（ステップＳ１５１５）、受信した情報に、登録（次へ）ボタン４０４が押下された旨の情報が含まれているか、キャンセルボタン４０５が押下された旨の情報が含まれているかを判定し（ステップＳ１５１６）、登録（次へ）ボタン４０４が押下された旨の情報が含まれていると判定された場合は（ステップＳ１５１６：ＹＥＳ）、コース情報登録画面（図５）を表示するための表示情報をクライアント端末１０２に送信する（ステップＳ１５１７）。一方、キャンセルボタン４０５が押下された旨の情報が含まれていると判定された場合は（ステップＳ１５１６：ＮＯ）、処理をステップＳ１５０２に戻し、クライアント端末１０２から送信される会員情報登録画面（図３）の表示情報の取得要求の受信を待つ。ステップＳ１５１５は、本発明の受信手段の適用例である。

クライアント端末１０２は、サーバ１０１から、コース情報登録画面（図５）を表示するための表示情報を受信すると（ステップＳ１５１８）、該表示情報に従ってコース情報登録画面（図５）を表示部に表示する（ステップＳ１５１９）。

図５は、コース情報登録画面の一例を示す図である。

コース情報登録画面（図５）には、図５に示すように、コースを選択するプルダウン５０１と、想定日数を選択するためのプルダウン５０２と、制限金額を入力するための入力欄５０３と、登録ボタン５０４と、キャンセルボタン５０５とが表示される。想定日数は、本発明の生活日数の適用例である。

ここで、コース情報には、例えば、災害を受けた直後にどのような生活をおくるかが示されており、図５の例では、災害直後から自宅で暮らすことを想定したコースである「自宅暮らし想定コース」、災害直後に避難所で暮らすことを想定したコースである「避難所暮らし想定コース」、災害直後にペットと共に暮らすことを想定したコースである「ペットがいるコース」、災害直後に自宅でも避難所でもない場所で暮らすことを想定したコースである「サバイバル生活想定コース」の４つのコースが選択可能に表示されている。

すなわち、コース情報は、本発明のライフスタイル情報の適用例であり、災害後のライフスタイルを示している。

また、想定日数とは、災害後、プルダウン５０１で選択したコースで暮らす日数のことを示している。すなわち、想定日数は、災害後、プルダウン５０１で選択したコースで暮らすために必要となる備品を使用する期間を示している。

また、制限金額とは、災害後、プルダウン５０１で選択したコースで、プルダウン５０２で選択した想定日数、暮らすために必要となる備品の購入費用の上限金額である。

クライアント端末１０２は、ユーザの操作による、プルダウン５０１からのコースの入力、プルダウン５０２からの想定日数の入力、入力欄５０３への制限金額の入力を受け付ける（ステップＳ１５２０）。

このように、クライアント端末１０２は、コース情報登録画面（図５）を介してユーザの操作により入力される情報をコース情報として受け付ける。

そして、クライアント端末１０２は、ユーザの操作により、キャンセルボタン５０５、又は登録ボタン５０４が押下されると、コース情報登録画面（図５）を介して入力された内容の情報（ユーザにより入力された情報と共に、ユーザにより押下されたボタンの種類（キャンセルボタン５０５、又は登録ボタン５０４））をサーバ１０１に送信する（ステップＳ１５２１）。

サーバ１０１は、クライアント端末１０２から、コース情報登録画面（図５）を介して入力された内容の情報を受信すると（ステップＳ１５２２）、受信した情報に、登録ボタン５０４が押下された旨の情報が含まれているか、キャンセルボタン５０５が押下された旨の情報が含まれているかを判定し（ステップＳ１５２３）、登録ボタン５０４が押下された旨の情報が含まれていると判定された場合は（ステップＳ１５２３：ＹＥＳ）、ステップＳ１５０８で受信した情報（会員情報登録画面（図３）を介して入力された内容の情報）、及びステップＳ１５１５で受信した情報（同居人情報登録画面（図４）を介して入力された内容の情報）、及びステップＳ１５２２で受信した情報（コース情報登録画面（図５）を介して入力された内容の情報）を、会員情報テーブル（図８）、及び同居人情報テーブル（図９）に登録し記憶する（ステップＳ１５２４）。ステップＳ１５２２は、本発明の受信手段の適用例である。

ステップＳ１５０８で受信した情報（会員情報登録画面（図３）を介して入力された内容の情報）、及びステップＳ１５１５で受信した情報（同居人情報登録画面（図４）を介して入力された内容の情報）は、本発明のユーザ情報の適用例であり、ユーザと該ユーザの同居人を示している。

一方、キャンセルボタン５０５が押下された旨の情報が含まれていると判定された場合は（ステップＳ１５２３：ＮＯ）、処理をステップＳ１５０２に戻し、クライアント端末１０２から送信される会員情報登録画面（図３）の表示情報の取得要求の受信を待つ。

クライアント端末１０２は、ステップＳ１５２１で、コース情報登録画面（図５）を介して入力された内容の情報（ユーザにより入力された情報と共に、ユーザにより押下されたボタンの種類（キャンセルボタン５０５、又は登録ボタン５０４））をサーバ１０１に送信すると、処理を図１７に示すステップＳ１７０３に移行する。

また、サーバ１０１は、ステップＳ１５２４の記憶処理を実行すると、処理を、図１６に示すステップＳ１６０１に移行する。

図８は、会員情報テーブルの一例を示す図である。

会員情報テーブル（図８）は、「ユーザＩＤ」、「パスワード」、「性別」、「生年月日」、「メールアドレス１（通知先）」、「メールアドレス２（通知先）」、「人数」、「コース」、「想定日数」、「同居人情報ＩＤ」、「制限金額」の項目から構成される。 次に、会員情報テーブル（図８）の各項目に記憶される情報について説明する。

「ユーザＩＤ」には、３０１に入力されたユーザＩＤが記憶される。また、「パスワード」には、３０２に入力されたパスワードが記憶される。また、「性別」には、３０３に入力された性別が記憶される。また、「生年月日」には、３０４に入力されたユーザの生年月日が記憶される。また、「メールアドレス１（通知先）」には、３０５に入力された通知先となる電子メールアドレスが記憶される。また、「メールアドレス２（通知先）」には、３０６に入力された通知先となる電子メールアドレスが記憶される。また、「人数」には、４０１に入力された同居人数に「１」を加算した値が記憶される。これは、４０１には、図３、図４、図５の各画面を介して各情報の登録を行っているユーザ（顧客）以外の、該ユーザの同居人の人数（同居人数）が入力されるため、「人数」には、該ユーザが共に生活をしている、該ユーザを含む人数（例えば、家族の人数）を示す値として、同居人数に「１」を加算した値が記憶される。また、「コース」には、５０１で選択され入力されたコースが記憶される。また、「想定日数」には、５０２に入力された想定日数が記憶される。また、「同居人情報ＩＤ」には、４０２、及び４０３に入力され、後述する同居人情報テーブルに記憶される同居人の性別と生年月日を関連付けるための識別情報として採番されたＩＤ（同居人情報ＩＤ）が記憶される。この同居人情報ＩＤは、ステップＳ１５２４で、会員情報テーブル（図８）、及び同居人情報テーブル（図９）に登録される際に、採番され、会員情報テーブル（図８）、及び同居人情報テーブル（図９）の「同居人情報ＩＤ」の項目に登録され記憶される。「制限金額」には、５０３に入力された制限金額が記憶される。

図９は、同居人情報テーブルの一例を示す図である。

同居人情報テーブル（図９）は、「同居人情報ＩＤ」、「性別」、「生年月日」の項目から構成される。

次に、同居人情報テーブル（図９）の各項目に記憶される情報について説明する。

「同居人情報ＩＤ」には、会員情報テーブル（図８）のレコードと関連付けるために、該レコードの「同居人情報ＩＤ」と同一の値が記憶される。また、「性別」には、４０２に入力された同居人の性別が記憶される。また、「生年月日」には、４０３に入力された生年月日が記憶される。

以上のように、ステップＳ１５２４では、会員情報テーブル（図８）、同居人情報テーブル（図９）に示すように、会員情報登録画面（図３）、及び同居人情報登録画面（図４）、及びコース情報登録画面（図５）に入力された各情報が記憶される。

例えば、会員情報テーブル（図８）の「ユーザＩＤ」が「ｏｇａｔａ」のレコードには、「同居人ＩＤ」が「１」が記憶され、この「同居人ＩＤ」と関連付けられて同居人情報テーブル（図９）に記憶されている「同居人情報ＩＤ」が「１」の各レコードには、図４の同居人情報登録画面の４０２に示す全ての同居人の性別、及び４０３に示す全ての同居人の生年月日が記憶される。

次に、図１６に示すフローチャートを用いてステップＳ１４０２の詳細処理について説明する。

図１６は、ステップＳ１４０２の備品リスト決定処理の詳細処理を示すフローチャートである。

ステップＳ１６０１からステップＳ１１６１５に示す処理は、サーバ１０１のＣＰＵ２０１によって実行され実現される。

サーバ１０１は、サーバ１０１の外部メモリ２１１に記憶されている必要備品決定テーブル（図１３）を読み出して取得する（ステップＳ１６０１）。

そして、サーバ１０１は、ステップＳ１６０１で取得した必要備品決定テーブル（図１３）のレコード毎に、優先順位の順番に、ステップＳ１６０２からステップＳ１６１５までの処理を繰り返し実行する。

図１３は、必要備品決定テーブルの一例を示す図である。

必要備品決定テーブルは、「備品名称」、「対応人数」、「必要数／日」、「必要条件」、「ネット購入」、「自宅」、「避難所」、「サバイバル」、「金額」、「優先順位」の項目から構成されている。

必要備品決定テーブルは、本発明の必要備品決定情報の適用例である。
「備品名称」には、備品の名称が記憶される。すなわち、災害後の生活に必要となる備品の名称が記憶されている。

また、「対応人数」には、備品名称に示される備品１つで使用可能な（対応可能な）人数が記憶される。図１３の例では、「∞」は、備品１つで使用可能な（対応可能な）人数は何人でもよいことを示している。

また、「必要数／日」には、災害後の生活の１日及び１人当たりに必要とされる備品の数が記憶される。

図１３の例では、「非常用ラジオ」、「食器セット」、「組み立て式テント」、「パック毛布」、「寝袋」は消耗品ではなく、「水（ペットボトル１．５Ｌ）」、「サバイバル米（１００ｇ）」、「オムツ（大人用：２４枚入り）」、「オムツ（幼児用：３２枚入り）」、「ペットフード（犬用：３Ｋｇ（キログラム））」、「ナプキン（１０枚入り）」は、消耗品である。

そのため、消耗品ではない「非常用ラジオ」、「食器セット」、「組み立て式テント」、「パック毛布」、「寝袋」の「必要数／日」には、その旨を示す「―」が記憶されている。

「対応人数」、及び「必要数／日」は、本願発明の備品情報の適用例であり、災害後の生活で必要となる該備品の数を決定するための情報である。

また、「必要条件」には、備品名称に示される備品を使用（必要）する条件が記憶される。図１３の例では、「オムツ（大人用：２４枚入り）」は、６５歳以上の人が使用する（必要とする）ことを示している。また、「オムツ（幼児用：３２枚入り）」は、３歳未満の人が使用する（必要とする）ことを示している。また、「ペットフード（犬用：３Ｋｇ（キログラム））」は、ペット（犬）が使用する（必要とする）ことを示している。また、「ナプキン（１０枚入り）」は、１３歳以上の女性が使用する（必要とする）ことを示している。

「必要条件」は、本発明の年齢条件の適用例である。

また、「ネット購入」には、ネットによる購入（オンラインショップからの購入）が可能か否かを示す情報が記憶される。図１３の例では、ネットによる購入が可能なことを示す情報として「可能」が、また、ネットによる購入が不可能なことを示す情報として「なし」が記憶されている。

また、「自宅」は「自宅暮らし想定コース」を示しており、「自宅」には、備品名称に示される備品について、「自宅暮らし想定コース」で必要とされるか否かを示す情報が記憶される。図１３の例では、備品名称に示される備品が「自宅暮らし想定コース」で必要とされることを示す情報として「Ｔ」（Ｔｒｕｅ）が、また、備品名称に示される備品が「自宅暮らし想定コース」で不必要とされることを示す情報として「Ｆ」（Ｆａｌｓｅ）が記憶される。

また、「避難所」は「避難所暮らし想定コース」を示しており、「避難所」には、備品名称に示される備品について、「避難所暮らし想定コース」で必要とされるか否かを示す情報が記憶される。図１３の例では、備品名称に示される備品が「避難所暮らし想定コース」で必要とされることを示す情報として「Ｔ」（Ｔｒｕｅ）が、また、備品名称に示される備品が「避難所暮らし想定コース」で不必要とされることを示す情報として「Ｆ」（Ｆａｌｓｅ）が記憶される。

また、「サバイバル」は「サバイバル生活想定コース」を示しており、「サバイバル」には、備品名称に示される備品について、「サバイバル生活想定コース」で必要とされるか否かを示す情報が記憶される。図１３の例では、備品名称に示される備品が「サバイバル生活想定コース」で必要とされることを示す情報として「Ｔ」（Ｔｒｕｅ）が、また、備品名称に示される備品が「サバイバル生活想定コース」で不必要とされることを示す情報として「Ｆ」（Ｆａｌｓｅ）が記憶される。

上述の通り、「自宅」、「避難所」、「サバイバル」は、それぞれ、「自宅暮らし想定コース」、「避難所暮らし想定コース」、「サバイバル生活想定コース」を示しており、これらは、本発明のライフスタイル情報の適用例であり、災害後のライフスタイルを示している。 また、「金額」には、備品の１個当たりの価格が記憶される。

また、「優先順位」には、備品の必要性を示す順位が記憶されている。図１３の例では、「優先順位」に記憶されている値は、小さい値の方が、優先順位が高いことを示している。

図１６の説明に戻る。

サーバ１０１は、ステップＳ１６０１で、サーバ１０１の外部メモリ２１１から取得した必要備品決定テーブル（図１３）の各レコードのうち、まだステップＳ１６０３からステップＳ１６１４までの処理を行っていない、「優先順位」が最も高いレコードを処理対象とする（ステップＳ１６０２）。

次に、サーバ１０１は、ステップＳ１５２４で会員情報テーブル（図８）、及び同居人情報テーブル（図９）に登録されたレコードに示される「コース」に一致する、現在処理対象の必要備品決定テーブル（図１３）のレコードのコース（「自宅」（「自宅暮らし想定コース」）、「避難所」（「避難所暮らし想定コース」）、「サバイバル」（「サバイバル生活想定コース」）の何れか）の値が「Ｔ」（Ｔｒｕｅ）であるか「Ｆ」（Ｆａｌｓｅ）であるかを判定する（ステップＳ１６０３）。

そして、ステップＳ１６０３で「Ｔ」（Ｔｒｕｅ）であると判定された場合は（ＹＥＳ）、ステップＳ１６０４に移行し、「Ｆ」（Ｆａｌｓｅ）であると判定された場合は（ＮＯ）、ステップＳ１６１４に移行する。

ステップＳ１６０４では、ステップＳ１５２４で会員情報テーブル（図８）、及び同居人情報テーブル（図９）に登録されたレコードの各項目の情報から、現在処理対象の必要備品決定テーブル（図１３）のレコードの「必要条件」に合致する人がいるか否かを判定する。

ステップＳ１６０４で、ステップＳ１５２４で会員情報テーブル（図８）、及び同居人情報テーブル（図９）に登録されたレコードの各項目の情報から、現在処理対象の必要備品決定テーブル（図１３）のレコードの「必要条件」に合致する人がいると判定された場合は（ＹＥＳ）、処理をステップＳ１６０５に移行し、一方、合致する人がいないと判定された場合は（ＮＯ）、処理をステップＳ１６１４に移行する。

例えば、現在処理対象のレコードの「必要条件」が「６５歳以上」である場合、ステップＳ１５２４で会員情報テーブル（図８）、及び同居人情報テーブル（図９）に登録されたレコードの「生年月日」と現在の日時から計算して得られる年齢が、６５歳以上であるか否かを判定することで、「必要条件」に合致する人がいるか否かを判定することができる。ユーザＩＤが「ｏｇａｔａ」のレコードを例に説明すると、現在日時が２０１１年５月１０日の場合、ユーザＩＤが「ｏｇａｔａ」のレコードに関連付いて同居人情報テーブル（図９）に登録されている生年月日が１９４０／１／２５の女性の人が７１歳であるため、６５歳以上であると判定され、「必要条件」に合致する人がいると判定される。

そして、サーバ１０１は、ステップＳ１６０４で「必要条件」に合致する人がいると判定された場合（ＹＥＳ）、ステップＳ１６０４で「必要条件」に合致すると判定された人数を特定して（ステップＳ１６０５）、現在処理対象のレコードの「必要数／日」に「―」が記憶されているか否かを判定することにより、現在処理対象のレコードが消耗品であるか否かを判定する（ステップＳ１６０６）。

そして、サーバ１０１は、ステップＳ１６０６で現在処理対象のレコードが消耗品であると判定された場合は（ＹＥＳ）、ステップＳ１６０５で特定された人数と、ステップＳ１５２４で会員情報テーブル（図８）に登録されたレコードの「想定日数」に示される値と、必要備品決定テーブル（図１３）の現在処理対象のレコードの「必要数／日」に示される値とをかける（乗算する）ことにより、必要備品決定テーブル（図１３）の現在処理対象のレコードの備品を必要とする数（必要備品数）を算出する（ステップＳ１６０７）。

ここで、「必要数／日」に示される値は、本発明の備品数決定情報の適用例である。

一方、サーバ１０１は、ステップＳ１６０６で現在処理対象のレコードが消耗品ではないと判定された場合は（ＮＯ）、ステップＳ１６０５で特定された人数と、必要備品決定テーブル（図１３）の現在処理対象のレコードの「対応人数」に示される値とをかける（乗算する）ことにより、必要備品決定テーブル（図１３）の現在処理対象のレコードの備品を必要とする数（必要備品数）を算出する（ステップＳ１６０８）。

次に、サーバ１０１は、ステップＳ１６０８、又はステップＳ１６０７の処理を実行すると、処理をステップＳ１６０９に移行する。

ステップＳ１６０９では、サーバ１０１は、ステップＳ１６０８、又はステップＳ１６０７で算出された必要備品数と、必要備品決定テーブル（図１３）の現在処理対象のレコードの備品の金額とをかける（乗算する）ことにより、該備品の金額（該備品を必要備品数分、購入した場合の金額）を算出する。そして、サーバ１０１は、ここで算出された金額に、これまでにステップＳ１６０９で算出された金額を加算することにより、ステップＳ１５２４で会員情報テーブル（図８）、及び同居人情報テーブル（図９）に登録されたレコードのユーザ、同居人が必要とする備品を購入するために必要とする金額の合計（累積金額）を算出する（ステップＳ１６０９）。

ここで、ステップＳ１６０９では、後述するステップＳ１６１０で累積金額が制限金額を超えると判定され（ＹＥＳ）、ステップＳ１６１４で、災害備品リストテーブル（図１０）の「必要性の有無」に「不要」と登録された備品を、必要備品数分、購入した場合の金額は、累積金額の算出の際に加算しない。これは、必要と判定された各備品（「必要性の有無」に「必要」と登録された各備品）を、それぞれ必要備品数分、購入した場合の金額（累計金額）を算出するためである。

次に、サーバ１０１は、ステップＳ１６０９で算出された累積金額が、ステップＳ１５２４で会員情報テーブル（図８）に登録されたレコードの制限金額を超えるか否かを判定する（ステップＳ１６１０）。これにより、ユーザにより入力された制限金額以内で購入可能で、かつ災害後の生活で必要となる備品を決定することが可能となる。

サーバ１０１は、ステップＳ１６０９で算出された累積金額が、ステップＳ１５２４で会員情報テーブル（図８）に登録されたレコードの制限金額を超えると判定された場合は（ＹＥＳ）、処理をステップＳ１６１４に移行する。

ステップＳ１６１４では、サーバ１０１は、サーバ１０１の外部メモリ２１１に記憶される、ステップＳ１５２４で会員情報テーブル（図８）に登録されたユーザＩＤの災害備品リストテーブル（図１０）に、必要備品決定テーブル（図１３）の現在処理対象のレコードの備品の備品名称を記憶する。

また、ステップＳ１６１４では、該レコードの「ネット購入」に「可能」が記憶されている場合は、該災害備品リストテーブル（図１０）の「ネット購入の可否」に「可能」が記憶され、該レコードの「ネット購入」に「なし」が記憶されている場合は、該災害備品リストテーブル（図１０）の「ネット購入の可否」に「不可」が記憶される。

また、ステップＳ１６１４では、該備品が必要ではないことを示す情報（「不要」）を「必要性の有無」に登録する。

また、ステップＳ１６１４では、「個数」には「―」を登録し、「消費期限」には「―」を登録し、「未購入／購入済」には「未購入」を登録する。

次に、災害備品リストテーブル（図１０）について説明する。

図１０は、災害備品リストテーブルの一例を示す図である。

災害備品リストテーブルは、「備品名称」、「必要性の有無」、「個数」、「消費期限」、「未購入／購入済」、「ネット購入の可否」の項目から構成される。

「備品名称」には、備品の名称が記憶される。

「必要性の有無」には、備品が必要であるか否かを示す情報が記憶される。図１０の例では、備品が必要であることを示す情報として「必要」が、備品が不要であることを示す情報として「不要」が記憶されている。

「個数」には、備品を必要とする数が記憶される。

「消費期限」には、備品の消費期限が記憶される。図１０の例では、消費期限が記憶されているが、消費期限だけではなく、賞味期限や使用期限であってもよい。

「未購入／購入済」には、備品を購入済みであるか否かを示す情報が記憶される。図１０（後述する図１１）の例では、備品を購入済みであることを示す情報として、「購入済」が記憶され、また備品を購入済みではない（購入していない）ことを示す情報として、「未購入」が記憶される。

「ネット購入の可否」には、ネットによる購入（オンラインショップからの購入）が可能か否かを示す情報が記憶される。図１３の例では、ネットによる購入が可能なことを示す情報として「可能」が、また、ネットによる購入が不可能なことを示す情報として「不可」が記憶されている。

また、災害備品リストテーブルは、ステップＳ１５２４で会員情報テーブル（図８）のユーザＩＤ毎に、サーバ１０１の外部メモリ２１１に記憶されている。

次に、図１６の説明に戻る。

サーバ１０１は、ステップＳ１６０９で算出された累積金額が、ステップＳ１５２４で会員情報テーブル（図８）に登録されたレコードの制限金額を超えないと判定された場合は（ＮＯ）、処理をステップＳ１６１１に移行する。

ステップＳ１６１１では、必要備品決定テーブル（図１３）の現在処理対象のレコードの「ネット購入」が「可能」であるか「なし」であるかを判定する。すなわち、サーバ１０１は、現在処理対象のレコードの備品について、ネット購入が可能であるか否かを判定する。

そして、サーバ１０１は、「ネット購入」が「可能」である（ネット購入が可能である）と判定された場合は（ステップＳ１６１１：ＹＥＳ）、処理をステップＳ１６１３に移行し、「ネット購入」が「なし」である（ネット購入が不可能である）と判定された場合は（ステップＳ１６１１：ＮＯ）、処理をステップＳ１６１２に移行する。

ステップＳ１６１３では、サーバ１０１は、サーバ１０１の外部メモリ２１１に記憶される、ステップＳ１５２４で会員情報テーブル（図８）に登録されたユーザＩＤの災害備品リストテーブル（図１０）に、必要備品決定テーブル（図１３）の現在処理対象のレコードの備品の備品名称を記憶する。

また、ステップＳ１６１３では、該災害備品リストテーブル（図１０）の「ネット購入の可否」に「可能」が記憶される。

また、ステップＳ１６１３では、該備品が必要であることを示す情報（「必要」）を「必要性の有無」に登録する。

また、ステップＳ１６１３では、「個数」には、ステップＳ１６０８、又はステップＳ１６０７で算出された必要備品数を必要備品個数として登録する。

また、ステップＳ１６１３では、「消費期限」には「―」を登録し、「未購入／購入済」には「未購入」を登録する。

ステップＳ１６１２では、サーバ１０１は、サーバ１０１の外部メモリ２１１に記憶される、ステップＳ１５２４で会員情報テーブル（図８）に登録されたユーザＩＤの災害備品リストテーブル（図１０）に、必要備品決定テーブル（図１３）の現在処理対象のレコードの備品の備品名称を記憶する。

また、ステップＳ１６１２では、該災害備品リストテーブル（図１０）の「ネット購入の可否」に「不可」が記憶される。

また、ステップＳ１６１２では、該備品が必要であることを示す情報（「必要」）を「必要性の有無」に登録する。

また、ステップＳ１６１２では、「個数」には、ステップＳ１６０８、又はステップＳ１６０７で算出された必要備品数を必要備品個数として登録する。

また、ステップＳ１６１２では、「消費期限」には「―」を登録し、「未購入／購入済」には「未購入」を登録する。

サーバ１０１は、ステップＳ１６１２、又はステップＳ１６１３、又はステップＳ１６１４の処理を実行すると、処理をステップＳ１６１５に移行して、必要備品決定テーブル（図１３）の全てのレコードに対して処理を実行したか否かを判定し、必要備品決定テーブル（図１３）の全てのレコードに対して処理を実行したと判定された場合は、処理を図１７に示すステップＳ１７０１に移行する。

一方、必要備品決定テーブル（図１３）の全てのレコードに対して処理を実行していないと判定された場合は、次に、優先順位の高い（必要備品決定テーブルのまだ処理を実行していないレコードのうち、優先順位の値が最も低い）レコードを処理対象とし、ステップＳ１６０３に処理を戻す。

サーバ１０１は、必要備品決定テーブル（図１３）の全てのレコードに対して処理を実行すると、例えば図１０に示す災害備品リストテーブルを生成し、サーバ１０１の外部メモリ２１１に記憶する。

ステップＳ１６１２、ステップＳ１６１３、ステップＳ１６１４は、本発明の決定手段の適用例である。

次に、図１７に示すフローチャートを用いてステップＳ１４０３の詳細処理について説明する。

図１７は、ステップＳ１４０３の備品リスト表示・更新処理の詳細処理を示すフローチャートである。

ステップＳ１７０１、ステップＳ１７０２、ステップＳ１７１０、ステップＳ１７１１に示す処理は、サーバ１０１のＣＰＵ２０１によって実行され実現される。

また、ステップＳ１７０３からステップＳ１７０９に示す処理は、クライアント端末１０２のＣＰＵ２０１によって実行され実現される。

まず、サーバ１０１は、サーバ１０１の外部メモリ２１１に記憶されている災害備品リストテーブル（図１０）、及び災害備品販売サイトのＵＲＬテーブル（図１２）を取得して、該災害備品リストテーブル（図１０）、及び災害備品販売サイトのＵＲＬテーブル（図１２）に基づいて、図６に示す必要備品リスト表示画面を表示するための表示情報（ＨＴＭＬ等）を生成する（ステップＳ１７０１）。

図６は、必要備品リスト表示画面の一例を示す図である。

図６の必要備品リスト表示画面には、購入済みかを示す情報としてのチェックを入力するためのチェックボックス６０１と、必要な備品の名称の表示欄６０２と、当該備品の必要な個数の入力欄６０３と、当該備品の消費期限の入力欄６０４と、当該備品をネットで購入するか否かのボタン６０５とが表示される。

ここで、災害備品リストテーブル（図１０）の「必要性の有無」が「必要」と登録されているレコードの備品名称が６０２に表示される。また、当該備品の災害備品リストテーブル（図１０）の「未購入／購入済」が「未購入」であるか否かを判定し、「未購入／購入済」が「未購入」であると判定された場合は、６０１には、チェックは入力されずに表示される。また、当該備品の災害備品リストテーブル（図１０）の個数が６０３に表示される。また、当該備品の災害備品リストテーブル（図１０）の消費期限が６０４に表示される。また、当該備品の災害備品リストテーブル（図１０）の「ネット購入の可否」に登録されている値が「可能」であれば、「ネット購入」ボタン６０５に備品をネットで購入することを示す「する」が表示される。また、「ネット購入の可否」に登録されている値が「不可」であれば、６０５に備品をネットで購入することを示す「しない」が表示される。

６０５は、ユーザにより押下されることにより、ユーザによりネット購入する指示を受け付けることが可能となる。

災害備品販売サイトのＵＲＬテーブル（図１２）は、各備品をネット購入する場合のオンラインショップのＵＲＬが登録されている。

図１２は、災害備品販売サイトのＵＲＬテーブルの一例を示す図である。

災害備品販売サイトのＵＲＬテーブル（図１２）は、サーバ１０１の外部メモリ２１１に予め登録され記憶されている。

災害備品販売サイトのＵＲＬテーブルは、「備品名称」、「ＵＲＬ」の項目から構成されている。「備品名称」には、備品の名称が記憶され、「ＵＲＬ」には、当該備品を購入するオンラインショップ（災害備品ベンダーのオンラインショップ）のＵＲＬが記憶されている。

必要備品リスト表示画面（図６）の６０２に表示される必要とされる備品の名称（備品名称）に一致する、災害備品販売サイトのＵＲＬテーブル（図１２）の「備品名称」に紐付いて登録されている「ＵＲＬ」が、必要備品リスト表示画面（図６）の６０５のボタンに設定される。

図６、図１２の例では、必要備品リスト表示画面の６０２に必要備品として表示されている「非常用ラジオ」の「ネット購入」ボタン６０５には、ＵＲＬとして、「ｈｔｔｐ：／／＊＊＊．ｃｏ．ｊｐ／ｒａｄｉｏ」が設定される。

ステップＳ１７０１では、サーバ１０１は、必要備品リスト表示画面（図６）の６０２に表示される必要とされる備品の名称（備品名称）に一致する、災害備品販売サイトのＵＲＬテーブル（図１２）の「備品名称」に紐付いて登録されている「ＵＲＬ」が、６０５のボタンに設定された必要備品リスト表示画面（図６）を表示するための表示情報（ＨＴＭＬ等）を生成する。

次に、サーバ１０１は、ステップＳ１７０１で生成された、必要備品リスト表示画面（図６）を表示するための表示情報（ＨＴＭＬ等）を、クライアント端末１０２の表示部に表示させるべく送信（出力）する（ステップＳ１７０２）。

すなわち、ステップＳ１７０２は、本発明の出力手段の適用例である。

そして、クライアント端末１０２は、サーバ１０１から、必要備品リスト表示画面（図６）を表示するための表示情報（ＨＴＭＬ等）を受信すると（ステップＳ１７０３）、当該表示情報に従って、必要備品リスト表示画面（図６）をクライアント端末１０２のＣＲＴ２１０等の表示部に表示する（ステップＳ１７０４）。

これにより、クライアント端末１０２を操作しているユーザは、どの備品がいくつ必要であるかを把握することが可能となる。

次に、クライアント端末１０２は、ユーザの操作により、既に購入している備品について、その購入内容について必要備品リスト表示画面（図６）を介して入力を受け付ける。また、クライアント端末１０２は、「ネット購入」ボタン６０５のユーザによる押下により、これからネット購入する指示を受け付ける（ステップＳ１７０５）。

ステップＳ１７０５での、既に購入している備品の購入内容の入力受付は、例えば、具体的には、購入した備品について、６０１のチェックボックスへのチェックの入力、６０４の入力欄への消費期限の入力を受け付ける。また、ここで、必要備品リスト表示画面（図６）を介して、備品の個数についても、入力を受け付けることができる。

これにより、どの備品を必要備品数、購入しており、その消費期限がいつまでかを、サーバ１０１が管理することが可能となる。

そして、クライアント端末１０２は、「ネット購入」ボタン６０５のユーザによる押下がなされたか否かを判定し、「ネット購入」ボタン６０５が押下されたと判定された場合は（ステップＳ１７０６：ＹＥＳ）、処理をステップＳ１７０７に移行して、災害備品ベンダーへの発注処理を実行する（ステップＳ１７０７）。一方、「ネット購入」ボタン６０５が押下されていないと判定された場合は（ステップＳ１７０６：ＮＯ）、処理をステップＳ１７０８に移行する。 ステップＳ１７０７の災害備品ベンダーへの発注処理の詳細処理の説明は、図１８を用いて、後で説明する。

そして、サーバ１０１は、必要備品リスト表示画面に表示されている登録ボタンがユーザにより押下されたか否かを判定し、ユーザにより当該登録ボタンが押下されたと判定された場合は（ステップＳ１７０８：ＹＥＳ）、必要備品リスト表示画面に入力された購入内容を示す情報をサーバ１０１に送信する（ステップＳ１７０９）。ここで、購入内容を示す情報とは、必要備品リスト表示画面（図６）に入力された情報（ステップＳ１７０４で表示された必要備品リスト表示画面の内容から変更された内容を示す情報）を示し、例えば、上述した６０１、６０４、６０３への入力内容である。

例えば、ステップＳ１７０５で、必要備品リスト表示画面（図６）に「非常用ラジオ」を購入したことを示すチェックを６０１に入力され、「水（ペットボトル１．５Ｌ（リットル））」を購入したことを示すチェックを６０１に入力され、「水（ペットボトル１．５Ｌ（リットル））」の消費期限が６０４に「２０１２．０１．１５」と入力され、「サバイバル米（１００ｇ）」を購入したことを示すチェックを６０１に入力され、「サバイバル米（１００ｇ）」の消費期限が６０４に「２０１５．０８．３１」と入力され、「オムツ（大人用：２４枚入り）」を購入したことを示すチェックを６０１に入力され、「オムツ（大人用：２４枚入り）」の消費期限が６０４に「２０１３．０１．３１」と入力された場合、図７に示す必要備品リスト表示画面が表示される。

図７は、ステップＳ１７０５で備品の購入内容が入力された必要備品リスト表示画面の一例を示す図である。

そして、クライアント端末１０２は、登録ボタン７０１が押下されると、ステップＳ１７０５で入力された購入内容を示す情報をサーバ１０１に送信する。

次に、サーバ１０１は、クライアント端末１０２から、購入内容を示す情報を受信すると（ステップＳ１７１０）、当該受信した購入内容を示す情報に従って、サーバ１０１の外部メモリ２１１に記憶されている災害備品リストテーブル（図１０）の内容を更新する（ステップＳ１７１１）。 サーバ１０１は、ステップＳ１７１０で、購入済みの備品の消費期限、又は賞味期限の入力を受け付ける（入力受付手段）。

具体的には、例えば、図７に示す必要備品リスト表示画面のように、「非常用ラジオ」を購入したことを示すチェックを６０１に入力され、「水（ペットボトル１．５Ｌ（リットル））」を購入したことを示すチェックを６０１に入力され、「水（ペットボトル１．５Ｌ（リットル））」の消費期限が６０４に「２０１２．０１．１５」と入力され、「サバイバル米（１００ｇ）」を購入したことを示すチェックを６０１に入力され、「サバイバル米（１００ｇ）」の消費期限が６０４に「２０１５．０８．３１」と入力され、「オムツ（大人用：２４枚入り）」を購入したことを示すチェックを６０１に入力され、「オムツ（大人用：２４枚入り）」の消費期限が６０４に「２０１３．０１．３１」と入力された場合、ステップＳ１７１１では、災害備品リストテーブル（図１０）の備品名称「非常用ラジオ」の「未購入／購入済」を「購入済」に、備品名称「水（ペットボトル１．５Ｌ（リットル））」の「消費期限」を「２０１２．０１．１５」に、備品名称「水（ペットボトル１．５Ｌ（リットル））」の「未購入／購入済」を「購入済」に、備品名称「サバイバル米（１００ｇ）」の「消費期限」を「２０１５．０８．３１」に、備品名称「サバイバル米（１００ｇ）」の「未購入／購入済」を「購入済」に、備品名称「オムツ（大人用：２４枚入り）」の「消費期限」を「２０１３．０１．３１」に、備品名称「オムツ（大人用：２４枚入り）」の「未購入／購入済」を「購入済」に、更新される。

このようにして、更新された災害備品リストテーブルを図１１に示す。

図１１は、ステップＳ１７１１で更新された災害備品リストテーブルの一例を示す図である。

次に、図１８を用いて、図１７に示すステップＳ１７０７の詳細処理について説明する。

図１８は、ステップＳ１７０７の詳細処理を示すフローチャートである。

ステップＳ１８０１、ステップＳ１８０４からステップＳ１８０７、ステップＳ１８１１、ステップＳ１８１２に示す処理は、クライアント端末１０２のＣＰＵ２０１によって実行され実現される。

また、ステップＳ１８０２、ステップＳ１８０３、ステップＳ１８０８、ステップＳ１８０９、ステップＳ１８１０に示す処理は、災害備品ベンダーサーバ１０４のＣＰＵ２０１によって実行され実現される。

まず、クライアント端末１０２は、ステップＳ１５０１で起動したブラウザとは別の新しいブラウザを起動して（タブ付ブラウザであれば、新しいタブを表示して）、ステップＳ１７０６で押下されたと判定された「ネット購入」ボタン６０５に設定されているＵＲＬへのアクセスを行い、当該ＵＲＬでアクセスされる災害備品ベンダーサーバ１０４に対して、該「ネット購入」ボタン６０５の災害備品の販売画面を表示するための表示情報（ＨＴＭＬなど）の取得要求を送信する（ステップＳ１８０１）。

そして、災害備品ベンダーサーバ１０４は、クライアント端末１０２から、災害備品の販売画面を表示するための表示情報（ＨＴＭＬなど）の取得要求を受信すると（ステップＳ１８０２）、当該表示情報をクライアント端末１０２に送信する（ステップＳ１８０３）。

次に、クライアント端末１０２は、災害備品ベンダーサーバ１０４から、該表示情報を受信すると（ステップＳ１８０４）、該表示情報に従って、不図示の災害備品の販売画面を、クライアント端末１０２のＣＲＴ２１０などの表示部に表示する（ステップＳ１８０５）。

そして、クライアント端末１０２は、災害備品の販売画面を介して、ユーザによる、災害備品の注文内容の入力を受け付け（ステップＳ１８０６）、入力された注文内容を災害備品ベンダーサーバ１０４に送信する（ステップＳ１８０７）。ここで、注文内容とは、少なくとも、購入する備品（災害備品）、該備品（災害備品）を購入する数を含む情報である。

次に、災害備品ベンダーサーバ１０４は、クライアント端末１０２から、注文内容を受信すると（ステップＳ１８０８）、災害備品ベンダーサーバ１０４の外部メモリ２１１に、該注文内容に含まれる備品の名称に対応して記憶されている、クライアント端末１０２を操作しているユーザに対して販売する該備品の消費期限を、クライアント端末１０２に送信する（ステップＳ１８０９）。

そして、クライアント端末１０２は、災害備品ベンダーサーバ１０４から、該備品の消費期限を受信すると、該備品の消費期限をクライアント端末１０２のＣＲＴ２１０などの表示部に表示する（ステップＳ１８１１）。

そして、ユーザは、ステップＳ１８１１で表示された消費期限を確認して、ステップＳ１５０１で起動されたブラウザに表示されている必要備品リスト表示画面（図６）の６０４にその消費期限を入力する。また、ユーザは、該備品が購入済みであることを示すチェックを６０１に入力する。

クライアント端末１０２は、備品の消費期限、購入済みであることを示すチェックの入力を受け付けると（ステップＳ１８１２）、処理を図１７に示すステップＳ１７０８に移行する。

また、災害備品ベンダーサーバ１０４は、ステップＳ１８０９で災害備品の消費期限をクライアント端末１０２に送信すると、該災害備品を、クライアント端末１０２を操作しているユーザに発送するための発送処理を行う。

なお、この発送処理の発送先となる当該ユーザの住所などの情報（発送先情報）は、ステップＳ１８０６で入力され、注文内容に含まれているものとする。そのため、発送処理では、災害備品ベンダーサーバ１０４は、その注文内容に含まれている発送先情報に、注文を受け付けた災害備品を発注するための処理を行う。

災害備品ベンダーサーバ１０４は、ステップＳ１８１０で災害備品の発送処理を行うと、処理をステップＳ１８０２に戻す。

ステップＳ１８０９、ステップＳ１８１１、ステップＳ１８１２、ステップＳ１８１０では、災害備品ベンダーサーバ１０４から受信してクライアント端末１０２の表示部に表示された消費期限を、ユーザが確認して、災害備品リスト表示画面の６０４に、その消費期限を手入力し、６０１にチェックを手入力することについて、説明した。

次に、この他の例として、災害備品ベンダーサーバ１０４が、サーバ１０１にアクセスして、サーバ１０１に記憶されている災害備品リストテーブル（図１０）を自動的に更新する処理について説明する。

図１８に示すステップＳ１８０９、ステップＳ１８１０、ステップＳ１８１１、ステップＳ１８１２の代わりに、ステップＳ１８１３、ステップＳ１８１４、ステップＳ１８１５の処理を実行する。

ステップＳ１８１３に示す処理は、災害備品ベンダーサーバ１０４のＣＰＵ２０１によって実行され実現される。

また、ステップＳ１８１４、ステップＳ１８１５に示す処理は、サーバ１０１のＣＰＵ２０１によって実行され実現される。

クライアント端末１０２と、災害備品ベンダーサーバ１０４は、ステップＳ１８０１からステップＳ１８０８までの処理を、上述の通り、実行する。そして、災害備品ベンダーサーバ１０４は、ステップＳ１８０８で、注文内容をクライアント端末１０２から受信すると、災害備品ベンダーサーバ１０４の外部メモリ２１１に、該注文内容に含まれる備品の名称に対応して記憶されている、クライアント端末１０２を操作しているユーザに対して販売する該備品の消費期限を、サーバ１０１に送信する（ステップＳ１８１３）。なお、ステップＳ１８１３では、クライアント端末１０２のユーザＩＤや該備品の名称も一緒にサーバ１０１に送信する。

サーバ１０１は、災害備品ベンダーサーバ１０４から、ユーザＩＤと、備品の名称、備品の消費期限を受信すると（ステップＳ１８１４）、外部メモリ２１１に記憶されている該ユーザＩＤの災害備品テーブルの、該備品の名称（備品名称）の消費期限に、ステップＳ１８１４で受信した消費期限を入力して、災害備品リストテーブルを更新する（ステップＳ１８１５）。

サーバ１０１は、ステップＳ１８１４で、購入済みの備品の消費期限、又は賞味期限の入力を受け付ける（入力受付手段）。

このようにして、災害備品ベンダーサーバ１０４が、サーバ１０１にアクセスして、サーバ１０１に記憶されている災害備品リストテーブル（図１０）を自動的に更新することが可能となる。

次に、購入時期通知処理について、図１９を用いて説明する。

図１９は、購入時期通知処理の一例を示すフローチャートである。

ステップＳ１９０１からステップＳ１９１３に示す処理は、サーバ１０１のＣＰＵ２０１によって実行され実現される。

また、ステップＳ１９１４からステップＳ１９１５に示す処理は、クライアント端末１０２のＣＰＵ２０１によって実行され実現される。

まず、サーバ１０１は、前回、購入時期通知処理を実行したときから、予め設定された期間（例えば２４時間）を経過したか否かを判定する（ステップＳ１９０１）。

すなわち、ステップＳ１９０１では、前回、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定してから所定期間を経過したか否かを判定する。

そして、サーバ１０１は、前回、購入時期通知処理を実行したとき（災害後の生活で必要となる備品と該備品の数を決定して）から、予め設定された期間（例えば２４時間）を経過したと判定された場合は（ステップＳ１９０１：ＹＥＳ）、会員情報テーブル（図８）、同居人情報テーブル（図９）を外部メモリ２１１から読み込み取得する（ステップＳ１９０２）。

一方、ステップＳ１９０１で、前回、購入時期通知処理を実行したときから、予め設定された期間（例えば２４時間）を経過していないと判定された場合は（ＮＯ）、処理をステップＳ１９０１に戻し、サーバ１０１は、予め設定された期間（例えば２４時間）を経過するときを待つ。

そして、サーバ１０１は、ステップＳ１９０２で取得した会員情報テーブル（図８）のレコード毎に、ステップＳ１９０４からステップＳ１９１３に示す処理を実行し、これら全てのレコードを処理するまで繰り返し、ステップＳ１９０４からステップＳ１９１３に示す処理を実行する。

まず、サーバ１０１は、ステップＳ１９０２で取得した会員情報テーブル（図８）の各レコードのうち、１つのレコードを処理対象とする。また、サーバ１０１は、当該処理対象とした会員情報テーブル（図８）のレコードの同居人情報ＩＤが同一の、同居人情報テーブル（図９）のレコードを処理対象とし、処理対象としているレコードのユーザＩＤの災害備品リストテーブルを更新対象の情報とする。

そのため、ここで、該ユーザＩＤの災害備品リストテーブルを読み込み（取得し）、ステップＳ１９０４の処理を実行する。

ステップＳ１９０４では、ここで現在処理対象としているレコードのユーザＩＤの災害備品リストテーブルを更新対象の情報として処理が実行される。

ステップＳ１９０４に示す備品リスト決定処理の詳細処理は、図１６に示す。

サーバ１０１は、図１６に示したステップＳ１６０１から、ステップＳ１６１５の処理を実行することにより、現在のユーザ及び同居人の状況に適した災害備品リストテーブルに更新することが可能となる。すなわち、現在のユーザ及び同居人の状況で、新たに必要となる備品、今後、不要となる備品、及びその数等を把握することが可能となる。

図１６に示した備品リスト決定処理の詳細処理の説明は、上述しているため、ここでは、説明を省略する。

そして、サーバ１０１は、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルを外部メモリから読み込む。

次に、サーバ１０１は、更新対象として読み込まれた更新前の災害備品リストテーブル内の各データと、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの各データとを比較して（ステップＳ１９０５）、更新前の災害備品リストテーブルの内容から、ステップＳ１９０４の処理がなされた後の災害備品リストテーブルの内容に変更があるか否かを判定する（ステップＳ１９０６）。

そして、サーバ１０１は、災害備品リストテーブルの内容に変更がないと判定された場合は（ステップＳ１９０６：ＮＯ）、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、現在の日時を超えている（消費期限切れである）か否かを判定する（ステップＳ１９０８）。

ステップＳ１９０８、ステップＳ１９０７は、購入済みの備品の消費期限、又は賞味期限が切れているかを判定する（期限判定手段）。

そして、サーバ１０１は、ステップＳ１９０８で、災害備品リストテーブルの消費期限が、現在の日時を超えていると判定された場合は（ＹＥＳ）、ステップＳ１９０８で消費期限切れであると判定された備品の名称と、該備品が期限切れであることを示す文言とを含む電子メール（通知メール）を生成する（ステップＳ１９０９）。ここで生成される電子メールのメール本文には、例えば、「備品（水（ペットボトル１．５Ｌ（リットル）））の消費期限が切れています」などのメッセージを含んでいる。

また、ここで生成される電子メールの宛先には、現在処理対象としている会員情報テーブルのレコードの「メールアドレス１（通知先）」、「メールアドレス２（通知先）」に登録されている電子メールアドレスが設定される。

ステップＳ１９０８では、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、現在の日時を超えている（消費期限切れである）か否かを判定する例について、説明したが、ステップＳ１９０８では、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、予め設定された、現在よりも所定の期間先の（将来の）日時を超えているか否かを判定するようにしてもよい。この場合、ステップＳ１９０９では、そろそろ消費期限を超える備品が有ることを示す情報を含む電子メールを生成する。これにより、ユーザは、そろそろ消費期限を超える備品があることを把握することができるようになる。

サーバ１０１は、ステップＳ１９０８で、（更新された）災害備品リストテーブルの消費期限が、現在の日時を超えていない（または、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、予め設定された、現在よりも所定の期間先の（将来の）日時を超えていない）と判定された場合（ＮＯ）、処理をステップＳ１９１３に移行する。

サーバ１０１は、ステップＳ１９０９で電子メールが生成されると、当該電子メールをクライアント端末１０２の表示部に表示させるべく送信（出力）する（ステップＳ１９１２）。
すなわち、ステップＳ１９１２は、本発明の出力手段の適用例である。

そして、サーバ１０１は、災害備品リストテーブルの内容に変更があると判定された場合は（ステップＳ１９０６：ＹＥＳ）、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、現在の日時を超えている（または、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、予め設定された、現在よりも所定の期間先の（将来の）日時を超えている）か否かを判定する（ステップＳ１９０７）。

そして、サーバ１０１は、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、現在の日時を超えている（または、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、予め設定された、現在よりも所定の期間先の（将来の）日時を超えている）と判定された場合は（ＹＥＳ）、ステップＳ１９０７で消費期限切れである（または、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、予め設定された、現在よりも所定の期間先の（将来の）日時を超えている）と判定された備品の名称と、該備品が期限切れであることを示す文言と、災害備品リストテーブルの変更された内容（変更内容）を含む電子メール（通知メール）を生成する（ステップＳ１９１０）。ここで生成される電子メールのメール本文には、例えば、「備品（水（ペットボトル１．５Ｌ（リットル）））の消費期限が切れています（または、そろそろ切れます）。また、新しい備品として、「オムツ（大人用：２４枚入り）が必要となります」」などのメッセージを含んでいる。

また、ここで生成される電子メールの宛先には、現在処理対象としている会員情報テーブルのレコードの「メールアドレス１（通知先）」、「メールアドレス２（通知先）」に登録されている電子メールアドレスが設定される。

また、サーバ１０１は、ステップＳ１９０７において、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、現在の日時を超えていない（または、ステップＳ１９０４の処理がなされた後の（更新された）災害備品リストテーブルの消費期限が、予め設定された、現在よりも所定の期間先の（将来の）日時を超えていない）と判定された場合（ＮＯ）、災害備品リストテーブルの変更された内容（変更内容）を含む電子メール（通知メール）を生成する（ステップＳ１９１１）。ここで生成される電子メールのメール本文には、例えば、「新しい備品として、「オムツ（大人用：２４枚入り）が必要となります」」などのメッセージを含んでいる。

また、ここで生成される電子メールの宛先には、現在処理対象としている会員情報テーブルのレコードの「メールアドレス１（通知先）」、「メールアドレス２（通知先）」に登録されている電子メールアドレスが設定される。

サーバ１０１は、ステップＳ１９０９、ステップＳ１９１０、ステップＳ１９１１で生成された電子メール（通知メール）を送信する（ステップＳ１９１２）。

そして、サーバ１０１は、ステップＳ１９０２で取得した会員情報テーブル（図８）の各レコードのうち、まだ、処理をしていないレコードがあるか否かを判定して、まだ、処理をしていないレコードがあると判定された場合は、処理をステップＳ１９０３に処理を戻す。一方、会員情報テーブル（図８）の全てのレコードについて処理をしたと判定された場合は、処理を一旦終了して、所定時間後に起動してステップＳ１９０１の処理を再開する。

クライアント端末１０２は、サーバ１０１から通知メールを受信すると（ステップＳ１９１４）、当該通知メールをクライアント端末１０２の表示部に表示する（ステップＳ１９１５）。

以上説明したように、本実施の形態によれば、ユーザの災害後のライフスタイルを示すライフスタイル情報と、該ユーザとその同居人を示すユーザ情報とに従って、災害後の生活で必要な備品の名称と、その数をユーザに提示させることにより、ユーザによる煩雑な作業を低減させると共に、適切に、災害後の生活で必要な備品をユーザに把握させることができる。

以上、本発明の一実施形態を詳述したが、本発明は、例えば、システム、装置、方法、装置で読み取り実行可能なプログラム（コンピュータプログラム）もしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

１０１ サーバ １０２ クライアント端末 １０３ クライアント端末 １０４ 災害備品ベンダーサーバ １０５ 災害備品ベンダーサーバ １０６ ネットワーク（インターネット） １０７ 複数のクライアント端末 １０８ 複数の災害備品ベンダーサーバ

Claims (7)

1. クライアント端末と通信可能に接続され、災害後の生活に必要な備品の名称を前記クライアント端末に出力する情報処理装置であって、
   災害後のライフスタイルを示すライフスタイル情報と、該ライフスタイル情報に示されるライフスタイルでの災害後の生活に必要となる備品の名称と、前記クライアント端末から受信される、ユーザと該ユーザの同居人とを示すユーザ情報から、災害後の生活で必要となる該備品の数を決定するための備品情報とが関連付けられた必要備品決定情報を記憶する記憶手段と、
   ユーザと該ユーザの同居人とを示すユーザ情報と、該ユーザ情報に示されるユーザと該ユーザの同居人の災害後のライフスタイルを示すライフスタイル情報と、を前記クライアント端末から受信する受信手段と、
   前記記憶手段に記憶された必要備品決定情報と、前記受信手段で受信したライフスタイル情報と前記ユーザ情報とに従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定する決定手段と、
   前記決定手段で決定された備品の名称と、該備品の数とを前記クライアント端末の表示部に表示させるべく出力する出力手段と、
   を備えることを特徴とする情報処理装置。
2. 前記記憶手段に記憶されている必要備品決定情報に含まれる備品情報は、前記クライアント端末から受信される災害後の生活日数とユーザ情報とから、災害後の生活で必要となる備品の数を決定するための備品数決定情報を含み、
   前記受信手段は、更に、前記クライアント端末から受信されるライフスタイル情報に示されるライフスタイルでの災害後の生活日数を前記クライアント端末から受信し、
   前記決定手段は、前記記憶手段に記憶された必要備品決定情報と、前記受信手段で受信したライフスタイル情報と前記ユーザ情報と前記生活日数とに従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定することを特徴とする請求項１に記載の情報処理装置。
3. 前記記憶手段に記憶されている必要備品決定情報は、更に、前記クライアント端末から受信される前記ユーザ情報に含まれるユーザと該ユーザの同居人との生年月日から特定される現在の該ユーザと該ユーザの同居人の年齢から、災害後の生活に必要とされる備品の名称を決定するための年齢条件が、前記備品の名称と関連付けられて含まれており、
   前記受信手段で受信されるユーザ情報には、更に、ユーザと該ユーザの同居人の生年月日を含み、
   前記決定手段は、前記記憶手段に記憶された必要備品決定情報と、前記受信手段で受信したライフスタイル情報と、前記ユーザ情報に含まれる生年月日から特定される現在のユーザと該ユーザの同居人の年齢と、に従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記決定手段は、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定してから所定期間を経過した後に、再度、前記記憶手段に記憶された必要備品決定情報と、前記受信手段で受信したライフスタイル情報と、前記ユーザ情報に含まれる生年月日から特定される現在のユーザと該ユーザの同居人の年齢と、に従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定し、
   前記出力手段は、再度、前記決定手段で決定された備品の名称と、該備品の数とを前記クライアント端末の表示部に表示させるべく出力することを特徴とする請求項３に記載の情報処理装置。
5. 前記決定手段で決定された災害後の生活で必要となる備品のうち、購入済みの備品の消費期限、又は賞味期限の入力を受け付ける入力受付手段と、
   前記入力受付手段で入力を受け付けた購入済みの備品の消費期限、又は賞味期限が切れているかを判定する期限判定手段と、を更に備え、
   前記出力手段は、前記期限判定手段で、購入済みの備品の消費期限、又は賞味期限が切れていると判定された場合に、その旨を前記クライアント端末の表示部に表示させるべく出力することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
6. クライアント端末と通信可能に接続され、災害後のライフスタイルを示すライフスタイル情報と、該ライフスタイル情報に示されるライフスタイルでの災害後の生活に必要となる備品の名称と、前記クライアント端末から受信される、ユーザと該ユーザの同居人とを示すユーザ情報から、災害後の生活で必要となる該備品の数を決定するための備品情報とが関連付けられた必要備品決定情報を記憶する記憶手段を備えており、災害後の生活に必要な備品の名称を前記クライアント端末に出力する情報処理装置の制御方法であって、
   前記情報処理装置の受信手段が、ユーザと該ユーザの同居人とを示すユーザ情報と、該ユーザ情報に示されるユーザと該ユーザの同居人の災害後のライフスタイルを示すライフスタイル情報と、を前記クライアント端末から受信する受信工程と、
   前記情報処理装置の決定手段が、前記記憶手段に記憶された必要備品決定情報と、前記受信工程で受信したライフスタイル情報と前記ユーザ情報とに従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定する決定工程と、
   前記情報処理装置の出力手段が、前記決定工程で決定された備品の名称と、該備品の数とを前記クライアント端末の表示部に表示させるべく出力する出力工程と、
   を備えることを特徴とする制御方法。
7. クライアント端末と通信可能に接続され、災害後のライフスタイルを示すライフスタイル情報と、該ライフスタイル情報に示されるライフスタイルでの災害後の生活に必要となる備品の名称と、前記クライアント端末から受信される、ユーザと該ユーザの同居人とを示すユーザ情報から、災害後の生活で必要となる該備品の数を決定するための備品情報とが関連付けられた必要備品決定情報を記憶する記憶手段を備えており、災害後の生活に必要な備品の名称を前記クライアント端末に出力する情報処理装置で読み取り実行可能なプログラムであって、
   前記情報処理装置を、
   ユーザと該ユーザの同居人とを示すユーザ情報と、該ユーザ情報に示されるユーザと該ユーザの同居人の災害後のライフスタイルを示すライフスタイル情報と、を前記クライアント端末から受信する受信手段と、
   前記記憶手段に記憶された必要備品決定情報と、前記受信手段で受信したライフスタイル情報と前記ユーザ情報とに従って、災害後の生活に必要となる備品の名称と、災害後の生活で必要となる該備品の数を決定する決定手段と、
   前記決定手段で決定された備品の名称と、該備品の数とを前記クライアント端末の表示部に表示させるべく出力する出力手段として機能させることを特徴とするプログラム。
   
   
   
   

Images