JP6925071B1 - 情報処理システム、情報処理方法およびコンピュータプログラム - Google Patents

Abstract

【課題】感染者の行動履歴の特定および感染者から感染症がうつった可能性が高い者の抽出を容易に確実に行う情報処理システム、情報処理方法及びコンピュータプログラムを提供する。【解決手段】第一の情報処理装置から発信された信号を受信する機能を有する第二の情報処理装置と、少なくとも第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムであって、サーバ装置３００は、記憶部３１０、抽出部３２０、推定部３３０及び特定部３４０を備える。特定部は、推定部により推定された位置と略同一の位置に、特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する。【選択図】図５

Description

本発明は、情報処理システム、情報処理方法およびコンピュータプログラムに関する。

新型コロナウイルス（ＣＯＶＩＤ−１９）等の感染症に罹患した者（以下、「感染者」という。）が特定された場合に、かかる感染者から感染症がうつった可能性の高い他の者を特定するためには、感染者の行動履歴を知る必要がある。

現状、かかる行動履歴は、感染者に聞き取り調査を行うことにより得るのが一般的であり、不確実なものであった。

最近では、互いのスマートフォンの近距離無線通信機能を利用して近くにいる他人の情報を自身のスマートフォンに記録しておくことで、自身が感染者となった場合に当該情報に基づいて濃厚接触者を特定するというアプリケーションが開発されている。

なお、ここでいう濃厚接触者は、一般的に、手で触れること又は対面で会話することが可能な距離で、必要な感染予防策なしで、感染者と接触があった者とされている。

"シンガポール、コロナ感染をアプリで追跡、政府開発"、日本経済新聞電子版、令和２年４月２日検索＜URL:https://www.nikkei.com/article/DGXMZO57056430Q0A320C2FF8000/＞

しかしながら、かかる技術によれば、他人の情報は個々のスマートフォンに記録されているため、行動履歴の追跡チームによる管理が容易ではないという問題がある。

また、近頃では、感染者との直接的な接触がなくとも、すなわち、濃厚接触者でなくとも、感染が確認される例が報告されている。

したがって、本開示の目的は、感染者の行動履歴の特定および感染者から感染症がうつった可能性が高い者の抽出を容易に確実に行うことが可能な情報処理システム、情報処理方法およびコンピュータプログラムを提供することにある。

本開示の情報処理装置は、第一の情報処理装置から発信された信号を受信する機能を有する第二の情報処理装置と、少なくとも第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムであって、サーバ装置は、第二の情報処理装置の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置が受信した信号を発信する一以上の第一の情報処理装置の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する記憶部と、サーバ装置が、一以上の第一の情報処理装置の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、特定の第一の識別情報が含まれるセットの中から、特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する抽出部と、抽出部により抽出されたセットに含まれる強度情報に基づいて、特定の第一の情報処理装置が存在した位置を推定する推定部と、推定部により推定された位置と略同一の位置に、特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する特定部とを備えることを特徴とする。

特定部は、推定部により推定された位置と略同一の位置に、第一の情報処理装置が存在した日時よりも後で、かつ、所定の終了日時より前の間に存在したと推定される、他の第一の情報処理装置を特定することができる。

サーバ装置は、所定の終了日時を、第三の情報処理端末から受信した第三識別情報および当該第三識別情報の受信時刻に基づいて設定することができる。

第三の情報処理端末は、所定の領域毎に設置された媒体に表示された二次元バーコードを読み取ることにより第三識別情報をサーバ装置に送信することができる。

特定の日時情報は、特定の日時よりも第一の期間だけ前の日時を含むことができる。

特定の日時は、特定の第一の情報処理装置を利用する特定のユーザが所定の感染症であると診断された日時であり、第一の期間は、感染症の潜伏期間であることができる。

特定の日時情報は、特定の日時よりも第二の期間だけ後の日時を含むことができる。

サーバ装置は、さらに、特定部により特定された他の第一識別情報を有する他の第一の情報処理装置を有するユーザに対して、特定の情報を通知する通知部を有することができる。

通知部は、特定部により特定された他の第一識別情報のうち、拒否情報が関連付けられていない他の第一識別情報を有する他の第一の情報処理装置を有するユーザに対して、特定の情報を通知することができる。

特定部は、推定部により推定された位置から所定範囲内に、特定の第一の情報処理装置が存在した日時に存在したと推定される、他の第一の情報処理装置を有する他のユーザを濃厚接触者として特定することができる。

第二の情報処理装置は、所定の領域に複数設置され、推定部は、複数の第二の情報処理装置から抽出されたセットに含まれる強度情報に基づいて、特定の第一の情報処理装置が存在した位置を推定することができる。

本開示の情報処理方法は、第一の情報処理装置から発信された信号を受信する機能を有する第二の情報処理装置と、少なくとも第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムにおいて実行される情報処理方法であって、サーバ装置に、第二の情報処理装置の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置が受信した信号を発信する一以上の第一の情報処理装置の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する記憶ステップと、サーバ装置が、一以上の第一の情報処理装置の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、特定の第一の識別情報が含まれるセットの中から、特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する抽出ステップと、抽出ステップにおいて抽出されたセットに含まれる強度情報に基づいて、特定の第一の情報処理装置が存在した位置を推定する推定ステップと、推定ステップにおいて推定された位置と略同一の位置に、特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する特定ステップとを実行させることを特徴とする。

本開示のコンピュータプログラムは、第一の情報処理装置から発信された信号を受信する機能を有する第二の情報処理装置と、少なくとも第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムにおいて実行されるコンピュータプログラムであって、サーバ装置に、第二の情報処理装置の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置が受信した信号を発信する一以上の第一の情報処理装置の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する記憶機能と、サーバ装置が、一以上の第一の情報処理装置の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、特定の第一の識別情報が含まれるセットの中から、特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する抽出機能と、抽出機能において抽出されたセットに含まれる強度情報に基づいて、特定の第一の情報処理装置が存在した位置を推定する推定機能と、推定機能により推定された位置と略同一の位置に、特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する特定機能とを実現させることを特徴とする。

本開示によれば、感染者の行動履歴の特定および感染者から感染症がうつった可能性が高い者の抽出を容易に確実に行うことが可能な情報処理システム、情報処理方法およびコンピュータプログラムを提供することができる。

本開示の実施形態にかかる情報処理システムの構成の一例を示したシステム構成図である。 本開示の実施形態にかかる第一の情報処理装置のハードウェア構成を示すハードウェア構成図である。 本開示の実施形態にかかる第一の情報処理装置の機能構成を示す機能構成図である。 本開示の実施形態にかかる第二の情報処理装置の機能構成を示す機能構成図である。 本開示の実施形態にかかるサーバ装置の機能構成を示す機能構成図である。 本開示の実施形態にかかるサーバ装置の記憶部に記憶されるデータテーブルの一例を示したイメージ図である。 本開示の実施形態のイメージを示したイメージ図である。 本開示の実施形態にかかるサーバ装置の機能構成の他の例を示す機能構成図である。 本開示の実施形態にかかるサーバ装置の記憶部に記憶されるデータテーブルの一例を示したイメージ図である。 本開示の実施形態にかかる第二の情報処理装置の機能構成の他の例を示す機能構成図である。 本開示の実施形態に係るＩｏＴ接続システムの構成の一例を示したシステム構成図である。 本開示の実施形態に係るＩｏＴ接続システムの複数のプライベートクラウドの一例を示したイメージ図である。 本開示の実施形態に係るＩｏＴ接続システムのプライベートクラウドに接続される複数の第一のデバイスの一例を示したイメージ図である。 本開示の実施形態に係るＩｏＴ接続システムで提供されるサービスの流れの一例を示したイメージ図である。 本開示の実施形態にかかるＩｏＴルータのハードウェア構成を示すハードウェア構成図である。 本開示の実施形態に係るＩｏＴ接続システムで提供されるサービスの流れの一例を示したイメージ図である。 本開示の実施形態に係るＩｏＴ接続システムの接続界面を説明するためのイメージ図である。 本開示の実施形態に係るＩｏＴ接続システムで提供されるサービスの流れの他の例を示したイメージ図である。 本開示の実施形態に係るＩｏＴ接続システムで提供される仮想ドライバ機能の流れの一例を示したイメージ図である。 本開示の実施形態に係るＩｏＴ接続システムで提供される仮想ドライバ機能の流れの他の例を示したイメージ図である。 本開示の実施形態に係る情報処理方法のフローの一例を示したフロー図である。 本開示の実施形態に係る情報処理システムの構成の他の例を示した概念図である。

本開示の情報処理システムの実施形態について、図面を参照しながら説明する。

図１に一例として示されるように、本開示の情報処理システム１０００は、第一の情報処理装置１００から発信された信号を受信する機能を有する第二の情報処理装置２−０と、少なくとも第二の情報処理装置２００とインターネットを介して接続可能なサーバ装置３００とを備える。

第一の情報処理装置１００は、信号を発信する機能を有する装置である。

信号を発する機能とは、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）やＷｉ−Ｆｉ等の無線技術を使い、当該信号を受信可能な装置に対して情報を発信することができる機能である。

第一の情報処理装置１００は、上記信号を発する機能を有する装置であれば特に限定されないが、一例としてスマートフォンやタブレット等の情報処理装置とすることができる。

そして、上記信号を発する機能は、専用のアプリケーションをインストールすることにより第一の情報処理装置１００により実現されることができる。

第二の情報処理装置２００は、上記信号を受信する機能を有する装置である。

第二の情報処理装置２００は、上記信号を受信する機能を有する装置であれば特に限定されないが、一例としてスマートフォンやタブレット等の情報処理装置とすることができる。また、第二の情報処理装置２００として後述するＩｏＴルータを用いてもよい。

そして、上記信号を受信する機能は、専用のアプリケーションをインストールすることにより第二の情報処理装置２００により実現されることができる。

サーバ装置３００は、第二の情報処理装置２００とインターネットを介して接続可能な装置である。

ここで、図２を用いて、第一の情報処理装置１００のハードウェア構成について説明する。第一の情報処理装置１００は、プロセッサ１０１と、メモリ１０２と、ストレージ１０３と、入出力インターフェース（入出力Ｉ／Ｆ）１０４と、通信インターフェース（通信Ｉ／Ｆ）１０５とを含むことができる。各構成要素は、バスＢを介して相互に接続される。

