WO2024236705A1

WO2024236705A1 - 携帯端末および通報解除方法

Info

Publication number: WO2024236705A1
Application number: PCT/JP2023/018158
Authority: WO
Inventors: 文明江坂
Original assignee: Maxell Ltd
Current assignee: Maxell Ltd
Priority date: 2023-05-15
Filing date: 2023-05-15
Publication date: 2024-11-21
Anticipated expiration: 2025-11-15

Abstract

誤通報などの場合にも、好適な対応が可能な技術を提供する。携帯端末１は、携帯端末１の状態に応じて、ユーザＵ１が緊急または異常または問題の状態１００１である第１の状態であると判定した場合に、所定の通報先である第１の通報先に自動通報１００２である第１の通報を自動的に行う自動通報機能Ｆ１を有する。携帯端末１は、自動通報１００２の後の時間において、携帯端末１の状態を監視し、第１の状態が解消したかどうか、または、第１の通報が誤通報であったかどうかを判定し、解消した、または、誤通報であった、と判定した場合には、第１の通報に関する解除を伝えるための解除通知１００３を第１の通報先に行う解除通知機能Ｆ２を有する。

Description

携帯端末および通報解除方法

　本開示は、携帯端末などの技術に関する。

　スマートフォンやスマートウォッチなどの携帯端末（言い換えると情報端末装置など）は、当該携帯端末を所持するユーザの緊急時（言い換えると異常時、問題発生時など）に自動的に通報を行う機能（自動通報機能と記載する場合がある）を備えるものがある。例えば、最近のスマートフォンは、衝撃などに対応した加速度などのセンシングおよび判断に基づいて、ユーザが例えば転倒して立てない状態などを、緊急／異常／問題の状態として判定・検知する。そして、スマートフォンは、その状態に応じて、警察や救急などの所定の通報先へ、自動的に通報（言い換えると、自動通報、ＳＯＳ、救難信号など）を実行・送信する。このような携帯端末の自動通報機能によれば、ユーザの緊急時にすぐに救難などの対応がしやすくなり、ユーザの命を救うことができる場合もある。

　先行技術例として、特開２０２２－３７０４８号公報（特許文献１）が挙げられる。特許文献１には、モバイルデバイスが、衝撃と、衝撃前の時間でのユーザの第１の動作特性と、衝撃後の時間でのユーザの第２の動作特性とに基づいて、ユーザの転倒を判定し、それに応じて、ユーザが転倒したことを示す通知を生成する旨が記載されている。

特開２０２２－３７０４８号公報

　しかしながら、上記携帯端末の自動通報機能は、ユーザに異常などが無い状態の場合でも、自動通報が誤通報として生じる場合がある。例えば、ユーザがスキー等の運動をしていた場合に、ユーザのスマートフォンが、衝撃のセンシング等に基づいて、異常状態と判定し、実際には異常や問題が無い状態でも、自動通報が誤通報として生じる場合がある。

　上記携帯端末の自動通報機能による誤通報が生じた場合には、ユーザが困る場合がある。また、警察や救急等の通報先のシステムも、誤通報への対応にリソースが必要となり、困る場合がある。

　特許文献１のような先行技術例では、自動通報後の処理や、誤通報の場合の処理については、記載されていない。

　本開示の目的は、上記携帯端末の自動通報機能に関する技術に関して、誤通報などの場合にも、好適な対応が可能な技術を提供することである。

　本開示のうち代表的な実施の形態は以下に示す構成を有する。実施の形態の携帯端末は、自動通報機能を有する携帯端末であって、前記自動通報機能は、前記携帯端末の状態に応じて、前記携帯端末を携帯するユーザが緊急または異常または問題の状態である第１の状態であると判定した場合に、所定の通報先である第１の通報先に自動通報である第１の通報を自動的に行う機能であり、前記携帯端末は、前記自動通報が行われた場合に、前記自動通報の後の時間において、前記携帯端末の状態を監視し、前記第１の状態が解消したかどうか、または、前記第１の通報が誤通報であったかどうかを判定し、解消した、または、前記誤通報であった、と判定した場合には、前記第１の通報に関する解除を伝えるための解除通知を前記第１の通報先に行う。

　本開示のうち代表的な実施の形態によれば、上記携帯端末の自動通報機能に関する技術に関して、誤通報などの場合にも、好適な対応が可能となる。上記した以外の課題、構成および効果等については、発明を実施するための形態において示される。

実施の形態１の携帯端末を含むシステムの構成を示す図。実施の形態１の通報解除方法の概要として携帯端末と通報先との間のシーケンスを示す図。実施の形態１の携帯端末としてスマートフォンの構成例を示す図。実施の形態１の携帯端末としてスマートウォッチの構成例を示す図。実施の形態１の携帯端末のソフトウェアの構成例を示す図。実施の形態１の携帯端末の処理フロー（１－１）を示す図。実施の形態１の携帯端末の処理フロー（１－２）を示す図。実施の形態１の携帯端末の処理フロー（１－３）を示す図。実施の形態１の携帯端末の処理フロー（１－４）を示す図。実施の形態１の携帯端末の画面表示例を示す図。実施の形態１の携帯端末の画面表示例を示す図。実施の形態１の携帯端末の画面表示例を示す図。実施の形態１の携帯端末における、時間軸上でのユーザの状態に応じた自動通報および解除通知の発生を示す図。実施の形態１の携帯端末における、時間軸上でのバッテリーの状態に応じた再度自動通報などの時間間隔制御例を示す図。実施の形態１の携帯端末における、自動通報、解除通知、および関連情報の構成例を示す図。

　以下、図面を参照しながら本開示の実施の形態を詳細に説明する。図面において、同一部には原則として同一符号を付し、繰り返しの説明を省略する。図面において、構成要素の表現は、発明の理解を容易にするために、実際の位置、大きさ、形状、範囲等を表していない場合がある。

　説明上、プログラムによる処理について説明する場合に、プログラムや機能や処理部等を主体として説明する場合があるが、それらについてのハードウェアとしての主体は、プロセッサ、あるいはそのプロセッサ等で構成されるコントローラ、装置、計算機、システム等である。計算機は、プロセッサによって、適宜にメモリや通信インタフェース等の資源を用いながら、メモリ上に読み出されたプログラムに従った処理を実行する。これにより、所定の機能や処理部等が実現される。プロセッサは、例えばＣＰＵ／ＭＰＵやＧＰＵ等の半導体デバイス等で構成される。処理は、ソフトウェアプログラム処理に限らず、専用回路でも実装可能である。専用回路は、ＦＰＧＡ、ＡＳＩＣ、ＣＰＬＤ等が適用可能である。

　プログラムは、対象計算機に予めデータとしてインストールされていてもよいし、プログラムソースから対象計算機にデータとして配布されてもよい。プログラムソースは、通信網上のプログラム配布サーバでもよいし、非一過性のコンピュータ読み取り可能な記憶媒体、例えばメモリカードやディスクでもよい。プログラムは、複数のモジュールから構成されてもよい。コンピュータシステムは、複数台の装置によって構成されてもよい。コンピュータシステムは、クライアント・サーバシステム、クラウドコンピューティングシステム、ＩｏＴシステム等で構成されてもよい。各種のデータや情報は、例えばテーブルやリスト等の構造で構成されるが、これに限定されない。識別情報、識別子、ＩＤ、名前、番号等の表現は互いに置換可能である。

　［課題等］
　課題等について補足する。ユーザが転倒などした場合、携帯端末の自動通報機能は、衝撃検知に基づいて、自動通報を発生させる。例えば、携帯端末は、大きなアラート音を鳴らし、本体を振動させ、カウントダウンを開始する。ユーザがカウントダウンを止めない場合、携帯端末は、ユーザが重大な事故に遭っている等、緊急／異常／問題の状態であると判断し、自動的に緊急通報サービス等に自動通報を発信する。

　しかしながら、上記自動通報が発信された後、ユーザに異常や問題が無い状態、例えば転倒したものの怪我が無い状態などの場合や、ユーザが操作を誤って自動通報をしてしまった場合などがある。その場合には、通報先からユーザへの救難等の対応は不要であり、その自動通報は、ユーザおよび通報先にとって、基本的に不要なものとなる。

　従来、上記不要な自動通報を受けた通報先（例えば警察や救急）は、対応者がユーザに状態を確認する等の対応を行う必要があり、時間や手間等、限られたリソースを消費する。

　そこで、上記不要な自動通報が生じた場合に、あるいは、自動通報後にユーザの状態が改善した場合に、その自動通報を解除／キャンセルすること、が有用である。言い換えると、自動通報が生じたものの、ユーザに異常や問題が無いこと、通常状態に復帰したこと、あるいは、誤通報であったこと、救難等の対応を必要としていないこと等を、通報先に伝えることが有用である。

　実施の形態は、上記自動通報の発生後に、上記自動通報を解除する仕組み、後述の通報解除機能、を有する。これにより、ユーザは安心でき、通報先も対応のための時間や手間等を低減でき、限られたリソースの消費を低減できる。

　なお、自動通報の通報先の電話番号の例は以下である。
　日本において、１１０番：警察、１１９番：救急。
　中国において、１１０番：警察、１２０番または９９９番：救急。
　米国において、９１１番：警察・救急。
　欧州において、１１２番：警察・救急。

　＜実施の形態１＞
　図１～図１４を用いて、本開示の実施の形態１の携帯端末および通報解除方法について説明する。実施の形態１の携帯端末は、図１等に示すように、自動通報機能Ｆ１を備える携帯端末１である。実施の形態１の通報解除方法は、実施の形態１の携帯端末によって実行される方法である。実施の形態１の携帯端末１は、携帯端末１の状態に応じて、ユーザＵ１が緊急または異常または問題の状態１００１である第１の状態であると判定した場合に、所定の通報先（通報先のシステム２）である第１の通報先に、自動通報１００２である第１の通報を自動的に行う自動通報機能Ｆ１を有する。携帯端末１は、自動通報１００２の後の時間において、携帯端末１の状態を監視し、第１の状態が解消したかどうか、または、第１の通報が誤通報であったかどうかを判定し、解消した、または、誤通報であった、と判定した場合には、第１の通報に関する解除を伝えるための解除通知１００２を第１の通報先に行う解除通知機能Ｆ２を有する。

