説明

安否確認システムおよびプログラム

【課題】 本発明は、地震や水害等の災害時にシステムに登録している登録者の安否を確認する安否確認システムに関するものである。
【解決手段】 本発明の安否確認システムは、登録者に対応付けてメールアドレスを記憶した登録者情報記憶部と、登録者の安否情報を登録する安否情報記憶部、災害発生時に登録者のメールアドレスに安否確認メールを送信する安否確認メール送信手段、安否確認メールに対する返信メールを受信する返信メール受信手段、返信メールのメッセージから安否情報を抽出し、安否情報記憶部に返信者の安否情報を登録する安否情報登録手段、および返信メールの安否情報を除いたメッセージから名詞となる文字列を抽出し、その文字列を登録者記憶部の登録者と一致した場合に、安否情報記憶部に登録者を代理確認されたことを登録する代理確認登録手段、を備えるよう構成する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、地震や水害等の災害時にシステムに登録している登録者の安否を確認する安否確認システムに関するものである。
【背景技術】
【0002】
地震や水害等における大規模の災害発生時において、被災者の安否を確認するため安否確認システムが知られており、このようなシステムとして音声を用いるものと電子メールを用いるものとがある。
【0003】
音声を用いるシステムでは「災害用伝言ダイアル(商標)」が一般的になっており、これは被災地において被災者が電話番号171にダイアルして、ガイダンスに従って電話番号と伝言を伝えると、これらの情報が伝言蓄積装置に記憶され、被災者の関係者が電話番号171にダイアルして被災者の電話番号を指定すると、録音された伝言を聞くことができるものである。災害用伝言ダイヤルは、被災地内の電話番号をメールボックスとしたボイスメールということができる。
【0004】
電子メールを用いる方法は、電話回線やインターネットのネットワークを介して電子メールにより安否情報を収集するシステムである。一般的に行われている方法は、予め利用者が安否確認システムに自身のメールアドレスを登録しておくと、災害の発生時に登録してあるメールアドレスに安否確認のメール(以降、安否確認メールと言う)を一斉同報する。安否確認メールを受け取った登録者がその安否確認メールに対する回答を返信メールとしてシステムに送信すると、システムは返信メールの内容を安否情報DBに登録する。関係者がその安否情報DBにアクセスすることで登録者の安否の確認ができるものである。
【0005】
このような安否確認システムの従来例を図16と図17に示す。図16は、会社組織における安否確認システムの処理の流れを示した図で、災害発生時に安否確認サーバが登録者である組織のメンバーA〜Fに安否確認メールを送信し、メンバーAとFとからの返信メールの安否情報を安否情報DBに登録する流れる状態を示している。この例では、返信メールが短時間の操作で返信できるように、少なくとも安否の状態を示す特定の1文字(「あ」は無事、「か」は負傷、「さ」はその他、を意味するものとしている。因みにこの文字は、携帯電話の3つの並んだキーに対応している)を入力して返信すればよいことになっている。時間的余裕があれば、特定の1文字に続いてコメントの入力もできるようになっている。
【0006】
図17は、図16で示される返信メールに基づいて安否情報DBにシステムが安否情報を自動登録した例を示している。返信者である登録者の安否状況欄に、返信メールの最初の1文字を翻訳した内容が登録され、コメント欄に返信メールのコメントが登録されている。
【0007】
安否確認の返信メールをより簡便に行なう方法として、安否確認メールに対して何らの入力操作をせずにそのまま返信する方法が知られている。システムは返信メールがなされたことで返信者は「生存」と判断して安否情報DBに記憶するものである(例えば、特許文献1)。
【0008】
会社組織等のグループに属している者を対象とした安否確認システムも知られている。この安否確認システムは、予め組織のグループ毎にグループに属するメンバーを安否確認システムに登録しておき、組織の管理者からの安否確認メールの発信要求に基づいて、その管理者の配下に属する登録者を抽出し、抽出された登録者のメールアドレスに基づいて安否確認メールを配信するものである(例えば、特許文献2)。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】公開特許公報 特開2003−198751号公報
【特許文献2】公開特許公報 特開2007−188441号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
上記した安否確認システム(以降、単にシステムという場合がある)は、災害時に電話回線が輻輳し連絡がとれない、あるいは連絡がとり難いことから考案されたものであり、災害発生時の安否確認に大きな効果を発揮するものと考えられる。特に電子メールを利用したシステムは、一斉同報の長所を活かしてシステムが能動的に安否情報を収集する点で優れている(ボイスメールによる安否確認は、被災者が自発的に伝言を録音しない限り安否の確認は取れない)。
【0011】
しかしながら、電子メールを用いたシステムにおいて被災者が仮に健在であっても、登録者が所持または所有する端末が使えない状態(端末の破損や携帯電話の電池切れ等)の場合は、システムから発信された安否確認メールを受信できない、という問題がある。このため、被災者からの安否確認の回答率はある一定の値を得られるものの(例えば80%)、より高い回答率にするには限界があった。
【0012】
また、これらのシステムは登録者全員に安否確認メールを送信し、全員から返信メールによる回答を期待するものであるため、通信回線の輻輳を増長させる、という問題もある。
【0013】
このため、安否確認システムにおいては、少ない通信量で安否確認ができ、その上で被災者からの回答率を上げる仕組みを備えることが重要な課題となっていた。
【0014】
本発明は、従来技術における問題を解消し、課題を解決するためになされたものであり、登録者の所有する端末が使えない状態にあってもそれらの人の確認ができて被災者からの回答率を上げると共に、通信量を抑制した安否確認システムを提供することを目的とする。
【課題を解決するための手段】
【0015】
上記課題を解決するために本発明の安否確認システムは、登録者情報記憶部、安否情報記憶部、安否確認メール送信手段、返信メール受信手段、安否情報登録手段および代理確認登録手段から構成される。
【0016】
登録者情報記憶部は、登録者に対応付けてメールアドレスを記憶した記憶部であり、安否情報記憶部は、登録者の安否情報を登録する記憶部である。
【0017】
安否確認メール送信手段は、災害発生時に登録者情報記憶部を参照して登録者のメールアドレスに登録者の安否を問う安否確認メールを送信する。
【0018】
返信メール受信手段は、安否確認メールに対する返信メールを受信する。
【0019】
安否情報登録手段は、受信した返信メールのメッセージから安否情報を抽出し、安否情報記憶部に返信者の安否情報を登録する。
【0020】
代理確認登録手段は、返信メールの安否情報を除いたメッセージから名詞となる文字列を抽出し、その文字列を登録者記憶部の登録者と照合して一致した場合に、安否情報記憶部に登録者が代理確認されたことを登録するものである。
【発明の効果】
【0021】
安否確認メールに対する返信メールのメッセージから、返信者以外の登録者を抽出するようにしたので、登録者の所有する端末が使えない状態にあってもそれらの人の確認ができる安否確認システムを提供することができる。また、1通の返信メールで、返信者以外の人の確認ができるので通信量を抑制できる。
【図面の簡単な説明】
【0022】
【図1】安否確認システムの構成例である。
【図2】実施例その1の安否確認サーバの構成例である。
【図3】登録者情報DBのデータ例である。
【図4】安否情報DBのデータ例である。
【図5】実施例その1の安否確認サーバの処理フロー例である。
【図6】安否確認メールの例である。
【図7】登録者ID確認のメール例である。
【図8】安否確認サーバの端末との送受信と処理である。
【図9】実施例その2の安否確認サーバの構成例である。
【図10】登録者情報DBのデータ例である。
【図11】安否情報DBのデータ例である。
【図12】就業管理DBのデータ例である。
【図13】実施例その2の安否確認サーバの処理フロー例(1)である。
【図14】実施例その2の安否確認サーバの処理フロー例(2)である。
【図15】回答代表者に送信する代表用安否確認メールの例
【図16】従来の安否確認サーバの端末との送受信と処理である。
【図17】従来の安否情報DBのデータ例である。
【発明を実施するための形態】
【0023】
(実施例)
本発明の実施例を図1〜図15を用いて説明する。
【0024】
(実施例その1)
図1は、本発明の安否確認システム10の構成例を示したもので、安否確認システム10は安否確認サーバ100、携帯電話20〜22、パソコン30、31、管理端末40およびネットワーク50とで構成する。
【0025】
安否確認サーバ100は、安否確認システム10の登録者をメールアドレスと対応付けて記憶しておき、災害発生時にネットワーク50を介して登録者の端末である携帯電話20〜22あるいはパソコン30、31に安否確認メールを送信する。この安否確認メールに対し端末から返信された返信メールを受信し、安否情報を安否情報DBに登録する。このとき、返信メールのメッセージを解析し、メッセージ中に返信者以外の登録者名の情報があるとき、この登録者に対して代理確認の情報を安否情報登録DBに登録する。管理端末40は、登録者または登録者の関係者が安否確認サーバ10の安否情報DBにアクセスして登録者の安否を知る端末である。
【0026】
図2は、安否確認サーバ100の構成例を示し、安否確認サーバ100はプログラムやデータを制御する主制御部110、主メモリ120上に展開した安否確認プログラム130、安否確認の対象者である登録者の情報を記憶する登録者情報DB140、安否情報が登録される安否情報DB141、ネットワーク50を介して登録者の端末とメールの送受信を制御する通信制御部150から構成する。
【0027】
次に、登録者情報DB140と安否情報DB141のデータ例について説明する。
【0028】
図3は、登録者情報DB140のデータ例を示すもので、「氏名」、「登録ID」、「生年月日」、「年齢」、「性別」、「メールアドレス」、「電話番号」の各フィールドで構成している。この登録者情報DB140で重要なフィールドは、「氏名」と「登録ID」、「メールアドレス」のフィールドであり、他のフィールドは必要に応じて適宜変更してよい。また、本実施例では、会社組織における安否確認システムを例としており、登録IDは所属するグループのIDと同一のものとしている。ここでは、「1234」と「1106」の2つのグループの登録者を示している。なお、電話番号もグループの代表番号を登録しているため、グループ内は同じ電話番号を登録している。
【0029】
図4は、安否情報DB141のデータ例を示すもので、「氏名」、「送信日時」、「受信日時」、「安否状況」、「コメント」、「備考」の各フィールドで構成している。「送信日時」は安否確認メールを送信した日時であり、「受信日時」は安否確認メールの送信に対する返信メールを受信した日時である。「安否状況」は返信メールのメッセージから抽出された安否情報を登録するフィールドであり、「コメント」は返信メールのメッセージから安否情報を除いたメッセージである。返信メールのメッセージに返信者以外の登録者名の情報が書かれていた場合は、その登録者名が登録者情報DBに登録された登録者である場合に「安否状況」フィールドに“代理確認”が登録され、「備考」フィールドには代理確認した返信者の情報(ここでは、“Aさん確認”)が格納される。また、同時にその返信者の「備考」フィールドには、代理確認者であることを示す“代理確認者”が格納される。
【0030】
図2に戻って、安否確認プログラム130は、さらに各人安否確認メール送信部131、返信メール受信/解析部132、安否情報登録部133、登録ID照会部134および安否情報登録通知メール送信部135からなる。各プログラムの概要を次に述べる。
【0031】
各人安否確認メール送信部131は、災害発生時に登録者情報DB140を参照して登録者の各人に安否確認メールを送信する。
【0032】
返信メール受信/解析部132は、各人安否確認メール送信部131で送信した安否確認メールに対する返信メールを受信し、受信した返信メールのメッセージを解析することを行なう。解析により、メッセージから返信者の安否情報と、返信者以外の登録者名を抽出する。
【0033】
安否情報登録部133は、返信者の安否情報を安否情報DB141に登録すると共に、返信者以外の登録者で次に説明する登録IDが確認された登録者に対し、代理確認されたことを示す“代理確認”を安否情報DB141に登録する。
【0034】
登録ID照会部134は、返信メール受信/解析部132で抽出された登録者名が登録者情報DB140に登録された登録者であることを確認するため、返信メールの返信者に登録IDを問い合わせるメールを送り、回答された登録IDを登録者情報DBに照会する。この照会によって登録者情報DB140に登録された登録者であると確認された場合に、安否情報登録部133で代理確認が登録されることになる。
【0035】
安否情報登録通知メール送信部135は、返信メールを送信した返信者に、返信されたメールによって安否情報が安否情報DBに登録されたことを通知するものである。
【0036】
次に、安否確認サーバ100の処理フローについて図5を用いて説明する。図5の処理フローは、安否確認システム10が会社組織におけるものであり、組織のメンバーが登録者情報DB140に登録されている例を示している。また、その会社の所在は災害発生の地域に在るものとし、安否確認システム10が何らかの方法で災害発生(この例では地震)の情報を得て、それをトリガーに安否確認のプログラムを起動するものとする。
【0037】
図5において、まず安否確認システム10は登録者情報DB140を参照して登録者全員に安否確認メールを送信する(ステップS1、以降単にS1と記す)。安否確認メールのメール文は予め作成されてあるもので、例えば図6(a)に示すメッセージである。メッセージは、地震に対する被災害状況を返信して欲しい旨の依頼と、返信方法を記した内容である。登録者全員に、このメールが一斉同報される。また、安否情報DB141の「送信日時」フィールドに安否確認メッセージを送信した日時を書き込む。
【0038】
安否確認メールに基づいてメールを受け取った登録者から返信メールが送信され、安否確認サーバ100はこの返信メールを受信する。図6(b)は、図3に示す登録者情報DB140の「Aさん」からの返信メールの例を示す。「あBさん、Cさん、Eさんも会社にいます。」が返信内容で、それ以降の行頭の「>」で始まる文は送信メールのメール文のコピーである。図6(a)の安否確認メールに示すように、返信メールのメッセージ形式は、最初の1文字が安否情報を意味する特定の文字(「あ、か、さ」のいずれか1文字)の後にコメントが続くものとなっている。図6(b)の最初の1文字が「あ」であるので、返信者は「無事」であり、「Bさん、Cさん、Eさんも会社にいます。」がコメントということになる。なお、返信は安否情報のみで、コメントは無くてもよいことになっている。その場合は、例えば携帯電話の「あ」を押して(入力して)、返信ボタンを押すだけでよい(S2)。
【0039】
返信メールに基づいて、特定の1文字である返信者の安否情報を安否情報DB141に登録する。上記のように、返信者である「Aさん」は「無事」であるので、図4に示す安否情報DBの氏名「A」さんの「安否状況」フィールドに「無事」を書込む(記録する)。また、返信メールを受け取った受信日時の情報を「受信日時」フィールドに書き込む(S3)。
【0040】
続いて、返信メールのメッセージのコメント部分の文字列を形態素解析し、名詞を抽出する。図6(b)に示すコメント部分の「Bさん、Cさん、Eさんも会社にいます。」の場合、形態素解析により「B」、「C」、「E」、「会社」の文字列が抽出されることになる。抽出した文字列を登録者情報DB140の「氏名」フィールドに登録されている文字列と照合し、一致すればその文字列は登録者名ということになる。上記の例の場合、「B」、「C」、「E」が登録者情報DB140に一致し、「Bさん」、「Cさん」、「Eさん」がコメントとして書かれていることが判る。また、「会社」は一致しなかったので登録者名ではない、と判断できる。返信者にこの一致した登録者名の登録IDを問い合わせる照会メールを送信する。S6で抽出した文字列が登録者情報DB140に一つもなければ終了となる(S4〜S7)。
【0041】
図7(a)は照会メールの例である。登録者情報DB140で一致した登録者である「Bさん」、「Cさん」、「Eさん」に対する登録IDを入力できるようにしてある。
【0042】
登録IDの照会メールに対して返信された返信照会メールを受信し、返信照会メールから登録IDの情報を取り出し、登録者情報DB140の「登録ID」フィールドに登録された情報と照合する。照合の結果一致した登録IDの登録者に対し、安否情報DB141の「安否状況」に“代理確認”を記録する。また、「備考」フィールドには“代理確認者”を書き込む。一つも登録IDが一致しなければ終了となる(S8−S11)。
【0043】
図7(b)に返信照会メールの例を示す。図4の安否情報DB141のBさん、Cさん、Eさんの「安否状況」フィールドには“代理確認”が記録されている。また、「備考」フィールドには、代理確認したことを伝えた返信者である“Aさん確認”を書き込む。
【0044】
返信メールの返信した登録者(返信者)と、代理確認された登録者に対し安否情報DBに安否情報を登録した旨のメールを送信する(S12)。
【0045】
本発明の安否確認サーバ100と端末とのメールのやり取りを先に説明した図17と同様の形で図8に示す。図17と比較して、コメントに含まれる登録者を代理確認している点が追加されている。
【0046】
ここで、「Dさん」と「Fさん」の返信に対して処理フローで説明していなかったので、その内容について説明する。Dさんからの返信メールは「さN社のエレベータの中です」であるので、図4の安否情報DB141の「安否状況」には“その他”が書き込まれている(「さ」の安否情報は“その他”を意味する)。Dさんの返信メールのコメント部分を解析して名詞を抽出し、登録者情報DB140と照合したが登録者名と一致するものはなかったので「備考」フィールドは空白のままである。また、Fさんからは返信メールが届かなかったので図4の安否情報DB141の「送信日時」フィールド以外は空白となっている。
【0047】
本実施例により、端末に障害があるような登録者に対して代理確認を行えるようにしたので、安否の回答率は向上する。また、端末に障害がなくとも一人の登録者が近くに居る人の分をまとめてコメントに記載して返信できるので、通信量を抑制できる。また、登録IDの確認は、代理確認された人が間違いなく登録者情報DBに登録された登録者であることを確認するために行なっており、正しい情報が登録される。
【0048】
(実施例その2)
実施例その1の安否確認システム10は、災害発生時に登録者全員に安否確認メールを送り、返信メールのコメントに登録者の情報が含まれる場合は代理確認するものであった。実施例その2は、就業時間帯に災害が発生した場合にグループの代表回答者に安否確認メールを送信し、代理確認をより積極的に行なうものである。
【0049】
実施例その2の安否確認システム11の構成は、実施例その1の安否確認システム10の構成を示した図1と同様であるので説明を省略する。
【0050】
次に、実施例その2の安否確認サーバ101の構成を図9を用いて説明する。実施例その1で示した図2と異なる構成は、登録者情報DB142と安否情報DB143がデータの構成が変わることと、就業管理DB144と安否確認プログラムに代表用安否確認メール送信部161を新たに設ける点である。
【0051】
最初に、登録者情報DB142と安否情報DB143のデータ例を説明する。図10は登録者情報DB142のデータ例を示すもので、実施例その1の図3と較べて「代表回答順序」フィールドを追加している。代表回答順序は、災害発生時にグループ内で在席する人を代表として選ぶための順序である。ここでは、グループの中で年齢の高い人から順番に代表となるように定めている。なお、登録IDは前述したようにグループを識別するIDを用いており、登録IDにより登録者がどのグループに属しているか判る。
【0052】
図11は安否情報DBのデータ例を示し、実施例その1で説明した図4に「グループID」フィールドを付加したもので、他は同一である。ここでは、グループIDと登録IDは同一の番号としているが、別の番号にしてもよい。
【0053】
次に、就業管理DB144のデータ例を図12を用いて説明する。就業管理DB144はグループによって異なる就業時間帯とグループに属する登録者とその在席状況を示すデータベースである。図12に示すように、就業管理DB144は「グループID」、「就業時間」、「氏名」、「プレゼンス」の各フィールドを含む構成となっている。ここでは2つのグループがあり、グループIDが“1234”のグループの就業時間は“8:00〜17:00”であり、グループIDが“1106”のグループは“9:00〜18:00”であることが判る。また、1234”のグループのメンバー(登録者)はAさん〜Gさんであり、“1106”のグループはHさん〜・・である。Dさんは出張で、Fさんは休暇中であるが他のメンバーは在席している。なお、この会社は土日、祝日は休業日であるが、その情報は保持してなく暗黙の了解としている。
【0054】
続いて、安否確認サーバ101の処理フローを図13と図14を用いて説明する。
【0055】
図13は、安否確認サーバ101が安否確認メールを送信するフローを示している。ここでも実施例その1と同様に、安否確認システム11を用いている会社の所在は災害発生の地域に在るものとし、安否確認システム11が何らかの方法で災害発生(この例では地震)の情報を得て、それをトリガーに安否確認のプログラムを起動するものとする。まず、安否確認サーバ101が備えるカレンダークロック(図9で不図示)から日時tdを取得し、就業管理DB144を参照して、取得した日時tdにおける就業時間帯のグループの存在を調べる。図12の就業管理DB144から災害の発生が平日の8:00〜18:00であれば、いずれかのグループが就業時間帯にあることになる(S21〜S23)。
【0056】
次に、就業管理DB144と登録者情報DB142を参照して、グループ内で在席する登録者の中から代表回答者を決定する。例えば、災害が平日の8:30に発生したとすれば、就業管理DB144の「就業時間」フィールドのデータから“1234”のグループが就業時間帯にあり、このグループで在席する人は「プレゼンス」フィールドのデータからAさん、Bさん、Cさん、Eさん、Gさんであることが分かる。そして、登録者情報DB142の「代表回答順序」フィールドのデータから、Aさんを代表回答者として決定する(S24)。
【0057】
代表回答者と決定したAさん自身の安否と、Aさんを除く在席者(即ち、Bさん、Cさん、Eさん、Gさん)の安否の代理確認を行なって貰うための代表用安否確認メールのメール文の作成を行なう。メール文の作成が終わったら、このメール文をAさんに送信すると共に、安否情報DB143に送信日時を記録する。図15(a)に代表用安否確認メールの例を示す。Aさん自身の安否状況と、Bさん、Cさん、Eさん、Gさんに対する確認できたらチェックを入れるように依頼している(S25、S26)。
【0058】
続いて、就業管理DB144を参照して不在者を抽出し、この不在者に対して各人用安否確認メール(前記の代表用安否確認メールに対して、各人用安否確認メールと呼ぶ)を送信し、安否情報DB143に送信日時を記録する。各人用安否確認メールは実施例その1で示した図6の例と同一である(S28)。
【0059】
S23で就業時間帯にないグループに対しては、そのグループ全員に各人用安否確認メールを送信し、安否情報DB143に送信日時を記録する(S29)。
【0060】
S21〜S29までが安否確認サーバ101の安否確認メール(代表用安否確認メールおよび各人用安否確認メール)の送信の処理フローである。続いて、この安否確認メールに対して返信メールを受け付ける処理フローを図14を用いて説明する。
【0061】
まず、返信メールを受信すると、その返信メールが代表回答者からのものかを調べる。返信メールが代表回答者のものであった場合、安否情報DB143に返信者である代表回答者の「安否状況」フィールドに安否情報を、「備考」フィールドに代表回答者であることを示す“代表回答者”を、そして「受信日時」フィールドに返信メールを受信した日時を記録する。続いて、返信メールにチェックされたメンバーを調べ、そのメンバーの「安否状況」フィールドに“代理確認”を記録し、「備考」フィールドに代理確認した代表回答者を記録する。代表用安否確認メールに対する返信メールの例を図15(b)に示す。Bさん、Cさん、Gさんにはチェックがなされ、Eさんはチェックがされていない。このため、図11の安否確認DB143はBさん、Cさん、Gさんの「安否状況」フィールドには“代理確認”が書き込まれ、「備考」フィールドには“Aさん確認”が書き込まれている。Eさんは空白となっており、確認されなかったことが判る。チェックのないメンバーに対しては、各人用安否確認メールを送信し、そのメンバーの送信日時を記録する(S41〜S46)。
【0062】
S42で、返信メールが代表用安否確認メールでない場合、S47〜S56の処理が行なわれる。これは、実施例その1で説明した図5のS3〜S12と同一であるので説明を省略する(S47〜S56)。
【0063】
以上説明したように、実施例その2では災害が就業時間帯で発生した場合は、安否確認メールをグループの代表回答者に送るようにしたので通信量を抑制することができる。
【符号の説明】
【0064】
10、11 安否確認システム
20〜22 携帯電話
30、31 パソコン
40 管理端末
50 ネットワーク
100、101 安否確認サーバ
110 主制御部
120 主メモリ
130、160 安否確認プログラム
131 各人安否確認メール送信部
132 返信メール受信/解析部
133 安否情報登録部
134 登録ID照会部
135 安否情報登録通知メール送信部
140、142 登録者情報DB
141、143 安否情報DB
144 就業管理DB
161 代表用安否確認メール送信部

