特開 2022-138320 報知装置、報知方法及びプログラム

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

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

(11)【公開番号】P2022138320

(43)【公開日】2022-09-26

(54)【発明の名称】報知装置、報知方法及びプログラム

(51)【国際特許分類】

   G16H 50/80 20180101AFI20220915BHJP

【ＦＩ】

G16H50/80

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2021038133

(22)【出願日】2021-03-10

(71)【出願人】

【識別番号】308036402

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

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】宮田 哲

(72)【発明者】

【氏名】中村 真巳

(72)【発明者】

【氏名】木下 義仁

(72)【発明者】

【氏名】三原 真哉

(72)【発明者】

【氏名】高田 昌幸

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

5L099

【Ｆターム（参考）】

5L099AA00

(57)【要約】

【課題】感染拡大のおそれを低減することが可能な報知装置、報知方法、及びプログラムを提供すること。
【解決手段】本開示にかかる報知装置は、各ユーザの体調に関する体調情報を取得する体調情報取得部２１０と、体調情報に基づいて、各ユーザの体調レベルを判定する体調レベル判定部２２０と、各ユーザの予定を示す予定情報に基づいて、各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得部２３０と、体調レベル及び存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定部２４０と、決定された報知形態に基づいて報知を制御する報知制御部２５０と、を備える。報知形態決定部２４０は、体調レベルが所定値以上であるユーザの存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、報知形態を決定する。
【選択図】図４

【特許請求の範囲】

【請求項1】

各ユーザの体調に関する体調情報を取得する体調情報取得部と、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定部と、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得部と、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定部と、
前記決定された報知形態に基づいて前記報知を制御する報知制御部と、
を備え、
前記報知形態決定部は、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定する
報知装置。

【請求項2】

前記報知形態決定部は、前記所定領域の大きさに更に基づいて前記報知形態を決定する
請求項１に記載の報知装置。

【請求項3】

前記予定情報は、前記ユーザが参加予定のイベントにおける前記ユーザの参加属性情報を含み、
前記報知形態決定部は、前記参加属性情報に更に基づいて前記報知形態を決定する
請求項１又は２に記載の報知装置。

【請求項4】

各ユーザの体調に関する体調情報を取得する体調情報取得ステップと、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定ステップと、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得ステップと、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定ステップと、
前記決定された報知形態に基づいて前記報知を制御する報知制御ステップと、
を備え、
前記報知形態決定ステップでは、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定する
報知方法。

【請求項5】

各ユーザの体調に関する体調情報を取得する体調情報取得ステップと、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定ステップと、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得ステップと、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定ステップと、
前記決定された報知形態に基づいて前記報知を制御する報知制御ステップと、
を備える報知方法をコンピュータに実行させ、
前記報知形態決定ステップでは、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定する
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、報知装置、報知方法及びプログラムに関する。

【背景技術】

【0002】

感染症に対するリスクを予測し、感染拡大を防止する技術が知られている。例えば、特許文献１は、感染原因の検出により事前に感染リスクを予測し、ユーザのスケジュール変更を行うことで、ユーザへの感染拡大を防止することが可能な感染拡大防止システムを開示する。

【0003】

特許文献１が開示する感染拡大防止システムは、感染原因を検出した感染情報を取得するセンシング部、ユーザのスケジュールを格納するスケジュール情報記憶部、及びスケジュールデータを調整するスケジュール調整部を備えている。スケジュール調整部は、センシング部により感染原因が検出されると、スケジュール情報記憶部に格納されているスケジュールデータを確認する。また、スケジュール調整部は、センシング部が感染原因を検出してから所定期間を含むスケジュールデータが存在すれば、そのスケジュールデータを所定期間以降のスケジュールとするように調整を行う。

【先行技術文献】

【特許文献】

【0004】

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

【発明の概要】

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

【0005】

例えば、オフィスビルなどに設置されるゲート装置において、ユーザの体温を測定し、測定された体温が所定値（例えば、37.5℃）未満のユーザに対してのみ通過を許可する場合を想定する。このような場合、体温が所定値以上のユーザ対してはゲートの通過が許可されないので、感染症などで発熱しているユーザのオフィスエリア内への入場を回避することができる。

【0006】

しかし、所定値を僅かに下回るような、微妙な範囲内の体温（例えば、37.0～37.4℃）のユーザに対しては、ゲートの通過が許可される。このようなユーザは、ゲート通過後に発熱し、所定値以上の体温となるおそれがある。しかし、ゲートを通過してオフィスエリア内に入場するか、発熱の可能性を考慮して入場を中止するか否かは、ユーザの意思に委ねられている。

【0007】

一旦ゲートを通過したユーザは、仮にオフィスエリア内で発熱した場合でも、再度ゲート装置の通過を試みない限りは、継続してエリア内に留まることができる。そのため、このようなユーザが感染症に感染していた場合、オフィスエリア内において感染が拡大し、感染クラスターが発生するおそれがある。

【0008】

本開示は、上述した課題を鑑み、感染拡大のおそれを低減することが可能な報知装置、報知方法、及びプログラムを提供することを目的とする。

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

【0009】

本開示にかかる報知装置は、
各ユーザの体調に関する体調情報を取得する体調情報取得部と、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定部と、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得部と、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定部と、
前記決定された報知形態に基づいて前記報知を制御する報知制御部と、
を備え、
前記報知形態決定部は、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定するものである。

【0010】

本開示にかかる報知方法は、
各ユーザの体調に関する体調情報を取得する体調情報取得ステップと、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定ステップと、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得ステップと、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定ステップと、
前記決定された報知形態に基づいて前記報知を制御する報知制御ステップと、
を備え、
前記報知形態決定ステップでは、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定するものである。

【0011】

本開示にかかるプログラムは、
各ユーザの体調に関する体調情報を取得する体調情報取得ステップと、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定ステップと、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得ステップと、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定ステップと、
前記決定された報知形態に基づいて前記報知を制御する報知制御ステップと、
を備える報知方法をコンピュータに実行させ、
前記報知形態決定ステップでは、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定するものである。

【発明の効果】

【0012】

本開示にかかる報知装置、報知方法及びプログラムは、感染拡大のおそれを低減することを可能とする。

【図面の簡単な説明】

【0013】

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

【図2】実施形態にかかる体温測定装置が行う処理の概要を示す図である。

【図3】実施形態にかかる体温測定装置の構成を示すブロック図である。

【図4】実施形態にかかる報知サーバの構成を示すブロック図である。

【図5】実施形態にかかる体調情報を示す図である。