　［通報システム］
　図１は、実施の形態１の携帯端末１を含んだシステム全体の構成例を示す。図１のシステム（説明上、通報システムとも記載する）は、ユーザＵ１の携帯端末１と、警察や救急などの通報先のシステム２とが、通信網９を介して接続されるシステムである。また、図２には、実施の形態１の通報解除方法の概要として、図１の携帯端末１と通報先のシステム２との間での主なシーケンスを示している。

　ユーザＵ１は、実施の形態１の携帯端末１を携帯し、本通報システムでの自動通報機能Ｆ１や解除通知機能Ｆ２などの機能を利用する対象者である。携帯端末１には、自動通報機能Ｆ１や解除通知機能Ｆ２が実装されている。携帯端末１は、例えばスマートフォン１Ａやスマートウォッチ１Ｂなどが挙げられ、詳細については限定しない。ユーザＵ１は、スマートフォン１Ａとスマートウォッチ１Ｂとの両方を所持してもよい。スマートフォン１Ａとスマートウォッチ１Ｂが通信で連携してもよい。

　ユーザＵ１は、例えば歩行や運動時に転倒して倒れる、事故に遭う等、緊急／異常／問題の状態１００１になる場合がある。この状態１００１は、自動通報１００２の対象となる状態である。

　携帯端末１は、自動通報機能Ｆ１によって、ユーザＵ１のこのような異常等の状態１００１（第１の状態）を判定・検知する（図２でのステップＳ１）。すると、携帯端末１は、自動通報機能Ｆ１によって、自動通報１００２を、所定の通報先のシステム２へ送信する（図２でのステップＳ２）。

　警察や救急などの通報先のシステム２は、電話機２００１、サーバ２００２、ＰＣ２００３、携帯端末２００４などを備えており、自動通報１００２を受信する（図３でのステップＳ２）。対応者Ｕ２であるユーザＵ２は、自動通報１００２を受けて、確認や救難などの対応を行う人である。なお、対応者Ｕ２が、スマートフォンなどの携帯端末２００４を携帯していてもよく、その携帯端末２００４で自動通報１００２を受けてもよい。対応者Ｕ２による対応は、ユーザＵ１への呼びかけ、状態確認、救難などの手配、などが挙げられ、詳細については限定しない。

　ユーザＵ１の携帯端末１は、自動通報１００２がされた後の時間において、ユーザＵ１の異常等の状態１００１が解消・改善したかどうか、あるいは、先に為された自動通報１００２が誤通報であったかどうか等を判定する（図２でのステップＳ４）。携帯端末１は、解消した、あるいは誤通報であった、と判定した場合、先の自動通報１００２（それに対応付けられた状態１００１）に関する解除のための解除通知１００３を、先の自動通報１００２と同じ通報先のシステム２へ送信する（図２でのステップＳ５）。

　通報先のシステム２は、解除通知１００３を受信し、対応者Ｕ２は、その解除通知１００３を受けて、先の自動通報１００２に関する解除などの対応を行う（図２のステップＳ６）。

　自動通報１００２は、例えばモバイル網を用いた電話（言い換えると音声データ通信）による通報であるが、詳細を限定しない。この自動通報１００２には、例えば文字や音声や画像などのデータが伴ってもよい。

　また、図１の例では、通信網９に事業者のシステム３が接続されており、事業者のサーバ３００１やＰＣ３００２を有する。事業者のシステム３が、ユーザＵ１の携帯端末１と通信して一部の機能を提供してもよいし、通報先のシステム２と通信して一部の機能を提供してもよいし、ユーザＵ１の携帯端末１と通報先のシステム２との間に介在してもよい。例えば、クラウドコンピューティングシステムまたはクライアント・サーバシステムとして、事業者のサーバ３００１が、自動通報１００２に係わる状態の検知や判定などの処理を行ってもよいし、解除通知１００３に係わる状態の検知や判定などの処理を行ってもよい。

　図１では、後述する構成要素もあわせて図示している。ユーザＵ１の携帯端末１に対し、通信網９を介して、家族や知人等の他者のユーザＵ３の携帯端末４００１を有する。あるいは、ユーザＵ１の携帯端末１に対し、周囲（比較的近い距離範囲内）に、家族や知人等の他者のユーザＵ３の携帯端末４００１を有してもよいし、不特定の他者のユーザＵ３の携帯端末４００１を有してもよい。また、ユーザＵ１の携帯端末１に対し、周囲（比較的近い距離範囲内）に、不特定の任意のデバイス４００２があってもよい。周囲のデバイス４００２は、例えば監視カメラや施設のサーバ、無線基地局などが挙げられる。

　［通報解除方法］
　図２は、実施の形態１の通報解除方法の概要を示すシーケンス図である。ステップＳ１で、ユーザＵ１の携帯端末１の自動通報機能Ｆ１は、各種センサ等を用いたセンシングに基づいて、ユーザＵ１の転倒等の緊急／異常／問題の状態１００１を判定・検知する。ステップＳ２で、携帯端末１の自動通報機能Ｆ１は、ユーザＵ１の状態１００１を伝えて救難などを求めるための自動通報１００２を、所定の通報先のシステム２へ発信する。

　ステップＳ３で、通報先のシステム２は、自動通報１００２を受信し、対応を行う。例えば、対応者Ｕ２は、自動通報１００２を確認し、発信元であるユーザＵ１の携帯端末１へ折り返しの連絡を行い、ユーザＵ１の状態の確認などを行う。なお、ステップＳ３の対応は、図２では即時に行われた場合を図示しているが、必ずしも即時に行われるとは限らない。

　ステップＳ４で、携帯端末１は、解除通知機能Ｆ２によって、自動通報１００２後の時間において、ユーザＵ１の緊急／異常／問題の状態１００１が解消／改善したかどうか、あるいは誤通報であったかどうか等を、追加センシングを含む追加監視に基づいて、判定・検知する。

　ステップＳ５で、携帯端末１の解除通知機能Ｆ２は、ステップＳ４で解消または誤通報と判定した場合に、先の自動通報１００２の通報先と同じ通報先に、解除通知１００３（言い換えるとＳＯＳキャンセル通知）を送信する。ステップＳ６で、通報先のシステム２は、解除通知１００３を受信し、対応者Ｕ２は、その解除通知１００３から、先の自動通報１００２に関する解除（ＳＯＳキャンセル）の対応を行う。

　［自動通報機能］
　まず、自動通報１００２を行うための基本前提的な機能として、図１の自動通報機能Ｆ１の構成例を説明する。この自動通報機能Ｆ１は、例えば特許文献１に記載の技術を同様に適用できるが、これに限定されない。実施の形態１では、自動通報機能Ｆ１としては、特許文献１に記載の技術を同様に適用した場合を説明する。

　この自動通報機能Ｆ１では、携帯端末１は、各種のセンサ等を用いて、携帯端末１またはユーザＵ１の動き、衝撃などをセンシングする。携帯端末１は、検出した衝撃の前の時間でのユーザＵ１の動作特性と、検出した衝撃の後の時間でのユーザＵ１の動作特性とを比較して、ユーザＵ１が転倒等したかどうかを判定する。例えば、衝撃前の動作特性では、ユーザＵ１が周期的な動きで普通に歩いていたが、衝撃後の動作特性では、体の向きが変化し変則的な動きになっている。携帯端末１は、そのような動作特性の変化から、ユーザＵ１の転倒等の事象や状態を推定できる。携帯端末１は、ユーザＵ１が転倒等したと判定した場合、すなわちユーザＵ１が緊急／異常／問題の状態１００１であると判定した場合、自動通報１００２を生成する。自動通報１００２は、ユーザＵ１が転倒等によって緊急または異常または問題などの状態１００１であることを表す通報である。

　なお、特許文献１の技術の場合、図１２の状態遷移図に示されるように、ＳＯＳ通報をする前に、一定時間待機し（１２０６ｂ）、判断を行う。特許文献１の技術は、その待機の間に、通報の必要が有ると判断した場合には、ＳＯＳ通報を出し（１２０２）、ノミナル状態（１２０２）に戻る。また、特許文献１の技術は、その待機の間に、通報の必要が無いと判断した場合には、ＳＯＳ通報をキャンセルし（１２１０）、ＳＯＳを出さずにノミナル状態（１２０２）に戻る。特許文献１の技術の場合、ＳＯＳ通報（１２０２）を出した後の何らかの処理については開示されていない。

　［解除通知機能］
　次に、実施の形態１での特徴的な機能である、解除通知１００３を行うための機能である、解除通知機能Ｆ２について説明する。

　実施の形態１では、上記自動通報機能Ｆ１によって、自動通報１００２（図１）が一旦出力された後の時間において、携帯端末１の解除通知機能Ｆ２は、携帯端末１およびユーザＵ１の動き等の状態の監視を継続する。携帯端末１の解除通知機能Ｆ２は、ユーザＵ１の緊急／異常／問題の状態１００１が解消したかどうか、あるいは、先の自動通報１００２が、ユーザＵ１に問題無い状態での誤通報であったかどうか、等を判断する。携帯端末１の解除通知機能Ｆ２は、例えば、ユーザＵ１が転倒後に立ち上がり再度歩行し始める等の動きを検出した場合、異常等の状態１００１が解消した、あるいは、そもそも異常等の状態１００１ではなく誤通報に該当した、と判定する。そして、携帯端末１の解除通知機能Ｆ２は、先の自動通報１００２の通報先と同じ通報先に、先の自動通報１００２に関するユーザＵ１の異常等の状態１００２が解消した旨あるいは誤通報であった旨を伝えるための解除通知１００３を生成し、当該解除通知１００３を自動的に発信する。

　実施の形態１では、自動通報１００２の後の時間における解除通機能Ｆ２による通報解除判断処理としては、自動通報機能Ｆ１による自動通報判断処理（特に衝撃の前後の時間での動作特性の比較判定）と同様の処理に加え、使用するセンサ等のパラメータを増やし、追加センシングを含む追加監視処理を行う。実施の形態１では、増やすセンサ等のパラメータとして、音声入力・音声認識によるユーザＵ１の状態の判断を有する。携帯端末１は、マイクを含む音声入力・音声認識機能をオン状態にする。このオン状態で、携帯端末１は、ユーザＵ１が自分の状態あるいは通報解除を伝えるための音声を入力・認識してもよいし、携帯端末１の周囲の音声を拾って、状態を判断してもよい。

