特許 6598904 災害情報処理装置および災害情報通知方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6598904

(24)【登録日】2019年10月11日

(45)【発行日】2019年10月30日

(54)【発明の名称】災害情報処理装置および災害情報通知方法

(51)【国際特許分類】

   B66B 5/00 20060101AFI20191021BHJP

【ＦＩ】

   B66B5/00 G

【請求項の数】6

【全頁数】22

(21)【出願番号】特願2018-39010(P2018-39010)

(22)【出願日】2018年3月5日

(65)【公開番号】特開2019-151468(P2019-151468A)

(43)【公開日】2019年9月12日

【審査請求日】2018年3月5日

(73)【特許権者】

【識別番号】390025265

【氏名又は名称】東芝エレベータ株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】中村 正人

【審査官】 須山 直紀

(56)【参考文献】

【文献】 特開２００７−２５４０３９（ＪＰ，Ａ）

【文献】 特開２００５−０７１０９２（ＪＰ，Ａ）

【文献】 特開２０１２−２１２１９９（ＪＰ，Ａ）

【文献】 特開２０１１−２０１６２１（ＪＰ，Ａ）

【文献】 特開２０１４−１７２７１９（ＪＰ，Ａ）

【文献】 特開平１１−１７８８００（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｂ６６Ｂ ５／００

(57)【特許請求の範囲】

【請求項1】

異常を感知した建物のエレベータの稼動状況を示す情報を受け付ける第１の受付部と、
端末で入力されたユーザの被災情報を受け付ける第２の受付部と、
複数の病院の病院情報と、ユーザの持病又はかかりつけの病院を示すユーザ情報とを記憶する記憶部と、
前記第１の受付部が受け付けた病院のエレベータの前記稼動状況と前記第２の受付部が受け付けた前記被災情報と前記複数の病院の病院情報と前記ユーザ情報とから、前記ユーザ情報に示されるユーザを受け入れ可能な病院の候補を算出する処理部と、
前記処理部の算出によって得た、ユーザを受け入れ可能な病院の候補を前記ユーザが確認可能な端末に出力する出力部と、
を備える災害情報処理装置。

【請求項2】

異常を感知した建物のエレベータの稼動状況を示す情報を受け付ける第１の受付部と、
複数の病院の病院情報と、ユーザの持病又はかかりつけの病院を示すユーザ情報とを記憶する記憶部と、
前記第１の受付部が受け付けた病院のエレベータの前記稼動状況を示す情報を送信した各病院と、災害を受けていない病院と、前記複数の病院の病院情報と、前記ユーザ情報とから、前記ユーザ情報に示されるユーザを受け入れ可能な病院の候補を算出する処理部と、
前記処理部の算出によって得た、ユーザを受け入れ可能な病院の候補を前記ユーザが確認可能な端末に出力する出力部と、
を備える災害情報処理装置。

【請求項3】

前記出力部は、ユーザの端末に対し、該ユーザの被災情報を確認する問い合わせを行い、
前記処理部は、前記問い合わせに対して前記ユーザから応答された被災情報に基づいて、前記ユーザを受け入れ可能な病院の候補を算出する、
請求項１に記載の災害情報処理装置。

【請求項4】

設定時間が経過した場合に、前記異常を感知した前記病院からエレベータの稼動状況を示す情報としてエレベータの稼動頻度を示す情報を取得する取得部をさらに備え、
前記処理部は、前記取得部が取得した各時点のエレベータの前記稼動頻度を示す情報に基づき、ユーザを受け入れ可能な病院の候補を更新し、
前記出力部は、前記処理部の更新結果を、前記ユーザが確認可能な端末に再出力する、
請求項１または３に記載の災害情報処理装置。

【請求項5】

エレベータの異常を遠隔から監視するエレベータ監視装置からユーザに利用可能な病院を通知する災害情報通知方法であって、
エレベータで異常を感知するステップと、
エレベータの稼動状況を示す情報を収集するステップと、
前記エレベータの記憶部が記憶するユーザのかかりつけの病院を示すユーザ情報と、前記収集により得た前記稼動状況を示す情報とを前記エレベータ監視装置に送信するステップと、
端末で入力されたユーザの被災情報を前記エレベータ監視装置に送信するステップと、
前記エレベータ監視装置において、受信により得られた病院の前記稼動状況を示す情報と、前記被災情報と、前記エレベータ監視装置の記憶部に記憶された病院情報とから、前記ユーザ情報に示されるユーザを受け入れ可能な病院の候補を算出するステップと、
前記算出によって得た、ユーザを受け入れ可能な病院の候補を前記ユーザが確認可能な端末に出力するステップと、
を含む災害情報通知方法。

【請求項6】

エレベータの異常を遠隔から監視するエレベータ監視装置からユーザに利用可能な病院を通知する災害情報通知方法であって、
エレベータで異常を感知するステップと、
エレベータの稼動状況を示す情報を収集するステップと、
前記エレベータの記憶部が記憶するユーザのかかりつけの病院を示すユーザ情報と、前記収集により得た前記稼動状況を示す情報とを前記エレベータ監視装置に送信するステップと、
前記エレベータ監視装置において、受信により得られた病院の前記稼動状況を示す情報を送信した各病院と、災害を受けていない病院と、前記エレベータ監視装置の記憶部に記憶された病院情報とから、前記ユーザ情報に示されるユーザを受け入れ可能な病院の候補を算出するステップと、
前記算出によって得た、ユーザを受け入れ可能な病院の候補を前記ユーザが確認可能な端末に出力するステップと、
を含む災害情報通知方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、災害情報処理装置および災害情報通知方法に関する。

【背景技術】

【0002】

従来、広域災害が発生すると、災害の発生状況により建物内のエレベータが停止したり、場合によっては、そのエレベータが一時的に利用できなくなったりすることがある。エレベータが停止すると、その建物を利用する利用者の移動や運搬の際に不便が生じるため、早期復旧が望まれる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１４−６９９６８号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、災害発生地域において病院のエレベータが停止したままになると寝台や治療器具などの移動ができなくなり、診察や治療など、診療行為そのものができなくなる可能性が高くなる。その場合、周辺の同じ診療科目を設けた病院を探すことになるが、災害発生時においては病院について得られる情報が少ないため、特に持病のある人や負傷者などにとって、病院を探し回るという行為が大きな負担になるという問題がある。

【0005】

本発明の一実施形態は、上記に鑑みてなされたものであって、災害などにより受け入れ困難な病院がある場合に他の受け入れ可能な病院をユーザに通知する災害情報処理装置および災害情報通知方法を提供することを目的とする。

【課題を解決するための手段】

【0006】

実施形態の災害情報処理装置は、第１の受付部と、第２の受付部と、記憶部と、処理部と、出力部とを備える。前記第１の受付部は、異常を感知した建物のエレベータの稼動状況を示す情報を受け付ける。前記第２の受付部は、端末で入力されたユーザの被災情報を受け付ける。前記記憶部は、複数の病院の病院情報と、ユーザの持病又はかかりつけの病院を示すユーザ情報とを記憶する。前記処理部は、前記第１の受付部が受け付けた病院のエレベータの前記稼動状況と前記第２の受付部が受け付けた前記被災情報と前記複数の病院の病院情報と前記ユーザ情報とから、前記ユーザ情報に示されるユーザを受け入れ可能な病院の候補を算出する。前記出力部は、前記処理部の算出によって得た、ユーザを受け入れ可能な病院の候補を前記ユーザが確認可能な端末に出力する。

【図面の簡単な説明】

【0007】

【図1】図１は、実施形態にかかる災害情報通知方法の一例を示す全体システム図である。

