特開 2024-140181 通知制御装置及び通知制御プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024140181

(43)【公開日】2024-10-10

(54)【発明の名称】通知制御装置及び通知制御プログラム

(51)【国際特許分類】

   G06Q 10/10 20230101AFI20241003BHJP

【ＦＩ】

G06Q10/10

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2023051204

(22)【出願日】2023-03-28

(71)【出願人】

【識別番号】308036402

【氏名又は名称】株式会社ＪＶＣケンウッド

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】今野 良彦

(72)【発明者】

【氏名】宍戸 一郎

(72)【発明者】

【氏名】吉田 朝明

(72)【発明者】

【氏名】高畠 仁志

(72)【発明者】

【氏名】中原 良和

(72)【発明者】

【氏名】笠原 圭輔

【テーマコード（参考）】

5L010

5L049

【Ｆターム（参考）】

5L010AA11

5L049AA11

(57)【要約】

【課題】端末装置の故障が予測された場合に、イベントの関係者に対して適切に通知を行うことが可能な通知制御装置を提供すること。
【解決手段】本開示にかかる通知制御装置は、ユーザ端末１（端末装置）が備えるセンサ部において検出されたセンサ情報を取得するセンサ情報取得部３１と、センサ情報に基づいて、端末装置の故障予測を行う故障予測部３４と、端末装置のユーザが係るイベントの日時と、イベントの関係者の連絡先と、が関連付けられたイベント情報を取得するイベント情報取得部３２と、端末装置の故障が予測された場合、イベント情報を参照し、故障予測がなされた以降に開催予定のイベントを抽出し、抽出したイベントの関係者の連絡先を、故障予測に関する通知情報の送信先として特定する特定部３６と、送信先に対する通知情報の送信を制御する送信制御部３７と、を備える。
【選択図】図２

【特許請求の範囲】

【請求項1】

端末装置が備えるセンサ部において検出されたセンサ情報を取得するセンサ情報取得部と、
前記センサ情報に基づいて、前記端末装置の故障予測を行う故障予測部と、
前記端末装置のユーザが係るイベントの日時と、前記イベントの関係者の連絡先と、が関連付けられたイベント情報を取得するイベント情報取得部と、
前記故障予測部において前記端末装置の故障が予測された場合、前記イベント情報を参照し、前記故障予測がなされた以降に開催予定のイベントを抽出し、抽出したイベントの関係者の連絡先を、前記故障予測に関する通知情報の送信先として特定する特定部と、
前記送信先に対する前記通知情報の送信を制御する送信制御部と、を備える
通知制御装置。

【請求項2】

前記端末装置が故障したか否かを判定する故障判定部をさらに備え、
前記送信制御部は、前記故障予測がなされた時点から所定時間の経過後に、前記通知情報が前記送信先に送信されるように送信予約を行うための予約情報を、前記通知情報を送信するメッセージサーバに送信し、
前記故障判定部は、前記送信制御部が前記予約情報を送信した後、前記所定時間の経過前に、前記端末装置が故障したか否かを判定し、
前記送信制御部は、前記端末装置が故障していないと判定された場合、前記送信予約を取り消すための予約取消情報を前記メッセージサーバに送信する
請求項１に記載の通知制御装置。

【請求項3】

前記イベント情報は、前記イベントの場所がさらに関連付けられており、
前記特定部は、前記故障予測部において前記端末装置の故障が予測された場合、前記イベント情報を参照し、前記故障予測がなされた以降に開催予定のイベントであり、かつ、前記イベントの場所が所定の場所以外のイベントを抽出し、抽出したイベントの関係者の連絡先を前記通知情報の送信先として特定する
請求項１又は２に記載の通知制御装置。

【請求項4】

前記イベント情報が前記端末装置以外の他の端末装置によってアクセスされたか否かを示す情報を取得する端末情報取得部をさらに備え、
前記特定部は、前記故障予測部において前記端末装置の故障が予測された場合、前記イベント情報を参照し、前記故障予測がなされた以降に開催予定のイベントであり、かつ、前記他の端末装置によってアクセスされていないイベントを抽出し、抽出したイベントの関係者の連絡先を前記通知情報の送信先として特定する
請求項１又は２に記載の通知制御装置。

【請求項5】

端末装置が備えるセンサ部において検出されたセンサ情報を取得するセンサ情報取得ステップと、
前記センサ情報に基づいて、前記端末装置の故障予測を行う故障予測ステップと、
前記端末装置のユーザが係るイベントの日時と、前記イベントの関係者の連絡先と、が関連付けられたイベント情報を取得するイベント情報取得ステップと、
前記故障予測ステップにおいて前記端末装置の故障が予測された場合、前記イベント情報を参照し、前記故障予測がなされた以降に開催予定のイベントを抽出し、抽出したイベントの関係者の連絡先を、前記故障予測に関する通知情報の送信先として特定する特定ステップと、
前記送信先に対する前記通知情報の送信を制御する送信制御ステップと、をコンピュータに実行させる
通知制御プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、通知制御装置及び通知制御プログラムに関する。

【背景技術】

【0002】

電子機器に内蔵されたセンサを用いて動作状態を監視し、当該電子機器の故障が予測された場合にユーザに対して通知を行う技術が知られている。

【0003】

関連する技術として、特許文献１は、電子機器に障害を発生させ得る衝撃などの動作環境の変化を検知して、ユーザに注意喚起する障害発生予防装置を開示する。特許文献１が開示する障害発生予防装置は、電子機器に障害が発生する可能性があるか否かを判定する判定手段と、判定結果に応じて動作環境の改善をユーザに喚起する喚起手段と、を備えている。特許文献１では、喚起手段の例として、予め設定されたアドレス宛に電子メールを送信させる電子メール送信手段が開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００３－３４５６２７号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、スマートフォンなどの端末装置を用いて、ユーザがイベントに参加する場合がある。例えば、ユーザが端末装置を用いてオンライン会議に参加する場合、端末装置が故障することで、ユーザはオンライン会議に参加できなくなる可能性がある。また、例えば、ユーザが所定の会場で開催されるイベントに参加する場合、端末装置が故障することで、イベントに同行する友人などと連絡がとれなくなる可能性がある。

【0006】

このような状況で、特許文献１が開示するような技術を用いて端末装置の故障を予測し、あらかじめ設定された固定的なメールアドレス宛に通知することは適切ではない場合がある。例えば、端末装置の故障によって影響を受ける可能性のある関係者が固定的でない場合、端末装置の故障を予測したときの状況に応じて、適切な通知先が設定されることが好ましい。しかしながら、特許文献１が開示する技術では、このような問題については十分考慮されていない。

【0007】

本開示の目的は、上述した課題を鑑み、端末装置の故障が予測された場合に、イベントの関係者に対して適切に通知を行うことが可能な通知制御装置及び通知制御プログラムを提供することにある。

【課題を解決するための手段】

【0008】

本開示にかかる通知制御装置は、
端末装置が備えるセンサ部において検出されたセンサ情報を取得するセンサ情報取得部と、
前記センサ情報に基づいて、前記端末装置の故障予測を行う故障予測部と、
前記端末装置のユーザが係るイベントの日時と、前記イベントの関係者の連絡先と、が関連付けられたイベント情報を取得するイベント情報取得部と、
前記故障予測部において前記端末装置の故障が予測された場合、前記イベント情報を参照し、前記故障予測がなされた以降に開催予定のイベントを抽出し、抽出したイベントの関係者の連絡先を、前記故障予測に関する通知情報の送信先として特定する特定部と、
前記送信先に対する前記通知情報の送信を制御する送信制御部と、を備えるものである。

【0009】

本開示にかかる通知制御プログラムは、
端末装置が備えるセンサ部において検出されたセンサ情報を取得するセンサ情報取得ステップと、
前記センサ情報に基づいて、前記端末装置の故障予測を行う故障予測ステップと、
前記端末装置のユーザが係るイベントの日時と、前記イベントの関係者の連絡先と、が関連付けられたイベント情報を取得するイベント情報取得ステップと、
前記故障予測ステップにおいて前記端末装置の故障が予測された場合、前記イベント情報を参照し、前記故障予測がなされた以降に開催予定のイベントを抽出し、抽出したイベントの関係者の連絡先を、前記故障予測に関する通知情報の送信先として特定する特定ステップと、
前記送信先に対する前記通知情報の送信を制御する送信制御ステップと、をコンピュータに実行させるものである。

【発明の効果】

【0010】

本開示にかかる通知制御装置及び通知制御プログラムは、端末装置の故障が予測された場合に、イベントの関係者に対して適切に通知を行うことを可能とする。

【図面の簡単な説明】

【0011】

【図1】実施形態１にかかる故障通知システムの構成を示すブロック図である。

【図2】実施形態１にかかるユーザ端末の構成を示すブロック図である。

【図3】実施形態１にかかるイベント情報の一例を示す図である。

【図4】実施形態１にかかる通知情報の一例である故障予測通知を示す図である。

【図5】実施形態１にかかる加速度センサの検出結果を用いて故障予測を行う場合にユーザ端末が行う処理を示すフローチャートである。

【図6】実施形態１にかかる加速度センサ以外のセンサの検出結果を用いて故障予測を行う場合にユーザ端末が行う処理を示すフローチャートである。

【図7】実施形態２にかかる故障通知システムの構成を示すブロック図である。

【図8】実施形態２にかかるユーザ端末の構成を示すブロック図である。

【図9】実施形態２にかかる加速度センサの検出結果を用いて故障予測を行う場合にユーザ端末が行う処理を示すフローチャートである。

【図10】実施形態２にかかる加速度センサ以外のセンサの検出結果を用いて故障予測を行う場合にユーザ端末が行う処理を示すフローチャートである。

【図11】実施形態３にかかる故障通知システムの構成を示すブロック図である。

【図12】実施形態３にかかるユーザ端末の構成を示すブロック図である。

【図13】実施形態３にかかる通知制御サーバの構成を示すブロック図である。

【図14】実施形態３にかかる加速度センサの検出結果を用いて故障予測を行う場合に、ユーザ端末が行う処理を示すフローチャートである。

【図15】実施形態３にかかる加速度センサ以外のセンサの検出結果を用いて故障予測を行う場合に、ユーザ端末が行う処理を示すフローチャートである。

【図16】実施形態３にかかる通知制御サーバが行う処理を示すフローチャートである。

【図17】実施形態３にかかる電子メールの予約機能を用いた場合における通知制御サーバが行う処理を示すフローチャートである。

【発明を実施するための形態】

【0012】

以下では、本開示の実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されている。説明の明確化のため、必要に応じて重複説明は省略される。

【0013】

＜実施形態１＞
まず、図１を参照して、実施形態１にかかる故障通知システム１００について説明する。図１は、故障通知システム１００の構成を示すブロック図である。

【0014】

（故障通知システム１００の構成）
故障通知システム１００は、ユーザ端末１、関係者端末３、及びメールサーバ５を備えている。ユーザ端末１、関係者端末３、及びメールサーバ５は、ネットワークＮを介して接続されている。ネットワークＮは、有線又は無線の通信回線である。ネットワークＮは、例えば、３Ｇ、４Ｇ、５Ｇなどの移動体通信網、インターネット、公衆電話回線網、又は衛星通信網などを用いて構成されてよい。

【0015】

ユーザ端末１は、故障通知システム１００を利用するユーザが使用する端末装置である。ユーザは、故障通知システム１００において管理されるイベントへの参加を予定している人物である。ユーザ端末１は、例えば、スマートフォン、携帯電話端末、タブレット端末、又はＰＣ（Personal Computer）などである。なお、図１において、ユーザ端末１は１つであるが、ユーザ端末１は複数あってもよく、ユーザ端末１の数は任意である。

【0016】

