特開 2024-73280 監視システムおよびプログラム

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

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

(11)【公開番号】P2024073280

(43)【公開日】2024-05-29

(54)【発明の名称】監視システムおよびプログラム

(51)【国際特許分類】

   G08B 25/04 20060101AFI20240522BHJP

   G08B 21/02 20060101ALI20240522BHJP

   H04M 1/00 20060101ALI20240522BHJP

   G06Q 50/22 20240101ALI20240522BHJP

【ＦＩ】

G08B25/04 K

G08B21/02

H04M1/00 Q

G06Q50/22

【審査請求】未請求

【請求項の数】13

【出願形態】ＯＬ

(21)【出願番号】P 2022184393

(22)【出願日】2022-11-17

(71)【出願人】

【識別番号】000001432

【氏名又は名称】グローリー株式会社

(74)【代理人】

【識別番号】110001818

【氏名又は名称】弁理士法人Ｒ＆Ｃ

(72)【発明者】

【氏名】柳内 久和

(72)【発明者】

【氏名】藻川 俊二

(72)【発明者】

【氏名】福田 幸貴

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

5C086

5C087

5K127

5L099

【Ｆターム（参考）】

5C086AA22

5C086BA07

5C086CA28

5C086CB36

5C086DA08

5C086FA01

5C086FA17

5C086FA18

5C086FA20

5C087AA02

5C087AA03

5C087AA09

5C087AA10

5C087AA21

5C087AA25

5C087AA31

5C087AA51

5C087DD03

5C087DD30

5C087EE14

5C087EE18

5C087FF01

5C087FF02

5C087FF04

5K127AA31

5K127BA03

5K127CB02

5K127CB18

5K127CB22

5K127CB42

5K127GA12

5K127GB07

5K127HA08

5K127HA10

5K127JA14

5K127JA34

5K127KA01

5K127KA02

5L099AA13

(57)【要約】

【課題】ユーザーが応援要請を行い、且つ、当該応援要請に応じて他のユーザーが応援に向かう場合に、当該他のユーザーに応援意思があることを、当該他のユーザー以外のユーザーが知ることができる監視システムおよびプログラムを提供する。
【解決手段】複数の端末２と、被監視者Ｄの状態を検知する状態検知部と、状態検知部により所定状態が検知されたことに応じて、状態検知部による検知結果を示す情報である状態情報を複数の端末２へ送信する状態送信部と、を備える監視システムであって、端末２は、応援要請の入力操作を受け付ける要請入力部２０と、応援要請を示す情報である要請情報を外部へ送信する要請送信部と、他の端末２から送信された要請情報を受信する要請受信部と、応援要請に対する応援意思の入力操作を受け付ける意思入力部２０と、応援意思を示す情報である意思情報を外部へ送信する意思送信部と、を有する。
【選択図】図７

【特許請求の範囲】

【請求項1】

複数の端末と、
被監視者の状態を検知する状態検知部と、
前記状態検知部により所定状態が検知されたことに応じて、前記状態検知部による検知結果を示す情報である状態情報を前記複数の端末へ送信する状態送信部と、を備える監視システムであって、
前記端末は、
応援要請の入力操作を受け付ける要請入力部と、
前記応援要請を示す情報である要請情報を外部へ送信する要請送信部と、
他の前記端末から送信された前記要請情報を受信する要請受信部と、
前記応援要請に対する応援意思の入力操作を受け付ける意思入力部と、
前記応援意思を示す情報である意思情報を外部へ送信する意思送信部と、を有する監視システム。

【請求項2】

前記端末は、他の前記端末から送信された前記意思情報を受信する意思受信部を有しており、
前記端末は、当該端末が前記応援要請の入力操作を受け付け、且つ、当該応援要請に関する前記意思情報を受信した場合、当該端末のユーザーに当該意思情報に基づく報知を行う意思報知部を有する請求項１に記載の監視システム。

【請求項3】

前記端末は、前記応援要請に対する応援完了の入力操作を受け付ける完了入力部を有する請求項１または２に記載の監視システム。

【請求項4】

前記端末は、前記応援完了を示す情報である完了情報を外部へ送信する完了送信部を有する請求項３に記載の監視システム。

【請求項5】

前記端末は、他の前記端末から送信された前記意思情報を受信する意思受信部を有しており、
前記端末は、前記要請情報を受信し、且つ、当該要請情報に関する前記意思情報を受信した場合、当該端末における前記意思入力部を、前記応援意思の入力操作を受け付けない状態にする連携処理部を有する請求項１または２に記載の監視システム。

【請求項6】

前記端末は、
当該端末が前記応援要請の入力操作を受け付けた後、当該応援要請のキャンセルの入力操作を受け付けるキャンセル入力部と、
前記キャンセルを示す情報であるキャンセル情報を外部へ送信するキャンセル送信部と、を有する請求項１または２に記載の監視システム。

【請求項7】

前記端末は、他の前記端末から送信された前記キャンセル情報を受信するキャンセル受信部を有しており、
前記端末は、前記キャンセル情報を受信した場合、当該端末における前記意思入力部を、前記応援意思の入力操作を受け付けない状態にするキャンセル処理部を有する請求項６に記載の監視システム。

【請求項8】

前記端末は、他の前記端末から送信された前記キャンセル情報を受信するキャンセル受信部を有しており、
前記端末は、当該端末が前記応援意思の入力操作を受け付け、且つ、当該応援意思に関する前記キャンセル情報を受信した場合、当該端末のユーザーに当該キャンセル情報に基づく報知を行うキャンセル報知部を有する請求項６に記載の監視システム。

【請求項9】

前記要請情報は、前記応援要請の入力操作を行った人物を示す情報である要請者情報と、前記応援要請の入力操作が行われた時刻を示す情報である要請時刻情報と、を含んでいる請求項１または２に記載の監視システム。

【請求項10】

前記要請入力部は、要請する応援の内容を選択式で入力操作可能に構成されており、
前記端末は、前記要請入力部への入力操作に基づいて、応援の内容を示す内容情報を生成する内容情報生成部を有しており、
前記要請情報は、前記内容情報を含んでいる請求項１または２に記載の監視システム。

【請求項11】

前記要請入力部は、前記応援要請の対象者の属性を入力操作可能に構成されており、
前記端末は、前記要請入力部への入力操作に基づいて、前記属性を示す属性情報を生成する属性情報生成部を有しており、
前記要請情報は、前記属性情報を含んでいる請求項１または２に記載の監視システム。

【請求項12】

前記意思情報は、前記応援意思の入力操作を行った人物を示す情報である応援人物情報を含んでいる請求項１または２に記載の監視システム。

【請求項13】

被監視者の状態を検知する状態検知部により所定状態が検知された場合に前記状態検知部による検知結果を示す情報である状態情報を受信する端末にて実行されるプログラムであって、
応援要請の入力操作を受け付ける要請入力機能と、
前記応援要請を示す情報である要請情報を外部へ送信する要請送信機能と、
外部からの前記要請情報を受信する要請受信機能と、
前記応援要請に対する応援意思の入力操作を受け付ける意思入力機能と、
前記応援意思を示す情報である意思情報を外部へ送信する意思送信機能と、を前記端末に実現させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、監視システムおよびプログラムに関する。

【背景技術】

【0002】

特許文献１には、被監視者を監視する監視システムが記載されている。この監視システム（特許文献１では「見守りシステム」）においては、被監視者（特許文献１では「対象者」）に関する所定のイベント（例えば転倒）が発生した場合、端末（特許文献１では「携帯端末」）への通知が行われる。

【0003】

この監視システムにおける端末は、応援要請（特許文献１では「スタッフ窮状情報」）の入力操作を受け付けることができる。応援要請の入力操作が行われた場合、他の端末へ、応援要請を示す情報が送信される。これにより、端末を所持するユーザーは、他の端末を所持するユーザーに対して、応援の要請を行うことができる。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０２０－１４０４１８号公報

【発明の概要】

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

【0005】

特許文献１に記載の監視システムでは、ユーザーが応援要請を行い、且つ、当該応援要請に応じて他のユーザーが応援に向かう場合に、応援要請を行ったユーザーは、当該他のユーザーが応援に向かっていることを知ることができない。

【0006】