【図6】実施形態にかかる体調レベル判定情報を示す図である。

【図7】実施形態にかかる予定情報を示す図である。

【図8】実施形態にかかる座席情報を示す図である。

【図9】実施形態にかかる存在予定位置情報を示す図である。

【図10】実施形態にかかる領域情報を示す図である。

【図11】実施形態にかかる通信端末の表示画面及び警告表示を示す図である。

【図12】実施形態において、感染リスクが高い場合の表示画面を示す図である。

【図13】実施形態において、感染リスクが低い場合の表示画面を示す図である。

【図14】実施形態にかかる報知サーバの処理を示すフローチャートである。

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

【0014】

以下、図面を参照して本開示の実施形態について説明する。図１は、本実施形態にかかる報知システム１０００の構成を示すブロック図である。報知システム１０００は、体温測定装置１００、報知サーバ（報知装置）２００、予定情報管理部３００、関連ユーザ端末４５０、及び報知部５００、を備えている。これらは、ネットワークＮを介して相互に接続されている。ネットワークＮは、例えば、インターネット又はイントラネットなどであってよい。また報知装置である報知サーバ２００が、体温測定装置１００、予定情報管理部３００、報知部５００や、ユーザインタフェースとなる入出力部（不図示）を含んで構成されていてもよく、これらの機能の一部を含んでいてもよい。

【0015】

報知システム１０００は、報知サーバ２００が体温測定装置１００及び予定情報管理部３００から情報を取得し、所定の条件に基づいて、後述する関連領域４００ごとに、又は、関連ユーザ端末４５０として、備えられる報知部５００に対して感染拡大防止に関する報知を行うことが可能なシステムである。報知システム１０００は、例えば、オフィスビル、医療機関、飲食店、又は公共施設などで用いられてよい。これらに限らず、報知システム１０００は、感染拡大リスクの低減が望まれる種々の領域において用いられてよい。

【0016】

まず、予定情報管理部３００について説明する。予定情報管理部３００は、ユーザの予定情報を管理する機能を有している。ユーザの予定情報は、ユーザが参加を予定しているイベントに関する種々の情報を含み得る。予定情報は、例えば、参加予定のイベントの内容、開催日時、及び開催場所の情報を含み得る。イベントは、例えば、会議、打ち合わせ、面談、研修、来客対応、セミナー、倉庫内作業、又は清掃作業などを含み得る。これらに限らず、イベントは会食や会合、旅行などの様々な事柄を含んでよい。イベントは、屋内で行われるものに限らず、例えば、屋外での作業や、社用車などを用いた外勤業務などを含んでもよい。またユーザの予定情報は、イベントへの参加に限らず、通常の勤務予定を含んでよい。

【0017】

予定情報管理部３００は、例えば、ユーザから予定情報の入力を受け付けて、ユーザ毎のスケジュール管理を行うことが可能なカレンダーアプリケーション又は会議予約アプリケーションなどであってよい。ユーザは、自身が使用する通信端末４５１などから、または、予定情報管理部３００に直接、予定情報管理部３００に対して予定情報を入力することで、自身のスケジュールを予定情報管理部３００が提供するカレンダー表示などにおいて管理することができる。予定情報管理部３００は、ユーザのスケジュールを他のユーザからも閲覧可能に表示する。このようにすることで、他のユーザのスケジュールや画面上に表示された表示情報を、複数のユーザ間で速やかに共有することができる。

【0018】

次に、関連領域４００について説明する。関連領域４００は、報知サーバ２００から行う報知に関連する領域である。関連領域４００は、報知サーバ２００における報知を行う対象となり得る部屋、施設、又は領域などを含み得る。関連領域４００は、例えば、オフィス内の会議室、研修室、セミナールーム、勤務スペース、食堂、倉庫、又は更衣室などを含み得る。関連領域４００は、例えば、オフィス全体やオフィスの各フロアなどの領域であってもよい。これらに限らず、関連領域４００は、間仕切りなどを用いて簡易的に区切られた領域であってもよい。また、関連領域４００は、壁や間仕切りなどが用いられていない打ち合わせスペースや作業スペースなどを含んでもよい。ユーザは、関連領域４００の各領域において、会議などのイベントを行うことができる。関連領域４００は、オフィスに限らず、校舎、店舗、病院、その他のユーザが存在する空間を含んでよい。

【0019】

関連領域４００における各領域は、その領域に存在するユーザに対する報知を行うことが可能な報知部５００を備えている。一例として、図１に示される会議室Ａを用いて説明する。会議室Ａは、報知部５００として、通信端末４０１、表示装置４０２、ランプ４０３、スピーカ４０４、及びブザー４０５の全て、または一部を備えている。報知部５００は、関連領域４００における各領域ごとに備えられる形態に限定されない。後述する関連ユーザ端末４５０（通信端末４５１）にユーザに対する報知を行う場合、関連ユーザ端末４５０（通信端末４５１）を報知部５００と見做すことができる。

【0020】

通信端末４０１は、ネットワークＮを介して、報知サーバ２００から報知に関する報知情報を受信する。通信端末４０１は、例えば、ＰＣ（Personal Computer）、スマートフォン、携帯電話、又はタブレット端末などであってよい。報知部５００は、通信端末４０１の代替として、報知サーバ２００から報知に関する報知情報を有線又は無線で受信する受信部を備えていてもよい。

【0021】

表示装置４０２は、通信端末４０１と接続され、通信端末４０１で受信された報知内容を表示する。表示装置４０２は、報知情報を示すメッセージを表示する。メッセージは、例えば、「体調不良者は、離れて着座してください」などであってよい。表示装置４０２は、液晶ディスプレイ又は有機ＥＬディスプレイなどであってよい。表示装置４０２は、通信端末４０１と一体として設けられていてもよい。表示装置４０２は、報知サーバ２００から直接表示情報を受信して、報知内容を表示してもよい。

【0022】

ランプ４０３、スピーカ４０４、及びブザー４０５は、報知サーバ２００から報知情報を受信して、それぞれの出力形態に応じて報知情報を出力することができる。ランプ４０３は、例えば、会議室Ａ内の入口近傍に設けられ、点灯又は点滅などを行うことで報知情報を出力する。ランプ４０３は、複数の色の光を点灯又は点滅可能であってよい。

【0023】

スピーカ４０４及びブザー４０５は、会議室Ａ内において報知情報を音声により出力する。スピーカ４０４は、報知情報を示すメッセージを人の音声により出力する。メッセージは、例えば、「体調不良者は、離れて着座してください」などであってよい。ブザー４０５は、報知情報を示す報知音を出力する。報知音は、音声メッセージを含まない「ピッ、ピッ」などのブザー音であってよい。