【図2】図２は、実施形態にかかる制御設備の管制運転制御の処理の一例を示す図である。

【図3】図３は、実施形態にかかる病院情報についての設定テーブルの一例を示す図である。

【図4】図４は、実施形態にかかる稼動状況情報についての設定テーブルの一例を示す図である。

【図5】図５は、実施形態にかかるユーザ情報についての設定テーブルの一例を示す図である。

【図6】図６は、実施形態にかかるエレベータ監視装置が行う災害通知処理の手順の一例を示すフローチャートである。

【図7】図７は、実施形態にかかる端末に出力される通知画面の構成の一例を示す図である。

【図8】図８は、変形例１にかかる災害通知処理の一例を示すフローチャートである。

【図9】図９は、変形例１にかかる第２の受付部が行う受付処理の一例を示す図である。

【図10】図１０は、変形例１にかかる入力フォーム情報の一例を示す図である。

【図11】図１１は、変形例４にかかるエレベータ監視装置の機能ブロックの構成の一例を示す図である。

【図12】図１２は、変形例４にかかるログの一例を示す図である。

【図13】図１３は、変形例４にかかるエレベータ監視装置が最新の病院候補を配信する手順の一例を示すフローチャートである。

【図14】図１４は、変形例４にかかる通知画面の表示内容の更新例を示す図である。

【発明を実施するための形態】

【0008】

以下、図面を参照して実施形態にかかる災害情報処理装置および災害情報通知方法について説明する。なお、実施形態にかかる災害情報処理装置については、以下においてエレベータ監視装置へ適用した場合の一例を示す。

【0009】

（実施形態）
図１は、実施形態にかかる災害情報通知方法の一例を示す全体システム図である。図１に示す災害情報通知システム１は、各建物Ａ１、Ａ２、・・・が備えるエレベータＥＶ１、ＥＶ２、・・・の設備と、各建物Ａ１、Ａ２、・・・のエレベータＥＶ１、ＥＶ２、・・・をサービスセンタなどで遠隔から監視するエレベータ監視装置１０と、エレベータ監視装置１０が各建物Ａ１、Ａ２、・・・のエレベータＥＶ１、ＥＶ２、・・・から得た災害情報の出力先の端末１１とを含む構成を有している。

【0010】

各建物Ａ１、Ａ２、・・・は、ユーザが利用する病院やマンションなどである。各建物Ａ１、Ａ２、・・・には、エレベータＥＶ１、ＥＶ２、・・・が備えられ、建物内の制御設備１２の制御盤１２−１等により運転が制御される。また、各建物Ａ１、Ａ２、・・・には、地震や火災などの異常を感知して異常信号を制御設備１２に出力する異常感知センサ２１が設置されている。そして、本実施形態では、エレベータＥＶ１、ＥＶ２、・・・に制御設備１２から読み取りが可能な記憶部２２を設置する。

【0011】

記憶部２２は、例えば、制御設備１２からエレベータＥＶ１、ＥＶ２、・・・に延在する制御ケーブルに通信ケーブルを束ね、その通信ケーブルの端部に接続されたエレベータＥＶ１、ＥＶ２、・・・の操作盤などのメモリである。この他、記憶部２２をエレベータＥＶ１、ＥＶ２、・・・に無線タグとして設け、移動するエレベータＥＶ１、ＥＶ２、・・・やエレベータＥＶ１、ＥＶ２、・・・の通過経路に設置したリーダなどに制御設備１２からコマンドを送って情報を取得するようにしてもよい。

【0012】

記憶部２２には、その建物を利用するユーザのユーザ情報Ｄ１と、その建物が病院である場合には、更に、その建物の病院名や、病院の診療情報などを含む病院情報Ｄ３を記憶させている。ユーザ情報Ｄ１には、ユーザのかかりつけの病院名と診療科目とを判別することができる情報（診療情報）とが含まれる。例えば、病院のエレベータの記憶部２２には、その病院の利用者の診療情報を含める。また、マンションのエレベータの記憶部２２には、その住人の診療情報を含める。診療科目は病名や治療内容などであってもよく、以下において、特に診療科目に限定しない場合に診療科目を上位概念で「診療情報」と呼ぶ場合がある。

【0013】

エレベータ監視装置１０は、各建物Ａ１、Ａ２、・・・などから得られた情報に基づきデータベース作成システム１０−１によりデータベースを作成し、病院の受け入れ可否や最適な病院を算出する。エレベータ監視装置１０は、各建物Ａ１、Ａ２、・・・内の制御設備１２がエレベータ監視装置１０と通信するための遠隔監視端末装置１２−２との間で、ネットワークＮ１を介してデータを送受信する。エレベータ監視装置１０と端末１１とはネットワークＮ２を介してデータを送受信する。ネットワークＮ１としては、専用線が考えられる。ネットワークＮ２は、携帯電話網やインターネットなどが考えられる。データベース作成システム１０−１の詳細については後述する。

【0014】

端末１１は、例えば、ユーザ端末や避難所に設けた表示ディスプレイなどである。ユーザ端末には、デスクトップ型のＰＣ（Personal Computer）や、スマートフォンや、タブレット端末、携帯電話機や、ファックスや、プリンタなどが挙げられる。

【0015】

（災害情報通知方法）
以上のような災害情報通知システム１では、広域災害が発生すると、先ず、災害が生じた地域の建物内で異常感知センサ２１が反応し、その建物内の制御設備１２で異常感知センサ２１による異常信号を検出する（Ｓ１）。

【0016】

制御設備１２は、異常信号を検出すると建物内の各エレベータＥＶ１、ＥＶ２、・・・の動作を、例えば後述するような管制運転を行ってチェックし、各エレベータＥＶ１、ＥＶ２、・・・について稼動可能や稼動不可などの稼動状況（稼動状況情報Ｄ２）を収集する（Ｓ２）。

【0017】

続いて、制御設備１２は、記憶部２２からユーザ情報Ｄ１と、その建物が病院である場合は病院情報Ｄ３とを取得し、当該ユーザ情報Ｄ１と病院情報Ｄ３と収集した稼動状況情報Ｄ２とを、エレベータ監視装置１０にネットワークＮ１を介して送信する（Ｓ３）。

【0018】

エレベータ監視装置１０は、異常が感知され１つ又は複数の建物から送信された各情報を受信してデータベースを作成し、その中に病院情報Ｄ３が含まれていた場合に、データベースから病院の候補を算出するための処理を行う（Ｓ４）。データベースは、複数の病院の病院情報と、ユーザの持病又はかかりつけの病院を示すユーザ情報とを記憶する「災害情報処理装置が備える記憶部」の一例である。異常が感知され１つ又は複数の病院から送信された病院情報Ｄ３とユーザ情報Ｄ１とを各種のテーブルに設定して記憶する。なお、病院情報Ｄ３やユーザ情報Ｄ１は、エレベータ監視装置１０に予め記憶させておいてもよいし、外部データベースなどから取得してもよい。病院情報Ｄ３を外部データベースから取得する場合の一例については、変形例３として後に示す。

【0019】

エレベータ監視装置１０は、例えば、受信した稼動状況情報Ｄ２から、病院のエレベータの稼動可否をチェックする。そして、エレベータが稼動不可であった場合に、受け入れが困難な状況と判定し、その病院のユーザ情報（ユーザ情報Ｄ１に対応）に含まれている各ユーザを対象に、各ユーザのそれぞれの診療科目の受け入れが可能な他の病院の候補を他の病院情報（病院情報Ｄ３に対応）から抽出する。

【0020】