　携帯端末１は、追加センシングに基づいて、ユーザＵ１の異常等の状態１００１が解消した、または誤通報であったと判定した場合、解除通知１００３を先の通報先に発信する。

　上記のように、実施の形態１では、自動通報機能Ｆ１によるセンシングを含むユーザＵ１の状態の判断の処理と、自動通報１００２後の解除通知機能Ｆ２による追加センシングを含むユーザＵ１の状態の判断の処理とは、一部異なり、後者は追加センシングを含む。

　［関連情報］
　また、携帯端末１の解除通知機能Ｆ２は、解除通知１００３に、当該解除通知１００３と先の自動通報１００２とを関連付け、先の自動通報１００２を通報先が同定しやすくするための情報である関連情報１００４を含める、または添付等するようにする。この関連情報１００４は、例えば、先の自動通報１００２が、自動通報機能Ｆ１による衝撃の検知に基づいて発生した自動通報であったこと、先の自動通報１００２とこの解除通知１００３とが関連していること、等を表す情報である。

　この関連情報１００４には、例えば、デバイスすなわち携帯端末１のＩＤや通信アドレスなどの固有情報、電話番号、位置情報、ユーザＵ１の氏名などの利用者情報、先の自動通報１００２の発信の日時情報（例えば日時分秒）、発信内容情報などのうち、少なくとも１つの情報を有する。

　通報先のシステム２は、上記解除通知１００３を受信した場合、その解除通知１００３に含まれる関連情報１００４から、この解除通知１００３と関連した先の自動通報１００２を同定できる。そして、通報先のシステム２は、先の自動通報１００２が、不要となったまたは誤通報であったため、解除できることを、認識できる。対応者Ｕ２は、先の自動通報１００２への救難などの対応が不要である、または、ユーザＵ１の状態が軽微であるため簡易な対応のみでよい、等と判断できる。

　［解除通知機能Ｆ２の詳細な機能］
　また、解除通知機能Ｆ２の詳細な機能としては、以下が挙げられる。

　（１）携帯端末１は、携帯端末１が通報先に自動通報１００２を行った旨（言い換えると自動通報済み）を、携帯端末１から出力して、ユーザＵ１に伝える機能を有する。この出力は、少なくとも表示や音声で行われる。

　（２）携帯端末１は、自動通報１００２の後に、解除通知１００３のための追加監視を開始する。この追加監視では、前述のセンサを増やした追加センシングの他に、近距離通信をオン状態にして、携帯端末１の周囲のデバイスと近距離通信し、周囲のデバイスに、ユーザＵ１の状態を通知する。

　（３）携帯端末１は、自動通報１００２の後の追加監視の時間に、通報先や他の番号から、当該ユーザＵ１の携帯端末１に連絡の着呼を受けた場合に、その発信元の番号が、所定の通報先の番号であるか、所定の通報先と関連する発信元の番号であるか、無関係の第三者の番号であるか等を、自動的にサーチ等によって判断する。そして、携帯端末１は、判断した番号に応じて、自動的に、対処処理を分岐する。例えば、携帯端末１は、どのような連絡先（発信元）であるかを、携帯端末１から出力して明らかにする。

　（４）携帯端末１は、自動通報１００２の後の追加監視の時間に、ユーザＵ１の異常等の状態１００１が継続しているか、通常状態に復帰したかどうか等の判断を継続し、異常等の状態１００１が継続していると判定した場合には、再度、所定の通報先へ自動通報１００２を発信する等の処理を行う。また、携帯端末１は、そのような場合には、携帯端末１からアラートを出力してもよい。

　また、携帯端末１は、そのような場合には、所定の連絡先とは異なる、予め設定された連絡先、例えば家族や知人等のユーザＵ３の携帯端末４００１（図１）に対応した連絡先へ、ユーザＵ１が異常等の状態１００１である旨の連絡１０１１を行ってもよい。当該連絡１０１１を携帯端末４００１で受けたユーザＵ３は、ユーザＵ１が、自動通報１００２後にも異常等の状態１００１である旨を認識できる。

　また、携帯端末１は、そのような場合には、近距離通信に基づいて、周囲の第三者の携帯端末４００１や任意のデバイス４００２へ、ユーザＵ１が異常等の状態１００１である旨の通知１０１２を発信してもよい。これらの周囲のデバイスは、当該通知１０１２の近距離通信を受け入れ可能な任意のデバイスである。当該周囲のデバイスは、当該通知１０１２を受けた場合には、自動通報１００２後で救難を必要としているユーザＵ１が近くにいること等を認識できる。

　（５）携帯端末１は、追加監視の時間に、ユーザＵ１の異常等の状態１００１が継続していると判定した場合には、携帯端末１を、自動通報１００２に関する動作以外の動作を控えて電力を温存するバッテリーセーブモードに移行させる。携帯端末１は、そのバッテリーセーブモードでは、定期的に、再度、通報先へ自動通報１００２を行ってもよい。また、携帯端末１は、そのバッテリーセーブモードで、自動通報１００２または他の種類の通信を定期的に繰り返す場合の時間間隔を、バッテリーの残量に応じて変えるように制御する。これにより、携帯端末１は、できるだけ長い時間、自動通報１００２に関する待機、外部へ救難のための発信などを行うことができる。

　［スマートフォン１Ａ］
　図３は、携帯端末１としてスマートフォン１Ａの場合のハードウェア構成例を示す。スマートフォン１Ａは、プロセッサ３０１、メモリ３０２、不揮発性メモリ３０３、カメラ・撮像部３０４、位置検知部３０５、姿勢検知部３０６、生体情報検知部３０７、第１無線通信部３１１、第２無線通信部３１２、第３無線通信部３１３、有線通信部３１４、ボタン・操作部３１５、ディスプレイ・表示部３１６、マイク・音声入力部３１７、スピーカ・音声出力部３１８、コネクタ・入出力インタフェース３１９、バッテリー・電源部３２０、振動部３２１、発光部３２２、等を備える。これらの構成要素は図示しないバス等のアーキテクチャで相互に接続されている。なお、これらの要素のすべてが必須というわけではなく、一部省略した構成でもよい。

　例えば不揮発性メモリ３０３には、必要なデータや情報として、ＯＳ、プログラム、デバイス情報、アプリ情報、利用者情報、通報先情報、状態情報、設定情報などが記憶されている。プログラムは、自動通報機能Ｆ１や解除通知機能Ｆ２を構成するためのコンピュータプログラムである。デバイス情報は、このスマートフォン１ＡのＩＤや通信アドレス情報等の固有情報がある。アプリ情報は、各種のアプリケーションプログラムの情報である。利用者情報は、このスマートフォン１Ａを所持し利用するユーザＵ１の氏名などの情報である。通報先情報は、自動通報１００２の際の所定の通報先の電話番号あるいはＵＲＬ等の情報である。状態情報は、ユーザＵ１および携帯端末１の状態を表す情報である。設定情報は、機能に関するシステム設定情報やユーザ設定情報である。

　デバイス情報、アプリ情報、および利用者情報等に含まれる情報の例は、スマートフォン１Ａのデバイス固有番号、通信アドレス、ネットワークＩＤ、電話番号、ユーザＵ１の氏名、ＬＩＮＥ（通話アプリ）等のアプリでのユーザＩＤ、等が挙げられる。状態情報は、例えば、ユーザＵ１の緊急／異常／問題の状態１００１の有無、ＳＯＳ（自動通報１００２）の発信の有無、ＳＯＳに対する通報先からの連絡／応答の有無、解除通知１００３の発信の有無、等が挙げられる。また、メモリ３０３または不揮発性メモリ３０３には、各時点の状態情報を含め、機能および処理に係わる履歴情報が保持されてもよい。

　自動通報機能Ｆ１や解除通知機能Ｆ２は、ＯＳの一部として実装されてもよいし、専用のアプリケーションプログラムとして実装されてもよい。アプリケーションとして実装される場合、そのアプリケーションは、ディスプレイ・表示部３１６にアプリケーション画面を表示してもよい。

　スマートフォン１Ａは、平板状の筐体において、前面側に、タッチパネルによるディスプレイ・表示部３１６や、カメラ・撮像部３０４としてインカメラ等を有する。スマートフォン１Ａは、筐体の背面側に、カメラ・撮像部３０４としてアウトカメラ等を有する。スマートフォン１Ａは、筐体の側面に、ボタン・操作部３１５、マイク・音声入力部３１７、スピーカ・音声出力部３１８、コネクタ・入出力インタフェース３１９等を有する。

　プロセッサ３０１は、ＣＰＵ等で構成され、スマートフォン１Ａのコントローラを構成する。プロセッサ３０１は、メモリ３０２や不揮発性メモリ３０３のデータ・情報を読み書きする。プロセッサ３０１は、メモリ３０２上に読み出したプログラムに従った処理を実行する。これにより、各種の機能や処理部が実現される。

　第１無線通信部３１１は、例えば無線ＬＡＮ通信インタフェース（例えばＷｉ－Ｆｉ）が実装されている。第２無線通信部３１２は、例えばモバイル網通信インタフェース（例えばＬＴＥ、４Ｇ、５Ｇなど）が実装されている。第３無線通信部３１３は、例えば近距離無線通信インタフェース（例えばＢｌｕｅｔｏｏｔｈ、ＮＦＣなど）が実装されている。有線通信部３１４は、有線通信インタフェース（例えばＵＳＢ）が実装されている。

　ボタン・操作部３１５は、例えば電源ボタン、音量ボタンなどがあり、ユーザＵ１による操作入力を受ける部分である。プロセッサ３０１は、ボタン・操作部３１５での操作入力に応じて制御を行う。ディスプレイ・表示部３１６は、例えば液晶／有機ＥＬタッチパネルを備える。マイク・音声入力部３１７は、マイクから音声を入力し、音声データに変換する。スピーカ・音声出力部３１８は、音声データから音声に変換してスピーカから出力する。コネクタ・入出力インタフェース３１９は、例えばＵＳＢに対応したＵＳＢコネクタ等がある。バッテリー・電源部３２０は、バッテリーに充電された電力を、各部へ供給する。振動部３２１は、必要に応じた振動を発生させる。発光部３２２は、必要に応じた発光を発生させる。