関係者端末３は、イベントの関係者が使用する端末装置である。関係者は、ユーザが参加予定のイベントに関係する人物である。関係者は、例えば、イベントに関してユーザと連絡を取ることが想定される人物や、ユーザ端末１の故障が与えるイベントへの影響に対し、なんらかの対処を行うことが想定される人物である。関係者は、例えば、ユーザと共にイベントに参加する参加者や、イベントの主催者などである。関係者は、参加者や主催者がユーザと連絡が取れない場合に、ユーザの代わりに連絡を受ける人物（代理人）であってもよい。関係者端末３は、ユーザ端末１と同様、スマートフォン、携帯電話端末、タブレット端末、又はＰＣなどである。また、図１において、関係者端末３は１つであるが、関係者端末３は複数あってもよく、関係者端末３の数は任意である。

【0017】

メールサーバ５は、メッセージ情報の送受信を行うためのメッセージサーバとして機能する。メールサーバ５は、例えば、ユーザ端末１から通知情報を受信して、当該通知情報を関係者端末３に送信する。ここで、通知情報は、ユーザ端末１において予測された、ユーザ端末１の故障に関する情報である。通知情報について、詳細は後述する。

【0018】

メールサーバ５は、電子メールサービスを提供することで、ユーザ端末１と関係者端末３との間で、通知情報の送受信を行う。メールサーバ５は、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）を用いて、ユーザ端末１から受信した通知情報を関係者端末３に送信する。

【0019】

なお、本開示では、メッセージサーバの一例として、メールサーバ５を用いて説明するが、これに限られない。メールサーバ５に代えて、他のサービスを提供する種々のサーバがメッセージサーバとして用いられてもよい。例えば、メッセージサーバとして、ＳＭＳ（Short Message Service）を提供するＳＭＳサーバ、チャットサービスを提供するチャットサーバ、又はＳＮＳ（Social Networking Service）を提供するＳＮＳサーバなどが用いられ得る。

【0020】

（ユーザ端末１の構成）
続いて、図２を参照して、ユーザ端末１の構成について説明する。図２は、ユーザ端末１の機能的な構成を示すブロック図である。ユーザ端末１は、センサ部１０、記憶部２０、制御部３０、通信部４０、及び位置検出部５０を備えている。

【0021】

ユーザ端末１は、図示しない構成としてプロセッサ及びメモリ（半導体メモリ等）を備えている。半導体メモリ等の記憶装置で構成された記憶部２０には、本実施形態にかかる処理が実装されたコンピュータプログラムが記憶されている。プロセッサは、記憶装置からコンピュータプログラムをメモリへ読み込ませ、当該コンピュータプログラムを実行することで、ユーザ端末１の各種機能を実現できる。例えば、プロセッサとメモリの組み合わせにより、制御部３０が備える各種機能、すなわち、センサ情報取得部３１、イベント情報取得部３２、端末位置情報取得部３３、故障予測部３４、特定部３６、及び送信制御部３７としての機能を実現する。

【0022】

または、制御部３０が備える各種機能は、それぞれが専用のハードウエアで実現されていてもよい。また、各装置の各構成要素の一部又は全部は、汎用又は専用の回路（circuitry）、プロセッサ等やこれらの組合せによって実現されてもよい。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組合せによって実現されてもよい。また、プロセッサとして、CPU（Central Processing Unit）、GPU（Graphics Processing Unit）、FPGA（field-programmable gate array）、量子プロセッサ（量子コンピュータ制御チップ）等を用いることができる。

【0023】

また、ユーザ端末１の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

【0024】

センサ部１０は、ユーザ端末１の外部環境の変化を検出するセンサを１つ以上含む。ここでは、センサ部１０は、加速度センサ１１、磁気センサ１２、温度・湿度センサ１３、及び圧力センサ１４を備えているが、センサ部１０の構成は、これらに限定されるものではない。センサ部１０は、複数種類のセンサを備えている必要はなく、少なくとも１つのセンサを備えていればよい。例えば、センサ部１０は、加速度センサ１１のみを備えていてもよい。加速度センサ１１、磁気センサ１２、温度・湿度センサ１３、及び圧力センサ１４のそれぞれは、検出結果を制御部３０に出力する。

【0025】

加速度センサ１１は、ユーザ端末１の加速度を検出する。加速度センサ１１は、例えば、ユーザ端末１本体のＸ軸方向、Ｙ軸方向、及びＺ軸方向のそれぞれにおける加速度を検出する。加速度センサ１１は、検出した加速度を、センサ情報として制御部３０に出力する。加速度センサ１１は、ユーザ端末１の落下を検出した場合、ユーザ端末１が落下状態であることを示すセンサ情報を制御部３０に出力する。例えば、加速度センサ１１は、加速度の値が所定値以上となった場合、あるいは加速度が急激に変化した場合に、落下状態の開始を検出し、センサ情報として出力する。例えば、加速度センサ１１は、加速度の単位時間当たりの変化量が所定値以上となった場合に、落下状態の開始を検出し、センサ情報として出力する。

【0026】

また例えば、加速度センサ１１は、ユーザ端末１が自由落下状態であることを検出する。自由落下状態とは、ユーザ端末１が重力の働きのみによって落下している状態である。この状態において、加速度センサ１１の出力は基本的に「０」となる。このため、加速度センサ１１は基本的には、出力が「０」になるタイミングを検出することにより、自由落下状態の開始を検出することができる。もちろん、加速度センサ１１の誤差や製品の特性を考慮して、加速度センサ１１の出力が所定の範囲になった場合に、自由落下状態を検出してもよい。

【0027】

また例えば、加速度センサ１１は、加速度の変化に基づいて、落下状態が終了したことを示すセンサ情報を制御部３０に出力する。例えば、ユーザ端末１が落下して、床や地面に衝突した場合、大きな衝撃（すなわち大きな加速度）が発生するため、これを検出することにより、落下状態の終了を検出することができる。これにより、制御部３０では、落下状態の開始タイミングと終了タイミングとを取得することができる。なお、加速度センサ１１は、落下状態の開始からの経過時間、つまり落下状態の継続時間を計測して、センサ情報として制御部３０に出力してもよい。

【0028】

磁気センサ１２は、ユーザ端末１の周囲の磁界の強度を検出する。温度・湿度センサ１３は、ユーザ端末１の周囲の温度及び湿度を検出する。圧力センサ１４は、ユーザ端末１に加えられた圧力を検出する。

【0029】

上述したセンサ部１０は一例であるので、センサ部１０は、他のセンサを備えてもよい。例えば、センサ部１０は、ユーザ端末１が水没したことを検出する水没センサ（水分検出センサ）を含んでもよい。

【0030】

記憶部２０は、半導体メモリ等で構成されており、各種のデータ及びプログラムを記憶する。記憶部２０の少なくとも一部は、ユーザ端末１の電源を切ってもデータが保持されるように、不揮発性のメモリで構成されている。特に、記憶部２０はイベント情報２１を記憶する。イベント情報２１は、ユーザ端末１のユーザが参加するイベントに関する情報である。イベント情報２１は、イベントごとに、日時と関係者の連絡先とが対応付けられている。イベント情報２１は、イベントの場所がさらに関連付けられてもよい。

【0031】

なお、ここではイベント情報２１を記憶部２０に記憶する構成を用いて説明するが、イベント情報２１は、ユーザ端末１以外の装置に記憶されてもよい。例えば、クラウドコンピューティングシステムを利用する場合、クラウド上に記憶されたイベント情報２１を、ユーザ端末１が取得する構成としてもよい。

【0032】

ここで、図３を参照して、イベント情報２１について説明する。図３は、イベント情報２１の一例を示す図である。本図に示すように、イベント情報２１は、ＩＤ２１０、イベント日時２１１、イベント種別２１２、イベント名２１３、イベント場所２１４、第１関係者２１５、第１連絡先２１６、第２関係者２１７、第２連絡先２１８、予備端末の有無２１９、及び予備連絡先２２０の項目（フィールド）を含む。イベント情報２１は、ユーザがユーザ端末１を操作して作成してもよいし、後述するように一部の項目については、制御部３０が自動的に設定してもよい。なお、図３は記憶部２０に記憶されるイベント情報２１の一例であり、ユーザ端末１は１人のユーザによって使用される（複数のユーザが使用しない）ことを想定しているため、イベント情報２１は、イベントに参加するユーザ（イベントに係るユーザ）を識別するためのユーザＩＤを含んでいない。ただし、これに限定されるものではなく、クラウド上などに記憶されたイベント情報２１は、もちろんユーザを識別するためのユーザＩＤ、あるいはユーザが使用する端末を識別するための端末ＩＤを含んでいてよい。

【0033】

ＩＤ２１０は、イベントを識別するための情報（識別情報）であり、イベントＩＤとも呼ばれる。イベント日時２１１は、イベントが開始される日時を示している。例えば、「2023/1/1 10:00」は、「２０２３年１月１日 １０時００分」を示す。

【0034】

イベント種別２１２は、イベントの種別を示している。イベント種別２１２は、イベントが「リアル」であるか、又は「オンライン」であるか、を示す情報を含み得る。リアルイベントは、所定のイベント会場に参加者を集めて開催されるイベントを示している。ユーザは、イベント会場に赴いてイベントに参加する。リアルイベントは、例えば、コンサートなどである。オンラインで開催されるオンラインイベントに対し、リアルイベントは、オフラインで開催されるイベントであるといえる。なお、イベント種別は「リアル」と「オンライン」に限定されるものではない。例えば、「ビジネス」、「家族」、「趣味」といったイベント種別を用いてもよい。

【0035】

ユーザは、リアルイベントに参加する場合、ユーザ端末１を、関係者への連絡手段として用い得る。よって、ユーザ端末１が故障した場合、ユーザは関係者と連絡を取ることができなくなるおそれがある。

【0036】

リアルイベントに対し、オンラインイベントは、インターネットや専用回線などを用いて、オンラインで開催されるイベントを示している。オンラインイベントは、参加者を所定のイベント会場に集めることなく開催され得る。参加者は、自身が使用するＰＣなどの端末装置を用いて、任意の場所からオンラインイベントに参加することができる。オンラインイベントは、例えば、Ｗｅｂ会議などである。

【0037】

ユーザは、ユーザ端末１を用いてオンラインイベントに参加する場合、ユーザ端末１の故障により、イベントへの参加ができなくなる。但し、ユーザが予備の端末装置を使用可能な場合、ユーザはイベントに参加することができる。

【0038】

イベント名２１３は、イベントの名称を示している。イベント場所２１４は、ユーザがイベントに参加する場所を示している。イベント種別２１２がリアルイベントの場合、イベント場所２１４（イベントの場所）は、イベントの開催場所あるいは関係者との待ち合わせ場所である。イベント種別２１２がオンラインイベントの場合、イベント場所２１４は、ユーザがオンラインイベントに参加する予定の場所（例えば、「自宅」等）である。

【0039】

なお、図３では省略しているが、イベント情報２１は、オンラインイベントの場合、オンラインイベントに参加するためのＵＲＬ等を、イベントと対応付けて、さらに記録してもよい。

【0040】

第１関係者２１５は、イベントの第１の関係者を示している。第１連絡先２１６は、第１関係者２１５の連絡先を示している。第１連絡先２１６は、例えば、通知情報の宛先を示すメールアドレスである。第１連絡先２１６は、電話番号などであってもよいし、ＳＮＳのアカウント情報であってもよい。第２関係者２１７は、第１関係者２１５とは異なるイベントの関係者を示している。第２連絡先２１８は、第２関係者２１７の連絡先を示している。

【0041】

なお、本図に示す例では、イベント情報２１は、第１関係者と第２関係者とを含んでいるが、もちろんこれに限定されるものではない。イベント情報２１は、任意の数の関係者及び連絡先を含んでもよい。また、イベントごとに異なる数の関係者及び連絡先を記憶できるようにしてもよい。また、本図において、関係者及び連絡先が存在しない場合には、その旨が「ＮＵＬＬ」で示されている。