また、総合病院などのように診療科目に応じて診察室や検査室などに昇降するためのエレベータが異なる場合には、稼動状況情報Ｄ２から、診療科目ごとにエレベータの稼動可否をチェックする。そして、一部の診療科目の受け入れが困難な状況にあれば、その病院のユーザ情報Ｄ１において当該一部の診療科目の受診が設定されているユーザを対象に、各ユーザのそれぞれの診療科目の受け入れが可能な他の病院の候補を病院情報から抽出する。この場合、各エレベータＥＶ１、ＥＶ２、・・・に記憶部２２を設け、各記憶部２２に対し、それぞれのエレベータＥＶ１、ＥＶ２、・・・に対応する診療科目のユーザ情報を記憶させることができ、ユーザをエレベータＥＶ１、ＥＶ２、・・・毎に管理することができる。

【0021】

続いて、エレベータ監視装置１０は、算出した各ユーザのそれぞれの病院の候補を、各ユーザが確認可能な端末１１に出力する（Ｓ５）。

【0022】

続いて、災害情報通知システム１の各装置の具体的な構成や処理フローについて説明する。なお、各建物Ａ１、Ａ２、・・・については、各建物Ａ１、Ａ２、・・・の既存の設備において、記憶部２２の設置や、稼動状況情報Ｄ２を収集する管制運転などを行うことにより実施することができる。従って、各建物Ａ１、Ａ２、・・・については、記憶部２２のユーザ情報Ｄ１のデータ構成や、制御設備１２による稼動状況情報Ｄ２の収集処理について説明する。また、ユーザの端末１１については、情報の出力を行うことができる端末であり、その構成は一般的に知られている。従って、ここでは、端末１１の構成について説明は省略する。

【0023】

（制御設備１２による収集処理）
先ず、各建物Ａ１、Ａ２、・・・の制御設備１２が各々の建物内のエレベータＥＶ１、ＥＶ２、・・・の稼動状況情報Ｄ２を収集する処理について説明する。ここでは、異常感知センサ２１が地震に反応した場合の制御設備１２の管制運転制御の処理を例に説明する。

【0024】

図２は、制御設備１２の管制運転制御の処理の一例を示す図である。図２に示すように、制御設備１２は、異常感知センサ２１の出力をモニタし、その出力が「Ｐ波」または「特低レベルの加速度値」以上かを判定する（Ｓ２１）。「Ｐ波」または「特低レベルの加速度値」以上でない場合（Ｓ２１：Ｎｏ判定）、各エレベータＥＶ１、ＥＶ２、・・・を平常運転のままにし（Ｓ２２）、各エレベータＥＶ１、ＥＶ２、・・・について、稼動状況情報Ｄ２に「稼動可能」を示す情報を設定する（Ｓ２３）。

【0025】

一方、「Ｐ波」または「特低レベルの加速度値」以上であった場合は（Ｓ２１：Ｙｅｓ判定）、「低レベルの加速度値」以上を示すかを判定する（Ｓ２４）。ここで、「低レベルの加速度値」以上でない場合は（Ｓ２４：Ｎｏ判定）、地震規模が「特低レベルの加速度値」の範囲であることを示す。続けて、各エレベータＥＶ１、ＥＶ２、・・・が走行中であるかを判定し（Ｓ２５）、エレベータが走行中でない場合（Ｓ２５：Ｎｏ判定）、そのエレベータを６０秒程度停止後（Ｓ２６）、平常運転に戻し（Ｓ２７）、そのエレベータについて稼動状況情報Ｄ２に「稼動可能」を示す情報を設定する（Ｓ２８）。

【0026】

また、エレベータが走行中である場合は（Ｓ２５：Ｙｅｓ判定）、最寄階または非常着床階へ１０秒程度で着床できるかを判定する（Ｓ２９）。１０秒程度で着床できる場合（Ｓ２９：Ｙｅｓ判定）、ステップＳ２６に移行する。

【0027】

１０秒程度で着床できない場合（Ｓ２９：Ｎｏ判定）、そのエレベータの非常停止安全装置が正常かをチェックし（Ｓ３０）、正常である場合（Ｓ３０：Ｙｅｓ判定）、ステップＳ２６に移行する。

【0028】

非常停止安全装置が正常でない場合は（Ｓ３０：Ｎｏ判定）、運転を休止し（Ｓ３１）、そのエレベータについて稼動状況情報Ｄ２に「稼動不可」を示す情報を設定する（Ｓ３２）。

【0029】

一方、「低レベルの加速度値」以上である場合は（Ｓ２４：Ｙｅｓ判定）、そのエレベータが走行中かを判定し（Ｓ３３）、走行中でなければ（Ｓ３３：Ｎｏ判定）、そのエレベータを停止した状態で（Ｓ３４）、そのエレベータについて稼動状況情報Ｄ２に「稼動不可」を示す情報を設定する。その後、自動復旧運転または点検員による点検により（Ｓ３６）、平常運転に戻ると（Ｓ３７）、そのエレベータについて稼動状況情報Ｄ２の「稼動不可」を「稼動可能」に更新する（Ｓ３８）。

【0030】

「低レベルの加速度値」以上である場合において（Ｓ２４：Ｙｅｓ判定）、エレベータが走行中である場合は（Ｓ３３：Ｙｅｓ判定）、そのエレベータが最寄階または非常着床階へ１０秒程度で着床可能かを判定する（Ｓ３９）。着床可能でない場合（Ｓ３９：Ｎｏ判定）、そのエレベータを非常停止し（Ｓ４０）、ステップＳ４２に移行する。

【0031】

一方、着床可能である場合（Ｓ３９：Ｙｅｓ判定）、安全装置が一時的に作動しエレベータが停止した状態になったかを判定する（Ｓ４１）。そうなっていない場合（Ｓ４１：Ｎｏ判定）、異常感知センサ２１の出力が「高レベルの加速度値」以上を示すかを判定する（Ｓ４２）。ここで「高レベルの加速度値」以上でない場合（Ｓ４２：Ｎｏ判定）は、地震規模が「低レベルの加速度値」の範囲であることを示す。この場合、続いて、安全装置が正常かを判定し（Ｓ４３）、安全装置が正常な場合に（Ｓ４３：Ｙｅｓ判定）、ステップＳ３４に移行する。

【0032】

安全装置が正常でない場合には（Ｓ４３：Ｎｏ判定）、そのエレベータを停止し（Ｓ４４）、そのエレベータについて稼動状況情報Ｄ２に「稼動不可」を示す情報を設定する（Ｓ４５）。

【0033】

一方、異常感知センサ２１の出力が「高レベルの加速度値」以上である場合（Ｓ４２：Ｙｅｓ判定）は、地震規模が「高レベルの加速度値」の範囲であることを示す。この場合、非常救出運転して運転を休止し（Ｓ４６）、そのエレベータについて稼動状況情報Ｄ２に「稼動不可」を示す情報を設定する（Ｓ４７）。

【0034】

なお、安全装置が一時的に作動しエレベータが停止した状態になった場合は（Ｓ４１：Ｙｅｓ判定）、そのエレベータについて稼動状況情報Ｄ２に「稼動不可」を示す情報を設定する（Ｓ４５）。

【0035】

以上のように、異常感知センサ２１が地震に反応すると、制御設備１２が管制運転を実施し、その建物内の各エレベータＥＶ１、ＥＶ２、・・・について、稼動状況情報Ｄ２に稼動可否の情報が設定される。

【0036】

（エレベータ監視装置１０の構成）
エレベータ監視装置１０は、制御部５１（図１参照）と、ＨＤＤ（Hard Disk Drive）と、通信インタフェースとを有する。これらは、バスなどを介して接続されている。

【0037】