【0024】

これらは一例であり、各領域において、これ以外の報知機能が備えられていてもよい。また、これらの一部のみが各領域において備えられていてもよい。

【0025】

続いて、関連ユーザ端末４５０について説明する。関連ユーザ端末４５０は、報知サーバ２００が行う報知に関連する各ユーザが用いる通信端末４５１を含む端末群を示している。通信端末４５１は、例えば、ＰＣ、スマートフォン、携帯電話、又はタブレット端末などを含み得る。１人のユーザが複数の通信端末４５１を使用してもよい。ユーザは、通信端末４５１を用いて、予定情報管理部３００に対するスケジュールの入力、編集、又は削除などを行うことができる。

【0026】

通信端末４５１は、報知サーバ２００から報知情報を受信し、通信端末４５１が備える表示部（不図示）への表示や、スピーカ（不図示）を用いた音声出力などによって報知情報をユーザに報知する。通信端末４５１は、例えば、ユーザが参加予定の会議の開催日時又は開催場所の変更などのメールを報知情報として受信し、表示部に表示する。通信端末４５１は、予定情報管理部３００を介して報知情報を表示部に表示してもよい。例えば、通信端末４５１は、予定情報管理部３００が提供するカレンダー上に報知内容を表示してよい。

【0027】

ユーザは、表示部の内容を確認することで、自身が参加予定のイベントに関する報知情報を確認することができる。通信端末４５１は、後述する報知制御部２５０からの報知を受信してユーザに報知する、報知部５００として機能することができる。

【0028】

続いて、体温測定装置１００について説明する。図２は、体温測定装置１００が行う処理の概要を示す図である。体温測定装置１００は、例えば、ユーザがオフィスフロアや会議室に入場する際に通過するゲート装置の近傍に設置される。体温測定装置１００は、ユーザが勤務する勤務スペースに設置されてもよい。体温測定装置１００は、ユーザを撮像して、撮像画像からユーザを認識し、ユーザの認証を行う。

【0029】

また、体温測定装置１００は、ユーザの体温を測定し、測定値とユーザとを対応付けて、体温情報として報知サーバ２００に送信する。各ユーザの体温情報は、報知サーバ２００において、ユーザを識別するユーザＩＤや測定日時などと対応付けて体調情報２６１として記憶される。体温情報は、体温測定装置１００においてユーザの体温が測定される度に報知サーバ２００に送信され、報知サーバ２００において蓄積される。

【0030】

ここでは、ユーザは、オフィスに勤務する社員であるものとして説明を行う。体温測定装置１００は、ユーザがゲート装置を通過する度にユーザの体温測定を行う。例えば、体温測定装置１００は、ユーザの朝の出勤時に測定を行う。また、これに加えて、夕方などの退勤時、会議室への入退室時、または勤務中の所定期間ごとに、更に体温測定を行うこととしてもよい。ユーザの体温を定点観測することにより、ユーザの体温の上昇及び下降の傾向を把握することができる。

【0031】

図３を用いて体温測定装置１００の構成を説明する。図３は、体温測定装置１００の構成を示すブロック図である。体温測定装置１００は、撮像部１１０、抽出部１２０、認証部１３０、赤外線撮像部１４０、体温測定部１５０、通信部１６０、及び表示部１７０を備えている。

【0032】

撮像部１１０は、所定の方向からユーザの顔領域を含む領域を撮像して画像データを取得する。撮像部１１０は、例えば、撮像レンズ及びＣＣＤイメージセンサなどの撮像素子を備えたカメラなどであってよい。撮像部１１０は、人感センサ（不図示）などと連動し、体温測定装置１００の前方にユーザの存在を検知した場合にユーザを撮像してもよいし、体温測定装置１００の前方を通過するユーザを常時撮像してもよい。撮像部１１０は、取得した画像データを抽出部１２０に出力する。

【0033】

抽出部１２０は、撮像部１１０から画像データを取得して、ユーザの顔領域を抽出する。顔領域の抽出には、公知の画像認識技術が用いられてよい。また、抽出部１２０は、ユーザの顔領域からユーザの特徴点を抽出し、特徴点情報として認証部１３０に出力する。

【0034】

認証部１３０は、抽出部１２０から特徴点情報を取得し、ユーザの顔認証を行う。認証部１３０は、ユーザを識別するユーザＩＤと、ユーザの顔の特徴点情報とが対応付けて記憶された特徴点情報データベース（不図示）を参照して、ユーザの認証を行う。ユーザＩＤは、例えば、社員番号などが用いられてよい。特徴点情報データベースは、体温測定装置１００の記憶部（不図示）に記憶されていてもよいし、体温測定装置１００とは別の装置に記憶されていてもよい。例えば、特徴点情報データベースは、報知サーバ２００の記憶部２６０（後述）に記憶されていてもよい。

【0035】

認証部１３０は、認証結果を通信部１６０などに出力する。認証部１３０は、ユーザの顔認証に失敗した場合、その旨を表示部１７０に表示させてもよい。

【0036】

なお、ここでは顔認証を用いてユーザの認証を行ったが、これに限られない。体温測定装置１００は、他の認証方法を用いてユーザの認証を行ってもよい。例えば、虹彩認証を用いることで、ユーザがマスクをしているような場合にも精度よくユーザの認証を行うことができる。また、顔認証又は虹彩認証などの生体認証に限らず、社員証などを用いてユーザの認証が行われてもよい。ユーザが手動でＩＤを入力してもよい。

【0037】

赤外線撮像部１４０は、所定の方向からユーザの顔領域を含む領域を撮像し、ユーザの赤外線画像データを取得する。赤外線撮像部１４０は、例えば、赤外線サーモグラフィカメラであってよい。赤外線撮像部１４０は、撮像部１１０の機能を兼ね備えていてもよい。赤外線撮像部１４０は、撮像部１１０がユーザを撮像するのと同時にユーザを撮像してもよいし、ユーザを常時撮像してもよい。赤外線撮像部１４０は、取得した赤外線画像データを体温測定部１５０に出力する。

【0038】

体温測定部１５０は、赤外線撮像部１４０から赤外線画像データを取得して、ユーザの体温を測定する。体温測定部１５０は、例えば、抽出部１２０において抽出されたユーザの顔領域における赤外線画像データに基づいて、ユーザの体温を算出する。体温測定部１５０は、ユーザの顔の表面温度を当該ユーザの体温として算出してよい。体温測定部１５０は、測定結果とユーザＩＤとを対応付けて通信部１６０に出力する。