また、特に三人以上のユーザーが存在する場合において、一人のユーザーが応援要請を行い、且つ、当該応援要請に応じて他の一人のユーザーが応援に向かう場合に、その他のユーザー（応援要請を行ったユーザーでなく、応援に向かっているユーザーでもないユーザー）は、当該他の一人のユーザーが応援に向かっていることを知ることができない。その結果、例えば応援が重複してしまう等の非効率な事態が生じる可能性がある。

【0007】

本発明の目的は、ユーザーが応援要請を行い、且つ、当該応援要請に応じて他のユーザーが応援に向かう場合に、当該他のユーザーに応援意思があることを、当該他のユーザー以外のユーザーが知ることができる監視システムおよびプログラムを提供することである。

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

【0008】

本発明に係る監視システムの特徴は、複数の端末と、被監視者の状態を検知する状態検知部と、前記状態検知部により所定状態が検知されたことに応じて、前記状態検知部による検知結果を示す情報である状態情報を前記複数の端末へ送信する状態送信部と、を備える監視システムであって、前記端末は、応援要請の入力操作を受け付ける要請入力部と、前記応援要請を示す情報である要請情報を外部へ送信する要請送信部と、他の前記端末から送信された前記要請情報を受信する要請受信部と、前記応援要請に対する応援意思の入力操作を受け付ける意思入力部と、前記応援意思を示す情報である意思情報を外部へ送信する意思送信部と、を有することにある。

【0009】

本発明に係るプログラムの特徴は、被監視者の状態を検知する状態検知部により所定状態が検知された場合に前記状態検知部による検知結果を示す情報である状態情報を受信する端末にて実行されるプログラムであって、応援要請の入力操作を受け付ける要請入力機能と、前記応援要請を示す情報である要請情報を外部へ送信する要請送信機能と、外部からの前記要請情報を受信する要請受信機能と、前記応援要請に対する応援意思の入力操作を受け付ける意思入力機能と、前記応援意思を示す情報である意思情報を外部へ送信する意思送信機能と、を前記端末に実現させることにある。

【0010】

本発明によれば、応援意思を示す情報である意思情報が、端末の外部へ送信される。そのため、例えば他の端末が当該意思情報を受信すれば、当該意思情報を受信した端末のユーザーは、自身以外のユーザーに応援意思があることを知ることができる。その結果、例えば応援が重複してしまう等の非効率な事態の発生を抑制できる。

【0011】

このように、本発明によれば、ユーザーが応援要請を行い、且つ、当該応援要請に応じて他のユーザーが応援に向かう場合に、当該他のユーザーに応援意思があることを、当該他のユーザー以外のユーザーが知ることができる。

【0012】

さらに、本発明において、前記端末は、他の前記端末から送信された前記意思情報を受信する意思受信部を有しており、前記端末は、当該端末が前記応援要請の入力操作を受け付け、且つ、当該応援要請に関する前記意思情報を受信した場合、当該端末のユーザーに当該意思情報に基づく報知を行う意思報知部を有すると好適である。

【0013】

本構成によれば、ユーザーが応援要請を行い、且つ、当該応援要請に応じて他のユーザーが応援に向かう場合に、応援要請を行ったユーザーは、意思報知部による報知によって、当該他のユーザーに応援意思があることを知ることができる。これにより、応援要請を行ったユーザーは、当該他のユーザーが応援に来ることを知った上で、適切な行動をとりやすい。

【0014】

さらに、本発明において、前記端末は、前記応援要請に対する応援完了の入力操作を受け付ける完了入力部を有すると好適である。

【0015】

本構成によれば、監視システムにおいて、応援が完了したことを示す情報を利用することができる。その結果、例えば、各ユーザーが当該情報に基づいて適切な行動をとりやすい。

【0016】

さらに、本発明において、前記端末は、前記応援完了を示す情報である完了情報を外部へ送信する完了送信部を有すると好適である。

【0017】

本構成によれば、応援完了を示す情報である完了情報が、端末の外部へ送信される。そのため、例えば他の端末が当該完了情報を受信すれば、当該完了情報を受信した端末のユーザーは、応援が完了したことを知ることができる。

【0018】

さらに、本発明において、前記端末は、他の前記端末から送信された前記意思情報を受信する意思受信部を有しており、前記端末は、前記要請情報を受信し、且つ、当該要請情報に関する前記意思情報を受信した場合、当該端末における前記意思入力部を、前記応援意思の入力操作を受け付けない状態にする連携処理部を有すると好適である。

【0019】

本構成によれば、端末における意思入力部が応援意思の入力操作を受け付けない状態となることにより、当該端末のユーザーは、他のユーザーが既に応援意思の入力操作を行ったことを確実に認識しやすい。

【0020】

さらに、本発明において、前記端末は、当該端末が前記応援要請の入力操作を受け付けた後、当該応援要請のキャンセルの入力操作を受け付けるキャンセル入力部と、前記キャンセルを示す情報であるキャンセル情報を外部へ送信するキャンセル送信部と、を有すると好適である。

【0021】

本構成によれば、応援要請のキャンセルを示す情報であるキャンセル情報が、端末の外部へ送信される。そのため、例えば他の端末が当該キャンセル情報を受信すれば、当該キャンセル情報を受信した端末のユーザーは、応援要請がキャンセルされたことを知ることができる。

【0022】

さらに、本発明において、前記端末は、他の前記端末から送信された前記キャンセル情報を受信するキャンセル受信部を有しており、前記端末は、前記キャンセル情報を受信した場合、当該端末における前記意思入力部を、前記応援意思の入力操作を受け付けない状態にするキャンセル処理部を有すると好適である。

【0023】

本構成によれば、端末における意思入力部が応援意思の入力操作を受け付けない状態となることにより、当該端末のユーザーは、応援要請がキャンセルされたことを確実に認識しやすい。

【0024】

さらに、本発明において、前記端末は、他の前記端末から送信された前記キャンセル情報を受信するキャンセル受信部を有しており、前記端末は、当該端末が前記応援意思の入力操作を受け付け、且つ、当該応援意思に関する前記キャンセル情報を受信した場合、当該端末のユーザーに当該キャンセル情報に基づく報知を行うキャンセル報知部を有すると好適である。

【0025】

本構成によれば、応援要請に応じてユーザーが応援に向かっているときに、当該応援要請がキャンセルされた場合、当該ユーザーは、キャンセル報知部による報知により、当該応援要請がキャンセルされたことを知ることができる。これにより、応援要請がキャンセルされたにもかかわらず、ユーザーが応援のための行動（例えば応援要請を行ったユーザーのいる部屋へ向かって移動すること）を続けてしまう事態を回避しやすい。

【0026】

さらに、本発明において、前記要請情報は、前記応援要請の入力操作を行った人物を示す情報である要請者情報と、前記応援要請の入力操作が行われた時刻を示す情報である要請時刻情報と、を含んでいると好適である。

【0027】

本構成によれば、要請情報を受信した端末のユーザーは、応援要請の入力操作を行った人物と、応援要請の入力操作が行われた時刻と、を知ることができる。これにより、要請情報に要請者情報及び要請時刻情報が含まれていない場合に比べて、ユーザーが、自身が応援に向かうべきか否かを適切に判断しやすい。

【0028】

さらに、本発明において、前記要請入力部は、要請する応援の内容を選択式で入力操作可能に構成されており、前記端末は、前記要請入力部への入力操作に基づいて、応援の内容を示す内容情報を生成する内容情報生成部を有しており、前記要請情報は、前記内容情報を含んでいると好適である。

【0029】

本構成によれば、要請情報を受信した端末のユーザーは、要請されている応援の内容を知ることができる。これにより、要請情報に内容情報が含まれていない場合に比べて、ユーザーが、自身が応援に向かうべきか否かを適切に判断しやすい。

【0030】

さらに、本発明において、前記要請入力部は、前記応援要請の対象者の属性を入力操作可能に構成されており、前記端末は、前記要請入力部への入力操作に基づいて、前記属性を示す属性情報を生成する属性情報生成部を有しており、前記要請情報は、前記属性情報を含んでいると好適である。

【0031】

本構成によれば、要請情報を受信した端末のユーザーは、応援要請の対象者の属性を知ることができる。これにより、要請情報に属性情報が含まれていない場合に比べて、ユーザーが、自身が応援に向かうべきか否かを適切に判断しやすい。

【0032】

さらに、本発明において、前記意思情報は、前記応援意思の入力操作を行った人物を示す情報である応援人物情報を含んでいると好適である。

【0033】

