JP7273124B1 - プログラム、情報処理方法、サーバ - Google Patents

Abstract

【課題】安否確認に関する利便性を向上させるサーバの情報処理方法を提供する。【解決手段】端末と通信するサーバによって実行されるプログラムは、端末のユーザに対する安否確認の依頼に関する第１情報を、サーバの通信部によって第１端末から受信し、第１情報と設定された条件とに基づき、安否確認に関する第２情報を、通信Ｉ／Ｆによって端末に送信し、端末のユーザに対する第１情報をサーバが最初に受信した場合、第２情報を端末に送信し、端末のユーザに対する第１情報を最初に受信した後、第１設定条件に基づいて第２情報を、端末に送信する。【選択図】図１－１

Description

本開示は、プログラム、情報処理方法、端末、サーバ等に関する。

災害発生時に携帯端末を用いて警報を報知する技術がある（例えば、特許文献１）。

特開２０１６－１５１７９９号公報

本発明の第１の態様によると、端末と通信するサーバによって実行されるプログラムは、端末のユーザに対する安否確認の依頼に関する第１情報をサーバの通信部によって第１端末から受信することと、第１情報と設定された条件とに基づき、安否確認に関する第２情報を通信部によって端末に送信することとがサーバによって実行される。
本発明の第２の態様によると、端末と通信するサーバの情報処理方法は、端末のユーザに対する安否確認の依頼に関する第１情報をサーバの通信部によって第１端末から受信することと、第１情報と設定された条件とに基づき、安否確認に関する第２情報を通信部によって端末に送信することとを含む。
本発明の第３の態様によると、端末と通信するサーバは、端末のユーザに対する安否確認の依頼に関する第１情報を第１端末から受信し、第１情報と設定された条件とに基づき、安否確認に関する第２情報を端末に送信する通信部を備える。
本発明の第４の態様によると、端末と通信するサーバは、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、端末のユーザに対する安否確認の依頼に関する第１情報をサーバの通信部によって第１端末から受信することと、第１情報と設定された条件とに基づき、安否確認に関する第２情報を通信部によって端末に送信することとを実行する。
本発明の第５の態様によると、端末と通信するサーバによって実行されるプログラムは、端末のユーザに対するコンテンツの送信の依頼に関する第１情報を第１端末からサーバの通信部によって受信することと、第１情報に基づき、コンテンツに関する第２情報を端末に通信部によって送信することと、端末のユーザに対する第１情報を第２端末からサーバの通信部によって受信することと、第１情報と設定された条件とに基づき、第２情報を端末に通信部によって送信することとがサーバによって実行される。

実施形態に係る通信システムのシステム構成の一例を示す図。 第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。 第１実施例に係るサーバの記憶部に記憶される情報等の一例を示す図。 第１実施例に係るアカウント登録データの一例を示す図。 第１実施例に係るアカウント管理データベースの一例を示す図。 第１実施例に係る端末の制御部によって実現される機能の一例を示す図。 第１実施例に係る端末の記憶部に記憶される情報等の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係るサーバの記憶部に記憶される情報等の一例を示す図。 第１変形例に係るグループ管理データベースの一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例に係る安否確認処理の流れの一例を示すフローチャート。 第２実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第２変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第４変形例に係る端末の表示部に表示される画面の一例を示す図。 第４変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第５実施例に係る端末の表示部に表示される画面の一例を示す図。 第５実施例に係る端末の表示部に表示される画面の一例を示す図。 第５実施例に係る端末の表示部に表示される画面の一例を示す図。 第５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る安否登録リクエスト処理の流れの一例を示すフローチャート。 第５変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第６実施例に係る端末の表示部に表示される画面の一例を示す図。 第６実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第６変形例に係る端末の表示部に表示される画面の一例を示す図。 第７実施例に係る端末の表示部に表示される画面の一例を示す図。 第７実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第７変形例に係るアカウント管理データベースの一例を示す図。 第７変形例に係る端末の表示部に表示される画面の一例を示す図。 第７変形例に係る各装置が実行する処理のタイミングの一例を示す図。 第７変形例に係る端末の表示部に表示される画面の一例を示す図。 第８実施例に係る端末の表示部に表示される画面の一例を示す図。 第８実施例に係る各装置が実行する処理のタイミングの一例を示す図。 第８実施例に係る第１安否情報と第２安否情報との組み合わせを示す図。 第９実施例に係る端末の表示部に表示される画面の一例を示す図。 第９変形例に係る端末の表示部に表示される画面の一例を示す図。

＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。

＜実施形態＞
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。

本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。

システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。

また、クライアント（クライアント装置）とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
（１）端末＆サーバ
（２）サーバ
（３）端末

（１）は、限定ではなく例として、少なくとも１つの端末と、少なくとも１つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。

サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。

具体的には、サーバは、限定ではなく例として、少なくとも１つのプロセッサー（限定ではなく例として、ＣＰＵ：Central Processing Unit、ＧＰＵ：Graphics Processing Unit、ＡＰＵ：Accelerated Processing Unit、ＤＳＰ：Digital Signal Processor（限定ではなく例として、ＡＳＩＣ：Application Specific Integrated Circuit、ＦＰＧＡ：Field Programmable Gate Array）等）、コンピュータ装置（プロセッサー＋メモリ）、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか１つの装置の同種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＣＰＵ、ホモジニアスマルチコアプロセッサー等）や、いずれか１つの装置の異種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＤＳＰ、ヘテロジニアスマルチコアプロセッサー等）としてもよいし、複数の装置の組み合わせ（限定ではなく例として、プロセッサー＋コンピュータ装置、プロセッサー＋演算装置、複数の装置をヘテロジニアス化したもの等）であってもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。

また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第１処理をプロセッサーが実行し、第２処理を演算装置が実行するように構成されていてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。

また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるＰａａＳやＩａａＳ、ＳａａＳの形態で提供されるようにしてもよい。

また、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、（１Ａ）端末の制御部のみ、（１Ｂ）サーバの制御部のみ、（１Ｃ）端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。

また、システムの制御部が行う制御や処理（以下、包括的に「制御等」と称する。）は、（１Ａ）端末の制御部のみによって行うようにしてもよいし、（１Ｂ）サーバの制御部のみによって行うようにしてもよいし、（１Ｃ）端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
また、（１Ｃ）では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。

また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
限定ではなく例として、サーバは、第１装置と第２装置とを備え、第１装置は第１通信部を有し、第２装置は第２通信部を有する場合、サーバの通信部は、第１通信部と第２通信部とを含む概念としてもよい。

（２）は、限定ではなく例として、複数のサーバによって構成されるシステム（以下、「サーバシステム」と称する。）とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。

サーバシステムが行う制御等は、複数のサーバのうち、（２Ａ）一のサーバのみによって行うようにしてもよいし、（２Ｂ）他のサーバのみによって行うようにしてもよいし、（２Ｃ）一のサーバと他のサーバとが行うようにしてもよい。
また、（２Ｃ）では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。

（３）は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム（分散システム）。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース（登録商標）等の近距離無線通信技術を用いてＰ２Ｐ（ピアツーピア）方式等で通信を行うことで実現可能である。

なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。

以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム（限定ではなく例として、クライアントサーバシステム）を例示する。
なお、サーバとして、上記（２）のサーバシステムを適用することも可能である。

また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記（３）のシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管（格納）する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。

なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。

また、本明細書では、適宜「通信Ｉ／Ｆによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示してもよいものとする。

また、本明細書において「関する」、「関連する」と記載された用語について、「Ａに関するＢ」や「Ａに関連するＢ」という場合、限定ではなく例として、「Ａ」と何らかの関係性を有する「Ｂ」を意味してよいものとする。この具体例については後述する。

また、本明細書において、「ＡとＢとを送信する」、「ＡとＢとを受信する」といったように、装置が２以上のものを対象として処理を行うことには、「Ａ」と「Ｂ」とをタイミングを合わせて行うもの（以下、「同時」という。）と、「Ａ」と「Ｂ」とをタイミングをずらして行うもの（以下、「非同時」という。）とを含めてよいものとする。
限定ではなく例として、第１情報と第２情報とを送信するという場合、第１情報と第２情報とをタイミングを合わせて送信するものと、第１情報と第２情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ（タイムラグ）を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。

なお、「Ａ」と「Ｂ」とをタイミングをずらして行うといっても、これはあくまでも「Ａ」と「Ｂ」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
限定ではなく例として、上記のように第１情報と第２情報とを送信するという場合、第１情報と第２情報とを送信しさえすればよく、同じ目的で第１情報と第２情報とを送信する場合の他、異なる目的で第１情報と第２情報とを送信する場合も含めてよいものとする。

以下の実施例では、ユーザがチャットを行うためのサービス（以下、「チャットサービス」と称する。）の一例として、メッセージングサービス（Messaging Service）を例示する。また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。また、チャットアプリケーションでは、限定ではなく例として、ユーザ間における通話（音声通話やビデオ通話等）を行うことができるようにすることができる。

なお、メッセージングサービス：ＭＳ（インスタントメッセージサービス：ＩＭＳを含む。）は、ソーシャルネットワーキングサービス：ＳＮＳの１つの形態（一形態）と考えることもできる。このため、メッセージンサービスとソーシャルネットワーキングサービスとを区別してもよいし、区別しなくてもよい。つまり、ソーシャルネットワーキングサービスにメッセージングサービスを含めてもよいものとする。

また、以下の実施例では、メッセージングサービスの一例として、サーバを介して複数の装置（限定ではなく例として、端末）間で、コンテンツを簡単なメッセージの形式で送受するインスタントメッセージングサービス：ＩＭＳ（Instant Messaging Service）を例示する。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。また、インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザ間における通話（音声通話やビデオ通話等）を行うことができるようにすることができる。

チャットルーム（限定ではなく例として、トークルーム）とは、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）とすることができる。

また、トークルームには、一対一のユーザのトークルーム（以下、「一対一トークルーム」と称する。）、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）、公式アカウントのユーザとのトークルーム（以下、「ＯＡトークルーム」と称する。）等を含めることができる。

なお、一対一トークルームは、データ管理上、一対一のユーザや一対一のアカウントのトークルームとして管理してもよいし、２名のユーザや２つのアカウントで構成されるグループのトークルームとして管理してもよい。

公式アカウントは、一般のユーザではなく事業者のアカウント（事業者のユーザのアカウント）であり、この公式アカウントのユーザも、限定ではなく例として、一般のユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でコンテンツ（メッセージ）の送受信を行うことができるようにすることができる。

本明細書において、コンテンツとは、送信元から送信先に送信される情報であってもよい。また、コンテンツは、１または複数のコンテンツであってもよい。

コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像（静止画像、動画像の少なくともいずれか一方を含む。）形式の画像コンテンツ、音（音声を含む。）形式の音コンテンツなどを含めてよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報（限定ではなく例として、ＵＲＩ（Uniform Resource Identifier）等を含む。）などのリンクコンテンツを含めてもよいものとする。

テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか１つを含めてよいものとする。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも１つを含まなくてもよく、その他のテキストを含んでもよい。

画像には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか１つを含めることができる。

また、以下の実施例では、災害（大規模災害等）発生時、ユーザが安否確認を行うためのサービスの一例として、安否確認サービス（Safety confirming Service）を例示する。また、安否確認サービスを実現するためのアプリケーションを「安否確認アプリケーション」と称する。
安否確認アプリケーションでは、限定ではなく例として、ユーザが自身の安否に関する情報を登録し、他のユーザの安否に関する情報を参照することができる。

安否確認サービス（安否確認アプリケーション）を実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
（Ａ）メッセージングアプリケーションの一機能として安否確認サービスの機能を持たせる形態
（Ｂ）安否確認サービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｃ）安否確認アプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
（Ｄ）安否確認アプリケーションを単体のアプリケーションとして構成する形態

（Ａ）や（Ｂ）の形態では、限定ではなく例として、安否確認サービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
また、この場合、１つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、安否確認アプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、音楽アプリケーションにおけるユーザのアカウントとが自動的に関連付けられる（連携される）ようにすることができる。

（Ｃ）の形態では、限定ではなく例として、安否確認サービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
また、（Ｃ）の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、安否確認アプリケーションにおけるユーザのアカウントとを関連付ける処理（連携する処理）を行うようにすることができる。

なお、上記とは異なり、安否確認アプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。

＜第１実施例＞
第１実施例は、限定ではなく例として、大規模災害等の災害が発生した場合、一の端末２０（以下、適宜「端末」と称する。）に、他の端末２０（以下、適宜「第１端末」と称する。）のユーザ（以下、適宜「第１ユーザ」と称する。）が登録した安否確認に関する情報（以下、「安否確認情報」と称する。）を表示する実施例である。

ここで、「安否確認情報」は、限定ではなく例として、以下の３種類の情報に大別することができる。
（Ａ１）安否ステータス情報
ユーザの置かれる状況を示す安全レベルに関するクラス情報。
本実施形態では、限定ではなく例として、ユーザによって登録される安否ステータス情報を「安全」と「危険」の２クラスとする。
なお、安否ステータス情報は、２クラスに限定されない。限定ではなく例として、安否ステータス情報に安否不明であることを示す「不明」のクラスや、災害の被災範囲外であることを示す「エリア外」等のクラスを設けるようにしてもよい。

（Ａ２）安否コメント情報
ユーザの安否を伝えるための、安否に関するメッセージ等のコンテンツ情報。
本実施形態では、限定ではなく例として、安否コメント情報をテキストとする。
なお、安否コメント情報は、限定ではなく例として、音声や映像、アイコン等としてもよい。

（Ａ３）安否位置情報
安否確認情報を登録するユーザの位置に関する情報。
本実施形態では、限定ではなく例として、安否位置情報を住所で規定されるエリア（限定ではなく例として、市区町村）とする。
なお、安否位置情報は、限定ではなく例として、緯度と経度とで規定される位置座標や、緯度と経度とで規定される位置座標で結ばれるエリアとしてもよい。また、安否位置情報に、高度に関する情報を含めるようにしてもよい。

安否確認情報には、安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせを用いることができる。
なお、安否確認情報には、少なくとも、安否ステータス情報または安否コメント情報が含まれることが望ましい。ただし、これに限定されるわけではない。

また、表示画面における安否確認情報は、日本語で表示されてもよいし、他の言語（英語等）で表示されてもよい。
限定ではなく例として、「安全」を「Ｓａｆｅ」、危険（安全ではない）を「Ｄａｎｇｅｒ」や「Ｎｏｔ Ｓａｆｅ」、エリア外を「Ｎｏｔ ＩＮ Ａｒｅａ」等のように表示してもよい。

また、以下では、安否確認情報を登録するユーザアカウントを「安否登録アカウント」、登録された安否確認情報に基づく「安否情報」を参照するユーザアカウントを「安否参照アカウント」と称する。
なお、一般に、一のユーザアカウントは安否登録アカウントと安否参照アカウントとを兼ねることができる。

また、以下では、前述したように、メッセージングアプリケーションによるメッセージングサービスを提供する事業者のことを「メッセージングサービス事業者」と称する。
なお、メッセージングサービス事業者は、メッセージングアプリケーションを提供する事業者や、サーバ１０の事業者と表現することもできる。
また、メッセージングサービスを提供する事業者という意味で、メッセージングサービスの事業者と表現することもできる。

また、以下では、メッセージングアプリケーションの名称を、適宜「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」と称して図示・説明する。

メッセージングアプリケーションでは、限定ではなく例として、友だちとしてサーバ１０に登録しているアカウント同士で、一対一トークを行うことができるように構成することができる。また、限定ではなく例として、２以上のアカウントを含むグループを構成し、グループに含まれるアカウント同士で、グループトークを行うことができるように構成することができる。

また、メッセージングアプリケーションでは、限定ではなく例として、一のユーザアカウントに対して送信されたメッセージ一覧をトークリストとして確認できるように構成することができる。

ユーザによって登録された安否確認情報を確認するための情報（以下、適宜「安否情報」と称する。）を各々の端末２０において表示する形式としては、限定ではなく例として、メッセージングアプリケーションにおける以下の構成要件に表示させる形式が挙げられる。
（Ｂ１）友だちリストに表示
（Ｂ２）トークリストに表示
（Ｂ３）トークルームに表示

なお、ユーザ同士（アカウント同士）が関連付けられていることの一例として、以下ではメッセージングサービスにおける「友だち」を主に例示するが、これに限定されない。
限定ではなく例として、ＳＮＳにおいて、自分が興味を持つなどして登録した他のユーザ（アカウント）を示す「フォロー」や、自分に興味を持つなどして自分を登録した他のユーザ（アカウント）を示す「フォロワー」のような関係も、ユーザ同士（アカウント同士）が関連付けられていることに含めることができる。

限定ではなく例として、ＳＮＳにおいて、「フォロー」関係にあるユーザや、「フォロワー」関係にあるユーザの一覧は、上記構成要件（Ｂ１）と対応させることができる。
また、限定ではなく例として、ＳＮＳにおいて、「フォロー」関係にあるユーザの投稿一覧（限定ではなく例として、「タイムライン」）は、上記構成要件（Ｂ２）と対応させることができる。
また、限定ではなく例として、ＳＮＳにおいて、特定のユーザに対する投稿（限定ではなく例として、「ダイレクトメッセージ」）は、上記構成要件（Ｂ３）と対応させることができる。

第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜システム構成＞
図１－１は、本開示の実施形態における通信システム１のシステム構成の一例を示す図である。
通信システム１では、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。

サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に、所定のサービス（限定ではなく例として、メッセージングサービス、安否確認サービス等）を提供する機能を有する。サーバ１０は、限定ではなく例として、メッセージングサーバ、安否確認サーバ等のように表現することもできる。
本実施形態では、メッセージングサービス事業者（運営者）や安否確認サービス事業者（運営者）をサーバ１０のユーザとする。

なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。

端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ、・・・）は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、ＶＲ（Virtual Reality）端末、スマートスピーカ（音声認識用デバイス）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。

ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。

［各装置のハードウェア（ＨＷ）構成］
通信システム１に含まれる各装置のＨＷ構成について説明する。

（１）端末のＨＷ構成
図１－１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部２３は、端末２０に対する各種操作を入力する装置や、端末２０で処理された処理結果を出力する装置等を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。

出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

あくまでも一例であるが、入出力部２３は、限定ではなく例として、表示部２４、音入力部２５、音出力部２６、撮像部２７を備える。

表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。

音入力部２５は、音データ（音声データを含む。以下同様。）の入力に利用される。音入力部２５は、マイクなどを含む。
音出力部２６は、音データの出力に利用される。音出力部２６は、スピーカなどを含む。
撮像部２７は、画像データ（静止画像データ、動画像データを含む。以下同様。）の取得に利用される。撮像部２７は、カメラなどを含む。

入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。

時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。

なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。

位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。

位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））、ＵＷＢ（超広帯域無線：Ultra Wide Band）を利用して端末２０の位置を算出するためのセンサやユニットであるＵＷＢ測位センサ（ＵＷＢ測位ユニット）等を含む。

衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。

慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。

ＵＷＢ測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域ＲＦ（Radio Frequency）信号をデジタル信号に変換する超広帯域ＲＦ受信回路や、超広帯域ＲＦ受信回路から出力されるデジタル信号に基づいて端末２０と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、ＵＷＢ測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域ＲＦ信号を送信することで、端末２０を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。

制御部２１は、限定ではなく例として、位置算出用情報検出部２９Ｂによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末２０の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部２１は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部２８に記憶させるようにしてもよいし、そうしなくてもよい。

制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。

記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。

端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。

（２）サーバのＨＷ構成
図１－１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。

制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。

記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。

通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部１２は、サーバ１０に対する各種操作を入力する装置や、サーバ１０で処理された処理結果を出力する装置等を含む。入出力部１２は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。

出力部は、制御部１１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

あくまでも一例であるが、入出力部１２は、限定ではなく例として、表示部１３を備える。

表示部１３は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。

時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
（３）その他
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。

本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。

なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。

また、システムのプログラム（システムによって実行されるプログラム）という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをＰ１とすると、システムのプログラムＰ１は、端末に保存されたプログラムＰ２と、サーバに保存されたプログラムＰ３とで構成され、Ｐ２とＰ３とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムＰ２は、第１の処理を実行し、第１の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムＰ３は、受信した第１の処理をした結果に対して第２の処理を行い、第２の処理を行った結果を端末に送信するプログラムであってもよい。

記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。

サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。

また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。

また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部、または全部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部、または全部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。

明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。

なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。

＜機能構成＞
（１）サーバの機能構成
図１－２は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
制御部１１は、限定ではなく例として、記憶部１５に記憶されたアプリケーション管理処理プログラム１５１に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部１１１を機能部として含む。

図１－３は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５とが記憶される。

アカウント登録データ１５３は、アプリケーション（本実施例では、メッセージングアプリケーション）のアカウントに関する登録データであり、そのデータ構成の一例を図１－４に示す。
アカウント登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、その他登録情報とが関連付けて記憶される。

ユーザ名は、このアプリケーションを利用する端末２０のアカウントの名称であり、限定ではなく例として、端末２０のユーザがアプリケーションを利用する際に登録する名称が記憶される。

アプリケーションＩＤは、アプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
アプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。

その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号（端末電話番号）、メールアドレス（端末メールアドレス）、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報といった各種の情報を含めるようにすることができる。

端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションＩＤや公式ユーザ用のアプリケーションＩＤとすることができる。

なお、アプリケーションＩＤに代えて「ユーザＩＤ」としてもよいし、しなくてもよい。
また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」とすることができる。

また、限定ではなく例として、１つのアプリケーションＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。この場合、１つのアプリケーションＩＤを識別（ログイン）対象として、複数の端末２０においてアプリケーションを同時に起動できるようにしてもよいし、そのようにしなくてもよい。

また、アプリケーションＩＤ等の各種のＩＤに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
この場合、アプリケーションＩＤ等のＩＤの情報をアカウント登録データ１５３に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ１５３に記憶させるようにすることができる。なお、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報に代えず、アプリケーションＩＤ等のＩＤの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。

なお、以下の各種の実施例では、説明の簡明化のため、１つの端末２０につき１つのアカウントが登録されていることとして説明する。
また、この場合、上記のように「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。

アカウント管理データベース１５５は、アカウント登録データ１５３に登録されたアカウントに関する情報を管理するためのデータベースであり、その一例であるアカウント管理データベース１５５Ａのデータ構成例を図１－５に示す。
アカウント管理データベース１５５Ａには、アカウントごとの管理データとして、アカウント管理データが記憶される。

各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、友だち管理データと、安否登録データとが記憶される。

アプリケーションＩＤは、アカウント管理データで管理されるアカウントを識別するための情報であり、限定ではなく例として、アカウント登録データ１５３に登録されたアプリケーションＩＤが記憶される。

友だち管理データは、このアプリケーションＩＤのアカウントと友だちであるアカウントのアプリケーションＩＤを記憶させるためのデータであり、限定ではなく例として、ユーザが友だち登録を行うと、サーバによって友だち登録を行ったユーザのアプリケーションＩＤが追加され更新される。

安否登録データは、このアプリケーションＩＤのアカウントに関連付けられた、安否に関する登録を記憶させるためのデータであり、限定ではなく例として、安否ステータス情報が記憶される。

アカウントごとの安否登録データは、限定ではなく例として、端末２０に対するユーザ操作等のユーザ入力に基づいて変更可能とすることができる。
なお、安否登録データの初期値（デフォルト）としては、限定ではなく例として、サーバ１０が安否確認情報を受信していないことを示す情報（限定ではなく例として、安否不明であることを示す「不明」フラグ）が予め設定されるようにすることができる。

また、安否登録データとして、このアカウントの端末２０によって登録された安否確認情報のうち、安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせを関連付けて記憶させるようにしてもよい。

（２）端末の機能構成
図１－６は、本実施例において端末２０の制御部２１によって実現される機能の一例を示す図である。
制御部２１は、限定ではなく例として、記憶部２８に記憶されたアプリケーション処理プログラム２８１に従ってアプリケーション処理を実行するためのアプリケーション処理部２１１を機能部として含む。

図１－７は、本実施例において端末２０の記憶部２８に記憶されるデータ等の一例を示す図である。
記憶部２８には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム２８１と、この端末２０、または端末２０のユーザのアカウントに対応するアプリケーションＩＤ２８３とが記憶される。
なお、端末２０の記憶部２８に、アカウント管理データベース１５５Ａの友だち管理データを同期させて記憶させるようにしてもよい。

＜表示画面＞
本実施例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。
以下では、限定ではなく例として、端末２０が、縦長のディスプレイの表示部２４を備えるスマートフォンである場合を例示する。

スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。

なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。

図１－８～図１－１０は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、
・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
・安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
とする場合の表示画面例を説明する。

図１－８左側は、メッセージングアプリケーション（限定ではなく、チャットアプリケーションの一例）のホーム画面であり、画面最上部中央には、メッセージングアプリケーションの名称として「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」の文字が表示されている。また、画面最上部の右部には、この端末２０Ｙのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＹ．Ｙ」）が表示されている。

また、その下には、メッセージングアプリケーション内での現在の位置やページ等を示す領域（以下、包括的に「アプリ内位置表示領域」と称する。）が構成されており、この例では、ホーム画面であることに基づいて、「ホーム」の文字が表示されている。

アプリ内位置表示領域の下には、災害が発生したことを報知するための災害情報を示す領域である災害情報表示領域が構成されており、この例では、地震が発生したことに基づいて、災害情報（限定ではなく例として、震源地を示す地図情報と、「災害発生」の文字と、「２０ＸＸ／０８／０４ ０９：３９発表」の文字と、「最大震度：５強」の文字と、「震源地：茨城県沖」の文字と、「マグニチュード：６．５」の文字）が表示されている。また、災害情報表示領域の内部の右下には、メッセージングアプリケーションのアカウントごとの安否登録（安否確認情報の登録）を行うための「安否登録」の文字を含むアイコンで示される安否登録ボタンＢＴ１が表示されている。

災害情報表示領域の下には、メッセージングアプリケーションにおける友だちやグループのリストが表示される友だち・グループリスト表示領域が構成されている。
この例では、友だち・グループリスト表示領域には、この端末２０のアカウント（この例では「ユーザＹ．Ｙ」）の友だちを一覧表示させるための友だちリストと、この端末２０のアカウントをメンバーとして含むグループを一覧表示させるためのグループリストとが表示されるように構成されている。この例では、限定ではなく例として、友だちリストがタップされて展開された状態で表示されている。

グループリストには、限定ではなく例として、「グループ」の文字と、ユーザＹ．Ｙが属するグループの数（本例では「８」）とが表示されている。
その下の友だちリストには、「友だち」の文字と、ユーザＹ．Ｙが友だちとして登録しているユーザ（アカウント）の数（本例では「４」）とが表示されている。

グループリストや友だちリストがユーザによってタップされると、それらのリストが展開され表示される。具体的には、限定ではなく例として、グループリストの下に、グループのアイコンと、グループ名と、そのグループに属するメンバー数とが、グループリストの項目として一覧表示される。また、限定ではなく例として、友だちリストの下に、友だちのアイコンと、ユーザ名とが、友だちリストの項目として一覧表示される。

この画面では、友だちリストの項目として、ユーザＸ．Ｘに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名等が一覧表示されている。

限定ではなく例として、安否登録ボタンＢＴ１がユーザによってタップされると、限定ではなく例として、図１－８中央のような表示がなされる。
このホーム画面では、図１－８左側のホーム画面に重畳して、自身の安否情報を登録（設定）するための安否登録領域Ｒ１がせり上がり表示されるように構成されている。

安否登録領域Ｒ１には、ユーザに安否情報を登録（設定）することを促す旨のメッセージ（本例では、「安否登録」の文字と、「みんなに安否を伝えよう」の文字）が表示されている。その下には、安否情報として安全であることを設定するための安全ボタンＳＢＴ（本例では、笑顔のアイコンと「安全」の文字とで示されるボタン）と、安否情報として安全でないことを設定するための危険ボタンＤＢＴ（本例では、笑顔でない顔のアイコンと「危険」の文字とで示されるボタン）と、選択した安否情報を設定するための登録ボタンＢＴ３とが表示されている。

限定ではなく例として、図１－８中央の安否登録領域Ｒ１において、危険ボタンＤＢＴがユーザによってタップされ、登録ボタンＢＴ３がユーザによってタップされたとする。
この場合、ユーザＹ．Ｙと友だちであるユーザＸ．Ｘの端末２０Ｘには、限定ではなく例として、図１－８右側に示すような画面が表示される。

図１－８右側には、端末２０Ｘの表示部２４に表示されるホーム画面の一例を示しており、友だちリストの項目として、ユーザＹ．Ｙに対応したアイコンおよびユーザ名、ユーザＡ．Ａに対応したアイコンおよびユーザ名、ユーザＢ．Ｂに対応したアイコンおよびユーザ名等が一覧表示されている。

この場合、上記のようにユーザＹ．Ｙが安否情報として「危険」を設定（登録）したことに基づいて、この例では、友だちリストのユーザＹ．Ｙのアイコンと関連付けて、危険であることを示すアイコンＤＩＣ１（本例では、笑顔でない顔のアイコン、以下、適宜「第１危険アイコン」と称する。）が重畳表示されている。

なお、ユーザＹ．Ｙが安否情報として「安全」を設定している場合、友だちリストのユーザＹ．Ｙのアイコンには、安全であることを示すアイコンＳＩＣ１（本例では、笑顔アイコン、以下、適宜「第１安全アイコン」と称する。）が重畳表示される。

友だちリストの各ユーザの項目に表示される＜危険であることを示す第１危険アイコンＤＩＣ１＞または＜安全であることを示す第１安全アイコンＳＩＣ１＞を確認することにより、端末２０ＸのユーザＸ．Ｘは、友だち登録しているユーザの安否情報を確認することができる。