【0042】

予備端末の有無２１９は、ユーザ端末１以外にイベント参加可能な予備端末が存在するか否かを示す情報である。ユーザがイベント情報２１を作成する際に、ユーザ端末１を操作して、予備端末の有無２１９を設定してもよい。また制御部３０が、イベント場所に応じて、予備端末の有無２１９を自動的に設定してもよい。例えば、制御部３０は、イベント場所が「自宅」あるいは「職場」である場合には、予備端末の有無２１９を「有」に設定し、それ以外の場所では「無」に設定してもよい。これは、「自宅」あるいは「職場」においては、ユーザ端末１以外にユーザが使用可能な予備端末がある可能性が高く、それ以外の場所（外出先など）では予備端末がない可能性が高いという知見に基づく処理である。換言すれば、イベント場所が所定の場所である場合に、予備端末の有無２１９を「有」に設定し、それ以外の場所では「無」に設定してもよい。予備連絡先２２０は、通常は公開していない、ユーザの連絡先である。本実施形態では、連絡先として電子メールアドレスを用いるが、これに限定される訳ではなく、電話番号やＳＮＳのアカウント情報などを用いてもよい。なお、イベント種別２１２、イベント名２１３、イベント場所２１４、予備端末の有無２１９、及び、予備連絡先２２０の項目は、省略することも可能である。

【0043】

図２に戻り説明を続ける。制御部３０は、本実施形態にかかる通知制御処理を行う通知制御装置として機能する。本実施形態では、ユーザ端末１が制御部３０を備える構成を用いるが、これに限られない。他の装置が制御部３０の構成を備えるようにしてもよい。例えば、所定の情報処理サーバが制御部３０の機能を有していてもよい。例えば、メールサーバ５が本実施形態にかかる制御部３０に対応する機能を備えていてもよい。

【0044】

制御部３０は、センサ情報取得部３１、イベント情報取得部３２、端末位置情報取得部３３、故障予測部３４、特定部３６、及び送信制御部３７を備えている。

【0045】

センサ情報取得部３１は、ユーザ端末１が備えるセンサ部１０において検出されたセンサ情報を取得する。本実施形態では、センサ情報取得部３１は、加速度センサ１１、磁気センサ１２、温度・湿度センサ１３、及び圧力センサ１４のそれぞれからセンサ情報を取得する。例えば、センサ情報取得部３１は、ユーザ端末１の落下状態に関する情報を、センサ情報として、加速度センサ１１から取得する。

【0046】

イベント情報取得部３２は、イベントの日時と、イベントの関係者の連絡先と、が少なくとも関連付けられたイベント情報２１を取得する。イベント情報取得部３２は、記憶部２０を参照してイベント情報２１を取得してもよいし、ネットワークＮを介して、他の装置からイベント情報２１を取得してもよい。また、イベント情報２１に複数のユーザの情報が含まれている場合（複数のユーザＩＤが含まれている場合）には、イベント情報取得部３２は、ユーザ端末１のユーザが参加するイベントの情報のみを取得すればよい。すなわち、イベント情報取得部３２は、ユーザ端末１のユーザが係るイベントの情報を取得する。

【0047】

端末位置情報取得部３３は、ユーザ端末１の位置を示す端末位置情報を、位置検出部５０から取得する。端末位置情報取得部３３は、所定の時間間隔で端末位置情報を取得してもよい。

【0048】

故障予測部３４は、センサ情報取得部３１で取得されたセンサ情報に基づいて、ユーザ端末１の故障予測を行う。故障予測は、センサ情報に基づいて、ユーザ端末１が故障する可能性があることを予測するものである。

【0049】

故障予測部３４は、例えば、加速度センサ１１で検出されたユーザ端末１の落下に関する情報を用いて、ユーザ端末１の故障予測を行う。故障予測部３４は、加速度センサ１１でユーザ端末１の落下状態が検出された場合、落下状態の継続時間を計測する。

【0050】

落下状態は、例えば、ユーザ端末１が自由落下している状態を含む。例えば、故障予測部３４は、図示しないタイマを用いて、落下状態が検出されたタイミングから、落下状態の終了が検出されたタイミングまでの時間を計測してもよい。制御部３０がタイマを備えていてよいし、センサ部１０がタイマを備えていてもよい。また例えば、故障予測部３４は、落下状態の開始のタイミング（開始時点）からの継続時間を計測してもよい。この場合、加速度センサ１１および故障予測部３４は、落下状態の終了を検出しなくてもよく、落下の継続時間が所定の時間（所定の閾値）を超えたことを検出すればよい。故障予測部３４は、加速度センサ１１から、落下の継続時間の情報をセンサ情報として取得してもよい。

【0051】

故障予測部３４は、落下状態の継続時間が所定の閾値以上であるか否かを判定し、判定結果に基づいて、ユーザ端末１の故障を予測する。落下状態の継続時間が長い場合、ユーザ端末１が床や地面に衝突した際の衝撃が大きいと予想され、ユーザ端末１が故障する可能性が高いと予想される。一方、落下状態の継続時間が短い場合、ユーザ端末１が床や地面に衝突した際の衝撃が小さいと予想され、ユーザ端末１が故障する可能性は低いと予想される。このため、所定の閾値を適切な値に設定することにより、ユーザ端末１が故障する可能性を適切に判定することができる。所定の閾値は、固定されてもよいし、適宜変更されてもよい。

【0052】

具体的には、過去又は現在においてセンサ部１０において検出されたセンサ情報に応じて、所定の閾値を変更してもよい。例えば、過去において加速度センサ１１で検出された最大加速度あるいは圧力センサ１４で検出された最大圧力が大きいほど、所定の閾値を低い値（小さい値）にしてもよい。

【0053】

また例えば、過去において加速度センサ１１で所定値以上の加速度が検出された回数、あるいは圧力センサで所定値以上の圧力が検出された回数が多いほど、所定の閾値を低い値（小さい値）にしてもよい。これらは、過去に大きな加速度や圧力が加えられたり、頻繁に加速度や圧力が加えられたユーザ端末１は、その影響がユーザ端末１の内部に残っている可能性があり、小さな衝撃でも故障する可能性が高いという知見に基づく処理である。なお、ここでの過去とは、過去の所定期間（例えば、直近の３か月）であってもよいし、期間を定めない過去であってもよい。

【0054】

また例えば、現在の温度・湿度センサ１３で検出された温度が所定の温度範囲（例えば、ユーザ端末１の動作温度範囲）を超えている場合に、所定の閾値を低い値にしてもよい。これは、現在の温度が所定の温度範囲を超えている場合には、それだけでユーザ端末１にかかる負荷が大きくなっており、、小さな衝撃でも故障する可能性が高いという知見に基づく処理である。

【0055】

さらに温度・湿度センサ１３の過去のセンサ情報に基づいて所定の閾値を設定してもよい。例えば、温度・湿度センサ１３において過去に所定の温度範囲（例えば、ユーザ端末１の動作温度範囲）を超えた温度が検出された回数が多いほど、所定の閾値を低い値にしてもよい。これは、過去に所定の温度範囲を超えた回数が多い場合には、ユーザ端末１内部の部品が劣化している可能性が高いため、小さな衝撃でも故障する可能性が高いという知見に基づく処理である。また例えば、過去に検出された最高温度が高いほど、あるいは過去に検出された最低温度が低いほど、所定の閾値を低い値にしてもよい。これは、過去に高い温度あるいは低い温度が検出された場合には、ユーザ端末１内部の部品が劣化している可能性が高いため、小さな衝撃でも故障する可能性が高いという知見に基づく処理である。

【0056】

物体の落下時間は、落下する高さ及び重力加速度から求めることができる。例えば、ユーザ端末１が１ｍの高さから地面に自由落下した場合、ユーザ端末１の落下時間は、およそ０．４５秒である。故障予測部３４は、当該秒数が考慮された閾値を用いて故障予測を行い得る。落下状態の継続時間が所定の閾値以上である場合、故障予測部３４は、ユーザ端末１が故障する可能性があると予測する。例えば、ユーザ端末１が１ｍないし１．５ｍの高さから落下した場合の落下時間を所定の閾値とし、それ以上の継続時間が検出された場合に、ユーザ端末１が故障する可能性があると予測してもよい。

【0057】

落下状態の継続時間が長い場合、ユーザ端末１が高い場所から落下している可能性が高い。この場合、ユーザ端末１が床等に衝突した際の衝撃が大きいことが想定されるので、故障予測部３４は、ユーザ端末１が故障する可能性が高いと予測することができる。

【0058】

また、故障予測部３４は、磁気センサ１２、温度・湿度センサ１３、又は圧力センサ１４で検出されたセンサ情報に基づいて、ユーザ端末１の故障を予測する。例えば、故障予測部３４は、磁気、温度、湿度（水分）、又は圧力に基づいて、ユーザ端末１の故障を予測する。

【0059】

故障予測部３４は、それぞれのセンサで取得された物理量を用いて故障を予測する。故障予測部３４は、あらかじめ設定された閾値を用いて故障を予測し得る。例えば、故障予測部３４は、温度・湿度センサ１３で検出されたユーザ端末１の温度や湿度が所定の閾値以上である場合、あるいは温度や湿度が所定の閾値以下である場合、ユーザ端末１の故障を予測する。同様に、磁気センサ１２で検出された磁気の強さが所定の閾値以上であった場合や、圧力センサ１４で検出した圧力が所定の閾値以上であった場合、ユーザ端末１の故障を予測する。

【0060】

特定部３６は、故障予測部３４においてユーザ端末１の故障が予測された場合、イベント情報２１を参照し、ユーザ端末１が故障した場合に影響を受ける可能性の高いイベントを処理対象のイベントとして抽出する。具体的には、故障予測がなされた以降に開催予定のイベントを抽出する。例えば、特定部３６は、故障予測がなされた時点以降に開催予定のイベントを全て（期限を定めずに）抽出してもよい。また例えば、特定部３６は、故障予測がなされた時点から所定の対象期間（例えば、２４時間）内に開催予定のイベントを抽出する。これは、ユーザ端末１が故障した場合、故障直後に開催されるイベントの関係者に対してユーザが連絡できない可能性が高いため、関係者に与える影響が大きいと予測されるという知見に基づく処理である。また、故障直後に開催されるイベントに関しては、ユーザ端末１の代わりの端末をユーザが用意できる可能性が低い（時間的な余裕がない）ため、ユーザがオンラインイベント等に参加できない可能性が高いという知見に基づく処理である。また、特定部３６は、抽出したイベントの関係者の連絡先を、故障予測に関する通知情報の送信先として特定する。

【0061】

上述した図３の例を用いて具体的に説明する。例えば、２０２３年１月１日の９時３０分に、故障予測部３４がユーザ端末１の故障を予測したとする。この場合、特定部３６は、故障予測がなされてから２４時間以内に開催予定であるＩＤ「１」のイベントを抽出する。

【0062】

特定部３６は、抽出したＩＤ「１」のイベントに対応付けられた関係者の連絡先を、通知情報の送信先として特定する。ＩＤ「１」のイベントには、第１関係者である「Ａ氏」の連絡先として「[e-mail]」が設定されている。特定部３６は、当該連絡先を、通知情報の送信先として特定する。第２関係者が設定されている場合、特定部３６は、第２関係者の連絡先を、送信先としてさらに特定してもよい。このようにして、特定部３６は、イベントごとに、通知情報の送信先を特定する。

【0063】