本構成によれば、応援人物情報を含む意思情報が、端末の外部へ送信される。そのため、例えば他の端末が当該意思情報を受信すれば、当該意思情報を受信した端末のユーザーは、応援意思の入力操作を行った人物を知ることができる。これにより、各ユーザーは、応援に向かう人物を知った上で、適切な行動をとりやすい。

【図面の簡単な説明】

【0034】

【図1】監視システムの概要を示す図である。

【図2】監視装置に関する構成を示すブロック図である。

【図3】応援要請に関する構成を示すブロック図である。

【図4】要請入力画面を示す図である。

【図5】要請入力画面を示す図である。

【図6】要請入力画面を示す図である。

【図7】第１端末に応援要請の入力操作が行われた後の各端末の表示画面を示す図である。

【図8】第２端末に応援意思の入力操作が行われた後の各端末の表示画面を示す図である。

【図9】応援処理フローのフローチャートである。

【図10】第１キャンセル画面を示す図である。

【図11】第２端末に応援完了の入力操作が行われた後の各端末の表示画面を示す図である。

【図12】第２キャンセル画面を示す図である。

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

【0035】

本発明を実施するための形態について、図面に基づき説明する。

【0036】

〔監視システムの全体構成〕
図１に示すように、本実施形態における監視システムＡは、監視装置１及び複数の端末２を備えている。監視装置１と複数の端末２とは、所定のネットワークを介して互いに接続されている。また、複数の端末２同士も、所定のネットワークを介して互いに接続されている。

【0037】

監視装置１は、被監視者Ｄの存在するエリアに設置されている。監視装置１は、被監視者Ｄを監視する。監視装置１は、被監視者Ｄが所定状態（例えば転倒した状態）となったとき、複数の端末２に、被監視者Ｄの状態を示す情報を送信する。複数の端末２は、当該情報を受信すると、発報を行う。

【0038】

特に限定されないが、本実施形態において、被監視者Ｄは老人福祉施設の入居者であり、端末２のユーザーＥは、老人福祉施設の職員である。監視装置１は、例えば、トイレ、居室、廊下等に設置されていても良い。監視システムＡに含まれる監視装置１は、一つであっても良いし、複数個であっても良い。また、監視システムＡにより監視される被監視者Ｄは、一人であっても良いし、複数人であっても良い。

【0039】

また、監視システムＡに含まれる複数の端末２のうち、一部または全部が、携帯端末（スマートフォンやタブレット等）であっても良いし、老人福祉施設の職員用の部屋に設置されたパソコン等であっても良い。

【0040】

図１に示すように、端末２はタッチパネル２０（本発明に係る「要請入力部」、「意思入力部」、「完了入力部」、「キャンセル入力部」に相当）を有している。特に限定されないが、上述の発報は、より具体的には、タッチパネル２０において被監視者Ｄの状態を表示することにより行われても良いし、端末２から発生する音や、端末２の振動等により行われても良い。

【0041】

〔監視装置の構成〕
図２に示すように、監視装置１は、撮像部３、状態検知部４、状態送信部５を有している。端末２は、状態受信部２１を有している。

【0042】

撮像部３は、監視装置１の設置されているエリア内を撮像する。本実施形態において、撮像部３は、赤外線カメラにより構成されている。ただし、本発明はこれに限定されず、撮像部３は、監視装置１の設置されているエリア内を撮像可能であれば、赤外線カメラ以外のいかなる装置であっても良い。撮像部３は、ＴｏＦ（Ｔｉｍｅ ｏｆ ｆｌｉｇｈｔ）カメラであると好適である。撮像部３により取得される撮像画像は、深度の情報を含む画像である深度画像であると好適である。尚、撮像部３により取得される撮像画像は、動画であっても良いし、静止画であっても良い。

【0043】

撮像部３は、取得した撮像画像を、状態検知部４へ送る。状態検知部４は、撮像部３から受け取った撮像画像に基づいて、被監視者Ｄの状態を検知する。即ち、監視システムＡは、被監視者Ｄの状態を検知する状態検知部４を備えている。

【0044】

本実施形態において、状態検知部４は、受け取った撮像画像に基づいて、被監視者Ｄの骨格を示す情報である骨格モデルを生成する。骨格モデルは、撮像画像を解析して被監視者Ｄの関節の位置を３次元的に認識し、各関節を直線で結んで生成される。

【0045】

さらに、状態検知部４は、撮像画像及び生成された骨格モデルに基づいて、被監視者Ｄの体位（例えば、立位、臥位、座位）を検知すると共に、撮像画像及び骨格モデルに基づいて、被監視者Ｄが所定状態にあるか否かを検知するように構成されている。

【0046】

特に限定されないが、当該所定状態は、被監視者Ｄの危険状態（例えば転倒した状態）であっても良い。尚、撮像画像あるいは骨格モデルに基づいて転倒等の危険状態を検知する技術については公知であるため説明を省略する。

【0047】

状態検知部４により被監視者Ｄの所定状態が検知された場合、状態検知部４から状態送信部５へ状態情報が送られる。状態情報とは、状態検知部４による検知結果を示す情報である。状態送信部５は、当該状態情報を、各端末２の状態受信部２１へ送信する。

【0048】

即ち、監視システムＡは、状態検知部４により所定状態が検知されたことに応じて、状態検知部４による検知結果を示す情報である状態情報を複数の端末２へ送信する状態送信部５を備えている。

【0049】

状態受信部２１は、受信した状態情報に基づいて、タッチパネル２０に、被監視者Ｄの状態を示す情報を表示する。これにより、上述の発報が行われる。尚、状態受信部２１が受信する状態情報や、タッチパネル２０に表示される情報は、例えば、被監視者Ｄの存在するエリアを特定する情報（例えば「１Ｆ東トイレ」というメッセージ）を含んでいても良いし、被監視者Ｄの骨格を示す画像を含んでいても良い。

【0050】

〔応援要請〕
図３には、本実施形態の監視システムＡに含まれる第１端末２Ａ、第２端末２Ｂ、第３端末２Ｃが示されている。第１端末２Ａ、第２端末２Ｂ、第３端末２Ｃは、何れも、端末２である。尚、監視システムＡに含まれる端末２の個数は、二つでも良いし、四つ以上であっても良い。

【0051】

本実施形態において、各端末２は、互いに同一の構成を有している。即ち、第１端末２Ａ、第２端末２Ｂ、第３端末２Ｃは、互いに同一の構成を有している。

【0052】

図３に示すように、端末２は、制御部２２を有している。制御部２２は、タッチパネル２０の表示を制御可能に構成されている。

【0053】

端末２は、応援要請の入力操作を受け付け可能に構成されている。尚、応援要請とは、端末２のユーザーＥが、他の端末２のユーザーＥに対して応援を要請することである。以下では、応援要請に関する構成について詳述する。

【0054】

図３に示すように、制御部２２は、要請送信部２３及び要請受信部２４を有している。また、端末２は、タッチパネル２０に、図４から図６に示す要請入力画面を表示可能に構成されている。

【0055】

図４に示すように、要請入力画面には、内容入力部４０、対象者入力部４１、要請ボタン４２が含まれている。

【0056】

図５に示すように、内容入力部４０は、要請する応援の内容を、例えばプルダウンメニューによって、選択式で入力操作可能に構成されている。即ち、タッチパネル２０は、要請する応援の内容を選択式で入力操作可能に構成されている。

【0057】

内容入力部４０に入力可能な内容の選択肢は特に限定されないが、例えば図５に示すように、「未選択」、「車椅子が必要です」、「医師を呼んで」、「トイレ介助」、「入浴介助」であっても良い。

【0058】

図６に示すように、対象者入力部４１は、応援要請の対象者の属性を、例えばプルダウンメニューによって、選択式で入力操作可能に構成されている。即ち、タッチパネル２０は、応援要請の対象者の属性を入力操作可能に構成されている。

【0059】

対象者入力部４１に入力可能な属性の選択肢は特に限定されないが、例えば図６に示すように、「未選択」、「管理職員」、「女性」、「男性」、「看護師」であっても良い。

【0060】

また、ここでの「属性」は、例えば、特定の人物であること（例えば、「特定のＸさんまたはＹさんであること」）であっても良い。

【0061】

要請ボタン４２が操作されると、図３に示すように、タッチパネル２０から所定の信号が制御部２２へ送られる。これにより、応援要請の入力操作が受け付けられる。当該信号は、内容入力部４０及び対象者入力部４１に行われた入力操作の内容を示す情報を含んでいる。要請送信部２３は、当該信号に基づいて、要請情報を生成する。要請情報とは、応援要請を示す情報である。

