JP2022016351A - 感染症対策システム - Google Patents

Abstract

【課題】感染症の拡大を抑制することが可能な感染症対策システムを提供する。【解決手段】複数の携帯端末と、管理サーバとが、ネットワークを介して相互通信可能な感染症対策システムにおいて、管理サーバ２０は、他人との接触状況をあらわす接触データやユーザの健康状態をあらわすヘルスケアデータ等を受信する通信部２３０、ユーザの健康状態のリスクレベルを判定するための健康リスク基準テーブルを記憶する記憶部２１０、接触データに基づき過去一定期間内にユーザと接触した接触ユーザを特定する特定部２６０、接触ユーザのヘルスケアデータと健康リスク基準テーブルとに基づきユーザの健康リスクを判断する判断部２７０及び判断結果を各ユーザが所属する企業などのコンピュータや各ユーザの携帯端末に出力する通知部２８０を備える。【選択図】図１１

Description

本発明は、感染症対策システムに関する。

近年、インフルエンザウイルスやコロナウイルスなどをはじめとする様々な感染症の拡大阻止を図るために予防策が種々検討されている。感染拡大を阻止するためには、感染者を早期に発見することはもちろん、感染者と接触した接触者を早期に発見し、感染のおそれがあることをいち早く知らせることが重要になる。
例えば、下記特許文献１には、感染者と接触した接触者に対し、警告メールを送信することで感染のおそれがあることを知らせる感染症予防システムが開示されている。

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

しかしながら、特許文献１に開示されたシステムでは、サーバ側で管理する接触者の情報（例えば、携帯電話機の電話番号、接触日時やメールアドレスなど）は、感染者の自己申告に委ねられている。このため、感染者と接触したにもかかわらず、申告漏れがあった接触者には、警告メールが通知されることはない。この結果、接触者への感染だけでなく、接触者による第三者への感染を招くおそれがある、という問題があった。

本発明は、以上説明した事情を鑑みてなされたものであり、感染症の拡大を抑制することが可能な技術を提供することを目的の一つとする。

本開示の一態様に係る感染症対策システムは、他人との接触状況をあらわす接触データを受信する第１受信部と、ユーザの健康状態をあらわすヘルスケアデータを受信する第２受信部と、ユーザの健康状態のリスクレベルを判定するための健康リスク基準情報を記憶する第１記憶部と、接触データに基づき、過去一定期間内にユーザと接触した接触ユーザを特定する特定部と、接触ユーザのヘルスケアデータと、健康リスク基準情報とに基づき、ユーザの健康リスクを判断する判断部と、判断の結果を、前記ユーザに通知する通知部とを具備することを要旨とする。

本開示の別の態様に係る感染症対策システムは、子端末である複数のタグ端末と、親端末である複数の携帯端末と、各タグ端末及び各携帯端末を管理する管理サーバとを備えた感染症対策システムであって、各タグ端末は、タグ端末を識別するための子端末識別情報を含むビーコン信号を発信する発信部を備え、各携帯端末は、タグ端末から前記ビーコン信号を受信する受信部と、携帯端末を識別するための親端末識別情報と、ビーコン信号に含まれる子端末識別情報と、ビーコン信号の受信日時をあらわす受信日時情報とを含む接触データを、管理サーバに送信する送信部とを備え、管理サーバは、各携帯端末から送信される接触データを受信する受信部と、各携帯端末から送信される接触データに基づき、各携帯端末を利用する各ユーザと各タグ端末を利用する各ユーザとの接触状況を検知する検知部とを具備することを要旨とする。

本開示の別の態様に係る感染症対策システムは、他人との接触状況をあらわす接触データを受信する第１受信部と、企業に属する各ユーザの行動履歴をあらわす行動データを受信する第２受信部と、各ユーザの健康状態をあらわすヘルスケアデータを受信する第３受信部と、感染症のリスクレベルを判定するための基準情報を記憶する記憶部と、接触データと、行動データと、ヘルスケアデータと、基準情報とに基づき、各ユーザの感染症のリスクレベルを判定する判定部と、判定の結果を出力する出力部とを具備し、出力部は、各ユーザの携帯端末に、各ユーザのリスクレベルに応じた行動指針をあらわす指針情報を表示する一方、企業のコンピュータに、リスクレベルごとの各ユーザの割合を表示することを要旨とする。

本発明の所定の態様によれば、感染症の拡大を抑制することが可能となる。

本実施形態に係る感染症対策システムの構成の一例を示す図である。 携帯端末、管理サーバのハードウェア構成の一例を示す図である。 携帯端末の機能構成を示すブロック図である。 ヘルスケアデータの入力画面を例示した図である。 管理サーバの機能構成を示すブロック図である。 基準テーブルの登録内容を例示した図である。 企業のコンピュータに表示される判定結果の表示画面を例示した図である。 各携帯端末に表示される判定結果の表示画面を例示した図である。 接触トレース方法の第１態様を示す説明図である。 接触トレース方法の第２態様を示す説明図である。 応用例１に係る管理サーバの機能構成を示すブロック図である。 健康リスク基準テーブルの登録内容を例示した図である。 感染者に接触したユーザの健康リスクの変化を例示した図である。 管理サーバによる体調リスク判断処理を示すフローチャートである。 携帯端末がビーコン端末を検知する場合の説明図である。 携帯端末によるビーコン端末の接触トレース方法を説明するための説明図である。

添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

Ａ．本実施形態
＜システム構成＞
図１は、本実施形態に係る感染症対策システム１００の構成の一例を示す図である。
感染症対策システム１００は、各ユーザが利用する携帯端末１０と、各ユーザを管理する管理サーバ２０とを含んで構成される。各携帯端末１０と管理サーバ２０とは、ネットワークＮを介して相互通信可能となっている。

ネットワークＮのうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワークＮは、限定でなく例として、アドホック・ネットワーク（Ad Hoc Network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（Virtual Private Network：ＶＰＮ）、ローカル・エリア・ネットワーク（Local Area Network：ＬＡＮ）、ワイヤレスＬＡＮ（Wireless LAN：ＷＬＡＮ）、広域ネットワーク（Wide Area Network：ＷＡＮ）、ワイヤレスＷＡＮ（Wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（Metropolitan Area Network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮｓ（Integrated Service Digital Networks）、無線ＬＡＮｓ、ＬＴＥ（Long Term Evolution）、ＣＤＭＡ（Code Division Multiple Access）、ブルートゥース（Bluetooth（登録商標））、ＩｒＤＡ（登録商標）、衛星通信など、または、これらの２つ以上の組合せを含むことができる。