【0039】

通信部１６０は、ネットワークＮを介して報知サーバ２００との間で通信を行う。通信部１６０は、体温測定部１５０から取得した体温の測定結果とユーザＩＤとを対応付けて、体温情報として報知サーバ２００に送信する。通信部１６０は、ユーザの顔認証の結果などを報知サーバ２００に送信してもよい。

【0040】

表示部１７０は、ユーザの認証結果及び体温の測定結果を表示する。表示部１７０は、例えば、液晶ディスプレイ、有機ＥＬディスプレイなどを含み得る。表示部１７０は、ユーザが指などで触れることで操作可能なタッチパネルなどであってもよい。例えば、表示部１７０は、「○○さん 認証に成功しました。体温は36.0℃です。」などと表示する。ユーザは、表示部１７０の表示を確認することで、認証結果及び自身の測定体温を把握することができる。

【0041】

なお、ここでは撮像部を用いて体温の測定を行ったが、これに限られない。体温測定装置１００は、他の測定方法を用いてユーザの体温測定を行ってもよい。例えば、赤外線センサを用いてユーザの額などの温度を測定してもよい。

【0042】

続いて、報知サーバ２００の構成について説明する。図４は、報知サーバ２００の構成を示すブロック図である。同図に示されるように、報知サーバ２００は、体調情報取得部２１０、体調レベル判定部２２０、存在予定位置情報取得部２３０、報知形態決定部２４０、報知制御部２５０、及び記憶部２６０を備えている。

【0043】

体調情報取得部２１０は、例えば体温測定装置１００から、ユーザの体調に関する体調情報を取得する。体調情報は、ユーザの体温や、咳の回数、顔色などのユーザの体調に関する種々の情報が含まれてよい。体調情報には、体温測定装置１００やセンサなどを用いて取得できる客観情報と、ユーザの主観による頭痛、腹痛、だるさなどの主観情報とを含み得る。体調情報取得部２１０は、体調情報とユーザＩＤとを対応付けて、体調情報２６１として記憶部２６０に記憶する。

【0044】

図５は、体調情報２６１の一例を示す図である。ここでは、体調情報取得部２１０は、体温測定装置１００から送信された体温情報を取得し、体温情報とユーザＩＤとを対応付けて体調情報２６１として記憶する。同図に示されるように、体調情報２６１は、ユーザＩＤ、氏名、体温の測定日時、及び測定された体温が対応付けられて記憶されている。ユーザの氏名は、ユーザの個人情報が記憶された個人情報データベース（不図示）などを参照することで取得されてよい。また、セキュリティ等の観点から、氏名が取得されなくともよい。氏名が取得されないようにすることで、体調情報を提供するユーザの心理的負担を軽減することができる。

【0045】

体調情報２６１は、体温情報に限らず、他の客観情報を含んでよい。客観情報は、例えば、ユーザの咳の回数、顔色、声色、歩行速度、又は姿勢などであってよい。これらは、体温測定装置１００で得られる画像から取得されてもよいし、体温測定装置１００以外のセンサ類を用いて取得されてもよい。

【0046】

体調情報２６１は、上記のような客観情報に限らず、体調に関するユーザの主観情報を含んでもよい。主観情報は、例えば、ユーザ自身が感じる頭痛、腹痛、ふらつき、吐き気、又はだるさなどの自覚症状を含む情報が含まれてよい。これに限らず、主観情報は、例えば、同居する家族が発熱したことなどの懸念事項などが含まれてもよい。

【0047】

ユーザは、各人の通信端末４５１から報知サーバ２００にアクセスし、体調情報取得部２１０に主観情報を入力することができる。体調情報取得部２１０は、ユーザの入力を受け付けて、ユーザＩＤと主観情報とを対応付けて、体調情報２６１として記憶する。このようにすることで、体調レベル判定部２２０において、客観情報及び主観情報の双方に基づいて、精度よく体調レベルの判定を行うことができる。

【0048】

図４に戻り説明を続ける。体調レベル判定部２２０は、体調情報取得部２１０において取得された体調情報２６１に基づいて、ユーザの体調レベルを判定する。体調レベル判定部２２０は、客観情報に主観情報を加味して体調レベルを判定してよい。

【0049】

図６は、体調レベルの判定に用いられる判定条件の一例を示す図である。体調レベル判定部２２０は、同図に示されるような判定条件を参照して、ユーザの体調レベルを判定する。ここでは、判定条件を識別する条件ＩＤ、判定項目、判定条件、及び体調レベルが対応付けられて、体調レベル判定情報２６２として予め記憶部２６０に記憶されている。体調レベル判定情報２６２は、報知サーバ２００の管理者などによって、適宜変更されてよい。

【0050】

同図に示される例では、条件ＩＤ：Ａ００１～Ａ００３においては、客観情報であるユーザの体温情報を判定条件として体調レベルが設定されている。体温情報は、体温測定装置１００から取得されたものでもよいし、ユーザの自己申告による入力値でもよい。また、条件ＩＤ：Ｘ００１及びＸ００２では、主観情報である頭痛や吐き気などの自覚症状に基づいて、体調レベルが設定されている。

【0051】

同図に示されるように、体調レベルは、例えば、判定条件を満たすか否かによって、「好調」、「やや不調」、及び「不調」の３つのレベル設定が用いられてよい。これに限らず、体調レベルは４段階以上あってもよいし、２段階であってもよい。また、各判定項目に重み付けを行い、判定における優先順位を設けてもよい。例えば、体温よりも咳の回数により大きい重み付け値を設定するとする。ユーザの体温が37.0℃未満であるが、咳の回数が10回以上である場合には、体調レベル判定部２２０は、ユーザの体調レベルを「不調」と判定する。

【0052】

また、上記に限らず、各体調レベルは、数値化されていてもよい。体調レベル判定部２２０は、ユーザが複数の条件を満たす場合に、これらの数値を合算することで体調レベルを判定してもよい。

【0053】

また、体調レベル判定部２２０は、ユーザの体温の個人差を考慮して判定を行ってもよい。例えば、ユーザは、自身の平熱を予め報知サーバ２００に登録しておく。体調レベル判定部２２０は、登録された各ユーザの平熱と、体温測定装置１００から取得された実測値との差分を用いて判定を行ってもよい。このようにすることで、体調レベル判定部２２０は、ユーザの体温にかかる個人差を考慮して体調レベルを判定することができる。

【0054】

