JP6448495B2 - 救助要請支援装置、その作動方法、プログラム、及びシステム - Google Patents

Description

本発明は、救助要請支援装置、その作動方法、プログラム、及びシステムに関する。

突発的な発病などユーザに緊急事態が発生して、ユーザが要救助者になった場合に、ユーザの救助要請を支援する救助要請支援システムが知られている（例えば、特許文献１に記載の緊急通報付き健康管理装置及び特許文献２に記載のサービス提供方法）。こうしたシステムによれば、専門の救急隊員が到着するまでの間、要救助者の近くにいる人によって応急的な救助が可能になる。

特許文献１に記載の救命救急補助システムは、ユーザに体調異常が生じ救命救急行為が必要になったときに、救命救急補助装置がユーザ周辺にいるユーザ救助に適切な第三者（医師、看護師、救命士など）を選定し、救命指示情報を第三者端末装置に送信している（段落００１１）。また、ユーザ救助に適切な第三者を選定する際に、ユーザの登録情報から医療行為が可能な医者や看護師などの医療従事者を選定している（段落００２５）。

特許文献２に記載の救助システムは、被救助者の端末からの安否情報をサーバが受け付ける（段落００３０）。安否情報を受け付けた救助システムは、被救助者の救助に向かう救助者の端末に対して、救助者と複数の被救助者との位置を含めたマップ表示として発信する機能を有している（段落００３６）。

特開２０１２−２２２４４３号公報 特開２０１４−０８９５４３号公報

救助に当たっては、１人で救助を行うよりも複数人が協力して救助を行う方が迅速で適切な救助が行える可能性が高い。救助者の中に医療従事者が存在すれば、より適切な救助を行うことが可能となる。また、救助者が複数人いれば、各救助者は、救助を行うのは自分１人ではないという安心感が得られる。

このように、複数人が協力して救助を行う場合において、サーバが医療従事者を選定して救助要請を行う特許文献１の技術や、救助に向かう複数人の救助者の位置を地図上で把握できる特許文献２の技術は有用である。

しかしながら、迅速かつ適切な救助を確実に行うためには、さらなる改良の余地があった。というのも、特許文献１のように医療従事者に対して救助要請をしても、実際に医療従事者が救助要請を承諾しない場合もある。その場合には、サーバは別の医療従事者を探すことになるが、予め登録されたユーザの中に適切な医療従事者が存在しなかったり、サーバが別の医療従事者を探すのに時間を要したりする場合もある。そのため、医療従事者をより迅速に救助に向かわせるための技術が求められていた。

本発明は、要救助者の現在位置に医療従事者をより迅速に救助に向かわせることが可能な救助要請支援装置、その作動方法、プログラム、及びシステムを提供することを目的とする。

上記目的を達成するために、本発明の救助要請支援装置は、位置情報取得部と、地図情報作成部と、地図情報配信部と、救助者選定部と、救助要請通知送信部と、判定部とを備えている。位置情報取得部は、救助要請が出された要救助者と要救助者の救助要請を受けた救助者のそれぞれが携帯する携帯端末から、要救助者及び救助者の現在位置を表す位置情報を取得する。また、位置情報取得部は、予め登録されたユーザが携帯する携帯端末からの情報に基づいて、ユーザの位置情報を取得する。地図情報作成部は、要救助者及び救助者の現在位置をマッピングした地図情報を作成する。地図情報には、予め登録された登録情報に基づいて救助者が医療従事者であるか否かを示す識別マークが表示される。地図情報配信部は、地図情報を救助者の携帯端末に配信する。救助者選定部は、要救助者の現在位置に基づいて、ユーザの中から救助者を選定する。救助要請通知送信部は、選定された救助者に対して救助要請通知を送信する。判定部は、救助要請通知を受信した救助者が、要救助者の現在位置に向かっているか否かを判定する。そして、要救助者の現在位置に向かっていないと判定された救助者の中に、医療従事者がいる場合には、医療従事者に対して救助要請通知を再送信する。

医療従事者は、医者、看護師、救急救命士のいずれかであり、識別マークは医者、看護師、救急救命士を識別するマークであることが好ましい。この場合には、医療従事者であることのみならず、職業も判ることから、要救助者の容態等に応じて、より治療レベルの高い医者等を救助者として新たに要請することが可能になる。

地図情報において、複数の救助者の現在位置の表示が重なっている場合には、医療従事者である救助者が優先的に表示されることが好ましい。この場合には、複数の救助者が重なって表示される場合に、医療従事者の有無が確実に判る。

地図情報配信部は、救助要請通知の送信先に地図情報を配信することが好ましい。

救助者選定部は、探索エリアとして第１エリアを設定して１回目の選定を行う。この１回目の選定で救助者の中に医療従事者が含まれていない場合には、探索エリアとして第１エリアよりも広い第２エリアを設定して２回目の選定を行うことが好ましい。この場合には、医療従事者が見つかる可能性が高まる。エリアの設定は、例えば、１回目は徒歩圏内、２回目は所定時間内に車両で移動できる範囲に広げる。

地図情報において、要救助者の現在位置に向かっていると判定された救助者と、要救助者の現在位置に向かっていないと判定された救助者とを識別可能に表示することが好ましい。この場合には、救助に向かっているか否かが確認し易くなる。

さらに、複数の救助者間の連絡を可能にする連絡機能を備えていることが好ましい。この場合には、複数人の救助者の協力が簡単に得られる。これにより、例えば、画面上に表示される任意の救助者と連絡がとれ、例えば、ＡＥＤなど救助に必要な物資の依頼が可能となる。

本発明の救助要請支援装置の作動方法は、位置情報取得ステップと、地図情報作成ステ
ップと、地図情報配信ステップと、救助者選定ステップと、救助要請通知送信ステップと、判定ステップとを救助要請支援装置に実行させる。位置情報取得ステップは、救助要請が出された要救助者と要救助者の救助要請を受けた救助者のそれぞれが携帯する携帯端末から、要救助者及び救助者の現在位置を表す位置情報を取得する。また、位置情報取得ステップは、予め登録されたユーザが携帯する携帯端末からの情報に基づいて、ユーザの位置情報を取得する。地図情報作成ステップは、要救助者及び救助者の現在位置をマッピングした地図情報を作成する。地図情報には、予め登録された登録情報に基づいて救助者が医療従事者であるか否かを示す識別マークが表示される。地図情報配信ステップは、地図情報を、救助者の携帯端末に配信する。救助者選定ステップは、要救助者の現在位置に基づいて、ユーザの中から救助者を選定する。救助要請通知送信ステップは、選定された救助者に対して救助要請通知を送信する。判定ステップは、救助要請通知を受信した救助者が、要救助者の現在位置に向かっているか否かを判定する。そして、要救助者の現在位置に向かっていないと判定された救助者の中に、医療従事者がいる場合には、医療従事者に対して救助要請通知を再送信する。

本発明の救助要請支援プログラムは、位置情報取得ステップと、地図情報作成ステップと、地図情報配信ステップと、救助者選定ステップと、救助要請通知送信ステップと、判定ステップとをコンピュータに実行させる。位置情報取得ステップは、救助要請が出された要救助者と要救助者の救助要請を受けた救助者のそれぞれが携帯する携帯端末から、要救助者及び救助者の現在位置を表す位置情報を取得する。また、位置情報取得ステップは、予め登録されたユーザが携帯する携帯端末からの情報に基づいて、ユーザの位置情報を取得する。地図情報作成ステップは、要救助者及び救助者の現在位置をマッピングした地図情報を作成する。地図情報には、予め登録された登録情報に基づいて救助者が医療従事者であるか否かを示す識別マークが表示される。地図情報配信ステップは、地図情報を、救助者の携帯端末に配信する。救助者選定ステップは、要救助者の現在位置に基づいて、ユーザの中から救助者を選定する。救助要請通知送信ステップは、選定された救助者に対して救助要請通知を送信する。判定ステップは、救助要請通知を受信した救助者が、要救助者の現在位置に向かっているか否かを判定する。そして、要救助者の現在位置に向かっていないと判定された救助者の中に、医療従事者がいる場合には、医療従事者に対して救助要請通知を再送信する。