図１－９左側は、図１－８中央の表示画面と同様のユーザＹ．Ｙの端末２０Ｙにおけるホーム画面の一例である。
本例では、図１－９左側の安否登録領域Ｒ１において、限定ではなく例として、危険ボタンＤＢＴがユーザによってタップされ、登録ボタンＢＴ３がユーザによってタップされると、ユーザＸ．Ｘの端末２０Ｘの表示部２４に、限定ではなく例として、図１－９中央に示すような画面が表示される。

この端末２０Ｘの表示部２４に表示されるホーム画面では、ユーザＹ．Ｙが安否情報として「危険」を設定したものの、図１－８右側に示した例とは異なり、友だちリストのユーザＹ．Ｙのアイコンに、危険であることを示すアイコンが重畳表示されていない。

限定ではなく例として、図１－９中央のホーム画面において、画面最下部のトークの項目がユーザによってタップされると、限定ではなく例として、図１－９右側のトークリスト画面に表示が遷移する。

トークリスト画面は、限定ではなく例として、この端末２０Ｘに対してメッセージが送信されたトークルームを一覧で確認可能とする画面とすることができる。
このトークリスト画面のアプリ内位置表示領域では、トークリスト画面であることに基づいて、「トーク」の文字と、前の画面に戻るための「＜」の文字で示される戻るボタンとが表示されている。

アプリ内位置表示領域の下には、この端末２０Ｘに対してメッセージが送信されたトークルームに関する情報が一覧表示されている。各々のトークルームと対応するトークルームリスト項目（トークリスト項目）には、そのトークルームのアイコン（以下、「トークルームアイコン」と称する。）と、トークルーム名と、そのトークルームがグループトークルームであった場合にはメンバー数とが関連付けて表示されている。
ここで、トークルームアイコンは、一対一トークルームの場合、限定ではなく例として、トーク相手のユーザのアイコンとすることができ、グループトークルームの場合、限定ではなく例として、グループに設定されたアイコン（グループアイコン）とすることができる。
また、トークルーム名は、一対一トークルームの場合、限定ではなく例として、トーク相手のユーザ名とすることができ、グループトークルームの場合、限定ではなく例として、グループ名とすることができる。

本例では、限定ではなく例として、トークルームリスト項目として、ユーザＹ．Ｙとのトークルームに対応したトークルームリスト項目（以下、「ユーザＹ．Ｙ」のトークルームリスト項目と称する。）と、ユーザＡ．Ａのトークルームリスト項目と、ユーザＢ．Ｂのトークルームリスト項目等とが表示されている。

この例では、各々のトークルームリスト項目には、限定ではなく例として、未読状態であるメッセージ数が関連付けて表示されるように構成されている。
限定ではなく例として、ユーザＹ．Ｙのトークルームにおいて、端末２０ＸのユーザＸ．Ｘが未読状態である（ユーザＸ．Ｘによって閲覧されていない）メッセージが１件あることに基づいて、ユーザＹ．Ｙのトークルームリスト項目には「１」の数字が関連付けて表示されている。

この場合、ユーザＹ．Ｙが安否情報として「危険」を設定していることに基づいて、トークリスト画面におけるユーザＹ．Ｙのトークルームリスト項目では、トークルームアイコンに＜危険であることを示すアイコンＤＩＣ２＞（本例では、「危険」の文字が示されているアイコン、以下、適宜「第２危険アイコン」と称する。）が重畳表示されている。

なお、ユーザＹ．Ｙが安否情報として「安全」を設定している場合、トークリスト画面におけるユーザＹ．Ｙのトークルームリスト項目では、トークルームアイコンに＜安全であることを示すアイコンＳＩＣ２＞（本例では、「安全」の文字が示されているアイコン、以下、適宜「第２安全アイコン」と称する。）が重畳表示される。

トークリストの各トークルームリスト項目に表示される＜危険であることを示すアイコン＞または＜安全であることを示すアイコン＞を確認することにより、端末２０ＸのユーザＸ．Ｘは、メッセージを端末２０Ｘに対して送信したユーザの安否情報を確認することができる。

なお、トークルームアイコンに第２安全アイコンＳＩＣ２や第２危険アイコンＤＩＣ２を表示させるのではなく、「安全」の場合は「青色」のアイコンを表示させ、「危険」の場合は「赤色」のアイコンを表示させるなどしてもよい。また、トークルームの名称を示す文字の色や書体を変えて表示させるなどしてもよい。
なお、これらの表示態様の変更の手法は、友だちリストやグループリストにも同様に適用可能である。

図１－１０左側には、ユーザＸ．Ｘの端末２０Ｘのトークリスト画面が表示されている。このトークリスト画面は、図１－９右側で示したトークリスト画面とは異なり、ユーザＹ．Ｙが安否情報として「危険」を設定しているものの、トークリスト画面におけるユーザＹ．Ｙのトークルームリスト項目では、トークルームアイコンに第２危険アイコンＤＩＣ２が重畳表示されていない。

限定ではなく例として、図１－１０左側のトークリスト画面において、ユーザＹ．Ｙに対応したトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図１－１０中央のトークルーム画面が表示される。
このトークルーム画面には、画面最上部のメッセージングアプリケーションの名称等が表示される領域の下に、限定ではなく例として、メッセージングアプリケーション内のいずれのページ（この例では、トークルーム）が現在表示されているかを示す領域の一種として、トークルームの名称（以下、「トークルーム名」と称する。）を含むトークルーム名表示領域が設けられている。トークルーム名表示領域は、現在ユーザが位置しているメッセージングアプリケーション内のページ（この例では、トークルーム）を示す領域とも言える。

本例では、トークルーム名表示領域には、限定ではなく例として、前の画面に戻るための「＜」の戻るボタンと、ユーザＸ．ＸがユーザＹ．Ｙを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｙ．Ｙ」）と、このトークルームに属するユーザの安否情報を表示するための安否情報表示アイコンＩＣ１とが表示されている。
また、その下には、ユーザＸ．ＸとユーザＹ．Ｙとが対話形式でトークを行うためのトーク領域が構成されており、画面向かって左側には相手であるユーザＹ．Ｙのメッセージが、画面向かって右側には自分であるユーザＸ．Ｘのメッセージが表示されるように構成されている。

トーク領域の上部には、限定ではなく例として、ユーザＹ．Ｙが設定した安否情報をトークルーム内で報知するためのトークルーム内安否情報（本例では、「Ｙ．Ｙさんが安否確認に回答しました」の文字と、端末のユーザのアイコンと安否に関する情報とを含むユーザ状態アイコンＩＣＹＤ（ユーザＹ．Ｙのアイコン、「危険」の文字、笑顔でないアイコン））が表示されている。以下、ユーザ状態アイコンを、適宜「ユーザ状態アイコン（ユーザ名（のアイコン）、安全または危険（に対応した文字および顔のアイコン））」と称する。

なお、この表示画面例では、ユーザ状態アイコンを、そのユーザのアイコンと、安否ステータス情報に対応する文字（安全／危険）と、安否ステータス情報に対応するアイコンとを組み合わせたアイコンとしているが、これに限定されない。
限定ではなく例として、そのユーザのアイコンと、安否ステータス情報に対応する文字（安全／危険）とを組み合わせたアイコンとしたり、そのユーザのアイコンと、安否ステータス情報に対応するアイコンとを組み合わせたアイコンとするなどしてもよい。

限定ではなく例として、図１－１０中央のトークルーム画面において、安否情報表示アイコンＩＣ１がユーザによってタップされると、限定ではなく例として、図１－１０右側に示すように、トークルーム名表示領域の下に展開する形式で、このトークルームに含まれる各々のユーザの安否情報を表示するためのユーザ別安否情報が表示される。
この例では、トークルームに属するユーザの安否情報を含むユーザ別安否情報を表示するためのユーザ別安否情報表示領域が構成されており、本例では、安否情報表示アイコンＩＣ１とともに、ユーザ別安否情報として、第２危険アイコンＤＩＣ２が重畳表示されたユーザＹ．Ｙのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＸ．Ｘのアイコンとが表示されている。

＜処理＞
図１－１１は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

なお、以下説明する処理は、本開示の手法を実現するための処理の一例に過ぎず、これらに限定されるものではない。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略（削除）してもよい。

ここでは、表示画面と同様に、
・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
・安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
とする場合の処理を例示する。

最初に、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１と、サーバ１０の制御部１１とは、限定ではなく例として、チャット処理を実行する（Ｘ１１０、Ｙ１１０、Ｓ１１０）。
チャット処理では、限定ではなく例として、各端末２０の入出力部２３に対する入力（限定ではなく例として、ユーザ入力（ユーザによる操作入力や音入力等）以下同様。）に基づいて、各端末２０の制御部２１は、メッセージングサービスにおけるコンテンツの送受信処理と表示処理とを実行する。また、サーバ１０の制御部１１は、限定ではなく例として、各端末２０から送信されたコンテンツの中継処理を実行する。

なお、チャット処理は、処理中の任意のステップ間で実行されるようにしてもよい。また、本システムにおいて、チャット処理は実行されなくてもよい。

次いで、サーバ１０の制御部１１は、限定ではなく例として、サーバ１０の入出力部１２に対する入力（限定ではなく例として、ユーザ入力（サーバ１０のユーザによる操作入力や音入力等））に基づいて、災害が発生したことと、この災害における各端末２０のユーザの安否登録を依頼することとを含む災害情報を、通信Ｉ／Ｆ１４によって各端末２０に送信する（Ｓ１２０）。

ここで、災害情報は、限定ではなく例として、以下の災害要素Ａ～災害要素Ｈの任意の組み合わせと、ユーザに安否登録を依頼することとを含むように構成するようにしてもよい。
・災害要素Ａ：災害が発生したこと。
・災害要素Ｂ：災害の種類（限定ではなく例として、地震や洪水、大規模火災等）。
・災害要素Ｃ：災害の規模（限定ではなく例として、震度やマグニチュード、河川水位、延焼範囲等）。
・災害要素Ｄ：災害の発生日時。
・災害要素Ｅ：災害の発生場所。
・災害要素Ｆ：災害による副次的な影響（限定ではなく例として、停電や断水の状況や交通機関の運行状況等）。
・災害要素Ｇ：災害に対する対処方法（限定ではなく例として、避難場所や避難経路等）。
・災害要素Ｈ：その他災害に関連する情報。
なお、災害情報に、その災害における安否登録の期間や期限に関する情報を含めるようにしてもよい。

なお、サーバ１０の制御部１１は、任意の災害が発生した場合、不図示の災害情報提供サーバから発生した災害に関する情報である災害状況情報（限定ではなく例として、上記の災害要素Ａ～Ｄにより構成される情報）を受信する。すると、サーバ１０の制御部１１は、災害状況情報に基づいて、発生した災害が所定の規模（限定ではなく例として、最大震度５や、大雨）より大きい、または所定の規模以上であると判定する場合、自動的に災害情報を各端末２０に送信するようにしてもよい。

また、サーバ１０の制御部１１は、任意の災害が発生した場合、災害情報提供サーバから災害状況情報を受信すると、表示部１３に災害情報を送信するか否かの選択用表示画面を表示させるようにしてもよい。そして、サーバ１０の制御部１１は、選択用表示画面に対するユーザ入力に基づいて、災害情報を各端末２０に送信するようにしてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から災害情報を受信すると、各端末２０の制御部２１は、受信した災害情報を表示部２４に表示させる（Ｘ１２０、Ｙ１２０）。

限定ではなく例として、安否登録アカウントの端末２０Ｙの入出力部２３に対する入力に基づいて、安否確認情報が入力されると、端末２０Ｙの制御部２１は、限定ではなく例として、入力された安否確認情報と、安否登録アカウントのアプリケーションＩＤとを含む安否確認登録情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｙ１４０）。

通信Ｉ／Ｆ１４によって安否登録アカウントの端末２０Ｙから安否確認登録情報を受信すると、サーバ１０の制御部１１は、受信した安否確認登録情報に基づいて、安否情報を生成する。
安否情報には、限定ではなく例として、安否確認登録情報において送信された安否登録アカウントのアプリケーションＩＤと、安否確認情報とを含めることができる。

なお、サーバ１０の制御部１１は、安否情報に、安否確認登録情報において送信された安否登録アカウントのアプリケーションＩＤに紐付けられたユーザ名を含めるようにしてもよい。また、サーバ１０の制御部１１は、安否情報に、安否確認登録情報において送信された安否確認情報における安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせのうち、任意の情報の組み合わせのみ（限定ではなく例として、安否ステータス情報と安否位置情報とが安否確認情報に含まれる場合、安否ステータス情報のみ）を含めるようにしてもよい。

すると、サーバ１０の制御部１１は、限定ではなく例として、アカウント管理データベース１５５Ａを検索し、安否登録アカウントの友だち管理データに友だち登録されているアカウントを参照する。そして、友だち登録されている各アカウントの端末２０に対して通信Ｉ／Ｆ１４によって安否情報を送信する（Ｓ１４０）。

なお、サーバ１０の制御部１１は、Ｓ１４０のステップにおいて全ての端末２０に安否情報を送信するようにしてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から安否情報を受信すると、端末２０Ｘの制御部２１は、受信した安否情報を表示部２４に表示させる（Ｘ１６０）。
なお、安否参照アカウントの端末２０において、安否情報を表示部２４に表示させる判定条件としては、限定ではなく例として、以下の場合における任意の組み合わせが挙げられる。
・無条件に表示（プッシュ通知等）
・友だちリスト（グループリスト）の閲覧を行うと安否登録アカウントと関連付けて表示
・トークリストの閲覧を行うと安否登録アカウントと関連付けて表示
・安否参照アカウントと安否登録アカウントとの一対一トークルームの閲覧を行うと表示
・安否登録アカウントを含むグループのグループトークルームの閲覧を行うと表示

また、Ｓ１４０のステップにおいて、サーバ１０が全ての端末２０に安否情報を送信する場合、安否参照アカウントの端末２０の制御部２１は、限定ではなく例として、記憶部２８に記憶される友だち管理データを参照する。そして、友だち管理データに安否登録アカウントのアプリケーションＩＤが含まれる場合、安否情報を表示部２４に表示させるようにしてもよい。

＜第１実施例の効果＞
本実施例は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）とのトーク（限定ではなく、チャットの一例）に関連する処理（限定ではなく、チャットに関連する処理の一例）を行う安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）の端末２０は、安否登録アカウントのユーザによる自己の端末２０に対する入力に基づいて、安否情報（または安否確認登録情報）（限定ではなく、第１端末のユーザの安否に関する第１情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、安否参照アカウントのユーザの端末２０は、安否登録アカウントのユーザに関連するトークの情報（限定ではなく、チャットの情報の一例）に関連付けられた安否情報を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信した上で、第１端末のユーザに関連するチャットの情報に関連付けられた第１情報を端末の表示部に表示して、端末のユーザに知らせることができる。チャットの情報に関連付けられた形で端末のユーザにとって分かり易い表示を実現することができる。

なお、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信することには、限定ではなく例として、第１端末から第１情報がサーバに送信され、サーバが第１情報を受信したことに基づいて、サーバから端末に第１情報が送信されて端末が第１情報を受信することと、サーバを介さずに第１端末から端末に第１情報が直接的に送信され、それを端末が受信することとを含めることができる。

また、チャットに関連する処理とは、限定ではなく例として、チャットを行うための情報を送受信する処理や、チャットに関連するコンテンツを表示する処理などの、チャットを行うための各種の処理やチャットを実現するための各種の処理等を含む概念とすることができる。
また、チャットの情報とは、メッセージングアプリケーションでは、限定ではなく例として、前述した（Ｂ１）～（Ｂ３）に対応する「友だちリスト」、「トークリスト」、「トークルーム」等を含む概念とすることができる。なお、前述した「フォロー」、「フォロワー」等についても同様である。

また、この場合、安否参照アカウントのユーザの端末２０は、安否情報（または安否確認登録情報）を、サーバ１０を介して通信Ｉ／Ｆ２２によって受信するようにすることができる。
このような構成により得られる実施例の効果の一例として、サーバを介して、第１情報を適切に受信することができる。

また、この場合、上記のトークの情報（限定ではなく、チャットの情報の一例）は、メッセージングアプリケーションにおけるトーク（限定ではなく、チャットの一例）で、安否参照アカウントのユーザに関連付けられたユーザのリスト（限定ではなく、ユーザのリストの一例）に含まれるようにすることができる。
このような構成により得られる実施例の効果の一例として、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信した上で、端末のユーザに関連付けられたユーザのリストに含まれるチャットの情報に関連付けられた第１情報を端末の表示部に表示して、端末のユーザに知らせることができる。

また、この場合、上記のトークの情報（限定ではなく、チャットの情報の一例）は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）とを含むトークルーム（限定ではなく、第１チャットルームの一例）に関する情報を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信した上で、第１端末のユーザと端末のユーザとを含む第１チャットルームに関する情報に関連付けられた第１情報を端末の表示部に表示して、端末のユーザに知らせることができる。第１端末のユーザと端末のユーザとを含む第１チャットルームに関する情報に関連付けられた形で端末のユーザにとって分かり易い表示を実現することができる。

また、この場合、上記のトークの情報は、安否参照アカウントのユーザが含まれるトークルームのトークリスト（限定ではなく、チャットルームのリストの一例）に含まれる一対一トークルーム（トーク相手）のアイコン画像等の情報（限定ではなく、端末のユーザが含まれるチャットルームのリストに含まれる第１チャットルームに関する情報の一例）や、安否参照アカウントのユーザが含まれるグループトークルームのグループリストに含まれるグループトークルーム（グループ）のアイコン画像等の情報（限定ではなく、端末のユーザが含まれるチャットルームのリストに含まれる第１チャットルームに関する情報の一例）を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１端末のユーザによる第１端末に対する入力に基づいて、第１端末のユーザの安否に関する第１情報を受信した上で、端末のユーザが含まれるチャットルームのリストに含まれる第１チャットルームに関する情報に関連付けられた第１情報を端末の表示部に表示して、端末のユーザに知らせることができる。

また、この場合、安否参照アカウントのユーザの端末２０は、安否情報に基づいて、上記のアイコン画像等の表示態様を変更する制御を制御部２１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、第１情報に基づいて、第１端末のユーザと端末のユーザとを含む第１チャットルームに関する情報の表示態様を変更することで、端末のユーザにとって分かり易い表示を実現することができる。

また、この場合、安否情報（限定ではなく、第１情報の一例）は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）とを含むトークルーム（限定ではなく、第１チャットルームの一例）に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第１端末のユーザと端末のユーザとを含む第１チャットルームへの第１情報の表示という分かり易い形で、第１端末のユーザの安否を端末のユーザに知らせることができる。

また、この場合、安否情報（限定ではなく、第１情報の一例）は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）によって設定された自身のアイコン画像等の画像（限定ではなく、第１画像の一例）と関連付けられて、上記のトークルームに表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第１端末のユーザによって設定された第１画像と関連づけられて第１チャットルームに第１情報が表示されるため、第１端末のユーザの安否に関する情報であることを端末のユーザが認識し易くなるようにすることができる。

＜第１変形例（１）＞
上記の実施例では、安否確認情報として、安否ステータス情報のみを登録する例について例示したが、これに限定されない。また、上記の実施例では、安否登録アカウントと安否参照アカウントとが異なる例について例示したが、これに限定されない。

図１－１２左側は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示されるホーム画面の一例を示している。
このホーム画面では、図１－８左側に示したユーザＹ．Ｙの端末２０Ｙのホーム画面とは異なり、画面最上部の右側には、この端末２０ＡのユーザＡ．Ａのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「Ａ．Ａ」）が表示されている。

グループリストには、グループリストの項目として、テニスサークルに対応したアイコンおよびグループ名（メンバー数）、ゼミ仲間に対応したアイコンおよびグループ名（メンバー数）等が一覧表示されている。
また、友だちリストには、友だちリストの項目として、ユーザＢ．Ｂに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名等が一覧表示されている。

限定ではなく例として、安否登録ボタンＢＴ１がユーザによってタップされると、限定ではなく例として、図１－１２中央のような表示がなされる。
この例では、安否登録領域Ｒ１における安全ボタンＳＢＴおよび危険ボタンＤＢＴの下に、安否コメント情報の一種である安否メッセージを入力するための安否メッセージ入力領域が構成されている。

安否メッセージ入力領域には、「安否メッセージ」の文字とともに、安否メッセージを入力するための領域（入力された安否メッセージが表示される領域）が構成されている。
また、その下には、安否メッセージの定型文を選択するための領域が構成されている。この例では、安否メッセージの定型文として、限定ではなく例として、「怪我をした」のテキストと、「閉じ込められた」のテキストと、「火災に巻き込まれた」のテキストと、「避難中」のテキストとがあらかじめ用意されており、各々がタップによって選択可能なアイコンとして表示されている。

また、その下には、安否位置情報の一種である現在の居場所を入力するための現在地入力領域が構成されている。現在地入力領域には、「現在の居場所」の文字と、現在の居場所を入力するための領域（入力された現在の居場所を表示する領域）と、現在地を取得するための現在地取得ボタンとが表示されている。

そして、画面の最下部には、選択／入力した安否情報を設定するための登録ボタンＢＴ３が設けられている。

なお、安否コメント情報と安否位置情報とのいずれか一方のみを登録するように安否登録領域Ｒ１を構成してもよい。

限定ではなく例として、図１－１２中央の安否登録領域Ｒ１において、安全ボタンＳＢＴがユーザＡ．Ａによってタップされた後、登録ボタンＢＴ３がユーザＡ．Ａによってタップされた場合における、ユーザＡ．Ａの端末２０Ａに表示されるホーム画面の一例を図１－１２右側に示す。

災害情報表示領域では、安否登録ボタンＢＴ１の表示が消去され、これに代えて、ユーザ状態アイコンが表示されている。本例では、ユーザＡ．Ａの状態を示すユーザ状態アイコンＩＣＡＳ（この例では、ユーザＡ．Ａ、安全）が表示されている。

また、ユーザＢ．Ｂが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＢ．Ｂに対応したアイコンには、第１危険アイコンＤＩＣ１が重畳表示されている。ユーザＣ．Ｃが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＣ．Ｃに対応したアイコンには、第１危険アイコンＤＩＣ１が重畳表示されている。ユーザＤ．Ｄが安否情報として「安全」を設定していることに基づいて、ユーザＤ．Ｄに対応したアイコンに、第１安全アイコンＳＩＣ１が重畳表示されている。

図１－１３左側は、ユーザＡ．Ａの端末２０Ａのトークリスト画面が表示されている。このトークリスト画面は、図１－９右側のトークリスト画面とは異なり、アプリ内位置表示領域の下であって、この端末２０Ａに対してメッセージが送信されたトークルームに関する情報が一覧表示されている領域の上には、災害が発生したことをトークリスト画面において報知するための第２災害情報を示す領域である第２災害情報表示領域が構成されている。そして、この例では、地震が発生したことに基づいて、第２災害情報（限定ではなく例として、「２０ＸＸ／０８／０４ ０９：３９発表」の文字と、「最大震度：５強」の文字と、「地震発生」の文字とが表示されている。また、ユーザＡ．Ａが、自身は「安全」であることを設定したことに基づき、その旨を示すユーザ状態アイコンＩＣＡＳ（ユーザＡ．Ａ、安全））が第２災害情報表示領域に表示されている。

本例では、限定ではなく例として、トークルームリスト項目として、テニスサークルのトークルームリスト項目、ユーザＤ．Ｄのトークルームリスト項目、ユーザＢ．Ｂのトークルームリスト項目、ゼミ仲間のトークルームリスト項目、ユーザＣ．Ｃのトークルームリスト項目、ユーザＥ．Ｅのトークルームリスト項目等が表示されている。

本例では、テニスサークルのトークルームリスト項目に関連付けて未読数「１３」の数字が表示され、ユーザＤ．Ｄのトークルームリスト項目に関連付けて未読数「２」の数字が表示され、ユーザＢ．Ｂのトークルームリスト項目に関連付けて未読数「１」の数字が表示され、ゼミ仲間のトークルームリスト項目に関連付けて未読数「２」の数字が表示され、ユーザＣ．Ｃのトークルームリスト項目に関連付けて未読数「２」の数字が表示され、ユーザＥ．Ｅのトークルームリスト項目に関連付けて未読数「１」の数字が表示されている。

また、ユーザＤ．Ｄが安否情報として「安全」を設定していることに基づいて、ユーザＤ．Ｄのトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。ユーザＢ．Ｂが安否情報として「危険」を設定していることに基づいて、ユーザＢ．Ｂのトークルームリスト項目に対応したアイコンには、第２危険アイコンＤＩＣ２が重畳表示されている。ユーザＣ．Ｃが安否情報として「危険」を設定していることに基づいて、ユーザＣ．Ｃのトークルームリスト項目に対応したアイコンには、第２危険アイコンＤＩＣ２が重畳表示されている。ユーザＥ．Ｅが安否情報として「安全」を設定していることに基づいて、ユーザＥ．Ｅのトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。

本例では、グループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、グループトークルームに対応したアイコンには、安否情報に基づくアイコンが重畳表示されていない。
この場合、テニスサークルのグループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、テニスサークルのトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２および第２危険アイコンＤＩＣ２のいずれも重畳表示されていない。ゼミ仲間のグループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、ゼミ仲間のトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２および第２危険アイコンＤＩＣ２のいずれも重畳表示されていない。

また、このトークリスト画面において、トークルームリスト項目に対応したユーザ名の下には、そのユーザによって、前述した現在地入力領域に入力されて登録された安否位置情報と、前述した安否メッセージ入力領域に入力されて登録された安否コメント情報とに基づく情報が表示されている。
この例では、限定ではなく例として、ユーザＢ．Ｂに対応する「Ｂ．Ｂ」の文字の下に、ユーザＢ．Ｂによって登録された現在地「つくば市」と、ユーザＢ．Ｂによって登録された安否メッセージ「怪我しちゃった」とを複合した（組み合わせた）情報として複合安否情報「つくば／怪我しちゃった」が表示されている。
ユーザＣ．ＣやユーザＥ．Ｅについても、登録された情報が同様に表示されている。

なお、この表示画面例では、トークルームリスト項目のユーザ名の下に複合安否情報を表示させているが、これに限定されない。
限定ではなく例として、ユーザ名の右に複合安否情報を表示させるようにしてもよい。また、この場合、トークルームリスト項目のユーザ名の下には、そのトークルームにおける最新のコンテンツ（メッセージ）に基づく情報を表示させるようにしてもよいし、表示させなくてもよい。

また、限定ではなく例として、ユーザのアイコンに重畳して表示される安否ステータス情報に基づくアイコン（第２安全アイコンＳＩＣ２または第２危険アイコンＤＩＣ２がタップされたことに基づいて、吹き出しやバブル等によって複合安否情報が表示されるようにしてもよい。

また、安否位置情報と安否コメント情報との両方をトークリストに表示させることは必須ではなく、これらを別の画面に表示させてもよい。

また、複合安否情報を、前述した友だちリストが表示される画面（ホーム画面等）に表示させるようにしてもよい。
また、安否位置情報と安否コメント情報とのいずれか一方の情報を、前述した友だちリストが表示される画面（ホーム画面等）に表示させるようにしてもよい。

限定ではなく例として、図１－１３左側のトークリスト画面において、ユーザＢ．Ｂのトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図１－１３右側のトークルーム画面が表示される。この画面は、図１－１０中央で示したトークルーム画面とは異なり、トーク領域にトークルーム内安否情報が表示されていない一方で、ユーザ別安否情報表示領域にユーザ別安否情報が表示されている。

本例では、トークルーム名表示領域には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｂ．Ｂ」）が表示されている。
また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第２危険アイコンＤＩＣ２が重畳表示されたユーザＢ．Ｂのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＡ．Ａのアイコンとが表示されている。

また、ユーザＢ．Ｂから発信されたテキストコンテンツとして、地震で足を怪我してしまい動けなくなっていることを伝えるテキストコンテンツが、トーク領域の左側に表示されている。

図１－１４は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

ここでは、表示画面とは異なり、
・安否登録アカウント 兼 安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（表示画面における端末２０ＡのユーザＡ．Ａ）
・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（表示画面における端末２０Ｂ～端末２０Ｅのユーザ）
とする場合の処理を例示する。

端末２０Ｘの制御部２１は、限定ではなく例として、災害情報を表示部２４に表示させると（Ｘ１２０）、限定ではなく例として、安否登録アカウントの端末２０Ｘの入出力部２３に対する入力に基づいて、安否確認情報を入力するか否かを判定する（Ｘ１３０）。安否確認情報を入力すると判定された場合（Ｘ１３０：ＹＥＳ）、端末２０Ｘの制御部２１は、安否確認情報を受け付け、安否確認登録情報をサーバ１０に送信する（Ｘ１４０）。安否確認情報を入力しないと判定された場合（Ｘ１３０：ＮＯ）、端末２０Ｘの制御部２１は、Ｘ１４０のステップをスキップする。

端末２０Ｙの制御部２１においても同様に、Ｙ１１０～Ｙ１４０の各ステップを実行する。

通信Ｉ／Ｆ１４によって端末２０Ｘから安否確認登録情報を受信する場合（Ｓ１３０）、サーバ１０の制御部１１は、受信した安否確認登録情報に基づいて、安否情報を生成し、各端末２０に送信する（Ｓ１４０）。他の端末（限定ではなく例として、端末２０Ｙ）から安否確認登録情報を受信する場合についても同様である。

通信Ｉ／Ｆ２２によってサーバ１０から安否情報を受信したと判定される場合（Ｘ１５０：ＹＥＳ）、端末２０Ｘの制御部２１は、受信した安否情報を表示部２４に表示させる（Ｘ１６０）。
なお、複数回安否情報を受信したと判定される場合、端末２０Ｘの制御部２１は受信するたびに受信した安否情報を表示部２４に表示させるようにしてもよいし、安否登録アカウントが異なる場合のみ受信した安否情報を表示部２４に表示させるようにしてもよい。