＜感染症対策システム１００の概要＞
本実施形態に係る感染症対策システム１００は、ユーザの行動や、他人との接触状況、ユーザの健康状態をもとに感染症のリスクレベルを判定し、ユーザ本人や本人が所属する企業などに、リスクレベルの判定結果を速やかに通知することで感染症の拡大を抑制することを可能とする（詳細は後述）。

携帯端末１０は、各ユーザが所持する端末であり、例えばスマートフォン、携帯電話、パーソナルコンピュータ、ハンドヘルドコンピュータデバイス、ウェアラブル端末などによって構成されている。携帯端末１０には、自端末を所持するユーザが過去に接触した人をトレース（追跡、確認）するためのアプリケーション（以下、「接触トレースアプリ」ともいう。）が格納されている。携帯端末１０は、接触トレースアプリを起動することで、後述する接触トレース方法を実現する。

管理サーバ２０は、例えばサーバコンピュータにより実現され、各ユーザの携帯端末１０から取得される様々な情報に基づき感染症のリスクレベルを判定し、判定結果を出力する。各ユーザの携帯端末１０から取得される情報として、他人との接触状況をあらわす接触データや、ユーザの行動履歴をあらわす行動データ、ユーザの健康状態をあらわすヘルスケアデータなどがある（詳細は後述）。

＜ハードウェア構成＞
図２は、携帯端末１０、管理サーバ２０のハードウェア構成の一例を示す図である。携帯端末１０及び管理サーバ２０は、それぞれ、ＣＰＵ（Central Processing Unit）１、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等の記憶装置２、有線通信や無線通信などを行う通信ＩＦ（Interface）３、入力操作を受け付ける入力デバイス４、及び情報の出力を行う出力デバイス５を有する。入力デバイス４は、例えばキーボード、マウス、タッチパネル、マイク等である。出力デバイス５は、例えば、ディスプレイ（画面）及び／又はスピーカ等である。

以下、図３を参照しながら、携帯端末１０の機能構成について説明する。

＜携帯端末１０の機能ブロック構成＞
携帯端末１０は、記憶部１１０と、制御部１２０と、操作部１３０と、表示部１４０と、近距離無線通信部１５０と、接触データ取得部１６０と、行動データ取得部１７０と、ヘルスケアデータ取得部１８０と、通信部１９０とを含む。

制御部１２０と、操作部１３０と、表示部１４０と、近距離無線通信部１５０と、接触データ取得部１６０と、行動データ取得部１７０と、ヘルスケアデータ取得部１８０と、通信部１９０は、携帯端末１０のＣＰＵ１が記憶装置２に記憶された各種プログラムを実行することによって実現される。なお、プログラムは、ＵＳＢメモリやＣＤ－ＲＯＭ等の記憶媒体に格納することができる。

記憶部１１０は、記憶装置２によって実現され、上述した接触トレースアプリＡＰ１のほか、様々なアプリケーションや各種データを記憶する。

制御部１２０は、携帯端末１０を中枢的に制御する。操作部１３０は、操作内容に応じた各種コマンドを入力し、表示部１４０は、ディスプレイに各種情報を表示する。近距離無線通信部１５０は、例えばブルートゥース規格に準拠した近距離無線通信機能を利用して、近接した他の携帯端末１０との間で近距離無線通信を行う。本実施形態では、ユーザが他のユーザ（以下、「接触ユーザ」ともいう。）に接触した場合に、当該ユーザの携帯端末１０と接触ユーザの携帯端末１０との間で近距離無線通信を行い、カプセル情報の交換を行う。「カプセル情報」とは、各ユーザに割り当てられるユニークな識別情報（トークン）である。カプセル情報は、記憶部１１０に格納される。詳細は後述するが、交換されるカプセル情報には、そのユーザ自身のカプセル情報だけでなく、そのユーザが過去に接触して得た他のユーザのカプセル情報も含まれる。なお、以下では説明の便宜上、そのユーザ自身のカプセル情報を「自カプセル情報」と呼び、そのユーザが過去に接触して得た他のユーザのカプセル情報を「履歴カプセル情報」と呼ぶ。

接触データ取得部１６０は、記憶部１１０に格納されているカプセル情報を接触データとして取得する。
行動データ取得部１７０は、携帯端末１０に搭載されているＧＰＳ（Global Positioning System）機能や加速度センサ、画像センサ（いずれも図示略）などを利用して、当該携帯端末１０を利用するユーザの位置や行動内容などを含む行動履歴をあらわす行動データを取得する。
ヘルスケアデータ取得部１８０は、ユーザによって入力される体温データ、問診データといった健康状態をあらわす情報を、ヘルスケアデータとして取得する。

図４は、ディスプレイに表示されるヘルスケアデータの入力画面Ｇ１を例示した図である。
ユーザは、入力画面Ｇ１に従って、自身の体温データ（例えば、３６．５℃など）Ｄ１を入力するとともに、自身の体調をあらわす問診データ（例えば、体がだるいか、息切れがあるか、咳がでるかなど）Ｄ２をタップ入力する。なお、携帯端末１０に検温機能が搭載されている場合には、検温機能を使って自動で体温を測定し入力してもよい。

通信部１９０は、ネットワークＮを介して管理サーバ２０を含む外部機器と様々なデータを授受する。一例として、通信部１９０は、接触データや行動データ、ヘルスケアデータを管理サーバ２０に送信する。これらすべてのデータは、ユーザの許諾が得られることを前提に管理サーバ２０へ送信される。もっとも、全てのデータが、ユーザの許諾なく管理サーバ２０へ送信される構成であってもよく、また、一部のデータ（例えば、接触データ）についてのみユーザの許諾を必要とし、他のデータについてはユーザの許諾を必要としない構成であってもよい。

次に、図５を参照しながら、管理サーバ２０の機能構成について説明する。

＜管理サーバ２０の機能ブロック構成＞
管理サーバ２０は、記憶部２１０と、制御部２２０と、通信部２３０と、判定部２４０と、出力部２５０とを含む。