制御部５１は、ＣＰＵ（Central Processing Unit）とＲＯＭ（Read Only Memory）とＲＡＭ（Random Access Memory）とを備えたコンピュータ構成であり、ＣＰＵがＲＯＭのプログラムを実行することにより、演算処理やエレベータ監視装置１０の各部の制御処理を行う。ＲＡＭはＣＰＵの作業領域などとして使用する。

【0038】

ＨＤＤは、磁気ディスクを備え、制御部５１からの命令に基づき、磁気ディスクからのデータの読出しや、磁気ディスクへのデータの書き込みなどを行う。ＨＤＤは、後述するデータベース（「記憶部」の一例）などを格納する。

【0039】

通信インタフェースは、ネットワークＮ１、ネットワークＮ２に接続し、通信先とデータを送受信する例えばイーサネット（登録商標）ボードである。

【0040】

エレベータ監視装置１０のデータベース作成システム１０−１は、制御部５１を備えている。図１には、制御部５１における機能ブロックの構成の一例を示しておる。制御部５１がプログラムを実行することにより、各種機能が実現される。図１には、それらの内の主な機能として、第１の受付部１０１と、処理部１０３と、出力部１０４とを示している。

【0041】

第１の受付部１０１は、各建物Ａ１、Ａ２、・・・の制御設備１２から送信されるエレベータＥＶ１、ＥＶ２、・・・の稼動状況情報Ｄ２を受け付ける。具体的には、各建物Ａ１、Ａ２、・・・の制御設備１２から送信された稼動状況情報Ｄ２とユーザ情報Ｄ１と、その建物が病院である場合は更に病院情報Ｄ３とを含む、送信データを通信インタフェースが受信し、通信インタフェースからの通知などにより、第１の受付部１０１が稼動状況情報Ｄ２とユーザ情報Ｄ１と病院情報Ｄ３とを処理対象として処理部１０３に渡す。

【0042】

処理部１０３は、稼動状況情報Ｄ２とユーザ情報Ｄ１と病院情報Ｄ３とを含むデータベースを作成し、当該データベースから病院の受け入れが可能かの要否や、他の受け入れ可能な病院の候補を算出する。例えば、稼動状況情報Ｄ２の設定から病院内の各診療科目の受け入れ状況を読み取る。そして、稼動状況情報Ｄ２と共に送信されたユーザ情報Ｄ１において、当該病院の診療科目がかかりつけになっている各ユーザを対象に、当該病院においてユーザの受診科目の受け入れが可能かどうかの判定や、当該病院で受け入れが困難な場合には、さらに他の病院の候補を他の病院情報Ｄ３から抽出する処理などを行う。

【0043】

出力部１０４は、処理部１０３による判定結果（算出結果）、つまり、かかりつけの病院の受け入れ状況の結果や各ユーザのそれぞれの最適な病院の候補を、該当する各ユーザの端末１１に出力する。

【0044】

（テーブル）
続いて、データベースが備えるテーブルの一例を示す。
図３は、病院情報Ｄ３についての設定テーブルの一例を示す図である。図３（ａ）に示す各診療科目テーブルＴ１は、「診療科目」と、その「診療科目」を行き先とする「エレベータの識別情報」とを、「病院単位」で設定するテーブルである。各診療科目テーブルＴ１には、処理部１０３が病院情報Ｄ３から病院の診療科目についてのリストと、各診療科目を利用するためのエレベータＥＶ１、ＥＶ２、・・・とを抽出して設定する。ここでは、一例として「第１病院」と「第２病院」と「第３病院」についての３つのテーブルを示し、その他は図示を省略しているが、その他の病院についてのテーブルについても、同様に有するものとする。

【0045】

図３（ｂ）に示す病院位置情報テーブルＴ２は、病院の場所を設定するテーブルである。病院位置情報テーブルＴ２には、処理部１０３が病院情報Ｄ３から病院の場所として位置情報（緯度情報、経度情報）を抽出して設定する。

【0046】

具体的に、図３（ａ）に示す各診療科目テーブルＴ１の例では、「診療科目」の項目に全ての病院の各診療科目を示し、「内科」や「外科」などの各診療科目ごとに、対応するエレベータがあれば「○」を設定している。「×」は該当しないことを表している。

【0047】

例えば、「第１病院」の診療科目テーブルＴ１において、各エレベータＥＶ１、ＥＶ２、・・・の内の「ＥＶ１」で「内科」と「外科」に「○」が設定されている。また、「ＥＶ２」で「耳鼻科」に「○」が設定されている。これは、「第１病院」では、「内科」と「外科」を各エレベータＥＶ１、ＥＶ２、・・・の内の「ＥＶ１」により利用できることを表し、「耳鼻科」を「ＥＶ２」により利用できることを表している。ここから「第１病院」には診療科目として「内科」、「外科」、「耳鼻科」が含まれていることも分かる。

【0048】

これに対し、「第２病院」は、２台のエレベータの「ＥＶ１」と「ＥＶ２」のどちらにおいても「内科」は「×」となっている。つまり「第２病院」には「内科」が含まれていないことが分かる。また、「第３病院」は、２台のエレベータの「ＥＶ１」と「ＥＶ２」のどちらにおいても「外科」は「×」となっており、「第３病院」に「外科」が含まれていないことが分かる。

【0049】

なお、病院情報Ｄ３から各診療科目とエレベータＥＶ１、ＥＶ２、・・・との分類までを示す情報が得られない場合には、エレベータ単位で分けて設定しなくてもよい。そのような場合、処理部１０３は、その病院の診療科目テーブルＴ１に、エレベータＥＶ１、ＥＶ２、・・・を代表して表す「ＥＶ０」を設け、「ＥＶ０」のレコードに「内科」や「外科」や「耳鼻科」などの「○」や「×」を設定する。

【0050】

図４は、稼動状況情報Ｄ２についての設定テーブルの一例を示す図である。図４（ａ）には、各建物Ａ１、Ａ２、・・・から地震などの災害検出により送信されてくる稼動状況情報Ｄ２の設定テーブル（稼動状況情報設定テーブルＴ３）の一例を示している。稼動状況情報設定テーブルＴ３には、処理部１０３により各建物Ａ１、Ａ２、・・・の稼動状況情報Ｄ２がレコードごとに設定される。

【0051】

一例では、「第１病院」と、「第２病院」と、「第３病院」と、「第１マンション」とから稼動状況情報Ｄ２が送信されたときの設定を示している。例えば「第１病院」については、稼動状況情報Ｄ２から、災害発生日時の「２０１７年１１月９日、１０：３０」や、各エレベータＥＶ１、ＥＶ２、・・・の「稼動可能」または「稼動不可」を示す情報が設定される。なお、「第２病院」と「第３病院」についてはエレベータが「ＥＶ１」と「ＥＶ２」しか設定されていないため「ＥＶ３」は情報が無いものとして「−」で表している。

【0052】

図４（ｂ）には、処理部１０３が稼動状況情報設定テーブルＴ３の設定に基づいて生成した判定テーブルＴ４の一例を示している。この例において、判定テーブルＴ４は、各病院の診療科目テーブルＴ１の設定と、稼動状況情報設定テーブルＴ３の設定とから生成しており、各病院の診療科目の受け入れ状況を示している。例えば、稼動状況情報設定テーブルＴ３において「第１病院」は何れのエレベータも「稼動不可」である。これは、「第１病院」では患者の受け入れができないことを表している。このため、判定テーブルＴ４の「第１病院」には何れの診療科目にも受け入れ不可の「△」が設定される。判定テーブルＴ４において、「○」は受け入れ可を示し、「△」は受け入れ不可を示し、「×」は対応する診療科目がないことを示す。このようにして処理部１０３は、判定テーブルＴ４を随時生成し、生成した最新の判定テーブルから診療科目単位で受け入れ先の病院を探すことが可能になる。

