JP2004038881A

JP2004038881A - 緊急通報システム及びその方法

Info

Publication number: JP2004038881A
Application number: JP2002198822A
Authority: JP
Inventors: Hiroshi Oshio; 大鹽　拓; Fumihiko Sugiyama; 杉山　文彦; Masami Taniguchi; 谷口　正巳; Masazumi Saito; 斉藤　正純; Katsunori Eguchi; 江口　克則
Original assignee: Individual
Current assignee: Individual
Priority date: 2002-07-08
Filing date: 2002-07-08
Publication date: 2004-02-05

Abstract

【課題】事件や事故への対応を迅速なものとし、救急車患者受け入れ先病院の決定をスムーズにして人命の救護に貢献する緊急通報システム及びその方法を提供する。
【解決手段】事件や事故等の緊急通報の発信側であるＧＰＳ機能を搭載した複数の第１クライアント１と、緊急通報の受信側である複数の第２クライアント２とを、ネットワーク網Ａ上のサーバ３を介して接続し、第１クライアント１から発せられた緊急通報の発信場所をＧＰＳ機能により特定し、当該特定された位置から最短の位置に存在する第２クライアント（警察車両又は救急車両等）を現場へ向かわせる。また、ＧＰＳ機能を搭載した救急車によって、当該救急車の走行位置に最も近い患者受け入れ可能な救急医療施設をサーバ３でリストアップし、救急車に通知することにより、患者のスムーズな搬送を実現する。
【選択図】　　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、緊急情報の受信に基づいて、警察車両や救急車、あるいは民間警備会社の緊急車両等の手配・搬送等の命令を処理する緊急通報システム及びその方法に関する。
【０００２】
【従来の技術】
従来、警察車両や警備会社のパトロールカー、救急車などの緊急車両の出動を要請する場合は、そのほとんどが電話による１１０番通報や１１９番通報等である。このような緊急通報は、一括してオペレーションセンタへ繋がるようになっており、通報を受けたオペレーションセンタでは、担当オペレータが、事件発生現場や状況などの各種情報を聞き出して、パトロールカーや救急車の出動命令を発したリ、巡回中のパトロールカーに対し、その旨を無線連絡して現場へ急行させている。
【０００３】
また、救急車の場合、現場に急行した後、患者や負傷者を乗せて医療機関へ搬送する際、オペレーションセンタから緊急医療機関に対して患者受け入れを打診し、患者の受け入れ先病院を決定している。
【０００４】
【発明が解決しようとする課題】
ところで、１１０番通報を例にとると、現在、日本全国で年間約８４０万件の緊急通報があり、その内訳をみると、４９．３％という約半分の通報が携帯電話からの通報となっている。
このような側面からも、現在、携帯電話機の普及は目覚しいものと言えるが、その反面、現在位置が比較的明確な据置き型の電話機と違い、携帯電話機からの緊急通報は、そのほとんどが外出先での通報となっており、通報者自体が自己の現在位置を要領良く説明できない場合が極めて多い。
【０００５】
このようなことから、緊急車両を手配するオペレーションセンタでは、事件等の発生現場の特定に苦慮しているのが実情で、このことは、位置特定の容易な据置き型の電話機からの通報と比較して、緊急車両の現場到着時間が平均にして約２０秒遅くなっていることが如実に物語っている。特に人命がかかっている場合などは、この初動の遅れは取り返しのつかない事態を招くこととなる。
【０００６】
さらに救急車の場合は、患者を乗せて医療機関へ搬送する際に、情報が錯綜して患者受け入れ先病院の決定に手間どう場合が往々にしてあり、早急に改善する必要がある。
【０００７】
ところで、現在主流の電話システムは、専用交換機を必要とする、いわゆる、Ｐｈｏｎｅ　ｔｏ　Ｐｈｏｎｅ　であるが、昨今、専用交換機を必要としないインターネット経由のＩＰフォンなるものが出現してきている。
このＩＰフォンは、パーソナルコンピュータから電話回線上の電話機への通話が可能なＰＣ　ｔｏ　Ｐｈｏｎｅ　から、さらに進んで、ＰＣ　ｔｏ　ＰＣ　へと変貌を遂げており、これからの通信ツールの主流になるものと期待されている。
【０００８】
全国民的といって良いほど多くの人々に浸透した携帯電話機は、上記した　Ｐｈｏｎｅ　ｔｏ　Ｐｈｏｎｅ　のシステム上のものではあるが、近い将来、ＰＣ　ｔｏ　ＰＣ　のシステム上でのものに取って代わることは時間の問題と言える。もっとも、すでにインターネット接続が可能なＰＤＡなどは、インカムを用いれば、ＰＣ　ｔｏ　ＰＣ　が可能である。
【０００９】
このような状況下において、上述した現在の緊急通報システムは、Ｐｈｏｎｅ　ｔｏ　Ｐｈｏｎｅ　のシステム上で、通報者に対し、全ての情報をオペレータが聞き出すといった人手を介した旧態依然としたシステムであるため、迅速性の向上は、もはや限界であり、しかも今後、ますます携帯電話からの緊急通報が増えることは確実で、上記した「初動の遅れ」の解消は不可能である。
【００１０】
そこで、本発明は、通信ツールの主流がＩＰフォンとなることを見越して、迅速な緊急・救急対応が可能な新規な緊急通報システムを提供することを目的とし、さらに他に目的とする処は、救急車患者受け入れ先病院の決定をスムーズにして、もって、人命の救護に貢献できる救急搬送システム及びその方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
前記課題を解決するために、本発明は、　複数の第１クライアントと、複数の第２クライアントと、がネットワーク上のサーバを介して接続される緊急通報システムであって、前記第１クライアントは、ＧＰＳ機能を備え、緊急通報時に該ＧＰＳ機能により検出された現在位置情報と緊急情報とを前記サーバへ送信し、前記第２クライアントは、ＧＰＳ機能を備え、定期的に該ＧＰＳ機能により検出された位置情報を前記サーバへ送信し、前記サーバは、前記複数の第２クライアントから定期的に送信される位置情報をクライアント毎に更新登録するデータベースを備え、前記第１クライアントから緊急通報時に送信された現在位置情報と前記データベースに更新登録されている前記複数の第２クライアントの位置情報とを比較し、前記第１クライアントの現在位置情報から最も近隣に位置する第２クライアントを選定し、当該選定された第２クライアントへ当該第１クライアントの現在位置情報及び前記緊急情報を送信する、ことを特徴とする。
【００１２】
また、前記サーバは、前記緊急情報及び前記第１クライアントの現在位置情報からなるＷｅｂページを作成し、当該作成されたＷｅｂページのＵＲＬ情報を前記選定された第２クライアントへ送信することを特徴とする。
【００１３】
さらに、前記ネットワークは、ＴＣＰ／ＩＰネットワーク網であり、
前記第１クライアントは、携帯ＩＰフォンであることを特徴とする。
【００１４】
本発明は、複数の第１クライアントと、複数の第２クライアントと、がネットワーク上のサーバを介して接続される緊急通報システムの方法であって、前記第１クライアントは、ＧＰＳ機能を備え、緊急通報時に該ＧＰＳ機能により検出された現在位置情報及び緊急情報を前記サーバへ送信する緊急通報ステップを有し、前記第２クライアントは、ＧＰＳ機能を備え、定期的に該ＧＰＳ機能により検出された位置情報を前記サーバへ送信する位置情報送信ステップを有し、前記サーバは、前記位置情報送信ステップにより前記複数の第２クライアントから定期的に送信される位置情報をクライアント毎に更新登録する更新登録ステップと、前記緊急通報ステップにより前記第１クライアントから送信された現在位置情報と前記更新登録ステップにより更新登録されている前記複数の第２クライアントの位置情報とを比較する比較ステップと、
前記第１クライアントの現在位置情報から最も近隣に位置する第２クライアントへ当該第１クライアントの現在位置情報及び前記緊急情報を送信する緊急情報送信ステップと、を有することを特徴とする。
【００１５】
【発明の実施の形態】
以下、添付図面を参照しながら本発明に係る緊急通報システム及びその方法の実施の形態を詳細に説明する。図１〜図１０に、本発明に係る緊急通報システム及びその方法の実施形態を示す。図１において、符号１は第１クライアントを、符号２は第２クライアントを、符号３はサーバを夫々示す。
【００１６】
本発明の実施形態である緊急通報システムは、図１に示すように、ネットワーク網（ＴＣＰ／ＩＰネットワーク）Ａを介して構成され、第１クライアント１と、第２クライアント２と、サーバ３と、を備えてなる。第１クライアント１及び第２クライアント２は、ＧＰＳシステム（Ｇ）により夫々、自己位置検出機能を備えている。
【００１７】
図２は、第１クライアントの概略構成を示すブロック図である。
図２において、第１クライアント１は、静的なグローバルＩＰアドレスによりネットワークＡへ参加可能な複数のクライアント（例えば、ＴＣＰ／ＩＰプロトコルによる通信可能な携帯電話、ＰＨＳ端末やＩＰフォンなど）１ａ〜１ｎであり、位置情報取得部１１と、位置情報発信部１２と、緊急情報発信部１３と、指示情報受信部１４と、を備えて構成される。
【００１８】
位置情報取得部１１は、ＧＰＳシステム（Ｇ）により当該第１クライアント１の現在位置情報を取得する。
位置情報発信部１２は、緊急車両を要請する場合、該当する電話番号（１１０番など）を発呼するだけで、位置情報取得部１１によって取得された位置情報を後述するサーバ３へ発信する。
【００１９】
緊急情報発信部１３は、後述するサーバ３へ緊急としてのステータス情報が送信可能に構成されており、この緊急ステータスは、上記した該当する電話番号（１１０番など）を発呼した時点で緊急情報として対応付けるステータスであり、直ちに該当するサーバ３へ発信する。
【００２０】
指示情報受信部１４は、後述するサーバ３から送信される情報、例えば、警察や消防署における初動が完了した旨の救急初動了解通知を受信し、その情報を液晶パネルなどの表示部へ表示するものである。この情報は、サーバ３にアクセスしてＷｅｂインタフェースで表示されるようになっている。
【００２１】
図３は、第２クライアントの概略構成を示すブロック図である。
図３において、第２クライアント２は、静的なグローバルＩＰアドレスによりネットワークＡへ参加可能な複数のクライアント２ａ〜２ｎであり、固定型と移動型のものに分けられる。固定型の第２クライアント２ａは、位置情報が不変である警察署や消防署等に設置される端末であり、移動型の第２クライアント２ｂは、位置情報が常に変動する第２警察車両や救急車等に搭載される端末である。この第２クライアント２は、位置情報取得部２１と、位置情報発信部２２と、指示情報受信部２３と、を備えて構成される。
【００２２】
位置情報取得部２１は、ＧＰＳシステム（Ｇ）により当該第２クライアント２の現在位置情報を取得する。
【００２３】
位置情報発信部２２は、位置情報取得部２１により取得した位置情報をサーバ３に対して発信する。この第２クライアント２の位置情報は、上述したように、緊急車両の出動施設の場合、予めサーバ３のデータベースに登録されており、パトロールカーや救急車等の緊急車両自体は、ＧＰＳシステム（Ｇ）より位置情報発信部２２でリアルタイムにサーバ３へ発信され、逐一、時刻情報と共にデータベースへ登録されている。
【００２４】
指示情報受信部２３は、サーバ３からの緊急通報に関する指示情報（ＵＲＬとして提供される）を受信し、ブラウザ上でサーバ３へアクセスすることにより全てＷＥｂインタフェースで緊急通報の内容（位置情報、事件、事故、火災などの情報）を確認できる。
【００２５】
図４は、サーバの概略構成を示すブロック図である。
図４において、サーバ３は、ネットワーク網Ａ上に設けられたホストコンピュータであり、位置情報受信部３１と、緊急情報受信部３２と、検索部３３と、指示情報送信部３４と、データベース３５と、を備えて構成される。
【００２６】
位置情報受信部３１は、第１クライアント１からの位置情報及び第２クライアント２からの位置情報を受信し、これらの位置情報を送信された時刻情報と共にデータベース３５に登録する。
【００２７】
緊急情報受信部３２は、第１クライアント１からの緊急情報を受信し、該情報をデータベース３５に登録する。
【００２８】
検索部３３は、第１クライアント１からの位置情報に基づいて、全ての第２クライアント２の中から上記位置情報から最短距離にある第２クライアント２を、データベース３５に登録されている情報の中から検索する。
【００２９】
指示情報送信部３４は、検索部３３によって検索された上記位置情報から最短距離にある第２クライアント２に対し、緊急情報と第１クライアント１の位置情報とをＵＲＬ情報として通知する。この指示情報（ＵＲＬ情報）とは、緊急通報のあった第１クライアント１から口頭で伝達された緊急情報（事件、事故、火災などの状況）と、緊急通報の発呼と共に送信される位置情報と、からなるＷｅｂページのＵＲＬが提供される。
なお、このＷｅｂページは、第１クライアント１から口頭で伝達された内容（緊急情報）を音声認識機能により認識し、送信された位置情報を付加して自動的に作成することも可能であるが、オペレータを介して手入力作業により緊急情報を入力して作成することも可能である。
【００３０】
＜第１の通信処理シーケンス＞
図５は、第２クライアント２とサーバ３との位置情報用プロトコルによる通信例を示すシーケンスチャートである。本プロトコルは、ＯＳＩ参照モデルのセッション層（第５層）にあたるものであり、トランスポート層（第４層）のＴＣＰを使用して全てのプロトコルを実現するものである。
【００３１】
まず、第２クライアント２は、サーバ３に対して接続要求を送信する（ステップＳ１１）。サーバ３は、第２クライアント２からの接続要求に対して第２クライアント２へ接続完了を送信する（ステップＳ１２）。
【００３２】
次に、第２クライアント２は、サーバ３に対して端末ＫＥＹを送信する（ステップＳ１３）。この端末ＫＥＹとは、サーバ３が第２クライアント２を認証するためのもので、端末毎に予め定められたＫＥＹコードであり、本実施例ではＩＰアドレスを用いる。サーバ３は、第２クライアント２から送信された端末ＫＥＹに基づく認証処理がＯＫの場合、以降のデータ受信受付が可能であることを示す旨（認証ＯＫ）を第２クライアント２へ送信する（ステップＳ１４）。
【００３３】
次に、第２クライアント２は、サーバ３に対して自身の位置情報を示す緯度経度データを送信する（ステップＳ１５）。サーバ３は、第２クライアント２から送信された緯度経度データの受信が正常に行われた場合、当該データの受信完了の旨を第２クライアント２へ送信する（ステップＳ１６）。なお、サーバ３で緯度経度データが正常に受信されなかった場合は、当該データの再送要求を第２クライアント２へ送信する。
【００３４】
第２クライアント２は、サーバ３から緯度経度データの受信完了の旨を受信すると、終了コマンドをサーバ３へ送信して切断処理を行う（ステップＳ１７）。
【００３５】
以上の処理から、サーバ３は、定期的に第２クライアント２の位置情報を取得することで、パトロールカーや救急車等のように移動するクライアント（端末機器）の位置情報を常に把握することができる。なお、位置情報の送受信（タイミング）に関しては、端末側アプリケーションとして任意に設定変更可能な環境設定ファイルが設けられている。
【００３６】
＜第２の通信処理シーケンス＞
図６は、第１クライアント１とサーバ３との緊急情報用プロトコルによる通信例を示すシーケンスチャートである。本プロトコルは、ＯＳＩ参照モデルのセッション層（第５層）にあたるものであり、トランスポート層（第４層）のＴＣＰを使用して全てのプロトコルを実現するものである。
【００３７】
まず、第１クライアント１は、サーバ３に対して接続要求を送信する（ステップＳ２１）。サーバ３は、第１クライアント１からの接続要求に対して第１クライアント１へ接続完了を送信する（ステップＳ２２）。
【００３８】
次に、第１クライアント１は、サーバ３に対して端末ＫＥＹを送信する（ステップＳ２３）。この端末ＫＥＹとは、サーバ３が第１クライアント１を認証するためのもので、端末毎に予め定められたＫＥＹコードであり、本実施例ではＩＰアドレスを用いる。サーバ３は、第１クライアント１から送信された端末ＫＥＹに基づく認証処理がＯＫの場合、以降のデータ受信受付が可能であることを示す旨（認証ＯＫ）を第１クライアント１へ送信する（ステップＳ２４）。
【００３９】
次に、第１クライアント１は、サーバ３に対して緊急である旨を示すヘッダーを付した自身位置情報を示す緯度経度データを送信する（ステップＳ２５）。サーバ３は、第１クライアント１から送信された緊急である旨を示すヘッダーが付された緯度経度データの受信が正常に行われた場合、当該データの受信完了の旨を第１クライアント１へ送信する（ステップＳ２６）。なお、サーバ３で緯度経度データが正常に受信されなかった場合は、当該データの再送要求を第１クライアント１へ送信する。
【００４０】
第１クライアント１は、サーバ３から緯度経度データの受信完了の旨を受信すると、終了コマンドをサーバ３へ送信して切断処理を行う（ステップＳ２７）。
【００４１】
＜第３の通信処理シーケンス＞
図７は、サーバ３と第２クライアント２との指示情報用プロトコルによる通信例を示すシーケンスチャートである。本プロトコルは、ＯＳＩ参照モデルのセッション層（第５層）にあたるものであり、トランスポート層（第４層）のＴＣＰを使用して全てのプロトコルを実現するものである。
【００４２】
まず、サーバ３は、第２クライアント２に対して接続要求を送信する（ステップＳ３１）。第２クライアント２は、サーバ３からの接続要求に対して当該サーバ３へ接続完了を送信する（ステップＳ３２）。
【００４３】
次に、サーバ３は、第２クライアント２に対してサーバＫＥＹを送信する（ステップＳ３３）。このサーバＫＥＹとは、第２クライアント２がサーバ３を認証するためのもので、サーバに予め定められたＫＥＹコードであり、本実施例ではＩＰアドレスを用いる。第２クライアント２は、サーバ３から送信されたサーバＫＥＹに基づく認証処理がＯＫの場合、以降のデータ受信受付が可能であることを示す旨（認証ＯＫ）をサーバ３へ送信する（ステップＳ３４）。
【００４４】
次に、サーバ３は、第２クライアント２に対して緊急である旨を示すメッセージと緊急通報のあった位置情報とから構成されるＷｅｂページのＵＲＬ情報（緊急情報）を送信する（ステップＳ３５）。第２クライアント２は、サーバ３から送信されたＵＲＬを正常に受信した場合、当該ＵＲＬを正常に受信した旨をサーバ３へ送信する（ステップＳ３６）。なお、第２クライアント２でＵＲＬ緯度経度データが正常に受信されなかった場合は、当該ＵＲＬの再送要求をサーバ３へ送信する。
【００４５】
サーバ３は、第２クライアント２からＵＲＬを正常に受信した旨を受信すると、終了コマンドを第２クライアント２へ送信して切断処理を行う（ステップＳ３７）。第２クライアント２は、受信したＵＲＬをブラウザに引き渡してブラウザを起動することにより、何処で何が起こっているかという情報を確認することができる。
【００４６】
以上のように構成された本発明の実施形態である緊急通報システムの動作例を図８〜図１０に基づいて説明する。
【００４７】
＜第１の動作例＞
図８は、１１０番通報による警察の出動を要請する動作例を示すフローチャートである。ここでの登録クライアントとは、図１に示す第１クライアント１に相当するものであり、通報者の携帯電話機、コンビニエンスストアやファミリーレストラン等に設置される端末装置、あるいは、予め本システムの利用登録を済ませている通報者の端末装置である。また、対応クライアントとは、図１に示す第２クライアント２に相当するものであり、警察車両に搭載される端末装置（移動型）、または、警察署や交番に設置される端末装置（固定型）である。
【００４８】
まず、登録クライアントは、緊急事態（事件）の発生に対して該当する電話番号（１１０番）に発信する（ステップＳ４１）。この登録クライアントは、位置情報取得部によって現在の位置情報を取得し、緊急ステータスによって自動的に該当サーバ３へ位置情報及び緊急情報を通知する。
【００４９】
位置情報及び緊急情報を受信したサーバ３は、初動告知処理として、登録クライアントからの位置情報と、事前にデータベースに登録されている対応クライアント（警察車両）の現在位置とを比較して、登録クライアントの位置情報から最短距離に存在する警察車両を選定する。サーバ３は、上記選定された警察車両に対し、登録クライアントの位置情報と緊急情報とを通知する（ステップＳ４２）。この通知は、例えば、サーバ３側で自動的に登録クライアントの位置情報と緊急情報とから構成されるＷｅｂページを作成する機能を設けておくことにより、警察車両（対応クライアント）へは当該ＷｅｂページのＵＲＬを送信するとよい。
【００５０】
対応クライアント（選定された警察車両）は、サーバ３からＵＲＬを受信すると（ステップＳ４３）、オペレータ（警察官等）によってブラウザ上で当該ＵＲＬにより指定されるＷｅｂページ上で登録クライアント（通報者）の位置情報及び緊急情報を確認後、通知確認及び了解確認をサーバ３へ送信する。
【００５１】
なお、対応クライアントは、初動の了解ができない場合、例えば、既に他の事件の処理中であり、緊急通報を受けた現場へ急行できないような場合、オペレータの確認操作によってサーバ３に非了解通知を送信するようにする。
【００５２】
サーバ３は、初動非了解の通知を受信した場合には、次に登録クライアントから最短距離にいる対応クライアントを選定し、了解通知を受信するまで処理を繰り返す。（ステップＳ４２、４３、４４）。
【００５３】
サーバ３は、対応クライアントから了解通知を受信すると、即座に登録クライアントに対して初動が完了した旨を示す了解通知を送信する（ステップＳ４５）。登録クライアントは、サーバから初動（緊急車両が現場に急行している）が完了した旨を通知されると、液晶パネルなどに表示し、緊急通報処理を終了する（ステップＳ４６）。
【００５４】
＜第２の動作例＞
図９は、１１９番通報による救急車の出動を要請する動作例を示すフローチャートである。ここでの登録クライアントとは、図１に示す第１クライアント１に相当するものであり、通報者の携帯電話機、コンビニエンスストアやファミリーレストラン等に設置される端末装置、あるいは、予め本システムの利用登録を済ませている通報者の端末装置である。また、対応クライアントとは、図１に示す第２クライアント２に相当するものであり、救急車に搭載される端末装置（移動型）、または、消防署に設置される端末装置（固定型）である。
【００５５】
まず、登録クライアントは、緊急事態（事故や急病）の発生に対して該当する電話番号（１１９番）に発信する（ステップＳ５１）。この登録クライアントは、位置情報取得部によって現在の位置情報を取得し、緊急ステータスによって自動的に該当サーバ３へ位置情報及び緊急情報を通知する。
【００５６】
位置情報及び緊急情報を受信したサーバ３は、初動告知処理として、登録クライアントからの位置情報と、事前にデータベースに登録されている対応クライアント（救急車や消防署）の現在位置とを比較して、登録クライアントの位置情報から最短距離に存在する救急車又は消防署を選定する。サーバ３は、上記選定された救急車又は消防署に対し、登録クライアントの位置情報と緊急情報とを通知する（ステップＳ５２）。この通知は、例えば、サーバ３側で自動的に登録クライアントの位置情報と緊急情報とから構成されるＷｅｂページを作成する機能を設けておくことにより、救急車又は消防署（対応クライアント）へは当該ＷｅｂページのＵＲＬを送信するとよい。
【００５７】
対応クライアント（選定された救急車又は消防署）は、サーバ３からＵＲＬを受信すると（ステップＳ５３）、オペレータによってブラウザ上で当該ＵＲＬにより指定されるＷｅｂページ上で登録クライアント（通報者）の位置情報及び緊急情報を確認後、通知確認及び了解確認をサーバ３へ送信する。
【００５８】
なお、対応クライアントは、初動の了解ができない場合、例えば、既に他の事故現場へ急行している、あるいは、既に患者を搬送中であるため、現場へ急行できないといった場合、オペレータの確認操作によってサーバ３に非了解通知を送信するようにする。
【００５９】
サーバ３は、初動非了解の通知を受信した場合には、次に登録クライアントの現在位置から最短距離にいる対応クライアントを選定し、了解通知を受信するまで処理を繰り返す。（ステップＳ５２、５３、５４）。なお、通報者の近隣に複数の対応クライアントが存在する場合には、全ての対応クライアントに対して同報配信するような構成とし、了解通知の最も早く送信された対応クライアントにより初動を開始するようにしてもよい。
【００６０】
サーバ３は、対応クライアントから了解通知を受信すると、即座に登録クライアントに対して初動が完了した旨を示す了解通知を送信する（ステップＳ５５）。登録クライアント（通報者）は、サーバ３から初動（救急車が現場に急行している）が完了した旨を通知されると、液晶パネルなどに表示し、緊急通報処理を終了する（ステップＳ５６）。
【００６１】
＜第３の動作例＞
図１０は、患者を収容した救急車からの搬送先特定に関する動作例を示すフローチャートである。ここでの登録クライアントとは、図１に示す第１クライアント１に相当するものであり、救急車に搭載される端末装置である。また、対応クライアントとは、図１に示す第２クライアント２に相当するものであり、患者の搬送先となる救急医療機関（大学病院や救急医療センターなど）に設置される端末装置（固定型）である。
【００６２】
まず、登録クライアント（救急車）は、サーバ３に対して患者受け入れ要求や現在位置情報等を送信する（ステップＳ６１）。なお、この際、患者の症状も送信するようにし、適切な救急医療機関を選定するための情報として用いることも可能である。
【００６３】
サーバ３は、救急車から患者受け入れ要求と現在位置情報とを受信すると、救急車の現在位置情報と予めサーバ３のデータベースに登録されている対応クライアント（救急医療機関）の位置情報とを比較する。サーバ３は、この比較結果から救急車の現在位置から最短距離にある救急医療機関に設置されている対応クライアントを選定し、当該対応クライアントに対して患者受け入れ要請並びに救急車の現在位置情報を送信する（ステップＳ６２）。なお、救急医療機関を選定する際には、救急車の現在位置を中心に半径ｘｋｍ以内に位置する対応クライアント全てを選定し、当該選定された対応クライアントに対して同報配信して了解通知の最も早く送信された対応クライアント（救急医療機関）を患者受け入れ先と選定するようにしてもよい。
【００６４】
対応クライアントは、患者受け入れ要求と救急車の現在位置情報とを受信すると（ステップＳ６３）、医師などのオペレータの判断によって受け入れの可否を示す通知確認及び了解確認をサーバ３へ送信する（ステップＳ６４）。
【００６５】
サーバ３は、対応クライアントから送信された通知確認及び了解確認に基づいて、患者受け入れ可能な医療機関リストを作成し、登録クライアント（救急車）へ送信する（ステップＳ６５）。
【００６６】
登録クライアントは、サーバ３から送信された受け入れ可能な医療機関リストを確認して、救急隊員の判断によって搬送先医療機関を検討し（ステップ６６）、決定した搬送先医療機関の確定情報をサーバ３へ送信する（ステップ６７）。
【００６７】
サーバ３は、登録クライアントから搬送先医療機関の確定情報を受信すると、その旨を決定した搬送先医療機関（対応クライアント）に対して患者受け入れ準備の指示を送信して（ステップＳ６８）、処理を終了する。
【００６８】
なお、上述する実施形態は本発明の好適な実施形態であり、本発明の主旨を逸脱しない範囲内において種々変形して実施することが可能である。
【００６９】
【発明の効果】
以上の説明から明らかなように、本発明によれば、緊急通報のあった事件現場や事故現場を特定する際に人手を介すことなく、正確な位置を瞬時に特定することができるので、警察や救急等の初動の遅れを改善することができる。
【００７０】
また、本発明によれば、携帯ＩＰフォンを本システムの構成としたことにより、初めての外出先など、通報者自体が自己の現在位置を把握していない場所で発生した事件や事故に関する緊急通報も、上記した効果と同様に、人手を介することなく特定することができるので、警察や救急等の初動の遅れを改善することができる。
【００７１】
さらに、本発明によれば、人手を介することなく患者の搬送先医療機関を特定することができるので、救急患者の受け入れ先医療機関の決定をスムーズにして、人命救助に多大に貢献することができる。
【図面の簡単な説明】
【図１】本発明の実施形態である緊急通報システムの概略構成を示すブロック図である。
【図２】第１クライアントの構成を示すブロック図である。
【図３】第２クライアントの構成を示すブロック図である。
【図４】サーバの構成を示すブロック図である。
【図５】第２クライアントとサーバとの位置情報用プロトコルによる通信例を示すシーケンスチャートである。
【図６】第１クライアントとサーバとの緊急情報用プロトコルによる通信例を示すシーケンスチャートである。
【図７】サーバから第２クライアントとの指示情報用プロトコルによる通信例を示すシーケンスチャートである。
【図８】第１の動作例を示すシーケンスチャートである。
【図９】第２の動作例を示すシーケンスチャートである。
【図１０】第３の動作例を示すシーケンスチャートである。
【符号の説明】
１　第１クライアント
１１　位置情報取得部
１２　位置情報発信部
１３　緊急情報発信部
１４　指示情報受信部
２　第２クライアント
２１　受信部
２２　位置情報取得部
３　サーバ
３１　位置情報受信部
３２　緊急情報受信部
３３　検索部
３４　指示情報送信部
Ｇ　ＧＰＳ