本発明の救助要請支援システムは、救助要請が出された要救助者及び要救助者の救助要請を受けた救助者がそれぞれ携帯する携帯端末と、救助要請支援装置とを備えた救助要請支援システムであり、救助要請支援装置は、位置情報取得部と、地図情報作成部と、地図情報配信部と、救助者選定部と、救助要請通知送信部と、判定部とを備えている。位置情報取得部は、携帯端末から、要救助者及び救助者の現在位置を表す位置情報を取得する。また、位置情報取得部は、予め登録されたユーザが携帯する携帯端末からの情報に基づいて、ユーザの位置情報を取得する。地図情報作成部は、要救助者及び救助者の現在位置をマッピングした地図情報を作成する。地図情報には、予め登録された登録情報に基づいて救助者が医療従事者であるか否かを示す識別マークが表示される。地図情報配信部は、地図情報を救助者の携帯端末に配信する。救助者選定部は、要救助者の現在位置に基づいて、ユーザの中から救助者を選定する。救助要請通知送信部は、選定された救助者に対して救助要請通知を送信する。判定部は、救助要請通知を受信した救助者が、要救助者の現在位置に向かっているか否かを判定する。そして、要救助者の現在位置に向かっていないと判定された救助者の中に、医療従事者がいる場合には、医療従事者に対して救助要請通知を再送信する。

本発明によれば、要救助者の現在位置に医療従事者をより迅速に救助に向かわせることが可能な救助要請支援装置、方法、プログラム及びシステムを提供することができる。

携帯端末及び救助要請支援サーバからなる救助要請支援システムの説明図である。 コンピュータの概略構成を示すブロック図である。 携帯端末の機能ブロック図である。 携帯端末の操作画面の遷移を示す説明図である。 救助要請支援サーバの機能ブロック図である。 救助要請の地図情報の一例を示す説明図である。 救助要請通知画面の一例を示す説明図である。 救助要請支援システムの全体の処理を示すフローチャートである。 救助者の中に医療従事者がいない時の救助要請通知の一例を示す説明図である。 エリアを順次拡大して医療従事者を探索する第２実施形態の説明図である。 救助可能か否かの意志表示確認のボタンを有する救助要請通知の一例を示す説明図である。 救助可能か否かの意志表示確認により、救助者マークの表示色を変更する例における処理を示すフローチャートである。 救助者の移動方向に基づき救助に向かっているか否かを判定し、救助者マークの表示色を変更する例における処理を示すフローチャートである。 移動方向を示す矢印を用いて、救助者が救助に向かっているか否かを表示する地図情報の一例を示す説明図である。 救助に向かっていない医療従事者がいる場合に、救助要請通知を再送信する別実施形態のフローチャートである。 救助者同士で連絡する別実施形態の地図情報の一例を示す説明図である。 複数の救助者が重なり表示される場合に、医療従事者を優先表示する地図情報の一例を示す説明図である。 医療従事者を職業別に表示する地図情報の一例を示す説明図である。 要救助者マークを操作して、処方薬、通院先等を表示させる地図情報の変形例を示す説明図である。 救助要請を受けた段階で全ユーザの携帯端末の現在位置情報を取得して救助者を選定する変形例を示すフローチャートである。

［第１実施形態］
図１に示すように、救助要請支援システム１０は、携帯端末１１，１２と通信可能な救助要請支援サーバ（救助要請支援装置）１４とで構成される。救助要請支援サーバ１４は、予め登録されたユーザに対して、ネットワーク１６を介して救助要請支援のアプリケーションサービスを提供する。

予め登録されたユーザは、携帯端末１１、１２を保有するユーザであり、救助要請支援サーバ１４が提供するアプリケーションサービスの利用登録をしたユーザである。救助要請支援のアプリケーションサービスは、ユーザに緊急事態が発生した場合に、ユーザの近くにいる別のユーザに対して救助要請通知を送信してもらえるサービスである。

具体的には、ユーザに緊急事態が発生して、そのユーザや周囲の者が救助要請を出して要救助者Ｐ１となった場合に、要救助者Ｐ１は、要救助者Ｐ１が保有する携帯端末１１から救助要請支援サーバ１４に対して救助要請要求を送信する。救助要請支援サーバ１４は、救助要請要求を受け付けると、要救助者Ｐ１以外のユーザの中から、要救助者Ｐ１の現在位置の近くの別のユーザを救助者Ｐ２として選定して、救助要請通知を送信する。ここで、緊急事態とは、突発的な持病の発作、事故等によって、ユーザに体調の異変や傷害が生じた場合をいう。また、救助者Ｐ２は要救助者Ｐ１の救助要請を受けた者をいう。

救助者Ｐ２の携帯端末１２が救助要請通知を受けると、携帯端末１２には、救助要請通知画面３６が表示される。救助要請通知画面３６には、要救助者Ｐ１の救助要請があったこと、要救助者Ｐ１の近くの人の救助を請う旨を含むメッセージと、要救助者Ｐ１の現在位置とが含まれる。現在位置は、テキストによる住所表示に加えて、地図情報４９の形態で表示される。

また、救助要請支援サーバ１４は、ユーザからの救助要請要求を受け付けた場合に、別のユーザに救助要請通知を送信することに加えて、消防指令センタに対して緊急通報を行って、医療従事者である救急隊の出動を要請する緊急通報サービスを提供してもよい。

緊急通報サービスとは別に、救助要請支援のアプリケーションサービスを提供するメリットは次のとおりである。すなわち、緊急通報を行っても、救急隊の出動場所である消防署が、要救助者Ｐ１の現在位置から離れている場合には、現場に救急隊が到着するまでに時間を要する。そのため、救助要請支援サーバ１４が提供するアプリケーションサービスを利用して、要救助者Ｐ１の近くにいるユーザに救助要請を行うことで、救急隊が到着するまでの間に、救助者Ｐ２による迅速な救助が可能となる。また、救助要請支援サーバ１４が、消防指令センタに対する緊急通報を行うサービスを提供しない場合でも、救助要請通知を受けた救助者Ｐ２によって緊急通報や医療従事者の手配をしてもらうことも可能となる。

なお、ユーザは、潜在的に要救助者Ｐ１や救助者Ｐ２となる可能性を有している。携帯端末１１の保有者が救助者Ｐ２になる場合や、携帯端末１２の保有者が要救助者Ｐ１となる場合もあるが、本例では、説明の便宜上、携帯端末１１を保有するユーザが要救助者Ｐ１となり、携帯端末１２を保有するユーザが救助者Ｐ２になる例で説明する。

携帯端末１１，１２は、例えば、小型のコンピュータで構成される。一般的なコンピュータの概略構成は、図２に示すようなものであり、携帯端末１１，１２の基本的な構成も同様である。図２に示すように、コンピュータは、ＣＰＵ（Central Processing Unit）２１、メモリ２２、ストレージデバイス２３、通信Ｉ／Ｆ２４、及び入出力部２６を備えている。これらはデータバス２７を介して接続されている。入出力部２６は、ディスプレイ２８と、操作キーなどの入力デバイス２９とからなる。ディスプレイ２８は、例えば、タッチパネル式のディスプレイであり、ディスプレイ２８は入力デバイス２９としても機能する。

ストレージデバイス２３は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive)であり、制御プログラムやアプリケーションプログラム（以下、ＡＰという）３０が格納される。携帯端末１１，１２の場合には、ストレージデバイス２３は例えばＳＳＤである。