また、特定部３６は、故障予測部３４においてユーザ端末１の故障が予測された場合、イベントの場所を加味して、処理対象のイベントを抽出してもよい。具体的には、特定部３６は、イベント情報２１を参照し、故障予測がなされた以降に開催予定のイベントであり、かつ、イベントの場所がユーザ端末１の位置から所定の範囲外であるイベントを抽出する。特定部３６は、抽出したイベントの関係者の連絡先を通知情報の送信先として特定するようにしてもよい。なお、ユーザ端末１の位置から所定の範囲内を「所定の場所」と言い換えることもできるので、特定部３６は、故障予測がなされた以降に開催予定のイベントであり、かつ、イベントの場所が所定の場所以外のイベントを抽出するともいえる。

【0064】

またこの場合、特定部３６は、イベント種別が「リアル」であるか、又は「オンライン」であるか、の情報を加味してもよい。特定部３６は、イベント種別が「リアル」であり、かつ、ユーザ端末１の位置がイベントの場所から所定の距離以内である場合、処理対象のイベントとして抽出しない。このようにすることで、ユーザが開催間近のリアルイベントの会場近くまで移動している場合、送信制御部３７において、関係者に通知情報を送信しないようにすることができる。これは、ユーザ端末１の故障により、ユーザが電話や電子メール等の通信手段を使えない場合であっても、ユーザが予定通りイベント会場に到着する可能性が高いためである。このような場合、ユーザが関係者と連絡が取れない状況であっても、関係者に影響を与える可能性は低いことが想定される。

【0065】

また、特定部３６は、予備端末の有無に応じて、処理対象のイベントを抽出してもよい。例えば、特定部３６は、予備端末の有無が「無」又は「ＮＵＬＬ」に設定されている場合のみ、処理対象のイベントとして抽出する。これにより、予備端末が存在する場合には、送信制御部３７において、関係者に通知情報を送信しないようにすることができる。これは、予備端末が存在する場合には、ユーザが予定通りイベントに参加できる可能性が高いためである。なお、上述したように、イベント場所が「自宅」あるいは「職場」等の所定の場所以外であるイベントについて、予備端末を「無」と自動的に設定する処理を行った場合、特定部３６は、故障予測がなされた以降に開催予定のイベントであり、かつ、イベントの場所が所定の場所以外のイベントを抽出するともいえる。

【0066】

さらに、特定部３６は、イベント種別及び予備端末の有無に応じて処理対象のイベントを抽出してもよい。例えば、特定部３６は、イベント種別が「オンライン」であり、かつ、予備端末の有無が「無」又は「ＮＵＬＬ」に設定されている場合のみ、処理対象のイベントとして抽出する。これは、特にオンラインイベントにおいて、予備端末が存在する場合にはユーザがイベントに参加できる可能性が高く、予備端末が存在しない場合にはユーザがイベントに参加できない可能性が高いためである。

【0067】

またさらに、イベントに設定されている関係者に応じて処理対象のイベントを抽出してもよい。具体的には、記憶部２０に関係者（人物）ごとの重要度を記憶させておく。例えば、関係者（人物）のメールアドレス等に関連付けて（紐づけて）、「１」（非常に重要でない）、「２」（やや重要でない）、「３」（普通）、「４」（やや重要）、「５」（非常に重要）といった重要度を記憶部２０に記憶させておく。重要度は、ユーザがユーザ端末１を操作して、例えばアドレス帳の管理の一環として、あらかじめ登録しておけばよい。そして特定部３６は、記憶部２０を参照し、重要度が所定の閾値（例えば、「３」）以上の人物が関係者として設定されているイベントを処理対象のイベントとして抽出する。また同様に、ユーザがイベントごとにイベントの重要度を設定し、それをイベント情報２１に含めておいてもよい。すなわち、イベント情報２１において、イベントＩＤとイベントの重要度とを関連付けて記憶させてもよい。そして特定部３６は、記憶部２０を参照し、重要度が所定の閾値以上のイベントを処理対象のイベントとして抽出してもよい。

【0068】

図２に戻り説明を続ける。送信制御部３７は、送信先に対する通知情報の送信を制御する。通知情報は、例えば、関係者が使用する関係者端末３に送信する電子メールである。通知情報は、ＳＭＳやチャットサービスやＳＮＳにおけるメッセージであってもよい。送信制御部３７は、通知情報を作成し、通信部４０に対してメール送信を指示する。

【0069】

ここで、図４を参照して、通知情報について説明する。図４は、通知情報の一例である故障予測通知３１０を示す図である。故障予測通知３１０は、例えば、関係者端末３が備える表示部に表示される。

【0070】

本図に示すように、故障予測通知３１０は、タイトル３１１、通知文３１２、故障予測日時３１３、故障予測内容３１４、予測場所位置情報３１５、予測場所地図情報３１６、イベント種別３１７、イベント名３１８、イベント場所３１９、予備端末の有無３２０、及び予備連絡先３２１の項目を含んでいる。

【0071】

タイトル３１１は、メールタイトルであり、故障予測の通知であることを示している。通知文３１２は、故障予測を通知する旨を示すメッセージである。通知文３１２は、定型文が用いられ得る。

【0072】

故障予測日時３１３は、故障予測が行われた日時を示している。故障予測日時３１３は、例えば、故障予測部３４において、落下状態の継続時間が所定の閾値以上となったタイミングの日付及び時刻である。故障予測日時３１３は、ユーザ端末１が備える図示しない時計機能から取得され得る。

【0073】

故障予測内容３１４は、故障の可能性が高いと判定した理由を示している。例えば、故障予測内容３１４は、閾値を超えて検出された物理量などを示す。具体的には、故障予測内容３１４は、長時間の落下、強い磁気、高温度、高湿度、高圧力、又は強い衝撃などである。なお故障予測内容３１４は省略してもよい。例えば、ユーザが故障予測内容３１４を関係者に知らせたくない場合には、ユーザ端末１を操作して、あらかじめ故障予測内容３１４を故障予測通知３１０に含めない設定を行い、その情報を記憶部２０に記憶しておいてもよい。またさらに、ユーザがユーザ端末１を操作して、故障予測通知３１０に含める項目を任意に選択し、その情報を記憶部２０に記憶しておいてもよい。送信制御部３７は、記憶部２０を参照し、ユーザにより選択された項目で構成される通知情報を作成してよい。

【0074】

予測場所位置情報３１５は、故障予測時点におけるユーザ端末１の位置情報、例えば緯度、経度を示している。予測場所位置情報３１５は、位置検出部５０において取得される。もちろん、予測場所位置情報３１５は、緯度、経度に限らず、住所表示であったり、ランドマーク（例えば、最寄り駅）からの方角と距離であってもよい。予測場所地図情報３１６は、予測場所位置情報３１５で示される位置の周囲の地図画像を示している。予測場所地図情報３１６は、ユーザ端末１が備える地図機能などから取得され得る。予測場所地図情報３１６は、地図画像を提供するサーバなどのような、ユーザ端末１以外の装置から取得されてもよい。

【0075】

イベント種別３１７、イベント名３１８、イベント場所３１９、予備端末の有無３２０、及び予備連絡先３２１は、イベント情報２１のイベント種別２１２、イベント名２１３、イベント場所２１４、予備端末の有無２１９、及び予備連絡先２２０にそれぞれ対応する。

【0076】

なお、上述した故障予測通知３１０は通知情報の一例である。予測場所位置情報３１５、予測場所地図情報３１６、イベント種別３１７、イベント名３１８、イベント場所３１９、予備端末の有無３２０、及び予備端末の有無３２０の項目は、省略することも可能である。

【0077】

図２に戻り説明を続ける。通信部４０は、関係者端末３との間、及びメールサーバ５との間で通信を行う。通信部４０は、有線又は無線により通信を行うための通信インタフェースであってよい。通信部４０は、送信制御部３７から指示された宛先及び内容を含む通知情報を、メールサーバ５に対して送信する。

【0078】

位置検出部５０は、ユーザ端末１の位置を検出する。位置検出部５０は、検出された位置を示す端末位置情報を制御部３０に出力する。位置検出部５０は、例えば、ＧＮＳＳ（Global Navigation Satellite System）等の技術を用いて測位を行う。位置検出部５０は、例えば、ＧＰＳ（Global Positioning System）受信機等で構成され得る。また例えば、ユーザ端末１の周囲にある無線ＬＡＮのアクセスポイントの情報を用いて位置を検出してもよい。なお、ユーザ端末１は、位置検出部５０を備えない構成であってもよい。

【0079】

（ユーザ端末１の処理）
続いて、図５及び図６を参照して、ユーザ端末１が行う処理を説明する。図５は、加速度センサ１１の検出結果を用いて故障予測を行う場合にユーザ端末１が行う処理を示すフローチャートである。図６は、加速度センサ１１以外のセンサの検出結果を用いて故障予測を行う場合にユーザ端末１が行う処理を示すフローチャートである。

【0080】

（加速度センサ１１における検出結果を用いる場合）
まず、図５を参照して、加速度センサ１１の検出結果を用いて故障予測を行う場合にユーザ端末１が行う処理を説明する。

【0081】

ステップＳ１において、加速度センサ１１は、ユーザ端末１の落下状態を検出する。加速度センサ１１は、例えば、その出力値が「０」の状態を検出することにより、ユーザ端末１の自由落下状態を検出することができる。また例えば、加速度センサ１１は、加速度の値あるいは加速度の変化量が所定の閾値を超えた状態を検出することにより、ユーザ端末１の落下状態の開始及び終了を検出できる。加速度センサ１１は、ユーザ端末１の落下状態を検出した場合に、その旨を制御部３０へ通知する。センサ情報取得部３１は、ユーザ端末１が落下状態である旨の通知をセンサ情報として取得する。

【0082】

ステップＳ２において、故障予測部３４は、加速度センサ１１から取得された落下状態の通知を基に、落下状態の継続時間（落下状態の開始が検出された時点からの経過時間）が所定の閾値以上であるか否かを判定する。これにより、故障予測部３４は、ユーザ端末１の故障予測を行う。落下状態の継続時間が閾値以上である場合（Ｓ２：Ｙｅｓ）、ステップＳ３へ進む。落下状態の継続時間が閾値未満である場合（Ｓ２：Ｎｏ）はステップＳ１に戻り処理を繰り返す。

【0083】

ステップＳ３において、イベント情報取得部３２は、ユーザ端末１の故障により影響を受ける可能性の高いイベント情報を取得する。具体的には、イベント情報取得部３２は、故障予測がなされた時点以降に開催予定のイベント、あるいは故障予測がなされた時点から、あらかじめ設定した所定の対象期間（例えば、２４時間）以内に開催予定のイベントのイベント情報２１を記憶部２０から取得する。なお上述したように、イベント情報２１に複数のユーザの情報が含まれる場合には、イベント情報取得部３２は、ユーザ端末１のユーザが係るイベントの情報を取得する。上述したように、イベント情報２１は、少なくとも、イベントの日時と、イベントの関係者の連絡先と、が関連付けられている。ただし、ステップＳ３においては、イベント日時を限定せずに全てのイベント情報を取得し、ステップＳ４において特定部３６が、故障により影響を受ける可能性の高いイベントを抽出してもよい。

【0084】

ステップＳ４において、特定部３６は、処理対象のイベントを抽出（特定）する。具体的には、特定部３６は、ステップＳ３において取得されたイベント情報のうち、少なくとも１人の関係者が設定されているイベントを処理対象とする。なお、「関係者が設定されている」という条件の他に、さらに別の条件を加えて処理対象のイベントを抽出してもよい。説明を簡潔にするために、以下のステップＳ４に関する説明においては、「関係者が設定されている」という条件を省略する。

【0085】

特定部３６は、イベントの場所を加味して、処理対象のイベントを抽出（特定）してもよい。具体的には、特定部３６は、故障予測がなされた以降に開催予定のイベントであり、かつ、イベントの場所がユーザ端末１の位置から所定の範囲外であるイベントを抽出する。またこの場合、特定部３６は、イベント種別が「リアル」であるか、又は「オンライン」であるか、の情報を加味してもよい。特定部３６は、イベント種別が「リアル」であり、かつ、ユーザ端末１の位置がイベントの場所から所定の距離以内である場合、処理対象のイベントとして抽出しない処理を行ってもよい。