Claims

複数の第１クライアントと、複数の第２クライアントと、がネットワーク上のサーバを介して接続される緊急通報システムであって、
前記第１クライアントは、ＧＰＳ機能を備え、
緊急通報時に該ＧＰＳ機能により検出された現在位置情報及び緊急情報を前記サーバへ送信し、
前記第２クライアントは、ＧＰＳ機能を備え、
定期的に該ＧＰＳ機能により検出された位置情報を前記サーバへ送信し、
前記サーバは、
前記複数の第２クライアントから定期的に送信される位置情報をクライアント毎に更新登録するデータベースを備え、
前記第１クライアントから緊急通報時に送信された現在位置情報と前記データベースに更新登録されている前記複数の第２クライアントの位置情報とを比較し、
前記第１クライアントの現在位置情報から最も近隣に位置する第２クライアントを選定し、当該選定された第２クライアントへ当該第１クライアントの現在位置情報及び前記緊急情報を送信する、
ことを特徴とする緊急通報システム。
前記サーバは、
前記緊急情報及び前記第１クライアントの現在位置情報からなるＷｅｂページを作成し、当該作成されたＷｅｂページのＵＲＬ情報を前記選定された第２クライアントへ送信することを特徴とする請求項１記載の緊急通報システム。
前記ネットワークは、ＴＣＰ／ＩＰネットワーク網であり、
前記第１クライアントは、携帯ＩＰフォンであることを特徴とする請求項１または２記載の緊急通報システム。
複数の第１クライアントと、複数の第２クライアントと、がネットワーク上のサーバを介して接続される緊急通報システムの方法であって、
前記第１クライアントは、ＧＰＳ機能を備え、
緊急通報時に該ＧＰＳ機能により検出された現在位置情報及び緊急情報を前記サーバへ送信する緊急通報ステップを有し、
前記第２クライアントは、ＧＰＳ機能を備え、
定期的に該ＧＰＳ機能により検出された位置情報を前記サーバへ送信する位置情報送信ステップを有し、
前記サーバは、
前記位置情報送信ステップにより前記複数の第２クライアントから定期的に送信される位置情報をクライアント毎に更新登録する更新登録ステップと、
前記緊急通報ステップにより前記第１クライアントから送信された現在位置情報と前記更新登録ステップにより更新登録されている前記複数の第２クライアントの位置情報とを比較する比較ステップと、
前記第１クライアントの現在位置情報から最も近隣に位置する第２クライアントへ当該第１クライアントの現在位置情報及び前記緊急情報を送信する緊急情報送信ステップと、
を有することを特徴とする緊急通報システムの方法。