【0062】

このように、端末２は、応援要請の入力操作を受け付けるタッチパネル２０を有している。尚、本発明に係る「応援要請の入力操作」は、具体的には、内容入力部４０と対象者入力部４１と要請ボタン４２とを操作することであっても良いし、要請ボタン４２を操作することのみであっても良い。

【0063】

ここで、図３に示すように、要請送信部２３は、内容情報生成部２５及び属性情報生成部２６を有している。内容情報生成部２５は、内容入力部４０への入力操作に基づいて、内容情報を生成する。内容情報とは、応援の内容を示す情報である。要請送信部２３により生成される要請情報には、内容情報が含まれている。

【0064】

このように、端末２は、タッチパネル２０への入力操作に基づいて、応援の内容を示す内容情報を生成する内容情報生成部２５を有している。また、要請情報は、内容情報を含んでいる。

【0065】

属性情報生成部２６は、対象者入力部４１への入力操作に基づいて、属性情報を生成する。属性情報とは、応援要請の対象者の属性を示す情報である。要請送信部２３により生成される要請情報には、属性情報が含まれている。

【0066】

このように、端末２は、タッチパネル２０への入力操作に基づいて、属性を示す属性情報を生成する属性情報生成部２６を有している。また、要請情報は、属性情報を含んでいる。

【0067】

また、特に限定されないが、本実施形態において、要請情報は、要請位置情報を含んでいる。要請位置情報とは、応援要請の入力操作が行われた時点での端末２の位置（例えば、「１Ｆ東トイレ」等）を示す情報である。要請送信部２３は、例えばＧＰＳ（グローバル・ポジショニング・システム）やビーコン等を利用して端末２の位置を算出することにより、要請位置情報を生成しても良い。

【0068】

また、上述の要請位置情報に基づいて、属性情報が自動的に生成されても良い。例えば、要請位置情報及び他の端末２の現在位置を示す情報に基づいて、他の端末２のうち、要請位置情報により示される位置から最も近くに位置する端末２が特定されると共に、特定された端末２のユーザーＥの人物名が属性情報によって示されるように構成されていても良い。

【0069】

また、特に限定されないが、要請送信部２３により生成される要請情報には、要請者情報及び要請時刻情報が含まれていても良い。要請者情報とは、応援要請の入力操作を行った人物（ユーザーＥ）を示す情報である。要請時刻情報とは、応援要請の入力操作が行われた時刻を示す情報である。即ち、要請情報は、応援要請の入力操作を行った人物を示す情報である要請者情報と、応援要請の入力操作が行われた時刻を示す情報である要請時刻情報と、を含んでいても良い。

【0070】

要請送信部２３は、生成した要請情報を外部へ送信する。本実施形態においては、図３に示すように、要請送信部２３は、要請情報を他の全ての端末２へ送信する。ただし、本発明はこれに限定されない。要請送信部２３は、要請情報を、他の一部の端末２へ送信しても良いし、端末２以外（例えば管理サーバ等）へ送信しても良い。

【0071】

このように、端末２は、応援要請を示す情報である要請情報を外部へ送信する要請送信部２３を有している。

【0072】

図３に示すように、要請受信部２４は、他の端末２から送信された要請情報を受信するように構成されている。尚、要請受信部２４は、他の端末２から要請情報を直接受信しても良いし、管理サーバ等を介して受信しても良い。

【0073】

図３に示す例では、第１端末２Ａの要請送信部２３から、要請情報が送信されている。当該要請情報は、第２端末２Ｂ及び第３端末２Ｃにおける要請受信部２４により受信される。

【0074】

このように、端末２は、他の端末２から送信された要請情報を受信する要請受信部２４を有している。

【0075】

尚、状態検知部４、状態送信部５、状態受信部２１、制御部２２、及び、制御部２２に含まれる要請送信部２３等の各機能部は、マイクロコンピュータ等の物理的な装置であっても良いし、ソフトウェアにおける機能部であっても良い。例えば、制御部２２に含まれる各機能部に対応するプログラムを図示しないＲＯＭや不揮発性メモリに記憶しておき、それらプログラムをＣＰＵにロードして実行することにより、各機能部に対応するプロセスが実行される構成であっても良い。

【0076】

〔応援意思〕
端末２は、応援要請に対する応援意思の入力操作を受け付け可能に構成されている。尚、応援意思とは、応援を行う意思である。以下では、応援意思の入力に関する構成について詳述する。

【0077】

図３に示すように、制御部２２は、意思送信部２７及び意思受信部２８を有している。また、端末２は、上述の要請情報を受信すると、当該要請情報に基づいて、タッチパネル２０に、意思入力画面を表示するように構成されている。例えば、図７においては、第２端末２Ｂ及び第３端末２Ｃのタッチパネル２０に、意思入力画面が表示されている。

【0078】

図７に示すように、意思入力画面には、詳細情報表示部４３及び応援ボタン４４が含まれている。

【0079】

詳細情報表示部４３には、要請情報に基づいて、応援要請の詳細な情報が表示される。図７に示す例では、詳細情報表示部４３に、上述の要請位置情報により示される位置（「１Ｆ東トイレ」）と、当該位置とユーザーＥとの距離の短さの順位（例えば、自身の端末２が要請情報を受信した複数のユーザーＥの中での順位）を示す情報（「あなたが１番目に最寄りです！」等）と、内容情報により示される応援の内容（「車椅子が必要です」）と、が表示されている。

【0080】

尚、詳細情報表示部４３における表示内容は、特に限定されない。詳細情報表示部４３に、上述の属性情報により示される属性が表示されても良いし、上述の要請者情報や要請時刻情報が表示されても良い。

【0081】

応援ボタン４４が操作されると、図３に示すように、タッチパネル２０から所定の信号が制御部２２へ送られる。これにより、応援要請に対する応援意思の入力操作が受け付けられる。意思送信部２７は、当該信号に基づいて、意思情報を生成する。意思情報とは、応援意思を示す情報である。

【0082】

このように、端末２は、応援要請に対する応援意思の入力操作を受け付けるタッチパネル２０を有している。尚、応援ボタン４４を操作することは、本発明に係る「応援意思の入力操作」に相当する。

【0083】

本実施形態において、意思送信部２７により生成される意思情報には、応援人物情報が含まれている。応援人物情報とは、応援意思の入力操作を行った人物（ユーザーＥ）を示す情報である。即ち、意思情報は、応援意思の入力操作を行った人物を示す情報である応援人物情報を含んでいる。

【0084】

意思送信部２７は、生成した意思情報を外部へ送信する。本実施形態においては、図３に示すように、意思送信部２７は、意思情報を他の全ての端末２へ送信する。ただし、本発明はこれに限定されない。意思送信部２７は、意思情報を、他の一部の端末２へ送信しても良いし、端末２以外（例えば管理サーバ等）へ送信しても良い。

【0085】

このように、端末２は、応援意思を示す情報である意思情報を外部へ送信する意思送信部２７を有している。

【0086】

図３に示すように、意思受信部２８は、他の端末２から送信された意思情報を受信するように構成されている。尚、意思受信部２８は、他の端末２から意思情報を直接受信しても良いし、管理サーバ等を介して受信しても良い。

【0087】

図３に示す例では、第２端末２Ｂの意思送信部２７から、意思情報が送信されている。当該意思情報は、第１端末２Ａ及び第３端末２Ｃにおける意思受信部２８により受信される。

【0088】

このように、端末２は、他の端末２から送信された意思情報を受信する意思受信部２８を有している。

【0089】

〔応援完了〕
端末２は、応援要請に対する応援完了の入力操作を受け付け可能に構成されている。以下では、応援完了の入力に関する構成について詳述する。

【0090】

図３に示すように、制御部２２は、完了送信部３０及び完了受信部３１を有している。また、複数の端末２のうちの何れかが応援意思の入力操作を受け付けると、各端末２は、第１応援中画面、第２応援中画面、第３応援中画面のうちの何れかをタッチパネル２０に表示する。例えば、図８においては、第１端末２Ａのタッチパネル２０に第１応援中画面が表示され、第２端末２Ｂのタッチパネル２０に第２応援中画面が表示され、第３端末２Ｃのタッチパネル２０に第３応援中画面が表示されている。

【0091】