制御部２２０と、通信部２３０と、判定部２４０と、出力部２５０は、管理サーバ２０のＣＰＵ１が記憶装置２に記憶された各種プログラムを実行することによって実現される。なお、プログラムは、ＵＳＢメモリやＣＤ－ＲＯＭ等の記憶媒体に格納することができる。

記憶部２１０は、記憶装置２によって実現され、様々なアプリケーションや各種データを記憶する。記憶部２１０には、個別データベースＤＢ１が格納されている。個別データベースＤＢ１には、ユーザごとに、当該ユーザを識別するカプセル情報と、当該ユーザの携帯端末１０から受信した接触データ、行動データ、ヘルスケアデータなどが対応づけて登録されている。また、記憶部２１０には、感染症のリスクレベルを判定するための基準テーブルＴＡ１（基準情報）が記憶されている。

制御部２２０は、管理サーバ２０を中枢的に制御する。通信部（第１～第３受信部）２３０は、ネットワークＮを介して携帯端末１０を含む外部機器と様々なデータを授受する。一例として、通信部２３０は、各携帯端末１０から接触データや行動データ、ヘルスケアデータを受信する。

判定部２４０は、通信部によって受信された接触データや行動データ、ヘルスケアデータとともに、記憶部２１０に格納されている基準テーブルＴＡ１を利用して各ユーザの感染症のリスクレベルを判定する。

図６は、基準テーブルＴＡ１の登録内容を例示した図である。
図６に示すように、基準テーブルＴＡ１には、判定基準と、４段階の感染症のリスクレベルとが対応づけて登録されている。図６を例に説明すると、判定部２４０は、「発熱がなく、体調に異常が認められない場合」には、最もリスクレベルが低い「リスクレベル０（健常者）」と判定する。一方、判定部２４０は、「発熱があるものの、体調の異常は軽度であり、かつ、過去〇×日の間に感染者集団（クラスター）が発生した場所にいなかった場合」には、「リスクレベル１（リスク・ロー・ユーザ）」と判定する。また、判定部２４０は、「３７．５℃以上の発熱が継続するとともに、体調に重度の異常が認められ、かつ、過去×〇日の間に感染者と接触している場合」には、「リスクレベル２（リスク・ハイ・ユーザ）」と判定する。さらに、判定部２４０は、「ＰＣＲ検査によって陽性が認められた場合」には、最もリスクレベルが高い「リスクレベル３（感染者）」と判定する。

ここで、発熱の有無や体調の異常の有無などは、例えばヘルスケアデータに基づいて判断する。また、ユーザがクラスターの発生場所にいたか否かなどは、例えばクラスター・マップ（図示略）や行動データに基づいて判断する。また、感染者との接触の有無などは、例えば接触データに基づいて判断する。なお、管理サーバ２０は、外部サーバに定期的（または不定期）にアクセスすることで、最新のクラスター・マップを取得することができる。

出力部２５０は、判定部２４０による判定結果を適宜加工し、各ユーザが所属する企業などのコンピュータや各ユーザの携帯端末１０に出力する。

図７は、企業のコンピュータに表示される判定結果の表示画面Ｇ２を例示した図であり、図８は、各ユーザの携帯端末１０に表示される判定結果の表示画面Ｇ３を例示した図である。

図７に示すように、企業のコンピュータの表示画面Ｇ２には、どのリスクレベルにどれくらいの人数のユーザがいるか（すなわち、リスクレベルごとのユーザの割合）をあらわすグラフｇｆ１や、所定期間中のアラートの発生数をあらわすグラフｇｆ２などが表示される。

出力部２５０は、企業の管理者が視認しやすいように、リスクレベルごとに色分けしてグラフｇｆ１を表示する。一例として、出力部２５０は、「リスクレベル０（健常者）」を緑色、「リスクレベル１（リスク・ロー・ユーザ）」を黄色、「リスクレベル２（リスク・ハイ・ユーザ）」を橙色、「リスクレベル３（感染者）」を赤色で表示する。

なお、グラフｇｆ２に示すアラートの通知条件は、管理サーバ２０が任意に設定するこができる。例えば体温が３７．５℃以上、または体調に重度の異常が認められたユーザの携帯端末１０に対し、アラートを通知することができる。

出力部２５０は、図７に示す表示画面Ｇ２に示す各グラフｇｆ１、ｇｆ２のほか、各リスクレベルの変動履歴に基づいてリスクレベルの変動を予想し、予想した結果をあらわすグラフなどを企業のコンピュータに表示する。

一方、図８に示すように、各ユーザの携帯端末１０の表示画面Ｇ３には、当該ユーザのリスクレベルに応じた行動指針をあらわす指針情報Ｉｍ１が表示される。例えば、「リスクレベル０（健常者）」のユーザであれば、「出勤ＯＫです」といったメッセージが表示される。また、「リスクレベル１（リスク・ロー・ユーザ）」であれば、「リモートワークＯＫです」といったメッセージ、「リスクレベル２（リスク・ハイ・ユーザ）」であれば、「指定の医療機関で受診してください。」といったメッセージ、「リスクレベル３（感染者）」であれば、「治療を継続してください。」といったメッセージなどが表示される。

各ユーザは、携帯端末１０に表示される指針情報Ｉｍ１を確認することで、自身が出勤してもよいか、またはリモートワークすべきか等を速やかに把握することができる。その他にも、各ユーザは、携帯端末１０を適宜操作することで、所定期間単位（例えば週、月、単位など）での自身の体温の変化を確認したり、所定期間単位（例えば、週、月、単位など）で自身が何人と接触していたのか等を確認したりすることができる。なお、出力部２５０は、ユーザが自身のリスクレベルを速やかに把握できるように、企業のコンピュータへの表示と同様、リスクレベルを色分けして表示してもよい。

つぎに、本実施形態に係る接触トレースアプリＡＰ１を利用した接触トレース方法について詳細に説明する。

＜接触トレース方法の説明＞
（１）第１態様
図９は、各携帯端末１０の制御部１２０が接触トレースアプリＡＰ１を起動することで実行される接触トレース方法の第１態様を示す説明図である。
以下の説明では、４人のユーザＡ～Ｄの間で接触が行われ、最終的にユーザＡが感染症に感染したことが判明した場合を想定する。また、ユーザＡ～Ｄのそれぞれの携帯端末１０において、自カプセル情報１～４が生成・格納されているものとする。