　カメラ・撮像部３０４は、インカメラやアウトカメラを用いて撮影を行い、撮影画像データを得る。位置検知部３０５は、例えばＧＰＳ受信器を用いて、スマートフォン１Ａの現在の位置情報（例えば緯度、経度、高度など）を取得する。また、位置検知部３０５は、無線基地局から無線基地局位置情報を取得してもよい。姿勢検知部３０６は、例えば地磁気センサ、ジャイロセンサ、加速度センサなどの各種のセンサを含み、スマートフォン１Ａの現在の姿勢（例えば直交するＸ，Ｙ，Ｚの３軸の向き）や角速度や加速度などの状態を検出する。また、携帯端末１に備えるセンサとして、他にも、照度センサ、近接センサ、測距センサ、視線検出センサなどがあってもよい。照度センサは、スマートフォン１Ａの周囲の照度を検出する。近接センサは、スマートフォン１Ａに対する他の物体の近接を検出する。測距センサは、スマートフォン１Ａから外部の物体までの距離を測定する。視線検出センサは、スマートフォン１Ａを見るユーザＵ１の視線を検出する。生体情報検知部３０７は、ユーザＵ１の生体情報を検出する。

　スマートフォン１Ａは、自動通報１００２の際には、上記ディスプレイ・表示部３１６、スピーカ・音声出力部３１８、振動部３２１、発光部３２２等を利用して、所定の出力を行うようにしてもよい。

　［スマートウォッチ１Ｂ］
　図４は、携帯端末１としてスマートウォッチ１Ｂの場合のハードウェア構成例を示す。スマートウォッチ１Ｂは、プロセッサ４０１、メモリ４０２、不揮発性メモリ４０３、ボタン・操作部４１５、ディスプレイ・表示部４１６、マイク・音声入力部４１７、スピーカ・音声出力部４１８、位置検知部４０５、姿勢検知部４０６、生体情報検知部４０７、通信インタフェース４１１、バッテリー・電源部４２０、振動部４２１、発光部４２２、センサインタフェース４３１、等を備える。これらの構成要素は図示しないバス等のアーキテクチャで相互に接続されている。なお、これらの要素のすべてが必須というわけではなく、一部省略した構成でもよい。

　例えば不揮発性メモリ４０３には、必要なデータや情報として、ＯＳ、プログラム、デバイス情報、アプリ情報、利用者情報、通報先情報、状態情報、設定情報などが記憶されている。プログラムは、自動通報機能Ｆ１や解除通知機能Ｆ２を構成するためのコンピュータプログラムである。デバイス情報は、このスマートウォッチ１ＢのＩＤ等の固有情報である。アプリ情報は、各種のアプリケーションプログラムの情報である。利用者情報は、このスマートウォッチ１Ｂを所持し利用するユーザＵ１の情報である。通報先情報は、自動通報１００２の際の所定の通報先の電話番号、ＵＲＬ等の情報である。状態情報は、ユーザＵ１および携帯端末１の状態を表す情報である。設定情報は、機能に関するシステム設定情報やユーザ設定情報である。

　デバイス情報、アプリ情報、および利用者情報等に含まれる情報の例は、スマートウォッチ１Ｂのデバイス固有番号、通信アドレス、ネットワークＩＤ、電話番号、ユーザＵ１の氏名、ＬＩＮＥ（通話アプリ）等のアプリでのユーザＩＤ、等が挙げられる。状態情報は、例えば、ユーザＵ１の緊急／異常／問題の状態１００１の有無、ＳＯＳ（自動通報１００２）の発信の有無、ＳＯＳに対する通報先からの連絡／応答の有無、解除通知１００３の発信の有無、等が挙げられる。また、メモリ４０３または不揮発性メモリ４０３には、各時点の状態情報を含め、機能および処理に係わる履歴情報が保持されてもよい。

　自動通報機能Ｆ１や解除通知機能Ｆ２は、ＯＳの一部として実装されてもよいし、専用のアプリケーションプログラムとして実装されてもよい。アプリケーションとして実装される場合、そのアプリケーションは、ディスプレイ・表示部４１６にアプリケーション画面を表示してもよい。

　スマートウォッチ１Ｂは、腕時計状の筐体において、前面側に、タッチパネルによるディスプレイ・表示部４１６等を有する。スマートウォッチ１Ｂは、筐体の側面に、ボタン・操作部４１５、マイク・音声入力部４１７、スピーカ・音声出力部４１８等を有する。

　プロセッサ４０１は、ＣＰＵ等で構成され、スマートウォッチ１Ｂのコントローラを構成する。プロセッサ４０１は、メモリ４０２や不揮発性メモリ４０３のデータ・情報を読み書きする。プロセッサ４０１は、メモリ４０２上に読み出したプログラムに従った処理を実行する。これにより、各種の機能や処理部が実現される。

　通信インタフェース４１１は、例えば無線ＬＡＮ、モバイル網、近距離無線通信などのうち１つ以上の通信インタフェースが実装された部分である。通信インタフェース４１１は、スマートフォン１Ａと連携する場合にはその連携のための通信インタフェースが実装されている。

　ボタン・操作部４１５は、例えばホームボタン、リセットボタンなどがあり、ユーザによる操作入力を受ける部分である。例えばホームボタンが押された場合、プロセッサ４０１は、スマートウォッチ１Ｂ本体を初期状態にし、ディスプレイ・表示部４１６には初期画面を表示するように、制御する。

　ディスプレイ・表示部４１６は、例えば液晶／有機ＥＬのタッチパネルを備える。マイク・音声入力部４１７は、マイクから音声を入力し、音声データに変換する。スピーカ・音声出力部４１８は、音声データから音声に変換してスピーカから出力する。バッテリー・電源部４２０は、バッテリーに充電された電力を、各部へ供給する。振動部４２１は、必要に応じた振動を発生させる。発光部４２２は、必要に応じた発光を発生させる。

　位置検知部４０５は、例えばＧＰＳ受信器を用いて、スマートウォッチ１Ｂの現在の位置情報（例えば緯度、経度、高度など）を取得する。また、位置検知部４０５は、無線基地局から無線基地局位置情報を取得してもよい。姿勢検知部４０６は、例えば地磁気センサ、ジャイロセンサ、加速度センサなどの各種のセンサを含み、スマートウォッチ１Ｂの現在の姿勢（例えば直交するＸ，Ｙ，Ｚの３軸の向き）や角速度や加速度などの状態を検出する。また、スマートウォッチ１Ｂに備えるセンサとして、他にも、照度センサ、近接センサ、測距センサ、視線検出センサなどがあってもよい。照度センサは、スマートウォッチ１Ｂの周囲の照度を検出する。近接センサは、スマートウォッチ１Ｂに対する他の物体の近接を検出する。測距センサは、スマートウォッチ１Ｂから外部の物体までの距離を測定する。視線検出センサは、スマートウォッチ１Ｂを見るユーザＵ１の視線を検出する。生体情報検知部４０７は、ユーザＵ１の生体情報を検出する。

　センサインタフェース４３１は、センサを外部接続するインタフェースである。センサインタフェース４３１には、例えば身体情報計測センサ４４１が接続される。身体情報計測センサ４４１は、例えば、脈拍数、心拍数、または血流量などを測定する。当該センサは、例えば、ユーザＵ１の腕に対し、光を照射し、反射光を受光して、受光光量に応じた信号を生成する構成が挙げられる。その他、スマートウォッチ１Ｂにカメラ等を備えてもよい。

　スマートウォッチ１Ｂは、自動通報１００２の際には、上記ディスプレイ・表示部４１６、スピーカ・音声出力部４１８、振動部４２１、発光部４２２等を利用して、所定の出力を行うようにしてもよい。

　［機能ブロック］
　図５は、携帯端末１（ここではスマートフォン１Ａの場合で説明する）のソフトウェアの機能ブロックの構成例を示す。図５の機能ブロックは、プロセッサ３０１による処理によって実現される。自動通報機能Ｆ１や解除通知機能Ｆ２は、主にコンピュータプログラムで実装されてもよい。自動通報機能Ｆ１や解除通知機能Ｆ２は、専用のアプリケーションで実装されてもよい。解除通知機能Ｆ２のみが専用のアプリケーションで実装されてもよい。また、解除通知機能Ｆ２は、自動通報機能Ｆ１と一体で実装されてもよい。

　自動通報機能Ｆ１は、姿勢検知部３０５等のセンサによる出力値であるセンサ情報５０１を入力し、センサ情報５０１に基づいて、ユーザＵ１の異常等の状態を判定する処理５０２を行う。処理５０２は、ユーザＵ１が転倒等によって緊急／異常／問題の状態１００１となったかどうかの判定である。なお、異常等の状態１００１に該当しない場合の状態を、通常状態とも記載する。自動通報機能Ｆ１は、処理５０２の結果、異常等の状態１００１である場合、通報先情報５０４等に基づいて、自動通報１００２を生成・発信する処理５０３を行う。通報先情報５０４は、設定された所定の通報先の電話番号等の情報である。自動通報機能Ｆ１は、状態情報５０５（または履歴情報）には、ユーザＵ１が異常等の状態１００１であること、および自動通報１００２を行ったこと、等を表す情報を記載する。

　解除通知機能Ｆ２は、自動通報機能Ｆ１による自動通報１００２が生じた場合、例えば状態情報５０５が、異常状態、および自動通報有り（自動通報済み）を示している場合、解除通知１００３のための処理を開始する。解除通知機能Ｆ２は、自動通報１００２以後の時間において、センサのセンサ情報５１１を用いて監視を継続する処理５１２を行う。この監視を追加監視とも記載する。この追加監視は前述のように追加センシングを含む。

　解除通知機能Ｆ２は、追加監視の結果、ユーザＵ１の緊急／異常／問題の状態１００１が解消したかどうか、あるいは先の自動通報１００２が誤通報であったか、を判定する処理５１３を行う。

　解除通知機能Ｆ２は、上記判定の結果、解消した場合／誤通報であった場合には、前述の通報先情報５０４、および状態情報５０５等に基づいて、解除通知１００３を生成し、先の自動通報１００２の通報先と同じ通報先に、解除通知１００３を発信する処理５１４を行う。この際、前述のように、この解除通知機能Ｆ２には、先の自動通報１００２とこの解除通知１００３を関連付けて先の自動通報１００２を容易に同定できるようにするための関連情報１００４を含ませる。

　解除通知機能Ｆ２は、解除通知１００３の送信後、ユーザＵ１の異常等の状態１００１が解消したこと（言い換えると通常状態、解消状態）、および解除通知１００３を発信したこと（解除通知済み）、を表す情報を、状態情報５１５（または履歴情報）に記載する。