端末２０Ｙの制御部２１においても同様に、Ｙ１５０～Ｙ１６０の各ステップを実行する。

本変形例は、安否参照アカウントのユーザの端末２０が、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて、自己の端末２０のユーザの安否に関する安否情報（または安否確認登録情報）（限定ではなく、端末のユーザの安否に関する第３情報の一例）を通信Ｉ／Ｆ１２２によって送信する構成を示している。
このような構成により得られる変形例の効果の一例として、端末のユーザによる端末に対する入力に基づいて、端末のユーザの安否に関する第３情報を送信して、端末のユーザの安否を他者に知らせることができる。

＜第１変形例（２）＞
上記の実施例では、安否情報をユーザアカウントと関連付けて表示させる例について例示したが、これに限定されない。限定ではなく例として、安否情報を安否登録アカウントが属するグループアカウントと関連付けて表示させるようにしてもよい。

図１－１５は、本変形例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５とに加えて、グループ管理データベース１５７が記憶される。

グループ管理データベース１５７は、グループに関する情報を管理するためのデータベースであり、その一例であるグループ管理データベース１５７のデータ構成例を図１－１６に示す。
グループ管理データベース１５７には、グループごとの管理データとして、グループ管理データが記憶される。

各々のグループ管理データには、限定ではなく例として、グループＩＤと、グループ名と、グループメンバーデータとが記憶される。

グループＩＤは、グループ管理データで管理されるグループを識別するための情報である。
このグループＩＤは、好ましくはグループごとに一意な値であり、限定ではなく例として、サーバ１０によってグループごとに一意な値（固有の値）が設定されて記憶される。

グループ名は、このグループの名称であり、限定ではなく例として、端末２０のユーザがグループを作成する際に登録する名称が記憶される。

グループメンバーデータは、このグループのメンバーである（グループに属する）アカウントのアプリケーションＩＤを記憶させるためのデータであり、限定ではなく例として、ユーザがグループ参加登録を行うと、サーバによってグループ参加登録を行ったユーザのアプリケーションＩＤが追加され更新される。

なお、グループ管理データに、グループの代表であるアカウントのアプリケーションＩＤを関連付けて記憶させるようにしてもよい。

図１－１７左側は、ユーザＡ．Ａの端末２０Ａのトークリスト画面が表示されている。このトークリスト画面では、図１－１３左側の表示画面から、Ｂ．Ｂとのトークルームが閲覧されたことに基づいて、Ｂ．Ｂとの間でのメッセージ未読数が「０」（非表示）となっている。

限定ではなく例として、図１－１７左側のトークリスト画面において、ゼミ仲間のトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図１－１７右側のトークルーム画面が表示される。
この画面は、図１－１３右側の表示画面と異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＡ．Ａがゼミ仲間のグループを相手としてトークを行うためのトークルームであることを示す文字（本例では「ゼミ仲間（４）」（数字はメンバー数））が表示されている。

ユーザ別安否情報表示領域には、ユーザ別安否情報として、第２危険アイコンＤＩＣ２が重畳表示されたユーザＢ．Ｂのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＡ．Ａのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＤ．Ｄのアイコンと、第２危険アイコンＤＩＣ２が重畳表示されたユーザＦ．Ｆのアイコンとが表示されている。

また、トーク領域には、ユーザＤ．Ｄから送信されたコンテンツとして、ユーザＢ．Ｂが今日つくばで学会発表する予定であることを確認するテキストコンテンツが表示され、その下には、ユーザＦ．Ｆから送信されたコンテンツとして、つくばで震度５弱の地震が発生したことでユーザＢ．Ｂを心配するテキストコンテンツが表示されている。

図１－１８左側には、ユーザＡ．Ａの端末２０Ａのトークリスト画面を示している。
このトークリスト画面は、図１－１３左側のトークリスト画面とは異なり、グループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合に、グループトークルームに対応したアイコンに、安否情報に基づく画像（アイコン等）が関連付けて表示される一例を示す図である。

本例では、グループトークルームに属するメンバーが安否情報の設定を行っている場合に、グループトークルームに対応したアイコンに、安否情報に基づくエフェクト安否情報が付加表示される。
限定ではなく例として、グループトークルームに属する全てのメンバーの安否情報が「安全」を設定している場合、第１エフェクト情報ＳＦＡ（限定ではなく例として、白色のオブジェクト）がグループトークルームに対応したアイコンに付加表示される。
限定ではなく例として、グループトークルームに属する１名以上のメンバーの安否情報が「危険」を設定している場合、第２エフェクト情報ＤＦＡ（限定ではなく例として、赤色のオブジェクト）がグループトークルームに対応したアイコンに付加表示される。

この例では、テニスサークルのグループトークルームに属するメンバー全員が、安否情報として「安全」を設定していることに基づいて、テニスサークルのグループトークルームに対応したアイコンに、第１エフェクト情報ＳＦＡが付加表示されている。
また、この例では、ゼミ仲間のグループトークルームに属するメンバーのうち１名が、安否情報として「危険」を設定していることに基づいて、ゼミ仲間のグループトークルームに対応したアイコンに、第２エフェクト情報ＤＦＡが付加表示されている。

限定ではなく例として、図１－１８左側のトークルームリスト画面において、ゼミ仲間のトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図１－１８右側のトークルーム画面が表示される。
この画面は、図１－１７右側のトークルーム画面と同様であるので説明を省略する。

なお、表示態様を変更する手法は上記に限られない。
限定ではなく例として、グループトークルームに属する全てのメンバーの安否情報が「安全」を設定している場合は「青色」でグループトークルームに対応したアイコンを表示させ、グループトークルームに属する１名以上のメンバーの安否情報が「危険」を設定している場合は「赤色」でグループトークルームに対応したアイコンを表示させるなどしてもよい。
さらに細分化して、グループトークルームに属するメンバーのうちの「危険」を設定している人数（または割合）に基づいて、「黄色」、「赤色」でグループトークルームに対応したアイコンを表示させたり、上記のエフェクト表示を行うようにしてもよい。
また、これらに限定されるわけではなく、グループトークルームの名称を示す文字の色や書体を変えて表示させるなどしてもよい。

トークリスト内に表示させる場合、限定ではなく例として、サーバ１０の制御部１１は、安否確認登録情報を受信すると、グループ管理データベース１５７を参照し、安否登録アカウントが属するグループを検索する。そして、安否登録アカウントが属する各々のグループについて、グループメンバーデータに登録されている各アプリケーションＩＤの安否登録データを参照する。
あるグループメンバーデータに登録されている全てのアプリケーションＩＤの安否登録データが「安全」である場合、サーバ１０の制御部１１は、そのグループに対する安否情報（以下、「グループ安否情報」と称する。）をメンバー全員が「安全」であることを示す第１態様で生成する。全てのアプリケーションＩＤの安否登録データが「安全」でない場合には、サーバ１０の制御部１１は、そのグループに対するグループ安否情報をメンバー全員が「安全」ではないことを示す第２態様で生成する。
そして、サーバ１０の制御部１１は、グループ安否情報を通信Ｉ／Ｆ１４によってそのグループメンバーデータに登録されている全てのアカウントの端末２０に送信する。

上記の実施例および本変形例は、安否参照アカウントのユーザの端末２０は、安否情報を含む、一対一トークルームやグループトークルーム等のトークルーム（限定ではなく、第１チャットルームの一例）に含まれるユーザの安否に関する情報に基づいて、そのトークルームに関する情報の表示態様を変更する制御を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として。第１情報を含む、第１端末のユーザと端末のユーザとを含む第１チャットルームに含まれるユーザの安否に関する情報に基づいて、第１チャットルームに関する情報の表示態様を適切に変更することができる。

＜第１変形例（３）＞
上記の実施例では、安否ステータス情報を「安全」と「危険」の２クラスとしたが、これに限定されない。他の安否ステータス情報を含めるようにしてもよい。
限定ではなく例として、安否情報を「安全」と「危険」と「エリア外」の３クラスで設定可能であるようにしてもよい。

図１－１９左側は、ユーザＡ．Ａの端末２０Ａのホーム画面が表示されている。この画面は、図１－１２中央のホーム画面とは異なり、安否登録領域Ｒ１において、安否情報として安全であることを設定するための安全ボタンＳＢＴと、安否情報として安全でないことを設定するための危険ボタンＤＢＴとに加えて、安否情報としてエリア外であることを設定するためのエリア外ボタンＡＢＴ（本例では、「エリア外」の文字で示されるボタン）が表示される一例を示す図である。

「エリア外」である場合とは、限定ではなく例として、現在発生している災害の影響を受けない位置にユーザが位置している場合であり、限定ではなく例として、災害が地震である場合、ユーザの端末２０が示す現在地が震源地から設定距離（限定ではなく例として２００ｋｍ）以上離れた位置に位置している場合等である。

限定ではなく例として、図１－１９左側の安否登録領域Ｒ１において、安全ボタンＳＢＴがユーザＡ．Ａによってタップされた後、登録ボタンＢＴ３がユーザＡ．Ａによってタップされ、ホーム画面に表示が遷移する（不図示）。そして、このホーム画面において、画面最下部のトークの項目がユーザによってタップされると、限定ではなく例として、図１－１９右側に示すトークリスト画面が端末２０Ａの表示部２４に表示される。

このトークリスト画面では、図１－１３左側のトークリスト画面とは異なり、ユーザＥ．Ｅが安否情報として「エリア外」を設定していることに基づいて、ユーザＥ．Ｅに対応したアイコンに、エリア外であることを示すエリア外アイコンＡＩＣ（本例では、「エリア外」の文字を含むアイコン）が重畳表示されている。

なお、これら以外にも、限定ではなく例として、元気であることを示す「元気」、少し元気であることを示す「少し元気」、あまり元気ではないことを示す「あまり元気ない」、元気がないことを示す「元気ない」等の情報を安否ステータス情報に含めるようにしてもよい。

＜第１変形例（４）＞
上記の実施例では、サーバ１０において、安否確認登録情報に基づく安否情報を生成したが、これに限定されない。限定ではなく例として、端末２０において安否情報を生成するようにしてもよい。

この場合、限定ではなく例として、安否登録アカウントの端末２０Ｙの制御部２１は、安否確認登録情報を受け付けると、安否情報を生成する。すると、安否登録アカウントの端末２０Ｙの制御部２１は、安否登録アカウントの友だち管理データを参照し、限定ではなく例として、安否登録アカウントと友だち登録済みであるアカウントの各端末２０に安否情報を送信する。

なお、安否登録アカウントの端末２０Ｙの制御部２１は、限定ではなく例として、サーバ１０を介して安否情報を各端末２０に送信するようにしてもよい。また、安否登録アカウントの端末２０Ｙの制御部２１は、限定ではなく例として、ブロードキャスト通信を利用して、全ての端末２０に安否情報を送信するようにしてもよい。

＜第２実施例＞
第１実施例では、安否登録アカウントの端末２０において、一度だけ安否登録を行う例を例示した。第２実施例は、安否登録アカウントの端末２０のユーザが繰り返し安否登録を行うことで、安否参照アカウントの端末２０において安否情報が更新される実施例である。

第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
本実施例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。また、安否参照アカウントの端末２０において、安否情報をトークルーム内にのみ表示する場合について例示する。

図２－１左側のホーム画面では、限定ではなく例として、ユーザＹ．Ｙが安否情報として「危険」を設定していることに基づいて、ユーザ状態アイコンＩＣＹＤ（ユーザＹ．Ｙ、危険）が表示されている。

また、ユーザＹ．Ｙの端末２０Ｙのホーム画面に重畳して、安否登録領域Ｒ１がせり上がり表示されている。この安否登録領域Ｒ１は、本実施例では、安否情報を変更するために用いられる。

安否登録領域Ｒ１には、ユーザに安否情報を設定することを促す旨のメッセージ（本例では、「安否確認」の文字と、「みんなに安否を伝えよう」の文字）が表示されている。その下には、安全ボタンＳＢＴと危険ボタンＤＢＴとが設けられている。また、画面下部には、安否情報を、選択された安否情報に変更するための変更ボタンＢＴ５が表示されている。

限定ではなく例として、図２－１左側の安否情報変更領域において、安全ボタンＳＢＴがユーザによってタップされた後、変更ボタンＢＴ５がユーザによってタップされた場合における、ユーザＸ．Ｘの端末２０Ｘに表示されるトークリスト画面の一例を図２－１中央に示す。このトークリスト画面は、図１－１０左側の表示画面と同様であるので説明を省略する。

限定ではなく例として、図２－１中央のトークリスト画面において、ユーザＹ．Ｙに対応したトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図２－１右側のトークルーム画面が表示される。

このトークルーム画面のトーク領域の上部には、限定ではなく例として、ユーザＹ．Ｙが設定した安否情報をトークルーム内で通知するための第１通知情報ＮＩ１（本例では、「Ｙ．Ｙさんが安否確認に回答しました」の文字と、ユーザ状態アイコンＩＣＹＤ（ユーザＹ．Ｙ、危険））が表示されている。
その下には、限定ではなく例として、ユーザＹ．Ｙからのコンテンツとして、テキストコンテンツ（「地震 大丈夫だった？」）が表示されている。

また、その下には、ユーザＹ．Ｙが安否情報を「危険」から「安全」に変更したことに基づき、限定ではなく例として、安否が安全に変更された第２通知情報ＮＩ２（本例では、「Ｙ．Ｙさんが安否確認に回答しました」の文字と、ユーザ状態アイコンＩＣＹＳ（ユーザＹ．Ｙ、安全））が表示されている。
その下には、限定ではなく例として、ユーザＹ．Ｙからのコンテンツとして、テキストコンテンツ（「避難しました！」）が表示されている。

＜処理＞
図２－２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

限定ではなく例として、Ｓ１２０とＸ１２０とＹ１２０とのステップが実行されると、安否確認処理が実行される（Ｘ２１０、Ｙ２１０、Ｓ２１０）。

図２－３は、安否確認処理の流れの一例を示すフローチャートである。図の見方は、図２－２と同様である。
端末２０Ｘの制御部２１は、限定ではなく例として、図１－１４におけるＸ１３０～Ｘ１６０のステップと同様に、Ｘ２１３０～Ｘ２１６０のステップを実行する。また、端末２０Ｙの制御部２１は、限定ではなく例として、図１－１４におけるＹ１３０～Ｙ１６０のステップと同様に、Ｙ２１３０～Ｙ２１６０のステップを実行する。サーバ１０の制御部１１は、限定ではなく例として、図１－１４におけるＳ１３０～Ｓ１４０のステップと同様に、Ｓ２１３０～Ｓ２１４０のステップを実行する。

図２－２に戻り、安否確認処理が実行されると、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１と、サーバ１０の制御部１１とは、処理を終了させるか否かを判定する（Ｘ２２０、Ｙ２２０、Ｓ２２０）。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間（限定ではなく例として、一週間）が経過した場合や、サーバ１０のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。

処理を終了させると判定された場合（Ｘ２２０：ＹＥＳ、Ｙ２２０：ＹＥＳ、Ｓ２２０：ＹＥＳ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、処理を終了させる。
処理を終了させないと判定された場合（Ｘ２２０：ＮＯ、Ｙ２２０：ＮＯ、Ｓ２２０：ＮＯ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、再度安否確認処理を実行させる（Ｘ２１０、Ｙ２１０、Ｓ２１０）。

なお、各端末２０の制御部２１およびサーバ１０の制御部１１は、安否確認処理の前後の任意のタイミングにおいてチャット処理を実行するようにしてもよい。

図２－４は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
ここでは、表示画面と同様に、
・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
・安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
とする場合の処理を例示する。

限定ではなく例として、安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力（操作入力等）を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ１１０」）。そして、サーバ１０は第１の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
サーバ１０の制御部１１は、第１の安否確認登録情報に基づいて、第１の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ１２０」）。
端末２０Ｘは第１の安否情報を受信すると表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ１３０」）。

再度安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ１４０」）。そして、サーバ１０は第２の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
サーバ１０の制御部１１は、第２の安否確認登録情報に基づいて、第２の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ１５０」）。
端末２０Ｘは第２の安否情報を受信すると表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ１６０」）。

なお、サーバ１０の制御部１１は、第２の安否確認登録情報を受信した場合、第１の安否確認登録情報と第２の安否確認登録情報との安否比較処理を行うようにしてもよい。そして、第１の安否確認登録情報と第２の安否確認登録情報とに差異が生じていない場合、第２の安否情報を各端末２０に送信しないようにしてもよい。

また、サーバ１０の制御部１１は、安否比較処理の結果、第１の安否確認登録情報と第２の安否確認登録情報とに差異が生じている場合、安否登録アカウントの安否状況に変化が生じたことを示す安否変化情報を各端末２０に送信するようにしてもよい。

本タイミングチャートでは、安否登録アカウントの端末２０Ｙにおいて２回安否確認登録情報が入力される例を例示したが、３回以上安否確認登録情報が入力される場合についても同様に処理を実行することができる。

＜第２実施例の効果＞
本実施例は、安否参照アカウントのユーザの端末２０が、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）によって、第１の安否情報（限定ではなく、第１情報の一例）が第２の安否情報（限定ではなく、第２情報の一例）に変更された場合、第２の安否情報を通信Ｉ／Ｆ２２によって受信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザによって、第１端末のユーザの安否に関する第１情報が第２情報に変更された場合であっても、端末が第２情報を確実に取得可能となる。

また、この場合、第２の安否情報は、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）とを含むトークルーム（限定ではなく、第１チャットルームの一例）に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第１端末のユーザと端末のユーザとを含む第１チャットルームへの表示という分かり易い形で、第２情報を端末のユーザに知らせることができる。

＜第２変形例（１）＞
上記の実施例では、安否登録アカウントの端末２０において第２の安否確認登録情報が登録されると、安否参照アカウントの端末２０は自動的に第２の安否情報を受信する例を例示したが、これに限定されない。
限定ではなく例として、安否参照アカウントの端末２０において、特定の表示要素を表示させた場合など、設定された条件が成立した場合に、第２の安否情報を受信するようにしてもよい。

本変形例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。また、安否参照アカウントの端末２０において、安否情報を友だちリストと、ユーザのプロフィール画面とに表示させる場合について例示する。なお、安否情報をトークリスト画面やトークルーム画面に表示させるようにしてもよい。

図２－５左側は、ユーザＹ．Ｙの端末２０Ｙのホーム画面に重畳して、設定済みの安否情報を変更するための安否情報変更領域がせり上がり表示されている。このホーム画面は、図２－１左側の表示画面と同様であるので説明を省略する。

限定ではなく例として、図２－５左側の安否情報変更領域において、安全ボタンＳＢＴがユーザによってタップされた後、変更ボタンＢＴ５がユーザによってタップされた場合における、ユーザＸ．Ｘの端末２０Ｘに表示されるホーム画面の一例を図２－５中央に示す。

このホーム画面では、友だちリストの項目として、ユーザＹ．Ｙに対応したアイコンおよびユーザ名、ユーザＡ．Ａに対応したアイコンおよびユーザ名、ユーザＢ．Ｂに対応したアイコンおよびユーザ名等が一覧表示されている。そして、この例では、ユーザＹ．Ｙが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＹ．Ｙのアイコンと関連付けて第１危険アイコンＤＩＣ１が重畳表示され、ユーザＡ．Ａが安否情報として「安全」を設定していることに基づいて、友だちリストのユーザＡ．Ａのアイコンと関連付けて第１安全アイコンＳＩＣ１が重畳表示され、ユーザＢ．Ｂが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＢ．Ｂのアイコンと関連付けて第１危険アイコンＤＩＣ１が重畳表示されている。

限定ではなく例として、図２－５中央のホーム画面において、ユーザＹ．Ｙに対応した友だちリストの項目がユーザによってタップされると、限定ではなく例として、図２－５右側のユーザＹ．Ｙに対応したプロフィール画面に表示が遷移する。

プロフィール画面は、限定ではなく例として、選択されたユーザのプロフィールに関する情報を表示する画面とすることができる。そして、このプロフィール画面には、限定ではなく例として、各ユーザのメッセージングアプリケーションにおけるアイコン画像、ユーザ名、安否に関する情報、そのユーザを相手としたトークを行うためのボタン、そのユーザを相手とした音声通話を行うためのボタン、このユーザを相手としたビデオ通話を行うためのボタン等を表示させるようにすることができる。

この例では、ユーザＹ．Ｙが安否情報を「危険」から「安全」に変更したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション（サーバ１０）を発信元とする、ユーザＹ．Ｙが安否情報を変更したことを示すテキスト（Ｙ．Ｙさんのステータス（ステイタス）が変わりました）やアイコン（ユーザＹ．Ｙのアイコンおよび第２危険アイコンＤＩＣ２→第２安全アイコンＳＩＣ２）等を含む、プッシュ形式で表示されるプッシュ通知ＰＮ１が表示されている。

また、ユーザＹ．Ｙのプロフィールを示すアイコンおよびユーザ名の下には、ユーザＹ．Ｙの安否に関する情報として、第２安全アイコンＳＩＣ２が表示されている。
より具体的には、図２－５中央のホーム画面では、友だちリストのユーザＹ．Ｙのアイコンと関連付けて第１危険アイコンＤＩＣ１が表示されていた。ユーザＹ．Ｙによって安否に関する第１情報（危険）が第２情報（安全）に変更され、図２－５右側に示すユーザＹ．Ｙのプロフィール画面が表示されたことに基づき、ユーザＹ．Ｙのアイコンと関連付けて第２安全アイコンＳＩＣ２が表示されている。

この例では、図２－５中央のホーム画面において、ユーザＹ．Ｙに対応した友だちリストの項目がユーザによってタップされると、端末２０Ｘの制御部２１は、図２－５右側のユーザＹ．Ｙに対応したプロフィール画面を表示させる。そして、端末２０Ｘの制御部２１は、安否更新要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信し、これに基づいて、上記のプッシュ通知で表示するための情報が、サーバ１０から端末２０Ｘに送信される。そして、端末２０Ｘの制御部２１は、受信した情報に基づいて、上記のプッシュ通知を表示させるとともに、受信した情報に基づいて、変更後の安否情報に対応するアイコン（この例では、安全に対応する第２安全アイコンＳＩＣ２）を表示させる。

なお、端末２０Ｘの制御部２１が安否更新要求情報をサーバ１０に送信すると、これに基づいて、変更後の安否情報（この例では、安全）がサーバ１０から端末２０Ｘに送信されるようにする。そして、端末２０Ｘの制御部２１は、受信した情報に基づいて、変更後の安否情報に対応するアイコン（この例では、安全に対応する第２安全アイコンＳＩＣ２）を表示させる。また、端末２０Ｘの制御部２１は、先に受信していた変更前の安否情報（この例では「危険」）と、新たに受信した変更後の安否情報（この例では「安全」）とに基づいて、上記のプッシュ通知を表示するための情報を生成して、上記のプッシュ通知を表示させるようにしてもよい。

なお、図２－５右側のプロフィール画面が表示された場合であっても、上記のプッシュ通知を表示させないようにしてもよい。
また、図２－５中央のホーム画面の友だちリストにおいて、そのリストに含まれるユーザに関連付けて安否に関する情報（第１安全アイコンＳＩＣ１または第１危険アイコンＤＩＣ１）を表示させないが、図２－５右側のプロフィール画面が表示された場合に、上記のプッシュ通知を表示させるようにしてもよい。

また、図２－５中央のホーム画面において、ユーザＹ．Ｙに対応した友だちリストの項目がユーザによってタップされると、端末２０Ｘの制御部２１は、図２－５右側のユーザＹ．Ｙに対応したプロフィール画面を表示させるが、変更前の安否情報に対応するアイコン（この例では、危険に対応する第２危険アイコンＤＩＣ２）を表示させるようにする。そして、端末２０Ｘの制御部２１は、安否更新要求情報をサーバ１０に送信し、これに基づいて、変更後の安否情報（この例では、安全）がサーバ１０から端末２０Ｘに送信されるようにする。そして、端末２０Ｘの制御部２１が、変更前の安否情報に対応するアイコン（この例では、危険に対応する第２危険アイコンＤＩＣ２）の表示を、変更後の安否情報に対応するアイコン（この例では、安全に対応する第２安全アイコンＳＩＣ２）に変更する制御を行うようにしてもよい。

また、限定ではなく例として、前述したトークリスト画面において、ユーザのトークルームリスト項目に対応したアイコンに重畳して表示される安否ステータス情報に基づくアイコン（第２安全アイコンＳＩＣ２または第２危険アイコンＤＩＣ２）がタップされると、そのユーザのプロフィール画面が表示されるようにしてもよい。
限定ではなく例として、図１－１３左側の画面においてユーザＢ．Ｂのトークルームリスト項目に対応したアイコンに重畳して表示されている第２危険アイコンＤＩＣ２がタップされると、限定ではなく例として図２－５右側のプロフィール画面と同様の態様で、ユーザＢ．Ｂのプロフィール画面が表示されるようにしてもよい。この場合、ユーザＢ．Ｂのプロフィール画面には、第２危険アイコンＤＩＣ２が表示されるようにすることができる。

また、安否登録アカウントによって安否情報が登録されると、安否参照アカウントの端末２０において、安否登録アカウントのユーザのトークルームリスト項目（限定ではなく例として、ユーザのトークルームリスト項目に対応したアイコンや安否ステータス情報に基づくアイコン）を光らせて表示させるなどしてもよい。そして、光っている項目がタップされると、そのユーザのプロフィール画面が表示されるようにしてもよい。

また、前述したように、安否位置情報と安否コメント情報とを別の画面に表示させてもよく、限定ではなく例として、これらのうちの一方の情報をトークリスト画面に表示させ、他方の情報をプロフィール画面に表示させてもよい。

また、複合安否情報を、上記のプロフィール画面に表示させるようにしてもよい。
また、安否位置情報と安否コメント情報とのいずれか一方の情報を、上記のプロフィール画面に表示させるようにしてもよい。

また、上記の例とは異なるが、安否情報を上記のプロフィール画面には表示させないようにしてもよい。一例として、安否情報を前述したホーム画面に表示させるが、上記のプロフィール画面には表示させないようにしてもよい。

また、上記のプロフィール画面に代えて、安否情報を表示する専用の画面を表示させるなどしてもよい。

図２－６は、本変形例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
ここでは、表示画面と同様に、
・安否登録アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
・安否参照アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
とする場合の処理を例示する。

限定ではなく例として、安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ２１０」）。そして、サーバ１０は第１の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
サーバ１０の制御部１１は、第１の安否確認登録情報に基づいて、第１の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ２２０」）。
端末２０Ｘは第１の安否情報を受信すると表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ２３０」）。

再度安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ２４０」）。そして、サーバ１０は第２の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。サーバ１０の制御部１１は、第２の安否確認登録情報に基づいて、第２の安否情報を生成する。

端末２０Ｘにおいて、限定ではなく例として、ユーザＸ．Ｘの端末２０に対するユーザ操作に基づいて、メッセージングアプリケーションにおける特定表示要素を表示させる表示処理が実行される（タイミング「ＴＭ２５０」）。
ここで、特定表示要素としては、限定ではなく例として、以下の表示要素が挙げられる。
・安否登録アカウントのユーザのプロフィール画面
・安否登録アカウントと安否参照アカウントとの一対一トークルーム
・安否登録アカウントを含むグループトークルーム
・安否登録アカウントを含むトークリスト画面
・安否確認サービスの公式アカウントプロフィール画面
・安否確認サービスの公式アカウントと安否参照アカウントとのトークルーム
・安否確認サービスの公式アカウントを含むトークリスト画面
なお、トークリスト画面については、過剰に安否情報が表示されることを防ぐために、特定表示要素から除外するようにしてもよい。

すると、端末２０Ｘの制御部２１は、所定の安否登録アカウントの安否情報を要求するための安否更新要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ２６０」）。

サーバ１０の制御部１１は、安否更新要求情報を受信する場合、第２の安否情報を安否参照アカウントの端末２０Ｘに送信する（Ｓ２１４０）（タイミング「ＴＭ２７０」）。
なお、サーバ１０の制御部１１は、安否比較処理の結果、第１の安否確認登録情報と第２の安否確認登録情報とに差異が生じていない場合、第２の安否情報を端末２０Ｘに送信しないようにしてもよい。この場合、安否に変更がないことを示す情報を端末２０Ｘに送信するようにしてもよい。
また、サーバ１０の制御部１１は、安否比較処理の結果、第１の安否確認登録情報と第２の安否確認登録情報とに差異が生じている場合、安否登録アカウントの安否状況に変化が生じたことを示す安否変化情報を端末２０Ｘに送信するようにしてもよい。

端末２０Ｘは第２の安否情報を受信すると、表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ２８０」）。

本タイミングチャートでは、安否登録アカウントの端末２０Ｙにおいて２回安否確認登録情報が入力される例を例示したが、３回以上安否確認登録情報が入力される場合についても同様に処理を実行することができる。

本変形例は、安否参照アカウントのユーザの端末２０が、第１の安否情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ２２によって受信した後、安否登録アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と安否参照アカウントのユーザ（限定ではなく、端末のユーザの一例）とを含むトークルーム（限定ではなく、第１チャットルームの一例）を表示部２４に表示した場合、第２の安否情報（限定ではなく、第２情報の一例）を通信Ｉ／Ｆ２２によって受信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末が第１情報を受信した後、第１端末のユーザと端末のユーザとを含む第１チャットルームを表示することを契機として、端末が第２情報を取得できるようにすることができる。また、このようにすることで、むやみに第２情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。