本実施形態に係る接触トレース方法は、直接接触のみならず、間接接触や非接触の判定などもサポートすることが可能となっている。

ユーザＡとユーザＢが接触（近接）すると、ユーザＡ及びユーザＢの携帯端末１０は、カプセル情報の交換を行う（Ａ１参照）。カプセル情報を交換する際、各携帯端末１０は、近距離無線通信機能を利用する。カプセル情報の交換によって得た他ユーザのカプセル情報は、それぞれ履歴カプセル情報として記憶部１１０に格納される。ユーザＡとユーザＢのカプセル情報の交換によって、ユーザＡの携帯端末１０の記憶部１１０には、自カプセル情報１に加えて履歴カプセル情報２が格納され、ユーザＢの携帯端末１０の記憶部１１０には、自カプセル情報２に加えて履歴カプセル情報１が格納される。

ユーザＣとユーザＤが接触した場合も同様、ユーザＣ及びユーザＤの携帯端末１０は、カプセル情報の交換を行う（Ａ２参照）。ユーザＣとユーザＤのカプセル情報の交換により、ユーザＣの携帯端末１０の記憶部１１０には、自カプセル情報３に加えて履歴カプセル情報４が格納され、ユーザＤの携帯端末１０の記憶部１１０には、自カプセル情報４に加えて履歴カプセル情報３が格納される。

その後、ユーザＢとユーザＣが接触すると、ユーザＢ及びユーザＣの携帯端末１０は、カプセル情報の交換を行う（Ａ３参照）。ユーザＢとユーザＣが接触した時点において、ユーザＢ及びユーザＣは、自カプセル情報だけでなく履歴カプセル情報も保有している。よって、ユーザＢとユーザＣが接触した場合には、自カプセル情報とともに履歴カプセル情報の交換が行われることになる。この結果、ユーザＢの携帯端末１０の記憶部１１０には、自カプセル情報２及び履歴カプセル情報１に加え、ユーザＣの携帯端末１０から受け取った履歴カプセル情報３及び４が格納される。一方、ユーザＣの携帯端末１０の記憶部１１０には、自カプセル情報３及び履歴カプセル情報４に加え、ユーザＢの携帯端末１０から受け取った履歴カプセル情報２及び１が格納される。このように、本実施形態では、直接接触したユーザ（すなわち、直接接触者）のカプセル情報だけを交換するのではなく、そのユーザが過去に接触して得た他のユーザ（すなわち、間接接触者）のカプセル情報も交換する。なお、自カプセル情報と履歴カプセル情報を判別できるように、カプセル情報の種別をあらわすフラグを付加するようにしてもよい。

その後、例えばＰＣＲ検査などを受けることにより、ユーザＡが感染症に感染したことが判明すると、ユーザＡは、自身の携帯端末１０を操作して感染症の感染を管理サーバ２０に報告（以下、「感染報告」ともいう。）する。感染報告には、ユーザＡを特定するカプセル情報が含まれる。本実施形態では、感染した本人の許諾が得られた場合に感染報告を行う場合を想定するが、本人の許諾なしに感染報告を行ってもよい。

管理サーバ２０は、携帯端末１０から感染報告を受け取ると、感染報告に含まれるカプセル情報（以下、「感染カプセル情報」ともいう。）と、個別データベースＤＢ１に登録されている各ユーザのカプセル情報を比較することで、感染したユーザを特定する。ここでは、感染報告に含まれる感染カプセル情報が、ユーザＡのカプセル情報であることから、管理サーバ２０は、ユーザＡが感染したユーザであると判断する。

管理サーバ２０は、他のユーザの携帯端末１０に対し、ユーザＡの感染カプセル情報を含めてユーザＡとの接触判定を指示する。
他のユーザの携帯端末１０は、管理サーバ２０からユーザＡの感染カプセル情報を受け取ると、受け取った感染カプセル情報と、記憶部１１０に格納されているカプセル情報とを比較することで、他のユーザの接触状況を判定する。

（ユーザＢの場合）
ユーザＢの携帯端末１０には、ユーザＡを特定する履歴カプセル情報１が格納されている。ここで、ユーザＡは、ユーザＢが直接カプセル情報を交換したユーザであることから、ユーザＢの携帯端末１０は、ユーザＢは直接接触者であると判断し、判断結果をディスプレイ（表示装置）に出力する。一例として、ユーザＢは「直接接触者」である旨のメッセージとともに、「出社停止」を促すメッセージをディスプレイに表示する（Ａ４参照）。

（ユーザＣの場合）
ユーザＣの携帯端末１０にも、ユーザＡを特定する履歴カプセル情報１が格納されている。しかしながら、ユーザＡは、ユーザＣが直接カプセル情報を交換したユーザではなく、ユーザＢとのカプセル情報の交換を介して、間接的に接触してカプセル情報を得たユーザである。よって、ユーザＣの携帯端末１０は、ユーザＣは間接接触者であると判断し、判断結果をディスプレイに出力する。一例として、ユーザＣは「間接接触者」である旨のメッセージとともに、「経過観察」を促すメッセージをディスプレイに表示する（Ａ５参照）。

（ユーザＤの場合）
ユーザＤの携帯端末１０には、ユーザＡを特定する履歴カプセル情報１は格納されていない。よって、ユーザＤの携帯端末１０は、ユーザＤは非接触者であると判断し、判断結果をディスプレイに表示する。一例として、ユーザＤは「非接触者」である旨のメッセージとともに、「通常勤務」を促すメッセージをディスプレイに表示する（Ａ６参照）。

かかる第１態様によれば、直接接触したユーザのカプセル情報だけを交換するのではなく、そのユーザが過去に接触して得た他のユーザのカプセル情報も交換する。これにより、いずれかのユーザに感染が認められた場合に、直接接触者だけでなく、間接接触者や非接触者を判断することができる。

（１）第２態様
図１０は、各携帯端末１０の制御部１２０が接触トレースアプリＡＰ１を起動することで実行される接触トレース方法の第２態様を示す説明図である。
なお、図１０では、５人のユーザＡ～Ｅの間で接触が行われ、最終的にユーザＡ及びユーザＥが感染症に感染したことが判明した場合を想定する。また、ユーザＡ～Ｅのそれぞれの携帯端末１０において、自カプセル情報１～５が生成・格納されているものとする。