【0053】

図５は、ユーザ情報Ｄ１についての設定テーブルの一例を示す図である。図５に示す設定テーブル（ユーザ情報テーブルＴ５）は、設定項目として、「ユーザ識別情報」と、「病院名」と、「受診科目」と、「端末情報」とを有する。これらのデータは、送信されたユーザ情報Ｄ１に基づいて処理部１０３が設定する。これらのデータには個人情報が含まれているため、記憶部２２にユーザ情報Ｄ１としてユーザ登録時に割り当てられたユニークな識別コードを記憶させてもよい。この場合、エレベータ監視装置１０において、各識別コードから「ユーザ識別情報」、「病院名」、「受診科目」、および「端末情報」のデータをデータベースなどから照会して抽出する。ここで「端末情報」とは、ユーザのスマートフォンなどの端末１１に登録されている各種のアドレス（ＭＡＣ（Media Access Control address）アドレスやＥメールアドレスなど、端末１１の送信先を示す情報）である。

【0054】

（病院の候補を抽出する処理のフロー）
続いて、エレベータ監視装置１０における災害通知処理の手順について説明する。

【0055】

図６は、エレベータ監視装置１０（制御部５１）が行う災害通知処理の手順の一例を示すフローチャートである。この処理は、エレベータ監視装置１０が、災害の発生を検出した各建物Ａ１、Ａ２、・・・から送信される稼動状況情報Ｄ２とユーザ情報Ｄ１と、建物が病院である場合は更に病院情報Ｄ３とを含む送信データを受信することにより開始される。

【0056】

先ず、制御部５１は、各建物Ａ１、Ａ２、・・・からの各送信データに含まれるユーザ情報Ｄ１と稼動状況情報Ｄ２と病院情報Ｄ３とを受け付ける（Ｓ１０１）。

【0057】

続いて、制御部５１は、各建物Ａ１、Ａ２、・・・から送信された上記ユーザ情報Ｄ１と上記稼動状況情報Ｄ２と上記病院情報Ｄ３とについてデータベースを作成する（Ｓ１０２）。本実施形態において示す例では、制御部５１は、上記ユーザ情報Ｄ１のデータをユーザ情報テーブルＴ５（図５参照）に設定し、上記稼動状況情報Ｄ２のデータを稼動状況情報設定テーブルＴ３（図４（ａ）参照）に設定する。また、制御部５１は、上記病院情報Ｄ３のデータを診療科目テーブルＴ１（図３（ａ）参照）と病院位置情報テーブルＴ２（図３（ｂ）参照）とに設定する。そして、各病院の診療科目テーブルＴ１（図３（ａ）参照）の設定と、稼動状況情報設定テーブルＴ３の設定とから、判定テーブルＴ４（図４（ｂ）参照）を生成する。

【0058】

判定テーブルＴ４の生成は、具体的には、処理部１０３が次のように行う。先ず、各病院の診療科目テーブルＴ１から、各エレベータに対応する診療科目をエレベータ毎に抽出し、稼動状況情報設定テーブルＴ３において、該当する病院且つエレベータの稼動状況を示す情報を抽出する。そして、判定テーブルＴ４に対し、病院名と、その病院のそれぞれの診療科目について、上記稼動状況を示す情報が「稼動可」であれば「○」を、「稼動不可」であれば「△」を設定する。先にも説明したが、「×」は診療科目がないことを示す。

【0059】

例えば、第１病院の診療科目テーブルＴ１において、エレベータＥＶ１は「内科」と「外科」に通じ、エレベータＥＶ２は「耳鼻科」に通じることが設定されている。一方、稼動状況情報設定テーブルＴ３において、「第１病院」の「ＥＶ１」と「ＥＶ２」は共に「稼動不可」になっている。従って、判定テーブルＴ４において、「第１病院」の「内科」、「外科」、および「耳鼻科」が「△」になっている。

【0060】

また、第２病院の診療科目テーブルＴ１において、エレベータＥＶ１は「外科」に通じ、エレベータＥＶ２は「耳鼻科」に通じることが設定されている。一方、稼動状況情報設定テーブルＴ３において、「第２病院」の「ＥＶ１」は「稼動可能」で、「ＥＶ２」は「稼動不可」になっている。従って、判定テーブルＴ４において、「第２病院」の「外科」が「○」で「耳鼻科」が「△」になっている。「内科」は設けていないため「×」になっている。

【0061】

続いて、制御部５１は、ユーザ情報テーブルＴ５に設定されている各ユーザについて、かかりつけの病院の診療科目が患者を受け入れることが可能かを判定テーブルＴ４から判定する（Ｓ１０３）。

【0062】

例えば、ユーザ情報テーブルＴ５において、「Ｕｓｅｒ１」は「第１病院」の「内科」をかかりつけとする設定になっている。判定テーブルＴ４には、第１病院の「内科」は受け入れ不可を示す「△」が設定されている。このため、「Ｕｓｅｒ１」については第１病院に行っても「内科」を受けられる可能性が低いことが判明する。一方、「Ｕｓｅｒ２」は、ユーザ情報テーブルＴ５において「第２病院」の「外科」をかかりつけとする設定になっている。判定テーブルＴ４にも、第２病院の「外科」は受け入れ可を示す「○」が設定されている。このため、「Ｕｓｅｒ２」についてはかかりつけの第２病院で「外科」を受けられることが判明する。

【0063】

ステップＳ１０３においてかかりつけの病院の診療科目が受け入れ不可と判定されたユーザについては、続いて制御部５１が最適な病院を選択する処理を行う（Ｓ１０４）。

【0064】

例えば、「Ｕｓｅｒ１」の場合は「内科」を受診するため、他の病院の中から「内科」を受け入れているところで最適な場所（所定の優先順序で決めた病院）を選択する。処理の具体例として、例えば、制御部５１は、判定テーブルＴ４において「内科」に「○」が設定されているものを抽出する。この例では、その内の一つとして「第３病院」が該当する。制御部５１は、抽出した各病院（この例では「第３病院」も含む）について、所定の優先順序でユーザに提示する病院の候補を決定する。例えば、基準とする位置（ユーザのかかりつけの病院や、ユーザの住居や、ユーザの現在位置など）から病院までの距離が近い順に病院の候補を上位順に並べる。

【0065】

そして、制御部５１は、該当するユーザの端末１１のアドレスをそれぞれ指定し、そのユーザについての病院候補を含む通知画面情報を配信する（Ｓ１０５）。

【0066】

（端末１１に出力する通知画面）
図７は、端末１１において出力される通知画面の構成の一例を示す図である。図７に示す通知画面９１には、端末１１のユーザについてのかかりつけの病院の情報９１０と別の病院候補の情報９１１とを出力可能に組み込んでいる。この例では、「Ｕｓｅｒ１」の端末１１における出力例を示しており、「Ｕｓｅｒ１」のかかりつけの病院の患者の受け入れ状況を「困難」として示している。また、その他の病院の候補を、距離が近い順にリスト表示し、それぞれの病院の位置を示す記号と文字を地図情報９１２に重畳させて示している。地図情報９１２は、エレベータ監視装置１０が予め記憶しておいたものを出力してもよいし、外部の地図情報データベースから取得して出力してもよい。また、病院の位置を示す方法は、記号と文字に限らず、任意に設定してよい。例えば、基準とする位置（ユーザのかかりつけの病院や、ユーザの住居や、ユーザの現在位置など）から病院までの経路情報を示してもよい。

【0067】

これらの表示により、「Ｕｓｅｒ１」は、かかりつけの病院に行っても診療が受けられない可能性が高いと判断し、病院候補の中から別の病院を見つけ出すことができるようになる。