また、安否参照アカウントのユーザの端末２０は、安否登録アカウントのユーザのプロフィール情報などの安否登録アカウントのユーザの情報（限定ではなく、第１端末のユーザの情報の一例）を表示部２４に表示した場合、第２の安否情報を通信Ｉ／Ｆ２２によって受信する構成としてもよい。
このような構成により得られる実施例の効果の一例として、端末が第１端末のユーザの情報を表示することを契機として、端末が第２情報を取得できるようにすることができる。また、このようにすることで、むやみに第２情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。

また、この場合、安否登録アカウントのユーザの情報は、安否登録アカウントのユーザの安否に関連する情報（安全、危険など）を含む、安否登録アカウントのユーザのステータスに関する情報を含むようにすることができる。
このような構成により得られる変形例の効果の一例として、端末が第１端末のユーザの安否に関連する第１情報を含む、第１端末のユーザのステータスに関する情報を表示することを契機として、端末が第２情報を取得できるようにすることができる。また、このようにすることで、むやみに第２情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。

＜第２変形例（２）＞
上記の実施例では、安否登録アカウントの端末２０において第２の安否確認登録情報が登録されると、安否参照アカウントの端末２０は自動的に第２の安否情報を受信する例を例示したが、これに限定されない。
限定ではなく例として、安否参照アカウントと安否登録アカウントとの関係性に基づいて、第２の安否情報を受信するようにしてもよい。

限定ではなく例として、以下のように安否参照アカウントと安否登録アカウントとの親密度を定義する。
親密度（安否参照アカウント，安否登録アカウント）＝安否参照アカウントと安否登録アカウントとにおける１日当たりの平均メッセージ送受信回数

この場合、限定ではなく例として、親密度が設定値（限定ではなく例として、「１０」通）以上、または設定値より大きい場合、サーバ１０の制御部１１は、第２の安否情報を安否参照アカウントの端末２０に送信するようにしてもよい。

なお、親密度が設定値以上、または設定値より大きい場合、安否参照アカウントの端末２０は、安否更新要求情報を設定時間間隔（限定ではなく例として、「５分間」）ごとにサーバ１０に送信する。そして、サーバ１０の制御部１１は、安否更新要求情報を受信する場合、第２の安否情報を安否参照アカウントの端末２０に送信するようにしてもよい。

本変形例は、第２の安否情報（限定ではなく、第２情報の一例）は、安否参照アカウントのユーザと安否登録アカウントのユーザとの関係に基づいて送信される構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザと、端末のユーザとの関係に基づいて適切に送信された第２情報を、端末が受信できるようにすることができる。

＜第２変形例（３）＞
上記の実施例では、安否登録アカウントと安否参照アカウントとが異なる例について例示したが、これに限定されない。ここでは、
・安否登録アカウント 兼 安否参照アカウント＝端末２０ＡのユーザＡ．Ａのアカウントとする場合を例示する。

図２－７左側は、ユーザＡ．Ａの端末２０Ａのトークリスト画面の一例を示している。このトークリスト画面は、図１－１３左側の表示画面と同様であり、ユーザＡ．Ａが、自身は「安全」であることを設定したことに基づき、その旨を示すユーザ状態アイコン（ユーザＡ．Ａ、安全））を含む情報が、第２災害情報表示領域に表示されている。つまり、この例では、ユーザＡ．Ａのアカウントは、安否登録アカウントとして機能している。

限定ではなく例として、図２－７左側のトークリスト画面において、ユーザＣ．Ｃのトークルームリスト項目がユーザによってタップされると、限定ではなく例として、図２－７中央のトークルーム画面が表示される。この画面は、図１－１３右側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＡ．ＡがユーザＣ．Ｃを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｃ．Ｃ」）が表示されている。
また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第２危険アイコンＤＩＣ２が重畳表示されたユーザＣ．Ｃのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＡ．Ａのアイコンとが表示されている。

トーク領域には、限定ではなく例として、ユーザＣ．Ｃからのコンテンツ（限定ではなく例として「地震だ～揺れがすごい」のテキストコンテンツ、「エレベーター止まった」のテキストコンテンツ）と、ユーザＡ．Ａによって発信されたコンテンツ（限定ではなく例として「地震大丈夫？誰かと一緒にいる？」のテキストコンテンツ）とが表示されている。

限定ではなく例として、ユーザＣ．Ｃによって安否情報が変更された場合における、ユーザＡ．Ａの端末２０Ａに表示されるトークルーム画面の一例を図２－７右側に示す。
この例では、ユーザＣ．Ｃが安否情報を「危険」から「安全」に変更したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション（サーバ１０）を発信元とする、ユーザＣ．Ｃが安否情報を変更したことを示すテキスト（Ｃ．Ｃさんのステータス（ステイタス）が変わりました）やアイコンを含むプッシュ通知ＰＮ３が表示されている。

また、トーク領域には、限定ではなく例として、新たなユーザＣ．Ｃからのコンテンツ（限定ではなく例として「エレベーター止まった」のテキストコンテンツ、「１人だよー怖いよー あ、エレベーター動いた！」のテキストコンテンツ、「出られた～～！」のテキストコンテンツ）が表示されている。

また、この表示画面例では、ユーザＣ．Ｃのテキストコンテンツ「出られた～～！）の下に、ユーザＹ．Ｙが変更した安否情報をトークルーム内で通知する通知情報として、限定ではなく例として、「Ｃ．Ｃさんのステイタスが変わりました」の文字と、ユーザ状態アイコンＩＣＣＤ（ユーザＣ．Ｃ、危険）→ユーザ状態アイコンＩＣＣＳ（ユーザＣ．Ｃ、安全）とを含む第３通知情報ＮＩ３が表示されている。

また、この第３通知情報ＮＩ３の下には、ユーザＡ．Ａによって発信されたコンテンツ（限定ではなく例として「よかったーー」のテキストコンテンツ）が表示されている。

つまり、この例では、ユーザＡ．Ａのアカウントは、安否参照アカウントとしても機能している。

＜第３実施例＞
第３実施例は、２以上の安否登録アカウントの端末２０間で通話を行う場合、限定ではなく例として、登録された安否ステータス情報に基づいて、接続制御を行う実施例である。

以下では、通話を行うために発信する者である発信元のユーザアカウントを「発信元アカウント」、発信された通話を受ける者である着信先のユーザアカウントを「発信先アカウント」と称する。

第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
本実施例における表示画面では、発信元アカウントを端末２０ＡのユーザＡ．Ａ、発信先アカウントを、端末２０ＢのユーザＢ．Ｂおよび端末２０ＣのユーザＣ．Ｃとする。また、発信元アカウントおよび発信先アカウントは、安否登録を済ませた安否登録アカウントとして例示する。

図３－１左側は、ユーザＡ．Ａの端末２０Ａのトークルーム画面が表示されている。この画面は、図１－１３右側で示した表示画面と同様であるので説明を省略する。

限定ではなく例として、図３－１左側のトークルーム画面において、トークルーム名表示領域の右部の通話を行うための通話ボタンＢＴ７がユーザによってタップされた場合における、ユーザＡ．Ａの端末２０Ａに表示される通話画面の一例を図３－１右側に示す。

通話画面には、画面最上部のメッセージングアプリケーションの名称等が表示される領域の下に、限定ではなく例として、通話ステータス（通話の状態）を示す通話ステータス表示領域が設けられている。通話ステータスとしては、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂに発信していることを示す「発信中」、ユーザＡ．ＡがユーザＢ．Ｂと通話していることを示す「通話中」等が設けられている。

その下には、通話相手となるユーザのメッセージングアプリケーションにおけるアイコン画像、ユーザ名、通話時間、マイクをオフにするためのマイクオフボタン（本例では、マイク型の画像と「マイクをオフ」の文字）、そのユーザを相手としたビデオ通話を行うためのビデオ通話ボタン（本例では、ビデオカメラ型の画像と「ビデオ通話を開始」の文字）、スピーカをオンにするためのスピーカオンボタン（本例では、スピーカ型の画像と「スピーカをオン」の文字）、および、通話を終了するための通話終了ボタン等が表示されている。

本例では、通話ステータス表示領域には、「通話中」の文字が表示されており、その下には、ユーザＢ．Ｂのアイコン画像、「Ｂ．Ｂ」の文字、通話時間として「１：４７」の数字、マイクオフボタン、ビデオ通話ボタン、スピーカオンボタン、および、通話終了ボタンが表示されている。

図３－２左側は、ユーザＡ．Ａの端末２０Ａのトークルーム画面が表示されている。この画面は、図２－７右側で示したトークルーム画面と同様であるものの、トークルーム名表示領域には、限定ではなく例として、前の画面に戻るための「＜」の戻るボタン、ユーザＡ．ＡがユーザＣ．Ｃを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｃ．Ｃ」）、および通話ボタン等が表示されている。

限定ではなく例として、図３－２左側のトークルーム画面において、トークルーム名表示領域の右部の通話ボタンＢＴ７がユーザによってタップされると、図３－２中央のような表示がなされる。

このトークルーム画面では、ユーザＡ．ＡとユーザＢ．Ｂの安否ステータスがともに「安全」であることに基づき、図３－２左側のトークルーム画面に重畳して、災害発生時に不要不急の通話を控えさせるための通話遠慮要請情報ＣＲＩ１が表示されている。
この例では、通話遠慮要請情報ＣＲＩ１には、災害が発生している場合に不要不急の通話を控えるよう促す（注意喚起する）旨のメッセージ（本例では、「大規模災害発生のため不要不急の通話はお控えください」の文字、キャラクタの画像）とともに、発信をキャンセルするためのキャンセルボタン（本例では、「キャンセル」の文字が含まれたボタン）、および、通話を行うための第２通話ボタン（本例では、「どうしても発信」の文字が含まれたボタン）が表示されている。

限定ではなく例として、図３－２中央のトークルーム画面において、第２通話ボタンがユーザによってタップされた場合における、ユーザＡ．Ａの端末２０Ａに表示される通話画面の一例を図３－２右側に示す。

本例では、通話ステータス表示領域には、「通話中」の文字が表示されており、その下には、ユーザＣ．Ｃのアイコン画像、「Ｃ．Ｃ」の文字、通話時間として「０：１２」の数字、マイクオフボタン、ビデオ通話ボタン、スピーカオンボタン、および、通話終了ボタンが表示されている。

＜処理＞
図３－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、発信元アカウントの端末２０Ｘの制御部２１が実行する処理、発信先アカウントの端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

限定ではなく例として、端末２０Ｘの制御部２１は、安否確認処理を実行すると（Ｘ２１０）、限定ではなく例として、端末２０Ｘの入出力部２３に対する入力（ユーザ操作等）に基づいて、限定ではなく例として、発信先アカウントのアプリケーションＩＤを含む通話要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｘ３１０）。

通信Ｉ／Ｆ１４によって発信元アカウントの端末２０Ｘから通話要求情報を受信したと判定する場合、サーバ１０の制御部１１は、安否ステータス判定処理を実行する（Ｓ３１０）。

安否ステータス判定処理において、サーバ１０の制御部１１は、アカウント管理データベース１５５Ａを参照し、発信元アカウントの安否登録データにおける安否ステータス情報（以下、「発信元ステータス」と称する。）と、発信先アカウントの安否登録データにおける安否ステータス情報（「以下、「発信先ステータス」と称する。）とを取得する。
そして、サーバ１０の制御部１１は、限定ではなく例として、発信元ステータスが「安全」かつ発信先ステータスが「安全」であるか否かを判定する。

発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合（Ｓ３１０：「安全」－「安全」）、サーバ１０の制御部１１は、通話の発信を控えることを要請するための通話遠慮要請情報を、通信Ｉ／Ｆ１４によって発信元アカウントの端末２０Ｘに送信する（Ｓ３２０）。

発信元ステータスが「安全」かつ発信先ステータスが「安全」以外であると判定される場合（Ｓ３１０：「安全」－「安全」以外）、サーバ１０の制御部１１は、Ｓ３２０のステップをスキップさせる。

通信Ｉ／Ｆ２２によってサーバ１０から通話遠慮要請情報を受信したと判定される場合（Ｘ３２０：ＹＥＳ）、端末２０Ｘの制御部２１は、受信した通話遠慮要請情報を表示部２４に表示させる（Ｘ３３０）。
通話遠慮要請情報を受信しないと判定される場合（Ｘ３２０：ＮＯ）、端末２０Ｘの制御部２１は、Ｘ３３０のステップをスキップさせる。

その後、サーバ１０の制御部１１は、通話処理を開始する（Ｓ３４０）。また、端末２０Ｘおよび端末２０Ｙの制御部２１は、通話処理を開始する（Ｘ３４０、Ｙ３４０）。
通話処理において、端末２０Ｙの制御部２１は、限定ではなく例として、通話が着信したことを示す通話着信音を音出力部２６から着信音を音出力させる。これにより、ユーザＸ．Ｘに着信音を聞かせ、通話が要求されていることを報知させる。また、端末２０Ｙの制御部２１は、限定ではなく例として、発信元アカウントの情報（限定ではなく例として、ユーザ名）を含む着信表示を表示部２４に表示させる。
なお、発信元アカウントの情報として、発信元ステータスを含む情報を発信先アカウントの端末２０の表示部２４に表示させるようにしてもよい。

限定ではなく例として、端末２０Ｙの入出力部２３に対する入力に基づいて、通話が受け入れられると、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１とは、限定ではなく例として、サーバ１０を介してユーザ間の通話におけるＶｏＩＰ処理を実行する。なお、通話が受け入れられると、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１とは、ピアツーピア通信を行い、通話におけるＶｏＩＰ処理を実行するようにしてもよい。

限定ではなく例として、端末２０Ｘまたは端末２０Ｙの入出力部２３に対する入力に基づいて、通話が終了し切断されると、サーバ１０の制御部１１は、処理を終了させる。また、端末２０Ｘおよび端末２０Ｙの制御部２１は、処理を終了させる。

なお、通話遠慮要請情報に、通話の発信を取りやめるか否かの選択用表示を含めるようにしてもよい。この場合、発信元アカウントの端末２０Ｘに通話遠慮要請情報が表示され、限定ではなく例として、通話遠慮要請情報に対する入力に基づいて通話の発信を取りやめることが選択された場合、発信元アカウントの端末２０Ｘの制御部２１は、通話の発信を取りやめることを示す通話発信解消情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。通信Ｉ／Ｆ１４によって発信元アカウントの端末２０Ｘから通話発信解消情報を受信したと判定される場合、サーバ１０の制御部１１は、端末２０Ｘと端末２０Ｙとの通話処理を開始しないようにしてもよい。通話遠慮要請情報に対する入力操作に基づいて通話の発信を続けることが選択された場合、サーバ１０の制御部１１は、端末２０Ｘと端末２０Ｙとの通話処理を開始するようにしてもよい。

また、サーバ１０の制御部１１は、安否ステータス判定処理において、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合（Ｓ３１０：「安全」－「安全」）、通話を接続しないことを示す通話接続拒否情報を通信Ｉ／Ｆ１４によって発信元アカウントの端末２０Ｘに送信するようにしてもよい。端末２０Ｘの制御部２１は、通話接続拒否情報を受信すると、表示部２４に表示させるようにしてもよい。そして、サーバ１０の制御部１１は、通話処理を開始しないようにしてもよい。
すなわち、安否ステータス判定処理において、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合には、通話は強制的に解消される。

＜第３実施例の効果＞
本実施例は、発信元アカウントのユーザの端末２０が、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とに基づいて、通話に関する処理を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、通話に関連するユーザの安否に関する情報に基づいて、通話に関する処理を適切に行うことができる。

また、この場合、通話に関する処理は、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とがともに「安全」であるような場合に、通話を抑制（禁止）する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とが設定された条件を満たす場合に、通話を抑制（禁止）することができる。

＜第３変形例（１）＞
上記の実施例では、安否ステータス判定処理に基づいて、通話を抑制させるか否かを判定したが、これに限定されない。限定ではなく例として、安否ステータス判定において、発信元ステータスが「危険」であると判定される場合、サーバ１０の制御部１１は、通話の接続優先度を上げて通話処理を実行するようにしてもよい。

発信元ステータスが「危険」である場合、発信元アカウントのユーザによる通話発信は緊急性が高いと考えられる。そのため、発信元ステータスが「危険」であると判定される場合、通話の接続優先度を上げることにより、緊急性の高い可能性が高い通話を接続し易くすることができる。

なお、発信元ステータスが「危険」である場合、通話処理において、限定ではなく例として、発信先アカウントの端末２０Ｙにおける通話着信音をより目立つ態様の着信音として音出力させるようにしてもよい。また、発信元ステータスが「危険」である場合、通話処理において、限定ではなく例として、発信先アカウントの端末２０Ｙにおける通話表示をより目立つ態様の着信表示として表示させるようにしてもよい。
これにより、発信元アカウントのユーザは、助けを求める等の行動を取っている可能性が高い発信元アカウントからの通話着信をより容易に区別することができる。

なお、安否ステータス判定において、発信先ステータスが「危険」であると判定される場合、通話の接続優先度を上げるようにしてもよい。

＜第３変形例（２）＞
上記の実施例では、サーバ１０において安否ステータス判定処理を実行することとしたが、これに限定されない。限定ではなく例として、発信元アカウントの端末２０Ｘにおいて安否ステータス判定処理を実行するようにしてもよい。

限定ではなく例として、発信元アカウントの端末２０Ｘの制御部２１は、安否確認処理を実行すると、限定ではなく例として、端末２０Ｘの入出力部２３に対する入力（ユーザ操作等）に基づいて、通話発信先アカウントを受け付ける。すると、端末２０Ｘの制御部２１は、限定ではなく例として、発信元アカウントのアプリケーションＩＤと、発信先アカウントのアプリケーションＩＤとを含む安否情報要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。
通信Ｉ／Ｆ１４によって端末２０Ｘから安否情報要求情報を受信すると、サーバ１０の制御部１１は、アカウント管理データベース１５５Ａを参照し、発信元ステータスと、発信先ステータスとを取得する。そして、発信元ステータスと、発信先ステータスとを含む安否情報を通信Ｉ／Ｆ１４によって端末２０Ｘに送信する。

通信Ｉ／Ｆ２２によってサーバ１０から安否情報を受信すると、端末２０Ｘの制御部２１は、受信した安否情報に基づいて、安否ステータス判定処理を実行する。そして、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合、端末２０Ｘの制御部２１は、通話遠慮要請情報を表示部２４に表示させる。

なお、端末２０Ｘが通話開始に先立ち安否情報として発信先ステータスを取得している場合、端末２０Ｘの制御部２１は、安否情報要求情報をサーバ１０に送信せず、記憶部２８に記憶される発信元ステータスと発信先ステータスとに基づいて安否ステータス判定処理を実行するようにしてもよい。

＜第４実施例＞
第４実施例は、安否登録アカウントの端末２０において安否確認登録情報が登録されると、その後の安否登録アカウントに対して送信されるメッセージに対して自動的に応答を行う実施例である。

第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図４－１左側は、ユーザＡ．Ａの端末２０Ａのホーム画面が表示されている。この画面は、図１－１２中央のホーム画面と異なり、安否メッセージ入力領域には、ユーザによって入力された安否メッセージ（本例では、「自転車で移動中です」）が表示されている。また、その下の現在地入力領域には、ユーザによって入力された現在の居場所（本例では「三鷹市」）が表示されている。

限定ではなく例として、図４－１左側の安否登録領域Ｒ１において、登録ボタンＢＴ３がユーザＡ．Ａによってタップされると図４－１中央の安否登録領域Ｒ１に表示が遷移する。

この場合、安否登録領域Ｒ１では、安全ボタンＳＢＴ、危険ボタンＤＢＴ、安否メッセージ入力領域、現在地入力領域等の表示が消去され、設定された安否情報を確認するための安否情報確認領域が構成されている。安否情報確認領域には、限定ではなく例として、「以下の内容で登録しました」の文字、「安否メッセージ」の文字、ユーザ状態アイコンＩＣＡＳ（ユーザＡ．Ａ、安全）、「三鷹／自転車で移動中です」の文字が表示されている。

また、その下には、自動応答モードに設定するための自動応答設定領域が構成されている。自動応答設定領域には、限定ではなく例として、「自動応答モードに切り替えますか？」の文字と、自動応答モードに設定する（モードを自動応答モードに切り替える）ための「はい」ボタンＢＴ１１と、自動応答モードに設定しないための「いいえ」ボタンＢＴ１２（本例では、「いいえ」の文字で示されるボタン）とが表示されている。

限定ではなく例として、図４－１中央の安否登録領域Ｒ１において、「はい」ボタンＢＴ１１がユーザＡ．Ａによってタップされたとする。この場合、図４－１右側に示すような画面が表示される。

図４－１右側は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示されるトークリスト画面の一例を示している。この画面は、図１－１３左側のトークリスト画面とは異なり、自動応答モードの設定を行っている場合に、トークルームリスト項目に、自動応答モードに設定された後に他のユーザからメッセージが送信された（自動応答で返信された）トークルームであることを示す自動応答済み情報が表示されている。

本例では、自動応答モードの設定を行っている場合に、自動応答モードに設定された後に他のユーザからメッセージが送信されたトークルームのトークルームリスト項目のうち最も古い時間にメッセージが送信されたトークルーム（ユーザＢ．Ｂのトークルーム）に対応したトークルームリスト項目から、最も新しい時間にメッセージが送信されたトークルーム（テニスサークルのグループトークルーム）に対応したトークルームリスト項目に亘って、自動応答済み情報（本例では、「自動応答済み」の文字が示されたテロップ）が重畳表示されている。

図４－２左側は、ユーザＤ．Ｄの端末２０Ｄのトークルーム画面が表示されている。この画面は、図１－１３右側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＤ．ＤがユーザＡ．Ａを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ａ．Ａ」）が表示されている。
また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第２安全アイコンＳＩＣ２が重畳表示されたユーザＡ．Ａのアイコンと、第２安全アイコンＳＩＣ２が重畳表示されたユーザＤ．Ｄのアイコンとが表示されている。

トーク領域には、限定ではなく例として、ユーザＡ．Ａからのコンテンツ（限定ではなく例として、「じゃあ、おやすみ～」のテキストコンテンツ）と、ユーザＤ．Ｄによって発信されたコンテンツ（限定ではなく例として、「また明日～」のテキストコンテンツ、「揺れてる～地震？」のテキストコンテンツ、「大丈夫？もう家出た？」のテキストコンテンツ）とが表示されている。

また、その下には、ＯＡアカウント（本例では、安否確認応答サービス）を発信元とする自動応答確認情報ＡＲＩ（限定ではなく例として、「こちらは安否確認サービスです ２０ＸＸ／０８／０４ ９：３９発生の災害においてＡ．Ａさんの無事が確認されています 現在、電池節約等のため自動応答に設定されています」の文字を含む情報）が表示されている。

ここで、「未読」に相対する用語として「既読」を定義することができる。
メッセージ（コンテンツ）が既読となる条件（以下、「既読条件」と称する。）としては、限定ではなく例として、以下のいずれかの条件を適用することができる。
（Ａ）メッセージが表示されたこと。
（Ｂ）メッセージが表示されてから一定時間（限定ではなく、数秒～１０秒程度の時間）が経過したこと。
（Ｃ）メッセージが表示された後、表示されたメッセージがタップ（クリック）されたこと。
（Ｄ）メッセージが表示された後、そのメッセージに対して返信がされたこと。
（Ｅ）メッセージが動画像のメッセージである場合に、その動画像が再生されたこと。
（Ｆ）メッセージが動画像のメッセージである場合に、その動画像を再生してから一定時間（限定ではなく、数秒～１０秒程度の時間）が経過したこと。

この場合、「未読」の状態は、限定ではなく例として、上記の既読条件を満たしていない状態と定義することができる。
「未読」の状態は、ユーザがメッセージ（コンテンツ）を未閲覧の状態であることの一種である。

本例では、ユーザＤ．Ｄによって発信されたコンテンツのうち、限定ではなく例として「また明日～」のテキストコンテンツが既読状態となっていることに基づいて、このテキストコンテンツの吹き出しの左下方に「既読」の文字が表示されており、「揺れてる～ 地震？」のテキストコンテンツおよび「大丈夫？もう家出た？」のテキストコンテンツが未読状態となっていることに基づいて、これらのテキストコンテンツの吹き出しの左下方に「既読」の文字が表示されていない。

限定ではなく例として、ユーザＡ．Ａによって自動応答モードに設定された場合における、ユーザＡ．Ａの端末２０Ａに表示されるトークルーム画面の一例を図４－２右側に示す。

この画面は、図４－２左側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＡ．ＡがユーザＤ．Ｄを相手としてトークを行うためのトークルームであることを示す文字（本例では「Ｄ．Ｄ」）が表示されている。

トーク領域には、限定ではなく例として、ユーザＡ．Ａによって発信されたコンテンツ（限定ではなく例として、「じゃあ、おやすみ～」のテキストコンテンツ、「返信遅くなってごめん Ｂ．Ｂさんが足ケガしたみたいでヘルプしてた；」のテキストコンテンツ）と、ユーザＤ．Ｄからのコンテンツ（限定ではなく例として、「また明日～」のテキストコンテンツ、「揺れてる～地震？」のテキストコンテンツ、「大丈夫？もう家出た？」のテキストコンテンツ）とが表示されている。

また、ユーザＤ．Ｄからのコンテンツのうち、限定ではなく例として、「揺れてる～ 地震？」のテキストコンテンツが送信された後であって、「大丈夫？もう家出た？」のテキストコンテンツが送信されるよりも前のタイミングで、ユーザＡ．Ａによって自動応答モードに設定されたことに基づいて、これらのテキストコンテンツの間に「自動応答モードを設定しました」の文字を含む自動応答設定情報ＡＲＳＩが表示されている。

また、ユーザＤ．Ｄからのコンテンツのうち、限定ではなく例として、「大丈夫？もう家出た？」のテキストコンテンツが送信された後のタイミングであって、ユーザＡ．Ａからのコンテンツのうち、限定ではなく例として、「返信遅くなってごめん Ｂ．Ｂさんが足ケガしたみたいでヘルプしてた；」のテキストコンテンツが送信されるよりも前のタイミングで、ユーザＡ．Ａによって自動応答モードが解除されたことに基づいて、これらのテキストコンテンツの間に「自動応答モードを解除しました」の文字が示された自動応答解除情報ＡＲＲＩが表示されている。

＜処理＞
本実施例において各装置が実行する処理については、限定ではなく例として、図２－２～図２－３に従って実行することができる。

図４－３は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
ここでは、
・自動応答を行う安否登録アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
・自動応答を行った安否登録アカウントにメッセージ送信を行うアカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
とする場合の処理を例示する。

限定ではなく例として、安否確認処理が実行され、端末２０Ｙにおいて、安否確認登録情報の入力操作を受け付ける（Ｙ２１３０）と、第１の安否確認登録情報がサーバ１０に送信される（Ｙ２１４０）（タイミング「ＴＭ３１０」）。そして、サーバ１０は第１の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
サーバ１０の制御部１１は、第１の安否確認登録情報に基づいて、第１の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ３１５」）。
端末２０Ｘは第１の安否情報を受信すると表示処理を実行する（Ｘ２１６０）（タイミング「ＴＭ３２０」）。

端末２０Ｘにおいて、安否確認登録情報の入力操作を受け付ける（Ｘ２１３０）と、第２の安否確認登録情報がサーバ１０に送信される（Ｘ２１４０）（タイミング「ＴＭ３２５」）。そして、サーバ１０は第２の安否確認登録情報を受信する（Ｓ２１３０：ＹＥＳ）。
サーバ１０の制御部１１は、第２の安否確認登録情報に基づいて、第２の安否情報を生成し、各端末２０に送信する（Ｓ２１４０）（タイミング「ＴＭ３３０」）。
端末２０Ｙは第２の安否情報を受信すると表示処理を実行する（Ｙ２１６０）（タイミング「ＴＭ３３５」）。

端末２０Ｘの制御部２１は、自動応答を開始するか否かの判定用表示を表示部２４に表示させる（タイミング「ＴＭ３４０」）。
限定ではなく例として、端末２０Ｘに表示された判定用表示に対する入力操作に基づいて、自動応答を開始することが選択された場合、端末２０Ｘの制御部２１は、自動応答を開始させることを要請するための自動応答開始要請情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ３４５」）。

通信Ｉ／Ｆ１４によって端末２０Ｘから自動応答開始要請情報を受信したと判定される場合、サーバ１０の制御部１１は、自動応答開始要請情報を送信した端末２０に対するメッセージ自動応答処理を開始する（タイミング「ＴＭ３５０」）。

チャット処理において、限定ではなく例として、端末２０Ｙに対する入力操作に基づいて、端末２０ＸのユーザＸ．Ｘに対するメッセージが入力されると、端末２０Ｙの制御部２１は、限定ではなく例として、入力されたメッセージと、メッセージ送信元である端末２０ＹのアプリケーションＩＤと、メッセージ送信先である端末２０ＸのアプリケーションＩＤとを含むメッセージ送信依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ３５５」）。

通信Ｉ／Ｆ１４によって端末２０Ｙからメッセージ送信依頼情報を受信すると、サーバ１０の制御部１１は、メッセージ送信依頼情報に基づいて、メッセージ送信先のアカウントに対する自動応答処理が実行されているか否かを判定する。この例では、端末２０Ｘに対するメッセージ自動応答処理はタイミング「ＴＭ３５０」～「ＴＭ３７５」の間である場合に実行されている。
従って、メッセージ送信依頼情報を受信したタイミングがタイミング「ＴＭ３５０」よりも後であり、かつ、タイミング「ＴＭ３７５」よりも前であると判定される場合、サーバ１０の制御部１１は、メッセージ自動応答情報を通信Ｉ／Ｆ１４によって端末２０Ｙに送信する（タイミング「ＴＭ３６０」）。

通信Ｉ／Ｆ２２によってサーバ１０からメッセージ自動応答情報を受信すると、端末２０Ｙの制御部２１は、受信したメッセージ自動応答情報を表示部２４に表示させる（タイミング「ＴＭ３６５」）。