また、体調レベル判定部２２０は、蓄積されたユーザの体温情報を参照し、所定期間における平均値と実測値との差分を用いて判定を行ってもよい。体調レベル判定部２２０は、測定日時を加味して判定を行ってもよい。例えば、午前中と比べると、夕方は比較的体温が高くなるのが一般的である。体調レベル判定部２２０は、これを考慮して判定を行ってもよい。

【0055】

図４に戻り説明を続ける。存在予定位置情報取得部２３０は、ユーザの予定を示す予定情報に基づいて、ユーザの存在予定位置を示す存在予定位置情報を取得する。ここで、予定情報は、ユーザが予定情報管理部３００に入力している情報であってよい。存在予定位置情報取得部２３０は、予定情報を予定情報管理部３００から取得し、ユーザＩＤと対応付けて、予定情報２６３として記憶部２６０に記憶する。

【0056】

図７は、予定情報２６３の一例を示す図である。同図に示されるように、予定情報２６３は、ユーザＩＤ、氏名、開催日時、内容、場所、及び参加属性が対応付けて記憶されている。ここで、内容には、会議、打ち合わせ、面談、研修、来客対応、セミナー、倉庫内作業、又は清掃作業など種々のイベントや、通常の勤務予定が含まれてよい。また場所には、会議室、研修室、セミナールームや、通常勤務時におけるユーザの存在位置（座席位置）が含まれてよい。

【0057】

存在予定位置情報取得部２３０は、所定時間毎に予定情報管理部３００から予定情報を取得し、予定情報２６３を更新する。存在予定位置情報取得部２３０は、リアルタイムで予定情報を取得してよい。

【0058】

図７に示される例において、参加属性は、ユーザがそのイベントに対してどのような立場で参加するのか、を示す参加属性情報である。参加属性情報は、例えば、司会者、聴講者、発表者、説明者、又は一般参加者などの参加形態を示す情報であってよい。インターネットなどを介したオンライン上で会議に参加するような場合、その旨を参加属性情報に含めてもよい。参加属性情報は、イベント日時や場所と共に、ユーザにより予定情報管理部３００に入力される。

【0059】

存在予定位置情報取得部２３０は、予定情報２６３を参照し、所定の時刻におけるユーザの存在予定位置（場所）を示す存在予定位置情報を取得する。また、存在予定位置情報取得部２３０は、イベント時以外の、例えば通常の勤務予定におけるユーザの存在位置（座席位置）を取得してもよい。

【0060】

図８は、ユーザの座席位置を示す座席情報２６４を示す図である。座席情報２６４は、予め記憶部２６０に記憶されているものとする。同図に示されるように、座席情報２６４は、ユーザＩＤ、氏名、所属部署、階数、及び座席番号が対応付けられて記憶されている。存在予定位置情報取得部２３０は、イベント参加時以外の時間帯においては、座席情報２６４に示される位置にユーザが存在すると推定する。

【0061】

図９は、存在予定位置情報取得部２３０が取得する存在予定位置情報の一例を示す図である。存在予定位置情報取得部２３０は、上述した予定情報２６３及び座席情報２６４に基づいて、ユーザの存在予定位置を取得し、存在予定位置情報２６５として記憶部２６０に記憶する。同図に示されるように、存在予定位置情報取得部２３０は、ユーザＩＤ、氏名、日時、及び存在予定位置を対応付けて存在予定位置情報２６５を記憶する。

【0062】

同図において、ユーザＡを例として説明する。ユーザＡの座席は、３Ｆ人事部の座席番号307の位置である（図８を参照）。また、ユーザＡは、2020/12/2の10:00に開催される会議に参加予定である（図７を参照）。したがって、存在予定位置情報取得部２３０は、会議が開催される時間帯におけるユーザＡの存在予定位置を会議室Ａとし、その前後の存在予定位置をユーザＡの座席位置として、存在予定位置情報２６５を取得する。なお、イベント等の終了時刻は、予定情報２６３に含めて予め取得されてもよいし、開始時刻から所定の時間経過後が自動設定されてもよい。

【0063】

上記のようにして、存在予定位置情報取得部２３０は、全てのユーザの存在予定位置を取得することができる。なお、存在予定位置情報取得部２３０は、上記以外の方法を用いて存在予定位置情報２６５を取得してもよい。存在予定位置情報取得部２３０は、例えば、ＧＮＳＳ(Global Navigation Satellite System)、室内ビーコン、入退室管理システム、又は監視カメラ画像などを用いて、リアルタイムにユーザの現在位置情報を取得してもよい。言い換えると、存在予定位置情報取得部２３０は、ユーザの現在存在位置を取得する形態を含んでよい。この場合、存在予定位置情報取得部２３０は、図示しない現在位置情報取得部に代替される形態であってよい。このようにすることで、より正確なユーザの位置情報をリアルタイムで取得することができる。

【0064】

図４に戻り説明を続ける。報知形態決定部２４０は、体調レベル判定部２２０において判定されたユーザの体調レベルと、存在予定位置情報取得部２３０で取得されたユーザの存在予定位置情報と、に基づいて、報知の報知形態を決定する。具体的には、報知形態決定部２４０は、体調レベルが所定値以上であるユーザの存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、報知形態を決定する。

【0065】

ここで、所定領域は、会議などのイベントが開催される場所全体、例えば各会議室や各研修室であってもよいし、その一部の領域であってよい。また通常勤務における勤務スペースのうち、フロア全体や各部屋全体、またはその一部の領域であってよい。報知形態決定部２４０は、例えば、体調レベル判定部２２０において体調が「不調」と判定されたユーザ（以下、「体調不良者」と称する）が所定の人数以上、同じ会議に参加を予定している場合、その会議室に設置された報知部５００や、会議に参加を予定しているユーザの通信端末４５１に対し、感染リスクが高いとの報知を行うことを決定する。所定の人数とは、例えば２人以上などの複数人を想定するが、後述するように所定の領域の大きさごとに設定されてよく、例えば狭い空間であれば、所定の人数は１人であってもよい。

【0066】

報知の報知形態は、報知を行う対象である報知対象と、報知対象に行う報知の内容である報知内容とを含み得る。報知対象は、イベントに関連する関連領域４００（図１を参照）における各報知部５００又は関連ユーザ端末４５０であってよい。報知形態決定部２４０は、これらのうち複数を報知対象として決定してよい。

【0067】