第一の情報処理装置１００は、プロセッサ１０１と、メモリ１０２と、ストレージ１０３と、入出力Ｉ／Ｆ１０４と、通信Ｉ／Ｆ１０５との協働により、本実施形態に記載される機能、方法を実現することができる。

プロセッサ１０１は、ストレージ１０３に記憶されるプログラムに含まれるコード又は命令によって実現する機能、及び／又は、方法を実行する。プロセッサ２０１は、例えば、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、１又は複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩ等と呼称されることもある。

メモリ１０２は、ストレージ１０３からロードしたプログラムを一時的に記憶し、プロセッサ１０１に対して作業領域を提供する。メモリ１０２には、プロセッサ１０１がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ１０２は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等を含む。

ストレージ１０３は、プログラムを記憶する。ストレージ１０３は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等を含む。

通信Ｉ／Ｆ１０５は、ネットワークアダプタ等のハードウェアや通信用ソフトウェア、及びこれらの組み合わせとして実装され、ネットワークを介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１０５は、ネットワークを介して、他の情報処理装置との通信を実行する。通信Ｉ／Ｆ１０５は、各種データをプロセッサ１０１からの指示に従って、他の情報処理装置に送信する。また、通信Ｉ／Ｆ１０５は、他の情報処理装置から送信された各種データを受信し、プロセッサ１０１に伝達する。

入出力Ｉ／Ｆ１０４は、第一の情報処理装置１００に対する各種操作を入力する入力装置、及び、第一の情報処理装置１００で処理された処理結果を出力する出力装置を含む。入出力Ｉ／Ｆ１０４は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。

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

出力装置は、プロセッサ１０１で処理された処理結果を出力する。出力装置は、例えば、タッチパネル、スピーカ等を含む。

上記第二の情報処理装置２００およびサーバ装置３００についても、上記第一の情報処理装置１００と同様のハードウェア構成とすることができる。

そして、本開示の第一の情報処理装置１００は、図３に示されるように、発信部１１０を有することができる。

発信部１１０は、第一の情報処理装置１００の第一識別情報を含む信号を発信するものである。

第一識別情報は、第一の情報処理装置１００を特定可能な識別情報であれば特に限定されるものではない。第一識別情報の例として、ＵＤＩＤ（Unique Device IDentifier）やＵＵＩＤ（Universally Unique IDentifier）等を用いることができるが、プライバシー・セキュリティー上の観点からＵＵＩＤを第一識別情報とするのが好ましい。

第二の情報処理装置２００は、図４に示されるように、受信部２１０と、送信部２２０とを有することができる。

受信部２１０は、第一の情報処理装置１００から発信された信号を受信するものである。

送信部２２０は、時刻情報、強度情報および第一識別情報を、第二の情報処理装置２００の第二識別情報とともにサーバ装置３００に送信するものである。

時刻情報は、上記信号を受信した時刻に関する情報である。かかる時刻情報は日付および時刻を含み、時刻は時分秒を含むものとすることができる。

強度情報は、信号の受信強度に基づく情報である。かかる受信強度に関する情報は受信した電波の強度を示す電波強度に加え、基準強度を含むことができる。そして、これらから第一の情報処理装置１００と第二の情報処理装置２００との推定距離を算出しておくことも可能であり、この推定距離を受信強度に基づく情報としてもよい。かかる推定距離の算出については、第二の情報処理装置２００で行うものとしてもよいし、サーバ装置３００で行うものとしてもよい。

第二識別情報は、第二の情報処理装置２００を特定可能な識別情報であれば特に限定されるものではない。第二識別情報の例として、第一識別情報と同様に、ＵＤＩＤ（Unique Device IDentifier）やＵＵＩＤ（Universally Unique IDentifier）等を用いることができるが、プライバシー・セキュリティー上の観点からＵＵＩＤを第二識別情報とするのが好ましい。このＵＵＩＤは、上述した専用のアプリケーションにより発行される数値であって、個人情報を含まないものとすることができる。

そして、サーバ装置は、図５に示すように、記憶部３１０と、抽出部３２０と、推定部３３０と、特定部３４０とを備える。

記憶部３１０は、第二の情報処理装置２００の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置２００が受信した信号を発信する一以上の第一の情報処理装置１００の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する。

図６は、記憶部３１０が記憶するデータテーブルの一例を示したものである。図６に示されるように、第二の情報処理装置２００の識別ＩＤには、受信した信号を発信した第一の情報処理装置１００の識別ＩＤ、受信時刻、強度情報が関連付けられることができる。

なお、図６では時刻情報が各第一識別情報に１つのみ示しているが、信号を最初に受信した時刻から受信しなくなった時刻まで所定の間隔で記憶されることができる。

抽出部３２０は、サーバ装置３００が、一以上の第一の情報処理装置１００の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、特定の第一の識別情報が含まれるセットの中から、特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する。

具体的には、受付部３２０は、特定の第一の情報処理装置１００Ａの特定の第一識別情報の指定を受け付ける。この特定の第一の情報処理装置１００Ａは、感染者（検査により感染症であると診断された者。以下、「特定のユーザ」と呼ぶ。）の所有するスマートフォン等の携帯端末とすることができる。

上記指定は、本開示の情報処理システム１０００を利用するユーザにより所定の情報処理端末を介して行われるものとする。

この場合、上記指定を行うユーザの例としては、感染者の行動履歴を追跡する者、例えば、保健所の担当者や医療従事者などであるが、これらの者に限定されるものではない。

例えば、感染者である特定のユーザが、自身の第一の情報処理装置１００から感染症であると診断された旨の情報をサーバ装置３００に送信し、自身の第一の情報処理装置１００が特定の第一の情報処理装置１００Ａであるとして特定の第一識別情報を指定することもできる。

そして、特定の日時とは、特定のユーザが、検査により感染症であると診断された日時とすることができる。なお、基本的には、何かしらの症状が出た場合に、ユーザは医療機関を受診して感染症の検査を行うものであるから、この感染症であると診断された日時は、感染症の発症日ということもできる。なお、特定の日時については、日さえ含まれれば、時分を含まなくてもよい。

また、特定の日時に関連する特定の日時情報には、特定の日時よりも第一の期間だけ前の日時から、特定の日時までの期間が含まれるものとすることができる。この第一の期間は、感染症の潜伏期間とすることができ、感染症の種類によって適宜設定することができる。一例として、第一の期間は２日とする。

そして、抽出部３２０は、特定のユーザの感染症の発症日に基づいて、潜伏期間を考慮した第一の期間に、特定のユーザがどの部屋のどの場所にいたかを特定するために、記憶部３１０に記憶された特定の第一の識別情報が含まれるセットの中から、第一の期間に含まれる時刻情報を含むセットを抽出する。

推定部３３０は、抽出部３２０により抽出されたセットに含まれる強度情報に基づいて、特定の第一の情報処理装置１００Ａが存在した位置を推定する。

図７は、一例として、デスク１〜５およびチェア６〜１０が配置された所定の領域Ｒにおいて、特定の第一の情報処理装置１００Ａを有する特定のユーザがデスク３に対応するチェア８に着席した状態を想定したイメージ図である。

なお、感染対策として、デスク１〜５の間には仕切り板が設けられているのが好ましい。

このような状態において、特定のユーザは、ウイルスのついた手でデスク３やチェア８を触ったり、咳やくしゃみなどにより周囲にウイルスを拡散させたりしてしまう可能性がある。

周囲に拡散したウイルスは、特定のユーザと同じタイミングで同じ領域Ｒにいた第一の情報処理端末１００Ｂまたは第一の情報処理端末１００Ｃを有するユーザを感染させる可能性があり（これら濃厚接触者の特定については後述する。）、デスク３やチェア８に付着したウイルスは、特定のユーザがいなくなった後でも、デスク３やチェア８を触ったユーザを感染させる可能性がある。

そして、所定の領域Ｒには、一以上の第二の情報処理装置２００が設置され、第二の情報処理装置２００は、一以上の第一の情報処理装置１００からの信号を受信する。

記憶部３１０に強度情報として電波強度が記憶されている場合には、予め基準距離で測定された基準強度に基づいて推定距離が算出され、特定の第一の情報処理装置１００Ａが存在した位置が推定される。なお、すでに算出された推定距離が記憶部３１０に記憶されている場合には、かかる記憶された推定距離に基づいて特定の第一の情報処理装置１００Ａが存在した位置が推定されるものとする。

そして、特定部３４０は、推定部３３０により推定された位置と略同一の位置に、特定の第一の情報処理装置１００Ａが存在した日時よりも後に存在したと推定される、他の第一の情報処理装置１００Ｄを有する他のユーザを接触感染可能性者として特定する。

推定部３３０により推定された位置と略同一の位置とは、一例として、チェア８に着席している特定のユーザが、ウイルスのついた手で触ることにより、および／または、咳やくしゃみなどによりウイルスが付着した範囲、すなわち、チェア８に着席していると推定される位置とすることができる。

以上の構成によれば、上述した従来技術の問題の少なくとも一部を解決又は緩和する技術的な改善を提供することができる。具体的には、本開示によれば、感染者の行動履歴の特定および感染者から感染症がうつった可能性が高い者の抽出を容易に確実に行うことが可能となる。

また、本開示の情報処理システムは、特定のユーザの感染症の発症日に基づいて、潜伏期間を考慮した期間に、特定のユーザがどの部屋のどの場所にいたかを推定し、その後、同じ部屋の同じ場所にいたと推定される他のユーザ（接触感染可能性者）を特定することが可能になる。

また、会社内の各部屋に第二の情報処理装置２００を設置しておけば、感染者が生じた場合に、感染者がどの部屋にどのくらいの時間滞在したか、濃厚接触者または接触感染可能性者は誰かなどの情報を迅速に抽出することができる。

濃厚接触者または接触感染可能性者を迅速に特定することで、会社内に出入りした者全員ではなく、濃厚接触者または接触感染可能性者のみを自宅待機させるなどの効果的な対応を迅速にとることができる。その結果、事務所の全閉鎖といった事態を避けることができ、ＢＣＰ（事業継続性）対策にもなる。

また、第二の情報処理装置２００は、所定の領域に複数設置されることができる。

この場合、推定部３３０は、複数の第二の情報処理装置２００から抽出されたセットに含まれる強度情報に基づいて、特定の第一の情報処理装置が存在した位置を推定することができる。かかる推定の技術については、既知の技術を用いることができる。

以上の構成によれば、位置の推定の精度を向上させることができる。