　［通報の関連付け・同定について］
　自動通報機能Ｆ１による自動通報１００２（１回目の通報として捉えてもよい）と、解除通知機能Ｆ２による解除通知１００３（２回目の通報として捉えてもよい）との関連や同定について説明する。例えばそれらの２つの通報・通知、あるいはそれらを含む不特定多数の複数の通報・通知が、それらを受ける側である通報先のシステム２（図１）において、すみやかに同定できない場合、対応作業が手間となる。そのため、実施の形態１では、自動通報機能Ｆ１による自動通報１００２と、解除通知機能Ｆ２による解除通知１００３とが関連した情報であることを、通報先に伝えるための関連情報１００４を、解除通知１００３に含ませる。通知先のシステム２は、解除通知１００３の関連情報１００４から、それらの２つの通報・通知を容易にすみやかに関連付けて先の自動通報１００２を同定できる。

　自動通報１００２および解除通知１００３には、いずれも、携帯端末１のデバイスのＩＤ、電話番号、位置情報、ユーザＵ１の氏名、ユーザＵ１の状態、などの情報を伴わせる。解除通知１００３には、先の自動通報１００１との関連を表す関連情報１００４を含ませる。

　図１５には、自動通報１００２、解除通知１００３、および関連情報１００４などの構成例を図示している。（Ａ）の例では、解除通知１００３の情報内容のうち、デバイスＩＤ、電話番号、位置情報、利用者氏名などの情報部分は、関連情報１００４に相当する。

　関連情報１００４の他の構成例としては、（Ｂ）に示すように、解除通知１００３において、関連する自動通報１００２の発信の日時などを指定・記述するようにしてもよい。また、解除通知１００３は、関連する自動通報１００２の内容のコピーのデータを持つようにしてもよい。

　関連情報１００４の他の構成例としては、（Ｃ）に示すように、自動通報１００２や解除通知１００３に、それぞれ、ＩＤを付与しておき、関連情報１００４では自動通報１００２のＩＤを指し示すようにしてもよい。

　また、通報先のシステム２は、上記情報、例えば電話番号などに基づいて、同じ電話番号による１つ以上の通報や通知は、関連する通報であるとして、グループやツリー、スレッド等の形式で出力してもよい。これにより、通報先の対応者Ｕ２は、受けた複数の通報の中で、自動通報機能Ｆ１による自動通報１００２と、解除通知機能Ｆ２による解除通知１００３とを、関連する通報として、容易に同定でき、当該通報への対応作業が容易となる。

　［処理フロー］
　次に、実施の形態１における詳細な処理フローを説明する。図６～図９は、携帯端末１の処理フロー例を示している。図６のフローは、部分的なフローであり、（１－１）とする。

　［処理フロー（１－１）］
　図６で、ステップＳ６００で、最初、携帯端末１のユーザＵ１の状態は通常状態である。ステップＳ６０１で、携帯端末１は、自動通報機能Ｆ１により、通常監視として、第１時間でのセンシングを継続し、センサ情報を取得する。この第１時間は、下記衝撃を検知する前の時間を指す。例えば、第１時間では、ユーザＵ１の移動状況や振動状況（例えば静止、水平面の歩行、階段の歩行等）を表すセンサ情報が得られる。

　ステップＳ６０２で、携帯端末１は、特異情報のセンシングを行う。特異情報は、例えばある程度の大きさ以上の衝撃である。衝撃は、例えばユーザＵ１が転倒して地面にぶつかった際の衝撃や、ユーザＵ１が事故に遭って外部の物体がぶつかってきた際の衝撃である。

　ステップＳ６０３で、携帯端末１は、特異情報（例えば衝撃）の検出後の、第２時間でのセンシングを継続し、センサ情報を取得する。この第２時間は、上記衝撃を検知した後の時間を指す。例えば、第２時間では、ユーザＵ１の移動状況や振動状況（例えば地面に倒れたまま動かない等）を表すセンサ情報が得られる。

　ステップＳ６０４で、携帯端末１は、上記第１時間のセンサ情報、特異情報、および第２時間のセンサ情報に基づいて、ユーザＵ１の状態が、転倒や事故等の、緊急／異常／問題の状態１００１であるかどうかを判定する。携帯端末１は、例えば、第１時間での動作特性と、第２時間での動作特性との比較で、変化が大きい場合に、転倒等の状態と推定できる。

　ステップＳ６０４の結果、異常等の状態１００１と判定した場合に、ステップＳ６０５で、携帯端末１は、上記第２時間での状況に基づいて、自動通報１００２の要否を判断する。この判断は、携帯端末１が、ユーザＵ１が異常等の状態１００１であると判定・推定したものの、実際にはユーザＵ１に問題無い状態である場合に、自動通報１００２を行わないようにするためのものである。このステップＳ６０５では、例えば、携帯端末１は、ユーザＵ１に対し、アラートを出力し、カウントダウンを開始する（後述の図１０の（Ａ））。携帯端末１は、このカウントダウンの間、ユーザＵ１による操作入力（すなわち問題無いこと／自動通報が不要であることを表す確認入力）を受け付けて、その操作入力がある場合には、ユーザＵ１が問題無い状態であると判定する。そして、その場合、携帯端末１は、自動通報１００２が不要であると判定する。他方、カウントダウンの間、ユーザＵ１による操作入力が無いまま、タイムアップした場合、携帯端末１は、ユーザＵ１が反応していないことから、自動通報１００２が必要であると判定する。

　なお、上記ステップＳ６０５の処理は、特許文献１の技術でいえば、図１２での待機時間のＳＯＳキャンセルの判断に相当する。

　ステップＳ６０５の結果、ステップＳ６０６で、自動通報１００２が必要とされた場合（Ｙ）、ステップＳ６０７で、携帯端末１は、所定の通報先に、自動通報１００２を発信する。携帯端末１は、自動通報１００２には、当該自動通報１００２を行う自デバイスである携帯端末１を特定できる情報を含めるようにする。この情報は、例えば、携帯端末１のＩＤ、電話番号、位置情報、ユーザＵ１の氏名、などである。また、携帯端末１は、自動通報１００２には、携帯端末１のユーザＵ１の状況、すなわち判定した異常等の状態１００１（例えば転倒して動かない状態）を表す情報を含めるようにする。

　ステップＳ６０８で、携帯端末１は、上記自動通報１００２を発信した事実や結果（自動通報有り、通報先、日時、通報内容など）を、状態情報５０５（図５）あるいは履歴情報に記載し、自デバイス内の不揮発性メモリ３０３等に保持する。また、携帯端末１は、ユーザＵ１に対し、自動通報１００２を発信済みである旨を、携帯端末１から例えば画面表示や音声出力で出力する（後述の図１０の（Ｂ））。

　ステップＳ６０６で不要と判定した場合（Ｓ６０６－Ｎ）、例えばＳ６０１に戻り、同様の繰り返しである。ステップＳ６０８の後、次のフローに続く。

　［処理フロー（１－２）］
　図７は、続く処理フローとして（１－２）を示す。ステップＳ６０８からステップＳ７０１に続く。ステップＳ７０１で、携帯端末１は、上記自動通報１００２の発生に伴い、解除通知機能Ｆ２による処理を開始する。詳しくは、ステップＳ６０７で自動通報１００２を発信した後の時点から、解除通知機能Ｆ２による処理を開始してもよい。

　ステップＳ７０２で、携帯端末１は、センサを用いたユーザＵ１の状態に関する監視を継続する。言い換えると、携帯端末１は、自動通報機能Ｆ１による監視を前述の通常監視とすると、解除通知機能Ｆ２による監視を追加監視（言い換えると通報後監視）として、その追加監視を開始する。この追加監視では、通常監視時のセンシングに対し、使用するセンサ種類等を増やす。例えば、増やすセンサとして、マイクを含む音声入力・音声認識や、ＮＦＣ等の近距離通信機能がある。携帯端末１は、これらの追加センサを強制オンにする。この音声入力・音声認識は、例えば図３のマイク・音声入力部３１７で実現される。この近距離通信機能は、例えば図３の第３無線通信部３１３で実現される。

　ステップＳ７０３で、携帯端末１は、ステップＳ７０２でオンにした追加センシングを含む追加監視によって、自動通報１００２後から少なくとも所定の時間（ここでは第３時間とする）の間、ユーザＵ１の移動状況、振動状況、音声入力・音声認識の状況、近距離通信の状況などをセンシングし、第３時間でのセンサ情報（言い換えると時系列センサデータ）を検出・取得する。

　追加センサとして音声入力・音声認識を用いる場合、例えば、ユーザＵ１が発している音声や携帯端末１の周囲の音声を、携帯端末１は、音声入力・音声認識によって音声データとして取得する。この音声データは、ユーザＵ１の状態を判断するための材料となる。

　また、追加センサとして近距離通信を用いる場合、例えば、携帯端末１は、近距離通信によって周囲に信号を発信し、周囲の任意のデバイスから応答の信号を受信してもよい。

　ステップＳ７０４で、携帯端末１は、上記ステップＳ７０３の第３時間のセンサ情報に基づいて、ユーザＵ１の状態が、異常等の状態１００１から通常状態に復帰したかどうか、あるいは、そもそも誤通報であって通常状態のままであるかどうか、等を判定する。言い換えると、携帯端末１は、先の自動通報１００２に関して、ユーザＵ１の状況が、救難などの対応を必要としない状況になったかどうか、異常等の状態１００１が解消／改善されたかどうか、すなわち、先の自動通報１００２を解除すべきかどうか、等を判定する。

　上記ステップＳ７０４の判定の処理内容としては、ステップＳ６０４やステップＳ６０５の処理内容を同様に適用する他に、追加センサ情報を加味して判断する。例えば、先の自動通報１００２の時点では、ユーザＵ１が転倒により地面に倒れていたとする。その後、ユーザＵ１の心身に問題無く、ユーザＵ１は立ち上がり、歩行し始めたとする。携帯端末１は、このような状況を判断・推定することで、ユーザＵ１が通常状態に復帰したと判定する（後述の図１３）。また、例えば、自動通報１００２後、ユーザＵ１が心身に問題無い旨を音声入力し、携帯端末１は、その音声入力から、ユーザＵ１が通常状態に復帰したと判定してもよい。