【0086】

さらに、特定部３６は、予備端末の有無に応じて、処理対象のイベントを抽出（特定）してもよい。例えば、特定部３６は、予備端末の有無が「無」又は「ＮＵＬＬ」に設定されている場合のみ、処理対象のイベントとして抽出するようにしてもよい。また上述したように、特定部３６は、イベントの関係者に対して設定された重要度に応じて、処理対象のイベントを抽出（特定）してもよい。例えば、特定部３６は、重要度が所定の閾値（例えば、「３」）以上の人物が関係者として設定されているイベントを処理対象のイベントとして抽出してもよい。また例えば、特定部３６は、重要度が所定の閾値（例えば、「３」）以上のイベントを処理対象のイベントとして抽出してもよい。

【0087】

ステップＳ５において、特定部３６は、ステップＳ４において抽出された処理対象のイベントの関係者の連絡先を、故障予測に関する通知情報の送信先として特定する。１つのイベントに対して複数の関係者が設定されている場合、特定部３６は、複数の関係者のそれぞれに対応する送信先を特定する。また、ステップＳ４において抽出された処理対象のイベントが複数ある場合、特定部３６は、複数のイベントのそれぞれに対応する関係者を、通知情報の送信先として特定する。

【0088】

ステップＳ６において、送信制御部３７は、通知情報を作成し、通信部４０へ通知を指示する。ここでは、送信制御部３７は、図４に示される故障予測通知３１０のような電子メールを通知情報として作成する。これに限らず、通知情報は、ＳＭＳやチャットサービスにおけるメッセージであってもよい。複数の送信先が特定された場合、送信制御部３７は、それぞれの送信先に対する通知を指示する。

【0089】

通信部４０は、送信制御部３７からの指示を受けて、故障予測通知３１０をメールサーバ５に送信する。これにより、メールサーバ５は、故障予測通知３１０を関係者端末３に送信する。関係者は、関係者端末３の表示部に表示された故障予測通知３１０を視認することで、ユーザ端末１がイベントに参加できない可能性があることを把握することができる。

【0090】

このように、図５に示す処理によれば、センサ部１０がユーザ端末１の落下状態を検出し、制御部３０が故障予測通知３１０の送信先を特定し、通信部４０がメールサーバ５に通知を指示する。これにより、ユーザ端末１が床等に衝突して故障する前に、通信部４０が故障予測通知３１０を送信できる可能性を高めることができる。つまり、ユーザ端末１の故障により、故障予測通知３１０が送信できなくなるリスクを低減することができる。

【0091】

（加速度センサ１１以外のセンサにおける検出結果を用いる場合）
続いて、図６を参照して、加速度センサ１１以外の検出結果を用いて故障予測を行う場合にユーザ端末１が行う処理を説明する。ユーザ端末１は、センサ部１０で検出された磁気、温度、湿度、圧力、又は衝撃などのセンサ情報を用いて故障を予測する。ユーザ端末１は、検出されたこれらの物理量のうち、少なくとも１つを用いて、落下状態以外の状態を検出して故障予測を行う。

【0092】

ステップＳ１１において、センサ情報取得部３１は、各種センサで検出されたセンサ情報を取得する。ここでは、センサ情報取得部３１は、加速度センサ１１、磁気センサ１２、温度・湿度センサ１３、及び圧力センサ１４で検出された加速度、磁気、温度、湿度、及び圧力をそれぞれ取得することとする。例えば、センサ情報取得部３１は、加速度センサ１１で検出された瞬間的な衝撃に対応する物理量を示す値などを取得する。

【0093】

ステップＳ１２において、故障予測部３４は、センサ情報取得部３１で取得されたそれぞれの値が、あらかじめ設定された所定の範囲を超えるか否かを判定する。例えば、温度が第１の値以上かつ第２の値以下（ただし、第１の値＜第２の値）範囲を所定の範囲として設定した場合、温度が第１の値未満である場合、あるいは温度が第２の値より高い場合に所定の範囲を超えると判定される。所定の範囲は、センサ情報の種類（物理量）に応じてそれぞれ設定され得る。１つでも所定の範囲を超える値がある場合、ステップＳ１３へ進む。

【0094】

ステップＳ１３～Ｓ１６は、図５におけるステップＳ３～Ｓ６と同様であるので説明を省略する。

【0095】

このように、図６に示す処理によれば、ユーザ端末１は、故障予測部３４において、センサ部１０が備える各種センサで取得されたセンサ情報を用いて故障予測を行う。これにより、落下に限らず、他の要因でユーザ端末１が故障する可能性が高い場合にも、送信先を特定し、故障予測通知３１０を送信することができる。また、例えば、温度・湿度センサ１３を用いて温度を検出することにより、故障予測部３４は、高温や低温のためにユーザ端末１が故障する可能性を予測し、その可能性が高い場合に故障予測通知３１０を送信することができる。

【0096】

以上説明したように、本実施形態にかかる故障通知システム１００では、ユーザ端末１は、センサ部１０で検出されたセンサ情報に基づいて、ユーザ端末１が故障する可能性が高いか否かを判定する故障予測を行うことができる。また、ユーザ端末１が故障する可能性が高い場合に、ユーザ端末１は、ユーザが参加する予定のイベントのうち、故障により影響を受ける可能性が高いイベントを抽出し、そのイベントの関係者を通知情報の送信先として特定する。ユーザ端末１は、特定された送信先に対し、ユーザがイベントに参加できない可能性を示す通知情報を送信するので、イベントの関係者の不便を軽減することができる。

【0097】

このような構成により、本実施形態にかかる故障通知システム１００によれば、ユーザ端末１の故障が予測された場合に、イベントの関係者に対して適切に通知を行うことができる。

【0098】

＜実施形態２＞
続いて、実施形態２について説明する。実施形態１にかかる故障通知システム１００は、落下などによりユーザ端末１が故障すると予測された場合、関係者の連絡先に対して直ちに通知情報を送信する構成を備えていた。

【0099】

しかしながら、故障を予測した際に通知を送信した後、ユーザ端末１の故障が起きない可能性がある。つまり、実施形態１では、本来送信する必要のない通知情報を関係者に送信してしまう可能性がある。

【0100】

本実施形態にかかる故障通知システム１００ａは、電子メールの予約機能を用いて、電子メールの送信予約を行う。電子メールの予約機能とは、電子メールの送信日時を指定することで、その日時に電子メールを自動送信する機能である。故障通知システム１００ａは、予約機能を用いることで、故障予測がなされた後、実際に故障が発生したか否かに応じて、関係者への通知情報の送信を制御することができる。

【0101】

図７は、本実施形態にかかる故障通知システム１００ａの構成を示すブロック図である。故障通知システム１００ａは、ユーザ端末１ａ、関係者端末３、及びメールサーバ５ａを備えている。故障通知システム１００ａの構成は、図１に示される故障通知システム１００と概ね同様である。以下では、故障通知システム１００と異なる点を中心に説明し、重複する点については適宜説明を省略する。

【0102】

メールサーバ５ａは、電子メールの送信予約を行う機能と、送信予約を取り消す機能と、を備えている。例えば、メールサーバ５ａは、ユーザ端末１から、通知情報の送信予約を行うための予約情報を受信して、通知情報の送信予約を行う。予約情報は、通知情報や送信先の情報に加え、送信先に通知情報を送信する送信日時の情報を含む。

【0103】

また、メールサーバ５ａは、ユーザ端末１ａから送信予約を取り消すための予約取消情報を受信して、送信予約を取り消す。予約取消情報は、取り消す対象の予約に関する情報を含む。メールサーバ５ａは、送信日時までに予約が取り消されなかった場合、送信先に対して通知情報を送信する。

【0104】

（ユーザ端末１ａの構成）
図８を参照して、ユーザ端末１ａについて説明する。図８は、ユーザ端末１ａの構成を示すブロック図である。ユーザ端末１ａは、図２に示されるユーザ端末１における制御部３０とは構成が異なる制御部３０ａを備えている。制御部３０ａは、制御部３０の構成に加え、ユーザ端末１ａが故障したか否かを判定する故障判定部３５をさらに備えている。また、制御部３０ａは、送信制御部３７と構成が異なる送信制御部３７ａを備えている。

【0105】

故障判定部３５は、送信制御部３７ａが予約情報を送信した後、所定時間（例えば、１０分）が経過する前に、ユーザ端末１ａが故障したか否かを判定する。所定時間は、あらかじめ設定され得る。また所定時間は、固定されてもよいし、例えば、故障の可能性やイベント開催日時までの期間に応じて変更されてもよい。

【0106】

送信制御部３７ａは、故障予測がなされた時点から所定時間（例えば、１０分）の経過後の送信日時に、通知情報が送信先に送信されるように送信予約を行うための予約情報を通信部４０を介して、メールサーバ５ａに送信する。ただし可能な限り、送信日時がイベントの開始日時よりも前になるように設定する。また、送信制御部３７ａは、故障判定部３５においてユーザ端末１ａが故障していないと判定された場合、送信予約を取り消すための予約取消情報をメールサーバ５ａに送信する。

【0107】

具体例を用いて説明する。例えば、所定時間が１０分に設定されており、２０２３年１月１日の９時３０分に、故障予測部３４がユーザ端末１ａの故障を予測したとする。送信制御部３７ａは、故障予測がなされた同日９時３０分の時点において、予約情報をメールサーバ５ａに送信する。当該予約情報は、関係者の連絡先である送信先に対し、同日９時４０分に通知情報を送信するための指示を含んでいる。

【0108】

故障判定部３５は、送信制御部３７が予約情報を送信した後、１０分が経過する前に、ユーザ端末１ａが実際に故障したか否かを判定する。したがって、故障判定部３５は、同日９時４０分より前に、ユーザ端末１ａが故障したか否かを判定する。例えば、故障判定部３５は、加速度センサ１１のセンサ情報をもとに、落下状態が終了したことを検出したタイミングでユーザ端末１ａが実際に故障したか否かを判定する。一般的に、落下状態が継続するのは数秒程度なので、落下後にユーザ端末１が正常に動作している場合、当然ながら９時４０分よりも前に判定がなされる。

【0109】

故障判定部３５においてユーザ端末１ａが故障していると判定された場合、又は、故障しているか否かが判定できない場合（故障により判定処理が実行できない場合）、送信制御部３７ａは、予約取消情報をメールサーバ５ａに送信しない。そのため、メールサーバ５ａは、予約情報に従い、同日９時４０分に通知情報を送信する。これにより、関係者は、ユーザがイベントに参加できない可能性があることを把握することができる。

【0110】

一方、故障判定部３５においてユーザ端末１ａが故障していないと判定された場合、送信制御部３７ａは、送信予約を取り消すための予約取消情報をメールサーバ５ａに送信する。これにより、メールサーバ５ａは、送信予約を取り消す。そのため、メールサーバ５ａは、同日９時４０分になっても通知情報を送信しない。これにより、関係者端末３が不要な通知情報を受信することがないので、関係者に不便が生じない。

【0111】

（ユーザ端末１ａの処理）
続いて、図９及び図１０を参照して、ユーザ端末１ａが行う処理を説明する。図９は、加速度センサ１１の検出結果を用いて故障予測を行う場合にユーザ端末１ａが行う処理を示すフローチャートである。図１０は、加速度センサ１１以外のセンサの検出結果を用いて故障予測を行う場合にユーザ端末１ａが行う処理を示すフローチャートである。

【0112】

（加速度センサ１１における検出結果を用いる場合）
まず、図９を参照して、加速度センサ１１の検出結果を用いて故障予測を行う場合にユーザ端末１ａが行う処理を説明する。ステップＳ２１～Ｓ２５は、図５におけるステップＳ１～Ｓ５と同様であるので説明を省略する。