特定部３４０は、推定部３３０により推定された位置と略同一の位置に、第一の情報処理装置が存在した日時よりも後で、かつ、所定の終了日時より前の間に存在したと推定される、他の第一の情報処理装置を特定することができる。

所定の終了日時とは、すなわち、付着したウイルスが死滅した日時である。ウイルスが付着してから自動的に死滅するまでの期間は、ウイルスの種類および被付着物の材質等に基づいて適宜設定されることができる。一例として、木製のデスクに付着したコロナウイルスが死滅するまでは、約２日程度かかると言われている。

あるいは、所定の終了日時とは、すなわち、ウイルスが付着した可能性のある被付着物を除菌した日時である。ウイルスが付着してから除菌されるまでの期間は、利用の都度除菌される場合、清掃時に除菌される場合などによって異なる。

このように、ウイルスが死滅または被付着物が除菌された場合には、その後にその場所にいても感染の可能性は低いため、所定の終了日時より後のユーザの特定は不要となる。

サーバ装置３００は、所定の終了日時を、第三の情報処理端末から受信した第三識別情報および当該第三識別情報の受信時刻に基づいて設定することができる。

第三の情報処理端末は、一例として、デスクやチェアなどの除菌を行う清掃員が利用するものとする。これによれば、所定の領域Ｒに設置された第二の情報処理装置２００が、清掃員が有する第三の情報処理端末から発信された第三識別情報を受信した場合に、デスクおよびチェアが除菌された（ウイルスが取り除かれた）として所定の終了日時を設定することができる。

あるいは、第三の情報処理端末は、所定の領域毎に設置された媒体に表示された二次元バーコードを読み取ることにより第三識別情報をサーバ装置３００に送信することができる。

二次元バーコードは、一例としてＱＲコード（登録商標）であり、媒体はデスクに添付可能なシール等とすることができる。

このように、第三識別情報の受信により、第二の識別情報に関連付けて記憶される時系列のデータにタイムスタンプを押すことができるようになる。

また、特定の日時情報は、特定の日時よりも第二の期間だけ後の日時を含むものとすることができる。

特定の日時が感染症であると診断された日時である場合には、その後に外出（会社等に出社）することはないと考えられるが、特定の日時が、症状が出た日時であって、その後、診断されるまでの間に会社に出社等していた場合には、特定の日時情報には、特定の日時から最終出社日時までの間の期間（第二の期間）を含ませる必要がある。

サーバ装置３００は、図８に示すように、さらに、通知部３５０を有することができる。

通知部３５０は、特定部３４０により特定された他の第一識別情報を有する他の第一の情報処理装置を有するユーザに対して、特定の情報を通知する。

特定の情報とは、一例として、接触感染可能性者であることを知らせる内容の情報とすることができる。かかる情報には、さらに、感染症に対応が可能な近くの施設の情報、相談窓口の電話番号などの情報を含めてもよい。

通知は、プッシュ通知の技術を利用して強制的に行うのが好ましい。

通知部３５０は、特定部３４０により特定された他の第一識別情報のうち、拒否情報が関連付けられていない他の第一識別情報を有する他の第一の情報処理装置を有するユーザに対して、特定の情報を通知することができる。

拒否情報は、ユーザによって登録されるものであって、一例として、チェア８に着席する前に、デスク３とチェア８を自身で除菌した、離席後すぐに手洗いを行ったなど、被付着物への接触による感染の防止対策を行ったことを示す情報である。

以上、感染者との直接的な接触がない接触感染可能性者を特定する発明についての実施形態を説明したが、本開示の情報処理システムは、濃厚接触者を特定することも可能である。

具体的には、特定部３４０は、推定部３３０により推定された位置から所定範囲内に、特定の第一の情報処理装置１００Ａが存在した日時に存在したと推定される、他の第一の情報処理装置を有する他のユーザを濃厚接触者として特定することができる。

この濃厚接触者として特定される他のユーザは、図７に示す第一の情報処理装置１００Ｂまたは第一の情報処理装置１００Ｃを有するユーザである。

特定の第一の情報処理装置１００Ａの特定の第一識別情報が図６における「１００００２」であった場合に抽出される他の第一識別情報のイメージを示した例を図９に示す。

特定の第一の情報処理装置１００Ａが存在した日時は、一例として、特定の第一の情報処理装置からの信号を最初に受信した時刻から受信しなくなった時刻まで所定の間隔で記憶される時刻のすべてとすることができる。

あるいは、特定の第一の情報処理装置１００Ａが存在した日時は、他の例として、特定の第一の情報処理装置からの信号を最初に受信した時刻、および、当該最初に受信した時刻から受信しなくなった時刻までの時間に基づいて算出される滞在時間を含むことができる。

さらに、抽出部３２０は、強度情報に基づくフィルタ条件に基づいて、他の第二識別情報を抽出してもよい。

すなわち、感染者が第二の情報処理装置２００が設置されたある部屋にいると推定される場合に、強度情報に基づいて当該部屋の外にいると推定される者については、濃厚接触者として抽出しなくともよい。

通知部３３０は、抽出された他の第一の情報処理装置に対して、特定の情報を通知する。

特定の情報とは、一例として、濃厚接触者であることを知らせる内容の情報とすることができる。かかる情報には、さらに、感染症に対応が可能な近くの施設の情報、相談窓口の電話番号などの情報を含めてもよい。

通知は、プッシュ通知の技術を利用して強制的に行うのが好ましい。

また、第二の情報処理装置２００は、図１０に示されるように、取得部２３０と、環境情報送信部２４０とをさらに有することができる。

取得部２３０は、設置場所の環境情報を所定のセンサから取得する。

所定のセンサは設置場所の環境情報を測定可能な物であれば特に限定されるものではないが、一例として、室温センサ、湿度センサ、照度センサ、気圧センサ、騒音センサ、各種ガス濃度センサ、不快指数センサ、熱中症警戒度センサの少なくとも一つとすることができる。

ガスセンサが測定可能なガスの例としてはＣＯ_２、揮発性有機溶媒量線などとすることができる。

環境情報送信部２４０は、当該環境情報を受信した時刻に関する時刻情報を、環境情報とともにサーバ装置３００に送信する。

そして、サーバ装置３００の記憶部３１０は、第二の情報処理装置２００から受信した環境情報および時刻情報を、第二識別情報に関連付けて記憶することができる。

そして、サーバ装置３００の抽出部３３０は、第二の情報処理装置２００から受信した環境情報が特定の条件を満たす場合に、第二識別情報に関連付けて記憶された１以上の第一識別情報を抽出してもよい。

特定の条件とは、いわゆる三密（密閉・密集・密接）の条件を満たす条件とすることができる。具体的な数値については予め適切に設定されることができる。

また、上述した通知部３５０は、特定の条件を満たす場合に抽出された１以上の第一識別情報を有する第一の情報処理装置１００の少なくとも一つに対して、注意情報を通知することができる。

すなわち、部屋が三密の条件を満たしてしまっている場合に、会議の開催者などに対して換気などを促す等の注意情報を通知することができる。

あるいは、環境情報が特定の条件を満たす場合に、室内のＩｏＴデバイス（エアコン、空気清浄機、加湿器等）を自動制御することにより三密を解消させるようにしてもよい。ＩｏＴデバイスの自動制御については、後述するように第二の情報処理装置２００がＩｏＴルータである場合に適用することができる。

そして、本開示における第二の情報処理装置２００は、ＩｏＴルータとすることができる。

ＩｏＴルータは、図１１に示されるように、クラウド上で実現されるＩｏＴハブ１２００、および、ローカルにありＩｏＴハブ１２００と接続されるＩｏＴルータ１３００を備えるＩｏＴ接続システム２０００におけるＩｏＴルータ１３００である。

ここで、本開示の実施形態におけるＩｏＴ接続システム２０００の実施形態について、図面を参照しながら説明する。

図１１に示すように、本開示の実施形態におけるＩｏＴ接続システム２０００は、ＩｏＴハブ１２００およびＩｏＴルータ１３００を備えるものとする。

ＩｏＴハブ１２００は、クラウド上で実現されるものとする。具体的には、ＩｏＴハブ１２００は、クラウド内でホストされているマネージドサービスであり、ＩｏＴアプリケーション（以下「ＩｏＴアプリ」という。）とＩｏＴデバイスとの間の双方向通信に対する中継器として機能する。

ＩｏＴルータ１３００は、ローカルにあり、ＩｏＴハブ１２００とＷＡＮ（Wide Area Network）により接続されるものとする。

具体的には、ＩｏＴルータ１３００は、宅内ネットワークなどインターネットに接続されていないＩｏＴデバイスがＩｏＴハブ１２００に接続することを実現するものである。

そして、ＩｏＴハブ１２００は、第一のドライバ１２１０または第二のドライバ１２２０の少なくとも一方を有する。

第一のドライバ１２１０および第二のドライバ１２２０は、各ＩｏＴデバイスのメーカごとの仕様の違いを吸収するものである。

第一のドライバ１２１０は、第一のデバイス１４１０が接続可能なプライベートクラウド１４００と当該ＩｏＴハブ１２００とを接続するためのものである。

一例として、第一のデバイス１４１０とプライベートクラウド１４００とはＬＡＮ（Local Area Network）またはＷＡＮによる接続とし、プライベートクラウド１４００と第一のドライバ１２１０もＬＡＮまたはＷＡＮによる接続とするのが好ましい。

プライベートクラウド１４００は、第一のデバイス１４１０の事業者により提供されるものである。図１１ではプライベートクラウド１４００が一つである場合が示されているが、この数は一つに限られるものではなく、複数のプライベートクラウド１４００がＩｏＴハブ１２００に接続されることができる。また、ＩｏＴハブ１２００は、複数の第一のドライバ１２１０を有してもよい。

図１２は、異なる事業者Ａ，Ｂにより提供される２つのプライベートクラウド１４００Ａ，１４００Ｂの詳細を示したものである。図１２に示されるように、プライベートクラウド１４００Ａは、事業者Ａが提供するアプリケーションＡ（以下、「アプリＡ」とする。）と接続され、第一のデバイス１４１０に対してアプリＡによるサービスを提供するものである。

同様に、プライベートクラウド１４００Ｂは、事業者Ｂが提供するアプリケーションＢ（以下、「アプリＢ」とする。）と接続され、第一のデバイス１４１０に対してアプリＢによるサービスを提供するものである。