報知内容は、イベント開催又は参加予定ユーザに関する種々の内容を含み得る。イベント開催に関する報知内容は、イベント開催事項の変更や、その提案を含み得る。報知形態決定部２４０は、例えば、イベントの中止、開催日時の変更、開催場所の変更、参加人数の変更、又は参加ユーザの変更を行うよう、関連ユーザに提案することを決定する。関連ユーザは、例えば、そのイベントに参加するユーザ、イベント主催者、又はユーザの上長などを含んでもよい。報知形態決定部２４０は、上述した報知形態の決定において、体調不良者の人数や体調レベルに基づいて報知形態を決定することができる。例えば、体調不良者の人数が４人などの所定値以上であればイベントの中止を、３人など所定値未満であれば開催場所の変更や参加人数の変更、体調不良者が他者から離れて着座することなどを、それぞれ提案してよい。

【0068】

報知形態決定部２４０は、例えば、より広い会場に空きがあるか否かを確認して、イベントの開催場所の変更をメールなどで関連ユーザに提案するよう報知形態を決定してよい。また、報知形態決定部２４０は、体調不良者に対する会議出席の見合わせの提案、体調不良者が他者から離れて着座すること、体調不良者同士が離れて着座すること、などの提案などを行うように報知内容を決定してもよい。

【0069】

参加予定ユーザに関する報知内容は、例えば、イベント参加予定のユーザの体調などに関する情報を含んでよい。例えば、報知形態決定部２４０は、イベントの開催場所の変更の提案と共に、参加予定ユーザの体調に関する情報を関連ユーザに報知する。参加予定ユーザの体調に関する情報は、例えば、参加予定ユーザの人数、体調レベル、体温情報、自覚症状の有無、体調不良者の人数、又は全参加者に対する体調不良者の割合などを含んでよい。

【0070】

また、報知形態決定部２４０は、報知形態の決定において、所定領域の大きさに更に基づいて報知形態を決定することができる。所定領域の大きさは、イベントの開催場所の面積を予め取得し、領域情報２６６として記憶部２６０に記憶しておくことで把握されてよい。

【0071】

図１０は、領域情報２６６の一例を示す図である。報知サーバ２００の管理者などは、イベントの開催場所となり得る領域の面積情報を、各領域を識別するための領域ＩＤと対応付けて、領域情報２６６として記憶部２６０に予め記憶しておく。ここでは、領域ＩＤ、領域名、面積、及び収容人数が対応付けられて、領域情報２６６として記憶されている。

【0072】

報知形態決定部２４０は、領域情報２６６を参照し、イベント会場の領域の大きさに応じて、ユーザへの警告の度合いを異なるものにしてよい。例えば、報知形態決定部２４０は、会場の面積に応じて、許容する体調不良者の人数を予め設定する。報知形態決定部２４０は、体調不良者数が許容人数以上となる場合には、会議の中止又は延期を促し、許容人数未満の場合には着座位置を指定するなどの決定を行う。

【0073】

例えば、比較的広い会議室に２名の体調不良者が存在予定である場合、報知形態決定部２４０は、「離れて着座するように」との警告メッセージを各ユーザに通知するよう決定する。また、比較的狭い会議室に複数名の体調不良者が存在予定である場合、報知形態決定部２４０は、「会議を中止又は延期するように」との報知メッセージを各ユーザに通知するよう決定する。

【0074】

また、報知形態決定部２４０は、体調不良者が所定領域内に所定人数未満となるように、予定の調整を行うよう報知形態を決定してもよい。例えば、会場を変えることで、体調不良者数が許容人数未満に抑えられる場合、報知形態決定部２４０は、「会議の開催場所を小会議室から大会議室に変更するように」との通知を行うよう決定してもよい。

【0075】

このようにすることで、体調レベルが所定値以上となる人物が、所定人数以上、所定領域内に集合又は接近することを事前に防止し、同じ会議に体調不良の人が複数参加し、密集する状態を防止することで、より感染リスクが低くなるようにすることができる。また、単純にイベントを中止するだけでなく、開催場所の面積に応じて、より感染リスクが低くなるように予定の調整を提案することができるので、スケジュールの再調整などで生じるユーザへの影響を抑えることができる。

【0076】

なお、報知形態の決定において用いられる領域の大きさは、ユーザ又は報知サーバ２００の管理者などから入力を受け付けて、適宜調整されてよい。例えば、参加人数に対して十分に面積の大きい倉庫内において、複数人が共同で作業を行うとする。このような場合、参加者は倉庫の一部の領域に集合することとなる。また、参加者同士の会話を要する作業であれば、参加者同士が接近するおそれが高くなる。このような場合、倉庫の面積に代えて、参加者の作業スペースを実質的な領域の大きさとして設定し、報知形態が決定されてもよい。このようにすることで、報知形態決定部２４０は、ユーザの感染リスクがより低減されるように報知形態を決定することができる。

【0077】

また、イベントが、オフィスエリア外で開催される場合には、概算の面積を所定領域の大きさとして記憶させてもよい。例えば、複数のユーザが社用車に同乗して長時間過ごすような場合、適当な値を社用車の面積として領域情報２６６に記憶しておく。このようにすることで、オフィスエリア外においても感染リスクを低減することができる。

【0078】

また、報知形態決定部２４０は、予定情報２６３に含まれる参加属性情報に更に基づいて、上記の報知形態を決定してもよい。報知形態決定部２４０は、ユーザの参加属性情報に基づいて、周囲のユーザに対する感染拡大のリスクが大きいか否かを判断し、リスクが大きいと判断される場合、警告の度合いを強くするように報知形態を決定する。

【0079】

例えば、体調不良者がセミナーに参加する場合、報知形態決定部２４０は、体調不良者の参加属性が講師であるか、又は聴講者であるか、によって異なる報知形態を決定する。体調不良者の参加属性が講師である場合、報知形態決定部２４０は、参加属性が聴講者である場合と比較して、より警告の度合いを強くして報知形態を決定する。例えば、体調不良者が聴講者の場合、報知形態決定部２４０は、他のユーザと距離を空けて着座するよう体調不良者に報知するよう報知形態を決定する。また、体調不良者が講師の場合、報知形態決定部２４０は、セミナーの延期を促す、オンラインによる開催に変更する、又は参加者数を削減するなどの対応を提案するよう報知形態を決定する。

【0080】

また、報知形態決定部２４０は、予定情報管理部３００を介して報知を行うように報知形態を決定してもよい。予定情報管理部３００を介して報知することで、ユーザは、通信端末４５１を用いて、予定情報管理部３００が提供する表示画面上で報知内容を把握することができる。

【0081】