図８に示すように、第１応援中画面、第２応援中画面、第３応援中画面には、応援詳細表示部４５が含まれている。応援詳細表示部４５には、要請情報及び意思情報に基づいて、行われている（または行われる予定の）応援の詳細な情報が表示される。図８に示す例では、応援詳細表示部４５に、上述の要請位置情報により示される位置（「１Ｆ東トイレ」）と、応援人物情報（「職員Ｙさん応援中」等）と、が表示されている。尚、応援詳細表示部４５における表示内容は、特に限定されない。

【0092】

また、図８に示すように、第２応援中画面には、完了ボタン４６が含まれている。完了ボタン４６が操作されると、図３に示すように、タッチパネル２０から所定の信号が制御部２２へ送られる。これにより、応援要請に対する応援完了の入力操作が受け付けられる。完了送信部３０は、当該信号に基づいて、完了情報を生成する。完了情報とは、応援要請に対する応援完了を示す情報である。

【0093】

このように、端末２は、応援要請に対する応援完了の入力操作を受け付けるタッチパネル２０を有している。尚、完了ボタン４６を操作することは、本発明に係る「応援完了の入力操作」に相当する。

【0094】

完了送信部３０は、生成した完了情報を外部へ送信する。本実施形態においては、図３に示すように、完了送信部３０は、完了情報を他の全ての端末２へ送信する。ただし、本発明はこれに限定されない。完了送信部３０は、完了情報を、他の一部の端末２へ送信しても良いし、端末２以外（例えば管理サーバ等）へ送信しても良い。

【0095】

このように、端末２は、応援完了を示す情報である完了情報を外部へ送信する完了送信部３０を有している。

【0096】

図３に示すように、完了受信部３１は、他の端末２から送信された完了情報を受信するように構成されている。尚、完了受信部３１は、他の端末２から完了情報を直接受信しても良いし、管理サーバ等を介して受信しても良い。

【0097】

図３に示す例では、第２端末２Ｂの完了送信部３０から、完了情報が送信されている。当該完了情報は、第１端末２Ａ及び第３端末２Ｃにおける完了受信部３１により受信される。

【0098】

〔応援要請のキャンセル〕
端末２は、応援要請の入力操作を受け付けた後、当該応援要請のキャンセルの入力操作を受け付け可能に構成されている。以下では、応援要請のキャンセルに関する構成について詳述する。

【0099】

図３に示すように、制御部２２は、キャンセル送信部３２及びキャンセル受信部３３を有している。また、端末２が応援要請の入力操作を受け付けると、当該端末２は、上述の要請情報に基づいて、タッチパネル２０に、要請中画面を表示する。例えば、図７においては、第１端末２Ａのタッチパネル２０に、要請中画面が表示されている。

【0100】

図７に示すように、要請中画面には、要請詳細表示部４７及びキャンセルボタン４８が含まれている。要請詳細表示部４７には、要請情報に基づいて、応援要請の詳細な情報が表示される。図７に示す例では、要請詳細表示部４７に、上述の要請位置情報により示される位置（「１Ｆ東トイレ」）と、内容情報により示される応援の内容（「車椅子が必要です」）と、が表示されている。

【0101】

尚、要請詳細表示部４７における表示内容は、特に限定されない。要請詳細表示部４７に、上述の属性情報により示される属性が表示されても良いし、上述の要請者情報や要請時刻情報が表示されても良い。

【0102】

キャンセルボタン４８が操作されると、図３に示すように、タッチパネル２０から所定の信号が制御部２２へ送られる。これにより、応援要請のキャンセルの入力操作が受け付けられる。キャンセル送信部３２は、当該信号に基づいて、キャンセル情報を生成する。キャンセル情報とは、応援要請のキャンセルを示す情報である。

【0103】

このように、端末２は、当該端末２が応援要請の入力操作を受け付けた後、当該応援要請のキャンセルの入力操作を受け付けるタッチパネル２０を有している。尚、キャンセルボタン４８を操作することは、本発明に係る「キャンセルの入力操作」に相当する。

【0104】

キャンセル送信部３２は、生成したキャンセル情報を外部へ送信する。本実施形態においては、図３に示すように、キャンセル送信部３２は、キャンセル情報を他の全ての端末２へ送信する。ただし、本発明はこれに限定されない。キャンセル送信部３２は、キャンセル情報を、他の一部の端末２へ送信しても良いし、端末２以外（例えば管理サーバ等）へ送信しても良い。

【0105】

このように、端末２は、キャンセルを示す情報であるキャンセル情報を外部へ送信するキャンセル送信部３２を有している。

【0106】

図３に示すように、キャンセル受信部３３は、他の端末２から送信されたキャンセル情報を受信するように構成されている。尚、キャンセル受信部３３は、他の端末２からキャンセル情報を直接受信しても良いし、管理サーバ等を介して受信しても良い。

【0107】

図３に示す例では、第１端末２Ａのキャンセル送信部３２から、キャンセル情報が送信されている。当該キャンセル情報は、第２端末２Ｂ及び第３端末２Ｃにおけるキャンセル受信部３３により受信される。

【0108】

このように、端末２は、他の端末２から送信されたキャンセル情報を受信するキャンセル受信部３３を有している。

【0109】

〔応援処理フロー〕
各端末２における制御部２２は、図９に示す応援処理フローに従って、応援要請に関する処理を行うように構成されている。

【0110】

この応援処理フローが開始されると、まず、ステップＳ０１の処理が実行される。ステップＳ０１では、上述の要請入力画面（図４から図６参照）がタッチパネル２０に表示される。その後、処理はステップＳ０２へ移行する。

【0111】

ステップＳ０２では、他の端末２から送信された要請情報を要請受信部２４が受信したか否かが、制御部２２により判定される。他の端末２から送信された要請情報を要請受信部２４が受信していない場合（図９のステップＳ０２にて「Ｎｏ」）、処理はステップＳ０３へ移行する。他の端末２から送信された要請情報を要請受信部２４が受信した場合（図９のステップＳ０２にて「Ｙｅｓ」）、処理はステップＳ１４へ移行する。

【0112】

ステップＳ０３では、タッチパネル２０が応援要請の入力操作を受け付けたか否かが、制御部２２により判定される。タッチパネル２０が応援要請の入力操作を受け付けていない場合（図９のステップＳ０３にて「Ｎｏ」）、処理はステップＳ０２へ戻る。即ち、他の端末２から送信された要請情報を要請受信部２４が受信しておらず、且つ、タッチパネル２０が応援要請の入力操作を受け付けていない間、タッチパネル２０の表示は要請入力画面のままで維持されると共に、処理はステップＳ０２及びステップＳ０３を繰り返すこととなる。

【0113】

タッチパネル２０が応援要請の入力操作を受け付けた場合（図９のステップＳ０３にて「Ｙｅｓ」）、処理はステップＳ０４へ移行する。

【0114】

ステップＳ０４では、要請送信部２３が要請情報を生成する。そして、要請送信部２３は、生成した要請情報を他の全ての端末２へ送信する。その後、処理はステップＳ０５へ移行する。

【0115】

ステップＳ０５では、上述の要請中画面（図７の第１端末２Ａのタッチパネル２０参照）がタッチパネル２０に表示される。その後、処理はステップＳ０６へ移行する。

【0116】

ステップＳ０６では、タッチパネル２０が応援要請のキャンセルの入力操作を受け付けたか否かが、制御部２２により判定される。タッチパネル２０が応援要請のキャンセルの入力操作を受け付けた場合（より具体的には、要請中画面のキャンセルボタン４８が操作された場合）（図９のステップＳ０６にて「Ｙｅｓ」）、処理はステップＳ０７へ移行する。タッチパネル２０が応援要請のキャンセルの入力操作を受け付けていない場合（より具体的には、要請中画面のキャンセルボタン４８が操作されていない場合）（図９のステップＳ０６にて「Ｎｏ」）、処理はステップＳ０９へ移行する。

【0117】

ステップＳ０７では、キャンセル送信部３２がキャンセル情報を生成する。そして、キャンセル送信部３２は、生成したキャンセル情報を他の全ての端末２へ送信する。その後、処理はステップＳ０８へ移行する。

【0118】

ステップＳ０８では、図１０に示す第１キャンセル画面がタッチパネル２０に表示される。第１キャンセル画面は、応援要請がキャンセルされたことを示す情報を含んでいる。特に限定されないが、第１キャンセル画面は、応援要請がキャンセルされたことを示すメッセージ（例えば「応援要請がキャンセルされました」）を含んでいても良い。ステップＳ０８の後、この応援処理フローは一旦終了する。