限定ではなく例として、端末２０Ｘに対する入力操作に基づいて、自動応答を終了させることが選択された場合、端末２０Ｘの制御部２１は、自動応答を終了させることを要請するための自動応答終了要請情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ３７０」）。

通信Ｉ／Ｆ１４によって端末２０Ｘから自動応答終了要請情報を受信すると、サーバ１０の制御部１１は、端末２０Ｘに対するメッセージ自動応答処理を終了する（タイミング「ＴＭ３７５」）。
そして、サーバ１０の制御部１１は、メッセージ自動応答処理期間内（この場合、タイミング「ＴＭ３５０」～「ＴＭ３７５」の間）に端末２０Ｘに対して送信されたメッセージを含むメッセージ自動応答対応履歴情報を通信Ｉ／Ｆ１４によって端末２０Ｘに送信する（タイミング「ＴＭ３８０」）。

通信Ｉ／Ｆ２２によってサーバ１０からメッセージ自動応答対応履歴情報を受信すると、端末２０Ｘの制御部２１は、受信したメッセージ自動応答対応履歴情報を表示部２４に表示させる（タイミング「ＴＭ３８５」）。

なお、本タイミングチャートでは、サーバ１０はメッセージ自動応答処理期間内に端末２０Ｘに対するメッセージ送信依頼情報を１回受信する例を例示したが、２回以上メッセージ送信依頼情報を受信する場合についても同様に処理を実行することができる。また、サーバ１０が、メッセージ自動応答処理期間内に複数の端末２０から端末２０Ｘに対するメッセージ送信依頼情報を受信する場合においても同様である。

なお、サーバ１０の制御部１１は、メッセージ自動応答処理期間内（この場合、タイミング「ＴＭ３５０」～「ＴＭ３７５」の間）に再度端末２０Ｙからメッセージ送信依頼情報を受信する場合、メッセージ自動応答情報を端末２０Ｙに送信しないようにしてもよい。

また、サーバ１０の制御部１１は、メッセージ自動応答処理期間内に端末２０Ｘのアカウントが含まれるグループトークルームに対するメッセージ送信依頼情報を受信する場合、メッセージ自動応答情報をグループに属するメンバーの各端末２０に送信しないようにしてもよい。

また、端末２０Ｘにおいて、タイミング「ＴＭ３２０」やタイミング「ＴＭ３２５」に先んじて、自動応答を開始するか否かの判定用表示を表示部２４に表示させ、自動応答開始要請情報をサーバ１０に送信するようにしてもよい。

＜第４実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて、自己の端末２０のユーザの安否に関する安否情報（または安否確認登録情報）（限定ではなく、端末のユーザの安否に関する第３情報の一例）を通信Ｉ／Ｆ２２によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによる端末に対する入力に基づいて、端末のユーザの安否に関する第３情報を送信して、端末のユーザの安否を他者に知らせることができる。

また、この場合、端末２０は、上記の安否情報の送信に基づいて、トーク（限定ではなく、チャットの一例）の自動応答を開始するか否かの判定用の情報（限定ではなく、チャットの自動応答に関する情報の一例）を表示部２４に表示する。そして、端末２０は、この判定用の情報に対する、自己の端末２０のユーザによる入力に基づいて、自動応答を開始させることを要請するための自動応答開始要請情報を送信する処理や、自動応答を開始したことに関する情報を表示する処理といった、トーク（チャット）の自動応答に関する処理を制御部２１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、上記の第３情報の送信に基づいてチャットの自動応答に関する情報を表示部に表示して、チャットの自動応答が可能であることを端末のユーザに知らせることができる。また、表示した自動応答に関する情報に対する端末のユーザによる入力に基づいて、チャットの自動応答に関連する処理が適切に行われるようにすることができる。

＜第４変形例（１）＞
上記の実施例では、自動応答を開始する端末２０Ｘに対する入力操作に基づいて、自動応答開始要請情報が送信される例を例示したが、これに限定されない。
限定ではなく例として、端末２０Ｘのバッテリー残量が設定値（限定ではなく例として、「２０％」）以下である場合、端末２０Ｘの制御部２１は、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。

また、端末２０Ｘの制御部２１は、限定ではなく例として、サーバ１０から災害情報を受信すると、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。

また、端末２０Ｘの制御部２１は、限定ではなく例として、サーバ１０から災害情報を受信すると、限定ではなく例として、位置算出用情報検出部２９Ｂを介して現在位置を取得する。そして、端末２０Ｘの制御部２１は、現在位置が災害情報に含まれる災害発生場所と近しい（限定ではなく例として、最大震度の観測地点から１０ｋｍ以内）と判定される場合、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。

また、端末２０Ｘの通信状態が不良である場合（限定ではなく例として、電波強度が設定値以下である場合）、端末２０Ｘの制御部２１は、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。

また、端末２０Ｘで実行されるアプリケーションの使用の状態（状況）（限定ではなく例として、バックグラウンドで使用中）や、位置算出用情報検出部２９Ｂによる位置算出の状態（状況）（限定ではなく例として、いわゆる屋内環境（インドア環境）などの測位用衛星の捕捉が困難な状態、測位用衛星から衛星信号を受信する場合の信号強度が設定値以下である状態等）に基づいて、端末２０Ｘの制御部２１は、サーバ１０に自動応答開始要請情報を自動的に送信するようにしてもよい。

本変形例は、端末２０が、自己の端末２０のバッテリー残量などの自己の端末２０の状態に基づいて、トーク（限定ではなく、チャットの一例）の自動応答を開始するか否かの判定用の情報（限定ではなく、チャットの自動応答に関する情報の一例）を表示部２４に表示する。そして、端末２０は、この判定用の情報に対する、自己の端末２０のユーザによる入力に基づいて、自動応答を開始させることを要請するための自動応答開始要請情報を送信する処理や、自動応答を開始したことに関する情報を表示する処理といった、トーク（チャット）の自動応答に関する処理を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末の状態に基づいてチャットの自動応答に関する情報を表示部に表示して、チャットの自動応答が可能であることを端末のユーザに知らせることができる。また、表示した自動応答に関する情報に対する端末のユーザによる入力に基づいて、チャットの自動応答に関連する処理が適切に行われるようにすることができる。

＜第４変形例（２）＞
上記の実施例では、自動応答を開始する端末２０Ｘに対する入力に基づいて、自動応答を終了させることとしたが、これに限定されない。
限定ではなく例として、サーバ１０の制御部１１は、メッセージ自動応答処理期間内に端末２０Ｘに対するメッセージ送信依頼情報をＮ回（「Ｎ」は所定の自然数）受信した場合、メッセージ自動応答処理を終了させ、端末２０Ｘにメッセージ自動応答応対履歴情報を送信するようにしてもよい。

なお、限定ではなく例として、サーバ１０の制御部１１は、メッセージ自動応答処理期間内に端末２０Ｘに対するメッセージ送信依頼情報をＮ回（「Ｎ」は所定の自然数）受信した場合、端末２０Ｘにメッセージ自動応答処理を終了させることを示唆するための自動応答終了示唆情報を送信するようにしてもよい。
この場合、端末２０Ｘの制御部２１は、自動応答終了示唆情報を受信すると、受信した自動応答終了示唆情報を表示部２４に表示させる。そして、限定ではなく例として、端末２０Ｘの制御部２１は、表示された自動応答終了示唆情報に対する入力操作に基づいて、自動応答を終了させることが選択された場合、自動応答終了要請情報をサーバ１０に送信するようにしてもよい。

図４－４左側は、ユーザＡ．Ａの端末２０Ａの表示部２４Ａに表示されるトークリスト画面の一例を示している。
この画面は、図４－１右側のトークリスト画面とは異なり、限定ではなく例として、トークルームリスト項目として、テニスサークルのトークルームリスト項目の上に、ユーザＦ．Ｆのトークルームリスト項目が表示されている。また、ユーザＦ．Ｆのトークルームリスト項目に関連付けて未読数「４」の数字が表示されている。また、ユーザＦ．Ｆが安否情報として「安全」を設定していることに基づいて、ユーザＦ．Ｆのトークルームリスト項目に対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。

本例では、自動応答モードの設定を行っていることに基づいて、自動応答モードに設定された後に他のユーザからメッセージが送信されたトークルームのトークルームリスト項目のうち最も古い時間にメッセージが送信されたトークルーム（ユーザＢ．Ｂのトークルーム）に対応したトークルームリスト項目から、最も新しい時間にメッセージが送信されたトークルーム（ユーザＦ．Ｆのトークルーム）に対応したトークルームリスト項目に亘って、自動応答済み情報（本例では、「自動応答済み」の文字が示されたテロップ）が重畳表示されている。

この例では、ユーザＡ．Ａが自動応答モードに設定してから設定数（１０件）のメッセージを受信したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション（サーバ１０）を発信元とする、ユーザＡ．Ａが自動応答モードに設定してから設定数（限定ではなく例として１０件）のメッセージを受信したことを示すテキスト（自動応答中にメッセージが１０件届きました 自動応答を続けますか？）を含むプッシュ通知ＰＮ５が表示されている。

限定ではなく例として、図４－４左側の表示画面において、プッシュ通知ＰＮ５がユーザＡ．Ａによってタップされると、限定ではなく例として、図４－４右側のような表示がなされる。

この表示画面では、図４－４左側のトークリスト画面に重畳して、安否登録領域Ｒ１がせり上がり表示されるように構成されている。
この場合、安否登録領域Ｒ１では、設定された安否情報を確認するための安否情報確認領域が構成されている。安否情報確認領域には、限定ではなく例として、「以下の内容で登録しています」の文字、「安否メッセージ」の文字、ユーザ状態アイコンＩＣＡＳ（ユーザＡ．Ａ、安全）、「三鷹／自転車で移動中です」の文字が表示されている。
また、その下には、自動応答モードを解除するための自動応答解除領域が構成されている。自動応答解除領域には、限定ではなく例として、「自動応答モードを解除しますか？」の文字と、自動応答モードを解除するための「はい」ボタンＢＴ１３（本例では、「はい」の文字で示されるボタン）と、自動応答モードを解除しないための「いいえ」ボタンＢＴ１４（本例では、「いいえ」の文字で示されるボタン）とが表示されている。

＜第４変形例（３）＞
上記の実施例では、メッセージ自動応答処理をサーバ１０において実行することとしたが、これに限定されない。限定ではなく例として、自動応答を開始することが選択された端末２０Ｘにおいてメッセージ自動応答処理を実行するようにしてもよい。

図４－５は、本変形例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
限定ではなく例として、端末２０Ｘに表示された判定用表示に対する入力操作に基づいて、自動応答を開始することが選択された場合、端末２０Ｘの制御部２１は、メッセージ自動応答処理を開始する（タイミング「ＴＭ４１０」）。

通信Ｉ／Ｆ１４によって端末２０Ｙからメッセージ送信依頼情報を受信すると、サーバ１０の制御部１１は、メッセージ送信依頼情報に基づいて、端末２０Ｘにメッセージ情報を送信する（タイミング「ＴＭ４２０」）。

通信Ｉ／Ｆ２２によってサーバ１０からメッセージ情報を受信すると、端末２０Ｘの制御部２１は、自動応答処理が実行されているか否かを判定する。この例では、端末２０Ｘにおけるメッセージ自動応答処理はタイミング「ＴＭ４１０」～「ＴＭ４４０」の間である場合に実行されている。
従って、メッセージ情報を受信したタイミングがタイミング「ＴＭ４１０」よりも後であり、かつ、タイミング「ＴＭ４４０」よりも前であると判定される場合、端末２０Ｘの制御部２１は、メッセージ自動応答情報を通信Ｉ／Ｆ２２によって端末２０Ｙに送信する（タイミング「ＴＭ４３０」）。なお、端末２０Ｘの制御部２１は、メッセージ自動応答情報を、サーバ１０を介して端末２０Ｙに送信するようにしてもよい。
また、端末２０Ｘの制御部２１は、受信したメッセージ情報を表示部２４に表示させない。

限定ではなく例として、端末２０Ｘに対する入力操作に基づいて、自動応答を終了させることが選択された場合、端末２０Ｘの制御部２１は、自動応答処理を終了させる。そして、メッセージ自動応答処理期間中に受信したメッセージ情報に基づいて、メッセージ自動応答応対履歴情報を生成する（タイミング「ＴＭ４４０」）。

端末２０Ｘの制御部２１は、生成したメッセージ自動応答対応履歴情報を表示部２４に表示させる（タイミング「ＴＭ４５０」）。

＜第５実施例＞
第５実施例は、限定ではなく例として、大規模災害等の災害が発生した場合、一の端末２０（以下、適宜「端末」と称する。）による安否確認登録（限定ではなく例として、安否確認情報の入力と送信）を、他の端末２０（以下、適宜「第１端末」と称する。）のユーザが要求する場合、設定条件に基づいて、端末に対する安否確認登録の要求を行う実施例である。

以下では、前述したように、安否確認アプリケーションによる安否確認サービスを提供する事業者のことを「安否確認サービス事業者」と称する。
なお、安否確認サービス事業者は、安否確認アプリケーションを提供する事業者や、サーバ１０の事業者と表現することもできる。
また、安否確認サービスを提供する事業者という意味で、安否確認サービスの事業者と表現することもできる。

また、以下では、安否確認アプリケーションの名称を、適宜「Ｓａｆｅｔｙ Ｃｏｎｆｉｒｍａｔｉｏｎ Ａｐｐ」と称して図示・説明する。

安否確認アプリケーションでは、限定ではなく例として、安否確認対象としてサーバ１０に登録しているアカウント同士で、安否確認登録の要求を行うことができるように構成することができる。また、限定ではなく例として、安否確認対象としてサーバ１０に登録している一のアカウントが安否確認登録を行うと、他のアカウントは登録された安否確認情報を参照することができる。

以下では、安否確認登録を要求されるユーザアカウントを「被安否登録要求アカウント」、被安否登録要求アカウントに対して安否確認登録を要求するユーザアカウントを「安否登録要求アカウント」と称する。なお、一般に、一のユーザアカウントは安否登録要求アカウントと被安否登録要求アカウントとを兼ねることができる。

なお、安否確認登録の方法は、安否確認アプリケーションや前述のメッセージングアプリケーションを用いて安否確認情報を入力し登録する方法に限定されない。限定ではなく例として、安否確認アプリケーションやメッセージングアプリケーションを用いずに、電話やＦＡＸ等の手段により安否確認情報を伝達する方法や、メッセージングアプリケーションにおけるメッセージとして安否確認情報を伝達する方法を用いるようにしてもよい。

第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図５－１左側は、安否確認アプリケーションのメインメニュー画面であり、画面最上部中央には、安否確認アプリケーションの名称として「Ｓａｆｅｔｙ Ｃｏｎｆｉｒｍａｔｉｏｎ Ａｐｐ」の文字が表示されている。また、画面最上部の右部には、この端末２０Ｙのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＹ．Ｙ」）が表示されている。

また、その下には、安否確認アプリケーションにおけるアプリ内位置表示領域が構成されており、この例では、メインメニュー画面であることに基づいて、「メインメニュー」の文字が表示されている。

アプリ内位置表示領域の下には、災害が発生したことを報知するための災害情報を示す領域である災害情報表示領域が構成されており、この例では、地震が発生したことに基づいて、災害情報が表示されている。また、災害情報表示領域の内部の右下には、ユーザＹ．Ｙが安否情報として「安全」を設定していることに基づいて、「自分のステイタス」の文字と、ユーザ状態アイコン（ユーザＡ．Ａ、安全）とが表示されている。

災害情報表示領域の下には、安否確認アプリケーションにおいてユーザＹ．Ｙと関連付けられているユーザ（以下、「メンバー」として図示・説明する。）のリストが表示されるメンバーリスト表示領域が構成されている。

限定ではなく例として、ある組織で安否確認アプリケーション（安否確認サービス）を利用するような場合、限定ではなく例として、その組織の代表者等のユーザが、サーバ１０に対してメンバーを登録するようにすることができる。このようにすることで、その組織に属する人が、安否確認アプリケーションにおいてメンバーとして関連付けられるようにすることができる。

なお、組織ではなく個人でメンバーを設定するようにすることも可能である。
この場合は、前述したメッセージングアプリケーションにおいて友だちを登録するのと同様に、限定ではなく例として、電話番号やアプリケーションＩＤ等を利用して、個人個人の端末２０のユーザがメンバーを登録するようにすることができる。

この例では、メンバーリスト表示領域には、この端末２０Ｙのアカウント（この例では「ユーザＹ．Ｙ」）と関連付けられたメンバーを一覧表示させるためのメンバーリストが表示されるように構成されている。

メンバーリストがユーザＹ．Ｙによってタップされると、それらのリストが展開され表示される。具体的には、限定ではなく例として、メンバーのアイコンと、ユーザ名とが、メンバーリストの項目として一覧表示される。この例では、限定ではなく例として、メンバーリストがタップされて展開された状態で表示されている。

この画面では、メンバーリストの項目として、ユーザＸ．Ｘに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名等が一覧表示されている。
また、ユーザＸ．Ｘが安否情報を設定していないことに基づいて、ユーザＸ．Ｘに対応したアイコンには、第２不明アイコンＵＩＣ２（本例では、「不明」の文字が示されているアイコン）が重畳表示されている。ユーザＣ．Ｃが安否情報を「安全」に設定していることに基づいて、ユーザＣ．Ｃに対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。ユーザＤ．Ｄが安否情報を「危険」に設定していることに基づいて、ユーザＤ．Ｄに対応したアイコンには、第２危険アイコンＤＩＣ２が重畳表示されている。

限定ではなく例として、図５－１左側のメインメニュー画面において、ユーザＸ．Ｘに対応したメンバーリストの項目がユーザによってタップされると、限定ではなく例として、図５－１右側のメンバー画面に表示が遷移する。

メンバー画面は、限定ではなく例として、選択されたユーザの安否状況に関する情報を表示する画面とすることができる。そして、このメンバー画面には、限定ではなく例として、各々のメンバーの安否確認アプリケーションにおけるアイコン画像、ユーザ名、安否に関する情報（本例では、「安否状況」の文字、第２不明アイコンＵＩＣ２）、そのユーザに安否情報を登録するように促すための安否登録リクエストボタンＢＴ２ａ等を表示させるようにすることができる。

限定ではなく例として、図５－１右側のメンバー画面において、ユーザＸ．Ｘを相手とする安否登録リクエストボタンＢＴ２ａがユーザＹ．Ｙによってタップされると、限定ではなく例として、図５－２左側に示す安否登録リクエスト確認情報ＳＲＩ１がメンバー画面に重畳表示される。

安否登録リクエスト確認情報ＳＲＩ１には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「Ｘ．Ｘに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報ＳＲＩ１の表示を終了するための「ＯＫ」の文字を含むアイコンで示されるＯＫボタンとが含まれる。

ＯＫボタンがタップされ、ユーザＹ．ＹによってユーザＸ．Ｘを相手とする安否登録リクエストが行われたとする。
この場合、ユーザＸ．Ｘの端末２０Ｘには、限定ではなく例として、図５－２右側に示すような画面が表示される。

図５－２右側は、端末２０Ｘの表示部２４Ｘに表示されるメインメニュー画面に重畳して、安否情報を設定するようにリクエストされていることを報知するための安否登録リクエスト確認領域Ｒ２がせり上がり表示されている。

このメインメニュー画面は、図５－１左側で示したメインメニュー画面とは異なり、画面最上部の右部には、この端末２０Ｘのユーザの安否確認アプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＸ．Ｘ」）が表示されている。

また、災害情報表示領域の内部の右下には、ユーザＸ．Ｘが安否情報を設定していないことに基づいて、「自分のステイタスを登録」の文字と、前述した安否登録ボタンＢＴ１と同様の安否登録ボタンＢＴ２とが表示されている。

また、メンバーリストの項目として、ユーザＹ．Ｙに対応したアイコンおよびユーザ名等が一覧表示されている。
また、ユーザＹ．Ｙが安否情報を「安全」に設定していることに基づいて、ユーザＹ．Ｙに対応したアイコンには、第２安全アイコンＳＩＣ２が重畳表示されている。

安否登録リクエスト確認領域Ｒ２には、安否情報を設定していないユーザＸ．Ｘに対してユーザＹ．Ｙから安否情報を設定するように促されている旨のメッセージ（本例では、「安否登録リクエスト」の文字と、「Ｙ．Ｙから安否登録を求められています」の文字、ユーザＹ．Ｙのアイコン→ユーザＸ．Ｘのアイコン）が表示されている。その下には、安否情報を設定するための回答ボタンＢＴ４ａが表示されている。

図５－３左側は、ユーザＹ．Ｙの端末２０Ｙの表示部２４Ｙにおいて、ユーザＹ．ＹによってユーザＸ．Ｘを相手とする２回目の安否登録リクエストを行ったことに基づいて、安否確認アプリケーションのメンバー画面に安否登録リクエスト確認領域が表示されている。この表示画面は、図５－２左側の表示画面と同様であるので説明を省略する。

限定ではなく例として、ユーザＹ．ＹによってユーザＸ．Ｘを相手とする２回目の安否登録リクエスト（安否登録リマインドと捉えてもよい。）が行われたとする。
この場合、ユーザＸ．Ｘの端末２０Ｘには、限定ではなく例として、図５－３右側に示すような画面が表示される。

図５－３右側は、端末２０Ｘの表示部２４Ｘにメインメニュー画面が表示されている。このメインメニュー画面は、図５－３右側の表示画面に対応するが、安否登録リクエストが行われたにも関わらず、メインメニュー画面に重畳して安否登録リクエスト確認領域Ｒ２が表示されていない。

＜処理＞
図５－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

ここでは、表示画面と同様に、
・安否登録要求アカウント＝端末２０ＹのユーザＹ．Ｙ（限定ではなく、第１端末のユーザの一例）のアカウント
・被安否登録要求アカウント＝端末２０ＸのユーザＸ．Ｘ（限定ではなく、端末のユーザの一例）のアカウント
とする場合の処理を例示する。

端末２０Ｙの制御部２１は、限定ではなく例として、災害情報を表示させると（Ｙ１２０）、被安否登録要求アカウントにおける安否確認登録を要求するための安否登録リクエストを行うか否かの判定用画面を表示部２４に表示させる（Ｙ４１０）。

限定ではなく例として、判定用画面に対する入力操作に基づいて、安否登録リクエストを行うことが選択されたと判定される場合（Ｙ４１０：ＹＥＳ）、端末２０Ｙの制御部２１は、限定ではなく例として、被安否登録要求アカウントのアプリケーションＩＤを含む安否登録リクエスト要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｙ４２０）。
安否登録リクエストを行うことが選択されないと判定される場合（Ｙ４１０：ＮＯ）、端末２０Ｙの制御部２１は、Ｙ４２０のステップをスキップさせる。

サーバ１０の制御部１１は、限定ではなく例として、災害情報を送信すると（Ｓ１２０）、通信Ｉ／Ｆ１４によって被安否登録要求アカウントに対する安否登録リクエスト要求情報を受信したか否かを判定する（Ｓ４１０）。
安否登録リクエスト要求情報を受信したと判定する場合（Ｓ４１０：ＹＥＳ）、サーバ１０の制御部１１は、被安否登録要求アカウントに関する設定条件が成立しているか否かを判定する（Ｓ４２０）。設定条件については後述する。

設定条件が成立していると判定する場合（Ｓ４２０：ＹＥＳ）、サーバ１０の制御部１１は、安否確認登録を要求するための安否登録リクエスト情報を被安否登録要求アカウントの端末２０Ｘに送信する（Ｓ４３０）。

なお、安否登録リクエスト情報に、安否登録要求アカウントに関する情報（限定ではなく例として、アプリケーションＩＤ）を含めるようにしてもよいし、そうしなくてもよい。
また、安否登録リクエスト情報は、受信した安否登録リクエスト要求情報をそのまま中継して送信するようにしてもよい。

設定条件が成立していない判定する場合（Ｓ４２０：ＮＯ）、サーバ１０の制御部１１は、Ｓ４３０のステップをスキップさせる。

安否登録リクエスト要求情報を受信しないと判定する場合（Ｓ４１０：ＮＯ）、サーバ１０の制御部１１は、Ｓ４２０～Ｓ４３０のステップをスキップさせる。

端末２０Ｘの制御部２１は、限定ではなく例として、災害情報を表示させると（Ｘ１２０）、通信Ｉ／Ｆ２２によって安否登録リクエスト情報を受信したか否かを判定する（Ｘ４３０）。
安否登録リクエスト情報を受信したと判定する場合（Ｘ４３０：ＹＥＳ）、端末２０Ｘの制御部２１は、受信した安否登録リクエスト情報を表示部２４に表示させる（Ｘ４４０）。
安否登録リクエスト情報を受信していないと判定する場合（Ｘ４３０：ＮＯ）、端末２０Ｘの制御部２１は、Ｘ４４０のステップをスキップさせる。

端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１と、サーバ１０の制御部１１とは、処理を終了させるか否かを判定する（Ｘ４５０、Ｙ４５０、Ｓ４５０）。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間（限定ではなく例として、一週間）が経過した場合や、サーバ１０のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。

処理を終了させると判定された場合（Ｘ４５０：ＹＥＳ、Ｙ４５０：ＹＥＳ、Ｓ４５０：ＹＥＳ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、処理を終了させる。

処理を終了させないと判定された場合（Ｘ４５０：ＮＯ、Ｙ４５０：ＮＯ、Ｓ４５０：ＮＯ）、端末２０Ｘの制御部２１は、限定ではなく例として、Ｘ４３０のステップに処理を戻す。また、端末２０Ｙの制御部２１は、限定ではなく例として、Ｙ４１０のステップに処理を戻す。また、サーバ１０の制御部１１は、限定ではなく例として、Ｓ４１０のステップに処理を戻す。

なお、本フローチャートにおいて、Ｓ１２０・Ｘ１２０・Ｙ１２０の処理を省略し、サーバ１０における災害情報の送信と各端末２０における災害情報の表示とは行わないようにしてもよい。

また、端末２０ＸにおけるＸ４３０～Ｘ４４０のステップは必須ではない。これは、災害により被安否登録要求アカウントの端末２０Ｘがオフライン状態となっている可能性が生じるためである。

図５－５は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。本タイミングチャートを用いて前述の設定条件の一例について説明する。ここでは、設定条件を、「被安否登録要求アカウントに対して１回目の安否登録リクエスト要求が行われた場合」とする。

限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われる（Ｙ４１０：ＹＥＳ）と、第１の安否登録リクエスト要求情報がサーバ１０に送信される（Ｙ４２０）（タイミング「ＴＭ５１０」）。
すると、サーバ１０の制御部１１は、設定条件が成立していると判定し（４２０：ＹＥＳ）、第１の安否登録リクエスト情報を端末２０Ｘに送信する（Ｓ４３０）（タイミング「ＴＭ５２０」）。

端末２０Ｘの制御部１１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（Ｘ４４０）（タイミング「ＴＭ５３０」）。

その後、限定ではなく例として、再度端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われる（Ｙ４１０：ＹＥＳ）と、第２の安否登録リクエスト要求情報がサーバ１０に送信される（Ｙ４２０）（タイミング「ＴＭ５４０」）。
すると、サーバ１０の制御部１１は、設定条件が成立していないと判定し（Ｓ４２０：ＮＯ）、第２の安否登録リクエスト情報を端末２０Ｘに送信しない。

限定ではなく例として、再度端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われる（Ｙ４１０：ＹＥＳ）と、第３の安否登録リクエスト要求情報がサーバ１０に送信される（Ｙ４２０）（タイミング「ＴＭ５５０」）。
すると、サーバ１０の制御部１１は、設定条件が成立していないと判定し（Ｓ４２０：ＮＯ）、第３の安否登録リクエスト情報を端末２０Ｘに送信しない。

本設定条件では、安否登録要求アカウントから一の被安否登録要求アカウントに対して複数回の安否登録リクエスト要求が行われる場合、初めの一回目のみ被安否登録要求アカウントの端末２０に対して安否登録リクエストが行われる例を示している。このように設定条件を定めることで、非常時に被安否登録要求アカウントのユーザが繰り返し安否登録を求められる煩わしさから解放することができる。

なお、上記の設定条件とは異なり、設定条件を「被安否登録要求アカウントに対してＮ回目（「Ｎ」は自然数）の安否登録リクエスト要求が行われた場合」としてもよい。この場合、安否登録要求アカウントから一の被安否登録要求アカウントに対してＮ回の安否登録リクエスト要求が行われると、サーバ１０の制御部１１は、初めて安否登録リクエスト要求情報を被安否登録要求アカウントの端末２０に送信する。

＜第５実施例の効果＞
本実施例は、サーバ１０（限定ではなく、端末と通信するサーバの一例）は、被安否登録要求アカウントのユーザ（限定ではなく、端末のユーザの一例）に対する第１の安否登録リクエスト要求情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ１４によって安否登録要求アカウントのユーザの端末２０（限定ではなく、第１端末の一例）から受信する。そして、サーバ１０は、受信した第１の安否登録リクエスト要求情報と、設定された条件とに基づき、第１の安否登録リクエスト情報（限定ではなく、安否確認に関する第２情報の一例）を通信Ｉ／Ｆ１４によって被安否登録要求アカウントのユーザの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに対する安否確認の依頼に関する第１情報を第１端末から受信した上で、その第１情報と設定された条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる。

＜第５変形例（１）＞
上記の実施例では、設定条件に基づいて、サーバ１０は被安否登録要求アカウントに対して１回のみ安否登録リクエスト情報を送信することとしたが、これに限定されない。限定ではなく例として、サーバ１０は、設定条件に基づいて、複数回安否登録リクエスト情報を送信するようにしてもよい。
また、上記の実施例では、安否登録要求アカウントと被安否登録要求アカウントとは異なるアカウントとして説明したが、これに限定されない。