メモリ２２は、ＣＰＵ２１が処理を実行するためのワークメモリであり、ＲＡＭ（Random Access Memory）で構成される。ＣＰＵ２１は、ストレージデバイス２３に格納された制御プログラムをメモリ２２へロードして、プログラムに従った処理を実行することにより、コンピュータの各部を統括的に制御する。

通信Ｉ／Ｆ２４は、ネットワーク１６との間の伝送制御を行うネットワークインタフェースである。携帯端末１１，１２の場合には、通信Ｉ／Ｆ２４は、例えば、無線通信モジュールであり、ネットワーク１６は、移動体通信網、無線ＬＡＮなどである。

図３に示すように、携帯端末１１、１２には、救助要請支援サーバ１４のアプリケーションサービスを利用するためのＡＰ３０として、救助要請支援ＡＰ３０がインストールされる。救助要請支援ＡＰ３０は、要救助者Ｐ１の携帯端末１１として救助要請要求を送信する機能と、救助者Ｐ２の携帯端末１２として救助要請通知を受信する機能の両方を実現するプログラムである。そのため、以下において、救助要請支援ＡＰ３０によって実現される機能については、携帯端末１１、１２の区別なく、まとめて説明を行う。

ここで、携帯端末１１，１２に使用されるコンピュータの構成については、後述する救助要請支援サーバ１４のコンピュータの構成（図５参照）と区別するため、説明の便宜上、例えば、ＣＰＵ２１Ａというように、数字の符号に英文字の「Ａ」を付して示す。

救助要請支援ＡＰ３０Ａは、例えば救助要請支援サーバ１４を運営する事業者から提供を受けてダウンロードすることができる。ダウンロード後に、救助要請支援ＡＰ３０Ａが実行されると、携帯端末１１，１２のＣＰＵ２１Ａは、ＧＵＩ（Graphical User Interface）制御部３２、設定部３３、救助要請送受信部３４、及び位置情報取得部３５として機能する。これら各部が連動することにより、携帯端末１１，１２は、救助要請支援のアプリケーションサービスの利用が可能になる。具体的には、サービスの利用に必要なユーザ情報の設定や、救助要請支援サーバ１４に対する救助要請要求の送信や、救助要請支援サーバ１４からの救助要請通知の受信等が可能になる。

図３に示すように、ＧＵＩ制御部３２は、ディスプレイ２８Ａに操作画面を表示し、操作画面を通じて各種操作指示を受け付ける。設定部３３は、ＧＵＩ制御部３２を介して入力されたユーザ情報４８の登録処理を実行する。ユーザ情報４８は、ストレージデバイス２３Ａに格納された後、救助要請支援サーバ１４に対して送信されて、救助要請支援サーバ１４において登録される。この際に、救助要請支援サーバ１４からユーザＩＤが発行される。発行されたユーザＩＤはユーザ情報４８に記録される。登録されたユーザの携帯端末１１、１２と救助要請支援サーバ１４との間で通信が行われる際には、各携帯端末１１、１２からユーザＩＤが救助要請支援サーバ１４に送信される。ユーザＩＤによって、救助要請支援サーバ１４は、ユーザを識別する。

図４に示すように、ＧＵＩ制御部３２が制御する操作画面は、例えば、初期画面５０、起動画面５２、設定登録画面５６などからなる。初期画面５０には、メール、ブラウザ、カレンダ、地図などの各種のアプリケーションのアイコン５１が表示される。救助要請支援ＡＰ３０Ａがインストールされている場合には、アイコン５１の１つとして、救助要請支援ＡＰ３０Ａを起動するアイコン５１が表示される。初期画面５０においてアイコン５１が操作されると、初期画面５０から、救助要請支援ＡＰ３０Ａの起動画面５２に遷移する。

起動画面５２には、設定ボタン５３、救助要請ボタン５４が設けられている。起動画面５２において、設定ボタン５３が操作されると、設定登録画面５６が表示される。設定登録画面５６には、ユーザ情報の入力を促すメッセージが表示されるとともに、ユーザ情報を入力する入力欄Ｈ１や、入力されたユーザ情報を救助要請支援サーバ１４に対する登録を実行する登録ボタン５７が設けられている。

入力欄Ｈ１への入力に際しては、画面上にテンキー等の文字や英数字などの文字入力パッドが一部に表示（図示省略）され、ユーザ情報の入力が可能になる。登録するユーザ情報の項目には、氏名、性別、年齢、携帯電話番号、メールアドレス、職業、医療従事者か否かの情報、救助要請受諾可否の情報などがあり、入力欄Ｈ１はこれらの項目に区画されている。医療従事者か否かの情報は、職業が医師や看護師などの医療従事者であるか否かの情報である。救助要請受諾可否の情報は、救助要請が有った場合に救助者Ｐ２として活動することが可能かどうかのユーザの意思を示す情報である。救助要請受諾可否の情報が、「否」のユーザは、救助要請通知の対象から除外される。

設定部３３は、設定登録画面５６を通じて入力されるユーザ情報を受け付けて、ストレージデバイス２３Ａにユーザ情報４８を格納する。登録ボタン５７が操作されると、設定部３３は、ストレージデバイス２３Ａ内のユーザ情報４８を読み出して、ユーザ情報４８の登録要求を救助要請支援サーバ１４に送信する。こうして、携帯端末１１、１２から救助要請支援サーバ１４に対するユーザ情報４８の登録が行われる。

起動画面５２において、救助要請ボタン５４は、救助要請要求の送信を指令する操作ボタンである。救助要請ボタン５４が操作されると、ＧＵＩ制御部３２を介して、操作指示が救助要請送受信部３４に入力される。

図３において、救助要請送受信部３４は、救助要請ボタン５４の操作に基づいて、救助要請要求を送信する処理を行う。また、救助要請送受信部３４は、救助要請支援サーバ１４からの救助要請通知を受信する。ＧＵＩ制御部３２は、救助要請通知を受信した場合に、救助要請通知画面３６をディスプレイ２８Ａに表示する。

位置情報取得部３５は、ＧＰＳ方式や基地局方式等によって携帯端末１１、１２の現在位置を表す位置情報を取得する。位置情報取得部３５は、救助要請支援サーバ１４に対して、定期的に携帯端末１１、１２の位置情報を送信する。救助要請要求、救助要請通知、位置情報、ユーザ情報４８など、救助要請支援サーバ１４との間で行われる情報の送受信は、通信Ｉ／Ｆ２４Ａ及びネットワーク１６を介して行われる。

救助要請支援サーバ１４も、コンピュータであり、基本的な構成は携帯端末１１，１２と同様に図２に示すとおりである。図５に示すように、救助要請支援サーバ１４のストレージデバイス２３Ｂには、救助要請支援サーバプログラム３０Ｂが格納されている。救助要請支援サーバプログラム３０Ｂが実行されると、救助要請支援サーバ１４のＣＰＵ２１Ｂは、要求受付部４１、救助要請通知送信部４２、登録部４３、位置情報取得部４４、及び地図情報作成部４６として機能する。ここで、説明の便宜上、救助要請支援サーバ１４のＣＰＵなどの構成については、携帯端末１１，１２（数字の符号に「Ａ」を付している）のＣＰＵなどの構成と区別するために、数字の符号に「Ｂ」を付す。

要求受付部４１は、携帯端末１１，１２から救助要請要求及び登録要求を受け付けて、受け付けた要求に応じた指示を各部に与える。

登録部４３は、携帯端末１１，１２からの登録要求に基づいて、登録要求に含まれるユーザ情報４８に対してユーザＩＤを付与して、ストレージデバイス２３Ｂに格納された登録情報５８に記録する。登録情報５８は、ユーザＩＤが付与された、複数人分のユーザ情報４８（氏名、性別、年齢、携帯電話番号、職業、医療従事者か否かの情報、救助要請受諾可否の情報）をまとめた情報である。