【0119】

ステップＳ０９では、ステップＳ０４で送信された要請情報により示される応援要請に関する意思情報を意思受信部２８が受信したか否かが、制御部２２により判定される。当該意思情報を意思受信部２８が受信していない場合（図９のステップＳ０９にて「Ｎｏ」）、処理はステップＳ０６へ戻る。即ち、タッチパネル２０が応援要請のキャンセルの入力操作を受け付けておらず、且つ、当該意思情報を意思受信部２８が受信していない間、タッチパネル２０の表示は要請中画面のままで維持されると共に、処理はステップＳ０６及びステップＳ０９を繰り返すこととなる。

【0120】

当該意思情報を意思受信部２８が受信した場合（図９のステップＳ０９にて「Ｙｅｓ」）、処理はステップＳ１０へ移行する。

【0121】

図３に示すように、制御部２２は意思報知部３４を有している。図９のステップＳ１０では、意思報知部３４が、端末２のユーザーＥに、意思受信部２８が受信した意思情報に基づく報知を行う。より具体的には、意思報知部３４は、意思情報に基づいて、タッチパネル２０に、上述の第１応援中画面（図８の第１端末２Ａのタッチパネル２０参照）を表示させる。タッチパネル２０に第１応援中画面を表示させることは、本発明に係る「意思情報に基づく報知」に相当する。

【0122】

尚、本発明はこれに限定されない。意思報知部３４は、意思情報に基づいて、端末２から発生する音や、端末２の振動等による報知を行うように構成されていても良い。

【0123】

以上で説明した構成により、意思報知部３４は、端末２が応援要請の入力操作を受け付け（図９のステップＳ０３にて「Ｙｅｓ」）、且つ、当該応援要請に関する意思情報を受信した場合（図９のステップＳ０９にて「Ｙｅｓ」）、当該端末２のユーザーＥに当該意思情報に基づく報知を行う。

【0124】

即ち、端末２は、当該端末２が応援要請の入力操作を受け付け、且つ、当該応援要請に関する意思情報を受信した場合、当該端末２のユーザーＥに当該意思情報に基づく報知を行う意思報知部３４を有している。

【0125】

尚、図８に示すように、第１応援中画面には、キャンセルボタン４８が含まれている。第１応援中画面のキャンセルボタン４８の機能は、要請中画面のキャンセルボタン４８の機能と同一である。

【0126】

ステップＳ１０の後、処理はステップＳ１１へ移行する。ステップＳ１１では、タッチパネル２０が応援要請のキャンセルの入力操作を受け付けたか否かが、制御部２２により判定される。タッチパネル２０が応援要請のキャンセルの入力操作を受け付けた場合（より具体的には、第１応援中画面のキャンセルボタン４８が操作された場合）（図９のステップＳ１１にて「Ｙｅｓ」）、処理はステップＳ０７へ移行する。タッチパネル２０が応援要請のキャンセルの入力操作を受け付けていない場合（より具体的には、第１応援中画面のキャンセルボタン４８が操作されていない場合）（図９のステップＳ１１にて「Ｎｏ」）、処理はステップＳ１２へ移行する。

【0127】

ステップＳ１２では、ステップＳ０４で送信された要請情報により示される応援要請に関する完了情報を完了受信部３１が受信したか否かが、制御部２２により判定される。当該完了情報を完了受信部３１が受信していない場合（図９のステップＳ１２にて「Ｎｏ」）、処理はステップＳ１１へ戻る。即ち、タッチパネル２０が応援要請のキャンセルの入力操作を受け付けておらず、且つ、当該完了情報を完了受信部３１が受信していない間、タッチパネル２０の表示は第１応援中画面のままで維持されると共に、処理はステップＳ１１及びステップＳ１２を繰り返すこととなる。

【0128】

当該完了情報を完了受信部３１が受信した場合（図９のステップＳ１２にて「Ｙｅｓ」）、処理はステップＳ１３へ移行する。

【0129】

ステップＳ１３では、第１完了画面がタッチパネル２０に表示される。例えば、図１１においては、第１端末２Ａ及び第３端末２Ｃのタッチパネル２０に第１完了画面が表示されている。尚、図１１においては、第２端末２Ｂのタッチパネル２０に第２完了画面が表示されている。

【0130】

図１１に示すように、第１完了画面及び第２完了画面には、完了詳細表示部４９が含まれている。完了詳細表示部４９には、要請情報、意思情報、完了情報に基づいて、完了した応援の詳細な情報が表示される。図１１に示す例では、完了詳細表示部４９に、上述の要請位置情報により示される位置（「１Ｆ東トイレ」）と、応援人物情報（「職員Ｙさん対応済」等）と、が表示されている。尚、完了詳細表示部４９における表示内容は、特に限定されない。

【0131】

ステップＳ１３の後、この応援処理フローは一旦終了する。

【0132】

ステップＳ１４では、ステップＳ０２で受信した要請情報に基づいて、タッチパネル２０に、上述の意思入力画面（図７の第２端末２Ｂ及び第３端末２Ｃのタッチパネル２０参照）が表示される。その後、処理はステップＳ１５へ移行する。

【0133】

ステップＳ１５では、ステップＳ０２で受信した要請情報に関するキャンセル情報をキャンセル受信部３３が受信したか否かが、制御部２２により判定される。当該キャンセル情報をキャンセル受信部３３が受信した場合（図９のステップＳ１５にて「Ｙｅｓ」）、処理はステップＳ１６へ移行する。当該キャンセル情報をキャンセル受信部３３が受信していない場合（図９のステップＳ１５にて「Ｎｏ」）、処理はステップＳ１７へ移行する。

【0134】

図３に示すように、制御部２２は、キャンセル処理部３５を有している。図９のステップＳ１６では、ステップＳ０２で受信した要請情報とステップＳ１５で受信したキャンセル情報とに基づいて、キャンセル処理部３５が、第２キャンセル画面（図１２参照）をタッチパネル２０に表示させる。これにより、タッチパネル２０の表示は、意思入力画面から第２キャンセル画面に切り替わることとなる。

【0135】

図１２に示すように、第２キャンセル画面は、上述の意思入力画面と同様に、詳細情報表示部４３及び応援ボタン４４を含んでいる。ただし、第２キャンセル画面の応援ボタン４４は、操作できない状態（例えばグレーアウトした状態）になっている。このように、キャンセル処理部３５は、キャンセル受信部３３がキャンセル情報を受信した場合、端末２におけるタッチパネル２０を、応援意思の入力操作を受け付けない状態にする。

【0136】

即ち、端末２は、キャンセル情報を受信した場合、当該端末２におけるタッチパネル２０を、応援意思の入力操作を受け付けない状態にするキャンセル処理部３５を有している。

【0137】

ステップＳ１６の後、この応援処理フローは一旦終了する。

【0138】

ステップＳ１７では、ステップＳ０２で受信した要請情報により示される応援要請に関する、他の端末２から送信された意思情報を意思受信部２８が受信したか否かが、制御部２２により判定される。当該意思情報を意思受信部２８が受信していない場合（図９のステップＳ１７にて「Ｎｏ」）、処理はステップＳ１８へ移行する。当該意思情報を意思受信部２８が受信した場合（図９のステップＳ１７にて「Ｙｅｓ」）、処理はステップＳ２６へ移行する。

【0139】

ステップＳ１８では、タッチパネル２０が応援意思の入力操作を受け付けたか否かが、制御部２２により判定される。タッチパネル２０が応援意思の入力操作を受け付けていない場合（より具体的には、意思入力画面の応援ボタン４４が操作されていない場合）（図９のステップＳ１８にて「Ｎｏ」）、処理はステップＳ１５へ戻る。即ち、ステップＳ０２で受信した要請情報に関して、キャンセル情報をキャンセル受信部３３が受信しておらず、且つ、他の端末２から送信された意思情報を意思受信部２８が受信しておらず、且つ、タッチパネル２０が応援意思の入力操作を受け付けていない間、タッチパネル２０の表示は意思入力画面のままで維持されると共に、処理はステップＳ１５、ステップＳ１７、ステップＳ１８を繰り返すこととなる。

【0140】

タッチパネル２０が応援意思の入力操作を受け付けた場合（より具体的には、意思入力画面の応援ボタン４４が操作された場合）（図９のステップＳ１８にて「Ｙｅｓ」）、処理はステップＳ１９へ移行する。