以下説明する画面図では、メッセージングアプリケーションにおける実装例を例示する。

図５－６は、本実施例の手法をメッセージングアプリケーションに適用した場合のユーザＡ．Ａの端末２０Ａの表示部２４に表示されるメッセージングアプリケーションのホーム画面の一例を示している。
このホーム画面では、図１－１２左側に示したホーム画面とは異なり、友だちリストには、友だちリストの項目として、 ユーザＢ．Ｂに対応したアイコンおよびユーザ名、ユーザＣ．Ｃに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名、ユーザＥ．Ｅに対応したアイコンおよびユーザ名、ユーザＦ．Ｆに対応したアイコンおよびユーザ名等が一覧表示されている。

また、ユーザＢ．Ｂが安否情報を設定していないことに基づいて、友だちリストのユーザＢ．Ｂに対応したアイコンには、第１不明アイコンＵＩＣ１（本例では、「？」の文字が示されているアイコン）が重畳表示されている。ユーザＣ．Ｃが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザＣ．Ｃに対応したアイコンには、第１危険アイコンＤＩＣ１が重畳表示されている。ユーザＤ．Ｄが安否情報として「安全」を設定していることに基づいて、ユーザＤ．Ｄに対応したアイコンに、第１安全アイコンＳＩＣ１が重畳表示されている。ユーザＥ．Ｅが安否情報として「安全」を設定していることに基づいて、ユーザＥ．Ｅに対応したアイコンに、第１安全アイコンＳＩＣ１が重畳表示されている。ユーザＦ．Ｆが安否情報として「安全」を設定していることに基づいて、ユーザＦ．Ｆに対応したアイコンに、第１安全アイコンＳＩＣ１が重畳表示されている。

限定ではなく例として、図５－６左側のホーム画面において、ユーザＢ．Ｂに対応した友だちリストの項目がユーザによってタップされると、限定ではなく例として、図５－６中央のユーザＢ．Ｂのプロフィール画面に表示が遷移する。

このプロフィール画面は、図２－５右側に示した例とは異なり、ユーザＢ．Ｂのプロフィールを示すアイコンおよびユーザ名の下に、ユーザＢ．Ｂの安否に関する情報として、第２不明アイコンＵＩＣ２が表示されている。また、そのユーザを相手としたトークを行うためのボタン、そのユーザを相手とした音声通話を行うためのボタン、および、そのユーザを相手としたビデオ通話を行うためのボタンの下には、そのユーザに安否情報を設定するように促すための、前述した安否登録リクエストボタンＢＴ２ａと同様の安否登録リクエストボタンＢＴ２ｂが表示されている。

限定ではなく例として、図５－６中央のプロフィール画面において、ユーザＢ．Ｂを相手とする安否登録リクエストボタンＢＴ２ｂがユーザによってタップされると、限定ではなく例として、図５－６右側に示すように、安否登録リクエスト確認情報ＳＲＩ２がプロフィール画面に重畳表示される。

安否登録リクエスト確認情報ＳＲＩ２には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「Ｂ．Ｂに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報ＳＲＩ２の表示を終了するための「ＯＫ」の文字を含むアイコンで示されるＯＫボタンとが含まれる。

図５－７左側は、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるトークルーム画面の一例を示している。
このトークルーム画面では、図１－１０中央に示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザＢ．Ｂが、公式アカウントとしてメッセージングアプリケーションに登録されている安否確認サービスのＯＡアカウントを相手としてトークを行うためのトークルームであることを示す文字（本例では「安否確認サービス」）が表示されている。

トーク領域には、限定ではなく例として、ＯＡアカウントからのコンテンツとして、「こちらは安否確認応答サービスです ２０ＸＸ／０８／０４ ９：３９ 茨城県沖を震源とする地震が発生しました」の文字を含む災害発生コンテンツＤＣＴ１が表示されている。
また、その下には、ＯＡアカウントからのコンテンツとして、「安否登録リクエスト 以下の友だちから安否登録を求められています」、ユーザＡ．Ａのアイコン画像とユーザ名、およびそのリクエストに回答するための回答ボタンＢＴ４ｂを含む安否登録リクエストコンテンツＲＣＴ１が表示されている。

限定ではなく例として、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われた後、ユーザＣ．ＣによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。
この場合、ユーザＣ．Ｃの端末２０Ｃには、限定ではなく例として、図５－７中央に示すようなプロフィール画面に安否登録リクエスト確認情報ＳＲＩ３が重畳表示される。

このプロフィール画面では、図５－６右側に示したプロフィール画面とは異なり、画面最上部の右側には、この端末２０Ｃのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＣ．Ｃ」）が表示されている。

安否登録リクエスト確認情報ＳＲＩ３には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「Ｂ．Ｂに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報ＳＲＩ３の表示を終了するための「ＯＫ」の文字を含むアイコンで示されるＯＫボタンとが表示されている。

限定ではなく例として、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われた後、ユーザＣ．ＣによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。
この場合、ユーザＢ．Ｂの端末２０Ｂには、限定ではなく例として、図５－７右側に示すようなトークルーム画面が表示される。

このトークルーム画面の表示例では、ユーザＣ．ＣによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたにも関わらず、トーク領域に新たな安否登録リクエストコンテンツが表示されておらず、図５－７左側と同様の表示画面となっている。

図５－８左側は、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるトークルーム画面の一例を示している。このトークルーム画面は、図５－７左側の表示画面と同様であるので説明を省略する。

限定ではなく例として、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われた後、上記のようにユーザＣ．ＣによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。さらに、他のユーザ（この例では、ユーザＤ．Ｄ、ユーザＦ．Ｆ）によってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。
この場合、ユーザＢ．Ｂの端末２０Ｂには、限定ではなく例として、図５－８右側に示すようなトークルーム画面が表示される。

このトークルーム画面の表示例では、図５－７右側に示したトークルーム画面とは異なり、トーク領域には、限定ではなく例として、「９：４３」の安否登録リクエストコンテンツＲＣＴ１の下に、ＯＡアカウントからのコンテンツとして、「安否登録リクエスト 以下の友だちから安否登録を求められています」、ユーザＡ．Ａのアイコン画像とユーザ名、ユーザＣ．Ｃのアイコン画像とユーザ名、ユーザＤ．Ｄのアイコン画像とユーザ名、ユーザＦ．Ｆのアイコン画像とユーザ名、およびそのリクエストに回答するための回答ボタンＢＴ４ｂを含む、上記の「９：４３」から６０分後の「１０：４３」の新たな安否登録リクエストコンテンツＲＣＴ２が表示されている。

なお、安否登録リクエストコンテンツ等の情報を、上記のように安否確認サービスのＯＡアカウントのトークルームの画面に表示させるのではなく、他の画面に表示させてもよい。
限定ではなく例として、図５－７の表示画面例において、ユーザＡ．Ａからの安否登録リクエストコンテンツを、ユーザＡ．Ａとトークを行うためのトークルーム画面に表示させてもよいし、友だちリスト画面に表示させてもよいし、トークリスト画面に表示させてもよい。

図５－９は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

ここでは、表示画面とは異なり、
・端末２０ＸのユーザＸ．Ｘ＝表示画面における端末２０ＡのユーザＡ．Ａ
・端末２０ＹのユーザＹ．Ｙ＝表示画面における端末２０ＢのユーザＢ．Ｂ
とする場合の処理を例示する。
なお、他の端末２０Ｃ等についても端末２０Ｘや端末２０Ｙと同様に処理を実行することが可能である。

各装置の制御部は、限定ではなく例として、安否確認処理を実行すると（Ｘ２１０・Ｙ２１０・Ｓ２１０）、安否登録リクエスト処理を実行する（Ｘ４８０・Ｙ４８０・Ｓ４８０）。

図５－１０は、安否登録リクエスト処理の一例を示すフローチャートである。図の見方は、図５－９と同様である。
端末２０Ｘの制御部２１は、限定ではなく例として、端末２０ＹのユーザＹ．Ｙに対して安否確認登録を要求するための安否登録リクエストを行うか否かの判定用画面を表示部２４に表示させるなどして、端末２０Ｙに対して安否登録リクエストを行うか否かを判定する（Ｙ４４１０ｙ）。

限定ではなく例として、判定用画面に対する入力操作に基づいて、安否登録リクエストを行うことが選択されたと判定される場合（Ｘ４４１０ｙ：ＹＥＳ）、端末２０Ｘの制御部２１は、限定ではなく例として、端末２０ＹのアプリケーションＩＤを含む安否登録リクエスト要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｘ４４２０ｙ）。
安否登録リクエストを行うことが選択されないと判定される場合（Ｘ４４１０ｙ：ＮＯ）、端末２０Ｘの制御部２１は、Ｘ４４２０ｙのステップをスキップさせる。

サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｙのアカウントを被安否登録要求アカウントとする安否登録リクエスト要求情報を受信したか否かを判定する（Ｓ４４１０ｙ）。
端末２０Ｙに対する安否登録リクエスト要求情報を受信したと判定する場合（Ｓ４４１０ｙ：ＹＥＳ）、サーバ１０の制御部１１は、被安否登録要求アカウントの端末２０（この場合、端末２０Ｙ）に関する複合設定条件が成立しているか否かを判定する（Ｓ４４２０ｙ）。複合設定条件については後述する。

端末２０Ｙに対する複合設定条件が成立していると判定する場合（Ｓ４４２０ｙ：ＹＥＳ）、サーバ１０の制御部１１は、安否確認登録を要求するための安否登録リクエスト情報を被安否登録要求アカウントの端末２０Ｙに送信する（Ｓ４４３０ｙ）。なお、安否登録リクエスト情報に、安否登録要求アカウントに関する情報（限定ではなく例として、アプリケーションＩＤ）を含めるようにしてもよいし、そうしなくてもよい。

端末２０Ｙに対する複合設定条件が成立していない判定する場合（Ｓ４４２０ｙ：ＮＯ）、サーバ１０の制御部１１は、Ｓ４４３０ｙのステップをスキップさせる。

何れの端末２０からも端末２０Ｙに対する安否登録リクエスト要求情報を受信しないと判定する場合（Ｓ４４１０ｙ：ＮＯ）、サーバ１０の制御部１１は、Ｓ４４２０ｙ～Ｓ４４３０ｙのステップをスキップさせる。

端末２０Ｙの制御部２１は、限定ではなく例として、端末２０ＸのユーザＸ．Ｘに対する安否登録リクエストを行う場合、安否登録リクエスト要求情報をサーバ１０に送信する（Ｙ４４１０ｘ・Ｙ４４２０ｘ）。各ステップは、限定ではなく例として、Ｘ４４１０ｙ・Ｘ４４２０ｙと同様に実行することができる。

サーバ１０の制御部１１は、被安否登録要求アカウントを端末２０ＸのアカウントとしてＳ４４１０ｘ～Ｓ４４３０ｘの各ステップを実行する。各ステップは、限定ではなく例として、Ｓ４４１０ｙ～Ｓ４４３０ｙと同様に実行することができる。

また、端末２０Ｘの制御部２１は、他の端末２０のアカウントを被安否登録要求アカウントとして、Ｘ４４１０ｙ・Ｘ４４２０ｙと同様の処理を実行する。サーバ１０の制御部１１は、被安否登録要求アカウントを変えながらＳ４４１０ｘ～Ｓ４４３０ｘの各ステップと同様の処理を実行する。

他の端末２０においても同様である。

端末２０Ｙの制御部２１は、通信Ｉ／Ｆ２２によって安否登録リクエスト情報を受信したか否かを判定する（Ｙ４４３０）。
安否登録リクエスト情報を受信したと判定する場合（Ｙ４４３０：ＹＥＳ）、端末２０Ｙの制御部２１は、受信した安否登録リクエスト情報を表示部２４に表示させる（Ｙ４４４０）。
安否登録リクエスト情報を受信していないと判定する場合（Ｙ４４３０：ＮＯ）、端末２０Ｙの制御部２１は、Ｙ４４４０のステップをスキップさせる。

他の端末２０においても同様である。

図５－９に戻り、端末２０Ｘの制御部２１と、端末２０Ｙの制御部２１と、サーバ１０の制御部１１とは、処理を終了させるか否かを判定する（Ｘ４９０、Ｙ４９０、Ｓ４９０）。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間（限定ではなく例として、一週間）が経過した場合や、サーバ１０のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。

処理を終了させると判定された場合（Ｘ４９０：ＹＥＳ、Ｙ４９０：ＹＥＳ、Ｓ４９０：ＹＥＳ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、処理を終了させる。

処理を終了させないと判定された場合（Ｘ４９０：ＮＯ、Ｙ４９０：ＮＯ、Ｓ４９０：ＮＯ）、各端末２０の制御部２１およびサーバ１０の制御部１１は、限定ではなく例として、再度安否確認処理を実行する（Ｘ２１０、Ｙ２１０、Ｓ２１０）。

他の端末２０においても同様である。

なお、図５－９において、サーバ１０における災害情報の各端末２０への送信と、各端末２０における災害情報の表示処理とは実行されなくてもよい。
また、任意のタイミングにおいてチャット処理が実行されるようにしてもよい。

ここで、限定ではなく例として、各端末２０に対する複合設定条件を以下の２つの条件の組み合わせとして定義する。
・「初期送信設定条件」：被安否登録要求アカウントの端末２０に対して安否登録リクエスト情報を始めて送信する条件。
・「再送信設定条件」：被安否登録要求アカウントの端末２０に対して安否登録リクエスト情報を送信後、再度安否登録リクエスト要求情報を送信する条件。

初期送信設定条件としては、限定ではなく例として、以下の例が挙げられる。
（Ｘ１）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した場合。
（Ｘ２）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＬ回（「Ｌ」は自然数）受信した場合。
（Ｘ３）．サーバ１０が一の安否登録要求アカウントの端末２０から一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した場合。
（Ｘ４）．サーバ１０が一の安否登録要求アカウントの端末２０から一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＭ回（「Ｍ」は自然数）受信した場合。
（Ｘ５）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した後、第１設定時刻（限定ではなく例として、「毎時０分０秒」）となった場合。
（Ｘ６）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した後、第１設定時間（限定ではなく例として、「５分間」）が経過した場合。
（Ｘ７）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した後、再度災害情報を送信する場合。
（Ｘ８）．上記の（Ｘ１）～（Ｘ７）の任意の組み合わせ。

また、再送信設定条件としては、限定ではなく例として、以下の例が挙げられる。
（Ｙ１）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＰ回（「Ｐ」は自然数）受信した場合。なお、Ｐ回には、初期送信設定条件成立までにサーバ１０が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
（Ｙ２）．サーバ１０が初期送信設定条件を満たした一の安否登録要求アカウントの端末２０とは異なる安否登録要求アカウントの端末２０から、一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を初めて受信した場合。
（Ｙ３）．サーバ１０が初期送信設定条件を満たした一の安否登録要求アカウントの端末２０とは異なる安否登録要求アカウントの端末２０から、一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＱ回（「Ｑ」は自然数）受信した場合。なお、Ｑ回には、初期送信設定条件成立までにサーバ１０が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
（Ｙ４）．サーバ１０が初期送信設定条件を満たした一の安否登録要求アカウントの端末２０から、一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＲ回（「Ｒ」は自然数）受信した場合。なお、Ｒ回には、初期送信設定条件成立までにサーバ１０が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
（Ｙ５）．サーバ１０が一の被安否登録要求アカウントの端末２０に安否登録リクエスト情報を送信した後、第２設定時刻（限定ではなく例として、「日付が変わる０時０分０秒」や「災害発生時刻＋Ｔ時間後」（「Ｔ」は自然数））となった場合。
（Ｙ６）．サーバ１０が一の被安否登録要求アカウントの端末２０に安否登録リクエスト情報を送信した後、第２設定時間（限定ではなく例として、「６０分間」）が経過した場合。
（Ｙ７）．サーバ１０が一の被安否登録要求アカウントの端末２０に安否登録リクエスト情報を送信した後、再度災害情報を送信する場合。
（Ｙ８）．上記の（Ｙ１）～（Ｙ７）の任意の組み合わせ。

限定ではなく例として、図５－６～図５－８の例は、複合設定条件を（Ｘ１）＋（Ｙ６）とした場合の一例である。

図５－１１は、限定ではなく例として、複合設定条件を（Ｘ１）＋（Ｙ１）とした場合、各装置が実行する処理のタイミングの一例を示すタイミングチャートである。

限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ６１０」）。
すると、サーバ１０の制御部１１は、初期送信設定条件（Ｘ１）が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ６２０」）。
端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ６３０」）。

その後、限定ではなく例として、再度端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第２の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ６４０」）。
すると、サーバ１０の制御部１１は、再送信設定条件（Ｙ１）が成立していないと判定し、第２の安否登録リクエスト情報を端末２０Ｘに送信しない（タイミング「ＴＭ６５０」）。

端末２０Ｘに対する安否登録リクエスト要求操作が各端末２０において実行され、第Ｐ＋１の安否登録リクエスト要求情報をサーバ１０が受信する（タイミング「ＴＭ６６０」）。すると、サーバ１０の制御部１１は、再送信設定条件（Ｙ１）が成立したと判定し、第２の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ６７０」）。
端末２０Ｘの制御部２１は、第２の安否登録リクエスト情報を受信すると、第２の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ６８０」）。

初期送信設定条件と再送信設定条件とは、限定ではなく例として、以下の考え方に従って設定することができる。

・第１の考え方
一の被安否登録要求アカウントにおいて初期送信設定条件を満たし、一度安否登録リクエスト情報を送信した後は基本的には再送しない。これにより、通信帯域が切迫し、端末２０の動作時間にも限りが生じる可能性が高い非常時において、被安否登録要求アカウントの端末２０に対して、繰り返し同じ種類の情報を送信することを防ぐことができる。しかしながら、安否確認登録を行うことを被安否登録要求アカウントのユーザが忘れている可能性があるため、再送信設定条件を満たす場合、リマインダーとして再度安否登録リクエスト情報を送信する。

・第２の考え方
一の被安否登録要求アカウントにおいて初期送信設定条件を満たす場合は即座に安否登録リクエスト情報を送信する。その後、再送信設定条件を満たす場合においても、即座に安否登録リクエスト情報を送信する。これにより、サーバ１０が被安否登録要求アカウントの端末２０に対して安否登録リクエスト情報を送信する頻度を制御することができ、端末２０において頻繁に安否登録リクエスト情報が表示される煩わしさからユーザを解放することができる。

なお、複合設定条件を初期送信設定条件のみの条件としてもよい。この場合、安否登録リクエスト情報の再送は実行されない。

また、限定ではなく例として、再送信設定条件に、再送信回数に関する条件を付加するようにしてもよい。再送信回数に関する条件として、限定ではなく例として、安否登録リクエスト情報を被安否登録要求アカウントの端末２０に再送信する上限回数を定めるようにしてもよい。

本変形例は、前述した設定条件は、初期送信設定条件（限定ではなく、端末のユーザに対する第１情報をサーバが最初に受信した場合、第２情報を端末に送信する条件の一例）に基づいて送信し、再送信設定条件（限定ではなく、端末のユーザに対する第１情報を最初に受信した後、第２情報を端末に送信する第１設定条件の一例）に基づいて送信する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報と、端末のユーザに対する第１情報をサーバが最初に受信した場合、第２情報を端末に送信し、端末のユーザに対する第１情報を最初に受信した後、第１設定条件に基づいて第２情報を端末に送信する条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる

また、この場合、再送信設定条件は、設定された時刻、または設定された時間（時間間隔）に基づいて安否登録リクエスト情報（限定ではなく、第２情報の一例）を被安否登録要求アカウントのユーザの端末２０に送信する条件を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１情報と、設定された時刻、または設定された時間に基づいて第２情報を端末に送信する条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる。

また、この場合、再送信設定条件は、最初にサーバ１０が安否登録リクエスト要求情報（限定ではなく、第１情報の一例）を受信した後、サーバ１０が受信した安否登録リクエスト要求情報（限定ではなく、第１情報の一例）の数に基づいて安否登録リクエスト情報（限定ではなく、第２情報の一例）を被安否登録要求アカウントのユーザの端末２０に送信する条件を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１情報と、最初に第１情報を受信した後、サーバが受信した第１情報の数に基づいて第２情報を端末に送信する条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる。

また、この場合、再送信設定条件は、再度災害が発生したことを示す情報等の情報（限定ではなく、災害に関する情報の一例）に基づいて安否登録リクエスト情報（限定ではなく、第２情報の一例）を被安否登録要求アカウントのユーザの端末２０に送信する条件を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１情報と、災害に関する情報に基づいて第２情報を端末に送信する条件とに基づき、安否確認に関する第２情報を端末に送信して、その端末のユーザの安否を尋ねることができる。

また、この場合、安否登録リクエスト情報（限定ではなく、第２情報の一例）は、被安否登録要求アカウントのユーザ（限定ではなく、端末のユーザの一例）を含むトークルーム（限定ではなく、チャットルームの一例）に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、安否確認に関する第２情報が、端末のユーザを含むチャットルームに表示されるようにすることで、分かり易い形で、端末のユーザに安否を尋ねることができる。

＜第５変形例（２）＞
上記の変形例では、サーバ１０は、複合設定条件が成立する場合、安否登録リクエスト情報を被安否登録要求アカウントの端末２０に送信することとしたが、これに限定されない。限定ではなく例として、サーバ１０は、後述する送信停止設定条件を満たす場合、初期送信設定条件や再送信設定条件が成立しても安否登録リクエスト情報を被安否登録要求アカウントの端末２０に送信しないようにしてもよい。

図５－１２左側は、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるトークルーム画面の一例を示している。このトークルーム画面は、図５－７左側の表示画面と同様であるので説明を省略する。

限定ではなく例として、図５－１２左側のトークルーム画面において、安否登録リクエストコンテンツＲＣＴ１に含まれる回答ボタンＢＴ４ｂがユーザによってタップされると、限定ではなく例として、図５－１２中央に示すホーム画面に表示が遷移する。

このホーム画面では、図４－１左側に示すホーム画面とは異なり、画面最上部の右部には、この端末２０Ｂのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＢ．Ｂ」）が表示されている。

限定ではなく例として、図５－１２中央の安否登録領域Ｒ１において、危険ボタンＤＢＴがユーザＢ．Ｂによってタップされ、安否メッセージの定型文として「怪我をした」のテキストがユーザＢ．Ｂによって選択された後、登録ボタンＢＴ３がユーザＢ．Ｂによってタップされた場合における、ユーザＡ．Ａの端末２０Ａに表示されるトークリスト画面の一例を図５－１２右側に示す。このトークリスト画面は、図１－１９右側のトークリスト画面と同様であるので説明を省略する。

限定ではなく例として、図５－１２右側のトークリスト画面において、ユーザＢ．Ｂのトークルームリスト項目のうちアイコン画像がユーザによってタップされると、限定ではなく例として、図５－１３左側のユーザＢ．Ｂに対応したプロフィール画面に表示が遷移する。

このプロフィール画面では、図５－６中央に示した例とは異なり、画面最上部の右部に、この端末２０Ｂのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例では「ユーザＡ．Ａ」）が表示されている。また、ユーザＢ．Ｂのプロフィールを示すアイコンおよびユーザ名の下には、ユーザＢ．Ｂの安否に関する情報として、第２危険アイコンＤＩＣ２が表示されている。

限定ではなく例として、図５－１３左側のプロフィール画面において、ユーザＢ．Ｂを相手とする安否登録リクエストボタンＢＴ２ｂがユーザによってタップされると、限定ではなく例として、図５－１３中央に示す安否登録リクエスト確認情報ＳＲＩ４がプロフィール画面に重畳表示される。
この安否登録リクエスト確認情報ＳＲＩ４は、図５－６右側の安否登録リクエスト確認情報ＳＲＩ２と同様であるので説明を省略する。

限定ではなく例として、ユーザＢ．Ｂが安否登録リクエストに回答した後、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたとする。
この場合、ユーザＢ．Ｂの端末２０Ｂには、限定ではなく例として、図５－１３右側に示すようなトークルーム画面が表示される。

このトークルーム画面では、ユーザＡ．ＡによってユーザＢ．Ｂを相手とする安否登録リクエストが行われたにも関わらず、トーク領域に新たな安否登録リクエストに対応したＯＡアカウントからの安否登録リクエストコンテンツが表示されておらず、図５－１２左側と同様の表示画面となっている。

本変形例において、送信停止設定条件としては、限定ではなく例として、以下の例が挙げられる。
（Ｚ１）．サーバ１０が一の被安否登録要求アカウントの端末２０から安否確認登録情報を受信した場合。
（Ｚ２）．サーバ１０が一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＵ回（「Ｕ」は自然数）受信した場合。
（Ｚ３）．サーバ１０が特定の安否登録要求アカウントの端末２０から、一の被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報をＶ回（「Ｖ」は自然数）受信した場合。
（Ｚ４）．第３設定時刻（限定ではなく例として、「災害発生時刻＋７２時間後」となった場合）となった場合。
（Ｚ５）．サーバ１０が一の被安否登録要求アカウントの端末２０に安否登録リクエスト情報を送信した後、第３設定時間（限定ではなく例として、「３６時間」）が経過した場合。
（Ｚ６）．サーバ１０が再度災害情報を送信する場合。
（Ｚ７）．上記の（Ｚ１）～（Ｚ６）の任意の組み合わせ。

限定ではなく例として、図５－１２・図５－１３の例は、送信停止設定条件を（Ｚ１）とした場合の一例である。

図５－１４は、限定ではなく例として、複合設定条件を（Ｘ１）＋任意の再送信設定条件＋（Ｚ１）とした場合、各装置が実行する処理のタイミングの一例を示すタイミングチャートである。

限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ７１０」）。
すると、サーバ１０の制御部１１は、初期送信設定条件（Ｘ１）が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ７２０」）。
端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ７３０」）。

その後、限定ではなく例として、安否確認処理が実行され、端末２０Ｘにおいて、安否確認登録情報の入力操作を受け付けると、第１の安否確認登録情報がサーバ１０に送信される（タイミング「ＴＭ７４０」）。そして、サーバ１０は第１の安否確認登録情報を受信する。
サーバ１０の制御部１１は、第１の安否確認登録情報に基づいて、第１の安否情報を生成し、各端末２０に送信する（タイミング「ＴＭ７５０」）。
端末２０Ｙは第１の安否情報を受信すると表示処理を実行する（タイミング「ＴＭ７６０」）。

その後、限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第２の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ７７０」）。
すると、サーバ１０の制御部１１は、送信停止設定条件（Ｚ１）が成立していると判定し、第２の安否登録リクエスト情報を端末２０Ｘに送信しない（タイミング「ＴＭ７８０」）。

なお、端末２０Ｙの制御部２１は、端末２０Ｘのアカウントに関する安否情報を受信した場合、それ以降に端末２０Ｘのアカウントに対する安否登録リクエスト要求操作を受け付けないようにしてもよい。

本変形例は、サーバ１０が、安否登録リクエスト情報（限定ではなく、第２情報の一例）の送信に基づき、安否確認登録情報（限定ではなく、端末のユーザの安否に関する情報を含む第３情報の一例）を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、この安否確認登録情報の受信に基づき、この安否確認登録情報の受信の後に、被安否登録要求アカウントに対する安否登録リクエスト要求情報（限定ではなく、第３情報の一例）を受信した場合、その安否登録リクエスト要求情報に基づく安否登録リクエスト情報の送信を行わない制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第２情報の送信に基づき、端末のユーザの安否に関する情報を含む第３情報を端末から受信した上で、この第３情報の受信に基づいて、第３情報の受信の後に端末のユーザに対する第１情報を受信した場合、第１情報に基づく第２情報の送信を行わないようにすることで、端末のユーザの安否を一旦確認した場合は再度確認せずに済み、端末のユーザが煩わしさを感じないようにすることができる。また、不要な通信をせずに済み、通信量を削減することができる

＜第５変形例（３）＞
上記の実施例では、サーバ１０において設定条件（複合設定条件）の判定を実行することとしたが、これに限定されない。限定ではなく例として、設定条件（複合設定条件）の判定を被安否登録要求アカウントの端末２０で判定するようにしてもよい。

この場合、サーバ１０の制御部１１は、安否登録要求アカウントの端末２０Ｙから被安否登録要求アカウントの端末２０Ｘに対する安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を端末２０Ｘに送信する。
端末２０Ｘの制御部２１は、安否登録リクエスト情報を受信すると、設定条件（複合設定条件）が成立するか否かを判定する。そして、端末２０Ｘの制御部２１は、設定条件（複合設定条件）が成立すると判定する場合、受信した安否登録リクエスト情報を表示部２４に表示させる。
設定条件（複合設定条件）が成立しないと判定する場合、端末２０Ｘの制御部２１は、受信した安否登録リクエスト情報を表示部２４に表示させない。

＜第５変形例（４）＞
上記の実施例では、サーバ１０において設定条件（複合設定条件）の判定を実行することとしたが、これに限定されない。限定ではなく例として、設定条件（複合設定条件）の判定を安否登録要求アカウントの端末２０で判定するようにしてもよい。

この場合、安否登録要求アカウントの端末２０Ｙの制御部２１は、被安否登録要求アカウントの端末２０Ｘに対する安否登録リクエスト要求操作が行われると、設定条件（複合設定条件）が成立するか否かを判定する。そして、端末２０Ｙの制御部２１は、設定条件（複合設定条件）が成立すると判定する場合、サーバ１０に安否登録リクエスト情報を送信する。
サーバ１０の制御部１１は、端末２０Ｙから端末２０Ｘに対する安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を端末２０Ｘに送信する。
端末２０Ｘの制御部２１は、安否登録リクエスト情報を受信すると、表示部２４に表示させる。

設定条件（複合設定条件）が成立しないと判定する場合、端末２０Ｙの制御部２１は、サーバ１０に安否登録リクエスト情報を送信しない。