【0113】

ステップＳ２６において、送信制御部３７ａは、通知情報として故障予測通知３１０を作成して、電子メールの送信予約の設定を通信部４０に指示する。送信制御部３７ａは、現在時刻（故障を予測した日時）からあらかじめ設定した所定時間経過後の日時を送信日時として設定する。例えば、所定時間を１０分とすればよいが、送信制御部３７ａは、所定時間後の日時がイベント日時よりも前になるように、送信日時を設定する。通信部４０は送信日時が設定された予約情報をメールサーバ５ａに送信する。

【0114】

ステップＳ２７において、故障判定部３５は、落下の検出終了時（落下の終了が検出された後）に、ユーザ端末１ａにおいて実際に故障が発生したか否かを判定する。例えば、故障判定部３５は、ユーザ端末１ａが備える各機能が正常に動作しているか否かを判定する。故障判定部３５において、各機能が正常動作しており、故障が発生していないと判定された場合（Ｓ２７：故障なし）、ステップＳ２８へ進む。

【0115】

また、故障判定部３５において、各機能が正常動作しておらず、故障が発生していると判定された場合（Ｓ２７：故障あり）は、処理を終了する。この場合、メールサーバ５ａは、設定された送信日時に故障予測通知３１０を送信先に送信する。

【0116】

また、ユーザ端末１ａが故障したことにより、故障判定部３５において故障の判定ができない場合（Ｓ２７：判定不可）も、故障が発生したと判定された場合と同様に、処理を終了する。

【0117】

ステップＳ２８において、送信制御部３７ａは、送信予約の取消しを通信部４０へ指示する。送信制御部３７ａは、送信予約を取り消すための予約取消情報を通信部４０に送信させる。これにより、メールサーバ５ａは、予約取消情報を受信し、送信予約を取り消す。また、故障が発生していないと判定されたため、再びステップＳ２１へ戻り、加速度センサ１１を用いて落下状態の検出を続ける。

【0118】

このように、図９に示す処理によれば、落下が検出された後に、ユーザ端末１ａが地面などに衝突した場合であっても、ユーザ端末１ａが正常に動作している場合に、通知情報の送信予約を取り消すことができる。これにより、ユーザ端末１ａが実際には故障していない場合に、関係者への通知情報を行わないようにすることができるので、故障予測の頻度を維持しつつ、実際の故障の発生状況に応じて、適切な頻度で関係者に通知を行うことができる。

【0119】

また、落下の時間が長いほど落下時の衝撃が強くなり故障する可能性が高くなることが予想できるが、故障の可能性は床や地面の材質等によっても変わるため、故障と判定する閾値を適切に設定することが難しい面がある。図９に示す処理によれば、図５に示す処理と同様に、落下状態を検出するため、ユーザ端末１ａが故障する前に通知情報を送信する可能性を高めることができる。

【0120】

さらに、故障予測の閾値を低く（小さく）設定しても、故障予測後にユーザ端末１ａが正常動作をしていれば、関係者への通知は送信されない。そのため、閾値を低めに設定することで、故障時に通知情報を送信できないリスクを低減し、かつ、非故障時に必要のない通知情報を送信してしまうリスクを低減することができる。

【0121】

（加速度センサ１１以外のセンサにおける検出結果を用いる場合）
続いて、図１０を参照して、加速度センサ１１以外の検出結果を用いて故障予測を行う場合にユーザ端末１ａが行う処理を説明する。

【0122】

ステップＳ３１～Ｓ３５は、図６におけるステップＳ１１～Ｓ１５と同様であるので説明を省略する。ステップＳ３６において、送信制御部３７ａは、通知情報として故障予測通知３１０を作成して、電子メールの送信予約の設定を通信部４０に指示する。すなわち、送信制御部３７ａは、通信部４０を介して予約情報を送信する。送信制御部３７ａは、現在時刻からあらかじめ設定した所定時間経過後の日時を送信日時として設定する。例えば、所定時間を１０分とすればよいが、送信制御部３７ａは、送信日時がイベント日時よりも前になるように設定する。

【0123】

ステップＳ３７において、故障判定部３５は、送信制御部３７ａ及び通信部４０により予約情報が送信された後、あらかじめ設定した第１判定時間（例えば、１分）経過後に、ユーザ端末１ａに故障が発生したか否かを判定する。例えば、故障判定部３５は、ユーザ端末１ａの各機能が正常に動作しているか否かを判定する。なお、第１判定時間は、上記の送信日時を決定した所定時間（例えば、１０分）よりも短い時間に設定する。

【0124】

故障判定部３５において、ユーザ端末１ａが正常動作しており故障発生なしと判定された場合（Ｓ３７：故障なし）は、ステップＳ３８へ進む。故障判定部３５において故障が発生していると判定された場合（Ｓ３７：故障あり）は、処理終了となる。この場合、メールサーバ５ａは、設定された送信日時に通知情報を送信する。

【0125】

ユーザ端末１の故障により、ステップＳ３７の判定処理ができない場合（Ｓ３７：判定不可）も、故障が発生したと判定された場合と同様に処理は終了する。

【0126】

ステップＳ３８において、故障判定部３５は、ステップＳ３２において所定の範囲を超えた検出値の現在の検出値を取得し、現在の検出値が所定の範囲内となったか否かを判定する。故障判定部３５において所定の範囲内ではない、つまり所定の範囲外であると判定された場合（Ｓ３８：Ｎｏ）はステップＳ３９へ進む。故障判定部３５において所定の範囲内であると判定された場合（Ｓ３８：Ｙｅｓ）は、ステップＳ４０へ進む。

【0127】

ステップＳ３９において、送信制御部３７ａは、新しい送信日時での送信予約と、既存の送信予約の取消しと、を通信部４０へ指示する。ステップＳ３９においては、ユーザ端末１ａはまだ故障はしていない。しかしながら、この段階では、現在の検出値が所定の範囲外であるため、ユーザ端末１ａが故障する可能性が残されている。そのため、送信制御部３７ａは、送信予約における送信日時を更新するために、新しい送信日時を用いてメールサーバ５ａに対して送信予約を行う。また、送信制御部３７ａは、既存の送信予約の取消しを行う。

【0128】

ステップＳ４０において、送信制御部３７ａは、ユーザ端末１ａの故障の可能性が十分低くなったと判定して、送信予約の取消しを通信部４０に指示する。送信制御部３７ａは、送信予約を取り消すための予約取消情報をメールサーバ５ａに送信させる。再び処理スタートへ戻り、センサ部１０においてセンサ情報の検出を続ける。

【0129】

図１０に示す処理によれば、図６に示す処理と同様に、落下に限らず他の要因でユーザ端末１ａが故障する可能性が高い場合にも、通知情報を送信先に送信することができる。また、ユーザ端末１ａが故障していない場合の関係者への通知を軽減することができる。例えば、センサ部１０において、瞬間的に所定の範囲を超える温度を検出したが、すぐに温度が正常値に戻ったため故障が発生しなかった場合などに、ユーザ端末１ａは、不要な通知を関係者に対して送信せずに済む。また例えば、ユーザ端末１ａが故障していない状態であっても、センサ部１０において所定の範囲を超える温度が持続している場合には、継続的に予約情報を送信するため、実際にユーザ端末１ａが故障した場合に通知情報が送信されないリスクを低減できる。

【0130】

以上説明したように、本実施形態にかかる故障通知システム１００ａによれば、故障予測の閾値を低く設定しても、故障予測後に正常動作をしていれば、関係者に通知情報が送信されない。そのため、閾値を低めに設定することで、故障時に通知情報を送信できないリスクを低減し、かつ非故障時に通知情報を送信してしまうリスクを低減できる。すなわち、故障通知システム１００ａは、通知情報を精度よく、適切に送信することができる。

【0131】

＜実施形態３＞
続いて、実施形態３について説明する。実施形態１及び２では、ユーザ端末１又は１ａが、メールサーバ５又は５ａに対して通知情報を送信した。本実施形態にかかる故障通知システム１００ｂでは、ユーザ端末１又は１ａではなく、通知制御を行うための通知制御サーバ７が通知情報の送信を行う。

【0132】

（故障通知システム１００ｂの構成）
図１１は、本実施形態にかかる故障通知システム１００ｂの構成を示すブロック図である。故障通知システム１００ｂは、ユーザ端末１ｂ、関係者端末３、メールサーバ５ａ、及び通知制御サーバ７を備えている。通知制御サーバ７は、ネットワークＮを介して、ユーザ端末１ｂ及びメールサーバ５ａとの間でデータを送受信する。すなわち、通知制御サーバ７はユーザ端末１ｂ及びメールサーバ５ａとの間で通信可能である。

【0133】

故障通知システム１００ｂは、図１及び図７に示される故障通知システム１００及び１００ａの構成に加え、通知制御サーバ７を備えている。ユーザ端末１ｂは、図７に示されるユーザ端末１ａに対応するものである。以下では、故障通知システム１００及び１００ａと異なる点を中心に説明し、重複する点については適宜説明を省略する。

【0134】

（ユーザ端末１ｂの構成）
図１２は、ユーザ端末１ｂの構成を示すブロック図である。ユーザ端末１ｂは、図８に示されるユーザ端末１ａと概ね同様の構成を備えているが、一部の構成が異なる。

【0135】

本図に示されるように、記憶部２０ｂは、ユーザ端末１及び１ａの記憶部２０と異なり、イベント情報２１を記憶していなくともよい。

【0136】

制御部３０ｂは、センサ情報取得部３１、端末位置情報取得部３３、故障予測部３４、故障判定部３５、及び送信制御部３７ｂを備えている。制御部３０ｂは、例えば、ユーザ端末１ａの制御部３０ａが備えるイベント情報取得部３２及び特定部３６の構成を備えていない。

【0137】

制御部３０ｂの送信制御部３７ｂは、故障予測部３４においてユーザ端末１ｂの故障が予測された場合、ユーザ端末１ｂに故障の発生が予測される旨を通知するための故障予測情報を、通知制御サーバ７に送信する。故障予測情報は、例えば、予測される故障の内容やセンサ情報などを含み得る。

【0138】

また、送信制御部３７ｂは、故障判定部３５においてユーザ端末１ｂが故障していないと判定された場合、ユーザ端末１ｂが正常動作している旨を通知するための正常動作情報を通知制御サーバ７に送信する。

【0139】

さらに、送信制御部３７ｂは、故障判定部３５においてユーザ端末１ｂが故障していないと判定された場合であって、かつ、センサ情報が示す検出値が所定の範囲内ではない場合（所定の範囲外である場合）、故障予測更新情報を通知制御サーバ７に送信する。故障予測更新情報は、通知制御サーバ７において、通知情報を送信するか否かの判定を行うタイミングを延期するために用いられ得る。

【0140】

（通知制御サーバ７の構成）
続いて、図１３を参照して、通知制御サーバ７について説明する。図１３は、通知制御サーバ７の構成を示すブロック図である。通知制御サーバ７は、記憶部７２０、制御部７３０、及び通信部７４０を備えている。

【0141】

記憶部７２０は、各種のデータ及びプログラムを記憶する。特に、記憶部７２０は、イベント情報７２１を記憶する。イベント情報７２１は、図３に示されるイベント情報２１と同様のフォーマットを用いて表すことができる。なお、ここではイベント情報７２１を記憶部７２０に記憶する構成を用いて説明するが、イベント情報７２１は、通知制御サーバ７以外の装置に記憶されてもよい。例えば、クラウドコンピューティングシステムを利用する場合、クラウド上に記憶されたイベント情報７２１を、通知制御サーバ７が取得する構成としてもよい。

【0142】