【0141】

ステップＳ１９では、意思送信部２７が意思情報を生成する。そして、意思送信部２７は、生成した意思情報を他の全ての端末２へ送信する。その後、処理はステップＳ２０へ移行する。

【0142】

ステップＳ２０では、上述の第２応援中画面（図８の第２端末２Ｂのタッチパネル２０参照）がタッチパネル２０に表示される。その後、処理はステップＳ２１へ移行する。

【0143】

ステップＳ２１では、ステップＳ０２で受信した要請情報に関するキャンセル情報をキャンセル受信部３３が受信したか否かが、制御部２２により判定される。当該キャンセル情報をキャンセル受信部３３が受信した場合（図９のステップＳ２１にて「Ｙｅｓ」）、処理はステップＳ２５へ移行する。当該キャンセル情報をキャンセル受信部３３が受信していない場合（図９のステップＳ２１にて「Ｎｏ」）、処理はステップＳ２２へ移行する。

【0144】

ステップＳ２２では、タッチパネル２０が応援完了の入力操作を受け付けたか否かが、制御部２２により判定される。タッチパネル２０が応援完了の入力操作を受け付けていない場合（より具体的には、第２応援中画面の完了ボタン４６が操作されていない場合）（図９のステップＳ２２にて「Ｎｏ」）、処理はステップＳ２１へ戻る。即ち、ステップＳ０２で受信した要請情報に関して、キャンセル情報をキャンセル受信部３３が受信しておらず、且つ、タッチパネル２０が応援完了の入力操作を受け付けていない間、タッチパネル２０の表示は第２応援中画面のままで維持されると共に、処理はステップＳ２１及びステップＳ２２を繰り返すこととなる。

【0145】

タッチパネル２０が応援完了の入力操作を受け付けた場合（より具体的には、第２応援中画面の完了ボタン４６が操作された場合）（図９のステップＳ２２にて「Ｙｅｓ」）、処理はステップＳ２３へ移行する。

【0146】

ステップＳ２３では、完了送信部３０が完了情報を生成する。そして、完了送信部３０は、生成した完了情報を他の全ての端末２へ送信する。その後、処理はステップＳ２４へ移行する。

【0147】

ステップＳ２４では、上述の第２完了画面（図１１の第２端末２Ｂのタッチパネル２０参照）がタッチパネル２０に表示される。その後、この応援処理フローは一旦終了する。

【0148】

図３に示すように、制御部２２はキャンセル報知部３６を有している。図９のステップＳ２５では、キャンセル報知部３６が、端末２のユーザーＥに、キャンセル受信部３３が受信したキャンセル情報に基づく報知を行う。より具体的には、キャンセル報知部３６は、キャンセル情報に基づいて、タッチパネル２０に、上述の第１キャンセル画面（図１０参照）を表示させる。タッチパネル２０に第１キャンセル画面を表示させることは、本発明に係る「キャンセル情報に基づく報知」に相当する。

【0149】

尚、本発明はこれに限定されない。キャンセル報知部３６は、キャンセル情報に基づいて、端末２から発生する音や、端末２の振動等による報知を行うように構成されていても良い。

【0150】

以上で説明した構成により、キャンセル報知部３６は、端末２が応援意思の入力操作を受け付け（図９のステップＳ１８にて「Ｙｅｓ」）、且つ、当該応援意思に関するキャンセル情報を受信した場合（図９のステップＳ２１にて「Ｙｅｓ」）、当該端末２のユーザーＥに当該キャンセル情報に基づく報知を行う。

【0151】

即ち、端末２は、当該端末２が応援意思の入力操作を受け付け、且つ、当該応援意思に関するキャンセル情報を受信した場合、当該端末２のユーザーＥに当該キャンセル情報に基づく報知を行うキャンセル報知部３６を有している。

【0152】

図３に示すように、制御部２２は連携処理部３７を有している。図９のステップＳ２６では、ステップＳ０２で受信した要請情報とステップＳ１７で受信した意思情報とに基づいて、連携処理部３７が、上述の第３応援中画面（図８の第３端末２Ｃのタッチパネル２０参照）をタッチパネル２０に表示させる。これにより、タッチパネル２０の表示は、意思入力画面から第３応援中画面に切り替わることとなる。

【0153】

図８に示すように、第３応援中画面は、応援ボタン４４を含んでいない。そのため、タッチパネル２０に第３応援中画面が表示されているとき、タッチパネル２０は、応援意思の入力操作を受け付けない状態である。このように、連携処理部３７は、要請受信部２４が要請情報を受信し、且つ、意思受信部２８が意思情報を受信した場合、端末２におけるタッチパネル２０を、応援意思の入力操作を受け付けない状態にする。

【0154】

即ち、端末２は、要請情報を受信し、且つ、当該要請情報に関する意思情報を受信した場合、当該端末２におけるタッチパネル２０を、応援意思の入力操作を受け付けない状態にする連携処理部３７を有している。

【0155】

ステップＳ２６の後、処理はステップＳ２７へ移行する。

【0156】

ステップＳ２７では、ステップＳ０２で受信した要請情報に関するキャンセル情報をキャンセル受信部３３が受信したか否かが、制御部２２により判定される。当該キャンセル情報をキャンセル受信部３３が受信した場合（図９のステップＳ２７にて「Ｙｅｓ」）、処理はステップＳ０８へ移行する。当該キャンセル情報をキャンセル受信部３３が受信していない場合（図９のステップＳ２７にて「Ｎｏ」）、処理はステップＳ２８へ移行する。

【0157】

ステップＳ２８では、ステップＳ０２で受信した要請情報に関する完了情報を完了受信部３１が受信したか否かが、制御部２２により判定される。当該完了情報を完了受信部３１が受信していない場合（図９のステップＳ２８にて「Ｎｏ」）、処理はステップＳ２７へ戻る。即ち、ステップＳ０２で受信した要請情報に関するキャンセル情報をキャンセル受信部３３が受信しておらず、且つ、当該完了情報を完了受信部３１が受信していない間、タッチパネル２０の表示は第３応援中画面のままで維持されると共に、処理はステップＳ２７及びステップＳ２８を繰り返すこととなる。

【0158】

当該完了情報を完了受信部３１が受信した場合（図９のステップＳ２８にて「Ｙｅｓ」）、処理はステップＳ１３へ移行する。

【0159】

尚、以上で説明した応援処理フローは、各端末２において、それぞれ個別に実行される。例えば、第１端末２Ａにおいて、ステップＳ０１、ステップＳ０２、ステップＳ０３、ステップＳ０４の順に処理が進んだ場合、第２端末２Ｂ及び第３端末２Ｃにおいては、ステップＳ０１、ステップＳ０２、ステップＳ１４の順に処理が進むケースが想定される。

【0160】

〔応援要請に関する処理の具体例〕
以下では、応援要請に関する処理の流れについて、具体例を挙げて説明する。この例では、図１に示すように、第１ユーザーＥＡが第１端末２Ａを所持しており、第２ユーザーＥＢが第２端末２Ｂを所持しており、第３ユーザーＥＣが第３端末２Ｃを所持しているものとする。第１ユーザーＥＡ、第２ユーザーＥＢ、第３ユーザーＥＣは、何れもユーザーＥである。

【0161】

まず、図１に示すように、被監視者Ｄが所定状態（例えば転倒した状態）となる。これに応じて、第１端末２Ａ、第２端末２Ｂ、第３端末２Ｃにより、発報が行われる。この例では、第１ユーザーＥＡが、被監視者Ｄの介助に向かうものとする。

【0162】

そして、第１ユーザーＥＡは、第１端末２Ａを操作して、応援要請の入力操作を行う。その結果、図７に示すように、第１端末２Ａには要請中画面が表示される（図９のステップＳ０５）と共に、第２端末２Ｂ及び第３端末２Ｃには意思入力画面が表示される（図９のステップＳ１４）。

【0163】

これにより、第２ユーザーＥＢ及び第３ユーザーＥＣは、第１ユーザーＥＡが応援を求めていることを知ることができる。

【0164】

図７に示す状態において、仮に、第１ユーザーＥＡがキャンセルボタン４８を操作すると、第１端末２Ａには第１キャンセル画面（図１０参照）が表示される（図９のステップＳ０８）と共に、第２端末２Ｂ及び第３端末２Ｃには第２キャンセル画面（図１２参照）が表示される（図９のステップＳ１６）。