　ステップＳ７０５で、携帯端末１は、上記ステップＳ７０４の結果でユーザＵ１が通常状態に復帰した場合（Ｙ）にはステップＳ７０６に分岐し、復帰していない場合（Ｎ）には後述のステップＳ９０１に分岐する。

　ステップＳ７０６で、携帯端末１は、先の自動通報１００２（ステップＳ６０７）に関する解除通知１００３を生成し、先の通報先へ発信する。この解除通知１００３には、前述のように、先の自動通報１００２と関連付け・同定するための関連情報１００４を含める。この解除通知１００３は、先の自動通報１００２に係わるユーザＵ１の緊急／異常／問題の状態１００１が解消した旨、あるいは、軽微なので問題無い旨、誤通報であった旨、救難などの対応が不要となった旨、先の自動通報１００２を解除してもよい旨、等を通報先に伝える情報である。解除通知１００３は、異常事象解決連絡などと言い換えてもよい。

　通報先のシステム２（図１）では、担当者Ｕ２は、解除通知１００３およびそれに含まれる関連情報１００４から、すぐに、解除通知１００３に関連付けられる先の自動通報１００２を同定することができる。そして、担当者Ｕ２は、先の自動通報１００２に関する携帯端末１のユーザＵ１の状況に問題無く、救難などの対応が不要になったことが認識できる。

　通報先のシステム２が、不特定多数の通報を受けている場合、対応の作業が大変であるが、解除通知１００３によって、不特定多数の通報の中から、解除対象の自動通報１００２をすぐに同定でき、対応が必要な通報の数を減少できる。通報先のシステム２は、対応の作業に係わる限られたリソースの消費を低減できる。

　ステップＳ７０７で、携帯端末１は、上記解除通知１００３を発信した事実や結果を、状態情報５１５（図５）あるいは履歴情報に記載し保持する。その状態情報５１５あるいは履歴情報には、例えば解除通知１００３の発信の日時や内容などが記載される。

　ステップＳ７０８で、携帯端末１は、上記追加監視の処理を停止する、言い換えると追加センシングをオフ状態にする。例えば、音声入力・音声認識や近距離通信は、強制オフされる。

　ステップＳ７０９で、携帯端末１は、上記解除通知１００３を通報先へ発信済みであることを、自デバイスから出力（少なくとも画面表示や音声出力）する。例えば、携帯端末１は、画面に解除通知１００３を送信済みである旨を表示し、解除通知１００３を送信済みである旨を音声で出力する（後述の図１１の（Ａ））。

　図７の例では、ステップＳ７０３のタイミングで、音声入力をオンにし、近距離通信をオンにしている。これは、その後の処理のための準備である。これらの追加センシングをオンにするタイミングは、ステップＳ７０３の時点に限らず、より後のタイミングとしてもよい。後述するが、携帯端末１のバッテリー状態に応じて、当該タイミングを変えてもよい。

　［処理フロー（１－３）］
　図８は、図７の処理フロー（１－２）に関する変形例の処理フローとして（１－３）を示す。図８のフローは、追加監視の開始後、ステップＳ７０３の第３時間の間に、第三者からの連絡の着呼を受けた場合の処理例などを規定している。図８では、ステップＳ７０３の後に、ステップＳ８０１等が追加されている。ステップＳ８０１で、携帯端末１は、第三者からの連絡の着呼を受けた場合（Ｙ）に、ステップＳ８０２に進む。当該着呼を受けない場合（Ｎ）には、前述のステップＳ７０４の流れとなる。

　ステップＳ８０２で、携帯端末１は、その第三者からの連絡の着呼が、先の自動通報１００２（ステップＳ６０７）の通報先からの連絡、すなわち自動通報１００２に対する折り返し連絡であるかを確認する。当該確認は、例えば、先の通報先と同じ電話番号からの着呼であるかの確認である。その通報先からの連絡である場合（Ｙ）には、ステップＳ８０３へ進み、異なる場合（Ｙ）には、ステップＳ８１１へ進む。

　ステップＳ８０３で、携帯端末１は、その通報先からの連絡を受けた現在時点までのセンサ情報等に基づいて、ユーザＵ１が通常状態に復帰したかどうか（解消）の判定を行う。この判定の結果、ステップＳ８０３で、通常状態に復帰した判定の場合（Ｙ）には、ステップＳ８０５に進む。ステップＳ８０５で、携帯端末１は、その通報先からの連絡に対し、応答し、ユーザＵ１が通常状態に復帰した旨、問題無い旨、すなわち、先の自動通報１００２に関して解除してもよい旨を伝える。この応答は、機能としては、解除通知１００３に相当する。この応答は、ユーザＵ１が自分で電話の音声で応答するものとしてもよいが、携帯端末１が自動的に応答するものとしてもよい。後者の場合、ユーザＵ１の手間を低減できる。

　他方、ステップＳ８０３で、通常状態に復帰していない判定の場合（Ｎ）には、ステップＳ８０６に進む。ステップＳ８０６で、携帯端末１は、その判定結果、すなわち、ユーザＵ１の異常等の状態が解消した（通常状態に復帰した）とはまだ判断できず、監視継続中である旨を、その通報先からの連絡に対し応答する。この応答は、携帯端末１が自動的に行う。また、携帯端末１は、この応答に、所定の時間（例えば第３時間）の経過後に再度連絡を入れる旨を含める。

　この応答をした後、携帯端末１は、所定の時間（例えば第３時間）の経過後に、ユーザＵ１が通常状態に復帰していない判定の場合には、再度、その通報先に、まだ復帰していない旨の連絡を自動的に発信する。この連絡は、必要に応じた回数で同様に繰り返される。

　上記ステップＳ８０５の後では、ステップＳ８０７で、携帯端末１は、ステップＳ７０８と同様に、解除通知機能Ｆ２による追加監視を停止する。ステップＳ８０７の後は、図７と同様であるため省略する。

　ステップＳ８０２での処理は、例えば以下としてもよい。所定の通報先は、例えば、１１０番、１１９番などである。それに対し、上記第三者からの連絡は、所定の通報先の電場番号とは異なる電話番号からの連絡であることが想定される。例えば、所定の通報先が自動通報１００２を受信した後、その通報先から連携する別のシステムから連絡がユーザＵ１の携帯端末１へ送信される場合がある。携帯端末１は、その場合にも対応できるように、例えば予め対応表を保持しておく。携帯端末１は、対応表に、各種の通報先や発信元に関する電話番号などの情報に関する対応付け情報を保持しておく。携帯端末１は、第三者（任意の発信元）から連絡を受けた場合に、対応表を参照、サーチして、自動通報１００２の通報先との対応関係などを判断する。

　他の処理例としては、携帯端末１は、第三者（任意の発信元）から連絡を受けた場合に、インターネット（通信網９）上の情報、例えばＷｅｂ情報を検索し、着呼を受けた発信元の電話番号（所定の通報先の番号とは異なる番号）が、所定の通報先に関係する電話番号等であるかどうかをサーチして判断してもよい。

　上記ステップＳ８０２で通報先からの連絡ではない場合（Ｎ）、ステップＳ８１１で、携帯端末１は、上記対応表等に基づいて、その第三者からの連絡が、所定の通報先と関連した主体（発信元）、すなわち自動通報１００２に対し救急などの対応を行うことができる主体からの連絡であるかを確認する。ステップＳ８１１で関連した発信元である場合（Ｙ）、ステップＳ８０３に進む。ステップＳ８１１で関連した発信元ではない場合（Ｎ）、ステップＳ８１２に進む。

　ステップＳ８１２では、携帯端末１は、通常処理、すなわち通常の電話機能による処理を行う。携帯端末１は、その第三者からの連絡の着呼に対し、ユーザＵ１への呼び出し処理（無応答）、あるいは設定された自動応答処理などを行う。ユーザＵ１は、その連絡の呼び出しに対し、自分で応答してもよい。

　携帯端末１は、その連絡に対し、ユーザＵ１が自分で応答した場合（ステップＳ８１３－Ｙ）には、ユーザＵ１が通常状態に復帰したと判断し、ステップＳ８１４で、追加監視を停止する。また、ステップＳ８１５で、携帯端末１は、自動通報１００２が発信済みである旨を、ユーザＵ１に対し再度、携帯端末１からアラート出力（少なくとも表示や音声）する。

　［処理フロー（１－４）］
　図９は、処理フローとして（１－４）を示す。図９のフローは、図７のフロー（１－２）のステップＳ７０５で異常状態の継続、通常状態に復帰していない、となった場合（Ｎ）に、続くフローである。ステップＳ９０１では、携帯端末１は、自動通報１００２後の追加監視を継続する。前述の第３時間の後のこのさらなる追加監視の時間を、第４時間とする。ステップＳ９０２では、携帯端末１は、通報先からの折り返し連絡の有無に応じた処理を行う。この処理は図８のフロー（１－３）の処理と同様である。第４時間で、通報先からの折り返し連絡が無い場合、ステップＳ９０３に進む。

　ステップＳ９０３では、携帯端末１は、再度、同様内容の自動通報１００２を２回目の自動通報として、先の通報先へ送信する。また、携帯端末１は、この２回目の自動通報１００２には、再度の繰り返し（２回目以降）の自動通報である旨を伝える情報、１回目の自動通報１００２との関連がわかる情報を含ませる。ステップＳ９０３の再度の自動通報１００２は、経過時間に応じて、同様に繰り返し行われてもよい。

　さらに、ステップＳ９０４では、携帯端末１は、ステップＳ６０７での所定の通報先とは別の通報先にも、自動通報１００２を発信する。ステップＳ６０７での所定の通報先を第１の通報先とし、第１の通報先への自動通報１００２を第１の自動通報１００２とする。ステップＳ９０４での所定の通報先を、第２の通報先とし、第２の通報先への自動通報を、第２の自動通報１００５とする。

　携帯端末１は、予め、上記第１の通報先および第２の通報先を含む、複数の通報先について、設定しておく。携帯端末１は、予め、複数の通報先について、通報の優先順位を設定しておく。第２の通報先に第２の自動通報１００５を送信した場合、携帯端末１は、この第２の自動通報１００５についても、第１の自動通報１００２と同様に、制御対象とし、第２の自動通報１００５についても、必要に応じて解除通知１００３（第２の解除通知）を同様に行うようにする。上記第２の通報先は、救難などの対応を実行可能な主体とする。

