(57)【要約】【課題】救助の要請に対する返信メールとして確実に受信するとともに、受信した救助情報メールの内容を音声メッセージで出力するので、遭難者の生存意欲を維持し、遭難者の生存確率の向上を図ることができる救助要請用の携帯端末装置を提供する。【解決手段】送信部１０８が救助の要請を表す救助要請ファイルが添付された救助要請メールを送信し、受信部１０９が要請された救助に関する情報を表すとともに識別子を有する救助情報ファイルが添付された返信メールを救助情報メールとして受信し、制御部１３０が救助情報メールに添付された救助情報ファイルと、救助情報ファイルと音声メッセージとを対応付けたファイル対応情報１５４とに基づいて、スピーカ１０４から音声メッセージを出力させる。【選択図】図４
2015201803.tif 000002
【特許請求の範囲】
【請求項１】
救助の要請を表す救助要請ファイルが添付された救助要請メールを送信する送信部と、
前記送信部が送信した前記救助要請メールに対する返信メールであって、要請された救助に関する情報を表すとともに識別子を有する救助情報ファイルが添付された返信メールを救助情報メールとして受信する受信部と、
音声を出力する音声出力部と、
前記救助情報ファイルの前記識別子と、前記音声出力部から出力する音声メッセージとを対応付けたファイル対応情報を記憶するファイル対応情報記憶部と、
前記受信部により前記救助情報メールが受信されると、受信された前記救助情報メールに添付された前記救助情報ファイルと前記ファイル対応情報記憶部に記憶された前記ファイル対応情報とに基づいて、前記音声出力部から前記音声メッセージを出力させる制御部とを備えることを特徴とする携帯端末装置。
【請求項２】
さらに、光を発する発光部を備え、
前記ファイル対応情報記憶部は、
前記救助情報ファイルの前記識別子と、前記発光部の発光状態とを対応付けた前記ファイル対応情報を記憶し、
前記制御部は、
前記救助情報ファイルと前記ファイル対応情報とに基づいて、前記発光部を前記発光状態に制御することを特徴とする請求項１に記載の携帯端末装置。
【請求項３】
複数のメールアドレスが記憶されたアドレス格納部と、
救助を要請する場合に押下される救助ボタンと
を備え、
前記制御部は、
前記救助ボタンが押下されると、前記アドレス格納部に格納された前記複数のメールアドレスを宛先に設定するとともに前記救助要請ファイルを添付した前記救助要請メールを生成し、生成した前記救助要請メールを前記送信部に送信させる
ことを特徴とする請求項１または２に記載の携帯端末装置。
【請求項４】
前記受信部は、
前記救助要請メールが確認されたことを表す信号確認ファイルが前記救助情報ファイルとして添付された信号確認メールを前記救助情報メールとして受信し、
さらに、救助の要請を取り消す場合に押下される取消ボタンを備え、
前記制御部は、
前記受信部により前記信号確認メールが受信された後に、前記取消ボタンが押下されると、前記信号確認メールに対する返信メールとして、救助の要請の取り消しを表す取消情報ファイルを添付した取消通知メールを生成し、生成した前記取消通知メールを前記送信部に送信させることを特徴とする請求項３に記載の携帯端末装置。
【請求項５】
前記救助要請メールは、前記救助ボタンを押下するワンタッチ動作で送信され、
前記取消通知メールは、前記取消ボタンを押下するワンタッチ動作で送信されることを特徴とする請求項４に記載の携帯端末装置。
【請求項６】
前記救助ボタンと前記取消ボタンとのそれぞれは、ボタンカバーを備え、前記ボタンカバーを破壊しなければ押下できないことを特徴とする請求項４または５に記載の携帯端末装置。
【請求項７】
前記制御部は、
経度と緯度とを含む遭難位置情報を取得し、取得した前記遭難位置情報を前記救助要請メールに含めることを特徴とする請求項１〜６のいずれかに記載の携帯端末装置。
【請求項８】
前記制御部は、
定期的に取得する定期位置情報であって経度と緯度とを含む定期位置情報を取得し、取得した前記定期位置情報を記憶装置に記憶し、前記遭難位置情報を取得できなかった場合、前記記憶装置に記憶された前記定期位置情報を前記救助要請メールに含めることを特徴とする請求項７に記載の携帯端末装置。
【請求項９】
救助の要請を表す救助要請ファイルが添付された救助要請メールを送信する携帯端末装置と、
前記携帯端末装置から送信された前記救助要請メールを受信し、受信した前記救助要請メールに対する返信メールであって、要請された救助に関する情報を表すとともに識別子を有する救助情報ファイルが添付された返信メールを救助情報メールとして前記携帯端末装置に返信する受信端末装置と
を備え、
前記携帯端末装置は、
音声を出力する音声出力部と、
前記救助情報ファイルの前記識別子と、前記音声出力部から出力する音声メッセージとを対応付けたファイル対応情報を記憶するファイル対応情報記憶部と、
前記受信端末装置から前記救助情報メールを受信すると、受信した前記救助情報メールに添付された前記救助情報ファイルと前記ファイル対応情報記憶部に記憶された前記ファイル対応情報とに基づいて、前記音声出力部から前記音声メッセージを出力させる制御部とを備えることを特徴とする救助システム。
【請求項１０】
前記受信端末装置は、公衆ネットワークに接続され、
前記携帯端末装置は、通信衛星と、前記公衆ネットワークに接続されたプッシュ型のメールサーバとを介して、前記受信端末装置と通信することを特徴とする請求項９に記載の救助システム。
【請求項１１】
前記携帯端末装置は、
経度と緯度とを含む遭難位置情報を取得し、取得した前記遭難位置情報を前記救助要請メールに含めて送信し、
前記受信端末装置は、
前記遭難位置情報が示す遭難位置に救助隊が到着するまでの救助隊到着予想時間を表す到着予想時間ファイルを前記救助情報ファイルとして添付した到着予想時間メールを前記救助情報メールとして送信し、
前記携帯端末装置の制御部は、
前記受信端末装置から前記到着予想時間メールを受信すると、受信した前記到着予想時間メールに添付された前記到着予想時間ファイルと前記ファイル対応情報とに基づいて、前記音声出力部から前記音声メッセージを出力させることを特徴とする請求項９または１０に記載の救助システム。
【請求項１２】
前記受信端末装置は、
前記救助に関する情報と、前記救助情報ファイルとを対応付けて記憶する救助情報対応テーブルを備え、前記救助情報メールには前記救助情報対応テーブルから選択された前記救助情報ファイルが添付されることを特徴とする請求項９〜１１のいずれかに記載の救助システム。
【請求項１３】
前記携帯端末装置は、
前記受信端末装置のメールアドレスを含む複数のメールアドレスを格納するアドレス格納部を備え、前記アドレス格納部に格納された前記複数のメールアドレスが宛先に設定された前記救助要請メールを送信することを特徴とする請求項９〜１２のいずれかに記載の救助システム。
【請求項１４】
前記複数のメールアドレスには、前記携帯端末装置を携帯する携帯者が加入する保険会社が備える保険会社端末装置のメールアドレスが含まれ、
前記保険会社端末装置は、前記携帯端末装置と前記受信端末装置との通信の履歴を記憶する通信履歴記憶部を備えることを特徴とする請求項１３に記載の救助システム。
【請求項１５】
携帯端末装置が、救助の要請を表す救助要請ファイルが添付された救助要請メールを送信し、
受信端末装置が、前記携帯端末装置から送信された前記救助要請メールを受信し、受信した前記救助要請メールに対する返信メールであって、要請された救助に関する情報を表すとともに識別子を有する救助情報ファイルが添付された返信メールを救助情報メールとして前記携帯端末装置に返信し、
前記携帯端末装置が、音声を出力する音声出力部と、前記救助情報ファイルの前記識別子と、前記音声出力部から出力する音声メッセージとを対応付けたファイル対応情報を記憶するファイル対応情報記憶部とを備え、前記受信端末装置から前記救助情報メールを受信すると、受信した前記救助情報メールに添付された前記救助情報ファイルと前記ファイル対応情報記憶部に記憶された前記ファイル対応情報とに基づいて、前記音声出力部から前記音声メッセージを出力させることを特徴とする救助方法。
【請求項１６】
救助の要請を表す救助要請ファイルが添付された救助要請メールを送信する送信処理と、
前記送信処理により送信された前記救助要請メールに対する返信メールであって、要請された救助に関する情報を表すとともに識別子を有する救助情報ファイルが添付された返信メールを救助情報メールとして受信する受信処理と、
前記受信処理により前記救助情報メールが受信されると、受信された前記救助情報メールに添付された前記救助情報ファイルと、前記救助情報ファイルの前記識別子と音声を出力する音声出力部から出力する音声メッセージとを対応付けたファイル対応情報とに基づいて、前記音声出力部から前記音声メッセージを出力させる音声出力処理と
をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯端末装置、救助システム、救助方法及びプログラムに関する。特に、通常の手段で救助機関と連絡を取ることができない場所において緊急の救助を要請するために使用される携帯端末装置、救助システム、救助方法及びプログラムに関する。
【背景技術】
【０００２】
海を就航する船舶の衝突事故、乗組員の海面落下事故、登山者が遭難するなどの事故が止まない。また、このような事故による死者や行方不明者の数は日本だけでも年間１５００人を超える状況（警察庁統計、海上保安庁統計による）である。
【０００３】
このような事故に遭遇した場合の救助システムとして、従来の技術として以下のような例が開示されている。
図１６は、従来の救助システムの技術（ＥＰＩＲＢ、ＰＬＢ）の概要を説明するための模式図及び従来の救助システム（ＥＰＩＲＢ、携帯電話、ＰＬＢ）の適用対象における効果を比較する比較表である。
【０００４】
船舶の事故の場合、衛星経由で救難ビーコンを救助機関に送付する手段として、コスパスサーサット衛星を用いたＥＰＩＲＢ（Ｅｍｅｒｇｅｎｃｙ  Ｐｏｓｉｔｉｏｎ  Ｉｎｄｉｃａｔｅ  Ｒａｄｉｏ  Ｂｅａｃｏｎ：緊急位置指示ラジオビーコン）がある。これは、船が一定の水深まで沈没した際に自動的に船から離脱して機上に浮上するＥＰＩＲＢ端末が、衛星経由で、各国の主官庁（図１６に示す外国の救助機関、日本の場合は海上保安庁）に対して救難信号を送信するものである。ＥＰＩＲＢ端末は、船の識別が可能なビーコン信号と、コスパスサーサット衛星側でビーコン波のドップラーシフトを用いて取得した概略の遭難位置とを、衛星経由で各国の主官庁に直接通知する。
【０００５】
また、乗組員の海面落下事故に対応する手段としては、ＡＩＳ  ＳＡＲＴ（Ａｕｔｏｍａｔｉｃ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ  Ｓｅａｒｃｈ  ａｎｄ  Ｒｅｓｃｕｅ  Ｔｒａｎｓｐｏｎｄｅｒ）がある。これは、ＡＩＳの規格で決められた救難信号を発生することができる個人携帯の信号発生装置であり、ＡＩＳ送受信機の設置が義務付けられた大型船舶や客船、または海上保安庁に中短波帯の電波を利用して直接、ＧＰＳで取得した位置情報を含めた救難信号を届けるものである。
【０００６】
また、乗組員の海面落下事故に対応する手段であって衛星を使用する手段としては、コスパスサーサット衛星を用いたＰＬＢ（Ｐｅｒｓｏｎａｌ  Ｌｏｃａｔｏｒ  Ｂｅａｃｏｎ：個人用位置表示ビーコン）がある。ＰＬＢでは、海面落下した人が自分のＧＰＳ位置を含めた救難ビーコン信号を救難信号としてコスパスサーサット衛星に対して送信し、ＥＰＩＲＢと同様に各国の主管庁に対して衛星経由で直接通知する。
【０００７】
山岳遭難事故に対応する手段としては、殆どのエリアで携帯電話が通じないため、現状、衛星携帯電話に依存するしかない。ＰＬＢは、陸上での使用が認められている国もあるが、日本では認可されていないために使用できない。
【０００８】
また、災害発生時に、メールサーバを用いて安否確認を行うシステムが開示されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１３−１８７５８０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
上述した従来の技術では、以下のような課題があった。
船舶事故に対応するＥＰＩＲＢは、図１６の比較表に示すように、２０排水トン以上の船舶に搭載が義務付けられているが、それ以下の船舶には搭載されていない。また、船舶が沈まない限り動作せず、個人の海面落下等の事故には対応できない。加えて、ＥＰＩＲＢは救難信号を送出するだけであり、遭難者は救助活動がなされるか否かを知る術がない。
【００１１】
ＡＩＳ  ＳＡＲＴは、救難信号が到達可能な距離に限りがあり、それを超えた位置に船がいる場合には受信されない。また、救難信号を受信するには、ＡＩＳ受信機を船に装備しなければならないが、２００排水トン以上の船舶、または客船にしか搭載が義務付けられていないため、多くの船舶はそのＡＩＳ受信機を装備していない。そのため、ＡＩＳ  ＳＡＲＴからの信号を受信できない。また、近隣の船が救難信号を受信しても、受信した事実を遭難者側に伝える機能が無いため、遭難者は救助が来るかどうかを知る術がなく、常に不安を抱えた状態で、生存意欲を維持する面で問題がある。
【００１２】
ＰＬＢは、国際規格で通信手段が決められており、救難信号は、日本では海上保安庁、あるいは近隣諸国では救難機関として定められている主官庁という特殊な認可を受けた専用局に対して衛星経由で直接届く。しかし、救難信号の受理確認や救助開始等の情報を遭難者に対して返信する手段（以下、リターンリンクと称す）は、まだ国際的に検討中であり、実現には時間を要する。また、衛星経由で救難信号を受信する官庁が日本では海上保安庁だけであるため、海上事故に対しては対応可能でも、陸上事故の際に使用された場合には対応が困難との背景から、日本を含む多くの国で法整備上の問題があり、使用がまだ認められていない。
【００１３】
衛星携帯電話は、子機が高価であるだけでなく通信費用を含めた衛星回線契約の費用等が必要であるため、一般の人たちが山岳事故や海難事故に遭遇する際の救難信号通知手段としては普及していない。
通常の携帯電話は、通達距離が短いために極めて沿海近傍の船舶事故や落下事故にのみ有用であり、殆どの航海では役に立たない。また、山岳事故の場合も通達エリアが小さいために適さない（図１６比較表参照）。
特許文献１の技術は、メールサーバを用いて安否確認を行うためのものであり、救助の要請については、何ら記載されていない。
【００１４】
以上のように、従来の技術にはそれぞれ異なる課題がある。これらの課題を以下にまとめる。
（１）衛星経由で救難信号を発呼する従来技術においては、救難信号を受信する側が国の官庁、あるいはそれに類似する救助機関であり、国際規格で認許を得た特別な受信手段を必要とする。
（２）救難信号を発呼する携帯端末が国際規格の承認を必要とする。
（３）法的整備が必要な日本を含む諸国では国際規格を満足する携帯ビーコン端末でも実質使用できない。
（４）救難信号の受理確認を含む救助側からのリターンリンクを実現する手段がない。
（５）救難信号が各国の官庁や救助機関に並列で配信されるために特殊事情によっては非公開としたい場合でも実質公開となる。
（６）救難信号の誤発射の場合にそれを確認し、救助活動を中断する手段がない。
【００１５】
本発明は、上記のような課題を解決するためになされたものであり、衛星に対して救助要請メールを発呼し、衛星経由で公衆ネットワークに接続された救助者のメール端末に送信し、救助要請メールを受信した救助者から救難信号受理通知、救助開始通知、救助開始時間等のリターンリンクを受信すると、遭難者に対して音声等により通知することができるビーコン端末装置を提供する。このビーコン端末装置により、海難事故や山岳事故に遭遇する危険性のある使用者が短期間で容易に使用を開始することができるとともに、救難信号に対する返信信号（リターンリンク）により遭難者の生存意欲を維持し、遭難者の生存確率の向上を図ることができる。
【課題を解決するための手段】
【００１６】
本発明に係る携帯端末装置は、
救助の要請を表す救助要請ファイルが添付された救助要請メールを送信する送信部と、
前記送信部が送信した前記救助要請メールに対する返信メールであって、要請された救助に関する情報を表すとともに識別子を有する救助情報ファイルが添付された返信メールを救助情報メールとして受信する受信部と、
音声を出力する音声出力部と、
前記救助情報ファイルの前記識別子と、前記音声出力部から出力する音声メッセージとを対応付けたファイル対応情報を記憶するファイル対応情報記憶部と、
前記受信部により前記救助情報メールが受信されると、受信された前記救助情報メールに添付された前記救助情報ファイルと前記ファイル対応情報記憶部に記憶された前記ファイル対応情報とに基づいて、前記音声出力部から前記音声メッセージを出力させる制御部とを備えることを特徴とする。
【発明の効果】
【００１７】
本実施の形態に係る携帯端末装置によれば、送信部が救助の要請を表す救助要請ファイルが添付された救助要請メールを送信し、受信部が要請された救助に関する情報を表すとともに識別子を有する救助情報ファイルが添付された返信メールを救助情報メールとして受信し、制御部が前記救助情報メールに添付された前記救助情報ファイルと前記救助情報ファイルの前記識別子と前記音声出力部から出力する音声メッセージとを対応付けたファイル対応情報とに基づいて、前記音声出力部から前記音声メッセージを出力させるので、救助の要請に対する返信メールとして救助情報メールを確実に受信することができるとともに、受信した救助情報メールの内容を音声メッセージで出力することができるので、遭難者の生存意欲を維持し、遭難者の生存確率の向上を図ることができる。
【図面の簡単な説明】
【００１８】
【図１】実施の形態１に係る救助システムのシステム構成の一例を示す図である。
【図２】実施の形態に係る救助システムの概要を説明するための模式図である。
【図３】（ａ）が実施の形態１に係るビーコン端末の外観の一例を示す外観斜視図であり、（ｂ）がビーコン端末の外観の他の例を示す外観斜視図である。
【図４】実施の形態１に係るビーコン端末のブロック構成の一例を示すブロック構成図である。
【図５】実施の形態１に係るビーコン端末、メール端末のハードウェア構成の一例を示す図である。
【図６】実施の形態１に係る救助システムにおける救助方法の救助要請処理（工程）及び救助応答処理（工程）の動作の一例を示すフロー図である。
【図７】実施の形態１に係る救助システムにおける救難信号送信処理（工程）の動作の一例を示すフローチャートである。
【図８】実施の形態１に係るビーコン端末の動作をまとめた表である。
【図９】実施の形態１に係るメール端末の記憶機器に記憶されるファイル格納テーブルの構成の一例を示す図である。
【図１０】実施の形態１に係る添付ファイル対応情報の構成の一例を示す図である。
【図１１】実施の形態１に係るビーコン端末の添付ファイル対応処理（工程）の動作の一例を示すフローチャートである。
【図１２】実施の形態１に係るビーコン端末とその他の救助要請方式との効果等の比較表である。
【図１３】実施の形態２に係る救助システムにおける救助方法の救助要請処理（工程）及び救助応答処理（工程）の動作の一例を示すフロー図である。
【図１４】実施の形態３に係る救助システムのシステム構成の一例を示す図である。
【図１５】実施の形態３に係る救助システムを用いたビジネスモデル構成の一例を示す模式図である。
【図１６】従来の救助システムの技術（ＥＰＩＲＢ、ＰＬＢ）の概要を説明するための模式図及び従来の救助システム（ＥＰＩＲＢ、携帯電話、ＰＬＢ）の適用対象における効果を比較する比較表である。
【発明を実施するための形態】
【００１９】
実施の形態１．
図１は、本実施の形態に係る救助システム５００のシステム構成の一例を示す図である。図２は、本実施の形態に係る救助システム５００の概要を説明するための模式図である。
図１及び図２を用いて、本実施の形態に係る救助システム５００の概要について説明する。
【００２０】
図１に示すように、救助システム５００は、ビーコン端末１００と、複数のメール端末３００とを備える。
ビーコン端末１００は、救助要請メール１１０を送信する携帯端末装置の一例である。
メール端末３００は、救助要請メール１１０に対する返信メールを救助情報メールとして送信する受信端末装置の一例である。メール端末３００の各々は、記憶機器３５０を備える。
【００２１】
複数のメール端末３００は、公衆ネットワーク６００を介してメールサーバ４００と接続される。
ビーコン端末１００は、中継用衛星２００を経由してメールサーバ４００に接続される。
ビーコン端末１００と複数のメール端末３００とは、中継用衛星２００、メールサーバ４００、公衆ネットワーク６００を介して、メールの送受信を実行する。
【００２２】
メールサーバ４００は、例えば、通常の通信キャリアが提供しているメールサーバである。メールサーバ４００は、メール端末３００に対して、即時かつ能動的にメールを転送するプッシュ型であることが好ましい。
中継用衛星２００は、既存の通信衛星であり、例えば、衛星電話用の通信衛星（例えば、イリジウム衛星）、準天頂衛星などである。
【００２３】
図２の（１）に示すように、本実施の形態に係る救助システム５００に加入することにより、加入者である船舶の乗組員、登山者等はビーコン端末１００を携帯する。
図２の（２）に示すように、船舶事故、乗組員の落下事故、雪山遭難などの事故が発生すると、事故に遭った乗組員、登山者などの遭難者は、ビーコン端末１００からワンタッチ動作で救難信号をメールで送信する。このメールを救助要請メール１１０とする。救助要請メール１１０には、ＧＰＳ衛星から受信した自己の遭難位置が含まれる。
ビーコン端末１００からワンタッチ動作で救助要請メール１１０を送信する方法については、後で詳しく説明する。
【００２４】
図２の（３）に示すように、救助要請メール１１０は、ビーコン端末１００から中継用衛星２００、メールサーバ４００を経由し、複数のメール端末３００に送信される。
例えば、中継用衛星２００がイリジウム衛星の場合、現状では５つのメールアドレスを登録することができ、この５つのメールアドレスに対して同報通信が可能である。
また、例えば、中継用衛星２００が準天頂衛星の場合、準天頂衛星は日本の上空近傍に位置する衛星であるため、山岳遭難者からの救助要請信号の伝達性を格段に向上させることができる。また、実用準天頂衛星システムにより東シナ海、南シナ海並びに豪州付近の海域での海難救助システムを容易に構築することができる。
【００２５】
図２の（４）に示すように、メール端末３００は、救助要請メール１１０を受信する。メール端末３００は、本実施の形態に係る救助システム５００に加入する際に加入者により予め登録された複数のメールアドレスに対応する端末である。
図２の（５）に示すように、救助要請メール１１０の受信者は、予め登録されている返信用の添付ファイルを遭難者に対しメール返送する。救助要請メール１１０の受信者から遭難者に返信されるメールには、受信者が救助要請メール１１０を受理及び確認したことを通知する信号確認メール３１０と、救助の開始及び救助が到着するまでの時間等を通知する救助開始メール３２０とがある（図１参照）。図１に示すキャンセル通知メール１２０とキャンセル確認メール３３０とについては、実施の形態２において詳しく説明する。
【００２６】
図２の（６）に示すように、ビーコン端末１００は、中継用衛星２００を介して信号確認メール３１０を受信する。ビーコン端末１００は、信号確認メール３１０を受信すると、自動的にＬＥＤランプが点灯、かつ、録音された音声により救難信号が受理されたことを遭難者に通知する。このように、リターンリンクにより救難信号に対する返信信号が通知されるので、遭難者の生存意欲の維持を図ることができる。
【００２７】
図２の（７）に示すように、救助要請メール１１０の受信者は、信号確認メール３１０を送信すると、速やかに救助機関に救助を要請する。例えば、海難事故の場合１１８番（海上保安庁）、山岳事故の場合は１１０番（警察）あるいは山岳救助隊等に通報する。
図２の（８）に示すように、救助要請メール１１０の受信者は、救助機関に救助を要請し、救助が開始されたことを示す救助開始情報、救助が到着するまでの予想時間である到着予想時間等を添付ファイルとして添付した救助開始メール３２０をビーコン端末１００に送信する。また、救助開始メール３２０を送信する前に、救助の要請が完了したことを遭難者に通知する救助要請完了メールをビーコン端末１００に送信してもよい。
【００２８】
図２の（９）に示すように、ビーコン端末１００は、中継用衛星２００を介して救助開始メール３２０を受信する。ビーコン端末１００は、救助開始メール３２０を受信すると、自動的にＬＥＤを点灯し、かつ録音された音声により救助開始、救助隊の予想到着時間等を遭難者に通知する。これにより、遭難者は救助が開始されたこと、及び救助隊が到着するまでの時間を知ることができ、遭難者の生存意欲の維持をより図ることができる。
【００２９】
以上で、本実施の形態に係る救助システム５００の概要についての説明を終わる。
【００３０】
図３は、（ａ）が本実施の形態に係るビーコン端末１００の外観の一例を示す外観斜視図であり、（ｂ）がビーコン端末１００の外観の他の例を示す外観斜視図である。図４は、本実施の形態に係るビーコン端末１００のブロック構成の一例を示すブロック構成図である。
図３及び図４を用いて、ビーコン端末１００の機能構成について説明する。
【００３１】
図３（ａ）（ｂ）に示すように、ビーコン端末１００は、個人が携帯する携帯端末装置である。本実施の形態では、図３（ａ）（ｂ）は手のひらサイズの略直方体であるが、図３（ｂ）は上部の厚み（Ｌ５）より、下部の厚み（Ｌ４）が薄い形状である。図３（ｂ）では、遭難者にとって握り易くするために、厚みの薄い部分を形成している。
【００３２】
ビーコン端末１００の形状は、図３（ａ）（ｂ）に限られず、持ち易い流線形、楕円体などでもよい。重さは例えば、１００ｇ以上２００ｇ以下が好ましく、１５０ｇ以下であるとより好ましい。また、ビーコン端末１００は、防水機能、耐圧機能、温度に対する耐久機能等、救難信号発信用の携帯端末装置として必要な機能を備えている。
【００３３】
ビーコン端末１００の寸法は、できる限り小型であることが好ましいが、例えば、横幅（Ｌ１）５０ｍｍ×厚さ（Ｌ３）３０ｍｍ×高さ（Ｌ２）１３０ｍｍ以下であることが好ましい。
なお、ビーコン端末１００の形状、サイズ、重さ、機能などは、ビーコン端末１００の使用が想定される環境下において、所定時間にわたりその機能を発揮することができれば、どのような態様でも構わない。
【００３４】
図３に示すように、ビーコン端末１００は、表面に、ＨＥＬＰボタン１０１（救助ボタンの一例）、ＣＡＮＣＥＬボタン１０２（取消ボタンの一例）、複数のＬＥＤ１０３（発光部の一例）、スピーカ１０４（音声出力部の一例）を備える。
ＨＥＬＰボタン１０１、ＣＡＮＣＥＬボタン１０２は、互いに異なる色のボタンである。例えば、ＨＥＬＰボタン１０１は赤ボタン、ＣＡＮＣＥＬボタン１０２は、緑ボタンとする。また、ＨＥＬＰボタン１０１、ＣＡＮＣＥＬボタン１０２は、ボタンの前面に樹脂製のボタンカバーを備え、このボタンカバーを割って押すタイプのボタンであることが好ましい。これは、ＨＥＬＰボタン１０１、ＣＡＮＣＥＬボタン１０２を押下したことが遭難者にわかるようにするためである。
【００３５】
複数のＬＥＤ１０３は、例えば、発する光の色が互いに異なる３種類のＬＥＤから構成される。
例えば、黄色のＬＥＤ（図３（ｂ）において、「ＳＮＴ」と記載されたボタン）は、救助要請メール１１０の送信中、あるいは、キャンセル通知メール１２０の送信中を表す。
例えば、青色のＬＥＤ（図３（ｂ）において、「ＲＣＶ」と記載されたボタン）は、救助要請メール１１０が受信者により受理されたことを表す。すなわち、信号確認メール３１０を受信すると、点灯される。
例えば、緑色のＬＥＤ（図３（ｂ）において、「ＲＳＣ」と記載されたボタン）は、救助活動が開始されたことを表す。すなわち、救助開始メール３２０を受信すると、点灯される。また、点灯方法により救助隊が到着するまでの予想時間を表す。
【００３６】
スピーカ１０４は、再生される音声メッセージを出力する。スピーカ１０４から出力される音声メッセージは、通常の音声よりも大きな音（目覚まし程度の音量）で再生する。これは、例えば、音声が周囲の環境の音（波の音、吹雪の音等）にかき消されないようにして、遭難者に確実に届けるためである。また、スピーカ１０４から出力される音声は、複数回繰り返される。例えば、５回以上繰り返して出力される。
【００３７】
図４のビーコン端末１００のブロック構成図に示すように、ビーコン端末１００は、ＨＥＬＰボタン１０１、ＣＡＮＣＥＬボタン１０２、複数のＬＥＤ１０３、スピーカ１０４、ＧＰＳアンテナ１０５、ＧＰＳ受信部１０６、通信アンテナ１０７、送信部１０８、受信部１０９、電源部１４０、制御部１３０、記憶装置１５０を備える。
制御部１３０は、ＧＰＳ受信制御部１３１、メール生成部１３２、通信制御部１３３、ＬＥＤ制御部１３４、音声制御部１３５、電源制御部１３６を備える。
【００３８】
電源部１４０は、例えば、リチウム電池である。電源部１４０は、救助要請メール１１０の送出から救助の完了までの全てのシーケンスが完了する最大動作時間として４８時間以上を目標とする。なお、最大動作時間は、長ければ長いほうが好ましい。
【００３９】
記憶装置１５０は、アドレス格納部１５１、添付ファイル格納部１５２、音声格納部１５３、ファイル対応情報１５４を備える。ファイル対応情報１５４はファイル対応情報記憶部により記憶装置１５０に記憶される。
【００４０】
アドレス格納部１５１には、予め登録されている複数のメールアドレスが記憶される。この複数のメールアドレスは、救助要請メール１１０の宛先に設定されるメールアドレスである。ビーコン端末１００がイリジウム衛星に対してメールを発信するイリジウムメール端末の場合、メールアドレスは最大５つまで登録することができる。なお、登録するメールアドレスの数は、いくつでも構わない。
登録するメールアドレスは、例えば、救助システム５００に加入契約する際に、加入者により救助システム加入画面から入力される。そして、ビーコン端末１００が加入者に納品されるときには、既に複数のメールアドレスが記憶装置１５０のアドレス格納部１５１に登録された状態であるものとする。
【００４１】
登録するメールアドレスに対応する受信者（救助者）は、例えば、会社の救助対策機関、家族、同僚などである。可能であれば、民間の救助機関、公的な救助機関を登録してもよい。また、メール端末３００は、例えば、ＰＣ（パーソナルコンピュータ）、スマートフォン、タブレット端末、携帯電話機などである。
【００４２】
ファイル格納部１５２には、ＨＥＬＰボタン１０１が押下されたときに救助要請メール１１０に添付される「ＨＥＬＰ用ファイル」と、ＣＡＮＣＥＬボタン１０２が押下されたときにキャンセル通知メール１２０（取消通知メールの一例）に添付される「ＣＡＮＣＥＬ用ファイル」とが格納される。例えば、「ＨＥＬＰ用ファイル」はファイル名が「ＨＥＬＰ」であり、「ＣＡＮＣＥＬ用ファイル」はファイル名が「ＣＡＮＣＥＬ」である。「ＨＥＬＰ用ファイル」は、救助の要請を表す救助要請ファイルの一例であり、ファイル名「ＨＥＬＰ」は、救助要請ファイルを識別する識別子の一例である。また、ＣＡＮＣＥＬ用ファイル」は、救助の要請の取消を表す取消情報ファイルの一例であり、ファイル名「ＣＡＮＣＥＬ」は、取消情報ファイルを識別する識別子の一例である。
【００４３】
音声格納部１５３には、救助要請メール１１０の送信が完了したときに出力する「救難信号は受信されました」、救助開始メール３２０を受信したときに出力する「救助が開始されました。救助隊はＮ時間以内に到着予定です」などの録音された音声メッセージが格納されている。
【００４４】
ファイル対応情報１５４は、受信したメールに添付された添付ファイルと、添付ファイルを受信した場合のビーコン端末１００の動作とを対応付けた情報である。ファイル対応情報１５４については、後で詳しく説明する。
【００４５】
図５は、本実施の形態に係るビーコン端末１００、メール端末３００のハードウェア構成の一例を示す図である。
図５を用いて、ビーコン端末１００、メール端末３００のハードウェア構成例について説明する。
【００４６】
ビーコン端末１００、メール端末３００はコンピュータを備え、ビーコン端末１００、メール端末３００の各要素をプログラムで実現することができる。
【００４７】
ビーコン端末１００、メール端末３００のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。
【００４８】
演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）である。
外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）である。
【００４９】
メール端末３００における通信装置９０４は、例えば通信ボード等であり、ＬＡＮ（Ｌｏｃａｌ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）等に接続されている。通信装置９０４は、ＬＡＮに限らず、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ・Ｐｒｏｔｏｃｏｌ・Ｖｉｒｔｕａｌ・Ｐｒｉｖａｔｅ・Ｎｅｔｗｏｒｋ）、広域ＬＡＮ、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ・Ｔｒａｎｓｆｅｒ・Ｍｏｄｅ）ネットワークといったＷＡＮ（Ｗｉｄｅ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）、あるいは、インターネットに接続されていても構わない。ＬＡＮ、ＷＡＮ、インターネットは、公衆ネットワークの一例である。
【００５０】
メール端末３００における入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。マウスの代わりに、タッチパネル、タッチパッド、トラックボール、ペンタブレット、あるいは、その他のポインティングデバイスが用いられても構わない。ビーコン端末１００における入出力装置９０５は、例えば、各種ボタン、ＬＥＤ、スピーカなどである。
【００５１】
プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、ブロック構成図に示す「〜部」として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、ブロック構成図に示す「〜部」の機能を実現するプログラムを実行する。
また、アプリケーションプログラムも外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１により実行される。
また、「〜テーブル」等の情報も外部記憶装置９０２に記憶されている。
【００５２】
また、本実施の形態の説明において、「〜の判断」、「〜の判定」、「〜の抽出」、「〜の検知」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の生成」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３に記憶されている。
また、ビーコン端末１００、メール端末３００が受信したデータが主記憶装置９０３に記憶される。
また、暗号鍵・復号鍵や乱数値やパラメータが、主記憶装置９０３に記憶されても構わない。
【００５３】
なお、図５の構成は、あくまでもビーコン端末１００、メール端末３００のハードウェア構成の一例を示すものであり、ビーコン端末１００、メール端末３００のハードウェア構成は図５に記載の構成に限らず、他の構成であっても構わない。
【００５４】
図６は、本実施の形態に係る救助システム５００における救助方法の救助要請処理（工程）及び救助応答処理（工程）の動作の一例を示すフロー図である。
図６において、救助要請処理は遭難者側における処理であり、救助応答処理は受信者側における処理である。
【００５５】
＜Ｓ１０２：救難信号送信処理（工程）（送信処理の一例）＞
海難事故、山岳事故等が発生すると（Ｓ１０１）、遭難者は携帯しているビーコン端末１００から救助要請メール１１０を発信する（Ｓ１０２）。
【００５６】
図７は、本実施の形態に係る救助システム５００における救難信号送信処理（工程）の動作の一例を示すフローチャートである。図８は、本実施の形態に係るビーコン端末１００の動作をまとめた表である。
【００５７】
Ｓ１０２１において、遭難者により、ビーコン端末１００のＨＥＬＰボタン１０１が押下される。
ＨＥＬＰボタン１０１が押下されると、Ｓ１０２２において、ＧＰＳ受信制御部１３１は、ＧＰＳ受信部１０６がＧＰＳ衛星から現在位置（以下、ＧＰＳ現在位置（遭難位置情報））を取得するように制御する。ＧＰＳ受信部１０６は、ＧＰＳアンテナ１０５を用いて、ＧＰＳ衛星からＧＰＳ現在位置を取得する。
【００５８】
Ｓ１０２３において、メール生成部１３２は、救助要請メール１１０を生成する。メール生成部１３２は、アドレス格納部１５１に記憶されている全てのメールアドレスを救助要請メール１１０の宛先に設定する。また、メール生成部１３２は、添付ファイル格納部１５２からＨＥＬＰ用ファイルを取得し、救助要請メール１１０に添付する。また、メール生成部１３２は、ＧＰＳ受信部１０６により取得されたＧＰＳ現在位置を救助要請メール１１０に含める。
【００５９】
ここで、例えば、ＧＰＳ受信制御部１３１は、ＧＰＳ受信部１０６がＧＰＳ衛星から定期的に現在位置（以下、経度と緯度とを含む定期位置情報の一例）を取得するように制御してもよい。ＧＰＳ受信制御部１３１は、ＧＰＳ受信部１０６により取得された定期位置情報を記憶装置１５０に記憶しておく。もし、ＧＰＳ現在位置（遭難位置情報）を取得できなかった場合には、メール生成部１３２は、記憶装置１５０に記憶された定期位置情報を救助要請メール１１０に含める。
【００６０】
Ｓ１０２４において、通信制御部１３３は、メール生成部１３２により生成された救助要請メール１１０を、送信部１０８が通信アンテナ１０７を介して送信するように制御する。送信部１０８は、救助要請メール１１０を中継用衛星２００に対し、通信アンテナ１０７を介して発信する。
【００６１】
図８に示すように、救助要請メール送信の際には、ビーコン端末１００は救助要請メールに「ＨＥＬＰ用ファイル」を添付して送信する。また、ビーコン端末１００は黄色ＬＥＤ１０３を点滅させ、スピーカ１０４からは「救難信号送出中」と音声が出力させる。
Ｓ１０２５において、ＬＥＤ制御部１３４は、通信制御部１３３による救助要請メール１１０の送信中に、ＬＥＤを点滅させる。例えば、黄色ＬＥＤを点滅させる。また、音声制御部１３５は、通信制御部１３３による救助要請メール１１０の送信中に、「救難信号送信中」の音声データを繰り返し再生し、スピーカ１０４から繰り返し出力する。
また、送信部１０８による救助要請メール１１０の送信が完了すると、Ｓ１０２５において、ビーコン端末１００は黄色ＬＥＤを常時点灯させることで送信完了を示し、同時に録音音声「救難信号は送信されました」を、例えば、５回スピーカ１０４から出力する。
【００６２】
このように、ビーコン端末１００は、救助要請メール１１０の送信中に、ＬＥＤを点滅させたり、「救難信号送信中」の音声データをスピーカ１０４から出力したりすることにより、遭難者に安心感を与え、生存意欲を維持させることができる。
以上で、ビーコン端末１００の救難信号送信処理についての説明を終わる。
【００６３】
次に、図６に戻り、救助要請メール１１０を受信する受信者側の救難信号確認処理（Ｓ２０１〜Ｓ２０３）について説明する。
Ｓ２０１において、メール端末３００は、ビーコン端末１００から発信された救助要請メール１１０を、中継用衛星２００、メールサーバ４００を経由して受信する。
このとき、メールサーバ４００は、プッシュ型のメールサーバであることが好ましい。プッシュ型であれば、メールサーバ４００に救助要請メール１１０が配信されると、その後、自動的にメール端末３００に配信されるからである。
また、メール端末３００の受信者は、事故発生時にビーコン端末１００から救助要請メール１１０を送信する相手として、予め登録された人物である。よって、この受信者は、救助要請メール１１０を受信した場合には、アラーム音声メッセージ、アラーム音、画面強調表示などがメール端末３００において出力されるように設定し、直ちに救助要請メール１１０を確認できるように、工夫しておくことが好ましい。
メール端末３００が救助要請メール１１０を受信すると、受信者は救助要請メール１１０を直ちに確認する。
【００６４】
Ｓ２０２において、受信者は、速やかに救助機関に救助を要請する。例えば、海難事故の場合１１８番（海上保安庁）、山岳事故の場合は１１０番（警察）あるいは山岳救助隊等に通報する。
【００６５】
Ｓ２０３において、受信者は、ビーコン端末１００を携帯する遭難者に対し、信号確認メール３１０を送信する。
図９は、本実施の形態に係るメール端末３００の記憶機器３５０に記憶されるファイル格納テーブル３５１の構成の一例を示す図である。
図９に示すように、メール端末３００の記憶機器３５０には、ファイル格納テーブル３５１が登録されている。ファイル格納テーブル３５１は、加入者が救助システム５００に加入すると、救助要請メール１１０を受信するメール端末として予め登録された複数のメール端末３００のそれぞれの記憶機器３５０に登録される。
【００６６】
図９に示すように、ファイル格納テーブル３５１には、添付ファイルと、その添付ファイルが示す返信内容とが対応付けられている。
ファイル格納テーブル３５１は、救助に関する情報である返信内容と、遭難者に返信する救助情報メールに添付する添付ファイル（救助情報ファイル）とを対応付けて記憶する救助情報対応テーブルの一例である。救助情報メールにはファイル格納テーブル３５１から選択された添付ファイルが添付される。
【００６７】
添付ファイルは、例えば、ファイル名を「ＲＣＶＤ」、「ＣＲＣＶＤ」、「ＲＱＳＴＤ」などとし、ファイルの中身は空でよい。ファイル格納テーブル３５１では、返信内容がファイル名に対応付けられており、ファイルの中身は空であるため、通信料を抑制することができる。ファイル名は、添付ファイル（救助情報ファイル）を識別する識別子の一例である。
【００６８】
Ｓ２０３では、信号確認メール３１０には、受信者によりファイル格納テーブル３５１から添付ファイル「ＲＣＶＤ」（救難信号の受理確認）が選択され、選択された添付ファイル「ＲＣＶＤ」を添付した信号確認メールが生成され、返信される。信号確認メール３１０は、メールサーバ４００、中継用衛星２００を経由して、ビーコン端末１００に送信される。
以上で、受信者側の救難信号確認処理（Ｓ２０１〜Ｓ２０３）についての説明を終わる。
【００６９】
次に、遭難者側において、受信者からの信号確認メール３１０を受信した場合の信号受理確認処理（工程）について説明する。
【００７０】
Ｓ１０３において、ビーコン端末１００は、受信者のメール端末３００から送信された信号確認メール３１０を受信する。ビーコン端末１００では、受信部１０９が通信アンテナ１０７を介して、中継用衛星２００から信号確認メール３１０を受信する。
【００７１】
このとき、ビーコン端末１００は、最初に受信した信号確認メール３１０のみを受け付け、受け付けた信号確認メール３１０の後に配信される信号確認メール３１０については破棄するとしてもよい。これは、予め登録されたメール端末３００（メールアドレス）のうちの複数のメール端末３００から信号確認メール３１０が送信される場合があるからである。本実施の形態では、複数のメール端末３００から信号確認メール３１０が配信された場合は、最初に受信した信号確認メール３１０のみを受け付けることで、遭難者側で混乱が生じないようにする。また、受信者側と遭難者側とでやり取りされるメールは、予め登録された全てのメール端末３００（メールアドレス）に同報配信するものとし、予め登録された全ての受信者が救助要請に対する救助活動に関する情報を共有することができるものとする。
【００７２】
Ｓ１０４において、ビーコン端末１００は、受信した信号確認メール３１０に基づいて、音声を自動出力し、ＬＥＤを点灯する等の添付ファイル対応処理を実行する。
図１０は、本実施の形態に係る添付ファイル対応情報１５４の構成の一例を示す図である。
図１１は、本実施の形態に係るビーコン端末１００の添付ファイル対応処理（工程）の動作の一例を示すフローチャートである。
【００７３】
Ｓ１０４１において、メール生成部１３２は、受信部１０９が受信した信号確認メール３１０に添付されている添付ファイルを取得する。メール生成部１３２は、取得した添付ファイルに基づいて、記憶装置１５０に記憶されているファイル対応情報１５４を参照する。メール生成部１３２は、取得した添付ファイルに対応するファイル対応情報１５４のレコードを取得する。
【００７４】
図１０に示すように、ファイル対応情報１５４は、添付ファイルと、添付ファイルが示す内容と、ＬＥＤの点灯状態と、音声通知とを対応付けた情報である。音声通知の実体データ（録音音声）は音声格納部１５３に格納されている。ファイル対応情報１５４の音声通知と、音声格納部１５３に格納された録音音声とは紐付けられている。
【００７５】
Ｓ１０４１では、メール生成部１３２は、信号確認メール３１０の添付ファイル「ＲＣＶＤ」に基づいて、添付ファイル「ＲＣＶＤ」に対応するファイル対応情報１５４の１レコード目を取得する。ファイル対応情報１５４の１レコード目は、「ＲＣＶＤ」、「救難信号受理確認」、「青点滅」、「救難信号は受信されました。誤発信ならキャンセルボタンを押して下さい」という情報が含まれている。
【００７６】
Ｓ１０４２において、ＬＥＤ制御部１３４は、メール生成部１３２が取得したファイル対応情報１５４に基づいて、ＬＥＤ１０３を制御する。ここでは、ＬＥＤ制御部１３４は、ファイル対応情報１５４の１レコード目に基づいて、青色ＬＥＤを点滅させる。
【００７７】
Ｓ１０４３において、音声制御部１３５は、メール生成部１３２が取得したファイル対応情報１５４に基づいて、録音音声を再生し、スピーカ１０４から出力する。ここでは、音声制御部１３５は、ファイル対応情報１５４の１レコード目に基づいて、音声格納部１５３に格納されている「救難信号は受信されました。誤発信ならキャンセルボタンを押して下さい」をスピーカ１０４から出力する。音声格納部１５３は、録音音声「救難信号は受信されました。誤発信ならキャンセルボタンを押して下さい」を、スピーカ１０４から５回繰り返し出力する。
【００７８】
このように、信号確認メール３１０を受信した場合、ビーコン端末１００は、救助要請メール１１０が受信者に受信されたことを通知するために、青色ボタンを点滅する。このとき、救助要請メール１１０の送信完了時の黄色ＬＥＤの常時点灯は解除し、黄色ＬＥＤは消灯する。同時に録音音声「救難信号は受信されました。誤発信ならキャンセルボタンを押して下さい」が５回流れる。
以上で、ビーコン端末１００の信号受理確認処理（工程）（添付ファイル対応処理（工程））についての説明を終わる。
【００７９】
次に、受信者側において、救助活動の開始及び救助隊が到着するまでの予想時間（到着予想時間）を遭難者に通知する救助開始メール３２０を通知する救助開始送信処理（工程）について説明する。
受信者は、救助機関に救助を要請することにより、救助の開始時期、及び救助隊が到着するまでの予想時間を知ることができる。受信者が救助機関に救助を要請すると、直ちに救助機関において救助活動が開始されることになる。
そこで、Ｓ２０４において、受信者は、救助活動の開始及び到着予想時間が含まれる救助開始メール３２０を遭難者に送信する。
【００８０】
救助開始メール３２０には、受信者によりファイル格納テーブル３５１から選択された添付ファイルが添付される。
例えば、救助隊到着予想時間が４時間以内の場合、受信者により添付ファイル「ＥＴＡ４Ｈ」が選択され、救助開始メール３２０に添付される。救助開始メール３２０は、メール端末３００から、メールサーバ４００、中継用衛星２００を経由して、ビーコン端末１００に送信される。
【００８１】
救助要請メール１１０、信号確認メール３１０、救助開始メール３２０の送受信のやり取りについては、予め登録されたメールアドレスに対応するすべての受信者によって情報が共有されていることが好ましい。
また、アドレス格納部１５１に予め登録する救難信号の送信先には、例えば、官公庁の救助機関、民間の救助サービスなどを登録してもよい。
【００８２】
以上で、受信者側において、救助の開始及び救助隊到着予想時間を遭難者に通知する救助開始メール３２０を通知する救助開始送信処理（工程）についての説明を終わる。
【００８３】
次に、遭難者側において、受信者からの救助開始メール３２０を受信した場合の救助開始通知処理（工程）について説明する。
【００８４】
Ｓ１０５において、ビーコン端末１００は、受信者のメール端末３００から送信された救助開始メール３２０を受信する。ビーコン端末１００では、受信部１０９が通信アンテナ１０７を介して、中継用衛星２００から救助開始メール３２０を受信する。
【００８５】
Ｓ１０７において、ビーコン端末１００は、受信した救助開始メール３２０に基づいて、音声自動出力、ＬＥＤ点灯等の添付ファイル対応処理を実行する。この添付ファイル対応処理は、図１１で説明した添付ファイル対応処理と同様の処理である。
【００８６】
まず、メール生成部１３２は、受信部１０９が受信した救助開始メール３２０に添付されている添付ファイルを取得する。メール生成部１３２は、取得した添付ファイルに基づいて、記憶装置１５０に記憶されているファイル対応情報１５４を参照する。メール生成部１３２は、取得した添付ファイルに対応するファイル対応情報１５４のレコードを取得する。
【００８７】
受信部１０９が救助開始メール３２０を受信した場合、メール生成部１３２は、救助開始メール３２０の添付ファイル「ＥＴＡ４Ｈ」から、ファイル対応情報１５４の５レコード目を取得する。ファイル対応情報１５４の５レコード目は、「ＥＴＡ４Ｈ」、「救助隊到着予想４時間以内」、「緑点滅」、「救助隊到着は４時間以内。頑張って下さい」という情報が含まれている。
【００８８】
ＬＥＤ制御部１３４は、メール生成部１３２が取得したファイル対応情報１５４に基づいて、ＬＥＤ１０３を制御する。ここでは、ＬＥＤ制御部１３４は、ファイル対応情報１５４の５レコード目に基づいて、緑色ＬＥＤを点滅させる。
【００８９】
例えば、ＬＥＤ制御部１３４は、救助隊到着は４時間以内の場合、緑色ＬＥＤ１０３を次のように点灯制御する。緑色ＬＥＤ１０３を、４回点滅、所定間隔、４回点滅、所定間隔、４回点滅、所定間隔、・・・、という点灯制御を繰り返し、到着時間まで４時間であることを遭難者に通知してもよい。ＬＥＤ制御部１３４は、救助開始メール３２０を受信した時点から１時間後には、残り３時間を示すように、３回点滅、所定間隔、３回点滅、所定間隔、・・・、とＬＥＤ点滅方式を変更してもよい。
【００９０】
このように、救助開始メール３２０を受信した場合、ビーコン端末１００は、救助が開始されたことを通知するために、緑色ＬＥＤを点滅する。このとき、救助要請メール１１０が受信者に受理されたことを通知する青色ＬＥＤの点滅は解除し、青色ＬＥＤは消灯する。
【００９１】
音声制御部１３５は、メール生成部１３２が取得したファイル対応情報１５４に基づいて、録音音声を再生し、スピーカ１０４から出力する。ここでは、音声制御部１３５は、ファイル対応情報１５４の５レコード目に基づいて、音声格納部１５３に格納されている「救助隊到着は４時間以内。頑張って下さい」をスピーカ１０４出力する。音声格納部１５３は、録音音声「救助隊到着は４時間以内。頑張って下さい」を、スピーカ１０４から所定間隔ごとに繰り返し出力する。また、例えば、音声格納部１５３は、救助開始メール３２０を受信した時点から１時間後には、「救助隊到着は３時間以内。頑張って下さい」と変更する。このように、音声格納部１５３は、救助開始メール３２０を受信した時点から１時間経過するごとに、救助隊が到着するまでの残り時間を出力するようにしてもよい。また、音声は３０分ごとに出力してもよい。
【００９２】
なお、救助開始メール３２０を受信した場合のＬＥＤ１０３及び音声出力の制御方法は、上述した方式に限らず、遭難者に救助の開始を通知することができれば、どのような方式でもよく、ＬＥＤと音声とをどのように組み合わせて遭難者に通知してもよい。
ビーコン端末１００が遭難者に救助開始に関する情報を通知することにより、遭難者は救助隊が到着するという希望を持つことができ、生存意欲を低減させることなく待機することができる。
【００９３】
なお、ビーコン端末１００は、所定の時点（例えば、救助開始通知処理を開始した時点）から、ホーミングモードに移行してもよい。ホーミングモードとは、方向探知用に数十ＭＨｚ〜百数十ＭＨｚの電波を間欠的に出力するモードである。
以上で、ビーコン端末１００の救助開始通知処理（工程）（添付ファイル対応処理（工程））についての説明を終わる。
【００９４】
本実施の形態では、受信者側は、信号確認メール３１０を遭難者に送信した後に、救助開始メール３２０を用いて、救助の開始及び救助隊到着予想時間を通知するとした。しかし、例えば、救助活動が開始されたとしても、救助隊が到着するまでの予想時間がなかなかわからない場合もある。このような場合には、受信者は、救助隊到着予想時間を通知する前に、救助要請が完了したことを通知する救助要請完了メールを遭難者に送信してもよい。
救助要請完了メールを遭難者に送信する場合について、簡単に説明する。この場合、受信者は、図９に示すファイル格納テーブル３５１から、「救助要請完了：ＲＱＳＴＤ」を選択し、メールに添付して救助要請完了メールとして送信する。ビーコン端末１００は、この救助要請完了メールを受信すると、図１０のファイル対応情報１５４に基づいて、緑色ＬＥＤを連続点灯するとともに、「救助要請を完了しました。待機して下さい」という録音音声をスピーカ１０４から出力する。
【００９５】
図１２は、本実施の形態に係るビーコン端末１００とその他の救助要請方式との効果等の比較表である。ＥＰＩＲＢ、携帯電話、ＰＬＢについては、図１６の説明において記載したので、ここでは、説明を省略する。
図１２に示すように、本実施の形態に係るビーコン端末１００では、２０トン以上の大型船舶、２０トン未満の小型船舶、山岳等での活動のすべての場合において、使用し、高い効果を得ることができる。ここでは、２０トン以上の大型船舶自体については、必ずＥＰＩＲＢが装備されていること、ビーコン端末１００は個人が操作するものであり船舶自体の使用がなじまないことから「不要」とした。しかし、２０トン以上の大型船舶自体についてもＥＰＩＲＢを装備した上で、さらにビーコン端末１００を装備してもよい。大型船舶自体、小型船舶自体、グループ自体については、より有効な救助活動を行うために、個人とは異なる救難信号通報先を登録しておくことできる。
【００９６】
以上のように、本実施の形態に係るビーコン端末は、周回、または静止衛星を用いて構築する救助要請システムにおいて、遭難者が携帯する個人携帯ビーコン端末が、救助要請信号と自己が測定した緯度経度情報と自己の識別コード（これらの情報を以下、まとめて救助信号と称す）をメール形式で、衛星と地上ネットワークに接続されたにメールサーバ経由であらかじめ登録したメール端末に対しワンタッチ動作で送信する機能と、救助側から返信される信号受理確認、救助活動開始に関する返信メールを受信する機能と、その返信メール内容に対応したＬＥＤ点灯に加えてその内容を携帯ビーコン端末内に記録された音声信号に自動的に変換し音声で遭難者に対して通知する機能を有する。
このように、既存衛星、既存通信方式、公衆ネットワークを使用するため、免許や公的機関への届け出が不要であり、海難事故や山岳事故に遭遇する危険性のある使用者が短期間でビーコン端末の使用を開始することができる。また、遭難者に対するリターンリンクが確実になされるので、遭難者の生存意欲を維持させることができ、生存確率向上を図ることができる。
【００９７】
また、本実施の形態に係る救助システムでは、救難信号の送付先は、公衆ネットワークに繋がった全ての種類のメール端末から複数選択され、予め登録されるものである。よって、事故に遭った場合に確実に連絡を取りたい相手を登録することができる。
【００９８】
また、本実施の形態に係るビーコン端末は、ビーコン端末が定期的に緯度、経度情報を取得して記録し、救助要請メールに含めて送信する機能を有し、かつ救助信号を送信する際に緯度、経度情報が取得できない場合には、記録された最新の緯度、経度情報を救助要請メールに含めて送信する機能を有するので、的確な遭難位置を含み救助要請メールを送信することができる。
【００９９】
また、本実施の形態に係るメール端末は、救助要請メールの信号受理確認、救助活動開始、救助隊到着予想時間のそれぞれの定型文を添付ファイルとして保存し、メール端末の使用者である受信者がそれぞれの返信メールを送付する際に、添付ファイルを選択して返信するので、受信者は速やかに信号確認メール、救助開始メールを生成し、送信することができる。
【０１００】
実施の形態２．
本実施の形態では、主に、実施の形態１と異なる点について説明する。
また、実施の形態１で説明した機能構成部と同様の機能構成部については同一の符号を付し、その説明を省略する場合があるものとする。
【０１０１】
実施の形態１で説明したように、ビーコン端末１００は信号確認メール３１０を受信すると、青色ＬＥＤを点滅するとともに、スピーカ１０４から「救難信号が受理されました。誤発信ならキャンセルボタンを押して下さい」という音声が出力される。このとき、既に救助されていた場合、あるいは、実際に誤発信、誤動作してしまった場合などに、救助要請メール１１０の送信をキャンセルしたい場合がある。
本実施の形態では、上記の場合に、救助要請メール１１０の送信をキャンセルする方式について説明する。
【０１０２】
図１３は、本実施の形態に係る救助システム５００における救助方法の救助要請処理（工程）及び救助応答処理（工程）の動作の一例を示すフロー図である。
遭難者側の救難信号送信処理（Ｓ１０１〜Ｓ１０２）、受信者側の救難信号確認処理（Ｓ２０１〜Ｓ２０３）、遭難者側の信号受理確認処理（添付ファイル対応処理）（Ｓ１０３〜Ｓ１０４）については、実施の形態１で説明した処理と同様であるため、説明を省略する。
また、本実施の形態は、救助要請メール１１０の送信をキャンセルしたい場合の説明であるため、実施の形態１で遭難者として説明していたものを本実施の形態では利用者として説明する。遭難者も利用者も同様に、ビーコン端末１００を利用するものである。
【０１０３】
救助要請メール１１０の送信をキャンセルしたい場合、Ｓ１０３１において、利用者はビーコン端末１００のＣＡＮＣＥＬボタン１０２を押下する。ＣＡＮＣＥＬボタン１０２が押下されると、ビーコン端末１００は、キャンセル通知メール１２０を生成し、中継用衛星２００に発信する。
【０１０４】
以下に、ビーコン端末１００がキャンセル通知メール１２０を生成し送信する動作について説明する。
キャンセル通知メール１２０は、受信者からの信号確認メール３１０に対する返信として生成され、受信者に送信される。
利用者により、ビーコン端末１００のＣＡＮＣＥＬボタン１０２が押下されると、メール生成部１３２は、添付ファイル格納部１５２からＣＡＮＣＥＬ用ファイルを取得し、キャンセル通知メール１２０に添付する。
通信制御部１３３は、メール生成部１３２により生成されたキャンセル通知メール１２０を、送信部１０８が通信アンテナ１０７を介して送信するように制御する。送信部１０８は、キャンセル通知メール１２０を中継用衛星２００に対し、通信アンテナ１０７を介して発信する。
【０１０５】
図８に示すように、キャンセル通知メール１２０を送信する際には、ビーコン端末１００はキャンセル通知メール１２０に「ＣＡＮＣＥＬ用ファイル」を添付して送信する。また、ビーコン端末１００は黄色ＬＥＤ１０３を連続点灯させ、スピーカ１０４からは「キャンセル信号送出中」と音声が出力させる。
ＬＥＤ制御部１３４は、通信制御部１３３によるキャンセル通知メール１２０の送信中に、黄色ＬＥＤ１０３を連続点灯させる。例えば、黄色ＬＥＤを点滅させる。また、音声制御部１３５は、通信制御部１３３によるキャンセル通知メール１２０の送信中に、「キャンセル信号送出中」の音声データを再生し、スピーカ１０４から繰り返し出力する。
【０１０６】
次に、受信者側でメール端末３００がキャンセル通知メール１２０を受信した場合の処理について説明する。
受信者は、キャンセル通知メール１２０を受信すると、速やかに、救助を要請した救助機関に対し、救助活動の中止を要請する（Ｓ２０３１）。Ｓ２０３２において、受信者は、キャンセル確認メール３３０を生成し、利用者側に送信する。ここで、受信者は、図９に示すファイル格納テーブル３５１から「キャンセル確認」の添付ファイル「ＣＲＣＶＤ」を選択し、選択した添付ファイル「ＣＲＣＶＤ」が添付されたキャンセル確認メール３３０を生成し、利用者側に送信する。
【０１０７】
次に、利用者側でビーコン端末１００がキャンセル確認メール３３０を受信した場合の処理につい説明する。
Ｓ１０３２において、ビーコン端末１００がキャンセル確認メール３３０を受信する。
Ｓ１０３３において、ビーコン端末１００は、キャンセル確認メール３３０に添付された添付ファイル「ＣＲＣＶＤ」に基づいて、添付ファイル「ＣＲＣＶＤ」に対応するファイル対応情報１５４のレコード（２レコード目）を取得する。ビーコン端末１００は、取得したファイル対応情報１５４のレコード（２レコード目）に基づいて、ＬＥＤ１０３を消灯するとともに、スピーカ１０４から「キャンセルされました」の音声を出力する。繰り返し「キャンセルされました」の音声を出力するとしてもよい。
【０１０８】
本実施の形態に係る救助システムは、ビーコン端末が救助側から信号受理確認の返信メールを受信した際、救助信号を誤って通報したことを知らせるキャンセル通知メールをワンタッチ動作で返信する機能を有するので、必要のない、あるいは、必要がなくなった救助活動を防ぐことができる。
【０１０９】
上述した実施の形態１，２に係る救助システム５００では、メール端末３００に対応する受信者が、ビーコン端末１００から送信された救助要請メール１１０、キャンセル通知メール１２０を直接確認し、返信メール（信号確認メール３１０、救助開始メール３２０、キャンセル確認メール３３０）を返信する構成である。この返信メールは、メール端末３００が備える通常のメールソフトを用いて受信者により生成される。
【０１１０】
しかし、メール端末３００は、メール端末３００が救助要請メール１１０を受信すると、メール端末３００が返信メール（信号確認メール３１０、救助開始メール３２０、キャンセル確認メール３３０）を受信者に生成させる機能を有する構成であってもよい。例えば、メール端末３００が救助要請メール１１０を受信すると、メール端末３００が備える救助システム実行部（装置、プログラム）が起動されるとしてもよい。
【０１１１】
メール端末３００の救助システム実行部は、受信者に対し、信号確認メール３１０の返信処理、救助要請完了メールの返信処理、救助開始メール３２０の返信処理、キャンセル確認メール３３０の返信処理のいずれかを選択させる選択画面を表示する。救助システム実行部は、選択画面から選択された処理により返信される返信メールに対応する添付ファイルを、ファイル格納テーブル３５１から自動的に取得し、返信メールに添付して遭難者に送信する。このとき、受信者は、選択画面から返信処理の種別を選択するとともに送信ボタンをクリックするだけで所望の返信メールが送信される。
なお、救助開始メールの返信の場合には、救助システム実行部は、受信者に選択画面から救助隊到着予想時間を入力させ、入力された救助隊到着予想時間に基づいて、ファイル格納テーブル３５１から添付ファイルを取得する。
【０１１２】
このように、メール端末３００側に救助システム実行部のようなアプリケーションプログラムを備えることにより、受信者がよりスピーディに返信メールを送信することができるので、遭難者が知りたい情報をより速く通知することができる。
【０１１３】
実施の形態３．
本実施の形態では、主に、実施の形態１，２に追加する点について説明する。
また、実施の形態１，２で説明した機能構成部と同様の機能構成部については同一の符号を付し、その説明を省略する場合があるものとする。
【０１１４】
図１４は、本実施の形態に係る救助システム５００のシステム構成の一例を示す図である。図１５は、本実施の形態に係る救助システム５００を用いたビジネスモデル構成の一例を示す模式図である。
【０１１５】
図１４に示すように、本実施の形態では、救助要請メール１１０が送信されるメールアドレスのひとつに、保険会社８００が備える保険会社端末装置８１０が設定されている。
この保険会社端末装置８１０は、上述したメール端末３００のような、返信メール（信号確認メール３１０、救助開始メール３２０、キャンセル確認メール３３０）の返信機能は有さず、ビーコン端末１００とメール端末３００との通信履歴を通信履歴情報８１１に蓄積する。
【０１１６】
図１５に示すように、保険会社８００は、救助システム５００に加入した加入者と保険契約を結んでいる。また、保険会社８００は、救助システム５００とサービス契約を結ぶことにより、加入者のビーコン端末１００とメール端末３００との通信履歴を通信履歴情報８１１に蓄積することができるものとする。
保険会社８００は、この通信履歴情報８１１を利用して事故の情報を把握し、保険金支払いの準備をしたり、この通信履歴情報８１１を保険料算定、保険金支払判定の参考に用いたりすることができる。
【０１１７】
ここで、上記の実施の形態１〜３に係る救助システム、ビーコン端末、メール端末の有効性についてまとめる。
（１）既存衛星と既存のネットワークを使用するため、ＧＭＤＳＳ（Ｇｌｏｂａｌ  Ｍａｒｉｔｉｍｅ  Ｄｉｓｔｒｅｓｓ  ａｎｄ  Ｓａｆｅｔｙ  Ｓｙｓｔｅｍ  ：海上における遭難及び安全に関する世界的な制度）規定、電波法の新たな整備などが不要となり、即日、導入が可能となる。
（２）既に整備されている１１８番、１１０番、１１９番への緊急通報により救助活動が開始されるため、新たな救助機関や監視システムの設置も不要である。
（３）遭難者が、リターンリンクによって緊急通報の受理確認、救助開始、救助までの予想待機時間等を認識できるため、存命意欲の大幅な向上と共に救助成功確率が大幅に向上する。
（４）遭難者がリターンリンクで着信するメールを、ビーコン端末側で自動判読して、予め録音された「通報受理確認」、「救助開始、予想待機時間」に関するメッセージを自動再生するため、体が不自由な状態においても安心感を享受することが可能となる。万一のビーコン端末のメッセージ機能損傷に備え、ＬＥＤ点灯機能をリダンダンシー機能として付加している。
（５）メール受信者を、あらかじめ複数登録することによって、メールの読み忘れ確率を大幅に軽減することができる。
（６）メール受信者を、例えば、自分が乗る船のメールアドレスを登録しておけば、船からの落下事故の際には逸早く自船が検知して救助活動ができるため、遠方からの救助を待つ必要が無く、救助できる確率が飛躍的に向上する。
（７）万一の誤報の際には、「キャンセルボタン」押下によってその確認がなされるため、無駄な救助開始を回避することができる。
（８）救助開始メールを受信後、自動的にホーミングモードに切り替わるとしてもよい。この機能は、特に海流等で遭難者の位置が変わる海難救助に対して有効である。
（９）送受するメールを件名のみとし、最小パケットの伝送により通信費を節約できる。（１０）ビーコン端末は、ＧＰＳ受信機能、メール送受信機能に特化した構成の、衛星携帯電話より大幅に安価となる。
（１１）救助者が操作するメール端末がリターンリンクを容易に提供するための機能を備えたメール端末であり、当該救助システムの構築のために、携帯ビーコン端末と既存のメール端末以外の装備が必要なく、容易に構築が可能であるとともに新たな法整備や衛星を用いた救助システムにおける国際規格に一切縛られない救助システムを提供することで、即時導入可能、安価、かつ遭難者の生存確率が向上する。
（１２）コスパスサーサット衛星を用いる場合には、救難信号が世界各国の救助機関に発信されるが、本実施の形態に係る救助システムによれば、所定の機関の範囲内（例えば、「防衛省、海上保安庁、海上警察等の範囲内」）に閉じたシステムとして保証することができる。
【０１１８】
上記実施の形態１〜３の説明では、送信部、受信部、ＧＰＳ受信部、ＧＰＳ受信制御部、メール生成部、通信制御部、ＬＥＤ制御部、音声制御部、電源制御部、アドレス格納部、ファイル格納部、音声格納部、ファイル対応情報がそれぞれ独立した機能ブロックとしてビーコン端末を構成している。しかし、このような構成に限られるわけではなく、例えば、ＧＰＳ受信制御部、メール生成部をひとつの機能ブロックで実現し、ＬＥＤ制御部、音声制御部、電源制御部をひとつの機能ブロックで実現し、送信部、受信部、ＧＰＳ受信部をひとつの機能ブロックで実現し、アドレス格納部、ファイル格納部、音声格納部、ファイル対応情報をひとつの機能ブロックで実現してもよい。あるいは、これらの機能ブロックを、他のどのような組み合わせでビーコン端末を構成しても構わない。
また、上記実施の形態１〜３のビーコン端末１００は、救助要請メール１１０やキャンセル通知メール１２０を送信する際、及び信号確認メール３１０、救助開始メール３２０、キャンセル確認メール３３０を受信した際に、それぞれに対応した音声通知を行うものとしているが、必ずしも音声通知に限らず、送信内容や受信した添付ファイルの識別子に対応した各種アラーム音、音楽、その他の音を通知するように装置構成を変更することも可能である。具体的には、音声格納部１５３に記憶される音声情報やファイル対応情報１５４の音声通知内容が各種アラーム音、音楽、その他の音の情報に変更される。音には、音声、アラーム音、音楽、その他の音が含まれる。
【０１１９】
以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。
なお、以上の実施の形態は、本質的に好ましい例示であって、本発明、その適用物や用途の範囲を制限することを意図するものではなく、必要に応じて種々の変更が可能である。
【符号の説明】
【０１２０】
１００  ビーコン端末、１０１  ＨＥＬＰボタン、１０２  ＣＡＮＣＥＬボタン、１０３  ＬＥＤ、１０４  スピーカ、１０５  ＧＰＳアンテナ、１０６  ＧＰＳ受信部、１０７  通信アンテナ、１０８  送信部、１０９  受信部、１１０  救助要請メール、１２０  キャンセル通知メール、１３０  制御部、１３１  ＧＰＳ受信制御部、１３２  メール生成部、１３３  通信制御部、１３４  ＬＥＤ制御部、１３５  音声制御部、１３６  電源制御部、１４０  電源部、１５０  記憶装置、１５１  アドレス格納部、１５２  ファイル格納部、１５３  音声格納部、１５４  ファイル対応情報、２００  中継用衛星、３００  メール端末、３１０  信号確認メール、３２０  救助開始メール、３３０  キャンセル確認メール、３５０  記憶機器、３５１  ファイル格納テーブル、４００  メールサーバ、５００  救助システム、８００  保険会社、８１０  保険会社端末装置、８１１  通信履歴情報、９０１  演算装置、９０２  外部記憶装置、９０３  主記憶装置、９０４  通信装置、９０５  入出力装置。
【図１】
2015201803.tif 000003
【図２】
2015201803.tif 000004
【図３】
2015201803.tif 000005
【図４】
2015201803.tif 000006
【図５】
2015201803.tif 000007
【図６】
2015201803.tif 000008
【図７】
2015201803.tif 000009
【図８】
2015201803.tif 000010
【図９】
2015201803.tif 000011
【図１０】
2015201803.tif 000012
【図１１】
2015201803.tif 000013
【図１２】
2015201803.tif 000014
【図１３】
2015201803.tif 000015
【図１４】
2015201803.tif 000016
【図１５】
2015201803.tif 000017
【図１６】
2015201803.tif 000018