【0068】

本実施形態では、各建物Ａ１、Ａ２、・・・に、それぞれ、異常感知センサ２１が１つ備わっているものとして、各処理について一例を示したが、各エレベータＥＶ１、ＥＶ２、・・・のそれぞれに異常感知センサ２１が設置されている場合も考えられる。この場合には、制御設備１２において、異常信号が出力されたエレベータの動作についてチェックし、残りのエレベータについては稼動可能として稼動状況情報Ｄ２をまとめてもよい。

【0069】

また、ユーザ情報Ｄ１は、本実施形態では、各建物Ａ１、Ａ２、・・・の記憶部２２が記憶するものとして説明したが、これに限らない。例えば、エレベータ監視装置１０が予めユーザから登録を受けたり、外部のデータベースなどから取得したりしてもよい。その場合、ユーザ情報Ｄ１の各ユーザのかかりつけの病院や住居（マンション）などの情報も取得し、稼動状況情報Ｄ２が送信された各建物Ａ１、Ａ２、・・・とユーザとの対応関係が分かるようにしておく。

【0070】

本実施形態では、災害の発生範囲内においてユーザに最適な病院を通知することが可能になる。

【0071】

（変形例１）
災害発生時に、ユーザの端末１１に対しユーザの怪我の状況や体調などの被災情報を確認する問い合わせを行い、応答されたユーザの被災情報に応じて病院の候補を抽出できるようにした変形例について示す。なお、ここでは、実施形態と異なる部分について説明し、実施形態と共通する箇所の説明は、適宜省略する。

【0072】

変形例１では、実施形態のエレベータ監視装置１０の機能ブロックの構成（図１参照）において、さらに、第２の受付部（不図示）を設けている。変形例１では、出力部１０４において、ユーザの端末１１に候補情報と共に入力フォームも送信する。入力フォームは、ユーザの怪我の状況（体調なども含む）の被災情報を問い合わせる定型文などを含む送信情報である。

【0073】

第２の受付部は、ユーザの端末１１から入力フォームに基づいて返信される被災情報を受け付ける。そして、被災情報を処理部１０３に渡し、病院候補を再判定させる。ここで、「返信」は、「応答」の一手段である。

【0074】

図８は、変形例１にかかる災害通知処理の一例を示すフローチャートである。ここでは、繰り返しの説明を避けるため、実施形態の災害通知処理の手順（図６参照）に係る処理については簡単に説明する。

【0075】

ステップＳ１０４で持病についての他の病院候補を抽出すると、出力部１０４は、当該ユーザの端末１１に対して入力フォームが送信済みかを判定する（Ｓ１０５−１）。

【0076】

入力フォームが送信済みでない場合（Ｓ１０５−１：Ｎｏ判定）、出力部１０４は、上記病院候補と共に所定の入力フォームをユーザの端末１１に送信する（Ｓ１０５−２）。

【0077】

そして、第２の受付部が、入力フォームが送信されたユーザから返信があるかを判定する（Ｓ１０５−３）。例えば、第２の受付部は、一定の返信時間をカウントし、その時間内に返信がなかった場合に返信なしと判定し（Ｓ１０５−３：Ｎｏ判定）、処理を終了する。

【0078】

一定の返信時間内に返信があった場合（Ｓ１０５−３：Ｙｅｓ判定）、第２の受付部は、その返信内容（一例としてユーザの怪我を示す情報とする）を受け付け、処理部１０３により、ステップＳ１０３で、ユーザの怪我の状況に基づいて判定テーブルＴ４から再判定し、ステップＳ１０４で病院候補を抽出する。

【0079】

続いて、入力フォームは送信済みのため（Ｓ１０５−１：Ｙｅｓ判定）、出力部１０４は、通知画面に上記怪我についての病院候補を設定し、ユーザの端末１１に送信し（Ｓ１０５−４）、本処理を終了する。

【0080】

図９は、第２の受付部が行う受付処理の一例を示す図である。図９には、一例として「Ｕｓｅｒ１」から怪我の返信を受け付けた場合の受付処理について示している。

【0081】

先ず、災害発生時において、ユーザ情報テーブルＴ５には「Ｕｓｅｒ１」の「受診科目」が「内科」に設定されている（Ｓ２０１）。この設定に基づき、「Ｕｓｅｒ１」についての病院候補が判定テーブルＴ４から判定され（Ｓ２０２）、判定結果と、怪我を入力する入力フォームとが「Ｕｓｅｒ１」の端末１１に送信される（Ｓ２０３）。

【0082】

その後、「Ｕｓｅｒ１」の端末１１から、ユーザの怪我の状況として「打撲」と返信があったとする（Ｓ２０４）。すると、第２の受付部が、「打撲」が属する診療科目を診療科目テーブルＴ６から照会し（Ｓ２０５）、照会結果の診療科目を「Ｕｓｅｒ１」の「受診科目」に設定する（Ｓ２０６）。

【0083】

その後は、処理部１０３により「Ｕｓｅｒ１」の最新の設定で判定テーブルＴ４から病院候補が再判定され（Ｓ２０７）、再判定結果が「Ｕｓｅｒ１」の端末１１に送信される（Ｓ２０８）。

【0084】

図１０は、端末１１に送信する入力フォーム情報の一例を示す図である。図１０に示す入力フォーム情報９１３は、ユーザの負傷内容を受け付けるための入力フォームを設けている。図１０に示す例では、災害時の主な負傷内容の一覧（打撲、骨折、捻挫、・・・など）を表示し、それぞれに対応するチェックボックス９１３−１を設けている。また、その他の負傷内容を受け付けるためのテキスト入力ボックス９１３−２を設けている。それらの入力内容の返信を行って画面を終了させる指示は、「送信する」ボタン９１３−３で受け付ける。入力フォームによる返信を行わずに画面を終了させる指示は、「送信しない」ボタン９１３−４で受け付ける。

【0085】

入力フォーム情報９１３は、通知画面９１（図７参照）に組み込んでもよいし、通知画面９１とは別の入力フォーム画面として送信してもよい。

【0086】

本変形例１では、ユーザから被災情報として怪我の状況を受け取り、その怪我に該当する診療科目の病院候補を抽出したが、被災情報の内容に従い、病院候補を抽出する優先順序に所定の重みづけを行ってもよい。例えば、被災情報からユーザが動けるか動けないかを判定し、動ける場合は、少し遠目の病院を候補として通知し、動けない場合は、近めの病院を通知したり、その程度に応じて病院に緊急通報したりする。

【0087】

また、本変形例１では、入力フォームをエレベータ監視装置１０から端末１１へ送信する例を示したが、入力フォームを送信する主体は、エレベータ監視装置１０に限らなくてもよい。例えば、建物が災害を感知すると、その建物のエレベータの無線アクセスポイントから、付近のユーザ（主に、そのエレベータや建物内などにいるユーザ）の端末１１に入力フォーム情報が配信されるようにしてもよい。ユーザは、各端末１１において被災情報を入力し、その被災情報を無線アクセスポイントからエレベータ監視装置１０に送信する。この場合、エレベータ監視装置１０は、災害を感知した建物から送信されるユーザ情報Ｄ１において、かかりつけの診療科目をユーザから送られた被災情報に基づく診療科目に変更して病院候補を抽出する。

【0088】

このように、変形例１では、例えば、マンションにおいてエレベータの異常が検出された場合、そのマンションから送信されるユーザ情報Ｄ１に負傷している住人の情報を含む可能性が高い。そこで、マンションなどから送られてきたユーザ情報Ｄ１に設定されているユーザの端末１１に向け、入力フォームを送信し、住人の被災情報（怪我などの情報）を取得する。エレベータ監視装置１０は、各住人の被災情報から該当する診療科目を判定し、受け入れ可能な病院の候補を各住人の端末１１に送信する。これにより、現在の怪我に応じた病院の候補を提示することができる。