救助要請受諾可否の情報は、上述のとおり、救助要請通知を受けて救助者Ｐ２になることを受諾するユーザには「可」、受諾しないユーザには「不可」が設定される。本例では、ユーザＩＤが「００４」のユーザは「不可」、他のユーザは「可」が設定されている。

位置情報取得部４４は、各携帯端末１１，１２が定期的に送信される位置情報を取得する。位置情報取得部４４は、取得した位置情報を、ユーザＩＤ毎に現在位置テーブル４５に記憶する。本例では、各携帯端末１１、１２からの位置情報の取得間隔は、例えば３０秒である。また、現在位置テーブル４５には、最新の位置情報に加えて、一定時間例えば５分前までの位置データが記録される。これにより、後述する第３実施形態において、各携帯端末１２の移動方向を把握できるようになっている。

地図情報作成部４６は、要求受付部４１が救助要請要求を受け付けた場合に、要救助者Ｐ１及び救助者Ｐ２の現在位置をマッピングした、図６に示す地図情報４９を作成する。救助要請通知送信部４２は、地図情報４９を含めて救助要請通知を送信する。これにより、救助要請通知の送信先に地図情報４９が配信される。救助要請通知送信部４２は、地図情報配信部として機能する。

図６に示すように、地図情報４９には、例えば、要救助者Ｐ１の現在位置を中心に所定範囲のエリアの地図が表示され、地図上に、要救助者Ｐ１及び救助者Ｐ２の現在位置を示すマークがマッピングされる。

要救助者Ｐ１の現在位置は要救助者マーク６５で表示され、救助者Ｐ２は救助者マーク６６で表示される。本例では、要救助者マーク６５の形態として「×」印が割り当てられ、救助者マーク６６の形態として「○」印が割り当てられている。

さらに、地図情報４９において、救助者Ｐ２については、医療従事者であるか否かを示す識別マークが表示される。医療従事者であるか否かを示す識別マークは、本例では、救助者Ｐ２のうち、医療従事者である救助者Ｐ２に対して、医療従事者であることを示す医療従事者マーク６６Ｍを付与することにより表示される。医療従事者マーク６６Ｍは、救助者マーク６６の「○」印内に「Ｍ」の文字を挿入した形態である。「Ｍ」の文字の有無により、救助者Ｐ２が医療従事者か否かを識別することができる。

また、地図情報４９には、地図情報４９を含む救助要請通知を携帯端末１２で受信した受信者本人を示す本人マーク６６Ｓが表示される。受信者本人も、救助者Ｐ２であるので、本人マーク６６Ｓは、救助者マーク６６の「○」印に、一回り小さい「○」印を追加した二重丸「◎」の形態である。

地図情報４９には、要救助者マーク６５（「×」）、救助者マーク６６（「○」）、医療従事者マーク６６Ｍ（「○内にＭの文字」）、本人マーク６６Ｓ（「◎二重丸」）の各マークが何を示すものかの説明である凡例が表示される。また、地図上にもマークの説明として、要救助者マーク６５の近傍に「要救助者」という文字表示が、本人マーク６８の近傍に「あなたの現在位置」という文字表示が挿入される。こうした凡例や文字表示によって、地図上の各マークが何を示すのかを確認することができる。

地図情報作成部４６は、例えば、次のようにして地図情報４９を作成する。地図情報作成部４６は、まず、要求受付部４１が救助要請を受け付けた場合に、要救助者Ｐ１の現在位置を現在位置テーブル４５から読み出す。そして、地図情報作成部４６は、要救助者Ｐ１の現在位置に基づいて、予め登録されたユーザの中から救助者Ｐ２を選定する。救助者Ｐ２には、要救助者Ｐ１の近くにいるユーザが選定される。

具体的には、地図情報作成部４６は、要救助者Ｐ１の現在位置から所定距離の範囲を探索エリアとして設定する。所定距離の範囲としては、例えば、要救助者Ｐ１の現在位置から半径４００ｍ（おおよそ徒歩５分圏内）の範囲が設定される。そして、現在位置テーブル４５に記録されるユーザの現在位置を参照して、現在位置が探索エリア内のユーザを探索する。さらに、探索エリア内のユーザのうち、登録情報５８を参照して、救助要請受諾可否の情報が「否」のユーザが除外される。こうして抽出したユーザを救助者Ｐ２として選定する。このように、地図情報作成部４６は、救助者選定部として機能する。

救助者Ｐ２を選択した後、地図情報作成部４６は、要救助者Ｐ１の現在位置を中心とした所定範囲のエリア内の地図のデータを図示しない地図サーバから取得する。地図のデータには、地図上の地点毎にＧＰＳ情報などの位置情報が対応付けられている。地図情報作成部４６は、要救助者Ｐ１と救助者Ｐ２の現在位置を、要救助者マーク６５及び救助者マーク６６によってマッピングする。さらに、登録情報５８を参照して、救助者Ｐ２の中に医療従事者がいる場合には、その救助者Ｐ２に対しては、医療従事者マーク６７を追加する。

救助要請通知送信部４２は、地図情報作成部４６が作成した地図情報４９を、救助要請通知に含めて救助者Ｐ２の携帯端末１２に配信する。救助要請通知は、図７に示すように、携帯端末１２において救助要請通知画面３６として表示される。

救助要請通知は、携帯端末１２に対して配信されるため、救助要請通知送信部４２は、救助要請通知を配信に適したデータ形式で作成される。配信に適したデータ形式としては、例えば、ＸＭＬ（Extensible Markup Language）など、ＷＥＢページの作成言語として汎用的なマークアップ言語を使用した形式である。

ＸＭＬデータは、地図情報４９を再現するための命令や、地図上の位置と要救助者Ｐ１及び救助者Ｐ２の現在位置との対応情報や、地図情報４９の素材となるデータの所在を表すＵＲＬ（Uniform Resource Locator）などが記述される。携帯端末１２は、ＸＭＬデータを受信すると、ブラウザソフトがＸＭＬデータを解釈して、地図情報４９を再現する。再現された地図情報４９が、ディスプレイ２８Ａに表示される。

なお、こうした地図情報４９のデータ形式は、一例であり、地図情報作成部４６が、例えばＰＤＦ（Portable Document Format）形式などで地図情報４９を画像データとして作成して、これを配信してもよい。

また、救助要請通知送信部４２は、要救助者Ｐ１の現在位置が変化した場合など地図情報４９の更新が必要な場合には、随時、救助者Ｐ２の携帯端末１２に対して更新情報を配信する。携帯端末１２は、更新情報に基づいてディスプレイ２８Ａに表示中の地図情報４９を更新する。

以下、上記構成による作用について、図８のフローチャートを参照しながら説明する。救助要請支援サーバ１４には、携帯端末１１、１２のユーザ情報４８が登録されて、登録情報５８が格納されている。救助要請支援サーバ１４は、位置情報取得ステップとして、登録されたユーザの携帯端末１１、１２から定期的に位置情報を取得して、現在位置テーブル４５に記録する（ＳＴ１０，ＳＴ１１）。

携帯端末１１のユーザに緊急事態が発生して、そのユーザが要救助者Ｐ１となった場合には、要救助者Ｐ１は携帯端末１１において救助要請支援ＡＰ３０を起動して、図４に示す起動画面５２から救助要請ボタン５４を操作する。これにより、携帯端末１１から救助要請支援サーバ１４に救助要請要求が送信される（ＳＴ１２）。

救助要請支援サーバ１４は、救助要請要求を受信（ＳＴ１３）すると、要救助者Ｐ１の現在位置に基づいて、要救助者Ｐ１の近くにいる救助者Ｐ２を選定する（ＳＴ１４）。そして、地図情報作成部４６において、地図情報作成ステップとして、要救助者Ｐ１及び救助者Ｐ２の現在位置がマッピングされる地図情報４９が作成される（ＳＴ１５）。地図情報４９において、医療従事者である救助者Ｐ２には医療従事者マーク６７が含まれるため、救助者Ｐ２が医療従事者か否かの識別が可能となる。