制御部７３０は、ユーザ端末１ｂから受信した情報を用いて、通知情報の送信に関する処理を行う。制御部７３０は、ユーザ端末情報取得部７３１、イベント情報取得部７３２、特定部７３６、及び送信制御部７３７を備えている。

【0143】

ユーザ端末情報取得部７３１は、ユーザ端末１ｂから送信された情報を取得する。例えば、ユーザ端末情報取得部７３１は、ユーザ端末１ｂに故障発生が予測される旨の情報を含む故障予測情報を、ユーザ端末１ｂから取得する。なお、ユーザ端末情報取得部７３１は、端末情報取得部とも呼ばれる。

【0144】

なお、本実施形態では、故障の予測をユーザ端末１ｂにおいて行い、通知制御サーバ７は、ユーザ端末１ｂから故障予測情報を取得することで、ユーザ端末１ｂの故障に関する情報を取得しているが、これに限られない。例えば、通知制御サーバ７は、ユーザ端末１ｂの制御部３０ｂが備える故障予測部３４及び故障判定部３５の機能を備えるように構成されてもよい。この場合、ユーザ端末情報取得部７３１においてユーザ端末１ｂからセンサ情報を取得し、通知制御サーバ７は、当該センサ情報を用いて、故障の予測及び故障の判定を行ってもよい。

【0145】

また、ユーザ端末情報取得部７３１は、ユーザ端末１ｂが正常動作している旨を示す正常動作情報を取得する。また、ユーザ端末情報取得部７３１は、ユーザ端末１ｂが故障したと判定されていないが、センサ情報が示す検出値が所定の範囲内ではない場合、つまり検出値が所定の範囲外である場合に、故障予測更新情報を取得する。

【0146】

また、ユーザ端末情報取得部７３１は、正常動作情報及び故障予測更新情報以外に、ユーザ端末１ｂに関する様々な情報を取得してもよい。例えば、ユーザ端末情報取得部７３１は、ユーザ端末１ｂの位置を示す端末位置情報を、ユーザ端末１ｂから取得してもよい。

【0147】

また、例えば、ユーザ端末情報取得部７３１は、ユーザ端末１ｂを使用するユーザが予備端末を有しているか否かの情報を取得してもよい。具体的には、ユーザ端末情報取得部７３１は、イベント情報７２１にアクセスするユーザ端末１ｂを、端末あるいは端末で使用するブラウザ等のアプリに対応付けられた識別情報などに基づいて識別する。

【0148】

ユーザ端末情報取得部７３１は、イベント情報７２１にアクセスするユーザ端末１ｂの種類を判定することで、予備端末の有無を判定する。ユーザ端末１ｂを含む端末装置は、イベント情報７２１を作成する際、あるいはイベント情報７２１を参照（閲覧）する際に、イベント情報７２１にアクセスする。例えば、あるユーザＵ１が所定の使用期間（例えば、１週間以内）に、ユーザ端末１ｂ以外の端末を含む複数の端末でイベント情報７２１にアクセスしているとする。この場合、ユーザ端末情報取得部７３１は、ユーザＵ１が予備端末を有していると判定する。ユーザ端末情報取得部７３１は、イベント情報７２１において、ユーザＵ１に対応付けられたイベントの「予備端末の有無」の項目に「有」と設定する。すなわち、ユーザ端末情報取得部７３１は、イベント情報７２１が複数の端末装置によってアクセスされたか否かを示す情報、つまりイベント情報７２１がユーザ端末１ｂ以外の他の端末装置によってアクセスされたか否かを示す情報を取得し、それに応じて「予備端末の有無」の項目を設定してもよい。

【0149】

また、ユーザ端末情報取得部７３１は、端末又はアプリを識別する識別情報をもとに、端末の機種やＯＳ（Operating System）を判定し、機種やＯＳに関する所定の条件を満たす端末がユーザ端末１ｂ以外に存在する場合に、予備端末を「有」と設定してもよい。また、ユーザ端末情報取得部７３１は、ユーザＵ１の端末から位置情報を取得し、位置情報（場所）ごとにイベント情報７２１にアクセスする端末の種類を判定してもよい。あるいは端末に付与されたＩＰアドレス等から端末の位置（地域）を推定してもよい。そして、イベント場所におおよそ一致する場所や地域からユーザＵ１の複数の端末によってイベント情報７２１へのアクセスがなされている場合に、予備端末を「有」と設定してもよい。

【0150】

また、ユーザＵ１が所定の使用期間に１つのユーザ端末１ｂのみでイベント情報にアクセスしているとする。この場合、ユーザ端末情報取得部７３１は、ユーザＵ１が予備端末を有していないと判定し、イベント情報７２１の当該項目に「無」を設定する。

【0151】

このようにすることで、ユーザが予備端末の有無をイベント情報７２１に手動で登録することなく、ユーザ端末情報取得部７３１が自動的に当該内容を登録することができる。

【0152】

イベント情報取得部７３２は、上述したユーザ端末１及び１ａにおけるイベント情報取得部３２に対応する。イベント情報取得部７３２は、故障により影響を受ける可能性の高いイベントのイベント情報７２１を取得する。具体的には、故障予測がなされてから、所定の時間（例えば、２４時間）が経過するまでの対象期間に開催されるイベントを取得する。イベント情報取得部７３２は、少なくとも、イベントの日時と、イベントの関係者の連絡先と、が関連付けられたイベント情報７２１を取得する。

【0153】

特定部７３６は、上述したユーザ端末１及び１ａにおける特定部３６に対応する。特定部７３６は、故障予測情報が取得された場合、イベント情報取得部７３２が取得したイベント情報のうち、少なくとも１人の関係者が設定されているイベントを処理対象として抽出する。もちろん、上述したように、他の条件を用いてイベントを抽出してもよい。また、特定部７３６は、抽出したイベントの関係者の連絡先を、故障予測に関する通知情報の送信先として特定する。

【0154】

送信制御部７３７は、ユーザ端末情報取得部７３１で取得された情報に基づいて、通知情報の送信を制御する。

【0155】

例えば、ユーザ端末情報取得部７３１で故障予測情報が取得されたとする。送信制御部７３７は、正常動作情報が取得された場合、通知情報を送信しない。また、送信制御部７３７は、故障予測更新情報が取得された場合、通知情報を送信するか否かの判定を行うタイミングを延期する。そして、送信制御部７３７は、正常動作情報及び故障予測更新情報のいずれも取得されなかった場合、ユーザ端末１ｂが故障したと判定し、通知情報を作成する。送信制御部７３７は、作成した通知情報を送信するように、通信部７４０に指示する。上述したように、通知情報は、電子メールであってもよいし、ＳＭＳなどであってもよい。

【0156】

また、送信制御部７３７は、所定の条件が満たされた場合に、通知情報の送信予約を行うための予約情報、及び、送信予約を取り消すための予約取消情報をメールサーバ５ａに送信してもよい。

【0157】

通信部７４０は、ユーザ端末１ｂ、関係者端末３、及びメールサーバ５ａとの間で通信を行う。通信部７４０は、有線又は無線により通信を行うための通信インタフェースであってよい。通信部７４０は、送信制御部７３７から指示された宛先及び内容を含む通知情報を、メールサーバ５ａに対して送信する。

【0158】

（ユーザ端末１ｂの処理）
続いて、図１４及び図１５を参照して、ユーザ端末１ｂが行う処理を説明する。図１４は、加速度センサ１１の検出結果を用いて故障予測を行う場合に、ユーザ端末１ｂが行う処理を示すフローチャートである。図１５は、加速度センサ１１以外のセンサの検出結果を用いて故障予測を行う場合に、ユーザ端末１ｂが行う処理を示すフローチャートである。

【0159】

（加速度センサ１１における検出結果を用いる場合）
まず、図１４を参照して、加速度センサ１１の検出結果を用いて故障予測を行う場合にユーザ端末１ｂが行う処理を説明する。

【0160】

ステップＳ１０１及びステップＳ１０２は、図５のステップＳ１及びＳ２と同様であるので説明を省略する。

【0161】

ステップＳ１０３において、送信制御部３７ｂは、ユーザ端末１ｂに故障の発生が予測される旨を通知するための故障予測情報を、通知制御サーバ７に送信するように、通信部４０へ指示する。故障予測情報は、例えば、予測される故障の内容やセンサ情報などを含み得る。例えば、故障予測情報は、ユーザ端末１ｂの長時間の落下が検出されたことなどの情報を含んでよい。通信部４０は、送信制御部３７ｂの指示に従い、故障予測情報を通知制御サーバ７へ通知する。

【0162】

ステップＳ１０４において、故障判定部３５は、落下の検出終了時において（落下の終了が検出された後に）、実際にユーザ端末１ｂの故障が発生したか否かを判定する。故障判定部３５は、例えば、ユーザ端末１ｂが備える各機能が正常に動作しているか否かを判定する。

【0163】

故障判定部３５において、各機能が正常動作しており、故障が発生していないと判定された場合（Ｓ１０４：故障なし）、ステップＳ１０５へ進む。また、故障判定部３５において、各機能が正常動作しておらず、故障が発生していると判定された場合（Ｓ１０４：故障あり）は、処理を終了する。この場合、後述するように、メールサーバ５ａは、設定した送信日時に故障予測通知３１０を送信先に送信する。また、ユーザ端末１ｂが故障したことにより、故障判定部３５において故障の判定ができない場合（Ｓ１０４：判定不可）も、故障が発生したと判定された場合と同様に、処理を終了する。

【0164】

ステップＳ１０５において、送信制御部３７ｂは、ユーザ端末１ｂが正常動作していることを示す正常動作情報を、通知制御サーバ７へ送信するように通信部４０へ指示する。通信部４０は、正常動作情報を通知制御サーバ７へ送信する。ステップＳ１０５からはステップＳ１０１に戻り、繰り返し処理を続ける。

【0165】

（加速度センサ１１以外のセンサにおける検出結果を用いる場合）
続いて、図１５を参照して、加速度センサ１１以外の検出結果を用いて故障予測を行う場合にユーザ端末１ｂが行う処理を説明する。

【0166】

ステップＳ１１１及びＳ１１２は、図６におけるステップＳ１１及びステップＳ１２と同様であるので説明を省略する。ステップＳ１１３において、送信制御部３７ｂは、検出した故障予測情報を通知制御サーバ７へ送信するように、通信部４０へ指示する。故障予測情報は、例えば、ユーザ端末１ｂ周辺の強い磁気、高温度、低温度、高湿度、低湿度、高圧力、又はユーザ端末１ｂに加えられた強い衝撃などの情報を含み得る。通信部４０は、故障予測情報を通知制御サーバ７へ送信する。

【0167】

ステップＳ１１４において、故障判定部３５は、故障予測情報を送信してから、あらかじめ設定した第１判定時間が経過した後に、ユーザ端末１ｂに実際に故障が発生したか否かを判定する。第１判定時間は、例えば、１分間を用いればよい。故障判定部３５は、例えば、ユーザ端末１ｂの各機能が正常に動作しているか否かを判定する。

【0168】

故障判定部３５において、各機能が正常動作しており、故障が発生していないと判定された場合（Ｓ１１４：故障なし）、ステップＳ１１５へ進む。また、故障判定部３５において、各機能が正常動作しておらず、故障が発生していると判定された場合（Ｓ１１４：故障あり）は、処理を終了する。

【0169】

また、ユーザ端末１ｂが故障したことにより、故障判定部３５において故障の判定ができない場合（Ｓ１１４：判定不可）も、故障が発生したと判定された場合と同様に、処理を終了する。

【0170】

ステップＳ１１５において、故障判定部３５は、ステップＳ１１２において所定の範囲を超えた検出値について、現在の検出値を取得して、現在の検出値が所定の範囲内であるか否かを判定する。現在の検出値が所定の範囲外である場合（Ｓ１１５：Ｎｏ）はステップＳ１１６へ進む。所定の範囲内である場合（Ｓ１１５：Ｙｅｓ）は、ステップＳ１１７へ進む。