図１１は、ユーザが使用する通信端末４５１の表示部に表示される表示画面４５１１及び警告表示４５１２の一例を示す図である。予定情報管理部３００は、ユーザの予定情報を、表示画面４５１１のようにカレンダー形式で表示する。ユーザは、例えば、各予定情報をクリックすることで、各予定情報に関する詳細情報を閲覧することができる。

【0082】

同図に示されるように、報知形態決定部２４０は、感染リスクが高い場合、各予定の詳細情報において「キケン」などの警告表示４５１２を行うように報知形態を決定する。警告表示４５１２は、ユーザが直感的に危険を認識できるよう、他の文字と判別可能に色分けや強調表示がなされているとよい。報知形態決定部２４０は、警告表示４５１２がユーザによりクリックされた場合に、警告に関する詳細情報を更に表示するように報知形態を決定する。

【0083】

図１２は、警告表示４５１２に関する詳細情報４５１３が表示された表示画面の一例を示す図である。同図に示されるように、詳細情報４５１３には、警告文、クラスター発生指数、会議の参加者数、又は所定値以上の体温の出席者数などが含まれてよい。このようにすることで、会議の参加予定者は、その会議における感染拡大のリスクを詳細に把握することができる。なお、ここでは、37.0℃及び37.5℃を所定値として、それぞれの体温以上の参加者数を表示しているが、所定値はこれに限られない。

【0084】

また、報知形態決定部２４０は、感染リスクが低い場合においても、詳細情報４５１３を表示するように報知形態を決定してもよい。図１３は、感染リスクが低い場合の詳細情報４５１３の一例を示す図である。このような情報を表示することで、ユーザは、安心して会議などに参加することができる。

【0085】

なお、図１１に示される例では、表示画面４５１１と警告表示４５１２とを別のウインドウで表示させているが、これらは同一画面上に表示されてよい。例えば、スケジュールのタイトルである「10:00会議」に近接する位置に「キケン」の警告表示４５１２を表示させてもよい。このようにすることで、クリック操作を行うことなく、感染リスクを把握することができる。また、会議参加者以外のユーザにも感染の危険性を認識させることができる。

【0086】

また、ユーザの位置情報をリアルタイムで取得する場合、報知形態決定部２４０は、ユーザの現在位置に応じて、リアルタイムで報知形態を決定してもよい。その場合、報知形態決定部２４０は、ユーザの体調情報２６１又は体調レベルの度合いに応じて、報知形態を決定してよい。

【0087】

例えば、同じ会議に体調不良者が２名参加予定であるとする。報知形態決定部２４０は、２名のうちいずれかの体温が所定値（例えば、37.2℃）以上であれば、両者が10m以内に接近した場合に警告し、所定値未満であれば、30m以内に接近した場合に警告する、などというように報知形態を決定してもよい。警告を行う距離は、会議室の広さ、体調不良者の体調情報又は体調レベルなどに応じて適宜変更されてよい。

【0088】

警告は、例えば、会議室のスピーカから「体調不良者は離れてください」などの警告音声を出力させるようにしてもよいし、体調不良者が所有するスマートフォンなどに直接、プッシュ通知機能又はバイブレーション機能などを用いて行ってもよい。なお、体調不良者以外の参加者を含めて警告を行い、注意喚起を促してもよい。また、会議における参加者の座席位置が予め決められている場合には、その情報を用いて、体調不良者の周囲の参加者に事前に報知することとしてもよく、体調不良者の座席位置を変更してもよい。

【0089】

図４に戻り説明を続ける。報知制御部２５０は、報知形態決定部２４０において決定された報知形態に基づいた報知制御を行う。ここでは、報知制御部２５０は、決定された報知形態に基づいて、報知に必要な報知情報を生成し、報知部５００に対して送信する。報知情報は、ユーザに対する報知を行うための表示情報や音声情報であってよい。報知制御部２５０は、生成された報知情報を関連領域４００などに送信し、ユーザに対する報知を実行させる。

【0090】

図４に戻り説明を続ける。記憶部２６０は、報知サーバ２００が各種処理を実行するために必要なデータ及びプログラムなどを記憶する記憶領域である。記憶部２６０は、体調情報２６１、体調レベル判定情報２６２、予定情報２６３、座席情報２６４、存在予定位置情報２６５、及び領域情報２６６を記憶する。記憶部２６０は、報知制御部２５０が報知を行うための報知情報を記憶してもよい。

【0091】

続いて、図１４に示されるフローチャートを用いて、報知サーバ２００が行う処理を説明する。まず、体調情報取得部２１０（図４を参照）は、ユーザの体調情報２６１を取得する（Ｓ１０１）。体調情報取得部２１０は、体温測定装置１００から体温や咳の回数に関する客観情報を取得することで体調情報２６１を取得してよい。また、体調情報取得部２１０は、ユーザからの入力を受け付けて、頭痛などの自覚症状を含む客観情報を取得して、体調情報２６１に加味してもよい。

【0092】

次に、体調レベル判定部２２０は、体調情報２６１に基づいて、ユーザの体調レベルを判定する（Ｓ１０２）。体調レベル判定部２２０は、体調レベル判定情報２６２を参照し、各ユーザの体調レベルを判定する。

【0093】

続いて、存在予定位置情報取得部２３０は、ユーザの存在予定位置情報２６５を取得する（Ｓ１０３）。存在予定位置情報取得部２３０は、予定情報管理部３００から取得する予定情報２６３と、予め記憶されているユーザの座席情報２６４とに基づいて、存在予定位置情報２６５を取得する。

【0094】

続いて、報知形態決定部２４０は、ユーザの体調レベル及び存在予定位置情報２６５に基づいて、体調レベルが所定値以上であるユーザ（体調不良者）の存在予定位置情報が、所定領域内に所定人数以上含まれることを示すか否かを判定する（Ｓ１０４）。報知形態決定部２４０は、所定領域の大きさを加味して当該判定を行ってもよい。

【0095】

Ｓ１０４の処理において条件を満たす場合（Ｓ１０４のＹＥＳ）、報知形態決定部２４０は、体調レベル及び存在予定位置情報２６５に基づいて、ユーザに対する報知の報知形態を決定する（Ｓ１０５）。Ｓ１０４の処理において条件を満たさない場合（Ｓ１０４のＮＯ）は、処理を終了する。

【0096】

報知形態決定部２４０は、例えば、イベントの中止や延期などを関連ユーザに通知するよう報知形態を決定する。報知形態決定部２４０は、体調レベルが所定値以上のユーザが所定領域内に所定人数未満となるように、イベントの調整をユーザに促すような報知形態を決定してもよい。報知形態決定部２４０は、ユーザの参加属性情報を考慮して当該決定を行ってもよい。また、報知形態決定部２４０は、イベントの開催場所などに設置されたスピーカやランプなどでユーザに警告するように報知形態を決定してもよい。