なお、安否登録要求アカウントの端末２０において設定条件（複合設定条件）を判定させる場合、他の端末２０が被安否登録要求アカウントの端末２０に対する安否登録リクエスト要求情報を送信したか否かは判定できない。そのため、この場合、設定条件（複合設定条件）は自端末における安否登録リクエスト要求操作の回数や、時刻や自端末における安否登録リクエスト要求操作を受け付けてからの時間、災害情報を再度受信したか等に限られる。

＜第６実施例＞
第６実施例は、被安否登録要求アカウントの端末２０において、被安否登録要求アカウントに対して安否登録リクエストを要求した安否登録要求アカウントを確認可能とする実施例である。

第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図６－１は、端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
図６－１左側では、トーク領域の「安否登録リクエスト」と示された安否登録リクエストコンテンツＲＣＴ６内に、回答ボタンＢＴ４ｂの他、自分（ユーザＢ．Ｂ）に対して安否登録リクエストを要求した安否登録要求アカウント（友だち）を確認するための「友だち確認」ボタンＢＴ６が設けられている。この「友だち確認」ボタンＢＴ６がタップされると、図６－１右側のような表示がなされる。

具体的には、画面下部からせり上がるように、自分（ユーザＢ．Ｂ）に対して安否登録リクエストを要求した安否登録要求アカウントに関する情報を含む安否登録リクエスト要求ユーザ一覧領域ＳＲＲが表示されている。この例では、「以下の友だちから安否登録を求められています」の文字とともに、この例では、ユーザＡ．Ａ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＦ．Ｆの４名のユーザについて、それぞれアイコンおよびユーザ名が表示されている。また、各々のユーザのアイコンには、そのユーザによって登録された安否ステータス情報に基づくアイコンが重畳して表示されている。

＜処理＞
図６－２は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

ここでは、表示画面とは異なり、
・安否登録要求アカウント＝端末２０ＹのユーザＹ．Ｙのアカウント＝表示画面における端末２０Ａおよび端末２０Ｃ～端末２０Ｆのユーザ
・被安否登録要求アカウント＝端末２０ＸのユーザＸ．Ｘのアカウント＝表示画面における端末２０ＢのユーザＢ．Ｂ
とする場合の処理を例示する。

また、複合設定条件を上記の（Ｘ１）＋（Ｙ１）とした場合について例示する。

限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ８１０」）。
すると、サーバ１０の制御部１１は、初期送信設定条件（Ｘ１）が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ８２０」）。
端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ８３０」）。

その後、限定ではなく例として、他の端末２０において端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第２の安否登録リクエスト要求情報がサーバ１０に送信される。
すると、サーバ１０の制御部１１は、再送信設定条件（Ｙ１）が成立していないと判定し、第２の安否登録リクエスト情報を端末２０Ｘに送信しない（タイミング「ＴＭ８４０」）。

他の端末２０からサーバ１０に送信された安否登録リクエスト要求情報についても同様である。

そして、限定ではなく例として、端末２０Ｘの制御部２１は、安否登録リクエスト要求ユーザ情報要求操作を実行する（タイミング「ＴＭ８５０」）。安否登録リクエスト要求ユーザ情報要求操作において、端末２０Ｘの制御部２１は、限定ではなく例として、第１の安否登録リクエスト情報に対するユーザ操作に基づいて、端末２０Ｘに対する安否登録リクエスト要求情報を送信した安否登録要求アカウントを確認することが選択されたか否かを判定する。そして、安否登録要求アカウントを確認することが選択されたと判定した場合、端末２０Ｘの制御部２１は、安否登録リクエスト要求ユーザ情報要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。

通信Ｉ／Ｆ１４によって端末２０Ｘから安否登録リクエスト要求ユーザ情報要求情報を受信すると（タイミング「ＴＭ８６０」）、サーバ１０の制御部１１は、安否登録リクエスト要求ユーザ一覧情報を通信Ｉ／Ｆ１４によって端末２０Ｘに送信する（タイミング「ＴＭ８７０」）。
ここで、安否登録リクエスト要求ユーザ一覧情報には、限定ではなく例として、タイミング「ＴＭ８６０」以前に受信した端末２０Ｘに対する安否登録リクエスト要求情報における、安否登録要求アカウントに関する情報（限定ではなく例として、アプリケーションＩＤやユーザ名等を含む）の一覧が含まれる。

通信Ｉ／Ｆ２２によってサーバ１０から安否登録リクエスト要求ユーザ一覧情報を受信すると、端末２０Ｘの制御部２１は、受信した安否登録リクエスト要求ユーザ一覧情報を表示部２４に表示させる（タイミング「ＴＭ８８０」）。

＜第６実施例の効果＞
本実施例は、被安否登録要求アカウントの端末２０において、安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、その安否登録リクエスト情報の表示や、その被安否登録要求アカウントに対して安否登録リクエストを要求した安否登録要求アカウントに関する表示（限定ではなく、安否確認に関する第１表示の一例）が表示部２４に表示される。そして、サーバ１０は、被安否登録要求アカウントの端末２０において、その表示に対するその被安否登録要求アカウントのユーザによる入力に基づいて、安否登録リクエスト要求情報（限定ではなく、第１情報の一例）を送信した安否登録要求アカウントの情報（限定ではなく、第１情報を送信したユーザの情報の一例）を通信Ｉ／Ｆ１４によって被安否登録要求アカウントの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、その第１表示に対する、端末のユーザによる入力に基づいて、第１情報を送信したユーザの情報を端末に送信することで、第１情報を送信したユーザの情報を端末のユーザに知らせることができる。

また、この場合、サーバ１０は、一の安否登録要求アカウントの端末２０（限定ではなく、第１端末の一例）から送信された被安否登録要求アカウントに対する安否登録リクエスト要求情報の受信に基づき、安否登録リクエスト情報（限定ではなく、第２情報の一例）を通信Ｉ／Ｆ１４によって被安否登録要求アカウントの端末２０に送信する。また、サーバ１０は、被安否登録要求アカウントに対する安否登録リクエスト要求情報を一の安否登録要求アカウントの端末２０から受信した後、被安否登録要求アカウントに対する安否登録リクエスト要求情報を他の安否登録要求アカウントの端末２０（限定ではなく、第２端末の一例）から通信Ｉ／Ｆ１４によって受信する。また、サーバ１０は、設定された条件を満たさない場合、他の安否登録要求アカウントの端末２０（第２端末）から受信した安否登録リクエスト要求情報に基づく安否登録リクエスト情報を被安否登録要求アカウントの端末２０に送信しない制御を制御部１１によって行う。この場合、サーバ１０は、上記の表示に対する被安否登録要求アカウントのユーザによる入力に基づいて、安否登録リクエスト要求情報（限定ではなく、第１情報の一例）を送信した、一の安否登録要求アカウントの情報（限定ではなく、第１端末のユーザの情報の一例）と、他の安否登録要求アカウントの情報（限定ではなく、第２端末のユーザの情報の一例）とを通信Ｉ／Ｆ１４によって被安否登録要求アカウントの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに対する第１情報を第１端末から受信した後、端末のユーザに対する第１情報を第２端末から受信し、設定された条件を満たさない場合、第２端末から受信した第１情報に基づく第２情報を端末に送信しないようにすることで、端末のユーザが煩わしさを感じないようにすることができる。また、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、その第１表示に対する、端末のユーザによる入力に基づいて、第１情報を送信した、第１端末のユーザの情報と、第２端末のユーザの情報とを含むユーザの情報を端末に送信することで、第１情報を送信した、第１端末のユーザの情報と、第２端末のユーザの情報とを端末のユーザに知らせることができる。

＜第６変形例（１）＞
上記の実施例では、被安否登録要求アカウントの端末２０Ｘにおいて安否登録リクエスト要求ユーザ情報要求操作が実行されると、サーバ１０から端末２０Ｘに安否登録リクエスト要求ユーザ情報が送信されることとしたが、これに限定されない。

図６－３は、本変形例における表示画面の一例を示す図である。
図６－３左側、中央は、それぞれ図５－７左側、中央と同様である。

本変形例では、後述するタイミングで、安否登録リクエスト要求ユーザ一覧情報が、サーバ１０から端末２０Ｂに送信される。その結果、端末２０Ｂの表示部２４には、図６－３右側のような表示がなされる。この画面は、図６－３左側に対応する画面であるが、ＯＡからのコンテンツとして、ユーザＢ．ＢがユーザＡ．ＡとユーザＣ．Ｃとから安否登録を要求されていることを示す安否登録リクエストコンテンツＲＣＴ７が示されている。

サーバ１０の制御部１１は、任意のタイミングにおいて、安否登録リクエスト要求ユーザ一覧情報送信条件が成立すると判定した場合、端末２０Ｘに安否登録リクエスト要求ユーザ一覧情報を送信するようにすることができる。

ここで、安否登録リクエスト要求ユーザ一覧情報送信条件としては、限定ではなく例として、以下の例が挙げられる。
・任意の一の端末２０から安否登録リクエスト要求情報を最後に受信した後、設定期間（限定ではなく例として、「３０分」）が経過した場合。
・任意の一の端末２０から安否登録リクエスト要求情報を最後に受信した後、設定時刻（限定ではなく例として、「正午」）となった場合。
・任意の一の端末２０から安否登録リクエスト要求情報を設定回数以上、または設定回数より多く受信した場合。
・各端末２０から安否登録リクエスト要求情報を最後に受信した後、設定期間（限定ではなく例として、「３０分」）が経過した場合。
・各端末２０から安否登録リクエスト要求情報を最後に受信した後、設定時刻（限定ではなく例として、「正午」）となった場合。
・各端末２０から安否登録リクエスト要求情報を設定回数以上、または設定回数より多く受信した場合。
・端末２０Ｘから安否確認登録情報を受信した場合。
・端末２０Ｘに安否登録リクエスト情報を送信する場合。

なお、本変形例における処理は以下のようにしてもよい。
限定ではなく例として、サーバ１０の制御部１１は、安否登録要求アカウントの端末２０から安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を送信するか否かの複合設定条件に関わらず、端末２０Ｘに受信した安否登録要求アカウントに関する情報を送信する。以下では、限定ではなく例として、個別の安否登録リクエスト要求情報に対応する安否登録要求アカウントに関する情報を、「安否登録リクエスト要求ユーザ情報」と称する。

この場合、端末２０Ｘの制御部２１は、サーバ１０から安否登録リクエスト要求ユーザ情報を受信すると、限定ではなく例として、記憶部２８に記憶させる。
そして、端末２０Ｘの制御部２１は、安否登録リクエスト要求ユーザ表示条件が成立すると判定した場合、記憶部２８に記憶された安否登録リクエスト要求ユーザ情報を表示部２４に表示させる。

ここで、安否登録リクエスト要求ユーザ表示条件としては、限定ではなく例として、以下の例が挙げられる。

・安否登録リクエスト要求ユーザ情報要求操作が実行され、端末２０Ｘに対する安否登録リクエスト要求情報を送信した安否登録要求アカウントを確認することが選択された場合。
・サーバ１０から安否登録リクエスト情報を最後に受信後、設定期間（限定ではなく例として、「３０分」）が経過した場合。
・サーバ１０から安否登録リクエスト情報を最後に受信後、設定時刻（限定ではなく例として、「正午」）となった場合。
・サーバ１０から安否登録リクエスト要求ユーザ情報を設定回数以上、または設定回数より多く受信した場合。
・端末２０Ｘにおいて安否確認登録情報の入力が行われた場合。

＜第７実施例＞
第７実施例は、安否確認サービスにおいて、一の災害における安否登録の期間が終了した場合、安否確認登録を受け付けない実施例である。

第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図７－１は、本実施例において端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
この例では、前述したユーザＡ．Ａ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＦ．Ｆの４名のユーザから安否確認登録を要求されていることが示す安否登録リクエストコンテンツＲＣＴ８の下に、ＯＡアカウントからの「２０ＸＸ年８月４日９時３９分」に発生した地震による安否登録を停止することを示す安否登録停止確認コンテンツＳＣＴ１が表示されている。この状態で、安否登録リクエストコンテンツＲＣＴ８内の回答ボタンＢＴ４ｂがタップされると、図７－１右側のような表示がなされる。

この例では、既に安否登録が可能な期間が経過していることに基づいて、図７－１左側の画面の中央部に、「安否登録期間が終了しています」の文字と、キャラクタの画像と、「ＯＫ」ボタンとを含む安否確認登録受付期間終了情報ＥＰＩ１が表示されている。「ＯＫ」ボタンがタップされると、安否確認登録受付期間終了情報ＥＰＩ１の表示は消去されるが、安否確認登録は受け付けられず、ユーザＢ．Ｂは安否確認登録をすることができないように構成されている。

＜処理＞
図７－２は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

ここでは、表示画面とは異なり、
・安否登録要求アカウント＝端末２０ＹのユーザＹ．Ｙのアカウント＝表示画面における端末２０Ａおよび端末２０Ｃ～端末２０Ｆのユーザ
・被安否登録要求アカウント＝端末２０ＸのユーザＸ．Ｘのアカウント＝表示画面における端末２０ＢのユーザＢ．Ｂ
とする場合の処理を例示する。

限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ９１０」）。
すると、サーバ１０の制御部１１は、初期送信設定条件（Ｘ１）が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ９２０」）。
端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ９３０」）。

次いで、サーバ１０の制御部１１は、安否確認登録受付期間終了処理を実行する（タイミング「ＴＭ９４０」）。

安否確認登録受付期間終了処理において、サーバ１０の制御部１１は、限定ではなく例として、サーバ１０のユーザによる入力操作に基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行う。安否確認処理や安否登録リクエスト処理を終了させると判定された場合、サーバ１０の制御部１１は、安否確認登録情報の受信に対する安否情報の送信と、安否登録リクエスト要求情報の受信に対する安否登録リクエスト情報の送信とを停止させる。

なお、安否確認登録受付期間終了処理において、サーバ１０の制御部１１は、限定ではなく例として、災害情報の災害発生日時から設定期間が経過したか否かに基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行うようにしてもよい。また、サーバ１０の制御部１１は、限定ではなく例として、災害情報における安否確認受付終了日時に基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行うようにしてもよい。

その後、端末２０Ｘにおいて、限定ではなく例として、第１の安否登録リクエスト情報に対する入力操作に基づいて、安否確認登録情報を受け付けると、第１の安否確認登録情報がサーバ１０に送信される（タイミング「ＴＭ９５０」）。そして、サーバ１０は第１の安否確認登録情報を受信する（タイミング「ＴＭ９６０」）。

なお、端末２０Ｙにおいて安否登録リクエスト要求操作が実行され、端末２０Ｘが安否登録リクエスト情報を受信することは必須ではない。

サーバ１０の制御部１１は、タイミング「ＴＭ９４０」において安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「ＴＭ９４０」以降に安否確認登録情報を受信した場合（限定ではなく例として、タイミング「ＴＭ９６０」）、安否確認登録の受け付けを終了したことを示す安否確認登録受付期間終了情報を通信Ｉ／Ｆ１４によって安否登録アカウントの端末２０Ｘに送信する（タイミング「ＴＭ９７０」）。

端末２０Ｘの制御部２１は、サーバ１０から安否確認登録受付期間終了情報を受信すると、受信した安否確認登録受付期間終了情報を表示部２４に表示させる（タイミング「ＴＭ９８０」）。

なお、サーバ１０の制御部１１は、タイミング「ＴＭ９４０」において安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「ＴＭ９４０」以降に安否登録リクエスト要求情報を受信した場合、安否確認登録受付期間終了情報を安否登録要求アカウントの端末２０に送信するようにしてもよい。

また、サーバ１０の制御部１１は、限定ではなく例として、タイミング「ＴＭ９４０」以降に、端末２０Ｘから前述した安否登録リクエスト要求ユーザ情報要求情報を受信する場合、安否確認登録受付期間終了情報を端末２０Ｘに送信するようにしてもよい。

＜第７実施例の効果＞
本実施例は、被安否登録要求アカウントの端末２０において、安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、前述した第１表示が表示部２４に表示される。そして、サーバ１０は、安否確認登録受付期間（限定ではなく、安否確認の受付の一例）が終了している場合、その第１表示に対する、その被安否登録要求アカウントのユーザによる入力に基づいて、安否確認登録受付期間終了情報（限定ではなく、安否確認の受付が終了していることに関する情報の一例）を通信Ｉ／Ｆ１４によって被安否登録要求アカウントのユーザの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、安否確認の受付が終了している場合、その第１表示に対する、端末のユーザによる入力に基づいて、安否確認の受付が終了していることに関する情報を端末に送信することで、安否確認の受付が終了していることを端末のユーザに知らせることができる。

＜第７変形例（１）＞
上記の実施例では、安否確認登録受付期間終了処理において安否確認処理や安否登録リクエスト処理を終了させると判定した場合、サーバ１０の制御部１１は、それ以後に安否確認登録情報や安否登録リクエスト要求情報を受信すると、安否確認登録受付期間終了情報を返信する例を例示したが、これに限定されない。
限定ではなく例として、サーバ１０の制御部１１は、第１の災害情報に対する安否確認登録受付期間が終了している場合、第２の災害情報が送信する場合には、第２の災害情報に対する安否確認登録を受け付けるようにしてもよい。

図７－３は、本変形におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｂのデータ構成例である。
アカウント管理データベース１５５Ｂには、アカウントごとの管理データとして、アカウント管理データが記憶される。

各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、友だち管理データと、安否登録データとが記憶される。

アプリケーションＩＤと、友だち管理データとは、限定ではなく例として、アカウント管理データベース１５５Ａと同様に構成することができる。

安否登録データは、このアプリケーションＩＤのアカウントに関連付けられた、安否に関する登録を記憶させるためのデータであり、限定ではなく例として、災害ＩＤと、安否ステータス情報と、安否コメント情報と、安否位置情報とが関連付けて記憶される。

災害ＩＤは、発生した災害、あるいは発生した災害と対応する災害情報を識別するための情報である。この災害ＩＤは、好ましくは災害（災害情報）ごとに一意な値であり、限定ではなく例として、サーバ１０によって災害（災害情報）ごとに一意な値（固有の値）が設定されて記憶される。

安否ステータス情報と、安否コメント情報と、安否位置情報とは、限定ではなく例として、安否登録アカウントの端末２０によって入力される安否確認登録情報に基づいて、設定され、記憶される。なお、安否ステータス情報と、安否コメント情報と、安否位置情報とのうち、任意の要素を省略するようにしてもよい。

図７－４は、本実施例において端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
図７－４左側の画面では、ＯＡアカウントからの「２０ＸＸ年８月４日９時３９分」に発生した地震（限定ではなく、第１災害の一例）による安否登録を停止することを示す安否登録停止確認コンテンツＳＣＴ１の下に、ＯＡアカウントからの「２０ＸＸ年８月１４日１９時２３分」に地震（限定ではなく、第２災害の一例）が発生したことを示す災害発生コンテンツＤＣＴ２が表示されている。限定ではなく例として、安否登録リクエストコンテンツＲＣＴ８内の回答ボタンＢＴ４ｂがタップされると、図７－４中央のような表示がなされる。

具体的には、第１災害について安否確認登録受付期間（安否登録期間）は終了しているが、第２災害について安否登録を行うことは可能であり、安否登録を行うか否かを確認するための安否登録確認情報ＲＣＩ１が、画面中央部にポップアップ形式で表示されている。この情報に含まれる「ＯＫ」ボタンがタップされ、ホーム画面に表示を戻すと、図７－４右側のような表示がなされる。

このホーム画面では、第２災害の発生に関する情報が表示されている。
また、安否登録を行うための安否登録領域Ｒ１がホーム画面の下部からせり上がるように表示されている。この安否登録領域Ｒ１の構成例については、前述した通りであるため、説明を省略する。

図７－５は、限定ではなく例として、本実施例における各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
まず、サーバ１０の制御部１１は、限定ではなく例として、サーバ１０のユーザによる入力操作に基づいて、第１災害における安否確認処理や安否登録リクエスト処理を開始させるための第１災害安否確認登録受付処理を実行する（タイミング「ＴＭ１００５」）。第１災害安否確認登録受付処理において、サーバ１０の制御部１１は、第１災害と紐付けるための災害ＩＤを生成する。なお、第１災害安否確認登録受付処理に伴い、サーバ１０の制御部１１は、各端末２０に第１の災害情報を送信するようにしてもよい。また、第１の災害情報に第１災害と紐付けられた災害ＩＤを含めるようにしてもよい。

なお、サーバ１０の制御部１１は、不図示の災害情報サーバから受信した災害状況情報に基づいて、第１災害安否確認登録受付処理を実行するようにしてもよい。

次いで、限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ１０１０」）。
すると、サーバ１０の制御部１１は、初期送信設定条件が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ１０１５」）。
端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ１０２０」）。

次いで、サーバ１０の制御部１１は、第１災害における安否確認登録受付期間終了処理を実行する（タイミング「ＴＭ１０２５」）。
その後、サーバ１０の制御部１１は、第２災害における安否確認処理や安否登録リクエスト処理を開始させるための第２災害安否確認登録受付処理を実行する（タイミング「ＴＭ１０３０」）。なお、第２災害安否確認登録受付処理に伴い、サーバ１０の制御部１１は、各端末２０に第２の災害情報を送信するようにしてもよい。また、第２の災害情報に第２災害と紐付けられた災害ＩＤを含めるようにしてもよい。

その後、端末２０Ｘにおいて、限定ではなく例として、第１の安否登録リクエスト情報に対する入力操作に基づいて、安否確認登録情報を受け付けると、第１の安否確認登録情報がサーバ１０に送信される（タイミング「ＴＭ１０３５」）。そして、サーバ１０は第１の安否確認登録情報を受信する（タイミング「ＴＭ１０４０」）。なお、第１の安否確認登録情報に、第１災害と紐付けられた災害ＩＤを含めるようにしてもよい。

なお、端末２０Ｙにおいて安否登録リクエスト要求操作が実行され、端末２０Ｘが第１の安否登録リクエスト情報を受信することは必須ではない。

サーバ１０の制御部１１は、タイミング「ＴＭ１０２５」において第１災害における安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「ＴＭ１０２５」以降に第１災害と紐付けられた災害ＩＤを含む安否確認登録情報を受信した場合（限定ではなく例として、タイミング「ＴＭ１０４０」）、第１災害における安否確認登録の受け付けを終了したことを示す第１災害安否確認登録受付期間終了情報を通信Ｉ／Ｆ１４によって安否登録アカウントの端末２０Ｘに送信する（タイミング「ＴＭ１０４５」）。

また、サーバ１０の制御部１１は、限定ではなく例として、第１災害安否確認登録受付期間終了情報を送信すると、第２災害安否確認登録受付処理が実行されている場合、第２災害に対する安否確認登録を受け付けていることを示す第２災害安否確認登録受付開始情報を安否登録アカウントの端末２０Ｘに送信する（タイミング「ＴＭ１０５０」）。なお、第２災害安否確認登録受付開始情報に、第２災害と紐付けられた災害ＩＤを含めるようにしてもよい。

端末２０Ｘの制御部２１は、サーバ１０から第１災害安否確認登録受付期間終了情報を受信すると、受信した第１災害安否確認登録受付期間終了情報を表示部２４に表示させる（タイミング「ＴＭ１０５５」）。
また、端末２０Ｘの制御部２１は、サーバ１０から第２災害安否確認登録受付開始情報を受信すると、受信した第２災害安否確認登録受付開始情報を表示部２４に表示させる（ＴＭ１０５０）。

ここで、第２災害安否確認登録受付開始情報は、第１災害とは異なる新たな安否確認登録が始まったことを示す情報でもよいし、第２災害情報を含む第２災害に対する安否確認登録の受け付け表示に関する情報でもよい。

なお、サーバ１０の制御部１１は、タイミング「ＴＭ１０２５」において第１災害における安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「ＴＭ１０２５」以降に第１災害と紐付けられた安否登録リクエスト要求情報を受信した場合、第１災害安否確認登録受付期間終了情報を安否登録要求アカウントの端末２０に送信するようにしてもよい。

また、サーバ１０の制御部１１は、タイミング「ＴＭ１０３０」以降に安否登録リクエスト要求情報を受信した場合、第２災害に対する安否登録リクエスト要求を被安否登録要求アカウントの端末２０に送信するようにしてもよい。

なお、サーバ１０の制御部１１は、第１災害における安否確認登録受付期間終了処理において第１災害における安否確認処理や安否登録リクエスト処理を終了させると判定する場合、端末２０から安否確認登録情報を受信せずとも、各端末２０に第１災害安否確認登録受付期間終了情報を送信するようにしてもよい。
この場合、端末２０Ｘの制御部２１は、第１災害安否確認登録受付期間終了情報を受信すると、第１災害に対する安否確認登録を受け付けないように制御するようにしてもよい。

なお、サーバ１０の制御部１１は、第１の安否確認登録情報に災害ＩＤが含まれていない場合、第１の安否確認登録情報を受信したタイミングがタイミング「ＴＭ１０２５」以降かつタイミング「ＴＭ１０３０」以前である場合、第１災害安否確認登録受付期間終了情報を安否登録アカウントの端末２０Ｘに送信するようにしてもよい。
また、第１の安否確認登録情報に災害ＩＤが含まれず、第１の安否確認登録情報を受信したタイミングがタイミング「ＴＭ１０２５」以降かつタイミング「ＴＭ１０３０」以降である場合、サーバ１０の制御部１１は、受信した第１の安否確認登録情報に基づいて、第２災害に対する安否情報を生成し、各端末２０に送信するようにしてもよい。

なお、サーバ１０の制御部１１は、限定ではなく例として、タイミング「ＴＭ１０３０」以降に、端末２０Ｘから第１災害における安否登録リクエスト要求ユーザ情報要求情報を受信する場合、第１災害安否確認登録受付期間終了情報と第２災害安否確認登録受付開始情報とを端末２０Ｘに送信するようにしてもよい。

本変形例は、被安否登録アカウントの端末２０において、一の災害（限定ではなく、第１災害の一例）の安否登録リクエスト要求情報（限定ではなく、第１情報の一例）に基づく安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、その一の災害について、前述した第１表示が表示部２４に表示される。そして、サーバ１０は、一の災害の安否確認登録受付期間（限定ではなく、第１災害の安否確認の受付の一例）が終了し、別の災害（限定ではなく、第２災害の一例）の安否確認登録受付期間（限定ではなく、第２災害の安否確認の受付の一例）が開始されている場合、その第１表示に対する、その被安否登録要求アカウントのユーザによる入力に基づいて、第１災害安否確認登録受付期間終了情報（限定ではなく、第１災害の安否確認の受付が終了していることに関する情報の一例）と、第２災害安否確認登録受付開始情報（限定ではなく、第２災害の安否確認の受付が開始されていることに関する情報の一例）とを通信Ｉ／Ｆ１４によって被安否登録要求アカウントのユーザの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第１災害の第１情報に基づく第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、第１災害の安否確認の受付が終了し、第２災害の安否確認の受付が開始されている場合、その第１表示に対する、端末のユーザによる入力に基づいて、第１災害の安否確認の受付が終了していることに関する情報と、第２災害の安否確認の受付が開始されていることに関する情報とを端末に送信することで、第１災害の安否確認の受付が終了していることと、第２災害の安否確認の受付が開始されていることとを端末のユーザに知らせることができる。

また、本変形例は、被安否登録要求アカウントの端末２０において、安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、前述した第１表示が表示部２４に表示される。そして、サーバ１０は、安否確認登録受付期間（限定ではなく、安否確認の受付の一例）が終了している場合、その第１表示に対する入力を受け付けないことを示す情報を通信Ｉ／Ｆ１４によって被安否登録要求アカウントの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示部に表示され、安否確認の受付が終了している場合、その第１表示に対する入力を不可にするための情報を端末に送信することで、第１表示に対する入力を受け付けないようにすることができる。

＜第７変形例（２）＞
上記の実施例では、端末２０Ｘのユーザは、安否確認登録情報を送信する前に安否確認登録受付期間が終了しているか否かを知ることができなかったが、これに限定されない。限定ではなく例として、安否登録リクエスト情報に安否登録期間（安否登録が可能な期間）や安否登録期限（安否登録の終期））に関する情報を含めるようにしてもよい。

なお、これらの情報は、前述した第１表示を表示部２４に表示する表示期間に関する情報（表示期限に関する情報）としてもよい。また、前述した第１表示から安否確認の回答（安否登録）を行うための入力が可能な入力期間に関する情報（入力期限に関する情報）としてもよい。

図７－６左側は、本変形例において端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
この画面では、トーク領域における安否登録リクエストコンテンツＲＣＴ９内に、安否確認の回答を行うことが可能な回答期間に関する情報として、回答期限までの残り時間の情報を含む回答ボタンＢＴ４ｃが設けられている。

この例では、「９時４１分」に安否登録が停止されることとしている。そして、その時刻までの残り時間が表示されている。安否の回答をせずに「９：４１」になると、図７－６右側のような表示がなされる。

この例では、安否登録リクエストコンテンツＲＣＴ９の下に、ＯＡアカウントからの「２０ＸＸ年８月４日９時３９分」に発生した地震による安否登録を停止することを示す安否登録停止確認コンテンツＳＣＴ１が表示されている。また、安否登録リクエストコンテンツＲＣＴ９の回答ボタンＢＴ４ｃの中の回答期間に関する情報の表示が消去されるとともに、回答ボタンＢＴ４ｃがグレーアウトして表示されており、回答ボタンＢＴ４ｃをタップしても安否を回答することができないようになっている。

端末２０Ｘの制御部２１は、安否登録リクエスト情報に含まれる安否登録期間や安否登録期限が過ぎた場合、限定ではなく例として、安否登録リクエスト情報に対する入力に基づいて、安否確認登録情報の入力を受け付けないようにすることができる。