ユーザＡとユーザＢが接触すると、ユーザＡ及びユーザＢの携帯端末１０は、カプセル情報の交換を行う（Ｂ１参照）。カプセル情報の交換によって得た他ユーザのカプセル情報は、それぞれ履歴カプセル情報として記憶部１１０に格納される。ユーザＡとユーザＢのカプセル情報の交換によって、ユーザＡの携帯端末１０の記憶部１１０には、自カプセル情報１に加えて履歴カプセル情報２が格納され、ユーザＢの携帯端末１０の記憶部１１０には、自カプセル情報２に加えて履歴カプセル情報１が格納される。

その後、ユーザＢとユーザＣが接触すると、ユーザＢ及びユーザＣの携帯端末１０は、カプセル情報の交換を行う（Ｂ２参照）。ユーザＢとユーザＣが接触した時点において、ユーザＢは、自カプセル情報だけでなく履歴カプセル情報も保有している。一方、ユーザＣは、自カプセル情報のみを保有している。よって、ユーザＢとユーザＣが接触した場合には、ユーザＢの携帯端末１０の記憶部１１０には、自カプセル情報２及び履歴カプセル情報１に加え、ユーザＣの携帯端末１０から受け取った履歴カプセル情報３が格納される。一方、ユーザＣの携帯端末１０の記憶部１１０には、自カプセル情報３に加え、ユーザＢの携帯端末１０から受け取った履歴カプセル情報２及び１が格納される。

その後、ユーザＡとユーザＤが接触すると、ユーザＡ及びユーザＤの携帯端末１０は、カプセル情報の交換を行う（Ｂ３参照）。ユーザＡとユーザＤが接触した時点において、ユーザＡは、自カプセル情報だけでなく履歴カプセル情報も保有している。一方、ユーザＤは、自カプセル情報のみを保有している。よって、ユーザＡとユーザＤが接触した場合には、ユーザＡの携帯端末１０の記憶部１１０には、自カプセル情報１及び履歴カプセル情報２に加え、ユーザＤの携帯端末１０から受け取った履歴カプセル情報４が格納される。一方、ユーザＤの携帯端末１０の記憶部１１０には、自カプセル情報４に加え、ユーザＡの携帯端末１０から受け取った履歴カプセル情報１及び２が格納される。

その後、ユーザＤとユーザＥが接触すると、ユーザＤ及びユーザＥの携帯端末１０は、カプセル情報の交換を行う（Ｂ４参照）。ユーザＤとユーザＥが接触した時点において、ユーザＤは、自カプセル情報だけでなく履歴カプセル情報も保有している。一方、ユーザＥは、自カプセル情報のみを保有している。よって、ユーザＤとユーザＥが接触した場合には、ユーザＤの携帯端末１０の記憶部１１０には、自カプセル情報４及び履歴カプセル情報１及び２に加え、ユーザＥの携帯端末１０から受け取った履歴カプセル情報５が格納される。一方、ユーザＥの携帯端末１０の記憶部１１０には、自カプセル情報５に加え、ユーザＤの携帯端末１０から受け取った履歴カプセル情報４、１及び２が格納される。

その後、例えばＰＣＲ検査などを受けることにより、ユーザＡおよびユーザＥが感染症に感染したことが判明すると、ユーザＡ及びユーザＥは、それぞれ自身の携帯端末１０を操作して管理サーバ２０に感染報告する。ユーザＡからの感染報告には、ユーザＡを特定するカプセル情報が含まれる一方、ユーザＥからの感染報告には、ユーザＥを特定するカプセル情報が含まれる。

管理サーバ２０は、携帯端末１０から感染報告を受け取ると、感染報告に含まれる感染カプセル情報と、個別データベースＤＢ１に登録されている各ユーザのカプセル情報を比較することで、感染したユーザを特定する。ここでは、感染報告に含まれる感染カプセル情報が、ユーザＡのカプセル情報及びユーザＥのカプセル情報であることから、管理サーバ２０は、ユーザＡ及びユーザＥが感染したユーザであると判断する。

管理サーバ２０は、他のユーザの携帯端末１０に対し、ユーザＡ及びユーザＥの感染カプセル情報を含めてユーザＡ及びユーザＥとの接触判定を指示する。
他のユーザの携帯端末１０は、管理サーバ２０からユーザＡ及びユーザＥの感染カプセル情報を受け取ると、受け取った感染カプセル情報と、記憶部１１０に格納されているカプセル情報とを比較することで、他のユーザの接触状況を判定する。

（ユーザＢの場合）
ユーザＢの携帯端末１０には、ユーザＡを特定する履歴カプセル情報１が格納されている。ここで、ユーザＡは、ユーザＢが直接カプセル情報を交換したユーザであることから、ユーザＢの携帯端末１０は、ユーザＢは直接接触者であると判断し、判断結果をディスプレイに出力する。

（ユーザＣの場合）
ユーザＣの携帯端末１０にも、ユーザＡを特定する履歴カプセル情報１が格納されている。しかしながら、ユーザＡは、ユーザＣが直接カプセル情報を交換したユーザではなく、ユーザＢとのカプセル情報の交換を介して、間接的に接触してカプセル情報を得たユーザである。よって、ユーザＣの携帯端末１０は、ユーザＣは間接接触者であると判断し、判断結果をディスプレイに出力する。

（ユーザＤの場合）
ユーザＤの携帯端末１０には、ユーザＡを特定する履歴カプセル情報１とともに、ユーザＥを特定する履歴カプセル情報５が格納されている。そして、ユーザＡ及びユーザＥは、いずれもユーザＤが直接カプセル情報を交換したユーザであることから、ユーザＤの携帯端末１０は、ユーザＤは複数の感染者と接触したクラスター接触者（複数回、感染者との接触が確認された接触者）であると判断し、判断結果をディスプレイに出力する。

かかる第２態様によれば、直接接触者だけでなく、間接接触者やクラスター接触者を判断することができる。なお、各携帯端末１０は、接触状況の判定結果を管理サーバ２０に送信してもよい。管理サーバ２０は、各携帯端末１０から送信される各ユーザの接触状況の判定結果を統合・分析することで、前掲図７に示すリスクレベルごとのユーザの割合をあらわすグラフｇｆ１などを生成・出力することが可能となる。