なお、図１１、１２では、プライベートクラウド１４００に第一のデバイス１４１０が一つだけ接続されている例が示されているが、図１３に示すように、一つのプライベートクラウド１４００に複数の第一のデバイス１４１０が接続されてもよい。

第一のデバイス１４１０は、事業者がプライベートクラウドを提供しているデバイスとすることができる。一例として、リモートロック機能を有する電子錠、ＡＩスピーカ、リモート操作が可能な介護ベッドなどが挙げられるが、特にこれらに限定されるものではない。

図１１に戻り、第二のドライバ１２２０は、第二のデバイス１５１０とＩｏＴハブ１２００とを直接接続するためのものである。

第二のデバイス１５１０は、インターネット上にあるＩｏＴハブ１２００とＷＡＮにより接続されることができる（ＬＡＮ経由でもよい）。

なお、図１１では第二のドライバ１２２０に第二のデバイス１５１０が一つだけ接続されている例が示されているが、一つの第二のドライバ１２２０に複数の第二のデバイス１５１０が接続されてもよい。また、ＩｏＴハブ１２００は複数の第二のドライバ１２２０を有してもよい。

第二のデバイス１５１０は、事業者がプライベートクラウドを提供していないデバイスとすることができる。一例として、扇風機、エアコン、窓、カーテン、照明などとすることができるが、特にこれらに限定されるものではない。

そして、ＩｏＴルータ１３００は、第三のドライバ１３１０を有する。また、ＩｏＴルータ１３００は、複数の第三のドライバ１３１０を有してもよい。

第三のドライバ１３１０は、第三のデバイス１６１０と当該ＩｏＴルータ１３００とを接続するためのものである。

一例として、第三のデバイス１６１０と第三のドライバ１３１０とはＬＡＮによる接続とし、ＩｏＴルータ１３００とＩｏＴハブ１２００とはＷＡＮによる接続とするのが好ましい。

第三のデバイス１６１０は、上述したとおり、宅内ネットワークなどインターネットに接続されていないＩｏＴデバイスとすることができる。また、第三のデバイス６１０は、セキュリティ、プライバシーおよびセーフティ上の観点で、直接ＩｏＴハブ１２００と接続すべきでないデバイスとすることができる。一例として、ガスコンロ、顔認証デバイス、センサ情報収集用データロガーなどとすることができるが、特にこれに限定されるものではない。ただし、後述する災害時のリスク低減の観点から、どのようなデバイスであっても第三のデバイス１６１０としてＩｏＴルータ１３００へ接続させるようにしてもよい。

このように、本発明のＩｏＴ接続システム２０００は、すべてのデバイスをクラウド上のＩｏＴハブ１２００に直接的に接続させるものではなく、一部のデバイスをローカル上のＩｏＴルータ１３００に接続させるハイブリッドタイプのＩｏＴ接続システムである。

以上によれば、直接接続されたＩｏＴデバイス同士のみならず、従来のプライベートクラウドに接続されたＩｏＴデバイス同士も、容易に相互接続させることが可能となる。

これにより、決まったメーカのＩｏＴデバイス同士しか繋がっていなかった従来とは異なり、様々なメーカのＩｏＴデバイスを容易に相互接続させることができる。また、様々なメーカのＩｏＴデバイスを相互接続させることにより、従来にはなかったユニークなサービスを創造することができるようになる。

例えば、本発明のＩｏＴ接続システム２０００によれば、図１４に示すように、外部のサーバからの緊急地震速報を受信したら、ガスコンロに消火信号を送り、玄関ドアのカギを解錠するといったサービスを実現することも容易に可能である。

ここで、図１５を用いて、情報処理端末（ＩｏＴハブ）１２００のハードウェア構成について説明する。情報処理端末１２００は、プロセッサ１２０１と、メモリ１２０２と、ストレージ１２０３と、入出力インターフェース（入出力Ｉ／Ｆ）１２０４と、通信インターフェース（通信Ｉ／Ｆ）１２０５とを含むことができる。各構成要素は、バスＢを介して相互に接続される。

情報処理端末１２００は、プロセッサ１２０１と、メモリ１２０２と、ストレージ１２０３と、入出力Ｉ／Ｆ１２０４と、通信Ｉ／Ｆ１２０５との協働により、本実施形態に記載される機能、方法を実現することができる。

プロセッサ１２０１は、ストレージ１２０３に記憶されるプログラムに含まれるコード又は命令によって実現する機能、及び／又は、方法を実行する。プロセッサ１２０１は、例えば、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、１又は複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩ等と呼称されることもある。

メモリ１２０２は、ストレージ１２０３からロードしたプログラムを一時的に記憶し、プロセッサ１２０１に対して作業領域を提供する。メモリ１２０２には、プロセッサ１２０１がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ１２０２は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等を含む。

ストレージ１２０３は、プログラムを記憶する。ストレージ１２０３は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等を含む。

通信Ｉ／Ｆ１２０５は、ネットワークアダプタ等のハードウェアや通信用ソフトウェア、及びこれらの組み合わせとして実装され、ネットワークを介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１２０５は、ネットワークを介して、他の情報処理装置との通信を実行する。通信Ｉ／Ｆ１２０５は、各種データをプロセッサ１２０１からの指示に従って、他の情報処理装置に送信する。また、通信Ｉ／Ｆ１２０５は、他の情報処理装置から送信された各種データを受信し、プロセッサ１２０１に伝達する。

入出力Ｉ／Ｆ１２０４は、情報処理端末１２００に対する各種操作を入力する入力装置、及び、情報処理端末１２００で処理された処理結果を出力する出力装置を含む。入出力Ｉ／Ｆ１３０４は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。

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

出力装置は、プロセッサ１２０１で処理された処理結果を出力する。出力装置は、例えば、タッチパネル、スピーカ等を含む。

上記ＩｏＴルータ１３００についても、上記ＩｏＴハブ１２００と同様のハードウェア構成とすることができる。

また、ＩｏＴルータ１３００は、所定の基地局と通信可能な情報処理端末とするのが好ましい。

所定の基地局と通信可能な情報処理端末は、一例として、スマートフォンやタブレット端末などのＳＩＭカードを挿入して用いる情報処理端末である。ＩｏＴルータ１３００とＩｏＴハブ１２００との間の通信容量はひと月に１００Ｍバイト以下の低容量であることから、ＩｏＴルータ１３００には通信容量が少ない低額なＳＩＭカードを挿入すれば足りる。一例として、一つの会議室の周辺に平均１０ビーコン（人）が存在し、５分単位で情報をサーバに送信した場合には必要な通信容量は１７．３Ｍ／会議室（月）である。

また、ＩｏＴルータ１３００は、バッテリを含むものとする。かかるバッテリは、充電することにより電力を蓄えることができるものである。ＩｏＴルータ１３００は、満充電から３日程度は、電源に接続せずに本開示における機能を実現することができる。平常時（後述する特定の状況下に無い場合）には、ＩｏＴルータ１３００は、電源に接続して使用されるものとする。

そして、第三のデバイス１６１０は、特定の状況下において、ＩｏＴルータ１３００が備えるテザリング機能を介してＩｏＴハブ１２００に接続されることができる。

特定の状況は、第三のデバイス１６１０と所定の無線／有線ＬＡＮとの接続が途絶えた状況、ＩｏＴルータ１３００と所定の無線／有線ＬＡＮとの接続が途絶えた状況などとすることができるが、これに限られるものではない。

この特定の状況に陥る原因としては、停電が挙げられるが、これに限られるものではなく、Ｗｉ−Ｆｉ（登録商標）ルータの故障や接続不良等などが原因である場合もある。

また、テザリング機能としては公知の技術を用いることができ、Ｗｉ−Ｆｉテザリング、Ｂｌｕｅｔｏｏｔｈ（登録商標）テザリング、ＵＳＢテザリングなどの手法を用いることができる。

以上の構成によれば、プライベートクラウドごとにサイロ化状態になっている暮らしのＩｏＴを、インターネットを介して自由に相互接続して魅力的なサービスを提供することができる。

具体的には、本開示によれば、直接接続されたＩｏＴデバイス同士のみならず、従来のプライベートクラウドに接続されたＩｏＴデバイス同士も、容易に相互接続させることが可能となる。

また、以上の構成によれば、第三のデバイス１６１０が、特定の状況下において、ＩｏＴルータ１３００が備えるテザリング機能によりＩｏＴハブ１２００に接続されることで、災害等においてＩｏＴデバイスがネットワークに接続できない状態であっても、サービスを継続して利用することができるようになる。

また、ＩｏＴルータ１３００は、管理者装置によりＲｅｍｏｔｅ Ｃｏｎｔｒｏｌ（遠隔操作）が可能なものとするのが好ましい。かかる構成によれば、ＩｏＴルータの一つ一つをフルサポートすることができるようになる。

なお、上記遠隔操作は、管理者装置およびＩｏＴルータ１３００の双方に専用のアプリケーションをインストールしておくことで実現される。なお、遠隔操作のサポートのし易さを考慮して、ＩｏＴルータ１３００としての情報処理端末は、Ａｎｄｒｏｉｄ端末を用いるのが好ましい。

また、ＩｏＴルータ１３００は、管理者装置によりＣＤＭ（Connected Device Management：多様なデバイス管理）されるものとするのが好ましい。かかるＣＤＭは、既知のＭＤＭ（Mobile Device Management）の手法を用いて実現されることができる。かかる構成によれば、膨大数の世帯に設置されるＩｏＴルータを即時に一元管理し、遠隔監視・更新することができるようになる。また、ＣＤＭにより、デバイスの設定やアプリの配布、更新を遠隔監視制御することができるようになる。これにより、コスト削減と業務効率化を実現することができる。

また、ＩｏＴハブ１２００へは認証されたアプリやデバイスしか接続できないが、ＩｏＴルータ１３００は、ＩｏＴハブ１２００をローカル（宅内等）に延長し、ローカルでなければ実現できないリアルタイム性、セキュリティやプライバシーの確保、通信量の削減などに対応させることができる。

また、ＩｏＴルータ１３００を情報処理端末とすることで、顧客のスマートフォンや家庭内のインターネット回線を使用する必要がなくなり、想定外のトラブルが発生するリスクを低減させることができる。

また、本発明のＩｏＴ接続システム２０００は、第一のドライバ１２１０、第二のドライバ１２２０および第三のドライバ１３１０を作成するのにユーザが記述すべき情報は、デバイス定義およびコマンド定義に関する情報に限られてもよい。