　上記第２の通報先は、他にも、図１のユーザＵ１に対する家族や知人等のユーザＵ３のような、予め設定された任意の連絡先としてもよい。この場合、携帯端末１は、例えば、図１での家族や知人等のユーザＵ３の携帯端末４００１へ、第２の自動通報１００５に相当する連絡１０１１を送信する。連絡１０１１は、ユーザＵ１が異常等の状態１００１である旨や、自動通報１００２を送信済みである旨の情報を含む。

　ステップＳ９０５で、携帯端末１は、近距離通信を用いて、周囲のデバイス４００２（図１）に対し、通知１０１２（言い換えると緊急通信）を行う。この通知１０１２は、携帯端末１が自動通報１００２を発信済みであり、ユーザＵ１の異常等の状態が継続している旨を、周囲の任意のデバイス４００２や周囲の第三者の携帯端末４００１などに伝えるための通知である。

　なお、携帯端末１の近距離通信は、前述のステップＳ７０２で、追加監視の開始とともにオン済みであり、ステップＳ９０５の際にはすぐに近距離通信による通知１０１２を発信可能である。これに限らず、ステップＳ９０５になってから近距離通信をオン状態にしてもよい。

　また、ステップＳ９０６で、携帯端末１は、自デバイスからアラートを出力する。このアラート出力は、ユーザＵ１のみならず、携帯端末１の周囲に、ユーザＵ１の異常等の状態を伝えるための出力である。このアラートは、例えば図３のスピーカ・音声出力部３１８等を用いた、緊急音声やアラート音の出力である。また、この際のアラート音（例えばビープ音）は、周囲に聞こえやすいように、音量などが調整される。

　上記ステップＳ９０３～Ｓ９０６等の複数のステップは、同時並行で実行されてもよいし、順序を変えて実行されてもよいし、一部のみが実行されてもよい。

　上記ステップＳ９０６等の少なくとも一部の処理を実行後、携帯端末１は、バッテリーセーブモード（言い換えると省電力モード）に移行する。これは、今後の救難に係わる処理を想定して、携帯端末１の電力を抑制するためである。このバッテリーセーブモードに入ってからの時間を第５時間とする。このバッテリーセーブモードでは、自動通報機能Ｆ１および解除通知機能Ｆ２に係わる動作以外の動作が基本的にオフにされる。例えば画面表示はオフにされる、または表示輝度が低下される。例えば、セルラー通信（モバイル通信）はオンのままにされる。例えば、表示や通信は、アラート出力などの必要な所定のタイミングの時以外にはオフにされる。例えば、各種センサによるセンシングは、動き検知のみがオンにされ、音声入力などはオフにされる。

　携帯端末１は、バッテリーセーブモードでの第５時間において、所定の時間間隔で、定期的に、アラート出力などを行う（後述の図１４）。このアラート出力は、ステップＳ９０６のアラート出力と同様のもの、あるいは、低消費電力での簡易アラート出力とする。また、この定期的な処理は、アラート出力に限らず、ステップＳ９０３と同様の、再度の自動通報１００２の発信としてもよいし、ステップＳ９０５と同様の、周囲のデバイスへ通知としてもよい。

　携帯端末１は、自デバイスのバッテリーの残量を適宜確認し、残量に応じて、上記アラート出力などの定期的な処理を行う第５時間の範囲や時間間隔を調整する。携帯端末１は、残量が多ければ、第５時間を長くし、時間間隔を短くし、残量が少なければ、第５時間を短くし、時間間隔を長くする。また、携帯端末１は、残量に応じて、アラート出力などの時間間隔を、徐々に長くするようにしてもよい。

　また、携帯端末１は、ステップＳ９０５の近距離通信の結果、周囲のデバイスを検出した場合、あるいは周囲のデバイスから応答を受けた場合、言い換えると、他のデバイスの存在を認識した場合、上記アラート出力の時間間隔を一定時間短くするようにしてもよい。すなわち、携帯端末１は、認識した周囲のデバイスとの間で、短く調整された時間間隔で、アラート出力を繰り返すようにしてもよい。

　ステップＳ９０９で、携帯端末１は、バッテリーの電力が無くなるまで、上記処理を継続する。

　以上のフローは、ある１回の自動通報１００２に関して記述したが、２回目以降の自動通報１００２が発生した場合にも、同様の処理を適用可能である。

　［画面表示例］
　図１０は、携帯端末１のディスプレイでの画面表示例を示す。図１０の（Ａ）は、自動通報機能Ｆ１による自動通報１００２の発信の際の表示例を示す。本画面には、通報先（例えば１１９番）に自動通報１００２を発信するためのＳＯＳボタンｇ１と、その自動通報１００２の発信を取りやめるためのキャンセルボタンｇ２とを有する。携帯端末１は、例えばカウントダウンとともに本画面を表示し、カウントダウンの時間中にユーザＵ１によってボタンが押された場合には、押されたボタンに応じた処理を行う。携帯端末１は、カウントダウンの時間の経過後には、自動的に自動通報１００２を発信する。

　図１０の（Ｂ）は、解除通知機能Ｆ２による解除通知１００３の発信の際の表示例を示す。本画面には、自動通報１００２の発信済みを表す表示ｇ３と、解除通知１００３を発生させるための解除ボタンｇ４とを有する。携帯端末１は、ユーザＵ１の状態が改善したと判定した場合に、本画面を表示し、ユーザＵ１が解除ボタンｇ４を押した場合、解除通知１００３を発信するようにしてもよい。

　図１１は、他の画面例を示す。図１１の（Ａ）は、解除通知１００３を送信後の表示例である。本画面には、自動通報１００２を送信済みであることを表す表示ｇ３の他に、解除通知１００３を送信済みであることを表す表示ｇ５を有する。

　図１１の（Ｂ）は、変形例における画面例である。本画面には、解除通知１００３を送信済みであることを表す表示ｇ５の他に、再度の自動通報１００２を行うためのＳＯＳボタンｇ６を有する。例えば、ユーザＵ１の転倒後に自動通報１００２が発生し、その後、ユーザＵ１が通常状態に復帰したという判定に応じて解除通知１００３が発生する。さらに、その後、携帯端末１は、センシングに基づいて、ユーザＵ１が異常等の状態１００１に変化したと判断した場合には、ＳＯＳボタンｇ６を表示するようにしてもよい。

　図１２は、他の画面例を示す。図１２の（Ａ）は、前述の図８のステップＳ８０２の際に、通報先と関連する発信元から着呼を受けた場合の画面例である。本画面では、自動通報１００２の発信済みを表す表示ｇ３と、第三者からの連絡として通報先と関連する発信元からの着呼を表す表示ｇ７とを有する。表示ｇ７は、例えば、発信元の電話番号と、その発信元の電話番号が、通報先と関連する発信元の番号である旨を表す表示とを有する。

　図１２の（Ｂ）は、前述の図８のステップＳ８０２の際に、通報先と関連する発信元から着呼を受けてユーザＵ１が電話で応答した後の画面例である。本画面では、自動通報１００２の発信済みを表す強調表示ｇ８と、通報先と関連する発信元からの電話番号に対し応答した履歴の表示ｇ９とを有する。

　［解除通知機能による状況判断］
　図１３には、補足説明図として、解除通知機能Ｆ２によるユーザＵ１の状態１００１の判断等について例示している。解除通知機能Ｆ２によるユーザＵ１の状況の判断は、自動通報機能Ｆ１によるユーザＵ１の状況の判断と、処理アルゴリズム等が異なっていてもよい。例えば、自動通報機能Ｆ１による異常等の状態１００１の判断は、転倒等の衝撃の前後の動作特性を比較するものである。それに対し、解除通知機能Ｆ２による追加監視時のユーザＵ１の状況の判断は、転倒等による衝撃後の時間（第２時間）での動作特性に対し、さらに、時間軸上で、動作特性の変化を判断するものである。

　図１３で横軸は時間である。例えば時点ｔ１では、携帯端末１を携帯したユーザＵ１が歩行しており、通常状態である。時点ｔ２は、ユーザＵ１が転倒等し、携帯端末１がその転倒等による衝撃をセンシングした時点である。時点ｔ２までの第１の時間Ｔ１では、センシングに基づいて、ユーザＵ１は第１の動作特性を有する。時点ｔ２以後の第２の時間Ｔ２では、センシングに基づいて、ユーザＵ１は第２の動作特性を有する。例えば時点ｔ３は、ユーザＵ１が地面に倒れている状態である。携帯端末１の自動通報機能Ｆ１は、第１の動作特性と第２の動作特性との比較に基づいて、ユーザＵ１が異常等の状態１００１であると判定する。そして、携帯端末１は、自動通報１００２を発信する。

　その後、自動通報１００２に対応した時点ｔ３以後の第３の時間Ｔ３では、解除通知機能Ｆ２による追加監視がされる。例えば、時点ｔ４で、ユーザＵ１は立ち上がり、歩行し始める。第３の時間Ｔ３では、センシングに基づいて、ユーザＵ１は第３の動作特性を有する。携帯端末１の解除通知機能Ｆ２は、第２の時間Ｔ２での第２の動作特性と、第３の時間Ｔ３での第３の動作特性との比較に基づいて、ユーザＵ１が異常等の状態１００１から通常状態に復帰／改善したかどうかを判定する。通常状態に復帰したと判定した場合、携帯端末１は、解除通知１００３を発信する。

　また、時点ｔ４での下側に示しているように、ユーザＵ１が携帯端末１に音声入力で問題無い旨や通報を取り止める旨などを入力してもよく、携帯端末１は、その入力音声を音声認識し、声紋からユーザＵ１個人を認識し、音声認識した結果のワード等から、自動通報１００２を解除すべきかを判定し、解除通知１００３を発信してもよい。

　［バッテリーセーブモードでの制御例］
　図１４には、補足説明図として、図９のステップＳ９０７およびＳ９０８の、携帯端末１のバッテリー残量に応じた調整・制御の例について示している。図１４の横軸は時間である。図１４の（Ａ）は、時点ｔＡで、ユーザＵ１が異常等の状態１００１となり、自動通報１００２が発生した時に、バッテリー残量が例えば７５％の場合である。時点ｔＢで、携帯端末１は、バッテリーセーブモードに移行する（ステップＳ９０７）。携帯端末１は、バッテリー残量に応じて、定期的なアラート出力等に関する時間間隔を調整する。時点ｔＣ１で、携帯端末１は、周囲へのアラート出力、または、周囲のデバイスへの通知、または、再度の自動通報１００２、のうち少なくとも１つを行う。時点ｔＣ１から、時間間隔ＴＣ１が経過後、時点ｔＣ２で、携帯端末１は、同様に、周囲へのアラート出力、または、周囲のデバイスへの通知、または再度の自動通報１００２、のうち少なくとも１つを行う。以後同様に、時間間隔ＴＣ１ごとに、定期的な処理が行われる。

