(57)【要約】【課題】ユーザからの救助依頼がなくてもユーザの救助依頼を行うことが可能な遭難救助依頼システム等を提供する。【解決手段】遭難救助依頼システムは、ユーザが所持するユーザ端末１０と、救助隊が所持する救助隊端末３０とが通信回線４０を介して接続された遭難救助センターサーバ２０を有する。ユーザ端末１０は、ユーザのスケジュール情報とユーザ端末１０の現在位置情報とをサーバ２０に送信することができる。サーバ２０は、予め登録されているスケジュール情報に基づいて、帰着予定日時前にユーザ端末１０に対して帰着確認情報を送信する。これに対し、確認の返信が所定時間内にユーザ端末１０からサーバ２０に送られてこなかった場合には、サーバ２０は、そのユーザの救助を依頼する救助依頼情報を、ユーザ端末１０の現在位置情報と共に救助隊端末３０に送信する。救助隊端末３０は、そのユーザ端末１０の現在位置情報を地図情報として表示する。【選択図】  図１
2004318577.tif 000002
【特許請求の範囲】
【請求項１】
外出するユーザが所持するユーザ端末と、前記ユーザが遭難した可能性があるときに前記ユーザの救助に出動する救助隊が所持する救助隊端末とが通信回線を介して接続された遭難救助センターサーバを有する遭難救助依頼システムであって、
前記ユーザ端末は、前記ユーザ端末自身の現在位置を測位する位置測位手段を有し、該位置測位手段で測位した前記現在位置の情報を自動的に前記サーバに送信するとともに、少なくとも帰着予定日時を含む前記ユーザのスケジュール情報を前記サーバに送信して登録することができるように構成されており、
前記サーバは処理装置とデータベースとを有しており、前記処理装置は、前記ユーザ端末から送信されてきた前記スケジュール情報を前記データベースに格納するとともに、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記帰着予定日時までの残り時間が所定時間よりも少なくなっている前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して帰着確認情報を送信し、前記帰着確認情報に対する返信を該帰着確認情報を送信してから所定の時間が経過しても前記ユーザ端末から受信しなかった場合に、該ユーザの救助を依頼する救助依頼情報を該ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信するように構成されており、
前記救助隊端末は、前記ユーザ端末の前記現在位置の情報を地図情報として表示するように構成されている遭難救助依頼システム。
【請求項２】
前記処理装置は、前記検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して１回目の帰着確認情報を送信し、該１回目の帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記ユーザ端末に対して２回目の帰着確認情報を送信し、該２回目の帰着確認情報を送信してから所定の時間が経過してもなお前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記救助依頼情報を前記ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信するように構成されている、請求項１に記載の遭難救助依頼システム。
【請求項３】
前記処理装置は、前記ユーザ端末に対して前記２回目の帰着確認情報を送信する際に、前記ユーザ端末にアラーム音を鳴動させる鳴動信号も前記ユーザ端末に送信するように構成されており、
前記ユーザ端末は、前記鳴動信号を受信するとアラーム音を鳴動するように構成されている、請求項２に記載の遭難救助依頼システム。
【請求項４】
前記スケジュール情報は出発予定日時も含んでおり、
前記処理装置は、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記出発予定日時から所定時間が経過している前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して出発確認情報を送信するように構成されている、請求項１から３のいずれか１項に記載の遭難救助依頼システム。
【請求項５】
外出するユーザが所持するユーザ端末と、前記ユーザが遭難した可能性があるときに前記ユーザの救助に出動する救助隊が所持する救助隊端末とが通信回線を介して接続された遭難救助センターサーバを用いて、前記ユーザの救助依頼を救助隊端末に送信する遭難救助依頼方法であって、
前記ユーザ端末から前記サーバに対して、前記ユーザ端末に備えられた、前記ユーザ端末自身の現在位置を測位する位置測位手段で測位した前記現在位置の情報を自動的に送信するとともに、少なくとも帰着予定日時を含む前記ユーザのスケジュール情報を送信して登録する第１のステップと、
前記サーバの処理装置が、前記ユーザ端末から送信されてきた前記スケジュール情報を前記サーバのデータベースに格納する第２のステップと、
前記サーバの処理装置が、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記帰着予定日時までの残り時間が所定時間よりも少なくなっている前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して帰着確認情報を送信し、該帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合に、該ユーザの救助を依頼する救助依頼情報を該ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信する第３のステップと、
を有する遭難救助依頼方法。
【請求項６】
前記救助隊端末が前記ユーザ端末の前記現在位置の情報を地図情報として表示するステップを有する、請求項５に記載の遭難救助依頼方法。
【請求項７】
前記第３のステップは、前記処理装置が、前記検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して１回目の帰着確認情報を送信し、該１回目の帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記ユーザ端末に対して２回目の帰着確認情報を送信し、該２回目の帰着確認情報を送信してから所定の時間が経過してもなお前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記救助依頼情報を前記ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信するステップからなる、請求項５または６に記載の遭難救助依頼方法。
【請求項８】
前記処理装置が、前記ユーザ端末に対して前記２回目の帰着確認情報を送信する際に、前記ユーザ端末にアラーム音を鳴動させる鳴動信号も前記ユーザ端末に送信するステップを有する、請求項７に記載の遭難救助依頼方法。
【請求項９】
前記スケジュール情報は出発予定日時も含んでおり、
前記処理装置が、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記出発予定日時から所定時間が経過している前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して出発確認情報を送信するステップを有する、請求項５から８のいずれか１項に記載の遭難救助依頼方法。
【請求項１０】
外出するユーザが所持するユーザ端末と、前記ユーザが遭難した可能性があるときに前記ユーザの救助に出動する救助隊が所持する救助隊端末とが通信回線を介して接続された遭難救助センターサーバを用いて、前記ユーザの救助依頼を救助隊端末に送信する処理をコンピュータに実行させるためのプログラムであって、
前記ユーザ端末から前記サーバに対して自動的に送信される、前記ユーザ端末に備えられた前記ユーザ端末自身の現在位置を測位する位置測位手段で測位した前記現在位置の情報を前記サーバが受信するとともに、前記ユーザが外出する前に予め前記ユーザ端末から前記サーバに対して送信される、少なくとも帰着予定日時を含む前記ユーザのスケジュール情報を前記サーバが受信する第１の手順と、
前記サーバの処理装置が、前記ユーザ端末から送信されてきた前記スケジュール情報を前記サーバのデータベースに格納する第２の手順と、
前記サーバの処理装置が、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記帰着予定日時までの残り時間が所定時間よりも少なくなっている前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して帰着確認情報を送信し、該帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合に、該ユーザの救助を依頼する救助依頼情報を該ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信する第３の手順と、
をコンピュータに実行させるためのプログラム。
【請求項１１】
前記第３の手順は、前記処理装置が、前記検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して１回目の帰着確認情報を送信し、該１回目の帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記ユーザ端末に対して２回目の帰着確認情報を送信し、該２回目の帰着確認情報を送信してから所定の時間が経過してもなお前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記救助依頼情報を前記ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信する手順からなる、請求項１０に記載のプログラム。
【請求項１２】
前記処理装置が、前記ユーザ端末に対して前記２回目の帰着確認情報を送信する際に、前記ユーザ端末にアラーム音を鳴動させる鳴動信号も前記ユーザ端末に送信する手順を有する、請求項１１に記載のプログラム。
【請求項１３】
前記スケジュール情報は出発予定日時も含んでおり、
前記処理装置が、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記出発予定日時から所定時間が経過している前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して出発確認情報を送信する手順を有する、請求項１０から１２のいずれか１項に記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、救助隊が遭難したユーザの位置を特定して遭難救助を行うことを可能にする遭難救助依頼システム等に関する。
【０００２】
【従来の技術】
近年では海や山でのレジャーが盛んになっており、それに比例して事故や遭難が多発する傾向にある。レジャーに行った者が遭難に遭い、帰宅予定を過ぎても帰宅しない場合、一般的には、その者の家族等が関係機関に通報することで救助隊が現地に出動して救助が行われる。
【０００３】
しかしながら、そのような従来の救助方法では、救助隊は、遭難者がレジャーに出発する際に家族等に連絡していた行き先等の情報から、遭難したと考えられるおおよその地域を把握することはできても、遭難者の正確な位置を特定することはできない。そのため、救助隊が遭難者を発見して救助するまでに時間を要することもある。
【０００４】
そこで、救助を求める者の正確な位置を特定するために、特許文献１に開示されているようなシステムが考案されている。特許文献１は、救助を求める時間的余裕が無く、ユーザ（救助を求める者）が救助依頼先を特定できないような場合であっても、迅速に対処して緊急通報することを目的とする緊急通報システム等に関するものである。
【０００５】
この緊急通報システムによれば、まず、ユーザが操作する操作部と、自己の現在位置を検出して位置測位情報を出力する現在位置測位部とを有する移動体端末装置を用いて、ユーザが、操作部においてあらかじめ設定した所定の緊急通報操作を行うことにより、移動体端末装置からデータセンターに対して位置測位情報とともに緊急通報を行う。データセンターは、移動体端末装置からの緊急通報を受け取ると、緊急通報に含まれている位置測位情報から得られる機関までの直線距離あるいは機関までの経路探索などに基づいて最寄りの機関を判別し、ネットワークを介して最寄りの機関に緊急通報に対応する救助依頼を行う。
【０００６】
このようにして救助依頼された最寄りの機関が救助隊をユーザの位置へ出動させることにより、救助隊はユーザを速やかに発見して救助することが可能になる。
【０００７】
【特許文献１】
特開２００２−７４５６５号公報
【０００８】
【発明が解決しようとする課題】
しかしながら、特許文献１に開示された従来のシステムでは、ユーザが自らデータセンターに対して緊急通報を行わないと、センター側はユーザが遭難したことを認識できない。そのため、遭難したユーザが何らかの理由で移動体端末装置を操作できない事態に陥った場合には、ユーザからの緊急通報がなされないためセンターから関係機関に救助依頼がされることはなく、ユーザはこのシステムによる救助を受けることができない。
【０００９】
また、特に海上で遭難した場合には、ユーザが遭難したことに気付いて緊急通報をするまでに相当の時間が経過していると、その間に、移動体端末装置に通信基地局からの電波が届かないところまで漂流してしまう可能性もある。この場合にも、ユーザは移動体端末装置で緊急通報をすることができないため、このシステムによる救助を受けることができない。
【００１０】
そこで本発明は、ユーザからの救助依頼がなくても、ユーザが遭難したことをセンター側が判断して救助依頼を行うことが可能な遭難救助依頼システム等を提供することを目的とする。
【００１１】
【課題を解決するための手段】
上記目的を達成するため、本発明の遭難救助依頼システムは、外出するユーザが所持するユーザ端末と、前記ユーザが遭難した可能性があるときに前記ユーザの救助に出動する救助隊が所持する救助隊端末とが通信回線を介して接続された遭難救助センターサーバを有する遭難救助依頼システムであって、
前記ユーザ端末は、前記ユーザ端末自身の現在位置を測位する位置測位手段を有し、該位置測位手段で測位した前記現在位置の情報を自動的に前記サーバに送信するとともに、少なくとも帰着予定日時を含む前記ユーザのスケジュール情報を前記サーバに送信して登録することができるように構成されており、
前記サーバは処理装置とデータベースとを有しており、前記処理装置は、前記ユーザ端末から送信されてきた前記スケジュール情報を前記データベースに格納するとともに、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記帰着予定日時までの残り時間が所定時間よりも少なくなっている前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して帰着確認情報を送信し、前記帰着確認情報に対する返信を該帰着確認情報を送信してから所定の時間が経過しても前記ユーザ端末から受信しなかった場合に、該ユーザの救助を依頼する救助依頼情報を該ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信するように構成されており、
前記救助隊端末は、前記ユーザ端末の前記現在位置の情報を地図情報として表示するように構成されている。
【００１２】
上記本発明の遭難救助依頼システムによれば、遭難救助センターサーバは、ユーザ端末から予め登録されていたユーザのスケジュール情報に基づいて、帰着予定日時の前にユーザ端末に対して帰着確認情報を送信する。これに対し、ユーザが遭難して何らかの事情でユーザ端末を操作することができない事態に陥り、確認の返信が所定の時間内にユーザ端末から遭難救助センターサーバに送られてこなかった場合には、遭難救助センターサーバは、そのユーザの救助を依頼する救助依頼情報を救助隊端末に送信する。なお、遭難救助センターサーバには、ユーザ端末の位置測位手段で測位した現在位置の情報がユーザ端末から自動的に送信されるようになっており、遭難救助センターサーバが救助依頼情報を救助隊端末に送信する際には、ユーザ端末の現在位置の情報も一緒に遭難救助センターサーバから救助隊端末に送信される。救助隊は、救助隊端末に地図情報として表示されるユーザ端末の現在位置を確認しながら、そのユーザの救出に出動する。
【００１３】
このように、本発明の遭難救助依頼システムによれば、ユーザからの救助依頼がなくても、ユーザが遭難した可能性があることを自動的に判断して救助依頼が行われる。そのため、救助隊は、ユーザが遭難した可能性が発生した時点で速やかに救助に向かうことが可能になる。また、救助隊は、救助隊端末に地図情報として表示されるユーザ端末の現在位置を確認することができるので、ユーザを迅速に発見して救助することが可能になる。
【００１４】
また、前記処理装置は、前記検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して１回目の帰着確認情報を送信し、該１回目の帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記ユーザ端末に対して２回目の帰着確認情報を送信し、該２回目の帰着確認情報を送信してから所定の時間が経過してもなお前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記救助依頼情報を前記ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信するように構成されていてもよい。
【００１５】
これによれば、ユーザが遭難していないにもかかわらず、１回目の帰着確認情報が送られてきたことをユーザが気付かなかった場合に、誤って遭難救助依頼が送信されてしまうことを防止することが可能になる。その結果、救助隊が無駄に出動することを防ぐことができる。
【００１６】
さらに、前記処理装置は、前記ユーザ端末に対して前記２回目の帰着確認情報を送信する際に、前記ユーザ端末にアラーム音を鳴動させる鳴動信号も前記ユーザ端末に送信するように構成されており、前記ユーザ端末は、前記鳴動信号を受信するとアラーム音を鳴動するように構成されていてもよい。
【００１７】
この構成によれば、２回目の帰着確認情報が送られてきたときにはユーザ端末がアラーム音を発するので、帰着確認情報が送られてきたことをユーザに積極的に気付かせることが可能になる。
【００１８】
また、前記スケジュール情報は出発予定日時も含んでおり、前記処理装置は、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記出発予定日時から所定時間が経過している前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して出発確認情報を送信するように構成されていてもよい。
【００１９】
ユーザ端末に出発確認情報が送られてきたユーザは、当初の予定通りに出発しているときにはその旨をサーバに送信し、当初の予定を中止した場合や変更した場合にはその旨（変更した場合は変更後の予定も）をサーバに送信する。その後サーバは、当初の予定または変更後の予定に含まれる帰着予定日時に基づいて上記の帰着確認情報の送信を行う。これにより、ユーザが当初の予定通りに出発していないにもかかわらず、当初の予定の帰着予定日時に基づいて帰着確認情報の送信が行われてしまうことを防ぐことが可能になる。
【００２０】
また、本発明の遭難救助依頼方法は、外出するユーザが所持するユーザ端末と、前記ユーザが遭難した可能性があるときに前記ユーザの救助に出動する救助隊が所持する救助隊端末とが通信回線を介して接続された遭難救助センターサーバを用いて、前記ユーザの救助依頼を救助隊端末に送信する遭難救助依頼方法であって、
前記ユーザ端末から前記サーバに対して、前記ユーザ端末に備えられた、前記ユーザ端末自身の現在位置を測位する位置測位手段で測位した前記現在位置の情報を自動的に送信するとともに、少なくとも帰着予定日時を含む前記ユーザのスケジュール情報を送信して登録する第１のステップと、
前記サーバの処理装置が、前記ユーザ端末から送信されてきた前記スケジュール情報を前記サーバのデータベースに格納する第２のステップと、
前記サーバの処理装置が、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記帰着予定日時までの残り時間が所定時間よりも少なくなっている前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して帰着確認情報を送信し、該帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合に、該ユーザの救助を依頼する救助依頼情報を該ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信する第３のステップとを有する。
【００２１】
上記本発明の遭難救助依頼方法によれば、ユーザからの救助依頼がなくても、ユーザが遭難した可能性があることを自動的に判断して救助依頼が行われるので、救助隊は、ユーザが遭難した可能性が発生した時点で速やかに救助に向かうことが可能になる。また、救助隊は、救助隊端末に地図情報として表示されるユーザ端末の現在位置を確認することができるので、ユーザを迅速に発見して救助することが可能になる。
【００２２】
さらに、前記救助隊端末が、前記ユーザ端末の前記現在位置の情報を地図情報として表示するステップを有する構成としてもよい。
【００２３】
さらに、前記第３のステップは、前記処理装置が、前記検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して１回目の帰着確認情報を送信し、該１回目の帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記ユーザ端末に対して２回目の帰着確認情報を送信し、該２回目の帰着確認情報を送信してから所定の時間が経過してもなお前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記救助依頼情報を前記ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信するステップからなる構成としてもよい。
【００２４】
これによれば、ユーザが遭難していないにもかかわらず、１回目の帰着確認情報が送られてきたことをユーザが気付かなかった場合に、誤って遭難救助依頼が送られてしまうことを防止することが可能になるので、救助隊が無駄に出動することを防ぐことができる。
【００２５】
さらには、前記処理装置が、前記ユーザ端末に対して前記２回目の帰着確認情報を送信する際に、前記ユーザ端末にアラーム音を鳴動させる鳴動信号も前記ユーザ端末に送信するステップを有する構成としてもよい。鳴動信号を受信したユーザ端末がアラーム音を鳴動することで、帰着確認情報が送られてきたことをユーザに積極的に気付かせることが可能になる。
【００２６】
また、前記スケジュール情報は出発予定日時も含んでおり、前記処理装置が、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記出発予定日時から所定時間が経過している前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して出発確認情報を送信するステップを有する構成としてもよい。これにより、ユーザが当初の予定通りに出発していないにもかかわらず、当初の予定の帰着予定日時に基づいて帰着確認情報の送信が行われてしまうことを防ぐことが可能になる。
【００２７】
また、本発明のコンピュータプログラムは、外出するユーザが所持するユーザ端末と、前記ユーザが遭難した可能性があるときに前記ユーザの救助に出動する救助隊が所持する救助隊端末とが通信回線を介して接続された遭難救助センターサーバを用いて、前記ユーザの救助依頼を救助隊端末に送信する処理をコンピュータに実行させるためのプログラムであって、
前記ユーザ端末から前記サーバに対して自動的に送信される、前記ユーザ端末に備えられた前記ユーザ端末自身の現在位置を測位する位置測位手段で測位した前記現在位置の情報を前記サーバが受信するとともに、前記ユーザが外出する前に予め前記ユーザ端末から前記サーバに対して送信される、少なくとも帰着予定日時を含む前記ユーザのスケジュール情報を前記サーバが受信する第１の手順と、
前記サーバの処理装置が、前記ユーザ端末から送信されてきた前記スケジュール情報を前記サーバのデータベースに格納する第２の手順と、
前記サーバの処理装置が、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記帰着予定日時までの残り時間が所定時間よりも少なくなっている前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して帰着確認情報を送信し、該帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合に、該ユーザの救助を依頼する救助依頼情報を該ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信する第３の手順と、をコンピュータに実行させるためのプログラムである。
【００２８】
前記第３の手順は、前記処理装置が、前記検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して１回目の帰着確認情報を送信し、該１回目の帰着確認情報を送信してから所定の時間が経過しても前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記ユーザ端末に対して２回目の帰着確認情報を送信し、該２回目の帰着確認情報を送信してから所定の時間が経過してもなお前記帰着確認情報に対する返信を前記ユーザ端末から受信しなかった場合には、前記救助依頼情報を前記ユーザ端末の前記現在位置の情報とともに前記救助隊端末に送信する手順からなる構成としてもよい。
【００２９】
さらに、前記処理装置が、前記ユーザ端末に対して前記２回目の帰着確認情報を送信する際に、前記ユーザ端末にアラーム音を鳴動させる鳴動信号も前記ユーザ端末に送信する手順を有する構成としてもよい。
【００３０】
また、前記スケジュール情報は出発予定日時も含んでおり、前記処理装置が、前記データベース内に格納されている前記スケジュール情報の中から、前記スケジュール情報に含まれている前記出発予定日時から所定時間が経過している前記スケジュール情報を検索し、検索された前記スケジュール情報を登録した前記ユーザの前記ユーザ端末に対して出発確認情報を送信する手順を有する構成としてもよい。
【００３１】
【発明の実施の形態】
次に、本発明の実施形態について図面を参照して説明する。
【００３２】
まず、本発明の遭難救助依頼システムの一実施形態の構成について、図１を参照して説明する。図１は、本発明の遭難救助依頼システムの一実施形態の構成を示すブロック図である。
【００３３】
図１に示すように、本実施形態のシステムは、インターネット４０等の通信回線を介して接続されたユーザ端末１０および救助隊端末３０との間で情報の送受を行う遭難救助センターサーバ２０を有している。
【００３４】
ユーザ端末１０は、レジャーに行くユーザが携帯するＰＨＳ（Ｐｅｒｓｏｎａｌ  Ｈａｎｄｙｐｈｏｎｅ  Ｓｙｓｔｅｍ；登録商標）や携帯電話等の情報通信端末であり、図２に示すように、ユーザ端末１０全体の制御を行う制御部１０１と、アンテナを介して無線基地局との間で通信を行う通信部１０２と、ＧＰＳ衛星からの測位用電波をＧＰＳ用アンテナを介して受信してＧＰＳ測位データを生成する位置測位手段であるＧＰＳ測位部１０３と、各種操作ボタンを備えた操作部１０４と、音声入出力を行う音声入出力部１０５と、各種情報の表示を行う表示部１０６とを備えている。また、このユーザ端末１０にはブラウザソフトおよびメールソフトがインストールされており、ユーザ端末１０はインターネット４０を介してウェブページの閲覧を行ったり、電子メールの送受信を行ったりするこが可能である。
【００３５】
本実施形態におけるユーザ端末１０は、特に、レジャーに行く場所やスケジュールを予め遭難救助センターサーバ２０に登録したり、遭難救助センターサーバ２０から送信されてくる各種問い合わせに応答したりする目的で使用される。また、ユーザ端末１０は、そのＧＰＳ測位機能に基づいて、ユーザ端末１０（ユーザ）の現在位置の情報を、少なくとも定期的に、可能であればリアルタイムに遭難救助センターサーバ２０に自動的に送信する機能を有している。
【００３６】
遭難救助センターサーバ２０は、ユーザが遭難した時に救助隊を現地に派遣する指示をする遭難救助センターに管理されるものである。この遭難救助センターサーバ２０は、図３に示すように、処理装置２０１とＤＢ（データベース）２０２とを備えている。処理装置２０１は、上述したように、インターネット４０等の通信回線を介して接続されたユーザ端末１０および救助隊端末３０との間で情報の送受を行うものである。
【００３７】
処理装置２０１は、ウェブページ上で各種情報をやり取りできるとともに、電子メールの送受信もできるように構成されている。さらに、処理装置２０１には、下記に説明する処理動作を処理装置２０１等に実行させるプログラムが格納された、磁気ディスクや半導体メモリ等の記録媒体（不図示）が備えられている。そのプログラムはハードウェアである処理装置２０１等の動作を制御するものであり、プログラム制御された処理装置２０１がプログラムにより指令される特定の処理を行う。
【００３８】
本実施形態における処理装置２０１の記録媒体（不図示）には、特に以下の処理を処理装置２０１に実行させるプログラムが格納されている。
（１）ユーザ端末１０から送信されてきた、ユーザがレジャーに行く場所やスケジュール等に関する情報（以下、「レジャー情報」という。）をＤＢ２０２に格納する。
（２）ＤＢ２０２を検索し、予め登録されたレジャー情報の帰着予定日時になるとユーザ端末１０へ帰着確認のメールを送信する。
（３）送信した帰着確認のメールに対してユーザ端末１０から返信がない場合は、ユーザ端末１０に対して再度の帰着確認のメールを送信したり、ユーザ端末１０にアラームを鳴動させる信号を送信したりする。
（４）それでもユーザ端末１０から返信が無い場合は、ユーザの救出依頼に関する情報を、ユーザ端末１０から遭難救助センターサーバ２０に送信されてきた位置情報とともに救助隊端末３０へ送信する。
【００３９】
ＤＢ２０２には、ユーザがユーザ端末１０で選択しうる、レジャーの出発地、行き先、帰着地の地名データ（例えば、出発地や帰着地として「○○港」「△△マリーナ」等、行き先として「□□港沖」「××湾付近」等）が、それらのＧＰＳ位置情報と関連づけられた状態で予め格納されている。
【００４０】
また、ＤＢ２０２には、ユーザ端末１０から送信されたレジャー情報が格納される。ＤＢ２０２に格納されたレジャー情報は、スケジュール（日時）をキーワードにして、処理装置２０１によって、少なくとも定期的に、可能であればリアルタイムに検索される。
【００４１】
図４は、ＤＢ２０２に登録された、あるユーザのレジャー情報の一例を示す図である。ＤＢ２０２には、ユーザＩＤによって特定されるユーザごとに、ユーザが予定しているレジャーの内容、出発地、行き先、および帰着地と、そのスケジュール（日時）に関する情報が格納される。レジャーのスケジュール（日時）に関する情報は、出発予定日時と帰着予定日時を含んでいる。
【００４２】
図４は、プレジャーボートで水上レジャーを楽しむことを目的とする水上レジャーの場合を例に挙げて示している。図４に示す例では、ユーザが予定しているレジャーの出発地および帰着地は「○○港」、行き先は「◇◇湾近辺」であり、その内容は「水上スキー」である。また、レジャーのスケジュールは「ｙｙ年ｍｍ月ｄｄ日の□□時に出発予定」、「同日の△△時に帰着予定」である。
【００４３】
再び図１を参照すると、救助隊端末３０は、ユーザが予め登録した帰着時間までに帰着せず遭難した可能性がある場合に、遭難救助センターからの指示によって救助に出動する救助隊が所持するものである。救助隊端末３０は、少なくとも、救助隊端末３０全体の制御を行う制御部と、アンテナを介して無線基地局との間で通信を行う通信部と、各種情報の表示を行う表示部とを備えている。救助隊端末３０はその他にも、ユーザ端末１０と同様に、ＧＰＳ測位部、操作部、および音声入出力部を備えていてもよい。
【００４４】
救助隊端末３０は、遭難救助センターサーバ２０が送信する、ユーザ端末１０の位置を示すユーザ位置情報と、そのユーザの救助依頼を表す情報とを受信するように構成されている。また、救助隊端末３０は、受信したユーザ位置情報に基づいてユーザ端末１０（ユーザ）の位置をその表示部に地図情報として表示するとともに、そのユーザの救助依頼を表す情報（例えば、「緊急：ユーザＡさんの救助に向かって下さい」等）をその表示部に表示するように構成されている。
【００４５】
次に、図１から図６を参照して、本実施形態の遭難救助依頼システムの動作を説明する。図５〜図７は、図１〜図３に示した遭難救助依頼システムの動作を説明するためのフローチャートである。
【００４６】
本実施形態の遭難救助依頼システムを利用しようとするユーザは、まず、ユーザ端末１０を用いてインターネット４０を介して遭難救助センターサーバ２０にアクセスしてユーザ登録を行い、ユーザＩＤ「ａａａａ」とパスワード「ｘｘｘｘ」を取得する（ステップＳ１）。
【００４７】
次に、ユーザは、ユーザ端末１０を用い、インターネット４０を介して、遭難救助センターサーバ２０へユーザＩＤ「ａａａａ」とパスワード「ｘｘｘｘ」を送信し、サーバ２０へのログイン手続きを行う。続いて、ユーザは、レジャー情報を、図４に示すような形式で遭難救助センターサーバ２０へ送信する（ステップＳ２）。レジャー情報は、例えば、ユーザ端末１０を遭難救助センターサーバ２０に接続したときにユーザ端末１０の表示部１０６に表示される画面上の指示に従って、画面に表示されるレジャーの出発地、行き先、帰着地、レジャーの内容、およびスケジュール（出発予定日時および帰着予定日時）に関する所定の事項を操作部１０４で選択することによって、図４に示すような形式で遭難救助センターサーバ２０へ送信することが可能である。
【００４８】
上記のようにしてユーザ端末１０から遭難救助センターサーバ２０へ送信されたレジャー情報は、ユーザＩＤ「ａａａａ」を持つある特定のユーザの情報として、ＤＢ２０２に格納される（ステップＳ３）。
【００４９】
レジャー情報はこのようにして遭難救助センターサーバ２０に登録されるが、その後、ユーザの都合や天候不順等のためにレジャーを中止したりその予定を変更したりする場合がある。このような場合には、以下の手順でその旨を遭難救助センターサーバ２０に登録する。
【００５０】
レジャーを中止する場合には、ユーザは、ユーザ端末１０を用い、インターネット４０を介して遭難救助センターサーバ２０へログインした後に、レジャーを中止する旨の情報を遭難救助センターサーバ２０へ送信する（ステップＳ４，Ｓ５）。本実施形態の遭難救助依頼システムは、例えば、ユーザ端末１０を遭難救助センターサーバ２０に接続したとき、そのユーザのレジャー情報が既に遭難救助センターサーバ２０に登録されているときには、ユーザ端末１０の表示部１０６に「レジャー中止」の項目が表示されるようになっている。そのため、レジャーを中止する旨の情報は、その「レジャー中止」の項目を操作部１０４で選択することによって、遭難救助センターサーバ２０へ送信することができる。
【００５１】
遭難救助センターサーバ２０がこのようにして「レジャー中止情報」を受信すると、処理装置２０１はＤＢ２０２に登録されていた該ユーザのレジャー情報を消去し（ステップＳ１７）、遭難救助依頼システムの動作が終了する（ステップＳ１８）。
【００５２】
また、レジャーの予定を変更する場合には、ユーザはまず、ユーザ端末１０を用い、インターネット４０を介して、遭難救助センターサーバ２０へログインする。そして、変更後の新しいレジャー情報を遭難救助センターサーバ２０へ送信する（ステップＳ６，Ｓ７）。本実施形態の遭難救助依頼システムは、例えば、ユーザ端末１０を接続したとき、そのユーザのレジャー情報が既に遭難救助センターサーバ２０に登録されているときには、ユーザ端末１０の表示部１０６に「レジャー情報の変更」の項目も表示されるようになっている。そのため、新しいレジャー情報は、その「レジャー情報の変更」の項目を操作部１０４で選択した上で、上述のように、ユーザ端末１０の表示部１０６に表示される画面上の指示に従って所定の事項を操作部１０４で選択することによって、遭難救助センターサーバ２０へ送信することが可能である。
【００５３】
上記のようにしてユーザ端末１０から遭難救助センターサーバ２０へ新しいレジャー情報が送信されると、既にＤＢ２０２に格納されていたレジャー情報は、この新しいレジャー情報に更新される（ステップＳ８）。
【００５４】
上記のようにして、ユーザの最終的なレジャー情報が遭難救助センターサーバ２０に登録される。
【００５５】
ユーザは、このようにしてレジャー情報を遭難救助センターサーバ２０に登録した後、予定に従ってｙｙ年ｍｍ月ｄｄ日□□時に○○港を出発する（ステップＳ９）。
【００５６】
遭難救助センターサーバ２０は、上記のようにＤＢ２０２を検索し、予定の出発日時を過ぎているレジャー情報を検出したら、その予定の出発日時から所定の時間が経過した後に、そのレジャー情報を登録したユーザのユーザ端末１０に対して、予定通り出発したかどうかを確認するメッセージ（出発確認情報）を電子メールで送信する（ステップＳ１０）。ユーザ端末１０でその出発確認メッセージを受信したユーザは、予定通り出発している場合には「Ｙｅｓ情報」を遭難救助センターサーバ２０に送信し、出発していない場合には「Ｎｏ情報」を遭難救助センターサーバ２０に送信する（ステップＳ１１，Ｓ１２）。
【００５７】
これらの「Ｙｅｓ情報」や「Ｎｏ情報」は、例えば、電子メールの本文欄の冒頭に、「Ｙｅｓ情報」の場合には「ｙ」の一文字を記入し、「Ｎｏ情報」の場合には「ｎ」の一文字を記入した電子メールをユーザ端末１０から遭難救助センターサーバ２０に送信することによって、遭難救助センターサーバ２０に送ることができる。遭難救助センターサーバ２０の処理装置２０１は、上記の確認メッセージメールを送信した後に、ユーザ端末１０から送られてきた電子メールの中から「ｙ」または「ｎ」の文字を検出することで、ユーザ端末１０から「Ｙｅｓ情報」と「Ｎｏ情報」のどちらが送られてきたのかを認識する。
【００５８】
なお、遭難救助センターサーバ２０は、「Ｎｏ情報」を受信した場合には、「レジャー中止」か「レジャー情報の変更」の登録をすることを促す内容（例えば、「レジャー中止の登録、または、レジャー情報の変更の登録を行ってください」等）が記載されたメールをユーザ端末１０に送信する。ユーザは、その指示に応じて、上述した手順にしたがってそれらの登録を行う。
【００５９】
このように「出発確認情報」に対する応答をすることにより、ユーザが当初の予定通りに出発していないにもかかわらず、当初の予定の帰着予定日時に基づいて後述の帰着確認情報の送信が行われてしまうことを防ぐことができる。
【００６０】
遭難救助センターサーバ２０は、ＤＢ２０２を引き続き検索し、出発確認メッセージ（Ｓ１０）に対してＹｅｓ情報が送信されてきているレジャー情報の中から、予定の帰着日時が近づいてきているレジャー情報、換言すれば帰着予定日時までの残り時間が所定時間よりも少なくなっているレジャー情報を検出する。遭難救助センターサーバ２０は、予定の帰着日時が近づいてきているレジャー情報を検出したら、その予定の帰着日時よりも所定の時間だけ前に、そのレジャー情報を登録したユーザのユーザ端末１０に対して、予定通り帰着するかどうかを確認するメッセージ（１回目の帰着確認情報）を電子メールで送信する（ステップＳ１３）。そのメッセージは、例えば「予定通りレジャーを終了しますか？」等の定型文を含んでいる。
【００６１】
ユーザ端末１０でその帰着確認メッセージを受信したユーザは、予定よりも遅れて帰着する場合には「帰着予定日時の変更」を遭難救助センターサーバ２０に登録する（ステップＳ１４）。また、予定通り帰着する場合、あるいは予定よりも早く帰着する場合には「Ｙｅｓ情報」を遭難救助センターサーバ２０に送信する（ステップＳ１５）。「帰着予定日時の変更」の登録も上述した手順（ステップＳ６〜Ｓ８）と同様にして行うことができ、「Ｙｅｓ情報」の送信は上述した手順（ステップＳ１２）と同様にして行うことができる。
【００６２】
「帰着予定日時の変更」の登録がされた場合、遭難救助センターサーバ２０は、変更後の帰着予定日時に基づいて、再度、ユーザ端末１０に対して１回目の帰着確認メッセージの送信を行う（ステップＳ１３）。
【００６３】
一方、ユーザが１回目の帰着確認メッセージに対して「Ｙｅｓ情報」をユーザ端末１０から遭難救助センターサーバ２０に送信した場合（ステップＳ１５）、遭難救助センターサーバ２０がこれを受信すると、遭難救助センターサーバ２０はユーザ端末１０に対して、ＤＢ２０２に登録されたそのユーザのレジャー情報に含まれる帰着地（本例では○○港）に対応するＧＰＳ位置情報を送信する。その○○港に対応するＧＰＳ位置情報を受信したユーザ端末１０の制御部１０１は、その後、受信した○○港のＧＰＳ位置情報と、ＧＰＳ測位部１０３で測位される現在の位置情報との比較をほぼリアルタイムに行う。
【００６４】
両者の差は、ユーザが帰着地に近づくにつれて次第に小さくなり、やがて、○○港のＧＰＳ位置情報と現在位置の情報とが実質的に一致したとき、言い換えれば、現在位置の情報が○○港のＧＰＳ位置情報に対して所定の誤差範囲内に含まれたときに、ユーザ端末１０の制御部１０１はユーザが○○港に帰港したものと自動的に認識する。
【００６５】
すると、ユーザ端末１０は、レジャーが終了した旨の情報（レジャー終了情報）を遭難救助センターサーバ２０へ自動的に送信する（ステップＳ１６）。このレジャー終了情報の送信は、例えば、ユーザ端末１０から「レジャーが終了しました」等の定型文が記載された電子メールを遭難救助センターサーバ２０へ送信することによって行われる。
【００６６】
遭難救助センターサーバ２０がユーザ端末１０からレジャー終了情報を受信すると、処理装置２０１はＤＢ２０２に登録されていた該ユーザのレジャー情報を消去し（ステップＳ１７）、遭難救助依頼システムの動作が終了する（ステップＳ１８）。
【００６７】
上記では、ユーザが予定通りに無事にレジャーを終了した場合について説明した。しかし、レジャーの最中に不慮の事態が生じて、ユーザが予定通りに帰着できない場合もある。この場合、ユーザが、怪我をしている等の理由でユーザ端末１０を操作することができないこともあり、この場合にはユーザは自らユーザ端末１０を用いて救助を求めることができない。また、例えば水上でプレジャーボートの操船が不能になった場合に、救助を求めるのを忘れてその回復に集中し過ぎて長時間が経過してしまうと、ユーザ端末１０を用いて救助を求めようとした時には既に電波が届かない所まで漂流していることもあり得る。
【００６８】
本実施形態の遭難救助依頼システムは、このような事態が生じないように、ユーザからの救助連絡が無い場合でも、ユーザが遭難したと見られる場合にユーザを速やかに救助することを可能にするものである。具体的には、本実施形態の遭難救助依頼システムは、図７に示す動作に従って、遭難したと見られるユーザの救助を可能にしている。以下、その動作について説明する。
【００６９】
遭難救助センターサーバ２０は、１回目の帰着確認メッセージメールを送信した後（ステップＳ１３）、所定の時間が経過してもユーザ端末１０からこれに対する返信がない場合には、２回目の帰着確認メッセージメールを再度送信するとともに（ステップＳ１３）、ユーザ端末１０にアラーム音を鳴動させるためのアラーム信号をユーザ端末１０に送信する（ステップＳ１９）。ユーザ端末１０は、このアラーム信号を受信するとアラーム音を鳴動して、２回目の帰着確認メッセージメールが着信したことをユーザに積極的に知らせる。
【００７０】
この２回目の帰着確認メッセージメールを送信した後（ステップＳ１３）、所定の時間内にユーザ端末１０からこれに対する返信があった場合には、その返信の内容にしたがって上述した動作を行う（ステップＳ１４，Ｓ１５）。これに対し、２回目の帰着確認メッセージメールを送信した後に所定の時間が経過してもユーザ端末１０からこれに対する返信がない場合には、遭難救助センターサーバ２０は、救助隊端末３０に救助依頼情報を送信する（ステップＳ２０）。この救助依頼情報は、救助を依頼する旨の電子メール（例えば、「緊急：ユーザＡさんの救出に向かってください」等）と、該ユーザのユーザ端末１０から遭難救助センターサーバ２０に送られてくる該ユーザの位置情報とを含んでいる。ユーザ端末１０から遭難救助センターサーバ２０に送られてくる該ユーザの位置情報は、その後も遭難救助センターサーバ２０から救助隊端末３０へ随時転送され、救助隊は該ユーザの現在位置をほぼリアルタイムに認識することができる。
【００７１】
上記のようにして救助依頼を受けた救助隊は、救助隊端末３０でユーザの現在位置をリアルタイムに確認しながらユーザの救出に向かう（ステップＳ２１）。これにより、救助隊が救出に向かう間にユーザの現在位置が変わっても、救助隊はユーザを速やかに発見して救出することが可能になる。
【００７２】
また、上記のように帰着確認情報を２回送信するようにすることにより、ユーザが遭難していないにもかかわらず、１回目の帰着確認情報が送られてきたことをユーザが気付かなかった場合に、直ちに遭難救助依頼が誤って送られてしまうことを防止することが可能になる。その結果、救助隊が無駄に出動することを防ぐことができる。
【００７３】
救助隊は、ユーザの救出を終了した後、救助隊端末３０から遭難救助センターサーバ２０へ救助終了情報を送信する（ステップＳ２２）。遭難救助センターサーバ２０が救助隊端末３０から救助終了情報を受信すると、処理装置２０１がＤＢ２０２に登録されていた該ユーザのレジャー情報を消去し（ステップＳ１７）、遭難救助依頼システムの動作が終了する（ステップＳ１８）。
【００７４】
このように、本実施形態の遭難救助依頼システムによれば、ユーザからの救助依頼がなくても、ユーザが遭難した可能性があることを自動的に判断して救助依頼が行われる。そのため、救助隊は、ユーザが遭難した可能性が発生した時点で速やかに救助に向かうことが可能になる。また、救助隊は、救助隊端末に地図情報として表示されるユーザ端末の現在位置を確認することができるので、ユーザを迅速に発見して救助することが可能になる。
【００７５】
なお、上記ではユーザが水上レジャーに外出する場合を例に挙げて説明したが、その外出の目的や行き先はこれに限られない。例えば、登山やハイキングに行く場合にも、本実施形態の遭難救助依頼システム等を適用することができる。
【００７６】
【発明の効果】
以上説明したように、本発明によれば、ユーザからの救助依頼がなくても、ユーザが遭難した可能性があることを自動的に判断して救助依頼が行われるので、救助隊は、ユーザが遭難した可能性が発生した時点で速やかに救助に向かうことが可能になる。また、救助隊は、救助隊端末に地図情報として表示されるユーザ端末の現在位置を確認することができるので、ユーザを迅速に発見して救助することができる。
【図面の簡単な説明】
【図１】本発明の遭難救助依頼システムの一実施形態の構成を示すブロック図である。
【図２】図１に示した遭難救助依頼システムに用いられるユーザ端末の構成を示すブロック図である。
【図３】図１に示した遭難救助センターサーバの構成を示すブロック図である。
【図４】データベースに登録された、あるユーザのレジャー情報の一例を示す図である。
【図５】図１等に示した遭難救助依頼システムの動作を説明するためのフローチャートである。
【図６】図１等に示した遭難救助依頼システムの動作を説明するためのフローチャートである。
【図７】図１等に示した遭難救助依頼システムの動作を説明するためのフローチャートである。
【符号の説明】
１０    ユーザ端末
２０    遭難救助センターサーバ
３０    救助隊端末
４０  インターネット
１０１  制御部
１０２  通信部
１０３  ＧＰＳ測位部
１０４  操作部
１０５  音声入出力部
１０６  表示部
２０１  処理装置
２０２  ＤＢ（データベース）
【図１】
2004318577.tif 000003
【図２】
2004318577.tif 000004
【図３】
2004318577.tif 000005
【図４】
2004318577.tif 000006
【図５】
2004318577.tif 000007
【図６】
2004318577.tif 000008
【図７】
2004318577.tif 000009