ここで、第一のドライバ１２１０、第二のドライバ１２２０および第三のドライバ１３１０を作成する方法について説明を行う。なお、作成者は、ＩｏＴデバイスの製造開発に関するユーザ、あるいは、本発明のＩｏＴ接続システムの提供に関するユーザとすることができる。

なお、第一のドライバ１２１０および第二のドライバ１２２０と、第三のドライバ１３１０とは、同内容の情報が記述されればよく、プログラミング言語が異なるものであってもよい。

初めに、作成者は、デバイス定義として、利用機器一覧を定義する。一例として、利用機器として「気象センサ」、「屋内センサ」、「屋外センサ」、「不審者センサ」、「承認センサ」、「電力センサ」を定義する場合には、これらの名称およびそのＩＤとなる「weather」、「inhouse」、「outdoor」、「security」、「approve」、「power」を記述する。

続いて、作成者は、コマンド定義として、利用可能コマンドを定義する。一例として、「屋外センサ」の利用可能コマンドを定義する場合には、センサ値の観測コマンドを記述する。観測コマンドは、一例として、「観測」，「ゲット」，「屋外を観測します」などとすることができる。

以上のデバイス定義およびコマンド定義に関する情報を、作成者が穴埋め形式でプログラムに埋めていくことにより、第一のドライバ１２１０、第二のドライバ１２２０、第三のドライバ１３１０を完成させることができる。その他の部分については、ＳＤＫとして提供者から提供されることができる。

ＳＤＫ部分は、受信したコマンドでのデバイス操作処理に関する部分、収集したセンサデータ／操作結果データの前処理に関する部分、ＩｏＴハブへのデータ送信処理に関する部分を含むものとする。

以上の構成によれば、様々な形態のＩｏＴデバイスに対するドライバを簡易に完成させることができるため、ＩｏＴデバイスを柔軟にかつ容易に接続可能なＩｏＴ接続システムを実現することが可能となる。

通常、デバイスの開発に係るエンジニアは、Ｗｅｂ開発のエンジニアとは取得している技術の分野が異なり、デバイスをＩｏＴハブに繋ぐことができる技術レベルを有していない者も多い。

そのため、本開示のように、どのドライバ用プログラムに対しても共通の穴埋め形式の簡易な手法で作成が可能であることは、非常に有益である。これにより、ＩｏＴデバイスのＩｏＴハブへの接続に係る開発コストや開発期間を従来よりも抑えることができる。

また、開発コストの低減により、扇風機とエアコンのように掛けられるコストの許容値に差がある場合であっても、平等にＩｏＴハブへの接続を実現することができる。

続いて、本開示におけるＩｏＴ接続システム２０００に係るＩｏＴハブ１２００とＩｏＴアプリとの接続について説明する。

図１１に示されているように、ＩｏＴハブ１２００は、ＩｏＴアプリ１７００を利用するためのＷｅｂＡＰＩ１２３０を有することができる。なお、図１１に示すように、ＩｏＴアプリ１７００はサービスの数だけ接続されることができ、それぞれがＷｅｂＡＰＩ１２３０を使用して接続されることができる。

ＩｏＴアプリ１７００は、アプリ内にＩｏＴデバイス（センサ）からのデータ取得ロジックおよび／またはＩｏＴデバイスの操作ロジックを記述することで作成される。

データ取得ロジックは、取得したセンサデータの前処理を行う部分と、ＩｏＴハブ１２００のＡＰＩへの送信を行う部分とで構成される。必要な情報は、ＩｏＴ接続システム２０００の運営者から提供される接続先ＵＲＬ、運営者から提供されるＡＰＩキー、デバイス情報および実行コマンドである。

デバイスの操作ロジックは、操作したいデバイスコマンドの前処理を行う部分と、ＩｏＴハブ１２００のＡＰＩへの送信を行う部分とで構成される。必要な情報は、ＩｏＴ接続システム２０００の運営者から提供される接続先ＵＲＬ、運営者から提供されるＡＰＩキー、デバイス情報および実行コマンドである。

図１６は、ＩｏＴサービス利用者（エンドユーザ）が、ＩｏＴデバイス事業者により提供されたＩｏＴデバイスを用いて、ＩｏＴサービス提供事業者からＩｏＴサービスの提供を受けるフローを示した図である。図１６に示すように、初めに第一のデバイス１４１０からイベントの通知があると、プライベートクラウド１４００、第一のドライバ１２１０、ＷｅｂＡＰＩ１２３０、ＩｏＴアプリ１７００を介してエンドユーザにイベントが通知される。

続いて、エンドユーザがアクションを決定すると、ＩｏＴアプリ１７００、ＷｅｂＡＰＩ１２３０、第二のドライバ１２２０を介して第二のデバイス５１０にアクションの実行が指示される。

ＩｏＴデバイスの連携は、「〜がこうなったら〇〇する」といったイベント駆動型のプログラムで表現することができる。そして、この処理をマイクロサービスとして部品化し、共通化して使えるようにしたうえで、ＦａａＳ（Function as a Service）の関数として実装することができる。

ところで、上述したＩｏＴデバイスである第一のデバイス〜第三のデバイスは、近年のＩｏＴ分野の発展により様々なメーカにより開発・製造されることとなった。しかしながら、デバイスまたはＩｏＴアプリとの常時接続は、Ｇｏｏｇｌｅ社またはＡｐｐｌｅ社等の大手ベンダーが提供するプッシュ通知用サービスのためのサーバに接続可能なデバイスに限られるという問題があった。

本開示におけるＩｏＴハブ１２００は、すべてのＩｏＴデバイスの連携を目的として、常時接続機能と、ディレクトリ機能とを実現することを特徴とする。

常時接続機能は、第一のデバイス１４１０、第二のデバイス１５１０および第三のデバイス１６１０ならびにＩｏＴハブ１２００を介して利用可能なＩｏＴサービス（ＩｏＴアプリ１７００）を相互に常時接続させるものである。

ただし、ＩｏＴハブに接続されるＩｏＴデバイスには、常時接続が必須でないものと、必須なものの２種類がある。前者には、定期的または不定期的に情報を発信するセンサ系のデバイスが含まれる。後者には、リモコン操作を行う必要がある制御可能装置のようなデバイスが含まれる。よって、本開示における上記常時接続機能は、後者の常時接続が必須のＩｏＴデバイスに対しては常時接続を、前者の常時接続が必須でないＩｏＴデバイスに対しては求められた時に限定した接続を実現すればよい。

常時接続機能は、本開示におけるＩｏＴハブ１２００と第一のデバイス１４１０、第二のデバイス１５１０および第三のデバイス１６１０ならびにＩｏＴサービス１７００とを、ＩｏＴ向けのＭＱＴＴ（Message Queue Telemetry Transport）等の通信プロトコルを用いることで実現することができる。

また、ディレクトリ機能は、第一のデバイス１４１０、第二のデバイス１５１０および第三のデバイス１６１０ならびにＩｏＴサービスを相互に連携させる。

すなわち、ディレクトリ機能は、あるモノ（デバイス）からあるサービスへ、あるサービスからあるモノへ、あるモノからあるモノへ、モノまたはサービスを特定し、モノまたはサービスへ指示する機能を実現するものである。

そして、ディレクトリ機能は、連携元のデバイスにより指定された連携先のデバイスを、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報に基づいて特定することができる。

デバイスの識別情報は、ＩｏＴデバイスのＵＵＩＤである。ドライバの識別情報は、ドライバのＩＤである。接続界面の識別情報は、ドライバとＩｏＴハブ１２００との界面であるＲ界面を特定するための情報である。

また、ディレクトリ機能は、さらに、連携先のデバイスを、ＩｏＴハブ１２００の識別情報に基づいて特定することができる。

なお、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報は、所定の記憶装置に記憶され、当該記憶装置は、さらに、接続を許可しない接続元デバイスの識別情報および／またはデバイスの機能をホワイトリストとして記憶することができる。かかるリストについては、後述するサポート方法のメニュー票を利用することができる。

図１７は、本開示におけるＩｏＴ接続システムにおける相互接続インフラの構造を示した概念図である。図１７に示すように、アプリケーションとして示されるＩｏＴアプリとＩｏＴハブとの接続面はＰ界面であるが、ＷｅｂＡＰＩ（α、β、γ）を使用して接続することで標準化されたＱ界面持つことができる。

同様に、ＩｏＴデバイスとＩｏＴハブとの接続面はＳ界面であるが、ドライバ（Ａ〜Ｚ）を使用して接続することで標準化されたＲ界面を持つことができる。

従来、ＩｏＴアプリはＩｏＴデバイスの組み込みアプリと情報の授受を行うために、ＩｏＴアプリ側で宛先となるＩｏＴデバイスを指定する必要があるとともに、ＩｏＴデバイス側でもＩｏＴアプリから指定が可能な識別情報を持つ必要があった。

一方、本開示のＩｏＴ接続システムにおいて、上記宛先の指定はＩｏＴハブにより実現されるディレクトリ機能により行われる。

例えば、ＩｏＴデバイスの追加や交換は、ＩｏＴハブにドライバを追加して接続先を追加または切り替えることのみで対応可能となり、ＩｏＴアプリ自体を修正する必要がない。

すなわち、ＩｏＴアプリにおいて必要であったＩｏＴデバイスを指定する宛先部分、および、ＩｏＴデバイスにおいて必要であったＩｏＴアプリから指定が可能な識別情報部分は、いずれのＩｏＴハブに集約されることができる。

そのため、ＩｏＴデバイスの追加や交換は、アプリ開発者の工数を増やすことはなく、コストの低減につながる。

このように、本開示におけるＩｏＴ接続システムによれば、ＩｏＴデバイスの製造メーカや機種が異なっても、ＩｏＴハブに接続されることでプロトコルフリーな相互接続を実現することが可能となる。

また、図１８に示すように、本発明のＩｏＴハブ１２００は、関所エンジン１８００と接続されることができる。この関所エンジン１８００は、ＩｏＴハブ１２００がデバイスに指示する内容をチェックし、不適切なアクションが実行されることを防ぐためのものである。

例えば、“外気が爽やかなら、エアコンを止めて窓を開ける”、といったＩｏＴサービスを提供する場合、直後にゲリラ豪雨に見舞われると室内が濡れてしまうおそれがあるが、上記関所エンジン１８００は、このようなＩｏＴ由来の脅威を未然に防ぐためのものである。