救助要請支援サーバ１４は、地図情報配信ステップとして、救助要請通知送信部４２によって地図情報４９を含む救助要請通知を、選定された救助者Ｐ２の携帯端末１２に送信する（ＳＴ１６）。救助者Ｐ２の携帯端末１２は、救助要請通知を受信（ＳＴ１７）すると、ディスプレイ２８Ａに地図情報４９を含む救助要請通知画面３６を表示（ＳＴ１８）する。携帯端末１２のユーザである救助者Ｐ２は、救助要請通知画面３６を見て、要救助者Ｐ１の現在位置を確認することができる。これにより、救助者Ｐ２は、近くにいる要救助者Ｐ１の救助に向かうことができる。

また、図６に示すように、救助要請通知画面３６（図１参照）内の地図情報４９には、通知を受信した受信者本人以外の救助者Ｐ２も救助者マーク６６によって表示されるので、何人の救助者Ｐ２が要救助者Ｐ１の周辺にいるのかを確認することができる。加えて、救助者Ｐ２が医療従事者である場合には医療従事者マーク６７が表示されるため、救助者Ｐ２の中に医療従事者が含まれているか否かも確認することができる。

地図情報４９において救助者Ｐ２が医療従事者であるか否かを示すことによって、次のようなメリットがある。まず、要救助者Ｐ１の救助を適切に行うためには、救助者Ｐ２の中に医療従事者がいることが望まれる。そのため、地図情報４９において救助者Ｐ２の中に医療従事者がいない場合には、救助要請通知を受信する各救助者Ｐ２に対して、医療従事者の早急な手配が必要な状況であることを理解させることができる。

これにより、救助要請通知を受けた各救助者Ｐ２が自らの周囲で医療従事者を探したり、自らの人的なネットワークなどを頼って医療従事者を手配するといった行動を起こす強い動機付けを与えることができる。また、救助要請通知を受けた受信者本人が医療従事者である場合には、救助者Ｐ２の中に医療従事者がいない現状を知るせることで、医療従事者の使命感に訴えて、救助に向かわせる強い動機付けを与えることができる。

上述のとおり、緊急通報を行っても、救急隊の出動場所（消防署）が要救助者Ｐ１の現在位置から離れている場合には、現場に救急隊が到着するまでに時間が掛かる場合がある。また、救助要請支援サーバ１４の救助要請通知の送信対象は、登録されたユーザに限定されているため、要救助者Ｐ１の近くにいるユーザに医療従事者がいなければ、救助要請通知を送信することができない。そのような場合でも、地図情報４９の医療従事者マーク６７により、要救助者Ｐ１の近くの救助者Ｐ２の中に医療従事者が存在するか否かを知らせることで、各救助者Ｐ２に医療従事者の手配に関して協力を要請することができる。

つまり、救急隊が到着するまでに時間が掛かる場合や、救助要請支援サーバ１４による救助要請通知の送信対象に医療従事者がいない場合でも、医療従事者の手配に関して各救助者Ｐ２の手を借りることが可能になる。これにより、要救助者Ｐ１の現在位置に医療従事者をより迅速に救助に向かわせることが可能になる。

また、地図情報４９において救助者Ｐ２の中に医療従事者がいる場合には、それを各救助者Ｐ２が確認することにより、各救助者Ｐ２が協力しやすい状況になると考えられる。というのも、救助者Ｐ２の中には、要救助者Ｐ１の救助に向かう決断をするに当たって、例えば、救助に際して自分に何ができるだろうか、果たして役に立つだろうかなどといった、心理的な負担を感じる人が多いと考えられる。そのような場合に、救助者Ｐ２の中に医療従事者がいることが確認できれば、例えば、医療従事者でない救助者Ｐ２は医療従事者の指示の下であれば、何か役に立つかもしれないと考えることができる。このため、救助者Ｐ２の心理的な負担が軽減されて、救助に向かう決断をしやすくなる。これにより救助者Ｐ２の協力が得られやすい状況になる。

本例において、図６の地図情報４９において示した、要救助者マーク６５、救助者マーク６６、医療従事者マーク６７、本人マーク６８の形態は一例であり、形状、色、模様、それらの組み合わせなど各種のものが考えられる。それぞれが識別できれば、どのような形態でもよい。

また、本例では、地図情報４９を、救助要請通知の送信先である選定された救助者Ｐ２に対して配信している。救助要請通知に地図情報４９を含めることで、救助者Ｐ２に救助に必要な有益な情報を提供することができる。

なお、地図情報４９を、救助要請通知の送信先以外のユーザが閲覧できるようにしてもよい。この場合には、例えば、登録されたユーザから救助要請支援サーバ１４に閲覧要求があった場合に、救助要請支援サーバ１４が閲覧要求元のユーザに地図情報４９を配信する。これによれば、探索エリア外のユーザでも地図情報４９を確認することが可能となる。地図情報４９の閲覧人数が増えれば、救助に向かう人数が増える可能性も高まる。

また、図９に示す救助要請通知画面３６のように、救助要請のメッセージＭＳＧ１以外のメッセージを含めてもよい。例えば、通知時点において、救助者Ｐ２の中に医療従事者がいるかいないかの状況や、救助者Ｐ２（通知を受けた受信者本人）の知り合いや近くに医療従事者がいたら、救助要請をして欲しい旨の依頼内容を示すメッセージＭＳＧ２を含める。こうすれば、救助者Ｐ２に対して、医療従事者の手配に関する協力要請の意図を明確に伝えることができる。

［第２実施形態］
第１実施形態では、救助者Ｐ２の探索エリアについて、要救助者Ｐ１の現在位置からの距離が固定された１つの範囲を設定する例で説明している。これに対して、図１０に示す第２実施形態は、探索エリアに医療従事者が見つからない場合には、探索エリアを段階的に拡大していく例である。

具体的には、図１０に示すように、救助要請支援サーバ１４において、地図情報作成部４６（救助者選定部として機能する）は、要救助者Ｐ１の現在位置に基づいて、救助者Ｐ２の探索エリアとして第１エリアＡ１を設定する。そして、現在位置テーブル４５を参照して、Ａ１内の登録されたユーザを検索して、救助者Ｐ２の１回目の選定を行う。地図情報作成部４６は、医療従事者か否かに関わらず、検索されたユーザを救助者Ｐ２として選定する。そして、登録情報５８を参照して、１回目の選定で選定された救助者Ｐ２の中に医療従事者が含まれているか否かを判定する。

地図情報作成部４６は、医療従事者が含まれている場合には、その段階で救助者Ｐ２の選定を終了する。医療従事者が含まれていない場合には、探索エリアとして第１エリアＡ１よりも広い第２エリアＡ２を設定して２回目の選定を行う。地図情報作成部４６は、こうした手順を繰り返して、Ａ２、Ａ３、Ａ４というように探索エリアを段階的に拡大する。このように探索エリアを段階的に拡大することで、医療従事者を救助者Ｐ２として選定できる可能性が高まる。図１０の例では、第４エリアＡ４内に医療従事者が存在するため、探索エリアの拡大は第４エリアＡ４で終了する。医療従事者が見つからない場合でも、探索エリアの拡大は予め設定された上限値に達した段階で終了する。

第１エリアＡ１〜第４エリアＡ４は、例えば次のような範囲である。第１エリアＡ１は要救助者Ｐ１の現在位置から半径４００ｍ（おおよそ徒歩５分圏内）の範囲であり、第２エリアＡ２は、要救助者Ｐ１の現在位置から半径８００ｍ（おおよそ徒歩１０分圏内）の範囲である。第３エリアＡ３は、要救助者Ｐ１の現在位置から半径１２００ｍ（おおよそ徒歩１５分圏内）の範囲である。第４エリアＡ４は、要救助者Ｐ１の現在位置から半径６ｋｍ圏内であり、自転車、バイク、自動車等の車両を用いて１０分で到着が可能な車両移動圏内である。救急隊の到着に長時間を要する場合には、探索エリアを第４エリアＡ４のように車両移動圏内に拡大して医療従事者を探すメリットもある。探索エリアの大きさや拡大回数は本例に限らず、適宜変更が可能である。