上記実施形態では、特に言及しなかったが、交換日時（年月日や時刻など）を特定するための日時情報を、交換対象となるカプセル情報に含めるようにしてもよい。カプセル情報に含まれる日時情報を利用することで、例えば、いつ感染者に接触したのか等を正確に把握することができる。また、どの範囲の接触者までカプセル情報の交換対象とするかは任意に設定・変更可能である。例えば、二次接触者（間接接触者）までのカプセル情報を交換対象としてもよい。また、二次接触者が多数いる場合には、直近Ｎ人（Ｎ≧１）までの二次接触者をカプセル情報の交換対象としてもよい。また、交換したカプセル情報は、例えば１４日間など、所定期間だけ記憶部１１０に格納し、その後に消去するようにしてもよい。

また、上記実施形態では、感染報告を行う際、自端末１０を特定するカプセル情報のみを管理サーバ２０に送信したが、これに限る趣旨ではない。例えば、自端末１０の記憶部１１０に格納されている全てのカプセル情報を管理サーバ２０に送信してもよい。かかる構成によれば、感染者だけでなく直接接触者なども、管理サーバ２０において判断することが可能となる。
また、カプセル情報を管理サーバ２０に送信するタイミングは、感染報告を行う場合に限る趣旨ではない。感染報告とは異なるタイミング、例えばユーザ自身の体調が悪くなった場合やユーザが希望する場合など、ユーザが任意のタイミングでカプセル情報を管理サーバ２０に送信してもよい。

なお、管理サーバ２０において管理される各ユーザのカプセル情報は、固定的なものであってもよいが、定期的（例えば１ヶ月ごと）に更新してもよい。

また、各企業において確認された感染者のカプセル情報を企業間で共有することで、感染症の汎発流行（パンデミック）を抑制するようにしてもよい。なお、本実施形態では、ユーザの一例として企業に所属する従業員を例に説明したが、様々な団体に所属する構成員を含め、あらゆる人に本システムを適用可能である。
また、所定以上のリスクレベル（例えば、リスクレベル２以上）が認められたユーザ（以下、リスクユーザ）については、当該ユーザが所属する企業に知らせるだけではなく、他の企業に周知するようにしてもよい。一例として、管理サーバ２０は、リスクユーザの接触データ、行動データ、ヘルスケアデータの少なくともいずれかのデータを、他の企業のコンピュータに送信する。これにより、リスクユーザの存在を他の企業に周知し、感染症の拡大を抑制するようにしてもよい。

Ｂ．応用例
＜応用例１＞
上述した本実施形態では、ユーザの行動や、他人との接触状況、ユーザの健康状態をもとに感染症のリスクレベルを判定する場合について説明した。
これに対し、応用例１では、ユーザが過去に接触した他のユーザ（すなわち、接触ユーザ）の健康状態に基づき、ユーザ本人の健康リスクを判断する場合について説明する。

図１１は、応用例１に係る管理サーバ２０の機能構成を示すブロック図である。
図１１に示す管理サーバ２０は、健康リスク基準テーブルＴＡ２、特定部２６０、判断部２７０、通知部２８０を具備する点を除けば、図５に示す管理サーバ２０と同様であるため、対応する部分には同一符号を付し、詳細な説明は割愛する。

特定部２６０は、ユーザの携帯端末１０から送信されるユーザの接触データに基づき、過去一定期間内（例えば、３０日など）に当該ユーザと接触した接触ユーザを特定する。
判断部２７０は、特定部２６０によって特定された接触ユーザのヘルスケアデータと、記憶部２１０に格納されている健康リスク基準テーブル（健康リスク基準情報）ＴＡ２とに基づき、ユーザの健康リスクを判断する。

図１２は、健康リスク基準テーブルＴＡ２の登録内容を例示した図である。
図１２に示すように、健康リスク基準テーブルＴＡ２には、判断基準と、ｍ段階（ここでは、ｍ＝４）の健康リスクレベルとが対応づけて登録されている。具体的に説明すると、判断部２７０は、例えば「過去〇×日以内に、３人以上の接触ユーザの健康状態（以下、体調）の悪化が認められ、かつ、体調の悪化が所定日数以上継続している場合」には、この後にユーザの体調が悪化する可能性が高いと考えられることから、「健康リスクレベル３（予想）」と判断する。また、判断部２７０は、「過去△□以内に、３人未満の接触ユーザの体調の悪化が認められ、かつ、体調の悪化が継続している場合」には、この後にユーザの体調が悪化することが多少懸念されることから、「健康リスクレベル２（予想）」と判断する。

一方、判断部２７０は、「過去△□以内に、３人未満の接触ユーザの体調の悪化が認められるものの、体調の回復が認められる場合」には、この後にユーザの体調が悪化する可能性は低いと考えられることから、「健康リスクレベル１（予想）」と判断する。また、判断部２７０は、「過去〇△以内に、接触ユーザの体調の悪化が認められない場合」には、この後、ユーザの体調が悪化するとは考え難いことから、「健康リスクレベル０（予想）」と判断する。なお、接触ユーザの体調は、例えば接触ユーザのヘルスケアデータから把握することができる。また、管理サーバ２０は、例えば外部サーバに定期的（または不定期）にアクセスすることで、最新の健康リスク基準テーブルＴＡ２にアップデートすることができる。

図１１に戻り、通知部２８０は、判断部２７０によるユーザの健康リスクレベルの判断結果を、ユーザが所属する企業などのコンピュータや、ユーザの携帯端末１０に通知する。各ユーザは、携帯端末１０等に通知される自身の健康リスクを確認することで、自覚症状がなくても、この後に自身の体調が悪化する可能性等を事前に把握しておくことができる。

図１３は、感染者に接触したユーザの健康リスクの変化を例示した図である。
図１３のパターンＡに示すように、感染者から感染報告があった場合に、当該感染者と接触した各ユーザの感染リスクを判定する方法では、すでに各ユーザの体調が大きく悪化していることが懸念される。

そこで、本変形例では、図１３のパターンＢに示すように、感染者から感染報告がなされる前（具体的には、感染者の「体調悪化」や「体調悪化継続」が確認されたとき）に、過去一定期間内に感染者と接触した各ユーザの健康リスクを判断することで、各ユーザに健康リスクレベル等の注意喚起を可能とする。なお、本変形例では、健康リスクレベルの通知方法として、健康リスクレベルに応じたアイコン画像Ｐ１、Ｐ２をユーザの携帯端末１０に表示する方法を想定するが、どのような方法を採用するかは適宜設定・変更可能である。