また、本発明の第一のドライバ１２１０、第二のドライバ１２２０および第三のドライバ１３１０の少なくとも一つは、仮想デバイス機能を実現することができる。

この仮想デバイス機能は、第一のデバイス１４１０、第二のデバイス１５１０または第三のデバイス１６１０を仮想的に再現するものである。

図１９は、本発明の第二のドライバ１２２０が仮想デバイス機能を実現する例を示したものである。図１９に示すように、第二のドライバ１２２０に、第二のデバイス１５１０のコマンドの送受信を再現可能な仮想デバイス１９００を設けることにより、仮に第二のデバイス１５１０が接続されていなくても、第二のデバイス１５１０を用いるＩｏＴアプリの開発が可能となる。また、動作不良があった場合、現地に赴かずとも第二のデバイス１５１０とＩｏＴハブ１２００のどちらが故障しているのか故障切り分けを容易に行うことができる。

また、本発明では、図２０に示すように、ドライバではなくＩｏＴハブ１２００に仮想デバイス機能を実現させてもよい。これは、ローカルに存在するＩｏＴルータ１３００に接続される第三のデバイス１６１０の故障切り分けに有効な手段である。

上述したとおり、本開示におけるＩｏＴハブは、異なる通信プロトコルを使用するクラウド間であっても、ドライバと呼ばれるインターフェースによって、それらの相互接続を可能とするプロトコルフリーのインフラである。また、ディレクトリ機能によって、複数のアプリやＩｏＴデバイスを複雑に組み合わせて接続をすることも可能である。

また、本発明のＩｏＴ接続システム２０００において、第一のデバイス１４１０、第二のデバイス１５１０または第三のデバイス１６１０から取得される情報は、ＩｏＴハブ１２００では保存されないものとすることができる。

本発明のＩｏＴ接続システム２０００は、電気通信事業者により運営されることを想定している。電気通信事業者は、通信の秘密を遵守する義務が課せられるため、各種デバイスから取得される情報を、他の利活用を目的として保存することはしない。

これら情報は有益な情報であるため、各社のプライベートクラウドではかかる情報を独占的に取得すべく、ＩｏＴデバイスの囲い込みを行うのが通常である。

一方で、本発明のＩｏＴ接続システム２０００は、運営を電気通信事業者が行うことにより、各ＩｏＴデバイスおよびＩｏＴアプリを中立の立場で相互接続させ、ＩｏＴビジネスを促進させることができる。

また、ＩｏＴ相互接続サービスの継続性は利用する企業のＩｏＴサービスの継続性に影響するため、利用企業が共同で相互接続インフラを共有するのが好ましい。

また、本発明のＩｏＴ接続システム２０００において、ＩｏＴハブ１２００に接続できるのはＡＰＩキーと認証スキームにより許可されたデバイスやＩｏＴアプリのみとすることができる。すなわち、本発明のＩｏＴ接続システム２０００は、インターネット上にＩｏＴ通信専用の閉域網を構築することができる。また、通信経路も暗号化され、ＭＤＭ（Mobile Device Management）の手法を用いてＩｏＴルータも管理するため、新たな攻撃方法やＯＳやアプリの脆弱性対応も可能とする。

また、ＩｏＴ化されていないデバイスをＩｏＴハブ１２００に接続するには、ＢａａＳ（Backend as a service）やＳＤＫを活用することで、短期間での開発を行うことができる。

以上の構成によれば、上述した従来技術の問題の少なくとも一部を解決又は緩和する技術的な改善を提供することができる。また、以上の構成によれば、複数のデバイスの機能を組み合わせた新たなサービスの創造を効率的に行うことができるようになる。

サーバ装置３００は、図８に示すように、さらに、送信部３６０を有することができる。

送信部３６０は、第二の情報処理装置２００から受け付けた第一識別情報に対応する第一の情報処理装置１００に対してのみ、特定の電子錠を解除可能な解除キーに関する情報を送信する。

すなわち、自身のスマートフォンにアプリを入れている人だけ会議室への入出を許可するなどすることができる。

以上、上記の実施形態において、第二の情報処理装置２００が信号を受信する機能を有する装置であって会社内の会議室等に設置されるもので、第一の情報処理装置１００が信号を発信する機能を有するスマートフォン等の装置であってユーザが所持するものであることを想定して説明を行ったが、これらの発信受信機能は逆であってもよい。すなわち、第一の情報処理装置１００が信号を受信する機能を有し、第二の情報処理装置２００が信号を発信する機能を有するものであってもよい。

また、第一の情報処理装置１００および第二の情報処理装置２００のいずれもが発信機能および受信機能の両方の機能を有するものとしてもよい。この場合、どちらの装置がどちらの機能を実現するのかはサーバ装置３００からの指示に基づいて遠隔で自動的に切り替えられるものとすることができる。

また、発信機能を実現する装置（上記の実施形態では第一の情報処理装置１００）としては、上述したスマートフォン等の情報処理装置に限られず、タグ型の発信機（所謂「ビーコンタグ」）を用いることも可能である。

これによれば、スマートフォンを所持しない／することができない子供や高齢者、持ち歩けない医療・介護従事者の行動履歴を容易に確実に取得することができ、かつ、上記者と同じ場所にいた者を容易に確実に特定することができるようになる。

以下に、本開示における情報処理システム、情報処理方法およびコンピュータプログラムにより実現されるサービスの実施形態について説明する。

＜概要＞
本開示における情報処理システム、情報処理方法およびコンピュータプログラムにより実現されるサービスによれば、会議室等にＩｏＴセンサを設置し、当該会議室に一定時間入室した社員をその所有するスマートフォンにより特定することができる。

社員の中で新型コロナウイルス等の感染者が見つかった時に、その情報を利用して濃厚接触者または接触感染可能性者を特定できる。このことにより、ビル内に出入りした社員全員では無く、濃厚接触者または接触感染可能性者のみを自宅待機させたりするなどの感染拡大の防止手段が取りやすくなる。

合わせて、ＩｏＴセンサとして室内環境センサ等の様々なセンサを組み込むことにより、室内環境の継続的なモニターを行い、適切な換気等により室内での感染拡大をできるだけ防止するというような措置も採ることが可能となる。

＜提供方法＞
本サービスを提供するにあたり、ＩｏＴセンサとそのセンサがインターネットと通信するためのゲートウェイ（ＩｏＴルータ）を提供する。なお、ＩｏＴセンサの中でもＢＬＥビーコンをブロードキャストして入室する社員を特定するための機能はＩｏＴルータに内蔵される。

また、社員がＢＬＥビーコンを受けて入室したことを特定するためには、社有ないしは私用スマホに本開示におけるアプリケーションを事前にインストールして登録する必要がある。

この仕組みによって収集された入室情報および室内の環境情報は、以下に詳説する「ＩｏＴ Ｅｘｃｈａｎｇｅ」を通して「Ｃｏｒｏｎａ Ｔｒａｃｅｒ」サービス内に蓄積され、各企業の担当者が自由に引き出すことができる。

なお、情報の取り出しとその情報に基づいたアクションについては、ＲＰＡ（ロボティック・プロセス・オートメーション）などの自動化ツールを使っても良い。

＜サービスの構成要素とその機能＞
「ＩｏＴ Ｅｘｃｈａｎｇｅ」は、センサ等を制御するための命令やセンサから上がってくる情報を送受信する。

「ＩｏＴルータ」は、環境センサとの接続を担って、環境データを「ＩｏＴ Ｅｘｃｈａｎｇｅ」に送信するだけで無く、内蔵するＢＬＥチップがＢＬＥ送受信機としての役割を果たし、スマートフォンから送出されるＢＬＥビーコンを受信したり、自らＢＬＥビーコンを送出したりすることができる。

「環境センサ」は、会議室等の環境データ（室温、湿度、騒音、ＣＯ_２量、揮発性有機溶媒量等）を測定して、ＩｏＴルータ経由で「Ｃｏｒｏｎａ Ｔｒａｃｅｒ」サービスに送付する。

「Ｃｏｒｏｎａ Ｔｒａｃｅｒ Ａｐｐ」は、ｉＯＳおよびＡｎｄｒｏｉｄに対応し、社員の持つスマートフォン（社給ないしは個人所有）にインストールされ、ＢＬＥビーコンを送信する。また、ＢＬＥビーコンが常に送信されているかの確認情報を「Ｃｏｒｏｎａ Ｔｒａｃｅｒ」サービスに対して送出する。また、ＢＬＥビーコンを受信してその情報（タイムスタンプ、会社ＩＤ、社員ＩＤ、ビーコンＩＤ、ビーコン強度）を「Ｃｏｒｏｎａ Ｔｒａｃｅｒ」サービスに送付するものであってもよい。

「Ｃｏｒｏｎａ Ｔｒａｃｅｒ」サービスは、環境センサ、ＩｏＴルータおよび「Ｃｏｒｏｎａ Ｔｒａｃｅｒ Ａｐｐ」からの情報を収集して保存する。また、本サービスはＩｏＴルータの設定を遠隔で行うことができる。また、ＩｏＴルータをＢＬＥ発信機として利用する場合には、ＢＬＥの早出間隔や送信強度を変更することができる。本サービスは更に、社員の会議室への入退出情報についてレポートを生成してｃｓｖファイルに保存することができる。

「ＲＰＡ」または、連携を希望する他システムは、「Ｃｏｒｏｎａ Ｔｒａｃｅｒ」サービスにアクセスし、社員の会議室入退出情報を取得し、その情報に基づいてレポートを生成したり、アラートを送出したりする。

＜サービス提供の準備＞
本サービスの提供にあたっては、会議室へのデバイスの設置と社員によるアプリのインストールおよびＲＰＡまたは、連携を希望する他システムへの種々の登録が必要である。会議室に設置されるデバイスは、ＩｏＴルータ、環境センサ及びＡＣアダプタである。電源が室内に無い場合には、モバイルバッテリーも必要である。ＩｏＴルータはＡｎｄｒｏｉｄスマホであるが、アクティベーション、アプリのインストレーション等のキッティングは本サービス提供者にて行う。よって、設置業者は本デバイス一式を会議室に置いていくだけで良い。

社員のスマホにインストールされるアプリは、Ｇｏｏｇｌｅ Ｐｌａｙ ＳｔｏｒｅないしはＡｐｐｌｅ Ａｐｐ Ｓｔｏｒｅからそれぞれの社員がダウンロードし、インストールすることとする。また、インストール後は、会社ＩＤと社員ＩＤを登録する必要がある。