【0097】

そして、報知制御部２５０は、決定された報知形態に基づいて、ユーザに対する報知を行う（Ｓ１０６）。報知制御部２５０は、報知部５００を用いて報知を行う。これにより、ユーザは、通信端末４５１上やイベント開催場所において、報知内容を確認することができる。

【0098】

以上説明したように、本実施形態にかかる報知システム１０００では、体温測定装置１００において、ユーザの体温を測定し、測定された各ユーザの体温と、ユーザを識別するユーザＩＤとを対応付けて報知サーバ２００に送信する。報知サーバ２００では、各ユーザの体温情報と、自覚症状などの主観情報とを対応付けて、体調情報として記憶し、体調情報に基づいて各ユーザの体調レベルを判定することができる。また、報知サーバ２００は、予定情報管理部３００からユーザの予定情報を取得し、予定情報に基づいて、ユーザの存在予定位置情報を取得する。

【0099】

報知サーバ２００は、ユーザの体調レベル及び存在予定位置情報に基づいて、ユーザに対してイベントの中止や開催場所の変更を促すための報知形態を決定し、予定情報管理部３００、関連領域４００、又は関連ユーザ端末４５０などを用いてユーザに報知する。

【0100】

報知サーバ２００は、報知形態の決定において、体調レベルが所定値以上となるユーザの人数を考慮することができるので、イベント開催場所に体調不良者が集中することを防止することができる。

【0101】

また、報知サーバ２００は、イベントが開催される場所の大きさを更に考慮して報知形態を決定することができる。報知サーバ２００は、例えば、体調不良者の人数が同じ場合であっても、会場が広い場合と狭い場合とで、異なる報知形態を決定することができる。したがって、イベントを中止させるだけでなく、参加者の座席位置の配慮などによって、柔軟に対応を決定することができる。

【0102】

このようにすることで、ユーザは、参加予定のイベントに関する感染拡大リスクの大きさを、事前に、しかも容易に確認することができる。したがって、本実施形態にかかる報知システム１０００によれば、体調不良者が所定領域内に集合又は接近するような場合でも、組織レベルにおいてクラスターの発生リスクを低減することができる。

【0103】

＜ハードウエアの構成例＞
報知サーバ２００、体温測定装置１００、予定情報管理部３００、通信端末４０１、及び通信端末４５１の各機能構成部は、各機能構成部を実現するハードウエア（例：ハードワイヤードされた電子回路など）で実現されてもよいし、ハードウエアとソフトウエアとの組み合わせ（例：電子回路とそれを制御するプログラムの組み合わせなど）で実現されてもよい。以下、報知サーバ２００等の各機能構成部がハードウエアとソフトウエアとの組み合わせで実現される場合について、更に説明する。

【0104】

プロセッサの各々は、アルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに提供することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ（compact disc）、又はＤＶＤ（digital versatile disc）などの光ディスク媒体、半導体メモリ（例えば、マスク ROM、PROM（Programmable ROM）、EPROM（Erasable PROM）、フラッシュROM、RAM）を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに提供されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

【0105】

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

【0106】

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
各ユーザの体調に関する体調情報を取得する体調情報取得部と、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定部と、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得部と、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定部と、
前記決定された報知形態に基づいて前記報知を制御する報知制御部と、
を備え、
前記報知形態決定部は、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定する
報知装置。
（付記２）
前記報知形態決定部は、前記所定領域の大きさに更に基づいて前記報知形態を決定する
付記１に記載の報知装置。
（付記３）
前記予定情報は、前記ユーザが参加予定のイベントにおける前記ユーザの参加属性情報を含み、
前記報知形態決定部は、前記参加属性情報に更に基づいて前記報知形態を決定する
付記１又は２に記載の報知装置。
（付記４）
前記体調情報は、前記体調に関する前記各ユーザの主観情報を含み、
前記体調レベル判定部は、前記主観情報を加味して前記体調レベルを判定する
付記１～３のいずれか１項に記載の報知装置。
（付記５）
前記報知形態決定部は、前記存在予定位置において、前記体調レベルが所定値以上のユーザが前記所定領域内に前記所定人数未満となるように、前記予定の調整を行うよう前記報知形態を決定する
付記１～４のいずれか１項に記載の報知装置。
（付記６）
各ユーザの体調に関する体調情報を取得する体調情報取得ステップと、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定ステップと、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得ステップと、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定ステップと、
前記決定された報知形態に基づいて前記報知を制御する報知制御ステップと、
を備え、
前記報知形態決定ステップでは、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定する
報知方法。
（付記７）
各ユーザの体調に関する体調情報を取得する体調情報取得ステップと、
前記体調情報に基づいて、前記各ユーザの体調レベルを判定する体調レベル判定ステップと、
前記各ユーザの予定を示す予定情報に基づいて、前記各ユーザの存在予定位置を示す存在予定位置情報を取得する存在予定位置情報取得ステップと、
前記体調レベル及び前記存在予定位置情報に基づいて、報知の報知形態を決定する報知形態決定ステップと、
前記決定された報知形態に基づいて前記報知を制御する報知制御ステップと、
を備える報知方法をコンピュータに実行させ、
前記報知形態決定ステップでは、前記体調レベルが所定値以上であるユーザの前記存在予定位置情報が、所定領域内に所定人数以上含まれることを示す場合、前記報知形態を決定する
プログラム。

【符号の説明】

【0107】

１００ 体温測定装置
１１０ 撮像部
１２０ 抽出部
１３０ 認証部
１４０ 赤外線撮像部
１５０ 体温測定部
１６０ 通信部
１７０ 表示部
２００ 報知サーバ
２１０ 体調情報取得部
２２０ 体調レベル判定部
２３０ 存在予定位置情報取得部
２４０ 報知形態決定部
２５０ 報知制御部
２６０ 記憶部
２６１ 体調情報
２６２ 体調レベル判定情報
２６３ 予定情報
２６４ 座席情報
２６５ 存在予定位置情報
２６６ 領域情報
３００ 予定情報管理部
４００ 関連領域
４０１ 通信端末
４０２ 表示装置
４０３ ランプ
４０４ スピーカ
４０５ ブザー
４５０ 関連ユーザ端末
４５１ 通信端末
４５１１ 表示画面
４５１２ 警告表示
４５１３ 詳細情報
５００ 報知部
１０００ 報知システム
Ｎ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】