【0089】

（変形例２）
被災地域では、通信経路に断線等が発生し、通信できなくなる可能性があるため、各建物Ａ１、Ａ２、・・・内における通信や、各建物Ａ１、Ａ２、・・・とエレベータ監視装置１０との間の一部または全ての通信を無線ネットワークにより構築してもよい。
例えば、各建物Ａ１、Ａ２、・・・のエレベータＥＶ１、ＥＶ２、・・・に無線アクセスポイントを設ける。この場合、各無線アクセスポイントを通じて、端末１１と制御設部１２間や、端末１１とエレベータ監視装置１０間の一部または全てで、無線通信を行うことができる。各無線アクセスポイントは、例えば建物内のユーザの端末１１にユーザの被災情報を確認する入力フォームを送信して、各無線アクセスポイントから各ユーザの怪我の状況などを示す被災情報を回収するなどの利用形態が考えられる。

【0090】

（変形例３）
実施形態では、災害発生範囲内において病院候補を抽出する形態を示したが、災害発生範囲外の病院も含めて病院候補を抽出することができるようにした変形例を示す。

【0091】

変形例３では、エレベータ監視装置１０は、各病院の病院情報Ｄ３を外部データベース（病院情報データベースなど）から取得する。

【0092】

このように、エレベータ監視装置１０は病院情報Ｄ３を外部から取得するため、各病院のエレベータに設けられた記憶部２２にはユーザ情報Ｄ１を記憶させておけばよいことになる。

【0093】

エレベータ監視装置１０は、災害を検出した病院から、当該病院のユーザ情報Ｄ１と当該病院の稼動状況情報Ｄ２とを受け付ける。病院情報Ｄ３については、所定のタイミングでエレベータ監視装置１０が外部データベースから取得する。そして、エレベータ監視装置１０は、外部データベースから取得した病院情報Ｄ３により、各病院のエレベータと診療科目との関係を診療科目テーブルＴ１（図３参照）に設定する。また、病院位置情報テーブルＴ２（図３参照）に各病院の位置を設定する。そして、エレベータ監視装置１０は、判定テーブルＴ４（図４（ｂ）参照）を、異常感知センサ２１が反応しなかった災害範囲外の病院の判定情報も含めて生成する。例えば、エレベータ監視装置１０は、診療科目テーブルＴ１において災害範囲外の病院の各診療科目を受け入れ可の「○」に設定する。この設定により、エレベータ監視装置１０は、判定テーブルＴ４の生成の際に、災害範囲外の病院について各診療科目に判定情報「○」を設定する。

【0094】

このように、判定テーブルＴ４には、災害発生範囲の病院と災害発生範囲外の病院とが設定されることになる。エレベータ監視装置１０は、判定テーブルＴ４から、かかりつけの病院での受け入れが不可の利用者について利用可能な病院の候補を所定の優先順序で災害範囲内と災害範囲外とから算出する。例えば、判定情報が「○」の病院から、基準とする位置から病院までの距離が近い順に、災害発生範囲外の病院も含めて、病院の候補を上位順に並べる。そして、その算出結果である病院候補を利用者の端末１１に送信する。

【0095】

なお、病院情報Ｄ３は、システムの起動時や、１日１回など、適宜設定したタイミングで最新のデータに書き換えることが望ましい。最新データへの書き換えは、例えば、エレベータ監視装置１０が外部データベースに要求して取得したり、外部データベースから更新の通知を受け取るなどして行う。

【0096】

変形例３では、災害の発生範囲だけでなく、災害の発生範囲以外においての病院も含め、ユーザに最適な病院候補を抽出する。このように、災害の発生範囲以外の病院も含めることにより、災害発生範囲で病院が見つからなかった場合に災害発生範囲外の近隣地区からユーザに最適な病院を確実に通知することが可能になる。

【0097】

（変形例４）
災害情報の１回目の配信から所定時間経過後に、エレベータ監視装置１０がユーザの端末１１に病院候補の最新情報を配信できるようにした変形例について示す。ここでは、変形例１の構成において、ユーザの端末１１から入力フォームの返信があった場合を一例に、最新情報を配信する構成について示す。なお、ここでは、変形例１と異なる部分について説明し、変形例１と共通する箇所の説明は、適宜省略する。

【0098】

図１１は、変形例４にかかるエレベータ監視装置１０の機能ブロックの構成の一例を示す図である。変形例１の機能ブロックの構成において、さらに、タイマ２０１と取得部２０２とを設けている。なお、第２の受付部３０１は変形例１において不図示であった第２の受付部である。

【0099】

タイマ２０１は、所定時間をカウントし、その時間経過を取得部２０２に通知する。ここでは、一例として災害発生時におけるユーザからの被災情報により再判定された病院候補が出力部１０４からユーザの端末１１に再配信されたときから、カウントを開始し、設定された時間が経過する度に、その時間経過を取得部２０２に通知する。例えば、刻み間隔が「３０分」で継続時間が「２４時間」になるように設定した場合、タイマ２０１は、２４時間が経過するまで３０分刻みで設定時間の経過を通知する。

【0100】

取得部２０２は、タイマ２０１から設定時間の経過の通知を受ける度に、各建物Ａ１、Ａ２、・・・から、当該設定時間までのエレベータＥＶ１、ＥＶ２、・・・の稼動状況を示すログ（「稼動頻度を示す情報」の一例）を取得する。そして、各ログを解析し、更新用の稼動状況情報Ｄ２を生成する。

【0101】

図１２は、上記ログの一例を示す図である。図１２（ａ）と図１２（ｂ）には、ある設定時間後の、第１病院から送られてきたログＤ２１と、第３病院から送られたログＤ２２とを示している。ここでは第１病院と第３病院のログを一例として示しているが、この他にも、第２病院や第４病院など他の病院からもログを取得する。

【0102】

ログＤ２１は、第１病院のエレベータＥＶ１、ＥＶ２、・・・の稼動状況を示すログである。日付と時刻の欄に示すように、「２０１７年１１月９日」の発生時刻１０時３０分から１時間後の１１時３０分までのログである。ログＤ２２や、その他の病院のログも同様に、「２０１７年１１月９日」の発生時刻１０時３０分から１時間後の１１時３０分までのログが送られる。ここでは、災害発生直後からのログの全てを示しているが、送信時前に送ったログとの差分を送ってよい。

【0103】

ログＤ２１には、第１病院のエレベータＥＶ１とエレベータＥＶ２は共に、発生時刻１０時３０分から１１時２７分まで稼動不可（×）であったことが記録されている。エレベータＥＶ３など、他のエレベータも、ここでは図示を省略しているが、エレベータＥＶ１とエレベータＥＶ２と同様に稼動不可（×）である。そして、１１時２８分において、エレベータＥＶ１とエレベータＥＶ２とにおいて行き先の階数が「３Ｆ」と「２Ｆ」として記録されており、ここで稼動が再開したことが推測できる。再開後は、エレベータの利用が少ないため、エレベータの移動が無いことを示す（−）が記録されている。

【0104】

他方のログＤ２２においては、第３病院のエレベータＥＶ１とエレベータＥＶ２は共に、発生時刻１０時３０分後も稼動していることが記録されている。そして、１１時２７分頃から、エレベータＥＶ１とエレベータＥＶ２とがそれぞれ頻繁に「３Ｆ」と「４Ｆ」とを行き来していることが記録され、混雑し始めてきたことが推測できる。