先行技術文献として挙げたアプリケーションは、双方がスマホにアプリを入れていることが前提であるが、本開示における発明によれば、片方はタグなどでも動作可能である。これにより、スマートフォンを持っていない子供や高齢者、持ち歩けない医療・介護従事者にも対応可能である。

また、先行技術文献として挙げたアプリケーションは、スマートフォンに保存する方式のみであるが、本開示における発明によれば、スマートフォンおよびクラウドの双方に保存する方法を選択可能である。また、双方の相対距離情報と本人を特定できる情報を全く別システムとして分離し、連携システム経由でのアクセスしかできないよう制限されている。これにより、端末側の情報、クラウド側の情報にアクセスできたとしても情報の入手は不可能である。

また、先行技術文献として挙げたアプリケーションは、スマートフォン用アプリケーションであって親機・子機の概念がなくいずれの端末も対等であり位置情報を取得しないことが前提であるが、本開示における発明によれば、受信側を特定の場所に設置することができるため、集団感染場所の特定を容易に行うことができる。これにより、集団感染が発生した場所と日時を容易に特定できる。具体的には、会議室、トイレ、店舗、クラブ、教室、カラオケルームなどである。場所や日時が特定できれば、その場所にいた人間がスマートフォンやアプリ、タグ等を持たない人がいた場合でも、感染リスクを知らせることができる場合がある。また、本開示における発明によれば、子機が何台あっても、親機が受信する方式なので、データ蓄積・収集先を限定・一元化することができる。親機は、会社が会議室等に導入・設置して管理することで、親機の場所（位置情報を含む）を特定することができる、なお、親機は会社が遠隔から運用保守可能とするのが好ましい。

また、先行技術文献として挙げたアプリケーションは、このアプリケーションが必ず必要で、これ以外の同様のアプリケーションやサービスと連携することが難しいが、本開示における発明によれば、特定の企業、団体、自治体等が個別に入れたシステムを簡単に相互接続することができ、契約が成立した相手と契約に基づいた情報だけを共有することができる。これにより、個人の同意や契約に基づかない情報の共有は行われないことが保証できる。

また、先行技術文献として挙げたアプリケーションは、基本的に個人情報を極力特定しない方式の一般的な感染情報共有システムであるが、本開示における発明は、事業者の設置した場所の情報を追加できるので、どの場所が感染場所になったかを特定することができる。その結果、事業者が事業停止リスクを減少させ、かつ従業員の安全を確保することが可能になる。ここでいう事業者とは、会社（会議室、トイレ）、学校（教室、トイレ）、店舗（飲食、カラオケ、クラブ等）など、これまで個別に対策を取れなかった事業者全てである。

また、本開示における発明は、第一の情報処理装置が備えるＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）機能と連動させて、帰国後自宅待機を命じられた人の周辺で感染者が発生した場合に、自分は自宅にずっと待機していたことを証明するために自分の位置情報を提出できるような仕組みを構築してもよい。

最後に、本開示における情報処理方法およびコンピュータプログラムの実施形態について説明する。

本開示における情報処理方法は、図１に示したように、第一の情報処理装置１００から発信された信号を受信する機能を有する第二の情報処理装置２００と、少なくとも第二の情報処理装置２００とインターネットを介して接続可能なサーバ装置３００とを備える情報処理システム１０００において実行される情報処理方法である。

本開示における情報処理方法は、図２１に示されるように、サーバ装置３００に、記憶ステップＳ１０と、抽出ステップＳ２０と、推定ステップＳ３０と、特定ステップＳ４０とを実行させる。

記憶ステップＳ１０では、第二の情報処理装置の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置が受信した信号を発信する一以上の第一の情報処理装置の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する。かかる記憶ステップＳ１０は、上述した記憶部３１０により実行されることができる。記憶部３１０の詳細については上述したとおりである。

抽出ステップＳ２０では、サーバ装置が、一以上の第一の情報処理装置の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、特定の第一の識別情報が含まれるセットの中から、特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する。かかる抽出ステップＳ２０は、上述した抽出部３２０により実行されることができる。抽出部３２０の詳細については上述したとおりである。

推定ステップＳ３０では、抽出ステップにおいて抽出されたセットに含まれる強度情報に基づいて、特定の第一の情報処理装置が存在した位置を推定する。かかる推定ステップＳ３０は、上述した推定部３３０により実行されることができる。推定部３３０の詳細については上述したとおりである。

特定ステップＳ４０では、推定ステップにおいて推定された位置と略同一の位置に、特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する。かかる特定ステップＳ４０は、上述した特定部３４０により実行されることができる。特定部３４０の詳細については上述したとおりである。

以上の構成によれば、上述した従来技術の問題の少なくとも一部を解決又は緩和する技術的な改善を提供することができる。

本開示におけるコンピュータプログラムは、第一の情報処理装置から発信された信号を受信する機能を有する第二の情報処理装置と、少なくとも第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムにおいて実行されるコンピュータプログラムである。

本開示におけるコンピュータプログラムは、サーバ装置に、サーバ装置３００に、記憶機能、抽出機能、推定機能および特定機能を実現させる。

記憶機能は、第二の情報処理装置の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置が受信した信号を発信する一以上の第一の情報処理装置の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する。

抽出機能は、サーバ装置が、一以上の第一の情報処理装置の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、特定の第一の識別情報が含まれるセットの中から、特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する。

推定機能は、抽出機能において抽出されたセットに含まれる強度情報に基づいて、特定の第一の情報処理装置が存在した位置を推定する。

特定機能は、推定機能により推定された位置と略同一の位置に、特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する。

上記記憶機能、抽出機能、推定機能および特定機能は、それぞれ記憶回路、抽出回路、推定回路および特定回路により実行されることができる。これら回路は上述した記憶部３１０、抽出部３２０、推定部３３０および特定部３４０が備えるものとすることができる。これらの詳細は上述したとおりである。

以上の構成によれば、上述した従来技術の問題の少なくとも一部を解決又は緩和する技術的な改善を提供することができる。

最後に、本開示における情報処理システムの他の適用例について説明する。
新型コロナウイルスは、主に感染者との飛沫接触等により伝染する事が報告されており、公衆衛生機関は、感染拡大を抑えるためには感染経路を断つこと、やむを得ず接触し感染した場合には速やかに濃厚接触者を特定するように求めている。

そのため、政府や感染症研究機関は、感染者の利用等があった場所（店舗、事業所、等の施設）を公開し、ＧＰＳ等の位置情報を使って地図上で確認できるサービスを提供する会社や、非特許文献１のように、感染経路を追跡し、濃厚接触者に通知できるサービスも現れている。

非特許文献１に記載されたサービスでは、該当のアプリをインストールしているスマートフォン同士が近づくと、端末ごとに割り振られたＩＤを近距離無線通信の「ブルートゥース」を使って交換し、記録する。感染した人がアプリ利用者の時は、保健省の職員が本人の同意を得た上でアプリ上の記録を手掛かりに感染者の近くに一定時間以上いたスマートフォン利用者を特定・連絡し、必要な措置を講ずる。

このようなアプリの活用により、本人が気付かない濃厚接触者を追跡することができ、クラスター（感染者集団）の早期発見や感染の恐れがある人の早期隔離に効果がある。しかし、このアプリはスマートフォンの利用が前提であり、しかも大勢の人が利用しないと効果が高まらない。

現在、新型コロナウイルスの感染拡大対策として緊急事態宣言が発令され、多くの企業が外出自粛の要請をされている。しかし、在宅では対応できない業務や、社会機能を維持するために必要な業種もあり、そうした業務に従事する人々は、引き続き出勤を継続せざるを得ない状況を強いられている。

ところが、現在では国民生活・国民経済の安定確保に不可欠な業務を行う企業、店舗、病院等でも感染者が発見され、特定の業務だけでなく事業そのものを一時的に停止しなければならない事態が発生している。

既に、すべての事業者にとって、濃厚接触者を速やかに特定し、仕分けを行うことが、事業継続性（ＢＣＰ）対策として必須になっている。

そこで、本発明者は、企業のＢＣＰ対策を目的として、第二の情報処理装置２００として会議室等に設置した本開示におけるＩｏＴルータ１３００を活用して「濃厚接触者特定サービス」を開発した。

まず、企業の会議室など「三密」になりやすい場所に、本開示におけるＩｏＴルータ（親機：第二の情報処理装置２００）を設置する。そこに、Ｂｅａｃｏｎアプリをインストールしたスマートフォン（子機：第一の情報処理装置１００）を持った社員が近づくと、社員の子機ＵＵＩＤと距離を検知し、時刻と共に記録する。

そのため、総務部門等の管理者は、感染した社員名を指定するだけで、濃厚接触の可能性のある社員名を簡単に特定することができる。

この「濃厚接触者特定サービス」は、「Ｂｅａｃｏｎデータ収集システム」と「濃厚接触者特定システム」という別々のシステムを、「ＩｏＴハブ」と「ＩｏＴルータ」を経由し、必要なデータを必要な時に必要な分だけ取得する仕組みになっており、管理者が誰かの行動を監視し続けることはできない仕組みになっている。

すなわち、本開示における第一の情報処理装置１００および第二の情報処理装置２００を含むシステムが「Ｂｅａｃｏｎデータ収集システム」であり、サーバ装置３００を含むシステムが「濃厚接触者特定システム」であり、上述したＩｏＴハブ１２００がこれらを繋ぐハブとして機能する。

そのため、高いプライバシー保護とセキュリティ確保を両立することが可能である。すなわち、収集するデータを個人情報に当たらないものだけに限定した「Ｂｅａｃｏｎデータ収集システム」と社員の氏名と連絡先といった個人情報を扱う「濃厚接触者特定システム」という二つのシステムを作り、これら二つのシステムを分けることによって、情報を遮断する。

そして、これらのシステムを必要な時に限りＩｏＴハブを使って疎結合することで、社員の行動の常時監視を防止しつつ、濃厚接触者を特定できるようにする。

かかるシステム構成は、ＩｏＴハブ１２００に様々な機能のシステムを接続することにより機能を拡張していくことが可能である。

続いて、図２２を用いて感染者発生から濃厚接触者を特定するフローを説明する。

