(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-09-22
(45)【発行日】2023-10-02
(54)【発明の名称】プログラム、情報処理方法、端末
(51)【国際特許分類】
H04L 51/046 20220101AFI20230925BHJP
H04M 11/00 20060101ALI20230925BHJP
【FI】
H04L51/046
H04M11/00 302
(21)【出願番号】P 2021176907
(22)【出願日】2021-10-28
【審査請求日】2022-09-29
【早期審査対象出願】
(73)【特許権者】
【識別番号】321003371
【氏名又は名称】LINE株式会社
(74)【代理人】
【識別番号】110001759
【氏名又は名称】弁理士法人よつ葉国際特許事務所
(74)【代理人】
【識別番号】100093687
【氏名又は名称】富崎 元成
(74)【代理人】
【氏名又は名称】山田 勉
(74)【代理人】
【識別番号】100168468
【氏名又は名称】富崎 曜
(74)【代理人】
【識別番号】100166176
【氏名又は名称】加美山 豊
(72)【発明者】
【氏名】岩本 俊介
(72)【発明者】
【氏名】濱窄 亮介
【審査官】木村 雅也
(56)【参考文献】
【文献】特開2018-151724(JP,A)
【文献】特開2003-331090(JP,A)
【文献】特開2020-048093(JP,A)
【文献】特開2014-109859(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 51/046
H04M 11/00
(57)【特許請求の範囲】
【請求項1】
第1端末のユーザとのチャットに関連する処理を行う端末によって実行されるプログラムであって、
前記第1端末のユーザによる前記第1端末に対する入力に基づいて、前記第1端末のユーザの安否に関する第1情報を前記端末の通信部によって受信することと、
前記第1端末のユーザと前記端末のユーザとを含
み、前記第1端末と前記端末とで送受信されたコンテンツを表示する第1領域を含むチャットルームを前記端末の表示部に表示することと、
前記第1端末のユーザによって設定された、前記第1端末のユーザを示す第1画像と、前記第1画像に関連付けられた前記第1情報とを、前記チャットルームの前記第1領域とは異なる第2領域に表示する制御と、を前記端末の制御部によって行うこととが前記端末によって実行される。
【請求項2】
請求項1に記載のプログラムであって、
前記第1端末のユーザによって、前記第1端末のユーザの安否に関する前記第1情報が第2情報に変更された場合、前記第2情報を前記通信部によって受信することが前記端末によって実行される。
【請求項3】
請求項2に記載のプログラムであって、
前記第2情報は、前記第1情報から変更されて、前記チャットルームの前記第2領域に表示される。
【請求項4】
請求項3に記載のプログラムであって、
前記第1情報を前記通信部によって受信した後、前記チャットルームを前記表示部に表示した場合、前記第2情報を前記通信部によって受信することが前記端末によって実行される。
【請求項5】
請求項2または請求項3に記載のプログラムであって、
前記第1端末のユーザの情報を前記表示部に表示した場合、前記第2情報を前記通信部によって受信することが前記端末によって実行される。
【請求項6】
請求項5に記載のプログラムであって、
前記第1端末のユーザの情報は、前記第1端末のユーザの安否に関連する前記第1情報を含む、前記第1端末のユーザのステータスに関する情報を含む。
【請求項7】
請求項2または請求項3に記載のプログラムであって、
前記第2情報は、前記第1端末のユーザと、前記端末のユーザとの関係に基づいて送信される。
【請求項8】
請求項1から請求項7のいずれか一項に記載のプログラムであって、
前記第1情報に基づいて、前記チャットルームに関する情報の表示態様を変更する制御を前記制御部によって行うことが前記端末によって実行される。
【請求項9】
請求項8に記載のプログラムであって、
前記第1情報を含む、前記チャットルームに含まれるユーザの安否に関する情報に基づいて、前記チャットルームに関する情報の表示態様を変更する制御を前記制御部によって行うことが前記端末によって実行される。
【請求項10】
請求項1から請求項9のいずれか一項に記載のプログラムであって、
前記端末のユーザに関連付けられたユーザのリストに前記第1情報を表示する制御を前記制御部によって行うことが前記端末によって実行される。
【請求項11】
請求項1から請求項10のいずれか一項に記載のプログラムであって、
前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザの安否に関する第3情報を前記通信部によって送信することが前記端末によって実行される。
【請求項12】
請求項11に記載のプログラムであって、
前記第3情報の送信に基づいて、前記チャットの自動応答に関する情報を前記表示部に表示することと、
前記自動応答に関する情報に対する、前記端末のユーザによる入力に基づいて、前記チャットの自動応答に関する処理を前記制御部によって行うことが前記端末によって実行される。
【請求項13】
請求項1から請求項12のいずれか一項に記載のプログラムであって、
前記端末の状態に基づいて、前記チャットの自動応答に関する情報を前記表示部に表示することと、
前記自動応答に関する情報に対する、前記端末のユーザによる入力に基づいて、前記チャットの自動応答に関する処理を前記制御部によって行うことが前記端末によって実行される。
【請求項14】
請求項1から請求項13のいずれか一項に記載のプログラムであって、
前記第1情報をサーバを介して前記通信部によって受信することが前記端末によって実行される。
【請求項15】
第1端末のユーザとのチャットに関連する処理を行う端末の情報処理方法であって、
前記第1端末のユーザによる前記第1端末に対する入力に基づいて、前記第1端末のユーザの安否に関する第1情報を前記端末の通信部によって受信することと、
前記第1端末のユーザと前記端末のユーザとを含
み、前記第1端末と前記端末とで送受信されたコンテンツを表示する第1領域を含むチャットルームを前記端末の表示部に表示することと、
前記第1端末のユーザによって設定された、前記第1端末のユーザを示す第1画像と、前記第1画像に関連付けられた前記第1情報とを、前記チャットルームの前記第1領域とは異なる第2領域に表示する制御と、を前記端末の制御部によって行うこととを含む。
【請求項16】
第1端末のユーザとのチャットに関連する処理を行う端末であって、
前記第1端末のユーザによる前記第1端末に対する入力に基づいて、前記第1端末のユーザの安否に関する第1情報を受信する通信部と、
前記第1端末のユーザと前記端末のユーザとを含
み、前記第1端末と前記端末とで送受信されたコンテンツを表示する第1領域を含むチャットルームを表示する表示部と、
前記第1端末のユーザによって設定された、前記第1端末のユーザを示す第1画像と、前記第1画像に関連付けられた前記第1情報とを、前記チャットルームの前記第1領域とは異なる第2領域に表示する制御と、を行う制御部とを備える。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、プログラム、情報処理方法、端末、サーバ等に関する。
【背景技術】
【0002】
災害発生時に携帯端末を用いて警報を報知する技術がある(例えば、特許文献1)。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【0004】
本発明の第1の態様によると、第1端末のユーザとのチャットに関連する処理を行う端末によって実行されるプログラムは、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を端末の通信部によって受信することと、第1端末のユーザに関連するチャットの情報に関連付けられた第1情報を端末の表示部に表示することとが端末によって実行される。
本発明の第2の態様によると、第1端末のユーザとのチャットに関連する処理を行う端末の情報処理方法は、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を端末の通信部によって受信することと、第1端末のユーザに関連するチャットの情報に関連付けられた第1情報を端末の表示部に表示することとを含む。
本発明の第3の態様によると、第1端末のユーザとのチャットに関連する処理を行う端末は、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を受信する通信部と、第1端末のユーザに関連するチャットの情報に関連付けられた第1情報を表示する表示部とを備える。
本発明の第4の態様によると、第1端末のユーザとのチャットに関連する処理を行う端末は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を端末の通信部によって受信することと、第1端末のユーザに関連するチャットの情報に関連付けられた第1情報を端末の表示部に表示することとを実行する。
【図面の簡単な説明】
【0005】
【
図1-1】実施形態に係る通信システムのシステム構成の一例を示す図。
【
図1-2】第1実施例に係るサーバの制御部によって実現される機能の一例を示す図。
【
図1-3】第1実施例に係るサーバの記憶部に記憶される情報等の一例を示す図。
【
図1-4】第1実施例に係るアカウント登録データの一例を示す図。
【
図1-5】第1実施例に係るアカウント管理データベースの一例を示す図。
【
図1-6】第1実施例に係る端末の制御部によって実現される機能の一例を示す図。
【
図1-7】第1実施例に係る端末の記憶部に記憶される情報等の一例を示す図。
【
図1-8】第1実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-9】第1実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-10】第1実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-11】第1実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図1-12】第1変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-13】第1変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-14】第1変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図1-15】第1変形例に係るサーバの記憶部に記憶される情報等の一例を示す図。
【
図1-16】第1変形例に係るグループ管理データベースの一例を示す図。
【
図1-17】第1変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-18】第1変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図1-19】第1変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図2-1】第2実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図2-2】第2実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図2-3】第2実施例に係る安否確認処理の流れの一例を示すフローチャート。
【
図2-4】第2実施例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図2-5】第2変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図2-6】第2変形例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図2-7】第2変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図3-1】第3実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図3-2】第3実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図3-3】第3実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図4-1】第4実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図4-2】第4実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図4-3】第4実施例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図4-4】第4変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図4-5】第4変形例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図5-1】第5実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図5-2】第5実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図5-3】第5実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図5-4】第5実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図5-5】第5実施例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図5-6】第5変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図5-7】第5変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図5-8】第5変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図5-9】第5変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。
【
図5-10】第5変形例に係る安否登録リクエスト処理の流れの一例を示すフローチャート。
【
図5-11】第5変形例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図5-12】第5変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図5-13】第5変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図5-14】第5変形例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図6-1】第6実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図6-2】第6実施例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図6-3】第6変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図7-1】第7実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図7-2】第7実施例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図7-3】第7変形例に係るアカウント管理データベースの一例を示す図。
【
図7-4】第7変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図7-5】第7変形例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図7-6】第7変形例に係る端末の表示部に表示される画面の一例を示す図。
【
図8-1】第8実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図8-2】第8実施例に係る各装置が実行する処理のタイミングの一例を示す図。
【
図8-3】第8実施例に係る第1安否情報と第2安否情報との組み合わせを示す図。
【
図9-1】第9実施例に係る端末の表示部に表示される画面の一例を示す図。
【
図9-2】第9変形例に係る端末の表示部に表示される画面の一例を示す図。
【発明を実施するための形態】
【0006】
<法的事項の遵守>
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
【0007】
<実施形態>
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。
【0008】
本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。
【0009】
システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。
【0010】
また、クライアント(クライアント装置)とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
(1)端末&サーバ
(2)サーバ
(3)端末
【0011】
(1)は、限定ではなく例として、少なくとも1つの端末と、少なくとも1つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。
【0012】
サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。
【0013】
具体的には、サーバは、限定ではなく例として、少なくとも1つのプロセッサー(限定ではなく例として、CPU:Central Processing Unit、GPU:Graphics Processing Unit、APU:Accelerated Processing Unit、DSP:Digital Signal Processor(限定ではなく例として、ASIC:Application Specific Integrated Circuit、FPGA:Field Programmable Gate Array)等)、コンピュータ装置(プロセッサー+メモリ)、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか1つの装置の同種を複数備える構成(限定ではなく例として、CPU+CPU、ホモジニアスマルチコアプロセッサー等)や、いずれか1つの装置の異種を複数備える構成(限定ではなく例として、CPU+DSP、ヘテロジニアスマルチコアプロセッサー等)としてもよいし、複数の装置の組み合わせ(限定ではなく例として、プロセッサー+コンピュータ装置、プロセッサー+演算装置、複数の装置をヘテロジニアス化したもの等)であってもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。
【0014】
また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第1処理をプロセッサーが実行し、第2処理を演算装置が実行するように構成されていてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。
【0015】
また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるPaaSやIaaS、SaaSの形態で提供されるようにしてもよい。
【0016】
また、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、(1A)端末の制御部のみ、(1B)サーバの制御部のみ、(1C)端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。
【0017】
また、システムの制御部が行う制御や処理(以下、包括的に「制御等」と称する。)は、(1A)端末の制御部のみによって行うようにしてもよいし、(1B)サーバの制御部のみによって行うようにしてもよいし、(1C)端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
また、(1C)では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
【0018】
また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
限定ではなく例として、サーバは、第1装置と第2装置とを備え、第1装置は第1通信部を有し、第2装置は第2通信部を有する場合、サーバの通信部は、第1通信部と第2通信部とを含む概念としてもよい。
【0019】
(2)は、限定ではなく例として、複数のサーバによって構成されるシステム(以下、「サーバシステム」と称する。)とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。
【0020】
サーバシステムが行う制御等は、複数のサーバのうち、(2A)一のサーバのみによって行うようにしてもよいし、(2B)他のサーバのみによって行うようにしてもよいし、(2C)一のサーバと他のサーバとが行うようにしてもよい。
また、(2C)では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
【0021】
(3)は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム(分散システム)。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース(登録商標)等の近距離無線通信技術を用いてP2P(ピアツーピア)方式等で通信を行うことで実現可能である。
【0022】
なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。
【0023】
以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム(限定ではなく例として、クライアントサーバシステム)を例示する。
なお、サーバとして、上記(2)のサーバシステムを適用することも可能である。
【0024】
また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記(3)のシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管(格納)する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。
【0025】
なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。
【0026】
また、本明細書では、適宜「通信I/Fによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部(プロセッサー等)の制御に基づいて、通信I/Fを介して(通信部を介して)、各種の情報やデータを送受信することを示してもよいものとする。
【0027】
また、本明細書において「関する」、「関連する」と記載された用語について、「Aに関するB」や「Aに関連するB」という場合、限定ではなく例として、「A」と何らかの関係性を有する「B」を意味してよいものとする。この具体例については後述する。
【0028】
また、本明細書において、「AとBとを送信する」、「AとBとを受信する」といったように、装置が2以上のものを対象として処理を行うことには、「A」と「B」とをタイミングを合わせて行うもの(以下、「同時」という。)と、「A」と「B」とをタイミングをずらして行うもの(以下、「非同時」という。)とを含めてよいものとする。
限定ではなく例として、第1情報と第2情報とを送信するという場合、第1情報と第2情報とをタイミングを合わせて送信するものと、第1情報と第2情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ(タイムラグ)を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。
【0029】
なお、「A」と「B」とをタイミングをずらして行うといっても、これはあくまでも「A」と「B」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
限定ではなく例として、上記のように第1情報と第2情報とを送信するという場合、第1情報と第2情報とを送信しさえすればよく、同じ目的で第1情報と第2情報とを送信する場合の他、異なる目的で第1情報と第2情報とを送信する場合も含めてよいものとする。
【0030】
以下の実施例では、ユーザがチャットを行うためのサービス(以下、「チャットサービス」と称する。)の一例として、メッセージングサービス(Messaging Service)を例示する。また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。また、チャットアプリケーションでは、限定ではなく例として、ユーザ間における通話(音声通話やビデオ通話等)を行うことができるようにすることができる。
【0031】
なお、メッセージングサービス:MS(インスタントメッセージサービス:IMSを含む。)は、ソーシャルネットワーキングサービス:SNSの1つの形態(一形態)と考えることもできる。このため、メッセージンサービスとソーシャルネットワーキングサービスとを区別してもよいし、区別しなくてもよい。つまり、ソーシャルネットワーキングサービスにメッセージングサービスを含めてもよいものとする。
【0032】
また、以下の実施例では、メッセージングサービスの一例として、サーバを介して複数の装置(限定ではなく例として、端末)間で、コンテンツを簡単なメッセージの形式で送受するインスタントメッセージングサービス:IMS(Instant Messaging Service)を例示する。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。また、インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザ間における通話(音声通話やビデオ通話等)を行うことができるようにすることができる。
【0033】
チャットルーム(限定ではなく例として、トークルーム)とは、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるUI(User Interface)やGUI(Graphical User Interface)とすることができる。
【0034】
また、トークルームには、一対一のユーザのトークルーム(以下、「一対一トークルーム」と称する。)、複数のユーザを含むグループのトークルーム(以下、「グループトークルーム」と称する。)、公式アカウントのユーザとのトークルーム(以下、「OAトークルーム」と称する。)等を含めることができる。
【0035】
なお、一対一トークルームは、データ管理上、一対一のユーザや一対一のアカウントのトークルームとして管理してもよいし、2名のユーザや2つのアカウントで構成されるグループのトークルームとして管理してもよい。
【0036】
公式アカウントは、一般のユーザではなく事業者のアカウント(事業者のユーザのアカウント)であり、この公式アカウントのユーザも、限定ではなく例として、一般のユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でコンテンツ(メッセージ)の送受信を行うことができるようにすることができる。
【0037】
本明細書において、コンテンツとは、送信元から送信先に送信される情報であってもよい。また、コンテンツは、1または複数のコンテンツであってもよい。
【0038】
コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像(静止画像、動画像の少なくともいずれか一方を含む。)形式の画像コンテンツ、音(音声を含む。)形式の音コンテンツなどを含めてよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報(限定ではなく例として、URI(Uniform Resource Identifier)等を含む。)などのリンクコンテンツを含めてもよいものとする。
【0039】
テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか1つを含めてよいものとする。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも1つを含まなくてもよく、その他のテキストを含んでもよい。
【0040】
画像には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか1つを含めることができる。
【0041】
また、以下の実施例では、災害(大規模災害等)発生時、ユーザが安否確認を行うためのサービスの一例として、安否確認サービス(Safety confirming Service)を例示する。また、安否確認サービスを実現するためのアプリケーションを「安否確認アプリケーション」と称する。
安否確認アプリケーションでは、限定ではなく例として、ユーザが自身の安否に関する情報を登録し、他のユーザの安否に関する情報を参照することができる。
【0042】
安否確認サービス(安否確認アプリケーション)を実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
(A)メッセージングアプリケーションの一機能として安否確認サービスの機能を持たせる形態
(B)安否確認サービスの機能とメッセージングサービスの機能とを有するアプリケーション(統合的なアプリケーション)を構成する形態
(C)安否確認アプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
(D)安否確認アプリケーションを単体のアプリケーションとして構成する形態
【0043】
(A)や(B)の形態では、限定ではなく例として、安否確認サービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
また、この場合、1つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、安否確認アプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、音楽アプリケーションにおけるユーザのアカウントとが自動的に関連付けられる(連携される)ようにすることができる。
【0044】
(C)の形態では、限定ではなく例として、安否確認サービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
また、(C)の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、安否確認アプリケーションにおけるユーザのアカウントとを関連付ける処理(連携する処理)を行うようにすることができる。
【0045】
なお、上記とは異なり、安否確認アプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。
【0046】
<第1実施例>
第1実施例は、限定ではなく例として、大規模災害等の災害が発生した場合、一の端末20(以下、適宜「端末」と称する。)に、他の端末20(以下、適宜「第1端末」と称する。)のユーザ(以下、適宜「第1ユーザ」と称する。)が登録した安否確認に関する情報(以下、「安否確認情報」と称する。)を表示する実施例である。
【0047】
ここで、「安否確認情報」は、限定ではなく例として、以下の3種類の情報に大別することができる。
(A1)安否ステータス情報
ユーザの置かれる状況を示す安全レベルに関するクラス情報。
本実施形態では、限定ではなく例として、ユーザによって登録される安否ステータス情報を「安全」と「危険」の2クラスとする。
なお、安否ステータス情報は、2クラスに限定されない。限定ではなく例として、安否ステータス情報に安否不明であることを示す「不明」のクラスや、災害の被災範囲外であることを示す「エリア外」等のクラスを設けるようにしてもよい。
【0048】
(A2)安否コメント情報
ユーザの安否を伝えるための、安否に関するメッセージ等のコンテンツ情報。
本実施形態では、限定ではなく例として、安否コメント情報をテキストとする。
なお、安否コメント情報は、限定ではなく例として、音声や映像、アイコン等としてもよい。
【0049】
(A3)安否位置情報
安否確認情報を登録するユーザの位置に関する情報。
本実施形態では、限定ではなく例として、安否位置情報を住所で規定されるエリア(限定ではなく例として、市区町村)とする。
なお、安否位置情報は、限定ではなく例として、緯度と経度とで規定される位置座標や、緯度と経度とで規定される位置座標で結ばれるエリアとしてもよい。また、安否位置情報に、高度に関する情報を含めるようにしてもよい。
【0050】
安否確認情報には、安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせを用いることができる。
なお、安否確認情報には、少なくとも、安否ステータス情報または安否コメント情報が含まれることが望ましい。ただし、これに限定されるわけではない。
【0051】
また、表示画面における安否確認情報は、日本語で表示されてもよいし、他の言語(英語等)で表示されてもよい。
限定ではなく例として、「安全」を「Safe」、危険(安全ではない)を「Danger」や「Not Safe」、エリア外を「Not IN Area」等のように表示してもよい。
【0052】
また、以下では、安否確認情報を登録するユーザアカウントを「安否登録アカウント」、登録された安否確認情報に基づく「安否情報」を参照するユーザアカウントを「安否参照アカウント」と称する。
なお、一般に、一のユーザアカウントは安否登録アカウントと安否参照アカウントとを兼ねることができる。
【0053】
また、以下では、前述したように、メッセージングアプリケーションによるメッセージングサービスを提供する事業者のことを「メッセージングサービス事業者」と称する。
なお、メッセージングサービス事業者は、メッセージングアプリケーションを提供する事業者や、サーバ10の事業者と表現することもできる。
また、メッセージングサービスを提供する事業者という意味で、メッセージングサービスの事業者と表現することもできる。
【0054】
また、以下では、メッセージングアプリケーションの名称を、適宜「Messaging App」と称して図示・説明する。
【0055】
メッセージングアプリケーションでは、限定ではなく例として、友だちとしてサーバ10に登録しているアカウント同士で、一対一トークを行うことができるように構成することができる。また、限定ではなく例として、2以上のアカウントを含むグループを構成し、グループに含まれるアカウント同士で、グループトークを行うことができるように構成することができる。
【0056】
また、メッセージングアプリケーションでは、限定ではなく例として、一のユーザアカウントに対して送信されたメッセージ一覧をトークリストとして確認できるように構成することができる。
【0057】
ユーザによって登録された安否確認情報を確認するための情報(以下、適宜「安否情報」と称する。)を各々の端末20において表示する形式としては、限定ではなく例として、メッセージングアプリケーションにおける以下の構成要件に表示させる形式が挙げられる。
(B1)友だちリストに表示
(B2)トークリストに表示
(B3)トークルームに表示
【0058】
なお、ユーザ同士(アカウント同士)が関連付けられていることの一例として、以下ではメッセージングサービスにおける「友だち」を主に例示するが、これに限定されない。
限定ではなく例として、SNSにおいて、自分が興味を持つなどして登録した他のユーザ(アカウント)を示す「フォロー」や、自分に興味を持つなどして自分を登録した他のユーザ(アカウント)を示す「フォロワー」のような関係も、ユーザ同士(アカウント同士)が関連付けられていることに含めることができる。
【0059】
限定ではなく例として、SNSにおいて、「フォロー」関係にあるユーザや、「フォロワー」関係にあるユーザの一覧は、上記構成要件(B1)と対応させることができる。
また、限定ではなく例として、SNSにおいて、「フォロー」関係にあるユーザの投稿一覧(限定ではなく例として、「タイムライン」)は、上記構成要件(B2)と対応させることができる。
また、限定ではなく例として、SNSにおいて、特定のユーザに対する投稿(限定ではなく例として、「ダイレクトメッセージ」)は、上記構成要件(B3)と対応させることができる。
【0060】
第1実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0061】
<システム構成>
図1-1は、本開示の実施形態における通信システム1のシステム構成の一例を示す図である。
通信システム1では、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)とが接続される。
【0062】
サーバ10は、ネットワーク30を介して、ユーザが所有する端末20に、所定のサービス(限定ではなく例として、メッセージングサービス、安否確認サービス等)を提供する機能を有する。サーバ10は、限定ではなく例として、メッセージングサーバ、安否確認サーバ等のように表現することもできる。
本実施形態では、メッセージングサービス事業者(運営者)や安否確認サービス事業者(運営者)をサーバ10のユーザとする。
【0063】
なお、ネットワーク30に接続されるサーバ10の数や端末20の数は限定されない。
【0064】
端末20(端末20A,端末20B,端末20C、・・・)は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末20は、限定ではなく例として、スマートフォン、携帯電話(フィーチャーフォン)、コンピュータ(限定でなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定でなく例として、PDA・(personal digital assistant)、電子メールクライアントなど)、ウェアラブル端末(メガネ型デバイス、時計型デバイスなど)、VR(Virtual Reality)端末、スマートスピーカ(音声認識用デバイス)、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末20は情報処理端末と表現されてもよい。
【0065】
端末20A、端末20Bおよび端末20Cの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザXが利用する端末を端末20Xと表現し、ユーザXまたは端末20Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
【0066】
ネットワーク30は、1以上の端末20と、1以上のサーバ10とを接続する役割を担う。すなわち、ネットワーク30は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
【0067】
ネットワーク30のうちの1つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク30は、限定ではなく例として、アドホック・ネットワーク(ad hoc network)、イントラネット、エクストラネット、仮想プライベート・ネットワーク(virtual private network:VPN)、ローカル・エリア・ネットワーク(local area network:LAN)、ワイヤレスLAN(wireless LAN:WLAN)、広域ネットワーク(wide area network:WAN)、ワイヤレスWAN(wireless WAN:WWAN)、大都市圏ネットワーク(metropolitan area network:MAN)、インターネットの一部、公衆交換電話網(Public Switched Telephone Network:PSTN)の一部、携帯電話網、ISDN(integrated service digital networks)、無線LAN、LTE(long term evolution)、CDMA(code division multiple access)、ブルートゥース(Bluetooth(登録商標))、衛星通信など、または、これらの2つ以上の組合せを含むことができる。ネットワーク30は、1つまたは複数のネットワーク30を含むことができる。
【0068】
サーバ10(限定ではなく、サーバ、情報処理装置、情報管理装置の一例)は、端末20に対して、所定のサービスを提供する機能を備える。サーバ10は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ10は、限定ではなく例として、サーバ装置、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ10は情報処理装置と表現されてもよい。サーバ10と端末20とを区別する必要がない場合は、サーバ10と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
【0069】
[各装置のハードウェア(HW)構成]
通信システム1に含まれる各装置のHW構成について説明する。
【0070】
(1)端末のHW構成
図1-1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
【0071】
通信I/F22は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F22は、ネットワーク30を介して、サーバ10等の各種装置との通信を実行する機能を有する。通信I/F22は、各種データを制御部21からの指示に従って、サーバ10等の各種装置に送信する。また、通信I/F22は、サーバ10等の各種装置から送信された各種データを受信し、制御部21に伝達する。また、通信I/F22を単に通信部と表現する場合もある。また、通信I/F22が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
【0072】
入出力部23は、端末20に対する各種操作を入力する装置や、端末20で処理された処理結果を出力する装置等を含む。入出力部23は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
【0073】
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部21に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含む。
【0074】
出力部は、制御部21で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ(音声出力)、レンズ(限定ではなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
【0075】
あくまでも一例であるが、入出力部23は、限定ではなく例として、表示部24、音入力部25、音出力部26、撮像部27を備える。
【0076】
表示部24は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部24は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))、ヘッドマウントディスプレイ(HDM:Head Mounted Display)、プロジェクションマッピング、ホログラム、空気中など(真空であってもよいし、そうでなくてもよい)に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部24は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。
【0077】
音入力部25は、音データ(音声データを含む。以下同様。)の入力に利用される。音入力部25は、マイクなどを含む。
音出力部26は、音データの出力に利用される。音出力部26は、スピーカなどを含む。
撮像部27は、画像データ(静止画像データ、動画像データを含む。以下同様。)の取得に利用される。撮像部27は、カメラなどを含む。
【0078】
入出力部23がタッチパネルの場合、入出力部23と表示部24とは、略同一の大きさおよび形状で対向して配置されていてもよい。
【0079】
時計部29Aは、端末20の内蔵時計であり、時刻情報(計時情報)を出力する。時計部29Aは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部29Aは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
【0080】
なお、時計部29Aは、NITZ(Network Identity and Time Zone)規格等を適用したクロックを有していてもよいし、有していなくてもよい。
【0081】
位置算出用情報検出部29Bは、制御部21が自己の端末20の位置を算出(測定)するために必要な情報(以下、「位置算出用情報」と称する。)を検出(計測)する機能部である。位置算出用情報検出部29Bは、限定ではなく例として、位置算出用センサ部と表現することもできる。
【0082】
位置算出用情報検出部29Bは、限定ではなく例として、GPS(Global Positioning System)等の衛星測位システムを利用して端末20の位置を算出するためのセンサやユニットである衛星測位センサ(衛星測位ユニット)や、慣性航法システムを利用して端末20の位置を算出するためのセンサやユニットである慣性計測センサ(慣性計測ユニット(IMU(Inertial Measurement Unit)))、UWB(超広帯域無線:Ultra Wide Band)を利用して端末20の位置を算出するためのセンサやユニットであるUWB測位センサ(UWB測位ユニット)等を含む。
【0083】
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むRF(Radio Frequency)信号をデジタル信号に変換するRF受信回路や、RF受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
【0084】
慣性計測ユニットは、慣性航法演算によって端末20の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、3軸の加速度センサや3軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
【0085】
UWB測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域RF(Radio Frequency)信号をデジタル信号に変換する超広帯域RF受信回路や、超広帯域RF受信回路から出力されるデジタル信号に基づいて端末20と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、UWB測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域RF信号を送信することで、端末20を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
【0086】
制御部21は、限定ではなく例として、位置算出用情報検出部29Bによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末20の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部21は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部28に記憶させるようにしてもよいし、そうしなくてもよい。
【0087】
制御部21は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
【0088】
制御部21は、限定ではなく例として、中央処理装置(CPU)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(application-specific integrated circuit)、FPGA(field programmable gate array)を含む。
【0089】
記憶部28は、端末20が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部28は、限定ではなく例として、HDD(hard disk drive)、SSD(solid state drive)、フラッシュメモリ、RAM(random access memory)、ROM(read only memory)など各種の記憶媒体を含む。また、記憶部28は、メモリ(memory)と表現されてもよいし、されなくてもよい。
【0090】
端末20は、プログラムPを記憶部28に記憶し、このプログラムPを実行することで、制御部21が、制御部21に含まれる各部としての処理を実行する。つまり、記憶部28に記憶されるプログラムPは、端末20に、制御部21が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
【0091】
(2)サーバのHW構成
図1-1には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
【0092】
制御部11は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
【0093】
制御部11は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部11は、これらに限定されない。
【0094】
記憶部15は、サーバ10が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部15は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部15は、これらに限定されない。また、記憶部15は、メモリ(memory)と表現されてもよいし、されなくてもよい。
【0095】
通信I/F14は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F14は、ネットワーク30を介して、端末20等の各種装置との通信を実行する機能を有する。通信I/F14は、各種データを制御部11からの指示に従って、端末20等の各種装置に送信する。また、通信I/F14は、端末20等の各種装置から送信された各種データを受信し、制御部11に伝達する。また、通信I/F14を単に通信部と表現する場合もある。また、通信I/F14が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
【0096】
入出力部12は、サーバ10に対する各種操作を入力する装置や、サーバ10で処理された処理結果を出力する装置等を含む。入出力部12は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
【0097】
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部11に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。
【0098】
出力部は、制御部11で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ(音出力)、レンズ(限定ではなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
【0099】
あくまでも一例であるが、入出力部12は、限定ではなく例として、表示部13を備える。
【0100】
表示部13は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。
【0101】
時計部19は、サーバ10の内蔵時計であり、時刻情報(計時情報)を出力する。時計部19は、限定ではなく例として、ハードウェアクロックとしてのRTC(Real Time Clock)やシステムクロック等を有して構成される。時計部19は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
(3)その他
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
【0102】
本開示の各実施形態においては、端末20および/またはサーバ10のCPUがプログラムPを実行することにより、実現するものとして説明する。
【0103】
なお、端末20の制御部21、および/または、サーバ10の制御部11は、制御回路を有するCPUだけでなく、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、1または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSIなどと呼称されることもある。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
【0104】
また、本開示の各実施形態のプログラムP(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよいし、そうでなくてもよい。
【0105】
また、システムのプログラム(システムによって実行されるプログラム)という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをP1とすると、システムのプログラムP1は、端末に保存されたプログラムP2と、サーバに保存されたプログラムP3とで構成され、P2とP3とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムP2は、第1の処理を実行し、第1の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムP3は、受信した第1の処理をした結果に対して第2の処理を行い、第2の処理を行った結果を端末に送信するプログラムであってもよい。
【0106】
記憶媒体は、1つまたは複数の半導体ベースの、または他の集積回路(IC)(限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ(FPGA)または特定用途向けIC(ASIC)など)、ハード・ディスク・ドライブ(HDD)、ハイブリッド・ハード・ドライブ(HHD)、光ディスク、光ディスクドライブ(ODD)、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ(FDD)、磁気テープ、固体ドライブ(SSD)、RAMドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの2つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムPを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ(memory)と表現されてもよいし、されなくてもよい。
【0107】
サーバ10および/または端末20は、記憶媒体に記憶されたプログラムPを読み出し、読み出したプログラムPを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
【0108】
また、本開示のプログラムPは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ10および/または端末20に提供されてもよいし、されなくてもよい。サーバ10および/または端末20は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムPを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
【0109】
また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部、または全部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部、または全部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
【0110】
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
【0111】
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。
【0112】
<機能構成>
(1)サーバの機能構成
図1-2は、本実施例においてサーバ10の制御部11によって実現される機能の一例を示す図である。
制御部11は、限定ではなく例として、記憶部15に記憶されたアプリケーション管理処理プログラム151に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部111を機能部として含む。
【0113】
図1-3は、本実施例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155とが記憶される。
【0114】
アカウント登録データ153は、アプリケーション(本実施例では、メッセージングアプリケーション)のアカウントに関する登録データであり、そのデータ構成の一例を
図1-4に示す。
アカウント登録データ153には、限定ではなく例として、ユーザ名と、アプリケーションIDと、その他登録情報とが関連付けて記憶される。
【0115】
ユーザ名は、このアプリケーションを利用する端末20のアカウントの名称であり、限定ではなく例として、端末20のユーザがアプリケーションを利用する際に登録する名称が記憶される。
【0116】
アプリケーションIDは、アプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ10によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
アプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
【0117】
その他登録情報には、限定ではなく例として、端末20を識別するための識別情報、端末20の電話番号(端末電話番号)、メールアドレス(端末メールアドレス)、アプリケーションにおける各種の認証に利用されるパスワード(ログインパスワード、認証パスワード等)等の認証情報といった各種の情報を含めるようにすることができる。
【0118】
端末20を識別するための識別情報は、限定ではなく例として、端末ID(限定ではなく例として、IMEI(International Mobile Equipment Identity))とすることができる。
また、端末20のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションIDや公式ユーザ用のアプリケーションIDとすることができる。
【0119】
なお、アプリケーションIDに代えて「ユーザID」としてもよいし、しなくてもよい。
また、1つの端末20につき1つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」とすることができる。
【0120】
また、限定ではなく例として、1つのアプリケーションIDに、複数の端末IDを割り当てることを可能としてもよいし、そのようにしなくてもよい。この場合、1つのアプリケーションIDを識別(ログイン)対象として、複数の端末20においてアプリケーションを同時に起動できるようにしてもよいし、そのようにしなくてもよい。
【0121】
また、アプリケーションID等の各種のIDに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
この場合、アプリケーションID等のIDの情報をアカウント登録データ153に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ153に記憶させるようにすることができる。なお、アプリケーションID等のIDの情報を端末電話番号等の情報に代えず、アプリケーションID等のIDの情報を端末電話番号等の情報と一対一に対応させるようにしてもよいし、そのようにしなくてもよい。
【0122】
なお、以下の各種の実施例では、説明の簡明化のため、1つの端末20につき1つのアカウントが登録されていることとして説明する。
また、この場合、上記のように「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
【0123】
アカウント管理データベース155は、アカウント登録データ153に登録されたアカウントに関する情報を管理するためのデータベースであり、その一例であるアカウント管理データベース155Aのデータ構成例を
図1-5に示す。
アカウント管理データベース155Aには、アカウントごとの管理データとして、アカウント管理データが記憶される。
【0124】
各々のアカウント管理データには、限定ではなく例として、アプリケーションIDと、友だち管理データと、安否登録データとが記憶される。
【0125】
アプリケーションIDは、アカウント管理データで管理されるアカウントを識別するための情報であり、限定ではなく例として、アカウント登録データ153に登録されたアプリケーションIDが記憶される。
【0126】
友だち管理データは、このアプリケーションIDのアカウントと友だちであるアカウントのアプリケーションIDを記憶させるためのデータであり、限定ではなく例として、ユーザが友だち登録を行うと、サーバによって友だち登録を行ったユーザのアプリケーションIDが追加され更新される。
【0127】
安否登録データは、このアプリケーションIDのアカウントに関連付けられた、安否に関する登録を記憶させるためのデータであり、限定ではなく例として、安否ステータス情報が記憶される。
【0128】
アカウントごとの安否登録データは、限定ではなく例として、端末20に対するユーザ操作等のユーザ入力に基づいて変更可能とすることができる。
なお、安否登録データの初期値(デフォルト)としては、限定ではなく例として、サーバ10が安否確認情報を受信していないことを示す情報(限定ではなく例として、安否不明であることを示す「不明」フラグ)が予め設定されるようにすることができる。
【0129】
また、安否登録データとして、このアカウントの端末20によって登録された安否確認情報のうち、安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせを関連付けて記憶させるようにしてもよい。
【0130】
(2)端末の機能構成
図1-6は、本実施例において端末20の制御部21によって実現される機能の一例を示す図である。
制御部21は、限定ではなく例として、記憶部28に記憶されたアプリケーション処理プログラム281に従ってアプリケーション処理を実行するためのアプリケーション処理部211を機能部として含む。
【0131】
図1-7は、本実施例において端末20の記憶部28に記憶されるデータ等の一例を示す図である。
記憶部28には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム281と、この端末20、または端末20のユーザのアカウントに対応するアプリケーションID283とが記憶される。
なお、端末20の記憶部28に、アカウント管理データベース155Aの友だち管理データを同期させて記憶させるようにしてもよい。
【0132】
<表示画面>
本実施例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。
以下では、限定ではなく例として、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
【0133】
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。
【0134】
なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。
【0135】
図1-8~
図1-10は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
ここでは、
・安否登録アカウント=端末20YのユーザY.Y(限定ではなく、第1端末のユーザの一例)のアカウント
・安否参照アカウント=端末20XのユーザX.X(限定ではなく、端末のユーザの一例)のアカウント
とする場合の表示画面例を説明する。
【0136】
図1-8左側は、メッセージングアプリケーション(限定ではなく、チャットアプリケーションの一例)のホーム画面であり、画面最上部中央には、メッセージングアプリケーションの名称として「Messaging App」の文字が表示されている。また、画面最上部の右部には、この端末20Yのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名(この例では「ユーザY.Y」)が表示されている。
【0137】
また、その下には、メッセージングアプリケーション内での現在の位置やページ等を示す領域(以下、包括的に「アプリ内位置表示領域」と称する。)が構成されており、この例では、ホーム画面であることに基づいて、「ホーム」の文字が表示されている。
【0138】
アプリ内位置表示領域の下には、災害が発生したことを報知するための災害情報を示す領域である災害情報表示領域が構成されており、この例では、地震が発生したことに基づいて、災害情報(限定ではなく例として、震源地を示す地図情報と、「災害発生」の文字と、「20XX/08/04 09:39発表」の文字と、「最大震度:5強」の文字と、「震源地:茨城県沖」の文字と、「マグニチュード:6.5」の文字)が表示されている。また、災害情報表示領域の内部の右下には、メッセージングアプリケーションのアカウントごとの安否登録(安否確認情報の登録)を行うための「安否登録」の文字を含むアイコンで示される安否登録ボタンBT1が表示されている。
【0139】
災害情報表示領域の下には、メッセージングアプリケーションにおける友だちやグループのリストが表示される友だち・グループリスト表示領域が構成されている。
この例では、友だち・グループリスト表示領域には、この端末20のアカウント(この例では「ユーザY.Y」)の友だちを一覧表示させるための友だちリストと、この端末20のアカウントをメンバーとして含むグループを一覧表示させるためのグループリストとが表示されるように構成されている。この例では、限定ではなく例として、友だちリストがタップされて展開された状態で表示されている。
【0140】
グループリストには、限定ではなく例として、「グループ」の文字と、ユーザY.Yが属するグループの数(本例では「8」)とが表示されている。
その下の友だちリストには、「友だち」の文字と、ユーザY.Yが友だちとして登録しているユーザ(アカウント)の数(本例では「4」)とが表示されている。
【0141】
グループリストや友だちリストがユーザによってタップされると、それらのリストが展開され表示される。具体的には、限定ではなく例として、グループリストの下に、グループのアイコンと、グループ名と、そのグループに属するメンバー数とが、グループリストの項目として一覧表示される。また、限定ではなく例として、友だちリストの下に、友だちのアイコンと、ユーザ名とが、友だちリストの項目として一覧表示される。
【0142】
この画面では、友だちリストの項目として、ユーザX.Xに対応したアイコンおよびユーザ名、ユーザC.Cに対応したアイコンおよびユーザ名、ユーザD.Dに対応したアイコンおよびユーザ名等が一覧表示されている。
【0143】
限定ではなく例として、安否登録ボタンBT1がユーザによってタップされると、限定ではなく例として、
図1-8中央のような表示がなされる。
このホーム画面では、
図1-8左側のホーム画面に重畳して、自身の安否情報を登録(設定)するための安否登録領域R1がせり上がり表示されるように構成されている。
【0144】
安否登録領域R1には、ユーザに安否情報を登録(設定)することを促す旨のメッセージ(本例では、「安否登録」の文字と、「みんなに安否を伝えよう」の文字)が表示されている。その下には、安否情報として安全であることを設定するための安全ボタンSBT(本例では、笑顔のアイコンと「安全」の文字とで示されるボタン)と、安否情報として安全でないことを設定するための危険ボタンDBT(本例では、笑顔でない顔のアイコンと「危険」の文字とで示されるボタン)と、選択した安否情報を設定するための登録ボタンBT3とが表示されている。
【0145】
限定ではなく例として、
図1-8中央の安否登録領域R1において、危険ボタンDBTがユーザによってタップされ、登録ボタンBT3がユーザによってタップされたとする。
この場合、ユーザY.Yと友だちであるユーザX.Xの端末20Xには、限定ではなく例として、
図1-8右側に示すような画面が表示される。
【0146】
図1-8右側には、端末20Xの表示部24に表示されるホーム画面の一例を示しており、友だちリストの項目として、ユーザY.Yに対応したアイコンおよびユーザ名、ユーザA.Aに対応したアイコンおよびユーザ名、ユーザB.Bに対応したアイコンおよびユーザ名等が一覧表示されている。
【0147】
この場合、上記のようにユーザY.Yが安否情報として「危険」を設定(登録)したことに基づいて、この例では、友だちリストのユーザY.Yのアイコンと関連付けて、危険であることを示すアイコンDIC1(本例では、笑顔でない顔のアイコン、以下、適宜「第1危険アイコン」と称する。)が重畳表示されている。
【0148】
なお、ユーザY.Yが安否情報として「安全」を設定している場合、友だちリストのユーザY.Yのアイコンには、安全であることを示すアイコンSIC1(本例では、笑顔アイコン、以下、適宜「第1安全アイコン」と称する。)が重畳表示される。
【0149】
友だちリストの各ユーザの項目に表示される<危険であることを示す第1危険アイコンDIC1>または<安全であることを示す第1安全アイコンSIC1>を確認することにより、端末20XのユーザX.Xは、友だち登録しているユーザの安否情報を確認することができる。
【0150】
図1-9左側は、
図1-8中央の表示画面と同様のユーザY.Yの端末20Yにおけるホーム画面の一例である。
本例では、
図1-9左側の安否登録領域R1において、限定ではなく例として、危険ボタンDBTがユーザによってタップされ、登録ボタンBT3がユーザによってタップされると、ユーザX.Xの端末20Xの表示部24に、限定ではなく例として、
図1-9中央に示すような画面が表示される。
【0151】
この端末20Xの表示部24に表示されるホーム画面では、ユーザY.Yが安否情報として「危険」を設定したものの、
図1-8右側に示した例とは異なり、友だちリストのユーザY.Yのアイコンに、危険であることを示すアイコンが重畳表示されていない。
【0152】
限定ではなく例として、
図1-9中央のホーム画面において、画面最下部のトークの項目がユーザによってタップされると、限定ではなく例として、
図1-9右側のトークリスト画面に表示が遷移する。
【0153】
トークリスト画面は、限定ではなく例として、この端末20Xに対してメッセージが送信されたトークルームを一覧で確認可能とする画面とすることができる。
このトークリスト画面のアプリ内位置表示領域では、トークリスト画面であることに基づいて、「トーク」の文字と、前の画面に戻るための「<」の文字で示される戻るボタンとが表示されている。
【0154】
アプリ内位置表示領域の下には、この端末20Xに対してメッセージが送信されたトークルームに関する情報が一覧表示されている。各々のトークルームと対応するトークルームリスト項目(トークリスト項目)には、そのトークルームのアイコン(以下、「トークルームアイコン」と称する。)と、トークルーム名と、そのトークルームがグループトークルームであった場合にはメンバー数とが関連付けて表示されている。
ここで、トークルームアイコンは、一対一トークルームの場合、限定ではなく例として、トーク相手のユーザのアイコンとすることができ、グループトークルームの場合、限定ではなく例として、グループに設定されたアイコン(グループアイコン)とすることができる。
また、トークルーム名は、一対一トークルームの場合、限定ではなく例として、トーク相手のユーザ名とすることができ、グループトークルームの場合、限定ではなく例として、グループ名とすることができる。
【0155】
本例では、限定ではなく例として、トークルームリスト項目として、ユーザY.Yとのトークルームに対応したトークルームリスト項目(以下、「ユーザY.Y」のトークルームリスト項目と称する。)と、ユーザA.Aのトークルームリスト項目と、ユーザB.Bのトークルームリスト項目等とが表示されている。
【0156】
この例では、各々のトークルームリスト項目には、限定ではなく例として、未読状態であるメッセージ数が関連付けて表示されるように構成されている。
限定ではなく例として、ユーザY.Yのトークルームにおいて、端末20XのユーザX.Xが未読状態である(ユーザX.Xによって閲覧されていない)メッセージが1件あることに基づいて、ユーザY.Yのトークルームリスト項目には「1」の数字が関連付けて表示されている。
【0157】
この場合、ユーザY.Yが安否情報として「危険」を設定していることに基づいて、トークリスト画面におけるユーザY.Yのトークルームリスト項目では、トークルームアイコンに<危険であることを示すアイコンDIC2>(本例では、「危険」の文字が示されているアイコン、以下、適宜「第2危険アイコン」と称する。)が重畳表示されている。
【0158】
なお、ユーザY.Yが安否情報として「安全」を設定している場合、トークリスト画面におけるユーザY.Yのトークルームリスト項目では、トークルームアイコンに<安全であることを示すアイコンSIC2>(本例では、「安全」の文字が示されているアイコン、以下、適宜「第2安全アイコン」と称する。)が重畳表示される。
【0159】
トークリストの各トークルームリスト項目に表示される<危険であることを示すアイコン>または<安全であることを示すアイコン>を確認することにより、端末20XのユーザX.Xは、メッセージを端末20Xに対して送信したユーザの安否情報を確認することができる。
【0160】
なお、トークルームアイコンに第2安全アイコンSIC2や第2危険アイコンDIC2を表示させるのではなく、「安全」の場合は「青色」のアイコンを表示させ、「危険」の場合は「赤色」のアイコンを表示させるなどしてもよい。また、トークルームの名称を示す文字の色や書体を変えて表示させるなどしてもよい。
なお、これらの表示態様の変更の手法は、友だちリストやグループリストにも同様に適用可能である。
【0161】
図1-10左側には、ユーザX.Xの端末20Xのトークリスト画面が表示されている。このトークリスト画面は、
図1-9右側で示したトークリスト画面とは異なり、ユーザY.Yが安否情報として「危険」を設定しているものの、トークリスト画面におけるユーザY.Yのトークルームリスト項目では、トークルームアイコンに第2危険アイコンDIC2が重畳表示されていない。
【0162】
限定ではなく例として、
図1-10左側のトークリスト画面において、ユーザY.Yに対応したトークルームリスト項目がユーザによってタップされると、限定ではなく例として、
図1-10中央のトークルーム画面が表示される。
このトークルーム画面には、画面最上部のメッセージングアプリケーションの名称等が表示される領域の下に、限定ではなく例として、メッセージングアプリケーション内のいずれのページ(この例では、トークルーム)が現在表示されているかを示す領域の一種として、トークルームの名称(以下、「トークルーム名」と称する。)を含むトークルーム名表示領域が設けられている。トークルーム名表示領域は、現在ユーザが位置しているメッセージングアプリケーション内のページ(この例では、トークルーム)を示す領域とも言える。
【0163】
本例では、トークルーム名表示領域には、限定ではなく例として、前の画面に戻るための「<」の戻るボタンと、ユーザX.XがユーザY.Yを相手としてトークを行うためのトークルームであることを示す文字(本例では「Y.Y」)と、このトークルームに属するユーザの安否情報を表示するための安否情報表示アイコンIC1とが表示されている。
また、その下には、ユーザX.XとユーザY.Yとが対話形式でトークを行うためのトーク領域が構成されており、画面向かって左側には相手であるユーザY.Yのメッセージが、画面向かって右側には自分であるユーザX.Xのメッセージが表示されるように構成されている。
【0164】
トーク領域の上部には、限定ではなく例として、ユーザY.Yが設定した安否情報をトークルーム内で報知するためのトークルーム内安否情報(本例では、「Y.Yさんが安否確認に回答しました」の文字と、端末のユーザのアイコンと安否に関する情報とを含むユーザ状態アイコンICYD(ユーザY.Yのアイコン、「危険」の文字、笑顔でないアイコン))が表示されている。以下、ユーザ状態アイコンを、適宜「ユーザ状態アイコン(ユーザ名(のアイコン)、安全または危険(に対応した文字および顔のアイコン))」と称する。
【0165】
なお、この表示画面例では、ユーザ状態アイコンを、そのユーザのアイコンと、安否ステータス情報に対応する文字(安全/危険)と、安否ステータス情報に対応するアイコンとを組み合わせたアイコンとしているが、これに限定されない。
限定ではなく例として、そのユーザのアイコンと、安否ステータス情報に対応する文字(安全/危険)とを組み合わせたアイコンとしたり、そのユーザのアイコンと、安否ステータス情報に対応するアイコンとを組み合わせたアイコンとするなどしてもよい。
【0166】
限定ではなく例として、
図1-10中央のトークルーム画面において、安否情報表示アイコンIC1がユーザによってタップされると、限定ではなく例として、
図1-10右側に示すように、トークルーム名表示領域の下に展開する形式で、このトークルームに含まれる各々のユーザの安否情報を表示するためのユーザ別安否情報が表示される。
この例では、トークルームに属するユーザの安否情報を含むユーザ別安否情報を表示するためのユーザ別安否情報表示領域が構成されており、本例では、安否情報表示アイコンIC1とともに、ユーザ別安否情報として、第2危険アイコンDIC2が重畳表示されたユーザY.Yのアイコンと、第2安全アイコンSIC2が重畳表示されたユーザX.Xのアイコンとが表示されている。
【0167】
<処理>
図1-11は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20Xの制御部21が実行する処理、端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0168】
なお、以下説明する処理は、本開示の手法を実現するための処理の一例に過ぎず、これらに限定されるものではない。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略(削除)してもよい。
【0169】
ここでは、表示画面と同様に、
・安否登録アカウント=端末20YのユーザY.Y(限定ではなく、第1端末のユーザの一例)のアカウント
・安否参照アカウント=端末20XのユーザX.X(限定ではなく、端末のユーザの一例)のアカウント
とする場合の処理を例示する。
【0170】
最初に、端末20Xの制御部21と、端末20Yの制御部21と、サーバ10の制御部11とは、限定ではなく例として、チャット処理を実行する(X110、Y110、S110)。
チャット処理では、限定ではなく例として、各端末20の入出力部23に対する入力(限定ではなく例として、ユーザ入力(ユーザによる操作入力や音入力等)以下同様。)に基づいて、各端末20の制御部21は、メッセージングサービスにおけるコンテンツの送受信処理と表示処理とを実行する。また、サーバ10の制御部11は、限定ではなく例として、各端末20から送信されたコンテンツの中継処理を実行する。
【0171】
なお、チャット処理は、処理中の任意のステップ間で実行されるようにしてもよい。また、本システムにおいて、チャット処理は実行されなくてもよい。
【0172】
次いで、サーバ10の制御部11は、限定ではなく例として、サーバ10の入出力部12に対する入力(限定ではなく例として、ユーザ入力(サーバ10のユーザによる操作入力や音入力等))に基づいて、災害が発生したことと、この災害における各端末20のユーザの安否登録を依頼することとを含む災害情報を、通信I/F14によって各端末20に送信する(S120)。
【0173】
ここで、災害情報は、限定ではなく例として、以下の災害要素A~災害要素Hの任意の組み合わせと、ユーザに安否登録を依頼することとを含むように構成するようにしてもよい。
・災害要素A:災害が発生したこと。
・災害要素B:災害の種類(限定ではなく例として、地震や洪水、大規模火災等)。
・災害要素C:災害の規模(限定ではなく例として、震度やマグニチュード、河川水位、延焼範囲等)。
・災害要素D:災害の発生日時。
・災害要素E:災害の発生場所。
・災害要素F:災害による副次的な影響(限定ではなく例として、停電や断水の状況や交通機関の運行状況等)。
・災害要素G:災害に対する対処方法(限定ではなく例として、避難場所や避難経路等)。
・災害要素H:その他災害に関連する情報。
なお、災害情報に、その災害における安否登録の期間や期限に関する情報を含めるようにしてもよい。
【0174】
なお、サーバ10の制御部11は、任意の災害が発生した場合、不図示の災害情報提供サーバから発生した災害に関する情報である災害状況情報(限定ではなく例として、上記の災害要素A~Dにより構成される情報)を受信する。すると、サーバ10の制御部11は、災害状況情報に基づいて、発生した災害が所定の規模(限定ではなく例として、最大震度5や、大雨)より大きい、または所定の規模以上であると判定する場合、自動的に災害情報を各端末20に送信するようにしてもよい。
【0175】
また、サーバ10の制御部11は、任意の災害が発生した場合、災害情報提供サーバから災害状況情報を受信すると、表示部13に災害情報を送信するか否かの選択用表示画面を表示させるようにしてもよい。そして、サーバ10の制御部11は、選択用表示画面に対するユーザ入力に基づいて、災害情報を各端末20に送信するようにしてもよい。
【0176】
通信I/F22によってサーバ10から災害情報を受信すると、各端末20の制御部21は、受信した災害情報を表示部24に表示させる(X120、Y120)。
【0177】
限定ではなく例として、安否登録アカウントの端末20Yの入出力部23に対する入力に基づいて、安否確認情報が入力されると、端末20Yの制御部21は、限定ではなく例として、入力された安否確認情報と、安否登録アカウントのアプリケーションIDとを含む安否確認登録情報を通信I/F22によってサーバ10に送信する(Y140)。
【0178】
通信I/F14によって安否登録アカウントの端末20Yから安否確認登録情報を受信すると、サーバ10の制御部11は、受信した安否確認登録情報に基づいて、安否情報を生成する。
安否情報には、限定ではなく例として、安否確認登録情報において送信された安否登録アカウントのアプリケーションIDと、安否確認情報とを含めることができる。
【0179】
なお、サーバ10の制御部11は、安否情報に、安否確認登録情報において送信された安否登録アカウントのアプリケーションIDに紐付けられたユーザ名を含めるようにしてもよい。また、サーバ10の制御部11は、安否情報に、安否確認登録情報において送信された安否確認情報における安否ステータス情報と、安否コメント情報と、安否位置情報との任意の組み合わせのうち、任意の情報の組み合わせのみ(限定ではなく例として、安否ステータス情報と安否位置情報とが安否確認情報に含まれる場合、安否ステータス情報のみ)を含めるようにしてもよい。
【0180】
すると、サーバ10の制御部11は、限定ではなく例として、アカウント管理データベース155Aを検索し、安否登録アカウントの友だち管理データに友だち登録されているアカウントを参照する。そして、友だち登録されている各アカウントの端末20に対して通信I/F14によって安否情報を送信する(S140)。
【0181】
なお、サーバ10の制御部11は、S140のステップにおいて全ての端末20に安否情報を送信するようにしてもよい。
【0182】
通信I/F22によってサーバ10から安否情報を受信すると、端末20Xの制御部21は、受信した安否情報を表示部24に表示させる(X160)。
なお、安否参照アカウントの端末20において、安否情報を表示部24に表示させる判定条件としては、限定ではなく例として、以下の場合における任意の組み合わせが挙げられる。
・無条件に表示(プッシュ通知等)
・友だちリスト(グループリスト)の閲覧を行うと安否登録アカウントと関連付けて表示
・トークリストの閲覧を行うと安否登録アカウントと関連付けて表示
・安否参照アカウントと安否登録アカウントとの一対一トークルームの閲覧を行うと表示
・安否登録アカウントを含むグループのグループトークルームの閲覧を行うと表示
【0183】
また、S140のステップにおいて、サーバ10が全ての端末20に安否情報を送信する場合、安否参照アカウントの端末20の制御部21は、限定ではなく例として、記憶部28に記憶される友だち管理データを参照する。そして、友だち管理データに安否登録アカウントのアプリケーションIDが含まれる場合、安否情報を表示部24に表示させるようにしてもよい。
【0184】
<第1実施例の効果>
本実施例は、安否登録アカウントのユーザ(限定ではなく、第1端末のユーザの一例)とのトーク(限定ではなく、チャットの一例)に関連する処理(限定ではなく、チャットに関連する処理の一例)を行う安否参照アカウントのユーザ(限定ではなく、端末のユーザの一例)の端末20は、安否登録アカウントのユーザによる自己の端末20に対する入力に基づいて、安否情報(または安否確認登録情報)(限定ではなく、第1端末のユーザの安否に関する第1情報の一例)を通信I/F22によって受信する。そして、安否参照アカウントのユーザの端末20は、安否登録アカウントのユーザに関連するトークの情報(限定ではなく、チャットの情報の一例)に関連付けられた安否情報を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を受信した上で、第1端末のユーザに関連するチャットの情報に関連付けられた第1情報を端末の表示部に表示して、端末のユーザに知らせることができる。チャットの情報に関連付けられた形で端末のユーザにとって分かり易い表示を実現することができる。
【0185】
なお、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を受信することには、限定ではなく例として、第1端末から第1情報がサーバに送信され、サーバが第1情報を受信したことに基づいて、サーバから端末に第1情報が送信されて端末が第1情報を受信することと、サーバを介さずに第1端末から端末に第1情報が直接的に送信され、それを端末が受信することとを含めることができる。
【0186】
また、チャットに関連する処理とは、限定ではなく例として、チャットを行うための情報を送受信する処理や、チャットに関連するコンテンツを表示する処理などの、チャットを行うための各種の処理やチャットを実現するための各種の処理等を含む概念とすることができる。
また、チャットの情報とは、メッセージングアプリケーションでは、限定ではなく例として、前述した(B1)~(B3)に対応する「友だちリスト」、「トークリスト」、「トークルーム」等を含む概念とすることができる。なお、前述した「フォロー」、「フォロワー」等についても同様である。
【0187】
また、この場合、安否参照アカウントのユーザの端末20は、安否情報(または安否確認登録情報)を、サーバ10を介して通信I/F22によって受信するようにすることができる。
このような構成により得られる実施例の効果の一例として、サーバを介して、第1情報を適切に受信することができる。
【0188】
また、この場合、上記のトークの情報(限定ではなく、チャットの情報の一例)は、メッセージングアプリケーションにおけるトーク(限定ではなく、チャットの一例)で、安否参照アカウントのユーザに関連付けられたユーザのリスト(限定ではなく、ユーザのリストの一例)に含まれるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を受信した上で、端末のユーザに関連付けられたユーザのリストに含まれるチャットの情報に関連付けられた第1情報を端末の表示部に表示して、端末のユーザに知らせることができる。
【0189】
また、この場合、上記のトークの情報(限定ではなく、チャットの情報の一例)は、安否登録アカウントのユーザ(限定ではなく、第1端末のユーザの一例)と安否参照アカウントのユーザ(限定ではなく、端末のユーザの一例)とを含むトークルーム(限定ではなく、第1チャットルームの一例)に関する情報を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を受信した上で、第1端末のユーザと端末のユーザとを含む第1チャットルームに関する情報に関連付けられた第1情報を端末の表示部に表示して、端末のユーザに知らせることができる。第1端末のユーザと端末のユーザとを含む第1チャットルームに関する情報に関連付けられた形で端末のユーザにとって分かり易い表示を実現することができる。
【0190】
また、この場合、上記のトークの情報は、安否参照アカウントのユーザが含まれるトークルームのトークリスト(限定ではなく、チャットルームのリストの一例)に含まれる一対一トークルーム(トーク相手)のアイコン画像等の情報(限定ではなく、端末のユーザが含まれるチャットルームのリストに含まれる第1チャットルームに関する情報の一例)や、安否参照アカウントのユーザが含まれるグループトークルームのグループリストに含まれるグループトークルーム(グループ)のアイコン画像等の情報(限定ではなく、端末のユーザが含まれるチャットルームのリストに含まれる第1チャットルームに関する情報の一例)を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザによる第1端末に対する入力に基づいて、第1端末のユーザの安否に関する第1情報を受信した上で、端末のユーザが含まれるチャットルームのリストに含まれる第1チャットルームに関する情報に関連付けられた第1情報を端末の表示部に表示して、端末のユーザに知らせることができる。
【0191】
また、この場合、安否参照アカウントのユーザの端末20は、安否情報に基づいて、上記のアイコン画像等の表示態様を変更する制御を制御部21によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、第1情報に基づいて、第1端末のユーザと端末のユーザとを含む第1チャットルームに関する情報の表示態様を変更することで、端末のユーザにとって分かり易い表示を実現することができる。
【0192】
また、この場合、安否情報(限定ではなく、第1情報の一例)は、安否登録アカウントのユーザ(限定ではなく、第1端末のユーザの一例)と安否参照アカウントのユーザ(限定ではなく、端末のユーザの一例)とを含むトークルーム(限定ではなく、第1チャットルームの一例)に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザと端末のユーザとを含む第1チャットルームへの第1情報の表示という分かり易い形で、第1端末のユーザの安否を端末のユーザに知らせることができる。
【0193】
また、この場合、安否情報(限定ではなく、第1情報の一例)は、安否登録アカウントのユーザ(限定ではなく、第1端末のユーザの一例)によって設定された自身のアイコン画像等の画像(限定ではなく、第1画像の一例)と関連付けられて、上記のトークルームに表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザによって設定された第1画像と関連づけられて第1チャットルームに第1情報が表示されるため、第1端末のユーザの安否に関する情報であることを端末のユーザが認識し易くなるようにすることができる。
【0194】
<第1変形例(1)>
上記の実施例では、安否確認情報として、安否ステータス情報のみを登録する例について例示したが、これに限定されない。また、上記の実施例では、安否登録アカウントと安否参照アカウントとが異なる例について例示したが、これに限定されない。
【0195】
図1-12左側は、ユーザA.Aの端末20Aの表示部24に表示されるホーム画面の一例を示している。
このホーム画面では、
図1-8左側に示したユーザY.Yの端末20Yのホーム画面とは異なり、画面最上部の右側には、この端末20AのユーザA.Aのメッセージングアプリケーションにおけるアイコン画像およびユーザ名(この例では「A.A」)が表示されている。
【0196】
グループリストには、グループリストの項目として、テニスサークルに対応したアイコンおよびグループ名(メンバー数)、ゼミ仲間に対応したアイコンおよびグループ名(メンバー数)等が一覧表示されている。
また、友だちリストには、友だちリストの項目として、ユーザB.Bに対応したアイコンおよびユーザ名、ユーザC.Cに対応したアイコンおよびユーザ名、ユーザD.Dに対応したアイコンおよびユーザ名等が一覧表示されている。
【0197】
限定ではなく例として、安否登録ボタンBT1がユーザによってタップされると、限定ではなく例として、
図1-12中央のような表示がなされる。
この例では、安否登録領域R1における安全ボタンSBTおよび危険ボタンDBTの下に、安否コメント情報の一種である安否メッセージを入力するための安否メッセージ入力領域が構成されている。
【0198】
安否メッセージ入力領域には、「安否メッセージ」の文字とともに、安否メッセージを入力するための領域(入力された安否メッセージが表示される領域)が構成されている。
また、その下には、安否メッセージの定型文を選択するための領域が構成されている。この例では、安否メッセージの定型文として、限定ではなく例として、「怪我をした」のテキストと、「閉じ込められた」のテキストと、「火災に巻き込まれた」のテキストと、「避難中」のテキストとがあらかじめ用意されており、各々がタップによって選択可能なアイコンとして表示されている。
【0199】
また、その下には、安否位置情報の一種である現在の居場所を入力するための現在地入力領域が構成されている。現在地入力領域には、「現在の居場所」の文字と、現在の居場所を入力するための領域(入力された現在の居場所を表示する領域)と、現在地を取得するための現在地取得ボタンとが表示されている。
【0200】
そして、画面の最下部には、選択/入力した安否情報を設定するための登録ボタンBT3が設けられている。
【0201】
なお、安否コメント情報と安否位置情報とのいずれか一方のみを登録するように安否登録領域R1を構成してもよい。
【0202】
限定ではなく例として、
図1-12中央の安否登録領域R1において、安全ボタンSBTがユーザA.Aによってタップされた後、登録ボタンBT3がユーザA.Aによってタップされた場合における、ユーザA.Aの端末20Aに表示されるホーム画面の一例を
図1-12右側に示す。
【0203】
災害情報表示領域では、安否登録ボタンBT1の表示が消去され、これに代えて、ユーザ状態アイコンが表示されている。本例では、ユーザA.Aの状態を示すユーザ状態アイコンICAS(この例では、ユーザA.A、安全)が表示されている。
【0204】
また、ユーザB.Bが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザB.Bに対応したアイコンには、第1危険アイコンDIC1が重畳表示されている。ユーザC.Cが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザC.Cに対応したアイコンには、第1危険アイコンDIC1が重畳表示されている。ユーザD.Dが安否情報として「安全」を設定していることに基づいて、ユーザD.Dに対応したアイコンに、第1安全アイコンSIC1が重畳表示されている。
【0205】
図1-13左側は、ユーザA.Aの端末20Aのトークリスト画面が表示されている。このトークリスト画面は、
図1-9右側のトークリスト画面とは異なり、アプリ内位置表示領域の下であって、この端末20Aに対してメッセージが送信されたトークルームに関する情報が一覧表示されている領域の上には、災害が発生したことをトークリスト画面において報知するための第2災害情報を示す領域である第2災害情報表示領域が構成されている。そして、この例では、地震が発生したことに基づいて、第2災害情報(限定ではなく例として、「20XX/08/04 09:39発表」の文字と、「最大震度:5強」の文字と、「地震発生」の文字とが表示されている。また、ユーザA.Aが、自身は「安全」であることを設定したことに基づき、その旨を示すユーザ状態アイコンICAS(ユーザA.A、安全))が第2災害情報表示領域に表示されている。
【0206】
本例では、限定ではなく例として、トークルームリスト項目として、テニスサークルのトークルームリスト項目、ユーザD.Dのトークルームリスト項目、ユーザB.Bのトークルームリスト項目、ゼミ仲間のトークルームリスト項目、ユーザC.Cのトークルームリスト項目、ユーザE.Eのトークルームリスト項目等が表示されている。
【0207】
本例では、テニスサークルのトークルームリスト項目に関連付けて未読数「13」の数字が表示され、ユーザD.Dのトークルームリスト項目に関連付けて未読数「2」の数字が表示され、ユーザB.Bのトークルームリスト項目に関連付けて未読数「1」の数字が表示され、ゼミ仲間のトークルームリスト項目に関連付けて未読数「2」の数字が表示され、ユーザC.Cのトークルームリスト項目に関連付けて未読数「2」の数字が表示され、ユーザE.Eのトークルームリスト項目に関連付けて未読数「1」の数字が表示されている。
【0208】
また、ユーザD.Dが安否情報として「安全」を設定していることに基づいて、ユーザD.Dのトークルームリスト項目に対応したアイコンには、第2安全アイコンSIC2が重畳表示されている。ユーザB.Bが安否情報として「危険」を設定していることに基づいて、ユーザB.Bのトークルームリスト項目に対応したアイコンには、第2危険アイコンDIC2が重畳表示されている。ユーザC.Cが安否情報として「危険」を設定していることに基づいて、ユーザC.Cのトークルームリスト項目に対応したアイコンには、第2危険アイコンDIC2が重畳表示されている。ユーザE.Eが安否情報として「安全」を設定していることに基づいて、ユーザE.Eのトークルームリスト項目に対応したアイコンには、第2安全アイコンSIC2が重畳表示されている。
【0209】
本例では、グループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、グループトークルームに対応したアイコンには、安否情報に基づくアイコンが重畳表示されていない。
この場合、テニスサークルのグループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、テニスサークルのトークルームリスト項目に対応したアイコンには、第2安全アイコンSIC2および第2危険アイコンDIC2のいずれも重畳表示されていない。ゼミ仲間のグループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合であっても、ゼミ仲間のトークルームリスト項目に対応したアイコンには、第2安全アイコンSIC2および第2危険アイコンDIC2のいずれも重畳表示されていない。
【0210】
また、このトークリスト画面において、トークルームリスト項目に対応したユーザ名の下には、そのユーザによって、前述した現在地入力領域に入力されて登録された安否位置情報と、前述した安否メッセージ入力領域に入力されて登録された安否コメント情報とに基づく情報が表示されている。
この例では、限定ではなく例として、ユーザB.Bに対応する「B.B」の文字の下に、ユーザB.Bによって登録された現在地「つくば市」と、ユーザB.Bによって登録された安否メッセージ「怪我しちゃった」とを複合した(組み合わせた)情報として複合安否情報「つくば/怪我しちゃった」が表示されている。
ユーザC.CやユーザE.Eについても、登録された情報が同様に表示されている。
【0211】
なお、この表示画面例では、トークルームリスト項目のユーザ名の下に複合安否情報を表示させているが、これに限定されない。
限定ではなく例として、ユーザ名の右に複合安否情報を表示させるようにしてもよい。また、この場合、トークルームリスト項目のユーザ名の下には、そのトークルームにおける最新のコンテンツ(メッセージ)に基づく情報を表示させるようにしてもよいし、表示させなくてもよい。
【0212】
また、限定ではなく例として、ユーザのアイコンに重畳して表示される安否ステータス情報に基づくアイコン(第2安全アイコンSIC2または第2危険アイコンDIC2がタップされたことに基づいて、吹き出しやバブル等によって複合安否情報が表示されるようにしてもよい。
【0213】
また、安否位置情報と安否コメント情報との両方をトークリストに表示させることは必須ではなく、これらを別の画面に表示させてもよい。
【0214】
また、複合安否情報を、前述した友だちリストが表示される画面(ホーム画面等)に表示させるようにしてもよい。
また、安否位置情報と安否コメント情報とのいずれか一方の情報を、前述した友だちリストが表示される画面(ホーム画面等)に表示させるようにしてもよい。
【0215】
限定ではなく例として、
図1-13左側のトークリスト画面において、ユーザB.Bのトークルームリスト項目がユーザによってタップされると、限定ではなく例として、
図1-13右側のトークルーム画面が表示される。この画面は、
図1-10中央で示したトークルーム画面とは異なり、トーク領域にトークルーム内安否情報が表示されていない一方で、ユーザ別安否情報表示領域にユーザ別安否情報が表示されている。
【0216】
本例では、トークルーム名表示領域には、限定ではなく例として、ユーザA.AがユーザB.Bを相手としてトークを行うためのトークルームであることを示す文字(本例では「B.B」)が表示されている。
また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第2危険アイコンDIC2が重畳表示されたユーザB.Bのアイコンと、第2安全アイコンSIC2が重畳表示されたユーザA.Aのアイコンとが表示されている。
【0217】
また、ユーザB.Bから発信されたテキストコンテンツとして、地震で足を怪我してしまい動けなくなっていることを伝えるテキストコンテンツが、トーク領域の左側に表示されている。
【0218】
図1-14は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20Xの制御部21が実行する処理、端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0219】
ここでは、表示画面とは異なり、
・安否登録アカウント 兼 安否参照アカウント=端末20XのユーザX.X(表示画面における端末20AのユーザA.A)
・安否登録アカウント=端末20YのユーザY.Y(表示画面における端末20B~端末20Eのユーザ)
とする場合の処理を例示する。
【0220】
端末20Xの制御部21は、限定ではなく例として、災害情報を表示部24に表示させると(X120)、限定ではなく例として、安否登録アカウントの端末20Xの入出力部23に対する入力に基づいて、安否確認情報を入力するか否かを判定する(X130)。安否確認情報を入力すると判定された場合(X130:YES)、端末20Xの制御部21は、安否確認情報を受け付け、安否確認登録情報をサーバ10に送信する(X140)。安否確認情報を入力しないと判定された場合(X130:NO)、端末20Xの制御部21は、X140のステップをスキップする。
【0221】
端末20Yの制御部21においても同様に、Y110~Y140の各ステップを実行する。
【0222】
通信I/F14によって端末20Xから安否確認登録情報を受信する場合(S130)、サーバ10の制御部11は、受信した安否確認登録情報に基づいて、安否情報を生成し、各端末20に送信する(S140)。他の端末(限定ではなく例として、端末20Y)から安否確認登録情報を受信する場合についても同様である。
【0223】
通信I/F22によってサーバ10から安否情報を受信したと判定される場合(X150:YES)、端末20Xの制御部21は、受信した安否情報を表示部24に表示させる(X160)。
なお、複数回安否情報を受信したと判定される場合、端末20Xの制御部21は受信するたびに受信した安否情報を表示部24に表示させるようにしてもよいし、安否登録アカウントが異なる場合のみ受信した安否情報を表示部24に表示させるようにしてもよい。
【0224】
端末20Yの制御部21においても同様に、Y150~Y160の各ステップを実行する。
【0225】
本変形例は、安否参照アカウントのユーザの端末20が、自己の端末20のユーザによる自己の端末20に対する入力に基づいて、自己の端末20のユーザの安否に関する安否情報(または安否確認登録情報)(限定ではなく、端末のユーザの安否に関する第3情報の一例)を通信I/F122によって送信する構成を示している。
このような構成により得られる変形例の効果の一例として、端末のユーザによる端末に対する入力に基づいて、端末のユーザの安否に関する第3情報を送信して、端末のユーザの安否を他者に知らせることができる。
【0226】
<第1変形例(2)>
上記の実施例では、安否情報をユーザアカウントと関連付けて表示させる例について例示したが、これに限定されない。限定ではなく例として、安否情報を安否登録アカウントが属するグループアカウントと関連付けて表示させるようにしてもよい。
【0227】
図1-15は、本変形例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155とに加えて、グループ管理データベース157が記憶される。
【0228】
グループ管理データベース157は、グループに関する情報を管理するためのデータベースであり、その一例であるグループ管理データベース157のデータ構成例を
図1-16に示す。
グループ管理データベース157には、グループごとの管理データとして、グループ管理データが記憶される。
【0229】
各々のグループ管理データには、限定ではなく例として、グループIDと、グループ名と、グループメンバーデータとが記憶される。
【0230】
グループIDは、グループ管理データで管理されるグループを識別するための情報である。
このグループIDは、好ましくはグループごとに一意な値であり、限定ではなく例として、サーバ10によってグループごとに一意な値(固有の値)が設定されて記憶される。
【0231】
グループ名は、このグループの名称であり、限定ではなく例として、端末20のユーザがグループを作成する際に登録する名称が記憶される。
【0232】
グループメンバーデータは、このグループのメンバーである(グループに属する)アカウントのアプリケーションIDを記憶させるためのデータであり、限定ではなく例として、ユーザがグループ参加登録を行うと、サーバによってグループ参加登録を行ったユーザのアプリケーションIDが追加され更新される。
【0233】
なお、グループ管理データに、グループの代表であるアカウントのアプリケーションIDを関連付けて記憶させるようにしてもよい。
【0234】
図1-17左側は、ユーザA.Aの端末20Aのトークリスト画面が表示されている。このトークリスト画面では、
図1-13左側の表示画面から、B.Bとのトークルームが閲覧されたことに基づいて、B.Bとの間でのメッセージ未読数が「0」(非表示)となっている。
【0235】
限定ではなく例として、
図1-17左側のトークリスト画面において、ゼミ仲間のトークルームリスト項目がユーザによってタップされると、限定ではなく例として、
図1-17右側のトークルーム画面が表示される。
この画面は、
図1-13右側の表示画面と異なり、トークルーム名表示領域には、限定ではなく例として、ユーザA.Aがゼミ仲間のグループを相手としてトークを行うためのトークルームであることを示す文字(本例では「ゼミ仲間(4)」(数字はメンバー数))が表示されている。
【0236】
ユーザ別安否情報表示領域には、ユーザ別安否情報として、第2危険アイコンDIC2が重畳表示されたユーザB.Bのアイコンと、第2安全アイコンSIC2が重畳表示されたユーザA.Aのアイコンと、第2安全アイコンSIC2が重畳表示されたユーザD.Dのアイコンと、第2危険アイコンDIC2が重畳表示されたユーザF.Fのアイコンとが表示されている。
【0237】
また、トーク領域には、ユーザD.Dから送信されたコンテンツとして、ユーザB.Bが今日つくばで学会発表する予定であることを確認するテキストコンテンツが表示され、その下には、ユーザF.Fから送信されたコンテンツとして、つくばで震度5弱の地震が発生したことでユーザB.Bを心配するテキストコンテンツが表示されている。
【0238】
図1-18左側には、ユーザA.Aの端末20Aのトークリスト画面を示している。
このトークリスト画面は、
図1-13左側のトークリスト画面とは異なり、グループトークルームに属するいずれかのメンバーが安否情報の設定を行っている場合に、グループトークルームに対応したアイコンに、安否情報に基づく画像(アイコン等)が関連付けて表示される一例を示す図である。
【0239】
本例では、グループトークルームに属するメンバーが安否情報の設定を行っている場合に、グループトークルームに対応したアイコンに、安否情報に基づくエフェクト安否情報が付加表示される。
限定ではなく例として、グループトークルームに属する全てのメンバーの安否情報が「安全」を設定している場合、第1エフェクト情報SFA(限定ではなく例として、白色のオブジェクト)がグループトークルームに対応したアイコンに付加表示される。
限定ではなく例として、グループトークルームに属する1名以上のメンバーの安否情報が「危険」を設定している場合、第2エフェクト情報DFA(限定ではなく例として、赤色のオブジェクト)がグループトークルームに対応したアイコンに付加表示される。
【0240】
この例では、テニスサークルのグループトークルームに属するメンバー全員が、安否情報として「安全」を設定していることに基づいて、テニスサークルのグループトークルームに対応したアイコンに、第1エフェクト情報SFAが付加表示されている。
また、この例では、ゼミ仲間のグループトークルームに属するメンバーのうち1名が、安否情報として「危険」を設定していることに基づいて、ゼミ仲間のグループトークルームに対応したアイコンに、第2エフェクト情報DFAが付加表示されている。
【0241】
限定ではなく例として、
図1-18左側のトークルームリスト画面において、ゼミ仲間のトークルームリスト項目がユーザによってタップされると、限定ではなく例として、
図1-18右側のトークルーム画面が表示される。
この画面は、
図1-17右側のトークルーム画面と同様であるので説明を省略する。
【0242】
なお、表示態様を変更する手法は上記に限られない。
限定ではなく例として、グループトークルームに属する全てのメンバーの安否情報が「安全」を設定している場合は「青色」でグループトークルームに対応したアイコンを表示させ、グループトークルームに属する1名以上のメンバーの安否情報が「危険」を設定している場合は「赤色」でグループトークルームに対応したアイコンを表示させるなどしてもよい。
さらに細分化して、グループトークルームに属するメンバーのうちの「危険」を設定している人数(または割合)に基づいて、「黄色」、「赤色」でグループトークルームに対応したアイコンを表示させたり、上記のエフェクト表示を行うようにしてもよい。
また、これらに限定されるわけではなく、グループトークルームの名称を示す文字の色や書体を変えて表示させるなどしてもよい。
【0243】
トークリスト内に表示させる場合、限定ではなく例として、サーバ10の制御部11は、安否確認登録情報を受信すると、グループ管理データベース157を参照し、安否登録アカウントが属するグループを検索する。そして、安否登録アカウントが属する各々のグループについて、グループメンバーデータに登録されている各アプリケーションIDの安否登録データを参照する。
あるグループメンバーデータに登録されている全てのアプリケーションIDの安否登録データが「安全」である場合、サーバ10の制御部11は、そのグループに対する安否情報(以下、「グループ安否情報」と称する。)をメンバー全員が「安全」であることを示す第1態様で生成する。全てのアプリケーションIDの安否登録データが「安全」でない場合には、サーバ10の制御部11は、そのグループに対するグループ安否情報をメンバー全員が「安全」ではないことを示す第2態様で生成する。
そして、サーバ10の制御部11は、グループ安否情報を通信I/F14によってそのグループメンバーデータに登録されている全てのアカウントの端末20に送信する。
【0244】
上記の実施例および本変形例は、安否参照アカウントのユーザの端末20は、安否情報を含む、一対一トークルームやグループトークルーム等のトークルーム(限定ではなく、第1チャットルームの一例)に含まれるユーザの安否に関する情報に基づいて、そのトークルームに関する情報の表示態様を変更する制御を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として。第1情報を含む、第1端末のユーザと端末のユーザとを含む第1チャットルームに含まれるユーザの安否に関する情報に基づいて、第1チャットルームに関する情報の表示態様を適切に変更することができる。
【0245】
<第1変形例(3)>
上記の実施例では、安否ステータス情報を「安全」と「危険」の2クラスとしたが、これに限定されない。他の安否ステータス情報を含めるようにしてもよい。
限定ではなく例として、安否情報を「安全」と「危険」と「エリア外」の3クラスで設定可能であるようにしてもよい。
【0246】
図1-19左側は、ユーザA.Aの端末20Aのホーム画面が表示されている。この画面は、
図1-12中央のホーム画面とは異なり、安否登録領域R1において、安否情報として安全であることを設定するための安全ボタンSBTと、安否情報として安全でないことを設定するための危険ボタンDBTとに加えて、安否情報としてエリア外であることを設定するためのエリア外ボタンABT(本例では、「エリア外」の文字で示されるボタン)が表示される一例を示す図である。
【0247】
「エリア外」である場合とは、限定ではなく例として、現在発生している災害の影響を受けない位置にユーザが位置している場合であり、限定ではなく例として、災害が地震である場合、ユーザの端末20が示す現在地が震源地から設定距離(限定ではなく例として200km)以上離れた位置に位置している場合等である。
【0248】
限定ではなく例として、
図1-19左側の安否登録領域R1において、安全ボタンSBTがユーザA.Aによってタップされた後、登録ボタンBT3がユーザA.Aによってタップされ、ホーム画面に表示が遷移する(不図示)。そして、このホーム画面において、画面最下部のトークの項目がユーザによってタップされると、限定ではなく例として、
図1-19右側に示すトークリスト画面が端末20Aの表示部24に表示される。
【0249】
このトークリスト画面では、
図1-13左側のトークリスト画面とは異なり、ユーザE.Eが安否情報として「エリア外」を設定していることに基づいて、ユーザE.Eに対応したアイコンに、エリア外であることを示すエリア外アイコンAIC(本例では、「エリア外」の文字を含むアイコン)が重畳表示されている。
【0250】
なお、これら以外にも、限定ではなく例として、元気であることを示す「元気」、少し元気であることを示す「少し元気」、あまり元気ではないことを示す「あまり元気ない」、元気がないことを示す「元気ない」等の情報を安否ステータス情報に含めるようにしてもよい。
【0251】
<第1変形例(4)>
上記の実施例では、サーバ10において、安否確認登録情報に基づく安否情報を生成したが、これに限定されない。限定ではなく例として、端末20において安否情報を生成するようにしてもよい。
【0252】
この場合、限定ではなく例として、安否登録アカウントの端末20Yの制御部21は、安否確認登録情報を受け付けると、安否情報を生成する。すると、安否登録アカウントの端末20Yの制御部21は、安否登録アカウントの友だち管理データを参照し、限定ではなく例として、安否登録アカウントと友だち登録済みであるアカウントの各端末20に安否情報を送信する。
【0253】
なお、安否登録アカウントの端末20Yの制御部21は、限定ではなく例として、サーバ10を介して安否情報を各端末20に送信するようにしてもよい。また、安否登録アカウントの端末20Yの制御部21は、限定ではなく例として、ブロードキャスト通信を利用して、全ての端末20に安否情報を送信するようにしてもよい。
【0254】
<第2実施例>
第1実施例では、安否登録アカウントの端末20において、一度だけ安否登録を行う例を例示した。第2実施例は、安否登録アカウントの端末20のユーザが繰り返し安否登録を行うことで、安否参照アカウントの端末20において安否情報が更新される実施例である。
【0255】
第2実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0256】
<表示画面>
本実施例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。また、安否参照アカウントの端末20において、安否情報をトークルーム内にのみ表示する場合について例示する。
【0257】
図2-1左側のホーム画面では、限定ではなく例として、ユーザY.Yが安否情報として「危険」を設定していることに基づいて、ユーザ状態アイコンICYD(ユーザY.Y、危険)が表示されている。
【0258】
また、ユーザY.Yの端末20Yのホーム画面に重畳して、安否登録領域R1がせり上がり表示されている。この安否登録領域R1は、本実施例では、安否情報を変更するために用いられる。
【0259】
安否登録領域R1には、ユーザに安否情報を設定することを促す旨のメッセージ(本例では、「安否確認」の文字と、「みんなに安否を伝えよう」の文字)が表示されている。その下には、安全ボタンSBTと危険ボタンDBTとが設けられている。また、画面下部には、安否情報を、選択された安否情報に変更するための変更ボタンBT5が表示されている。
【0260】
限定ではなく例として、
図2-1左側の安否情報変更領域において、安全ボタンSBTがユーザによってタップされた後、変更ボタンBT5がユーザによってタップされた場合における、ユーザX.Xの端末20Xに表示されるトークリスト画面の一例を
図2-1中央に示す。このトークリスト画面は、
図1-10左側の表示画面と同様であるので説明を省略する。
【0261】
限定ではなく例として、
図2-1中央のトークリスト画面において、ユーザY.Yに対応したトークルームリスト項目がユーザによってタップされると、限定ではなく例として、
図2-1右側のトークルーム画面が表示される。
【0262】
このトークルーム画面のトーク領域の上部には、限定ではなく例として、ユーザY.Yが設定した安否情報をトークルーム内で通知するための第1通知情報NI1(本例では、「Y.Yさんが安否確認に回答しました」の文字と、ユーザ状態アイコンICYD(ユーザY.Y、危険))が表示されている。
その下には、限定ではなく例として、ユーザY.Yからのコンテンツとして、テキストコンテンツ(「地震 大丈夫だった?」)が表示されている。
【0263】
また、その下には、ユーザY.Yが安否情報を「危険」から「安全」に変更したことに基づき、限定ではなく例として、安否が安全に変更された第2通知情報NI2(本例では、「Y.Yさんが安否確認に回答しました」の文字と、ユーザ状態アイコンICYS(ユーザY.Y、安全))が表示されている。
その下には、限定ではなく例として、ユーザY.Yからのコンテンツとして、テキストコンテンツ(「避難しました!」)が表示されている。
【0264】
<処理>
図2-2は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20Xの制御部21が実行する処理、端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0265】
限定ではなく例として、S120とX120とY120とのステップが実行されると、安否確認処理が実行される(X210、Y210、S210)。
【0266】
図2-3は、安否確認処理の流れの一例を示すフローチャートである。図の見方は、
図2-2と同様である。
端末20Xの制御部21は、限定ではなく例として、
図1-14におけるX130~X160のステップと同様に、X2130~X2160のステップを実行する。また、端末20Yの制御部21は、限定ではなく例として、
図1-14におけるY130~Y160のステップと同様に、Y2130~Y2160のステップを実行する。サーバ10の制御部11は、限定ではなく例として、
図1-14におけるS130~S140のステップと同様に、S2130~S2140のステップを実行する。
【0267】
図2-2に戻り、安否確認処理が実行されると、端末20Xの制御部21と、端末20Yの制御部21と、サーバ10の制御部11とは、処理を終了させるか否かを判定する(X220、Y220、S220)。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間(限定ではなく例として、一週間)が経過した場合や、サーバ10のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。
【0268】
処理を終了させると判定された場合(X220:YES、Y220:YES、S220:YES)、各端末20の制御部21およびサーバ10の制御部11は、処理を終了させる。
処理を終了させないと判定された場合(X220:NO、Y220:NO、S220:NO)、各端末20の制御部21およびサーバ10の制御部11は、再度安否確認処理を実行させる(X210、Y210、S210)。
【0269】
なお、各端末20の制御部21およびサーバ10の制御部11は、安否確認処理の前後の任意のタイミングにおいてチャット処理を実行するようにしてもよい。
【0270】
図2-4は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
ここでは、表示画面と同様に、
・安否登録アカウント=端末20YのユーザY.Y(限定ではなく、第1端末のユーザの一例)のアカウント
・安否参照アカウント=端末20XのユーザX.X(限定ではなく、端末のユーザの一例)のアカウント
とする場合の処理を例示する。
【0271】
限定ではなく例として、安否確認処理が実行され、端末20Yにおいて、安否確認登録情報の入力(操作入力等)を受け付ける(Y2130)と、第1の安否確認登録情報がサーバ10に送信される(Y2140)(タイミング「TM110」)。そして、サーバ10は第1の安否確認登録情報を受信する(S2130:YES)。
サーバ10の制御部11は、第1の安否確認登録情報に基づいて、第1の安否情報を生成し、各端末20に送信する(S2140)(タイミング「TM120」)。
端末20Xは第1の安否情報を受信すると表示処理を実行する(X2160)(タイミング「TM130」)。
【0272】
再度安否確認処理が実行され、端末20Yにおいて、安否確認登録情報の入力を受け付ける(Y2130)と、第1の安否確認登録情報がサーバ10に送信される(Y2140)(タイミング「TM140」)。そして、サーバ10は第2の安否確認登録情報を受信する(S2130:YES)。
サーバ10の制御部11は、第2の安否確認登録情報に基づいて、第2の安否情報を生成し、各端末20に送信する(S2140)(タイミング「TM150」)。
端末20Xは第2の安否情報を受信すると表示処理を実行する(X2160)(タイミング「TM160」)。
【0273】
なお、サーバ10の制御部11は、第2の安否確認登録情報を受信した場合、第1の安否確認登録情報と第2の安否確認登録情報との安否比較処理を行うようにしてもよい。そして、第1の安否確認登録情報と第2の安否確認登録情報とに差異が生じていない場合、第2の安否情報を各端末20に送信しないようにしてもよい。
【0274】
また、サーバ10の制御部11は、安否比較処理の結果、第1の安否確認登録情報と第2の安否確認登録情報とに差異が生じている場合、安否登録アカウントの安否状況に変化が生じたことを示す安否変化情報を各端末20に送信するようにしてもよい。
【0275】
本タイミングチャートでは、安否登録アカウントの端末20Yにおいて2回安否確認登録情報が入力される例を例示したが、3回以上安否確認登録情報が入力される場合についても同様に処理を実行することができる。
【0276】
<第2実施例の効果>
本実施例は、安否参照アカウントのユーザの端末20が、安否登録アカウントのユーザ(限定ではなく、第1端末のユーザの一例)によって、第1の安否情報(限定ではなく、第1情報の一例)が第2の安否情報(限定ではなく、第2情報の一例)に変更された場合、第2の安否情報を通信I/F22によって受信する構成を示している。
このような構成により得られる実施例の効果の一例として、第1端末のユーザによって、第1端末のユーザの安否に関する第1情報が第2情報に変更された場合であっても、端末が第2情報を確実に取得可能となる。
【0277】
また、この場合、第2の安否情報は、安否登録アカウントのユーザ(限定ではなく、第1端末のユーザの一例)と安否参照アカウントのユーザ(限定ではなく、端末のユーザの一例)とを含むトークルーム(限定ではなく、第1チャットルームの一例)に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザと端末のユーザとを含む第1チャットルームへの表示という分かり易い形で、第2情報を端末のユーザに知らせることができる。
【0278】
<第2変形例(1)>
上記の実施例では、安否登録アカウントの端末20において第2の安否確認登録情報が登録されると、安否参照アカウントの端末20は自動的に第2の安否情報を受信する例を例示したが、これに限定されない。
限定ではなく例として、安否参照アカウントの端末20において、特定の表示要素を表示させた場合など、設定された条件が成立した場合に、第2の安否情報を受信するようにしてもよい。
【0279】
本変形例における表示画面では、安否確認情報として、安否ステータス情報のみを登録する例について例示する。また、安否参照アカウントの端末20において、安否情報を友だちリストと、ユーザのプロフィール画面とに表示させる場合について例示する。なお、安否情報をトークリスト画面やトークルーム画面に表示させるようにしてもよい。
【0280】
図2-5左側は、ユーザY.Yの端末20Yのホーム画面に重畳して、設定済みの安否情報を変更するための安否情報変更領域がせり上がり表示されている。このホーム画面は、
図2-1左側の表示画面と同様であるので説明を省略する。
【0281】
限定ではなく例として、
図2-5左側の安否情報変更領域において、安全ボタンSBTがユーザによってタップされた後、変更ボタンBT5がユーザによってタップされた場合における、ユーザX.Xの端末20Xに表示されるホーム画面の一例を
図2-5中央に示す。
【0282】
このホーム画面では、友だちリストの項目として、ユーザY.Yに対応したアイコンおよびユーザ名、ユーザA.Aに対応したアイコンおよびユーザ名、ユーザB.Bに対応したアイコンおよびユーザ名等が一覧表示されている。そして、この例では、ユーザY.Yが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザY.Yのアイコンと関連付けて第1危険アイコンDIC1が重畳表示され、ユーザA.Aが安否情報として「安全」を設定していることに基づいて、友だちリストのユーザA.Aのアイコンと関連付けて第1安全アイコンSIC1が重畳表示され、ユーザB.Bが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザB.Bのアイコンと関連付けて第1危険アイコンDIC1が重畳表示されている。
【0283】
限定ではなく例として、
図2-5中央のホーム画面において、ユーザY.Yに対応した友だちリストの項目がユーザによってタップされると、限定ではなく例として、
図2-5右側のユーザY.Yに対応したプロフィール画面に表示が遷移する。
【0284】
プロフィール画面は、限定ではなく例として、選択されたユーザのプロフィールに関する情報を表示する画面とすることができる。そして、このプロフィール画面には、限定ではなく例として、各ユーザのメッセージングアプリケーションにおけるアイコン画像、ユーザ名、安否に関する情報、そのユーザを相手としたトークを行うためのボタン、そのユーザを相手とした音声通話を行うためのボタン、このユーザを相手としたビデオ通話を行うためのボタン等を表示させるようにすることができる。
【0285】
この例では、ユーザY.Yが安否情報を「危険」から「安全」に変更したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション(サーバ10)を発信元とする、ユーザY.Yが安否情報を変更したことを示すテキスト(Y.Yさんのステータス(ステイタス)が変わりました)やアイコン(ユーザY.Yのアイコンおよび第2危険アイコンDIC2→第2安全アイコンSIC2)等を含む、プッシュ形式で表示されるプッシュ通知PN1が表示されている。
【0286】
また、ユーザY.Yのプロフィールを示すアイコンおよびユーザ名の下には、ユーザY.Yの安否に関する情報として、第2安全アイコンSIC2が表示されている。
より具体的には、
図2-5中央のホーム画面では、友だちリストのユーザY.Yのアイコンと関連付けて第1危険アイコンDIC1が表示されていた。ユーザY.Yによって安否に関する第1情報(危険)が第2情報(安全)に変更され、
図2-5右側に示すユーザY.Yのプロフィール画面が表示されたことに基づき、ユーザY.Yのアイコンと関連付けて第2安全アイコンSIC2が表示されている。
【0287】
この例では、
図2-5中央のホーム画面において、ユーザY.Yに対応した友だちリストの項目がユーザによってタップされると、端末20Xの制御部21は、
図2-5右側のユーザY.Yに対応したプロフィール画面を表示させる。そして、端末20Xの制御部21は、安否更新要求情報を通信I/F22によってサーバ10に送信し、これに基づいて、上記のプッシュ通知で表示するための情報が、サーバ10から端末20Xに送信される。そして、端末20Xの制御部21は、受信した情報に基づいて、上記のプッシュ通知を表示させるとともに、受信した情報に基づいて、変更後の安否情報に対応するアイコン(この例では、安全に対応する第2安全アイコンSIC2)を表示させる。
【0288】
なお、端末20Xの制御部21が安否更新要求情報をサーバ10に送信すると、これに基づいて、変更後の安否情報(この例では、安全)がサーバ10から端末20Xに送信されるようにする。そして、端末20Xの制御部21は、受信した情報に基づいて、変更後の安否情報に対応するアイコン(この例では、安全に対応する第2安全アイコンSIC2)を表示させる。また、端末20Xの制御部21は、先に受信していた変更前の安否情報(この例では「危険」)と、新たに受信した変更後の安否情報(この例では「安全」)とに基づいて、上記のプッシュ通知を表示するための情報を生成して、上記のプッシュ通知を表示させるようにしてもよい。
【0289】
なお、
図2-5右側のプロフィール画面が表示された場合であっても、上記のプッシュ通知を表示させないようにしてもよい。
また、
図2-5中央のホーム画面の友だちリストにおいて、そのリストに含まれるユーザに関連付けて安否に関する情報(第1安全アイコンSIC1または第1危険アイコンDIC1)を表示させないが、
図2-5右側のプロフィール画面が表示された場合に、上記のプッシュ通知を表示させるようにしてもよい。
【0290】
また、
図2-5中央のホーム画面において、ユーザY.Yに対応した友だちリストの項目がユーザによってタップされると、端末20Xの制御部21は、
図2-5右側のユーザY.Yに対応したプロフィール画面を表示させるが、変更前の安否情報に対応するアイコン(この例では、危険に対応する第2危険アイコンDIC2)を表示させるようにする。そして、端末20Xの制御部21は、安否更新要求情報をサーバ10に送信し、これに基づいて、変更後の安否情報(この例では、安全)がサーバ10から端末20Xに送信されるようにする。そして、端末20Xの制御部21が、変更前の安否情報に対応するアイコン(この例では、危険に対応する第2危険アイコンDIC2)の表示を、変更後の安否情報に対応するアイコン(この例では、安全に対応する第2安全アイコンSIC2)に変更する制御を行うようにしてもよい。
【0291】
また、限定ではなく例として、前述したトークリスト画面において、ユーザのトークルームリスト項目に対応したアイコンに重畳して表示される安否ステータス情報に基づくアイコン(第2安全アイコンSIC2または第2危険アイコンDIC2)がタップされると、そのユーザのプロフィール画面が表示されるようにしてもよい。
限定ではなく例として、
図1-13左側の画面においてユーザB.Bのトークルームリスト項目に対応したアイコンに重畳して表示されている第2危険アイコンDIC2がタップされると、限定ではなく例として
図2-5右側のプロフィール画面と同様の態様で、ユーザB.Bのプロフィール画面が表示されるようにしてもよい。この場合、ユーザB.Bのプロフィール画面には、第2危険アイコンDIC2が表示されるようにすることができる。
【0292】
また、安否登録アカウントによって安否情報が登録されると、安否参照アカウントの端末20において、安否登録アカウントのユーザのトークルームリスト項目(限定ではなく例として、ユーザのトークルームリスト項目に対応したアイコンや安否ステータス情報に基づくアイコン)を光らせて表示させるなどしてもよい。そして、光っている項目がタップされると、そのユーザのプロフィール画面が表示されるようにしてもよい。
【0293】
また、前述したように、安否位置情報と安否コメント情報とを別の画面に表示させてもよく、限定ではなく例として、これらのうちの一方の情報をトークリスト画面に表示させ、他方の情報をプロフィール画面に表示させてもよい。
【0294】
また、複合安否情報を、上記のプロフィール画面に表示させるようにしてもよい。
また、安否位置情報と安否コメント情報とのいずれか一方の情報を、上記のプロフィール画面に表示させるようにしてもよい。
【0295】
また、上記の例とは異なるが、安否情報を上記のプロフィール画面には表示させないようにしてもよい。一例として、安否情報を前述したホーム画面に表示させるが、上記のプロフィール画面には表示させないようにしてもよい。
【0296】
また、上記のプロフィール画面に代えて、安否情報を表示する専用の画面を表示させるなどしてもよい。
【0297】
図2-6は、本変形例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
ここでは、表示画面と同様に、
・安否登録アカウント=端末20YのユーザY.Y(限定ではなく、第1端末のユーザの一例)のアカウント
・安否参照アカウント=端末20XのユーザX.X(限定ではなく、端末のユーザの一例)のアカウント
とする場合の処理を例示する。
【0298】
限定ではなく例として、安否確認処理が実行され、端末20Yにおいて、安否確認登録情報の入力を受け付ける(Y2130)と、第1の安否確認登録情報がサーバ10に送信される(Y2140)(タイミング「TM210」)。そして、サーバ10は第1の安否確認登録情報を受信する(S2130:YES)。
サーバ10の制御部11は、第1の安否確認登録情報に基づいて、第1の安否情報を生成し、各端末20に送信する(S2140)(タイミング「TM220」)。
端末20Xは第1の安否情報を受信すると表示処理を実行する(X2160)(タイミング「TM230」)。
【0299】
再度安否確認処理が実行され、端末20Yにおいて、安否確認登録情報の入力を受け付ける(Y2130)と、第1の安否確認登録情報がサーバ10に送信される(Y2140)(タイミング「TM240」)。そして、サーバ10は第2の安否確認登録情報を受信する(S2130:YES)。サーバ10の制御部11は、第2の安否確認登録情報に基づいて、第2の安否情報を生成する。
【0300】
端末20Xにおいて、限定ではなく例として、ユーザX.Xの端末20に対するユーザ操作に基づいて、メッセージングアプリケーションにおける特定表示要素を表示させる表示処理が実行される(タイミング「TM250」)。
ここで、特定表示要素としては、限定ではなく例として、以下の表示要素が挙げられる。
・安否登録アカウントのユーザのプロフィール画面
・安否登録アカウントと安否参照アカウントとの一対一トークルーム
・安否登録アカウントを含むグループトークルーム
・安否登録アカウントを含むトークリスト画面
・安否確認サービスの公式アカウントプロフィール画面
・安否確認サービスの公式アカウントと安否参照アカウントとのトークルーム
・安否確認サービスの公式アカウントを含むトークリスト画面
なお、トークリスト画面については、過剰に安否情報が表示されることを防ぐために、特定表示要素から除外するようにしてもよい。
【0301】
すると、端末20Xの制御部21は、所定の安否登録アカウントの安否情報を要求するための安否更新要求情報を通信I/F22によってサーバ10に送信する(タイミング「TM260」)。
【0302】
サーバ10の制御部11は、安否更新要求情報を受信する場合、第2の安否情報を安否参照アカウントの端末20Xに送信する(S2140)(タイミング「TM270」)。
なお、サーバ10の制御部11は、安否比較処理の結果、第1の安否確認登録情報と第2の安否確認登録情報とに差異が生じていない場合、第2の安否情報を端末20Xに送信しないようにしてもよい。この場合、安否に変更がないことを示す情報を端末20Xに送信するようにしてもよい。
また、サーバ10の制御部11は、安否比較処理の結果、第1の安否確認登録情報と第2の安否確認登録情報とに差異が生じている場合、安否登録アカウントの安否状況に変化が生じたことを示す安否変化情報を端末20Xに送信するようにしてもよい。
【0303】
端末20Xは第2の安否情報を受信すると、表示処理を実行する(X2160)(タイミング「TM280」)。
【0304】
本タイミングチャートでは、安否登録アカウントの端末20Yにおいて2回安否確認登録情報が入力される例を例示したが、3回以上安否確認登録情報が入力される場合についても同様に処理を実行することができる。
【0305】
本変形例は、安否参照アカウントのユーザの端末20が、第1の安否情報(限定ではなく、第1情報の一例)を通信I/F22によって受信した後、安否登録アカウントのユーザ(限定ではなく、第1端末のユーザの一例)と安否参照アカウントのユーザ(限定ではなく、端末のユーザの一例)とを含むトークルーム(限定ではなく、第1チャットルームの一例)を表示部24に表示した場合、第2の安否情報(限定ではなく、第2情報の一例)を通信I/F22によって受信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末が第1情報を受信した後、第1端末のユーザと端末のユーザとを含む第1チャットルームを表示することを契機として、端末が第2情報を取得できるようにすることができる。また、このようにすることで、むやみに第2情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。
【0306】
また、安否参照アカウントのユーザの端末20は、安否登録アカウントのユーザのプロフィール情報などの安否登録アカウントのユーザの情報(限定ではなく、第1端末のユーザの情報の一例)を表示部24に表示した場合、第2の安否情報を通信I/F22によって受信する構成としてもよい。
このような構成により得られる実施例の効果の一例として、端末が第1端末のユーザの情報を表示することを契機として、端末が第2情報を取得できるようにすることができる。また、このようにすることで、むやみに第2情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。
【0307】
また、この場合、安否登録アカウントのユーザの情報は、安否登録アカウントのユーザの安否に関連する情報(安全、危険など)を含む、安否登録アカウントのユーザのステータスに関する情報を含むようにすることができる。
このような構成により得られる変形例の効果の一例として、端末が第1端末のユーザの安否に関連する第1情報を含む、第1端末のユーザのステータスに関する情報を表示することを契機として、端末が第2情報を取得できるようにすることができる。また、このようにすることで、むやみに第2情報を受信せずに済み、端末のユーザが煩わしさを感じないようにすることができる。
【0308】
<第2変形例(2)>
上記の実施例では、安否登録アカウントの端末20において第2の安否確認登録情報が登録されると、安否参照アカウントの端末20は自動的に第2の安否情報を受信する例を例示したが、これに限定されない。
限定ではなく例として、安否参照アカウントと安否登録アカウントとの関係性に基づいて、第2の安否情報を受信するようにしてもよい。
【0309】
限定ではなく例として、以下のように安否参照アカウントと安否登録アカウントとの親密度を定義する。
親密度(安否参照アカウント,安否登録アカウント)=安否参照アカウントと安否登録アカウントとにおける1日当たりの平均メッセージ送受信回数
【0310】
この場合、限定ではなく例として、親密度が設定値(限定ではなく例として、「10」通)以上、または設定値より大きい場合、サーバ10の制御部11は、第2の安否情報を安否参照アカウントの端末20に送信するようにしてもよい。
【0311】
なお、親密度が設定値以上、または設定値より大きい場合、安否参照アカウントの端末20は、安否更新要求情報を設定時間間隔(限定ではなく例として、「5分間」)ごとにサーバ10に送信する。そして、サーバ10の制御部11は、安否更新要求情報を受信する場合、第2の安否情報を安否参照アカウントの端末20に送信するようにしてもよい。
【0312】
本変形例は、第2の安否情報(限定ではなく、第2情報の一例)は、安否参照アカウントのユーザと安否登録アカウントのユーザとの関係に基づいて送信される構成を示している。
このような構成により得られる実施例の効果の一例として、第1端末のユーザと、端末のユーザとの関係に基づいて適切に送信された第2情報を、端末が受信できるようにすることができる。
【0313】
<第2変形例(3)>
上記の実施例では、安否登録アカウントと安否参照アカウントとが異なる例について例示したが、これに限定されない。ここでは、
・安否登録アカウント 兼 安否参照アカウント=端末20AのユーザA.Aのアカウントとする場合を例示する。
【0314】
図2-7左側は、ユーザA.Aの端末20Aのトークリスト画面の一例を示している。このトークリスト画面は、
図1-13左側の表示画面と同様であり、ユーザA.Aが、自身は「安全」であることを設定したことに基づき、その旨を示すユーザ状態アイコン(ユーザA.A、安全))を含む情報が、第2災害情報表示領域に表示されている。つまり、この例では、ユーザA.Aのアカウントは、安否登録アカウントとして機能している。
【0315】
限定ではなく例として、
図2-7左側のトークリスト画面において、ユーザC.Cのトークルームリスト項目がユーザによってタップされると、限定ではなく例として、
図2-7中央のトークルーム画面が表示される。この画面は、
図1-13右側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザA.AがユーザC.Cを相手としてトークを行うためのトークルームであることを示す文字(本例では「C.C」)が表示されている。
また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第2危険アイコンDIC2が重畳表示されたユーザC.Cのアイコンと、第2安全アイコンSIC2が重畳表示されたユーザA.Aのアイコンとが表示されている。
【0316】
トーク領域には、限定ではなく例として、ユーザC.Cからのコンテンツ(限定ではなく例として「地震だ~揺れがすごい」のテキストコンテンツ、「エレベーター止まった」のテキストコンテンツ)と、ユーザA.Aによって発信されたコンテンツ(限定ではなく例として「地震大丈夫?誰かと一緒にいる?」のテキストコンテンツ)とが表示されている。
【0317】
限定ではなく例として、ユーザC.Cによって安否情報が変更された場合における、ユーザA.Aの端末20Aに表示されるトークルーム画面の一例を
図2-7右側に示す。
この例では、ユーザC.Cが安否情報を「危険」から「安全」に変更したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション(サーバ10)を発信元とする、ユーザC.Cが安否情報を変更したことを示すテキスト(C.Cさんのステータス(ステイタス)が変わりました)やアイコンを含むプッシュ通知PN3が表示されている。
【0318】
また、トーク領域には、限定ではなく例として、新たなユーザC.Cからのコンテンツ(限定ではなく例として「エレベーター止まった」のテキストコンテンツ、「1人だよー怖いよー あ、エレベーター動いた!」のテキストコンテンツ、「出られた~~!」のテキストコンテンツ)が表示されている。
【0319】
また、この表示画面例では、ユーザC.Cのテキストコンテンツ「出られた~~!)の下に、ユーザY.Yが変更した安否情報をトークルーム内で通知する通知情報として、限定ではなく例として、「C.Cさんのステイタスが変わりました」の文字と、ユーザ状態アイコンICCD(ユーザC.C、危険)→ユーザ状態アイコンICCS(ユーザC.C、安全)とを含む第3通知情報NI3が表示されている。
【0320】
また、この第3通知情報NI3の下には、ユーザA.Aによって発信されたコンテンツ(限定ではなく例として「よかったーー」のテキストコンテンツ)が表示されている。
【0321】
つまり、この例では、ユーザA.Aのアカウントは、安否参照アカウントとしても機能している。
【0322】
<第3実施例>
第3実施例は、2以上の安否登録アカウントの端末20間で通話を行う場合、限定ではなく例として、登録された安否ステータス情報に基づいて、接続制御を行う実施例である。
【0323】
以下では、通話を行うために発信する者である発信元のユーザアカウントを「発信元アカウント」、発信された通話を受ける者である着信先のユーザアカウントを「発信先アカウント」と称する。
【0324】
第3実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0325】
<表示画面>
本実施例における表示画面では、発信元アカウントを端末20AのユーザA.A、発信先アカウントを、端末20BのユーザB.Bおよび端末20CのユーザC.Cとする。また、発信元アカウントおよび発信先アカウントは、安否登録を済ませた安否登録アカウントとして例示する。
【0326】
図3-1左側は、ユーザA.Aの端末20Aのトークルーム画面が表示されている。この画面は、
図1-13右側で示した表示画面と同様であるので説明を省略する。
【0327】
限定ではなく例として、
図3-1左側のトークルーム画面において、トークルーム名表示領域の右部の通話を行うための通話ボタンBT7がユーザによってタップされた場合における、ユーザA.Aの端末20Aに表示される通話画面の一例を
図3-1右側に示す。
【0328】
通話画面には、画面最上部のメッセージングアプリケーションの名称等が表示される領域の下に、限定ではなく例として、通話ステータス(通話の状態)を示す通話ステータス表示領域が設けられている。通話ステータスとしては、限定ではなく例として、ユーザA.AがユーザB.Bに発信していることを示す「発信中」、ユーザA.AがユーザB.Bと通話していることを示す「通話中」等が設けられている。
【0329】
その下には、通話相手となるユーザのメッセージングアプリケーションにおけるアイコン画像、ユーザ名、通話時間、マイクをオフにするためのマイクオフボタン(本例では、マイク型の画像と「マイクをオフ」の文字)、そのユーザを相手としたビデオ通話を行うためのビデオ通話ボタン(本例では、ビデオカメラ型の画像と「ビデオ通話を開始」の文字)、スピーカをオンにするためのスピーカオンボタン(本例では、スピーカ型の画像と「スピーカをオン」の文字)、および、通話を終了するための通話終了ボタン等が表示されている。
【0330】
本例では、通話ステータス表示領域には、「通話中」の文字が表示されており、その下には、ユーザB.Bのアイコン画像、「B.B」の文字、通話時間として「1:47」の数字、マイクオフボタン、ビデオ通話ボタン、スピーカオンボタン、および、通話終了ボタンが表示されている。
【0331】
図3-2左側は、ユーザA.Aの端末20Aのトークルーム画面が表示されている。この画面は、
図2-7右側で示したトークルーム画面と同様であるものの、トークルーム名表示領域には、限定ではなく例として、前の画面に戻るための「<」の戻るボタン、ユーザA.AがユーザC.Cを相手としてトークを行うためのトークルームであることを示す文字(本例では「C.C」)、および通話ボタン等が表示されている。
【0332】
限定ではなく例として、
図3-2左側のトークルーム画面において、トークルーム名表示領域の右部の通話ボタンBT7がユーザによってタップされると、
図3-2中央のような表示がなされる。
【0333】
このトークルーム画面では、ユーザA.AとユーザB.Bの安否ステータスがともに「安全」であることに基づき、
図3-2左側のトークルーム画面に重畳して、災害発生時に不要不急の通話を控えさせるための通話遠慮要請情報CRI1が表示されている。
この例では、通話遠慮要請情報CRI1には、災害が発生している場合に不要不急の通話を控えるよう促す(注意喚起する)旨のメッセージ(本例では、「大規模災害発生のため不要不急の通話はお控えください」の文字、キャラクタの画像)とともに、発信をキャンセルするためのキャンセルボタン(本例では、「キャンセル」の文字が含まれたボタン)、および、通話を行うための第2通話ボタン(本例では、「どうしても発信」の文字が含まれたボタン)が表示されている。
【0334】
限定ではなく例として、
図3-2中央のトークルーム画面において、第2通話ボタンがユーザによってタップされた場合における、ユーザA.Aの端末20Aに表示される通話画面の一例を
図3-2右側に示す。
【0335】
本例では、通話ステータス表示領域には、「通話中」の文字が表示されており、その下には、ユーザC.Cのアイコン画像、「C.C」の文字、通話時間として「0:12」の数字、マイクオフボタン、ビデオ通話ボタン、スピーカオンボタン、および、通話終了ボタンが表示されている。
【0336】
<処理>
図3-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、発信元アカウントの端末20Xの制御部21が実行する処理、発信先アカウントの端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0337】
限定ではなく例として、端末20Xの制御部21は、安否確認処理を実行すると(X210)、限定ではなく例として、端末20Xの入出力部23に対する入力(ユーザ操作等)に基づいて、限定ではなく例として、発信先アカウントのアプリケーションIDを含む通話要求情報を通信I/F22によってサーバ10に送信する(X310)。
【0338】
通信I/F14によって発信元アカウントの端末20Xから通話要求情報を受信したと判定する場合、サーバ10の制御部11は、安否ステータス判定処理を実行する(S310)。
【0339】
安否ステータス判定処理において、サーバ10の制御部11は、アカウント管理データベース155Aを参照し、発信元アカウントの安否登録データにおける安否ステータス情報(以下、「発信元ステータス」と称する。)と、発信先アカウントの安否登録データにおける安否ステータス情報(「以下、「発信先ステータス」と称する。)とを取得する。
そして、サーバ10の制御部11は、限定ではなく例として、発信元ステータスが「安全」かつ発信先ステータスが「安全」であるか否かを判定する。
【0340】
発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合(S310:「安全」-「安全」)、サーバ10の制御部11は、通話の発信を控えることを要請するための通話遠慮要請情報を、通信I/F14によって発信元アカウントの端末20Xに送信する(S320)。
【0341】
発信元ステータスが「安全」かつ発信先ステータスが「安全」以外であると判定される場合(S310:「安全」-「安全」以外)、サーバ10の制御部11は、S320のステップをスキップさせる。
【0342】
通信I/F22によってサーバ10から通話遠慮要請情報を受信したと判定される場合(X320:YES)、端末20Xの制御部21は、受信した通話遠慮要請情報を表示部24に表示させる(X330)。
通話遠慮要請情報を受信しないと判定される場合(X320:NO)、端末20Xの制御部21は、X330のステップをスキップさせる。
【0343】
その後、サーバ10の制御部11は、通話処理を開始する(S340)。また、端末20Xおよび端末20Yの制御部21は、通話処理を開始する(X340、Y340)。
通話処理において、端末20Yの制御部21は、限定ではなく例として、通話が着信したことを示す通話着信音を音出力部26から着信音を音出力させる。これにより、ユーザX.Xに着信音を聞かせ、通話が要求されていることを報知させる。また、端末20Yの制御部21は、限定ではなく例として、発信元アカウントの情報(限定ではなく例として、ユーザ名)を含む着信表示を表示部24に表示させる。
なお、発信元アカウントの情報として、発信元ステータスを含む情報を発信先アカウントの端末20の表示部24に表示させるようにしてもよい。
【0344】
限定ではなく例として、端末20Yの入出力部23に対する入力に基づいて、通話が受け入れられると、端末20Xの制御部21と、端末20Yの制御部21とは、限定ではなく例として、サーバ10を介してユーザ間の通話におけるVoIP処理を実行する。なお、通話が受け入れられると、端末20Xの制御部21と、端末20Yの制御部21とは、ピアツーピア通信を行い、通話におけるVoIP処理を実行するようにしてもよい。
【0345】
限定ではなく例として、端末20Xまたは端末20Yの入出力部23に対する入力に基づいて、通話が終了し切断されると、サーバ10の制御部11は、処理を終了させる。また、端末20Xおよび端末20Yの制御部21は、処理を終了させる。
【0346】
なお、通話遠慮要請情報に、通話の発信を取りやめるか否かの選択用表示を含めるようにしてもよい。この場合、発信元アカウントの端末20Xに通話遠慮要請情報が表示され、限定ではなく例として、通話遠慮要請情報に対する入力に基づいて通話の発信を取りやめることが選択された場合、発信元アカウントの端末20Xの制御部21は、通話の発信を取りやめることを示す通話発信解消情報を通信I/F22によってサーバ10に送信する。通信I/F14によって発信元アカウントの端末20Xから通話発信解消情報を受信したと判定される場合、サーバ10の制御部11は、端末20Xと端末20Yとの通話処理を開始しないようにしてもよい。通話遠慮要請情報に対する入力操作に基づいて通話の発信を続けることが選択された場合、サーバ10の制御部11は、端末20Xと端末20Yとの通話処理を開始するようにしてもよい。
【0347】
また、サーバ10の制御部11は、安否ステータス判定処理において、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合(S310:「安全」-「安全」)、通話を接続しないことを示す通話接続拒否情報を通信I/F14によって発信元アカウントの端末20Xに送信するようにしてもよい。端末20Xの制御部21は、通話接続拒否情報を受信すると、表示部24に表示させるようにしてもよい。そして、サーバ10の制御部11は、通話処理を開始しないようにしてもよい。
すなわち、安否ステータス判定処理において、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合には、通話は強制的に解消される。
【0348】
<第3実施例の効果>
本実施例は、発信元アカウントのユーザの端末20が、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とに基づいて、通話に関する処理を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、通話に関連するユーザの安否に関する情報に基づいて、通話に関する処理を適切に行うことができる。
【0349】
また、この場合、通話に関する処理は、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とがともに「安全」であるような場合に、通話を抑制(禁止)する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、発信元アカウントのユーザの安否に関する情報と、発信先アカウントのユーザの安否に関する情報とが設定された条件を満たす場合に、通話を抑制(禁止)することができる。
【0350】
<第3変形例(1)>
上記の実施例では、安否ステータス判定処理に基づいて、通話を抑制させるか否かを判定したが、これに限定されない。限定ではなく例として、安否ステータス判定において、発信元ステータスが「危険」であると判定される場合、サーバ10の制御部11は、通話の接続優先度を上げて通話処理を実行するようにしてもよい。
【0351】
発信元ステータスが「危険」である場合、発信元アカウントのユーザによる通話発信は緊急性が高いと考えられる。そのため、発信元ステータスが「危険」であると判定される場合、通話の接続優先度を上げることにより、緊急性の高い可能性が高い通話を接続し易くすることができる。
【0352】
なお、発信元ステータスが「危険」である場合、通話処理において、限定ではなく例として、発信先アカウントの端末20Yにおける通話着信音をより目立つ態様の着信音として音出力させるようにしてもよい。また、発信元ステータスが「危険」である場合、通話処理において、限定ではなく例として、発信先アカウントの端末20Yにおける通話表示をより目立つ態様の着信表示として表示させるようにしてもよい。
これにより、発信元アカウントのユーザは、助けを求める等の行動を取っている可能性が高い発信元アカウントからの通話着信をより容易に区別することができる。
【0353】
なお、安否ステータス判定において、発信先ステータスが「危険」であると判定される場合、通話の接続優先度を上げるようにしてもよい。
【0354】
<第3変形例(2)>
上記の実施例では、サーバ10において安否ステータス判定処理を実行することとしたが、これに限定されない。限定ではなく例として、発信元アカウントの端末20Xにおいて安否ステータス判定処理を実行するようにしてもよい。
【0355】
限定ではなく例として、発信元アカウントの端末20Xの制御部21は、安否確認処理を実行すると、限定ではなく例として、端末20Xの入出力部23に対する入力(ユーザ操作等)に基づいて、通話発信先アカウントを受け付ける。すると、端末20Xの制御部21は、限定ではなく例として、発信元アカウントのアプリケーションIDと、発信先アカウントのアプリケーションIDとを含む安否情報要求情報を通信I/F22によってサーバ10に送信する。
通信I/F14によって端末20Xから安否情報要求情報を受信すると、サーバ10の制御部11は、アカウント管理データベース155Aを参照し、発信元ステータスと、発信先ステータスとを取得する。そして、発信元ステータスと、発信先ステータスとを含む安否情報を通信I/F14によって端末20Xに送信する。
【0356】
通信I/F22によってサーバ10から安否情報を受信すると、端末20Xの制御部21は、受信した安否情報に基づいて、安否ステータス判定処理を実行する。そして、発信元ステータスが「安全」かつ発信先ステータスが「安全」であると判定される場合、端末20Xの制御部21は、通話遠慮要請情報を表示部24に表示させる。
【0357】
なお、端末20Xが通話開始に先立ち安否情報として発信先ステータスを取得している場合、端末20Xの制御部21は、安否情報要求情報をサーバ10に送信せず、記憶部28に記憶される発信元ステータスと発信先ステータスとに基づいて安否ステータス判定処理を実行するようにしてもよい。
【0358】
<第4実施例>
第4実施例は、安否登録アカウントの端末20において安否確認登録情報が登録されると、その後の安否登録アカウントに対して送信されるメッセージに対して自動的に応答を行う実施例である。
【0359】
第4実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0360】
<表示画面>
図4-1左側は、ユーザA.Aの端末20Aのホーム画面が表示されている。この画面は、
図1-12中央のホーム画面と異なり、安否メッセージ入力領域には、ユーザによって入力された安否メッセージ(本例では、「自転車で移動中です」)が表示されている。また、その下の現在地入力領域には、ユーザによって入力された現在の居場所(本例では「三鷹市」)が表示されている。
【0361】
限定ではなく例として、
図4-1左側の安否登録領域R1において、登録ボタンBT3がユーザA.Aによってタップされると
図4-1中央の安否登録領域R1に表示が遷移する。
【0362】
この場合、安否登録領域R1では、安全ボタンSBT、危険ボタンDBT、安否メッセージ入力領域、現在地入力領域等の表示が消去され、設定された安否情報を確認するための安否情報確認領域が構成されている。安否情報確認領域には、限定ではなく例として、「以下の内容で登録しました」の文字、「安否メッセージ」の文字、ユーザ状態アイコンICAS(ユーザA.A、安全)、「三鷹/自転車で移動中です」の文字が表示されている。
【0363】
また、その下には、自動応答モードに設定するための自動応答設定領域が構成されている。自動応答設定領域には、限定ではなく例として、「自動応答モードに切り替えますか?」の文字と、自動応答モードに設定する(モードを自動応答モードに切り替える)ための「はい」ボタンBT11と、自動応答モードに設定しないための「いいえ」ボタンBT12(本例では、「いいえ」の文字で示されるボタン)とが表示されている。
【0364】
限定ではなく例として、
図4-1中央の安否登録領域R1において、「はい」ボタンBT11がユーザA.Aによってタップされたとする。この場合、
図4-1右側に示すような画面が表示される。
【0365】
図4-1右側は、ユーザA.Aの端末20Aの表示部24に表示されるトークリスト画面の一例を示している。この画面は、
図1-13左側のトークリスト画面とは異なり、自動応答モードの設定を行っている場合に、トークルームリスト項目に、自動応答モードに設定された後に他のユーザからメッセージが送信された(自動応答で返信された)トークルームであることを示す自動応答済み情報が表示されている。
【0366】
本例では、自動応答モードの設定を行っている場合に、自動応答モードに設定された後に他のユーザからメッセージが送信されたトークルームのトークルームリスト項目のうち最も古い時間にメッセージが送信されたトークルーム(ユーザB.Bのトークルーム)に対応したトークルームリスト項目から、最も新しい時間にメッセージが送信されたトークルーム(テニスサークルのグループトークルーム)に対応したトークルームリスト項目に亘って、自動応答済み情報(本例では、「自動応答済み」の文字が示されたテロップ)が重畳表示されている。
【0367】
図4-2左側は、ユーザD.Dの端末20Dのトークルーム画面が表示されている。この画面は、
図1-13右側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザD.DがユーザA.Aを相手としてトークを行うためのトークルームであることを示す文字(本例では「A.A」)が表示されている。
また、その下のユーザ別安否情報表示領域には、限定ではなく例として、ユーザ別安否情報として、第2安全アイコンSIC2が重畳表示されたユーザA.Aのアイコンと、第2安全アイコンSIC2が重畳表示されたユーザD.Dのアイコンとが表示されている。
【0368】
トーク領域には、限定ではなく例として、ユーザA.Aからのコンテンツ(限定ではなく例として、「じゃあ、おやすみ~」のテキストコンテンツ)と、ユーザD.Dによって発信されたコンテンツ(限定ではなく例として、「また明日~」のテキストコンテンツ、「揺れてる~地震?」のテキストコンテンツ、「大丈夫?もう家出た?」のテキストコンテンツ)とが表示されている。
【0369】
また、その下には、OAアカウント(本例では、安否確認応答サービス)を発信元とする自動応答確認情報ARI(限定ではなく例として、「こちらは安否確認サービスです 20XX/08/04 9:39発生の災害においてA.Aさんの無事が確認されています 現在、電池節約等のため自動応答に設定されています」の文字を含む情報)が表示されている。
【0370】
ここで、「未読」に相対する用語として「既読」を定義することができる。
メッセージ(コンテンツ)が既読となる条件(以下、「既読条件」と称する。)としては、限定ではなく例として、以下のいずれかの条件を適用することができる。
(A)メッセージが表示されたこと。
(B)メッセージが表示されてから一定時間(限定ではなく、数秒~10秒程度の時間)が経過したこと。
(C)メッセージが表示された後、表示されたメッセージがタップ(クリック)されたこと。
(D)メッセージが表示された後、そのメッセージに対して返信がされたこと。
(E)メッセージが動画像のメッセージである場合に、その動画像が再生されたこと。
(F)メッセージが動画像のメッセージである場合に、その動画像を再生してから一定時間(限定ではなく、数秒~10秒程度の時間)が経過したこと。
【0371】
この場合、「未読」の状態は、限定ではなく例として、上記の既読条件を満たしていない状態と定義することができる。
「未読」の状態は、ユーザがメッセージ(コンテンツ)を未閲覧の状態であることの一種である。
【0372】
本例では、ユーザD.Dによって発信されたコンテンツのうち、限定ではなく例として「また明日~」のテキストコンテンツが既読状態となっていることに基づいて、このテキストコンテンツの吹き出しの左下方に「既読」の文字が表示されており、「揺れてる~ 地震?」のテキストコンテンツおよび「大丈夫?もう家出た?」のテキストコンテンツが未読状態となっていることに基づいて、これらのテキストコンテンツの吹き出しの左下方に「既読」の文字が表示されていない。
【0373】
限定ではなく例として、ユーザA.Aによって自動応答モードに設定された場合における、ユーザA.Aの端末20Aに表示されるトークルーム画面の一例を
図4-2右側に示す。
【0374】
この画面は、
図4-2左側で示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザA.AがユーザD.Dを相手としてトークを行うためのトークルームであることを示す文字(本例では「D.D」)が表示されている。
【0375】
トーク領域には、限定ではなく例として、ユーザA.Aによって発信されたコンテンツ(限定ではなく例として、「じゃあ、おやすみ~」のテキストコンテンツ、「返信遅くなってごめん B.Bさんが足ケガしたみたいでヘルプしてた;」のテキストコンテンツ)と、ユーザD.Dからのコンテンツ(限定ではなく例として、「また明日~」のテキストコンテンツ、「揺れてる~地震?」のテキストコンテンツ、「大丈夫?もう家出た?」のテキストコンテンツ)とが表示されている。
【0376】
また、ユーザD.Dからのコンテンツのうち、限定ではなく例として、「揺れてる~ 地震?」のテキストコンテンツが送信された後であって、「大丈夫?もう家出た?」のテキストコンテンツが送信されるよりも前のタイミングで、ユーザA.Aによって自動応答モードに設定されたことに基づいて、これらのテキストコンテンツの間に「自動応答モードを設定しました」の文字を含む自動応答設定情報ARSIが表示されている。
【0377】
また、ユーザD.Dからのコンテンツのうち、限定ではなく例として、「大丈夫?もう家出た?」のテキストコンテンツが送信された後のタイミングであって、ユーザA.Aからのコンテンツのうち、限定ではなく例として、「返信遅くなってごめん B.Bさんが足ケガしたみたいでヘルプしてた;」のテキストコンテンツが送信されるよりも前のタイミングで、ユーザA.Aによって自動応答モードが解除されたことに基づいて、これらのテキストコンテンツの間に「自動応答モードを解除しました」の文字が示された自動応答解除情報ARRIが表示されている。
【0378】
<処理>
本実施例において各装置が実行する処理については、限定ではなく例として、
図2-2~
図2-3に従って実行することができる。
【0379】
図4-3は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
ここでは、
・自動応答を行う安否登録アカウント=端末20XのユーザX.X(限定ではなく、端末のユーザの一例)のアカウント
・自動応答を行った安否登録アカウントにメッセージ送信を行うアカウント=端末20YのユーザY.Y(限定ではなく、第1端末のユーザの一例)のアカウント
とする場合の処理を例示する。
【0380】
限定ではなく例として、安否確認処理が実行され、端末20Yにおいて、安否確認登録情報の入力操作を受け付ける(Y2130)と、第1の安否確認登録情報がサーバ10に送信される(Y2140)(タイミング「TM310」)。そして、サーバ10は第1の安否確認登録情報を受信する(S2130:YES)。
サーバ10の制御部11は、第1の安否確認登録情報に基づいて、第1の安否情報を生成し、各端末20に送信する(S2140)(タイミング「TM315」)。
端末20Xは第1の安否情報を受信すると表示処理を実行する(X2160)(タイミング「TM320」)。
【0381】
端末20Xにおいて、安否確認登録情報の入力操作を受け付ける(X2130)と、第2の安否確認登録情報がサーバ10に送信される(X2140)(タイミング「TM325」)。そして、サーバ10は第2の安否確認登録情報を受信する(S2130:YES)。
サーバ10の制御部11は、第2の安否確認登録情報に基づいて、第2の安否情報を生成し、各端末20に送信する(S2140)(タイミング「TM330」)。
端末20Yは第2の安否情報を受信すると表示処理を実行する(Y2160)(タイミング「TM335」)。
【0382】
端末20Xの制御部21は、自動応答を開始するか否かの判定用表示を表示部24に表示させる(タイミング「TM340」)。
限定ではなく例として、端末20Xに表示された判定用表示に対する入力操作に基づいて、自動応答を開始することが選択された場合、端末20Xの制御部21は、自動応答を開始させることを要請するための自動応答開始要請情報を通信I/F22によってサーバ10に送信する(タイミング「TM345」)。
【0383】
通信I/F14によって端末20Xから自動応答開始要請情報を受信したと判定される場合、サーバ10の制御部11は、自動応答開始要請情報を送信した端末20に対するメッセージ自動応答処理を開始する(タイミング「TM350」)。
【0384】
チャット処理において、限定ではなく例として、端末20Yに対する入力操作に基づいて、端末20XのユーザX.Xに対するメッセージが入力されると、端末20Yの制御部21は、限定ではなく例として、入力されたメッセージと、メッセージ送信元である端末20YのアプリケーションIDと、メッセージ送信先である端末20XのアプリケーションIDとを含むメッセージ送信依頼情報を、通信I/F22によってサーバ10に送信する(タイミング「TM355」)。
【0385】
通信I/F14によって端末20Yからメッセージ送信依頼情報を受信すると、サーバ10の制御部11は、メッセージ送信依頼情報に基づいて、メッセージ送信先のアカウントに対する自動応答処理が実行されているか否かを判定する。この例では、端末20Xに対するメッセージ自動応答処理はタイミング「TM350」~「TM375」の間である場合に実行されている。
従って、メッセージ送信依頼情報を受信したタイミングがタイミング「TM350」よりも後であり、かつ、タイミング「TM375」よりも前であると判定される場合、サーバ10の制御部11は、メッセージ自動応答情報を通信I/F14によって端末20Yに送信する(タイミング「TM360」)。
【0386】
通信I/F22によってサーバ10からメッセージ自動応答情報を受信すると、端末20Yの制御部21は、受信したメッセージ自動応答情報を表示部24に表示させる(タイミング「TM365」)。
【0387】
限定ではなく例として、端末20Xに対する入力操作に基づいて、自動応答を終了させることが選択された場合、端末20Xの制御部21は、自動応答を終了させることを要請するための自動応答終了要請情報を通信I/F22によってサーバ10に送信する(タイミング「TM370」)。
【0388】
通信I/F14によって端末20Xから自動応答終了要請情報を受信すると、サーバ10の制御部11は、端末20Xに対するメッセージ自動応答処理を終了する(タイミング「TM375」)。
そして、サーバ10の制御部11は、メッセージ自動応答処理期間内(この場合、タイミング「TM350」~「TM375」の間)に端末20Xに対して送信されたメッセージを含むメッセージ自動応答対応履歴情報を通信I/F14によって端末20Xに送信する(タイミング「TM380」)。
【0389】
通信I/F22によってサーバ10からメッセージ自動応答対応履歴情報を受信すると、端末20Xの制御部21は、受信したメッセージ自動応答対応履歴情報を表示部24に表示させる(タイミング「TM385」)。
【0390】
なお、本タイミングチャートでは、サーバ10はメッセージ自動応答処理期間内に端末20Xに対するメッセージ送信依頼情報を1回受信する例を例示したが、2回以上メッセージ送信依頼情報を受信する場合についても同様に処理を実行することができる。また、サーバ10が、メッセージ自動応答処理期間内に複数の端末20から端末20Xに対するメッセージ送信依頼情報を受信する場合においても同様である。
【0391】
なお、サーバ10の制御部11は、メッセージ自動応答処理期間内(この場合、タイミング「TM350」~「TM375」の間)に再度端末20Yからメッセージ送信依頼情報を受信する場合、メッセージ自動応答情報を端末20Yに送信しないようにしてもよい。
【0392】
また、サーバ10の制御部11は、メッセージ自動応答処理期間内に端末20Xのアカウントが含まれるグループトークルームに対するメッセージ送信依頼情報を受信する場合、メッセージ自動応答情報をグループに属するメンバーの各端末20に送信しないようにしてもよい。
【0393】
また、端末20Xにおいて、タイミング「TM320」やタイミング「TM325」に先んじて、自動応答を開始するか否かの判定用表示を表示部24に表示させ、自動応答開始要請情報をサーバ10に送信するようにしてもよい。
【0394】
<第4実施例の効果>
本実施例は、端末20が、自己の端末20のユーザによる自己の端末20に対する入力に基づいて、自己の端末20のユーザの安否に関する安否情報(または安否確認登録情報)(限定ではなく、端末のユーザの安否に関する第3情報の一例)を通信I/F22によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによる端末に対する入力に基づいて、端末のユーザの安否に関する第3情報を送信して、端末のユーザの安否を他者に知らせることができる。
【0395】
また、この場合、端末20は、上記の安否情報の送信に基づいて、トーク(限定ではなく、チャットの一例)の自動応答を開始するか否かの判定用の情報(限定ではなく、チャットの自動応答に関する情報の一例)を表示部24に表示する。そして、端末20は、この判定用の情報に対する、自己の端末20のユーザによる入力に基づいて、自動応答を開始させることを要請するための自動応答開始要請情報を送信する処理や、自動応答を開始したことに関する情報を表示する処理といった、トーク(チャット)の自動応答に関する処理を制御部21によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、上記の第3情報の送信に基づいてチャットの自動応答に関する情報を表示部に表示して、チャットの自動応答が可能であることを端末のユーザに知らせることができる。また、表示した自動応答に関する情報に対する端末のユーザによる入力に基づいて、チャットの自動応答に関連する処理が適切に行われるようにすることができる。
【0396】
<第4変形例(1)>
上記の実施例では、自動応答を開始する端末20Xに対する入力操作に基づいて、自動応答開始要請情報が送信される例を例示したが、これに限定されない。
限定ではなく例として、端末20Xのバッテリー残量が設定値(限定ではなく例として、「20%」)以下である場合、端末20Xの制御部21は、サーバ10に自動応答開始要請情報を自動的に送信するようにしてもよい。
【0397】
また、端末20Xの制御部21は、限定ではなく例として、サーバ10から災害情報を受信すると、サーバ10に自動応答開始要請情報を自動的に送信するようにしてもよい。
【0398】
また、端末20Xの制御部21は、限定ではなく例として、サーバ10から災害情報を受信すると、限定ではなく例として、位置算出用情報検出部29Bを介して現在位置を取得する。そして、端末20Xの制御部21は、現在位置が災害情報に含まれる災害発生場所と近しい(限定ではなく例として、最大震度の観測地点から10km以内)と判定される場合、サーバ10に自動応答開始要請情報を自動的に送信するようにしてもよい。
【0399】
また、端末20Xの通信状態が不良である場合(限定ではなく例として、電波強度が設定値以下である場合)、端末20Xの制御部21は、サーバ10に自動応答開始要請情報を自動的に送信するようにしてもよい。
【0400】
また、端末20Xで実行されるアプリケーションの使用の状態(状況)(限定ではなく例として、バックグラウンドで使用中)や、位置算出用情報検出部29Bによる位置算出の状態(状況)(限定ではなく例として、いわゆる屋内環境(インドア環境)などの測位用衛星の捕捉が困難な状態、測位用衛星から衛星信号を受信する場合の信号強度が設定値以下である状態等)に基づいて、端末20Xの制御部21は、サーバ10に自動応答開始要請情報を自動的に送信するようにしてもよい。
【0401】
本変形例は、端末20が、自己の端末20のバッテリー残量などの自己の端末20の状態に基づいて、トーク(限定ではなく、チャットの一例)の自動応答を開始するか否かの判定用の情報(限定ではなく、チャットの自動応答に関する情報の一例)を表示部24に表示する。そして、端末20は、この判定用の情報に対する、自己の端末20のユーザによる入力に基づいて、自動応答を開始させることを要請するための自動応答開始要請情報を送信する処理や、自動応答を開始したことに関する情報を表示する処理といった、トーク(チャット)の自動応答に関する処理を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末の状態に基づいてチャットの自動応答に関する情報を表示部に表示して、チャットの自動応答が可能であることを端末のユーザに知らせることができる。また、表示した自動応答に関する情報に対する端末のユーザによる入力に基づいて、チャットの自動応答に関連する処理が適切に行われるようにすることができる。
【0402】
<第4変形例(2)>
上記の実施例では、自動応答を開始する端末20Xに対する入力に基づいて、自動応答を終了させることとしたが、これに限定されない。
限定ではなく例として、サーバ10の制御部11は、メッセージ自動応答処理期間内に端末20Xに対するメッセージ送信依頼情報をN回(「N」は所定の自然数)受信した場合、メッセージ自動応答処理を終了させ、端末20Xにメッセージ自動応答応対履歴情報を送信するようにしてもよい。
【0403】
なお、限定ではなく例として、サーバ10の制御部11は、メッセージ自動応答処理期間内に端末20Xに対するメッセージ送信依頼情報をN回(「N」は所定の自然数)受信した場合、端末20Xにメッセージ自動応答処理を終了させることを示唆するための自動応答終了示唆情報を送信するようにしてもよい。
この場合、端末20Xの制御部21は、自動応答終了示唆情報を受信すると、受信した自動応答終了示唆情報を表示部24に表示させる。そして、限定ではなく例として、端末20Xの制御部21は、表示された自動応答終了示唆情報に対する入力操作に基づいて、自動応答を終了させることが選択された場合、自動応答終了要請情報をサーバ10に送信するようにしてもよい。
【0404】
図4-4左側は、ユーザA.Aの端末20Aの表示部24Aに表示されるトークリスト画面の一例を示している。
この画面は、
図4-1右側のトークリスト画面とは異なり、限定ではなく例として、トークルームリスト項目として、テニスサークルのトークルームリスト項目の上に、ユーザF.Fのトークルームリスト項目が表示されている。また、ユーザF.Fのトークルームリスト項目に関連付けて未読数「4」の数字が表示されている。また、ユーザF.Fが安否情報として「安全」を設定していることに基づいて、ユーザF.Fのトークルームリスト項目に対応したアイコンには、第2安全アイコンSIC2が重畳表示されている。
【0405】
本例では、自動応答モードの設定を行っていることに基づいて、自動応答モードに設定された後に他のユーザからメッセージが送信されたトークルームのトークルームリスト項目のうち最も古い時間にメッセージが送信されたトークルーム(ユーザB.Bのトークルーム)に対応したトークルームリスト項目から、最も新しい時間にメッセージが送信されたトークルーム(ユーザF.Fのトークルーム)に対応したトークルームリスト項目に亘って、自動応答済み情報(本例では、「自動応答済み」の文字が示されたテロップ)が重畳表示されている。
【0406】
この例では、ユーザA.Aが自動応答モードに設定してから設定数(10件)のメッセージを受信したことに基づいて、限定ではなく例として、画面上部に、メッセージングアプリケーション(サーバ10)を発信元とする、ユーザA.Aが自動応答モードに設定してから設定数(限定ではなく例として10件)のメッセージを受信したことを示すテキスト(自動応答中にメッセージが10件届きました 自動応答を続けますか?)を含むプッシュ通知PN5が表示されている。
【0407】
限定ではなく例として、
図4-4左側の表示画面において、プッシュ通知PN5がユーザA.Aによってタップされると、限定ではなく例として、
図4-4右側のような表示がなされる。
【0408】
この表示画面では、
図4-4左側のトークリスト画面に重畳して、安否登録領域R1がせり上がり表示されるように構成されている。
この場合、安否登録領域R1では、設定された安否情報を確認するための安否情報確認領域が構成されている。安否情報確認領域には、限定ではなく例として、「以下の内容で登録しています」の文字、「安否メッセージ」の文字、ユーザ状態アイコンICAS(ユーザA.A、安全)、「三鷹/自転車で移動中です」の文字が表示されている。
また、その下には、自動応答モードを解除するための自動応答解除領域が構成されている。自動応答解除領域には、限定ではなく例として、「自動応答モードを解除しますか?」の文字と、自動応答モードを解除するための「はい」ボタンBT13(本例では、「はい」の文字で示されるボタン)と、自動応答モードを解除しないための「いいえ」ボタンBT14(本例では、「いいえ」の文字で示されるボタン)とが表示されている。
【0409】
<第4変形例(3)>
上記の実施例では、メッセージ自動応答処理をサーバ10において実行することとしたが、これに限定されない。限定ではなく例として、自動応答を開始することが選択された端末20Xにおいてメッセージ自動応答処理を実行するようにしてもよい。
【0410】
図4-5は、本変形例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
限定ではなく例として、端末20Xに表示された判定用表示に対する入力操作に基づいて、自動応答を開始することが選択された場合、端末20Xの制御部21は、メッセージ自動応答処理を開始する(タイミング「TM410」)。
【0411】
通信I/F14によって端末20Yからメッセージ送信依頼情報を受信すると、サーバ10の制御部11は、メッセージ送信依頼情報に基づいて、端末20Xにメッセージ情報を送信する(タイミング「TM420」)。
【0412】
通信I/F22によってサーバ10からメッセージ情報を受信すると、端末20Xの制御部21は、自動応答処理が実行されているか否かを判定する。この例では、端末20Xにおけるメッセージ自動応答処理はタイミング「TM410」~「TM440」の間である場合に実行されている。
従って、メッセージ情報を受信したタイミングがタイミング「TM410」よりも後であり、かつ、タイミング「TM440」よりも前であると判定される場合、端末20Xの制御部21は、メッセージ自動応答情報を通信I/F22によって端末20Yに送信する(タイミング「TM430」)。なお、端末20Xの制御部21は、メッセージ自動応答情報を、サーバ10を介して端末20Yに送信するようにしてもよい。
また、端末20Xの制御部21は、受信したメッセージ情報を表示部24に表示させない。
【0413】
限定ではなく例として、端末20Xに対する入力操作に基づいて、自動応答を終了させることが選択された場合、端末20Xの制御部21は、自動応答処理を終了させる。そして、メッセージ自動応答処理期間中に受信したメッセージ情報に基づいて、メッセージ自動応答応対履歴情報を生成する(タイミング「TM440」)。
【0414】
端末20Xの制御部21は、生成したメッセージ自動応答対応履歴情報を表示部24に表示させる(タイミング「TM450」)。
【0415】
<第5実施例>
第5実施例は、限定ではなく例として、大規模災害等の災害が発生した場合、一の端末20(以下、適宜「端末」と称する。)による安否確認登録(限定ではなく例として、安否確認情報の入力と送信)を、他の端末20(以下、適宜「第1端末」と称する。)のユーザが要求する場合、設定条件に基づいて、端末に対する安否確認登録の要求を行う実施例である。
【0416】
以下では、前述したように、安否確認アプリケーションによる安否確認サービスを提供する事業者のことを「安否確認サービス事業者」と称する。
なお、安否確認サービス事業者は、安否確認アプリケーションを提供する事業者や、サーバ10の事業者と表現することもできる。
また、安否確認サービスを提供する事業者という意味で、安否確認サービスの事業者と表現することもできる。
【0417】
また、以下では、安否確認アプリケーションの名称を、適宜「Safety Confirmation App」と称して図示・説明する。
【0418】
安否確認アプリケーションでは、限定ではなく例として、安否確認対象としてサーバ10に登録しているアカウント同士で、安否確認登録の要求を行うことができるように構成することができる。また、限定ではなく例として、安否確認対象としてサーバ10に登録している一のアカウントが安否確認登録を行うと、他のアカウントは登録された安否確認情報を参照することができる。
【0419】
以下では、安否確認登録を要求されるユーザアカウントを「被安否登録要求アカウント」、被安否登録要求アカウントに対して安否確認登録を要求するユーザアカウントを「安否登録要求アカウント」と称する。なお、一般に、一のユーザアカウントは安否登録要求アカウントと被安否登録要求アカウントとを兼ねることができる。
【0420】
なお、安否確認登録の方法は、安否確認アプリケーションや前述のメッセージングアプリケーションを用いて安否確認情報を入力し登録する方法に限定されない。限定ではなく例として、安否確認アプリケーションやメッセージングアプリケーションを用いずに、電話やFAX等の手段により安否確認情報を伝達する方法や、メッセージングアプリケーションにおけるメッセージとして安否確認情報を伝達する方法を用いるようにしてもよい。
【0421】
第5実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0422】
<表示画面>
図5-1左側は、安否確認アプリケーションのメインメニュー画面であり、画面最上部中央には、安否確認アプリケーションの名称として「Safety Confirmation App」の文字が表示されている。また、画面最上部の右部には、この端末20Yのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名(この例では「ユーザY.Y」)が表示されている。
【0423】
また、その下には、安否確認アプリケーションにおけるアプリ内位置表示領域が構成されており、この例では、メインメニュー画面であることに基づいて、「メインメニュー」の文字が表示されている。
【0424】
アプリ内位置表示領域の下には、災害が発生したことを報知するための災害情報を示す領域である災害情報表示領域が構成されており、この例では、地震が発生したことに基づいて、災害情報が表示されている。また、災害情報表示領域の内部の右下には、ユーザY.Yが安否情報として「安全」を設定していることに基づいて、「自分のステイタス」の文字と、ユーザ状態アイコン(ユーザA.A、安全)とが表示されている。
【0425】
災害情報表示領域の下には、安否確認アプリケーションにおいてユーザY.Yと関連付けられているユーザ(以下、「メンバー」として図示・説明する。)のリストが表示されるメンバーリスト表示領域が構成されている。
【0426】
限定ではなく例として、ある組織で安否確認アプリケーション(安否確認サービス)を利用するような場合、限定ではなく例として、その組織の代表者等のユーザが、サーバ10に対してメンバーを登録するようにすることができる。このようにすることで、その組織に属する人が、安否確認アプリケーションにおいてメンバーとして関連付けられるようにすることができる。
【0427】
なお、組織ではなく個人でメンバーを設定するようにすることも可能である。
この場合は、前述したメッセージングアプリケーションにおいて友だちを登録するのと同様に、限定ではなく例として、電話番号やアプリケーションID等を利用して、個人個人の端末20のユーザがメンバーを登録するようにすることができる。
【0428】
この例では、メンバーリスト表示領域には、この端末20Yのアカウント(この例では「ユーザY.Y」)と関連付けられたメンバーを一覧表示させるためのメンバーリストが表示されるように構成されている。
【0429】
メンバーリストがユーザY.Yによってタップされると、それらのリストが展開され表示される。具体的には、限定ではなく例として、メンバーのアイコンと、ユーザ名とが、メンバーリストの項目として一覧表示される。この例では、限定ではなく例として、メンバーリストがタップされて展開された状態で表示されている。
【0430】
この画面では、メンバーリストの項目として、ユーザX.Xに対応したアイコンおよびユーザ名、ユーザC.Cに対応したアイコンおよびユーザ名、ユーザD.Dに対応したアイコンおよびユーザ名等が一覧表示されている。
また、ユーザX.Xが安否情報を設定していないことに基づいて、ユーザX.Xに対応したアイコンには、第2不明アイコンUIC2(本例では、「不明」の文字が示されているアイコン)が重畳表示されている。ユーザC.Cが安否情報を「安全」に設定していることに基づいて、ユーザC.Cに対応したアイコンには、第2安全アイコンSIC2が重畳表示されている。ユーザD.Dが安否情報を「危険」に設定していることに基づいて、ユーザD.Dに対応したアイコンには、第2危険アイコンDIC2が重畳表示されている。
【0431】
限定ではなく例として、
図5-1左側のメインメニュー画面において、ユーザX.Xに対応したメンバーリストの項目がユーザによってタップされると、限定ではなく例として、
図5-1右側のメンバー画面に表示が遷移する。
【0432】
メンバー画面は、限定ではなく例として、選択されたユーザの安否状況に関する情報を表示する画面とすることができる。そして、このメンバー画面には、限定ではなく例として、各々のメンバーの安否確認アプリケーションにおけるアイコン画像、ユーザ名、安否に関する情報(本例では、「安否状況」の文字、第2不明アイコンUIC2)、そのユーザに安否情報を登録するように促すための安否登録リクエストボタンBT2a等を表示させるようにすることができる。
【0433】
限定ではなく例として、
図5-1右側のメンバー画面において、ユーザX.Xを相手とする安否登録リクエストボタンBT2aがユーザY.Yによってタップされると、限定ではなく例として、
図5-2左側に示す安否登録リクエスト確認情報SRI1がメンバー画面に重畳表示される。
【0434】
安否登録リクエスト確認情報SRI1には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「X.Xに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報SRI1の表示を終了するための「OK」の文字を含むアイコンで示されるOKボタンとが含まれる。
【0435】
OKボタンがタップされ、ユーザY.YによってユーザX.Xを相手とする安否登録リクエストが行われたとする。
この場合、ユーザX.Xの端末20Xには、限定ではなく例として、
図5-2右側に示すような画面が表示される。
【0436】
図5-2右側は、端末20Xの表示部24Xに表示されるメインメニュー画面に重畳して、安否情報を設定するようにリクエストされていることを報知するための安否登録リクエスト確認領域R2がせり上がり表示されている。
【0437】
このメインメニュー画面は、
図5-1左側で示したメインメニュー画面とは異なり、画面最上部の右部には、この端末20Xのユーザの安否確認アプリケーションにおけるアイコン画像およびユーザ名(この例では「ユーザX.X」)が表示されている。
【0438】
また、災害情報表示領域の内部の右下には、ユーザX.Xが安否情報を設定していないことに基づいて、「自分のステイタスを登録」の文字と、前述した安否登録ボタンBT1と同様の安否登録ボタンBT2とが表示されている。
【0439】
また、メンバーリストの項目として、ユーザY.Yに対応したアイコンおよびユーザ名等が一覧表示されている。
また、ユーザY.Yが安否情報を「安全」に設定していることに基づいて、ユーザY.Yに対応したアイコンには、第2安全アイコンSIC2が重畳表示されている。
【0440】
安否登録リクエスト確認領域R2には、安否情報を設定していないユーザX.Xに対してユーザY.Yから安否情報を設定するように促されている旨のメッセージ(本例では、「安否登録リクエスト」の文字と、「Y.Yから安否登録を求められています」の文字、ユーザY.Yのアイコン→ユーザX.Xのアイコン)が表示されている。その下には、安否情報を設定するための回答ボタンBT4aが表示されている。
【0441】
図5-3左側は、ユーザY.Yの端末20Yの表示部24Yにおいて、ユーザY.YによってユーザX.Xを相手とする2回目の安否登録リクエストを行ったことに基づいて、安否確認アプリケーションのメンバー画面に安否登録リクエスト確認領域が表示されている。この表示画面は、
図5-2左側の表示画面と同様であるので説明を省略する。
【0442】
限定ではなく例として、ユーザY.YによってユーザX.Xを相手とする2回目の安否登録リクエスト(安否登録リマインドと捉えてもよい。)が行われたとする。
この場合、ユーザX.Xの端末20Xには、限定ではなく例として、
図5-3右側に示すような画面が表示される。
【0443】
図5-3右側は、端末20Xの表示部24Xにメインメニュー画面が表示されている。このメインメニュー画面は、
図5-3右側の表示画面に対応するが、安否登録リクエストが行われたにも関わらず、メインメニュー画面に重畳して安否登録リクエスト確認領域R2が表示されていない。
【0444】
<処理>
図5-4は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20Xの制御部21が実行する処理、端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0445】
ここでは、表示画面と同様に、
・安否登録要求アカウント=端末20YのユーザY.Y(限定ではなく、第1端末のユーザの一例)のアカウント
・被安否登録要求アカウント=端末20XのユーザX.X(限定ではなく、端末のユーザの一例)のアカウント
とする場合の処理を例示する。
【0446】
端末20Yの制御部21は、限定ではなく例として、災害情報を表示させると(Y120)、被安否登録要求アカウントにおける安否確認登録を要求するための安否登録リクエストを行うか否かの判定用画面を表示部24に表示させる(Y410)。
【0447】
限定ではなく例として、判定用画面に対する入力操作に基づいて、安否登録リクエストを行うことが選択されたと判定される場合(Y410:YES)、端末20Yの制御部21は、限定ではなく例として、被安否登録要求アカウントのアプリケーションIDを含む安否登録リクエスト要求情報を通信I/F22によってサーバ10に送信する(Y420)。
安否登録リクエストを行うことが選択されないと判定される場合(Y410:NO)、端末20Yの制御部21は、Y420のステップをスキップさせる。
【0448】
サーバ10の制御部11は、限定ではなく例として、災害情報を送信すると(S120)、通信I/F14によって被安否登録要求アカウントに対する安否登録リクエスト要求情報を受信したか否かを判定する(S410)。
安否登録リクエスト要求情報を受信したと判定する場合(S410:YES)、サーバ10の制御部11は、被安否登録要求アカウントに関する設定条件が成立しているか否かを判定する(S420)。設定条件については後述する。
【0449】
設定条件が成立していると判定する場合(S420:YES)、サーバ10の制御部11は、安否確認登録を要求するための安否登録リクエスト情報を被安否登録要求アカウントの端末20Xに送信する(S430)。
【0450】
なお、安否登録リクエスト情報に、安否登録要求アカウントに関する情報(限定ではなく例として、アプリケーションID)を含めるようにしてもよいし、そうしなくてもよい。
また、安否登録リクエスト情報は、受信した安否登録リクエスト要求情報をそのまま中継して送信するようにしてもよい。
【0451】
設定条件が成立していない判定する場合(S420:NO)、サーバ10の制御部11は、S430のステップをスキップさせる。
【0452】
安否登録リクエスト要求情報を受信しないと判定する場合(S410:NO)、サーバ10の制御部11は、S420~S430のステップをスキップさせる。
【0453】
端末20Xの制御部21は、限定ではなく例として、災害情報を表示させると(X120)、通信I/F22によって安否登録リクエスト情報を受信したか否かを判定する(X430)。
安否登録リクエスト情報を受信したと判定する場合(X430:YES)、端末20Xの制御部21は、受信した安否登録リクエスト情報を表示部24に表示させる(X440)。
安否登録リクエスト情報を受信していないと判定する場合(X430:NO)、端末20Xの制御部21は、X440のステップをスキップさせる。
【0454】
端末20Xの制御部21と、端末20Yの制御部21と、サーバ10の制御部11とは、処理を終了させるか否かを判定する(X450、Y450、S450)。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間(限定ではなく例として、一週間)が経過した場合や、サーバ10のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。
【0455】
処理を終了させると判定された場合(X450:YES、Y450:YES、S450:YES)、各端末20の制御部21およびサーバ10の制御部11は、処理を終了させる。
【0456】
処理を終了させないと判定された場合(X450:NO、Y450:NO、S450:NO)、端末20Xの制御部21は、限定ではなく例として、X430のステップに処理を戻す。また、端末20Yの制御部21は、限定ではなく例として、Y410のステップに処理を戻す。また、サーバ10の制御部11は、限定ではなく例として、S410のステップに処理を戻す。
【0457】
なお、本フローチャートにおいて、S120・X120・Y120の処理を省略し、サーバ10における災害情報の送信と各端末20における災害情報の表示とは行わないようにしてもよい。
【0458】
また、端末20XにおけるX430~X440のステップは必須ではない。これは、災害により被安否登録要求アカウントの端末20Xがオフライン状態となっている可能性が生じるためである。
【0459】
図5-5は、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。本タイミングチャートを用いて前述の設定条件の一例について説明する。ここでは、設定条件を、「被安否登録要求アカウントに対して1回目の安否登録リクエスト要求が行われた場合」とする。
【0460】
限定ではなく例として、端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われる(Y410:YES)と、第1の安否登録リクエスト要求情報がサーバ10に送信される(Y420)(タイミング「TM510」)。
すると、サーバ10の制御部11は、設定条件が成立していると判定し(420:YES)、第1の安否登録リクエスト情報を端末20Xに送信する(S430)(タイミング「TM520」)。
【0461】
端末20Xの制御部11は、第1の安否登録リクエスト情報を受信すると、第1の安否登録リクエスト情報を表示部24に表示させる(X440)(タイミング「TM530」)。
【0462】
その後、限定ではなく例として、再度端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われる(Y410:YES)と、第2の安否登録リクエスト要求情報がサーバ10に送信される(Y420)(タイミング「TM540」)。
すると、サーバ10の制御部11は、設定条件が成立していないと判定し(S420:NO)、第2の安否登録リクエスト情報を端末20Xに送信しない。
【0463】
限定ではなく例として、再度端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われる(Y410:YES)と、第3の安否登録リクエスト要求情報がサーバ10に送信される(Y420)(タイミング「TM550」)。
すると、サーバ10の制御部11は、設定条件が成立していないと判定し(S420:NO)、第3の安否登録リクエスト情報を端末20Xに送信しない。
【0464】
本設定条件では、安否登録要求アカウントから一の被安否登録要求アカウントに対して複数回の安否登録リクエスト要求が行われる場合、初めの一回目のみ被安否登録要求アカウントの端末20に対して安否登録リクエストが行われる例を示している。このように設定条件を定めることで、非常時に被安否登録要求アカウントのユーザが繰り返し安否登録を求められる煩わしさから解放することができる。
【0465】
なお、上記の設定条件とは異なり、設定条件を「被安否登録要求アカウントに対してN回目(「N」は自然数)の安否登録リクエスト要求が行われた場合」としてもよい。この場合、安否登録要求アカウントから一の被安否登録要求アカウントに対してN回の安否登録リクエスト要求が行われると、サーバ10の制御部11は、初めて安否登録リクエスト要求情報を被安否登録要求アカウントの端末20に送信する。
【0466】
<第5実施例の効果>
本実施例は、サーバ10(限定ではなく、端末と通信するサーバの一例)は、被安否登録要求アカウントのユーザ(限定ではなく、端末のユーザの一例)に対する第1の安否登録リクエスト要求情報(限定ではなく、第1情報の一例)を通信I/F14によって安否登録要求アカウントのユーザの端末20(限定ではなく、第1端末の一例)から受信する。そして、サーバ10は、受信した第1の安否登録リクエスト要求情報と、設定された条件とに基づき、第1の安否登録リクエスト情報(限定ではなく、安否確認に関する第2情報の一例)を通信I/F14によって被安否登録要求アカウントのユーザの端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに対する安否確認の依頼に関する第1情報を第1端末から受信した上で、その第1情報と設定された条件とに基づき、安否確認に関する第2情報を端末に送信して、その端末のユーザの安否を尋ねることができる。
【0467】
<第5変形例(1)>
上記の実施例では、設定条件に基づいて、サーバ10は被安否登録要求アカウントに対して1回のみ安否登録リクエスト情報を送信することとしたが、これに限定されない。限定ではなく例として、サーバ10は、設定条件に基づいて、複数回安否登録リクエスト情報を送信するようにしてもよい。
また、上記の実施例では、安否登録要求アカウントと被安否登録要求アカウントとは異なるアカウントとして説明したが、これに限定されない。
【0468】
以下説明する画面図では、メッセージングアプリケーションにおける実装例を例示する。
【0469】
図5-6は、本実施例の手法をメッセージングアプリケーションに適用した場合のユーザA.Aの端末20Aの表示部24に表示されるメッセージングアプリケーションのホーム画面の一例を示している。
このホーム画面では、
図1-12左側に示したホーム画面とは異なり、友だちリストには、友だちリストの項目として、 ユーザB.Bに対応したアイコンおよびユーザ名、ユーザC.Cに対応したアイコンおよびユーザ名、ユーザD.Dに対応したアイコンおよびユーザ名、ユーザE.Eに対応したアイコンおよびユーザ名、ユーザF.Fに対応したアイコンおよびユーザ名等が一覧表示されている。
【0470】
また、ユーザB.Bが安否情報を設定していないことに基づいて、友だちリストのユーザB.Bに対応したアイコンには、第1不明アイコンUIC1(本例では、「?」の文字が示されているアイコン)が重畳表示されている。ユーザC.Cが安否情報として「危険」を設定していることに基づいて、友だちリストのユーザC.Cに対応したアイコンには、第1危険アイコンDIC1が重畳表示されている。ユーザD.Dが安否情報として「安全」を設定していることに基づいて、ユーザD.Dに対応したアイコンに、第1安全アイコンSIC1が重畳表示されている。ユーザE.Eが安否情報として「安全」を設定していることに基づいて、ユーザE.Eに対応したアイコンに、第1安全アイコンSIC1が重畳表示されている。ユーザF.Fが安否情報として「安全」を設定していることに基づいて、ユーザF.Fに対応したアイコンに、第1安全アイコンSIC1が重畳表示されている。
【0471】
限定ではなく例として、
図5-6左側のホーム画面において、ユーザB.Bに対応した友だちリストの項目がユーザによってタップされると、限定ではなく例として、
図5-6中央のユーザB.Bのプロフィール画面に表示が遷移する。
【0472】
このプロフィール画面は、
図2-5右側に示した例とは異なり、ユーザB.Bのプロフィールを示すアイコンおよびユーザ名の下に、ユーザB.Bの安否に関する情報として、第2不明アイコンUIC2が表示されている。また、そのユーザを相手としたトークを行うためのボタン、そのユーザを相手とした音声通話を行うためのボタン、および、そのユーザを相手としたビデオ通話を行うためのボタンの下には、そのユーザに安否情報を設定するように促すための、前述した安否登録リクエストボタンBT2aと同様の安否登録リクエストボタンBT2bが表示されている。
【0473】
限定ではなく例として、
図5-6中央のプロフィール画面において、ユーザB.Bを相手とする安否登録リクエストボタンBT2bがユーザによってタップされると、限定ではなく例として、
図5-6右側に示すように、安否登録リクエスト確認情報SRI2がプロフィール画面に重畳表示される。
【0474】
安否登録リクエスト確認情報SRI2には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「B.Bに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報SRI2の表示を終了するための「OK」の文字を含むアイコンで示されるOKボタンとが含まれる。
【0475】
図5-7左側は、ユーザB.Bの端末20Bの表示部24に表示されるトークルーム画面の一例を示している。
このトークルーム画面では、
図1-10中央に示したトークルーム画面とは異なり、トークルーム名表示領域には、限定ではなく例として、ユーザB.Bが、公式アカウントとしてメッセージングアプリケーションに登録されている安否確認サービスのOAアカウントを相手としてトークを行うためのトークルームであることを示す文字(本例では「安否確認サービス」)が表示されている。
【0476】
トーク領域には、限定ではなく例として、OAアカウントからのコンテンツとして、「こちらは安否確認応答サービスです 20XX/08/04 9:39 茨城県沖を震源とする地震が発生しました」の文字を含む災害発生コンテンツDCT1が表示されている。
また、その下には、OAアカウントからのコンテンツとして、「安否登録リクエスト 以下の友だちから安否登録を求められています」、ユーザA.Aのアイコン画像とユーザ名、およびそのリクエストに回答するための回答ボタンBT4bを含む安否登録リクエストコンテンツRCT1が表示されている。
【0477】
限定ではなく例として、ユーザA.AによってユーザB.Bを相手とする安否登録リクエストが行われた後、ユーザC.CによってユーザB.Bを相手とする安否登録リクエストが行われたとする。
この場合、ユーザC.Cの端末20Cには、限定ではなく例として、
図5-7中央に示すようなプロフィール画面に安否登録リクエスト確認情報SRI3が重畳表示される。
【0478】
このプロフィール画面では、
図5-6右側に示したプロフィール画面とは異なり、画面最上部の右側には、この端末20Cのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名(この例では「ユーザC.C」)が表示されている。
【0479】
安否登録リクエスト確認情報SRI3には、限定ではなく例として、安否確認アプリケーションのアイコン画像に関連した画像と、「B.Bに安否登録のリクエストを行いました」の文字と、安否登録のリクエストが行われたことを確認し、安否登録リクエスト確認情報SRI3の表示を終了するための「OK」の文字を含むアイコンで示されるOKボタンとが表示されている。
【0480】
限定ではなく例として、ユーザA.AによってユーザB.Bを相手とする安否登録リクエストが行われた後、ユーザC.CによってユーザB.Bを相手とする安否登録リクエストが行われたとする。
この場合、ユーザB.Bの端末20Bには、限定ではなく例として、
図5-7右側に示すようなトークルーム画面が表示される。
【0481】
このトークルーム画面の表示例では、ユーザC.CによってユーザB.Bを相手とする安否登録リクエストが行われたにも関わらず、トーク領域に新たな安否登録リクエストコンテンツが表示されておらず、
図5-7左側と同様の表示画面となっている。
【0482】
図5-8左側は、ユーザB.Bの端末20Bの表示部24に表示されるトークルーム画面の一例を示している。このトークルーム画面は、
図5-7左側の表示画面と同様であるので説明を省略する。
【0483】
限定ではなく例として、ユーザA.AによってユーザB.Bを相手とする安否登録リクエストが行われた後、上記のようにユーザC.CによってユーザB.Bを相手とする安否登録リクエストが行われたとする。さらに、他のユーザ(この例では、ユーザD.D、ユーザF.F)によってユーザB.Bを相手とする安否登録リクエストが行われたとする。
この場合、ユーザB.Bの端末20Bには、限定ではなく例として、
図5-8右側に示すようなトークルーム画面が表示される。
【0484】
このトークルーム画面の表示例では、
図5-7右側に示したトークルーム画面とは異なり、トーク領域には、限定ではなく例として、「9:43」の安否登録リクエストコンテンツRCT1の下に、OAアカウントからのコンテンツとして、「安否登録リクエスト 以下の友だちから安否登録を求められています」、ユーザA.Aのアイコン画像とユーザ名、ユーザC.Cのアイコン画像とユーザ名、ユーザD.Dのアイコン画像とユーザ名、ユーザF.Fのアイコン画像とユーザ名、およびそのリクエストに回答するための回答ボタンBT4bを含む、上記の「9:43」から60分後の「10:43」の新たな安否登録リクエストコンテンツRCT2が表示されている。
【0485】
なお、安否登録リクエストコンテンツ等の情報を、上記のように安否確認サービスのOAアカウントのトークルームの画面に表示させるのではなく、他の画面に表示させてもよい。
限定ではなく例として、
図5-7の表示画面例において、ユーザA.Aからの安否登録リクエストコンテンツを、ユーザA.Aとトークを行うためのトークルーム画面に表示させてもよいし、友だちリスト画面に表示させてもよいし、トークリスト画面に表示させてもよい。
【0486】
図5-9は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20Xの制御部21が実行する処理、端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0487】
ここでは、表示画面とは異なり、
・端末20XのユーザX.X=表示画面における端末20AのユーザA.A
・端末20YのユーザY.Y=表示画面における端末20BのユーザB.B
とする場合の処理を例示する。
なお、他の端末20C等についても端末20Xや端末20Yと同様に処理を実行することが可能である。
【0488】
各装置の制御部は、限定ではなく例として、安否確認処理を実行すると(X210・Y210・S210)、安否登録リクエスト処理を実行する(X480・Y480・S480)。
【0489】
図5-10は、安否登録リクエスト処理の一例を示すフローチャートである。図の見方は、
図5-9と同様である。
端末20Xの制御部21は、限定ではなく例として、端末20YのユーザY.Yに対して安否確認登録を要求するための安否登録リクエストを行うか否かの判定用画面を表示部24に表示させるなどして、端末20Yに対して安否登録リクエストを行うか否かを判定する(Y4410y)。
【0490】
限定ではなく例として、判定用画面に対する入力操作に基づいて、安否登録リクエストを行うことが選択されたと判定される場合(X4410y:YES)、端末20Xの制御部21は、限定ではなく例として、端末20YのアプリケーションIDを含む安否登録リクエスト要求情報を通信I/F22によってサーバ10に送信する(X4420y)。
安否登録リクエストを行うことが選択されないと判定される場合(X4410y:NO)、端末20Xの制御部21は、X4420yのステップをスキップさせる。
【0491】
サーバ10の制御部11は、通信I/F14によって端末20Yのアカウントを被安否登録要求アカウントとする安否登録リクエスト要求情報を受信したか否かを判定する(S4410y)。
端末20Yに対する安否登録リクエスト要求情報を受信したと判定する場合(S4410y:YES)、サーバ10の制御部11は、被安否登録要求アカウントの端末20(この場合、端末20Y)に関する複合設定条件が成立しているか否かを判定する(S4420y)。複合設定条件については後述する。
【0492】
端末20Yに対する複合設定条件が成立していると判定する場合(S4420y:YES)、サーバ10の制御部11は、安否確認登録を要求するための安否登録リクエスト情報を被安否登録要求アカウントの端末20Yに送信する(S4430y)。なお、安否登録リクエスト情報に、安否登録要求アカウントに関する情報(限定ではなく例として、アプリケーションID)を含めるようにしてもよいし、そうしなくてもよい。
【0493】
端末20Yに対する複合設定条件が成立していない判定する場合(S4420y:NO)、サーバ10の制御部11は、S4430yのステップをスキップさせる。
【0494】
何れの端末20からも端末20Yに対する安否登録リクエスト要求情報を受信しないと判定する場合(S4410y:NO)、サーバ10の制御部11は、S4420y~S4430yのステップをスキップさせる。
【0495】
端末20Yの制御部21は、限定ではなく例として、端末20XのユーザX.Xに対する安否登録リクエストを行う場合、安否登録リクエスト要求情報をサーバ10に送信する(Y4410x・Y4420x)。各ステップは、限定ではなく例として、X4410y・X4420yと同様に実行することができる。
【0496】
サーバ10の制御部11は、被安否登録要求アカウントを端末20XのアカウントとしてS4410x~S4430xの各ステップを実行する。各ステップは、限定ではなく例として、S4410y~S4430yと同様に実行することができる。
【0497】
また、端末20Xの制御部21は、他の端末20のアカウントを被安否登録要求アカウントとして、X4410y・X4420yと同様の処理を実行する。サーバ10の制御部11は、被安否登録要求アカウントを変えながらS4410x~S4430xの各ステップと同様の処理を実行する。
【0498】
他の端末20においても同様である。
【0499】
端末20Yの制御部21は、通信I/F22によって安否登録リクエスト情報を受信したか否かを判定する(Y4430)。
安否登録リクエスト情報を受信したと判定する場合(Y4430:YES)、端末20Yの制御部21は、受信した安否登録リクエスト情報を表示部24に表示させる(Y4440)。
安否登録リクエスト情報を受信していないと判定する場合(Y4430:NO)、端末20Yの制御部21は、Y4440のステップをスキップさせる。
【0500】
他の端末20においても同様である。
【0501】
図5-9に戻り、端末20Xの制御部21と、端末20Yの制御部21と、サーバ10の制御部11とは、処理を終了させるか否かを判定する(X490、Y490、S490)。ここで、処理を終了させる判定条件としては、限定ではなく例として、災害発生日時から特定期間(限定ではなく例として、一週間)が経過した場合や、サーバ10のユーザ入力に基づいて、安否確認サービスが停止されることが選択された場合等が挙げられる。
【0502】
処理を終了させると判定された場合(X490:YES、Y490:YES、S490:YES)、各端末20の制御部21およびサーバ10の制御部11は、処理を終了させる。
【0503】
処理を終了させないと判定された場合(X490:NO、Y490:NO、S490:NO)、各端末20の制御部21およびサーバ10の制御部11は、限定ではなく例として、再度安否確認処理を実行する(X210、Y210、S210)。
【0504】
他の端末20においても同様である。
【0505】
なお、
図5-9において、サーバ10における災害情報の各端末20への送信と、各端末20における災害情報の表示処理とは実行されなくてもよい。
また、任意のタイミングにおいてチャット処理が実行されるようにしてもよい。
【0506】
ここで、限定ではなく例として、各端末20に対する複合設定条件を以下の2つの条件の組み合わせとして定義する。
・「初期送信設定条件」:被安否登録要求アカウントの端末20に対して安否登録リクエスト情報を始めて送信する条件。
・「再送信設定条件」:被安否登録要求アカウントの端末20に対して安否登録リクエスト情報を送信後、再度安否登録リクエスト要求情報を送信する条件。
【0507】
初期送信設定条件としては、限定ではなく例として、以下の例が挙げられる。
(X1).サーバ10が一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報を初めて受信した場合。
(X2).サーバ10が一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報をL回(「L」は自然数)受信した場合。
(X3).サーバ10が一の安否登録要求アカウントの端末20から一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報を初めて受信した場合。
(X4).サーバ10が一の安否登録要求アカウントの端末20から一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報をM回(「M」は自然数)受信した場合。
(X5).サーバ10が一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報を初めて受信した後、第1設定時刻(限定ではなく例として、「毎時0分0秒」)となった場合。
(X6).サーバ10が一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報を初めて受信した後、第1設定時間(限定ではなく例として、「5分間」)が経過した場合。
(X7).サーバ10が一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報を初めて受信した後、再度災害情報を送信する場合。
(X8).上記の(X1)~(X7)の任意の組み合わせ。
【0508】
また、再送信設定条件としては、限定ではなく例として、以下の例が挙げられる。
(Y1).サーバ10が一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報をP回(「P」は自然数)受信した場合。なお、P回には、初期送信設定条件成立までにサーバ10が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
(Y2).サーバ10が初期送信設定条件を満たした一の安否登録要求アカウントの端末20とは異なる安否登録要求アカウントの端末20から、一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報を初めて受信した場合。
(Y3).サーバ10が初期送信設定条件を満たした一の安否登録要求アカウントの端末20とは異なる安否登録要求アカウントの端末20から、一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報をQ回(「Q」は自然数)受信した場合。なお、Q回には、初期送信設定条件成立までにサーバ10が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
(Y4).サーバ10が初期送信設定条件を満たした一の安否登録要求アカウントの端末20から、一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報をR回(「R」は自然数)受信した場合。なお、R回には、初期送信設定条件成立までにサーバ10が安否登録リクエスト要求情報を受信した回数を含めるようにしてもよいし、そうしなくてもよい。
(Y5).サーバ10が一の被安否登録要求アカウントの端末20に安否登録リクエスト情報を送信した後、第2設定時刻(限定ではなく例として、「日付が変わる0時0分0秒」や「災害発生時刻+T時間後」(「T」は自然数))となった場合。
(Y6).サーバ10が一の被安否登録要求アカウントの端末20に安否登録リクエスト情報を送信した後、第2設定時間(限定ではなく例として、「60分間」)が経過した場合。
(Y7).サーバ10が一の被安否登録要求アカウントの端末20に安否登録リクエスト情報を送信した後、再度災害情報を送信する場合。
(Y8).上記の(Y1)~(Y7)の任意の組み合わせ。
【0509】
限定ではなく例として、
図5-6~
図5-8の例は、複合設定条件を(X1)+(Y6)とした場合の一例である。
【0510】
図5-11は、限定ではなく例として、複合設定条件を(X1)+(Y1)とした場合、各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
【0511】
限定ではなく例として、端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われると、第1の安否登録リクエスト要求情報がサーバ10に送信される(タイミング「TM610」)。
すると、サーバ10の制御部11は、初期送信設定条件(X1)が成立していると判定し、第1の安否登録リクエスト情報を端末20Xに送信する(タイミング「TM620」)。
端末20Xの制御部21は、第1の安否登録リクエスト情報を受信すると、第1の安否登録リクエスト情報を表示部24に表示させる(タイミング「TM630」)。
【0512】
その後、限定ではなく例として、再度端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われると、第2の安否登録リクエスト要求情報がサーバ10に送信される(タイミング「TM640」)。
すると、サーバ10の制御部11は、再送信設定条件(Y1)が成立していないと判定し、第2の安否登録リクエスト情報を端末20Xに送信しない(タイミング「TM650」)。
【0513】
端末20Xに対する安否登録リクエスト要求操作が各端末20において実行され、第P+1の安否登録リクエスト要求情報をサーバ10が受信する(タイミング「TM660」)。すると、サーバ10の制御部11は、再送信設定条件(Y1)が成立したと判定し、第2の安否登録リクエスト情報を端末20Xに送信する(タイミング「TM670」)。
端末20Xの制御部21は、第2の安否登録リクエスト情報を受信すると、第2の安否登録リクエスト情報を表示部24に表示させる(タイミング「TM680」)。
【0514】
初期送信設定条件と再送信設定条件とは、限定ではなく例として、以下の考え方に従って設定することができる。
【0515】
・第1の考え方
一の被安否登録要求アカウントにおいて初期送信設定条件を満たし、一度安否登録リクエスト情報を送信した後は基本的には再送しない。これにより、通信帯域が切迫し、端末20の動作時間にも限りが生じる可能性が高い非常時において、被安否登録要求アカウントの端末20に対して、繰り返し同じ種類の情報を送信することを防ぐことができる。しかしながら、安否確認登録を行うことを被安否登録要求アカウントのユーザが忘れている可能性があるため、再送信設定条件を満たす場合、リマインダーとして再度安否登録リクエスト情報を送信する。
【0516】
・第2の考え方
一の被安否登録要求アカウントにおいて初期送信設定条件を満たす場合は即座に安否登録リクエスト情報を送信する。その後、再送信設定条件を満たす場合においても、即座に安否登録リクエスト情報を送信する。これにより、サーバ10が被安否登録要求アカウントの端末20に対して安否登録リクエスト情報を送信する頻度を制御することができ、端末20において頻繁に安否登録リクエスト情報が表示される煩わしさからユーザを解放することができる。
【0517】
なお、複合設定条件を初期送信設定条件のみの条件としてもよい。この場合、安否登録リクエスト情報の再送は実行されない。
【0518】
また、限定ではなく例として、再送信設定条件に、再送信回数に関する条件を付加するようにしてもよい。再送信回数に関する条件として、限定ではなく例として、安否登録リクエスト情報を被安否登録要求アカウントの端末20に再送信する上限回数を定めるようにしてもよい。
【0519】
本変形例は、前述した設定条件は、初期送信設定条件(限定ではなく、端末のユーザに対する第1情報をサーバが最初に受信した場合、第2情報を端末に送信する条件の一例)に基づいて送信し、再送信設定条件(限定ではなく、端末のユーザに対する第1情報を最初に受信した後、第2情報を端末に送信する第1設定条件の一例)に基づいて送信する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第1情報と、端末のユーザに対する第1情報をサーバが最初に受信した場合、第2情報を端末に送信し、端末のユーザに対する第1情報を最初に受信した後、第1設定条件に基づいて第2情報を端末に送信する条件とに基づき、安否確認に関する第2情報を端末に送信して、その端末のユーザの安否を尋ねることができる
【0520】
また、この場合、再送信設定条件は、設定された時刻、または設定された時間(時間間隔)に基づいて安否登録リクエスト情報(限定ではなく、第2情報の一例)を被安否登録要求アカウントのユーザの端末20に送信する条件を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第1情報と、設定された時刻、または設定された時間に基づいて第2情報を端末に送信する条件とに基づき、安否確認に関する第2情報を端末に送信して、その端末のユーザの安否を尋ねることができる。
【0521】
また、この場合、再送信設定条件は、最初にサーバ10が安否登録リクエスト要求情報(限定ではなく、第1情報の一例)を受信した後、サーバ10が受信した安否登録リクエスト要求情報(限定ではなく、第1情報の一例)の数に基づいて安否登録リクエスト情報(限定ではなく、第2情報の一例)を被安否登録要求アカウントのユーザの端末20に送信する条件を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第1情報と、最初に第1情報を受信した後、サーバが受信した第1情報の数に基づいて第2情報を端末に送信する条件とに基づき、安否確認に関する第2情報を端末に送信して、その端末のユーザの安否を尋ねることができる。
【0522】
また、この場合、再送信設定条件は、再度災害が発生したことを示す情報等の情報(限定ではなく、災害に関する情報の一例)に基づいて安否登録リクエスト情報(限定ではなく、第2情報の一例)を被安否登録要求アカウントのユーザの端末20に送信する条件を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第1情報と、災害に関する情報に基づいて第2情報を端末に送信する条件とに基づき、安否確認に関する第2情報を端末に送信して、その端末のユーザの安否を尋ねることができる。
【0523】
また、この場合、安否登録リクエスト情報(限定ではなく、第2情報の一例)は、被安否登録要求アカウントのユーザ(限定ではなく、端末のユーザの一例)を含むトークルーム(限定ではなく、チャットルームの一例)に表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、安否確認に関する第2情報が、端末のユーザを含むチャットルームに表示されるようにすることで、分かり易い形で、端末のユーザに安否を尋ねることができる。
【0524】
<第5変形例(2)>
上記の変形例では、サーバ10は、複合設定条件が成立する場合、安否登録リクエスト情報を被安否登録要求アカウントの端末20に送信することとしたが、これに限定されない。限定ではなく例として、サーバ10は、後述する送信停止設定条件を満たす場合、初期送信設定条件や再送信設定条件が成立しても安否登録リクエスト情報を被安否登録要求アカウントの端末20に送信しないようにしてもよい。
【0525】
図5-12左側は、ユーザB.Bの端末20Bの表示部24に表示されるトークルーム画面の一例を示している。このトークルーム画面は、
図5-7左側の表示画面と同様であるので説明を省略する。
【0526】
限定ではなく例として、
図5-12左側のトークルーム画面において、安否登録リクエストコンテンツRCT1に含まれる回答ボタンBT4bがユーザによってタップされると、限定ではなく例として、
図5-12中央に示すホーム画面に表示が遷移する。
【0527】
このホーム画面では、
図4-1左側に示すホーム画面とは異なり、画面最上部の右部には、この端末20Bのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名(この例では「ユーザB.B」)が表示されている。
【0528】
限定ではなく例として、
図5-12中央の安否登録領域R1において、危険ボタンDBTがユーザB.Bによってタップされ、安否メッセージの定型文として「怪我をした」のテキストがユーザB.Bによって選択された後、登録ボタンBT3がユーザB.Bによってタップされた場合における、ユーザA.Aの端末20Aに表示されるトークリスト画面の一例を
図5-12右側に示す。このトークリスト画面は、
図1-19右側のトークリスト画面と同様であるので説明を省略する。
【0529】
限定ではなく例として、
図5-12右側のトークリスト画面において、ユーザB.Bのトークルームリスト項目のうちアイコン画像がユーザによってタップされると、限定ではなく例として、
図5-13左側のユーザB.Bに対応したプロフィール画面に表示が遷移する。
【0530】
このプロフィール画面では、
図5-6中央に示した例とは異なり、画面最上部の右部に、この端末20Bのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名(この例では「ユーザA.A」)が表示されている。また、ユーザB.Bのプロフィールを示すアイコンおよびユーザ名の下には、ユーザB.Bの安否に関する情報として、第2危険アイコンDIC2が表示されている。
【0531】
限定ではなく例として、
図5-13左側のプロフィール画面において、ユーザB.Bを相手とする安否登録リクエストボタンBT2bがユーザによってタップされると、限定ではなく例として、
図5-13中央に示す安否登録リクエスト確認情報SRI4がプロフィール画面に重畳表示される。
この安否登録リクエスト確認情報SRI4は、
図5-6右側の安否登録リクエスト確認情報SRI2と同様であるので説明を省略する。
【0532】
限定ではなく例として、ユーザB.Bが安否登録リクエストに回答した後、ユーザA.AによってユーザB.Bを相手とする安否登録リクエストが行われたとする。
この場合、ユーザB.Bの端末20Bには、限定ではなく例として、
図5-13右側に示すようなトークルーム画面が表示される。
【0533】
このトークルーム画面では、ユーザA.AによってユーザB.Bを相手とする安否登録リクエストが行われたにも関わらず、トーク領域に新たな安否登録リクエストに対応したOAアカウントからの安否登録リクエストコンテンツが表示されておらず、
図5-12左側と同様の表示画面となっている。
【0534】
本変形例において、送信停止設定条件としては、限定ではなく例として、以下の例が挙げられる。
(Z1).サーバ10が一の被安否登録要求アカウントの端末20から安否確認登録情報を受信した場合。
(Z2).サーバ10が一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報をU回(「U」は自然数)受信した場合。
(Z3).サーバ10が特定の安否登録要求アカウントの端末20から、一の被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報をV回(「V」は自然数)受信した場合。
(Z4).第3設定時刻(限定ではなく例として、「災害発生時刻+72時間後」となった場合)となった場合。
(Z5).サーバ10が一の被安否登録要求アカウントの端末20に安否登録リクエスト情報を送信した後、第3設定時間(限定ではなく例として、「36時間」)が経過した場合。
(Z6).サーバ10が再度災害情報を送信する場合。
(Z7).上記の(Z1)~(Z6)の任意の組み合わせ。
【0535】
限定ではなく例として、
図5-12・
図5-13の例は、送信停止設定条件を(Z1)とした場合の一例である。
【0536】
図5-14は、限定ではなく例として、複合設定条件を(X1)+任意の再送信設定条件+(Z1)とした場合、各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
【0537】
限定ではなく例として、端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われると、第1の安否登録リクエスト要求情報がサーバ10に送信される(タイミング「TM710」)。
すると、サーバ10の制御部11は、初期送信設定条件(X1)が成立していると判定し、第1の安否登録リクエスト情報を端末20Xに送信する(タイミング「TM720」)。
端末20Xの制御部21は、第1の安否登録リクエスト情報を受信すると、第1の安否登録リクエスト情報を表示部24に表示させる(タイミング「TM730」)。
【0538】
その後、限定ではなく例として、安否確認処理が実行され、端末20Xにおいて、安否確認登録情報の入力操作を受け付けると、第1の安否確認登録情報がサーバ10に送信される(タイミング「TM740」)。そして、サーバ10は第1の安否確認登録情報を受信する。
サーバ10の制御部11は、第1の安否確認登録情報に基づいて、第1の安否情報を生成し、各端末20に送信する(タイミング「TM750」)。
端末20Yは第1の安否情報を受信すると表示処理を実行する(タイミング「TM760」)。
【0539】
その後、限定ではなく例として、端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われると、第2の安否登録リクエスト要求情報がサーバ10に送信される(タイミング「TM770」)。
すると、サーバ10の制御部11は、送信停止設定条件(Z1)が成立していると判定し、第2の安否登録リクエスト情報を端末20Xに送信しない(タイミング「TM780」)。
【0540】
なお、端末20Yの制御部21は、端末20Xのアカウントに関する安否情報を受信した場合、それ以降に端末20Xのアカウントに対する安否登録リクエスト要求操作を受け付けないようにしてもよい。
【0541】
本変形例は、サーバ10が、安否登録リクエスト情報(限定ではなく、第2情報の一例)の送信に基づき、安否確認登録情報(限定ではなく、端末のユーザの安否に関する情報を含む第3情報の一例)を通信I/F14によって受信する。そして、サーバ10は、この安否確認登録情報の受信に基づき、この安否確認登録情報の受信の後に、被安否登録要求アカウントに対する安否登録リクエスト要求情報(限定ではなく、第3情報の一例)を受信した場合、その安否登録リクエスト要求情報に基づく安否登録リクエスト情報の送信を行わない制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第2情報の送信に基づき、端末のユーザの安否に関する情報を含む第3情報を端末から受信した上で、この第3情報の受信に基づいて、第3情報の受信の後に端末のユーザに対する第1情報を受信した場合、第1情報に基づく第2情報の送信を行わないようにすることで、端末のユーザの安否を一旦確認した場合は再度確認せずに済み、端末のユーザが煩わしさを感じないようにすることができる。また、不要な通信をせずに済み、通信量を削減することができる
【0542】
<第5変形例(3)>
上記の実施例では、サーバ10において設定条件(複合設定条件)の判定を実行することとしたが、これに限定されない。限定ではなく例として、設定条件(複合設定条件)の判定を被安否登録要求アカウントの端末20で判定するようにしてもよい。
【0543】
この場合、サーバ10の制御部11は、安否登録要求アカウントの端末20Yから被安否登録要求アカウントの端末20Xに対する安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を端末20Xに送信する。
端末20Xの制御部21は、安否登録リクエスト情報を受信すると、設定条件(複合設定条件)が成立するか否かを判定する。そして、端末20Xの制御部21は、設定条件(複合設定条件)が成立すると判定する場合、受信した安否登録リクエスト情報を表示部24に表示させる。
設定条件(複合設定条件)が成立しないと判定する場合、端末20Xの制御部21は、受信した安否登録リクエスト情報を表示部24に表示させない。
【0544】
<第5変形例(4)>
上記の実施例では、サーバ10において設定条件(複合設定条件)の判定を実行することとしたが、これに限定されない。限定ではなく例として、設定条件(複合設定条件)の判定を安否登録要求アカウントの端末20で判定するようにしてもよい。
【0545】
この場合、安否登録要求アカウントの端末20Yの制御部21は、被安否登録要求アカウントの端末20Xに対する安否登録リクエスト要求操作が行われると、設定条件(複合設定条件)が成立するか否かを判定する。そして、端末20Yの制御部21は、設定条件(複合設定条件)が成立すると判定する場合、サーバ10に安否登録リクエスト情報を送信する。
サーバ10の制御部11は、端末20Yから端末20Xに対する安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を端末20Xに送信する。
端末20Xの制御部21は、安否登録リクエスト情報を受信すると、表示部24に表示させる。
【0546】
設定条件(複合設定条件)が成立しないと判定する場合、端末20Yの制御部21は、サーバ10に安否登録リクエスト情報を送信しない。
【0547】
なお、安否登録要求アカウントの端末20において設定条件(複合設定条件)を判定させる場合、他の端末20が被安否登録要求アカウントの端末20に対する安否登録リクエスト要求情報を送信したか否かは判定できない。そのため、この場合、設定条件(複合設定条件)は自端末における安否登録リクエスト要求操作の回数や、時刻や自端末における安否登録リクエスト要求操作を受け付けてからの時間、災害情報を再度受信したか等に限られる。
【0548】
<第6実施例>
第6実施例は、被安否登録要求アカウントの端末20において、被安否登録要求アカウントに対して安否登録リクエストを要求した安否登録要求アカウントを確認可能とする実施例である。
【0549】
第6実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0550】
<表示画面>
図6-1は、端末20Bの表示部24に表示されるメッセージングアプリケーションの画面の一例を示す図である。
図6-1左側では、トーク領域の「安否登録リクエスト」と示された安否登録リクエストコンテンツRCT6内に、回答ボタンBT4bの他、自分(ユーザB.B)に対して安否登録リクエストを要求した安否登録要求アカウント(友だち)を確認するための「友だち確認」ボタンBT6が設けられている。この「友だち確認」ボタンBT6がタップされると、
図6-1右側のような表示がなされる。
【0551】
具体的には、画面下部からせり上がるように、自分(ユーザB.B)に対して安否登録リクエストを要求した安否登録要求アカウントに関する情報を含む安否登録リクエスト要求ユーザ一覧領域SRRが表示されている。この例では、「以下の友だちから安否登録を求められています」の文字とともに、この例では、ユーザA.A、ユーザC.C、ユーザD.D、ユーザF.Fの4名のユーザについて、それぞれアイコンおよびユーザ名が表示されている。また、各々のユーザのアイコンには、そのユーザによって登録された安否ステータス情報に基づくアイコンが重畳して表示されている。
【0552】
<処理>
図6-2は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
この図では、左側から順に、端末20Xの制御部21が実行する処理、端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0553】
ここでは、表示画面とは異なり、
・安否登録要求アカウント=端末20YのユーザY.Yのアカウント=表示画面における端末20Aおよび端末20C~端末20Fのユーザ
・被安否登録要求アカウント=端末20XのユーザX.Xのアカウント=表示画面における端末20BのユーザB.B
とする場合の処理を例示する。
【0554】
また、複合設定条件を上記の(X1)+(Y1)とした場合について例示する。
【0555】
限定ではなく例として、端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われると、第1の安否登録リクエスト要求情報がサーバ10に送信される(タイミング「TM810」)。
すると、サーバ10の制御部11は、初期送信設定条件(X1)が成立していると判定し、第1の安否登録リクエスト情報を端末20Xに送信する(タイミング「TM820」)。
端末20Xの制御部21は、第1の安否登録リクエスト情報を受信すると、第1の安否登録リクエスト情報を表示部24に表示させる(タイミング「TM830」)。
【0556】
その後、限定ではなく例として、他の端末20において端末20Xに対する安否登録リクエスト要求操作が行われると、第2の安否登録リクエスト要求情報がサーバ10に送信される。
すると、サーバ10の制御部11は、再送信設定条件(Y1)が成立していないと判定し、第2の安否登録リクエスト情報を端末20Xに送信しない(タイミング「TM840」)。
【0557】
他の端末20からサーバ10に送信された安否登録リクエスト要求情報についても同様である。
【0558】
そして、限定ではなく例として、端末20Xの制御部21は、安否登録リクエスト要求ユーザ情報要求操作を実行する(タイミング「TM850」)。安否登録リクエスト要求ユーザ情報要求操作において、端末20Xの制御部21は、限定ではなく例として、第1の安否登録リクエスト情報に対するユーザ操作に基づいて、端末20Xに対する安否登録リクエスト要求情報を送信した安否登録要求アカウントを確認することが選択されたか否かを判定する。そして、安否登録要求アカウントを確認することが選択されたと判定した場合、端末20Xの制御部21は、安否登録リクエスト要求ユーザ情報要求情報を通信I/F22によってサーバ10に送信する。
【0559】
通信I/F14によって端末20Xから安否登録リクエスト要求ユーザ情報要求情報を受信すると(タイミング「TM860」)、サーバ10の制御部11は、安否登録リクエスト要求ユーザ一覧情報を通信I/F14によって端末20Xに送信する(タイミング「TM870」)。
ここで、安否登録リクエスト要求ユーザ一覧情報には、限定ではなく例として、タイミング「TM860」以前に受信した端末20Xに対する安否登録リクエスト要求情報における、安否登録要求アカウントに関する情報(限定ではなく例として、アプリケーションIDやユーザ名等を含む)の一覧が含まれる。
【0560】
通信I/F22によってサーバ10から安否登録リクエスト要求ユーザ一覧情報を受信すると、端末20Xの制御部21は、受信した安否登録リクエスト要求ユーザ一覧情報を表示部24に表示させる(タイミング「TM880」)。
【0561】
<第6実施例の効果>
本実施例は、被安否登録要求アカウントの端末20において、安否登録リクエスト情報(限定ではなく、第2情報の一例)の受信に基づき、その安否登録リクエスト情報の表示や、その被安否登録要求アカウントに対して安否登録リクエストを要求した安否登録要求アカウントに関する表示(限定ではなく、安否確認に関する第1表示の一例)が表示部24に表示される。そして、サーバ10は、被安否登録要求アカウントの端末20において、その表示に対するその被安否登録要求アカウントのユーザによる入力に基づいて、安否登録リクエスト要求情報(限定ではなく、第1情報の一例)を送信した安否登録要求アカウントの情報(限定ではなく、第1情報を送信したユーザの情報の一例)を通信I/F14によって被安否登録要求アカウントの端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第2情報の受信に基づき、安否確認に関する第1表示が表示部に表示され、その第1表示に対する、端末のユーザによる入力に基づいて、第1情報を送信したユーザの情報を端末に送信することで、第1情報を送信したユーザの情報を端末のユーザに知らせることができる。
【0562】
また、この場合、サーバ10は、一の安否登録要求アカウントの端末20(限定ではなく、第1端末の一例)から送信された被安否登録要求アカウントに対する安否登録リクエスト要求情報の受信に基づき、安否登録リクエスト情報(限定ではなく、第2情報の一例)を通信I/F14によって被安否登録要求アカウントの端末20に送信する。また、サーバ10は、被安否登録要求アカウントに対する安否登録リクエスト要求情報を一の安否登録要求アカウントの端末20から受信した後、被安否登録要求アカウントに対する安否登録リクエスト要求情報を他の安否登録要求アカウントの端末20(限定ではなく、第2端末の一例)から通信I/F14によって受信する。また、サーバ10は、設定された条件を満たさない場合、他の安否登録要求アカウントの端末20(第2端末)から受信した安否登録リクエスト要求情報に基づく安否登録リクエスト情報を被安否登録要求アカウントの端末20に送信しない制御を制御部11によって行う。この場合、サーバ10は、上記の表示に対する被安否登録要求アカウントのユーザによる入力に基づいて、安否登録リクエスト要求情報(限定ではなく、第1情報の一例)を送信した、一の安否登録要求アカウントの情報(限定ではなく、第1端末のユーザの情報の一例)と、他の安否登録要求アカウントの情報(限定ではなく、第2端末のユーザの情報の一例)とを通信I/F14によって被安否登録要求アカウントの端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに対する第1情報を第1端末から受信した後、端末のユーザに対する第1情報を第2端末から受信し、設定された条件を満たさない場合、第2端末から受信した第1情報に基づく第2情報を端末に送信しないようにすることで、端末のユーザが煩わしさを感じないようにすることができる。また、端末で、第2情報の受信に基づき、安否確認に関する第1表示が表示部に表示され、その第1表示に対する、端末のユーザによる入力に基づいて、第1情報を送信した、第1端末のユーザの情報と、第2端末のユーザの情報とを含むユーザの情報を端末に送信することで、第1情報を送信した、第1端末のユーザの情報と、第2端末のユーザの情報とを端末のユーザに知らせることができる。
【0563】
<第6変形例(1)>
上記の実施例では、被安否登録要求アカウントの端末20Xにおいて安否登録リクエスト要求ユーザ情報要求操作が実行されると、サーバ10から端末20Xに安否登録リクエスト要求ユーザ情報が送信されることとしたが、これに限定されない。
【0564】
図6-3は、本変形例における表示画面の一例を示す図である。
図6-3左側、中央は、それぞれ
図5-7左側、中央と同様である。
【0565】
本変形例では、後述するタイミングで、安否登録リクエスト要求ユーザ一覧情報が、サーバ10から端末20Bに送信される。その結果、端末20Bの表示部24には、
図6-3右側のような表示がなされる。この画面は、
図6-3左側に対応する画面であるが、OAからのコンテンツとして、ユーザB.BがユーザA.AとユーザC.Cとから安否登録を要求されていることを示す安否登録リクエストコンテンツRCT7が示されている。
【0566】
サーバ10の制御部11は、任意のタイミングにおいて、安否登録リクエスト要求ユーザ一覧情報送信条件が成立すると判定した場合、端末20Xに安否登録リクエスト要求ユーザ一覧情報を送信するようにすることができる。
【0567】
ここで、安否登録リクエスト要求ユーザ一覧情報送信条件としては、限定ではなく例として、以下の例が挙げられる。
・任意の一の端末20から安否登録リクエスト要求情報を最後に受信した後、設定期間(限定ではなく例として、「30分」)が経過した場合。
・任意の一の端末20から安否登録リクエスト要求情報を最後に受信した後、設定時刻(限定ではなく例として、「正午」)となった場合。
・任意の一の端末20から安否登録リクエスト要求情報を設定回数以上、または設定回数より多く受信した場合。
・各端末20から安否登録リクエスト要求情報を最後に受信した後、設定期間(限定ではなく例として、「30分」)が経過した場合。
・各端末20から安否登録リクエスト要求情報を最後に受信した後、設定時刻(限定ではなく例として、「正午」)となった場合。
・各端末20から安否登録リクエスト要求情報を設定回数以上、または設定回数より多く受信した場合。
・端末20Xから安否確認登録情報を受信した場合。
・端末20Xに安否登録リクエスト情報を送信する場合。
【0568】
なお、本変形例における処理は以下のようにしてもよい。
限定ではなく例として、サーバ10の制御部11は、安否登録要求アカウントの端末20から安否登録リクエスト要求情報を受信すると、安否登録リクエスト情報を送信するか否かの複合設定条件に関わらず、端末20Xに受信した安否登録要求アカウントに関する情報を送信する。以下では、限定ではなく例として、個別の安否登録リクエスト要求情報に対応する安否登録要求アカウントに関する情報を、「安否登録リクエスト要求ユーザ情報」と称する。
【0569】
この場合、端末20Xの制御部21は、サーバ10から安否登録リクエスト要求ユーザ情報を受信すると、限定ではなく例として、記憶部28に記憶させる。
そして、端末20Xの制御部21は、安否登録リクエスト要求ユーザ表示条件が成立すると判定した場合、記憶部28に記憶された安否登録リクエスト要求ユーザ情報を表示部24に表示させる。
【0570】
ここで、安否登録リクエスト要求ユーザ表示条件としては、限定ではなく例として、以下の例が挙げられる。
【0571】
・安否登録リクエスト要求ユーザ情報要求操作が実行され、端末20Xに対する安否登録リクエスト要求情報を送信した安否登録要求アカウントを確認することが選択された場合。
・サーバ10から安否登録リクエスト情報を最後に受信後、設定期間(限定ではなく例として、「30分」)が経過した場合。
・サーバ10から安否登録リクエスト情報を最後に受信後、設定時刻(限定ではなく例として、「正午」)となった場合。
・サーバ10から安否登録リクエスト要求ユーザ情報を設定回数以上、または設定回数より多く受信した場合。
・端末20Xにおいて安否確認登録情報の入力が行われた場合。
【0572】
<第7実施例>
第7実施例は、安否確認サービスにおいて、一の災害における安否登録の期間が終了した場合、安否確認登録を受け付けない実施例である。
【0573】
第7実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0574】
<表示画面>
図7-1は、本実施例において端末20Bの表示部24に表示されるメッセージングアプリケーションの画面の一例を示す図である。
この例では、前述したユーザA.A、ユーザC.C、ユーザD.D、ユーザF.Fの4名のユーザから安否確認登録を要求されていることが示す安否登録リクエストコンテンツRCT8の下に、OAアカウントからの「20XX年8月4日9時39分」に発生した地震による安否登録を停止することを示す安否登録停止確認コンテンツSCT1が表示されている。この状態で、安否登録リクエストコンテンツRCT8内の回答ボタンBT4bがタップされると、
図7-1右側のような表示がなされる。
【0575】
この例では、既に安否登録が可能な期間が経過していることに基づいて、
図7-1左側の画面の中央部に、「安否登録期間が終了しています」の文字と、キャラクタの画像と、「OK」ボタンとを含む安否確認登録受付期間終了情報EPI1が表示されている。「OK」ボタンがタップされると、安否確認登録受付期間終了情報EPI1の表示は消去されるが、安否確認登録は受け付けられず、ユーザB.Bは安否確認登録をすることができないように構成されている。
【0576】
<処理>
図7-2は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
この図では、左側から順に、端末20Xの制御部21が実行する処理、端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0577】
ここでは、表示画面とは異なり、
・安否登録要求アカウント=端末20YのユーザY.Yのアカウント=表示画面における端末20Aおよび端末20C~端末20Fのユーザ
・被安否登録要求アカウント=端末20XのユーザX.Xのアカウント=表示画面における端末20BのユーザB.B
とする場合の処理を例示する。
【0578】
限定ではなく例として、端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われると、第1の安否登録リクエスト要求情報がサーバ10に送信される(タイミング「TM910」)。
すると、サーバ10の制御部11は、初期送信設定条件(X1)が成立していると判定し、第1の安否登録リクエスト情報を端末20Xに送信する(タイミング「TM920」)。
端末20Xの制御部21は、第1の安否登録リクエスト情報を受信すると、第1の安否登録リクエスト情報を表示部24に表示させる(タイミング「TM930」)。
【0579】
次いで、サーバ10の制御部11は、安否確認登録受付期間終了処理を実行する(タイミング「TM940」)。
【0580】
安否確認登録受付期間終了処理において、サーバ10の制御部11は、限定ではなく例として、サーバ10のユーザによる入力操作に基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行う。安否確認処理や安否登録リクエスト処理を終了させると判定された場合、サーバ10の制御部11は、安否確認登録情報の受信に対する安否情報の送信と、安否登録リクエスト要求情報の受信に対する安否登録リクエスト情報の送信とを停止させる。
【0581】
なお、安否確認登録受付期間終了処理において、サーバ10の制御部11は、限定ではなく例として、災害情報の災害発生日時から設定期間が経過したか否かに基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行うようにしてもよい。また、サーバ10の制御部11は、限定ではなく例として、災害情報における安否確認受付終了日時に基づいて、安否確認処理や安否登録リクエスト処理を終了させるか否かの判定を行うようにしてもよい。
【0582】
その後、端末20Xにおいて、限定ではなく例として、第1の安否登録リクエスト情報に対する入力操作に基づいて、安否確認登録情報を受け付けると、第1の安否確認登録情報がサーバ10に送信される(タイミング「TM950」)。そして、サーバ10は第1の安否確認登録情報を受信する(タイミング「TM960」)。
【0583】
なお、端末20Yにおいて安否登録リクエスト要求操作が実行され、端末20Xが安否登録リクエスト情報を受信することは必須ではない。
【0584】
サーバ10の制御部11は、タイミング「TM940」において安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「TM940」以降に安否確認登録情報を受信した場合(限定ではなく例として、タイミング「TM960」)、安否確認登録の受け付けを終了したことを示す安否確認登録受付期間終了情報を通信I/F14によって安否登録アカウントの端末20Xに送信する(タイミング「TM970」)。
【0585】
端末20Xの制御部21は、サーバ10から安否確認登録受付期間終了情報を受信すると、受信した安否確認登録受付期間終了情報を表示部24に表示させる(タイミング「TM980」)。
【0586】
なお、サーバ10の制御部11は、タイミング「TM940」において安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「TM940」以降に安否登録リクエスト要求情報を受信した場合、安否確認登録受付期間終了情報を安否登録要求アカウントの端末20に送信するようにしてもよい。
【0587】
また、サーバ10の制御部11は、限定ではなく例として、タイミング「TM940」以降に、端末20Xから前述した安否登録リクエスト要求ユーザ情報要求情報を受信する場合、安否確認登録受付期間終了情報を端末20Xに送信するようにしてもよい。
【0588】
<第7実施例の効果>
本実施例は、被安否登録要求アカウントの端末20において、安否登録リクエスト情報(限定ではなく、第2情報の一例)の受信に基づき、前述した第1表示が表示部24に表示される。そして、サーバ10は、安否確認登録受付期間(限定ではなく、安否確認の受付の一例)が終了している場合、その第1表示に対する、その被安否登録要求アカウントのユーザによる入力に基づいて、安否確認登録受付期間終了情報(限定ではなく、安否確認の受付が終了していることに関する情報の一例)を通信I/F14によって被安否登録要求アカウントのユーザの端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第2情報の受信に基づき、安否確認に関する第1表示が表示部に表示され、安否確認の受付が終了している場合、その第1表示に対する、端末のユーザによる入力に基づいて、安否確認の受付が終了していることに関する情報を端末に送信することで、安否確認の受付が終了していることを端末のユーザに知らせることができる。
【0589】
<第7変形例(1)>
上記の実施例では、安否確認登録受付期間終了処理において安否確認処理や安否登録リクエスト処理を終了させると判定した場合、サーバ10の制御部11は、それ以後に安否確認登録情報や安否登録リクエスト要求情報を受信すると、安否確認登録受付期間終了情報を返信する例を例示したが、これに限定されない。
限定ではなく例として、サーバ10の制御部11は、第1の災害情報に対する安否確認登録受付期間が終了している場合、第2の災害情報が送信する場合には、第2の災害情報に対する安否確認登録を受け付けるようにしてもよい。
【0590】
図7-3は、本変形におけるアカウント管理データベース155の一例であるアカウント管理データベース155Bのデータ構成例である。
アカウント管理データベース155Bには、アカウントごとの管理データとして、アカウント管理データが記憶される。
【0591】
各々のアカウント管理データには、限定ではなく例として、アプリケーションIDと、友だち管理データと、安否登録データとが記憶される。
【0592】
アプリケーションIDと、友だち管理データとは、限定ではなく例として、アカウント管理データベース155Aと同様に構成することができる。
【0593】
安否登録データは、このアプリケーションIDのアカウントに関連付けられた、安否に関する登録を記憶させるためのデータであり、限定ではなく例として、災害IDと、安否ステータス情報と、安否コメント情報と、安否位置情報とが関連付けて記憶される。
【0594】
災害IDは、発生した災害、あるいは発生した災害と対応する災害情報を識別するための情報である。この災害IDは、好ましくは災害(災害情報)ごとに一意な値であり、限定ではなく例として、サーバ10によって災害(災害情報)ごとに一意な値(固有の値)が設定されて記憶される。
【0595】
安否ステータス情報と、安否コメント情報と、安否位置情報とは、限定ではなく例として、安否登録アカウントの端末20によって入力される安否確認登録情報に基づいて、設定され、記憶される。なお、安否ステータス情報と、安否コメント情報と、安否位置情報とのうち、任意の要素を省略するようにしてもよい。
【0596】
図7-4は、本実施例において端末20Bの表示部24に表示されるメッセージングアプリケーションの画面の一例を示す図である。
図7-4左側の画面では、OAアカウントからの「20XX年8月4日9時39分」に発生した地震(限定ではなく、第1災害の一例)による安否登録を停止することを示す安否登録停止確認コンテンツSCT1の下に、OAアカウントからの「20XX年8月14日19時23分」に地震(限定ではなく、第2災害の一例)が発生したことを示す災害発生コンテンツDCT2が表示されている。限定ではなく例として、安否登録リクエストコンテンツRCT8内の回答ボタンBT4bがタップされると、
図7-4中央のような表示がなされる。
【0597】
具体的には、第1災害について安否確認登録受付期間(安否登録期間)は終了しているが、第2災害について安否登録を行うことは可能であり、安否登録を行うか否かを確認するための安否登録確認情報RCI1が、画面中央部にポップアップ形式で表示されている。この情報に含まれる「OK」ボタンがタップされ、ホーム画面に表示を戻すと、
図7-4右側のような表示がなされる。
【0598】
このホーム画面では、第2災害の発生に関する情報が表示されている。
また、安否登録を行うための安否登録領域R1がホーム画面の下部からせり上がるように表示されている。この安否登録領域R1の構成例については、前述した通りであるため、説明を省略する。
【0599】
図7-5は、限定ではなく例として、本実施例における各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
まず、サーバ10の制御部11は、限定ではなく例として、サーバ10のユーザによる入力操作に基づいて、第1災害における安否確認処理や安否登録リクエスト処理を開始させるための第1災害安否確認登録受付処理を実行する(タイミング「TM1005」)。第1災害安否確認登録受付処理において、サーバ10の制御部11は、第1災害と紐付けるための災害IDを生成する。なお、第1災害安否確認登録受付処理に伴い、サーバ10の制御部11は、各端末20に第1の災害情報を送信するようにしてもよい。また、第1の災害情報に第1災害と紐付けられた災害IDを含めるようにしてもよい。
【0600】
なお、サーバ10の制御部11は、不図示の災害情報サーバから受信した災害状況情報に基づいて、第1災害安否確認登録受付処理を実行するようにしてもよい。
【0601】
次いで、限定ではなく例として、端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われると、第1の安否登録リクエスト要求情報がサーバ10に送信される(タイミング「TM1010」)。
すると、サーバ10の制御部11は、初期送信設定条件が成立していると判定し、第1の安否登録リクエスト情報を端末20Xに送信する(タイミング「TM1015」)。
端末20Xの制御部21は、第1の安否登録リクエスト情報を受信すると、第1の安否登録リクエスト情報を表示部24に表示させる(タイミング「TM1020」)。
【0602】
次いで、サーバ10の制御部11は、第1災害における安否確認登録受付期間終了処理を実行する(タイミング「TM1025」)。
その後、サーバ10の制御部11は、第2災害における安否確認処理や安否登録リクエスト処理を開始させるための第2災害安否確認登録受付処理を実行する(タイミング「TM1030」)。なお、第2災害安否確認登録受付処理に伴い、サーバ10の制御部11は、各端末20に第2の災害情報を送信するようにしてもよい。また、第2の災害情報に第2災害と紐付けられた災害IDを含めるようにしてもよい。
【0603】
その後、端末20Xにおいて、限定ではなく例として、第1の安否登録リクエスト情報に対する入力操作に基づいて、安否確認登録情報を受け付けると、第1の安否確認登録情報がサーバ10に送信される(タイミング「TM1035」)。そして、サーバ10は第1の安否確認登録情報を受信する(タイミング「TM1040」)。なお、第1の安否確認登録情報に、第1災害と紐付けられた災害IDを含めるようにしてもよい。
【0604】
なお、端末20Yにおいて安否登録リクエスト要求操作が実行され、端末20Xが第1の安否登録リクエスト情報を受信することは必須ではない。
【0605】
サーバ10の制御部11は、タイミング「TM1025」において第1災害における安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「TM1025」以降に第1災害と紐付けられた災害IDを含む安否確認登録情報を受信した場合(限定ではなく例として、タイミング「TM1040」)、第1災害における安否確認登録の受け付けを終了したことを示す第1災害安否確認登録受付期間終了情報を通信I/F14によって安否登録アカウントの端末20Xに送信する(タイミング「TM1045」)。
【0606】
また、サーバ10の制御部11は、限定ではなく例として、第1災害安否確認登録受付期間終了情報を送信すると、第2災害安否確認登録受付処理が実行されている場合、第2災害に対する安否確認登録を受け付けていることを示す第2災害安否確認登録受付開始情報を安否登録アカウントの端末20Xに送信する(タイミング「TM1050」)。なお、第2災害安否確認登録受付開始情報に、第2災害と紐付けられた災害IDを含めるようにしてもよい。
【0607】
端末20Xの制御部21は、サーバ10から第1災害安否確認登録受付期間終了情報を受信すると、受信した第1災害安否確認登録受付期間終了情報を表示部24に表示させる(タイミング「TM1055」)。
また、端末20Xの制御部21は、サーバ10から第2災害安否確認登録受付開始情報を受信すると、受信した第2災害安否確認登録受付開始情報を表示部24に表示させる(TM1050)。
【0608】
ここで、第2災害安否確認登録受付開始情報は、第1災害とは異なる新たな安否確認登録が始まったことを示す情報でもよいし、第2災害情報を含む第2災害に対する安否確認登録の受け付け表示に関する情報でもよい。
【0609】
なお、サーバ10の制御部11は、タイミング「TM1025」において第1災害における安否確認処理や安否登録リクエスト処理を終了させると判定し、タイミング「TM1025」以降に第1災害と紐付けられた安否登録リクエスト要求情報を受信した場合、第1災害安否確認登録受付期間終了情報を安否登録要求アカウントの端末20に送信するようにしてもよい。
【0610】
また、サーバ10の制御部11は、タイミング「TM1030」以降に安否登録リクエスト要求情報を受信した場合、第2災害に対する安否登録リクエスト要求を被安否登録要求アカウントの端末20に送信するようにしてもよい。
【0611】
なお、サーバ10の制御部11は、第1災害における安否確認登録受付期間終了処理において第1災害における安否確認処理や安否登録リクエスト処理を終了させると判定する場合、端末20から安否確認登録情報を受信せずとも、各端末20に第1災害安否確認登録受付期間終了情報を送信するようにしてもよい。
この場合、端末20Xの制御部21は、第1災害安否確認登録受付期間終了情報を受信すると、第1災害に対する安否確認登録を受け付けないように制御するようにしてもよい。
【0612】
なお、サーバ10の制御部11は、第1の安否確認登録情報に災害IDが含まれていない場合、第1の安否確認登録情報を受信したタイミングがタイミング「TM1025」以降かつタイミング「TM1030」以前である場合、第1災害安否確認登録受付期間終了情報を安否登録アカウントの端末20Xに送信するようにしてもよい。
また、第1の安否確認登録情報に災害IDが含まれず、第1の安否確認登録情報を受信したタイミングがタイミング「TM1025」以降かつタイミング「TM1030」以降である場合、サーバ10の制御部11は、受信した第1の安否確認登録情報に基づいて、第2災害に対する安否情報を生成し、各端末20に送信するようにしてもよい。
【0613】
なお、サーバ10の制御部11は、限定ではなく例として、タイミング「TM1030」以降に、端末20Xから第1災害における安否登録リクエスト要求ユーザ情報要求情報を受信する場合、第1災害安否確認登録受付期間終了情報と第2災害安否確認登録受付開始情報とを端末20Xに送信するようにしてもよい。
【0614】
本変形例は、被安否登録アカウントの端末20において、一の災害(限定ではなく、第1災害の一例)の安否登録リクエスト要求情報(限定ではなく、第1情報の一例)に基づく安否登録リクエスト情報(限定ではなく、第2情報の一例)の受信に基づき、その一の災害について、前述した第1表示が表示部24に表示される。そして、サーバ10は、一の災害の安否確認登録受付期間(限定ではなく、第1災害の安否確認の受付の一例)が終了し、別の災害(限定ではなく、第2災害の一例)の安否確認登録受付期間(限定ではなく、第2災害の安否確認の受付の一例)が開始されている場合、その第1表示に対する、その被安否登録要求アカウントのユーザによる入力に基づいて、第1災害安否確認登録受付期間終了情報(限定ではなく、第1災害の安否確認の受付が終了していることに関する情報の一例)と、第2災害安否確認登録受付開始情報(限定ではなく、第2災害の安否確認の受付が開始されていることに関する情報の一例)とを通信I/F14によって被安否登録要求アカウントのユーザの端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第1災害の第1情報に基づく第2情報の受信に基づき、安否確認に関する第1表示が表示部に表示され、第1災害の安否確認の受付が終了し、第2災害の安否確認の受付が開始されている場合、その第1表示に対する、端末のユーザによる入力に基づいて、第1災害の安否確認の受付が終了していることに関する情報と、第2災害の安否確認の受付が開始されていることに関する情報とを端末に送信することで、第1災害の安否確認の受付が終了していることと、第2災害の安否確認の受付が開始されていることとを端末のユーザに知らせることができる。
【0615】
また、本変形例は、被安否登録要求アカウントの端末20において、安否登録リクエスト情報(限定ではなく、第2情報の一例)の受信に基づき、前述した第1表示が表示部24に表示される。そして、サーバ10は、安否確認登録受付期間(限定ではなく、安否確認の受付の一例)が終了している場合、その第1表示に対する入力を受け付けないことを示す情報を通信I/F14によって被安否登録要求アカウントの端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第2情報の受信に基づき、安否確認に関する第1表示が表示部に表示され、安否確認の受付が終了している場合、その第1表示に対する入力を不可にするための情報を端末に送信することで、第1表示に対する入力を受け付けないようにすることができる。
【0616】
<第7変形例(2)>
上記の実施例では、端末20Xのユーザは、安否確認登録情報を送信する前に安否確認登録受付期間が終了しているか否かを知ることができなかったが、これに限定されない。限定ではなく例として、安否登録リクエスト情報に安否登録期間(安否登録が可能な期間)や安否登録期限(安否登録の終期))に関する情報を含めるようにしてもよい。
【0617】
なお、これらの情報は、前述した第1表示を表示部24に表示する表示期間に関する情報(表示期限に関する情報)としてもよい。また、前述した第1表示から安否確認の回答(安否登録)を行うための入力が可能な入力期間に関する情報(入力期限に関する情報)としてもよい。
【0618】
図7-6左側は、本変形例において端末20Bの表示部24に表示されるメッセージングアプリケーションの画面の一例を示す図である。
この画面では、トーク領域における安否登録リクエストコンテンツRCT9内に、安否確認の回答を行うことが可能な回答期間に関する情報として、回答期限までの残り時間の情報を含む回答ボタンBT4cが設けられている。
【0619】
この例では、「9時41分」に安否登録が停止されることとしている。そして、その時刻までの残り時間が表示されている。安否の回答をせずに「9:41」になると、
図7-6右側のような表示がなされる。
【0620】
この例では、安否登録リクエストコンテンツRCT9の下に、OAアカウントからの「20XX年8月4日9時39分」に発生した地震による安否登録を停止することを示す安否登録停止確認コンテンツSCT1が表示されている。また、安否登録リクエストコンテンツRCT9の回答ボタンBT4cの中の回答期間に関する情報の表示が消去されるとともに、回答ボタンBT4cがグレーアウトして表示されており、回答ボタンBT4cをタップしても安否を回答することができないようになっている。
【0621】
端末20Xの制御部21は、安否登録リクエスト情報に含まれる安否登録期間や安否登録期限が過ぎた場合、限定ではなく例として、安否登録リクエスト情報に対する入力に基づいて、安否確認登録情報の入力を受け付けないようにすることができる。
【0622】
本変形例は、安否登録リクエスト情報(限定ではなく、第2情報の一例)は、安否登録期間や安否登録期限等に関する情報を含む。そして、被安否登録要求アカウントの端末20では、この安否登録リクエスト情報(限定ではなく、第2情報の一例)の受信に基づき、前述した第1表示が表示部24に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第1表示が端末の表示部に表示される有効期限に関する情報、または、第1表示に対する入力が可能な有効期限に関する情報を含む第2情報の受信に基づき、安否確認に関する第1表示が表示されて、端末のユーザがその第1表示を確認できるようにすることができる。
【0623】
<第7変形例(3)>
上記の実施例では、サーバ10において一の災害に対する安否確認登録の受付是非を判定したが、これに限定されない。限定ではなく例として、各端末20において、安否確認登録や安否登録リクエスト要求の受付是非を判定できるようにしてもよい。
【0624】
この場合、限定ではなく例として、サーバ10の制御部11は、災害情報にその災害に対する安否確認登録の受付期限に関する情報を含め、各端末20に送信する。そして、各端末20の制御部21は、受信した安否確認登録の受付期限に関する情報に基づいて、安否確認登録操作または安否登録リクエスト要求操作時に、安否確認登録情報または安否登録リクエスト要求を受け付けるか否かを判定するようにできる。
限定ではなく例として、各端末20の制御部21は、受付期限を過ぎている場合、安否確認登録情報または安否登録リクエスト要求の送信を受け付けないようにすることができる。
【0625】
<第7変形例(4)>
安否登録期間や安否登録期限が経過しても、登録済みの安否情報が、安否参照アカウントの端末20に表示されるようにしてもよいし、表示されないようにしてもよい。
【0626】
<第8実施例>
第8実施例は、安否確認サービスにおけるメンバーまたはメッセージングアプリケーションにおける友だちのブロックに関する実施例である。
【0627】
以下では、ブロック対象とされるユーザアカウントを「ブロック対象アカウント」、ブロック対象アカウントから送信されるコンテンツをブロックするユーザアカウントを「ブロック実行アカウント」と称する。
【0628】
第8実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0629】
<表示画面>
図8-1は、本実施例における端末20の表示部24に表示されるメッセージングアプリケーションの画面の一例を示す図である。
図8-1左側は、端末20Bの表示部24に表示されるメッセージングアプリケーションのホーム画面であり、安否登録領域R1において危険ボタンDBTがタップされ、安否メッセージ「怪我しちゃった」と、現在の居場所「つくば市」とが入力されて、登録ボタンBT3がタップされた状態が示されている。
【0630】
図8-1中央は、この場合に端末20Aの表示部24に表示されるメッセージングアプリケーションのトークリスト画面である。ユーザA.AはユーザB.Bにブロックされておらず、トークリストのユーザB.Bの項目には、第2危険アイコンDIC2が重畳されたユーザB.Bのアイコン画像、ユーザ名に加えて、前述した複合安否情報「つくば/怪我しちゃった」が表示されている。
【0631】
一方、
図8-1右側は、この場合に端末20Gの表示部24に表示されるメッセージングアプリケーションのトークリスト画面である。ユーザG.GはユーザB.Bにブロックされており、
図8-1中央の端末20Aの画面とは異なり、トークリストのユーザB.Bの項目には、第2危険アイコンDIC2が重畳されたユーザB.Bのアイコン画像、ユーザ名しか表示されていない。つまり、前述した複合安否情報「つくば/怪我しちゃった」は表示されておらず、「危険」であることはわかるが、安否メッセージや居場所はわからないようになっている。
【0632】
なお、ブロックされたユーザの端末20において、安否位置情報と安否コメント情報とを両方とも表示させないようにするのではなく、いずれか一方の情報は表示させるようにしてもよい。
【0633】
<処理>
図8-2は、限定ではなく例として、本実施例において各装置が実行する処理のタイミングの一例を示すタイミングチャートである。
この図では、左側から順に、端末20Xの制御部21が実行する処理、端末20Yの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
【0634】
ここでは、表示画面とは異なり、
・ブロック対象アカウント=端末20YのユーザY.Yのアカウント=表示画面における端末20AのユーザA.A
・ブロック実行アカウント=端末20XのユーザX.Xのアカウント=表示画面における端末20BのユーザB.B
とする場合の処理を例示する。
【0635】
限定ではなく例として、端末20Xの制御部21は、ユーザ操作に基づいて、ブロック対象アカウント(この場合、端末20Yのアカウント)からのコンテンツをブロックさせるためのブロック要求情報を通信I/F22によってサーバ10に送信する(タイミング「TM1105」)。ブロック要求情報には、端末20YのアプリケーションIDを含めるようにしてもよい。
【0636】
通信I/F14によって端末20Xからブロック要求情報を受信すると、サーバ10の制御部11は、ブロック処理を実行する(タイミング「TM1110」)。サーバ10の制御部11は、ブロック処理の実行後、限定ではなく例として、チャット処理において、端末20Yから端末20Xに対するメッセージ送信依頼情報を受信する場合、端末20Xにメッセージ送信依頼情報に基づくメッセージ情報を送信しない。
【0637】
次いで、限定ではなく例として、端末20Yにおいて端末20Xに対する安否登録リクエスト要求操作が行われると、第1の安否登録リクエスト要求情報がサーバ10に送信される(タイミング「TM1115」)。
すると、サーバ10の制御部11は、初期送信設定条件が成立していると判定し、第1の安否登録リクエスト情報を端末20Xに送信する(タイミング「TM1120」)。
端末20Xの制御部21は、第1の安否登録リクエスト情報を受信すると、第1の安否登録リクエスト情報を表示部24に表示させる(タイミング「TM1125」)。
【0638】
なお、サーバ10の制御部11は、ブロック対象アカウントの端末20Yからブロック実行アカウントの端末20Xへの安否登録リクエスト要求情報を受信する場合、安否登録リクエスト情報をブロック実行アカウントの端末20Xに送信しないようにしてもよい。
【0639】
端末20Xの制御部21は、限定ではなく例として、第1の安否登録リクエスト情報における第2表示に対する入力操作に基づいて、限定ではなく例として、安否ステータス情報を受け付け、受け付けた第1の安否ステータス情報を通信I/F22によってサーバ10に送信する(タイミング「TM1130」)。
また、端末20Xの制御部21は、限定ではなく例として、第1の安否登録リクエスト情報における第3表示に対する入力操作に基づいて、限定ではなく例として、安否コメント情報を受け付け、受け付けた第1の安否コメント情報を通信I/F22によってサーバ10に送信する(タイミング「TM1135」)。
【0640】
なお、画面図で例示したように、第2表示と第3表示とを同じ表示画面内に含むことに限定されない。限定ではなく例として、端末20Xの制御部21は、第2表示に対する入力操作を実行すると、第3表示を表示部24に表示させ、第3表示に対する入力操作を受け付けるようにしてもよい。
【0641】
サーバ10の制御部11は、端末20Xから第1の安否ステータス情報と、第1の安否コメント情報とを受信する。そして、サーバ10の制御部11は、第1の安否ステータス情報のみを含む第1の安否情報をブロック対象アカウントの端末20Yに送信する(タイミング「TM1140」)。
また、サーバ10の制御部11は、第1の安否ステータス情報と、第1の安否コメント情報とを含む第1の安否情報をブロック対象アカウント以外の各端末20に送信する(タイミング「TM1150」)。
【0642】
端末20Yの制御部21は、サーバ10から第1の安否ステータス情報のみを含む第1の安否情報を受信すると、受信した第1の安否情報を表示部24に表示させる(タイミング「TM1145」)。
【0643】
なお、第2表示と第3表示とにおいて受け付ける安否確認登録情報の組み合わせは、上記の組み合わせに限定されない。
ここで、第2表示に対して入力される安否登録情報を「第1安否情報」、第3表示に対して入力される安否登録情報を「第2安否情報」と称する。ブロック実行アカウントの端末20において、第1安否情報と第2安否情報とが入力されると、ブロック対象アカウントの端末20には、第1安否情報のみを含む安否情報が送信される。また、ブロック対象アカウント以外の各端末20には、第1安否情報と第2安否情報とを含む安否情報が送信される。
【0644】
なお、ブロック対象アカウントの端末20に、第1安否情報と第2安否情報とを含む安否情報が送信されるようにしてもよい。
【0645】
図8-3は、第1安否情報と第2安否情報との組み合わせを示す表である。
ここでは、限定ではなく例として、安否登録情報の構成要素を安否ステータス情報と安否コメント情報と安否位置情報として例示するが、他の構成要素が加わる場合にも同様にして第1安否情報と第2安否情報とを定めることができる。
【0646】
限定ではなく例として、
図8-1の例は、パターン(C)の場合に相当する。
パターン(A)~(C)では、ブロック対象アカウントの端末20において、安否ステータス情報は表示されるが、安否コメント情報と安否位置情報とは表示されない。しかし、安否確認登録入力において、安否コメント情報や安否位置情報の入力は安否ステータス情報の入力に比べて手間がかかるため、安否登録アカウントのユーザは安否ステータス情報のみを入力し、安否コメント情報や安否位置情報の入力を省略することが大いに考え得る。そのため、ブロック対象アカウントの端末20において、安否ステータス情報のみが表示される場合、ブロック対象アカウントのユーザからは安否コメント情報や安否位置情報が表示されていないのか、それともそもそも入力されていないのかを区別することができない。従って、ブロック対象アカウントのユーザは、ブロック実行アカウントのユーザからブロックされていることを認知することが困難である。
【0647】
なお、サーバ10の制御部11は、ブロック実行アカウントの端末20Xから安否確認登録情報を受信する場合、受信した安否確認登録情報に基づく安否確認情報をブロック対象アカウントの端末20Yに送信しないようにしてもよい。
【0648】
<第8実施例の効果>
本実施例は、被安否登録要求アカウントの端末20において、安否登録リクエスト情報(限定ではなく、第2情報の一例)の受信に基づき、前述した第1表示が表示部24に表示され、この第1表示に対する入力に基づいて、第2表示と、第2表示とは異なる第3表示とが表示部24に表示される。サーバ10は、被安否登録要求アカウントの端末20に表示された第2表示に対する入力に基づいて、被安否登録要求アカウントの端末20のユーザによって入力された一の安否情報(限定ではなく、第1安否情報の一例)を通信I/F14によって受信し、第3表示に対する入力に基づいて、被安否登録要求アカウントの端末20のユーザによって入力された別の安否情報(限定ではなく、第2安否情報の一例)を通信I/F14によって受信する。そして、サーバ10は、被安否登録要求アカウントのユーザによって友だち登録されているなどの被安否登録要求アカウントのユーザに関連付けられたユーザ(限定ではなく、端末のユーザに関連付けられたユーザの一例)の端末20に一の安否情報(第1安否情報)を送信する一方、被安否登録要求アカウントのユーザによって設定されたユーザの端末20に他の安否情報(第2安否情報)を送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末で、第2情報の受信に基づき、安否確認に関する第1表示が表示され、その第1表示に対する入力に基づいて、第2表示と、第2表示とは異なる第3表示とが表示される。そして、第2表示に対する入力に基づいて、端末のユーザによって入力された安否に関する第1安否情報を端末から受信し、第3表示に対する入力に基づいて、端末のユーザによって入力された安否に関する第2安否情報を受信することができる。また、端末のユーザに関連付けられたユーザに第1安否情報を送信して、端末のユーザの安否を知らせることができる。また、端末のユーザによって設定されたユーザに第2安否情報を送信して、端末のユーザの安否を知らせることができる。
【0649】
また、この場合、被安否登録要求アカウントのユーザによって設定されたユーザは、被安否登録要求アカウントのユーザによって友だち登録されているなどの被安否登録要求アカウントのユーザに関連付けられたユーザのうち、被安否登録要求アカウントのユーザによってブロックされたユーザ以外のユーザを含むようにすることができる。
このような構成により得られる実施例の効果の一例として、上記の端末のユーザによって設定されたユーザに、端末のユーザに関連付けられたユーザのうち端末のユーザによってブロックされたユーザ以外のユーザが含まれるようにすることで、端末のユーザによってブロックされたユーザ以外のユーザには第2安否情報を送信するようにすることができる。
【0650】
<第8変形例(1)>
上記の実施例では、ブロック対象アカウントの端末20には、第1安否情報のみを含む安否情報が送信され、ブロック対象アカウント以外の各端末20には、第1安否情報と第2安否情報とを含む安否情報が送信されることとしたが、これに限定されない。限定ではなく例として、各端末20には、第1安否情報と第2安否情報とを含む安否情報が送信されるが、ブロック対象アカウントの端末20では、第1安否情報のみが表示されるようにしてもよい。
【0651】
この場合、限定ではなく例として、サーバ10の制御部11は、ブロック実行アカウントの端末20Xからブロック要求情報を受信すると、ブロック対象アカウントの端末20Yに、ブロック実行アカウントの情報(限定ではなく例として、アプリケーションID)を含む安否表示ブロック要請情報を送信する。
ブロック対象アカウントの端末20Yの制御部21は限定ではなく例として、安否表示ブロック要請情報を受信した後にブロック実行アカウントを安否登録アカウントとし、第1安否情報と第2安否情報とを含む安否情報を受信する場合、第1安否情報のみを表示部24に表示させる。
【0652】
<第9実施例>
第9実施例は、安否確認サービスにおけるメンバーまたはメッセージングアプリケーションにおける友だちの安否確認登録状況を簡易に閲覧可能とする実施例である。
【0653】
第9実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
【0654】
<表示画面>
図9-1は、本実施例において端末20Bの表示部24に表示されるメッセージングアプリケーションの画面の一例を示す図である。
図9-1左側は、前述したメッセージングアプリケーションのOAアカウントとのトーク画面であり、この例では、OAからの安否登録リクエストコンテンツRCT1がタップされた状態が示されている。この場合、
図9-1右側のホーム画面が表示される。
【0655】
このホーム画面は、メッセージングアプリケーションのホーム画面であり、友だちリストの項目として、ユーザA.Aに対応したアイコンおよびユーザ名、ユーザD.Dに対応したアイコンおよびユーザ名、ユーザF.Fに対応したアイコンおよびユーザ名、ユーザG.Gに対応したアイコンおよびユーザ名等が表示されている。また、各々のユーザのアイコンには、そのユーザによって登録された安否情報を示すアイコンとして、前述した第1安全アイコン、第1危険アイコン、第1不明アイコンが関連付けて表示されている。つまり、安否確認登録状況の一覧画面が表示されている。
【0656】
さらに、この例では、ユーザB.Bが安否登録を未だ行っていないことに基づいて、安否登録ボタンBT1が強調表示(限定ではなく例として、点滅表示)されている。
【0657】
なお、上記のように友だちリストの画面に遷移させるのではなく、トークリスト画面に遷移させてもよく、安否確認登録状況の一覧が表示される画面に遷移させればよい。
【0658】
<第9変形例(1)>
上記の実施例では、安否登録リクエスト情報に対するユーザ操作に基づいて、安否確認登録状況の一覧画面に遷移したが、これに限定されない。限定ではなく例として、安否確認アプリケーションまたはメッセージングアプリケーションのプッシュ通知に対するユーザ操作に基づいて、安否確認登録画面に遷移するようにしてもよい。
【0659】
・スマートチャット領域内に安否登録リクエスト情報を表示(タップで安否確認登録画面に遷移可能)
・アプリプッシュで安否登録リクエスト情報から安否確認登録画面に遷移
【0660】
図9-2は、本変形例において端末20Bの表示部24に表示される画面の一例を示す図である。
図9-2左側は、端末20Bの表示部24に表示されるメッセージングアプリケーションのトークリスト画面であり、アプリ内位置表示領域の下の、災害が発生したことをトークリスト画面において報知するための災害情報表示領域の内部の右下には、ユーザB.Bが未だ安否登録を行っていないため安否登録ボタンBT1が表示されている。
また、その下には、ユーザB.Bに対して安否登録リクエストを行ったユーザのアイコンおよびユーザ名が一覧表示されている。
【0661】
端末20Bが操作されずに一定時間が経過すると、
図9-2中央のようなロック画面が表示される。この例では、ロック画面にアプリプッシュとして、メッセージングアプリケーションを発信元とする安否登録リクエスト情報のプッシュ通知PN7が表示されている。このプッシュ通知PN7がタップされると、限定ではなく例として、
図9-2右側のメッセージングアプリケーションのホーム画面が表示される。
【0662】
このホーム画面では、画面下部からせり上がるように安否登録領域R1が表示されており、安否登録をそのまますぐに行うことができるように構成されている。
【0663】
なお、
図9-2左側の画面における、安否登録リクエストを行っているユーザの一覧が表示される領域(この例では4名のユーザ)がタップされると、
図9-2右側のホーム画面が表示されるようにしてもよい。
【0664】
また、限定ではなく例として、安否登録リクエスト情報を、任意のトークルーム画面の最上部に表示させるようにしてもよい。そして、最上部に表示される安否登録リクエスト情報に対するユーザ操作に基づいて、安否確認登録画面に遷移できるようにしてもよい。
【0665】
<他の実施例>
<他の実施例(1)>
上記の実施例では、安否登録アカウントにより入力される安否確認登録情報を、安否確認アプリケーションまたはメッセージングアプリケーションのユーザに対する安否情報の送信のために使用したが、これに限定されない。限定ではなく例として、サーバ10の制御部11は、各端末20より受信した安否確認登録情報を集計処理し、集計結果を救援活動のためのビッグデータとして用いるようにしてもよい。
【0666】
限定ではなく例として、サーバ10の制御部11は、各端末20より受信した安否ステータス情報と安否位置情報とを集計し、安否ステータス情報が「危険」と入力された地域の偏りを求める。そして、サーバ10の制御部11は、「危険」と入力された頻度が高い地域に関する位置情報である救助対象エリア情報を算出する。サーバ10の制御部11は、算出された救助対象エリア情報を表示部13に表示させるようにしてもよい。
【0667】
なお、サーバ10の制御部11は、算出された救助対象エリア情報を通信I/F14によって不図示の災害対策本部サーバに送信するようにしてもよい。
【0668】
<他の実施例(2)>
上記の実施例では、被安否登録要求アカウントの端末20に対して安否確認登録情報の入力と送信とを促すために安否登録リクエスト要求情報を送信する例について例示したが、これに限定されない。より一般的に、サーバ10の制御部11は、任意の情報の入力と送信とを促すためのリクエスト情報を送信するようにしてもよい。
【0669】
限定ではなく例として、リクエスト情報として、借金の返済を促す要求例(以下、「要望」と称する。)について例示する。
また、以下では、借金の返済を迫られるユーザのアカウントを「被要望要求アカウント」、被要望要求アカウントに対して借金の返済を求めるユーザのアカウントを「要望要求アカウント」と称する。ここで、要望要求アカウントは複数のアカウントとし、限定ではなく例として、「第1の要望要求アカウント」と「第2の要望要求アカウント」と称する。
【0670】
第1の要望要求アカウントの端末20は、限定ではなく例として、ユーザ操作に基づいて、被要望要求アカウントに対して要望を伝えるための第1の要望要求情報をサーバ10に送信する。
サーバ10の制御部11は、第1の要望要求アカウントの端末20から第1の要望要求情報を受信すると、設定条件(複合設定条件)が成立しているか否かを判定する。そして、設定条件(複合設定条件)が成立していると判定する場合、サーバ10の制御部11は、第1の要望要求情報に基づく第1の要望情報(この例では借金の返済を促すことに関する情報)を被要望要求アカウントの端末20に送信する。
被要望要求アカウントの端末20の制御部21は、受信した第1の要望情報を表示部24に表示させる。
【0671】
次いで、第2の要望要求アカウントの端末20は、限定ではなく例として、ユーザ操作に基づいて、被要望要求アカウントに対して要望を伝えるための第2の要望要求情報をサーバ10に送信する。
サーバ10の制御部11は、第2の要望要求アカウントの端末20から第2の要望要求情報を受信すると、設定条件(複合設定条件)が成立しているか否かを判定する。そして、設定条件(複合設定条件)が成立していると判定する場合、サーバ10の制御部11は、第2の要望要求情報に基づく第2の要望情報を被要望要求アカウントの端末20に送信する。被要望要求アカウントの端末20の制御部21は、受信した第2の要望情報を表示部24に表示させる。
設定条件(複合設定条件)が成立しているないと判定する場合、サーバ10の制御部11は、第2の要望要求情報に基づく第2の要望情報を被要望要求アカウントの端末20に送信しない。
【0672】
すなわち、複数のアカウントを含む要望要求アカウントが一の被要望要求アカウントに対して任意の要望を通達する場合、限定ではなく例として、以下の対応関係を当てはめることができる。
・「安否登録リクエスト要求情報」=「要望要求情報」
・「安否登録リクエスト情報」=「要望情報」
・「被安否登録要求アカウント」=「被要望要求アカウント」
・「安否登録要求アカウント」=「要望要求アカウント」
【0673】
この場合、任意のタイミングにおける要望要求情報に基づく要望情報送信の有無は、限定ではなく例として、第5実施例の複合設定条件による制御と同様に制御することができる。すなわち、上記の実施例を参酌すると、初めて一の被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、サーバ10は被要望要求アカウントの端末20に要望情報を送信する。そしてサーバ10はそれ以後にその被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、再度被要望要求アカウントの端末20に要望情報を送信しないといった制御が実現可能である。また、サーバ10は、被要望要求アカウントに対する安否登録リクエスト要求情報を受信する場合、所定の条件を満たす場合、リマインドとして再度被要望要求アカウントの端末20に要望情報を送信するといった制御も可能である。
【0674】
なお、要望要求アカウントの端末20は、被要望要求アカウントの端末20に対する任意のコンテンツの送信要求(「コンテンツ送信要求情報」と称する。)をサーバ10に送信するようにしてもよい。サーバ10の制御部11は、コンテンツ送信要求情報を受信すると、複合設定条件に基づいて、要望要求アカウントの端末20にコンテンツ送信要求情報に基づくコンテンツ情報を送信するか否かの制御を実行するようにしてもよい。
【0675】
本実施例は、被要望要求アカウントの端末20(限定ではなく、端末の一例)と通信するサーバ10が、被要望要求アカウントの端末20のユーザに対するコンテンツの送信の依頼に関する情報(限定ではなく、コンテンツの送信の依頼に関する第1情報の一例)を、一の要望要求アカウントの端末20(限定ではなく、第1端末の一例)から受信する。そして、サーバ10は、受信したコンテンツの送信の依頼に関する情報に基づき、コンテンツに関する情報を、通信I/F14によって被要望要求アカウントの端末20に送信する。
また、サーバ10は、被要望要求アカウントの端末20のユーザに対するコンテンツの送信の依頼に関する情報(限定ではなく、コンテンツの送信の依頼に関する第1情報の一例)を、他の要望要求アカウントの端末20(限定ではなく、第2端末の一例)から受信する。そして、サーバ10は、受信したコンテンツの送信の依頼に関する情報と、設定された条件とに基づき、コンテンツに関する情報を、通信I/F14によって被要望要求アカウントの端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザに対するコンテンツの送信の依頼に関する第1情報を第1端末から受信した上で、その第1情報に基づき、コンテンツに関する第2情報を端末に送信することで、限定ではなく例として、コンテンツを送信するように端末のユーザに促すことができる。また、端末のユーザに対するコンテンツの送信の依頼に関する第1情報を第2端末から受信した上で、その第1情報と設定された条件とに基づき、コンテンツに関する第2情報を端末に送信することで、限定ではなく例として、コンテンツを送信するように端末のユーザに促すことができる。
【0676】
<その他>
上記の実施例や変形例で説明した、メッセージングアプリケーション(メッセージングサービス)で実現した内容は、基本的に、第5実施例で説明した安否確認アプリケーション(安否確認サービス)についても同様に適用可能である。
【符号の説明】
【0677】
1 通信システム
10 サーバ
20 端末
30 ネットワーク