［第３実施形態］
図１１〜図１５に示す第３実施形態は、救助要請通知を受信した各救助者Ｐ２が実際に要救助者Ｐ１の現在位置に向かっているか否かを判定する機能、言い換えれば、要救助者Ｐ１の救助に向かっているか否かを判定する機能を備えた形態である。

この判定機能は、例えば、図１２〜図１４に示すように、地図情報４９において、要救助者Ｐ１の現在位置に向かっていると判定された救助者Ｐ２と、要救助者Ｐ１の現在位置に向かっていないと判定された救助者Ｐ２とを識別可能に表示するために利用される。

救助者Ｐ２が要救助者Ｐ１の現在位置に向かっているか否かの判定は、例えば、救助者Ｐ２の救助の意思を確認することにより行う。具体的には、図１１に示すように、救助要請通知画面３６に、救助者Ｐ２の意思を救助要請支援サーバ１４に伝えるための操作ボタンとして、救助可能ボタン７２及び救助不可ボタン７３を設ける。救助者Ｐ２は救助に向かう意思がある場合は救助可能ボタン７２を操作して、意思が無い場合は救助不可ボタン７３を操作する。各ボタン７２、７３の操作により、それぞれに応じた意思を表す意思表示が、救助要請支援サーバ１４に送信される。

救助要請支援サーバ１４において、受信した意思表示は、地図情報作成部４６に送られる。図１２のフローチャートに示すように、地図情報作成部４６は、意思表示の受信を待機しており、意思表示を受信した場合には、意思表示の内容（「救助可」あるいは「救助不可」）を判定する。このように、地図情報作成部４６は、受信した意思表示に基づいて、救助者Ｐ２が、要救助者の現在位置に向かっているか否かを判定する判定部として機能する。

地図情報作成部４６は、意思表示の内容に応じて地図情報４９内の救助者マーク６６の表示を更新する。「救助可」の意思表示があった救助者Ｐ２に対応する救助者マーク６６の表示色を「緑」、「救助不可」の意思表示があった救助者Ｐ２に対応する救助者マーク６６の表示色を「赤」というように、救助者マーク６６の表示色を変更する。

なお、救助に向かっているか否かの表示は、表示色を変更する代わりに、または加えて、救助者マーク６６の形状を変更したり、点滅表示にしたり、「移動中」などの表示の追加により行ってもよい。このように表示色等を変更した場合には、その意味が分かるような凡例を表示することが好ましい。

また、図１３に示すように、救助者Ｐ２が要救助者Ｐ１の現在位置に向かっているか否かの判定は、地図情報作成部４６が、救助者Ｐ２の携帯端末１２から定期的に送信される位置情報に基づいて行ってもよい。上述のとおり、現在位置テーブル４５には、最新の位置情報に加えて、一定時間例えば５分前までの位置データが記録される。地図情報作成部４６は、現在位置テーブル４５を参照する。そして、位置データの経時変化に基づいて各携帯端末１２の移動方向を把握する。把握した移動方向に基づいて、救助者Ｐ２毎に、要救助者Ｐ１の現在位置に向かっているか否かを判定する。この判定結果に基づいて、救助者マーク６６の表示色を変更する。

また、救助者マーク６６の表示色を変更することに加えて、または、代えて、図１４に示すように、移動方向を地図情報４９に表示してもよい。移動方向は、現在位置テーブル４５の位置データに基づいて判定することできる。地図情報作成部４６は、地図情報４９において、判定した移動方向を示す移動方向マーク８１を、救助者Ｐ２毎の救助者マーク６６に追加する。なお、位置データの経時変化から、要救助者Ｐ１の現在位置に向かっている救助者Ｐ２のおおよその移動速度も算出できるので、マーク８１の長さを変化させるなどの方法により移動速度を表示してもよい。

また、救助者Ｐ２が要救助者Ｐ１の現在位置に向かっているか否かの判定機能を別の目的に利用してもよい。例えば、図１５に示すように、救助者Ｐ２の中に、要救助者Ｐ１の現在位置に向かっていない医療従事者がいるか否かを判定して、向かっていない医療従事者がいる場合には、その医療従事者に対して救助要請通知を再送信する。

判定部として機能する地図情報作成部４６は、現在位置テーブル４５を参照して、救助者Ｐ２の移動方向を把握する。そして、救助者Ｐ２の中に医療従事者がいる場合には、その医療従事者の移動方向に基づいて、要救助者Ｐ１の現在位置に向かっているか否かを判定する。現在位置に向かっていない、つまり、要救助者Ｐ１の救助に向かっていない場合には、救助要請通知を再送信する。再送信により、医療従事者に対して救助の必要性を強く訴えることができる。

［第４実施形態］
図１６に示す第４実施形態は、複数の救助者Ｐ２間の連絡を可能にする連絡機能を備えた形態である。この場合には、図１６に示すように、携帯端末１２の救助要請通知画面８３において、連絡のための操作ツール８４を表示する。

操作ツール８４は、救助要請通知画面８３において、救助者Ｐ２を示す救助者マーク６６（医療従事者マーク６６Ｍを含む）を操作することで、開かれる。操作ツール８４には、通話ボタン８５、メールボタン８６が設けられている。通話ボタン８５が操作されると、救助要請支援サーバ１４の登録情報５８から対応する要救助者Ｐ１の携帯電話番号が表示され、それを選択操作することで、救助者Ｐ２間で通話が可能になる。通話は、電話会社が提供する移動体通信網を介して行われる。もちろん、インターネットを利用した電話サービスにより通話が行われてもよい。

また、メールボタン８６が操作されると、メッセージ入力画面（図示せず）が開き、メッセージの入力が可能になる。救助者マーク６６の選択によりメールには、メールアドレスが自動的に挿入される。メッセージの入力が完了すると、メールが送信される。メールの送信は、救助要請支援サーバ１４経由で行ってもよいし、携帯端末１２のユーザが加入している別のインターネット接続業者のサーバ経由で行ってもよい。

このような救助者Ｐ２間の連絡機能を設けることで、救助者Ｐ２の内、例えば医療従事者がＡＥＤ（Automated External Defibrillator）などの救助に必要な物資の運搬を他の救助者Ｐ２に依頼したり、逆に医療従事者に救助物資の運搬が必要かどうか問い合わせしたりすることが可能になる。このようにして複数の救助者Ｐ２の協力が簡単に可能になる。

また、要救助者Ｐ１の現在位置に最初に到着した救助者Ｐ２が、救助に向かっている医療従事者に電話連絡して、要救助者Ｐ１の容態を伝えて、その対処方法を聞くといったことも可能になる。

［第５実施形態］
図１７に示す第５実施形態では、地図情報４９において、複数の救助者Ｐ２の現在位置の表示である救助者マーク６６が重なって表示されている場合に、医療従事者を優先的に表示する形態である。

優先的に表示する形態としては、例えば、重なっている救助者マーク６６のうち、医療従事者の医療従事者マーク６６Ｍを一番上に表示して、医療従事者の存在が目立つように表示する。この場合には、複数の救助者Ｐ２が近接している場合でも医療従事者の存在を確認しやすい。さらに、図１７において、丸数字で示すように、重なっている救助者Ｐ２の総数を数字で表示してもよい。例えば、３人が重なって表示されている場合には、最上層の救助者Ｐ２に３人が重なって表示されていることを示す「３」の丸数字が付加される。こうすれば、重なっている救助者Ｐ２の総数が確認しやすい。