【0171】

ステップＳ１１６において、センサ部１０における検出値は所定の範囲外の状態である。従って、ユーザ端末１ｂは、まだ故障はしていないものの、故障の可能性が残されている。そのため、送信制御部３７ｂは、故障予測通知を関係者に送信するか否かの判定を行うタイミングを延期するために、故障予測更新情報を通知制御サーバ７に送信する。その後、処理はステップＳ１１４へ戻る。

【0172】

ステップＳ１１７において、送信制御部３７ｂは、故障の可能性が十分低くなったと判定して、正常動作情報を通知制御サーバ７に送信する。再び処理スタートへ戻り、センサ部１０での検出を続ける。

【0173】

（通知制御サーバ７の処理）
続いて、図１６を参照して、本実施形態にかかる通知制御サーバ７が行う処理を説明する。図１６は、通知制御サーバ７が行う処理を示すフローチャートである。

【0174】

ステップＳ１２１において、ユーザ端末情報取得部７３１は、クライアントであるユーザ端末１ｂからの故障予測情報を受信したか否かを判定する。故障予測情報を受信した場合（Ｓ１２１：Ｙｅｓ）、ステップＳ１２２へ進む。故障予測情報を受信していない場合（Ｓ１２１：Ｎｏ）は、ステップＳ１２１の処理を繰り返す。これにより、ユーザ端末情報取得部７３１は、ユーザ端末１ｂから故障予測情報が送信されるのを待つ。

【0175】

ステップＳ１２２において、送信制御部７３７は、あらかじめ設定された第２判定時間だけ待機したのち、第２判定時間以内に、ユーザ端末１ｂから受信した情報があるか否かを判定する。ここで、第２判定時間は、上述した第１判定時間と同じであってもよいし、異なる時間であってもよい。この第２判定時間は、第１判定時間以上であることが好ましい。

【0176】

送信制御部７３７は、正常動作情報を受信したか、故障予測更新情報を受信したか、又は、何も受信していないか、に応じて異なる処理を行う。正常動作情報を受信した場合（Ｓ１２２：正常動作情報）は、処理終了となる。故障予測更新情報を受信した場合（Ｓ１２２：故障予測更新情報）、送信制御部７３７は、再び同じ第２判定時間の経過を待つために、Ｓ１２２を繰り返す。

【0177】

第２判定時間以内に、正常動作情報及び故障予測更新情報のいずれも受信しなかった場合（Ｓ１２２：なし）、送信制御部７３７は、ユーザ端末１ｂに故障が発生している可能性があると判定し、ステップＳ１２３へ進む。

【0178】

ステップＳ１２３において、イベント情報取得部７３２は、記憶部７２０から、故障により影響を受ける可能性の高いイベントのイベント情報７２１を取得する。具体的には、イベント情報取得部７３２は、記憶部７２０から、あらかじめ設定された所定期間以内のイベント情報７２１を取得する。所定期間は、実施形態１及び２における対象期間と同様に、例えば、２４時間を用いればよい。

【0179】

ステップＳ１２４において、特定部７３６は、図５におけるステップＳ４と同様にして、処理対象のイベントを抽出（特定）する。特定部７３６は、ステップＳ１２３において取得されたイベント情報のうち、少なくとも１人の関係者が設定されているイベントを処理対象とする。なお上述したように、「関係者が設定されている」という条件の他に、さらに別の条件を加えて処理対象のイベントを抽出してもよい。

【0180】

ステップＳ１２５において、特定部７３６は、ステップＳ１２４で抽出したイベントの関係者の連絡先を通知情報の送信先として特定する。ステップＳ１２６において、送信制御部７３７は、図４に示される故障予測通知３１０のような電子メールを通知情報として作成し、送信先へ送信するように、通信部７４０へ指示する。送信先が複数設定されている場合、送信制御部７３７は、複数の通知を行うように指示する。

【0181】

通信部７４０は、送信制御部７３７からの指示に従い、故障予測通知３１０をメールサーバ５ａに送信する。これにより、メールサーバ５ａは、故障予測通知３１０を関係者端末３に送信する。また、ステップＳ１２４において抽出されたイベントが複数ある場合、送信制御部７３７は、そのイベントごとに通知を行う。通知制御サーバ７は、図１６に示す処理を繰り返し実行する。

【0182】

なお、ステップＳ１２６では、実施形態１及び２と同様に、イベント種別、場所、予備端末の有無の情報を、故障予測通知３１０を送信するか否かの判定に加えてもよい。

【0183】

このように、ユーザ端末１ｂのセンサ部１０において所定の範囲を超える値が検出された後、ユーザ端末１ｂは、イベント情報の取得及び通知情報の作成処理を行うことなく、通知制御サーバ７へ故障予測情報を送信する。これにより、実施形態１及び２よりも短い時間でユーザ端末１ｂ内での処理を完了することができる。このようにすることで、ユーザ端末１ｂの故障を予測した直後に、実際に故障が発生することで通知情報の送信処理までを完了できないというリスクを軽減することができる。

【0184】

なお、実施形態２と同様に、通知制御サーバ７は、メールサーバ５ａが備える電子メールの予約機能を用いてもよい。

【0185】

図１７を参照して、電子メールの予約機能を用いた場合における通知制御サーバ７の処理を説明する。図１７は、電子メールの予約機能を用いた場合における通知制御サーバ７が行う処理を示すフローチャートである。

【0186】

ステップＳ１３１は、図１６におけるステップＳ１２１と同様である。ユーザ端末情報取得部７３１は、ユーザ端末１ｂからの故障予測情報を受信したか否かを判定する。故障予測情報を受信した場合（Ｓ１３１：Ｙｅｓ）は、ステップＳ１３２へ進む。故障予測情報を受信していない場合（Ｓ１３１：Ｎｏ）は、ステップＳ１３１の処理を繰り返す。これにより、ユーザ端末情報取得部７３１は、ユーザ端末１ｂから故障予測情報が送信されるのを待つ。

【0187】

ステップＳ１３２において、イベント情報取得部７３２は、記憶部７２０から、故障により影響を受ける可能性の高いイベントのイベント情報７２１を取得する。ステップＳ１３３において、特定部７３６は、処理対象のイベントを抽出（特定）する。ステップＳ１３２及びＳ１３３は、図１６におけるステップＳ１２３及びＳ１２４と同様のため、詳細を省略する。

【0188】

ステップＳ１３４において、特定部７３６は、ステップＳ１３３で抽出したイベントの関係者の連絡先を、故障予測に関する通知情報の送信先として特定する。ステップＳ１３５において、送信制御部７３７は、図９におけるステップＳ２６と同様に、故障予測通知３１０を通知情報として作成し、通信部７４０へ電子メールの送信予約の設定を指示する。

【0189】

ステップＳ１３６において、送信制御部７３７は、あらかじめ設定された第２判定時間だけ待機したのち、第２判定時間以内に、ユーザ端末１ｂから受信した情報があるか否かを判定する。送信制御部７３７は、ユーザ端末１ｂから正常動作情報を受信したか、故障予測更新情報を受信したか、又は何も受信していないか、を判定する。

【0190】

正常動作情報を受信した場合（Ｓ１３６：正常動作情報）は、ステップＳ１３７へ進む。故障予測更新情報を受信した場合（Ｓ１３６：故障予測更新情報）は、再び同じ所定時間経過を待つためにＳ１３６を繰り返す。

【0191】

第２判定時間以内に、正常動作情報及び故障予測更新情報のいずれも受信しなかった場合（Ｓ１３６：なし）は、処理を終了する。この場合、メールサーバ５ａは、予約された送信日時になると、通知情報を送信する。ステップＳ１３７において、送信制御部７３７は、送信予約の取消しを通信部７４０に指示する。これにより、メールサーバ５ａは通知情報を送信しない。

【0192】

以上説明したように、本実施形態にかかる故障通知システム１００ｂでは、通知制御サーバ７でイベント情報の取得及び通知情報の作成処理を行うことにより、ユーザ端末１ｂが行う処理にかかる時間を短縮することができる。これにより、必要な処理を完了する前にユーザ端末１ｂが故障して、イベントの関係者に通知情報を送信できないリスクを低減することができる。

【0193】

また、ユーザ端末１ｂが故障していないと判定された場合、ユーザ端末１ｂは、通知制御サーバ７に正常動作情報を送信する。通知制御サーバ７は、正常動作情報を受信して、これに基づいて通知情報の送信を制御する。例えば、通知制御サーバ７は、ユーザ端末１ｂから正常動作情報を受信した場合、メールサーバ５ａに対して行った通知情報の送信予約を取り消すことができる。これにより、ユーザ端末１ｂが故障していないにも関わらず、関係者に通知情報が送信されるという誤動作のリスクを低減することができる。

【0194】

上述したユーザ端末１、１ａ、１ｂ、関係者端末３、メールサーバ５、５ａ、及び通知制御サーバ７の各機能構成部は、各機能構成部を実現するハードウエア（例：ハードワイヤードされた電子回路など）で実現されてもよいし、ハードウエアとソフトウエアとの組み合わせ（例：電子回路とそれを制御するプログラムの組み合わせなど）で実現されてもよい。例えば、本開示は、任意の処理を、ＣＰＵにコンピュータプログラムを実行させることにより実現することも可能である。

【0195】

プログラムは、コンピュータに読み込まれた場合に、実施形態で説明された１又はそれ以上の機能をコンピュータに行わせるための命令群（又はソフトウェアコード）を含む。プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）又は実体のある記憶媒体（tangible storage medium）に格納されてもよい。限定ではなく例として、非一時的なコンピュータ可読媒体又は実体のある記憶媒体は、random-access memory（RAM）、read-only memory（ROM）、フラッシュメモリ、solid-state drive（SSD）又はその他のメモリ技術、CD-ROM、digital versatile disc（DVD）、Blu-ray（登録商標）ディスク又はその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又はその他の磁気ストレージデバイスを含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）又は通信媒体上で送信されてもよい。限定ではなく例として、一時的なコンピュータ可読媒体又は通信媒体は、電気的、光学的、音響的、又はその他の形式の伝搬信号を含む。

【0196】

なお、本開示は上記実施形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、上述した実施形態は任意に組み合わせて実行可能である。

【符号の説明】

【0197】

１、１ａ、１ｂ ユーザ端末
３ 関係者端末
５、５ａ メールサーバ
７ 通知制御サーバ
１０ センサ部
１１ 加速度センサ
１２ 磁気センサ
１３ 温度・湿度センサ
１４ 圧力センサ
２０、２０ｂ 記憶部
２１ イベント情報
３０、３０ａ、３０ｂ 制御部
３１ センサ情報取得部
３２ イベント情報取得部
３３ 端末位置情報取得部
３４ 故障予測部
３５ 故障判定部
３６ 特定部
３７、３７ａ、３７ｂ 送信制御部
４０ 通信部
５０ 位置検出部
１００、１００ａ、１００ｂ 故障通知システム
２１１ イベント日時
２１２ イベント種別
２１３ イベント名
２１４ イベント場所
２１５ 第１関係者
２１６ 第１連絡先
２１７ 第２関係者
２１８ 第２連絡先
２１９ 予備端末の有無
２２０ 予備連絡先
３１０ 故障予測通知
３１１ タイトル
３１２ 通知文
３１３ 故障予測日時
３１４ 故障予測内容
３１５ 予測場所位置情報
３１６ 予測場所地図情報
３１７ イベント種別
３１８ イベント名
３１９ イベント場所
３２０ 予備端末の有無
３２１ 予備連絡先
７２０ 記憶部
７２１ イベント情報
７３０ 制御部
７３１ ユーザ端末情報取得部
７３２ イベント情報取得部
７３６ 特定部
７３７ 送信制御部
７４０ 通信部
Ｎ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】