【0165】

これにより、第２ユーザーＥＢ及び第３ユーザーＥＣは、第１ユーザーＥＡへの応援が不要であることを知ることができる。

【0166】

この例では、図７に示す状態において、第１ユーザーＥＡがキャンセルボタン４８を操作することなく、第２ユーザーＥＢが応援ボタン４４を操作するものとする。その結果、図８に示すように、第１端末２Ａには第１応援中画面が表示され（図９のステップＳ１０）、第２端末２Ｂには第２応援中画面が表示され（図９のステップＳ２０）、第３端末２Ｃには第３応援中画面が表示される（図９のステップＳ２６）。そして、第２ユーザーＥＢは、第１ユーザーＥＡの応援に向かう。

【0167】

これにより、第１ユーザーＥＡ及び第３ユーザーＥＣは、第２ユーザーＥＢに応援意思があることを知ることができる。

【0168】

図８に示す状態において、仮に、第１ユーザーＥＡがキャンセルボタン４８を操作すると、第１端末２Ａ及び第３端末２Ｃに第１キャンセル画面（図１０参照）が表示される（図９のステップＳ０８）と共に、第２端末２Ｂにも第１キャンセル画面（図１０参照）が表示される（図９のステップＳ２５）。

【0169】

これにより、第２ユーザーＥＢ及び第３ユーザーＥＣは、第１ユーザーＥＡへの応援が不要であることを知ることができる。

【0170】

この例では、図８に示す状態において、第１ユーザーＥＡがキャンセルボタン４８を操作することなく、第２ユーザーＥＢによる応援が完了し、第２ユーザーＥＢが完了ボタン４６を操作するものとする。これにより、図１１に示すように、第１端末２Ａ及び第３端末２Ｃには第１完了画面が表示される（図９のステップＳ１３）と共に、第２端末２Ｂには第２完了画面が表示される（図９のステップＳ２４）。

【0171】

これにより、第３ユーザーＥＣは、第１ユーザーＥＡへの応援が完了したことを知ることができる。

【0172】

以上で説明した構成によれば、応援意思を示す情報である意思情報が、端末２の外部へ送信される。そのため、例えば他の端末２が当該意思情報を受信すれば、当該意思情報を受信した端末２のユーザーＥは、自身以外のユーザーＥに応援意思があることを知ることができる。その結果、例えば応援が重複してしまう等の非効率な事態の発生を抑制できる。

【0173】

このように、以上で説明した構成によれば、ユーザーＥ（例えば第１ユーザーＥＡ）が応援要請を行い、且つ、当該応援要請に応じて他のユーザーＥ（例えば第２ユーザーＥＢ）が応援に向かう場合に、当該他のユーザーＥ（例えば第２ユーザーＥＢ）に応援意思があることを、当該他のユーザーＥ（例えば第２ユーザーＥＢ）以外のユーザーＥ（例えば第１ユーザーＥＡ及び第３ユーザーＥＣ）が知ることができる。

【0174】

〔その他の実施形態〕
（１）上記実施形態における各部材の機能をコンピュータに実現させるプログラムとして構成されていても良い。例えば、端末２にて実行されるプログラムであって、応援要請の入力操作を受け付ける要請入力機能と、要請送信部２３に対応する要請送信機能と、要請受信部２４に対応する要請受信機能と、応援要請に対する応援意思の入力操作を受け付ける意思入力機能と、意思送信部２７に対応する意思送信機能と、を端末２に実現させるプログラムとして構成されていても良い。

【0175】

この場合、端末２は、被監視者Ｄの状態を検知する状態検知部４により所定状態が検知された場合に状態検知部４による検知結果を示す情報である状態情報を受信する構成を備えていると好適である。

【0176】

（２）監視装置１（より具体的には、撮像部３、状態検知部４、状態送信部５）及び状態受信部２１が設けられていなくても良い。

【0177】

（３）各端末２は、互いに同一の構成を有していなくても良い。例えば、複数の端末２のうちの一部のみが、応援要請の入力操作を受け付け可能であり、且つ、外部への要請情報の送信が可能であっても良い。この場合、当該一部の端末２は、応援意思の入力操作を受け付け不能であり、且つ、外部への意思情報の送信が不能であっても良い。さらに、この場合、当該一部以外の端末２が、応援意思の入力操作を受け付け可能であり、且つ、外部への意思情報の送信が可能であると好適である。

【0178】

また、例えば、複数の端末２のうちの一部のみが、応援意思の入力操作を受け付け可能であり、且つ、外部への意思情報の送信が可能であっても良い。この場合、当該一部の端末２は、応援要請の入力操作を受け付け不能であり、且つ、外部への要請情報の送信が不能であっても良い。さらに、この場合、当該一部以外の端末２が、応援要請の入力操作を受け付け可能であり、且つ、外部への要請情報の送信が可能であると好適である。

【0179】

（４）第１応援中画面に完了ボタン４６が含まれていても良い。即ち、端末２のタッチパネル２０は、当該端末２が応援要請の入力操作を受け付け、当該応援要請に関する意思情報を受信した後、当該応援要請に対する応援完了の入力操作を受け付けるように構成されていても良い。

【0180】

（５）第２キャンセル画面が応援ボタン４４を含んでいなくても良い。この場合、タッチパネル２０に第２キャンセル画面が表示されることにより、タッチパネル２０は、応援意思の入力操作を受け付けない状態となる。

【0181】

（６）第３応援中画面が、操作できない状態（例えばグレーアウトした状態）の応援ボタン４４を含んでいても良い。この場合、タッチパネル２０に第３応援中画面が表示されることにより、タッチパネル２０は、応援意思の入力操作を受け付けない状態となる。

【0182】

（７）第１キャンセル画面または第２キャンセル画面に代えて、平常時用の画面（例えば待ち受け画面やホーム画面等）や要請入力画面が表示されても良い。

【0183】

（８）意思送信部２７により生成される意思情報には、応援時刻情報が含まれていても良い。応援時刻情報とは、応援意思の入力操作が行われた時刻を示す情報である。

【0184】

（９）端末２は、タッチパネル２０に代えて、ユーザーＥによる入力操作を受け付けるキーボードやボタンやマウス等の入力装置を有していても良い。この場合、当該入力装置は、本発明に係る「要請入力部」、「意思入力部」、「完了入力部」、「キャンセル入力部」に相当する。

【0185】

（１０）制御部２２が、本発明に係る「要請入力部」、「意思入力部」、「完了入力部」、「キャンセル入力部」に相当する要素を有していても良い。

【0186】

（１１）端末２は、内容情報生成部２５、属性情報生成部２６、意思受信部２８、完了送信部３０、完了受信部３１、キャンセル送信部３２、キャンセル受信部３３、意思報知部３４、キャンセル処理部３５、キャンセル報知部３６、連携処理部３７のうち一部または全部を有していなくても良い。

【0187】

（１２）内容入力部４０は、要請する応援の内容を、選択式以外の形式（例えば入力欄に文字を入力する形式）で入力操作可能に構成されていても良い。

【0188】

（１３）対象者入力部４１は、応援要請の対象者の属性を、選択式以外の形式（例えば入力欄に文字を入力する形式）で入力操作可能に構成されていても良い。

【0189】

尚、上述の実施形態（別実施形態を含む、以下同じ）で開示される構成は、矛盾が生じない限り、他の実施形態で開示される構成と組み合わせて適用することが可能である。また、本明細書において開示された実施形態は例示であって、本発明の実施形態はこれに限定されず、本発明の目的を逸脱しない範囲内で適宜改変することが可能である。

【産業上の利用可能性】

【0190】

本発明は、老人福祉施設だけではなく、医療施設や公共施設等の種々の施設に利用可能であり、また、屋外であっても利用可能である。

【符号の説明】

【0191】

２ ：端末
４ ：状態検知部
５ ：状態送信部
２０ ：タッチパネル（要請入力部、意思入力部、完了入力部、キャンセル入力部）
２３ ：要請送信部
２４ ：要請受信部
２５ ：内容情報生成部
２６ ：属性情報生成部
２７ ：意思送信部
２８ ：意思受信部
３０ ：完了送信部
３２ ：キャンセル送信部
３３ ：キャンセル受信部
３４ ：意思報知部
３５ ：キャンセル処理部
３６ ：キャンセル報知部
３７ ：連携処理部
Ａ ：監視システム
Ｄ ：被監視者
Ｅ ：ユーザー

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】