安否情報確認システム
【課題】地震発生後に通信システムが輻輳し、安否情報の確認が行えない、といったトラブルを防止することができる安否情報確認システムを提供する。
【解決手段】本発明の安否情報確認システム１００は、自らの位置情報を無線で発信する携帯電話機（又はＰＨＳ電話機）１０１と、安否情報確認システム用ネットワークリソース１２４と、該携帯電話機（又はＰＨＳ電話機）１０１が交信する基地局１０６と通信回線によって接続される安否情報確認メインシステム１２１と、からなり、該安否情報確認メインシステム１２１は、緊急地震速報の入力を契機として、安否情報確認システム用ネットワークリソース１２４の優先順位を引き上げることを特徴とする。
【解決手段】本発明の安否情報確認システム１００は、自らの位置情報を無線で発信する携帯電話機（又はＰＨＳ電話機）１０１と、安否情報確認システム用ネットワークリソース１２４と、該携帯電話機（又はＰＨＳ電話機）１０１が交信する基地局１０６と通信回線によって接続される安否情報確認メインシステム１２１と、からなり、該安否情報確認メインシステム１２１は、緊急地震速報の入力を契機として、安否情報確認システム用ネットワークリソース１２４の優先順位を引き上げることを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大規模災害の発生時において予め登録してある登録者に対して被災者の安否情報確認情報等を発信することが可能な安否情報確認システムに関する。
【背景技術】
【０００２】
大地震等の自然災害発生時においては、家族、友人、社員、職員、在校生等の安否に係る情報をできるだけ早く知りたいと考えるものであり、また被災者本人も自身が安全であることや負傷してしまったこと等を家族、知人、会社、学校等にできるだけ早く知らせたいと考えるものである。 そこで、携帯電話、ＰＨＳ（Personal Handy-phone System）などの移動体通信の回線、インターネットを利用し、災害発生時に地域住民各個人の安否情報等を防災ポータルサイトなどで提供する安否情報確認システムが提案されている。このようなシステムは地震等の大規模な災害が発生した場合には、安否情報確認等の固定電話が急増して回線混雑により輻輳状態となるなどの混乱が生じ、被災者の安否を確認することができなくなってしまうことや、テレビ放送、ラジオ放送からの情報では、被災者各個人の安否情報を容易には入手できないことなどから、実用化が強く望まれているものである。
【０００３】
例えば、特許文献１（特開２００５−２５８６３８号公報）には、サーバと、複数の携帯型通信装置とを備えた安否情報確認システムであって、前記サーバは、前記複数の携帯型通信装置の位置情報を収集する手段と、災害発生時に、安否情報確認が必要な安否情報確認エリアを示す情報を記憶する手段と、収集した各携帯型通信装置の位置情報と前記記憶手段に記憶されている安否情報確認エリアを示す情報とに基づいて、前記複数の携帯型通信装置のうち、前記安否情報確認エリア内にいる携帯型通信装置を選択する手段と、前記選択手段が選択した携帯型情報通信装置へ、安否情報確認通知を送信する手段と、を備え、前記複数の携帯型通信装置は、前記安否情報確認通知を受信すると安否情報の入力を受け付け、前記サーバへ送信する手段を備える安否情報確認システムが開示されている。
【０００４】
また、特許文献２（特開２００５−１８３９５号公報）には、地震計と、前記地震計と第１の通信ネットワークで接続されて地震データを収集し、地震の震源位置や規模等の特性を分析、計算して地震情報を作成する地震データの収集・分析機構と、前記地震データの収集・分析機構と第２の通信ネットワークで接続され配信された前記地震情報に基づいて、対象となる地域での安否情報確認情報の収集が必要かどうかを判断する地震情報発信・安否情報収集機構と、前記地震情報発信機構と第３の通信ネットワークで接続されたユーザの通信端末とを備え、震源地の近傍に設置された前記地震計が地震を検知した際に、前記地震情報発信機構が前記安否情報確認情報の収集が必要と判断した場合には、地震の揺れが当該地域に到達する前に、当該地域周辺の前記ユーザの通信端末に地震に関する情報と安否情報確認指示を送信すると共に、前記ユーザの通信端末から前記地震情報発信機構に安否情報確認情報を返信することを特徴とする、災害時の安否情報確認システムが開示されている。
【特許文献１】特開２００５−２５８６３８号公報
【特許文献２】特開２００５−１８３９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来の安否情報確認システムは、地震発生後に、自身の安否を自分自身で携帯電話やパーソナルコンピュータ等により入力する必要があった。この場合、被災して入力できない状況におかれた人は、「救助してほしい」という情報を発信することができなかった。さらに、地震発生時には多数のユーザーから安否情報確認システムへアクセスが集中するとともに、他の通信量も増えることにより、通信環境が圧迫され、個々のユーザーが確実にアクセスすることが困難になると推測される。
【０００６】
特許文献１に記載の、所在位置に応じた安否情報確認システムでは、災害発生後に所在位置を取得し、取得した情報に基づき、災害発生場所周辺にいる者に対して安否情報確認を行うものである。しかしながら、特許文献１に開示されたシステムでは、災害発生後に通信システムが輻輳し、所在位置が取得できない可能性がある。このシステムでも、安否情報の発信は、ユーザー自身であるため、例えば、倒壊した建物の下敷きになっている者などは、安否情報を返信できない。
【０００７】
また、特許文献２開示の、緊急地震速報を用いた安否情報確認システムでは、地震が到着する前に、安否情報確認を返信する指示をするが、安否の返信は携帯電話等からユーザーが入力する必要がある。このシステムにおいても、被災し、安否情報を返信できない者に対しては、安否の確認という所期の目的を達成することができない。また、本システムはユーザーが安否情報を発信する際に、位置情報の取得や安否情報の返信ができない可能性がある。
【課題を解決するための手段】
【０００８】
この発明は、上記のような課題を解決するものであって、請求項１に係る発明は、自らの位置情報を無線で発信する携帯端末機器と、安否情報確認システム用ネットワークリソースと、前記携帯端末機器が交信する基地局と通信回線によって接続される安否情報確認メインシステムと、からなる安否情報確認システムにおいて、前記安否情報確認メインシステムは、緊急地震速報の入力を契機として、安否情報確認システム用ネットワークリソースの優先順位を引き上げることを特徴とする安否情報確認システムである。
【０００９】
また、請求項２に係る発明は、請求項１に記載の安否情報確認システムにおいて、安否情報確認システムと共に提供される他のサービス用のネットワークリソースを有しており、緊急地震速報の入力を契機として、前記他のサービス用のネットワークリソースを安否情報確認システム用ネットワークリソースに振り替えることを特徴とする。
【００１０】
また、請求項３に係る発明は、請求項１又は請求項２に記載の安否情報確認システムにおいて、緊急時用ネットワークリソースを有しており、緊急地震速報の入力を契機として、前記緊急時用ネットワークリソースを立ち上げることを特徴とする。
【００１１】
また、請求項４に係る発明は、請求項１乃至請求項３のいずれかに記載の安否情報確認システムにおいて、前記携帯端末機器から送信される位置情報を定期的に記録することを特徴とする。
【００１２】
また、請求項５に係る発明は、請求項４に記載の安否情報確認システムにおいて、定期的に記録される位置情報に基づいて前記携帯端末機器の所有者の安否を推定することを特徴とする。
【００１３】
また、請求項６に係る発明は、請求項１乃至請求項５に記載の安否情報確認システムにおいて、緊急地震速報の入力を契機として、前記携帯端末機器に対して、安否問い合わせメールを送信することを特徴とする。
【００１４】
また、請求項７に係る発明は、請求項６に記載の安否情報確認システムにおいて、安否問い合わせメールは、返信コードを入力するように促すことを特徴とする。
【００１５】
また、請求項８に係る発明は、請求項７に記載の安否情報確認システムにおいて、返信コードに応じて、登録者に対して安否情報を提供することを特徴とする。
【００１６】
また、請求項９に係る発明は、請求項１乃至請求項８のいずれかに記載の安否情報確認システムにおいて、前記携帯端末機器はＧＰＳ機能付き携帯電話であることを特徴とする。
【００１７】
また、請求項１０に係る発明は、請求項１乃至請求項８のいずれかに記載の安否情報確認システムにおいて、前記携帯端末機器はＰＨＳ電話機であることを特徴とする。
【発明の効果】
【００１８】
本発明の安否情報確認システムによれば、地震発生後に通信システムが輻輳し、安否情報の確認が行えない、といったトラブルを防止することができる。また、安否情報が不明なユーザーに対しては、ユーザーの位置情報を定期的に取得し、対処するような設定となっているために、倒壊した建物の下敷きになり、安否情報が送信できない者などの救出を迅速に行える、というメリットがある。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態を図面を参照しつつ説明する。図１は、本発明の実施形態に係る安否情報確認システムの全体構成の概略を示す図である。図１において、１００は安否情報確認システム、１０１は携帯電話機（又はＰＨＳ電話機）、１０５はＧＰＳ衛星、１０６は携帯電話（ＰＨＳ電話）基地局、１１０は通信回線網、１２０はサービス提供用システム、１２１は安否情報確認メインシステム、１２２はサービスＡ用リソース、１２３はサービスＢ用リソース、１２４は安否情報確認システム用リソース、１２５は緊急時用内部ネットワークリソース、１２６は安否情報確認システムデータベース、１２７は平常時用内部ネットワークリソース、１２８は緊急時用対外ネットワークリソース、１２９は平常時用対外ネットワークリソース、２００は緊急地震速報発信センター、２０１は地震計１〜ｎ、３００は救助機関をそれぞれ示している。
【００２０】
安否情報確認システム１００によるサービス提供は、自らの位置情報を無線で発信することが可能な携帯端末機器であるＧＰＳ機能付きの携帯電話機１０１（又はＰＨＳ電話機）を所有するユーザーを対象としている。携帯電話機１０１の場合は、ＧＰＳ衛星１０５からの信号により携帯電話機１０１が存在する位置を把握したり、また、ＰＨＳ電話機１０１の場合には、基地局１０６からの情報によってＰＨＳ電話機１０１が存在する位置を把握したり、することが可能に構成されるものである。また、このような携帯電話機１０１（又はＰＨＳ電話機）には通常メールの送受信を行う機能が搭載されており、本発明の安否情報確認システムではこのようなメール機能も利用するものである。
【００２１】
携帯電話機１０１（又はＰＨＳ電話機）は、基地局１０６と無線通信して、音声通話情報に加えて、メール情報、測位による位置情情報等を交信可能に構成されている。基地局１０６は公衆通信回線網やインターネット、ＷＡＮやＬＡＮなどからなる通信回線網１１０と接続されており、サービス提供用システム１２０と、平常時用対外ネットワークリソース１２９を通じて通信可能に構成される。
【００２２】
サービス提供用システム１２０は、安否情報確認システム１００を含めた種々のサービスを提供する全体のシステム構成を示している。本実施形態では、サービス提供用システム１２０は、安否情報確認システム１００の他に安否情報確認システムとは直接関係のないサービスＡ及びサービスＢを提供しているものとして説明する。サービスＡ用リソース１２２は、サービス提供用システム１２０のうちサービスＡを提供するための、またサービスＢ用リソース１２３は、サービス提供用システム１２０のうちサービスＢを提供するための、コンピュータリソースを示すものである。ここで、このようなコンピュータリソースとは、サーバやルータなどのネットワークに係るリソースを主として想定している。また、安否情報確認システム用リソース１２４は、安否情報確認システムに係るサービスを提供するための、コンピュータリソースを示すものであり、サーバやルータなどのネットワークに係るリソースを主として想定している。以上で述べたリソースは、平常時用内部ネットワークリソース１２７により相互に接続されている。
【００２３】
安否情報確認メインシステム１２１は、安否情報確認システム１００のネットワークに係るリソース以外のコンピュータリソースを想定している。このような安否情報確認メインシステム１２１には周知のメール機能などが包含されているものであるとして説明する。また、緊急時用内部ネットワークリソース１２５は地震発生時などの通信の内部的な輻輳対策のためのネットワークリソースであり、緊急時用対外ネットワークリソース１２８は地震発生時などの通信の輻輳対策と、平常時用対外ネットワークリソースにより接続されている通信経路のバックアップの役割を担うネットワークリソースである。安否情報確認システムデータベース１２６は、安否情報確認メインシステム１２１がユーザーの管理用として用いるデータベースである。なお、これまで説明してきたシステムやリソースは、いずれも例えば汎用的なコンピュータ及びその周辺機器により構成され、個々の構成要素または機能は、例えば、記憶手段に書き込まれたコンピュータプログラムを実行することにより実現されるものである。
【００２４】
緊急地震速報発信センター２００は、当該センターが管理する地震計１〜ｎ２０１などによって地震の発生を瞬時に検知し、この地震波が各地に到達する前に各機関に緊急地震速報を発信するものである。安否情報確認システム１００は、緊急地震速報発信センター２００からの緊急地震速報を受領できるように構成されている。また、安否情報確認システム１００は、救助機関３００に対して、救助依頼などの通信を行えるようにも構成されている。
【００２５】
本発明の安否情報確認システム１００においては、地震波が到達する前に鍵となるネットワークリソースを確保するとともに、ＧＰＳ機能付きの携帯電話機１０１（又はＰＨＳ電話機）などにより当該携帯電話機１０１を所有するユーザーの所在位置を事前に自動的に取得する。さらに、地震発生後は、ユーザーにメール等により安否情報の報告を求めるとともに、一定時間間隔（例えば、１〜５分間隔）でユーザーの所在位置を定期的に取得する。返信された安否情報をデータベース化し、安否の問い合わせなどに対応するとともに、安否情報により救助を求める者、および安否情報を返信せず、一定時間内に所在位置の動きがない者に関しては、救助機関３００に対して所在位置情報に基づき救助を依頼するものである。
【００２６】
次に、本発明の実施形態に係る安否情報確認システムの動作について説明する。図２は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。なお、このようなフローチャートは主として安否情報確認メインシステム１２１上で動作するものとして説明する。また、以下において説明するフローチャートは、本発明を実施するためのフローチャートの一例であり、唯一のものでない。以下のそれぞれのフローチャートは本発明の主旨を逸脱しない限り種々の改変することができるものである。
【００２７】
ステップＳ１００において、安否情報確認システム起動が起動されると、ステップＳ１０１で安否情報確認システムに新たに登録使用するユーザーが存在するかどうかを判定する。ステップＳ１０１での判定がＹＥＳの場合には、ステップＳ１０４へと進みユーザーの新規登録処理を行う。また、ステップＳ１０１での判定がＮＯの場合には、ステップＳ１０２へと進む。
【００２８】
ステップＳ１０２においては、緊急地震速報発信センター２００からの緊急地震速報を受領したかどうかが判定される。ステップＳ１０２での判定がＮＯである場合には、ステップＳ１０１に戻る。また、緊急地震速報発信センター２００から緊急地震速報を受領して、ステップＳ１０２での判定がＹＥＳとなったときには、次にステップＳ１０３へと進み、安否情報確認システム地震発生時処理を起動する。ステップＳ１０５では、安否情報確認システムの処理を終了する。
【００２９】
次に、上記ステップＳ１０４に関連して、安否情報確認メインシステム１２１がユーザーの管理用として用いる安否情報確認システムデータベース１２６について説明する。図３は、本発明の実施形態に係る安否情報確認システムが管理する安否情報確認システムデータベースのデータ構成を示す図である。また、図４は、本発明の実施形態に係る安否情報確認システムにおける新規ユーザー登録のためのユーザーインターフェイス画面の例を示す図である。
【００３０】
図３に示すように、安否情報確認システムデータベース１２６は、各ユーザーの「ＩＤ」、「ユーザーネーム」、「パスワード」、「メールアドレス」、「登録者１」、「登録者２」、・・、「登録者Ｎ」、「位置情報（Ｘn，Ｙn）」、「位置情報（Ｘn―1，Ｙn―1）」、「Ｒフラグ」、「Ｄフラグ」、「Ｉフラグ」、「Ｓフラグ」のデータを保有する構成となっている。ここで「ユーザー」とは、安否情報確認システム自体に直接的に登録している者をいい、「登録者」とはユーザーが自身の安否情報を発信しようとして安否情報確認システムに登録している者をいう。また、「位置情報（Ｘn，Ｙn）」はユーザーの最新の位置情報、「位置情報（Ｘn―1，Ｙn―1）」は最新の位置情報の一つ前の位置情報を示している。各フラグについては後で説明する。
【００３１】
安否情報確認システムに登録するためには、ユーザーは携帯電話機（又はＰＨＳ電話機）１０１を用いて、例えば、図４に示すようなインターフェイス画面を通してユーザーネーム、パスワード、自分のメールアドレス、安否メールを送信したい登録者のメールアドレスを入力する。このようにして安否情報確認システムに登録された情報は、図３の安否情報確認システムデータベース１２６の形式で保存される。
【００３２】
次に、上述の安否情報確認システム地震発生時処理について図５を参照しつつ説明する。図５は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。図５のフローチャートは、ステップＳ１０３のより詳細なルーチンである。図５において、ステップＳ２００での安否情報確認システムの地震発生時処理が開始されると、ステップＳ２０１においてネットワークリソースの選択処理が行われる。
【００３３】
このような選択処理とは具体的には、安否情報確認システムとは関係のないサービスＡ用リソース１２２、サービスＢ用リソース１２３などのリソースを安否情報確認システム向けに振り替えたり、或いは停止させたりする。また、その他の選択処理としては、安否情報確認システム用リソース１２４の優先順位の引き上げや、緊急時用内部ネットワークリソース１２５の立ち上げ、緊急時用対外ネットワークリソース１２８の立ち上げによる通信経路の確保、平常時用対外ネットワークリソース１２９の安否確認情報システム向け通信の優先順位引き上げ・不要通信の優先順位引き下げ、などがある。
これらのネットワークリソースの選択によって、安否情報確認システムは、地震発生後に通信システムが輻輳し、安否情報の確認が行えない、といったトラブルを防止することができる。
【００３４】
ステップＳ２０１に続き、ステップＳ２０２へと進むと、地震発生前処理のルーチンを実行する。ステップＳ２０３では地震発生時処理を終了する。
【００３５】
次に、上述の地震発生前処理について図６を参照しつつ説明する。図６は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。図６のフローチャートは、ステップＳ２０２のより詳細なルーチンである。
【００３６】
図６において、ステップＳ３００での安否情報確認システムの地震発生前処理が開始されると、ステップＳ３０１において地震発生前位置情報取得処理ルーチンが実行される。このルーチンは、地震発生前に各ユーザーの位置情報を把握するためのものである。このルーチンの具体的な処理の流れについては後述する。
【００３７】
次にステップＳ３０２において、実際に地震が発生したかどうかが判定される。このような判定には、緊急地震速報発信センター２００からの情報を用いることができる。Ｓ３０２におおける判定がＹＥＳであれば、ステップＳ３０３へと進み、地震発生後処理のルーチンが実行される。Ｓ３０２におおける判定がＮＯであれば、ステップＳ３０４へと進み、地震発生前処理を終了する。
【００３８】
次に、上述のステップＳ３０１の地震発生前位置情報取得処理ルーチン、及び、ステップ３０３の地震発生後処理ルーチンについて説明する。図７及び図８は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【００３９】
図７において、ステップＳ４００で地震発生前位置情報取得処理ルーチンが開始されると、ステップＳ４０１へと進み、ＩＤに１がセットされる。続いて、ＩＤが１のユーザーの位置情報を取得して、取得した位置情報を安否情報確認システムデータベース１２６に保存する。ステップＳ４０３においては、全ＩＤについて位置情報の取得が終了したかどうかが判定される。
【００４０】
ステップＳ４０３における判定がＮＯであれば、ステップＳ４０４へと進み、ＩＤが１インクリメントされる。ステップＳ４０３における判定がＹＥＳであれば、ステップＳ４０５へと進み、地震発生前位置情報取得処理のルーチンを終了する。
【００４１】
次に、地震発生後処理ルーチンについて図８により説明する。ステップＳ５００で地震発生後処理ルーチンが開始されると、ステップＳ５０１において安否確認メール送信処理のルーチンが実行される。次にステップＳ５０２へと進み、ステップＳ５０２において地震発生後位置情報取得処理のルーチンが実行される。次にステップＳ５０３へと進み、ステップＳ５０３において安否確認処理のルーチンが実行される。ステップＳ５０４へと進み、地震発生後処理ルーチンを終了する。
【００４２】
次に、図８の地震発生後処理ルーチンに登場する、安否確認メール送信処理、地震発生後位置情報取得処理、安否確認処理の各ルーチンについて説明する。
【００４３】
図９は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（安否確認メール送信処理）の一例を示す図である。図９において、ステップＳ６００において、安否確認メール送信処理が開始されると、ステップＳ６０１において、地震の発生地域などに応じて定型の安否問い合わせメールが作成される。図１０は、このような定型の安否問い合わせメールの一例を示すものである。この定型メールは図１０に示すように、ユーザーに自身の状況を０〜３までの数字（返信コード）で表すように促したり、自身のおかれている状況についてコメントを促したりするような文面となっている。
【００４４】
次に、ステップＳ６０１においてＩＤに１がセットされ、ステップＳ６０３に当該ＩＤに対して作成された定型メールが送信される。ステップＳ６０４では、全ＩＤについてメール送信が終了したかどうか判定される。判定結果がＮＯであるときはステップＳ６０５に進み、ＩＤに１が足された上で、ステップＳ６０３に戻る。また、ステップＳ６０４の判定結果がＹＥＳであるときは、ステップＳ６０６に進み、安否確認メール送信処理を終了する。
【００４５】
図１１は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（地震発生後位置情報取得処理）の一例を示す図である。ステップＳ７００で地震発生後位置情報取得処理のルーチンが開始されると、ステップＳ７０１においてＩＤに１がセットされる。続いてステップＳ７０２において、地震発生後の位置情報を各ユーザーの携帯電話機（又はＰＨＳ電話機）１０１から取得する。ここで、取得された位置情報はステップＳ７０３において、位置情報（Ｘ1，Ｙ1）として安否情報確認システムデータベース１２６に登録・保存される。ステップＳ７０４では、全てのＩＤについて位置情報取得の処理が終わっているかどうかが判定される。ステップＳ７０４での判定の結果がＮＯであればステップＳ７０５に進み、ＩＤを１インクリメントしてステップＳ７０２へと進む。ステップＳ７０４での判定の結果がＹＥＳであればステップＳ７０６に進み、地震発生後位置情報取得処理を終了する。
【００４６】
次に、安否確認処理のルーチンを説明する。図１２は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（安否確認処理）の一例を示す図である。ステップＳ８００で安否確認処理のルーチンが開始されると、まず、ステップＳ８０１において全てのＩＤの「Ｒフラグ」、「Ｄフラグ」、「Ｉフラグ」、「Ｓフラグ」の全フラグを０にセットする。ここで、これらのフラグは、０か１かの値をとり、あるＩＤのあるフラグが１の値をとったときには、安否情報確認システムが何かしらの対応を当該ＩＤのユーザーに対して行ったことを示すものである。それぞれのフラグの意味については後に説明する。
【００４７】
ステップＳ８０２に進むと、ＩＤに１がセットされる。続いて、ステップＳ８０３において当該ＩＤのユーザーから返信メールがあったかどうかが判定される。ステップＳ８０３における判定結果がＹＥＳである場合には、ステップＳ８０７の返信メール受領処理サブルーチンが実行される。ステップＳ８０３における判定結果がＮＯである場合には、ステップＳ８０４へと進む。ステップＳ８０４では、（Ｘ1，Ｙ1）と（Ｘ0，Ｙ0）とで差分が存在するかどうかが判定される。
【００４８】
ステップＳ８０４の判定の結果がＹＥＳであれば、ステップＳ８０８の差分検出処理サブルーチンが実行される。ステップＳ８０４の判定の結果がＮＯであれば、ステップＳ８０５へと進み、ステップＳ８０５で安否再確認処理のルーチンが実行される。ステップＳ８０６において全てのＩＤについて処理が終了したかどうかが判定され、判定がＮＯであるとステップＳ８０９に進み、ＩＤが１インクリメントされた上で、ステップＳ８０３へと進む。ステップＳ８０６の判定結果がＹＥＳであると、ステップＳ８１０へと進み、安否確認処理を終了する。
【００４９】
次に、ステップＳ８０７の返信メール受領処理サブルーチンについて説明する。図１１は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（返信メール受領処理サブルーチン）の一例を示す図である。
【００５０】
ステップＳ９００で返信メール受領処理サブルーチンが開始されると、ステップＳ９０１へと進み、現在扱っているＩＤのフラグを１にセットする。このＲフラグが１にセットされているＩＤのユーザーからは、安否情報確認システムから送信した安否問い合わせメールに対して返信があったことを示している。
【００５１】
安否問い合わせメール（図１０）では、ユーザーに返信コードによって自身の状態を表すように促している。以下のステップＳ９０２乃至ステップＳ９０５ではこの返信コードの判定が行われる。ステップＳ９０２においては、返信コードが０であるか否かが判定される。ステップＳ９０２での判定がＮＯであるとステップＳ９０３へと進み、ＹＥＳであるとステップＳ９０６へと進む。ステップＳ９０６においては、返信コード０に対応する安否情報メールを自動生成し、ユーザーのコメントがあれば当該メールにそれを付加する。ステップＳ９０７においては、ステップＳ９０６で作成されたメールが各登録者に送信される。
【００５２】
ステップＳ９０３においては、返信コードが１であるか否かが判定される。ステップＳ９０３での判定がＮＯであるとステップＳ９０４へと進み、ＹＥＳであるとステップＳ９０８へと進む。ステップＳ９０８においては、返信コード１に対応する安否情報メールを自動生成し、ユーザーのコメントがあれば当該メールにそれを付加する。ステップＳ９０９においては、ステップＳ９０８で作成されたメールが各登録者に送信される。
【００５３】
図１３は、返信コードが１であるメールの例を示している。このようにユーザーは、自身の被災した状況を、返信コードと、簡単なコメントによって記述して返信している。また、図１５は、返信コードが１であるメールを安否情報確認システムが受領した場合に自動生成するメールの例を示している。
【００５４】
ステップＳ９０４においては、返信コードが２であるか否かが判定される。ステップＳ９０４での判定がＮＯであるとステップＳ９０５へと進み、ＹＥＳであるとステップＳ９１０へと進む。ステップＳ９１０においては、返信コード２に対応する安否情報メールを自動生成し、ユーザーのコメントがあれば当該メールにそれを付加する。ステップＳ９１１においては、ステップＳ９１０で作成されたメールが各登録者に送信される。
【００５５】
ステップＳ９０５においては、返信コードが３であるか否かが判定される。ステップＳ９０５での判定がＮＯであるとステップＳ９１５へと進み、リターンする。ステップＳ９０５での判定がＹＥＳであるとステップＳ９１２へと進む。ステップＳ９１２においては、返信コード３に対応する安否情報メールを自動生成し、ユーザーのコメントがあれば当該メールにそれを付加する。ステップＳ９１３においては、ステップＳ９１２で作成されたメールが各登録者に送信される。返信コードの３は、要救助のコードであるので、ステップＳ９１４において、安否情報確認システムは救助機関３００に対して、ユーザーの位置情報などと共に救助の要請連絡を行う。
【００５６】
次に、ステップＳ８０８の差分検出処理サブルーチンについて説明する。図１６は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（差分検出処理サブルーチン）の一例を示す図である。
【００５７】
ステップＳ１０００で差分検出処理サブルーチンが開始されると、ステップ１００１でフラグＤに１がセットされる。このＤフラグが１にセットされているＩＤのユーザーは、少なくとも地震発生前と地震発生後での位置情報の差分が検出された者である。このようなユーザーは、移動することが可能であり、被災後も無事であるものと推測される。ステップＳ１００２においては、安否情報確認システムは、このような差分が検出された場合のメールを自動生成する。テップＳ１００３においては、ステップＳ１００２で作成されたユーザーの安否情報に係るメールが各登録者に送信され、ステップＳ１００４でリターンとなる。
【００５８】
図１７は、本発明の実施形態に係る安否情報確認システムにおいて登録者に対して送信する安否情報メールの一例を示すものである。図示するように、ユーザーの位置情報の差分に基づいて、ユーザーの無事が推定される旨の情報を各登録者に報知するような文面となっている。
【００５９】
次に、ステップＳ８０５の安否再確認処理について説明する。図１７は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（安否再確認処理）の一例を示す図である。ステップＳ１１００で安否再確認処理が開始されると、続いてステップＳ１１０１で安否問い合わせメール（図１０）に対する返信メールを受領しているかどうかを判定し、判定の結果がＹＥＳであればステップＳ１１０９へと進み、ステップＳ１１０９で返信メール受領処理サブルーチンを実行する。ステップＳ１１０１の判定の結果がＮＯであれば、次にステップ１１０２へと進む。ステップＳ１１０２では位置情報取得処理サブルーチンを実行する。この位置情報取得処理サブルーチンについては後に説明する。
【００６０】
続いて、ステップＳ１１０３において、最新の位置情報（Ｘn，Ｙn）とその一つ前の位置情報（Ｘn―1，Ｙn―1）との差分があったかどうかが判定される。ステップ１１０３における判定結果がＹＥＳである場合には、ステップＳ１１１０において、すでに説明した差分検出処理サブルーチンを実行する。ステップＳ１１０３における判定結果がＮＯである場合には、次にステップＳ１１０４へと進む。
【００６１】
ステップＳ１１０４において最新の位置情報（Ｘn，Ｙn）が被災地域なであるかどうかが判定される。被災地域情報は、例えば緊急地震速報発信センター２００により得るものとする。ステップＳ１１０４での判定結果がＮＯでるときは、ステップＳ１１１１においてフラグＩに１をたてる。フラグＩが１のユーザーは、ユーザーが被災地域外に存在し、安否情報確認システムが当面無視しても差し支えないユーザーを示している。ステップＳ１１０４での判定結果がＹＥＳでるときは、次にステップＳ１１０５に進む。ステップＳ１１０５においては、最新の位置情報（Ｘn，Ｙn）のｎの値が、所定の値mと等しくなったかどうかが判定される。例えば、m＝１０とする。そのm＝１０と等しいｎ＝１０とは、地震発生後に１０回目に取得した位置情報であることを示している。ステップＳ１１０５において、ｎがmに達していなければ、判定の結果はＮＯとなり、ステップＳ１１０８に進む。ステップＳ１１０５の判定の結果がＹＥＳである場合には、例えば地震発生後に１０回目にわたって取得した位置情報が全く不動であることを示しているので、ユーザーが何らかの形で被災している可能性が高いので、ステップＳ１１０６で位置情報等とともに救助機関３００に通報する。このように、すでに救助機関に通報したユーザーについては、ステップＳ１１０７にて、フラグＳに１をたてて、安否情報確認システムがなんらかの対処をしたことを記録しておく。
【００６２】
ステップＳ１１０８では、全てのＩＤについて、Ｒ＝１又はＤ＝１又はＩ＝１又はＳ＝１であるか否かが判定される。ステップＳ１１０８の判定の結果がＮＯである場合には、いまだになんの対処もしていないユーザーＩＤがあるということなので、再びステップＳ１１０１に戻る。ステップＳ１１０８の判定の結果がＹＥＳである場合には、全てのユーザーＩＤについて何らかの処理を施したことを意味するので、ステップＳ１１１２へと進み、安否再確認処理を終了する。
【００６３】
次に、ステップＳ１１０１の位置情報取得処理サブルーチンについて説明する。図１９は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（位置情報取得処理サブルーチン）の一例を示す図である。
【００６４】
ステップＳ１２００で位置情報取得処理サブルーチンが開始されると、ステップＳ１２０１においては所定の時間Ｔが経過しているかどうかが判定される。判定の結果がＮＯであれば、ステップＳ１２０７へと進みリターンする。ステップ１２０１の判定の結果がＹＥＳであるときは、ステップＳ１２０２へと進み、ＩＤに１をセットする。続いてステップＳ１２０３において、当該ＩＤについて、Ｒ＝０かつＤ＝０又はＩ＝０かつＳ＝０であるか否かが判定される。いずれかのフラグに１がたっているということは、安否情報確認システムが当該ユーザーＩＤに対して何らかの処理を対処したことを意味しており、そのような場合にはこの判定の結果はＮＯとなり、続いてステップＳ１２０６へと進む。ステップＳ１２０６では、ＩＤを１インクリメントして、再びステップＳ１２０３の判断ループを通る。
【００６５】
ステップＳ１２０３の判定がＹＥＳであるときは、ステップＳ１２０４へと進み、ユーザーの携帯電話機（又はＰＨＳ電話機）１０１から位置情報を取得する。ステップＳ１２０５に示すように、取得した最新の位置情報を順次大きい方のnで表す。続いて、ステップＳ１２０７へと進み、リターンする。
【００６６】
以上、 本発明の安否情報確認システムによれば、地震発生後に通信システムが輻輳し、安否情報の確認が行えない、といったトラブルを防止することができる。また、安否情報が不明なユーザーに対しては、ユーザーの位置情報を定期的に取得し、対処するような設定となっているために、倒壊した建物の下敷きになり、安否情報が送信できない者などの救出を迅速に行える、というメリットがある。
【図面の簡単な説明】
【００６７】
【図１】本発明の実施形態に係る安否情報確認システムの全体構成の概略を示す図である。
【図２】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図３】本発明の実施形態に係る安否情報確認システムが管理する安否情報確認システムデータベースのデータ構成を示す図である。
【図４】本発明の実施形態に係る安否情報確認システムにおける新規ユーザー登録のためのユーザーインターフェイス画面の例を示す図である。
【図５】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図６】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図７】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図８】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図９】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１０】本発明の実施形態に係る安否情報確認システムの定型の安否問い合わせメールの一例を示すものである。
【図１１】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１２】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１３】本発明の実施形態に係る安否情報確認システムの定型の安否問い合わせメールに対する返信例を示すものである。
【図１４】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１５】本発明の実施形態に係る安否情報確認システムにおいて登録者に対して送信する安否情報メールの一例を示すものである。
【図１６】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１７】本発明の実施形態に係る安否情報確認システムにおいて登録者に対して送信する安否情報メールの一例を示すものである。
【図１９】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１８】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【符号の説明】
【００６８】
１００・・・安否情報確認システム、１０１・・・携帯電話機（又はＰＨＳ電話機）、１０５・・・ＧＰＳ衛星、１０６・・・携帯電話（ＰＨＳ電話）基地局、１１０・・・通信回線網、１２０・・・サービス提供用システム、１２１・・・安否情報確認メインシステム、１２２・・・サービスＡ用リソース、１２３・・・サービスＢ用リソース、１２４・・・安否情報確認システム用リソース、１２５・・・緊急時用内部ネットワークリソース、１２６・・・安否情報確認システムデータベース、１２７・・・平常時用内部ネットワークリソース、１２８・・・緊急時用対外ネットワークリソース、１２９・・・平常時用対外ネットワークリソース、２００・・・緊急地震速報発信センター、２０１・・・地震計１〜ｎ、３００・・・救助機関
【技術分野】
【０００１】
本発明は、大規模災害の発生時において予め登録してある登録者に対して被災者の安否情報確認情報等を発信することが可能な安否情報確認システムに関する。
【背景技術】
【０００２】
大地震等の自然災害発生時においては、家族、友人、社員、職員、在校生等の安否に係る情報をできるだけ早く知りたいと考えるものであり、また被災者本人も自身が安全であることや負傷してしまったこと等を家族、知人、会社、学校等にできるだけ早く知らせたいと考えるものである。 そこで、携帯電話、ＰＨＳ（Personal Handy-phone System）などの移動体通信の回線、インターネットを利用し、災害発生時に地域住民各個人の安否情報等を防災ポータルサイトなどで提供する安否情報確認システムが提案されている。このようなシステムは地震等の大規模な災害が発生した場合には、安否情報確認等の固定電話が急増して回線混雑により輻輳状態となるなどの混乱が生じ、被災者の安否を確認することができなくなってしまうことや、テレビ放送、ラジオ放送からの情報では、被災者各個人の安否情報を容易には入手できないことなどから、実用化が強く望まれているものである。
【０００３】
例えば、特許文献１（特開２００５−２５８６３８号公報）には、サーバと、複数の携帯型通信装置とを備えた安否情報確認システムであって、前記サーバは、前記複数の携帯型通信装置の位置情報を収集する手段と、災害発生時に、安否情報確認が必要な安否情報確認エリアを示す情報を記憶する手段と、収集した各携帯型通信装置の位置情報と前記記憶手段に記憶されている安否情報確認エリアを示す情報とに基づいて、前記複数の携帯型通信装置のうち、前記安否情報確認エリア内にいる携帯型通信装置を選択する手段と、前記選択手段が選択した携帯型情報通信装置へ、安否情報確認通知を送信する手段と、を備え、前記複数の携帯型通信装置は、前記安否情報確認通知を受信すると安否情報の入力を受け付け、前記サーバへ送信する手段を備える安否情報確認システムが開示されている。
【０００４】
また、特許文献２（特開２００５−１８３９５号公報）には、地震計と、前記地震計と第１の通信ネットワークで接続されて地震データを収集し、地震の震源位置や規模等の特性を分析、計算して地震情報を作成する地震データの収集・分析機構と、前記地震データの収集・分析機構と第２の通信ネットワークで接続され配信された前記地震情報に基づいて、対象となる地域での安否情報確認情報の収集が必要かどうかを判断する地震情報発信・安否情報収集機構と、前記地震情報発信機構と第３の通信ネットワークで接続されたユーザの通信端末とを備え、震源地の近傍に設置された前記地震計が地震を検知した際に、前記地震情報発信機構が前記安否情報確認情報の収集が必要と判断した場合には、地震の揺れが当該地域に到達する前に、当該地域周辺の前記ユーザの通信端末に地震に関する情報と安否情報確認指示を送信すると共に、前記ユーザの通信端末から前記地震情報発信機構に安否情報確認情報を返信することを特徴とする、災害時の安否情報確認システムが開示されている。
【特許文献１】特開２００５−２５８６３８号公報
【特許文献２】特開２００５−１８３９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来の安否情報確認システムは、地震発生後に、自身の安否を自分自身で携帯電話やパーソナルコンピュータ等により入力する必要があった。この場合、被災して入力できない状況におかれた人は、「救助してほしい」という情報を発信することができなかった。さらに、地震発生時には多数のユーザーから安否情報確認システムへアクセスが集中するとともに、他の通信量も増えることにより、通信環境が圧迫され、個々のユーザーが確実にアクセスすることが困難になると推測される。
【０００６】
特許文献１に記載の、所在位置に応じた安否情報確認システムでは、災害発生後に所在位置を取得し、取得した情報に基づき、災害発生場所周辺にいる者に対して安否情報確認を行うものである。しかしながら、特許文献１に開示されたシステムでは、災害発生後に通信システムが輻輳し、所在位置が取得できない可能性がある。このシステムでも、安否情報の発信は、ユーザー自身であるため、例えば、倒壊した建物の下敷きになっている者などは、安否情報を返信できない。
【０００７】
また、特許文献２開示の、緊急地震速報を用いた安否情報確認システムでは、地震が到着する前に、安否情報確認を返信する指示をするが、安否の返信は携帯電話等からユーザーが入力する必要がある。このシステムにおいても、被災し、安否情報を返信できない者に対しては、安否の確認という所期の目的を達成することができない。また、本システムはユーザーが安否情報を発信する際に、位置情報の取得や安否情報の返信ができない可能性がある。
【課題を解決するための手段】
【０００８】
この発明は、上記のような課題を解決するものであって、請求項１に係る発明は、自らの位置情報を無線で発信する携帯端末機器と、安否情報確認システム用ネットワークリソースと、前記携帯端末機器が交信する基地局と通信回線によって接続される安否情報確認メインシステムと、からなる安否情報確認システムにおいて、前記安否情報確認メインシステムは、緊急地震速報の入力を契機として、安否情報確認システム用ネットワークリソースの優先順位を引き上げることを特徴とする安否情報確認システムである。
【０００９】
また、請求項２に係る発明は、請求項１に記載の安否情報確認システムにおいて、安否情報確認システムと共に提供される他のサービス用のネットワークリソースを有しており、緊急地震速報の入力を契機として、前記他のサービス用のネットワークリソースを安否情報確認システム用ネットワークリソースに振り替えることを特徴とする。
【００１０】
また、請求項３に係る発明は、請求項１又は請求項２に記載の安否情報確認システムにおいて、緊急時用ネットワークリソースを有しており、緊急地震速報の入力を契機として、前記緊急時用ネットワークリソースを立ち上げることを特徴とする。
【００１１】
また、請求項４に係る発明は、請求項１乃至請求項３のいずれかに記載の安否情報確認システムにおいて、前記携帯端末機器から送信される位置情報を定期的に記録することを特徴とする。
【００１２】
また、請求項５に係る発明は、請求項４に記載の安否情報確認システムにおいて、定期的に記録される位置情報に基づいて前記携帯端末機器の所有者の安否を推定することを特徴とする。
【００１３】
また、請求項６に係る発明は、請求項１乃至請求項５に記載の安否情報確認システムにおいて、緊急地震速報の入力を契機として、前記携帯端末機器に対して、安否問い合わせメールを送信することを特徴とする。
【００１４】
また、請求項７に係る発明は、請求項６に記載の安否情報確認システムにおいて、安否問い合わせメールは、返信コードを入力するように促すことを特徴とする。
【００１５】
また、請求項８に係る発明は、請求項７に記載の安否情報確認システムにおいて、返信コードに応じて、登録者に対して安否情報を提供することを特徴とする。
【００１６】
また、請求項９に係る発明は、請求項１乃至請求項８のいずれかに記載の安否情報確認システムにおいて、前記携帯端末機器はＧＰＳ機能付き携帯電話であることを特徴とする。
【００１７】
また、請求項１０に係る発明は、請求項１乃至請求項８のいずれかに記載の安否情報確認システムにおいて、前記携帯端末機器はＰＨＳ電話機であることを特徴とする。
【発明の効果】
【００１８】
本発明の安否情報確認システムによれば、地震発生後に通信システムが輻輳し、安否情報の確認が行えない、といったトラブルを防止することができる。また、安否情報が不明なユーザーに対しては、ユーザーの位置情報を定期的に取得し、対処するような設定となっているために、倒壊した建物の下敷きになり、安否情報が送信できない者などの救出を迅速に行える、というメリットがある。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態を図面を参照しつつ説明する。図１は、本発明の実施形態に係る安否情報確認システムの全体構成の概略を示す図である。図１において、１００は安否情報確認システム、１０１は携帯電話機（又はＰＨＳ電話機）、１０５はＧＰＳ衛星、１０６は携帯電話（ＰＨＳ電話）基地局、１１０は通信回線網、１２０はサービス提供用システム、１２１は安否情報確認メインシステム、１２２はサービスＡ用リソース、１２３はサービスＢ用リソース、１２４は安否情報確認システム用リソース、１２５は緊急時用内部ネットワークリソース、１２６は安否情報確認システムデータベース、１２７は平常時用内部ネットワークリソース、１２８は緊急時用対外ネットワークリソース、１２９は平常時用対外ネットワークリソース、２００は緊急地震速報発信センター、２０１は地震計１〜ｎ、３００は救助機関をそれぞれ示している。
【００２０】
安否情報確認システム１００によるサービス提供は、自らの位置情報を無線で発信することが可能な携帯端末機器であるＧＰＳ機能付きの携帯電話機１０１（又はＰＨＳ電話機）を所有するユーザーを対象としている。携帯電話機１０１の場合は、ＧＰＳ衛星１０５からの信号により携帯電話機１０１が存在する位置を把握したり、また、ＰＨＳ電話機１０１の場合には、基地局１０６からの情報によってＰＨＳ電話機１０１が存在する位置を把握したり、することが可能に構成されるものである。また、このような携帯電話機１０１（又はＰＨＳ電話機）には通常メールの送受信を行う機能が搭載されており、本発明の安否情報確認システムではこのようなメール機能も利用するものである。
【００２１】
携帯電話機１０１（又はＰＨＳ電話機）は、基地局１０６と無線通信して、音声通話情報に加えて、メール情報、測位による位置情情報等を交信可能に構成されている。基地局１０６は公衆通信回線網やインターネット、ＷＡＮやＬＡＮなどからなる通信回線網１１０と接続されており、サービス提供用システム１２０と、平常時用対外ネットワークリソース１２９を通じて通信可能に構成される。
【００２２】
サービス提供用システム１２０は、安否情報確認システム１００を含めた種々のサービスを提供する全体のシステム構成を示している。本実施形態では、サービス提供用システム１２０は、安否情報確認システム１００の他に安否情報確認システムとは直接関係のないサービスＡ及びサービスＢを提供しているものとして説明する。サービスＡ用リソース１２２は、サービス提供用システム１２０のうちサービスＡを提供するための、またサービスＢ用リソース１２３は、サービス提供用システム１２０のうちサービスＢを提供するための、コンピュータリソースを示すものである。ここで、このようなコンピュータリソースとは、サーバやルータなどのネットワークに係るリソースを主として想定している。また、安否情報確認システム用リソース１２４は、安否情報確認システムに係るサービスを提供するための、コンピュータリソースを示すものであり、サーバやルータなどのネットワークに係るリソースを主として想定している。以上で述べたリソースは、平常時用内部ネットワークリソース１２７により相互に接続されている。
【００２３】
安否情報確認メインシステム１２１は、安否情報確認システム１００のネットワークに係るリソース以外のコンピュータリソースを想定している。このような安否情報確認メインシステム１２１には周知のメール機能などが包含されているものであるとして説明する。また、緊急時用内部ネットワークリソース１２５は地震発生時などの通信の内部的な輻輳対策のためのネットワークリソースであり、緊急時用対外ネットワークリソース１２８は地震発生時などの通信の輻輳対策と、平常時用対外ネットワークリソースにより接続されている通信経路のバックアップの役割を担うネットワークリソースである。安否情報確認システムデータベース１２６は、安否情報確認メインシステム１２１がユーザーの管理用として用いるデータベースである。なお、これまで説明してきたシステムやリソースは、いずれも例えば汎用的なコンピュータ及びその周辺機器により構成され、個々の構成要素または機能は、例えば、記憶手段に書き込まれたコンピュータプログラムを実行することにより実現されるものである。
【００２４】
緊急地震速報発信センター２００は、当該センターが管理する地震計１〜ｎ２０１などによって地震の発生を瞬時に検知し、この地震波が各地に到達する前に各機関に緊急地震速報を発信するものである。安否情報確認システム１００は、緊急地震速報発信センター２００からの緊急地震速報を受領できるように構成されている。また、安否情報確認システム１００は、救助機関３００に対して、救助依頼などの通信を行えるようにも構成されている。
【００２５】
本発明の安否情報確認システム１００においては、地震波が到達する前に鍵となるネットワークリソースを確保するとともに、ＧＰＳ機能付きの携帯電話機１０１（又はＰＨＳ電話機）などにより当該携帯電話機１０１を所有するユーザーの所在位置を事前に自動的に取得する。さらに、地震発生後は、ユーザーにメール等により安否情報の報告を求めるとともに、一定時間間隔（例えば、１〜５分間隔）でユーザーの所在位置を定期的に取得する。返信された安否情報をデータベース化し、安否の問い合わせなどに対応するとともに、安否情報により救助を求める者、および安否情報を返信せず、一定時間内に所在位置の動きがない者に関しては、救助機関３００に対して所在位置情報に基づき救助を依頼するものである。
【００２６】
次に、本発明の実施形態に係る安否情報確認システムの動作について説明する。図２は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。なお、このようなフローチャートは主として安否情報確認メインシステム１２１上で動作するものとして説明する。また、以下において説明するフローチャートは、本発明を実施するためのフローチャートの一例であり、唯一のものでない。以下のそれぞれのフローチャートは本発明の主旨を逸脱しない限り種々の改変することができるものである。
【００２７】
ステップＳ１００において、安否情報確認システム起動が起動されると、ステップＳ１０１で安否情報確認システムに新たに登録使用するユーザーが存在するかどうかを判定する。ステップＳ１０１での判定がＹＥＳの場合には、ステップＳ１０４へと進みユーザーの新規登録処理を行う。また、ステップＳ１０１での判定がＮＯの場合には、ステップＳ１０２へと進む。
【００２８】
ステップＳ１０２においては、緊急地震速報発信センター２００からの緊急地震速報を受領したかどうかが判定される。ステップＳ１０２での判定がＮＯである場合には、ステップＳ１０１に戻る。また、緊急地震速報発信センター２００から緊急地震速報を受領して、ステップＳ１０２での判定がＹＥＳとなったときには、次にステップＳ１０３へと進み、安否情報確認システム地震発生時処理を起動する。ステップＳ１０５では、安否情報確認システムの処理を終了する。
【００２９】
次に、上記ステップＳ１０４に関連して、安否情報確認メインシステム１２１がユーザーの管理用として用いる安否情報確認システムデータベース１２６について説明する。図３は、本発明の実施形態に係る安否情報確認システムが管理する安否情報確認システムデータベースのデータ構成を示す図である。また、図４は、本発明の実施形態に係る安否情報確認システムにおける新規ユーザー登録のためのユーザーインターフェイス画面の例を示す図である。
【００３０】
図３に示すように、安否情報確認システムデータベース１２６は、各ユーザーの「ＩＤ」、「ユーザーネーム」、「パスワード」、「メールアドレス」、「登録者１」、「登録者２」、・・、「登録者Ｎ」、「位置情報（Ｘn，Ｙn）」、「位置情報（Ｘn―1，Ｙn―1）」、「Ｒフラグ」、「Ｄフラグ」、「Ｉフラグ」、「Ｓフラグ」のデータを保有する構成となっている。ここで「ユーザー」とは、安否情報確認システム自体に直接的に登録している者をいい、「登録者」とはユーザーが自身の安否情報を発信しようとして安否情報確認システムに登録している者をいう。また、「位置情報（Ｘn，Ｙn）」はユーザーの最新の位置情報、「位置情報（Ｘn―1，Ｙn―1）」は最新の位置情報の一つ前の位置情報を示している。各フラグについては後で説明する。
【００３１】
安否情報確認システムに登録するためには、ユーザーは携帯電話機（又はＰＨＳ電話機）１０１を用いて、例えば、図４に示すようなインターフェイス画面を通してユーザーネーム、パスワード、自分のメールアドレス、安否メールを送信したい登録者のメールアドレスを入力する。このようにして安否情報確認システムに登録された情報は、図３の安否情報確認システムデータベース１２６の形式で保存される。
【００３２】
次に、上述の安否情報確認システム地震発生時処理について図５を参照しつつ説明する。図５は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。図５のフローチャートは、ステップＳ１０３のより詳細なルーチンである。図５において、ステップＳ２００での安否情報確認システムの地震発生時処理が開始されると、ステップＳ２０１においてネットワークリソースの選択処理が行われる。
【００３３】
このような選択処理とは具体的には、安否情報確認システムとは関係のないサービスＡ用リソース１２２、サービスＢ用リソース１２３などのリソースを安否情報確認システム向けに振り替えたり、或いは停止させたりする。また、その他の選択処理としては、安否情報確認システム用リソース１２４の優先順位の引き上げや、緊急時用内部ネットワークリソース１２５の立ち上げ、緊急時用対外ネットワークリソース１２８の立ち上げによる通信経路の確保、平常時用対外ネットワークリソース１２９の安否確認情報システム向け通信の優先順位引き上げ・不要通信の優先順位引き下げ、などがある。
これらのネットワークリソースの選択によって、安否情報確認システムは、地震発生後に通信システムが輻輳し、安否情報の確認が行えない、といったトラブルを防止することができる。
【００３４】
ステップＳ２０１に続き、ステップＳ２０２へと進むと、地震発生前処理のルーチンを実行する。ステップＳ２０３では地震発生時処理を終了する。
【００３５】
次に、上述の地震発生前処理について図６を参照しつつ説明する。図６は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。図６のフローチャートは、ステップＳ２０２のより詳細なルーチンである。
【００３６】
図６において、ステップＳ３００での安否情報確認システムの地震発生前処理が開始されると、ステップＳ３０１において地震発生前位置情報取得処理ルーチンが実行される。このルーチンは、地震発生前に各ユーザーの位置情報を把握するためのものである。このルーチンの具体的な処理の流れについては後述する。
【００３７】
次にステップＳ３０２において、実際に地震が発生したかどうかが判定される。このような判定には、緊急地震速報発信センター２００からの情報を用いることができる。Ｓ３０２におおける判定がＹＥＳであれば、ステップＳ３０３へと進み、地震発生後処理のルーチンが実行される。Ｓ３０２におおける判定がＮＯであれば、ステップＳ３０４へと進み、地震発生前処理を終了する。
【００３８】
次に、上述のステップＳ３０１の地震発生前位置情報取得処理ルーチン、及び、ステップ３０３の地震発生後処理ルーチンについて説明する。図７及び図８は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【００３９】
図７において、ステップＳ４００で地震発生前位置情報取得処理ルーチンが開始されると、ステップＳ４０１へと進み、ＩＤに１がセットされる。続いて、ＩＤが１のユーザーの位置情報を取得して、取得した位置情報を安否情報確認システムデータベース１２６に保存する。ステップＳ４０３においては、全ＩＤについて位置情報の取得が終了したかどうかが判定される。
【００４０】
ステップＳ４０３における判定がＮＯであれば、ステップＳ４０４へと進み、ＩＤが１インクリメントされる。ステップＳ４０３における判定がＹＥＳであれば、ステップＳ４０５へと進み、地震発生前位置情報取得処理のルーチンを終了する。
【００４１】
次に、地震発生後処理ルーチンについて図８により説明する。ステップＳ５００で地震発生後処理ルーチンが開始されると、ステップＳ５０１において安否確認メール送信処理のルーチンが実行される。次にステップＳ５０２へと進み、ステップＳ５０２において地震発生後位置情報取得処理のルーチンが実行される。次にステップＳ５０３へと進み、ステップＳ５０３において安否確認処理のルーチンが実行される。ステップＳ５０４へと進み、地震発生後処理ルーチンを終了する。
【００４２】
次に、図８の地震発生後処理ルーチンに登場する、安否確認メール送信処理、地震発生後位置情報取得処理、安否確認処理の各ルーチンについて説明する。
【００４３】
図９は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（安否確認メール送信処理）の一例を示す図である。図９において、ステップＳ６００において、安否確認メール送信処理が開始されると、ステップＳ６０１において、地震の発生地域などに応じて定型の安否問い合わせメールが作成される。図１０は、このような定型の安否問い合わせメールの一例を示すものである。この定型メールは図１０に示すように、ユーザーに自身の状況を０〜３までの数字（返信コード）で表すように促したり、自身のおかれている状況についてコメントを促したりするような文面となっている。
【００４４】
次に、ステップＳ６０１においてＩＤに１がセットされ、ステップＳ６０３に当該ＩＤに対して作成された定型メールが送信される。ステップＳ６０４では、全ＩＤについてメール送信が終了したかどうか判定される。判定結果がＮＯであるときはステップＳ６０５に進み、ＩＤに１が足された上で、ステップＳ６０３に戻る。また、ステップＳ６０４の判定結果がＹＥＳであるときは、ステップＳ６０６に進み、安否確認メール送信処理を終了する。
【００４５】
図１１は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（地震発生後位置情報取得処理）の一例を示す図である。ステップＳ７００で地震発生後位置情報取得処理のルーチンが開始されると、ステップＳ７０１においてＩＤに１がセットされる。続いてステップＳ７０２において、地震発生後の位置情報を各ユーザーの携帯電話機（又はＰＨＳ電話機）１０１から取得する。ここで、取得された位置情報はステップＳ７０３において、位置情報（Ｘ1，Ｙ1）として安否情報確認システムデータベース１２６に登録・保存される。ステップＳ７０４では、全てのＩＤについて位置情報取得の処理が終わっているかどうかが判定される。ステップＳ７０４での判定の結果がＮＯであればステップＳ７０５に進み、ＩＤを１インクリメントしてステップＳ７０２へと進む。ステップＳ７０４での判定の結果がＹＥＳであればステップＳ７０６に進み、地震発生後位置情報取得処理を終了する。
【００４６】
次に、安否確認処理のルーチンを説明する。図１２は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（安否確認処理）の一例を示す図である。ステップＳ８００で安否確認処理のルーチンが開始されると、まず、ステップＳ８０１において全てのＩＤの「Ｒフラグ」、「Ｄフラグ」、「Ｉフラグ」、「Ｓフラグ」の全フラグを０にセットする。ここで、これらのフラグは、０か１かの値をとり、あるＩＤのあるフラグが１の値をとったときには、安否情報確認システムが何かしらの対応を当該ＩＤのユーザーに対して行ったことを示すものである。それぞれのフラグの意味については後に説明する。
【００４７】
ステップＳ８０２に進むと、ＩＤに１がセットされる。続いて、ステップＳ８０３において当該ＩＤのユーザーから返信メールがあったかどうかが判定される。ステップＳ８０３における判定結果がＹＥＳである場合には、ステップＳ８０７の返信メール受領処理サブルーチンが実行される。ステップＳ８０３における判定結果がＮＯである場合には、ステップＳ８０４へと進む。ステップＳ８０４では、（Ｘ1，Ｙ1）と（Ｘ0，Ｙ0）とで差分が存在するかどうかが判定される。
【００４８】
ステップＳ８０４の判定の結果がＹＥＳであれば、ステップＳ８０８の差分検出処理サブルーチンが実行される。ステップＳ８０４の判定の結果がＮＯであれば、ステップＳ８０５へと進み、ステップＳ８０５で安否再確認処理のルーチンが実行される。ステップＳ８０６において全てのＩＤについて処理が終了したかどうかが判定され、判定がＮＯであるとステップＳ８０９に進み、ＩＤが１インクリメントされた上で、ステップＳ８０３へと進む。ステップＳ８０６の判定結果がＹＥＳであると、ステップＳ８１０へと進み、安否確認処理を終了する。
【００４９】
次に、ステップＳ８０７の返信メール受領処理サブルーチンについて説明する。図１１は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（返信メール受領処理サブルーチン）の一例を示す図である。
【００５０】
ステップＳ９００で返信メール受領処理サブルーチンが開始されると、ステップＳ９０１へと進み、現在扱っているＩＤのフラグを１にセットする。このＲフラグが１にセットされているＩＤのユーザーからは、安否情報確認システムから送信した安否問い合わせメールに対して返信があったことを示している。
【００５１】
安否問い合わせメール（図１０）では、ユーザーに返信コードによって自身の状態を表すように促している。以下のステップＳ９０２乃至ステップＳ９０５ではこの返信コードの判定が行われる。ステップＳ９０２においては、返信コードが０であるか否かが判定される。ステップＳ９０２での判定がＮＯであるとステップＳ９０３へと進み、ＹＥＳであるとステップＳ９０６へと進む。ステップＳ９０６においては、返信コード０に対応する安否情報メールを自動生成し、ユーザーのコメントがあれば当該メールにそれを付加する。ステップＳ９０７においては、ステップＳ９０６で作成されたメールが各登録者に送信される。
【００５２】
ステップＳ９０３においては、返信コードが１であるか否かが判定される。ステップＳ９０３での判定がＮＯであるとステップＳ９０４へと進み、ＹＥＳであるとステップＳ９０８へと進む。ステップＳ９０８においては、返信コード１に対応する安否情報メールを自動生成し、ユーザーのコメントがあれば当該メールにそれを付加する。ステップＳ９０９においては、ステップＳ９０８で作成されたメールが各登録者に送信される。
【００５３】
図１３は、返信コードが１であるメールの例を示している。このようにユーザーは、自身の被災した状況を、返信コードと、簡単なコメントによって記述して返信している。また、図１５は、返信コードが１であるメールを安否情報確認システムが受領した場合に自動生成するメールの例を示している。
【００５４】
ステップＳ９０４においては、返信コードが２であるか否かが判定される。ステップＳ９０４での判定がＮＯであるとステップＳ９０５へと進み、ＹＥＳであるとステップＳ９１０へと進む。ステップＳ９１０においては、返信コード２に対応する安否情報メールを自動生成し、ユーザーのコメントがあれば当該メールにそれを付加する。ステップＳ９１１においては、ステップＳ９１０で作成されたメールが各登録者に送信される。
【００５５】
ステップＳ９０５においては、返信コードが３であるか否かが判定される。ステップＳ９０５での判定がＮＯであるとステップＳ９１５へと進み、リターンする。ステップＳ９０５での判定がＹＥＳであるとステップＳ９１２へと進む。ステップＳ９１２においては、返信コード３に対応する安否情報メールを自動生成し、ユーザーのコメントがあれば当該メールにそれを付加する。ステップＳ９１３においては、ステップＳ９１２で作成されたメールが各登録者に送信される。返信コードの３は、要救助のコードであるので、ステップＳ９１４において、安否情報確認システムは救助機関３００に対して、ユーザーの位置情報などと共に救助の要請連絡を行う。
【００５６】
次に、ステップＳ８０８の差分検出処理サブルーチンについて説明する。図１６は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（差分検出処理サブルーチン）の一例を示す図である。
【００５７】
ステップＳ１０００で差分検出処理サブルーチンが開始されると、ステップ１００１でフラグＤに１がセットされる。このＤフラグが１にセットされているＩＤのユーザーは、少なくとも地震発生前と地震発生後での位置情報の差分が検出された者である。このようなユーザーは、移動することが可能であり、被災後も無事であるものと推測される。ステップＳ１００２においては、安否情報確認システムは、このような差分が検出された場合のメールを自動生成する。テップＳ１００３においては、ステップＳ１００２で作成されたユーザーの安否情報に係るメールが各登録者に送信され、ステップＳ１００４でリターンとなる。
【００５８】
図１７は、本発明の実施形態に係る安否情報確認システムにおいて登録者に対して送信する安否情報メールの一例を示すものである。図示するように、ユーザーの位置情報の差分に基づいて、ユーザーの無事が推定される旨の情報を各登録者に報知するような文面となっている。
【００５９】
次に、ステップＳ８０５の安否再確認処理について説明する。図１７は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（安否再確認処理）の一例を示す図である。ステップＳ１１００で安否再確認処理が開始されると、続いてステップＳ１１０１で安否問い合わせメール（図１０）に対する返信メールを受領しているかどうかを判定し、判定の結果がＹＥＳであればステップＳ１１０９へと進み、ステップＳ１１０９で返信メール受領処理サブルーチンを実行する。ステップＳ１１０１の判定の結果がＮＯであれば、次にステップ１１０２へと進む。ステップＳ１１０２では位置情報取得処理サブルーチンを実行する。この位置情報取得処理サブルーチンについては後に説明する。
【００６０】
続いて、ステップＳ１１０３において、最新の位置情報（Ｘn，Ｙn）とその一つ前の位置情報（Ｘn―1，Ｙn―1）との差分があったかどうかが判定される。ステップ１１０３における判定結果がＹＥＳである場合には、ステップＳ１１１０において、すでに説明した差分検出処理サブルーチンを実行する。ステップＳ１１０３における判定結果がＮＯである場合には、次にステップＳ１１０４へと進む。
【００６１】
ステップＳ１１０４において最新の位置情報（Ｘn，Ｙn）が被災地域なであるかどうかが判定される。被災地域情報は、例えば緊急地震速報発信センター２００により得るものとする。ステップＳ１１０４での判定結果がＮＯでるときは、ステップＳ１１１１においてフラグＩに１をたてる。フラグＩが１のユーザーは、ユーザーが被災地域外に存在し、安否情報確認システムが当面無視しても差し支えないユーザーを示している。ステップＳ１１０４での判定結果がＹＥＳでるときは、次にステップＳ１１０５に進む。ステップＳ１１０５においては、最新の位置情報（Ｘn，Ｙn）のｎの値が、所定の値mと等しくなったかどうかが判定される。例えば、m＝１０とする。そのm＝１０と等しいｎ＝１０とは、地震発生後に１０回目に取得した位置情報であることを示している。ステップＳ１１０５において、ｎがmに達していなければ、判定の結果はＮＯとなり、ステップＳ１１０８に進む。ステップＳ１１０５の判定の結果がＹＥＳである場合には、例えば地震発生後に１０回目にわたって取得した位置情報が全く不動であることを示しているので、ユーザーが何らかの形で被災している可能性が高いので、ステップＳ１１０６で位置情報等とともに救助機関３００に通報する。このように、すでに救助機関に通報したユーザーについては、ステップＳ１１０７にて、フラグＳに１をたてて、安否情報確認システムがなんらかの対処をしたことを記録しておく。
【００６２】
ステップＳ１１０８では、全てのＩＤについて、Ｒ＝１又はＤ＝１又はＩ＝１又はＳ＝１であるか否かが判定される。ステップＳ１１０８の判定の結果がＮＯである場合には、いまだになんの対処もしていないユーザーＩＤがあるということなので、再びステップＳ１１０１に戻る。ステップＳ１１０８の判定の結果がＹＥＳである場合には、全てのユーザーＩＤについて何らかの処理を施したことを意味するので、ステップＳ１１１２へと進み、安否再確認処理を終了する。
【００６３】
次に、ステップＳ１１０１の位置情報取得処理サブルーチンについて説明する。図１９は、本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャート（位置情報取得処理サブルーチン）の一例を示す図である。
【００６４】
ステップＳ１２００で位置情報取得処理サブルーチンが開始されると、ステップＳ１２０１においては所定の時間Ｔが経過しているかどうかが判定される。判定の結果がＮＯであれば、ステップＳ１２０７へと進みリターンする。ステップ１２０１の判定の結果がＹＥＳであるときは、ステップＳ１２０２へと進み、ＩＤに１をセットする。続いてステップＳ１２０３において、当該ＩＤについて、Ｒ＝０かつＤ＝０又はＩ＝０かつＳ＝０であるか否かが判定される。いずれかのフラグに１がたっているということは、安否情報確認システムが当該ユーザーＩＤに対して何らかの処理を対処したことを意味しており、そのような場合にはこの判定の結果はＮＯとなり、続いてステップＳ１２０６へと進む。ステップＳ１２０６では、ＩＤを１インクリメントして、再びステップＳ１２０３の判断ループを通る。
【００６５】
ステップＳ１２０３の判定がＹＥＳであるときは、ステップＳ１２０４へと進み、ユーザーの携帯電話機（又はＰＨＳ電話機）１０１から位置情報を取得する。ステップＳ１２０５に示すように、取得した最新の位置情報を順次大きい方のnで表す。続いて、ステップＳ１２０７へと進み、リターンする。
【００６６】
以上、 本発明の安否情報確認システムによれば、地震発生後に通信システムが輻輳し、安否情報の確認が行えない、といったトラブルを防止することができる。また、安否情報が不明なユーザーに対しては、ユーザーの位置情報を定期的に取得し、対処するような設定となっているために、倒壊した建物の下敷きになり、安否情報が送信できない者などの救出を迅速に行える、というメリットがある。
【図面の簡単な説明】
【００６７】
【図１】本発明の実施形態に係る安否情報確認システムの全体構成の概略を示す図である。
【図２】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図３】本発明の実施形態に係る安否情報確認システムが管理する安否情報確認システムデータベースのデータ構成を示す図である。
【図４】本発明の実施形態に係る安否情報確認システムにおける新規ユーザー登録のためのユーザーインターフェイス画面の例を示す図である。
【図５】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図６】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図７】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図８】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図９】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１０】本発明の実施形態に係る安否情報確認システムの定型の安否問い合わせメールの一例を示すものである。
【図１１】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１２】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１３】本発明の実施形態に係る安否情報確認システムの定型の安否問い合わせメールに対する返信例を示すものである。
【図１４】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１５】本発明の実施形態に係る安否情報確認システムにおいて登録者に対して送信する安否情報メールの一例を示すものである。
【図１６】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１７】本発明の実施形態に係る安否情報確認システムにおいて登録者に対して送信する安否情報メールの一例を示すものである。
【図１９】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【図１８】本発明の実施形態に係る安否情報確認システムを動作させるためのフローチャートの一例を示す図である。
【符号の説明】
【００６８】
１００・・・安否情報確認システム、１０１・・・携帯電話機（又はＰＨＳ電話機）、１０５・・・ＧＰＳ衛星、１０６・・・携帯電話（ＰＨＳ電話）基地局、１１０・・・通信回線網、１２０・・・サービス提供用システム、１２１・・・安否情報確認メインシステム、１２２・・・サービスＡ用リソース、１２３・・・サービスＢ用リソース、１２４・・・安否情報確認システム用リソース、１２５・・・緊急時用内部ネットワークリソース、１２６・・・安否情報確認システムデータベース、１２７・・・平常時用内部ネットワークリソース、１２８・・・緊急時用対外ネットワークリソース、１２９・・・平常時用対外ネットワークリソース、２００・・・緊急地震速報発信センター、２０１・・・地震計１〜ｎ、３００・・・救助機関
【特許請求の範囲】
【請求項１】
自らの位置情報を無線で発信する携帯端末機器と、安否情報確認システム用ネットワークリソースと、前記携帯端末機器が交信する基地局と通信回線によって接続される安否情報確認メインシステムと、からなる安否情報確認システムにおいて、
前記安否情報確認メインシステムは、緊急地震速報の入力を契機として、安否情報確認システム用ネットワークリソースの優先順位を引き上げることを特徴とする安否情報確認システム。
【請求項２】
安否情報確認システムと共に提供される他のサービス用のネットワークリソースを有しており、緊急地震速報の入力を契機として、前記他のサービス用のネットワークリソースを安否情報確認システム用ネットワークリソースに振り替えることを特徴とする請求項１に記載の安否情報確認システム。
【請求項３】
緊急時用ネットワークリソースを有しており、緊急地震速報の入力を契機として、前記緊急時用ネットワークリソースを立ち上げることを特徴とする請求項１又は請求項２に記載の安否情報確認システム。
【請求項４】
前記携帯端末機器から送信される位置情報を定期的に記録することを特徴とする請求項１乃至請求項３のいずれかに記載の安否情報確認システム。
【請求項５】
定期的に記録される位置情報に基づいて前記携帯端末機器の所有者の安否を推定することを特徴とする請求項４に記載の安否情報確認システム。
【請求項６】
緊急地震速報の入力を契機として、前記携帯端末機器に対して、安否問い合わせメールを送信することを特徴とする請求項１乃至請求項５に記載の安否情報確認システム。
【請求項７】
安否問い合わせメールは、返信コードを入力するように促すことを特徴とする請求項６に記載の安否情報確認システム。
【請求項８】
返信コードに応じて、登録者に対して安否情報を提供することを特徴とする請求項７に記載の安否情報確認システム。
【請求項９】
前記携帯端末機器はＧＰＳ機能付き携帯電話であることを特徴とする請求項１乃至請求項８のいずれかに記載の安否情報確認システム。
【請求項１０】
前記携帯端末機器はＰＨＳ電話機であることを特徴とする請求項１乃至請求項８のいずれかに記載の安否情報確認システム。
【請求項１】
自らの位置情報を無線で発信する携帯端末機器と、安否情報確認システム用ネットワークリソースと、前記携帯端末機器が交信する基地局と通信回線によって接続される安否情報確認メインシステムと、からなる安否情報確認システムにおいて、
前記安否情報確認メインシステムは、緊急地震速報の入力を契機として、安否情報確認システム用ネットワークリソースの優先順位を引き上げることを特徴とする安否情報確認システム。
【請求項２】
安否情報確認システムと共に提供される他のサービス用のネットワークリソースを有しており、緊急地震速報の入力を契機として、前記他のサービス用のネットワークリソースを安否情報確認システム用ネットワークリソースに振り替えることを特徴とする請求項１に記載の安否情報確認システム。
【請求項３】
緊急時用ネットワークリソースを有しており、緊急地震速報の入力を契機として、前記緊急時用ネットワークリソースを立ち上げることを特徴とする請求項１又は請求項２に記載の安否情報確認システム。
【請求項４】
前記携帯端末機器から送信される位置情報を定期的に記録することを特徴とする請求項１乃至請求項３のいずれかに記載の安否情報確認システム。
【請求項５】
定期的に記録される位置情報に基づいて前記携帯端末機器の所有者の安否を推定することを特徴とする請求項４に記載の安否情報確認システム。
【請求項６】
緊急地震速報の入力を契機として、前記携帯端末機器に対して、安否問い合わせメールを送信することを特徴とする請求項１乃至請求項５に記載の安否情報確認システム。
【請求項７】
安否問い合わせメールは、返信コードを入力するように促すことを特徴とする請求項６に記載の安否情報確認システム。
【請求項８】
返信コードに応じて、登録者に対して安否情報を提供することを特徴とする請求項７に記載の安否情報確認システム。
【請求項９】
前記携帯端末機器はＧＰＳ機能付き携帯電話であることを特徴とする請求項１乃至請求項８のいずれかに記載の安否情報確認システム。
【請求項１０】
前記携帯端末機器はＰＨＳ電話機であることを特徴とする請求項１乃至請求項８のいずれかに記載の安否情報確認システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２００８−２１１４１９（Ｐ２００８−２１１４１９Ａ）
【公開日】平成２０年９月１１日（２００８．９．１１）
【国際特許分類】
【出願番号】特願２００７−４４９９２（Ｐ２００７−４４９９２）
【出願日】平成１９年２月２６日（２００７．２．２６）
【出願人】（０００００２２９９）清水建設株式会社 (2,433)
【Ｆターム（参考）】
【公開日】平成２０年９月１１日（２００８．９．１１）
【国際特許分類】
【出願日】平成１９年２月２６日（２００７．２．２６）
【出願人】（０００００２２９９）清水建設株式会社 (2,433)
【Ｆターム（参考）】
[ Back to top ]