【新規性喪失の例外の表示】特許法第30条第2項適用 ・令和2年4月20日 https://www.iot−ex.co.jp/news/news_200420.html ・令和2年4月28日 https://www.iot−ex.co.jp/news/news_200428.html ・令和2年4月28日 https://smartiot−forum.jp/iot−val−team/iot−case/case−iot−ex ・令和2年5月15日 https://smartiot−forum.jp/iot−val−team/iot−case/mailmagazine/mailmaga−039−20200514?mailmaga=
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0021】
本開示の情報処理システムの実施形態について、図面を参照しながら説明する。
【0022】
図1に一例として示されるように、本開示の情報処理システム1000は、第一の情報処理装置100と、第二の情報処理装置200と、サーバ装置300とを備えるものである。
【0023】
第一の情報処理装置100は、信号を発信する機能を有する装置である。
【0024】
信号を発する機能とは、例えば、Bluetooth(登録商標) Low Energy(BLE)やWi−Fi等の無線技術を使い、当該信号を受信可能な装置に対して情報を発信することができる機能である。
【0025】
第一の情報処理装置100は、上記信号を発する機能を有する装置であれば特に限定されないが、一例としてスマートフォンやタブレット等の情報処理装置とすることができる。
【0026】
そして、上記信号を発する機能は、専用のアプリケーションをインストールすることにより第一の情報処理装置100により実現されることができる。
【0027】
第二の情報処理装置200は、上記信号を受信する機能を有する装置である。
【0028】
第二の情報処理装置200は、上記信号を受信する機能を有する装置であれば特に限定されないが、一例としてスマートフォンやタブレット等の情報処理装置とすることができる。また、第二の情報処理装置200として後述するIoTルータを用いてもよい。
【0029】
そして、上記信号を受信する機能は、専用のアプリケーションをインストールすることにより第二の情報処理装置200により実現されることができる。
【0030】
サーバ装置300は、第二の情報処理装置200とインターネットを介して接続可能な装置である。
【0031】
ここで、
図2を用いて、第一の情報処理装置100のハードウェア構成について説明する。第一の情報処理装置100は、プロセッサ101と、メモリ102と、ストレージ103と、入出力インターフェース(入出力I/F)104と、通信インターフェース(通信I/F)105とを含むことができる。各構成要素は、バスBを介して相互に接続される。
【0032】
第一の情報処理装置100は、プロセッサ101と、メモリ102と、ストレージ103と、入出力I/F104と、通信I/F105との協働により、本実施形態に記載される機能、方法を実現することができる。
【0033】
プロセッサ101は、ストレージ103に記憶されるプログラムに含まれるコード又は命令によって実現する機能、及び/又は、方法を実行する。プロセッサ201は、例えば、中央処理装置(CPU)、MPU(Micro Processing Unit)、GPU(Graphics Processing Unit)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(Application-Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)等を含み、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、1又は複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSI等と呼称されることもある。
【0034】
メモリ102は、ストレージ103からロードしたプログラムを一時的に記憶し、プロセッサ101に対して作業領域を提供する。メモリ102には、プロセッサ101がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ102は、例えば、RAM(Random Access Memory)、ROM(Read Only Memory)等を含む。
【0035】
ストレージ103は、プログラムを記憶する。ストレージ103は、例えば、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリ等を含む。
【0036】
通信I/F105は、ネットワークアダプタ等のハードウェアや通信用ソフトウェア、及びこれらの組み合わせとして実装され、ネットワークを介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F105は、ネットワークを介して、他の情報処理装置との通信を実行する。通信I/F105は、各種データをプロセッサ101からの指示に従って、他の情報処理装置に送信する。また、通信I/F105は、他の情報処理装置から送信された各種データを受信し、プロセッサ101に伝達する。
【0037】
入出力I/F104は、第一の情報処理装置100に対する各種操作を入力する入力装置、及び、第一の情報処理装置100で処理された処理結果を出力する出力装置を含む。入出力I/F104は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。
【0038】
入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報をプロセッサ101に伝達できる全ての種類の装置のいずれか、又は、その組み合わせにより実現される。入力装置は、例えば、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(画像を介した操作入力)、マイク(音声による操作入力)を含む。
【0039】
出力装置は、プロセッサ101で処理された処理結果を出力する。出力装置は、例えば、タッチパネル、スピーカ等を含む。
【0040】
上記第二の情報処理装置200およびサーバ装置300についても、上記第一の情報処理装置100と同様のハードウェア構成とすることができる。
【0041】
そして、本開示における第一の情報処理装置100は、
図3に示されるように、発信部110を有する。
【0042】
発信部110は、第一の情報処理装置100の第一識別情報を含む信号を発信するものである。
【0043】
第一識別情報は、第一の情報処理装置100を特定可能な識別情報であれば特に限定されるものではない。第一識別情報の例として、UDID(Unique Device IDentifier)やUUID(Universally Unique IDentifier)等を用いることができるが、プライバシー・セキュリティー上の観点からUUIDを第一識別情報とするのが好ましい。
【0044】
第二の情報処理装置200は、
図4に示されるように、受信部210と、送信部220とを有する。
【0045】
受信部210は、第一の情報処理装置100から発信された信号を受信するものである。
【0046】
送信部220は、時刻情報、強度情報および第一識別情報を、第二の情報処理装置200の第二識別情報とともにサーバ装置300に送信するものである。
【0047】
時刻情報は、上記信号を受信した時刻に関する情報である。かかる時刻情報は日付および時刻を含み、時刻は時分秒を含むものとすることができる。
【0048】
強度情報は、信号の受信強度に基づく情報である。かかる受信強度に関する情報は受信した電波の強度を示す電波強度に加え、基準強度を含むことができる。そして、これらから第一の情報処理装置100と第二の情報処理装置200との推定距離を算出しておくことも可能であり、この推定距離を受信強度に基づく情報としてもよい。かかる推定距離の算出については、第二の情報処理装置200で行うものとしてもよいし、サーバ装置300で行うものとしてもよい。
【0049】
第二識別情報は、第二の情報処理装置200を特定可能な識別情報であれば特に限定されるものではない。第二識別情報の例として、第一識別情報と同様に、UDID(Unique Device IDentifier)やUUID(Universally Unique IDentifier)等を用いることができるが、プライバシー・セキュリティー上の観点からUUIDを第二識別情報とするのが好ましい。このUUIDは、上述した専用のアプリケーションにより発行される数値であって、個人情報を含まないものとすることができる。
【0050】
そして、サーバ装置300は、
図5に示されるように、記憶部310と、受付部320と、抽出部330とを有する。
【0051】
記憶部310は、第二の情報処理装置200から受信した時刻情報、強度情報、第一識別情報および第二識別情報を互いに関連付けて記憶するものである。
【0052】
図6は、記憶部310が記憶されるデータテーブルの一例を示したものである。
図6に示されるように、第二の情報処理装置200が、受信した信号を発信した第一の情報処理装置100とその受信時刻、電波強度とともに記憶される。
【0053】
なお、
図6では時刻情報が各第一識別情報に1つのみ示しているが、信号を最初に受信した時刻から受信しなくなった時刻まで所定の間隔で記憶されることができる。
【0054】
受付部320は、特定の第一の情報処理装置100の特定の第一識別情報の指定を受け付けるものである。
【0055】
上記指定は、本開示における情報処理システムを利用するユーザにより所定の情報処理端末を介して行われるものとする。
【0056】
そして、特定の第一の情報処理装置100は、感染者の所有するスマートフォン等の携帯端末とすることができる。
【0057】
この場合、上記指定を行うユーザの例としては、感染者の行動履歴を追跡する者、例えば、保健所の担当者や医療従事者などであるが、これらの者に限定されるものではない。
【0058】
例えば、感染者自身が、第一の情報処理装置100から感染症に感染した旨の情報をサーバ装置300に送信し、自分の特定の第一の情報処理装置100Aの特定の第一識別情報を指定することもできる。
【0059】
抽出部330は、受付部320が特定の第一の情報処理装置100の特定の第一識別情報の指定を受け付けた場合に、特定の第一識別情報に関連付けて記憶された特定の第二識別情報に基づいて、当該特定の第二識別情報に関連付けて記憶された1以上の他の第一識別情報を抽出することを特徴とする。
【0060】
特定の第一の情報処理装置100Aの特定の第一識別情報が
図6における「100002」であった場合に抽出される他の第一識別情報のイメージを示した例を
図7に示す。
【0061】
なお、抽出部330は、時刻情報および/または強度情報に基づくフィルタ条件に基づいて、他の第二識別情報を抽出してもよい。詳細については後述する。
【0062】
以上のように、本開示における情報処理システムによれば、特定の第一の情報処理装置を有する者が、いつ何処にいたかという行動履歴を容易に確実に取得することができ、かつ、上記者と同じ場所にいた者を容易に確実に特定することができるようになる。すなわち、本開示における情報処理システムは、感染者のトレーサビリティを可能にする。
【0063】
例えば、会社内の部屋に第二の情報処理装置200を設置しておけば、感染者が生じた場合に、感染者がどの部屋にどのくらいの時間滞在したか、濃厚接触者は誰かなどの情報を迅速に抽出することができる。
【0064】
濃厚接触者を迅速に特定することで、会社内に出入りした者全員ではなく、濃厚接触者のみを自宅待機させるなどの効果的な対応を迅速にとることができる。その結果、事務所の全閉鎖といった事態を避けることができ、BCP(事業継続性)対策にもなる。
【0065】
抽出部330は、特定の第一識別情報の指定を受け付けた場合に、特定の第一識別情報に関連付けて記憶された特定の第二識別情報および当該特定の第一識別情報を含む信号を受信した特定の時刻に関する特定時刻情報に基づいて、当該特定時刻情報に関連付けて記憶された1以上の他の第一識別情報を抽出することができる。
【0066】
すなわち、抽出部330は、時刻情報に基づくフィルタ条件に基づいて、他の第二識別情報を抽出することができる。
【0067】
特定の時刻に関する特定時刻情報は、一例として、特定の第一の情報処理装置が信号を最初に受信した時刻から受信しなくなった時刻まで所定の間隔で記憶される時刻のすべてとすることができる。
【0068】
あるいは、特定の時刻に関する特定時刻情報は、他の例として、特定の第一の情報処理装置が信号を最初に受信した時刻、および、当該最初に受信した時刻から受信しなくなった時刻までの時間に基づいて算出される滞在時間を含むことができる。
【0069】
そして、特定時刻情報に関連する時刻情報とは、上記特定時刻情報に基づいて設定された、感染者と濃厚接触の可能性が高い時刻とすることができる。
【0070】
具体的には、感染者と同じ場所・時間にいた者に加えて、感染者と同じ場所に、感染者がいなくなった後、予め設定された所定の時間が経過するまでの間にいた者も濃厚接触者として抽出することができる。
【0071】
さらに、抽出部330は、強度情報に基づくフィルタ条件に基づいて、他の第二識別情報を抽出してもよい。
【0072】
すなわち、感染者が第二の情報処理装置200が設置されたある部屋にいると推定される場合に、強度情報に基づいて当該部屋の外にいると推定される者については、濃厚接触者として抽出しなくともよい。
【0073】
サーバ装置300は、
図8に示すように、さらに、通知部340を有することができる。
【0074】
通知部340は、特定の第一識別情報の指定を受け付けた場合に抽出された1以上の第一識別情報を有する第一の情報処理装置100に対して、特定の情報を通知する。
【0075】
特定の情報とは、一例として、第二の情報処理装置200の近くにいたことを知らせる内容の情報とすることができる。かかる情報には、さらに、感染症に対応が可能な近くの施設の情報、相談窓口の電話番号などの情報を含めてもよい。
【0076】
通知は、プッシュ通知の技術を利用して強制的に行うのが好ましい。
【0077】
第二の情報処理装置200は、
図9に示されるように、取得部230と、環境情報送信部240とをさらに有することができる。
【0078】
取得部230は、設置場所の環境情報を所定のセンサから取得する。
【0079】
所定のセンサは設置場所の環境情報を測定可能な物であれば特に限定されるものではないが、一例として、室温センサ、湿度センサ、照度センサ、気圧センサ、騒音センサ、各種ガス濃度センサ、不快指数センサ、熱中症警戒度センサの少なくとも一つとすることができる。
【0080】
ガスセンサが測定可能なガスの例としてはCO
2、揮発性有機溶媒量線などとすることができる。
【0081】
環境情報送信部240は、当該環境情報を受信した時刻に関する時刻情報を、環境情報とともにサーバ装置300に送信する。
【0082】
そして、サーバ装置300の記憶部310は、第二の情報処理装置200から受信した環境情報および時刻情報を、第二識別情報に関連付けて記憶することができる。
【0083】
そして、サーバ装置300の抽出部330は、第二の情報処理装置200から受信した環境情報が特定の条件を満たす場合に、第二識別情報に関連付けて記憶された1以上の第一識別情報を抽出してもよい。
【0084】
特定の条件とは、いわゆる三密(密閉・密集・密接)の条件を満たす条件とすることができる。具体的な数値については予め適切に設定されることができる。
【0085】
また、
上述した通知部340は、特定の条件を満たす場合に抽出された1以上の第一識別情報を有する第一の情報処理装置100の少なくとも一つに対して、注意情報を通知することができる。
【0086】
すなわち、部屋が三密の条件を満たしてしまっている場合に、会議の開催者などに対して換気などを促す等の注意情報を通知することができる。
【0087】
あるいは、環境情報が特定の条件を満たす場合に、室内のIoTデバイス(エアコン、空気清浄機、加湿器等)を自動制御することにより三密を解消させるようにしてもよい。IoTデバイスの自動制御については、後述するように第二の情報処理装置200がIoTルータである場合に適用することができる。
【0088】
そして、本開示における第二の情報処理装置200は、IoTルータとすることができる。
【0089】
IoTルータは、
図10に示されるように、クラウド上で実現されるIoTハブ1200、および、ローカルにありIoTハブ1200と接続されるIoTルータ1300を備えるIoT接続システム2000におけるIoTルータ1300である。
【0090】
ここで、本開示の実施形態におけるIoT接続システム2000の実施形態について、図面を参照しながら説明する。
【0091】
図10に示すように、本開示の実施形態におけるIoT接続システム2000は、IoTハブ1200およびIoTルータ1300を備えるものとする。
【0092】
IoTハブ1200は、クラウド上で実現されるものとする。具体的には、IoTハブ1200は、クラウド内でホストされているマネージドサービスであり、IoTアプリケーション(以下「IoTアプリ」という。)とIoTデバイスとの間の双方向通信に対する中継器として機能する。
【0093】
IoTルータ1300は、ローカルにあり、IoTハブ1200とWAN(Wide Area Network)により接続されるものとする。
【0094】
具体的には、IoTルータ1300は、宅内ネットワークなどインターネットに接続されていないIoTデバイスがIoTハブ1200に接続することを実現するものである。
【0095】
そして、IoTハブ1200は、第一のドライバ1210または第二のドライバ1220の少なくとも一方を有する。
【0096】
第一のドライバ1210および第二のドライバ1220は、各IoTデバイスのメーカごとの仕様の違いを吸収するものである。
【0097】
第一のドライバ1210は、第一のデバイス1410が接続可能なプライベートクラウド1400と当該IoTハブ1200とを接続するためのものである。
【0098】
一例として、第一のデバイス1410とプライベートクラウド1400とはLAN(Local Area Network)またはWANによる接続とし、プライベートクラウド1400と第一のドライバ1210もLANまたはWANによる接続とするのが好ましい。
【0099】
プライベートクラウド1400は、第一のデバイス1410の事業者により提供されるものである。
図10ではプライベートクラウド1400が一つである場合が示されているが、この数は一つに限られるものではなく、複数のプライベートクラウド1400がIoTハブ1200に接続されることができる。また、IoTハブ1200は、複数の第一のドライバ1210を有してもよい。
【0100】
図11、異なる事業者A,Bにより提供される2つのプライベートクラウド1400A,1400Bの詳細を示したものである。
図11に示されるように、プライベートクラウド1400Aは、事業者Aが提供するアプリケーションA(以下、「アプリA」とする。)と接続され、第一のデバイス1410に対してアプリAによるサービスを提供するものである。
【0101】
同様に、プライベートクラウド1400Bは、事業者Bが提供するアプリケーションB(以下、「アプリB」とする。)と接続され、第一のデバイス1410に対してアプリBによるサービスを提供するものである。
【0102】
なお、
図10、11ではプライベートクラウド1400に第一のデバイス1410が一つだけ接続されている例が示されているが、
図12に示すように、一つのプライベートクラウド1400に複数の第一のデバイス1410が接続されてもよい。
【0103】
第一のデバイス1410は、事業者がプライベートクラウドを提供しているデバイスとすることができる。一例として、リモートロック機能を有する電子錠、AIスピーカ、リモート操作が可能な介護ベッドなどが挙げられるが、特にこれらに限定されるものではない。
【0104】
図10に戻り、第二のドライバ1220は、第二のデバイス1510とIoTハブ1200とを直接接続するためのものである。
【0105】
第二のデバイス1510は、インターネット上にあるIoTハブ1200とWANにより接続されることができる(LAN経由でもよい)。
【0106】
なお、
図10では第二のドライバ1220に第二のデバイス1510が一つだけ接続されている例が示されているが、一つの第二のドライバ1220に複数の第二のデバイス1510が接続されてもよい。また、IoTハブ1200は複数の第二のドライバ1220を有してもよい。
【0107】
第二のデバイス1510は、事業者がプライベートクラウドを提供していないデバイスとすることができる。一例として、扇風機、エアコン、窓、カーテン、照明などとすることができるが、特にこれらに限定されるものではない。
【0108】
そして、IoTルータ1300は、第三のドライバ1310を有する。また、IoTルータ1300は、複数の第三のドライバ1310を有してもよい。
【0109】
第三のドライバ1310は、第三のデバイス1610と当該IoTルータ1300とを接続するためのものである。
【0110】
一例として、第三のデバイス1610と第三のドライバ1310とはLANによる接続とし、IoTルータ1300とIoTハブ1200とはWANによる接続とするのが好ましい。
【0111】
第三のデバイス1610は、上述したとおり、宅内ネットワークなどインターネットに接続されていないIoTデバイスとすることができる。また、第三のデバイス610は、セキュリティ、プライバシーおよびセーフティ上の観点で、直接IoTハブ1200と接続すべきでないデバイスとすることができる。一例として、ガスコンロ、顔認証デバイス、センサ情報収集用データロガーなどとすることができるが、特にこれに限定されるものではない。ただし、後述する災害時のリスク低減の観点から、どのようなデバイスであっても第三のデバイス1610としてIoTルータ1300へ接続させるようにしてもよい。
【0112】
このように、本発明のIoT接続システム2000は、すべてのデバイスをクラウド上のIoTハブ1200に直接的に接続させるものではなく、一部のデバイスをローカル上のIoTルータ1300に接続させるハイブリッドタイプのIoT接続システムである。
【0113】
以上によれば、直接接続されたIoTデバイス同士のみならず、従来のプライベートクラウドに接続されたIoTデバイス同士も、容易に相互接続させることが可能となる。
【0114】
これにより、決まったメーカのIoTデバイス同士しか繋がっていなかった従来とは異なり、様々なメーカのIoTデバイスを容易に相互接続させることができる。また、様々なメーカのIoTデバイスを相互接続させることにより、従来にはなかったユニークなサービスを創造することができるようになる。
【0115】
例えば、本発明のIoT接続システム2000によれば、
図13に示すように、外部のサーバからの緊急地震速報を受信したら、ガスコンロに消火信号を送り、玄関ドアのカギを解錠するといったサービスを実現することも容易に可能である。
【0116】
ここで、
図14を用いて、情報処理端末(IoTハブ)1200のハードウェア構成について説明する。情報処理端末1200は、プロセッサ1201と、メモリ1202と、ストレージ1203と、入出力インターフェース(入出力I/F)1204と、通信インターフェース(通信I/F)1205とを含むことができる。各構成要素は、バスBを介して相互に接続される。
【0117】
情報処理端末1200は、プロセッサ1201と、メモリ1202と、ストレージ1203と、入出力I/F1204と、通信I/F1205との協働により、本実施形態に記載される機能、方法を実現することができる。
【0118】
プロセッサ1201は、ストレージ1203に記憶されるプログラムに含まれるコード又は命令によって実現する機能、及び/又は、方法を実行する。プロセッサ1201は、例えば、中央処理装置(CPU)、MPU(Micro Processing Unit)、GPU(Graphics Processing Unit)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(Application-Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)等を含み、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、1又は複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSI等と呼称されることもある。
【0119】
メモリ1202は、ストレージ1203からロードしたプログラムを一時的に記憶し、プロセッサ1201に対して作業領域を提供する。メモリ1202には、プロセッサ1201がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ1202は、例えば、RAM(Random Access Memory)、ROM(Read Only Memory)等を含む。
【0120】
ストレージ1203は、プログラムを記憶する。ストレージ1203は、例えば、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリ等を含む。
【0121】
通信I/F1205は、ネットワークアダプタ等のハードウェアや通信用ソフトウェア、及びこれらの組み合わせとして実装され、ネットワークを介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F1205は、ネットワークを介して、他の情報処理装置との通信を実行する。通信I/F1205は、各種データをプロセッサ1201からの指示に従って、他の情報処理装置に送信する。また、通信I/F1205は、他の情報処理装置から送信された各種データを受信し、プロセッサ1201に伝達する。
【0122】
入出力I/F1204は、情報処理端末1200に対する各種操作を入力する入力装置、及び、情報処理端末1200で処理された処理結果を出力する出力装置を含む。入出力I/F1304は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。
【0123】
入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報をプロセッサ1201に伝達できる全ての種類の装置のいずれか、又は、その組み合わせにより実現される。入力装置は、例えば、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(画像を介した操作入力)、マイク(音声による操作入力)を含む。
【0124】
出力装置は、プロセッサ1201で処理された処理結果を出力する。出力装置は、例えば、タッチパネル、スピーカ等を含む。
【0125】
上記IoTルータ1300についても、上記IoTハブ1200と同様のハードウェア構成とすることができる。
【0126】
また、IoTルータ1300は、所定の基地局と通信可能な情報処理端末とするのが好ましい。
【0127】
所定の基地局と通信可能な情報処理端末は、一例として、スマートフォンやタブレット端末などのSIMカードを挿入して用いる情報処理端末である。IoTルータ1300とIoTハブ1200との間の通信容量はひと月に100Mバイト以下の低容量であることから、IoTルータ1300には通信容量が少ない低額なSIMカードを挿入すれば足りる。一例として、一つの会議室の周辺に平均10ビーコン(人)が存在し、5分単位で情報をサーバに送信した場合には必要な通信容量は17.3M/会議室(月)である。
【0128】
また、IoTルータ1300は、バッテリを含むものとする。かかるバッテリは、充電することにより電力を蓄えることができるものである。IoTルータ1300は、満充電から3日程度は、電源に接続せずに本開示における機能を実現することができる。平常時(後述する特定の状況下に無い場合)には、IoTルータ1300は、電源に接続して使用されるものとする。
【0129】
そして、第三のデバイス1610は、特定の状況下において、IoTルータ1300が備えるテザリング機能を介してIoTハブ1200に接続されることができる。
【0130】
特定の状況は、第三のデバイス1610と所定の無線/有線LANとの接続が途絶えた状況、IoTルータ1300と所定の無線/有線LANとの接続が途絶えた状況などとすることができるが、これに限られるものではない。
【0131】
この特定の状況に陥る原因としては、停電が挙げられるが、これに限られるものではなく、Wi−Fi(登録商標)ルータの故障や接続不良等などが原因である場合もある。
【0132】
また、テザリング機能としては公知の技術を用いることができ、Wi−Fiテザリング、Bluetooth(登録商標)テザリング、USBテザリングなどの手法を用いることができる。
【0133】
以上の構成によれば、プライベートクラウドごとにサイロ化状態になっている暮らしのIoTを、インターネットを介して自由に相互接続して魅力的なサービスを提供することができる。
【0134】
具体的には、本開示によれば、直接接続されたIoTデバイス同士のみならず、従来のプライベートクラウドに接続されたIoTデバイス同士も、容易に相互接続させることが可能となる。
【0135】
また、以上の構成によれば、第三のデバイス1610が、特定の状況下において、IoTルータ1300が備えるテザリング機能によりIoTハブ1200に接続されることで、災害等においてIoTデバイスがネットワークに接続できない状態であっても、サービスを継続して利用することができるようになる。
【0136】
また、IoTルータ1300は、管理者装置によりRemote Control(遠隔操作)が可能なものとするのが好ましい。かかる構成によれば、IoTルータの一つ一つをフルサポートすることができるようになる。
【0137】
なお、上記遠隔操作は、管理者装置およびIoTルータ1300の双方に専用のアプリケーションをインストールしておくことで実現される。なお、遠隔操作のサポートのし易さを考慮して、IoTルータ1300としての情報処理端末は、Android端末を用いるのが好ましい。
【0138】
また、IoTルータ1300は、管理者装置によりCDM(Connected Device Management:多様なデバイス管理)されるものとするのが好ましい。かかるCDMは、既知のMDM(Mobile Device Management)の手法を用いて実現されることができる。かかる構成によれば、膨大数の世帯に設置されるIoTルータを即時に一元管理し、遠隔監視・更新することができるようになる。また、CDMにより、デバイスの設定やアプリの配布、更新を遠隔監視制御することができるようになる。これにより、コスト削減と業務効率化を実現することができる。
【0139】
また、IoTハブ1200へは認証されたアプリやデバイスしか接続できないが、IoTルータ1300は、IoTハブ1200をローカル(宅内等)に延長し、ローカルでなければ実現できないリアルタイム性、セキュリティやプライバシーの確保、通信量の削減などに対応させることができる。
【0140】
また、IoTルータ1300を情報処理端末とすることで、顧客のスマートフォンや家庭内のインターネット回線を使用する必要がなくなり、想定外のトラブルが発生するリスクを低減させることができる。
【0141】
また、本発明のIoT接続システム2000は、第一のドライバ1210、第二のドライバ1220および第三のドライバ1310を作成するのにユーザが記述すべき情報は、デバイス定義およびコマンド定義に関する情報に限られてもよい。
【0142】
ここで、第一のドライバ1210、第二のドライバ1220および第三のドライバ1310を作成する方法について説明を行う。なお、作成者は、IoTデバイスの製造開発に関するユーザ、あるいは、本発明のIoT接続システムの提供に関するユーザとすることができる。
【0143】
なお、第一のドライバ1210および第二のドライバ1220と、第三のドライバ1310とは、同内容の情報が記述されればよく、プログラミング言語が異なるものであってもよい。
【0144】
初めに、作成者は、デバイス定義として、利用機器一覧を定義する。一例として、利用機器として「気象センサ」、「屋内センサ」、「屋外センサ」、「不審者センサ」、「承認センサ」、「電力センサ」を定義する場合には、これらの名称およびそのIDとなる「weather」、「inhouse」、「outdoor」、「security」、「approve」、「power」を記述する。
【0145】
続いて、作成者は、コマンド定義として、利用可能コマンドを定義する。一例として、「屋外センサ」の利用可能コマンドを定義する場合には、センサ値の観測コマンドを記述する。観測コマンドは、一例として、「観測」,「ゲット」,「屋外を観測します」などとすることができる。
【0146】
以上のデバイス定義およびコマンド定義に関する情報を、作成者が穴埋め形式でプログラムに埋めていくことにより、第一のドライバ1210、第二のドライバ1220、第三のドライバ1310を完成させることができる。その他の部分については、SDKとして提供者から提供されることができる。
【0147】
SDK部分は、受信したコマンドでのデバイス操作処理に関する部分、収集したセンサデータ/操作結果データの前処理に関する部分、IoTハブへのデータ送信処理に関する部分を含むものとする。
【0148】
以上の構成によれば、様々な形態のIoTデバイスに対するドライバを簡易に完成させることができるため、IoTデバイスを柔軟にかつ容易に接続可能なIoT接続システムを実現することが可能となる。
【0149】
通常、デバイスの開発に係るエンジニアは、Web開発のエンジニアとは取得している技術の分野が異なり、デバイスをIoTハブに繋ぐことができる技術レベルを有していない者も多い。
【0150】
そのため、本開示のように、どのドライバ用プログラムに対しても共通の穴埋め形式の簡易な手法で作成が可能であることは、非常に有益である。これにより、IoTデバイスのIoTハブへの接続に係る開発コストや開発期間を従来よりも抑えることができる。
【0151】
また、開発コストの低減により、扇風機とエアコンのように掛けられるコストの許容値に差がある場合であっても、平等にIoTハブへの接続を実現することができる。
【0152】
続いて、本開示におけるIoT接続システム2000に係るIoTハブ1200とIoTアプリとの接続について説明する。
【0153】
図10に示されているように、IoTハブ1200は、IoTアプリ1700を利用するためのWebAPI1230を有することができる。なお、
図10に示すように、IoTアプリ1700はサービスの数だけ接続されることができ、それぞれがWebAPI1230を使用して接続されることができる。
【0154】
IoTアプリ1700は、アプリ内にIoTデバイス(センサ)からのデータ取得ロジックおよび/またはIoTデバイスの操作ロジックを記述することで作成される。
【0155】
データ取得ロジックは、取得したセンサデータの前処理を行う部分と、IoTハブ1200のAPIへの送信を行う部分とで構成される。必要な情報は、IoT接続システム2000の運営者から提供される接続先URL、運営者から提供されるAPIキー、デバイス情報および実行コマンドである。
【0156】
デバイスの操作ロジックは、操作したいデバイスコマンドの前処理を行う部分と、IoTハブ1200のAPIへの送信を行う部分とで構成される。必要な情報は、IoT接続システム2000の運営者から提供される接続先URL、運営者から提供されるAPIキー、デバイス情報および実行コマンドである。
【0157】
図15は、IoTサービス利用者(エンドユーザ)が、IoTデバイス事業者により提供されたIoTデバイスを用いて、IoTサービス提供事業者からIoTサービスの提供を受けるフローを示した図である。
図15に示すように、初めに第一のデバイス1410からイベントの通知があると、プライベートクラウド1400、第一のドライバ1210、WebAPI1230、IoTアプリ1700を介してエンドユーザにイベントが通知される。
【0158】
続いて、エンドユーザがアクションを決定すると、IoTアプリ1700、WebAPI1230、第二のドライバ1220を介して第二のデバイス510にアクションの実行が指示される。
【0159】
IoTデバイスの連携は、「〜がこうなったら〇〇する」といったイベント駆動型のプログラムで表現することができる。そして、この処理をマイクロサービスとして部品化し、共通化して使えるようにしたうえで、FaaS(Function as a Service)の関数として実装することができる。
【0160】
ところで、上述したIoTデバイスである第一のデバイス〜第三のデバイスは、近年のIoT分野の発展により様々なメーカにより開発・製造されることとなった。しかしながら、デバイスまたはIoTアプリとの常時接続は、Google社またはApple社等の大手ベンダーが提供するプッシュ通知用サービスのためのサーバに接続可能なデバイスに限られるという問題があった。
【0161】
本開示におけるIoTハブ1200は、すべてのIoTデバイスの連携を目的として、常時接続機能と、ディレクトリ機能とを実現することを特徴とする。
【0162】
常時接続機能は、第一のデバイス1410、第二のデバイス1510および第三のデバイス1610ならびにIoTハブ1200を介して利用可能なIoTサービス(IoTアプリ1700)を相互に常時接続させるものである。
【0163】
ただし、IoTハブに接続されるIoTデバイスには、常時接続が必須でないものと、必須なものの2種類がある。前者には、定期的または不定期的に情報を発信するセンサ系のデバイスが含まれる。後者には、リモコン操作を行う必要がある制御可能装置のようなデバイスが含まれる。よって、本開示における上記常時接続機能は、後者の常時接続が必須のIoTデバイスに対しては常時接続を、前者の常時接続が必須でないIoTデバイスに対しては求められた時に限定した接続を実現すればよい。
【0164】
常時接続機能は、本開示におけるIoTハブ1200と第一のデバイス1410、第二のデバイス1510および第三のデバイス1610ならびにIoTサービス1700とを、IoT向けのMQTT(Message Queue Telemetry Transport)等の通信プロトコルを用いることで実現することができる。
【0165】
また、ディレクトリ機能は、第一のデバイス1410、第二のデバイス1510および第三のデバイス1610ならびにIoTサービスを相互に連携させる。
【0166】
すなわち、ディレクトリ機能は、あるモノ(デバイス)からあるサービスへ、あるサービスからあるモノへ、あるモノからあるモノへ、モノまたはサービスを特定し、モノまたはサービスへ指示する機能を実現するものである。
【0167】
そして、ディレクトリ機能は、連携元のデバイスにより指定された連携先のデバイスを、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報に基づいて特定することができる。
【0168】
デバイスの識別情報は、IoTデバイスのUUIDである。ドライバの識別情報は、ドライバのIDである。接続界面の識別情報は、ドライバとIoTハブ1200との界面であるR界面を特定するための情報である。
【0169】
また、ディレクトリ機能は、さらに、連携先のデバイスを、IoTハブ1200の識別情報に基づいて特定することができる。
【0170】
なお、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報は、所定の記憶装置に記憶され、当該記憶装置は、さらに、接続を許可しない接続元デバイスの識別情報および/またはデバイスの機能をホワイトリストとして記憶することができる。かかるリストについては、後述するサポート方法のメニュー票を利用することができる。
【0171】
図16は、本開示におけるIoT接続システムにおける相互接続インフラの構造を示した概念図である。
図16に示すように、アプリケーションとして示されるIoTアプリとIoTハブとの接続面はP界面であるが、WebAPI(α、β、γ)を使用して接続することで標準化されたQ界面持つことができる。
【0172】
同様に、IoTデバイスとIoTハブとの接続面はS界面であるが、ドライバ(A〜Z)を使用して接続することで標準化されたR界面を持つことができる。
【0173】
従来、IoTアプリはIoTデバイスの組み込みアプリと情報の授受を行うために、IoTアプリ側で宛先となるIoTデバイスを指定する必要があるとともに、IoTデバイス側でもIoTアプリから指定が可能な識別情報を持つ必要があった。
【0174】
一方、本開示のIoT接続システムにおいて、上記宛先の指定はIoTハブにより実現されるディレクトリ機能により行われる。
【0175】
例えば、IoTデバイスの追加や交換は、IoTハブにドライバを追加して接続先を追加または切り替えることのみで対応可能となり、IoTアプリ自体を修正する必要がない。
【0176】
すなわち、IoTアプリにおいて必要であったIoTデバイスを指定する宛先部分、および、IoTデバイスにおいて必要であったIoTアプリから指定が可能な識別情報部分は、いずれのIoTハブに集約されることができる。
【0177】
そのため、IoTデバイスの追加や交換は、アプリ開発者の工数を増やすことはなく、コストの低減につながる。
【0178】
このように、本開示におけるIoT接続システムによれば、IoTデバイスの製造メーカや機種が異なっても、IoTハブに接続されることでプロトコルフリーな相互接続を実現することが可能となる。
【0179】
また、
図17に示すように、本発明のIoTハブ1200は、関所エンジン1800と接続されることができる。この関所エンジン1800は、IoTハブ1200がデバイスに指示する内容をチェックし、不適切なアクションが実行されることを防ぐためのものである。
【0180】
例えば、“外気が爽やかなら、エアコンを止めて窓を開ける”、といったIoTサービスを提供する場合、直後にゲリラ豪雨に見舞われると室内が濡れてしまうおそれがあるが、上記関所エンジン1800は、このようなIoT由来の脅威を未然に防ぐためのものである。
【0181】
また、本発明の第一のドライバ1210、第二のドライバ1220および第三のドライバ1310の少なくとも一つは、仮想デバイス機能を実現することができる。
【0182】
この仮想デバイス機能は、第一のデバイス1410、第二のデバイス1510または第三のデバイス1610を仮想的に再現するものである。
【0183】
図18は、本発明の第二のドライバ1220が仮想デバイス機能を実現する例を示したものである。
図18に示すように、第二のドライバ1220に、第二のデバイス1510のコマンドの送受信を再現可能な仮想デバイス1900を設けることにより、仮に第二のデバイス1510が接続されていなくても、第二のデバイス1510を用いるIoTアプリの開発が可能となる。また、動作不良があった場合、現地に赴かずとも第二のデバイス1510とIoTハブ1200のどちらが故障しているのか故障切り分けを容易に行うことができる。
【0184】
また、本発明では、
図19に示すように、ドライバではなくIoTハブ1200に仮想デバイス機能を実現させてもよい。これは、ローカルに存在するIoTルータ1300に接続される第三のデバイス1610の故障切り分けに有効な手段である。
【0185】
上述したとおり、本開示におけるIoTハブは、異なる通信プロトコルを使用するクラウド間であっても、ドライバと呼ばれるインターフェースによって、それらの相互接続を可能とするプロトコルフリーのインフラである。また、ディレクトリ機能によって、複数のアプリやIoTデバイスを複雑に組み合わせて接続をすることも可能である。
【0186】
また、本発明のIoT接続システム2000において、第一のデバイス1410、第二のデバイス1510または第三のデバイス1610から取得される情報は、IoTハブ1200では保存されないものとすることができる。
【0187】
本発明のIoT接続システム2000は、電気通信事業者により運営されることを想定している。電気通信事業者は、通信の秘密を遵守する義務が課せられるため、各種デバイスから取得される情報を、他の利活用を目的として保存することはしない。
【0188】
これら情報は有益な情報であるため、各社のプライベートクラウドではかかる情報を独占的に取得すべく、IoTデバイスの囲い込みを行うのが通常である。
【0189】
一方で、本発明のIoT接続システム2000は、運営を電気通信事業者が行うことにより、各IoTデバイスおよびIoTアプリを中立の立場で相互接続させ、IoTビジネスを促進させることができる。
【0190】
また、IoT相互接続サービスの継続性は利用する企業のIoTサービスの継続性に影響するため、利用企業が共同で相互接続インフラを共有するのが好ましい。
【0191】
また、本発明のIoT接続システム2000において、IoTハブ1200に接続できるのはAPIキーと認証スキームにより許可されたデバイスやIoTアプリのみとすることができる。すなわち、本発明のIoT接続システム2000は、インターネット上にIoT通信専用の閉域網を構築することができる。また、通信経路も暗号化され、MDM(Mobile Device Management)の手法を用いてIoTルータも管理するため、新たな攻撃方法やOSやアプリの脆弱性対応も可能とする。
【0192】
また、IoT化されていないデバイスをIoTハブ1200に接続するには、BaaS(Backend as a service)やSDKを活用することで、短期間での開発を行うことができる。
【0193】
以上の構成によれば、上述した従来技術の問題の少なくとも一部を解決又は緩和する技術的な改善を提供することができる。また、以上の構成によれば、複数のデバイスの機能を組み合わせた新たなサービスの創造を効率的に行うことができるようになる。
【0194】
サーバ装置300は、
図8に示すように、さらに、送信部350を有することができる。
【0195】
送信部350は、第二の情報処理装置200から受け付けた第一識別情報に対応する第一の情報処理装置100に対してのみ、特定の電子錠を解除可能な解除キーに関する情報を送信する。
【0196】
すなわち、自身のスマートフォンにアプリを入れている人だけ会議室への入出を許可するなどすることができる。
【0197】
以上、上記の実施形態において、第二の情報処理装置200が信号を受信する機能を有する装置であって会社内の会議室等に設置されるもので、第一の情報処理装置100が信号を発信する機能を有するスマートフォン等の装置であってユーザが所持するものであることを想定して説明を行ったが、これらの発信受信機能は逆であってもよい。すなわち、第一の情報処理装置100が信号を受信する機能を有し、第二の情報処理装置200が信号を発信する機能を有するものであってもよい。
【0198】
また、第一の情報処理装置100および第二の情報処理装置200のいずれもが発信機能および受信機能の両方の機能を有するものとしてもよい。この場合、どちらの装置がどちらの機能を実現するのかはサーバ装置300からの指示に基づいて遠隔で自動的に切り替えられるものとすることができる。
【0199】
また、発信機能を実現する装置(上記の実施形態では第一の情報処理装置100)としては、上述したスマートフォン等の情報処理装置に限られず、タグ型の発信機(所謂「ビーコンタグ」)を用いることも可能である。
【0200】
これによれば、スマートフォンを所持しない/することができない子供や高齢者、持ち歩けない医療・介護従事者の行動履歴を容易に確実に取得することができ、かつ、上記者と同じ場所にいた者を容易に確実に特定することができるようになる。
【0201】
以下に、本開示における情報処理システム、情報処理方法およびコンピュータプログラムにより実現されるサービスの実施形態について説明する。
【0202】
<概要>
本開示における情報処理システム、情報処理方法およびコンピュータプログラムにより実現されるサービスによれば、会議室等にIoTセンサを設置し、当該会議室に一定時間入室した社員をその所有するスマートフォンにより特定することができる。
【0203】
社員の中で新型コロナウイルス等の感染者が見つかった時に、その情報を利用して濃厚接触者を特定できる。このことにより、ビル内に出入りした社員全員では無く、濃厚接触者のみを自宅待機させたりするなどの感染拡大の防止手段が取りやすくなる。
【0204】
合わせて、IoTセンサとして室内環境センサ等の様々なセンサを組み込むことにより、室内環境の継続的なモニターを行い、適切な換気等により室内での感染拡大をできるだけ防止するというような措置も採ることが可能となる。
【0205】
<提供方法>
本サービスを提供するにあたり、IoTセンサとそのセンサがインターネットと通信するためのゲートウェイ(IoTルータ)を提供する。なお、IoTセンサの中でもBLEビーコンをブロードキャストして入室する社員を特定するための機能はIoTルータに内蔵される。
【0206】
また、社員がBLEビーコンを受けて入室したことを特定するためには、社有ないしは私用スマホに本開示におけるアプリケーションを事前にインストールして登録する必要がある。
【0207】
この仕組みによって収集された入室情報および室内の環境情報は、以下に詳説する「IoT Exchange」を通して「Corona Tracer」サービス内に蓄積され、各企業の担当者が自由に引き出すことができる。
【0208】
なお、情報の取り出しとその情報に基づいたアクションについては、RPA(ロボティック・プロセス・オートメーション)などの自動化ツールを使っても良い。
【0209】
<サービスの構成要素とその機能>
「IoT Exchange」は、センサ等を制御するための命令やセンサから上がってくる情報を送受信する。
【0210】
「IoTルータ」は、環境センサとの接続を担って、環境データを「IoT Exchange」に送信するだけで無く、内蔵するBLEチップがBLE送受信機としての役割を果たし、スマートフォンから送出されるBLEビーコンを受信したり、自らBLEビーコンを送出したりすることができる。
【0211】
「環境センサ」は、会議室等の環境データ(室温、湿度、騒音、CO
2量、揮発性有機溶媒量等)を測定して、IoTルータ経由で「Corona Tracer」サービスに送付する。
【0212】
「Corona Tracer App」は、iOSおよびAndroidに対応し、社員の持つスマートフォン(社給ないしは個人所有)にインストールされ、BLEビーコンを送信する。また、BLEビーコンが常に送信されているかの確認情報を「Corona Tracer」サービスに対して送出する。また、BLEビーコンを受信してその情報(タイムスタンプ、会社ID、社員ID、ビーコンID、ビーコン強度)を「Corona Tracer」サービスに送付するものであってもよい。
【0213】
「Corona Tracer」サービスは、環境センサ、IoTルータおよび「Corona Tracer App」からの情報を収集して保存する。また、本サービスはIoTルータの設定を遠隔で行うことができる。また、IoTルータをBLE発信機として利用する場合には、BLEの早出間隔や送信強度を変更することができる。本サービスは更に、社員の会議室への入退出情報についてレポートを生成してcsvファイルに保存することができる。
【0214】
「RPA」または、連携を希望する他システムは、「Corona Tracer」サービスにアクセスし、社員の会議室入退出情報を取得し、その情報に基づいてレポートを生成したり、アラートを送出したりする。
【0215】
<サービス提供の準備>
本サービスの提供にあたっては、会議室へのデバイスの設置と社員によるアプリのインストールおよびRPAまたは、連携を希望する他システムへの種々の登録が必要である。会議室に設置されるデバイスは、IoTルータ、環境センサ及びACアダプタである。電源が室内に無い場合には、モバイルバッテリーも必要である。IoTルータはAndroidスマホであるが、アクティベーション、アプリのインストレーション等のキッティングは本サービス提供者にて行う。よって、設置業者は本デバイス一式を会議室に置いていくだけで良い。
【0216】
社員のスマホにインストールされるアプリは、Google Play StoreないしはApple App Storeからそれぞれの社員がダウンロードし、インストールすることとする。また、インストール後は、会社IDと社員IDを登録する必要がある。
【0217】
先行技術文献として挙げたアプリケーションは、双方がスマホにアプリを入れていることが前提であるが、本開示における発明によれば、片方はタグなどでも動作可能である。これにより、スマートフォンを持っていない子供や高齢者、持ち歩けない医療・介護従事者にも対応可能である。
【0218】
また、先行技術文献として挙げたアプリケーションは、スマートフォンに保存する方式のみであるが、本開示における発明によれば、スマートフォンおよびクラウドの双方に保存する方法を選択可能である。また、双方の相対距離情報と本人を特定できる情報を全く別システムとして分離し、連携システム経由でのアクセスしかできないよう制限されている。これにより、端末側の情報、クラウド側の情報にアクセスできたとしても情報の入手は不可能である。
【0219】
また、先行技術文献として挙げたアプリケーションは、スマートフォン用アプリケーションであって親機・子機の概念がなくいずれの端末も対等であり位置情報を取得しないことが前提であるが、本開示における発明によれば、受信側を特定の場所に設置することができるため、集団感染場所の特定を容易に行うことができる。これにより、集団感染が発生した場所と日時を容易に特定できる。具体的には、会議室、トイレ、店舗、クラブ、教室、カラオケルームなどである。場所や日時が特定できれば、その場所にいた人間がスマートフォンやアプリ、タグ等を持たない人がいた場合でも、感染リスクを知らせることができる場合がある。また、本開示における発明によれば、子機が何台あっても、親機が受信する方式なので、データ蓄積・収集先を限定・一元化することができる。親機は、会社が会議室等に導入・設置して管理することで、親機の場所(位置情報を含む)を特定することができる、なお、親機は会社が遠隔から運用保守可能とするのが好ましい。
【0220】
また、先行技術文献として挙げたアプリケーションは、このアプリケーションが必ず必要で、これ以外の同様のアプリケーションやサービスと連携することが難しいが、本開示における発明によれば、特定の企業、団体、自治体等が個別に入れたシステムを簡単に相互接続することができ、契約が成立した相手と契約に基づいた情報だけを共有することができる。これにより、個人の同意や契約に基づかない情報の共有は行われないことが保証できる。
【0221】
また、先行技術文献として挙げたアプリケーションは、基本的に個人情報を極力特定しない方式の一般的な感染情報共有システムであるが、本開示における発明は、事業者の設置した場所の情報を追加できるので、どの場所が感染場所になったかを特定することができる。その結果、事業者が事業停止リスクを減少させ、かつ従業員の安全を確保することが可能になる。ここでいう事業者とは、会社(会議室、トイレ)、学校(教室、トイレ)、店舗(飲食、カラオケ、クラブ等)など、これまで個別に対策を取れなかった事業者全てである。
【0222】
また、本開示における発明は、第一の情報処理装置が備えるGPS(Global Positioning System)機能と連動させて、帰国後自宅待機を命じられた人の周辺で感染者が発生した場合に、自分は自宅にずっと待機していたことを証明するために自分の位置情報を提出できるような仕組みを構築してもよい。
【0223】
最後に、本開示における情報処理方法およびコンピュータプログラムの実施形態について説明する。
【0224】
本開示における情報処理方法は、
図1に示したように、信号を発信する機能を有する第一の情報処理装置100と、信号を受信する機能を有する第二の情報処理装置200と、第二の情報処理装置200とインターネットを介して接続可能なサーバ装置300とを備える情報処理システム1000において実行される情報処理方法である。
【0225】
本開示における情報処理方法は、
図20に示されるように、第一の情報処理装置100に、当該第一の情報処理装置100の第一識別情報を含む信号を発信するステップS10を実行させる。
【0226】
そして、本開示における情報処理方法は、第二の情報処理装置200に、第一の情報処理装置100から発信された信号を受信するステップS20と、信号を受信した時刻に関する時刻情報、信号の受信強度に基づく強度情報および第一識別情報を、第二の情報処理装置200の第二識別情報とともにサーバ装置300に送信するステップS30とを実行させる。
【0227】
そして、本開示における情報処理方法は、サーバ装置300に、第二の情報処理装置200から受信した時刻情報、強度情報、第一識別情報および第二識別情報を互いに関連付けて記憶するステップS30と、特定の第一の情報処理装置100の特定の第一識別情報の指定を受け付けるステップS40と、特定の第一の情報処理装置100の特定の第一識別情報の指定を受け付けた場合に、特定の第一識別情報に関連付けて記憶された特定の第二識別情報に基づいて、当該特定の第二識別情報に関連付けて記憶された1以上の他の第一識別情報を抽出するステップS50とを実行させる。
【0228】
以上のように、本開示における情報処理方法によれば、特定の第一の情報処理装置を有する者が、いつ何処にいたかという行動履歴を容易に確実に取得することができ、かつ、上記者と同じ場所にいた者を容易に確実に特定することができるようになる。すなわち、本開示における情報処理方法は、感染者のトレーサビリティを可能にする。
【0229】
本開示におけるコンピュータプログラムは、信号を発信する機能を有する第一の情報処理装置と、信号を受信する機能を有する第二の情報処理装置と、第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システムにおいて実行されるコンピュータプログラムである。
【0230】
本開示におけるコンピュータプログラムは、第二の情報処理装置に、第一の情報処理装置から発信された第一の情報処理装置の第一識別情報を含む信号を受信する機能と、信号を受信した時刻に関する時刻情報、信号の受信強度に基づく強度情報および第一識別情報を、第二の情報処理装置の第二識別情報とともにサーバ装置に送信する機能とを実現させる。
【0231】
そして、本開示におけるコンピュータプログラムは、サーバ装置に、第二の情報処理装置から受信した時刻情報、強度情報、第一識別情報および第二識別情報を互いに関連付けて記憶させる機能と、特定の第一の情報処理装置の特定の第一識別情報の指定を受け付ける機能と、指定を受け付けた場合に、特定の第一識別情報に関連付けて記憶された特定の第二識別情報に基づいて、当該特定の第二識別情報に関連付けて記憶された1以上の他の第一識別情報を抽出する機能とを実現させる。
【0232】
以上のように、本開示におけるコンピュータプログラムによれば、特定の第一の情報処理装置を有する者が、いつ何処にいたかという行動履歴を容易に確実に取得することができ、かつ、上記者と同じ場所にいた者を容易に確実に特定することができるようになる。すなわち、本開示におけるコンピュータプログラムは、感染者のトレーサビリティを可能にする。
【0233】
最後に、本開示における情報処理システムの他の適用例について説明する。
新型コロナウイルスは、主に感染者との飛沫接触等により伝染する事が報告されており、公衆衛生機関は、感染拡大を抑えるためには感染経路を断つこと、やむを得ず接触し感染した場合には速やかに濃厚接触者を特定するように求めている。
【0234】
そのため、政府や感染症研究機関は、感染者の利用等があった場所(店舗、事業所、等の施設)を公開し、GPS等の位置情報を使って地図上で確認できるサービスを提供する会社や、非特許文献1のように、感染経路を追跡し、濃厚接触者に通知できるサービスも現れている。
【0235】
非特許文献1に記載されたサービスでは、該当のアプリをインストールしているスマートフォン同士が近づくと、端末ごとに割り振られたIDを近距離無線通信の「ブルートゥース」を使って交換し、記録する。感染した人がアプリ利用者の時は、保健省の職員が本人の同意を得た上でアプリ上の記録を手掛かりに感染者の近くに一定時間以上いたスマートフォン利用者を特定・連絡し、必要な措置を講ずる。
【0236】
このようなアプリの活用により、本人が気付かない濃厚接触者を追跡することができ、クラスター(感染者集団)の早期発見や感染の恐れがある人の早期隔離に効果がある。しかし、このアプリはスマートフォンの利用が前提であり、しかも大勢の人が利用しないと効果が高まらない。
【0237】
現在、新型コロナウイルスの感染拡大対策として緊急事態宣言が発令され、多くの企業が外出自粛の要請をされている。しかし、在宅では対応できない業務や、社会機能を維持するために必要な業種もあり、そうした業務に従事する人々は、引き続き出勤を継続せざるを得ない状況を強いられている。
【0238】
ところが、現在では国民生活・国民経済の安定確保に不可欠な業務を行う企業、店舗、病院等でも感染者が発見され、特定の業務だけでなく事業そのものを一時的に停止しなければならない事態が発生している。
【0239】
既に、すべての事業者にとって、濃厚接触者を速やかに特定し、仕分けを行うことが、事業継続性(BCP)対策として必須になっている。
【0240】
そこで、本発明者は、企業のBCP対策を目的として、第二の情報処理装置200として会議室等に設置した本開示におけるIoTルータ1300を活用して「濃厚接触者特定サービス」を開発した。
【0241】
まず、企業の会議室など「三密」になりやすい場所に、本開示におけるIoTルータ(親機:第二の情報処理装置200)を設置する。そこに、Beaconアプリをインストールしたスマートフォン(子機:第一の情報処理装置100)を持った社員が近づくと、社員の子機UUIDと距離を検知し、時刻と共に記録する。
【0242】
そのため、総務部門等の管理者は、感染した社員名を指定するだけで、濃厚接触の可能性のある社員名を簡単に特定することができる。
【0243】
この「濃厚接触者特定サービス」は、「Beaconデータ収集システム」と「濃厚接触者特定システム」という別々のシステムを、「IoTハブ」と「IoTルータ」を経由し、必要なデータを必要な時に必要な分だけ取得する仕組みになっており、管理者が誰かの行動を監視し続けることはできない仕組みになっている。
【0244】
すなわち、本開示における第一の情報処理装置100および第二の情報処理装置200を含むシステムが「Beaconデータ収集システム」であり、サーバ装置300を含むシステムが「濃厚接触者特定システム」であり、上述したIoTハブ1200がこれらを繋ぐハブとして機能する。
【0245】
そのため、高いプライバシー保護とセキュリティ確保を両立することが可能である。すなわち、収集するデータを個人情報に当たらないものだけに限定した「Beaconデータ収集システム」と社員の氏名と連絡先といった個人情報を扱う「濃厚接触者特定システム」という二つのシステムを作り、これら二つのシステムを分けることによって、情報を遮断する。
【0246】
そして、これらのシステムを必要な時に限りIoTハブを使って疎結合することで、社員の行動の常時監視を防止しつつ、濃厚接触者を特定できるようにする。
【0247】
かかるシステム構成は、IoTハブ1200に様々な機能のシステムを接続することにより機能を拡張していくことが可能である。
【0248】
続いて、
図21を用いて感染者発生から濃厚接触者を特定するフローを説明する。
【0249】
具体的には、予め、
図21に示すBeaconデータ収集システム3100において、会議室に設置したBeaconやスマートフォンアプリを利用して、会議室にいた人のデータ(UUID、時刻、親機であるIoTルータと子機であるスマートフォンの距離)を自動収集する。このBeaconデータ収集システム3100には、個人情報は一切含まれない。
【0250】
そして、管理者が感染者となった従業員から感染の報告を受けた際には、管理者は、管理画面から従業員の名前を入力する。そうすると、濃厚接触者特定システム3200は感染者のUUIDをBeaconデータ収集システム3100に送付する。このUUIDを基にBeaconデータ収集システム3100は、濃厚接触の恐れがあるUUIDを特定し濃厚接触者特定システム3200に送付する。そして、このシステム3200はUUIDと氏名を紐づけ、濃厚接触候補者リストとして出力する。管理者である総務の担当者は、そのリストの情報から優先順位を付けて濃厚接触者候補に連絡し、自宅待機や検査の指示、継続的な報告などの指示を行う。
【0251】
なお、「Corona Tracer」では、BLEをBeaconとして活用している。スマートフォン同士でBeaconを活用し、濃厚接触を検知することも可能であるが、スマートフォンを持たない社員がいること、一部のスマートフォンはBLEの双方向通信が可能でないことを考慮し、IoTルータを親機として活用し、BLE双方向通信ができない社員にはBeaconタグを持たせることで全ての社員がシステムを使うことができるようにしている。スマートフォン間のBLE活用で収集したデータは、距離精度の向上など補助的な用途に活用されている。
【0252】
なお、本システムの管理者はIDとパスワードをメールで社員に通知する。通知を受けた社員がアプリをインストールする際に送付されたIDとパスワードを入力するとスマートフォンの中で自動的にUUIDが生成され、氏名とともに濃厚接触者特定システムに登録される。Beaconデータ収集システムには、このUUIDのみが送付され記録に使用されるので、UUIDから個人の特定はできない。
【0253】
また、IoTハブを利用することにより、異なる会社のデータを契約に基づき限定的に情報共有することができる。この機能を活用すれば、同席した別の会社の社員にも感染リスクがあることを教えることが可能になる。
【0254】
また、導入企業が同意すれば、個人情報を伏せて、政府や自治体、または保険機関に情報を一括して提供することも可能である。これにより、感染者集団(クラスター)情報をいち早く提供することが可能になる。
【0255】
最後に、第一の情報処理装置100に代えて、または、加えて、二次元コードを印刷した媒体を用いた例について付記する。
【0256】
上述した実施例では、第一の情報処理装置100に専用のアプリケーションがインストールされた者を対象者であると想定して説明を行ったが、他の情報処理装置(専用のアプリケーションがインストールされていない情報処理端末)を有する者や、情報処理端末を有しない者などが会社に来訪する場合も多い。
【0257】
例えば、工事などを行う作業員や、会議などのために一時的に来訪する者などの来訪者などは、上述した専用のアプリケーションをインストールしたスマートフォンやビーコンタグを用いて管理するよりも、入館証にQRコード(登録商標)などの二次元コードを印刷し、この二次元コードに含まれる情報を管理する方が容易である。
【0258】
このQRコードには、来訪者の氏名および連絡先(メールアドレスおよび/または電話番号等)の情報を記録する。これらの情報は、来訪時に来訪者が所定の入力端末を介して入力するものであってもよいし、来訪者または迎え入れる側の者が事前に登録しておくものであってもよい。
【0259】
そして、来訪者は会議室に入室した際に、会議室に設置された親機である第二の情報処理装置200に、自身の入館証に印刷された二次元コードを読み取らせる。これにより、来訪者の情報、および、読み取った時間等の情報はサーバ装置300に記録される。
【0260】
なお、二次元コードを読み取るのは親機に限られず、子機である第一の情報処理装置100が読み取り、親機に送信する形式としてもよい。
【0261】
そして、上述した実施形態と組み合わせ、来訪者に対して連絡する必要がある場合には、連絡先として記録されたメールアドレスや電話番号に対してEメールまたはSMS(ショートメッセージサービス)を送信することにより行われるのが好ましい。
【0262】
さらに、上記二次元コードは、オンライン名刺として活用することも可能である。すなわち、実際の紙媒体を交換する従来の名刺交換に代えて、名刺の内容を二次元コードに記録してスマートフォン等の画面に表示することで、接触を避けて遠隔からでも名刺交換を行うことが可能になる。
【0263】
また、会議において参加者に共有される画面上にオンライン名刺を表示することで、参加者と一斉に名刺交換を行うことも可能である。
【0264】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【0265】
また、実施形態に記載した手法は、計算機(コンピュータ)に実行させることができるプログラムとして、例えば磁気ディスク(フロッピー(登録商標)ディスク、ハードディスク等)、光ディスク(CD−ROM、DVD、MO等)、半導体メモリ(ROM、RAM、フラッシュメモリ等)等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウェア手段(実行プログラムのみならずテーブルやデータ構造も含む)を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウェア手段を構築し、このソフトウェア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。記憶部は、例えば主記憶装置、補助記憶装置、又はキャッシュメモリとして機能してもよい。
【解決手段】信号を発信する機能を有する第一の情報処理装置と、信号を受信する機能を有する第二の情報処理装置と、第二の情報処理装置とインターネットを介して接続可能なサーバ装置とを備える情報処理システム1000であって、サーバ装置は、第二の情報処理装置から受信した時刻情報、強度情報、第一識別情報および第二識別情報を互いに関連付けて記憶し、特定の第一の情報処理装置の特定の第一識別情報の指定を受け付けた場合に、特定の第一識別情報に関連付けて記憶された特定の第二識別情報に基づいて、当該特定の第二識別情報に関連付けて記憶された1以上の他の第一識別情報を抽出する。