　図１４の（Ｂ）は、時点ｔＡで、ユーザＵ１が異常等の状態１００１となり、自動通報１００２が発生した時に、バッテリー残量が例えば３０％の場合である。時点ｔＢで、携帯端末１は、バッテリーセーブモードに移行する（ステップＳ９０７）。携帯端末１は、バッテリー残量に応じて、定期的なアラート出力等に関する時間間隔を調整する。（Ｂ）では、（Ａ）よりも、バッテリー残量が少ないので、時間間隔ＴＣ２は、時間間隔ＴＣ１よりも長くされる。時点ｔＣ１で、携帯端末１は、周囲へのアラート出力、または、周囲のデバイスへの通知、または、再度の自動通報１００２、のうち少なくとも１つを行う。時点ｔＣ１から、時間間隔ＴＣ２が経過後、時点ｔＣ２で、携帯端末１は、周囲へのアラート出力、または、周囲のデバイスへの通知、または、再度の自動通報１００２、のうち少なくとも１つを行う。以後同様に、時間間隔ＴＣ２ごとに、定期的な処理が行われる。

　また、携帯端末１は、バッテリー残量に応じて、上記第５時間での定期的な処理を行うための時間範囲（開始から終了まで）を決めてもよい。また、携帯端末１は、自動通報１００２の発信後、バッテリー残量に応じて、いつバッテリーセーブモードへ移行させるべきかを判断し決定してもよい。例えば、バッテリー残量が所定の残量以下になった場合に、バッテリーセーブモードへ移行させるものとしてもよい。

　また、携帯端末１は、バッテリー残量に応じて、上記定期的な処理として、周囲へのアラート出力のみを行うか、近距離通信による周囲のデバイスへの通知のみを行うか、再度の自動通報１００２のみを行うか、それらを２つ以上行うか、等を選択してもよい。例えば、バッテリー残量が第１閾値以上である場合、３つまたは２つの処理を行い、第１閾値未満となった場合、１つの処理のみを行い、さらに、第１閾値よりも小さい第２閾値未満となった場合、すべての処理を停止して、通報先からの折り返し連絡のみを待機するようにしてもよい。

　［実施の形態の効果等］
　上記実施の形態１によれば、携帯端末１の自動通報機能Ｆ１に関して、誤通報などの場合にも、好適な対応が可能となる。携帯端末１の自動通報機能Ｆ１が、ユーザＵ１の状態１００１に基づいて、自動通報１００２を発生させた後、解除通知機能Ｆ２が、ユーザＵ１の状況に応じて、自動的に解除通知１００３を発信することができる。

　［変形例］
　実施の形態１では、ユーザＵ１の操作入力が何も無くても、携帯端末１の判断に応じて自動的に解除通知１００３を発信するものとしたが、これに限定されず、ユーザＵ１の操作入力を介するようにしてもよい。携帯端末１は、先の自動通報１００２を解除すべきと判定した場合に、解除通知１００３を通報先へ送信する前に、解除する旨をユーザＵ１に対し出力（例えば画面表示や音声）する。例えば、図１０の（Ｂ）の例のように、画面での解除ボタンｇ４の押下の操作を介するようにしてもよい。ユーザＵ１が、確認・肯定の操作、例えば解除ボタンｇ４を押下した場合に、携帯端末１は、解除通知１００３を通報先へ送信する。ユーザＵが、その肯定の操作をしない場合には、携帯端末１は、解除通知１００３を送信しない。

　携帯端末１の解除通知機能Ｆ２のアプリケーション等に関するユーザ設定では、解除通知機能Ｆ２に関する詳細な機能をユーザ設定可能とする。例えば、上記解除通知１００３を自動的に送信するか、解除ボタンｇ４の押下の操作を介して送信するかを、選択可能とする。

　変形例として、自動通報１００２以外に、派生的な各種の通報や通知（例えば連絡１０１１や通知１０１２）が行われた場合に、それらの派生的な通報等についても、解除通知１００３を同様に適用するようにしてもよい。

　以上、本開示の実施の形態について具体的に説明したが、前述の実施の形態に限定されず、要旨を逸脱しない範囲で種々変更可能である。各実施の形態は、必須構成要素を除き、構成要素の追加・削除・置換などが可能である。特に限定しない場合、各構成要素は、単数でも複数でもよい。各実施の形態や変形例を組み合わせた形態も可能である。

　１…携帯端末、１Ａ…スマートフォン、１Ｂ…スマートウォッチ、２…通報先のシステム、３…事業者のシステム、９…通信網、Ｆ１…自動通報機能、Ｆ２…解除通知機能、１００１…緊急／異常／問題の状態、１００２…自動通報、１００３…解除通知、１００４…関連情報、Ｕ１…ユーザ、Ｕ２…対応者。

Claims

　自動通報機能を有する携帯端末であって、
　前記自動通報機能は、前記携帯端末の状態に応じて、前記携帯端末を携帯するユーザが緊急または異常または問題の状態である第１の状態であると判定した場合に、所定の通報先である第１の通報先に自動通報である第１の通報を自動的に行う機能であり、
　前記携帯端末は、前記自動通報が行われた場合に、前記自動通報の後の時間において、前記携帯端末の状態を監視し、前記第１の状態が解消したかどうか、または、前記第１の通報が誤通報であったかどうかを判定し、解消した、または、前記誤通報であった、と判定した場合には、前記第１の通報に関する解除を伝えるための解除通知を前記第１の通報先に行う、
　携帯端末。
　請求項１記載の携帯端末において、
　前記解除通知には、当該解除通知と前記第１の通報との関連付け、および前記第１の通報を前記第１の通報先が同定できるようにするための関連情報として、前記第１の通報に関する日時情報、前記携帯端末の位置情報、電話番号情報、固有情報、前記ユーザの名前情報、前記第１の通報の内容情報のうち、少なくとも１つの情報を伴わせる、
　携帯端末。
　請求項１記載の携帯端末において、
　前記第１の通報の後の時間での監視では、前記自動通報機能による前記第１の通報の前の時間での監視よりも、センシングするパラメータを増やし、増やすパラメータの１つとして、音声入力および音声認識による前記ユーザの状態の判断を有する、
　携帯端末。
　請求項１記載の携帯端末において、
　前記解除通知を行った場合に、前記ユーザの前記第１の状態が解消した旨、前記誤通報であったと判定した旨、または、前記第１の通報に関する前記解除通知を前記第１の通報先に行った旨、のうち少なくとも１つを、前記携帯端末から少なくとも表示または音声で出力する、
　携帯端末。
　請求項１記載の携帯端末において、
　前記第１の通報の後の監視の時間において、前記第１の通報先の番号とは異なる番号からの連絡の着呼を受けた場合に、当該着呼を受けた番号が、前記第１の通報先の番号に関連する番号であるかどうかをサーチし、サーチした結果を前記携帯端末から少なくとも表示または音声で出力する、
　携帯端末。
　請求項５記載の携帯端末において、
　前記着呼を受けた番号が、前記第１の通報先の番号に関連する番号である場合で、かつ、当該着呼に対し前記ユーザが応答できた場合に、前記監視を停止し、前記第１の通報が実行済みの旨を前記携帯端末から少なくとも表示または音声で出力する、
　携帯端末。
　請求項１記載の携帯端末において、
　前記第１の通報の後の時間において、前記第１の状態が解消していないと判定した場合に、再度、前記第１の通報先へ前記自動通報を行う、
　携帯端末。
　請求項１記載の携帯端末において、
　前記第１の通報の後の時間において、前記第１の状態が解消していないと判定した場合に、前記第１の通報先とは異なる予め設定された連絡先へ、前記ユーザが前記第１の状態である旨の連絡を自動的に行う、
　携帯端末。
　請求項１記載の携帯端末において、
　前記第１の通報の後の時間において、前記第１の状態が解消していないと判定した場合に、近距離通信に基づいて、前記携帯端末の周囲のデバイスへ、前記ユーザが前記第１の状態である旨の通知を自動的に行う、
　携帯端末。
　請求項１記載の携帯端末において、
　前記第１の通報の後の時間において、前記第１の状態が解消していないと判定した場合に、前記携帯端末から周囲に少なくとも音声でアラートを出力する、
　携帯端末。
　請求項１記載の携帯端末において、
　前記第１の通報の後の時間において、前記第１の状態が解消していないと判定した場合に、前記携帯端末を、前記自動通報に関する動作以外の動作を控えてバッテリーをセーブするバッテリーセーブモードに移行させる、
　携帯端末。
　請求項１１記載の携帯端末において、
　前記バッテリーセーブモードでは、定期的な処理として、
　前記携帯端末から周囲に少なくとも音声でアラートを出力する、または、近距離通信に基づいて、前記携帯端末の周囲のデバイスへ、前記ユーザが前記第１の状態である旨の通知を自動的に行う、または、再度、前記第１の通報先へ前記自動通報を行う、
　携帯端末。
　請求項１２記載の携帯端末において、
　前記バッテリーセーブモードで、前記自動通報または他の種類の通信を定期的に繰り返す場合の時間間隔を、前記バッテリーの残量に応じて変えるように制御する、
　携帯端末。
　自動通報機能を有する携帯端末における通報解除方法であって、
　前記自動通報機能は、前記携帯端末の状態に応じて、前記携帯端末を携帯するユーザが緊急または異常または問題の状態である第１の状態であると判定した場合に、所定の通報先である第１の通報先に自動通報である第１の通報を自動的に行う機能であり、
　前記携帯端末が、前記自動通報を行うステップと、
　前記携帯端末が、前記自動通報が行われた場合に、前記自動通報の後の時間において、前記携帯端末の状態を監視し、前記第１の状態が解消したかどうか、または、前記第１の通報が誤通報であったかどうかを判定し、解消した、または、前記誤通報であった、と判定した場合には、前記第１の通報に関する解除を伝えるための解除通知を前記第１の通報先に行うステップと、
　を有する、通報解除方法。