【特許請求の範囲】
【請求項1】
登録者に対応付けてメールアドレスを記憶する登録者情報記憶部と、
前記登録者の安否情報が登録される安否情報記憶部と、
災害発生時に前記登録者情報記憶部を参照して登録者のメールアドレスに該登録者の安否を問う安否確認メールを送信する安否確認メール送信手段と、
前記安否確認メールに対する返信メールを受信する返信メール受信手段と、
該返信メールのメッセージから安否情報を抽出し、前記安否情報記憶部に返信者の該安否情報を登録する安否情報登録手段と、
前記返信メールの安否情報を除いたメッセージから名詞となる文字列を抽出し、該文字列を前記登録者記憶部の登録者と照合して一致した場合に、前記安否情報記憶部に該登録者が代理確認されたことを登録する代理確認登録手段と
を備えることを特徴とする安否確認システム。
【請求項2】
前記登録者情報記憶部は、登録者に対応付けて登録IDとメールアドレスとを記憶し、
前記代理確認登録手段は、前記返信メールの安否情報を除いたメッセージから名詞となる文字列を抽出し、該文字列を前記登録者記憶部の登録者と照合して一致した場合に、該返信メールの返信者に該登録者の登録IDを問い合わせるメールを送信し、回答された登録IDと該登録者記憶部とを照合して正しいと確認された場合に該登録者が代理確認されたことを前記安否情報記憶部に登録する
ことを特徴とする請求項1に記載の安否確認システム。
【請求項3】
グループ毎に、該グループに属する登録者に対応付けてメールアドレスを記憶する登録者情報記憶部と、
前記グループの就業時間と前記登録者の在席状況とを記憶する就業管理記憶部と、
前記登録者の安否情報が登録される安否情報記憶部と、
日時情報を保持するカレンダークロックと、
災害発生時に前記カレンダークロックから日時情報を取得し、取得した日時情報に基づいて前記就業管理記憶部から就業時間中のグループを抽出し、抽出したそれぞれのグループにおいて在席する登録者の中から代表回答者を決める代表回答者決定手段と、
前記代表回答者と該代表回答者の属するグループの在席する登録者との安否を問うメール文を作成し、前記登録者情報記憶部を参照して該代表回答者に該メール文から成る代表安否確認メールを送信すると共に、該グループの不在の登録者に対して安否確認を行なう各人安否確認メールを送信する安否確認メール送信手段と、
前記代表安否確認メールおよび前記各人安否確認メールに対する返信メールを受信する返信メール受信手段と、
前記返信メールが代表安否確認メールに対する返信である場合は、前記安否情報記憶部に返信者である前記代表回答者の安否情報を登録すると共に、該代表安否確認メールに記載された登録者で該代表回答者によって安否確認がなされた登録者を代理確認として登録し、該返信メールが各人安否確認メールからの場合は、該安否情報記憶部に該返信メールの返信者である登録者の安否情報を登録する安否情報登録手段と
を備えることを特徴とする安否確認システム。
【請求項4】
コンピュータを、
災害発生時に、登録者のメールアドレスを記憶した登録者情報記憶部を参照して該登録者に安否を確認する安否確認メールを送信する安否確認メール送信手段と、
前記安否確認メールに対する返信メールを受信する返信メール受信手段と、
前記返信メールのメッセージから安否情報を抽出し、前記安否情報記憶部に返信者の該安否情報を登録する安否情報登録手段と、
前記返信メールの前記安否情報を除いたメッセージから名詞となる文字列を抽出し、該文字列を前記登録者記憶部の登録者と照合して一致した場合に、前記安否情報記憶部に該登録者が代理確認されたことを登録する代理確認登録手段と
して機能させるための安否確認プログラム。
【請求項5】
コンピュータを、
グループ毎に、該グループに属する登録者に対応付けてメールアドレスを記憶する登録者情報記憶手段と、
災害発生時に、日時情報を保持するカレンダークロックから日時情報を取得し、取得した日時情報に基づいて前記グループの就業時間と前記登録者の在席状況を記憶する就業管理記憶部から就業時間中のグループを抽出し、抽出したそれぞれのグループにおいて在席する登録者の中から代表回答者を決める代表回答者決定手段と、
前記代表回答者と該代表回答者の属するグループの在席する登録者との安否を問うメール文を作成し、前記登録者情報記憶手段を参照して該代表回答者に該メール文から成る代表安否確認メールを送信すると共に、該グループの不在の登録者に対して安否を問う各人安否確認メールを送信する安否確認メール送信手段と、
前記代表安否確認メールおよび前記各人安否確認メールに対する返信メールを受信する返信メール受信手段と、
前記返信メールが代表安否確認メールに対する返信である場合は、安否情報記憶部に返信者である前記代表回答者の安否情報を登録すると共に、該代表安否確認メールに記載された登録者で該代表回答者によって安否確認がなされた登録者を代理確認として登録し、該返信メールが各人安否確認メールからの場合は、該安否情報記憶部に該返信メールの返信者である登録者の安否情報を登録する安否情報登録手段と
して機能させるための安否確認プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate


【公開番号】特開2011−170821(P2011−170821A)
【公開日】平成23年9月1日(2011.9.1)
【国際特許分類】
【出願番号】特願2010−36690(P2010−36690)
【出願日】平成22年2月22日(2010.2.22)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】