(57)【要約】【課題】複数の安否確認対象者の安否情報を受信する装置の負荷を軽減することを課題とする。【解決手段】本発明は、クライアント端末１の１つ又は複数のアプリケーション部１０各々が、災害に関するイベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始し、操作履歴に基づき決定したユーザ状況を示す状況情報を、自アプリケーションと連携するサーバ２に送信する。各サーバ２は、受信した状況情報を安否確認システム３に送信する。安否確認システム３は、受信した状況情報に基づき、複数の安否確認対象者各々の安否情報を管理する。【選択図】図１
2020149295.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末のコンピュータを、
災害に関するイベントを検知する検知手段、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集手段、及び、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信手段、
として機能させるプログラム。
【請求項２】
請求項１に記載のプログラムにおいて、
前記クライアント送信手段は、前記操作履歴に基づき前記状況情報を生成し、生成した前記状況情報を前記サーバに送信するプログラム。
【請求項３】
請求項２に記載のプログラムにおいて、
前記収集手段は、予め定められた所定の終了タイミングになるまで前記収集処理を継続し、
前記クライアント送信手段は、前記収集処理が継続している間、繰り返し到来する所定の判断タイミングで、それまでに収集された前記操作履歴に基づき、前記状況情報を生成するプログラム。
【請求項４】
請求項３に記載のプログラムにおいて、
前記収集手段は、前記状況情報の内容が予め定められた終了条件を満たすと、前記収集処理を終了するプログラム。
【請求項５】
請求項３に記載のプログラムにおいて、
前記収集手段は、前記収集処理を開始してから所定時間経過すると、前記収集処理を終了するプログラム。
【請求項６】
請求項３から５のいずれか１項に記載のプログラムにおいて、
前記クライアント送信手段は、前記判断タイミングで生成した前記状況情報のうち、送信条件を満たす前記状況情報を、前記サーバに送信するプログラム。
【請求項７】
災害に関するイベントを検知する検知手段と、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集手段と、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信手段と、
を有するクライアント端末。
【請求項８】
クライアント端末のコンピュータが、
災害に関するイベントを検知する検知工程と、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集工程と、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信工程と、
を実行する処理方法。
【請求項９】
サーバのコンピュータを、
クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得手段、及び、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信手段、
として機能させるプログラム。
【請求項１０】
請求項９に記載のプログラムにおいて、
前記サーバ送信手段は、前記操作履歴に基づき前記状況情報を生成し、生成した前記状況情報を前記安否確認システムに送信するプログラム。
【請求項１１】
クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得手段と、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信手段と、
を有するサーバ。
【請求項１２】
サーバのコンピュータが、
クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得工程と、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信工程と、
を実行する処理方法。
【請求項１３】
クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得手段と、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録手段と、
を有する安否確認システム。
【請求項１４】
請求項１３に記載の安否確認システムにおいて、
前記登録手段は、前記操作履歴に基づき前記状況情報を生成し、生成した前記状況情報を登録する安否確認システム。
【請求項１５】
請求項１３又は１４に記載の安否確認システムにおいて、
前記安否確認システム取得手段は、互いに異なるアプリケーションと連携している複数の前記サーバ各々から、前記操作履歴及び前記状況情報の少なくとも一方を取得する安否確認システム。
【請求項１６】
コンピュータが、
クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得工程と、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録工程と、
を実行する処理方法。
【請求項１７】
コンピュータを、
クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得手段、及び、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録手段、
として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント端末、業務サーバ、安否確認システム、処理方法及びプログラムに関する。
【背景技術】
【０００２】
特許文献１は、携帯端末とセンタ装置とを有するシステムを開示している。携帯端末は、緊急地震速報を受信すると利用者に報知し、所定時間の間、利用者からの入力操作を待ち受け、利用者からの入力操作があった場合には安否確認信号をセンタ装置に送信する。センタ装置は、携帯端末から受信した安否確認信号に基づき、利用者の安否状態を管理する。
【０００３】
特許文献２は、携帯端末に対して所定操作がなされたことを検出する手段と、所定時間内に所定操作がなされたことが検出されると、当該所定時間経過後に他の装置に対してその旨を示す通知メールを送信する手段と、を備える携帯端末を開示している。
【０００４】
特許文献３は、無線送受信機能を備えた携帯電話機本体と、ユーザによるキー入力操作を検出する手段と、最後のキー入力操作の検出時から所定時間経過したことを検知した場合に、携帯電話機本体の備える無線送受信機能を用いて異常通知メッセージを所定の宛先に送信する手段とを備える監視装置を開示している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−８６１５６号公報
【特許文献２】特開２００８−９８７４４号公報
【特許文献３】特開２００４−２８２１６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１乃至３に開示の技術はいずれも、安否確認対象者の安否情報を、安否確認対象者が所有する端末から直接、利用者の安否状態を管理するセンタ装置や、監視者のメールアドレス等に送信している。このような構成の場合、安否情報を受信する装置は、安否確認対象者の数と同数の端末から安否情報を受信することとなる。安否情報の送受信は災害等の発生直後に集中するため、多数の端末からランダムに安否情報が送信された場合、安否情報を受信する装置の負荷が大きくなる。
【０００７】
本発明は、複数の安否確認対象者の安否情報を受信する装置の負荷を軽減することを課題とする。
【課題を解決するための手段】
【０００８】
本発明によれば、
クライアント端末のコンピュータを、
災害に関するイベントを検知する検知手段、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集手段、及び、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信手段、
として機能させるプログラムが提供される。
【０００９】
また、本発明よれば、
災害に関するイベントを検知する検知手段と、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集手段と、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信手段と、
を有するクライアント端末が提供される。
【００１０】
また、本発明によれば、
クライアント端末のコンピュータが、
災害に関するイベントを検知する検知工程と、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集工程と、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信工程と、
を実行する処理方法が提供される。
【００１１】
また、本発明によれば、
サーバのコンピュータを、
クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得手段、及び、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信手段、
として機能させるプログラムが提供される。
【００１２】
また、本発明によれば、
クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得手段と、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信手段と、
を有するサーバが提供される。
【００１３】
また、本発明によれば、
サーバのコンピュータが、
クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得工程と、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信工程と、
を実行する処理方法が提供される。
【００１４】
また、本発明によれば、
クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得手段と、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録手段と、
を有する安否確認システムが提供される。
【００１５】
また、本発明によれば、
コンピュータが、
クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得工程と、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録工程と、
を実行する処理方法が提供される。
【００１６】
また、本発明によれば、
コンピュータを、
クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得手段、及び、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録手段、
として機能させるプログラムが提供される。
【発明の効果】
【００１７】
本発明によれば、複数の安否確認対象者の安否情報を受信する装置の負荷を軽減することができる。
【図面の簡単な説明】
【００１８】
【図１】本実施形態の処理システムの全体像を示す機能ブロック図の一例である。
【図２】本実施形態のクライアント端末、サーバ及び安否確認システムのハードウエア構成の一例を示す図である。
【図３】本実施形態のクライアント端末の機能ブロック図の一例である。
【図４】本実施形態の処理システムが処理する情報の一例を模式的に示す図である。
【図５】本実施形態のサーバの機能ブロック図の一例である。
【図６】本実施形態の安否確認システムの機能ブロック図の一例である。
【図７】本実施形態の処理システムが処理する情報の一例を模式的に示す図である。
【図８】本実施形態の処理システムの処理の流れの一例を示すシーケンス図である。
【図９】本実施形態のクライアント端末の処理の流れの一例を示すフローチャートである。
【図１０】本実施形態のクライアント端末の処理の流れの一例を示すフローチャートである。
【発明を実施するための形態】
【００１９】
＜第１の実施形態＞
まず、図１を用いて、本実施形態の処理システムの全体像及び概要を説明する。図示するように、処理システムは、クライアント端末１と、サーバ２と、安否確認システム３とを有する。これらはインターネット等の通信ネットワークを介して、互いに通信可能になっている。
【００２０】
クライアント端末１は、安否確認対象者に所持され、安否確認者によって利用される。クライアント端末１は、スマートフォン、タブレット端末、ＰＣ（personal computer）、携帯電話、スマートウォッチ等が例示されるが、これらに限定されない。クライアント端末１には、１つ又は複数のアプリケーション（プログラム）がインストールされ、１つ又は複数のアプリケーション部１０が実現される。アプリケーションは、サーバと連携して所定の機能を提供する。例えば、アプリケーションは、電子メールアプリ、電話アプリ、テレビ会議アプリ、スケジュール管理アプリ、施設予約アプリ、ゲームアプリ、チャットアプリ等であるが、これらに限定されない。
【００２１】
なお、図では１つのクライアント端末１が示されているが、処理システムは複数のクライアント端末１を有することができる。複数のクライアント端末１各々は、複数の安否確認対象者各々に所持され、各々によって利用される。
【００２２】
１つ又は複数のアプリケーション部１０各々は、電子メール、電話、テレビ会議、スケジュール管理、施設予約、ゲーム、チャット等に関する主たる機能に加えて、次の付加的機能を有する。具体的には、各アプリケーション部１０は、災害に関するイベントを検知する機能、当該イベントの検知に応じて、自アプリケーションの操作履歴を収集する収集処理を開始する機能、及び、当該操作履歴、及び、当該記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、自アプリケーションと連携するサーバ２に送信する機能を有する。これら付加的機能は、予め各アプリケーションに備えられた機能であってもよいし、プラグイン（プログラム）等で拡張された機能であってもよい。
【００２３】
サーバ２は、クライアント端末１にインストールされたアプリケーションと連携して、所定の機能を提供する。複数のサーバ２は、互いに異なるアプリケーションと連携している。処理システムは、１つ又は複数のサーバ２を有することができる。例えば、サーバ２は、電子メールサーバ、電話サーバ、テレビ会議サーバ、スケジュール管理サーバ、施設予約サーバ、ゲームサーバ、チャットサーバ等であるが、これらに限定されない。
【００２４】
サーバ２は、電子メール、電話、テレビ会議、スケジュール管理、施設予約、ゲーム、チャット等に関する主たる機能に加えて、次の付加的機能を有する。具体的には、サーバ２は、各クライアント端末１から上記操作履歴及び上記状況情報の少なくとも一方を受信すると、受信した情報を安否確認システム３に送信する。当該付加的機能は、予め各サーバ２に備えられた機能であってもよいし、プラグイン等で拡張された機能であってもよい。
【００２５】
安否確認システム３は、複数の安否確認対象者各々に対応付けて、各々の安否を示す状況情報を管理する。安否確認システム３は、サーバ２から受信した上記操作履歴及び上記状況情報の少なくとも一方に基づき、管理している状況情報を更新する。
【００２６】
次に、処理システムの構成を詳細に説明する。まず、クライアント端末１、サーバ２及び安否確認システム３のハードウエア構成の一例について説明する。クライアント端末１、サーバ２及び安否確認システム３が備える各機能部は、任意のコンピュータのＣＰＵ（Central Processing Unit）、メモリ、メモリにロードされるプログラム、そのプログラムを格納するハードディスク等の記憶ユニット（あらかじめ装置を出荷する段階から格納されているプログラムのほか、ＣＤ（Compact Disc）等の記憶媒体やインターネット上のサーバ等からダウンロードされたプログラムをも格納できる）、ネットワーク接続用インターフェイスを中心にハードウエアとソフトウエアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。
【００２７】
図２は、クライアント端末１、サーバ２及び安否確認システム３各々のハードウエア構成を例示するブロック図である。図２に示すように、クライアント端末１、サーバ２及び安否確認システム３各々は、プロセッサ１Ａ、メモリ２Ａ、入出力インターフェイス３Ａ、周辺回路４Ａ、バス５Ａを有する。周辺回路４Ａには、様々なモジュールが含まれる。クライアント端末１、サーバ２及び安否確認システム３の少なくとも１つは周辺回路４Ａを有さなくてもよい。なお、クライアント端末１、サーバ２及び安否確認システム３の少なくとも１つは物理的及び／又は論理的に分かれた複数の装置で構成されてもよいし、物理的及び／又は論理的に一体となった１つの装置で構成されてもよい。クライアント端末１、サーバ２及び安否確認システム３のいずれかが物理的及び／又は論理的に分かれた複数の装置で構成される場合、複数の装置各々が上記ハードウエア構成を備えることができる。
【００２８】
バス５Ａは、プロセッサ１Ａ、メモリ２Ａ、周辺回路４Ａ及び入出力インターフェイス３Ａが相互にデータを送受信するためのデータ伝送路である。プロセッサ１Ａは、例えばＣＰＵ、ＧＰＵ（Graphics Processing Unit）などの演算処理装置である。メモリ２Ａは、例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などのメモリである。入出力インターフェイス３Ａは、入力装置、外部装置、外部サーバ、外部センサー、カメラ等から情報を取得するためのインターフェイスや、出力装置、外部装置、外部サーバ等に情報を出力するためのインターフェイスなどを含む。入力装置は、例えばキーボード、マウス、マイク、物理ボタン、タッチパネル等である。出力装置は、例えばディスプレイ、スピーカ、プリンター、メーラ等である。プロセッサ１Ａは、各モジュールに指令を出し、それらの演算結果をもとに演算を行うことができる。
【００２９】
次に、クライアント端末１の機能構成を説明する。図３に、クライアント端末１の機能ブロック図の一例を示す。図示するように、クライアント端末１には、１つ又は複数のアプリケーションがインストールされ、１つ又は複数のアプリケーション部１０が実現される。図ではＮ個のアプリケーション部１０（第１〜第Ｎのアプリケーション部１０−１〜１０−Ｎ）が示されている。なお、Ｎは１以上の整数である。
【００３０】
アプリケーションは、サーバと連携して所定の機能を提供する。例えば、アプリケーションは、電子メールアプリ、電話アプリ、テレビ会議アプリ、スケジュール管理アプリ、施設予約アプリ、ゲームアプリ、チャットアプリ等であるが、これらに限定されない。
【００３１】
各アプリケーション部１０は、主機能部１１と、検知部１２と、収集部１３と、クライアント送信部１４とを有する。主機能部１１は各アプリケーションの主たる機能を実現する機能部であり、検知部１２、収集部１３及びクライアント送信部１４は、安否確認に関する機能（上述した付加的機能）を実現する機能部である。検知部１２、収集部１３及びクライアント送信部１４は、予め各アプリケーションに備えられた機能であってもよいし、プラグイン等で拡張された機能であってもよい。以下、各機能部を詳細に説明する。
【００３２】
主機能部１１は、各アプリケーションの主たる機能を実現する。主機能部１１が実現する機能は、アプリケーションの内容に応じて定まる。以下、一例を説明するがこれらに限定されない。
【００３３】
電子メールアプリをインストールすることで実現されたアプリケーション部１０の主機能部１１は、例えば、電子メールの送受信、電子メールの閲覧、電子メールの作成、送受信した電子メールの管理等の機能を実現する。また、電話アプリをインストールすることで実現されたアプリケーション部１０の主機能部１１は、例えば、通話、通話履歴の管理、通話相手の連絡先の管理等の機能を実現する。
【００３４】
また、テレビ会議アプリをインストールすることで実現されたアプリケーション部１０の主機能部１１は、例えば、テレビ会議、通話履歴の管理、通話相手の連絡先の管理等の機能を実現する。また、スケジュール管理アプリをインストールすることで実現されたアプリケーション部１０の主機能部１１は、例えば、スケジュールの管理、登録しているスケジュールの閲覧、スケジュールの編集等の機能を実現する。
【００３５】
また、施設予約アプリをインストールすることで実現されたアプリケーション部１０の主機能部１１は、例えば、会議室やスポーツ施設等の予約、予約状況の閲覧等の機能を実現する。ゲームアプリをインストールすることで実現されたアプリケーション部１０の主機能部１１は、例えば、ゲームプレイ等の機能を実現する。チャットアプリをインストールすることで実現されたアプリケーション部１０の主機能部１１は、例えば、チャット等の機能を実現する。
【００３６】
検知部１２は、災害に関するイベントを検知する。例えば、クライアント端末１は、所定のサーバから、地震、台風、ハリケーン、噴火、大雨、大雪等の災害を引き起こし得る自然現象の発生又は発生予告の通知を、インターネット等のネットワークを介して取得する通知取得部を備えていてもよい。そして、検知部１２は、「当該通知取得部が自然現象の発生又は発生予告の通知を取得するイベント」を検知してもよい。
【００３７】
その他、検知部１２は、「当該通知取得部が、所定地域における自然現象の発生又は発生予告の通知を取得するイベント」を検知してもよい。所定地域は、予め登録されている地域であってもよいし、クライアント端末１の現在位置を含む地域（例：現在位置から所定の距離以内の地域）であってもよい。この場合、通知取得部が取得する通知には、自然現象の発生位置又は発生予告位置等の位置情報が含まれる。そして、検知部１２は、当該位置情報に基づき、上記イベントの発生の有無を判断する。
【００３８】
その他、検知部１２は、「当該通知取得部が、所定レベル以上の自然現象の発生又は発生予告の通知を取得するイベント」を検知してもよい。所定レベルは、震度、マグニチュード、最大風速、降水量、降雪量等の任意の指標で示される。この場合、通知取得部が取得する通知には、発生した自然現象の上記指標、又は、上記指標の予告等の指標情報が含まれる。そして、検知部１２は、当該指標情報に基づき、上記イベントの発生の有無を判断する。
【００３９】
その他、検知部１２は、「当該通知取得部が、所定地域における所定レベル以上の自然現象の発生又は発生予告の通知を取得するイベント」を検知してもよい。検知部１２は、上述した例と同様にして、当該イベントの検知を実現することができる。
【００４０】
その他、クライアント端末１は、自然現象の発生を示すユーザ入力を受付ける入力受付部を有してもよい。そして、検知部１２は、「当該入力受付部が、自然現象の発生を示すユーザ入力を受付けるイベント」を検知してもよい。
【００４１】
なお、本明細書において、「取得」とは、ユーザ入力に基づき、又は、プログラムの指示に基づき、「自装置が他の装置や記憶媒体に格納されているデータを取りに行くこと（能動的な取得）」、たとえば、他の装置にリクエストまたは問い合わせして受信すること、他の装置や記憶媒体にアクセスして読み出すこと等、および、ユーザ入力に基づき、又は、プログラムの指示に基づき、「自装置に他の装置から出力されるデータを入力すること（受動的な取得）」、たとえば、配信（または、送信、プッシュ通知等）されるデータを受信すること、また、受信したデータまたは情報の中から選択して取得すること、及び、「データを編集（テキスト化、データの並び替え、一部データの抽出、ファイル形式の変更等）などして新たなデータを生成し、当該新たなデータを取得すること」の少なくともいずれか一方を含む。
【００４２】
収集部１３は、検知部１２によるイベントの検知に応じて、自アプリケーションの操作履歴を収集する収集処理を開始する。収集部１３は、収集した操作履歴をクライアント端末１の記憶装置内に記憶させる。図４に、収集部１３が収集した操作履歴の一例を模式的に示す。図示する操作履歴の例では、操作が検知された日時が記録されている。操作は、各アプリケーションで検出可能なあらゆる操作を含み、アプリケーションを立ち上げる操作、アプリケーション内のいずれかの機能を実行させる操作等が例示される。
【００４３】
クライアント送信部１４は、収集部１３が取集した操作履歴、及び、当該操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、ユーザ識別情報に対応付けて、自アプリケーションと連携するサーバ２に送信する。当該ユーザ識別情報は、各アプリケーションのユーザを識別する情報であり、例えばログイン時に入力される情報とすることができる。なお、本実施形態では、クライアント送信部１４は、収集部１３が取集した操作履歴に基づき状況情報を生成し、生成した状況情報をサーバ２に送信する。クライアント送信部１４が操作履歴をサーバ２に送信する実施形態は、以下で説明する。
【００４４】
ここで、操作履歴に基づき状況情報を生成する処理の一例を説明する。例えば、クライアント送信部１４は、検知部１２によるイベント検知から所定時間以内に、収集部１３が少なくとも１回操作を検知した場合、無事であることを示す状況情報を生成してもよい。そして、クライアント送信部１４は、検知部１２によるイベント検知から所定時間以内に、収集部１３が１回も操作を検知しなかった場合、不明であることを示す状況情報を生成してもよい。なお、以下の実施形態で、操作履歴に基づき状況情報を生成する処理の他の例を説明する。
【００４５】
次に、サーバ２の機能構成を説明する。図５に、サーバ２の機能ブロック図の一例を示す。図示するように、処理システムが有する１つ又は複数のサーバ２（図１に示す第１〜第Ｎのサーバ２−１〜２−Ｎ）各々は、主機能部２３と、サーバ取得部２１と、サーバ送信部２２とを有する。主機能部２３は、クライアント端末１にインストールされた各アプリケーションと連携して各サーバ２の主たる機能を実現する機能部であり、サーバ取得部２１及びサーバ送信部２２は、安否確認に関する機能を実現する機能部である。サーバ取得部２１及びサーバ送信部２２は、予め各サーバ２に備えられた機能であってもよいし、プラグイン等で拡張された機能であってもよい。以下、各機能部を詳細に説明する。
【００４６】
主機能部２３は、クライアント端末１の主機能部１１と連携して、各サーバ２の主たる機能を実現する。主機能部２３が実現する機能は、各サーバ２が提供する機能（サービス）に応じて定まる。以下、一例を説明するがこれらに限定されない。
【００４７】
サーバ２が電子メールサーバである場合、例えば、主機能部２３は、電子メールサービスの管理・制御等を行う。また、サーバ２が電話サーバやテレビ会議サーバである場合、例えば、主機能部２３は、ＳＩＰ（Session Initiation Protocol）を利用したＩＰ（Internet Protocol）電話サービスの管理・制御等を行なう。
【００４８】
また、サーバ２がスケジュール管理サーバである場合、例えば、主機能部２３は、スケジュール管理サービスの管理・制御等を行う。また、サーバ２が施設予約サーバである場合、例えば、主機能部２３は、施設予約サービスの管理・制御等を行う。また、サーバ２がゲームサーバである場合、例えば、主機能部２３は、ゲームの管理・制御等を行う。また、サーバ２がチャットサーバである場合、例えば、主機能部２３は、チャットの管理・制御等を行う。
【００４９】
サーバ取得部２１は、クライアント端末１からアプリケーションの操作履歴、及び、状況情報の少なくとも一方と、ユーザ識別情報とを取得する。サーバ取得部２１は、１つ又は複数のクライアント端末１各々から、操作履歴及び状況情報の少なくとも一方を取得する。そして、サーバ送信部２２は、サーバ取得部２１が取得した操作履歴及び状況情報の少なくとも一方と、ユーザ識別情報とを安否確認システム３に送信する。なお、本実施形態では、サーバ取得部２１は状況情報を取得し、サーバ送信部２２は状況情報をサーバ２に送信する。サーバ取得部２１が操作履歴を取得する実施形態や、サーバ送信部２２が操作履歴を送信する実施形態は、以下で説明する。
【００５０】
サーバ送信部２２から安否確認システム３にデータ（操作履歴及び状況情報の少なくとも一方）が送信されるタイミングは、複数のサーバ２各々から安否確認システム３にデータ送信されるタイミングが互いに異なるように（同じタイミングでデータ送信しないように）、制御されていてもよい。
【００５１】
当該制御の一例として、サーバ送信部２２は、予め定められたタイミングで、データ（操作履歴及び状況情報の少なくとも一方）を安否確認システム３に送信してもよい。この場合、複数のサーバ２各々から安否確認システム３にデータ送信されるタイミングが互いに異なるように（同じタイミングでデータ送信しないように）、各サーバ２のサーバ送信部２２がデータ送信するタイミングが定められる。データ送信するタイミングは時刻で定義されてもよい。一例として、第１のサーバ２のサーバ送信部２２が送信するタイミングは毎分「００秒」となるタイミングであり、第２のサーバ２のサーバ送信部２２が送信するタイミングは毎分「１０秒」となるタイミング等のように定義されてもよい。
【００５２】
次に、安否確認システム３の機能構成を説明する。図６に、安否確認システム３の機能ブロック図の一例を示す。図示するように、安否確認システム３は、安否確認システム取得部３１と、登録部３２とを有する。
【００５３】
安否確認システム取得部３１は、１つ又は複数のサーバ２各々から、クライアント端末１における各アプリケーションの操作履歴、及び、当該操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方と、ユーザ識別情報とを取得する。本実施形態では、安否確認システム取得部３１は状況情報を取得する。安否確認システム取得部３１が操作履歴を取得する実施形態は、以下で説明する。
【００５４】
登録部３２は、操作履歴に基づき決定されたユーザ状況を示す状況情報を、ユーザ識別情報に対応付けて登録する。具体的には、登録部３２は、状況情報を、ユーザ識別情報に対応付けて、記憶部に記憶させる。当該記憶部は、安否確認システム３が備えてもよいし、安否確認システム３と通信可能に構成された外部装置が備えてもよい。
【００５５】
図７に、状況情報とユーザ識別情報とを対応付けた情報（安否情報）の一例を模式的に示す。図示する例では、ユーザ識別情報と、所属している部署と、氏名と、ユーザ状況と、被災状況と、出社可否情報とが互いに対応付けられている。ユーザ識別情報、部署及び氏名は、予め互いに対応付けて登録されている。ユーザ状況は、安否確認システム取得部３１が取得した状況情報に基づき登録される。被災状況及び出社可否については、後述する。
【００５６】
なお、クライアント端末１が複数のアプリケーション部１０を有する場合、安否確認システム取得部３１は、同一の安否確認対象者に関する状況情報を複数のサーバ２から取得することとなる。この場合、登録部３２は、複数の状況情報に基づき１つの状況情報を決定し、決定した状況情報を登録することができる。例えば、登録部３２は、複数の状況情報の中の少なくとも１つが無事を示す場合、無事を示す状況情報を登録してもよい。そして、登録部３２は、複数の状況情報の全てが不明であることを示す場合、不明であることを示す状況情報を登録してもよい。
【００５７】
次に、図８のシーケンス図を用いて、処理システムの処理の流れの一例を説明する。ここでは、クライアント端末１は、第１のアプリケーション部１０−１と第２のアプリケーション部１０−２の２つのアプリケーション部１０を有する前提とする。
【００５８】
まず、災害に関するイベントが発生すると、第１のアプリケーション部１０−１の検知部１２、及び、第２のアプリケーション部１０−２の検知部１２は、当該イベントを検知する（Ｓ１０）。
【００５９】
第１のアプリケーション部１０−１の収集部１３は、第１のアプリケーション部１０−１の検知部１２による災害に関するイベントの検知に応じて、自アプリケーションの操作履歴を収集する収集処理を開始する（Ｓ１１）。また、第２のアプリケーション部１０−２の収集部１３は、第２のアプリケーション部１０−２の検知部１２による災害に関するイベントの検知に応じて、自アプリケーションの操作履歴を収集する収集処理を開始する（Ｓ１１）。
【００６０】
そして、第１のアプリケーション部１０−１のクライアント送信部１４は、収集処理で収集された自アプリケーションの操作履歴に基づき、ユーザ状況を示す状況情報を生成する（Ｓ１２）。次いで、第１のアプリケーション部１０−１のクライアント送信部１４は、自アプリケーションと連携して所定の機能を提供する第１のサーバ２−１に、生成した状況情報と、自アプリケーションのユーザを識別するユーザ識別情報とを送信する（Ｓ１３）。
【００６１】
また、第２のアプリケーション部１０−２のクライアント送信部１４は、収集処理で収集された自アプリケーションの操作履歴に基づき、ユーザ状況を示す状況情報を生成する（Ｓ１２）。次いで、第２のアプリケーション部１０−２のクライアント送信部１４は、自アプリケーションと連携して所定の機能を提供する第２のサーバ２−２に、生成した状況情報と、自アプリケーションのユーザを識別するユーザ識別情報況情報とを送信する（Ｓ１４）。
【００６２】
第１のサーバ２−１のサーバ取得部２１は、Ｓ１３で送信された状況情報とユーザ識別情報とを取得する。そして、第１のサーバ２−１のサーバ送信部２２は、Ｓ１３で取得された状況情報とユーザ識別情報とを安否確認システム３に送信する（Ｓ１５）。
【００６３】
また、第２のサーバ２−２のサーバ取得部２１は、Ｓ１４で送信された状況情報とユーザ識別情報とを取得する。そして、第２のサーバ２−２のサーバ送信部２２は、Ｓ１４で取得された状況情報とユーザ識別情報とを安否確認システム３に送信する（Ｓ１６）。
【００６４】
安否確認システム３の安否確認システム取得部３１は、Ｓ１５及びＳ１６で送信された状況情報とユーザ識別情報とを取得する。そして、安否確認システム３の登録部３２は、状況情報とユーザ識別情報とを対応付けて登録する（Ｓ１７）。
【００６５】
なお、安否確認対象者各々の各アプリケーションのユーザ識別情報は、同一であってもよい。例えば、安否確認対象者は任意の団体（例：企業等）に所属するメンバーであり、アプリケーションは団体の活動（例：業務等）で利用されるものであってもよい。この場合、その団体内で決定された安否確認対象者各々の識別情報が、安否確認対象者各々の各アプリケーションのユーザ識別情報として利用されてもよい。
【００６６】
その他、安否確認対象者各々の各アプリケーションのユーザ識別情報は、互いに異なってもよい。この場合、安否確認システム３は、安否確認対象者各々の各アプリケーションのユーザ識別情報を互いに対応付けた対応付け情報を予め保持しておく。そして、当該対応付け情報を利用して、複数のサーバ２各々から取得した情報を、同一の安否確認対象者に関するもの同士で対応付けることができる。
【００６７】
次に、本実施形態の処理システムの作用効果を説明する。本実施形態の処理システムでは、安否確認対象者の安否情報（状況情報）を、安否確認対象者が所有するクライアント端末１から、サーバ２を経由して、安否確認システム３に送信する。このため、クライアント端末１から安否確認システム３に直接安否確認対象者の安否情報（状況情報）を送信する場合に比べて、安否確認システム３に情報を送信する送信元の数を減らすことができる。
【００６８】
送信元の数が少ない程、送信タイミングの制御は簡単になる。サーバ２（送信元）から安否確認システム３へのデータ送信のタイミングを適切に制御することで、データ送信のタイミングが重なり、安否確認システム３の処理負担が大きくなる不都合を軽減できる。
【００６９】
＜第２の実施形態＞
本実施形態の処理システムでは、クライアント端末１は、アプリケーションの操作履歴を収集する収集処理を開始すると、予め定められた終了タイミングとなるまで、収集処理を継続する。そして、クライアント端末１は、収集処理を継続している間に所定の判断タイミングになると、その都度、それまでに収集された操作履歴に基づき状況情報を生成し、サーバ２に送信する。以下、詳細に説明する。
【００７０】
本実施形態のクライアント端末１の機能ブロック図の一例は、第１の実施形態同様、図３で示される。
【００７１】
収集部１３は、災害に関するイベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始した後、予め定められた所定の終了タイミングになるまで収集処理を継続する。クライアント送信部１４は、収集処理が継続している間、繰り返し到来する所定の判断タイミングで、それまでに収集された１つ又は複数の操作履歴に基づき状況情報を生成する。
【００７２】
ここで、複数の操作履歴に基づき状況情報を生成する処理の一例を説明する。なお、当該例では、状況情報が取り得る内容は「無事」、「生存」、「不明」の３つであるものとする。「無事」は、安否確認対象者が生存しており、かつ、業務等をこなせるほど無事な状態であることを意味する。「生存」は、安否確認対象者が生存しているが、無事か否かは不明な状態を意味する。「不明」は、安否確認対象者が生存しているか否か、また、無事か否かが不明な状態を意味する。
【００７３】
例えば、クライアント送信部１４は、災害に関するイベントの検知から所定の時間ｔ１が経過するまでの間に少なくとも１回のアプリケーションの操作が検出されている場合、状況情報「生存」を生成してもよい。
【００７４】
なお、クライアント送信部１４は、災害に関するイベントの検知から所定の時間ｔ１が経過するまでの間に所定時間継続してアプリケーションの操作が検出されている場合、状況情報「無事」を生成してもよい。例えば、クライアント送信部１４は、直前のアプリケーションの操作タイミングから今回のアプリケーションの操作タイミングまでの経過時間が基準値以下である場合、操作が継続していると判断してもよい。
【００７５】
また、クライアント送信部１４は、災害に関するイベントの検知から所定の時間ｔ１が経過するまでの間に所定回数以上アプリケーションの操作が検出されている場合、状況情報「無事」を生成してもよい。
【００７６】
また、クライアント送信部１４は、災害に関するイベントの検知から所定の時間ｔ１が経過した後に少なくとも１回のアプリケーションの操作が検出されている場合、状況情報「無事」を生成してもよい。
【００７７】
時間ｔ１が経過するまでに検出された１回のアプリケーションの操作だけでは、その安否確認対象者の生存を確認できても、無事か否かの判断はできない。負傷していても、１回位なら操作できる可能性がある。しかし、アプリケーションを継続して操作していたり、また、所定回数以上操作しているような場合には、その安否確認対象者の無事を推認できる。
【００７８】
また、時間ｔ１が経過するまでは生存していたとしても、２次災害等にあう恐れがある。時間ｔ１が経過した後にアプリケーションの操作が検出されれば、２次災害に合わずに生存している、すなわち無事であると推認できる。
【００７９】
なお、クライアント送信部１４は、アプリケーションの操作が１回も検出されていない場合、状況情報「不明」を生成してもよい。
【００８０】
判断タイミングは、経過時間で定義されてもよい。例えば、判断タイミングは、災害に関するイベントの検知から所定時間ｔ２経過したタイミング、及び、先の判断タイミングから所定時間ｔ２経過したタイミングであってもよい（ｔ１≧ｔ２）。
【００８１】
その他、判断タイミングは、アプリケーションに対する操作が検出された回数で定義されてもよい。例えば、判断タイミングは、災害に関するイベントの検知後に検出された操作の回数が所定値になったタイミング、及び、先の判断タイミング後に検出された操作の回数が所定値になったタイミングであってもよい。
【００８２】
その他、判断タイミングは、経過時間と、アプリケーションに対する操作が検出された回数との組合せで定義されてもよい。例えば、判断タイミングは、災害に関するイベントの検知から所定時間ｔ２経過したタイミング、及び、災害に関するイベントの検知後に検出された操作の回数が所定値になったタイミングのいずれか早い方（又は遅い方）であってもよい。さらに、判断タイミングは、先の判断タイミングから所定時間ｔ２経過したタイミング、及び、先の判断タイミング後に検出された操作の回数が所定値になったタイミングのいずれか早い方（又は遅い方）であってもよい。
【００８３】
終了タイミングは、経過時間で定義されてもよい。例えば、終了タイミングは、収集処理を開始してから所定時間ｔ３経過したタイミング（ｔ３＞ｔ１≧ｔ２）であってもよい。その他、終了タイミングは、アプリケーションに対する操作が検出された回数で定義されてもよい。例えば、終了タイミングは、アプリケーションに対する操作がＭ回検出されたタイミングであってもよい。その他、終了タイミングは、生成された状況情報の数で定義されてもよい。例えば、終了タイミングは、状況情報がＮ回生成されたタイミングであってもよい。
【００８４】
その他、終了タイミングは、状況情報の内容が予め定められた終了条件を満たすタイミングであってもよい。終了条件は、例えば、「状況情報が無事になったこと」であってもよい。
【００８５】
次に、図９のフローチャートを用いて、クライアント端末１の処理の流れの一例を説明する。まず、１つ又は複数のアプリケーション部１０各々の検知部１２が災害に関するイベントを検知すると（Ｓ２０）、１つ又は複数のアプリケーション部１０各々の収集部１３が自アプリケーションの操作履歴を収集する収集処理を開始する（Ｓ２１）。収集処理の開始に応じて、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、上述した判断タイミングの到来の監視を開始する。また、収集処理の開始に応じて、１つ又は複数のアプリケーション部１０各々の収集部１３は、上述した終了タイミングの到来の監視を開始する。
【００８６】
判断タイミングになると（Ｓ２２のＹｅｓ）、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、それまでに収集された操作履歴に基づき、状況情報を生成する（Ｓ２３）。そして、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、生成した状況情報を、自アプリケーションと連携するサーバ２に送信する（Ｓ２４）。
【００８７】
終了タイミングになるまで、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、上述した判断タイミングの到来の監視を継続し、Ｓ２２乃至Ｓ２４の処理を繰り返す。
【００８８】
終了タイミングになると（Ｓ２５のＹｅｓ）、１つ又は複数のアプリケーション部１０各々の収集部１３は収集処理を終了する（Ｓ２６）。
【００８９】
本実施形態の処理システムのその他の構成は、第１の実施形態の処理システムの構成と同様である。
【００９０】
以上説明した本実施形態の処理システムによれば、第１の実施形態の処理システムと同様な作用効果を実現できる。
【００９１】
また、本実施形態の処理システムによれば、アプリケーションの操作履歴の収集を所定の終了タイミングまで継続し、その間に蓄積された操作履歴に基づき、安否確認対象者の状況を示す状況情報を生成することができる。一定期間内に蓄積された操作履歴に基づき判断することで、安否確認対象者の状況をより正確に判断することができる。例えば、アプリケーションを所定時間の間継続して利用できるほど無事な状態なのか、所定時間内に所定回数以上アプリケーションを操作できるほど無事な状態なのか、また、２次災害が発生する可能性があるタイミングが経過した後において生存が確認された無事な状態なのか等を判断できる。
【００９２】
上述の通り、複数の入力情報に基づき判断することで、安否確認対象者の状況をより正確に判断することができるが、安否確認対象者が安否情報を複数回入力しなければならない構成とすると、安否確認対象者の負担が大きくなる。本発明は、アプリケーションに対する操作履歴（入力情報）を利用するので、安否確認対象者の負担を軽減できる。
【００９３】
また、本実施形態の処理システムによれば、状況情報が無事になったタイミング、すなわち安否確認対象者の無事が確認できたタイミングで、アプリケーションの操作履歴の収集、状況情報の生成、及び、状況情報の送受信を終了することができる。また、本実施形態の処理システムによれば、収集処理を開始してから所定時間経過したタイミングで、これらの処理を終了することができる。適切なタイミングで処理を終了することで、処理システムの負担を軽減できる。
【００９４】
また、本実施形態の処理システムによれば、予め定められた判断タイミングで状況情報を生成し、生成した状況情報をクライアント端末１とサーバ２と間で送受信することができる。そして、当該判断タイミングを、アプリケーションに対する操作が検出された回数を用いて定義することができる。
【００９５】
アプリケーションに対する操作のタイミングは、アプリケーションごとに異なる。このため、１つのクライアント端末１が有する複数のアプリケーション部１０各々の判断タイミングが重なる可能性は低い。このため、複数のアプリケーション部１０各々のクライアント送信部１４が同時に状況情報を生成し、同時にサーバ２に送信する不都合を抑制できる。
【００９６】
また、アプリケーションに対する操作のタイミングは、安否確認対象者ごとに異なり、多数の安否確認対象者が同時に同じアプリケーションに対する操作を行うことは稀である。このため、多数のクライアント端末１各々において同時に同じアプリケーション部１０のクライアント送信部１４が判断タイミングを検出し、同時に、状況情報をサーバ２に送信することは稀である。このため、複数のクライアント端末１からサーバ２への状況情報の送信タイミングが集中し、サーバ２の負荷が大きくなる不都合を抑制できる。
【００９７】
＜第３の実施形態＞
本実施形態の処理システムでは、クライアント端末１は、第２の実施形態と同様に、収集処理を継続している間に所定の判断タイミングになると、その都度、それまでに収集された操作履歴に基づき状況情報を生成し、生成した状況情報のうち、送信条件を満たす状況情報を、サーバ２に送信する。以下、詳細に説明する。
【００９８】
本実施形態のクライアント端末１の機能ブロック図の一例は、第２の実施形態同様、図３で示される。
【００９９】
クライアント送信部１４は、第２の実施形態同様、収集処理が継続している間、繰り返し到来する所定の判断タイミングで、それまでに収集された１つ又は複数の操作履歴に基づき状況情報を生成する。そして、クライアント送信部１４は、判断タイミングで生成した状況情報のうち、送信条件を満たす状況情報を、サーバ２に送信する。
【０１００】
送信条件は、「直前に送信した状況情報の内容と異なる」であってもよいし、「状況情報の内容が不明以外（例：無事、生存）である」であってもよいし、「収集処理開始後、最初に生成した状況情報である」であってもよい。
【０１０１】
次に、図１０のフローチャートを用いて、クライアント端末１の処理の流れの一例を説明する。まず、１つ又は複数のアプリケーション部１０各々の検知部１２が災害に関するイベントを検知すると（Ｓ３０）、１つ又は複数のアプリケーション部１０各々の収集部１３が自アプリケーションの操作履歴を収集する収集処理を開始する（Ｓ３１）。収集処理の開始に応じて、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、第２の実施形態で説明した判断タイミングの到来の監視を開始する。また、収集処理の開始に応じて、１つ又は複数のアプリケーション部１０各々の収集部１３は、第２の実施形態で説明した終了タイミングの到来の監視を開始する。
【０１０２】
判断タイミングになると（Ｓ３２のＹｅｓ）、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、それまでに収集された操作履歴に基づき、状況情報を生成する（Ｓ３３）。状況情報の生成処理の詳細は、第２の実施形態で説明したので、ここでの説明は省略する。
【０１０３】
次いで、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、生成した状況情報の内容が、送信条件を満たすか判断する（Ｓ３４）。送信条件を満たす場合（Ｓ３４のＹｅｓ）、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、生成した状況情報を、自アプリケーションと連携するサーバ２に送信する（Ｓ３５）。
【０１０４】
終了タイミングになるまで、１つ又は複数のアプリケーション部１０各々のクライアント送信部１４は、上述した判断タイミングの到来の監視を継続し、Ｓ３２乃至Ｓ３５の処理を繰り返す。
【０１０５】
終了タイミングになると（Ｓ３６のＹｅｓ）、１つ又は複数のアプリケーション部１０各々の収集部１３は収集処理を終了する（Ｓ３７）。
【０１０６】
本実施形態の処理システムのその他の構成は、第２の実施形態の処理システムの構成と同様である。
【０１０７】
以上説明した本実施形態の処理システムによれば、第２の実施形態の処理システムと同様な作用効果を実現できる。
【０１０８】
また、本実施形態の処理システムによれば、送信条件を満たす状況情報のみを送受信する構成とすることで、クライアント端末１とサーバ２との間、及び、サーバ２と安否確認システム３との間における不要な情報の送受信を抑制できる。結果、これら装置の処理負担を軽減できる。
【０１０９】
＜第４の実施形態＞
本実施形態の処理システムでは、クライアント端末１のクライアント送信部１４は、操作履歴をサーバ２に送信する。そして、サーバ２のサーバ送信部２２は、操作履歴に基づき状況情報を生成し、生成した状況情報を安否確認システム３に送信する。操作履歴に基づく状況情報の生成処理は、第１乃至第３の実施形態と同様である。
【０１１０】
なお、サーバ送信部２２は、第２及び第３の実施形態で説明したクライアント送信部１４と同様に、収集処理が継続している間、繰り返し到来する所定の判断タイミングで、それまでに収集された１つ又は複数の操作履歴に基づき状況情報を生成してもよい。また、サーバ送信部２２は、判断タイミングで生成した状況情報のうち、送信条件を満たす状況情報を、安否確認システム３に送信してもよい。この例の場合、サーバ２が、状況情報の内容が予め定められた終了条件を満たすか判断し、終了条件を満たすと、その旨をクライアント端末１に通知してもよい。
【０１１１】
処理システムのその他の構成は、第１乃至第３の実施形態と同様である。
【０１１２】
本実施形態の処理システムによれば、第１乃至第３の実施形態と同様の作用効果を実現できる。
【０１１３】
＜第５の実施形態＞
本実施形態の処理システムでは、クライアント端末１のクライアント送信部１４は、操作履歴をサーバ２に送信する。そして、サーバ２のサーバ送信部２２は、操作履歴を安否確認システム３に送信する。安否確認システム３の登録部３２は、操作履歴に基づき状況情報を生成し、生成した状況情報を登録する。操作履歴に基づく状況情報の生成処理は、第１乃至第４の実施形態と同様である。
【０１１４】
なお、登録部３２は、第２及び第３の実施形態で説明したクライアント送信部１４と同様に、収集処理が継続している間、繰り返し到来する所定の判断タイミングで、それまでに収集された１つ又は複数の操作履歴に基づき状況情報を生成してもよい。この例の場合、安否確認システム３が、状況情報の内容が予め定められた終了条件を満たすか判断し、終了条件を満たすと、その旨を、サーバ２を経由してクライアント端末１に通知してもよい。
【０１１５】
処理システムのその他の構成は、第１乃至第４の実施形態と同様である。
【０１１６】
本実施形態の処理システムによれば、第１乃至第４の実施形態と同様の作用効果を実現できる。
【０１１７】
＜変形例＞
ここで、すべての実施形態に適用可能な変形例を説明する。災害発生時には、クライアント端末１のインターネットへの接続が切断される場合がある。そこで、クライアント送信部１４は、操作履歴及び状況情報の少なくとも一方をサーバ２に送信するタイミングでインターネットへの接続が切断されている場合には、自クライアント端末１のインターネットへの接続状況を監視し、自クライアント端末１がインターネットに接続されたタイミングで、操作履歴及び状況情報の少なくとも一方をサーバ２に送信してもよい。
【０１１８】
他の変形例を説明する。安否確認対象者の監督者は、所定の端末を操作して安否確認システム３にログインし、所定の安否確認対象者の安否情報を閲覧できてもよい。また、監督者は、安否確認システム３に対して、所定の安否確認対象者の所定の情報を要求する入力を行ってもよい。所定の情報は、被災状況、出社可否等が考えられるが、これらに限定されない。
【０１１９】
安否確認システム３は、所定のサーバ２に当該情報のリクエストを送信する。当該情報のリクエストを受信したサーバ２は、クライアント端末１に送信する。当該リクエストは、当該リクエストを送信したサーバ２と連携するアプリケーション部１０が取得する。そして、そのアプリケーション部１０は、ポップアップ、プッシュ通知等の手段で当該情報のリクエストを安否確認対象者に通知し、任意の手段で回答の入力を受付ける。そして、そのアプリケーション部１０は、受付けた回答を、連携しているサーバ２に送信する。回答を受信したサーバ２は、その回答を安否確認システム３に送信する。安否確認システム３の登録部３２は、受信した回答を安否情報として登録する（図７参照）。結果、監督者は、リクエストした情報を閲覧できる。
【０１２０】
なお、安否確認システム３は、その安否確認対象者に対応付けて不明以外の状況情報を送信してきたサーバ２に、当該情報のリクエストを送信してもよい。このようなサーバ２は、災害に関するイベント検知後に、安否確認対象者が操作したアプリケーションと連携しているサーバ２である。このようなサーバ２及びアプリケーションを介して安否確認対象者にリクエストを通知することで、リクエストの確認漏れ等を抑制することができる。
【０１２１】
以上、実施形態（及び実施例）を参照して本願発明を説明したが、本願発明は上記実施形態（及び実施例）に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１２２】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限定されない。
１．  クライアント端末のコンピュータを、
災害に関するイベントを検知する検知手段、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集手段、及び、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信手段、
として機能させるプログラム。
２．  １に記載のプログラムにおいて、
前記クライアント送信手段は、前記操作履歴に基づき前記状況情報を生成し、生成した前記状況情報を前記サーバに送信するプログラム。
３．  ２に記載のプログラムにおいて、
前記収集手段は、予め定められた所定の終了タイミングになるまで前記収集処理を継続し、
前記クライアント送信手段は、前記収集処理が継続している間、繰り返し到来する所定の判断タイミングで、それまでに収集された前記操作履歴に基づき、前記状況情報を生成するプログラム。
４．  ３に記載のプログラムにおいて、
前記収集手段は、前記状況情報の内容が予め定められた終了条件を満たすと、前記収集処理を終了するプログラム。
５．  ３に記載のプログラムにおいて、
前記収集手段は、前記収集処理を開始してから所定時間経過すると、前記収集処理を終了するプログラム。
６．  ３から５のいずれかに記載のプログラムにおいて、
前記クライアント送信手段は、前記判断タイミングで生成した前記状況情報のうち、送信条件を満たす前記状況情報を、前記サーバに送信するプログラム。
７．  災害に関するイベントを検知する検知手段と、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集手段と、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信手段と、
を有するクライアント端末。
８．  クライアント端末のコンピュータが、
災害に関するイベントを検知する検知工程と、
前記イベントの検知に応じて、アプリケーションの操作履歴を収集する収集処理を開始する収集工程と、
前記操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバに送信するクライアント送信工程と、
を実行する処理方法。
９．  サーバのコンピュータを、
クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得手段、及び、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信手段、
として機能させるプログラム。
１０．  ９に記載のプログラムにおいて、
前記サーバ送信手段は、前記操作履歴に基づき前記状況情報を生成し、生成した前記状況情報を前記安否確認システムに送信するプログラム。
１１．  クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得手段と、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信手段と、
を有するサーバ。
１２．  サーバのコンピュータが、
クライアント端末からアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を取得するサーバ取得工程と、
前記操作履歴及び前記状況情報の少なくとも一方を、ユーザ毎の安否を管理する安否確認システムに送信するサーバ送信工程と、
を実行する処理方法。
１３．  クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得手段と、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録手段と、
を有する安否確認システム。
１４．  １３に記載の安否確認システムにおいて、
前記登録手段は、前記操作履歴に基づき前記状況情報を生成し、生成した前記状況情報を登録する安否確認システム。
１５．  １３又は１４に記載の安否確認システムにおいて、
前記安否確認システム取得手段は、互いに異なるアプリケーションと連携している複数の前記サーバ各々から、前記操作履歴及び前記状況情報の少なくとも一方を取得する安否確認システム。
１６．  コンピュータが、
クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得工程と、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録工程と、
を実行する処理方法。
１７．  コンピュータを、
クライアント端末におけるアプリケーションの操作履歴、及び、前記操作履歴に基づき決定したユーザ状況を示す状況情報の少なくとも一方を、前記アプリケーションと連携するサーバから取得する安否確認システム取得手段、及び、
前記操作履歴に基づき決定したユーザ状況を示す状況情報を登録する登録手段、
として機能させるプログラム。
【符号の説明】
【０１２３】
１Ａ    プロセッサ
２Ａ    メモリ
３Ａ    入出力Ｉ／Ｆ
４Ａ    周辺回路
５Ａ    バス
１      クライアント端末
２      サーバ
３      安否確認システム
１０    アプリケーション部
１１    主機能部
１２    検知部
１３    収集部
１４    クライアント送信部
２１    サーバ取得部
２２    サーバ送信部
２３    主機能部
３１    安否確認システム取得部
３２    登録部
【図１】
2020149295.tif 000003
【図２】
2020149295.tif 000004
【図３】
2020149295.tif 000005
【図４】
2020149295.tif 000006
【図５】
2020149295.tif 000007
【図６】
2020149295.tif 000008
【図７】
2020149295.tif 000009
【図８】
2020149295.tif 000010
【図９】
2020149295.tif 000011
【図１０】
2020149295.tif 000012