図１４は、管理サーバ２０による体調リスク判断処理を示すフローチャートである。
特定部２６０は、体調リスクの判断対象となるユーザの接触データに基づき、過去一定期間内に当該ユーザと接触した他のユーザ（すなわち、接触ユーザ）を特定する（ステップＳ１）。

判断部２７０は、各接触ユーザのヘルスケアデータを確認した後（ステップＳ２）各接触ユーザのヘルスケアデータと、最新の健康リスク基準テーブルＴＡ２とに基づき、ユーザの健康リスクレベルを判断する（ステップＳ３）。
通知部２８０は、ユーザの健康リスクレベルの判断結果を、ユーザが所属する企業などのコンピュータや、ユーザの携帯端末１０に通知し（ステップＳ４）、処理を終了する。

＜応用例２＞
上述した本実施形態では、携帯端末１０を所持するユーザ同士の接触を検知する場合について説明したが、これに限る趣旨ではない。例えば、ビーコン端末を所持するユーザと携帯端末１０を所持するユーザの接触を検知する場合にも適用可能である。

図１５は、親端末となる携帯端末１０が、子端末となるビーコン端末３０を検知する場合の説明図である。
ビーコン端末３０は、例えばＢＬＥ（Bluetooth Low Energy）を利用した端末であり、自端末を識別するタグ識別情報を含めてビーコン信号を発信する。携帯端末（受信部）１０は、ビーコン端末３０から発信されるビーコン信号を受信することで、ビーコン端末３０を検知する。

携帯端末（送信部）１０は、ビーコン信号を受信すると、ビーコン信号に含まれるタグ識別情報（子端末識別情報）と、当該携帯端末１０を識別するための携帯端末識別情報（親端末識別情報）と、ビーコン信号の受信日時をあらわす受信日時情報とを含む接触データを生成し、管理サーバ２０に送信する。

管理サーバ（受信部、検知部）２０は、各携帯端末１０から送信される接触データを受信すると、受信した接触データに基づき、各携帯端末１０を利用するユーザと、各ビーコン端末３０を利用するユーザとの接触状況を検知する。

図１６は、下記前提条件の下、携帯端末１０によるビーコン端末３０の接触トレース方法を説明するための説明図である。
（前提条件（図１６のＡ参照））
・ユーザＡ～Ｃは、ビーコン端末３０を所持し、１０：００～１１：００の時間帯において個室１の固定席に滞在。
・ユーザＤは、ビーコン端末３０を所持し、１０：００～１１：０の時間帯において個室２の固定席に滞在。
・ユーザＸは、携帯端末１０を所持し、１０：００～１０：３０の時間帯において個室１を巡回し、ユーザＡ、Ｂと接触した後、個室２へ移動し、１０：３０～１１：００の時間帯においてユーザＤと接触。
・ユーザＹは、携帯端末１０を所持し、１０：００～１１：００の時間帯において個室１を巡回し、ユーザＢ、Ｃと接触。
・後にユーザＡから感染症の感染報告あり。

ユーザＸの携帯端末１０は、１０：００～１１：００の間にユーザＡ、Ｂ、Ｄのビーコン端末３０からビーコン信号を受信し、ユーザＡ、Ｂ、Ｄのタグ識別情報を記憶する（図１６のＢ参照）。ユーザＸの携帯端末１０は、ユーザＸの携帯端末識別情報とともに、ユーザＡ、Ｂ、Ｄのタグ識別情報、ビーコン信号の受信日時情報を含む接触データを、管理サーバ２０に送信する。

一方、ユーザＹの携帯端末１０は、１０：００～１１：００の間にユーザＢ、Ｃのビーコン端末３０からビーコン信号を受信し、ユーザＢ、Ｃのタグ識別情報を記憶する（図１６のＢ参照）。ユーザＹの携帯端末１０は、ユーザＹの携帯端末識別情報とともに、ユーザＢ、Ｃのタグ識別情報、ビーコン信号の受信日時情報を含む接触データを、管理サーバ２０に送信する。

管理サーバ２０は、ユーザＸの携帯端末１０の接触データと、ユーザＹの携帯端末１０の接触データを比較する。管理サーバ２０は、１０：００～１１：００の時間帯において、ユーザＢのタグ識別情報が重複していることから（図１６のＣ参照）、ユーザＸとユーザＹは、それぞれ同一のユーザＢに接触したと判断する。そして、管理サーバ２０は、ユーザＸの携帯端末１０とユーザＹの携帯端末１０の各接触データを結合して結合リストＣＬを作成する（図１６のＤ参照）。

図１６のＤに示すように、結合リストＣＬには、すでに感染報告のあったユーザ（感染者）Ａのタグ識別情報が含まれていることから、管理サーバ２０は、結合リストＣＬに基づき、接触候補者を抽出する。具体的には、結合リストＣＬには、ユーザＸ、Ｙの携帯端末識別情報、ユーザＡ、Ｂ、Ｃ、Ｄのタグ識別情報が含まれていることから、管理サーバ２０は、結合リストＣＬに携帯端末識別情報またはタグ識別情報が登録されているユーザＢ、Ｃ、Ｄ、Ｘ、Ｙを、接触候補者として抽出する。

その後、管理サーバ２０は、接触候補者として抽出したユーザＢ、Ｃ、Ｄ、Ｘ、Ｙに対して濃厚接触者に該当するか否かを判断するためのアンケートを送信する。一例として、ユーザＸ、Ｙについては、各携帯端末１０宛てにアンケートを送信する一方、ユーザＢ、Ｃ、Ｄについては、それぞれビーコン端末３０以外の端末（例えば、スマホやＰＣ）宛てにアンケートを送信する。なお、アンケートの内容は、例えば「１０:００～１１：００の時間帯に、個室１にいましたか？」など、滞在時間と滞在場所を問うメッセージでもよいが、これに限られない。

各ユーザＢ、Ｃ、Ｄ、Ｘ、Ｙは、自身の携帯端末などを利用して、アンケートに回答する。ここでは、ユーザＤのみが、１０：００～１１：００の時間帯において個室２に滞在しており、感染者Ａと接触していないことから、管理サーバ２０は、アンケートの回答結果に基づき、ユーザＤを非濃厚接触者と判断する一方、ユーザＢ、Ｃ、Ｘ、Ｙを濃厚接触者と判断する（図１６のＥ参照）。