こうした処理は、地図情報作成部４６によって行われる。地図情報作成部４６は、現在位置テーブル４５を参照して複数の救助者Ｐ２の現在位置を把握する。現在位置に基づいて近接している複数の救助者Ｐ２の有無を判定する。さらに、近接している複数の救助者Ｐ２がいる場合には、登録情報５８に基づいてその中に医療従事者がいるかいないかを判定する。医療従事者がいる場合には医療従事者マーク６６Ｍが最上位に位置するように優先表示を行う。

［第６実施形態］
上記実施形態では、単に医療従事者か否かを示す表示を行っているが、第６実施形態では、地図情報４９において、医療従事者をさらに細分化して、医師、看護師、救急救命士といった職種まで識別可能にする形態である。

図１８に示すように、医療従事者マーク６６Ｍは、医者を示す医者マーク６６Ｍ１、看護師を示す看護師マーク６６Ｍ２、救急救命士を示す救急救命士マーク６６Ｍ３に分類される。これらのマーク６６Ｍ１〜６６Ｍ３は、医者、看護師、救急救命士のいずれかを示す識別マークとして機能する。各マーク６６Ｍ１、６６Ｍ２、６６Ｍ３は、それぞれ、医者は「Ｄ」、看護師は「Ｎ」、救急救命士は「Ｅ」の文字が○印に挿入された形態である。地図情報４９には、各マーク６６Ｍ１〜６６Ｍ３が何を示すかの凡例を表示することが好ましい。

このように、医療従事者の職業まで表示することで、次のようなメリットがある。一言で医療従事者と言っても、医師、看護師、救命救急士は法律によって、職種毎に作業内容が制限されているので、どの職業の人が向かっているかを知ることは、とても重要である。また、要救助者Ｐ１の現在位置に到着した救助者Ｐ２が、要救助者Ｐ１の容態を確認したところ、要救助者Ｐ１が明らかに重篤な状態であり、救助には医師の力が必要だと判断したとする。その場合に、地図情報４９において、救助者Ｐ２の中に、例えば看護師しかいない場合には、看護師等に連絡をとって医師の救助要請をするといった対応が可能となる。

［第７実施形態］
図１９に示すように、第７実施形態は、地図情報４９において、要救助者マーク６５を操作した時に、要救助者Ｐ１の診療情報を表示する形態である。診療情報は、登録情報５８に予め登録されている。救助要請支援サーバ１４は、この診療情報を救助者Ｐ２の携帯端末に配信する。こうした診療情報の配信は、例えば、救助要請通知送信部４２が担う。

例えば、地図情報４９において、要救助者マーク６５が操作されると、選択画面９６が開く。選択画面９６には、処方薬、通院先、病歴といった診療情報の種類を選択する各ボタン９７〜９９が設けられている。各ボタン９７〜９９が操作されると、処方薬、通院先、病歴といった診療情報の配信要求が救助要請支援サーバ１４に送信される。救助要請支援サーバ１４において、救助要請通知送信部４２は、処方薬の配信要求を受信した場合には、登録情報５８から要救助者Ｐ１が現在服用している処方薬を読み出して要求元の携帯端末１２に配信する。これにより、携帯端末１２において要救助者Ｐ１の処方歴が表示される。同様に、通院ボタン９８を操作することで、病院やクリニック等の通院先が表示される。病歴ボタン９９を操作することで病歴が表示される。

診療情報は秘匿要請が強い個人情報であるため、これらの診療情報の配信要求は医療従事者に限定して許可されることが好ましい。この場合には、救助要請通知送信部４２は、診療情報の配信要求があった場合には、登録情報５８を参照して要求元が医療従事者か否かを判定し、医療従事者と判定した場合にのみ、配信を行う。

なお、このような診療情報は、登録情報５８に登録されていなくもよく、例えば、救助要請支援サーバ１４が、要救助者Ｐ１のかかりつけの病院のサーバにアクセスして、そこから診療情報を取得して、取得した診療情報を配信する形態でもよい。この場合には、例えば、登録情報５８にユーザの通院先の病院ＩＤや患者ＩＤを登録しておく。救助要請支援サーバ１４は、この情報を元に要救助者Ｐ１のかかりつけ病院を特定して、病院に対して患者ＩＤを含めた取得要求を送信する。

また、国民一人一人にユニークな番号を割り当てるマイナンバ制度が将来的に導入された場合には、マイナンバを登録情報５８に登録しておいてもよい。マイナンバがあれば、マイナンバを検索キーとして、複数の病院のサーバにアクセスして、診療情報を取得することも可能となる。

上記各実施形態では、要救助者Ｐ１の救助要請要求を、要救助者Ｐ１の携帯端末１１から救助要請支援サーバ１４に対して送信する例で説明しているが、携帯端末１１と、生体センサとを連動させて救助要請要求のトリガー信号を発信してもよい。例えば、生体センサは、要救助者Ｐ１に装着可能なウェアラブルな生体センサである。生体センサが異常を検知した場合に、生体センサからのトリガー信号に応じて携帯端末１１が救助要請要求の送信を行う。例えば、慢性病患者を定常的に生体センサでモニタリングし、異常値が検知された場合に、携帯端末１１に対してトリガー信号が入力される。携帯端末１１はトリガー信号に基づいて救助要請要求を送信する。

上記各実施形態では、図８に示すように、各携帯端末１１，１２の現在位置を表す位置情報を一定時間毎に常に取得している。これに代えて、図２０のフローチャートに示す変形例のように、要救助者の携帯端末１１が救助要請要求を送信し（ＳＴ２０）、この救助要請要求を救助要請支援サーバ１４が救助要請要求を受信（ＳＴ２１）した後に、携帯端末１１，１２から位置情報の取得を開始してもよい。

この変形例の場合には、救助要請を受けた段階で救助要請支援サーバ１４は要救助者Ｐ１の携帯端末１１を除く携帯端末１２に対して、現在位置取得指令を送信する（ＳＴ２２）。各携帯端末１２はこの現在位置取得指令を受信した時に（ＳＴ２３）、現在位置情報を救助要請支援サーバ１４に送信する（ＳＴ２４）。救助要請支援サーバ１４は送られてきた現在位置情報に基づき、第１実施形態と同様にして、要救助者Ｐ１の現在位置を中心とする一定距離内のユーザのみを救助者Ｐ２として選定する（ＳＴ１４）。選定後は、第１実施形態と同様にして、地図情報を作成し（ＳＴ１５）、この地図情報を含む救助要請通知を選定した救助者Ｐ２に送信する（ＳＴ１６）。救助者Ｐ２の携帯端末１２は、救助要請通知を受信（ＳＴ１７）すると、ディスプレイ２８Ａに地図情報４９を含む救助要請通知画面３６を表示（ＳＴ１８）する。携帯端末１２のユーザである救助者Ｐ２は、救助要請通知画面３６を見て、要救助者Ｐ１の現在位置を確認することができる。これにより、救助者Ｐ２は、近くにいる要救助者Ｐ１の救助に向かうことができる。なお、選定した救助者Ｐ２のみに対して、定期的に現在位置情報を取得して、地図情報４９を更新する。

本変形例の場合には、救助要請を受けた後に他のユーザの現在位置を取得するため、第１実施形態に比べて救助者Ｐ２の選定がその分だけ遅れる可能性がある。しかし、要救助者Ｐ１を中心とする探索エリア外の他のユーザの携帯端末１２に、現在位置情報を定期的に取得させることがなく、救助要請支援サーバ１４や探索エリア外に位置する携帯端末１２の負荷を軽減することができる。

上記救助要請支援サーバ１４や救助要請支援のアプリケーションサービスの運営主体は、民間事業者であってもよいし、地方自治体などの公共団体であってもよい。