具体的には、予め、図２２に示すＢｅａｃｏｎデータ収集システム３１００において、会議室に設置したＢｅａｃｏｎやスマートフォンアプリを利用して、会議室にいた人のデータ（ＵＵＩＤ、時刻、親機であるＩｏＴルータと子機であるスマートフォンの距離）を自動収集する。このＢｅａｃｏｎデータ収集システム３１００には、個人情報は一切含まれない。

そして、管理者が感染者となった従業員から感染の報告を受けた際には、管理者は、管理画面から従業員の名前を入力する。そうすると、濃厚接触者特定システム３２００は感染者のＵＵＩＤをＢｅａｃｏｎデータ収集システム３１００に送付する。このＵＵＩＤを基にＢｅａｃｏｎデータ収集システム３１００は、濃厚接触の恐れがあるＵＵＩＤを特定し濃厚接触者特定システム３２００に送付する。そして、このシステム３２００はＵＵＩＤと氏名を紐づけ、濃厚接触候補者リストとして出力する。管理者である総務の担当者は、そのリストの情報から優先順位を付けて濃厚接触者候補に連絡し、自宅待機や検査の指示、継続的な報告などの指示を行う。

なお、「Ｃｏｒｏｎａ Ｔｒａｃｅｒ」では、ＢＬＥをＢｅａｃｏｎとして活用している。スマートフォン同士でＢｅａｃｏｎを活用し、濃厚接触を検知することも可能であるが、スマートフォンを持たない社員がいること、一部のスマートフォンはＢＬＥの双方向通信が可能でないことを考慮し、ＩｏＴルータを親機として活用し、ＢＬＥ双方向通信ができない社員にはＢｅａｃｏｎタグを持たせることで全ての社員がシステムを使うことができるようにしている。スマートフォン間のＢＬＥ活用で収集したデータは、距離精度の向上など補助的な用途に活用されている。

なお、本システムの管理者はＩＤとパスワードをメールで社員に通知する。通知を受けた社員がアプリをインストールする際に送付されたＩＤとパスワードを入力するとスマートフォンの中で自動的にＵＵＩＤが生成され、氏名とともに濃厚接触者特定システムに登録される。Ｂｅａｃｏｎデータ収集システムには、このＵＵＩＤのみが送付され記録に使用されるので、ＵＵＩＤから個人の特定はできない。

また、ＩｏＴハブを利用することにより、異なる会社のデータを契約に基づき限定的に情報共有することができる。この機能を活用すれば、同席した別の会社の社員にも感染リスクがあることを教えることが可能になる。

また、導入企業が同意すれば、個人情報を伏せて、政府や自治体、または保険機関に情報を一括して提供することも可能である。これにより、感染者集団（クラスター）情報をいち早く提供することが可能になる。

最後に、第一の情報処理装置１００に代えて、または、加えて、二次元コードを印刷した媒体を用いた例について付記する。

上述した実施例では、第一の情報処理装置１００に専用のアプリケーションがインストールされた者を対象者であると想定して説明を行ったが、他の情報処理装置（専用のアプリケーションがインストールされていない情報処理端末）を有する者や、情報処理端末を有しない者などが会社に来訪する場合も多い。

例えば、工事などを行う作業員や、会議などのために一時的に来訪する者などの来訪者などは、上述した専用のアプリケーションをインストールしたスマートフォンやビーコンタグを用いて管理するよりも、入館証にＱＲコード（登録商標）などの二次元コードを印刷し、この二次元コードに含まれる情報を管理する方が容易である。

このＱＲコードには、来訪者の氏名および連絡先（メールアドレスおよび／または電話番号等）の情報を記録する。これらの情報は、来訪時に来訪者が所定の入力端末を介して入力するものであってもよいし、来訪者または迎え入れる側の者が事前に登録しておくものであってもよい。

そして、来訪者は会議室に入室した際に、会議室に設置された親機である第二の情報処理装置２００に、自身の入館証に印刷された二次元コードを読み取らせる。これにより、来訪者の情報、および、読み取った時間等の情報はサーバ装置３００に記録される。

なお、二次元コードを読み取るのは親機に限られず、子機である第一の情報処理装置１００が読み取り、親機に送信する形式としてもよい。

そして、上述した実施形態と組み合わせ、来訪者に対して連絡する必要がある場合には、連絡先として記録されたメールアドレスや電話番号に対してＥメールまたはＳＭＳ（ショートメッセージサービス）を送信することにより行われるのが好ましい。

さらに、上記二次元コードは、オンライン名刺として活用することも可能である。すなわち、実際の紙媒体を交換する従来の名刺交換に代えて、名刺の内容を二次元コードに記録してスマートフォン等の画面に表示することで、接触を避けて遠隔からでも名刺交換を行うことが可能になる。

また、会議において参加者に共有される画面上にオンライン名刺を表示することで、参加者と一斉に名刺交換を行うことも可能である。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

また、実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラムとして、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウェア手段（実行プログラムのみならずテーブルやデータ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウェア手段を構築し、このソフトウェア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。記憶部は、例えば主記憶装置、補助記憶装置、又はキャッシュメモリとして機能してもよい。

１０００ 情報処理システム
１００ 第一の情報処理装置
１１０ 発信部
２００ 第二の情報処理装置
２１０ 受信部
２２０ 送信部
２３０ 取得部
２４０ 環境情報送信部
３００ サーバ装置
３１０ 記憶部
３２０ 抽出部
３３０ 推定部
３４０ 特定部
３５０ 通知部
３６０ 送信部

Claims (11)

1. 第一の情報処理装置から発信された信号を受信する機能を有する第二の情報処理装置と、
   少なくとも前記第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムであって、
   前記サーバ装置は、
   前記第二の情報処理装置の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置が受信した信号を発信する一以上の第一の情報処理装置の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する記憶部と、
   前記サーバ装置が、前記一以上の第一の情報処理装置の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、前記特定の第一の識別情報が含まれるセットの中から、前記特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する抽出部と、
   前記抽出部により抽出されたセットに含まれる強度情報に基づいて、前記特定の第一の情報処理装置が存在した位置を推定する推定部と、
   前記推定部により推定された位置と略同一の位置に、前記特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する特定部と
   を備える情報処理システム。
2. 前記特定部は、前記推定部により推定された位置と略同一の位置に、前記第一の情報処理装置が存在した日時よりも後で、かつ、所定の終了日時より前の間に存在したと推定される、他の第一の情報処理装置を特定し、
   前記サーバ装置は、
   前記所定の終了日時を、第三の情報処理端末から受信した第三識別情報および当該第三識別情報の受信時刻に基づいて設定することを特徴とする請求項１に記載の情報処理システム。
3. 前記特定部は、前記推定部により推定された位置から所定範囲内に、前記特定の第一の情報処理装置が存在した日時に存在したと推定される、他の第一の情報処理装置を有する他のユーザを濃厚接触者として特定することを特徴とする請求項１または２に記載の情報処理システム。
4. 前記サーバ装置は、さらに、
   前記特定部により特定された他の第一識別情報を有する他の第一の情報処理装置を有するユーザに対して、特定の情報を通知する通知部を有し、
   前記通知部は、前記特定部により特定された他の第一識別情報のうち、接触感染の防止対策を行ったことを示す拒否情報が関連付けられていない他の第一識別情報を有する他の第一の情報処理装置を有するユーザに対して、特定の情報を通知することを特徴とする請求項１、２または３に記載の情報処理システム。
5. 前記第三の情報処理端末は、所定の領域毎に設置された媒体に表示された二次元バーコードを読み取ることにより前記第三識別情報を前記サーバ装置に送信することを特徴とする請求項２に記載の情報処理システム。
6. 前記特定の日時情報は、前記特定の日時よりも第一の期間だけ前の日時を含むことを特徴とする請求項１から５のいずれか一項に記載の情報処理システム。
7. 前記特定の日時は、前記特定の第一の情報処理装置を利用する特定のユーザが所定の感染症であると診断された日時であり、
   前記第一の期間は、前記感染症の潜伏期間であることを特徴とする請求項６に記載の情報処理システム。
8. 前記特定の日時情報は、前記特定の日時よりも第二の期間だけ後の日時を含むことを特徴とする請求項１に記載の情報処理システム。
9. 前記第二の情報処理装置は、所定の領域に複数設置され、
   前記推定部は、前記複数の第二の情報処理装置から抽出されたセットに含まれる強度情報に基づいて、前記特定の第一の情報処理装置が存在した位置を推定することを特徴とする請求項１から８のいずれか一項に記載の情報処理システム。
10. 第一の情報処理装置から発信された信号を受信する機能を有する第二の情報処理装置と、
    少なくとも前記第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムにおいて実行される情報処理方法であって、
    前記サーバ装置に、
    前記第二の情報処理装置の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置が受信した信号を発信する一以上の第一の情報処理装置の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する記憶ステップと、
    前記サーバ装置が、前記一以上の第一の情報処理装置の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、前記特定の第一の識別情報が含まれるセットの中から、前記特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する抽出ステップと、
    前記抽出ステップにおいて抽出されたセットに含まれる強度情報に基づいて、前記特定の第一の情報処理装置が存在した位置を推定する推定ステップと、
    前記推定ステップにおいて推定された位置と略同一の位置に、前記特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する特定ステップと
    を実行させる情報処理方法。
11. 第一の情報処理装置から発信された信号を受信する機能を有する第二の情報処理装置と、
    少なくとも前記第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムにおいて実行されるコンピュータプログラムであって、
    前記サーバ装置に、
    前記第二の情報処理装置の第二識別情報に関連付けて、少なくとも当該第二の情報処理装置が受信した信号を発信する一以上の第一の情報処理装置の第一識別情報と、当該信号を受信した時刻情報と、当該信号の強度情報とのセットを記憶する記憶機能と、
    前記サーバ装置が、前記一以上の第一の情報処理装置の中の特定の第一の情報処理装置の特定の第一識別情報および特定の日時の指定を受け付けた場合に、前記特定の第一の識別情報が含まれるセットの中から、前記特定の日時に関連する特定の日時情報に含まれる時刻情報を含むセットを抽出する抽出機能と、
    前記抽出機能において抽出されたセットに含まれる強度情報に基づいて、前記特定の第一の情報処理装置が存在した位置を推定する推定機能と、
    前記推定機能により推定された位置と略同一の位置に、前記特定の第一の情報処理装置が存在した日時よりも後に存在したと推定される、他の第一の情報処理装置を有する他のユーザを接触感染可能性者として特定する特定機能と
    を実現させるコンピュータプログラム。

Images