管理サーバ２０は、濃厚接触者、非濃厚接触者を特定すると、これを各ユーザが所属する企業などのコンピュータや、各ユーザの携帯端末などに通知する。
このように、携帯端末１０だけでなくビーコン端末３０との接触も検知可能とすることで、システム全体の消費電力量を抑えることが可能となる。

ここで、各ユーザに送信するアンケートについては、回答内容の精度を高めるために、位置情報を利用してもよい。例えば、ユーザＸ、Ｙの携帯端末１０は、ＧＰＳや施設内のビーコンなどを利用して位置情報を取得し、取得した位置情報を接触データに含めて管理サーバ２０に送信する。管理サーバ２０は、ユーザＸ、Ｙの携帯端末１０から取得した位置情報を利用（付与）して、ユーザＢ、Ｃ、Ｄ向けのアンケートを生成し、送信する。ユーザＢ、Ｃ、Ｄは、アンケートに付与された位置情報を確認することで、そのときに自分がどこにいたのか、記憶の呼び起こしが支援され、アンケートの回答内容の精度を高めることが可能となる。
また、以上説明した各実施形態及び応用例において、「部」とは、単に物理的手段を意味するものではなく、その「部」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や装置が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や装置の機能が１つの物理的手段や装置により実現されても良い。

１００…感染症対策システム、１０…携帯端末、２０…管理サーバ、１１０…記憶部、１２０…制御部、１３０…操作部、１４０…表示部、１５０…近距離無線通信部、１６０…接触データ取得部、１７０…行動データ取得部、１８０…ヘルスケアデータ取得部、１９０…通信部、２１０…記憶部、２２０…制御部、２３０…通信部、２４０…判定部、２５０…出力部、２６０…特定部、２７０…判断部、２８０…通知部、ＡＰ１…接触トレースアプリ、ＤＢ１…個別データベース、ＴＡ１…基準テーブル、ＴＡ２…健康リスク基準テーブル。

Claims (10)

1. 他人との接触状況をあらわす接触データを受信する第１受信部と、
   ユーザの健康状態をあらわすヘルスケアデータを受信する第２受信部と、
   ユーザの健康状態のリスクレベルを判定するための健康リスク基準情報を記憶する第１記憶部と、
   前記接触データに基づき、過去一定期間内に前記ユーザと接触した接触ユーザを特定する特定部と、
   前記接触ユーザのヘルスケアデータと、前記健康リスク基準情報とに基づき、前記ユーザの健康リスクを判断する判断部と、
   前記判断の結果を、前記ユーザに通知する通知部と
   を具備する感染症対策システム。
2. 前記ユーザの行動履歴をあらわす行動データを受信する第３受信部と、
   感染症のリスクレベルを判定するための感染症リスク基準情報を記憶する第２記憶部と、
   前記接触データと、前記行動データと、前記ヘルスケアデータと、前記感染症リスク基準情報とに基づき、前記ユーザの前記感染症のリスクレベルを判定する判定部と、
   前記判定の結果を出力する出力部とをさらに具備する、請求項１に記載の感染症対策システム。
3. 前記出力部は、前記ユーザの携帯端末に、当該ユーザのリスクレベルを色分けして表示する、請求項２に記載の感染症対策システム。
4. 前記出力部は、さらに、前記ユーザの携帯端末に、当該ユーザのリスクレベルに応じた行動指針をあらわす指針情報を表示する、請求項３に記載の感染症対策システム。
5. 子端末である複数のタグ端末と、親端末である複数の携帯端末と、各タグ端末及び各携帯端末を管理する管理サーバとを備えた感染症対策システムであって、
   前記各タグ端末は、
   当該タグ端末を識別するための子端末識別情報を含むビーコン信号を発信する発信部を備え、
   前記各携帯端末は、
   前記タグ端末から前記ビーコン信号を受信する受信部と、
   当該携帯端末を識別するための親端末識別情報と、前記ビーコン信号に含まれる子端末識別情報と、前記ビーコン信号の受信日時をあらわす受信日時情報とを含む接触データを、前記管理サーバに送信する送信部とを備え、
   前記管理サーバは、
   前記各携帯端末から送信される接触データを受信する受信部と、
   前記各携帯端末から送信される接触データに基づき、前記各携帯端末を利用する各ユーザと前記各タグ端末を利用する各ユーザとの接触状況を検知する検知部と
   を具備する、感染症対策システム。
6. 前記検知部は、前記各携帯端末から送信される接触データを比較することで、同一時間帯において、複数の携帯端末が同一のタグ端末と接触していることが判明した場合には、前記複数の携帯端末の接触データを結合して結合リストを生成する、請求項５に記載の感染症対策システム。
7. 他人との接触状況をあらわす接触データを受信する第１受信部と、
   企業に属する各ユーザの行動履歴をあらわす行動データを受信する第２受信部と、
   前記各ユーザの健康状態をあらわすヘルスケアデータを受信する第３受信部と、
   感染症のリスクレベルを判定するための基準情報を記憶する記憶部と、
   前記接触データと、前記行動データと、前記ヘルスケアデータと、前記基準情報とに基づき、前記各ユーザの前記感染症のリスクレベルを判定する判定部と、
   前記判定の結果を出力する出力部とを具備し、
   前記出力部は、前記各ユーザの携帯端末に、当該各ユーザのリスクレベルに応じた行動指針をあらわす指針情報を表示する一方、前記企業のコンピュータに、リスクレベルごとの前記各ユーザの割合を表示する、感染症対策システム。
8. 前記出力部は、前記ユーザの携帯端末に、当該ユーザのリスクレベルを色分けして表示する、請求項７に記載の感染症対策システム。
9. 前記感染症のリスクレベルは、複数存在し、
   前記出力部は、前記感染症の各リスクレベルの変動履歴に基づき、リスクレベルの変動を予想し、予想した結果を前記企業のコンピュータに表示する、請求項７または８に記載の感染症対策システム。
10. 前記各受信部は、前記ユーザの許諾が得られた場合に、それぞれ前記接触データ、前記行動データ、前記ヘルスケアデータを受信する、請求項７から９のいずれか一項に記載の感染症対策システム。

Images