【0105】

図１３は、病院候補が再配信された後にエレベータ監視装置１０がユーザの端末１１に最新の病院候補を配信するための手順の一例を示すフローチャートである。図１３には、変形例１の災害通知処理の手順（図８参照）については省略し、ステップＳ１０５−４の後の処理について示している。なお、図１３には、説明を分かり易くするため、一人のユーザに対する処理手順を示しているが、この処理フローは、各ユーザに対して行われるものとする。

【0106】

制御部５１は、ステップＳ１０５−４の再配信が終わると、タイマ２０１により設定時間のカウントを開始する（Ｓ３０１）。

【0107】

続いて、制御部５１は、タイマ２０１が設定時間になると、各建物Ａ１、Ａ２、・・・から、災害発生から当該設定時間までのエレベータＥＶ１、ＥＶ２、・・・の稼動状況を示すログ（ログＤ２１、・・・、ログＤ２２、・・・）を取得する（Ｓ３０２）。

【0108】

続いて、制御部５１は、各ログから得られた最新の稼動状況情報Ｄ２によりデータベースを更新する（Ｓ３０３）。具体的に、制御部５１は、最新の稼動状況情報Ｄ２により稼動状況情報設定テーブルＴ３（図４（ａ）参照）の設定を更新し、稼動状況情報設定テーブルＴ３の更新後の設定に基づいて判定テーブル（図４（ｂ）参照）を生成する。

【0109】

続いて、制御部５１は、当該ユーザについて、判定テーブルＴ４の設定に基づき最新の病院候補を抽出する（Ｓ３０４）。
そして、制御部５１は、当該ユーザの端末１１のアドレスを指定し、当該ユーザについての病院候補を含む通知画面情報を配信し（Ｓ３０５）、本処理を終了する。

【0110】

なお、本処理が示すように、制御部５１は所定時間になると最新の病院候補を再算出し、算出結果を再配信するように動作するが、この一連の動作は、１回に限らず、複数回繰り返してもよい。例えば、タイマ２０１に刻み間隔が「３０分」で継続時間が「２４時間」になるように設定し、２４時間が経過するまで３０分刻みで上記処理を繰り返させるようにする。

【0111】

次に、最新の稼動状況情報Ｄ２に基づく稼動状況情報設定テーブルＴ３の設定例と、その設定に基づいて再生成された判定テーブルＴ４の設定例とについて説明する。

【0112】

図４（ａ）に示す稼動状況情報設定テーブルＴ３については、時刻が設定時刻の１１時３０分に更新される。また、各病院の各エレベータＥＶ１、ＥＶ２、・・・の設定が書き換わる。

【0113】

具体的に、「第１病院」のログＤ２１では、災害発生時は何れのエレベータＥＶ１、ＥＶ２、・・・でも「稼動不可」であったが、１１時３０分頃のＥＶ１、ＥＶ２、・・・の記録データの解析により、１１時２８分に復旧したことが予測され、ＥＶ１、ＥＶ２、・・・が「稼動可能」に書き換わる。また、「第３病院」のログＤ２２では、災害発生直後もエレベータＥＶ１、ＥＶ２共に「稼動可能」であったが、１１時３０分頃のＥＶ１、ＥＶ２の記録データの解析により、１１時２７分頃からの頻繁な稼動が混雑と予測され、ＥＶ１、ＥＶ２が共に「混雑」に書き換わる。

【0114】

図４（ｂ）に示す判定テーブルＴ４については、第１病院の各診療科目が「△」から「○」に変更される。また第３病院については、内科が「○」であったものが「混雑」により「△」に変更される。

【0115】

従って、この場合、「Ｕｓｅｒ１」の端末１１において１０時３０分時点でかかりつけの病院の患者の受け入れ状況を「困難」として示されていたもの（図７参照）が、１１時３０分の更新により、受け入れ可能を示す「可」に変更されることになる。「Ｕｓｅｒ１」については、かかりつけの病院が利用できることになるため、病院候補などの他の情報は、通知画面情報から削除してもよい。

【0116】

図１４は、通知画面の内容の更新の一例を示す図である。図１４には、一例として「Ｕｓｅｒ３」の端末１１における通知内容の更新例を示している。図１４（ａ）は、１０時３０分時点の通知例であり、図１４（ｂ）は、１１時３０分時点の通知例である。これまでに説明してきたように１０時３０分時点では第３病院の「内科」が利用できるため、図１４（ａ）に示すように、かかりつけの病院の情報９１０の「患者の受け入れ」が「可」で示されている。一方、図１４（ｂ）に示す１１時３０分時点には、第３病院の「内科」が「不可」として判断されるため、「患者の受け入れ」が「困難」に変更され、別の病院候補の情報９１１に病院候補として「第１病院」などが提示される。

【0117】

なお、本例の通知画面９１には、エレベータが「混雑」と解析された場合であっても、かかりつけの病院の情報９１０の「患者の受け入れ」の欄にエレベータが稼動不可の場合と同じ「困難」を設定しているが、この設定をエレベータが稼動不可の場合と区別できるように「混雑」に変えてもよい。また、解析の際に、エレベータの頻度から混雑度数を算定し、「患者受け入れ」の欄にその「混雑度数」を設定してもよい。

【0118】

また、本例では、エレベータ監視装置１０にタイマ２０１を設け、タイマ２０１の設定時刻になるとエレベータ監視装置１０が各建物Ａ１、Ａ２、・・・からログを取得する構成としたが、各建物Ａ１、Ａ２、・・・が、災害を検出すると、災害発生後の一定期間、各建物Ａ１、Ａ２、・・・が、上記ログをエレベータ監視装置１０に定期的に送信し、そのログをエレベータ監視装置１０で受け付けるようにしてもよい。

【0119】

このように、変形例４では、各建物Ａ１、Ａ２、・・・から各時点の稼動状況情報Ｄ２の最新情報を取得して、それを病院候補の判定に反映し、最新の病院候補をユーザの端末１１に配信する。このようにすることで、例えば、かかりつけの病院が災害発生当初において患者を受け入れることができなかった場合でも、災害発生から１０分経過後、３０分経過後、１時間経過後など、時間の経過により復旧し、受け入れが可能になる可能性が高まるため、復旧された時点で知ることができるようになる。また、他の病院候補が受け入れ可能として情報提供されていた場合であっても、時間の経過により、そこに患者が集中し、新たな患者の受け入れが困難になる場合がある。このような場合に、一定時間の経過後、改めて病院候補が提示されることで、最新の受け入れ状況を知ることが可能になる。

【0120】

本発明の実施形態および変形例を説明したが、これらは、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態および変形例は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態および変形例は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【0121】

例えば、実施形態および変形例で設けた機能部の一部または全てをＡＳＩＣなどにより構成してもよい。

【符号の説明】

【0122】

１…災害情報通知システム、１０…エレベータ監視装置（災害情報処理装置）、１０−１…データベース作成システム、１１…端末、１２…制御設備、１２−１…エレベータ制御盤、１２−２…遠隔監視端末装置、２１…異常感知センサ、２２…記憶部、１０１…第１の受付部、１０３…処理部、１０４…出力部、２０１…タイマ、２０２…取得部、３０１…第２の受付部、Ａ１、Ａ２…建物（病院、マンションなど）、Ｄ１…ユーザ情報、Ｄ２…稼動状況情報、Ｄ３…病院情報、ＥＶ１、ＥＶ２…エレベータ、Ｎ１、Ｎ２…ネットワーク、Ｔ１…診療科目テーブル（記憶部）、Ｔ２…病院位置情報テーブル（記憶部）、Ｔ５…ユーザ情報テーブル（記憶部）。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】