本変形例は、安否登録リクエスト情報（限定ではなく、第２情報の一例）は、安否登録期間や安否登録期限等に関する情報を含む。そして、被安否登録要求アカウントの端末２０では、この安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、前述した第１表示が表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第１表示が端末の表示部に表示される有効期限に関する情報、または、第１表示に対する入力が可能な有効期限に関する情報を含む第２情報の受信に基づき、安否確認に関する第１表示が表示されて、端末のユーザがその第１表示を確認できるようにすることができる。

＜第７変形例（３）＞
上記の実施例では、サーバ１０において一の災害に対する安否確認登録の受付是非を判定したが、これに限定されない。限定ではなく例として、各端末２０において、安否確認登録や安否登録リクエスト要求の受付是非を判定できるようにしてもよい。

この場合、限定ではなく例として、サーバ１０の制御部１１は、災害情報にその災害に対する安否確認登録の受付期限に関する情報を含め、各端末２０に送信する。そして、各端末２０の制御部２１は、受信した安否確認登録の受付期限に関する情報に基づいて、安否確認登録操作または安否登録リクエスト要求操作時に、安否確認登録情報または安否登録リクエスト要求を受け付けるか否かを判定するようにできる。
限定ではなく例として、各端末２０の制御部２１は、受付期限を過ぎている場合、安否確認登録情報または安否登録リクエスト要求の送信を受け付けないようにすることができる。

＜第７変形例（４）＞
安否登録期間や安否登録期限が経過しても、登録済みの安否情報が、安否参照アカウントの端末２０に表示されるようにしてもよいし、表示されないようにしてもよい。

＜第８実施例＞
第８実施例は、安否確認サービスにおけるメンバーまたはメッセージングアプリケーションにおける友だちのブロックに関する実施例である。

以下では、ブロック対象とされるユーザアカウントを「ブロック対象アカウント」、ブロック対象アカウントから送信されるコンテンツをブロックするユーザアカウントを「ブロック実行アカウント」と称する。

第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図８－１は、本実施例における端末２０の表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
図８－１左側は、端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションのホーム画面であり、安否登録領域Ｒ１において危険ボタンＤＢＴがタップされ、安否メッセージ「怪我しちゃった」と、現在の居場所「つくば市」とが入力されて、登録ボタンＢＴ３がタップされた状態が示されている。

図８－１中央は、この場合に端末２０Ａの表示部２４に表示されるメッセージングアプリケーションのトークリスト画面である。ユーザＡ．ＡはユーザＢ．Ｂにブロックされておらず、トークリストのユーザＢ．Ｂの項目には、第２危険アイコンＤＩＣ２が重畳されたユーザＢ．Ｂのアイコン画像、ユーザ名に加えて、前述した複合安否情報「つくば／怪我しちゃった」が表示されている。

一方、図８－１右側は、この場合に端末２０Ｇの表示部２４に表示されるメッセージングアプリケーションのトークリスト画面である。ユーザＧ．ＧはユーザＢ．Ｂにブロックされており、図８－１中央の端末２０Ａの画面とは異なり、トークリストのユーザＢ．Ｂの項目には、第２危険アイコンＤＩＣ２が重畳されたユーザＢ．Ｂのアイコン画像、ユーザ名しか表示されていない。つまり、前述した複合安否情報「つくば／怪我しちゃった」は表示されておらず、「危険」であることはわかるが、安否メッセージや居場所はわからないようになっている。

なお、ブロックされたユーザの端末２０において、安否位置情報と安否コメント情報とを両方とも表示させないようにするのではなく、いずれか一方の情報は表示させるようにしてもよい。

＜処理＞
図８－２は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
この図では、左側から順に、端末２０Ｘの制御部２１が実行する処理、端末２０Ｙの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

ここでは、表示画面とは異なり、
・ブロック対象アカウント＝端末２０ＹのユーザＹ．Ｙのアカウント＝表示画面における端末２０ＡのユーザＡ．Ａ
・ブロック実行アカウント＝端末２０ＸのユーザＸ．Ｘのアカウント＝表示画面における端末２０ＢのユーザＢ．Ｂ
とする場合の処理を例示する。

限定ではなく例として、端末２０Ｘの制御部２１は、ユーザ操作に基づいて、ブロック対象アカウント（この場合、端末２０Ｙのアカウント）からのコンテンツをブロックさせるためのブロック要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ１１０５」）。ブロック要求情報には、端末２０ＹのアプリケーションＩＤを含めるようにしてもよい。

通信Ｉ／Ｆ１４によって端末２０Ｘからブロック要求情報を受信すると、サーバ１０の制御部１１は、ブロック処理を実行する（タイミング「ＴＭ１１１０」）。サーバ１０の制御部１１は、ブロック処理の実行後、限定ではなく例として、チャット処理において、端末２０Ｙから端末２０Ｘに対するメッセージ送信依頼情報を受信する場合、端末２０Ｘにメッセージ送信依頼情報に基づくメッセージ情報を送信しない。

次いで、限定ではなく例として、端末２０Ｙにおいて端末２０Ｘに対する安否登録リクエスト要求操作が行われると、第１の安否登録リクエスト要求情報がサーバ１０に送信される（タイミング「ＴＭ１１１５」）。
すると、サーバ１０の制御部１１は、初期送信設定条件が成立していると判定し、第１の安否登録リクエスト情報を端末２０Ｘに送信する（タイミング「ＴＭ１１２０」）。
端末２０Ｘの制御部２１は、第１の安否登録リクエスト情報を受信すると、第１の安否登録リクエスト情報を表示部２４に表示させる（タイミング「ＴＭ１１２５」）。

なお、サーバ１０の制御部１１は、ブロック対象アカウントの端末２０Ｙからブロック実行アカウントの端末２０Ｘへの安否登録リクエスト要求情報を受信する場合、安否登録リクエスト情報をブロック実行アカウントの端末２０Ｘに送信しないようにしてもよい。

端末２０Ｘの制御部２１は、限定ではなく例として、第１の安否登録リクエスト情報における第２表示に対する入力操作に基づいて、限定ではなく例として、安否ステータス情報を受け付け、受け付けた第１の安否ステータス情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ１１３０」）。
また、端末２０Ｘの制御部２１は、限定ではなく例として、第１の安否登録リクエスト情報における第３表示に対する入力操作に基づいて、限定ではなく例として、安否コメント情報を受け付け、受け付けた第１の安否コメント情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（タイミング「ＴＭ１１３５」）。

なお、画面図で例示したように、第２表示と第３表示とを同じ表示画面内に含むことに限定されない。限定ではなく例として、端末２０Ｘの制御部２１は、第２表示に対する入力操作を実行すると、第３表示を表示部２４に表示させ、第３表示に対する入力操作を受け付けるようにしてもよい。

サーバ１０の制御部１１は、端末２０Ｘから第１の安否ステータス情報と、第１の安否コメント情報とを受信する。そして、サーバ１０の制御部１１は、第１の安否ステータス情報のみを含む第１の安否情報をブロック対象アカウントの端末２０Ｙに送信する（タイミング「ＴＭ１１４０」）。
また、サーバ１０の制御部１１は、第１の安否ステータス情報と、第１の安否コメント情報とを含む第１の安否情報をブロック対象アカウント以外の各端末２０に送信する（タイミング「ＴＭ１１５０」）。

端末２０Ｙの制御部２１は、サーバ１０から第１の安否ステータス情報のみを含む第１の安否情報を受信すると、受信した第１の安否情報を表示部２４に表示させる（タイミング「ＴＭ１１４５」）。

なお、第２表示と第３表示とにおいて受け付ける安否確認登録情報の組み合わせは、上記の組み合わせに限定されない。
ここで、第２表示に対して入力される安否登録情報を「第１安否情報」、第３表示に対して入力される安否登録情報を「第２安否情報」と称する。ブロック実行アカウントの端末２０において、第１安否情報と第２安否情報とが入力されると、ブロック対象アカウントの端末２０には、第１安否情報のみを含む安否情報が送信される。また、ブロック対象アカウント以外の各端末２０には、第１安否情報と第２安否情報とを含む安否情報が送信される。

なお、ブロック対象アカウントの端末２０に、第１安否情報と第２安否情報とを含む安否情報が送信されるようにしてもよい。

図８－３は、第１安否情報と第２安否情報との組み合わせを示す表である。
ここでは、限定ではなく例として、安否登録情報の構成要素を安否ステータス情報と安否コメント情報と安否位置情報として例示するが、他の構成要素が加わる場合にも同様にして第１安否情報と第２安否情報とを定めることができる。

限定ではなく例として、図８－１の例は、パターン（Ｃ）の場合に相当する。
パターン（Ａ）～（Ｃ）では、ブロック対象アカウントの端末２０において、安否ステータス情報は表示されるが、安否コメント情報と安否位置情報とは表示されない。しかし、安否確認登録入力において、安否コメント情報や安否位置情報の入力は安否ステータス情報の入力に比べて手間がかかるため、安否登録アカウントのユーザは安否ステータス情報のみを入力し、安否コメント情報や安否位置情報の入力を省略することが大いに考え得る。そのため、ブロック対象アカウントの端末２０において、安否ステータス情報のみが表示される場合、ブロック対象アカウントのユーザからは安否コメント情報や安否位置情報が表示されていないのか、それともそもそも入力されていないのかを区別することができない。従って、ブロック対象アカウントのユーザは、ブロック実行アカウントのユーザからブロックされていることを認知することが困難である。

なお、サーバ１０の制御部１１は、ブロック実行アカウントの端末２０Ｘから安否確認登録情報を受信する場合、受信した安否確認登録情報に基づく安否確認情報をブロック対象アカウントの端末２０Ｙに送信しないようにしてもよい。

＜第８実施例の効果＞
本実施例は、被安否登録要求アカウントの端末２０において、安否登録リクエスト情報（限定ではなく、第２情報の一例）の受信に基づき、前述した第１表示が表示部２４に表示され、この第１表示に対する入力に基づいて、第２表示と、第２表示とは異なる第３表示とが表示部２４に表示される。サーバ１０は、被安否登録要求アカウントの端末２０に表示された第２表示に対する入力に基づいて、被安否登録要求アカウントの端末２０のユーザによって入力された一の安否情報（限定ではなく、第１安否情報の一例）を通信Ｉ／Ｆ１４によって受信し、第３表示に対する入力に基づいて、被安否登録要求アカウントの端末２０のユーザによって入力された別の安否情報（限定ではなく、第２安否情報の一例）を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、被安否登録要求アカウントのユーザによって友だち登録されているなどの被安否登録要求アカウントのユーザに関連付けられたユーザ（限定ではなく、端末のユーザに関連付けられたユーザの一例）の端末２０に一の安否情報（第１安否情報）を送信する一方、被安否登録要求アカウントのユーザによって設定されたユーザの端末２０に他の安否情報（第２安否情報）を送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第２情報の受信に基づき、安否確認に関する第１表示が表示され、その第１表示に対する入力に基づいて、第２表示と、第２表示とは異なる第３表示とが表示される。そして、第２表示に対する入力に基づいて、端末のユーザによって入力された安否に関する第１安否情報を端末から受信し、第３表示に対する入力に基づいて、端末のユーザによって入力された安否に関する第２安否情報を受信することができる。また、端末のユーザに関連付けられたユーザに第１安否情報を送信して、端末のユーザの安否を知らせることができる。また、端末のユーザによって設定されたユーザに第２安否情報を送信して、端末のユーザの安否を知らせることができる。

また、この場合、被安否登録要求アカウントのユーザによって設定されたユーザは、被安否登録要求アカウントのユーザによって友だち登録されているなどの被安否登録要求アカウントのユーザに関連付けられたユーザのうち、被安否登録要求アカウントのユーザによってブロックされたユーザ以外のユーザを含むようにすることができる。
このような構成により得られる実施例の効果の一例として、上記の端末のユーザによって設定されたユーザに、端末のユーザに関連付けられたユーザのうち端末のユーザによってブロックされたユーザ以外のユーザが含まれるようにすることで、端末のユーザによってブロックされたユーザ以外のユーザには第２安否情報を送信するようにすることができる。

＜第８変形例（１）＞
上記の実施例では、ブロック対象アカウントの端末２０には、第１安否情報のみを含む安否情報が送信され、ブロック対象アカウント以外の各端末２０には、第１安否情報と第２安否情報とを含む安否情報が送信されることとしたが、これに限定されない。限定ではなく例として、各端末２０には、第１安否情報と第２安否情報とを含む安否情報が送信されるが、ブロック対象アカウントの端末２０では、第１安否情報のみが表示されるようにしてもよい。

この場合、限定ではなく例として、サーバ１０の制御部１１は、ブロック実行アカウントの端末２０Ｘからブロック要求情報を受信すると、ブロック対象アカウントの端末２０Ｙに、ブロック実行アカウントの情報（限定ではなく例として、アプリケーションＩＤ）を含む安否表示ブロック要請情報を送信する。
ブロック対象アカウントの端末２０Ｙの制御部２１は限定ではなく例として、安否表示ブロック要請情報を受信した後にブロック実行アカウントを安否登録アカウントとし、第１安否情報と第２安否情報とを含む安否情報を受信する場合、第１安否情報のみを表示部２４に表示させる。

＜第９実施例＞
第９実施例は、安否確認サービスにおけるメンバーまたはメッセージングアプリケーションにおける友だちの安否確認登録状況を簡易に閲覧可能とする実施例である。

第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図９－１は、本実施例において端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションの画面の一例を示す図である。
図９－１左側は、前述したメッセージングアプリケーションのＯＡアカウントとのトーク画面であり、この例では、ＯＡからの安否登録リクエストコンテンツＲＣＴ１がタップされた状態が示されている。この場合、図９－１右側のホーム画面が表示される。

このホーム画面は、メッセージングアプリケーションのホーム画面であり、友だちリストの項目として、ユーザＡ．Ａに対応したアイコンおよびユーザ名、ユーザＤ．Ｄに対応したアイコンおよびユーザ名、ユーザＦ．Ｆに対応したアイコンおよびユーザ名、ユーザＧ．Ｇに対応したアイコンおよびユーザ名等が表示されている。また、各々のユーザのアイコンには、そのユーザによって登録された安否情報を示すアイコンとして、前述した第１安全アイコン、第１危険アイコン、第１不明アイコンが関連付けて表示されている。つまり、安否確認登録状況の一覧画面が表示されている。

さらに、この例では、ユーザＢ．Ｂが安否登録を未だ行っていないことに基づいて、安否登録ボタンＢＴ１が強調表示（限定ではなく例として、点滅表示）されている。

なお、上記のように友だちリストの画面に遷移させるのではなく、トークリスト画面に遷移させてもよく、安否確認登録状況の一覧が表示される画面に遷移させればよい。

＜第９変形例（１）＞
上記の実施例では、安否登録リクエスト情報に対するユーザ操作に基づいて、安否確認登録状況の一覧画面に遷移したが、これに限定されない。限定ではなく例として、安否確認アプリケーションまたはメッセージングアプリケーションのプッシュ通知に対するユーザ操作に基づいて、安否確認登録画面に遷移するようにしてもよい。

・スマートチャット領域内に安否登録リクエスト情報を表示（タップで安否確認登録画面に遷移可能）
・アプリプッシュで安否登録リクエスト情報から安否確認登録画面に遷移

図９－２は、本変形例において端末２０Ｂの表示部２４に表示される画面の一例を示す図である。
図９－２左側は、端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションのトークリスト画面であり、アプリ内位置表示領域の下の、災害が発生したことをトークリスト画面において報知するための災害情報表示領域の内部の右下には、ユーザＢ．Ｂが未だ安否登録を行っていないため安否登録ボタンＢＴ１が表示されている。
また、その下には、ユーザＢ．Ｂに対して安否登録リクエストを行ったユーザのアイコンおよびユーザ名が一覧表示されている。

端末２０Ｂが操作されずに一定時間が経過すると、図９－２中央のようなロック画面が表示される。この例では、ロック画面にアプリプッシュとして、メッセージングアプリケーションを発信元とする安否登録リクエスト情報のプッシュ通知ＰＮ７が表示されている。このプッシュ通知ＰＮ７がタップされると、限定ではなく例として、図９－２右側のメッセージングアプリケーションのホーム画面が表示される。

このホーム画面では、画面下部からせり上がるように安否登録領域Ｒ１が表示されており、安否登録をそのまますぐに行うことができるように構成されている。

なお、図９－２左側の画面における、安否登録リクエストを行っているユーザの一覧が表示される領域（この例では４名のユーザ）がタップされると、図９－２右側のホーム画面が表示されるようにしてもよい。

また、限定ではなく例として、安否登録リクエスト情報を、任意のトークルーム画面の最上部に表示させるようにしてもよい。そして、最上部に表示される安否登録リクエスト情報に対するユーザ操作に基づいて、安否確認登録画面に遷移できるようにしてもよい。

＜他の実施例＞
＜他の実施例（１）＞
上記の実施例では、安否登録アカウントにより入力される安否確認登録情報を、安否確認アプリケーションまたはメッセージングアプリケーションのユーザに対する安否情報の送信のために使用したが、これに限定されない。限定ではなく例として、サーバ１０の制御部１１は、各端末２０より受信した安否確認登録情報を集計処理し、集計結果を救援活動のためのビッグデータとして用いるようにしてもよい。

限定ではなく例として、サーバ１０の制御部１１は、各端末２０より受信した安否ステータス情報と安否位置情報とを集計し、安否ステータス情報が「危険」と入力された地域の偏りを求める。そして、サーバ１０の制御部１１は、「危険」と入力された頻度が高い地域に関する位置情報である救助対象エリア情報を算出する。サーバ１０の制御部１１は、算出された救助対象エリア情報を表示部１３に表示させるようにしてもよい。

なお、サーバ１０の制御部１１は、算出された救助対象エリア情報を通信Ｉ／Ｆ１４によって不図示の災害対策本部サーバに送信するようにしてもよい。

＜他の実施例（２）＞
上記の実施例では、被安否登録要求アカウントの端末２０に対して安否確認登録情報の入力と送信とを促すために安否登録リクエスト要求情報を送信する例について例示したが、これに限定されない。より一般的に、サーバ１０の制御部１１は、任意の情報の入力と送信とを促すためのリクエスト情報を送信するようにしてもよい。

限定ではなく例として、リクエスト情報として、借金の返済を促す要求例（以下、「要望」と称する。）について例示する。
また、以下では、借金の返済を迫られるユーザのアカウントを「被要望要求アカウント」、被要望要求アカウントに対して借金の返済を求めるユーザのアカウントを「要望要求アカウント」と称する。ここで、要望要求アカウントは複数のアカウントとし、限定ではなく例として、「第１の要望要求アカウント」と「第２の要望要求アカウント」と称する。

第１の要望要求アカウントの端末２０は、限定ではなく例として、ユーザ操作に基づいて、被要望要求アカウントに対して要望を伝えるための第１の要望要求情報をサーバ１０に送信する。
サーバ１０の制御部１１は、第１の要望要求アカウントの端末２０から第１の要望要求情報を受信すると、設定条件（複合設定条件）が成立しているか否かを判定する。そして、設定条件（複合設定条件）が成立していると判定する場合、サーバ１０の制御部１１は、第１の要望要求情報に基づく第１の要望情報（この例では借金の返済を促すことに関する情報）を被要望要求アカウントの端末２０に送信する。
被要望要求アカウントの端末２０の制御部２１は、受信した第１の要望情報を表示部２４に表示させる。

次いで、第２の要望要求アカウントの端末２０は、限定ではなく例として、ユーザ操作に基づいて、被要望要求アカウントに対して要望を伝えるための第２の要望要求情報をサーバ１０に送信する。
サーバ１０の制御部１１は、第２の要望要求アカウントの端末２０から第２の要望要求情報を受信すると、設定条件（複合設定条件）が成立しているか否かを判定する。そして、設定条件（複合設定条件）が成立していると判定する場合、サーバ１０の制御部１１は、第２の要望要求情報に基づく第２の要望情報を被要望要求アカウントの端末２０に送信する。被要望要求アカウントの端末２０の制御部２１は、受信した第２の要望情報を表示部２４に表示させる。
設定条件（複合設定条件）が成立しているないと判定する場合、サーバ１０の制御部１１は、第２の要望要求情報に基づく第２の要望情報を被要望要求アカウントの端末２０に送信しない。

すなわち、複数のアカウントを含む要望要求アカウントが一の被要望要求アカウントに対して任意の要望を通達する場合、限定ではなく例として、以下の対応関係を当てはめることができる。
・「安否登録リクエスト要求情報」＝「要望要求情報」
・「安否登録リクエスト情報」＝「要望情報」
・「被安否登録要求アカウント」＝「被要望要求アカウント」
・「安否登録要求アカウント」＝「要望要求アカウント」

この場合、任意のタイミングにおける要望要求情報に基づく要望情報送信の有無は、限定ではなく例として、第５実施例の複合設定条件による制御と同様に制御することができる。すなわち、上記の実施例を参酌すると、初めて一の被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、サーバ１０は被要望要求アカウントの端末２０に要望情報を送信する。そしてサーバ１０はそれ以後にその被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、再度被要望要求アカウントの端末２０に要望情報を送信しないといった制御が実現可能である。また、サーバ１０は、被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、所定の条件を満たす場合、リマインドとして再度被要望要求アカウントの端末２０に要望情報を送信するといった制御も可能である。

なお、要望要求アカウントの端末２０は、被要望要求アカウントの端末２０に対する任意のコンテンツの送信要求（「コンテンツ送信要求情報」と称する。）をサーバ１０に送信するようにしてもよい。サーバ１０の制御部１１は、コンテンツ送信要求情報を受信すると、複合設定条件に基づいて、要望要求アカウントの端末２０にコンテンツ送信要求情報に基づくコンテンツ情報を送信するか否かの制御を実行するようにしてもよい。

本実施例は、被要望要求アカウントの端末２０（限定ではなく、端末の一例）と通信するサーバ１０が、被要望要求アカウントの端末２０のユーザに対するコンテンツの送信の依頼に関する情報（限定ではなく、コンテンツの送信の依頼に関する第１情報の一例）を、一の要望要求アカウントの端末２０（限定ではなく、第１端末の一例）から受信する。そして、サーバ１０は、受信したコンテンツの送信の依頼に関する情報に基づき、コンテンツに関する情報を、通信I／F１４によって被要望要求アカウントの端末２０に送信する。
また、サーバ１０は、被要望要求アカウントの端末２０のユーザに対するコンテンツの送信の依頼に関する情報（限定ではなく、コンテンツの送信の依頼に関する第１情報の一例）を、他の要望要求アカウントの端末２０（限定ではなく、第２端末の一例）から受信する。そして、サーバ１０は、受信したコンテンツの送信の依頼に関する情報と、設定された条件とに基づき、コンテンツに関する情報を、通信I／Ｆ１４によって被要望要求アカウントの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに対するコンテンツの送信の依頼に関する第１情報を第１端末から受信した上で、その第１情報に基づき、コンテンツに関する第２情報を端末に送信することで、限定ではなく例として、コンテンツを送信するように端末のユーザに促すことができる。また、端末のユーザに対するコンテンツの送信の依頼に関する第１情報を第２端末から受信した上で、その第１情報と設定された条件とに基づき、コンテンツに関する第２情報を端末に送信することで、限定ではなく例として、コンテンツを送信するように端末のユーザに促すことができる。

＜その他＞
上記の実施例や変形例で説明した、メッセージングアプリケーション（メッセージングサービス）で実現した内容は、基本的に、第５実施例で説明した安否確認アプリケーション（安否確認サービス）についても同様に適用可能である。

１ 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク

Claims (18)

1. 端末と通信するサーバによって実行されるプログラムであって、
   前記端末のユーザに対する安否確認の依頼に関する第１情報を前記サーバの通信部によって第１端末から受信することと、
   設定された条件と、前記第１端末から送信された前記端末のユーザに対する前記第１情報の受信とに基づき、前記安否確認に関する第２情報を前記通信部によって前記端末に送信することと、
   前記端末のユーザに対する前記第１情報を前記第１端末から受信した後、前記端末のユーザに対する前記第１情報を、前記第１端末とは異なる第２端末から前記通信部によって受信することと、
   前記設定された条件に基づいて、前記第２端末から受信した前記第１情報に基づく前記第２情報を前記端末に送信しない制御を前記サーバの制御部によって行うこととが前記サーバによって実行される。
2. 請求項１に記載のプログラムであって、
   前記設定された条件は、前記端末のユーザに対する前記第１情報を前記サーバが最初に受信した場合、前記第２情報を前記端末に送信し、前記端末のユーザに対する前記第１情報を最初に受信した後、第１設定条件に基づいて前記第２情報を前記端末に送信する条件を含む。
3. 請求項２に記載のプログラムであって、
   前記第１設定条件は、設定された時刻、または設定された時間に基づいて前記第２情報を前記端末に送信する条件を含む。
4. 請求項２または請求項３に記載のプログラムであって、
   前記第１設定条件は、最初に前記第１情報を受信した後、前記サーバが受信した第１情報の数に基づいて前記第２情報を前記端末に送信する条件を含む。
5. 請求項２から請求項４のいずれか一項に記載のプログラムであって、
   前記第１設定条件は、災害に関する情報に基づいて前記第２情報を前記端末に送信する条件を含む。
6. 請求項２から請求項５のいずれか一項に記載のプログラムであって、
   前記第２情報の送信に基づき、前記端末のユーザの安否に関する情報を含む第３情報を前記端末から前記通信部によって受信することと、
   前記第３情報の受信に基づいて、前記第３情報の受信の後に前記端末のユーザに対する前記第１情報を受信した場合、前記第１情報に基づく前記第２情報の送信を行わない制御を前記制御部によって行うこととが前記サーバによって実行される。
7. 請求項１から請求項６のいずれか一項に記載のプログラムであって、
   前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
   前記第１表示に対する、前記端末のユーザによる入力に基づいて、前記第１情報を送信したユーザの情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
8. 請求項７に記載のプログラムであって、
   前記第１表示に対する、前記端末のユーザによる入力に基づいて、前記第１情報を送信した、前記第１端末のユーザの情報と、前記第２端末のユーザの情報とを含む前記ユーザの情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
9. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
   前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
   前記安否確認の受付が終了している場合、前記第１表示に対する、前記端末のユーザによる入力に基づいて、前記安否確認の受付が終了していることに関する情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
10. 請求項９に記載のプログラムであって、
    前記端末は、第１災害の前記第１情報に基づく前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
    前記第１災害の前記安否確認の受付が終了し、第２災害の前記安否確認の受付が開始されている場合、前記第１表示に対する、前記端末のユーザによる入力に基づいて、前記第１災害の前記安否確認の受付が終了していることに関する情報と、前記第２災害の前記安否確認の受付が開始されていることに関する情報とを前記通信部によって前記端末に送信することが前記サーバによって実行される。
11. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
    前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
    前記安否確認の受付が終了している場合、前記第１表示に対する入力を不可にするための情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
12. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
    前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、
    前記第２情報は、前記第１表示が前記端末の表示部に表示される有効期限に関する情報、または、前記第１表示に対する入力が可能な有効期限に関する情報を含み、
    前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示する。
13. 請求項１から請求項１２のいずれか一項に記載のプログラムであって、
    前記端末は、前記第２情報の受信に基づき、前記安否確認に関する第１表示を前記端末の表示部に表示し、前記第１表示に対する入力に基づいて、第２表示と、前記第２表示とは異なる第３表示とが前記端末の表示部に表示され、
    前記第２表示に対する入力に基づいて、前記端末のユーザによって入力された第１安否情報を前記通信部によって前記端末から受信し、前記第３表示に対する入力に基づいて、前記端末のユーザによって入力された安否に関する第２安否情報を前記通信部によって前記端末から受信することと、
    前記端末のユーザに関連付けられたユーザに前記第１安否情報を前記通信部によって送信し、前記端末のユーザによって設定されたユーザに前記第２安否情報を前記通信部によって送信することとが前記サーバによって実行される。
14. 請求項１３に記載のプログラムであって、
    前記設定されたユーザは、前記端末のユーザに関連付けられたユーザのうち、前記端末のユーザによってブロックされたユーザ以外のユーザを含む。
15. 請求項１から請求項１４のいずれか一項に記載のプログラムであって、
    前記第２情報は、前記端末のユーザを含むチャットルームに表示される。
16. 請求項１から請求項１５のいずれか一項に記載のプログラムであって、
    前記第１端末のユーザは、前記端末のユーザと関連付けられたユーザであり、
    前記第２端末のユーザは、前記端末のユーザと関連付けられたユーザである。
17. 端末と通信するサーバの情報処理方法であって、
    前記端末のユーザに対する安否確認の依頼に関する第１情報を前記サーバの通信部によって第１端末から受信することと、
    設定された条件と、前記第１端末から送信された前記端末のユーザに対する前記第１情報の受信とに基づき、前記安否確認に関する第２情報を前記通信部によって前記端末に送信することと、
    前記端末のユーザに対する前記第１情報を前記第１端末から受信した後、前記端末のユーザに対する前記第１情報を、前記第１端末とは異なる第２端末から前記通信部によって受信することと、
    前記設定された条件に基づいて、前記第２端末から受信した前記第１情報に基づく前記第２情報を前記端末に送信しない制御を前記サーバの制御部によって行うこととを含む。
18. 端末と通信するサーバであって、
    前記端末のユーザに対する安否確認の依頼に関する第１情報を第１端末から受信し、設定された条件と、前記第１端末から送信された前記端末のユーザに対する前記第１情報の受信とに基づき、前記安否確認に関する第２情報を前記端末に送信し、前記端末のユーザに対する前記第１情報を前記第１端末から受信した後、前記端末のユーザに対する前記第１情報を、前記第１端末とは異なる第２端末から受信する通信部と、
    前記設定された条件に基づいて、前記第２端末から受信した前記第１情報に基づく前記第２情報を前記端末に送信しない制御を行う制御部とを備える。

Images