救助要請支援サーバ１４のハードウェア構成は種々の変形が可能である。例えば、処理能力や信頼性の向上を目的として、救助要請支援サーバ１４を、ハードウェアとして分離された複数台のサーバコンピュータで構成することも可能である。このように、コンピュータシステムのハードウェア構成は、処理能力、安全性、信頼性など要求される性能に応じて適宜変更することができる。さらに、ハードウェアに限らず、プログラムについて、安全性や信頼性の確保を目的として、二重化したり、あるいは、複数のストレージデバイスに分散して格納したりしてもよい。

本発明は、上記実施形態や上述した変形例に限らず、本発明の要旨を逸脱しない限り種々の構成を採り得ることはもちろんである。例えば、上記実施形態や上述した変形例を適宜組み合わせることも可能である。また、本発明は、プログラムに加えて、プログラムを記憶する記憶媒体にも及ぶ。

１０ 救助要請支援システム
１１，１２ 携帯端末
１４ 救助要請支援サーバ
３０Ａ 救助要請支援ＡＰ
３０Ｂ 救助要請支援サーバプログラム
３６ 救助要請通知画面
４８ ユーザ情報
４９ 地図情報
６５ 要救助者マーク
６６ 救助者マーク
６７ 医療従事者マーク
６８ 本人マーク
８４ 連絡ツール
８５ 通話ボタン
８６ メールボタン
Ｐ１ 要救助者
Ｐ２ 救助者

Claims (10)

1. 救助要請が出された要救助者と前記要救助者の救助要請を受けた救助者のそれぞれが携帯する携帯端末から、前記要救助者及び前記救助者の現在位置を表す位置情報を取得し、且つ予め登録されたユーザが携帯する携帯端末からの情報に基づいて、前記ユーザの位置情報を取得する位置情報取得部と、
   前記要救助者及び前記救助者の前記現在位置がマッピングされる地図情報であり、かつ、予め登録された登録情報に基づいて前記救助者が医療従事者であるか否かを示す識別マークが表示される前記地図情報を作成する地図情報作成部と、
   前記地図情報を、前記救助者の携帯端末に配信する地図情報配信部と、
   前記位置情報取得部が取得した前記要救助者の現在位置に基づいて、前記ユーザの中から前記救助者を選定する救助者選定部と、
   選定された前記救助者に対して救助要請通知を送信する救助要請通知送信部と、
   前記救助要請通知を受信した前記救助者が、前記要救助者の現在位置に向かっているか否かを判定し、前記要救助者の現在位置に向かっていないと判定された前記救助者の中に、前記医療従事者がいる場合には、前記医療従事者に対して前記救助要請通知を再送信する判定部と
   を備えている救助要請支援装置。
2. 前記医療従事者は、医者、看護師、救急救命士のいずれかであり、前記識別マークは前記医者、看護師、救急救命士を識別するマークである請求項１に記載の救助要請支援装置。
3. 前記地図情報において、複数の前記救助者の現在位置の表示が重なっている場合には、前記医療従事者である前記救助者が優先的に表示される請求項１又は２に記載の救助要請支援装置。
4. 前記地図情報配信部は、前記救助要請通知の送信先に前記地図情報を配信する請求項３に記載の救助要請支援装置。
5. 前記救助者選定部は、前記救助者の探索エリアとして第１エリアを設定して１回目の選定を行い、１回目の選定で選定された前記救助者の中に前記医療従事者が含まれていない場合には、前記探索エリアとして前記第１エリアよりも広い第２エリアを設定して２回目の選定を行う請求項４に記載の救助要請支援装置。
6. 前記地図情報において、前記要救助者の現在位置に向かっていると判定された前記救助者と、前記要救助者の現在位置に向かっていないと判定された前記救助者とを識別可能に表示する請求項５に記載の救助要請支援装置。
7. 複数の前記救助者間の連絡を可能にする連絡機能を備えている請求項６に記載の救助要請支援装置。
8. 救助要請が出された要救助者と前記要救助者の救助要請を受けた救助者のそれぞれが携帯端末から、前記要救助者及び前記救助者の現在位置を表す位置情報を取得し、且つ予め登録されたユーザが携帯する携帯端末からの情報に基づいて、前記ユーザの位置情報を取得する位置情報取得ステップと、
   前記要救助者及び前記救助者の前記現在位置がマッピングされる地図情報であり、かつ、予め登録された登録情報に基づいて前記救助者が医療従事者であるか否かを示す識別マークが表示される前記地図情報を作成する地図情報作成ステップと、
   前記地図情報を、前記救助者の携帯端末に配信する地図情報配信ステップと、
   前記位置情報取得ステップで取得した前記要救助者の現在位置に基づいて、前記ユーザの中から前記救助者を選定する救助者選定ステップと、
   選定された前記救助者に対して救助要請通知を送信する救助要請通知送信ステップと、
   前記救助要請通知を受信した前記救助者が、前記要救助者の現在位置に向かっているか否かを判定し、前記要救助者の現在位置に向かっていないと判定された前記救助者の中に、前記医療従事者がいる場合に、前記医療従事者に対して前記救助要請通知を再送信する判定ステップとを、
   救助要請支援装置に実行させる救助要請支援装置の作動方法。
9. 救助要請が出された要救助者と前記要救助者の救助要請を受けた救助者のそれぞれが携帯端末から、前記要救助者及び前記救助者の現在位置を表す位置情報を取得し、且つ予め登録されたユーザが携帯する携帯端末からの情報に基づいて、前記ユーザの位置情報を取得する位置情報取得ステップと、
   前記要救助者及び前記救助者の前記現在位置がマッピングされる地図情報であり、かつ、予め登録された登録情報に基づいて前記救助者が医療従事者であるか否かを示す識別マークが表示される前記地図情報を作成する地図情報作成ステップと、
   前記地図情報を、前記救助者の携帯端末に配信する地図情報配信ステップと、
   前記位置情報取得ステップで取得した前記要救助者の現在位置に基づいて、前記ユーザの中から前記救助者を選定する救助者選定ステップと、
   選定された前記救助者に対して救助要請通知を送信する救助要請通知送信ステップと、
   前記救助要請通知を受信した前記救助者が、前記要救助者の現在位置に向かっているか否かを判定し、前記要救助者の現在位置に向かっていないと判定された前記救助者の中に、前記医療従事者がいる場合に、前記医療従事者に対して前記救助要請通知を再送信する判定ステップとを、
   コンピュータに実行させることによりコンピュータを救助要請支援装置として機能させる救助要請支援プログラム。
10. 救助要請が出された要救助者と前記要救助者の救助要請を受けた救助者のそれぞれが携帯する携帯端末と、救助要請支援装置とを備えた救助要請支援システムであり、
    前記救助要請支援装置は、
    前記要救助者と前記要救助者の救助要請を受けた救助者のそれぞれが携帯する携帯端末から、前記要救助者及び前記救助者の現在位置を表す位置情報を取得し、且つ予め登録されたユーザが携帯する携帯端末からの情報に基づいて、前記ユーザの位置情報を取得する位置情報取得部と、
    前記要救助者及び前記救助者の前記現在位置がマッピングされる地図情報であり、かつ、予め登録された登録情報に基づいて前記救助者が医療従事者であるか否かを示す識別マークが表示される前記地図情報を作成する地図情報作成部と、
    前記地図情報を、前記救助者の携帯端末に配信する地図情報配信部と、
    前記位置情報取得部が取得した前記要救助者の現在位置に基づいて、前記ユーザの中から前記救助者を選定する救助者選定部と、
    選定された前記救助者に対して救助要請通知を送信する救助要請通知送信部と、
    前記救助要請通知を受信した前記救助者が、前記要救助者の現在位置に向かっているか否かを判定し、前記要救助者の現在位置に向かっていないと判定された前記救助者の中に、前記医療従事者がいる場合には、前記医療従事者に対して前記救助要請通知を再送信する判定部と
    を備えている救助要請支援システム。

Images